Re: better support for bnodes

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?

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/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/

Received on Monday, 2 October 2006 18:22:54 UTC