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

On 10/19/2010 06:05 PM, Shane McCarron wrote:
> I have no preference.  However, can we please get a ruling on this (my
> chairman?) so I can update the spec?

+1 from me for the text below as well - so that's +3 so far (Toby,
Nathan, myself). Ivan said that he trusts Shane to make the proper edit
to the spec regarding this issue. Mark, please +1/-1 on the change
below, just for the record.

Shane, in an attempt to not make your life a living hell over the next
couple of days, feel free to add the text below to an unpublished
version of the spec (the Overview-src.html file would be fine) with the
assumption that we've found rough consensus on this issue.

Folks still have until 13:00 UTC on this coming Thursday to object to
the change below, at which point the RDFa WG will have to straw-poll to
see whether or not this text will stay in the document.

If anyone objects to this change, please offer the complete spec text
that would work for you, keeping in mind the spirit of what the text
below is attempting to accomplish.

> On 10/19/2010 3:45 PM, Nathan wrote:
>> Toby Inkster wrote:
>>> How about:
>>> """
>>> After processing, the following triples will be generated:
>>>   _:john foaf:mbox <> .
>>>   _:sue foaf:mbox <> .
>>>   _:john foaf:knows _:sue .
>>> The blank node identifiers ("_:john" and "_:sue") are arbitrary and
>>> implementations are not required to maintain the same identifiers as
>>> occur in the RDFa markup. The above data could have equivalently been
>>> represented as:
>>>   _:a foaf:mbox <> .
>>>   _:b foaf:mbox <> .
>>>   _:a foaf:knows _:b .
>>> For clarity, this document retains blank node identifiers in examples,
>>> but developers must not rely on RDFa implementations returning
>>> identifiers that are consistent with the RDFa markup.
>>> """
>> +1 from me - perfectly clear imho

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Saving Journalism - The PaySwarm Developer API

Received on Wednesday, 20 October 2010 00:09:13 UTC