- From: Kjetil Kjernsmo <kjekje@ifi.uio.no>
- Date: Fri, 9 Dec 2011 13:42:26 +0100
- To: public-rdf-dawg-comments@w3.org
Fredag 09 desember 2011 10:51, skrev Gregg Reynolds: > But how would you know to do that? You've got your endpoint; I've got > mine. We can't require that all endpoints at a given host be > centrally administered. We're both free to name our graphs however we > like, whenever we like. Nothing says the three URI's in Sandro's > example must yield identical representations. They don't even have to > mean the same thing - meanings change, after all. Yes, meanings change, that's not the point. > > At the very least, if the WG persists on using this any reference to > > REST should be removed, as this is very clearly not RESTful. > > I don't see why not. Three different URIs, three (possibly) different > resources, no? > > This kind of thing is inevitable with any kind of hierarchical > namespace whose use is not centrally controlled. Nobody says that > /foo should have the same meaning on every server; why should embedded > IRIs be any different? In my opinion, what makes this non-RESTful (RESTless?) is that the Request-URI is different from the (embedded) graph URI. You're manipulating a different resource than you're identifying. Now, that wouldn't be a problem in practice if nobody ever saw the embedded URI. If that had always been the case, I really don't care what URI you're using, but in practice, I strongly suspect that's not going to be the case. So, there's a graph http://example.org/foo. We both make a copy of it and stuff it into our public endpoints with the same URI. Then, we use the Graph Store protocol to manipulate these graphs using indirect graph manipulation. Now, there are three different resources with the same URI. Eeeeevil! In this case, the http://example.com/rdf-graphs/service?graph=http://example.org/foo URI is irrelevant, even though, yes they could easily be made different and yes, then each of these URIs correctly identifies different graphs. But that only takes the attention away from the real issue: At different endpoints, http://example.org/foo identifies different graphs. I fear that this will cause very significant problems in the future for SPARQL federation, where agents try to get an idea of what is on different endpoints by exploring service descriptions, etc. They will not be able to rely on that two identical URIs identifying the same graph. Therefore, Request-URI should be the same as graph_uri. Also, I really don't see the problem of just giving the copied graph a new URI. If you in your app need to know the "embedded URI", you would know how to get it, either by violating the opacity of the URI or by having some statements saying where it came from. > Not really; it's the composite that > identifies the triples, not the embedded IRI alone. If that had been the case, it would help, but in practice, this will often not be the case, which is what makes it evil. Cheers, Kjetil -- Kjetil Kjernsmo PhD Research Fellow, University of Oslo, Norway Semantic Web / SPARQL Query Federation kjekje@ifi.uio.no http://www.kjetil.kjernsmo.net/
Received on Friday, 9 December 2011 12:42:52 UTC