Subject: Re: [urn] urn:ietf:rfc

From: Juha Hakala <[email-masked]>
Date: Thu, 03 Jul 2014 11:49:15 +0300

Hello,

Some comments below.

On 30.6.2014 21:54, Svensson, Lars wrote:
> John,
>
>>
>>>> Some comments below, mostly to clarify my earlier note to
>>>> which both of you partially responded.  First, and most
>>>> important, please understand that, while I have biases and
>>>> opinions about URNs and their proper definition and use, I'm
>>>> trying to be completely pragmatic about this.  That means I
>>>> am putting three strategic principles ahead of declarations
>>>> about what is or is not correct from some perspective.  Those
>>>> pragmatic principles are
>>>>
>>>>   -- try to accommodate all of those who think URNs are
>>>> 	necessary, i.e., that they are distinct from URLs.
>>> Well, of course they are.
>> Unless I've misunderstood a number of remarks, your "of course"
>> view is not universally shared.

Outside the persistent identifier community (people using Handles, DOIs, 
URNs and ARKs) it is not uncommon to think that URI replaces both URL 
and URN, and that "a URI may be a a name and a locator at the same time" 
(see http://en.wikipedia.org/wiki/Uniform_resource_name).

I find the word "may" in the quote interesting, since that allows URNs 
and URLs to be distinct. But the image showing relations of URIs, URLs 
and URNs in the Wikipedia page quoted above is not correct. RFC 3986 
says that every URI is a name (identifier) and in addition URI can also 
be locator (but not a location). So term URL refers to the subset of 
URIs that, in addition to identifying a resource, provide a means of 
locating the resource.

See http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html for more 
information about this.

PID community does not share the view of RFC 3986 that every URI is a 
name (identifier). But folks using e.g. DOIs have no problems with RFC 
3986, since URI Generic Syntax is only explicitly attacking URNs, not 
other PIDs.

> My reading of the discussion is rather that we (== "the community") don't differ on the necessity of URNs. To me the big question is if we can say URI==URL. I say it's not. There are names and there are locators. In some settings, it makes sense to use a locator as a name (and sometimes it doesn't). In my eyes that doesn't make all URIs URLs (but perhaps I live in a parallel universe...).

RFC 3986 puts it other way: sometimes it makes sense to use a name as a 
locator.

To me, the real issue is that introducing URIs in RFC 3986 has made 
things more confused, especially for the PID community in general, and 
URN users in particular (since of all PIDs, URN is bearing the brunt of 
the attack). But as the DOI community points out (see 
http://www.doi.org/factsheets/DOIIdentifierSpecs.html), replacing URN 
and URL with URI has generic harmful practical implications.

>
>
> The difficulty
> is that we don't have a URI syntax definition that is ultimately:
>
>     Method: <stuff> <single-terminating-delimiter>
>
> Instead, we have a lot of Method-dependent stuff that affects
> how the rest of the URI (whatever that means) is parsed and
> interpreted.

In some (most?) URN namespaces, NSS syntax is well defined and an 
application parsing the namespace specific string will know where the 
identifier ends. It may also be possible to find out with check sum if 
the identifier is well formed.

This parsing would of course cover just the NSS, not the fragment or 
query (if present).

>
>>> This seems to be the place where we need to find a common view
>>> on things. My reading is that URIs (as defined by 3986) are
>>> _always_ identifiers and that _some_ URIs (depending on their
>>> scheme) are also locators.

Yes, this is what RFC 3986 says. So according to the URI Generic Syntax, 
my email address [email-masked] identifies me (or my mail box 
in the Helsinki University mail system, or both), even though email 
addresses are not locators.

For anyone who has had any real involvement with identification of 
people and / or their public identities, the idea of using email address 
as the identifier for a person is a bad joke. There are situations when 
email address, alongside the name, can help us to tell apart two people 
with the same name. But people usually have multiple email addresses, 
and their emails change. Proper identifiers should be persistent and 
unique, and there are a lot of URIs out there which are neither.

The authors of RFC 3986 could not take a qualified approach and say that 
only some URIs are identifiers because then they would have been left 
with what they started from: URLs. And of course RFC 3986 does not 
require uniqueness and persistence, since that requires (for instance) a 
well managed URN namespace.

>>> To the "pure identifiers" I count
>>> e. g. geo:, xcon: and crid: (and urn:), while e. g. http:,
>>> ftp: and smtp: would be locators as well. So in my view, we
>>> cannot generalise URLs into URIs, which would allow us to keep
>>> URNs as a subclass of URIs.
>> As I've tried to say before, I think that a philosophical debate
>> about the precise proper usage of the term "identifier" is
>> extremely interesting but doesn't lead us anywhere on which
>> agreement is likely in the foreseeable future.  That makes one
>> important question whether we are willing to delay any progress
>> on URNs until we do agree.

In RFC 3986 the scope of the term identifier is completely different 
from what e.g. libraries and publishers are used to.  This semantic 
difference has also massive practical implications. Assigning social 
security number to a person, or ISNI / ORCID to a public identity of 
that person, is very different process than getting an email address 
from Gmail. The latter has nothing to do with identification.

>>
>> However, "we cannot generalise URLs into URIs,..." is a
>> statement with which I've come to agree.   RFC 3986 is precisely
>> a generalization of URLs into URI.  Yet another view of it is
>> that it attempted the impossible (or contradictory) and failed.
>> So where does that leave us?

Had RFC 3986 been successful, usage of URNs and other persistent 
identifiers would be diminishing. But during the last decade 100 million 
DOIs (and much more Handles and URNs) have been assigned, because 
significant communities out there don't think that a locator is an 
acceptable name.

What is happening is that important digital resources (proper 
publications, scientific data sets, applications) made available in the 
Web very often get persistent identifiers which are resolved to URLs. 
The cool URI philosophy underlying RFC 3986 is being ignored by 
libraries, publishers, universities and others who own or host 
significant digital resources and / or must preserve them in the long term.

These communities may take PID standardization in their own hands if 
they don't get from IETF what they want. Handle system and DOI are 
already being maintained elsewhere (ITU and ISO, respectively), and if 
URNBIS gets completely bogged in philosophical  debates, it will also be 
hosted by other, less theoretical organizations in the future. Basically 
we just want to make our existing identifiers actionable in the Web, and 
it is rather frustrating that achieving this has turned out to be 
complicated because (among other things) there is something wrong with 
URI Generic Syntax.

Juha

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678