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

[John C Klensin <[e-mail]>]

--On Friday, April 18, 2014 22:34 -0400 Phillip Hallam-Baker
<[e-mail]> wrote:

>> 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.

As Mark Nottingham suggested and I tried to elaborate, this
particular discussion may be interesting (or not), but, in the
current context, isn't worth the energy it takes.  

First, a UPC code for a can of beans isn't a URN.  If an
identifier for those were documented and registered as an NID,
or if it were treated as part of an identifier sub-space within
the "epc" NID specified in RFC 5134, _that_ would be a URN.  As
a URN, the defining materials would presumably come with a lot
of information about what it was and what operations could be
performed with it.  For a URN based on that UPC associated with
a can of beans, those operations might include whether its
purpose is just to distinguish one brand or can-size of beans
from another or whether it can be used to retrieve a product
(see below).

That set of distinctions is not just pedantry.  If "URN" mean
whatever someone claims it means at a given moment, then we
don't have a specific category of identifier, we just have a
very generic term for some variety of identifier.  For the
information it contains, one might as well have the above
statement read "UPC code for a can of baked beans is an
Ironduck".

Even ignoring whether it is a URN or not, a UPC doesn't act as a
UPS-mediated locator, any more than urn:isbn:0-88175-188-X is a
TCP-medidated locator.  It is an identifier of an abstraction of
a class of objects.  To get the object to your doorstep, it is
typically necessary to resolve it to a different product
abstraction, to a warehouse and location in it, to a
shelf-picking mechanism, and so on, typically through several
step before a particular can-instance is finally chosen, boxed,
labeled, and handed over to UPS (or some other transit carrier
whose choice might be another item in the list of
abstraction-resolutions.

In addition, like many URNs (see my notes on the URN list),
there are other useful questions that apply to the
generically-named object and not to the particular can that
might be located.  For example, "what is the size of the can
associated with that code" is a question about the generic named
object.  "What is the sell-by date" probably still doesn't apply
to a particular can that needs to be located and retrieved
before the question can be answered -- perhaps it is sufficient
to locate a case of cans and to do so in an appropriate database.

So I suggest they are still different from http-type URLs in
more ways than the [retrieval] method.   But, again as Mark
Nottingham pointed out, it may be that the greatest value of
this proposed separation is to get around the situation of
different communities talking past each other and being
unwilling to accept each other's perspective and legitimacy even
to the extent needed to have a real conversation.

     john