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 Saturday, 4 August 2001 17:10:02 UTC