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

On Oct 9, 2010, at 11:18 , Mark Birbeck wrote:

> Hi Ivan,
> 
> I don't see the need for the extra text, but I also don't have a
> problem with adding what you have proposed.
> 

Ok. I believe it is necessary to add it.

> I was only trying to flag up that Manu had the action item on me, and
> I was saying I didn't think it was on me.
> 
> However, I think changing the examples is a very different thing.
> 
> Since the examples only deal with bnode identifiers and *not* the
> internal representation of bnode identifiers, then I think we must be
> internally consistent with the use of the identifiers otherwise the
> examples don't make sense.
> 
> In other words, I think it would be wrong to say that this:
> 
>  <div about="_:a" rel="b" resource="c" />
> 
> generates this:
> 
>  _:x <b> <c> .
> 
> because regardless of how those identifiers are implemented, the rules
> of bnode identifiers say that these identify two different bnodes.
> 
> Equally, to say that this:
> 
>  <div about="_:a" rel="b" resource="c" />
> 
> generates this:
> 
>  _:a <b> <c> .
> 
> is not to say anything prescriptive about the internal representation
> of bnode identifiers, but it is internally consistent as an example.
> 

As I said in 

http://www.w3.org/mid/09E96070-4E1B-441F-A4F2-0ECE304C31C7@w3.org

our current text says. 

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

First of all, this is _wrong_, plainly and simply. And all our examples reuse the same blank nodes in the output as in the input. Mainly if people begin to use the API, where these things really count, they might expect to get to the same blank node id-s. You are right that this is not what we say, but this is what we suggest. And that is, didactically, wrong. Shane suggested to say 'Triples similar to the following will be generated:' and use _:X for _:john and _:y for _:sue. I think that is the minimum we should do.

>  But when showing examples and the triples that correspond to
> them I think we need to retain consistency, and not mix in the
> serialisation question.

We show examples of serialized graphs (obviously), so there is no way to avoid that. I do not see any issue of consistency here; if people use blank nodes then, well, they use blank nodes! Difficult the blank node concept may be, you cannot just hide it and the fact that, at the end of the day, you may get different ids if you get them via an API or when you read the generated RDF/XML or Turtle is just the way it is.

I maintain that what is in the current text is simply wrong and misleading to the reader. This should not go out that way...

Ivan


> 
> Regards,
> 
> Mark
> 
> On Sat, Oct 9, 2010 at 8:52 AM, Ivan Herman <ivan@w3.org> wrote:
>> Mark,
>> 
>> are you opposed, or do you have any problem with the additional text I have proposed in
>> 
>> http://www.w3.org/mid/09E96070-4E1B-441F-A4F2-0ECE304C31C7@w3.org
>> 
>> 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.
>> 
>> Ivan
>> 
>> 
>> 
>> 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] <http://www.w3.org/TR/rdf-concepts/#section-URI-Vocabulary>
>>> 
>>> 
>>> On Sun, Oct 3, 2010 at 6:08 PM, Manu Sporny <msporny@digitalbazaar.com> 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
>> 
>> 
>> 
>> 
>> 
>> 


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