[uf-new] Microformat for Music Downloads
martin at weborganics.co.uk
Fri Apr 6 03:36:55 PDT 2007
On Thu, 2007-04-05 at 10:17 -0500, Scott Reynen wrote:
> On Apr 5, 2007, at 9:56 AM, Manu Sporny wrote:
> > media-info will definitely solve this problem once it is finalized.
> > That
> > being said, does that invalidate the need for Music Download
> > microformat? Based on Stephen and your problem definition for Music
> > Download, and with your addition below, I think it does.
> I think this is backwards. We shouldn't delay solving the simpler
> problem until the more complex problem is solved. We should solve
> the simpler problem first, and make that solution a modular part of
> the more complex solution.
> >> isn't rel="enclosure" type="audio/mpeg" sufficient enough to do this
> >> then? maybe just adding length="198000" or something ?
> > That is a good, simple solution. 'rel' and 'type' are standard <a>
> > elements and would aid a browser in recognizing that you are talking
> > about an MP3 file... Amarok/iTunes could detect an hAtom/hReview combo
> > with a type="audio/mpeg" link. It would be difficult for it to
> > recognize
> > artist/track information - wouldn't it? Wouldn't that have to be
> > standardized to some degree? While we can use hAtom/hReview to do
> > this -
> > it seems a bit like a band-aid... media-info being the real
> > solution to
> > this problem. Do you agree or disagree?
> I agree that artist and track information are still needed, but
> disagree that this in some way reduces the value in reusing existing
> standards. We can and should reuse existing standards *and* add
> artist and track information.
I can agree with scott we should re-use existing formats if we can to
solve the simpler problem, isn't this the Microformat way to solve the
simple problem. If the new format can be hooked into an existing format
such as hAtom, with the addition of rel="enclosure" with a few extra
extensions such as artist, and length, why not its simple which is how
it should be, and easy for developers of all skill levels to use.
The problem as far as I can see is the Question "Microformat for music
download" as far as I can understand it the microformat for music
download should be simple in the same way as when I choose to download a
music file I will already know about the file because I have already
made the choice to download the file because previously I like the
artist or I have visited the website or on-line store and read about it
> > The Atom standard defines "length" for content, so it wouldn't be a
> > stretch to imagine that being an optional element of hAtom? The
> > question
> > is... do we want to add that to hAtom?
> Even before asking that, the question is: is length a property we
> need to add at all? It shows up in just over half of surveyed sites,
> a bit short of our rough 80% benchmark. We can always add more
> later, so we should start as simple as possible. Maybe that means
> including length, but maybe it doesn't. We shouldn't be adding
> properties just because we can.
What I'm trying to get at is before hand we know very little about the
file itself or how it relates to an artist, when we download a file we
rename the file or convert it into a different format and strip the tags
and replace them with something that fits in with our way of things
iTunes will do all this automatically as soon as the file is downloaded
into its music collection.
All I want to know before hand is "Is it the file type I'm expecting
i.e. mp3" and "Is it by who I'm expecting it to be"
A new microformat media-info may be something to solve a more extended
problem how to describe the information outside the file or download
itself, where a customer gets information about their favorite artist or
speaker is usually different to where they download a file, and
something which is a far greater and involved discussion to be debated.
> Scott Reynen
> microformats-new mailing list
> microformats-new at microformats.org
More information about the microformats-new