Re: Possible URI collisions with graph URIs

On 5 May 2011 21:57, Kjetil Kjernsmo <> wrote:
> 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:
> 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
> 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?
> <> a foaf:PersonalProfileDocument .
> <> a void:Dataset .
> <> a owl:Ontology .
> <> 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?

If you want to store information about the file, independent of the
triples in the file, you could do it in a separate graph that is
dedicated to this purpose. A URI collision is then only important if
the triples in the file are inconsistent because your added statements
are not colocated.



Received on Thursday, 5 May 2011 21:22:37 UTC