[uf-new] hAudio - audio-album and audio-podcast
scott at makedatamakesense.com
Wed Jun 6 07:52:11 PDT 2007
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,
>>> "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.
> Why should we do the above, when something much simpler would solve
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:
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
> draft of audio-info seems to be done.
> Nobody seems to have raised any
> issues related to existing elements in the haudio draft in several
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.
More information about the microformats-new