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

[Manu Sporny]

Joe Andrieu wrote:
> It seems that halbum means we no longer requires this 
> "grouping" abstraction.

That is correct - but this has only come about in the last couple of
days. I usually wait for some sort of concensus before updating the wiki.

>>>> 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.

Apologies if my statements came across as patronizing. They were
certainly not intended as such, you have made some very good points and
continue to do so. Please take my statements as opinion backed by what I
consider solid logical arguments.

The reason that I pointed you to that link is that I think you are
making an argument for an addition to hAudio grouping called 'playlist'.

At the end of the thread, Kevin Marks said:

"XOXO is a fine way to express simple collections, or nested ones; eg
hGeo in XOXO is a sensible form fro waypoints."

"hAudio in XOXO would be a sequence, or playlist, which is a useful form."

Nobody seemed to disagree with that - the thread died there. I think
everybody on here is open to talking about playlists.

I don't necessarily think that we NEED the concept of a 'playlist' in
halbum... we probably don't even need the concept of xoxo in halbum.
We're trying to start with the simplest possible solution and we can
build on top of that at a later date.

> I support "album" as a semantically specific collection, but 
> I'm still unsure why there are two different types of
> hAudio in your example

The example doesn't contain two different types of hAudio. hAudio
describes information about an audio recording. Note that this is
different from describing an audio file. Describing an audio file is the
job of the file-format exploratory discussion:

http://microformats.org/wiki/file-format-examples

> I have several questions with this approach.
> 
> First, what is that first haudio item, the at 
> halbum->summary->haudio?

The first haudio describes the album - which is why it is encased in a
'summary' tag.

> Is that a playable audio file of the entire album?  

If somebody wanted to provide a complete audio file of the entire album,
they would use the rel-enclosure method in halbum->summary->haudio. Here
is an example:

<div class="halbum">
 <div class="summary">
  <div class="haudio">
   <span class="fn">Black Horse and The Cherry Tree</span>
   <a rel="enclosure" href="/black-horse-album.mp3">Download</a>
  </div>
 </div>
</div>

> 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).

Describing an audio file is the job of the file-format exploratory
discussion. Describing files is not part of the haudio discussion:

http://microformats.org/wiki/file-format-examples

I pointed you to the

> 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.

Then, perhaps it would be helpful to think of it this way. We are
talking about two Microformats: halbum and haudio

haudio is the "atomic" Microformat that is used to describe audio
recordings.

halbum is the grouping Microformat for audio albums specifically - it
can aggregate a number of haudio recordings together.

We are not using hAtom to aggregate hAudio into albums because when we
use hAtom, we lose semantic meaning. The same argument could be used as
a pro-playlist stance.

> 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>

With the current approach it would be like this:

<ol class="xoxo">
 <li>
  <div class="haudio">
   <span class="fn">Black Horse & The Cherry Tree</span>
  </div>
 </li>
 <li>
  <div class="haudio">
   <span class="fn">One Day [Live]</span>
  </div>
 </li>
</ol>

if you want to make an argument for adding a playlist container, it
could be like this:

<ol class="playlist">
 <li class="track">
  <div class="haudio">
   <span class="fn">Black Horse & The Cherry Tree</span>
  </div>
 </li>
 <li class="track">
  <div class="haudio">
   <span class="fn">One Day [Live]</span>
  </div>
 </li>
</ol>

> If that is correct, then how am I (as a parser) to know that this 
> XOXO is a playlist?

If you find an xoxo that has at least two elements that are haudios -
you would assume that you have a playlist.

> Generalizing the playlist to XOXO loses semantic specificity,
> with nothing gained.
> Then, replacing XOXO in your example with "hplaylist" or its
> equivalent provides a more semantically rich representation of
> playlists.

You have a valid point as far as I'm concerned.

> 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.

A track is an entry in halbum. It is not specified in the haudio schema
because we haven't had enough people agree/disagree with the concept. We
are still discussing it. In general, a track is "a containing element
for haudio that specifies that it is a part of an album".

> Fourth, this outline seems inconsistent with what is current on the wiki.

The album/track discussions are in far too great a state of flux to
document it on the wiki. Once we come to some sort of rough consensus,
we can put something up there.

>>> . 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?

Just a simple miscommunication. I didn't mean "we don't need tracks" - I
meant "tracks go with albums, and I've already stated my position on that".

>> 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. 

That is correct. We are concentrating on describing information about
the audio recording. We are not dealing with describing files - that
discussion is part of the file format exploratory discussion:

http://microformats.org/wiki/file-format-examples

In the future, we may use file-format in haudio. However, for this
release of haudio, we're more narrowly focused.

> 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?

<div class="haudio">
 <span class="fn">A Song</span>
 <a rel="sample" href="sample/asong">Sample</a>
 <a rel="enclosure" href="/song-realplayer-low-quality.ra">
   Download Low Quality Realplayer File
 </a>
 <a rel="enclosure" href="/song-wma-high-quality.wma">
   Download High Quality WMA File
 </a>
</div>

Can we please split this discussion into two threads?

hPlaylist
hAlbums

-- manu