W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > October 2004

RE: comments on nodeID in RDF/A

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Tue, 26 Oct 2004 11:33:35 +0100
To: "'Jeremy Carroll'" <jjc@hplb.hpl.hp.com>
Cc: "'public-rdf-in-xhtml task force''" <public-rdf-in-xhtml-tf@w3.org>
Message-ID: <003701c4bb47$42f437f0$6701a8c0@W100>


I'm being a bit dim here, and I have not explained the XPointer proposal
properly. You may find that it still doesn't 'work', but I should at least
clarify how it was intended to work.

> I agree that there is nothing illegal about using #node(a) as 
> a nodeID 
> representation, but it does prevent the serialization of 
> #node(a) as a 
> URIref, and leads to potential confusion.

The main thing is that the proposal was *not* supposed to generate URIrefs
like this:


I know that I endorsed this view when I said in my last mail:

> > However, looking at it again I can see that there is no way 
> > with this 
> > approach to prevent the following (i.e., someone making statements 
> > about your blank nodes):
> > 
> >   <link about="http://example.com/your-doc#bnode(b)" ... />

and must apologise, but I was a bit distracted when I saw your email, and
replied too hastily. As it happens I spent a lot of time working on this
'solution' because I am well aware of the points you make about the
distinction between a URIref and a blank node:

> There has been lots 
> of that on 
> this issue; people find it hard to recognise that blank nodes 
> and URIref 
> nodes really are different.

Anyway, the whole point of the XPointer proposal was that the bnode scheme
was actually 'traversed' or 'evaluated'. In other words, the GRDDLiser
should evaluate the bnode scheme to find a sub-resource (in XPointer
parlance), and so end up with a blank node identifier. The following is from
section 3 of the XPointer Framework spec [1]:

  An XPointer processor takes as input an XML resource and a string
  to be used as a pointer (for example, a fragment identifier, with
  escaping reversed, taken from the URI reference that was used to
  access the resource), attempts to evaluate the pointer with respect
  to the resource, and produces as output an identification of
  subresources, or one or more errors.

This means that the result of this:

  <link about="#bnode(a)" rel="foaf:knows" href="#bnode(b)" />

is *not* this:

  <http://www.example.org/mydoc.html#bnode(a)> foaf:knows

but is intended to be this:

  _:a foaf:knows _:b

The relevant section of RDF/A is at the end of 4.2.2:

  The bnode() Scheme Syntax is simply:

  [1]    BnodeSchemeData    ::=    (NCName) 

  An implementation of the bnode() scheme can return a [unique
  anonymous ID] in any valid format that meets the requirements
  of [RDF-CONCEPTS]. However, the same processor should always
  return the same value for the same input. In addition, it is
  not an error if the parameter does not refer to a value used
  in a nodeID attribute.

The idea would be that a GRDDLiser could create unique identifiers using any
technique it wanted to, but however it does it, it *must* do it, and keep
them consistent. (I'm no longer so sure about errors, but that's a separate

My reading of both XPointer and [RDF-CONCEPTS] is that this is legitimate.
>From the RDF point of view, we are not using a URIref, but the *result of
traversing a URI* (a sub-resource, which in our case is a blank node). And
from the point of view of XPointer you can do pretty much what you want with
schemes, as described in section 1 of the XPointer Framework spec [1]:

  This specification does not constrain the types of applications
  that utilize URI references to XML resources, nor does it constrain
  or dictate the behavior of those applications once they locate the
  desired information in those resources.

I hope that clarifies at least the intention, and I apologise for the red
herrings I've been throwing around.



[1] http://www.w3.org/TR/xptr-framework/

Mark Birbeck
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/

Download our XForms processor from
Received on Tuesday, 26 October 2004 11:09:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:18 UTC