>> Ressourcen > Theses > Neussl, Dietmar[..] > HTML-Version > Verbesserungspo[..]

  Qp=(A1,a1) andp(A2,a2) andp....andp(An,an)
Qp=(A1,a1) orp(A2,a2) orp...orp(An,an

Die Negation der boolschen Anfrage (Q) aus den beiden Gleichungen wird wie folgt dargestellt: 

Qp=not Q 

Es seien nun weiters dA1,dA2,...,dAn die Gewichte der Wörter im Index. Die Ähnlichkeit (SIM(Q,D)) zwischen Anfragen (Qand, Qor, Qnot) und Dokument (D) errechnet sich im P-Modell aus: 

SIM(Qand p,D)=wurzelp{a1pdA1p+a2pdA2p+...+anpdAnpa1p+a2p+...+anp

SIM(Qor p,D)=1-wurzelp{a1p(1-dA1)p+a2p(1-dA2)p+...+anp(1-dAn)pa1p+a2p+...+anp

SIM(Qnot p)=1-SIM(Q,D)  

und liegt im Intervall [0,1]

Der so errechnete Wert für die Ähnlichkeit zwischen einem Dokumenten und einer Anfrage gibt an, wie gut das Dokument zu Anfrage paßt. Durch unterschiedliche Bewertung der Suchterme (a1,a2,...,an) in der Anfrage gehen die einzelnen Koordinaten der Dokumente (dA1,dA2,...,dAn) mehr oder weniger stark in die Distanzberechnung ein. Im Falle, daß alle Suchwortgewichte gleich sind, fallen sie aus den Gleichungen heraus. Je größer p, desto größer wird der Unterschied zwischen Konjunktion und Disjunktion. Für den Fall p=1 ergeben sich, wie man leicht aus den Gleichungen entnehmen kann, zwei idente Gleichungen. Je größer die Ähnlichkeitswerte zwischen gefundenem Dokument und Suchanfrage sind, desto wichtiger ist dieses im Gesamtergebnis. 

Beispiel 1: 
Die Suchabfrage Q ((Zug,0.4) and (Straße,0.3)) sei nun durch den Vektor (0.4, 0.3)dargestellt. Es sei weiters p=2. Gesucht wird in den Dokumenten nach Abbildung 4.1. Für die Ähnlichkeiten der Anfrage mit den Dokumenten DA und DB ergibt sich nun: 

SIM(Q,D) = 1-sqrt{0.42(1-dZug)2+0.32(1-dStraße)20.32+0.42
Werden für dZug und dStraße die entsprechenden Werte aus der Tabelle aus Abbildung 4.1 eingesetzt, ergeben sich schließlich folgende Resultate : 
SIM(Q,DA) = 0.5348; SIM(Q,DB) = 0.7136
Dokument DB wird hier vor DA gereiht. 

Beispiel 2: 
Gesucht wird wieder in den Dokumenten nach Abbildung 4.1. Die Suchabfrage Q sieht wie folgt aus: ((Zug,0.5) or(Straße,0.1))p=2. Das Wort "Zug'' ist nun in der Abfrage wichtiger als das Wort "Straße''. Für die Ähnlichkeiten dieser Abfrage mit den gefundenen Dokumenten ergeben sich: 

SIM(Q,D) = 1-sqrt{0.52(1-dZug)2+0.12(1-dStraße)20.52+0.12
und somit 
SIM(Q,DA) = 0.7148; SIM(Q,DB) = 0.6495
Dokument DA ist in diesem Fall wichtiger als DB

Mit Hilfe eines Index, der ein Datenbanksystem als Basis hat, ließen sich die für dieses Verfahren notwendigen Daten verwalten. Dies Suchmaschinen des Harvest-Systems sind dazu nicht in der Lage. 

Die hier eingeführte Ähnlichkeit zwischen einem Dokumenten und einer boolschen Anfrage gibt Auskunft darüber, wie gut ein Dokument zu einer Anfrage paßt. Der Ähnlichkeitswert kann als Kriterium für die Reihung im Suchergebnis dienen. Gefundene Dokumente, deren Ähnlichkeitswert einen konfigurierbaren Schwellwert unterschreiten, könnten aus dem Gesamtewrgebnis ausgeschieden werden. Unter Verwendung des P-Modells ist es auch möglich, einzelnen Suchtermen in der Anfrage mehr oder weniger wichtig einzustufen. 

Zusatzinformation über Server und Sites

Die verteilte Suche hat unter anderem den wesentlichen Vorteil der Nähe zum Informationsangebot. Im Abschnitt 3.4.5 wurde auch die daraus resultierende Möglichkeit erläutert, Informationen über den Server oder einer Site bereitzustellen. Das Harvest-System macht davon allerdings keinen Gebrauch. 

Folgende Zusatzinformationen scheinen nützlich: 

Thematische Kategorien und Qualitätsbezeichnung 
können einerseits als erste Orientierungshilfe für den Benutzer dienen. Andererseits lassen sich Gatherer, die Informationsdiensten der selben Kategorie bzw. Qualität zugeteilt sind, anhand dieser Information gruppieren und zu einem gemeinsamen, umfassenderen Suchdienst zusammenfügen. 
Namen der Autoren und Herausgeber 
geben u.a. Auskunft über Qualität und Seriosität der angebotenen Information. 
Kurzbeschreibung des Gesamtinhaltes 
kann ebenfalls als Orientierungshilfe verwendet werden und in einer zweistufigen Suche (siehe Abschnitt 4.2.4) als Informationsbasis dienen. 
Statistische Werte 
Zum Beispiel kann die durchschnittliche Lebensdauer der Dokumente die Update-Rate des Suchsystems beeinflussen. Je kürzer die Lebensdauer desto öfter muß der Informationsbereich untersucht werden. Die durchschnittliche Anzahl der "Besucher'' kann ein Maß für die Bedeutung des Dokumentes sein. 
Der Gesamtindex müßte über einen Mechanismus verfügen, der eine Zuordnung von Dokumenten zu Server (bzw. Sites) erlaubt, damit die Serverzusatzinformationen bei bekanntem Dokument ermittelt werden kann. Zusätzlich sollten auch in den Serverzusatzinformationen gesucht werden können, was deren Indizierung notwendig machen würde. 

Benutzerschnittstelle

Multimediaobjekte und Skripts

Oft ist es aus Sicht des Benutzers wünschenswert, zusätzlich zu den eigentlichen Suchbegriffen, noch andere Kriterien anzugeben. So könnte er das Suchergebnis auf Dokumente mit oder ohne eingebettete Multimedia-Objekte beschränken. Der Gatherer des Harvest-System kann zwar so konfiguriert werden, daß er eingebettete Objekte in einem SOIF-Attribut vermerkt, als Suchkriterium kann es aber nicht ohne weiters dienen, da ja nicht der Inhalt des Attributes sondern allein dessen Auftreten im SOIF-Objekt maßgeblich ist. 

Es wäre auch wünschenswert, das Vorhandensein und den Typ eingebetteter Objekte im Suchergebnis darzustellen. 

Zweistufige Ergebnisaufbereitung

Ist der Suchterm einer Suchanfrage zu unspezifisch, werden zu viele Dokumente als Ergebnis geliefert. Der Aufwand der Suche steigt während die Brauchbarkeit des Resultats sinkt. Ein möglicher Ausweg wäre es, in solchen Fällen nicht nach einzelne Dokumente, sondern nach Informationsserver zu suchen und deren Namen als Suchergebnis zu liefern. Die Suche könnte somit auf Benutzerwunsch oder automatisch "gröber'' ausgelegt werden. In einem zweiten Schritt wäre dann eine genauere Suche innerhalb der ausgewählten Server notwendig, um eine Dokumentenliste als Resultat zu erhalten. 

Damit nicht alle Dokumente im Index überprüft werden müssen, kann man sich zuerst auf die indizierte Zusatzinformation des Servers beschränken. Ein Stichwortkatalog oder eine thematische Beschreibung des Informationsangebotes wäre denkbar. Auch wenn dies nicht möglich ist, hat diese Zweistufigkeit ihre Berechtigung. Zwar bliebe der Aufwand unverändert, da in den Dokumenten gesucht werden muß, die Suchergebnisdarstellung wäre aber wesentlich kompakter und strukturierter. Alle gefundenen Dokumente eines Servers beziehungsweise einer Site wäre nur durch einen Eintrag (URL und Kurzbeschreibung des Servers (Site), Anzahl der gefundenen Dokumente) in der Ergebinsdarstellung repräsentiert. 

Zusammenfassung

In diesem Kapitel wurden Verbesserungsmöglichkeiten am Harvest-System im Bereich der HTML-Konvertierung und des Suchindexes aufgezeigt. 

Es wurden Verbesserungsvorschläge in Bereich der Konfigurierbarkeit und der Anbindung an externe Module gemacht. Die Fehlertoleranz der HTML-Parsers ist zu gering sollte, so wurde vorgeschlagen, an das Verhalten der Web-Browser angepaßt werden. 

Die Suchindex des Harvest-Systems wird mittels externer Suchmaschinen (Glimpse) bereitgestellt und verwendet. Diese eignen sich nicht für komplexere Aufgaben auf dem Gebiet der Suchabfrage und Suchergebnispräsentation. Einige wünschenswerten Methoden, wie zum Beispiel der Keyword-Relenvanz-Filterung und das Ranking des Suchergebnisses, wurden beschrieben. 

Die Erkenntnisse dieses Kapitels sind Ausgangspunkte für die Veränderungen am Harvest-System, die im wesentlichen aus zwei Teilen bestehen: 

  • Ein neuer HTML-nach-SOIF-Konverter und seine Eigenschaften werden in Kapitel 5 beschrieben. 
  • Ein Suchindex auf Basis relationaler Datenbanken und die sich daraus ergebenden neuen Möglichkeiten für die Suche und Ergebnisdarstellung sind Thema des Kapitels 6

Nächstes Kapitel: Gestaltungsbereich Vorhergehendes Kapitel: Das Harvest-Suchsystem 

Zur Titelseite 


Verbesserungspotential am Harvest-System

Auf den folgenden Seiten werden die entsprechenden Module des Harvest-Systems zum Parsen von HTML-Dokumenten und zum Indexaufbau auf Verbesserungmöglichkeiten untersucht. Die tatsächliche Umsetzung von Verbesserungen werden im Abschnitt Gestaltungsbereich (Kapitel 5 und 6) ausführlich beschrieben. 

Die HTML-SOIF-Konvertierung

Der HTML-Parser

Das Essence-Subsystem (siehe Abschnitt 3.2.1) des Harvest-Gatherer beinhaltet u.a. einen Summerizer, der die Konvertierung der HTMLgif-Seiten in SOIF-Objekte durchführt. Bevor auf die Problematik der Konvertierung eingegangen wird, werden zuerst die wesentlichen Eigenheiten von HTML beschrieben. 

HTML - Hypertext Markup Language

HTML [Rag] ist eine SGMLgif-Anwendung [Cov], die mittels einer DTDgif definiert ist [Gro]. Die Markup-Befehle (Tags) werden von spitzen Klammerngif umschlossen, um sie vom eigentlichen Text zu unterscheiden. Manche dieser Tags haben Parameter (sogenannte Attribute), die in der Form <TAG ATTR1=VALUE1 ATTR2=VALUE2> angegeben werden. 

Bei Tags und Attributen wird die Groß- und Kleinschreibung nicht berücksichtigt. Bei den Attributwerten hingegen wird manchmal, abhängig vom jeweiligen Attribut, die Schreibweise übernommen. Die Argumente müssen zwischen Anführungszeichen eingeschlossen werden, wenn diese Sonderzeichen beinhalten oder dei Schreibweise explizit beachtet werden soll. 

Einfache oder mehrfache Leerstellen oder Zeilenwechsel wirken (von Spezialfällen wie Text innerhalb des <PRE>-Tags abgesehen) jeweils so wie ein Leerzeichen. Somit läßt sich der Text im HTML-Dokument optisch gliedern, ohne das Aussehen des Dokumentes davon beeinflußt wird. 

Die meisten HTML-Befehle bestehen aus einem Start-Tag der Form <TAG> und einem End-Tag der Form </TAG>. Diese Befehlspaare legen jeweils die Bedeutung des dazwischen liegenden Textes fest. So umschließt zum Beispiel das Tag-Paar <TITLE> und </TITLE> den Titel eines HTML-Dokumentes. 

Einzeln auftretende HTML-Befehle (ohne End-Tag) bezeichnen bestimmte Elemente, die an der entsprechenden Stelle eingefügt werden. So bewirkt zum Beispiel <BR> einen Zeilenumbruch im HTML-Dokument. 

Die paarweisen HTML-Befehle müssen immer richtig geschachtelt werden. Nicht erlaubt sind Verschränkungen. Die gängigen Web-Browser (Netscape, Internet Explorer) tolerieren allerdings solche syntaktisch falschen Definitionen (siehe nächster Absatz). Kommentare können in der Form <!- Kommentar -> eingefügt werden. Damit der Kommentartext tatsächlich von allen Browser-Versionen als Kommentar erkannt wird, sollte er weder - noch > enthalten. 

Anpassung an das Verhalten der Web-Browser

Der HTML-Parser des Gatherer hält sich strickt an die DTD-Spezifikationen von HTML [HSW96]. Die Web-Browser (Netscape, Internet Explorer) verhalten sich wesentlich toleranter. Testläufe am IICMgif zeigten zum Teil große Unterschiede zwischen SOIF-Objekt und angezeigten HTML-Text. Hier einige Beispiele des nicht HTML-konformen Verhaltens der Web-Browser: 
  • Text vor dem <BODY>-Tag führt zu keinem Fehler und wird sogar angezeigt. 
  • Das <HEAD>-Tag hat keinen Einfluß. Es wird ignoriert, unabhängig von der Platzierung im Dokument. 
  • Verschränkte Definitionen werden von den Web-Browser aufgelöst. Un zwar wird bei einem End-Tag die innerste Definition geschlossen, gleichgültig welches Tag diese geöffnet hat. In HTML sind sie nicht erlaubt. 
  • Kommentare werden wie folgt akzeptiert: <!Kommentar> 
  • Steht zwischen den spitzen Klammern ein Tag, das syntaktisch richtig, aber kein HTML-Tag ist, so wird es ignoriert. 
  • Steht zwischen den spitzen Klammern etwas anderes als ein syntaktisch richtiges Tag, wird der Text mit den Klammern als Text interpretiert und angezeigt. 
Die Autoren von Web-Seiten überprüfen ihre Dokumente mit Hilfe der Web-Browser. Das Erscheinungsbild am Browser ist somit das entscheidende Kriterium bei der Dokumentenerstellung. Damit Konsistenz zwischen SOIF-Objekt und für den Benutzer sichtbarer Information herrscht, wäre eine Angleichung des HTML-Parsers an die Eigenschaften der Web-Browser notwendig. 

Konfigurierbarkeit und Fehlertoleranz

Der Parser kann so konfiguriert werden, daß er einzelne Tag-Inhalte ignoriert [HSW96]. <CODE> wäre ein sinnvolles Beispiel dafür. Der Code kommt so nicht in den Volltext. Textteile die innerhalb dieser Definition durch ein anderes Tag, zum Beispiel als Schlüsselwort, gekennzeichnet sind, werden natürlich auch nicht in die Menge der Schlüsselwörter aufgenommen, da der ganze Bereich ignoriert wird. Beinhaltet der Code einen Hyperlink, also ein <A>-Tag mit einer Referenz als Attribut, so wird dieser ebenfalls ignoriert. Da der Benutzer allerdings einen Link sieht und ihn benutzen kann, sollte das SOIF-Objekt den Link auch aufnehmen. Daher darf sich das Ignorieren von HTML-Inhalten nicht auf die HTML-Attribute enthaltener HTML-Definitionen auswirken. 

Des weiteren kommt es bei fehlerhaften HTML-Dokumenten oft zu unvorhersehbaren Reaktionen des Parsers. Sobald ein Fehler erkannt wird, ist das resultierende SOIF-Objekt unbrauchbar. Wünschenswert wäre hier ein toleranteres Verhalten. So sollten verschränkte Definitionen bearbeitet und nicht in HTML definierte beziehungsweise nicht benötigte Tags ignoriert werden. 

Modifikation der SOIF-Attribute

Das SOIF-Format (siehe Abschnitt 3.1) hat keinen festen Attributsatz. Es lassen sich somit neue Attribute für die Generierung der SOIF-Objekte selbst definieren. Auch der HTML-Summerizer des Gatherer ist in weiten Bereichen konfigurierbar. So lassen sich nach Abschluß des Parsen und der Erstellung des SOIF-Objektes bestehender SOIF-Attribute im Zuge einer Nachbearbeitunggif modifizieren. Zum Beispiel können Überschriften nachträglich sortiert und doppelt vorhandene Schlüsselwörter löschen. Dennoch bleiben diesbezüglich einige Wünsche offen: 
  • Bestehende SOIF-Attribute lassen sich zwar im Objekt nachbearbeiten, neue Attribute können aber nicht mehr eingefügt werden. So läßt sich zum Beispiel mittels eines externen Moduls ein SOIF-Attribut "Inhaltszusammenfassung'' nur dann in das SOIF-Objekt integrieren, wenn bereits ein solches existiert. 
  • Inhalte von SOIF-Attributen können nicht in Abhängigkeit des Inhaltes eines anderen SOIF-Attributes modifiziert werden. Zum Beispiel wäre es wünschenswert, nur dann die aus dem Text extrahierten Schlüsselwörter zu verwenden, wenn keine durch das <META>-Tag gewonnen wurden. 
  • Es ist nicht möglich, den Inhalt eines SOIF-Attributes unter Berücksichtigung der HTML-Tags zu gliedern, da die Information der HTML-Formatierung nach dem Parsen nicht mehr zur Verfügung steht. Der Mechanismus einer Gliederung wäre zum Beispiel im Volltextattribut ein Weg, um Absätze und Überschriften zu kennzeichnen. 
  • Standardwerte können nicht vergeben werden. So kann zum Beispiel beim Auftreten eines <SCRIPT>-Tags ohne Language-Attribut der Standardwert JavaScript im entsprechenden SOIF-Attribut nicht vermerkt werden. 
  • Da sich die Nachbearbeitung des SOIF-Objektes immer nur auf ein Attribut pro Arbeitsgang bezieht, können keine Abhängigkeiten zwischen zwei oder mehreren Attributen in die Modifikation einfließen und Verschmelzungen von Attributinhalten nicht durchgeführt werden. So wäre es zum Beispiel wünschenswert, nach der Generierung des SOIF-Objektes externe Module entscheiden zu lassen, ob und welche SOIF-Attribute zusammengefügt werden sollen. Diese Möglichkeit ist vor allem dann sinnvoll, wenn der SOIF-Attributname mittels <Meta>-Tag des HTML-Codes bestimmt wird (siehe nächsten Abschnitt). Zum Beispiel können Schlüsselwörter sowohl aus dem Textteil extrahiert als auch mittels <META>-Tag gewonnen werden. Im Zuge der Nachbearbeitung könnte nun entschieden werden, welche Schlüsselwortmenge ins SOIF-Attribut keywords gelangt. So könnte auch die Vereinigungsmenge beider das SOIF-Attribut ergeben. 

Metadatengenerierung

Metadaten können über das <META>-Tag in ein SOIF-Attribut abgelegt werden. Der HTML-Summerizer des Gatherer kann nicht zwischen statischen SOIF-Attributnamen und solchen, die mittels <Meta>-Tag erzeugt wurden, unterscheiden. Wäre dies der Fall, könnte der Summerizer in der Nachbearbeitungsphase entscheiden, ob diese Metadaten zum Inhalt des gleichlautenden SOIF-Attributes, dessen Inhalt aus dem Text ermittelt wurde, hinzugefügt werden, ob sie dieses ersetzt oder ob sie gelöscht werden. Metadaten und Daten aus dem Inhalt könnten auch, abhängig von der jeweiligen Konfiguration, verknüpft werden. So wäre es dann zum Beispiel machbar, Schlüsselwörter aus dem Text und aus den Metadaten entweder zusammenzulegen oder, abhängig von der Konfiguration, die einen oder die anderen zu verwerfen. 

Automatische Zusammenfassung

Eine Kurzzusammenfassung des Dokumentinhaltes ist in erster Linie eine Orientierungshilfe für den Benutzer. Der Harvest generiert keine automatische Zusammenfassung des Inhaltes. Die Integration von Modulen zur Erstellung von Zusammenfassungen ist zwar mit Hilfe der Nachbearbeitung denkbar; brauchbare Ergebnisse erzielt man aufgrund der oben erwähnten Einschränkungen im ursprünglichen Harvest-System kaum. 

Folgende neue Wege und deren Kombination sind vorstellbar: 

  • Verwendung von HTML-Metaattributen (z.B.: ABSTRACT, DESCRIPTION, etc.) 
  • Inhalte verschiedener SOIF-Attribute (z.B.: title, headings etc.) 
  • Suche nach Absatz im Volltextattribut, der mit "abstract'', "Inhaltsangabe'', "Zusammenfassung'' etc. beginnt. Dies ist nur möglich, wenn der Volltext im SOIF-Objekt nach Abschnitten gegliedert ist. 
  • Wahl des ersten oder des letzten Absatzes. 
Die Art und Weise, wie eine Inhaltszusammenfassung erzeugt wird, müßte individuell vom Administrator des Informationsservers bestimmt werden können, da er über die Richtlinien des Dokumentenlayouts in seinem Bereich verfügt. So beinhalten wissenschaftliche Publikationen in der Regel eine Zusammenfassung. Diese könnte dann vom Administrator mittels Konfiguration für den Eintrag im SOIF-Objekt bestimmt werden. 

Spracherkennung

Der Name WORLD WIDE WEB impliziert schon Mehrsprachigkeit. Die Sprache ist eines der wesentlichen Merkmale eines Dokumentes. Da von der Möglichkeit, die Sprache mittels <Meta>-Tag im HTML-Header anzugeben, selten gebrach gemacht wird, sind Spracherkennungsmodule notwendig. Im Gatherer fehlt jedoch eine Schnittstelle zur Spracherkennung. Auch die oben beschriebene Methode der Nachbearbeitung der SOIF-Objekte ist aufgrund der oben beschriebenen Schwachpunkte dafür nicht geeignet. Spracherkennungsmodule müssen auf mehrere Attribute schreibend und lesend zugreifen können. Dies ist bei HTML-Summerizer, wie schon erwähnt, nicht machbar. 

Ein Spracherkennungsmodul müßte den Inhalt des Volltext-SOIF-Attributes lesen, und das Resultat seiner Untersuchung - die Sprache - in Form einer Kennung in ein entsprechendes SOIF-Attribut ablegen können. 

Der Suchindex

Das Harvest-System verwaltet seinen Suchindex mittels externer Werkzeuge wie zum Beispiel Glimpse (siehe Abschnitt 3.3). Über das Indexinterface können auch andere Indexer an den Broker angeschlossen werden (siehe Abschnitt 3.3.1). 

Eine wesentliche Schwäche der Indizierung liegt darin, daß die Suchmaschinen den Inhalt der SOIF-Dateien indizieren, ohne zwischen Metadaten und tatsächlichem Inhalt zu unterscheiden. Attributnamen werden ebenso indiziert wie Einträge, die Lebensdauer, URL etc. beinhalten. Das hat zur Folge, daß zum Beispiel bei einer Suche nach "md5'' alle indizierten Dokumente als Ergebnis ausgegeben werden, weil jedes SOIF-Objekt ein Attribut dieses Namens enthält. 

Es lassen sich auch keine statistischen Aussagen über die Häufigkeit einzelner Wörter und deren SOIF-Attribut machen. Diese Information ist notwendig, wenn man häufig vorkommende Wörter ausscheiden und das Suchergebnis anhand einer Gewichtung der Wörter sortieren will. 

Keyword-Relevanz-Filter

Ein Keyword-Filter hat die Aufgabe, nicht gewünschte Schlüsselwörter auszuscheiden und so die Menge der indizierten Wörter zu verkleinern und damit die Brauchbarkeit der Schlüsselwörter des Index als Unterscheidungskriterium der Dokumente zu erhöhen [GDN+98]. Statisch kann dies mittels Stoppliste geschehen. Dieser Mechanismus ist im Gatherer integriert [HSW96]. Ein Relevanzfilter hingegen mißt die Häufigkeit des Auftretens eines Schlüsselwortes, vergleicht diesen Wert mit einem voreingestellten Schwellwert und entscheidet dann, ob dieses auch tatsächlich aufgenommen wird. Dem Harvest-Systems fehlt ein solches Verfahren. 

Der Index unterliegt ständigen Veränderungen und so kann die Worthäufigkeit eines Wortes einmal unterhalb und einmal oberhalb des Grenzwertes liegen. Daher müssen alle Worteinträge mitgeführt werden und entsprechend der Worthäufigkeit ein- und ausgeblendet werden. Da ein Schlüsselwort als Unterscheidungsmerkmal einzelner Dokumente dienen soll, spielt die Häufigkeit des Auftretens innerhalb eines Dokumentes für die Relevanzbetrachtung keine Rolle. Mit steigender Anzahl der Dokumente, in denen das Schlüsselwort enthalten ist, nimmt dessen Brauchbarkeit als Suchkriterium in Form eines Keywords ab. Es kann kaum als Merkmal innerhalb des Informationsraumesgif dienen. 

Die Wichtigkeit eines Wortes ist zeitabhängig. So ist das Schlüsselwort "Schifahren'' im Winter weniger relevant als im Sommer. Sie ist aber auch abhängig vom Grad der Spezialisierung des Suchdienstes. Das Keyword "Medizin'' kann für einen allgemeinen Suchdienst relevant sein, für einen speziellen Suchdienst für Mediziner ist es dies nicht. Die Zeitabängigkeit läßt sich insofern berücksichtigen, als daß bei jedem Update auch die Häufigkeit neu ermittelt wird. Da der Broker in ein hierarchisches System eingebunden sein kann, und sich bei übergeordneten Brokern andere Worthäufigkeiten ergeben, muß er alle Schlüsselwörter verwalten; für sich selbst scheidet er jene aus, deren Häufigkeit einen bestimmten Schwellwert überschreiten. 

Die im gefundenen Dokument enthalten relevanten Schlüsselwörter könnten als Zusatzinformation beim Suchergebnis zu jedem Dokument ausgegeben werden (siehe Abschnitt 4.2.3). Es läßt sich aber auch die Suche entsprechend einschränken. 

Gewichtung der Suchergebnisse - Ähnlichkeit von Dokument und Suchanfrage

Boolsche Anfragesysteme haben sich vor allem bei Systemen bewährt, die einen eingeschränkten, geschulten Benutzerkreis haben. Benutzer, die ein solchens System selten verwenden, haben Schwierigkeiten mit der Syntax und Sematik der Abfragen [Har92]. Boolsche Systeme erzielen gute Ergebnisse in bezug auf Recallgif und Precisiongif, wenn die Anfrage exakt formuliert wird. 

Folgende Schwächen dieser Systeme werden in [ESM92] erläutert: 

  • Die boolschen Operatoren sind strikt. Zum Beispiel liefern Suchabfragen der Form A and B and C and D and E nur Dokumente, in denen alle Terme enthalten sind. Der Benutzer hat kaum die Möglichkeit, dieses Verhalten "aufzuweichen''gif
  • Das boolsche Modell gibt keine Auskunft über die Wichtigkeit der einzelnen gefundenen Dokumente. 
  • Das boolsche Modell bietet keine Möglichkeit, einzelne Suchterme nach ihrer Bedeutung zu bewerten. 
Das nachfolgend beschriebene Ranking-Verfahren für das Retrieval verzichten auf boolsche Operatoren und scheinen somit benutzerfreundlicher zu sein [Har92]. 

Prinzip des Rankings

Worthäufigkeiten und unterschiedliche Formatierungen innerhalb eines Dokuments geben Auskunft über die Bedeutung der einzelnen Wörter im Dokument. Ein Wert, der diese Bedeutung widerspiegelt, wird beim Ranking im Index mitgespeichert. Für jedes Dokument, das zum Suchergebnis einer Anfrage gehört, wird in weiterer Folge ein Wert errechnet, der dessen Wichtigkeit im Gesamtergebnis wiedergibt, und als ein weiteres Kriterium für die Suchergebnispräsentation dient. Dokumente, die das Suchwort im Titel oder mehrmals enthalten, werden höher bewertet als solche, in denen es nur einmal im Textbereich vorkommt.gif 

Zusätzlich zur Bedeutung eines Suchterms im Dokument wird bei den Ranking-Verfahren auch dessen Bedeutung innerhalb der Suchanfrage selbst berücksichtigt. Statt boolscher Operatoren gibt der Benutzer das relative Gewicht der einzelnen Suchbegriffe an [Har92]. 

Ein Beispiel: 
gegeben seien zwei Dokumente A und B (siehe Abbildung 4.1). Der Benutzer gibt zusätzlich zu jedem Suchterm eine Zahl an, die dessen Bedeutung in der Anfrage repräsentiert. Diese Zahlen werden einzeln mit dem Gewicht des jeweiligen Terms im Dokument multipliziert. Durch Addition dieser Produkte liefert einen Wert, der als Maß für die Wichtigkeit des Dokuments in bezug auf die Suchanfrage dient. Die Anfrage nach ((Zug,0.7) (Wagen,0.1)) ergibt so (A,0.35); (B,0.22). Das Dokument A ist somit relevanter. Verschiedene Ranking-Algorithmen werden in [Har92] beschrieben. 

figure1030
Abbildung: Zwei Dokumente: Wörter und ihre Bedeutung für das Dokument

Das bisher beschriebene Konzept läßt sich nun um die Verwendung von boolschen Operatoren erweitern. Es stellt sich die Frage, wie sich das Gewicht eines gefundenen Dokumentes aus den Gewichten der Teilterme ermitteln läßt, damit es vergleichbar wird. In [ESM92] wird unter anderem das P-Norm-Modell vorgestellt. 

Das P-Norm-Modell

Das P-Norm-Modell [SFW83] [ESM92] erlaubt es, sowohl den Wörtern im Index ein dokumentspezifisches Gewicht zu geben, als auch die einzelnen Termen in der Anfrage, abhängig von ihrer Wichtigkeit, unterschiedlich zu bewerten. Hier werden Abfragen und Dokumente als n-dimensionale Vektoren betrachtet, wobei die Dimension gleich der Anzahl der Suchterme der Anfrage ist. Die Koordinaten entsprechen dem Gewicht der Termegif. Die Koordinaten liegen im Intervall [0,1]. Ein Dokument, das durch den Punkt (0,0,...,0) repräsentiert wird, enthält keinen Suchterm. Der Punkt (1,1,...,1) steht hingegen für ein Dokument, das alle Suchterme mit dem maximalen Gewicht enthält. Somit ist es möglich, gefundene Dokumente bezüglich ihrer Distanz zu diesen beiden Punkten zu reihen. Während die boolsche Konjunktion verlangt, daß alle Terme im Dokument auftreten (Optimum (1,1,...,1)), werden Dokumente in diesem Modell um so besser bewertet, je näher sie am Optimum liegen. Das Vorkommen aller Terme ist daher nicht zwingend. Ein Dokument, das im Resultat einer disjunktiven Suchabfrage enthalten ist, ist im P-Modell dann am wichtigsten, wenn sein Abstand vom Ursprung (kein Suchwort im Dokument) am größten ist, weil mit steigendem Abstand vom Ursprung die Anzahl bzw. die Gewichtung der Wörter eines Dokuments zunimmt. 

Es seien nun A1,A2,...,An die Suchwörter und a1,a2,...,an deren, vom Benutzer vergebenen Gewichte. Durch p sei angegeben, wie genau sich der boolsche Operator auf die Berechnung des Gewichtes (siehe Gleichungen 4.6 und 4.5) auswirken soll. Der Parameter p ist ein Maß für die unterschiedliche Bewertung der beiden boolschen Operatoren () bei der Berechnung der Ähnlichkeit und liegt im Intervall (1&ldots&inf). Er wird bei der Konfiguration des Ranking-Systems festgelegt. Suchanfragen (Q) mit n-1 Konjunktionen (Qp) beziehungsweise n-1 Disjunktionen (Qp) haben in diesem Modell folgende Form: