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

[Manu Sporny]

Scott Reynen 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".  

What I'm challenging is the idea that TITLE should mean "job title". I'm
asserting that it should be the definition of TITLE as used in the
English language.

TITLE means "job title" because it was defined in Microformats by
re-using the meaning in RFC 2426, which is a narrow definition of TITLE.
I realize that circumstances change and I wasn't implying that there was
"no thought" behind those decisions. However, those decisions happened
in a Microformats community that was far smaller than it is now. It
happened in one that was attempting to solve problems without the
constraint of the vocabularies that we have now.

> 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.

Yes, and if we were to change TITLE to mean "title" as defined by the
English language, then it would gain additional context in hCard to mean
"job title", and additional context in hAudio to mean "audio recording
title". I don't think that concept is that revolutionary, even though it
has been treated as that in the past.

> 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.

I wholeheartedly did not mean to imply that there was no thought put
into the decision. I have always attempted to use a very respectful tone
in e-mails to the list. I assert that you would find it difficult to
find any one of my e-mails that attack anybody on this list personally.
 I will always attempt to keep a respectful tone and feel that I have
done that in the majority of my communication to the list.

I did ask for explanations for the TITLE decision[1], I started asking
back in June of 2007[2], and have not been satisfied with the arguments
for keeping TITLE the same.

Since it seems as if my intentions were misunderstood - I am criticizing
an idea here, not the people that made the decision. As a general rule,
I never criticize people. Ideas, however, are fair game.

I am challenging the idea that TITLE should mean "job title". Apologies
if it seemed if I was doing anything other than that.

>> 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. 

I would love to have that conversation, so let's begin...

> 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.

Then let's talk about the ramifications of changing TITLE to mean
"title" instead of "job title". After putting a significant amount of
thought into this, I am asserting that it will not affect any legacy
Microformats page for the following reasons:

* TITLE is not used outside of hCard.

Additionally, it will greatly reduce context collisions between hAudio
and hCard:

* There can be an FN conflict between hAudio and hCard already. Since
  TITLE would be used far less than FN when combining hCards and
  hAudios, the chances of a hAudio.TITLE confliciting with an
  hCard.TITLE in hAudio are far lower than an hAudio.FN conflicting with
  an hCard.FN. TITLE is rarely used in hCards that are included in
  hAudios.

Are there any other ramifications of changing the definition of TITLE
from "job title" to "title" that I am not seeing?

-- manu

[1]http://microformats.org/discuss/mail/microformats-new/2008-February/001414.html
[2]http://microformats.org/discuss/mail/microformats-new/2007-June/000511.html