Subject: [urn] A way forward for rfc2141bis and rfc3406bis -- was: Finalizing items ...

From: Alfred Hönes <[email-masked]>
Date: Thu, 5 Jul 2012 11:26:08 +0200 (MESZ)

URN folks,

thanks to all for reviving the discussion on the rfx2141bis and
rfc3406bis I-Ds.  As the editor of both drafts, I try to sum up
below and provide a perspective for a way forward; I'll respond
individually in more detail ASAP (see endnote).

** general **

Unfortunately, stakeholders of URN Namespaces for various reasons
seem to feel discouraged to participate in the on-list discussion,
which now has been majorized by few long-time "IETF professional"
contributors.  Part of the frustration I observe also seems to be
based on the lack of constructive proposals on the list so far,
as replacement solutions for the options being voted against.

We should not forget that the prime target audience of these URN
core documents is the rather divers family of (present and)
prospective stakeholders of URN Namespaces, which frequently
have not been in contact with the IETF, but possibly with other
persistent ID schemes, _or_ which are working within the IETF,
but with a focus on a particular technology and mostly unaware
of relevant work for URNs.
Hence, the goal of the "core URN documents" should be to give
concise guidance to _that_ audience, in order to help avoid to
have to explain the same context again and again individually
(as I have done in the past couple of years).
This IMO needs to include a bit of a "marketing" effort for the
URN framework against other, concurring identifier systems.
Recently, being able to point prospective applicants of
new URN Namespaces (from inside and outside of the IETF) to
the material in the present Introductions of the rfc2141bis
and rfc3406bis drafts has been very helpful in giving guidance
on technical/document/historical context; such material is
sought by prospective stakeholders in the core documents.

** towards a way forward **

We face several general kinds of problems to deal with.
One stems from the chartered restriction to not revise the
"strategical" RFCs laying the foundation of URNs and to presently
obstain from work on services/methods and details of URN resolution
and URN services.  There seems to be consensus that some parts of
these RFCs are outdated by more than a decade of experience with
URNs.  Since we aim our work towards bringing our documents
forward on the Standards Track, we cannot make Normative
references to past, Informational RFCs.  So, as elaborated upon
in the URNbis chartering discussion, we need to incorporate
selected text from, e.g. RFC 1737, verbatim in order to remind
the readers (including prospective stakeholders of URN Namespaces)
of what we now deem still particularly valid and important for URNs.
Likewise, experience shows that we need to provide a more precise
framework for the establishment of URN services for URN Namespaces,
in order to further a uniform style -- to the benefit of generic
URN handling applications.

Unlike for other URIs, URNs in general are dedicated to be media-
and technology-independent, as almost necessitated by the target
of long-term, global scope, uniqueness, and persistence (RFC 1737,
Section 2).
Since there are various services applicable to URNs, resolution
of a URN does not have the same media orientation properties like
it is common in a HTTP/HTML context. The objects/resources named
by URNs might be structured, complex, and inter-related with the
details perhaps evolving over time, whereas the abstract object
and its naming (as done by the assignement of {NID}:{NSS}) needs
to be stable.

Our effort has been driven by a major class of mass URN "customers",
the bibliographic community.  That community has identified the
urgent need to identify in a uniform way, in the URN resolution
process, object/resource components and/or related resources.
The description in the first paragraph of Section 3.5 in RFC 3986
has lead to a URN service/resolution implementation attempt based
on the usage of fragment identifiers, and that has been reflected
in the rfc2141bis draft since its beginning as an individual I-D.

In the meantime, it has become clear that the subsequent text
in Section 3.5 of RFC 3986 is incompatible with the goals, since
it calls for URI users to strip the fragment identifier component
before forwarding a URI reference for resolution, and to apply
the fragment identifier, in a media-type dependent manner, to the
returned content.  In the bibliographic context, components might
be archived in different media items over time to maintain their
accessability, and they might be subject to diverse distribution
restrictions; so in general, it will be impossible or impractical
to return an all-encompassing response and allow the client to
select the required part.  An additional restriction of the use
of fragment identifiers is that, in practice, media types and/or
common browsers do not support to "pick a component" from the
returned resource, but represent the whole resource, pointing to
a particular spot therein, such maintain the user perception of
a "fragment identifier" essentially being used as a pointer to
a particular point in the returned media, not a particular part
of the resource.  The IETF has recently put emphasis on this
particular, strict media-type dependence of the fragment part
of URIs, and we need to accomodate that and established practice
in browsers.

In order to avoid recurrence of this issue, explaining text on
fragment use with URNs IMO needs to be present in rfc2141bis,
_and_ we need to provide a uniform working scheme for the
identified requirements.

** the proposal **

Study of RFCs and off-list conversations with folks from the
bibliographic community has lead to a model how these goals could
be achieved by a common-style usage of the <query> URI part,
and I want to present this to the WG as a way forward for
discussion before going to work out the details in the next
version of the rfc2141bis and rfc3406bis I-Ds.

Let me explain the idea with a very hypothetical (intentionally
invalid) example:

Say a book has been assigned the ISBN (ISBN-13) 987-65-4321-678-9.
Thus, per the rfc3187bis I-D, it gets assigned the URN,
            urn:isbn:987-65-4321-678-9

A resolution service might be able to provide the bibliographic
record of the book and point to reproductions of selected parts
of it, say
    - an image of the front page (cover page),
    - a text version of the table of contents,
    - some rich text copy (e.g. HTML or PDF) of the foreword,
    - the list of references included in the book
      (e.g. in the form of a set of shortened bibligraphic records),
    all of the above available for free, without restrictions to anyone;
    and
    - the Introduction section of the book (in PDF)
    available to registered (authenticated and authorized) users
    of a specific community only.

Then, specific URI references to the above URN can direct its consumer
to steer the resolution process, using the fragment part of the URI
reference:

    urn:isbn:987-65-4321-678-9
      returns the metadata for the book (default);
    urn:isbn:987-65-4321-678-9?s=I2R&c=toc
      returns the table of contents;
    urn:isbn:987-65-4321-678-9?s=I2L&c=foreword
      returns a URL for the foreword of the book;
    urn:isbn:987-65-4321-678-9?s=I2Ns&c=reflist
      returns a URI list (text/uri-list per RFC 2483)
      with the URNs of the references included in the book;
    urn:isbn:987-65-4321-678-9?s=I2L&c=sec.1
      returns a URL pointing to the Introduction (Section 1)
      of the book, which can only be resolved by authorized users.

This solution, in a nutshell, would consist of the following elements
for rfc2141bis and rfc3406bis:

o  rfc2141bis specifies
   - the forms-like syntax of the <query> component in URN references,
     as a sequence of  keyword=value  items separated by "&" chars;
     I suggest that for simplicity both <keyword> and <value> should
     be simple fixed tokens (or follow simple patterns), i.e. kind of
     enumerated value protocol elements, and hence not subject to
     internationalization
     (<keyword>s are case-insensitive, in the spirit of RFC 1737,
     <value>s should preferably be case-insensitive as well, but
     namespace-specific considerations might dictate allowance for
     case-sensitivity);
   - the handling rules: single instance of items with a particular
     <keyword> only, semantics independent of order of the items,
     items with unknown (or falsely repeated) <keyword> are to be
     ignored by the resolution service, "sensical" fallback in case
     of unknown / unsupported / not applicable <value> needed
     (these rules will support easy introduction and future extension
     of the repertoire supported by URN services);
   - a new IANA registry of "URN Resolution Query Tokens" with a
     sub-registry for <keyword>s to be used with URI references
     to URNs -- either for general use or specific to particular
     URN Namespaces --, which will be initialized with two entries
     explained below;
   - the <keyword> "s" (Service) to indicate the label of the desired
     URN resolution service;
   - the <keyword> "c" (component) to indicate the desire to obtain
     information about a particular component of the object/resource
     designated by the base URN;
   - another sub-registry of the above new IANA registry for
     <value>s used for the "s" keyword, (i.e. the "service labels"),
     which will be provisionally populated by the service identifiers
     from RFC 2483 -- leaving details to a future rfc2483bis;
   - that supported "c=" values need to be specified per URN namespace.

   Further, rfc2141bis will indicate that future URN Namespace
   registration documents (as per rfc3406bis) need to specify the
   support of the above <query> syntax by its resolution service(s),
   supported/applicable services, the default service provided,
   and the usage of "c=" (if applicable) and any other potential
   keywords for that URN Namespace and supported service.

   Explanatory material related to the issues (described above) with
   the use of <fragment> identifiers as in some recent prototype URN
   service implementations will stay in Appendices of rfc2141bis;
   this includes the mention of the choices URN namespace designers
   have for support of hierarchical (and cross-linked) resources:
   - include component identifier in registered identifier,
     making it a (perhaps distinguishable) part of the NSS;
   - support/use <query> with "c=", so the NSS registry for the
     namespace doesn't have to deal with the component information
     (which will be added value by the resolution services);
   - use <fragment> (if media types returned for particular NID
     are long-term stable and allow to support that).

   The proper use of <fragment> will be emphasized in the main body
   of rfc2141bis, with pointers to other specs, including the
   work-in-progress RFC 4288bis from APPSAWG.

o  rfc3406bis specifies the details for the above scheme expected to
   be specified in registration documents, including new entries in
   the URN Namespace registration template for supported services
   (per the "s" value IANA registry) and the usage and rules for
   "c=" (if applicable) and any other <query> keywords, including
   possible IANA registration of new keywords.

o  The definition of new service labels, and an update to the
   existing definitions is left to future work on a rfc2483bis
   document.  The inofficial rfc2482bis pre-draft circulated
   can be stripped of the definition of the URN service label
   IANA registry (then done in rfc2141bis) and focus on updates
   of service descriptions and the new services that have been
   identified in practice as being needed.

Please discuss this constructive proposal for a way forward  --
preferably by on-list comments.

Since I'll be unable to go online for the rest of July, I'll
evaluate the list discussion and comments sent in private
communications subsequently ASAP, and then provide feedback and
update the drafts accordingly; so please stay patient.

Best regards,
  Alfred.

---

From: Juha Hakala <[email-masked]>
Date: Fri, 06 Jul 2012 12:18:47 +0300

Hello,

Alfred has brought up several important issues in this message. I'll not 
respond to everything at once, but will discuss the general points, the 
way forward and the proposal separately.

This message concentrates on the general issues.

> as replacement solutions for the options being voted against.

There are not that many librarians, publishers etc. who are involved 
with standards work. And most of these standards activists concentrate 
on developing ISO standards. IETF as a whole, and the way in which it 
develops standards, is unfamiliar to book trade and libraries. So even 
if the URN system is vitally important for those organisations who use 
it, we have only a limited number of mainly technical people following 
the URNbis process.
> of relevant work for URNs.

There are on the one hand technical people who write, implement and 
maintain URN resolvers (among other tools), and on the other hand people 
who use URNs to identify resources. The former are familiar with RFCs, 
and will look for technical information from them. The latter must be 
familiar with the functionality of the URN system in general level, and 
the local URN policy in the detailed level. They cannot find the latter 
from RFCs, and they should get former from other sources than RFCs.

As an aside, there seems to be a misconception that developing a URN 
resolver is complicated. This is not the case; the resolver software 
used by the national library of Finland consists of 18 lines of Python 
code (including four blank lines). But we should be careful in not 
making the business of resolution too complex.

> (as I have done in the past couple of years).

I do not insist upon removal of the generic guidance information from 
URNbis documents (potential readers can skip the sections they don't 
need), but if we want e.g. librarians to read this information, it 
should be made available at (or linked to) places where librarians etc. 
go to find information about preservation of digital resources in 
general, such as http://www.digitalpreservation.gov/.

> URN framework against other, concurring identifier systems.

Choosing a persistent identifier system is a decision one has to live 
with for a long time. IMHO it is a big responsibility to tell somebody 
that you should use this or that persistent identifier. Moreover, no 
matter what the experts say, the choice is often based on the 
availability of software package which allows one to start Handle / DOI 
/ URN assignment easily, or mandates one of these systems (like e.g. 
DSpace requires Handles).

To be honest, currently it really does not matter whether the persistent 
identifier is endorsed by IETF or not, or even whether the technical 
requirements such as URI Generic Syntax are followed. There is a major 
project which started assigning Handles in which the fragment identifier 
and the rest of the identifier string in Handle suffix are separated by 
"@" (@ was selected because Handle syntax has not reserved it; the fact 
that it is reserved in URI syntax did not matter).

Given that the overall situation in PID assignment is a bit chaotic, it 
is important that after the revision of the URN system we can say that 
URNs follow strictly the requirements of e.g. RFC 3986, and that the 
RFCs which specify key features such as URN syntax are on standards 
track. Since no other PID system is a true Internet standard, this will 
give URN credibility compared to other PIDs. Of course, in order to gain 
more users, easy to use open source URN software package(s) are needed.

> sought by prospective stakeholders in the core documents.

True, and we will be even better off when this information is available 
in more accessible documents, and perhaps also in multiple languages.

Juha

>
> Best regards,
>    Alfred.
>
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email [email-masked], tel +358 50 382 7678

---

From: Juha Hakala <[email-masked]>
Date: Fri, 06 Jul 2012 15:31:39 +0300

Hello,

This is the second part of my comments.

> We face several general kinds of problems to deal with.

The trick is to select and solve only those problems that the charter 
requires us to solve, and leave the rest for later WGs or individual 
contributions. Having said this, I need to add that there is not that 
much that we can definitely leave for later in this message.

> URNs.

True. There are for instance many resolution services that are 
definitely relevant but which are not defined in RFC 2483.

But we do not need to solve this problem now, and the charter does not 
have a mandate for that. I have been working on an individual 
contribution which will specify a novel way of establishing URN 
resolution services, but that work can / should wait until 2141bis and 
3406bis have been completed.

Since we aim our work towards bringing our documents
> of what we now deem still particularly valid and important for URNs.

OK.

> URN handling applications.

Creating the technical framework for establishment of URN resolution 
services has been one of the weaknesses of the URN effort. There is no 
widely used open source software package like the one that has existed 
for many years for the Handle system. And locally developed resolvers 
usually provide only the basic URN resolution services, such as mapping 
the URN to (single) URL.

> of long-term, global scope, uniqueness, and persistence (RFC 1737,

I agree on technology independence, but media independence is a more 
complex issue. Many traditional identifier systems are media dependent. 
For instance, each manifestation of a book (hard back, paperback, PDF) 
must get its own ISBN. So any URN:ISBN will be forever tied to a single 
manifestation of the book. When the book in PDF is migrated to a more 
modern format, that updated manifestation shall receive a new ISBN. 
These two ISBNs / URN:ISBNs will be interlinked in metadata so the users 
can travel forward and backward in time, depending on their preferences. 
The national libraries are of course storing all the versions, so as to 
protect ourselves from mistakes made during migrations.

There are also identifiers which relate to immaterial works and are 
therefore media dependent. ISTC (International Standard Text Code) is an 
example of this. URN:ISTC therefore fulfills the spirit of RFC 1737 
fully. Those URNs will link to the metadata record which contains links 
to all the manifestations.

However, the URN system as a whole is only functional when it combines 
the work level and manifestation level identifiers.

> and its naming (as done by the assignement of {NID}:{NSS}) needs

Based on what I said above, I cannot agree with this. In all those 
namespaces which belong to manifestation identifiers such as ISBN, 
resolution is very much media oriented but however stable. National 
libraries and archives will have users who, for the sake of 
authenticity, even after hundreds of years, still want the original 
version of the digital document. Naming of these documents, given the 
assignment policy of ISBN and other systems, is as stable as it gets.

> in the rfc2141bis draft since its beginning as an individual I-D.

In fact there are two different approaches. Each namespace may have its 
own policy for identification of logical fragments which are not 
fragments in the URI syntax sense. For instance, both the entire book 
and its each chapter may receive ISBNs. When these chapters are 
published as individual files, resolving those URN:ISBNs to URLs is 
piece of cake.

When the entire book is published as a single structured file, there 
will be one ISBN for the book. Then it is possible to use fragments to 
specify the beginning of each chapter. This is based on physical 
fragments in the URI syntax sense of the word. From the ISBN point of 
view, no new ISBNs have been assigned. From URN point of view, there is 
only single URN since fragment is not part of the NSS.

In principle the chapters may receive ISBNs also in the second case. 
But using them as URN:ISBNs would not make much sense, since all these 
URN:ISBNs would resolve to the same resource.
> returned content.

As I see it, section 3.5, or the way HTTP deals with the fragments, is 
not incompatible with the goals of the bibliographic community. We would 
not use fragments to actually identify anything, but to help the user to 
get into a certain location within the identified resource. This would 
be very helpful for e.g. citing purposes.

In the bibliographic context, components might
> select the required part.

This applies to logical fragments, but it is not our intention to apply 
URI fragments to them. URI fragments will be applied to physical 
fragments of documents, to which they are applicable.

An additional restriction of the use
> of the resource.

Yes, this is why fragment is not part of the NSS, and why, if you have a 
base urn:isbn and you attach 10 different fragments to it, you will 
still have just one URN, but you have access to 10 different places 
within that particular manifestation of a resource.

And this is also why you should never use fragment in those URN 
namespaces where the identifier is not tied to particular manifestation 
of a resource or the identifier does not identify single documents. This 
means no fragments for ISCI (International Standard Collection 
Identifier) or ISSN (identifier for serials).

The IETF has recently put emphasis on this
> of URIs, and we need to accomodate that and established practice

The relevant text portions in rfc2141bis and elsewhere need to be 
clarified. The most important thing is to say that the fragment is not 
part of the NSS, and draw conclusions from that.
> be achieved by a common-style usage of the<query>  URI part,

Sorry - I am unwilling to put any fragment related data into query.

>              urn:isbn:987-65-4321-678-9

This ISBN would belong to a particular manifestation of a book, say a 
PDF version, in its entirety.
>      of a specific community only.

I am afraid that the URN resolution service would not and will not be 
able do all of this. For the time being they are simple tools with only 
a limited supporting role.

Resolution service may help the user to retrieve a bibliographic record 
describing the book, and those records nowadays often provide a link to 
the image of the book. Table of contents may be part of the 
bibliographic record, and the record may also contain links to Amazon 
and elsewhere where excerpts of the book are stored.

Adjusting the resolution services and bibliographic information systems 
in such a way that the user could request various data elements one at 
the time may be technically possible, but libraries probably prefer to 
supply this information from bibliographic systems, and not to extend 
radically the role of the resolution services.
>        returns the metadata for the book (default);

While no default behaviour has been specified, this would usually return 
the entire book. If the user wants just information about the book, 
asking for  metadata (and you can have descriptive, administrative, and 
structural metadata) is a good start.

>        returns a URL for the foreword of the book;

In some situations, the same effect can be achieved by

 >      urn:isbn:987-65-4321-678-9#toc
 >        takes the user to the beginning of the table of contents;
 >      urn:isbn:987-65-4321-678-9#foreword
 >        takes the user to the beginning of the the foreword.

Suitable structural elements could be harvested from the source 
document, and the resolver could be made aware of them. If the resource 
is not structured in the URI syntax sense, or the wanted structural 
elements are missing, metadata in the library system may contain the toc 
and reveal the location of the foreword. Alas, maintaining these URLs 
(pointing to e.g. the publisher's web site) will be difficult in the 
long term.

>        of the book, which can only be resolved by authorized users.

Libraries use another mechanism (OpenURL) for dynamic linking which 
checks whether the users are authorized to use the resource.

> for rfc2141bis and rfc3406bis:

This is a rather large nutshell :-).
>
> o  rfc2141bis specifies
>     - the forms-like syntax of the<query>  component in URN references,
>       I suggest that for simplicity both<keyword>  and<value>  should

Some of the URN resolution services may become complex. For instance, 
when a user asks for metadata about the resource, this metadata may come 
in many different formats, and the user may need to specify her 
preference. So the mechanism suggested here will be relevant in any 
case, with or without fragment functionality.

>       items with unknown (or falsely repeated)<keyword>  are to be
>       of unknown / unsupported / not applicable<value>  needed

This information will also be relevant for people who develop resolver 
applications.

>       sub-registry for<keyword>s to be used with URI references
>     - the<keyword>  "s" (Service) to indicate the label of the desired
>       URN resolution service;
>     - the<keyword>  "c" (component) to indicate the desire to obtain

We need this registry as well. At the moment services are carved in 
stone in RFC 2483, but during the 10+ years since it was written 
technology has changed, and there are many more services needed now.

>     - that supported "c=" values need to be specified per URN namespace.

I am not sure if it is a good idea to do this, given that the list of 
services and service components will grow. But there must be a way with 
which a user can check from the resolver which services and service 
components it supports.

>     support of the above<query>  syntax by its resolution service(s),

Namespace registrations should make it clear if fragment usage is 
allowed. This is based on what is being identified. If the target is a 
single manifestation of a resource, fine. If the identified object can 
be anything, then common sense can be used. If the object can never be 
something to which URI fragments in the RFC 3986 sense can be applied, 
forget it.

The registration can also list other services that may be supported. I 
don't know if we can say that some services must be supported.

>     the use of<fragment>  identifiers as in some recent prototype URN

This will be a common approach for logical fragments. In many namespaces 
the component identifiers will be identical to identifiers assigned to 
whole documents, and - of course - always part of the NSS.

>     - support/use<query>  with "c=", so the NSS registry for the

I am not sure - yet - how useful this might be.

>     - use<fragment>  (if media types returned for particular NID

There will be namespaces and documents to which this functionality is 
very useful.

>     The proper use of<fragment>  will be emphasized in the main body

I'll draft something to this effect.

>     "c=" (if applicable) and any other<query>  keywords, including

OK.
>     identified in practice as being needed.

Once we have agreed that this is the way to go, I will modify the 
rfc2483bis accordingly.

Best regards,

Juha

-- 

  Juha Hakala

---

From: "Svensson, Lars" <[email-masked]>
Date: Fri, 13 Jul 2012 09:49:59 +0000

Juha, all,

Much of the current discussion -- particularly the use of fragments -- revolves around the consequences for urn:isbn (RFC 3187bis). In my opinion, that discussion prevents us from making progress in other areas. In short, I consider the use of ISBNs to create URNs flawed and suggest that we for the time being ignore requirements arising from the use of urn:isbn.

Longer version:

As an answer to Alfred, Juha wrote:
> > and technology-independent, as almost necessitated by the target of 
> > long-term, global scope, uniqueness, and persistence (RFC 1737, 
> > Section 2).
> 
> must get its own ISBN. So any URN:ISBN will be forever tied to a 
> single manifestation of the book. When the book in PDF is migrated to 
> a more modern format, that updated manifestation shall receive a new ISBN.
> These two ISBNs / URN:ISBNs will be interlinked in metadata so the 
> users can travel forward and backward in time, depending on their 
> preferences.

This statement is dependent on two axioms/assumptions specified in URN documents:

	(1)	"Global uniqueness: The same URN will never be assigned to two different
		resources." (RFC 2141bis-02 sec 1.2)

	(2)	"Assumption #1:  Assignment of a URN is a managed process.” (RFC 3406bis-02)
		To me this means that if we create (assign) URNs merely by prefixing an
		existing identifier – as by putting “urn:issn:” in front of an existing ISSN
		– the process assigning the already existing identifier needs to be managed
		as well.

My take is that urn:isbn does not adhere to any of those criteria, at least not globally.
1)	Uniqueness: An analysis of ISBNs in the catalogue of the Deutsche Nationalbibliothek (German National Library, DNB) revealed more than 200,000 ISBNs where more than one bibliographic record shared the same ISBN. Some of those instances are OK according to the ISBN Manual [ISBN Manual], whereby it must be noted, that -- for someone used to the language of RFC 2119 -- the ISBN Manual's language is somewhat fuzzy, using a mixture of shall, should, must etc where an IETF document would use MUST. Nonetheless, an application building on the uniqueness of urn:isbn would then entail that all records having the same ISBN are the same resource, which is not true.
2)	Managed process: The assignment of ISBNs to individual publications is in many (most?) jurisdictions specified by the ISBN Manual [ISBN Manual] but delegated to the publisher. A publisher wishing to use ISBNs to identify his publications buys a number range from a national ISBN centre. In many cases, the national centre has no control over how the publisher uses the assigned number range and if he (willingly or not) assigns the same ISBN more than once. A national library _could_ be a control point, but that assumes that a) legal deposit is in place, so that the national library can be certain that _all_ publications can be checked and b) that the national library is in a position to check ISBNs _before_ the book is published. National libraries are generally documentation centres (i. e. we document what has been published) so when a publication arrives it is often too late to change an improper ISBN anyway...

The above statements about uniqueness are based on an ad hoc-analysis of data from the DNB. The first step was to collect all internal record identifiers sharing a common ISBN and to output a list of ISBNs pointing to more than one internal identifier. The second step was to manually evaluate a randomly chosen set of identifiers and see if the identified records actually are different or not. I could identify (at least) five different cases:
1)	The publisher has re-used an ISBN for two entirely different publications. Example: urn:isbn:3-332-00079-9 would identify [1] and [2]. This violates 5.1 of the ISBN Manual [ISBN Manual]
2)	The publisher has re-used an ISBN for the same publication in two different formats (e. g. print and electronic). Example: urn:isbn:3-8272-6986-5 would identify [3] and [4]. This violates 5.4 of the ISBN Manual.
3)	The publisher has used the same ISBN for two editions of a publication, where there has been no change of content (unchanged reprints). Example: urn:isbn:3-10-048198-4 would identify [5] and [6]. This is OK according to 5.2 of the ISBN Manual.
4)	The publisher has used the same ISBN for two editions of a publication where there has been a (significant) change in the content (augmented or revised reprints). Example: urn:isbn:3-921885-30-2 would identify [7] and [8]. This violates 5.2 of the ISBN Manual.
5)	The publisher has assigned an ISBN to a media bundle (e. g. a book with an accompanying CD or a collection of books sold as a bundle, such as the complete Works of William Shakespeare). Examples: urn:isbn:978-3-609-62394-8 would identify the media bundle [9] consisting of [10] and [11] (a book with a CD-ROM). This is OK according to 5.6 of the ISBN Manual.

A more thorough evaluation will provide data on the relative frequencies of those four cases and possibly identify further ones. And yes, the data indicates that some publishers are more notorious than others...

So what does this mean?
1)	We should stop using urn:isbns as globally unique identifiers, because they aren’t. The only statement we can make is that urn:isbn:xxxx identifies whatever the owner of xxxx says it identifies, which might not be uniquely determined. There is no way the urn community, the IETF or any other agency can globally control ISBN assignment and much less enforce the rules laid down in the ISBN Manual [ISBN Manual]. If you cannot control uniqueness, you should not regulate it (and much less you should build applications that depend on it).
2)	I propose that we deprecate RFC 3187 and cease work on 3187bis, at least until the questions of uniqueness and process management have been clarified. The process question requires close co-operation with the International ISBN Agency (which Juha does anyway, as far as I know). Alternatively, RFC 3187bis can state that the use of urn:isbn is restricted to certain registration group elements (e. g. 951 and 952 since it seems to work in Finland), but I doubt that that is feasible.
3)	When discussing the use of fragment identifiers in RFC 2141bis, we should ignore potential use cases stemming from the use of urn:isbn.

All the best,

Lars

[1] http://d-nb.info/870687158
[2] http://d-nb.info/881221112
[3] http://d-nb.info/1015716695
[4] http://d-nb.info/976818019
[5] http://d-nb.info/946281599
[6] http://d-nb.info/870379119
[7] http://d-nb.info/800228464
[8] http://d-nb.info/810433923
[9] http://d-nb.info/988495430
[10] http://d-nb.info/986478970
[11] http://d-nb.info/988495589
[ISBN Manual] ISBN User's Manual. International Edition. Sixth Edition. London 2012. http://www.isbn-international.org/pages/media/Usermanuals/ISBN%20Manual%202012%20-corr.pdf   

***Lesen. Hören. Wissen. 100 Jahre Deutsche Nationalbibliothek*** ***Reading. Listening. Understanding. A century of the German National Library***

--
Dr. Lars G. Svensson
Deutsche Nationalbibliothek / Informationstechnik http://www.dnb.de/ [email-masked] http://www.dnb.de/100jahre

---

From: "Svensson, Lars" <[email-masked]>
Date: Fri, 13 Jul 2012 15:44:01 +0000

Juha, all,

> This is the second part of my comments.

And of my comments, too. They are not intended to be off-putting, but simply an attempt to nail down problems so that we can move forward.
 
> On 5.7.2012 12:26, Alfred   wrote:

[...]
> definitely relevant but which are not defined in RFC 2483.

Yes, and Alfred gives us a very nice set of requirements for RFC 2483bis below.

[...]
> > forward on the Standards Track, we cannot make Normative references
> to
> > past, Informational RFCs.  So, as elaborated upon in the URNbis
> > chartering discussion, we need to incorporate selected text from,
> e.g.
> > RFC 1737, verbatim in order to remind the readers (including
> > prospective stakeholders of URN Namespaces) of what we now deem still
> > particularly valid and important for URNs.
> 
> OK.

Agreed.
 
> in
> > order to further a uniform style -- to the benefit of generic URN
> > handling applications.
> 

I believe that most institutions interested in this wait for the RFC 2483bis so that they know which services to provide. It's probably a chicken/egg-problem, everyone waiting for the other one to make the first move.

> > Unlike for other URIs, URNs in general are dedicated to be media- and
> > technology-independent, as almost necessitated by the target of

I commented on this in my previous mail: In order to go forward we should ignore ISBN for the time being.

> therefore media dependent. ISTC (International Standard Text Code) is
> an example of this. URN:ISTC therefore fulfills the spirit of RFC 1737

As an aside: ISTC works on the frbr:Expression level (different language versions receive different ISTCs) cf. ISTC Manual [ISTC Manual] Sec 7.1.

> > Since there are various services applicable to URNs, resolution of a
> > URN does not have the same media orientation properties like it is
> > common in a HTTP/HTML context. The objects/resources named by URNs
> > might be structured, complex, and inter-related with the details
> > perhaps evolving over time, whereas the abstract object and its
> naming
> > (as done by the assignement of {NID}:{NSS}) needs to be stable.
> 

This is only true if we can rely on everyone playing according to the rules. Since we can't, we should not rely on an ISBN being coupled to an object of a specific media type.

[...] <Snipped discussion about urn:isbn>

> > In the meantime, it has become clear that the subsequent text in
> > Section 3.5 of RFC 3986 is incompatible with the goals, since it
> calls
> > for URI users to strip the fragment identifier component before
> > forwarding a URI reference for resolution, and to apply the fragment
> > identifier, in a media-type dependent manner, to the returned
> content.
> 
> not incompatible with the goals of the bibliographic community. We
> would not use fragments to actually identify anything, but to help the
> user to get into a certain location within the identified resource.
> This would be very helpful for e.g. citing purposes.

I agree that the possibility to use a persistent identifier to point to a particular location in a resource will be _extremely_ helpful to researchers and other people who want to cite the sources they use. However, if we do not use the fragment to identify anything, we should find another name than "fragment identifier". On the other hand, if we want to help the user to get into a certain location within the resource, we need a something so that the system can find that location. That something is an identifier (identifying that location).
 
> > restrictions; so in general, it will be impossible or impractical to
> > return an all-encompassing response and allow the client to select
> the
> > required part.
> 

What is the difference between a "logical fragment", a "URI fragment", and a "physical fragment"? Which is the one referred to in RFC 3986 sec 3.5?

> returned
> > resource, but represent the whole resource, pointing to a particular
> > spot therein, such maintain the user perception of a "fragment
> > identifier" essentially being used as a pointer to a particular point
> > in the returned media, not a particular part of the resource.
> 
> Yes, this is why fragment is not part of the NSS, and why, if you have
> a base urn:isbn and you attach 10 different fragments to it, you will
> of a resource or the identifier does not identify single documents.
> This means no fragments for ISCI (International Standard Collection

Or ISBN, because no-one can ensure that there is a bijection between an ISBN and a particular manifestion.

> > particular, strict media-type dependence of the fragment part of
> URIs,
> > and we need to accomodate that and established practice in browsers.
> 

Yes.

> > fragment use with URNs IMO needs to be present in rfc2141bis, _and_
> we
> > need to provide a uniform working scheme for the identified
> > requirements.

Yes.

> > bibliographic community has lead to a model how these goals could be
> > achieved by a common-style usage of the<query>  URI part, and I want
> > to present this to the WG as a way forward for discussion before
> going
> > to work out the details in the next version of the rfc2141bis and
> > rfc3406bis I-Ds.
> 

With "fragment" here, do you mean "logical fragment", "URI fragment", or "physical fragment"?

> PDF version, in its entirety.

Or a printed book in your bookshelf. Or a package of books (complete works), or -- against the rules but done anyway -- a printed book and its e-book version.

> record
> > of the book and point to reproductions of selected parts of it, say

I think this is a very good set of requirements for resolution services.

I will snip the rest of the discussion on resolution services for urn:isbn.

> and elsewhere where excerpts of the book are stored.

We could integrate those services into our library catalogues.

> radically the role of the resolution services.

What if someone else decides to build his own library catalogue from the linked open data libraries supply?

[...]

> In some situations, the same effect can be achieved by

In which situations?

> elements are missing, metadata in the library system may contain the
> toc and reveal the location of the foreword. Alas, maintaining these
> URLs (pointing to e.g. the publisher's web site) will be difficult in
> the long term.
> 

That could be integrated into the resolver. OpenURL [OpenURL] is one way of doing that and not all libraries use it.

> > for rfc2141bis and rfc3406bis:

[...] 
Agree with the snipped text and Juha's comments.
 
> which a user can check from the resolver which services and service

Would it work that the URN namespace specifies a (changing) document where the components are listed? Then we don't need to update the rfc every time something changes.

> something to which URI fragments in the RFC 3986 sense can be applied,

According to what I understood, fragments in the RFC 3986 sense can always be used. The question is if they make sense for all urn namespaces. The namespace registration should make that clear.

> don't know if we can say that some services must be supported.

Some services probably should be mandatory.

> This will be a common approach for logical fragments. In many
> namespaces the component identifiers will be identical to identifiers
> assigned to whole documents, and - of course - always part of the NSS.

Again: what are logical fragments?
 
> > preferably by on-list comments.

Yes, a very helpful proposal!

All the best,

Lars

P. S. I shall be offline until August 8, so don't hold your breaths for answers from me...

[ISTC Manual] http://www.istc-international.org/html/multimedia/pdfs/ISTC_User_Manual_2010v1.2.pdf
[OpenURL] http://www.niso.org/apps/group_public/download.php/6640/The%20OpenURL%20Framework%20for%20Context-Sensitive%20Services.pdf 

***Lesen. Hören. Wissen. 100 Jahre Deutsche Nationalbibliothek***
***Reading. Listening. Understanding. A century of the German National Library***

-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek / Informationstechnik
http://www.dnb.de/
[email-masked]
http://www.dnb.de/100jahre

---

From: Juha Hakala <[email-masked]>
Date: Tue, 17 Jul 2012 11:12:16 +0300

Hello Lars,

> Much of the current discussion -- particularly the use of fragments -- revolves around the consequences for urn:isbn (RFC 3187bis). In my opinion, that discussion prevents us from making progress i…

Your message is related to a much broader issue of what kind of usage of 
(traditional) identifiers is acceptable, generally and more specifically 
from the URN point of view. Because identifier assignment is usually a 
manual process, human errors are possible, and perhaps inevitable. ISBN 
is no exception in this respect, and taking a closer look at the 
problems within this namespace is useful. But these problems do not 
undermine the value of the ISBN system as a whole. The biggest challenge 
to the URN system are the namespaces where there is no control over 
identifier assignment at all.

The ISBN community has detailed identifier assignment rules expressed in 
the ISBN manual, and national ISBN centers are responsible of 
communicating these rules to the publishers. In most countries these 
rules are well respected, but there are also countries where there has 
been pressures to cut corners, for instance as regards the requirement 
to give different ISBNs to different formats.

In spite of its problems, ISBN is one of the best managed bibliographic 
identifier systems in use. When ISBNs are assigned according to the ISBN 
manual, there should be no serious conflicts with the URN principles, 
although in some areas the ISBN community should perhaps investigate 
more closely from the URN point of view the practical implications of 
the existing policies.

Please see some comments below.
> My take is that urn:isbn does not adhere to any of those criteria, at least not globally.

IMHO, it does - if the system is used correctly. This interpretation is 
of course dependent on how we understand "different": is an unaltered 
reprint of a book a different resource than the original or not?

I would prefer not to elaborate in rfc2141bis the meaning of "different" 
in axiom 1, since too strict an interpretation might mean that some 
traditional identifiers would not be suitable URNs. And this would be 
harmful both to the URN system and these identifiers.

> 1)	Uniqueness: An analysis of ISBNs in the catalogue of the Deutsche Nationalbibliothek (German National Library, DNB) revealed more than 200,000 ISBNs where more than one bibliographic record shar…

For the sake of comparison, how many ISBNs have been correctly assigned? 
And of these 200.000, how many are OK according to the ISBN manual?

> 1)	The publisher has re-used an ISBN for two entirely different publications. Example: urn:isbn:3-332-00079-9 would identify [1] and [2]. This violates 5.1 of the ISBN Manual [ISBN Manual]

This is a human error and these cases should be rare. The national 
library or other organisation maintaining the national bibliography will 
spot these errors, and may have a policy for fixing them.

> 2)	The publisher has re-used an ISBN for the same publication in two different formats (e. g. print and electronic). Example: urn:isbn:3-8272-6986-5 would identify [3] and [4]. This violates 5.4 of…

In the worst case (if the principles of the ISBN Manual are not 
followed) these cases may become increasingly common. The library 
community and book stores must try to convince the publishers that this 
practice may have dire consequences.

> 3)	The publisher has used the same ISBN for two editions of a publication, where there has been no change of content (unchanged reprints). Example: urn:isbn:3-10-048198-4 would identify [5] and [6]…

 From the URN resolution point of view, this should not be a serious 
problem. There is no need to reprint a digital book. And if there are 
reprints of a printed book, there may be just one bibliographic record 
describing all of these versions.

> 4)	The publisher has used the same ISBN for two editions of a publication where there has been a (significant) change in the content (augmented or revised reprints). Example: urn:isbn:3-921885-30-2…

The publishers should not do this, so these cases ought to be relatively 
rare. The national library or other organisation maintaining the 
national bibliography should be able to spot these errors.

> 5)	The publisher has assigned an ISBN to a media bundle (e. g. a book with an accompanying CD or a collection of books sold as a bundle, such as the complete Works of William Shakespeare). Examples…

Individual parts of the bundle often receive their own ISBNs. An example 
of this is (book) series and its individual parts (e.g. The Lord of the 
rings and its three parts). There should be no problems in resolving 
these URN:ISBNs in an appropriate manner. If the parts do not have their 
own ISBNs, other identifiers can be assigned.
> A more thorough evaluation will provide data on the relative frequencies of those four cases and possibly identify further ones. And yes, the data indicates that some publishers are more notorious…

I look forward to this additional information.

Does the Deutsche Nationalbibliothek have plans to contact those 
publishers who are the worst offenders?

I don't know if we could provide a comparable analysis of the situation 
in Finland. And I doubt it would be of interest on the urn list.

> 1)	We should stop using urn:isbns as globally unique identifiers, because they aren’t. The only statement we can make is that urn:isbn:xxxx identifies whatever the owner of xxxx says it identifies,…

There will be no URN namespaces where IETF or any other organization can 
fully control the uniqueness and persistence of an identifier.

If a traditional identifier can only get a URN namespace if the 
identifier cannot be misused, by mistake or by purpose, then URN system 
could never become popular.

> 2)	I propose that we deprecate RFC 3187 and cease work on 3187bis, at least until the questions of uniqueness and process management have been clarified. The process question requires close co-oper…

IETF must not deprecate URN namespaces which are already in use. Any 
changes that would undermine existing URN services are out of scope of 
the URNbis.

Any fundamental issues with a namespace concerning the uniqueness and 
persistence of the identifiers should be discussed in the namespace 
registration request. IMHO, human errors in identifier assignment are 
not such issues. In the namespace registration I would not go beyond 
telling if the community has rules of identifier assignment, and perhaps 
providing an overview of these principles. Obviously these rules should 
not be in conflict with the URN principles. In the case of ISBN, I see 
no such conflicts, although there are cases in which we should 
investigate the practical consequences of existing (acceptable) practices.

The URN community may be able to support the ISBN international and the 
national ISBN centers in their work at enforcing the guidelines of the 
ISBN manual, by showing that if the same ISBN is given to different 
formats and / or editions of a book, URN resolution process can be 
compromised.

> 3)	When discussing the use of fragment identifiers in RFC 2141bis, we should ignore potential use cases stemming from the use of urn:isbn.

This is fine with me.

Best regards,

Juha

-- 

  Juha Hakala

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Jul 2012 16:29:57 -0600

> it, we have only a limited number of mainly technical people following

Hi Juha, what I have observed is that the scope of our work in the
URNBIS WG is actually quite small, and the topics are of interest to
people who care about URIs, but not to librarians, publishers, and the
like. Those folks are users of some URN namespaces, but they don't
particularly care about URNs in general (nor should they, I think).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/