Colin mentioned an excellent use case for microformats to me: a standardized way of displaying information about music, most likely a direct one-to-one relation in XHTML of the ID3 data that is embedded in MP3 files today.
Since audio files are binary files, in many cases quite huge, having basic crawlers parse them to get this ID3 would introduce a ton of overhead. Having this available in a human-readable way that is also parse-able would be great.
I'm sure Colin will expand on this mini-post (nudge, nudge). Update: He did - Micro formats and audio = peanut butter and chocolate
Comments
First good reason...
Ok, so far, I've been underwhelmed by Microformats. Basically, the argument for them is that they work, and that you can easily add class attributes in HTML tags to add semantic information to Web content. Big deal.
But, this is an excellent use case. Or at least it appears to be on the surface. But it's not particularly. Here is why:
MP3 files include a header at the start of the file with an 11 bit "sync" block. The sync block allows players to search for and "lock onto" bits of the file, including skipping right to ID3 or other data that may be living at the start of the mp3 file. You don't have to read the entire file to get the meta-data, so why do we need another format?
Isn't Microformats is what REST is for?
"Paving the cowpaths" as MF has been called, is an approach that has brought us such uglies as HTML4, and Javascript (ever heard of ECMAScript?). I'm not against Microformats, but history worries me.
I have an open mind here. Could someone put fourth a convincing argument that doesn't rely on "it fixes problems now" and "you don't need librarians" for why we really need Microformats? Those aren't good enough reasons for me to use an (X)HTML described code to replace well built web services.
Hard to do what you describe
The use case for music metadata is such that large binary files have to be read. Well, the very fact that they have to be read at all: the more common case would be to create a blog post and link to an MP3 file, or somehow attach it to the post.
Of course, the audio module that Colin wrote actually does read the ID3 metadata and displays it, so again it's a case of having a publishing platform that's more capable than the vast majority of systems out there.
If you don't like that answer, then my default fallback is to say that this is an easy way to put metadata inside a text blob.
good idea, let's work on it
A microformat for describing metadata about music is a great use case for microformats. Often, the metadata is already published on the web and a microformat would serve to make the data explicit. If anyone's interested in working on such a format, some people have started collecting examples of how metadata is marked up on the web. So, if you're interested, consider joining the microformats mailing list (http://microformats.org/discuss/) and then contributing to the wiki.
Seems like a no-brainer for music
Unless I'm missing something, a straight up implementation of ID3 in an XHTML compatible format seems the logical way to go. Playlist formats are a separate issue -- they represent collections of audio instances.
Not a no-brainer
The problem with this area is that there's a lot of prior art: ID3, MPEG, MediaRSS, Apple's podcasting stuff, etc. Of course, those formats have varying degrees of adoption, so they probably shouldn't be considered as equals. ID3, may indeed be a good model, but I think some more research is in order first, and that's what's going on right now on the microformats.org wiki.
Hmmm...
MediaRSS and iTunesRSS both don't seem to play in this same space -- i.e. that's a podcasting microformat, *IF* one is needed. And...those are for machines, not humans, so what do we care?
Playlists would be a list of music elements OR pointers to remote music objects/files.
I couldn't find any link to MPEG stuff for audio, other than the MPEG-7 link for video.
For just music metadata, ID3 just seems the logical choice.