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

[Scott Reynen]

On Jun 5, 2007, at 4:50 AM, Martin McEvoy wrote:

> On Mon, 2007-06-04 at 20:42 -0600, Scott Reynen wrote:
>> On Jun 4, 2007, at 6:33 PM, Joe Andrieu wrote:
>>
>>> The alternative to the above that I thought you were going for was
>>> something like this:
>>>
>>> halbum
>>> 	playlist/XOXO
>>> 		haudio
>>> 		haudio
>>> 		haudio
>>> 		haudio
>>
>> That makes sense to me.
>
> How so?

Well, I know what albums are, I know what playlists are, and I know  
what audio files are, so this is describing familiar concepts,  
specifically the concepts I thought we were trying to model.

> example of the proposed method:
>
> halbum
>    haudio [album title,contributor,image-summary, duration, payment]
>         xoxo
>           track
>                haudio [track 1, duration, sample]
>           track
>                haudio [track 2, duration, sample]
>           track
>                haudio [track 3 duration, sample]
>
> what doesn't make sense here? guys.

The label "haudio" appears to be describing two distinct concepts  
here (1: album information, 2: individual track information), which I  
find confusing.  That these two concepts share some properties, but  
that doesn't make them the same thing.  I think there are two many  
layers of abstraction here.  "haudio" should describe something  
specific, e.g. an audio recording, not a vague collection of metadata  
that could apply to a wide variety of things.

> The only possible argument here would be ...

Here's the argument I'm making, impossible though you may deem it:  
I'm confused, and microformats should not be confusing.

> so Now it becomes useful to define which track is music and which is
> video or Images.

I'd say if "track" isn't clearly specific to audio, haudio should use  
a different label which is clearly specific to audio, as that's all  
haudio is about.

> example
>
> halbum
>    haudio [album title,contributor,image-summary, duration, payment]
>
> maybe you do have a point though in the context of just an album
> description hAudio becomes a little redundant as this is indeed  
> nothing
> that is Audio just a description of audio maybe this is better:
>
> halbum
>    summary [album title,contributor,image-summary, duration, payment]

It seems to me we're talking about the title, contributor, etc. *of  
the album*, not of the summary of the album, nor of the "haudio" of  
the album.  So I don't see the value of an intermediate container  
here.  So I would suggest the following schema for album information,  
placing the properties directly within the album container:

halbum
	title
	contributor
	image-summary
	duration
	payment


> http://www.xspf.org/orig-xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.8

All of the terms there seem to be audio-specific.  I think all of the  
terms in haudio should be similarly audio-specific.

On Jun 5, 2007, at 7:58 AM, Manu Sporny wrote:

> hAudio describes information about an audio recording.

I would suggest that an album is not an audio recording; it's a  
series of audio recordings.  So if hAudio is about audio recordings,  
it shouldn't be used to describe albums.  And I would also suggest  
that the term "track" describes an audio recording, so using both  
"haudio" and "track" seems largely redundant here.

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

If it describes the album, why isn't it encased in the "halbum"  
element?  Isn't that the most obvious place to put something that  
describes the album?  The "summary" class seems completely  
meaningless here.  What exactly would we lose by taking it out?

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

"halbum" is the grouping of albums?  I'm guessing this is a  
miscommunication, as I've seen no previous discussion of groups of  
albums.  Please clarify.

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

I think the <div>s here are unnecessary markup, which we should avoid  
as much as possible.  We can apply classes to <li>s:

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

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

I disagree with the concept.  Any "haudio" element within an "halbum"  
element should be considered part of the album.  I see no need for an  
additional concept here.

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

I disagree.  The whole point of the wiki is to allow us to quickly  
iterate the documents.  If there's no consensus, put it in the wiki  
under -brainstorming.  Having something in the wiki where we can all  
reference it is very helpful in clarifying ideas.

On Jun 5, 2007, at 8:49 AM, Manu Sporny wrote:

>> hmm problem here, what if our album has multiple content types not  
>> all
>> albums are just playable music yes?
>
> I think what both Scott and Joe are referring to are "audio  
> albums". We
> aren't talking about "video albums" or "multimedia albums". We should
> concentrate on solving the audio album problem.

Indeed, if "album" isn't audio-specific, haudio should use something  
that *is* audio-specific, since audio is the focus of haudio.

> The reason 'summary' was included in halbum is because the
> audio-info-examples demonstrate that we need a way to specify album
> name, artist, publish date, cover image, sample links and a variety of
> other things related to both albums and tracks. It makes sense to just
> use haudio to describe those things because the haudio proposal  
> already
> contains all that information.

I disagree.  hCard already includes fn, but we don't use hCard  
everywhere we want to use fn because using hCard so indiscriminately  
would make it less meaningful.  I think haudio should describe a  
specific recording of audio only, not a collection of recordings of  
audio.  If some of the properties of a recording happen to also be  
properties of a collection of recordings, we should use those  
properties without resorting to abstract concepts.

--
Scott Reynen
MakeDataMakeSense.com