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

Re: better support for bnodes

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Mon, 2 Oct 2006 13:52:49 +0100
Message-ID: <640dd5060610020552x6eeb8d33ma26664a25709bdeb@mail.gmail.com>
To: RDFa <public-rdf-in-xhtml-tf@w3.org>

Hi all,

Good work Ben, on the example.

On the call last week I asked how the bnode issue was addressed in
RDF/XML. It was a slightly rhetorical question (!) since my
recollection was that the syntax was no easier than that in RDFa. This
means that although Ivan's question is certainly important ("can we
make bnodes easier to deal with") before I look at it I want to point
out that the underlying assumption--that it is significantly more
difficult to do bnodes in RDFa than RDF/XML--is not completely

(It's certainly more 'difficult' in RDFa than in Turtle--that's true!
But that never was the issue.)

Just to recap on RDF/XML, there are a number of ways of creating
anonymous nodes without having to specify an identifier, but both
involve quite a lot of mark-up. The first is simply to use the RDF/XML
striping, and to alternative 'rdf:Description' elements with
predicates, so that the object of one statement is the subject of the
next. This can be slightly abbreviated by using the 'rdf:parseType'
attribute on the predicate, with a value of "resource".

As RDFa stands at the moment, you need to specify a name for the
'anonymous node'. In terms of 'extra markup' it's probably actually
slightly less than in RDF/XML, but the advantage that RDF/XML has is
the automatic generation of IDs via its striping. (In my very first
draft of one of the precursors to RDFa, I actually chained statements
together in a similair way to RDF/XML. This unfortunately prevented
certain other constructs from being possible, so gradually mutated
into a different syntax...what you gain on one side you lose on

Anyway...enough 'defence' of RDFa against RDF/XML...on to the real issue.


I'd say that one way to look at the problem is that we don't say
anything about what should happen if there is no @href, but there is a
predicate present. To illustrate, I'll mark up as far as is currently
possible in RDFa, Ben's example, in a way that I would suggest is
quite intuitive (I've only used a part of the Turtle, since the
collection of authors is another matter again):

  <div about="[_:DJDKWBDADIH05]" class="bibtex:Article">
    <meta property="bibtex:title">Do you see what I mean?</meta>
    <div rel="bibtex:journal">
      <meta property="bibtex:name">IEEE Computer Graphics &amp;

I don't think we can mark up the example any more simply than this,
and to me it 'feels' quite natural. But the odd thing is that although
it feels right, the second-level 'div' with only a @rel doesn't
actually mean anything in RDFa. This is because we don't say anything
about what to do if a @rel (or other predicate) is detected but an
@href isn't.

Just to recap on how we've defined the processing model, in section
4.2 in RDFa Syntax we say that processing starts when we see a
predicate (@rel in this example). We then go on to 'look for' a
subject and an object, based on various rules. The rules for the
subject are pretty clear, and they already take into account what
happens if no subject can be found. But although the rules for the
object are also clear, nothing is said about what happens if an object
attribute is missing.

(Note that if there is no object when the predicate is @property, the
obvious default for the object is a string literal of an empty string.
We also have a rule for a missing object if the predicate is @rev,
since the rules for @about will kick in. So we're really only talking
about the situation where we have an element with a @rel, but no

So, one way to improve the use of bnodes would be to make use of this
'missing object syntax', and say that if no object is specified then
the object is the 'current element'. In the example I gave above, this
amounts to a triple that uses the internally generated bnode
identifier on the second-level 'div' as its object, which is what we


Unfortunately, the first wrinkle with this is what to do if the author
at some later point adds an @href:

  <div about="[_:DJDKWBDADIH05]" class="bibtex:Article">
    <meta property="bibtex:title">Do you see what I mean?</meta>
    <div rel="bibtex:journal" href="[journal:IEEECGA]">
      <meta property="bibtex:name">IEEE Computer Graphics &amp;

We've now got a bnode that isn't attached to anything, with a
predicate of bibtex:name. It may be argued that this is not actually a
problem, since the author has now explicitly specified a new resource
for the bibtex:journal predicate, but the issue is the 'trailing'
anonymous node. I happen to think this is all ok, since it takes the
author at their word, but I'm flagging it up for discussion.


The second issue is that the group might feel uncomfortable with the
object of the statement being the automatically created @id of the
anonymous node, when using @rel. To put it another way, we have:

  @about @rel @id

to generate the statement, but @id is normally used as the subject. It
may feel a little more 'natural' to use @rev:

  <div about="[_:DJDKWBDADIH05]" class="bibtex:Article">
    <meta property="bibtex:title">Do you see what I mean?</meta>
    <div rev="bibtex:journal">
      <meta property="bibtex:name">IEEE Computer Graphics &amp;

But this then has the disadvantage that the subject is now @about,
which does not conform to the normal object resolution rules. Also,
the rule would still be overridden by the presence of an @href, since
this attribute already has clearly defined behaviour.

Having said that, I could go either way on this, since the
'unusualness' of @rev would draw attention to this construction.


Anyway, wrinkles and all, it seems to me that there is a solution in
here somewhere, fighting to get out. In summary, it would be something
like an addition of the following to the 'object resolution' section

  DELETE:There is no other way...

  ADD:If there is no 'href' attribute present, the URI to use for the
object is a
  [unique anonymous ID] generated to identify the [blank node] associated with
  the [context statement].

Not quite sure if this is right...but I hope that will get us going,
as a strawman for discussion.



On 01/10/06, Ben Adida <ben@mit.edu> wrote:
> I was tasked with sending a complete example of the bnode support issue,
> as described by Ivan Herman. The issue is: how can we make it easier to
> represent this in RDFa? Currently, we would have to name the bnodes
> uniquely, which somewhat defeats the purpose of the bnode in the first
> place.
> Here is the turtle example:
> :DJDKWBDADIH05 a bibtex:Article;
>     bibtex:title "Do you see what I mean?";
>     bibtex:author (
>           [
>             foaf:name "David J Duke".
>           ],
>           [
>             foaf:name "Ken W Brodlie".
>           ]
>           [
>             foaf:name "David J Duce".
>           ],
>           [
>             foaf:name "Ivan Herman".
>           ]
>     );
>     bibtex:journal [
>           bibtex:name "IEEE Computer Graphics &amp; Application"
>         ];
>     bibtex:volume "25";
>     bibtex:number "3";
>     bibtex:date [
>           bibtex:year "2005";
>           bibtex:month "3";
>     ]
>     bibtex:page [
>           bibtex:startPage "6";
>           bibtex:endPage "9".
>     ].
> -Ben

Mark Birbeck
x-port.net Ltd.

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

Download our XForms processor from

  <div about="[_:DJDKWBDADIH05]" class="bibtex:Article">
    <meta property="bibtex:title">Do you see what I mean?</meta>
    <div rel="bibtex:author">
        <meta property="foaf:name">David J Duke</meta>
        <meta property="foaf:name">Ken W Brodlie</meta>
        <meta property="foaf:name">David J Duce</meta>
        <meta property="foaf:name">Ivan Herman</meta>
    <div rel="bibtex:journal">
      <span property="bibtex:name">IEEE Computer Graphics &amp;
Received on Monday, 2 October 2006 12:53:36 UTC

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