From: Dan Brickley (Daniel.Brickley@bristol.ac.uk)
Date: Wed Jun 28 2000 - 11:44:10 PDT
Interesting... You might go a step further, and consider using unique
Web identifiers for the fields/properties of the named resource. 'date'
alone doesn't cut it as there are multiple dates associated with any
interesting resource. And 'title' could be title in the white pages
sense (as in _Mr_ Paul McCartney) or title in the bibliographic sense
(eg. track title or album title).
This bloats things out a little, but what price precision?
(Aside: since many mime types can share the same kinds of properties,
I'd avoid using mime types as URN top level namespaces. But for sake of
argument lets stick with that, eg. urn:audio/music:etc)
> urn:<list of acceptable mime
> types>:artist=<artist>:title=<...>:date=<...>: etc.
Becomes... (if we introduce unambiguous Web ids for each field), and
add a ns ("namespace") field that associates URIs with convience local
prefixes for collections of fields/properties such as 'title','artist','date'):
urn:audio/music:AUDIO_artist=<artist>:dc_title=<....>:dc_date=<...>:ns=http://purl.org/dc/elements/1.1/%20as%20DC%20http://music.example.com/voc%20b/%20AS%20AUDIO
I've used %20 to hide the whitespace. Let's unpack that and allow a bit
of whitespace to make this readable. And lets lose those colon
separators for now...
urn
audio/music
AUDIO_artist=The Beatles
DC_title=Yellow Submarine
DC_date=1969
ns=
http://purl.org/dc/elements/1.1/ as DC
http://music.example.com/vocab/ AS AUDIO
So now I'm thinking, we could rejigg the ordering to make it more
intuitive, ie. put the namespace declarations at the top...
urn
ns= http://purl.org/dc/elements/1.1/ as DC
http://music.example.com/vocab/ AS AUDIO
audio/music
AUDIO_artist=The Beatles
DC_title=Yellow Submarine
DC_date=1969
Angle brackets and quotes seem to give people a nice warm fuzzy feeling
these days. So a few more trivial syntax changes gives us...
<AUDIO:Music
xmlns:DC="http://purl.org/dc/elements/1.1/"
xmlns:AUDIO="http://music.example.com/vocab/"
AUDIO:artist="The Beatles"
DC:title="Yellow Submarine"
DC:date="1969"
/>
Awww, you get where I'm heading with this. Bung this inside an RDF
element and you've got an RDF description of the resource. All of which
is a longwinded way of wondering out loud where identification stops and
description starts... And whether it makes sense to overload identifiers
with all this descriptive work.
Finished product:
<web:RDF xmlns:web="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<AUDIO:Music
xmlns:DC="http://purl.org/dc/elements/1.1/"
xmlns:AUDIO="http://music.example.com/vocab/"
AUDIO:artist="The Beatles"
DC:title="Yellow Submarine"
DC:date="1969"
/>
</web:RDF>
So the upside of using URN/URI syntax is compactness. Downside is
ambiguity: by the time you've added in enough extra information
(eg. identifiers for the namespaces your attributes are drawn from) you
might as well be using XML/RDF, ie. the URN/URI is going to be too long
to read out over the phone...
So from where I'm sitting, I can't help but see GNUtella and friends as
a distributed metadata service which can, given some abstract
description of a resource, find other handy properties of it, such as
the URLs of its online manifestations. I'm interested in arguments as to
+/- of thinking of these descriptions as uniquely identifying (as per
http://www.guha.com/mcf/reference.html). What does this buy us?
Dan
On Wed, 28 Jun 2000, Lucas Gonze wrote:
> 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 - 11:47:50 PDT