Re: RDFa generalization - expressing Microformats

Toby Inkster wrote:
>> prefix="http://microformats.org/vocab# http://vocabs-r-us.org/vocab#"
>>
>> The example above defines two documents that both contain unprefixed
>> reserved values. We wouldn't know which prefix to use in this case.
> 
> Well, yes, the disadvantage of my proposal is that there can only be  
> a single unprefixed vocabulary. However, that particular cloud has a  
> silver lining: it eliminates the prospect of collisions between  
> multiple vocabularies.

Hey Toby - great input :) - some thoughts:

Collisions between multiple vocabularies that express reserved words is
easy to deal with - the last reserved word expressed, wins.

In your example below:

>      <body prefix="http://microformats.org/vocab#">
>        <div typeof="hcard">
>          ...
>        </div>
>        <div typeof="hfoo" prefix="http://vocabs-r-us.org/vocab#">
>          ...
>        </div>
>      </body>

What happens if the author wants to use reserved words that don't clash
from both the Microformats vocabulary AND the Vocabs-R-Us vocabulary in
their markup? Should we force authors to choose when they can have both?

What about when the author wants one set of reserved words to shadow
another set of reserved words? For example, "I want to use Dublin Core's
'title', not Microformat's 'title'".

> Another advantage of mine is that I could choose to use, say Dublin  
> Core or FOAF as my unprefixed vocabulary, but if you wanted to do the  
> same under your proposed scheme, you'd have to wait for the DCMI  
> organisation or Dan Brickley to add a bunch of "xhv:reserved" triples  
> to their RDF schemas, which they may or may not be willing to do.

Not true, you could create your own vocabulary document and do this:

<span about="http://purl.org/dc/terms/title"
      rel="xhv:CURIE">title</span>

Which would produce the following triple:

<http://purl.org/dc/terms/title>
   xhv:CURIE
      "title" .

Which would allow you to do stuff like this:

<div about="#book">
   <span property="title">Watchmen</span>
</div>

which would produce the following triple:

<#book>
   <http://purl.org/dc/terms/title>
      "Watchmen" .

Easy as that... Gyerekjáték :)

> advantages :-
> 
>      * can still mix and match vocabs, but must give all but one of
>        them a CURIE prefix, or use prefix="" attributes scattered
>        throughout the DOM tree.

This is a limiting factor, since the other approach allows you to do the
same thing, but doesn't require you to give all but one of them a
prefix. The proposal on the wiki is less restrictive.

>      * does not require parsers to download external files
>          - saves bandwidth
>          - saves time
>          - allows off-line use
>          - simplifies parsers (they don't need to speak HTTP)

Yes, that is true and that's a big plus - however, then you're assuming
that the author wants every unprefixed word listed in
rel/rev/property/typeof to be mapped to that vocabulary. This is not a
safe assumption to make because it automatically voids all of the XHTML
reserved words. For example, what happens if somebody does this:

<body prefix="http://vocabs-r-us.org/vocab#">
   ...
   <a rel="license" href="mylicense.html">My license</span>
</body>

The vocabs-r-us.org vocabulary does not define any property for license,
however the triple you end up generating is this:

<> <http://vocabs-r-us.org/vocab#license> <mylicense.html> .

That's a problem because all of a sudden, you're overloading the meaning
of XHTML reserved word "license" when the author had no intention of
doing so.

I do admit that not requiring parsers to download external files is a
big win for your approach, but it is not without its side effects. I
don't think that these are side-effects that we want to introduce to
RDFa. Perhaps others have a different opinion on this assertion?

>      * avoids vocab collisions.

We can deal with this pretty easily - last reserved word loaded wins.

>      * can be used with existing RDF vocabs such as FOAF, Dublin
>        Core, SIOC, DOAP, etc without requiring their maintainers to
>        modify their schemas.

Vocabulary authors could create mappings separate of maintainers with
both approaches, as shown above. Maintainers wouldn't have to do
anything with either approach.

>      * can be used with non-dereferencable vocab URIs (e.g. URNs)

This violates the whole concept of "follow-your-nose" - you wouldn't
have any idea what the non-dereferencable vocabulary terms mean without
having to look it up in a search engine. Even if you do look it up in a
search engine, you can't be certain that the author who wrote the XHTML
page you are parsing used the vocabulary that is on the page that you
found on the web. This is a bad practice, unless I'm misinterpreting
what you mean by this statement.

I think the one real advantage with your approach is that there is no
loading of web-based resources required, which while desirable, has some
bad side-effects.

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.0 Website Launches
http://blog.digitalbazaar.com/2008/07/03/bitmunk-3-website-launches

Received on Wednesday, 3 September 2008 03:04:42 UTC