Re: URIs / URLs

Pierre-Antoine CHAMPIN wrote:
[...]
> HTML and PDF version available at
>   http://www710.univ-lyon1.fr/~champin/urls/

This document promulgates a number of myths about
Web Architecture...

  "However, other W3C recommendations use URLs to identify
  namespaces [6,8,11]. Those URLs do not locate the
  corresponding namespaces (which are abstract things and
  hence not locatable with the HTTP protocol), "

I don't see any justification for the claim
that namespaces are disjoint from HTTP resources.
One of the primary motivations for the
XML namespaces recommendation is to make the
Web self-describing: each document carries the
identifiers of the vocabularies/namespaces it's written in;
the system works best when you can use such
an identifier to GET a specification/description
of the vocabulary.


  "For example, the URI of the type property of RDF is
  http://www.w3.org/1999/02/22-rdf-syntax-ns#type. As a
  matter of fact, the property itself is not located by that
  URL: its description is. "

Again, I see no justification for the claim that this
identifier doesn't identify a property.

  "URLs are transient 

  That means they may become invalid after a certain period
  of time [9]. "

That's a fact of life in a distributed system. URNs may
become invalid after a period of time too. It's true
of all URIs. URIs mean what we all agree that they mean.
Agreement is facilitated by a lookup service like HTTP.
In practice, URIs are quite reliable:
6% linkrot according to http://www.useit.com/alertbox/980614.html
and I think the numbers get better when you measure
per-request rather than per-link,
since popular pages are maintained
more activly than average.

Unless urn: URIs provide value
that http: URIs do not, the won't be deployed.
I think the fact that

 (a) urn:'s have been standardized
 (IETF Proposed Standard, that is) since 1995
 (b) support for them is available in popular browsers
 and has been for several generations
and yet
 (c) still their use is negligible

speaks for itself. They don't provide any value.
Naming is a social contract, and the http: contract
works and the urn: contract doesn't.


  "In the immediate interpretation, a URL identifies the
  resource retrieved through it."

to be precise: it identifies the resource accessed
thru it. In the general case, you can't retrieve
a resource, but only a representation of one.
Other text that makes this error includes:

  "... the retrieved resource ..."

Another falsehood:

  "Contrarily to URLs, URNs (Uniform Resource Names) are
  designed to persistently identify a given resource."

URIs in general are designed to persistently identifiy
a given resource. Especially HTTP URIs.


I recommend a series of articles by the designer
of URIs, HTTP, and HTML to clarify a number of
these myths:

  World Wide Web Design Issues
  http://www.w3.org/DesignIssues/

esp

  The Web Model: Information hiding and URI syntax (Jan 98) 
  http://www.w3.org/DesignIssues/Model

  The Myth of Names and Addresses 
  http://www.w3.org/DesignIssues/NameMyth

  Persistent Domains- an idea for persistence of URIs(2000/10)
  http://www.w3.org/DesignIssues/PersistentDomains

  (Hmm... this one is an interesting idea, but I think freenet:
   might be easier to deploy.)

and regarding the intent of the design of namespaces, see:

  cf Web Architecture: Extensible Languages
  W3C Note 10 Feb 1998 
  http://www.w3.org/TR/NOTE-webarch-extlang

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Friday, 6 April 2001 09:54:09 UTC