[uf-new] hAudio ITEM/TRACK debate resolution

[Brian Suda]

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.

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