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

Hi Nathan,

On Tue, Oct 19, 2010 at 11:11 AM, Nathan <nathan@webr3.org> wrote:
> Perhaps effective wording in the Core (as proposed) and a dual example in
> the primer which visually shows how bnode identifiers can't be relied on
> would ensure clarity?

See other email about what it means to 'rely' on a bnde identifier.

Also, I'm starting to suspect that there is a big confusion here, so
forgive me if I go back to first principles.

Let's say we have the following bnode identifier:

  _:nathan

Let's also say that some processor internally represents this by the URI:

  <bnode:nathan>

Now, let's say that I'm writing some sample markup for some specification:

  <div about="_:nathan"
    property="foaf:name">Nathan</div>

and so in order to explain this markup, I state that the following
triples are generated:

  <bnode:nathan> foaf:name "Nathan" .

If I did this, you and Ivan would be quite right to jump up and down
and say that it's wrong, because (a) we're mandating some particular
format for the internal representation of bnodes, and (b) even if we
agree on 'bnode' at the front, the suffix can still be anything.

In other words, even within the frame of reference of this processor,
the generated *internal* format for the triples can be any of the
following (and many more):

  <bnode:n1233467> foaf:name "Nathan" .
  <bnode:ivan> foaf:name "Nathan" .

So yes, we would be wise to draw attention to this in our examples.

However, this is *not* what is happening in the RDFa spec.

In the RDFa spec our examples stay at the level of bnode identifiers,
and therefore it is not only right but *required* that when we use
this example:

  <div about="_:nathan"
    property="foaf:name">Nathan</div>

we say that it generates this:

  _:nathan foaf:name "Nathan" .

As I've said before we haven't said anything about the implementation
of bnodes or their *internal* representation. All we've done is
consistently use bnode identifiers across our examples.

Regards,

Mark

Received on Tuesday, 19 October 2010 11:52:29 UTC