Re: [urn] Tuning the "URNs are not URIs" spec

[Juha Hakala <[e-mail]>]

Hello,

On 17.6.2014 23:15, Dale R. Worley wrote:
>> From: John C Klensin <[e-mail]>
>>     Instead, the question is whether the IETF is willing to
>>     evolve and adapt the URN definition to accommodate those
>>     perceived needs or whether if prefers to have that work
>>     done elsewhere, either by adoption in the broader
>>     community and marketplace of a different approach or,
>>     potentially, even a competing URN standard.
> As far as I can tell, the key question is "Is the syntax of RFC 2141
> ("URN syntax") inadequate for the needs of important groups of users?"
Urnbis charter requires (among other things) the WG to make

> an update of the formal syntax specification in the light of the
> URI Standard (STD 66, RFC 3986) using the ABNF from STD 68
> (RFC 5234)

In practice, two major changes are needed: revised URN syntax should 
allow the use of fragment and query.

The use of URI fragment to indicate locations within identified 
resources enables creation of URN-based citations instead of URL-based 
ones. But in order to avoid breaking the assignment rules of traditional 
standard identifiers, RFC2141bis must make it clear that the fragment is 
not part of the namespace specific string (that is, from URN point of 
view, it does not identify anything).

There is definitely also a need to use URI query for passing resolution 
related parameters to URN resolvers. URN resolvers currently in use are 
dumb; of all the resolution services specified in RFC 2483 they usually 
support by default only URN - URL mapping (to a single URL only). This 
is insufficient, since users may not want the document itself. Instead 
they may be interested in descriptive metadata about the resource, or 
other versions of the resource (work), etc.

DDDS  (Dynamic Delegation Discovery System) has been available since 
2002 as a means for passing service related information to resolvers, 
but it has not become popular. URI query provides a more lightweight and 
technically sufficient means for making URN resolvers smarter.
> If the syntax is adequate, then various groups of users can define
> namespaces that have the properties that they desire without causing
> any upset in running code; at most, revisions would be needed to RFC
> 3406 ("URN namespace definition mechanisms").  (Unlike IPv4 addresses,
> we aren't in danger of running out of namespace identifiers.)
Services available in namespaces depend to large extent on applications 
used to manage the identified resources. That is, resolution services 
supported by a namespace will change over time.

For instance, with their current systems (such as integrated library 
systems and open repositories) libraries could in principle support all 
the URN resolution services specified in RFC 2483. In fact, there is 
already a problem since metadata about resource can be supplied in many 
metadata formats, and RFC 2483 does not allow the libraries to specify 
the format (it is supposed to be URC or Uniform Resource 
Characteristics, which does not exist).

In the future, when e.g. national libraries will establish digital 
preservation systems, a lot of new services will be available. For 
instance, a user can check if there are earlier / later versions of the 
identified resource in the digital archive. He will be able to compare 
the intellectual content of successive versions of the work, which may 
differ due to migrations needed to maintain the usability, and check 
which applications will be needed to render the preferred version readable.

>
> (And for example, this flexibility allows multiple sets of identifiers
> which handle name/locator differences in distinctly different ways.)
>
> What seems to be constantly hinted at in this discussion -- but never
> explicitly stated -- is that important groups of users have needs that
> CANNOT be satisfied within the syntax of RFC 2141.

I have tried to make it clear that for instance library community needs 
additional functionality which can be provided by query and fragment.

> Not just that the
> particular definitions of "fragment" and "query" in RFC 3986 are
> inadequate for their needs, but that those needs cannot be satisfied
> by *any alternative means* that can be represented within the syntax
> of RFC 2141.
I can't see an acceptable alternative for the usage of fragments. 
Everyone must be able to make citations and references, but identifier 
assignment - when done properly - is a managed process.

DDDS could be used instead of query, but slow / non-existent adoption of 
the former during the last decade makes it clear to at least me that an 
alternative method is needed.

>
> If that actually is so, it is a fairly concrete fact, it shouldn't be
> very difficult to make the case in a convincing way.  And once the
> case is made, it would be a sound reason to move ahead with
> significant changes to the status quo.

The problem is that what looks convincing to e.g. library community - 
and we are not the only significant group out here which is using 
persistent identifiers - may not convince other groups which have 
different requirements and applications. If there is no need to preserve 
millions of documents for hundreds of years, even cool URIs may look 
like a sufficient solution.
>
> One objection I can see to RFC 2141 is how restrictive it is:  The
> namespace-specific string can contain only letters (two cases),
> digits, and 15 of the 32 ASCII special characters.  (That's not
> counting %, since it has a special purpose.)  I can see how a group
> may want to have much more syntactic flexibility in designing an
> identifier, and they wouldn't enjoy %-encoding a large fraction of the
> characters in their identifiers.
In practice, many communities which use URNs do not see this as a 
significant limitation. Standard identifiers often allow only a very 
limited set of characters. And even if UNICODE is allowed in principle 
(as in Handle system), it is not used in practice.

The problem some traditional identifier systems such as ISBN and ISSN 
are facing when they are applied to digital documents has to do with the 
syntax. For instance, ISBN has been extended once (from ISBN-10 to 
ISBN-13) to extend the scope of the system. And the next revision is 
already under way.
>
> OTOH, there's no reason that a user group would have to *see* what
> their URNs look like very often.  Most user interfaces that would
> refer to sophisticated identifiers don't have to reveal the URNs that
> are used one the wire, any more than that we have to see the bits that
> encode the characters of our e-mails.

Correct. If resolution service / services exist, then making an ISBN 
actionable by turning it into URN can be an automated process. And this 
actionability is all the ISBN users want from URNs. URN implementation 
should not change the scope of the ISBN system in any way.
>
> For instance, there's no reason that DOIs can't be encoded much the
> same way that EIDRs are encoded (draft-pal-eidr-urn-03):
>
>      The DOI "10.1051/0004-6361:20054201"
>      becomes the URN "urn:doi:10.1051:0004-6361%3a20054201".
>
> (Any sequence of Unicode characters can be represented as a sequence
> of %-escapes per RFC 2141 section 2.2.)
>
> The great benefit of this approach is that generic operations on these
> URNs can be done by the great bulk of currently running code.

Technically, DOIs (or Handles or ARKs) can be expressed as URNs, and 
vice versa. But there is no added value whatsoever if the URN is 
resolved in the same way as the DOI.

There is often just one traditional identifier (such as ISBN), but it 
has to be made actionable in different ways. Let's assume that we have a 
doctoral dissertation published in PDF format with an ISBN. DOI using 
this ISBN as suffix may resolve to the publisher's repository, which is 
behind a pay wall. Same ISBN as Handle may provide a link to the 
DSpace-based open repository maintained by the author's alma mater where 
the thesis is available for free. And finally the national library may 
have a legal deposit copy of the book with URN:ISBN, available for free 
but only on dedicated workstations in legal deposit libraries (so a user 
not using one of these workstations will only get metadata about the book).

In theory, all this functionality could be provided by the publisher's 
DOI resolver. In practice, this is not likely to happen, for financial 
reasons that should be quite obvious. As an aside, PID communities are 
currently considering creation of multi-PID resolvers (via e.g. adding 
URN resolution functionality to the Handle software). This is necessary 
since there are (open) repositories which contain documents with 
different PIDs.

Juha
>
> Dale
>
> _______________________________________________
> urn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/urn


-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. [phone]
  Mobile [phone]