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

["Martin J. Dürst" <[e-mail]>]

On 2014/04/21 14:41, Mark Baker wrote:
> On Sun, Apr 20, 2014 at 11:17 AM, Barry Leiba <[e-mail]> wrote:

>>   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.
>
> There's nothing stopping that string from being used as a locator.
>
> Even if a transformation based approach were used, all I need is
> another scheme, say "doi2" that's defined so that all its URIs can be
> transformed to an http scheme URI at dx.doi.org. Whip up a little
> Javascript registerProtocolHandler with a one line string transform,
> and whammo, doi2:xyz-abc is a locator for me.
>
> Another configuration to consider - to John Levine's point - is using
> intercepting proxies (or manually configured ones, for those not on
> the library network) to, e.g. resolve http://dx.doi.org/xx.yy.zz to
> some local copy stored at the library. I'm sure there are other
> possible configurations too, that use a similar level of indirection,
> perhaps using other mechanisms (DNS?).
>
> So let's please forget about this "name" and "locator" stuff since
> those labels are so context dependent as to be useless in any broadly
> scoped discussion like this. There are only identifiers.

Yes indeed. I occasionally get students making presentations based on 
outdated (but Japanese) material that makes a sharp name/locator 
distinction, or get asked by students about the difference between URLs 
and URNs.

I always explain that in the context of a traditional library (i.e. 
physical books), the distinction is very easy: When you want to 
borrow/read a book, you don't care which copy you get, because they all 
look the same, but in order to actually get a copy, you have to know 
where it is.

However, as soon as you move to the Web (or any other electronic 
system), things start to get blurred. Caching (in CDNs, in proxies, by 
your browser, in core memory,...) and similar tricks (multiple 
servers,...) produce lots of copies, but you for most purposes, you 
don't have to be concerned where they are, that's all handled "under the 
hood". Even where it's not, it's always easy to make it so (see examples 
above).

That's why library people used to see the name/location distinction as 
an absolute one, and there are still some applications with a strong 
tie-in to that model (which is alright by me), but why we should keep 
our infrastructure flexible to allow different models to coexist.

Regards,   Martin.