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

Mon Feb 4 08:25:07 PST 2008

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