[uf-new] First draft of hAudio proposal

[Manu Sporny]

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
community?

> collaborator. optional. using hCard.
> 
> --- collaborator might be changed to more of the Dublin core terms
> such as contributer

A good suggestion, backed by favorable reception from the list... the
change has been made.

> release-date. optional. using datetime-design-pattern.
> 
> --- is release-date different than 'published-date'?

Another good suggestion. Going back through the data - it is clear that
it should have been 'published-date', not 'release-date'. Martin has a
point - they are different... but the data backs up the need to use
'published-date' instead of 'released-date'.

> sample. optional. using rel-design-pattern with sample as the mf-rel-value.
> 
> --- by 'sample' do you mean 'clip' or 'download'? what if it isn't a
> SAMPLE, but a full download?

Like Martin said - A sample is never for a full download (per the
examples). A sample is always a partial/incomplete/preview recording. If
a full download is to be specified via a URL, the 'acquire'
rel-design-pattern should be used.

> acquire. optional. using rel-design-pattern with acquire as the
> mf-rel-value.
> 
> --- there is aleady the 'enclosure' used for ATOM and Podcasts

Again, Martin is correct - enclosure is for direct links to files that
should be cached. Most of the examples never link directly to the
download, instead they link to some method of acquisition (usually a
buying or login process).

> image-summary. optional. using HTML and XHTML tag img.
> 
> --- image-summary? why not re-use LOGO or PHOTO?

We could - anybody else on the list have any arguments for or against?
Here's are two arguments related to using logo or photo:

Against LOGO or PHOTO:

- It would be nice if image-summary could be used for video and images
as well. Using PHOTO wouldn't make much sense for images. It wouldn't be
an accurate name for video either.
- LOGO has nothing to do with a pictoral representation of content. Logo
has more to do with branding, marketing and advertising.

For IMAGE-SUMMARY:

- The language is neutral - it can be used for video, image and audio
Microformats.

> 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.

>> is there a reason you want to get this done in the next week or
>> two?

Because I'm the jerk that is going to persistently push the draft
forward :). It would really help the Songbird, Firefox, Operator and
music blog community out - they want a standard. We owe it to them to
deliver it in a timely manner. The sooner we get a community consensus
the better... I'm sure all of us would like to see *thoroughly vetted*
Microformats used sooner rather than later.

-- manu