Re: telecon Thursday, 1600 UTC

Ivan,

First let me solve your example, then get back to the reason why this
makes sense.

> <http:://www.ivan-herman.net/Ivan_Herman>
>    foaf:holdsAccount
>       <http://www.facebook.com/p/Ivan_Herman/555188827>;
>    foaf:foaf:publications
>       <http://www.ivan-herman.net/professional/CV/publist.rdf>.
> 
> <http://www.facebook.com/p/Ivan_Herman/555188827>
>    rdf:type foaf:OnlineAccount;
>    foaf:accountServiceHomepage <http://www.facebook.com>
>    foaf:accountName "555188827".


This is actually a great example to show off Mark's chaining rules.

First, write your Facebook account information:

  <div about="http://www.facebook.com/p/Ivan_Herman/555188827"
       instanceof="foaf:OnlineAccount">
     a <a rel="foaf:accountServiceHomePage">facebook account</a>
     with name <span property="foaf:accountName">555188827</span>.
  </div>

Let's call that block <<ACCOUNT>>.

Now, let's go back to your first triples:

  <div about="http://www.ivan-herman.net/Ian_Herman">

     <div rel="foaf:holdsAccount">
        <<ACCOUNT>>
     </div>

     and some

     <a rel="foaf:publications" href="/professional/CV/publist.rdf">
        publications
     </a>
  </div>


Now, you can literally substitute the first block of HTML+RDFa for
<<ACCOUNT>>, and it all works out nicely. The @about completes the
hanging @rel, and you're done. The beauty of this approach is that you
can literally take whole blocks of HTML+RDFa and move them into the
"object" of a hanging @rel without modification.

Now, to get back to your earlier comment:

> - but... why? I mean: why is it necessary to introduce an extra rule?

It's partly the fault of microformats, and, actually, it's partly your
fault. Oh okay, and it's also partially mine. ;)

>From the microformats community, we have the following general approach:

  <div class="hCal">
    ...
  </div>

where you can declare a calendar event without naming it. We wanted the
same ease of use. To achieve it, we need to be able to declare a blank
calendar event without explicitly naming it. Thus

  <div instanceof="cal:Vevent">

has the same "feel" to it as

  <div class="hCal">

It declare a new "thing", even if you don't give it a name.

Then, there's also the use case you brought up: a bibtex entry with
multiple authors where one does not need to give the author a URI or
even a bnode ID. With the @instanceof construct creating a new bnode, we
get the following extremely pleasant approach:

  <div about="#paper">
    <span property="dc:title">RDFa Primer</span>

    <div rel="dc:creator">

       <span instanceof="foaf:Person"
             property="foaf:name">Ben Adida</span>

       <span instanceof="foaf:Person"
             property="foaf:name">Mark Birbeck</span>

       ... more authors ...

    </div>
  </div>

Now, we *could* force a new @rel="dc:creator" every time, but given the
beauty of the chaining rules, doesn't that seem like a missed
opportunity to have extremely clean markup?

There's a final argument that's more about how @instanceof feels to the
publisher. When I see two <div>'s, each with @instanceof, that implies
two instances to me. I think it would end up being counter-intuitive,
from an HTML publisher perspective, if the following:

  <div instanceof="foo:bar">
     ...
  </div>

  <div instanceof="foo:baz">
     ...
  </div>

somehow referred to the same item with two different types. If you
really wanted that, you would do:

  <div instanceof="foo:bar foo:baz">
    ...
  </div>


I won't claim that my search has been exhaustive, but I did spend a good
week trying to discredit Mark's chaining rules given the @instanceof
rules, and I didn't find any good counter-examples :) I think this
@instanceof approach combined with Mark's chaining rules form a strict
superset of other approaches in terms of expressive capability. Plus,
it's more pleasing to the eye, especially when you take all the history
out of the equation and take a fresh look at the above bibtex markup
example. Isn't it nice?

-Ben

Received on Sunday, 23 December 2007 17:47:59 UTC