[uf-new] Microformat for Music Downloads

[Alexandre Van de Sande]

Hello, i have been reading this discussion for some time now and I
think I would love to opinate. I think we are losing the bigger
picture of microformats, by finding the quicker fix for a
not-so-complicated-as-it-seems problem.

I believe that more importantly than creating a microformat to
describe a downloadable audio file, we should think that the track
comes first, the information about the music comes first, and the .mp3
file itself (or it's location) is just another description of it.

Also hAtom is a great microformat to describe any "sindicated"
content, but it's job is not to describe in details that content.
hAtom has an "author" field, but it does not describes that author:
instead it uses a hCard inside the field to do it. In the same manner,
I believe the most scalable way to add information about what's being
syndicated is to add another microformat inside the "content" field of
hAtom. Today it can be a media-info or an audio-info (or a hGeo for
syndicating places i like, hCard to sindicate people available for a
job), but tomorrow it could be as well be a hComicBook, an
hSelfHelpPresentation or a hCheesyJoke.

The best way to extend hAtom is to use another microformat inside it,
not to publicy discuss  a change to the standard every time somebody
wants to syndicate something new.

Therefore I believe the best,  in  the long term , is the option 2, to
complete the media-info format and the sindicate it using hAtom.

If that seems a difficult job then we should break that one in pieces,
and solve the media-info for pop music/spoken audio first, because
most of it's solutions will be reusable to grow media-info into a
microformat that can describe most medias on the web. But again, it's
just a first poster opinion and I might have missed the boat.


Alexandre Van de Sande
      •   •   •
interaction designer
wanderingabout.com

On 4/6/07, Martin McEvoy <martin at weborganics.co.uk> wrote:
> On Fri, 2007-04-06 at 11:32 -0500, Scott Reynen wrote:
> > On Apr 6, 2007, at 10:39 AM, Manu Sporny wrote:
> >
> > > 1. Extend hAtom/hReview to support a very small subset of Marian and
> > > your problem description, solving a simple problem, but potentially
> > > bloating a Microformat when a new microformat is needed.
> >
> > I don't think extending hAtom is an option.  Music is not fundamental
> > to the purpose of hAtom.  But we could still use hAtom with the
> > addition of music-specific properties that aren't part of hAtom.
> >
> > > 2. Complete media-info - which will solve both your and Marian's
> > > problem
> > > descriptions, but could take a really long time to solve a complex
> > > problem.
> > > 3. Create a very simple hAudio microformat, which can then be
> > > integrated
> > > into media-info, solving your problem and Marian's problem. It would
> > > also lay some foundation for media-info, which I know Scott was
> > > concerned about. The downside being YAuF - yet another Microformat.
>
> Marian's problem is very involved, its a bid to allow music players and
> web players to view media info without actually having to download part
> of the file first to read the info contained in the download.?
>
> containing this information in hAtom seems logical to me because the
> data can be re-used in many ways on all platforms. The content relates
> to what you are reading on the screen It can be used to contain factual
> information about the file that matches the tag information. I suggested
> rel enclosure because of its wide usage in podcasting, its  already
> reasonably well known Microformat
>
> hReview is just another way to extend this theory further It could
> contain official reviews or announcements about the track or album or
> maybe not included at all.
>
> extending hAtom or hReview may not be wise or practical doing it this
> way can make your code very bloated, but it seems we have to explore
> existing paths fist before we go a head and create the hAudio/media-info
> microformat.
>
> >
> > These are mutually exclusive options in name only.  The same
> > properties can be 1) used with hAtom, 2) used in media-info, and 3)
> > used outside both hAtom and media-info.  The semantics of something
> > like class="album-title" don't change when we use them with a
> > different microformat, as long as we define them clearly.  That's the
> > "modularity / embeddability" principle:
> >
> > http://microformats.org/about/
> >
> > I suspect the music downloads problem can be solved by using some
> > semantics from hAtom and introducing other new HTML semantics (e.g.
> > album title) that may be part of media-info in the future.  But I see
> > no reason we need to give those new semantics a separate microformat
> > name, and no reason we need to wait for all of media-info to be
> > complete before we start using them.  The point is solving the
> > problem.  If we solve this problem without creating a whole new
> > microformat with a whole new name, that's still a successful outcome.
> >
> > --
> > Scott Reynen
> > MakeDataMakeSense.com
> >
> >
> > _______________________________________________
> > microformats-new mailing list
> > microformats-new at microformats.org
> > http://microformats.org/mailman/listinfo/microformats-new
>
> _______________________________________________
> microformats-new mailing list
> microformats-new at microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
>