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

On 19/09/12 23:56, Ashok Malhotra wrote:
> Thanks, Andy, that very useful but your example
> http://server/graphstore?graph=http://example/snapshot556
> did not work for me.

In what way do you mean "did not work"?  It's just an example, of named 
graph <http://example/snapshot556> at graph store 
<http://server/graphstore>, not an operational system.

It is simply not possible to manage a typical graph store without some 
way to name a graph by full IRI so indirect naming is a MUST for GSP. 
The fact that this unfriendly format has to used is "unfortunate" (worse 
- it has to be %-encoded to be used).


> 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]

Received on Thursday, 20 September 2012 08:03:21 UTC