SWAD-Europe Weblog

ADTF: pOWL

Categories Applications and Demos | RDF authoring | Standards and Specifications

ADTF: SWAP

Categories Applications and Demos | Document Retrieval | Standards and Specifications

Explaining new features in RDF: the nodeID attribute

This article provides an introduction to the rdf:nodeID attribute which was introduced into the revised RDF/XML syntax by the RDFCore working group. This explanation is intended for RDF and XML developers who have some reasonable familiarity with RDF's XML syntax, and who want to catch up with the new features added to RDF by the RDFCore group. It is not intended as a general introduction to RDF syntax.

Over the last 3 years, W3C's RDF Core working group has been busy modernising the core RDF specifications. In particular, RDFCore have fixed some problems with the original RDF Model and Syntax specification from 1999. One of the most noticable changes was the introduction into the revised RDF/XML syntax of a new attribute, rdf:nodeID, which is used for encoding descriptions of things without using URI strings to identify them. The intent here is to provide a bit more background on this new feature of RDF's XML syntax.

Categories Standards and Specifications

This article is based on a message written originally in an rdfweb-dev thread. The question was originally about the use of rdf:nodeID within people descriptions using the FOAF RDF vocabulary.

RDF has always contained an rdf:ID attribute, dating from the original RDF spec, first drafted in 1997 when XML itself was in flux, XML namespaces barely existed, and DTDs were state of the art. RDFCore added rdf:nodeID. To understand rdf:nodeID, we should talk a bit about the rdf:ID attribute.

One constraint we had on rdf:ID was that it acted like an XML ID attribute, even though formally we couldn't say it was one since RDF didn't require DTD processing. In particular, you can only have one attribute with any given rdf:ID value within your RDF/XML document. The idea was that these were used for linking to things from elsewhere in the Web. An RDF parser, given some document (that has a base URI) will generate full URIs for a node whose XML element is decorated with an rdf:ID, so for example:

<rdf:Description rdf:ID="me">
 <foaf:name>Dan Brickley</foaf:Name>
</rdf:Description>

...if parsed with a base URI of http://example.com/foaf/test1.rdf ...will generate a single triple:

http://example.com/foaf/test1.rdf http://xmlns.com/foaf/0.1/name "Dan Brickley"

Simple enough. So where did this rdf:nodeID thing come from?

Well the basic problem was that 'original RDF', ie. the thing begun in 1997 and made into a W3C RECommendation in Feb 1999, was a bit rough around the edges. A few things weren't clear, for example the notion of so-called "anonymous resources", which we now refer to as "blank nodes" (or bNodes) in the graph. These correspond to RDF descriptions of things where the thing (a person, document, company, whatever...) is _mentioned_ yet not _named_ by specifying a full (or even partial) URI. Aside: we stopped using the term "anonymous resource" in acknowledgment that the thing being described isn't intrinsically anonymous; it may well have a widely known URI, it is just that some RDF files can mention it 'in passing' without giving that URI (ie. rdf:about or rdf:resource might not be used).

So... if you have an RDF graph, and it mentions a bunch of things, and several of those things don't have URIs attributed to them in the graph, ie they are blank nodes in the graph, then you can get a problem. It isn't always possible to write down in '99-era RDF/XML the markup that represents (serializes) that data structure losslessly. You end up inventing URIs for things so you can fit them into the constraints of the RDF syntax.

For example, say you have three people. And assume the world is still squabbling away about angels on pinheads and whether people have URIs, so there is no concensus about whether people 'have' URIs. But you still want to describe them in RDF. So you make an RDF graph with bNodes for the people.

Let's label our 3 people 'a','b' and 'c', noting that these are private, local, transitory etc IDs we're using just so we can talk about them. They're not web-wide IDs that we expect to be widely known (such as URIs).

a worksFor b
a marriedTo c
b fatherOf c

This mini-web of relations can't be serialized in '99-era RDF/XML without inventing URIs for these 3 things, ie. the mere syntax of RDF used to force us to mess around with our data, and change (albeit only slightly) what the data was telling us.

<Person>
  <name>person a</name>
  <worksFor>
    <Person>
      <name>person b</name>
      <fatherOf>
         <Person>
           <name>person c</name>
         </Person>
       <fatherOf>
    </Person>
   </worksFor>
   <marriedTo ... -- what do we write here to link to person c! />
</Person>

So this is just the classic problem of mapping between two data structures, ie. directed labeled graphs (RDF) to trees (XML).

We need a way of crossreferencing the XML element that stands for a to the one that stands for c, and labelling that relationship with 'marriedTo'.

So first let me show you the way that RDF'99 would have us do it. Note the asymmetry: we do something different at each end of the link.

<Person>
  <name>person a</name>
  <worksFor>
    <Person>
      <name>person b</name>
      <fatherOf>
         <Person rdf:ID="c">
           <name>person c</name>
         </Person>
       <fatherOf>
    </Person>
   </worksFor>
   <marriedTo rdf:resource="#c"/>
</Person>

Hopefully you can see an analogy with the old style of HTML linking: the link goes 'from' the marriedTo element, 'to' the Person element. This is like an 'a href' pointer to an 'a name' anchor target in HTML.

Since rdf:ID expands to a full URI, and rdf:resource also expands relative URIs to full URIs, what we have here is just shorthand for this:

<Person>
  <name>person a</name>
  <worksFor>
    <Person>
      <name>person b</name>
      <fatherOf>
         <Person rdf:about="http://example.com/whateverthisdociscalled#c">
           <name>person c</name>
         </Person>
       <fatherOf>
    </Person>
   </worksFor>
   <marriedTo rdf:resource="http://example.com/whateverthisdociscalled#c"/>
</Person>

...and the RDF triples you get back from an RDF parser reflect this. The descriptions of 'a' and 'b' will generate blank nodes in the graph, ie. we get RDF which says, in effect,

"there is a thing and we don't know its URI but anyway that thing has a works for relationship to another thing that we don't know the URI for either but that thing has a fatherOf relationship to yet another thing which is named by the URI http://example.com/whateverthisdociscalled#c and the first thing has a marriedTo relationship to the thing whose URI is http://example.com/whateverthisdociscalled#c". (I've ommitted the 'foaf:name' properties here for brevity).

So, where does that leave us?

Well, firstly we have the problem of the RDF syntax forcing us to invent URIs just so we can use RDF's XML syntax. Worse, the URIs that get invented / assigned confuse the thing being identified with a (part of) an RDF description that happens to mention that thing. Person 'c' from the silly story about would probably be suprised to discover that the Web community were treating http://example.com/whateverthisdociscalled#c as if it were a well known identifier for him/her.

The RDF Core Working Group created rdf:nodeID as a cleanup for this situation, so that now almost all RDF graphs can be round-tripped through RDF parsers/APIs and back into RDF/XML syntax without that process having to make up silly URIs for things in this way.

<Person>
  <name>person a</name>
  <worksFor>
    <Person>
      <name>person b</name>
      <fatherOf>
         <Person rdf:nodeID="c">
           <name>person c</name>
         </Person>
       <fatherOf>
    </Person>
   </worksFor>
   <marriedTo rdf:nodeID="c"/>
</Person>

...is the new look version. It is symmetrical, since the HTML-derrived linking metaphor didn't really work in RDF. Neither XML element is really 'linking to' the other in the sense familiar from hypertext. It is more that they are about the same resource. But RDF's syntax already uses the attribute names 'about' and 'resource', so we made up another somewhat technical attribute name, 'nodeID', whose purposes is to take local-to-this-document identifiers for the things described by our XML elements. Unlike the rdf:about and rdf:resource design, we don't distinguish between the cases where the element stands for a node in the graph (ie. rdf:about) versus stands for an edge in the graph (ie. rdf:resource). This is another belated lesson: the original RDF syntax could have been much simpler, by just replacing both rdf:about and rdf:resource with a single attribute called 'rdf:URI' or somesuch.

But that's water under the bridge. RDF Core fixed the nodeID situation because it was affecting people's ability to write sensible RDF without having XML encoding artifacts interfere with what they were saying. We could have done a bunch more to beautify the syntax, but at cost of greater disruption.

Although rdf:nodeID is relatively new, it is being supported by more and more RDF parsers and serializers, and is relatively easy to add to an RDF toolkit. If you are using an RDF parser or serializer which doesn't support rdf:nodeID, let them know that it's time to upgrade, and perhaps ask here or on www-rdf-interest to see if someone might help with the necessary fixes.

Taking RDF and Topic Maps seriously

Paul Shabajee pointed me at this article, about the Australian Literature Gateway. Contains the following interesting quote:

"Although AustLit makes its data available in an XML format, this is a far cry from making it available in a standard, reusable format. The problem we face is that we are unsure of what standard to use. If RDF or DAML, which vocabulary? If Topic Maps, which serialisation format and which topic types and standard identifiers? If as plain XML, which schema? "

Categories Standards and Specifications | XML and RDF

Graham Klyne - my ESW activity so far

I've been doing some work as part of Rutherford Appleton Laboratory's contribution, looking toward exploring the use of Semantic Web technologies to model and manipulate trust in open systems, looking initially at authorization and access control issues.

Categories Standards and Specifications

So far, I've prepared:

• a security protocol surver document [1]


• a trust scenarios document [2]


• a simple experiment using non-specific RDF tools (cwm and my own report generation software) to generate network system configuration files from an access policy description in RDF. [3][4]

We're still talking about where it might go from here, but I have some ideas...

[1] http://www.ninebynine.org/SWAD-E/Security-formats.html

[2] http://www.ninebynine.org/SWAD-E/Trust-scenarios.html

[3] http://www.ninebynine.org/SWAD-E/Scenario-HomeNetwork/HomeNetworkConfig.html

[4] http://www.ninebynine.org/SWAD-E/Scenario-HomeNetwork/HomeNetworkAccessConfig.html