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 its foot).

-- 
Andy Mabbett
From martin at weborganics.co.uk  Thu Jun  7 05:37:40 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Thu Jun  7 05:36:19 2007
Subject: [uf-new] hAudio: relevant UIDs
In-Reply-To: <Hlf7gzT$F+ZGFwoL@pigsonthewing.org.uk>
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>
	<Hlf7gzT$F+ZGFwoL@pigsonthewing.org.uk>
Message-ID: <1181219860.25598.9.camel@localhost.localdomain>

Hello Andy

On Thu, 2007-06-07 at 11:44 +0100, Andy Mabbett wrote:
> 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.

Unfortunately I can't find any examples on the
media-info/audio-info-examples wiki showing why hAudio would need this.

Can you add some examples to the wiki to display why hAudio needs this?

Do you think that the url of a down-loadable file is a UID of sorts?

-Martin-
> 
> See, for example,
> 
>         <http://en.wikipedia.org/wiki/ISRC>
> 
> (with links to other relevant pages at its foot).
> 
-------------- 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/20070607/2ecf1648/smime.bin
From andy at pigsonthewing.org.uk  Thu Jun  7 06:23:26 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Thu Jun  7 06:24:49 2007
Subject: [uf-new] hAudio: relevant UIDs
In-Reply-To: <1181219860.25598.9.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>
	<46F56F73-6CB3-4B01-BB03-6409D54A5497@makedatamakesense.com>
	<466603FC.10400@digitalbazaar.com>
	<F6EE3869-9BBF-493A-94C6-30CE6C0221BB@makedatamakesense.com>
	<46670939.6020703@digitalbazaar.com>
	<Hlf7gzT$F+ZGFwoL@pigsonthewing.org.uk>
	<1181219860.25598.9.camel@localhost.localdomain>
Message-ID: <3JQ3bIZObAaGFwU6@pigsonthewing.org.uk>

In message <1181219860.25598.9.camel@localhost.localdomain>, Martin
McEvoy <martin@weborganics.co.uk> writes

>Can you add some examples to the wiki to display why hAudio needs this?

I don't have time, but to start you off, here are some for Elgar and
Beethoven:

        <http://www.google.co.uk/search?q=elgar+ISMN>

        <http://www.google.co.uk/search?q=elgar+ISRC>

        <http://www.google.co.uk/search&q=beethoven+ISWC>

        (on the latter, you may need to start looking on the second
        page, as "ISWC" has other, popular meanings)

Besides, they're *ISO* international standards.

>Do you think that the url of a down-loadable file is a UID of sorts?

It uniquely identifies that particular instance; however it does not
uniquely identify that song or performance (or whatever).

Compare with the URL of a book for sale on Amazon, a copy of the same
book for sale on eBay, and the common ISBN for both copies.


You have incidentally illustrated one of the problems with the
"microformats process"  the evidence gathering is ad hoc and may be
unrepresentative, incomplete or biased (the later including, but not
limited to, cultural and linguistic bias).

-- 
Andy Mabbett
            *  Say "NO!" to compulsory UK ID Cards:  <http://www.no2id.net/>
            *  Free Our Data:  <http://www.freeourdata.org.uk>
            *  Are you using Microformats, yet: <http://microformats.org/> ?
From andy at pigsonthewing.org.uk  Thu Jun  7 06:51:55 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Thu Jun  7 06:53:02 2007
Subject: [uf-new] hAudio: relevant UIDs
In-Reply-To: <3JQ3bIZObAaGFwU6@pigsonthewing.org.uk>
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>
	<Hlf7gzT$F+ZGFwoL@pigsonthewing.org.uk>
	<1181219860.25598.9.camel@localhost.localdomain>
	<3JQ3bIZObAaGFwU6@pigsonthewing.org.uk>
Message-ID: <tZ9xPba71AaGFwXy@pigsonthewing.org.uk>

In message <3JQ3bIZObAaGFwU6@pigsonthewing.org.uk>, Andy Mabbett
<andy@pigsonthewing.org.uk> writes

>>Do you think that the url of a down-loadable file is a UID of sorts?
>
>It uniquely identifies that particular instance; however it does not
>uniquely identify that song or performance (or whatever).

More accurately, it may "uniquely" identify the song or recording, but
it doesn't uniquely identify it in a transferable, interoperable way.

-- 
Andy Mabbett
            *  Say "NO!" to compulsory UK ID Cards:  <http://www.no2id.net/>
            *  Free Our Data:  <http://www.freeourdata.org.uk>
            *  Are you using Microformats, yet: <http://microformats.org/> ?
From scott at makedatamakesense.com  Thu Jun  7 07:38:33 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Thu Jun  7 07:38:39 2007
Subject: [uf-new] hAudio: relevant UIDs
In-Reply-To: <Hlf7gzT$F+ZGFwoL@pigsonthewing.org.uk>
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>
	<Hlf7gzT$F+ZGFwoL@pigsonthewing.org.uk>
Message-ID: <82AB359C-3201-4420-92F0-4FD8FABF2036@makedatamakesense.com>

On Jun 7, 2007, at 4:44 AM, Andy Mabbett wrote:

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

What exactly do you mean by "allow for"?  Pretty much anything can be  
inserted into any HTML markup, so to that extent it's impossible to  
disallow any of this.  But if you mean we need to develop markup for  
this as part of the spec, I disagree, as it doesn't appear to be very  
common in HTML publishing.

On Jun 7, 2007, at 7:23 AM, Andy Mabbett wrote:

> <http://www.google.co.uk/search?q=elgar+ISMN>

That has 536 results.

http://www.google.co.uk/search?q=elgar

That has 6,120,000 results.

> <http://www.google.co.uk/search?q=elgar+ISRC>

That has 27,500 results.

>         <http://www.google.co.uk/search&q=beethoven+ISWC>

That has 13,400 results.

http://www.google.co.uk/search?q=beethoven

That has 24,400,000 results.

This cursory skim of real world publishing suggests to me that these  
ISO standards account for a very small portion (less than 1%) of our  
problem set.  If anyone is interested, obviously a more detailed  
analysis would provide more accurate information, but I don't  
personally see much cause for interest.

> Besides, they're *ISO* international standards.

That doesn't mean people are actually using them.  Let's first model  
data people are already publishing most widely, and leave the less- 
commonly published data for future versions.

--
Scott Reynen
MakeDataMakeSense.com


From andy at pigsonthewing.org.uk  Thu Jun  7 07:55:44 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Thu Jun  7 07:57:23 2007
Subject: [uf-new] hAudio: relevant UIDs
In-Reply-To: <82AB359C-3201-4420-92F0-4FD8FABF2036@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>
	<46670939.6020703@digitalbazaar.com>
	<Hlf7gzT$F+ZGFwoL@pigsonthewing.org.uk>
	<82AB359C-3201-4420-92F0-4FD8FABF2036@makedatamakesense.com>
Message-ID: <0pv3jvfwxBaGFwHh@pigsonthewing.org.uk>

In message <82AB359C-3201-4420-92F0-4FD8FABF2036@makedatamakesense.com>,
Scott Reynen <scott@makedatamakesense.com> writes

>http://www.google.co.uk/search?q=elgar
>
>That has 6,120,000 results.
>
>> <http://www.google.co.uk/search?q=elgar+ISRC>
>
>That has 27,500 results.
>
>>         <http://www.google.co.uk/search&q=beethoven+ISWC>
>
>That has 13,400 results.
>
>http://www.google.co.uk/search?q=beethoven
>
>That has 24,400,000 results.
>
>This cursory skim of real world publishing suggests to me that these
>ISO standards account for a very small portion (less than 1%) of our
>problem set.

You're using a bogus comparison, calculating "the proportion of sites
mentioning Elgar/ Beethoven which use ISO codes", instead of "the
proportion of sites publishing downloadable Elgar/ Beethoven audio (or
whatever) which use ISO codes".

>  If anyone is interested, obviously a more detailed  analysis would
>provide more accurate information, but I don't  personally see much
>cause for interest.
>
>> Besides, they're *ISO* international standards.
>
>That doesn't mean people are actually using them.

ISO don't write standards to keep themselves busy. Of course people are
using them.

How much of our "evidence" is obtained from b2b sites? How many people
with professional experience of music retailing, licensing or related
fields have contributed to the discussion? How much effort was made to
contact such people, in the fora they're likely to be using as part of
their work?


And are Google results acceptable as "evidence of lack of use", if
they're not allowed - by the "process" - as "evidence of use" ?

-- 
Andy Mabbett
            *  Say "NO!" to compulsory UK ID Cards:  <http://www.no2id.net/>
            *  Free Our Data:  <http://www.freeourdata.org.uk>
            *  Are you using Microformats, yet: <http://microformats.org/> ?
From msporny at digitalbazaar.com  Thu Jun  7 08:36:23 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Thu Jun  7 08:36:26 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <004e01c7a88b$9ebac7f0$19fa030a@andrieuhome>
References: <004e01c7a88b$9ebac7f0$19fa030a@andrieuhome>
Message-ID: <466825F7.1060300@digitalbazaar.com>

Joe Andrieu wrote:
> 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.

I agree with both you and Scott. Martin also made a good point in an
off-list e-mail for dropping halbum for now because it is confusing
people. So, let's drop audio grouping (halbum) for now.

We will re-visit halbum after we get haudio out of the door...

Let's clarify haudio to deal with individual audio recording, not groups
of audio recordings. I'll update hAudio and post the modifications to
the list for feedback.

-- manu

From scott at makedatamakesense.com  Thu Jun  7 08:58:27 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Thu Jun  7 08:58:33 2007
Subject: [uf-new] hAudio: relevant UIDs
In-Reply-To: <0pv3jvfwxBaGFwHh@pigsonthewing.org.uk>
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>
	<Hlf7gzT$F+ZGFwoL@pigsonthewing.org.uk>
	<82AB359C-3201-4420-92F0-4FD8FABF2036@makedatamakesense.com>
	<0pv3jvfwxBaGFwHh@pigsonthewing.org.uk>
Message-ID: <0A5E9F97-8D26-4AB0-B807-6925ED121A1C@makedatamakesense.com>

On Jun 7, 2007, at 8:55 AM, Andy Mabbett wrote:

>> This cursory skim of real world publishing suggests to me that these
>> ISO standards account for a very small portion (less than 1%) of our
>> problem set.
>
> You're using a bogus comparison, calculating "the proportion of sites
> mentioning Elgar/ Beethoven which use ISO codes", instead of "the
> proportion of sites publishing downloadable Elgar/ Beethoven audio (or
> whatever) which use ISO codes".

Not to suggest the comparison was particularly useful (merely enough  
to prevent me from becoming interested in UIDs in haudio), but I was  
under the impression haudio is not restricted to downloadable audio.

>>  Besides, they're *ISO* international standards.
>>
>> That doesn't mean people are actually using them.
>
> ISO don't write standards to keep themselves busy. Of course people  
> are
> using them.

Yeah, I should have said "many people."  Regardless of my poor word  
choice and vague metrics, my point is just that I don't yet see  
enough publishing of UIDs with audio to interest me in investigating  
further.  I presumed your goal was convincing active participants in  
the haudio discussion of the importance of UIDs in haudio, and you'd  
want to know that it wasn't yet accomplished in my case.  But if  
others are interested, I certainly wouldn't attempt to prevent  
further research.  Indeed, I would encourage it.

--
Scott Reynen
MakeDataMakeSense.com


From msporny at digitalbazaar.com  Thu Jun  7 10:10:28 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Thu Jun  7 10:10:30 2007
Subject: [uf-new] Third attempt at hAudio
Message-ID: <46683C04.4050006@digitalbazaar.com>

hAudio has been updated:

* Noted that hAudio deals with individual audio recordings
* Removed any reference to grouping
* Updated to match the latest discussions on the list
* Many other small edits and cleanups

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

Most everything that was under contention has been removed from the
latest haudio proposal. Constructive feedback from this list would be
great...

-- manu

From martin at weborganics.co.uk  Thu Jun  7 10:15:13 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Thu Jun  7 10:13:45 2007
Subject: [uf-new] hAudio - audio-album and audio-podcast
In-Reply-To: <466825F7.1060300@digitalbazaar.com>
References: <004e01c7a88b$9ebac7f0$19fa030a@andrieuhome>
	<466825F7.1060300@digitalbazaar.com>
Message-ID: <1181236513.3189.50.camel@localhost.localdomain>

On Thu, 2007-06-07 at 11:36 -0400, Manu Sporny wrote:
> Joe Andrieu wrote:
> > 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.
> 
> I agree with both you and Scott. Martin also made a good point in an
> off-list e-mail for dropping halbum for now because it is confusing
> people. So, let's drop audio grouping (halbum) for now.

Good call 

something we can all agree on?


-Martin-
> 
> We will re-visit halbum after we get haudio out of the door...
> 
> Let's clarify haudio to deal with individual audio recording, not groups
> of audio recordings. I'll update hAudio and post the modifications to
> the list for feedback.
> 
> -- 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/20070607/d843926a/smime.bin
From scott at makedatamakesense.com  Thu Jun  7 10:44:34 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Thu Jun  7 10:44:38 2007
Subject: [uf-new] Third attempt at hAudio
In-Reply-To: <46683C04.4050006@digitalbazaar.com>
References: <46683C04.4050006@digitalbazaar.com>
Message-ID: <9622E680-36C0-492E-A530-B21832CA5052@makedatamakesense.com>


On Jun 7, 2007, at 11:10 AM, Manu Sporny wrote:

> hAudio has been updated:
>
> * Noted that hAudio deals with individual audio recordings
> * Removed any reference to grouping
> * Updated to match the latest discussions on the list
> * Many other small edits and cleanups
>
> http://microformats.org/wiki/audio-info-proposal
>
> Most everything that was under contention has been removed from the
> latest haudio proposal. Constructive feedback from this list would be
> great...

Looks great.  I'll try implement it on one of my sites in the next  
couple days, play around with making a parsing tool or two, and see  
if any issues come up.

--
Scott Reynen
MakeDataMakeSense.com


From martin at weborganics.co.uk  Thu Jun  7 10:47:53 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Thu Jun  7 10:46:25 2007
Subject: [uf-new] Third attempt at hAudio
In-Reply-To: <46683C04.4050006@digitalbazaar.com>
References: <46683C04.4050006@digitalbazaar.com>
Message-ID: <1181238473.3189.71.camel@localhost.localdomain>

On Thu, 2007-06-07 at 13:10 -0400, Manu Sporny wrote:
> hAudio has been updated:
> 
> * Noted that hAudio deals with individual audio recordings
> * Removed any reference to grouping
> * Updated to match the latest discussions on the list
> * Many other small edits and cleanups
> 
> http://microformats.org/wiki/audio-info-proposal
> 
> Most everything that was under contention has been removed from the
> latest haudio proposal. Constructive feedback from this list would be
> great...
> 
> -- manu
trust me to have a question but here it is 

from the wiki 
http://microformats.org/wiki/audio-info-proposal

"Formatted Name 
The Formatted Name of an audio recording is a short textual description
used to identify the work among interested parties. This is also
referred to as the title of the work. This can be the title of a speech,
song title, or short description regarding a sound effect."

should we should re-use "summary" from hReview ?
http://microformats.org/wiki/hreview#Schema

"summary:: This optional field serves as a title for the review itself."

In hAudio summary would have to be a required field, the title of an
audio is a summary of the entire track?

It helps not to confuse the title of a hAudio with a contained vCard and
I think it has better meaning

thanks

-Martin-

> 
> _______________________________________________
> 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/20070607/fca1b1f6/smime-0001.bin
From brian.suda at gmail.com  Thu Jun  7 10:50:03 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Thu Jun  7 10:51:49 2007
Subject: [uf-new] Third attempt at hAudio
In-Reply-To: <1181238473.3189.71.camel@localhost.localdomain>
References: <46683C04.4050006@digitalbazaar.com>
	<1181238473.3189.71.camel@localhost.localdomain>
Message-ID: <21e770780706071050i2c8fe0d6j8e5a3e85b42ec284@mail.gmail.com>

On 6/7/07, Martin McEvoy <martin@weborganics.co.uk> wrote:
> should we should re-use "summary" from hReview ?
> http://microformats.org/wiki/hreview#Schema
>
> "summary:: This optional field serves as a title for the review itself."
>
> It helps not to confuse the title of a hAudio with a contained vCard and
> I think it has better meaning

--- i had the same thought myself. I think we should consider this
swap so it is also more inline with hReview and avoid confusion of FN
in the contributor and well as the FN of the container.

-brian

-- 
brian suda
http://suda.co.uk
From msporny at digitalbazaar.com  Thu Jun  7 11:17:41 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Thu Jun  7 11:17:44 2007
Subject: [uf-new] Third attempt at hAudio
In-Reply-To: <21e770780706071050i2c8fe0d6j8e5a3e85b42ec284@mail.gmail.com>
References: <46683C04.4050006@digitalbazaar.com>	<1181238473.3189.71.camel@localhost.localdomain>
	<21e770780706071050i2c8fe0d6j8e5a3e85b42ec284@mail.gmail.com>
Message-ID: <46684BC5.6010600@digitalbazaar.com>

Brian Suda wrote:
> On 6/7/07, Martin McEvoy <martin@weborganics.co.uk> wrote:
>> should we should re-use "summary" from hReview ?
>> http://microformats.org/wiki/hreview#Schema
>>
>> "summary:: This optional field serves as a title for the review itself."
>>
>> It helps not to confuse the title of a hAudio with a contained vCard and
>> I think it has better meaning
> 
> --- i had the same thought myself. I think we should consider this
> swap so it is also more inline with hReview and avoid confusion of FN
> in the contributor and well as the FN of the container.

Any objections to changing 'fn' to 'summary'? I definitely like
'summary' much more than 'fn'.

Ideally, we would be using 'title' - why can't we do that, again?
Because hcard uses it?

When the proposal started out, as Martin pointed out in an earlier
discussion, we started with 'work-title'.

What are the arguments against using 'title'? The only one that I can
think of is "hcard already uses it". The use of 'title' with haudio
seems to be a much more correct use of the word "title" that could be
used in hAudio, hVideo, hPublication, hMedia, etc.

-- manu
From brian.suda at gmail.com  Thu Jun  7 11:50:39 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Thu Jun  7 11:50:43 2007
Subject: [uf-new] Third attempt at hAudio
In-Reply-To: <46684BC5.6010600@digitalbazaar.com>
References: <46683C04.4050006@digitalbazaar.com>
	<1181238473.3189.71.camel@localhost.localdomain>
	<21e770780706071050i2c8fe0d6j8e5a3e85b42ec284@mail.gmail.com>
	<46684BC5.6010600@digitalbazaar.com>
Message-ID: <21e770780706071150s41a4cd73i2df7207cd533c52e@mail.gmail.com>

On 6/7/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> Ideally, we would be using 'title' - why can't we do that, again?
> Because hcard uses it?

--- because the semantics of TITLE have already been defined as
something else. It is irrelevant that hCard uses it, the semantics are
not what you intend.

TITLE: Job title or functional position of the object.

http://microformats.org/wiki/classes

> When the proposal started out, as Martin pointed out in an earlier
> discussion, we started with 'work-title'.
>
> What are the arguments against using 'title'? The only one that I can
> think of is "hcard already uses it".

--- because the semantics of TITLE are already defined. Work-title
unnecessarily re-defines the semantics of FN and SUMAMRY so there is
no need for it.

Point 4 in the process[1] says you should be aware of microformats
naming principles when choosing names.

Please make yourself aware of the process. If we are going to get
through this proposal, you MUST read the process and understand it.
This means being aware of other microformats in general and what
properties they defined and how they impact your proposal as a whole.

There is also the archives of this thread where these were already discussed.

Tue May 8 13:20:56 PDT 2007,  Manu Sporny msporny at digitalbazaar.com
 came to the conclusion that 'work-title' was not needed, you can read
that discussion here:
http://microformats.org/discuss/mail/microformats-new/2007-May/000353.html

-brian

[1] - http://microformats.org/wiki/process

-- 
brian suda
http://suda.co.uk
From martin at weborganics.co.uk  Thu Jun  7 12:00:39 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Thu Jun  7 11:59:11 2007
Subject: [uf-new] Third attempt at hAudio
In-Reply-To: <46684BC5.6010600@digitalbazaar.com>
References: <46683C04.4050006@digitalbazaar.com>
	<1181238473.3189.71.camel@localhost.localdomain>
	<21e770780706071050i2c8fe0d6j8e5a3e85b42ec284@mail.gmail.com>
	<46684BC5.6010600@digitalbazaar.com>
Message-ID: <1181242839.3189.102.camel@localhost.localdomain>

On Thu, 2007-06-07 at 14:17 -0400, Manu Sporny wrote:
> Brian Suda wrote:
> > On 6/7/07, Martin McEvoy <martin@weborganics.co.uk> wrote:
> >> should we should re-use "summary" from hReview ?
> >> http://microformats.org/wiki/hreview#Schema
> >>
> >> "summary:: This optional field serves as a title for the review itself."
> >>
> >> It helps not to confuse the title of a hAudio with a contained vCard and
> >> I think it has better meaning
> > 
> > --- i had the same thought myself. I think we should consider this
> > swap so it is also more inline with hReview and avoid confusion of FN
> > in the contributor and well as the FN of the container.
> 
> Any objections to changing 'fn' to 'summary'? I definitely like
> 'summary' much more than 'fn'.
> 
> Ideally, we would be using 'title' - why can't we do that, again?
> Because hcard uses it?
> 
> When the proposal started out, as Martin pointed out in an earlier
> discussion, we started with 'work-title'.

Personally I was not a supporter of changing work-title in the first
place...
 
> 
> What are the arguments against using 'title'? The only one that I can
> think of is "hcard already uses it". The use of 'title' with haudio
> seems to be a much more correct use of the word "title" that could be
> used in hAudio, hVideo, hPublication, hMedia, etc.

Yes this would be preferable it certainly has a better meaning than
summary. I initialy thought this, It fits in with existing methods in
use and concepts already discussed, 

but as you say it may be mistaken an misunderstood as re-use of title
from vCard which it is not, and its the same kind of thing we are trying
to avoid in with "fn". 

I would prefer users to understand or misunderstand what hAudio is
trying to describe as a re-use of the summary attribute from hreview It
makes it easy.

I also think that in any future evolution of hAudio for example hAlbum,
hCast etc, may rely on a "title" attribute of some kind for its meaning.

In most cases an audio track is one of many tracks, to give all these a
title attribute may be excessive and lead to confusion again.

-Martin-
 
> 
> -- 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/20070607/528dd99e/smime.bin
From brian.suda at gmail.com  Thu Jun  7 12:06:18 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Thu Jun  7 12:06:21 2007
Subject: [uf-new] Third attempt at hAudio
In-Reply-To: <1181242839.3189.102.camel@localhost.localdomain>
References: <46683C04.4050006@digitalbazaar.com>
	<1181238473.3189.71.camel@localhost.localdomain>
	<21e770780706071050i2c8fe0d6j8e5a3e85b42ec284@mail.gmail.com>
	<46684BC5.6010600@digitalbazaar.com>
	<1181242839.3189.102.camel@localhost.localdomain>
Message-ID: <21e770780706071206p4d4e9244t8933cb9044d00301@mail.gmail.com>

On 6/7/07, Martin McEvoy <martin@weborganics.co.uk> wrote:
> I also think that in any future evolution of hAudio for example hAlbum,
> hCast etc, may rely on a "title" attribute of some kind for its meaning.

--- it is best to not to think about theoretical issues before we even
have any sort of audio format. Much like hAtom, this can be easily
solved at the schema level. hAtom for instance uses rel-tag for
individual entries, but also for hFeed itself. Because we control the
semantics of hFeed it is easy to simply say "find all rel-tags that
are children that are NOT in an entry",  if/when we create a container
such as album, we can do the same thing and say use the
class="summary|foobar" that is NOT inside track data. We can resuse
properties easily without confusion because we control the schema of
the data.

-brian

-- 
brian suda
http://suda.co.uk
From martin at weborganics.co.uk  Thu Jun  7 12:14:46 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Thu Jun  7 12:13:21 2007
Subject: [uf-new] Third attempt at hAudio
In-Reply-To: <21e770780706071206p4d4e9244t8933cb9044d00301@mail.gmail.com>
References: <46683C04.4050006@digitalbazaar.com>
	<1181238473.3189.71.camel@localhost.localdomain>
	<21e770780706071050i2c8fe0d6j8e5a3e85b42ec284@mail.gmail.com>
	<46684BC5.6010600@digitalbazaar.com>
	<1181242839.3189.102.camel@localhost.localdomain>
	<21e770780706071206p4d4e9244t8933cb9044d00301@mail.gmail.com>
Message-ID: <1181243686.3189.106.camel@localhost.localdomain>

On Thu, 2007-06-07 at 19:06 +0000, Brian Suda wrote:
> On 6/7/07, Martin McEvoy <martin@weborganics.co.uk> wrote:
> > I also think that in any future evolution of hAudio for example hAlbum,
> > hCast etc, may rely on a "title" attribute of some kind for its meaning.
> 
> --- it is best to not to think about theoretical issues before we even
> have any sort of audio format. Much like hAtom, this can be easily
> solved at the schema level. hAtom for instance uses rel-tag for
> individual entries, but also for hFeed itself. Because we control the
> semantics of hFeed it is easy to simply say "find all rel-tags that
> are children that are NOT in an entry",  if/when we create a container
> such as album, we can do the same thing and say use the
> class="summary|foobar" that is NOT inside track data. We can resuse
> properties easily without confusion because we control the schema of
> the data.

agreed I think many of us do like to think ahead sometimes even if we
shouldn't, 

never the less point taken, disregard

"I also think that in any future evolution of hAudio for example hAlbum,
hCast etc, may rely on a "title" attribute of some kind for its
meaning."

-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/20070607/f38d8d37/smime.bin
From martin at weborganics.co.uk  Thu Jun  7 12:36:39 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Thu Jun  7 12:35:12 2007
Subject: [uf-new] Third attempt at hAudio
In-Reply-To: <21e770780706071150s41a4cd73i2df7207cd533c52e@mail.gmail.com>
References: <46683C04.4050006@digitalbazaar.com>
	<1181238473.3189.71.camel@localhost.localdomain>
	<21e770780706071050i2c8fe0d6j8e5a3e85b42ec284@mail.gmail.com>
	<46684BC5.6010600@digitalbazaar.com>
	<21e770780706071150s41a4cd73i2df7207cd533c52e@mail.gmail.com>
Message-ID: <1181244999.3189.114.camel@localhost.localdomain>

You could probably also argue that a "tile" attribute would represent a
defining term of an object which in the case of a single audio track is
not the case. song titles are usually just a summary of a song.

eg:

"love is in the air" John Paul Young
"Ghost Town" The Specials
"Symphony No. 6 in A minor" Gustav Mahler

-martin-

On Thu, 2007-06-07 at 18:50 +0000, Brian Suda wrote:
> On 6/7/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> > Ideally, we would be using 'title' - why can't we do that, again?
> > Because hcard uses it?
> 
> --- because the semantics of TITLE have already been defined as
> something else. It is irrelevant that hCard uses it, the semantics are
> not what you intend.
> 
> TITLE: Job title or functional position of the object.
> 
> http://microformats.org/wiki/classes
> 
> > When the proposal started out, as Martin pointed out in an earlier
> > discussion, we started with 'work-title'.
> >
> > What are the arguments against using 'title'? The only one that I can
> > think of is "hcard already uses it".
> 
> --- because the semantics of TITLE are already defined. Work-title
> unnecessarily re-defines the semantics of FN and SUMAMRY so there is
> no need for it.
> 
> Point 4 in the process[1] says you should be aware of microformats
> naming principles when choosing names.
> 
> Please make yourself aware of the process. If we are going to get
> through this proposal, you MUST read the process and understand it.
> This means being aware of other microformats in general and what
> properties they defined and how they impact your proposal as a whole.
> 
> There is also the archives of this thread where these were already discussed.
> 
> Tue May 8 13:20:56 PDT 2007,  Manu Sporny msporny at digitalbazaar.com
>  came to the conclusion that 'work-title' was not needed, you can read
> that discussion here:
> http://microformats.org/discuss/mail/microformats-new/2007-May/000353.html
> 
> -brian
> 
> [1] - http://microformats.org/wiki/process
> 
-------------- 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/20070607/52733cdf/smime-0001.bin
From andy at pigsonthewing.org.uk  Thu Jun  7 14:07:16 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Thu Jun  7 14:09:15 2007
Subject: [uf-new] Third attempt at hAudio
In-Reply-To: <21e770780706071150s41a4cd73i2df7207cd533c52e@mail.gmail.com>
References: <46683C04.4050006@digitalbazaar.com>
	<1181238473.3189.71.camel@localhost.localdomain>
	<21e770780706071050i2c8fe0d6j8e5a3e85b42ec284@mail.gmail.com>
	<46684BC5.6010600@digitalbazaar.com>
	<21e770780706071150s41a4cd73i2df7207cd533c52e@mail.gmail.com>
Message-ID: <Ahi6xAnEOHaGFwBn@pigsonthewing.org.uk>

In message 
<21e770780706071150s41a4cd73i2df7207cd533c52e@mail.gmail.com>, Brian 
Suda <brian.suda@gmail.com> writes

>Please make yourself aware of the process. If we are going to get
>through this proposal, you MUST read the process and understand it.

What if Manu (or anyone else) has read it, and fully understands it, but 
disagrees with it?

-- 
Andy Mabbett
From msporny at digitalbazaar.com  Thu Jun  7 14:18:56 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Thu Jun  7 14:18:59 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <21e770780706071150s41a4cd73i2df7207cd533c52e@mail.gmail.com>
References: <46683C04.4050006@digitalbazaar.com>	<1181238473.3189.71.camel@localhost.localdomain>	<21e770780706071050i2c8fe0d6j8e5a3e85b42ec284@mail.gmail.com>	<46684BC5.6010600@digitalbazaar.com>
	<21e770780706071150s41a4cd73i2df7207cd533c52e@mail.gmail.com>
Message-ID: <46687640.9040008@digitalbazaar.com>

Brian Suda wrote:
> On 6/7/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
>> Ideally, we would be using 'title' - why can't we do that, again?
>> Because hcard uses it?
> 
> --- because the semantics of TITLE have already been defined as
> something else. It is irrelevant that hCard uses it, the semantics are
> not what you intend.
> 
> TITLE: Job title or functional position of the object.
> 
> http://microformats.org/wiki/classes
> 
> Point 4 in the process[1] says you should be aware of microformats
> naming principles when choosing names.
> 
> Please make yourself aware of the process.

I am aware of the process and I am aware that the semantics of TITLE
have already been defined. I was asking a different set of questions,
more specifically:

1. How did TITLE come about?
2. Who created it and how many people signed off on it?
3. Did it originate in hCard?
4. How many Microformats existed when TITLE was created?
5. Is there anybody else on the list that thinks that TITLE has a bad
   semantic definition?

I realize that this is a can of worms that most on here don't want to
open up - but what do we do when semantics are hijacked by previous
Microformats?

It seems to me that the proper semantic name for "Job title or
functional position" should be something like 'position', or
'job-title', or 'function'.

I'm assuming that 'title' came about because it was defined in the VCARD
format (Section 3.5.1):

http://www.ietf.org/rfc/rfc2426.txt

The definition in VCARD Section 3.5.1 is:

3.5.1 TITLE Type Definition
   Subject: Registration of text/directory MIME type TITLE
   Type name: TITLE
   Type purpose: To specify the job title, functional position or
   function of the object the vCard represents.

So, because VCARD defined what TITLE was a long time ago, all
Microformats must follow that definition from now on because of a simple
copy-paste? The first Microformat to use a term gets to define what it
means in all other Microformats... forever?

I realize that what I am proposing is revising hCard and re-naming
'title' to 'function'... in return, we can use 'title' to mean what it
is defined as in most dictionaries:

http://dictionary.reference.com/browse/title

Dictionary.com
ti?tle
1.	the distinguishing name of a book, poem, picture, piece of music, or
the like.

American Heritage Dictionary
ti?tle
   1. An identifying name given to a book, play, film, musical
      composition, or other work.
   2. A general or descriptive heading, as of a book chapter.

WordNet
title
1. 	a heading that names a statute or legislative bill; may give a
        brief summary of the matters it deals with; "Title 8 provided
        federal help for schools"
2. 	the name of a work of art or literary composition etc.; "he
        looked for books with the word 'jazz' in the title"; "he refused
        to give titles to his paintings"; "I can never remember movie
        titles"
3. 	a general or descriptive heading for a section of a written
        work; "the novel had chapter titles"

etc.

Do you see the point I am trying to make?

-- manu
From brian.suda at gmail.com  Thu Jun  7 14:59:28 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Thu Jun  7 14:59:32 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <46687640.9040008@digitalbazaar.com>
References: <46683C04.4050006@digitalbazaar.com>
	<1181238473.3189.71.camel@localhost.localdomain>
	<21e770780706071050i2c8fe0d6j8e5a3e85b42ec284@mail.gmail.com>
	<46684BC5.6010600@digitalbazaar.com>
	<21e770780706071150s41a4cd73i2df7207cd533c52e@mail.gmail.com>
	<46687640.9040008@digitalbazaar.com>
Message-ID: <21e770780706071459l22eb1f9fl41599f25760d6b9@mail.gmail.com>

On 6/7/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 1. How did TITLE come about?

--- TITLE is part of the vCard spec, and is now part of the hCard spec.

> 2. Who created it and how many people signed off on it?

--- it came along with hCard. I'm not sure what you are implying about
"signed-off" on it. What you are implying is that there is an overall
"gold stamp", which there is not with microformats.

> 3. Did it originate in hCard?

--- it originated with vCard and was taken onboard with hCard.

> 4. How many Microformats existed when TITLE was created?

--- none, hCard was developed before Microformats.org existed. It was
developed along with hCalendar.

> 5. Is there anybody else on the list that thinks that TITLE has a bad
>    semantic definition?

--- The definition of TITLE has been assigned, it is not incorrect.
This is life, as audio moves along i'm sure people will suggest TRACK
as a property, but all the hWine folks might cringe because they might
want "TRACK" to mean a track of land. This is a fact of life that many
english words have multiple meanings. TITLE could mean a job title, a
title or deed to a house, or an honorary title, or book title.
Everyone will fight for it to mean different things.

Whether TITLE was a good or bad choice is not really up for debate, by
changing the semantics we potentially break every page that has an
hCard. This is an expensive practice to deprecate a property, let
alone re-assign it to a new value! There are much simpler ways, which
has been to use a different semantic element which means what you
intend, hence FN or SUMMARY.

> I realize that this is a can of worms that most on here don't want to
> open up - but what do we do when semantics are hijacked by previous
> Microformats?

--- they are not 'hijacked' they are simply different semantics that
you WANT. There is nothing incorrect about the current semantics of
TITLE.

> It seems to me that the proper semantic name for "Job title or
> functional position" should be something like 'position', or
> 'job-title', or 'function'.

--- this might be true, but TITLE is semantically correct as well.
When it comes to other properties such as length of a video, do we
choose 'duration' or 'frames' or 'run-time' or something else... no
matter what you choose it will never please everyone.

> So, because VCARD defined what TITLE was a long time ago, all
> Microformats must follow that definition from now on because of a simple
> copy-paste? The first Microformat to use a term gets to define what it
> means in all other Microformats... forever?

--- there are no namespace in microformats, so when we define a term
it is set for life. This is why we need to take the time to select the
correct terms. Microformats are an on-going process. This is also why
we want to keep things MICRO and not introduce hundreds of new
formats.

> I realize that what I am proposing is revising hCard and re-naming
> 'title' to 'function'... in return, we can use 'title' to mean what it
> is defined as in most dictionaries:

what you left out in your dictionary references, is that they also
contain the definition of TITLE as we currently defined it, along with
several others. The dictionary.com reference has 9 results with around
12 definitions for each, you posted 2.
http://dictionary.reference.com/browse/title

You will find that most of the enteries do have the current definition
of TITLE among them.

> Do you see the point I am trying to make?

--- i do, but i don't see why? what you call FN or SUMMARY or TITLE is
important, but we have assigned semantic values to terms already, this
process is expensive to go back on. Then if you wanted to redefine
TITLE in your manner what is the point of FN or SUMMARY? we now have
duplicate properties which we want to avoid.

Much of the very early work of microformats happened BEFORE
microformats.org existed. Since then we have learned more and more
with each step. Choosing the semantics we did for TITLE might not
please everyone, but this is done now. I don't see the need to change
it since it already works just fine and we have viable alternatives.

I really want to keep this discussion civalized, but to do so we need
to avoid leading questions, use of terms like "hijack" which evoke an
incorrect emotional response which is in no way true, if there is a
comment or question, lets ask it specifically so we can avoid any
confusion. You can always email me offlist and we can discuss it
further, there is also the IRC channel which discussions happen more
real-time.

-brian

-- 
brian suda
http://suda.co.uk
From joe at andrieu.net  Thu Jun  7 15:40:50 2007
From: joe at andrieu.net (Joe Andrieu)
Date: Thu Jun  7 15:40:44 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <21e770780706071459l22eb1f9fl41599f25760d6b9@mail.gmail.com>
Message-ID: <005a01c7a954$e71a5c80$0201a8c0@andrieuhome>

I would like to suggest "audio-title".

"title" itself is already defined elsewhere, in an incompatible way.

"summary" is inaccurate. Many titles are not summaries in any sense of the word:

"Hey Joe" - Jimi Hendrix
"Beethoven's Ninth Sympony" - Beethoven
"Rainy Day Women #12 and 35" - Bob Dylan
"The Start Spangled Banner" - Francis Scott Key

In contrast, one could easily imagine "summary" being incredibly useful semantic HTML for podcasts or speaches, or indeed, for
summarizing spoken essays.

Because "summary" is often incorrect and has useful meaning on its own, I think it would be an error to shoehorn it into a
replacement for "title".

In particular, an hReview that has a summary, is the summary of the /review/. It would be confusing if it also served as the title
of an an audio clip being reviewed, which I think would be a natural problem for an hReview that includes an hAudio.

While hReview uses "summary" for title, it is understood that reviews rarely have artistic titles (they are rarely artistic media),
and instead are usually titled as a summary of the entire review. 

Most artistic media, books, movies, poems, songs, and albums, on the other hand, have titles that are artistic expressions
themselves.

-j

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

From martin at weborganics.co.uk  Thu Jun  7 16:43:03 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Thu Jun  7 16:41:36 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <005a01c7a954$e71a5c80$0201a8c0@andrieuhome>
References: <005a01c7a954$e71a5c80$0201a8c0@andrieuhome>
Message-ID: <1181259783.3189.181.camel@localhost.localdomain>

On Thu, 2007-06-07 at 15:40 -0700, Joe Andrieu wrote: 
> I would like to suggest "audio-title".
> 
> "title" itself is already defined elsewhere, in an incompatible way.
> 
> "summary" is inaccurate. Many titles are not summaries in any sense of the word:
> 
> "Hey Joe" - Jimi Hendrix
> "Beethoven's Ninth Sympony" - Beethoven
> "Rainy Day Women #12 and 35" - Bob Dylan
> "The Start Spangled Banner" - Francis Scott Key
> 
> In contrast, one could easily imagine "summary" being incredibly useful semantic HTML for podcasts or speaches, or indeed, for
> summarizing spoken essays.
> 
> Because "summary" is often incorrect and has useful meaning on its own, I think it would be an error to shoehorn it into a
> replacement for "title".
> 
> In particular, an hReview that has a summary, is the summary of the /review/. It would be confusing if it also served as the title
> of an an audio clip being reviewed, which I think would be a natural problem for an hReview that includes an hAudio.
> 
> While hReview uses "summary" for title, it is understood that reviews rarely have artistic titles (they are rarely artistic media),
> and instead are usually titled as a summary of the entire review. 
> 
> Most artistic media, books, movies, poems, songs, and albums, on the other hand, have titles that are artistic expressions
> themselves.
> 
> -j

I am presuming that the reason we have entry-title in hAtom and not
title is because title had already been defined in vcard to mean
something else, but there was compelling evidence to support a title of
a different meaning?

The evidence to support that we need a title in hAudio is at first quite
compelling also, but I don't think it applies to an individual audio. I
think an individual audio has artistic properties but also that the
title is a summary of the whole audio, you gave four good examples of
this in your statement.

we gave an image related to hAudio a tag of image-summary which also has
artistic properties but is a summary of an entire album or an actual CD
cover.

I suggested changing fn to summary because FN was confusing people, and
there are still a lot of people in the real world wrongly
misunderstanding its meaning as Full Name, and I also wanted something
that meant the same thing but was also re-using existing microformats as
per the process, and 

http://microformats.org/wiki/existing-classes

summary has an already rich semantic meaning so I thought this would
make this easy (hmmm)

A last thought, If we use audio-title or any other derivative are we in
danger of reiterating the previous problem discussions we had with
work-title?


-Martin- 
> 
> --
> Joe Andrieu
> SwitchBook Software
> http://www.switchbook.com
> joe@switchbook.com
> +1 (805) 705-8651 
> 
> _______________________________________________
> 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/20070608/269340df/smime.bin
From joe at andrieu.net  Thu Jun  7 18:00:48 2007
From: joe at andrieu.net (Joe Andrieu)
Date: Thu Jun  7 18:00:47 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <1181259783.3189.181.camel@localhost.localdomain>
Message-ID: <007501c7a968$749e1ac0$0201a8c0@andrieuhome>

Martin McEvoy wrote:
> On Thu, 2007-06-07 at 15:40 -0700, Joe Andrieu wrote: 
> > I would like to suggest "audio-title".
> > 
> > "title" itself is already defined elsewhere, in an incompatible way.
> > 
> > "summary" is inaccurate. Many titles are not summaries in 
> any sense of 
> > the word:
> > 
> > "Hey Joe" - Jimi Hendrix
> > "Beethoven's Ninth Sympony" - Beethoven
> > "Rainy Day Women #12 and 35" - Bob Dylan
> > "The Start Spangled Banner" - Francis Scott Key
> > 
[snip]
> > 
> > Most artistic media, books, movies, poems, songs, and 
> albums, on the 
> > other hand, have titles that are artistic expressions themselves.
> > 
> > -j
> 
> I am presuming that the reason we have entry-title in hAtom 
> and not title is because title had already been defined in 
> vcard to mean something else, but there was compelling 
> evidence to support a title of a different meaning?

I can't speak to that, but it makes sense.

> The evidence to support that we need a title in hAudio is at 
> first quite compelling also, but I don't think it applies to 
> an individual audio. I think an individual audio has artistic 
> properties but also that the title is a summary of the whole 
> audio, you gave four good examples of this in your statement.

Most individual audio in the examples are songs. Songs have titles. The four examples above are NOT summaries.  I don't know how one
could consider "Beethoven's Ninth Sympony" or "Rainy Day Women #12 and 35" summaries. The summary for "Hey Joe" could be "A blues
song where the singer kills Joe for sleeping with his woman, then flees to Mexico." But the /title/ of the song is clearly "Hey
Joe".

> we gave an image related to hAudio a tag of image-summary 
> which also has artistic properties but is a summary of an 
> entire album or an actual CD cover.
> 
> I suggested changing fn to summary because FN was confusing 
> people, and there are still a lot of people in the real world 
> wrongly misunderstanding its meaning as Full Name, and I also 
> wanted something that meant the same thing but was also 
> re-using existing microformats as per the process, and 
> 
> http://microformats.org/wiki/existing-classes
> 
> summary has an already rich semantic meaning so I thought 
> this would make this easy (hmmm)
> 
> A last thought, If we use audio-title or any other derivative 
> are we in danger of reiterating the previous problem 
> discussions we had with work-title?

I hope not. Title is the word used in every day English and since we are talking about an audio piece in particular, I think we are
free from some of the work-title concerns.

Can you summarize why work-title was problematic?

-j

p.s.
(btw, I agree FN is a bit confusing)

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


From martin at weborganics.co.uk  Thu Jun  7 21:55:54 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Thu Jun  7 21:54:28 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <007501c7a968$749e1ac0$0201a8c0@andrieuhome>
References: <007501c7a968$749e1ac0$0201a8c0@andrieuhome>
Message-ID: <1181278554.6259.73.camel@localhost.localdomain>

On Thu, 2007-06-07 at 18:00 -0700, Joe Andrieu wrote:
> Martin McEvoy wrote:
> > On Thu, 2007-06-07 at 15:40 -0700, Joe Andrieu wrote: 
> > > I would like to suggest "audio-title".
> > > 
> > > "title" itself is already defined elsewhere, in an incompatible way.
> > > 
> > > "summary" is inaccurate. Many titles are not summaries in 
> > any sense of 
> > > the word:
> > > 
> > > "Hey Joe" - Jimi Hendrix
> > > "Beethoven's Ninth Sympony" - Beethoven
> > > "Rainy Day Women #12 and 35" - Bob Dylan
> > > "The Start Spangled Banner" - Francis Scott Key
> > > 
> [snip]
> > > 
> > > Most artistic media, books, movies, poems, songs, and 
> > albums, on the 
> > > other hand, have titles that are artistic expressions themselves.
> > > 
> > > -j
> > 
> > I am presuming that the reason we have entry-title in hAtom 
> > and not title is because title had already been defined in 
> > vcard to mean something else, but there was compelling 
> > evidence to support a title of a different meaning?
> 
> I can't speak to that, but it makes sense.
> 
> > The evidence to support that we need a title in hAudio is at 
> > first quite compelling also, but I don't think it applies to 
> > an individual audio. I think an individual audio has artistic 
> > properties but also that the title is a summary of the whole 
> > audio, you gave four good examples of this in your statement.
> 
> Most individual audio in the examples are songs. Songs have titles. The four examples above are NOT summaries.  I don't know how one
> could consider "Beethoven's Ninth Sympony" or "Rainy Day Women #12 and 35" summaries. The summary for "Hey Joe" could be "A blues
> song where the singer kills Joe for sleeping with his woman, then flees to Mexico." But the /title/ of the song is clearly "Hey
> Joe".
> 

You dont think  "Beethoven's Ninth Sympony" is a summary of the actual
symphony? or that "Hey Joe" is a summary of "Hey Joe, where you goin'
with that gun in your hand"?

lets try to think of meaning here not generic terms

> > we gave an image related to hAudio a tag of image-summary 
> > which also has artistic properties but is a summary of an 
> > entire album or an actual CD cover.
> > 
> > I suggested changing fn to summary because FN was confusing 
> > people, and there are still a lot of people in the real world 
> > wrongly misunderstanding its meaning as Full Name, and I also 
> > wanted something that meant the same thing but was also 
> > re-using existing microformats as per the process, and 
> > 
> > http://microformats.org/wiki/existing-classes
> > 
> > summary has an already rich semantic meaning so I thought 
> > this would make this easy (hmmm)
> > 
> > A last thought, If we use audio-title or any other derivative 
> > are we in danger of reiterating the previous problem 
> > discussions we had with work-title?
> 
> I hope not. Title is the word used in every day English and since we are talking about an audio piece in particular, I think we are
> free from some of the work-title concerns.

no we are not, even now we are addressing the same problem

> 
> Can you summarize why work-title was problematic?

we were re-defining the meaning of title to mean something different. 
Title has already been defined in vCard to mean "To specify the job
title, functional position or function of the object the vCard
represents" section 3.5.1 of RFC 2426
http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc2426.html 
there is nothing much we can do about this.


The full discussion can be read here:

http://microformats.org/discuss/mail/microformats-new/2007-May/000342.html

A question I might ask Is just because we *can* create a new microformat
do you think we *should*? especially when we already have a microformat
that means the same thing? summary from hReview

http://microformats.org/wiki/hreview#Field_details

and do you think that by creating a new microformat, that we would
increase the cognitive load of any future adapters of a microformat, we
do want people to use hAudio and understand it don't we?

the use of titles especially if you are talking about titles of audio is
misleading in itself, you have titles of albums and titles of tracks,
they both don't mean the same thing although they use the same words.

If we created a microformat that relies on the use of a title in every
single instance eg:

haudio audio-title Blonde on Blonde
haudio audio-title 1 Rainy Day Women #12 & 35 
haudio audio-title 2 Pledging My Time 
haudio audio-title 3 Visions of Johanna 
[etc...]

now can you see how misleading this is two contexts meaning the same
thing but entirely different objects.

I would say if you are going to use a *.-title in any microformat it has
to be the defining instance of the object you are trying to describe,
and not reused again to define another different object within the same
microformat or reused somewhere else to mean another different object.
what sense would there be in that?

-martin-

> 
> -j
> 
> p.s.
> (btw, I agree FN is a bit confusing)
> 
> --
> Joe Andrieu
> SwitchBook Software
> http://www.switchbook.com
> joe@switchbook.com
> +1 (805) 705-8651 
> 
-------------- 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/20070608/0c820ac3/smime.bin
From andy at pigsonthewing.org.uk  Fri Jun  8 04:37:11 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Fri Jun  8 04:38:29 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <007501c7a968$749e1ac0$0201a8c0@andrieuhome>
References: <1181259783.3189.181.camel@localhost.localdomain>
	<007501c7a968$749e1ac0$0201a8c0@andrieuhome>
Message-ID: <$GaF4yrn9TaGFwlw@pigsonthewing.org.uk>

In message <007501c7a968$749e1ac0$0201a8c0@andrieuhome>, Joe Andrieu 
<joe@andrieu.net> writes

>Most individual audio in the examples are songs. Songs have titles. The 
>four examples above are NOT summaries.  I don't know how one could 
>consider "Beethoven's Ninth Sympony" or "Rainy Day Women #12 and 35" 
>summaries. The summary for "Hey Joe" could be "A blues song where the 
>singer kills Joe for sleeping with his woman, then flees to Mexico." 
>But the /title/ of the song is clearly "Hey Joe".

Absolutely. That's a matter of semantics. Isn't one of the main ideas 
behind both microformats and, "POSH", to get the semantics *right*?

-- 
Andy Mabbett
From msporny at digitalbazaar.com  Fri Jun  8 05:29:34 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Jun  8 05:29:37 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <$GaF4yrn9TaGFwlw@pigsonthewing.org.uk>
References: <1181259783.3189.181.camel@localhost.localdomain>	<007501c7a968$749e1ac0$0201a8c0@andrieuhome>
	<$GaF4yrn9TaGFwlw@pigsonthewing.org.uk>
Message-ID: <46694BAE.5050508@digitalbazaar.com>

Andy Mabbett wrote:
> In message <007501c7a968$749e1ac0$0201a8c0@andrieuhome>, Joe Andrieu
> <joe@andrieu.net> writes
> 
>> Most individual audio in the examples are songs. Songs have titles.
>> The four examples above are NOT summaries.  I don't know how one could
>> consider "Beethoven's Ninth Sympony" or "Rainy Day Women #12 and 35"
>> summaries. The summary for "Hey Joe" could be "A blues song where the
>> singer kills Joe for sleeping with his woman, then flees to Mexico."
>> But the /title/ of the song is clearly "Hey Joe".
> 
> Absolutely. That's a matter of semantics. Isn't one of the main ideas
> behind both microformats and, "POSH", to get the semantics *right*?

Andy and Joe are exactly right. This is the point - we didn't get the
semantics of 'title' right the first time. Brian is also right - it's
unfortunate, but what is done is done. Title is being used for vcard and
we can't deprecate or replace it without a tremendous amount of backlash.

I think we can still fix this without impacting any of the Microformats,
here's how:

We update the definition of 'title' as it relates to all Microformats from:

TITLE: Job title or functional position of the object.

to

TITLE: The distinguishing name of a book, poem, picture, piece of music,
 job title, or functional position of an object or the like.

This seems to address all of the concerns raised thus far:

* It doesn't affect hcard, hcalendar, or any of the others.
* It brings the definition more in line with the way the English
  language defines it.
* It frees up 'title' to be used in other Microformats.

Thoughts?

-- manu
From brian.suda at gmail.com  Fri Jun  8 07:08:24 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Fri Jun  8 07:08:31 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <46694BAE.5050508@digitalbazaar.com>
References: <1181259783.3189.181.camel@localhost.localdomain>
	<007501c7a968$749e1ac0$0201a8c0@andrieuhome>
	<$GaF4yrn9TaGFwlw@pigsonthewing.org.uk>
	<46694BAE.5050508@digitalbazaar.com>
Message-ID: <21e770780706080708u3b7b9a7brdc18c398887102fb@mail.gmail.com>

On 6/8/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> TITLE: The distinguishing name of a book, poem, picture, piece of music,
>  job title, or functional position of an object or the like.
>
> This seems to address all of the concerns raised thus far:
>
> * It doesn't affect hcard, hcalendar, or any of the others.
> * It brings the definition more in line with the way the English
>   language defines it.
> * It frees up 'title' to be used in other Microformats.
>
> Thoughts?

--- the problem with updating the definition of TITLE then becomes in
a citation, book, or other reference such as audio, what happens when
you have an hCard with a title and a class="title" for the name of the
work? the issue becomes WHICH is the actual TITLE you intend? if you
begin to have two meaning for the same property and that property
appears twice in a format which is which?

Each of our properties should do it's best to have one and only one
semantic meaning.

-brian

-- 
brian suda
http://suda.co.uk
From scott at makedatamakesense.com  Fri Jun  8 07:40:23 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Fri Jun  8 07:40:31 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <1181278554.6259.73.camel@localhost.localdomain>
References: <007501c7a968$749e1ac0$0201a8c0@andrieuhome>
	<1181278554.6259.73.camel@localhost.localdomain>
Message-ID: <0F6BC1FF-FA41-4010-A55F-9754EFD2021C@makedatamakesense.com>

On Jun 7, 2007, at 11:15 AM, Martin McEvoy wrote:

>> So, let's drop audio grouping (halbum) for now.
>
> Good call
>
> something we can all agree on?

Apparently not:

On Jun 7, 2007, at 10:55 PM, Martin McEvoy wrote:

> you have titles of albums and titles of tracks,
> they both don't mean the same thing although they use the same words.

Hypothetical future album markup should not influence the markup of  
specific recordings in haudio.  It's a separate topic, and one which  
I thought we'd all agreed to postpone for now.  So why are we talking  
about albums again?

--
Scott Reynen
MakeDataMakeSense.com


From msporny at digitalbazaar.com  Fri Jun  8 07:56:32 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Jun  8 07:56:34 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <21e770780706080708u3b7b9a7brdc18c398887102fb@mail.gmail.com>
References: <1181259783.3189.181.camel@localhost.localdomain>	<007501c7a968$749e1ac0$0201a8c0@andrieuhome>	<$GaF4yrn9TaGFwlw@pigsonthewing.org.uk>	<46694BAE.5050508@digitalbazaar.com>
	<21e770780706080708u3b7b9a7brdc18c398887102fb@mail.gmail.com>
Message-ID: <46696E20.7020702@digitalbazaar.com>

Brian Suda wrote:
> --- the problem with updating the definition of TITLE then becomes in
> a citation, book, or other reference such as audio, what happens when
> you have an hCard with a title and a class="title" for the name of the
> work? the issue becomes WHICH is the actual TITLE you intend? if you
> begin to have two meaning for the same property and that property
> appears twice in a format which is which?

If I understand you correctly, this is what you are saying:

haudio
   title (this title is for the haudio)
   collaborator
      vcard
         fn
         title (this title is for the vcard)

You are stating that we don't want to do what is stated above. If we are
taking this rule to heart, then why didn't anybody argue against using
'fn' in haudio? To further illustrate my point:

haudio
   fn (this fn is for the haudio)
   collaborator
      vcard
         fn (this fn is for the vcard)
         title

Don't we already have this "problem" with hReview (among other uF drafts):

"I went down to have a drink at Chez Rasta, the new Jamaican place, with
Brian Suda the other week - here's how it went."
Item: Jamaican Chicken Pasta

<div class="hreview">
   <span class="summary">
      I went down to have a drink at Chez Rasta, the new Jamaican place,
      with
      <div class="vcard">
         <span class="fn">Brian Suda</span>
      </div>
      the other week - here's how it went."
   </span>
   <br/>
   Item: <div class="item">
            <span class="fn">Jamaican Chicken Pasta</span>
         </div>
</div>

hreview
   summary
      vcard
         fn (this fn is for the vcard)
   item
      fn (this fn is for the item)

Doesn't the above valid hReview markup break your rule as well? Is this
really a problem. As far as I can tell, it isn't a parsing problem. It
is clear which FN goes with which container in hReview, just like it
would be clear to a parser which TITLE goes with which container in haudio.

-- manu

From scott at makedatamakesense.com  Fri Jun  8 08:27:32 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Fri Jun  8 08:27:38 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <21e770780706080708u3b7b9a7brdc18c398887102fb@mail.gmail.com>
References: <1181259783.3189.181.camel@localhost.localdomain>
	<007501c7a968$749e1ac0$0201a8c0@andrieuhome>
	<$GaF4yrn9TaGFwlw@pigsonthewing.org.uk>
	<46694BAE.5050508@digitalbazaar.com>
	<21e770780706080708u3b7b9a7brdc18c398887102fb@mail.gmail.com>
Message-ID: <FFBF5C0F-70FE-4492-8ABF-DF138616E7DB@makedatamakesense.com>

On Jun 8, 2007, at 8:08 AM, Brian Suda wrote:

> the problem with updating the definition of TITLE then becomes in
> a citation, book, or other reference such as audio, what happens when
> you have an hCard with a title and a class="title" for the name of the
> work?

This is the same problem with re-using any class name in multiple  
microformats.  As mentioned earlier, if we re-use "summary" in haudio  
(which I'm not arguing for nor against here), what if we want to  
embed haudio inside hreview?  How do we keep the haudio summary from  
becoming the hreview summary?  The answer in both cases, I think, is  
to define parsing rules to account for embedded microformats with  
shared property names, which is a discussion already begun here:

http://microformats.org/wiki/mfo

More generally, I think we should be defining parsing rules based on  
the semantics, rather than vice versa.

--
Scott Reynen
MakeDataMakeSense.com


From brian.suda at gmail.com  Fri Jun  8 08:39:22 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Fri Jun  8 08:39:25 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <46696E20.7020702@digitalbazaar.com>
References: <1181259783.3189.181.camel@localhost.localdomain>
	<007501c7a968$749e1ac0$0201a8c0@andrieuhome>
	<$GaF4yrn9TaGFwlw@pigsonthewing.org.uk>
	<46694BAE.5050508@digitalbazaar.com>
	<21e770780706080708u3b7b9a7brdc18c398887102fb@mail.gmail.com>
	<46696E20.7020702@digitalbazaar.com>
Message-ID: <21e770780706080839t12d69554x32bf72d1417e91a8@mail.gmail.com>

On 6/8/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> If I understand you correctly, this is what you are saying:
>
> haudio
>    title (this title is for the haudio)
>    collaborator
>       vcard
>          fn
>          title (this title is for the vcard)
>
> You are stating that we don't want to do what is stated above. If we are
> taking this rule to heart, then why didn't anybody argue against using
> 'fn' in haudio? To further illustrate my point:

--- i believe we did, that is why it was suggested to switch to
'summary' on  Thu Jun 6
http://microformats.org/discuss/mail/microformats-new/2007-June/000502.html
by Martin McEvoy and acknoledged on the 7th by Manu Sporny
http://microformats.org/discuss/mail/microformats-new/2007-June/000504.html

> hreview
>    summary
>       vcard
>          fn (this fn is for the vcard)
>    item
>       fn (this fn is for the item)
>
> Doesn't the above valid hReview markup break your rule as well? Is this
> really a problem. As far as I can tell, it isn't a parsing problem. It
> is clear which FN goes with which container in hReview, just like it
> would be clear to a parser which TITLE goes with which container in haudio.

in the current pseudo-code no, but in this example it does:
hcalendar
  location
    vcard
      url#1
  url#2

you MIGHT intend that URL#2 be part of hcalender, but infact URL#1 is
the URL that gets used because it is the first found.

if you have
media
  hcard
   title#1
  title#2

then title#1 will be used for the media, NOT title#2

When you beging to give two different meaning to the same thing, you
are confusing the semantics, whereas:
media
  title#2
  hcard
   title#1

this is more what you intended were title#2 is correctly associated with media

media
  summary
  hcard
   title#1

- or -

media
  hcard
   title#1
  summary

yeild the same results

this is NOT a bug, it is a feature of NOT having namespace in that you
can use the same property across many domains. This IS different than
other languages like XML, microformats are NOT the same. This is where
some confusions arise when folks apply one technology domain to other
which in this case is not correct.

-brian

-- 
brian suda
http://suda.co.uk
From martin at weborganics.co.uk  Fri Jun  8 09:00:38 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Jun  8 08:59:11 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <0F6BC1FF-FA41-4010-A55F-9754EFD2021C@makedatamakesense.com>
References: <007501c7a968$749e1ac0$0201a8c0@andrieuhome>
	<1181278554.6259.73.camel@localhost.localdomain>
	<0F6BC1FF-FA41-4010-A55F-9754EFD2021C@makedatamakesense.com>
Message-ID: <1181318438.11634.58.camel@localhost.localdomain>

On Fri, 2007-06-08 at 08:40 -0600, Scott Reynen wrote:
> On Jun 7, 2007, at 11:15 AM, Martin McEvoy wrote:
> 
> >> So, let's drop audio grouping (halbum) for now.
> >
> > Good call
> >
> > something we can all agree on?
> 
> Apparently not:
> 
> On Jun 7, 2007, at 10:55 PM, Martin McEvoy wrote:
> 
> > you have titles of albums and titles of tracks,
> > they both don't mean the same thing although they use the same words.
> 
> Hypothetical future album markup should not influence the markup of  
> specific recordings in haudio.  It's a separate topic, and one which  
> I thought we'd all agreed to postpone for now.  So why are we talking  
> about albums again?

I am not it's the rest of you that keep on going round in circles.

You know guys we DID have a discussion about the use of "title" in
haudio I brought it up when I was trying to conceptualize what haudio
would be...

http://microformats.org/discuss/mail/microformats-new/2007-May/000385.html

... now for some reason my concept was shouted down particularly by Manu
and You (Scott), so I didn't push it because I thought my logic was
wrong, I have spent the last two months trying to think of alternatives
to my concept and try and fit it into how *YOU* all see haudio. now it
turns out that you are all suggesting that I may have been on the right
track in the first place?. 

So my questions are Why are we discussing this again? why do I not even
merit a decent reply to points that I make? other than I am wrong all
the time? Is it because I am not a savy microformateer so my points are
irrelevant because you think I am guessing things?  I have spent the
last year and a half trying to address the issue of media-info I first
read about it here:

http://www.mixedcontent.com/technology/2005/09/micro-formats-and-audio-peanut-butter-and-chocolate/

I am already podcasting using hAtom without any use of hAudio 
http://feeds.feedburner.com/WeborganicsPodcast 
and
http://grabb.it/grabs/d62c8c1cd3ab
 
The grab it guys were so impressed on how easy it is to grab audio from
my page that in their words "in principle interested in reading
hAtom." because "we'd like to read the whole web perfectly someday" It
is likley that they will use hAudio too.

what are you trying to say I was wrong then and you are right now why is
that?

Are we re-inventing the wheel here or trying to hit it with a hammer?,
are you suggesting that I was right? (heaven forbid)

If it wasn't for people like me thinking ahead then how many new
microformats do you think there would be and how many mistakes do you
think you will make.

my vote still stays with "summary" because its an easier path to chose
than trying to re-define "title" to suit your needs.

-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/20070608/63effb95/smime.bin
From brian.suda at gmail.com  Fri Jun  8 09:01:56 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Fri Jun  8 09:01:59 2007
Subject: [uf-new] Reusing classes names in multiple formats
Message-ID: <21e770780706080901y1a4c99c3oa20bbe2dbc5999df@mail.gmail.com>

On 6/8/07, Scott Reynen <scott@makedatamakesense.com> wrote:
> This is the same problem with re-using any class name in multiple
> microformats.  As mentioned earlier, if we re-use "summary" in haudio
> (which I'm not arguing for nor against here), what if we want to
> embed haudio inside hreview?

SUMMARY is defined as:
A short summary or subject for the object.
http://microformats.org/wiki/classes

It is currently used in: vevent , hreview, hresume

> How do we keep the haudio summary from becoming the hreview summary?

--- this is true, but sometime you want it to be both! Microformats
are purposefully simple and MICRO, we are quickly getting to WHAT
IF... the original intent of microformats is NOT to boil the oceans
and have hundreds of formats! each time a few format is proposed it
does have to interact with all the others, and this is exponential
growth... some things will never be microformats, that is a fact of
life, we are MICRO by design.

There is now a nice sliding scale of technologies, from POSH, to
microformats, to RDFa to GRDDL all which do things slightly
differently with different output and results. Microformats do NOT
need to cater to every theoretical eventuality.

> More generally, I think we should be defining parsing rules based on
> the semantics, rather than vice versa.

--- this is difficult because the semantics are meant to be the same,
it is context that you want to look at, and sometimes you WANT it to
be in both contexts at the same time.

IF we start to propose that every term be prefixed with hcard-title so
it doesn't collide with media-title then we are no better off than
RDFa and namespacing. Microformats were designed with intent to avoid
this. In doing so we have set limitations on ourselves which we
readily acknowledge, we are NOT attempting to solve every problem, we
are after low hanging fruit, at some point we will have exhausted
those resources and things will no longer be 'easy'. We should avoid
constantly inventing new terms which mean the same thing, just so we
can avoid collisions - the only reason we would go down that road is
so that we CAN attempt to solve every problem and boil the oceans,
which is NOT one of the goals of microformats - that is solved by
other technologies NOT microformats.

firstly we should look at all the available properties[1] regardless
of where they are used. if we don't fine on that meets our needs, is
there existing formats or prior-art that is using properties,
otherwise we create new ones. If there are properties that already
exists, then we should do our best to use them. If we can't then we
should go back and look into creating new properties.

[1] - http://microformats.org/wiki/classes

-brian

-- 
brian suda
http://suda.co.uk
From andy at pigsonthewing.org.uk  Fri Jun  8 10:26:34 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Fri Jun  8 10:27:39 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <21e770780706080708u3b7b9a7brdc18c398887102fb@mail.gmail.com>
References: <1181259783.3189.181.camel@localhost.localdomain>
	<007501c7a968$749e1ac0$0201a8c0@andrieuhome>
	<$GaF4yrn9TaGFwlw@pigsonthewing.org.uk>
	<46694BAE.5050508@digitalbazaar.com>
	<21e770780706080708u3b7b9a7brdc18c398887102fb@mail.gmail.com>
Message-ID: <YahMPMyKFZaGFwBB@pigsonthewing.org.uk>

In message 
<21e770780706080708u3b7b9a7brdc18c398887102fb@mail.gmail.com>, Brian 
Suda <brian.suda@gmail.com> writes

>Each of our properties should do it's best to have one and only one
>semantic meaning.

Yes; including "Fn".

-- 
Andy Mabbett
From msporny at digitalbazaar.com  Fri Jun  8 10:31:55 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Jun  8 10:31:58 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <1181318438.11634.58.camel@localhost.localdomain>
References: <007501c7a968$749e1ac0$0201a8c0@andrieuhome>	<1181278554.6259.73.camel@localhost.localdomain>	<0F6BC1FF-FA41-4010-A55F-9754EFD2021C@makedatamakesense.com>
	<1181318438.11634.58.camel@localhost.localdomain>
Message-ID: <4669928B.1060104@digitalbazaar.com>

Martin McEvoy wrote:
> You know guys we DID have a discussion about the use of "title" in
> haudio I brought it up when I was trying to conceptualize what haudio
> would be...
> 
> http://microformats.org/discuss/mail/microformats-new/2007-May/000385.html
> 
> ... now for some reason my concept was shouted down particularly by Manu
> and You (Scott), so I didn't push it because I thought my logic was
> wrong, I have spent the last two months trying to think of alternatives
> to my concept and try and fit it into how *YOU* all see haudio. now it
> turns out that you are all suggesting that I may have been on the right
> track in the first place?

I am definitely admitting that I was completely and utterly wrong about
the previous "title" discussion. Martin, you were clearly on the right
track back then as far as I am concerned.

My assumption was that the Microformats community had thought through
the selection of 'title' for hcard. I assumed discussion was off-limits
because I didn't understand some Microformat nuance.

It seems like there wasn't much thought put into how defining 'title' in
the way that it was would affect other Microformats (that didn't exist
yet). I am not trying to blame anybody for this. I probably would have
made the same mistake. I don't think this should be a discussion about
blame.

We should decide if we have a fundamental design problem with
Microformats. Following up in the thread Brian just posted to the
list... "Reusing class names in multiple formats".

-- manu
From scott at makedatamakesense.com  Fri Jun  8 11:18:10 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Fri Jun  8 11:18:16 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <1181318438.11634.58.camel@localhost.localdomain>
References: <007501c7a968$749e1ac0$0201a8c0@andrieuhome>
	<1181278554.6259.73.camel@localhost.localdomain>
	<0F6BC1FF-FA41-4010-A55F-9754EFD2021C@makedatamakesense.com>
	<1181318438.11634.58.camel@localhost.localdomain>
Message-ID: <22CE037C-72AC-462C-BA7B-20D5889E40DA@makedatamakesense.com>

On Jun 8, 2007, at 10:00 AM, Martin McEvoy wrote:

> what are you trying to say I was wrong then and you are right now  
> why is
> that?

I was only trying to say that albums are out of scope for this  
discussion.  That doesn't make any proposal right or wrong, only  
limited in scope.  I currently have no position on labeling audio  
titles/summaries.

--
Scott Reynen, Web Developer
303-717-1543 sreynen@integerdenver.com


From ckstjohn at gmail.com  Fri Jun  8 11:30:17 2007
From: ckstjohn at gmail.com (Christopher St John)
Date: Fri Jun  8 11:30:21 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <21e770780706080839t12d69554x32bf72d1417e91a8@mail.gmail.com>
References: <1181259783.3189.181.camel@localhost.localdomain>
	<007501c7a968$749e1ac0$0201a8c0@andrieuhome>
	<$GaF4yrn9TaGFwlw@pigsonthewing.org.uk>
	<46694BAE.5050508@digitalbazaar.com>
	<21e770780706080708u3b7b9a7brdc18c398887102fb@mail.gmail.com>
	<46696E20.7020702@digitalbazaar.com>
	<21e770780706080839t12d69554x32bf72d1417e91a8@mail.gmail.com>
Message-ID: <8ba906450706081130u3bb30ee6y540f86ec0c11960d@mail.gmail.com>

On 6/8/07, Brian Suda <brian.suda@gmail.com> wrote:
>
> this is NOT a bug, it is a feature of NOT having namespace in that you
> can use the same property across many domains. This IS different than
> other languages like XML, microformats are NOT the same.
>

I may have elided too much and got the antecedent of "it" wrong, but
can I read this as a suggestion that not having namespaces helps
with reusing the same property across many domains?

-cks

-- 
Christopher St. John
http://artofsystems.blogspot.com
From msporny at digitalbazaar.com  Fri Jun  8 11:35:16 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Jun  8 11:35:21 2007
Subject: [uf-new] Reusing classes names in multiple formats
In-Reply-To: <21e770780706080901y1a4c99c3oa20bbe2dbc5999df@mail.gmail.com>
References: <21e770780706080901y1a4c99c3oa20bbe2dbc5999df@mail.gmail.com>
Message-ID: <4669A164.7020100@digitalbazaar.com>

Brian Suda wrote:
> On 6/8/07, Scott Reynen <scott@makedatamakesense.com> wrote:
>> This is the same problem with re-using any class name in multiple
>> microformats.  As mentioned earlier, if we re-use "summary" in haudio
>> (which I'm not arguing for nor against here), what if we want to
>> embed haudio inside hreview?
> 
> SUMMARY is defined as:
> A short summary or subject for the object.

I think Scott's point is that we have the same problem using 'summary',
as we do with using 'title', as we do with using 'fn'.

> if you have
> media
>   hcard
>    title#1
>   title#2
>
> then title#1 will be used for the media, NOT title#2

Egad! I had no idea that is what the community meant by "no
namespace"... to programmers what you have described is a scope-less,
procedural language. Am I misunderstanding you? Do Microformats use a
scope-less design paradigm? Am I waaaaaay off here (I hope I am):

Variable Scoping
http://en.wikipedia.org/wiki/Variable_scoping

Therefore, the example you give above would boil down to these
assignment statements in a finite state machine (ie: the parser):

media.title = title#1
media.hcard.title = title#1

Is this what you are stating, Brian?

-- manu
From scott at makedatamakesense.com  Fri Jun  8 13:09:35 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Fri Jun  8 13:09:42 2007
Subject: [uf-new] Reusing classes names in multiple formats
In-Reply-To: <21e770780706080901y1a4c99c3oa20bbe2dbc5999df@mail.gmail.com>
References: <21e770780706080901y1a4c99c3oa20bbe2dbc5999df@mail.gmail.com>
Message-ID: <907011D9-D43D-41F7-B0C7-F9E6EB9B0C7D@makedatamakesense.com>

On Jun 8, 2007, at 10:01 AM, Brian Suda wrote:

> On 6/8/07, Scott Reynen <scott@makedatamakesense.com> wrote:
>> This is the same problem with re-using any class name in multiple
>> microformats.  As mentioned earlier, if we re-use "summary" in haudio
>> (which I'm not arguing for nor against here), what if we want to
>> embed haudio inside hreview?
>
> SUMMARY is defined as:
> A short summary or subject for the object.
> http://microformats.org/wiki/classes

Right.  There seem to be two issues here: 1) using the same term to  
apply two different meanings and 2) using the same term to apply the  
same meaning to two different concepts.  Both are an issue with  
"title," but the latter is still an issue with "summary" and "entry- 
title".  If we want to use any of those, we need to work out this  
issue, as hAudio is specifically designed to be contained in existing  
microformats.

>> How do we keep the haudio summary from becoming the hreview summary?
>
> --- this is true, but sometime you want it to be both! Microformats
> are purposefully simple and MICRO, we are quickly getting to WHAT
> IF...

Obviously everything with hAudio is a "what if," as no one is using  
it yet.  But using hAudio in hReview is one of the most obvious use  
cases.  It's so obvious that we even considered foregoing hAudio  
entirely and just using hReview.  So hoping it won't come up strikes  
me as foolish.  Embedding hAudio in other microformats is a given.   
Modularity and micro go hand in hand.

> the original intent of microformats is NOT to boil the oceans

I'm not suggesting we shouldn't use existing class names; I'm  
suggesting we should think about how that's going to work.  Please  
don't waste my time reciting microformat principles to me; after two  
years, I have them memorized.

>> More generally, I think we should be defining parsing rules based on
>> the semantics, rather than vice versa.
>
> --- this is difficult because the semantics are meant to be the same,
> it is context that you want to look at, and sometimes you WANT it to
> be in both contexts at the same time.

So let's account for that.  Here's a simple rule to get the ball  
rolling: for properties that should only occur once, only the first  
occurrence should be parsed.  This would allow us to use "summary" in  
hAudio within hReview, with the two values identical if there's only  
one, or separate as long as the haudio summary comes after the  
hReview summary.  And it would work just as well with fn or entry- 
title or whatever we choose.  So context collision is no longer a  
constraint on re-using existing classes (though semantic collision,  
of course, still is as it should be).

> IF we start to propose that every term be prefixed with hcard-title so
> it doesn't collide with media-title then we are no better off than
> RDFa and namespacing.

I agree, and I don't believe I anywhere suggested a new hyphenated  
class name, so I'm not sure why you're bringing it up.

> firstly we should look at all the available properties[1] regardless
> of where they are used.

I agree.  And then we should figure out how we can actually use those  
properties without confusion.

--
Scott Reynen
MakeDataMakeSense.com

From martin at weborganics.co.uk  Fri Jun  8 13:45:49 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Jun  8 13:44:21 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <4669928B.1060104@digitalbazaar.com>
References: <007501c7a968$749e1ac0$0201a8c0@andrieuhome>
	<1181278554.6259.73.camel@localhost.localdomain>
	<0F6BC1FF-FA41-4010-A55F-9754EFD2021C@makedatamakesense.com>
	<1181318438.11634.58.camel@localhost.localdomain>
	<4669928B.1060104@digitalbazaar.com>
Message-ID: <1181335549.12603.98.camel@localhost.localdomain>

On Fri, 2007-06-08 at 13:31 -0400, Manu Sporny wrote:
> Martin McEvoy wrote:
> > You know guys we DID have a discussion about the use of "title" in
> > haudio I brought it up when I was trying to conceptualize what haudio
> > would be...
> > 
> > http://microformats.org/discuss/mail/microformats-new/2007-May/000385.html
> > 
> > ... now for some reason my concept was shouted down particularly by Manu
> > and You (Scott), so I didn't push it because I thought my logic was
> > wrong, I have spent the last two months trying to think of alternatives
> > to my concept and try and fit it into how *YOU* all see haudio. now it
> > turns out that you are all suggesting that I may have been on the right
> > track in the first place?
> 
> I am definitely admitting that I was completely and utterly wrong about
> the previous "title" discussion. Martin, you were clearly on the right
> track back then as far as I am concerned.

on the right track yes, The trouble is I WAS wrong.

> 
> My assumption was that the Microformats community had thought through
> the selection of 'title' for hcard. I assumed discussion was off-limits
> because I didn't understand some Microformat nuance.
> 
> It seems like there wasn't much thought put into how defining 'title' in
> the way that it was would affect other Microformats (that didn't exist
> yet). I am not trying to blame anybody for this. I probably would have
> made the same mistake. I don't think this should be a discussion about
> blame.

I think at the time hCard was meant to be identical to the vCard
Standard in every way and mach the scheme defined in
http://www.ietf.org/rfc/rfc2426.txt there was no guess work or defining
or anything just well established standards

for us to use title from vCard would mean that our meaning in hAudio
would have to match the title attribute in the vCard standard. The Title
of our hAudio is not a function is it? and it is not a single text
value, if you need more reasons why title doesn't fit try here,
http://en.wikipedia.org/wiki/Title

the only other microformat that does use Title is of course hAtom which
is also built around rfc standards http://www.ietf.org/rfc/rfc4287 Atom

this is why we cant change hAtom to suit our needs because it is based
on already well established standards.

Summary as Brian put it is the easiest fruit to pick from the tree as
most or the established microformats  hReview, hResume, and hCalendar
already use summary to mean exactly what we want it to mean.

The discussion around re-defining the vcard title to mean what we want
it to mean may take a very long time to accomplish, and  it would have
to be via the microformat process.

how does this look 

<div class="haudio">
<span class="summary" title="Beethoven's Ninth Sympony">Beethoven's
Ninth Sympony</span>
</div>

we are using title here in the correct context

 http://www.w3.org/TR/html401/struct/global.html#h-7.4.3
"This attribute offers advisory information about the element for which
it is set"

HTML

would this suit our purpose?

-Martin- 

> 
> We should decide if we have a fundamental design problem with
> Microformats. Following up in the thread Brian just posted to the
> list... "Reusing class names in multiple formats".
> 
> -- 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/20070608/b49ab3c7/smime.bin
From martin at weborganics.co.uk  Fri Jun  8 13:57:04 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Jun  8 13:55:37 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <1181335549.12603.98.camel@localhost.localdomain>
References: <007501c7a968$749e1ac0$0201a8c0@andrieuhome>
	<1181278554.6259.73.camel@localhost.localdomain>
	<0F6BC1FF-FA41-4010-A55F-9754EFD2021C@makedatamakesense.com>
	<1181318438.11634.58.camel@localhost.localdomain>
	<4669928B.1060104@digitalbazaar.com>
	<1181335549.12603.98.camel@localhost.localdomain>
Message-ID: <1181336224.12603.106.camel@localhost.localdomain>

On Fri, 2007-06-08 at 21:45 +0100, Martin McEvoy wrote:

> <div class="haudio">
> <span class="summary" title="Beethoven's Ninth Sympony">Beethoven's
> Ninth Sympony</span>
> </div> 

You can enhance this further if you want to create extra meaning to one
of our hAudio's by using a bit of POSH

<div class="haudio">
<span class="summary" title="Blonde on Blonde">
<dfn>Blonde on Blonde</dfn>
</span>
</div>
<div class="haudio">
<span class="summary" title="Blonde on Blonde">
Rainy Day Women #12 & 35
</span>
</div>

http://www.w3.org/TR/html401/struct/text.html#edef-DFN

DFN:
        Indicates that this is the defining instance of the enclosed
        term.
        
-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/20070608/4c1947a0/smime.bin
From martin at weborganics.co.uk  Fri Jun  8 13:59:37 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Jun  8 13:58:08 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <1181336224.12603.106.camel@localhost.localdomain>
References: <007501c7a968$749e1ac0$0201a8c0@andrieuhome>
	<1181278554.6259.73.camel@localhost.localdomain>
	<0F6BC1FF-FA41-4010-A55F-9754EFD2021C@makedatamakesense.com>
	<1181318438.11634.58.camel@localhost.localdomain>
	<4669928B.1060104@digitalbazaar.com>
	<1181335549.12603.98.camel@localhost.localdomain>
	<1181336224.12603.106.camel@localhost.localdomain>
Message-ID: <1181336377.12603.109.camel@localhost.localdomain>

On Fri, 2007-06-08 at 21:57 +0100, Martin McEvoy wrote:
> <div class="haudio">
> <span class="summary" title="Blonde on Blonde">
> Rainy Day Women #12 & 35
> </span>
> </div> 

OOPs caught me copy and pasting.

<div class="haudio">
<span class="summary" title="Rainy Day Women #12 & 35">
Rainy Day Women #12 & 35
</span>
</div>

:)

-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/20070608/1c2bffcf/smime.bin
From joe at andrieu.net  Fri Jun  8 15:26:04 2007
From: joe at andrieu.net (Joe Andrieu)
Date: Fri Jun  8 15:26:10 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <1181336377.12603.109.camel@localhost.localdomain>
Message-ID: <001a01c7aa1c$0163ea80$0201a8c0@andrieuhome>

Martin McEvoy wrote:
> On Fri, 2007-06-08 at 21:57 +0100, Martin McEvoy wrote:
> > <div class="haudio">
> > <span class="summary" title="Blonde on Blonde">
> > Rainy Day Women #12 & 35
> > </span>
> > </div>
> 
> OOPs caught me copy and pasting.
> 
> <div class="haudio">
> <span class="summary" title="Rainy Day Women #12 & 35">
> Rainy Day Women #12 & 35
> </span>
> </div>


Actually, this is a perfect example why hidden data is problematic. I actually think the outright prohibition on it is too strict,
but as a general rule, it tends to cause problems.

Namely that it is easy for errors to creep in, and to do so in a way that avoids human visual checks that are critical to quality
control on any data set.  

This is even worse when you are duplicating data (a problem on its own), because copy & paste & edit will often miss one or the
other. I've done this many times with HTML for example, where I c&p a template, cycle through and update it to each sections new
data, but almost inevitably, I miss one edit or another.

Which is all to say that we should do what we can to avoid approaches that /systematically/ induce these types of human error.

I've always been puzzled by the anti-namespace and non-scoping arguments.  The world is probably too rich to suitably represent good
names without one or the other approach. If "audio-title" or "audiotitle" violates namespace principles here, then I think we are
seriously hitting one of the scaling problems of uF.

Of course, it has been argued that uF isn't supposed to scale and perhaps this is one of those areas where the namespace and scoping
principles induce a boundary on scale.  If that's really the point we are at, can someone explain why this is a good thing again?

Because, it is clear to me that "title" is just the tip of the iceburg on this problem, and in fact "audio-title" is really just the
hint of something in the water. Virtually all media have titles. In fact, the working schema for hCitation also has this problem[1].

[1] http://microformats.org/wiki/citation-brainstorming 


So, to clarify how we got to this point, why can't "title" be bound to the semantics of the first parent container to have a rule
for it?

I believe the answer is that because existing parsers would have to be constantly updated to handle new uFs contained therein. In
other words, hCard parsers would have to be re-written to handle contained hAudios. Am I following that argument correctly?  If so,
I don't quite understand the problem because hCard's don't contain hAudio. Or can they?  

Is there some way to embed arbitrary content into an hCard and have it actually be logically or semantically /embedded/ in the
hCard? I know you can do it presentationally so it displays the data. But does the hCard data model have a place for arbitrary
embedded content? If so, couldn't the parser simply ignore the children of that field when parsing for "title"?

-j

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


From martin at weborganics.co.uk  Fri Jun  8 16:28:17 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Jun  8 16:26:48 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <001a01c7aa1c$0163ea80$0201a8c0@andrieuhome>
References: <001a01c7aa1c$0163ea80$0201a8c0@andrieuhome>
Message-ID: <1181345297.14711.13.camel@localhost.localdomain>

On Fri, 2007-06-08 at 15:26 -0700, Joe Andrieu wrote:
> Martin McEvoy wrote:
> > On Fri, 2007-06-08 at 21:57 +0100, Martin McEvoy wrote:
> > > <div class="haudio">
> > > <span class="summary" title="Blonde on Blonde">
> > > Rainy Day Women #12 & 35
> > > </span>
> > > </div>
> > 
> > OOPs caught me copy and pasting.
> > 
> > <div class="haudio">
> > <span class="summary" title="Rainy Day Women #12 & 35">
> > Rainy Day Women #12 & 35
> > </span>
> > </div>
> 
> 
> Actually, this is a perfect example why hidden data is problematic. I actually think the outright prohibition on it is too strict,
> but as a general rule, it tends to cause problems.
> 
> Namely that it is easy for errors to creep in, and to do so in a way that avoids human visual checks that are critical to quality
> control on any data set.  
> 
> This is even worse when you are duplicating data (a problem on its own), because copy & paste & edit will often miss one or the
> other. I've done this many times with HTML for example, where I c&p a template, cycle through and update it to each sections new
> data, but almost inevitably, I miss one edit or another.

you have made a good point duplicating data! and really it doesn't make
much sense does it?

back to this then..

<div class="haudio">
<span class="summary">
Rainy Day Women #12 & 35
</span>
</div>

and 

<div class="haudio">
<dfn>Blonde on Blonde</dfn>
</div>

for a defining instance of hAudio 
I have ommited summary because that too didn't make much sense a
defining term inside a summary? 

> 
> Which is all to say that we should do what we can to avoid approaches that /systematically/ induce these types of human error.
> 
> I've always been puzzled by the anti-namespace and non-scoping arguments.  The world is probably too rich to suitably represent good
> names without one or the other approach. If "audio-title" or "audiotitle" violates namespace principles here, then I think we are
> seriously hitting one of the scaling problems of uF.

we are indeed hitting a brick wall

> 
> Of course, it has been argued that uF isn't supposed to scale and perhaps this is one of those areas where the namespace and scoping
> principles induce a boundary on scale.  If that's really the point we are at, can someone explain why this is a good thing again?
> 
> Because, it is clear to me that "title" is just the tip of the iceburg on this problem, and in fact "audio-title" is really just the
> hint of something in the water. Virtually all media have titles. In fact, the working schema for hCitation also has this problem[1].
> 
> [1] http://microformats.org/wiki/citation-brainstorming 
> 
> 
> So, to clarify how we got to this point, why can't "title" be bound to the semantics of the first parent container to have a rule
> for it?
> 
> I believe the answer is that because existing parsers would have to be constantly updated to handle new uFs contained therein. In
> other words, hCard parsers would have to be re-written to handle contained hAudios. Am I following that argument correctly?  If so,
> I don't quite understand the problem because hCard's don't contain hAudio. Or can they? 

No I don't think they can

>  
> 
> Is there some way to embed arbitrary content into an hCard and have it actually be logically or semantically /embedded/ in the
> hCard? I know you can do it presentationally so it displays the data. But does the hCard data model have a place for arbitrary
> embedded content? If so, couldn't the parser simply ignore the children of that field when parsing for "title"?

now that is a question for someone with a little more understanding than
me.

-Martin-
> 
> -j
> 
> --
> Joe Andrieu
> SwitchBook Software
> http://www.switchbook.com
> joe@switchbook.com
> +1 (805) 705-8651 
> 
-------------- 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/20070609/343ea386/smime.bin
From andy at pigsonthewing.org.uk  Fri Jun  8 16:59:40 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Fri Jun  8 17:01:25 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <001a01c7aa1c$0163ea80$0201a8c0@andrieuhome>
References: <1181336377.12603.109.camel@localhost.localdomain>
	<001a01c7aa1c$0163ea80$0201a8c0@andrieuhome>
Message-ID: <q$IQWG6s1eaGFw0u@pigsonthewing.org.uk>

In message <001a01c7aa1c$0163ea80$0201a8c0@andrieuhome>, Joe Andrieu
<joe@andrieu.net> writes

>If "audio-title" or "audiotitle" violates namespace principles here,
>then I think we are seriously hitting one of the scaling problems of
>uF.

We have a precedent in

        honorific-prefix
        honorific-suffix

(ironically, the former might be called "title"!)


>Of course, it has been argued that uF isn't supposed to scale and
>perhaps this is one of those areas where the namespace and scoping
>principles induce a boundary on scale.  If that's really the point we
>are at, can someone explain why this is a good thing again?

I think it was "not invented here".


>In other words, hCard parsers would have to be re-written to handle
>contained hAudios. Am I following that argument correctly?  If so, I
>don't quite understand the problem because hCard's don't contain
>hAudio. Or can they?

Suppose I make my autobiographical web page an hCard, using:

        class="vcard"

That's valid.

then suppose I decide to include on my page an mp3 of my new hit
single...

-- 
Andy Mabbett
            *  Say "NO!" to compulsory UK ID Cards:  <http://www.no2id.net/>
            *  Free Our Data:  <http://www.freeourdata.org.uk>
            *  Are you using Microformats, yet: <http://microformats.org/> ?
From andy at pigsonthewing.org.uk  Fri Jun  8 17:04:08 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Fri Jun  8 17:05:30 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <1181336224.12603.106.camel@localhost.localdomain>
References: <007501c7a968$749e1ac0$0201a8c0@andrieuhome>
	<1181278554.6259.73.camel@localhost.localdomain>
	<0F6BC1FF-FA41-4010-A55F-9754EFD2021C@makedatamakesense.com>
	<1181318438.11634.58.camel@localhost.localdomain>
	<4669928B.1060104@digitalbazaar.com>
	<1181335549.12603.98.camel@localhost.localdomain>
	<1181336224.12603.106.camel@localhost.localdomain>
Message-ID: <t$9RGr645eaGFw14@pigsonthewing.org.uk>

In message <1181336224.12603.106.camel@localhost.localdomain>, Martin 
McEvoy <martin@weborganics.co.uk> writes

>You can enhance this further if you want to create extra meaning to one 
>of our hAudio's by using a bit of POSH
>
><div class="haudio">
><span class="summary" title="Blonde on Blonde">
 ><dfn>Blonde on Blonde</dfn>
 ></span>

If you were approaching this bottom (POSH) up, rather than top 
(microformat) down, you would NEVER call that a summary; you would call 
it "title", or "record" or "album-name", or something like that.

When did you last walk into a shop and say something like "do you have a 
Bob Dylan CD? I can't recall the *summary*, but it was something like 
"Blood on the Macs"?

-- 
Andy Mabbett
From scott at makedatamakesense.com  Fri Jun  8 17:25:07 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Fri Jun  8 17:25:13 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <1181335549.12603.98.camel@localhost.localdomain>
References: <007501c7a968$749e1ac0$0201a8c0@andrieuhome>
	<1181278554.6259.73.camel@localhost.localdomain>
	<0F6BC1FF-FA41-4010-A55F-9754EFD2021C@makedatamakesense.com>
	<1181318438.11634.58.camel@localhost.localdomain>
	<4669928B.1060104@digitalbazaar.com>
	<1181335549.12603.98.camel@localhost.localdomain>
Message-ID: <19CD0F3B-FEBB-4E0A-A16A-92B841280A5F@makedatamakesense.com>

On Jun 8, 2007, at 2:45 PM, Martin McEvoy wrote:

> I think at the time hCard was meant to be identical to the vCard
> Standard in every way and mach the scheme defined in
> http://www.ietf.org/rfc/rfc2426.txt there was no guess work or  
> defining
> or anything just well established standards
>
> for us to use title from vCard would mean that our meaning in hAudio
> would have to match the title attribute in the vCard standard.

Right.

> the only other microformat that does use Title is of course hAtom  
> which
> is also built around rfc standards http://www.ietf.org/rfc/rfc4287  
> Atom

hAtom actually uses "entry-title."  While that has a similar meaning  
to "title" in English, those two terms have completely distinct  
meanings in microformat definitions, because microformats definitions  
are by necessity more specific than English definitions.

> this is why we cant change hAtom to suit our needs because it is based
> on already well established standards.

Right, but if we can re-use existing class names without changing the  
meaning, we should do so, as it makes things easier for publishers.

> Summary as Brian put it is the easiest fruit to pick from the tree as
> most or the established microformats  hReview, hResume, and hCalendar
> already use summary to mean exactly what we want it to mean.

There seems to be some disagreement over whether "summary" is  
actually what we want it to mean.  I point this out not because I  
personally disagree, but because addressing this disagreement is  
required before moving forward, which I think we'd all like to do.

> The discussion around re-defining the vcard title to mean what we want
> it to mean may take a very long time to accomplish, and  it would have
> to be via the microformat process.

Right.  I think trying to change hCard, one of the oldest  
microformats, before moving forward with hAudio is a good way to  
grind the hAudio discussion to a halt for a long time, so I think we  
should do whatever we can to avoid that.

--
Scott Reynen
MakeDataMakeSense.com


From martin at weborganics.co.uk  Fri Jun  8 17:32:19 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Jun  8 17:30:50 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <t$9RGr645eaGFw14@pigsonthewing.org.uk>
References: <007501c7a968$749e1ac0$0201a8c0@andrieuhome>
	<1181278554.6259.73.camel@localhost.localdomain>
	<0F6BC1FF-FA41-4010-A55F-9754EFD2021C@makedatamakesense.com>
	<1181318438.11634.58.camel@localhost.localdomain>
	<4669928B.1060104@digitalbazaar.com>
	<1181335549.12603.98.camel@localhost.localdomain>
	<1181336224.12603.106.camel@localhost.localdomain>
	<t$9RGr645eaGFw14@pigsonthewing.org.uk>
Message-ID: <1181349139.15238.7.camel@localhost.localdomain>

On Sat, 2007-06-09 at 01:04 +0100, Andy Mabbett wrote:
> In message <1181336224.12603.106.camel@localhost.localdomain>, Martin 
> McEvoy <martin@weborganics.co.uk> writes
> 
> >You can enhance this further if you want to create extra meaning to one 
> >of our hAudio's by using a bit of POSH
> >
> ><div class="haudio">
> ><span class="summary" title="Blonde on Blonde">
>  ><dfn>Blonde on Blonde</dfn>
>  ></span>
> 
> If you were approaching this bottom (POSH) up, rather than top 
> (microformat) down, you would NEVER call that a summary; you would call 
> it "title", or "record" or "album-name", or something like that.
> 
> When did you last walk into a shop and say something like "do you have a 
> Bob Dylan CD? I can't recall the *summary*, but it was something like 
> "Blood on the Macs"?

he he he never that's why I changed it to this...

<div class="haudio">
<dfn>Blonde on Blonde</dfn>
</div>

for a defining instance of hAudio 

but I suspect that we are going to use "title"

-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/20070609/4fb51380/smime.bin
From scott at makedatamakesense.com  Fri Jun  8 17:39:21 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Fri Jun  8 17:39:26 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <001a01c7aa1c$0163ea80$0201a8c0@andrieuhome>
References: <001a01c7aa1c$0163ea80$0201a8c0@andrieuhome>
Message-ID: <996B9BD3-F9AB-43DE-8FEE-11BD69929B87@makedatamakesense.com>

On Jun 8, 2007, at 4:26 PM, Joe Andrieu wrote:

> Actually, this is a perfect example why hidden data is problematic.  
> I actually think the outright prohibition on it is too strict,
> but as a general rule, it tends to cause problems.

There's not really an outright prohibition on the title attribute.   
We use it in the abbr design pattern, for example:

http://microformats.org/wiki/abbr-design-pattern

But there is a knee-jerk reaction against it because we want to  
maximize the visibility of content, because that's where microformats  
are really unique, in using already human-visible content as machine  
data.  The more we make it invisible, the more we might as well be  
using RDF, which is not to say that RDF is always bad, just that a  
diversity of options is good, so we should emphasize what makes  
microformats unique, e.g. visible data.

> I've always been puzzled by the anti-namespace and non-scoping  
> arguments.

For me, they boil down to what I said above: emphasize what makes  
microformats different (e.g. lack of namespaces) from other formats  
to give publishers the most alternatives.

> The world is probably too rich to suitably represent good
> names without one or the other approach. If "audio-title" or  
> "audiotitle" violates namespace principles here, then I think we are
> seriously hitting one of the scaling problems of uF.

In many ways, we are, and that's okay (in my view, of course --  
others certainly disagree).  RDF can scale while microformats ease  
the learning curve to a more data-rich web.  But we also have profile  
URIs available to accomplish much of what namespaces accomplish, and  
we're not really taking advantage of those now:

http://microformats.org/wiki/profile-uris

I doubt we'll ever focus heavily on profile URIs until someone else  
develops a popular alternative use of class names that conflicts with  
microformats, just because this is a community founded around solving  
the most obvious problems first, and that's what it will take to make  
disambiguation an obvious problem.

> Of course, it has been argued that uF isn't supposed to scale and  
> perhaps this is one of those areas where the namespace and scoping
> principles induce a boundary on scale.  If that's really the point  
> we are at, can someone explain why this is a good thing again?

In some ways scalability and ease-of-use are mutually exclusive, and  
microformats are in the ease-of-use camp.  In this case, it's easier  
to assume a given class name always means the same thing, so that's  
what microformats let publishers do.  When publishers run into a  
situation where they absolutely need namespaces, then they can always  
move to RDF.  But if microformats were to become more like RDF, then  
understanding namespaces would become a prerequisite to publishing  
machine-readable data on the web, which would result in fewer  
publishers doing so.  I would use a metaphor of microformats as  
training wheels for web-based data publishing.  When publishers start  
to get tired of the training wheels, they can take them off their own  
bike and start using RDF.  But banishing training wheels in general  
is not helpful to other beginners.  And right now the web is full of  
data-publishing beginners.

> Because, it is clear to me that "title" is just the tip of the  
> iceburg on this problem, and in fact "audio-title" is really just the
> hint of something in the water. Virtually all media have titles. In  
> fact, the working schema for hCitation also has this problem[1].
>
> [1] http://microformats.org/wiki/citation-brainstorming

Right, so ideally we would choose a term specific enough to have a  
clear meaning in the context of hAudio, but general enough to also be  
usable in future microformats.  And looking to previous microformats  
is a good way to find such a term, because if it works in both  
another microformat and hAudio, it probably has a good balance of  
specificity and re-usability.

> So, to clarify how we got to this point, why can't "title" be bound  
> to the semantics of the first parent container to have a rule
> for it?

Joe already seems to know the answer to this question, but for those  
new to this issue, consider this:

<div class="haudio">
	<span class="title">Purple Haze</span> by
	<span class="hcard">
		<span class="fn">Jimi Hendrix</span>, <span class="title">musical  
legend</span>
	</span>
</div>

The problem comes when trying to determine the title of this hAudio.   
How do we know if it's "Purple Haze" or "musical legend"?  We could  
tell parsers to ignore hCards, but that requires parsers to be aware  
of not only the microformat they're parsing, but also any other  
microformat that might include the same property names, some of which  
may not exist until after the parser is written.  I don't believe  
this is an impossible problem to solve, but as Brian said, it is a  
difficult problem.  When faced with the option of solving this  
difficult problem or choosing a different name and moving on, I  
expect most people interested in hAudio will opt to just choose a  
different name.  Repeat that over every microformat, and you get  
where we are now.

> I believe the answer is that because existing parsers would have to  
> be constantly updated to handle new uFs contained therein. In
> other words, hCard parsers would have to be re-written to handle  
> contained hAudios. Am I following that argument correctly?

Pretty much.  With "title," there's also an argument that we should  
neither use the same term to mean different things nor change the  
meaning of terms in already-published microformats.  I expect even  
slightly expanding the meaning of a term in a microformat published  
as widely as hCard would be an uphill battle.

> If so, I don't quite understand the problem because hCard's don't  
> contain hAudio. Or can they?

They could.  My hCard is here:

http://typewriting.org/about/scott/

If you look at the source of that page, you'll see the hCard covers  
almost the entire page, because my name is at the top and my birthday  
is at the bottom.  If I wanted to list my favorite song on that page,  
as I've previously done, I couldn't do it in hAudio without risking  
the song title would become my job title, as long as there are no  
rules to prevent that.  This is still an edge case, but it's an edge  
case that grows exponentially every time we re-use an existing class  
name in a new microformat.

> Is there some way to embed arbitrary content into an hCard and have  
> it actually be logically or semantically /embedded/ in the
> hCard? I know you can do it presentationally so it displays the  
> data. But does the hCard data model have a place for arbitrary
> embedded content? If so, couldn't the parser simply ignore the  
> children of that field when parsing for "title"?

Notes, maybe.  Ideally someone would be able to include an hAudio  
inside the node of an hCard without influencing the hCard at all.   
Also, it would be nice if there were a general solution that worked  
on any microformat embedded in any other.  That's generally where  
this seems to be headed:

http://microformats.org/wiki/mfo

The idea there seems to be that the included hAudio could have the  
"mfo" class added, e.g. class="haudio mfo" and that would indicate to  
any hCard parsers that they should ignore that section the  
surrounding hCard.  The same would work for embedding hAudio in  
hReview if we decided to re-use summary, or with embedding hAudio in  
hAtom if we re-used entry-title.  But there are several issues with  
that idea, and I haven't seen much interest in discussing it further.

--
Scott Reynen
MakeDataMakeSense.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://microformats.org/discuss/mail/microformats-new/attachments/20070608/5a676b67/attachment-0001.html
From martin at weborganics.co.uk  Fri Jun  8 18:20:53 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Jun  8 18:19:23 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <19CD0F3B-FEBB-4E0A-A16A-92B841280A5F@makedatamakesense.com>
References: <007501c7a968$749e1ac0$0201a8c0@andrieuhome>
	<1181278554.6259.73.camel@localhost.localdomain>
	<0F6BC1FF-FA41-4010-A55F-9754EFD2021C@makedatamakesense.com>
	<1181318438.11634.58.camel@localhost.localdomain>
	<4669928B.1060104@digitalbazaar.com>
	<1181335549.12603.98.camel@localhost.localdomain>
	<19CD0F3B-FEBB-4E0A-A16A-92B841280A5F@makedatamakesense.com>
Message-ID: <1181352053.15238.17.camel@localhost.localdomain>

On Fri, 2007-06-08 at 18:25 -0600, Scott Reynen wrote:
> On Jun 8, 2007, at 2:45 PM, Martin McEvoy wrote:
> 
> > I think at the time hCard was meant to be identical to the vCard
> > Standard in every way and mach the scheme defined in
> > http://www.ietf.org/rfc/rfc2426.txt there was no guess work or  
> > defining
> > or anything just well established standards
> >
> > for us to use title from vCard would mean that our meaning in hAudio
> > would have to match the title attribute in the vCard standard.
> 
> Right.
> 
> > the only other microformat that does use Title is of course hAtom  
> > which
> > is also built around rfc standards http://www.ietf.org/rfc/rfc4287  
> > Atom
> 
> hAtom actually uses "entry-title."  While that has a similar meaning  
> to "title" in English, those two terms have completely distinct  
> meanings in microformat definitions, because microformats definitions  
> are by necessity more specific than English definitions.

which is why entry-title would not be suitable...

> 
> > this is why we cant change hAtom to suit our needs because it is based
> > on already well established standards.
> 
> Right, but if we can re-use existing class names without changing the  
> meaning, we should do so, as it makes things easier for publishers.

I agree strongly with this principle..

> 
> > Summary as Brian put it is the easiest fruit to pick from the tree as
> > most or the established microformats  hReview, hResume, and hCalendar
> > already use summary to mean exactly what we want it to mean.
> 
> There seems to be some disagreement over whether "summary" is  
> actually what we want it to mean.  I point this out not because I  
> personally disagree, but because addressing this disagreement is  
> required before moving forward, which I think we'd all like to do.

correct

> 
> > The discussion around re-defining the vcard title to mean what we want
> > it to mean may take a very long time to accomplish, and  it would have
> > to be via the microformat process.
> 
> Right.  I think trying to change hCard, one of the oldest  
> microformats, before moving forward with hAudio is a good way to  
> grind the hAudio discussion to a halt for a long time, so I think we  
> should do whatever we can to avoid that.

not that i think it is possible to change the meaning of title in hCard 

and yes this is exactly what I am suggesting we avoid

so what do we do? is the question, 

-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/20070609/d5fd536f/smime.bin
From joe at andrieu.net  Fri Jun  8 23:09:46 2007
From: joe at andrieu.net (Joe Andrieu)
Date: Fri Jun  8 23:09:48 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <1181352053.15238.17.camel@localhost.localdomain>
Message-ID: <000a01c7aa5c$c85cda30$0201a8c0@andrieuhome>

Martin McEvoy wrote:
> On Fri, 2007-06-08 at 18:25 -0600, Scott Reynen wrote:
> > On Jun 8, 2007, at 2:45 PM, Martin McEvoy wrote:
> > 
> > > the only other microformat that does use Title is of course hAtom
> > > which
> > > is also built around rfc standards 
> http://www.ietf.org/rfc/rfc4287  
> > > Atom
> > 
> > hAtom actually uses "entry-title."  While that has a similar meaning
> > to "title" in English, those two terms have completely distinct  
> > meanings in microformat definitions, because microformats 
> definitions  
> > are by necessity more specific than English definitions.
> 
> which is why entry-title would not be suitable...

>From Scott's comments, I think I understand.

Either we need a generic "exclusion" container so that parent uFs can know to ignore potential duplicates in a child uF--which I
think is the heart of the "mfo" suggestion--or we need unique field names.

In short, that is because a uF can have sequentially embedded content that is not logically embedded. "mfo" would logically embed it
in a no-parse zone for current parents.  That sounds reasonable, but I think it is a "young" conversation that will take some time
to evaluate and work through its paces.

So, if hAtom uses "entry-title", why is "audio-title" bad?

-j

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


From andy at pigsonthewing.org.uk  Sat Jun  9 01:03:30 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sat Jun  9 01:05:01 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <000a01c7aa5c$c85cda30$0201a8c0@andrieuhome>
References: <1181352053.15238.17.camel@localhost.localdomain>
	<000a01c7aa5c$c85cda30$0201a8c0@andrieuhome>
Message-ID: <DqXKjZAS7laGFwA5@pigsonthewing.org.uk>

In message <000a01c7aa5c$c85cda30$0201a8c0@andrieuhome>, Joe Andrieu 
<joe@andrieu.net> writes

>Either we need a generic "exclusion" container so that parent uFs can 
>know to ignore potential duplicates in a child uF--which I think is the 
>heart of the "mfo" suggestion--

How would they be backwards-compatible?

>or we need unique field names.

Unique field names are "POSH".

Otherwise, we might as well start labelling with class="thing" or 
class="property16", class="property17" et al.

-- 
Andy Mabbett
From msporny at digitalbazaar.com  Sat Jun  9 12:26:12 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sat Jun  9 12:26:14 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <001a01c7aa1c$0163ea80$0201a8c0@andrieuhome>
References: <001a01c7aa1c$0163ea80$0201a8c0@andrieuhome>
Message-ID: <466AFED4.2060809@digitalbazaar.com>

Joe Andrieu wrote:
> I've always been puzzled by the anti-namespace and non-scoping arguments.

This discussion speaks volumes about how badly Microformats scale. This
whole process is short-sighted - it doesn't promote looking at the big
picture... about where we're headed if we keep making the short-term
decisions that we keep making.

We have five moderately sophisticated markup formats; hCalendar, hCard,
hAtom, hResume, and hReview. The fact that we're having such a hard time
deciding on a what to call "the distinguishing name of an audio
recording" is very telling - Microformat class naming is getting
exponentially more complicated.

In fact, the more Microformats there are - the more restrictive using
each with one another will become. There are two very contrary
Microformat philosophies at work here:

1. Reusing class names should be promoted as much as possible.
2. Due to no namespaces and no scoping - reusing terms restricts which
terms can be re-used.

The end result is we don't re-use class names. Rather than create the
possibility of a conflict when two or three Microformats are combined -
most uF authors will opt to create a new term.

As Scott pointed out, we probably don't want to use 'summary' because
placing an hAudio in an hReview is something that we want to do. In
fact, because we want hAudio to be integrated with hAtom and hReview -
we probably don't want to re-use any class names in either Microformat.

Following this logic, for anything that could be embedded in hAtom or
hReview, we could make good arguments for ruling out (at a bare minimum):

author, published, tags, entry-title, summary, type, item, rating,
description

Since hAtom and hReview also use hCard, it would also rule out:

fn, title, photo, logo, nickname, n

This is a problem because the semantics of 'fn', 'description' and
'summary' should be reused widely. However, because of the no-scoping
rule... we have to be incredibly careful with how we pick names.

For example, we may want to use 'description' for a 'work-of-art', but
because we wanted to embed the 'work-of-art' Microformat in hReview - we
can't use it.

What are the arguments against 'audio-title', again? We have
'entry-title', why can't we have an 'audio-title'?

-- manu

From martin at weborganics.co.uk  Sat Jun  9 13:45:34 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Jun  9 13:44:13 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <000a01c7aa5c$c85cda30$0201a8c0@andrieuhome>
References: <000a01c7aa5c$c85cda30$0201a8c0@andrieuhome>
Message-ID: <1181421935.18029.260.camel@localhost.localdomain>

On Fri, 2007-06-08 at 23:09 -0700, Joe Andrieu wrote:

> So, if hAtom uses "entry-title", why is "audio-title" bad?

and 

On Sat, 2007-06-09 at 15:26 -0400, Manu Sporny wrote:
> What are the arguments against 'audio-title', again? We have
> 'entry-title', why can't we have an 'audio-title'? 

I think I need to give you and everyone an insight into my logic and
explain a little why I proposed "summary" instead of FN I cannot vouch
for my accuracy in the following statements It is just how *I* see our
problem.

Why do I think audio-title is bad? because hAudio is not really based on
any standard audio-title would reflect the meaning of entry-title in
hAtom yes?

The hAtom entry-title matches the atom value of atom:title a property
that can only be used once within an atom:entry (hentry) and built upon
the RFC 4287 standard

*snip
The "atom:title" element is a Text construct that conveys a
human-readable title for an entry or feed

Although I was tempted to suggest we try entry-title this still doesn't
mean what we want our haudio title to mean

imagine...

haudio
  entry-title vcard fn [main title]
haudio
     entry-title download [track title] 
haudio
     entry-title download [track title]

Can you see the scenario hAudio has the need to define TWO different
titles depending on in which context it is used, song titles which are
used to describe a single track, and a title to describe an album or
collection which is a number of tracks. Atom does not yet have the
ability to do this.

Your audio-title would then have the same issues as work-title,
work-title for me worked, but threw up the issues of creating another
definition of title in vcard which is not really possible. This is only
because hAudio is not based on any standard and as such has to share its
meanings with other established microformats. We cant just pick names
out of the air and say this is what we will use they have to be based on
some kind of logic or established practices.

So the decision ended at FN as it closley mached our definition of
work-title

*snip
To specify the formatted text corresponding to the name of the object

great yes? it says what we mean, accept when you do this...

haudio
  vcard fn fn [Main title]
haudio
  fn download [track title] 
haudio
  fn download [track title]

confusing isn't it? because vCard in the same way as Atom does not yet
have the ability to convey FN as two different meanings or three in this
case.

hAudio is not designed or based upon any standard but it does use
standards compliant terms, its sole intention was to reuse existing
microformats, because it makes it easy to use, quicker to uptake, and
has a low cognitive load, and many other microformats that don't use any
particular standard are made in this way.

"summary" to me is what what we are left with:

hResume
summary[re-used from iCal rfc 2445]:: The class name summary is used to
mark up an overview of qualifications and objectives.
http://microformats.org/wiki/hresume#Field_details

a bit vague but over overview of a song or album is roughly how you
would describe a hAudio title...

hReview
summary[re-used from iCal rfc 2445]:: This optional field serves as a
title for the review itself.
http://microformats.org/wiki/hreview#Field_details

now this is better not exactly a review but it is a title...

hCalendar [Is based on iCal rfc 2445]
summary:: Short synopsis, title, or  name of the event. 
http://www.ietf.org/rfc/rfc2445.txt section 4.8.1.12.

...this gets even better uses the word title to mean title and it is
based on a standard.

The problem I am gathering is that "summary" is still a bit vague and
people would still like us to use title, am I correct? 

we have already established that we cant pick names out of thin air.

To do this sensibly is to base our proposal on a widely used
specification. *This is how Microformats scale*.

Our choices may be SMIL or ASX but we can't as all these formats are not
based upon open standards [patent issues]. 

RSS from what I can gather was owned by Netscape then Userland and was
later donated to a not-for-profit organization Harvard Law school.
RSS is still not an open standard and may be inadequate for our needs
[patent issues].

Atom was created in response to this [an open format].
http://en.wikipedia.org/wiki/ATOM#Development_History
 
So back to hAtom again, Although hAudio does have atomic properties Atom
does have a strict rule-set, things you are allowed to do and not
allowed to do. hAudio would have to adhere to the same principles. like
having two atom:title's within one atom:entry is a no no and have a
minimum required markup atom:title and atom:updated not too bad you
would say but how many examples can you find that have a date along side
the track title? relevant for a podcast I would say, but not enough
scope for hAudio.

So I would like to suggest that If we do want to base our proposal on a
standard then I would recommend using XSPF.
http://www.xspf.org/xspf-v1.html 

The reasons are, It is very similar to Atom, It uses XML (Great for
transformational uses, xslt), and it is an open format. 

I suggested It to Manu some time ago but he had the thought that it may
not be accepted and deemed pointless because we have hAtom at the time I
agreed with his point and put the idea to the back of my mind, 
At the time I had spent some time maping hAudio properties to XSPF. 
I am not saying this is in any way relevant just something to illustrate
my thought, I put all my findings in my user talk page on the wiki, The
work is not there now but you can see a diff here
http://microformats.org/wiki?title=User_talk:WebOrganics&diff=16847&oldid=16846#hSpiff_0.0.2

Im not too sure that we shouldn't use something like this now judging by
the current discussion...

Knowingly or not hAudio does share its naming structure with XSPF. All
the properties hAudio has and needs are available in XSPF, we could use
title in two different contexts and still have meaning.
 We would not have to create an new meaning for our hAudio title because
our proposal would be based on a standard. We can use x-title or
something similar. We can re-use all XSPF elements in hAudio hVideo
hImage, and as far as I know microformateer Kevin Marks may be able to
direct us further on this as I believe he Is/was one of the contributors
of XSPF and had strong influence on its architecture.

*Thought*

Podcasting has been around for a long time but imagine the scope that
xCast [or whatever name we would choose] could present to the podcasting
community and applications like SongBird. I could imagine that xCast
would be as popular in the podcasting community as hAtom is in Blogging.

[Sorry @Scott for thinking too far ahead I have to sometimes]

So there you go as simple as I can, If we cant use summary-track/song
and dfn-Album/collection then I recommend that we base our proposal on a
widely recognized format XSPF or something similar.

-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/20070609/025430f9/smime-0001.bin
From davidjanes at blogmatrix.com  Sat Jun  9 16:39:28 2007
From: davidjanes at blogmatrix.com (David Janes)
Date: Sat Jun  9 16:39:31 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <1181259783.3189.181.camel@localhost.localdomain>
References: <005a01c7a954$e71a5c80$0201a8c0@andrieuhome>
	<1181259783.3189.181.camel@localhost.localdomain>
Message-ID: <21e523c20706091639j6f78fe48j7ba5a51b23636c80@mail.gmail.com>

On 6/7/07, Martin McEvoy <martin@weborganics.co.uk> wrote:
> I am presuming that the reason we have entry-title in hAtom and not
> title is because title had already been defined in vcard to mean
> something else, but there was compelling evidence to support a title of
> a different meaning?

Nope. The competition for "entry-title" was "fn". The reason we didn't
go with "fn" was that we decided that the concept of a title of a blog
post -- i.e. what "fn" means -- wasn't always what you'd see on the
blog.

For example, Dave Winer uses _something_ like <h3>2007/06/09 Here's a
Blog Post</h3> on his blog. This is the "entry-title", but the "fn" of
the post is "Here's a Blog Post".

Regards, etc...

PS. I regret this decision a little, but not too much -- in
retrospect, 80/20 rule would make it "fn"

-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
From andy at pigsonthewing.org.uk  Sun Jun 10 11:23:37 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sun Jun 10 11:25:06 2007
Subject: [uf-new] title vs. summary (was: Third attempt at hAudio)
In-Reply-To: <21e523c20706091639j6f78fe48j7ba5a51b23636c80@mail.gmail.com>
References: <005a01c7a954$e71a5c80$0201a8c0@andrieuhome>
	<1181259783.3189.181.camel@localhost.localdomain>
	<21e523c20706091639j6f78fe48j7ba5a51b23636c80@mail.gmail.com>
Message-ID: <P4YpXePpGEbGFw4m@pigsonthewing.org.uk>

In message 
<21e523c20706091639j6f78fe48j7ba5a51b23636c80@mail.gmail.com>, David 
Janes <davidjanes@blogmatrix.com> writes

>I regret this decision a little, but not too much -- in
>retrospect, 80/20 rule would make it "fn"

Who wants to be wrong one-fifth of the time?

-- 
Andy Mabbett
From msporny at digitalbazaar.com  Mon Jun 11 09:22:42 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Mon Jun 11 09:22:45 2007
Subject: [uf-new] audio-title proposal for haudio
Message-ID: <466D76D2.3020600@digitalbazaar.com>

There seem to be quite a number of good arguments one way or the other
concerning the use or mis-use of 'title', 'summary', 'description', and
other such pre-existing class names.

Since we plan to embed haudio in other Microformats, it seems that we
should pick something that will not conflict with any of the other
already created Microformats.

Trying to convince the list to re-use any of the pre-existing element
names has met with stiff opposition.

I am proposing that we use 'audio-title' and leave it at that. I'll work
this into the haudio proposal at the end of this week unless there is
strong opposition to this proposal.

If you are strongly opposed to 'audio-title', please provide an
alternative in your argument against it.

-- manu

From scott at makedatamakesense.com  Mon Jun 11 10:46:35 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Mon Jun 11 10:47:04 2007
Subject: [uf-new] audio-title proposal for haudio
In-Reply-To: <466D76D2.3020600@digitalbazaar.com>
References: <466D76D2.3020600@digitalbazaar.com>
Message-ID: <184D8127-2554-4242-96A1-D576C93D2125@makedatamakesense.com>

On Jun 11, 2007, at 10:22 AM, Manu Sporny wrote:

> I am proposing that we use 'audio-title' and leave it at that. I'll  
> work
> this into the haudio proposal at the end of this week unless there is
> strong opposition to this proposal.
>
> If you are strongly opposed to 'audio-title', please provide an
> alternative in your argument against it.

I'm not sure my opposition is "strong," but I would personally prefer  
working out parsing rules to allow for embedded microformats with  
shared property names, and then re-examining the alternatives without  
this as a constraint.  But again, I think the wiki should reflect the  
diversity of views, and not be restricted to what is seen as  
consensus.  Email archives are a poor medium in which to review  
decisions, as indicated by nearly every other message in this thread  
starting with "we already talked about that..."

--
Scott Reynen
MakeDataMakeSense.com


From martin at weborganics.co.uk  Mon Jun 11 11:55:17 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Mon Jun 11 11:53:42 2007
Subject: [uf-new] audio-title proposal for haudio
In-Reply-To: <466D76D2.3020600@digitalbazaar.com>
References: <466D76D2.3020600@digitalbazaar.com>
Message-ID: <1181588117.4934.9.camel@localhost.localdomain>

On Mon, 2007-06-11 at 12:22 -0400, Manu Sporny wrote:
> There seem to be quite a number of good arguments one way or the other
> concerning the use or mis-use of 'title', 'summary', 'description', and
> other such pre-existing class names.
> 
> Since we plan to embed haudio in other Microformats, it seems that we
> should pick something that will not conflict with any of the other
> already created Microformats.
> 
> Trying to convince the list to re-use any of the pre-existing element
> names has met with stiff opposition.
> 
> I am proposing that we use 'audio-title' and leave it at that. I'll work
> this into the haudio proposal at the end of this week unless there is
> strong opposition to this proposal.

I know I sound awkward 

I preferred work-title if we are going to invent a new microformat.

"work-title of an audio recording is a short textual description used to
identify the work among interested parties. This is also referred to as
the title of the work. This can be the title of a speech, song title, or
short description regarding a sound effect."

At least it's more likely to be re-used in other microformats

-Martin-
> 
> If you are strongly opposed to 'audio-title', please provide an
> alternative in your argument against it.
> 
> -- 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/20070611/9cb4339d/smime.bin
From joe at andrieu.net  Mon Jun 11 12:16:58 2007
From: joe at andrieu.net (Joe Andrieu)
Date: Mon Jun 11 12:17:00 2007
Subject: [uf-new] audio-title proposal for haudio
In-Reply-To: <1181588117.4934.9.camel@localhost.localdomain>
Message-ID: <004201c7ac5d$15aa0b30$1afa030a@andrieuhome>

> Monday, June 11, 2007 11:55 AM, Martin McEvoy wrote
> On Mon, 2007-06-11 at 12:22 -0400, Manu Sporny wrote:
> > I am proposing that we use 'audio-title' and leave it at that. I'll 
> > work this into the haudio proposal at the end of this week unless 
> > there is strong opposition to this proposal.
> 
> I preferred work-title if we are going to invent a new microformat.
> 
> "work-title of an audio recording is a short textual 
> description used to identify the work among interested 
> parties. This is also referred to as the title of the work. 
> This can be the title of a speech, song title, or short 
> description regarding a sound effect."
> 
> At least it's more likely to be re-used in other microformats

Actually, it is quite likely to be used in the work of art uF under discussion.

But I that is actually the problem.  What if I have a speech about a work of art? Or an audio-tour of the Louvre? Embedded
hWorkOfArt in those hAudio now have name conflicts.

Audio is audio, no?

Speech, song, sound effect. "audio-title" seems to fit with all of those, without losing specificity and without overlapping with
other potential "works".

I agree with Scott that solving the embedding problem /generally/ would be preferable.  However, I think audio-title is better than
work-title, both because of overlap and because I think it more accurately addresses the currently scoped problem of marking up a
piece of audio.

-j

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

From martin at weborganics.co.uk  Mon Jun 11 13:31:58 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Mon Jun 11 13:30:25 2007
Subject: [uf-new] audio-title proposal for haudio
In-Reply-To: <004201c7ac5d$15aa0b30$1afa030a@andrieuhome>
References: <004201c7ac5d$15aa0b30$1afa030a@andrieuhome>
Message-ID: <1181593918.6450.12.camel@localhost.localdomain>

On Mon, 2007-06-11 at 12:16 -0700, Joe Andrieu wrote:
> > Monday, June 11, 2007 11:55 AM, Martin McEvoy wrote
> > On Mon, 2007-06-11 at 12:22 -0400, Manu Sporny wrote:
> > > I am proposing that we use 'audio-title' and leave it at that. I'll 
> > > work this into the haudio proposal at the end of this week unless 
> > > there is strong opposition to this proposal.
> > 
> > I preferred work-title if we are going to invent a new microformat.
> > 
> > "work-title of an audio recording is a short textual 
> > description used to identify the work among interested 
> > parties. This is also referred to as the title of the work. 
> > This can be the title of a speech, song title, or short 
> > description regarding a sound effect."
> > 
> > At least it's more likely to be re-used in other microformats
> 
> Actually, it is quite likely to be used in the work of art uF under discussion.
> 
> But I that is actually the problem.  What if I have a speech about a work of art? Or an audio-tour of the Louvre? Embedded
> hWorkOfArt in those hAudio now have name conflicts.

OK?

> 
> Audio is audio, no?
> 
> Speech, song, sound effect. "audio-title" seems to fit with all of those, without losing specificity and without overlapping with
> other potential "works".
> 
> I agree with Scott that solving the embedding problem /generally/ would be preferable.  However, I think audio-title is better than
> work-title, both because of overlap and because I think it more accurately addresses the currently scoped problem of marking up a
> piece of audio.

...why not! I really don't have a preference any more, as long as
everyone else agrees its fine by me.

-Martin-
> 
> -j
> 
> --
> Joe Andrieu
> SwitchBook Software
> http://www.switchbook.com
> joe@switchbook.com
> +1 (805) 705-8651 
> 
-------------- 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/20070611/10c9b469/smime.bin
From daniel.chudnov at gmail.com  Tue Jun 12 21:35:25 2007
From: daniel.chudnov at gmail.com (D Chudnov)
Date: Tue Jun 12 21:35:29 2007
Subject: [uf-new] div class for "service links"?
Message-ID: <4c5d16c30706122135m388274adt2d4cae2e0e57a6c5@mail.gmail.com>

Has anybody thought, talked about, or worked on naming those boxes of
"service links" every site seems to have now?  You know, the ones
within which you can "save to delicious" and "digg this" and "save to
facebook" or "look this up in technorati".  There are plugins that add
these sets of links for all the major blog engines, and all the major
media outlets seem to support some random subset of the world of
possible service links, but never just the ones I want.

I want to be able to dynamically mix in the exact services I subscribe
to whenever I see one of these, and I want institutions like libraries
to be able to mix in the kinds of stuff they're doing with OpenURL
right there, too, but it shouldn't take a lot of work.  If, for every
time anybody publishes one of those "boxes of service links", we could
at least identify that "this is where the service links go", we could
make quite a bit of progress toward this goal.

It could be as easy as "<div class='service-links'>blah blah
blah</div>".   Or class="serviceable".  Or something more uf-ish like
"hServices".

Let me know if this sounds interesting, or if I've missed some work on
something like this.

Thanks, -Dan
From ryan at technorati.com  Wed Jun 13 20:33:29 2007
From: ryan at technorati.com (Ryan King)
Date: Wed Jun 13 20:33:35 2007
Subject: [uf-new] Reusing classes names in multiple formats
In-Reply-To: <4669A164.7020100@digitalbazaar.com>
References: <21e770780706080901y1a4c99c3oa20bbe2dbc5999df@mail.gmail.com>
	<4669A164.7020100@digitalbazaar.com>
Message-ID: <5C179AF1-051B-43F0-8CA0-9A7B5DA87629@technorati.com>

On Jun 8, 2007, at 11:35 AM, Manu Sporny wrote:
> Brian Suda wrote:
>> On 6/8/07, Scott Reynen <scott@makedatamakesense.com> wrote:
>>> This is the same problem with re-using any class name in multiple
>>> microformats.  As mentioned earlier, if we re-use "summary" in  
>>> haudio
>>> (which I'm not arguing for nor against here), what if we want to
>>> embed haudio inside hreview?
>>
>> SUMMARY is defined as:
>> A short summary or subject for the object.
>
> I think Scott's point is that we have the same problem using  
> 'summary',
> as we do with using 'title', as we do with using 'fn'.
>
>> if you have
>> media
>>   hcard
>>    title#1
>>   title#2
>>
>> then title#1 will be used for the media, NOT title#2
>
> Egad! I had no idea that is what the community meant by "no
> namespace"... to programmers what you have described is a scope-less,
> procedural language. Am I misunderstanding you? Do Microformats use a
> scope-less design paradigm? Am I waaaaaay off here (I hope I am):

Yes. No name scoping. Only context scoping. And contexts can overlap.

> Variable Scoping
> http://en.wikipedia.org/wiki/Variable_scoping
>
> Therefore, the example you give above would boil down to these
> assignment statements in a finite state machine (ie: the parser):
>
> media.title = title#1
> media.hcard.title = title#1

This isn't a useful analogy. Microformats are not a programming  
language anymore than HTML is a programming language (though some may  
think it is) [1]. HTML is a document language and, in some ways a  
data source for applications (web applications, if you will).

One of the things that works well in microformats and related  
technologies is that the vocabularies are collapsed into a flat list.  
This means that when you see a term you can know what it means,  
without knowing much more about the context in which is appears.

-ryan


1. http://webdesign.about.com/b/a/255718.htm
From ryan at technorati.com  Wed Jun 13 20:36:30 2007
From: ryan at technorati.com (Ryan King)
Date: Wed Jun 13 20:36:36 2007
Subject: [uf-new] div class for "service links"?
In-Reply-To: <4c5d16c30706122135m388274adt2d4cae2e0e57a6c5@mail.gmail.com>
References: <4c5d16c30706122135m388274adt2d4cae2e0e57a6c5@mail.gmail.com>
Message-ID: <DB4408C0-0964-431D-BBF2-B64E455B417A@technorati.com>

On Jun 12, 2007, at 9:35 PM, D Chudnov wrote:

> Has anybody thought, talked about, or worked on naming those boxes of
> "service links" every site seems to have now?  You know, the ones
> within which you can "save to delicious" and "digg this" and "save to
> facebook" or "look this up in technorati".  There are plugins that add
> these sets of links for all the major blog engines, and all the major
> media outlets seem to support some random subset of the world of
> possible service links, but never just the ones I want.
>
> I want to be able to dynamically mix in the exact services I subscribe
> to whenever I see one of these, and I want institutions like libraries
> to be able to mix in the kinds of stuff they're doing with OpenURL
> right there, too, but it shouldn't take a lot of work.  If, for every
> time anybody publishes one of those "boxes of service links", we could
> at least identify that "this is where the service links go", we could
> make quite a bit of progress toward this goal.

This seems like a use case better addressed with browser add ons with  
the UI in the browser chrome.

And, you could do it without anyone changing their markup. Just  
create a browser extension that looks for every anchor tag with  
rel="bookmark" and gives you a shortcut to bookmark/digg/search that  
URL.

> It could be as easy as "<div class='service-links'>blah blah
> blah</div>".   Or class="serviceable".  Or something more uf-ish like
> "hServices".
>
> Let me know if this sounds interesting, or if I've missed some work on
> something like this.

On the other hand, though I still don't think this would be worthy of  
a microformat, it would be very useful (to me, at least) for someone  
to document the markup patterns with these tools.

-ryan

From daniel.chudnov at gmail.com  Wed Jun 13 22:53:20 2007
From: daniel.chudnov at gmail.com (D Chudnov)
Date: Wed Jun 13 22:53:23 2007
Subject: [uf-new] div class for "service links"?
In-Reply-To: <DB4408C0-0964-431D-BBF2-B64E455B417A@technorati.com>
References: <4c5d16c30706122135m388274adt2d4cae2e0e57a6c5@mail.gmail.com>
	<DB4408C0-0964-431D-BBF2-B64E455B417A@technorati.com>
Message-ID: <4c5d16c30706132253p4d19c87q3d3f28a28e18fe5e@mail.gmail.com>

On 6/13/07, Ryan King <ryan@technorati.com> wrote:
> On Jun 12, 2007, at 9:35 PM, D Chudnov wrote:
> > I want to be able to dynamically mix in the exact services I subscribe
> > to whenever I see one of these, and I want institutions like libraries
> > to be able to mix in the kinds of stuff they're doing with OpenURL
> > right there, too, but it shouldn't take a lot of work.  If, for every
> > time anybody publishes one of those "boxes of service links", we could
> > at least identify that "this is where the service links go", we could
> > make quite a bit of progress toward this goal.
>
> This seems like a use case better addressed with browser add ons with
> the UI in the browser chrome.
>
> And, you could do it without anyone changing their markup. Just
> create a browser extension that looks for every anchor tag with
> rel="bookmark" and gives you a shortcut to bookmark/digg/search that
> URL.

The problem with that is that not every site with sets of service
links on its pages uses rel="bookmark", and that not every site has
the same kinds of links (bookmarks or otherwise), so there isn't any
one standard thing to look for.  They're all just service links,
broadly defined, so imho we'd just need something that says that
explicitly.


> > It could be as easy as "<div class='service-links'>blah blah
> > blah</div>".   Or class="serviceable".  Or something more uf-ish like
> > "hServices".
>
> On the other hand, though I still don't think this would be worthy of
> a microformat, it would be very useful (to me, at least) for someone
> to document the markup patterns with these tools.

This kind of mixed message is very confusing, and, frankly, a bit
insulting.  Either it's interesting enough for people to think it's
worth going through the process, or it's not.  If it's worth going
through the process, then there has to be a chance of a positive
outcome.  Why would anybody go through the trouble of doing the work
if you make it clear up front that you think it's not worthy?

  -Dan
From scott at makedatamakesense.com  Thu Jun 14 06:44:22 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Thu Jun 14 07:25:18 2007
Subject: [uf-new] div class for "service links"?
In-Reply-To: <4c5d16c30706132253p4d19c87q3d3f28a28e18fe5e@mail.gmail.com>
References: <4c5d16c30706122135m388274adt2d4cae2e0e57a6c5@mail.gmail.com>
	<DB4408C0-0964-431D-BBF2-B64E455B417A@technorati.com>
	<4c5d16c30706132253p4d19c87q3d3f28a28e18fe5e@mail.gmail.com>
Message-ID: <EB6CD0AD-5726-433E-9475-F95F52A77930@makedatamakesense.com>

On Jun 13, 2007, at 11:53 PM, D Chudnov wrote:

> They're all just service links,
> broadly defined, so imho we'd just need something that says that
> explicitly.

How do you publish these links on your own site(s)?

>> On the other hand, though I still don't think this would be worthy of
>> a microformat, it would be very useful (to me, at least) for someone
>> to document the markup patterns with these tools.
>
> This kind of mixed message is very confusing, and, frankly, a bit
> insulting.  Either it's interesting enough for people to think it's
> worth going through the process, or it's not.

I think Ryan was suggesting that you're free to use parts of the  
microformats process (and indeed, documenting existing practices is a  
faily obvious step) to push forward standards without any dependence  
on the microformats community.  No one has a monopoly on HTML-based  
standards.  Microformats are a means to an end; it's a mistake to  
treat them as the end.

--
Scott Reynen
MakeDataMakeSense.com


From scott at makedatamakesense.com  Fri Jun 15 08:56:39 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Fri Jun 15 08:56:52 2007
Subject: [uf-new] Fwd: [uf-discuss] Using org in vcard in haudio
References: <C29819C9.4F04%Michael.Smethurst@bbc.co.uk>
Message-ID: <DDCF8E64-B303-42ED-8D7B-68D370A95319@makedatamakesense.com>

I think this belongs on the -new list, so I'm forwarding from -discuss.

--
Scott Reynen
MakeDataMakeSense.com

Begin forwarded message:

> From: Michael Smethurst <Michael.Smethurst@bbc.co.uk>
> Date: June 15, 2007 3:26:17 AM MDT
> To: Microformats Discuss <microformats-discuss@microformats.org>,  
> "For discussion of new microformats." <microformats- 
> new@microformats.org>
> Subject: Re: [uf-discuss] Using org in vcard in haudio
> Reply-To: Microformats Discuss <microformats-discuss@microformats.org>
>
> Hi Scott
>
> I was thinking along the same lines but couldn't decide on the  
> demarcation
> between people and people AS organisations. Is a function of  
> production or
> fame? Would the same rules apply to Tony Blair, Andy Warhol? Is  
> there a
> difference between Mark E Smith the person and Mark E. Smith the  
> ""singer""?
> Or Tony Blair the person and Tony Blair the politician. Anyway, for  
> now I'm
> keeping it simple and leaving out org cos I don't know from the db  
> if it's a
> group or a person... So just fn it is
>
> Anyway,  my first shot at combining hevent and haudio to describe a
> tracklist is in the wild(ish) here:
>
> http://bbc-hackday.dyndns.org:2822/programmes/shaunkeaveny/episodes/ 
> 43n8r
>
> If we can reach some consensus it'll be rolling out across all the  
> bbc music
> radio and tv programme pages soon(ish). That's a /lot/ of pages so  
> any help
> in getting it right would be much appreciated
>
> KNOWN ISSUES
>
> - each track played is both an event and audio. Because hevent uses  
> summmary
> for it's title and haudio uses fn there's some duplication
>
> - because each event ( a programme segment) doesn't  have a url but  
> the
> contributor / contact hcard does both operator and tails parse out  
> this url
> as the url of the event (see also
> http://microformats.org/discuss/mail/microformats-discuss/2007-June/ 
> 009789.h
> tml)
>
> - the way contributors are added in haudio seems to differ from how  
> contacts
> are added in hevent. In hevent the hcard can live on the same  
> element as
> contact; the haudio examples seem to suggest that the hcard lives  
> on a child
> element of contributor. This might make the layout of a tracklist  
> in a table
> difficult if the track has 2 contributors (performer + composer)
>
> - music brainz links. Both the bbc and another newer more 2.0 radio  
> service
> are committed to making music resources (artists, releases, tracks)
> addressable thru urls using musicbrainz ids. But we don't want  
> these to be
> our public facing canonical urls. We also don't wanna expose links to
> musicbrainz to users in tracklists (cos they'd get confused). So  
> I've added
> empty links to musicbrainz artists (where available). These are  
> definitely
> designed for machines first and humans not at all - apologies - I / 
> know/
> it's bad
>
> Anyway, help, tips, corrections, clarifications, rants all appreciated
>
> Thanks
> michael
>
>
>
> On 14/6/07 23:28, "Scott Reynen" <scott@randomchaos.com> wrote:
>
>> I'm cross-posting this to the -new list, as it might also be relevant
>> to the hAudio work happening on -new.
>>
>> On Jun 14, 2007, at 10:48 AM, Michael Smethurst wrote:
>>
>>>
>>> What should you do if you don't have the data to
>>> determine whether a "contact" is a group or an individual?
>>
>> I think it depends on the context.  If it's just a generic contact
>> that you know nothing about, I'd say just use fn, as adding org is
>> potentially incorrect information.  But if you know it's a music act,
>> I think it makes sense to consider even an individual performer's
>> name to be an organization name in that context.  I'd say there's a
>> difference, for example, between Norah Jones the person, who would be
>> <span class="fn">Norah Jones</span>, and Norah Jones the musical act,
>> which would be <span class="fn org">Norah Jones</span>.
>>
>> Peace,
>> Scott
>>
>> _______________________________________________
>> microformats-discuss mailing list
>> microformats-discuss@microformats.org
>> http://microformats.org/mailman/listinfo/microformats-discuss
>
>
> http://www.bbc.co.uk/
> This e-mail (and any attachments) is confidential and may contain  
> personal views which are not the views of the BBC unless  
> specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in  
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
> 					
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

From msporny at digitalbazaar.com  Fri Jun 15 13:14:55 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Jun 15 13:15:02 2007
Subject: [uf-new] hAudio final draft
Message-ID: <4672F33F.1050403@digitalbazaar.com>

The final submission of the hAudio draft is on the wiki:

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

Changes:

* Adopted 'audio-title' to specify the title of the recording
* Fixed a typo concerning contributor class
* Fixed all references from 'fn' to 'audio-title'
* Updated mailing list discussion page
* Added "Specification Development Statistics" section

We have successfully integrated haudio with several of our client sites
which will be going live in the next 2-3 weeks. We are also currently
authoring the haudio Operator plugin (which should be compatible with
Firefox 3 when it launches). We are also going to be working on
Wordpress plugins to aid hAudio in becoming adopted more rapidly in the
blogging community.

As of this point, all major concerns have been addressed. Please review
and send feedback to the list - if there is no feedback that changes the
draft significantly, this will be the last proposed version for this
round of the hAudio discussion.

As always, many thanks to the list and everybody involved in drafting
haudio. Hopefully, due to the rigor of the process, this format will
meet the basic needs of bloggers and website operators.

-- manu
From andy at pigsonthewing.org.uk  Fri Jun 15 13:58:28 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Fri Jun 15 14:00:01 2007
Subject: [uf-new] hAudio final draft
In-Reply-To: <4672F33F.1050403@digitalbazaar.com>
References: <4672F33F.1050403@digitalbazaar.com>
Message-ID: <pE4gYKS01vcGFwWq@pigsonthewing.org.uk>

In message <4672F33F.1050403@digitalbazaar.com>, Manu Sporny 
<msporny@digitalbazaar.com> writes

>We have successfully integrated haudio with several of our client sites 
>which will be going live in the next 2-3 weeks.

How are you using the currency proposal?

-- 
Andy Mabbett
From davidjanes at blogmatrix.com  Fri Jun 15 14:02:12 2007
From: davidjanes at blogmatrix.com (David Janes)
Date: Fri Jun 15 14:02:15 2007
Subject: [uf-new] hAudio final draft
In-Reply-To: <4672F33F.1050403@digitalbazaar.com>
References: <4672F33F.1050403@digitalbazaar.com>
Message-ID: <21e523c20706151402g4357c74cye7a79157f4780916@mail.gmail.com>

On 6/15/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> The final submission of the hAudio draft is on the wiki:
>
> http://microformats.org/wiki/audio-info-proposal
>
> Changes:
>
> * Adopted 'audio-title' to specify the title of the recording
> * Fixed a typo concerning contributor class
> * Fixed all references from 'fn' to 'audio-title'
> * Updated mailing list discussion page
> * Added "Specification Development Statistics" section
>
> We have successfully integrated haudio with several of our client sites
> which will be going live in the next 2-3 weeks. We are also currently
> authoring the haudio Operator plugin (which should be compatible with
> Firefox 3 when it launches). We are also going to be working on
> Wordpress plugins to aid hAudio in becoming adopted more rapidly in the
> blogging community.
>
> As of this point, all major concerns have been addressed. Please review
> and send feedback to the list - if there is no feedback that changes the
> draft significantly, this will be the last proposed version for this
> round of the hAudio discussion.

(1)
Sorry to bring up this sore point, but why "audio-title" over "fn"? I
did see your feedback a couple of days ago about the concepts of
"audio-title" being different from "track-title", etc (I can't
remember the exact terms, but you get the point). However, it seems to
me that "fn" could be used to represent each of these _concepts_, as
the "fn" will be appropriately nested within identifying containers.

(2)
A little voice in my head says this is more general than audio...

Regards, etc...

-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
From martin at weborganics.co.uk  Fri Jun 15 14:27:12 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Jun 15 14:27:16 2007
Subject: [uf-new] hAudio final draft
In-Reply-To: <pE4gYKS01vcGFwWq@pigsonthewing.org.uk>
References: <4672F33F.1050403@digitalbazaar.com>
	<pE4gYKS01vcGFwWq@pigsonthewing.org.uk>
Message-ID: <1181942832.31737.1.camel@localhost.localdomain>

On Fri, 2007-06-15 at 21:58 +0100, Andy Mabbett wrote:
> In message <4672F33F.1050403@digitalbazaar.com>, Manu Sporny 
> <msporny@digitalbazaar.com> writes
> 
> >We have successfully integrated haudio with several of our client sites 
> >which will be going live in the next 2-3 weeks.
> 
> How are you using the currency proposal?
> 

<span class="money">
  Price: <abbr class="currency" title="USD">&#36;</abbr> 
  <span class="amount">4.99</span>
</span>

I would hope ;)

-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/20070615/463af40c/smime.bin
From martin at weborganics.co.uk  Fri Jun 15 14:32:40 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Jun 15 14:32:43 2007
Subject: [uf-new] hAudio final draft
In-Reply-To: <4672F33F.1050403@digitalbazaar.com>
References: <4672F33F.1050403@digitalbazaar.com>
Message-ID: <1181943160.31737.4.camel@localhost.localdomain>

On Fri, 2007-06-15 at 16:14 -0400, Manu Sporny wrote:
> The final submission of the hAudio draft is on the wiki:
> 
> http://microformats.org/wiki/audio-info-proposal
> 
> Changes:
> 
> * Adopted 'audio-title' to specify the title of the recording
> * Fixed a typo concerning contributor class
> * Fixed all references from 'fn' to 'audio-title'
> * Updated mailing list discussion page
> * Added "Specification Development Statistics" section
> 
> We have successfully integrated haudio with several of our client sites
> which will be going live in the next 2-3 weeks. We are also currently
> authoring the haudio Operator plugin (which should be compatible with
> Firefox 3 when it launches). We are also going to be working on
> Wordpress plugins to aid hAudio in becoming adopted more rapidly in the
> blogging community.
> 
> As of this point, all major concerns have been addressed. Please review
> and send feedback to the list - if there is no feedback that changes the
> draft significantly, this will be the last proposed version for this
> round of the hAudio discussion.
> 
> As always, many thanks to the list and everybody involved in drafting
> haudio. Hopefully, due to the rigor of the process, this format will
> meet the basic needs of bloggers and website operators.
> 
> -- manu

hAudio 0.6

hatom/haudio here http://weborganics.co.uk/haudio

microformat mashup and here http://weborganics.co.uk/podcast/


have fun

-Martin-
> _______________________________________________
> 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/20070615/d69cd236/smime.bin
From martin at weborganics.co.uk  Fri Jun 15 15:09:59 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Jun 15 15:10:05 2007
Subject: [uf-new] hAudio final draft
In-Reply-To: <21e523c20706151402g4357c74cye7a79157f4780916@mail.gmail.com>
References: <4672F33F.1050403@digitalbazaar.com>
	<21e523c20706151402g4357c74cye7a79157f4780916@mail.gmail.com>
Message-ID: <1181945399.32165.5.camel@localhost.localdomain>

On Fri, 2007-06-15 at 16:02 -0500, David Janes wrote:
> On 6/15/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> > The final submission of the hAudio draft is on the wiki:
> >
> > http://microformats.org/wiki/audio-info-proposal
> >
> > Changes:
> >
> > * Adopted 'audio-title' to specify the title of the recording
> > * Fixed a typo concerning contributor class
> > * Fixed all references from 'fn' to 'audio-title'
> > * Updated mailing list discussion page
> > * Added "Specification Development Statistics" section
> >
> > We have successfully integrated haudio with several of our client sites
> > which will be going live in the next 2-3 weeks. We are also currently
> > authoring the haudio Operator plugin (which should be compatible with
> > Firefox 3 when it launches). We are also going to be working on
> > Wordpress plugins to aid hAudio in becoming adopted more rapidly in the
> > blogging community.
> >
> > As of this point, all major concerns have been addressed. Please review
> > and send feedback to the list - if there is no feedback that changes the
> > draft significantly, this will be the last proposed version for this
> > round of the hAudio discussion.
> 
> (1)
> Sorry to bring up this sore point, but why "audio-title" over "fn"? I
> did see your feedback a couple of days ago about the concepts of
> "audio-title" being different from "track-title", etc (I can't
> remember the exact terms, but you get the point). However, it seems to
> me that "fn" could be used to represent each of these _concepts_, as
> the "fn" will be appropriately nested within identifying containers.

we never did get to the bottom of this it was just left hanging!

> 
> (2)
> A little voice in my head says this is more general than audio...
> 

my little voice tells me baaad things but I guess its not a subject of
this list...

> Regards, etc...
> 
-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/20070615/93f31c8f/smime.bin
From martin at weborganics.co.uk  Fri Jun 15 15:21:42 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Jun 15 15:21:49 2007
Subject: [uf-new] hAudio final draft
In-Reply-To: <1181945399.32165.5.camel@localhost.localdomain>
References: <4672F33F.1050403@digitalbazaar.com>
	<21e523c20706151402g4357c74cye7a79157f4780916@mail.gmail.com>
	<1181945399.32165.5.camel@localhost.localdomain>
Message-ID: <1181946102.32165.14.camel@localhost.localdomain>

On Fri, 2007-06-15 at 23:10 +0100, Martin McEvoy wrote:
> On Fri, 2007-06-15 at 16:02 -0500, David Janes wrote:
> > On 6/15/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> > > The final submission of the hAudio draft is on the wiki:
> > >
> > > http://microformats.org/wiki/audio-info-proposal
> > >
> > > Changes:
> > >
> > > * Adopted 'audio-title' to specify the title of the recording
> > > * Fixed a typo concerning contributor class
> > > * Fixed all references from 'fn' to 'audio-title'
> > > * Updated mailing list discussion page
> > > * Added "Specification Development Statistics" section
> > >
> > > We have successfully integrated haudio with several of our client sites
> > > which will be going live in the next 2-3 weeks. We are also currently
> > > authoring the haudio Operator plugin (which should be compatible with
> > > Firefox 3 when it launches). We are also going to be working on
> > > Wordpress plugins to aid hAudio in becoming adopted more rapidly in the
> > > blogging community.
> > >
> > > As of this point, all major concerns have been addressed. Please review
> > > and send feedback to the list - if there is no feedback that changes the
> > > draft significantly, this will be the last proposed version for this
> > > round of the hAudio discussion.
> > 
> > (1)
> > Sorry to bring up this sore point, but why "audio-title" over "fn"? I
> > did see your feedback a couple of days ago about the concepts of
> > "audio-title" being different from "track-title", etc (I can't
> > remember the exact terms, but you get the point). However, it seems to
> > me that "fn" could be used to represent each of these _concepts_, as
> > the "fn" will be appropriately nested within identifying containers.
> 
> we never did get to the bottom of this it was just left hanging!
> 
> > 
> > (2)
> > A little voice in my head says this is more general than audio...
> > 
> 
> my little voice tells me baaad things but I guess its not a subject of
> this list...

...ok then it is

do you think that the title of an audio file is always the same as the
actual file itself?

or that audio-title refers to both a download-able file or an album
title, 

Im having difficulty again understanding how this is different than
either "fn" or "summary" or "whatever"

-martin-
> 
> > Regards, etc...
> > 
> -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/20070615/c077be97/smime.bin
From joe at andrieu.net  Fri Jun 15 15:46:30 2007
From: joe at andrieu.net (Joe Andrieu)
Date: Fri Jun 15 15:46:27 2007
Subject: [uf-new] hAudio final draft
In-Reply-To: <1181946102.32165.14.camel@localhost.localdomain>
Message-ID: <004901c7af9f$052a7d40$22fa030a@andrieuhome>

> Of Martin McEvoy wrote:
> On Fri, 2007-06-15 at 23:10 +0100, Martin McEvoy wrote:
> > On Fri, 2007-06-15 at 16:02 -0500, David Janes wrote:
> > > On 6/15/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> > > > * Adopted 'audio-title' to specify the title of the recording
> > > 
> > > Sorry to bring up this sore point, but why "audio-title" 
> over "fn"? 
> > > I did see your feedback a couple of days ago about the 
> concepts of 
> > > "audio-title" being different from "track-title", etc (I can't 
> > > remember the exact terms, but you get the point). 
> However, it seems 
> > > to me that "fn" could be used to represent each of these 
> _concepts_, 
> > > as the "fn" will be appropriately nested within identifying 
> > > containers.
> > 
> > we never did get to the bottom of this it was just left hanging!

As I understand it that problem is that "fn" for the hAudio would be unable to be differentiated from the "fn" for the hCard of a
contributor of the hAudio.

uF has no scoping.  See this email:
http://microformats.org/discuss/mail/microformats-new/2007-June/000555.html

As I understand it, if we had:
<div class="haudio">
   <span class="contributor">
      <span class="vcard">
         <span class="fn org">Phish</span>
      </span>
   </span>
   <span class="fn">Sneaking Sally Thru The Alley</span>
   <br/>
</div>

The two "fn" fields would clobber each other.

This is a pretty harsh limit on uF, one that I personally think should/could go away by allowing uF containing other uF to know that
the contained uF should be excluded from parsing by the parent.

However, in the above example, I believe we have a problem if the order is reversed and the hCard includes the hAudio, because hCard
is already defined and has no exclusionary principles.

This issue is worth tackling, but solving it before we finish hAudio would bring hAudio to a screeching halt for an indeterminate
period of time.


> > > (2)
> > > A little voice in my head says this is more general than audio...
> > > 
> > 
> > my little voice tells me baaad things but I guess its not a 
> subject of 
> > this list...
> 
> ...ok then it is
> 
> do you think that the title of an audio file is always the 
> same as the actual file itself?


The title is not the name of the file. Audio-info does nothing with regard to the mediafile/audiofile that may or may not be
associated with the audio except for, potentially, pointing to the file as "rel-enclosure".

> or that audio-title refers to both a download-able file or an 
> album title, 

???

This I don't understand. "audio-title" refers to the name/title or the audio piece referred to by the uF.  If that piece is an
/entire/ album, then that's what it is.  Albums that are groupings of multiple individual audio pieces are out of scope (for the
moment). The title of the piece has nothing to do with the filename that might be used.
 
> Im having difficulty again understanding how this is 
> different than either "fn" or "summary" or "whatever"

Martin, I don't know how to reply except to ask you to re-read the thread.  

"fn" is arguably inaccurate and clobbers "fn" from hCard.
"summary" is inaccurate for many audio pieces and clobbers "summary" from hReview.
"whatever" is semantically meaningless.

"audio-title" is specific, accurate, and has no clobber issues with any existing uF.

-j


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


From martin at weborganics.co.uk  Fri Jun 15 18:57:40 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Jun 15 18:57:35 2007
Subject: [uf-new] hAudio final draft
In-Reply-To: <004901c7af9f$052a7d40$22fa030a@andrieuhome>
References: <004901c7af9f$052a7d40$22fa030a@andrieuhome>
Message-ID: <1181959060.5927.74.camel@localhost.localdomain>

Hello Joe

On Fri, 2007-06-15 at 15:46 -0700, Joe Andrieu wrote:
> > Of Martin McEvoy wrote:
> > On Fri, 2007-06-15 at 23:10 +0100, Martin McEvoy wrote:
> > > On Fri, 2007-06-15 at 16:02 -0500, David Janes wrote:
> > > > On 6/15/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> > > > > * Adopted 'audio-title' to specify the title of the recording
> > > > 
> > > > Sorry to bring up this sore point, but why "audio-title" 
> > over "fn"? 
> > > > I did see your feedback a couple of days ago about the 
> > concepts of 
> > > > "audio-title" being different from "track-title", etc (I can't 
> > > > remember the exact terms, but you get the point). 
> > However, it seems 
> > > > to me that "fn" could be used to represent each of these 
> > _concepts_, 
> > > > as the "fn" will be appropriately nested within identifying 
> > > > containers.
> > > 
> > > we never did get to the bottom of this it was just left hanging!
> 
> As I understand it that problem is that "fn" for the hAudio would be unable to be differentiated from the "fn" for the hCard of a
> contributor of the hAudio.
> 
> uF has no scoping.  See this email:
> http://microformats.org/discuss/mail/microformats-new/2007-June/000555.html
> 
> As I understand it, if we had:
> <div class="haudio">
>    <span class="contributor">
>       <span class="vcard">
>          <span class="fn org">Phish</span>
>       </span>
>    </span>
>    <span class="fn">Sneaking Sally Thru The Alley</span>
>    <br/>
> </div>
> 
> The two "fn" fields would clobber each other.

yes I Know this...
> 
> This is a pretty harsh limit on uF, one that I personally think should/could go away by allowing uF containing other uF to know that
> the contained uF should be excluded from parsing by the parent.
> 
> However, in the above example, I believe we have a problem if the order is reversed and the hCard includes the hAudio, because hCard
> is already defined and has no exclusionary principles.
> 
> This issue is worth tackling, but solving it before we finish hAudio would bring hAudio to a screeching halt for an indeterminate
> period of time.
> 
> 
> > > > (2)
> > > > A little voice in my head says this is more general than audio...
> > > > 
> > > 
> > > my little voice tells me baaad things but I guess its not a 
> > subject of 
> > > this list...
> > 
> > ...ok then it is
> > 
> > do you think that the title of an audio file is always the 
> > same as the actual file itself?
> 
> 
> The title is not the name of the file. Audio-info does nothing with regard to the mediafile/audiofile that may or may not be
> associated with the audio except for, potentially, pointing to the file as "rel-enclosure".

hmm there is me getting it all wrong again I thought hAudio was about
the metadata associated with the file?

> 
> > or that audio-title refers to both a download-able file or an 
> > album title, 
> 
> ???
> 
> This I don't understand. "audio-title" refers to the name/title or the audio piece referred to by the uF.  If that piece is an
> /entire/ album, then that's what it is.  Albums that are groupings of multiple individual audio pieces are out of scope (for the
> moment). The title of the piece has nothing to do with the filename that might be used.

my argument is that audio-title refers to two or more separate
instances, It refers to a collection/album title witch may be a number
of tracks or none, and a single track title:

haudio audio-title album Title
haudio audio-title track title 1
haudio audio-title track title 2
haudio audio-title track title 3
 

> > Im having difficulty again understanding how this is 
> > different than either "fn" or "summary" or "whatever"

you may as well use any of the above including "whatever"

> 
> Martin, I don't know how to reply except to ask you to re-read the thread. 

thank you for your advice but #@$?!!.... oops there goes the little
voice in my head again.

ahem I Will 

>  
> 
> "fn" is arguably inaccurate and clobbers "fn" from hCard.
> "summary" is inaccurate for many audio pieces and clobbers "summary" from hReview.
> "whatever" is semantically meaningless.

It would be cool though to have a mF called "whatever" it could be used
in a hArgument or hDiss ..Joke..

my music collection is not something I would describe as "hey guys pop
over to my gaff and listen to a few audio's" or "hey have you got that
new audio by nine inch nails" no its as bad as my summary idea. My music
collection has album's, compilations, Mixes, EP's, Singles, Track's
Song's, Box Sets, multible CD's, CD's mp3's wav's

I even looked at the audio-info/media-info-examples to see how many used
the word "audio" to refer to a track or album title, apart from audio
find,...well I got bored trying to find one... people generally use the
words title album track song

"album-title" is good because people use the word
"track-title" is also good because of the above
"song-title" and you get my drift...

our "audio-title" refers to 1 album, 2 track, 3 song none of which are
the same thing are they?

> 
> "audio-title" is specific, accurate, and has no clobber issues with any existing uF.

I have doubts that it is accurate or not, is... 

audio-album title="[...]"

and

audio-track title="[...]"

...accurate?



Have fun.

-Martin-


> -j
> 
> 
> --
> Joe Andrieu
> SwitchBook Software
> http://www.switchbook.com
> joe@switchbook.com
> +1 (805) 705-8651 
> 
-------------- 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/20070616/e5b581d9/smime.bin
From andy at pigsonthewing.org.uk  Sat Jun 16 02:19:49 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sat Jun 16 02:21:30 2007
Subject: [uf-new] hAudio final draft
In-Reply-To: <4672F33F.1050403@digitalbazaar.com>
References: <4672F33F.1050403@digitalbazaar.com>
Message-ID: <2AInZSW1s6cGFwky@pigsonthewing.org.uk>

In message <4672F33F.1050403@digitalbazaar.com>, Manu Sporny
<msporny@digitalbazaar.com> writes

>The final submission of the hAudio draft is on the wiki:
>
>http://microformats.org/wiki/audio-info-proposal

I realise that this would be a late addition, but what about a "note"
property?

Many of the examples are published with accompanying text, and such
notes might say things like:

   *    "From the album "Dark Side of the Moon"

   *    "Featuring Van Morrison on guest vocals"

   *    "Live version recorded on 4 May 2007"

We already have "note "properties in other microformats, so there's both
precedence and pre-existing syntax .

-- 
Andy Mabbett
From davidjanes at blogmatrix.com  Sat Jun 16 06:35:58 2007
From: davidjanes at blogmatrix.com (David Janes)
Date: Sat Jun 16 06:36:00 2007
Subject: [uf-new] hAudio final draft
In-Reply-To: <004901c7af9f$052a7d40$22fa030a@andrieuhome>
References: <1181946102.32165.14.camel@localhost.localdomain>
	<004901c7af9f$052a7d40$22fa030a@andrieuhome>
Message-ID: <21e523c20706160635v776a1a1fje2bce5050a6fe968@mail.gmail.com>

On 6/15/07, Joe Andrieu <joe@andrieu.net> wrote:
> uF has no scoping.  See this email:
> http://microformats.org/discuss/mail/microformats-new/2007-June/000555.html
>
> As I understand it, if we had:
> <div class="haudio">
>    <span class="contributor">
>       <span class="vcard">
>          <span class="fn org">Phish</span>
>       </span>
>    </span>
>    <span class="fn">Sneaking Sally Thru The Alley</span>
>    <br/>
> </div>
>
> The two "fn" fields would clobber each other.
>
> This is a pretty harsh limit on uF, one that I personally think should/could go away by allowing uF containing other uF to know that
> the contained uF should be excluded from parsing by the parent.

I'm missing something that you're seeing in Ryan's message -- what fn
belongs to depends on the context of the "fn".

The "fn" within the contributor is bound in meaning to "contributor".
The other fn binds to "haudio".

NOTE that I looked in other microformats for this pattern and did not
find it. The closest I came was in hReview, which does this:

hreview
* item
** fn <- the title of the thing being reviewed
* reviewer
** fn <- the name of the reviewer

Perhaps this pattern would work for you?

Regards, etc...
David

-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
From davidjanes at blogmatrix.com  Sat Jun 16 06:37:55 2007
From: davidjanes at blogmatrix.com (David Janes)
Date: Sat Jun 16 06:37:56 2007
Subject: [uf-new] hAudio final draft
In-Reply-To: <1181946102.32165.14.camel@localhost.localdomain>
References: <4672F33F.1050403@digitalbazaar.com>
	<21e523c20706151402g4357c74cye7a79157f4780916@mail.gmail.com>
	<1181945399.32165.5.camel@localhost.localdomain>
	<1181946102.32165.14.camel@localhost.localdomain>
Message-ID: <21e523c20706160637q55199023g16af6e517aa638b6@mail.gmail.com>

On 6/15/07, Martin McEvoy <martin@weborganics.co.uk> wrote:
>
> do you think that the title of an audio file is always the same as the
> actual file itself?
>
> or that audio-title refers to both a download-able file or an album
> title,
>

No and no, but the "Audio Title" concept is not defined to be this [1].

Regards, etc...
David

[1] http://microformats.org/wiki/audio-info-proposal#Audio_Title
-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
From davidjanes at blogmatrix.com  Sat Jun 16 06:39:19 2007
From: davidjanes at blogmatrix.com (David Janes)
Date: Sat Jun 16 06:39:22 2007
Subject: [uf-new] hAudio final draft
In-Reply-To: <21e523c20706160637q55199023g16af6e517aa638b6@mail.gmail.com>
References: <4672F33F.1050403@digitalbazaar.com>
	<21e523c20706151402g4357c74cye7a79157f4780916@mail.gmail.com>
	<1181945399.32165.5.camel@localhost.localdomain>
	<1181946102.32165.14.camel@localhost.localdomain>
	<21e523c20706160637q55199023g16af6e517aa638b6@mail.gmail.com>
Message-ID: <21e523c20706160639x2bdfd414y469f74ee29ec5fbc@mail.gmail.com>

On 6/16/07, David Janes <davidjanes@blogmatrix.com> wrote:
> No and no, but the "Audio Title" concept is not defined to be this [1].

My apologies, by "this" meaning "the track filename"
From martin at weborganics.co.uk  Sat Jun 16 11:39:52 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Jun 16 11:39:46 2007
Subject: [uf-new] hAudio final draft
In-Reply-To: <2AInZSW1s6cGFwky@pigsonthewing.org.uk>
References: <4672F33F.1050403@digitalbazaar.com>
	<2AInZSW1s6cGFwky@pigsonthewing.org.uk>
Message-ID: <1182019192.10883.23.camel@localhost.localdomain>

On Sat, 2007-06-16 at 10:19 +0100, Andy Mabbett wrote:
> In message <4672F33F.1050403@digitalbazaar.com>, Manu Sporny
> <msporny@digitalbazaar.com> writes
> 
> >The final submission of the hAudio draft is on the wiki:
> >
> >http://microformats.org/wiki/audio-info-proposal
> 
> I realise that this would be a late addition, but what about a "note"
> property?
> 
> Many of the examples are published with accompanying text, and such
> notes might say things like:
> 
>    *    "From the album "Dark Side of the Moon"
> 
>    *    "Featuring Van Morrison on guest vocals"
> 
>    *    "Live version recorded on 4 May 2007"
> 
> We already have "note "properties in other microformats, so there's both
> precedence and pre-existing syntax .
> 
I have some data that I collected at the beginning of June that may
support this.

I was trying to find out If hAudio should support "annotation" or
album-summary, audio-summary.

so I looked at all the examples on the
http://microformats.org/wiki/audio-info-examples page to see if I could
determine how many examples had a description associated with albums or
files 

Podcasts 100% of 8 available sources
Individual Publishing of Music 100% 0f 2 available sources
Music Podcasting 80% of 9 available sources
Mashups, remixes, cut-ups and audio-collages 50% of 4 available sources
Service Publishing of Music 54% of 39 available sources.

It looks like podcasting needs an annotation of sorts the rest make what
you will.

two mFs I would recommend we adopt is "note" from hCard or "description"
from xFolk.

-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/20070616/daa4a2da/smime-0001.bin
From msporny at digitalbazaar.com  Sun Jun 17 10:14:12 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Jun 17 10:14:15 2007
Subject: [uf-new] hAudio final draft
In-Reply-To: <pE4gYKS01vcGFwWq@pigsonthewing.org.uk>
References: <4672F33F.1050403@digitalbazaar.com>
	<pE4gYKS01vcGFwWq@pigsonthewing.org.uk>
Message-ID: <46756BE4.5040804@digitalbazaar.com>

Andy Mabbett wrote:
> In message <4672F33F.1050403@digitalbazaar.com>, Manu Sporny
> <msporny@digitalbazaar.com> writes
> 
>> We have successfully integrated haudio with several of our client
>> sites which will be going live in the next 2-3 weeks.
> 
> How are you using the currency proposal?

Exactly what Martin said... We're keeping it as simple as possible for now:

<span class="money">
  Price: <abbr class="currency" title="USD">&#36;</abbr>
  <span class="amount">4.99</span>
</span>

-- manu

From msporny at digitalbazaar.com  Sun Jun 17 11:21:30 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Jun 17 11:21:33 2007
Subject: [uf-new] hAudio final draft
In-Reply-To: <21e523c20706160635v776a1a1fje2bce5050a6fe968@mail.gmail.com>
References: <1181946102.32165.14.camel@localhost.localdomain>	<004901c7af9f$052a7d40$22fa030a@andrieuhome>
	<21e523c20706160635v776a1a1fje2bce5050a6fe968@mail.gmail.com>
Message-ID: <46757BAA.7060801@digitalbazaar.com>

David Janes wrote:
>> The two "fn" fields would clobber each other.
>>
>> This is a pretty harsh limit on uF, one that I personally think
>> should/could go away by allowing uF containing other uF to know that
>> the contained uF should be excluded from parsing by the parent.
> 
> I'm missing something that you're seeing in Ryan's message -- what fn
> belongs to depends on the context of the "fn".
> 
> The "fn" within the contributor is bound in meaning to "contributor".
> The other fn binds to "haudio".

David, I was under the same false assumption. Microformats are
scope-less. There is no such thing as scope and binding... the only
thing that matters is the order that the Microformat elements are listed
on the page.

Here's some markup to demonstrate:

haudio
* hreview
** reviewer
*** vcard
**** fn  <---- the reviewer's name is used as the title for haudio
* fn <---- this is ignored by any Microformat-compliant parser

The parser would perform the following steps:

1. haudio detected
2. find elements for haudio
3. find name of audio recording (search for 'fn')
4. 'fn' found in haudio/hreview/reviewer/vcard/fn *OOPS!*
5. hreview detected
6. find elements for hreview
6. reviewer detected
7. find name of reviewer in vcard (search for 'fn')
8. reviewer's name found in vcard/fn
9. superfluous 'fn' detected, ignore 'fn'. *OOPS!*

-- manu
From davidjanes at blogmatrix.com  Sun Jun 17 11:55:59 2007
From: davidjanes at blogmatrix.com (David Janes)
Date: Sun Jun 17 11:56:02 2007
Subject: [uf-new] Microformats parsing, in general (was: hAudio final draft)
Message-ID: <21e523c20706171155n678af65fwab20640d105d7668@mail.gmail.com>

On 6/17/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
>
> David, I was under the same false assumption. Microformats are
> scope-less. There is no such thing as scope and binding... the only
> thing that matters is the order that the Microformat elements are listed
> on the page.
>
> Here's some markup to demonstrate:
>
> haudio
> * hreview
> ** reviewer
> *** vcard
> **** fn  <---- the reviewer's name is used as the title for haudio
> * fn <---- this is ignored by any Microformat-compliant parser
>
> The parser would perform the following steps:
>
> 1. haudio detected
> 2. find elements for haudio
> 3. find name of audio recording (search for 'fn')
> 4. 'fn' found in haudio/hreview/reviewer/vcard/fn *OOPS!*
> 5. hreview detected
> 6. find elements for hreview
> 6. reviewer detected
> 7. find name of reviewer in vcard (search for 'fn')
> 8. reviewer's name found in vcard/fn
> 9. superfluous 'fn' detected, ignore 'fn'. *OOPS!*

Has this been articulated anywhere on the Wiki? For example, it's not
here [1]. I'm not agreeing or disagreeing with this, but I haven't
quite seen this listed so clearly.

Note that this causes a conflict with the microformats naming
principles [2]. That is, let's assume for argument's sake that "fn" is
the best thing to use for Audio Title. Under the rules Manu gives,
"fn" isn't available for use (unless "item" or similar is injected, as
mentioned earlier in this thread)

Regards, etc...

[1] http://microformats.org/wiki/parsing-microformats
[2] http://microformats.org/wiki/naming-principles

-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
From scott at makedatamakesense.com  Sun Jun 17 12:55:15 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sun Jun 17 12:55:23 2007
Subject: [uf-new] Microformats parsing,
	in general (was: hAudio final draft)
In-Reply-To: <21e523c20706171155n678af65fwab20640d105d7668@mail.gmail.com>
References: <21e523c20706171155n678af65fwab20640d105d7668@mail.gmail.com>
Message-ID: <9610F3D3-5473-4BC8-ADAB-023FDE017610@makedatamakesense.com>

On Jun 17, 2007, at 12:55 PM, David Janes wrote:

>> David, I was under the same false assumption. Microformats are
>> scope-less. There is no such thing as scope and binding... the only
>> thing that matters is the order that the Microformat elements are  
>> listed
>> on the page.
>
> Has this been articulated anywhere on the Wiki?

Yes, the lack of a generic scoping mechanism is the problem discussed  
here:

http://microformats.org/wiki/mfo

However, individual microformats do define scoping within their own  
limited context.  For example, while hCalendar doesn't have very  
detailed parsing rules defined, it's clear that parsers must  
distinguish between the url of an attendee and the url of a vevent to  
avoid problems.  Which is fine when the internal microformat (in this  
case hCard) is defined at the time the external microformat (in this  
case hCalendar) is created, but that doesn't work when we're  
developing a new microformat (e.g. hAudio) intended to be embedded in  
existing microformats (e.g. hReview, hAtom).  We can't retroactively  
require parsers of these microformats to understand hAudio as  
hCalendar parsers understand hCard.

> Note that this causes a conflict with the microformats naming
> principles [2]. That is, let's assume for argument's sake that "fn" is
> the best thing to use for Audio Title. Under the rules Manu gives,
> "fn" isn't available for use (unless "item" or similar is injected, as
> mentioned earlier in this thread)

Right, that's the problem.  It's also a problem with older  
microformats.  For example, one can't safely embed hListing in  
hReview, nor vice versa, because both include a "description"  
property, which may be misinterpreted by any parser that doesn't  
understand both microformats.  This inability to embed conflicts with  
the modularity/embeddability principle.  So we're left choosing  
between two microformat principles that don't work well together in  
practice.  We could get them to work together by continuing that MFO  
discussion, but then we'd be conflicting with yet another principle:  
solve a specific problem.  So which principle do we discard here?

--
Scott Reynen
MakeDataMakeSense.com


From tantek at cs.stanford.edu  Mon Jun 18 11:06:43 2007
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Mon Jun 18 11:05:21 2007
Subject: [uf-new] Microformats parsing, in general (was: hAudio final
	draft)
In-Reply-To: <9610F3D3-5473-4BC8-ADAB-023FDE017610@makedatamakesense.com>
Message-ID: <C29B3637.908E2%tantek@cs.stanford.edu>

On 6/17/07 12:55 PM, "Scott Reynen" <scott@makedatamakesense.com> wrote:

> So we're left choosing
> between two microformat principles that don't work well together in
> practice.  We could get them to work together by continuing that MFO
> discussion, but then we'd be conflicting with yet another principle:
> solve a specific problem.  So which principle do we discard here?

This is likely to be precisely why we may need to solve this problem by
continuing the mfo discussion.

If you look at the current known alternatives:

1. require parsers to update whenever new nestable microformats are
introduced, and precisely define rules for handling known/common nesting
cases (to at a minimum avoid wasting time on straw-man arguments).

2. add a new class name to indicate a encapsulation scope (e.g. "mfo") when
embedding
 - = one new class name, only in cases where nesting occurs.

3. replicate/prefix property class names for each microformat e.g. audio-fn
 - = numerous new class names


It is pretty clear that #3 is the worst from a complexity (most new class
names) that would affect the most people (publishers) point of view.  So we
should seek to avoid #3 since that violates the principles the most.


#2 adds some incremental authoring complexity in some cases.


#1 is something that we can probably still do today since both the number of
microformats is small (a good reason to keep the overall number small), and
the number of parser implementations is small and parser implementers are
both involved in the community and able to update their code quite quickly (
cc'ing microformats-dev accordingly).


Therefore it is reasonable IMHO to:

Pursue #1 in the short term until we have solved #2 in the medium term.

Tantek

From brian.suda at gmail.com  Mon Jun 18 14:27:38 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Mon Jun 18 14:27:41 2007
Subject: [uf-new] Microformats parsing,
	in general (was: hAudio final draft)
In-Reply-To: <C29B3637.908E2%tantek@cs.stanford.edu>
References: <9610F3D3-5473-4BC8-ADAB-023FDE017610@makedatamakesense.com>
	<C29B3637.908E2%tantek@cs.stanford.edu>
Message-ID: <21e770780706181427h3ca95a3fi5a4eee885abbd9cf@mail.gmail.com>

On 6/18/07, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> This is likely to be precisely why we may need to solve this problem by
> continuing the mfo discussion.

--- Part of the reason the MSO discussion died is because it didn?t
actually solve anything.

> If you look at the current known alternatives:
>
> 1. require parsers to update whenever new nestable microformats are
> introduced, and precisely define rules for handling known/common nesting
> cases (to at a minimum avoid wasting time on straw-man arguments).

--- i do NOT like this alternative because it makes the assumption
that you WANT the data to be two different things. For instance, if i
have a URL as a child of hCard. Then the common parsing rules might
say, when that hCard is a location of an hCalendar ignore the URL, but
what happens when i WANT that URL to be part of the hCalendar - this
leads to incorrect assumptions. I would rather let the PUBLISHER be as
explicit as they want or not, rather than parsers attempt to
interprent their intents.

> 2. add a new class name to indicate a encapsulation scope (e.g. "mfo") when
> embedding
>  - = one new class name, only in cases where nesting occurs.

--- The problem with MSO is something like the following:

- hCalendar
-- location (MSO)
--- hcard
---- URL

the URL is ignored for the hCalendar, but then the LOCATION is blank
too because MSO says NOT to take any data. So we move the MSO inside
the hCard

- hCalendar
-- location
--- hcard
---- URL (MSO)

Now you get some data for the location, but now URL is ignored for
BOTH hCal and hCard.

>From what i remember MSO didn?t actually solve anything, it just
created more problems. This is why IMHO it was never persued any
further than just a thought.

> 3. replicate/prefix property class names for each microformat e.g. audio-fn
>  - = numerous new class names
>
> It is pretty clear that #3 is the worst from a complexity (most new class
> names) that would affect the most people (publishers) point of view.  So we
> should seek to avoid #3 since that violates the principles the most.

--- each microformat can also defined its parsing rules. For instance,
hAtom only looks for rel-tag NOT inside an hentry. there is no reason
that a media format can?t define that an FN can ONLY be taken when it
is NOT a child of an hCard, but then this limits the way people can
publish.

> #2 adds some incremental authoring complexity in some cases.

--- i am against MSO, it is un-needed, adds complexity and doesn?t
actually solve much. It attempts to add scoping, which has never been
a problem in the past. It also help focus microformats from attempting
boil the oceans.

> #1 is something that we can probably still do today since both the number of
> microformats is small (a good reason to keep the overall number small), and
> the number of parser implementations is small and parser implementers are
> both involved in the community and able to update their code quite quickly (
> cc'ing microformats-dev accordingly).
>
>
> Therefore it is reasonable IMHO to:
>
> Pursue #1 in the short term until we have solved #2 in the medium term.

--- i think this can be fixed without either of these options. If we
spend the time actually examining real data in the wild, i think we
will find that many of these theoretical issues will either disappear,
or we will have some exact examples that we can further explore and
encode the rules in the format itself rather than trying to work with
any of the above options... i am against #2 outright.

#1 doesn?t sit well with me because it causes an exponential code
growth and potential to introduce more and more bugs.

Each format simply represents data, which can be divisible from each
other. If there are hCards on the page, that is simply people data -
no matter what it is nested in - i should be able to extract them
independently of their scope. Introducing constraints i think makes
things more complex, so i think this should be avoided.

-brian

-- 
brian suda
http://suda.co.uk

From tantek at cs.stanford.edu  Mon Jun 18 15:18:53 2007
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Mon Jun 18 16:25:37 2007
Subject: [uf-new] Microformats parsing, in general (was: hAudio final
	draft)
In-Reply-To: <21e770780706181427h3ca95a3fi5a4eee885abbd9cf@mail.gmail.com>
Message-ID: <C29C5285.9097C%tantek@cs.stanford.edu>

(moving largely parsing discussion to microformats-dev, microformats-new
bcc'd)

On 6/18/07 2:27 PM, "Brian Suda" <brian.suda@gmail.com> wrote:

> On 6/18/07, Tantek ?elik <tantek@cs.stanford.edu> wrote:
>> This is likely to be precisely why we may need to solve this problem by
>> continuing the mfo discussion.
> 
> --- Part of the reason the MSO discussion died is because it didn?t
                             MFO


> actually solve anything.

No it helps abstract when to stop looking into a node for property values.
Full stop. Nothing more, nothing less.


>> If you look at the current known alternatives:
>> 
>> 1. require parsers to update whenever new nestable microformats are
>> introduced, and precisely define rules for handling known/common nesting
>> cases (to at a minimum avoid wasting time on straw-man arguments).
> 
> --- i do NOT like this alternative because it makes the assumption
> that you WANT the data to be two different things. For instance, if i
> have a URL as a child of hCard. Then the common parsing rules might
> say, when that hCard is a location of an hCalendar ignore the URL, but
> what happens when i WANT that URL to be part of the hCalendar - this
> leads to incorrect assumptions.

That case "when you want the URL (of the hCard) to be part of the hCalendar"
- I assert is *way* less than 20%.  If you think this is a real issue, let's
start with at least one concrete example you have seen where this is true.


> I would rather let the PUBLISHER be as
> explicit as they want or not, rather than parsers attempt to
> interpret their intents.

I agree with that methodological statement, yet perhaps we are coming to two
different conclusions.


>> 2. add a new class name to indicate a encapsulation scope (e.g. "mfo") when
>> embedding
>>  - = one new class name, only in cases where nesting occurs.
> 
> --- The problem with MSO is something like the following:
                       MFO

> - hCalendar
> -- location (MSO)
> --- hcard
> ---- URL

<snip> 

This is a false strawman example.  MFO is only for root microformat class
names, not for arbitrary properties.

e.g. class="vcard mfo",  NOT class="location mfo".

second example snipped for same false assumption.



> From what i remember MSO didn?t actually solve anything, it just
> created more problems. This is why IMHO it was never persued any
> further than just a thought.

No it wasn't pursued due to lack of time, and lower priority than other
pursuits.


>> 3. replicate/prefix property class names for each microformat e.g. audio-fn
>>  - = numerous new class names
>> 
>> It is pretty clear that #3 is the worst from a complexity (most new class
>> names) that would affect the most people (publishers) point of view.  So we
>> should seek to avoid #3 since that violates the principles the most.
> 
> --- each microformat can also defined its parsing rules. For instance,
> hAtom only looks for rel-tag NOT inside an hentry. there is no reason
> that a media format can?t define that an FN can ONLY be taken when it
> is NOT a child of an hCard, but then this limits the way people can
> publish.

These specific parsing rules are already part of the #1 option I mentioned.


>> #2 adds some incremental authoring complexity in some cases.
> 
> --- i am against MSO, it is un-needed, adds complexity and doesn?t
> actually solve much.

Based on the misspelling and false strawman examples, I think you may be
against something that is not being proposed.


>> #1 is something that we can probably still do today since both the number of
>> microformats is small (a good reason to keep the overall number small), and
>> the number of parser implementations is small and parser implementers are
>> both involved in the community and able to update their code quite quickly (
>> cc'ing microformats-dev accordingly).
>> 
>> 
>> Therefore it is reasonable IMHO to:
>> 
>> Pursue #1 in the short term until we have solved #2 in the medium term.
> 
> --- i think this can be fixed without either of these options. If we
> spend the time actually examining real data in the wild, i think we
> will find that many of these theoretical issues will either disappear,

This is a good approach of course.


> or we will have some exact examples that we can further explore and
> encode the rules in the format itself rather than trying to work with
> any of the above options...

Hence why I prefer pursuing #1 first as well.


> #1 doesn?t sit well with me because it causes an exponential code
> growth and potential to introduce more and more bugs.

Not necessarily.  I don't believe the assertion of required exponential code
growth.  I'm optimistic that patterns that emerge will solve a lot of this.


> Each format simply represents data, which can be divisible from each
> other. If there are hCards on the page, that is simply people data -
> no matter what it is nested in - i should be able to extract them
> independently of their scope.

Agreed.


> Introducing constraints i think makes
> things more complex, so i think this should be avoided.

In general yes we are trying to minimize complexity.

Sometimes it is difficult to avoid adding complexity *somewhere* and thus
the key point in this discussion is where to put necessary added complexity.

Thanks,

Tantek


From scott at makedatamakesense.com  Mon Jun 18 16:50:11 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Mon Jun 18 16:50:28 2007
Subject: [uf-new] Microformats parsing,
	in general (was: hAudio final draft)
In-Reply-To: <21e770780706181427h3ca95a3fi5a4eee885abbd9cf@mail.gmail.com>
References: <9610F3D3-5473-4BC8-ADAB-023FDE017610@makedatamakesense.com>
	<C29B3637.908E2%tantek@cs.stanford.edu>
	<21e770780706181427h3ca95a3fi5a4eee885abbd9cf@mail.gmail.com>
Message-ID: <96F26828-9C64-4441-8873-4C37F8BE117B@makedatamakesense.com>

On Jun 18, 2007, at 3:27 PM, Brian Suda wrote:

> On 6/18/07, Tantek ?elik <tantek@cs.stanford.edu> wrote:
>> This is likely to be precisely why we may need to solve this  
>> problem by
>> continuing the mfo discussion.
>
> --- Part of the reason the MSO discussion died is because it didn?t
> actually solve anything.

I'm not sure what this means.  It seems to solve the problem we've  
been discussing, the inability to publish embedded microformats with  
shared property names and have them parsed as expected.  As a result  
of this, hAudio discussion abandoned any re-use of existing property  
names.  If that's not a problem, then we should change the naming  
principles.

>> If you look at the current known alternatives:
>>
>> 1. require parsers to update whenever new nestable microformats are
>> introduced, and precisely define rules for handling known/common  
>> nesting
>> cases (to at a minimum avoid wasting time on straw-man arguments).
>
> --- i do NOT like this alternative because it makes the assumption
> that you WANT the data to be two different things. For instance, if i
> have a URL as a child of hCard. Then the common parsing rules might
> say, when that hCard is a location of an hCalendar ignore the URL, but
> what happens when i WANT that URL to be part of the hCalendar - this
> leads to incorrect assumptions. I would rather let the PUBLISHER be as
> explicit as they want or not, rather than parsers attempt to
> interprent their intents.

Isn't that exactly what the MFO proposal would do?

>> 2. add a new class name to indicate a encapsulation scope (e.g.  
>> "mfo") when
>> embedding
>>  - = one new class name, only in cases where nesting occurs.
>
> --- The problem with MSO is something like the following:
>
> - hCalendar
> -- location (MSO)
> --- hcard
> ---- URL
>
> the URL is ignored for the hCalendar, but then the LOCATION is blank
> too because MSO says NOT to take any data. So we move the MSO inside
> the hCard
>
> - hCalendar
> -- location
> --- hcard
> ---- URL (MSO)
>
> Now you get some data for the location, but now URL is ignored for
> BOTH hCal and hCard.

You seem to be missing the third option:

- hCalendar
-- location
--- hcard (MFO)
---- URL

Doesn't this do exactly what the publisher intends, prevent hCalendar  
parsers from looking within the hCard, while still allowing hCards  
parsers to look within?

> --- each microformat can also defined its parsing rules. For instance,
> hAtom only looks for rel-tag NOT inside an hentry. there is no reason
> that a media format can?t define that an FN can ONLY be taken when it
> is NOT a child of an hCard, but then this limits the way people can
> publish.

That only works when the included microformat is defined first.  If  
it's defined second, the outer microformat couldn't possibly have  
considered it in its parsing rules (because it didn't exist when they  
were determined).  I don't currently know the answer to this  
question: How can we include a new microformat, say hPet, using FN  
inside hCard without unexpected results with hCard parsers?  Of  
course that's a hypothetical, but without an answer, microformats  
like hPet, intended to be embedded, will NEVER re-use FN.  Which is  
exactly what's happening with hAudio.

> If there are hCards on the page, that is simply people data -
> no matter what it is nested in - i should be able to extract them
> independently of their scope.

And that's fine as long as we make it clear that no one can put  
anything new using class="fn" within hCards.  If they do, those  
hCards will break.  We can't both re-use property names and ignore  
the context of those property names.  My dog's FN is not my FN, and  
if the only way for me to make that clear is to use class="pet-name"  
instead of FN, that's what will happen.

--
Scott Reynen
MakeDataMakeSense.com



From msporny at digitalbazaar.com  Tue Jun 19 07:08:03 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue Jun 19 07:08:06 2007
Subject: [uf-new] Microformats parsing, in general (was: hAudio final
	draft)
In-Reply-To: <96F26828-9C64-4441-8873-4C37F8BE117B@makedatamakesense.com>
References: <9610F3D3-5473-4BC8-ADAB-023FDE017610@makedatamakesense.com>	<C29B3637.908E2%tantek@cs.stanford.edu>	<21e770780706181427h3ca95a3fi5a4eee885abbd9cf@mail.gmail.com>
	<96F26828-9C64-4441-8873-4C37F8BE117B@makedatamakesense.com>
Message-ID: <4677E343.2070902@digitalbazaar.com>

Scott Reynen wrote:
> We can't both re-use property names and ignore the context of
> those property names.  My dog's FN is not my FN, and if the only way for
> me to make that clear is to use class="pet-name" instead of FN, that's
> what will happen.

This is the heart of the problem.

The Microformats community has adopted two mutually exclusive philosophies:

1. Scope-less approach to parsing.
2. Requirement to heavily re-use class names.

The problem with combining these two philosophies is that they work
against each other. If there is no scope when you are parsing, your uF
class names are going to start conflicting with one another. The result
is that we end up being forced to not re-use class names because of the
scoping philosophy.

Case in point: hAudio.

If we were going the re-use route, we should have re-used 'title',
'summary', or 'description'. Instead, we chose to create a new class
name - 'audio-title'.

hAlbum is up next. What are we going to call the title of the album?
'audio-title'? We do know that hAudio is meant to be used for the
tracks... and that's going to cause a problem. Let's not talk about
theoretical, here's a real-world example of the problem:

http://www.bitmunk.com/view/media/6011107

In the page listed above, a track is listed before the album. The way
the uF markup would have to work is that 'halbum' would be listed first,
followed immediately by the haudio definition.

Therefore, if we use 'audio-title' for the title of the album, and
'audio-title' for the title of the track, we're going to have a problem.

halbum
   track
      haudio
         audio-title    Holiday
         collaborator
            hcard
               fn       Slick Fifty Seven
         rel-sample     Sample
         rel-purchase   PeerBuy
         rel-purchase   WebBuy
         published-date 2003-09-16
         category       Punk
         duration       4:39
         price
            money
               currency $
               amount   0.65
   audio-title          The Ghost Of Bonnie Parker **OOPS!***
      collaborator
         hcard
            fn          Slick Fifty Seven

Using MFO could fix this problem, although I believe that MFO is a hack.
If we think that getting people to understand scoping is a problem -
just wait until we need to explain why MFO exists. Try explaining MFO
without getting into details about the parsers and how Microformats use
a scope-less language design paradigm - these are not light-weight concepts.

MFO is a temporary band-aid for the real problem, which was the adoption
of two mutually exclusive philosophies.

One obvious question at this point is: Why are uFs scope-less?
OR: Why are uFs both scope-less and namespace-less?
OR: Why are uFs scope-less but require heavy re-use of class names?

-- manu
From davidjanes at blogmatrix.com  Tue Jun 19 07:14:41 2007
From: davidjanes at blogmatrix.com (David Janes)
Date: Tue Jun 19 07:14:45 2007
Subject: [uf-new] Microformats parsing,
	in general (was: hAudio final draft)
In-Reply-To: <4677E343.2070902@digitalbazaar.com>
References: <9610F3D3-5473-4BC8-ADAB-023FDE017610@makedatamakesense.com>
	<C29B3637.908E2%tantek@cs.stanford.edu>
	<21e770780706181427h3ca95a3fi5a4eee885abbd9cf@mail.gmail.com>
	<96F26828-9C64-4441-8873-4C37F8BE117B@makedatamakesense.com>
	<4677E343.2070902@digitalbazaar.com>
Message-ID: <21e523c20706190714g1b82cff7kb7efee0e521eee63@mail.gmail.com>

On 6/19/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> This is the heart of the problem.
>
> The Microformats community has adopted two mutually exclusive philosophies:
>
> 1. Scope-less approach to parsing.
> 2. Requirement to heavily re-use class names.

This is why I've been picking at this like a scab for the last week. I
don't think we've adopted #1 at all.

Regards, etc...

-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
From msporny at digitalbazaar.com  Tue Jun 19 08:00:00 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue Jun 19 08:00:09 2007
Subject: [uf-new] Microformats parsing, in general (was: hAudio final
	draft)
In-Reply-To: <21e523c20706190714g1b82cff7kb7efee0e521eee63@mail.gmail.com>
References: <9610F3D3-5473-4BC8-ADAB-023FDE017610@makedatamakesense.com>	<C29B3637.908E2%tantek@cs.stanford.edu>	<21e770780706181427h3ca95a3fi5a4eee885abbd9cf@mail.gmail.com>	<96F26828-9C64-4441-8873-4C37F8BE117B@makedatamakesense.com>	<4677E343.2070902@digitalbazaar.com>
	<21e523c20706190714g1b82cff7kb7efee0e521eee63@mail.gmail.com>
Message-ID: <4677EF70.1070705@digitalbazaar.com>

David Janes wrote:
> On 6/19/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
>> This is the heart of the problem.
>>
>> The Microformats community has adopted two mutually exclusive
>> philosophies:
>>
>> 1. Scope-less approach to parsing.
>> 2. Requirement to heavily re-use class names.
> 
> This is why I've been picking at this like a scab for the last week. I
> don't think we've adopted #1 at all.

Unless I misunderstood him, according to Mike Kaply, author of Operator
and THE guy implementing uFs in Firefox 3, this is exactly how it is
implemented: scope-less.

Brian Suda also confirmed that this is the case in this e-mail to the list:

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

Mind-boggling, isn't it?

We don't have to make Microformats scope-less... but somewhere along the
way, somebody made the decision that scope-less would be the best way to
go if we were to keep the uF concept simple. It sounds good in
principle, but in practice, it seems to be leading to more complexity.

An example of a group that has solved this problem the right way are the
RDFa folks (who have adopted both scope-full parsers and name spaces):

http://www.w3.org/TR/xhtml-rdfa-primer/

-- manu

From tantek at cs.stanford.edu  Tue Jun 19 10:46:53 2007
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Tue Jun 19 10:48:42 2007
Subject: [uf-new] Microformats parsing, in general (was: hAudio final
	draft)
In-Reply-To: <21e523c20706190714g1b82cff7kb7efee0e521eee63@mail.gmail.com>
Message-ID: <C29D6431.90A24%tantek@cs.stanford.edu>

moving *parsing* discussion to microformats-dev, microformats-new bcc'd.

please see http://microformats.org/wiki/mailing-lists for which topics are
better for which lists.


On 6/19/07 7:14 AM, "David Janes" <davidjanes@blogmatrix.com> wrote:

> On 6/19/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
>> This is the heart of the problem.
>> 
>> The Microformats community has adopted two mutually exclusive philosophies:
>> 
>> 1. Scope-less approach to parsing.
> 
> This is why I've been picking at this like a scab for the last week. I
> don't think we've adopted #1 at all.

"scope-less" is a mischaracterization and false.

For example, root class names have always been used to indicate the root of
a compound microformat. e.g. see: http://microformats.org/wiki/hcard-parsing

Tantek

From scott at makedatamakesense.com  Tue Jun 19 08:42:23 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Tue Jun 19 14:25:52 2007
Subject: [uf-new] Microformats parsing,
	in general (was: hAudio final draft)
In-Reply-To: <21e523c20706190714g1b82cff7kb7efee0e521eee63@mail.gmail.com>
References: <9610F3D3-5473-4BC8-ADAB-023FDE017610@makedatamakesense.com>
	<C29B3637.908E2%tantek@cs.stanford.edu>
	<21e770780706181427h3ca95a3fi5a4eee885abbd9cf@mail.gmail.com>
	<96F26828-9C64-4441-8873-4C37F8BE117B@makedatamakesense.com>
	<4677E343.2070902@digitalbazaar.com>
	<21e523c20706190714g1b82cff7kb7efee0e521eee63@mail.gmail.com>
Message-ID: <EF89DD3E-32D6-4948-A568-3DCBE0A7D003@makedatamakesense.com>

On Jun 19, 2007, at 8:14 AM, David Janes wrote:

>> 1. Scope-less approach to parsing.
>> 2. Requirement to heavily re-use class names.
>
> This is why I've been picking at this like a scab for the last week. I
> don't think we've adopted #1 at all.

I'm publishing a website with events marked up in hCalendar.  Each  
event has attendees, marked up in hCard.  The attendees have URLs,  
but the event does not.  How do I limit the scope of an hCard URL to  
the contact (and not the event)?  Here's a real world example of this  
problem:

http://playinghere.com/2007/07/21/LA/New_Orleans/The_Parish/

As far as I can tell, the current answer is that I can't do that, and  
it's not a big deal because the contact URL is somewhat relevant to  
the event.  But as a publisher, I don't like that  I can neither  
control nor predict how my events will be parsed.

--
Scott Reynen
MakeDataMakeSense.com


From martin at weborganics.co.uk  Wed Jun 20 13:11:49 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Wed Jun 20 13:11:46 2007
Subject: [uf-new] Microformats parsing, in general (was: hAudio final
	draft)
In-Reply-To: <4677E343.2070902@digitalbazaar.com>
References: <9610F3D3-5473-4BC8-ADAB-023FDE017610@makedatamakesense.com>
	<C29B3637.908E2%tantek@cs.stanford.edu>
	<21e770780706181427h3ca95a3fi5a4eee885abbd9cf@mail.gmail.com>
	<96F26828-9C64-4441-8873-4C37F8BE117B@makedatamakesense.com>
	<4677E343.2070902@digitalbazaar.com>
Message-ID: <1182370309.16942.33.camel@localhost.localdomain>

On Tue, 2007-06-19 at 10:08 -0400, Manu Sporny wrote:
> Scott Reynen wrote:
> > We can't both re-use property names and ignore the context of
> > those property names.  My dog's FN is not my FN, and if the only way for
> > me to make that clear is to use class="pet-name" instead of FN, that's
> > what will happen.
> 
> This is the heart of the problem.
> 
> The Microformats community has adopted two mutually exclusive philosophies:
> 
> 1. Scope-less approach to parsing.
> 2. Requirement to heavily re-use class names.
> 
> The problem with combining these two philosophies is that they work
> against each other. If there is no scope when you are parsing, your uF
> class names are going to start conflicting with one another. The result
> is that we end up being forced to not re-use class names because of the
> scoping philosophy.
> 
> Case in point: hAudio.
> 
> If we were going the re-use route, we should have re-used 'title',
> 'summary', or 'description'. Instead, we chose to create a new class
> name - 'audio-title'.
> 
> hAlbum is up next. What are we going to call the title of the album?
> 'audio-title'? We do know that hAudio is meant to be used for the
> tracks... and that's going to cause a problem. Let's not talk about
> theoretical, here's a real-world example of the problem:
> 
> http://www.bitmunk.com/view/media/6011107
> 
> In the page listed above, a track is listed before the album. The way
> the uF markup would have to work is that 'halbum' would be listed first,
> followed immediately by the haudio definition.
> 
> Therefore, if we use 'audio-title' for the title of the album, and
> 'audio-title' for the title of the track, we're going to have a problem.
> 
> halbum
>    track
>       haudio
>          audio-title    Holiday
>          collaborator
>             hcard
>                fn       Slick Fifty Seven
>          rel-sample     Sample
>          rel-purchase   PeerBuy
>          rel-purchase   WebBuy
>          published-date 2003-09-16
>          category       Punk
>          duration       4:39
>          price
>             money
>                currency $
>                amount   0.65
>    audio-title          The Ghost Of Bonnie Parker **OOPS!***
>       collaborator
>          hcard
>             fn          Slick Fifty Seven

   haudio
        audio-title    Holiday
        collaborator
           hcard
               fn       Slick Fifty Seven
         rel-sample     Sample
         rel-purchase   PeerBuy
         rel-purchase   WebBuy
         published-date 2003-09-16
         category       Punk
         duration       4:39
         price
            money
               currency $
               amount   0.65
  halbum  
      audio-title          The Ghost Of Bonnie Parker
      collaborator
         hcard
             fn          Slick Fifty Seven

would probably be the simple way? no nesting, it lets people publish
haudio and halbum separately.
Is your problem with the collection or album Item appearing last on a
page? If it is I would put it first on the page and sort the visual
issues out with css.

> Using MFO could fix this problem, although I believe that MFO is a hack.
> If we think that getting people to understand scoping is a problem -

It is when you cant use "title" when we mean "title" why Is it that only
hCard can use it when there is way more evidence to support it means
something else also? Way back machine has 85 billion web pages I would
guess that they all have <title></title> in the head. Title is not a
single definition is more of a disambiguation of many meanings.

> just wait until we need to explain why MFO exists. Try explaining MFO
> without getting into details about the parsers and how Microformats use
> a scope-less language design paradigm - these are not light-weight concepts.
> 
> MFO is a temporary band-aid for the real problem, which was the adoption
> of two mutually exclusive philosophies.
> 
> One obvious question at this point is: Why are uFs scope-less?
> OR: Why are uFs both scope-less and namespace-less?
> OR: Why are uFs scope-less but require heavy re-use of class names?
> 
> -- manu

:)

-Martin-
> _______________________________________________
> 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/20070620/07899c12/smime-0001.bin