- From: Kjetil Kjernsmo <Kjetil.Kjernsmo@computas.com>
- Date: Thu, 16 Jul 2009 17:14:35 +0200
- To: public-rdf-dawg@w3.org
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 UTC