Re: URIs vs. URNs vs. URLs

> In my experience, a typical bookmarked URL will outlast
> a URN.  The reason is because unimplemented persistent
> naming mechanisms go in and out of fashion.

I agree with the gist of your arguement here: that it doesn't matter
how persistent you say something is, it's the social usage of the
identifier that gives it persistence. However, this conversation came
from the topic of identifiers for the Semantic Web.

Often, in RDF, you don't often expect a network entity to be returned
from a particular term, because the semantics of it are coded into the
processing tools (e.g. the built-ins in CWM). Thus, the persistence is
still only as good as the implementation, but there is no particular
benefit to using a URL, i.e. something that will give you a data
representation of the resource upon dereferencing. Indeed, my argument
is that because the DNS system is not all that stable (with domain
takeovers, and money-crises a-plenty), a set of names that aren't
based upon this is useful. Names that aren't necessarily expected to
resolve to something could be useful too.

> Persistence is not, and never has been, a function of the
> syntax used to create the name.

Apart from where the authority component for that syntax can be
delegated away to other entities by "mistake", "force majure", "lack
of money", or whatever? Also, I think that persistence is reflected in
the syntax once it has been put to use for a while. People know that
if they dereference an HTTP URL, 90%+ of the time, they're going to
get a 200 O.K. response.

> If you want persistent names, ask a library to
> create one

Would the W3C and PURL count as libraries? I trust these two
organizations to provide persistent names, but only because I know
their backgrounds, and that if someone took away their domain names,
there would be an uproar.

But I don't know that about any other server. Perhaps I can work it
out given time, but often I will not trust a server, because most
people really don't care about persistence to the lengths that (for
example) the W3C and PURL do. And there comes another problem: how do
I get people to trust the names that I create? I can't really, only by
their experience with dealing with me.

> [...] the syntax only determines how often the name will be
> used.  Making it a URN only reduces the name's scope of use.

Surely the syntax that one uses for a URI scheme is independent of the
scope of its implementation? I mean that just because I use a URN for
a new scheme, that doesn't preclude me from building a successful
range of tools that use the new scheme, does it?

If we were talking about addresses here, I'd agree with you, but all I
really want is a way to create a name that I know won't be whipped out
from underneath me in a year or two. Heck, URLs could do it if domain
names were persistent. But I also don't want people to necessarily
believe that they're going to get some data back upon dereferencing
whatever name I'm providing. viz. I don't want them to rely upon that.
In the context of the Semantic Web, that can actually be a useful
thing, although in the context of the "normal" Web, it often isn't.

Of course, we still need addresses for all that RDF data :-)

Above all, it should be noted that I'm essentially a pragmatist. I
agree with you that mostly, URNs have a limited use, because people
don't often need to agree upon a set of unique "names" rather than
protocol bound addresses. XML namespaces confused the crap out of
people in this respect, because for many, it was the first example of
them needing to use a URL for a name. I don't know of any particular
reason why an XML namespace cannot be a URN, and the only reason for
it not being a URL is that it is more difficult to find URLs with a
good quality of service.

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .

Received on Friday, 3 August 2001 22:19:26 UTC