[uf-new] title vs. summary (was: Third attempt at hAudio)

[Scott Reynen]

On Jun 8, 2007, at 2:45 PM, Martin McEvoy wrote:

> I think at the time hCard was meant to be identical to the vCard
> Standard in every way and mach the scheme defined in
> http://www.ietf.org/rfc/rfc2426.txt there was no guess work or  
> defining
> or anything just well established standards
>
> for us to use title from vCard would mean that our meaning in hAudio
> would have to match the title attribute in the vCard standard.

Right.

> the only other microformat that does use Title is of course hAtom  
> which
> is also built around rfc standards http://www.ietf.org/rfc/rfc4287  
> Atom

hAtom actually uses "entry-title."  While that has a similar meaning  
to "title" in English, those two terms have completely distinct  
meanings in microformat definitions, because microformats definitions  
are by necessity more specific than English definitions.

> this is why we cant change hAtom to suit our needs because it is based
> on already well established standards.

Right, but if we can re-use existing class names without changing the  
meaning, we should do so, as it makes things easier for publishers.

> Summary as Brian put it is the easiest fruit to pick from the tree as
> most or the established microformats  hReview, hResume, and hCalendar
> already use summary to mean exactly what we want it to mean.

There seems to be some disagreement over whether "summary" is  
actually what we want it to mean.  I point this out not because I  
personally disagree, but because addressing this disagreement is  
required before moving forward, which I think we'd all like to do.

> The discussion around re-defining the vcard title to mean what we want
> it to mean may take a very long time to accomplish, and  it would have
> to be via the microformat process.

Right.  I think trying to change hCard, one of the oldest  
microformats, before moving forward with hAudio is a good way to  
grind the hAudio discussion to a halt for a long time, so I think we  
should do whatever we can to avoid that.

--
Scott Reynen
MakeDataMakeSense.com