[Audio] Playlists and Albums (was: Re: [uf-new] item property)

[Martin McEvoy]

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 at microformats.org
> http://microformats.org/mailman/listinfo/microformats-new