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
_______________________________________________
microformats-new mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-new
