[uf-new] Microformat for Music Downloads

Martin McEvoy martin at weborganics.co.uk
Fri Apr 6 10:28:17 PDT 2007


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



More information about the microformats-new mailing list