Re: [urn] URN standard

["Hakala, Juha E" <[e-mail]>]

Hello John; all,

(also a personal opinion only)

Considering just the URN syntax, the only library related requirements I am aware of involved URI fragment and query. We wanted to use the former to indicate locations within identified documents, and the latter to pass resolution related parameters to URN resolvers. Since our needs were relatively modest, URNBIS has already met our requirements and then went on to specify additional features.  And IMO there is nothing wrong with what 2141bis says (but I need to check the latest draft, just in case). 

I am not aware of any immediate need for newly minted URN features such as r-components, but library community may find uses for it later when our resolvers become smarter. As John says below, traditional identifiers are not and cannot be carved in stone. Digital publishing has changed and is still changing the ways in which ISBN, ISSN etc are used. Several systems are currently under revision, and in some cases changes may be substantial. Many identifier systems will specify how they can be made actionable as DOIs, URNs etc. New ISBN standard is one of the first examples of this.  

There are also new challenges, such as increasing need within publishing community and libraries to develop a standard-based solution for identification of logical fragments (assuming that URN + fragment can deal with physical ones, we still have a lot of cases when namespaces must develop their own solutions to identify logical parts of documents which lack proper physical encoding). 

Once the syntax revision is complete, we (I hope) need to take a closer look on mechanism for registering resolution services and parameters, and then specify to they are encoded as queries. How resolvers then deal with requests is a different matter; often it will be sufficient to know, which server(s) will be able to process the request and which protocol(s) they support. 
   
 Juha Hakala
 Senior advisor

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

 Gsm: [phone]
 email: [e-mail]

________________________________________
Lähettäjä: John C Klensin <[e-mail]>
Lähetetty: 16. kesäkuuta 2015 13:00
Vastaanottaja: Hakala, Juha E; Michael Mealling
Kopio: [e-mail]; Keith Moore
Aihe: RE: [urn] URN standard

--On Thursday, June 11, 2015 07:12 +0000 "Hakala, Juha E"
<[e-mail]> wrote:

>...
> I am afraid that the knight on the white horse is galloping
> away ;-), but there are no problems we librarians wouldn't be
> able to solve without his help. But we do need some support
> from IETF to make the identifiers do the tricks required.

Hi.

(personal opinion only)

I've found this discussion very useful in terms of understanding
both the context of the issues and the issues themselves.
However, I --and I hope all of us-- have a very specific and
narrow problem, which is to establish a syntax and registration
model in 2141bis that is sufficient to support whatever problems
or requirements are out there or that might be developed in the
reasonably near future.

To that end and noting that 2141bis-12 has been posted...

* If what it specifies does not provide the "support from IETF
to make the identifiers do the tricks required", it would be
good (actually, it is probably vital) to know, really soon now,
what is missing or wrong and, in very specific terms, how it
might reasonably be corrected.

* Part of that support question is whether the current version
of the registration templates and descriptions allow the
necessary information to be supplied, require what should be
required, provide enough hints and justification about what
information is needed that we are likely to get that
information, and, where appropriate, are clear about what needs
to be supplied in-line and what can be provided by reference.
If anything is not clear or complete enough, this is the time to
say so.

* There are some examples in 2141bis to illustrate applicability
of r-components and q-components.  I think they may be wrong and
that they really need checking (and other ones
specified/provided as appropriate) by people who have a clear
idea of what they are intended to mean.  The text about where
those queries go is also not as clear as I would like it to be
and that may be part of the problem, but it is about as good as
Peter and have been able to do so far.  Text would be
appreciated.

* The text about persistence has been removed from 2141bis.  The
recent threads of conversations have convinced me (at least),
that an updated and up-to-date "theory of URNs" document would
be very useful, but that (i) it isn't in the WG's charter, (ii)
getting it into the WG's critical path would probably kill this
effort, (iii) putting arbitrary small bits of it into 2141bis is
likely to add to, rather than reducing, confusion, and (iii) we
should almost certainly postpone work on that document (or even
figuring how to organize that work until after 2141bis is
finished).

* I discovered in a very helpful conversation last week (with
someone who still considers herself a librarian, by the way),
that there is a great deal of research going on about
identifiers in the Internet era, work that still pays attention
to non-electronic "resources" and that probes at what terms
like, e.g., "resource" are coming to mean.  The conversation
also convinced me even more of the wisdom of confining 2141bis
as much as possible to syntax and then moving the other
discussions to forums where the level of carefully-researched
knowledge is much higher than it is in the IETF.   Details
(including references and pointers) after I get my notes
together, but probably not until after 2141bis is locked down.
If anyone needs them for ongoing work that won't get in the way
to 2141bis, write me offlist.

I want to stress that I'm not speaking for the WG, the
Co-chairs, or even for Peter, but my assumption at the moment is
the penultimate version of 2141bis before WG and IETF Last Call.
In other words, we get the input asked for above, do one more
revision, and then should be ready to wind this effort up.
That schedule is also consistent with my/our not running out of
energy to keep waiting for the comments needed to make revisions.

I look forward to hearing from everyone who is involved and
interested.

best,
     john