Re: SPARQL 1.1 Graph Store HTTP Protocol for Topic Maps

* Lars Heuer
> 
> Each POST/PATCH/PUT request would trigger optionally new fragments (or
> snapshots). Further, the information about the snapshots/fragments is
> described in the service description document (a topic map or a RDF
> graph).

If you can represent the snapshot/fragment metadata in RDF/TM (plus somehow the snapshots/fragments themselves) you're getting somewhere.

> Synchronizing clients against a graph store is already possible if the
> clients and servers would utilize HTTP consequently: A server would
> send an ETag and/or a last modified header and the client would use
> that information for subsequent requests and either replace or update
> the local topic map. If a change is recognized, the client has to
> download the complete graph/topic map, though.

You can't download the whole thing, though. That makes it useless for most practical applications.

> Downloading the complete topic map/graph can be avoided in SDShare
> which is a big advantage of SDShare over the SPARQL 1.1 HTTP protocol.

More than that: it makes it feasible. Of course, in some cases downloading the entire dataset may work, but in general it won't.

> That's basically my vague idea: Extend the SPARQL 1.1 HTTP protocol
> with SDShare's fragments service

Then we would be talking.

> (I am unsure if the snapshot functionality is really needed).

In practice it's really useful as you are getting set up and need to restart as things change. The difficulty is getting it to work properly with big datasets.

--Lars M.
http://www.garshol.priv.no/tmphoto/
http://www.garshol.priv.no/blog/