[uf-new] Microformat for Music Downloads

[Manu Sporny]

Martin McEvoy wrote:
> I can agree with scott we should re-use existing formats if we can to
> solve the simpler problem, isn't this the Microformat way to solve the
> simple problem. If the new format can be hooked into an existing format
> such as hAtom, with the addition of rel="enclosure" with a few extra
> extensions such as artist, and length, why not its simple which is how
> it should be, and easy for developers of all skill levels to use.

I agree with both of you in principal - new formats should not be
created if minor modifications to a pre-existing format, such as hAtom
or hReview, will do.

However, it would be a bad idea to bloat pre-existing standards such as
hAtom and hReview when a new microformat is needed. I believe the
discussion we are having is "Do we need a new microformat to describe
music downloads?".

The problem description that I believe you have proposed is (paraphrased):

All I want to know before hand is 'Is it the file type I'm expecting
i.e. mp3' and 'Is it by who I'm expecting it to be'. I might also be
interested in the title of the download and the length of the file.

If you look back to the beginning of this thread:

http://microformats.org/discuss/mail/microformats-new/2007-March/000028.html

Marian stated a more complex problem description:

"Provide users with the correct metadata about the audio files so
users know who it's from and whether or not they want the file. In
case of music, this usually means an artist, a song title and so on.
For audio in general, this could also mean size of the file, duration,
bitrate and some other technical parameters like DRM info etc....

While the vast majority of the downloadable music out there is pop
music, also jazz and classical might want to be considered, since
there is a difference in description of meta information
(title/artist/album vs. title/musician(s)/composer vs.
title/orchestra/conductor/composer/work). I read in earlier music
discussions that OGG comments [3] provide a pretty useful model for
the description of classical."

Marian's problem description is much larger in scope than your problem
description. So, which problem are we attempting to solve? We have
several options that I can see:

1. Extend hAtom/hReview to support a very small subset of Marian and
your problem description, solving a simple problem, but potentially
bloating a Microformat when a new microformat is needed.
2. Complete media-info - which will solve both your and Marian's problem
descriptions, but could take a really long time to solve a complex problem.
3. Create a very simple hAudio microformat, which can then be integrated
into media-info, solving your problem and Marian's problem. It would
also lay some foundation for media-info, which I know Scott was
concerned about. The downside being YAuF - yet another Microformat.

Any thoughts on how to proceed? I think we should start by outlining
what problem we are trying to solve. I was under the impression that we
were trying to solve Marian's problem description and the one vaguely
outlined on the music-examples page.

-- manu