Re: Re 2: PROPOSAL to close ISSUE-37: Clarifying bnode explanation

This is all getting out of bounds, and we clearly have very different views on how a reader would read that document. But I guess we have to agree that we disagree on that point. I was perfectly happy with Toby's formulation, but let me propose a somewhat shortened version of yours:

[[[
After processing, the following triples will be generated:

_:john foaf:mbox <mailto:john@example.org> .
_:sue foaf:mbox <mailto:sue@example.org> .
_:john foaf:knows _:sue .


Note that processors use, internally, implementation-dependent identifications for bnodes. When triples are <em>retrieved</em>, new bnode indentifiers are used, which usually bear no relation to the original identifiers. However, implementations do ensure that these generated bnode identifiers are consistent: each bnode will have its own identifier, all references to a particular bnode will use the same identifier, and different bnodes will have different identifiers.
]]]

I have removed references to triple stores; this term does not even appear in the RDFa Core document!

Can we agree on this, and move on with our lives? :-)

Ivan



On Oct 20, 2010, at 06:44 , Mark Birbeck wrote:

> Hi Ivan,
> 
> I favour brevity too. :)
> 
> If we're going to add something it has to be clear, and with respect,
> neither your nor Toby's prose quite gets to the heart of the issue.
> 
> I'm not wedded to my prose, but if you look at its structure it only
> comprises three sentences, and it makes four points:
> 
> * bnode identifiers are converted to something
> implementation-dependent (i.e., they are *not* stored);
> 
> * as a consequence, when serialising out of a triple-store, new bnode
> identifiers will be generated;
> 
> * these new bnode identifiers should not be assumed to be the same as
> those that were in the original source;
> 
> * however, you can be sure that the bnode identifiers will be consistent.
> 
> Any wording that captures these four points -- without introducing
> further confusion! -- is fine by me.
> 
> Regards,
> 
> Mark
> 
> On Wed, Oct 20, 2010 at 7:35 AM, Ivan Herman <ivan@w3.org> wrote:
>> 
>> On Oct 19, 2010, at 17:57 , Mark Birbeck wrote:
>> 
>>> Hi Ivan,
>>> 
>>> I think that's definitely along the right lines, and if everyone is
>>> happy with it, I'm fine too.
>>> 
>>> However...since I can't resist the temptation to tinker, I offer the
>>> following additions, by:
>>> 
>>> * making the idea of bnode identifiers a little more explicit;
>>> * removing the reference to the RDFa API;
>>> * adding that a processor is also required to make references to the
>>> same bnode consistent.
>>> 
>>> 
>>> [[[
>>> After processing, the following triples will be generated:
>>> 
>>> _:john foaf:mbox <mailto:john@example.org> .
>>> _:sue foaf:mbox <mailto:sue@example.org> .
>>> _:john foaf:knows _:sue .
>>> 
>>> Note that when triples are stored in a triple-store the bnode
>>> identifiers (in this case _:john and _:sue) are converted to
>>> implementation-dependent values. The original bnode identifiers will
>>> usually not be stored, which means that when triples are /retrieved/
>>> from the store new bnode identifiers will need to be generated, and
>>> they could bear no relation to the original identifiers. However,
>>> implementations do ensure that these generated bnode identifiers are
>>> consistent: each bnode will have its own identifier, and all
>>> references to a particular bnode will use the same identifier.
>>> ]]]
>> 
>> This is going into too much details and intricacies for my taste (we are talking about an example, after all). I prefer either mine (sorry:-) or Toby's, with my final preference for the latter.
>> 
>> Ivan
>> 
>>> 
>>> Regards,
>>> 
>>> Mark
>>> 
>>> On Tue, Oct 19, 2010 at 7:45 PM, Ivan Herman <ivan@w3.org> wrote:
>>>> (Having some time in meeting breaks)
>>>> 
>>>> In
>>>> 
>>>> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0109.html
>>>> 
>>>> Nathan proposed an alternative, essentially making the issue more explicit. Taking his example, and Shane's earlier remark, a possible text might be:
>>>> 
>>>> [[[
>>>> 
>>>> After processing, the triples similar to the following will be generated:
>>>> 
>>>> _:john foaf:mbox <mailto:john@example.org> .
>>>> _:sue foaf:mbox <mailto:sue@example.org> .
>>>> _:john foaf:knows _:sue .
>>>> 
>>>> Note that when these triples are serialized, or accessed via an RDFa API, the identifiers "_:john" and "_:sue" may be exposed through some other, implementation dependent identifiers. The only feature that an implementation is required to keep is that the identifiers for the two blank nodes are different.
>>>> ]]]
>>>> 
>>>> Ivan
>>>> 
>>>> 
>>>> On Oct 19, 2010, at 14:59 , Mark Birbeck wrote:
>>>> 
>>>>> Hi Ivan,
>>>>> 
>>>>> Yes...sigh...deja vu...etc., etc.
>>>>> 
>>>>> I think the prose is actually fairly accurate. It says that two bnodes
>>>>> are created, and that those bnodes are referenced. We don't say
>>>>> anything here about what goes on inside a processor to generate those
>>>>> bnodes.
>>>>> 
>>>>> The problem we have is to try to explain what triples are generated
>>>>> from a particular piece of markup. All of our examples are talking
>>>>> about triples going *in* to a triple-store, and for that we need to
>>>>> ensure that the bnode identifiers are the same as in their
>>>>> corresponding examples -- otherwise it simply doesn't make sense.
>>>>> 
>>>>> However, when you serialise *out* of a triple-store, I agree with you
>>>>> that a different bnode identifier could be used.
>>>>> 
>>>>> But you can't help people understand this by suddenly changing an
>>>>> example halfway through so that it uses _:x instead of _:john...that
>>>>> breaks the example!
>>>>> 
>>>>> If you want to make it clear to people that the examples are showing
>>>>> serialisations on the way *in* to a triple-store then by all means
>>>>> propose some wording.
>>>>> 
>>>>> But that's very different to changing the examples.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Mark
>>>>> 
>>>>> 
>>>>> On Tue, Oct 19, 2010 at 5:26 PM, Ivan Herman <ivan@w3.org> wrote:
>>>>>> Sigh. I have a feeling of deja vu, and we seem to repeat the same arguments.
>>>>>> 
>>>>>> The document says:
>>>>>> 
>>>>>> [[[
>>>>>> <link about="_:john" rel="foaf:mbox" href="mailto:john@example.org" />
>>>>>> <link about="_:sue"  rel="foaf:mbox" href="mailto:sue@example.org" />
>>>>>> <link about="_:john" rel="foaf:knows" resource="_:sue" />
>>>>>> 
>>>>>> In the above fragment, two bnodes are explicitly created as the subject of triples. Those bnodes are then referenced to demonstrate the relationship between the parties. After processing, the following triples will be generated:
>>>>>> 
>>>>>> _:john foaf:mbox <mailto:john@example.org> .
>>>>>> _:sue foaf:mbox <mailto:sue@example.org> .
>>>>>> _:john foaf:knows _:sue .
>>>>>> ]]]
>>>>>> 
>>>>>> Ie, the text says "the following triples will be generated". This statement is purely and simply wrong. The generated triples are a serialized version of the triples and by saying 'will be generated' and using the same identifiers, a casual reader may deduce that the identifiers are the same as in the original RDFa source. It also suggests that
>>>>>> 
>>>>>> [[[
>>>>>> _:x foaf:mbox <mailto:john@example.org> .
>>>>>> _:y foaf:mbox <mailto:sue@example.org> .
>>>>>> _:x foaf:knows _:y .
>>>>>> ]]]
>>>>>> 
>>>>>> is wrong.
>>>>>> 
>>>>>> While this may not be very important for RDFa Core, because people do not necessarily care about the generated turtle or RDF/XML code which is usually brought into an RDF system, but if this perception is taken over to the RDFa API then we may have real problems.
>>>>>> 
>>>>>> I do not care about a slight inconsistency in the document if such false impression are given by the current document.
>>>>>> 
>>>>>> Ivan
>>>>>> 
>>>>>> 
>>>>>> On Oct 19, 2010, at 09:35 , Mark Birbeck wrote:
>>>>>> 
>>>>>>> Hi Ivan,
>>>>>>> 
>>>>>>> On Tue, Oct 19, 2010 at 11:41 AM, Ivan Herman <ivan@w3.org> wrote:
>>>>>>>> 
>>>>>>>> On Oct 19, 2010, at 08:00 , Mark Birbeck wrote:
>>>>>>>> 
>>>>>>>>> Hi Ivan,
>>>>>>>>> 
>>>>>>>>> But at the telecon we agreed not to change the examples.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> I have not seen minutes.
>>>>>>>>> Obviously I'll wait to see what this wording is, but based on previous
>>>>>>>>> discussions my argument was that the bnode identifiers in the prose
>>>>>>>>> and the serialisation needed to be consistent.
>>>>>>>> 
>>>>>>>> I am sorry, I strongly disagree with that. The current text is misleading for the casual reader of our spec (who will strongly rely on the examples) and giving a wrong impression via examples is a source of trouble. I do not see any consistency issue here, and even if there was, I would disagree with that argument.
>>>>>>>> 
>>>>>>>> _Something_ should be said in the examples that people should not rely on the bnode identifiers. I fully trust Shane to find the best editorial approach. But the current text is not acceptable in my view.
>>>>>>> 
>>>>>>> But what does it mean to "rely on bnode identifiers"?
>>>>>>> 
>>>>>>> How do you get a bnode identifier? How do you manipulate them?
>>>>>>> 
>>>>>>> It's like saying that JavaScript programmers shouldn't rely on
>>>>>>> variable names; yes of course you can tell the novice programmer that
>>>>>>> variable names can change without affecting functionality. But don't
>>>>>>> whatever you do create sample code where the variable name changes in
>>>>>>> the middle of an example.
>>>>>>> 
>>>>>>> The corollary for RDFa is that if we begin an example like this:
>>>>>>> 
>>>>>>> <div about="_:ivan" ...
>>>>>>> 
>>>>>>> then when we talk about the triples generated by that example we
>>>>>>> *must* use _:ivan in our explanations.
>>>>>>> 
>>>>>>> This says nothing about the triple-store, or the implementation
>>>>>>> specifics about bnodes, because we're just using bnode identifiers,
>>>>>>> and they are simply placeholders.
>>>>>>> 
>>>>>>> I've explained elsewhere on the list that if you don't retain
>>>>>>> consistency then it's like starting a JavaScript tutorial on addition
>>>>>>> like this:
>>>>>>> 
>>>>>>> var a = 10;
>>>>>>> 
>>>>>>> before going on to say that we can add 10 to this variable, like this:
>>>>>>> 
>>>>>>> b = b + 10;
>>>>>>> 
>>>>>>> Why did we change the name of the variable in mid-example? Apparently
>>>>>>> because we didn't want readers to have the false impression that all
>>>>>>> variables have to be called 'a'. :)
>>>>>>> 
>>>>>>> (Note that all of this is separate from our other discussion about
>>>>>>> what _:ivan generates internally in the graph.)
>>>>>>> 
>>>>>>> Regards,
>>>>>>> 
>>>>>>> Mark
>>>>>> 
>>>>>> 
>>>>>> ----
>>>>>> Ivan Herman, W3C Semantic Web Activity Lead
>>>>>> Home: http://www.w3.org/People/Ivan/
>>>>>> mobile: +31-641044153
>>>>>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>>>>>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> ----
>>>> Ivan Herman, W3C Semantic Web Activity Lead
>>>> Home: http://www.w3.org/People/Ivan/
>>>> mobile: +31-641044153
>>>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>>>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> 
>> ----
>> Ivan Herman, W3C Semantic Web Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>> FOAF: http://www.ivan-herman.net/foaf.rdf
>> 
>> 
>> 
>> 
>> 
>> 


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