Was liefert ein URN Resolver ?
Wie gelange ich an das Dokument, das durch ein URN identifiziert ist?

EDIT 2013-04-03: Nur einen Tag, nachdem ich den Post hier geschrieben habe, ist der DNB Dienst umgestellt worden. http://nbn-resolving.org/urn:nbn:de:gbv:3:1-2762 liefert nun standardmäßig das Dokument, zumindest über den Browser (über wget oder curl wird momentan HTTP status code 503 "Service Temporarily Unavailable" geliefert). Allerdings ist das Verhalten bei einer anderen URN anders - http://nbn-resolving.org/urn:nbn:de:gbv:3:1-60274 bringt die Verweisseite. Da ist wohl grad Baustelle. Mal sehen, wie lange ;) .Die URL des Resolvers http://nbn-resolving.org/ bringt nun eine Liste, wo der Benutzer aussuchen kann, ob er die Verweisseite haben will oder das Dokument.

Es gibt die Ansicht, dass z. B. http://nbn-resolving.org/urn:nbn:de:gbv:3:1-2762 den URN richtig auflöst, da erfolgreich eine Liste aller in der DNB registrierten URLs zurückgeliefert werden. HTTP Code 200 sei daher vollkommen richtig.
Es gibt die andere Ansicht, dass http://nbn-resolving.de/urn:nbn:de:gbv:3:1-2762 richtig ist, weil es direkt die Ressource liefert mitsamt korrekten HTTP Codes (302->303->200).
So, wie es http://nbn-resolving.org/ macht, finde ich es schlecht.
So, wie es http://nbn-resolving.de/ macht, finde ich es richtig.

Diese Ansicht ist durch folgendes begründet: Laut RFC 2169 (->"URN to URL") sollte nicht HTTP Code 200 geliefert werden, sondern erstmal ein HTTP Code 30x auf die Ressource. In der Wikipedia steht:
A URN resolver is responsible for initiating and sequencing the queries that ultimately lead to a full resolution (translation) of a URN name or a "resolution request", e.g., a request for translation of a URN name into a URL.
Genau diese Aufgabe,
"liefern eines URL für einen URN"
kann automatisiert umgesetzt werden, eben mittels HTTP Headern. Es könnte auch anders gehandhabt werden, mittels einer API. http://nbn-resolving.org/ leistet dies nicht, http://nbn-resolving.de/ hingegen schon.

Auch "Architectural Principles of Uniform Resource Name Resolution" unterstützt meine Ansicht:
This document addresses the issues of the discovery of URN (Uniform Resource Name) resolver services that in turn will directly translate URNs into URLs (Uniform Resource Locators) and URCs (Uniform Resource Characteristics).
Es geht also um die "direkte Übersetzung eines URN in einen URL". "Direkt" verstehe ich als "automatisiert" - und nicht, möglicherweise eine Liste aller Links zu anderen URLs zu liefern, die der Benutzer intellektuell auswerten muss um den passenden Hyperlink zu finden und diesem dann zu folgen.

Weiter heißt es:
The term "resolver" is used in this document to indicate a service that translates URNs to URLs (Uniform Resource Locators) or URCs (Uniform Resource Characteristics). Some resolvers may provide direct access to resources as well.
Die Frage ist: ist es aureichend, wenn dieser URL lediglich manuell erreichbar ist, oder sollte ein URN Resolver sich nicht selber darum kümmern und den URL des Dokumentes liefern?

Es gibt mindestens drei verschiedene Möglichkeiten, was mich erwartet, wenn ich einen URN in ein Resolvingsystem eingebe:
Ressource: Ich bekomme die Ressource, die durch den URN definiert ist
Metadaten: Ich bekomme Metadaten, die die Ressource beschreiben (also meist eine HTML-Seite)
Verweis: Ich bekomme eine HTML-Liste mit Verweisen auf (mehrere) URLs

Da diese 3 verschiedenen Antworten jeweils den gleichen HTTP-Header liefern (Status Code 200), kann maschinell nicht erkannt werden, um welche der Möglichkeiten es sich bei dem URL, den der URN-Resolver zurückgibt, handelt. Das macht einen URN-Resolver für maschinelle Arbeiten, z.B. um Mashups in Portale einblenden zu lassen, untauglich. Er taugt lediglich zum einfachen "Backlink" - eine alte, auch im Vascoda-Portal umgesetzte und gescheiterte Idee, da die Benutzerunfreundlichkeit stark leidet durch die ständigen Portalbrüche (Verlassen des ursprünglichen Rechercheportals, um (hier z.B.) in einem URN-Resolver weiterzuklicken) und den damit u.a. verbundenen (vermeidbaren!) Zeitaufwand (Benutzer sind schon lange besseres gewöhnt, z.B. durch die Internetsuchmaschinen).

Punkt 3) zeigt zudem, dass der oft zu lesende Vergleich von URN-Resolver und DNS basierte Namensauflösung unstimmig ist, denn ein DNS löst den Namen maschinell auf und führt maschinell zum richtigen Ziel. Ein URN-Resolver dagegen kann offenbar dagegen auch lediglich manuell interpretierbare Verweise (Liste in Html) zurückliefern, und es gibt keine Möglichkeit für eine Maschine, den Unterschied zu erkennen. Somit ist die maschinelle Verarbeitung von URNs unmöglich.

Ambivalenz - maschinelle Nicht-Entscheidbarkeit zum Zustand einer URN-Resolver-URL

Beispiel: Jenachdem, welchen Resolver ich anspreche, erhalte ich Unterschiedliches - bei gleicher URN:
http://nbn-resolving.org/urn:nbn:de:gbv:3:1-60274 liefert die Verweisseite,
http://nbn-resolving.de/urn:nbn:de:gbv:3:1-60274 liefert die Ressource
- und das, ohne maschinelle Möglichkeit der Diskriminierung dieser doch gänzlich andersartigen Inhalte der URLs.

URN-Resolver vs. Linked Data Ich setze das Linked-Data-Paradigma gegen den URN-Resolver, damit klarer wird, was technisch möglich ist:
Ich bekomme die Ressource. HTTP Status Code 200.
Metadata: z.B. qua Redirect (HTTP-Status-Code 303) (es gibt andere Mechanismen). Daten maschinell interpretierbar.
Liste: qua Redirect (HTTP-Status-Code 303) geht es zu den Metadaten, in denen dann maschinenlesbar eine Liste mit synonymen Identifieren hinterlegt ist ("owl:sameAs")

Mein Fazit:
Da URN Resolver aus Maschinensicht inadequat sind, sollten sie durch Linked Data cool URIs ersetzt werden.

[EDIT 2015/10/01 at 08:15]

Vergiss URN. ARK (siehe https://tools.ietf.org/html/draft-kunze-ark-18 ) ist viel besser, die haben das Resolving richtig gemacht. So sieht eine ARK aus:
http://ark.cdlib.org/ark:/13030/ft4w10060w
ark.cdlib.org := Name Mapping Authority Hostport (NMAH)
ark: := ARK Label
13030 := Name Assigning Authority Number (NAAN)
ft4w10060w := Name (assigned by the NAA)
Mein Kritikpunkt an ARK ist allerdings:

Das NAAN bringt eine Komplexitätsstufe hinein, die gar nicht nötig ist. Einfach NAAN und NAA durch eine UUID ersetzen, und es können ARKs von jedem erzeugt werden. Es braucht keine Vergabestelle (deren Arbeitsaufwand oft unterschätzt wird und z.B. bei ISBN dazu führt dass die Geld kosten ).