W3C home > Mailing lists > Public > uri@w3.org > October 2001

Re: Excess URI schemes considered harmful

From: Tim Berners-Lee <timbl@w3.org>
Date: Mon, 29 Oct 2001 18:57:33 -0500
Message-ID: <027b01c160d5$7b246d90$d6061812@CREST>
To: "Harald Tveit Alvestrand" <harald@alvestrand.no>, "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, "'Rob Lanphier'" <robla@real.com>
Cc: <uri@w3.org>, "Dan Connolly" <connolly@w3.org>, "Al Gilman" <asgilman@iamdigex.net>, "Larry Masinter" <LMM@acm.org>, "Dan Zigmond" <djz@corp.webtv.net>, "Rich Petke" <rpetke@wcom.net>
One reason you need a mapping between Contentxt-Types and
URIs is that one must be able to introduce new non-standard context types
with all the benefit
of URI machinery

- Anyone can make a new one
- Choice of schemes with different properties of identity, dereference, etc
- Ability to talk about them for example wiht RDF and all other languages
which use URIs.

There are millions of different sorts of things being registered in URI
space all the time
many more than IANA could ever cope with.

Sean Palmer is right, of course, that any DAML-aware engine can use the
unambiguousness of Content-Type to reason about content types.  BUT
if you use a string, then you have the X-problem again - what do you do
about experimental, local use, peer agreement etc Content types? The URI
has all this machinery built itn.  It's an hourglass system, like IP.  Lots
functionality supporting URIs below the waist, and lots of very different
above the waist, which specify a URI as the identifier.

----- Original Message -----
From: "Harald Tveit Alvestrand" <harald@alvestrand.no>
Sent: Tuesday, September 25, 2001 4:03 PM
> Don,
> it would be quite useful if your draft would explain better WHY you need a
> mapping between these two quite dissimilar name spaces.
> I have trouble imagining the case where you would want to use it.
>                  Harald
Received on Monday, 29 October 2001 18:57:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:03 UTC