[uf-discuss] mixing vocabularies

Ben Ward lists at ben-ward.co.uk
Wed Jun 24 11:38:40 PDT 2009

Hi Thomas,

On 24 Jun 2009, at 06:51, Thomas Loertsch wrote:

> a question: when contemplating over the feature set of hRecipe it  
> occured to
> me that i don't seem to get the rational of mixing vocabularies in  
> all it's
> subtleties. e.g. why should i add rel-tag to the hRecipe vocabulary  
> when
> people can use rel-tag anyway on any element they want to? likewise  
> for
> author and date.
> if i understand correctly the way meta information is added to the DOM
> defines which elements are described. when investigating the use of  
> hRecipe
> i often found some top level div containing the recipe marked up with
> classes hRecipe and some other vocabulary e.g. <div  
> id="yet_another_recipe"
> class="hrecipe vcard">. recipe specific elements where then marked  
> up with
> hrecipe vocabulary while the author was marked up as vcard. this  
> seems like
> a sensible approach to me. or does it make the job for parsers much  
> harder?

The following explanation could definitely be refined a bit, since I  
just made it up, but the way I tend to think of it goes something like  

I'd explain it is less in terms of “combining vocabularies”, and more  
in terms of combing *objects*. Using hCard for the `author` of a  
recipe is not importing the hCard vocabulary into hRecipe, it's that  
the `author` is a discrete hCard object within an hRecipe object. Each  
object uses a separate vocabulary.

This is perhaps better illustrated by hReview, since that shares the  
`fn` terms with hCard, and the way in which they do not conflict makes  
a clearer example:

hReview has an fn (formatted-name) property, and uses hCard for  
author. As such, a complete hReview structure will include two  
class='fn' elements, one for the name of the reviewed item and one for  
the name of the hCard. As such, in parsing, you are not consuming one  
combined hReview+hCard vocabulary, but instead two distinct objects,  
and hReview, of which the author property is an hCard.

That's why the class="vcard" is inside the hreview is combined to make  
class="author vcard", rather than higher up the DOM.

> but
> the fields marked as "experimental" get re-labeled as "supplemental".
> rational: they are considered useful and in common use for describing
> recipes but they are not specific to recipes and already part of well
> established vocabularies. therefor there use is encouraged and since  
> they
> are part of very popular vocabularies it's reasonable to expect that a
> decent microformats parser will recognize and handle them properly.  
> but they
> are not intended to get a part of hRecipe now or at a future time.

Within a freeform merging-vocabularies model this follows (although I  
think it's a level of complexity that runs counter to microformats  
starting simple), but within the object-esque model that microformats  
map to, it doesn't.

Reuse of other microformats (rel-tag, hcard, etc.) occurs when those  
existing microformats are the most appropriate way to mark-up a  
compound part of a microformat (recipes have authors, those are  
people, or perhaps credited to restaurants, thus hCard).

So it boils down to: Is there a case for tagging recipes? If yes, then  
each recipe tag will be a rel-tag structure. If not, then tagging  
should be left out of the spec.



More information about the microformats-discuss mailing list