[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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/


Listeninformationen unter http://www.inetbib.de.