Eric,
There are two way I can think of enforcing such a condition. Claude's
mentioned listening to graph changes, whereby you can fix up the data
after the change has been made.
To assist that you could provide your own GraphStore (just wrap the one
you actually want to update) and it has calls to startRequest and
finishRequest so you can know which points make the start and end of the
update request.
There is an event sent to the GraphEventManager to signal the start and
end of an update as well (called by startRequest/finishRequest). Except
checking I see these are not called for TDB - fix just applied.
startRequest() really should take the Request object as an argument -
again, added startRequest(Request), with a deprecation cycle to remove
startRequest().
If you want to enforce a condition before hand by checking the validity
of the update to see if it looks like it does include a :description in
the INSERT part, you can catch the update request object by adding your
own UpdateEngineFactory that passes the real request to an underlying
UpdateEngineFactory but gets to look at every request first.
Any feedback would be great - this is a reasonable thing to want to do
but it does look more complicated than it need be. In fact, what might
be a good idea is to plan out update request lifecycle have and specific
plug-in points.
If not, I gather best practice would be to provide a separate tool
for editing content which would not expose a sqarql update facility
to end users....
To be honest, if the condition is important then I'd do something like
this - have code that generates consistent updates. SPARQL is a general
purpose tool - packaging it up to give app-specific functionality seems
like a good design to me.
Andy
