[urn] URNs and URI <fragment> --> better URN <query> discussion?

["Kocer, Kadir Karaca" <[e-mail]>]

Dear list members,

the Fragment Identifiers discussion is very interesting indeed.

German National Library, one of the largest members of user communities of both urn:isbn, urn:nbn, ... supports all efforts towards <fragments>.
May be the experience with about 20 million objects, 6 million URNs and an active project implementing a new generation of URN-System can bring some practical facts in this mostly theoretical discussion.

First of all personally I find extending the "Fragment Identifiers in NBN" discussion on ISBN namespace contra productive.
This *personal opinion* of mine has to do with existing bad ISBN practice in Germany. Therefore other countries with "ideal" ISBN-Administrations may have other opinions.

In Germany each ISBN costs money. Unfortunately to save this (small amount of) money it is a common practice that some publishers "recycle" existing ISBNs of sold-out publications and assign them a second/third time to a new publication.

A simple example: if we resolve the following ISBN
https://www.abebooks.co.uk/servlet/SearchResults?isbn=9783430185691
we see that more than one completely different publications (different topics, different authors, ... even different publishing orts) are filed under this "Uniform Resource Name".

A non-unique identifier is for most of use-cases completely useless, so I think we do not need a further discussion about if ISBN is a "persistent" identifier (for me in a long term preservation point of view NOT, because uniqueness *not* guaranteed) or if fragments can be defined for this identifier type.

I know it sounds hard and I have a certain, subjective point of view, but as project manager of the new URN system implementation I have to keep project milestones and deadlines in mind. That means if the scope of this discussion extends with the consequence of a delayed RFC, our new system must be implemented as a non-RFC-Conform system.
Such a development is really annoying for us and I'm sure no one in this list will find it positive.

The second fact that must be taken into account is, the fact that Julian Reschke already explained:

> The syntax is then defined by HTTP (RFC 2616)
> and URI (RFC 3986); so the identified resource is
>
> http://resolver.example.com/urn:nbn:aq:987-65432-1
>
> any you apply the fragid "chapter98" to whatever is
> retrieved from that resource

At the moment there is no built-in direct support for URNs in Internet Explorer/Firefox/..., so that *every* URN needs some kind of resolving mechanism.
Most widely implemented solution is a HTTP-Based-Resolver.

Unfortunately my Test-Implementation shows that neither Internet Explorer nor Firefox sends # Fragments to the HTTP server/servlet container. That means if we consider the Julian's example:
http://resolver.example.com/urn:nbn:aq:987-65432-1#chapter98
the resolver do *not* receive the information that the user requests only chapter98 and not any other chapter so it can not react in appropriate way.

This simple fact has huge effect on URN-Fragments discussion: even the perfect URN fragment solution we agree here will not have any practical effect in daily life, till a future Internet Explorer (version 14/15?) supports URNs natively and all older obsolete IE versions are updated.

As a consequence of those two points I tried to explain above, I suggest to start a new discussion:
queries in URN(:NBN).
Instead of
http://resolver.example.com/urn:nbn:aq:987-65432-1#chapter98
standardizing
http://resolver.example.com/urn:nbn:aq:987-65432-1?chapter=98
so the resolver can get the information, that only a small part of the resource and not the whole is required.

This solution seems to be the only solution that can in real existing desktop systems function and easily be implemented*.

What is your opinion?
Karaca Koçer


(*) besides a REST based approach like
http://resolver.example.com/urn:nbn:aq:987-65432-1/chapter/98

--
Kadir Karaca Koçer
Deutsche Nationalbibliothek
Informationstechnik
Adickesallee 1
60322 Frankfurt am Main
Telefon: [phone]
Telefax: [phone] 
http://www.dnb.de/