[uf-new] hAudio - audio-album and audio-podcast

[Brian Suda]

On 5/31/07, Manu Sporny <msporny at digitalbazaar.com> wrote:
> > What ever happened to working on the media-format?
>
> The media-format was far too broad of a problem - that's why it hasn't
> moved forward in two years even though there are a great number of
> examples of marking up media on the web. It is far easier to break the
> problem up into audio, video and images and tackle those individually:

--- i would disagree, the Dublin Core group spent many many years and
narrowed down the base Metadata to 14 (i think) values. When people
propose these new microformats each one wants their little pet-project
portion of metadata to get into the new format. In the most basic
sense all the media has a creator and some additional metadata. They
might be different types of formats, but the metadata is the pretty
much the same. I just think there was either, no interest in
developing the format, or too many "what if we add this" happened and
it never moved forward.

> Those are different problems - we aren't addressing those problems with
> this Microformat. We have a very specific problem statement for audio-info:

The problem statement reads:
"It is difficult for a browser to extract semantic information about
an audio recording described on a web page. Metadata such as speaker,
musician, publisher, label, title of the work, release date,
acquisition link, related image artwork and tags provide relevant
context for the audio recording."

with the exception of "audio recording" the could apply to any media
format. I don't feel it is that specific for audio.


> We should stick to the small problem and solve that - not make it bigger
> and more complicated (boiling the oceans).

--- correct, but this doesn't have to mean what formats it
encompasses, but the scope of the problem. It shouldn't attempt to
have every possible metadata property possible - i agree that is
boiling the ocean, but if the same 4-5 metadata properties can apply
to multiple formats we should keep that in mind, and i think we have
done a good job to keep the scope focused on just the minimal amount
of metadata properities needed. I just feel these same properties can
simultaniously apply to multiple things.

> Could you expand on this idea please? I want to make sure I understand
> you correctly. I'm fine with the concept of non-hyphenated names, are
> you suggesting something along the lines of:
>
> album
>    description
>       haudio
>    track
>       haudio
>    track
>       haudio

--- You could have some overarching container, lets call that
something like "media". That has meta data, much like hfeed.

media
  tags, decription, contributer, ...

then, nested in that media is individual items, much like hentry in an hfeed.

media
  tags, description, contributer, ...
  track
  track
  track
  chapter

each of those items (track, chapter, ...) contain additional metadata
about themselves.

media
  tags, description, contributer, ...
  track
    duration, title, author, price, ...
  chapter
    duration, title, author, price, type, ...

> > Last i remember the hAudio proposal basically broke down to just an
> > hReview with a price and a running time.
>
> The semantics of audio-info are very different from the semantics of a
> review. The following are required for audio info (based on the analysis
> and brainstorming done by this list): fn, contributor, published-date,
> rel-sample (samples), rel-enclosure (full versions), rel-payment
> (purchase option), image-summary, category, duration, and price - hardly
> any of those overlap with hReview.

hm, hreview has fn, so does this proposal, it has published-date just
like this proposal, it has an image just like this proposal, it has
tags just like this proposal's category, hreview has URL which could
be used as the download links... like i originally said, it basically
broken down to many of the same values in hReview, with the addition
of price and duration.

The only value required for an hReview is the FN. Then we got all
side-tracked with a grouping issue.

One of the first steps in proposing a microformat is to see if an
existing microformat could fit. After spending along time on the
mailing list, simply suggesting things, the whole conversation
bascially was pulled back to hReview. Has anyone attempted to simply
mark-up their data using hReview with a price and duration (which is
already a solved problem in hCalendar)?

Lets try to keep this MICRO and not go wild attempting to layer more
and more data into hAudio/Media-format.

-brian

-- 
brian suda
http://suda.co.uk