[uf-new] An argument against 'fn' in hAudio (was: Second attempt at hAudio proposal)

Brian Suda brian.suda at gmail.com
Tue May 8 08:47:13 PDT 2007

On 5/8/07, Manu Sporny <msporny at digitalbazaar.com> wrote:
> Manu Sporny wrote:
> > - The use of 'fn' instead of 'work-title'.
> It has been proposed that 'fn' or 'n' be used instead of 'work-title',
> or 'title'. What follows is an argument against using 'fn' and 'n' for
> hAudio.
> Assumptions:
> - It is important that we choose the generic names that span all
> microformats carefully.
> - Our goal is to lower the cognitive load of website designers using
> Microformats by re-using terms that are semantically equivalent.
> Argument: fn is far too heavyweight for hAudio

--- a disagree, FN is the lightest weight most flexible property.

> fn is short for 'full-name' and is grounded in the VCARD/hCard format.
> The sub-properties of 'fn' and 'n' are: family-name, given-name,
> additional-name, honorific-prefix, honorific-suffix [1]. These are all
> related to 'proper names' - none of them have any meaning when applied
> to hAudio.

--- N should NOT be considered, it has nothing to do with this
conversation. hReview also uses FN for the FORMATTED NAME. FN is NOT
full-name. FN was taken from VCARD, but the semantics are defined as:
"The name of the object."[1] which has nothing to do with VCARD and
can easily be reused in other formats.

> The optimization rules for interpreting 'fn' are quite complex [2], for
> example:
> "If 'FN' and 'ORG' are not the same (see previous section), and the
> value of the 'FN' property is exactly two words (separated by
> whitespace), and there is no explicit 'N' property, then the 'N'
> property is inferred from the 'FN' property. For 'FN's with either one
> word see below, and for three or more, the author MUST explicitly markup
> the 'N', except for the organization contact info case, see above
> (http://microformats.org/wiki/hcard#Organization_Contact_Info) for that."

--- since you are NOT dealing with N and ORG, you can completely
ignore all of this with no issues.

> None of this applies to hAudio - and we don't want Microformat
> implementors confusing how to use 'fn' in hAudio and how to use 'fn' in
> hCard.

--- these are two very different things. This is a non-issue. hCard
parsers do onething, and you can defined Media parsers to do something
completely different. FN is just a semantic value not defining parsing
instructions, that is up to the format.

> Unless a solid argument is presented for using 'fn' instead of
> 'work-title', the proposal will stay with 'work-title'.

--- i would say just the opposite. FN works, you need a strong
argument on WHY we need to create YET ANOTHER property called


[1] - http://microformats.org/wiki/classes

brian suda

More information about the microformats-new mailing list