Zusammenfassung

  • ALIWEB überließ den Informationsanbietern die Auswahl der beschriebenen Ressourcen, bündelte Einsammeln und Suche aber in einem zentralen Dienst.
  • Der Pilot von 1994 zeigt, dass andere Kataloge einen kleinen Index nutzen konnten. Er belegt weder eine vollständige Abdeckung des Web noch eine breite Verbreitung.

Ende 1993 ging es im Web nicht mehr nur darum, Dokumente zu veröffentlichen. Man musste sie auch finden können, ohne jeden Server einzeln zu durchstöbern oder einen Roboter jede erreichbare Seite abrufen zu lassen. Manuell gepflegte Listen boten Kontext, konnten aber nicht jede Verschiebung und jeden neuen Dienst nachtragen. Ein Crawler fand mehr, verursachte jedoch wiederholte Zugriffe auf Server und verlor leicht die Struktur, die einer Sammlung ihren Sinn gab.

Am 30. November 1993 kündigte Martijn Koster ALIWEB als Experiment für eine „verteilte“ Webindexierung an. Jeder Server sollte seine Inhalte in einer lokalen Datei beschreiben; eine zentrale Stelle würde diese Dateien abrufen und verarbeiten; die zusammengeführte Datenbank ließe sich anschließend über das Web durchsuchen. Laut Kosters späterem Konferenzbeitrag lief der Pilot auf dem NEXOR-Webserver bereits seit Oktober. In seiner Ankündigung vom 30. November nannte Koster das Verfahren einen ersten Schritt, keine endgültige Lösung. Zugleich versprach er, die Daten sollten sich leicht weiterverwenden oder konvertieren lassen, sobald bessere Verfahren entstünden.

Dieses Versprechen macht die Architektur verständlicher. ALIWEB dezentralisierte nicht den Suchdienst selbst, sondern verteilte die Kontrolle über den Index. Der Administrator einer Website wählte aus, welche Dokumente und Dienste einen Eintrag erhalten sollten, und beschrieb sie. Der Betreiber von ALIWEB führte die Liste teilnehmender Server, bestimmte die Abrufintervalle, prüfte das Format, kombinierte gültige Einträge und betrieb die Suchoberfläche. Der Anbieter beschrieb die eigene Website; der zentrale Dienst bestimmte den Weg, auf dem diese Beschreibung andernorts auffindbar wurde.

Die Eingabe war eine vorbereitete Textdatei, häufig /site.idx genannt, auf Grundlage der Vorlagen der Internet Anonymous FTP Archives (IAFA). Die Attribut-Wert-Einträge konnten mehrere Objekte in einer Datei beschreiben, etwa mit Vorlagentyp, Titel, URI, Beschreibung und Schlagwörtern. ALIWEB versuchte nicht, die Bedeutung jeder Seite aus ihrem Markup abzuleiten. Stattdessen konnten diejenigen, die die Website kannten, wichtige Einstiegspunkte auswählen und die interne Ordnung erhalten. Kosters Beispiel beschreibt NEXORs Perl-Material und Handbuch, nicht sämtliche Dateien des Servers.

Die Teilnahme erforderte dennoch eine kleine Betriebsvereinbarung. Ein Administrator meldete Server, Port und Pfad der Indexdatei über ein Webformular an, nannte eine zuständige Kontaktperson und konnte einen Mindestabstand zwischen Abrufen festlegen. ALIWEB prüfte vor der Annahme, ob die Datei vorhanden war und das erwartete Format hatte. Ein separater Perl-Prozess prüfte die registrierten Dateien regelmäßig, rief Änderungen ab und baute die gemeinsame Datenbank über UNIX-cron neu auf. Suchbar war sie über das ALIWEB-Formular oder über andere Kataloge, darunter den CUI W3 Catalog.

Der Unterschied zu einem Roboter, der das gesamte Web durchläuft, lag in der Arbeitsweise, nicht darin, ob automatisiert wurde. ALIWEB sammelte und kombinierte automatisch, rief aber eine benannte Indexdatei ab, statt jedem Link zu folgen und alle erreichbaren Dokumente eines Servers zu laden. Das senkte den Datenverkehr und bewahrte den Kontext des Anbieters. Dafür konnte eine Seite unsichtbar bleiben, wenn sie im gelieferten Index fehlte, selbst wenn ein Crawler sie hätte erreichen können. Die Aktualität hing daher ebenso von der gepflegten Datei ab wie vom zentralen Abruf.

Kosters Pilotzahlen zeigen Nutzung und Grenzen zugleich. Zum Zeitpunkt des Beitrags waren 54 Hosts registriert und 310 Einträge in der Datenbank. Das einfache ALIWEB-Suchformular erhielt durchschnittlich 80 Anfragen am Tag; der CUI W3 Catalog nutzte die Datenbank mehr als 8.000-mal pro Woche. Das belegt einen laufenden Dienst und eine nützliche Integration. Es sagt nicht, welcher Anteil des Web indexiert war, wie gut die Treffer waren oder wie viele Server eine gültige Datei pflegen konnten oder wollten.

Probleme bei der Anmeldung zeigten sich früh. Einige Administratoren registrierten einen Host, ohne eine Indexdatei bereitzustellen – offenbar, weil sie das Formular gefunden hatten, bevor sie das Modell verstanden. Das Team erweiterte die Dokumentation und prüfte nun sofort, ob die Datei vorhanden und formal gültig war. Fehler in den Dateien traten weiterhin auf. ALIWEB protokollierte sie; ein manuell gestartetes Skript schrieb dann der zuständigen Person. Die Dezentralisierung beseitigte Wartungsarbeit also nicht. Sie verlagerte sie vom Abrufen jeder Seite auf das Erstellen, Prüfen und Aktualisieren eines ausgewählten Indexes.

„Manuell“ musste nicht bedeuten, dass jede Zeile dauerhaft von Hand geschrieben wurde. Koster hielt eine automatische Erzeugung für möglich, sofern genug beschreibende Metadaten für die Auswahl erhalten blieben. 1995 dokumentierte ein anderes Archivprojekt IAFA-Vorlagen, die anhand von Änderungen im Dateisystem aktualisiert und zu Text-, Gopher- und HTML-Indizes verarbeitet wurden. Dieser Beitrag der W3C-Konferenz zeigt, dass die Vorlagen mehrere Ansichten speisen konnten. Er belegt weder eine Migration von ALIWEBs eigenem Datenbestand noch eine breite Verbreitung des Dienstes.

Mit dem Wachstum trat eine zweite Grenze hervor. Koster räumte ein, dass eine einzelne Datenbank für das gesamte Web zu groß werden könnte. Als mögliche Auswege nannte er verteilte Abrufe, gespiegelte Suchzugänge, thematische Teildatenbanken oder eine Hierarchie von ALIWEB-Diensten. Außerdem erwartete er, Indexdateien könnten automatisch in künftige Verzeichnissysteme überführt werden. Das waren Vorschläge im Beitrag, keine nachweislich eingeführten Funktionen. Historisch wichtig ist die Absicht, dass das Format den zentralen Sammler des Piloten überdauern sollte.

Eine Übersicht zur netzweiten Informationssuche von 1994 beschrieb das Feld noch als jung; Klassifikationskontrolle und andere Funktionen waren nicht weit verbreitet. ALIWEB stand neben manuellen Listen, dem CUI W3 Catalog und Robotersystemen wie JumpStation oder der RBSE-URL-Datenbank. Es war nicht das erste Websuchwerkzeug. Sein engerer Beitrag bestand darin, die automatische Sammlung von Beschreibungen zu zeigen, die Anbieter selbst ausgewählt hatten und andere Systeme weiterverwenden konnten.

Heng Lus spätere Note 65 zur Priorität laufenden Codes bietet eine rückblickende Deutung, aber keinen Beleg für Kosters Beweggründe: Ein Format kann Portabilität versprechen; real wird sie erst, wenn laufende Systeme es übernehmen. Der Beitrag dokumentiert den ALIWEB-Piloten und die Nutzung seiner Datenbank durch den W3 Catalog. Er belegt weder eine allgemeine Übernahme noch ein Mandat über Webanbieter oder eine vollzogene Migration. Die historische Unterscheidung hat drei Teile: Anbieter bestimmten, was ihre Websites aussagten; ALIWEB bestimmte, was in den gemeinsamen Index gelangte; spätere Systeme konnten die Datei weiterverwenden, ohne den zentralen Dienst des Piloten zu übernehmen.