Re: Excess URI schemes considered harmful

On Wed, Sep 26, 2001 at 04:59:27PM +0100, Sean B. Palmer wrote:
> > Because different URN nids don't require different handling
> > by software that handles them (unlike different URI schemes,
> > which MAY require different handling).
> 
> Hmm... I guess I agree with you there, although intuitively it doesn't feel
> right. If I come across an arbitrary URI, and I am only told that it's a
> URI, then I will handle it just the same as I would any URI, including
> URNs. In other words, I don't particularly believe that the properties of
> URNs are *inherently* different from that of any given URI. It just so
> happens that due to the culture behind them, and the way in which they are
> delegated, they all end up being registered as location independent
> identifers. But they can still resolve, etc.

Right. If you disavow any specific knowledge of the properties
of any scheme you still have the inherit URI semantics (resolution
_not_ being one of them). But if you at least use the knowledge that
URNs have to adhere to a certain set of rules then you have a powerful
tool. Its up to you whether you use it or not...

> > [...] I believe a "very high shared knowledge of the properties
> > of" URNs is already present, because they don't really have
> > any significant properties other than being unique, persistent
> > names.
> 
> Well, URIs are unique persistent names too. But it depends upon context...
> for example:-
> 
>    http://example.org/
> 
> Assuming that some run-of-the-mill organization owned that domain name,
> would the URI be persistent? Let's say example.org is a company selling
> widgets, and they hand it over to a company making sprockets. Some people
> may argue that the traditional usage of the identifier (the binding of the
> identifier to a resource which is about widgets) has changed. However, what
> if there is no context to the link, and I'm just demonstrating that there
> is a domain called example.org? The URI is persistent in that context
> because it always identifies the HTTP server on the domain example.org.
> Even if there isn't an HTTP server there! [1]
> 
> So it always depends upon context, and I think that many of the problems in
> arguing about persistence is that people disagree on what the context of
> use of an identifier is. Some think that an HTTP URI identifies a document,
> some think it identifies a concept, some think it identifies a location on
> the internet...

Right. But some seem to be ignoring that a specific scheme (URN in this
discussion) has made limitations on that context so that certain
assumptions can be made by simple examination and having _no_ other
context at all....

> The measure of any persistence of a URI is in the quality of service in
> context over a period of time. 

It really sounds here like you assert that persistence of the identifier
has something to do with whether or not the server is still there or not.

> Without the qualifying context, anyone can
> argue convincingly that a URI is both persistent or non-persistent. Draw
> whatever conclusions from that about URNs:URIs that you may :-)

If this were the case then there would be no reason to have RFC 2396
since everything is done in context. No. RFC 2396 and any document
that defines a new URI scheme gets to make requirements on _all_
contexts that use that URI scheme. If you reject them then you're
violating the specs of that scheme...

> [1] A lower level example rather than a higher level example would be if I
> cited soemthing on the widget page, and then next week that material had
> been removed, but the page was still about widgets. In that context, even
> the W3C datespace area is not persistent!

Again, you seem to place 'persistence' in terms of whether or not the
resource is available on some network. That IMHO is persistence of
the Resource. Not the persistence of the URI...

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
michael@neonym.net      |                              | http://www.neonym.net

Received on Wednesday, 26 September 2001 14:10:07 UTC