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

[Scott Reynen]

On Jun 5, 2007, at 6:46 PM, Manu Sporny wrote:

> Scott Reynen wrote:
>> On Jun 5, 2007, at 4:00 PM, Colin Barrett wrote:
>>> A classical recording is a good example -- unlike popular music, the
>>> tracks on the album are often merely segments of a larger whole,  
>>> f.e.
>>> "Beethoven's Fifth" is comprised of four movements. All of the same
>>> information that can be applied to a "track" can be applied to an
>>> "album" or "playlist". They're really just divisions of a larger
>>> whole. The only information I could see an album of playlist needing
>>> that a track wouldn't would be: # of tracks and # of discs.
>>
>> If that's the case, what do we gain from using separate terms for
>> "album" and "track"?  Either it's useful to distinguish between  
>> the two
>> with labels, or it's not.
>
> "album", "summary", and "track", when combined with "haudio", are more
> semantically accurate when describing audio albums. They add semantic
> specificity to "haudio" which is needed to differentiate haudio that
> describes an album, and an haudio that describes a track.

We shouldn't need to combine terms to arrive at semantic accuracy.   
Each individual term should describe a specific, easily understood  
concept by itself.  For example, fn describes a name.  We all know  
what a name is.  "haudio," on the other hand, currently describes a  
collection of metadata about some type of audio.  It's not clear what  
that really means outside the context of "album" or "track."  I don't  
think "I'm going to publish an haudio on my website."  I think "I'm  
going to publish a track on my website" or "I'm going to publish an  
album on my website."  Where are the examples of something that would  
be "haudio" being published with no album or track?  I'm not finding  
any such examples in the wiki.

> I believe that Colin (and I) are arguing against complicating  
> halbum any
> more than necessary:

Right, me too.  We just disagree about what is complicated.

> halbum
> 	title
> 	contributor
> 	image-summary
> 	duration
> 	payment
>
> Why should we do the above, when something much simpler would solve  
> the
> problem:
>
> halbum
>    summary
>       haudio

In my view, that's not simpler; it's just fewer concepts.  "haudio"  
is a new concept, which publishers don't currently understand, so  
we'd need to explain what it means, which is basically "title,"  
"contributor," "image-summary," etc.  I see no reason they should  
need to learn a new concept for the container of all those already- 
understood concepts.  That you are able to look at "haudio" and  
understand "title," "contributor," etc. does not mean that anyone  
else will be able to do the same.  What you're actually asking  
publishers to understand and publish is this:

halbum
    summary
       haudio
          title
          contributor
          image-summary
          duration
          payment

Which I think is clearly more work for publishers than the same  
schema without the additional layers of "summary" and "haudio."   
Also, I think those layers are poor semantics.  We're not talking  
about the title of an haudio of a summary of an album.  We're talking  
about the title of an album, and the markup should clearly reflect that.

On Jun 6, 2007, at 1:43 AM, Joe Andrieu wrote:

> Why don't we stop worrying about albums and just solve audio-info?

I think this is a great idea.

On Jun 6, 2007, at 8:22 AM, Manu Sporny wrote:

> The reason that we are focusing on albums right now is because the  
> first
> draft of audio-info seems to be done.

I disagree.

> Nobody seems to have raised any
> issues related to existing elements in the haudio draft in several  
> weeks.

I don't know how you can possibly think that.  Multiple people have  
suggested changing the wiki entry in just the last few days, and  
you've said you don't think it should change because there's not  
enough consensus.  Now you're saying there's complete consensus?  I  
still don't understand what exactly class="haudio" means.  That's  
hardly a minor issue.

--
Scott Reynen
MakeDataMakeSense.com