[uf-new] hAudio - audio-album and audio-podcast
Joe Andrieu
joe at andrieu.net
Mon Jun 4 17:33:19 PDT 2007
Manu Sporny wrote:
> > 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 we're suggesting is a very simple addition to hAudio.
> This is the same exact solution that was devised for hAtom...
> you should take some time and read up on the 'hfeed' property.
>
> http://microformats.org/wiki/hatom#Feed
>
> What we're talking about adding is 'album'.
To quote from the wiki[1]:
==
tracks, songs, and parts in general are specified by embedding hAudio's inside of hAudios and using the ideas put forth in
grouping-brainstorming and grouping-proposal. Defining parts of an hAudio will not be complete without a complete grouping
draft/specification.
==
It seems that halbum means we no longer requires this "grouping" abstraction. If this is correct, I think it is the right way to go
(and we should update the wiki). If I'm misunderstanding and the above quote is still valid, then please explain how grouping fits
into the current haudio proposal.
> >> 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...
>
> We've already had the playlist discussion on this list:
>
> http://microformats.org/discuss/mail/microformats-new/2007-April/000155.html
>
> A playlist is hAudio + XOXO - simple as that.
Respectfully, a few points. First, please don't assume that your most recent statement on the email list is the definitive community
answer. "We've already had this discussion" comes across as patronizing.
Second, you asked for my definition. Please take a moment to respond rather than suggest it is made irrelevant by prior
conversations.
Third, the link you refer to seems to be discussing XOXO as a general solution to an ordered grouping. Certainly, playlists are an
ordered grouping. However, there is more to it than that. They are playslists. A playlist indicates that the following list is meant
(or is intrinsically packaged) to be played together. Not every listing of audio is a playlist. For example, considering the
combined works of Beethoven as a playlist is a bit excessive, even if the works are all proper hAudio items. However, I believe the
current specification has no way to specify that a given XOXO list is a /playlist/ without an oddly redundant haudio that is
confusing in more ways than one.
In the email cited above you state:
==
<div class="haudio">
<span class="collection">
Audio albums, DVDs, and photo albums could have the "collection"
specifier, songs, video episodes, and images wouldn't.
==
However, rather than have "album" a specific of a generic "collection", I believe you are currently suggesting evolving the the
proposal have halbum as a first class microformat, which contains other, multiply different haudio elements of fundamentally
different types. I support "album" as a semantically specific collection, but I'm still unsure why there are two different types of
hAudio in your example:
===
Here is a complete example of what we're talking about:
<div class="halbum">
<div class="summary">
<div class="haudio">
<span class="title">Black Horse and The Cherry Tree</span> by
<span class="collaborator hcard fn">KT Tunstall</span>
</div>
<ol class="xoxo">
<li>
<div class="track">
<div class="haudio">
<span class="fn">Black Horse & The Cherry Tree</span>
</div>
</div>
</li>
<li>
<div class="track">
<div class="haudio">
<span class="fn">One Day [Live]</span>
</div>
</div>
</li>
</ol>
</div>
It's simple design, readable, easy to author, contains a "playlist", doesn't have any scary dot-notation, and is semantically rich.
===
I have several questions with this approach.
First, what is that first haudio item, the at halbum->summary->haudio?
Is that a playable audio file of the entire album? If we are working with hAudio at the most basic component for audio, I would
think haudio would be the actual file or at least the meta-data around facsimiles of the same audio content (perhaps different file
formats underneath).
It seems that haudio is potentially--and confusingly--presented as both an atomic semantic class and as a grouping construct capable
of making collections out of itself. I don't quite understand how you intend to use it.
See the wiki example for album markup[2] for an example of haudio used as a collection item for albums.
Second, how would I display just a playlist, one that has never been an album? Is it like this:
<ol class="xoxo">
<div class="fn">My Party Songs</div>
<li>
<div class="track">
<div class="haudio">
<span class="fn">Black Horse & The Cherry Tree</span>
</div>
</div>
</li>
<li>
<div class="track">
<div class="haudio">
<span class="fn">One Day [Live]</span>
</div>
</div>
</li>
</ol>
If that is correct, then how am I (as a parser) to know that this XOXO is a playlist? It seems to me that just as halbum is a
specific collection, so too is a playlist, perhaps best represented by hplaylist. The point is that not all XOXOs are playlists and
not all lists of hAudio tracks are playlists. Generalizing the playlist to XOXO loses semantic specificity, with nothing gained.
If XOXO works well, then we can always adopt its semantics with added specificity: an hplaylist is an XOXO playlist of hAudio items.
Then, replacing XOXO in your example with "hplaylist" or its equivalent provides a more semantically rich representation of
playlists.
Third, what is a track? Is that semantically specified in the haudio schema? I don't see it in the wiki and you both argue that it
is unnecessary /and/ you use it in your example. I'm not sure what point you are trying to make with it.
Fourth, this outline seems inconsistent with what is current on the wiki. I'm guessing that the proposal is actually evolving based
on these conversations, which means it makes sense for it to be a bit out of date. However, it also makes it harder to track,
especially when hAudio gets used in different ways, like in your recent example.
> > In my conception:
> > . Album: playlist(s) + meta-data (including cover-art, etc.)
>
> Album: 'album' property + 'track' property + hAudio
>
> > . Playlist: track(s) + meta-data
>
> Playlist: XOXO + hAudio
>
> > . Track: option audiofile(s), each the same "audio" in
> > different formats or from different distribution points + meta-data
>
> No need for this complexity - this case is covered in the
> Album example above.
This I don't understand. You included tracks in your example, but then state that they aren't needed. Am I missing something?
> > . Podcast: playlist(s) + meta-data; although I think
> > 80/20 suggests podcasts are usually a single track, single audiofile
>
> No need for this complexity yet, or if we want to do this, it
> would be mirrored directly from Album:
>
> Album: 'podcast' property + XOXO + hAudio
>
> > . Audiofile: a specific downloadable media file that contains
> > audio + meta-data.
>
> We've already discussed this concept on the mailing list:
>
> http://microformats.org/discuss/mail/microformats-new/2007-April/000107.html
The referred email (and the referenced wiki page) seems to be barely more than a suggestion. I don't yet see how audiofiles are
addressed in the proposal, except to say that they aren't. In which case, it seems that hAudio represents only the meta-data about
an audio piece, but without the meta-data about the audiofile. Further, the media-info format seems to abstract away the essence of
the type of media, or at best requires a redundant specification.
Again, from a top-down perspective--how I have been thinking of this--it seems that hMedia is really about a set of peers, including
hVideo, hAudio, hImage, hPublication. In an hAudio item, child elements of that hAudio would then define the components of that
hAudio item without additional "h" prefixes. Note that this is /not/ the hAudio that you seem to be working with.
Hence, a hiarchy like this:
hAudio
album
playlist
track
audiofile
audiofile
audiofile
track
audiofile
audiofile
audiofile
track
audiofile
audiofile
audiofile
hVideo
series
episodelist
episode
videofile
videofile
episode
videofile
videofile
episode
videofile
videofile
Noting that playlist may or may not require album, but does use hAudio as the container for the child elements and audiofile for the
actual file. In short, hAudio is saying to the parser, the items in this container are a single hAudio item; treat accordingly,
whether an album, playlist, track, or audiofile. The audiofile is, essentially an audio version of a media-file.
The problem with media-file (referred to in your linked email) is that you gain nothing from the abstraction & generalization. If
at the bottom of an hAudio component, you have a media-file, won't you have to again specify the media-type? That is redundant.
hAudio should, imo, boil down to one or more actual audiofiles (assuming any media is available at all).
The alternative to the above that I thought you were going for was something like this:
halbum
playlist/XOXO
haudio
haudio
haudio
haudio
But then in your example, you did something like this:
halbum
haudio
playlist/XOXO
track
haudio
track
haudio
track
haudio
That was definitely confusing.
If we use the current proposal/brainstorms for hAudio and media-info, how does one mark up a given haudio so that you link to high
and low bandwidth realplayer and windows media format versions of the same song?
Where does the downloadable/streamable file go in the schema?
> > So, I'm good with focusing current efforts on the simplest case.
> Good, we have agreement on principal - however, I think the "simplest case" that we're
> outlining is far more simple than you think it is.
I don't think we're on the same page yet. hAudio still seems to have magical collection and grouping properties that I don't
understand and your use of "track" in your example is confusing. I'm not sure what to make of it. Finally, how do you represent
alternative presentations of the same effective audio piece as in my last point?
Btw, I want to be clear that hMedia, hVideo, etc., aren't items to tackle at this point. They are provided for symmetry to challenge
the assumptions around the benefits of generic containers and grouping. Each media format has its own grouping semantics, let's
retain that by simply standardizing how we currently package, sell, and distribute audio.
Respectfully,
-j
[1] http://microformats.org/wiki/audio-info-proposal#Schema
[2] http://microformats.org/wiki/audio-info-proposal#Audio_Album_Example
--
Joe Andrieu
SwitchBook Software
http://www.switchbook.com
joe at switchbook.com
+1 (805) 705-8651
More information about the microformats-new
mailing list