On Feb 4, 2008, at 8:38 AM, Manu Sporny 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". 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.
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.
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. 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.
--
Scott Reynen
MakeDataMakeSense.com
_______________________________________________
microformats-new mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-new
