Re: SPARQL 1.1 Graph Store HTTP Protocol for Topic Maps

Hi Lars,

[...]
>> The protocol provides no fragments/snapshots like SDShare, though.

> So, in other words, you can't use it for what SDshare is used for.
> I'd say that's a clear "no" to the question of whether it's a good
> alternative to SDshare. :-)

:)

You're right, you cannot use it as replacement for SDShare yet but it
should be possible to extend it in that way.

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).

Currently, the service description ontology is more or less equivalent
to SDShare's collection feed (ignoring the links to
snapshots/fragments): It lists all available graphs.

[...]
> Well, how would you get the fragments, and how would you find out
> which new fragments have appeared since the last time you asked? I
> don't see that this protocol helps you with these things, but maybe
> I missed something. (Of course, you can invent some way to do it
> yourself, but then you might as well just skip the graph store
> protocol.)

IMO the advantage of the SPARQL 1.1 protocol is given through the
consequent usage of REST and graphs. Further, we can expect that the
SPARQL 1.1 HTTP protocol is widely adopted simply because RDF is more
widely used than, for example, Topic Maps. And given it's rather
generic description it could serve as a protocol for RDF and Topic
Maps.

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.

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.
That's basically my vague idea: Extend the SPARQL 1.1 HTTP protocol
with SDShare's fragments service (I am unsure if the snapshot
functionality is really needed).

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com/>

<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine
<http://mappa.semagia.com/> Mappa - Python Topic Maps engine