[uf-new] An argument against 'fn' in hAudio (was: Second
attempt at hAudio proposal)
Tantek Ç elik
tantek at cs.stanford.edu
Tue May 8 14:22:15 PDT 2007
On 5/8/07 2:00 PM, "Andy Mabbett" <andy at pigsonthewing.org.uk> wrote:
> In message
> <21e770780705080847j5e11b6a5pb8b39cce96abe8ce at mail.gmail.com>, Brian
> Suda <brian.suda at gmail.com> writes
>> FN works, you need a strong
>> argument on WHY we need to create YET ANOTHER property called
> Because it describes something more specific (a "work", as opposed to a
The "it describes something more specific" can be a good argument to propose
a new name in general.
Often times that specificity is already implied by the context, i.e. the
root class name for the microformat (for an hAudio proposal vs. hCard), and
thus it is actually more desirable to use a more generic term from a limited
vocabulary for the properties, in order to keep that vocabulary as small as
possible to lower the overall cognitive load of learning microformats in
general, above and beyond learning just one.
Also, there is no need to imply the specificity twice, once by context from
the root, and another time in the name of the property itself.
> In similar fashion, "fn org" currently describes anything from say, a
> road junction to a football club. More specific names would enable
> places and organisations to have different, and therefore
> distinguishing, labels.
The implied issue here is a good one to note, i.e. how to semantically
distinguish a place vs. an org hCard. I've added it to hcard-issues.
More information about the microformats-new