Zusammenfassung

  • Die in RFC 1625 beschriebene WAIS-Type-3-Anfrage konnte sowohl die eingegebenen Suchwörter als auch ein vollständiges Dokument oder einen ausgewählten Abschnitt als Relevanzrückmeldung enthalten; der Server lieferte geordnete Verweise, nicht die Dokumente.
  • Der Server speicherte den Ergebnissatz nicht für eine spätere Präsentation. Um einen Verweis abzurufen, sendete der Client eine weitere Search-Anfrage mit Doc-ID, Format und bei Bedarf einem Bereich in Bytes, Zeilen oder Absätzen.
  • RFC 1625 definierte die Schnittstelle für Anfrage und Antwort, aber weder eine serverübergreifend vergleichbare Relevanzskala noch eine vollständige Einsatzstatistik oder die Gründe für den späteren Niedergang von WAIS.

Das Dokument wurde Teil der Frage

Im Juni 1994 beschrieb eine Information-RFC, wie WAIS Z39.50-1988 verwendete. Sie stellte ausdrücklich klar, dass sie keinen Internetstandard festlegte. Ein praktisches Ziel war eine einfache Schnittstelle zwischen Client und Server: Der Client sollte den Text der lesenden Person senden können, ohne ihn zunächst in eine serverspezifische Type-1-Anfrage umzuwandeln oder alle unterstützten Z39.50-Attribute kennen zu müssen.

WAIS nannte diese Freitextform eine Type-3-Anfrage. Sie bestand jedoch nicht nur aus einer Zeichenfolge. Sie konnte die eingegebenen „seed words“ mit einer Liste von Dokumentobjekten kombinieren. Ein Objekt konnte das ganze Dokument oder nur einen Teil davon umfassen und wurde mit Doc-ID, Objekttyp, Chunk-Code sowie Anfangs- und Endposition beschrieben. Der Chunk-Code legte fest, ob die Positionen Bytes, Zeilen oder Absätze zählten.

Dieser zweite Eingang ermöglichte Relevanzrückmeldung: Ein Dokument oder einen Abschnitt auswählen und nach ähnlichen Dokumenten suchen. Der Client musste den Abschnitt nicht erst auf Schlüsselwörter reduzieren und das Ausgangsdokument anschließend verwerfen. Das Objekt selbst konnte zusammen mit zusätzlichem Suchtext in die nächste Anfrage eingehen. Wie die Datenbank durchsucht wurde, blieb Aufgabe des Servers. Das Protokoll beschrieb, was die Schnittstelle übertrug, nicht einen identischen Rangalgorithmus für jeden Index.

Das ist eine engere Geschichte als „das Internet lernte zu suchen“. WAIS war ein vernetztes Informationsretrievalsystem aus Clients, Servern, Datenbanken und Protokoll. Der Werkzeugbericht RFC 1689 vom August 1994 beschrieb frühe WAIS-Clients mit natürlichsprachlichen Suchanfragen und meldete mehr als 100 Datenbanken sowie 5.000 Nutzende weltweit. Das sind Angaben aus einem zeitgenössischen Bericht über Werkzeuge, keine unabhängig geprüfte Vollerhebung und keine Messung der späteren Verbreitung.

Eine Rangfolge war noch keine Antwort

Die Serverantwort enthielt eine Liste von WAIS Citations. Jeder Verweis konnte eine Überschrift, einen Relevanzrang, verfügbare Formate, eine Doc-ID und die Länge in Bytes nennen. RFC 1625 normierte den höchsten Wert auf 1.000. So ließ sich eine einzelne Antwort ordnen. Daraus folgt weder, dass Werte verschiedener Server vergleichbar waren, noch dass der erste Treffer objektiv relevant war oder die suchende Person eine brauchbare Antwort gefunden hatte.

Ein Verweis zeigte auf ein Objekt auf dem Server, enthielt aber nicht dessen Inhalt. Das bestimmte den Abruf. RFC 1625 beschrieb WAIS als zustandslos: Der Server speicherte den Ergebnissatz nicht und konnte ihn nach dem Versand der Antwort löschen. Deshalb verwendete WAIS in diesem Ablauf nicht die Present Facility von Z39.50. Für den ausgewählten Inhalt schickte der Client eine neue Search-Anfrage, diesmal mit einer Type-1-Abfrage, die Doc-ID und gewünschtes Format nannte. Anfang und Ende eines Bereichs konnten hinzukommen.

Die Abrufantwort konnte das ganze Dokument oder einen Ausschnitt enthalten. RFC 1625 begründete die Teilabrufe damit, dass Volltexte und Bilder größer als der Empfangspuffer eines Clients sein konnten. Das ist eine Designbegründung und eine Option, aber kein Beleg dafür, dass jeder Client stets in Abschnitten abrief. Ein angeforderter Ausschnitt war auch nicht automatisch das vollständige Dokument: Angefragten und tatsächlich gelieferten Bereich musste man abgleichen.

Damit entstehen drei getrennte Datensätze: die Eingabe der lesenden Person, die Rangfolge des Servers und der spätere Abruf des Clients. Type 3 konnte Suchtext und ausgewählten Abschnitt verbinden. Ein Citation zeigte auf ein bestimmtes Format eines serverseitigen Objekts. Eine zweite Anfrage holte einen begrenzten Bereich. Wer alles als ein einziges „Suchergebnis“ behandelt, verdeckt, wo Interpretation, Speicherung und Abruf stattfanden.

Auch die URI hatte einen Geltungsbereich

Die später 1994 veröffentlichte URL-Spezifikation unterschied WAIS-Adressen für eine Datenbank, eine Suche darin und ein einzelnes Dokument. Sie stellte außerdem klar, dass wais: keine allgemeine Adresse für beliebige Z39.50-Dienste war. Das Schema benannte Dienst und Zielart; es machte nicht jeden Verweis überall abrufbar.

Eine RFC von 2005 bewahrte das historische URI-Schema wais: und ergänzte einen knappen Statushinweis: Das WAIS-Protokoll war nicht weit verbreitet implementiert, und fast keine WAIS-Server waren noch in Betrieb. Das dokumentiert einen späteren Zustand, erklärt aber nicht dessen Ursachen. Die verfügbaren Quellen belegen weder, dass ein bestimmter Nachfolger WAIS verdrängte, noch dass die Relevanzschleife die allgemeine Verbreitung der Websuche auslöste.

Der engste Vergleich in dieser Reihe ist Sofia Rens Beitrag zur Buchbibliografie aus RFC 1432. Dort ging es darum, ob ein Bucheintrag, ein Preis oder eine Kontaktangabe noch zur Beschaffung führte. Dieser Beitrag behandelt eine andere Ebene: wie ein gewähltes Dokument in die nächste Anfrage einging, wie der Server Verweise ordnete und wie der Client anschließend Objekt und Bereich benannte. Die These betrifft den Suchablauf, nicht die Aktualität des Katalogs.

Quellen und Beleggrenzen

Primärquelle ist RFC 1625, ergänzt durch den zeitgenössischen Bericht RFC 1689. Den URI-Geltungsbereich beschreibt RFC 1738; der spätere historische Hinweis steht in RFC 4156. Keine dieser Quellen liefert eine vollständige Implementierungserhebung, einen Rangvergleich zwischen Servern oder eine Kausalerzählung zum Niedergang von WAIS.