[uf-new] First draft of hAudio proposal
davidjanes at blogmatrix.com
Wed May 2 04:05:58 PDT 2007
On 5/1/07, Manu Sporny <msporny at digitalbazaar.com> wrote:
> Brian Suda wrote:
> > On 5/1/07, Manu Sporny <msporny at digitalbazaar.com> wrote:
> >> We need feedback on the hAudio Microformat proposal.
> >> hAudio (haudio)
> >> - title. required. text.
> > title is already taken to mean something else, so TITLE is not an
> > option. hCard uses TITLE for job-title. I would suggest FN instead.
> Sorry, that was a typo (in what would be the worst place possible). It
> should have been 'work-title'. The name was chosen because it can be
> re-used for the audio, video and image microformats. We could use FN,
> but 'work-title' is far more accurate. Thoughts from the rest of the
If you mean what most people do by "title", then FN is the correct
thing to use. If there's some real semantic difference between the
title of the song and FN, then you may want to invent something new.
But we don't want to invent two microformat terms to mean the same
For the reasons why hAtom uses entry-title and feed-title, see this
. Briefly, there are examples in the wild where semantically the FN
and entry-title would differ.
> > genre. optional. text.
> >> genre sounds alot like TAGS or CATEGORIES to me? we should recycle
> >> terms in existing microformats
> What Andy Mabbett said... not all authors want to mark up genres as
> URLs. There are enough examples that don't mark up the genre to not
> require the use of a URL-based TAGS/CATEGORIES approach.
While (very) sympathetic to Andy's point about this, we're getting to
the danger point of semantically forking rel-tag. I suspect you will
get strong pushback on this one, because the current approach is to
use rel-tag for this, and if that needs to be fixed, it needs to be
fixed and the problem should be addressed there.
More information about the microformats-new