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

[Martin McEvoy]

On Thu, 2008-02-14 at 08:29 +0000, Brian Suda wrote:
> 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.

You are correct "We do not know the intent of the vCard authors"
but we do know where "title" gets its semantics from it is cited in the
vcard "This type is based on the X.520 Title attribute".

X.520

5.4.3  Title

The Title attribute type specifies the designated position or function
of the object within an organization.

An attribute value for Title is a string.

www.dante.net/np/ds/osi/9594-6-X.520.A4.ps

or

http://tinyurl.com/27yb33


vCard refers to a person "job title", X.520 says nothing about a person
just and "object" however the semantics ARE similar:

"function of the object" in hcard is a Job title.

"function of the object" in haudio is an Audio title.

The truth is we are ALL missing the point hAudio does NOT re-use "title"
from hcard, because hcard was NOT built using "the process" it would
break our data model.

hAudio has however vigorously used "the microformats process" to
determine its meaning these are based upon "current usage"
Thus It would be IMPOSSIBLE for haudio to cite a source based upon a
single definition made back in 1993.

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

Quite some time ago we chose "item" INSTEAD if "track" because of the
exact same reasons as you noted...

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

I read somewhere quite recently that nested hcards are not allowed to
read information from their parents...

"When parsing an hCard, if a parser finds a nested hCard, it should
treat that hCard as its own object, and treat properties of the nested
hCard as only belonging to the nested hCard, not the containing hCard."
http://microformats.org/wiki?title=hcard-parsing&diff=next&oldid=25563

If a hcard DID occur within an hAudio I presume that it will be treated
as its own object or is that not what it means?. 

Anyway I wouldn't worry Not many Microfomats built using the process
actually make it to Specification...

I think we should start a new discussion about "grandfathering" some
microformats or at least see if they go through the process and bring
them up to date with current practices what do you think?

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

 ....

Thanks

Martin McEvoy
>