W3C home > Mailing lists > Public > public-ldp-wg@w3.org > September 2012

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

From: Ashok Malhotra <ashok.malhotra@oracle.com>
Date: Thu, 20 Sep 2012 05:07:10 -0700
Message-ID: <505B06EE.4090003@oracle.com>
To: public-ldp-wg@w3.org
The link took me to an unpopulated website.
All the best, Ashok

On 9/20/2012 1:02 AM, Andy Seaborne wrote:
>
>
> 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).
>
>     Andy
>
>> 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 Thursday, 20 September 2012 12:07:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:31 UTC