[uf-discuss] mixing vocabularies
pmika at yahoo-inc.com
Thu Jun 25 16:33:36 PDT 2009
I was thinking of something like Toby's page on compositioning which
sets out possible, clearly OK and clearly suspicious combinations.
Ben Ward wrote:
> Hi Peter,
> On 24 Jun 2009, at 23:04, Peter Mika wrote:
>>> What I posit has happened is that at one point, answers.com marked
>>> up the ‘Years Active’ part of that info box with dtstart and dtend.
>> Yes, but let's assume they had the dtstart, i.e. a valid event and a
>> card. Still, having an event named 'Kevin Bacon' is dubious.
> It's not a high quality object, I agree. But, it's valid. It describes
> a timespan and that's a valid event.
>> 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. With reference to this case:
> * hCalendar does not have an `fn` property, no example here or
> elsewhere would instruct someone to use `fn` in hCal.
> * The mark-up here explicitly uses `summary` and `fn`. That "Kevin
> Bacon" is an incomplete name for an event from a content quality
> perspective is not in dispute, but the author explicitly made it the
> summary of their event. They didn't add a second summary attribute
> elsewhere in the content, expecting it to be amalgamated.
> I think it's most likely that the developer is just trying to describe
> all the data they have available using the tools they have: There's an
> hCard there and there's an event. Someone trying to parse his page
> specifically could imply information from the hCard+hCalendar, and
> that's cool, but at the core he's tried to describe his complex
> content using the building blocks available.
> Either way, we can't be certain without consulting with them. I don't
> think it's evidence of erroneous confusion.
>> 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
> 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
> Like all new uses of microformats, ideas about uses of combined
> microformats should be documented on each microformat's
> *-brainstorming page.
> microformats-discuss mailing list
> microformats-discuss at microformats.org
More information about the microformats-discuss