Organisation und Verwaltung der Verweise im WWW

Klaus Tochtermann
Lehrstuhl Informatik 1
Universität Dortmund
44221 Dortmund
e-mail: tochterm@ls1.informatik.uni-dortmund.de

Zusammenfassung: In diesem Beitrag wird vorgestellt, wiederzeit Verweise in HTML-Dokumenten definiert werden und welcheProbleme bzgl. der Konsistenzhaltung von Informationsstrukturendadurch entstehen. Es werden drei unterschiedliche Ansätzezur Gewährleistung von konsistenten Verweisen skizziert:Zunächst werden verschiedene Werkzeuge vorgestellt und bewertet,die Inkonsistenzen bei Verweisen zwar entdecken, aber nicht behebenkönnen. Anschließend werden neue Ansätze zur Adressierungvon Dokumenten im World-Wide-Web skizziert. Von diesen Ansätzenverspricht man sich, Inkonsistenzen bei Verweisen möglichstweitgehend zu vermeiden. Zum Abschluß wird Hyper-G im Hinblickauf die Verwaltung von Verweisen diskutiert. Mit Hyper-G liegtein lauffähiges und damit einsetzbares Internet-Informationssystemvor, das viele der häufig anzutreffenden Ursachen fürinkonsistente Verweise behoben hat.


Inhaltsverzeichnis

Vorbemerkung

1. Einleitung

2. Verweise im WWW

3. Werzeuge zur Konsistenzprüfung von Verweisen
3.1 Benutzer und Log-Dateien
3.2 Spider

3.2.1 Statische Spider
3.2.2 Dynamische Spider
3.2.3 Weitere Spider
3.2.4 Bewertung

4. Ansätze über LRN und URN
4.1 Local Resource Name
4.2 Uniform Resource Name

4.2.1 Syntax einer URN
4.2.2 Protokoll zur Auflösung
4.2.3 Strategie zur Auflösung und Auflösungsergebnisse
4.3 Bewertungvon LRN und URN

5. Verweisverwaltung in Hyper-G
5.1 Einführung in Hyper-G
5.2 Verweiskonsistenz in Hyper-G

5.2.1 Verweiskonsistenz beim Löschen von Dokumenten
5.2.2 Verweiskonsistenz beim Verschieben und Umbenennen von Dokumenten
5.3 Bewertung

6. Zusammenfassung

7. Literatur


Vorbemerkung

Ein Großteil der verwendeten Literatur stammt aus dem World-Wide-Web,so daß es möglich ist, in der elektronischen Versiondieser Ausarbeitung Verweisen zu den angegebenen Literaturstellenzu folgen. Für alle Verweise wurde am 15.2.1996 geprüft,ob das jeweilige Zieldokument existiert. Zu diesem Zeitpunkt warenalle Verweise definiert. Da das Dokument vom Autor nicht weiteraktualisiert wird, kann es vorkommen, daß zu einem späterenZeitpunkt einige Zieldokumente nicht mehr existieren, die entsprechendenVerweise also undefiniert sind.

1. Einleitung

Das Internet ist ein weltweiter Verbund von Rechnernetzen undhat seinen Ursprung im ARPANET (Advanced Research Projects AgencyNetwork), das im Dezember 1969 in Betrieb genommen wurde. Diekonzeptionellen Grundlagen hierfür waren bereits 1964 veröffentlichtworden. Die Idee war es, in einem dezentral aufgebauten Netz Nachrichtenzwischen gleichberechtigten und unabhängigen Knotenrechnernauszutauschen. Die Nachrichten sollten in kleine "Pakete"zerlegt und mit Sender- und Empfängeradresse versehen verschicktwerden. Die praktische Umsetzung im ARPANET sah so aus, daßvier verschiedene Rechner (Hosts) über Telefonleitungen miteiner Übertragungsrate von 50 Kbit/s verbunden waren. DenHosts wurden aufgrund der Heterogenität weitere kleinereRechner, sogenannte Interface Message Processors, vorgeschaltet.Diese bildeten das eigentliche Netzwerk. Zu den ersten Anwendungengehörte die Steuerung eines Rechners aus der Ferne (remotecontrol) und der Transfer von Dateien zwischen entfernten Rechnern.Diese beiden Dienste existieren heute noch in Form von Telnetund FTP. 1972 bestand das ARPANET aus 37 Hosts. 1973 begann mandamit, auch nicht-terrestrische Möglichkeiten zur Übertragungzu nutzen, und es entstanden das SANET (Satellites Network, fürSatellitenübertragung) und das PRNET (Packet Radio Network,für Funkübertragung). Hinzu kam in den 70-er Jahrendas Ethernet für lokale Netzwerke. 1977 wurden die Verbindungzwischen ARPANET, SANET, PRNET und Ethernet geschaffen. Als Kommunikationsstandardzwischen den verschiedenen Netzen etablierte sich TCP/IP (TransmissionControl Protocol/Internet Protocol). Der militärische Anteildes ARPANET wurde Anfang der 80-er Jahre in das MILNET (MilitaryNetwork) ausgelagert, und es entstand das DARPA Internet, späternur noch Internet. Das ARPANET wurde 1989 vom US-Verteidigungsministeriumformal aufgelöst, nachdem zuvor (1986) das NSFNET (NationalScience Foundation Network) gegründet worden war. Ziel diesesNetzes war es, 6 NSF Supercomputer als Backbone (Rückgrat)für die Kommunikation im Internet miteinander zu verbinden.Im März 1986 hatte das Internet ca. 3000 Hosts, und die Zahlder angeschlossenen Rechner stieg und steigt ständig.

Im März 1989 begann am CERN die Entwicklung des World-Wide-Web(WWW). Die hier zugrundeliegende Idee war es, auf der Basis desInternet, Dokumente auf verschiedenen Rechnern über Hypertextverweisemiteinander in Beziehung zusetzen. Die Dokumente sollten durcheinen WWW-Server verwaltet und über WWW-Klienten zugänglichgemacht werden. 1993 erschien mit Mosaic der erste WWW-Klientfür X-Windows, nachdem 1992 das erste WWW-Client-Server-Paketinklusive Quellcode im Internet verfügbar gemacht wordenwar. Für die Adressierung von Dokumenten im WWW führteman das Konzept der URL (Uniform Resource Locator) und fürdas hypertextuelle Aufbereiten der Dokumente die Hypertext MarkupLanguage (HTML) ein. Mittlerweile gibt es im Internet ca. 9 Mio.Hosts, wobei ca. jeder 100. einen WWW-Server betreibt. Diese großeAnzahl an WWW-Servern läßt darauf schließen,das unzählige Dokumente mit unzähligen Verweisen imWWW verfügbar sind.

Ein großes Problem, das beim Aufbau und bei der Wartungvon Informationsstrukturen immer wieder entsteht, ist die Wahrungder Verweiskonsistenz. Wird beispielsweise ein Dokument gelöscht,so ist sicherzustellen, daß keine Verweise mehr auf diesesDokument zeigen. Ist dies dennoch der Fall, so spricht man vonhängenden Verweisen, also Verweisen deren Ziel nicht mehrdefiniert ist. Hängende Verweise führen im WWW zu derbekannten Fehlermeldung Error 404: Not found - file doesn'texist or is read protected [even tried multi]. DieserBeitrag stellt nun vor, welche weiteren typischen Schwierigkeitenim Zusammenhang der Verwaltung und Organisation von Verweisenim WWW auftreten können und welche Möglichkeiten esgibt, diese Schwierigkeiten in den Griff zu bekommen.

Der Beitrag ist wie folgt aufgebaut: Kapitel 2 beschreibt denAufbau einer URL, die Adressierung von Dokumenten mittels HTMLsowie deren Auswirkung auf die Verwaltung der Verweise im WWW.In Kapitel 3 werden verschiedene Werkzeuge vorgestellt, mit derenHilfe man gewissen Formen der Verweiskonsistenz im WWW prüfenkann. Neue, in der Diskussion befindliche Ansätze zur Verweisbehandlung,wie LRNund URN, werdenin Kapitel 4 diskutiert. Kapitel 5 zeigt schließlich, wiein Hyper-G, einem Internet-Informationssystem der 2. Generation,Verweise verwaltet werden. Der Beitrag schließt in Kapitel6 mit einer Zusammenfassung.


2. Verweise im WWW

Um Verweise zwischen Dokumenten im WWW definieren zu können,wird jedes Dokument über eine URL (Uniform Resource Locator)eindeutig identifiziert. Eine URL hat folgenden Aufbau: <Dienst>://<Host>/<Pfad>/<Datei>,eine konkrete URL, etwa die des Lehrstuhls Informatik 1 der UniversitätDortmund, ist:http://ls1-www.informatik.uni-dortmund.de/Welcome.html(wobei keine Pfadangabe nötig ist). Über den <Dienst>wird die Zugriffsmethode festgelegt. Dies ist im WWW das HypertextTransfer Protocol (http). Über den <Host>wird ein Internet-Rechner angesprochen, auf dem der WWW-Serverinstalliert ist. <Pfad>/<Datei> beschreibenschließlich, unter welchem Pfad die angegebene Datei dortzu finden ist.
Um plattformunabhängige Hypertext-Dokumente im WWW erzeugenzu können, verwendet man die Hypertext Markup Language (HTML).HTML soll hier nicht umfassend sondern nur bezüglich derVerweisdefinition vorgestellt werden. HTML bietet insbesonderedie Möglichkeit, um aus einem Text heraus einen Verweis zueinem anderen Dokument definieren zu können. Soll etwa innerhalbeines Dokumentes das Wort "Text" als Ausgangspunkt einesVerweises definiert werden, der zu einem Dokument A.htmlim Ordner ordner auf dem Rechner www.bsp.de führt,so hat eine solche Definition folgendes Aussehen:

<A HREF="http://www.bsp.de/ordner/A.html> Text</A>.

Aufgrund dieser Art, Verweise zu definieren, entstehen folgendeProbleme:
Wird ein Dokument gelöscht, so werden alle Verweise,die zu dem gelöschten Dokument führen, undefiniert,und es kommt auf Klientenseite zu obiger Fehlermeldung, wenn versuchtwird, einem solchen Verweis zu folgen.
Betreiber eines WWW-Servers stehen nun vor dem Problem, zu gewährleisten,daß die von ihren Dokumenten ausgehenden Verweise stetsvollständig definiert sind. Insbesondere sind Bibliothekenvon diesem Problem betroffen, wenn diese Internet-Ressourcen katalogisierenund Benutzern die Kataloge in Form von HTML-Dokumenten anbietenmöchten. Hier sollten Bibliotheken gewährleisten, daßihre Kataloge mit Internet-Ressourcen stets aktuell und konsistentbzgl. der über Verweise erreichbaren Zieldokumente sind.Welche Möglichkeiten zur Konsistenzprüfung es derzeitgibt, wird im folgenden Kapitel beschrieben.

3. Werkzeuge zur Konsistenzprüfungvon Verweisen

Dieses Kapitel stellt Werkzeuge vor, die weitgehend automatischüberprüfen, ob die Verweise eines HTML-Dokumentes eindefiniertes Ziel haben. Diese Werkzeuge gehören zu den sogenanntenSpidern (alternative Bezeichnungen sind Wanderer oder Robot).Allgemein sind dies Programme, die selbständig das WWW durchwandernund dort Informationen nach gewissen Kriterien zusammenstellen.Im World-Wide-Web ist eine Übersicht aller bekannten Spidervorhanden.

3.1 Benutzer und Log-Dateien

Natürlich ist es zur Überprüfung der Verweiskonsistenzmöglich, von Hand zu prüfen, ob alle Dokumente, dieman über einen Verweis erreichen möchte, auch tatsächlichnoch existieren. Dies ist jedoch zeitaufwendig und gerade beiumfangreichen Dokumentbeständen, wie etwa Katalogen, nichtmöglich.
Weiterhin gibt es die Möglichkeit, die Log-Dateien des eigenenServers auszuwerten. Damit ist es jedoch nicht möglich, zuprüfen, ob die Verweise, die von eigenen Dokumenten ausgehenkonsistent sind. Aber immerhin erhält man Aufschlußdarüber, ob von außen auf evtl. umbenannte oder inzwischengelöschte Dokumente des eigenen WWW-Servers zugegriffen wird.

3.2 Spider

Bei den Spidern, die speziell für die Überprüfungder Verweiskonsistenz entwickelt wurden, kann man zwischen statischenund dynamischen Spidern unterscheiden. Statische Spider sind solche,die für jeden Durchlauf durch zuvor angegebene Dokumenteoder Server vom Benutzer angestoßen werden müssen.Demgegenüber wiederholen dynamischen Spider solche Durchläufeimmer wieder in vorgegebenen Zeitabständen.

3.2.1 Statische Spider
Auch wenn mehr statische Spider existieren, sollen hier mit ChURLund html_analyzernur zwei detaillierter beschrieben werden. ChURL (Check URL) wurdean der University of Michigan entwickelt und prüft unterAngabe einer URL, ob die Verweise in dort befindlichen Dokumentenvollständig definiert sind. Ein typischer Aufruf ist demnachchurl http://www.bsp.de/ . Mit diesem Aufruf werden alleunter der angegebenen Adresse befindlichen Dokumente bezüglichder Verweiskonsistenz getestet. Wichtig ist, daß man beliebigeURLs als Aufrufparameter angeben kann; also auch solche, die nichtder eigenen Administration unterliegen. Unter Angabe zusätzlicherOptionen kann festgelegt werden, ob auch die über Verweiseerreichbaren Dokumente auf Verweiskonsistenz hin geprüftwerden sollen. So führt der Aufruf churl -r -l 4 http://www.bsp.de/dazu, daß auch alle über maximal vier Verweise erreichbarenDokumente untersucht werden. Nach einem Durchlauf wird der Benutzerinsbesondere über Dokumentverschiebungen (http-Fehlermeldung:[3xx-Move] Redirection - document is now elsewhere), Dokumentexistenz(http-Fehlermeldung: [4xx-Err] Not found - document incorrectlylinked) und Verfügbarkeit von Servern (http-Fehlermeldung:[5xx-Err] Server error) informiert.
html_analyzerwurde von James Pitkow am Georgia Institute of Technologie entwickelt.Im Gegensatz zu ChURLwird als Aufrufparameter nicht eine URL sondern ein Pfadname angegeben.Der Aufruf hat folgendes Aussehen
html_analyzer /user/directory/. In diesem Fall werdenalle in dem Directory /user/directory/ befindlichen Dateienvom Typ *.html auf Verweiskonsistenz hin untersucht. Mit html_analyzerkann man also nur die Dateien untersuchen, die man selbst administriertbzw. auf die man ein Zugriffsrecht hat; beliebige URLs könnennicht angegeben werden. Außerdem ist es nicht möglich,auch die von den eigenen Seiten über Verweise erreichbarenDokumente zu prüfen. html_analyzerunterscheidet neben der Prüfung auf Dokumentexistenz dreiverschiedene, sehr spezielle Auffassungen von Verweiskonsistenz:

  1. Vollständigkeit: Ist ein Vorkommen eines Wortes in einemText als Ausgangspunkt eines Verweises definiert, so liegt Verweisvollständigkeitvor, wenn alle anderen Vorkommen dieses Wortes ebenfalls Ausgangspunkteines Verweises sind.
  2. Ankerkonsistenz: Ankerkonsistenz liegt vor, wenn alle Verweise,die dasselbe Wort als Ausgangspunkt haben, zu demselben Ziel führen.Ist also in einem Text zweimal das Wort "Auto" als Ausgangspunkteines Verweises definiert, wobei die Ziele verschieden sind (fürdas eine Vorkommen von "Auto" gelangt man zu einem DokumentA.html, für das andere Vorkommen zu einem Dokument B.html),so ist die Ankerkonsistenz nicht gegeben.
  3. Verweiskonsistenz: Verweiskonsistenz ist gegeben, wenn verschiedeneAusgangspunkte von Verweisen auch verschiedenen Ziele haben. Istalso einmal das Wort "Auto" als Ausgangspunkt mit ZielA.html definiert und ein anderes Mal das Wort "Flugzeug"mit dem Ziel A.html, so ist die Verweiskonsistenz verletzt.

3.2.2. Dynamische Spider
Der einzig (mir bekannte) dynamische Spider zum Prüfen vonVerweiskonsistenz ist der MOMSpider(Multi-Owner Maintenance Spider), der im Rahmen des Arcadia Projektesvon Roy Fielding an der University of California, Irvine, entwickeltwurde. Der wesentliche Unterschied zu den oben vorgestellten statischenSpider besteht darin, daß man bestimmte Zeitabständeangeben kann, in denen die Verweise in Dokumenten angegebenerServer untersuchen werden sollen. Die Informationen, die die zuprüfenden Dokumente bestimmen, liest der MOMSpider aus einerInstruktionsdatei. Dort wird angegeben, von welcher Top-URL diePrüfung begonnen. Zusätzlich ist zu spezifizieren, inwelchen Dokumentbereichen nicht weiter geprüft wird. Zu diesemZweck kann man drei verschiedene Dokumentbereiche angeben:

  1. Site: Es werden nur die Dokumente untersucht,die auf dem Server liegen, der unter der Top-URL angegeben ist.Dokumente anderer Server werden nicht weiter geprüft.
  2. Tree: Es werden alle Dokumente geprüft,die auf der Ebene (im Sinne von Directories) des Dokumentes liegen,das in der Top-URL angegeben ist. Dokumente, die nicht auf dieserEbene oder einer tieferen Ebene liegen, werden nicht behandelt.
  3. Owner: Hiermit kann die Konsistenzprüfungauf bestimmte Benutzerbereiche begrenzt werden. Kommt in der anzugebendenTop-URL die Benennung eines bestimmten Benutzers etwa in Formvon .../~user-name/... vor, so werden nur die Dokumentedieses Benutzers untersucht. Die Information, ob es sich um Dokumentedieses Benutzers handelt, wird aus dem META-Element der betroffenenHTML-Dateien geholt. Hier wird also vorausgesetzt, daß diesesMETA-Element entsprechend eingesetzt wird.
Zusätzlich können auch URLs explizit angegeben werden,wenn diese von der Konsistenzprüfung ausgeschlossen werdensollen.
Folgende Aspekte werden vom MOMSpider geprüft: Dokumentverschiebungen,Dokumentexistenz, Dokumentmodifikationen, Dokumentgültigkeit.Dokumentmodifikation und -gültigkeit können nur untersuchtwerden, wenn diese im HEADER-Element der jeweiligen HTML-Dokumenteeingetragen sind.

3.2.3 Weitere Spider
Der Vollständigkeit halber seien hier weitere Spider zurPrüfung von Verweiskonsistenz kurz genannt. So gibt es denW3M2Robot,Checkbotsowie den LinkVerifier.Zum LinkVerifier kann erwähnt werden, daß dieser auchHTML-Formular überprüft. Dabei wird jeder möglicheButton bei leeren Feldeinträgen "gedrückt",um festzustellen, ob das damit verbundene CGI-Skript auf Server-Seiteüberhaupt existiert.


3.2.4 Bewertung
Zunächst sollte als positiv hervorgehoben werden, daßes überhaupt einige Werkzeuge gibt, die sich mit der Verweisproblematikbeschäftigen und versuchen Administratoren von WWW-Servernzu unterstützen. Häufig vorkommende Ursachen (Dokumentgelöscht, umbenannt, verschoben) für undefinierte Verweisewerden stets entdeckt.
Allerdings müssen alle betroffenen Dokumente nachbearbeitetwerden, um die undefinierten Verweise entweder ganz zu löschenoder auf ein anderes Ziel zu setzen. Dies führt unweigerlichzu einem hohen Wartungsaufwand, wenn Internet-Ressourcen in großemUmfang erfasst werden. Ein weiterer Nachteil der Spider liegtdarin, daß sie das Netz und die Server zusätzlich belasten;nicht selten werden ganze Server aufgrund zahlreicher Anfragenvon Spidern lahm gelegt. Um dies zu verhindern, wurde eine Möglichkeitgeschaffen, um Robotern den Zugriff auf Server zu verbieten.Schließlich behandeln die Spider nicht die Ursache, diezur aufwendigen Konsistenzhaltung der Verweise führt, sondernsind lediglich Zusatzwerkzeuge, die versuchen, die konzeptionellenSchwächen von HTML und seiner Verwendung im WWW zu überwinden.

4. Ansätze über LRNund URN

Da die derzeitige Adressierung von Verweiszielen über dieAngabe einer URL zahlreiche Probleme mit sich bringt, gibt esBestrebungen Dokumente nicht mehr über ihren Standort sondernüber einen logischen Namen zu adressieren. Hierzu gibt esdie Ansätze der LRN(Local Resource Name) und URN(Uniform Resource Name). Beide werden im folgenden nähervorgestellt. In jüngster Zeit wird verwirrender Weise dieAbkürzung URNauch im Zusammenhang mit Java als JavaURN verwendet. Damit istjedoch das Java User Resource Networkgemeint, das nichts mit der URNzur Adressierung von Internet-Ressourcen zu tun hat.

4.1 Local Resource Name

Die Idee der LRNliegt darin, Dokumente eines einzelnen Servers über lokaleindeutige Namen zu identifizieren. Das Konzept der LRNkann somit als Vorstufe der URNgesehen werden, vgl. 4.2. In diesem Zusammenhang wurde am CERNein System namens WebLinkerentwickelt.
Eine LRNhat folgenden Aufbau:

http://<domain-name>/lrn/<LIN>/;Frag-Id= <fragment>.

Auf dem im domain-name angegebenen Rechner mußes ein Directory lrn geben. Weiterhin ist der Name einer lokalenInformationsstruktur (Local Infostructure Name - LIN) zu benennen.Schließlich muß ein Fragment als Fragmentidentifikatorspezifiziert sein. Eine LIN ist nichts anderes als eine Tabelle,in der jedem Fragment eine konkrete Datei auf dem angegebenenServer zugeordnet wird. Eine konkrete Ausprägung einer LRNsieht wie folgt aus:

http://www.bsp.de/lrn/Tabelle/;Frag-Id = Info.

Es wird nun an einem Beispiel illustriert, wie mit WebLinkerLRNsgehandhabt werden. Dafür ist es hilfreich, zwischen der Definitionvon Verweisen und deren Auflösung zu unterscheiden :
Es sei folgende LIN mit Namen Tabelle gegeben:

Tabelle
Info /WWW/B.html
Test /WWW/A.html

In einer HTML-Datei wird nun der Ausgangspunkteines Verweises definiert als

<A URN="Tabelle#Info"> Information</A>

Eine solche Definition wird durch den Dokumentkonverter von WebLinkerwie folgt automatisch ergänzt:

<A URN="Tabelle#Info"
HREF=http://www.bsp.de/lrn/Tabelle/;Frag-Id = Info>
Information </A>
Damit ist in der Definition des Verweisursprungs angegeben, unterwelchem Pfad die LIN (hier Tabelle) auf dem Rechner www.bsp.dezu finden ist. In dieser ist die Adresse des Dokumentes zu finden,das den logischen Namen Info hat. Wird nun einem solchen Verweisgefolgt, stellt eine zweite und auf dem jeweiligen Server zu installierendeKomponente von die Verbindung zur LIN Tabelle her und löstdort das Fragment Info auf. Als Zieldokument wird die Datei /WWW/B.htmlgeöffnet.

4.2 Uniform Resource Name

Die Verallgemeinerung einer LRN ist die URN (Uniform ResourceName). Auch hier ist die Idee, Internet-Ressourcen über logischeNamen, also über ihren Standort, und nicht über Rechnerpfadezu beschreiben. Die Uniform Resource Identifier (URI) WorkingGroup, eine Arbeitsgruppe innerhalb der Internet Engineering TaskForce (IETF), ist damit beauftragt, Syntax einer URN,ein Protokoll zur Auflösung, eine Strategie zur Auflösungund Formate für die Auflösungsergebnisse zu definieren.Um ihre Ergebnisse der Öffentlichkeit zu präsentieren,werden alle sechs Monate entsprechende Internet-Drafts von derIETF im Internet bereitgestellt. Die hier vorgestellten Zwischenergebnissestammen aus einem Entwurf vom September 1995.

4.2.1 Syntax einer URN
Eine URN hat folgendenAufbau:

<urn:scheme-id:authority-id:element-id>

Über die scheme-id wird festgelegt, nach welchemPrinzip die authority-id vergeben wird. Derzeit ist nurdns (Domain Name System) als scheme-id vorgesehen, dasauch schon von den URLs bekannt ist. Die Vergabe einer scheme-idwird von der Internet Assigned Numbers Authority (IANA) vorgenommen.Über die authority-id wird ein Name einer Gruppe,einer Person oder eines Systems innerhalb der gegebenen scheme-idbestimmt, die das Recht hat, eine element-id zu erzeugen.Über eine element-id wird letztendlich das Elementfestgelegt, auf das zugegriffen werden soll. Eine konkrete Ausprägungeiner URN, alsoeines logischen Namens für eine Internet-Ressource, ist somit:

<urn:dns:www.bsp.de:datei1>

Es sei bemerkt, daß etwa die URN

<urn:dns:www.examp.uk:datei1>

ein völlig anderer Name für eine Internet-Ressourceist, auch wenn beide dieselbe element-id haben.
Es wird auch darüber nachgedacht, die von Printmedien bekannteISBN als URN verwendenzu können. Eine solche URNhätte dann für ein Buch mit der ISBN 3-598-11078 folgendesAussehen:

<urn:isbn:3-598:59811078>

Über die scheme-id wird hier festgelegt, daßdie URN nun nacheinem anderen Verfahren als bei der Verwendung einer dns aufzulösenist. Als authority-id wird die Kennung eines Verlagesangegeben, dessen konkretes Buch in der element-id kodiertist.

4.2.2 Protokoll zur Auflösung
Als Auflösungsprotokoll wird die HTTP 1.0 Spezifikation vorgeschlagen


4.2.3 Strategie zur Auflösung undAuflösungsergebnisse
Um URNs auflösenzu können, ist es erforderlich, daß ein URN-Auflösungsserverauf der durch die dns beschriebenen Maschine eingerichtet ist.Ähnlich wie bei der LRN-Auflösung gibt es dort zu jederURN eine oder auchmehrere URLs. Benutzer können dann auswählen, von welchemServer sie eine Internet-Ressource beziehen möchten. DieErgebnisse, d.h. die Liste der zu einer URNgehörenden URLs können in verschiedenen Formaten zurückgegebenwerden:

  1. URC-0: Hierbei handelt es sich um ein strukturiertesTextformat, das geparst und
    daher elektronisch weiter bearbeitet werden kann.
  2. PLAIN: Hierbei handelt es sich um ein reinesunformatiertes Textformat, das mit beliebigen Textprogrammen gelesenwerden kann.
  3. HTML:Bei diesem Format werden die Ergebnisseals HTML-Seiten aufbereitet. Der Inhalt einer HTML-Seite setztsich aus den URLs zu der zuvor angewählten URNzusammen. Benutzer können durch Anwahl eines Verweises aufdas für sie am nächsten liegenden Dokument zugreifen.

4.3 Bewertung von LRNund URN

Das Konzept der LRNund URN geht sicherlichin die richtige Richtung. Insbesondere ist hiermit wesentlichweniger Wartungsaufwand verbunden, wenn Dokumente verschoben oderumbenannt werden. In solchen Fällen sind nur noch die Einträgein der LIN bzw. in dem URNAuflösungsserver, nicht aber die Dokumente selbst entsprechendzu aktualisieren. Werden jedoch Dokumente gelöscht, so gehenwie auch bei der Verwendung von URLs die Verweise verloren, dievon dem Dokument ausgehen. Verweise, die zu einem gelöschtenDokument zeigen, sind im Falle der LRN undefiniert. Hierfürmüssen in der LIN oder gar in den Dokumenten selber Aktualisierungenvorgenommen werden. URNssollen persistent sein, so daß bei ihrer Verwendung darangedacht wird, in dem URN-Auflösungsserver weiterhin lesbareInformationen über das nicht mehr vorhandene Dokument zuhalten. Zu diesem Zweck soll über die Verwendung von URCs(Uniform Resource Characteristics) eine Möglichkeit angebotenwerden, Metadaten über eine Ressource anzugeben und abrufbarzu machen. Ein weiterer Nachteil beim Konzept der LRNliegt darin, daß diese und das System WebLinkernur für Verweise zwischen Dokumenten auf einem Server, alsonur für den lokalen Einsatz gedacht sind. Zudem ist WebLinkerderzeit nicht für die Allgemeinheit zugänglich. FürURNs läßtsich derzeit nicht abschätzen, wann diese in Betrieb genommenwerden können. Allerdings sei noch einmal betont, daßsich die hier gemachten Angaben nur im Entwurfsstadium befindenund Prototypen von URN-Auflösungsservern noch nicht existieren.

5. Verweisverwaltung in Hyper-G


In diesem Abschnitt wird zunächst Hyper-G, ein Internet-Informationssystemder 2. Generation kurz allgemein eingeführt. Der Schwerpunktwird dann auf die Möglichkeiten zur Gewährleistung vonVerweiskonsistenz zwischen Hyper-G-Dokumenten gelegt.

5.1 Einführung in Hyper-G

Hyper-G ist ein auf einer Client/Server-Technologie basierendeshypermediales Internet-Informationssystem, das an der TechnischenUniversität Graz (daher das G in Hyper-G) unter Leitung vonHermann Maurer und Frank Kappe entwickelt wird. Die erste Freigabedes Systems erfolgte im Juli 1994, und seitdem sind regelmäßigneue Versionen des Systems der Öffentlichkeit zur Verfügunggestellt worden. Zudem wurde im Dezember 1995 das Hyper-G-Consortiumins Leben gerufen. Ziel dieser Einrichtung ist es, Aktivitätenum Hyper-G zu beobachten und die Weiterentwicklung von Hyper-Gzu koordinieren.
Wenn man von Hyper-G spricht, so meint man stets den gesamtenProduktumfang, der aus einem Server, Klienten sowie zahlreichenZusatzwerkzeugen besteht. Der Hyper-G-Server besteht seinerseitsaus drei Servern: Im Dokumenten-Server werden die eigenen Dokumenteabgelegt, im Verweis-Server werden die Verweise zwischen Dokumentenverwaltet, und der Volltext-Server enthält u.a. einen Volltextindexfür alle Textdokumente des Dokumentservers. Der Server kannauf verschiedenen Rechnerplattformen installiert werden, etwaauf SUN Sparc, HP 700, DEC-Stationen, SGI oder IBM PC (unter Linux).Als Klienten stehen Harmony für Unix/X11 und Amadeus fürMicrosoft Windows zur Verfügung. Im Gegensatz zu bekanntenKlienten, wie Netscape, bieten Harmony und Amadeus neben der reinenLesefunktionalität auch Autorenfunktionalität an. Hieraufwird in diesem Beitrag jedoch nicht eingegangen. Vielmehr seiauf die Literatur am Ende dieses Kapitels verwiesen. Zu den Zusatzwerkzeugenzählt etwa Haradmin zum Einrichten von Benutzer- oder Gruppenaccounts.
Hyper-G zeichnet sich insbesondere durch folgende Eigenschaftenaus:

5.2 Verweiskonsistenz in Hyper-G


Hyper-G bietet nun verschiedene Möglichkeiten, um die Verweiskonsistenzin Informationsstrukturen zu wahren. Da Hyper-G-Dokumente in HTML(früher im Hyper-G Text Format HTF) geschrieben und abgelegtwerden, hat man zunächst auch die enge Kopplung der Verweisdefinitionenan die Dokumente. Der Unterschied zu WWW-Servern liegt jedochdarin, daß die Verweise zwischen Hyper-G-Dokumenten auchals eigene Objekte in einen eigenen Verweis-Server verwaltet werden.Die aus dieser Konzeption resultierenden Vorteile werden im folgendenin Hinblick auf Löschen sowie Umbenennen und Verschiebenvon Dokumenten diskutiert.

5.2.1 Verweiskonsistenz beim Löschenvon Dokumenten
Hyper-G bietet die Möglichkeit, sich die Dokumente und Verweisezwischen Dokumenten in einer graphischen Darstellung (Local Map)anzeigen zulassen. Da Verweise bi-direktional sind, werden nichtnur die von Dokumenten ausgehenden sondern auch die eingehendenVerweise angezeigt. Somit kann vor dem Löschen eines Dokumentesin der Local Map geprüft werden, welche anderen Dokumenteauf das zu löschenden verweisen.
Wird ein Dokument eines Hyper-G-Servers gelöscht, so kannder Benutzer angeben, ob alle in das Dokument eingehenden undalle aus dem Dokument ausgehenden Verweise ebenfalls gelöschtwerden sollen. Werden die Verweise mit gelöscht, so werdensie auch automatisch aus dem Verweis-Server entfernt. Das Löschender eingehenden Verweise bewirkt, daß aus allen Dokumentendie zu dem zu löschenden Dokument führenden Verweiseentfernt werden. Somit werden hängende Verweise vermieden.

Werden die eingehenden Verweise nicht mit gelöscht, so entstehenzwar hängende Verweise, Hyper-G erkennt dies aber und zeigtdiese hängenden Verweise Benutzern nicht an. Das heißt,Hyper-G präsentiert Benutzern nur Verweise, deren Ziel auchtatsächlich definiert ist und denen somit gefolgt werdenkann. Beim Editieren von Dokumenten werden jedoch alle Verweise,auch die hängenden, angezeigt.

Hängende Verweise können unter bestimmten Randbedingungenin Hyper-G wieder automatisch vervollständigt werden. Dieswird im folgenden am Beispiel illustriert: Jedes Dokument einesHyper-G-Servers hat einen systemweit eindeutigen Namen, der vomBenutzer festgelegt werden kann. Dieser Name wird nur fürinterne Zwecke benötigt und ist vom Titel eines Dokumenteszu unterscheiden. Der Titel eines Dokumentes ist die fürLeser sichtbare, ausführliche Bezeichnung eines Dokumentes.Es existiere nun ein Verweis von einem Dokument mit Namen A zueinem Dokument mit Namen B. Wird das Dokument mit Namen B gelöscht,ohne daß die eingehenden Verweise gelöscht werden,so entsteht ein hängender Verweis, der vom Dokument A ausgeht.Wird nun ein neues Dokument angelegt, daß wieder den NamenB erhält, so wird der hängende Verweis automatisch wiederzu einem Verweis vom Dokument mit Namen A zum nun neuen Dokumentmit Namen B vervollständigt. Das Vervollständigen vonVerweisen ist nur dann möglich, wenn das Ziel eines Verweisesein ganzes Dokument ist. Für die anderen Ausprägungeneines Verweiszieles, etwa wenn nur ein einzelnes Wort Verweiszielist, bietet auch Hyper-G keine Möglichkeit zur automatischenNeudefinition von Verweisen.

Die hier beschriebenen Mechanismen funktionieren auch, wenn Verweisezwischen Dokumenten aus zwei verschiedenen Hyper-G-Servern definiertsind. Jeder Verweis wird dann in zwei Verweis-Servern gelegt,und zwar in die Verweis-Server der jeweils betroffenen Hyper-G-Server.Im Falle eines Löschvorgangs werden über ein Server-Server-Protokollsowohl die betroffenen Dokumente als auch die betroffenen Verweis-Serveraktualisiert.


5.2.2 Verweiskonsistenz beim Verschiebenund Umbenennen von Dokumenten
Wie oben bereits erwähnt, können die Dokumente einesHyper-G-Servers über ihren Namen eindeutig identifiziertwerden, sofern ein Name von Benutzerseite vergeben wurde. In jedemFall wird jedoch vom System eine innerhalb des Servers eindeutigeIdentifikation für jedes Hyper-G-Objekt vergeben. Beide Identifikationsmöglichkeitensind unabhängig von Rechnerpfaden o.ä. des Rechners,auf dem der Hyper-G-Server installiert ist. Diese Randbedingungenermöglichen nun ein Verschieben der Dokumente, ohne daßdarauf zeigende Verweise ihre Gültigkeit verlieren.
Vom Namen eines Dokumentes ist der Titel eines Dokumentes zu unterscheiden.Ein Titel ist die für Benutzer sichtbare Bezeichnung einesDokumentes. Da Verweise Dokumente jedoch über ihren Namenbzw. ihre intern vergebene Identifikation ansprechen, kann derTitel eines Dokumentes verändert werden, ohne daß Verweisein irgendeiner Form davon betroffen sind.

5.3 Bewertung

Die Möglichkeiten von Hyper-G zur Einhaltung von Verweiskonsistenzgehen weit über das hinaus, was WWW-Server bzgl. dieses Aspektesderzeit anbieten. Allein die Möglichkeit der Umstrukturierung,ohne sich um Verweise kümmern zu müssen, könnenbei der Erstellung und Wartung von Informationsstrukturen einegroße Hilfe sein. Auch die automatische Vervollständigunghängender Verweis kann sehr hilfreich sein, wenn diese gezielteingesetzt wird. Vorsicht ist jedoch geboten, wenn ein Verweiszwischen Dokumenten zweier verschiedener Hyper-G-Server aktualisiertwird. Hyper-G gestattet hier temporäre Inkonsistenzen. Sokann es sein, daß dieser Verweis in dem einen Verweis-Serverbereits aktualisiert wurde, in dem anderen Verweis-Server abernoch nicht. Es sollte auch nicht unerwähnt bleiben, daßdas Server-Server-Protokoll eine zusätzliche Belastung desNetzes darstellt.

6. Zusammenfassung

Dieser Beitrag stellt zunächst Ursachen für Inkonsistenzenbei Verweisen im WWW vor. Anschließend wurden Möglichkeitenund Werkzeuge aufgezeigt, mit denen man solche Inkonsistenzenentdecken kann. Hier läßt sich jedoch zusammenfassen,daß mit den Werkzeugen nicht die Ursachen der häufigenInkonsistenzen bei Verweisen behandelt werden. Demgegenüberversuchen die Ansätze der LRNund der URN neueWege zu gehen, um mehr Möglichkeiten zur Gewährleistungvon Verweiskonsistenz zu bieten. Allerdings befindet sich dasallgemeinere Verfahren über URNs zu adressieren noch in derSpezifikationsphase und ist daher selbst von Prototyprealisierungenweit entfernt. Eine erste tatsächlich einsetzbare Möglichkeit,um Verweisinkonsistenzen zu vermeiden, bietet jedoch Hyper-G.Hier werden neue Konzepte angeboten, etwa die Verwendung von bi-direktionalenVerweisen und von Verweis-Servern, mit deren Hilfe Inkonsistenzenbei Verweisen weitgehend vermieden werden können.

7. Literatur

[DaHe95] W. Dalitz, G. Heyer; Hyper-G Das Internet-Informationssystemder 2. Generation; dpunkt Verlag Heidelberg, 1995.

[Flo95] U. Flohr; Hyper-G Organizes the Web; Byte, Nov. 1995,S. 59-64.

[Mau96] H. Maurer; Vorabversion des Buches: Hyper-G The SecondGeneration Web Solution; erscheint 1996 bei Addison Wesley.

[Toc96] K. Tochtermann; Hyper-G und virtuelle Bibliotheken; Erscheint im Tagungsbandder INETBIB Tagung an der Universitätsbibliothek Dortmund,1996.