On Jun 5, 2007, at 4:50 AM, Martin McEvoy wrote:
On Mon, 2007-06-04 at 20:42 -0600, Scott Reynen wrote:
On Jun 4, 2007, at 6:33 PM, Joe Andrieu wrote:
The alternative to the above that I thought you were going for was
something like this:
halbum
playlist/XOXO
haudio
haudio
haudio
haudio
That makes sense to me.
How so?
Well, I know what albums are, I know what playlists are, and I know
what audio files are, so this is describing familiar concepts,
specifically the concepts I thought we were trying to model.
example of the proposed method:
halbum
haudio [album title,contributor,image-summary, duration, payment]
xoxo
track
haudio [track 1, duration, sample]
track
haudio [track 2, duration, sample]
track
haudio [track 3 duration, sample]
what doesn't make sense here? guys.
The label "haudio" appears to be describing two distinct concepts
here (1: album information, 2: individual track information), which I
find confusing. That these two concepts share some properties, but
that doesn't make them the same thing. I think there are two many
layers of abstraction here. "haudio" should describe something
specific, e.g. an audio recording, not a vague collection of metadata
that could apply to a wide variety of things.
The only possible argument here would be ...
Here's the argument I'm making, impossible though you may deem it:
I'm confused, and microformats should not be confusing.
so Now it becomes useful to define which track is music and which is
video or Images.
I'd say if "track" isn't clearly specific to audio, haudio should use
a different label which is clearly specific to audio, as that's all
haudio is about.
example
halbum
haudio [album title,contributor,image-summary, duration, payment]
maybe you do have a point though in the context of just an album
description hAudio becomes a little redundant as this is indeed
nothing
that is Audio just a description of audio maybe this is better:
halbum
summary [album title,contributor,image-summary, duration, payment]
It seems to me we're talking about the title, contributor, etc. *of
the album*, not of the summary of the album, nor of the "haudio" of
the album. So I don't see the value of an intermediate container
here. So I would suggest the following schema for album information,
placing the properties directly within the album container:
halbum
title
contributor
image-summary
duration
payment
http://www.xspf.org/orig-xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.8
All of the terms there seem to be audio-specific. I think all of the
terms in haudio should be similarly audio-specific.
On Jun 5, 2007, at 7:58 AM, Manu Sporny wrote:
hAudio describes information about an audio recording.
I would suggest that an album is not an audio recording; it's a
series of audio recordings. So if hAudio is about audio recordings,
it shouldn't be used to describe albums. And I would also suggest
that the term "track" describes an audio recording, so using both
"haudio" and "track" seems largely redundant here.
The first haudio describes the album - which is why it is encased in a
'summary' tag.
If it describes the album, why isn't it encased in the "halbum"
element? Isn't that the most obvious place to put something that
describes the album? The "summary" class seems completely
meaningless here. What exactly would we lose by taking it out?
halbum is the grouping Microformat for audio albums specifically - it
can aggregate a number of haudio recordings together.
"halbum" is the grouping of albums? I'm guessing this is a
miscommunication, as I've seen no previous discussion of groups of
albums. Please clarify.
With the current approach it would be like this:
<ol class="xoxo">
<li>
<div class="haudio">
<span class="fn">Black Horse & The Cherry Tree</span>
</div>
</li>
<li>
<div class="haudio">
<span class="fn">One Day [Live]</span>
</div>
</li>
</ol>
I think the <div>s here are unnecessary markup, which we should avoid
as much as possible. We can apply classes to <li>s:
<ol class="xoxo">
<li class="haudio">
<span class="fn">Black Horse & The Cherry Tree</span>
</li>
<li class="haudio">
<span class="fn">One Day [Live]</span>
</li>
</ol>
A track is an entry in halbum. It is not specified in the haudio
schema
because we haven't had enough people agree/disagree with the concept.
I disagree with the concept. Any "haudio" element within an "halbum"
element should be considered part of the album. I see no need for an
additional concept here.
The album/track discussions are in far too great a state of flux to
document it on the wiki. Once we come to some sort of rough consensus,
we can put something up there.
I disagree. The whole point of the wiki is to allow us to quickly
iterate the documents. If there's no consensus, put it in the wiki
under -brainstorming. Having something in the wiki where we can all
reference it is very helpful in clarifying ideas.
On Jun 5, 2007, at 8:49 AM, Manu Sporny wrote:
hmm problem here, what if our album has multiple content types not
all
albums are just playable music yes?
I think what both Scott and Joe are referring to are "audio
albums". We
aren't talking about "video albums" or "multimedia albums". We should
concentrate on solving the audio album problem.
Indeed, if "album" isn't audio-specific, haudio should use something
that *is* audio-specific, since audio is the focus of haudio.
The reason 'summary' was included in halbum is because the
audio-info-examples demonstrate that we need a way to specify album
name, artist, publish date, cover image, sample links and a variety of
other things related to both albums and tracks. It makes sense to just
use haudio to describe those things because the haudio proposal
already
contains all that information.
I disagree. hCard already includes fn, but we don't use hCard
everywhere we want to use fn because using hCard so indiscriminately
would make it less meaningful. I think haudio should describe a
specific recording of audio only, not a collection of recordings of
audio. If some of the properties of a recording happen to also be
properties of a collection of recordings, we should use those
properties without resorting to abstract concepts.
--
Scott Reynen
MakeDataMakeSense.com
_______________________________________________
microformats-new mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-new
