[uf-new] Microformat for Music Downloads

Martin McEvoy martin at weborganics.co.uk
Mon Apr 9 13:31:50 PDT 2007


hAtom as a transport for music-downloads makes loads of sense to me.
hAtom follows the naming conventions of Atom yes? so adding a few more
Atom words like:

rights, for copyrights
contributor, because songwriters are not always the artist.
logo, for album covers or associated artwork

tied in with rel="enclosure" another Atom word and:

id, unique id of download
length, in milliseconds
type, audio/mpeg

I think we may have something workable without breaking anything.

I dont think hReview will fit into this scheme of things, the only thing
that prompted me to add a hRevew was when i was clicking around the
media-info examples http://microformats.org/wiki/media-info-examples I
noticed that quite a lot of the examples had an album review of some
kind, something to think about while i was kicking around the idea.
 

On Mon, 2007-04-09 at 16:52 -0300, Alexandre Van de Sande wrote:
> >publishing music with the intent that it be
> downloaded to a local audio player is just as much syndication as
> publishing text with the intent that it be downloaded to a local feed
> 
> I agree with you: and the information formatted on hAtom should
> concern the syndication: title, date released, type of content,
> author. But any extra information that's specific to the format being
> syndicated (composer,  album, drum player) should be formatted into a
> format-specific for it.
> 
> If we were syndicating places to be read by some kind of google earth
> plugin for exemple, no one would argue that the best way to do it
> would use a hGeo inside an hAtom, not to expand the hAtom in order to
> pass Geographical locations. Therefore if I am building a music-player
> + feed-reader that relies on hAtom we should use a microformat for
> music.
> 
> On 4/9/07, Scott Reynen <scott at makedatamakesense.com> wrote:
> > On Apr 9, 2007, at 12:52 PM, Alexandre Van de Sande wrote:
> >
> > > again I really do not understand the point on using hReview
> >
> > I agree that hReview doesn't make much sense outside of actual reviews.
> >
> > > Of course you can syndicate audio or review music, but it's wrong to
> > > try to fit hreview or hAtom for something totally different
> >
> > I would argue that publishing music with the intent that it be
> > downloaded to a local audio player is just as much syndication as
> > publishing text with the intent that it be downloaded to a local feed
> > reader.  So all music downloads are a form of syndication.  I'm not
> > suggesting putting audio downloads within a syndicated blog post just
> > to use hAtom; I'm suggesting the audio download itself is syndicated
> > content, so the audio itself can make use of existing hAtom semantics
> > for syndicated content.  That this will show up in feed readers is a
> > secondary concern.
> >
> > --
> > 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



More information about the microformats-new mailing list