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

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.

Ivan


> 
> Regards,
> 
> Mark
> 
> 
> On Tue, Oct 19, 2010 at 9:53 AM, Ivan Herman <ivan@w3.org> wrote:
>> The proposed resolution (which I agree with...) is not complete. I have also proposed to change the wording of at least one of the examples making use of bnodes. I believe Shane has the right formulation for it.
>> 
>> Ivan
>> 
>> On Oct 18, 2010, at 23:34 , Manu Sporny wrote:
>> 
>>> If there are no objections to this proposal by this Thursday, October
>>> 21st at 13:00 UTC, we will close ISSUE-37: Clarifying bnode explanation.
>>> 
>>> http://www.w3.org/2010/02/rdfa/track/issues/37
>>> 
>>> After a bit of back and forth between Ivan and Mark, it became clear
>>> that Ivan would be happy with something to this effect being added to
>>> the RDFa Core document:
>>> 
>>> [[[
>>> Beyond keeping track of the differences, the processor may choose any
>>> internal representation of, for example, _:a and _:b. These
>>> representations are not required to be identical on two different runs
>>> of the processor on the same RDFa source. Processors are also not
>>> required to keep the original names when granting access to the RDF
>>> graph. The only requirement is that <em>different</em> blank nodes in
>>> the original source should be mapped onto <em>different</em> blank
>>> nodes, and <em>identical</em> blank nodes should be mapped on
>>> <em>identical</em> blank nodes when answering an API request or when
>>> serializing the graph.
>>> ]]]
>>> 
>>> Discussion with Mark revealed that he would be fine with this addition
>>> as well. The core of Ivan's concern was that we don't highlight the
>>> possible issues with using bnodes in the specification text. The
>>> paragraph above attempts to highlight the issues.
>>> 
>>> This proposal asserts that the paragraph above, or one roughly
>>> equivalent to it, be inserted into the RDFa Core specification around
>>> section 8.1.1.4. This change addresses the issue and the issue should be
>>> closed.
>>> 
>>> Please comment before Thursday, October 21st at 13:00 UTC if you object
>>> to this proposal. If there are no objections by that time, this issue
>>> will be closed. If there are objections, the RDFa Working Group will
>>> perform a straw-poll and decide whether or not to close the issue before
>>> entering Last Call.
>>> 
>>> -- manu
>>> 
>>> --
>>> Manu Sporny (skype: msporny, twitter: manusporny)
>>> President/CEO - Digital Bazaar, Inc.
>>> blog: Saving Journalism - The PaySwarm Developer API
>>> http://digitalbazaar.com/2010/09/12/payswarm-api/
>>> 
>> 
>> 
>> ----
>> 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