[uf-new] hAudio ITEM/TRACK debate resolution

[Scott Reynen]

On Oct 20, 2007, at 3:03 PM, Brian Suda wrote:

>> The above seems to be based on a brand new idea of how we determine
>> the difference between an album and a track.  We've been assuming
>> until now that hAudio is a track by default.
>
> --- fair enough, the problem then is that we seem to have a problem
> with focus on what we are trying to achieve. This thread is called
> "ITEM/TRACK debate" if hAudio is track by default, then what is the
> debate?

The debate is specific to the non-default (but still worth covering)  
case where the audio is an album.  We'd already settled on a syntax  
for declaring that, the equivalent of hCard's syntax for declaring an  
organization (if the name is the album, it's an album).  The question  
was how we label the tracks within an album.  Until your proposal, we  
were all addressing that question from a common assumption of how the  
album itself is identified.

> If haudio is ONLY about tracks

It's not.  The model is almost entirely analogous to hCard:

hAudio is about audio.
The default type of audio is a track.
If the album and fn are the same, it's the non-default type: an album.

hCard is about contacts.
The default type of contact is an individual.
If the org and fn are the same, it's the non-default type: an  
organization.

>> This seems to be
>> supported by the examples, in which there are many more tracks than
>> albums.
>
> --- if that is the case, then we should NOT use haudio as the root
> class name to mean a collection of audio stuff

See above.  If you still think it's wrong to use hAudio for both  
album and track, please explain why you think this should differ from  
hCard's model.

> -- there seems to be two ways we COULD represent albums. #1 assuming
> all tracks are in an album and use /haudio/item/fn for just tracks
> that way we COULD have /haudio/fn and /haudio/item/fn to give an album
> name and a track name.... or #2 we could invert the relationship, and
> use /haudio/fn to be the track name an have /haudio/collection to
> associate an track to an album or podcast or something.

Or #3, we could recognize that when the audio's name is the same as  
the album's name, the audio is an album, without requiring an  
explicit statement from publishers.  This solution removes the main  
problem with both #1 and #2 above: unnecessary declaration of  
containers or items that may not even exist.

> --- right, ORG would be analigous to option #2 where you explicitly
> list the ALBUM. The downside is that if there are 2 track (like 20
> people) the (ORG or ALBUM) would have to be repeated 20 times.

Why?  HTML nesting semantics already indicate containers.  Similarly,  
hAtom doesn't repeat the feed 20 times for 20 entries.  I think the  
basic model is to follow hCard for differentiating between container  
type and item type, and follow hAtom for relating containers to items.

>> Tracks are more common, so why shouldn't we assume tracks?
>
> --- i would think so, but the examples in this email seems to suggest
> otherwise.

I think you're misreading them, possibly assuming hAudio is about  
either album or track, when it's actually about recorded audio,  
including both albums and tracks.

> I think we need a clarification of the goals.

I think much of the problem here is that the wiki proposal isn't up  
to date with email discussions.

> I'm happy to make the default assumption TRACK rather than ALBUM. Then
> i would say the original examples in this would have to be:
>
> Album with two tracks, simple example:
>
> <span class="haudio">
>    <span class="fn>Hokkaido Dream</span>
>    <span class="collection">Best Before 1984</span>
>    <span class="contributor">Crass</span>
> </span>
>
> <span class="haudio">
>    <span class="fn">Tokyo Groove</span>
>    <span class="collection">Best Before 1984</span>
>    <span class="contributor">Crass</span>
> </span>

That's pretty much exactly what everyone's agreed to, except we're  
using "album" instead of "collection."  If you think this should  
change, please explain why.

> Album with two tracks, more detailed:
>
> <span class="haudio">
>    <span class="fn>Hokkaido Dream</span>
>     <abbr class="duration" title="PT3M24S">3:24</abbr>
>    <span class="collection">Best Before 1984</span>
>    <span class="contributor">Crass</span>
> </span>
>
> <span class="haudio">
>    <span class="fn">Tokyo Groove</span>
>    <span class="collection">Best Before 1984</span>
>    <span class="contributor">Crass</span>
>     <abbr class="duration" title="PT4M46S">4:46</abbr>
> </span>

This, on the other hand, is very different.  The examples don't show  
publishers repeating album names, so the model needs to accommodate  
this.  We've been talking about something more like this:

<span class="haudio">
	<span class="album fn">Best Before 1984</span>
	<span class="contributor">Crass</span>

	<span class="item">
		<span class="fn">Hokkaido Dream</span>
		<abbr class="duration" title="PT3M24S">3:24</abbr>
	</span>

	<span class="item">
		<span class="fn">Tokyo Groove</span>
		<abbr class="duration" title="PT4M46S">4:46</abbr>
	</span>
</span>

Alternately, each class="item" could be class="item haudio", if  
necessary.  That's what we were discussing, all under the assumption  
that the relationship between tracks and albums would be determined  
by HTML containment.  Your proposal does not share this assumption,  
and I'm still not sure if that's because you see something wrong with  
it, or you just didn't understand it before.  If the former, please  
explain.  If the latter, I hope it's clear now.

> They would need to be two distinct haudio items because haudio models
> TRACKs not albums.

hAudio models audio, which includes both tracks and albums.   
Similarly, hCard models contacts, which includes both people and  
organizations.

> The duplicate data could be solved with the
> include-pattern.

It could be, but I think it's simpler to use HTML's existing  
containment semantics, as hAtom does.

--
Scott Reynen
MakeDataMakeSense.com