Re: [InetBib] Dauerhafte Verfuegbarkeit von URNs der DNB

["Kay Heiligenhaus" <kay.heiligenhaus@xxxxxxxxxxxx>]

Lieber Herr Pohl,

Ihre Fragen gehen m.E. genau in die richtige Richtung, auch wenn ich Details 
anders sehe, als Sie hier vorschlagen. Kurz zu Ihrem Punkten:

> ich frage mich, warum das Problem des URN-Resolvings nicht mittels
> verteilter Resolver gelöst wird/wurde. (Ich nehme an, dass dies nicht
> die erste URN-Resolving-Debatte ist und habe keine Ahnung, inwiefern
> das früher schon diskutiert wurde. Jedenfalls scheint ein Ansatz, bei
> dem die volle Verantwortung auf den Schultern der DNB liegt, ja
> offensichtlich nicht die optimale Lösung zu sein.)

Die Frage ist hier letztlich, wie man diese verteilte Infrastruktur dann für 
die Auflösung adressiert. Es ist schwer vorstellbar, daß nutzende Einrichtungen 
(z.B. die Verbundsysteme) beim Auflösen checken, welche der verteilten Resolver 
denn gerade verfügbar sind und wie einer davon gerade zu adressieren ist. 
Ebenso sehen die aktuellen Implementierungen nach meinem Kenntnisstand nicht 
vor, daß die Daten zwischen den bestehenden Resolvern ausgetauscht werden. 
Deshalb kommt ein Nutzer auch nicht weiter, wenn er den schwedischen Resolver 
nach URNs fragt, die im deutschen Namensraum registriert sind. Der schwedische 
Resolver leitet einfach zum deutschen weiter. Das war's.

Aus meiner Sicht heißt das Stichwort hier ganz einfach: Cloud Computing. Damit 
erreicht man die Hochverfügbarkeit und Skalierbarkeit, die ein solches - aus 
meiner Sicht notwendigerweise _zentrales_ - System benötigt. Was an diesem 
Konzept so alles hängt, macht dann deutlich, warum ich eine große Aversion 
gegen die "Zwei-Server-These" habe. ;)

> Wieso stellt die DNB nicht die jeweils aktuelle Version der
> URN-URL-Zuordnungsliste (eine solche dürfte ja den Kern des
> Resolvingdienstes ausmachen) öffentlich zur Verfügung, so dass sie von
> anderen Diensten geharvested werden kann? Dann wäre es ein Leichtes,
> zusätzliche dezentrale Resolving-Dienste aufzubauen, wodurch die
> Ausfallzeiten minimiert werden könnten. Wurde so etwas schon in der
> Anfangszeit des DNB-URN-Resolvings diskutiert? Und womöglich
> verworfen? Wenn ja, warum?

Dadurch wird das Problem nicht wirklich entschärft, sondern eher 
verkompliziert. Vor allem ist das oben beschriebene Problem nicht gelöst: an 
welchen Resolver wende ich mich, wenn der primäre nicht erreichbar ist? Soll 
diese "Lastverteilung" an hunderten Standorten implementiert werden, die URNs 
nutzen?

> Eine andere Frage: Wieso verfolgt man beim URN-Resolving nicht einen
> ähnlichen hierarchischen, verteilten Ansatz wie beim DNS-Modell? Hat
> da das W3C am Anfang die Weichen falsch gestellt oder was ist da los?
> Es kann doch nicht sein, dass die Benutzer selbst wissen müssen,
> welcher Resolving-Dienst für eine bestimmte URN angesprochen werden
> muss, weil es keine zentralen Resolver für URNs verschiedener
> Namensräume gibt...

Das ist Kernproblem I des URN-Resolvings aus meiner Sicht. Und nach dem, was 
man über das Thema so lesen kann, wird daran bereits intensiver gearbeitet in 
Kooperation der Nationalbibliotheken. Ein nicht ganz so einfaches Unterfangen...

> Meiner Meinung nach sollte es das Ziel sein, dass die Endnutzer eine
> URN (ist ja auch eine URI) in die Adressleiste ihres Browsers eingeben
> und so zum entsprechenden Dokument gelangen. Die freie Verfügbarkeit
> von Resolvinglisten dürfte wohl ein großer Schritt in Richtung dieses
> Ziels sein.

Nein, Lösung von Kernproblem I dürfte Kernproblem II (Eingabe in der 
Browserzeile) zu einer Lösung führen. Ansonsten verlagern Sie die oben 
diskutierten Fragen zu den Browserherstellern. Das halte ich für nicht 
umsetzbar.

> Falls aufgrund seines technischen Halbwissens und wegen Unkenntnis der
> URN-Historie total daneben liegt, freut sich auf Aufklärung:
> Adrian Pohl

Wenn diese erfreuliche Form "technischen Halbwissen" bei etwas mehr Leuten 
vorhanden wäre, würde wir hier manche "Diskussionen" gar nicht erst führen 
müssen. Besten Dank also für Ihren Beitrag!

Beste Grüße,
Kay Heiligenhaus

-- 
http://www.inetbib.de