[uf-new] hAudio ITEM/TRACK debate resolution

[Scott Reynen]

On Oct 21, 2007, at 10:01 AM, Manu Sporny wrote:

> First, let me state that hAudio is about "audio recordings", of which
> tracks and albums are a subset.

This is a crucial point.  As long as you continue to treat the root  
class meaning as something more specific than "audio recording," it  
won't make much sense.

> While we have borrowed some design elements from hReview and hCard, we
> should not get confused between the various Microformats and hAudio.

Indeed, I used other microformats as references for basic design  
structures, not to imply that anything about hAudio should affect  
those.  That was apparently more confusing than helpful.  The fact  
that it may make no sense to nest one hFeed inside another is  
completely irrelevant to whether or not it makes sense to nest one  
audio recording within another.  The publishing examples suggest  
audio nesting makes sense, and any opposition to this model should be  
based on the real-world examples, not on hypothetical applications of  
the model to concepts that are completely out of scope.

> Brian Suda wrote:
>> If that is so, then FN is NOT needed.
>
> FN is needed because the examples show that both album and song  
> name are
> listed on a page next to each other. Such as when a blogger talks  
> about
> a song that is a part of an album. This is done quite often on the
> hundreds of music blogs[1] on the 'net. For a specific example of this
> happening, check out Scissorkick[2], which usually lists songs and
> albums together.
>
> Additionally, ID3v1 and just about every other audio metadata tagging
> standard has the ability to specify the album name and the song  
> name. We
> have plenty of examples[3] and metadata formats[4] that support this
> approach.

We also have plenty of examples in which one audio element ("album")  
is mentioned only once and treated as a container for several other  
audio elements ("tracks").  Both methods of organizing this  
information are common and the model needs to address both, as it  
currently does.  It would be nice if we could simply use one or the  
other, but we shouldn't do that at the expense of not covering a  
significant portion of the examples.  If you look at most popular  
applications for collecting audio (e.g. iTunes), you'll find both  
organization methods are present.  In some views, tracks are listed  
with album names as a property, in others, albums are listed as  
containers for track names.  Luckily HTML allows us to easily put one  
element inside another, so this duality of relationships between  
track and album isn't really complicated, unless of course you  
approach it assuming a simpler model than the examples actually imply.

> We are doing this because this structure is inherent in almost every
> audio example collected to date. hAudio is about audio recordings,  
> audio
> recordings have parts that people specify, be it tracks, sections,
> movements, etc. hAudio is not hCard.

At the risk of further confusing matters, hCard actually nests one  
person within another using the "agent" property, so it's not like  
this is a completely new concept.  But hAudio is not a general  
proposal that anything should be nestable inside anything else.  It's  
very specific to audio inside audio, and that nesting-inside-same- 
type is very specific to the nature of audio.

> Why is attempting to do something that no other microformat does a bad
> thing?

Following precedent is important, but hAudio is very much doing  
that.  The only things hAudio is attempting that are new are  
completely audio-specific, so there is of course no precedent in  
other microformats.  We can take the *general* concept of nesting  
from other microformats (or more basically from HTML itself), but we  
can't take anything about the *specifics* of nesting audio within  
audio from them, nor does it make any sense to take that audio- 
specific proposal and apply it more generally.

> It is true that no other Microformat does
> sections/collections/parts.

I disagree.  XOXO does that.  hAtom does that.  hCalendar does that.   
No other microformat does that with audio within audio, of course,  
but that's an implied schema found in the audio publishing examples.   
We're not just making stuff up.

--
Scott Reynen
MakeDataMakeSense.com