- From: Steve K Speicher <sspeiche@us.ibm.com>
- Date: Mon, 17 Sep 2012 09:26:00 -0400
- To: public-ldp-wg@w3.org
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