W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2009

Re: ACTION-56: RESTful HTTP protocol Updates

From: Kjetil Kjernsmo <Kjetil.Kjernsmo@computas.com>
Date: Thu, 16 Jul 2009 17:14:35 +0200
To: public-rdf-dawg@w3.org
Message-Id: <200907161714.35663.Kjetil.Kjernsmo@computas.com>
On Wednesday 15 July 2009 19:06:35 Seaborne, Andy wrote:
> 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.

Good point!

> 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.

Right.

> > 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. 

No, what I am trying to argue is that that's not a sufficiently precise 
distinction.

> 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.

OK, but I don't see how this relates to whether the graph URI is derived from 
the store URI.

> 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/>

So, what can happen here is that I own both the "myhost" and the "example" 
hosts, and I may decide to implement the protocol so that a 
PUT http://example/foo 
will, given that the code on example has credentials to do so, for example by 
using the client's credentials, simply replace the triples in 
http://myhost/store/ . It doesn't matter here if the graph URI derives from 
the store URI, what matters is if the server at the example host can and will 
manipulate the graph at http://myhost/store/ . Others may decide to support 
such a scenario even though the ownership of the hosts are different.

I'm sure people will use this protocol, and I think that is perfectly OK, to 
manipulate files in a file system, completely separate from a SPARQL server.

Now, the problem is, if I understand you correctly, that the triples in the 
graph named http://example/foo on the http://myhost/store/ SPARQL Endpoint 
may be different from the triples you get if you GET http://example/foo . 
This is of course more likely to happen if the graph URI doesn't derive from 
the endpoint URI, but the server administrator can set it up to serve 
different things anyway, so I don't see this as anything we can prevent, and 
I don't know if it is even worth trying.

I think it is going to be quite common for people who make a local copy of  
DBPedia to modify, to name their imported graph http://dbpedia.org even 
though that's then a different graph that should have a different name. 



> "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.

Yeah, this should certainly not be a required feature. I feel this use case is 
sufficiently well supported by the language by doing INSERT DATA INTO <> {}, 
so it would be a very low-priority time-permitting feature.

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

Yup, optional and time-permitting, though it doesn't take much time, I guess.


For the record, if I don't show up in the next meeting, I'm voting "required" 
on I, very low-priority time-permitting on II, time-permitting on III. I 
think the IBM proposal is compelling, but it seems a bit too large for this 
round, but the rest of the features could be looked into on a time-permitting 
basis. 


Kind regards 

Kjetil Kjernsmo
-- 
Senior Knowledge Engineer / SPARQL F&R Editor
Mobile: +47 986 48 234
Email: kjetil.kjernsmo@computas.com   
Web: http://www.computas.com/

|  SHARE YOUR KNOWLEDGE  |

Computas AS  PO Box 482, N-1327 Lysaker | Phone:+47 6783 1000 | Fax:+47 6783 
1001
Received on Thursday, 16 July 2009 15:15:41 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:39 GMT