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

On Feb 16, 2013, at 11:39 , Pat Hayes <phayes@ihmc.us> 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.

Ok, thanks for the clarification.

> 
>> , 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.
> 
>> 
>> As for the former: I must admit I do not really follow your reasoning. The way I see is that SPARQL does not define/say more about the referral in the case of blank nodes as for IRI-s, ie, there is no difference. The 
>> 
>> {IRI-OR-BNODE :author "Bob" }
>> IRI-OR-BNODE {:TheMoon :madeOf :greenCheese }
>> 
>> pattern meaning also referral seems to be more of a social convention to me rather than anything else; I do not believe SPARQL makes any statement whatsoever for this. What am I missing?
> 
> I do not mean to refer to SPARQL here. My point is purely semantic. The old decision about IRI graph labels means that this pattern with an IRI **cannot** be presumed to be saying that Bob is the author of the graph. Maybe that is what the writer had in mind, but its not semantically justified, and in fact it is actually called out in the spec as not semantically justified: so if you read this pattern somewhere, you have no semantic justification for believing that the first use of that IRI does in fact refer to the graph labelled by the second use.

Agreed. That is what I meant when I said that this is a 'social convention', which is probably not the right term, actually. One could rather say that this is a convention for a (specific class of) applications. And you are right that this is not a SPARQL issue, my bad.

> That is the consequence of our failure to provide a semantics for graph label IRIs in datasets. The source of that failure was the perceived need, by some members of the WG, to permit IRIs which denote things other than graphs to be used as graph labels.

Isn't it the backward compatibility with SPARQL that put us into this situation? Ie, that SPARQL does not make any kind of statement on referral?

> But, my point is, none of this - neither the original motivation nor the decision - apply to bnodes used as graph labels. So if we allow bnodes to be used as graph labels in a dataset, then we have the possibility to give them the 'missing' but obvious semantics which requires them to denote the graph they label. (What other meaning could that use possibly have?) 
> 
>> 
>> I must say that *if* there is a major semantic difference at this point between a bnode label and a IRI label, that may actually be an argument *not* to reopen this issue either; it would create an inconsistency that nobody would understand, let alone explain to third parties...
> 
> I think we already have this problem, in explaining to people why it is that a graph "label" might not denote the graph it labels. The fact that you and Eric and Manu all seem to be unaware of the consequences of this illustrates the problem rather acutely.

I am sorry Pat, but I do understand the consequences.

What I was uneasy with, and I am still uneasy with, is that we would provide a different semantics for bNodes than for IRI-s. My understanding on what you propose is: a bnode usually means "There is an IRI such that bla bla bla". However, in this case we would have to say "There is an IRI such that bla bla bla AND that the IRI refers to the graph". Would't be the only place where we would attach an extra requirement on the "There is an IRI such that..."? I see that as a kind of inconsistency which seriously bothers me. 

(Let alone the fact that most in the community look at bnodes as a convenient way of defining some sort of an anonymous URI for a resource and they do not look at the existential nature of things. That may lead to further mess.)

To be clear: I am not very happy with the non-referral nature of graph labels, personally, and with my W3C position's hat put down. But, as you say, that is water under the bridge. Having this extra bnode semantics would really look like a kludge to me.

Sorry...:-)

Ivan


> At least, with the bnode case available, we could tell people that using bnode labels does carry the obvious intuitive meaning into the normative semantics, and its a very easy rule to follow even if you don't quite understand why it doesn't work in the IRI case. (The fact is, there is no rational reason for that decision, IMO, but that is water under the bridge now.)
> 
> Pat
> 
>> 
>> Ivan
>> 
>> 
>> ----
>> Ivan Herman, W3C Semantic Web Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> FOAF: http://www.ivan-herman.net/foaf.rdf
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973   
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
> 
> 
> 
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Sunday, 17 February 2013 00:07:32 UTC