Re: ACTION-4: Review SPARQL Graph Store Protocol and suggest how we should move forward with it

Thanks, Andy, that very useful but your example
http://server/graphstore?graph=http://example/snapshot556
did not work for me.
All the best, Ashok

On 9/19/2012 2:48 PM, Andy Seaborne wrote:
> tl;dr:
>
> GSP is a description of how to use HTTP for data management.  It defines very little; it is a direct use of HTTP.
>
> LDBP provides a higher level notion of resource - it places restrictions on data to enhance app interoperability but making it unsuitable for general data management.
>
> They are addressing different use cases.
>
> ----------------------------------
>
> See [1] - I see the two protocols (LBDP and GSP) as siblings both built on RFC 2616.  They have different use cases.
>
> LBDP adds machinery and restrictions to the use of HTTP in order to provide a lifecycle.
>
> GSP is a data management protocol for SPARQL graph stores.  It defines only:
>
> GSP-1: Indirect naming.
> GSP-2: POST means add triples.
>
> it is arguable that GSP-2 is "defining" anything because in RFC2616 section 9.5 already says:
> """
>       - Extending a database through an append operation.
> """
>
> So GSP defines indirect naming, nothing else.  This has been shown to be a useful and effective means of managing a graph store 9a collection of graphs).  GSP is deployed and in use today with multiple implementations.
>
> Indirect naming is the ability to have a graph name in a store that is not related to the local server name.  It is a common usage for graph store management.
>
> http://server/graphstore?graph=http://example/snapshot556
>
> Other than that, GSP is a description of how HTTP (RFC 2616) applies to a graph store.  GET means GET, PUT means create/replace, POST means add data, DELETE means delete.  A valid implementation of direct naming GSP is a file-system backed HTTP server.
>
> GSP has no concept of a container with an RDF presentation or containers-in-containers or of paging or ordering.
>
> LDBP does not consider indirect naming.
>
> LDBP is unsuitable for data management - it forbids general RDF data, for example. (4.1.9 - "BPR representations MUST use only the following standard datatypes"; 4.4.5 is also problematic where it hints at changing the predicates it does understand; 4.1.4 is at odds with IRI resolution; other requirements are problematic in intent and approach).
>
> If LDBP for BPRs removes the restrictions on simple "upload-download" to result in the same data then it might be able to use GSP(direct), and in fact it would just be RFC2616.
>
> LDBP for BPCs is not relevant for graph stores.  Graph stores do not have such a container model.
>
> Alternative:
>
> Why not make LDBP for BPRs be simply a link to RFC 2616? + discussion that text/turtle be provided.  Then a plain HTTP server can be used to provide LDBP for BPRs (not BPCs).
>
> > The reality is that many implementations of LDBP will be
> > based on graph stores,
>
> The key here is "will be based on graph stores" rather than "will be graph stores"  -- the graph store is not directly implementing LDBP but being used to implement it.  There will need an additional layer to implement the requirements specific to LDBP like containers.
>
> One final comment - I see nowhere in the submission that precludes a single graph, which has all the resources and containers in it.  A graph store - multiple graphs, flat structure - is not necessary.  Do you want to constraint
>
>     Andy
>
> [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2012Jul/0004.html
>

Received on Wednesday, 19 September 2012 22:57:17 UTC