[uf-discuss] mixing vocabularies

[Ben Ward]

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