[uf-discuss] mixing vocabularies

[Peter Mika]

Hi Ben,

I was thinking of something like Toby's page on compositioning which 
sets out possible, clearly OK and clearly suspicious combinations.

Cheers,
Peter

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 
> 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.
>
> Thanks,
>
> Ben
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss