From joe at andrieu.net  Fri Jun  1 02:41:51 2007
From: joe at andrieu.net (Joe Andrieu)
Date: Fri Jun  1 02:41:56 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <15996c030705312155i612de695kddf20a3ebea5c989@mail.gmail.com>
Message-ID: <00d801c7a431$164434f0$11fa030a@andrieuhome>

Chris Griego wrote:
> On 5/31/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> > > Your use of audio-album could cause problems later in the 
> semantic 
> > > meaning, iTunes has many celebrity playlists, which are 
> not actually 
> > > ALBUMS, but are a collection of related songs. The term podcast 
> > > seems very 2005, in 4 years will we still use 'podcats' 
> maybe, maybe 
> > > not?
> >
> > We're not concerned with what might happen in the future. We're 
> > concerned with what's already there - the cow paths. The two major 
> > types of grouping in the audio-examples are podcasts and albums.
> 
> Albums, podcasts, whatever, aren't they all forms of 
> playlists? haudio with opional hplaylist?

Not unless you can provide examples of them being display on the web as the same thing.

Albums suggest semantics as as a particular "publication", with a date, a title, cover art, publisher, artist, etc.

Playlists may or may not ever have been "published" in the traditional sense, especially personal playlists. A playlist /could/ just
be a list of audio clips without a dereferenceable link to the streams themselves. Note that FIQL[1] offers auto-play in Napster and
Rhapsody, but rarely of all the songs in the list are playable.

Podcasts are really just a single chunk of audio offered as a "cast". It /does/ contain or reference an URL to listen to the audio
(or at least the URL where it was once available). They are "published" in the sense of being created and/or offered for consumption
on a particular date.

I would argue that a podcast is, in particular, a conceptually complete downloadable audio "performance".  That term may evolve, but
the concept is pretty stable and "podcast" is unique enough that it might survive. They usually have an artist and creator, but
"publishers" are optional. I suppose NPR acts as a publisher, but many podcasts are self-published.

Albums on the other hand are complete audio collections published /as a unit/ with associated meta-media and meta-data like cover
art, publisher, artist, etc.. They are typically of multiple songs, usually by a single artist, but not always. 

Three very different things.

>From reviewing the examples [2], I think there are five distinct semantic items here, at a minimum: 
	album
	playlist
	track
	audiofile
	podcast

Looking at the Beatle's White Album at Amazon [3] also had two discs. Not an uncommon situation. Each disk had its own playlist. At
wikipedia [4], the same album had four sides, each with its own playlist.

Some more atomic than others, but I think the overlap is entirely constructive if organize correctly.

Here's my brief thinking about how these fit together:
o An album contains one or more playlists plus album meta-data (release-date, etc.) and potential meta-media (album cover, etc.)
o A playlist is a list of tracks, plus perhaps meta-data such as genre, creator, etc.
o A track specifies a particular audio clip: length, author, title, etc. It may point to zero or more audio files for those tracks. 
o An audiofile is a particular media file specifying format, URL, etc.
o A podcast is an audiofile plus publication meta-data such as publisher, release date, etc.

Any of these /entities/ could have a number of attributes.

Reviewing the proposed spec, it seems like all five of these entities are being jammed into one hAudio, which means I can't tell
which is a track or a podcast, which means a loss of semantic information.  It would also allow you to put an album inside a track,
inside a podcast. Kind of like a riddle wrapped in a puzzle wrapped in an enigma.

Using Amazon's structure for the moment how about something like this instead:
<div class="hAudio">
 <div class="album">
  <h1 class="title">The White Album</h1>
  <div class="release-date">22 November 1968</div>
  <h2 class="artist">The Beatles</h2>
   <div class="playlist">
    <h3 class="disc">Disc: 1</h3>
    <ol>
     <li class="track"><span class="trackTitle">Back in the U.S.S.R.</span> - <span class="duration">2:43</span></li>
     <li class="track"><span class="trackTitle">Dear Prudence</span> - <span class="duration">3:56</span></li>
     ...
    </ol>
   </div>
   <div class="playlist">
    <h3 class="disc">Disc: 2</h3>
    <ol>
     <li class="track"><span class="trackTitle">Birthday</span> - <span class="duration">2:42</span></li>
     <li class="track"><span class="trackTitle">Yer Blues</span> - <span class="duration">4:00</span></li>
     ...
    </ol>
   </div>
  </div>
</div>

Obviously, the attributes are just placeholders. I'm not sure if "fn" should be applied to The Beatles in this case, as they are not
a "person", but I expect others will find that acceptable. I do however like that "disc" as a potential part of "album" indicates
that this album is a CD, which a "side" would indicate vinyl. And I don't even want to get into the Date/ISO/ABBR issue, so just
replace the "release-date" with whatever semantics you prefer.

By being explicit about the "grouping" by using album and disc, we retain a lot of the semantic information that is visually obvious
to a human when looking at the page at Amazon or Wikipedia. Dump the above into an html file and you'll see it is quite legible. I
also think it is easier to understand and author.

Note that in the Amazon case, the playlists do not provide links to audio files.


Good list of examples, btw. I appreciated the work you've already done. It helped me understand what you are trying to do. Thanks to
those who have contributed to that.

-j

[1] http://www.fiql.com/
[2] http://microformats.org/wiki/audio-info-examples
[3] http://www.amazon.com/Beatles-White-Album/dp/B000002UAX

--
Joe Andrieu
SwitchBook Software
http://www.switchbook.com
joe@switchbook.com
+1 (805) 705-8651 


From martin at weborganics.co.uk  Fri Jun  1 05:30:57 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Jun  1 05:29:46 2007
Subject: [uf-new] Sound Optimization for haudio
Message-ID: <1180701057.3230.1.camel@localhost.localdomain>

Hello All

Can Anyone explain to me how to use the "sound" optimization in hcard
from what I can gather from 

http://www.ietf.org/rfc/rfc2426 section 3.6.6 SOUND Type Definition
I quote...

   Type purpose: To specify a digital sound content information that
   annotates some aspect of the vCard. By default this type is used to
   specify the proper pronunciation of the name type value of the vCard.

...so you know where I am going with this I think It may be a useful
addition to hAudio so we can point out which part of a hAudio is the
title of an album and which part is a track, an example borrowed from
joes on the list:

<div class="haudio">
 <h1 class="vcard">
	 <span class="contributor org">The Beatles</span> - 
		 <span class="fn">The White Album</span></h1>
		 
<div class="haudio vcard">
<h2 class="fn">Disc: 1</h2>
<ol>
	<li class="sound">Back in the U.S.S.R. - <span class="duration">2:43</span></li>
	<li class="sound">Dear Prudence- <span class="duration">3:56</span></li>
</ol>
</div>	
<div class="haudio vcard">	
<h2  class="fn">Disc: 2</h2>
<ol>
      <li class="sound">Birthday - <span class="duration">2:42</span></li>
      <li class="sound">Yer Blues - <span class="duration">4:00</span></li>
</ol>
</div>
</div>


Can we use the sound optimization in a class or does it have to have a
type attribute type-sound?

I have used the "org" optimization because bands can be organizations
and it helps determine the artist from the title?.
 
Notice I have nested multiple hAudios in a single hAudio to imply that
this is a Playlist 

Guidance help please or again just tell me its not possible ;)

-Martin-



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2171 bytes
Desc: not available
Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070601/7df7c4d2/smime.bin
From brian.suda at gmail.com  Fri Jun  1 07:04:10 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Fri Jun  1 07:04:13 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <465F2FDC.1060308@digitalbazaar.com>
References: <465E32ED.4040609@digitalbazaar.com>
	<21e770780705310556t37dc0b3eyd9a8314df1a04a24@mail.gmail.com>
	<465F2FDC.1060308@digitalbazaar.com>
Message-ID: <21e770780706010704u3f61bf4eo8af68a455cd517c@mail.gmail.com>

On 5/31/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> > What ever happened to working on the media-format?
>
> The media-format was far too broad of a problem - that's why it hasn't
> moved forward in two years even though there are a great number of
> examples of marking up media on the web. It is far easier to break the
> problem up into audio, video and images and tackle those individually:

--- i would disagree, the Dublin Core group spent many many years and
narrowed down the base Metadata to 14 (i think) values. When people
propose these new microformats each one wants their little pet-project
portion of metadata to get into the new format. In the most basic
sense all the media has a creator and some additional metadata. They
might be different types of formats, but the metadata is the pretty
much the same. I just think there was either, no interest in
developing the format, or too many "what if we add this" happened and
it never moved forward.

> Those are different problems - we aren't addressing those problems with
> this Microformat. We have a very specific problem statement for audio-info:

The problem statement reads:
"It is difficult for a browser to extract semantic information about
an audio recording described on a web page. Metadata such as speaker,
musician, publisher, label, title of the work, release date,
acquisition link, related image artwork and tags provide relevant
context for the audio recording."

with the exception of "audio recording" the could apply to any media
format. I don't feel it is that specific for audio.


> We should stick to the small problem and solve that - not make it bigger
> and more complicated (boiling the oceans).

--- correct, but this doesn't have to mean what formats it
encompasses, but the scope of the problem. It shouldn't attempt to
have every possible metadata property possible - i agree that is
boiling the ocean, but if the same 4-5 metadata properties can apply
to multiple formats we should keep that in mind, and i think we have
done a good job to keep the scope focused on just the minimal amount
of metadata properities needed. I just feel these same properties can
simultaniously apply to multiple things.

> Could you expand on this idea please? I want to make sure I understand
> you correctly. I'm fine with the concept of non-hyphenated names, are
> you suggesting something along the lines of:
>
> album
>    description
>       haudio
>    track
>       haudio
>    track
>       haudio

--- You could have some overarching container, lets call that
something like "media". That has meta data, much like hfeed.

media
  tags, decription, contributer, ...

then, nested in that media is individual items, much like hentry in an hfeed.

media
  tags, description, contributer, ...
  track
  track
  track
  chapter

each of those items (track, chapter, ...) contain additional metadata
about themselves.

media
  tags, description, contributer, ...
  track
    duration, title, author, price, ...
  chapter
    duration, title, author, price, type, ...

> > Last i remember the hAudio proposal basically broke down to just an
> > hReview with a price and a running time.
>
> The semantics of audio-info are very different from the semantics of a
> review. The following are required for audio info (based on the analysis
> and brainstorming done by this list): fn, contributor, published-date,
> rel-sample (samples), rel-enclosure (full versions), rel-payment
> (purchase option), image-summary, category, duration, and price - hardly
> any of those overlap with hReview.

hm, hreview has fn, so does this proposal, it has published-date just
like this proposal, it has an image just like this proposal, it has
tags just like this proposal's category, hreview has URL which could
be used as the download links... like i originally said, it basically
broken down to many of the same values in hReview, with the addition
of price and duration.

The only value required for an hReview is the FN. Then we got all
side-tracked with a grouping issue.

One of the first steps in proposing a microformat is to see if an
existing microformat could fit. After spending along time on the
mailing list, simply suggesting things, the whole conversation
bascially was pulled back to hReview. Has anyone attempted to simply
mark-up their data using hReview with a price and duration (which is
already a solved problem in hCalendar)?

Lets try to keep this MICRO and not go wild attempting to layer more
and more data into hAudio/Media-format.

-brian

-- 
brian suda
http://suda.co.uk
From joe at andrieu.net  Fri Jun  1 12:14:10 2007
From: joe at andrieu.net (Joe Andrieu)
Date: Fri Jun  1 12:14:15 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <21e770780706010704u3f61bf4eo8af68a455cd517c@mail.gmail.com>
Message-ID: <011401c7a481$09862070$11fa030a@andrieuhome>

Brian Suda wrote:
> On 5/31/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> > > What ever happened to working on the media-format?
> >
> > The media-format was far too broad of a problem - that's 
> why it hasn't 
> > moved forward in two years even though there are a great number of 
> > examples of marking up media on the web. It is far easier 
> to break the 
> > problem up into audio, video and images and tackle those 
> individually:
> 
> --- i would disagree, the Dublin Core group spent many many 
> years and narrowed down the base Metadata to 14 (i think) 
> values. When people propose these new microformats each one 
> wants their little pet-project portion of metadata to get 
> into the new format. In the most basic sense all the media 
> has a creator and some additional metadata. They might be 
> different types of formats, but the metadata is the pretty 
> much the same. I just think there was either, no interest in 
> developing the format, or too many "what if we add this" 
> happened and it never moved forward.
> 
> > Those are different problems - we aren't addressing those problems 
> > with this Microformat. We have a very specific problem 
> statement for 
> > audio-info:
> 
> The problem statement reads:
> "It is difficult for a browser to extract semantic 
> information about an audio recording described on a web page. 
> Metadata such as speaker, musician, publisher, label, title 
> of the work, release date, acquisition link, related image 
> artwork and tags provide relevant context for the audio recording."
> 
> with the exception of "audio recording" the could apply to 
> any media format. I don't feel it is that specific for audio.

This is true, but doesn't that suggest simply that the atomic elements for different media should be reused? Overgeneralizing loses
semantic information. Sure, it's "hMedia", but don't we still need to distinguish between albums and movies?

In other words, which is it better to say (structurally)

hMedia mediatype=Audio
	meta-data: type=album, title, creator, publisher, release-date, duration, genre
	data=track1, track2

hMedia mediatype=video
	meta-data: type=movie, title, creator, publisher, release-date, duration, genre
	data=moviefile

Than

hAudio 
	meta-data=album, title, creator, publisher, release-date, duration, genre
	data=track1, track2

And 

hVideo
	meta-data: type=movie, title, creator, publisher, release-date, duration, genre
	data=moviefile


It seems that these two (conceptual) structures encode the same semantics. But hMedia requires solving for all the media types,
which has already proven to be a problem.

> > We should stick to the small problem and solve that - not make it 
> > bigger and more complicated (boiling the oceans).
> 
> --- correct, but this doesn't have to mean what formats it 
> encompasses, but the scope of the problem. It shouldn't 
> attempt to have every possible metadata property possible - i 
> agree that is boiling the ocean, but if the same 4-5 metadata 
> properties can apply to multiple formats we should keep that 
> in mind, and i think we have done a good job to keep the 
> scope focused on just the minimal amount of metadata 
> properities needed. I just feel these same properties can 
> simultaniously apply to multiple things.

I would recommend that we address hAudio as a limited domain first. There is a lot of work and traction here. Get it to a mature
spec, then consider what it would take to make a similar hVideo and maybe hBook or similar. Then we can evaluate if an hMedia makes
sense. 

> > Could you expand on this idea please? I want to make sure I 
> understand 
> > you correctly. I'm fine with the concept of non-hyphenated 
> names, are 
> > you suggesting something along the lines of:
> >
> > album
> >    description
> >       haudio
> >    track
> >       haudio
> >    track
> >       haudio
> 
> --- You could have some overarching container, lets call that 
> something like "media". That has meta data, much like hfeed.
> 
> media
>   tags, decription, contributer, ...
> 
> then, nested in that media is individual items, much like 
> hentry in an hfeed.
> 
> media
>   tags, description, contributer, ...
>   track
>   track
>   track
>   chapter
> 
> each of those items (track, chapter, ...) contain additional 
> metadata about themselves.
> 
> media
>   tags, description, contributer, ...
>   track
>     duration, title, author, price, ...
>   chapter
>     duration, title, author, price, type, ...
> 
> > > Last i remember the hAudio proposal basically broke down 
> to just an 
> > > hReview with a price and a running time.

Also plus the clarification that it /is/ audio, and less the actual review, reviewer, and rating.

> > The semantics of audio-info are very different from the 
> semantics of a 
> > review. The following are required for audio info (based on the 
> > analysis and brainstorming done by this list): fn, contributor, 
> > published-date, rel-sample (samples), rel-enclosure (full 
> versions), 
> > rel-payment (purchase option), image-summary, category, 
> duration, and 
> > price - hardly any of those overlap with hReview.
> 
> hm, hreview has fn, so does this proposal, it has 
> published-date just like this proposal, it has an image just 
> like this proposal, it has tags just like this proposal's 
> category, hreview has URL which could be used as the download 
> links... like i originally said, it basically broken down to 
> many of the same values in hReview, with the addition of 
> price and duration.
> 
> The only value required for an hReview is the FN. Then we got 
> all side-tracked with a grouping issue.

Actually, the "item" value is the only requirement, which if I understand correctly could be an fn, hCard, or hCalendar.

> One of the first steps in proposing a microformat is to see 
> if an existing microformat could fit. After spending along 
> time on the mailing list, simply suggesting things, the whole 
> conversation bascially was pulled back to hReview. Has anyone 
> attempted to simply mark-up their data using hReview with a 
> price and duration (which is already a solved problem in hCalendar)?

If you mean that we should re-use the semantics/values in hReview, I agree. If you are suggesting actually having hReview instead of
hAudio or even changing hReview to fit hAudio (or hMedia) into it, I think that would be a problem.

An hReview for audio would require a new type (audio) and a new item category (hAudio?).  The current hReview doesn't actually work
for reviews of media that aren't in the set "product | business | event | person | place | website | url."

So, please correct me if I'm wrong, but I doesn't seem like hReview can't be used for reviewing movies or audio in a way that
retains the semantics that you are reviewing a movie or an audio piece or a book or any media type. Instead, all of those appear to
be shoehorned into "url" and are therefore semantically indistinguishable from reviewing a webpage/URL.  

Check out the example movie review on the wiki [1] and I think you will see what I mean. The fact that the review is of a movie is
only knowable if you magically know and assume that http://www.imdb.com/title/tt0299977/ refers to a movie. That seems like a hack
rather than a scalable semantic solution. What URLs do I use for book reviews? Songs?

On a somewhat related note, shouldn't there be a uid in both hReview for the item being reviewed and hAudio for the audio item? 

And once we have a new type in hReview, we still have all the required meta-data for that particular media, which naturally fits
into an hMedia or hAudio spec.

In summary:
Re-using atomic elements and values: good.
Overgeneralizing and losing meaning: bad.

So, I would suggest that (1) we will need to update hReview once we figure out how to refer to media, so that we can review media as
easily as people, businesses, events, people, places and websites; (2) we need to figure out the media meta-data
(hMedia/hAudio/whatever) so that hReview can appropriately refer to a piece of media rather than just hCards, hCalendars, and named
things.

-j

[1] http://microformats.org/wiki/hreview#Movie_Review

--
Joe Andrieu
SwitchBook Software
http://www.switchbook.com
joe@switchbook.com
+1 (805) 705-8651 


From msporny at digitalbazaar.com  Fri Jun  1 12:23:39 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Jun  1 12:23:44 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <00d801c7a431$164434f0$11fa030a@andrieuhome>
References: <00d801c7a431$164434f0$11fa030a@andrieuhome>
Message-ID: <4660723B.5030002@digitalbazaar.com>

Joe Andrieu wrote:
>>From reviewing the examples [2], 

Thank you for that very thorough and well thought out argument, Joe. I
agree with most of what you had to say, here's my $0.02 on the rest:

> I think there are five distinct semantic items here, at a minimum: 
> 	album
> 	playlist
> 	track
> 	audiofile
> 	podcast

I agree that there are several distinct semantic items that we are
discussing. What would be beneficial to all of us is to focus on just
one or two of them. Why can't we pick one of them and go with that?

album/track

That is not to say we can't do the others in the future (maybe one or
two per month). The most prior art/examples that we have are for albums
- let us focus and fix that problem.

It gives us a problem with a definite solution (rather than one that has
us pontificating endlessly as to the optimal ways we can combine various
items).

As for your playlist example at the end of your e-mail... you said it
best when you noted

>> Albums, podcasts, whatever, aren't they all forms of
>> playlists? haudio with opional hplaylist?
>
> Not unless you can provide examples of them being display on the web
> as the same thing.

We need examples of playlists to support your playlist argument... which
we don't have.

What we do have, however, is a plethora of album/track/song examples.
Let's focus on solving that very specific problem.

-- manu
From joe at andrieu.net  Fri Jun  1 12:35:43 2007
From: joe at andrieu.net (Joe Andrieu)
Date: Fri Jun  1 12:35:46 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <4660723B.5030002@digitalbazaar.com>
Message-ID: <011701c7a484$0bf36f90$11fa030a@andrieuhome>

Manu Sporny wrote:
> Joe Andrieu wrote:
> >>From reviewing the examples [2],
> 
> Thank you for that very thorough and well thought out 
> argument, Joe. I agree with most of what you had to say, 
> here's my $0.02 on the rest:
> 
> > I think there are five distinct semantic items here, at a minimum: 
> > 	album
> > 	playlist
> > 	track
> > 	audiofile
> > 	podcast
> 
> As for your playlist example at the end of your e-mail... you 
> said it best when you noted
> 
> >> Albums, podcasts, whatever, aren't they all forms of playlists? 
> >> haudio with opional hplaylist?
> >
> > Not unless you can provide examples of them being display 
> on the web 
> > as the same thing.
> 
> We need examples of playlists to support your playlist 
> argument... which we don't have.

Sure we do. There are a bunch on the examples page, including the FIQL service I mentioned in my email.

> What we do have, however, is a plethora of album/track/song 
> examples. Let's focus on solving that very specific problem.

I support that.  But then what you are solving is hAlbum. Not hAudio.  Once we figure out hAlbum, we can certainly generalize upward
to hAudio, incorporating playlists and podcasts as we go.

I think that's a good solution, as it allows us to solve the specifics of how albums group songs into published works, which is much
simpler than trying to generalize all the different ways that media properties aggregate and group other media. We just need to note
that hAudio is waiting for hAlbum and start through the process with the more limited, more tractable focus on albums, reusing what
we've already documented where appropriate.

-j

--
Joe Andrieu
SwitchBook Software
http://www.switchbook.com
joe@switchbook.com
+1 (805) 705-8651 


From msporny at digitalbazaar.com  Fri Jun  1 13:19:34 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Jun  1 13:19:38 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <21e770780706010704u3f61bf4eo8af68a455cd517c@mail.gmail.com>
References: <465E32ED.4040609@digitalbazaar.com>	<21e770780705310556t37dc0b3eyd9a8314df1a04a24@mail.gmail.com>	<465F2FDC.1060308@digitalbazaar.com>
	<21e770780706010704u3f61bf4eo8af68a455cd517c@mail.gmail.com>
Message-ID: <46607F56.9070509@digitalbazaar.com>

Brian Suda wrote:
> I just think there was either, no interest in
> developing the format, or too many "what if we add this" happened and
> it never moved forward.

It tends to be more of the latter when it comes to this list :) - lots
of good ideas... in fact, too many to see clearly, sometimes. That is
why it would be good of us to limit this discussion to audio-info only.

You also stated that that you "feel these same properties can
simultaneously apply to multiple things". Yes, absolutely they can - I
wouldn't be surprised at all if images and video shared a great number
of the elements (such as 'fn', 'image-summary', 'duration', and 'price').

However, we don't know until we do the research - that means collecting
80-100 video site examples and collecting 80-100 image site examples. If
somebody on the list wants to go and do that right now, that would be
great. However, barring any heroes collecting and analyzing all of those
examples - we don't have the data necessary to make the arguments.

My gut tells me you are correct, Brian - however, Microformats are not
based on gut-feelings... they're based on hard data.

> --- You could have some overarching container, lets call that
> something like "media". That has meta data, much like hfeed.

All good suggestions - why can't we do both album and media? I was
defending the position that you are defending just a few days ago. That
of generic grouping.

As Joe noted, you lose quite a bit of semantic meaning when you use
generic containers - that seemed to be a theme in the arguments against
hSet. I don't think you're going to find many people that will agree to
create another generic container when we just had a very drawn out
discussion about generic containers.

> Has anyone attempted to simply
> mark-up their data using hReview with a price and duration (which is
> already a solved problem in hCalendar)?

It loses semantic meaning. An album isn't the same thing as a review.
You don't tell your friends "Hey I just listened to a review called
"Yeehaw and the Kick Me Brothers" last night - it was great!". At that
point, they have no idea if you're talking about a movie, a podcast, an
album, or a song. You say "I listened to this album called "Yeehaw and
the Kick Me Brothers" last night". It is far more semantically accurate.

Encapsulating hAudio in hReview when writing a review about a song or
album would be a perfect example of using the two together in a proper
manner.

-- manu
From msporny at digitalbazaar.com  Fri Jun  1 14:22:20 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Jun  1 14:22:24 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <011701c7a484$0bf36f90$11fa030a@andrieuhome>
References: <011701c7a484$0bf36f90$11fa030a@andrieuhome>
Message-ID: <46608E0C.3020403@digitalbazaar.com>

Joe Andrieu wrote:
>> We need examples of playlists to support your playlist 
>> argument... which we don't have.
> 
> Sure we do. There are a bunch on the examples page, 
> including the FIQL service I mentioned in my email.

Are we looking at the same examples page?

http://microformats.org/wiki/audio-info-examples

>> What we do have, however, is a plethora of album/track/song 
>> examples. Let's focus on solving that very specific problem.
> 
> I support that.  But then what you are solving is hAlbum. 
> Not hAudio.  Once we figure out hAlbum, we can certainly
> generalize upward to hAudio, incorporating playlists and
> podcasts as we go.

That's funny... that's exactly what we said about hAudio... "we'll start
with hAudio and generalize upward to albums, podcasts and playlists."

The hAudio Microformat is meant to be "delivery/container mechanism"
agnostic. hAudio is supposed to be encapsulated by the delivery
mechanism, be it a playlist, album, podcast, media or other such container.

What is your definition for a playlist? I think we have different
definitions. Do you mean "A list of playable audio objects."?

-- manu

From joe at andrieu.net  Fri Jun  1 17:40:42 2007
From: joe at andrieu.net (Joe Andrieu)
Date: Fri Jun  1 17:40:45 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <46608E0C.3020403@digitalbazaar.com>
Message-ID: <001601c7a4ae$a75cf3a0$0201a8c0@andrieuhome>

Manu Sporny wrote:
> Joe Andrieu wrote:
> >> We need examples of playlists to support your playlist
> >> argument... which we don't have.
> > 
> > Sure we do. There are a bunch on the examples page,
> > including the FIQL service I mentioned in my email.
> 
> Are we looking at the same examples page?
> 
> http://microformats.org/wiki/audio-info-examples

Wow.  I literally have no idea how I found FIQL.  I was sure it was from the examples page. Here are a few examples of playlists:

CCMixter http://ccmixter.org/media/view/media/playlists
FIQL http://www.fiql.com
FNAC Music http://www.fnacmusic.com/pl/95c186a6-ca78-4e69-bb6c-d1fc155cfcdd.aspx
Mix Matcher http://www.mixmatcher.com

However, your point is correct. The current list of examples are all built around albums and playlists. Most likely because that's
pretty much what you restricted it to with the templates. No offense intended, but it's a pretty strong opening constraint at the
top of the wiki page.

Rather than jump in and violate that structure, I've not added the playlist examples above to the wiki yet.

> >> What we do have, however, is a plethora of album/track/song
> >> examples. Let's focus on solving that very specific problem.
> > 
> > I support that.  But then what you are solving is hAlbum.
> > Not hAudio.  Once we figure out hAlbum, we can certainly
> > generalize upward to hAudio, incorporating playlists and
> > podcasts as we go.
> 
> That's funny... that's exactly what we said about hAudio... 
> "we'll start with hAudio and generalize upward to albums, 
> podcasts and playlists."

Ah... Well, that's ok. But I don't think it is what you are doing as there is much conversation and documentation about albums and
"grouping".

If you want to start with the most basic atomic element, that /could/ be "hAudio", although a slightly different hAudio than I was
considering.  An "atomic" hAudio is more what I was calling audiofile, i.e., the representation of a single audio resource.

I was coming at it from the other direction: that hAudio is a type of hMedia, a peer of hVideo and hBook. In that case, it would
contain/be any kind of audio packaging from albums to podcasts to playlists.

> The hAudio Microformat is meant to be "delivery/container 
> mechanism" agnostic. hAudio is supposed to be encapsulated by 
> the delivery mechanism, be it a playlist, album, podcast, 
> media or other such container.

Ok. That I can support. So, let's step back from the "album" and grouping concepts and focus on "hAudio" as this paragraph suggests.

Frankly, whether this is called hAudio or hAudiofile is not so interesting. However, I do believe it is the simplest, most atomic
problem we could start with. And therefore, probably our best chance for getting traction.  The current hAudio proposal says
"Defining parts of an hAudio will not be complete without a complete grouping draft/specification."  That comes across as implying a
much more complicated hAudio than the schema and your most recent comments suggests.

> What is your definition for a playlist? I think we have 
> different definitions. Do you mean "A list of playable audio 
> objects."?

That's a really good question. I mean a list of audio tracks. They need not be "playable" in the sense of having a downloadable
reference, but if they were to be found, then each of the items should produce audio when played using the appropriate application
or device. So, althought I know this doesn't hit the 80/20 rule, for me, a playlist should work for offline and fictional songs. For
example a playlist of "Elvis From the Dead" with Elvis song titles "adjusted" for Halloween.  Yes, I know this is totally outside
the scope of what we should waste our time on, but it illustrates one of the boundaries of what a playlist could be. More
practically, one might create a playlist wishlist for songs they don't know where or how to find online or that they don't care to,
because they have the CDs and that's what the DJ will be using at the bar mitzvah this weekend. You get the idea, I think.

In my conception:
. Album: playlist(s) + meta-data (including cover-art, etc.)
. Playlist: track(s) + meta-data
. Track: option audiofile(s), each the same "audio" in different formats or from different distribution points + meta-data
. Podcast: playlist(s) + meta-data; although I think 80/20 suggests podcasts are usually a single track, single audiofile
. Audiofile: a specific downloadable media file that contains audio + meta-data.


So, I'm good with focusing current efforts on the simplest case. I would call that an audiofile, but by no means do I think that's
the important term.

What would you call what I've been referring to as hAudio, a type of hMedia and a peer to the as-yet-to-be-defined hVideo and hBook?


Also, I bet that cleaning up the current hAudio to focus entirely on just this atomic item, and none of the grouping... including
album... Would make this a lot more tractable and understandable for folks.

In fact, I would suggest moving all of the album examples to an album-examples page. And playlists to a playlist-examples page.

I am unsure about where to draw the line between "tracks" and "audiofiles" in a spec, but finding examples of each might be useful.
Specifically, I'm curious how many times alternative formats/sources are listed for tracks.

More research for the future. =)

-j

--
Joe Andrieu
SwitchBook Software
http://www.switchbook.com
joe@switchbook.com
+1 (805) 705-8651 


From msporny at digitalbazaar.com  Fri Jun  1 22:59:40 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Jun  1 22:59:44 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <001601c7a4ae$a75cf3a0$0201a8c0@andrieuhome>
References: <001601c7a4ae$a75cf3a0$0201a8c0@andrieuhome>
Message-ID: <4661074C.6020707@digitalbazaar.com>

Joe Andrieu wrote:
> However, your point is correct. The current list of examples are all built 
> around albums and playlists. Most likely because that's pretty much
> what you restricted it to with the templates. No offense intended,
> but it's a pretty strong opening constraint at the top of the
> wiki page.

The templates were only created after analyzing 30-50 of the sites.
Items were added to the templates as needed, for example:

Audio Lunch Box has 'price in credits' as a part of the audio-related
information displayed on the page. Note that this value isn't in the
templates. The templates were only finalized after we finished analysis
of over 110 audio websites. Martin, Alexandre and I did the data
collection and analysis - we all knew that collecting data on each page
was free form.

We started with a list of 110 URLs and the patterns emerged from there -
not the other way around. Please don't assume the data was collected in
a certain way, nor assume contributions happened in a certain way. We
keep a close watch on contributions to that page and start a dialogue on
the proper way to collect data with anybody that modifies the page. This
includes free-form data gathering - the template is there only to help
the person that is gathering the data.

> Rather than jump in and violate that structure, I've not added 
> the playlist examples above to the wiki yet.

Please do add any examples that you want to... I can double check to
make sure that our analysis software won't barf on your input. You can
use whatever terms that you want to describe the information on the
page. Please, please, please help us gather examples...

> However, I do believe it is the simplest, most atomic
> problem we could start with. And therefore, probably our 
> best chance for getting traction.  The current hAudio
> proposal says "Defining parts of an hAudio will not be
> complete without a complete grouping draft/specification."
> That comes across as implying a much more complicated
> hAudio than the schema and your most recent comments suggests.

What we're suggesting is a very simple addition to hAudio. This is the
same exact solution that was devised for hAtom... you should take some
time and read up on the 'hfeed' property.

http://microformats.org/wiki/hatom#Feed

What we're talking about adding is 'album'.

>> What is your definition for a playlist? I think we have 
>> different definitions. Do you mean "A list of playable audio 
>> objects."?
> 
> That's a really good question. I mean a list of audio tracks...

We've already had the playlist discussion on this list:

http://microformats.org/discuss/mail/microformats-new/2007-April/000155.html

A playlist is hAudio + XOXO - simple as that.

> In my conception:
> . Album: playlist(s) + meta-data (including cover-art, etc.)

Album: 'album' property + 'track' property + hAudio

> . Playlist: track(s) + meta-data

Playlist: XOXO + hAudio

> . Track: option audiofile(s), each the same "audio" in 
> different formats or from different distribution points + meta-data

No need for this complexity - this case is covered in the Album example
above.

> . Podcast: playlist(s) + meta-data; although I think 
> 80/20 suggests podcasts are usually a single track, single audiofile

No need for this complexity yet, or if we want to do this, it would be
mirrored directly from Album:

Album: 'podcast' property + XOXO + hAudio

> . Audiofile: a specific downloadable media file that contains 
> audio + meta-data.

We've already discussed this concept on the mailing list:

http://microformats.org/discuss/mail/microformats-new/2007-April/000107.html

> So, I'm good with focusing current efforts on the simplest case.

Good, we have agreement on principal - however, I think the "simplest
case" that we're outlining is far more simple than you think it is.

Here is a complete example of what we're talking about:

<div class="halbum">
 <div class="summary">
  <div class="haudio">
   <span class="title">Black Horse and The Cherry Tree</span> by
   <span class="collaborator hcard fn">KT Tunstall</span>
  </div>
 <ol class="xoxo">
  <li>
   <div class="track">
    <div class="haudio">
     <span class="fn">Black Horse & The Cherry Tree</span>
    </div>
   </div>
  </li>
  <li>
   <div class="track">
    <div class="haudio">
     <span class="fn">One Day [Live]</span>
    </div>
   </div>
  </li>
 </ol>
</div>

It's simple design, readable, easy to author, contains a "playlist",
doesn't have any scary dot-notation, and is semantically rich.

-- manu

From msporny at digitalbazaar.com  Sun Jun  3 11:55:14 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Jun  3 11:55:23 2007
Subject: [uf-new] Sound Optimization for haudio
In-Reply-To: <1180701057.3230.1.camel@localhost.localdomain>
References: <1180701057.3230.1.camel@localhost.localdomain>
Message-ID: <46630E92.9010900@digitalbazaar.com>

Martin McEvoy wrote:
> <div class="haudio">
>  <h1 class="vcard">
> 	 <span class="contributor org">The Beatles</span> - 
> 		 <span class="fn">The White Album</span></h1>
> 		 
> <div class="haudio vcard">
> <h2 class="fn">Disc: 1</h2>
> <ol>
> 	<li class="sound">Back in the U.S.S.R. - <span class="duration">2:43</span></li>
> 	<li class="sound">Dear Prudence- <span class="duration">3:56</span></li>
> </ol>
> </div>	
> <div class="haudio vcard">	
> <h2  class="fn">Disc: 2</h2>
> <ol>
>       <li class="sound">Birthday - <span class="duration">2:42</span></li>
>       <li class="sound">Yer Blues - <span class="duration">4:00</span></li>
> </ol>
> </div>
> </div>

In a very generic sense, I see where you're going, Martin.

However, keep in mind that what you've marked up is really a formatted
name. The sound markup is meant for "audio samples". hAudio has already
solved that problem in a more semantically compact and accurate way (by
using rel="sample", rel="enclosure", and rel="payment").

For solving the problem of albums, using the 'album/track' markup
previously proposed seems to make more semantic sense than this proposal.

-- manu
From martin at weborganics.co.uk  Sun Jun  3 14:44:24 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sun Jun  3 14:43:01 2007
Subject: [uf-new] Sound Optimization for haudio
In-Reply-To: <46630E92.9010900@digitalbazaar.com>
References: <1180701057.3230.1.camel@localhost.localdomain>
	<46630E92.9010900@digitalbazaar.com>
Message-ID: <1180907064.11081.1.camel@localhost.localdomain>

On Sun, 2007-06-03 at 14:55 -0400, Manu Sporny wrote:
> Martin McEvoy wrote:
> > <div class="haudio">
> >  <h1 class="vcard">
> > 	 <span class="contributor org">The Beatles</span> - 
> > 		 <span class="fn">The White Album</span></h1>
> > 		 
> > <div class="haudio vcard">
> > <h2 class="fn">Disc: 1</h2>
> > <ol>
> > 	<li class="sound">Back in the U.S.S.R. - <span class="duration">2:43</span></li>
> > 	<li class="sound">Dear Prudence- <span class="duration">3:56</span></li>
> > </ol>
> > </div>	
> > <div class="haudio vcard">	
> > <h2  class="fn">Disc: 2</h2>
> > <ol>
> >       <li class="sound">Birthday - <span class="duration">2:42</span></li>
> >       <li class="sound">Yer Blues - <span class="duration">4:00</span></li>
> > </ol>
> > </div>
> > </div>
> 
> In a very generic sense, I see where you're going, Martin.
> 
> However, keep in mind that what you've marked up is really a formatted
> name. The sound markup is meant for "audio samples". hAudio has already
> solved that problem in a more semantically compact and accurate way (by
> using rel="sample", rel="enclosure", and rel="payment").
> 
> For solving the problem of albums, using the 'album/track' markup
> previously proposed seems to make more semantic sense than this proposal.

Thought as much thank you Manu :)

> 
> -- manu
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2171 bytes
Desc: not available
Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070603/92552e1f/smime-0001.bin
From msporny at digitalbazaar.com  Sun Jun  3 18:02:40 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Jun  3 18:02:44 2007
Subject: [uf-new] Microformats get strong showing in Firefox 3 UI
Message-ID: <466364B0.30102@digitalbazaar.com>

Microformats are starting to look more and more like they're going to be
supported in a big way in the next major release of the browser.

http://blog.mozilla.com/faaborg/2007/06/01/the-user-interface-of-firefox-3-features/

Anybody else on here working with Michael Kaply or Alex Faaborg on
Microformats in Firefox 3?

-- manu


From joe at andrieu.net  Mon Jun  4 17:33:19 2007
From: joe at andrieu.net (Joe Andrieu)
Date: Mon Jun  4 17:33:19 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <4661074C.6020707@digitalbazaar.com>
Message-ID: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>

Manu Sporny wrote:
> > However, I do believe it is the simplest, most atomic
> > problem we could start with. And therefore, probably our
> > best chance for getting traction.  The current hAudio
> > proposal says "Defining parts of an hAudio will not be
> > complete without a complete grouping draft/specification."
> > That comes across as implying a much more complicated
> > hAudio than the schema and your most recent comments suggests.
> 
> What we're suggesting is a very simple addition to hAudio. 
> This is the same exact solution that was devised for hAtom... 
> you should take some time and read up on the 'hfeed' property.
> 
> http://microformats.org/wiki/hatom#Feed
> 
> What we're talking about adding is 'album'.

To quote from the wiki[1]:
==
tracks, songs, and parts in general are specified by embedding hAudio's inside of hAudios and using the ideas put forth in
grouping-brainstorming and grouping-proposal. Defining parts of an hAudio will not be complete without a complete grouping
draft/specification.
==

It seems that halbum means we no longer requires this "grouping" abstraction.  If this is correct, I think it is the right way to go
(and we should update the wiki).  If I'm misunderstanding and the above quote is still valid, then please explain how grouping fits
into the current haudio proposal.


> >> What is your definition for a playlist? I think we have
> >> different definitions. Do you mean "A list of playable audio 
> >> objects."?
> > 
> > That's a really good question. I mean a list of audio tracks...
> 
> We've already had the playlist discussion on this list:
> 
> http://microformats.org/discuss/mail/microformats-new/2007-April/000155.html
> 
> A playlist is hAudio + XOXO - simple as that.

Respectfully, a few points. First, please don't assume that your most recent statement on the email list is the definitive community
answer. "We've already had this discussion" comes across as patronizing.

Second, you asked for my definition. Please take a moment to respond rather than suggest it is made irrelevant by prior
conversations.

Third, the link you refer to seems to be discussing XOXO as a general solution to an ordered grouping.  Certainly, playlists are an
ordered grouping. However, there is more to it than that. They are playslists. A playlist indicates that the following list is meant
(or is intrinsically packaged) to be played together. Not every listing of audio is a playlist. For example, considering the
combined works of Beethoven as a playlist is a bit excessive, even if the works are all proper hAudio items. However, I believe the
current specification has no way to specify that a given XOXO list is a /playlist/ without an oddly redundant haudio that is
confusing in more ways than one.


In the email cited above you state:
==
<div class="haudio">
   <span class="collection">

Audio albums, DVDs, and photo albums could have the "collection"
specifier, songs, video episodes, and images wouldn't.
==


However, rather than have "album" a specific of a generic "collection", I believe you are currently suggesting evolving the the
proposal have halbum as a first class microformat, which contains other, multiply different  haudio elements of fundamentally
different types.  I support "album" as a semantically specific collection, but I'm still unsure why there are two different types of
hAudio in your example:

===
Here is a complete example of what we're talking about:

<div class="halbum">
 <div class="summary">
  <div class="haudio">
   <span class="title">Black Horse and The Cherry Tree</span> by
   <span class="collaborator hcard fn">KT Tunstall</span>
  </div>
 <ol class="xoxo">
  <li>
   <div class="track">
    <div class="haudio">
     <span class="fn">Black Horse & The Cherry Tree</span>
    </div>
   </div>
  </li>
  <li>
   <div class="track">
    <div class="haudio">
     <span class="fn">One Day [Live]</span>
    </div>
   </div>
  </li>
 </ol>
</div>

It's simple design, readable, easy to author, contains a "playlist", doesn't have any scary dot-notation, and is semantically rich.
===

I have several questions with this approach.

First, what is that first haudio item, the at halbum->summary->haudio?

Is that a playable audio file of the entire album?  If we are working with hAudio at the most basic component for audio, I would
think haudio would be the actual file or at least the meta-data around facsimiles of the same audio content (perhaps different file
formats underneath).

It seems that haudio is potentially--and confusingly--presented as both an atomic semantic class and as a grouping construct capable
of making collections out of itself. I don't quite understand how you intend to use it.

See the wiki example for album markup[2] for an example of haudio used as a collection item for albums.

Second, how would I display just a playlist, one that has never been an album? Is it like this:
 <ol class="xoxo">
  <div class="fn">My Party Songs</div>
  <li>
   <div class="track">
    <div class="haudio">
     <span class="fn">Black Horse & The Cherry Tree</span>
    </div>
   </div>
  </li>
  <li>
   <div class="track">
    <div class="haudio">
     <span class="fn">One Day [Live]</span>
    </div>
   </div>
  </li>
 </ol>

If that is correct, then how am I (as a parser) to know that this XOXO is a playlist? It seems to me that just as halbum is a
specific collection, so too is a playlist, perhaps best represented by hplaylist. The point is that not all XOXOs are playlists and
not all lists of hAudio tracks are playlists.  Generalizing the playlist to XOXO loses semantic specificity, with nothing gained.

If XOXO works well, then we can always adopt its semantics with added specificity: an hplaylist is an XOXO playlist of hAudio items.

Then, replacing XOXO in your example with "hplaylist" or its equivalent provides a more semantically rich representation of
playlists.


Third, what is a track? Is that semantically specified in the haudio schema? I don't see it in the wiki and you both argue that it
is unnecessary /and/ you use it in your example. I'm not sure what point you are trying to make with it.

Fourth, this outline seems inconsistent with what is current on the wiki.  I'm guessing that the proposal is actually evolving based
on these conversations, which means it makes sense for it to be a bit out of date. However, it also makes it harder to track,
especially when hAudio gets used in different ways, like in your recent example.


> > In my conception:
> > . Album: playlist(s) + meta-data (including cover-art, etc.)
> 
> Album: 'album' property + 'track' property + hAudio
> 
> > . Playlist: track(s) + meta-data
> 
> Playlist: XOXO + hAudio
> 
> > . Track: option audiofile(s), each the same "audio" in
> > different formats or from different distribution points + meta-data
> 
> No need for this complexity - this case is covered in the 
> Album example above.


This I don't understand. You included tracks in your example, but then state that they aren't needed. Am I missing something?

> > . Podcast: playlist(s) + meta-data; although I think
> > 80/20 suggests podcasts are usually a single track, single audiofile
> 
> No need for this complexity yet, or if we want to do this, it 
> would be mirrored directly from Album:
> 
> Album: 'podcast' property + XOXO + hAudio
> 
> > . Audiofile: a specific downloadable media file that contains
> > audio + meta-data.
> 
> We've already discussed this concept on the mailing list:
> 
> http://microformats.org/discuss/mail/microformats-new/2007-April/000107.html

The referred email (and the referenced wiki page) seems to be barely more than a suggestion. I don't yet see how audiofiles are
addressed in the proposal, except to say that they aren't.  In which case, it seems that hAudio represents only the meta-data about
an audio piece, but without the meta-data about the audiofile. Further, the media-info format seems to abstract away the essence of
the type of media, or at best requires a redundant specification.

Again, from a top-down perspective--how I have been thinking of this--it seems that hMedia is really about a set of peers, including
hVideo, hAudio, hImage, hPublication.  In an hAudio item, child elements of that hAudio would then define the components of that
hAudio item without additional "h" prefixes. Note that this is /not/ the hAudio that you seem to be working with.

Hence, a hiarchy like this:

	hAudio
		album
			playlist
				track
					audiofile
					audiofile
					audiofile
				track
					audiofile
					audiofile
					audiofile
				track
					audiofile
					audiofile
					audiofile	
	hVideo
		series
			episodelist
				episode
					videofile
					videofile
				episode
					videofile
					videofile
				episode
					videofile
					videofile

Noting that playlist may or may not require album, but does use hAudio as the container for the child elements and audiofile for the
actual file. In short, hAudio is saying to the parser, the items in this container are a single hAudio item; treat accordingly,
whether an album, playlist, track, or audiofile. The audiofile is, essentially an audio version of a media-file.

The problem with media-file (referred to in your linked email) is that you gain nothing from the abstraction & generalization.  If
at the bottom of an hAudio component, you have a media-file, won't you have to again specify the media-type? That is redundant.
hAudio should, imo, boil down to one or more actual audiofiles (assuming any media is available at all).

The alternative to the above that I thought you were going for was something like this:

halbum
	playlist/XOXO
		haudio
		haudio
		haudio
		haudio

But then in your example, you did something like this:
halbum
	haudio
	playlist/XOXO
		track
			haudio
		track	
			haudio
		track
			haudio

That was definitely confusing. 

If we use the current proposal/brainstorms for hAudio and media-info, how does one mark up a given haudio so that you link to high
and low bandwidth realplayer and windows media format versions of the same song?

Where does the downloadable/streamable file go in the schema?

> > So, I'm good with focusing current efforts on the simplest case.

> Good, we have agreement on principal - however, I think the "simplest case" that we're 
> outlining is far more simple than you think it is.

I don't think we're on the same page yet. hAudio still seems to have magical collection and grouping properties that I don't
understand and your use of "track" in your example is confusing. I'm not sure what to make of it. Finally, how do you represent
alternative presentations of the same effective audio piece as in my last point?

Btw, I want to be clear that hMedia, hVideo, etc., aren't items to tackle at this point. They are provided for symmetry to challenge
the assumptions around the benefits of generic containers and grouping.  Each media format has its own grouping semantics, let's
retain that by simply standardizing how we currently package, sell, and distribute audio.

Respectfully,

-j

[1] http://microformats.org/wiki/audio-info-proposal#Schema 
[2] http://microformats.org/wiki/audio-info-proposal#Audio_Album_Example

--
Joe Andrieu
SwitchBook Software
http://www.switchbook.com
joe@switchbook.com
+1 (805) 705-8651 


From scott at makedatamakesense.com  Mon Jun  4 19:42:35 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Mon Jun  4 19:42:46 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>
Message-ID: <DF29282A-FB2F-48B6-81EA-B2A4AEEBB2ED@makedatamakesense.com>

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.

> But then in your example, you did something like this:
> halbum
> 	haudio
> 	playlist/XOXO
> 		track
> 			haudio
> 		track	
> 			haudio
> 		track
> 			haudio
>
> That was definitely confusing.

I was also confused by that.  I spent a while trying to figure out  
what exactly class="haudio" would mean in this schema, and it looks  
like haudio has an incredibly generic meaning along the lines of  
"information about some type of audio" where both albums and tracks  
are potential types of audio.  I think that's far too general to be  
useful.  The container and item labels should be specific enough to  
make that unnecessary.  If we can't assume class="halbum" refers to  
audio, I think it's a poor class name and another name should be  
chosen that clearly indicates the content relates to audio without  
any need for additional labels like "haudio."

--
Scott Reynen
MakeDataMakeSense.com


From martin at weborganics.co.uk  Tue Jun  5 03:50:53 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Tue Jun  5 03:49:32 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <DF29282A-FB2F-48B6-81EA-B2A4AEEBB2ED@makedatamakesense.com>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>
	<DF29282A-FB2F-48B6-81EA-B2A4AEEBB2ED@makedatamakesense.com>
Message-ID: <1181040653.9118.50.camel@localhost.localdomain>

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?

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 only possible argument here would be the over use of haudio in xoxo
as it is not strictly necessary if you nested the playlist in a single
hAudio as each <li> is haudio

example:

halbum
   haudio [album title,contributor,image-summary, duration, payment]
        xoxo
          track 
               [track 1, duration, sample]
          track
               [track 2, duration, sample]
          track
               [track 3 duration, sample]

hmm problem here, what if our album has multiple content types not all
albums are just playable music yes? I don't think we would want to nest
hVideo and hImage inside hAudio would we? 
so Now it becomes useful to define which track is music and which is
video or Images.

example:

halbum
   haudio [album title,contributor,image-summary, duration, payment]
        xoxo
          track 
               hvideo [part 1, duration, sample, aspect, fps]
          track
               haudio [part 2, duration, sample]
          track
               haudio [part 3, duration, sample]
          track
               himage [part 4, size, filetype, compression,etc]

> 
> > But then in your example, you did something like this:
> > halbum
> > 	haudio
> > 	playlist/XOXO
> > 		track
> > 			haudio
> > 		track	
> > 			haudio
> > 		track
> > 			haudio
> >
> > That was definitely confusing.
> 
> I was also confused by that.  I spent a while trying to figure out  
> what exactly class="haudio" would mean in this schema, and it looks  
> like haudio has an incredibly generic meaning along the lines of  
> "information about some type of audio" where both albums and tracks  
> are potential types of audio.  

Err No not exactly haudio doesn't have to be playable audio it is also
be just information about an album

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]

this would fit into our schemata much more cleanly, Manu did use
<summary> in his original problem solution statement

http://microformats.org/discuss/mail/microformats-new/2007-June/000458.html


halbum
   summary [album title,contributor,image-summary, duration, payment]
        xoxo
          track 
               hvideo [part 1, duration, sample, aspect, fps, etc]
          track
               haudio [part 2, duration, sample]
          track
               haudio [part 3, duration, sample]
          track
               himage [part 4, size, filetype, compression,etc]


> I think that's far too general to be  
> useful.  The container and item labels should be specific enough to  
> make that unnecessary.  If we can't assume class="halbum" refers to  
> audio, I think it's a poor class name and another name should be  
> chosen that clearly indicates the content relates to audio without  
> any need for additional labels like "haudio."

Not when you take into account that hAlbum may contain Audio Video and Images

I think class-halbum is an excellent class name its simple, meaningful
and it uses terms that people already use.

http://www.xspf.org/orig-xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.8

-Martin-
> 
> --
> Scott Reynen
> MakeDataMakeSense.com
> 
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2171 bytes
Desc: not available
Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070605/32d6b804/smime.bin
From msporny at digitalbazaar.com  Tue Jun  5 05:54:56 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue Jun  5 05:55:00 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <DF29282A-FB2F-48B6-81EA-B2A4AEEBB2ED@makedatamakesense.com>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>
	<DF29282A-FB2F-48B6-81EA-B2A4AEEBB2ED@makedatamakesense.com>
Message-ID: <46655D20.3060508@digitalbazaar.com>

Scott Reynen 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.

Ah crap... I seem to have caused confusion with my ramblings. Apologies.
The proposal is close to what Joe and Scott have said makes sense:

halbum
   summary (this is the haudio that describes the album)
      haudio
   playlist/XOXO
      track
         haudio
      track
         haudio
      track
         haudio

The above is the current proposal... which is not set in stone and could
change. The wiki hasn't been updated because we have not decided if this
is okay with the list.

Martin has done some real-world markup to demonstrate the album/track
problem solution proposal:

http://weborganics.co.uk/haudio

Feedback on solving the problem as demonstrated above would be very helpful.

-- manu

From msporny at digitalbazaar.com  Tue Jun  5 06:58:09 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue Jun  5 06:58:12 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>
Message-ID: <46656BF1.7040907@digitalbazaar.com>

Joe Andrieu wrote:
> It seems that halbum means we no longer requires this 
> "grouping" abstraction.

That is correct - but this has only come about in the last couple of
days. I usually wait for some sort of concensus before updating the wiki.

>>>> What is your definition for a playlist? I think we have
>>>> different definitions. Do you mean "A list of playable audio 
>>>> objects."?
>>> That's a really good question. I mean a list of audio tracks...
>> We've already had the playlist discussion on this list:
>>
>> http://microformats.org/discuss/mail/microformats-new/2007-April/000155.html
>>
>> A playlist is hAudio + XOXO - simple as that.
> 
> Respectfully, a few points. First, please don't assume that 
> your most recent statement on the email list is the
> definitive community answer.
> "We've already had this discussion" comes across as patronizing.

Apologies if my statements came across as patronizing. They were
certainly not intended as such, you have made some very good points and
continue to do so. Please take my statements as opinion backed by what I
consider solid logical arguments.

The reason that I pointed you to that link is that I think you are
making an argument for an addition to hAudio grouping called 'playlist'.

At the end of the thread, Kevin Marks said:

"XOXO is a fine way to express simple collections, or nested ones; eg
hGeo in XOXO is a sensible form fro waypoints."

"hAudio in XOXO would be a sequence, or playlist, which is a useful form."

Nobody seemed to disagree with that - the thread died there. I think
everybody on here is open to talking about playlists.

I don't necessarily think that we NEED the concept of a 'playlist' in
halbum... we probably don't even need the concept of xoxo in halbum.
We're trying to start with the simplest possible solution and we can
build on top of that at a later date.

> I support "album" as a semantically specific collection, but 
> I'm still unsure why there are two different types of
> hAudio in your example

The example doesn't contain two different types of hAudio. hAudio
describes information about an audio recording. Note that this is
different from describing an audio file. Describing an audio file is the
job of the file-format exploratory discussion:

http://microformats.org/wiki/file-format-examples

> I have several questions with this approach.
> 
> First, what is that first haudio item, the at 
> halbum->summary->haudio?

The first haudio describes the album - which is why it is encased in a
'summary' tag.

> Is that a playable audio file of the entire album?  

If somebody wanted to provide a complete audio file of the entire album,
they would use the rel-enclosure method in halbum->summary->haudio. Here
is an example:

<div class="halbum">
 <div class="summary">
  <div class="haudio">
   <span class="fn">Black Horse and The Cherry Tree</span>
   <a rel="enclosure" href="/black-horse-album.mp3">Download</a>
  </div>
 </div>
</div>

> If we are working 
> with hAudio at the most basic component for audio, I would
> think haudio would be the actual file or at least the meta-data 
> around facsimiles of the same audio content (perhaps different file
> formats underneath).

Describing an audio file is the job of the file-format exploratory
discussion. Describing files is not part of the haudio discussion:

http://microformats.org/wiki/file-format-examples

I pointed you to the

> It seems that haudio is potentially--and confusingly--presented 
> as both an atomic semantic class and as a grouping construct capable
> of making collections out of itself. I don't quite understand how 
> you intend to use it.

Then, perhaps it would be helpful to think of it this way. We are
talking about two Microformats: halbum and haudio

haudio is the "atomic" Microformat that is used to describe audio
recordings.

halbum is the grouping Microformat for audio albums specifically - it
can aggregate a number of haudio recordings together.

We are not using hAtom to aggregate hAudio into albums because when we
use hAtom, we lose semantic meaning. The same argument could be used as
a pro-playlist stance.

> Second, how would I display just a playlist, one that has never been an album? Is it like this:
>  <ol class="xoxo">
>   <div class="fn">My Party Songs</div>
>   <li>
>    <div class="track">
>     <div class="haudio">
>      <span class="fn">Black Horse & The Cherry Tree</span>
>     </div>
>    </div>
>   </li>
>   <li>
>    <div class="track">
>     <div class="haudio">
>      <span class="fn">One Day [Live]</span>
>     </div>
>    </div>
>   </li>
>  </ol>

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>

if you want to make an argument for adding a playlist container, it
could be like this:

<ol class="playlist">
 <li class="track">
  <div class="haudio">
   <span class="fn">Black Horse & The Cherry Tree</span>
  </div>
 </li>
 <li class="track">
  <div class="haudio">
   <span class="fn">One Day [Live]</span>
  </div>
 </li>
</ol>

> If that is correct, then how am I (as a parser) to know that this 
> XOXO is a playlist?

If you find an xoxo that has at least two elements that are haudios -
you would assume that you have a playlist.

> Generalizing the playlist to XOXO loses semantic specificity,
> with nothing gained.
> Then, replacing XOXO in your example with "hplaylist" or its
> equivalent provides a more semantically rich representation of
> playlists.

You have a valid point as far as I'm concerned.

> Third, what is a track? Is that semantically specified in the haudio schema? 
> I don't see it in the wiki and you both argue that it is unnecessary
> /and/ you use it in your example. I'm not sure what point you are
> trying to make with it.

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. We
are still discussing it. In general, a track is "a containing element
for haudio that specifies that it is a part of an album".

> Fourth, this outline seems inconsistent with what is current on the wiki.

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.

>>> . Track: option audiofile(s), each the same "audio" in
>>> different formats or from different distribution points + meta-data
>> No need for this complexity - this case is covered in the 
>> Album example above.
> 
> This I don't understand. You included tracks in your example, but 
> then state that they aren't needed. Am I missing something?

Just a simple miscommunication. I didn't mean "we don't need tracks" - I
meant "tracks go with albums, and I've already stated my position on that".

>> http://microformats.org/discuss/mail/microformats-new/2007-April/000107.html
> 
> The referred email (and the referenced wiki page) seems to be barely more 
> than a suggestion. I don't yet see how audiofiles are addressed in
> the proposal, except to say that they aren't.  In which case, it seems
> that hAudio represents only the meta-data about
> an audio piece, but without the meta-data about the audiofile. 

That is correct. We are concentrating on describing information about
the audio recording. We are not dealing with describing files - that
discussion is part of the file format exploratory discussion:

http://microformats.org/wiki/file-format-examples

In the future, we may use file-format in haudio. However, for this
release of haudio, we're more narrowly focused.

> If we use the current proposal/brainstorms for hAudio and media-info, how 
> does one mark up a given haudio so that you link to high
> and low bandwidth realplayer and windows media format versions of the 
> same song?
> Where does the downloadable/streamable file go in the schema?

<div class="haudio">
 <span class="fn">A Song</span>
 <a rel="sample" href="sample/asong">Sample</a>
 <a rel="enclosure" href="/song-realplayer-low-quality.ra">
   Download Low Quality Realplayer File
 </a>
 <a rel="enclosure" href="/song-wma-high-quality.wma">
   Download High Quality WMA File
 </a>
</div>

Can we please split this discussion into two threads?

hPlaylist
hAlbums

-- manu
From msporny at digitalbazaar.com  Tue Jun  5 07:49:04 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue Jun  5 07:49:07 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <1181040653.9118.50.camel@localhost.localdomain>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>	<DF29282A-FB2F-48B6-81EA-B2A4AEEBB2ED@makedatamakesense.com>
	<1181040653.9118.50.camel@localhost.localdomain>
Message-ID: <466577E0.7060607@digitalbazaar.com>

Martin McEvoy 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.

> I don't think we would want to nest
> hVideo and hImage inside hAudio would we?

No, but we may want to nest hAudio, hVideo and hImage inside a hMedia
container.

>> I was also confused by that.  I spent a while trying to figure out  
>> what exactly class="haudio" would mean in this schema, and it looks  
>> like haudio has an incredibly generic meaning along the lines of  
>> "information about some type of audio" where both albums and tracks  
>> are potential types of audio.  
> 
> Err No not exactly haudio doesn't have to be playable audio it is also
> be just information about an album

That is correct - let's not confuse hAudio with the file-format
exploratory discussion. The purpose of haudio is to describe information
related to audio recordings.

> 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]
> 
> this would fit into our schemata much more cleanly, Manu did use
> <summary> in his original problem solution statement

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.

-- manu

From scott at makedatamakesense.com  Tue Jun  5 14:20:43 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Tue Jun  5 14:20:47 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <46656BF1.7040907@digitalbazaar.com>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>
	<46656BF1.7040907@digitalbazaar.com>
Message-ID: <180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>

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

From timber at lava.net  Tue Jun  5 15:00:21 2007
From: timber at lava.net (Colin Barrett)
Date: Tue Jun  5 15:00:28 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>
	<46656BF1.7040907@digitalbazaar.com>
	<180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>
Message-ID: <FDE397F9-7DA0-4072-A1F0-B138F928FCEB@lava.net>

On Jun 5, 2007, at 2:20 PM, Scott Reynen wrote:

> 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.

They're actually, IMO, almost entirely the same.

A classical recording is a good example -- unlike popular music, the  
tracks on the album are often merely segments of a larger whole, f.e.  
"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.

-Colin
From msporny at digitalbazaar.com  Tue Jun  5 15:14:22 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue Jun  5 15:14:25 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <FDE397F9-7DA0-4072-A1F0-B138F928FCEB@lava.net>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>	<46656BF1.7040907@digitalbazaar.com>	<180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>
	<FDE397F9-7DA0-4072-A1F0-B138F928FCEB@lava.net>
Message-ID: <4665E03E.3010303@digitalbazaar.com>

Colin Barrett wrote:
> On Jun 5, 2007, at 2:20 PM, Scott Reynen wrote:
> 
>> 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.
> 
> They're actually, IMO, almost entirely the same.

I agree with Colin - there really isn't a significant difference between
what you proposed for halbum and what haudio already does. They are
almost entirely the same.

-- manu

From scott at makedatamakesense.com  Tue Jun  5 15:56:58 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Tue Jun  5 15:57:01 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <FDE397F9-7DA0-4072-A1F0-B138F928FCEB@lava.net>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>
	<46656BF1.7040907@digitalbazaar.com>
	<180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>
	<FDE397F9-7DA0-4072-A1F0-B138F928FCEB@lava.net>
Message-ID: <46F56F73-6CB3-4B01-BB03-6409D54A5497@makedatamakesense.com>

On Jun 5, 2007, at 4:00 PM, Colin Barrett wrote:

> On Jun 5, 2007, at 2:20 PM, Scott Reynen wrote:
>
>> 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.
>
> They're actually, IMO, almost entirely the same.
>
> A classical recording is a good example -- unlike popular music,  
> the tracks on the album are often merely segments of a larger  
> whole, f.e. "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.  If it's not, we could just embed  
haudio inside haudio to indicate sub-sections of audio (as suggested  
in audio-info-proposal).  If it is a useful distinction, we should  
clearly identify the difference.  We shouldn't use unnecessary labels.

--
Scott Reynen
MakeDataMakeSense.com


From martin at weborganics.co.uk  Tue Jun  5 16:39:03 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Tue Jun  5 16:37:42 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <FDE397F9-7DA0-4072-A1F0-B138F928FCEB@lava.net>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>
	<46656BF1.7040907@digitalbazaar.com>
	<180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>
	<FDE397F9-7DA0-4072-A1F0-B138F928FCEB@lava.net>
Message-ID: <1181086744.11337.8.camel@localhost.localdomain>

On Tue, 2007-06-05 at 15:00 -0700, Colin Barrett wrote:
> On Jun 5, 2007, at 2:20 PM, Scott Reynen wrote:
> 
> > 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.
> 
> They're actually, IMO, almost entirely the same.
> 
> A classical recording is a good example -- unlike popular music, the  
> tracks on the album are often merely segments of a larger whole, f.e.  
> "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.

Colin you have a good point here
haudio would not be extended far enough to suit the classical
communities needs when you take into account that Beethoven has nine
symphonies with a total of 37 movements with sub properties of 

title
Composer
Performer
Conductor
Instrument
Ensemble
Opus
genre
sub-genre
style
period
Year composed
Sheet music

-Martin-

> 
> -Colin
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2171 bytes
Desc: not available
Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070606/1056cbe2/smime.bin
From timber at lava.net  Tue Jun  5 16:45:20 2007
From: timber at lava.net (Colin Barrett)
Date: Tue Jun  5 16:45:25 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <1181086744.11337.8.camel@localhost.localdomain>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>
	<46656BF1.7040907@digitalbazaar.com>
	<180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>
	<FDE397F9-7DA0-4072-A1F0-B138F928FCEB@lava.net>
	<1181086744.11337.8.camel@localhost.localdomain>
Message-ID: <3DAC0D49-AE35-452A-96CC-FFBC3EAB8E18@lava.net>


On Jun 5, 2007, at 4:39 PM, Martin McEvoy wrote:

> On Tue, 2007-06-05 at 15:00 -0700, Colin Barrett wrote:
>> On Jun 5, 2007, at 2:20 PM, Scott Reynen wrote:
>>
>>> 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.
>>
>> They're actually, IMO, almost entirely the same.
>>
>> A classical recording is a good example -- unlike popular music, the
>> tracks on the album are often merely segments of a larger whole, f.e.
>> "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.
>
> Colin you have a good point here
> haudio would not be extended far enough to suit the classical
> communities needs when you take into account that Beethoven has nine
> symphonies with a total of 37 movements with sub properties of

You would be marking up a specific recording of the symphony with  
haudio, though, so you would have information *about that recording,*  
not about the specific work of music in question.

Another example: You don't mark up information about the song "Star  
Spangled Banner," you mark up the information about Jimi Hendrix's  
particular recording of it. e.g, year would be 1967, not 1814.

-Colin
From brian.suda at gmail.com  Tue Jun  5 17:03:43 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Tue Jun  5 17:03:46 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <3DAC0D49-AE35-452A-96CC-FFBC3EAB8E18@lava.net>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>
	<46656BF1.7040907@digitalbazaar.com>
	<180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>
	<FDE397F9-7DA0-4072-A1F0-B138F928FCEB@lava.net>
	<1181086744.11337.8.camel@localhost.localdomain>
	<3DAC0D49-AE35-452A-96CC-FFBC3EAB8E18@lava.net>
Message-ID: <21e770780706051703p427f97b7mcee61c1ab09defb7@mail.gmail.com>

On 6/5/07, Martin McEvoy <martin@weborganics.co.uk> wrote:
> Colin you have a good point here
> haudio would not be extended far enough to suit the classical
> communities needs when you take into account that Beethoven has nine
> symphonies with a total of 37 movements with sub properties of
...

On 6/5/07, Colin Barrett <timber@lava.net> wrote:
> Another example: You don't mark up information about the song "Star
> Spangled Banner," you mark up the information about Jimi Hendrix's
> particular recording of it. e.g, year would be 1967, not 1814.

--- now we are spiraling back to ideas of what people "WANT" rather
than model what is being published. Another concern i have been having
about this prososal is that it is more about exposing existing company
Database Schemas, rather than what the average person is publishing.
The more i think about it, the more i realise i have never seen a blog
talk about the run-time of track 3 of a given CD. It is always, "that
CD is great, you should buy it". Which is more of a review than any
sort of media-format. We are spending alot of time trying to model a
database schema of existing companies rather than see what people are
publish.

We need to avoid, "what about ..." suggestions, otherwise we will have
more endless cyclical conversations.

-brian

-- 
brian suda
http://suda.co.uk
From martin at weborganics.co.uk  Tue Jun  5 17:23:13 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Tue Jun  5 17:21:50 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <21e770780706051703p427f97b7mcee61c1ab09defb7@mail.gmail.com>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>
	<46656BF1.7040907@digitalbazaar.com>
	<180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>
	<FDE397F9-7DA0-4072-A1F0-B138F928FCEB@lava.net>
	<1181086744.11337.8.camel@localhost.localdomain>
	<3DAC0D49-AE35-452A-96CC-FFBC3EAB8E18@lava.net>
	<21e770780706051703p427f97b7mcee61c1ab09defb7@mail.gmail.com>
Message-ID: <1181089393.11614.5.camel@localhost.localdomain>

On Wed, 2007-06-06 at 00:03 +0000, Brian Suda wrote:
> On 6/5/07, Martin McEvoy <martin@weborganics.co.uk> wrote:
> > Colin you have a good point here
> > haudio would not be extended far enough to suit the classical
> > communities needs when you take into account that Beethoven has nine
> > symphonies with a total of 37 movements with sub properties of
> ...
> 
> On 6/5/07, Colin Barrett <timber@lava.net> wrote:
> > Another example: You don't mark up information about the song "Star
> > Spangled Banner," you mark up the information about Jimi Hendrix's
> > particular recording of it. e.g, year would be 1967, not 1814.
> 
> --- now we are spiraling back to ideas of what people "WANT" rather
> than model what is being published. Another concern i have been having
> about this prososal is that it is more about exposing existing company
> Database Schemas, rather than what the average person is publishing.
> The more i think about it, the more i realise i have never seen a blog
> talk about the run-time of track 3 of a given CD. It is always, "that
> CD is great, you should buy it". Which is more of a review than any
> sort of media-format. We are spending alot of time trying to model a
> database schema of existing companies rather than see what people are
> publish.

we are not talking about blogs though are we? we are talking about music
download sites which do have run times and track numbers?

> 
> We need to avoid, "what about ..." suggestions, otherwise we will have
> more endless cyclical conversations.

which is, I guess, why the media info discussion ground to a halt?


-Martin-
> 
> -brian
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2171 bytes
Desc: not available
Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070606/9ae2e70b/smime.bin
From msporny at digitalbazaar.com  Tue Jun  5 17:46:52 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue Jun  5 17:46:55 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <46F56F73-6CB3-4B01-BB03-6409D54A5497@makedatamakesense.com>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>	<46656BF1.7040907@digitalbazaar.com>	<180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>	<FDE397F9-7DA0-4072-A1F0-B138F928FCEB@lava.net>
	<46F56F73-6CB3-4B01-BB03-6409D54A5497@makedatamakesense.com>
Message-ID: <466603FC.10400@digitalbazaar.com>

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, f.e.
>> "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.

I believe that Colin (and I) are arguing against complicating halbum any
more than necessary:

halbum
	title
	contributor
	image-summary
	duration
	payment

Why should we do the above, when something much simpler would solve the
problem:

halbum
   summary
      haudio

-- manu
From msporny at digitalbazaar.com  Tue Jun  5 17:57:06 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue Jun  5 17:57:09 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <21e770780706051703p427f97b7mcee61c1ab09defb7@mail.gmail.com>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>	<46656BF1.7040907@digitalbazaar.com>	<180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>	<FDE397F9-7DA0-4072-A1F0-B138F928FCEB@lava.net>	<1181086744.11337.8.camel@localhost.localdomain>	<3DAC0D49-AE35-452A-96CC-FFBC3EAB8E18@lava.net>
	<21e770780706051703p427f97b7mcee61c1ab09defb7@mail.gmail.com>
Message-ID: <46660662.7050700@digitalbazaar.com>

Brian Suda wrote:
> --- now we are spiraling back to ideas of what people "WANT" rather
> than model what is being published. 

I agree - we should keep our focus on solving demonstrated needs as
outlined by the audio-info-examples exploratory discussion. Right now,
we are talking about audio albums.

> Another concern i have been having
> about this prososal is that it is more about exposing existing company
> Database Schemas, rather than what the average person is publishing.

Are you saying that hAudio isn't useful to bloggers or website creators?
Or that we should differentiate between independent publishing and
corporate publishing? I didn't think that Microformats made that
distinction - isn't all published data of importance to this community?

-- manu

From timber at lava.net  Tue Jun  5 18:03:23 2007
From: timber at lava.net (Colin Barrett)
Date: Tue Jun  5 18:03:28 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <21e770780706051703p427f97b7mcee61c1ab09defb7@mail.gmail.com>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>
	<46656BF1.7040907@digitalbazaar.com>
	<180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>
	<FDE397F9-7DA0-4072-A1F0-B138F928FCEB@lava.net>
	<1181086744.11337.8.camel@localhost.localdomain>
	<3DAC0D49-AE35-452A-96CC-FFBC3EAB8E18@lava.net>
	<21e770780706051703p427f97b7mcee61c1ab09defb7@mail.gmail.com>
Message-ID: <298F88AA-AFFF-463F-A100-C36A1F0EA5C3@lava.net>

On Jun 5, 2007, at 5:03 PM, Brian Suda wrote:

> Another concern i have been having
> about this prososal is that it is more about exposing existing company
> Database Schemas, rather than what the average person is publishing.

Mmm, perhaps you're right -- hProduct or hListing might be better to  
describe all of that information.

You know, you might want to look at the various ID3 tags, and map  
hablum/haudio off that, similar to what was done with vCard->hCard.  
Those are a pretty meaningful, widely used set of semantics that  
people use quite often, and are also already embedded in many audio  
files.

-Colin
From msporny at digitalbazaar.com  Tue Jun  5 18:29:26 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue Jun  5 18:29:29 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <298F88AA-AFFF-463F-A100-C36A1F0EA5C3@lava.net>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>	<46656BF1.7040907@digitalbazaar.com>	<180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>	<FDE397F9-7DA0-4072-A1F0-B138F928FCEB@lava.net>	<1181086744.11337.8.camel@localhost.localdomain>	<3DAC0D49-AE35-452A-96CC-FFBC3EAB8E18@lava.net>	<21e770780706051703p427f97b7mcee61c1ab09defb7@mail.gmail.com>
	<298F88AA-AFFF-463F-A100-C36A1F0EA5C3@lava.net>
Message-ID: <46660DF6.8030102@digitalbazaar.com>

Colin Barrett wrote:
> On Jun 5, 2007, at 5:03 PM, Brian Suda wrote:
>> Another concern i have been having
>> about this prososal is that it is more about exposing existing company
>> Database Schemas, rather than what the average person is publishing.
> 
> Mmm, perhaps you're right -- hProduct or hListing might be better to
> describe all of that information.

We lose semantic accuracy if we go the hProduct/hListing route... plus
there is no need to bloat those proposals with hAudio cruft that is
clearly not needed for most of the hProduct/hListing entries.

hAudio would fit nicely in the 'description' element of hProduct.

hAudio would also fit nicely in the 'summary' or 'description' element
in hListing.

We shouldn't shoe-horn haudio into other Microformats that have nothing
to do with audio recording markup.

> You know, you might want to look at the various ID3 tags, and map
> hablum/haudio off that, similar to what was done with vCard->hCard.
> Those are a pretty meaningful, widely used set of semantics that people
> use quite often, and are also already embedded in many audio files.

haudio is modeled after ID3, Ogg, MusicBrainz XML, XSPF, and M3U among
others:

http://microformats.org/wiki/audio-info-formats

-- manu
From joe at andrieu.net  Wed Jun  6 00:43:37 2007
From: joe at andrieu.net (Joe Andrieu)
Date: Wed Jun  6 00:43:33 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <46660662.7050700@digitalbazaar.com>
Message-ID: <00aa01c7a80e$65c709e0$0201a8c0@andrieuhome>

Manu Sporny wrote:
> Brian Suda wrote:
> > --- now we are spiraling back to ideas of what people "WANT" rather 
> > than model what is being published.
> 
> I agree - we should keep our focus on solving demonstrated 
> needs as outlined by the audio-info-examples exploratory 
> discussion. Right now, we are talking about audio albums.

Rather than respond in detail to other points, I'd like to make a suggestion.

Why don't we stop worrying about albums and just solve audio-info?

This seems to be the most atomic, simplest case we can address. Playlists, albums, tracks, CDs, etc., are all complications. Once we
get hAudio working, I think it makes sense to talk about what hAlbum might look like--including whether or not it is just another
"type" of hAudio.

There are clearly far more audio pieces on the web than albums, even if all albums are (or have) audio characteristics.

Can we focus on solving this base case and then build from there?

-j

--
Joe Andrieu
SwitchBook Software
http://www.switchbook.com
joe@switchbook.com
+1 (805) 705-8651 


From msporny at digitalbazaar.com  Wed Jun  6 07:22:31 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Wed Jun  6 07:22:35 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <00aa01c7a80e$65c709e0$0201a8c0@andrieuhome>
References: <00aa01c7a80e$65c709e0$0201a8c0@andrieuhome>
Message-ID: <4666C327.9000307@digitalbazaar.com>

Joe Andrieu wrote:
> Manu Sporny wrote:
>> Brian Suda wrote:
>>> --- now we are spiraling back to ideas of what people "WANT" rather 
>>> than model what is being published.
>> I agree - we should keep our focus on solving demonstrated 
>> needs as outlined by the audio-info-examples exploratory 
>> discussion. Right now, we are talking about audio albums.
> 
> Rather than respond in detail to other points, I'd like to 
> make a suggestion.
> 
> Why don't we stop worrying about albums and just solve audio-info?

The reason that we are focusing on albums right now is because the first
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 weeks.

We talked about each element of haudio that was under contention in the
following discussions:

http://microformats.org/discuss/mail/microformats-new/2007-May/000252.html
http://microformats.org/discuss/mail/microformats-new/2007-May/000305.html
http://microformats.org/discuss/mail/microformats-new/2007-May/000316.html
http://microformats.org/discuss/mail/microformats-new/2007-May/000329.html
http://microformats.org/discuss/mail/microformats-new/2007-May/000342.html
http://microformats.org/discuss/mail/microformats-new/2007-May/000349.html
http://microformats.org/discuss/mail/microformats-new/2007-May/000377.html

I believe that the basic haudio draft addresses all of the needs
demonstrated by audio-info-examples.

The only thing that is left to do is address albums. We need to address
albums because they have a very heavy representation in the
audio-info-examples page.

> Can we focus on solving this base case and then build from there?

I believe that we have done a good job at addressing the base cases.

The only reason I am not saying that we've "solved" the haudio base case
is because you don't "solve" the problem in the first draft. We need to
publish something so that people can start playing around with it and
what we have now can address most of the examples (as long as we have
some way of specifying albums). The draft doesn't need to address every
issue under the sun... we will iterate on the concept as long as a need
is demonstrated.

We are doing what you are suggesting, Joe - we've done a good job at
addressing the base case. Now we're seeing if we can build on top of the
base case - audio albums are the first step.

-- manu

From msporny at digitalbazaar.com  Wed Jun  6 07:29:26 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Wed Jun  6 07:29:30 2007
Subject: [uf-new] XOXO + hAudio = Playlist problems
Message-ID: <4666C4C6.3080808@digitalbazaar.com>

Hmm, looks like the xoxo + haudio = playlist position that I've been
defending for playlists has a major problem.

Can somebody please verify or deny that the problem exists. If enough
people can verify that this is a problem I'm going to be dropping my
support for xoxo + haudio = playlist.

In fact, this is a general problem with xoxo for lists embedded in
tables. Many of the audio-info-examples use tables to list track
information.

When you load the following HTML in Firefox, the numbering for the list
gets screwed up. So much for simple playlist markup:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <title>XOXO for Playlists is bad...</title>
  </head>

  <body>

    <p>
       There seems to be quite a problem when using XOXO with
       tables. The numbering of playlist entries does not work as
       expected.
    </p>

    <h1>XOXO Playlist embedded in a table</h1>

    <!-- This is marked up via XOXO in a table -->
    <ol class="xoxo">
      <table border="3">
       <tr><td><li>Song A</li></td><td>Download</td></tr>
       <tr><td><li>Song B</li></td><td>Download</td></tr>
       <tr><td><li>Song C</li></td><td>Download</td></tr>
       <tr><td><li>Song D</li></td><td>Download</td></tr>
      </table>
    </ol>

    <h1>XOXO Playlist without being embedded in a table</h1>
    <!-- This is marked up via XOXO as well, but not in a table -->
    <ol class="xoxo">
       <li>Song A Download</li>
       <li>Song B Download</li>
       <li>Song C Download</li>
       <li>Song D Download</li>
    </ol>
  </body>
</html>

-- manu

From scott at makedatamakesense.com  Wed Jun  6 07:52:11 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Wed Jun  6 07:52:18 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <466603FC.10400@digitalbazaar.com>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>	<46656BF1.7040907@digitalbazaar.com>	<180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>	<FDE397F9-7DA0-4072-A1F0-B138F928FCEB@lava.net>
	<46F56F73-6CB3-4B01-BB03-6409D54A5497@makedatamakesense.com>
	<466603FC.10400@digitalbazaar.com>
Message-ID: <F6EE3869-9BBF-493A-94C6-30CE6C0221BB@makedatamakesense.com>

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,  
>>> f.e.
>>> "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.

> halbum
> 	title
> 	contributor
> 	image-summary
> 	duration
> 	payment
>
> Why should we do the above, when something much simpler would solve  
> the
> problem:
>
> halbum
>    summary
>       haudio

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:

halbum
    summary
       haudio
          title
          contributor
          image-summary
          duration
          payment

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  
> first
> draft of audio-info seems to be done.

I disagree.

> Nobody seems to have raised any
> issues related to existing elements in the haudio draft in several  
> weeks.

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.

--
Scott Reynen
MakeDataMakeSense.com

From taylor_cowan at yahoo.com  Wed Jun  6 08:50:55 2007
From: taylor_cowan at yahoo.com (Taylor Cowan)
Date: Wed Jun  6 08:50:58 2007
Subject: [uf-new] hListing operator script
Message-ID: <352720.40987.qm@web54102.mail.re2.yahoo.com>

http://s3.amazonaws.com/microformat/liveclipboard.js

http://s3.amazonaws.com/microformat/hListing.js



This is an Operator .8 script to parse hListings.  It's an adaptation on hReview that Mike Kapley kindly migrated for operator .8.  There's not much available today formated as hListing, however, it'll parse out listings at http://www.dealtagger.com/.

Along with this liveclipboard.js user script you can copy the listing to the clipboard and past it out (into notepad for example).  The use case I envision would be a wish list tool that lets the user collect hListings from various sites.  Kaboodle is very similar, however, it only knows of ambiguous web snippets.  hListings make it much easier to handle the items, perhaps even making them "alive" with auto price/status updates that come from pingerati.

I'm currently  working with liveclipboard's example to create a prototype product wish-listing tool, however, I'd be more than pleased if somebody beats me to the punch.

Taylor

http://s3.amazonaws.com/microformat/liveclipboard.js
http://s3.amazonaws.com/microformat/hListing.js






      ___________________________________________________________________________________
You snooze, you lose. Get messages ASAP with AutoCheck
in the all-new Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_html.html
From martin at weborganics.co.uk  Wed Jun  6 09:02:11 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Wed Jun  6 09:00:53 2007
Subject: [uf-new] XOXO + hAudio = Playlist problems
In-Reply-To: <4666C4C6.3080808@digitalbazaar.com>
References: <4666C4C6.3080808@digitalbazaar.com>
Message-ID: <1181145731.20645.18.camel@localhost.localdomain>

On Wed, 2007-06-06 at 10:29 -0400, Manu Sporny wrote:
> Hmm, looks like the xoxo + haudio = playlist position that I've been
> defending for playlists has a major problem.
> 
> Can somebody please verify or deny that the problem exists. If enough
> people can verify that this is a problem I'm going to be dropping my
> support for xoxo + haudio = playlist.
> 
> In fact, this is a general problem with xoxo for lists embedded in
> tables. Many of the audio-info-examples use tables to list track
> information.
> 
> When you load the following HTML in Firefox, the numbering for the list
> gets screwed up. So much for simple playlist markup:
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
>   <head>
>     <title>XOXO for Playlists is bad...</title>
>   </head>
> 
>   <body>
> 
>     <p>
>        There seems to be quite a problem when using XOXO with
>        tables. The numbering of playlist entries does not work as
>        expected.
>     </p>
> 
>     <h1>XOXO Playlist embedded in a table</h1>
> 
>     <!-- This is marked up via XOXO in a table -->
>     <ol class="xoxo">
>       <table border="3">
>        <tr><td><li>Song A</li></td><td>Download</td></tr>
>        <tr><td><li>Song B</li></td><td>Download</td></tr>
>        <tr><td><li>Song C</li></td><td>Download</td></tr>
>        <tr><td><li>Song D</li></td><td>Download</td></tr>
>       </table>
>     </ol>

No this is a problem xoxo can not be used in a table this way produces
invalid markup

you would have to mark your table up like this:

<ol class="xoxo">
<li>
<table>
<tr><th axis="track">Song A</th><td axis="acquire">download</td></tr>
<tr><th axis="track">Song B</th><td axis="acquire">download</td></tr>
<tr><th axis="track">Song C</th><td axis="acquire">download</td></tr>
<tr><th axis="track">Song C</th><td axis="acquire">download</td></tr>
</table>
</li>
</ol>

notice I left out border="3" use CSS to do this.

really you are supposed to give each axis property an id attribute too

I don't know if you would lose or gain any semantics using tables 

Tables are nothing that microformats have got round to exploring (Yet)

-martin- 
  
> 
>     <h1>XOXO Playlist without being embedded in a table</h1>
>     <!-- This is marked up via XOXO as well, but not in a table -->
>     <ol class="xoxo">
>        <li>Song A Download</li>
>        <li>Song B Download</li>
>        <li>Song C Download</li>
>        <li>Song D Download</li>
>     </ol>
>   </body>
> </html>
> 
> -- manu
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2171 bytes
Desc: not available
Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070606/5e9accc8/smime-0001.bin
From msporny at digitalbazaar.com  Wed Jun  6 11:31:33 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Wed Jun  6 11:31:35 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>	<46656BF1.7040907@digitalbazaar.com>
	<180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>
Message-ID: <4666FD85.7030302@digitalbazaar.com>

Scott Reynen wrote:
>> 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.

Yep, that was a typo... That should've read "halbum is one of the
grouping Microformats for haudios".

-- manu

From msporny at digitalbazaar.com  Wed Jun  6 12:21:29 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Wed Jun  6 12:21:32 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <F6EE3869-9BBF-493A-94C6-30CE6C0221BB@makedatamakesense.com>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>	<46656BF1.7040907@digitalbazaar.com>	<180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>	<FDE397F9-7DA0-4072-A1F0-B138F928FCEB@lava.net>	<46F56F73-6CB3-4B01-BB03-6409D54A5497@makedatamakesense.com>	<466603FC.10400@digitalbazaar.com>
	<F6EE3869-9BBF-493A-94C6-30CE6C0221BB@makedatamakesense.com>
Message-ID: <46670939.6020703@digitalbazaar.com>

Scott Reynen wrote:
>> Nobody seems to have raised any
>> issues related to existing elements in the haudio draft in several weeks.
> 
> 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.

No, I am not saying that there is complete consensus over everything
we're talking about in hAudio. I think there is a rough consensus over
the following items being important in haudio:

 * hAudio (haudio)
   o fn (aka formatted name). required. text (re-used from hcard).
   o contributor. optional. using hCard.
      + suggested 'role's: speaker, artist, composer, band, publisher
   o published-date. optional. using datetime-design-pattern.
   o sample. optional. using rel-design-pattern with sample as the
     mf-rel-value.
   o rel-enclosure and rel-payment. optional. acquisition using URL
     and rel-enclosure and rel-payment design patterns.
   o image-summary. optional. using HTML and XHTML tag img.
   o category. optional. text.
   o duration. optional. ISO-8601 time duration using
                         abbr-design-pattern (re-used from hcalendar).
   o price. optional. using currency-proposal.

The halbum topic is currently being debated heavily:

halbum
    summary
      haudio
    track
      haudio
    track
      haudio

vs.

halbum
    title
    contributor
    image-summary
    duration
    payment
    haudio
    haudio
    haudio

-- manu
From scott at makedatamakesense.com  Wed Jun  6 14:25:26 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Wed Jun  6 14:25:32 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <46670939.6020703@digitalbazaar.com>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>	<46656BF1.7040907@digitalbazaar.com>	<180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>	<FDE397F9-7DA0-4072-A1F0-B138F928FCEB@lava.net>	<46F56F73-6CB3-4B01-BB03-6409D54A5497@makedatamakesense.com>	<466603FC.10400@digitalbazaar.com>
	<F6EE3869-9BBF-493A-94C6-30CE6C0221BB@makedatamakesense.com>
	<46670939.6020703@digitalbazaar.com>
Message-ID: <EDFD4EAF-7B95-494D-AF08-5B6A49620DE6@makedatamakesense.com>

On Jun 6, 2007, at 1:21 PM, Manu Sporny wrote:

>  I think there is a rough consensus over
> the following items being important in haudio:
>
>  * hAudio (haudio)

[snip]

> The halbum topic is currently being debated heavily:
>
> halbum
>     summary
>       haudio
>     track
>       haudio
>     track
>       haudio
>
> vs.
>
> halbum
>     title
>     contributor
>     image-summary
>     duration
>     payment
>     haudio
>     haudio
>     haudio

It seems to me the main reason this is being debated is that it's not  
yet clear what "haudio" means.  The former suggestion treats it as an  
abstract container for metadata, which doesn't correlate directly to  
any real world concept.  The latter suggestion treats it as a track.   
This is coming up in the album discussion, but it's fundamental to  
haudio.  I think this stems from two separate problem statements:

http://microformats.org/wiki/audio-info-brainstorming#Purpose
http://microformats.org/wiki/audio-info-examples#The_Problem

In hindsight, there never should have been two separate problem  
statements, but now we have to decide which one we're actually trying  
to solve.  Specifically, does "haudio" describe "information about  
one or more audio recordings" or "information about an audio  
recording"?  The difference seems subtle at first, but after noting  
how the former definition matches the former album schema, and the  
latter definition matches the latter album schema, it looks like a  
significant difference we need to work out.

I personally prefer the latter, as it's describing a more specific  
concept, i.e. a single recording rather than one or more recordings.

--
Scott Reynen
MakeDataMakeSense.com


From joe at andrieu.net  Wed Jun  6 15:40:00 2007
From: joe at andrieu.net (Joe Andrieu)
Date: Wed Jun  6 15:39:56 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <EDFD4EAF-7B95-494D-AF08-5B6A49620DE6@makedatamakesense.com>
Message-ID: <004e01c7a88b$9ebac7f0$19fa030a@andrieuhome>

Scott Reynen wrote:
> Sent: Wednesday, June 06, 2007 2:25 PM
> To: For discussion of new microformats.
> Subject: Re: [uf-new] hAudio - audio-album and audio-podcast
> 
> 
> On Jun 6, 2007, at 1:21 PM, Manu Sporny wrote:
> 
> >  I think there is a rough consensus over
> > the following items being important in haudio:
> >
> >  * hAudio (haudio)
> 
> [snip]
> 
> > The halbum topic is currently being debated heavily:
> >
> > halbum
> >     summary
> >       haudio
> >     track
> >       haudio
> >     track
> >       haudio
> >
> > vs.
> >
> > halbum
> >     title
> >     contributor
> >     image-summary
> >     duration
> >     payment
> >     haudio
> >     haudio
> >     haudio
> 
> It seems to me the main reason this is being debated is that 
> it's not  
> yet clear what "haudio" means.  The former suggestion treats 
> it as an  
> abstract container for metadata, which doesn't correlate directly to  
> any real world concept.  The latter suggestion treats it as a 
> track.   
> This is coming up in the album discussion, but it's fundamental to  
> haudio.  I think this stems from two separate problem statements:
> 
> http://microformats.org/wiki/audio-info-brainstorming#Purpose
> http://microformats.org/wiki/audio-info-examples#The_Problem
> 
> In hindsight, there never should have been two separate problem  
> statements, but now we have to decide which one we're 
> actually trying  
> to solve.  Specifically, does "haudio" describe "information about  
> one or more audio recordings" or "information about an audio  
> recording"?  The difference seems subtle at first, but after noting  
> how the former definition matches the former album schema, and the  
> latter definition matches the latter album schema, it looks like a  
> significant difference we need to work out.
> 
> I personally prefer the latter, as it's describing a more specific  
> concept, i.e. a single recording rather than one or more recordings.


There seemed to be partial agreement that hAudio means the individual audio recording, that being the simplest case to solve,
although I agree with the contradiction in the above problem statements. The answer for multiple audio recordings on a page is to
have multiple hAudio. Dealing with "smart" ways to group hAudio is a different problem.

Let's solve the case of an individual audio recording as hAudio, update the examples and the schema, and "publish" it as a uF.
There's a lot of work between here and there, but I think it is the right goal.

Once we get /that/ done, then let's go back and see if hAlbum or hPlaylist or hPodcast or some other container class is worth doing.

I for one, don't understand why hAudio doesn't include the actual audio file. But that's not worth discussing until we can get
closure on what hAudio is.

-j

--
Joe Andrieu
SwitchBook Software
http://www.switchbook.com
joe@switchbook.com
+1 (805) 705-8651 


From andy at pigsonthewing.org.uk  Thu Jun  7 01:55:18 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Thu Jun  7 01:57:22 2007
Subject: [uf-new] "Species" Straw Man deployed on Wikipedia
Message-ID: <h39SEDQ2f8ZGFwM5@pigsonthewing.org.uk>


The current "straw man" for the Species microformat:

   <http://microformats.org/wiki/species-brainstorming#Straw_man_proposal>

has been deployed, in part, on Wikipedia.

*All* Wikipedia articles with "taxoboxes" (information panels on living 
things; and there are thousands):

   <http://en.wikipedia.org/wiki/Template:Taxobox>

now emit a species microformat. For example:

   <http://en.wikipedia.org/wiki/Southern_Tamandua> (a species)

   <http://en.wikipedia.org/wiki/Anteater> (a family of species)

These are recognised (with some issues, being worked on) by the 
"Species" user script for Operator 0.7 (and the beta version of the next 
release, 0.8a)

It now remains to firm-up the specification, and tweak the Wikipedia 
deployment accordingly.

Such discussion should take place on "microformats-new", to which I've 
cross-posted and set follow-ups.

-- 
Andy Mabbett
From andy at pigsonthewing.org.uk  Thu Jun  7 03:44:15 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Thu Jun  7 03:45:49 2007
Subject: [uf-new] hAudio: relevant UIDs
In-Reply-To: <46670939.6020703@digitalbazaar.com>
References: <006a01c7a709$1ea0d6f0$0201a8c0@andrieuhome>
	<46656BF1.7040907@digitalbazaar.com>
	<180C3D22-B39D-4BC6-AC66-505E7360C172@makedatamakesense.com>
	<FDE397F9-7DA0-4072-A1F0-B138F928FCEB@lava.net>
	<46F56F73-6CB3-4B01-BB03-6409D54A5497@makedatamakesense.com>
	<466603FC.10400@digitalbazaar.com>
	<F6EE3869-9BBF-493A-94C6-30CE6C0221BB@makedatamakesense.com>
	<46670939.6020703@digitalbazaar.com>
Message-ID: <Hlf7gzT$F+ZGFwoL@pigsonthewing.org.uk>


Any hAudio/ hMedia microformats should allow for:

   *    ISO 15706 International Standard Audiovisual Number (ISAN)

   *    ISO 15707 International Standard Musical Work Code (ISWC)

   *    ISO 10957 International Standard Music Number (ISMN)

   *    ISO 3901 International Standard Recording Code (ISRC)

   *    Project 27729 International Standard Party Identifier (ISPI)

which are the equivalents of ISBN; perhaps by including a one or more
UID type/ value pairs.

See, for example,

        <http://en.wikipedia.org/wiki/ISRC>

(with links to other relevant pages at i