Re: PROPOSAL to close ISSUE-37: is _ a special prefix? or a URI?

I think the very fact that we stumbled into this shows that, maybe, some tightening up of the document may be necessary.

First of all, I think that in the intro text, namely 3.10, we should make an explicit reference to 

http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-blank-nodes

when a blank node is mentioned. This is to make it clear that we speak of blank nodes and of nothing else.

I guess the text that has led to the discussion is in 8.1.1.4, saying:

[[[
A bnode is simply a unique identifier that is only available to the processor, not to any external software. By generating values internally, the processor is able to keep track of properties for _:a as being distinct from _:b. But by not exposing these values to any external software, it is possible to have complete control over the identifier, as well as preventing further statements being made about the item.
]]]

I think that adding to these Manu's text from below would make a lot of sense. Something like

[[[
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.
]]]

I remember that the discussion started by the examples in the document, e.g., 7.4.5, which says

[[[
Consider the following example:

<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 .
]]]

The text says "the following triples will be generated" which is wrong. At the minimum, the 'will' should be a 'may', but it is better if the generated triples explicitly do _not_ use the same blank node identifiers, ie, something like

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

with an extra comment that draws attention on the fact that different bnode identifiers may be used on output.

Ivan



On Oct 3, 2010, at 19:08 , Manu Sporny wrote:

> If there are no objections to this proposal in 14 days, we will close
> ISSUE-37: is _ a special prefix? or a URI?
> 
> http://www.w3.org/2010/02/rdfa/track/issues/37
> 
> The core of this issue revolves around how we explain the '_' prefix in
> RDFa Core. Proponents for adding language into the spec noted that it is
> important to further explain exactly what '_' is and the types of
> subjects that its usage generates. Namely, that identifiers such as
> "_:abc" cannot be used outside of a particular processing run or across
> graphs and that different implementations may choose to do different
> things with the blank node identifiers before granting access to the
> graph (via RDFa API) or re-serializing the graph. The argument of
> whether or not "_:abc" is a true URI or whether it is merely a mapping
> to RDF's "_" mechanism was discussed as well.
> 
> Alternatively, proponents for not adding language to the specification
> point out that we have over 18 RDFa processor implementations now and
> none of them have mentioned the lack of documentation on this particular
> aspect of the specification as being problematic.
> 
> This proposal asserts that proponents for adding language must produce
> the spec language in the next two weeks or this issue will be closed
> without a change to the RDFa Core specification. If spec language is
> produced, the RDFa WG will review the language and add it to RDFa Core
> if it is acceptable to the group, or reject the changes during a telecon
> straw-poll.
> 
> Mark is best positioned to author the spec changes to the RDFa Core
> specification since he is the one that suggested the change. If Mark
> does not submit a change proposal in the next 14 days, the issue will be
> closed without any change to the RDFa Core specification.
> 
> Please comment in 14 days from this post if you object to this proposal.
> If there are no objections within 14 days, ISSUE-37 will be closed.
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: WebID - Universal Login for the Web
> http://blog.digitalbazaar.com/2010/08/07/webid/2/
> 
> 


----
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