Re: Indirect Graph Identification

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