W3C home > Mailing lists > Public > public-rdf-wg@w3.org > February 2013

Re: Problem with auto-generated fragment IDs for graph names

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Sat, 16 Feb 2013 15:53:50 -0500
Message-ID: <511FF1DE.6050907@openlinksw.com>
To: RDF WG <public-rdf-wg@w3.org>
On 2/16/13 11:39 AM, Pat Hayes wrote:
> On Feb 16, 2013, at 7:40 AM, Ivan Herman wrote:
>> On Feb 15, 2013, at 11:59 , Pat Hayes <phayes@ihmc.us> wrote:
>>> OK, I am impressed. I wasnt aware that SPARQL allowed variables in graph name position.
>>> But let me ask you about this example. You are assuming here that the _:doc1 in the triple in the default graph, and the _:doc1 used as a graph label, refer to the same thing, which is the moon-green-cheese graph, right? What is interesting here is that this assumption seems inevitable when we have a bnode involved, as here, but (the WG has decided) it cannot be assumed when an IRI is used. So this data:
>>> {ex:doc1 :author "Bob" }
>>> ex:doc1 {:TheMoon :madeOf :greenCheese }
>>> does *not* entail that Bob is the author of the graph (since 'ex:doc1' might denote something else, which is what the default graph would be about, and not about the graph.) So this actually gives us a new, Manu-independent, reason to allow bnodes as graph labels in datasets: they provide exactly the missing expressivity that is needed to have the default graph act as genuine metadata.
>>> Hmm, I am now feeling like we should re-think our decision here. David, Guus, are you following this? Do I hear a groaning noise yet?
>> First of all, I am not sure what 'our decision here' means in this case. I may infer that you want to re-think the 'can a bnode stand as a graph id' one
> Yes, that is what I meant. The recent one.
>> , but I may also infer that you want to come back on 'graph label ... cannot be assumed when an IRI is used to refer to the graph'. I would be opposed to open the latter, that would mean another 1-2 years of discussion.
> No, I take that to be closed. But my point is, the bnode case (if we allow it) provides a neat way to provide some currently missing expressivity, while not going back or re-opening that earlier decision. So it looks like a win/win.


This is a neat tweak, it doesn't break what exists. It closes incidental 
arguments such as the one that's arisen from threads with Manu.



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

Received on Saturday, 16 February 2013 20:54:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:25 UTC