RE: URIs vs. URNs vs. URLs

It's interesting to see this discussion arising again (as
it did a few months back, and seemingly every few months
for quite some time ;-)

The bottom line, as I see it, is that there are two things
we need both for the Web and the Semantic Web: (1) names, 
and (2) locations. That's the original logic between the 
URL/URN distinction (no less reflected in the very terms 
themselves). And this distinction is still crucial.

What RDF must have are universal names. URI's were adopted
(seemingly) because they offered an easy source for universal
names which theoretically should not collide. Unfortunately,
folks started to use HTTP URLs rather than some form
of URN scheme and all of the issues about persistency, authority, 
ownership, control, transferral, responsibility, etc. etc. came up 
because HTTP URLs are linked to DNS and thus inherit all such 
management issues from DNS. It also confused alot of folks into
thinking that resource URIs should be dereferencable in some
fashion and most significantly, hid the QName to URI mapping 
problem by clever use of HTML fragment syntax.

The use of HTTP URLs for resource names was a short term convenience
with long term drawbacks. It appears that more folks are
finally coming to appreciate that fact, which is certainly
a good thing.

It is significant that name and location are different. One
can have e.g. many mappings from a name to different locations or
multiple names to the same location. It's not about whether
HTTP URLs *can* be used as names (they obviously can), but about
what the requirements are for names versus locations. Name URIs tend 
to be simpler and demand less overhead (e.g. resolution). Location URIs 
tend to be more structured and incur more overhead (e.g. resolution, 
redirection, etc.). Thus URI schemes which are intended to identify 
locations may be less suitable to be used to represent names than URI 
schemes intended for that purpose.

All URIs are created equal, to a certain degree, however
the syntax, storage, processing, and other constraints
and machinery surrounding their use are dictated by specific 
purposes and needs -- i.e. how those URI schemes are meant to
be used. It's not that one cannot bend a URI scheme to
some use other than originally intended, only that to do
so may come back to bite you.

This is the case with using HTTP URLs as names. For those with
large ontologies based on HTTP URLs, bend over, the big bite is 
coming ;-)

Still, this issue of URI vs URN vs URL is not a show stopper. The
SW can proceed even using HTTP URLs for names (hampered by their
shortcomings). Those who understand the issues will use URN schemes
for names and URL schemes for locations and be happier for it. Those
who don't will face the music in due time. But, as pointed out in
this thread, the issues are really about management, not about their
inherent suitability as universal identifiers (aside from the case
of non-synonymous reuse).

Though there are "social" issues of how such choices of URI scheme
might impact the global SW as a whole, such that the choice of someone else 
to use HTTP URLs (or any other persistence-challenged URI scheme) for names 
impacting my SW agent because those URIs become reused and introduce
ambiguity 
into the mix, etc. is not nearly as critical as the present and persisting 
disconnect between QNames and resource URIs -- which IMO is far more serious

(see my posting to the www-rdf-interest@w3.org list in June entitled "A
proposed 
solution to the RDF syntactic/semantic mapping problem." and the subsequent
thread
for more details).

Cheers,

Patrick

--
Patrick Stickler                      Phone:  +358 3 356 0209
Senior Research Scientist             Mobile: +358 50 483 9453
Software Technology Laboratory        Fax:    +358 7180 35409
Nokia Research Center                 Video:  +358 3 356 0209 / 4227
Visiokatu 1, 33720 Tampere, Finland   Email:  patrick.stickler@nokia.com
 

> -----Original Message-----
> From: ext Sean B. Palmer [mailto:sean@mysterylights.com]
> Sent: 05 August, 2001 00:10
> To: Roy T. Fielding
> Cc: uri@w3.org; www-rdf-interest@w3.org
> Subject: Re: URIs vs. URNs vs. URLs
> 
> 
> > So what?  Names that are not used are not useful, period.
> > Names that are not useful are never created.  Names that
> > are never created cannot be the basis of a formal reasoning
> > system like RDF.
> 
> Of course not. The point is that names in RDF are used; they don't
> just sit on the shelf wanting to be loved. Take the log namespace that
> TimBL created for FOPL in RDF at [1]. It wouldn't have made the
> slightest bit of difference to an RDF processor (namely, the
> aforementioned CWM that takes these URIs as primitives) if the terms
> therein were URLs, URNs, mid:s, TAGs, TANNs, PTSs, or whatever. So
> long as they aren't reused by someone else, because then you get the
> problems.
> 
> It's the problem of reuse which I am levelling at URLs for the
> Semantic Web, and while I admit that it's not something that's going
> to happen on a regular basis, it's something that should occur at all.
> 
> It doesn't matter that URLs break on the "Web" as in browsing, because
> there's no major hassle caused: you just can't get to a Web page. But
> if two systems clash on Semantic Web terms, you cause confusion,
> confusion which is utterly pointless when you consider that you don't
> *have* to use URLs. Once again, I admit that in the majority of cases,
> people should be able to keep up some level of persistence, but for
> others, paying out $250 for a domain for ten years (or whatever it is
> now) isn't all that cost effective. URLs were designed to get you
> data, and they do that job exceedingly well: testament to that fact is
> the hundreds of billions of active URLs out there today. But on the
> SW, we often don't need that functionality.
> 
> > So, unless this is yet another exercise in navel gazing, using
> > anything other than the same old names that everyone else
> > uses (commonly known as URI) is a total waste of time.
> 
> Who said I was going to use anything other than URIs?
> 
> [...]
> >  To increase scope, people add some more identifiers (like
> > my last name, my last known address, the institutions where
> > I worked, etc.).  They don't add syntax.
> 
> Hmm... you must have a different definition of "syntax" to me.
> 
>    name = firstname
>    fullname = firstname ' ' surname
> 
> Two different syntaxes, more scope in the latter (i.e. can operate in
> a larger context).
> 
> [...]
> > The fact that some DNS names are not permanent is simply
> > not relevant to my scope.  If I want better scope, I use more
> > names or pay for more resources to keep that name around
> > a lot longer.
> 
> Er... could you possibly give some practical examples?
> 
> [...]
> > PURL is maintained by the OCLC, which is essentially a
> > library (albeit an experimental one).  W3C is not.  However,
> > I am quite certain that if you give MIT a million dollar trust
> > fund, they will give you an mit.edu URL that will be permanent.
> 
> So every time that I want a persistent identifier, I have to donate
> millions of dollars to the W3C? Every time I want a persistent
> identifier, I have to put it on the news and go into advertising? All
> I want is a URI scheme that I can get for free, and won't be used by
> someone else. It's not difficult, and it has nothing to do with "how
> many people are going to recognize it". That part is the deployment of
> the term, and it comes after creating it. I'm interested in the
> planning, making sure that no unforeseen problems could occur *when* I
> start to deploy it.
> 
> > > [...] 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?
> >
> > No, but no one can use that scheme until you do build those
> > tools and deploy them to the extent that the new name is more
> > significant than some other name.  Nobody has done that for
> > URN without an additional layer of indirection --- a resolution
> > service that interprets the URN --- [...]
> 
> Once more, I'm building systems which don't necessarily need to
> resolve the identifiers to work. Traditionally, this is an odd idea,
> but it's true: namespaces are just names, RDF predicates are just
> names. No resolution, just names.
> 
> > ISBN names are an excellent example.  They are not
> > legitimate URNs, since publishers are allowed to reuse
> > them for multiple books [...]
> 
> I agree: there's no particular point in having the "urn:" junk on the
> front of an ISBN scheme, and I don't think I've ever used the ISBN
> scheme with the "urn:" prefix. It's just a new URI scheme.
> 
> > [...] What makes an ISBN useful is that it is used on the
> > back of every book, not the fact that you can squeeze it
> > into a URL or URN syntax.
> 
> Again, very much agreed. And it's a good example of why deployment
> makes an identifier persistent. But once again, it's not that which
> I'm having problems with, it's the fact that we need to make sure that
> identifiers don't clash in such a way that it breaks a system. I can
> foresee that happening with RDF.
> 
> > > [...] 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.
> >
> > As opposed to finding a URN with any quality of service?
> 
> As opposed to finding a URI with any quality of service: URNs
> included. People do want to deploy RDF, and they do get confused with
> using URLs as identifiers; one flick through XML-Dev searching for
> messages with the term "namespace" in them will prove that.
> 
> If RDF is deployed on as wide a scale as people are predicting/hoping,
> then the lack of deployment problem will be irrelevant. Quality of
> service is a different thing for namespaces in XML and triples in RDF
> as it is for links in HTML.
> 
> [1] http://www.w3.org/2000/10/swap/log#
> 
> Interestingly, TimBL recently changed the above from the same with
> ".n3" on the end (before the hash, of course). I wasn't too impressed;
> I still have broken code lying around! :-)
> 
> --
> Kindest Regards,
> Sean B. Palmer
> @prefix : <http://webns.net/roughterms/> .
> :Sean :hasHomepage <http://purl.org/net/sbp/> .
>

Received on Monday, 6 August 2001 06:46:29 UTC