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 19:22:37 +0100
Message-ID: <640dd5060610021122h170efc75hf175ccbb9c72408c@mail.gmail.com>
To: RDFa <public-rdf-in-xhtml-tf@w3.org>

Hi Ivan,

> > We've now got a bnode that isn't attached to anything, with a
> > predicate of bibtex:name.
> Hm. Is there? My understanding (but that may be wrong!) is that in your
> outlined solution above the blank node is created because no object has
> been assigned to bibtex:journal. If there is an object to it, then there
> is no reason to define a blank node; the meta would then be attached to
> the _:DJDKWBDADIH05 under the rules of finding a subject. Isn't that
> what would happen? (It is not necessarily much nicer, though, but those
> are the rules...)

No, the bnode is still created, by the rules that apply when 'meta'
and 'link' are used as children of an element that isn't another
'meta'. Of course, if the latter is the case then reification kicks
in, but without it, we're just creating properties on a bnode.

So the rule I'm proposing to add is simply that if there is no object,
the object should be the bnode identifier for the current
element...which rather conveniently makes it match up with the bnode
identifier created when we discover predicates defined by 'meta' and
'link' child elements. :) So we've achieved the 'chaining' that we
used to have in early drafts, and that you get in RDF/XML as a result
of the striping.

However, if you were to later add an @href, you would get the
'orphaned' bnode that I referred to, since although the bnode is still
there, nothing is referring to it. But as I said, you could argue that
this is 'correct'--you don't sound like you mind that consequence too
much, Ivan. Is that fair to say?



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
Received on Monday, 2 October 2006 18:22:54 UTC

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