[uf-discuss] mixing vocabularies

[Thomas Loertsch]

hi all,

thanks for the nice discussion!

On 25.06.09 11:15, "Ben Ward" <lists at ben-ward.co.uk> wrote:

>> However, they might have gotten the idea that it's ok to do this,
>> because the two microformats share the fn property. So they could
>> have thought, why repeat it twice?
> 
> I don't agree, although we should acknowledge here that we're both
> second guessing another developer's intent. I don't think the scenario
> you describe is a concern, and we've never had any prior suggestion of
> it occurring. 

really? i would have done this without hesitation if my data had suggested
it.

>> I would suggest a page that describes precise what combinations of
>> microformats are allowed, e.g. that an adr inside hcard is ok, but a
>> recipe inside an hresume is not.
> 
> I might not be following you quite right here, I keep interpreting
> this sentence in opposite ways each time I read it. I'm going to
> answer both interpretations for completeness:
> 
> 1. I don't think there is any concept of 'allowed' vs. 'not'. There's
> obviously no specified relationship between Resumé and Recipe (at this
> timeŠ cue every unemployed chef on the world wide web joining µf-
> discussŠ ha), but that doesn't mean a piece of content within that
> resume document couldn't be a recipe. A chef could include their
> favourite salad dressing recipe in their resumé as part of the
> description of some work experience. The example doesn't matter: There
> shouldn't be no restriction on describing one piece of structured
> data, independently of another, based on what the outer-most structure
> is.
> 
> In terms of µf that have explicit function within another microformat,
> that is already documented as part of the specs. ADR is part of hCard,
> hAtom specifies authors must be hCard, hReview specifies that
> class="item vevent" means you're reviewing an event. And so on. Any
> unspecified combination should be treated as two discrete objects.
> 
> 2. On the flip side, if you mean that we should provide fuller
> specifications of what microformats do mean in combination, that's a
> different issue, but one that again there's limited demand for.
> Combinations (say, using hCal inside of hResume for experience) get
> worked out in response to use cases, either in the initial development
> of a spec or later, either way not pre-emptively. Using hCalendar for
> life-spans (in place of an hCard date-of-death field), was an example
> that came up a few years ago.
>
> People experiment with combinations in their own pages where it makes
> sense to them; no different to publishing with any other HTML element.
> Those experiments may influence brainstorming for specifying new
> patterns.
> 
> Like all new uses of microformats, ideas about uses of combined
> microformats should be documented on each microformat's *-
> brainstorming page.

i understand this as an attempt to let not get microformats too complicated.
to paraphrase you: "if there's a strong enough usecase add the element to
the microformat. otherwise there's no need for a rule either".
but in your response #1 you say that no combinations are forbidden. actually
i don't get your difficulties with peters proposal but rather have trouble
aligning your two answers :-)

the example of chefs and resumes and recipes is a good one. noone would ever
add the hrecipe vocab to hresume element set. but just besause the case may
be very rare doesn't make it useless or unimportant. it's, so to say, part
of the long tail of vocabulary usage. that's where general rules get really
helpful.

as a general rule i'd say that concise formats are advantageous and concise
rules how these formats can be combined are advantageous as well. trying to
avoid rules to keep things simple will convolut the vocabularies. adding to
many or to complicated rules would hinder comprehensibility.


On 25.06.09 10:02, "Toby A Inkster" <mail at tobyinkster.co.uk> wrote:
> 
> Related wiki page:
> http://microformats.org/wiki/compositing

as always: excellent, toby! i think this is a good road to go:
-  make clear where the problem lies,
-  add examples both for usefull cases and for no-no's
  (maybe also a rather comprehensible list of what combinations won't work).


in this spirit i would modify my proposal for hRecipe in the following way
(without going into great details here):

* keeping the core element set as focused to recipes as possible
* adding a "best practices" section on how to combine with other
vocabularies for popular additions to recipes like review, tagging, measure
* also warn of common pitfalls (e.g. direct to the corresponding section on
http://microformats.org/wiki/compositing)


cheers,
thomas



.
Thomas Lörtsch
Business Development
G+J Exclusive&Living digital GmbH
Redaktion Online
..
Stubbenhuk 5
20459 Hamburg
...
eMail: loertsch.thomas at guj.de