[uf-new] hAudio ITEM/TRACK debate resolution

[Martin McEvoy]

On Sat, 2007-10-20 at 23:46 +0000, Brian Suda wrote:
> On 10/20/07, Scott Reynen <scott at 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
>