RE: ACTION-56: RESTful HTTP protocol Updates



> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
> request@w3.org] On Behalf Of Kjetil Kjernsmo
> Sent: 15 July 2009 11:06
> To: public-rdf-dawg@w3.org
> Subject: ACTION-56: RESTful HTTP protocol Updates
> 
> 
> All,
> 
> 
> I took an action to summarize the options that are on the table for
> RESTful HTTP protocol updates,
> http://www.w3.org/2009/sparql/track/actions/56

> and this email is in response to that action.
> 
> I have found it convenient to divide into four options, and I propose to a
> strawman poll on each, whether you think it should be
> required, time-permitting, don't care or don't want.

Overall: let's be clearer where we are just using existing web mechanisms (PUT {graph-uri}) as is and where there is SPARQL-specific update protocol going on.

> These are the four options:
> 
> I. Simple HTTP verbs only
> 
> I believe this is the simplest case, just the familiar HTTP verbs to
> manipulate graphs where you are priviliged to act on the graph name URI.
> In this proposal, we can take the following as a starting point, taking
> {graph-uri} as a meta-syntactic variable denoting the URI of the graph.
> 
> POST {graph-uri}
> will insert the triples in the message into the {graph-uri} if it does not
> exist, if it exists it will add the triples of the message to the graph
> 
> PUT {graph-uri}
> will insert the triples in the message into the {graph-uri} if it does not
> exist, and replace the graph if it does.
> 
> DELETE {graph-uri}
> will drop the graph identified by the {graph-uri}.
> 
> GET {graph-uri}
> will return all triples of the graph.
> 

For PUT/DELETE/GET, these are just the normal meanings applied to web resources so we should be clear we are merely documenting normal usage.

For POST, it is a specific meaning as POST is used for all sorts or things.

"required" for POST {graph-uri} being an accumulation of the triples.

> II. Add a graph parameter
> 
> I tried to draw the line on when this is needed in
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/0059.html

> The short story is that when the client can't be authorized to manipulate
> the {graph-uri}, one should be able to provide it to the endpoint to be
> able to manipulate the graph using the HTTP verbs above anyway.
> This can be done by encoding it in the Request-URI or a header.

Having been back over the email trail, I not sure I understand this formulation properly - I see it as a graph store having a named graph which does not derive from the store URI.  So the graph in the store is a copy of the graph at {graph-uri} because there may well be a graph at {graph-uri} in the usual way.  The test is that 
if you change the store one, the other will not change, and vice versa.

Use cases:
   store graph under URI <http://example/foo> in graph store <http://myhost/store/>
   upload this local data under URI <http://example/foo> in graph store <http://myhost/store/>

"time-permitting"

Because I think we need to engage in a wider discussion than just the WG e.g. use of "Graph:" so time is an important factor.

> 
> III. Deal with round-trip concurrency issues
> 
> The IBM proposal, below, raises the question and proposes a solution to
> the problem that a client may GET a graph, and then another client
> modifies the content of the graph before first client has the chance to
> PUT or POST modified content back to the graph, possibly creating a mess.
> We should decide if this a problem we want to address.

This is HTTP 1.1 usage of "ETag:"/"If-Match:".  The issue I see is whether they are mandated by this WG or not where the operations are the SPARQL update protocol (e.g. case II). 

I don't want to mandate their use because it's not going to mandated elsewhere.  

Documenting the use of ETags as a concurrency mechanism as a jolly good idea would be best.

> 
> IV. Adopt the IBM proposal as starting point.
> 
> The IBM proposal,
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/att-

> 0040/SPARQL-UProtocol-20090707.html
> addresses all of the above, although it is not very clear about II. It
> also introduces a HTTP PATCH verb (which is in HTTP 1.0, not 1.1) and a
> Graph HTTP header to allow more flexible naming of graphs.
> Thus, the fourth option is to adopt the IBM proposal as it is as a
> starting point for the WG.

I don’t want to get into the PATCH issues and I think we need to more widely consult when considering a Graph HTTP header (it's not a purely SPARQL issue). There is an issue around how easily client-side frameworks make it to modify the HTTP header (you can't from an HTML form, for example, as far as I know).  It's not all curl and wget.
 
But having a strawman as starting point and an issues list against that strawman is good way to go.

+1: adopt.

> 
> Best Regards,
> 
> Kjetil

 Andy

Received on Wednesday, 15 July 2009 17:08:24 UTC