[uf-discuss] mixing vocabularies
lists at ben-ward.co.uk
Wed Jun 24 11:38:40 PDT 2009
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
> people can use rel-tag anyway on any element they want to? likewise
> 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
> i often found some top level div containing the recipe marked up with
> classes hRecipe and some other vocabulary e.g. <div
> 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
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.
> 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
> 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