[uf-new] hAudio - audio-album and audio-podcast

Fri Jun 1 12:14:10 PDT 2007

Brian Suda wrote:
> On 5/31/07, Manu Sporny <msporny at digitalbazaar.com> wrote:
> > > What ever happened to working on the media-format?
> >
> > The media-format was far too broad of a problem - that's 
> why it hasn't 
> > moved forward in two years even though there are a great number of 
> > examples of marking up media on the web. It is far easier 
> to break the 
> > problem up into audio, video and images and tackle those 
> individually:
> 
> --- i would disagree, the Dublin Core group spent many many 
> years and narrowed down the base Metadata to 14 (i think) 
> values. When people propose these new microformats each one 
> wants their little pet-project portion of metadata to get 
> into the new format. In the most basic sense all the media 
> has a creator and some additional metadata. They might be 
> different types of formats, but the metadata is the pretty 
> much the same. I just think there was either, no interest in 
> developing the format, or too many "what if we add this" 
> happened and it never moved forward.
> 
> > Those are different problems - we aren't addressing those problems 
> > with this Microformat. We have a very specific problem 
> statement for 
> > audio-info:
> 
> The problem statement reads:
> "It is difficult for a browser to extract semantic 
> information about an audio recording described on a web page. 
> Metadata such as speaker, musician, publisher, label, title 
> of the work, release date, acquisition link, related image 
> artwork and tags provide relevant context for the audio recording."
> 
> with the exception of "audio recording" the could apply to 
> any media format. I don't feel it is that specific for audio.

This is true, but doesn't that suggest simply that the atomic elements for different media should be reused? Overgeneralizing loses
semantic information. Sure, it's "hMedia", but don't we still need to distinguish between albums and movies?

In other words, which is it better to say (structurally)

hMedia mediatype=Audio
	meta-data: type=album, title, creator, publisher, release-date, duration, genre
	data=track1, track2

hMedia mediatype=video
	meta-data: type=movie, title, creator, publisher, release-date, duration, genre
	data=moviefile

Than

hAudio 
	meta-data=album, title, creator, publisher, release-date, duration, genre
	data=track1, track2

And 

hVideo
	meta-data: type=movie, title, creator, publisher, release-date, duration, genre
	data=moviefile

It seems that these two (conceptual) structures encode the same semantics. But hMedia requires solving for all the media types,
which has already proven to be a problem.

> > We should stick to the small problem and solve that - not make it 
> > bigger and more complicated (boiling the oceans).
> 
> --- correct, but this doesn't have to mean what formats it 
> encompasses, but the scope of the problem. It shouldn't 
> attempt to have every possible metadata property possible - i 
> agree that is boiling the ocean, but if the same 4-5 metadata 
> properties can apply to multiple formats we should keep that 
> in mind, and i think we have done a good job to keep the 
> scope focused on just the minimal amount of metadata 
> properities needed. I just feel these same properties can 
> simultaniously apply to multiple things.

I would recommend that we address hAudio as a limited domain first. There is a lot of work and traction here. Get it to a mature
spec, then consider what it would take to make a similar hVideo and maybe hBook or similar. Then we can evaluate if an hMedia makes
sense. 

> > Could you expand on this idea please? I want to make sure I 
> understand 
> > you correctly. I'm fine with the concept of non-hyphenated 
> names, are 
> > you suggesting something along the lines of:
> >
> > album
> >    description
> >       haudio
> >    track
> >       haudio
> >    track
> >       haudio
> 
> --- You could have some overarching container, lets call that 
> something like "media". That has meta data, much like hfeed.
> 
> media
>   tags, decription, contributer, ...
> 
> then, nested in that media is individual items, much like 
> hentry in an hfeed.
> 
> media
>   tags, description, contributer, ...
>   track
>   track
>   track
>   chapter
> 
> each of those items (track, chapter, ...) contain additional 
> metadata about themselves.
> 
> media
>   tags, description, contributer, ...
>   track
>     duration, title, author, price, ...
>   chapter
>     duration, title, author, price, type, ...
> 
> > > Last i remember the hAudio proposal basically broke down 
> to just an 
> > > hReview with a price and a running time.

Also plus the clarification that it /is/ audio, and less the actual review, reviewer, and rating.

> > The semantics of audio-info are very different from the 
> semantics of a 
> > review. The following are required for audio info (based on the 
> > analysis and brainstorming done by this list): fn, contributor, 
> > published-date, rel-sample (samples), rel-enclosure (full 
> versions), 
> > rel-payment (purchase option), image-summary, category, 
> duration, and 
> > price - hardly any of those overlap with hReview.
> 
> hm, hreview has fn, so does this proposal, it has 
> published-date just like this proposal, it has an image just 
> like this proposal, it has tags just like this proposal's 
> category, hreview has URL which could be used as the download 
> links... like i originally said, it basically broken down to 
> many of the same values in hReview, with the addition of 
> price and duration.
> 
> The only value required for an hReview is the FN. Then we got 
> all side-tracked with a grouping issue.

Actually, the "item" value is the only requirement, which if I understand correctly could be an fn, hCard, or hCalendar.

> One of the first steps in proposing a microformat is to see 
> if an existing microformat could fit. After spending along 
> time on the mailing list, simply suggesting things, the whole 
> conversation bascially was pulled back to hReview. Has anyone 
> attempted to simply mark-up their data using hReview with a 
> price and duration (which is already a solved problem in hCalendar)?

If you mean that we should re-use the semantics/values in hReview, I agree. If you are suggesting actually having hReview instead of
hAudio or even changing hReview to fit hAudio (or hMedia) into it, I think that would be a problem.

So, please correct me if I'm wrong, but I doesn't seem like hReview can't be used for reviewing movies or audio in a way that
retains the semantics that you are reviewing a movie or an audio piece or a book or any media type. Instead, all of those appear to
be shoehorned into "url" and are therefore semantically indistinguishable from reviewing a webpage/URL.  

Check out the example movie review on the wiki [1] and I think you will see what I mean. The fact that the review is of a movie is
only knowable if you magically know and assume that http://www.imdb.com/title/tt0299977/ refers to a movie. That seems like a hack
rather than a scalable semantic solution. What URLs do I use for book reviews? Songs?

On a somewhat related note, shouldn't there be a uid in both hReview for the item being reviewed and hAudio for the audio item? 

And once we have a new type in hReview, we still have all the required meta-data for that particular media, which naturally fits
into an hMedia or hAudio spec.

In summary:
Re-using atomic elements and values: good.
Overgeneralizing and losing meaning: bad.

So, I would suggest that (1) we will need to update hReview once we figure out how to refer to media, so that we can review media as
easily as people, businesses, events, people, places and websites; (2) we need to figure out the media meta-data
(hMedia/hAudio/whatever) so that hReview can appropriately refer to a piece of media rather than just hCards, hCalendars, and named
things.

-j

[1] http://microformats.org/wiki/hreview#Movie_Review

--
Joe Andrieu
SwitchBook Software
http://www.switchbook.com
joe at switchbook.com
+1 (805) 705-8651 