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

Brian Suda brian.suda at gmail.com
Thu Feb 14 00:29:59 PST 2008


2008/2/13, Martin McEvoy <info at weborganics.co.uk>:
> If we are referring to "objects" not people they do not have
>  "job-titles" so we must be referring to the functional title of of the
>  object eg:

--- I don´t think we can say MUST be referring too. We do not know the
intent of the vCard authors.

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

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

>  I am sorry if i am misunderstanding anything, Please take the time to
>  explain to me anything that is incorrect or wrong?.

--- this does seem to be coming up more and more, so i began to look
around the wiki to see if there was already a page. i did find this:

http://microformats.org/wiki/naming-principles

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.

We could also start a separate page, and probably should separate
discussion thread about this topic.

This is and will be a common problem. For instance, hAudio makes use
of the term TRACK. 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 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.

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?

This inability to determine the exact meaning is the core of the
problem. I will try to get some information up on the wiki, if someone
wants to create stubs or FAQs, i (or someone else) will help document
and answer them.

The mailing list is not the best place to reference our answers when
these questions come-up again.

-brian

[1] - http://dictionary.reference.com/browse/track

-- 
brian suda
http://suda.co.uk



More information about the microformats-new mailing list