On 07/06/12 06:57, Stephen Allen wrote:
> So may there is a language lurking around here somewhere. It would
> stream-execute. More fine grained than GSP, less than full SPARQL Update.
>
> INSERT DATA, DELETE DATA
> BEGIN/COMMIT/ABORT
> CLEAR/DROP, LOAD
> CREATE DATASET, DROP DATASET
> UNMOUNT DATASET
> MOUNT DATASET
> BACKUP DATASET
> ...
I see where you're going with the BEGIN/COMMIT/ABORT. I think some
way of doing transactions and query identification (for tracking and
cancellation purposes) is something whose time has arrived, and we
should try out some implementations (with an eye towards future
standardization). The DATASET commands might be a little bit too
implementation specific for a standard, but would be a cool feature
for Fuseki.
That was a list of all possibilities mainly thinking about data
management not application update. It might be good to have some bulk
operations that are specially handled (e.g. to disk) which have
different replay characteristics. INSERT DATA, DELETE DATA can be
replayed onto a store; operations using WHERE can't in general.
This has been something Epimorphics have utilised running multiple
server for fault-tolerance and scalable performance reasons.
But the important point is multi-HTTP-request with interleaving of query
and update inside one transaction.
The DATASET operations are server control -- so there is a mix of
concerns in that list.
However I'm not convinced that we should have the overlapping SPARQL
Update commands. It seems that we probably want to support Update
properly, and then there wouldn't be much use for the overlap. SPARQL
1.1 Update appears amenable to streaming if we put some brainpower on
it. I don't have much experience with JavaCC, but am willing to
learn.
Doing the grammar, if we build a SPARQL-syntax, is quite easy and I can
contribute the grammar part. (How often does anyone write a grammar
from scratch rather than copy another one?!)
Andy
