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

[Manu Sporny]

Martin McEvoy wrote:
> I think he means "Context-Aware I
> And to answer Manu's no I don't think its necessary, Microformats
> already ARE context aware?

Yes! This is my point exactly. If Microformats ARE context aware, then
there is the concept of namespaces in Microformats. Namespaces are NOT
an anti-pattern afterall.

Guillaume wrote:
> "what I'm reading here is that classname "fn" may have different
> meaning if used outside of an element of class "vcard". Saying this is
> to me equivalent to saying the "vcard" classname syntax is syntactic
> sugar for the concept of a namespace (as is "vcard-fn" or "vcard:fn").
> My understanding was that the concept of namespace, not just its xml
> syntax, was an antipattern in microformats. Am I mistaken?"

No, you're not mistaken. You've just pointed out one of the logical
fallacies in the Microformats community.

The community keeps repeating that namespaces are bad and that we
shouldn't use them, all the while using them in each and every
Microformat that we put out.

Here's an example of this logical fallacy:

"What is the semantic meaning of FN outside of any Microformat markup?"

The undeniable answer is:

"There is no semantic meaning outside of any Microformat."

FN doesn't mean anything useful until it is "wrapped" by a Microformat -
hCard, or hAudio, for example. This means that the wrapping Microformat
brings context into the equation.

That is the core definition of a namespace:

"In general, a namespace is an abstract container providing context for
the items (names, or technical terms, or words) it holds and allowing
disambiguation of items having the same name (residing in different
namespaces)."[1]

FN in hAudio is really marking up "the audio recording's title", FN in
hCard is really marking up "the person or organization's formatted name".

FN means two different things when used in hCard and hAudio. So does
TITLE, if we were to adopt it for hAudio.

It is as if we're defaulting to hCard to define the meaning of TITLE
instead of defaulting to the English language to define the meaning of
TITLE.

Yes, the English language has ambiguous terms, but that is why we have
the concept of context in the English language and programming languages
have the concept of namespaces.

It is time for this community to realize that ambiguity is fine as long
as we have a method of disambiguation - namespaces, and more
specifically, context... which is already used, even though it is listed
as an anti-pattern.

We should be using TITLE for the title of audio recordings. hCard
shouldn't prevent us from doing so because of a narrow definition for
TITLE that was entered into the wiki several years back by one person.

The reason we aren't using title right now is because the Microformats
wiki defines "TITLE" as "job title" - which goes against the English
definition of the word.

So, who is going to make an argument against using TITLE in hAudio?

-- manu

[1]http://en.wikipedia.org/wiki/Namespace