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

On Thu, 2011-12-22 at 09:41 -0500, Chime Ogbuji wrote:
> Arnaud,
> 
> Thank you for your comments. See our response inline below
> > ..snip..
> > This problem is avoided when using PATCH.
> > 
> > It's interesting to note that relational technologies have no equivalent 
> > of PUT. Relational UPDATE is conceptually more like PATCH - it allows you 
> > to update only the predicates you can name, with the current value of the 
> > other predicates being preserved by the server.
> > 
> > Has there been any discussions about this?
> The relationship between relational UPDATE and PATCH has not been explicitly discussed, however, the difference between PUT and PATCH has been discussed and there is text in the WD discussing this (in the section regarding PATCH)
> > 2) Using PUT to create a new resource requires the client to know the URI 
> > of the resource. In our RDF applications, the client typically doesn't 
> > know and the URI is set by the server. For this reason we favor using POST 
> > to create resources but I wonder whether there was any discussion about 
> > this?
> 
> Note an implementation of this protocol that is also a SPARQL service can retrieve a service description that indicates the URIs of the graphs in the graph store that can be (in some cases) directly used for PUT requests. 
> > 3) For POST the draft specifies that "If the request URI identifies the 
> > underlying Graph Store, the origin server SHOULD create a new RDF graph 
> > comprised of the statements in the RDF payload and return a designated 
> > graph IRI associated with the new graph."
> > 
> > However, the draft is silent on how this IRI should be written in the 
> > "statements in the RDF payload" given that it isn't known by the client 
> > yet.
> 
> 
> 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:
> 
> PUT /rdf-graphs/service?graph=http%3A//www.example.com/other/graph HTTP/1.1
> Host: example.com
> Content-Type: text/turtle
> [] a  foaf:Person;
> foaf:name "Chimezie Ogbuji"
> 
> 
> Even without having http://www.example.com/other/graph in the set of turtle-encoded statements, the operation still performs as expected. If you were referring to knowledge of the Graph Store URI beforehand, there was some discussion about this, however the WG has decided to not specify a discovery mechanism specifically for this protocol. 
> > 
> > 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 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.)

    -- Sandro

> We'd appreciate if you could indicate whether this response adequately addresses your comment.
> 
> Chime Ogbuji
> 
> (On behalf of the SPARQL Working Group)
> 
> 
> 
>

Received on Thursday, 22 December 2011 16:01:22 UTC