PROPOSAL to close ISSUE-37: Clarifying bnode explanation

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.

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 This change addresses the issue and the issue should be

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

Received on Tuesday, 19 October 2010 01:34:50 UTC