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

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 21:48:59 UTC