Subject: Re: [apps-discuss] URNs are not URIs (another look at RFC 3986)

From: Graham Klyne <[email-masked]>
Date: Sun, 27 Apr 2014 17:37:58 +0100

[Re-sending; my previous attempt seems to have been blocked as I used a 
different email address.  But I'm not currently seeing my ninebynine email, so 
please include all my addresses in any response.]

Barry,

I'm responding to this message:

   http://www.ietf.org/mail-archive/web/apps-discuss/current/msg11826.html

but my email is broken, so I can't do a proper threaded response.

Anyways, to your message:

...

Again, addressing just one point here:

Graham said this:
> DOIs
> are conceived as names, and have the appropriate management processes
> around them applicable to names.  But I have observed that in recent times,
> the preferred form for presenting DOIs to the Web has increasingly been in
> the form "http://dx.doi.org/..."; or similar (see also: [1]).  I think this
> exemplifies something that MAY be used as both identifier and name.

Phill said this:
>> A string that *you* might *today* call a "name", might already be a
>> "locator" to somebody who's rigged a private resolution service. Ten years
>> from now, that "name" might be a "locator" to all of us.
>
> Which is exactly what I was saying.
> For example, UPC code for a can of baked beans is a URN.
> But if you go to Amazon you can use it as a locator, albeit mediated
> via UPS rather than TCP/IP.

I think both of these confuse the issue.  Given a name, we can often
turn it into a locator.  That's clear, and that's one thing that makes
names useful.  But I think we still need to keep in mind that the
names *aren't* locators.  If I can always take "urn:doi:xyz-abc",
transform it to "http://dx.doi.org/find/xyz-abc";, and get a valid
locator for the thing named, that's great.  But it's still the case
that the former is a name and *not* a locator.  And if dx.doi.org goes
away at some point, the thing is still named by "urn:doi:xyz-abc",
even though I can no longer use that locator.

>>>GK:
Sure, names are names and locators are locators (as abstractions).  But URIs are 
*strings* that are a central (mechanical, not abstract) element of the Web - I 
might go so far as to say *the* central mechanical element of the Web.

And in the Web, URIs can be used as either locators, names or both, depending on 
the context.  And this malleability is central to some of the things that are 
done today on the Web, particularly in the area of Web linked data.

It's rather like using "Barry Leiba" to talk about me, and that's fine
as long as it's a reference.  But as soon as you need to *find* me,
you have to get a locator.  The locator might or might not contain my
name; it could be "barryleiba at computer.org", it could be my phone
number, it could be a URL for my web site, or it could be a suggestion
that you look here <http://www.the-craftsman-ale-house.com/> on a
Friday evening.

>>>GK:
Or, if I'm an NSA analyst, with access to what that implies, the string "Barry 
Leiba" might well be a perfectly good locator for finding information about you 
(and those who share your name).

Again, for the purposes of abstraction, let's be sure to remember the
distinction, and to be clear about the scope of what we're discussing.

>>>GK:
The scope I am discussing is primarily the Web.  I think I've been clear about that.

Everything else is to some extent a result of using Web tools for non-Web 
purposes.  In this, I agree with a point that I think Mark Nottingham is making; 
  viz. that it may be helpful to separate Web and non-Web concerns concerning URIs.

At this point, I reflect on John K's original proposal, to recognize a 
disjointness in the space of UR{I|L|N}s.  But I think the relevant disjunct here 
is not name vs locator, but Web vs non-Web.  It may well be that in some usage, 
the name/locator is relevant, and something that needs to be articulated, but as 
a first-order concern I don't think that's true for the Web.

So I think we have a situation that URIs are just strings, with a defined, yet 
flexible, syntax and some very lightweight semantics to do with resolution of 
relative references.  (As I write, I can't think of any other semantics that are 
imposed by the URI specification.)  So I can't see any relevance to the 
discussion of names vs locators with respect to URIs qua URIs.  But there may 
well be relevance to such discussion in particular contexts of URI use (such as 
URIs used in preservation activities).  And some of those contexts may be 
applied within the Web.  But it does not make sense to me to try to apply those 
concerns to everything that takes place on the Web, as there are some aspects of 
Web usage where the unspecified aspect of a URI as name vs locator is a feature, 
not a bug.

Or, to put it another way, if you want to create a space of strings that is 
rigidly separated into strings-used-as-names and strings-used-as-locators, you 
are quite free to do so.  You may even adopt URI syntax for your name|locator 
strings.  But please don't try to retro-impose your distinctions onto the way 
that the Web uses URIs.

#g
--