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

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

From: Steve K Speicher <sspeiche@us.ibm.com>
Date: Mon, 17 Sep 2012 09:26:00 -0400
To: public-ldp-wg@w3.org
Message-ID: <OF4AA556EA.234BD7C2-ON85257A7C.0043B710-85257A7C.0049CE3C@us.ibm.com>
I have previously responded [1] to the request [2] for a review of "SPARQL 
1.1 Graph Store HTTP Protocol" [3] with member submission "Linked Data 
Basic Profile 1.0" [4].  Here is an update with some suggested steps to 
better the align the work of GSP with LDBP.


Background:
----------------
GSP, as its name implies, can be seen as a HTTP protocol definition on how 
to interact with a quad (graph) store.  The model, as seen as from HTTP 
clients, can be that HTTP resources are equal to a graph.  This is useful 
for HTTP clients that known they are working with graph stores.  LDBP 
looks to abstract away the server storage model and focus on the protocol 
for the lifecycle of HTTP resources and relationships (links and 
containers).  LDBP could be implemented with a graph store.


Summary Recommendation:
------------------------------------
It would be ideal if GSP was defined in the context of the LDBP and LDP 
work.  Due to its Last Call status, it may not be reasonable to be this 
work "on hold".  The reality is that many implementations of LDBP will be 
based on graph stores, so having a specification within this context will 
be useful.  The question is whether there needs to be 2 separate 
specifications: 1) HTTP access to graph store, independent of LDP  2) 
Mapping of LDP specs to graph stores (SPARQL Update).

I don't see the value in having 2 separate specifications.  I'd recommend 
leaving GSP as Last Call and have an open issue to align with LDP Last 
Call.


Details:
----------
*Compatible:*
- GET, HEAD, PUT

I don't see any big gaps in what is described here.  Some of the language 
doesn't clearly identify when a graph IRI aligns with the definition of an 
HTTP resource or information resource.  I think it could benefit from the 
attempt at this from the LDBP/LDP work.  For example, there is no real 
concept of resource creation.  So is PUT expected to allow for creation?

*Needing alignment:*
- Minimum formats (possibly)
GSP MUST support RDF/XML, Turtle or N-Triples if Accept header missing
LDBP MUST support Turtle (whether it really is needed when Accept is 
omitted)

- POST
This is where there is the biggest need for some alignment work. Take for 
example this text:
  "A request that uses the HTTP POST method and a request IRI that 
identifies RDF graph content MUST be understood as a request that the 
origin server perform an RDF merge..."
GSP: POST really means create graph or add/merge into existing graph.
LDBP: POST'ing to a BPR URI is not specified in LDBP.  POST'ing to a BPC 
is defined as creating a resource, server assigning the URI of that 
resource, responding with 201 + Location and adding this new resource to 
the membership of the BPC. 

The following statement could map that a "Graph Store" is a BPC:
  "If the request IRI identifies the underlying Graph Store, the origin 
server MUST create a new RDF graph comprised of the statements in the RDF 
payload and return a designated graph IRI associated with the new graph"
Client has full control over subject IRI naming and some control over 
graph naming.

What about "multipart/form-data"? LDBP doesn't touch on this, need to 
consider motivating use cases.

- PATCH
The POST in GSP (merge) seems to align better with PATCH semantics.

[1] - http://lists.w3.org/Archives/Public/public-ldp-wg/2012Jul/0012.html
[2] - http://lists.w3.org/Archives/Public/public-ldp-wg/2012Jul/0001.html
[3] - http://www.w3.org/TR/2012/WD-sparql11-http-rdf-update-20120501/
[4] - http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> 
http://open-services.net
Received on Monday, 17 September 2012 13:26:45 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 May 2013 13:44:23 UTC