Re: comments on nodeID in RDF/A

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. There has been lots of that on 
this issue; people find it hard to recognise that blank nodes and URIref 
nodes really are different. I think it would be fair to say that the 
first RDF WG did not fully appreciate this. The RDF Semantics doc makes 
this abundantly clear, but despite Pat Hayes' efforts that doc is for a 
fairly limited readership; clear syntactic markers are a better way of 
ensuring that the wider community appreciates that they are different, 
even if not the subtleties of the difference.

I have much sympathy with the "I'm all out of attribute names at the 
moment" point though ... I'll see if I cna understand what doesn't work 
with my proposal (using embedded elements). The syntax for this 
construct does not need to be easy, I doubt it will get much use; and if 
it proves more useful than I imagine, a shortcut could be provided in a 
XHTML 2.1. Partly will another attribute name be a greater or lesser 
cognitive load (on the user who does not want to think about this 
feature) than a variant on the syntax.

I suspect good editorial work could present the HTML 4 like aspects of 
the overall solution, and then the RDF motivated aspects as 'advanced 
features' in a way that the typical XHTML user only reads the first 
section: everything they do is RDF compatible, and if occasionally they 
copy/paste some code involving an advanced feature they may or may not 
choose to RTFM in order to understand it.

Jeremy


Mark Birbeck wrote:
> Hi Jeremy,
> 
> Thanks for your continued comments.
> 
> 
>>Friday I took an action to review RDF/A 
>>http://www.formsplayer.com/notes/rdf-a.html
>>11 October 2004
>>
>>to see whether it addresses the nodeID issue.
>>
>>It seems to, but I felt there were still a few rough edges.
>>
>>Two were:
>>
>>1)
>>
>>from section 5.2 the example
>>
>>[[
>><link nodeID="a" rel="foaf:mbox" 
>>href="mailto:daniel.brickley@bristol.ac.uk" />
>><link nodeID="b" rel="foaf:mbox" 
>>href="mailto:libby.miller@bristol.ac.uk" /> <link 
>>about="#bnode(a)" rel="foaf:knows" href="#bnode(b)" /> ]]
>>
>>the x-ppinter like notation #bnode(a) seems to confuse blank 
>>nodes and 
>>URIref nodes. I think it is significantly cleaner not to provide such 
>>syntax, but require, say:
>>
>>
>><link nodeID="a" rel="foaf:knows">
>>   <link nodeID="b"/>
>></link>
>>
>>which cannot be read as introducing URIref nodes.
> 
> 
> I looked first at doing what you describe, since that's effectively what
> RDF/XML does -- allow @nodeID in the position of either subject or object.
> However, your example won't work, because in the second line we cannot tell
> whether we have a subject or an object. You can get away with this in
> RDF/XML since there cannot be such a confusion, but in RDF/A we need to
> distinguish between them.
> 
> So, the alternatives that came to mind were:
> 
>  * have a different attribute for the object if the target is a bnode,
>    e.g.,
> 
>      <link nodeID="a" rel="foaf:knows" foo="b" />
>      <link nodeID="b" rel="foaf:knows" foo="a" />
> 
>  * modify the @href in some way to indicate that it is
>    actually a bnode that is being referred to.
> 
> I thought we had enough attributes already (!) so opted for the latter, and
> although there seemed to be a couple of ways that this could be done, the
> most likely to be accepted seemed to be to create an XPointer.
> 
> I of course agree with you that we have actually created a URIref, but I
> looked at this for quite a while and concluded that the definition of blank
> node identifiers in RDF-CONCEPTS allowed the graph representation syntax
> some leeway to decide what exactly a blank node identifier was. As far as I
> could see, as long as the processor (or GRDDLiser) knew to map these to
> something else, all would be well.
> 
> 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)" ... />
> 
> so it would seem the XPointer approach is flawed in that it breaks a
> fundamental aspect of blank nodes.
> 
> Thanks again for the extremely useful input and for spotting this; it would
> seem we need another attribute then (although I'm all out of attribute names
> at the moment). 
> 
> Regards,
> 
> Mark
> 
> 
> 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 08:26:49 UTC