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

[Joe Andrieu]

Manu Sporny wrote:
> Joe Andrieu wrote:
> >> We need examples of playlists to support your playlist
> >> argument... which we don't have.
> > 
> > Sure we do. There are a bunch on the examples page,
> > including the FIQL service I mentioned in my email.
> 
> Are we looking at the same examples page?
> 
> http://microformats.org/wiki/audio-info-examples

Wow.  I literally have no idea how I found FIQL.  I was sure it was from the examples page. Here are a few examples of playlists:

CCMixter http://ccmixter.org/media/view/media/playlists
FIQL http://www.fiql.com
FNAC Music http://www.fnacmusic.com/pl/95c186a6-ca78-4e69-bb6c-d1fc155cfcdd.aspx
Mix Matcher http://www.mixmatcher.com

However, your point is correct. The current list of examples are all built around albums and playlists. Most likely because that's
pretty much what you restricted it to with the templates. No offense intended, but it's a pretty strong opening constraint at the
top of the wiki page.

Rather than jump in and violate that structure, I've not added the playlist examples above to the wiki yet.

> >> What we do have, however, is a plethora of album/track/song
> >> examples. Let's focus on solving that very specific problem.
> > 
> > I support that.  But then what you are solving is hAlbum.
> > Not hAudio.  Once we figure out hAlbum, we can certainly
> > generalize upward to hAudio, incorporating playlists and
> > podcasts as we go.
> 
> That's funny... that's exactly what we said about hAudio... 
> "we'll start with hAudio and generalize upward to albums, 
> podcasts and playlists."

Ah... Well, that's ok. But I don't think it is what you are doing as there is much conversation and documentation about albums and
"grouping".

If you want to start with the most basic atomic element, that /could/ be "hAudio", although a slightly different hAudio than I was
considering.  An "atomic" hAudio is more what I was calling audiofile, i.e., the representation of a single audio resource.

I was coming at it from the other direction: that hAudio is a type of hMedia, a peer of hVideo and hBook. In that case, it would
contain/be any kind of audio packaging from albums to podcasts to playlists.

> The hAudio Microformat is meant to be "delivery/container 
> mechanism" agnostic. hAudio is supposed to be encapsulated by 
> the delivery mechanism, be it a playlist, album, podcast, 
> media or other such container.

Ok. That I can support. So, let's step back from the "album" and grouping concepts and focus on "hAudio" as this paragraph suggests.

Frankly, whether this is called hAudio or hAudiofile is not so interesting. However, I do believe it is the simplest, most atomic
problem we could start with. And therefore, probably our best chance for getting traction.  The current hAudio proposal says
"Defining parts of an hAudio will not be complete without a complete grouping draft/specification."  That comes across as implying a
much more complicated hAudio than the schema and your most recent comments suggests.

> What is your definition for a playlist? I think we have 
> different definitions. Do you mean "A list of playable audio 
> objects."?

That's a really good question. I mean a list of audio tracks. They need not be "playable" in the sense of having a downloadable
reference, but if they were to be found, then each of the items should produce audio when played using the appropriate application
or device. So, althought I know this doesn't hit the 80/20 rule, for me, a playlist should work for offline and fictional songs. For
example a playlist of "Elvis From the Dead" with Elvis song titles "adjusted" for Halloween.  Yes, I know this is totally outside
the scope of what we should waste our time on, but it illustrates one of the boundaries of what a playlist could be. More
practically, one might create a playlist wishlist for songs they don't know where or how to find online or that they don't care to,
because they have the CDs and that's what the DJ will be using at the bar mitzvah this weekend. You get the idea, I think.

In my conception:
. Album: playlist(s) + meta-data (including cover-art, etc.)
. Playlist: track(s) + meta-data
. Track: option audiofile(s), each the same "audio" in different formats or from different distribution points + meta-data
. Podcast: playlist(s) + meta-data; although I think 80/20 suggests podcasts are usually a single track, single audiofile
. Audiofile: a specific downloadable media file that contains audio + meta-data.


So, I'm good with focusing current efforts on the simplest case. I would call that an audiofile, but by no means do I think that's
the important term.

What would you call what I've been referring to as hAudio, a type of hMedia and a peer to the as-yet-to-be-defined hVideo and hBook?


Also, I bet that cleaning up the current hAudio to focus entirely on just this atomic item, and none of the grouping... including
album... Would make this a lot more tractable and understandable for folks.

In fact, I would suggest moving all of the album examples to an album-examples page. And playlists to a playlist-examples page.

I am unsure about where to draw the line between "tracks" and "audiofiles" in a spec, but finding examples of each might be useful.
Specifically, I'm curious how many times alternative formats/sources are listed for tracks.

More research for the future. =)

-j

--
Joe Andrieu
SwitchBook Software
http://www.switchbook.com
joe at switchbook.com
+1 (805) 705-8651