From fberriman at gmail.com  Mon Oct  1 08:53:32 2007
From: fberriman at gmail.com (Frances Berriman)
Date: Mon Oct  1 08:53:36 2007
Subject: [uf-new] Internet radio and TV
In-Reply-To: <6.2.0.14.2.20070925154427.02df1fc8@pop3>
References: <6.2.0.14.2.20070925154427.02df1fc8@pop3>
Message-ID: <e86992a40710010853o199eb8e8w683a9fa47fee328c@mail.gmail.com>

On 25/09/2007, Chris Newell <chris.newell@rd.bbc.co.uk> wrote:
> I'm interested in exploring how Internet radio and TV stations could be defined semantically.
>
> As hAudio appears targeted at individual recordings and collections of content I'm not sure it would be beneficial to the development process, or to the end-users, to add additional complexity in order to support Internet radio.
>
> Looking at the station listings out there on the web, there doesn't appear to be much difference between the metadata provided for radio and TV stations but there is a lot in common e.g. streams are often available at different bitrates or using different codecs.
>
> Does anyone else have an interest or thoughts in this area?
>
> Chris

It's an interesting concept and worth exploring and I see there's some
stuff up on the wiki about it that you've started.  Might be
worthwhile to see how much can be done with a mixture of the audio
work, hAtom (for syndication) and hCalendar (for scheduling - time of
air if it is time sensitive/limited broadcast)?


-- 
Frances Berriman
http://fberriman.com
From gl at brixlogic.com  Mon Oct  1 09:57:01 2007
From: gl at brixlogic.com (Guillaume Lebleu)
Date: Mon Oct  1 09:57:09 2007
Subject: [uf-new] Currency brainstorming
In-Reply-To: <A8lqGFrPPp$GFwo3@pigsonthewing.org.uk>
References: <615160.30567.qm@web54108.mail.re2.yahoo.com>
	<A8lqGFrPPp$GFwo3@pigsonthewing.org.uk>
Message-ID: <470126DD.7000009@brixlogic.com>

Andy Mabbett wrote:
> To apply a date, we could simply use hCalendar:
>
>     <div class="vevent">
>       <span class="description">
>         <span class="summary">
>           The last Monet painting to be auctioned
>         </span>
>         fetched
>         <abbr class="currency" title="USD95M">$95 million</abbr>
>         in
>         <span class="dtstart>2005</span>
>       </span>
>     </div>
>   
+1

Addresses the problem of historical money amounts without making the 
date a property/subclass of currency/hmoney class.

Guillaume

From chris.newell at rd.bbc.co.uk  Tue Oct  2 01:18:45 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Tue Oct  2 01:18:51 2007
Subject: [uf-new] Internet radio and TV examples
Message-ID: <6.2.0.14.2.20071002091252.03c74eb8@pop3>

I've started a wiki page to collect Internet radio and TV examples: http://microformats.org/wiki/broadcast-examples

Please feel free to contribute more examples if you have them. I will try to raise awareness within the broadcasting industry.

Chris
_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From chris.newell at rd.bbc.co.uk  Tue Oct  2 01:26:54 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Tue Oct  2 01:26:58 2007
Subject: [uf-new] Internet radio and TV
In-Reply-To: <e86992a40710010853o199eb8e8w683a9fa47fee328c@mail.gmail.co
 m>
References: <6.2.0.14.2.20070925154427.02df1fc8@pop3>
	<e86992a40710010853o199eb8e8w683a9fa47fee328c@mail.gmail.com>
Message-ID: <6.2.0.14.2.20071002090751.02e92ce8@pop3>

Frances Berriman wrote:
At 16:53 01/10/2007, you wrote:
>On 25/09/2007, Chris Newell <chris.newell@rd.bbc.co.uk> wrote:
>> I'm interested in exploring how Internet radio and TV stations could be defined semantically.
>>
>> As hAudio appears targeted at individual recordings and collections of content I'm not sure it would be beneficial to the development process, or to the end-users, to add additional complexity in order to support Internet radio.
>>
>> Looking at the station listings out there on the web, there doesn't appear to be much difference between the metadata provided for radio and TV stations but there is a lot in common e.g. streams are often available at different bitrates or using different codecs.
>>
>> Does anyone else have an interest or thoughts in this area?
>>
>> Chris
>
>It's an interesting concept and worth exploring and I see there's some
>stuff up on the wiki about it that you've started.  Might be
>worthwhile to see how much can be done with a mixture of the audio
>work, hAtom (for syndication) and hCalendar (for scheduling - time of
>air if it is time sensitive/limited broadcast)?

Syndication may be more appropriate to hAudio / hVideo as currently proposed but I agree entirely with the latter idea for real-time streams - something similar was proposed during the media-info discussion before it got bogged down due to the broadness of the overall scope.

Chris

_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From chris.newell at rd.bbc.co.uk  Wed Oct  3 01:39:21 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Wed Oct  3 01:39:39 2007
Subject: [uf-new] Internet radio and TV brainstorming
Message-ID: <6.2.0.14.2.20071002164620.02e126f0@pop3>

I've started a brainstorming page for Internet radio and TV: http://microformats.org/wiki/broadcast-brainstorming

Please contribute any ideas you have in this area.

Chris
_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From fberriman at gmail.com  Wed Oct  3 08:28:28 2007
From: fberriman at gmail.com (Frances Berriman)
Date: Wed Oct  3 08:28:33 2007
Subject: [uf-new] Recipe Examples- Any more?
Message-ID: <e86992a40710030828k17fe1cd1t6cb0083159f459d4@mail.gmail.com>

Ben Ward has kindly tidied the recipe-brainstorm[1] page to reflect
recent discussions we've had here.

Would any other interested parties take a look please and give us any feedback.

I think the first thing I'd like to do is query whether we feel the
examples[2] section of the work is complete enough to next discuss
commonalities and some of the proposed properties.

It does look to me like not that many, but I am feeling quite
confident that we're not going to find much more varied examples from
what's there given that our scope is to stick within food recipes
only.

Since I didn't conduct this research though, I'm keen to know other
people's feelings on it.

[1] http://microformats.org/wiki/recipe-brainstorming
[2]http://microformats.org/wiki/recipe-examples
-- 
Frances Berriman
http://fberriman.com
From mike at yarrt.com  Wed Oct  3 11:37:51 2007
From: mike at yarrt.com (Michael Walker)
Date: Wed Oct  3 11:38:12 2007
Subject: [uf-new] I propose a new microformat for poems.
Message-ID: <op.tzmwpdytjyd8jy@mikeslaptop>

Well, this is my first post to this mailing list and I thought i'd start  
by addressing a problem thats been annoying me for a while.

I can't seem to find a microformat for poetry. I often write poems and  
post them to my blog (http://blog.yarrt.com), and I sometimes wonder about  
the best way to code them. Below is the method I have thought of (with one  
of my poems as an example):

[Heading Text Here, possibly a <h1>, <h2>, etc, depending on the context]
<div class="poem">
   <p class="verse">
     Standing by the roadside,<br />
     A tall dark man,<br />
     Wore a long brown coat,<br />
     Stood in the rain.
   </p>
   <p class="verse">
     Explained he had no home,<br />
     Just travelled the country,<br />
     Sleeping on the streets,<br />
     Begging for his food.
   </p>
   <p class="verse">
     "Why is he helping me?",<br />
     "Where am I going?",<br />
     He must have wondered,<br />
     While stepping into the car.
   </p>
   <p class="verse">
     He seemed uneasy,<br />
     Not sure to trust me,<br />
     He had seem too much,<br />
     To trust people blindly.
   </p>
</div>

I would suggest marking it up with the following CSS rule:
div.poem p.verse{
   margin:10px;
}

Possibly with a border around the whole poem, but that is, of course,  
completely up to you.

What do you all think?
-- 
Michael Walker, Webmaster

From supercanadian at gmail.com  Wed Oct  3 11:58:11 2007
From: supercanadian at gmail.com (Charles Iliya Krempeaux)
Date: Wed Oct  3 11:58:16 2007
Subject: [uf-new] I propose a new microformat for poems.
In-Reply-To: <op.tzmwpdytjyd8jy@mikeslaptop>
References: <op.tzmwpdytjyd8jy@mikeslaptop>
Message-ID: <84ce626f0710031158o3896c0c2m696621437a9c7d95@mail.gmail.com>

Hello Michael,

On 10/3/07, Michael Walker <mike@yarrt.com> wrote:
> Well, this is my first post to this mailing list and I thought i'd start
> by addressing a problem thats been annoying me for a while.
>
> I can't seem to find a microformat for poetry. I often write poems and
> post them to my blog (http://blog.yarrt.com), and I sometimes wonder about
> the best way to code them. Below is the method I have thought of (with one
> of my poems as an example):
>

[...]

> What do you all think?

This is an excellent example of POSH.

So... you this may be a case for POSH (Plain Old Semantic HTML),
instead of a Microformat.  Here's more info on POSH...

http://microformats.org/wiki/posh


Having said that... if there are others putting poems on the web
too... then there may be a case to come up with a common POSH format
-- a Microformat.  If that's the case then you may want to look at the
Microformat process...

http://microformats.org/wiki/process


See ya




-- 
    Charles Iliya Krempeaux, B.Sc. <http://ChangeLog.ca/>


                 Vlog Razor... Vlogging News
                    http://vlograzor.com/
From scott at makedatamakesense.com  Wed Oct  3 12:04:34 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Wed Oct  3 12:04:47 2007
Subject: [uf-new] I propose a new microformat for poems.
In-Reply-To: <op.tzmwpdytjyd8jy@mikeslaptop>
References: <op.tzmwpdytjyd8jy@mikeslaptop>
Message-ID: <579F2201-E9BC-4904-8B42-301DD899F5F7@makedatamakesense.com>

On Oct 3, 2007, at 12:37 PM, Michael Walker wrote:

> I can't seem to find a microformat for poetry. I often write poems  
> and post them to my blog (http://blog.yarrt.com), and I sometimes  
> wonder about the best way to code them. Below is the method I have  
> thought of (with one of my poems as an example):

Before we get into brainstorming, do you have some specific use cases  
in mind for such a microformat?  What problem are we tying to solve  
here?  If you haven't already, please read about the microformats  
process:

http://microformats.org/wiki/process

--
Scott Reynen
MakeDataMakeSense.com


From alexandrevandesande at gmail.com  Wed Oct  3 14:59:46 2007
From: alexandrevandesande at gmail.com (Alexandre Van de Sande)
Date: Wed Oct  3 14:59:49 2007
Subject: [uf-new] I propose a new microformat for poems.
In-Reply-To: <579F2201-E9BC-4904-8B42-301DD899F5F7@makedatamakesense.com>
References: <op.tzmwpdytjyd8jy@mikeslaptop>
	<579F2201-E9BC-4904-8B42-301DD899F5F7@makedatamakesense.com>
Message-ID: <8608a69a0710031459o271f4624lb4d75f81e25748b1@mail.gmail.com>

you mean a microformat for sonnets, or for haikus or Odes or Sestinas,
because Poetry is a broad term that defies an objective structure
needed by microformatting. And I agree with previous commenters that
this requires a problem.

On 10/3/07, Scott Reynen <scott@makedatamakesense.com> wrote:
> On Oct 3, 2007, at 12:37 PM, Michael Walker wrote:
>
> > I can't seem to find a microformat for poetry. I often write poems
> > and post them to my blog (http://blog.yarrt.com), and I sometimes
> > wonder about the best way to code them. Below is the method I have
> > thought of (with one of my poems as an example):
>
> Before we get into brainstorming, do you have some specific use cases
> in mind for such a microformat?  What problem are we tying to solve
> here?  If you haven't already, please read about the microformats
> process:
>
> http://microformats.org/wiki/process
>
> --
> Scott Reynen
> MakeDataMakeSense.com
>
>
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
>


-- 
Alexandre Van de Sande
www.wanderingabout.com
rio de janeiro

     ?

From andy at pigsonthewing.org.uk  Wed Oct  3 15:02:50 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Wed Oct  3 15:03:58 2007
Subject: [uf-new] I propose a new microformat for poems.
In-Reply-To: <op.tzmwpdytjyd8jy@mikeslaptop>
References: <op.tzmwpdytjyd8jy@mikeslaptop>
Message-ID: <OIKp7abKGBBHFw$f@pigsonthewing.org.uk>

In message <op.tzmwpdytjyd8jy@mikeslaptop>, Michael Walker
<mike@yarrt.com> writes

>I can't seem to find a microformat for poetry.

What would be the use-case? In other words, what would parsers (browsers
or browser plug-ins; other websites) do with poems marked up that way?

You should also look at the work which has been done on a proposed
"citation" microformat:

        <http://microformats.org/wiki/citation>

since a poem on a website is, effectively, cited.

Then you should compile examples of poems published on the web: what
data is commonly included?

You might find, for example, that most poems published are dated, or
cre4dit the author. But what else?

-- 
Andy Mabbett
From lorenzo.detomasi at gmail.com  Thu Oct  4 00:19:16 2007
From: lorenzo.detomasi at gmail.com (Lorenzo De Tomasi)
Date: Thu Oct  4 00:19:21 2007
Subject: [uf-new] Recipe Examples- Any more?
In-Reply-To: <e86992a40710030828k17fe1cd1t6cb0083159f459d4@mail.gmail.com>
References: <e86992a40710030828k17fe1cd1t6cb0083159f459d4@mail.gmail.com>
Message-ID: <5c2a5c380710040019p314c8b77tffacc4ce2d68a266@mail.gmail.com>

Look at http://www.cooker.net , one of the most advanced recipe
repository of recipes in Italy.
You can ask them, for their experience.
Have a good lunch! :-D

On 10/3/07, Frances Berriman <fberriman@gmail.com> wrote:

> It does look to me like not that many, but I am feeling quite
> confident that we're not going to find much more varied examples from
> what's there given that our scope is to stick within food recipes
> only.

-- 
Lorenzo De Tomasi
Designer multimodale
http://www.ipernico.it
http://www.isotype.org (in costruzione)
From fberriman at gmail.com  Thu Oct  4 01:26:29 2007
From: fberriman at gmail.com (Frances Berriman)
Date: Thu Oct  4 01:26:33 2007
Subject: [uf-new] Recipe Examples- Any more?
In-Reply-To: <5c2a5c380710040019p314c8b77tffacc4ce2d68a266@mail.gmail.com>
References: <e86992a40710030828k17fe1cd1t6cb0083159f459d4@mail.gmail.com>
	<5c2a5c380710040019p314c8b77tffacc4ce2d68a266@mail.gmail.com>
Message-ID: <e86992a40710040126v18dad605h2dd456f45d5153b@mail.gmail.com>

On 04/10/2007, Lorenzo De Tomasi <lorenzo.detomasi@gmail.com> wrote:
> Look at http://www.cooker.net , one of the most advanced recipe
> repository of recipes in Italy.
> You can ask them, for their experience.
> Have a good lunch! :-D

Interesting. My Italian isn't up to much, but I can figure it out.


-- 
Frances Berriman
http://fberriman.com
From andy at pigsonthewing.org.uk  Thu Oct  4 03:04:55 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Thu Oct  4 03:05:06 2007
Subject: [uf-new] I propose a new microformat for poems.
Message-ID: <3860.80.249.57.38.1191492295.squirrel@www.gradwell.com>

I wrote:

>you should compile examples of poems published on the web: what
>data is commonly included?

For example, note the example, marking up Dublin Core metadata about a
poem, at the top of page three of rfc2731:

    <http://www.ietf.org/rfc/rfc2731.txt>

-- 
Andy Mabbett
** via webmail **

From xblazox at gmail.com  Thu Oct  4 05:00:44 2007
From: xblazox at gmail.com (John Blazier)
Date: Thu Oct  4 05:00:54 2007
Subject: [uf-new] unsubscribe
In-Reply-To: <200710032200.l93M0BBS028103@microformats.org>
References: <200710032200.l93M0BBS028103@microformats.org>
Message-ID: <000c01c8067e$32a63b20$2102a8c0@blazo4akn0dki8>



John Blazier

834 Old Waterbury Road

Southbury, CT 06488

 

voice:  203-267-3328  fax:  203-267-3329

               cell:  203-841-9399

 

xblazox@gmail.com


-----Original Message-----
From: microformats-new-bounces@microformats.org
[mailto:microformats-new-bounces@microformats.org] On Behalf Of
microformats-new-request@microformats.org
Sent: Wednesday, October 03, 2007 6:00 PM
To: microformats-new@microformats.org
Subject: microformats-new Digest, Vol 9, Issue 1

Send microformats-new mailing list submissions to
	microformats-new@microformats.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://microformats.org/mailman/listinfo/microformats-new
or, via email, send a message with subject or body 'help' to
	microformats-new-request@microformats.org

You can reach the person managing the list at
	microformats-new-owner@microformats.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of microformats-new digest..."


Today's Topics:

   1. Money (aka Currency) and Measure test cases (Andy Mabbett)
   2. Re: Internet radio and TV (Frances Berriman)
   3. Re: Currency brainstorming (Guillaume Lebleu)
   4. Internet radio and TV examples (Chris Newell)
   5. Re: Internet radio and TV (Chris Newell)
   6. Internet radio and TV brainstorming (Chris Newell)
   7. Recipe Examples- Any more? (Frances Berriman)
   8. I propose a new microformat for poems. (Michael Walker)
   9. Re: I propose a new microformat for poems.
      (Charles Iliya Krempeaux)
  10. Re: I propose a new microformat for poems. (Scott Reynen)
  11. Re: I propose a new microformat for poems.
      (Alexandre Van de Sande)


----------------------------------------------------------------------

Message: 1
Date: Sat, 29 Sep 2007 20:20:18 +0100
From: Andy Mabbett <andy@pigsonthewing.org.uk>
Subject: [uf-new] Money (aka Currency) and Measure test cases
To: Microformats New <microformats-new@microformats.org>
Message-ID: <$pa1zSxyVq$GFwfX@pigsonthewing.org.uk>
Content-Type: text/plain;charset=us-ascii


I have put up some simple test cases for Money and Currency microformats
(using arbitrary class names), based on Taylor Cowan's model or working.

Should anyone like to try a testing them with a parser, please feel free
and comment on the results here. or on the wiki.

I have added some variations of spacing, ordering and capitalisation, so
we can decide whether we need to be strict or generous in what we allow.

        <http://www.westmidlandbirdclub.com/test/money.htm>

        <http://www.westmidlandbirdclub.com/test/measure.htm>

I'll be happy to add alternative examples, if anyone has any.

Enjoy!

-- 
Andy Mabbett


------------------------------

Message: 2
Date: Mon, 1 Oct 2007 16:53:32 +0100
From: "Frances Berriman" <fberriman@gmail.com>
Subject: Re: [uf-new] Internet radio and TV
To: "For discussion of new microformats."
	<microformats-new@microformats.org>
Message-ID:
	<e86992a40710010853o199eb8e8w683a9fa47fee328c@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 25/09/2007, Chris Newell <chris.newell@rd.bbc.co.uk> wrote:
> I'm interested in exploring how Internet radio and TV stations could be
defined semantically.
>
> As hAudio appears targeted at individual recordings and collections of
content I'm not sure it would be beneficial to the development process, or
to the end-users, to add additional complexity in order to support Internet
radio.
>
> Looking at the station listings out there on the web, there doesn't appear
to be much difference between the metadata provided for radio and TV
stations but there is a lot in common e.g. streams are often available at
different bitrates or using different codecs.
>
> Does anyone else have an interest or thoughts in this area?
>
> Chris

It's an interesting concept and worth exploring and I see there's some
stuff up on the wiki about it that you've started.  Might be
worthwhile to see how much can be done with a mixture of the audio
work, hAtom (for syndication) and hCalendar (for scheduling - time of
air if it is time sensitive/limited broadcast)?


-- 
Frances Berriman
http://fberriman.com


------------------------------

Message: 3
Date: Mon, 01 Oct 2007 09:57:01 -0700
From: Guillaume Lebleu <gl@brixlogic.com>
Subject: Re: [uf-new] Currency brainstorming
To: "For discussion of new microformats."
	<microformats-new@microformats.org>
Message-ID: <470126DD.7000009@brixlogic.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Andy Mabbett wrote:
> To apply a date, we could simply use hCalendar:
>
>     <div class="vevent">
>       <span class="description">
>         <span class="summary">
>           The last Monet painting to be auctioned
>         </span>
>         fetched
>         <abbr class="currency" title="USD95M">$95 million</abbr>
>         in
>         <span class="dtstart>2005</span>
>       </span>
>     </div>
>   
+1

Addresses the problem of historical money amounts without making the 
date a property/subclass of currency/hmoney class.

Guillaume



------------------------------

Message: 4
Date: Tue, 02 Oct 2007 09:18:45 +0100
From: Chris Newell <chris.newell@rd.bbc.co.uk>
Subject: [uf-new] Internet radio and TV examples
To: <microformats-new@microformats.org>
Message-ID: <6.2.0.14.2.20071002091252.03c74eb8@pop3>
Content-Type: text/plain; charset="us-ascii"

I've started a wiki page to collect Internet radio and TV examples:
http://microformats.org/wiki/broadcast-examples

Please feel free to contribute more examples if you have them. I will try to
raise awareness within the broadcasting industry.

Chris
_______________________ 
Chris Newell
Lead Technologist 
BBC Research



------------------------------

Message: 5
Date: Tue, 02 Oct 2007 09:26:54 +0100
From: Chris Newell <chris.newell@rd.bbc.co.uk>
Subject: Re: [uf-new] Internet radio and TV
To: "For discussion of new microformats."
	<microformats-new@microformats.org>
Message-ID: <6.2.0.14.2.20071002090751.02e92ce8@pop3>
Content-Type: text/plain; charset="us-ascii"

Frances Berriman wrote:
At 16:53 01/10/2007, you wrote:
>On 25/09/2007, Chris Newell <chris.newell@rd.bbc.co.uk> wrote:
>> I'm interested in exploring how Internet radio and TV stations could be
defined semantically.
>>
>> As hAudio appears targeted at individual recordings and collections of
content I'm not sure it would be beneficial to the development process, or
to the end-users, to add additional complexity in order to support Internet
radio.
>>
>> Looking at the station listings out there on the web, there doesn't
appear to be much difference between the metadata provided for radio and TV
stations but there is a lot in common e.g. streams are often available at
different bitrates or using different codecs.
>>
>> Does anyone else have an interest or thoughts in this area?
>>
>> Chris
>
>It's an interesting concept and worth exploring and I see there's some
>stuff up on the wiki about it that you've started.  Might be
>worthwhile to see how much can be done with a mixture of the audio
>work, hAtom (for syndication) and hCalendar (for scheduling - time of
>air if it is time sensitive/limited broadcast)?

Syndication may be more appropriate to hAudio / hVideo as currently proposed
but I agree entirely with the latter idea for real-time streams - something
similar was proposed during the media-info discussion before it got bogged
down due to the broadness of the overall scope.

Chris

_______________________ 
Chris Newell
Lead Technologist 
BBC Research



------------------------------

Message: 6
Date: Wed, 03 Oct 2007 09:39:21 +0100
From: Chris Newell <chris.newell@rd.bbc.co.uk>
Subject: [uf-new] Internet radio and TV brainstorming
To: <microformats-new@microformats.org>
Message-ID: <6.2.0.14.2.20071002164620.02e126f0@pop3>
Content-Type: text/plain; charset="us-ascii"

I've started a brainstorming page for Internet radio and TV:
http://microformats.org/wiki/broadcast-brainstorming

Please contribute any ideas you have in this area.

Chris
_______________________ 
Chris Newell
Lead Technologist 
BBC Research



------------------------------

Message: 7
Date: Wed, 3 Oct 2007 16:28:28 +0100
From: "Frances Berriman" <fberriman@gmail.com>
Subject: [uf-new] Recipe Examples- Any more?
To: "For discussion of new microformats."
	<microformats-new@microformats.org>
Message-ID:
	<e86992a40710030828k17fe1cd1t6cb0083159f459d4@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Ben Ward has kindly tidied the recipe-brainstorm[1] page to reflect
recent discussions we've had here.

Would any other interested parties take a look please and give us any
feedback.

I think the first thing I'd like to do is query whether we feel the
examples[2] section of the work is complete enough to next discuss
commonalities and some of the proposed properties.

It does look to me like not that many, but I am feeling quite
confident that we're not going to find much more varied examples from
what's there given that our scope is to stick within food recipes
only.

Since I didn't conduct this research though, I'm keen to know other
people's feelings on it.

[1] http://microformats.org/wiki/recipe-brainstorming
[2]http://microformats.org/wiki/recipe-examples
-- 
Frances Berriman
http://fberriman.com


------------------------------

Message: 8
Date: Wed, 03 Oct 2007 19:37:51 +0100
From: "Michael Walker" <mike@yarrt.com>
Subject: [uf-new] I propose a new microformat for poems.
To: "Microformats Mailing List" <microformats-new@microformats.org>
Message-ID: <op.tzmwpdytjyd8jy@mikeslaptop>
Content-Type: text/plain; format=flowed; delsp=yes;
	charset=iso-8859-15

Well, this is my first post to this mailing list and I thought i'd start  
by addressing a problem thats been annoying me for a while.

I can't seem to find a microformat for poetry. I often write poems and  
post them to my blog (http://blog.yarrt.com), and I sometimes wonder about  
the best way to code them. Below is the method I have thought of (with one  
of my poems as an example):

[Heading Text Here, possibly a <h1>, <h2>, etc, depending on the context]
<div class="poem">
   <p class="verse">
     Standing by the roadside,<br />
     A tall dark man,<br />
     Wore a long brown coat,<br />
     Stood in the rain.
   </p>
   <p class="verse">
     Explained he had no home,<br />
     Just travelled the country,<br />
     Sleeping on the streets,<br />
     Begging for his food.
   </p>
   <p class="verse">
     "Why is he helping me?",<br />
     "Where am I going?",<br />
     He must have wondered,<br />
     While stepping into the car.
   </p>
   <p class="verse">
     He seemed uneasy,<br />
     Not sure to trust me,<br />
     He had seem too much,<br />
     To trust people blindly.
   </p>
</div>

I would suggest marking it up with the following CSS rule:
div.poem p.verse{
   margin:10px;
}

Possibly with a border around the whole poem, but that is, of course,  
completely up to you.

What do you all think?
-- 
Michael Walker, Webmaster



------------------------------

Message: 9
Date: Wed, 3 Oct 2007 11:58:11 -0700
From: "Charles Iliya Krempeaux" <supercanadian@gmail.com>
Subject: Re: [uf-new] I propose a new microformat for poems.
To: "For discussion of new microformats."
	<microformats-new@microformats.org>
Message-ID:
	<84ce626f0710031158o3896c0c2m696621437a9c7d95@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hello Michael,

On 10/3/07, Michael Walker <mike@yarrt.com> wrote:
> Well, this is my first post to this mailing list and I thought i'd start
> by addressing a problem thats been annoying me for a while.
>
> I can't seem to find a microformat for poetry. I often write poems and
> post them to my blog (http://blog.yarrt.com), and I sometimes wonder about
> the best way to code them. Below is the method I have thought of (with one
> of my poems as an example):
>

[...]

> What do you all think?

This is an excellent example of POSH.

So... you this may be a case for POSH (Plain Old Semantic HTML),
instead of a Microformat.  Here's more info on POSH...

http://microformats.org/wiki/posh


Having said that... if there are others putting poems on the web
too... then there may be a case to come up with a common POSH format
-- a Microformat.  If that's the case then you may want to look at the
Microformat process...

http://microformats.org/wiki/process


See ya




-- 
    Charles Iliya Krempeaux, B.Sc. <http://ChangeLog.ca/>


                 Vlog Razor... Vlogging News
                    http://vlograzor.com/


------------------------------

Message: 10
Date: Wed, 3 Oct 2007 13:04:34 -0600
From: Scott Reynen <scott@makedatamakesense.com>
Subject: Re: [uf-new] I propose a new microformat for poems.
To: "For discussion of new microformats."
	<microformats-new@microformats.org>
Message-ID:
	<579F2201-E9BC-4904-8B42-301DD899F5F7@makedatamakesense.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On Oct 3, 2007, at 12:37 PM, Michael Walker wrote:

> I can't seem to find a microformat for poetry. I often write poems  
> and post them to my blog (http://blog.yarrt.com), and I sometimes  
> wonder about the best way to code them. Below is the method I have  
> thought of (with one of my poems as an example):

Before we get into brainstorming, do you have some specific use cases  
in mind for such a microformat?  What problem are we tying to solve  
here?  If you haven't already, please read about the microformats  
process:

http://microformats.org/wiki/process

--
Scott Reynen
MakeDataMakeSense.com




------------------------------

Message: 11
Date: Wed, 3 Oct 2007 18:59:46 -0300
From: "Alexandre Van de Sande" <alexandrevandesande@gmail.com>
Subject: Re: [uf-new] I propose a new microformat for poems.
To: "For discussion of new microformats."
	<microformats-new@microformats.org>
Message-ID:
	<8608a69a0710031459o271f4624lb4d75f81e25748b1@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

you mean a microformat for sonnets, or for haikus or Odes or Sestinas,
because Poetry is a broad term that defies an objective structure
needed by microformatting. And I agree with previous commenters that
this requires a problem.

On 10/3/07, Scott Reynen <scott@makedatamakesense.com> wrote:
> On Oct 3, 2007, at 12:37 PM, Michael Walker wrote:
>
> > I can't seem to find a microformat for poetry. I often write poems
> > and post them to my blog (http://blog.yarrt.com), and I sometimes
> > wonder about the best way to code them. Below is the method I have
> > thought of (with one of my poems as an example):
>
> Before we get into brainstorming, do you have some specific use cases
> in mind for such a microformat?  What problem are we tying to solve
> here?  If you haven't already, please read about the microformats
> process:
>
> http://microformats.org/wiki/process
>
> --
> Scott Reynen
> MakeDataMakeSense.com
>
>
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
>


-- 
Alexandre Van de Sande
www.wanderingabout.com
rio de janeiro

     R	



------------------------------

_______________________________________________
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new


End of microformats-new Digest, Vol 9, Issue 1
**********************************************

From andy at pigsonthewing.org.uk  Thu Oct  4 12:29:17 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Thu Oct  4 12:30:50 2007
Subject: [uf-new] Currency brainstorming
In-Reply-To: <A8lqGFrPPp$GFwo3@pigsonthewing.org.uk>
References: <615160.30567.qm@web54108.mail.re2.yahoo.com>
	<A8lqGFrPPp$GFwo3@pigsonthewing.org.uk>
Message-ID: <mkLjgSiN8TBHFwYL@pigsonthewing.org.uk>

In message <A8lqGFrPPp$GFwo3@pigsonthewing.org.uk>, Andy Mabbett
<andy@pigsonthewing.org.uk> writes

>In message <615160.30567.qm@web54108.mail.re2.yahoo.com>, Taylor Cowan
><taylor_cowan@yahoo.com> writes
>
>>Pretending to forget all that we've know up till now about
>>microformats, what if we just wanted a way for web page designers to
>>make their currency amounts unambiguous with respect to currency
>>denomination and amount?
>
>That's certainly what I want; and to be able to include dates).

I've posted a new "money" microformat straw-man on th wiki:

        <http://microformats.org/wiki/currency-brainstorming#Straw_man>

comments and suggested amendments welcome!

-- 
Andy Mabbett
From andy at pigsonthewing.org.uk  Thu Oct  4 12:30:22 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Thu Oct  4 12:32:05 2007
Subject: [uf-new] Measurement brainstorming (was: Measure & currency)
In-Reply-To: <Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>
	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>
	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
Message-ID: <pU7gsqiO9TBHFw74@pigsonthewing.org.uk>

In message <Adq6+6txgp$GFwKO@pigsonthewing.org.uk>, Andy Mabbett
<andy@pigsonthewing.org.uk> writes

>Taylor Cowan's eelgant sugegstion in the Currency discussion:
>
>  <http://microformats.org/discuss/mail/microformats-new/2007-September
>/000915.html>
>
>talkes the form:
>
>        <abbr class="currency" title="USD100">one hundred bucks</abbr>
>
>abbr-accessibility issues notwithstanding, I think we can apply that to
>measurements, also

I've posted a new "measurement" microformat straw-man on th wiki:

        <http://microformats.org/wiki/measure-brainstorming#Straw_man>

comments and suggested amendments welcome!

-- 
Andy Mabbett
From julian at julianstahnke.com  Thu Oct  4 15:58:10 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Thu Oct  4 15:58:15 2007
Subject: [uf-new] hAudio v0.7 released
In-Reply-To: <46FD1623.8000802@digitalbazaar.com>
References: <46FD1623.8000802@digitalbazaar.com>
Message-ID: <6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>

I?d like to point out that the currently proposed spec (http:// 
microformats.org/wiki/audio-info-proposal#Complete_Album_Examplet) of  
nesting an haudio element in a track element to mark up albums is  
incompatible with using tables for the track listings. In a table,  
you only have one element per track that wraps all the information  
(the table row). So both track and haudio would need to be the same  
element.

I don?t know if the current proposed mark-up is the way it is  
(nesting an haudio element inside another element ?track?) to clarify  
the relationship of the elements, or if this is actually the proposed  
solution in a strict sense. If the latter is the case, a lot of the  
sites provided as example mark-up would actually be incompatible with  
the proposed solution as they all use tables and would therefore be  
unable to nest the elements as specified. This would be unacceptable  
because I think a lot of people (as you can see, again, on the sites  
provided as examples) would agree that using a table is a valid way  
of marking up a track listing.

(Of course, one could just put another whole table with the class  
?haudio? *inside* the table row with the class ?track?, but why  
anyone would want to do this is beyond me.

On 28 Sep 2007, at 3:56pm, Manu Sporny wrote:

> An updated version of the hAudio Draft (v0.7) has been placed on the
> wiki. It contains some changes that are contested. The draft was  
> updated
> to give people a complete picture of what is currently being proposed
> for hAudio. Here are the major changes:
>
> * Added 'album'
>   (concept approved, name is disputed)
> * Added 'track'
>   (concept approved, name is disputed)
> * Changed 'audio-title' to 'recording' to bring it in line with the
>   audio type naming convention that is being proposed.
>   (concept approved, name is disputed)
> * Changed 'published-date' to 'published'
>   (concept approved, name approved)
> * Changed 'image-summary' to 'photo'
>   (concept approved, name approved)
> * Added 'podcast'
>   (concept disputed, name disputed)
> * Added 'position'
>   (concept needs analysis, name disputed)
> * Added 'description'
>   (concept needs analysis, name disputed)
>
> The schema changes are here:
>
> http://microformats.org/wiki/audio-info-proposal#Schema
>
> The disputed properties are here:
>
> http://microformats.org/wiki/audio-info-proposal#Disputed_Additions
>
> All of the examples have been updated (examples have not been provided
> for disputed properties):
>
> http://microformats.org/wiki/audio-info-proposal#Examples
>
> Feedback would be appreciated...
>
> -- manu
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new


From msporny at digitalbazaar.com  Thu Oct  4 18:09:09 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Thu Oct  4 18:09:13 2007
Subject: [uf-new] hAudio/table incompatibility (was: hAudio v0.7 released)
In-Reply-To: <6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>
References: <46FD1623.8000802@digitalbazaar.com>
	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>
Message-ID: <47058EB5.602@digitalbazaar.com>

Julian Stahnke wrote:
> I?d like to point out that the currently proposed spec
> (http://microformats.org/wiki/audio-info-proposal#Complete_Album_Examplet)
> of nesting an haudio element in a track element to mark up albums is
> incompatible with using tables for the track listings. In a table, you
> only have one element per track that wraps all the information (the
> table row). So both track and haudio would need to be the same element.

Julian, you are absolutely, 100% correct! Crap! :)

We hadn't considered the limitations of HTML tables, thanks for catching
that rather glaring problem with the new hAudio proposal.

I have a feeling that the following proposed solution is going to ruffle
a few feathers, but it seems to be the simplest way to address the
problem - make the hAudio parser do the heavy lifting.

PROPOSAL:

TRACK and HAUDIO can co-exist in the same CLASS attribute, but they must
be specified in that order. It is the hAudio parsers job to detect the
co-existence of these two properties and act accordingly.

EXAMPLE:

   <table>
    <tr><th>#</th><th>Track</th><th>Length</th></tr>
    <tr class="track haudio">
        <td>1.</td>
        <td class="recording">Sanity</td>
        <td><abbr class="duration" title="P348S">5:48</abbr></td>
    </tr>
    <tr class="track haudio">
        <td>2.</td>
        <td class="recording">Highway To Hell</td>
        <td><abbr class="duration" title="P219S">3:39</abbr></td>
    </tr>
   </table>

The only reason I mention that order is important in the attribute list
is because we might have 'track hvideo' in the future for DVD chapters,
television episodes or other track-like items.

I remember there being opposition to placing properties (TRACK) and
types (HAUDIO) together in the same CLASS attribute, but can't remember
what the logic was behind the argument.

If there is no opposition to this approach, we could adopt it and make
the parser do the hard work. Thoughts?

Below is a more complete, validated XHTML 1.0 document demonstrating the
fix. You can copy and paste it into the following URL to verify that it
is a valid XHTML 1.0 document:

http://validator.w3.org/#validate_by_input

-- manu

----------------------------------------------------------------------

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
   <title>hAudio Table Example</title>
</head>
<body>
<p>This is an example of an hAudio in a table:</p>

<div class="haudio">
   <img class="photo" alt="Live Phish Album Image"
src="images/live_phish_vol_15.jpg" />
   <p>
   <span class="album">Live Phish, Volume 15</span>
   <span class="contributor">
      <span class="vcard">
         <span class="fn org">Phish</span>
      </span>
   </span>
   </p>
   <p>
   Released on:
   <abbr class="published" title="20023110">October 31, 2002</abbr>
   </p>
   <p>
   Acquire:
   <a rel="sample" href="/samples/live_phish_vol_15_sample.mp3">Sample</a>,
   <a rel="enclosure" href="/live/phish_live_phish_vol_15.mp3">Live
Recording</a>,
   <a rel="payment" href="/buy/phish_live_phish_vol_15">Buy High Quality
Track</a>
   </p>
   <p>
   Category: <span class="category">live</span>
   </p>
   <p>
   Duration: <abbr class="duration" title="P8727S">145 minutes, 27
seconds</abbr>
   </p>
   <p>
   Price: <span class="money">
             <abbr class="currency" title="USD">$</abbr>
             <span class="amount">14.99</span>
          </span>
   </p>
   <p>
   Tracks:
   </p>
   <table>
    <tr><th>#</th><th>Track</th><th>Length</th></tr>
    <tr class="track haudio">
        <td>1.</td>
        <td class="recording">Sanity</td>
        <td><abbr class="duration" title="P348S">5:48</abbr></td>
    </tr>
    <tr class="track haudio">
        <td>2.</td>
        <td class="recording">Highway To Hell</td>
        <td><abbr class="duration" title="P219S">3:39</abbr></td>
    </tr>
   </table>
</div>

</body>
</html>

From scott at makedatamakesense.com  Thu Oct  4 18:41:56 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Thu Oct  4 18:42:00 2007
Subject: [uf-new] hAudio/table incompatibility (was: hAudio v0.7 released)
In-Reply-To: <47058EB5.602@digitalbazaar.com>
References: <46FD1623.8000802@digitalbazaar.com>
	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>
	<47058EB5.602@digitalbazaar.com>
Message-ID: <3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>

On Oct 4, 2007, at 7:09 PM, Manu Sporny wrote:

> PROPOSAL:
>
> TRACK and HAUDIO can co-exist in the same CLASS attribute, but they  
> must
> be specified in that order. It is the hAudio parsers job to detect the
> co-existence of these two properties and act accordingly.

[...]

> The only reason I mention that order is important in the attribute  
> list
> is because we might have 'track hvideo' in the future for DVD  
> chapters,
> television episodes or other track-like items.

I'm not sure l understand that reason.  If you're saying that a  
class="track haudio" should carry the same meaning as a  
class="haudio" inside a class="track", I think that's a bad idea.  It  
discards useful HTML container semantics and introduces container  
semantics to the class attribute where none have existed previously.

But I also don't understand why we were ever treating those as  
separate elements.  It seems to me we're not talking about a track  
that *contains* audio, but rather a track that *is* audio.  If that's  
the case, why wouldn't they belong in the same element?  On a similar  
topic, why does the contributor description say "The contents of the  
element must *include* a valid hCard Microformat" rather than "The  
element must *be* a valid hCard Microformat" (emphasis added)?  In  
hCalender [1] we say "ATTENDEE, CONTACT, and ORGANIZER in iCalendar  
may be represented by an hCard in hCalendar."  So we use  
class="organizer hcard" (or class="hcard organizer") because the  
organizer is exactly the same entity as the hcard.  Why should  
contributor work differently?

[1] http://microformats.org/wiki/hcalendar#More_Semantic_Equivalents

--
Scott Reynen
MakeDataMakeSense.com


From msporny at digitalbazaar.com  Thu Oct  4 20:06:35 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Thu Oct  4 20:06:38 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>
	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>
Message-ID: <4705AA3B.2020802@digitalbazaar.com>

Scott Reynen wrote:
>> The only reason I mention that order is important in the attribute list
>> is because we might have 'track hvideo' in the future for DVD chapters,
>> television episodes or other track-like items.
> 
> I'm not sure l understand that reason.  If you're saying that a
> class="track haudio" should carry the same meaning as a class="haudio"
> inside a class="track", I think that's a bad idea.  It discards useful
> HTML container semantics and introduces container semantics to the class
> attribute where none have existed previously.
> 
> But I also don't understand why we were ever treating those as separate
> elements.  It seems to me we're not talking about a track that
> *contains* audio, but rather a track that *is* audio.  If that's the
> case, why wouldn't they belong in the same element?  

Yes, I agree. We are talking about a track that *is* audio. Based on
that suggestion, perhaps we can change the rules for processing TRACK to
be even more publisher-friendly.

PROPOSAL:

TRACK can be either plain text or marked up using HAUDIO.

This approach would make the following markup valid:

<div class="haudio">
...
  <span class="album">Album Title</span>
...
  <span class="track">Song Name</span>
...
</div>

the following would also be valid:

<div class="haudio">
...
   <table>
    <tr><th>#</th><th>Track</th><th>Length</th></tr>
    <tr class="track haudio">
        <td>1.</td>
        <td class="recording">Sanity</td>
        <td><abbr class="duration" title="P348S">5:48</abbr></td>
    </tr>
    <tr class="haudio track">
        <td>2.</td>
        <td class="recording">Highway To Hell</td>
        <td><abbr class="duration" title="P219S">3:39</abbr></td>
    </tr>
   </table>
...
</div>

These issues have been noted in hAudio ISSUE #11 and ISSUE #12:

http://microformats.org/wiki/audio-info-issues#Problem:_TRACK_does_not_work_in_tables

http://microformats.org/wiki/audio-info-issues#Problem:_CONTRIBUTOR_and_TRACK_are_not_publisher_friendly

> On a similar topic,
> why does the contributor description say "The contents of the element
> must *include* a valid hCard Microformat" rather than "The element must
> *be* a valid hCard Microformat" (emphasis added)?  In hCalender [1] we
> say "ATTENDEE, CONTACT, and ORGANIZER in iCalendar may be represented by
> an hCard in hCalendar."  So we use class="organizer hcard" (or
> class="hcard organizer") because the organizer is exactly the same
> entity as the hcard.  Why should contributor work differently?

It shouldn't work differently from hCalendar, and I agree again. We
should bring hAudio more in line with hCalendar. Do the following two
examples work for everybody?

This would be valid:

   <span class="contributor vcard">
         <span class="fn org">Phish</span>
   </span>

and so would this:

   <span class="contributor">Phish</span>

This has been noted in hAudio ISSUE #12:

http://microformats.org/wiki/audio-info-issues#Problem:_CONTRIBUTOR_and_TRACK_are_not_publisher_friendly

-- manu

From julian at julianstahnke.com  Fri Oct  5 01:44:26 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Fri Oct  5 01:44:30 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <4705AA3B.2020802@digitalbazaar.com>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>
	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>
	<4705AA3B.2020802@digitalbazaar.com>
Message-ID: <383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>

> PROPOSAL:
>
> TRACK can be either plain text or marked up using HAUDIO.
>
> This approach would make the following markup valid:
>
> <div class="haudio">
> ...
>   <span class="album">Album Title</span>
> ...
>   <span class="track">Song Name</span>
> ...
> </div>

I love this!

> It shouldn't work differently from hCalendar, and I agree again. We
> should bring hAudio more in line with hCalendar. Do the following two
> examples work for everybody?
>
> This would be valid:
>
>    <span class="contributor vcard">
>          <span class="fn org">Phish</span>
>    </span>
>
> and so would this:
>
>    <span class="contributor">Phish</span>

Again, I think this would be great. Big music sites like Last.fm  
would have no problem to implement all those nested vcard etc. in  
most cases, even though they may sometimes be a bit heavyweight.  
?Regular? people like bloggers who just want to write about music and  
mark it up accordingly would have a hard time understanding all that  
though, I think. (At least that?s my impression talking to people.)  
So this simpler proposal makes perfect sense to me.

One element per property and you just wrap the whole thing in an  
haudio element. That?s easy to explain and still covers the very  
basic information one would want to have. And if you want to have  
more details, you still can. I think that would be cool.

From chris.newell at rd.bbc.co.uk  Fri Oct  5 03:20:49 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Fri Oct  5 03:20:53 2007
Subject: [uf-new] Measurement brainstorming (was: Measure &
  currency)
In-Reply-To: <pU7gsqiO9TBHFw74@pigsonthewing.org.uk>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>
	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>
	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>
Message-ID: <6.2.0.14.2.20071005101709.02e09cd8@pop3>

At 20:30 04/10/2007, you wrote:
I've posted a new "measurement" microformat straw-man on the wiki:

        <http://microformats.org/wiki/measure-brainstorming#Straw_man>

comments and suggested amendments welcome!

Andy,

I guess you may have been through this but my first thought is why not separate unit-code and value?

The reasoning being:

- Programmers hate parsing strings (particularly if you have to deal with a number of different formats and field orders) and parsing strings is notorious for causing implementation interoperability problems.

- Users may want to style the unit-code differently from the numerical value and the separation would make this easier.

- Users wouldn't have to remember rules about the format of the string.

Straw man #2 could be:

   <span class="hmeasure">
      <span class="units">[unit-code]</span>
      <span class="value">[number]</span>
   </span>

With the alternative:

   <span class="hmeasure">
      <abbr class="units" title="[unit-code]">[text]</span>
      <abbr class="value" title="[number]">[text]</span>
   </span>

The same thoughts would apply to the recent Currency strawman proposal.

Chris
_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From andy at pigsonthewing.org.uk  Fri Oct  5 04:44:10 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Fri Oct  5 04:44:19 2007
Subject: [uf-new] Measurement brainstorming (was: Measure &  currency)
In-Reply-To: <6.2.0.14.2.20071005101709.02e09cd8@pop3>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>
	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>
	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>
	<6.2.0.14.2.20071005101709.02e09cd8@pop3>
Message-ID: <40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>

On Fri, October 5, 2007 11:20, Chris Newell wrote:

>> a new "measurement" microformat straw-man on the wiki:

>> <http://microformats.org/wiki/measure-brainstorming#Straw_man>

> I guess you may have been through this but my first thought is why not
> separate unit-code and value?

Please read Taylor Cowan's original comments:

<http://microformats.org/discuss/mail/microformats-new/2007-September/000915.html>

> The reasoning being:

> - Programmers hate parsing strings (particularly if you have to deal with
> a number of different formats and field orders) and parsing strings is
> notorious for causing implementation interoperability problems.

Microformats put the burden, where possible, on parsers, not publishers,
in order to make life as easy as possible for publishers.

> - Users may want to style the unit-code differently from the numerical
> value and the separation would make this easier.

They are not prevented from doing so by the current proposal.

> - Users wouldn't have to remember rules about the format of the string.

What rules?

> Straw man #2 could be:
>
>
> <span class="hmeasure">
> <span class="units">[unit-code]</span>
> <span class="value">[number]</span>
> </span>

That's already there, as an option, under "issues".

-- 
Andy Mabbett
** via webmail **

From msporny at digitalbazaar.com  Fri Oct  5 06:52:24 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Oct  5 06:53:39 2007
Subject: [uf-new] Currency brainstorming
In-Reply-To: <mkLjgSiN8TBHFwYL@pigsonthewing.org.uk>
References: <615160.30567.qm@web54108.mail.re2.yahoo.com>	<A8lqGFrPPp$GFwo3@pigsonthewing.org.uk>
	<mkLjgSiN8TBHFwYL@pigsonthewing.org.uk>
Message-ID: <47064198.4030005@digitalbazaar.com>

Andy Mabbett wrote:
> I've posted a new "money" microformat straw-man on th wiki:
> 
>         <http://microformats.org/wiki/currency-brainstorming#Straw_man>
> 
> comments and suggested amendments welcome!

Andy, I really like the new hmoney proposal. There is only one issue
that I can see:

The example uses the following markup:

<abbr class="currency" title="USD95M">$95 million</abbr>

however, the following markup possibilities are proposed:

    * [currency-code][number]
    * [currency-code][space][number]
    * [number][currency-code]
    * [number]space[currency-code]

This causes a problem with the above example when using the
[number][currency-code] markup. Take the example of Macedonian Dollars
(MKD) and the Kyat (MMK). If we wanted to mark up 50 million Macedonian
Dollars, we would do the following:

<abbr class="currency" title="95MMKD">95 million</abbr>

However, is this 95 MMK? or is it 95 million MKD? You could make the
parser a bit smarter and attempt to divine what the publisher meant, but
why are we allowing this markup in the first place?

This is one example of where too many options might confuse
publishers... can't we just use one simple markup that is easy for
publishers to understand:

[number][K|M|B|T][space][ISO-4217-currency-code]

I would also argue that we shouldn't even have K, M, B, or T - the full
number should be used.

-- manu
From chris.newell at rd.bbc.co.uk  Fri Oct  5 06:57:00 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Fri Oct  5 06:57:05 2007
Subject: [uf-new] Measurement brainstorming (was: Measure & 
  currency)
In-Reply-To: <40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>
	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>
	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>
	<6.2.0.14.2.20071005101709.02e09cd8@pop3>
	<40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>
Message-ID: <6.2.0.14.2.20071005130142.02e167d8@pop3>

Andy,
At 12:44 05/10/2007, you wrote:
On Fri, October 5, 2007 11:20, Chris Newell wrote:
>>> a new "measurement" microformat straw-man on the wiki:
>>>
>>> <http://microformats.org/wiki/measure-brainstorming#Straw_man>
>>
>> I guess you may have been through this but my first thought is why not
>> separate unit-code and value?
>
>Please read Taylor Cowan's original comments:
>
><http://microformats.org/discuss/mail/microformats-new/2007-September/000915.html>
>
>> The reasoning being:
>>
>> - Programmers hate parsing strings (particularly if you have to deal with
>> a number of different formats and field orders) and parsing strings is
>> notorious for causing implementation interoperability problems.
>
>Microformats put the burden, where possible, on parsers, not publishers,
>in order to make life as easy as possible for publishers.

Agreed, but this is a balance. If it's hard to parse you'll get buggy implementations.

For "currency" the parsing is not too bad because the unit-code is restricted to ISO currency codes (a fixed set of three letter codes).

However, for "measure" (where the unit-codes encompass all SI permutations etc) parsing the string to separate the value from the unit-code gets more tricky and potentially ambiguous. For example:

   <span class="hmeasure">2m<sup>2</sup></span>

I guess this wouldn't be too bad if we can state that numbers within unit-codes are always in <sup> tags.

>> - Users may want to style the unit-code differently from the numerical
>> value and the separation would make this easier.
>
>They are not prevented from doing so by the current proposal.

I didn't say they were.

>> - Users wouldn't have to remember rules about the format of the string.
>
>What rules?

The Strawman proposal states "where parsers must accept the formats: ....."

Chris
_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From andy at pigsonthewing.org.uk  Fri Oct  5 07:03:30 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Fri Oct  5 07:03:44 2007
Subject: [uf-new] Measurement brainstorming (was: Measure &   currency)
In-Reply-To: <6.2.0.14.2.20071005130142.02e167d8@pop3>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>
	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>
	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>
	<6.2.0.14.2.20071005101709.02e09cd8@pop3>
	<40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005130142.02e167d8@pop3>
Message-ID: <42696.80.249.57.38.1191593010.squirrel@www.gradwell.com>

On Fri, October 5, 2007 14:57, Chris Newell wrote:

>> Microformats put the burden, where possible, on parsers, not
>> publishers, in order to make life as easy as possible for publishers.
>
> Agreed, but this is a balance. If it's hard to parse you'll get buggy
> implementations.

*If*; For some value of "hard to parse".

This process is about making sure that's not the case.

> for "measure" (where the unit-codes encompass all SI
> permutations etc) parsing the string to separate the value from the
> unit-code gets more tricky and potentially ambiguous. For example:
>
> <span class="hmeasure">2m<sup>2</sup></span>

That would be:

<abbr class="hmeasure" title="2m2">2m<sup>2</sup></abbr>

using "m2", or whatever is that standard for representing square-metres.

> I guess this wouldn't be too bad if we can state that numbers within
> unit-codes are always in <sup> tags.

We can't.

>>> - Users may want to style the unit-code differently from the
>>> numerical value and the separation would make this easier.
>>
>> They are not prevented from doing so by the current proposal.
>>
>
> I didn't say they were.

Then your comment appears redundant.

>>> - Users wouldn't have to remember rules about the format of the
>>> string.
>>
>> What rules?
>>
>
> The Strawman proposal states "where parsers must accept the formats:
> ....."

"parsers" not "users".

-- 
Andy Mabbett
** via webmail **

From andy at pigsonthewing.org.uk  Fri Oct  5 07:18:26 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Fri Oct  5 07:18:33 2007
Subject: [uf-new] Currency brainstorming
In-Reply-To: <47064198.4030005@digitalbazaar.com>
References: <615160.30567.qm@web54108.mail.re2.yahoo.com>	<A8lqGFrPPp$GFwo3@pigsonthewing.org.uk>
	<mkLjgSiN8TBHFwYL@pigsonthewing.org.uk>
	<47064198.4030005@digitalbazaar.com>
Message-ID: <51440.80.249.57.38.1191593906.squirrel@www.gradwell.com>

On Fri, October 5, 2007 14:52, Manu Sporny wrote:
> Andy Mabbett wrote:


>> a new "money" microformat straw-man

>> <http://microformats.org/wiki/currency-brainstorming#Straw_man>

> Andy, I really like the new hmoney proposal.

Thank you.

> There is only one issue that I can see:
>
> The example uses the following markup:

> Take the example of Macedonian Dollars
> (MKD) and the Kyat (MMK). If we wanted to mark up 50 million Macedonian
> Dollars, we would do the following:

> <abbr class="currency" title="95MMKD">95 million</abbr>

> However, is this 95 MMK? or is it 95 million MKD?

It's 95 million MKD; the last three characters must be the currency;
because "95 MMK D" isn't valid.

> You could make the
> parser a bit smarter and attempt to divine what the publisher meant, but
> why are we allowing this markup in the first place?

Because people publish amounts like "10USD" in the wild
<http://tinyurl.com/39ztv7>.

> I would also argue that we shouldn't even have K, M, B, or T - the full
> number should be used.

That's a reasonable suggestion - please add it to the "issues" section of
the above wiki page.

-- 
Andy Mabbett
** via webmail **

From chris.newell at rd.bbc.co.uk  Fri Oct  5 07:31:37 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Fri Oct  5 07:31:44 2007
Subject: [uf-new] Measurement brainstorming (was: Measure &  
  currency)
In-Reply-To: <42696.80.249.57.38.1191593010.squirrel@www.gradwell.com>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>
	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>
	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>
	<6.2.0.14.2.20071005101709.02e09cd8@pop3>
	<40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005130142.02e167d8@pop3>
	<42696.80.249.57.38.1191593010.squirrel@www.gradwell.com>
Message-ID: <6.2.0.14.2.20071005151318.02dfc088@pop3>

Andy,
At 15:03 05/10/2007, you wrote:
>On Fri, October 5, 2007 14:57, Chris Newell wrote:
>
>>> Microformats put the burden, where possible, on parsers, not
>>> publishers, in order to make life as easy as possible for publishers.
>>
>> Agreed, but this is a balance. If it's hard to parse you'll get buggy
>> implementations.
>
>*If*; For some value of "hard to parse".
>
>This process is about making sure that's not the case.
>
>> for "measure" (where the unit-codes encompass all SI
>> permutations etc) parsing the string to separate the value from the
>> unit-code gets more tricky and potentially ambiguous. For example:
>>
>> <span class="hmeasure">2m<sup>2</sup></span>
>
>That would be:
>
><abbr class="hmeasure" title="2m2">2m<sup>2</sup></abbr>
>
>using "m2", or whatever is that standard for representing square-metres.

Given that "parsers must accept the formats" includes [unit-code][number] would:

  <span class="hmeasure">m23</span>

represent 23 metres or 3 square-metres?

Chris

_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From chris.newell at rd.bbc.co.uk  Fri Oct  5 07:38:03 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Fri Oct  5 07:38:08 2007
Subject: [uf-new] Currency brainstorming
In-Reply-To: <47064198.4030005@digitalbazaar.com>
References: <615160.30567.qm@web54108.mail.re2.yahoo.com>
	<A8lqGFrPPp$GFwo3@pigsonthewing.org.uk>
	<mkLjgSiN8TBHFwYL@pigsonthewing.org.uk>
	<47064198.4030005@digitalbazaar.com>
Message-ID: <6.2.0.14.2.20071005153143.02df9bb8@pop3>

At 14:52 05/10/2007, you wrote:
>Andy Mabbett wrote:
>> I've posted a new "money" microformat straw-man on th wiki:
>> 
>>         <http://microformats.org/wiki/currency-brainstorming#Straw_man>
>> 
>> comments and suggested amendments welcome!
>
>Andy, I really like the new hmoney proposal. There is only one issue
>that I can see:
>
>The example uses the following markup:
>
><abbr class="currency" title="USD95M">$95 million</abbr>
>
>however, the following markup possibilities are proposed:
>
>    * [currency-code][number]
>    * [currency-code][space][number]
>    * [number][currency-code]
>    * [number]space[currency-code]
>
>This causes a problem with the above example when using the
>[number][currency-code] markup. Take the example of Macedonian Dollars
>(MKD) and the Kyat (MMK). If we wanted to mark up 50 million Macedonian
>Dollars, we would do the following:
>
><abbr class="currency" title="95MMKD">95 million</abbr>
>
>However, is this 95 MMK? or is it 95 million MKD? You could make the
>parser a bit smarter and attempt to divine what the publisher meant, but
>why are we allowing this markup in the first place?
>
>This is one example of where too many options might confuse
>publishers... can't we just use one simple markup that is easy for
>publishers to understand:
>
>[number][K|M|B|T][space][ISO-4217-currency-code]

If we applied a similar restriction to the "measure" strawman proposal e.g.

   [number][space][unit-code]

I would withdraw my concerns about the potential parsing problems.

>I would also argue that we shouldn't even have K, M, B, or T - the full
>number should be used.

Agreed.

Chris

_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From andy at pigsonthewing.org.uk  Fri Oct  5 07:49:12 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Fri Oct  5 07:49:19 2007
Subject: [uf-new] Measurement brainstorming (was: Measure &    currency)
In-Reply-To: <6.2.0.14.2.20071005151318.02dfc088@pop3>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>
	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>
	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>
	<6.2.0.14.2.20071005101709.02e09cd8@pop3>
	<40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005130142.02e167d8@pop3>
	<42696.80.249.57.38.1191593010.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005151318.02dfc088@pop3>
Message-ID: <25109.80.249.57.38.1191595752.squirrel@www.gradwell.com>

On Fri, October 5, 2007 15:31, Chris Newell wrote:

>> That would be:

>> <abbr class="hmeasure" title="2m2">2m<sup>2</sup></abbr>

>> using "m2", or whatever is that standard for representing
>> square-metres.
>
> Given that "parsers must accept the formats" includes [unit-code][number]
> would:

> <span class="hmeasure">m23</span>

> represent 23 metres or 3 square-metres?

Note that I said "or whatever is [the] standard for representing
square-metres".

-- 
Andy Mabbett
** via webmail **

From andy at pigsonthewing.org.uk  Fri Oct  5 07:50:59 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Fri Oct  5 07:51:05 2007
Subject: [uf-new] Currency brainstorming
In-Reply-To: <6.2.0.14.2.20071005153143.02df9bb8@pop3>
References: <615160.30567.qm@web54108.mail.re2.yahoo.com>
	<A8lqGFrPPp$GFwo3@pigsonthewing.org.uk>
	<mkLjgSiN8TBHFwYL@pigsonthewing.org.uk>
	<47064198.4030005@digitalbazaar.com>
	<6.2.0.14.2.20071005153143.02df9bb8@pop3>
Message-ID: <27267.80.249.57.38.1191595859.squirrel@www.gradwell.com>

On Fri, October 5, 2007 15:38, Chris Newell wrote:


> If we applied a similar restriction to the "measure" strawman proposal

There is a separate thread" for discussion of that proposal.

> e.g.
>
> [number][space][unit-code]

> I would withdraw my concerns about the potential parsing problems.

People publish measurements, without spaces, such as "4cm" in the wild.

-- 
Andy Mabbett
** via webmail **

From chris.newell at rd.bbc.co.uk  Fri Oct  5 08:18:20 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Fri Oct  5 08:18:24 2007
Subject: [uf-new] Measurement brainstorming (was: Measure &   currency)
In-Reply-To: <25109.80.249.57.38.1191595752.squirrel@www.gradwell.com>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>
	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>
	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>
	<6.2.0.14.2.20071005101709.02e09cd8@pop3>
	<40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005130142.02e167d8@pop3>
	<42696.80.249.57.38.1191593010.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005151318.02dfc088@pop3>
	<25109.80.249.57.38.1191595752.squirrel@www.gradwell.com>
Message-ID: <6.2.0.14.2.20071005160918.02e07d30@pop3>

Andy,
At 15:49 05/10/2007, you wrote:
>On Fri, October 5, 2007 15:31, Chris Newell wrote:
>
>>> That would be:
>
>>> <abbr class="hmeasure" title="2m2">2m<sup>2</sup></abbr>
>
>>> using "m2", or whatever is that standard for representing
>>> square-metres.
>>
>> Given that "parsers must accept the formats" includes [unit-code][number]
>> would:
>
>> <span class="hmeasure">m23</span>
>
>> represent 23 metres or 3 square-metres?
>
>Note that I said "or whatever is [the] standard for representing
>square-metres".

I'm not sure there is a standard for representing the superscripts used within SI units using plain text.

We may have to specify something.

Chris

_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From msporny at digitalbazaar.com  Fri Oct  5 08:47:09 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Oct  5 08:48:25 2007
Subject: [uf-new] Measurement brainstorming
In-Reply-To: <6.2.0.14.2.20071005160918.02e07d30@pop3>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>	<6.2.0.14.2.20071005101709.02e09cd8@pop3>	<40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>	<6.2.0.14.2.20071005130142.02e167d8@pop3>	<42696.80.249.57.38.1191593010.squirrel@www.gradwell.com>	<6.2.0.14.2.20071005151318.02dfc088@pop3>	<25109.80.249.57.38.1191595752.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005160918.02e07d30@pop3>
Message-ID: <47065C7D.9090303@digitalbazaar.com>

Chris Newell wrote:
>> Note that I said "or whatever is [the] standard for representing
>> square-metres".
> 
> I'm not sure there is a standard for representing the superscripts 
> used within SI units using plain text.
> 
> We may have to specify something.

These are all good discussions, but I'm afraid that the second we get
into "We might have to specify something", we're going to get into
philosophical debates about how we represent prefixes, units and the
combinations thereof... thereby killing the discussion :)

In an attempt to avoid those philosophical debates, let's build on the
work of great people. Namely, the ISO and SI standards of measurement
used by the international community. I have put up Straw Man 2 on the
wiki in an attempt to outline basic markup that hmeasure could support:

http://microformats.org/wiki/measure-brainstorming#Straw_man_2

The Strawman includes the following new concepts:

- The proposal only uses abbr to avoid the "but the parsers are going to
  be so complicated!" argument. Let's focus on what we can represent
  using <abbr> - what we can support in <span> will naturally come out
  of that discussion.
- This is a first cut and is missing things like measurements for
  "cups", "feet", etc.
- SI-prefixes should be used when applicable.
- It attempts to simplify and focus the discussion on <abbr>

-- manu
From chris.newell at rd.bbc.co.uk  Fri Oct  5 09:28:21 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Fri Oct  5 09:28:26 2007
Subject: [uf-new] Measurement brainstorming
In-Reply-To: <47065C7D.9090303@digitalbazaar.com>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>
	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>
	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>
	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>
	<6.2.0.14.2.20071005101709.02e09cd8@pop3>
	<40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005130142.02e167d8@pop3>
	<42696.80.249.57.38.1191593010.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005151318.02dfc088@pop3>
	<25109.80.249.57.38.1191595752.squirrel@www.gradwell.com>
	<6.2.0.14.2.20071005160918.02e07d30@pop3>
	<47065C7D.9090303@digitalbazaar.com>
Message-ID: <6.2.0.14.2.20071005170303.02e2bbf0@pop3>

Andy,
At 16:47 05/10/2007, you wrote:
>I have put up Straw Man 2 on the
>wiki in an attempt to outline basic markup that hmeasure could support:
>
>http://microformats.org/wiki/measure-brainstorming#Straw_man_2
>
>The Strawman includes the following new concepts:
>
>- The proposal only uses abbr to avoid the "but the parsers are going to
>  be so complicated!" argument. Let's focus on what we can represent
>  using <abbr> - what we can support in <span> will naturally come out
>  of that discussion.
>- This is a first cut and is missing things like measurements for
>  "cups", "feet", etc.
>- SI-prefixes should be used when applicable.
>- It attempts to simplify and focus the discussion on <abbr>

Looks good.

We could also reference http://en.wikipedia.org/wiki/SI_derived_unit and http://en.wikipedia.org/wiki/Non-SI_units_accepted_for_use_with_SI which expand the number of units in a controlled way.

Even so, these references don't provide a suitable unit for bit-rate so I'd like to add "bit" as a supported unit, for use with the other entities you've defined e.g. "kbit/s".

Chris

_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From martin at weborganics.co.uk  Fri Oct  5 10:31:37 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Oct  5 10:31:01 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
References: <46FD1623.8000802@digitalbazaar.com>
	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>
	<47058EB5.602@digitalbazaar.com>
	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>
	<4705AA3B.2020802@digitalbazaar.com>
	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
Message-ID: <1191605497.31012.6.camel@localhost.localdomain>

On Fri, 2007-10-05 at 09:44 +0100, Julian Stahnke wrote:
> > PROPOSAL:
> >
> > TRACK can be either plain text or marked up using HAUDIO.
> >
> > This approach would make the following markup valid:
> >
> > <div class="haudio">
> > ...
> >   <span class="album">Album Title</span>
> > ...
> >   <span class="track">Song Name</span>
> > ...
> > </div>
> 
> I love this!

[ ... ]


> 
> > It shouldn't work differently from hCalendar, and I agree again. We
> > should bring hAudio more in line with hCalendar. Do the following two
> > examples work for everybody?
> >
> > This would be valid:
> >
> >    <span class="contributor vcard">
> >          <span class="fn org">Phish</span>
> >    </span>
> >
> > and so would this:
> >
> >    <span class="contributor">Phish</span>
> 
> Again, I think this would be great. Big music sites like Last.fm  
> would have no problem to implement all those nested vcard etc. in  
> most cases, even though they may sometimes be a bit heavyweight.  
> ?Regular? people like bloggers who just want to write about music and  
> mark it up accordingly would have a hard time understanding all that  
> though, I think. (At least that?s my impression talking to people.)  
> So this simpler proposal makes perfect sense to me.

Thank you for your comments Julian at least someone on the list Is
starting to make sense.

I have been wrestling with the current proposal of hAudio since Manu
made his announcement [1] And frankly the current proposal is starting
to make less and less sense to me,  With each different proposal the
concept of hAudio gets more and more vague. and honestly I dont like it
at all the way hAudio stands now.

What happened to keep it Simple,  and *Meaningful*?

So let Keep it simple eh?

PROPOSAL:

<div class="haudio">
   <span class="audio-title">Album Title</span>
   <span class="contributor vcard">[...]Artist[...]</span>
   <div class="track">1
        <span class="track-title">Track One</span>
        [...]
    </div>
    <div class="track">2
         <span class="track-title">Track Two</span>
       [...]
    </div>
</div>

Notice no need to Reiterate hAudio over and over again, hAudio only=20
needs to be declared *ONCE* because the entire contents *ARE* hAudio

Does hAudio really need to be more involved than the above example?

I feel the more we bloat hAudio with *not* well thought of semantic
class names such as *Album* (a container class or object not a title)
and *Podcast* (which is also a container class and not a title) the
less 

Publishers are going to use hAudio because it makes it difficult to
understand and integrate with their webpages.

> 
> One element per property and you just wrap the whole thing in an  
> haudio element. That?s easy to explain and still covers the very  
> basic information one would want to have. And if you want to have  
> more details, you still can. I think that would be cool.

[...]

Thanks

Martin McEvoy
[1]
http://microformats.org/discuss/mail/microformats-new/2007-September/000885.html
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From msporny at digitalbazaar.com  Fri Oct  5 11:34:00 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Oct  5 11:35:19 2007
Subject: [uf-new] Measurement brainstorming
In-Reply-To: <6.2.0.14.2.20071005170303.02e2bbf0@pop3>
References: <e86992a40709280700w3f0a110etee6409cbd74692d4@mail.gmail.com>	<zfQWeoHa3R$GFwt8@pigsonthewing.org.uk>	<Adq6+6txgp$GFwKO@pigsonthewing.org.uk>	<pU7gsqiO9TBHFw74@pigsonthewing.org.uk>	<6.2.0.14.2.20071005101709.02e09cd8@pop3>	<40064.80.249.57.38.1191584650.squirrel@www.gradwell.com>	<6.2.0.14.2.20071005130142.02e167d8@pop3>	<42696.80.249.57.38.1191593010.squirrel@www.gradwell.com>	<6.2.0.14.2.20071005151318.02dfc088@pop3>	<25109.80.249.57.38.1191595752.squirrel@www.gradwell.com>	<6.2.0.14.2.20071005160918.02e07d30@pop3>	<47065C7D.9090303@digitalbazaar.com>
	<6.2.0.14.2.20071005170303.02e2bbf0@pop3>
Message-ID: <47068398.4010805@digitalbazaar.com>

Chris Newell wrote:
>> The Strawman includes the following new concepts:
>>
>> - The proposal only uses abbr to avoid the "but the parsers are going to
>>  be so complicated!" argument. Let's focus on what we can represent
>>  using <abbr> - what we can support in <span> will naturally come out
>>  of that discussion.
>> - This is a first cut and is missing things like measurements for
>>  "cups", "feet", etc.
>> - SI-prefixes should be used when applicable.
>> - It attempts to simplify and focus the discussion on <abbr>
> 
> Looks good.

Chris, just to clarify - those were my suggestions, not Andy's. I don't
know if Andy agrees with this approach or not. If he does, then that's
great... but I don't want to put any words into his mouth. :)

> We could also reference http://en.wikipedia.org/wiki/SI_derived_unit and 
> http://en.wikipedia.org/wiki/Non-SI_units_accepted_for_use_with_SI
> which expand the number of units in a controlled way.

I have included the SI derived units and the Non-SI accepted units.

> Even so, these references don't provide a suitable unit for bit-rate 
> so I'd like to add "bit" as a supported unit, for use with the other
> entities you've defined e.g. "kbit/s".

I have also added 'bit' under "Units Defined by Microformats.org".

Changes can be found here:

http://microformats.org/wiki/measure-brainstorming#Supported_Derived_SI_Units

http://microformats.org/wiki/measure-brainstorming#Supported_Non-SI_Units

http://microformats.org/wiki/measure-brainstorming#Units_Defined_by_Microformats.org

-- manu

From msporny at digitalbazaar.com  Fri Oct  5 13:08:45 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Oct  5 13:10:06 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <1191605497.31012.6.camel@localhost.localdomain>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>	<4705AA3B.2020802@digitalbazaar.com>	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
	<1191605497.31012.6.camel@localhost.localdomain>
Message-ID: <470699CD.3050001@digitalbazaar.com>

Martin McEvoy wrote:
> On Fri, 2007-10-05 at 09:44 +0100, Julian Stahnke wrote:
>> So this simpler proposal makes perfect sense to me.
> 
> at least someone on the list Is starting to make sense.

Criticize the ideas, not the people, please. :)

> I have been wrestling with the current proposal of hAudio since Manu
> made his announcement [1] And frankly the current proposal is starting
> to make less and less sense to me,  With each different proposal the
> concept of hAudio gets more and more vague. and honestly I dont like it
> at all the way hAudio stands now.
> 
> What happened to keep it Simple, and *Meaningful*?

We are attempting to keep it simple... remember, if we don't have ALBUM
and TRACK - we have to have the hAlbum Microformat. hAlbum is an order
of magnitude more complicated than what is currently being proposed.

What part of the mark-up isn't "meaningful" to you? Please be very
explicit as I'm having a hard time following what part of the hAudio
specification you don't like. Preface your statements with "This
concerns hAudio ISSUE #N..."

> So let Keep it simple eh?
> 
> PROPOSAL:
> 
> <div class="haudio">
>    <span class="audio-title">Album Title</span>
>    <span class="contributor vcard">[...]Artist[...]</span>
>    <div class="track">1
>         <span class="track-title">Track One</span>
>         [...]
>     </div>
>     <div class="track">2
>          <span class="track-title">Track Two</span>
>        [...]
>     </div>
> </div>
> 
> Notice no need to Reiterate hAudio over and over again, hAudio only=20
> needs to be declared *ONCE* because the entire contents *ARE* hAudio

Please take a bit more time to outline your objection more clearly.
Which one of the hAudio ISSUES is this about?

http://microformats.org/wiki/audio-info-issues#Problem:_TRACK_does_not_work_in_tables

I'm guessing that you don't like the fact that you must define both
TRACK and HAUDIO?

The reason that we're doing this is because we might want to re-use
TRACK (or whatever we end up calling it) in hVideo.

Content has sections:

Albums have Tracks
Television Series have Episodes
DVDs have Chapters
Books have Chapters

We could end up re-using TRACK to describe DVDs like so:

<div class="hvideo">
...
   <span class="dvd">The Matrix</span>
...
   <span class="track hvideo">Chapter 27: The Lobby</span>
...
   <span class="track haudio">Chinese Audio Track</span>
...
</div>

If we don't specify hvideo for the video track and haudio for the audio
track, how would the parser determine the difference? We would have
ambiguity, which is one of the reasons all of the other Microformats do
this as well.

If you want to push your proposal above, you will have to make the
following arguments:

1. Why Ambiguity is not an issue for TRACK.
2. Why we should introduce a new property called TRACK-TITLE.
3. Why we should require CONTRIBUTOR to be marked up via a VCARD.

> I feel the more we bloat hAudio with *not* well thought of semantic
> class names such as *Album* (a container class or object not a title)

ALBUM is not a container class, it defines two things:

- the name of an audio album
- the type of the hAudio

The examples require us to have something like this, so is your
opposition to it's name... or the concept that we need something to
denote the name and type of an hAudio?

> and *Podcast* (which is also a container class and not a title) the
> less 

PODCAST will probably not make it in unless somebody other than me
starts supporting it.

Let me point out that we have plenty of podcast examples:

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

I'd like hAudio to be completed sooner than later and if PODCAST is
going to cause push-back, then I'd much rather drop it and move on...
even though we have a number of examples to support putting podcast in
hAudio.

-- manu

From martin at weborganics.co.uk  Sat Oct  6 03:49:43 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct  6 03:49:07 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <470699CD.3050001@digitalbazaar.com>
References: <46FD1623.8000802@digitalbazaar.com>
	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>
	<47058EB5.602@digitalbazaar.com>
	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>
	<4705AA3B.2020802@digitalbazaar.com>
	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
	<1191605497.31012.6.camel@localhost.localdomain>
	<470699CD.3050001@digitalbazaar.com>
Message-ID: <1191667783.5782.45.camel@localhost.localdomain>

On Fri, 2007-10-05 at 16:08 -0400, Manu Sporny wrote:
> Martin McEvoy wrote:
> > On Fri, 2007-10-05 at 09:44 +0100, Julian Stahnke wrote:
> >> So this simpler proposal makes perfect sense to me.
> > 
> > at least someone on the list Is starting to make sense.
> 
> Criticize the ideas, not the people, please. :)
> 
> > I have been wrestling with the current proposal of hAudio since Manu
> > made his announcement [1] And frankly the current proposal is starting
> > to make less and less sense to me,  With each different proposal the
> > concept of hAudio gets more and more vague. and honestly I dont like it
> > at all the way hAudio stands now.
> > 
> > What happened to keep it Simple, and *Meaningful*?
> 
> We are attempting to keep it simple... remember, if we don't have ALBUM
> and TRACK - we have to have the hAlbum Microformat. hAlbum is an order
> of magnitude more complicated than what is currently being proposed.
> 
> What part of the mark-up isn't "meaningful" to you? Please be very
> explicit as I'm having a hard time following what part of the hAudio
> specification you don't like. Preface your statements with "This
> concerns hAudio ISSUE #N..."
> 
> > So let Keep it simple eh?
> > 
> > PROPOSAL:
> > 
> > <div class="haudio">
> >    <span class="audio-title">Album Title</span>
> >    <span class="contributor vcard">[...]Artist[...]</span>
> >    <div class="track">1
> >         <span class="track-title">Track One</span>
> >         [...]
> >     </div>
> >     <div class="track">2
> >          <span class="track-title">Track Two</span>
> >        [...]
> >     </div>
> > </div>
> > 
> > Notice no need to Reiterate hAudio over and over again, hAudio only=20
> > needs to be declared *ONCE* because the entire contents *ARE* hAudio
> 
> Please take a bit more time to outline your objection more clearly.
> Which one of the hAudio ISSUES is this about?

all the general hAudio proposal....

> 
> http://microformats.org/wiki/audio-info-issues#Problem:_TRACK_does_not_work_in_tables
> 
> I'm guessing that you don't like the fact that you must define both
> TRACK and HAUDIO?
> 
> The reason that we're doing this is because we might want to re-use
> TRACK (or whatever we end up calling it) in hVideo.
> 
> Content has sections:
> 
> Albums have Tracks
> Television Series have Episodes
> DVDs have Chapters
> Books have Chapters
> 
> We could end up re-using TRACK to describe DVDs like so:
> 
> <div class="hvideo">
> ...
>    <span class="dvd">The Matrix</span>
> ...
>    <span class="track hvideo">Chapter 27: The Lobby</span>
> ...
>    <span class="track haudio">Chinese Audio Track</span>
> ...
> </div>

[?]

> 
> If we don't specify hvideo for the video track and haudio for the audio
> track, how would the parser determine the difference? We would have
> ambiguity, which is one of the reasons all of the other Microformats do
> this as well.
> 
> If you want to push your proposal above, you will have to make the
> following arguments:
> 
> 1. Why Ambiguity is not an issue for TRACK.

It is an ambiguity when you couple it with another instance of hAudio 
, it shouldn't I cause such confusions I don't think. TRACK should be
clearly defined as a child element of hAudio for it to contain hAudio
seems confusing an unnecessary:

haudio 
  track
    haudio

? 
hAudio inside hAudio ?...  

> 2. Why we should introduce a new property called TRACK-TITLE.

You Have proposed 

recording, album, track, podcast,  position and  description

5 new properties ONE reused from hAlbum *Track* the rest !!! 

You decided from the Issues page I Hope?

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

First I notice that you have dropped the audio-title property?

http://microformats.org/wiki/audio-info-issues#audio-title_Property

Only YOU made a vote for changing the current propsal which clearly
means to me that only you had an issue with this?
 +1 : use RECORDING and ALBUM ManuSporny 18:20, 27 Sep 2007 (PDT)

My Proposal Suggests We Keep it I voted Against changing it 
-1 : don't change audio-title Martin McEvoy 15:48, 14 Aug 2007 (GMT)

David Janes voted also on this issue
+1 for using FN, no clear difference between two so why invent another
David Janes 14 August 2007

I would take that as a vote against or changing it entirely

My view would be from the *Three* votes we had that this was really a
*NON ISSUE* but you changed it any way to reflect your views?
 
> 3. Why we should require CONTRIBUTOR to be marked up via a VCARD.

It Doesn't Just a recomendation as per the hAudio Spec.

>   
> > I feel the more we bloat hAudio with *not* well thought of semantic
> > class names such as *Album* (a container class or object not a title)
> 
> ALBUM is not a container class, 

In your view It Isn't..

In my View IT IS
You re used the already discovered meaning of hAlbum I Presume?

http://microformats.org/wiki/audio-album-proposal#hAlbum
http://microformats.org/wiki/audio-album-proposal#Simple_Album_Example


> it defines two things:
> 
> - the name of an audio album
> - the type of the hAudio
> 
> The examples require us to have something like this, so is your
> opposition to it's name... or the concept that we need something to
> denote the name and type of an hAudio?
> 
> > and *Podcast* (which is also a container class and not a title) the
> > less 
> 
> PODCAST will probably not make it in unless somebody other than me
> starts supporting it.
> 
> Let me point out that we have plenty of podcast examples:
> 
> http://microformats.org/wiki/audio-info-examples#Music_Podcasting
> 
> I'd like hAudio to be completed sooner than later and if PODCAST is
> going to cause push-back, then I'd much rather drop it and move on...
> even though we have a number of examples to support putting podcast in
> hAudio.

I propose You change the hAudio Proposal back to the 0.6 version UNTILL
these ISSUES have been resolved YOU cant Just change the proposal to
reflect your personal views..

Manu you didnt even notify the list that you were making these changes
untill AFTER the changes were made.

Frankly I resent the way you are seeming to bully this community into
fiting into hAudio RDFa agenda 

http://wiki.digitalbazaar.com/en/HAudio_RDFa

which you have said yourself is more useful than the Microformat
Proposal

http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Oct/0017.html

Thanks

Martin
> 
> -- manu
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From martin at weborganics.co.uk  Sat Oct  6 04:31:12 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct  6 04:30:35 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <1191667783.5782.45.camel@localhost.localdomain>
References: <46FD1623.8000802@digitalbazaar.com>
	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>
	<47058EB5.602@digitalbazaar.com>
	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>
	<4705AA3B.2020802@digitalbazaar.com>
	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
	<1191605497.31012.6.camel@localhost.localdomain>
	<470699CD.3050001@digitalbazaar.com>
	<1191667783.5782.45.camel@localhost.localdomain>
Message-ID: <1191670272.5782.48.camel@localhost.localdomain>

On Sat, 2007-10-06 at 11:49 +0100, Martin McEvoy wrote:
> On Fri, 2007-10-05 at 16:08 -0400, Manu Sporny wrote:
> > Martin McEvoy wrote:
> > > On Fri, 2007-10-05 at 09:44 +0100, Julian Stahnke wrote:
> > >> So this simpler proposal makes perfect sense to me.
> > > 
> > > at least someone on the list Is starting to make sense.

Oh And thanks for Quoting me out of context..

http://microformats.org/discuss/mail/microformats-new/2007-October/000958.html

> > 
> > Criticize the ideas, not the people, please. :)
> > 
> > > I have been wrestling with the current proposal of hAudio since Manu
> > > made his announcement [1] And frankly the current proposal is starting
> > > to make less and less sense to me,  With each different proposal the
> > > concept of hAudio gets more and more vague. and honestly I dont like it
> > > at all the way hAudio stands now.
> > > 
> > > What happened to keep it Simple, and *Meaningful*?
> > 
> > We are attempting to keep it simple... remember, if we don't have ALBUM
> > and TRACK - we have to have the hAlbum Microformat. hAlbum is an order
> > of magnitude more complicated than what is currently being proposed.
> > 
> > What part of the mark-up isn't "meaningful" to you? Please be very
> > explicit as I'm having a hard time following what part of the hAudio
> > specification you don't like. Preface your statements with "This
> > concerns hAudio ISSUE #N..."
> > 
> > > So let Keep it simple eh?
> > > 
> > > PROPOSAL:
> > > 
> > > <div class="haudio">
> > >    <span class="audio-title">Album Title</span>
> > >    <span class="contributor vcard">[...]Artist[...]</span>
> > >    <div class="track">1
> > >         <span class="track-title">Track One</span>
> > >         [...]
> > >     </div>
> > >     <div class="track">2
> > >          <span class="track-title">Track Two</span>
> > >        [...]
> > >     </div>
> > > </div>
> > > 
> > > Notice no need to Reiterate hAudio over and over again, hAudio only=20
> > > needs to be declared *ONCE* because the entire contents *ARE* hAudio
> > 
> > Please take a bit more time to outline your objection more clearly.
> > Which one of the hAudio ISSUES is this about?
> 
> all the general hAudio proposal....
> 
> > 
> > http://microformats.org/wiki/audio-info-issues#Problem:_TRACK_does_not_work_in_tables
> > 
> > I'm guessing that you don't like the fact that you must define both
> > TRACK and HAUDIO?
> > 
> > The reason that we're doing this is because we might want to re-use
> > TRACK (or whatever we end up calling it) in hVideo.
> > 
> > Content has sections:
> > 
> > Albums have Tracks
> > Television Series have Episodes
> > DVDs have Chapters
> > Books have Chapters
> > 
> > We could end up re-using TRACK to describe DVDs like so:
> > 
> > <div class="hvideo">
> > ...
> >    <span class="dvd">The Matrix</span>
> > ...
> >    <span class="track hvideo">Chapter 27: The Lobby</span>
> > ...
> >    <span class="track haudio">Chinese Audio Track</span>
> > ...
> > </div>
> 
> [?]
> 
> > 
> > If we don't specify hvideo for the video track and haudio for the audio
> > track, how would the parser determine the difference? We would have
> > ambiguity, which is one of the reasons all of the other Microformats do
> > this as well.
> > 
> > If you want to push your proposal above, you will have to make the
> > following arguments:
> > 
> > 1. Why Ambiguity is not an issue for TRACK.
> 
> It is an ambiguity when you couple it with another instance of hAudio 
> , it shouldn't I cause such confusions I don't think. TRACK should be
> clearly defined as a child element of hAudio for it to contain hAudio
> seems confusing an unnecessary:
> 
> haudio 
>   track
>     haudio
> 
> ? 
> hAudio inside hAudio ?...  
> 
> > 2. Why we should introduce a new property called TRACK-TITLE.
> 
> You Have proposed 
> 
> recording, album, track, podcast,  position and  description
> 
> 5 new properties ONE reused from hAlbum *Track* the rest !!! 
> 
> You decided from the Issues page I Hope?
> 
> http://microformats.org/wiki/audio-info-issues
> 
> First I notice that you have dropped the audio-title property?
> 
> http://microformats.org/wiki/audio-info-issues#audio-title_Property
> 
> Only YOU made a vote for changing the current propsal which clearly
> means to me that only you had an issue with this?
>  +1 : use RECORDING and ALBUM ManuSporny 18:20, 27 Sep 2007 (PDT)
> 
> My Proposal Suggests We Keep it I voted Against changing it 
> -1 : don't change audio-title Martin McEvoy 15:48, 14 Aug 2007 (GMT)
> 
> David Janes voted also on this issue
> +1 for using FN, no clear difference between two so why invent another
> David Janes 14 August 2007
> 
> I would take that as a vote against or changing it entirely
> 
> My view would be from the *Three* votes we had that this was really a
> *NON ISSUE* but you changed it any way to reflect your views?
>  
> > 3. Why we should require CONTRIBUTOR to be marked up via a VCARD.
> 
> It Doesn't Just a recomendation as per the hAudio Spec.
> 
> >   
> > > I feel the more we bloat hAudio with *not* well thought of semantic
> > > class names such as *Album* (a container class or object not a title)
> > 
> > ALBUM is not a container class, 
> 
> In your view It Isn't..
> 
> In my View IT IS
> You re used the already discovered meaning of hAlbum I Presume?
> 
> http://microformats.org/wiki/audio-album-proposal#hAlbum
> http://microformats.org/wiki/audio-album-proposal#Simple_Album_Example
> 
> 
> > it defines two things:
> > 
> > - the name of an audio album
> > - the type of the hAudio
> > 
> > The examples require us to have something like this, so is your
> > opposition to it's name... or the concept that we need something to
> > denote the name and type of an hAudio?
> > 
> > > and *Podcast* (which is also a container class and not a title) the
> > > less 
> > 
> > PODCAST will probably not make it in unless somebody other than me
> > starts supporting it.
> > 
> > Let me point out that we have plenty of podcast examples:
> > 
> > http://microformats.org/wiki/audio-info-examples#Music_Podcasting
> > 
> > I'd like hAudio to be completed sooner than later and if PODCAST is
> > going to cause push-back, then I'd much rather drop it and move on...
> > even though we have a number of examples to support putting podcast in
> > hAudio.
> 
> I propose You change the hAudio Proposal back to the 0.6 version UNTILL
> these ISSUES have been resolved YOU cant Just change the proposal to
> reflect your personal views..
> 
> Manu you didnt even notify the list that you were making these changes
> untill AFTER the changes were made.
> 
> Frankly I resent the way you are seeming to bully this community into
> fiting into hAudio RDFa agenda 
> 
> http://wiki.digitalbazaar.com/en/HAudio_RDFa
> 
> which you have said yourself is more useful than the Microformat
> Proposal
> 
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Oct/0017.html
> 
> Thanks
> 
> Martin
> > 
> > -- manu
> > 
> > _______________________________________________
> > microformats-new mailing list
> > microformats-new@microformats.org
> > http://microformats.org/mailman/listinfo/microformats-new

From scott at makedatamakesense.com  Sat Oct  6 07:53:06 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sat Oct  6 07:53:10 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <1191670272.5782.48.camel@localhost.localdomain>
References: <46FD1623.8000802@digitalbazaar.com>
	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>
	<47058EB5.602@digitalbazaar.com>
	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>
	<4705AA3B.2020802@digitalbazaar.com>
	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
	<1191605497.31012.6.camel@localhost.localdomain>
	<470699CD.3050001@digitalbazaar.com>
	<1191667783.5782.45.camel@localhost.localdomain>
	<1191670272.5782.48.camel@localhost.localdomain>
Message-ID: <18A82A57-257A-4C92-B562-4C539D1759B5@makedatamakesense.com>

>>> So this simpler proposal makes perfect sense to me.
>>
>> at least someone on the list Is starting to make sense.
>
> Oh And thanks for Quoting me out of context..

Let's all try to clearly state what we mean without sarcasm and  
avoiding assumptions about what others mean, in the interest of  
clarifying disagreement and finding agreement.

--
Scott Reynen
MakeDataMakeSense.com


From julian at julianstahnke.com  Sat Oct  6 11:24:26 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Sat Oct  6 11:24:31 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <470699CD.3050001@digitalbazaar.com>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>	<4705AA3B.2020802@digitalbazaar.com>	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
	<1191605497.31012.6.camel@localhost.localdomain>
	<470699CD.3050001@digitalbazaar.com>
Message-ID: <85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>

> I'm guessing that you don't like the fact that you must define both
> TRACK and HAUDIO?
>
> The reason that we're doing this is because we might want to re-use
> TRACK (or whatever we end up calling it) in hVideo.
>
> Content has sections:
>
> Albums have Tracks
> Television Series have Episodes
> DVDs have Chapters
> Books have Chapters
>
> We could end up re-using TRACK to describe DVDs like so:
>
> <div class="hvideo">
> ...
>    <span class="dvd">The Matrix</span>
> ...
>    <span class="track hvideo">Chapter 27: The Lobby</span>
> ...
>    <span class="track haudio">Chinese Audio Track</span>
> ...
> </div>
>
> If we don't specify hvideo for the video track and haudio for the  
> audio
> track, how would the parser determine the difference? We would have
> ambiguity, which is one of the reasons all of the other  
> Microformats do
> this as well.
>
> If you want to push your proposal above, you will have to make the
> following arguments:
>
> 1. Why Ambiguity is not an issue for TRACK.
> 2. Why we should introduce a new property called TRACK-TITLE.
> 3. Why we should require CONTRIBUTOR to be marked up via a VCARD.

About tracks inside hAudio/hVideo: What about assuming that the track  
has the same media type as its parent element unless declared otherwise?

That way, the following?mentioned before?would thus be possible:

<div class="haudio">
...
   <span class="album">Album Title</span>
...
   <span class="track">Song Name</span>
...
</div>

What does ?track? mean in the context of the hVideo format, though? I  
would assume, from my limited forays into the world of video editing  
and from DVDs I own, that there can be multiple audio tracks that run  
in parallel. You can then choose one (?English?, for example) or even  
two which then run in parallel (?English? and ?Director?s comments?  
on a DVD).

The usage of ?track? specifically in hAudio (and rightfully so) is a  
sequential one, though. One track comes after another. So while it  
shares the same name, it?s (to my mind) an entirely different concept  
than a track found on a CD.

I?m not saying that one shouldn?t use the name track for hVideo?by no  
means, it seems to be quite valid. But I think it?s dangerous to  
define ?track? _across_ the boundaries of it?s definition in the  
container it?s used in. Maybe it should not have a definition by its  
own but only in context with the microformat it is used in. (Same as,  
for example, ?boot??it can either be something you wear on your foot  
or a part of a car.)

Then again, that might be quite confusing. I?m very confused already,  
for you could also map ?track? in hVideo to what commonly is referred  
to as a ?chapter? on a DVD. Which would be against its common usage  
in everyday language (I think). Maybe I missed a bit that would shed  
some light on this, but I think this issue needs some clarification.

For the record: I?m totally for using ?track? in hAudio, I?m just  
wary of trying to define it in a way that makes it be exactly the  
same in hVideo as well.

From julian at julianstahnke.com  Sat Oct  6 11:36:46 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Sat Oct  6 11:37:24 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>	<4705AA3B.2020802@digitalbazaar.com>	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
	<1191605497.31012.6.camel@localhost.localdomain>
	<470699CD.3050001@digitalbazaar.com>
	<85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
Message-ID: <71B758F6-A0AC-401D-973D-4CF044C5B045@julianstahnke.com>

> The usage of ?track? specifically in hAudio (and rightfully so) is  
> a sequential one, though. One track comes after another. So while  
> it shares the same name, it?s (to my mind) an entirely different  
> concept than a track found on a CD.

Gah! I wrote that in a very misleading way. I *don?t* mean that the  
usage of track in hAudio is entirely different than tracks on a CD.

I mean that tracks on a DVD/in a video seem to be an entirely  
different concept from tracks on a CD (from which the hAudio tracks  
are derived).
From scott at makedatamakesense.com  Sat Oct  6 12:02:55 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sat Oct  6 12:04:41 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>	<4705AA3B.2020802@digitalbazaar.com>	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
	<1191605497.31012.6.camel@localhost.localdomain>
	<470699CD.3050001@digitalbazaar.com>
	<85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
Message-ID: <F71F75D6-1B44-4D3F-9DE1-C4E2CF9E6838@makedatamakesense.com>

On Oct 6, 2007, at 12:24 PM, Julian Stahnke wrote:

> What does ?track? mean in the context of the hVideo format, though?

I think we're getting distracted here.  That's a good question for  
the hVideo discussion, but it's really irrelevant to the hAudio  
discussion.  Audio tracks need to be clearly identified as audio  
tracks regardless of what happens with hVideo, so let's focus on how  
to do that and leave hVideo for a separate discussion.

--
Scott Reynen
MakeDataMakeSense.com
From julian at julianstahnke.com  Sat Oct  6 12:42:02 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Sat Oct  6 12:43:00 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <F71F75D6-1B44-4D3F-9DE1-C4E2CF9E6838@makedatamakesense.com>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>	<4705AA3B.2020802@digitalbazaar.com>	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
	<1191605497.31012.6.camel@localhost.localdomain>
	<470699CD.3050001@digitalbazaar.com>
	<85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
	<F71F75D6-1B44-4D3F-9DE1-C4E2CF9E6838@makedatamakesense.com>
Message-ID: <56FF72C7-16C4-40D7-8806-956D44103C80@julianstahnke.com>

On 6 Oct 2007, at 8:02pm, Scott Reynen wrote:

> On Oct 6, 2007, at 12:24 PM, Julian Stahnke wrote:
>
>> What does ?track? mean in the context of the hVideo format, though?
>
> I think we're getting distracted here.  That's a good question for  
> the hVideo discussion, but it's really irrelevant to the hAudio  
> discussion.  Audio tracks need to be clearly identified as audio  
> tracks regardless of what happens with hVideo, so let's focus on  
> how to do that and leave hVideo for a separate discussion.

Okay. If that?s the case, then I don?t see why ?track? could not be  
just plain text?

Secondly, somewhat related, what happens if you stumble upon  
something like the following:

<div class="haudio">
     <h3 class="album">my album title</h3>
     by <strong class="contributor">the artist</strong>
     <ol>
         <li class="track">my track title</li>
         <li class="track">my track title</li>
         <li class="track">my track title</li>
     </ol>
</div>

Even though the tracks aren?t marked up as hAudio element and hence  
have no ?position? attribute, should ?position? be implied by the  
position of the track in the <ol>? (This must, obviously, never  
happen for an <ul>.) I think that would make sense and enable some  
nice, light-weight mark-up that everyone with even the most basic  
understanding of HTML could comprehend or write (and that is quite  
parseable as well).

(Also, I don?t know if the proposal to allow ?contributor? to be  
plain-text was welcomed or not. Just imagine an hcard in there in  
case it wasn?t ;))
From msporny at digitalbazaar.com  Sat Oct  6 15:54:33 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sat Oct  6 15:54:36 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>	<4705AA3B.2020802@digitalbazaar.com>	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>	<1191605497.31012.6.camel@localhost.localdomain>	<470699CD.3050001@digitalbazaar.com>
	<85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
Message-ID: <47081229.80403@digitalbazaar.com>

Julian Stahnke wrote:
>> If you want to push your proposal above, you will have to make the
>> following arguments:
>>
>> 1. Why Ambiguity is not an issue for TRACK.
>> 2. Why we should introduce a new property called TRACK-TITLE.
>> 3. Why we should require CONTRIBUTOR to be marked up via a VCARD.
> 
> About tracks inside hAudio/hVideo: What about assuming that the track
> has the same media type as its parent element unless declared otherwise?

That is a rule that we could certainly enforce via the parser... and it
would reduce the markup that a publisher would have to do.

Just to add a bit of implementation detail to your proposal:

An hAudio parser would then assume that the contents of TRACK is an
hAudio object if it is inside of an hAudio container. This means that
any uF markup inside of TRACK could be any of the properties of hAudio.

hAudio parsers, when seeing TRACK would create another hAudio object and
stuff the properties found in TRACK into the newly created hAudio object
for the TRACK.

Scott Reynen wrote:
>> What does ?track? mean in the context of the hVideo format, though?
> I think we're getting distracted here.  That's a good question for the
> hVideo discussion, but it's really irrelevant to the hAudio
> discussion.

I was attempting to think ahead to hVideo, but it seems to be causing
more confusion than helping. Scott's right... we should concentrate on
hAudio.

> Okay. If that?s the case, then I don?t see why ?track? could not be
> just plain text?

We could easily give publishers both options without complicating the
parser that greatly. Both of the examples below would be proper uses of
hAudio:

<div class="haudio">
    <h3 class="album">my album title</h3>
    by <strong class="contributor">the artist</strong>
    <ol>
        <li class="track">my track title</li>
        <li class="track">my track title</li>
        <li class="track">my track title</li>
    </ol>
</div>

<div class="haudio">
    <h3 class="album">3 live bands at my local venue</h3>
    by <strong class="contributor">various artists</strong>
    <ol>
        <li class="track">
           <span class="recording">first track title</a> by
           <span class="contributor">first artist</span>
        </li>
        <li class="track">
           <span class="recording">second track title</a> by
           <span class="contributor">second artist</span>
        </li>
        <li class="track">
           <span class="recording">third track title</a> by
           <span class="contributor">third artist</span>
        </li>
    </ol>
</div>

> Even though the tracks aren?t marked up as hAudio element and hence
> have no ?position? attribute, should ?position? be implied by the
> position of the track in the <ol>?

My thoughts are that it should be... but with the ability to override
the <li> numbering scheme. What happens if somebody only wants to list 3
of the items in the album... song 3, 5, and 8?

It should also be noted that the POSITION and DESCRIPTION concepts are
disputed additions to the proposal. I still need to go back through and
re-analyze the examples to prove that there is enough evidence in the
examples to add POSITION and DESCRIPTION to hAudio.

PODCAST is disputed by Martin and since I'm the only person that is
backing it based on the examples, it will probably be dropped unless
somebody else wants to see the ability to mark up PODCASTs via hAudio.
It also seems that RECORDING (was audio-title) is a disputed name
change, per Martin.

-- manu

From scott at makedatamakesense.com  Sat Oct  6 16:24:52 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sat Oct  6 16:24:55 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <47081229.80403@digitalbazaar.com>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>	<4705AA3B.2020802@digitalbazaar.com>	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>	<1191605497.31012.6.camel@localhost.localdomain>	<470699CD.3050001@digitalbazaar.com>
	<85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
	<47081229.80403@digitalbazaar.com>
Message-ID: <D59C377F-550C-4FBE-AAB8-0E07AD90C782@makedatamakesense.com>

On Oct 6, 2007, at 4:54 PM, Manu Sporny wrote:

> PODCAST is disputed by Martin and since I'm the only person that is
> backing it based on the examples, it will probably be dropped unless
> somebody else wants to see the ability to mark up PODCASTs via hAudio.

That's assuming those who don't want a podcast class don't want to be  
able to markup podcasts, which in my case is a false assumption.  I  
don't want a podcast class because I think we can markup podcasts  
without it.  Specifically, hAtom + hAudio = a podcast.  If you see  
something missing there, please clarify what exactly.

--
Scott Reynen
MakeDataMakeSense.com


From julian at julianstahnke.com  Sat Oct  6 16:38:08 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Sat Oct  6 16:38:13 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <47081229.80403@digitalbazaar.com>
References: <46FD1623.8000802@digitalbazaar.com>	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>	<47058EB5.602@digitalbazaar.com>	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>	<4705AA3B.2020802@digitalbazaar.com>	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>	<1191605497.31012.6.camel@localhost.localdomain>	<470699CD.3050001@digitalbazaar.com>
	<85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
	<47081229.80403@digitalbazaar.com>
Message-ID: <86B0D4A9-F1FB-4AFB-9670-503FB04F3318@julianstahnke.com>

> <div class="haudio">
>     <h3 class="album">my album title</h3>
>     by <strong class="contributor">the artist</strong>
>     <ol>
>         <li class="track">my track title</li>
>         <li class="track">my track title</li>
>         <li class="track">my track title</li>
>     </ol>
> </div>
>
> <div class="haudio">
>     <h3 class="album">3 live bands at my local venue</h3>
>     by <strong class="contributor">various artists</strong>
>     <ol>
>         <li class="track">
>            <span class="recording">first track title</a> by
>            <span class="contributor">first artist</span>
>         </li>
>         <li class="track">
>            <span class="recording">second track title</a> by
>            <span class="contributor">second artist</span>
>         </li>
>         <li class="track">
>            <span class="recording">third track title</a> by
>            <span class="contributor">third artist</span>
>         </li>
>     </ol>
> </div>

I think that, if you want to use hAudio properties inside a track, it  
actually must be an hAudio element. It must not be an hAudio element  
if you *only* want to use plain-text. Same for contributor with  
regards to hCard. Would seem most sensible to me.

>> Even though the tracks aren?t marked up as hAudio element and hence
>> have no ?position? attribute, should ?position? be implied by the
>> position of the track in the <ol>?
>
> My thoughts are that it should be... but with the ability to override
> the <li> numbering scheme. What happens if somebody only wants to  
> list 3
> of the items in the album... song 3, 5, and 8?

In that case, one would either use an unordered list (and have no  
numbering) or just use a full-blown haudio element and specify the  
position via the position property as that would *always* override  
any implied formatting. Implied formatting should accommodate for the  
most common use cases and be kept simple, I think.

It?s the same with implied fn formatting. It works fine in most  
cases, and if one wants something more fancy, one just uses given- 
name and family-name etc.

Note the use of haudio on the <li>s, I?m using properties of haudio  
instead of plain-text, so a new nested haudio element should be  
required imho.

That would result in the following mark-up:

<div class="haudio">
     <h3 class="album">3 live bands at my local venue</h3>
     by <strong class="contributor">various artists</strong>
     <ul>
         <li class="track haudio">
            <span class="position">1</span>
            <span class="recording">first track title</a> by
            <span class="contributor">first artist</span>
         </li>
         <li class="track haudio">
            <span class="position">4</span>
            <span class="recording">second track title</a> by
            <span class="contributor">second artist</span>
         </li>
         <li class="track haudio">
            <span class="position">8</span>
            <span class="recording">third track title</a> by
            <span class="contributor">third artist</span>
         </li>
     </ul>
</div>

Your example brings up something new; the various artist album case.  
 From common sense I?d say one should be able to omit the contributor  
in that case. The parser then should assume it is a various artist  
album and either say ?various artists? (less colloquial,  
obviously ;)) and/or, if available, construct it from the  
contributors in the ?track haudio? elements. The decision about what  
to do/display would then be in the hands of the person using the  
parser for his specific project.

I?m aware though that this leads to a dangerous path of assumptions  
and implications. It may be common sense and thus not very  
complicated for *me*?but someone else may think differently. Then  
again, it *really* makes sense to me. But I think we really need some  
more opinions on this case.

>> PODCAST is disputed by Martin and since I'm the only person that is
>> backing it based on the examples, it will probably be dropped unless
>> somebody else wants to see the ability to mark up PODCASTs via  
>> hAudio.
>
> That's assuming those who don't want a podcast class don't want to  
> be able to markup podcasts, which in my case is a false  
> assumption.  I don't want a podcast class because I think we can  
> markup podcasts without it.  Specifically, hAtom + hAudio = a  
> podcast.  If you see something missing there, please clarify what  
> exactly.

I haven?t given that case a lot of thinking, but I really like that  
solution. It even mirrors the technical definition of a podcast and  
makes it digestible by the whole toolchain I image one would want to  
use on it.
From paul_wilkins at xtra.co.nz  Sat Oct  6 17:27:25 2007
From: paul_wilkins at xtra.co.nz (paul_wilkins@xtra.co.nz)
Date: Sat Oct  6 17:27:29 2007
Subject: [uf-new] I propose a new microformat for poems.
Message-ID: <787886.78618.qm@web96002.mail.aue.yahoo.com>

From: Michael Walker <mike@yarrt.com>
> <div class="poem">
>    <p class="verse">
>      Standing by the roadside,<br />
>      A tall dark man,<br />
>      Wore a long brown coat,<br />
>      Stood in the rain.
>    </p>



I've never been keen with using breaks.

A
more semantically correct answer is provided with XHTML 2.0 where a
line element is defined so that awful breaks aren't required in things
like poems.
If they were used, then the poem would look like this:

<p class="verse">
  <l>Standing by the roadside,</l>
  <l>A tall dark man,</l>
  <l>Wore a long brown coat,</l>
  <l>Stood in the rain.</l>
</p>

Until such code is supported though, a modified form can be used

<p class="verse">

  <span class="l">Standing by the roadside,</span>

  <span class="l">A tall dark man,</span>

  <span class="l">Wore a long brown coat,</span>

  <span class="l">Stood in the rain.</span>

</p>


with a style of
.l { display: block; }


It's bulkier than just having breaks, but it gives warm fuzzies to the the semantic leprechaun within me.

-- 
Paul Wilkins

From msporny at digitalbazaar.com  Sat Oct  6 18:08:48 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sat Oct  6 18:08:51 2007
Subject: [uf-new] hAudio position and description properties
Message-ID: <470831A0.7070300@digitalbazaar.com>

Most of the day today was spent re-analyzing all of the music service
and podcast websites in audio-info-examples using Microformalyze. The
raw analysis data is available here:

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

The analysis is available here:

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

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

The new analysis shows very strong support for POSITION. This property
is displayed in 70.73% of 41 music service websites analyzed and 100% of
the 8 podcast websites analyzed.

There is also enough support to meet the 80/20 rule for DESCRIPTION.
This property is displayed in 39.02% of 41 music service websites
analyzed and 100% of the 8 podcast websites analyzed.

PROPOSAL: We add POSITION and DESCRIPTION to the hAudio draft since
          there are enough examples to warrant their inclusion into
          the Microformat.

-- manu
From julian at julianstahnke.com  Sat Oct  6 18:14:45 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Sat Oct  6 18:14:51 2007
Subject: [uf-new] hAudio position and description properties
In-Reply-To: <470831A0.7070300@digitalbazaar.com>
References: <470831A0.7070300@digitalbazaar.com>
Message-ID: <316FC33D-99C3-4E8F-839C-9B3AB61F4AAD@julianstahnke.com>

> PROPOSAL: We add POSITION and DESCRIPTION to the hAudio draft since
>           there are enough examples to warrant their inclusion into
>           the Microformat.

I think you?re right and they both make perfect sense.
From martin at weborganics.co.uk  Sat Oct  6 19:47:17 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct  6 19:46:40 2007
Subject: [uf-new] hAudio position and description properties
In-Reply-To: <470831A0.7070300@digitalbazaar.com>
References: <470831A0.7070300@digitalbazaar.com>
Message-ID: <1191725237.12116.17.camel@localhost.localdomain>

On Sat, 2007-10-06 at 21:08 -0400, Manu Sporny wrote:
> Most of the day today was spent re-analyzing all of the music service
> and podcast websites in audio-info-examples using Microformalyze. The
> raw analysis data is available here:
> 
> http://microformats.org/wiki/audio-info-examples#Microformalyze_Data_Files
> 
> The analysis is available here:
> 
> http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Services
> 
> http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Podcasts
> 
> The new analysis shows very strong support for POSITION. This property
> is displayed in 70.73% of 41 music service websites analyzed and 100% of
> the 8 podcast websites analyzed.

I found No evidence of Position as far as podcasting is concerned
although all the examples make a reference to episode I am not sure that
this is the same thing, Can I also point out that podcasting Is NOT a
problem area for this discussion.

However Position Is something that should be supported As far as Music
Downloads are concerned

+1 for Position

> 
> There is also enough support to meet the 80/20 rule for DESCRIPTION.
> This property is displayed in 39.02% of 41 music service websites
> analyzed and 100% of the 8 podcast websites analyzed.

+1 for Description

> 
> PROPOSAL: We add POSITION and DESCRIPTION to the hAudio draft since
>           there are enough examples to warrant their inclusion into
>           the Microformat.
> 
> -- manu

Manu are you also going to REMOVE the Album and Podcast properties and
revert back to *audio-title* until any disputes have been resolved? I do
not think that three votes was enough to warrant any changes to the
existing proposal.

I think you should have notified all the active participants in hAudio
BEFORE you made any changes to OUR proposition.

Thanks

Martin
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From martin at weborganics.co.uk  Sun Oct  7 12:30:39 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sun Oct  7 12:30:05 2007
Subject: [uf-new] hAudio position and description properties
In-Reply-To: <1191725237.12116.17.camel@localhost.localdomain>
References: <470831A0.7070300@digitalbazaar.com>
	<1191725237.12116.17.camel@localhost.localdomain>
Message-ID: <1191785439.18330.16.camel@localhost.localdomain>

On Sun, 2007-10-07 at 03:47 +0100, Martin McEvoy wrote:
> On Sat, 2007-10-06 at 21:08 -0400, Manu Sporny wrote:
> > Most of the day today was spent re-analyzing all of the music service
> > and podcast websites in audio-info-examples using Microformalyze. The
> > raw analysis data is available here:
> > 
> > http://microformats.org/wiki/audio-info-examples#Microformalyze_Data_Files
> > 
> > The analysis is available here:
> > 
> > http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Services
> > 
> > http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Podcasts
> > 
> > The new analysis shows very strong support for POSITION. This property
> > is displayed in 70.73% of 41 music service websites analyzed and 100% of
> > the 8 podcast websites analyzed.
> 
> I found No evidence of Position as far as podcasting is concerned
> although all the examples make a reference to episode I am not sure that
> this is the same thing, Can I also point out that podcasting Is NOT a
> problem area for this discussion.
> 
> However Position Is something that should be supported As far as Music
> Downloads are concerned
> 
> +1 for Position
> 
> > 
> > There is also enough support to meet the 80/20 rule for DESCRIPTION.
> > This property is displayed in 39.02% of 41 music service websites
> > analyzed and 100% of the 8 podcast websites analyzed.
> 
> +1 for Description
> 
> > 
> > PROPOSAL: We add POSITION and DESCRIPTION to the hAudio draft since
> >           there are enough examples to warrant their inclusion into
> >           the Microformat.
> > 
> > -- manu
> 
> Manu are you also going to REMOVE the Album and Podcast properties and
> revert back to *audio-title* until any disputes have been resolved? I do
> not think that three votes was enough to warrant any changes to the
> existing proposal.
> 
> I think you should have notified all the active participants in hAudio
> BEFORE you made any changes to OUR proposition.

Sorry for seeming unreasonable but the additions of Album and Recording
really was a bit of a surprise to me and something that wasn't fully
discussed

Anyway An easy solution  The beginning of this conversation was about
(in a nutshell) merging certain properties from  hAlbum into hAudio
right! so why don't we just do that 

>From hAlbum we reuse both 

*album-title*
http://microformats.org/wiki/audio-album-proposal#Album_Title

and 

*track*
http://microformats.org/wiki/audio-album-proposal#Track 

coupled with new properties

*position*  and *description*

merge all that with the 0.6 version of hAudio and I think we have
something that will suit everyone's situation

The full property list would be

hAudio
album-title
contributor
published
rel-sample
rel-enclosure
rel-payment
photo
track
audio-title
duration
category
price

Comments?


Thanks 
Martin

> 
> Thanks
> 
> Martin
> > _______________________________________________
> > microformats-new mailing list
> > microformats-new@microformats.org
> > http://microformats.org/mailman/listinfo/microformats-new

From martin at weborganics.co.uk  Sun Oct  7 12:32:30 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sun Oct  7 12:31:53 2007
Subject: [uf-new] hAudio position and description properties
In-Reply-To: <1191785439.18330.16.camel@localhost.localdomain>
References: <470831A0.7070300@digitalbazaar.com>
	<1191725237.12116.17.camel@localhost.localdomain>
	<1191785439.18330.16.camel@localhost.localdomain>
Message-ID: <1191785550.18330.18.camel@localhost.localdomain>

On Sun, 2007-10-07 at 20:30 +0100, Martin McEvoy wrote:
> On Sun, 2007-10-07 at 03:47 +0100, Martin McEvoy wrote:
> > On Sat, 2007-10-06 at 21:08 -0400, Manu Sporny wrote:
> > > Most of the day today was spent re-analyzing all of the music service
> > > and podcast websites in audio-info-examples using Microformalyze. The
> > > raw analysis data is available here:
> > > 
> > > http://microformats.org/wiki/audio-info-examples#Microformalyze_Data_Files
> > > 
> > > The analysis is available here:
> > > 
> > > http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Services
> > > 
> > > http://microformats.org/wiki/audio-info-examples#Analysis_of_Music_Podcasts
> > > 
> > > The new analysis shows very strong support for POSITION. This property
> > > is displayed in 70.73% of 41 music service websites analyzed and 100% of
> > > the 8 podcast websites analyzed.
> > 
> > I found No evidence of Position as far as podcasting is concerned
> > although all the examples make a reference to episode I am not sure that
> > this is the same thing, Can I also point out that podcasting Is NOT a
> > problem area for this discussion.
> > 
> > However Position Is something that should be supported As far as Music
> > Downloads are concerned
> > 
> > +1 for Position
> > 
> > > 
> > > There is also enough support to meet the 80/20 rule for DESCRIPTION.
> > > This property is displayed in 39.02% of 41 music service websites
> > > analyzed and 100% of the 8 podcast websites analyzed.
> > 
> > +1 for Description
> > 
> > > 
> > > PROPOSAL: We add POSITION and DESCRIPTION to the hAudio draft since
> > >           there are enough examples to warrant their inclusion into
> > >           the Microformat.
> > > 
> > > -- manu
> > 
> > Manu are you also going to REMOVE the Album and Podcast properties and
> > revert back to *audio-title* until any disputes have been resolved? I do
> > not think that three votes was enough to warrant any changes to the
> > existing proposal.
> > 
> > I think you should have notified all the active participants in hAudio
> > BEFORE you made any changes to OUR proposition.
> 
> Sorry for seeming unreasonable but the additions of Album and Recording
> really was a bit of a surprise to me and something that wasn't fully
> discussed
> 
> Anyway An easy solution  The beginning of this conversation was about
> (in a nutshell) merging certain properties from  hAlbum into hAudio
> right! so why don't we just do that 
> 
> >From hAlbum we reuse both 
> 
> *album-title*
> http://microformats.org/wiki/audio-album-proposal#Album_Title
> 
> and 
> 
> *track*
> http://microformats.org/wiki/audio-album-proposal#Track 
> 
> coupled with new properties
> 
> *position*  and *description*
> 
> merge all that with the 0.6 version of hAudio and I think we have
> something that will suit everyone's situation
> 
> The full property list would be
> 
> hAudio
> album-title
description
> contributor
> published
> rel-sample
> rel-enclosure
> rel-payment
> photo
> track
position
> audio-title
> duration
> category
> price
> 
> Comments?
> 
> 
> Thanks 
> Martin

Sorry, Its been a long weekend :)

> 
> > 
> > Thanks
> > 
> > Martin
> > > _______________________________________________
> > > microformats-new mailing list
> > > microformats-new@microformats.org
> > > http://microformats.org/mailman/listinfo/microformats-new

From msporny at digitalbazaar.com  Sun Oct  7 12:56:42 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Oct  7 12:59:10 2007
Subject: [uf-new] hAudio position and description properties
In-Reply-To: <1191785439.18330.16.camel@localhost.localdomain>
References: <470831A0.7070300@digitalbazaar.com>	<1191725237.12116.17.camel@localhost.localdomain>
	<1191785439.18330.16.camel@localhost.localdomain>
Message-ID: <470939FA.8010009@digitalbazaar.com>

Martin McEvoy wrote:
> Anyway An easy solution  The beginning of this conversation was about
> (in a nutshell) merging certain properties from  hAlbum into hAudio
> right! so why don't we just do that 
> 
>>From hAlbum we reuse both 
> 
> *album-title*
> http://microformats.org/wiki/audio-album-proposal#Album_Title
> 
> and 
> 
> *track*
> http://microformats.org/wiki/audio-album-proposal#Track 
> 
> coupled with new properties
> 
> *position*  and *description*
> 
> merge all that with the 0.6 version of hAudio and I think we have
> something that will suit everyone's situation

The hAudio specification has been updated. The following properties have
been reverted or added:

* RECORDING has been changed back to AUDIO-TITLE
* ALBUM has been changed back to ALBUM-TITLE
* POSITION has been moved from disputed to not disputed status.
* DESCRIPTION has been moved from disputed to not disputed status.

-- manu
From martin at weborganics.co.uk  Sun Oct  7 13:34:57 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sun Oct  7 13:34:20 2007
Subject: [uf-new] hAudio position and description properties
In-Reply-To: <470939FA.8010009@digitalbazaar.com>
References: <470831A0.7070300@digitalbazaar.com>
	<1191725237.12116.17.camel@localhost.localdomain>
	<1191785439.18330.16.camel@localhost.localdomain>
	<470939FA.8010009@digitalbazaar.com>
Message-ID: <1191789297.18962.0.camel@localhost.localdomain>

On Sun, 2007-10-07 at 15:56 -0400, Manu Sporny wrote:
> Martin McEvoy wrote:
> > Anyway An easy solution  The beginning of this conversation was about
> > (in a nutshell) merging certain properties from  hAlbum into hAudio
> > right! so why don't we just do that 
> > 
> >>From hAlbum we reuse both 
> > 
> > *album-title*
> > http://microformats.org/wiki/audio-album-proposal#Album_Title
> > 
> > and 
> > 
> > *track*
> > http://microformats.org/wiki/audio-album-proposal#Track 
> > 
> > coupled with new properties
> > 
> > *position*  and *description*
> > 
> > merge all that with the 0.6 version of hAudio and I think we have
> > something that will suit everyone's situation
> 
> The hAudio specification has been updated. The following properties have
> been reverted or added:
> 
> * RECORDING has been changed back to AUDIO-TITLE
> * ALBUM has been changed back to ALBUM-TITLE
> * POSITION has been moved from disputed to not disputed status.
> * DESCRIPTION has been moved from disputed to not disputed status.

Thank You Manu :)

Martin
> 
> -- manu
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From jeff at jeffmcneill.com  Sun Oct  7 16:58:13 2007
From: jeff at jeffmcneill.com (Jeff McNeill)
Date: Sun Oct  7 16:58:17 2007
Subject: [uf-new] course syllabus markup or microformat?
In-Reply-To: <mailman.3058.1191801384.30172.microformats-new@microformats.org>
References: <mailman.3058.1191801384.30172.microformats-new@microformats.org>
Message-ID: <519fa62f0710071658g2a7dd341q7be3695b125f4d0f@mail.gmail.com>

Aloha everyone,

Wondering if there is any work on microformat or markup of a course
syllabus? Any and all suggestions solicited.

Problem statement:
 * Syllabi are a source of much labor by instructors and much
discussion and concern by students in higher education. Yet there
appears to be no standard format either within or across colleges,
disciplines, or courses. Reuse is based on copy-and-paste,
word-of-mouth and serendipitous use of Google. With over 2 million
undergraduate degrees awarded yearly in the United States alone, there
is a large and growing population which use this document format. With
the increasing demand for assessment of higher education (Spellings
report, etc.), the humble syllabus is gaining in prominence.

Initial information-gathering:
* A cursory review of 14 syllabi of a similar course (undergraduate
organizational communication), across a number of universities reveals
a large amount of common information.
 * It appears that hCard, hCalendar, and citation/bibliographic
microformats may be usefully deployed in this endeavor.

Other efforts:
* SylViA is a Berkeley iSchool masters project, but is specific only
to one school:
http://groups.sims.berkeley.edu/sylvia/docs/schema/syllabus_schema.xsd

Definition:
*  http://en.wikipedia.org/wiki/Syllabus includes the formulation:
>
>
> The syllabus serves many purposes for the students and the teacher such as 1) ensuring a fair and upfront contract between the instructor and students such that there is minimal confusion on policies relating to the course, 2) setting clear expectations of a) material to be learned, b) behavior in the classroom, and c) effort of student's behalf to be put into the course, 3) providing a roadmap of course organization/direction 4) relaying the instructor's teaching philosophy to the students, and 5) providing a marketing angle of the course such that students may choose early in the course whether the subject material is attractive.
>
> Many items can be included in a syllabus to maximize course organization and student understanding of expected material such as 1) grading policy (grading scale optional but helpful), 2) locations and times (classroom location/time, instructor office hours and location, teaching assistant office hours and location), 3) other contact information for instructor and teaching assistant such as phone or email, 4) materials required and/or recommended such as textbooks, assigned reading books, calculators (or other equipment), lab vouchers, etc 5) outside resources for subject material assistance (extra-curricular books, tutor locations, resource centers, etc), 6) important dates in course such as exams and paper due-dates 7) tips for succeeding in mastering course content such as study habits and expected time allotment, 8) suggested problems if applicable 9) necessary pre-requisites or co-requisites to current course, 10) safety rules if appropriate, and most importantly 11) objectives of course.

-- 
Sincerely,
Jeff McNeill
http://jeffmcneill.com/

From bewest at gmail.com  Sun Oct  7 21:57:58 2007
From: bewest at gmail.com (Benjamin West)
Date: Sun Oct  7 21:58:01 2007
Subject: [uf-new] I propose a new microformat for poems.
In-Reply-To: <op.tzmwpdytjyd8jy@mikeslaptop>
References: <op.tzmwpdytjyd8jy@mikeslaptop>
Message-ID: <8ad71be30710072157l4ee10744vf977a5f06347acd6@mail.gmail.com>

On 10/3/07, Michael Walker <mike@yarrt.com> wrote:
> I can't seem to find a microformat for poetry. I often write poems and
> post them to my blog (http://blog.yarrt.com), and I sometimes wonder about
> the best way to code them. Below is the method I have thought of (with one
> of my poems as an example):
> --
> Michael Walker, Webmaster
>

There are other groups interested in this.  It was recently brought up
in a thread on the public-html list in the context of HTML5.

http://lists.w3.org/Archives/Public/public-html/2007Oct/0058.html
http://esw.w3.org/topic/HTML/PoeticSemantics

Hope this helps.

-Ben
From paul_wilkins at xtra.co.nz  Mon Oct  8 00:32:44 2007
From: paul_wilkins at xtra.co.nz (paul_wilkins@xtra.co.nz)
Date: Mon Oct  8 00:32:49 2007
Subject: [uf-new] I propose a new microformat for poems.
Message-ID: <928863.56190.qm@web96002.mail.aue.yahoo.com>

From: Benjamin West <bewest@gmail.com>

> There are other groups interested in this.  It was recently brought up

> in a thread on the public-html list in the context of HTML5.

> 

> http://lists.w3.org/Archives/Public/public-html/2007Oct/0058.html

> http://esw.w3.org/topic/HTML/PoeticSemantics

> 

> Hope this helps.





Thank you Benjamin, that helps a lot.



I've been wanting to get rid of the break elements from poetry.
A previous post achieved that but at the expense of a lot of repeated class names, or as some call it, classitis.

The discussion of poetry semantics helped remind me of what the answer should be.



On the poetery semantics wiki, Olaf was proposing some HTML5 elements, POEM, STROPHE, LINE and H, but elements should be elemental, from which other more meaningful constructs are built.


Gregory was saying

    "why not a containing element that indicates a line of poetry, much as <LI> and </LI> indicate the beginning and end of a list item?"


XHTML is supposed to have an L element for marking up separate lines of text within a paragraph.
This idea already exists, in the OL and UL structures.


Tantek put together a presentation called "The Elements of Meaningful XHTML" where XHTML compounds are used to properly markup the content.
http://tantek.com/presentations/2005/09/elements-of-xhtml/



I don't know how he still feels about his presentation, but to me it covers some very important ideas.

A part of the presentation used OL structures to markup conversations between multiple people, and bibliographies. This works because the elements provide the semantics, while the styles are used to remove the line numbers from the list elements, to affect how it's presented.


With this in mind, a poem can be quite easily marked up without linebreaks or special elements.

ol.stanza { list-style: none; margin: 0; padding: 0; }
. . .
<div class="poem">
  <h1>The Lady of Shalott</h1>

  <ol class="stanza">

    <li>On either side the river lie</li>

    <li>Long fields of barley and of rye,</li>

    <li>That clothe the wold and meet the sky;</li>

    <li>And through the field the road run by</li>

    <li>To many-tower'd Camelot;</li>

    <li>And up and down the people go,</li>

    <li>Gazing where the lilies blow</li>

    <li>Round an island there below,</li>

    <li>The island of Shalott.</li>

  </ol>


</div>



-- 
Paul Wilkins



From chris.newell at rd.bbc.co.uk  Mon Oct  8 07:42:09 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Mon Oct  8 08:12:34 2007
Subject: [uf-new] hAudio/table incompatibility
In-Reply-To: <D59C377F-550C-4FBE-AAB8-0E07AD90C782@makedatamakesense.com
 >
References: <46FD1623.8000802@digitalbazaar.com>
	<6E0FB330-6450-426C-8D27-926055E60C26@julianstahnke.com>
	<47058EB5.602@digitalbazaar.com>
	<3B835F83-6E6E-4FBA-8308-FFDAC836F64B@makedatamakesense.com>
	<4705AA3B.2020802@digitalbazaar.com>
	<383B3334-80FC-40BF-B655-39963BF5DB99@julianstahnke.com>
	<1191605497.31012.6.camel@localhost.localdomain>
	<470699CD.3050001@digitalbazaar.com>
	<85137B17-28D2-4A07-87E7-7864A39EDAEA@julianstahnke.com>
	<47081229.80403@digitalbazaar.com>
	<D59C377F-550C-4FBE-AAB8-0E07AD90C782@makedatamakesense.com>
Message-ID: <6.2.0.14.2.20071008153204.02df8ea0@pop3>

At 00:24 07/10/2007, Scott Reynen wrote:
>On Oct 6, 2007, at 4:54 PM, Manu Sporny wrote:
>>PODCAST is disputed by Martin and since I'm the only person that is
>>backing it based on the examples, it will probably be dropped unless
>>somebody else wants to see the ability to mark up PODCASTs via hAudio.
>
>That's assuming those who don't want a podcast class don't want to be  
>able to markup podcasts, which in my case is a false assumption.  I  
>don't want a podcast class because I think we can markup podcasts  
>without it.  Specifically, hAtom + hAudio = a podcast.  If you see  
>something missing there, please clarify what exactly.

Likewise we have TOPLIST, CHART, and PLAYLIST discussed as collection names in audio-info-issues #10.

Aren't these generic list types which should be defined (where necessary) outside of hAudio?

Chris

_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From msporny at digitalbazaar.com  Mon Oct  8 08:22:05 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Mon Oct  8 08:24:40 2007
Subject: [uf-new] hAudio position and description properties
In-Reply-To: <1191725237.12116.17.camel@localhost.localdomain>
References: <470831A0.7070300@digitalbazaar.com>
	<1191725237.12116.17.camel@localhost.localdomain>
Message-ID: <470A4B1D.8090204@digitalbazaar.com>

Martin McEvoy wrote:
> I found No evidence of Position as far as podcasting is concerned
> although all the examples make a reference to episode I am not sure that
> this is the same thing

I treated podcast episode number as a POSITION because it was something
that denoted an order, other than release date, for an audio recording.

> I think you should have notified all the active participants in hAudio
> BEFORE you made any changes to OUR proposition.

I was merely attempting to bring the hAudio specification up-to-date
with the issues page and the discussion. It no longer reflected the
issues page nor the discussion that was happening on the mailing list,
so I updated the audio-info-proposal page to reflect, what I thought,
was the current thinking on hAudio. That is all, there were and still
are no sinister motives behind those edits other than attempting to move
the format forward.

-- manu

From msporny at digitalbazaar.com  Mon Oct  8 08:58:44 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Mon Oct  8 09:01:22 2007
Subject: [uf-new] Closing several hAudio issues
Message-ID: <470A53B4.8070408@digitalbazaar.com>

There are several hAudio issues that seem to have been resolved in the
past several weeks that should be marked as "Resolved".

PROPOSAL: We close the following issues as each problem seems to have
          been addressed.

hAudio ISSUE #1: image-summary Property is redundant
 - PHOTO has been used to replace image-summary in the latest proposal,
   reusing a previous Microformat property, which is a Good Thing(tm).
 - http://microformats.org/wiki/audio-info-proposal#Photo

hAudio ISSUE #3:  published-date Property is redundant
 - PUBLISHED has been used to replace published-date in the latest
   proposal, reusing a previous Microformat property, which is a Good
   Thing (tm).
 -http://microformats.org/wiki/audio-info-issues#published-date_Property

hAudio ISSUE #6: Summary Property is Missing
 - DESCRIPTION has been added to the latest proposal.
 - http://microformats.org/wiki/audio-info-proposal#Description

hAudio ISSUE #7: Track Number is Missing
 - POSITION has been added to the hAudio proposal, thus resolving this
   issue.
 - http://microformats.org/wiki/audio-info-proposal#Position

hAudio ISSUE #8: hAlbum is redundant
 - We now have the ALBUM-TITLE and TRACK elements in hAudio, there is no
   longer a need for hAlbum.
 - http://microformats.org/wiki/audio-info-proposal#Schema

hAudio ISSUE #12: CONTRIBUTOR and TRACK are not publisher friendly
 - Short forms for CONTRIBUTOR and TRACK are proposed in the newest
   proposal and doesn't seem to cause any parsing problems or
   compatibility issues with other Microformats.
 - http://microformats.org/wiki/audio-info-proposal#Contributor
 - http://microformats.org/wiki/audio-info-proposal#Track

If there are no objections, I would like to mark each as a "Resolved Issue"

-- manu
From hober0 at gmail.com  Mon Oct  8 10:35:04 2007
From: hober0 at gmail.com (Edward O'Connor)
Date: Mon Oct  8 11:12:48 2007
Subject: [uf-new] Re: I propose a new microformat for poems.
References: <928863.56190.qm@web96002.mail.aue.yahoo.com>
Message-ID: <86tzp11pdj.fsf@rakim.cfhp.org>

> I've been wanting to get rid of the break elements from poetry.

We've shied away from a "source code" microformat, becuase the existing
HTML compound of <pre><code> works. Isn't the poetry case analagous?
(Except that we have no inline element to compound with the <pre>.)

<pre class="poem">
When Aubrey did live there lived no poor,
The lord and the beggar on roots did dine
With lily, germander, and sops in wine,
  With sweet-brier,
    And bon-fire,
    And strawberry-wire,
      And columbine.
</pre>


-- 
Edward O'Connor
hober0@gmail.com

Ense petit placidam sub libertate quietem.

From paul_wilkins at xtra.co.nz  Mon Oct  8 12:27:02 2007
From: paul_wilkins at xtra.co.nz (paul_wilkins@xtra.co.nz)
Date: Mon Oct  8 12:27:05 2007
Subject: [uf-new] Re: I propose a new microformat for poems.
Message-ID: <513837.88861.qm@web96012.mail.aue.yahoo.com>

From: Edward O'Connor <hober0@gmail.com>
> We've shied away from a "source code" microformat, becuase the existing
> HTML compound of <pre><code> works. Isn't the poetry case analagous?
> (Except that we have no inline element to compound with the <pre>.)
> 
> <pre class="poem">
> When Aubrey did live there lived no poor,
> The lord and the beggar on roots did dine
> With lily, germander, and sops in wine,
>   With sweet-brier,
>     And bon-fire,
>     And strawberry-wire,
>       And columbine.
> </pre>

While that works, it seems to be a brutal method to use when special formatting isn't required.

-- 
Paul Wilkins




From bhawkeslewis at googlemail.com  Mon Oct  8 12:55:24 2007
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Mon Oct  8 12:55:35 2007
Subject: [uf-new] Re: I propose a new microformat for poems.
In-Reply-To: <513837.88861.qm@web96012.mail.aue.yahoo.com>
References: <513837.88861.qm@web96012.mail.aue.yahoo.com>
Message-ID: <470A8B2C.5050505@googlemail.com>

paul_wilkins@xtra.co.nz wrote:
> From: Edward O'Connor <hober0@gmail.com>
>> We've shied away from a "source code" microformat, becuase the existing
>> HTML compound of <pre><code> works. Isn't the poetry case analagous?
>> (Except that we have no inline element to compound with the <pre>.)
>>
>> <pre class="poem">
>> When Aubrey did live there lived no poor,
>> The lord and the beggar on roots did dine
>> With lily, germander, and sops in wine,
>>   With sweet-brier,
>>     And bon-fire,
>>     And strawberry-wire,
>>       And columbine.
>> </pre>
> 
> While that works, it seems to be a brutal method to use when special formatting isn't required.
> 

Brutal how?

--
Benjamin Hawkes-Lewis
From paul_wilkins at xtra.co.nz  Mon Oct  8 14:17:26 2007
From: paul_wilkins at xtra.co.nz (paul_wilkins@xtra.co.nz)
Date: Mon Oct  8 14:17:30 2007
Subject: [uf-new] Re: I propose a new microformat for poems.
Message-ID: <610159.10069.qm@web96003.mail.aue.yahoo.com>

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
> Brutal how?

In that there are several styling limitation when using a PRE block for a stanza, and that only a small percentage of poems are free-form in nature. Usually it's the 80% group for which problems are solved.

The tools for extracting and working with the text are often XML based. Processing of such text becomes more difficult when whitespace has to be taken into account.

it also reminds me of using tables for page layout in the bad old days. It's a lazy habit that provides no real benefit other than pure layout, often at the expense of other things.

Perhaps it may help if we see how the code looks for each case.

The standard formatting uses linebreaks

<div class="poem">

<h1>Title</h1>

<p class="stanza">

Line 1<br />

Line 2

</p>

<p class="stanza">

Line 3<br />

Line 4

</pre>

</div>


If you loath linebreaks like I do, other options are using ordered lists with a touch of styling to remove the line numbers


<div class="poem">

<h1>Title</h1>

<ol class="stanza">

  <li>Line 1</li>

  <li>Line 2</li>

</ol>

<ol> class="stanza">

  <li>Line 3</li>

  <li>Line 4</li>

</ol>

</div>


Then there's the preformatted tag, which does the job and in the few instances where required, lets you adjust the spacing, but doesn't allow much room for much else


<div class="poem">
<h1>Title</h1>
<pre>
Line 1
Line 2

Line 3
Line 4
</pre>
</div>

-- 
Paul Wilkins




From scott at makedatamakesense.com  Mon Oct  8 15:22:34 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Mon Oct  8 15:42:46 2007
Subject: [uf-new] Re: I propose a new microformat for poems.
In-Reply-To: <610159.10069.qm@web96003.mail.aue.yahoo.com>
References: <610159.10069.qm@web96003.mail.aue.yahoo.com>
Message-ID: <6AEE5EE6-98FD-463E-9B98-9750520D819C@makedatamakesense.com>

On Oct 8, 2007, at 3:17 PM, paul_wilkins@xtra.co.nz wrote:

> it also reminds me of using tables for page layout in the bad old  
> days. It's a lazy habit that provides no real benefit other than  
> pure layout, often at the expense of other things.

Clearly identifying those "other things" would probably help.  What  
exactly is the problem we're trying to solve here?

--
Scott Reynen
MakeDataMakeSense.com


From martin at weborganics.co.uk  Mon Oct  8 16:15:37 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Mon Oct  8 16:15:00 2007
Subject: [uf-new] Closing several hAudio issues
In-Reply-To: <470A53B4.8070408@digitalbazaar.com>
References: <470A53B4.8070408@digitalbazaar.com>
Message-ID: <1191885337.25159.56.camel@localhost.localdomain>

On Mon, 2007-10-08 at 11:58 -0400, Manu Sporny wrote:
> There are several hAudio issues that seem to have been resolved in the
> past several weeks that should be marked as "Resolved".
> 
> PROPOSAL: We close the following issues as each problem seems to have
>           been addressed.
> 
> hAudio ISSUE #1: image-summary Property is redundant
>  - PHOTO has been used to replace image-summary in the latest proposal,
>    reusing a previous Microformat property, which is a Good Thing(tm).
>  - http://microformats.org/wiki/audio-info-proposal#Photo
> 
> hAudio ISSUE #3:  published-date Property is redundant
>  - PUBLISHED has been used to replace published-date in the latest
>    proposal, reusing a previous Microformat property, which is a Good
>    Thing (tm).
>  -http://microformats.org/wiki/audio-info-issues#published-date_Property
> 
> hAudio ISSUE #6: Summary Property is Missing
>  - DESCRIPTION has been added to the latest proposal.
>  - http://microformats.org/wiki/audio-info-proposal#Description
> 
> hAudio ISSUE #7: Track Number is Missing
>  - POSITION has been added to the hAudio proposal, thus resolving this
>    issue.
>  - http://microformats.org/wiki/audio-info-proposal#Position
> 
> hAudio ISSUE #8: hAlbum is redundant
>  - We now have the ALBUM-TITLE and TRACK elements in hAudio, there is no
>    longer a need for hAlbum.
>  - http://microformats.org/wiki/audio-info-proposal#Schema
> 
> hAudio ISSUE #12: CONTRIBUTOR and TRACK are not publisher friendly
>  - Short forms for CONTRIBUTOR and TRACK are proposed in the newest
>    proposal and doesn't seem to cause any parsing problems or
>    compatibility issues with other Microformats.
>  - http://microformats.org/wiki/audio-info-proposal#Contributor
>  - http://microformats.org/wiki/audio-info-proposal#Track
> 
> If there are no objections, I would like to mark each as a "Resolved Issue"

No Objections

although I do have concerns with the track definition
http://microformats.org/wiki/audio-info-proposal#Track

A container for another hAudio item. Used in conjunction with
album-title. 

      * The element is identified by the class name track.
      * hAudio MAY have one or more tracks, but MUST have album-title
        defined. If album-title is not defined, track cannot be defined.
      * The element MUST be processed opaquely. No sub-elements should
        be read from any hAudio contained in a track element.
      * The contents of the element MAY be plain-text or marked up using
        hAudio.

In Particular

"hAudio MAY have one or more tracks, but MUST have album-title defined.
If album-title is not defined, track cannot be defined"

?

What Happens when I want to mark up a single track from an Album  that
may be part of a collection, best of, or compilation?

I would Like to mark my page up like this:

<div class="haudio">
	<div class="track">
            <span class="audio-title">Spanish Bombs</span> 
            <abbr class="duration" title="P191T">3:18</abbr>
	    taken from the <span class="album-title">London Calling</span> album
            By <span class="contributor">The Clash</span>
         </div>
 	<div class="track">
	   <span class="audio-title">Nagasaki Nightmare</span> 
           <abbr class="duration" title="P268T">4:46</abbr>
	   taken from the <span class="album-title">Best Before 1984</span> album
	   By <span class="contributor">Crass</span>
       </div>
</div>

Seems to make sense but according to the Proposal this Is Invalid hAudio

Maybe like this then?

<div class="haudio">
	<div class="track">
            <span class="audio-title">Spanish Bombs</span> 
            <abbr class="duration" title="P191T">3:18</abbr>
	</div>
	    taken from the <span class="album-title">London Calling</span> album
            By <span class="contributor">The Clash</span>
</div>

<div class="haudio">
 	<div class="track">
	   <span class="audio-title">Nagasaki Nightmare</span> 
           <abbr class="duration" title="P268T">4:46</abbr>
         </div>
	   taken from the <span class="album-title">Best Before 1984</span> album
	   By <span class="contributor">Crass</span>
</div>

Seems like valid hAudio but Is not because the contents of a hAudio
track must either be marked up as text or as hAudio

<div class="haudio">
	<div class="track haudio">
            <span class="audio-title">Spanish Bombs</span> 
            <abbr class="duration" title="P191T">3:18</abbr>
	</div>
	    taken from the <span class="album-title">London Calling</span>
album
            By <span class="contributor">The Clash</span>
</div>

<div class="haudio">
 	<div class="track haudio">
	   <span class="audio-title">Nagasaki Nightmare</span> 
           <abbr class="duration" title="P268T">4:46</abbr>
         </div>
	   taken from the <span class="album-title">Best Before 1984</span>
album
	   By <span class="contributor">Crass</span>
</div>

This Is  Valid hAudio my concerns are Do we really need to reiterate
haudio In the track class It seems confusing that hAudio Is both a
parent and a child class. used in the above context haudio has the same
meaning as track?

I think the proposition should simply say 

      * "hAudio MAY have zero or more tracks" 
      * "Track titles MAY be defined by using the class name
        *audio-title* it is recommended that a hAudio track SHOULD have
        an audio-title" *

This would enable Greater flexibility when publishing hAudio.

Thanks 

Martin



> -- manu
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From julian at julianstahnke.com  Mon Oct  8 17:27:47 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Mon Oct  8 17:27:54 2007
Subject: [uf-new] Closing several hAudio issues
In-Reply-To: <1191885337.25159.56.camel@localhost.localdomain>
References: <470A53B4.8070408@digitalbazaar.com>
	<1191885337.25159.56.camel@localhost.localdomain>
Message-ID: <94F0EA16-7B03-4A69-9839-EF5A23370752@julianstahnke.com>

>
> A container for another hAudio item. Used in conjunction with
> album-title.
>
>       * The element is identified by the class name track.
>       * hAudio MAY have one or more tracks, but MUST have album-title
>         defined. If album-title is not defined, track cannot be  
> defined.
>       * The element MUST be processed opaquely. No sub-elements should
>         be read from any hAudio contained in a track element.
>       * The contents of the element MAY be plain-text or marked up  
> using
>         hAudio.
>
> In Particular
>
> "hAudio MAY have one or more tracks, but MUST have album-title  
> defined.
> If album-title is not defined, track cannot be defined"
>
> ?
>
> What Happens when I want to mark up a single track from an Album  that
> may be part of a collection, best of, or compilation?
>
> I would Like to mark my page up like this:
>
> <div class="haudio">
> 	<div class="track">
>             <span class="audio-title">Spanish Bombs</span>
>             <abbr class="duration" title="P191T">3:18</abbr>
> 	    taken from the <span class="album-title">London Calling</span>  
> album
>             By <span class="contributor">The Clash</span>
>          </div>
>  	<div class="track">
> 	   <span class="audio-title">Nagasaki Nightmare</span>
>            <abbr class="duration" title="P268T">4:46</abbr>
> 	   taken from the <span class="album-title">Best Before 1984</ 
> span> album
> 	   By <span class="contributor">Crass</span>
>        </div>
> </div>
>
> Seems to make sense but according to the Proposal this Is Invalid  
> hAudio
>
> Maybe like this then?
>
> <div class="haudio">
> 	<div class="track">
>             <span class="audio-title">Spanish Bombs</span>
>             <abbr class="duration" title="P191T">3:18</abbr>
> 	</div>
> 	    taken from the <span class="album-title">London Calling</span>  
> album
>             By <span class="contributor">The Clash</span>
> </div>
>
> <div class="haudio">
>  	<div class="track">
> 	   <span class="audio-title">Nagasaki Nightmare</span>
>            <abbr class="duration" title="P268T">4:46</abbr>
>          </div>
> 	   taken from the <span class="album-title">Best Before 1984</ 
> span> album
> 	   By <span class="contributor">Crass</span>
> </div>
>
> Seems like valid hAudio but Is not because the contents of a hAudio
> track must either be marked up as text or as hAudio
>
> <div class="haudio">
> 	<div class="track haudio">
>             <span class="audio-title">Spanish Bombs</span>
>             <abbr class="duration" title="P191T">3:18</abbr>
> 	</div>
> 	    taken from the <span class="album-title">London Calling</span>
> album
>             By <span class="contributor">The Clash</span>
> </div>
>
> <div class="haudio">
>  	<div class="track haudio">
> 	   <span class="audio-title">Nagasaki Nightmare</span>
>            <abbr class="duration" title="P268T">4:46</abbr>
>          </div>
> 	   taken from the <span class="album-title">Best Before 1984</span>
> album
> 	   By <span class="contributor">Crass</span>
> </div>
>
> This Is  Valid hAudio my concerns are Do we really need to reiterate
> haudio In the track class It seems confusing that hAudio Is both a
> parent and a child class. used in the above context haudio has the  
> same
> meaning as track?
>
> I think the proposition should simply say
>
>       * "hAudio MAY have zero or more tracks"
>       * "Track titles MAY be defined by using the class name
>         *audio-title* it is recommended that a hAudio track SHOULD  
> have
>         an audio-title" *
>
> This would enable Greater flexibility when publishing hAudio.

To my understanding, you would mark it up like this:

<span class="haudio">
     <span class="audio-title">Nagasaki Nightmare</span>
     <abbr class="duration" title="P268T">4:46</abbr>
     taken from the <span class="album-title">Best Before 1984</span>  
album
     By <span class="contributor">Crass</span>
</span>

Because as long as audio-title is present in the haudio element, it  
would be a track.

If only album-title was present, it would be an album.

If both audio-title and album-title were present, it would be a  
single track from an album.

Examples:

Single track, with known album (same as putting text in the ?album?  
field of an ID3 tag):
<span class="haudio">
     <span class="audio-title">Nagasaki Nightmare</span>
     <span class="album-title">Best Before 1984</span>
     <span class="contributor">Crass</span>
</span>

Single track, album unknown:
<span class="haudio">
     <span class="audio-title">Nagasaki Nightmare</span>
     <span class="contributor">Crass</span>
</span>

Album:
<span class="haudio">
     <span class="album-title">Best Before 1984</span>
     <span class="contributor">Crass</span>
</span>

Album with a couple of tracks, simple example:
<span class="haudio">
     <span class="album-title">Best Before 1984</span>
     <span class="contributor">Crass</span>
     <span class="track">Nagasaki Nightmare</span>
     <span class="track">Nagasaki Nightmare</span>
     <span class="track">Nagasaki Nightmare</span>
</span>

Album with a couple of tracks, more detailed:
<span class="haudio">
     <span class="album-title">Best Before 1984</span>
     <span class="contributor">Crass</span>
     <span class="track haudio"><span class="audio-title">Nagasaki  
Nightmare</span> ? <abbr class="duration" title="P268T">4:46</abbr></ 
span>
     <span class="track haudio"><span class="audio-title">Nagasaki  
Nightmare</span> ? <abbr class="duration" title="P268T">4:46</abbr></ 
span>
     <span class="track haudio"><span class="audio-title">Nagasaki  
Nightmare</span> ? <abbr class="duration" title="P268T">4:46</abbr></ 
span>
</span>

From msporny at digitalbazaar.com  Mon Oct  8 20:33:47 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Mon Oct  8 20:36:36 2007
Subject: [uf-new] Closing several hAudio issues
In-Reply-To: <94F0EA16-7B03-4A69-9839-EF5A23370752@julianstahnke.com>
References: <470A53B4.8070408@digitalbazaar.com>	<1191885337.25159.56.camel@localhost.localdomain>
	<94F0EA16-7B03-4A69-9839-EF5A23370752@julianstahnke.com>
Message-ID: <470AF69B.8090907@digitalbazaar.com>

Julian Stahnke wrote:
>> Martin McEvoy wrote:
>> I think the proposition should simply say
>>
>>       * "hAudio MAY have zero or more tracks"
>>       * "Track titles MAY be defined by using the class name
>>         *audio-title* it is recommended that a hAudio track SHOULD have
>>         an audio-title" *
>>
>> This would enable Greater flexibility when publishing hAudio.
> 
> as long as audio-title is present in the haudio element, it
> would be a track.

This is correct... as long as audio-title is present in the hAudio
element, it is semantically indistinguishable from a "track". The
processing rules have been updated to make this more clear:

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

> If only album-title was present, it would be an album.
> 
> If both audio-title and album-title were present, it would be a single
> track from an album.

Also correct.

The benefit with the current hAudio proposal is that you don't need to
specify TRACK to identify the hAudio as a singular item... all you have
to do is specify AUDIO-TITLE. It's easier on publishers because there is
less HTML to write (you don't have to specify TRACK for individual
recordings).

To address your other concern, Martin, we might not have to specify
"track haudio". Instead, we could have:

 <div class="haudio">
  <div class="track">
    <span class="audio-title">Nagasaki Nightmare</span>
    <abbr class="duration" title="P268T">4:46</abbr>
  </div>
  and
  <span class="track">Bloody Revolution</span>
  taken from <span class="album-title">Best Before 1984</span>
  By <span class="contributor">Crass</span>
 </div>

I have to admit, though, that the above mark-up just doesn't sit well
with me. We have to assume that properties inside of TRACK are of type
hAudio and can use any of it's properties. In other words, we are
assuming the type of the contents of TRACK is an hAudio based on the
parent container, which is hAudio.

Perhaps others that have been involved with Microformats for longer than
I have been can point out the benefits or drawbacks of such an approach.

Here are the ones that I can see:

Pros:

* Less mark-up for publishers.
* Less confusing?

Cons:

* The type must be assumed from the parent container type.

-- manu
From msporny at digitalbazaar.com  Mon Oct  8 21:03:52 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Mon Oct  8 21:06:39 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
Message-ID: <470AFDA8.2080906@digitalbazaar.com>

One of the last remaining (and most pedantic) issues for hAudio is the
naming of the audio-title and album-title properties. This includes the
following issues (we could close them all if we can finally decide on
these two names):

hAudio ISSUE #2: audio-title Property
http://microformats.org/wiki/audio-info-issues#audio-title_Property

hAudio ISSUE #9: album-title Property
http://microformats.org/wiki/audio-info-issues#album-title_Property

hAudio ISSUE #10: Collection Names
http://microformats.org/wiki/audio-info-issues#Collection_Names

The primary issue that I have with audio-title and album-title is that
they are not orthogonal in the programming language sense:

http://www.lrdev.com/lr/frequently-asked-questions.html#programming-language-orthogonality

audio-title is the title of a singular/atomic audio expression. It is a
rather general term used to identify a singular work.

album-title is the title of an audio album. It is a specific term used
to identify a collection of singular works that are in an album/track
format.

To add to the complexity of the semantics behind these two terms, they
not only denote the title, but the type of the hAudio as well.

The question is: Can we make these terms more orthogonal to publishers.
Can we choose terms that denote both title and type. The first attempt
was to name them something like the following:

recording-title and album-title

The use of -title seemed a bit redundant, so it was dropped to form:

recording and album

Speaking and reading the words in context makes sense:

hAudio recording
hAudio album

whereas speaking and reading what we have currently doesn't really make
sense:

hAudio audio-title (specifies the recording title AND the hAudio type)
hAudio album-title (specifies the album title AND the hAudio type)

There is also only one example to back-up using the "*-title" pattern in
Microformats, that being ENTRY-TITLE in hAtom. There are, however, loads
of examples of taking the other approach, which is using nouns to denote
"title (type)":

author (Person), item (Thing), label (Identifier), locality (Place),
logo (Image), note (Text), photo (Image), summary (Text), region
(Place), reviewer (Person), sound (Sound), and title (Text) are a
handful of examples of nouns being used to denote title and type.

The best that we've been able to do has been RECORDING and ALBUM. Any
suggestions on addressing these issues?

-- manu

PS: Keep in mind that RECORDING can be re-used in hVideo.
From scott at makedatamakesense.com  Mon Oct  8 22:13:29 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Mon Oct  8 22:13:36 2007
Subject: [uf-new] Closing several hAudio issues
In-Reply-To: <470AF69B.8090907@digitalbazaar.com>
References: <470A53B4.8070408@digitalbazaar.com>	<1191885337.25159.56.camel@localhost.localdomain>
	<94F0EA16-7B03-4A69-9839-EF5A23370752@julianstahnke.com>
	<470AF69B.8090907@digitalbazaar.com>
Message-ID: <8F1CCD2F-A8D9-44B2-B2A3-E9EB9AE9E0DF@makedatamakesense.com>

On Oct 8, 2007, at 9:33 PM, Manu Sporny wrote:

>  <div class="haudio">
>   <div class="track">
>     <span class="audio-title">Nagasaki Nightmare</span>
>     <abbr class="duration" title="P268T">4:46</abbr>
>   </div>
>   and
>   <span class="track">Bloody Revolution</span>
>   taken from <span class="album-title">Best Before 1984</span>
>   By <span class="contributor">Crass</span>
>  </div>
>
> I have to admit, though, that the above mark-up just doesn't sit well
> with me. We have to assume that properties inside of TRACK are of type
> hAudio and can use any of it's properties. In other words, we are
> assuming the type of the contents of TRACK is an hAudio based on the
> parent container, which is hAudio.

Not only based on the parent container, but also based on the  
contained properties, because a track with no audio-title isn't  
hAudio.  So someone looking at an element with class="track" would  
need to look both at the parent elements and at the contents of the  
element to know what exactly "track" means.  I think it's simpler for  
track to always mean the same thing, and use the hAudio class to  
clearly indicate whether or not it's actually hAudio.  Similarly,  
hCard has an "agent" property, which can itself be another hCard, and  
we mark this with class="agent hcard".

--
Scott Reynen
MakeDataMakeSense.com


From andy at pigsonthewing.org.uk  Tue Oct  9 02:35:19 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Tue Oct  9 02:35:27 2007
Subject: [uf-new] Video, Closed Captions, and Audio Description Tracks
Message-ID: <24279.80.249.57.38.1191922519.squirrel@www.gradwell.com>

The BBC iPlayer apparently uses three downloads:

1. Standard.

2. BSL.

3. Audio described (almost twice the size of Standard).

All three have closed-captioning.

Source:

http://www.bbc.co.uk/blogs/access20/2007/05/audio_description_on_the_iplay.shtml

How can the proposed microformat(s) for TV streaming and video downloads
cater for captioning?

-- 
Andy Mabbett
** via webmail **

From lists at ben-ward.co.uk  Tue Oct  9 05:43:49 2007
From: lists at ben-ward.co.uk (Ben Ward)
Date: Tue Oct  9 05:43:56 2007
Subject: [uf-new] Pattern: Presence of Property
Message-ID: <6622F246-86D4-4763-B5F7-B6CCDB604454@ben-ward.co.uk>

Out of the Recipe format development happening on uf-new I came  
across an interested concept that hasn't come up yet in previous  
microformats:

Quoting Andy Mabbett, then myself:
>> Whether an ingredients is optional or required is important (again,
>> consider the "ingredients to hand" use case).
>
> Agreed, that's a very good use-case. Needs to be included in a  
> language-agnostic manner but writing ?3 sprigs of parsley  
> (optional)? is familiar. I would think that ?Required? is implied  
> by the absence of ?Optional?.

In this case, we have a property established for the format which is  
either present or absence. An ingredient is either optional or not.  
So, lets say you have this in English:

<span class="ingredient">3 Strawberries <span class="optional"> 
(optional)</span></span>

Or this in French:

<span class="ingredient" lang="fr">3 Le Strawberries <span  
class="optional">(en option)</span></span>

 From a parsing POV, we're only interested in whether ?optional? is  
present or not. If it's absent, we'd be assuming ?required?. We'd be  
using a pattern whereby the property value is determined from  
presence or absence of the element, not by the value of it.

Now of course this application is early days and we may yet find  
further requirements or different ways of doing it, but I like the  
idea of the pattern as it's language agnostic. Also, I think  
?Presence of Property? is a pretty snappy name.

What would people think about this sort of parsing rule being added  
to the microformats cannon?

Ben
From andy at pigsonthewing.org.uk  Tue Oct  9 06:15:51 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Tue Oct  9 06:16:15 2007
Subject: [uf-new] Pattern: Presence of Property
In-Reply-To: <6622F246-86D4-4763-B5F7-B6CCDB604454@ben-ward.co.uk>
References: <6622F246-86D4-4763-B5F7-B6CCDB604454@ben-ward.co.uk>
Message-ID: <38234.80.249.57.38.1191935751.squirrel@www.gradwell.com>

On Tue, October 9, 2007 13:43, Ben Ward wrote:
> say you have this in English:
>
> <span class="ingredient">3 Strawberries <span class="optional">
> (optional)</span></span>

Surely:

  <span class="ingredient optional">3 Strawberries (optional)</span>



From brian.suda at gmail.com  Tue Oct  9 06:21:51 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Tue Oct  9 06:21:54 2007
Subject: [uf-new] Pattern: Presence of Property
In-Reply-To: <6622F246-86D4-4763-B5F7-B6CCDB604454@ben-ward.co.uk>
References: <6622F246-86D4-4763-B5F7-B6CCDB604454@ben-ward.co.uk>
Message-ID: <21e770780710090621h7ce114cey1e83e13f789bc7fc@mail.gmail.com>

On 10/9/07, Ben Ward <lists@ben-ward.co.uk> wrote:
>  From a parsing POV, we're only interested in whether 'optional' is
> present or not. If it's absent, we'd be assuming 'required'. We'd be
> using a pattern whereby the property value is determined from
> presence or absence of the element, not by the value of it.
>
> Now of course this application is early days and we may yet find
> further requirements or different ways of doing it, but I like the
> idea of the pattern as it's language agnostic. Also, I think
> 'Presence of Property' is a pretty snappy name.
>
> What would people think about this sort of parsing rule being added
> to the microformats cannon?

--- i don?t think a binary true/false should be used as a class
attribute. This brings us back to SHOULD, MUST, MAY, you MAY use this
or you MAY NOT. Optional might not be a binary relationship.

Your example could become:
<span><span class="ingredient optional">3 Strawberries</span> (optional)</span>
And we are back to hiding data.

using the TYPE we can make an enumerated list of OPTIONAL, REQUIRED,
MAY, RECOMMENDED, REPLACABLE, SUBSTITUDE, etc.

-brian

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

From scott at makedatamakesense.com  Tue Oct  9 06:45:40 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Tue Oct  9 06:45:46 2007
Subject: [uf-new] Pattern: Presence of Property
In-Reply-To: <6622F246-86D4-4763-B5F7-B6CCDB604454@ben-ward.co.uk>
References: <6622F246-86D4-4763-B5F7-B6CCDB604454@ben-ward.co.uk>
Message-ID: <F9575B07-BCBE-44A9-81E0-34D43931A142@makedatamakesense.com>

On Oct 9, 2007, at 6:43 AM, Ben Ward wrote:

> <span class="ingredient">3 Strawberries <span class="optional"> 
> (optional)</span></span>
>
> What would people think about this sort of parsing rule being added  
> to the microformats cannon?

I don't like how that reads.  The HTML spec says of the class  
attribute "the element may be said to belong to these classes" [1],  
but I don't think that's true in this case.  We would say "3  
Strawberries (optional)" belongs to the class of ingredient but we  
would not say "(optional)" belongs to the class of optional.  "3  
Strawberries" belongs to that class, which would give us this:

<span class="ingredient optional">3 Strawberries</span> (optional)

But that also gets into repeating ourselves.  Alternatively, I think  
it may be better to say that "(optional)" belongs to a class of  
dispensability, giving us this:

<span class="ingredient">3 Strawberries <span class="dispensability"> 
(optional)</span></span>

And maybe some parsers could assume any amount of dispensability  
makes something entirely optional, but others may choose to present  
the specific level of dispensability to users directly, as it may  
contain more specific information.

[1] http://www.w3.org/TR/html401/struct/global.html#h-7.5.2

--
Scott Reynen
MakeDataMakeSense.com
From martin at weborganics.co.uk  Tue Oct  9 13:22:24 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Tue Oct  9 13:22:19 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <470AFDA8.2080906@digitalbazaar.com>
References: <470AFDA8.2080906@digitalbazaar.com>
Message-ID: <1191961345.29452.39.camel@localhost.localdomain>

Hello Manu

On Tue, 2007-10-09 at 00:03 -0400, Manu Sporny wrote:
> One of the last remaining (and most pedantic) issues for hAudio is the
> naming of the audio-title and album-title properties. This includes the
> following issues (we could close them all if we can finally decide on
> these two names):
> 
> hAudio ISSUE #2: audio-title Property
> http://microformats.org/wiki/audio-info-issues#audio-title_Property
> 
> hAudio ISSUE #9: album-title Property
> http://microformats.org/wiki/audio-info-issues#album-title_Property
> 
> hAudio ISSUE #10: Collection Names
> http://microformats.org/wiki/audio-info-issues#Collection_Names
> 
> The primary issue that I have with audio-title and album-title is that
> they are not orthogonal in the programming language sense:
> 
> http://www.lrdev.com/lr/frequently-asked-questions.html#programming-language-orthogonality
> 
> audio-title is the title of a singular/atomic audio expression. It is a
> rather general term used to identify a singular work.
> 
> album-title is the title of an audio album. It is a specific term used
> to identify a collection of singular works that are in an album/track
> format.
> 
> To add to the complexity of the semantics behind these two terms, they
> not only denote the title, but the type of the hAudio as well.
> 
> The question is: Can we make these terms more orthogonal to publishers.
> Can we choose terms that denote both title and type. The first attempt
> was to name them something like the following:
> 
> recording-title and album-title
> 
> The use of -title seemed a bit redundant, so it was dropped to form:
> 
> recording and album
> 
> Speaking and reading the words in context makes sense:
> 
> hAudio recording
> hAudio album
> 
> whereas speaking and reading what we have currently doesn't really make
> sense:
> 
> hAudio audio-title (specifies the recording title AND the hAudio type)
> hAudio album-title (specifies the album title AND the hAudio type)
> 
> There is also only one example to back-up using the "*-title" pattern in
> Microformats, that being ENTRY-TITLE in hAtom. There are, however, loads
> of examples of taking the other approach, which is using nouns to denote
> "title (type)":
> 
> author (Person), item (Thing), label (Identifier), locality (Place),
> logo (Image), note (Text), photo (Image), summary (Text), region
> (Place), reviewer (Person), sound (Sound), and title (Text) are a
> handful of examples of nouns being used to denote title and type.
> 
> The best that we've been able to do has been RECORDING and ALBUM. Any
> suggestions on addressing these issues?

In Principle I agree with you certainly *album-title* and *audio-title*
don't seem to sit right and are causing some problems as regards naming
and definition, we do have to resolve these issues. Also *track* to me
is causing similar concerns.

+1 for changing album-title to just album because on its own it is both
type and title

My concern is "recording" although the name suggests type and title, I
dont think it is specific enough Its still a very loose term to describe
what actually may be a recording or just the title itself. 

I know I have brought up that we re use ITEM from hReview before on the
list but I guess I didnt explain my reasoning correctly, and I never
really understood why It is that we cant use ITEM, because from what i
can glean from the wiki and how people use it in other formats such as
rss It seems to do exactly what we need.
So please consider again.

so another attempt at simplifying hAudio using my previous example

<div class="haudio">
	<span class="album">Best Before 1984</span>
	By <span class="contributor">Crass</span>
[...]
    <div class="item">
        <span class="track">Nagasaki Nightmare</span> 
        <abbr class="duration" title="P268T">4:46</abbr>
    </div>

    <div class="item">
        <span class="track">Big A, Little A </span> 
        <abbr class="duration" title="P368T"> 6:13</abbr>
    </div>
[...]
</div>

If we were to do this in hReview the markup would be..

[...]
  <div class="item">
    <span class="fn">Nagasaki Nightmare</span>
    <abbr class="duration" title="P268T">4:46</abbr>
  </div>
[...]

The above markup does seem to make hAudio compact and clean no confusion
about what our hAudio properties mean?

Comments?

Thanks

Martin

> 
> -- manu
> 
> PS: Keep in mind that RECORDING can be re-used in hVideo.
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From martin at weborganics.co.uk  Tue Oct  9 13:27:48 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Tue Oct  9 13:27:12 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <1191961345.29452.39.camel@localhost.localdomain>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
Message-ID: <1191961668.29452.41.camel@localhost.localdomain>

On Tue, 2007-10-09 at 21:22 +0100, Martin McEvoy wrote:
> If we were to do this in hReview the markup would be..
> 
> [...]
>   <div class="item">
>     <span class="fn">Nagasaki Nightmare</span>
>     <abbr class="duration" title="P268T">4:46</abbr>
>   </div>
> [...] 

sorry rubbish markup

[...]
  <div class="item">
    <span class="fn">Nagasaki Nightmare</span>
  </div>
[...]

duration has nothing to do with hReview

:)

Thanks

Martin

From paul_wilkins at xtra.co.nz  Wed Oct 10 03:48:52 2007
From: paul_wilkins at xtra.co.nz (paul_wilkins@xtra.co.nz)
Date: Wed Oct 10 03:48:58 2007
Subject: [uf-new] Re: I propose a new microformat for poems.
Message-ID: <58180.29567.qm@web96006.mail.aue.yahoo.com>

From: Scott Reynen <scott@makedatamakesense.com>
> Clearly identifying those "other things" would probably help.  What  
> exactly is the problem we're trying to solve here?

When the content is in a pre tag, there can be issues with word-wrapping, or not wrapping as the case may be.


The purpose of the pre tag is to say that the spacing is predefined, within the content of the pre element itself.
When there is no special spacing, which is the case for a majority of poetry, the use of the pre tag becomes redundant.

Using linebreak tags or other structures provide additional structural information about the content that isn't available with pre tags.

And, we should be able to apply class names to whatever code structure we are currently using for poetry, rather than restricting everyone to using a certain element.

These are the issues I have with using the pre tag to markup all poetry.

-- 
Paul Wilkins







From scott at makedatamakesense.com  Wed Oct 10 06:39:55 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Wed Oct 10 06:40:05 2007
Subject: [uf-new] Re: I propose a new microformat for poems.
In-Reply-To: <58180.29567.qm@web96006.mail.aue.yahoo.com>
References: <58180.29567.qm@web96006.mail.aue.yahoo.com>
Message-ID: <255DC7CF-DB0D-4B26-82C9-78242B9953D2@makedatamakesense.com>

On Oct 10, 2007, at 4:48 AM, paul_wilkins@xtra.co.nz wrote:

>> Clearly identifying those "other things" would probably help.  What
>> exactly is the problem we're trying to solve here?
>
> When the content is in a pre tag, there can be issues with word- 
> wrapping, or not wrapping as the case may be.
>
> The purpose of the pre tag is to say that the spacing is  
> predefined, within the content of the pre element itself.
> When there is no special spacing, which is the case for a majority  
> of poetry, the use of the pre tag becomes redundant.
>
> Using linebreak tags or other structures provide additional  
> structural information about the content that isn't available with  
> pre tags.
>
> And, we should be able to apply class names to whatever code  
> structure we are currently using for poetry, rather than  
> restricting everyone to using a certain element.
>
> These are the issues I have with using the pre tag to markup all  
> poetry.

Sorry, that didn't really answer my question at all.  Why do you want  
to apply class names to your poetry in the first place?  What's the  
problem you're trying to solve with that?  We should avoid wasting  
our time on semantics for semantics' sake.

--
Scott Reynen
MakeDataMakeSense.com


From paul_wilkins at xtra.co.nz  Wed Oct 10 11:44:50 2007
From: paul_wilkins at xtra.co.nz (paul_wilkins@xtra.co.nz)
Date: Wed Oct 10 11:44:54 2007
Subject: [uf-new] Re: I propose a new microformat for poems.
Message-ID: <111656.92075.qm@web96011.mail.aue.yahoo.com>

From: Scott Reynen <scott@makedatamakesense.com>
> Sorry, that didn't really answer my question at all.  Why do you want  
> to apply class names to your poetry in the first place?  What's the  
> problem you're trying to solve with that?  We should avoid wasting  
> our time on semantics for semantics' sake.

I think there's a misunderstanding going on here.

I'm not proposing a new microformat, that was someone else who started this ball rolling.

I'm just putting my bit in to say that the proposed pre tag is not a catch-all answer.

-- 
Paul Wilkins




From jeremyboggs at gmail.com  Wed Oct 10 17:51:11 2007
From: jeremyboggs at gmail.com (Jeremy Boggs)
Date: Wed Oct 10 17:51:15 2007
Subject: [uf-new] course syllabus markup or microformat?
In-Reply-To: <519fa62f0710071658g2a7dd341q7be3695b125f4d0f@mail.gmail.com>
References: <mailman.3058.1191801384.30172.microformats-new@microformats.org>
	<519fa62f0710071658g2a7dd341q7be3695b125f4d0f@mail.gmail.com>
Message-ID: <b42f987d0710101751w572645f5ydba9eb9375bc5693@mail.gmail.com>

On 10/7/07, Jeff McNeill <jeff@jeffmcneill.com> wrote:

> Wondering if there is any work on microformat or markup of a course
> syllabus? Any and all suggestions solicited.

There's no work AFAIK, but I'm interested in researching the topic.
I've thought a bit about it, and have implemented microformats in my
course websites. (I teach an undergraduate US History survey at George
Mason University).

Most of the content of your email seems like a good start for a
syllabi-examples wiki page, unless other in the Microformats community
think otherwise.

>
> Problem statement:
>  * Syllabi are a source of much labor by instructors and much
> discussion and concern by students in higher education. Yet there
> appears to be no standard format either within or across colleges,
> disciplines, or courses. Reuse is based on copy-and-paste,
> word-of-mouth and serendipitous use of Google. With over 2 million
> undergraduate degrees awarded yearly in the United States alone, there
> is a large and growing population which use this document format. With
> the increasing demand for assessment of higher education (Spellings
> report, etc.), the humble syllabus is gaining in prominence.
>
> Initial information-gathering:
> * A cursory review of 14 syllabi of a similar course (undergraduate
> organizational communication), across a number of universities reveals
> a large amount of common information.

One tool that might be useful for research is Syllabus Finder.[2] It
searches over 500,000 syllabi on Google.

>  * It appears that hCard, hCalendar, and citation/bibliographic
> microformats may be usefully deployed in this endeavor.

Agreed. I use hCard for my contact information. I use hCalendar for my
course schedule, and include a link to subscribe to the schedule. I
also mark up my reading assignments with citation microformat.[3]

Additionally, I use XOXO for my presentation slides, using Eric
Meyer's S5,[4] and hAtom for marking up my course weblog. My
presentations aren't in my syllabus per se, but are included in my
course website in general.

In other cases, I've used POSH, like adding class="assignment reading"
or class="assignment writing" for assignments and assignment types.

>
> Other efforts:
> * SylViA is a Berkeley iSchool masters project, but is specific only
> to one school:
> http://groups.sims.berkeley.edu/sylvia/docs/schema/syllabus_schema.xsd
>

Some friends and I have also developed a WordPress plugin, called
ScholarPress Courseware, that allows an instructor to add syllabus
content to a WordPress blog: contact information, schedules,
bibliographies, assignments. My course website uses this plugin. I
plan to release it soon, once I iron out the wrinkles and get over the
jitters of releasing a new plugin ;) If anyone's interested in trying
it out, feel free to contact me off-list.

Best,
Jeremy

[1] http://clioweb.org/courses/history120/fall07/
[2] http://chnm.gmu.edu/tools/syllabi/
[3] http://clioweb.org/courses/history120/fall07/schedule/.


-- 
Jeremy Boggs
Creative Lead, Center for History and New Media
George Mason University
4400 University Drive, MSN 1E7
Fairfax, VA 22030-4444
http://chnm.gmu.edu
--
From msporny at digitalbazaar.com  Fri Oct 12 11:24:09 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Oct 12 11:24:16 2007
Subject: [uf-new] Mapping Microformats to RDFa
Message-ID: <470FBBC9.9060609@digitalbazaar.com>

We've started an initiative to map all of the current Microformats that
are in the draft or spec stage to RDFa vocabularies.

The goal is to identify deficiencies in RDFa vocabularies and create a
plan to fill those gaps in the next 6 months. It is also an interesting
exercise to see what differences exist between Microformats and RDF
vocabularies.

This builds upon the work that Danny Ayers (he helped with hCard,
hReview, hAudio, and hAtom to name a few) did in 2005 with his
MicroModels[1] approach to the semantic web. It is also an attempt to
help the GRDDL people out:

http://wiki.digitalbazaar.com/en/mapping-ufs-to-rdfa

-- manu

[1] http://esw.w3.org/topic/MicroModels
From martin at weborganics.co.uk  Fri Oct 12 11:36:17 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Oct 12 11:35:31 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <1191961345.29452.39.camel@localhost.localdomain>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
Message-ID: <1192214178.25526.2.camel@localhost.localdomain>

So we leave album-title and audio-title as it is?

Or are we going to talk about it?


Thanks

Martin

On Tue, 2007-10-09 at 21:22 +0100, Martin McEvoy wrote:
> Hello Manu
> 
> On Tue, 2007-10-09 at 00:03 -0400, Manu Sporny wrote:
> > One of the last remaining (and most pedantic) issues for hAudio is the
> > naming of the audio-title and album-title properties. This includes the
> > following issues (we could close them all if we can finally decide on
> > these two names):
> > 
> > hAudio ISSUE #2: audio-title Property
> > http://microformats.org/wiki/audio-info-issues#audio-title_Property
> > 
> > hAudio ISSUE #9: album-title Property
> > http://microformats.org/wiki/audio-info-issues#album-title_Property
> > 
> > hAudio ISSUE #10: Collection Names
> > http://microformats.org/wiki/audio-info-issues#Collection_Names
> > 
> > The primary issue that I have with audio-title and album-title is that
> > they are not orthogonal in the programming language sense:
> > 
> > http://www.lrdev.com/lr/frequently-asked-questions.html#programming-language-orthogonality
> > 
> > audio-title is the title of a singular/atomic audio expression. It is a
> > rather general term used to identify a singular work.
> > 
> > album-title is the title of an audio album. It is a specific term used
> > to identify a collection of singular works that are in an album/track
> > format.
> > 
> > To add to the complexity of the semantics behind these two terms, they
> > not only denote the title, but the type of the hAudio as well.
> > 
> > The question is: Can we make these terms more orthogonal to publishers.
> > Can we choose terms that denote both title and type. The first attempt
> > was to name them something like the following:
> > 
> > recording-title and album-title
> > 
> > The use of -title seemed a bit redundant, so it was dropped to form:
> > 
> > recording and album
> > 
> > Speaking and reading the words in context makes sense:
> > 
> > hAudio recording
> > hAudio album
> > 
> > whereas speaking and reading what we have currently doesn't really make
> > sense:
> > 
> > hAudio audio-title (specifies the recording title AND the hAudio type)
> > hAudio album-title (specifies the album title AND the hAudio type)
> > 
> > There is also only one example to back-up using the "*-title" pattern in
> > Microformats, that being ENTRY-TITLE in hAtom. There are, however, loads
> > of examples of taking the other approach, which is using nouns to denote
> > "title (type)":
> > 
> > author (Person), item (Thing), label (Identifier), locality (Place),
> > logo (Image), note (Text), photo (Image), summary (Text), region
> > (Place), reviewer (Person), sound (Sound), and title (Text) are a
> > handful of examples of nouns being used to denote title and type.
> > 
> > The best that we've been able to do has been RECORDING and ALBUM. Any
> > suggestions on addressing these issues?
> 
> In Principle I agree with you certainly *album-title* and *audio-title*
> don't seem to sit right and are causing some problems as regards naming
> and definition, we do have to resolve these issues. Also *track* to me
> is causing similar concerns.
> 
> +1 for changing album-title to just album because on its own it is both
> type and title
> 
> My concern is "recording" although the name suggests type and title, I
> dont think it is specific enough Its still a very loose term to describe
> what actually may be a recording or just the title itself. 
> 
> I know I have brought up that we re use ITEM from hReview before on the
> list but I guess I didnt explain my reasoning correctly, and I never
> really understood why It is that we cant use ITEM, because from what i
> can glean from the wiki and how people use it in other formats such as
> rss It seems to do exactly what we need.
> So please consider again.
> 
> so another attempt at simplifying hAudio using my previous example
> 
> <div class="haudio">
> 	<span class="album">Best Before 1984</span>
> 	By <span class="contributor">Crass</span>
> [...]
>     <div class="item">
>         <span class="track">Nagasaki Nightmare</span> 
>         <abbr class="duration" title="P268T">4:46</abbr>
>     </div>
> 
>     <div class="item">
>         <span class="track">Big A, Little A </span> 
>         <abbr class="duration" title="P368T"> 6:13</abbr>
>     </div>
> [...]
> </div>
> 
> If we were to do this in hReview the markup would be..
> 
> [...]
>   <div class="item">
>     <span class="fn">Nagasaki Nightmare</span>
>     <abbr class="duration" title="P268T">4:46</abbr>
>   </div>
> [...]
> 
> The above markup does seem to make hAudio compact and clean no confusion
> about what our hAudio properties mean?
> 
> Comments?
> 
> Thanks
> 
> Martin
> 
> > 
> > -- manu
> > 
> > PS: Keep in mind that RECORDING can be re-used in hVideo.
> > _______________________________________________
> > microformats-new mailing list
> > microformats-new@microformats.org
> > http://microformats.org/mailman/listinfo/microformats-new

From msporny at digitalbazaar.com  Fri Oct 12 12:30:36 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Oct 12 12:30:42 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <1192214178.25526.2.camel@localhost.localdomain>
References: <470AFDA8.2080906@digitalbazaar.com>	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
Message-ID: <470FCB5C.9070802@digitalbazaar.com>

Martin McEvoy wrote:
> So we leave album-title and audio-title as it is?
> Or are we going to talk about it?

I was giving others at least a week to weigh in on the issue if they
wanted to... didn't want to front-load the discussion. :)

It is looking more and more like audio-title and album-title are going
to stick. If I'm the only one that really has an issue with it, that is
not a good reason to change it. I've made my argument and unless
somebody else steps forward to support changing it, it'll remain as is
(audio-title and album-title).

What is important is that we move hAudio to draft stage and I'm willing
to drop my proposal in order to do that... in the name of progress. :)

> +1 for changing album-title to just album because on its own it is
> both type and title

I don't think we can change just album... both of them would have to
change because the semantics behind both of them are the same. I think
the only viable options are:

audio-title and album-title
recording and album

> My concern is "recording" although the name suggests type and title, I
> dont think it is specific enough Its still a very loose term to
> describe what actually may be a recording or just the title itself.

In context, I believe that it makes sense. Remember, hAudio is the
top-level element, so they already know it's related to audio. I guess
we could do:

recording-title and album-title

which could be read as:

haudio recording-title and haudio album-title

and could be re-used in hvideo as:

hvideo recording-title

I believe we should chop off "-title", but I also admit that I'm being
pedantic... and it really isn't going to slow adoption.

> so another attempt at simplifying hAudio using my previous example
>
> <div class="haudio">
> 	<span class="album">Best Before 1984</span>
> 	By <span class="contributor">Crass</span>
> [...]
>     <div class="item">
>         <span class="track">Nagasaki Nightmare</span>
>         <abbr class="duration" title="P268T">4:46</abbr>
>     </div>
>
>     <div class="item">
>         <span class="track">Big A, Little A </span>
>         <abbr class="duration" title="P368T"> 6:13</abbr>
>     </div>
> [...]
> </div>

Item has already been defined as:

  item required. fn (url || photo ) | hCard (for person or business) |
                 hCalendar (for event)

Even if we were able to add "hAudio (for recording)" to the list of
allowables in hReview, we would be back to your issue of having to put
"item haudio" in the same class name, OR hAudio not being able to be
defined in tables. TRACK also more accurately describes what we're
talking about... and audio track.

The strongest argument for ITEM, assuming that it can contain hAudio, is
that we could re-use it in most of the other formats to denote a
sub-part of the higher-level Microformat. Who created ITEM in this
community, perhaps they have some insight?

-- manu

From brian.suda at gmail.com  Fri Oct 12 12:37:15 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Fri Oct 12 12:37:20 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <470FCB5C.9070802@digitalbazaar.com>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
Message-ID: <21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>

On 10/12/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> Martin McEvoy wrote:
> > So we leave album-title and audio-title as it is?
> > Or are we going to talk about it?
>
> I was giving others at least a week to weigh in on the issue if they
> wanted to... didn't want to front-load the discussion. :)

--- i was under the impression this was still an open issue that is
already solved with FN. I was unaware this was still a discussion
point.

-brian

-- 
brian suda
http://suda.co.uk
From msporny at digitalbazaar.com  Fri Oct 12 13:01:35 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Oct 12 13:01:41 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
References: <470AFDA8.2080906@digitalbazaar.com>	<1191961345.29452.39.camel@localhost.localdomain>	<1192214178.25526.2.camel@localhost.localdomain>	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
Message-ID: <470FD29F.3060107@digitalbazaar.com>

Brian Suda wrote:
> On 10/12/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
>> Martin McEvoy wrote:
>>> So we leave album-title and audio-title as it is?
>>> Or are we going to talk about it?
>> I was giving others at least a week to weigh in on the issue if they
>> wanted to... didn't want to front-load the discussion. :)
> 
> --- i was under the impression this was still an open issue that is
> already solved with FN. I was unaware this was still a discussion
> point.

FN doesn't solve the problem because the examples demonstrate that the
type of the hAudio, whether the item is an audio track or audio album,
is never explicitly stated, but is instead implied by the markup.

Therefore, we need at least two properties that imply both type and title.

If we were to use FN, it would be impossible to distinguish between an
album (an concept that can contain more than one hAudio) and a
song/speech (an individual hAudio).

Got any suggestions as to how we imply that an hAudio is either a single
work (song/speech/sound effect), or a collection of works (album)?

-- manu
From scott at makedatamakesense.com  Fri Oct 12 13:41:28 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Fri Oct 12 13:41:34 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <470FD29F.3060107@digitalbazaar.com>
References: <470AFDA8.2080906@digitalbazaar.com>	<1191961345.29452.39.camel@localhost.localdomain>	<1192214178.25526.2.camel@localhost.localdomain>	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
Message-ID: <B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>

On Oct 12, 2007, at 2:01 PM, Manu Sporny wrote:

> If we were to use FN, it would be impossible to distinguish between an
> album (an concept that can contain more than one hAudio) and a
> song/speech (an individual hAudio).

I don't think that's true.  hCard uses FN for two different types of  
contacts: organizations and people.  The main item's name is  
class="fn".  If that main item is an organization, it's class="fn  
org".  If the main item is a person within a stated organization, the  
person's name is class="fn" and the organization's class="org".   
hAudio is only slightly more complicated because we can also have an  
album with several tracks, whereas we never use a single hCard to  
list an organization and several members.  For that case we could  
still use "track".  Examples of how this might work based on Julian's  
earlier examples:

Single track, with known album (same as putting text in the ?album?  
field of an ID3 tag):
<span class="haudio">
     <span class="fn">Nagasaki Nightmare</span>
     <span class="album">Best Before 1984</span>
     <span class="contributor">Crass</span>
</span>

Single track, album unknown:
<span class="haudio">
     <span class="fn">Nagasaki Nightmare</span>
     <span class="contributor">Crass</span>
</span>

Album:
<span class="haudio">
     <span class="fn album">Best Before 1984</span>
     <span class="contributor">Crass</span>
</span>

Album with a couple of tracks, simple example:
<span class="haudio">
     <span class="fn album">Best Before 1984</span>
     <span class="contributor">Crass</span>
     <span class="track">Nagasaki Nightmare</span>
     <span class="track">Nagasaki Nightmare</span>
     <span class="track">Nagasaki Nightmare</span>
</span>

Album with a couple of tracks, more detailed:
<span class="haudio">
     <span class="fn album">Best Before 1984</span>
     <span class="contributor">Crass</span>
     <span class="track haudio"><span class="fn">Nagasaki Nightmare</ 
span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
     <span class="track haudio"><span class="fn">Nagasaki Nightmare</ 
span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
     <span class="track haudio"><span class="fn">Nagasaki Nightmare</ 
span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
</span>

--
Scott Reynen
MakeDataMakeSense.com



From martin at weborganics.co.uk  Fri Oct 12 16:26:16 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Oct 12 16:25:29 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
Message-ID: <1192231576.25526.35.camel@localhost.localdomain>

On Fri, 2007-10-12 at 14:41 -0600, Scott Reynen wrote:
> On Oct 12, 2007, at 2:01 PM, Manu Sporny wrote:
> 
> > If we were to use FN, it would be impossible to distinguish between an
> > album (an concept that can contain more than one hAudio) and a
> > song/speech (an individual hAudio).
> 
> I don't think that's true.  hCard uses FN for two different types of  
> contacts: organizations and people.  The main item's name is  
> class="fn".  If that main item is an organization, it's class="fn  
> org".  If the main item is a person within a stated organization, the  
> person's name is class="fn" and the organization's class="org".   
> hAudio is only slightly more complicated because we can also have an  
> album with several tracks, whereas we never use a single hCard to  
> list an organization and several members.  For that case we could  
> still use "track".  Examples of how this might work based on Julian's  
> earlier examples:
> 
> Single track, with known album (same as putting text in the ?album?  
> field of an ID3 tag):
> <span class="haudio">
>      <span class="fn">Nagasaki Nightmare</span>
>      <span class="album">Best Before 1984</span>
>      <span class="contributor">Crass</span>
> </span>
> 
> Single track, album unknown:
> <span class="haudio">
>      <span class="fn">Nagasaki Nightmare</span>
>      <span class="contributor">Crass</span>
> </span>
> 
> Album:
> <span class="haudio">
>      <span class="fn album">Best Before 1984</span>
>      <span class="contributor">Crass</span>
> </span>
> 
> Album with a couple of tracks, simple example:
> <span class="haudio">
>      <span class="fn album">Best Before 1984</span>
>      <span class="contributor">Crass</span>
>      <span class="track">Nagasaki Nightmare</span>
>      <span class="track">Nagasaki Nightmare</span>
>      <span class="track">Nagasaki Nightmare</span>
> </span>
> 
> Album with a couple of tracks, more detailed:
> <span class="haudio">
>      <span class="fn album">Best Before 1984</span>
>      <span class="contributor">Crass</span>
>      <span class="track haudio"><span class="fn">Nagasaki Nightmare</ 
> span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
>      <span class="track haudio"><span class="fn">Nagasaki Nightmare</ 
> span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
>      <span class="track haudio"><span class="fn">Nagasaki Nightmare</ 
> span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> </span>

Hello Scott I have been thinking recently that it is perhaps best to use
something that everyone is familiar with *FN* but I thought that it
would be simpler just to use *track* to imply type and title I also
don't think it is best practice to embed haudios *inside* haudio, I
think of it like a hfeed element in hAtom or the Channel element in RSS,
also would you embed hfeed's inside other hfeed's?

David Janes made some good proposal back in November about a hTing uF

http://microformats.org/discuss/mail/microformats-discuss/2006-November/007139.html

which eventually turned into a hItem design pattern/uF proposed by Andy
Mabbett

http://microformats.org/discuss/mail/microformats-discuss/2006-November/007281.html

there is a brainstorm about the hItem uf/item design pattern

http://microformats.org/wiki/items-brainstorming


So I thought simple solution

<div class="haudio">
	<span class="album">Best Before 1984</span>
	<span class="contributor">Crass</span>
    <div class="item">
        <span class="track">Nagasaki Nightmare</span>
	<abbr class="duration" title="P268T">4:46</abbr>
    </div>
    <div class="item">
        <span class="track">Big A, Little A </span> 
        <abbr class="duration" title="P368T"> 6:13</abbr>
    </div>
  </div>
</div> 

Elegant I would say?

It solves the problem of do we use FN audio-title, whatever...
We have established that we cant use FN because want to describe
something MORE specific 

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

And also we dont need to use either FN or audio-title because
track I understand has to have the exact semantic value as album 
The example above shows how to clearly define both track and album


Comments?


Thanks

Martin


> 
> --
> Scott Reynen
> MakeDataMakeSense.com
> 
> 
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From martin at weborganics.co.uk  Fri Oct 12 16:46:32 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Oct 12 16:45:45 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <1192231576.25526.35.camel@localhost.localdomain>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<1192231576.25526.35.camel@localhost.localdomain>
Message-ID: <1192232792.25526.38.camel@localhost.localdomain>

On Sat, 2007-10-13 at 00:26 +0100, Martin McEvoy wrote:
> think of it like a hfeed element in hAtom or the Channel element in
> RSS,
> also would you embed hfeed's inside other hfeed's? 

Hmm thats not perhaps correct :) more like entry's

Thanks

Martin 

From martin at weborganics.co.uk  Fri Oct 12 16:54:23 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Oct 12 16:53:33 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <1192231576.25526.35.camel@localhost.localdomain>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<1192231576.25526.35.camel@localhost.localdomain>
Message-ID: <1192233263.27585.2.camel@localhost.localdomain>

On Sat, 2007-10-13 at 00:26 +0100, Martin McEvoy wrote:
> <div class="haudio">
>         <span class="album">Best Before 1984</span>
>         <span class="contributor">Crass</span>
>     <div class="item">
>         <span class="track">Nagasaki Nightmare</span>
>         <abbr class="duration" title="P268T">4:46</abbr>
>     </div>
>     <div class="item">
>         <span class="track">Big A, Little A </span> 
>         <abbr class="duration" title="P368T"> 6:13</abbr>
>     </div>
>   </div>
> </div>  

I am making an ass of myself tonight sorry one too many </div> 
I should learn to check my copy and pasting.

Oh well I guess you guys are used to me now :)

Martin

From msporny at digitalbazaar.com  Fri Oct 12 20:39:45 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Oct 12 20:39:49 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
References: <470AFDA8.2080906@digitalbazaar.com>	<1191961345.29452.39.camel@localhost.localdomain>	<1192214178.25526.2.camel@localhost.localdomain>	<470FCB5C.9070802@digitalbazaar.com>	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
Message-ID: <47103E01.8010908@digitalbazaar.com>

Scott Reynen wrote:
> On Oct 12, 2007, at 2:01 PM, Manu Sporny wrote:
>> If we were to use FN, it would be impossible to distinguish between an
>> album (an concept that can contain more than one hAudio) and a
>> song/speech (an individual hAudio).
> 
> I don't think that's true.  hCard uses FN for two different types of
> contacts: organizations and people.  The main item's name is
> class="fn".  If that main item is an organization, it's class="fn org". 
> 
> Single track, with known album (same as putting text in the ?album?
> field of an ID3 tag):
> <span class="haudio">
>     <span class="fn">Nagasaki Nightmare</span>
>     <span class="album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
> </span>
> 
> Single track, album unknown:
> <span class="haudio">
>     <span class="fn">Nagasaki Nightmare</span>
>     <span class="contributor">Crass</span>
> </span>
> 
> Album:
> <span class="haudio">
>     <span class="fn album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
> </span>
> 
> Album with a couple of tracks, simple example:
> <span class="haudio">
>     <span class="fn album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
>     <span class="track">Nagasaki Nightmare</span>
>     <span class="track">Nagasaki Nightmare</span>
>     <span class="track">Nagasaki Nightmare</span>
> </span>
> 
> Album with a couple of tracks, more detailed:
> <span class="haudio">
>     <span class="fn album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
>     <span class="track haudio"><span class="fn">Nagasaki
> Nightmare</span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
>     <span class="track haudio"><span class="fn">Nagasaki
> Nightmare</span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
>     <span class="track haudio"><span class="fn">Nagasaki
> Nightmare</span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> </span>

Scott... this is fantastic! Thank you for proving me wrong! :)

I think this is our front-runner for replacing audio-title and
album-title. Finally! It re-uses FN without being ambiguous about the
difference between a single audio recording and an album. We
simultaneously remove the need for audio-title. Does this also work for
the Suda-nator (Brian Suda)?

Martin, can you post some markup for the same 5 examples above using
your proposal? We'll weigh the pros/cons for Scott's proposal and your
proposal... I'm dropping my proposal in preference of Scott's.

-- manu

From scott at makedatamakesense.com  Fri Oct 12 23:18:49 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Fri Oct 12 23:48:10 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <47103E01.8010908@digitalbazaar.com>
References: <470AFDA8.2080906@digitalbazaar.com>	<1191961345.29452.39.camel@localhost.localdomain>	<1192214178.25526.2.camel@localhost.localdomain>	<470FCB5C.9070802@digitalbazaar.com>	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<47103E01.8010908@digitalbazaar.com>
Message-ID: <F422DFB0-70BE-4B70-9930-BB80DAFB4EAC@makedatamakesense.com>

On Oct 12, 2007, at 9:39 PM, Manu Sporny wrote:

> Martin, can you post some markup for the same 5 examples above using
> your proposal?

Yeah, I'd like that too, Martin.  It seems to me you're making  
several proposals at once, and I'm not able to conceptually separate  
them enough to understand and respond.  Examples of the various types  
Julian posted earlier (single track with album, single track without  
album, single album without tracks, single album with simple tracks,  
and single album with detailed tracks) would help clarify for me  
exactly how you see it all fitting together.

--
Scott Reynen
MakeDataMakeSense.com


From julian at julianstahnke.com  Sat Oct 13 03:06:52 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Sat Oct 13 03:26:41 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <1192231576.25526.35.camel@localhost.localdomain>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<1192231576.25526.35.camel@localhost.localdomain>
Message-ID: <996265E1-109A-4B42-95B9-3526A52404EF@julianstahnke.com>

> Hello Scott I have been thinking recently that it is perhaps best  
> to use
> something that everyone is familiar with *FN* but I thought that it
> would be simpler just to use *track* to imply type and title I also
> don't think it is best practice to embed haudios *inside* haudio, I
> think of it like a hfeed element in hAtom or the Channel element in  
> RSS,
> also would you embed hfeed's inside other hfeed's?
>
> David Janes made some good proposal back in November about a hTing uF
>
> http://microformats.org/discuss/mail/microformats-discuss/2006- 
> November/007139.html
>
> which eventually turned into a hItem design pattern/uF proposed by  
> Andy
> Mabbett
>
> http://microformats.org/discuss/mail/microformats-discuss/2006- 
> November/007281.html
>
> there is a brainstorm about the hItem uf/item design pattern
>
> http://microformats.org/wiki/items-brainstorming
>
>
> So I thought simple solution
>
> <div class="haudio">
> 	<span class="album">Best Before 1984</span>
> 	<span class="contributor">Crass</span>
>     <div class="item">
>         <span class="track">Nagasaki Nightmare</span>
> 	<abbr class="duration" title="P268T">4:46</abbr>
>     </div>
>     <div class="item">
>         <span class="track">Big A, Little A </span>
>         <abbr class="duration" title="P368T"> 6:13</abbr>
>     </div>
>   </div>
> </div>
>
> Elegant I would say?
>
> It solves the problem of do we use FN audio-title, whatever...
> We have established that we cant use FN because want to describe
> something MORE specific
>
> http://microformats.org/discuss/mail/microformats-new/2007-May/ 
> 000355.html
> http://microformats.org/discuss/mail/microformats-new/2007-May/ 
> 000357.html

I understand Tantek?s position to be in favour of using ?fn? and  
against inventing a new property. Also, I talked to him a couple of  
days ago and he made that point again. I myself kinda thought fn was  
more or less specific to people and meant ?full name? instead of  
?formatted name?.[1] Shame on me.

Specific to the hAudio microformat, I?d still love to use audio-title  
and album-title or similar names as they make for mark-up that is  
wonderfully readable by anyone. Yet, in the greater scheme of things,  
I guess it?s better to be pragmatic and re-use as many properties  
from other microformats as possible. He really has a point there.

> And also we dont need to use either FN or audio-title because
> track I understand has to have the exact semantic value as album
> The example above shows how to clearly define both track and album

In the example above, I?d use fn in the item instead of track.

Anyhow, I?m more in favour of Scott?s approach. I wonder though if we  
could maybe use item instead of track somehow, as it is used in other  
microformats already (mentioned here: http://microformats.org/wiki/ 
item#3._As_a_composite). Works great for

Album with a couple of tracks, more detailed:
<span class="haudio">
      <span class="fn album">Best Before 1984</span>
      <span class="contributor">Crass</span>
      <span class="item haudio"><span class="fn">Nagasaki Nightmare</
span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
      <span class="item haudio"><span class="fn">Nagasaki Nightmare</
span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
      <span class="item haudio"><span class="fn">Nagasaki Nightmare</
span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
</span>

The problem with that obviously is the missing possibility of the  
?album with a couple of tracks, simple example? variant:

<span class="haudio">
      <span class="fn album">Best Before 1984</span>
      <span class="contributor">Crass</span>
      <span class="item">Nagasaki Nightmare</span>
      <span class="item">Nagasaki Nightmare</span>
      <span class="item">Nagasaki Nightmare</span>
</span>

That looks a bit wrong. The question really is if we need this. I?d  
very much like to have that possibility. Maybe someone has an idea  
about how to deal with it?

[1] That?s mentioned neither in the cheatsheet nor on the main hcard  
page nor on the singular properties page. Found it in the FAQ,  
eventually. I think it should be mentioned in the explanation of the  
property as well, though. Anyone opposed to adding it there: http:// 
microformats.org/wiki/hcard-singular-properties#fn ?

From martin at weborganics.co.uk  Sat Oct 13 05:40:43 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 13 05:39:53 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <F422DFB0-70BE-4B70-9930-BB80DAFB4EAC@makedatamakesense.com>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<47103E01.8010908@digitalbazaar.com>
	<F422DFB0-70BE-4B70-9930-BB80DAFB4EAC@makedatamakesense.com>
Message-ID: <1192279243.875.31.camel@localhost.localdomain>

Hello Scott, Manu, Julian...

On Sat, 2007-10-13 at 00:18 -0600, Scott Reynen wrote:
> On Oct 12, 2007, at 9:39 PM, Manu Sporny wrote:
> 
> > Martin, can you post some markup for the same 5 examples above using
> > your proposal?
> 
> Yeah, I'd like that too, Martin.  It seems to me you're making  
> several proposals at once, and I'm not able to conceptually separate  
> them enough to understand and respond.  Examples of the various types  
> Julian posted earlier (single track with album, single track without  
> album, single album without tracks, single album with simple tracks,  
> and single album with detailed tracks) would help clarify for me  
> exactly how you see it all fitting together.

Single Track album known
<span class="haudio">
     <span class="item track">Nagasaki Nightmare</span>
     <span class="album">Best Before 1984</span>
     <span class="contributor">Crass</span>
</span>

Single track, album unknown:

<span class="haudio">
     <span class="item track">Nagasaki Nightmare</span>
     <span class="contributor">Crass</span>
</span>

Album:
<span class="haudio">
     <span class="album">Best Before 1984</span>
     <span class="contributor">Crass</span>
</span>

Album with a couple of tracks, simple example:
<span class="haudio">
     <span class="album">Best Before 1984</span>
     <span class="contributor">Crass</span>
     <span class="item track">Nagasaki Nightmare</span>
     <span class="item track">Nagasaki Nightmare</span>
     <span class="item track">Nagasaki Nightmare</span>
</span>

Album with a couple of tracks, more detailed:
<span class="haudio">
     <span class="album">Best Before 1984</span>
     <span class="contributor">Crass</span>
     <span class="item"><span class="track">Nagasaki Nightmare</ 
span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
     <span class="item"><span class="track">Nagasaki Nightmare</ 
span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
     <span class="item"><span class="track">Nagasaki Nightmare</ 
span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
</span>

...

As I said in one of my previous messages I am a supporter of using *FN*
as it suits the original design intention that when creating the hAudio
uF we should re-use existing microformats where possible If none can not
be found then we propose another,

...

Single Track album known
<span class="haudio">
     <span class="item fn">Nagasaki Nightmare</span>
     <span class="album">Best Before 1984</span>
     <span class="contributor">Crass</span>
</span>

Single track, album unknown:

<span class="haudio">
     <span class="item fn">Nagasaki Nightmare</span>
     <span class="contributor">Crass</span>
</span>

Album:
<span class="haudio">
     <span class="album">Best Before 1984</span>
     <span class="contributor">Crass</span>
</span>

Album with a couple of tracks, simple example:
<span class="haudio">
     <span class="album">Best Before 1984</span>
     <span class="contributor">Crass</span>
     <span class="item fn">Nagasaki Nightmare</span>
     <span class="item fn">Nagasaki Nightmare</span>
     <span class="item fn">Nagasaki Nightmare</span>
</span>

Album with a couple of tracks, more detailed:
<span class="haudio">
     <span class="album">Best Before 1984</span>
     <span class="contributor">Crass</span>
     <span class="item"><span class="fn">Nagasaki Nightmare</ 
span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
     <span class="item"><span class="fn">Nagasaki Nightmare</ 
span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
     <span class="item"><span class="fn">Nagasaki Nightmare</ 
span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
</span>

Pros:
 NO more New Microformats other than *album* and those already
discovered, and we get to drop audio-title as its meaning is a grey area
to begin with.

Cons:
 Is it easy to understand that an Item within hAudio is a track? (I
think it is)
Should we create yet another microformat "track"? when re-using "item"
seems to suit our purpose?


Comments?

Thanks

Martin

> 
> --
> Scott Reynen
> MakeDataMakeSense.com
> 
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From andy at pigsonthewing.org.uk  Sat Oct 13 06:03:36 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sat Oct 13 06:04:59 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <1192279243.875.31.camel@localhost.localdomain>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<47103E01.8010908@digitalbazaar.com>
	<F422DFB0-70BE-4B70-9930-BB80DAFB4EAC@makedatamakesense.com>
	<1192279243.875.31.camel@localhost.localdomain>
Message-ID: <InnYg5ToIMEHFwEN@pigsonthewing.org.uk>

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


>Single Track album known
><span class="haudio">
>     <span class="item track">Nagasaki Nightmare</span>
>     <span class="album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
></span>

What is "item" telling us there, that "track" isn't already telling us?


>Album with a couple of tracks, more detailed:
><span class="haudio">
>     <span class="album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
>     <span class="item"><span class="track">Nagasaki Nightmare</
>span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
>     <span class="item"><span class="track">Nagasaki Nightmare</
>span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
>     <span class="item"><span class="track">Nagasaki Nightmare</
>span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
></span>

Why is "track" nested in "item" in the latter example, but not the 
former?


>Single Track album known
><span class="haudio">
>     <span class="item fn">Nagasaki Nightmare</span>
>     <span class="album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
></span>

What is "item" telling us there, that "fn" isn't already telling us (or 
vice versa)?

>Album with a couple of tracks, more detailed:
><span class="haudio">
>     <span class="album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
>     <span class="item"><span class="fn">Nagasaki Nightmare</
>span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
>     <span class="item"><span class="fn">Nagasaki Nightmare</
>span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
>     <span class="item"><span class="fn">Nagasaki Nightmare</
>span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
></span>

4:46, in plain English, is not an abbreviation of "P268T".

-- 
Andy Mabbett

From martin at weborganics.co.uk  Sat Oct 13 07:00:08 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 13 07:27:59 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <996265E1-109A-4B42-95B9-3526A52404EF@julianstahnke.com>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<1192231576.25526.35.camel@localhost.localdomain>
	<996265E1-109A-4B42-95B9-3526A52404EF@julianstahnke.com>
Message-ID: <1192284008.875.61.camel@localhost.localdomain>

On Sat, 2007-10-13 at 11:06 +0100, Julian Stahnke wrote:
> > Hello Scott I have been thinking recently that it is perhaps best  
> > to use
> > something that everyone is familiar with *FN* but I thought that it
> > would be simpler just to use *track* to imply type and title I also
> > don't think it is best practice to embed haudios *inside* haudio, I
> > think of it like a hfeed element in hAtom or the Channel element in  
> > RSS,
> > also would you embed hfeed's inside other hfeed's?
> >
> > David Janes made some good proposal back in November about a hTing uF
> >
> > http://microformats.org/discuss/mail/microformats-discuss/2006- 
> > November/007139.html
> >
> > which eventually turned into a hItem design pattern/uF proposed by  
> > Andy
> > Mabbett
> >
> > http://microformats.org/discuss/mail/microformats-discuss/2006- 
> > November/007281.html
> >
> > there is a brainstorm about the hItem uf/item design pattern
> >
> > http://microformats.org/wiki/items-brainstorming
> >
> >
> > So I thought simple solution
> >
> > <div class="haudio">
> > 	<span class="album">Best Before 1984</span>
> > 	<span class="contributor">Crass</span>
> >     <div class="item">
> >         <span class="track">Nagasaki Nightmare</span>
> > 	<abbr class="duration" title="P268T">4:46</abbr>
> >     </div>
> >     <div class="item">
> >         <span class="track">Big A, Little A </span>
> >         <abbr class="duration" title="P368T"> 6:13</abbr>
> >     </div>
> >   </div>
> > </div>
> >
> > Elegant I would say?
> >
> > It solves the problem of do we use FN audio-title, whatever...
> > We have established that we cant use FN because want to describe
> > something MORE specific
> >
> > http://microformats.org/discuss/mail/microformats-new/2007-May/ 
> > 000355.html
> > http://microformats.org/discuss/mail/microformats-new/2007-May/ 
> > 000357.html
> 
> I understand Tantek?s position to be in favour of using ?fn? and  
> against inventing a new property. Also, I talked to him a couple of  
> days ago and he made that point again. I myself kinda thought fn was  
> more or less specific to people and meant ?full name? instead of  
> ?formatted name?.[1] Shame on me.

:) its a common misconception there is no shame in that.

 Many of us on the list agree with Tantek (including Me) that we SHOULD
use FN, the trouble is Some on the list want to use *Track* and
*audio-title* or *recording* because they believe the properties we are
trying to describe SHOULD mean something specific, which I tend to
disagree with, as the way I have proposed hAudio, *Item*  contained
within hAudio is a *track* 

None of my proposal are set in stone just yet we are just talking about
the possibilities...

> Specific to the hAudio microformat, I?d still love to use audio-title  
> and album-title or similar names as they make for mark-up that is  
> wonderfully readable by anyone. 

So would I but these Issues are not sitting well with any of the
community because I believe they are not staying within the "principles"
of creating a new microformat 

To "reuse building blocks from widely adopted standards: 
      * semantic (http://tantek.com/presentations/20040928sdforumws/semantic-xhtml.html), meaningful (X)HTML (http://tantek.com/presentations/2005/03/elementsofxhtml), i.e. POSH. See SemanticXHTMLDesignPrinciples for more details. 
      * existing microformats"

http://microformats.org/wiki/principles#summary_of_key_principles

I shouldn't have to quote that should I?
 
> Yet, in the greater scheme of things,  
> I guess it?s better to be pragmatic and re-use as many properties  
> from other microformats as possible. He really has a point there.
> 

He does a very good one...

> > And also we dont need to use either FN or audio-title because
> > track I understand has to have the exact semantic value as album
> > The example above shows how to clearly define both track and album
> 
> In the example above, I?d use fn in the item instead of track.
> 
> Anyhow, I?m more in favour of Scott?s approach. I wonder though if we  
> could maybe use item instead of track somehow, as it is used in other  
> microformats already (mentioned here: http://microformats.org/wiki/ 
> item#3._As_a_composite). Works great for
> 
> Album with a couple of tracks, more detailed:
> <span class="haudio">
>       <span class="fn album">Best Before 1984</span>
>       <span class="contributor">Crass</span>
>       <span class="item haudio"><span class="fn">Nagasaki Nightmare</
> span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
>       <span class="item haudio"><span class="fn">Nagasaki Nightmare</
> span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
>       <span class="item haudio"><span class="fn">Nagasaki Nightmare</
> span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> </span>

works for me too but without the haudio on every item, 

type in this case..

[snip]

<span class="haudio">
     <span class="album">Best Before 1984</span>
     <span class="contributor">Crass</span>
     <span class="item"><span class="fn">Nagasaki Nightmare</ 
span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
     <span class="item"><span class="fn">Nagasaki Nightmare</ 
span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
     <span class="item"><span class="fn">Nagasaki Nightmare</ 
span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
</span>

[/snip]

.. Is inherited from the parent class hAudio


> 
> The problem with that obviously is the missing possibility of the  
> ?album with a couple of tracks, simple example? variant:
> 
> <span class="haudio">
>       <span class="fn album">Best Before 1984</span>
>       <span class="contributor">Crass</span>
>       <span class="item">Nagasaki Nightmare</span>
>       <span class="item">Nagasaki Nightmare</span>
>       <span class="item">Nagasaki Nightmare</span>
> </span>
> 
> That looks a bit wrong. The question really is if we need this. I?d  
> very much like to have that possibility. Maybe someone has an idea  
> about how to deal with it?
> 
> [1] That?s mentioned neither in the cheatsheet nor on the main hcard  
> page nor on the singular properties page. Found it in the FAQ,  
> eventually. I think it should be mentioned in the explanation of the  
> property as well, though. Anyone opposed to adding it there: http:// 
> microformats.org/wiki/hcard-singular-properties#fn ?

Thanks

Martin

From martin at weborganics.co.uk  Sat Oct 13 07:32:38 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 13 07:31:47 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <InnYg5ToIMEHFwEN@pigsonthewing.org.uk>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<47103E01.8010908@digitalbazaar.com>
	<F422DFB0-70BE-4B70-9930-BB80DAFB4EAC@makedatamakesense.com>
	<1192279243.875.31.camel@localhost.localdomain>
	<InnYg5ToIMEHFwEN@pigsonthewing.org.uk>
Message-ID: <1192285958.875.88.camel@localhost.localdomain>

On Sat, 2007-10-13 at 14:03 +0100, Andy Mabbett wrote:
> In message <1192279243.875.31.camel@localhost.localdomain>, Martin 
> McEvoy <martin@weborganics.co.uk> writes
> 
> 
> >Single Track album known
> ><span class="haudio">
> >     <span class="item track">Nagasaki Nightmare</span>
> >     <span class="album">Best Before 1984</span>
> >     <span class="contributor">Crass</span>
> ></span>
> 
> What is "item" telling us there, that "track" isn't already telling us?

track is used in the above example instead of *fn* or *audio-title*

I now believe that this should be FN

> 
> >Album with a couple of tracks, more detailed:
> ><span class="haudio">
> >     <span class="album">Best Before 1984</span>
> >     <span class="contributor">Crass</span>
> >     <span class="item"><span class="track"></
> >span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> >     <span class="item"><span class="track">Nagasaki Nightmare</
> >span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> >     <span class="item"><span class="track">Nagasaki Nightmare</
> >span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> ></span>
> 
> Why is "track" nested in "item" in the latter example, but not the 
> former?

where Item only has a single property it can be used:

<span class="item fn">Nagasaki Nightmare</span>

of course you can do it like this,

<span class="item"><span class="fn">Nagasaki Nightmare</span></span>

but I dont really see the point?


If Item has sub properties such as duration 

it can be achieved like this

[snip]

<span class="item"><span class="fn">Nagasaki Nightmare</ 
span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
</span>

[/snip]

> 
> 
> >Single Track album known
> ><span class="haudio">
> >     <span class="item fn">Nagasaki Nightmare</span>
> >     <span class="album">Best Before 1984</span>
> >     <span class="contributor">Crass</span>
> ></span>
> 
> What is "item" telling us there, that "fn" isn't already telling us (or 
> vice versa)?

Item is being used as a composite

http://microformats.org/wiki/item#3._As_a_composite

not as a formatted name or title


> 
> >Album with a couple of tracks, more detailed:
> ><span class="haudio">
> >     <span class="album">Best Before 1984</span>
> >     <span class="contributor">Crass</span>
> >     <span class="item"><span class="fn">Nagasaki Nightmare</
> >span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> >     <span class="item"><span class="fn">Nagasaki Nightmare</
> >span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> >     <span class="item"><span class="fn">Nagasaki Nightmare</
> >span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> ></span>
> 
> 4:46, in plain English, is not an abbreviation of "P268T".

No you are correct it isn't It needs changing.

Thanks

Martin


> 

From martin at weborganics.co.uk  Sat Oct 13 08:17:44 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 13 08:16:53 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <1192285958.875.88.camel@localhost.localdomain>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<47103E01.8010908@digitalbazaar.com>
	<F422DFB0-70BE-4B70-9930-BB80DAFB4EAC@makedatamakesense.com>
	<1192279243.875.31.camel@localhost.localdomain>
	<InnYg5ToIMEHFwEN@pigsonthewing.org.uk>
	<1192285958.875.88.camel@localhost.localdomain>
Message-ID: <1192288664.875.93.camel@localhost.localdomain>

On Sat, 2007-10-13 at 15:32 +0100, Martin McEvoy wrote:
> > 
> > >Album with a couple of tracks, more detailed:
> > ><span class="haudio">
> > >     <span class="album">Best Before 1984</span>
> > >     <span class="contributor">Crass</span>
> > >     <span class="item"><span class="fn">Nagasaki Nightmare</
> > >span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> > >     <span class="item"><span class="fn">Nagasaki Nightmare</
> > >span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> > >     <span class="item"><span class="fn">Nagasaki Nightmare</
> > >span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> > ></span>
> > 
> > 4:46, in plain English, is not an abbreviation of "P268T".
> 
> No you are correct it isn't It needs changing. 

would this work:

<abbr class="duration" title="2676000">4:46</abbr>

title is expressed in milliseconds 4:46 is a human readable abbreviation

Thanks

Martin

From martin at weborganics.co.uk  Sat Oct 13 08:22:47 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 13 08:21:56 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <1192288664.875.93.camel@localhost.localdomain>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<47103E01.8010908@digitalbazaar.com>
	<F422DFB0-70BE-4B70-9930-BB80DAFB4EAC@makedatamakesense.com>
	<1192279243.875.31.camel@localhost.localdomain>
	<InnYg5ToIMEHFwEN@pigsonthewing.org.uk>
	<1192285958.875.88.camel@localhost.localdomain>
	<1192288664.875.93.camel@localhost.localdomain>
Message-ID: <1192288967.875.96.camel@localhost.localdomain>

On Sat, 2007-10-13 at 16:17 +0100, Martin McEvoy wrote:
> On Sat, 2007-10-13 at 15:32 +0100, Martin McEvoy wrote:
> > > 
> > > >Album with a couple of tracks, more detailed:
> > > ><span class="haudio">
> > > >     <span class="album">Best Before 1984</span>
> > > >     <span class="contributor">Crass</span>
> > > >     <span class="item"><span class="fn">Nagasaki Nightmare</
> > > >span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> > > >     <span class="item"><span class="fn">Nagasaki Nightmare</
> > > >span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> > > >     <span class="item"><span class="fn">Nagasaki Nightmare</
> > > >span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> > > ></span>
> > > 
> > > 4:46, in plain English, is not an abbreviation of "P268T".
> > 
> > No you are correct it isn't It needs changing. 
> 
> would this work:
> 
> <abbr class="duration" title="2676000">4:46</abbr>

opps one to many zeros title="267600"

I am a dope :)

Martin
> 
> title is expressed in milliseconds 4:46 is a human readable abbreviation
> 
> Thanks
> 
> Martin

From scott at makedatamakesense.com  Sat Oct 13 08:50:50 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sat Oct 13 08:50:54 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <1192285958.875.88.camel@localhost.localdomain>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<47103E01.8010908@digitalbazaar.com>
	<F422DFB0-70BE-4B70-9930-BB80DAFB4EAC@makedatamakesense.com>
	<1192279243.875.31.camel@localhost.localdomain>
	<InnYg5ToIMEHFwEN@pigsonthewing.org.uk>
	<1192285958.875.88.camel@localhost.localdomain>
Message-ID: <2A01001E-A057-4F9A-9BED-EB4CFB934547@makedatamakesense.com>

On Oct 13, 2007, at 8:32 AM, Martin McEvoy wrote:

>> Why is "track" nested in "item" in the latter example, but not the
>> former?
>
> where Item only has a single property it can be used:
>
> <span class="item fn">Nagasaki Nightmare</span>
>
> of course you can do it like this,
>
> <span class="item"><span class="fn">Nagasaki Nightmare</span></span>
>
> but I dont really see the point?

The point is clear semantics.  There's no way of knowing with  
class="item fn" that the fn is a subproperty of the item.  Merging  
properties and subproperties into the same element is not considered  
valid in any microformat for this reason.  If you want to change  
that, please raise the issue in a thread outside the hAudio  
discussion, as it would be a major change affecting every single  
microformat.

--
Scott Reynen
MakeDataMakeSense.com


From scott at makedatamakesense.com  Sat Oct 13 08:57:02 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sat Oct 13 08:57:06 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <1192284008.875.61.camel@localhost.localdomain>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<1192231576.25526.35.camel@localhost.localdomain>
	<996265E1-109A-4B42-95B9-3526A52404EF@julianstahnke.com>
	<1192284008.875.61.camel@localhost.localdomain>
Message-ID: <EBAC5FC9-060B-419B-806E-C07F7E3DE1E7@makedatamakesense.com>

On Oct 13, 2007, at 8:00 AM, Martin McEvoy wrote:

> works for me too but without the haudio on every item,

Please respond to the concerns Manu and I already raised about this,  
which I've updated below with our current naming preferences:

On Oct 8, 2007, at 11:13 PM, Scott Reynen wrote:

> On Oct 8, 2007, at 9:33 PM, Manu Sporny wrote:
>
>> I have to admit, though, that the above mark-up just doesn't sit well
>> with me. We have to assume that properties inside of ITEM are of type
>> hAudio and can use any of it's properties. In other words, we are
>> assuming the type of the contents of ITEM  is an hAudio based on the
>> parent container, which is hAudio.
>
> Not only based on the parent container, but also based on the  
> contained properties, because an item with no fn isn't hAudio.  So  
> someone looking at an element with class="item" would need to look  
> both at the parent elements and at the contents of the element to  
> know what exactly "item" means.  I think it's simpler for item to  
> always mean the same thing, and use the hAudio class to clearly  
> indicate whether or not it's actually hAudio.  Similarly, hCard has  
> an "agent" property, which can itself be another hCard, and we mark  
> this with class="agent hcard".

--
Scott Reynen
MakeDataMakeSense.com


From andy at pigsonthewing.org.uk  Sat Oct 13 08:51:16 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sat Oct 13 09:02:42 2007
Subject: [uf-new] I propose a new microformat for poems.
In-Reply-To: <787886.78618.qm@web96002.mail.aue.yahoo.com>
References: <787886.78618.qm@web96002.mail.aue.yahoo.com>
Message-ID: <gkgiQsX0lOEHFwBb@pigsonthewing.org.uk>

In message <787886.78618.qm@web96002.mail.aue.yahoo.com>, 
paul_wilkins@xtra.co.nz writes

><l>

><span class="l">

<line> and <span class="line"> would be better.

-- 
Andy Mabbett
From andy at pigsonthewing.org.uk  Sat Oct 13 09:13:48 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sat Oct 13 09:14:50 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <1192288664.875.93.camel@localhost.localdomain>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<47103E01.8010908@digitalbazaar.com>
	<F422DFB0-70BE-4B70-9930-BB80DAFB4EAC@makedatamakesense.com>
	<1192279243.875.31.camel@localhost.localdomain>
	<InnYg5ToIMEHFwEN@pigsonthewing.org.uk>
	<1192285958.875.88.camel@localhost.localdomain>
	<1192288664.875.93.camel@localhost.localdomain>
Message-ID: <mnCTwIa86OEHFwgG@pigsonthewing.org.uk>

In message <1192288664.875.93.camel@localhost.localdomain>, Martin
McEvoy <martin@weborganics.co.uk> writes (corrected per his follow-up)

>> > 4:46, in plain English, is not an abbreviation of "P268T".
>>
>> No you are correct it isn't It needs changing.
>
>would this work:
>
><abbr class="duration" title="267600">4:46</abbr>
>
>title is expressed in milliseconds 4:46 is a human readable
>abbreviation

It would "work", in that could be parsed; but "4:46" is *not* an
abbreviation of "267600". Consider, also that that might be in a table
whose column-title is "duration in minutes and seconds".

If the evidence is that people are publishing times as "4:46", why not
simply allow them to do so as part of this microformat:

        <span class="duration">4:46</span>

and for longer works:

        <span class="duration">1:16:00</span>

Where the pattern is:

        nn (seconds)

        nn:nn (minutes and seconds)

        nn:nn:nn (hours, minutes and seconds)

Additionally, decimal values in seconds could be allowed:

        nn:nn:nn.nn


That said, 4'46", 4m46s and 4mins 46secs, and more, have to be catered
for. This:

        <abbr class="duration" title="4:46">4m 46s</abbr>

is less of an abuse of abbr, but still not right.


I think we should resolve the abbr-accessibility "elephant in the room",
once and for all, before introducing any new mis-uses of abbr. After
all, it was identified over a year ago...

-- 
Andy Mabbett
From martin at weborganics.co.uk  Sat Oct 13 09:16:11 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 13 09:15:18 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <2A01001E-A057-4F9A-9BED-EB4CFB934547@makedatamakesense.com>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<47103E01.8010908@digitalbazaar.com>
	<F422DFB0-70BE-4B70-9930-BB80DAFB4EAC@makedatamakesense.com>
	<1192279243.875.31.camel@localhost.localdomain>
	<InnYg5ToIMEHFwEN@pigsonthewing.org.uk>
	<1192285958.875.88.camel@localhost.localdomain>
	<2A01001E-A057-4F9A-9BED-EB4CFB934547@makedatamakesense.com>
Message-ID: <1192292171.1923.10.camel@localhost.localdomain>

On Sat, 2007-10-13 at 09:50 -0600, Scott Reynen wrote:
> On Oct 13, 2007, at 8:32 AM, Martin McEvoy wrote:
> 
> >> Why is "track" nested in "item" in the latter example, but not the
> >> former?
> >
> > where Item only has a single property it can be used:
> >
> > <span class="item fn">Nagasaki Nightmare</span>
> >
> > of course you can do it like this,
> >
> > <span class="item"><span class="fn">Nagasaki Nightmare</span></span>
> >
> > but I dont really see the point?
> 
> The point is clear semantics.  There's no way of knowing with  
> class="item fn" that the fn is a subproperty of the item.  Merging  
> properties and subproperties into the same element is not considered  
> valid in any microformat for this reason.  

Ahh now I see the point :)

> If you want to change  
> that, please raise the issue in a thread outside the hAudio  
> discussion, as it would be a major change affecting every single  
> microformat.

so this is Invalid in hListing?

http://microformats.org/wiki/hlisting#Examples_.28Preliminary.29


just this then

<span class="item">
    <span class="fn">Nagasaki Nightmare</span>
</span>

no sub properties inside the Item class?


Thanks

Martin

> 
> --
> Scott Reynen
> MakeDataMakeSense.com
> 
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From andy at pigsonthewing.org.uk  Sat Oct 13 09:16:40 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sat Oct 13 09:18:13 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <1192285958.875.88.camel@localhost.localdomain>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<47103E01.8010908@digitalbazaar.com>
	<F422DFB0-70BE-4B70-9930-BB80DAFB4EAC@makedatamakesense.com>
	<1192279243.875.31.camel@localhost.localdomain>
	<InnYg5ToIMEHFwEN@pigsonthewing.org.uk>
	<1192285958.875.88.camel@localhost.localdomain>
Message-ID: <onnQgtao9OEHFwAV@pigsonthewing.org.uk>

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

>> >Single Track album known
>> ><span class="haudio">
>> >     <span class="item fn">Nagasaki Nightmare</span>
>> >     <span class="album">Best Before 1984</span>
>> >     <span class="contributor">Crass</span>
>> ></span>
>>
>> What is "item" telling us there, that "fn" isn't already telling us (or
>> vice versa)?
>
>Item is being used as a composite
>
>http://microformats.org/wiki/item#3._As_a_composite
>
>not as a formatted name or title

I believe that that "item composite pattern" is just a "brainstorm", and 
not agreed practice.

-- 
Andy Mabbett
From andy at pigsonthewing.org.uk  Sat Oct 13 09:30:28 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sat Oct 13 09:31:41 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <1192284008.875.61.camel@localhost.localdomain>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<1192231576.25526.35.camel@localhost.localdomain>
	<996265E1-109A-4B42-95B9-3526A52404EF@julianstahnke.com>
	<1192284008.875.61.camel@localhost.localdomain>
Message-ID: <LmUIQ9bkKPEHFw1g@pigsonthewing.org.uk>

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

> Many of us on the list agree with Tantek (including Me) that we SHOULD
>use FN, the trouble is Some on the list want to use *Track* and
>*audio-title* or *recording* because they believe the properties we are
>trying to describe SHOULD mean something specific, which I tend to
>disagree with, as the way I have proposed hAudio, *Item*  contained
>within hAudio is a *track*

"fn" is fine, so long as it's clear (from a higher-level attribute) what
is being named, as in this pseudocode:

        <li><track><fn>Speak to me</fn></track></li>
        <li><track><fn>Breathe</fn></track></li>
        <li><track><fn>On the Run</fn></track></li>
        <li><track><fn>Time</fn></track></li>

Whereas that may be OK, this:

        <li><fn>Speak to me</fn></li>
        <li><fn>Breathe</fn></li>
        <li><fn>On the Run</fn></li>
        <li><fn>Time</fn></li>

is not.

Would we use "fn", though, if hCard had been created before vCard?


>> I wonder though if we
>> could maybe use item instead of track somehow

><span class="haudio">
>     <span class="album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
>     <span class="item"><span class="fn">Nagasaki Nightmare</
>span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
>     <span class="item"><span class="fn">Nagasaki Nightmare</
>span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
>     <span class="item"><span class="fn">Nagasaki Nightmare</
>span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
></span>

Item is semantically empty, other than as a container. We might as well
say "thing".

-- 
Andy Mabbett

From scott at makedatamakesense.com  Sat Oct 13 09:32:15 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sat Oct 13 09:32:18 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <mnCTwIa86OEHFwgG@pigsonthewing.org.uk>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<47103E01.8010908@digitalbazaar.com>
	<F422DFB0-70BE-4B70-9930-BB80DAFB4EAC@makedatamakesense.com>
	<1192279243.875.31.camel@localhost.localdomain>
	<InnYg5ToIMEHFwEN@pigsonthewing.org.uk>
	<1192285958.875.88.camel@localhost.localdomain>
	<1192288664.875.93.camel@localhost.localdomain>
	<mnCTwIa86OEHFwgG@pigsonthewing.org.uk>
Message-ID: <1B6B1F39-BCAB-46D5-9310-67583CF7BA71@makedatamakesense.com>

On Oct 13, 2007, at 10:13 AM, Andy Mabbett wrote:

> I think we should resolve the abbr-accessibility "elephant in the  
> room",
> once and for all, before introducing any new mis-uses of abbr. After
> all, it was identified over a year ago...

And it could easily go unresolved for another year.  Any resolution  
to abbr problems can be applied to hAudio in the future just as  
easily as every other microformat already using abbr.  That shouldn't  
slow down hAudio progress.  In this case, someone wrote "P268T" as a  
long form of "4:46", when it should have been "P286T".  Typo aside,  
that follows established microformat use of <abbr> and ISO 8601.  If  
and when such use changes, hAudio can change accordingly.

--
Scott Reynen
MakeDataMakeSense.com


From andy at pigsonthewing.org.uk  Sat Oct 13 10:03:06 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sat Oct 13 10:04:37 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <1B6B1F39-BCAB-46D5-9310-67583CF7BA71@makedatamakesense.com>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<47103E01.8010908@digitalbazaar.com>
	<F422DFB0-70BE-4B70-9930-BB80DAFB4EAC@makedatamakesense.com>
	<1192279243.875.31.camel@localhost.localdomain>
	<InnYg5ToIMEHFwEN@pigsonthewing.org.uk>
	<1192285958.875.88.camel@localhost.localdomain>
	<1192288664.875.93.camel@localhost.localdomain>
	<mnCTwIa86OEHFwgG@pigsonthewing.org.uk>
	<1B6B1F39-BCAB-46D5-9310-67583CF7BA71@makedatamakesense.com>
Message-ID: <DHfaoTdKpPEHFwWr@pigsonthewing.org.uk>

In message <1B6B1F39-BCAB-46D5-9310-67583CF7BA71@makedatamakesense.com>, 
Scott Reynen <scott@makedatamakesense.com> writes

>On Oct 13, 2007, at 10:13 AM, Andy Mabbett wrote:
>
>> I think we should resolve the abbr-accessibility "elephant in the 
>>room",
>> once and for all, before introducing any new mis-uses of abbr. After
>> all, it was identified over a year ago...
>
>And it could easily go unresolved for another year.

It could well do. For shame.

Can anyone here give an undertaking not to loose their sight, during 
that time? Does everyone here think disability only happens to other 
people?

>  Any resolution  to abbr problems can be applied to hAudio in the 
>future just as  easily as every other microformat already using abbr.

Yeah, who cares about cripples. What are they doing using our web, 
anyway? Let 'em wait.

> That shouldn't  slow down hAudio progress.  In this case, someone 
>wrote "P268T" as a  long form of "4:46", when it should have been 
>"P286T".  Typo aside,  that follows established microformat use of 
><abbr> and ISO 8601.

I didn't even notice the typo; "4:46", in plain English, is no more an 
abbreviation of "P286T" than it is of "P268T".

-- 
Andy Mabbett
From martin at weborganics.co.uk  Sat Oct 13 10:38:00 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 13 10:37:10 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <LmUIQ9bkKPEHFw1g@pigsonthewing.org.uk>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<1192231576.25526.35.camel@localhost.localdomain>
	<996265E1-109A-4B42-95B9-3526A52404EF@julianstahnke.com>
	<1192284008.875.61.camel@localhost.localdomain>
	<LmUIQ9bkKPEHFw1g@pigsonthewing.org.uk>
Message-ID: <1192297080.1923.21.camel@localhost.localdomain>

On Sat, 2007-10-13 at 17:30 +0100, Andy Mabbett wrote:
> In message <1192284008.875.61.camel@localhost.localdomain>, Martin
> McEvoy <martin@weborganics.co.uk> writes
> 
> > Many of us on the list agree with Tantek (including Me) that we SHOULD
> >use FN, the trouble is Some on the list want to use *Track* and
> >*audio-title* or *recording* because they believe the properties we are
> >trying to describe SHOULD mean something specific, which I tend to
> >disagree with, as the way I have proposed hAudio, *Item*  contained
> >within hAudio is a *track*
> 
> "fn" is fine, so long as it's clear (from a higher-level attribute) what
> is being named, as in this pseudocode:
> 
>         <li><track><fn>Speak to me</fn></track></li>
>         <li><track><fn>Breathe</fn></track></li>
>         <li><track><fn>On the Run</fn></track></li>
>         <li><track><fn>Time</fn></track></li>
> 
> Whereas that may be OK, this:
> 
>         <li><fn>Speak to me</fn></li>
>         <li><fn>Breathe</fn></li>
>         <li><fn>On the Run</fn></li>
>         <li><fn>Time</fn></li>
> 
> is not.
> 
> Would we use "fn", though, if hCard had been created before vCard?
> 
> 
> >> I wonder though if we
> >> could maybe use item instead of track somehow
> 
> ><span class="haudio">
> >     <span class="album">Best Before 1984</span>
> >     <span class="contributor">Crass</span>
> >     <span class="item"><span class="fn">Nagasaki Nightmare</
> >span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> >     <span class="item"><span class="fn">Nagasaki Nightmare</
> >span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> >     <span class="item"><span class="fn">Nagasaki Nightmare</
> >span> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> ></span>
> 
> Item is semantically empty, other than as a container. We might as well
> say "thing".

You are correct as this is my Intention Item should be treated as
transparent, opaque, Its just a way or pointing out a "thing" in hAudio

what is a track on your CD? Just a space, gap or marker nothing more its
the contents of a track that has meaning. If we store tracks on a file
system each or these tracks has unique properties on their own and it is
these values that hAudio has to describe.

Thanks
Martin

> 

From martin at weborganics.co.uk  Sat Oct 13 10:40:18 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 13 10:39:26 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <onnQgtao9OEHFwAV@pigsonthewing.org.uk>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<47103E01.8010908@digitalbazaar.com>
	<F422DFB0-70BE-4B70-9930-BB80DAFB4EAC@makedatamakesense.com>
	<1192279243.875.31.camel@localhost.localdomain>
	<InnYg5ToIMEHFwEN@pigsonthewing.org.uk>
	<1192285958.875.88.camel@localhost.localdomain>
	<onnQgtao9OEHFwAV@pigsonthewing.org.uk>
Message-ID: <1192297218.1923.24.camel@localhost.localdomain>

On Sat, 2007-10-13 at 17:16 +0100, Andy Mabbett wrote:
> In message <1192285958.875.88.camel@localhost.localdomain>, Martin 
> McEvoy <martin@weborganics.co.uk> writes
> 
> >> >Single Track album known
> >> ><span class="haudio">
> >> >     <span class="item fn">Nagasaki Nightmare</span>
> >> >     <span class="album">Best Before 1984</span>
> >> >     <span class="contributor">Crass</span>
> >> ></span>
> >>
> >> What is "item" telling us there, that "fn" isn't already telling us (or
> >> vice versa)?
> >
> >Item is being used as a composite
> >
> >http://microformats.org/wiki/item#3._As_a_composite
> >
> >not as a formatted name or title
> 
> I believe that that "item composite pattern" is just a "brainstorm", and 
> not agreed practice.

Not Yet but this is another discussion Intend to persue

> 

From martin at weborganics.co.uk  Sat Oct 13 10:43:55 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 13 10:43:04 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <mnCTwIa86OEHFwgG@pigsonthewing.org.uk>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<47103E01.8010908@digitalbazaar.com>
	<F422DFB0-70BE-4B70-9930-BB80DAFB4EAC@makedatamakesense.com>
	<1192279243.875.31.camel@localhost.localdomain>
	<InnYg5ToIMEHFwEN@pigsonthewing.org.uk>
	<1192285958.875.88.camel@localhost.localdomain>
	<1192288664.875.93.camel@localhost.localdomain>
	<mnCTwIa86OEHFwgG@pigsonthewing.org.uk>
Message-ID: <1192297435.1923.29.camel@localhost.localdomain>

On Sat, 2007-10-13 at 17:13 +0100, Andy Mabbett wrote:
> In message <1192288664.875.93.camel@localhost.localdomain>, Martin
> McEvoy <martin@weborganics.co.uk> writes (corrected per his follow-up)
> 
> >> > 4:46, in plain English, is not an abbreviation of "P268T".
> >>
> >> No you are correct it isn't It needs changing.
> >
> >would this work:
> >
> ><abbr class="duration" title="267600">4:46</abbr>
> >
> >title is expressed in milliseconds 4:46 is a human readable
> >abbreviation
> 
> It would "work", in that could be parsed; but "4:46" is *not* an
> abbreviation of "267600". Consider, also that that might be in a table
> whose column-title is "duration in minutes and seconds".
> 
> If the evidence is that people are publishing times as "4:46", why not
> simply allow them to do so as part of this microformat:
> 
>         <span class="duration">4:46</span>
> 
> and for longer works:
> 
>         <span class="duration">1:16:00</span>
> 
> Where the pattern is:
> 
>         nn (seconds)
> 
>         nn:nn (minutes and seconds)
> 
>         nn:nn:nn (hours, minutes and seconds)
> 
> Additionally, decimal values in seconds could be allowed:
> 
>         nn:nn:nn.nn
> 
> 
> That said, 4'46", 4m46s and 4mins 46secs, and more, have to be catered
> for. This:
> 
>         <abbr class="duration" title="4:46">4m 46s</abbr>
> 
> is less of an abuse of abbr, but still not right.
> 
> 
> I think we should resolve the abbr-accessibility "elephant in the room",
> once and for all, before introducing any new mis-uses of abbr. After
> all, it was identified over a year ago...

You have made a fair argument I have no problems with this I would
recommend that in hAudio any use or the abbr-pattern should be delayed
until all accessibility issues are resolved

<span class="duration">4:46</span>

+1

Martin McEvoy
> 

From andy at pigsonthewing.org.uk  Sat Oct 13 11:47:05 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sat Oct 13 11:48:27 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <1192297080.1923.21.camel@localhost.localdomain>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<1192231576.25526.35.camel@localhost.localdomain>
	<996265E1-109A-4B42-95B9-3526A52404EF@julianstahnke.com>
	<1192284008.875.61.camel@localhost.localdomain>
	<LmUIQ9bkKPEHFw1g@pigsonthewing.org.uk>
	<1192297080.1923.21.camel@localhost.localdomain>
Message-ID: <umHBgphpKREHFwR+@pigsonthewing.org.uk>

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

>> Item is semantically empty, other than as a container. We might as well
>> say "thing".

>what is a track on your CD? Just a space, gap or marker nothing more

On the contrary, it has a distinct meaning, which defines it as being
apart from the other "items" on a CD, such as an index, the performer,
its catalogue number, or whatever.

-- 
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 martin at weborganics.co.uk  Sat Oct 13 12:01:21 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 13 12:00:30 2007
Subject: [uf-new] hAudio current thinking?
Message-ID: <1192302081.1923.54.camel@localhost.localdomain>

Just to try and Outline the current thinking on hAudio

Manu's proposed *album* and *recording* properties
Album we can all agree on? 
Manu later changed his support to FN instead of Recording
which is something else we can all agree on? 

I am proposing that we re-use *item* from hListing, hReview and hItem
instead of creating another microformat *track* the status of this is
still unknown

Andy aired his concerns over the misuse of the abbr design pattern,
I agree with Andy, we SHOULD not use the abbr design pattern in hAudio
until all current abbr issues are resolved.

the proposed markup

...

[1] Single Track album known
<span class="haudio">
     <span class="item">
              <span class="fn>Nagasaki Nightmare</span>
       </span>
     <span class="album">Best Before 1984</span>
     <span class="contributor">Crass</span>
</span>

...

[2] Single track, album unknown:

<span class="haudio">
     <span class="item">
              <span class="fn>Nagasaki Nightmare</span>
       </span>
     <span class="contributor">Crass</span>
</span>

...

[3] Album:
<span class="haudio">
     <span class="album">Best Before 1984</span>
     <span class="contributor">Crass</span>
</span>

...

[4] Album with a couple of tracks, simple example:
<span class="haudio">
     <span class="album">Best Before 1984</span>
     <span class="contributor">Crass</span>
     <span class="item">
              <span class="fn>Nagasaki Nightmare</span>
       </span>
     <span class="item">
              <span class="fn>Nagasaki Nightmare</span>
       </span>
     <span class="item">
              <span class="fn>Nagasaki Nightmare</span>
       </span>
</span>

...

[5] Album with a couple of tracks, more detailed:
<span class="haudio">
     <span class="album">Best Before 1984</span>Any concerns should be
raised now
     <span class="contributor">Crass</span>
     <span class="item">
	<span class="fn">Nagasaki Nightmare</span> ? 
	<span class="duration">4:46</span>
     </span>
     <span class="item">
	<span class="fn">Nagasaki Nightmare</span> ? 
	<span class="duration">4:46</span>
     </span>
     <span class="item">
	<span class="fn">Nagasaki Nightmare</span> ? 
	<span class="duration">4:46</span>
     </span>
</span>

...


Does this sit well with everybody?

Comments?

Thanks

Martin McEvoy

From martin at weborganics.co.uk  Sat Oct 13 12:14:39 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 13 12:13:47 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
In-Reply-To: <umHBgphpKREHFwR+@pigsonthewing.org.uk>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<1192231576.25526.35.camel@localhost.localdomain>
	<996265E1-109A-4B42-95B9-3526A52404EF@julianstahnke.com>
	<1192284008.875.61.camel@localhost.localdomain>
	<LmUIQ9bkKPEHFw1g@pigsonthewing.org.uk>
	<1192297080.1923.21.camel@localhost.localdomain>
	<umHBgphpKREHFwR+@pigsonthewing.org.uk>
Message-ID: <1192302879.1923.60.camel@localhost.localdomain>

On Sat, 2007-10-13 at 19:47 +0100, Andy Mabbett wrote:
> In message <1192297080.1923.21.camel@localhost.localdomain>, Martin
> McEvoy <martin@weborganics.co.uk> writes
> 
> >> Item is semantically empty, other than as a container. We might as
> well
> >> say "thing".
> 
> >what is a track on your CD? Just a space, gap or marker nothing more
> 
> On the contrary, it has a distinct meaning, which defines it as being
> apart from the other "items" on a CD, such as an index, the performer,
> its catalogue number, or whatever.

Perhaps I am thinking to literally Item is just an Item? its the
contents of which that describe just what kind of item it is?

Thanks

Martin 
> 
> -- 
> 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/> ?
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
> 

From martin at weborganics.co.uk  Sat Oct 13 12:21:27 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 13 12:20:36 2007
Subject: [uf-new] Re: hAudio current thinking?
In-Reply-To: <1192302081.1923.54.camel@localhost.localdomain>
References: <1192302081.1923.54.camel@localhost.localdomain>
Message-ID: <1192303287.1923.63.camel@localhost.localdomain>

On Sat, 2007-10-13 at 20:01 +0100, Martin McEvoy wrote:
>      <span class="album">Best Before 1984</span>Any concerns should be
> raised now
>      <span class="contributor">Crass</span> 

WTF "Any concerns should be raised now" should have been at the bottom
of my email!!

Oh well that's Evolution for you :)

Martin

From andy at pigsonthewing.org.uk  Sat Oct 13 12:32:59 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sat Oct 13 12:34:18 2007
Subject: [uf-new] hAudio current thinking?
In-Reply-To: <1192302081.1923.54.camel@localhost.localdomain>
References: <1192302081.1923.54.camel@localhost.localdomain>
Message-ID: <oGnAoNir1REHFwyl@pigsonthewing.org.uk>

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

>I am proposing that we re-use *item* from hListing, hReview and hItem
>instead of creating another microformat *track* the status of this is
>still unknown

>Does this sit well with everybody?

No. You seem to have overlooked my concerns about the semantic impotence 
of "item".

-- 
Andy Mabbett
From martin at weborganics.co.uk  Sat Oct 13 12:48:15 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 13 12:47:23 2007
Subject: [uf-new] hAudio current thinking?
In-Reply-To: <oGnAoNir1REHFwyl@pigsonthewing.org.uk>
References: <1192302081.1923.54.camel@localhost.localdomain>
	<oGnAoNir1REHFwyl@pigsonthewing.org.uk>
Message-ID: <1192304895.1923.66.camel@localhost.localdomain>

On Sat, 2007-10-13 at 20:32 +0100, Andy Mabbett wrote:
> In message <1192302081.1923.54.camel@localhost.localdomain>, Martin 
> McEvoy <martin@weborganics.co.uk> writes
> 
> >I am proposing that we re-use *item* from hListing, hReview and hItem
> >instead of creating another microformat *track* the status of this is
> >still unknown
> 
> >Does this sit well with everybody?
> 
> No. You seem to have overlooked my concerns about the semantic impotence 
> of "item".

And your suggestions or alternatives are?
...


Thanks

Martin

> 

From andy at pigsonthewing.org.uk  Sat Oct 13 12:48:12 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sat Oct 13 12:49:50 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <1192302879.1923.60.camel@localhost.localdomain>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<1192231576.25526.35.camel@localhost.localdomain>
	<996265E1-109A-4B42-95B9-3526A52404EF@julianstahnke.com>
	<1192284008.875.61.camel@localhost.localdomain>
	<LmUIQ9bkKPEHFw1g@pigsonthewing.org.uk>
	<1192297080.1923.21.camel@localhost.localdomain>
	<umHBgphpKREHFwR+@pigsonthewing.org.uk>
	<1192302879.1923.60.camel@localhost.localdomain>
Message-ID: <50yk0Qk8DSEHFwDR@pigsonthewing.org.uk>

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

>On Sat, 2007-10-13 at 19:47 +0100, Andy Mabbett wrote:
>> In message <1192297080.1923.21.camel@localhost.localdomain>, Martin
>> McEvoy <martin@weborganics.co.uk> writes
>>
>> >> Item is semantically empty, other than as a container. We might as
>> well
>> >> say "thing".
>>
>> >what is a track on your CD? Just a space, gap or marker nothing more
>>
>> On the contrary, it has a distinct meaning, which defines it as being
>> apart from the other "items" on a CD, such as an index, the performer,
>> its catalogue number, or whatever.
>
>Perhaps I am thinking to literally Item is just an Item? its the
>contents of which that describe just what kind of item it is?

It's my understanding that "item" in microformats was intended purely as
a delimiter, with the same - empty - semantic value as SPAN and DIV in
HTML.

The hReview spec is unhelpful in this regard, specifying it thus:

        item info. required. fn (url || photo ) | hCard (for person or
        business) | hCalendar (for event)

where "item" is in CODE tags but "info." is not, and is not explained.

The subsequent definition gives:

        item info:: This required field MUST have at a minimum the name
        ("fn" - the formatted text corresponding to the name, except for
        an event item which MUST have the "summary" property inside the
        respective hCalendar "vevent") of the item (an hReview describes
        only one item), SHOULD provide at least one URI ("url") for the
        item, and MAY provide at least one URL to a photo or depiction
        ("photo") of the item. For items of type person or business, the
        item info (fn, url, photo) MUST be encapsulated in an hCard. For
        items of type event, the item info SHOULD be encapsulated in an
        hCalendar "vevent". Non-URL unique item IDs (e.g. ISBNs, UPCs)
        MAY be represented as a URN ("url") for the item. Encapsulated
        microformats (e.g. hCard and hCalendar events for now) may be
        set on the item itself (e.g. class="item vcard"). However, when
        using item info subproperties ("fn", "url", "photo"), they MUST
        be nested inside the item element.

and the use of "item" in the examples is not consistent:

   *    <div class="description item vcard">
                <p>
                <span class="fn org">Crepes on Cole</span>
                is one of the best little creperies in
                <span class="adr">
                <span class="locality">San Francisco</span>
                </span>.
                Excellent food and service. Plenty of tables in a
                variety of sizes for parties large and small. Window
                seating makes for excellent people watching to/from the
                N-Judah which stops right outside. I've had many fun
                social gatherings here, as well as gotten plenty of work
                done thanks to neighborhood WiFi. </p>
        </div>


   *    <div class="item vcard">
                <div class="fn org summary">Cafe Borrone</div>
                <span class="adr"> <span class="street-address">1010 El
                Camino Real</span>, <span class="locality">Menlo
                Park</span>, <span class="region">CA</span> <span
                class="postal-code">94025</span>, </span>
                <span class="tel">+1-650-327-0830</span>;
                <a class="url"
                href="http://cafeborrone.com">cafeborrone.com
                </a>
        </div>


   *    <span class="item">
                <a class="url fn"
                href="http://www.amazon.com/exec/obidos/ASIN/B000089CJI/"
                >
                <img
                src="http://images.amazon.com/images/P/B000089CJI.01._SCT
                HUMBZZZ_.jpg" alt="Album cover photo: The Postal
                Service: Give Up. " class="photo" />
                 The Postal Service: Give Up
                </a>
        </span>


   *    <div class="item">
                <a lang="zh" class="url fn"
                href="http://www.imdb.com/title/tt0299977/">
                Ying Xiong (<span lang="en">HERO</span>)
                </a>
        </div>

-- 
Andy Mabbett
From andy at pigsonthewing.org.uk  Sat Oct 13 13:03:38 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sat Oct 13 13:05:21 2007
Subject: [uf-new] hAudio current thinking?
In-Reply-To: <1192304895.1923.66.camel@localhost.localdomain>
References: <1192302081.1923.54.camel@localhost.localdomain>
	<oGnAoNir1REHFwyl@pigsonthewing.org.uk>
	<1192304895.1923.66.camel@localhost.localdomain>
Message-ID: <jUbis+kaSSEHFwjH@pigsonthewing.org.uk>

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

>>You seem to have overlooked my concerns about the semantic impotence
>> of "item".
>
>And your suggestions or alternatives are?

"Track" would seem to be the closest fit, but I'm not precious about it, 
if better suggestions are made.

-- 
Andy Mabbett
From martin at weborganics.co.uk  Sat Oct 13 13:11:02 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 13 13:10:10 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs. recording/album)
In-Reply-To: <50yk0Qk8DSEHFwDR@pigsonthewing.org.uk>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<1192231576.25526.35.camel@localhost.localdomain>
	<996265E1-109A-4B42-95B9-3526A52404EF@julianstahnke.com>
	<1192284008.875.61.camel@localhost.localdomain>
	<LmUIQ9bkKPEHFw1g@pigsonthewing.org.uk>
	<1192297080.1923.21.camel@localhost.localdomain>
	<umHBgphpKREHFwR+@pigsonthewing.org.uk>
	<1192302879.1923.60.camel@localhost.localdomain>
	<50yk0Qk8DSEHFwDR@pigsonthewing.org.uk>
Message-ID: <1192306262.1923.82.camel@localhost.localdomain>

On Sat, 2007-10-13 at 20:48 +0100, Andy Mabbett wrote:
> 
> It's my understanding that "item" in microformats was intended purely
> as
> a delimiter, with the same - empty - semantic value as SPAN and DIV in
> HTML. 

the exact same semantics are mirrored In my suggestion in hAudio, do you
not think that Item can be a powerful tool in microformats if we use it
the same way as a div or a span in html?

I think if we use track ...

     <span class="track">
              <span class="fn>Nagasaki Nightmare</span>
       </span>


in the context of hAudio does it have any more meaning than

     <span class="item">
              <span class="fn>Nagasaki Nightmare</span>
       </span>

track and item are both being used as container for which the contents
describe what it is?

Anyway there is only Me at the moment supporting using *item* instead of
a new microformat *track*

so 
     <span class="track">
              <span class="fn>Nagasaki Nightmare</span>
       </span>
It is.

Martin




From martin at weborganics.co.uk  Sat Oct 13 13:15:10 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 13 13:14:21 2007
Subject: [uf-new] Re: hAudio current thinking?
In-Reply-To: <1192302081.1923.54.camel@localhost.localdomain>
References: <1192302081.1923.54.camel@localhost.localdomain>
Message-ID: <1192306510.1923.85.camel@localhost.localdomain>

UPDATE on current Thinking on hAudio

@Manu we need your input on this

[1] Single Track album known
<span class="haudio">
     <span class="track">
              <span class="fn>Nagasaki Nightmare</span>
       </span>
     <span class="album">Best Before 1984</span>
     <span class="contributor">Crass</span>
</span>

...

[2] Single track, album unknown:
<span class="haudio">
     <span class="track">
              <span class="fn>Nagasaki Nightmare</span>
       </span>
     <span class="contributor">Crass</span>
</span>

...

[3] Album:
<span class="haudio">
     <span class="album">Best Before 1984</span>
     <span class="contributor">Crass</span>
</span>

...

[4] Album with a couple of tracks, simple example:
<span class="haudio">
     <span class="album">Best Before 1984</span>
     <span class="contributor">Crass</span>
     <span class="track">
              <span class="fn>Nagasaki Nightmare</span>
       </span>
     <span class="track">
              <span class="fn>Nagasaki Nightmare</span>
       </span>
     <span class="track">
              <span class="fn>Nagasaki Nightmare</span>
       </span>
</span>

...

[5] Album with a couple of tracks, more detailed:
<span class="haudio">
     <span class="album">Best Before 1984</span>
     <span class="contributor">Crass</span>
     <span class="track">
        <span class="fn">Nagasaki Nightmare</span> ? 
        <span class="duration">4:46</span>
     </span>
     <span class="track">
        <span class="fn">Nagasaki Nightmare</span> ? 
        <span class="duration">4:46</span>
     </span>
     <span class="track">
        <span class="fn">Nagasaki Nightmare</span> ? 
        <span class="duration">4:46</span>
     </span>
</span>

...

Comments?

Thanks

Martin

On Sat, 2007-10-13 at 20:01 +0100, Martin McEvoy wrote:
> Just to try and Outline the current thinking on hAudio
> 
> Manu's proposed *album* and *recording* properties
> Album we can all agree on? 
> Manu later changed his support to FN instead of Recording
> which is something else we can all agree on? 
> 
> I am proposing that we re-use *item* from hListing, hReview and hItem
> instead of creating another microformat *track* the status of this is
> still unknown
> 
> Andy aired his concerns over the misuse of the abbr design pattern,
> I agree with Andy, we SHOULD not use the abbr design pattern in hAudio
> until all current abbr issues are resolved.
> 
> the proposed markup
> 
> ...
> 
> [1] Single Track album known
> <span class="haudio">
>      <span class="item">
>               <span class="fn>Nagasaki Nightmare</span>
>        </span>
>      <span class="album">Best Before 1984</span>
>      <span class="contributor">Crass</span>
> </span>
> 
> ...
> 
> [2] Single track, album unknown:
> 
> <span class="haudio">
>      <span class="item">
>               <span class="fn>Nagasaki Nightmare</span>
>        </span>
>      <span class="contributor">Crass</span>
> </span>
> 
> ...
> 
> [3] Album:
> <span class="haudio">
>      <span class="album">Best Before 1984</span>
>      <span class="contributor">Crass</span>
> </span>
> 
> ...
> 
> [4] Album with a couple of tracks, simple example:
> <span class="haudio">
>      <span class="album">Best Before 1984</span>
>      <span class="contributor">Crass</span>
>      <span class="item">
>               <span class="fn>Nagasaki Nightmare</span>
>        </span>
>      <span class="item">
>               <span class="fn>Nagasaki Nightmare</span>
>        </span>
>      <span class="item">
>               <span class="fn>Nagasaki Nightmare</span>
>        </span>
> </span>
> 
> ...
> 
> [5] Album with a couple of tracks, more detailed:
> <span class="haudio">
>      <span class="album">Best Before 1984</span>Any concerns should be
> raised now
>      <span class="contributor">Crass</span>
>      <span class="item">
> 	<span class="fn">Nagasaki Nightmare</span> ? 
> 	<span class="duration">4:46</span>
>      </span>
>      <span class="item">
> 	<span class="fn">Nagasaki Nightmare</span> ? 
> 	<span class="duration">4:46</span>
>      </span>
>      <span class="item">
> 	<span class="fn">Nagasaki Nightmare</span> ? 
> 	<span class="duration">4:46</span>
>      </span>
> </span>
> 
> ...
> 
> 
> Does this sit well with everybody?
> 
> Comments?
> 
> Thanks
> 
> Martin McEvoy

From julian at julianstahnke.com  Sat Oct 13 13:31:41 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Sat Oct 13 13:31:46 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <1192306262.1923.82.camel@localhost.localdomain>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<1192231576.25526.35.camel@localhost.localdomain>
	<996265E1-109A-4B42-95B9-3526A52404EF@julianstahnke.com>
	<1192284008.875.61.camel@localhost.localdomain>
	<LmUIQ9bkKPEHFw1g@pigsonthewing.org.uk>
	<1192297080.1923.21.camel@localhost.localdomain>
	<umHBgphpKREHFwR+@pigsonthewing.org.uk>
	<1192302879.1923.60.camel@localhost.localdomain>
	<50yk0Qk8DSEHFwDR@pigsonthewing.org.uk>
	<1192306262.1923.82.camel@localhost.localdomain>
Message-ID: <994227DC-3DB0-4899-BF0B-93A905B7A770@julianstahnke.com>

> Anyway there is only Me at the moment supporting using *item*  
> instead of
> a new microformat *track*

Nope, I too think item would be better. Maybe, if it is too  
meaningless, together with haudio ? la <span class="item haudio">. I  
don?t know enough about item to say if just item is enough, but I  
think it even may be. Then again, if we could use item in such a way  
that we could say ?if it is haudio, look for properties in child  
nodes, otherwise use the content of item?, that?d be potentially nice  
as well.

From andy at pigsonthewing.org.uk  Sat Oct 13 13:33:47 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sat Oct 13 13:35:01 2007
Subject: [uf-new] Re: hAudio current thinking?
In-Reply-To: <1192306510.1923.85.camel@localhost.localdomain>
References: <1192302081.1923.54.camel@localhost.localdomain>
	<1192306510.1923.85.camel@localhost.localdomain>
Message-ID: <qEHgopnruSEHFwjy@pigsonthewing.org.uk>

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

>[1] Single Track album known
><span class="haudio">
>     <span class="track">
>              <span class="fn>Nagasaki Nightmare</span>
>       </span>
>     <span class="album">Best Before 1984</span>
>     <span class="contributor">Crass</span> </span>

>[5] Album with a couple of tracks, more detailed: <span class="haudio">
>     <span class="album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
>     <span class="track">
>        <span class="fn">Nagasaki Nightmare</span> ?
>        <span class="duration">4:46</span>
>     </span>
>     <span class="track">
>        <span class="fn">Nagasaki Nightmare</span> ?
>        <span class="duration">4:46</span>
>     </span>
>     <span class="track">
>        <span class="fn">Nagasaki Nightmare</span> ?
>        <span class="duration">4:46</span>
>     </span>
></span>

How would these work, for tracks on a compilation album, by different
artists? Or tracks on a one-album artist, but where one features a guest
vocalist?

-- 
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 martin at weborganics.co.uk  Sat Oct 13 15:09:25 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 13 15:08:32 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs. recording/album)
In-Reply-To: <994227DC-3DB0-4899-BF0B-93A905B7A770@julianstahnke.com>
References: <470AFDA8.2080906@digitalbazaar.com>
	<1191961345.29452.39.camel@localhost.localdomain>
	<1192214178.25526.2.camel@localhost.localdomain>
	<470FCB5C.9070802@digitalbazaar.com>
	<21e770780710121237w5cb35be5r69893f8dcf3f4f2f@mail.gmail.com>
	<470FD29F.3060107@digitalbazaar.com>
	<B562E954-367B-4D97-8E49-D0B64E2EFC4B@makedatamakesense.com>
	<1192231576.25526.35.camel@localhost.localdomain>
	<996265E1-109A-4B42-95B9-3526A52404EF@julianstahnke.com>
	<1192284008.875.61.camel@localhost.localdomain>
	<LmUIQ9bkKPEHFw1g@pigsonthewing.org.uk>
	<1192297080.1923.21.camel@localhost.localdomain>
	<umHBgphpKREHFwR+@pigsonthewing.org.uk>
	<1192302879.1923.60.camel@localhost.localdomain>
	<50yk0Qk8DSEHFwDR@pigsonthewing.org.uk>
	<1192306262.1923.82.camel@localhost.localdomain>
	<994227DC-3DB0-4899-BF0B-93A905B7A770@julianstahnke.com>
Message-ID: <1192313365.1923.100.camel@localhost.localdomain>

On Sat, 2007-10-13 at 21:31 +0100, Julian Stahnke wrote:
> > Anyway there is only Me at the moment supporting using *item*  
> > instead of
> > a new microformat *track*
> 
> Nope, I too think item would be better. Maybe, if it is too  
> meaningless, together with haudio ? la <span class="item haudio">. I  
> don?t know enough about item to say if just item is enough, but I  
> think it even may be. Then again, if we could use item in such a way  
> that we could say ?if it is haudio, look for properties in child  
> nodes, otherwise use the content of item?, that?d be potentially nice  
> as well.

Thank you Julian i will take that as another vote FOR using *item*
instead of a new proposed microformat *track*

I think track is a too powerful a class name to be immediately used in
hAudio at the first opportunity we get

Track has a vast amount of meaning outside of hAudio, not many of which
mean the same thing.

http://www.answers.com/track&r=67

If we define track now in hAudio we will be stuck with it 
then potentially we will have the same problems as we do with the title
property in hCard

Thanks

Martin


From martin at weborganics.co.uk  Sat Oct 13 14:55:29 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 13 15:50:11 2007
Subject: [uf-new] Re: hAudio current thinking?
In-Reply-To: <qEHgopnruSEHFwjy@pigsonthewing.org.uk>
References: <1192302081.1923.54.camel@localhost.localdomain>
	<1192306510.1923.85.camel@localhost.localdomain>
	<qEHgopnruSEHFwjy@pigsonthewing.org.uk>
Message-ID: <1192312529.1923.89.camel@localhost.localdomain>

On Sat, 2007-10-13 at 21:33 +0100, Andy Mabbett wrote:
> In message <1192306510.1923.85.camel@localhost.localdomain>, Martin
> McEvoy <martin@weborganics.co.uk> writes
> 
> >[1] Single Track album known
> ><span class="haudio">
> >     <span class="track">
> >              <span class="fn>Nagasaki Nightmare</span>
> >       </span>
> >     <span class="album">Best Before 1984</span>
> >     <span class="contributor">Crass</span> </span>
> 
> >[5] Album with a couple of tracks, more detailed: <span class="haudio">
> >     <span class="album">Best Before 1984</span>
> >     <span class="contributor">Crass</span>
> >     <span class="track">
> >        <span class="fn">Nagasaki Nightmare</span> ?
> >        <span class="duration">4:46</span>
> >     </span>
> >     <span class="track">
> >        <span class="fn">Nagasaki Nightmare</span> ?
> >        <span class="duration">4:46</span>
> >     </span>
> >     <span class="track">
> >        <span class="fn">Nagasaki Nightmare</span> ?
> >        <span class="duration">4:46</span>
> >     </span>
> ></span>
> 
> How would these work, for tracks on a compilation album, by different
> artists? Or tracks on a one-album artist, but where one features a guest
> vocalist?

Not sure but Ill try

Basic examples...
...

[6] example with multiple contributors

<div class="haudio">
   <span class="album">Hip-Hop Essentials Vol. 3</span>
  <div class="track">
     <span class="fn">Parents Just Don't Understand</span> -
      <span class="contributor">Jazzy Jeff</span> & 
       <span class="contributor">Fresh Prince</span>
   </div>
</div>

...

[7] exmple of multiple album tracks in a compilation

<div class="haudio">
   <span class="album">The Complete Studio Recordings</span>
   <span class="contributor">Led Zeppelin</span>
    <span class="track">
        "<span class="fn">Good Times Bad Times</span>" - 
        taken from the album <span class="album">Led Zeppelin</span> - 
          <span class="duration">2:46</span>
      </span>
    <span class="track">
        "<span class="fn">Whole Lotta Love</span>" - 
        taken from the album <span class="album">Led Zeppelin II</span> 
         <span class="duration">5:34</span>
      </span>
</div>

...

[8] example of multiple artists albums and tracks

<div class="haudio">
   <span class="album">The Best of SKA</span>
    <span class="track">
     <span class="fn">On My Radio</span> by <span
class="contributor">Selecter</span> - 
     Taken from <span class="album">Too Much Pressure</span>
    </span>
    <span class="track">
     <span class="fn">Mirror in the Bathroom</span> by <span
class="contributor">The Beat</span> - 
     Taken from <span class="album">I Just Can't Stop It</span>
    </span>
   <span class="track">
     <span class="fn">My Girl</span> by <span
class="contributor">Madness</span> - 
      Taken from <span class="album">One Step Beyond</span>
    </span>
</div>

...

Example no [6] I cant see any issues

[7] and [8] probably need discussing


Thanks

Martin
 
> 

From martin at weborganics.co.uk  Sat Oct 13 15:50:56 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 13 15:56:27 2007
Subject: [uf-new] Re: hAudio current thinking?
In-Reply-To: <1192312529.1923.89.camel@localhost.localdomain>
References: <1192302081.1923.54.camel@localhost.localdomain>
	<1192306510.1923.85.camel@localhost.localdomain>
	<qEHgopnruSEHFwjy@pigsonthewing.org.uk>
	<1192312529.1923.89.camel@localhost.localdomain>
Message-ID: <1192315856.4577.6.camel@localhost.localdomain>

On Sat, 2007-10-13 at 22:55 +0100, Martin McEvoy wrote:
> On Sat, 2007-10-13 at 21:33 +0100, Andy Mabbett wrote:
> > In message <1192306510.1923.85.camel@localhost.localdomain>, Martin
> > McEvoy <martin@weborganics.co.uk> writes
> > 
> > >[1] Single Track album known
> > ><span class="haudio">
> > >     <span class="track">
> > >              <span class="fn>Nagasaki Nightmare</span>
> > >       </span>
> > >     <span class="album">Best Before 1984</span>
> > >     <span class="contributor">Crass</span> </span>
> > 
> > >[5] Album with a couple of tracks, more detailed: <span class="haudio">
> > >     <span class="album">Best Before 1984</span>
> > >     <span class="contributor">Crass</span>
> > >     <span class="track">
> > >        <span class="fn">Nagasaki Nightmare</span> ?
> > >        <span class="duration">4:46</span>
> > >     </span>
> > >     <span class="track">
> > >        <span class="fn">Nagasaki Nightmare</span> ?
> > >        <span class="duration">4:46</span>
> > >     </span>
> > >     <span class="track">
> > >        <span class="fn">Nagasaki Nightmare</span> ?
> > >        <span class="duration">4:46</span>
> > >     </span>
> > ></span>
> > 
> > How would these work, for tracks on a compilation album, by different
> > artists? Or tracks on a one-album artist, but where one features a guest
> > vocalist?
> 
> Not sure but Ill try
> 
> Basic examples...
> ...
> 
> [6] example with multiple contributors
> 
> <div class="haudio">
>    <span class="album">Hip-Hop Essentials Vol. 3</span>
>   <div class="track">
>      <span class="fn">Parents Just Don't Understand</span> -
>       <span class="contributor">Jazzy Jeff</span> & 
>        <span class="contributor">Fresh Prince</span>
>    </div>
> </div>
> 
> ...
> 
> [7] exmple of multiple album tracks in a compilation
> 
> <div class="haudio">
>    <span class="album">The Complete Studio Recordings</span>
>    <span class="contributor">Led Zeppelin</span>
>     <span class="track">
>         "<span class="fn">Good Times Bad Times</span>" - 
>         taken from the album <span class="album">Led Zeppelin</span> - 
>           <span class="duration">2:46</span>
>       </span>
>     <span class="track">
>         "<span class="fn">Whole Lotta Love</span>" - 
>         taken from the album <span class="album">Led Zeppelin II</span> 
>          <span class="duration">5:34</span>
>       </span>
> </div>
> 
> ...
> 
> [8] example of multiple artists albums and tracks
> 
> <div class="haudio">
>    <span class="album">The Best of SKA</span>
>     <span class="track">
>      <span class="fn">On My Radio</span> by <span
> class="contributor">Selecter</span> - 
>      Taken from <span class="album">Too Much Pressure</span>
>     </span>
>     <span class="track">
>      <span class="fn">Mirror in the Bathroom</span> by <span
> class="contributor">The Beat</span> - 
>      Taken from <span class="album">I Just Can't Stop It</span>
>     </span>
>    <span class="track">
>      <span class="fn">My Girl</span> by <span
> class="contributor">Madness</span> - 
>       Taken from <span class="album">One Step Beyond</span>
>     </span>
> </div>
> 
> ...
> 
> Example no [6] I cant see any issues
> 
> [7] and [8] probably need discussing

you know I think examples [7] and [8] show us that *album* is probably
not a good class name either or the markup needs to be changed to
something like:

...

[9] same as [8] but re-using hAudio

<div class="haudio">
   <span class="album">The Best of SKA</span>
</div>
<div class="haudio">
    <span class="track">
     <span class="fn">On My Radio</span> 
       </span>
        by <span class="contributor">Selecter</span> - 
     Taken from <span class="album">Too Much Pressure</span>
</div>
<div class="haudio">
    <span class="track">
     <span class="fn">Mirror in the Bathroom</span>
      </span>
       by <span class="contributor">The Beat</span> - 
     Taken from <span class="album">I Just Can't Stop It</span>
<div class="haudio">
   <span class="track">
     <span class="fn">My Girl</span> 
     </span>
      by <span class="contributor">Madness</span> - 
      Taken from <span class="album">One Step Beyond</span>
</div>

...

which seems a bit involved to me but makes a little more sense


Thanks

Martin

> 
> 
> Thanks
> 
> Martin
>  
> > 

From julian at julianstahnke.com  Sat Oct 13 14:18:24 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Sat Oct 13 16:29:42 2007
Subject: [uf-new] Re: hAudio current thinking?
In-Reply-To: <qEHgopnruSEHFwjy@pigsonthewing.org.uk>
References: <1192302081.1923.54.camel@localhost.localdomain>
	<1192306510.1923.85.camel@localhost.localdomain>
	<qEHgopnruSEHFwjy@pigsonthewing.org.uk>
Message-ID: <E7BA8354-0722-473A-8AD2-70F096EF04C0@julianstahnke.com>

> How would these work, for tracks on a compilation album, by different
> artists? Or tracks on a one-album artist, but where one features a  
> guest
> vocalist?

Would have no contributor in the haudio thing but only in the items.  
The latter would have an additional contributor in the respective item?
From tantek at cs.stanford.edu  Sat Oct 13 17:03:06 2007
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Sat Oct 13 17:02:12 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs. recording/album)
In-Reply-To: <50yk0Qk8DSEHFwDR@pigsonthewing.org.uk>
Message-ID: <C33695E7.95C42%tantek@cs.stanford.edu>

On 10/13/07 12:48 PM, "Andy Mabbett" <andy@pigsonthewing.org.uk> wrote:

> In message <1192302879.1923.60.camel@localhost.localdomain>, Martin
> McEvoy <martin@weborganics.co.uk> writes
> 
>> On Sat, 2007-10-13 at 19:47 +0100, Andy Mabbett wrote:
>>> In message <1192297080.1923.21.camel@localhost.localdomain>, Martin
>>> McEvoy <martin@weborganics.co.uk> writes
>>> 
>>>>> Item is semantically empty, other than as a container. We might as
>>> well
>>>>> say "thing".
>>> 
>>>> what is a track on your CD? Just a space, gap or marker nothing more
>>> 
>>> On the contrary, it has a distinct meaning, which defines it as being
>>> apart from the other "items" on a CD, such as an index, the performer,
>>> its catalogue number, or whatever.
>> 
>> Perhaps I am thinking to literally Item is just an Item? its the
>> contents of which that describe just what kind of item it is?
> 
> It's my understanding that "item" in microformats was intended purely as
> a delimiter, with the same - empty - semantic value as SPAN and DIV in
> HTML.

It is a container for subproperties (or a submicroformat) , in hReview,
similar to how "adr" is a container for subproperties.


> The hReview spec is unhelpful in this regard, specifying it thus:
> 
>       item info. required. fn (url || photo ) | hCard (for person or
>       business) | hCalendar (for event)
> 
> where "item" is in CODE tags but "info." is not, and is not explained.

What help were you expecting?  Perhaps I can add it either in the
specification or in a tutorial / authoring page.


> The subsequent definition gives:
> 
>       item info:: This required field MUST have at a minimum the name
>       ("fn" - the formatted text corresponding to the name, except for
>       an event item which MUST have the "summary" property inside the
>       respective hCalendar "vevent") of the item (an hReview describes
>       only one item), SHOULD provide at least one URI ("url") for the
>       item, and MAY provide at least one URL to a photo or depiction
>       ("photo") of the item. For items of type person or business, the
>       item info (fn, url, photo) MUST be encapsulated in an hCard. For
>       items of type event, the item info SHOULD be encapsulated in an
>       hCalendar "vevent". Non-URL unique item IDs (e.g. ISBNs, UPCs)
>       MAY be represented as a URN ("url") for the item. Encapsulated
>       microformats (e.g. hCard and hCalendar events for now) may be
>       set on the item itself (e.g. class="item vcard"). However, when
>       using item info subproperties ("fn", "url", "photo"), they MUST
>       be nested inside the item element.
> 
> and the use of "item" in the examples is not consistent:

Could you provide a specific explanation of which example is inconsistent
with which statement in the prose of the specification?

Or even if there is no specific inconsistency, if you could elaborate on how
the current prose/examples *seemed* inconsistent, even that is worth fixing.


The examples below are consistent with the specification quoted above as
follows:


>  *    <div class="description item vcard">
>               <p>
>               <span class="fn org">Crepes on Cole</span>
>               is one of the best little creperies in
>               <span class="adr">
>               <span class="locality">San Francisco</span>
>               </span>.
>               Excellent food and service. Plenty of tables in a
>               variety of sizes for parties large and small. Window
>               seating makes for excellent people watching to/from the
>               N-Judah which stops right outside. I've had many fun
>               social gatherings here, as well as gotten plenty of work
>               done thanks to neighborhood WiFi. </p>
>       </div>

This example uses the feature of the definition quoted:

       Encapsulated microformats (e.g. hCard and hCalendar events for now)
       may be set on the item itself (e.g. class="item vcard").


>  *    <div class="item vcard">
>               <div class="fn org summary">Cafe Borrone</div>
>               <span class="adr"> <span class="street-address">1010 El
>               Camino Real</span>, <span class="locality">Menlo
>               Park</span>, <span class="region">CA</span> <span
>               class="postal-code">94025</span>, </span>
>               <span class="tel">+1-650-327-0830</span>;
>               <a class="url"
>               href="http://cafeborrone.com">cafeborrone.com
>               </a>
>       </div>

As does this one.


>  *    <span class="item">
>               <a class="url fn"
>               href="http://www.amazon.com/exec/obidos/ASIN/B000089CJI/"
>> 
>               <img
>               src="http://images.amazon.com/images/P/B000089CJI.01._SCT
>               HUMBZZZ_.jpg" alt="Album cover photo: The Postal
>               Service: Give Up. " class="photo" />
>                The Postal Service: Give Up
>               </a>
>       </span>

This example shows an item which is a product (not a business nor an event),
and thus uses "url" and "fn" properties *inside* the item per the portion of
specification above quoted:

        when using item info subproperties ("fn", "url", "photo"), they MUST
        be nested inside the item element.


>  *    <div class="item">
>               <a lang="zh" class="url fn"
>               href="http://www.imdb.com/title/tt0299977/">
>               Ying Xiong (<span lang="en">HERO</span>)
>               </a>
>       </div>

As does this one.

Thanks,

Tantek

From tantek at cs.stanford.edu  Sat Oct 13 17:03:08 2007
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Sat Oct 13 17:02:21 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs. recording/album)
In-Reply-To: <1192306262.1923.82.camel@localhost.localdomain>
Message-ID: <C336A98F.95C44%tantek@cs.stanford.edu>

On 10/13/07 1:11 PM, "Martin McEvoy" <martin@weborganics.co.uk> wrote:

> On Sat, 2007-10-13 at 20:48 +0100, Andy Mabbett wrote:
>> 
>> It's my understanding that "item" in microformats was intended purely
>> as
>> a delimiter, with the same - empty - semantic value as SPAN and DIV in
>> HTML. 
> 
> the exact same semantics are mirrored In my suggestion in hAudio, do you
> not think that Item can be a powerful tool in microformats if we use it
> the same way as a div or a span in html?

Precisely.


> I think if we use track ...
> 
>    <span class="track">
>             <span class="fn>Nagasaki Nightmare</span>
>      </span>
> 
> in the context of hAudio does it have any more meaning than
> 
>    <span class="item">
>             <span class="fn>Nagasaki Nightmare</span>
>      </span>
> 
> track and item are both being used as container for which the contents
> describe what it is?

Correct, they appear to be isomorphic.


> Anyway there is only Me at the moment supporting using *item* instead of
> a new microformat *track*

I support re-use of "item" as well, rather than inventing a new term that
has apparently the same semantics, which would violate one of our naming
principles: re-use the same name to mean the same thing (instead of using
two names to mean the same thing).

http://microformats.org/wiki/naming-principles#Reuse

And regardless of the number of people, if you can point to a principle
supporting your position, your position is stronger.  Science is not a
democracy.

Thanks,

Tantek

From tantek at cs.stanford.edu  Sat Oct 13 17:09:47 2007
From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik)
Date: Sat Oct 13 17:08:33 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs. recording/album)
In-Reply-To: <C33695E7.95C42%tantek@cs.stanford.edu>
Message-ID: <C336AC51.95C62%tantek@cs.stanford.edu>

On 10/13/07 5:03 PM, "Tantek ?elik" <tantek@cs.stanford.edu> wrote:

>> The hReview spec is unhelpful in this regard, specifying it thus:
>> 
>>       item info. required. fn (url || photo ) | hCard (for person or
>>       business) | hCalendar (for event)
>> 
>> where "item" is in CODE tags but "info." is not, and is not explained.
> 
> What help were you expecting?  Perhaps I can add it either in the
> specification or in a tutorial / authoring page.

Upon re-reading my first question "... expecting?" I can see how it could be
interpreted as rhetorical impatience - which is not the intent at all.

I am actually interested in understanding what precise concepts you were
expecting to see documented but didn't find so that we may improve the
documentation both of hReview and in general in specifications.

Apologies for the reply to my own message but I wanted to make sure the tone
was not misunderstood.

Thanks,

Tantek


From martin at weborganics.co.uk  Sun Oct 14 04:33:26 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sun Oct 14 04:39:25 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs. recording/album)
In-Reply-To: <C33695E7.95C42%tantek@cs.stanford.edu>
References: <C33695E7.95C42%tantek@cs.stanford.edu>
Message-ID: <1192361606.9987.4.camel@localhost.localdomain>

On Sat, 2007-10-13 at 17:03 -0700, Tantek =?ISO-8859-1?B?xw==?=elik
wrote:
> On 10/13/07 12:48 PM, "Andy Mabbett" <andy@pigsonthewing.org.uk> wrote:
> 
> > In message <1192302879.1923.60.camel@localhost.localdomain>, Martin
> > McEvoy <martin@weborganics.co.uk> writes
> > 
> >> On Sat, 2007-10-13 at 19:47 +0100, Andy Mabbett wrote:
> >>> In message <1192297080.1923.21.camel@localhost.localdomain>, Martin
> >>> McEvoy <martin@weborganics.co.uk> writes
> >>> 
> >>>>> Item is semantically empty, other than as a container. We might as
> >>> well
> >>>>> say "thing".
> >>> 
> >>>> what is a track on your CD? Just a space, gap or marker nothing more
> >>> 
> >>> On the contrary, it has a distinct meaning, which defines it as being
> >>> apart from the other "items" on a CD, such as an index, the performer,
> >>> its catalogue number, or whatever.
> >> 
> >> Perhaps I am thinking to literally Item is just an Item? its the
> >> contents of which that describe just what kind of item it is?
> > 
> > It's my understanding that "item" in microformats was intended purely as
> > a delimiter, with the same - empty - semantic value as SPAN and DIV in
> > HTML.
> 
> It is a container for subproperties (or a submicroformat)

*submicroformat* is an excellent description

The Rest of your message was intended for Andy I think, :)



Thanks

Martin

>  , in hReview,
> similar to how "adr" is a container for subproperties.
> 
> 
> > The hReview spec is unhelpful in this regard, specifying it thus:
> > 
> >       item info. required. fn (url || photo ) | hCard (for person or
> >       business) | hCalendar (for event)
> > 
> > where "item" is in CODE tags but "info." is not, and is not explained.
> 
> What help were you expecting?  Perhaps I can add it either in the
> specification or in a tutorial / authoring page.
> 
> 
> > The subsequent definition gives:
> > 
> >       item info:: This required field MUST have at a minimum the name
> >       ("fn" - the formatted text corresponding to the name, except for
> >       an event item which MUST have the "summary" property inside the
> >       respective hCalendar "vevent") of the item (an hReview describes
> >       only one item), SHOULD provide at least one URI ("url") for the
> >       item, and MAY provide at least one URL to a photo or depiction
> >       ("photo") of the item. For items of type person or business, the
> >       item info (fn, url, photo) MUST be encapsulated in an hCard. For
> >       items of type event, the item info SHOULD be encapsulated in an
> >       hCalendar "vevent". Non-URL unique item IDs (e.g. ISBNs, UPCs)
> >       MAY be represented as a URN ("url") for the item. Encapsulated
> >       microformats (e.g. hCard and hCalendar events for now) may be
> >       set on the item itself (e.g. class="item vcard"). However, when
> >       using item info subproperties ("fn", "url", "photo"), they MUST
> >       be nested inside the item element.
> > 
> > and the use of "item" in the examples is not consistent:
> 
> Could you provide a specific explanation of which example is inconsistent
> with which statement in the prose of the specification?
> 
> Or even if there is no specific inconsistency, if you could elaborate on how
> the current prose/examples *seemed* inconsistent, even that is worth fixing.
> 
> 
> The examples below are consistent with the specification quoted above as
> follows:
> 
> 
> >  *    <div class="description item vcard">
> >               <p>
> >               <span class="fn org">Crepes on Cole</span>
> >               is one of the best little creperies in
> >               <span class="adr">
> >               <span class="locality">San Francisco</span>
> >               </span>.
> >               Excellent food and service. Plenty of tables in a
> >               variety of sizes for parties large and small. Window
> >               seating makes for excellent people watching to/from the
> >               N-Judah which stops right outside. I've had many fun
> >               social gatherings here, as well as gotten plenty of work
> >               done thanks to neighborhood WiFi. </p>
> >       </div>
> 
> This example uses the feature of the definition quoted:
> 
>        Encapsulated microformats (e.g. hCard and hCalendar events for now)
>        may be set on the item itself (e.g. class="item vcard").
> 
> 
> >  *    <div class="item vcard">
> >               <div class="fn org summary">Cafe Borrone</div>
> >               <span class="adr"> <span class="street-address">1010 El
> >               Camino Real</span>, <span class="locality">Menlo
> >               Park</span>, <span class="region">CA</span> <span
> >               class="postal-code">94025</span>, </span>
> >               <span class="tel">+1-650-327-0830</span>;
> >               <a class="url"
> >               href="http://cafeborrone.com">cafeborrone.com
> >               </a>
> >       </div>
> 
> As does this one.
> 
> 
> >  *    <span class="item">
> >               <a class="url fn"
> >               href="http://www.amazon.com/exec/obidos/ASIN/B000089CJI/"
> >> 
> >               <img
> >               src="http://images.amazon.com/images/P/B000089CJI.01._SCT
> >               HUMBZZZ_.jpg" alt="Album cover photo: The Postal
> >               Service: Give Up. " class="photo" />
> >                The Postal Service: Give Up
> >               </a>
> >       </span>
> 
> This example shows an item which is a product (not a business nor an event),
> and thus uses "url" and "fn" properties *inside* the item per the portion of
> specification above quoted:
> 
>         when using item info subproperties ("fn", "url", "photo"), they MUST
>         be nested inside the item element.
> 
> 
> >  *    <div class="item">
> >               <a lang="zh" class="url fn"
> >               href="http://www.imdb.com/title/tt0299977/">
> >               Ying Xiong (<span lang="en">HERO</span>)
> >               </a>
> >       </div>
> 
> As does this one.
> 
> Thanks,
> 
> Tantek
> 

From davidjanes at blogmatrix.com  Sun Oct 14 06:50:05 2007
From: davidjanes at blogmatrix.com (David Janes)
Date: Sun Oct 14 07:14:41 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <C336A98F.95C44%tantek@cs.stanford.edu>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
Message-ID: <21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>

On 10/13/07, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> On 10/13/07 1:11 PM, "Martin McEvoy" <martin@weborganics.co.uk> wrote:
>
> > On Sat, 2007-10-13 at 20:48 +0100, Andy Mabbett wrote:
> >>
> >> It's my understanding that "item" in microformats was intended purely
> >> as
> >> a delimiter, with the same - empty - semantic value as SPAN and DIV in
> >> HTML.
> >
> > the exact same semantics are mirrored In my suggestion in hAudio, do you
> > not think that Item can be a powerful tool in microformats if we use it
> > the same way as a div or a span in html?
>
> Precisely.
>
>
> > I think if we use track ...
> >
> >    <span class="track">
> >             <span class="fn>Nagasaki Nightmare</span>
> >      </span>
> >
> > in the context of hAudio does it have any more meaning than
> >
> >    <span class="item">
> >             <span class="fn>Nagasaki Nightmare</span>
> >      </span>
> >
> > track and item are both being used as container for which the contents
> > describe what it is?
>
> Correct, they appear to be isomorphic.
>
>
> > Anyway there is only Me at the moment supporting using *item* instead of
> > a new microformat *track*
>
> I support re-use of "item" as well, rather than inventing a new term that
> has apparently the same semantics, which would violate one of our naming
> principles: re-use the same name to mean the same thing (instead of using
> two names to mean the same thing).
>
> http://microformats.org/wiki/naming-principles#Reuse

Note that a did a moderate amount of work on this last year [1],
looking over the options as isolating item as it's own microformat, as
a design pattern, or as a microformat explicitly designed to be used
as a composite. Also supported by examples [2] and formats [3]

Regards, etc...

[1] http://microformats.org/wiki/item
[2] http://microformats.org/wiki/item-examples
[3] http://microformats.org/wiki/item-formats

-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com

From martin at weborganics.co.uk  Sun Oct 14 08:08:29 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sun Oct 14 08:07:34 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs. recording/album)
In-Reply-To: <21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
Message-ID: <1192374509.9987.17.camel@localhost.localdomain>

On Sun, 2007-10-14 at 08:50 -0500, David Janes wrote:
> On 10/13/07, Tantek ?elik <tantek@cs.stanford.edu> wrote:
> > On 10/13/07 1:11 PM, "Martin McEvoy" <martin@weborganics.co.uk> wrote:
> >
> > > On Sat, 2007-10-13 at 20:48 +0100, Andy Mabbett wrote:
> > >>
> > >> It's my understanding that "item" in microformats was intended purely
> > >> as
> > >> a delimiter, with the same - empty - semantic value as SPAN and DIV in
> > >> HTML.
> > >
> > > the exact same semantics are mirrored In my suggestion in hAudio, do you
> > > not think that Item can be a powerful tool in microformats if we use it
> > > the same way as a div or a span in html?
> >
> > Precisely.
> >
> >
> > > I think if we use track ...
> > >
> > >    <span class="track">
> > >             <span class="fn>Nagasaki Nightmare</span>
> > >      </span>
> > >
> > > in the context of hAudio does it have any more meaning than
> > >
> > >    <span class="item">
> > >             <span class="fn>Nagasaki Nightmare</span>
> > >      </span>
> > >
> > > track and item are both being used as container for which the contents
> > > describe what it is?
> >
> > Correct, they appear to be isomorphic.
> >
> >
> > > Anyway there is only Me at the moment supporting using *item* instead of
> > > a new microformat *track*
> >
> > I support re-use of "item" as well, rather than inventing a new term that
> > has apparently the same semantics, which would violate one of our naming
> > principles: re-use the same name to mean the same thing (instead of using
> > two names to mean the same thing).
> >
> > http://microformats.org/wiki/naming-principles#Reuse
> 
> Note that a did a moderate amount of work on this last year [1],
> looking over the options as isolating item as it's own microformat, as
> a design pattern, or as a microformat explicitly designed to be used
> as a composite. Also supported by examples [2] and formats [3]

yes I did notice that you have done a lot of work already to support an
item design pattern or submicroformat

On the Wiki Item has been tagged as Moribund? 

discussions on the list over the last few days certainly indicates that
an Item submicroformat may be an extremely important tool

Is there a reason Item never became a proposal? and also can you see any
reasons why *Item* cannot be completed?

Thanks

Martin
> 
> Regards, etc...
> 
> [1] http://microformats.org/wiki/item
> [2] http://microformats.org/wiki/item-examples
> [3] http://microformats.org/wiki/item-formats
> 

From davidjanes at blogmatrix.com  Sun Oct 14 08:37:50 2007
From: davidjanes at blogmatrix.com (David Janes)
Date: Sun Oct 14 08:37:52 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <1192374509.9987.17.camel@localhost.localdomain>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
Message-ID: <21e523c20710140837i1fdc763by81cf7ed4cab2fe03@mail.gmail.com>

On 10/14/07, Martin McEvoy <martin@weborganics.co.uk> wrote:
> yes I did notice that you have done a lot of work already to support an
> item design pattern or submicroformat
>
> On the Wiki Item has been tagged as Moribund?
>
> discussions on the list over the last few days certainly indicates that
> an Item submicroformat may be an extremely important tool
>
> Is there a reason Item never became a proposal? and also can you see any
> reasons why *Item* cannot be completed?
>
> Thanks
>
> Martin

I suspect it's marked moribund since there's been no activity in the
last year. I personally think it's a great idea, especially since it's
a refinement/distillation of what is already out there and think we
should complete it.

The reason it never became an official proposal is more complicated,
mainly that unless you have a cadre of interested people willing to do
the work ... and there's a lot ... it's pretty hard to individually
push a complete uF through the process here. As there were several
competing ideas at the time around uFs for "things", last year perhaps
wasn't the time.

Regards, etc...

-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
From davidjanes at blogmatrix.com  Sun Oct 14 08:39:21 2007
From: davidjanes at blogmatrix.com (David Janes)
Date: Sun Oct 14 08:39:23 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <21e523c20710140837i1fdc763by81cf7ed4cab2fe03@mail.gmail.com>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<21e523c20710140837i1fdc763by81cf7ed4cab2fe03@mail.gmail.com>
Message-ID: <21e523c20710140839i7c689b10t5ad85169ae1278a0@mail.gmail.com>

On 10/14/07, David Janes <davidjanes@blogmatrix.com> wrote:

... and also since the discussion of how uFs nest together (cf "fn"
issues) wasn't solved to anyone's satisification ...

-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
From andy at pigsonthewing.org.uk  Sun Oct 14 09:26:52 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sun Oct 14 09:28:10 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <C33695E7.95C42%tantek@cs.stanford.edu>
References: <50yk0Qk8DSEHFwDR@pigsonthewing.org.uk>
	<C33695E7.95C42%tantek@cs.stanford.edu>
Message-ID: <6FO04n4MNkEHFwhv@pigsonthewing.org.uk>

In message <C33695E7.95C42%tantek@cs.stanford.edu>, Tantek ?elik 
<tantek@cs.stanford.edu> writes

>> It's my understanding that "item" in microformats was intended purely as
>> a delimiter, with the same - empty - semantic value as SPAN and DIV in
>> HTML.
>
>It is a container for subproperties (or a submicroformat) , in hReview,
>similar to how "adr" is a container for subproperties.

Quite, we use "adr" not "item", because "adr" (meaning "address") is a 
more precise, and thus more semantically meaningful, container - it 
names the thing it contains.

>> The hReview spec is unhelpful in this regard, specifying it thus:
>>
>>       item info. required. fn (url || photo ) | hCard (for person or
>>       business) | hCalendar (for event)
>>
>> where "item" is in CODE tags but "info." is not, and is not explained.
>
>What help were you expecting?  Perhaps I can add it either in the
>specification or in a tutorial / authoring page.

A definition of item, in the context of the review microformat, without 
the apparently stray textual fragment of "info."

The use of "pipe" separators and parentheses, without a clear statement 
of their meaning, is also unhelpful.

>> The subsequent definition gives:
[...]
>> and the use of "item" in the examples is not consistent:
>
>Could you provide a specific explanation of which example is inconsistent
>with which statement in the prose of the specification?

Now you're asking me to provide examples of something I haven't stated.

>The examples below are consistent with the specification quoted above

but not with each other.

-- 
Andy Mabbett

From andy at pigsonthewing.org.uk  Sun Oct 14 09:27:57 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sun Oct 14 09:29:36 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <C336AC51.95C62%tantek@cs.stanford.edu>
References: <C33695E7.95C42%tantek@cs.stanford.edu>
	<C336AC51.95C62%tantek@cs.stanford.edu>
Message-ID: <kVuz8T5NOkEHFwCt@pigsonthewing.org.uk>

In message <C336AC51.95C62%tantek@cs.stanford.edu>, Tantek ?elik 
<tantek@cs.stanford.edu> writes

>Apologies for the reply to my own message but I wanted to make sure the 
>tone was not misunderstood.

Thank you, but unnecessary; it wasn't.

-- 
Andy Mabbett

From andy at pigsonthewing.org.uk  Sun Oct 14 09:21:16 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sun Oct 14 09:32:45 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <C336A98F.95C44%tantek@cs.stanford.edu>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
Message-ID: <EGiL4038HkEHFwn4@pigsonthewing.org.uk>

In message <C336A98F.95C44%tantek@cs.stanford.edu>, Tantek ?elik 
<tantek@cs.stanford.edu> writes

>I support re-use of "item" as well, rather than inventing a new term 
>that has apparently the same semantics, which would violate one of our 
>naming principles: re-use the same name to mean the same thing (instead 
>of using two names to mean the same thing).

The two names do not mean the same thing. "item" means "a thing" "track" 
(for example) names that thing, and distinguishes it from other things.

>And regardless of the number of people, if you can point to a principle 
>supporting your position, your position is stronger.  Science is not a 
>democracy.

Nether is science the act of citing made-up principles.

-- 
Andy Mabbett

From andy at pigsonthewing.org.uk  Sun Oct 14 09:42:40 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sun Oct 14 09:44:20 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <1192374509.9987.17.camel@localhost.localdomain>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
Message-ID: <PFd5I36AckEHFwHf@pigsonthewing.org.uk>

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

>On Sun, 2007-10-14 at 08:50 -0500, David Janes wrote:

>> Note that a did a moderate amount of work on this last year [1]

>yes I did notice that you have done a lot of work already to support an
>item design pattern or submicroformat

>> [1] http://microformats.org/wiki/item

In which, David Janes said:

        hItem should [...] not be a general purpose dumping ground for
        attributes

-- 
Andy Mabbett
From martin at weborganics.co.uk  Sun Oct 14 11:12:09 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sun Oct 14 11:11:21 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs. recording/album)
In-Reply-To: <PFd5I36AckEHFwHf@pigsonthewing.org.uk>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
Message-ID: <1192385529.9987.31.camel@localhost.localdomain>

On Sun, 2007-10-14 at 17:42 +0100, Andy Mabbett wrote:
> In message <1192374509.9987.17.camel@localhost.localdomain>, Martin
> McEvoy <martin@weborganics.co.uk> writes
> 
> >On Sun, 2007-10-14 at 08:50 -0500, David Janes wrote:
> 
> >> Note that a did a moderate amount of work on this last year [1]
> 
> >yes I did notice that you have done a lot of work already to support an
> >item design pattern or submicroformat
> 
> >> [1] http://microformats.org/wiki/item
> 
> In which, David Janes said:
> 
>         hItem should [...] not be a general purpose dumping ground for
>         attributes
> 

Item suits our type purpose definition

>From the audio-info-proposal

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

Field details Track

A container for another hAudio item. Used in conjunction with
album-title. 

      * The element is identified by the class name track.
      * hAudio MAY have one or more tracks, but MUST have album-title
        defined. If album-title is not defined, track cannot be defined.
      * The element MUST be processed opaquely. No sub-elements should
        be read from any hAudio contained in a track element.
      * The contents of the element MAY be plain-text or marked up using
        hAudio.

I also think that if we go ahead and use TRACK then we WILL be causing
huge problems when it comes to "future" microformats as TRACK has more
than one meaning not many of which match out Definition

http://www.answers.com/track&r=67

TRACK has many meaning and no single meaning in the real world

How would you feel when it comes to marking up hRacetrack, or
hTraintrack and you find that hAudio has already defined TRACK to mean

"A container for another hAudio item"

Thanks

Martin



From soc at code404.com  Sun Oct 14 11:21:50 2007
From: soc at code404.com (Justin Maxwell)
Date: Sun Oct 14 11:21:57 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <1192385529.9987.31.camel@localhost.localdomain>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
Message-ID: <D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>

On Oct 14, 2007, at 11:12 AM, Martin McEvoy wrote:

> A container for another hAudio item. Used in conjunction with
> album-title.
>
>  [snip]
>       * hAudio MAY have one or more tracks, but MUST have album-title
>         defined. If album-title is not defined, track cannot be  
> defined.

Sorry to be jumping in late here, but I'm afraid this poses a problem  
with self-titled albums, of which there are many in existence.   
Unless the implementer is forced to input "S/T" or "self-titled" as  
album-name, which is still incorrect because that's not what the  
creator has named the album, the model fails.

Thanks,
Justin
From msporny at digitalbazaar.com  Sun Oct 14 11:30:47 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Oct 14 11:30:51 2007
Subject: [uf-new] 6 hAudio issues closed
Message-ID: <47126057.5070007@digitalbazaar.com>

I'm marking the following issues as closed on the hAudio issues page.
Each has a solution in the current hAudio proposal that most seem to be
comfortable with using.

Changes can be seen here:

http://microformats.org/wiki/audio-info-issues#Resolved_Issues

Details are below:

hAudio ISSUE #1: image-summary Property is redundant
 - PHOTO has been used to replace image-summary in the latest proposal,
   reusing a previous Microformat property, which is a Good Thing(tm).
 - http://microformats.org/wiki/audio-info-proposal#Photo

hAudio ISSUE #3:  published-date Property is redundant
 - PUBLISHED has been used to replace published-date in the latest
   proposal, reusing a previous Microformat property, which is a Good
   Thing (tm).
 -http://microformats.org/wiki/audio-info-issues#published-date_Property

hAudio ISSUE #6: Summary Property is Missing
 - DESCRIPTION has been added to the latest proposal.
 - http://microformats.org/wiki/audio-info-proposal#Description

hAudio ISSUE #7: Track Number is Missing
 - POSITION has been added to the hAudio proposal, thus resolving this
   issue.
 - http://microformats.org/wiki/audio-info-proposal#Position

hAudio ISSUE #8: hAlbum is redundant
 - We now have the ALBUM-TITLE and TRACK elements in hAudio, there is no
   longer a need for hAlbum.
 - http://microformats.org/wiki/audio-info-proposal#Schema

hAudio ISSUE #12: CONTRIBUTOR and TRACK are not publisher friendly
 - Short forms for CONTRIBUTOR and TRACK are proposed in the newest
   proposal and doesn't seem to cause any parsing problems or
   compatibility issues with other Microformats.
 - http://microformats.org/wiki/audio-info-proposal#Contributor
 - http://microformats.org/wiki/audio-info-proposal#Track

-- manu

From soc at code404.com  Sun Oct 14 11:36:54 2007
From: soc at code404.com (Justin Maxwell)
Date: Sun Oct 14 11:36:53 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
Message-ID: <8FC3583C-AC10-422A-9407-0D202A6BD268@code404.com>

Also, regarding "track" vs. "item."

"Track" is familiar and common.  I believe I'd even recommended its  
use at one time.  However, it's nothing more than a distortion of  
meaning through popular usage -- "tracks" in a vinyl record (similar  
to the use of "patch" for electronic musical instrumentation stemming  
from the days of patch cables).  The CD industry picked up this term  
as well as it replies to physical sectors on the disc itself.   
However, there is no "track" in data and we should eliminate an  
unnecessary literal abstraction (one that will eventually require  
explanation) by calling it as such.  So, as unfamiliar as it is to my  
ears, I recommend "item" for this role.

Thanks,
Justin
From julian at julianstahnke.com  Sun Oct 14 11:45:20 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Sun Oct 14 11:45:25 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
Message-ID: <C66FAA82-14AF-4816-A727-0DE2668B7AA2@julianstahnke.com>

>> A container for another hAudio item. Used in conjunction with
>> album-title.
>>
>>  [snip]
>>       * hAudio MAY have one or more tracks, but MUST have album-title
>>         defined. If album-title is not defined, track cannot be  
>> defined.
>
> Sorry to be jumping in late here, but I'm afraid this poses a  
> problem with self-titled albums, of which there are many in  
> existence.  Unless the implementer is forced to input "S/T" or  
> "self-titled" as album-name, which is still incorrect because  
> that's not what the creator has named the album, the model fails.

I don?t think you can make album-title mandatory. Unless you can tell  
me what album Martin Luther King?s ?I have a dream? speech is on ;)

There are far too many mentions of tracks which include only artist  
name and track name to require album-title, in my opinion. Take a  
look at music blogs, for example.

You should definitely not need to mention an album as it may be  
inconvenient, the track may not have an album yet or is not a music  
track but a speech or something hence not having an album at all.
From msporny at digitalbazaar.com  Sun Oct 14 11:47:45 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Oct 14 11:47:47 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs. recording/album)
In-Reply-To: <D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
References: <1192306262.1923.82.camel@localhost.localdomain>	<C336A98F.95C44%tantek@cs.stanford.edu>	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>	<1192374509.9987.17.camel@localhost.localdomain>	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
Message-ID: <47126451.9040009@digitalbazaar.com>

Justin Maxwell wrote:
> On Oct 14, 2007, at 11:12 AM, Martin McEvoy wrote:
> 
>> A container for another hAudio item. Used in conjunction with
>> album-title.
>>
>>  [snip]
>>       * hAudio MAY have one or more tracks, but MUST have album-title
>>         defined. If album-title is not defined, track cannot be defined.
> 
> Sorry to be jumping in late here, but I'm afraid this poses a problem
> with self-titled albums, of which there are many in existence.  Unless
> the implementer is forced to input "S/T" or "self-titled" as album-name,
> which is still incorrect because that's not what the creator has named
> the album, the model fails.

I don't think it does, Justin... let me know if this mark-up doesn't
work. The example album is Celldweller:

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

This album is a self-titled release by Celldweller.

<div class="haudio">
 <span class="fn album contributor">Celldweller</span>
 just released their first self-titled album.
</div>

You can mention tracks for self-titled albums fairly easily with the
newest set of proposals:

<div class="haudio">
 <span class="fn album contributor">Celldweller</span>
 just released their first self-titled album. You might have heard the
 first song on the album, <span class="track">Switchback</span>. Another
 good song is <span class="track">Symbiont</span>.
</div>

Is that what you were concerned about?

-- manu


From julian at julianstahnke.com  Sun Oct 14 11:49:33 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Sun Oct 14 11:49:37 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <8FC3583C-AC10-422A-9407-0D202A6BD268@code404.com>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<8FC3583C-AC10-422A-9407-0D202A6BD268@code404.com>
Message-ID: <FC825804-A971-43CF-825B-5C35016396BC@julianstahnke.com>

> "Track" is familiar and common.  I believe I'd even recommended its  
> use at one time.  However, it's nothing more than a distortion of  
> meaning through popular usage -- "tracks" in a vinyl record  
> (similar to the use of "patch" for electronic musical  
> instrumentation stemming from the days of patch cables).  The CD  
> industry picked up this term as well as it replies to physical  
> sectors on the disc itself.  However, there is no "track" in data  
> and we should eliminate an unnecessary literal abstraction (one  
> that will eventually require explanation) by calling it as such.   
> So, as unfamiliar as it is to my ears, I recommend "item" for this  
> role.

I second that. Item is better in my opinion. Imagine you mark up the  
different movements of classical music or something like that. Would  
you call them track? (Well, maybe you would, but, uh, anyway ;)) Or  
implement another movement property? Or parts of speeches, stuff like  
that.

I know I?ve been in favour of track just a couple of days ago, but I  
didn?t see the implications of this. I vote for item. Would also be  
nice to have as a generic container microformat, as mentioned here  
before.
From msporny at digitalbazaar.com  Sun Oct 14 11:54:37 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Oct 14 11:54:40 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs.	recording/album)
In-Reply-To: <C66FAA82-14AF-4816-A727-0DE2668B7AA2@julianstahnke.com>
References: <1192306262.1923.82.camel@localhost.localdomain>	<C336A98F.95C44%tantek@cs.stanford.edu>	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>	<1192374509.9987.17.camel@localhost.localdomain>	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>	<1192385529.9987.31.camel@localhost.localdomain>	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<C66FAA82-14AF-4816-A727-0DE2668B7AA2@julianstahnke.com>
Message-ID: <471265ED.5060108@digitalbazaar.com>

Julian Stahnke wrote:
>>> A container for another hAudio item. Used in conjunction with
>>> album-title.
>>>
>>>  [snip]
>>>       * hAudio MAY have one or more tracks, but MUST have album-title
>>>         defined. If album-title is not defined, track cannot be defined.
>>
>> Sorry to be jumping in late here, but I'm afraid this poses a problem
>> with self-titled albums, of which there are many in existence.  Unless
>> the implementer is forced to input "S/T" or "self-titled" as
>> album-name, which is still incorrect because that's not what the
>> creator has named the album, the model fails.
> 
> I don?t think you can make album-title mandatory. Unless you can tell me
> what album Martin Luther King?s ?I have a dream? speech is on ;)
> 
> There are far too many mentions of tracks which include only artist name
> and track name to require album-title, in my opinion. Take a look at
> music blogs, for example.
> 
> You should definitely not need to mention an album as it may be
> inconvenient, the track may not have an album yet or is not a music
> track but a speech or something hence not having an album at all.

The meaning that you have understood was not the intent of that text...
it needs to be clarified on the wiki.

I was attempting to state that if you want to use multiple tracks in one
hAudio, you should name the album. If you don't want to name the album
single hAudios should be used, for example:

<div class="haudio">
 <span class="fn album contributor">Celldweller</span> contains
 <span class="track">Switchback</span> and
 <span class="track">Symbiont</span>.
</div>

We don't want people doing the following:

 <div class="haudio">
  <span class="track">Switchback</span> and
  <span class="track">Symbiont</span>.
 </div>

The above should be marked up like this:

 Two songs that I like are
 <div class="haudio">
    <span class="fn">Switchback</span>
 </div>
 <div class="haudio"> and
    <span class="fn">Symbiont</span>.
 </div>

-- manu
From martin at weborganics.co.uk  Sun Oct 14 11:56:46 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sun Oct 14 11:55:52 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs. recording/album)
In-Reply-To: <C66FAA82-14AF-4816-A727-0DE2668B7AA2@julianstahnke.com>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<C66FAA82-14AF-4816-A727-0DE2668B7AA2@julianstahnke.com>
Message-ID: <1192388206.9987.34.camel@localhost.localdomain>

Julian and Justin

On Sun, 2007-10-14 at 19:45 +0100, Julian Stahnke wrote:
> >> A container for another hAudio item. Used in conjunction with
> >> album-title.
> >>
> >>  [snip]
> >>       * hAudio MAY have one or more tracks, but MUST have album-title
> >>         defined. If album-title is not defined, track cannot be  
> >> defined.
> >
> > Sorry to be jumping in late here, but I'm afraid this poses a  
> > problem with self-titled albums, of which there are many in  
> > existence.  Unless the implementer is forced to input "S/T" or  
> > "self-titled" as album-name, which is still incorrect because  
> > that's not what the creator has named the album, the model fails.
> 
> I don?t think you can make album-title mandatory. Unless you can tell  
> me what album Martin Luther King?s ?I have a dream? speech is on ;)

I agree album-title SHOULD not be mandatory

> 
> There are far too many mentions of tracks which include only artist  
> name and track name to require album-title, in my opinion. Take a  
> look at music blogs, for example.
> 
> You should definitely not need to mention an album as it may be  
> inconvenient, the track may not have an album yet or is not a music  
> track but a speech or something hence not having an album at all.

Thanks

Martin
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From soc at code404.com  Sun Oct 14 12:00:55 2007
From: soc at code404.com (Justin Maxwell)
Date: Sun Oct 14 12:00:54 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <47126451.9040009@digitalbazaar.com>
References: <1192306262.1923.82.camel@localhost.localdomain>	<C336A98F.95C44%tantek@cs.stanford.edu>	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>	<1192374509.9987.17.camel@localhost.localdomain>	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<47126451.9040009@digitalbazaar.com>
Message-ID: <C6891363-5F9B-40C1-8263-E344CECEA369@code404.com>

Thanks for clarifying that -- your follow-up email to Julian helped  
illustrate usage as well.  It seems a bit odd taxonomically (my  
initial reaction is that an album without a name shouldn't be  
assigned one for the sake of microformats), but acceptable if it  
means we're coming closer to a final working proposal :)

On Oct 14, 2007, at 11:47 AM, Manu Sporny wrote:

> Justin Maxwell wrote:
>> On Oct 14, 2007, at 11:12 AM, Martin McEvoy wrote:
>>
>>> A container for another hAudio item. Used in conjunction with
>>> album-title.
>>>
>>>  [snip]
>>>       * hAudio MAY have one or more tracks, but MUST have album- 
>>> title
>>>         defined. If album-title is not defined, track cannot be  
>>> defined.
>>
>> Sorry to be jumping in late here, but I'm afraid this poses a problem
>> with self-titled albums, of which there are many in existence.   
>> Unless
>> the implementer is forced to input "S/T" or "self-titled" as album- 
>> name,
>> which is still incorrect because that's not what the creator has  
>> named
>> the album, the model fails.
>
> I don't think it does, Justin... let me know if this mark-up doesn't
> work. The example album is Celldweller:
>
> http://www.bitmunk.com/view/media/6068744
>
> This album is a self-titled release by Celldweller.
>
> <div class="haudio">
>  <span class="fn album contributor">Celldweller</span>
>  just released their first self-titled album.
> </div>
>
> You can mention tracks for self-titled albums fairly easily with the
> newest set of proposals:
>
> <div class="haudio">
>  <span class="fn album contributor">Celldweller</span>
>  just released their first self-titled album. You might have heard the
>  first song on the album, <span class="track">Switchback</span>.  
> Another
>  good song is <span class="track">Symbiont</span>.
> </div>
>
> Is that what you were concerned about?
>
> -- manu
>
>
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From msporny at digitalbazaar.com  Sun Oct 14 12:01:49 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Oct 14 12:01:52 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs. recording/album)
In-Reply-To: <1192388206.9987.34.camel@localhost.localdomain>
References: <1192306262.1923.82.camel@localhost.localdomain>	<C336A98F.95C44%tantek@cs.stanford.edu>	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>	<1192374509.9987.17.camel@localhost.localdomain>	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>	<1192385529.9987.31.camel@localhost.localdomain>	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>	<C66FAA82-14AF-4816-A727-0DE2668B7AA2@julianstahnke.com>
	<1192388206.9987.34.camel@localhost.localdomain>
Message-ID: <4712679D.9030005@digitalbazaar.com>

Martin McEvoy wrote:
> Justin
>> I don?t think you can make album-title mandatory. Unless you can tell  
>> me what album Martin Luther King?s ?I have a dream? speech is on ;)

It's not on an album, and would be marked up like so, per the current
approach:

<div class="haudio">	
   <span class="fn">I Have a Dream</span>, a
   <span class="category">speech</span> by
   <span class="contributor">Martin Luther King, Jr.</span>
</div>	

album-title is NOT mandatory. It is only mandatory when you're listing
one or more TRACKs.

-- manu

From paul_wilkins at xtra.co.nz  Sun Oct 14 12:10:54 2007
From: paul_wilkins at xtra.co.nz (paul_wilkins@xtra.co.nz)
Date: Sun Oct 14 12:10:59 2007
Subject: [uf-new] I propose a new microformat for poems.
Message-ID: <82945.6869.qm@web96001.mail.aue.yahoo.com>

From: Andy Mabbett <andy@pigsonthewing.org.uk>
> ><l>
> 
> ><span class="l">
> 
> <line> and <span class="line"> would be better.


They may be better, but you'll have to take that up with the XHTML 2.0 working group.

Here is the working draft for the XHTML 2.0 L element.
http://www.w3.org/TR/xhtml2/mod-text.html#edef_text_l

-- 
Paul Wilkins




From andy at pigsonthewing.org.uk  Sun Oct 14 12:10:03 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sun Oct 14 12:11:29 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs.	recording/album)
In-Reply-To: <8FC3583C-AC10-422A-9407-0D202A6BD268@code404.com>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<8FC3583C-AC10-422A-9407-0D202A6BD268@code404.com>
Message-ID: <G5P7n7BLmmEHFwlX@pigsonthewing.org.uk>

In message <8FC3583C-AC10-422A-9407-0D202A6BD268@code404.com>, Justin
Maxwell <soc@code404.com> writes

>"Track" is familiar and common.

>However, it's nothing more than a distortion of  meaning through
>popular usage -- "tracks" in a vinyl record (similar  to the use of
>"patch" for electronic musical instrumentation stemming  from the days
>of patch cables).  The CD industry picked up this term  as well as it
>replies to physical sectors on the disc itself.   However, there is no
>"track" in data and we should eliminate an  unnecessary literal
>abstraction (one that will eventually require  explanation) by calling
>it as such.

What do you mean by "there is no 'track' in data"?

I thought we created microformats by looking at evidence, not
considering personal opinions and supposition about what may be
understood at dome unknown point in the future.

If people refer to a songs or other recording as a "track" - as the
evidence [1] shows they do - then we should use that.


[1] -   <http://tinyurl.com/yvekd2>
        <http://tinyurl.com/ywg8qu>
        <http://tinyurl.com/2kq96z>

-- 
Andy Mabbett
From andy at pigsonthewing.org.uk  Sun Oct 14 12:14:08 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sun Oct 14 12:15:31 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs.	recording/album)
In-Reply-To: <C66FAA82-14AF-4816-A727-0DE2668B7AA2@julianstahnke.com>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<C66FAA82-14AF-4816-A727-0DE2668B7AA2@julianstahnke.com>
Message-ID: <$Jd1LvCAqmEHFwhM@pigsonthewing.org.uk>

In message <C66FAA82-14AF-4816-A727-0DE2668B7AA2@julianstahnke.com>, 
Julian Stahnke <julian@julianstahnke.com> writes

>I don?t think you can make album-title mandatory. Unless you can tell 
>me what album Martin Luther King?s ?I have a dream? speech is on ;)

'Great Speeches of the 20th Century', issues free with the Guardian 
newspaper this summer (I have a copy right here next to my PC):

   <http://blogs.guardian.co.uk/podcasts/2007/04/newsdesk_notes_for_friday_apri_4.html>

Do I get a prize? ;-)

-- 
Andy Mabbett

From paul_wilkins at xtra.co.nz  Sun Oct 14 12:24:09 2007
From: paul_wilkins at xtra.co.nz (paul_wilkins@xtra.co.nz)
Date: Sun Oct 14 12:24:12 2007
Subject: [uf-new] hAudio: audio-title/album-title vs. recording/album
Message-ID: <604973.94966.qm@web96011.mail.aue.yahoo.com>

From: Andy Mabbett <andy@pigsonthewing.org.uk>
> Scott Reynen <scott@makedatamakesense.com> writes
> > That shouldn't  slow down hAudio progress.  In this case, someone 
> >wrote "P268T" as a  long form of "4:46", when it should have been 
> >"P286T".  Typo aside,  that follows established microformat use of 
> ><abbr> and ISO 8601.
> 
> I didn't even notice the typo; "4:46", in plain English, is no more an 
> abbreviation of "P286T" than it is of "P268T".

I If we're talking about ISO 8601, the format is P<date>T<time>
http://en.wikipedia.org/wiki/ISO_8601#Duration

The representation for 4:46 would be PT4M46S 

Making the code sample look like
<abbr class="duration" title="PT4M46S">4:46</abbr>

-- 
Paul Wilkins




From scott at makedatamakesense.com  Sun Oct 14 12:31:09 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sun Oct 14 12:31:09 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <C66FAA82-14AF-4816-A727-0DE2668B7AA2@julianstahnke.com>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<C66FAA82-14AF-4816-A727-0DE2668B7AA2@julianstahnke.com>
Message-ID: <BF8004C8-5B64-4021-B230-E18E3B20A033@makedatamakesense.com>

On Oct 14, 2007, at 12:45 PM, Julian Stahnke wrote:

>>> A container for another hAudio item. Used in conjunction with
>>> album-title.
>>>
>>>  [snip]
>>>       * hAudio MAY have one or more tracks, but MUST have album- 
>>> title
>>>         defined. If album-title is not defined, track cannot be  
>>> defined.
>>
>> Sorry to be jumping in late here, but I'm afraid this poses a  
>> problem with self-titled albums, of which there are many in  
>> existence.  Unless the implementer is forced to input "S/T" or  
>> "self-titled" as album-name, which is still incorrect because  
>> that's not what the creator has named the album, the model fails.
>
> I don?t think you can make album-title mandatory. Unless you can  
> tell me what album Martin Luther King?s ?I have a dream? speech is  
> on ;)
>
> There are far too many mentions of tracks which include only artist  
> name and track name to require album-title, in my opinion. Take a  
> look at music blogs, for example.
>
> You should definitely not need to mention an album as it may be  
> inconvenient, the track may not have an album yet or is not a music  
> track but a speech or something hence not having an album at all.
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

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



From davidjanes at blogmatrix.com  Sun Oct 14 12:31:13 2007
From: davidjanes at blogmatrix.com (David Janes)
Date: Sun Oct 14 12:31:15 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <FC825804-A971-43CF-825B-5C35016396BC@julianstahnke.com>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<8FC3583C-AC10-422A-9407-0D202A6BD268@code404.com>
	<FC825804-A971-43CF-825B-5C35016396BC@julianstahnke.com>
Message-ID: <21e523c20710141231q2d62c962na0a672cfcd16996@mail.gmail.com>

Just to give some insight into what I was thinking with hItem:

<div class="haudio">
 <span class="fn album contributor">Celldweller</span> contains
 <span class="item track"><span class="fn">Switchback</span></span> and
 <span class="item track"><span class="fn">Symbiont</span></span>.
</div>

What does this get you?

(1) forever and ever, no matter how "track" evolves with hAudio,
parses will _always_ know that attributes within the item associate to
the "track", not to hAudio
(2) hAudio doesn't have to spec what's in track if it already gets it from hItem
(3) If there was _some other sort of item_ with auto ... say "studio"
... the purpose of having "item" & "track" together makes more sense

Regards, etc...
From andy at pigsonthewing.org.uk  Sun Oct 14 12:31:05 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sun Oct 14 12:32:21 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs.	recording/album)
In-Reply-To: <C6891363-5F9B-40C1-8263-E344CECEA369@code404.com>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<47126451.9040009@digitalbazaar.com>
	<C6891363-5F9B-40C1-8263-E344CECEA369@code404.com>
Message-ID: <4Zj0v8D55mEHFwBC@pigsonthewing.org.uk>

In message <C6891363-5F9B-40C1-8263-E344CECEA369@code404.com>, Justin
Maxwell <soc@code404.com> writes

>my  initial reaction is that an album without a name shouldn't be
>assigned one for the sake of microformats

Again: what do publishers do?

   *    Amazon uses a title: <http://tinyurl.com/34gfjo>

   *    Play.com uses a title: <http://tinyurl.com/2pzznr>

   *    HMV uses a title: <http://tinyurl.com/34z9pm>

and so on...

-- 
Andy Mabbett
From msporny at digitalbazaar.com  Sun Oct 14 13:01:27 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Oct 14 13:01:31 2007
Subject: [uf-new] hAudio proposal: ITEM/TRACK
In-Reply-To: <C6891363-5F9B-40C1-8263-E344CECEA369@code404.com>
References: <1192306262.1923.82.camel@localhost.localdomain>	<C336A98F.95C44%tantek@cs.stanford.edu>	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>	<1192374509.9987.17.camel@localhost.localdomain>	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>	<1192385529.9987.31.camel@localhost.localdomain>	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>	<47126451.9040009@digitalbazaar.com>
	<C6891363-5F9B-40C1-8263-E344CECEA369@code404.com>
Message-ID: <47127597.10006@digitalbazaar.com>

The problem:

We need some sort of "container" to hold track/song information in an
hAudio album. The contents of this "container" will be another hAudio
chunk or text (which will be the FN of an hAudio object).

There are two proposals that are on the table right now. The end result
and semantics for hAudio are the same, the only thing that we are
discussing is the name of that "container".

TRACK or ITEM

Using TRACK means creating a new Microformat property that, while
specific, is not re-using ITEM. There is also contention over whether
this accurately describes a part of an album.

Using ITEM means that we will be changing the current definition of ITEM:

-----------------------------------------------------------------------

"item - hReview - The item that the object exists for. For example, a
review about Coca-Cola would list "Coca-Cola" as the item."[1]

"item info:: This required field MUST have at a minimum the name ("fn" -
the formatted text corresponding to the name, except for an event item
which MUST have the "summary" property inside the respective hCalendar
"vevent") of the item (an hReview describes only one item), SHOULD
provide at least one URI ("url") for the item, and MAY provide at least
one URL to a photo or depiction ("photo") of the item. For items of type
person or business, the item info (fn, url, photo) MUST be encapsulated
in an hCard. For items of type event, the item info SHOULD be
encapsulated in an hCalendar "vevent". Non-URL unique item IDs (e.g.
ISBNs, UPCs) MAY be represented as a URN ("url") for the item.
Encapsulated microformats (e.g. hCard and hCalendar events for now) may
be set on the item itself (e.g. class="item vcard"). However, when using
item info subproperties ("fn", "url", "photo"), they MUST be nested
inside the item element."[2]

"item info:: This required field MUST have at a minimum the name ("fn" -
the formatted text corresponding to the name) of the item , SHOULD
provide at least one URI ("url") for the item, and MAY provide at least
one URL to a photo or depiction ("photo") of the item. For items of type
person or business, the item info (fn, url, photo) SHOULD be
encapsulated in an hCard. Unique item IDs (e.g. ISBNs, UPCs) MAY be
represented as a URN ("url") for the item."[3]

-----------------------------------------------------------------------

However, it seems that there is support from a number of people to
re-use ITEM because it achieves two things (moves hAudio forward AND
simultaneously creates a generic "bag/hset/container" concept for
Microformats... something that we've been attempting to do for over a year.

We don't want to break backwards compatability, so we have to work with
the current definitions of item for hReview and hListing by defining
ITEM as the following, which can be used across all Microformats:

-----------------------------------------------------------------------

ITEM - A generic method that Microformats use for unordered containment
of other Microformat properties or objects. This property MUST have, at
a minimum, the name of the item. The name of the item can be specified
using either:

  a) plain-text, if the property contains only the name of the item.
  b) "fn", if the property contains multiple Microformat properties.

ITEM MAY contain other properties/Microformats, but anything other than
FN must be defined by the Microformat that is using ITEM.

-----------------------------------------------------------------------

The above definition doesn't require hReview or hListing to change at
all. It also means that we can use it like so in hAudio:

Single track, with known album (same as putting text in the ?album?
field of an ID3 tag):
<span class="haudio">
    <span class="fn">Nagasaki Nightmare</span>
    <span class="album">Best Before 1984</span>
    <span class="contributor">Crass</span>
</span>

Single track, album unknown:
<span class="haudio">
    <span class="fn">Nagasaki Nightmare</span>
    <span class="contributor">Crass</span>
</span>

Album:
<span class="haudio">
    <span class="fn album">Best Before 1984</span>
    <span class="contributor">Crass</span>
</span>

Album with a couple of tracks, simple example:
<span class="haudio">
    <span class="fn album">Best Before 1984</span>
    <span class="contributor">Crass</span>
    <span class="item">Nagasaki Nightmare</span>
    <span class="item">Hokkaido Dream</span>
    <span class="item">Tokyo Groove</span>
</span>

Album with a couple of tracks, more detailed:
<span class="haudio">
    <span class="fn album">Best Before 1984</span>
    <span class="contributor">Crass</span>
    <span class="item haudio"><span class="fn">Nagasaki Nightmare</span>
? <abbr class="duration" title="P268T">4:46</abbr></span>
    <span class="item haudio"><span class="fn">Nagasaki Nightmare</span>
? <abbr class="duration" title="P268T">4:46</abbr></span>
    <span class="item haudio"><span class="fn">Nagasaki Nightmare</span>
? <abbr class="duration" title="P268T">4:46</abbr></span>
</span>

-- manu

PS: Andy, Martin - I'm just as frustrated with this approach as I'm sure
both of you are, especially since it was deemed that we couldn't change
TITLE from hCard... but now we're changing the meaning, quite blatantly,
for ITEM.

[1] http://microformats.org/wiki/existing-classes
[2] http://microformats.org/wiki/hreview#Field_details
[3] http://microformats.org/wiki/hlisting#Item_Metadata
From martin at weborganics.co.uk  Sun Oct 14 13:10:47 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sun Oct 14 13:09:51 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs.	recording/album)
In-Reply-To: <G5P7n7BLmmEHFwlX@pigsonthewing.org.uk>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<8FC3583C-AC10-422A-9407-0D202A6BD268@code404.com>
	<G5P7n7BLmmEHFwlX@pigsonthewing.org.uk>
Message-ID: <1192392647.9987.43.camel@localhost.localdomain>

On Sun, 2007-10-14 at 20:10 +0100, Andy Mabbett wrote:
> In message <8FC3583C-AC10-422A-9407-0D202A6BD268@code404.com>, Justin
> Maxwell <soc@code404.com> writes
> 
> >"Track" is familiar and common.
> 
> >However, it's nothing more than a distortion of  meaning through
> >popular usage -- "tracks" in a vinyl record (similar  to the use of
> >"patch" for electronic musical instrumentation stemming  from the days
> >of patch cables).  The CD industry picked up this term  as well as it
> >replies to physical sectors on the disc itself.   However, there is no
> >"track" in data and we should eliminate an  unnecessary literal
> >abstraction (one that will eventually require  explanation) by calling
> >it as such.
> 
> What do you mean by "there is no 'track' in data"?
> 
> I thought we created microformats by looking at evidence, not
> considering personal opinions and supposition about what may be
> understood at dome unknown point in the future.
> 
> If people refer to a songs or other recording as a "track" - as the
> evidence [1] shows they do - then we should use that.
> 
> 
> [1] -   <http://tinyurl.com/yvekd2>
>         <http://tinyurl.com/ywg8qu>
>         <http://tinyurl.com/2kq96z>

Seems like you are NOT making your point

[1] http://tinyurl.com/2vzag4
[2] http://tinyurl.com/2jvbms
[3] http://tinyurl.com/2lj5x2
[4] http://tinyurl.com/2lbs9a
[5] http://tinyurl.com/343jjy
[6] http://tinyurl.com/2tc9ch

I could go on all night giving you different examples of different
meanings of "TRACK", I hope I don't have to.

Am I making My point?

Thanks

Martin

> 

From soc at code404.com  Sun Oct 14 13:15:52 2007
From: soc at code404.com (Justin Maxwell)
Date: Sun Oct 14 13:15:51 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs.	recording/album)
In-Reply-To: <G5P7n7BLmmEHFwlX@pigsonthewing.org.uk>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<8FC3583C-AC10-422A-9407-0D202A6BD268@code404.com>
	<G5P7n7BLmmEHFwlX@pigsonthewing.org.uk>
Message-ID: <2D84A83F-CA01-46AA-93BA-3FB10AF12DFF@code404.com>

On Oct 14, 2007, at 12:10 PM, Andy Mabbett wrote:

> What do you mean by "there is no 'track' in data"?
>
> I thought we created microformats by looking at evidence, not
> considering personal opinions and supposition about what may be
> understood at dome unknown point in the future.

Hi Andy,

and i thought i was helping define a microformat, not practicing my  
skill in public debate.  so, we're even. :)

moving on...

"there is no 'track' in data."  I wrote that thinking it was self- 
explanatory and obvious, so, sorry if it seemed too abstract.  a  
"track" refers to a physically demonstrable "track" in a recording  
medium, whether that track is a set of continuous grooves divided by  
physical markers, or a series of sectors on a CD/DVD divided by start  
and end markers.  In short, "track" is a term reserved for physical,  
tangible media.  Its usage in digital media derived from the  
translation of physical recorded media, making intangible  
representations of their physical counterparts (e.g., iTunes), and  
the textual cataloging of media information (e.g., Amazon, Discogs).

> If people refer to a songs or other recording as a "track" - as the
> evidence [1] shows they do - then we should use that.
>
> [1] -   <http://tinyurl.com/yvekd2>
>         <http://tinyurl.com/ywg8qu>
>         <http://tinyurl.com/2kq96z>

good point!  however, people also refer to items as "songs," but a  
google search on "'spoken word' songs" (and similar variations of non- 
musical recorded genres, such as "audiobook +songs") gives evidence  
that popular usage is incorrect as well.  So it's easy to find  
evidence of people using both "track" and "song," but neither are  
correct.  If we have the opportunity to define a standard, why not go  
with one -- "item" -- that is universally correct?

--

At the risk of being tangental, I'd like to illustrate the problem I  
previously mentioned in my last post about "patch," and the enormous  
taxonomical snafu that's been for the electronic music instrument  
industry.  I write this intending to support the kind of problems  
"track" and "song" present when using them out of their original  
context, but understand it could unfortunately be irrelevant  
supposition...

Early programmable synthesizers consisted of a series of functionally- 
specific modules.  To set up a playable instrument from the hardware,  
the user employed patch cables between modules.  Over time, this  
activity became known as "patching," the configuration could be  
transcribed on a blank "patch sheet" [1], and users referred to these  
configurations as "patches."  When memory first surfaced in consumer  
hardware, manufacturers chose to continue use of the term "patch"  
even though no patch cables were anywhere in sight.

Fast forward 25 years.  The market now uses "ensemble," "instrument  
settings," "multi," "preset," "tone," and a handful of other terms  
all for the same thing, but more than anything else, it still uses  
"patch." And nearly every time "patch" is used in a product, the  
manual includes a few paragraphs explaining what the word "patch"  
means and why the user needs to think in this way.

I see this as an opportunity to prevent our involvement in a similar,  
unnecessary abstraction.  That's all.

Thanks for your time,
Justin

[1] http://www.yawgmoth.com/files/arp2600patch.jpg



From msporny at digitalbazaar.com  Sun Oct 14 14:03:55 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Oct 14 14:03:57 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs. recording/album)
In-Reply-To: <2D84A83F-CA01-46AA-93BA-3FB10AF12DFF@code404.com>
References: <1192306262.1923.82.camel@localhost.localdomain>	<C336A98F.95C44%tantek@cs.stanford.edu>	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>	<1192374509.9987.17.camel@localhost.localdomain>	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>	<1192385529.9987.31.camel@localhost.localdomain>	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>	<8FC3583C-AC10-422A-9407-0D202A6BD268@code404.com>	<G5P7n7BLmmEHFwlX@pigsonthewing.org.uk>
	<2D84A83F-CA01-46AA-93BA-3FB10AF12DFF@code404.com>
Message-ID: <4712843B.5070709@digitalbazaar.com>

Justin Maxwell wrote:
> and i thought i was helping define a microformat, not practicing my
> skill in public debate.  so, we're even. :)

You must be new here. This is the New Microformats Community. We don't
actually create Microformats, instead we endlessly debate the meaning of
words and their implied semantics. Sometimes we argue with one another
just for the hell of it. We are at our best on the weekends, when sane
people are outside, enjoying their time off from work. :)

>> If people refer to a songs or other recording as a "track" - as the
>> evidence [1] shows they do - then we should use that.

Andy, Martin, Justin, and everyone else that is asserting that TRACK has
multiple, different meanings: You are all correct.

TRACK has multiple definitions, nobody is arguing that it doesn't.
ITEM is also not as semantically accurate as TRACK in hAudio.

This thread has been identified as hAudio ISSUE #13 and has been
recorded on the wiki. Please go and leave your feedback/preference for
TRACK or ITEM if you have been involved in this conversation:

http://microformats.org/wiki/audio-info-issues#Problem:_Container_property_naming

-- manu


From martin at weborganics.co.uk  Sun Oct 14 14:10:03 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sun Oct 14 14:09:07 2007
Subject: [uf-new] hAudio proposal: ITEM/TRACK
In-Reply-To: <47127597.10006@digitalbazaar.com>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<47126451.9040009@digitalbazaar.com>
	<C6891363-5F9B-40C1-8263-E344CECEA369@code404.com>
	<47127597.10006@digitalbazaar.com>
Message-ID: <1192396203.9987.49.camel@localhost.localdomain>

On Sun, 2007-10-14 at 16:01 -0400, Manu Sporny wrote:
> The problem:
> 
> We need some sort of "container" to hold track/song information in an
> hAudio album. The contents of this "container" will be another hAudio
> chunk or text (which will be the FN of an hAudio object).
> 
> There are two proposals that are on the table right now. The end result
> and semantics for hAudio are the same, the only thing that we are
> discussing is the name of that "container".
> 
> TRACK or ITEM
> 
> Using TRACK means creating a new Microformat property that, while
> specific, is not re-using ITEM. There is also contention over whether
> this accurately describes a part of an album.
> 
> Using ITEM means that we will be changing the current definition of ITEM:
> 
> -----------------------------------------------------------------------
> 
> "item - hReview - The item that the object exists for. For example, a
> review about Coca-Cola would list "Coca-Cola" as the item."[1]
> 
> "item info:: This required field MUST have at a minimum the name ("fn" -
> the formatted text corresponding to the name, except for an event item
> which MUST have the "summary" property inside the respective hCalendar
> "vevent") of the item (an hReview describes only one item), SHOULD
> provide at least one URI ("url") for the item, and MAY provide at least
> one URL to a photo or depiction ("photo") of the item. For items of type
> person or business, the item info (fn, url, photo) MUST be encapsulated
> in an hCard. For items of type event, the item info SHOULD be
> encapsulated in an hCalendar "vevent". Non-URL unique item IDs (e.g.
> ISBNs, UPCs) MAY be represented as a URN ("url") for the item.
> Encapsulated microformats (e.g. hCard and hCalendar events for now) may
> be set on the item itself (e.g. class="item vcard"). However, when using
> item info subproperties ("fn", "url", "photo"), they MUST be nested
> inside the item element."[2]
> 
> "item info:: This required field MUST have at a minimum the name ("fn" -
> the formatted text corresponding to the name) of the item , SHOULD
> provide at least one URI ("url") for the item, and MAY provide at least
> one URL to a photo or depiction ("photo") of the item. For items of type
> person or business, the item info (fn, url, photo) SHOULD be
> encapsulated in an hCard. Unique item IDs (e.g. ISBNs, UPCs) MAY be
> represented as a URN ("url") for the item."[3]
> 
> -----------------------------------------------------------------------
> 
> However, it seems that there is support from a number of people to
> re-use ITEM because it achieves two things (moves hAudio forward AND
> simultaneously creates a generic "bag/hset/container" concept for
> Microformats... something that we've been attempting to do for over a year.
> 
> We don't want to break backwards compatability, so we have to work with
> the current definitions of item for hReview and hListing by defining
> ITEM as the following, which can be used across all Microformats:
> 
> -----------------------------------------------------------------------
> 
> ITEM - A generic method that Microformats use for unordered containment
> of other Microformat properties or objects. This property MUST have, at
> a minimum, the name of the item. The name of the item can be specified
> using either:
> 
>   a) plain-text, if the property contains only the name of the item.
>   b) "fn", if the property contains multiple Microformat properties.
> 
> ITEM MAY contain other properties/Microformats, but anything other than
> FN must be defined by the Microformat that is using ITEM.
> 
> -----------------------------------------------------------------------
> 
> The above definition doesn't require hReview or hListing to change at
> all. It also means that we can use it like so in hAudio:
> 
> Single track, with known album (same as putting text in the ?album?
> field of an ID3 tag):
> <span class="haudio">
>     <span class="fn">Nagasaki Nightmare</span>
>     <span class="album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
> </span>
> 
> Single track, album unknown:
> <span class="haudio">
>     <span class="fn">Nagasaki Nightmare</span>
>     <span class="contributor">Crass</span>
> </span>
> 
> Album:
> <span class="haudio">
>     <span class="fn album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
> </span>
> 
> Album with a couple of tracks, simple example:
> <span class="haudio">
>     <span class="fn album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
>     <span class="item">Nagasaki Nightmare</span>
>     <span class="item">Hokkaido Dream</span>
>     <span class="item">Tokyo Groove</span>
> </span>
> 
> Album with a couple of tracks, more detailed:
> <span class="haudio">
>     <span class="fn album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
>     <span class="item haudio"><span class="fn">Nagasaki Nightmare</span>
> ? <abbr class="duration" title="P268T">4:46</abbr></span>
>     <span class="item haudio"><span class="fn">Nagasaki Nightmare</span>
> ? <abbr class="duration" title="P268T">4:46</abbr></span>
>     <span class="item haudio"><span class="fn">Nagasaki Nightmare</span>
> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> </span>
> 
> -- manu
> 
> PS: Andy, Martin - I'm just as frustrated with this approach as I'm sure
> both of you are, especially since it was deemed that we couldn't change
> TITLE from hCard... but now we're changing the meaning, quite blatantly,
> for ITEM.

Hi Manu very thorough summary can you clarify one thing for me
How are we quite blatantly changing the meaning for ITEM?

[1] http://microformats.org/wiki/item

...

Thanks

Martin
> 
> [1] http://microformats.org/wiki/existing-classes
> [2] http://microformats.org/wiki/hreview#Field_details
> [3] http://microformats.org/wiki/hlisting#Item_Metadata
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From martin at weborganics.co.uk  Sun Oct 14 14:16:32 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sun Oct 14 14:15:37 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs. recording/album)
In-Reply-To: <4712843B.5070709@digitalbazaar.com>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<8FC3583C-AC10-422A-9407-0D202A6BD268@code404.com>
	<G5P7n7BLmmEHFwlX@pigsonthewing.org.uk>
	<2D84A83F-CA01-46AA-93BA-3FB10AF12DFF@code404.com>
	<4712843B.5070709@digitalbazaar.com>
Message-ID: <1192396592.9987.55.camel@localhost.localdomain>

On Sun, 2007-10-14 at 17:03 -0400, Manu Sporny wrote:
> Justin Maxwell wrote:
> > and i thought i was helping define a microformat, not practicing my
> > skill in public debate.  so, we're even. :)
> 
> You must be new here. This is the New Microformats Community. We don't
> actually create Microformats, instead we endlessly debate the meaning of
> words and their implied semantics. Sometimes we argue with one another
> just for the hell of it. We are at our best on the weekends, when sane
> people are outside, enjoying their time off from work. :)

 +1 to Manu
> 
> >> If people refer to a songs or other recording as a "track" - as the
> >> evidence [1] shows they do - then we should use that.
> 
> Andy, Martin, Justin, and everyone else that is asserting that TRACK has
> multiple, different meanings: You are all correct.
> 
> TRACK has multiple definitions, nobody is arguing that it doesn't.
> ITEM is also not as semantically accurate as TRACK in hAudio.
> 
> This thread has been identified as hAudio ISSUE #13 and has been
> recorded on the wiki. Please go and leave your feedback/preference for
> TRACK or ITEM if you have been involved in this conversation:
> 
> http://microformats.org/wiki/audio-info-issues#Problem:_Container_property_naming
> 
> -- manu
> 
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From andy at pigsonthewing.org.uk  Sun Oct 14 14:38:21 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sun Oct 14 14:39:41 2007
Subject: [uf-new] item property (was: hAudio:
	audio-title/album-title	vs.	recording/album)
In-Reply-To: <1192392647.9987.43.camel@localhost.localdomain>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<8FC3583C-AC10-422A-9407-0D202A6BD268@code404.com>
	<G5P7n7BLmmEHFwlX@pigsonthewing.org.uk>
	<1192392647.9987.43.camel@localhost.localdomain>
Message-ID: <IVu48fINxoEHFwnT@pigsonthewing.org.uk>

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

>> If people refer to a songs or other recording as a "track" - as the
>> evidence [1] shows they do - then we should use that.
>>
>>
>> [1] -   <http://tinyurl.com/yvekd2>
>>         <http://tinyurl.com/ywg8qu>
>>         <http://tinyurl.com/2kq96z>
>
>Seems like you are NOT making your point

Thank you, but my point was stated explicitly.

>[1] http://tinyurl.com/2vzag4
>[2] http://tinyurl.com/2jvbms
>[3] http://tinyurl.com/2lj5x2
>[4] http://tinyurl.com/2lbs9a
>[5] http://tinyurl.com/343jjy
>[6] http://tinyurl.com/2tc9ch
>
>I could go on all night giving you different examples of different 
>meanings of "TRACK", I hope I don't have to.

Please don't feel you have do something so pointless on my account.

>Am I making My point?

Not clearly, no.

-- 
Andy Mabbett
From andy at pigsonthewing.org.uk  Sun Oct 14 14:44:24 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sun Oct 14 14:45:45 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <2D84A83F-CA01-46AA-93BA-3FB10AF12DFF@code404.com>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<8FC3583C-AC10-422A-9407-0D202A6BD268@code404.com>
	<G5P7n7BLmmEHFwlX@pigsonthewing.org.uk>
	<2D84A83F-CA01-46AA-93BA-3FB10AF12DFF@code404.com>
Message-ID: <cFj9oQJ42oEHFwEL@pigsonthewing.org.uk>

In message <2D84A83F-CA01-46AA-93BA-3FB10AF12DFF@code404.com>, Justin 
Maxwell <soc@code404.com> writes

>On Oct 14, 2007, at 12:10 PM, Andy Mabbett wrote:
>
>> What do you mean by "there is no 'track' in data"?
>>
>> I thought we created microformats by looking at evidence, not
>> considering personal opinions and supposition about what may be
>> understood at dome unknown point in the future.

>and i thought i was helping define a microformat, not practicing my 
>skill in public debate.  so, we're even. :)

Given that this is a debate, carried out in public, I can't see why you 
were under the misapprehension that you're not doing both.

>moving on...
>
>"there is no 'track' in data."  I wrote that thinking it was self- 
>explanatory and obvious, so, sorry if it seemed too abstract.  a 
>"track" refers to a physically demonstrable "track" in a recording 
>medium, whether that track is a set of continuous grooves divided by 
>physical markers, or a series of sectors on a CD/DVD divided by start 
>and end markers.  In short, "track" is a term reserved for physical, 
>tangible media.

And now used to refer to a song or other piece of music. We're concerned 
with current usage, not etymology.

>> If people refer to a songs or other recording as a "track" - as the
>> evidence [1] shows they do - then we should use that.
>>
>> [1] -   <http://tinyurl.com/yvekd2>
>>         <http://tinyurl.com/ywg8qu>
>>         <http://tinyurl.com/2kq96z>
>
>good point!  however, people also refer to items as "songs,"

Some tracks are songs, others are not. All songs, though, are tracks.

> but a  google search on "'spoken word' songs" (and similar variations 
>of non- musical recorded genres, such as "audiobook +songs") gives 
>evidence  that popular usage is incorrect as well.

I don't see what it is, that leads you to that conclusion.

>  So it's easy to find  evidence of people using both "track" and 
>"song," but neither are  correct.  If we have the opportunity to define 
>a standard, why not go  with one -- "item" -- that is universally 
>correct?

Because it's semantically barren.

-- 
Andy Mabbett
From scott at makedatamakesense.com  Sun Oct 14 14:56:05 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sun Oct 14 14:56:05 2007
Subject: [uf-new] hAudio proposal: ITEM/TRACK
In-Reply-To: <47127597.10006@digitalbazaar.com>
References: <1192306262.1923.82.camel@localhost.localdomain>	<C336A98F.95C44%tantek@cs.stanford.edu>	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>	<1192374509.9987.17.camel@localhost.localdomain>	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>	<1192385529.9987.31.camel@localhost.localdomain>	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>	<47126451.9040009@digitalbazaar.com>
	<C6891363-5F9B-40C1-8263-E344CECEA369@code404.com>
	<47127597.10006@digitalbazaar.com>
Message-ID: <0C631978-7446-41EC-8426-559C374CDB2A@makedatamakesense.com>

On Oct 14, 2007, at 2:01 PM, Manu Sporny wrote:

> We need some sort of "container" to hold track/song information in an
> hAudio album. The contents of this "container" will be another hAudio
> chunk or text (which will be the FN of an hAudio object).

I hope this doesn't complicate matters further, but the way Manu  
phrased this gave me an idea for a third solution to this problem:  
use class="haudio" alone.  Any hAudio without an album property is  
already assumed to be a single track.  If the only reason we're  
specifying this with an additional class name of "track" or "item" is  
to allow for track listings in name-only shorthand, why don't we just  
allow that shorthand with hAudio itself?  I.e. make the following  
semantically identical:

<span class="haudio"><span class="fn">My Way</span></span>
<span class="haudio">My Way</span>

That would remove the need for an additional class name, and also  
make it easier for publishers to use hAudio in its minimal form even  
without surrounding albums.  This would be somewhat similar to  
hCard's implied n optimization, only simpler.

One drawback: this would make it impossible to use hAudio markup for  
a song mentioned in the context of an album that is not a track of  
that album.  The song could still be mentioned, just not marked up  
with hAudio without implying it's a track of the surrounding album.   
I'm not sure whether or not that's common enough to be a reason for  
using another class name.

--
Scott Reynen
MakeDataMakeSense.com


From msporny at digitalbazaar.com  Sun Oct 14 15:14:05 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Oct 14 15:14:07 2007
Subject: [uf-new] hAudio proposal: ITEM/TRACK
In-Reply-To: <1192396203.9987.49.camel@localhost.localdomain>
References: <1192306262.1923.82.camel@localhost.localdomain>	<C336A98F.95C44%tantek@cs.stanford.edu>	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>	<1192374509.9987.17.camel@localhost.localdomain>	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>	<1192385529.9987.31.camel@localhost.localdomain>	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>	<47126451.9040009@digitalbazaar.com>	<C6891363-5F9B-40C1-8263-E344CECEA369@code404.com>	<47127597.10006@digitalbazaar.com>
	<1192396203.9987.49.camel@localhost.localdomain>
Message-ID: <471294AD.1040001@digitalbazaar.com>

Martin McEvoy wrote:
>> PS: Andy, Martin - I'm just as frustrated with this approach as I'm sure
>> both of you are, especially since it was deemed that we couldn't change
>> TITLE from hCard... but now we're changing the meaning, quite blatantly,
>> for ITEM.
> 
> Hi Manu very thorough summary can you clarify one thing for me
> How are we quite blatantly changing the meaning for ITEM?
> 
> [1] http://microformats.org/wiki/item

I should have ended my statement with "Let's not argue core Microformat
principles, but instead focus on the issue at hand: naming". :)

I'm not referring to the hItem proposal you linked to, Martin. hItem is
a non-issue since it isn't anywhere close to the Draft stage in the
Microformats process.

Instead, I was referring to the definitions for ITEM that already exist.
ITEM is defined in both hReview and hListing. I copy/pasted the contents
of these definitions at the start of this thread.

>From what I understand, it is one of those unwritten Microformats
principles that we don't change the definitions of Microformat
properties. I think you remember the TITLE discussion for hAudio:

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

Andy has also pointed out that we would be re-writing/re-purposing the
Microformat semantics of ITEM, which has previously been taboo. You have
traditionally disagreed with the definition of TITLE (as defined in
hCard) as well.

I was merely stating that we should overlook the flip-flop that the
community is doing and examine if ITEM is a good choice. In other words
- let's assume the prior definition that I stated earlier in this thread
for ITEM and go from there.

-- manu

From msporny at digitalbazaar.com  Sun Oct 14 15:20:30 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Oct 14 15:20:33 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs.	recording/album)
In-Reply-To: <cFj9oQJ42oEHFwEL@pigsonthewing.org.uk>
References: <1192306262.1923.82.camel@localhost.localdomain>	<C336A98F.95C44%tantek@cs.stanford.edu>	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>	<1192374509.9987.17.camel@localhost.localdomain>	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>	<1192385529.9987.31.camel@localhost.localdomain>	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>	<8FC3583C-AC10-422A-9407-0D202A6BD268@code404.com>	<G5P7n7BLmmEHFwlX@pigsonthewing.org.uk>	<2D84A83F-CA01-46AA-93BA-3FB10AF12DFF@code404.com>
	<cFj9oQJ42oEHFwEL@pigsonthewing.org.uk>
Message-ID: <4712962E.6070904@digitalbazaar.com>

Andy Mabbett wrote:
>>  So it's easy to find  evidence of people using both "track" and
>> "song," but neither are  correct.  If we have the opportunity to
>> define a standard, why not go  with one -- "item" -- that is
>> universally correct?
> 
> Because it's semantically barren.

Agreed, it is semantically barren! That being said, Andy, do you think
this is semantically barren:

<div class="haudio">
   <span class="album">Album Title</span>
   <span class="item haudio">Song Title</span>
</div>

-- manu

From martin at weborganics.co.uk  Sun Oct 14 15:24:22 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sun Oct 14 15:23:27 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs. recording/album)
In-Reply-To: <cFj9oQJ42oEHFwEL@pigsonthewing.org.uk>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<8FC3583C-AC10-422A-9407-0D202A6BD268@code404.com>
	<G5P7n7BLmmEHFwlX@pigsonthewing.org.uk>
	<2D84A83F-CA01-46AA-93BA-3FB10AF12DFF@code404.com>
	<cFj9oQJ42oEHFwEL@pigsonthewing.org.uk>
Message-ID: <1192400662.14668.3.camel@localhost.localdomain>

On Sun, 2007-10-14 at 22:44 +0100, Andy Mabbett wrote:
> >good point!  however, people also refer to items as "songs,"
> 
> Some tracks are songs, others are not. All songs, though, are tracks.

You may find that all songs are NOT Tracks...

a busker may sing a song for you on a street corner
YOU may sing a song to yourself in the shower.

>  

Thanks

Martin

From andy at pigsonthewing.org.uk  Sun Oct 14 15:32:01 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sun Oct 14 15:33:28 2007
Subject: [uf-new] hAudio proposal: ITEM/TRACK
In-Reply-To: <0C631978-7446-41EC-8426-559C374CDB2A@makedatamakesense.com>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<47126451.9040009@digitalbazaar.com>
	<C6891363-5F9B-40C1-8263-E344CECEA369@code404.com>
	<47127597.10006@digitalbazaar.com>
	<0C631978-7446-41EC-8426-559C374CDB2A@makedatamakesense.com>
Message-ID: <uUFhMNLhjpEHFwyI@pigsonthewing.org.uk>

In message <0C631978-7446-41EC-8426-559C374CDB2A@makedatamakesense.com>, 
Scott Reynen <scott@makedatamakesense.com> writes

>the way Manu  phrased this gave me an idea for a third solution to this 
>problem:  use class="haudio" alone.  Any hAudio without an album 
>property is  already assumed to be a single track.  If the only reason 
>we're  specifying this with an additional class name of "track" or 
>"item" is  to allow for track listings in name-only shorthand, why 
>don't we just  allow that shorthand with hAudio itself?  I.e. make the 
>following  semantically identical:
>
><span class="haudio"><span class="fn">My Way</span></span>
><span class="haudio">My Way</span>

How would you show the artist and duration of that track, using the 
latter model?

-- 
Andy Mabbett
From andy at pigsonthewing.org.uk  Sun Oct 14 15:44:56 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sun Oct 14 15:46:16 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <1192385529.9987.31.camel@localhost.localdomain>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
Message-ID: <ZF38ohMovpEHFw0J@pigsonthewing.org.uk>

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

>> >> [1] http://microformats.org/wiki/item
>>
>> In which, David Janes said:
>>
>>         hItem should [...] not be a general purpose dumping ground for
>>         attributes

>Item suits our type purpose definition

I'm not clear whether you're just expressing an opinion; or speaking on
behalf of some undeclared group, when you use "our".

The definition of "item" on:

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

does NOT match the use proposed for item in hAudio.


>I also think that if we go ahead and use TRACK then we WILL be causing
>huge problems when it comes to "future" microformats as TRACK has more
>than one meaning not many of which match out Definition

>TRACK has many meaning and no single meaning in the real world

As do "class", "contact", "experience", "key", "label", "latitude",
"note", "profile", "region", "sound" and many other class names already
used in microformats.

I don't see the relevance of track's other meanings, to this issue.


>How would you feel when it comes to marking up hRacetrack, or
>hTraintrack and you find that hAudio has already defined TRACK to mean
>
>"A container for another hAudio item"

Perfectly relaxed; unless you intended to wrap hRacetrack or hTraintrack
(!) in hAudio.

Are you suggesting we should use "album-track" instead of just "rack".

-- 
Andy Mabbett
From andy at pigsonthewing.org.uk  Sun Oct 14 15:47:30 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Sun Oct 14 15:49:00 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <1192400662.14668.3.camel@localhost.localdomain>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<8FC3583C-AC10-422A-9407-0D202A6BD268@code404.com>
	<G5P7n7BLmmEHFwlX@pigsonthewing.org.uk>
	<2D84A83F-CA01-46AA-93BA-3FB10AF12DFF@code404.com>
	<cFj9oQJ42oEHFwEL@pigsonthewing.org.uk>
	<1192400662.14668.3.camel@localhost.localdomain>
Message-ID: <elN9ALNCypEHFwXX@pigsonthewing.org.uk>

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

>On Sun, 2007-10-14 at 22:44 +0100, Andy Mabbett wrote:
>> >good point!  however, people also refer to items as "songs,"
>>
>> Some tracks are songs, others are not. All songs, though, are tracks.
>
>You may find that all songs are NOT Tracks...
>
>a busker may sing a song for you on a street corner YOU may sing a song 
>to yourself in the shower.

Indeed; read my comment as "all recorded songs". Or are you planning to 
mark up your local busker?

-- 
Andy Mabbett
From scott at makedatamakesense.com  Sun Oct 14 16:43:18 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sun Oct 14 16:43:19 2007
Subject: [uf-new] hAudio proposal: ITEM/TRACK
In-Reply-To: <uUFhMNLhjpEHFwyI@pigsonthewing.org.uk>
References: <1192306262.1923.82.camel@localhost.localdomain>
	<C336A98F.95C44%tantek@cs.stanford.edu>
	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>
	<1192374509.9987.17.camel@localhost.localdomain>
	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>
	<1192385529.9987.31.camel@localhost.localdomain>
	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>
	<47126451.9040009@digitalbazaar.com>
	<C6891363-5F9B-40C1-8263-E344CECEA369@code404.com>
	<47127597.10006@digitalbazaar.com>
	<0C631978-7446-41EC-8426-559C374CDB2A@makedatamakesense.com>
	<uUFhMNLhjpEHFwyI@pigsonthewing.org.uk>
Message-ID: <93ED83C4-F73C-4E18-BB18-DEA4328996AF@makedatamakesense.com>

On Oct 14, 2007, at 4:32 PM, Andy Mabbett wrote:

>> <span class="haudio"><span class="fn">My Way</span></span>
>> <span class="haudio">My Way</span>
>
> How would you show the artist and duration of that track, using the  
> latter model?

We wouldn't.  I see now that Manu's recent definition of text-only  
track's "(which will be the FN of an hAudio object)" is more  
restrictive than the (lack of) definition in the wiki [1].  My  
suggestion would only work under this more restrictive definition.   
Do we have use cases in mind for unstructured plain-text tracks?   
I've forgotten why we included that option in the first place.

[1] http://microformats.org/wiki/audio-info-proposal#Track

--
Scott Reynen
MakeDataMakeSense.com


From msporny at digitalbazaar.com  Sun Oct 14 20:20:06 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Oct 14 20:56:44 2007
Subject: [uf-new] hAudio proposal: ITEM/TRACK
In-Reply-To: <93ED83C4-F73C-4E18-BB18-DEA4328996AF@makedatamakesense.com>
References: <1192306262.1923.82.camel@localhost.localdomain>	<C336A98F.95C44%tantek@cs.stanford.edu>	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>	<1192374509.9987.17.camel@localhost.localdomain>	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>	<1192385529.9987.31.camel@localhost.localdomain>	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>	<47126451.9040009@digitalbazaar.com>	<C6891363-5F9B-40C1-8263-E344CECEA369@code404.com>	<47127597.10006@digitalbazaar.com>	<0C631978-7446-41EC-8426-559C374CDB2A@makedatamakesense.com>	<uUFhMNLhjpEHFwyI@pigsonthewing.org.uk>
	<93ED83C4-F73C-4E18-BB18-DEA4328996AF@makedatamakesense.com>
Message-ID: <4712DC66.4060601@digitalbazaar.com>

Scott Reynen wrote:
>> How would you show the artist and duration of that track, using the
>> latter model?
> 
> We wouldn't.  I see now that Manu's recent definition of text-only
> track's "(which will be the FN of an hAudio object)" is more restrictive
> than the (lack of) definition in the wiki [1].  My suggestion would only
> work under this more restrictive definition.  Do we have use cases in
> mind for unstructured plain-text tracks?  I've forgotten why we included
> that option in the first place.

Plain-text tracks are being considered for two reasons:

1. It eases the markup needed for publishers. The less mark-up required,
the better.
2. Music bloggers use that approach[1] quite often for marking up albums
and songs in free-flowing paragraphs.

Looks like we have two approaches so far for the hAudio "container":

Approach #1 ITEM+HAUDIO:

 <span class="haudio">
    <span class="fn album">Album Name</span>
    <span class="contributor">Artist Name</span>
    <div class="item haudio">
       <span class="fn">A Song</span> ?
       <abbr class="duration" title="P268T">4:46</abbr>
    </span>
    <span class="haudio item">Spoken Word</span>
    <span class="item haudio">
       <span class="fn">Another Song</span> ?
       <abbr class="duration" title="P268T">4:46</abbr>
    </span>
 </span>

Approach #2 HAUDIO-only:

 <span class="haudio">
    <span class="fn album">Album Name</span>
    <span class="contributor">Artist Name</span>
    <div class="haudio">
       <span class="fn">A Song</span> ?
       <abbr class="duration" title="P268T">4:46</abbr>
    </span>
    <span class="haudio">Spoken Word</span>
    <span class="haudio">
       <span class="fn">Another Song</span> ?
       <abbr class="duration" title="P268T">4:46</abbr>
    </span>
 </span>

I'm leaning more towards approach #1 if we don't use TRACK. The second
approach would confuse haudio's that are referred to in an haudio
description as a "contains song" relationship on the haudio when they
really just have a "sounds like" relationship. For example:

 <span class="haudio">
    <span class="description">
       The entire
       <span class="fn album">Country Album</span>
       is done in the same style as the following song called
       <span class="haudio">Other Country Song</span>
       by a completely different artist and on a completely different
       album. The first album is done by
       <span class="contributor">Country Star</span>.
    </span>
 </span>

The above example, using approach #2 would generate the wrong MicroModel
("Other Country Song" would be listed as contained in "Country Album",
when that wasn't the publishers intent). This is bad because the style
of the paragraph above is used quite often in music blogs or when
reviewing music.

Scott, Andy - do each of you have further thoughts on approach #1
(assuming we can change the definition for ITEM)? Would it be acceptable
to either of you?

-- manu

[1] http://wiki.digitalbazaar.com/demos/scissorkick/scissorkick.html
From Michael.Smethurst at bbc.co.uk  Mon Oct 15 02:11:05 2007
From: Michael.Smethurst at bbc.co.uk (Michael Smethurst)
Date: Mon Oct 15 02:11:12 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs. recording/album)
In-Reply-To: <cFj9oQJ42oEHFwEL@pigsonthewing.org.uk>
Message-ID: <C338ED39.71BF%Michael.Smethurst@bbc.co.uk>




On 14/10/07 22:44, "Andy Mabbett" <andy@pigsonthewing.org.uk> wrote:


> 
> Some tracks are songs, others are not. All songs, though, are tracks.
> 

Again in the case of live performance no


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.
					
From Michael.Smethurst at bbc.co.uk  Mon Oct 15 02:26:45 2007
From: Michael.Smethurst at bbc.co.uk (Michael Smethurst)
Date: Mon Oct 15 02:26:52 2007
Subject: [uf-new] hAudio proposal: ITEM/TRACK
In-Reply-To: <47127597.10006@digitalbazaar.com>
Message-ID: <C338F0E5.71C6%Michael.Smethurst@bbc.co.uk>

3 quick questions:

1. how would this work for a tracklist for a radio/tv programme. Like this?:

<span class="haudio">
 <span class="fn">Nagasaki Nightmare</span>
 <span class="album">Best Before 1984</span>
 <span class="contributor">Crass</span>
</span>
<span class="haudio">
 <span class="fn">The Classical</span>
 <span class="album">Hex Enduction Hour</span>
 <span class="contributor">The Fall</span>
</span>

Or should the whole thing be wrapped in an haudio with haudio items?

2. how would it work for a live performance by a single artist

<span class="haudio">
 <span class="contributor">The Fall</span>
 <span class="item">The Classical</span>
 <span class="item">Frenz</span>
 <span class="item">Container Drivers</span>
</span>

In which case should album be mandatory for a top level haudio with items?

3. can you have infinite nesting of item/haudios to handle the modelling of
classical music?

Again no mandatory album



On 14/10/07 21:01, "Manu Sporny" <msporny@digitalbazaar.com> wrote:

> The problem:
> 
> We need some sort of "container" to hold track/song information in an
> hAudio album. The contents of this "container" will be another hAudio
> chunk or text (which will be the FN of an hAudio object).
> 
> There are two proposals that are on the table right now. The end result
> and semantics for hAudio are the same, the only thing that we are
> discussing is the name of that "container".
> 
> TRACK or ITEM
> 
> Using TRACK means creating a new Microformat property that, while
> specific, is not re-using ITEM. There is also contention over whether
> this accurately describes a part of an album.
> 
> Using ITEM means that we will be changing the current definition of ITEM:
> 
> -----------------------------------------------------------------------
> 
> "item - hReview - The item that the object exists for. For example, a
> review about Coca-Cola would list "Coca-Cola" as the item."[1]
> 
> "item info:: This required field MUST have at a minimum the name ("fn" -
> the formatted text corresponding to the name, except for an event item
> which MUST have the "summary" property inside the respective hCalendar
> "vevent") of the item (an hReview describes only one item), SHOULD
> provide at least one URI ("url") for the item, and MAY provide at least
> one URL to a photo or depiction ("photo") of the item. For items of type
> person or business, the item info (fn, url, photo) MUST be encapsulated
> in an hCard. For items of type event, the item info SHOULD be
> encapsulated in an hCalendar "vevent". Non-URL unique item IDs (e.g.
> ISBNs, UPCs) MAY be represented as a URN ("url") for the item.
> Encapsulated microformats (e.g. hCard and hCalendar events for now) may
> be set on the item itself (e.g. class="item vcard"). However, when using
> item info subproperties ("fn", "url", "photo"), they MUST be nested
> inside the item element."[2]
> 
> "item info:: This required field MUST have at a minimum the name ("fn" -
> the formatted text corresponding to the name) of the item , SHOULD
> provide at least one URI ("url") for the item, and MAY provide at least
> one URL to a photo or depiction ("photo") of the item. For items of type
> person or business, the item info (fn, url, photo) SHOULD be
> encapsulated in an hCard. Unique item IDs (e.g. ISBNs, UPCs) MAY be
> represented as a URN ("url") for the item."[3]
> 
> -----------------------------------------------------------------------
> 
> However, it seems that there is support from a number of people to
> re-use ITEM because it achieves two things (moves hAudio forward AND
> simultaneously creates a generic "bag/hset/container" concept for
> Microformats... something that we've been attempting to do for over a year.
> 
> We don't want to break backwards compatability, so we have to work with
> the current definitions of item for hReview and hListing by defining
> ITEM as the following, which can be used across all Microformats:
> 
> -----------------------------------------------------------------------
> 
> ITEM - A generic method that Microformats use for unordered containment
> of other Microformat properties or objects. This property MUST have, at
> a minimum, the name of the item. The name of the item can be specified
> using either:
> 
>   a) plain-text, if the property contains only the name of the item.
>   b) "fn", if the property contains multiple Microformat properties.
> 
> ITEM MAY contain other properties/Microformats, but anything other than
> FN must be defined by the Microformat that is using ITEM.
> 
> -----------------------------------------------------------------------
> 
> The above definition doesn't require hReview or hListing to change at
> all. It also means that we can use it like so in hAudio:
> 
> Single track, with known album (same as putting text in the ?album?
> field of an ID3 tag):
> <span class="haudio">
>     <span class="fn">Nagasaki Nightmare</span>
>     <span class="album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
> </span>
> 
> Single track, album unknown:
> <span class="haudio">
>     <span class="fn">Nagasaki Nightmare</span>
>     <span class="contributor">Crass</span>
> </span>
> 
> Album:
> <span class="haudio">
>     <span class="fn album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
> </span>
> 
> Album with a couple of tracks, simple example:
> <span class="haudio">
>     <span class="fn album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
>     <span class="item">Nagasaki Nightmare</span>
>     <span class="item">Hokkaido Dream</span>
>     <span class="item">Tokyo Groove</span>
> </span>
> 
> Album with a couple of tracks, more detailed:
> <span class="haudio">
>     <span class="fn album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
>     <span class="item haudio"><span class="fn">Nagasaki Nightmare</span>
> ? <abbr class="duration" title="P268T">4:46</abbr></span>
>     <span class="item haudio"><span class="fn">Nagasaki Nightmare</span>
> ? <abbr class="duration" title="P268T">4:46</abbr></span>
>     <span class="item haudio"><span class="fn">Nagasaki Nightmare</span>
> ? <abbr class="duration" title="P268T">4:46</abbr></span>
> </span>
> 
> -- manu
> 
> PS: Andy, Martin - I'm just as frustrated with this approach as I'm sure
> both of you are, especially since it was deemed that we couldn't change
> TITLE from hCard... but now we're changing the meaning, quite blatantly,
> for ITEM.
> 
> [1] http://microformats.org/wiki/existing-classes
> [2] http://microformats.org/wiki/hreview#Field_details
> [3] http://microformats.org/wiki/hlisting#Item_Metadata
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new


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.
					

From Michael.Smethurst at bbc.co.uk  Mon Oct 15 02:28:08 2007
From: Michael.Smethurst at bbc.co.uk (Michael Smethurst)
Date: Mon Oct 15 02:28:14 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs. recording/album)
In-Reply-To: <4712679D.9030005@digitalbazaar.com>
Message-ID: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>




On 14/10/07 20:01, "Manu Sporny" <msporny@digitalbazaar.com> wrote:

> Martin McEvoy wrote:

> 
> album-title is NOT mandatory. It is only mandatory when you're listing
> one or more TRACKs.

Tracks can be grouped by more than just albums. I'd say album-title should
never be mandatory
> 
> -- manu
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new


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.
					
From paul_wilkins at xtra.co.nz  Mon Oct 15 02:42:19 2007
From: paul_wilkins at xtra.co.nz (paul_wilkins@xtra.co.nz)
Date: Mon Oct 15 02:42:24 2007
Subject: [uf-new] hAudio proposal: ITEM/TRACK
Message-ID: <623976.25529.qm@web96009.mail.aue.yahoo.com>

From: Manu Sporny <msporny@digitalbazaar.com>
> Approach #1 ITEM+HAUDIO:
> 
>  <span class="haudio">
>     <span class="fn album">Album Name</span>
>     <span class="contributor">Artist Name</span>
>     <div class="item haudio">
>        <span class="fn">A Song</span> ?
>        <abbr class="duration" title="P268T">4:46</abbr>
>     </span>
>     <span class="haudio item">Spoken Word</span>
>     <span class="item haudio">
>        <span class="fn">Another Song</span> ?
>        <abbr class="duration" title="P268T">4:46</abbr>
>     </span>
>  </span>


If anyone understands why P268T is being used, please explain.

Otherwise I think that we really SHOULD be using PT4M46S

-- 
Paul Wilkins




From andy at pigsonthewing.org.uk  Mon Oct 15 02:50:42 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Mon Oct 15 02:50:56 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title 
	vs. recording/album)
In-Reply-To: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>
References: <4712679D.9030005@digitalbazaar.com>
	<C338F138.71C8%Michael.Smethurst@bbc.co.uk>
Message-ID: <49762.80.249.57.38.1192441842.squirrel@www.gradwell.com>

On Mon, October 15, 2007 10:28, Michael Smethurst wrote:

> Tracks can be grouped by more than just albums.

Examples, please.

-- 
Andy Mabbett
** via webmail **

From andy at pigsonthewing.org.uk  Mon Oct 15 02:55:19 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Mon Oct 15 02:55:25 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title 
	vs. recording/album)
In-Reply-To: <C338ED39.71BF%Michael.Smethurst@bbc.co.uk>
References: <cFj9oQJ42oEHFwEL@pigsonthewing.org.uk>
	<C338ED39.71BF%Michael.Smethurst@bbc.co.uk>
Message-ID: <51378.80.249.57.38.1192442119.squirrel@www.gradwell.com>

On Mon, October 15, 2007 10:11, Michael Smethurst wrote:

>> Some tracks are songs, others are not. All songs, though, are tracks.

> Again in the case of live performance no

If the live performance is presented as single MP3 (say), perhaps not. But
if it's sub-divided, each sub-division is a track.

-- 
Andy Mabbett
** via webmail **

From Michael.Smethurst at bbc.co.uk  Mon Oct 15 02:07:01 2007
From: Michael.Smethurst at bbc.co.uk (Michael Smethurst)
Date: Mon Oct 15 03:01:30 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs. recording/album)
In-Reply-To: <elN9ALNCypEHFwXX@pigsonthewing.org.uk>
Message-ID: <C338EC45.71BC%Michael.Smethurst@bbc.co.uk>




On 14/10/07 23:47, "Andy Mabbett" <andy@pigsonthewing.org.uk> wrote:

> In message <1192400662.14668.3.camel@localhost.localdomain>, Martin
> McEvoy <martin@weborganics.co.uk> writes
> 
>> On Sun, 2007-10-14 at 22:44 +0100, Andy Mabbett wrote:
>>>> good point!  however, people also refer to items as "songs,"
>>> 
>>> Some tracks are songs, others are not. All songs, though, are tracks.
>> 
>> You may find that all songs are NOT Tracks...
>> 
>> a busker may sing a song for you on a street corner YOU may sing a song
>> to yourself in the shower.
> 
> Indeed; read my comment as "all recorded songs". Or are you planning to
> mark up your local busker?

Well I wouldn't want to mark up my local busker but marking up live
performances would be kinda handy. In my case I need to mark up
performance/set lists for Glastonbury, the Proms etc

In these cases track would be plain wrong

Also nested items/haudios would allow you to mark up classical works/opera
(as opposed to perfomances/recordings). In the case of an opera:

Haudio - opera
    haudio - act
        haudio - scene
            haudio - aria

Or is this too much of a corner case?


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.
					
From julian at julianstahnke.com  Mon Oct 15 02:44:47 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Mon Oct 15 03:11:28 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>
Message-ID: <B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>

>> album-title is NOT mandatory. It is only mandatory when you're  
>> listing
>> one or more TRACKs.
>
> Tracks can be grouped by more than just albums. I'd say album-title  
> should
> never be mandatory

Playlists or charts come to my mind, for example.
From davidjanes at blogmatrix.com  Mon Oct 15 03:20:46 2007
From: davidjanes at blogmatrix.com (davidjanes@blogmatrix.com)
Date: Mon Oct 15 03:20:49 2007
Subject: [uf-new] hAudio proposal: ITEM/TRACK
In-Reply-To: <623976.25529.qm@web96009.mail.aue.yahoo.com>
References: <623976.25529.qm@web96009.mail.aue.yahoo.com>
Message-ID: <21e523c20710150320q3f26f6e3jbd43f41b104a89e@mail.gmail.com>

Please excuse the fmt of this msg. My daughter dropped an oj in my
kybd and so I'm typing this on a loaner blackberry.

The dfn of item in hreview is much looser than it is in
existingpatterns and actually clearly says that in hreviw its one item
but elsewhere it couuld be more than one.

Even if this was not the case, we could "narrow" the meaning of item
in a backwards compatible sense wo breaking anytthing. I believe there
are precidents for this.

Finally, bcause we are using it in a composite sense, the item is
clearly the track, not the thing containing the track

-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
From Michael.Smethurst at bbc.co.uk  Mon Oct 15 03:23:11 2007
From: Michael.Smethurst at bbc.co.uk (Michael Smethurst)
Date: Mon Oct 15 03:23:17 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title 
	vs. recording/album)
In-Reply-To: <49762.80.249.57.38.1192441842.squirrel@www.gradwell.com>
Message-ID: <C338FE1F.71DA%Michael.Smethurst@bbc.co.uk>




On 15/10/07 10:50, "Andy Mabbett" <andy@pigsonthewing.org.uk> wrote:

> On Mon, October 15, 2007 10:28, Michael Smethurst wrote:
> 
>> Tracks can be grouped by more than just albums.
> 
> Examples, please.

Playlists [1], tracklists [2], set lists [3], works [4]:

[1] http://www.bbc.co.uk/radio1/playlist/

[2] http://www.bbc.co.uk/radio1/petetong/

[3] http://www.efestivals.co.uk/forums/lofiversion/index.php/t60883.html

[4] http://en.wikipedia.org/wiki/Symphony_No._5_(Beethoven)#First_movement


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.
					
From Michael.Smethurst at bbc.co.uk  Mon Oct 15 03:24:32 2007
From: Michael.Smethurst at bbc.co.uk (Michael Smethurst)
Date: Mon Oct 15 03:24:38 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title 
	vs. recording/album)
In-Reply-To: <51378.80.249.57.38.1192442119.squirrel@www.gradwell.com>
Message-ID: <C338FE70.71DC%Michael.Smethurst@bbc.co.uk>

But it may never be recorded let alone released

I might want to mark up a set list for a gig I enjoyed


On 15/10/07 10:55, "Andy Mabbett" <andy@pigsonthewing.org.uk> wrote:

> On Mon, October 15, 2007 10:11, Michael Smethurst wrote:
> 
>>> Some tracks are songs, others are not. All songs, though, are tracks.
> 
>> Again in the case of live performance no
> 
> If the live performance is presented as single MP3 (say), perhaps not. But
> if it's sub-divided, each sub-division is a track.


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.
					
From andy at pigsonthewing.org.uk  Mon Oct 15 03:34:17 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Mon Oct 15 03:34:27 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title 
	vs. recording/album)
In-Reply-To: <C338EC45.71BC%Michael.Smethurst@bbc.co.uk>
References: <elN9ALNCypEHFwXX@pigsonthewing.org.uk>
	<C338EC45.71BC%Michael.Smethurst@bbc.co.uk>
Message-ID: <13009.80.249.57.38.1192444457.squirrel@www.gradwell.com>

On Mon, October 15, 2007 10:07, Michael Smethurst wrote:

> I need to mark up performance/set lists for Glastonbury, the Proms
> etc
>
> In these cases track would be plain wrong

How so?

> Also nested items/haudios would allow you to mark up classical
> works/opera (as opposed to perfomances/recordings). In the case of an
> opera:

> Haudio - opera
> haudio - act haudio - scene haudio - aria
>
> Or is this too much of a corner case?

I don't think so; though the current evidence probably doesn't cover them;
and more should be gathered.

(I have previously commented on the problem that our evidence collecting,
in general, may be deficient and unrepresentative; but that's a whole
other debate.)

-- 
Andy Mabbett
** via webmail **


From lists at ben-ward.co.uk  Mon Oct 15 03:43:54 2007
From: lists at ben-ward.co.uk (Ben Ward)
Date: Mon Oct 15 03:43:59 2007
Subject: [Audio] Playlists and Albums (was: Re: [uf-new] item property)
In-Reply-To: <B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>
	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>
Message-ID: <56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>

On 15 Oct 2007, at 10:44, Julian Stahnke wrote:
>>> album-title is NOT mandatory. It is only mandatory when you're  
>>> listing
>>> one or more TRACKs.
>>
>> Tracks can be grouped by more than just albums. I'd say album- 
>> title should
>> never be mandatory
>
> Playlists or charts come to my mind, for example.

I'm very out of touch with hAudio development, but this touches on  
something I've not seen addressed lately. In the context of hAudio  
what is the difference between a ?Playlist? and an ?Album?? How is an  
?Album? not just a specialised kind of playlist?

Answers by way of links to previous discussions are fine.

Thank you,

Ben
From Michael.Smethurst at bbc.co.uk  Mon Oct 15 04:06:59 2007
From: Michael.Smethurst at bbc.co.uk (Michael Smethurst)
Date: Mon Oct 15 04:07:05 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title 
	vs. recording/album)
In-Reply-To: <13009.80.249.57.38.1192444457.squirrel@www.gradwell.com>
Message-ID: <C3390863.71E4%Michael.Smethurst@bbc.co.uk>




On 15/10/07 11:34, "Andy Mabbett" <andy@pigsonthewing.org.uk> wrote:

> On Mon, October 15, 2007 10:07, Michael Smethurst wrote:
> 
>> I need to mark up performance/set lists for Glastonbury, the Proms
>> etc
>> 
>> In these cases track would be plain wrong
> 
> How so?

They may not be recorded or released on cd, tape or vinyl. That doesn't fit
any definition of track I know of

> 
>> Also nested items/haudios would allow you to mark up classical
>> works/opera (as opposed to perfomances/recordings). In the case of an
>> opera:
> 
>> Haudio - opera
>> haudio - act haudio - scene haudio - aria
>> 
>> Or is this too much of a corner case?
> 
> I don't think so; though the current evidence probably doesn't cover them;
> and more should be gathered.
> 
> (I have previously commented on the problem that our evidence collecting,
> in general, may be deficient and unrepresentative; but that's a whole
> other debate.)


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.
					
From scott at makedatamakesense.com  Mon Oct 15 06:11:47 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Mon Oct 15 06:11:46 2007
Subject: [uf-new] hAudio proposal: ITEM/TRACK
In-Reply-To: <4712DC66.4060601@digitalbazaar.com>
References: <1192306262.1923.82.camel@localhost.localdomain>	<C336A98F.95C44%tantek@cs.stanford.edu>	<21e523c20710140650j69f45dcek2f1f602a8ae7ad75@mail.gmail.com>	<1192374509.9987.17.camel@localhost.localdomain>	<PFd5I36AckEHFwHf@pigsonthewing.org.uk>	<1192385529.9987.31.camel@localhost.localdomain>	<D9E669FF-EFBD-4D4B-BFED-3CC061D55A1A@code404.com>	<47126451.9040009@digitalbazaar.com>	<C6891363-5F9B-40C1-8263-E344CECEA369@code404.com>	<47127597.10006@digitalbazaar.com>	<0C631978-7446-41EC-8426-559C374CDB2A@makedatamakesense.com>	<uUFhMNLhjpEHFwyI@pigsonthewing.org.uk>
	<93ED83C4-F73C-4E18-BB18-DEA4328996AF@makedatamakesense.com>
	<4712DC66.4060601@digitalbazaar.com>
Message-ID: <25BA99FD-2080-4849-8966-02CC5355E21F@makedatamakesense.com>

On Oct 14, 2007, at 9:20 PM, Manu Sporny wrote:

> Scott, Andy - do each of you have further thoughts on approach #1
> (assuming we can change the definition for ITEM)? Would it be  
> acceptable
> to either of you?

I don't have strong feelings either way on item vs. track.

--
Scott Reynen
MakeDataMakeSense.com


From Michael.Smethurst at bbc.co.uk  Mon Oct 15 06:28:19 2007
From: Michael.Smethurst at bbc.co.uk (Michael Smethurst)
Date: Mon Oct 15 06:28:25 2007
Subject: [uf-new] hAudio proposal: ITEM/TRACK
In-Reply-To: <25BA99FD-2080-4849-8966-02CC5355E21F@makedatamakesense.com>
Message-ID: <C3392983.71FA%Michael.Smethurst@bbc.co.uk>

Not wanting to add to the confusion but would it not be possible to have
infinitely nested haudios with neither item or track and use mfo when the
markup enforces containment that you don't want to be reflected in the
model?


On 15/10/07 14:11, "Scott Reynen" <scott@makedatamakesense.com> wrote:

> On Oct 14, 2007, at 9:20 PM, Manu Sporny wrote:
> 
>> Scott, Andy - do each of you have further thoughts on approach #1
>> (assuming we can change the definition for ITEM)? Would it be
>> acceptable
>> to either of you?
> 
> I don't have strong feelings either way on item vs. track.
> 
> --
> Scott Reynen
> MakeDataMakeSense.com
> 
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new


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.
					
From msporny at digitalbazaar.com  Mon Oct 15 07:45:11 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Mon Oct 15 07:45:51 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title
	vs. recording/album)
In-Reply-To: <C338EC45.71BC%Michael.Smethurst@bbc.co.uk>
References: <C338EC45.71BC%Michael.Smethurst@bbc.co.uk>
Message-ID: <47137CF7.3000502@digitalbazaar.com>

Michael Smethurst wrote:
> In these cases track would be plain wrong
> 
> Also nested items/haudios would allow you to mark up classical works/opera
> (as opposed to perfomances/recordings). In the case of an opera:
> 
> Haudio - opera
>     haudio - act
>         haudio - scene
>             haudio - aria
> 
> Or is this too much of a corner case?

Marking up collections of live performances is outside of the scope of
the current discussion. The current scope of the discussion (and of
hAudio) is how to handle albums and tracks, specifically.

That being said, with all of the known nuances in the examples and
haudio proposals, you could do the above like so with the current
ITEM+HAUDIO proposal (which uses mfo - any "item haudio" is opaque to
the containing hAudio):

div class="haudio" - opera
   div class="item haudio" - act
      div class="item haudio" - scene
         div class="item haudio" - aria

TRACK+HAUDIO wouldn't make semantic sense above. The above example is,
however, a bit contrived as I've never seen an opera described online
and none of the examples have Opera in there. That is not to say that it
doesn't exist... but it definitely isn't as mainstream as music blogs or
music service websites.

It is outside of the scope of this discussion, but the current
ITEM+HAUDIO, TRACK and TRACK+HAUDIO proposals work for Opera markup. The
semantics do make more sense with ITEM+HAUDIO, FWIW.

-- manu

From scott at makedatamakesense.com  Mon Oct 15 07:51:49 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Mon Oct 15 07:51:57 2007
Subject: [uf-new] hAudio proposal: ITEM/TRACK
In-Reply-To: <C3392983.71FA%Michael.Smethurst@bbc.co.uk>
References: <C3392983.71FA%Michael.Smethurst@bbc.co.uk>
Message-ID: <27455CCE-6153-4B2B-B046-86A4E4DB8B3A@makedatamakesense.com>

On Oct 15, 2007, at 7:28 AM, Michael Smethurst wrote:

> Not wanting to add to the confusion but would it not be possible to  
> have
> infinitely nested haudios with neither item or track and use mfo  
> when the
> markup enforces containment that you don't want to be reflected in the
> model?

As much as I'd like to move forward a general MFO technique, that  
isn't necessary here as the hAudio proposal specifically makes all  
contained hAudio (currently called "track") opaque [1].  The current  
proposal appears to only support two levels of nesting, but that may  
change.  Examples of several levels of audio published on the web  
today would help support such a change.

[1] http://microformats.org/wiki/audio-info-proposal#Track

--
Scott Reynen
MakeDataMakeSense.com


From msporny at digitalbazaar.com  Mon Oct 15 07:53:28 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Mon Oct 15 07:54:09 2007
Subject: [uf-new] hAudio proposal: ITEM/TRACK
In-Reply-To: <C338F0E5.71C6%Michael.Smethurst@bbc.co.uk>
References: <C338F0E5.71C6%Michael.Smethurst@bbc.co.uk>
Message-ID: <47137EE8.90100@digitalbazaar.com>

Michael Smethurst wrote:
> 3 quick questions:
> 
> 1. how would this work for a tracklist for a radio/tv programme. Like this?:
> 
> <span class="haudio">
>  <span class="fn">Nagasaki Nightmare</span>
>  <span class="album">Best Before 1984</span>
>  <span class="contributor">Crass</span>
> </span>
> <span class="haudio">
>  <span class="fn">The Classical</span>
>  <span class="album">Hex Enduction Hour</span>
>  <span class="contributor">The Fall</span>
> </span>

Keep in mind that live performances are outside of the current scope of
discussion.

Exactly like you've marked up above, OR:

<span class="haudio">
 <span class="fn">Name of Radio Program/Tracklist</span>
 <span class="item haudio">
  <span class="fn">Nagasaki Nightmare</span>
  <span class="album">Best Before 1984</span>
  <span class="contributor">Crass</span>
 </span>
 <span class="item haudio">
  <span class="fn">The Classical</span>
  <span class="album">Hex Enduction Hour</span>
  <span class="contributor">The Fall</span>
 </span>
</span>

Assuming that we drop the requirement for ALBUM to be mandatory if there
are tracks. Your argument above is a good reason to drop the mandatory
requirement.

> Or should the whole thing be wrapped in an haudio with haudio items?
> 
> 2. how would it work for a live performance by a single artist
> 
> <span class="haudio">
>  <span class="contributor">The Fall</span>
>  <span class="item">The Classical</span>
>  <span class="item">Frenz</span>
>  <span class="item">Container Drivers</span>
> </span>

You're missing the name of the performance, which is required, but other
than that, the above would work. The argument is the same as above, but
it is another reason to drop the mandatory requirement for ALBUM being
specified.

> In which case should album be mandatory for a top level haudio with items?
> 
> 3. can you have infinite nesting of item/haudios to handle the modelling of
> classical music?

With the current proposal of ITEM+HAUDIO with mfo for sub-haudios, yes,
you can.

-- manu
From msporny at digitalbazaar.com  Mon Oct 15 07:57:44 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Mon Oct 15 07:58:24 2007
Subject: [uf-new] hAudio proposal: ITEM/TRACK
In-Reply-To: <623976.25529.qm@web96009.mail.aue.yahoo.com>
References: <623976.25529.qm@web96009.mail.aue.yahoo.com>
Message-ID: <47137FE8.6070101@digitalbazaar.com>

paul_wilkins@xtra.co.nz wrote:
> From: Manu Sporny <msporny@digitalbazaar.com>
>> Approach #1 ITEM+HAUDIO:
>>
>>  <span class="haudio">
>>     <span class="fn album">Album Name</span>
>>     <span class="contributor">Artist Name</span>
>>     <div class="item haudio">
>>        <span class="fn">A Song</span> ?
>>        <abbr class="duration" title="P268T">4:46</abbr>
>>     </span>
>>     <span class="haudio item">Spoken Word</span>
>>     <span class="item haudio">
>>        <span class="fn">Another Song</span> ?
>>        <abbr class="duration" title="P268T">4:46</abbr>
>>     </span>
>>  </span>
> 
> 
> If anyone understands why P268T is being used, please explain.
> 
> Otherwise I think that we really SHOULD be using PT4M46S

That is a cut-and-paste problem (exacerbated by everybody else
cutting-and-pasting) and a mis-understanding of how ISO-8601 works,
thanks for the correction, Paul. The corrected value should be:

title="PT268S"

OR

title="PT4M46S"

That field must follow the ISO-8601 standard.

-- manu
From msporny at digitalbazaar.com  Mon Oct 15 08:15:09 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Mon Oct 15 08:15:49 2007
Subject: [Audio] Playlists and Albums (was: Re: [uf-new] item property)
In-Reply-To: <56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>
	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>
Message-ID: <471383FD.7090701@digitalbazaar.com>

Ben Ward wrote:
> On 15 Oct 2007, at 10:44, Julian Stahnke wrote:
>>>> album-title is NOT mandatory. It is only mandatory when you're listing
>>>> one or more TRACKs.
>>>
>>> Tracks can be grouped by more than just albums. I'd say album-title
>>> should
>>> never be mandatory
>>
>> Playlists or charts come to my mind, for example.
> 
> I'm very out of touch with hAudio development, but this touches on
> something I've not seen addressed lately. In the context of hAudio what
> is the difference between a ?Playlist? and an ?Album?? How is an ?Album?
> not just a specialised kind of playlist?

Most of the examples that were gathered for hAudio were from music
service websites and music blogs. To help us make progress, this round
of haudio focuses on just albums and tracks.

We tried talking about playlists, podcasts, top-lists and others, but
those were slowing the discussion down. There is a clear answer to how
we support playlists, podcasts, and top-lists in the future... we add
the property to haudio. haudio has been designed in such a way as to
support that if it is ever needed.

We can support playlists, podcasts and top-lists with the current
ITEM+HAUDIO or ITEM+TRACK or TRACK+HAUDIO proposals, as long as we don't
make ALBUM mandatory (which is the direction in which the discussion is
going):

<span class="haudio">
 <span class="fn">My Playlist</span>
 <span class="item haudio">
  <span class="position">1</span>
  <span class="fn">Nagasaki Nightmare</span>
  <span class="album">Best Before 1984</span>
  <span class="contributor">Crass</span>
 </span>
 <span class="item haudio">
  <span class="position">2</span>
  <span class="fn">The Classical</span>
  <span class="album">Hex Enduction Hour</span>
  <span class="contributor">The Fall</span>
 </span>
</span>

However, that is beyond the scope of the current discussion, which is
just albums and the contents of those albums (tracks).

-- manu

From msporny at digitalbazaar.com  Mon Oct 15 08:26:54 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Mon Oct 15 08:27:34 2007
Subject: [uf-new] hAudio proposal: ITEM/TRACK
In-Reply-To: <27455CCE-6153-4B2B-B046-86A4E4DB8B3A@makedatamakesense.com>
References: <C3392983.71FA%Michael.Smethurst@bbc.co.uk>
	<27455CCE-6153-4B2B-B046-86A4E4DB8B3A@makedatamakesense.com>
Message-ID: <471386BE.10808@digitalbazaar.com>

Scott Reynen wrote:
>> Not wanting to add to the confusion but would it not be possible to have
>> infinitely nested haudios with neither item or track and use mfo when the
>> markup enforces containment that you don't want to be reflected in the
>> model?
> 
> As much as I'd like to move forward a general MFO technique, that isn't
> necessary here as the hAudio proposal specifically makes all contained
> hAudio (currently called "track") opaque [1].  The current proposal
> appears to only support two levels of nesting, but that may change. 
> Examples of several levels of audio published on the web today would
> help support such a change.

We could also make the argument that there is no reason to restrict
hAudio to two levels of nesting. There are no ill side-effects by not
restricting it.

-- manu
From scott at makedatamakesense.com  Mon Oct 15 08:50:46 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Mon Oct 15 08:50:53 2007
Subject: [uf-new] hAudio duration syntax (was: hAudio proposal: ITEM/TRACK)
In-Reply-To: <47137FE8.6070101@digitalbazaar.com>
References: <623976.25529.qm@web96009.mail.aue.yahoo.com>
	<47137FE8.6070101@digitalbazaar.com>
Message-ID: <15F226AF-1C57-4815-AE8B-FAE97048856C@makedatamakesense.com>

On Oct 15, 2007, at 8:57 AM, Manu Sporny wrote:

> The corrected value should be:
>
> title="PT268S"
>
> OR
>
> title="PT4M46S"
>
> That field must follow the ISO-8601 standard.

I think the current consensus around ISO 8601 is that we should use  
the most human-readable valid syntax.  Of the two above, the latter  
appears to be more readable.  However, I think the following may also  
be valid ISO 8601 duration syntax:

title="PT04:46"

The Wikipedia entry on ISO 8601 says "Alternately, a format more  
based on the combined representation may be used: P[YYYY]-[MM]-[DD]T 
[hh]:[mm]:[ss]" [1].  Unfortunately ISO 8601 itself is not freely  
available, and few of the online discussions of ISO 8601 discuss  
duration syntax at all, so I haven't found another source confirming  
this syntax is valid.  But if it is valid, I think we should use it.

I'm not suggesting we should explicitly disallow any other valid ISO  
8601 syntax, but the vast majority of publishers will likely use  
whatever we use in examples, so I think it's worth establishing a  
preferred syntax and using it consistently.

[1] http://en.wikipedia.org/wiki/ISO_8601#Duration

--
Scott Reynen
MakeDataMakeSense.com


From andy at pigsonthewing.org.uk  Mon Oct 15 09:04:38 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Mon Oct 15 09:04:47 2007
Subject: [Audio] Playlists and Albums (was: Re: [uf-new] item property)
In-Reply-To: <471383FD.7090701@digitalbazaar.com>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>
	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>
	<471383FD.7090701@digitalbazaar.com>
Message-ID: <7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>

On Mon, October 15, 2007 16:15, Manu Sporny wrote:

> Most of the examples that were gathered for hAudio were from music
> service websites and music blogs. To help us make progress, this round of
> haudio focuses on just albums and tracks.

Is that sufficient?

How many of them were for classical music, including opera?

[...]
> However, that is beyond the scope of the current discussion, which is
> just albums and the contents of those albums (tracks).

Who gets to decide the scope of this or any other such discussion?

-- 
Andy Mabbett
** via webmail **

From Michael.Smethurst at bbc.co.uk  Mon Oct 15 09:09:03 2007
From: Michael.Smethurst at bbc.co.uk (Michael Smethurst)
Date: Mon Oct 15 09:09:09 2007
Subject: [uf-new] hAudio proposal: ITEM/TRACK
In-Reply-To: <27455CCE-6153-4B2B-B046-86A4E4DB8B3A@makedatamakesense.com>
Message-ID: <C3394F2F.721B%Michael.Smethurst@bbc.co.uk>




On 15/10/07 15:51, "Scott Reynen" <scott@makedatamakesense.com> wrote:

> On Oct 15, 2007, at 7:28 AM, Michael Smethurst wrote:
> 
>> Not wanting to add to the confusion but would it not be possible to
>> have
>> infinitely nested haudios with neither item or track and use mfo
>> when the
>> markup enforces containment that you don't want to be reflected in the
>> model?
> 
> As much as I'd like to move forward a general MFO technique, that
> isn't necessary here as the hAudio proposal specifically makes all
> contained hAudio (currently called "track") opaque [1].  The current
> proposal appears to only support two levels of nesting, but that may
> change.  Examples of several levels of audio published on the web
> today would help support such a change.

Multiple levels would also allow you to mark up multi-disc box sets:

Haudio - hex enduction hour

    haudio - disc 1

        haudio - The Classical

Sorry for lack of examples - I'm short on time today


> 
> [1] http://microformats.org/wiki/audio-info-proposal#Track
> 
> --
> Scott Reynen
> MakeDataMakeSense.com
> 
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new


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.
					
From msporny at digitalbazaar.com  Mon Oct 15 10:34:17 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Mon Oct 15 10:34:59 2007
Subject: [uf-new] hAudio duration syntax
In-Reply-To: <15F226AF-1C57-4815-AE8B-FAE97048856C@makedatamakesense.com>
References: <623976.25529.qm@web96009.mail.aue.yahoo.com>	<47137FE8.6070101@digitalbazaar.com>
	<15F226AF-1C57-4815-AE8B-FAE97048856C@makedatamakesense.com>
Message-ID: <4713A499.7020801@digitalbazaar.com>

Scott Reynen wrote:
> On Oct 15, 2007, at 8:57 AM, Manu Sporny wrote:
> 
>> The corrected value should be:
>>
>> title="PT268S"
>>
>> OR
>>
>> title="PT4M46S"
>>
>> That field must follow the ISO-8601 standard.
> 
> I think the current consensus around ISO 8601 is that we should use the
> most human-readable valid syntax.  Of the two above, the latter appears
> to be more readable.  However, I think the following may also be valid
> ISO 8601 duration syntax:
> 
> title="PT04:46"

I haven't been able to find anything to support that mark-up (I tried
looking for about 30 minutes). Here are the pages that I found (none of
which use the mark-up you specified above):

http://www.ostyn.com/standards/scorm/samples/ISOTimeForSCORM.htm
http://www.stylusstudio.com/w3c/schema2/built-in-primitive-datatypes.htm#duration

I also couldn't find it in the ISO-8601 specification (page 31 and 32):

http://isotc.iso.org/livelink/livelink/4021199/ISO_8601_2004_E.zip?func=doc.Fetch&nodeid=4021199

There are no extended formats for time interval that I can see. Unless
anybody else can find any evidence to the contrary, we should probably
use the following format in the examples:

title="PT4M46S"

-- manu

From msporny at digitalbazaar.com  Mon Oct 15 10:52:38 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Mon Oct 15 10:53:19 2007
Subject: [Audio] Playlists and Albums (was: Re: [uf-new] item property)
In-Reply-To: <7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>	<471383FD.7090701@digitalbazaar.com>
	<7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>
Message-ID: <4713A8E6.5020404@digitalbazaar.com>

Andy Mabbett wrote:
> On Mon, October 15, 2007 16:15, Manu Sporny wrote:
> 
>> Most of the examples that were gathered for hAudio were from music
>> service websites and music blogs. To help us make progress, this round of
>> haudio focuses on just albums and tracks.
> 
> Is that sufficient?

For albums and tracks, yes. For marking up classical music, no.

> How many of them were for classical music, including opera?

None. Not one of the submitted 145 example URLs contained any opera or
classical music that I can recall. Draw whatever conclusions you want to
from that statement. :)

If it bothers you, please collect some examples and add them to the
audio-info-examples page. Although I fear it would be a waste of your
time since we already have several proposals on the table that would
solve the infinite nesting issue, which I assume, is what you are
talking about.

>> However, that is beyond the scope of the current discussion, which is
>> just albums and the contents of those albums (tracks).
> 
> Who gets to decide the scope of this or any other such discussion?

I was strongly requesting a scope of discussion because the thread was
going all over the place. It's over 125 messages deep at this point -
which is a good sign that people are talking about too many issues.

Also keep in mind that bringing in a great number of issues complicates
things and slows the Microformat down. Case in point: The media-info
discussion. I should also add that while a reminder to the scope of this
discussion was given, the questions that were asked were answered.

-- manu
From paul_wilkins at xtra.co.nz  Mon Oct 15 12:08:30 2007
From: paul_wilkins at xtra.co.nz (paul_wilkins@xtra.co.nz)
Date: Mon Oct 15 12:08:34 2007
Subject: [uf-new] hAudio proposal: ITEM/TRACK
Message-ID: <769217.26388.qm@web96005.mail.aue.yahoo.com>

From: Manu Sporny <msporny@digitalbazaar.com>
> That is a cut-and-paste problem (exacerbated by everybody else
> cutting-and-pasting) and a mis-understanding of how ISO-8601 works,
> thanks for the correction, Paul. The corrected value should be:
> 
> title="PT268S"
> 
> OR
> 
> title="PT4M46S"
> 
> That field must follow the ISO-8601 standard.

Pardon me for asking again, but why is PT268S being used for 4:46 ?
4 minutes and 46 seconds is not 268 seconds. It's 286 seconds.

This is a gross example of why using different standards (only seconds to represent minutes and seconds) is a bad idea. It's much harder to spot when mistakes have occurred. I think that I've read about this issue somewhere before.

I don't know about you, but I haven't seen many tracks shown in just seconds. If the title is just seconds while time is displayed as minutes and seconds, that makes it a lot easier for errors to creep in.

My suggestion is we don't cross the streams. The title value should match as closely as possible the displayed value, so that any mistakes become obvious.


Wrong:
<abbr title="PT4M36S">286 seconds</abbr>
Right:
<abbr title="PT286S">286 seconds</abbr>

Wrong:
<abbr title="PT266S">4:46</abbr>

Right:
<abbr title="PT4M46S">4:46</abbr>

There is a deliberate problem with the wrong examples. See if you can find them and consider why mistakes a more easily hidden.






-- 
Paul Wilkins




From scott at makedatamakesense.com  Mon Oct 15 12:52:27 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Mon Oct 15 12:52:35 2007
Subject: [uf-new] hAudio duration syntax
In-Reply-To: <4713A499.7020801@digitalbazaar.com>
References: <623976.25529.qm@web96009.mail.aue.yahoo.com>	<47137FE8.6070101@digitalbazaar.com>
	<15F226AF-1C57-4815-AE8B-FAE97048856C@makedatamakesense.com>
	<4713A499.7020801@digitalbazaar.com>
Message-ID: <A24AE52E-5774-4E2A-86C0-E69EA70AEAC2@makedatamakesense.com>

On Oct 15, 2007, at 11:34 AM, Manu Sporny wrote:

> I also couldn't find it in the ISO-8601 specification (page 31 and  
> 32):
>
> http://isotc.iso.org/livelink/livelink/4021199/ISO_8601_2004_E.zip? 
> func=doc.Fetch&nodeid=4021199

I didn't realize the actual ISO spec was available for free.  Section  
4.4.3.3 of that document covers the "Alternative Format" for duration  
mentioned in Wikipedia:

> The complete representation of the expression for duration in the  
> alternative format is as follows:
> Basic format: PYYYYMMDDThhmmss or PYYYYDDDThhmmss
> Extended format: PYYYY-MM-DDThh:mm:ss or PYYYY-DDDThh:mm:ss

That section also includes several references to other sections  
defining date and time formats, including "reduced accuracy" formats  
(i.e. removing segments with values of zero).  So I believe "PT04:46"  
is a valid ISO 8601 duration.

--
Scott Reynen
MakeDataMakeSense.com


From martin at weborganics.co.uk  Mon Oct 15 14:31:52 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Mon Oct 15 14:31:03 2007
Subject: [uf-new] hAudio duration syntax
In-Reply-To: <A24AE52E-5774-4E2A-86C0-E69EA70AEAC2@makedatamakesense.com>
References: <623976.25529.qm@web96009.mail.aue.yahoo.com>
	<47137FE8.6070101@digitalbazaar.com>
	<15F226AF-1C57-4815-AE8B-FAE97048856C@makedatamakesense.com>
	<4713A499.7020801@digitalbazaar.com>
	<A24AE52E-5774-4E2A-86C0-E69EA70AEAC2@makedatamakesense.com>
Message-ID: <1192483912.3116.5.camel@localhost.localdomain>

On Mon, 2007-10-15 at 13:52 -0600, Scott Reynen wrote:
> (i.e. removing segments with values of zero).  So I believe
> "PT04:46"  
> is a valid ISO 8601 duration. 

It Is also

T04:46

and

PT04M46S

Duration Is not however expressed in seconds 

T268S

unless you had something that was 0 minutes 46 seconds

T46S

http://en.wikipedia.org/wiki/Iso_time#Duration

Thanks

Martin




From paul_wilkins at xtra.co.nz  Mon Oct 15 15:12:14 2007
From: paul_wilkins at xtra.co.nz (paul_wilkins@xtra.co.nz)
Date: Mon Oct 15 15:12:18 2007
Subject: [uf-new] hAudio duration syntax
Message-ID: <174005.31717.qm@web96003.mail.aue.yahoo.com>

From: Martin McEvoy <martin@weborganics.co.uk>
> On Mon, 2007-10-15 at 13:52 -0600, Scott Reynen wrote:
> > (i.e. removing segments with values of zero).  So I believe
> > "PT04:46"  
> > is a valid ISO 8601 duration. 
> 
> It Is also
> T04:46
> and
> PT04M46S

+1

> Duration Is not however expressed in seconds 
> T268S

T286S

Can we please get this right.
4 minutes and 28 seconds is 268 seconds.
4 minutes and 46 seconds is 286 seconds.


> unless you had something that was 0 minutes 46 seconds
> T46S
> http://en.wikipedia.org/wiki/Iso_time#Duration


Thank you, I agree completely.

-- 
Paul Wilkins






From msporny at digitalbazaar.com  Mon Oct 15 15:14:11 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Mon Oct 15 15:14:17 2007
Subject: [uf-new] hAudio duration syntax
In-Reply-To: <A24AE52E-5774-4E2A-86C0-E69EA70AEAC2@makedatamakesense.com>
References: <623976.25529.qm@web96009.mail.aue.yahoo.com>	<47137FE8.6070101@digitalbazaar.com>	<15F226AF-1C57-4815-AE8B-FAE97048856C@makedatamakesense.com>	<4713A499.7020801@digitalbazaar.com>
	<A24AE52E-5774-4E2A-86C0-E69EA70AEAC2@makedatamakesense.com>
Message-ID: <4713E633.9030004@digitalbazaar.com>

Scott Reynen wrote:
>> The complete representation of the expression for duration in the
>> alternative format is as follows:
>> Basic format: PYYYYMMDDThhmmss or PYYYYDDDThhmmss
>> Extended format: PYYYY-MM-DDThh:mm:ss or PYYYY-DDDThh:mm:ss
> 
> That section also includes several references to other sections defining
> date and time formats, including "reduced accuracy" formats (i.e.
> removing segments with values of zero).  So I believe "PT04:46" is a
> valid ISO 8601 duration.

I still don't think it is, Scott. After reading through the spec, I am
getting the impression that "reduced accuracy" means the trailing digits
(the more accurate ones, such as seconds and minutes), not the leading
digits (the less accurate ones, such as hour), can be avoided. To quote
the spec (Section 4.4.3.2):

"For reduced accuracy or decimal representations of this representation,
the following rules apply.

a) If necessary for a particular application, the lowest order
components may be omitted to represent duration with reduced accuracy."

The following is ambiguous without a specific interpretation (which is
included in the specification):

PT04:46

Is that 4 hours and 46 minutes, or 4 minutes and 46 seconds? If I'm
interpreting the spec correctly, it is the prior - 4 hours and 46
minutes. The following would be the correct use of ISO-8601 for the
example you gave:

PT00:04:46

or

PT4M46S

> Martin McEvoy wrote:
> Duration Is not however expressed in seconds
>
> T268S
>
> unless you had something that was 0 minutes 46 seconds
>
> T46S

I think you are correct Martin... apologies for the crappy markup.
Clearly, I didn't understand the nuances of ISO-8601 until just recently :)

-- manu
From martin at weborganics.co.uk  Mon Oct 15 16:00:00 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Mon Oct 15 15:59:11 2007
Subject: [uf-new] hAudio duration syntax
In-Reply-To: <4713E633.9030004@digitalbazaar.com>
References: <623976.25529.qm@web96009.mail.aue.yahoo.com>
	<47137FE8.6070101@digitalbazaar.com>
	<15F226AF-1C57-4815-AE8B-FAE97048856C@makedatamakesense.com>
	<4713A499.7020801@digitalbazaar.com>
	<A24AE52E-5774-4E2A-86C0-E69EA70AEAC2@makedatamakesense.com>
	<4713E633.9030004@digitalbazaar.com>
Message-ID: <1192489200.5054.4.camel@localhost.localdomain>

On Mon, 2007-10-15 at 18:14 -0400, Manu Sporny wrote:
> Scott Reynen wrote:
> >> The complete representation of the expression for duration in the
> >> alternative format is as follows:
> >> Basic format: PYYYYMMDDThhmmss or PYYYYDDDThhmmss
> >> Extended format: PYYYY-MM-DDThh:mm:ss or PYYYY-DDDThh:mm:ss
> > 
> > That section also includes several references to other sections defining
> > date and time formats, including "reduced accuracy" formats (i.e.
> > removing segments with values of zero).  So I believe "PT04:46" is a
> > valid ISO 8601 duration.
> 
> I still don't think it is, Scott. After reading through the spec, I am
> getting the impression that "reduced accuracy" means the trailing digits
> (the more accurate ones, such as seconds and minutes), not the leading
> digits (the less accurate ones, such as hour), can be avoided. To quote
> the spec (Section 4.4.3.2):
> 
> "For reduced accuracy or decimal representations of this representation,
> the following rules apply.
> 
> a) If necessary for a particular application, the lowest order
> components may be omitted to represent duration with reduced accuracy."
> 
> The following is ambiguous without a specific interpretation (which is
> included in the specification):
> 
> PT04:46
> 
> Is that 4 hours and 46 minutes, or 4 minutes and 46 seconds? If I'm
> interpreting the spec correctly, it is the prior - 4 hours and 46
> minutes. The following would be the correct use of ISO-8601 for the
> example you gave:
> 
> PT00:04:46
> 
> or
> 
> PT4M46S
> 
> > Martin McEvoy wrote:
> > Duration Is not however expressed in seconds
> >
> > T268S
> >
> > unless you had something that was 0 minutes 46 seconds
> >
> > T46S
> 
> I think you are correct Martin... apologies for the crappy markup.
> Clearly, I didn't understand the nuances of ISO-8601 until just recently :)
> 
> -- manu

which brings us down to 

<span class="duration">04:46</span>

is a valid ISO duration format?


Thanks

Martin
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From martin at weborganics.co.uk  Mon Oct 15 17:50:26 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Mon Oct 15 19:25:38 2007
Subject: [Audio] Playlists and Albums (was: Re: [uf-new] item property)
In-Reply-To: <4713A8E6.5020404@digitalbazaar.com>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>
	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>
	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>
	<471383FD.7090701@digitalbazaar.com>
	<7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>
	<4713A8E6.5020404@digitalbazaar.com>
Message-ID: <1192495826.5054.93.camel@localhost.localdomain>

Hello All

I have been observing this discussion for the last couple of days
because it was good to see how you were all taking the proposition to
use ITEM instead of TRACK and to find out what you all make of it.

First I will say Is That my interpretation of TRACK is name for a
separation of content.
In a digital media such as a CD, the elements could be "block", "PCM",
"frame", "channel", "bytes" etc 
NONE or which are existent in hAudio 

TRACK in the way Some on the list mean it is current popular slang for
what is a composition or a song the stuff you actually hear through your
speakers or read about on the Internet, very nice in your retro 50s to
80s world when you were buying the latest groovy track by Cliff Richard
but... the world has moved on 
Vinyl has almost vanished accept to DJ's, and CD's bit the bullet around
the time that broadband hit everyone's homes so what exactly are you
calling a track? what will a track be in the near future? 
To me as non-existent as Vinyl and CD's
If we are going to use Slang to mark up hAudio why not class="choon" its
as good a word as any?
http://www.urbandictionary.com/define.php?term=choon


all I have to go on is the Field definition on the wiki 
http://microformats.org/wiki/audio-info-proposal#Track
and the principles of designing microformats
http://microformats.org/wiki/principles

"TRACK"

A container for another hAudio item.

and

The element MUST be processed opaquely. No sub-elements should be read
from any hAudio contained in a track element.

says it all really It suggests that we need only a container that means
nothing only:

      * that it is a block of something, 
      * and that this is treated as something that has unique property's
        relating to itself.

The Principles of designing new Microformats are 

      * Use POSH first

that was tried using ol li ul li didn't work in tables

      * RE-USE existing Microformats

as far as i know there is only one existing microformat that matches our
description

ITEM found in hReview and hListing 

As well as various design patterns within our own community We currently
have two different types of microformats:

      * Compound microformats They generally use a combination of
        several class and/or rel attributes.
        http://microformats.org/wiki/compound
      * Elemental microformats They generally use a single class or rel
        attribute.http://microformats.org/wiki/elemental-microformat


I know all of you should know this (for those who are new)

I am suggesting that ITEM belongs to a THIRD set of microformats called
Composite Microformats

Composites perform the function of either 

      * a span <span class="item fn">Parking space</span> (an elemental)
        http://microformats.org/wiki/hlisting#Simple_Listing

      * a div  <div class="item vcard"> [...] (a compound)
        http://microformats.org/wiki/hreview#Multidimensional_Restaurant_Review

Composites have the ability to define context and/or composition
depending on the way they are used

David Janes as far as I know discovered the existence of composite
microformats in our community
http://microformats.org/wiki/item#3._As_a_composite

In hAudio ITEM gives us the ability to mark up hAudio like this:

[1] 

<span class="haudio">

     <span class="item">
              <span class="fn>Nagasaki Nightmare</span>
       </span>

     <span class="item">
              <span class="fn>Big A, Little A</span>
       </span>

     <span class="album">Best Before 1984</span>

     <span class="contributor">Crass</span>

</span>

no need to reiterate haudio on the item class, context and composition
is the important thing, like divs and spans ITEM inherits the properties
of hAudio.

[2]

<span class="haudio">
     <span class="fn>Nagasaki Nightmare</span>
     <span class="contributor">Crass</span>
     <span class="album">Best Before 1984</span>
</span>

Just hAudio


[3]

<div class="hreview">
  [...]
<span class="item haudio">
        <span class="fn>Nagasaki Nightmare</span>
	<span class="contributor">Crass</span>
        <span class="album">Best Before 1984</span>
       </span>
  [...]
</div>

in a hreview 

the only question you can ask about the above can we nest items within
each other:

<div class="hlisting">
  [...]
<span class="item haudio">

     <span class="item">
              <span class="fn>Nagasaki Nightmare</span>
       </span>

     <span class="item">
              <span class="fn>Big A, Little A</span>
       </span>

     <span class="album">Best Before 1984</span>

     <span class="contributor">Crass</span>
       </span>
  [...]
</div>

...?

hAudio marked up in the above ways makes hAudio flexible, usable, and
hopefully be used still in few years time.

Comments?


Thanks

Martin

On Mon, 2007-10-15 at 13:52 -0400, Manu Sporny wrote: 
> Andy Mabbett wrote:
> > On Mon, October 15, 2007 16:15, Manu Sporny wrote:
> > 
> >> Most of the examples that were gathered for hAudio were from music
> >> service websites and music blogs. To help us make progress, this round of
> >> haudio focuses on just albums and tracks.
> > 
> > Is that sufficient?
> 
> For albums and tracks, yes. For marking up classical music, no.
> 
> > How many of them were for classical music, including opera?
> 
> None. Not one of the submitted 145 example URLs contained any opera or
> classical music that I can recall. Draw whatever conclusions you want to
> from that statement. :)
> 
> If it bothers you, please collect some examples and add them to the
> audio-info-examples page. Although I fear it would be a waste of your
> time since we already have several proposals on the table that would
> solve the infinite nesting issue, which I assume, is what you are
> talking about.
> 
> >> However, that is beyond the scope of the current discussion, which is
> >> just albums and the contents of those albums (tracks).
> > 
> > Who gets to decide the scope of this or any other such discussion?
> 
> I was strongly requesting a scope of discussion because the thread was
> going all over the place. It's over 125 messages deep at this point -
> which is a good sign that people are talking about too many issues.
> 
> Also keep in mind that bringing in a great number of issues complicates
> things and slows the Microformat down. Case in point: The media-info
> discussion. I should also add that while a reminder to the scope of this
> discussion was given, the questions that were asked were answered.
> 
> -- manu
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From andy at pigsonthewing.org.uk  Mon Oct 15 23:13:17 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Mon Oct 15 23:14:49 2007
Subject: [uf-new] item property (was: hAudio: audio-title/album-title vs.
	recording/album)
In-Reply-To: <C3390863.71E4%Michael.Smethurst@bbc.co.uk>
References: <13009.80.249.57.38.1192444457.squirrel@www.gradwell.com>
	<C3390863.71E4%Michael.Smethurst@bbc.co.uk>
Message-ID: <d+zNmoT9ZFFHFw$2@pigsonthewing.org.uk>

In message <C3390863.71E4%Michael.Smethurst@bbc.co.uk>, Michael 
Smethurst <Michael.Smethurst@bbc.co.uk> writes

>
>On 15/10/07 11:34, "Andy Mabbett" <andy@pigsonthewing.org.uk> wrote:
>
>> On Mon, October 15, 2007 10:07, Michael Smethurst wrote:
>>
>>> I need to mark up performance/set lists for Glastonbury, the Proms
>>> etc
>>>
>>> In these cases track would be plain wrong
>>
>> How so?
>
>They may not be recorded or released on cd, tape or vinyl. That doesn't 
>fit any definition of track I know of

I was at a concert last night; the leader of one of the groups (Modified 
Toy Orchestra; witty and superb) announced at one point "the next track 
is called...."

-- 
Andy Mabbett
From andy at pigsonthewing.org.uk  Mon Oct 15 23:18:30 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Mon Oct 15 23:20:12 2007
Subject: [Audio] Playlists and Albums (was: Re: [uf-new] item property)
In-Reply-To: <1192495826.5054.93.camel@localhost.localdomain>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>
	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>
	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>
	<471383FD.7090701@digitalbazaar.com>
	<7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>
	<4713A8E6.5020404@digitalbazaar.com>
	<1192495826.5054.93.camel@localhost.localdomain>
Message-ID: <mPBTKYU2eFFHFwaw@pigsonthewing.org.uk>

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

>TRACK in the way Some on the list mean it is current popular slang for
>what is a composition or a song the stuff you actually hear through your
>speakers or read about on the Internet, very nice in your retro 50s to
>80s world when you were buying the latest groovy track by Cliff Richard
>but... the world has moved on

Apparently not, according to the evidence presented.

>what will a track be in the near future?
>To me as non-existent as Vinyl and CD's

Your personal hypothesis of some future development carries no weight.

>If we are going to use Slang to mark up hAudio why not class="choon" its
>as good a word as any?

Do we have any evidence that people, in the wild, are using "choon" to 
refer to individual pieces of music, on their web pages? No.

Do we have any evidence that people, in the wild, are using "track" to 
refer to individual pieces of music, on their web pages? Yes.

>all I have to go on is the Field definition on the wiki
>http://microformats.org/wiki/audio-info-proposal#Track
>and the principles of designing microformats
>http://microformats.org/wiki/principles

and the evidence.

[...]
 >a container that means nothing

Let's use a term that means something.

-- 
Andy Mabbett
From soc at code404.com  Mon Oct 15 23:50:28 2007
From: soc at code404.com (Justin Maxwell)
Date: Mon Oct 15 23:50:32 2007
Subject: [Audio] Playlists and Albums (was: Re: [uf-new] item property)
In-Reply-To: <mPBTKYU2eFFHFwaw@pigsonthewing.org.uk>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>
	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>
	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>
	<471383FD.7090701@digitalbazaar.com>
	<7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>
	<4713A8E6.5020404@digitalbazaar.com>
	<1192495826.5054.93.camel@localhost.localdomain>
	<mPBTKYU2eFFHFwaw@pigsonthewing.org.uk>
Message-ID: <7F4D8CAD-11A1-4D75-96B3-E92CCE3841FF@code404.com>

On Oct 15, 2007, at 11:18 PM, Andy Mabbett wrote:

> Do we have any evidence that people, in the wild, are using "choon"  
> to refer to individual pieces of music, on their web pages? No.

Unless of course by "no," you mean "yes."

http://www.google.com/search?q=choon+%2Bdubstep&btnG=Search

http://www.google.com/search?q=choon+%2Bjungle&btnG=Search

http://www.google.com/search?q=choon+%2Bgarage&btnG=Search

etc.

just search for "choon" + [electronic music genre]

and if that's not enough, feel free to throw the words "playlist,"  
"album," "set," and any other appropriate context in which "choons"  
might be "rinsed" in there for good measure...


personally hypothesizing a weight-free future development,
justin
From andy at pigsonthewing.org.uk  Tue Oct 16 11:13:24 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Tue Oct 16 11:14:48 2007
Subject: [Audio] Playlists and Albums (was: Re: [uf-new] item property)
In-Reply-To: <7F4D8CAD-11A1-4D75-96B3-E92CCE3841FF@code404.com>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>
	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>
	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>
	<471383FD.7090701@digitalbazaar.com>
	<7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>
	<4713A8E6.5020404@digitalbazaar.com>
	<1192495826.5054.93.camel@localhost.localdomain>
	<mPBTKYU2eFFHFwaw@pigsonthewing.org.uk>
	<7F4D8CAD-11A1-4D75-96B3-E92CCE3841FF@code404.com>
Message-ID: <PmdJAzYE9PFHFwdV@pigsonthewing.org.uk>

In message <7F4D8CAD-11A1-4D75-96B3-E92CCE3841FF@code404.com>, Justin
Maxwell <soc@code404.com> writes

>On Oct 15, 2007, at 11:18 PM, Andy Mabbett wrote:
>
>> Do we have any evidence that people, in the wild, are using "choon"
>>to refer to individual pieces of music, on their web pages? No.
>
>Unless of course by "no," you mean "yes."

I meant "no"; that's why I typed "no".

Note that I said "do we have", in the (then) present tense.

[...]
>feel free to throw the words "playlist,"  "album," "set," and any other
>appropriate context in which "choons"  might be "rinsed" in there for
>good measure...

Sure. Google finds:

        about    272,000 for choon +album

        about 99,000,000 for track +album

and:

        about    83,200 for choon +opera

        about 6,820,000 for track +opera

        (none of at least the first few pages of the former seems to
        relate "choon" to Opera in the classical sense)

and:

                    3 for "choon 1" +"choon 2" +album

        about 867,000 for "track 1" +"track 2" +album

        (none of the former seems to be from a list of
        sequentially-numbered "choons")


Does anyone still favour "choon" over "track"?

-- 
Andy Mabbett
From martin at weborganics.co.uk  Tue Oct 16 16:30:36 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Tue Oct 16 16:29:50 2007
Subject: [Audio] Playlists and Albums (was: Re: [uf-new] item property)
In-Reply-To: <mPBTKYU2eFFHFwaw@pigsonthewing.org.uk>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>
	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>
	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>
	<471383FD.7090701@digitalbazaar.com>
	<7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>
	<4713A8E6.5020404@digitalbazaar.com>
	<1192495826.5054.93.camel@localhost.localdomain>
	<mPBTKYU2eFFHFwaw@pigsonthewing.org.uk>
Message-ID: <1192577437.13041.41.camel@localhost.localdomain>

Hello Andy

I have enjoyed our debates over the weekend it was Interesting

....

On Tue, 2007-10-16 at 07:18 +0100, Andy Mabbett wrote:
> >all I have to go on is the Field definition on the wiki
> >http://microformats.org/wiki/audio-info-proposal#Track
> >and the principles of designing microformats
> >http://microformats.org/wiki/principles
> 
> and the evidence.

Thanks for getting to that :)

I have Just finished a study on the haudio examples page, Gathering
evidence so to speak I thought you may be Interested In the results...

The Question was do our examples show real world usage of people using
the word TRACK as a way to describe a single audio file?

at first looking at the results of previous efforts provided buy Manu it
would at first seem judging by the results that TRACK is widely used.

In the Analysis of Music Services

 85%: of the examples are using tracks

wow a lot I thought, so i thought Ill have another look I'm wrong so it
seems I want to know why?

The first thing I spotted was that someone seems to have spammed the
word "track" 100's of times all over our model examples and results,
making them as far as i can see unusable, Vandalized almost

Then I noticed this

iTunes RSS
extensions (http://www.apple.com/itunes/store/podcaststechspecs.html#_Toc526931673) 
              * Properties: track title, album title, track sample,
                album genre, album cover image, track artist, track
                length, description, track release date, track format,
                track id, track summary, album owner, album owner
                e-mail, album website, album language, track tags, album
                licensing

I have been a keen podcaster for years and TRACK does not exist in
iTunes RSS so how do we get those properties? from a document with NO
TRACK

another

Vorbis Comment
Recommendations (http://reactor-core.org/ogg-tagging.html) 
              * Properties: album artist, track title, album title,
                album label, album release date, track number, album
                genre, album cover image, track artist, track length,
                description, track release date, track album, track
                label, track genre, album license, track composer, track
                album title, track summary, track copyright, album part
                number, track cover image, track arranger, album
                comment, track location, album copyright, track disc
                number, album arranger, album isrc, album ensemble,
                track file type, album encoding, album ean/upn, track
                lyrics, track isrc, track conductor, track genres, track
                ensemble, album conductor, track part, track lyricist,
                track part number, album performer, album part, album
                version, track version, track comment, track opus, album
                author, track source media, album composer, track
                encoding, track encoded-by, track author, track
                performer, track label number, album location, track
                tags, album disc number, track ean/upn, track license,
                album encoded-by, album lyricist, track creators, album
                source media, album label catalog number, album opus
                
WTF TRACK does not exist in Vorbis Comments either TRACKNUMBER YES as a
Decimal

So my own study 

I looked at every example manualy by hand, using Firefox 

do the examples show people using track?

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

Speech
http://www.microformats.org/blog/2005/09/30/web-essentials-audio/
NO 1
http://chris.pirillo.com/help/20060119_chuck_cummins_on_windows_vista_interface_design.phtml
NO 2
http://yukelzon.blogspot.com/2006/01/podcasts.html
NO 3
http://www.evilgeniuschronicles.org/wordpress/2006/01/12/egc-clambake-for-january-12-2006/
NO 4
http://www.bizbyjake.com/2006/01/how-are-you-doing.html
NO 5
http://btpodshow.com/shows/?mode=detail&episode_id=56539
NO 6
http://reviews.cnet.com/4520-11455_7-6457370-1.html
NO 7
http://podcast.rubyonrails.org/
NO 8

--------------------------------------------------------------------------------------------------------------------------------------

 Music Individual Publishing of Music 

http://www.bradsucks.net/music/
NO 9
http://www.scottandrew.com/music/
NO 10
http://www.hearingdouble.co.uk/dumb/index2.html
UNAVAILABLE

_________________________________________________________________________________________________

 Music Podcasting

http://www.coverville.com/
NO 11
http://magnatune.com/podcasts/details/magnatune_middle-eastern_podcast_2006_12_14
NO 12
http://www.mutantpop.net/radioclash/archives/2007/03/24/rc-113/
NO  13
http://btpodshow.com/shows/?mode=detail&episode_id=56721
NO  14
http://indiecastwp.podshow.com/?p=76
NO  15
http://www.accidenthash.com/2007/04/02/gray-wet-yuck-monday/
NO 16
http://veercast.com/2007/05/31/episode-20-tranforming-you-into-stds-since-1983/
NO 17
http://threehive.libsyn.com/index.php?post_id=111596
NO 18

----------------------------------------------------------------------------------------------------------------------------------------

Mashups, remixes, cut-ups and audio-collages

http://viprhealthcare.typepad.com/mashup_of_the_week_podcas/
NO 19
http://bannedmusic.org/
UNAVAILABLE
http://illegalart.org/
NO MEDIA AVAILABLE
http://ccmixter.org/media/view/media/playlists
NO 20

---------------------------------------------------------------------------------------------------------------------------------------------

Top Lists (Charts)

http://top40.about.com/od/onthecharts/tp/top071007.htm
NO 21
http://www.channel4.com/entertainment/tv/microsites/G/greatest/albums/results.html
NO 22
http://www.bbc.co.uk/radio1/chart/singles.shtml
NO 23
http://www.bbc.co.uk/radio1/chart/downloads.shtml
NO 24
http://www.amazon.co.uk/2007s-Best-Singles-So-Far/lm/R1DMGDL2WC6DEK
NO 25
http://freakytrigger.co.uk/other-indexes/freaky-triggers-top-100-songs-of-all-time/
NO 26
http://freakytrigger.co.uk/other-indexes/freaky-triggers-top-100-songs-of-all-time/
NO 27
http://en.wikipedia.org/wiki/List_of_songs_in_English_labeled_the_best_ever
NOT FOUND 
http://billboard.com/bbcom/charts/chart_display.jsp?g=Singles&f=The
+Billboard+Hot+100
NO 28
http://www.nme.com/reviews/tracks/oftheyear
USES TRACKS to mean a collection
http://www.hearya.com/2007/02/14/top-100-indie-songs-of-all-time/
NO 29
http://www.rollingstone.com/news/story/5938174/the_rs_500_greatest_albums_of_all_time/
NO 30
http://www.theofficialcharts.com/top40_singles.php
NO 31
http://www.everyhit.com/worstever.html
NO 32

---------------------------------------------------------------------------------------------------------------------------------
 Service Publishing of Music

http://audiofind.ru/music/album/-/Lost%20Angel/Destination/?id=591
NO 33
http://bigpondmusic.com/Album/The-Decemberists/The-Crane-Wife.aspx
YES 1
http://www.bitmunk.com/view/media/6068744
YES 2
http://www.downloadpunk.com/?webaction=AlbumDetail&albumid=13202
NO 34
http://www.fye.com/Not-Too-Late-Music_stcVVproductId7456462VVcatId458211VVviewprod.htm
YES 3
http://imusic.libero.it/compilation.php?icom_id=105902&ptipo=pus&pid=171437
NO  35
http://www.omds.de/servlets/2452685121527Dispatch/31/Call?htmltemplate=./album/viewalbum.htm&lmtype=ALBUM&albumid=2310333
NO 36
http://musik.tdconline.dk/servlets/2452306090224Dispatch/19/call?htmltemplate=./album/viewalbum.htm&albumid=10783647
NO 37
http://www.audiolunchbox.com/album?a=75751
NO 38
http://chaos.com/product.asp?intProductID=739720&intArtistID=167488
Track Listing YES  4
http://store.connect-europe.com/albumDetailPage.do?albumId=3260785
UNAVAILABLE (LINUX)
http://www.digirama.co.nz/AlbumDetailsFeature.aspx?MediaID=578456
YES 5
http://www-v3.emusic.com/album/10917/10917324.html
UNAVAILABLE
http://www.fnacmusic.com/album/7088f214-6187-4845-afdc-6391e103f67d.aspx
NO 39
http://www.misrolas.com/downloadmusic/album.php?id=1316
NO 40
http://www.mtv.co.uk/shop/downloads
NO 41
http://musica360.com/
DEAD 42
http://www.musicload.de/item.ml?releaseid=1884260_2
NO 43
http://free.napster.com/view/album/index.html?id=12376484
YES 6
http://www.partymob.com/edl/details/default.aspx?album=2089814
NO 44
http://www2.peerimpact.com/contentstorage-xml/album30.do?templateName=WEB-INF/conversion-templates/album30.vm&albumId=89449
DEAD 45
http://www.puretracks.com/catalog/details.aspx?pid=warner_093624992899
USES TRACKS COLECTION 7
http://www.reggaecountry.com/shop/ItemInfo.aspx?AlbumID=10007
NO 46
http://www.rhapsody.com/harryconnickjr/chansonduvieuxcarrconnickonpiano3
YES 8
http://www.ruckus.com/ruckus/music/album.do?albumId=1405034
YES 9
http://www.sanity.com.au/product/product.asp?sku=2100360
YES 10
http://www.thecellcity.com/music/index.php?command=productquery&department=music&section=R+%26+B+and+Hip+Hop&startrecord=14&numrecords=13&cdmnomimematch=y&order=Rating
NO 47
http://www.top100.cn/
NO 48
http://www.wippit.com/GenreArtist.aspx?StrCatId=20&StrCatType=S
UNAVAILABLE
http://yanga.ru/music/album/-/Duke%20Ellington/Jack%20The%
20Bear/?id=28510
YES as a list 11
http://magnatune.com/artists/albums/ammonite-recon/
NO 49
http://www.songfight.org/artistpage.php?key=15-16_puzzle&sortkey=date
NO 50
http://www.yes.com/
NO 51
http://myspace.com/theradioknives
NO 52
http://musicbrainz.org/release/1138abc1-77f4-4ba9-900d-5cf52baaf4bf.html
NO 53
http://reactor-core.org/ogg-tagging.html
NO but Not MUSIC ?
http://www.apple.com/itunes/store/podcaststechspecs.html#_Toc526931673
NO NOT MUSIC  ?
http://www.discogs.com/release/705805
YES as a LIST 12

-------------------------------------------------------------------------------------------------------------------------------------------

 In-active Music Services

NONE Anylized

--------------------------------------------------------------------------------------------------------------------------------------------

Discographies

http://soundtrackcollector.net/catalog/soundtrackdetail.php?movieid=9659
YES 13
http://en.wikipedia.org/wiki/Dark_side_of_the_moon
YES 14

100% YES

------------------------------------------------------------------------------------------------------------------------------------------- 

Result

21% of 67 available examples DO use Track or Tracklist

89% of 67 available examples DO NOT use Track or Tracklist


----------------------------------------------------------------------------------------------------------------------

Im truthfully appaled that Our Model that we found all our debates on Is
wildly inaccurate? 

I Really dont think that we can have a clear Idea of what hAudio is
Until our our examples are re-studied without the use of a program.

But really who is going to do that? not me? again?

I have No Intrest now 

Do what you will I wont be using hAudio 


Martin






> 
> [...] 

From msporny at digitalbazaar.com  Tue Oct 16 18:06:49 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue Oct 16 18:06:53 2007
Subject: [Audio] Playlists and Albums (was: Re: [uf-new] item property)
In-Reply-To: <1192577437.13041.41.camel@localhost.localdomain>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>	<471383FD.7090701@digitalbazaar.com>	<7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>	<4713A8E6.5020404@digitalbazaar.com>	<1192495826.5054.93.camel@localhost.localdomain>	<mPBTKYU2eFFHFwaw@pigsonthewing.org.uk>
	<1192577437.13041.41.camel@localhost.localdomain>
Message-ID: <47156029.7050104@digitalbazaar.com>

Martin McEvoy wrote:
> The first thing I spotted was that someone seems to have spammed the
> word "track" 100's of times all over our model examples and results,
> making them as far as i can see unusable, Vandalized almost

Martin, I wish you had said something before going and doing all that
hard work (not that it wasn't useful).

The site is not vandalized, I used those names when merging from the
old, manual way of doing things to the new Microformalyze way of doing
things. There was no data loss. There were numerous namespace collisions
between the terms we were using to identify properties for albums and
tracks.

For example, we had used "title" to denote the name for albums and
tracks... obviously, if we merged both records, we wouldn't be able to
tell which one was the album title and which one was the track title...
so I wrote a script to convert it to "album title" and "track title".
There is no foul play going on here... however, if you think there is,
you're more than welcome to quadruple check the work (it has already
been triple checked).

Whether track or choon is used on the examples page, however, is of no
consequence to the discussion. The names on the examples pages have
almost nothing to do with the names that we pick for the actual proposal.

When analyzing websites on any examples page, we must ensure that we use
common property names when performing the analysis of the data. We need
to perform apples-to-apples comparisons. In other words, if we say that
websites A and B have PROPERTY_FOO, then we will use PROPERTY_FOO across
analysis write-ups to denote if the websites do or do not have PROPERTY_FOO.

I decided to use track because it was the most obvious choice (to me) at
the time... however, that decision has no bearing on the current discussion.

-- manu

From msporny at digitalbazaar.com  Tue Oct 16 18:23:39 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue Oct 16 18:23:43 2007
Subject: [Audio] Playlists and Albums (was: Re: [uf-new] item property)
In-Reply-To: <1192577437.13041.41.camel@localhost.localdomain>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>	<471383FD.7090701@digitalbazaar.com>	<7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>	<4713A8E6.5020404@digitalbazaar.com>	<1192495826.5054.93.camel@localhost.localdomain>	<mPBTKYU2eFFHFwaw@pigsonthewing.org.uk>
	<1192577437.13041.41.camel@localhost.localdomain>
Message-ID: <4715641B.4050408@digitalbazaar.com>

Martin McEvoy wrote:
> Im truthfully appaled that Our Model that we found all our debates on Is
> wildly inaccurate? 

It is not. :)

I stand by the examples, the analysis and the research performed to date
by myself and several others (including you, Martin). I also challenge
you to prove its "wild inaccuracy". Many people have looked at the data
and helped to analyze it numerous times. All the data is there for the
world to see.

> I Really dont think that we can have a clear Idea of what hAudio is
> Until our our examples are re-studied without the use of a program.

Why do you think this approach is going to help us?

That "program", Microformalyze[1], merely is an application and a
database that helps the user track the properties on each page. It can
automatically calculate statistics and helped the process of analysis
immensely.

All of the analysis is still done by a human. There is no automatic
anything in Microformalyze. Have you ever used the application?

Once again, all of the source code is there as well as the data files.
Feel free to go over them as many times as you want to... please report
your findings back to the mailing list, I believe you will not be
disappointed.

-- manu

[1] http://microformats.org/wiki/microformalyze-software
From lucapost at gmail.com  Thu Oct 18 11:01:13 2007
From: lucapost at gmail.com (LucaP)
Date: Thu Oct 18 11:01:19 2007
Subject: [uf-new] Measurement brainstorming
Message-ID: <f436e9f80710181101j99f85e5y4938db6670e01118@mail.gmail.com>

Hi all, I have been redirected in here after posting my personal
measurement-brainstorming on the 'discuss' list:

http://www.mail-archive.com/microformats-discuss@microformats.org/msg08902.html

Despite being totally unaware of this thread, my reasoning seems to
fit for the most part in the ongoing discussion, I believe there is
one big issue that has been totally forgotten thought:

in many contexts (scientific/technical) a measurement has no meaning
without a corresponding error/confidence!

thus, something like <span class="data-error">0.1</span> should find
its place inside hmeasure ( hWhateverWillBe), actually this can be
simplified by exploiting the '&plusmn;' html-entity to signal the
beginning of the error-value part, in place of the extra <span
class="data-error>

The correct measurement notation on paper is normally (absolute_error):

( 5.8 +/- 0.4 ) km.

i.e. the 2 values must be expressed in the same unit and with the same
precision (number of digits).
This is far more important than requiring that the string used for the
unit-measure conforms with SI standard.
As long as the 2 values are consistent (as defined above), they
represent a valid data-entry in some unit, and the parser's should
just 'export' (*).

another notation is (relative_error):

5.8 Km. +/- 7%

error propagation on derived quantities is computed by algebraic rules
on relative_errors, than converted back to the absolute_error
notation.

Sorry for the cheap 101-lesson in Experimental Science & Statistics!


(*)
Verifying strict SI-conformance is not that important for the entry in
itself, it does get crucial when comparing and combining entries, but
I believe this is a separate computing layer and the initial hmeasure
specs can go soft about it.
For example let's imagine a 'universal unit-conversion Firefox
extension', it would definetly exploit the hmeasure parser, but would
have to take care of unit-validations on its own, once it gets the
data entries from the parser.
From martin at weborganics.co.uk  Thu Oct 18 14:58:41 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Thu Oct 18 14:57:55 2007
Subject: [Audio] Playlists and Albums (was: Re: [uf-new] item property)
In-Reply-To: <4715641B.4050408@digitalbazaar.com>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>
	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>
	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>
	<471383FD.7090701@digitalbazaar.com>
	<7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>
	<4713A8E6.5020404@digitalbazaar.com>
	<1192495826.5054.93.camel@localhost.localdomain>
	<mPBTKYU2eFFHFwaw@pigsonthewing.org.uk>
	<1192577437.13041.41.camel@localhost.localdomain>
	<4715641B.4050408@digitalbazaar.com>
Message-ID: <1192744721.24894.41.camel@localhost.localdomain>

On Tue, 2007-10-16 at 21:23 -0400, Manu Sporny wrote:
> Martin McEvoy wrote:
> > Im truthfully appaled that Our Model that we found all our debates on Is
> > wildly inaccurate? 
> 
> It is not. :)
> 
> I stand by the examples, the analysis and the research performed to date
> by myself and several others (including you, Martin). I also challenge
> you to prove its "wild inaccuracy". Many people have looked at the data
> and helped to analyze it numerous times. All the data is there for the
> world to see.

I know I have seen It and you are right I have gone over it *many*
times...

> 
> > I Really dont think that we can have a clear Idea of what hAudio is
> > Until our our examples are re-studied without the use of a program.

Because it is my opinion that the data output of your application is not
to be relied upon

> 
> Why do you think this approach is going to help us?

Why do you think that the Microformalyze approach is going to help us?

do you not think the Hand and Eye are a better approach? 

> 
> That "program", Microformalyze[1], 

A 15kb Python script

> merely is an application and a
> database 

and a text file ...

I understand what it is, credit me with some intelligence please :). 

> that helps the user track the properties on each page. It can
> automatically calculate statistics and helped the process of analysis
> immensely.

This is my concern *HOW* does Microformalize do this? 

Microformalize has all the power of a high profile search engine that
can output the relevance of a given keyword in order and frequency of
occurrence correct?

> 
> All of the analysis is still done by a human. There is no automatic
> anything in Microformalyze. Have you ever used the application?
> 

Have you ever asked a silly question? :)

> Once again, all of the source code is there as well as the data files.
> Feel free to go over them as many times as you want to... 

I have done Thank You

> please report
> your findings back to the mailing list, 

we will see.

> I believe you will not be
> disappointed.

I'm just interested in having a reliable model to work with, which
hasn't got much to do with If I approve or not, its to do with accuracy
of data.

Thanks

Martin
> 
> -- manu
> 
> [1] http://microformats.org/wiki/microformalyze-software
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From chrisjroos at gmail.com  Fri Oct 19 00:22:44 2007
From: chrisjroos at gmail.com (Chris Roos)
Date: Fri Oct 19 00:22:50 2007
Subject: [uf-new] Another problem statement for a Receipt Microformat
Message-ID: <3a5e51050710190022o23f4c9d4gfb0f43347e40dbb8@mail.gmail.com>

I've just been looking at a receipt page where the retailer has some
of the receipt data repeated ten times.  This is to satisfy the nine
different providers they work with (each one uses javascript to
redefine the receipt data) and to display it to the user.  It seems to
me that a receipt microformat could (assuming those providers were to
get on board) reduce this duplication.

I wrote about this in a little more detail on my blog[1].

Does this seem like a valid problem to want to solve?  If so, what
should I do next (add stuff to the wiki)?

Cheers,

Chris

[1]  http://blog.seagul.co.uk/articles/2007/10/19/a-common-pattern-in-retailers-receipt-pages-and-a-microformat-solution
From msporny at digitalbazaar.com  Fri Oct 19 07:57:13 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri Oct 19 07:58:54 2007
Subject: Microformalyze (was: Playlists and Albums (was: Re: [uf-new]
	item property))
In-Reply-To: <1192744721.24894.41.camel@localhost.localdomain>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>	<471383FD.7090701@digitalbazaar.com>	<7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>	<4713A8E6.5020404@digitalbazaar.com>	<1192495826.5054.93.camel@localhost.localdomain>	<mPBTKYU2eFFHFwaw@pigsonthewing.org.uk>	<1192577437.13041.41.camel@localhost.localdomain>	<4715641B.4050408@digitalbazaar.com>
	<1192744721.24894.41.camel@localhost.localdomain>
Message-ID: <4718C5C9.2070803@digitalbazaar.com>

Martin McEvoy wrote:
>>> I Really dont think that we can have a clear Idea of what hAudio is
>>> Until our our examples are re-studied without the use of a program.
> 
> Because it is my opinion that the data output of your application is not
> to be relied upon

I don't want this to become a nasty discussion, Martin. I realize that
you have questions about Microformalyze and I am attempting to answer them.

I believe the tone of this discussion is a bit off... right now, it
sounds like you're alluding to the notion that there has been some sort
of "nefarious behavior" when gathering data for hAudio, or that the data
we have is not dependable. I realize that my responses could have been
less inflammatory and more explanatory.

I am going to attempt to explain how Microformalyze works in a more
explanatory manner.

>> Why do you think this approach is going to help us?
> 
> Why do you think that the Microformalyze approach is going to help us?
> do you not think the Hand and Eye are a better approach? 

Microformalyze is a "Hand and Eye" approach... there is no automation to
the "analyzing a web page" part of the tool.

It saves us the time from having to tally statistics by hand. It is also
far more accurate to have a machine tally the results and statistics.

Before we were using Microformalyze there were several errors when
calculating the statistics that I made. It is difficult to go through 48
examples and over 1,000 properties by hand, calculate statistics, and
not expect some human error.

Here's how we used to gather examples for hAudio:

1. Open up the hAudio Wiki.
2. Copy/Paste one example URL into a different tab in the web browser.
3. Copy/Paste the hAudio example template that had all of the properties
   into the correct part of the wiki page.
4. Flip between the hAudio Wiki tab and the example URL page, adding or
   deleting properties from hAudio.
5. Repeat this process 84 times (each page took around 20 minutes to
   analyze).

Here's how it works with Microformalyze:

1. Open up Microformalyze
2. Click "Add URL" to add URLs that need to be analyzed.
3. Click "Add property" to add properties that you expect to see (this
   can also be done while you're analyzing the pages)
4. Once all of the URLs that need to be analyzed have been added, you
   click the "Next URL" button.
5. Microformalyze displays the URL in a web browser and you click
   checkboxes to specify what properties exist on the example URL page.
   This small change to the process cuts down the time to analyze a
   page greatly... mainly because you're not editing wiki text, you're
   just clicking a checkbox.
6. Repeat this process 84 times (each page took around 5 minutes to
   analyze).

The old way of doing things took around 20 minutes per website. The
Microformalyze way of doing things takes around 5 minutes per website.

Now let's examine how we calculated statistics before:

Here's how we did it via the Wiki:

Every time a new property was created, I would have to go through and
tally the results by hand. This was error prone and on more than one
occasion, I had to wipe everything and start over. It also required me
to triple-check my work to make sure I was reporting the correct
statistics to the list. I spent hours doing this - just calculating
statistics. There is a reason not many people help out with gathering
examples and calculating statistics - it is tedious and excruciatingly
time consuming.

Here's how it was done using Microformalyze:

You click a button and the statistics are automatically calculated for
you. You click another button and it dumps the wiki formatted text for
displaying the properties. It is no longer time consuming or error prone
to do this!

However, the most important aspect of Microformalyze is that ANYBODY can
go back and validate our findings easily. The data files are there,
there is a common namespace across all properties/websites, in other
words: there is a verifiable paper trail.

It is important to point out that this does not exist for any other
Microformat that I know about. Verifiability of analysis results is very
important! Reducing human error in statistics calculations is very
important! Microformalyze builds this into the examples gathering and
statistics calculation process.

>> that helps the user track the properties on each page. It can
>> automatically calculate statistics and helped the process of analysis
>> immensely.
> 
> This is my concern *HOW* does Microformalize do this? 
> 
> Microformalize has all the power of a high profile search engine that
> can output the relevance of a given keyword in order and frequency of
> occurrence correct?

No, absolutely not. This is the core of your misunderstanding of what
Microformalyze does. There is no "search engine" or "keyword matching"
technology in Microformalyze. That would be a horrible way to go about
gathering examples.

All Microformalyze does is automate the tedious and error-prone parts of
the examples and statistics gathering portion of the Microformats
process. It also adds verifiability - which is really it's most
important contribution to the process.

If you would like to see a detailed tutorial on how it works, the
tutorial is available here:

http://wiki.digitalbazaar.com/en/Microformalyze#Tutorial

I'd be happy to answer any other questions or concerns that you have
about Microformalyze. Like I said before, all of the data files, source
code (which I placed under the GPL), and documentation is available via
the website listed above. You don't have to take my word for it... you
could read the code, look at the data and see for yourself.

-- manu
From martin at weborganics.co.uk  Fri Oct 19 14:15:30 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Oct 19 14:14:47 2007
Subject: Microformalyze (was: Playlists and Albums (was: Re: [uf-new]
	item property))
In-Reply-To: <4718C5C9.2070803@digitalbazaar.com>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>
	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>
	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>
	<471383FD.7090701@digitalbazaar.com>
	<7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>
	<4713A8E6.5020404@digitalbazaar.com>
	<1192495826.5054.93.camel@localhost.localdomain>
	<mPBTKYU2eFFHFwaw@pigsonthewing.org.uk>
	<1192577437.13041.41.camel@localhost.localdomain>
	<4715641B.4050408@digitalbazaar.com>
	<1192744721.24894.41.camel@localhost.localdomain>
	<4718C5C9.2070803@digitalbazaar.com>
Message-ID: <1192828530.29450.65.camel@localhost.localdomain>

On Fri, 2007-10-19 at 10:57 -0400, Manu Sporny wrote:
> Martin McEvoy wrote:
> >>> I Really dont think that we can have a clear Idea of what hAudio is
> >>> Until our our examples are re-studied without the use of a program.
> > 
> > Because it is my opinion that the data output of your application is not
> > to be relied upon
> 
> I don't want this to become a nasty discussion, 

?? now you are confusing me, this is a nasty discussion because I ask
questions? 

> Martin. I realize that
> you have questions about Microformalyze and I am attempting to answer them.
> 
> I believe the tone of this discussion is a bit off... right now, it
> sounds like you're alluding to the notion that there has been some sort
> of "nefarious behavior" when gathering data for hAudio, 

I am not saying that there is some sort of sinister behavior going on at
all I am pointing out that the data that Microformalize outputs (in the
terminal) is not to be trusted.

> or that the data
> we have is not dependable. I realize that my responses could have been
> less inflammatory and more explanatory.
> 
> I am going to attempt to explain how Microformalyze works in a more
> explanatory manner.
> 
> >> Why do you think this approach is going to help us?
> > 
> > Why do you think that the Microformalyze approach is going to help us?
> > do you not think the Hand and Eye are a better approach? 
> 
> Microformalyze is a "Hand and Eye" approach... there is no automation to
> the "analyzing a web page" part of the tool.
> 

...

> It saves us the time from having to tally statistics by hand. It is also
> far more accurate to have a machine tally the results and statistics.
> 

...

> Before we were using Microformalyze there were several errors when
> calculating the statistics that I made. It is difficult to go through 48
> examples and over 1,000 properties by hand, calculate statistics, and
> not expect some human error.
> 
> Here's how we used to gather examples for hAudio:
> 
> 1. Open up the hAudio Wiki.
> 2. Copy/Paste one example URL into a different tab in the web browser.
> 3. Copy/Paste the hAudio example template that had all of the properties
>    into the correct part of the wiki page.
> 4. Flip between the hAudio Wiki tab and the example URL page, adding or
>    deleting properties from hAudio.
> 5. Repeat this process 84 times (each page took around 20 minutes to
>    analyze).
> 
> Here's how it works with Microformalyze:
> 
> 1. Open up Microformalyze
> 2. Click "Add URL" to add URLs that need to be analyzed.
> 3. Click "Add property" to add properties that you expect to see (this
>    can also be done while you're analyzing the pages)
> 4. Once all of the URLs that need to be analyzed have been added, you
>    click the "Next URL" button.
> 5. Microformalyze displays the URL in a web browser and you click
>    checkboxes to specify what properties exist on the example URL page.

So I tell the application what properties exist on a given page, and It
confirms if this is true or not?

>    This small change to the process cuts down the time to analyze a
>    page greatly... mainly because you're not editing wiki text, you're
>    just clicking a checkbox.
> 6. Repeat this process 84 times (each page took around 5 minutes to
>    analyze).
> 
> The old way of doing things took around 20 minutes per website. The
> Microformalyze way of doing things takes around 5 minutes per website.
> 
> Now let's examine how we calculated statistics before:
> 
> Here's how we did it via the Wiki:
> 
> Every time a new property was created, I would have to go through and
> tally the results by hand. This was error prone and on more than one
> occasion, I had to wipe everything and start over. It also required me
> to triple-check my work to make sure I was reporting the correct
> statistics to the list. I spent hours doing this - just calculating
> statistics. There is a reason not many people help out with gathering
> examples and calculating statistics - it is tedious and excruciatingly
> time consuming.
> 
> Here's how it was done using Microformalyze:
> 
> You click a button and the statistics are automatically calculated for
> you. You click another button and it dumps the wiki formatted text for
> displaying the properties. It is no longer time consuming or error prone
> to do this!
> 
> However, the most important aspect of Microformalyze is that ANYBODY can
> go back and validate our findings easily. The data files are there,
> there is a common namespace across all properties/websites, in other
> words: there is a verifiable paper trail.
> 
> It is important to point out that this does not exist for any other
> Microformat that I know about. Verifiability of analysis results is very
> important! Reducing human error in statistics calculations is very
> important! Microformalyze builds this into the examples gathering and
> statistics calculation process.
> 
> >> that helps the user track the properties on each page. It can
> >> automatically calculate statistics and helped the process of analysis
> >> immensely.
> > 
> > This is my concern *HOW* does Microformalize do this? 
> > 
> > Microformalize has all the power of a high profile search engine that
> > can output the relevance of a given keyword in order and frequency of
> > occurrence correct?
> 
> No, absolutely not. This is the core of your misunderstanding of what
> Microformalyze does. There is no "search engine" or "keyword matching"
> technology in Microformalyze. That would be a horrible way to go about
> gathering examples.
> 
> All Microformalyze does is automate the tedious and error-prone parts of
> the examples and statistics gathering portion of the Microformats
> process. It also adds verifiability - which is really it's most
> important contribution to the process.

Sorry my friend I don't think I was being very clear

*HOW* does Microformalize do this? 

What Is a property? 
how is a property determined?, 
does Microformalize Analyze the raw html to determine the existence of
these properties? does it look for actual output on a web page?

How does it gather statistics?
how are they compared?, are they compared against other url's loaded
into Microformalize, or does it calculate the occurence of a "property"
on a page, or some other way?

> 
> If you would like to see a detailed tutorial on how it works, the
> tutorial is available here:
> 
> http://wiki.digitalbazaar.com/en/Microformalyze#Tutorial

Thanks for the tutorial but How do I use Microformalize was not the
question.

> 
> I'd be happy to answer any other questions or concerns that you have
> about Microformalyze. Like I said before, all of the data files, source
> code (which I placed under the GPL), and documentation is available via
> the website listed above. You don't have to take my word for it... you
> could read the code, look at the data and see for yourself.

I have had a look at the code but Python is not my strong point, Perhaps
you might like to explain?

I did a test, the "properties" I was Looking for were Baba and Flumps
(because there is a good chance that these properties will NOT exist in
any of the pages I'm likely to test)

here is the test file (copy and paste if you like)

property	Baba	The Elephant
property	Flumps	A sweetie
url	Bazaar	http://blog.digitalbazaar.com/
properties	Baba	Flumps

sorry to use your url but it was the first thing that sprung to mind :)

I ticked both boxes in the GUI Baba and Flumps and outputted the data in
the terminal

Baba                               : 100.00%
Flumps                             : 100.00%


I looked at your page thinking "Huh" how can that be correct?

In the web page text there is no mention of the words Baba or Flumps 

I looked at the source code No no Mention there either?

Does Microformalize determine the existence of these properties in
another way?

I added another url to examine

property	Baba	The Elephant
property	Flumps	A sweetie
url	Bazaar	http://blog.digitalbazaar.com/
properties	Baba	Flumps
url	no foo in this	http://weborganics.co.uk/
properties	Baba


the outputed data from the second url

Baba                               : 100.00%
Flumps                             : 50.00%

I KNOW these two properties do not exist in any way at WebOrganics

Can you see now WHY I am concerned and moderately confused 
Microformalize does not seem to be calculating the existence of these
properties on a page it seems to be Just calculating if I have ticked a
box or not.


Am I missing something?


Thanks

Martin
 
> 
> -- manu
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From scott at makedatamakesense.com  Fri Oct 19 14:53:01 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Fri Oct 19 14:53:05 2007
Subject: Microformalyze (was: Playlists and Albums (was: Re: [uf-new] item
	property))
In-Reply-To: <1192828530.29450.65.camel@localhost.localdomain>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>
	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>
	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>
	<471383FD.7090701@digitalbazaar.com>
	<7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>
	<4713A8E6.5020404@digitalbazaar.com>
	<1192495826.5054.93.camel@localhost.localdomain>
	<mPBTKYU2eFFHFwaw@pigsonthewing.org.uk>
	<1192577437.13041.41.camel@localhost.localdomain>
	<4715641B.4050408@digitalbazaar.com>
	<1192744721.24894.41.camel@localhost.localdomain>
	<4718C5C9.2070803@digitalbazaar.com>
	<1192828530.29450.65.camel@localhost.localdomain>
Message-ID: <8ABCBCA0-22B2-40B3-843B-FB494AF9F6EC@makedatamakesense.com>

On Oct 19, 2007, at 3:15 PM, Martin McEvoy wrote:
>
> I ticked both boxes in the GUI Baba and Flumps and outputted the  
> data in
> the terminal
>
> Baba                               : 100.00%
> Flumps                             : 100.00%
>
> I looked at your page thinking "Huh" how can that be correct?

It's not correct, but that's because you gave it incorrect  
information by clicking boxes for properties that weren't really  
there.  The tool itself isn't determining what properties are there  
or not there at all; it only makes it easier for a person to do  
that.  As Manu was the person who analyzed most of the hAudio sites,  
your suggestion that the data isn't trustworthy is essentially a  
suggestion that Manu isn't trustworthy.

Obviously no one is perfect, so if you still think the analysis is  
wrong, please try to point out specifically where you see errors so  
we can correct them.  So far I get the impression you're just using a  
different meaning of the word "track" than Manu.  As long as  
everything Manu called "track" is relatively the same type of  
information, the specific name isn't particularly important at the  
schema analysis stage.

--
Scott Reynen
MakeDataMakeSense.com


From martin at weborganics.co.uk  Fri Oct 19 16:03:58 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Fri Oct 19 16:03:10 2007
Subject: Microformalyze (was: Playlists and Albums (was: Re: [uf-new]
	item property))
In-Reply-To: <8ABCBCA0-22B2-40B3-843B-FB494AF9F6EC@makedatamakesense.com>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>
	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>
	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>
	<471383FD.7090701@digitalbazaar.com>
	<7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>
	<4713A8E6.5020404@digitalbazaar.com>
	<1192495826.5054.93.camel@localhost.localdomain>
	<mPBTKYU2eFFHFwaw@pigsonthewing.org.uk>
	<1192577437.13041.41.camel@localhost.localdomain>
	<4715641B.4050408@digitalbazaar.com>
	<1192744721.24894.41.camel@localhost.localdomain>
	<4718C5C9.2070803@digitalbazaar.com>
	<1192828530.29450.65.camel@localhost.localdomain>
	<8ABCBCA0-22B2-40B3-843B-FB494AF9F6EC@makedatamakesense.com>
Message-ID: <1192835038.2234.10.camel@localhost.localdomain>

On Fri, 2007-10-19 at 15:53 -0600, Scott Reynen wrote:
> On Oct 19, 2007, at 3:15 PM, Martin McEvoy wrote:
> >
> > I ticked both boxes in the GUI Baba and Flumps and outputted the  
> > data in
> > the terminal
> >
> > Baba                               : 100.00%
> > Flumps                             : 100.00%
> >
> > I looked at your page thinking "Huh" how can that be correct?
> 
> It's not correct, but that's because you gave it incorrect  
> information by clicking boxes for properties that weren't really  
> there.  The tool itself isn't determining what properties are there  
> or not there at all; it only makes it easier for a person to do  
> that.  As Manu was the person who analyzed most of the hAudio sites,  
> your suggestion that the data isn't trustworthy is essentially a  
> suggestion that Manu isn't trustworthy.

What is up with this List? How on earth do you come to that
conclusion?...

> 
> Obviously no one is perfect, so if you still think the analysis is  
> wrong, please try to point out specifically where you see errors so  
> we can correct them.  So far I get the impression you're just using a  
> different meaning of the word "track" than Manu.  As long as  
> everything Manu called "track" is relatively the same type of  
> information, the specific name isn't particularly important at the  
> schema analysis stage.

Thank you Scott for a nice short answer sometimes you do make sense :)

you load properties that you would like to find in a webpage

add a few urls the page opens in a browser and YOU the user verifies
that the data exists by ticking a box.. correct?

Microformalize does not examine the page for its contents the User Does.


....

Thanks 

Martin

> 
> --
> Scott Reynen
> MakeDataMakeSense.com
> 
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
From roBman at MobileOnlineBusiness.com.au  Fri Oct 19 20:23:03 2007
From: roBman at MobileOnlineBusiness.com.au (Rob Manson)
Date: Fri Oct 19 20:23:20 2007
Subject: Microformalyze (was: Playlists and Albums (was: Re: [uf-new]
	item property))
In-Reply-To: <1192828530.29450.65.camel@localhost.localdomain>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>
	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>
	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>
	<471383FD.7090701@digitalbazaar.com>
	<7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>
	<4713A8E6.5020404@digitalbazaar.com>
	<1192495826.5054.93.camel@localhost.localdomain>
	<mPBTKYU2eFFHFwaw@pigsonthewing.org.uk>
	<1192577437.13041.41.camel@localhost.localdomain>
	<4715641B.4050408@digitalbazaar.com>
	<1192744721.24894.41.camel@localhost.localdomain>
	<4718C5C9.2070803@digitalbazaar.com>
	<1192828530.29450.65.camel@localhost.localdomain>
Message-ID: <1192850583.3125.121.camel@robslap>

Martin,

it doesn't analyse the page for Baba and Flumps...you do.

You checked the boxes telling it Baba and Flumps are there...so it gave
you a 100% answer.

8)


Manu, I think it's a very useful tool to help standardise analysis.


roBman


On Fri, 2007-10-19 at 22:15 +0100, Martin McEvoy wrote:
> On Fri, 2007-10-19 at 10:57 -0400, Manu Sporny wrote:
> > Martin McEvoy wrote:
> > >>> I Really dont think that we can have a clear Idea of what hAudio is
> > >>> Until our our examples are re-studied without the use of a program.
> > > 
> > > Because it is my opinion that the data output of your application is not
> > > to be relied upon
> > 
> > I don't want this to become a nasty discussion, 
> 
> ?? now you are confusing me, this is a nasty discussion because I ask
> questions? 
> 
> > Martin. I realize that
> > you have questions about Microformalyze and I am attempting to answer them.
> > 
> > I believe the tone of this discussion is a bit off... right now, it
> > sounds like you're alluding to the notion that there has been some sort
> > of "nefarious behavior" when gathering data for hAudio, 
> 
> I am not saying that there is some sort of sinister behavior going on at
> all I am pointing out that the data that Microformalize outputs (in the
> terminal) is not to be trusted.
> 
> > or that the data
> > we have is not dependable. I realize that my responses could have been
> > less inflammatory and more explanatory.
> > 
> > I am going to attempt to explain how Microformalyze works in a more
> > explanatory manner.
> > 
> > >> Why do you think this approach is going to help us?
> > > 
> > > Why do you think that the Microformalyze approach is going to help us?
> > > do you not think the Hand and Eye are a better approach? 
> > 
> > Microformalyze is a "Hand and Eye" approach... there is no automation to
> > the "analyzing a web page" part of the tool.
> > 
> 
> ...
> 
> > It saves us the time from having to tally statistics by hand. It is also
> > far more accurate to have a machine tally the results and statistics.
> > 
> 
> ...
> 
> > Before we were using Microformalyze there were several errors when
> > calculating the statistics that I made. It is difficult to go through 48
> > examples and over 1,000 properties by hand, calculate statistics, and
> > not expect some human error.
> > 
> > Here's how we used to gather examples for hAudio:
> > 
> > 1. Open up the hAudio Wiki.
> > 2. Copy/Paste one example URL into a different tab in the web browser.
> > 3. Copy/Paste the hAudio example template that had all of the properties
> >    into the correct part of the wiki page.
> > 4. Flip between the hAudio Wiki tab and the example URL page, adding or
> >    deleting properties from hAudio.
> > 5. Repeat this process 84 times (each page took around 20 minutes to
> >    analyze).
> > 
> > Here's how it works with Microformalyze:
> > 
> > 1. Open up Microformalyze
> > 2. Click "Add URL" to add URLs that need to be analyzed.
> > 3. Click "Add property" to add properties that you expect to see (this
> >    can also be done while you're analyzing the pages)
> > 4. Once all of the URLs that need to be analyzed have been added, you
> >    click the "Next URL" button.
> > 5. Microformalyze displays the URL in a web browser and you click
> >    checkboxes to specify what properties exist on the example URL page.
> 
> So I tell the application what properties exist on a given page, and It
> confirms if this is true or not?
> 
> >    This small change to the process cuts down the time to analyze a
> >    page greatly... mainly because you're not editing wiki text, you're
> >    just clicking a checkbox.
> > 6. Repeat this process 84 times (each page took around 5 minutes to
> >    analyze).
> > 
> > The old way of doing things took around 20 minutes per website. The
> > Microformalyze way of doing things takes around 5 minutes per website.
> > 
> > Now let's examine how we calculated statistics before:
> > 
> > Here's how we did it via the Wiki:
> > 
> > Every time a new property was created, I would have to go through and
> > tally the results by hand. This was error prone and on more than one
> > occasion, I had to wipe everything and start over. It also required me
> > to triple-check my work to make sure I was reporting the correct
> > statistics to the list. I spent hours doing this - just calculating
> > statistics. There is a reason not many people help out with gathering
> > examples and calculating statistics - it is tedious and excruciatingly
> > time consuming.
> > 
> > Here's how it was done using Microformalyze:
> > 
> > You click a button and the statistics are automatically calculated for
> > you. You click another button and it dumps the wiki formatted text for
> > displaying the properties. It is no longer time consuming or error prone
> > to do this!
> > 
> > However, the most important aspect of Microformalyze is that ANYBODY can
> > go back and validate our findings easily. The data files are there,
> > there is a common namespace across all properties/websites, in other
> > words: there is a verifiable paper trail.
> > 
> > It is important to point out that this does not exist for any other
> > Microformat that I know about. Verifiability of analysis results is very
> > important! Reducing human error in statistics calculations is very
> > important! Microformalyze builds this into the examples gathering and
> > statistics calculation process.
> > 
> > >> that helps the user track the properties on each page. It can
> > >> automatically calculate statistics and helped the process of analysis
> > >> immensely.
> > > 
> > > This is my concern *HOW* does Microformalize do this? 
> > > 
> > > Microformalize has all the power of a high profile search engine that
> > > can output the relevance of a given keyword in order and frequency of
> > > occurrence correct?
> > 
> > No, absolutely not. This is the core of your misunderstanding of what
> > Microformalyze does. There is no "search engine" or "keyword matching"
> > technology in Microformalyze. That would be a horrible way to go about
> > gathering examples.
> > 
> > All Microformalyze does is automate the tedious and error-prone parts of
> > the examples and statistics gathering portion of the Microformats
> > process. It also adds verifiability - which is really it's most
> > important contribution to the process.
> 
> Sorry my friend I don't think I was being very clear
> 
> *HOW* does Microformalize do this? 
> 
> What Is a property? 
> how is a property determined?, 
> does Microformalize Analyze the raw html to determine the existence of
> these properties? does it look for actual output on a web page?
> 
> How does it gather statistics?
> how are they compared?, are they compared against other url's loaded
> into Microformalize, or does it calculate the occurence of a "property"
> on a page, or some other way?
> 
> > 
> > If you would like to see a detailed tutorial on how it works, the
> > tutorial is available here:
> > 
> > http://wiki.digitalbazaar.com/en/Microformalyze#Tutorial
> 
> Thanks for the tutorial but How do I use Microformalize was not the
> question.
> 
> > 
> > I'd be happy to answer any other questions or concerns that you have
> > about Microformalyze. Like I said before, all of the data files, source
> > code (which I placed under the GPL), and documentation is available via
> > the website listed above. You don't have to take my word for it... you
> > could read the code, look at the data and see for yourself.
> 
> I have had a look at the code but Python is not my strong point, Perhaps
> you might like to explain?
> 
> I did a test, the "properties" I was Looking for were Baba and Flumps
> (because there is a good chance that these properties will NOT exist in
> any of the pages I'm likely to test)
> 
> here is the test file (copy and paste if you like)
> 
> property	Baba	The Elephant
> property	Flumps	A sweetie
> url	Bazaar	http://blog.digitalbazaar.com/
> properties	Baba	Flumps
> 
> sorry to use your url but it was the first thing that sprung to mind :)
> 
> I ticked both boxes in the GUI Baba and Flumps and outputted the data in
> the terminal
> 
> Baba                               : 100.00%
> Flumps                             : 100.00%
> 
> 
> I looked at your page thinking "Huh" how can that be correct?
> 
> In the web page text there is no mention of the words Baba or Flumps 
> 
> I looked at the source code No no Mention there either?
> 
> Does Microformalize determine the existence of these properties in
> another way?
> 
> I added another url to examine
> 
> property	Baba	The Elephant
> property	Flumps	A sweetie
> url	Bazaar	http://blog.digitalbazaar.com/
> properties	Baba	Flumps
> url	no foo in this	http://weborganics.co.uk/
> properties	Baba
> 
> 
> the outputed data from the second url
> 
> Baba                               : 100.00%
> Flumps                             : 50.00%
> 
> I KNOW these two properties do not exist in any way at WebOrganics
> 
> Can you see now WHY I am concerned and moderately confused 
> Microformalize does not seem to be calculating the existence of these
> properties on a page it seems to be Just calculating if I have ticked a
> box or not.
> 
> 
> Am I missing something?
> 
> 
> Thanks
> 
> Martin
>  
> > 
> > -- manu
> > _______________________________________________
> > microformats-new mailing list
> > microformats-new@microformats.org
> > http://microformats.org/mailman/listinfo/microformats-new
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
> 

From martin at weborganics.co.uk  Sat Oct 20 03:39:01 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sat Oct 20 03:38:19 2007
Subject: [uf-new] Re: Microformalyze (Apology made an ass of myself)
In-Reply-To: <1192828530.29450.65.camel@localhost.localdomain>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>
	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>
	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>
	<471383FD.7090701@digitalbazaar.com>
	<7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>
	<4713A8E6.5020404@digitalbazaar.com>
	<1192495826.5054.93.camel@localhost.localdomain>
	<mPBTKYU2eFFHFwaw@pigsonthewing.org.uk>
	<1192577437.13041.41.camel@localhost.localdomain>
	<4715641B.4050408@digitalbazaar.com>
	<1192744721.24894.41.camel@localhost.localdomain>
	<4718C5C9.2070803@digitalbazaar.com>
	<1192828530.29450.65.camel@localhost.localdomain>
Message-ID: <1192876741.7599.5.camel@localhost.localdomain>

On Fri, 2007-10-19 at 22:15 +0100, Martin McEvoy wrote:
> On Fri, 2007-10-19 at 10:57 -0400, Manu Sporny wrote:
> > Martin McEvoy wrote:
> > >>> I Really dont think that we can have a clear Idea of what hAudio is
> > >>> Until our our examples are re-studied without the use of a program.
> > > 
> > > Because it is my opinion that the data output of your application is not
> > > to be relied upon
> > 
> > I don't want this to become a nasty discussion, 
> 
> ?? now you are confusing me, this is a nasty discussion because I ask
> questions? 
> 
> > Martin. I realize that
> > you have questions about Microformalyze and I am attempting to answer them.
> > 
> > I believe the tone of this discussion is a bit off... right now, it
> > sounds like you're alluding to the notion that there has been some sort
> > of "nefarious behavior" when gathering data for hAudio, 
> 
> I am not saying that there is some sort of sinister behavior going on at
> all I am pointing out that the data that Microformalize outputs (in the
> terminal) is not to be trusted.
> 
> > or that the data
> > we have is not dependable. I realize that my responses could have been
> > less inflammatory and more explanatory.
> > 
> > I am going to attempt to explain how Microformalyze works in a more
> > explanatory manner.
> > 
> > >> Why do you think this approach is going to help us?
> > > 
> > > Why do you think that the Microformalyze approach is going to help us?
> > > do you not think the Hand and Eye are a better approach? 
> > 
> > Microformalyze is a "Hand and Eye" approach... there is no automation to
> > the "analyzing a web page" part of the tool.
> > 
> 
> ...
> 
> > It saves us the time from having to tally statistics by hand. It is also
> > far more accurate to have a machine tally the results and statistics.
> > 
> 
> ...
> 
> > Before we were using Microformalyze there were several errors when
> > calculating the statistics that I made. It is difficult to go through 48
> > examples and over 1,000 properties by hand, calculate statistics, and
> > not expect some human error.
> > 
> > Here's how we used to gather examples for hAudio:
> > 
> > 1. Open up the hAudio Wiki.
> > 2. Copy/Paste one example URL into a different tab in the web browser.
> > 3. Copy/Paste the hAudio example template that had all of the properties
> >    into the correct part of the wiki page.
> > 4. Flip between the hAudio Wiki tab and the example URL page, adding or
> >    deleting properties from hAudio.
> > 5. Repeat this process 84 times (each page took around 20 minutes to
> >    analyze).
> > 
> > Here's how it works with Microformalyze:
> > 
> > 1. Open up Microformalyze
> > 2. Click "Add URL" to add URLs that need to be analyzed.
> > 3. Click "Add property" to add properties that you expect to see (this
> >    can also be done while you're analyzing the pages)
> > 4. Once all of the URLs that need to be analyzed have been added, you
> >    click the "Next URL" button.
> > 5. Microformalyze displays the URL in a web browser and you click
> >    checkboxes to specify what properties exist on the example URL page.
> 
> So I tell the application what properties exist on a given page, and It
> confirms if this is true or not?
> 
> >    This small change to the process cuts down the time to analyze a
> >    page greatly... mainly because you're not editing wiki text, you're
> >    just clicking a checkbox.
> > 6. Repeat this process 84 times (each page took around 5 minutes to
> >    analyze).
> > 
> > The old way of doing things took around 20 minutes per website. The
> > Microformalyze way of doing things takes around 5 minutes per website.
> > 
> > Now let's examine how we calculated statistics before:
> > 
> > Here's how we did it via the Wiki:
> > 
> > Every time a new property was created, I would have to go through and
> > tally the results by hand. This was error prone and on more than one
> > occasion, I had to wipe everything and start over. It also required me
> > to triple-check my work to make sure I was reporting the correct
> > statistics to the list. I spent hours doing this - just calculating
> > statistics. There is a reason not many people help out with gathering
> > examples and calculating statistics - it is tedious and excruciatingly
> > time consuming.
> > 
> > Here's how it was done using Microformalyze:
> > 
> > You click a button and the statistics are automatically calculated for
> > you. You click another button and it dumps the wiki formatted text for
> > displaying the properties. It is no longer time consuming or error prone
> > to do this!
> > 
> > However, the most important aspect of Microformalyze is that ANYBODY can
> > go back and validate our findings easily. The data files are there,
> > there is a common namespace across all properties/websites, in other
> > words: there is a verifiable paper trail.
> > 
> > It is important to point out that this does not exist for any other
> > Microformat that I know about. Verifiability of analysis results is very
> > important! Reducing human error in statistics calculations is very
> > important! Microformalyze builds this into the examples gathering and
> > statistics calculation process.
> > 
> > >> that helps the user track the properties on each page. It can
> > >> automatically calculate statistics and helped the process of analysis
> > >> immensely.
> > > 
> > > This is my concern *HOW* does Microformalize do this? 
> > > 
> > > Microformalize has all the power of a high profile search engine that
> > > can output the relevance of a given keyword in order and frequency of
> > > occurrence correct?
> > 
> > No, absolutely not. This is the core of your misunderstanding of what
> > Microformalyze does. There is no "search engine" or "keyword matching"
> > technology in Microformalyze. That would be a horrible way to go about
> > gathering examples.
> > 
> > All Microformalyze does is automate the tedious and error-prone parts of
> > the examples and statistics gathering portion of the Microformats
> > process. It also adds verifiability - which is really it's most
> > important contribution to the process.
> 
> Sorry my friend I don't think I was being very clear
> 
> *HOW* does Microformalize do this? 
> 
> What Is a property? 
> how is a property determined?, 
> does Microformalize Analyze the raw html to determine the existence of
> these properties? does it look for actual output on a web page?
> 
> How does it gather statistics?
> how are they compared?, are they compared against other url's loaded
> into Microformalize, or does it calculate the occurence of a "property"
> on a page, or some other way?
> 
> > 
> > If you would like to see a detailed tutorial on how it works, the
> > tutorial is available here:
> > 
> > http://wiki.digitalbazaar.com/en/Microformalyze#Tutorial
> 
> Thanks for the tutorial but How do I use Microformalize was not the
> question.
> 
> > 
> > I'd be happy to answer any other questions or concerns that you have
> > about Microformalyze. Like I said before, all of the data files, source
> > code (which I placed under the GPL), and documentation is available via
> > the website listed above. You don't have to take my word for it... you
> > could read the code, look at the data and see for yourself.
> 
> I have had a look at the code but Python is not my strong point, Perhaps
> you might like to explain?
> 
> I did a test, the "properties" I was Looking for were Baba and Flumps
> (because there is a good chance that these properties will NOT exist in
> any of the pages I'm likely to test)
> 
> here is the test file (copy and paste if you like)
> 
> property	Baba	The Elephant
> property	Flumps	A sweetie
> url	Bazaar	http://blog.digitalbazaar.com/
> properties	Baba	Flumps
> 
> sorry to use your url but it was the first thing that sprung to mind :)
> 
> I ticked both boxes in the GUI Baba and Flumps and outputted the data in
> the terminal
> 
> Baba                               : 100.00%
> Flumps                             : 100.00%
> 
> 
> I looked at your page thinking "Huh" how can that be correct?
> 
> In the web page text there is no mention of the words Baba or Flumps 
> 
> I looked at the source code No no Mention there either?
> 
> Does Microformalize determine the existence of these properties in
> another way?
> 
> I added another url to examine
> 
> property	Baba	The Elephant
> property	Flumps	A sweetie
> url	Bazaar	http://blog.digitalbazaar.com/
> properties	Baba	Flumps
> url	no foo in this	http://weborganics.co.uk/
> properties	Baba
> 
> 
> the outputed data from the second url
> 
> Baba                               : 100.00%
> Flumps                             : 50.00%
> 
> I KNOW these two properties do not exist in any way at WebOrganics
> 
> Can you see now WHY I am concerned and moderately confused 
> Microformalize does not seem to be calculating the existence of these
> properties on a page it seems to be Just calculating if I have ticked a
> box or not.
> 
> 
> Am I missing something?

You know I am Impossibly Dense sometimes, Lets call it being
overworked :)

Sorry Manu Looking at the above now It seems I was making an ass of
myself again

Wish I was better at apologising


Thanks

Martin
> 
> 
> Thanks
> 
> Martin
>  
> > 
> > -- manu
> > _______________________________________________
> > microformats-new mailing list
> > microformats-new@microformats.org
> > http://microformats.org/mailman/listinfo/microformats-new

From msporny at digitalbazaar.com  Sat Oct 20 10:29:42 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sat Oct 20 10:29:45 2007
Subject: [uf-new] Re: Microformalyze (Apology made an ass of myself)
In-Reply-To: <1192876741.7599.5.camel@localhost.localdomain>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>	<471383FD.7090701@digitalbazaar.com>	<7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>	<4713A8E6.5020404@digitalbazaar.com>	<1192495826.5054.93.camel@localhost.localdomain>	<mPBTKYU2eFFHFwaw@pigsonthewing.org.uk>	<1192577437.13041.41.camel@localhost.localdomain>	<4715641B.4050408@digitalbazaar.com>	<1192744721.24894.41.camel@localhost.localdomain>	<4718C5C9.2070803@digitalbazaar.com>	<1192828530.29450.65.camel@localhost.localdomain>
	<1192876741.7599.5.camel@localhost.localdomain>
Message-ID: <471A3B06.70900@digitalbazaar.com>

Martin McEvoy wrote:
>> Baba                               : 100.00%
>> Flumps                             : 50.00%
>>
>> I KNOW these two properties do not exist in any way at WebOrganics
>>
>> Can you see now WHY I am concerned and moderately confused 
>> Microformalize does not seem to be calculating the existence of these
>> properties on a page it seems to be Just calculating if I have ticked a
>> box or not.
>>
>> Am I missing something?
> 
> You know I am Impossibly Dense sometimes, Lets call it being
> overworked :)
> 
> Sorry Manu Looking at the above now It seems I was making an ass of
> myself again
> 
> Wish I was better at apologising

No problem, Martin - no need to feel that bad about it. I could have
been much more helpful in the first reply I sent to the list regarding
the examples and Microformalyze, so my apologies for that. :)

Your intentions were good and that goes a long way. Plus, there has
never been a public vetting on Microformalyze, so that was very useful
as well. In addition, we can say that the hAudio examples have been
rigorously defended - which only strengthens the hAudio Microformat.

All in all, while painful, these discussions help us understand what
we're doing in the Microformats community and how we go about doing it.

That being said, I'm going to be mailing an updated proposal to the
hAudio TRACK/ITEM debate that I think will work for everyone involved
and will hopefully resolve the last major remaining issues for hAudio!

-- manu
From msporny at digitalbazaar.com  Sat Oct 20 11:16:08 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sat Oct 20 11:16:11 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
Message-ID: <471A45E8.1030303@digitalbazaar.com>

This e-mail is a proposed resolution to the hAudio ITEM/TRACK debate.
The list has seemed to have calmed down a bit, so I have gone back
through and attempted to address each post's concerns about using either
ITEM or TRACK. The proposed resolution is a mix of Martin, Scott, Andy,
Julian, Michael, David, Tantek, Brian, and Ben's input. It is a solution
that will hopefully work for everyone.

GOALS:

The primary goal is to create a mechanism for listing hAudio tracks
within hAudio albums.

The secondary goal is to create a mechanism that is expandable. We know
we might want to support classical music, opera, parts of podcasts,
top-lists and other forms of audio eventually, so the solution should
not prevent this from happening.

PROPOSAL:

1. HAUDIO can contain plain text to specify the FN property:
   <span class="haudio">Song Name</span>
2. HAUDIO parts are denoted by ITEM+HAUDIO:
   <span class="item haudio">Track Name</span>

EXAMPLES:

Album with two tracks, simple example:
<span class="haudio">
    <span class="fn album">Best Before 1984</span>
    <span class="contributor">Crass</span>
    <span class="item haudio">Hokkaido Dream</span>
    <span class="item haudio">Tokyo Groove</span>
</span>

Album with two tracks, more detailed:
<span class="haudio">
   <span class="fn album">Best Before 1984</span>
   <span class="contributor">Crass</span>
   <span class="item haudio">
      <span class="fn">Hokkaido Dream</span>
      <abbr class="duration" title="PT3M24S">3:24</abbr>
   </span>
   <span class="item haudio">
      <span class="fn">Tokyo Groove</span>
      <abbr class="duration" title="PT4M46S">4:46</abbr>
   </span>
</span>

REASONING:

TRACK seems to be far too controversial of a name to use for the
property. There seem to be people on both sides of the debate and rather
than try and convince each other, let's re-frame the discussion to see
if we can agree on something else. The proposal above gives us the
following benefits:

 * Re-use of an existing Microformat property.
 * Not creating a new TRACK property (a Good Thing).
 * Pairing HAUDIO with ITEM solves the problem of ITEM being too generic
   and not specific (Andy and my primary problem with ITEM).
 * We are creating a number of short-hand markup approaches will allow
   publishers to write hAudio in a much easier way.
 * It enables marking up opera, classical music, and other singular
   recordings with movements, parts, sections, etc.
 * It allows the publisher to do infinite nesting (not that we have
   identified that as a need... but it also doesn't prevent it from
   happening, which is good).
 * We seem to have cracked the hSet/hBag/hContainer/item container
   problem.

These are the drawbacks that have been identified for the following
approach:

 * "ITEM HAUDIO" isn't as specific as TRACK.

If there isn't much push-back for this approach, we should probably
change the hAudio draft to reflect it and create an implementation in
Operator to test it.

Thoughts, comments, suggestions?

-- manu

From brian.suda at gmail.com  Sat Oct 20 12:18:41 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Sat Oct 20 12:24:52 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <471A45E8.1030303@digitalbazaar.com>
References: <471A45E8.1030303@digitalbazaar.com>
Message-ID: <21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>

On 10/20/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> PROPOSAL:
>
> 1. HAUDIO can contain plain text to specify the FN property:
>    <span class="haudio">Song Name</span>

--- i'm not against this, but lets not put this in right now. This is
an optimization. As Donald Knuth said "Premature optimization is the
root of all evil". Lets keep the <span class="fn"> for now, try it for
a few iterations, then we can discuss optimizations later. hCard is
not <span class="vcard">brian suda</span>, it is still <div
class="vcard"><span class="fn">brian suda</span></div> optimization
have been discussed, but there hasn't beed a NEED for this yet, so
lets not complicate hAudio with optimization YET. We might "paint
ourselves into corners" with premature optimizations, so i'd rather
have something working in the wild with implementations, then we can
discuss this further based on evidence rather than assumptions.

> 2. HAUDIO parts are denoted by ITEM+HAUDIO:
>    <span class="item haudio">Track Name</span>

--- i don't think the  haudio in your class list is needed. With
haudio, item and fn, that nesting can tell you everything you need.
Let me edit your examples below to illustrate

> EXAMPLES:
>
> Album with two tracks, simple example:
> <span class="haudio">
>     <span class="fn album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
>     <span class="item haudio">Hokkaido Dream</span>
>     <span class="item haudio">Tokyo Groove</span>
> </span>

The previous would need to be changed to:
<span class="haudio">
     <span class="fn album">Best Before 1984</span>
     <span class="contributor">Crass</span>
     <span class="item">
         <span class="fn">Hokkaido Dream</span>
     </span>
    <span class="item">
         <span class="fn">Tokyo Groove</span>
     </span>
</span>

(this is just expanding the optimization of FN in an item and removing
the un-needed haudio)

> Album with two tracks, more detailed:
> <span class="haudio">
>    <span class="fn album">Best Before 1984</span>
>    <span class="contributor">Crass</span>
>    <span class="item haudio">
>       <span class="fn">Hokkaido Dream</span>
>       <abbr class="duration" title="PT3M24S">3:24</abbr>
>    </span>
>    <span class="item haudio">
>       <span class="fn">Tokyo Groove</span>
>       <abbr class="duration" title="PT4M46S">4:46</abbr>
>    </span>
> </span>

--- this looks fine, except you don't need the class="item haudio", it
just needs to be class="item"


>  * We are creating a number of short-hand markup approaches will allow
>    publishers to write hAudio in a much easier way.

--- i think at the moment we should avoid premature optimizations, we
can re-examine them at a later date.

> These are the drawbacks that have been identified for the following
> approach:
>
>  * "ITEM HAUDIO" isn't as specific as TRACK.

--- this is a good thing, it is just an ITEM. We can reuse all the
semantics of hReview. For things like iTunes "buy this album and get a
video too" now you can still use ITEM to represent a nested VIDEO or
PDF or other formats, not just AUDIO.  Using the class="type" you
could specific what it is, track, video, pdf, etc. If there is no TYPE
it is assumed to be an audio track. I don't think we need to make the
connection of "item haudio" to "cast" the item as an audio element.

So if you want to talk about JUST a track you can do this:
<span class="haudio">
     <span class="item">
         <span class="fn">Hokkaido Dream</span>
     </span>
</span>

it might be slightly more verbose that you want, but we can always
discuss optimization later once we have real data to work with. Lets
not throw the baby out with the bathwater. First get a working format,
then iterate for optimizations.

That would be my suggestion
-brian

-- 
brian suda
http://suda.co.uk
From davidjanes at blogmatrix.com  Sat Oct 20 12:47:07 2007
From: davidjanes at blogmatrix.com (David Janes)
Date: Sat Oct 20 13:14:41 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>
References: <471A45E8.1030303@digitalbazaar.com>
	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>
Message-ID: <21e523c20710201247i3291ee76me57e58e2d3d5d9c5@mail.gmail.com>

On 10/20/07, Brian Suda <brian.suda@gmail.com> wrote:

> > These are the drawbacks that have been identified for the following
> > approach:
> >
> >  * "ITEM HAUDIO" isn't as specific as TRACK.
>
> --- this is a good thing, it is just an ITEM. We can reuse all the
> semantics of hReview. For things like iTunes "buy this album and get a
> video too" now you can still use ITEM to represent a nested VIDEO or
> PDF or other formats, not just AUDIO.  Using the class="type" you
> could specific what it is, track, video, pdf, etc. If there is no TYPE
> it is assumed to be an audio track. I don't think we need to make the
> connection of "item haudio" to "cast" the item as an audio element.
>
> So if you want to talk about JUST a track you can do this:
> <span class="haudio">
>      <span class="item">
>          <span class="fn">Hokkaido Dream</span>
>      </span>
> </span>
>
> it might be slightly more verbose that you want, but we can always
> discuss optimization later once we have real data to work with. Lets
> not throw the baby out with the bathwater. First get a working format,
> then iterate for optimizations.
>

Hi Brian,

The idea -- based on previous discussions, feedback, etc. -- was that
for hItem to be compatible with "hreview" (and others [1]) it would
defined as follows:
- if not paired with an appropriate semantic class, the hItem refers
to the "top level" uF -- this is how hReview and hListing use it
- if paired with an appropriate semantic class -- e.g. "haudio" or
"track" -- then the hItem refers to that particular sub-element of the
uF

This feels rightish to me, but I'm not wedded to it.

Regards, etc...
David

[1] http://microformats.org/wiki/item-formats#hListing
-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
From scott at makedatamakesense.com  Sat Oct 20 13:32:40 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sat Oct 20 13:32:42 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>
References: <471A45E8.1030303@digitalbazaar.com>
	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>
Message-ID: <62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>

On Oct 20, 2007, at 1:18 PM, Brian Suda wrote:

> So if you want to talk about JUST a track you can do this:
> <span class="haudio">
>      <span class="item">
>          <span class="fn">Hokkaido Dream</span>
>      </span>
> </span>
>
> it might be slightly more verbose that you want, but we can always
> discuss optimization later once we have real data to work with.

The above seems to be based on a brand new idea of how we determine  
the difference between an album and a track.  We've been assuming  
until now that hAudio is a track by default.  This seems to be  
supported by the examples, in which there are many more tracks than  
albums.  The above seems to assume the opposite, that hAudio is  
always an album.  I see no reason to make such an assumption.  Could  
you maybe explain why the above is preferable to the individual track  
model we've been working with, e.g.:

<span class="haudio">
	<span class="fn">Hokkaido Dream</span>
</span>

This seems to me analogous to hCard's treatment of organizations and  
individuals.  Individuals are more common, so we assume individuals.   
Tracks are more common, so why shouldn't we assume tracks?

--
Scott Reynen
MakeDataMakeSense.com


From brian.suda at gmail.com  Sat Oct 20 13:36:26 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Sat Oct 20 13:36:28 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <21e523c20710201247i3291ee76me57e58e2d3d5d9c5@mail.gmail.com>
References: <471A45E8.1030303@digitalbazaar.com>
	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>
	<21e523c20710201247i3291ee76me57e58e2d3d5d9c5@mail.gmail.com>
Message-ID: <21e770780710201336q65d627a8id0d5939afb2c087c@mail.gmail.com>

On 10/20/07, David Janes <davidjanes@blogmatrix.com> wrote:
> The idea -- based on previous discussions, feedback, etc. -- was that
> for hItem to be compatible with "hreview" (and others [1]) it would
> defined as follows:
> - if not paired with an appropriate semantic class, the hItem refers
> to the "top level" uF -- this is how hReview and hListing use it

--- right, so in the examples, since there was only one "top-level" uF
the class="item haudio" would not need the extra "haudio" because we
know which we are talking about

> - if paired with an appropriate semantic class -- e.g. "haudio" or
> "track" -- then the hItem refers to that particular sub-element of the
> uF

--- i don't perticularly like "sectioning off" of microformated data.
Firstly, we are venturing into theoretical territory with "what if an
haudio was in an hreview", but this is a solvable problem with the
tools and rules we already have.

<div class="hreview">
<span class="haudio">
    <span class="fn album">Best Before 1984</span>
    <span class="contributor">Crass</span>
    <span class="item">
        <span class="fn">Hokkaido Dream</span>
    </span>
   <span class="item">
        <span class="fn">Tokyo Groove</span>
    </span>
</span>
</div>

In this case the FN of the hReview would be THE FIRST fn it finds in
an item object, so it would be Hokkaido Dream. To fix this, simply add
am "item" property into the <span class="haudio">.

<div class="hreview">
<span class="haudio">
    <span class="fn">Best Before 1984</span>
    ...

Then the first FN that is found inside an ITEM inside an HREVIEW is
now "Best Before 1984" the other items are ignored in the context of
hreview but NOT for haudio. It solves both problems without extra
mark-up.

As for hItem, if it went by the same "first only" rules, then it would
find 3 items, with 3 corresponding FNs without the need for any
sectioning off of data.

I think that solves the issues nicely. The "type casing" of what an
item is optional. We do it with hResume, and somewhat with hCard's
ADR. The ADR should be an hCard, just like the class="contributor"
SHOULD be an hCard, but isn't a MUST. We should examine this more on a
case-by-case basis if issues arrise rather than protect against
something that might not even exist.

-brian

-- 
brian suda
http://suda.co.uk
From brian.suda at gmail.com  Sat Oct 20 14:03:01 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Sat Oct 20 14:03:03 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>
References: <471A45E8.1030303@digitalbazaar.com>
	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>
	<62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>
Message-ID: <21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>

On 10/20/07, Scott Reynen <scott@makedatamakesense.com> wrote:
> The above seems to be based on a brand new idea of how we determine
> the difference between an album and a track.  We've been assuming
> until now that hAudio is a track by default.

--- fair enough, the problem then is that we seem to have a problem
with focus on what we are trying to achieve. This thread is called
"ITEM/TRACK debate" if hAudio is track by default, then what is the
debate? in the examples the author seems to be rolling metadata about
an album into haudio and therefore a new class had to be made to
corner off data about the ALBUM from data about TRACKS. If we are NOT
talking about album metadata, then things get alot easier, but i don't
get the feeling that is what we are discussing. The example:

<span class="haudio">
   <span class="fn album">Best Before 1984</span>
   <span class="contributor">Crass</span>
   <span class="item haudio">Hokkaido Dream</span>
   <span class="item haudio">Tokyo Groove</span>
</span>

to me says "haudio" is about an object with some metadata and 2
tracks. If haudio is ONLY about tracks, then the base haudio would be
incorrect. If haudio is more about collections of multi-media, then
the ITEM is where the TRACK info exists (what we assumed haudio was
all about in the first place)

> This seems to be
> supported by the examples, in which there are many more tracks than
> albums.

--- if that is the case, then we should NOT use haudio as the root
class name to mean a collection of audio stuff, too me the examples
provide looked like Albums being marked-up with haudio

> The above seems to assume the opposite, that hAudio is
> always an album.

--- this would be correct.

> I see no reason to make such an assumption.  Could
> you maybe explain why the above is preferable to the individual track
> model we've been working with

--- there seems to be two ways we COULD represent albums. #1 assuming
all tracks are in an album and use /haudio/item/fn for just tracks
that way we COULD have /haudio/fn and /haudio/item/fn to give an album
name and a track name.... or #2 we could invert the relationship, and
use /haudio/fn to be the track name an have /haudio/collection to
associate an track to an album or podcast or something. I thought the
second idea was shot-down because if you have multiple tracks on a
page in the same album, you would need to explictly list the album
name for each track.

> This seems to me analogous to hCard's treatment of organizations and
> individuals.  Individuals are more common, so we assume individuals.

--- right, ORG would be analigous to option #2 where you explicitly
list the ALBUM. The downside is that if there are 2 track (like 20
people) the (ORG or ALBUM) would have to be repeated 20 times. Where
as option #1 assumes we are talking about an ALBUM (or an
ORGANIZATION) and everything in it is part of that container (ORG or
ALBUM)

> Tracks are more common, so why shouldn't we assume tracks?

--- i would think so, but the examples in this email seems to suggest
otherwise. I think we need a clarification of the goals.

On a side-note, ID3 tags works like #2, each TRACK includes data about
the ALBUM, not ALBUM with TRACK data.

I have re-read the audio-info-proposal:
http://microformats.org/wiki/audio-info-proposal
to try and find more direction on what we are attempting to model. The
Intro and Scope aren't very clear, it mentions AUDIO alot, but not
TRACK or ALBUM.

I think we should make it more explict on the wiki, this could be as a
result of the analysis of example collected.

I'm happy to make the default assumption TRACK rather than ALBUM. Then
i would say the original examples in this would have to be:

Album with two tracks, simple example:

<span class="haudio">
   <span class="fn>Hokkaido Dream</span>
   <span class="collection">Best Before 1984</span>
   <span class="contributor">Crass</span>
</span>

<span class="haudio">
   <span class="fn">Tokyo Groove</span>
   <span class="collection">Best Before 1984</span>
   <span class="contributor">Crass</span>
</span>

Album with two tracks, more detailed:

<span class="haudio">
   <span class="fn>Hokkaido Dream</span>
    <abbr class="duration" title="PT3M24S">3:24</abbr>
   <span class="collection">Best Before 1984</span>
   <span class="contributor">Crass</span>
</span>

<span class="haudio">
   <span class="fn">Tokyo Groove</span>
   <span class="collection">Best Before 1984</span>
   <span class="contributor">Crass</span>
    <abbr class="duration" title="PT4M46S">4:46</abbr>
</span>

They would need to be two distinct haudio items because haudio models
TRACKs not albums. The duplicate data could be solved with the
include-pattern.

-brian

-- 
brian suda
http://suda.co.uk
From davidjanes at blogmatrix.com  Sat Oct 20 14:11:52 2007
From: davidjanes at blogmatrix.com (David Janes)
Date: Sat Oct 20 14:11:53 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <21e770780710201336q65d627a8id0d5939afb2c087c@mail.gmail.com>
References: <471A45E8.1030303@digitalbazaar.com>
	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>
	<21e523c20710201247i3291ee76me57e58e2d3d5d9c5@mail.gmail.com>
	<21e770780710201336q65d627a8id0d5939afb2c087c@mail.gmail.com>
Message-ID: <21e523c20710201411p2ddbb99eoc1c8d97cd9c376fb@mail.gmail.com>

Just so this is clear, I wasn't trying to take a position on the
"fn"-optimization nor on the merits of "sectioning off" vs.
"first-come/first-serve"; sorry that this was misinterpreted this way.

The issue was the way "item" is being described as you are using isn't
or wasn't seen to be 100% compatible with the existing definitions;
you'll have to read the thread from about a week ago for the
particulars. A way around this issue was the pairing of hItem with
another semantic-class to form a composite.

Regards, etc...

On 10/20/07, Brian Suda <brian.suda@gmail.com> wrote:
> On 10/20/07, David Janes <davidjanes@blogmatrix.com> wrote:
> > The idea -- based on previous discussions, feedback, etc. -- was that
> > for hItem to be compatible with "hreview" (and others [1]) it would
> > defined as follows:
> > - if not paired with an appropriate semantic class, the hItem refers
> > to the "top level" uF -- this is how hReview and hListing use it
>
> --- right, so in the examples, since there was only one "top-level" uF
> the class="item haudio" would not need the extra "haudio" because we
> know which we are talking about
>
> > - if paired with an appropriate semantic class -- e.g. "haudio" or
> > "track" -- then the hItem refers to that particular sub-element of the
> > uF
>
> --- i don't perticularly like "sectioning off" of microformated data.
> Firstly, we are venturing into theoretical territory with "what if an
> haudio was in an hreview", but this is a solvable problem with the
> tools and rules we already have.
>
> <div class="hreview">
> <span class="haudio">
>     <span class="fn album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
>     <span class="item">
>         <span class="fn">Hokkaido Dream</span>
>     </span>
>    <span class="item">
>         <span class="fn">Tokyo Groove</span>
>     </span>
> </span>
> </div>
>
> In this case the FN of the hReview would be THE FIRST fn it finds in
> an item object, so it would be Hokkaido Dream. To fix this, simply add
> am "item" property into the <span class="haudio">.
>
> <div class="hreview">
> <span class="haudio">
>     <span class="fn">Best Before 1984</span>
>     ...
>
> Then the first FN that is found inside an ITEM inside an HREVIEW is
> now "Best Before 1984" the other items are ignored in the context of
> hreview but NOT for haudio. It solves both problems without extra
> mark-up.
>
> As for hItem, if it went by the same "first only" rules, then it would
> find 3 items, with 3 corresponding FNs without the need for any
> sectioning off of data.
>
> I think that solves the issues nicely. The "type casing" of what an
> item is optional. We do it with hResume, and somewhat with hCard's
> ADR. The ADR should be an hCard, just like the class="contributor"
> SHOULD be an hCard, but isn't a MUST. We should examine this more on a
> case-by-case basis if issues arrise rather than protect against
> something that might not even exist.
>
> -brian
>
> --
> brian suda
> http://suda.co.uk
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
>


-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
From scott at makedatamakesense.com  Sat Oct 20 15:26:21 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sat Oct 20 15:26:22 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>
References: <471A45E8.1030303@digitalbazaar.com>
	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>
	<62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>
	<21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>
Message-ID: <BE1F12E0-B669-40CB-B930-B26471BEC1A0@makedatamakesense.com>

On Oct 20, 2007, at 3:03 PM, Brian Suda wrote:

>> The above seems to be based on a brand new idea of how we determine
>> the difference between an album and a track.  We've been assuming
>> until now that hAudio is a track by default.
>
> --- fair enough, the problem then is that we seem to have a problem
> with focus on what we are trying to achieve. This thread is called
> "ITEM/TRACK debate" if hAudio is track by default, then what is the
> debate?

The debate is specific to the non-default (but still worth covering)  
case where the audio is an album.  We'd already settled on a syntax  
for declaring that, the equivalent of hCard's syntax for declaring an  
organization (if the name is the album, it's an album).  The question  
was how we label the tracks within an album.  Until your proposal, we  
were all addressing that question from a common assumption of how the  
album itself is identified.

> If haudio is ONLY about tracks

It's not.  The model is almost entirely analogous to hCard:

hAudio is about audio.
The default type of audio is a track.
If the album and fn are the same, it's the non-default type: an album.

hCard is about contacts.
The default type of contact is an individual.
If the org and fn are the same, it's the non-default type: an  
organization.

>> This seems to be
>> supported by the examples, in which there are many more tracks than
>> albums.
>
> --- if that is the case, then we should NOT use haudio as the root
> class name to mean a collection of audio stuff

See above.  If you still think it's wrong to use hAudio for both  
album and track, please explain why you think this should differ from  
hCard's model.

> -- there seems to be two ways we COULD represent albums. #1 assuming
> all tracks are in an album and use /haudio/item/fn for just tracks
> that way we COULD have /haudio/fn and /haudio/item/fn to give an album
> name and a track name.... or #2 we could invert the relationship, and
> use /haudio/fn to be the track name an have /haudio/collection to
> associate an track to an album or podcast or something.

Or #3, we could recognize that when the audio's name is the same as  
the album's name, the audio is an album, without requiring an  
explicit statement from publishers.  This solution removes the main  
problem with both #1 and #2 above: unnecessary declaration of  
containers or items that may not even exist.

> --- right, ORG would be analigous to option #2 where you explicitly
> list the ALBUM. The downside is that if there are 2 track (like 20
> people) the (ORG or ALBUM) would have to be repeated 20 times.

Why?  HTML nesting semantics already indicate containers.  Similarly,  
hAtom doesn't repeat the feed 20 times for 20 entries.  I think the  
basic model is to follow hCard for differentiating between container  
type and item type, and follow hAtom for relating containers to items.

>> Tracks are more common, so why shouldn't we assume tracks?
>
> --- i would think so, but the examples in this email seems to suggest
> otherwise.

I think you're misreading them, possibly assuming hAudio is about  
either album or track, when it's actually about recorded audio,  
including both albums and tracks.

> I think we need a clarification of the goals.

I think much of the problem here is that the wiki proposal isn't up  
to date with email discussions.

> I'm happy to make the default assumption TRACK rather than ALBUM. Then
> i would say the original examples in this would have to be:
>
> Album with two tracks, simple example:
>
> <span class="haudio">
>    <span class="fn>Hokkaido Dream</span>
>    <span class="collection">Best Before 1984</span>
>    <span class="contributor">Crass</span>
> </span>
>
> <span class="haudio">
>    <span class="fn">Tokyo Groove</span>
>    <span class="collection">Best Before 1984</span>
>    <span class="contributor">Crass</span>
> </span>

That's pretty much exactly what everyone's agreed to, except we're  
using "album" instead of "collection."  If you think this should  
change, please explain why.

> Album with two tracks, more detailed:
>
> <span class="haudio">
>    <span class="fn>Hokkaido Dream</span>
>     <abbr class="duration" title="PT3M24S">3:24</abbr>
>    <span class="collection">Best Before 1984</span>
>    <span class="contributor">Crass</span>
> </span>
>
> <span class="haudio">
>    <span class="fn">Tokyo Groove</span>
>    <span class="collection">Best Before 1984</span>
>    <span class="contributor">Crass</span>
>     <abbr class="duration" title="PT4M46S">4:46</abbr>
> </span>

This, on the other hand, is very different.  The examples don't show  
publishers repeating album names, so the model needs to accommodate  
this.  We've been talking about something more like this:

<span class="haudio">
	<span class="album fn">Best Before 1984</span>
	<span class="contributor">Crass</span>

	<span class="item">
		<span class="fn">Hokkaido Dream</span>
		<abbr class="duration" title="PT3M24S">3:24</abbr>
	</span>

	<span class="item">
		<span class="fn">Tokyo Groove</span>
		<abbr class="duration" title="PT4M46S">4:46</abbr>
	</span>
</span>

Alternately, each class="item" could be class="item haudio", if  
necessary.  That's what we were discussing, all under the assumption  
that the relationship between tracks and albums would be determined  
by HTML containment.  Your proposal does not share this assumption,  
and I'm still not sure if that's because you see something wrong with  
it, or you just didn't understand it before.  If the former, please  
explain.  If the latter, I hope it's clear now.

> They would need to be two distinct haudio items because haudio models
> TRACKs not albums.

hAudio models audio, which includes both tracks and albums.   
Similarly, hCard models contacts, which includes both people and  
organizations.

> The duplicate data could be solved with the
> include-pattern.

It could be, but I think it's simpler to use HTML's existing  
containment semantics, as hAtom does.

--
Scott Reynen
MakeDataMakeSense.com
From brian.suda at gmail.com  Sat Oct 20 16:46:54 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Sat Oct 20 16:46:56 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <BE1F12E0-B669-40CB-B930-B26471BEC1A0@makedatamakesense.com>
References: <471A45E8.1030303@digitalbazaar.com>
	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>
	<62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>
	<21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>
	<BE1F12E0-B669-40CB-B930-B26471BEC1A0@makedatamakesense.com>
Message-ID: <21e770780710201646m45d78959t950816365e412d75@mail.gmail.com>

On 10/20/07, Scott Reynen <scott@makedatamakesense.com> wrote:
> It's not.  The model is almost entirely analogous to hCard:
>
> hAudio is about audio.
> The default type of audio is a track.
> If the album and fn are the same, it's the non-default type: an album.
>
> hCard is about contacts.
> The default type of contact is an individual.
> If the org and fn are the same, it's the non-default type: an
> organization.

--- this is ONLY because FN is required in vCard and making FN==ORG in
most PIMs set the type of card as a company not a person. I think
people are missing that and assuming that class="fn org" is making the
FN a TYPE of ORG, hence class="fn album" attempting to cast FN as
ALBUM. (the fn and org can be on completely different elements, as
long as their values are the same. That is what counts, not the fact
that they share the same class="fn org")

Sorry i completely missed the emails about saying when an ALBUM came
into existance. If that is so, then FN is NOT needed. I personally
don't like ALBUM, because then we get an enumerated list of people's
pet projects, PODCAST, ALBUM, COLLECTION, etc, but that is another
discussion.

If we are going to have a class ALBUM then we do NOT need both FN and ALBUM.

> See above.  If you still think it's wrong to use hAudio for both
> album and track, please explain why you think this should differ from
> hCard's model.

because hCard doesn't have class="vcard" for the root and class="vcard
item" again to specific all the people or orgs that it may contain. I
think i agree with you, if i understand your model of the assumption
being a track, with an explicit album name. I don't think i agree with
having nested types of the same object... a TRACK that has an album,
but actually then has multiple tracks inside it... to me that isn't
ideal.

> Or #3, we could recognize that when the audio's name is the same as
> the album's name, the audio is an album, without requiring an
> explicit statement from publishers.  This solution removes the main
> problem with both #1 and #2 above: unnecessary declaration of
> containers or items that may not even exist.

--- correct. The default is that we are talking about a TRACK (just
like in vCard we are talking about a person), BUT if the FN and ALBUM
are the same (just like FN and ORG) the object is an ALBUM/ORG. What
falls down is that now you are attempting to shove multiple
TRACKS/PEOPLE into the same ALBUM/ORG. You can't do this in vCard, so
the analogy gets weird.

vCard is ever ONLY about 1 object at a time, just like hAudio should
be about 1 object at a time, (either a track or an album). Attempting
to squeeze multiple things inside should either be out-of-scope or
looked at later, we don;t have a format, yet we are attempting
something no other microformat does.

> > --- right, ORG would be analigous to option #2 where you explicitly
> > list the ALBUM. The downside is that if there are 2 track (like 20
> > people) the (ORG or ALBUM) would have to be repeated 20 times.
>
> Why?  HTML nesting semantics already indicate containers.  Similarly,
> hAtom doesn't repeat the feed 20 times for 20 entries.

--- but hAtom isn't nesting hfeed inside itself, it has 1 root class
(hfeed) with multple henteries and each hentry does not contain itself
over and over again. We have new properties for different object
container.

> I think the
> basic model is to follow hCard for differentiating between container
> type and item type, and follow hAtom for relating containers to items.

--- sure, but if we do, then we don't need to re-use the same
root-class name of haudio to mean both a track and a generic media
container.

> That's pretty much exactly what everyone's agreed to, except we're
> using "album" instead of "collection."  If you think this should
> change, please explain why.

--- i don't really care what it is called, but if we choose ALBUM,
then all the podcasters complain, if we choose ALBUM then all the
people who release it in another format complain... just look at the
suggestions on the issues list:
http://microformats.org/wiki/audio-info-issues#Collection_Names
+1 for using ALBUM ManuSporny 09:31, 12 Sep 2007 (PDT)
+1 for using PODCAST ManuSporny 09:54, 12 Sep 2007 (PDT)
+1 for using TRACK ManuSporny 09:54, 12 Sep 2007 (PDT)
+1 for using TRACK Chris Newell 12:21, 25 Sep 2007 (GMT+1)
+1 for using CHART Chris Newell 12:21, 25 Sep 2007 (GMT+1)
+1 for using PLAYLIST Chris Newell 12:21, 25 Sep 2007 (GMT+1)
+1 for using RELEASE Michael Smethurst, 12 Sep 2007
Dublin Core uses COLLECTION:
http://dublincore.org/documents/dcmi-type-vocabulary/

we can discuss the exact name later - lets not get hung-up on that. I
think we both agree that something unique is needed if we are going to
model this similar to hCard.

>  We've been talking about something more like this:
>
> <span class="haudio">
>         <span class="album fn">Best Before 1984</span>
>         <span class="contributor">Crass</span>
>
>         <span class="item">
>                 <span class="fn">Hokkaido Dream</span>
>                 <abbr class="duration" title="PT3M24S">3:24</abbr>
>         </span>
>
>         <span class="item">
>                 <span class="fn">Tokyo Groove</span>
>                 <abbr class="duration" title="PT4M46S">4:46</abbr>
>         </span>
> </span>

--- that is fine, but i then have a few issues. To me, that is NOT
describing a TRACK by default. hAudio is now just a generic container
for MEDIA data. with some metadata and items. I gather from the next
statement that you NEED to type cast those ITEMS because your
assumption that this is by default a track, but it is now wrong
because the FN and ALBUM are present, so we are talking about an
album, but you still want multiple ITEMS inside this (what was a
track) but is now an Album. The root class of haudio on the items to
now making it be a track, so we need to re-state that these items are
tracks by default hence class="item haudio"... that sounds pretty
complicated to me and nothing like hCard or hAtom.

>  Your proposal does not share this assumption,
> and I'm still not sure if that's because you see something wrong with
> it, or you just didn't understand it before.  If the former, please
> explain.  If the latter, I hope it's clear now.

--- at first i didn't understand it, now that (i think) i do, i like
it even less.

> hAudio models audio, which includes both tracks and albums.
> Similarly, hCard models contacts, which includes both people and
> organizations.

--- hCard models 1 org or 1 person. hAudio is attempting to model 1
track or 1 album or 1 album with multiple tracks. This last part is my
hang-up, both in communication and in mark-up.

> It could be, but I think it's simpler to use HTML's existing
> containment semantics, as hAtom does.

--- probably, but hAtom doesn't reuse hFeed or hentry inside elements
of the same type.

OK, so it seems that hAudio wants to model 3 different things. The
first two seem pretty close to being solved. Just for my own sanity
let me rehash it.

<!-- This is a TRACK and ONLY a track -->
<div class="haudio">
  <span class="fn">Track 123</span>
</div>

<!-- This is a TRACK with some metadata -->
<div class="haudio">
  <span class="item">
    <span class="fn">Track 123</span>
    <abbr class="duration" title="PT3M24S">3:24</abbr>
  </span>
</div>

<!-- if haudio is TRACK by default, then there is no need to have
"item" here, right?-->
<div class="haudio">
    <span class="fn">Track 123</span>
    <abbr class="duration" title="PT3M24S">3:24</abbr>
</div>


<!-- But This is also a only TRACK? -->
<div class="haudio">
  <span class="item">
    <span class="fn">Track 123</span>
  </span>
</div>

<!-- and This too? -->
<div class="haudio">Track 123</div>


<!-- Track with album -->
<div class="haudio">
  <span class="fn">Track 123</span>
  <span class="album">Album 123</span>
</div>

<!-- hAudio is just an album -->
<div class="haudio">
  <span class="album">Album 123</span>
</div>

<!-- what is this? an album with a duration, or an un-named track in
an album with a track duration? -->
<div class="haudio">
  <span class="item">
    <span class="album">Album 123</span>
    <abbr class="duration" title="PT30M24S">30:24</abbr>
  </span>
</div>


<!-- now the part we are debating -->
<!-- hAudio is an album with lots of tracks -->
<div class="haudio">
  <span class="album">Album 123</span>
  <span class="fn">Track 123</span>
  <span class="fn">Track 456</span>
  <span class="fn">Track 789</span>
</div>

That last example is where things get abit weird depending on what you
want to do.
now we have 1 container, haudio, that we are attempting to stick
multiple ITEMS into. In hAtom, we have a root of hFeed that contains
multiple entries. What the current haudio proposal is suggesting to me
is that haudio is more like each hentry (normally just a track) but
when we want it to contain multiple things then we are going to say
hentery now is like hfeed when other hentries are inside it.

Isn't it easier to just create a root class above haudio? i know that
was discussed and dropped (that was the whole halbum) but now we have
created (what i think is a confusing mess) of nesting the same element
in side itself just to avoid making a root class. Or not assume haudio
by default is a TRACK, but instead just a container.

am i missing something or is that what has happened? This last aspect
is nothing like hCard or hAtom.

If we are going to say that an hAudio can contain multiple tracks,
then (IMHO) BY DEFAULT audio should be an empty container. Just like
hFeed is an empty container. These then get multple items put inside
them.

<div class="hfeed">entry title</div>
this isn't assumed to be an entry with a title of "entry title", but
that is exactly what is happening with
<div class="haudio">track name</div>
we have foregone the middle parts that make this an ITEM that can be
contained multuple times inside the container.

then we run into problems when we need it to represent multiple
things. hAtom doesn't have class="item hfeed" (it has hentry instead),
which is what class="item haudio" is trying doing to represent tracks.
sorry if i missed those discussions, but this just seems wrong to me.
If we want 1 haudio object with 1 album and multuple tracks, then it
should be designed like hAtom. If we want to talk about a single
hAudio object, then we can model it after hCard where it is 1 track or
1 album at a time.

-brian

-- 
brian suda
http://suda.co.uk
From martin at weborganics.co.uk  Sun Oct 21 07:08:38 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sun Oct 21 07:07:58 2007
Subject: [uf-new] Re: Microformalyze (Apology made an ass of myself)
In-Reply-To: <471A3B06.70900@digitalbazaar.com>
References: <C338F138.71C8%Michael.Smethurst@bbc.co.uk>
	<B186D899-96B6-4BB6-9AEE-294136ADF706@julianstahnke.com>
	<56957CB2-A3DE-442C-B029-100765EBE7EA@ben-ward.co.uk>
	<471383FD.7090701@digitalbazaar.com>
	<7331.80.249.57.38.1192464278.squirrel@www.gradwell.com>
	<4713A8E6.5020404@digitalbazaar.com>
	<1192495826.5054.93.camel@localhost.localdomain>
	<mPBTKYU2eFFHFwaw@pigsonthewing.org.uk>
	<1192577437.13041.41.camel@localhost.localdomain>
	<4715641B.4050408@digitalbazaar.com>
	<1192744721.24894.41.camel@localhost.localdomain>
	<4718C5C9.2070803@digitalbazaar.com>
	<1192828530.29450.65.camel@localhost.localdomain>
	<1192876741.7599.5.camel@localhost.localdomain>
	<471A3B06.70900@digitalbazaar.com>
Message-ID: <1192975718.15223.15.camel@localhost.localdomain>

On Sat, 2007-10-20 at 13:29 -0400, Manu Sporny wrote:
> Martin McEvoy wrote:
> >> Baba                               : 100.00%
> >> Flumps                             : 50.00%
> >>
> >> I KNOW these two properties do not exist in any way at WebOrganics
> >>
> >> Can you see now WHY I am concerned and moderately confused 
> >> Microformalize does not seem to be calculating the existence of these
> >> properties on a page it seems to be Just calculating if I have ticked a
> >> box or not.
> >>
> >> Am I missing something?
> > 
> > You know I am Impossibly Dense sometimes, Lets call it being
> > overworked :)
> > 
> > Sorry Manu Looking at the above now It seems I was making an ass of
> > myself again
> > 
> > Wish I was better at apologising
> 
> No problem, Martin - no need to feel that bad about it. I could have
> been much more helpful in the first reply I sent to the list regarding
> the examples and Microformalyze, so my apologies for that. :)
> 

You can be a little cryptic sometimes but only as much as I am vague :)

Something I will have to work on ;)

> Your intentions were good and that goes a long way. Plus, there has
> never been a public vetting on Microformalyze, so that was very useful
> as well. In addition, we can say that the hAudio examples have been
> rigorously defended - which only strengthens the hAudio Microformat.
> 

If you ever need something to show what Microformalize does NOT do you
can always point them at this discussion, 

> All in all, while painful, these discussions help us understand what
> we're doing in the Microformats community and how we go about doing it.
> 

+1

> That being said, I'm going to be mailing an updated proposal to the
> hAudio TRACK/ITEM debate that I think will work for everyone involved
> and will hopefully resolve the last major remaining issues for hAudio!
> 

Thanks

Martin
> -- manu
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From martin at weborganics.co.uk  Sun Oct 21 07:03:25 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sun Oct 21 07:29:51 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <21e770780710201646m45d78959t950816365e412d75@mail.gmail.com>
References: <471A45E8.1030303@digitalbazaar.com>
	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>
	<62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>
	<21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>
	<BE1F12E0-B669-40CB-B930-B26471BEC1A0@makedatamakesense.com>
	<21e770780710201646m45d78959t950816365e412d75@mail.gmail.com>
Message-ID: <1192975405.15223.9.camel@localhost.localdomain>

On Sat, 2007-10-20 at 23:46 +0000, Brian Suda wrote:
> On 10/20/07, Scott Reynen <scott@makedatamakesense.com> wrote:
> > It's not.  The model is almost entirely analogous to hCard:
> >
> > hAudio is about audio.
> > The default type of audio is a track.
> > If the album and fn are the same, it's the non-default type: an album.
> >
> > hCard is about contacts.
> > The default type of contact is an individual.
> > If the org and fn are the same, it's the non-default type: an
> > organization.
> 
> --- this is ONLY because FN is required in vCard and making FN==ORG in
> most PIMs set the type of card as a company not a person. I think
> people are missing that and assuming that class="fn org" is making the
> FN a TYPE of ORG, hence class="fn album" attempting to cast FN as
> ALBUM. (the fn and org can be on completely different elements, as
> long as their values are the same. That is what counts, not the fact
> that they share the same class="fn org")
> 
> Sorry i completely missed the emails about saying when an ALBUM came
> into existance. If that is so, then FN is NOT needed. I personally
> don't like ALBUM, because then we get an enumerated list of people's
> pet projects, PODCAST, ALBUM, COLLECTION, etc, but that is another
> discussion.
> 
> If we are going to have a class ALBUM then we do NOT need both FN and ALBUM.
> 
> > See above.  If you still think it's wrong to use hAudio for both
> > album and track, please explain why you think this should differ from
> > hCard's model.
> 
> because hCard doesn't have class="vcard" for the root and class="vcard
> item" again to specific all the people or orgs that it may contain. I
> think i agree with you, if i understand your model of the assumption
> being a track, with an explicit album name. I don't think i agree with
> having nested types of the same object... a TRACK that has an album,
> but actually then has multiple tracks inside it... to me that isn't
> ideal.
> 
> > Or #3, we could recognize that when the audio's name is the same as
> > the album's name, the audio is an album, without requiring an
> > explicit statement from publishers.  This solution removes the main
> > problem with both #1 and #2 above: unnecessary declaration of
> > containers or items that may not even exist.
> 
> --- correct. The default is that we are talking about a TRACK (just
> like in vCard we are talking about a person), BUT if the FN and ALBUM
> are the same (just like FN and ORG) the object is an ALBUM/ORG. What
> falls down is that now you are attempting to shove multiple
> TRACKS/PEOPLE into the same ALBUM/ORG. You can't do this in vCard, so
> the analogy gets weird.
> 
> vCard is ever ONLY about 1 object at a time, just like hAudio should
> be about 1 object at a time, (either a track or an album). Attempting
> to squeeze multiple things inside should either be out-of-scope or
> looked at later, we don;t have a format, yet we are attempting
> something no other microformat does.
> 
> > > --- right, ORG would be analigous to option #2 where you explicitly
> > > list the ALBUM. The downside is that if there are 2 track (like 20
> > > people) the (ORG or ALBUM) would have to be repeated 20 times.
> >
> > Why?  HTML nesting semantics already indicate containers.  Similarly,
> > hAtom doesn't repeat the feed 20 times for 20 entries.
> 
> --- but hAtom isn't nesting hfeed inside itself, it has 1 root class
> (hfeed) with multple henteries and each hentry does not contain itself
> over and over again. We have new properties for different object
> container.
> 
> > I think the
> > basic model is to follow hCard for differentiating between container
> > type and item type, and follow hAtom for relating containers to items.
> 
> --- sure, but if we do, then we don't need to re-use the same
> root-class name of haudio to mean both a track and a generic media
> container.
> 
> > That's pretty much exactly what everyone's agreed to, except we're
> > using "album" instead of "collection."  If you think this should
> > change, please explain why.
> 
> --- i don't really care what it is called, but if we choose ALBUM,
> then all the podcasters complain, if we choose ALBUM then all the
> people who release it in another format complain... just look at the
> suggestions on the issues list:
> http://microformats.org/wiki/audio-info-issues#Collection_Names
> +1 for using ALBUM ManuSporny 09:31, 12 Sep 2007 (PDT)
> +1 for using PODCAST ManuSporny 09:54, 12 Sep 2007 (PDT)
> +1 for using TRACK ManuSporny 09:54, 12 Sep 2007 (PDT)
> +1 for using TRACK Chris Newell 12:21, 25 Sep 2007 (GMT+1)
> +1 for using CHART Chris Newell 12:21, 25 Sep 2007 (GMT+1)
> +1 for using PLAYLIST Chris Newell 12:21, 25 Sep 2007 (GMT+1)
> +1 for using RELEASE Michael Smethurst, 12 Sep 2007
> Dublin Core uses COLLECTION:
> http://dublincore.org/documents/dcmi-type-vocabulary/
> 
> we can discuss the exact name later - lets not get hung-up on that. I
> think we both agree that something unique is needed if we are going to
> model this similar to hCard.
> 
> >  We've been talking about something more like this:
> >
> > <span class="haudio">
> >         <span class="album fn">Best Before 1984</span>
> >         <span class="contributor">Crass</span>
> >
> >         <span class="item">
> >                 <span class="fn">Hokkaido Dream</span>
> >                 <abbr class="duration" title="PT3M24S">3:24</abbr>
> >         </span>
> >
> >         <span class="item">
> >                 <span class="fn">Tokyo Groove</span>
> >                 <abbr class="duration" title="PT4M46S">4:46</abbr>
> >         </span>
> > </span>
> 
> --- that is fine, but i then have a few issues. To me, that is NOT
> describing a TRACK by default. hAudio is now just a generic container
> for MEDIA data. with some metadata and items. I gather from the next
> statement that you NEED to type cast those ITEMS because your
> assumption that this is by default a track, but it is now wrong
> because the FN and ALBUM are present, so we are talking about an
> album, but you still want multiple ITEMS inside this (what was a
> track) but is now an Album. The root class of haudio on the items to
> now making it be a track, so we need to re-state that these items are
> tracks by default hence class="item haudio"... that sounds pretty
> complicated to me and nothing like hCard or hAtom.
> 
> >  Your proposal does not share this assumption,
> > and I'm still not sure if that's because you see something wrong with
> > it, or you just didn't understand it before.  If the former, please
> > explain.  If the latter, I hope it's clear now.
> 
> --- at first i didn't understand it, now that (i think) i do, i like
> it even less.
> 
> > hAudio models audio, which includes both tracks and albums.
> > Similarly, hCard models contacts, which includes both people and
> > organizations.
> 
> --- hCard models 1 org or 1 person. hAudio is attempting to model 1
> track or 1 album or 1 album with multiple tracks. This last part is my
> hang-up, both in communication and in mark-up.
> 
> > It could be, but I think it's simpler to use HTML's existing
> > containment semantics, as hAtom does.
> 
> --- probably, but hAtom doesn't reuse hFeed or hentry inside elements
> of the same type.
> 
> OK, so it seems that hAudio wants to model 3 different things. The
> first two seem pretty close to being solved. Just for my own sanity
> let me rehash it.
> 
> <!-- This is a TRACK and ONLY a track -->
> <div class="haudio">
>   <span class="fn">Track 123</span>
> </div>
> 
> <!-- This is a TRACK with some metadata -->
> <div class="haudio">
>   <span class="item">
>     <span class="fn">Track 123</span>
>     <abbr class="duration" title="PT3M24S">3:24</abbr>
>   </span>
> </div>
> 
> <!-- if haudio is TRACK by default, then there is no need to have
> "item" here, right?-->
> <div class="haudio">
>     <span class="fn">Track 123</span>
>     <abbr class="duration" title="PT3M24S">3:24</abbr>
> </div>
> 
> 
> <!-- But This is also a only TRACK? -->
> <div class="haudio">
>   <span class="item">
>     <span class="fn">Track 123</span>
>   </span>
> </div>
> 
> <!-- and This too? -->
> <div class="haudio">Track 123</div>
> 
> 
> <!-- Track with album -->
> <div class="haudio">
>   <span class="fn">Track 123</span>
>   <span class="album">Album 123</span>
> </div>
> 
> <!-- hAudio is just an album -->
> <div class="haudio">
>   <span class="album">Album 123</span>
> </div>
> 
> <!-- what is this? an album with a duration, or an un-named track in
> an album with a track duration? -->
> <div class="haudio">
>   <span class="item">
>     <span class="album">Album 123</span>
>     <abbr class="duration" title="PT30M24S">30:24</abbr>
>   </span>
> </div>
> 
> 
> <!-- now the part we are debating -->
> <!-- hAudio is an album with lots of tracks -->
> <div class="haudio">
>   <span class="album">Album 123</span>
>   <span class="fn">Track 123</span>
>   <span class="fn">Track 456</span>
>   <span class="fn">Track 789</span>
> </div>
> 
> That last example is where things get abit weird depending on what you
> want to do.
> now we have 1 container, haudio, that we are attempting to stick
> multiple ITEMS into. In hAtom, we have a root of hFeed that contains
> multiple entries. What the current haudio proposal is suggesting to me
> is that haudio is more like each hentry (normally just a track) but
> when we want it to contain multiple things then we are going to say
> hentery now is like hfeed when other hentries are inside it.
> 
> Isn't it easier to just create a root class above haudio? i know that
> was discussed and dropped (that was the whole halbum) but now we have
> created (what i think is a confusing mess) of nesting the same element
> in side itself just to avoid making a root class. Or not assume haudio
> by default is a TRACK, but instead just a container.
> 
> am i missing something or is that what has happened? This last aspect
> is nothing like hCard or hAtom.

I think haudio is becoming more like a hReview?

Could We reuse Item :type and Item :info ?

<div class="haudio">
<div class="item">
  <span class="type">Album</span>: 
    <span class="fn">Best Before 1984</span>
    By: <span class="contributor">Crass</span>
</div>
      <div class="item">
           <span class="fn">Nagasaki Nightmare</span>
           <span class="duration">4:46</span>
     </div>
      <div class="item">
           <span class="fn">Big A, Little A</span>
           <span class="duration">6:13</span>
     </div>
</div>

Would give publishers the flexibility of describing their own collection
types and contents.


Thanks

Martin
> 
> If we are going to say that an hAudio can contain multiple tracks,
> then (IMHO) BY DEFAULT audio should be an empty container. Just like
> hFeed is an empty container. These then get multple items put inside
> them.
> 
> <div class="hfeed">entry title</div>
> this isn't assumed to be an entry with a title of "entry title", but
> that is exactly what is happening with
> <div class="haudio">track name</div>
> we have foregone the middle parts that make this an ITEM that can be
> contained multuple times inside the container.
> 
> then we run into problems when we need it to represent multiple
> things. hAtom doesn't have class="item hfeed" (it has hentry instead),
> which is what class="item haudio" is trying doing to represent tracks.
> sorry if i missed those discussions, but this just seems wrong to me.
> If we want 1 haudio object with 1 album and multuple tracks, then it
> should be designed like hAtom. If we want to talk about a single
> hAudio object, then we can model it after hCard where it is 1 track or
> 1 album at a time.
> 
> -brian
> 

From davidjanes at blogmatrix.com  Sun Oct 21 07:54:05 2007
From: davidjanes at blogmatrix.com (David Janes)
Date: Sun Oct 21 07:54:08 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <1192975405.15223.9.camel@localhost.localdomain>
References: <471A45E8.1030303@digitalbazaar.com>
	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>
	<62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>
	<21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>
	<BE1F12E0-B669-40CB-B930-B26471BEC1A0@makedatamakesense.com>
	<21e770780710201646m45d78959t950816365e412d75@mail.gmail.com>
	<1192975405.15223.9.camel@localhost.localdomain>
Message-ID: <21e523c20710210754v3b023fa2m6eefd8da3a723536@mail.gmail.com>

On 10/21/07, Martin McEvoy <martin@weborganics.co.uk> wrote:

> Could We reuse Item :type and Item :info ?
>
> <div class="haudio">
> <div class="item">
>   <span class="type">Album</span>:
>     <span class="fn">Best Before 1984</span>
>     By: <span class="contributor">Crass</span>
> </div>
>       <div class="item">
>            <span class="fn">Nagasaki Nightmare</span>
>            <span class="duration">4:46</span>
>      </div>
>       <div class="item">
>            <span class="fn">Big A, Little A</span>
>            <span class="duration">6:13</span>
>      </div>
> </div>
>
> Would give publishers the flexibility of describing their own collection
> types and contents.

The downside being that you're now making content providers explicitly
put a string (i.e. the type) that they may think is implicitly obvious
and unnecessary.

Regards, etc...

-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
From davidjanes at blogmatrix.com  Sun Oct 21 07:59:36 2007
From: davidjanes at blogmatrix.com (David Janes)
Date: Sun Oct 21 07:59:38 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <21e523c20710210754v3b023fa2m6eefd8da3a723536@mail.gmail.com>
References: <471A45E8.1030303@digitalbazaar.com>
	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>
	<62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>
	<21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>
	<BE1F12E0-B669-40CB-B930-B26471BEC1A0@makedatamakesense.com>
	<21e770780710201646m45d78959t950816365e412d75@mail.gmail.com>
	<1192975405.15223.9.camel@localhost.localdomain>
	<21e523c20710210754v3b023fa2m6eefd8da3a723536@mail.gmail.com>
Message-ID: <21e523c20710210759j6a705730mf44c3bb9ff5c4630@mail.gmail.com>

On 10/21/07, David Janes <davidjanes@blogmatrix.com> wrote:
> On 10/21/07, Martin McEvoy <martin@weborganics.co.uk> wrote:
>
> > Could We reuse Item :type and Item :info ?
> >
> > <div class="haudio">
> > <div class="item">
> >   <span class="type">Album</span>:
> >     <span class="fn">Best Before 1984</span>
> >     By: <span class="contributor">Crass</span>
> > </div>
> >       <div class="item">
> >            <span class="fn">Nagasaki Nightmare</span>
> >            <span class="duration">4:46</span>
> >      </div>
> >       <div class="item">
> >            <span class="fn">Big A, Little A</span>
> >            <span class="duration">6:13</span>
> >      </div>
> > </div>
> >
> > Would give publishers the flexibility of describing their own collection
> > types and contents.
>
> The downside being that you're now making content providers explicitly
> put a string (i.e. the type) that they may think is implicitly obvious
> and unnecessary.
>

And I should also note that parameterizing the role of an embedded
microformat using addition class names is reasonably well established:
i.e. "author vcard" in hAtom

Regards, etc...

-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
From martin at weborganics.co.uk  Sun Oct 21 08:25:57 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sun Oct 21 08:25:14 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <21e523c20710210759j6a705730mf44c3bb9ff5c4630@mail.gmail.com>
References: <471A45E8.1030303@digitalbazaar.com>
	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>
	<62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>
	<21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>
	<BE1F12E0-B669-40CB-B930-B26471BEC1A0@makedatamakesense.com>
	<21e770780710201646m45d78959t950816365e412d75@mail.gmail.com>
	<1192975405.15223.9.camel@localhost.localdomain>
	<21e523c20710210754v3b023fa2m6eefd8da3a723536@mail.gmail.com>
	<21e523c20710210759j6a705730mf44c3bb9ff5c4630@mail.gmail.com>
Message-ID: <1192980357.15608.10.camel@localhost.localdomain>

On Sun, 2007-10-21 at 09:59 -0500, David Janes wrote:
> On 10/21/07, David Janes <davidjanes@blogmatrix.com> wrote:
> > On 10/21/07, Martin McEvoy <martin@weborganics.co.uk> wrote:
> >
> > > Could We reuse Item :type and Item :info ?
> > >
> > > <div class="haudio">
> > > <div class="item">
> > >   <span class="type">Album</span>:
> > >     <span class="fn">Best Before 1984</span>
> > >     By: <span class="contributor">Crass</span>
> > > </div>
> > >       <div class="item">
> > >            <span class="fn">Nagasaki Nightmare</span>
> > >            <span class="duration">4:46</span>
> > >      </div>
> > >       <div class="item">
> > >            <span class="fn">Big A, Little A</span>
> > >            <span class="duration">6:13</span>
> > >      </div>
> > > </div>
> > >
> > > Would give publishers the flexibility of describing their own collection
> > > types and contents.
> >
> > The downside being that you're now making content providers explicitly
> > put a string (i.e. the type) that they may think is implicitly obvious
> > and unnecessary.
> >

Maybe true but lets talk about it :)

> 
> And I should also note that parameterizing the role of an embedded
> microformat using addition class names is reasonably well established:
> i.e. "author vcard" in hAtom
> 
> Regards, etc...

Could It be done  Like this?

<div class="haudio">
<div class="item">
    <span class="type" title="Release">
        <span class="fn">Best Before 1984</span>
    </span>
    By: <span class="contributor">Crass</span>
</div>
      <div class="item">
           <span class="fn">Nagasaki Nightmare</span>
           <span class="duration">4:46</span>
     </div>
      <div class="item">
           <span class="fn">Big A, Little A</span>
           <span class="duration">6:13</span>
     </div>
</div>

type titles can be Album, Release, Podcast, Chart, Toplist, even Episode
and Track  but would this be too restrictive? I think It may be a more
flexible approach than having class names for all these properties.


Thanks

Martin


> 

From msporny at digitalbazaar.com  Sun Oct 21 09:01:52 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Oct 21 09:01:57 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <21e770780710201646m45d78959t950816365e412d75@mail.gmail.com>
References: <471A45E8.1030303@digitalbazaar.com>	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>	<62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>	<21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>	<BE1F12E0-B669-40CB-B930-B26471BEC1A0@makedatamakesense.com>
	<21e770780710201646m45d78959t950816365e412d75@mail.gmail.com>
Message-ID: <471B77F0.4000305@digitalbazaar.com>

Brian, it sounds like you have several misconceptions about hAudio, some
of them are from recent changes that we have discussed on the list, some
of them are from discussions that we have had long ago. I am going
attempt to address the ones that are most poignant and explain why we
are where we are right now.

First, let me state that hAudio is about "audio recordings", of which
tracks and albums are a subset. I think you were under the impression
that hAudio was primarily about Albums and containing tracks. It is not.

While we have borrowed some design elements from hReview and hCard, we
should not get confused between the various Microformats and hAudio. We
should draw parallels to hReview and hCard when it is applicable, but to
say that hAudio is EXACTLY like hReview or hCard is a mistake. It is not.

At this point, we are not discussing what properties should be a part of
the hAudio specification. It seems that everybody is more or less agreed
on what properties should be a part of the specification. We are discussing:

- Naming those properties (specifically, tracks in audio albums)
- The structure of hAudio as a container.

Specifically, we are talking about tracks in albums, and what should
denote the track container in hAudio.

Brian Suda wrote:
> If that is so, then FN is NOT needed.

FN is needed because the examples show that both album and song name are
listed on a page next to each other. Such as when a blogger talks about
a song that is a part of an album. This is done quite often on the
hundreds of music blogs[1] on the 'net. For a specific example of this
happening, check out Scissorkick[2], which usually lists songs and
albums together.

Additionally, ID3v1 and just about every other audio metadata tagging
standard has the ability to specify the album name and the song name. We
have plenty of examples[3] and metadata formats[4] that support this
approach.

> I personally
> don't like ALBUM, because then we get an enumerated list of people's
> pet projects, PODCAST, ALBUM, COLLECTION, etc, but that is another
> discussion.

We have too many examples to ignore ALBUM. We also have too many
examples to ignore FN.

We are not discussing PODCASTs or other pet projects because we don't
have enough data yet. However, the latest proposal would be able to
markup both podcasts and collections.

>> See above.  If you still think it's wrong to use hAudio for both
>> album and track, please explain why you think this should differ from
>> hCard's model.
> 
> because hCard doesn't have class="vcard" for the root and class="vcard
> item" again to specific all the people or orgs that it may contain. I
> think i agree with you, if i understand your model of the assumption
> being a track, with an explicit album name. I don't think i agree with
> having nested types of the same object... a TRACK that has an album,
> but actually then has multiple tracks inside it... to me that isn't
> ideal.

I think there is a disconnect between what was proposed and how you
interpreted it. We are not saying that you can have "a track that has an
album with multiple tracks inside of it" - that is an abuse of the
hAudio spec. Just like somebody specifying a review having to do with 6
items that are completely different from one another.

>> Or #3, we could recognize that when the audio's name is the same as
>> the album's name, the audio is an album, without requiring an
>> explicit statement from publishers.  This solution removes the main
>> problem with both #1 and #2 above: unnecessary declaration of
>> containers or items that may not even exist.

You are assuming that the current proposal requires you to unnecessarily
declare containers. It does not.

> vCard is ever ONLY about 1 object at a time, just like hAudio should
> be about 1 object at a time, (either a track or an album). Attempting
> to squeeze multiple things inside should either be out-of-scope or
> looked at later, we don;t have a format, yet we are attempting
> something no other microformat does.

We are doing this because this structure is inherent in almost every
audio example collected to date. hAudio is about audio recordings, audio
recordings have parts that people specify, be it tracks, sections,
movements, etc. hAudio is not hCard.

We are already at "later" - we have solved the "atomic recording"
problem for hAudio. We are now attempting to solve the "recording with
multiple parts" problem for hAudio.

Why is attempting to do something that no other microformat does a bad
thing? It is true that no other Microformat does
sections/collections/parts. I would argue that is so because no other
Microformat has collections as an inherent part of it's structure...
hAudio does.

>> That's pretty much exactly what everyone's agreed to, except we're
>> using "album" instead of "collection."  If you think this should
>> change, please explain why.
> 
> --- i don't really care what it is called, but if we choose ALBUM,
> then all the podcasters complain, if we choose ALBUM then all the
> people who release it in another format complain... 

Then we will address the problem when people start complaining. We have
more than enough examples to back up creating a collection property
called ALBUM. The same cannot be said for PODCAST, PLAYLIST, or TOPLIST.

The reason we are using ALBUM is because "type" is never specified in
most of the audio info examples collected to date. We needed a way of
specifying the name of an album and the type of an album. The choice in
name came solely from the requirements that the examples dictated.

It might help if we use examples of what we are talking about:

> <!-- This is a TRACK and ONLY a track -->
> <div class="haudio">
>   <span class="fn">Track 123</span>
> </div>

The above could also be written like so:

   <span class="haudio">Track 123</span>

This describes a single audio recording called "Track 123".

> <!-- This is a TRACK with some metadata -->
> <div class="haudio">
>   <span class="item">
>     <span class="fn">Track 123</span>
>     <abbr class="duration" title="PT3M24S">3:24</abbr>
>   </span>
> </div>

The above, while it would parse correctly, is not advised markup. It
should have been written like so:

   <div class="haudio">
      <span class="fn">Track 123</span>
      <abbr class="duration" title="PT3M24S">3:24</abbr>
   </div>

This is a single audio recording called "Track 123" with a duration of 3
minutes and 24 seconds.

> <!-- if haudio is TRACK by default, then there is no need to have
> "item" here, right?-->
> <div class="haudio">
>     <span class="fn">Track 123</span>
>     <abbr class="duration" title="PT3M24S">3:24</abbr>
> </div>

Correct... nobody said that ITEM was required for a single audio recording.

> <!-- But This is also a only TRACK? -->
> <div class="haudio">
>   <span class="item">
>     <span class="fn">Track 123</span>
>   </span>
> </div>

Again, this would parse correctly, but would be incorrect markup and is
not advised. The above is a single audio recording named "Track 123".
The above is like writing:

   <div class="vcard">
      <span class="item">
         <span class="fn">Brian Suda</span>
      </span>
   </div>

The above would parse correctly, but it's just weird and hopefully
nobody would use it in that way.

> <!-- and This too? -->
> <div class="haudio">Track 123</div>

Yes, that is correct.

> <!-- Track with album -->
> <div class="haudio">
>   <span class="fn">Track 123</span>
>   <span class="album">Album 123</span>
> </div>

Yes, correct.

> <!-- hAudio is just an album -->
> <div class="haudio">
>   <span class="album">Album 123</span>
> </div>

Yes, correct.

> <!-- what is this? an album with a duration, or an un-named track in
> an album with a track duration? -->
> <div class="haudio">
>   <span class="item">
>     <span class="album">Album 123</span>
>     <abbr class="duration" title="PT30M24S">30:24</abbr>
>   </span>
> </div>

That is incorrect markup. The parser would identify that as an album
called "Album 123" with a duration of 30 minutes and 24 seconds.

> <!-- now the part we are debating -->
> <!-- hAudio is an album with lots of tracks -->
> <div class="haudio">
>   <span class="album">Album 123</span>
>   <span class="fn">Track 123</span>
>   <span class="fn">Track 456</span>
>   <span class="fn">Track 789</span>
> </div>

We're not debating this... the markup is clear (although, the multiple
FNs are a bit strange). The above is a single audio recording named
"Track 123" that is found on an album named "Album 123".

> Isn't it easier to just create a root class above haudio? i know that
> was discussed and dropped (that was the whole halbum) but now we have
> created (what i think is a confusing mess) of nesting the same element
> in side itself just to avoid making a root class. Or not assume haudio
> by default is a TRACK, but instead just a container.

hAudio by default IS a single audio recording! I think this is your
primary misconception... isn't it?

Please give markup examples of where you think this falls down. It was
very helpful to see how your mental model of hAudio diverged from mine.

-- manu

[1] http://hypem.com/
[2] http://www.scissorkick.com/
[3] http://microformats.org/wiki/audio-info-examples
[4] http://microformats.org/wiki/audio-info-formats
From msporny at digitalbazaar.com  Sun Oct 21 09:06:05 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Oct 21 09:06:08 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <21e523c20710210754v3b023fa2m6eefd8da3a723536@mail.gmail.com>
References: <471A45E8.1030303@digitalbazaar.com>	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>	<62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>	<21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>	<BE1F12E0-B669-40CB-B930-B26471BEC1A0@makedatamakesense.com>	<21e770780710201646m45d78959t950816365e412d75@mail.gmail.com>	<1192975405.15223.9.camel@localhost.localdomain>
	<21e523c20710210754v3b023fa2m6eefd8da3a723536@mail.gmail.com>
Message-ID: <471B78ED.9040406@digitalbazaar.com>

David Janes wrote:
> The downside being that you're now making content providers explicitly
> put a string (i.e. the type) that they may think is implicitly obvious
> and unnecessary.

Not to mention that most publishers aren't doing that now... and the
ones that do, don't mark it up in any sort of standardized way. Just
take a look at the audio info examples[1].

-- manu

[1] http://microformats.org/wiki/audio-info-examples

From msporny at digitalbazaar.com  Sun Oct 21 09:30:27 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Oct 21 09:30:31 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <1192980357.15608.10.camel@localhost.localdomain>
References: <471A45E8.1030303@digitalbazaar.com>	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>	<62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>	<21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>	<BE1F12E0-B669-40CB-B930-B26471BEC1A0@makedatamakesense.com>	<21e770780710201646m45d78959t950816365e412d75@mail.gmail.com>	<1192975405.15223.9.camel@localhost.localdomain>	<21e523c20710210754v3b023fa2m6eefd8da3a723536@mail.gmail.com>	<21e523c20710210759j6a705730mf44c3bb9ff5c4630@mail.gmail.com>
	<1192980357.15608.10.camel@localhost.localdomain>
Message-ID: <471B7EA3.8040904@digitalbazaar.com>

Martin McEvoy wrote:
> Could It be done  Like this?
> 
> <div class="haudio">
> <div class="item">
>     <span class="type" title="Release">
>         <span class="fn">Best Before 1984</span>
>     </span>
>     By: <span class="contributor">Crass</span>
> </div>
>       <div class="item">
>            <span class="fn">Nagasaki Nightmare</span>
>            <span class="duration">4:46</span>
>      </div>
>       <div class="item">
>            <span class="fn">Big A, Little A</span>
>            <span class="duration">6:13</span>
>      </div>
> </div>
> 
> type titles can be Album, Release, Podcast, Chart, Toplist, even Episode
> and Track  but would this be too restrictive? I think It may be a more
> flexible approach than having class names for all these properties.

While I am a fan of doing it this way, it goes against one of the
primary Microformat principles: "No hidden data!"

This is one of the main things that separate the Microformats approach
from the RDFa approach. hAudio in RDFa[1] would mark up the previous
example like so:

   <div about="#best-before-1984" instanceof="hmedia:Album">
      <span property="dc:title">Best Before 1984</span>
      By: <span property="dc:contributor">Crass</span>
   </div>

   ...

   <span about="#best-before-1984" rel="hmedia:contains"
         resource="#nagasaki-nightmare">
      <div about="#nagasaki-nightmare" instanceof="hmedia:Recording">
         <span property="dc:title">Nagasaki Nightmare</span>
         <span property="hmedia:duration" content="PT4M46S">4:46</span>
      </div>
   </span>
   ...

   <span about="#best-before-1984" rel="hmedia:contains"
         resource="#big-a-little-a">
      <div about="#big-a-little-a" instanceof="hmedia:Recording">
         <span property="dc:title">Big A, Little A</span>
         <span property="dc:duration" content="PT6M13S">6:13</span>
      </div>
   </span>

Note that with the RDFa approach:

 - The type is explicitly stated using @instanceof.
 - There is slightly more hidden data with the RDFa approach.
 - RDFa is more verbose.
 - There is no need for nesting in RDFa to express containment.
 - Items can be related to one another without nesting in RDFa.

So, while it is a good argument, Martin... it is an argument for RDFa,
not an argument for the Microformats community.

The closest we can get to specifying type in the Microformats community
is by either:

a) explicitly stating it, which we can't do with hAudio, or
b) implicitly stating it, which is why we have ALBUM

-- manu

[1] http://wiki.digitalbazaar.com/en/HAudio_RDFa
From brian.suda at gmail.com  Sun Oct 21 09:54:04 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Sun Oct 21 09:54:08 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <471B77F0.4000305@digitalbazaar.com>
References: <471A45E8.1030303@digitalbazaar.com>
	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>
	<62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>
	<21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>
	<BE1F12E0-B669-40CB-B930-B26471BEC1A0@makedatamakesense.com>
	<21e770780710201646m45d78959t950816365e412d75@mail.gmail.com>
	<471B77F0.4000305@digitalbazaar.com>
Message-ID: <21e770780710210954p832f1b9j8b03e5e6e8687007@mail.gmail.com>

On 10/21/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> - Naming those properties (specifically, tracks in audio albums)
> - The structure of hAudio as a container.
>
> Specifically, we are talking about tracks in albums, and what should
> denote the track container in hAudio.

--- i agree with these two points, but what i disagree with this the
design of this "container" so far i have heard it called a container
about tracks and albums and i have heard it called "track" by default.
>From the descriptions i am hearing, the property "haudio" is 2
different thing. IMHO it should only be 1, a generic container for
audio.

> Brian Suda wrote:
> > If that is so, then FN is NOT needed.
>
> FN is needed because the examples show that both album and song name are
> listed on a page next to each other. Such as when a blogger talks about
> a song that is a part of an album.

--- (we have lost the original HTML example in all the replies) If we
are using a unique property for the string that is the ALBUM name
class="album" then it is redundany to have BOTH class="fn album", FN
should be used for 1 or the other for the name of the string, be it
the string for the album name, or the string for the track name. Since
tracks seems to me more common, class="fn" for track names... and
class="albums" for album names, not class="fn" for tracks and
class="fn album" for album names.

The reason you think you NEED class="fn album" is because of your
"short-cuts". If you have ONLY one way to represent the hAudio
structure (which you don't there are several) then you do not need
class="album"

//haudio/fn == album name
//haudio/item/fn == track name

But instead haudio is attempting
//haudio == track name
//haudio/fn == track name
//haudio/item/fn == track name
//haudio/album+fn == album name (i don't understand this, it could
just be //haudio//album)

But for now, if we impose a SINGLE structure to mark-up haudio (which
i think is best, it helps adoption, examples and explaining) then we
don't even need ALBUM.

> > I personally
> > don't like ALBUM, because then we get an enumerated list of people's
> > pet projects, PODCAST, ALBUM, COLLECTION, etc, but that is another
> > discussion.
>
> We have too many examples to ignore ALBUM. We also have too many
> examples to ignore FN.

--- i think that might have been a mis-communication. I disliked the
property name ALBUM, i am not debating the merit of its existance.

> We are already at "later" - we have solved the "atomic recording"
> problem for hAudio. We are now attempting to solve the "recording with
> multiple parts" problem for hAudio.

--- then this is two different things. With hAtom we solved the atom
ENTRY, then put it in a FEED. If we have solved the atomic RECORDING,
then we are putting it into a COLLECTION (or ALBUM) this is a level
above hAudio. The original examples where making (what i think is a
poor use) of class="item haudio" in a class="haudio", but i see what
you are attempting.

> Why is attempting to do something that no other microformat does a bad
> thing?

--- it isn't, but the concept of NESTING isn't new, hAtom does this.
What is new and bad is nesting the same property inside itself. Which
is what this whole class='item haudio" is doing.

> It is true that no other Microformat does
> sections/collections/parts.

--- i think you proved your point right there, you have 3 distinct
levels. But in your mark-up you are saying haudio/item+haudio (that is
NOT three distinct things)

> It might help if we use examples of what we are talking about:
>
> > <!-- This is a TRACK and ONLY a track -->
> > <div class="haudio">
> >   <span class="fn">Track 123</span>
> > </div>
>
> The above could also be written like so:
>
>    <span class="haudio">Track 123</span>

--- i disagree with this idea. Firstly, it is a premature
optimization. Secondly, haudio is no longer a generic container, it is
now a TRACK. Which goes against what you said at the begining of your
email.

"First, let me state that hAudio is about "audio recordings", of which
tracks and albums are a subset."

There is no SUBSET here, it is ONLY hAudio.

A subset would be //haudio/SUBSET HERE (item in all the examples)/value

> > <!-- if haudio is TRACK by default, then there is no need to have
> > "item" here, right?-->
> > <div class="haudio">
> >     <span class="fn">Track 123</span>
> >     <abbr class="duration" title="PT3M24S">3:24</abbr>
> > </div>
>
> Correct... nobody said that ITEM was required for a single audio recording.

--- fine, but if this is the ATOMIC structure for a Audio Object, then
we need a class ABOVE haudio to contain multiple hAudios, much the
same way hEntry is contained within an hFeed. OR always have ITEM so
haudio stays the generic container and contains SUBSETS of multiple
other things (namely tracks)

> > <!-- what is this? an album with a duration, or an un-named track in
> > an album with a track duration? -->
> > <div class="haudio">
> >   <span class="item">
> >     <span class="album">Album 123</span>
> >     <abbr class="duration" title="PT30M24S">30:24</abbr>
> >   </span>
> > </div>
>
> That is incorrect markup. The parser would identify that as an album
> called "Album 123" with a duration of 30 minutes and 24 seconds.

--- how is that incorrect? what if that is exactly what i wanted?
hAudio is about tracks and Albums correct? then if that is metadata
about an haudio item and it is only a album, right? or is it the fact
that it is in an ITEM that causes the problem?

> hAudio by default IS a single audio recording! I think this is your
> primary misconception... isn't it?

--- no, i agree completely that hAudio is a SINGLE audio recording. My
issue is mainly with your original example which no longer models
hAudio as a SINGLE audio recording:

Album with two tracks, more detailed:
<span class="haudio">
  <span class="fn album">Best Before 1984</span>
  <span class="contributor">Crass</span>
  <span class="item haudio">
     <span class="fn">Hokkaido Dream</span>
     <abbr class="duration" title="PT3M24S">3:24</abbr>
  </span>
  <span class="item haudio">
     <span class="fn">Tokyo Groove</span>
     <abbr class="duration" title="PT4M46S">4:46</abbr>
  </span>
</span>

The class="item haudio" is a poor design choice.

> Please give markup examples of where you think this falls down. It was
> very helpful to see how your mental model of hAudio diverged from mine.

The above is an haudio which is a generic container. We are now
nesting generic contains inside itself. There is no need. We can drop
the class="item haudio" to simply class="item". Then we are the exact
model as hAtom. hFeed==hAudio, hEntry==item then we can add metadata
about the container (be it album, duration, etc as optional), then it
can have multiple tracks (optional) as items.

Which brings us back to the my more verbose default TRACK of:
<span class="haudio">
    <span class="item">
        <span class="fn">Hokkaido Dream</span>
    </span>
</span>
This (for now until we discuss optimizations) is how you would need to
write JUST a track. If you wanted to write JUST an album it would be:

<span class="haudio">
   <span class="album">Best Before 1984</span>
</span>

No optimizations YET.

hAudio is NOT by default a track or an album, it is a container. Then
we do NOT have to do any sort of nesting of itself and complicated
things.

Other than that, nothing changes. It is just cutting out the
short-forms (for now) and making the overall mark-up easier by not
having to nest weird structures inside itself. It also makes haudio a
generic container NOT a track by default. I think haudio should be 1
thing and 1 thing only. How and what we decide that too be impacts the
rest of our choices.

-- brian

-- 
brian suda
http://suda.co.uk
From scott at makedatamakesense.com  Sun Oct 21 10:08:51 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sun Oct 21 10:08:53 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <471B77F0.4000305@digitalbazaar.com>
References: <471A45E8.1030303@digitalbazaar.com>	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>	<62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>	<21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>	<BE1F12E0-B669-40CB-B930-B26471BEC1A0@makedatamakesense.com>
	<21e770780710201646m45d78959t950816365e412d75@mail.gmail.com>
	<471B77F0.4000305@digitalbazaar.com>
Message-ID: <57B33070-BF9A-4DDE-B470-686FC234B3AB@makedatamakesense.com>

On Oct 21, 2007, at 10:01 AM, Manu Sporny wrote:

> First, let me state that hAudio is about "audio recordings", of which
> tracks and albums are a subset.

This is a crucial point.  As long as you continue to treat the root  
class meaning as something more specific than "audio recording," it  
won't make much sense.

> While we have borrowed some design elements from hReview and hCard, we
> should not get confused between the various Microformats and hAudio.

Indeed, I used other microformats as references for basic design  
structures, not to imply that anything about hAudio should affect  
those.  That was apparently more confusing than helpful.  The fact  
that it may make no sense to nest one hFeed inside another is  
completely irrelevant to whether or not it makes sense to nest one  
audio recording within another.  The publishing examples suggest  
audio nesting makes sense, and any opposition to this model should be  
based on the real-world examples, not on hypothetical applications of  
the model to concepts that are completely out of scope.

> Brian Suda wrote:
>> If that is so, then FN is NOT needed.
>
> FN is needed because the examples show that both album and song  
> name are
> listed on a page next to each other. Such as when a blogger talks  
> about
> a song that is a part of an album. This is done quite often on the
> hundreds of music blogs[1] on the 'net. For a specific example of this
> happening, check out Scissorkick[2], which usually lists songs and
> albums together.
>
> Additionally, ID3v1 and just about every other audio metadata tagging
> standard has the ability to specify the album name and the song  
> name. We
> have plenty of examples[3] and metadata formats[4] that support this
> approach.

We also have plenty of examples in which one audio element ("album")  
is mentioned only once and treated as a container for several other  
audio elements ("tracks").  Both methods of organizing this  
information are common and the model needs to address both, as it  
currently does.  It would be nice if we could simply use one or the  
other, but we shouldn't do that at the expense of not covering a  
significant portion of the examples.  If you look at most popular  
applications for collecting audio (e.g. iTunes), you'll find both  
organization methods are present.  In some views, tracks are listed  
with album names as a property, in others, albums are listed as  
containers for track names.  Luckily HTML allows us to easily put one  
element inside another, so this duality of relationships between  
track and album isn't really complicated, unless of course you  
approach it assuming a simpler model than the examples actually imply.

> We are doing this because this structure is inherent in almost every
> audio example collected to date. hAudio is about audio recordings,  
> audio
> recordings have parts that people specify, be it tracks, sections,
> movements, etc. hAudio is not hCard.

At the risk of further confusing matters, hCard actually nests one  
person within another using the "agent" property, so it's not like  
this is a completely new concept.  But hAudio is not a general  
proposal that anything should be nestable inside anything else.  It's  
very specific to audio inside audio, and that nesting-inside-same- 
type is very specific to the nature of audio.

> Why is attempting to do something that no other microformat does a bad
> thing?

Following precedent is important, but hAudio is very much doing  
that.  The only things hAudio is attempting that are new are  
completely audio-specific, so there is of course no precedent in  
other microformats.  We can take the *general* concept of nesting  
from other microformats (or more basically from HTML itself), but we  
can't take anything about the *specifics* of nesting audio within  
audio from them, nor does it make any sense to take that audio- 
specific proposal and apply it more generally.

> It is true that no other Microformat does
> sections/collections/parts.

I disagree.  XOXO does that.  hAtom does that.  hCalendar does that.   
No other microformat does that with audio within audio, of course,  
but that's an implied schema found in the audio publishing examples.   
We're not just making stuff up.

--
Scott Reynen
MakeDataMakeSense.com


From martin at weborganics.co.uk  Sun Oct 21 11:11:49 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Sun Oct 21 11:11:08 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <471B7EA3.8040904@digitalbazaar.com>
References: <471A45E8.1030303@digitalbazaar.com>
	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>
	<62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>
	<21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>
	<BE1F12E0-B669-40CB-B930-B26471BEC1A0@makedatamakesense.com>
	<21e770780710201646m45d78959t950816365e412d75@mail.gmail.com>
	<1192975405.15223.9.camel@localhost.localdomain>
	<21e523c20710210754v3b023fa2m6eefd8da3a723536@mail.gmail.com>
	<21e523c20710210759j6a705730mf44c3bb9ff5c4630@mail.gmail.com>
	<1192980357.15608.10.camel@localhost.localdomain>
	<471B7EA3.8040904@digitalbazaar.com>
Message-ID: <1192990309.16781.12.camel@localhost.localdomain>

On Sun, 2007-10-21 at 12:30 -0400, Manu Sporny wrote:
> Martin McEvoy wrote:
> > Could It be done  Like this?
> > 
> > <div class="haudio">
> > <div class="item">
> >     <span class="type" title="Release">
> >         <span class="fn">Best Before 1984</span>
> >     </span>
> >     By: <span class="contributor">Crass</span>
> > </div>
> >       <div class="item">
> >            <span class="fn">Nagasaki Nightmare</span>
> >            <span class="duration">4:46</span>
> >      </div>
> >       <div class="item">
> >            <span class="fn">Big A, Little A</span>
> >            <span class="duration">6:13</span>
> >      </div>
> > </div>
> > 
> > type titles can be Album, Release, Podcast, Chart, Toplist, even Episode
> > and Track  but would this be too restrictive? I think It may be a more
> > flexible approach than having class names for all these properties.
> 
> While I am a fan of doing it this way, it goes against one of the
> primary Microformat principles: "No hidden data!"
> 
> This is one of the main things that separate the Microformats approach
> from the RDFa approach. hAudio in RDFa[1] would mark up the previous
> example like so:
> 
>    <div about="#best-before-1984" instanceof="hmedia:Album">
>       <span property="dc:title">Best Before 1984</span>
>       By: <span property="dc:contributor">Crass</span>
>    </div>
> 
>    ...
> 
>    <span about="#best-before-1984" rel="hmedia:contains"
>          resource="#nagasaki-nightmare">
>       <div about="#nagasaki-nightmare" instanceof="hmedia:Recording">
>          <span property="dc:title">Nagasaki Nightmare</span>
>          <span property="hmedia:duration" content="PT4M46S">4:46</span>
>       </div>
>    </span>
>    ...
> 
>    <span about="#best-before-1984" rel="hmedia:contains"
>          resource="#big-a-little-a">
>       <div about="#big-a-little-a" instanceof="hmedia:Recording">
>          <span property="dc:title">Big A, Little A</span>
>          <span property="dc:duration" content="PT6M13S">6:13</span>
>       </div>
>    </span>
> 
> Note that with the RDFa approach:
> 
>  - The type is explicitly stated using @instanceof.
>  - There is slightly more hidden data with the RDFa approach.
>  - RDFa is more verbose.
>  - There is no need for nesting in RDFa to express containment.
>  - Items can be related to one another without nesting in RDFa.
> 
> So, while it is a good argument, Martin... it is an argument for RDFa,
> not an argument for the Microformats community.
> 
> The closest we can get to specifying type in the Microformats community
> is by either:
> 
> a) explicitly stating it, which we can't do with hAudio, or
> b) implicitly stating it, which is why we have ALBUM

I thought that the @title area is for giving hints to people? visible
data? and intended to be implicitly stated, not directly expressed. 
Explicitly was how I stated type In an earlier suggestion <span
class="type">Album</span>: which cant be done in hAudio I'm told so...?

Thanks

Martin

> 
> -- manu
> 
> [1] http://wiki.digitalbazaar.com/en/HAudio_RDFa
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From scott at makedatamakesense.com  Sun Oct 21 11:20:20 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sun Oct 21 11:20:22 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <21e770780710210954p832f1b9j8b03e5e6e8687007@mail.gmail.com>
References: <471A45E8.1030303@digitalbazaar.com>
	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>
	<62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>
	<21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>
	<BE1F12E0-B669-40CB-B930-B26471BEC1A0@makedatamakesense.com>
	<21e770780710201646m45d78959t950816365e412d75@mail.gmail.com>
	<471B77F0.4000305@digitalbazaar.com>
	<21e770780710210954p832f1b9j8b03e5e6e8687007@mail.gmail.com>
Message-ID: <D429DC66-0B02-4BFF-9EC4-912B9E60B769@makedatamakesense.com>

On Oct 21, 2007, at 10:54 AM, Brian Suda wrote:

> --- i agree with these two points, but what i disagree with this the
> design of this "container" so far i have heard it called a container
> about tracks and albums and i have heard it called "track" by default.

You may have heard that, but I believe no one said it.  I said hAudio  
is considered a track by default, but I did not say that hAudio  
*containers* are tracks by default.  hAudio containers are by  
definition not tracks, they're not the default, and anything specific  
to tracks does not apply to them.  But most of hAudio is not specific  
to tracks, it's generally applicable to all audio.

> --- (we have lost the original HTML example in all the replies) If we
> are using a unique property for the string that is the ALBUM name
> class="album" then it is redundany to have BOTH class="fn album"

FN does *not* mean album name.  It means *audio* name.  Whether or  
not that's the same as the album name determines whether or not we're  
talking about an album.  To paraphrase directly from the hCard spec:

If the "FN" and "ALBUM" properties have the exact same value  
(typically because they are set on the same element, e.g. class="fn  
album"), then the hAudio represents audio information for an album,  
and should be treated as such.

> FN
> should be used for 1 or the other for the name of the string, be it
> the string for the album name, or the string for the track name. Since
> tracks seems to me more common, class="fn" for track names... and
> class="albums" for album names, not class="fn" for tracks and
> class="fn album" for album names.

This would be a redefinition of either FN or HAUDIO.  Per the wiki  
[1], FN is "The name of the object."  The object here is hAudio,  
which means *audio*, not track, and not album.

> The reason you think you NEED class="fn album" is because of your
> "short-cuts".

False.  It's because the *meaning* of FN and ALBUM are not the same.   
They may at times refer to the same content, but that doesn't make  
them mean the same thing any more than FN and ORG mean the same thing  
merely because they often co-exist.

> If you have ONLY one way to represent the hAudio
> structure (which you don't there are several) then you do not need
> class="album"

Real world examples demonstrate multiple ways of representing audio.

> //haudio/fn == album name
> //haudio/item/fn == track name

That only works if we redefine HAUDIO to mean *album*.

> But instead haudio is attempting
> //haudio == track name

False.  HAUDIO means *audio*, not track.  You're treating a proposed  
syntax optimization as a new semantic structure, which is a mistake  
of yours, not a fault of the model.

> //haudio/fn == track name

False.  HAUDIO means *audio*, not track, so FN here means "audio  
name."  Calling that a "track name" may work in imprecise discussion,  
but we should be more precise here.

> //haudio/album+fn == album name (i don't understand this, it could
> just be //haudio//album)

False.  ALBUM means "album title."  FN (in HAUDIO) means "audio  
title."  That those two may in some cases overlap does not give them  
the sort of shared meaning you've suggested here, which would be  
completely at odds with the semantics of HTML's class attribute.

> But for now, if we impose a SINGLE structure to mark-up haudio (which
> i think is best, it helps adoption, examples and explaining) then we
> don't even need ALBUM.

The real world examples suggest otherwise.

> --- then this is two different things. With hAtom we solved the atom
> ENTRY, then put it in a FEED.

That made sense in hAtom.  It does not make sense here, because  
unlike feeds, audio has the same structure as both container or  
contained.  The publishing examples make this clear, and I think it  
would help if you looked more at those and questioned a few of your  
assumptions where they contradict the examples.

> If we have solved the atomic RECORDING,
> then we are putting it into a COLLECTION (or ALBUM) this is a level
> above hAudio.

False.  A collection of audio recordings is itself an audio  
recording.  This is the implied schema derived from the examples.   
You appear to be imposing your own assumed schema on this without  
regard to the examples.  That's not how the microformats process works.

> the concept of NESTING isn't new, hAtom does this.
> What is new and bad is nesting the same property inside itself.

False.  Again, hCard does that.  That doesn't make sense in general,  
but it *does* make sense for audio.  You've only criticized it in  
contexts that have nothing to do with audio, and are thus irrelevant  
to the proposal.  Do you disagree with the specific assertion that  
audio is made up of smaller segments of audio?

>  if this is the ATOMIC structure for a Audio Object, then
> we need a class ABOVE haudio to contain multiple hAudios, much the
> same way hEntry is contained within an hFeed.

Correct.  But it turns out this container is itself audio, so we can  
re-use hAudio here.  It seems to me you've assumed based on your  
previous experience in other unrelated contexts that a container  
could *never* be the same type as the contained items.  I believe  
this assumption is false, specifically in the context of audio, and I  
challenge you to back up your assumption with some sort of rationale  
rather than just repeatedly stating it as if it were fact.

>>> <!-- what is this? an album with a duration, or an un-named track in
>>> an album with a track duration? -->
>>> <div class="haudio">
>>>   <span class="item">
>>>     <span class="album">Album 123</span>
>>>     <abbr class="duration" title="PT30M24S">30:24</abbr>
>>>   </span>
>>> </div>
>>
>> That is incorrect markup. The parser would identify that as an album
>> called "Album 123" with a duration of 30 minutes and 24 seconds.
>
> --- how is that incorrect? what if that is exactly what i wanted?

If you don't even know what it means, how could it possibly be  
exactly what you wanted?  It is not the microformats process to start  
with markup and then try to figure out what it means.  We start with  
publishing examples, and figure out how to structure them most easily  
for publishers.

> hAudio is about tracks and Albums correct?

False.  hAudio is about audio.

> --- no, i agree completely that hAudio is a SINGLE audio recording. My
> issue is mainly with your original example which no longer models
> hAudio as a SINGLE audio recording:
>
> Album with two tracks, more detailed:

That an album is not a single audio recording is your *opinion*, not  
a fact.  The examples have suggested this opinion is wrong.

> Which brings us back to the my more verbose default TRACK of:
> <span class="haudio">
>     <span class="item">
>         <span class="fn">Hokkaido Dream</span>
>     </span>
> </span>
> This (for now until we discuss optimizations) is how you would need to
> write JUST a track.

For now we're using a schema that everyone agreed to before you  
entered the discussion.  You're welcome to try to question that  
schema and explain why you think a different schema would be better,  
based on real world examples.  But you can't just declare a different  
schema.  That's not how the microformats process works.

--
Scott Reynen
MakeDataMakeSense.com


From msporny at digitalbazaar.com  Sun Oct 21 12:04:09 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Oct 21 12:04:14 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <21e770780710210954p832f1b9j8b03e5e6e8687007@mail.gmail.com>
References: <471A45E8.1030303@digitalbazaar.com>	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>	<62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>	<21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>	<BE1F12E0-B669-40CB-B930-B26471BEC1A0@makedatamakesense.com>	<21e770780710201646m45d78959t950816365e412d75@mail.gmail.com>	<471B77F0.4000305@digitalbazaar.com>
	<21e770780710210954p832f1b9j8b03e5e6e8687007@mail.gmail.com>
Message-ID: <471BA2A9.1090901@digitalbazaar.com>

Brian Suda wrote:
> On 10/21/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
>> - Naming those properties (specifically, tracks in audio albums)
>> - The structure of hAudio as a container.
>>
>> Specifically, we are talking about tracks in albums, and what should
>> denote the track container in hAudio.
> 
> --- i agree with these two points

I think we agree on, or can compromise towards, much more than I thought
at the beginning of this conversation. Let me state what hAudio is, just
so that we're clear:

hAudio is used to mark up an audio recording. An audio recording is a
re-playable series of sounds that are made by something.

That is the definition of hAudio, it is not any more specific than that.
What gives hAudio its specificity is the attributes that go inside hAudio.

For example, if nothing goes inside hAudio other than FN, it is the name
of the audio recording:

   <div class="haudio">
      <span class="fn">A Sound Recording</span>
   </div>

If somebody wants to be more specific and mark up an album, they can do
the following (leaving out FN - using your proposal, Brian):

   <div class="haudio">
      <span class="album">An Audio Album</span>
   </div>

If somebody wants to be even more specific and mark up an audio
recording that is a part of an album, they can do this:

   <div class="haudio">
      <span class="fn">A Sound Recording</span> found in
      <span class="album">An Audio Album</span>
   </div>

All three examples above are audio recordings. An album can have
sections, but played from beginning to end, it is still an audio
recording. It should also be noted that we are required to provide at
least the functionality shown above - the examples are very clear on this.

In addition to the above, we are also required to be able to list albums
and tracks. I think the following markup is what you would prefer, right
Brian?

   <div class="haudio">
      <span class="fn">A Sound Recording</span> found in
      <span class="album">An Audio Album</span>
      <div class="item">
         <span class="fn">Track 1</span>
         <abbr class="duration" title="PT2M32S">2:32</abbr>
      </div>
      <div class="item">
         <span class="fn">Track 2</span>
         <abbr class="duration" title="PT3M11S">3:11</abbr>
      </div>
   </div>

> But instead haudio is attempting
> //haudio == track name

We should probably stop using "track name" - it seems to be causing
confusion. Use "audio recording" instead. We aren't as specific as a
track using that markup.... all we know is that it is an audio
recording... we don't know if it is an album and we don't know if it is
a track, nor do we know if it is a podcast. We don't know anything other
than it is an audio recording.

> //haudio/fn == track name

We still only know the name of the audio recording, nothing else. It is
definitely not a track at this point.

> //haudio/item/fn == track name

Again, we don't know that it is a track unless ALBUM is also specified
in that structure. Only then can we assume that the audio recording
listed under ITEM is a track. If ALBUM is not specified, it is just a
part of the audio recording. For example:

   <div class="haudio">
      <span class="fn">A Sound Recording</span> -
      <div class="item">
         <span class="fn">A Part</span>
      </div>
      <div class="item">
         <span class="fn">Another Part</span>
      </div>
   </div>

"A Part" and "Another Part" are just two sections (which are audio
recordings) of the audio recording "A Sound Recording".

> //haudio/album+fn == album name (i don't understand this, it could
> just be //haudio//album)

Yes it could. I had proposed that approach during the last two weeks. It
didn't go over well, check the archives... I think Scott had issues with
it. Scott?

> But for now, if we impose a SINGLE structure to mark-up haudio (which
> i think is best, it helps adoption, examples and explaining) then we
> don't even need ALBUM.

We would be going against the examples if we were to do that.

>> Why is attempting to do something that no other microformat does a bad
>> thing?
> 
> --- it isn't, but the concept of NESTING isn't new, hAtom does this.
> What is new and bad is nesting the same property inside itself. Which
> is what this whole class='item haudio" is doing.

Why is nesting the same property inside itself a bad thing?

>> It is true that no other Microformat does
>> sections/collections/parts.
> 
> --- i think you proved your point right there, you have 3 distinct
> levels. But in your mark-up you are saying haudio/item+haudio (that is
> NOT three distinct things)

Wait... I proved my point, or I proved your point?! :) I'm so confused.
I didn't mean to imply that sections/collections/parts were three
different levels - they are three different words that mean the same
thing in hAudio. Does it help if I re-state the problem like so:

We are attempting to create two concepts:

* a single, non-descript recording (audio recording)
* a single, descriptive recording with multiple sections/parts (still an
  audio recording, but specifically an album containing tracks)

> "First, let me state that hAudio is about "audio recordings", of which
> tracks and albums are a subset."
> 
> There is no SUBSET here, it is ONLY hAudio.

Hmm... my definition of subset seems to be different than your
definition of subset. There is only hAudio, yes. hAudio is an audio
recording. An album is a type of audio recording. A track is a type of
audio recording. An album with multiple tracks is a type of audio recording.

In other words - we're talking about an audio recording.

> --- fine, but if this is the ATOMIC structure for a Audio Object, then
> we need a class ABOVE haudio to contain multiple hAudios, much the
> same way hEntry is contained within an hFeed. OR always have ITEM so
> haudio stays the generic container and contains SUBSETS of multiple
> other things (namely tracks)

Why do we need this? Why can't the contents of hAudio define the type of
audio recording that it is?

>>> <!-- what is this? an album with a duration, or an un-named track in
>>> an album with a track duration? -->
>>> <div class="haudio">
>>>   <span class="item">
>>>     <span class="album">Album 123</span>
>>>     <abbr class="duration" title="PT30M24S">30:24</abbr>
>>>   </span>
>>> </div>
>> That is incorrect markup. The parser would identify that as an album
>> called "Album 123" with a duration of 30 minutes and 24 seconds.
> 
> --- how is that incorrect? what if that is exactly what i wanted?
> hAudio is about tracks and Albums correct? then if that is metadata
> about an haudio item and it is only a album, right? or is it the fact
> that it is in an ITEM that causes the problem?

ITEM causes the issue. You wouldn't need it - it is superfluous. I
shouldn't have used the word "incorrect", what I meant was
"superfluous". What were you trying to do with the markup above?

>> hAudio by default IS a single audio recording! I think this is your
>> primary misconception... isn't it?
> 
> --- no, i agree completely that hAudio is a SINGLE audio recording. My
> issue is mainly with your original example which no longer models
> hAudio as a SINGLE audio recording:
> 
> Album with two tracks, more detailed:
> <span class="haudio">
>   <span class="fn album">Best Before 1984</span>
>   <span class="contributor">Crass</span>
>   <span class="item haudio">
>      <span class="fn">Hokkaido Dream</span>
>      <abbr class="duration" title="PT3M24S">3:24</abbr>
>   </span>
>   <span class="item haudio">
>      <span class="fn">Tokyo Groove</span>
>      <abbr class="duration" title="PT4M46S">4:46</abbr>
>   </span>
> </span>
> 
> The class="item haudio" is a poor design choice.

Then we can use item... although, I think Scott has something to say
about that. I agree with Scott's take on it.

> hAudio is NOT by default a track or an album, it is a container. 

I disagree. hAudio by default is an audio recording... nothing more.

> Then
> we do NOT have to do any sort of nesting of itself and complicated
> things.

Why is this viewed as complicated, and nesting hCard in hReview not seen
as complicated? See Scott's comments...

-- manu

From brian.suda at gmail.com  Sun Oct 21 13:05:40 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Sun Oct 21 13:05:44 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <471BA2A9.1090901@digitalbazaar.com>
References: <471A45E8.1030303@digitalbazaar.com>
	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>
	<62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>
	<21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>
	<BE1F12E0-B669-40CB-B930-B26471BEC1A0@makedatamakesense.com>
	<21e770780710201646m45d78959t950816365e412d75@mail.gmail.com>
	<471B77F0.4000305@digitalbazaar.com>
	<21e770780710210954p832f1b9j8b03e5e6e8687007@mail.gmail.com>
	<471BA2A9.1090901@digitalbazaar.com>
Message-ID: <21e770780710211305u2361bff3r558d51b1f000ddfc@mail.gmail.com>

We are replying to alot at once, so lets break it up, and get down to
only the sticking points.

On 10/21/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> That is the definition of hAudio, it is not any more specific than that.
> What gives hAudio its specificity is the attributes that go inside hAudio.

--- ok, i can agree with this as an idea, and i think we can move to a
better way to mark this up. Below looks more like what i had in mind.

> For example, if nothing goes inside hAudio other than FN, it is the name
> of the audio recording:
>
>    <div class="haudio">
>       <span class="fn">A Sound Recording</span>
>    </div>
>
> If somebody wants to be more specific and mark up an album, they can do
> the following (leaving out FN - using your proposal, Brian):
>
>    <div class="haudio">
>       <span class="album">An Audio Album</span>
>    </div>

--- so far i agree. I think part of the issue was that //haudio/fn is
JUST a string to represent the string not a track title. I can agree
with that. I think the two examples above make sense to me. I would
also press for requiring ATLEAST an FN or ALBUM, not <span
class="haudio">A string</span>. We can discuss this in a later
itteration as an optimization.

> If somebody wants to be even more specific and mark up an audio
> recording that is a part of an album, they can do this:
>
>    <div class="haudio">
>       <span class="fn">A Sound Recording</span> found in
>       <span class="album">An Audio Album</span>
>    </div>

--- yes, that is fine. FN could be your display-name in something like
Operator, but Album is the name of the title of the album. If you
WANTED these could be the same class="fn album", but to me that
doesn't make any semantic compound. Just that the display name happens
to be the same string as the album.

> All three examples above are audio recordings. An album can have
> sections, but played from beginning to end, it is still an audio
> recording. It should also be noted that we are required to provide at
> least the functionality shown above - the examples are very clear on this.

--- i agree with the previous. I don't think there is much arguments
there. The tricky  (IMHO) things happens when we start "nesting".

> In addition to the above, we are also required to be able to list albums
> and tracks. I think the following markup is what you would prefer, right
> Brian?
>
>    <div class="haudio">
>       <span class="fn">A Sound Recording</span> found in
>       <span class="album">An Audio Album</span>
>       <div class="item">
>          <span class="fn">Track 1</span>
>          <abbr class="duration" title="PT2M32S">2:32</abbr>
>       </div>
>       <div class="item">
>          <span class="fn">Track 2</span>
>          <abbr class="duration" title="PT3M11S">3:11</abbr>
>       </div>
>    </div>

--- correct. To me this makes the most sense. Each "track" has
individual metadata bound by class="item", things outside of that are
assumed to be part of the audio object in general. So far this isn't
really nesting. If we look at hAtom, you can have rel-tag inside a
entry but also a feed, that really isn't nesting, just the ability to
have properies inside and outside of the item.

But as i understand, the ITEM could recursively be more audio-objects.

> > But instead haudio is attempting
> > //haudio == track name
>
> We should probably stop using "track name" - it seems to be causing
> confusion. Use "audio recording" instead. We aren't as specific as a
> track using that markup.... all we know is that it is an audio
> recording... we don't know if it is an album and we don't know if it is
> a track, nor do we know if it is a podcast. We don't know anything other
> than it is an audio recording.

--- i agree, i have been under the assumption that it would have been
a TRACK name, but you are right it should be re-defined as just a
"string" that describes the audio object, which is optional.

> > //haudio/fn == track name
>
> We still only know the name of the audio recording, nothing else. It is
> definitely not a track at this point.

--- ok, i can agree with this. So we do NOT know this is a TRACK, just
an audio object with a title of some sorts?

Once we all get on the same page here, we can discuss the rest of the message.

-brian

-- 
brian suda
http://suda.co.uk
From msporny at digitalbazaar.com  Sun Oct 21 13:48:46 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Oct 21 13:48:50 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <21e770780710211305u2361bff3r558d51b1f000ddfc@mail.gmail.com>
References: <471A45E8.1030303@digitalbazaar.com>	<21e770780710201218q68ac7b46ha7742887d1531764@mail.gmail.com>	<62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>	<21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>	<BE1F12E0-B669-40CB-B930-B26471BEC1A0@makedatamakesense.com>	<21e770780710201646m45d78959t950816365e412d75@mail.gmail.com>	<471B77F0.4000305@digitalbazaar.com>	<21e770780710210954p832f1b9j8b03e5e6e8687007@mail.gmail.com>	<471BA2A9.1090901@digitalbazaar.com>
	<21e770780710211305u2361bff3r558d51b1f000ddfc@mail.gmail.com>
Message-ID: <471BBB2E.6080601@digitalbazaar.com>

Brian Suda wrote:
> I would
> also press for requiring ATLEAST an FN or ALBUM, not <span
> class="haudio">A string</span>. We can discuss this in a later
> itteration as an optimization.

That's fine... we can avoid talking about that for now since it will
simplify the discussion. I recognize it as an optimization in your
model. It is not an optimization in the "item haudio" approach, but
we'll get there eventually.

The main reason that was in there was to ease the burden on publishers.

>> If somebody wants to be even more specific and mark up an audio
>> recording that is a part of an album, they can do this:
>>
>>    <div class="haudio">
>>       <span class="fn">A Sound Recording</span> found in
>>       <span class="album">An Audio Album</span>
>>    </div>
> 
> --- yes, that is fine. FN could be your display-name in something like
> Operator, but Album is the name of the title of the album. If you
> WANTED these could be the same class="fn album", but to me that
> doesn't make any semantic compound. Just that the display name happens
> to be the same string as the album.

Just to be crystal clear, I think we agree... with one clarification. FN
is not "display name", FN is the "formatted name" of the audio
recording. "fn album" doesn't make a semantic compound, I don't think
anybody was saying that it did. Let's not say "display name" as it will
lead to confusion.

FN is the formatted name of the audio recording.

Here are the rules we defined earlier this month, which have been
updated to match the discussions over the past two weeks:

# If only FN is specified, then the hAudio is a general audio recording.
# If only ALBUM is specified, then the hAudio is an album.
# If both ALBUM and FN is specified, then the hAudio is a song/track
that is part of an album.
# If ALBUM and one or more ITEMs are specified, the hAudio is an album
containing tracks. Each track is assumed to be an hAudio, unless
specified otherwise. None of the track properties should implicitly be
added to the containing hAudio. In other words, the parser shouldn't
parse the contents of the ITEM hAudio into the higher-level, non-track
hAudio object.

> But as i understand, the ITEM could recursively be more audio-objects.

Yes, in the "item haudio" proposal it can. It is assumed that item can
contain anything that hAudio can contain, including more items.

>>> But instead haudio is attempting
>>> //haudio == track name
>> We should probably stop using "track name" - it seems to be causing
>> confusion. Use "audio recording" instead. We aren't as specific as a
>> track using that markup.... all we know is that it is an audio
>> recording... we don't know if it is an album and we don't know if it is
>> a track, nor do we know if it is a podcast. We don't know anything other
>> than it is an audio recording.
> 
> --- i agree, i have been under the assumption that it would have been
> a TRACK name, but you are right it should be re-defined as just a
> "string" that describes the audio object, which is optional.

Again, to be crystal clear - FN or ALBUM is required, it is not
optional. If you can't name what you are talking about, you can't talk
about it. This is very specific to hAudio - people refer to audio
recordings by name... the examples prove that, thus it is not optional.

>>> //haudio/fn == track name
>> We still only know the name of the audio recording, nothing else. It is
>> definitely not a track at this point.
> 
> --- ok, i can agree with this. So we do NOT know this is a TRACK, just
> an audio object with a title of some sorts?

Yes, that is correct.

If you don't disagree with any of the statements above, please explain
why you believe nesting to be a bad design choice. It seems like that is
the big disagreement, here.

-- manu

From brian.suda at gmail.com  Sun Oct 21 14:51:25 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Sun Oct 21 14:51:27 2007
Subject: [uf-new] hAudio ITEM/TRACK debate resolution
In-Reply-To: <471BBB2E.6080601@digitalbazaar.com>
References: <471A45E8.1030303@digitalbazaar.com>
	<62E191ED-4885-4176-BDA6-A402F51FF5B2@makedatamakesense.com>
	<21e770780710201403s3062d9e3v4cfa59f958fc4253@mail.gmail.com>
	<BE1F12E0-B669-40CB-B930-B26471BEC1A0@makedatamakesense.com>
	<21e770780710201646m45d78959t950816365e412d75@mail.gmail.com>
	<471B77F0.4000305@digitalbazaar.com>
	<21e770780710210954p832f1b9j8b03e5e6e8687007@mail.gmail.com>
	<471BA2A9.1090901@digitalbazaar.com>
	<21e770780710211305u2361bff3r558d51b1f000ddfc@mail.gmail.com>
	<471BBB2E.6080601@digitalbazaar.com>
Message-ID: <21e770780710211451y13928a25o9306de989cbbd12b@mail.gmail.com>

On 10/21/07, Manu Sporny <msporny@digitalbazaar.com> wrote:
> FN is the formatted name of the audio recording.

--- that"s fine. I agree.

> Here are the rules we defined earlier this month, which have been
> updated to match the discussions over the past two weeks:
> ...
> # If ALBUM and one or more ITEMs are specified, the hAudio is an album
> containing tracks. Each track is assumed to be an hAudio, unless
> specified otherwise. None of the track properties should implicitly be
> added to the containing hAudio. In other words, the parser shouldn't
> parse the contents of the ITEM hAudio into the higher-level, non-track
> hAudio object.

--- this is fine. I know why we have stated this. It is to prevent
something like
//haudio/item/duration being applied to just the //haudio/duration or
//haudio/item/fn mixing with //haudio/fn

I agree with this, no issues here.

> > But as i understand, the ITEM could recursively be more audio-objects.
>
> Yes, in the "item haudio" proposal it can. It is assumed that item can
> contain anything that hAudio can contain, including more items.

--- ok, this is i think were i need to go back and read some things. I
don't disagree here, but think that there must be a better way to
represent this rather than infinite nesting of haudios. Then you could
re-declare the album to be different with each instance. Like i said,
i'll try to go back and see why this is.

> If you don't disagree with any of the statements above, please explain
> why you believe nesting to be a bad design choice. It seems like that is
> the big disagreement, here.

--- i don't disagree with anything but the infinite nesting of haudio
items. There have been alot of different people answering the same
questions differently. Thanks for your patience. Things are much
clearer and now that we agree on the basics and aren't "talking past"
each other, we can try to work out what is left.

-brian

-- 
brian suda
http://suda.co.uk
From pault at dessci.com  Thu Oct 25 09:23:21 2007
From: pault at dessci.com (Paul Topping)
Date: Thu Oct 25 09:23:25 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
Message-ID: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci>

Hi,

I'm trying to determine whether microformats is the right venue for
developing a standard math representation within HTML.

Back in '98, many of us involved with the W3C's MathML standard had
hopes of it being widely supported within most browsers in a few years.
That has sort of happened. MathML is supported natively within Firefox
but users experience font problems and it only works if pages are XHMTL,
rather than HTML. My company's free MathPlayer plugin makes MathML work
in Internet Explorer. MathML support is still missing from Safari,
Opera, and other browsers. People interested in publishing math on the
web still find serving up pages as XHTML challenging (getting the MIME
type right, etc.). Some websites, blogs, and wikis convert TeX or LaTeX
to images on the server to handle equations in content. Quite frankly,
the space is a mess.

Regardless of whether the math is represented using MathML, TeX, LaTeX,
or some other notation, it is important to expose the mathematical
structure behind the equation to the client in order to support
accessibility (ie, allow screen readers to speak the math) and
interoperability (eg, allow users to copy equations from pages into
Mathematica, MS Word docs, MathType, or new pages). What is needed is a
consistent way to associate an underlying math representation with its
visual representation regardless of whether it is a GIF or PNG image or
MathML formatted by the browser (or a browser plugin).

This seems like a job for a microformat but I must admit that I have
limited knowledge of the microformat philosophy. On one hand,
microformats embed semantic representations in HTML in a practical but
rigorous way. On the other hand, in most (all?) microformats the
representation is visible in the browser. In the kind of representation
I'm imagining, the user won't actually see the actual MathML or TeX code
in the browser window.

Thoughts? Is microformats the right place for this kind of thing?

Paul Topping
Design Science, Inc.
www.dessci.com

From scott at makedatamakesense.com  Thu Oct 25 15:11:28 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Thu Oct 25 15:11:35 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
In-Reply-To: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci>
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci>
Message-ID: <6FCC7A43-F782-487B-91A4-7A8566858814@makedatamakesense.com>

On Oct 25, 2007, at 10:23 AM, Paul Topping wrote:

> I'm trying to determine whether microformats is the right venue for
> developing a standard math representation within HTML.

> Thoughts? Is microformats the right place for this kind of thing?

I don't know enough about math publishing to answer that question,  
but I would encourage you to try to answer it for yourself by  
familiarizing yourself with microformats.  This is the first step of  
the microformats process:

http://microformats.org/wiki/process

That experience should give you a useful basis with which to evaluate  
the potential for a math microformat.  You may already be aware of  
the ongoing discussion of including MathML in HTML 5, but if not,  
that's another avenue you may want to explore.

--
Scott Reynen
MakeDataMakeSense.com


From pault at dessci.com  Thu Oct 25 15:39:30 2007
From: pault at dessci.com (Paul Topping)
Date: Thu Oct 25 15:39:33 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci>
	<6FCC7A43-F782-487B-91A4-7A8566858814@makedatamakesense.com>
Message-ID: <D1EFB337111B674B8F1BE155B01C6DD6025CFC75@franklin.corp.dessci>

Actually, I think I am following the "process". The very first paragraph
says, 

"Start the discussion before you start creating any pages on the wiki."

Let the discussion begin ;-)

I'm aware of the effort to support MathML in HTML5 but this effort seems
unlikely to bear fruit. Besides, I'm looking to create something that
will work in "plain old HTML" which, as I understand it, is part of the
microformat philosophy. As I stated, MathML was originally intended to
be implemented in browsers but the actuality leaves something to be
desired. With HTML5, I would simply be waiting for yet another thing to
be implemented in browsers. Exactly what I want to avoid.

Paul

> -----Original Message-----
> From: microformats-new-bounces@microformats.org 
> [mailto:microformats-new-bounces@microformats.org] On Behalf 
> Of Scott Reynen
> Sent: Thursday, October 25, 2007 3:11 PM
> To: For discussion of new microformats.
> Subject: Re: [uf-new] an equation/MathML/TeX microformat?
> 
> On Oct 25, 2007, at 10:23 AM, Paul Topping wrote:
> 
> > I'm trying to determine whether microformats is the right venue for
> > developing a standard math representation within HTML.
> 
> > Thoughts? Is microformats the right place for this kind of thing?
> 
> I don't know enough about math publishing to answer that question,  
> but I would encourage you to try to answer it for yourself by  
> familiarizing yourself with microformats.  This is the first step of  
> the microformats process:
> 
> http://microformats.org/wiki/process
> 
> That experience should give you a useful basis with which to 
> evaluate  
> the potential for a math microformat.  You may already be aware of  
> the ongoing discussion of including MathML in HTML 5, but if not,  
> that's another avenue you may want to explore.
> 
> --
> Scott Reynen
> MakeDataMakeSense.com
> 
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
> 

From paul_wilkins at xtra.co.nz  Thu Oct 25 20:16:31 2007
From: paul_wilkins at xtra.co.nz (paul_wilkins@xtra.co.nz)
Date: Thu Oct 25 20:16:36 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
Message-ID: <640030.9481.qm@web96003.mail.aue.yahoo.com>

From: Paul Topping <pault@dessci.com>
> To: For discussion of new microformats. <microformats-new@microformats.org>
> Sent: Friday, 26 October, 2007 11:39:30 AM
> Subject: RE: [uf-new] an equation/MathML/TeX microformat?
> 
> "Start the discussion before you start creating any pages on the wiki."
> 
> Let the discussion begin ;-)

Why do you want an equation microformat?
hCard solved the problem of copying contact details to your address book.

What problem will an equation microformat solve?
Can it be solved already with the existing MathML and other formats?


-- 
Paul Wilkins




From hollym at dls.net  Thu Oct 25 20:23:37 2007
From: hollym at dls.net (holly)
Date: Thu Oct 25 20:23:29 2007
Subject: [uf-new] Recipe: Additional Recipe Examples.
Message-ID: <47215DB9.9020307@dls.net>

I was reading over the archives and noticed a request wrt additional 
recipe examples.

I may have a few additional examples to add and also a possible other 
sub-section for examples, but would like to run that by this list first.


Currently, the recipe-examples page [1] has:

3 Recipes Examples
    3.1 Individuals
    3.2 Services

===

possible next subsection - applications, widget, software?

I bring this up because one or more of these applications I came across 
may import a variety of recipes from other sources and then display 
these recipes in its own format.  Or would these types of application 
recipe outputs fit under Services? [services examples so far seem to be 
recipe sites or large collections]

At any rate, it may be a good idea to see how these applications render 
recipes from various sources or what formats the applications use.

In the meantime, I will add a few more examples and wait for some ideas 
about the recipe applications/software item.

holly

[1] http://microformats.org/wiki/recipe-examples

From pault at dessci.com  Thu Oct 25 20:45:13 2007
From: pault at dessci.com (Paul Topping)
Date: Thu Oct 25 20:45:19 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
References: <640030.9481.qm@web96003.mail.aue.yahoo.com>
Message-ID: <D1EFB337111B674B8F1BE155B01C6DD6025CFCB3@franklin.corp.dessci>

MathML and TeX are fine as formats but what I'm looking for is a way to
associate them with an equation image within HTML. Just as other
microformats create invisible-to-the-user structure containing text that
is visible to the user, I want to create invisible-to-the-user structure
containing an equation image. The invisible-to-the-user structure in
this case would contain the MathML and/or TeX language representing the
equation. This way, one gets an equation image which is visible in all
browsers but backed with useful equation structure.

This would be useful in a number of ways but here's two:

1) Accessibility of math to people with vision problems and/or learning
disabilities is enabled by converting the MathML to speech or to
braille. This technology is already available in my company's MathPlayer
plugin for IE and it works with popular Windows screen readers. TeX can
also be handled by first converting it to MathML.

2) Other math and scientific software can work directly with equations
if the representation is rich enough. Obviously, an equation image won't
work but MathML or TeX will. Embedding the MathML or TeX with the
equation image in the HTML page will enable one to copy the equation to
the clipboard and then into apps such as Mathematica, Maple, or
MathType. The latest version of MathType includes a feature like this
that allows the user to copy equations out of the many Wikipedia pages
that contain equations. Luckily, Wikipedia exposes the TeX
representation of the equations which enables this feature to work.
Unfortunately, this is done in an ad hoc manner. Standardization of this
is what I seek with an equation microformat.

All of this would be unnecessary if browsers uniformly supported MathML
in HTML but, as previously explained, they don't. IE requires a plugin
and Firefox supports MathML only in XHTML, not plain old HTML. Other
browsers don't support display of MathML at all.

I hope I've made the situation clearer.

Paul

> -----Original Message-----
> From: microformats-new-bounces@microformats.org [mailto:microformats-
> new-bounces@microformats.org] On Behalf Of paul_wilkins@xtra.co.nz
> Sent: Thursday, October 25, 2007 8:17 PM
> To: For discussion of new microformats.
> Subject: Re: [uf-new] an equation/MathML/TeX microformat?
> 
> From: Paul Topping <pault@dessci.com>
> > To: For discussion of new microformats. <microformats-
> new@microformats.org>
> > Sent: Friday, 26 October, 2007 11:39:30 AM
> > Subject: RE: [uf-new] an equation/MathML/TeX microformat?
> >
> > "Start the discussion before you start creating any pages on the
> wiki."
> >
> > Let the discussion begin ;-)
> 
> Why do you want an equation microformat?
> hCard solved the problem of copying contact details to your address
> book.
> 
> What problem will an equation microformat solve?
> Can it be solved already with the existing MathML and other formats?
> 
> 
> --
> Paul Wilkins
> 
> 
> 
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From jeff at jeffmcneill.com  Thu Oct 25 20:52:23 2007
From: jeff at jeffmcneill.com (Jeff McNeill)
Date: Thu Oct 25 20:52:27 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
In-Reply-To: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci>
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci>
Message-ID: <519fa62f0710252052n70d1e0b8kbe65cad85cd4a4ab@mail.gmail.com>

Aloha Paul, et al,

Microformats won't fix any display problems that folks have, but could
help with say the problem of searching for a given formula across
semantically marked up content.

However, since the problem to be solved seems to be rendering the math
visually, with a variety of ways of doing that, would a microformat
require all the formulations (aka mathml, texvc, mimetex) to provide
support for yet another markup?

(Paul, I recall your comments on my blog entry trying to implement
just such rendering on a mediawiki install
http://jeffmcneill.com/2007/01/24/mathml-tex-latex-texvc-mimetex-oh-my/
)

You are right, it is a mess. Not sure how microformats could help, though.

-- 
Sincerely,
Jeff McNeill
http://jeffmcneill.com/


On 10/25/07, Paul Topping <pault@dessci.com> wrote:
> Hi,
>
> I'm trying to determine whether microformats is the right venue for
> developing a standard math representation within HTML.
>
> Back in '98, many of us involved with the W3C's MathML standard had
> hopes of it being widely supported within most browsers in a few years.
> That has sort of happened. MathML is supported natively within Firefox
> but users experience font problems and it only works if pages are XHMTL,
> rather than HTML. My company's free MathPlayer plugin makes MathML work
> in Internet Explorer. MathML support is still missing from Safari,
> Opera, and other browsers. People interested in publishing math on the
> web still find serving up pages as XHTML challenging (getting the MIME
> type right, etc.). Some websites, blogs, and wikis convert TeX or LaTeX
> to images on the server to handle equations in content. Quite frankly,
> the space is a mess.
>
> Regardless of whether the math is represented using MathML, TeX, LaTeX,
> or some other notation, it is important to expose the mathematical
> structure behind the equation to the client in order to support
> accessibility (ie, allow screen readers to speak the math) and
> interoperability (eg, allow users to copy equations from pages into
> Mathematica, MS Word docs, MathType, or new pages). What is needed is a
> consistent way to associate an underlying math representation with its
> visual representation regardless of whether it is a GIF or PNG image or
> MathML formatted by the browser (or a browser plugin).
>
> This seems like a job for a microformat but I must admit that I have
> limited knowledge of the microformat philosophy. On one hand,
> microformats embed semantic representations in HTML in a practical but
> rigorous way. On the other hand, in most (all?) microformats the
> representation is visible in the browser. In the kind of representation
> I'm imagining, the user won't actually see the actual MathML or TeX code
> in the browser window.
>
> Thoughts? Is microformats the right place for this kind of thing?
>
> Paul Topping
> Design Science, Inc.
> www.dessci.com
>
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
>
From pault at dessci.com  Thu Oct 25 23:30:23 2007
From: pault at dessci.com (Paul Topping)
Date: Thu Oct 25 23:30:28 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci>
	<519fa62f0710252052n70d1e0b8kbe65cad85cd4a4ab@mail.gmail.com>
Message-ID: <D1EFB337111B674B8F1BE155B01C6DD6025CFCB5@franklin.corp.dessci>

The problem has nothing to do with improving display. As I said, that
will be via an image such as a GIF or PNG. The microformat is solely for
the purpose of associating a MathML or TeX representation with the
image. As with other microformats, normal HTML content is what the user
sees while software sees structured, useful data.

Paul

> -----Original Message-----
> From: microformats-new-bounces@microformats.org [mailto:microformats-
> new-bounces@microformats.org] On Behalf Of Jeff McNeill
> Sent: Thursday, October 25, 2007 8:52 PM
> To: For discussion of new microformats.
> Subject: Re: [uf-new] an equation/MathML/TeX microformat?
> 
> Aloha Paul, et al,
> 
> Microformats won't fix any display problems that folks have, but could
> help with say the problem of searching for a given formula across
> semantically marked up content.
> 
> However, since the problem to be solved seems to be rendering the math
> visually, with a variety of ways of doing that, would a microformat
> require all the formulations (aka mathml, texvc, mimetex) to provide
> support for yet another markup?
> 
> (Paul, I recall your comments on my blog entry trying to implement
> just such rendering on a mediawiki install
>
http://jeffmcneill.com/2007/01/24/mathml-tex-latex-texvc-mimetex-oh-my/
> )
> 
> You are right, it is a mess. Not sure how microformats could help,
> though.
> 
> --
> Sincerely,
> Jeff McNeill
> http://jeffmcneill.com/
> 
> 
> On 10/25/07, Paul Topping <pault@dessci.com> wrote:
> > Hi,
> >
> > I'm trying to determine whether microformats is the right venue for
> > developing a standard math representation within HTML.
> >
> > Back in '98, many of us involved with the W3C's MathML standard had
> > hopes of it being widely supported within most browsers in a few
> years.
> > That has sort of happened. MathML is supported natively within
Firefox
> > but users experience font problems and it only works if pages are
> XHMTL,
> > rather than HTML. My company's free MathPlayer plugin makes MathML
> work
> > in Internet Explorer. MathML support is still missing from Safari,
> > Opera, and other browsers. People interested in publishing math on
the
> > web still find serving up pages as XHTML challenging (getting the
MIME
> > type right, etc.). Some websites, blogs, and wikis convert TeX or
> LaTeX
> > to images on the server to handle equations in content. Quite
frankly,
> > the space is a mess.
> >
> > Regardless of whether the math is represented using MathML, TeX,
> LaTeX,
> > or some other notation, it is important to expose the mathematical
> > structure behind the equation to the client in order to support
> > accessibility (ie, allow screen readers to speak the math) and
> > interoperability (eg, allow users to copy equations from pages into
> > Mathematica, MS Word docs, MathType, or new pages). What is needed
is
> a
> > consistent way to associate an underlying math representation with
its
> > visual representation regardless of whether it is a GIF or PNG image
> or
> > MathML formatted by the browser (or a browser plugin).
> >
> > This seems like a job for a microformat but I must admit that I have
> > limited knowledge of the microformat philosophy. On one hand,
> > microformats embed semantic representations in HTML in a practical
but
> > rigorous way. On the other hand, in most (all?) microformats the
> > representation is visible in the browser. In the kind of
> representation
> > I'm imagining, the user won't actually see the actual MathML or TeX
> code
> > in the browser window.
> >
> > Thoughts? Is microformats the right place for this kind of thing?
> >
> > Paul Topping
> > Design Science, Inc.
> > www.dessci.com
> >
> > _______________________________________________
> > microformats-new mailing list
> > microformats-new@microformats.org
> > http://microformats.org/mailman/listinfo/microformats-new
> >
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From fberriman at gmail.com  Fri Oct 26 02:31:03 2007
From: fberriman at gmail.com (Frances Berriman)
Date: Fri Oct 26 02:31:05 2007
Subject: [uf-new] Recipe: Additional Recipe Examples.
In-Reply-To: <47215DB9.9020307@dls.net>
References: <47215DB9.9020307@dls.net>
Message-ID: <e86992a40710260231p7ef99a99n69e22c50f30e3651@mail.gmail.com>

On 26/10/2007, holly <hollym@dls.net> wrote:
> I was reading over the archives and noticed a request wrt additional
> recipe examples.
>
> I may have a few additional examples to add and also a possible other
> sub-section for examples, but would like to run that by this list first.

Great  :)

> Currently, the recipe-examples page [1] has:
>
> 3 Recipes Examples
>     3.1 Individuals
>     3.2 Services
>

> At any rate, it may be a good idea to see how these applications render
> recipes from various sources or what formats the applications use.


Yeah - I've no problems with sectioning off those recipes that are
marked up in a specific way ready to be consumed by a particular bit
of software.  Pop them under the heading of "applications" or some
such and we should make sure that the application they're written for
is listed under the recipe-formats page (where there's a few links to
examples of recipes published on the web for those apps).

http://microformats.org/wiki/recipe-formats

-- 
Frances Berriman
http://fberriman.com
From ckstjohn at gmail.com  Fri Oct 26 07:34:16 2007
From: ckstjohn at gmail.com (Christopher St John)
Date: Fri Oct 26 07:34:18 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
In-Reply-To: <D1EFB337111B674B8F1BE155B01C6DD6025CFCB5@franklin.corp.dessci>
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci>
	<519fa62f0710252052n70d1e0b8kbe65cad85cd4a4ab@mail.gmail.com>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFCB5@franklin.corp.dessci>
Message-ID: <8ba906450710260734p82f0bf6ga32bfa87954f5001@mail.gmail.com>

On 10/26/07, Paul Topping <pault@dessci.com> wrote:
> The problem has nothing to do with improving display. As I said, that
> will be via an image such as a GIF or PNG. The microformat is solely for
> the purpose of associating a MathML or TeX representation with the
> image. As with other microformats, normal HTML content is what the user
> sees while software sees structured, useful data.
>

To restate the hopefully obvious, just in case:

You just want to say "this png image of an equation you're looking at
is associated with the (MathML | TeX | Etc) ( at the end of this link | embedded
here in the document)"

How would you do it now, without microformats? Something along the
lines of:

 <a href="some_mathml.xml"><img src="some_math.png"></a>

with maybe a "class" or "rel" or something in there to tie them together
a bit tighter?

Would "the rendering fallback for this MathML is this png image" get you
the same effect? In which case you're maybe looking at the standard
<object> tag mechanism, but that gets you some (hopefully fading)
issues on certain browsers. But do the semantics of <object> fallbacks
match what you want to do?

Have you read through the existing microformats in detail checking to
see how similiar sorts of problems have been solved before? Not sure if
there's anything exactly applicable, but it's probably worth a shot.

-cks

-- 
Christopher St. John
http://artofsystems.blogspot.com
From hollym at dls.net  Fri Oct 26 07:56:33 2007
From: hollym at dls.net (holly)
Date: Fri Oct 26 07:56:55 2007
Subject: [uf-new] Recipe:  Features and Format
Message-ID: <47220021.8080101@dls.net>

A recipe software review [1], which may point up some missed items or 
some items which may be more relevant to the Recipe Microformat.

Recipe Ratings: 6/10 had ratings

Categories: 10/10 had food categories

Import: 9/10 could import various recipe formats from other software or 
other websites.

There may be other items on the comparison table to check.

holly
[1]
http://cookbook-recipe-software-review.toptenreviews.com/
From pault at dessci.com  Fri Oct 26 08:58:21 2007
From: pault at dessci.com (Paul Topping)
Date: Fri Oct 26 08:58:25 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci><519fa62f0710252052n70d1e0b8kbe65cad85cd4a4ab@mail.gmail.com><D1EFB337111B674B8F1BE155B01C6DD6025CFCB5@franklin.corp.dessci>
	<8ba906450710260734p82f0bf6ga32bfa87954f5001@mail.gmail.com>
Message-ID: <D1EFB337111B674B8F1BE155B01C6DD6025CFCD6@franklin.corp.dessci>

What you suggest is close to what I'm looking for but lacks declaration
of the kind of data the image/linked data bundle represents. Software
working with the page would have to fetch the linked-to MathML or TeX
and examine it to know it was an equation. As I understand it, what a
microformat does is more than just hold the data, it declares a
datatype. 

Also, I want to put the MathML or TeX in the page, not in separate
documents. Typical pages with math in them might have dozens of
equations. Having their representation in separate files is inefficient
but perhaps the biggest problem is that it makes authoring a lot more
tedious as lots of small files have to be managed. 

Paul Topping
Design Science, Inc.
www.dessci.com
 
> -----Original Message-----
> From: microformats-new-bounces@microformats.org [mailto:microformats-
> new-bounces@microformats.org] On Behalf Of Christopher St John
> Sent: Friday, October 26, 2007 7:34 AM
> To: For discussion of new microformats.
> Subject: Re: [uf-new] an equation/MathML/TeX microformat?
> 
> On 10/26/07, Paul Topping <pault@dessci.com> wrote:
> > The problem has nothing to do with improving display. As I said,
that
> > will be via an image such as a GIF or PNG. The microformat is solely
> for
> > the purpose of associating a MathML or TeX representation with the
> > image. As with other microformats, normal HTML content is what the
> user
> > sees while software sees structured, useful data.
> >
> 
> To restate the hopefully obvious, just in case:
> 
> You just want to say "this png image of an equation you're looking at
> is associated with the (MathML | TeX | Etc) ( at the end of this link
|
> embedded
> here in the document)"
> 
> How would you do it now, without microformats? Something along the
> lines of:
> 
>  <a href="some_mathml.xml"><img src="some_math.png"></a>
> 
> with maybe a "class" or "rel" or something in there to tie them
together
> a bit tighter?
> 
> Would "the rendering fallback for this MathML is this png image" get
you
> the same effect? In which case you're maybe looking at the standard
> <object> tag mechanism, but that gets you some (hopefully fading)
> issues on certain browsers. But do the semantics of <object> fallbacks
> match what you want to do?
> 
> Have you read through the existing microformats in detail checking to
> see how similiar sorts of problems have been solved before? Not sure
if
> there's anything exactly applicable, but it's probably worth a shot.
> 
> -cks
> 
> --
> Christopher St. John
> http://artofsystems.blogspot.com
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From jeff at jeffmcneill.com  Fri Oct 26 11:14:34 2007
From: jeff at jeffmcneill.com (Jeff McNeill)
Date: Fri Oct 26 11:14:39 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
In-Reply-To: <D1EFB337111B674B8F1BE155B01C6DD6025CFCD6@franklin.corp.dessci>
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci>
	<519fa62f0710252052n70d1e0b8kbe65cad85cd4a4ab@mail.gmail.com>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFCB5@franklin.corp.dessci>
	<8ba906450710260734p82f0bf6ga32bfa87954f5001@mail.gmail.com>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFCD6@franklin.corp.dessci>
Message-ID: <519fa62f0710261114u2327235agfd790145995f26c6@mail.gmail.com>

Aloha,

Why not use the alt="" tag for a given rendered image? That is what
works on the MimeTeX installations, see e.g.,
http://garden9.com/wiki/user-talk:jeffmcneill

-- 
Sincerely,
Jeff McNeill
http://jeffmcneill.com/


On 10/26/07, Paul Topping <pault@dessci.com> wrote:
> What you suggest is close to what I'm looking for but lacks declaration
> of the kind of data the image/linked data bundle represents. Software
> working with the page would have to fetch the linked-to MathML or TeX
> and examine it to know it was an equation. As I understand it, what a
> microformat does is more than just hold the data, it declares a
> datatype.
>
> Also, I want to put the MathML or TeX in the page, not in separate
> documents. Typical pages with math in them might have dozens of
> equations. Having their representation in separate files is inefficient
> but perhaps the biggest problem is that it makes authoring a lot more
> tedious as lots of small files have to be managed.
>
> Paul Topping
> Design Science, Inc.
> www.dessci.com
>
> > -----Original Message-----
> > From: microformats-new-bounces@microformats.org [mailto:microformats-
> > new-bounces@microformats.org] On Behalf Of Christopher St John
> > Sent: Friday, October 26, 2007 7:34 AM
> > To: For discussion of new microformats.
> > Subject: Re: [uf-new] an equation/MathML/TeX microformat?
> >
> > On 10/26/07, Paul Topping <pault@dessci.com> wrote:
> > > The problem has nothing to do with improving display. As I said,
> that
> > > will be via an image such as a GIF or PNG. The microformat is solely
> > for
> > > the purpose of associating a MathML or TeX representation with the
> > > image. As with other microformats, normal HTML content is what the
> > user
> > > sees while software sees structured, useful data.
> > >
> >
> > To restate the hopefully obvious, just in case:
> >
> > You just want to say "this png image of an equation you're looking at
> > is associated with the (MathML | TeX | Etc) ( at the end of this link
> |
> > embedded
> > here in the document)"
> >
> > How would you do it now, without microformats? Something along the
> > lines of:
> >
> >  <a href="some_mathml.xml"><img src="some_math.png"></a>
> >
> > with maybe a "class" or "rel" or something in there to tie them
> together
> > a bit tighter?
> >
> > Would "the rendering fallback for this MathML is this png image" get
> you
> > the same effect? In which case you're maybe looking at the standard
> > <object> tag mechanism, but that gets you some (hopefully fading)
> > issues on certain browsers. But do the semantics of <object> fallbacks
> > match what you want to do?
> >
> > Have you read through the existing microformats in detail checking to
> > see how similiar sorts of problems have been solved before? Not sure
> if
> > there's anything exactly applicable, but it's probably worth a shot.
> >
> > -cks
> >
> > --
> > Christopher St. John
> > http://artofsystems.blogspot.com
> > _______________________________________________
> > microformats-new mailing list
> > microformats-new@microformats.org
> > http://microformats.org/mailman/listinfo/microformats-new
>
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
>
From pault at dessci.com  Fri Oct 26 11:24:18 2007
From: pault at dessci.com (Paul Topping)
Date: Fri Oct 26 11:24:21 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci><519fa62f0710252052n70d1e0b8kbe65cad85cd4a4ab@mail.gmail.com><D1EFB337111B674B8F1BE155B01C6DD6025CFCB5@franklin.corp.dessci><8ba906450710260734p82f0bf6ga32bfa87954f5001@mail.gmail.com><D1EFB337111B674B8F1BE155B01C6DD6025CFCD6@franklin.corp.dessci>
	<519fa62f0710261114u2327235agfd790145995f26c6@mail.gmail.com>
Message-ID: <D1EFB337111B674B8F1BE155B01C6DD6025CFD33@franklin.corp.dessci>

Because that eliminates its originally intended use as "alternative
text". Screen readers will read this literally, for example, and it will
show up in tooltips when one hovers over it with the mouse. It is
exactly this kind of hack that I'm looking to microformats to escape
from.

Paul

> -----Original Message-----
> From: microformats-new-bounces@microformats.org [mailto:microformats-
> new-bounces@microformats.org] On Behalf Of Jeff McNeill
> Sent: Friday, October 26, 2007 11:15 AM
> To: For discussion of new microformats.
> Subject: Re: [uf-new] an equation/MathML/TeX microformat?
> 
> Aloha,
> 
> Why not use the alt="" tag for a given rendered image? That is what
> works on the MimeTeX installations, see e.g.,
> http://garden9.com/wiki/user-talk:jeffmcneill
> 
> --
> Sincerely,
> Jeff McNeill
> http://jeffmcneill.com/
> 
> 
> On 10/26/07, Paul Topping <pault@dessci.com> wrote:
> > What you suggest is close to what I'm looking for but lacks
> declaration
> > of the kind of data the image/linked data bundle represents.
Software
> > working with the page would have to fetch the linked-to MathML or
TeX
> > and examine it to know it was an equation. As I understand it, what
a
> > microformat does is more than just hold the data, it declares a
> > datatype.
> >
> > Also, I want to put the MathML or TeX in the page, not in separate
> > documents. Typical pages with math in them might have dozens of
> > equations. Having their representation in separate files is
> inefficient
> > but perhaps the biggest problem is that it makes authoring a lot
more
> > tedious as lots of small files have to be managed.
> >
> > Paul Topping
> > Design Science, Inc.
> > www.dessci.com
> >
> > > -----Original Message-----
> > > From: microformats-new-bounces@microformats.org
> [mailto:microformats-
> > > new-bounces@microformats.org] On Behalf Of Christopher St John
> > > Sent: Friday, October 26, 2007 7:34 AM
> > > To: For discussion of new microformats.
> > > Subject: Re: [uf-new] an equation/MathML/TeX microformat?
> > >
> > > On 10/26/07, Paul Topping <pault@dessci.com> wrote:
> > > > The problem has nothing to do with improving display. As I said,
> > that
> > > > will be via an image such as a GIF or PNG. The microformat is
> solely
> > > for
> > > > the purpose of associating a MathML or TeX representation with
the
> > > > image. As with other microformats, normal HTML content is what
the
> > > user
> > > > sees while software sees structured, useful data.
> > > >
> > >
> > > To restate the hopefully obvious, just in case:
> > >
> > > You just want to say "this png image of an equation you're looking
> at
> > > is associated with the (MathML | TeX | Etc) ( at the end of this
> link
> > |
> > > embedded
> > > here in the document)"
> > >
> > > How would you do it now, without microformats? Something along the
> > > lines of:
> > >
> > >  <a href="some_mathml.xml"><img src="some_math.png"></a>
> > >
> > > with maybe a "class" or "rel" or something in there to tie them
> > together
> > > a bit tighter?
> > >
> > > Would "the rendering fallback for this MathML is this png image"
get
> > you
> > > the same effect? In which case you're maybe looking at the
standard
> > > <object> tag mechanism, but that gets you some (hopefully fading)
> > > issues on certain browsers. But do the semantics of <object>
> fallbacks
> > > match what you want to do?
> > >
> > > Have you read through the existing microformats in detail checking
> to
> > > see how similiar sorts of problems have been solved before? Not
sure
> > if
> > > there's anything exactly applicable, but it's probably worth a
shot.
> > >
> > > -cks
> > >
> > > --
> > > Christopher St. John
> > > http://artofsystems.blogspot.com
> > > _______________________________________________
> > > microformats-new mailing list
> > > microformats-new@microformats.org
> > > http://microformats.org/mailman/listinfo/microformats-new
> >
> > _______________________________________________
> > microformats-new mailing list
> > microformats-new@microformats.org
> > http://microformats.org/mailman/listinfo/microformats-new
> >
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From jeff at jeffmcneill.com  Fri Oct 26 12:22:01 2007
From: jeff at jeffmcneill.com (Jeff McNeill)
Date: Fri Oct 26 12:22:05 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
In-Reply-To: <D1EFB337111B674B8F1BE155B01C6DD6025CFD33@franklin.corp.dessci>
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci>
	<519fa62f0710252052n70d1e0b8kbe65cad85cd4a4ab@mail.gmail.com>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFCB5@franklin.corp.dessci>
	<8ba906450710260734p82f0bf6ga32bfa87954f5001@mail.gmail.com>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFCD6@franklin.corp.dessci>
	<519fa62f0710261114u2327235agfd790145995f26c6@mail.gmail.com>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFD33@franklin.corp.dessci>
Message-ID: <519fa62f0710261222o54d7d8a4w3072627ad521f2c0@mail.gmail.com>

Aloha Paul, et al,

Not quite sure that (alt="") is not its intended or suggested use[1].
It appears that WAG suggests the practices that are being used[2]. For
good measure, there is the MediaWiki page on formula display[3]. For
tooltips, I thought that title="" was the appropriate use and not alt,
but not sure how that works.

I can appreciate the desire to do something more than this, if only
for the use case of "search for all documents that have the KR-20
formula"[4].


[1] http://www.w3.org/TR/html4/struct/objects.html#alternate-text
[2] http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-markup
[3] http://meta.wikimedia.org/wiki/Help:Formula
[4] http://en.wikipedia.org/wiki/KR-20

-- 
Sincerely,
Jeff McNeill
http://jeffmcneill.com/


On 10/26/07, Paul Topping <pault@dessci.com> wrote:
> Because that eliminates its originally intended use as "alternative
> text". Screen readers will read this literally, for example, and it will
> show up in tooltips when one hovers over it with the mouse. It is
> exactly this kind of hack that I'm looking to microformats to escape
> from.
>
> Paul
>
> > -----Original Message-----
> > From: microformats-new-bounces@microformats.org [mailto:microformats-
> > new-bounces@microformats.org] On Behalf Of Jeff McNeill
> > Sent: Friday, October 26, 2007 11:15 AM
> > To: For discussion of new microformats.
> > Subject: Re: [uf-new] an equation/MathML/TeX microformat?
> >
> > Aloha,
> >
> > Why not use the alt="" tag for a given rendered image? That is what
> > works on the MimeTeX installations, see e.g.,
> > http://garden9.com/wiki/user-talk:jeffmcneill
> >
> > --
> > Sincerely,
> > Jeff McNeill
> > http://jeffmcneill.com/
> >
> >
> > On 10/26/07, Paul Topping <pault@dessci.com> wrote:
> > > What you suggest is close to what I'm looking for but lacks
> > declaration
> > > of the kind of data the image/linked data bundle represents.
> Software
> > > working with the page would have to fetch the linked-to MathML or
> TeX
> > > and examine it to know it was an equation. As I understand it, what
> a
> > > microformat does is more than just hold the data, it declares a
> > > datatype.
> > >
> > > Also, I want to put the MathML or TeX in the page, not in separate
> > > documents. Typical pages with math in them might have dozens of
> > > equations. Having their representation in separate files is
> > inefficient
> > > but perhaps the biggest problem is that it makes authoring a lot
> more
> > > tedious as lots of small files have to be managed.
> > >
> > > Paul Topping
> > > Design Science, Inc.
> > > www.dessci.com
> > >
> > > > -----Original Message-----
> > > > From: microformats-new-bounces@microformats.org
> > [mailto:microformats-
> > > > new-bounces@microformats.org] On Behalf Of Christopher St John
> > > > Sent: Friday, October 26, 2007 7:34 AM
> > > > To: For discussion of new microformats.
> > > > Subject: Re: [uf-new] an equation/MathML/TeX microformat?
> > > >
> > > > On 10/26/07, Paul Topping <pault@dessci.com> wrote:
> > > > > The problem has nothing to do with improving display. As I said,
> > > that
> > > > > will be via an image such as a GIF or PNG. The microformat is
> > solely
> > > > for
> > > > > the purpose of associating a MathML or TeX representation with
> the
> > > > > image. As with other microformats, normal HTML content is what
> the
> > > > user
> > > > > sees while software sees structured, useful data.
> > > > >
> > > >
> > > > To restate the hopefully obvious, just in case:
> > > >
> > > > You just want to say "this png image of an equation you're looking
> > at
> > > > is associated with the (MathML | TeX | Etc) ( at the end of this
> > link
> > > |
> > > > embedded
> > > > here in the document)"
> > > >
> > > > How would you do it now, without microformats? Something along the
> > > > lines of:
> > > >
> > > >  <a href="some_mathml.xml"><img src="some_math.png"></a>
> > > >
> > > > with maybe a "class" or "rel" or something in there to tie them
> > > together
> > > > a bit tighter?
> > > >
> > > > Would "the rendering fallback for this MathML is this png image"
> get
> > > you
> > > > the same effect? In which case you're maybe looking at the
> standard
> > > > <object> tag mechanism, but that gets you some (hopefully fading)
> > > > issues on certain browsers. But do the semantics of <object>
> > fallbacks
> > > > match what you want to do?
> > > >
> > > > Have you read through the existing microformats in detail checking
> > to
> > > > see how similiar sorts of problems have been solved before? Not
> sure
> > > if
> > > > there's anything exactly applicable, but it's probably worth a
> shot.
> > > >
> > > > -cks
> > > >
> > > > --
> > > > Christopher St. John
> > > > http://artofsystems.blogspot.com
> > > > _______________________________________________
> > > > microformats-new mailing list
> > > > microformats-new@microformats.org
> > > > http://microformats.org/mailman/listinfo/microformats-new
> > >
> > > _______________________________________________
> > > microformats-new mailing list
> > > microformats-new@microformats.org
> > > http://microformats.org/mailman/listinfo/microformats-new
> > >
> > _______________________________________________
> > microformats-new mailing list
> > microformats-new@microformats.org
> > http://microformats.org/mailman/listinfo/microformats-new
>
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
>
From pault at dessci.com  Fri Oct 26 12:40:36 2007
From: pault at dessci.com (Paul Topping)
Date: Fri Oct 26 12:40:38 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci><519fa62f0710252052n70d1e0b8kbe65cad85cd4a4ab@mail.gmail.com><D1EFB337111B674B8F1BE155B01C6DD6025CFCB5@franklin.corp.dessci><8ba906450710260734p82f0bf6ga32bfa87954f5001@mail.gmail.com><D1EFB337111B674B8F1BE155B01C6DD6025CFCD6@franklin.corp.dessci><519fa62f0710261114u2327235agfd790145995f26c6@mail.gmail.com><D1EFB337111B674B8F1BE155B01C6DD6025CFD33@franklin.corp.dessci>
	<519fa62f0710261222o54d7d8a4w3072627ad521f2c0@mail.gmail.com>
Message-ID: <D1EFB337111B674B8F1BE155B01C6DD6025CFD51@franklin.corp.dessci>

Alt text is a common way to associate some sort of metadata with an
image. However,  as the HTML4 reference you give states,

"... alternate text to serve as content when the element cannot be
rendered normally. Specifying alternate text assists users without
graphic display terminals, users whose browsers don't support forms,
visually impaired users, those who use speech synthesizers, those who
have configured their graphical user agents not to display images, etc."

I think it is pretty clear that those that see or hear alt text for an
equation do not want to see or hear its MathML representation. There are
a few people that wouldn't mind a TeX representation but that most
certainly won't make most people happy.

And, as already stated, the goal is to embed MathML and TeX in such a
way that it enables programs to identify it beyond the shadow of a doubt
and without having to sniff the actual data.

Paul

> -----Original Message-----
> From: microformats-new-bounces@microformats.org 
> [mailto:microformats-new-bounces@microformats.org] On Behalf 
> Of Jeff McNeill
> Sent: Friday, October 26, 2007 12:22 PM
> To: For discussion of new microformats.
> Subject: Re: [uf-new] an equation/MathML/TeX microformat?
> 
> Aloha Paul, et al,
> 
> Not quite sure that (alt="") is not its intended or suggested use[1].
> It appears that WAG suggests the practices that are being used[2]. For
> good measure, there is the MediaWiki page on formula display[3]. For
> tooltips, I thought that title="" was the appropriate use and not alt,
> but not sure how that works.
> 
> I can appreciate the desire to do something more than this, if only
> for the use case of "search for all documents that have the KR-20
> formula"[4].
> 
> 
> [1] http://www.w3.org/TR/html4/struct/objects.html#alternate-text
> [2] http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-markup
> [3] http://meta.wikimedia.org/wiki/Help:Formula
> [4] http://en.wikipedia.org/wiki/KR-20
> 
> -- 
> Sincerely,
> Jeff McNeill
> http://jeffmcneill.com/
> 
> 
> On 10/26/07, Paul Topping <pault@dessci.com> wrote:
> > Because that eliminates its originally intended use as "alternative
> > text". Screen readers will read this literally, for 
> example, and it will
> > show up in tooltips when one hovers over it with the mouse. It is
> > exactly this kind of hack that I'm looking to microformats to escape
> > from.
> >
> > Paul
> >
> > > -----Original Message-----
> > > From: microformats-new-bounces@microformats.org 
> [mailto:microformats-
> > > new-bounces@microformats.org] On Behalf Of Jeff McNeill
> > > Sent: Friday, October 26, 2007 11:15 AM
> > > To: For discussion of new microformats.
> > > Subject: Re: [uf-new] an equation/MathML/TeX microformat?
> > >
> > > Aloha,
> > >
> > > Why not use the alt="" tag for a given rendered image? 
> That is what
> > > works on the MimeTeX installations, see e.g.,
> > > http://garden9.com/wiki/user-talk:jeffmcneill
> > >
> > > --
> > > Sincerely,
> > > Jeff McNeill
> > > http://jeffmcneill.com/
> > >
> > >
> > > On 10/26/07, Paul Topping <pault@dessci.com> wrote:
> > > > What you suggest is close to what I'm looking for but lacks
> > > declaration
> > > > of the kind of data the image/linked data bundle represents.
> > Software
> > > > working with the page would have to fetch the linked-to 
> MathML or
> > TeX
> > > > and examine it to know it was an equation. As I 
> understand it, what
> > a
> > > > microformat does is more than just hold the data, it declares a
> > > > datatype.
> > > >
> > > > Also, I want to put the MathML or TeX in the page, not 
> in separate
> > > > documents. Typical pages with math in them might have dozens of
> > > > equations. Having their representation in separate files is
> > > inefficient
> > > > but perhaps the biggest problem is that it makes authoring a lot
> > more
> > > > tedious as lots of small files have to be managed.
> > > >
> > > > Paul Topping
> > > > Design Science, Inc.
> > > > www.dessci.com
> > > >
> > > > > -----Original Message-----
> > > > > From: microformats-new-bounces@microformats.org
> > > [mailto:microformats-
> > > > > new-bounces@microformats.org] On Behalf Of Christopher St John
> > > > > Sent: Friday, October 26, 2007 7:34 AM
> > > > > To: For discussion of new microformats.
> > > > > Subject: Re: [uf-new] an equation/MathML/TeX microformat?
> > > > >
> > > > > On 10/26/07, Paul Topping <pault@dessci.com> wrote:
> > > > > > The problem has nothing to do with improving 
> display. As I said,
> > > > that
> > > > > > will be via an image such as a GIF or PNG. The 
> microformat is
> > > solely
> > > > > for
> > > > > > the purpose of associating a MathML or TeX 
> representation with
> > the
> > > > > > image. As with other microformats, normal HTML 
> content is what
> > the
> > > > > user
> > > > > > sees while software sees structured, useful data.
> > > > > >
> > > > >
> > > > > To restate the hopefully obvious, just in case:
> > > > >
> > > > > You just want to say "this png image of an equation 
> you're looking
> > > at
> > > > > is associated with the (MathML | TeX | Etc) ( at the 
> end of this
> > > link
> > > > |
> > > > > embedded
> > > > > here in the document)"
> > > > >
> > > > > How would you do it now, without microformats? 
> Something along the
> > > > > lines of:
> > > > >
> > > > >  <a href="some_mathml.xml"><img src="some_math.png"></a>
> > > > >
> > > > > with maybe a "class" or "rel" or something in there 
> to tie them
> > > > together
> > > > > a bit tighter?
> > > > >
> > > > > Would "the rendering fallback for this MathML is this 
> png image"
> > get
> > > > you
> > > > > the same effect? In which case you're maybe looking at the
> > standard
> > > > > <object> tag mechanism, but that gets you some 
> (hopefully fading)
> > > > > issues on certain browsers. But do the semantics of <object>
> > > fallbacks
> > > > > match what you want to do?
> > > > >
> > > > > Have you read through the existing microformats in 
> detail checking
> > > to
> > > > > see how similiar sorts of problems have been solved 
> before? Not
> > sure
> > > > if
> > > > > there's anything exactly applicable, but it's probably worth a
> > shot.
> > > > >
> > > > > -cks
> > > > >
> > > > > --
> > > > > Christopher St. John
> > > > > http://artofsystems.blogspot.com
> > > > > _______________________________________________
> > > > > microformats-new mailing list
> > > > > microformats-new@microformats.org
> > > > > http://microformats.org/mailman/listinfo/microformats-new
> > > >
> > > > _______________________________________________
> > > > microformats-new mailing list
> > > > microformats-new@microformats.org
> > > > http://microformats.org/mailman/listinfo/microformats-new
> > > >
> > > _______________________________________________
> > > microformats-new mailing list
> > > microformats-new@microformats.org
> > > http://microformats.org/mailman/listinfo/microformats-new
> >
> > _______________________________________________
> > microformats-new mailing list
> > microformats-new@microformats.org
> > http://microformats.org/mailman/listinfo/microformats-new
> >
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
> 

From ckstjohn at gmail.com  Fri Oct 26 13:02:25 2007
From: ckstjohn at gmail.com (Christopher St John)
Date: Fri Oct 26 13:02:34 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
In-Reply-To: <519fa62f0710261222o54d7d8a4w3072627ad521f2c0@mail.gmail.com>
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci>
	<519fa62f0710252052n70d1e0b8kbe65cad85cd4a4ab@mail.gmail.com>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFCB5@franklin.corp.dessci>
	<8ba906450710260734p82f0bf6ga32bfa87954f5001@mail.gmail.com>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFCD6@franklin.corp.dessci>
	<519fa62f0710261114u2327235agfd790145995f26c6@mail.gmail.com>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFD33@franklin.corp.dessci>
	<519fa62f0710261222o54d7d8a4w3072627ad521f2c0@mail.gmail.com>
Message-ID: <8ba906450710261302p210d7658uee08b5224d835032@mail.gmail.com>

On 10/26/07, Jeff McNeill <jeff@jeffmcneill.com> wrote:
>
> Not quite sure that (alt="") is not its intended or suggested use ...
>

There are (at least) three artifacts involved:

 a) The text that should be pronounced by a screen reader ( the alt
    text in <img
   src="http://jeffmcneill.com/cgi-bin/mimetex.cgi?E(aX+b)=aE(X)+b"
   alt= "E(aX+b)=aE(X)+b" /> )

 b) The underlying semantic representation, possibly MathML,
   possibly TeX). As (a) shows you can sometimes _say_ TeX (and
   sometimes arguably not: \Large f(x)=\int_{-\infty}^x e^{-t^2}dt), but
   nobody should ever be forced to listen to MathML spoken aloud
   because it looks like this: "...<mrow><msup><mfenced open=
   "[" close="]"><mrow><mi>a</mi><mo>+</mo>..."

 c) The <img> that is the rendering of the underlying semantic
   markup.

But the Wikipedia work is certainly a good start at an examples list,
and in my Googling around I came across several others. Although I
have a sneaking suspicion this might not really be a big-M uf thing,
it's certainly seems worth gathering more examples as ammunition
for whatever next step is appropriate.

On 10/26/07, Paul Topping <pault@dessci.com> wrote:
> ... It is
> exactly this kind of hack that I'm looking to microformats to escape
> from.
>

In that case, you're going to _hate_ microformats, because they
don't so much escape those kinds of hacks as enshrine them
as standards :-)

-cks

-- 
Christopher St. John
http://artofsystems.blogspot.com
From jeff at jeffmcneill.com  Fri Oct 26 13:27:45 2007
From: jeff at jeffmcneill.com (Jeff McNeill)
Date: Fri Oct 26 13:27:49 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
In-Reply-To: <8ba906450710261302p210d7658uee08b5224d835032@mail.gmail.com>
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci>
	<519fa62f0710252052n70d1e0b8kbe65cad85cd4a4ab@mail.gmail.com>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFCB5@franklin.corp.dessci>
	<8ba906450710260734p82f0bf6ga32bfa87954f5001@mail.gmail.com>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFCD6@franklin.corp.dessci>
	<519fa62f0710261114u2327235agfd790145995f26c6@mail.gmail.com>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFD33@franklin.corp.dessci>
	<519fa62f0710261222o54d7d8a4w3072627ad521f2c0@mail.gmail.com>
	<8ba906450710261302p210d7658uee08b5224d835032@mail.gmail.com>
Message-ID: <519fa62f0710261327n215772ajc8b5e73c6d251259@mail.gmail.com>

Aloha,

Found this useful site which has a variety of approaches to math text
descriptions[1]. It discusses the elements as mentioned by
Christopher:

* image
* code
* description (natural language summary (for alt or longdesc)

[1] http://nimas.cast.org/about/resources/math/text_descriptions.html

-- 
Sincerely,
Jeff McNeill
http://jeffmcneill.com/


On 10/26/07, Christopher St John <ckstjohn@gmail.com> wrote:
> On 10/26/07, Jeff McNeill <jeff@jeffmcneill.com> wrote:
> >
> > Not quite sure that (alt="") is not its intended or suggested use ...
> >
>
> There are (at least) three artifacts involved:
>
>  a) The text that should be pronounced by a screen reader ( the alt
>     text in <img
>    src="http://jeffmcneill.com/cgi-bin/mimetex.cgi?E(aX+b)=aE(X)+b"
>    alt= "E(aX+b)=aE(X)+b" /> )
>
>  b) The underlying semantic representation, possibly MathML,
>    possibly TeX). As (a) shows you can sometimes _say_ TeX (and
>    sometimes arguably not: \Large f(x)=\int_{-\infty}^x e^{-t^2}dt), but
>    nobody should ever be forced to listen to MathML spoken aloud
>    because it looks like this: "...<mrow><msup><mfenced open=
>    "[" close="]"><mrow><mi>a</mi><mo>+</mo>..."
>
>  c) The <img> that is the rendering of the underlying semantic
>    markup.
>
> But the Wikipedia work is certainly a good start at an examples list,
> and in my Googling around I came across several others. Although I
> have a sneaking suspicion this might not really be a big-M uf thing,
> it's certainly seems worth gathering more examples as ammunition
> for whatever next step is appropriate.
>
> On 10/26/07, Paul Topping <pault@dessci.com> wrote:
> > ... It is
> > exactly this kind of hack that I'm looking to microformats to escape
> > from.
> >
>
> In that case, you're going to _hate_ microformats, because they
> don't so much escape those kinds of hacks as enshrine them
> as standards :-)
>
> -cks
>
> --
> Christopher St. John
> http://artofsystems.blogspot.com
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
>
From pault at dessci.com  Fri Oct 26 13:38:04 2007
From: pault at dessci.com (Paul Topping)
Date: Fri Oct 26 13:38:06 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci><519fa62f0710252052n70d1e0b8kbe65cad85cd4a4ab@mail.gmail.com><D1EFB337111B674B8F1BE155B01C6DD6025CFCB5@franklin.corp.dessci><8ba906450710260734p82f0bf6ga32bfa87954f5001@mail.gmail.com><D1EFB337111B674B8F1BE155B01C6DD6025CFCD6@franklin.corp.dessci><519fa62f0710261114u2327235agfd790145995f26c6@mail.gmail.com><D1EFB337111B674B8F1BE155B01C6DD6025CFD33@franklin.corp.dessci><519fa62f0710261222o54d7d8a4w3072627ad521f2c0@mail.gmail.com>
	<8ba906450710261302p210d7658uee08b5224d835032@mail.gmail.com>
Message-ID: <D1EFB337111B674B8F1BE155B01C6DD6025CFD63@franklin.corp.dessci>

<snip>

> But the Wikipedia work is certainly a good start at an examples list,
> and in my Googling around I came across several others. Although I
> have a sneaking suspicion this might not really be a big-M uf thing,
> it's certainly seems worth gathering more examples as ammunition
> for whatever next step is appropriate.
> 
> On 10/26/07, Paul Topping <pault@dessci.com> wrote:
> > ... It is
> > exactly this kind of hack that I'm looking to microformats to escape
> > from.
> >
> 
> In that case, you're going to _hate_ microformats, because they
> don't so much escape those kinds of hacks as enshrine them
> as standards :-)

Yes, but microformats does this in a way that doesn't interfere with
existing uses of the HTML attribute or tag that it appropriates. This is
key. It exploits places in HTML where extension is allowed to encode
information. This makes it much less of a hack.

Paul

From scott at makedatamakesense.com  Fri Oct 26 13:49:27 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Fri Oct 26 13:49:32 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
In-Reply-To: <D1EFB337111B674B8F1BE155B01C6DD6025CFCD6@franklin.corp.dessci>
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci><519fa62f0710252052n70d1e0b8kbe65cad85cd4a4ab@mail.gmail.com><D1EFB337111B674B8F1BE155B01C6DD6025CFCB5@franklin.corp.dessci>
	<8ba906450710260734p82f0bf6ga32bfa87954f5001@mail.gmail.com>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFCD6@franklin.corp.dessci>
Message-ID: <A3912D2F-AA06-4350-834A-F1C015C46466@makedatamakesense.com>

On Oct 26, 2007, at 9:58 AM, Paul Topping wrote:

> Also, I want to put the MathML or TeX in the page, not in separate
> documents.

This seems to be the fundamental problem, and I doubt microformats  
can solve it.  With microformats we can make maximum use of existing  
HTML tags, but we can't create new tags.  And I don't think any  
existing HTML tags allow embedding of XML-based data directly in HTML  
documents.  You could escape all the XML with entities, e.g.  
&lt;math&gt;, but that would be far more work than a separate  
document.  <script> can include XML, but implies the XML is a script,  
which MathML isn't really.  If you're okay with such redefinition of  
HTML elements, you could do something like this:

<script type="text/mathml">
	[MathML version]
</script>
<script type="text/tex">
	[Tex version]
</script>
<noscript>
	<img src="[image version]" alt="[text version]" />
</noscript>

Note that's just plain HTML, no microformat.  You could also just  
wrap the XML in a comment, but HTML comments by definition don't have  
any semantics.  You could wrap a container around the comment with  
semantics, but again you're getting into redefining HTML elements:

<div class="math">
	<img src="[image version]" alt="[text version]" class="photo" />
	<div class="mathml">
	<!--
		[MathML version]
	-->
	</div>
	<div class="tex">
	<!--
		[TeX version]
	-->
	</div>
</div>

That's closer to what microformats do, but not likely to be accepted  
by this community as it requires treating an HTML element as  
something completely different from what the HTML spec suggests.  I  
believe anywhere else you put raw XML will cause it to be treated as  
(invalid) HTML.

--
Scott Reynen
MakeDataMakeSense.com
From pault at dessci.com  Fri Oct 26 15:04:05 2007
From: pault at dessci.com (Paul Topping)
Date: Fri Oct 26 15:04:08 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci><519fa62f0710252052n70d1e0b8kbe65cad85cd4a4ab@mail.gmail.com><D1EFB337111B674B8F1BE155B01C6DD6025CFCB5@franklin.corp.dessci><8ba906450710260734p82f0bf6ga32bfa87954f5001@mail.gmail.com><D1EFB337111B674B8F1BE155B01C6DD6025CFCD6@franklin.corp.dessci>
	<A3912D2F-AA06-4350-834A-F1C015C46466@makedatamakesense.com>
Message-ID: <D1EFB337111B674B8F1BE155B01C6DD6025CFD7E@franklin.corp.dessci>

This is the kind of thing I was looking for. The use of comments within
<div> might be a problem as they can't be accessed via the DOM, right?
I'm not sure escaping the MathML or TeX is as big a problem as you say
as it can be handled by proper authoring tools. 

Paul Topping
Design Science, Inc.
http://www.dessci.com
 

> -----Original Message-----
> From: microformats-new-bounces@microformats.org 
> [mailto:microformats-new-bounces@microformats.org] On Behalf 
> Of Scott Reynen
> Sent: Friday, October 26, 2007 1:49 PM
> To: For discussion of new microformats.
> Subject: Re: [uf-new] an equation/MathML/TeX microformat?
> 
> On Oct 26, 2007, at 9:58 AM, Paul Topping wrote:
> 
> > Also, I want to put the MathML or TeX in the page, not in separate
> > documents.
> 
> This seems to be the fundamental problem, and I doubt microformats  
> can solve it.  With microformats we can make maximum use of existing  
> HTML tags, but we can't create new tags.  And I don't think any  
> existing HTML tags allow embedding of XML-based data directly 
> in HTML  
> documents.  You could escape all the XML with entities, e.g.  
> &lt;math&gt;, but that would be far more work than a separate  
> document.  <script> can include XML, but implies the XML is a 
> script,  
> which MathML isn't really.  If you're okay with such redefinition of  
> HTML elements, you could do something like this:
> 
> <script type="text/mathml">
> 	[MathML version]
> </script>
> <script type="text/tex">
> 	[Tex version]
> </script>
> <noscript>
> 	<img src="[image version]" alt="[text version]" />
> </noscript>
> 
> Note that's just plain HTML, no microformat.  You could also just  
> wrap the XML in a comment, but HTML comments by definition 
> don't have  
> any semantics.  You could wrap a container around the comment with  
> semantics, but again you're getting into redefining HTML elements:
> 
> <div class="math">
> 	<img src="[image version]" alt="[text version]" class="photo" />
> 	<div class="mathml">
> 	<!--
> 		[MathML version]
> 	-->
> 	</div>
> 	<div class="tex">
> 	<!--
> 		[TeX version]
> 	-->
> 	</div>
> </div>
> 
> That's closer to what microformats do, but not likely to be accepted  
> by this community as it requires treating an HTML element as  
> something completely different from what the HTML spec suggests.  I  
> believe anywhere else you put raw XML will cause it to be treated as  
> (invalid) HTML.
> 
> --
> Scott Reynen
> MakeDataMakeSense.com
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
> 

From bhawkeslewis at googlemail.com  Sat Oct 27 06:24:33 2007
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Sat Oct 27 06:24:36 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
In-Reply-To: <D1EFB337111B674B8F1BE155B01C6DD6025CFC75@franklin.corp.dessci>
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci>
	<6FCC7A43-F782-487B-91A4-7A8566858814@makedatamakesense.com>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFC75@franklin.corp.dessci>
Message-ID: <1193491473.10990.99.camel@galahad>


On Thu, 2007-10-25 at 15:39 -0700, Paul Topping wrote:

> I'm aware of the effort to support MathML in HTML5 but this effort seems
> unlikely to bear fruit. Besides, I'm looking to create something that
> will work in "plain old HTML" which, as I understand it, is part of the
> microformat philosophy. As I stated, MathML was originally intended to
> be implemented in browsers but the actuality leaves something to be
> desired. With HTML5, I would simply be waiting for yet another thing to
> be implemented in browsers. Exactly what I want to avoid.

Personally, I believe wanting to use MathML is one of the rare
use-cases that justifies choosing XHTML over HTML 4.01, in which case
you can inline MathML directly into your markup.

Can you provide some more details about the problem you're trying to
solve, in particular:

1. What are the deficiencies of existing techniques for using
mathematical markup in conjunction with HTML that you are realistically
expecting to overcome?

2. What are the key existing consuming agents you'd like the solution to
those deficiencies to work with? e.g. What platforms, browsers, and
assistive technology?

Currently, your company's MathPlayer ActiveX plugin can already speak
maths and has MSAA support for assistive technology:

http://www.dessci.com/en/products/mathplayer/tech/accessibility.htm

Gecko has built-in support for a subset of MathML; the FireVox extension
turns Firefox into a self-voicing browser on all three major platforms
and can read MathML using Abraham Nemeth's Mathspeak rules:

http://www.firevox.clcworld.net/features.html

The next version of Opera will include support for a subset of MathML
and restore (some level of) support for assistive technologies on
Windows and Mac: 

http://dev.opera.com/articles/view/can-kestrels-do-math-mathml-support-in/

http://my.opera.com/desktopteam/blog/2007/08/31/focus-areas-during-kestrel-development

The only major engine missing support for MathML at all is WebKit:

http://bugs.webkit.org/show_bug.cgi?id=3251

This situation could be a /lot/ better. 

Your problem seems very similar to the problem of inlining RDF in HTML:

http://infomesh.net/2002/rdfinhtml/

http://esw.w3.org/topic/EmbeddingRDFinHTML

The suggested approach of dumping XML markup inside comments was
actually used by Creative Commons and Moveable Type's Trackback system:

http://www.xml.com/pub/a/2003/01/15/creative.html

But I can't really see how embedding MathML markup inside HTML comments
is supposed to improve things with existing (or even future) consuming
agents. You did say this:

> Also, I want to put the MathML or TeX in the page, not in separate
> documents. Typical pages with math in them might have dozens of
> equations. Having their representation in separate files is
> inefficient but perhaps the biggest problem is that it makes authoring
> a lot more tedious as lots of small files have to be managed. 

The web stack tends to work by stitching together lots of different
resources to make up the final presentation the user experiences when
she visits a URI: multiple HTML documents, scripts, stylesheets, images,
Flash movies, and so on all get bound together by a master document. I'm
generally sceptical about attempts to fight against this model in the
name of efficiency without changing the HTML specification itself. 

There's also an issue of efficiency for consuming agents that don't
support MathML and would have to waste bandwidth on MathML embedded in
comments.

Having said that, additional requests are more expensive than additional
bytes. But even if you have to externalize MathML outside the main HTML
document, you could (I guess) cut down the additional requests to just
one by using fragment identifiers to pinpoint individual equations in an
XML document containing a series of equations. You could even make the
referenced document an XHTML version of the HTML document, and use a
<link rel="alternate" type="application/xhtml+xml"> element to point to
the XHTML version from the HEAD of the HTML version, and use the HTML
HREF and LONGDESC attributes to point to fragment identifiers for
particular equations. HTTP content negotiation could perhaps be used to
send supporting consuming agents to the XHTML version in the first
place.

For very short equations, you might be able to do away with the external
document altogether by using data URIs instead of referencing an actual
external document:

http://www.w3.org/TR/html401/struct/objects.html#adef-data

http://en.wikipedia.org/wiki/Data:_URI_scheme

If authoring tools make creating master documents hard, I think that
highlights a flaw in the authoring tools in question, and the authoring
tools are likely to be a little easier to "fix" than consuming agents.
OpenDocuments consist of an archive of multiple resources, but the user
experience of editing an OpenDocument in OpenOffice.org is of editing a
seamless document.

Using HTML comments to hide stuff is generally a bad idea since comments
should be disposable and sometimes are discarded. There are cases where
that doesn't matter. For example, it doesn't matter when conditional
comments are used to serve different styles to IE are okay because, if
content has been kept separate from presentation, it should be possible
to use the browser's default CSS to achieve a usable presentation of the
document. Now there could be cases where using comments is worth the
risk even for data that is important to understanding a document, but I
don't really see sufficient advantages in this particular case to offset
the costs.

--
Benjamin Hawkes-Lewis

From pault at dessci.com  Sat Oct 27 08:46:30 2007
From: pault at dessci.com (Paul Topping)
Date: Sat Oct 27 08:46:44 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci><6FCC7A43-F782-487B-91A4-7A8566858814@makedatamakesense.com><D1EFB337111B674B8F1BE155B01C6DD6025CFC75@franklin.corp.dessci>
	<1193491473.10990.99.camel@galahad>
Message-ID: <D1EFB337111B674B8F1BE155B01C6DD6025CFDA1@franklin.corp.dessci>

For an explanation of why I'm looking to embed MathML and/or TeX in
HTML, I refer you to my original post for the details. The short answer
is that MathML is not a universal enough solution. I am aware of most of
what you mention below (especially the stuff about my own company's
products -- thanks!) and agree with it. Perhaps I should come at this
from a slightly different angle. 

Instead of addressing the successes and failures of MathML, let's look
at the many "solutions" to the equation display in a web page problem.
There are many websites that represent equations as images. They do this
because of the universal browser compatibility of HTML with equation
images. MathML is not a solution as it is not close to being universally
supported in browsers. This is a big issue in education which is usually
not in a position to dictate browsers and, perhaps more importantly,
doesn't want to embrace any solution that might require the user to
download plugins and/or fonts. Equation images are 100% reliable.

Pretty much all the equation images are produced by rendering TeX or
MathML using a variety of tools. In the case of TeX at least, this
textual representation is also potentially useful in the browser so some
math websites embed the TeX in alt text or as a comment. Many don't
expose this textual representation at all. 

If math websites embedded the TeX or MathML used to produce each
equation image in a standardized manner, it would enable client-side
software to provide math accessibility and interoperability. And, if it
could be done in a way that didn't interfere with other HTML features,
such as commandeering alt text away from its intended purpose, that
would be a win. Finally, it needs to be done in a rigorous way. For
example, if a certain version of LaTeX is used for the representation,
that should be declared so the s/w that processes the notation should
not have to sniff and guess. 

Paul Topping
Design Science, Inc.
www.dessci.com
 
> -----Original Message-----
> From: microformats-new-bounces@microformats.org [mailto:microformats-
> new-bounces@microformats.org] On Behalf Of Benjamin Hawkes-Lewis
> Sent: Saturday, October 27, 2007 6:25 AM
> To: For discussion of new microformats.
> Subject: RE: [uf-new] an equation/MathML/TeX microformat?
> 
> 
> On Thu, 2007-10-25 at 15:39 -0700, Paul Topping wrote:
> 
> > I'm aware of the effort to support MathML in HTML5 but this effort
> seems
> > unlikely to bear fruit. Besides, I'm looking to create something
that
> > will work in "plain old HTML" which, as I understand it, is part of
> the
> > microformat philosophy. As I stated, MathML was originally intended
to
> > be implemented in browsers but the actuality leaves something to be
> > desired. With HTML5, I would simply be waiting for yet another thing
> to
> > be implemented in browsers. Exactly what I want to avoid.
> 
> Personally, I believe wanting to use MathML is one of the rare
> use-cases that justifies choosing XHTML over HTML 4.01, in which case
> you can inline MathML directly into your markup.
> 
> Can you provide some more details about the problem you're trying to
> solve, in particular:
> 
> 1. What are the deficiencies of existing techniques for using
> mathematical markup in conjunction with HTML that you are
realistically
> expecting to overcome?
> 
> 2. What are the key existing consuming agents you'd like the solution
to
> those deficiencies to work with? e.g. What platforms, browsers, and
> assistive technology?
> 
> Currently, your company's MathPlayer ActiveX plugin can already speak
> maths and has MSAA support for assistive technology:
> 
> http://www.dessci.com/en/products/mathplayer/tech/accessibility.htm
> 
> Gecko has built-in support for a subset of MathML; the FireVox
extension
> turns Firefox into a self-voicing browser on all three major platforms
> and can read MathML using Abraham Nemeth's Mathspeak rules:
> 
> http://www.firevox.clcworld.net/features.html
> 
> The next version of Opera will include support for a subset of MathML
> and restore (some level of) support for assistive technologies on
> Windows and Mac:
> 
>
http://dev.opera.com/articles/view/can-kestrels-do-math-mathml-support-
> in/
> 
> http://my.opera.com/desktopteam/blog/2007/08/31/focus-areas-during-
> kestrel-development
> 
> The only major engine missing support for MathML at all is WebKit:
> 
> http://bugs.webkit.org/show_bug.cgi?id=3251
> 
> This situation could be a /lot/ better.
> 
> Your problem seems very similar to the problem of inlining RDF in
HTML:
> 
> http://infomesh.net/2002/rdfinhtml/
> 
> http://esw.w3.org/topic/EmbeddingRDFinHTML
> 
> The suggested approach of dumping XML markup inside comments was
> actually used by Creative Commons and Moveable Type's Trackback
system:
> 
> http://www.xml.com/pub/a/2003/01/15/creative.html
> 
> But I can't really see how embedding MathML markup inside HTML
comments
> is supposed to improve things with existing (or even future) consuming
> agents. You did say this:
> 
> > Also, I want to put the MathML or TeX in the page, not in separate
> > documents. Typical pages with math in them might have dozens of
> > equations. Having their representation in separate files is
> > inefficient but perhaps the biggest problem is that it makes
authoring
> > a lot more tedious as lots of small files have to be managed.
> 
> The web stack tends to work by stitching together lots of different
> resources to make up the final presentation the user experiences when
> she visits a URI: multiple HTML documents, scripts, stylesheets,
images,
> Flash movies, and so on all get bound together by a master document.
I'm
> generally sceptical about attempts to fight against this model in the
> name of efficiency without changing the HTML specification itself.
> 
> There's also an issue of efficiency for consuming agents that don't
> support MathML and would have to waste bandwidth on MathML embedded in
> comments.
> 
> Having said that, additional requests are more expensive than
additional
> bytes. But even if you have to externalize MathML outside the main
HTML
> document, you could (I guess) cut down the additional requests to just
> one by using fragment identifiers to pinpoint individual equations in
an
> XML document containing a series of equations. You could even make the
> referenced document an XHTML version of the HTML document, and use a
> <link rel="alternate" type="application/xhtml+xml"> element to point
to
> the XHTML version from the HEAD of the HTML version, and use the HTML
> HREF and LONGDESC attributes to point to fragment identifiers for
> particular equations. HTTP content negotiation could perhaps be used
to
> send supporting consuming agents to the XHTML version in the first
> place.
> 
> For very short equations, you might be able to do away with the
external
> document altogether by using data URIs instead of referencing an
actual
> external document:
> 
> http://www.w3.org/TR/html401/struct/objects.html#adef-data
> 
> http://en.wikipedia.org/wiki/Data:_URI_scheme
> 
> If authoring tools make creating master documents hard, I think that
> highlights a flaw in the authoring tools in question, and the
authoring
> tools are likely to be a little easier to "fix" than consuming agents.
> OpenDocuments consist of an archive of multiple resources, but the
user
> experience of editing an OpenDocument in OpenOffice.org is of editing
a
> seamless document.
> 
> Using HTML comments to hide stuff is generally a bad idea since
comments
> should be disposable and sometimes are discarded. There are cases
where
> that doesn't matter. For example, it doesn't matter when conditional
> comments are used to serve different styles to IE are okay because, if
> content has been kept separate from presentation, it should be
possible
> to use the browser's default CSS to achieve a usable presentation of
the
> document. Now there could be cases where using comments is worth the
> risk even for data that is important to understanding a document, but
I
> don't really see sufficient advantages in this particular case to
offset
> the costs.
> 
> --
> Benjamin Hawkes-Lewis
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From bhawkeslewis at googlemail.com  Sat Oct 27 10:45:01 2007
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Sat Oct 27 10:45:06 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
In-Reply-To: <D1EFB337111B674B8F1BE155B01C6DD6025CFDA1@franklin.corp.dessci>
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci>
	<6FCC7A43-F782-487B-91A4-7A8566858814@makedatamakesense.com>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFC75@franklin.corp.dessci>
	<1193491473.10990.99.camel@galahad>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFDA1@franklin.corp.dessci>
Message-ID: <1193507101.12656.9.camel@galahad>

On Sat, 2007-10-27 at 08:46 -0700, Paul Topping wrote: 
> Perhaps I should come at this from a slightly different angle. 

Thanks for the second explanation. I've also just found your helpful
earlier reply, which I'm afraid I missed earlier, where you discuss
copying TeX/MathML data out of webpages and into MathML applications as
the main deliverable.

So would this be a fair outline of your goals?

1. Images are used to display equations in an HTML document.
2. The alternative text for the image is human-readable.
3. Latex/MathML data is associated with the equation image.
4. The Latex/MathML data is normally invisible.
5. The Latex/MathML data is inline in the HTML master document, not in
separate resource(s).
6. The user can discover and copy the data to the clipboard.
7. No browser add-on is required to discover and copy the data.
8. Works with all mainstream (by which I mean "A-grade" as defined by
http://developer.yahoo.com/yui/articles/gbs/) browsers.

These goals are tricky since browsers tend to focus on allowing users to
manipulate and copy visible not invisible data. And microformats tend to
rely on browser add-ons like the Operator toolbar to enable users to
extract data structured by microformats. So it seems to me that the big
question is this: what invisible data /do/ browsers allow easy access
to? All browsers seem to provide access to anchor URIs, and the
resources they reference. Christopher St John already suggested:

<a href="some_mathml.xml"><img src="some_math.png"></a>

In that scenario, users could right click on the equation image,
download a MathML file to their Desktop, and then open the MathML file
in their MathML software. Perhaps in some cases they could even drag the
anchor and drop the URI directly onto their MathML software.

If the MathML software you have in mind can actually process a URI,
rather than relying on browsers to download the resource for it, then it
might be possible to use data URIs or reference fragments of a MathML
document full of equations. Then users could right-click on the anchors,
copy the URIs to the clipboard, and paste them into their MathML
software. I'm guessing that MathML software can't be counted on to be
able to open URIs, in which case Christopher St John's solution would
probably be more practical. One of your objections was:

> What you suggest is close to what I'm looking for but lacks
> declaration
> of the kind of data the image/linked data bundle represents. Software
> working with the page would have to fetch the linked-to MathML or TeX
> and examine it to know it was an equation. As I understand it, what a
> microformat does is more than just hold the data, it declares a
> datatype. 
> 
That certainly sounds like something microformats could help with. :) At
the very crudest:

<span class="hequation"><a rel="equation" href="your-equation.xml"
type="application/xhtml+xml"><img alt="energy equals mass times velocity
squared" src="your-equation.png"></a></span>

Where the equation makes for too long or complex an alt, alt could
briefly describe the equation and longdesc could be used to point to a
document containing a full alternative (your-equation.html).

If you need to provide both MathML /and/ TeX versions you'd probably
need to provide little icons and hequation could scale to do that:

<span class="hequation"><img alt="energy equals mass times velocity
squared" src="your-equation.png"> (<a rel="equation"
href="your-equation.xml" type="application/xhtml+xml"><img
href="mathml.gif" alt="MathML for equation 5" title="MathML
version"></a>, <a href="your-equation.tex" type="text/tex"><img
href="mathml.gif" alt="TeX for equation 5" title="TeX
version"></a>)</span>

Such a microformat could also be the basis of online tools that look for
hequation anchors, extract all the equations from a URI or uploaded
document, and make a DL providing the MathML and TeX CODE blocks for
each IMG.

Except for the possibility of using data URIs, this suggestion doesn't
meet Goal 5 ("The Latex/MathML data is inline in the HTML master
document, not in separate resource(s)"). But it does meet the other
goals I attempted to itemize.

--
Benjamin Hawkes-Lewis

From james at howison.name  Sat Oct 27 10:46:46 2007
From: james at howison.name (James Howison)
Date: Sat Oct 27 10:47:05 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
In-Reply-To: <D1EFB337111B674B8F1BE155B01C6DD6025CFDA1@franklin.corp.dessci>
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci><6FCC7A43-F782-487B-91A4-7A8566858814@makedatamakesense.com><D1EFB337111B674B8F1BE155B01C6DD6025CFC75@franklin.corp.dessci>
	<1193491473.10990.99.camel@galahad>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFDA1@franklin.corp.dessci>
Message-ID: <14BE6323-4782-425A-9817-9C25E1D944AC@howison.name>

Since you are focusing on image files always being present ("Equation  
images are 100% reliable") would another option be to encode the  
MathML or TeX into the image file, then use a class name to indicate  
that this image should be parsed to look for the data.

eg stick it into the Description or Comment field (or make your own  
field keyword) in a PNG file:

http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.Anc-text

That could be added to some of the commonly used MathML->PNG or TeX- 
 >PNG tools.  eg

http://redsymbol.net/software/l2p/dist/l2p-doc.html

Then you could use something like:

<img class="parse-image-for-mathml" alt="natural language description  
of forumla" src="image-with-embedded-MathML.png" />

Of course this would need a tool to read the text out from the image  
file, but those are widely available. Client side applications that  
supported MathML could even read the MathML out of the image and  
replace the PNG with the preferred MathML content.

Yeah, it wouldn't be in the HTML file, but you'd almost always also  
have to download the image representation, no?

It would have the advantage of being able to be easily emailed too :)

--J

On Oct 27, 2007, at 11:46 AM, Paul Topping wrote:

> For an explanation of why I'm looking to embed MathML and/or TeX in
> HTML, I refer you to my original post for the details. The short  
> answer
> is that MathML is not a universal enough solution. I am aware of  
> most of
> what you mention below (especially the stuff about my own company's
> products -- thanks!) and agree with it. Perhaps I should come at this
> from a slightly different angle.
>
> Instead of addressing the successes and failures of MathML, let's look
> at the many "solutions" to the equation display in a web page problem.
> There are many websites that represent equations as images. They do  
> this
> because of the universal browser compatibility of HTML with equation
> images. MathML is not a solution as it is not close to being  
> universally
> supported in browsers. This is a big issue in education which is  
> usually
> not in a position to dictate browsers and, perhaps more importantly,
> doesn't want to embrace any solution that might require the user to
> download plugins and/or fonts. Equation images are 100% reliable.
>
> Pretty much all the equation images are produced by rendering TeX or
> MathML using a variety of tools. In the case of TeX at least, this
> textual representation is also potentially useful in the browser so  
> some
> math websites embed the TeX in alt text or as a comment. Many don't
> expose this textual representation at all.
>
> If math websites embedded the TeX or MathML used to produce each
> equation image in a standardized manner, it would enable client-side
> software to provide math accessibility and interoperability. And,  
> if it
> could be done in a way that didn't interfere with other HTML features,
> such as commandeering alt text away from its intended purpose, that
> would be a win. Finally, it needs to be done in a rigorous way. For
> example, if a certain version of LaTeX is used for the representation,
> that should be declared so the s/w that processes the notation should
> not have to sniff and guess.
>
> Paul Topping
> Design Science, Inc.
> www.dessci.com
>
>> -----Original Message-----
>> From: microformats-new-bounces@microformats.org [mailto:microformats-
>> new-bounces@microformats.org] On Behalf Of Benjamin Hawkes-Lewis
>> Sent: Saturday, October 27, 2007 6:25 AM
>> To: For discussion of new microformats.
>> Subject: RE: [uf-new] an equation/MathML/TeX microformat?
>>
>>
>> On Thu, 2007-10-25 at 15:39 -0700, Paul Topping wrote:
>>
>>> I'm aware of the effort to support MathML in HTML5 but this effort
>> seems
>>> unlikely to bear fruit. Besides, I'm looking to create something
> that
>>> will work in "plain old HTML" which, as I understand it, is part of
>> the
>>> microformat philosophy. As I stated, MathML was originally intended
> to
>>> be implemented in browsers but the actuality leaves something to be
>>> desired. With HTML5, I would simply be waiting for yet another thing
>> to
>>> be implemented in browsers. Exactly what I want to avoid.
>>
>> Personally, I believe wanting to use MathML is one of the rare
>> use-cases that justifies choosing XHTML over HTML 4.01, in which case
>> you can inline MathML directly into your markup.
>>
>> Can you provide some more details about the problem you're trying to
>> solve, in particular:
>>
>> 1. What are the deficiencies of existing techniques for using
>> mathematical markup in conjunction with HTML that you are
> realistically
>> expecting to overcome?
>>
>> 2. What are the key existing consuming agents you'd like the solution
> to
>> those deficiencies to work with? e.g. What platforms, browsers, and
>> assistive technology?
>>
>> Currently, your company's MathPlayer ActiveX plugin can already speak
>> maths and has MSAA support for assistive technology:
>>
>> http://www.dessci.com/en/products/mathplayer/tech/accessibility.htm
>>
>> Gecko has built-in support for a subset of MathML; the FireVox
> extension
>> turns Firefox into a self-voicing browser on all three major  
>> platforms
>> and can read MathML using Abraham Nemeth's Mathspeak rules:
>>
>> http://www.firevox.clcworld.net/features.html
>>
>> The next version of Opera will include support for a subset of MathML
>> and restore (some level of) support for assistive technologies on
>> Windows and Mac:
>>
>>
> http://dev.opera.com/articles/view/can-kestrels-do-math-mathml- 
> support-
>> in/
>>
>> http://my.opera.com/desktopteam/blog/2007/08/31/focus-areas-during-
>> kestrel-development
>>
>> The only major engine missing support for MathML at all is WebKit:
>>
>> http://bugs.webkit.org/show_bug.cgi?id=3251
>>
>> This situation could be a /lot/ better.
>>
>> Your problem seems very similar to the problem of inlining RDF in
> HTML:
>>
>> http://infomesh.net/2002/rdfinhtml/
>>
>> http://esw.w3.org/topic/EmbeddingRDFinHTML
>>
>> The suggested approach of dumping XML markup inside comments was
>> actually used by Creative Commons and Moveable Type's Trackback
> system:
>>
>> http://www.xml.com/pub/a/2003/01/15/creative.html
>>
>> But I can't really see how embedding MathML markup inside HTML
> comments
>> is supposed to improve things with existing (or even future)  
>> consuming
>> agents. You did say this:
>>
>>> Also, I want to put the MathML or TeX in the page, not in separate
>>> documents. Typical pages with math in them might have dozens of
>>> equations. Having their representation in separate files is
>>> inefficient but perhaps the biggest problem is that it makes
> authoring
>>> a lot more tedious as lots of small files have to be managed.
>>
>> The web stack tends to work by stitching together lots of different
>> resources to make up the final presentation the user experiences when
>> she visits a URI: multiple HTML documents, scripts, stylesheets,
> images,
>> Flash movies, and so on all get bound together by a master document.
> I'm
>> generally sceptical about attempts to fight against this model in the
>> name of efficiency without changing the HTML specification itself.
>>
>> There's also an issue of efficiency for consuming agents that don't
>> support MathML and would have to waste bandwidth on MathML  
>> embedded in
>> comments.
>>
>> Having said that, additional requests are more expensive than
> additional
>> bytes. But even if you have to externalize MathML outside the main
> HTML
>> document, you could (I guess) cut down the additional requests to  
>> just
>> one by using fragment identifiers to pinpoint individual equations in
> an
>> XML document containing a series of equations. You could even make  
>> the
>> referenced document an XHTML version of the HTML document, and use a
>> <link rel="alternate" type="application/xhtml+xml"> element to point
> to
>> the XHTML version from the HEAD of the HTML version, and use the HTML
>> HREF and LONGDESC attributes to point to fragment identifiers for
>> particular equations. HTTP content negotiation could perhaps be used
> to
>> send supporting consuming agents to the XHTML version in the first
>> place.
>>
>> For very short equations, you might be able to do away with the
> external
>> document altogether by using data URIs instead of referencing an
> actual
>> external document:
>>
>> http://www.w3.org/TR/html401/struct/objects.html#adef-data
>>
>> http://en.wikipedia.org/wiki/Data:_URI_scheme
>>
>> If authoring tools make creating master documents hard, I think that
>> highlights a flaw in the authoring tools in question, and the
> authoring
>> tools are likely to be a little easier to "fix" than consuming  
>> agents.
>> OpenDocuments consist of an archive of multiple resources, but the
> user
>> experience of editing an OpenDocument in OpenOffice.org is of editing
> a
>> seamless document.
>>
>> Using HTML comments to hide stuff is generally a bad idea since
> comments
>> should be disposable and sometimes are discarded. There are cases
> where
>> that doesn't matter. For example, it doesn't matter when conditional
>> comments are used to serve different styles to IE are okay  
>> because, if
>> content has been kept separate from presentation, it should be
> possible
>> to use the browser's default CSS to achieve a usable presentation of
> the
>> document. Now there could be cases where using comments is worth the
>> risk even for data that is important to understanding a document, but
> I
>> don't really see sufficient advantages in this particular case to
> offset
>> the costs.
>>
>> --
>> Benjamin Hawkes-Lewis
>>
>> _______________________________________________
>> microformats-new mailing list
>> microformats-new@microformats.org
>> http://microformats.org/mailman/listinfo/microformats-new
>
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
>

From pault at dessci.com  Sat Oct 27 11:01:13 2007
From: pault at dessci.com (Paul Topping)
Date: Sat Oct 27 11:01:18 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci><6FCC7A43-F782-487B-91A4-7A8566858814@makedatamakesense.com><D1EFB337111B674B8F1BE155B01C6DD6025CFC75@franklin.corp.dessci><1193491473.10990.99.camel@galahad><D1EFB337111B674B8F1BE155B01C6DD6025CFDA1@franklin.corp.dessci>
	<14BE6323-4782-425A-9817-9C25E1D944AC@howison.name>
Message-ID: <D1EFB337111B674B8F1BE155B01C6DD6025CFDA5@franklin.corp.dessci>

Yes, that's a good idea. In fact, our products already do embed this
kind of data in the equation images they produce. However, to make it a
useful standard, I have to convince the makers of many other products
and websites to do the same. Somehow it seems like an easier task to
convince them to change their HTML but perhaps it amounts to the same
thing. Is it practical for client-side script code to extract MathML or
TeX embedded in an image this way? 

Paul

> -----Original Message-----
> From: microformats-new-bounces@microformats.org [mailto:microformats-
> new-bounces@microformats.org] On Behalf Of James Howison
> Sent: Saturday, October 27, 2007 10:47 AM
> To: For discussion of new microformats.
> Subject: Re: [uf-new] an equation/MathML/TeX microformat?
> 
> Since you are focusing on image files always being present ("Equation
> images are 100% reliable") would another option be to encode the
> MathML or TeX into the image file, then use a class name to indicate
> that this image should be parsed to look for the data.
> 
> eg stick it into the Description or Comment field (or make your own
> field keyword) in a PNG file:
> 
> http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.Anc-text
> 
> That could be added to some of the commonly used MathML->PNG or TeX-
>  >PNG tools.  eg
> 
> http://redsymbol.net/software/l2p/dist/l2p-doc.html
> 
> Then you could use something like:
> 
> <img class="parse-image-for-mathml" alt="natural language description
> of forumla" src="image-with-embedded-MathML.png" />
> 
> Of course this would need a tool to read the text out from the image
> file, but those are widely available. Client side applications that
> supported MathML could even read the MathML out of the image and
> replace the PNG with the preferred MathML content.
> 
> Yeah, it wouldn't be in the HTML file, but you'd almost always also
> have to download the image representation, no?
> 
> It would have the advantage of being able to be easily emailed too :)
> 
> --J
> 
> On Oct 27, 2007, at 11:46 AM, Paul Topping wrote:
> 
> > For an explanation of why I'm looking to embed MathML and/or TeX in
> > HTML, I refer you to my original post for the details. The short
> > answer
> > is that MathML is not a universal enough solution. I am aware of
> > most of
> > what you mention below (especially the stuff about my own company's
> > products -- thanks!) and agree with it. Perhaps I should come at
this
> > from a slightly different angle.
> >
> > Instead of addressing the successes and failures of MathML, let's
look
> > at the many "solutions" to the equation display in a web page
problem.
> > There are many websites that represent equations as images. They do
> > this
> > because of the universal browser compatibility of HTML with equation
> > images. MathML is not a solution as it is not close to being
> > universally
> > supported in browsers. This is a big issue in education which is
> > usually
> > not in a position to dictate browsers and, perhaps more importantly,
> > doesn't want to embrace any solution that might require the user to
> > download plugins and/or fonts. Equation images are 100% reliable.
> >
> > Pretty much all the equation images are produced by rendering TeX or
> > MathML using a variety of tools. In the case of TeX at least, this
> > textual representation is also potentially useful in the browser so
> > some
> > math websites embed the TeX in alt text or as a comment. Many don't
> > expose this textual representation at all.
> >
> > If math websites embedded the TeX or MathML used to produce each
> > equation image in a standardized manner, it would enable client-side
> > software to provide math accessibility and interoperability. And,
> > if it
> > could be done in a way that didn't interfere with other HTML
features,
> > such as commandeering alt text away from its intended purpose, that
> > would be a win. Finally, it needs to be done in a rigorous way. For
> > example, if a certain version of LaTeX is used for the
representation,
> > that should be declared so the s/w that processes the notation
should
> > not have to sniff and guess.
> >
> > Paul Topping
> > Design Science, Inc.
> > www.dessci.com
> >
> >> -----Original Message-----
> >> From: microformats-new-bounces@microformats.org
[mailto:microformats-
> >> new-bounces@microformats.org] On Behalf Of Benjamin Hawkes-Lewis
> >> Sent: Saturday, October 27, 2007 6:25 AM
> >> To: For discussion of new microformats.
> >> Subject: RE: [uf-new] an equation/MathML/TeX microformat?
> >>
> >>
> >> On Thu, 2007-10-25 at 15:39 -0700, Paul Topping wrote:
> >>
> >>> I'm aware of the effort to support MathML in HTML5 but this effort
> >> seems
> >>> unlikely to bear fruit. Besides, I'm looking to create something
> > that
> >>> will work in "plain old HTML" which, as I understand it, is part
of
> >> the
> >>> microformat philosophy. As I stated, MathML was originally
intended
> > to
> >>> be implemented in browsers but the actuality leaves something to
be
> >>> desired. With HTML5, I would simply be waiting for yet another
thing
> >> to
> >>> be implemented in browsers. Exactly what I want to avoid.
> >>
> >> Personally, I believe wanting to use MathML is one of the rare
> >> use-cases that justifies choosing XHTML over HTML 4.01, in which
case
> >> you can inline MathML directly into your markup.
> >>
> >> Can you provide some more details about the problem you're trying
to
> >> solve, in particular:
> >>
> >> 1. What are the deficiencies of existing techniques for using
> >> mathematical markup in conjunction with HTML that you are
> > realistically
> >> expecting to overcome?
> >>
> >> 2. What are the key existing consuming agents you'd like the
solution
> > to
> >> those deficiencies to work with? e.g. What platforms, browsers, and
> >> assistive technology?
> >>
> >> Currently, your company's MathPlayer ActiveX plugin can already
speak
> >> maths and has MSAA support for assistive technology:
> >>
> >> http://www.dessci.com/en/products/mathplayer/tech/accessibility.htm
> >>
> >> Gecko has built-in support for a subset of MathML; the FireVox
> > extension
> >> turns Firefox into a self-voicing browser on all three major
> >> platforms
> >> and can read MathML using Abraham Nemeth's Mathspeak rules:
> >>
> >> http://www.firevox.clcworld.net/features.html
> >>
> >> The next version of Opera will include support for a subset of
MathML
> >> and restore (some level of) support for assistive technologies on
> >> Windows and Mac:
> >>
> >>
> > http://dev.opera.com/articles/view/can-kestrels-do-math-mathml-
> > support-
> >> in/
> >>
> >> http://my.opera.com/desktopteam/blog/2007/08/31/focus-areas-during-
> >> kestrel-development
> >>
> >> The only major engine missing support for MathML at all is WebKit:
> >>
> >> http://bugs.webkit.org/show_bug.cgi?id=3251
> >>
> >> This situation could be a /lot/ better.
> >>
> >> Your problem seems very similar to the problem of inlining RDF in
> > HTML:
> >>
> >> http://infomesh.net/2002/rdfinhtml/
> >>
> >> http://esw.w3.org/topic/EmbeddingRDFinHTML
> >>
> >> The suggested approach of dumping XML markup inside comments was
> >> actually used by Creative Commons and Moveable Type's Trackback
> > system:
> >>
> >> http://www.xml.com/pub/a/2003/01/15/creative.html
> >>
> >> But I can't really see how embedding MathML markup inside HTML
> > comments
> >> is supposed to improve things with existing (or even future)
> >> consuming
> >> agents. You did say this:
> >>
> >>> Also, I want to put the MathML or TeX in the page, not in separate
> >>> documents. Typical pages with math in them might have dozens of
> >>> equations. Having their representation in separate files is
> >>> inefficient but perhaps the biggest problem is that it makes
> > authoring
> >>> a lot more tedious as lots of small files have to be managed.
> >>
> >> The web stack tends to work by stitching together lots of different
> >> resources to make up the final presentation the user experiences
when
> >> she visits a URI: multiple HTML documents, scripts, stylesheets,
> > images,
> >> Flash movies, and so on all get bound together by a master
document.
> > I'm
> >> generally sceptical about attempts to fight against this model in
the
> >> name of efficiency without changing the HTML specification itself.
> >>
> >> There's also an issue of efficiency for consuming agents that don't
> >> support MathML and would have to waste bandwidth on MathML
> >> embedded in
> >> comments.
> >>
> >> Having said that, additional requests are more expensive than
> > additional
> >> bytes. But even if you have to externalize MathML outside the main
> > HTML
> >> document, you could (I guess) cut down the additional requests to
> >> just
> >> one by using fragment identifiers to pinpoint individual equations
in
> > an
> >> XML document containing a series of equations. You could even make
> >> the
> >> referenced document an XHTML version of the HTML document, and use
a
> >> <link rel="alternate" type="application/xhtml+xml"> element to
point
> > to
> >> the XHTML version from the HEAD of the HTML version, and use the
HTML
> >> HREF and LONGDESC attributes to point to fragment identifiers for
> >> particular equations. HTTP content negotiation could perhaps be
used
> > to
> >> send supporting consuming agents to the XHTML version in the first
> >> place.
> >>
> >> For very short equations, you might be able to do away with the
> > external
> >> document altogether by using data URIs instead of referencing an
> > actual
> >> external document:
> >>
> >> http://www.w3.org/TR/html401/struct/objects.html#adef-data
> >>
> >> http://en.wikipedia.org/wiki/Data:_URI_scheme
> >>
> >> If authoring tools make creating master documents hard, I think
that
> >> highlights a flaw in the authoring tools in question, and the
> > authoring
> >> tools are likely to be a little easier to "fix" than consuming
> >> agents.
> >> OpenDocuments consist of an archive of multiple resources, but the
> > user
> >> experience of editing an OpenDocument in OpenOffice.org is of
editing
> > a
> >> seamless document.
> >>
> >> Using HTML comments to hide stuff is generally a bad idea since
> > comments
> >> should be disposable and sometimes are discarded. There are cases
> > where
> >> that doesn't matter. For example, it doesn't matter when
conditional
> >> comments are used to serve different styles to IE are okay
> >> because, if
> >> content has been kept separate from presentation, it should be
> > possible
> >> to use the browser's default CSS to achieve a usable presentation
of
> > the
> >> document. Now there could be cases where using comments is worth
the
> >> risk even for data that is important to understanding a document,
but
> > I
> >> don't really see sufficient advantages in this particular case to
> > offset
> >> the costs.
> >>
> >> --
> >> Benjamin Hawkes-Lewis
> >>
> >> _______________________________________________
> >> microformats-new mailing list
> >> microformats-new@microformats.org
> >> http://microformats.org/mailman/listinfo/microformats-new
> >
> > _______________________________________________
> > microformats-new mailing list
> > microformats-new@microformats.org
> > http://microformats.org/mailman/listinfo/microformats-new
> >
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From bhawkeslewis at googlemail.com  Sat Oct 27 12:03:59 2007
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Sat Oct 27 12:04:05 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
In-Reply-To: <D1EFB337111B674B8F1BE155B01C6DD6025CFDA5@franklin.corp.dessci>
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci>
	<6FCC7A43-F782-487B-91A4-7A8566858814@makedatamakesense.com>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFC75@franklin.corp.dessci>
	<1193491473.10990.99.camel@galahad>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFDA1@franklin.corp.dessci>
	<14BE6323-4782-425A-9817-9C25E1D944AC@howison.name>
	<D1EFB337111B674B8F1BE155B01C6DD6025CFDA5@franklin.corp.dessci>
Message-ID: <1193511839.5926.13.camel@galahad>

James Howison's idea is very neat.

I think it might probably be difficult to write cross-browser,
performant JavaScript that parses the PNG bytes for this data, and it
would introduce an undesirable dependency on users having JS enabled
that may be unrealistic in educational settings. But it would probably
be comparatively easy to write a webservice that does the same thing and
returns an XML representation that can be downloaded:

<span class="hequation"><a rel="equation"
href="http://webservice.example.org/png2mathml.php?uri=http%
3A//images.example.com/345.png" type="application/xhtml+xml"><img
alt="energy equals mass times velocity squared"
src="http://images.example.com/345.png" type="image/png"></a></span>

Now you could layer some JavaScript on top of that which collects all
the hequation IMG source URIs, rolls them up into a single request to
the webservice, and receives back a MathML document into memory. But I'm
not clear how you'd like the script to expose the resulting information
to the end user. Intercepting attempts to copy the image to the
clipboard would probably be problematic, both in terms of how to achieve
it and in terms of confusing end users. Adding items to the context menu
would be nice, but very hard to do with JavaScript. So adding little
icons after each equation might be a better bet.

If developers of other MathML software could be persuaded to parse data
from images, that would be good. But I think it's important to have a
link to MathML serialization within the HTML layer, given the existence
of multiple browsers and assistive technologies that can cope with
MathML (at least to some degree).

--
Benjamin Hawkes-Lewis

From pault at dessci.com  Sat Oct 27 12:18:57 2007
From: pault at dessci.com (Paul Topping)
Date: Sat Oct 27 12:19:01 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
References: <D1EFB337111B674B8F1BE155B01C6DD6025CFB60@franklin.corp.dessci><6FCC7A43-F782-487B-91A4-7A8566858814@makedatamakesense.com><D1EFB337111B674B8F1BE155B01C6DD6025CFC75@franklin.corp.dessci><1193491473.10990.99.camel@galahad><D1EFB337111B674B8F1BE155B01C6DD6025CFDA1@franklin.corp.dessci><14BE6323-4782-425A-9817-9C25E1D944AC@howison.name><D1EFB337111B674B8F1BE155B01C6DD6025CFDA5@franklin.corp.dessci>
	<1193511839.5926.13.camel@galahad>
Message-ID: <D1EFB337111B674B8F1BE155B01C6DD6025CFDA6@franklin.corp.dessci>

Yes, these are all good ideas. The web service idea is especially
intriguing though the need to service a request to get at the data
probably makes it about as performant as parsing images with JS. As to
whether education is ok with enabling JS, I think that's ok. One can do
so little in pages these days if scripting is disabled.

Paul

> -----Original Message-----
> From: microformats-new-bounces@microformats.org [mailto:microformats-
> new-bounces@microformats.org] On Behalf Of Benjamin Hawkes-Lewis
> Sent: Saturday, October 27, 2007 12:04 PM
> To: For discussion of new microformats.
> Subject: RE: [uf-new] an equation/MathML/TeX microformat?
> 
> James Howison's idea is very neat.
> 
> I think it might probably be difficult to write cross-browser,
> performant JavaScript that parses the PNG bytes for this data, and it
> would introduce an undesirable dependency on users having JS enabled
> that may be unrealistic in educational settings. But it would probably
> be comparatively easy to write a webservice that does the same thing
and
> returns an XML representation that can be downloaded:
> 
> <span class="hequation"><a rel="equation"
> href="http://webservice.example.org/png2mathml.php?uri=http%
> 3A//images.example.com/345.png" type="application/xhtml+xml"><img
> alt="energy equals mass times velocity squared"
> src="http://images.example.com/345.png" type="image/png"></a></span>
> 
> Now you could layer some JavaScript on top of that which collects all
> the hequation IMG source URIs, rolls them up into a single request to
> the webservice, and receives back a MathML document into memory. But
I'm
> not clear how you'd like the script to expose the resulting
information
> to the end user. Intercepting attempts to copy the image to the
> clipboard would probably be problematic, both in terms of how to
achieve
> it and in terms of confusing end users. Adding items to the context
menu
> would be nice, but very hard to do with JavaScript. So adding little
> icons after each equation might be a better bet.
> 
> If developers of other MathML software could be persuaded to parse
data
> from images, that would be good. But I think it's important to have a
> link to MathML serialization within the HTML layer, given the
existence
> of multiple browsers and assistive technologies that can cope with
> MathML (at least to some degree).
> 
> --
> Benjamin Hawkes-Lewis
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From paul_wilkins at xtra.co.nz  Sat Oct 27 16:17:22 2007
From: paul_wilkins at xtra.co.nz (paul_wilkins@xtra.co.nz)
Date: Sat Oct 27 16:17:27 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
Message-ID: <608799.94562.qm@web96012.mail.aue.yahoo.com>

From: Paul Topping <pault@dessci.com>
> Instead of addressing the successes and failures of MathML, let's look
> at the many "solutions" to the equation display in a web page problem.
> There are many websites that represent equations as images. They do this
> because of the universal browser compatibility of HTML with equation
> images. MathML is not a solution as it is not close to being universally
> supported in browsers. This is a big issue in education which is usually
> not in a position to dictate browsers and, perhaps more importantly,
> doesn't want to embrace any solution that might require the user to
> download plugins and/or fonts. Equation images are 100% reliable.

Education places didn't want to enable javascript on their browsers because that gave the illusion of greater protection.
Now they have and they are more the richer from the experience.

MathML is a really good answer to the problem of displaying equations on the web, but it won't be more widely used until it's more widely used. There was a similar dilemma with shockwave flash, there has been an ongoing issue with support for various browsers, and there is beginning to be one once again with AJAX powered sites.

With all of these, the consensus has been to use the more advanced technology, but allow the user to use a lesser form should they desire.

MathML has to be the primary notation, otherwise it just won't make any ground at all. The TEX format if available can be incorporated as a title attribute, or even in plain text on the screen, with a link to a normal image for greater accessibility.

Anyone who uses MathML regularly will have the greatest incentive to update what's required so that they become able to use it. Those who occasionally use MathML will realise after a few experiences that doing some minor updates to their machine will bring greater usability for them.

If on the other hand we display images first and the more useful information elsewhere, what incentive is there to hunt out that other information. There is none.

The MathML standard has been around for long enough now, it's about time to start using it properly.


-- 
Paul Wilkins




From pault at dessci.com  Sat Oct 27 16:38:45 2007
From: pault at dessci.com (Paul Topping)
Date: Sat Oct 27 16:38:54 2007
Subject: [uf-new] an equation/MathML/TeX microformat?
References: <608799.94562.qm@web96012.mail.aue.yahoo.com>
Message-ID: <D1EFB337111B674B8F1BE155B01C6DD6025CFDAA@franklin.corp.dessci>

Yes, MathML is the "right" way to do equations, but after a decade of
waiting it's time to go with what actually works. That said, even if we
come up with a standard for associating MathML and TeX with images, I'm
not going to stop pushing for MathML. Equations displayed (and spoken)
directly from embedded MathML in the web page will have a number of
advantages over any other scheme. Just off the top of my head, they
include:

- The font used in the equation can be made to match that of the
surrounding text in face, size, color, etc.

- When the page is zoomed, the equation display won't look pixelated as
with a blown up bitmap.

- Client-side scripting can modify the equation and it will update
accordingly.

- When spoken, sub-expressions may be highlighted in synchrony.

A good way to go for website designers is to do server-side browser
detection to detect MathML support. If present, a page containing MathML
equations may be returned. Otherwise, a page with equation images and
attached or embedded MathML should be returned.

Paul Topping
Design Science, Inc.
www.dessci.com
 

> -----Original Message-----
> From: microformats-new-bounces@microformats.org [mailto:microformats-
> new-bounces@microformats.org] On Behalf Of paul_wilkins@xtra.co.nz
> Sent: Saturday, October 27, 2007 4:17 PM
> To: For discussion of new microformats.
> Subject: Re: [uf-new] an equation/MathML/TeX microformat?
> 
> From: Paul Topping <pault@dessci.com>
> > Instead of addressing the successes and failures of MathML, let's
look
> > at the many "solutions" to the equation display in a web page
problem.
> > There are many websites that represent equations as images. They do
> this
> > because of the universal browser compatibility of HTML with equation
> > images. MathML is not a solution as it is not close to being
> universally
> > supported in browsers. This is a big issue in education which is
> usually
> > not in a position to dictate browsers and, perhaps more importantly,
> > doesn't want to embrace any solution that might require the user to
> > download plugins and/or fonts. Equation images are 100% reliable.
> 
> Education places didn't want to enable javascript on their browsers
> because that gave the illusion of greater protection.
> Now they have and they are more the richer from the experience.
> 
> MathML is a really good answer to the problem of displaying equations
on
> the web, but it won't be more widely used until it's more widely used.
> There was a similar dilemma with shockwave flash, there has been an
> ongoing issue with support for various browsers, and there is
beginning
> to be one once again with AJAX powered sites.
> 
> With all of these, the consensus has been to use the more advanced
> technology, but allow the user to use a lesser form should they
desire.
> 
> MathML has to be the primary notation, otherwise it just won't make
any
> ground at all. The TEX format if available can be incorporated as a
> title attribute, or even in plain text on the screen, with a link to a
> normal image for greater accessibility.
> 
> Anyone who uses MathML regularly will have the greatest incentive to
> update what's required so that they become able to use it. Those who
> occasionally use MathML will realise after a few experiences that
doing
> some minor updates to their machine will bring greater usability for
> them.
> 
> If on the other hand we display images first and the more useful
> information elsewhere, what incentive is there to hunt out that other
> information. There is none.
> 
> The MathML standard has been around for long enough now, it's about
time
> to start using it properly.
> 
> 
> --
> Paul Wilkins
> 
> 
> 
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From msporny at digitalbazaar.com  Sun Oct 28 18:23:58 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Sun Oct 28 18:24:02 2007
Subject: [uf-new] hAudio ITEM debate proposal #3
Message-ID: <4725443E.8070303@digitalbazaar.com>

This is a follow-up to a previous attempt at resolving the hAudio
track/item debate:

http://microformats.org/discuss/mail/microformats-new/2007-October/001150.html

Brian Suda and I spent quite a bit of time talking about alternatives
and it seems that his disagreement with the previous approach was
largely due to implementation requirements. The end result of our
discussion had more to do with implementation than a change in markup.

While we didn't agree on everything, there was a common thread in the
ideas that allow us to move forward. Namely, if we focus on the
following, we should reach agreement:

 * Not prematurely optimizing hAudio.
 * Use ITEM and not ITEM+HAUDIO.

PROPOSAL:

HAUDIO parts are denoted by ITEM:
   <span class="item"><span class="fn">Track Name</span></span>

EXAMPLES:

Album with two tracks, simple example:
<span class="haudio">
   <span class="fn album">Best Before 1984</span>
   <span class="contributor">Crass</span>
   <div class="item">
      <span class="fn">Hokkaido Dream</span>
   </div>
   <div class="item">
      <span class="fn">Tokyo Groove</span>
   </div>
</span>

Album with two tracks, more detailed:
<span class="haudio">
   <span class="fn album">Best Before 1984</span>
   <span class="contributor">Crass</span>
   <span class="item">
      <span class="fn">Hokkaido Dream</span>
      <abbr class="duration" title="PT3M24S">3:24</abbr>
   </span>
   <span class="item">
      <span class="fn">Tokyo Groove</span>
      <abbr class="duration" title="PT4M46S">4:46</abbr>
   </span>
</span>

Scott, I think you and I had the most adverse reactions to this
approach. I've learned to live with it as this approach did not cause
problems when marking up over 20 of the audio-info examples.

Thoughts, suggestions, comments? This is the last blocking issue with
hAudio before we can move it to Draft status.

-- manu

From scott at makedatamakesense.com  Sun Oct 28 19:49:35 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Sun Oct 28 19:49:43 2007
Subject: [uf-new] hAudio ITEM debate proposal #3
In-Reply-To: <4725443E.8070303@digitalbazaar.com>
References: <4725443E.8070303@digitalbazaar.com>
Message-ID: <0E9B3CAF-98DF-4912-96EE-5CF1C040EA59@makedatamakesense.com>

On Oct 28, 2007, at 8:23 PM, Manu Sporny wrote:

> Scott, I think you and I had the most adverse reactions to this
> approach. I've learned to live with it as this approach did not cause
> problems when marking up over 20 of the audio-info examples.
>
> Thoughts, suggestions, comments?


As long as an ITEM within an HAUDIO is itself defined as an audio  
recording, I see no problem with leaving out the HAUDIO class name here.

--
Scott Reynen
MakeDataMakeSense.com


From paul_wilkins at xtra.co.nz  Sun Oct 28 23:39:21 2007
From: paul_wilkins at xtra.co.nz (paul_wilkins@xtra.co.nz)
Date: Sun Oct 28 23:39:25 2007
Subject: [uf-new] hAudio ITEM debate proposal #3
Message-ID: <702096.12079.qm@web96008.mail.aue.yahoo.com>

From: Manu Sporny <msporny@digitalbazaar.com>
> Thoughts, suggestions, comments? This is the last blocking issue with
> hAudio before we can move it to Draft status.


I am eternally reminded about the nesting trouble that hCard has with table layouts and peoples names.

Have issues with table layouts for existing audio examples been thought through?

-- 
Paul Wilkins




From davidjanes at blogmatrix.com  Mon Oct 29 02:36:58 2007
From: davidjanes at blogmatrix.com (David Janes)
Date: Mon Oct 29 02:37:00 2007
Subject: [uf-new] hAudio ITEM debate proposal #3
In-Reply-To: <0E9B3CAF-98DF-4912-96EE-5CF1C040EA59@makedatamakesense.com>
References: <4725443E.8070303@digitalbazaar.com>
	<0E9B3CAF-98DF-4912-96EE-5CF1C040EA59@makedatamakesense.com>
Message-ID: <21e523c20710290336g18dcd2danb256ee4dee153042@mail.gmail.com>

On 10/28/07, Scott Reynen <scott@makedatamakesense.com> wrote:
> On Oct 28, 2007, at 8:23 PM, Manu Sporny wrote:
>
> > Scott, I think you and I had the most adverse reactions to this
> > approach. I've learned to live with it as this approach did not cause
> > problems when marking up over 20 of the audio-info examples.
> >
> > Thoughts, suggestions, comments?
>
>
> As long as an ITEM within an HAUDIO is itself defined as an audio
> recording, I see no problem with leaving out the HAUDIO class name here.

Concurred.

There may be an issue in the _docs_ for hListing [1] and hReview [2],
i.e. that item can now refer to part of a thing rather than the thing
itself, though nothing functional should need to change. There's
definitely a change need here [3], though once again no big deal. The
way they same to spec item seems to be loose enough anyway, and
perhaps after this proposal goes through we can make hItem a real spec
and reference that.

Regards, etc...

[1] http://microformats.org/wiki/hlisting
[2] http://microformats.org/wiki/hreview
[3] http://microformats.org/wiki/existing-classes

-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com
From msporny at digitalbazaar.com  Mon Oct 29 04:34:06 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Mon Oct 29 04:34:10 2007
Subject: [uf-new] hAudio ITEM debate proposal #3
In-Reply-To: <0E9B3CAF-98DF-4912-96EE-5CF1C040EA59@makedatamakesense.com>
References: <4725443E.8070303@digitalbazaar.com>
	<0E9B3CAF-98DF-4912-96EE-5CF1C040EA59@makedatamakesense.com>
Message-ID: <4725D33E.6090003@digitalbazaar.com>

Scott Reynen wrote:
> On Oct 28, 2007, at 8:23 PM, Manu Sporny wrote:
> 
>> Scott, I think you and I had the most adverse reactions to this
>> approach. I've learned to live with it as this approach did not cause
>> problems when marking up over 20 of the audio-info examples.
>>
>> Thoughts, suggestions, comments?
> 
> 
> As long as an ITEM within an HAUDIO is itself defined as an audio
> recording, I see no problem with leaving out the HAUDIO class name here.

Yes, that is the approach that this proposal takes.

-- manu
From julian at julianstahnke.com  Mon Oct 29 04:35:15 2007
From: julian at julianstahnke.com (Julian Stahnke)
Date: Mon Oct 29 04:35:20 2007
Subject: [uf-new] hAudio ITEM debate proposal #3
In-Reply-To: <4725443E.8070303@digitalbazaar.com>
References: <4725443E.8070303@digitalbazaar.com>
Message-ID: <F9E2C0ED-AA52-46C9-AA8E-1B6504102D4D@julianstahnke.com>

I like it!

So, to clarify, would a single track be marked up like this?

<span class="haudio">
    <span class="fn">Two Sleepy People</span>
    <span class="contributor">Silje Nergaard</span>
</span>

And a track from the album ?At First Light?:

<span class="haudio">
    <span class="fn">Two Sleepy People</span>
    <span class="contributor">Silje Nergaard</span>
    <span class="album">At First Light</span>
</span>
From msporny at digitalbazaar.com  Mon Oct 29 04:45:06 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Mon Oct 29 04:45:14 2007
Subject: [uf-new] hAudio ITEM debate proposal #3
In-Reply-To: <702096.12079.qm@web96008.mail.aue.yahoo.com>
References: <702096.12079.qm@web96008.mail.aue.yahoo.com>
Message-ID: <4725D5D2.10801@digitalbazaar.com>

paul_wilkins@xtra.co.nz wrote:
> From: Manu Sporny <msporny@digitalbazaar.com>
>> Thoughts, suggestions, comments? This is the last blocking issue with
>> hAudio before we can move it to Draft status.
> 
> I am eternally reminded about the nesting trouble that hCard 
> has with table layouts and peoples names.
> 
> Have issues with table layouts for existing audio examples 
> been thought through?

Yes, tables are important as that is the primary way the music services
describe audio albums. Here's how you would use hAudio in a table:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
   <title>hAudio Table Example</title>
</head>
<body>
<p>This is an example of an hAudio in a table:</p>

<div class="haudio">
   <img class="photo" alt="Live Phish Album Image"
src="images/live_phish_vol_15.jpg" />
   <p>
   <span class="album">Live Phish, Volume 15</span>
   <span class="contributor">Phish</span>
   </p>
   <p>
   Released on:
   <abbr class="published" title="20023110">October 31, 2002</abbr>
   </p>
   <p>
   Acquire:
   <a rel="sample" href="/samples/live_phish_vol_15_sample.mp3">Sample</a>,
   <a rel="enclosure" href="/live/phish_live_phish_vol_15.mp3">Live
Recording</a>,
   <a rel="payment" href="/buy/phish_live_phish_vol_15">Buy High Quality
Track</a>
   </p>
   <p>
   Category: <span class="category">live</span>
   </p>
   <p>
   Duration: <abbr class="duration" title="PT145M27S">145 minutes, 27
seconds</abbr>
   </p>
   <p>
   Tracks:
   </p>
   <table>
    <tr><th>#</th><th>Track</th><th>Length</th></tr>
    <tr class="item">
        <td>1.</td>
        <td class="fn">Sanity</td>
        <td><abbr class="duration" title="PT5M48S">5:48</abbr></td>
    </tr>
    <tr class="item">
        <td>2.</td>
        <td class="fn">Highway To Hell</td>
        <td><abbr class="duration" title="PT3M39S">3:39</abbr></td>
    </tr>
   </table>
</div>

</body>
</html>

-- manu
From msporny at digitalbazaar.com  Mon Oct 29 04:46:37 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Mon Oct 29 04:46:40 2007
Subject: [uf-new] hAudio ITEM debate proposal #3
In-Reply-To: <F9E2C0ED-AA52-46C9-AA8E-1B6504102D4D@julianstahnke.com>
References: <4725443E.8070303@digitalbazaar.com>
	<F9E2C0ED-AA52-46C9-AA8E-1B6504102D4D@julianstahnke.com>
Message-ID: <4725D62D.7000006@digitalbazaar.com>

Julian Stahnke wrote:
> I like it!
> 
> So, to clarify, would a single track be marked up like this?
> 
> <span class="haudio">
>    <span class="fn">Two Sleepy People</span>
>    <span class="contributor">Silje Nergaard</span>
> </span>
> 
> And a track from the album ?At First Light?:
> 
> <span class="haudio">
>    <span class="fn">Two Sleepy People</span>
>    <span class="contributor">Silje Nergaard</span>
>    <span class="album">At First Light</span>
> </span>

Yes, that would be the proper markup based on the current proposal.

-- manu
From Michael.Smethurst at bbc.co.uk  Mon Oct 29 06:28:48 2007
From: Michael.Smethurst at bbc.co.uk (Michael Smethurst)
Date: Mon Oct 29 06:28:55 2007
Subject: [uf-new] hAudio ITEM debate proposal #3
In-Reply-To: <4725D62D.7000006@digitalbazaar.com>
Message-ID: <C34B9EA0.769D%Michael.Smethurst@bbc.co.uk>




On 29/10/07 12:46, "Manu Sporny" <msporny@digitalbazaar.com> wrote:

> Julian Stahnke wrote:
>> I like it!
>> 
>> So, to clarify, would a single track be marked up like this?
>> 
>> <span class="haudio">
>>    <span class="fn">Two Sleepy People</span>
>>    <span class="contributor">Silje Nergaard</span>
>> </span>
>> 
>> And a track from the album ?At First Light?:
>> 
>> <span class="haudio">
>>    <span class="fn">Two Sleepy People</span>
>>    <span class="contributor">Silje Nergaard</span>
>>    <span class="album">At First Light</span>
>> </span>
> 
> Yes, that would be the proper markup based on the current proposal.

Again not wanting to muddy any waters but it seems like we're trying to
capture 2 forms of containment here:

- using nesting + item to indicate containment of

- using album to indicate containment by

Is there any mileage in pushing for class="hasPart" and class="isPartOf"?

It would bring things into line with dublin core but my be a little triple-y
for these parts


> 
> -- manu
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new


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.
					

From msporny at digitalbazaar.com  Mon Oct 29 06:42:24 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Mon Oct 29 06:48:15 2007
Subject: [uf-new] hAudio ITEM debate proposal #3
In-Reply-To: <C34B9EA0.769D%Michael.Smethurst@bbc.co.uk>
References: <C34B9EA0.769D%Michael.Smethurst@bbc.co.uk>
Message-ID: <4725F150.5070708@digitalbazaar.com>

Michael Smethurst wrote:
> Again not wanting to muddy any waters but it seems like we're trying to
> capture 2 forms of containment here:
> 
> - using nesting + item to indicate containment of

This is correct. More specifically, we use item to indicate containment
of another hAudio.

> - using album to indicate containment by

ALBUM does not indicate containment of any kind with this proposal. The
only thing ALBUM does is name the title of the album the hAudio is
associated with and further specify the type of the hAudio if FN is
missing. So:

* If only ALBUM is specified, the hAudio is an album.
* If FN and ALBUM are specified and different, the hAudio is a song in
an album.
* IF FN and ALBUM are both specified and are identical, the hAudio is an
album.

> Is there any mileage in pushing for class="hasPart" and class="isPartOf"?

hAudio RDFa specifies a rel="hmedia:contains", which does exactly what
you are proposing above. It works really well in the RDFa markup, but as
you said... RDFa markup is a bit different than Microformats markup.

We don't really have a universally accepted way of creating the
equivalent of a RDF link within a Microformatted page. Do we?

-- manu

From paul_wilkins at xtra.co.nz  Mon Oct 29 11:08:41 2007
From: paul_wilkins at xtra.co.nz (paul_wilkins@xtra.co.nz)
Date: Mon Oct 29 11:08:45 2007
Subject: [uf-new] hAudio ITEM debate proposal #3
Message-ID: <615511.44254.qm@web96010.mail.aue.yahoo.com>

From: Manu Sporny <msporny@digitalbazaar.com>
> > Have issues with table layouts for existing audio examples 
> > been thought through?
> 
> Yes, tables are important as that is the primary way the music services
> describe audio albums. Here's how you would use hAudio in a table:

<snip example>

Thanks Manu that was very helpful.

What I eventually hope to see will be code examples of how sites are currently marking up their music - such as from http://microformats.org/wiki/audio-info-examples - and how the hAudio microformat can be best fully applied to these examples.

Some of them will be trivial, and others will duplicate others, so those don't all need to have examples for each of them, but the rest would be very useful.

When someone wants to use a microformat, it can be a lot of work to go through the specs and mentally convert the intention into real code, but if real-world examples existed they could go through them and find something that's very similar to the existing usage they're facing at that time.

It could be very instructive to have a wide range of non-simple examples that demonstrate how to apply it to real-world situations.
This may also help to discover any issues that may require working through.

-- 
Paul Wilkins






From martin at weborganics.co.uk  Mon Oct 29 15:07:43 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Mon Oct 29 15:07:09 2007
Subject: [uf-new] hAudio ITEM debate proposal #3
In-Reply-To: <4725443E.8070303@digitalbazaar.com>
References: <4725443E.8070303@digitalbazaar.com>
Message-ID: <1193699263.5187.12.camel@localhost.localdomain>

On Sun, 2007-10-28 at 22:23 -0400, Manu Sporny wrote:

...
> <span class="haudio">
>    <span class="fn album">Best Before 1984</span> 

...

I have always been a firm supporter of not changing audio-title
because I think it reflects hentry/entry-title in hAtom which from a
publisher point of view is an easy association to make.
so I think it would be simpler sticking with audio-title

<span class="haudio">
   <span class="audio-title">Best Before 1984</span> 
<div class="item">
      <span class="fn">Hokkaido Dream</span>
   </div>
</span>

also I dont believe fn and album together serve any real benefit as they
both seem to mean the equivalent of a title


Thanks

Martin

From scott at makedatamakesense.com  Mon Oct 29 16:27:22 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Mon Oct 29 16:27:30 2007
Subject: [uf-new] hAudio ITEM debate proposal #3
In-Reply-To: <1193699263.5187.12.camel@localhost.localdomain>
References: <4725443E.8070303@digitalbazaar.com>
	<1193699263.5187.12.camel@localhost.localdomain>
Message-ID: <F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>

On Oct 29, 2007, at 5:07 PM, Martin McEvoy wrote:

> also I dont believe fn and album together serve any real benefit as  
> they
> both seem to mean the equivalent of a title


Not true.

On Oct 21, 2007, at 12:20 PM, Scott Reynen wrote:

> FN does *not* mean album name.  It means *audio* name.  Whether or  
> not that's the same as the album name determines whether or not  
> we're talking about an album.

This is a pattern taken directly from hCard, another context in which  
subtypes are not explicitly stated but can still be determined by  
which elements are present.  If you think hAudio should differ from  
hCard here, please explain why.

--
Scott Reynen
MakeDataMakeSense.com


From martin at adwords-media.co.uk  Tue Oct 30 04:34:03 2007
From: martin at adwords-media.co.uk (Martin McEvoy)
Date: Tue Oct 30 04:34:02 2007
Subject: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
In-Reply-To: <F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>
References: <4725443E.8070303@digitalbazaar.com>	<1193699263.5187.12.camel@localhost.localdomain>
	<F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>
Message-ID: <472724BB.10103@adwords-media.co.uk>


Scott Reynen wrote:
> On Oct 29, 2007, at 5:07 PM, Martin McEvoy wrote:
>
>> also I dont believe fn and album together serve any real benefit as they
>> both seem to mean the equivalent of a title
>
>
> Not true.
OK? ......
>
> On Oct 21, 2007, at 12:20 PM, Scott Reynen wrote:
>
>> FN does *not* mean album name.  It means *audio* name.  Whether or 
>> not that's the same as the album name determines whether or not we're 
>> talking about an album.
>
That Is YOUR definition

> This is a pattern taken directly from hCard, another context in which 
> subtypes are not explicitly stated but can still be determined by 
> which elements are present.  If you think hAudio should differ from 
> hCard here, please explain why.
are you meaning that  "fn album" is an optimization  based on something 
like  the  nickname optimization in  hCard  ?
http://microformats.org/wiki/hcard#Implied_.22nickname.22_Optimization

The wiki is a little misleading at the moment but off the 
audio-info-proposal page...

Album

The title of a collection of audio recordings that are represented as a 
CD, album or LP. The text should be a short textual description used to 
identify the work among interested parties. This can be the title of a 
CD, album title, or the name of a collection of audio recordings.

    * The element is identified by the class name |album-title|.
    * hAudio /MUST/ have either |album-title| or |audio-title|.

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

How has the definition changed from the above?

All I am suggesting is that we should forget about any "fn album" 
optimization for now and keep it simple.
Now that  item / fn has been accepted to described hAudio  tracks, there 
is no real need to complicate hAudio any more than saying that 
audio-title is the main hAudio title and fn is a track title and leave 
it there.


Thanks

Martin McEvoy
Adwords Media
http://adwords-media.co.uk
> -- 
> Scott Reynen
> MakeDataMakeSense.com
>
>
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
>
From scott at makedatamakesense.com  Tue Oct 30 06:19:31 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Tue Oct 30 06:19:40 2007
Subject: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
In-Reply-To: <472724BB.10103@adwords-media.co.uk>
References: <4725443E.8070303@digitalbazaar.com>	<1193699263.5187.12.camel@localhost.localdomain>
	<F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>
	<472724BB.10103@adwords-media.co.uk>
Message-ID: <F4FD1929-7AB8-4A83-994A-532559227789@makedatamakesense.com>

On Oct 30, 2007, at 6:34 AM, Martin McEvoy wrote:

>>> FN does *not* mean album name.  It means *audio* name.  Whether or  
>>> not that's the same as the album name determines whether or not  
>>> we're talking about an album.
>>
> That Is YOUR definition

It is, but only because that's the definition of FN in the wiki:

http://microformats.org/wiki/classes

"The name of the object."

The object of an hAudio is an audio recording, so FN in hAudio means  
"the name of the audio recording."  The definition of ALBUM on the  
other hand, is the name of the album.  That the album is sometimes  
also the recording does not make those two definitions the same.   
Similarly the terms "big" and "elephant" do not have the same meaning  
merely because they often refer to the same object.

>> This is a pattern taken directly from hCard, another context in  
>> which subtypes are not explicitly stated but can still be  
>> determined by which elements are present.  If you think hAudio  
>> should differ from hCard here, please explain why.
> are you meaning that  "fn album" is an optimization  based on  
> something like  the  nickname optimization in  hCard  ?

It's not an optimization, and it's not related to nickname.  It's an  
indirect way of indicating subtype when a subtype is not explicitly  
stated, just like we use the identical value of FN and ORG to indicate  
the subtype of the hCard is organization.

> All I am suggesting is that we should forget about any "fn album"  
> optimization for now and keep it simple.

It seems to me we're talking about two different definitions of what  
those terms mean.  Take a look at how FN and ORG work in hCard; it's  
the same pattern.  If you don't like this pattern, I'd like to hear  
why, but you seem to be objecting to a definition of these terms that  
doesn't match previous use (e.g. what FN means above), so I don't  
really understand your objection.

> Now that  item / fn has been accepted to described hAudio  tracks,  
> there is no real need to complicate hAudio any more than saying that  
> audio-title is the main hAudio title and fn is a track title and  
> leave it there.

How should we describe a single track and its album title?  Currently  
we'd do that like this:

<p class="haudio">
	I like the song <span class="fn">Everything in Its Right Place</span>  
on <span class="album">Kid A</span>.
</p>

I'm not clear what you see as the alternative without separate  
properties.

--
Scott Reynen
MakeDataMakeSense.com
From msporny at digitalbazaar.com  Tue Oct 30 06:51:26 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue Oct 30 06:57:43 2007
Subject: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
In-Reply-To: <472724BB.10103@adwords-media.co.uk>
References: <4725443E.8070303@digitalbazaar.com>	<1193699263.5187.12.camel@localhost.localdomain>	<F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>
	<472724BB.10103@adwords-media.co.uk>
Message-ID: <472744EE.90307@digitalbazaar.com>

Martin McEvoy wrote:
> Scott Reynen wrote:
>>> also I dont believe fn and album together serve any real benefit as they
>>> both seem to mean the equivalent of a title
>>
>> Not true.
> OK? ......

Scott's correct - FN and ALBUM are used to identify two completely
different things.

>> On Oct 21, 2007, at 12:20 PM, Scott Reynen wrote:
>>> FN does *not* mean album name.  It means *audio* name.  Whether or
>>> not that's the same as the album name determines whether or not we're
>>> talking about an album.
>>
> That Is YOUR definition

Not really... it's the definition that we've settled on after a very
long discussion regarding AUDIO-TITLE and FN. It is not Scott's
definition - it is the definition that is in hCard. We are probably
going to re-use it in hAudio because we won't have to invent a new word
(AUDIO-TITLE) and we will be re-using the proper semantics.

> The wiki is a little misleading at the moment but off the
> audio-info-proposal page...

Would anybody have a problem with me taking the time to update the
hAudio page? It is badly out of date at this point and it is leading to
more confusion than helping. I could integrate the ITEM proposal and the
FN proposal and fix up some very outdated language. The hAudio page is
in grave need of an update.

> Album
> 
> The title of a collection of audio recordings that are represented as a
> CD, album or LP. The text should be a short textual description used to
> identify the work among interested parties. This can be the title of a
> CD, album title, or the name of a collection of audio recordings.
> 
>    * The element is identified by the class name |album-title|.
>    * hAudio /MUST/ have either |album-title| or |audio-title|.
> 
> http://microformats.org/wiki/audio-info-proposal#Album
> 
> How has the definition changed from the above?

The only change is to the bullet points:

 * The element is identified by the class name ALBUM.
 * hAudio /MUST/ have either ALBUM or FN.

> All I am suggesting is that we should forget about any "fn album"
> optimization for now and keep it simple.
> Now that  item / fn has been accepted to described hAudio  tracks, there
> is no real need to complicate hAudio any more than saying that
> audio-title is the main hAudio title and fn is a track title and leave
> it there.

As Scott pointed out, it is not an optimization. Remember, we have the
following rules for hAudio that allow us to describe the type of a
recording:

* If only ALBUM is specified, the hAudio is an album.
* If FN and ALBUM are specified and different, the hAudio is a song in
  an album.
* IF FN and ALBUM are both specified and are identical, the hAudio is an
  album.

-- manu
From chris.newell at rd.bbc.co.uk  Tue Oct 30 07:15:20 2007
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Tue Oct 30 07:15:28 2007
Subject: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
In-Reply-To: <472744EE.90307@digitalbazaar.com>
References: <4725443E.8070303@digitalbazaar.com>
	<1193699263.5187.12.camel@localhost.localdomain>
	<F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>
	<472724BB.10103@adwords-media.co.uk>
	<472744EE.90307@digitalbazaar.com>
Message-ID: <6.2.0.14.2.20071030151149.0421e150@pop3>

Manu,
At 14:51 30/10/2007, you wrote:
>Would anybody have a problem with me taking the time to update the
>hAudio page? It is badly out of date at this point and it is leading to
>more confusion than helping. I could integrate the ITEM proposal and the
>FN proposal and fix up some very outdated language. The hAudio page is
>in grave need of an update.

It would be really helpful if you could spare the time to do an update following recent discussions.

Chris

_______________________ 
Chris Newell
Lead Technologist 
BBC Research

From paul_wilkins at xtra.co.nz  Tue Oct 30 10:55:09 2007
From: paul_wilkins at xtra.co.nz (paul_wilkins@xtra.co.nz)
Date: Tue Oct 30 10:55:19 2007
Subject: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
Message-ID: <292415.42784.qm@web96003.mail.aue.yahoo.com>

From: Martin McEvoy <martin@adwords-media.co.uk>
> The wiki is a little misleading at the moment but off the 
> audio-info-proposal page...
<snip>

Another thing that's misleading from the audio-info-proposal page is the duration section.
It states that times are to be an "ISO-8601 formatted duration" that "SHOULD be in seconds"

This is now wrong, as times are to be in the H/M/S format.

Instead of P203S it should be P2M23S

-- 
Paul Wilkins



From martin at weborganics.co.uk  Tue Oct 30 11:22:38 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Tue Oct 30 11:22:10 2007
Subject: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
In-Reply-To: <F4FD1929-7AB8-4A83-994A-532559227789@makedatamakesense.com>
References: <4725443E.8070303@digitalbazaar.com>
	<1193699263.5187.12.camel@localhost.localdomain>
	<F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>
	<472724BB.10103@adwords-media.co.uk>
	<F4FD1929-7AB8-4A83-994A-532559227789@makedatamakesense.com>
Message-ID: <1193772158.14790.2.camel@localhost.localdomain>

Hi Scott

On Tue, 2007-10-30 at 08:19 -0600, Scott Reynen wrote: 
> On Oct 30, 2007, at 6:34 AM, Martin McEvoy wrote:
> 
> >>> FN does *not* mean album name.  It means *audio* name.  Whether or  
> >>> not that's the same as the album name determines whether or not  
> >>> we're talking about an album.
> >>
> > That Is YOUR definition
> 
> It is, but only because that's the definition of FN in the wiki:
> 
> http://microformats.org/wiki/classes
> 
> "The name of the object."

as usual you are misunderstanding what I mean

I have no Issue with FN on its own and believe it or not I have a
complete understanding of what FN means

I do however have an Issue with the combination of FN and ALBUM
> 
> The object of an hAudio is an audio recording, so FN in hAudio means  
> "the name of the audio recording."  The definition of ALBUM on the  
> other hand, is the name of the album.  That the album is sometimes  
> also the recording does not make those two definitions the same.   
> Similarly the terms "big" and "elephant" do not have the same meaning  
> merely because they often refer to the same object.
> 
> >> This is a pattern taken directly from hCard, another context in  
> >> which subtypes are not explicitly stated but can still be  
> >> determined by which elements are present.  If you think hAudio  
> >> should differ from hCard here, please explain why.
> > are you meaning that  "fn album" is an optimization  based on  
> > something like  the  nickname optimization in  hCard  ?

class="fn nickname" does the same as class="fn org" 

formated name type nickname

formated name type organization.

But then I dont have to tell you that either? 

> 
> It's not an optimization, and it's not related to nickname.  It's an  
> indirect way of indicating subtype when a subtype is not explicitly  
> stated, just like we use the identical value of FN and ORG to indicate  
> the subtype of the hCard is organization.

any way before we all get carried away with this issue... 

> 
> > All I am suggesting is that we should forget about any "fn album"  
> > optimization for now and keep it simple.
> 
> It seems to me we're talking about two different definitions of what  
> those terms mean.  Take a look at how FN and ORG work in hCard; it's  
> the same pattern.  If you don't like this pattern, I'd like to hear  
> why, but you seem to be objecting to a definition of these terms that  
> doesn't match previous use (e.g. what FN means above), so I don't  
> really understand your objection.
> 
> > Now that  item / fn has been accepted to described hAudio  tracks,  
> > there is no real need to complicate hAudio any more than saying that  
> > audio-title is the main hAudio title and fn is a track title and  
> > leave it there.
> 
> How should we describe a single track and its album title?  Currently  
> we'd do that like this:
> 
> <p class="haudio">
> 	I like the song <span class="fn">Everything in Its Right Place</span>  
> on <span class="album">Kid A</span>.
> </p>
> 
> I'm not clear what you see as the alternative without separate  
> properties.
> 

<p class="haudio"> 
	I like the song <span class="item fn">Everything in Its Right Place</span>  
on <span class="audio-title">Kid A</span>.
</p>

doesn't rock the boat much does it?


Thanks

Martin McEvoy

> --
> Scott Reynen
> MakeDataMakeSense.com
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From martin at weborganics.co.uk  Tue Oct 30 11:53:54 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Tue Oct 30 11:53:27 2007
Subject: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
In-Reply-To: <472744EE.90307@digitalbazaar.com>
References: <4725443E.8070303@digitalbazaar.com>
	<1193699263.5187.12.camel@localhost.localdomain>
	<F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>
	<472724BB.10103@adwords-media.co.uk> <472744EE.90307@digitalbazaar.com>
Message-ID: <1193774034.14790.6.camel@localhost.localdomain>

On Tue, 2007-10-30 at 10:51 -0400, Manu Sporny wrote:
> * If only ALBUM is specified, the hAudio is an album.
> * If FN and ALBUM are specified and different, the hAudio is a song in
>   an album.
> * IF FN and ALBUM are both specified and are identical, the hAudio is
> an album. 

sounds exotic

* audio-title represents 

From martin at weborganics.co.uk  Tue Oct 30 12:33:14 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Tue Oct 30 12:32:42 2007
Subject: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
In-Reply-To: <1193774034.14790.6.camel@localhost.localdomain>
References: <4725443E.8070303@digitalbazaar.com>
	<1193699263.5187.12.camel@localhost.localdomain>
	<F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>
	<472724BB.10103@adwords-media.co.uk> <472744EE.90307@digitalbazaar.com>
	<1193774034.14790.6.camel@localhost.localdomain>
Message-ID: <1193776394.15191.11.camel@localhost.localdomain>

On Tue, 2007-10-30 at 19:54 +0000, Martin McEvoy wrote:
> On Tue, 2007-10-30 at 10:51 -0400, Manu Sporny wrote:
> > * If only ALBUM is specified, the hAudio is an album.
> > * If FN and ALBUM are specified and different, the hAudio is a song in
> >   an album.
> > * IF FN and ALBUM are both specified and are identical, the hAudio is
> > an album. 
> 
> sounds exotic
> 
> * audio-title represents 
.....

Sorry pressed Send instead of save, had to take my mother in law home :)

.....

* audio-title represents the main title of haudio every haudio must have
an audio-title

* fn represents the title of an item within haudio

I dont see why haudio should be more complicated than (using Scott's
example)

<p class="haudio"> 
        I like the song <span class="item fn">Everything in Its Right
Place</span>  
on <span class="audio-title">Kid A</span>.
</p> 

Thanks
Martin 



From msporny at digitalbazaar.com  Tue Oct 30 13:04:44 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue Oct 30 13:04:52 2007
Subject: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
In-Reply-To: <1193776394.15191.11.camel@localhost.localdomain>
References: <4725443E.8070303@digitalbazaar.com>	<1193699263.5187.12.camel@localhost.localdomain>	<F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>	<472724BB.10103@adwords-media.co.uk>
	<472744EE.90307@digitalbazaar.com>	<1193774034.14790.6.camel@localhost.localdomain>
	<1193776394.15191.11.camel@localhost.localdomain>
Message-ID: <47279C6C.9080904@digitalbazaar.com>

Martin McEvoy wrote:
> * audio-title represents the main title of haudio every haudio must have
> an audio-title
> 
> * fn represents the title of an item within haudio
> 
> I dont see why haudio should be more complicated than (using Scott's
> example)
> 
> <p class="haudio"> 
>         I like the song <span class="item fn">Everything in Its Right
> Place</span>  
> on <span class="audio-title">Kid A</span>.
> </p> 

How do we know the example that you have given is an audio album? What
are the parsing rules that denote "Kid A" is an audio album, and not an
an audio song?

How do we specify a singular audio recording using your proposal? An
album with two or more tracks? An Opera? A podcast that contains
multiple sections? The reason I ask this is because we can do everything
mentioned previously with the new hAudio proposal, so you're going to
have to demonstrate how we can do all of these things using your approach.

-- manu
From martin at weborganics.co.uk  Tue Oct 30 14:20:03 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Tue Oct 30 14:19:32 2007
Subject: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
In-Reply-To: <2279D2F8-7570-42D3-BDB2-DF795342C13A@makedatamakesense.com>
References: <4725443E.8070303@digitalbazaar.com>
	<1193699263.5187.12.camel@localhost.localdomain>
	<F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>
	<472724BB.10103@adwords-media.co.uk>
	<F4FD1929-7AB8-4A83-994A-532559227789@makedatamakesense.com>
	<1193772158.14790.2.camel@localhost.localdomain>
	<2279D2F8-7570-42D3-BDB2-DF795342C13A@makedatamakesense.com>
Message-ID: <1193782803.15191.33.camel@localhost.localdomain>

On Tue, 2007-10-30 at 15:29 -0600, Scott Reynen wrote:
> On Oct 30, 2007, at 1:22 PM, Martin McEvoy wrote:
> 
> > class="fn nickname" does the same as class="fn org" 
> > 
> > formated name type nickname
> > 
> > formated name type organization.
> > 
> > But then I dont have to tell you that either? 
> 
> 
> That's actually useful to know you think that.  I believe you're
> misunderstanding what those mean.  class="fn nickname" does not mean
> the FN is of type NICKNAME.  It means the contained content is
> classified as FN and also classified as NICKNAME.  That may sound like
> a pedantic difference, but it's important to avoid thinking two
> classes used together mean the same thing, or that either class has
> any effect on what the other means.  class="fn org", similarly,
> assigns two distinct classes to the same content.  Putting them in
> separate elements would mean the exact same thing.  They mean
> different things and don't change each other's meaning at all.  It's
> the identical value of FN and ORG (whether or not they're the same
> element) that indicates the subtype of the hCard, whereas an identical
> value of FN and NICKNAME carries no such meaning.
> 
> > > How should we describe a single track and its album title?
> > >  Currently  
> > > we'd do that like this:
> > > 
> > > <p class="haudio">
> > > I like the song <span class="fn">Everything in Its Right
> > > Place</span>  
> > > on <span class="album">Kid A</span>.
> > > </p>
> > > 
> > > I'm not clear what you see as the alternative without separate  
> > > properties.
> > > 
> > 
> > <p class="haudio"> 
> > I like the song <span class="item fn">Everything in Its Right
> > Place</span>  
> > on <span class="audio-title">Kid A</span>.
> > </p>
> > 
> > doesn't rock the boat much does it?
> 
> 
> I'd say it does, but probably not where you intended.  HTML's class
> attribute doesn't allow for sub-properties in the same element, as
> you've done with class="item fn".  After making that change, we're to
> this:

Right? I didnt know that I think someone mentioned before that item and
fn cant be used in that way but never got round to explaining why?

then this is probably wrong?

 <div class="hlisting">
   <p>
     <span class="item fn">Parking space</span>
     <span class="offer rent">for rent</span>
     (<abbr class="dtlisted" title="20060202">2/2/06</abbr>)
   </p>
...

http://microformats.org/wiki/hlisting#Simple_Listing

or am I misunderstanding something else? :)

> 
> 
> <p class="haudio"> 
> I like the song <span class="item"><span class="fn">Everything in Its
> Right Place</span></span>  
> on <span class="audio-title">Kid A</span>.
> </p>
> 
> 
> After that, you've made two changes.  First, you changed "album" to
> "audio-title."  With only the context of an album to go on, these
> appear to mean the exact same thing, so if you intend "audio-title" to
> mean something different, please explain what exactly.  The other
> change is adding ITEM as a wrapper around the song's name.  Again, I'm
> not sure what purpose this serves.  By definition (and by the
> examples), there are more individual recordings of audio than
> collections, so I think it makes sense to assume audio is not a
> collection unless otherwise indicated.  You seem to be making the
> opposite assumption?

Yes I am making the opposite assumption, haudio (to me and probably
others) stopped being about a single audio recording the moment we
decided it may be wise to merge halbum's track and album-title with
hAudio, when upon reflection it may have been simpler to merge hAudio
into hAlbum as most of the time this seems to be what we are talking
about 

I dont think I am suggesting anything new for hAudio in-fact i am
intending slimming down the proposal by removing both album-title and
track In favour of re-using the Item microfomat
http://microformats.org/wiki/item for tracks and only using audio-title
(instead of both audio-title and album-title) as the main hAudio title 
http://microformats.org/wiki/audio-info-proposal#Schema

Thanks

Martin
> 
> --
> Scott Reynen
> MakeDataMakeSense.com

From martin at weborganics.co.uk  Tue Oct 30 14:23:19 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Tue Oct 30 14:22:47 2007
Subject: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
In-Reply-To: <47279C6C.9080904@digitalbazaar.com>
References: <4725443E.8070303@digitalbazaar.com>
	<1193699263.5187.12.camel@localhost.localdomain>
	<F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>
	<472724BB.10103@adwords-media.co.uk> <472744EE.90307@digitalbazaar.com>
	<1193774034.14790.6.camel@localhost.localdomain>
	<1193776394.15191.11.camel@localhost.localdomain>
	<47279C6C.9080904@digitalbazaar.com>
Message-ID: <1193782999.15191.34.camel@localhost.localdomain>

On Tue, 2007-10-30 at 17:04 -0400, Manu Sporny wrote:
> Martin McEvoy wrote:
> > * audio-title represents the main title of haudio every haudio must have
> > an audio-title
> > 
> > * fn represents the title of an item within haudio
> > 
> > I dont see why haudio should be more complicated than (using Scott's
> > example)
> > 
> > <p class="haudio"> 
> >         I like the song <span class="item fn">Everything in Its Right
> > Place</span>  
> > on <span class="audio-title">Kid A</span>.
> > </p> 
> 
> How do we know the example that you have given is an audio album? What
> are the parsing rules that denote "Kid A" is an audio album, and not an
> an audio song?

> 
> How do we specify a singular audio recording using your proposal? An
> album with two or more tracks? An Opera? A podcast that contains
> multiple sections? The reason I ask this is because we can do everything
> mentioned previously with the new hAudio proposal, so you're going to
> have to demonstrate how we can do all of these things using your approach.
> 
> -- manu
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From martin at weborganics.co.uk  Tue Oct 30 14:45:39 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Tue Oct 30 14:45:10 2007
Subject: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
In-Reply-To: <47279C6C.9080904@digitalbazaar.com>
References: <4725443E.8070303@digitalbazaar.com>
	<1193699263.5187.12.camel@localhost.localdomain>
	<F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>
	<472724BB.10103@adwords-media.co.uk> <472744EE.90307@digitalbazaar.com>
	<1193774034.14790.6.camel@localhost.localdomain>
	<1193776394.15191.11.camel@localhost.localdomain>
	<47279C6C.9080904@digitalbazaar.com>
Message-ID: <1193784339.15191.54.camel@localhost.localdomain>

On Tue, 2007-10-30 at 17:04 -0400, Manu Sporny wrote:
> Martin McEvoy wrote:
> > * audio-title represents the main title of haudio every haudio must have
> > an audio-title
> > 
> > * fn represents the title of an item within haudio
> > 
> > I dont see why haudio should be more complicated than (using Scott's
> > example)
> > 
> > <p class="haudio"> 
> >         I like the song <span class="item fn">Everything in Its Right
> > Place</span>  
> > on <span class="audio-title">Kid A</span>.
> > </p> 
> 
> How do we know the example that you have given is an audio album? What
> are the parsing rules that denote "Kid A" is an audio album, and not an
> an audio song?

<span class="item fn">Everything in Its Right
Place</span> 

Is a song

<span class="audio-title">Kid A</span> is the hAudio title

You can tell by context, and content what type of haudio it is

> 
> How do we specify a singular audio recording using your proposal? An
> album with two or more tracks? An Opera? A podcast that contains
> multiple sections? The reason I ask this is because we can do everything
> mentioned previously with the new hAudio proposal, so you're going to
> have to demonstrate how we can do all of these things using your approach.

a single track

<p class="haudio"> 
        I like the song <span class="audio-title">Everything in Its
Right Place</span>.
</p> 

Scott Has informed me that item and fn cant share the same class so

more Tracks

<p class="haudio"> 
I like the songs <span class="item"><span class="fn">Everything in Its
Right Place</span></span> and <span class="item"><span class="fn">The
National Anthem </span></span> 
from the <span class="audio-title">Kid A</span> album
</p> 

A podcast,

<div class="haudio">
  <h1 class="audio title">My Latest Episode</h1>
<p>In four Parts</p>
<ol>
<li class="item"><span class="fn">Part 1</span>, duration <span
class="duration">10:15</span></li>
<li class="item"><span class="fn">Part 2</span>, duration <span
class="duration">08:15</span></li>
<li class="item"><span class="fn">Part 3</span>, duration <span
class="duration">09:05</span></li>
<li class="item"><span class="fn">Part 4</span>, duration <span
class="duration">12:33</span></li>
</ol>


Thanks

Martin
> 
> -- manu
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From martin at weborganics.co.uk  Tue Oct 30 14:48:18 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Tue Oct 30 14:47:46 2007
Subject: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
In-Reply-To: <1193784339.15191.54.camel@localhost.localdomain>
References: <4725443E.8070303@digitalbazaar.com>
	<1193699263.5187.12.camel@localhost.localdomain>
	<F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>
	<472724BB.10103@adwords-media.co.uk> <472744EE.90307@digitalbazaar.com>
	<1193774034.14790.6.camel@localhost.localdomain>
	<1193776394.15191.11.camel@localhost.localdomain>
	<47279C6C.9080904@digitalbazaar.com>
	<1193784339.15191.54.camel@localhost.localdomain>
Message-ID: <1193784498.15191.56.camel@localhost.localdomain>

On Tue, 2007-10-30 at 22:45 +0000, Martin McEvoy wrote:
> <div class="haudio">
>   <h1 class="audio title">My Latest Episode</h1>
> <p>In four Parts</p>
> <ol>
> <li class="item"><span class="fn">Part 1</span>, duration <span
> class="duration">10:15</span></li>
> <li class="item"><span class="fn">Part 2</span>, duration <span
> class="duration">08:15</span></li>
> <li class="item"><span class="fn">Part 3</span>, duration <span
> class="duration">09:05</span></li>
> <li class="item"><span class="fn">Part 4</span>, duration <span
> class="duration">12:33</span></li>
> </ol> 
</div>

:)

Martin

From msporny at digitalbazaar.com  Tue Oct 30 20:20:53 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue Oct 30 20:20:57 2007
Subject: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
In-Reply-To: <1193782803.15191.33.camel@localhost.localdomain>
References: <4725443E.8070303@digitalbazaar.com>	<1193699263.5187.12.camel@localhost.localdomain>	<F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>	<472724BB.10103@adwords-media.co.uk>	<F4FD1929-7AB8-4A83-994A-532559227789@makedatamakesense.com>	<1193772158.14790.2.camel@localhost.localdomain>	<2279D2F8-7570-42D3-BDB2-DF795342C13A@makedatamakesense.com>
	<1193782803.15191.33.camel@localhost.localdomain>
Message-ID: <472802A5.3000600@digitalbazaar.com>

Martin McEvoy wrote:
> I dont think I am suggesting anything new for hAudio in-fact i am
> intending slimming down the proposal by removing both album-title and
> track In favour of re-using the Item microfomat
> http://microformats.org/wiki/item for tracks

I believe this is already happening, Martin... nobody seemed to have
much of a problem with the latest hAudio ITEM proposal. So, I don't
think your thoughts on this matter are in conflict with anybody else on
the list at this point.

> only using audio-title
> (instead of both audio-title and album-title) as the main hAudio title 
> http://microformats.org/wiki/audio-info-proposal#Schema

This seems to be purely a disagreement between using AUDIO-TITLE and FN.

Manu Sporny wrote:
>> How do we know the example that you have given is an audio album?
>> What are the parsing rules that denote "Kid A" is an audio album, and
>> not an an audio song?
>
> <span class="item fn">Everything in Its Right Place</span>
> Is a song
> <span class="audio-title">Kid A</span> is the hAudio title
> You can tell by context, and content what type of haudio it is

That's indeterminate. We have no way of telling whether or not that is
an album or an audio recording that is partly composed of another audio
recording. In other words, there is nothing in those semantics that say
that "Everything in Its Right Place" is a song, and nothing that
mentions that "Kid A" is actually an album.

I think you're proposing that if an hAudio contains an ITEM, then it is
automatically an album. While this would save us from having to define a
new property, ALBUM, it would kill every non-album use case that exists
out there. All of a sudden, any collection of audio would become an
album... whether or not it is an album. For two examples of why this is
a bad approach, take a look at the Podcast example on the hAudio
proposal page:

http://microformats.org/wiki/audio-info-proposal#Multi-part_Podcast_Example

or the Opera example on the hAudio proposal page:

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

Context isn't enough to tell us what the type of the audio is... we have
more types out there than just album. We also can't say it is just an
"audio collection" because the audio-info-examples clearly state that we
MUST be able to specify the difference between a song and an album, in
the very least.

-- manu

From msporny at digitalbazaar.com  Tue Oct 30 20:30:57 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue Oct 30 20:31:01 2007
Subject: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
In-Reply-To: <1193784339.15191.54.camel@localhost.localdomain>
References: <4725443E.8070303@digitalbazaar.com>	<1193699263.5187.12.camel@localhost.localdomain>	<F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>	<472724BB.10103@adwords-media.co.uk>
	<472744EE.90307@digitalbazaar.com>	<1193774034.14790.6.camel@localhost.localdomain>	<1193776394.15191.11.camel@localhost.localdomain>	<47279C6C.9080904@digitalbazaar.com>
	<1193784339.15191.54.camel@localhost.localdomain>
Message-ID: <47280501.4060302@digitalbazaar.com>

Martin McEvoy wrote:
> Scott Has informed me that item and fn cant share the same class so
> 
> more Tracks
> 
> <p class="haudio"> 
> I like the songs <span class="item"><span class="fn">Everything in Its
> Right Place</span></span> and <span class="item"><span class="fn">The
> National Anthem </span></span> 
> from the <span class="audio-title">Kid A</span> album
> </p> 
> 
> A podcast,
> 
> <div class="haudio">
>   <h1 class="audio title">My Latest Episode</h1>
> <p>In four Parts</p>
> <ol>
> <li class="item"><span class="fn">Part 1</span>, duration <span
> class="duration">10:15</span></li>
> <li class="item"><span class="fn">Part 2</span>, duration <span
> class="duration">08:15</span></li>
> <li class="item"><span class="fn">Part 3</span>, duration <span
> class="duration">09:05</span></li>
> <li class="item"><span class="fn">Part 4</span>, duration <span
> class="duration">12:33</span></li>
> </ol>
> </div>

Your podcast example has exactly the same semantics associated with it
as your album example. Take a closer look at the structure of both, they
are:

haudio
   item
      fn
   item
      fn
   audio-title

haudio
   audio-title
   item
      fn
      duration
   item
      fn
      duration
   item
      fn
      duration
   item
      fn
      duration

Looking at the structure, not the data. How can you say one is an album
and the other is a podcast? There is no way to deduce this information
from the mark-up. Have I understood your approach correctly?

-- manu
From msporny at digitalbazaar.com  Tue Oct 30 20:43:26 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Tue Oct 30 20:43:29 2007
Subject: [uf-new] hAudio v0.8 updated
Message-ID: <472807EE.20204@digitalbazaar.com>

The hAudio proposal has been updated to reflect all of the discussions
and resolutions for the past 2 months:

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

There is really only one contentious issue right now: the use of FN or
AUDIO-TITLE and the inclusion of ALBUM. The proposal has been updated to
reflect the most backed stance, but could change depending on how the
current thread proceeds.

-- manu

From martin at adwords-media.co.uk  Wed Oct 31 02:44:42 2007
From: martin at adwords-media.co.uk (Martin McEvoy)
Date: Wed Oct 31 02:44:41 2007
Subject: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
In-Reply-To: <47280501.4060302@digitalbazaar.com>
References: <4725443E.8070303@digitalbazaar.com>	<1193699263.5187.12.camel@localhost.localdomain>	<F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>	<472724BB.10103@adwords-media.co.uk>	<472744EE.90307@digitalbazaar.com>	<1193774034.14790.6.camel@localhost.localdomain>	<1193776394.15191.11.camel@localhost.localdomain>	<47279C6C.9080904@digitalbazaar.com>	<1193784339.15191.54.camel@localhost.localdomain>
	<47280501.4060302@digitalbazaar.com>
Message-ID: <47285C9A.9040108@adwords-media.co.uk>

Hello Manu

Manu Sporny wrote:
> Martin McEvoy wrote:
>   
>> Scott Has informed me that item and fn cant share the same class so
>>
>> more Tracks
>>
>> <p class="haudio"> 
>> I like the songs <span class="item"><span class="fn">Everything in Its
>> Right Place</span></span> and <span class="item"><span class="fn">The
>> National Anthem </span></span> 
>> from the <span class="audio-title">Kid A</span> album
>> </p> 
>>
>> A podcast,
>>
>> <div class="haudio">
>>   <h1 class="audio title">My Latest Episode</h1>
>> <p>In four Parts</p>
>> <ol>
>> <li class="item"><span class="fn">Part 1</span>, duration <span
>> class="duration">10:15</span></li>
>> <li class="item"><span class="fn">Part 2</span>, duration <span
>> class="duration">08:15</span></li>
>> <li class="item"><span class="fn">Part 3</span>, duration <span
>> class="duration">09:05</span></li>
>> <li class="item"><span class="fn">Part 4</span>, duration <span
>> class="duration">12:33</span></li>
>> </ol>
>> </div>
>>     
>
> Your podcast example has exactly the same semantics associated with it
> as your album example. Take a closer look at the structure of both, they
> are:
>
> haudio
>    item
>       fn
>    item
>       fn
>    audio-title
>
> haudio
>    audio-title
>    item
>       fn
>       duration
>    item
>       fn
>       duration
>    item
>       fn
>       duration
>    item
>       fn
>       duration
>
> Looking at the structure, not the data. How can you say one is an album
> and the other is a podcast? There is no way to deduce this information
> from the mark-up. Have I understood your approach correctly?
>   
Ahh! I think I know where our misunderstanding is.

I think it has something to do with what our basic concept of an Album 
is and how type or subtypes are marked up implicitly, by implicit I mean 
only suggesting or giving the general idea that what we are talking 
about is a hAudio album.

take this example using the current proposed method

<div class="haudio">
  <h1 class="fn album">My Latest Episode</h1>
<p>In four Parts</p>
<ol>
<li class="item"><span class="fn">Part 1</span>, duration <span
class="duration">10:15</span></li>
<li class="item"><span class="fn">Part 2</span>, duration <span
class="duration">08:15</span></li>
<li class="item"><span class="fn">Part 3</span>, duration <span
class="duration">09:05</span></li>
<li class="item"><span class="fn">Part 4</span>, duration <span
class="duration">12:33</span></li>
</ol>
</div>

you are explicitly requiring me to mark up my podcast as an album? when in fact it is not!

You are trying to set the type of hAudio (The Object) as an Album but it just doesn't seem to work, its too restrictive you are requiring every author to mark up their haudio explicitly as an Album? which in the above example is not correct.

The reality is that it is the blogging community that is likely to adopt hAudio first before any corporate adoption, from a business perspective it would cost too much for say Apple iTunes (and many other major music download stores) to test and deploy hAudio on its music stores, I has to be tested first, In the case of Microformats Community its usually by publishers of Blogs that do the testing first, So to simply ignore the early adopters of hAudio seems like folly.

How about giving the publisher or author the option to describe what the contents of haudio are?

an Idea something to talk about Not a proposal:

<div class="haudio">
  <h1 class="type" title="podcast">
	<span class="fn">My Latest Episode</span>
  </h1>
<p>In four Parts</p>
<ol>
<li class="item"><span class="fn">Part 1</span>, duration <span
class="duration">10:15</span></li>
<li class="item"><span class="fn">Part 2</span>, duration <span
class="duration">08:15</span></li>
<li class="item"><span class="fn">Part 3</span>, duration <span
class="duration">09:05</span></li>
<li class="item"><span class="fn">Part 4</span>, duration <span
class="duration">12:33</span></li>
</ol>
</div>

A relatively new concept I know, @title represents the authors interpretation of what the hAudio object may be about, not a set type a free form Microformat? the only thing I do not know is if this is possible?, or if the semantics are correct they seem to be, but the only example of type being set by @title is in hReview but is done with the abbr design pattern...

...
<abbr class="type" title="business">
  <a href="http://en.wikipedia.org/wiki/cafe" rel="tag">cafe</a></abbr> 
... 

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

which seems a bit like an abuse of the abbr design pattern to me ? is 
cafe an abbreviation of  buisness maybe I dont know?


Thoughts ?

Thanks

Martin McEvoy
Adwords Media
http://adwords-media.co.uk/

> -- manu
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
>
>   
From brian.suda at gmail.com  Wed Oct 31 02:52:52 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Wed Oct 31 02:52:55 2007
Subject: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
In-Reply-To: <1193782803.15191.33.camel@localhost.localdomain>
References: <4725443E.8070303@digitalbazaar.com>
	<1193699263.5187.12.camel@localhost.localdomain>
	<F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>
	<472724BB.10103@adwords-media.co.uk>
	<F4FD1929-7AB8-4A83-994A-532559227789@makedatamakesense.com>
	<1193772158.14790.2.camel@localhost.localdomain>
	<2279D2F8-7570-42D3-BDB2-DF795342C13A@makedatamakesense.com>
	<1193782803.15191.33.camel@localhost.localdomain>
Message-ID: <21e770780710310352i1453d269y720b5b02db99cfbb@mail.gmail.com>

On 10/30/07, Martin McEvoy <martin@weborganics.co.uk> wrote:
> then this is probably wrong?
>
>  <div class="hlisting">
>    <p>
>      <span class="item fn">Parking space</span>
>      <span class="offer rent">for rent</span>
>      (<abbr class="dtlisted" title="20060202">2/2/06</abbr>)
>    </p>
> ...
>
> http://microformats.org/wiki/hlisting#Simple_Listing
>
> or am I misunderstanding something else? :)

--- you are correct, that mark-up is wrong. I have updated the wiki
example, there were a few errors, so if anyone wants to double-check
my edits please do.

Generally, because hListing (and hAudio) use the same style "item" as
hReview, properties such as FN, URL, PHOTO and others need to be
children of the ITEM property to give an explicit nesting and
relationship.

-brian

-- 
brian suda
http://suda.co.uk
From scott at makedatamakesense.com  Wed Oct 31 05:54:43 2007
From: scott at makedatamakesense.com (Scott Reynen)
Date: Wed Oct 31 05:54:50 2007
Subject: [uf-new] Album Vs audio-title (was hAudio ITEM debate proposal #3)
In-Reply-To: <47285C9A.9040108@adwords-media.co.uk>
References: <4725443E.8070303@digitalbazaar.com>	<1193699263.5187.12.camel@localhost.localdomain>	<F5018D44-67E7-4060-A251-6C4498FAF146@makedatamakesense.com>	<472724BB.10103@adwords-media.co.uk>	<472744EE.90307@digitalbazaar.com>	<1193774034.14790.6.camel@localhost.localdomain>	<1193776394.15191.11.camel@localhost.localdomain>	<47279C6C.9080904@digitalbazaar.com>	<1193784339.15191.54.camel@localhost.localdomain>
	<47280501.4060302@digitalbazaar.com>
	<47285C9A.9040108@adwords-media.co.uk>
Message-ID: <FD53A1A0-0506-45BB-B3E9-346FFF93A719@makedatamakesense.com>

On Oct 31, 2007, at 4:44 AM, Martin McEvoy wrote:

> you are explicitly requiring me to mark up my podcast as an album?  
> when in fact it is not!

Now that the wiki is relatively up to date we can actually use it and  
avoid wasting our time talking about completely different things.  The  
podcast example in the wiki includes no mention of album:

http://microformats.org/wiki/audio-info-proposal#Multi-part_Podcast_Example

Problem solved?

> A relatively new concept I know

Can we please focus on clarifying specific problems with the current  
proposal before we start introducing new concepts as potential  
solutions?  It seems to me we're mostly talking past each other and I  
think this would go a lot faster if we had everyone on the same page  
(if not in agreement about that page).

--
Scott Reynen
MakeDataMakeSense.com


From martin at weborganics.co.uk  Wed Oct 31 13:31:51 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Wed Oct 31 13:31:21 2007
Subject: [uf-new] hAudio v0.8 updated
In-Reply-To: <472807EE.20204@digitalbazaar.com>
References: <472807EE.20204@digitalbazaar.com>
Message-ID: <1193866311.22211.7.camel@localhost.localdomain>

On Wed, 2007-10-31 at 00:43 -0400, Manu Sporny wrote:
> The hAudio proposal has been updated to reflect all of the discussions
> and resolutions for the past 2 months:
> 
> http://microformats.org/wiki/audio-info-proposal

Great Manu really good work thank you for your time :)

> 
> There is really only one contentious issue right now: the use of FN or
> AUDIO-TITLE and the inclusion of ALBUM. The proposal has been updated to
> reflect the most backed stance, but could change depending on how the
> current thread proceeds.

I am still a little concerned about creating an album microformat and
the way its used but there only seems to be me that has aired any
concerns about this, and everyone else seems to be happy so in the
interests of of finishing this proposal lets drop the whole type album
issue and move along :)

I have no further issues with the current proposal

Thanks

Martin McEvoy
WebOrganics
http://weborganics.co.uk/

> 
> -- manu
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From msporny at digitalbazaar.com  Wed Oct 31 17:12:11 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Wed Oct 31 17:12:15 2007
Subject: [uf-new] hAudio v0.8 updated (corrections)
In-Reply-To: <1193866311.22211.7.camel@localhost.localdomain>
References: <472807EE.20204@digitalbazaar.com>
	<1193866311.22211.7.camel@localhost.localdomain>
Message-ID: <472927EB.7000108@digitalbazaar.com>

Chris Newell wrote:
> 1) The Schema section states "fn and/or album required" but in the
> Field Details section for both Formatted Name and Album it states
> "hAudio MUST have either fn or album". It would be good to use
> "and/or" throughout.

Fixed.

> 2) The definition of the "position" field is currently "a number or
> other sequential identifier" which is rather vague for a machine
> readable field. I'd prefer to see this specified as an integer with a
> reminder that <abbr> can be used to provide an alternative human
> readable form.

I'd be fine with that proposal, except that LPs and EPs are usually
listed as having A and B sides. Opera acts are usually written using
roman numerals. We would like to support these other forms of
"sequential identifier". Here's a real-world example:

http://www.discogs.com/release/74366

A1 	Figuras Frustradas   Psychic Vacuum
A2 	Pametex              Laque
B1 	Cosmic Force         The Electric Vision
B2 	Blue Villa People    R.E.M.

The question then becomes, is A1 position #1, or is B1 position #1? Can
we support these varied methods using only integers, or are we going to
have to focus on "humans first and machines second". My inclination is
to focus on "humans first and machines second".

No change has been made, yet. I'd like to keep that statement as-is
until there is a compelling way to support roman numeral and LP/EP
positional notation. Anybody have any great ideas on how to do this?

> 3) The "category" field is currently defined as text. Most of the
> examples I've examined a link which is effectively a tag. Can we adopt
> the approach used for the hCard "category" field and say:
>   "Categories in hAudio MAY be represented by tags with rel-tag. When
> a category property is a rel-tag, the tag (as defined by rel-tag) is
> used for that category."
> Apart from the benefit of using rel-tag, a consistent definition of
> "category" throughout microformats would be good.

Done. I made some small editorial corrections, does the following
statement work for you?

# This element MAY be expressed using the rel-tag elemental microformat.
When a category is expressed using rel-tag, the inner content of the
element is used as the text for the category. For example: <a
class="category" rel="tag" href="/tags/rock">Rock and Roll</a> would
have "Rock and Roll" as the text for the category.

> 4) The Language section has an odd reference to "reviews" (cut and
> paste error from hReview?):
>    "hAudio processors which need to handle the language of reviews
> MUST process the standard (X)HTML 'lang' attribute as specified."

Fixed.

> 5) This is probably not the time and place to say it but I regret the
> fact that there is no way to indicate the language used in the audio
> content, as opposed to the hAudio property values.

We can always add it into future versions of hAudio if it becomes common
place to specify the language of an audio recording. The reason hAudio
doesn't have a way to indicate the language of audio content is because
we didn't see that markup behavior while analyzing the examples.

For the time being, the publisher can add a "category" property with the
language listed, such as:

<span class="category">spanish</span> or <a rel="tag" class="category"
href="http://en.wikipedia.org/wiki/Burmese_language">burmese</a>

> 6) Aren't the last three bullets in the informative Notes section now
> obsolete?

Fixed.

Thanks for the vetting, Chris :). If anybody else wants to take a look
through hAudio and point out sections that are misleading, confusing or
wrong, please do.

-- manu

From msporny at digitalbazaar.com  Wed Oct 31 17:31:46 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Wed Oct 31 17:31:51 2007
Subject: [uf-new] hAudio v0.8 updated
In-Reply-To: <1193866311.22211.7.camel@localhost.localdomain>
References: <472807EE.20204@digitalbazaar.com>
	<1193866311.22211.7.camel@localhost.localdomain>
Message-ID: <47292C82.7000503@digitalbazaar.com>

Martin McEvoy wrote:
> On Wed, 2007-10-31 at 00:43 -0400, Manu Sporny wrote:
>> The hAudio proposal has been updated to reflect all of the discussions
>> and resolutions for the past 2 months:
>>
>> http://microformats.org/wiki/audio-info-proposal
> 
> Great Manu really good work thank you for your time :)

No problem... thanks to you and the rest of the fine people on this list
for helping to move hAudio forward. The process hasn't been pretty by
any stretch of the imagination, but I think all of us here are doing
something that is very important to musicians, music fans, podcasters
and anybody that creates and distributes audio.

> I am still a little concerned about creating an album microformat and
> the way its used but there only seems to be me that has aired any
> concerns about this, and everyone else seems to be happy so in the
> interests of of finishing this proposal lets drop the whole type album
> issue and move along :)
> 
> I have no further issues with the current proposal

Fair enough.

I'll send an e-mail after this with a list of issues that seem to be
closed with the latest round of discussions.

-- manu

From martin at weborganics.co.uk  Wed Oct 31 17:45:52 2007
From: martin at weborganics.co.uk (Martin McEvoy)
Date: Wed Oct 31 17:45:22 2007
Subject: [uf-new] hAudio v0.8 updated
In-Reply-To: <47292C82.7000503@digitalbazaar.com>
References: <472807EE.20204@digitalbazaar.com>
	<1193866311.22211.7.camel@localhost.localdomain>
	<47292C82.7000503@digitalbazaar.com>
Message-ID: <1193881553.23524.2.camel@localhost.localdomain>

On Wed, 2007-10-31 at 21:31 -0400, Manu Sporny wrote:
> Martin McEvoy wrote:
> > On Wed, 2007-10-31 at 00:43 -0400, Manu Sporny wrote:
> >> The hAudio proposal has been updated to reflect all of the discussions
> >> and resolutions for the past 2 months:
> >>
> >> http://microformats.org/wiki/audio-info-proposal
> > 
> > Great Manu really good work thank you for your time :)
> 
> No problem... thanks to you and the rest of the fine people on this list
> for helping to move hAudio forward. The process hasn't been pretty by
> any stretch of the imagination, but I think all of us here are doing
> something that is very important to musicians, music fans, podcasters
> and anybody that creates and distributes audio.
> 
> > I am still a little concerned about creating an album microformat and
> > the way its used but there only seems to be me that has aired any
> > concerns about this, and everyone else seems to be happy so in the
> > interests of of finishing this proposal lets drop the whole type album
> > issue and move along :)
> > 
> > I have no further issues with the current proposal
> 
> Fair enough.
> 
> I'll send an e-mail after this with a list of issues that seem to be
> closed with the latest round of discussions.
> 

Thank You ;) Manu


When do you plan a move to draft ?


Martin
 
> -- manu
> 
> _______________________________________________
> microformats-new mailing list
> microformats-new@microformats.org
> http://microformats.org/mailman/listinfo/microformats-new

From msporny at digitalbazaar.com  Wed Oct 31 17:55:50 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Wed Oct 31 17:55:53 2007
Subject: [uf-new] Closing outstanding hAudio issues
Message-ID: <47293226.7050206@digitalbazaar.com>

The following hAudio issues have been resolved with the latest update to
the hAudio proposal (hAudio v0.8). If there are no objections, I'd like
to mark all of them as resolved:

------------------------------------------------------------------------
ISSUE #2: audio-title Property
http://microformats.org/wiki/audio-info-issues#audio-title_Property

RESOLUTION: The latest proposal uses FN and most seem to be happy with
            that.

------------------------------------------------------------------------
ISSUE #9:  album-title Property
http://microformats.org/wiki/audio-info-issues#album-title_Property

RESOLUTION: The latest proposal uses ALBUM and most seem to be OK with
            that approach.

------------------------------------------------------------------------
ISSUE #10: Collection names
http://microformats.org/wiki/audio-info-issues#Collection_Names

RESOLUTION: We seem to have settled on ALBUM as the only explicit
            collection type for now.

------------------------------------------------------------------------
ISSUE #11: TRACK does not work in tables
http://microformats.org/wiki/audio-info-issues#Problem:_TRACK_does_not_work_in_tables

RESOLUTION: When we settled on ITEM containing hAudio properties, this
            problem went away. We have demonstrated that hAudio v0.8
            works in tables.

------------------------------------------------------------------------
ISSUE #13: Container property naming
http://microformats.org/wiki/audio-info-issues#Problem:_Container_property_naming

RESOLUTION: The latest proposal uses ITEM to denote containers.

-- manu
From msporny at digitalbazaar.com  Wed Oct 31 18:14:49 2007
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Wed Oct 31 18:14:52 2007
Subject: [uf-new] hAudio v0.8 updated
In-Reply-To: <1193881553.23524.2.camel@localhost.localdomain>
References: <472807EE.20204@digitalbazaar.com>	<1193866311.22211.7.camel@localhost.localdomain>	<47292C82.7000503@digitalbazaar.com>
	<1193881553.23524.2.camel@localhost.localdomain>
Message-ID: <47293699.708@digitalbazaar.com>

Martin McEvoy wrote:
> When do you plan a move to draft ?

haha... good question :). I don't really know the process of moving from
where we are now to draft... I've never seen it happen before =P

We should probably:

1. Close up most of the remaining hAudio issues (this is where we are
   currently).
2. Take another round of comments on whether people think hAudio is
   ready to go to draft.
3. Update the hAudio implementation for Operator.
4. Make a "formal" request to move hAudio to the Draft Specification
   stage.

Perhaps a gray-beard on the list would like to comment on if the above
is a rational way to move forward?

-- manu