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

From: Juha Hakala <[email-masked]>
Date: Thu, 03 Jul 2014 14:43:35 +0300

Hello,

More comments.

>
>>> OK. RFC 2483 defines a handful of these keywords and services,
>>> but not nearly enough.
>> Another example of what I'm trying to avoid.  I am certain your
>> statement above is true.  I am equally certain the trying to
>> define (or even adequately characterize) the others will bog us
>> down for a very long time and lead us to Plan C or D [2].  So
>> I'm trying to push that problem away by making those services
>> and keywords a per-NID matter.  If it turns out that we can
>> later make groups of NIDs into categories that share some set of
>> services and keywords, that would be great.  But, if we make
>> doing so, or even proving that we can do so, a condition for
>> URNs, then we will be back to where we were when I first killed
>> the URI WG.

URNBIS should not even try to specify the missing resolution services 
and parameters (if any). Creating an exhaustive list would require a lot 
of time, and after a few years, the list would no longer be complete 
because new / enhanced applications (digital archives, repositories 
etc.) will enable more services by then.

Trying to specify all these services per-NID is not an optimal solution, 
since many namespaces will support the same services. Moreover, other 
persistent identifiers such as Handles and DOIs can use the same 
services and service parameters. Trying to locate a relevant service 
from 40+ NID-specific service lists would be time consuming.

The solution I've been promoting is that RFC2483bis should specify a 
mechanism (such as IANA registry) via which the list of resolution 
services is maintained. Writing a new RFC every time a new service is 
needed is not a practical solution, but adding a new service into a 
registry maintained by IANA should not be too burdensome.

> Does this imply that we should not try to update 2483 at all but instead make the service description (keywords etc.) part of the NID registration process?

NID registrations can include a list of services supported. But such 
lists are not and will not be stable. So any listing will become 
outdated shortly, and it is not practical to demand a revision of 
namespace registration each time a new service becomes available. So the 
value of this information in namespace registrations is bound to 
diminish over time.
>
>>>>> ComparisonIndicator tells something trying to compare a pair
>>>>> of URNs for identity whether that particular ServiceRequest
>>>>> counts or should be ignored.
>>> I am not sure I understand the need for ComparisonIndicator.
>> It is a trick to avoid having to resolve the question of whether
>> a particular Service Request --or Service Requests in general--
>> are "part of the NSS".   I called it "ComparisonIndicator"
>> because I believe that, absent the question of comparing a pair
>> of URNs for equality, the "part of the NSS" question doesn't
>> need a precise answer and might be a distraction.
> I think I understand what you are aiming at, but do you think you could provide an example or two just for clarity? (No, I won't nail you down on syntax...).

To me, the question of whether service requests are part of the NSS does 
not really exist. A priori they are not, since the namespace specific 
string should only contain the identifier.

>
>>>>> ServiceTarget identifies where the
>>>>> ServiceRequest is to be sent and, depending on the
>>>>> ServiceType, may be a keyword indicator or, at the risk of
>>>>> descending into recursion hell, a URL or URN.
>>> Including ServiceTarget into ServiceRequest may not be
>>> necessary. URN resolver appropriate for the namespace in
>>> question should know which server is able to cater for
>>> ServiceRequests of given type. For instance, if a user wants
>>> full metadata about an academid dissertation, the resolver
>>> "knows" that the national bibliography should be able to
>>> fulfill the request. But if the document itself is requested,
>>> open repository (using Fedora, DSpace or some other such
>>> application) is better choice.
>> In the language I've used, what you have just said is "for all
>> NIDs, it should be possible to specify the ServiceTarget as part
>> of the definition/ registration, thereby not requiring it to
>> appear in the ServiceRequest associated with a URN and probably
>> prohibiting it there".    If that is true, it is wonderful.  But
>> I'm trying to avoid a requirement to prove such statements about
>> "all NIDs" rather than particular NIDs or, e.g., NIDs that might
>> sensibly be used in the library community.

At least up to now, if URNs in a namespace X are resolvable, then the 
namespace registration request for X must explain how the resolution 
takes place in practice. If the identifier is dumb (non-semantic), the 
explanation is simple - there can only be one resolver. ISSN is an 
example of this. If the identifier is semantic, then there can be 1-n 
resolution services. In these identifiers, NSS contains a hint which 
will assist Resolver Discovery Service to locate the correct resolver. 
For instance, any NBN starting with fi: will be resolved in Finland; 
likewise for any ISBN-13 starting by 978-951 or 978-952.

For the time being, ServiceTarget is hardcoded in HTTP URIs:

http://urn.fi/URN:ISBN:978-952-10-9989-2

but when RDS is implemented, the beginning of the ISBN will indicate the 
location of the ServiceTarget.

However, there are at least two valid use cases for ServiceTarget: dumb 
identifiers with multiple resolvers, and need to override the default 
ServiceTarget. For instance, URN:ISNI (International Standard Name 
Identifier) will normally be resolved in the ISNI database 
(http://isni.oclc.nl), but if there is a need to resolve an ISNI in the 
national authority database, that can be achieved by ServiceTarget, 
which could be an additional parameter in query (or whatever the 
ServiceRequest is called).

>>>> Two URNs should be considered to be equivalent if they
>>>> identify the same thing.
>>> Yes, and this depends on your definition of "thing"...
>> Indeed.  And I'm essentially suggesting that, in the general
>> case, we don't know how to define "thing" except on a
>> per-namespace (NID-dependent) basis.

In DOI context, they call the thing "referent"; particular object 
identified by a DOI name. Object is an entity within the scope of the 
DOI system that can be digital, physical or abstract.

Likewise, we can say that "thing" is a resource identified by a URN. And 
the resource is a digital, physical or abstract entity within a scope of 
a URN namespace (for instance, a book which is in the scope of the ISBN 
namespace).  Abstract entities are for instance works like Shakespeare's 
"Hamlet".

We can of course invent our own definitions to "thing", but IMO 
different persistent identifier systems should not become too diverse in 
this respect, because that would have a negative impact on 
interoperability. There is a chance that DOIs will be expressed as URNs 
in a future (or vice versa).

>> I believe there may be
>> categories of namespeaces (and NIDs) that would share
>> thing-definitions but we haven't even begun to talk about such
>> categories, much less their definitions and properties.
>> However, I think we can demonstrate that the differences exist
>> just by looking at the differences in starting point, language,
>> and assumptions between Juha and Dale -- both of whom, I'm
>> convinced are acting in good faith and with a good understanding
>> to the problems they need to solve for their communities.

I hope that the differences can be overcome by making the definition 
abstract enough. Since in the end of the day the scope of the URN system 
is the sum of the scopes of all URN namespaces, we need to make sure 
that the definition  does not become a Procrustean bed.

>>
>>> ...
>>>> ...because neither fragment nor query are part of the NSS.
>>> In my eyes, that is not a strong enough argument since that is
>>> obvious from the syntax urn:nid:nss?query#fragment. We need an
>>> explicit statement that says that "for identification
>>> purposes, the URN ends after the last character of the NSS.
>>> This implies that while a generic URI parser would consider
>>> the two URIs urn:example:foo and urn:example:foo?bar#baz two
>>> different URIs and thus -- without further knowledge --
>>> identifying two different resources, a URN parser would treat
>>> them as equivalent." (Or something along those lines, which I
>>> cannot find in 2141bis). I also suggest that rfc 2141bis adds
>>> some examples with queries and fragments to §6.1.

Yes, it is important to make it absolutely clear that although according 
to RFC 3986 the two URIs above identify different things, then from URN 
point of view the resource they identify is the same, although resolving 
them may provide different results.

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