Possible URI collisions with graph URIs

Dear all,

I've been concerned with the problems caused by the SPARQL 1.0 concept of what 
the graph URI identifies, something I find terribly confusing and if it is 
brought to SPARQL 1.1, I think that it will cause much confusion in the years 
to come. Rather than send yet another comment, I figured I'll rather post a 
question that may help to clearify things. 

The confusion is caused by the formulation in the last paragraph of section 
8.2.2 of the 1.0 query language spec:
 http://www.w3.org/TR/rdf-sparql-query/#namedGraphs
as I have previously commented. With 1.0, it wasn't hard to live with that 
confusion, is nothing specified what you should do if it was dereferenced. 
You could get around any conflicts by clever use of redirects or something. 
Now that the Graph Store HTTP Protocol does attempt to specify what to do, it 
changes the game somewhat.

To me, it seems to boil down to what URI collisions may occur. I would like to 
ask, for each of the below triples, given that http://example.org/graph 
identifies a graph and returns a 200 when dereferenced, which of these 
triples (prefixes omitted for brevity) would introduce a URI collision, and 
why or why not?

<http://example.org/graph> a foaf:PersonalProfileDocument .
<http://example.org/graph> a void:Dataset .
<http://example.org/graph> a owl:Ontology .
<http://example.org/graph> a cc:Work .

All of these are very common, and I sincerely hope that the answer is "none of 
them introduce a URI collision", but in that case, I hope someone can explain 
it in clear terms. :-) 

Finally, I also note that is commonly implemented that you can do
SELECT * FROM <file:///home/foo/data.ttl> WHERE { ?s ?p ?o }
In this case, you can say that file:///home/foo/data.ttl identifies a file 
without introducing a URI collision, or is this bad practice?

Best,

Kjetil
-- 
Kjetil Kjernsmo
PhD Research Fellow, University of Oslo, Norway
Semantic Web / SPARQL Query Federation
kjetil@kjernsmo.net           http://www.kjetil.kjernsmo.net/

Received on Thursday, 5 May 2011 11:58:05 UTC