Re: Questions and comments on SPARQL 1.1 Graph Store HTTP Protocol draft

I'm not sure where to put this response (here or in the WG list), but my response is inline below is meant to clarify matters.
On Thursday, December 22, 2011 at 11:01 AM, Sandro Hawke wrote: 
> On Thu, 2011-12-22 at 09:41 -0500, Chime Ogbuji wrote:
> > ..snip..
> > The text above is referring to the request URI not a URI in the body of the request. The RDF payload doesn't necessarily need to include the target Request-URI in its content in order for the server to properly update an RDF graph managed by this protocol via PUT. For example:
> > ..snip..
> > > One convention we have adopted is to use the null relative URL (<> in 
> > > Turtle, or "" in RDF/XML). I'd like to know whether there is a standard 
> > > way of doing this. Maybe the spec should indicate one.This would require a base URI resolution mechanism that would (in the end) simply resolve this to the request-URI (per base URI resolution rules). The WG has decided to not support a base URI resolution mechanism for this specification. So, without a discovery mechanism the only way to perform this "append" behavior is to know the URI of the Graph Store before hand and to POST to it directly.So the suggested workaround is to POST to the graphstore to get a new
> URL allocated, then PUT your graph to that new address. And your
> understanding is that the technique Arnaud is suggesting -- defining the
> base URI as the URI that is allocated to hold the content -- could be
> standardized in the future?
I think (in general) base URI resolution for this protocol specification can be straight-forwardly standardized in the future once the question of resolution precedence is properly answered. See [1] and where that thread left off. 
> (I note that you said "POST", but only PUT works for this
> , unless you
> have out-of-band knowledge of how POST or PATCH will behave, since those
> behaviors are also not yet specified in a manner where they can be
> relied upon.)
I'm not sure what you mean here. In general, the scenarios break down as follows (for creating resources):

1) Direct PUT using the graph URI as request URI or via indirect identification

i.e., 

PUT /rdf-graphs/1 HTTP/1.1
Host: example.com
Content-Type: text/turtle
.. etc ..


or

PUT /graph-store?graph=http%3A//www.example.com/other/graph HTTP/1.1
Host: example.com
Content-Type: text/turtle
.. etc ..

2) POST using Graph Store URI as request URI

POST /graph-store HTTP/1.1
Host: example.com
Content-Type: text/turtle
.. etc ..

The first scenario requires either the client knows (beforehand) the graph URI to use for the new graph (i.e., http://example.com/rdf-graphs/1) or the URI of the Graph Store (http://example.com/graph-store). The second scenario requires the client knows the URI of the Graph Store before hand, but the Location header in the response gives the URI to the client for use in a subsequent (direct) PUT.

[1] http://lists.w3.org/Archives/Public/public-rdf-dawg/2010AprJun/0207.html

Received on Saturday, 24 December 2011 05:43:59 UTC