From: Lucas Gonze (lg@gonze.com)
Date: Wed Jun 28 2000 - 10:12:37 PDT
A very elegant point. The only thing I don't like about it is that the
fields are defined positionally, instead of by name.
Different styles of music will always have different points of interest.
jazz needs personnel lists and recording dates. Some users
may care about the label - e.g. Charlie Parker on Verve. Some may care
about the place of origin - e.g. punk from Latvia. Sometimes album titles
matter, sometimes they don't.
The fields should be dynamically settable by name, in an xml-like way.
Sensible defaults are good as well, but should be overridable.
urn:<list of acceptable mime
types>:artist=<artist>:title=<...>:date=<...>: etc.
Ultimately this allows an OOP approach to extension.
- Lucas
On Wed, 28 Jun 2000, Jim Whitehead wrote:
> So, it dawned on me today that the name of a song, along with its band name,
> acts as an identifier for the song. Hence, it is possible to construct a
> Uniform Resource Name (URN) for songs, following syntax rules given in RFC
> 2141 <http://www.ietf.org/rfc/rfc2141.txt>. Examples being:
>
> urn:music:The%20Cars:Good%20Times%20Roll:
> (The Cars, Good Times Roll)
>
> urn:music:The%20Beatles:Lucy%20in%20the%20Sky%20with%20Diamonds:
> (The Beatles, Lucy in the Sky with Diamonds)
>
> An additional field could be added for song variants:
>
> urn:music:Orb:Little%20Fluffy%20Clouds:Live:
> (Orb, Little Fluffy Cluds, Live)
>
> This being the case, Napster and Gnutella start looking like URN resolution
> services. Of course, Napster and Gnutella are also capable of handling
> searches just on song name, and just on group name, which could also be
> handled by introducing a wildcard into the name:
>
> urn:music:The%20Cars:#:
> (A collection resource containing all of the songs by The Cars)
>
> Presumably user interfaces would hide the syntax of such URNs from
> non-technical users.
>
> Since there are now multiple services that can resolve (band name, song)
> pairs into actual resources, it would be handy to have a URN resolver
> discovery service around, so that you could discover which of several
> resolver services coul dbe used to access a particular song. The scheme
> discussed in RFC 2168 <http://andrew2.andrew.cmu.edu/rfc/rfc2168.html>
> doesn't seem like it would work, since it appears to have a centralized
> point of access (DNS server at urn.net) and isn't capable of handling the
> dynamism in Gnutella and Napster, where music resources may only be
> locatable at a particular place for a short period of time.
>
> Still, the question remains whether Naptser and Gnutella offer any insight
> into resolution of other types of URNs (such as ISBN, ISSN, etc.
> <http://andrew2.andrew.cmu.edu/rfc/rfc2288.html>). And, they continue to
> raise the issue of how much value there is in controlling a particular
> namespace resolution service. Though it seems strange to contemplate now,
> what would happen if song owners had to pay Napster to resolve requests to
> their music? This is how the DNS system works today, you pay to register
> your domain name, and pay to have it reolved to a particular machine.
> Napster can be viewed as an attempt to control the namespace resolution
> services for an extremely valuable class of intellectual property.
>
> - Jim
>
>
This archive was generated by hypermail 2b29 : Wed Jun 28 2000 - 10:22:35 PDT