W3C home > Mailing lists > Public > www-rdf-comments@w3.org > January to March 2003

Re: name of rdf:nodeID attribute

From: Dave Beckett <dave.beckett@bristol.ac.uk>
Date: Tue, 14 Jan 2003 19:59:48 +0000
To: Garret Wilson <garret@globalmentor.com>
cc: www-rdf-comments@w3.org
Message-ID: <28458.1042574388@hoth.ilrt.bris.ac.uk>

>>>Garret Wilson said:
> Dave,
> Dave Beckett wrote:
> >>>>Garret Wilson said:
> >><rdf:Description>
> >>   <ex:editor rdf:nodeID="abc">
> >>     <ex:homePage rdf:resource="http://purl.org/net/dajobe/"/>
> >>   </ex:editor>
> >></rdf:Description>
> > 
> > Not quite, you broke the node element / property element striping
> > there so the innermost ex:homePage is a node element and doesn't take
> > rdf:resource, does take an rdf:about (see I said it was confusing!).
> Actually, it does take an rdf:resource, which is exactly my point. 

Er, no it doesn't.  Your example above, annotated:

Node <rdf:Description>
Prop   <ex:editor rdf:nodeID="abc">
Node     <ex:homePage rdf:resource="http://purl.org/net/dajobe/"/>
Prop   </ex:editor>
Node </rdf:Description>

and a NodeElement http://www.w3.org/TR/rdf-syntax-grammar/#nodeElement
does not allow an rdf:resource:
    attributes == set((idAttr | nodeIdAttr | aboutAttr )?, bagIdAttr?, propertyAttr*))

> Here's what this is meant to encode:
> <rdf:Description>
>    <ex:editor>
>      <rdf:Description rdf:nodeID="abc"
>        <ex:homePage rdf:resource="http://purl.org/net/dajobe/"/>
>      </rdf:Description>
>    </ex:editor>
> </rdf:Description>
> Here, rdf:nodeID is serving the same function as rdf:about. ...

Yes.  That is correct and it is a legal fragment.

> ... In the above 
> example, you noted that I can't put another property ex:homePage that 
> describes the resource represented by rdf:nodeID="abc". That's because 
> *that* occurrence of rdf:nodeID is talking about the node in the context 
> of the object of ex:editor, not as the subject of ex:homePage.

I was trying to say that:
   <ex:editor rdf:nodeID="abc" />

is legal; an empty property element form handled by
so the rdf:nodeID is the object.

Adding any element content to a property element is only allowed if no
object identifier (blank or URI) is given and only a single
nodeElement is contained.  This is the production:
It is expected that the contained nodeElement gives the identifier as
an attribute (rdf:about or rdf:nodeID)(.

Your 'meant to encode' version is correct and the right way to put
the URI at the object of one statement and the subject of another.

The rdf:resource (rdf:nodeID) on an empty property element is yet
another abbreviation form for writing it out longhand, and in this
case, you can't use it.

> As the object of ex:editor, the node ID should be represented by a 
> reference (e.g. rdf:nodeIDRef="abc") analogous to rdf:reference. As the 
> subject of ex:homePage it should be represented by rdf:nodeID analogous 
> to rdf:about. If rdf:nodeIDRef can talk about a node in the context of 
> both an object and a subject, then the first example above should be 
> allowed, to mean the same thing as the second example above.
> My point here is that rdf:about and rdf:reference are used in different 
> situations in the syntax depending on whether the resource identifies is 
> taking the role of subject or object of a triple. The same should go for 
> rdf:nodeID/rdf:nodeIDRef.

It is more that rdf:about is on node elements and rdf:resource is on
property elements.

> > rdf:nodeID is not in the graph at all.
> Right, but the node it represents is on the graph. That's what was meant.
> > You really can change any RDF/XML with rdf:about and/or rdf:resource
> > attributes to use rdf:nodeID and that is ok.
> So, why don't we deprecate rdf:resource and allow rdf:about wherever we 
> can have an rdf:resource? I really don't see the confusion for having 
> both, though.

I expect RDF/XML would be (even more?) totally unreadable if you
couldn't work out which element was a node element or property
element without the rdf:about / rdf:resource hints. You would have to
read the striping carefully.

Received on Tuesday, 14 January 2003 15:06:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:15:19 UTC