- 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>
Jeremy, 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: http://www.example.org/mydoc.html#bnode(a) 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 <http://www.example.org/mydoc.html#bnode(b)> 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 issue.) 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. Regards, Mark [1] http://www.w3.org/TR/xptr-framework/ Mark Birbeck CEO 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 http://www.formsPlayer.com/
Received on Tuesday, 26 October 2004 11:09:29 UTC