Re: better support for bnodes

Oops...I left a bit of 'clipboard' data at the bottom of that previous
email! Please ignore it. :)

On 02/10/06, Mark Birbeck <mark.birbeck@x-port.net> wrote:
> 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
> correct.
>
> (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
> another!)
>
> Anyway...enough 'defence' of RDFa against RDF/XML...on to the real issue.
>
>
> WHAT TO DO IF WE HAVE A PREDICATE BUT NO OBJECT
>
> 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;
> Application</meta>
>     </div>
>   </div>
>
> 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
> @href.)
>
> 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
> want.
>
>
> WRINKLE 1
>
> 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;
> Application</meta>
>     </div>
>   </div>
>
> 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.
>
>
> WRINKLE 2
>
> 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;
> Application</meta>
>     </div>
>   </div>
>
> 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.
>
>
> SUMMARY
>
> 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
> (4.4.2):
>
>   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.
>
> Regards,
>
> Mark
>
>
>
> 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
> 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/
>
>
>
>
>
>   <div about="[_:DJDKWBDADIH05]" class="bibtex:Article">
>     <meta property="bibtex:title">Do you see what I mean?</meta>
>     <div rel="bibtex:author">
>       <div>
>         <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>
>     </div>
>     <div rel="bibtex:journal">
>       <span property="bibtex:name">IEEE Computer Graphics &amp;
> Application</span>
>     </div>
>   </div>
>


-- 
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 14:13:33 UTC