>> Ressourcen > Theses > Neussl, Dietmar[..] > HTML-Version > Das Harvest-Suc[..]

 

Das Harvest-Suchsystem

Im folgenden Kapitel wird ein System der Universität von Colorado vorgestellt, das sich durch Vermeidung vieler der in Kapitel 2 erwähnten Schwächen auszeichnet. Das Harvest-Systemgif [BDH+94] stellt eine Sammlung von Werkzeugen zur Auffindung, Aufbereitung, Verwaltung und Suche von Informationen im Internet dar. Es kann Daten aus den verschiedensten Dokumentformaten (HTML, LaTeX, Tar- und Zipfiles, etc.) extrahieren. Zur Indizierung verwendet das Harvest-System externe Werkzeuge wie zum Beispiel Glimpse [WM93]. 
figure678 
Abbildung: Ineffizienz gewöhnlicher Suchsysteme (aus [BDH+94])

Das Harvest-Konzept

  Das Grundkonzept des Harvest-Systems [BDH+94] beruht auf der Idee der verteilten Informationsauffindung, Datenaufbereitung und Bereitstellung. Während zentrale Suchsysteme (siehe Abbildung 3.1) jedes für sich sämtliche gefundenen Dokumente über das Netz anfordern, dann analysieren und aufbereiten, geht Harvest einen anderen Weg. Ein Teil des Suchsystems ist für die Auffindung und Aufbereitung der Daten zuständig. Wie in Abschnitt 3.2 gezeigt wird, sollte dieser Teil möglichst lokal am Hostrechner des Informationsservers arbeiten. Der andere Teil des Systems bedient sich der so aufbereiteten Daten und stellt sie dem Suchenden zur Verfügung. Die Beschreibung im folgenden Abschnitt beruht auf [BDH+94] und [HSW96]. 
  figure691 
Abbildung: Lokal und über das Netz arbeitende Gatherer (aus [BDH+94])

Das Harvest-Suchsystem bietet die Möglichkeit des Aufbaues eines verteilten, kooperativen Suchsystems mit Hilfe zweier unterschiedlicher Komponenten: 

Der Gatherer 
sammelt und extrahiert periodisch verschiedenartige Dokumente von einem oder mehreren Informationsserver und generiert für jedes aufgefundene Dokument ein sogenanntes SOIFgif-Objekt. Dieses wird bei Bedarf weitergeleitet. Der Gatherer läuft üblicherweise am Hostrechner des Informationsservers. Abbildung 3.2.b zeigt eine solche Konfiguration. Gatherer, die am selben Host wie der Informationsserver arbeiten, geben Information an übergeordnete Instanzen weiter. Pro Server ist genau ein Gatherer vorhanden. Es ist jedoch auch möglich, daß ein oder mehrere Informationsserver von einem Gatherer bearbeitet werden, der auf einem anderen Rechner läuft. Abbildung 3.2.a zeigt einen Gatherer, der Daten von drei entfernten Informationsservern über das Netz lädt und diese an drei übergeordnete Module weiterleitet. 
Der Broker 
fragt die ihm zugeordneten Gatherer periodisch nach Änderungen des Informationsangebotes ab. Die erhaltenen SOIF-Objekte werden von ihm verwaltet und der Inhalt mittels externer Werkzeuge indiziert. Dem Benutzer stellt er über einen WWW-Client ein Suchinterface zur Verfügung. 
Gatherer und Broker können nun auf unterschiedlichste Weise zusammenarbeiten. Der linke Teil der Abbildung 3.2 zeigt einen Gatherer, der über das Netz auf die Daten des Servers zugreift; der Vorteil einer lokalen Suche kommt nicht zum tragen. Dennoch hat diese Konfiguration ihre Berechtigung, da aufgrund des Zusammenarbeitens mit mehreren Brokern die Belastung für Netz und Server reduziert werden kann.gif Der rechte Teil der Abbildung 3.2 skizziert eine Struktur, bei der sich der Gatherer am Rechner des Informationsservers befindet. Wie durch die dünneren Pfeile und Umrandungen angedeutet wird, werden bei dieser Konfiguration Netz und Server wesentlich weniger beansprucht. Die einzelnen Methoden, durch die diese Effizienzsteigerung möglich ist, werden im Abschnitt 3.2 erläutert. 

Der Broker kann Informationen von mehreren Gatherer beziehen. Ein Gatherer wiederum kann seine gesammelten Informationen an verschiedene Broker übermitteln. Schließlich können auch Broker ihre Informationen an andere Broker weiterreichen. Durch dieses Zusammenspiel der hierarchisch angeordneten Komponenten werden die Kosten für das Auffinden und Aufbereiten der Daten minimiert. 

Effizienz ist nicht die einzige Stärke der verteilten Suche. Durch die Nähe des Gatherers zum Informationsserver können zum Beispiel Informationen über den Server übernommen und Konfigurationsparameter individuell angepaßt werden.gif Durch die Gliederung des Informationsangebotes lassen sich weitere wichtige Eigenschaften erreichen. Diese Vorteile werden in Abschnit 3.4 erläutert. 

Das Metadatenformat SOIF

  Wie schon eingangs erwähnt, generiert der Gatherer für jedes aufgefundene Informationsobjekt eine Inhaltszusammenfassung (Content Summary). Diese enthält Attribut-Wert-Paare und wird im sogenannten Summary Object Interchange Format (SOIF) gespeichert. SOIF basiert auf einer Kombination von IAFA-Templates und BibTeX. 
figure719 
Abbildung 3.3: Das SOIF-Format: Formale Beschreibung in BNF (aus [HSW96])

Jedes SOIF-Objekt beinhaltet die URL des Dokumentes und eine Liste von Attribut-Wert-Paaren. Nach dem Namen des Attributes steht die Länge des Inhaltes. Dieses Format enthält aber nicht nur eine Teilmenge des Inhaltes des Originaldokumentes. Unterschiedlichste Zusatz- und Metainformationen können mit Hilfe der SOIF-Attribute festgehalten werden. Welche Metainformation im SOIF-Objekt steht, hängt beim Harvest-System vom Summarizer des entsprechenden Dokumentformates ab. Abbildung 3.4 zeigt ein HTML-Dokument und ein mögliches korrespondierendes SOIF-Objekt. Bei diesem Beispiel werden unter anderem fett gedruckte Textteile als Schlüsselwörter interpretiert und dem keywords-Attribut zugeordnet. Die Information des Meta-Tags fließt ebenfalls in die entsprechenden Attribute des SOIF-Objektes. Links werden erkannt und die Zieladresse im Attribut url-reference abgelegt. Ähnlich wird mit den Inhalten anderer HTML-Tags und HTML-Attributen verfahren. [HSW96

figure733 
Abbildung 3.4: Eine HTML-Datei und ein daraus generiertes SOIF-Objekt

Das SOIF-Format beschreibt keine starre Konvertierung von Dokumenten. Es stellt viel mehr einen Rahmen dar, der es erlaubt, den Inhalt unterschiedlichster Originaldokumente in ein einheitliches Objekt abzubilden, wobei die Zuordnung zu den Attributen individuell konfigurierbar ist. 

Wesentlicher Vorteil dieses Formates ist die einfache Verarbeitung. SOIF läßt sich "on-the-fly'' untersuchen und da es ohne spezielle Zeichen auskommt, braucht es keinen Escape-Mechanismus. Eine Menge von SOIF-Objekten läßt sich zu einem Paket zusammenstellen, das als Strom übertragen wird. Nachteilig wirkt sich aus, daß ein Fehler innerhalb des SOIF-Stroms dessen gesammten restlichen Inhalt unbrauchbar macht. [NK94

Die meisten Module des Harvest-Systems befassen sich unmittelbar mit dem SOIF-Format [Wes95]: 

  • Die Module des Essence-Subsystems (Summarizer) geben SOIF-Objekte aus (siehe Abschnitt 3.2.1). 
  • Die "Datenbank''gif des Gatherer beinhaltet SOIF-Objekte. 
  • Der Gatherer exportiert den Inhalt dieser Datenbank in Form eines SOIF-Stromes. 
  • Der Broker empfängt, indiziert und speichert SOIF-Objekte im Dateisystem. 
  • Der Broker exportiert wieder SOIF-Ströme. 

Der Gatherer

  Der Gatherer des Harvest-Systems [BDH+94] sammelt periodisch Dokumente innerhalb eines definierten Bereiches und extrahiert deren Inhalt. Der Auffindungsbereich wird durch Start-URLs und maximalen Suchtiefen festgelegt und durch konfigurierbare URL-, Server- und IP-Domainfilter eingeengt. Die Linkverfolgung wird in Abschnitt 3.2.2 erläutert. Neben verschiedenen Zugriffsarten wie FTP, Gopher, NetNews, HTTP und lokales Dateisystem unterstützt das Harvest-System mannigfaltige Dateiformate. Auf diese und deren Aufbereitung wird im Abschnitt 3.2.1 eingegangen. Die Flexibilität des Gatherer erlaubt es, auf das Harvest-System die unterschiedlichsten Suchdienste aufzusetzen. 

Um einen Index von zum Beispiel HTML-Objekten erstellen zu können, muß bei zentralen Suchsystemen jedes einzelne Objekt über das Netz angefordert und geladen werden. Anschließend erfolgt das Extrahieren der Hyperlinks. Mit deren Zieldokumenten wird gleich verfahren. Diese Methode ist äußerst ineffizient, da so für jedes Objekt eine TCP/IP-Verbindung errichtet und ein neuer Prozeß gestartet werden muß. 

Ein Gatherer, der resident am Rechner des Providers ist, vermeidet diesen Overhead. Er greift im allgemeinen über das lokale Dateisystem auf die Daten zu und sucht die HTML-Objekte periodisch ab. Dabei werden nur Dokumente neu untersucht und in einen lokalen Cache aufgenommen, die sich seit dem letzten Mal verändert haben. Wie die Konsistenz zwischen Informationsserver und Broker erreicht wird, wird in Abschnitt 3.3 gezeigt. Bei einer Anfrage eines Broker an einen Gatherer können die extrahierten Daten somit auf einmal geladen werden. Dies führt zu enormen Verringerung der Serverlast. Konkrete Messungen und Zahlen werden in [BDH+94] erläutert. 

Um die Netzwerklast zu minimieren, verwendet der Harvest im wesentlichen drei Verfahren: 

  • Das Essence-Subsystem (Abschnitt 3.2.1) des Gatherers extrahiert aus dem Inhalt der Informationsobjekte sogenannte Content Summaries (SOIF-Objekte), die dann an einen oder mehrere Broker geschickt werden. Diese Objekte sind, abhängig von der Konfiguration, im wesentlichen kleiner als die ursprünglichen Dokumente. 
  • Alternativ zum normalen Format können die Daten auch komprimiert übertragen werden. 
  • Je größer die Update-Rate des Index im Vergleich zur mittleren Zeitspanne der Veränderungen der Dokumente ist, desto sinnvoller sind inkrementelle Verfahren zur Indexerstellung. Hierbei wird ein Objekt nur im Falle einer inhaltlichen Veränderung neuerlich übertragen. Im Fall von HTTP verwendet der Gatherer den "if-modified-since''-Headereintrag in der Anfrage. Greift der Gatherer direkt auf ein Dateisystem zu, entnimmt er aus dem Dateieintrag den Zeitpunkt der letzten Änderung. Zusätzlich bildet er eine MD5-Prüfsumme über die einzelnen Dokumente und kann gegebenenfalls mit ihrer Hilfe entscheiden, ob ein Dokument neu aufgenommen werden muß. Durch dieses inkrementelle Verfahren spart man sich einerseits das Extrahieren des Originaldokumentes und andererseits die Übertragung zum Broker und die anschließende Indizierung. 

Das Essence-Subsystem

  Das Essence-System [HS95] des Gatherer teilt die Aufgabe der Informationsextraktion auf mehrere Komponenten auf. Der Typ des Informationsobjektes muß erkannt, eventuelle Einkapselung aufgelöst und die zur Indizierung verwendbaren Dateien ausgewählt werden. Erst dann folgt der eigentliche Prozeß des Extrahierens. Speziell für den entsprechenden Dokumenttyp entwickelte Module filtern Information aus dem Objekt und stellen sie in einem SOIF-Objekt zusammen. Alle typenspezifischen Methoden können außerhalb des Essence-Systems definiert, ergänzt und konfiguriert werden. 
Typerkennung: 
Sie wird mit Hilfe der Erweiterung des Dateinamens (zum Beispiel *.html für HTML-Dateien) und durch implizite Erkennung, indem der Dokumentinhalt selbst untersucht wird (Magic Number Test), durchgeführt. Bei typenbehafteten Dateisystemen (zum Beispiel OLEgif bei Microsoft Windows) wird die Typinformation aus dem Dateieintrag selbst gewonnen. 
Entkapselung: 
Die Typenerkennung kann eine Einkapselung (Komprimierung, Gruppierung, Verschlüsselung) feststellen. Diese wird nach Möglichkeit aufgelöst. Das Ergebnis ist im allgemeinen eine Menge von Dateien. 
Auswahl: 
In diesem Schritt werden Vertreter uninteressanter Objekttypen ausgeschieden. Dieses Verhalten ist natürlich konfigurierbar. Falls durch eine Entkapselung aus einem Objekt mehrere Teile entstanden sind, wird zusätzlich die Redundanz berücksichtigt und Einzelobjekte entsprechend verworfen. So können zum Beispiel alte Dateiversion (zum Beispiel *.bak) eliminiert werden, wenn eine neue Version existiert und Objektcode ausgeschieden werden, wenn der entsprechende Quellcode vorhanden ist. 
Inhaltszusammenfassung: 
Basierend auf der Typinformation wird in diesem Schritt eine passende Extraktionsprozedur (Summarizer) zur Verarbeitung des Objektes aufgerufen. Jeder Dokumenttyp hat einen eigenen Summarizer, der wiederum individuell vom Andministrator des Gatherer angepasst werden kann. Aufgrund des objektorientierten Ansatzes des Essence-Systems, lassen sich Methoden eines Summarizer an andere vererben. So ist der HTML-Summarizer ein Spezialfall des SGML-Summarizer. Dieser hält sich genau an die Spezifikationen von HTML. Für gängige, selbsterstellte HTML-Dokumente ist dieses Verfahren zu wenig fehlertolerant. 

Wie dieser Teil des Essence-Systemes für den Fall von HTML-Dateien funktioniert und welche Probleme die Verwendung des SGML-Summarizer mit sich bringt, wird im Abschnitt 4.1 diskutiert. 

Die Linkverfolgung

  Um den Auffindungsbereich im Informationsraum zu bestimmen, hat der Administrator mehrere Möglichkeiten. Er kann die URL der Objekte individuell festlegen (leave node) oder einen Startpunkt (root node) mit einer maximalen Verzweigungstiefe angeben. Zusätzlich können Stopplisten mit URLs von Dokumenten und Sides geführt werden. So läßt sich zum Beispiel erreichen, daß sich der Gatherer auf Objekte innerhalb eines bestimmten Bereiches beschränkt. Die Verwendung von regulären Ausdrücken in den Konfigurationsdateien erlaubt eine Vielfalt an Einstellungen. [HSW96

Damit der Vorteil eines lokalen Gatherer zum tragen kommt, müssen die URLs, die er von den Konfigurationsdateien liest und im Laufe des Auffindungsprozeßes extrahiert, in eine URL des Dateisystems umgewandelt werden. Im allgemeinen werden die Dokumente eines Informationsservers in einem eigenen Verzeichnis verwaltet. Dieses Verzeichnis kann für den Zugriff über den Server neu benannt werden. Somit gelangt keine Information über die tatsächliche Verzeichnisstruktur nach außen. Der Administrator kennt beide Bezeichnungen, den lokalen Pfad und die Entsprechung für HTTP oder FTP. In der Konfigurationsdatei kann er für beliebige URLs den lokalen Pfad vermerken. Extrahiert der Gatherer eine nicht-lokale URL, kann er diese, falls ein Eintrag in der Konfigurationsdatei existiert, in einen Pfad des Dateisystems umwandeln und über diesen Weg lokal auf die Datei zugreifen. [HSW96

Der Gatherer untersucht nun zu festgesetzten Zeiten die Startdokumente und ermittelt, nachdem der Inhalt behandelt wurde (siehe Abschnitt 3.2.1), die darin enthaltenen Links. Mit den Zieldokumente der Links wird nun auf gleiche Weise verfahren. Beendet wird dieser Prozeß, wenn alle Links im definierten Bereich verfolgt wurden. 

Der Broker

  Der Broker des Harvest-Systems [BDH+94] ist die Schnittstelle zwischen Gatherer und Index einerseits und zwischen aufgefundenem Wissen und Benutzer andererseits. Er verwaltet die vom Gatherer bereitgestellten SOIF-Objekte und veranlaßt die Indizierung durch externe Werkzeuge. Dem Benutzer stellt er mit Hilfe eines Web-Clients und eines CGI-Skripts eine Schnittstelle zur Kommunikation mit dem Suchsystem bereit. Des weiteren kann er seine SOIF-Objekte einem anderen Broker zur Verfügung stellen. Folgende Teilmodule führen die Arbeit des Broker aus [Cam94]: 
Der Registry-Manager 
wartet eine Liste der im Broker existierenden SOIF-Objekte. Der Registry-Eintrag setzt sich aus einem Ablaufdatum- und einem ID-Feld, das aus URL und Gatherer-Information gebildet wird, zusammen. Das Ablaufdatum wird aus der Summe des "update-time''gif- und des "time-to-live''gif-Wertes gebildet. Wenn dieser Zeitpunkt erreicht ist, wird das Objekt aus der Registry entfernt. Bei jedem Update des Broker wird so die Lebensdauer der noch am Informationsserver befindlichen Objekte verlängert.gif 
Der Storage-Manager 
archiviert die Sammlung von SOIF-Objekten, indem er sie im darunterliegenden Dateisystem speichert. Er eliminiert mehrfach vorhandene Objekte. Zum Vergleich bedient er sich der MD5-Signatur und der Gatherer-ID. 
Der Collector 
fragt periodisch die Gatherer und andere Broker nach Updates ab. Diese antworten mit einem SOIF-Strom, der die in ihrem Bereich aufgefundenen Dokumente beschreibt. Objekte, die seit der letzten Brokeranfrage neu erstellt oder inhaltlich verändert wurden, müssen zum Storage Managager weitergeleitet und in der Registry neu aufgenommen werden. Um die neuen Dokumente zu indizieren, ruft derCollector anschließend über das Indexinterface den externen Indexer auf. Die Lebensdauer der Objekte, die vor der letzten Anfrage vorhanden waren und deren Inhalt sich nicht verändert hat, wird in der Registry verlängert, indem die neue "update-time'' in die Berechnung einfließt. 
Der Query-Manager 
empfängt Anfragen von einem Suchclient (Web-Client via CGI), übersetzt diese in ein Format, das von der angebunden Suchmaschine akzeptiert wird, und schickt es dieser. Die Suchmaschine antwortet mit einer Liste von "Identifiern'' von Objekten, die der Suchanfrage genügen. Der Query Manager erzeugt nun eine kurze Beschreibung dieser Objekte und schickt sie dem Suchclient zurück. Im Fall, daß der Broker von einem darüberliegenden Broker abgefragt wird, werden alle entsprechenden SOIF-Objekte als Ganzes, und nicht deren Kurzbeschreibung, übertragen. Dies geschieht mit einem eigenen Protokoll (Bulk Transfer). So ist es für einen Broker machbar, eine Teilmenge des Inhaltes eines anderen Broker aufzunehmen. 
Wenn ein Dokument als SOIF-Objekt im Broker erstellt wird, wird eine Objekt-ID in der Registry hinzugefügt; das Summary-Objekt wird vom Storage Manager archiviert und von der Suchmaschine indiziert. Befindet sich ein Objekt beim nächsten Update des Broker noch immer am Informationsserver, wird seine Lebensdauer neu berechnet. Falls dieser Eintrag abläuft, weil das korrespondierende Dokument am Informationsserver entfernt wurde, wird das Objekt lediglich aus der Registry gelöscht. So kommt es, daß im Laufe der Zeit die Inkonsistenz zwischen Inhalt des Storage Manager und der Registry-Einträge zunimmt. Daher wird periodisch eine Bereinigung dieses Zustandes (Garbage Collection) durchgeführt. 

Das oben erwähnte "time-to-life''-Attribut legt die Zeitspanne fest, innerhalb derer ein Objekt im Broker existieren kann, obwohl der zuständige Gatherer das entsprechende Dokument nicht mehr aufgefunden hat. Dies hat den Vorteil, daß im Fall von kurzzeitiger Außerbetriebnahme des Informationsservers oder von Wartungen einzelner Dokumente, die Einträge im Index nicht gelöscht werden müssen, um beim nächsten Update wieder neu generiert zu werden. 

Die Konsistenz zwischen Suchindex des Broker und Dokumenten am Informationsserver sinkt also mit der Länge des Abfrageintervalls und der Differenz zwischen "time-to-live''-Eintrag sowie der tatsächlichen Lebensdauer. Die Lebensdauer in der Registry kann fix vom Administrator des Broker vergeben oder aus dem SOIF-Objekt entnommen werden. Der Gatherer kann sie aus den Metadatengif des Dokuments berechnen. 

Die Administration des Broker wird über den Query Manager abgewickelt. Viele Konfigurationsparameter können so manipuliert werden. Dazu gehören die Liste der Gatherer und Broker, die als Informationsquelle dienen, die Standardlebensdauer der Objekte, die Abfragerate und die Rate der Garbage Collection

Das Indexinterface

  Damit der Broker verschiedensten Ansprüchen gerecht werden kann, wird eine flexible Schnittstelle zwischen Broker und Indexer definiert, nicht aber ein spezieller Indexer spezifiziert. Unterschiede im Design von Indexern erschweren dabei das Erstellen eines Interface. Einige Indexer indizieren objektweise, andere arbeiten besser, wenn sie viele Objekte gleichzeitig indizieren können. Einige Indexer können keine einzelnen Objekte löschen, was eine Reindizierung notwendig macht. Aufgrund dieser Differenzen werden vom Broker vier Interfaceoperationen bereitgestellt [Cam94] [HSW96]: 
Update_Object 
wird vom Collector bei jedem Update im Storage Manager pro Objekt einmal aufgerufen. 
Index_Flush 
wird vom Collector nach jedem Update gestartet. 
Garbage_Collect 
wird vom Broker zum Löschen von nicht mehr aktuellen Einträgen im Index verwendet. Falls der Indexer dies nicht unterstützt (Glimpse), wird von hieraus die Reindizierung eingeleitet. 
Resolve_Query 
generiert aus dem brokereigenen Abfrageformat das Format des jeweiligen Indexers. Dieses wird dem Indexer übermittelt, das Resultat analysiert. Resolve_Query gibt die IDs der im Ergebnis vorkommenden Objekte zurück. 
Zum Beispiel kann ein Indizerwerkzeug, das Objekte einzeln bearbeitet, dies mit Update_Object tun; Index_Flush wird nicht gebraucht. Für einen andere Indizierer, der Objekte gebündelt indiziert, werden mit Update_Object die einzelnen Update-Anfragen zwischengespeichert und am Ende mit Index_Flush gesammelt indiziert. 

Das Suchinterface

  Damit der Benutzer über das Web mit dem Broker kommunizieren kann, wurde ein Webinterface implementiert. Dieses besteht im wesentlichen aus [HSW96]: 
  • HTML-Dateien, die Formsgif verwenden. Sie stellen die grafische Benutzerschnittstelle (GUIgif) dar. 
  • einem CGIgif-Programmteil, das die Daten aus den HTML-Forms liest, daraus eine Anfrage formuliert und diese schließlich an den Query Manager des Broker leitet. 
  • einem CGI-Programmteil, das das Resultat der Anfrage in ein HTML-Dokument bettet und desen Darstellung am Webbrowser veranlaßt. Beide CGI-Programmteile sind somit die Verbindung zwischen GUI und der Funktionalität des Query Manager
Das Suchinterface unterstützt, abhängig von der verwendeten Suchmaschine, unterschiedlicheste Anfragetypen. Die Anfragesyntax ist einheitlich, da erst im Indexerinterface das interne Anfrageformat in das entsprechende Format des Indexers umgewandelt wird. Kann ein spezieller Broker eine Anfrage nicht weiterbehandeln, weil der Indexer deren Typ nicht unterstützt, wird eine Fehlermeldung ausgegeben. Glimpsegif [WM93] kann folgende Anfragetypen verarbeiten: 
  • wahlweise Berücksichtigung der Groß- und Kleinschreibung 
  • Wildcards 
  • Suche nach Phrasen 
  • boolsche Verknüpfungen 
  • Begrenzung der Suche auf spezielle SOIF-Attribute 
  • Möglichkeit der Angabe der maximalen Anzahl der Resultate, die ausgegeben werden sollen 

Vorteile der verteilten Suche

  Aufgrund der Topologie des Gesamtsystems und der Nähe zur Wissensquelle ergeben sich Vorteile, die nachfolgend beschrieben werden und die Ursache für weitere Effizienzsteigerungen sind. Speziellen Verfahren des Harvest-Suchsystems erzielen weitere Verbesserungen. 

Es sei hier angemerkt, daß das System der verteilten Suche auch einen großen Nachteil hat. Mit der Verteilung der Aufgaben geht zwangsläufig ein Mehraufwand an Organisation einher. So ist man in erster Linie auf die Mitarbeit der Informationsanbieter angewiesen, will man einen verteilten Suchdienst ins Leben rufen. Da diese aber im allgemeinen an der Verbreitung ihrer im Netz befindlichen Dokumente interessiert sind, dürften sich die Widerstände in Grenzen halten. 

Netzwerk- und Serverbelastung

  Wie in Abschnit 3.2 schon erwähnt wurde, ist die Reduktion der Last für Netz und Server beim Harvest-Verfahren mehrfach begründet: 
  • Die Auffindung im lokalen Dateisystem ist wesentlich effizienter als die Kommunikation via HTTP. 
  • Durch Übertragung einer Sammlung von vielen Objekten statt Einzelübertragung, werden aufwändige Betriebssystemaufrufe (UNIX-Fork) gespart. 
  • Die Erstellung von Inhaltszusammenfassungen (Content Summaries) und deren mögliche Komprimierung verringert die zu sendende Datenmenge. 
  • Inkrementelles Update des Broker macht nur die Übermittlung der Veränderungen notwendig. 
  • Schließlich reduziert die Zusammenarbeit vieler Dienste den Aufwand der Informationsauffindung und Vorverarbeitung. 

Vollständigkeit, Aktualität und Linkkonsistenz

Das System der verteilten Suche beschränkt sich bei der Erreichung der Vollständigkeit auf Teilbereiche. Die kleinste Einheit ist durch den Informationsserver gegeben. Mittels lokalem Gatherer kann, aufgrund der Nähe und geringerem Aufwand, der Informationsserver wesentlich häufiger als bei zentralen Suchmodellen abgesucht werden. Dies führt zu einem guten Maß an Aktualität und somit zu Konsistenz innerhalb des Untersuchungsgebietes. [BDH+94

Die Absuchrate kann für jeden Server individuell angepaßt werden. So werden Server mit dynamischem Informationsangebot öfter untersucht werden müssen, als solche, deren Inhalt sich kaum verändert. [HSW96

Die Zusammenfügung von mehreren Teilbereichen eines betrachteten Informationsraumes erweitert die Vollständigkeit auf den gesamten Bereich, ohne daß sich die Aktualität verschlechtern würde. 

Gliederung des Informationsraumes

Wie in Abschnitt 3.2.1 und Abschnitt 3.2.2 beschrieben wurde, kann ein Administrator die Gatherer in seinem Bereich individuell anpassen. So kann dieser aufgrund seiner Kenntnis, in welchen Verzeichnissen welche Themen behandelt werden, Gatherer für unterschiedliche Wissensgebiete einrichten. 

Die Broker können sich nun in zweierlei Hinsicht spezialisieren. Entweder kontaktieren sie nur Gatherer und Broker, die sich innerhalb eines geographischen Gebietes beziehungsweise einer Domain befinden, oder sie wählen nur themenspezifische Quellen aus. Natürlich setzt dies das Wissen um die Gatherer und Broker und deren Angebot voraus. Dieses Wissen kann als Zusatzinformation (siehe Abschnitt 3.4.5) über den Server und die Website vom Gatherer zur Verfügung gestellt werden. Kooperation braucht Organisation. 

Die Möglichkeit der Zusammenarbeit einzelner Suchdienste kann in einer hierarchischen Struktur erfolgen. Bei dieser Topologie nimmt der Spezialisierungsgrad nach obenhin ab, der Umfang an Dokumenten nimmt zu. 

Qualität und Zuverlässigkeit

Aus dem oben erwähnten läßt sich schon ersehen, wie ein verteiltes Suchsystem die Güte von Information bewerten kann. Eine Möglichkeit besteht darin, daß der Broker mittels eines lokalen Gatherer eine Beschreibung des Informationsservers 3.4.5 ermittelt und so auf die Qualität des Inhaltes schließt. Es ist auch denkbar, daß ein Broker nicht nur themenspezifisch sondern auch qualitätsspezifisch einer Gruppe angehört. 

Ein anderer Weg wäre die Verwendung von Experten, die die Dokumente an ihrem Server beurteilen. Diese Bewertung könnte als Metainformation im Dokument vermerkt und in weiterer Folge als Attribut im SOIF-Objekt aufgenommen werden. 

Zusatzinformation über Server und Sites 

  Die Nähe des Gatherer zur Informationsquelle erlaubt es, auch über diese selbst Informationen zu sammeln und bereitzustellen. Von Interesse sind Eigenschaften wie Betreibername, Qualitätsmaß, thematische Kategorie, Größe, Richtlinien für das Dokumentenlayout und statistische Werte wie zum Beispiel die durchschnittliche Änderungsrate der Dokumente. Diese Zusatzinformationen ermöglichen erst die Zusammenarbeit einzelner Teilsuchsysteme, die anhand dieser Eigenschaften gruppiert werden können. 

Die Serverinformationen verbessern auch, unabhängig von Zusammenschlüssen, die Brauchbarkeit der Suchergebnisse. So können zum Beispiel Fehler, die auf Mehrdeutigkeit des Suchbegriffes beruhen, durch Berücksichtigung von thematischen Kategorien vermieden werden. Bei der zweistufigen Ergebnispräsentation (siehe Abschnitt 4.2.4) dient die Serverinformation als Beschreibung und somit als Hilfe für den Benutzer, der entscheiden muß, welche Server genauer durchsucht werden sollen. 

Zusammenfassung

Das Grundkonzept des Harvest-Systems beruht auf der Idee der verteilten Informationsauffindung, Datenaufbereitung und Bereitstellung. Ein Harvest-Gatherer sammelt periodisch Dokumente innerhalb eines definierten Bereiches und extrahiert deren Inhalt. Neben den verschiedenen Zugriffsarten (HTTP, FTP) und lokales Dateisystem unterstützen die Verarbeitungsmodule des Gatherer eine Reihe von Dateiformaten. Ein Teilsystem des Gatherer erzeugt aus dem Dokumentinhalt sogenannte SOIF-Objekte. Diese werden dann zum Zwecke der Bereitstellung über das Netz weitergeleitet. 

Der Harvest-Broker ist die Schnittstelle zwischen Gatherer und Index einerseits un zwischen Index und Benutzer andererseits. Er verwaltet die vom Gatherer bereitgestellten SOIF-Objekte und veranlaßt deren Indizierung durch externe Werkzeuge. Dem Benutzer stellt er mit Hilfe eines Web-Clients und eines CGI-Skripts eine Schnittstelle zur Kommunikation mit dem System bereit. Damit verschiedene Indexer mit dem Broker zusammenarbeiten können, ist eine flexible Schnittstelle zwischen Broker und Indexer definiert. 

Broker können ihre Daten austauschen. So kann ein kooperierendes verteiltes Suchsystem aufgebaut werden. Einzelne Broker können speziellen Themen zugeordnet werden und ihre Daten an übergeordnetere Broker weiterreichen. 

Durch das Konzept der verteilten Suche ergeben sich eine Reihe von Vorteilen, wie zum Beispiel die Reduktion der Netzwerk- und Serverlast, die das Harvest-System im Vergleich zu anderen Suchsystemen auszeichnet. Weiters führen die Nähe des Gatherer zur Informationsquelle und die mögliche Zusammenarbeit einzelner Teilsysteme zu einem vergleichsweise hohen Grad an Effizienz und Aktualität. 

Im folgenden Kapitel werden einzelne Module des hier vorgestellten Harvest-Systems im Detail untersucht und daraus Verbesserungs- und Erweiterungsvorschläge abgeleitet. 


Nächstes Kapitel: Verbesserungspotential am Harvest-System Vorhergehendes Kapitel: Suchdienste 

Zur Titelseite