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


are you opposed, or do you have any problem with the additional text I have proposed in

namely to _add_ to your text a further explanation 

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.

It is true that implementations do it essentially right but, well, they were written by RDF savy people. On the other hand, the fact that you opposed my request of changing the example (ie, that the generated bnode id-s would not necessarily be the same as the ones used in the HTML code) shows that you yourself feel there is a problem. Therefore, and with an eye for the much larger community we try to reach here and mainly with the users of the API, this issue must be made more clear.


On Oct 7, 2010, at 12:03 , Mark Birbeck wrote:

> Hi Manu,
> Sorry that I've only just noticed that you think the onus is on me here!
> It's not, though...
> In the discussion we had on the telecon I explained some of the
> wording that I'd added to RDFa 1.0 so as to make it very easy to
> implement bnodes. The gist of what I wrote in the spec is that
> developers should treat the underscore like an ordinary prefix mapping
> and give the prefix a URI that has been internally generated.
> The key point I made on the telecon was that when I was writing this
> part of the spec it was *very* difficult to get to the heart of bnodes
> and their relationship to RDFa in a simple manner.
> Yet by explaining bnode identifiers simply as resources that are
> generated using the CURIE mechanism, using a prefix mapping that is
> implementation-specific, I felt I was able to cut through a lot of
> potential confusion.
> Given that bnodes are renowned for being one of the most confusing
> things in RDF, and given that (as you say) we now have 18
> implementations that have never yet mentioned a problem with bnodes, I
> feel that I might have been on the right path with my
> 'sleight-of-hand'!
> Actually, to be more serious, this wasn't completely a
> sleight-of-hand; blank node *identifiers* (as opposed to blank nodes
> themselves) are not part of RDF as such, and different serialisations
> have adopted different conventions for naming blank nodes.
> So I felt that what I was doing was within the spirit of the notion of
> blank node identifiers both as described in the RDF/XML spec (i.e.,
> via the use of @nodeID) and more fundamentally, as discussed in the
> RDF Concepts and Abstract Syntax spec. (See especially the end of the
> section 3.2. [1])
> (For those not completely familiar with all of this, the function of a
> blank node identifier is to allow many local statements to be made
> about some resource, whilst preventing global statements from being
> made about the same resource. How this is achieved is not defined in
> RDF.)
> So although I wouldn't want to stand in the way of anyone trying to
> make this more precise, I'm having trouble seeing what it will be made
> more precise in relation to.
> Anyway, whatever the outcome of that, there is definitely no new
> wording to come from me because I'm happy with the old wording. :)
> Regards,
> Mark
> [1] <>
> On Sun, Oct 3, 2010 at 6:08 PM, 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?
>> 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

Ivan Herman, W3C Semantic Web Activity Lead
mobile: +31-641044153
PGP Key:

Received on Saturday, 9 October 2010 07:53:12 UTC