[uf-new] PROPOSAL: Replace hAudio FN with TITLE

[Manu Sporny]

Brian Suda wrote:
>>  hcard does not need to change, we are not RE Defining anything "title"
>>  is used correctly as a "job title"
> 
> --- yes we would be effecting the definition TITLE in hCard. When
> there is an hCard with a title nested inside and hAudio as a
> contributor or other, TITLE now has two different meaning. Which
> MEANING of TITLE should i use? Is this instance of TITLE meant for the
> hCard or for the hAudio?

You could use the same argument for arguing against FN in hAudio.

"When there is an hCard with a FN nested inside an hAudio as the name,
FN now has two different meanings. Which MEANING of FN should I use? Is
this instance of FN meant for the hCard or for the hAudio?"

This is a limitation of Microformats - we don't do object opacity by
default. Although, even that comes into question because of the recent
hCard edit that Tantek made.

This statement makes it seem like you're missing the point - FN has a
slightly different meaning between hCard and hAudio already, are you
arguing for or against that? If you are arguing for keeping FN in
hAudio, that's a slippery slope, as CATEGORY has the same issue in hCard
and hCalendar:

CATEGORY in hCard means "person or organization category"
CATEGORY in hCalendar means "event category"

Those are two different meanings. Microformats have more examples of
this occurring - if you'd like more examples, I'd be happy to give them.

I'm fine with this - I would guess that most are fine with this because
it has happened time and time again in the Microformats specs.

>>  In haudio we are proposing that "title" means "audio title" again
>>  perfectly valid when referring to the "object" not a person.
>>
>>  "Title      hCard Job title or functional position of the object."
>>
>>  would change to..
>>
>>  "Title      hCard Job title or functional position.
>>             hAudio Audio title.
>>             Generally the title of the object"
>>
>>  There is nothing earth shattering about that is there? HOW exacly would
>>  that *break* the definition of hcard?
> 
> Now you have two DIFFERENT meaning for the same term. When you have
> overlapping microformats, there is no way to know which MEANING to
> use. Terms that have the SAME meaning are not effected because the
> property used can overlap and not have any disambiguation.

No, when you have overlapping Microformats that share the same term, you
have issues, period. This holds for FN and it would also hold for TITLE.

> There is a section for anti-patterns but it is blank. Rather than
> start a new page, i think this might be the best place to document why
> giving a property two different meanings is a bad idea, just like
> giving two different properties the same meaning.

You keep saying that we're giving the property two different meanings...
would you want us to extend that to every Microformat, if so - we should
all have issues with CATEGORY, and ITEM.

> We could also start a separate page, and probably should separate
> discussion thread about this topic.
> 
> This is and will be a common problem. 

Yes, it is and will ALWAYS be a common problem because this community
made the decision to not use namespaces. That's fine by me, but that
comes with a trade-off and that trade-off is ambiguity.

It should be quite apparent to everyone at this point that this
community spends more time arguing about which word to use than creating
new standards. These arguments occur because we keep trying to re-define
words that have multiple meanings in the English language to have only
one meaning.

> For instance, hAudio makes use of the term TRACK. 

No, it doesn't - hAudio doesn't use TRACK at all.

> One argument about TITLE is that it is not the
> "Common English definition" therefore we should change it. The meaning
> of TRACK in hAudio is the 14th most common definition in the English
> language[1]. Now it would be silly to stop hAudio from using that. In
> the future, if hWine or hModelTrainEnthusist ever surfaces, they will
> have this same argument. TRACK doesn't mean what it should mean - just
> like we have TITLE does not mean what it should mean!

I'd rather not have a philosophical debate on a theoretical future
Microformat - the discussion will lead nowhere. Let's stick to the
problem at hand: TITLE in hAudio and hCard and the implications of
having TITLE mean what it does in the English language.

Just for the record: I would hate if hAudio stopped the
hModelTrainEnthusiast Microformat from picking the correct name because
we had incorrectly re-defined TRACK to mean something narrower than the
definition in the English language. As for TRACK in hWine, I think you
mean TRACT (as in of land).

> I would say that hAudio was here first, they used the term TRACK and
> defined its meaning for microformats, just as TITLE has been defined
> by vCard. Trying to point to the ever-changing English language as a
> reference point, is probably not a good idea.

When was the last time that the meaning of TITLE was changed in the
English language?

> To have TRACK and TITLE and XYZ have multiple meaning at the same
> time, causes all sorts of semantic problems when you begin to overlap
> the trees. How do you know which meaning to choose?

Show me a place where this happens, and I'll show you that FN has the
same issue. I don't understand what you are proposing in changing?

> This inability to determine the exact meaning is the core of the
> problem.

I agree wholeheartedly. That is at the core of why we get into these
long drawn out discussions. Don't you see - it's at the core of
Microformats - that's the weakness of not using namespaces and having
document processing rules that ignore HTML scope. This issue isn't going
anywhere because it is at the core of what we do.

We're not trying to boil the oceans here - there will always be corner
cases that won't fit into Microformats... that's why we have the 80/20 rule.

You still haven't addressed what is being broken? What will stop
functioning as a result of us using TITLE in both hCard and hAudio?

-- manu