[uf-new] Namespace anti-pattern and hAudio TITLE (was: hAudio FN or Title)

[Scott Reynen]

On Feb 4, 2008, at 8:38 AM, Manu Sporny wrote:

>> The problem of such use of the term "title" is twofold.
>> 1) it's already used to mean "job title" in the context of  
>> microformats.
>
> Wait, what!? So FN can have two slightly different meanings based on
> it's context, but TITLE cannot? Why is that?


TITLE can have different meanings, but those different meanings can  
not contradict the meaning within the larger context of microformats,  
which is currently "job title".  If audio segments had job titles, we  
could use TITLE to indicate those, creating a derived meaning of  
"audio job title" vs. "person job title" in hCard.  This would be  
analogous to "item formatted name" in hReview vs. "person formatted  
name" in hCard.  The meaning of "formatted name" or "job title" does  
not change between microformats; it only gains *additional* meaning  
with additional context.

On a more meta-level, if past decisions don't appear to make sense,  
please ask for explanations of the thought behind them rather than  
assuming there was no thought.  The latter can come off as somewhat  
insulting to those who made the decisions and create unnecessarily  
inflammatory discussions.

> Incorrect, the concept that it is being proposed to represent is the
> *title* of an audio recording. TITLE is widely used for that purpose  
> in
> the english language. We should not restrict that word to mean "job
> title"

We've *already* done that, out of deference for the semantics of RFC  
2426.  Regardless of how we feel about that decision in hindsight, the  
question now is whether or not we should, or even could, change it  
now.  Even if the change makes sense on an abstract level, we now need  
to ask: what are the practical consequences of redefining TITLE to  
mean simply "title" instead of the current meaning of "job title"?   
It's no longer merely an issue of which abstract semantics are more  
accurate.

--
Scott Reynen
MakeDataMakeSense.com