RE: URIs / URLs

Some excellent points in here.  IMHO, there is not enough appreciation of
these kinds of lower-level issues and their impact discussed in the RDF
interest group.

My thoughts:

Mailto
======
TimBL had some interesting views on mailto: in one of his musings (I can't
remember which one) that equated a mailto: as a locator, and the "default"
action browsers tend to adopt is to launch a mail client to send an email to
that address.  However, the action could quite easily be something else,
such as 'finger' that person to get info on them, or retrieve their home
address from your favourite address book app.  

The point is that "retrieval" is not an endemic aspect of URLs.  URLs merely
identify by location.  Software agents do something with that identifier
(which just happens to be retrieval of the identified resource, mostly).

Resource Versions
=================

In terms of resources changing, two examples you cited sprang out at me:
1) Two people with the name Champin at the same university at different
points in time.
2) Different versions of a W3C Working Draft.

It seems that 1) is clear cut: two different resources identified by the
same URL because they occupy the same location at different points in time.
This is a problem in general in terms of the transient nature of the
Internet.

However, 2) is not so straight forward.  The W3C use URLs that identify
different versions of a document as different resources (by incorporating
the publish date).  Yet the latest version is also identified by a URL that
does not contain any distinguishing date information.  The resource
retrieved by this URL changes to always retrieve the "latest version".

I would suggest that a new URN scheme could directly represent the notion of
different resource versions.  After all, versioning is a fundamental aspect
of tracking the evolution of just about anything.  This "version" attribute
would not form part of the main identifier, and would be optional (like a
port specifier in a URL).  The default "version" if not specified in a URN
would be the "latest".  Then the mapping from URN to URL (if any) can
reflect versioning directly.

Perhaps WebDAV efforts have already addressed versioning issues, I don't
know.  It would be worth investigating!

N2L & L2N service
=================

From what I understand, you propose a N2L service of replacing "urn:xxx:"
with "http:", and a L2N service of providing additional metadata with
resources to convey any L2N mappings.

I would suggest something altogether different.

It strikes me that mapping some abstract string to an address is exactly
analogous to DNS.  I would propose a distributed service similar to DNS+HTTP
and reverse-DNS for N2L & L2N lookups:

1) Firstly, make the services processes (i.e. daemons).
The extra constraints of making the URNs in documents conform to the http
protocol for N2L mappings disappear (hooray!).  You also don't have to
specify L2N mappings within documents, avoiding unnecessary clutter.

2) Secondly, make use of DNS / reverse-DNS.
Using standard internet domain names is an excellent way of both segmenting
the namespace for these URNs (as your document points out), but also
provides an excellent hierarchical mechanism for locating the relevant,
highly distributed N2L & L2N daemons (i.e. just do a DNS lookup on a URN /
URL to identify the server with the relevent N2L / L2N daemons for that
domain).  Anyone wanting N2L & L2N capabilities for mapping urns within
their own domain space simply run these services alongside DNS.

3) Specify & implement standard N2L & L2N protocols.
Once the ip address of the appropriate daemon is found, query it using some
standard protocol that is yet to be specified for retrieving the N2L / L2N
mappings.  As a short cut, an N2L mapping could just perform the specified
action on the resource referred to (if it exists).

The analogies are:
1) a specific urn protocol analogous to the 'http:' protocol, but based on
pure identity not location.  It should also incorporate the concept of
resource versions.
2) an N2L daemon analogous to an http daemon that responds to requests for
actions on resources identified by the urns (this could just be an extra
level of indirection, looking up a URL then 'hopping' to a http daemon on
the same machine / LAN to satisfy the request).
3) an L2N daemon analogous to a reverse-DNS daemon, only at the resource
level (not the IP address / domain name level).

Regards

Lee



-----Original Message-----
From: Pierre-Antoine CHAMPIN [mailto:champin@bat710.univ-lyon1.fr]
Sent: 05 April 2001 12:22
To: www-rdf-interest@w3.org; www-rdf-logic@w3.org
Subject: URIs / URLs


Hello RDF folks,

There is a recurring debate on both RDF lists about URIs, what they
mean, and how some problems with RDF come from problems with them.

Actually, we think there is actually a problem URIs, and especially with
URLs used as URIs.

Here is an attempt to clarify those problems and give some pieces of
solution.

  Pierre-Antoine Champin

HTML and PDF version available at 
  http://www710.univ-lyon1.fr/~champin/urls/

Received on Friday, 6 April 2001 08:31:33 UTC