[uf-new] hAudio ITEM/TRACK debate resolution
scott at makedatamakesense.com
Sun Oct 21 10:08:51 PDT 2007
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
> a song that is a part of an album. This is done quite often on the
> hundreds of music blogs on the 'net. For a specific example of this
> happening, check out Scissorkick, 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 and metadata formats that support this
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,
> 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
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
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.
More information about the microformats-new