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

On Sat, 2011-12-24 at 00:43 -0500, Chime Ogbuji wrote:
> 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. 

Sorry, I misread this bit of your response to Arnaud.    It was just
expanding on the answer ("no"), but I thought it was proposing a
workaround to the problem Arnaud was raising, naming how you add a
resource which needs to refer to itself.  I thought you were saying you
could add a resource, then PUT (or PATCH, or in some cases POST) the
self-referring content, once you have the new URL assigned.   There's no
defined way to do it in one step, yet, but given the defined methods one
can do it in two steps.

    -- Sandro

> 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 13:27:56 UTC