Re: Browser-Plugin zur direkten URN (NBN)-Aufloesung

[Sascha Carlin <sc _at__ itst.org>]

Stefan Farrenkopf wrote:

> Ich denke Sie haben falsche Erwartungen an URNs bzw. persistent 
> identifier. Ich versuche mich mal an einer Klarstellung:
> Persistent Identifier zielen nicht darauf ab URLs überflüssig zu machen. 
> Der Ort an dem ein Objekt liegt wird sich immer wieder ändern. Heute ist 
> es leider so, dass diese Ortsänderung, die häufig gleichbedeutend mit 
> einer Änderung der URL ist alle bis dahin existierenden Refernzen auf 
> das Objekt ungültig macht. Und genau an dieser Stelle werden wir in 
> Zukunt von Persitent Identifier Systemen profitieren. Sie zitieren eine 
> URN, wo das Objekt liegt ist egal. Solange jemand die URN-URL 
> Beziehnungen zuverlässig verwaltet, solange werden Sie ihr Dokument 
> immer mit der gleichen URN erreichen. Die URL hat sich inzwischen 
> vielleicht zehn mal geändert, das interessiert sie dann aber nicht mehr ;)

Danke für Ihre Erläuterungen, Herr Farrenkopf. Mir ist dies durchaus 
bewusst. Die Vorteile sind klar, doch beseitigen URN das _grundlegende_ 
Problem nicht, sie verlagern es nur auf eine höhere Ebene.

Ein Beispiel anhand des Domain-Name-Server-Systems, also der Auflösung 
von unhandlichen IP-Adressen (192.67.198.50) in menschenfreundlichere 
Domainnamen (wie inetbib.de). Ich setze hier IP-Adressen mit URL und 
Domainnamen mit URN gleich: zugrunde liegt die IP-Adresse. Der 
Domainname kapselt die IP-Adresse nach außen und stellt einen Verweis 
auf sie dar. (Weiter Term: Website = Resource).

Um dies zu bewerkstelligen, und vor allem um dafür zu sorgen, das 
weltweit der Domainname www.inetbib.de gleich verstanden wird, gibt es 
Root-Server genannte Einrichtungen, die alle (fast alle) Domainnamen 
kennen und einer IP-Adresse zuordnen können. Diese Root-Server agieren 
global. Daneben, bzw. in der Hierarchie darunter, existieren weitere, 
1000e weitere Nameserver. So betreibt praktisch jeder Webhoster oder 
Internetprovider seine eigenen Nameserver.

Im Regelfall funktioniert das alles auch. Ob jemand in San Fransisco 
oder eine Bibliothekarin aus Ghana 'www.inetbib.de' in ihren Browser 
tippt, beide landen auf der gleichen Website.

Doch was passiert, wenn eine Website (bleiben wir beim Beispiel 
inetbib.de) auf einen anderen Webserver (zu einem anderen Hoster) 
umzieht und damit unter einer neuen IP zu erreichen ist? Stufenartig 
wird diese Änderung an alle (fast alle) DNS-Server weitergegeben, vom 
kleinen lokalen bis zum riesigen globalen Root-Server. Geht auf diesem 
Weg etwas schief, haben wir ein Problem: die eine Hälfte der Welt kann 
inetbib.de ungestört erreichen und bemerkt von dem Serverwechsel, also 
dem IP-Wechsel, nichts. Die andere Hälfte wundert sich jedoch, warum sie 
inetbib.de nicht mehr erreichen kann.

Das _grundlegende_ Problem, der Wechsel der IP-Adresse, ist ein Fakt, 
den man - zumindest mit den momentan verfügbaren Technologien - nicht 
ignorieren kann. Dieser Wechsel findet statt. Die Nameserver ihrerseits 
müssen nun dafür sorgen, das dieser Wechsel weltweit propagiert wird um 
die Erreichbarkeit der Website sicherzustellen.

Prinzipiell handelt es sich bei dem System der PI um das gleiche Schema: 
wir kapseln eine variable Eigenschaft, die Adresse einer Resource, mit 
einer pseudo-dauerhaften Adresse. Ändert sich die grundlegende Adresse, 
müssen wir dies abbilden und die URN 'updaten'.

Puh. Lange Rede kurzer Sinn: *PI sind nur so gut wie das 
'Änderungssystem' dahinter - und lösen das eigentliche Problem nicht.*

Gruß, Sascha Carlin

PS: Mir ist klar, das ich das DNS-System hier vereinfacht dargestellt 
habe und das es weitaus mehr kann bzw. zu weitaus mehr zu gebrauchen ist.

--
Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt
http://www.itst.org/