[uf-new] hAudio ISSUE #8: hAlbum is redundant

[Manu Sporny]

Scott Reynen wrote:
>> If we do that, we will lose the ability to differentiate between an
>> album, podcast, toplist, download, and chart.
> 
> Can you explain a bit more what exactly we gain with that ability, in
> terms of practical capabilities?  

Here is the premise:

It is important to be able to differentiate between types of audio
collections. At least three different types of audio are backed up by
the audio-info-examples: audio recordings, audio albums and audio podcasts.

Here are our goals:

- Eliminate hAlbum, but support its functionality in hAudio.
- Add as little as possible to hAudio to support audio collections.

This thread has been split into three issues:

hAudio ISSUE #8:
http://microformats.org/wiki/audio-info-issues#Problem:_hAlbum_is_redundant

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

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

We should continue to talk about ISSUE #8 in this thread.

ISSUE #9 and ISSUE #10 are in regard to what we call these new classes.
What we name these new classes should be in a different thread of
conversation and should happen after we decide what to do with hAlbum.
Issue 9 and 10 become rather easy decisions if we decide not to go
forward with the proposed solution to issue 8.

> How would a hypothetical application
> treat two documents differently if they were otherwise identical, but
> one said "album-title" and the other "podcast-title"?

Here are the parsing rules. I will use the existing hAudio terms
(audio-title, album-title) in an attempt to not confuse this issue with
issue #9 or issue #10:

 * If only 'album-title' is specified, then the hAudio is an album.
 * If only 'audio-title' is specified, then the hAudio is a song/speech
   or other singular work.
 * If both 'album-title' and 'audio-title' is specified, then the hAudio
   is a song that is part of an album.
 * If 'album-title' and one or more 'track's are specified, the hAudio
   is an album containing tracks. Each track is an hAudio. None of the
   track properties should be added to the hAudio album. In other
   words, the parser shouldn't parse the contents of the TRACK hAudio
   into the non-track hAudio object, TRACK operates similarly to the
   'mfo' proposal[1].

The issue is that of semantics. None of the examples explicitly state
this is an "album" or this is a "track", however, they implicitly state
this fact.

This is the reason putting a TYPE class into hAudio doesn't make sense.
Only a few of the examples ever explicitly state that they're talking
about an album, a single recording or a podcast. It is implied by the
context in the page. Since Microformats do not allow hidden data, we
can't propose the use of TYPE - there is no text on the page to mark up
even if we did use TYPE.

Thus, in order to get the concept of an album, a single audio recording,
or a track across we must figure out a clever way to imply these
semantics without having the publisher explicitly state "this is an
album" in their HTML.

The current proposal is an attempt to imply the type of the hAudio
without requiring the publisher to put "album" in their HTML.

For software, it is important to know the semantic difference between an
audio recording, an album, and a podcast. For example - it could
determine which search service you use to find more information about
the recording, album or podcast.

On Bitmunk, our REST XML Web API allows one to specify whether the title
that you're sending it is an album, or a song. The results you get back
can be heavily dependent on the type of media that you're sending it.

Another use case is for the Operator plug-in. How you display an album,
a podcast, and a single song to a user could (and probably would) use a
slightly different UI layout.

It is not enough just to call something an audio object and be done with
it. The type of audio object has a great deal of semantic meaning to
human beings, and that is what we're trying to encapsulate with this
proposal.

> Everything else, I thought, was determined to be out of scope.  You
> previously wrote [1]:
> 
>> There are only two things that are strongly supported by the
>> audio-info-examples right now. Audio albums and audio podcasts
>> (collections of audio).
> 
> Has that since changed?

Not, it has not and it should not... it seems that I've done a bad job
of explaining that. :)

By bringing up podcast-title and toplist-title, I was attempting to
outline how we would go about naming these other "types" of hAudio. I
was attempting to demonstrate that this naming mechanism and approach
scales well. We don't end up with a Microformat for each type, we just
end up with the lesser of two evils, one more class in hAudio.

At the very least, we're talking about adding the following to hAudio:

album-title
track

Does that help clarify hAudio ISSUE #8?

-- manu


[1] http://microformats.org/wiki/mfo