PDF-Version

Transcrição

PDF-Version

Knowledge Discovery
Broker-Entwicklungsarbeiten für das
xFIND-Suchsystem
Untersuchung gegenwärtiger Information Retrieval- und Klassifikationssysteme
sowie Entwicklung eines Brokerprototyps
Diplomarbeit
an der
Technischen Universität Graz
vorgelegt von
Jürgen Heber
Institut für Informationsverarbeitung und Computergestützte neue Medien (IICM)
Technische Universität Graz
A-8010 Graz
Juli 2000
c Copyright 2000, Jürgen Heber
Begutachter: o.Univ.-Prof.Dr.Dr.h.c. Hermann Maurer
Betreuer: Dipl.-Ing. Christian Gütl
Kurzfassung
Das World Wide Web (WWW), als die herausragendste Anwendung des Internet, stellt
heute das größte und am schnellsten wachsende Informationssystem der Welt dar. Als
solches verlangt das WWW nach offenen Standards und Verfahren, die dem Benutzer
eine hohe Qualität der Information gewährleisten. Die rasante Zunahme der Datenmenge, sowie die Vielfalt und Unstrukturiertheit ihrer Repräsentation behindern die
zaghaft einsetzenden Standardisierungsbemühungen der Informationsbeschreibung und
-wiederauffindung.
In den derzeitigen Suchdiensten findet der Qualitätsaspekt ebensowenig Berücksichtigung wie die Netzentlastung durch lokale Informationssammlung und Informationsverteilung. Eine einmal vorverarbeitete Information sollte im Idealfall jedem interessierten Suchdienst derart zur Verfügung stehen, daß bei der Abfrage keine unnötige Serveroder Netzbelastung entsteht. Die vorliegende Studie beschreibt Forschungs- und Implementierungsarbeiten, die im Zusammenhang mit dem Suchsystem xFIND (Extended
Framework for Information Discovery) durchgeführt wurden. Das am IICM (Institut
für Informationsverarbeitung und Computergestützte Neue Medien) der Technischen
Universität Graz entwickelte System organisiert die Aufbereitung, Indizierung und Abrufbarkeit von Information in einer verteilten Architektur, welche die Vollständigkeit
und Aktualität bei geringer Server- und Netzbelastung wesentlich verbessert.
Im Untersuchungsbereich wird als erster Punkt die Indizierung behandelt, die den
Mittelpunkt jedes Suchsystems darstellt. Es erfolgt eine Betrachtung aus theoretischer
und praktischer Sicht und es wird eine Gegenüberstellung gängiger Indizierer, die innerhalb des xFIND-Suchsystems zur Anwendung gelangen können, vorgenommen. Als
zweiter Punkt der Untersuchung wird die Bedeutung von Metadaten zur qualitätvollen
Informationsbeschreibung und -suche erläutert, dabei steht der Einfluß der thematischen Klassifikation von Webressourcen im Vordergrund.
Die Ergebnisse des Untersuchungsbereiches fließen in die Entwicklung eines Brokerprototyps für das xFIND-Suchsystem ein. Ein xFIND-Broker, der als Vermittler zwischen anfragenden Benutzern und Informationsanbietern fungiert, hat genaue Kenntnis
über das Informationsangebot einzelner Anbieter (z.B. über die behandelten Themengebiete). Dadurch kann eine selektive thematische Verteilung der einlangenden Suchanfragen erfolgen, die in Verbindung mit der Auswertung weiterer inhaltsbeschreibender
und -beurteilender Metadaten entscheidend zur Erhöhung der Qualität von Suchergebnissen beiträgt. Die zugrundeliegenden Konzepte, die Architektur und Funktionsweise,
sowie eine Reihe von Vorschlägen zur Weiterentwicklung des Broker werden im Gestaltungsbereich dieser Arbeit beschrieben.
Abstract
Today the World Wide Web (WWW), as the most popular internet application, represents the world’s largest and fastest growing information system. Therefore it demands
some sort of open standards and methods, which are able to grant a high degree of
information quality. Rapid growth of data as well as great variety and lack of structure
are main characteristics of the WWW, which hamper upcoming standardization effords
of information description and retrieval.
Present searchservices don’t consider aspects of quality very well and there are no
proposals about local gathering and distribution of information, which would help to
minimize data traffic. Information gathered and preprocessed in one place should be
available to searchservices in such a manner that any access to this information has only
little impact on server- and net-load. This thesis describes research and implementation work concerning the searchsystem xFIND (Extended Framework for Information
Discovery). The xFIND-System, which is in process of development at IICM (Institute
for Information Processing and Computer Supported New Media) at Graz University
of Technology, organizes information gathering, indexing and access in a distributed
architecture. As an outcome it provides completeness and topicality of information,
whilst decreasing server- and net-load.
The first part of this study treats with indexing as the most important feature of
any searchsystem. It will be analysed by a theoretical and practical point of view and
by a comparison of present day information retrieval systems, which can be used in
xFIND. In the second part of this study the role of metadata in high-quality information description and retrieval will be explained, with special emphasis on thematical
classification of web resources.
The results of this study will be used in the development of a broker prototype
which fits into the xFIND searchsystem. A xFIND broker works between users and
information providers, it has a detailed knowledge about any offered information (e.g.
about topics). By that means a broker performs a thematically distribution of searchqueries, which in conjunction with an evaluation of additional metadata - used for
content description and rating - leads to a higher degree of quality in searchresults.
Inherent concepts, architecture and mode of operation of this knowledge broker will be
discussed in the practical part of this thesis.
Ich versichere hiermit, diese Arbeit selbständig verfaßt, andere als die angegebenen
Quellen und Hilfsmittel nicht benutzt und mich auch sonst keiner unerlaubten Hilfsmittel bedient zu haben.
Inhaltsverzeichnis
1 Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Strukturierung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
5
I
7
Untersuchungsbereich
2 Das xFIND-Suchsystem
2.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
8
13
3 Information Retrieval Systeme
3.1 Motivation . . . . . . . . . . . . . . .
3.2 Architektur und Funktionsweise von
IR Systemen . . . . . . . . . . . . . .
3.2.1 Modell . . . . . . . . . . . . .
3.2.2 Filestruktur . . . . . . . . . .
3.2.3 Funktionalität . . . . . . . . .
3.2.4 Bewertung . . . . . . . . . . .
3.3 Analyse gegenwärtiger IR Systeme .
3.3.1 Anforderungen . . . . . . . .
3.3.2 Informale Gegenüberstellung .
3.3.3 Reviews . . . . . . . . . . . .
3.3.4 Performance . . . . . . . . . .
3.3.5 Search Development Kits . . .
3.4 Zusammenfassung . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
14
15
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
17
18
25
30
31
32
36
37
42
47
54
4 Klassifikation von Webressourcen
4.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Metadaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
56
56
56
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.3
4.4
II
4.2.2 Anwendung im WWW . . . . . . . .
4.2.3 Schemata . . . . . . . . . . . . . . .
4.2.4 Kritische Bemerkungen . . . . . . . .
4.2.5 xFIND Quality Metadata Scheme . .
Klassifikationssysteme . . . . . . . . . . . .
4.3.1 Grundlagen . . . . . . . . . . . . . .
4.3.2 Selbstentwickelte Themenhierarchien
4.3.3 Fachspezifische Klassifikationen . . .
4.3.4 Universalklassifikationen . . . . . . .
4.3.5 xFIND und Klassifikation . . . . . .
Zusammenfassung . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Gestaltungsbereich
5 Brokertheorie
5.1 Motivation der Metasuche . . . . . . . . .
5.2 Grundlagen der Metasuche . . . . . . . . .
5.2.1 Client-basierende Metasuchdienste
5.2.2 Server-basierende Metasuchdienste
5.3 WWW Metasuchdienste vs. xFIND-Broker
5.3.1 Formulierung der Suchanfrage . . .
5.3.2 Ablauf der Suche . . . . . . . . . .
5.3.3 Anzeige der Suchergebnisse . . . .
5.3.4 Integration in den xFIND-Broker .
59
60
61
62
64
64
64
67
70
82
83
84
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Brokerarchitektur
6.1 Inbetriebnahme des xFIND-Broker . . . . . . . . . . . . . .
6.1.1 Brokersource . . . . . . . . . . . . . . . . . . . . . .
6.1.2 Brokerkonfiguration . . . . . . . . . . . . . . . . . . .
6.1.3 Start des Broker . . . . . . . . . . . . . . . . . . . .
6.2 Klassenstruktur des xFIND-Broker . . . . . . . . . . . . . .
6.2.1 Serverklasse XFBroker . . . . . . . . . . . . . . . . .
6.2.2 Kommunikationsklasse XFBrokerSearchQueryComm
6.2.3 Kernklasse XFBrokerTask . . . . . . . . . . . . . . .
6.2.4 Steuerklasse XFBrokerRequest . . . . . . . . . . . . .
6.2.5 Anfrageklasse XFIndexerQuery . . . . . . . . . . . .
6.2.6 Ergebnisklasse XFIndexerResult . . . . . . . . . . . .
6.2.7 Informationsklasse XFIndexerInfo . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
85
86
88
88
88
89
89
93
94
95
.
.
.
.
.
.
.
.
.
.
.
.
98
99
99
100
101
101
101
103
104
107
108
109
110
6.3
6.2.8 Produktionsklasse XFMergeFactory . . . . . . . . . . . . . . . . 111
6.2.9 Speicherklasse XFBrokerCache . . . . . . . . . . . . . . . . . . 112
xFIND-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7 Ausblick
119
8 Zusammenfassung
121
III
Anhang
A Suchhilfen im WWW
A.1 Volltextsuchdienste
A.2 Katalogdienste . .
A.3 Metasuchdienste . .
A.4 Sonstige Suchhilfen
123
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
B Metadaten- und Klassifikationsschemata
B.1 Dublin Core Metadata Element Set, V1.1
B.2 Dublin Core Metadata Template . . . . .
B.3 xFIND Quality Metadata Scheme, V1.0 .
B.4 Haupt- und Unterklassen von DDC . . .
B.5 Haupt- und Unterklassen von UDC . . .
B.6 Hauptklassen von LCC . . . . . . . . . .
B.7 Hauptklassen von BLISS . . . . . . . . .
B.8 Haupt- und Unterklassen von ACM CCS
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
124
124
126
126
127
.
.
.
.
.
.
.
.
128
128
129
130
131
132
133
134
134
C CD ROM
136
Abbildungsverzeichnis
138
Tabellenverzeichnis
139
Listingsverzeichnis
140
Literaturverzeichnis
141
Kapitel 1
Einleitung
1.1
Motivation
Das World Wide Web (WWW) hat sich in den letzten Jahren zum weltweit größten
Informationssystem entwickelt. Zum Jahresbeginn 2000 übersteigt die geschätzte Anzahl an Dokumenten im WWW bereits eine Milliarde [Ink2000] und für die Zukunft
wird weiterhin ein starkes Wachstum der Informationsmenge prognostiziert. Die Ursachen dieser bemerkenswerten Entwicklung liegen im rasanten technischen Fortschritt
von Telekommunikation und Informatik, in der zunehmenden Akzeptanz dieses neuen Mediums und der Realisierung der vielfältigen Möglichkeiten, die sich im Umgang
mit dem WWW eröffnen. Ein Umstand, der ebenfalls zum raschen Anwachsen der Informationsmenge beiträgt, ist die Tatsache, daß zum heutigen Zeitpunkt etwa 90 %
aller Wissenschaftler tätig sind, die jemals auf unserer Erde gelebt haben. Das Wissen
der gesamten Menschheit verdoppelt sich in einem immer kürzer werdenden Zeitraum,
derzeit geschieht dies innerhalb von 20 Jahren. [Gütl99a]
Um in einem Informationssystem dieser Größenordnung gezielt suchen zu können,
bedarf es einer Reihe von Maßnahmen und Werkzeugen, die in der vorliegenden Arbeit analysiert und diskutiert werden sollen. Aus der Sicht des Anwenders, der das
Internet zur Suche nach Information zu einem konkreten Thema nutzen möchte, stellt
sich zunächst die Frage nach einem geeigneten Ausgangspunkt seiner Recherchen. Hier
bieten sich zum gegebenen Zeitpunkt zwei grundsätzliche Typen von Suchdiensten an,
die Volltextsuchdienste und die Katalogdienste. [Bag99]
Volltextsuchdienste
Sie bestehen aus Datensammlern, einem Indizierer und einem Abfrageprogramm. Die
Datensammler, auch Robots oder Spiders genannt, fordern Webseiten von den Informationsservern an und bereiten die darin enthaltenen Informationen für die anschließende Indizierung auf. Die gesammelten Daten werden in einem oder mehreren Indizes
vermerkt, wobei sich die genaue Vorgehensweise bei der Indizierung, vorallem aber
bei der Bestimmung von Ranking-Werten, von Suchdienst zu Suchdienst beträchtlich
unterscheiden kann. Das Ranking bestimmt die Position eines einzelnen Suchergebnisses innerhalb aller erzielten Suchergebnisse, d.h. es ist ein Indikator für die Relevanz
1
KAPITEL 1. EINLEITUNG
2
eines Suchergebnisses. Ein Ranking-Wert kann aus einer Vielzahl von auswertbaren
Dokumenteigenschaften ermittelt werden. Traditionelle Beispiele dafür sind Positionen
von Wörtern im Text, Worthäufigkeiten oder Metainformationen, in der letzten Zeit
finden aber auch komplexere Relevanzmaße zunehmend Verwendung. Die Anzahl externer Links (d.h. wieviele andere Dokumente zeigen auf ein bestimmtes Dokument)
und Relevanz-Links (d.h. Verweise von wichtigeren Sites zählen mehr) bestimmen das
Ranking ebenso mit wie das Benutzerverhalten (z.B. die Verweildauer auf der Ergebnisliste oder die Häufigkeit der Auswahl einzelner Links). Abhängig von den eingegebenen
Suchwörtern erhält man von den Volltextsuchdiensten in der Regel eine große Anzahl
von Ergebnissen unterschiedlichster Relevanz. Zur Einschränkung der Suche stehen eine
Reihe von Optionen zur Verfügung, die Palette erstreckt sich von einfachen Textsuchen
bis hin zur Auffindung von speziellen Multimediaobjekten. Eine Gegenüberstellung der
beliebtesten Volltextsuchdienste im WWW ist in Anhang A.1 zu finden. [Bag99]
Katalogdienste
Im einfachsten Fall erfolgt die Aufnahme einer Webseite in den zumeist thematisch
gegliederten Katalog direkt, d.h. aufgrund der Beschreibung, die z.B. der Autor bei
der Anmeldung der Webseite abgibt. Es wird keine manuelle Prüfung der Qualität
oder der korrekten Einordnung in die Hierarchie des Kataloges vorgenommen. Im Idealfall werden die Webseiten allerdings von Redakteuren des Dienstes begutachtet, unter
Umständen bewertet, mit einer Kurzbeschreibung versehen und korrekt in den Themenkatalog eingeordnet. Dieser aufwendige Vorgang stellt sicher, daß nur relevante
Informationen in den Katalog aufgenommen werden, gleichzeitig kann jedoch nur ein
kleiner Teil des WWW erfaßt werden. Redaktionell betreute Katalogdienste liefern i.a.
qualitativ bessere Ergebnisse als Volltextsuchdienste, für sehr spezielle Suchen kann es
aber durchaus vorkommen, daß keine Einträge vorhanden sind. Neue Ansätze, wie das
Open Directory Project1 , versuchen dem entgegenzuwirken, indem sie eine sehr große
Anzahl von freiwilligen Redakteuren mit der Betreuung kleiner Fachbereiche beauftragen. Dennoch bleibt die Einschränkung dieser Art der Aufbereitung, daß hier lediglich
die redaktionell erfaßten Kurzbeschreibungen, nicht aber die eigentlichen Inhalte der
katalogisierten Webseiten, durchsucht werden können. Eine Auswahl von Katalogdiensten enthält Anhang A.2. [Bag99]
Jede Art von Suchdienst bietet für bestimmte Suchprobleme seine Vorzüge, Volltextsuchdienste zur Recherche in spezielleren Gebieten, Katalogdienste für die systematische Suche zu allgemeineren Themen. Daher ist es kaum verwunderlich, daß neue
Suchdienste dazu übergehen, beide Dienste miteinander zu verknüpfen. Werden für eine
Suchanfrage im Katalog keine Suchergebnisse gefunden, so erfolgt eine Weiterleitung an
einen Volltextsuchdienst, umgekehrt bieten Volltextsuchdienste in zunehmenden Maße auch Kataloge an. Derartige Kooperationen finden sich z.B. zwischen Web.de2 und
1
2
http://dmoz.org/
http://web.de/
3
AltaVista.de3 oder im Netscape Netcenter4 mit Google5 und Auszügen aus dem Open
Directory.
Zur Suche in sehr eingeschränkten Themenbereichen, die im WWW nur wenig behandelt werden, eignen sich natürlich auch Metasuchdienste. Diese leiten die Suchanfragen an mehrere Volltextsuchdienste und Kataloge weiter, nehmen deren Suchergebnisse
entgegen und erstellen eine Zusammenfassung. Bei Anfragen zu allgemeineren Themen
erhält man naturgemäß sehr viele Ergebnisse, ein Problem, daß durch die meist bescheiden ausgeführten Möglichkeiten zur Einschränkungen der Suche noch weiter verstärkt
wird. Beispiele für Metasuchdienste sind in Anhang A.3 aufgelistet. [Bag99]
Was die Vollständigkeit und Aktualität der Suchdienste betrifft, so zeigt sich, daß die
ständig wachsenden Indizes nicht mehr mit dem Wachstum des WWW schritthalten
können. Ein immer geringerer Teil des WWW findet Aufnahme in die Suchdienste,
wurden im Dezember 1997 noch 60 % von rund 320 Mio. Webseiten indiziert, so waren
es im Februar 1999 nur mehr 42 % von 800 Mio. Webseiten. Die Suchdienste sind
mit der Größenordnung des WWW zunehmend überfordert, das zeigt sich auch daran,
daß die Betreiber von Websites gezwungen sind, sich laufend bei den Suchdiensten in
Erinnerung zu bringen. Andernfalls werden von den Suchdiensten einzelne Webseiten
übersehen, bereits indizierte Webseiten fallen aus dem Index heraus oder die Aufnahme
neuer Webseiten erfolgt erst nach Wochen, Monaten oder überhaupt nicht. [Bag99]
An der mangelnden Vollständigkeit ändert die Tatsache, daß laufend neue Suchdienste ihren Betrieb aufnehmen, nur wenig. Dies führt vielmehr dazu, daß eine immer
größere Anzahl von Suchdiensten versucht, ihre Indizes zu erweitern und aktuell zu
halten. Die Suchdienste senden unabhängig voneinander eine Hundertschaft von Datensammlern aus und verursachen damit eine hohe Server- und Netzbelastung. [Gütl99a]
Neben den geschilderten quantitativen Aspekten sehen sich Suchdienste zunehmend
mit qualitativen Herausforderungen konfrontiert. Das Internet ist nicht einfach nur Hypertext, es besteht aus einer Vielfalt von Multimediaobjekten, wie z.B. Wetterkarten,
Grafiken, Audiodaten oder Videosequenzen. Die Indizierung bzw. Katalogisierung von
Internetobjekten stellt sich aufgrunddessen als ein außerordentlich schwieriges Unterfangen heraus. Konventionen zur Beschreibung von Internetobjekten sind noch nicht
sehr gut entwickelt, weil die Objekte selbst in einer unkontrollierten und unkonventionellen Weise erzeugt und veröffentlicht werden. Die Herausforderung bei der Katalogisierung sind die laufend auftretenden Veränderungen an den Objekten und in
ihrem Umfeld. Hervorzuheben sind hier vorallem inhaltliche, strukturelle und örtliche
Modifikationen, sowie Änderungen der Urheberschaft und der Zuständigkeit für diese
Objekte. [Bru93]
Eine Möglichkeit zur Berücksichtigung wichtiger Merkmale eines Objektes sind Metadaten, die mit dem Objekt in Beziehung stehen. Angesichts der überhandnehmenden
Datenmenge im WWW zeigt sich sehr deutlich, wie notwendig Metadaten zur Beschreibung und Auffindung von Internetobjekten benötigt werden. Die Benutzer sind nicht
3
http://www.altavista.de/
http://my.netscape.com/
5
http://www.google.com/
4
4
mehr in der Lage, die gewünschte Information in ansprechender Zeit zu finden. Die
durchschnittliche Erfolgsrate der Suche im WWW beträgt gemäß einer vierteljährlich
durchgeführten Studie der NPD New Media Services6 lediglich 77 % und zeigt eine
absteigende Tendenz (siehe Abbildung 1.1).
Abbildung 1.1: Durchschnittliche Erfolgsrate der Suche im WWW
Sm = Summer; F = Fall; W = Winter; Sp = Spring
(Quelle: http://www.searchenginewatch.com/reports/npd.html)
Würden alle Objekte durch dieselben Felder mit demselben kontrollierten Vokabular
beschrieben werden, dann sollten sich bessere Suchergebnisse einstellen. Der Prozeß der
Einführung von Metadaten ist jedoch ein relativ langwieriger im schnellebigen Medium
Internet, in dem Zeit einen äußerst limitierenden Faktor darstellt. [MF99]
Internetobjekte weisen viele Parallelen zu traditionell herausgegebenen Werken
(Bücher, Zeitschriften, etc.) auf, daher erscheint eine Orientierung am Bibliothekswesen
vorteilhaft. Neben den allgemeinen Merkmalen wie Titel, Verfasser oder Herausgeber,
erleichtert eine thematische Beschreibung - im folgenden als Klassifikation bezeichnet die systematische Auffindung von Internetobjekten. Darüberhinaus ermöglicht die Aufnahme von Klassifikationsinformation in die Metadaten eine bibliothekarische Organisation und einen einheitlichen Zugriff auf traditionelle und elektronische Bibliotheken.
[VGU96]
Über eine lange Zeitspanne wurde von Bibliothekaren die thematische Beschlagwortung, d.h. die Zuordnung von Themen aus einem kontrollierten Vokabular, der
Verwendung von traditionellen Klassifikationssystemen, die Dokumente in Themenhierarchien einordnen, vorgezogen. Selbst diese thematische Beschlagwortung wurde
in den Anfängen des WWW durch die Erfolge der automatischen Volltextindizierung
in Frage gestellt. Die stark anwachsenden Datenmengen zeigten allerdings sehr bald
die Grenzen und Probleme einer vollständigen, aber flachen Textindizierung auf, die
Benutzer derartiger Systeme sahen sich mit großen Mengen an irrelevanter Information konfrontiert. Eine Verbesserung der Situation versprachen Ansätze, die neben der
6
http://www.npd.com/
5
Suche im Volltextindex auch ein Browsing in einer hierarchischen Themenstruktur erlaubten. Der wichtigste Vertreter dieser Ideologie ist Yahoo7 , dessen selbstentwickelte
Themenhierarchie wohl jedem Internetbenutzer ein Begriff ist und die großen Anteil
am Erfolgszug des WWW hatte. Es wurde rasch erkannt, daß die Klassifikation und
die Wiederauffindung von Ressourcen auf Basis von hierarchischen Themenkatalogen
eine äußerst positive Auswirkung auf die Qualität der Suchergebnisse hat. [Koc97]
Ein wichtiger Schritt zur weiteren Verbesserung der Suche im WWW sind Bemühungen, die Relevanz der Dokumente meßbar zu machen. Der Einsatz von fortgeschrittenen
Information Retrieval Techniken, z.B. Ranking der Suchergebnisse, stellt jedoch keine
ausreichende Lösung dar. Zumeist fehlt jeglicher Hinweis auf die Qualität der Ergebnisse, wodurch der Benutzer gezwungen ist, sich die einzelnen Ressourcen in mühsamer
Kleinarbeit durchzusehen und nach Möglichkeit selbst zu beurteilen [TSV97]. In diesem
Umfeld können bewertende Metadaten, die von dem Verfasser des jeweiligen Dokumentes bereitgestellt und von fachspezifischen Gutachtern geprüft und beurteilt werden,
einen wichtigen Beitrag zu einer effizienten Auffindung von qualitätsvoller Information
leisten.
1.2
Strukturierung der Arbeit
Ausgehend von den geschilderten Schwierigkeiten der aktuellen Suchdienste wird in
Kapitel 2 das Suchsystem xFIND vorgestellt. Die verteilte Architektur und die darin
zur Anwendung gelangenden Mechanismen bewirken eine drastische Verminderung
der Netz- und Serverbelastung und verbessern die Vollständigkeit und Aktualität der
Suchergebnisse wesentlich.
Die zentrale Komponente des xFIND-Suchsystems bildet der Indexer (siehe Abschnitt 2.1), dessen Aufgabe in der Verwaltung, Verknüpfung und Bereitstellung der gesammelten Dokumentdaten besteht. Zur Erfüllung dieser Aufgabe kann sich ein xFINDIndexer verschiedenster Information Retrieval (IR) Systeme bedienen. Kapitel 3 setzt
sich daher mit den Eigenschaften von IR Systemen auseinander und untersucht eine
Reihe gängiger IR Softwarepakete auf ihre Einsetzbarkeit im xFIND-Suchsystem. Der
Leistungsumfang wird verglichen und die Praxistauglichkeit wird durch Performancemessungen im Bereich der Indizierung und Suche bestimmt. Als mächtige Alternative
zu den vorgestellten Softwarepaketen werden einige Search Development Kits behandelt, mit deren Hilfe sich projektspezifische Erweiterungen, wie sie sich im Verlauf der
Forschungsarbeit zum xFIND-Suchsystem ergeben, effizient durchführen lassen.
Der Übergang von der technischen zur qualitativen Sichtweise auf das xFINDSuchsystem erfolgt in Kapitel 4 dieser Arbeit. Wie bereits in Abschnitt 1.1 erwähnt,
gilt es Mittel und Wege zu finden, selbst bei einer stark anwachsenden Dokumentenmenge im WWW für den Benutzer ein hohes Maß an Qualität der Information sicherzustellen. In Kapitel 4 werden daher Metadaten zur Beschreibung von Webinhalten
und ihr Einfluß auf die Indizierung und Wiederauffindung von Information betrachtet.
7
http://www.yahoo.com/
6
Den Schwerpunkt innerhalb der Metadaten bilden thematische Klassifikationen, die
Themengebiete in - selbstdefinierten bis hin zu wissenschaftlich optimierten - hierarchischen Strukturen organisieren. Die Vor- und Nachteile einer thematischen Ordnung
von Webressourcen werden erläutert und sind Grundlage für die Auswahl konkreter
Klassifikationen für das inhaltsbeschreibende und -bewertende xFIND Quality Metadata Scheme (xQMS).
Am Beginn des Gestaltungsbereiches wird in Kapitel 5 das Konzept der Metasuche vorgestellt. Resultate dieser Recherche fließen ebenso in die Entwicklung eines
Brokerprototyps für das xFIND-Suchsystem mit ein wie die Erkenntnisse aus dem
Untersuchungsbereich. Die Funktionsweise und die Architektur des Broker wird in Kapitel 6 anhand der Klassenstruktur erklärt, die in der plattformunabhängigen Programmiersprache JAVA implementiert wurde. Wünschenswerte Erweiterungen und mögliche
Verbesserungen des Brokerprototyps werden im Ausblick in Kapitel 7 aufgezählt, eine
Zusammenfassung in Kapitel 8 rundet letztlich diese Arbeit ab.
Teil I
Untersuchungsbereich
7
Kapitel 2
Das xFIND-Suchsystem
Der praktische Teil dieser Diplomarbeit hat die Entwicklung eines Brokerprototyps
für das xFIND-Suchsystem1 zur Aufgabe. Aus diesem Grund soll in diesem Kapitel
ein kurze Vorstellung dieses neuen, für die Auffindung von qualitätvoller Information
dringend benötigten, Suchsystems erfolgen. Das Extended Framework for Information
Discovery wird zum Zeitpunkt des Verfassens dieser Arbeit am IICM (Institut für
Informationsverarbeitung und Computergestützte Neue Medien) an der Technischen
Universität Graz entwickelt.
Die großen Informationsmengen und ihre Unstrukturiertheit bereiten den Anbietern
von WWW-Suchdiensten beträchtliche Schwierigkeiten. Die bedeutendste Anforderung
der Benutzer ist eine möglichst hohe Zuverlässigkeit der Suchergebnisse. Dies betrifft
vorallem die Aspekte Relevanz und Aktualität, beide können nur sehr eingeschränkt
von den Suchdiensten erfüllt werden. Die Einführung neuer Ansätze, wie sie im xFINDSuchsystem vorgesehen sind, soll hier eine wesentliche Verbesserung der Situation zur
Folge haben. [GMP99]
2.1
Architektur
Das grundlegende Design von xFIND orientiert sich an Aspekten, die im allgemeinen jedes Knowledge Management System zu erfüllen hat, es sind dies die folgenden
Punkte [GMP99]:
• Das Wissen muß sichtbar gemacht werden, man muß wissen wo relevante Informationen zu beziehen sind und wer etwas weiß.
• Es ist eine Wissensinfrastruktur aufzubauen, i.a. handelt es sich dabei um eine
Organisationseinheit, die den Zugriff auf interne und externe Informationsquellen
ermöglicht.
• Der gewählte Ansatz zur Wissensverarbeitung deckt die notwendigen Bearbeitungsund Kommunikationsprozesse ab.
1
http://xfind.iicm.edu/
8
KAPITEL 2. DAS XFIND-SUCHSYSTEM
9
• Schließlich ist eine Wissenskultur zu etablieren, die einen zuverläßigen und vertrauenswürdigen Informationsaustausch gewährleistet.
Die Implementierung erfolgt mit Hilfe der plattformunabhängigen Programmiersprache Java. Um eine möglichst hohe Flexibilität und Skalierbarkeit zu erreichen, wurde
eine verteilte Architektur, die sich bereits im Harvest-Suchsystem als sehr vorteilhaft
erwiesen hat, gewählt und weiterentwickelt. Ein konkretes xFIND-System wird demnach aus den nachfolgend beschriebenen Modulen aufgebaut [GMP99]:
Gatherer
Die Zielvorstellung eines Suchsystems ist es, entsprechend der gestellten Suchanfrage
die geeignetsten Informationen aus dem zugrundeliegenden Datenbestand herauszufiltern und dem Benutzer zu präsentieren. Da sich der Datenbestand aus sehr unterschiedlichen Objekten (z.B. Text- oder Bilddokumente in vielfältigen Datenformaten)
zusammensetzen kann, erweist sich eine Vorverarbeitung der Daten für die nachfolgenden Bearbeitungsschritte der Indizierung und Suche als nutzbringend.
Das Gatherer-Modul erledigt diese Vorverarbeitung, es ist für die Beschaffung und
Aufbereitung der Daten zuständig. Wie die Aufbereitung im Detail erfolgen soll, kann
individuell konfiguriert werden, so können beispielsweise Titel, Schlüsselwörter, Hyperlinks, eingebettete Multimediaobjekte usw. aus den untersuchten Dokumenten extrahiert und zu Beschreibungsobjekten zusammengefaßt werden. Darüberhinaus wird für
jedes Dokument ein elektronischer Fingerabdruck erstellt, der zur Verwaltung oder zur
Identifikation verwendet werden kann. Besondere Beachtung finden im Dokument enthaltene Metadaten, die auf unterschiedlichen Metadatenschemata, wie DC, LOM2 oder
xQMS3 , basieren können. Diese Metadaten werden ebenfalls extrahiert und spielen eine
wichtige Rolle bei der Erzielung qualitativ hochwertiger Suchresultate. Da die Erfassung von Metadaten durch den Autor erfolgt, sind in xFIND eine Reihe von Werkzeugen
zur Unterstützung und Sicherstellung der Konsistenz vorgesehen.
Ein Gatherer kann entweder direkt am Informationsserver betrieben werden und auf
das lokale Dateisystem zugreifen, oder er wird an einem beliebigen Ort gestartet und
fordert die aufzubereitenden Daten via HTTP oder über ein anderes Transferprotokoll
an. Die erstere Variante hat den großen Vorteil einer minimalen Server- und Netzbelastung. Ein lokaler Gatherer kann weiters selbst festgelegte Beschreibungsobjekte zur
Verfügung stellen und auf diese Weise lesegeschützte Bereiche suchbar machen.
Die aufbereiteten Daten stehen zur Abholung durch übergeordnete Services bereit,
weiters bietet ein aktiver Mechanismus die Möglichkeit, nachgelagerte Module über
Änderungen oder Neuigkeiten umgehend zu informieren. Externe Systeme (Ratingdienste, Kommentarsysteme, Benachrichtigungsdienste etc.) können in einer ähnlichen
Art und Weise in das xFIND-System eingebunden werden.
2
3
Dublin Core und Learning Object Metadata (siehe Abschnitt 4.2.3)
xFIND Quality Metadata Scheme (siehe Abschnitt 4.2.5)
10
Indexer
Er holt oder erhält die vorverarbeiteten Daten von einem oder mehreren Gatherern
in komprimierter Form und registriert sie in den von ihm verwalteten Indizes. Dabei
kann ein Indexer auf bestimmte Themenbereiche spezialisiert oder auch einer Projektgruppe, Abteilung etc. zugeordnet sein. Die Hauptaufgabe eines Indexer besteht in der
Verwaltung von Datentabellen, dem lokalen Cachen der Information und in der Beantwortung von Suchanfragen. Beim Aufbau seiner ”Datenbank” werden unter anderem
für die Suche sehr nützliche Zusatzinformationen gewonnen, Beispiele dafür sind die
Anzahl neuer Dokumente in einem bestimmten Webbereich oder exakte Worthäufigkeiten in Dokumenten. Ein Indexer kann auch mit externen Systemen kommunizieren, die
zusätzliche Informationen, wie z.B. die Bewertung von Dokumenten, in den Suchprozeß
einbringen können. Am Indexer verwaltete Information kann vollständig oder teilweise
an andere Indexer weitergegeben werden, um durch eine redundante Datenhaltung eine
Ausfallssicherheit und eine verteilte Belastung des Systems zu erzielen.
Broker
Dieses Modul repräsentiert die Kontaktstelle für den Benutzer. Wie schon beschrieben, erhält der Indexer die Daten von einem oder mehreren Gatherern, dies bedeutet, daß er im Normalfall lediglich einen mehr oder minder großen Teil des gesamten
verfügbaren Wissens verwaltet. Jeder Broker kennt eine Reihe von Indexern und weiß
auch, welche Wissensbereiche jeder einzelne von ihnen abdeckt. Die Aufgabe des Broker besteht darin, die an ihn gestellten Suchanfragen (abhängig von dem darin formulierten Problem) auf die passenden Indexer zu verteilen. Neben den xFIND-Indexern
können natürlich auch externe Quellen, die über das xFIND-API oder einen zwischengeschalteten xFIND-Wrapper ansprechbar sind, abgefragt werden. Die von den Indexern
zurückgelieferten Resultate werden vom Broker zusammengefaßt und an den anfragenden Client geschickt. Dieses grundlegende Konzept eines Broker kann natürlich
nach Belieben erweitert werden, so sind in xFIND die Einbeziehung von Bewertungsinformationen und Benachrichtigungsmechanismen vorgesehen. Weiters sind statistische
Auswertungen von Suchanfragen und -suchergebnissen, sowie deren Zusammenführung
mit Benutzerbewertungen zur Verbesserung zukünftiger Anfragen genauso denkbar wie
die Anpassung einzelner Broker auf die aktuellen Problemstellungen individueller Benutzer. Im Gestaltungsbereich dieser Diplomarbeit werden diesbezüglich weitere Überlegungen angestellt.
11
Diskussion der verteilten Lösung von xFIND
Die Vorteile eines aus den vorne angeführten Modulen aufgebauten Suchsystems treten besonders im direkten Vergleich mit derzeitigen Suchsystemen zutage. Der überwiegende Teil aller heute betriebenen Suchdienste arbeitet auf der Basis eines Index,
der an einer zentralen Stelle geführt wird. Um einen umfangreichen Index erstellen zu
können, beschäftigen diese Dienste sogenannte Robots und Spiders, die in regelmäßigen Zeitabständen Websites ”besuchen” und nach der aufzunehmenden Information
durchkämmen. Hierbei ist jedoch zu beachten, daß diese Programme die Informationsserver nicht tatsächlich ”besuchen”, sondern vielmehr die Dokumente über das Internet anfordern und zentral analysieren. Die Folge sind eine unnötig hohe Serverund Netzbelastung, zumal die Anzahl der Dokumente und Suchdienste stark ansteigt
und die Suchdienste unabhängig voneinander dieselben Dokumente mehrfach anfordern. [Leg99]
Abbildung 2.1 verdeutlicht den wachsenden Datenverkehr anhand einiger bekannter
Suchdienste und ihrer zugehörigen Datensammler.
Abbildung 2.1: Gathering zentraler Suchdienste mit Hilfe von Robots
und Spiders
Im Unterschied zum obigen Ansatz werden im xFIND-Suchsystem nicht ganze Dokumente, sondern die von Gatherern erstellten Beschreibungsobjekte versandt, zudem
entfällt bei lokal betriebenen Gatherern die Serverbelastung. Ein xFIND-Indexer muß
zwar ebenfalls in regelmäßigen Abständen die Gatherer besuchen, dabei werden allerdings nur jene Beschreibungsobjekte angefordert, die seit dem letzten Besuch hinzugekommen sind oder sich verändert haben. Insgesamt ergibt sich also eine deutlich
geringere Netzlast, die durch eine Komprimierung der Beschreibungsobjekte noch weiter reduziert werden kann. [Leg99]
12
Neben den genannten Vorzügen gestattet es der verteilte Ansatz von xFIND, Suchsysteme entsprechend ihres Verwendungszweckes beliebig komplex zu gestalten. Das
Anwendungsspektrum reicht von einem sehr einfachen Suchsystem bestehend aus einem
lokalen Gatherer (auf einem Informationsserver), einem Indexer und keinem Broker, bis
hin zu einem weit verzweigten Netz aus thematisch oder geographisch organisierten Indizierern und Brokern.
Eine Beispielarchitektur, die u.a. auch die Einbindung einer externen Quelle auf Brokerebene beinhaltet, zeigt Abbildung 2.2.
Abbildung 2.2: Beispielarchitektur eines xFIND-Suchsystems
In der Abbildung ist bereits die zentrale Rolle der Indexer ersichtlich, sie liegen in
der xFIND-Architektur auf derselben Ebene wie externe Suchsysteme. Abgesehen von
den xFIND-spezifischen Funktionen hat ein Indexer grundsätzlich dieselben Aufgaben
zu erledigen wie jedes andere Suchsystem auch, nämlich das Indizieren und Bereitstellen von Dokumentdaten. Zur Erfüllung dieser Aufgaben stehen eine Reihe von frei
verfügbaren und kommerziellen Softwarepaketen bereit, die als eigenständige Module
im Rahmen eines xFIND-Indexers zur Anwendung gelangen können.
Das modulare Konzept wird somit auch auf Indexerebene fortgesetzt, wodurch die
Anpassung und Erweiterung eines bereits bestehenden xFIND-Systems auf neue Erfordernisse einfach zu bewerkstelligen ist. So sind in einer zukünftigen Entwicklungsstufe
des xFIND-Prototyps beispielsweise Indexer eingeplant, die sich auf die Verwaltung
von Multimediainhalten spezialisieren werden. Die dafür notwendigen Softwaremodule
können selbst entwickelt oder von externen Anbietern lizensiert und in die Indexerarchitektur eingebunden werden.
2.2
13
Zusammenfassung
Die Betrachtung der Informationsbeschaffung im Internet führt auf zwei vordringliche
Problemkreise. Einerseits sehen sich die Suchdienste mit dem starken Anwachsen der
Informationsmenge und der fehlenden Struktur von Dokumentendaten konfrontiert,
wodurch ihre Bemühungen um Aktualität und Relevanz der Suchergebnisse immer
aussichtsloser werden. Andererseits nimmt die Zahl der zentral geführten Suchdienste
und mit ihnen die Server- und Netzbelastung laufend zu, ohne dadurch nennenswerte
Verbesserungen der Suchergebnisse zu erzielen.
Das vorgestellte xFIND-Suchsystem adressiert die genannten Probleme durch eine
konsequent modular aufgebaute, verteilte Architektur von Informationssammlern (Gatherer), -verwaltern (Indexer) und -vermittlern (Broker). Lokale Informationsvorverarbeitung, Datenkompression, sowie selektive Abholung oder Zustellung von aktuellen
Daten gewährleisten die Aktualität der Information bei minimaler Server- und Netzbelastung. Durch die Berücksichtigung dokumentbeschreibender Informationen (Metadaten), u.a. auch aus externen Quellen, wird dem Aspekt der Relevanz besondere
Beachtung beigemessen. Die verteilte Architektur bietet den Vorteil der Skalierbarkeit,
die xFIND in die Lage versetzt, sich den gestellten thematischen, geographischen oder
beliebig anders gruppierten Anforderungen einer Suchanwendung anzupassen und mit
ihnen zu wachsen.
Das wichtigste Modul der xFIND-Architektur ist der Indexer, aus diesem Grund
befaßt sich das nächste Kapitel mit der zugrundeliegenden Theorie der Indizierung und
Suche. Weiters werden einige gängige Information Retrieval Systeme analysiert, die als
Subsystem eines xFIND-Indexers eingesetzt werden könnten.
Kapitel 3
Information Retrieval Systeme
Gliederung dieses Kapitels
In diesem Teil des Untersuchungsbereiches erfolgt eine umfassende Behandlung von
Information Retrieval (IR) Systemen aus theoretischer und praktischer Sicht. Die modulare Architektur des xFIND-Suchsystems (siehe Kapitel 2) gestattet es, zur Indizierung der Daten beliebige IR Systeme zu verwenden. Zumal xFIND ein allgemeines
Rahmenwerk zur Erstellung vielfältiger Suchanwendungen bietet, ist es bei der Wahl
eines konkreten IR Systems unbedingt erforderlich, sich an den Vorgaben des jeweiligen
Einsatzgebietes zu orientieren. Die vorliegende Studie erschließt die den IR Systemen
zugrundeliegenden Mechanismen und liefert wesentliche Entscheidungskriterien für ihre
Auswahl.
In Abschnitt 3.1 wird zunächst die Bedeutung derartiger Systeme im Informationszeitalter erläutert. Daran anschließend wird in Abschnitt 3.2 der Aufbau und die
Funktionsweise von IR Systemen beschrieben. Dabei werden jene Merkmale herausgearbeitet, die eine gezielte Analyse von zu beurteilenden Systemen erleichtern sollen, dies
sind im einzelnen das Grundkonzept (siehe Abschnitt 3.2.1), die Dateistruktur (siehe
Abschnitt 3.2.2), die Indizier-, Such- und Anzeigefunktionen (siehe Abschnitt 3.2.3)
und die qualitativen und quantitativen Bewertungskriterien (siehe Abschnitt 3.2.4) eines IR Systems.
In Abschnitt 3.3 wird auf der theoretischen Basis aufbauend eine Analyse von
gegenwärtigen IR Systemen durchgeführt. Ein besonderes Augenmerk wird auf die
vom xFIND-Projekt gestellten Anforderungen (siehe Abschnitt 3.3.1) gelegt. Eine Gegenüberstellung der analysierten IR Systeme hinsichtlich ihrer unterstützten Funktionen (siehe Abschnitt 3.3.2) und ihrer gezeigten Indizier- und Suchperformance (siehe
Abschnitt 3.3.4), sowie eine detaillierte Beschreibung der Vor- und Nachteile (siehe
Abschnitt 3.3.3) können als Entscheidungshilfe für das xFIND-Projekt oder ähnliche
IR-Projekte herangezogen werden.
Abgerundet wird die Untersuchung in Abschnitt 3.3.5 mit dem Vergleich einiger
Search Development Kits, die eine sehr flexible Alternative zu den zuvor getesteten IR
Systemen darstellen.
14
KAPITEL 3. INFORMATION RETRIEVAL SYSTEME
3.1
15
Motivation
Die ständig anwachsenden Informationsmengen in Bibliotheken, Datenbanken und gerade in den letzten Jahren auch im World Wide Web haben die Entwicklung von immer
leistungsfähigeren IR Systemen notwendig gemacht und vorangetrieben. [FB92]
Der wohl wichtigste Bestandteil dieser Systeme ist der Index, eine Liste von Termen1 und Verweisen auf Orte, an denen die dazugehörige Information zu finden ist.
Er ermöglicht die rasche Lokalisierung eines Suchbegriffes in einer umfangreichen Datensammlung. In ihrer ursprünglichsten Form findet man Indizes in Büchern oder als
Karteikartensystem in Bibliotheken. Derartige Suchhilfen sind aufgrund ihrer Einfachheit und Effizienz auch heute, etwa 200 Jahre nach ihrer Einführung, die am häufigsten
verwendete Methode, um auf Informationen zuzugreifen. [FB92]
Die Informationsexplosion vergangener Jahre und Jahrzehnte stellt nun neue Anforderungen. Einerseits benötigt man schnellere Computer, höhere Speicherkapazität
und größere Übertragungsbandbreiten, andererseits müssen die Datenstrukturen und
Algorithmen zur Archivierung und Wiederauffindung entscheidend verbessert werden.
Moderne Computersysteme eröffnen unzählige Möglichkeiten zur Indizierung von Dokumenten, dies ist auch der Grund dafür, daß IR in vielen äußerst unterschiedlichen
Anwendungsgebieten zum Einsatz kommen kann und wird. IR ist darüberhinaus durch
eine besonders ausgeprägte Interdisziplinarität gekennzeichnet, so sind Einflüsse von
Künstlicher Intelligenz, Datenbankmanagement, Multimediatechniken, Parallelverarbeitung und vielen anderen Forschungsbereichen vorhanden. [FB92]
3.2
Architektur und Funktionsweise von
IR Systemen
Die grundsätzliche Aufgabe eines IR Systems ist der Vergleich von Benutzeranfragen
mit den in einer Datenbank gespeicherten Dokumenten und die Rückgabe von Suchergebnissen. Ein Dokument ist ein Datenobjekt, das viele unterschiedliche Datentypen
(z.B. Text, Bilder, Audio, Video) in sich kapseln kann. Eine kompakte Beschreibung
eines Dokumentes in einem definierten Datenformat kann man in diesem Zusammenhang ebenfalls als ein Dokument betrachten. Das Harvest-Suchsystem [HSW96] verwendet das Metadatenformat SOIF (Summary Object Interchange Format) und ist
für die durchzuführende Analyse von Indexern von weiterer Bedeutung. Das SOIFDatenformat wird in Abschnitt 3.3.1.2 noch näher vorgestellt werden. Die Generierung
von Beschreibungsobjekten wirkt sich insbesondere günstig auf die Datenbankgröße
und die Suchzeit aus. [FB92]
1
Terme können aus jeder erdenklichen Art von suchbarer Information bestehen, z.B.
Schlüsselwörter eines Textes, Themengebiete, Autorennamen oder Telefonnummern.
16
Um eine erste Vorstellung von einem IR System zu bekommen, ist eine Betrachtung
aus funktionaler Sicht sinnvoll. Abbildung 3.1 zeigt die Arbeitsweise eines auf einem
boolschen Modell basierenden typischen IR Systems.
Abbildung 3.1: Funktionales Modell eines typischen IR Systems
(Quelle: [FB92])
Wie aus der Abbildung ersichtlich ist, muß jedes IR System zumindest Funktionen
zum Einfügen, Ändern und Löschen von Dokumenten zur Verfügung stellen, weiters
muß die Suche nach Dokumenten und die Ergebnisausgabe unterstützt werden. Die
Realisierung dieser Funktionalitäten unterscheidet sich von System zu System erheblich, man kann jedoch mit Hilfe einer Domain Analyse [PDA91] eine Einteilung der IR
Systeme in einige wenige Klassen vornehmen. Bei einer Domain Analyse wird versucht,
Ähnlichkeiten und Unterschiede zwischen Systemen zu finden, die mehrfach miteinander in Beziehung stehen. Dazu werden die wesentlichen Konzepte und Begriffe der be-
17
trachteten Systeme definiert und anschließend in sogenannte Aspekte und dazugehörige
Aspektwerte eingeteilt.
In Tabelle 3.1 sind mögliche Bestandteile von IR Systemen aufgelistet. Die erste
Zeile bezeichnet die Aspekte, die jedes IR System zwingend aufzuweisen hat, darunter
stehen die Aspektwerte die angeben, wie ein Aspekt tatsächlich realisiert werden kann.
Beispielsweise benötigt jedes IR System eine Filestruktur, die auf mehrere Arten implementiert werden kann, z.B. als invertiertes File oder als Graph. Natürlich können
auch mehrere Aspektwerte gleichzeitig zur Anwendung kommen.
Modell
Filestruktur
Stringsuche
Boolsche Suche
Erweiterte Boolsche Suche
Probabilistische Suche
Vektorraumsuche
Flaches File
Invertiertes File
Signaturfile
Graph
Query
Operationen
Parsing
Boolean
Clustering
Feedback
Term
Operationen
Stemming
Gewichtung
Thesaurus
Stopliste
Truncation
Dokument
Operationen
Parsing
Anzeige
Clustering
Ranking
Sortierung
FeldIDs
Hardware
vonNeumann
Parallel
IR spezifisch
Optospeicher
Magnetspeicher
Tabelle 3.1: Aspekte und Aspektwerte von IR Systemen als Ergebnis
einer Domain Analyse (Quelle: [FB92])
Die einzelnen Aspekte und die entsprechenden Aspektwerte erfahren in der Folge
unterschiedliche Aufmerksamkeit, so wird das Modell nur kurz beschrieben (siehe Abschnitt 3.2.1) und der Schwerpunkt auf die Filestruktur gelegt (siehe Abschnitt 3.2.2),
die Hardware wird nicht näher betrachtet. Query, Term und Dokument Operationen
sollen ebenfalls kurz diskutiert werden (siehe Abschnitt 3.2.3), um die Analyse der
gegenwärtigen IR Systeme von einem theoretischen Standpunkt her vorzubereiten.
3.2.1
Modell
Jedes IR System basiert auf einem oder mehreren Grundkonzepten, die sich nicht unbedingt gegeneinander ausschließen. Abbildung 3.2 zeigt eine grobe Einteilung aufgrund
des Suchverfahrens, wie sie in [BC87] vorgeschlagen wird.
Abbildung 3.2: Basismodelle von IR Systemen und deren Einteilung
18
Die Stringsuche wird vorallem bei kleineren Datenbeständen eingesetzt, hier bestehen die Suchanfragen aus Strings und regulären Ausdrücken. Ein prominentes Beispiel dafür ist grep2 zur Suche in lokalen Filesystemen. Bei großen Datensammlungen
wird in erster Linie die Boolsche Suche verwendet, die Anfragen werden mit Hilfe von
Schlüsselwörtern und den logischen Operatoren AND, OR und NOT formuliert. Die klassische Boolsche Suche verhält sich in vielen Fällen äußerst strikt, um eine Verbesserung
des Suchresultates zu erzielen wurden daher zahlreiche Erweiterungen durchgeführt.
Bei der Erweiterten Boolschen Suche kann man u.a. den Schlüsselwörtern individuelle
Gewichte zuweisen. [FB92]
Die probabilistische Suche bezieht statistische Wortverteilungen in die Bewertung
mit ein, so gelingt es, die Suchergebnisse nach ihrer wahrscheinlichen Relevanz zu ordnen. Bei der Vektorraumsuche werden Anfragen und Dokumente als mehrdimensionale
Vektoren im Raum betrachtet, das Matching entspricht dann einer Distanzbestimmung
zwischen den Vektoren. Wie bei der probabilistischen Suche eröffnen sich auch hier viele
Möglichkeiten zum Ranking3 der Suchergebnisse. [FB92]
3.2.2
Filestruktur
Der interne Aufbau von IR Systemen läßt sich in einige prinzipielle Klassen einteilen.
Die wohl wichtigste Organisationsform sind invertierte Files (siehe Abschnitt 3.2.2.2),
die eine lexikographische Ordnung der Suchterme ausnützen. Flache Filestrukturen
(siehe Abschnitt 3.2.2.1) sind ebenfalls weitverbreitet, weniger populär sind Indizes,
die auf Hashing beruhen (siehe Abschnitt 3.2.2.3) und vernetzte Architekturen (siehe
Abschnitt 3.2.2.4). An dieser Stelle soll nocheinmal darauf hingewiesen werden, daß ein
konkretes IR System selbstverständlich auch mehrere unterschiedliche Filestrukturen
in sich vereinen kann. [FB92]
3.2.2.1
Flache Files
Bei dieser Struktur wird vorzugsweise die bereits genannte Stringsuche verwendet (siehe Abschnitt 3.2.1). Obwohl die Stringsuche im Vergleich zu anderen Verfahren relativ
langsam ist, sind flache Files und deren Behandlung auch innerhalb moderner IR Systeme von großer Bedeutung, so etwa bei der Feinfilterung von potentiellen Ergebnissen
oder bei der Suche nach Begriffen, die im Ergebnis hervorgehoben werden sollen. Die
Vor- und Nachteile gemäß [FB92] sind nachfolgend aufgelistet:
• Vorteile:
– viele sehr gute Algorithmen zur Stringsuche sind vorhanden
– beinahe kein zusätzlicher Platzbedarf für Verwaltungsinformationen
• Nachteile:
– Suche in großen Datenbeständen zu langsam
2
3
UNIX-Tool zur sequentiellen Suche nach Textmustern
Ordnung der Dokumente aufgrund eines definierten Relevanzmaßes
3.2.2.2
19
Invertierte Files
Grundlage für die Erstellung dieser Datenstruktur ist eine Dokumentenmenge. Jedes
darin enthaltene Dokument wird durch seine Schlüsselwörter und optional durch die
dazugehörigen Relevanzwerte beschrieben. Ein invertiertes File ist dann die sortierte
Liste aller Schlüsselwörter, wobei für jedes Wort die Dokumente in der Postingdatei
vermerkt werden, in denen es auftritt. Abbildung 3.3 zeigt ein Beispiel für einen derartigen Index.
Abbildung 3.3: Sortiertes Array zur Realisierung eines invertierten
Files (Quelle: [FB92])
Über die sortierten Schlüsselwörter wird zumeist eine binäre Suche durchgeführt,
dadurch lassen sich auch bei großen Datenbeständen die Antwortzeiten bedeutend
verbessern. Dennoch sei auf einige Erfordernisse dieses Indexverfahrens hingewiesen [FB92]:
• Zusätzlicher Speicher ist notwendig, die Größe variiert von 10 bis 100 % und mehr
bezogen auf die Originaldaten des zu indizierenden Dokumentes.
• Bei häufigen Datenänderungen ist das Indexupdate4 ein bestimmender Faktor
für die Effizienz des Systems.
• Man benötigt ein kontrolliertes Vokabular, das vorgibt, was der Indizierung zugeführt bzw. von der Indizierung und somit auch von der Suche ausgeschlossen
wird.
• Regeln zur Behandlung von Leerzeichen, Satzzeichen, Präfixes etc. sind zu formulieren.
4
Einfügen oder Löschen von Schlüsselwörtern und/oder Verweisen
20
Invertierte Files können, entsprechend den an sie gestellten Anforderungen, sehr
unterschiedlich implementiert werden. In der Praxis haben sich die folgenden lexikographischen Indizes bewährt [FB92]:
Sortierte Arrays
Die Liste der Schlüsselwörter wird zusammen mit der Häufigkeit ihres Auftretens und
den Dokumentverweisen in einem sortierten Array gespeichert, für die effiziente Abfrage des Index sorgt eine binäre Suche. Ein Beispiel wurde bereits in Abbildung 3.3
angegeben.
• Vorteile:
– einfache Handhabung des Arrays
– Zugriff in den meisten Anwendungsfällen ausreichend schnell
• Nachteile:
– Update des Index ist aufwendig
B-Bäume
Im binären Suchbaum enthält jeder innere Knoten einen Schlüsselwert, der linke Teilbaum speichert alle Schlüsselwerte, die kleiner als der im übergeordneten Knoten sind,
der rechte Teilbaum speichert dementsprechend jene die größer sind.
Dieses Konzept läßt sich auf Suchbäume verallgemeinern, die in jedem inneren
Knoten mehrere Verzweigungen und eine gleichmäßige Tiefe (Balanciertheit) aufweisen.
Solche B-Bäume werden nun als Index verwendet, wobei alle zu den Schlüsselwörtern
gehörenden Informationen in den Blättern gespeichert werden. Abbildung 3.4 stellt eine
Variante eines B-Baumes vor, die Präfixes als Schlüssel benützt und zudem eine variable
Anzahl von Knotenverzweigungen unterstützt. Bei der Suche nach einem Schlüsselwort
wird ausgehend von der Wurzel in die passenden Teilbäume verzweigt, bis man auf der
Blattebene angelangt ist.
• Vorteile:
– umfassend wissenschaftlich untersuchte Datenstruktur
– sehr schneller Zugriff (Anzahl der Diskzugriffe entspricht Baumhöhe)
– Update ist auch bei sich häufig ändernden Daten unproblematisch
• Nachteile:
– größerer Platzbedarf als bei sortiertem Array
– schwieriger zu implementieren
21
Abbildung 3.4: Präfix B-Baum mit variabler Anzahl von Knotenverzweigungen (Quelle: [FB92])
Tries
Bei dieser Datenstruktur handelt es sich um einen binären Baum, der alle möglichen
Teilstrings eines Textes speichert. Die binäre Beschreibung der Strings wird zur Steuerung der Suche herangezogen, ein Nullbit bedeutet eine Verzweigung nach links, ein
Einsbit eine Verzweigung nach rechts. Ein geordnetes Alphabet vorausgesetzt, wird in
der Wurzel das erste Zeichen betrachtet, in den Kindern der Wurzel das zweite Zeichen
usw., der Pfad von der Wurzel bis zu einem Blatt beschreibt somit einen Teilstring.
Die Position des Auftretens dieses Teilstrings im Text wird im Blatt gespeichert.
Abbildung 3.5 zeigt einen Trie für den Text "01100100010111..." nach dem
Einfügen bis zum achten Bit. Wie zu erkennen ist, tritt z.B. der Teilstring "010" ab
der fünften Textposition auf. Tries eignen sich ausgezeichnet zur Suche nach Präfixes,
es ist aber ebenso möglich, Tries für die Suche nach Suffixes zu generieren.
Abbildung 3.5: Trie zur Verwaltung von binär beschriebenen Strings
(Quelle: [FB92])
22
• Vorteile:
– sehr schnelle Stringsuche
– Der Text muß nicht zwingend eine Dokument- oder Wortstruktur aufweisen,
er wird als ein einzelner langer String aufgefaßt. Die Anfragen basieren auf
Teilstrings, die an einer bestimmten Position im Text beginnen und sich
beliebig weit nach rechts erstrecken.
– Dadurch ergeben sich zusätzliche Anfragefunktionalitäten:
∗ Präfixsuche: Jeder Teiltrie enthält alle Teilstrings mit einem bestimmten Präfix, der durch den Pfad von der Wurzel des Tries zur Wurzel
des Teiltries bestimmt ist. Es muß demnach lediglich der gesamte Teiltrie ausgegeben werden, um alle Ergebnisse zu erhalten, die mit diesem
Präfix beginnen.
∗ Umgebungssuche: Auffinden aller Positionen, an denen ein Teilstring
von einem anderen Teilstring eine bestimmte Anzahl von Zeichen entfernt ist.
∗ Bereichssuche: Auffinden aller Strings, die lexikographisch zwischen
zwei angegebenen Strings liegen, z.B. alle Strings zwischen "abc" und
"acc".
∗ Häufigstes Auftreten von Strings
• Nachteile:
– Es wird jede Position des Textstrings im Trie vermerkt, wodurch ein sehr
großer Speicherbedarf entsteht. Die meisten Anwendungen benötigen nicht
unbedingt den Zugriff auf einzelne Zeichenpositionen, sondern lediglich auf
Worte oder Phrasen. In diesem Fall dürfen nur die entsprechenden Teilstrings in den Trie aufgenommen werden.
PAT-Bäume
Sie sind auch bekannt als Patricia-Bäume (Practical Algorithm To Retrieve Information
Coded In Alphanumerical) und stellen eine Abwandlung der Tries dar. Zum Unterschied
zu Tries werden hier innere Knoten eliminiert, die nur einen Nachfahren aufweisen,
weiters wird in jedem inneren Knoten eine Variable mitgeführt, die das nächste zu
untersuchende Bit anzeigt.
3.2.2.3
23
Signaturfiles
Sie basieren auf der Idee eines ungenauen Filters, der zusätzlich zu den passenden Dokumenten auch einige Dokumente durchläßt, die den Anforderungen nicht genügen.
Jedes Dokument wird durch eine sogenannte Signatur identifiziert. Zur Bestimmung
der Signatur wird das Dokument zunächst in logische Blöcke zerlegt, das sind Textteile, die eine konstante Anzahl von Wörtern beinhalten. Jedes Wort für sich erhält
eine Wortsignatur konstanter Länge, dabei handelt es sich um ein von einem HashingAlgorithmus generiertes Bitmuster. Diese Wortsignaturen werden mit dem logischen
Operator OR verknüpft und bilden die Blocksignatur. Schließlich werden die Blocksignaturen konkateniert zur Dokumentsignatur. [FB92]
Im folgenden Beispiel wird eine einfache Blocksignatur berechnet, dabei besteht
ein Block aus lediglich zwei Wörtern und jedes Wort wird durch eine 12 Bit lange
Wortsignatur repräsentiert.
Wort
neue
medien
OR
Signatur
001000110010
000010101001
001010111011
Ein Signaturfile sammelt die Signaturen aller Dokumente, eine mögliche Speicherstruktur zeigt Abbildung 3.6. Hier werden die Blocksignaturen sequentiell verwaltet,
die zugeordneten Zeiger verweisen auf den Beginn der logischen Textblöcke. Sobald
eine Anfrage einlangt, wird sie in Wortsignaturen umgesetzt, mit deren Hilfe letztlich
die in Frage kommenden Blöcke im Signaturfile gefunden werden.
Abbildung 3.6: Signaturfile als sequentielle Anordnung von Blocksignaturen (Quelle: [FB92])
24
• Vorteile:
– wesentlich schneller als Stringsuche
– bedeutend geringerer Platzbedarf als bei invertierten Files
– neue Dokumente können einfach angehängt werden, Suchanfragen können
währenddessen ebenfalls bearbeitet werden
– es werden mit Sicherheit alle zur Suchanfrage passenden Dokumente gefunden
• Nachteile:
– für große Datensammlungen langsam, ohne Modifikation (z.B. Kompression
und/oder Partitionierung des Signaturfiles) lineares Antwortzeitverhalten
– abhängig von der Methode der Signaturbestimmung können bei Suchanfragen mehr oder weniger unpassende Dokumente gefunden werden
3.2.2.4
Graphen
Mathematisch gesehen versteht man unter einem Graph eine Menge von Knoten, die
durch gerichtete Kanten miteinander verbunden sind. In IR Systemen nützt man diesen
Ansatz, um Dokumente mit Hilfe von semantischen Netzen zu beschreiben. [FB92]
• Vorteile:
– es bleiben Zusammenhänge erhalten, die die Flexibilität der Suche erhöhen
• Nachteile:
– derzeit ist es nicht möglich, semantische Netze ohne manuellen Eingriff zu
erzeugen, daher besteht momentan eine Einschränkung auf kleine Datenbestände
Die genannten Modelle und Filestrukturen sind in erster Linie für den Entwickler von
Interesse. Um ein IR System praxisgerecht bewerten zu können, muß es in jedem Fall
auch aus der Perspektive des Benutzers betrachtet werden. Hier spielt das Funktionsangebot, das im nun folgenden Abschnitt behandelt wird, eine wichtige Rolle.
3.2.3
25
Funktionalität
Im Laufe der Jahre wurden die IR Verfahren immer intelligenter, schneller und vielfältiger, sodaß es einen beachtlichen Aufwand darstellt, IR Systeme aufgrund ihrer angebotenen Funktionen zu vergleichen. Um eine objektive Gegenüberstellung erzielen zu
können, sollen die wesentlichen Funktionalitäten getrennt nach den Teilgebieten Indizierung (siehe Abschnitt 3.2.3.1), Suchanfrage (siehe Abschnitt 3.2.3.2) und Suchergebnis (siehe Abschnitt 3.2.3.3) beschrieben werden.
3.2.3.1
Indizierung
Eine elementare Designentscheidung stellt die Granularität eines Index dar, von ihr sind
Art und Anzahl der Funktionalitäten abhängig. Unter Granularität wird die Auflösung
verstanden, mit der die Positionen der einzelnen Terme innerhalb eines Dokumentes
aufgezeichnet werden. Anders ausgedrückt ist es die Genauigkeit, mit der die Position
eines Terms lokalisiert werden kann. [WMB94]
Wird beispielsweise für jedes Wort die genaue Position im Dokument im Index
vermerkt, so liegt eine sehr feine Auflösung vor. Wählt man eine grobe Auflösung, so
wird lediglich ein Verweis auf den jeweiligen Satz oder das jeweilige Dokument, in dem
sich das Wort befindet, im Index gespeichert. Dadurch reduziert sich einerseits der
Platzbedarf des Index beträchtlich, andererseits verliert man allerdings die Möglichkeit
einer einfach zu realisierenden Umgebungssuche. [WMB94]
Der Aufbau eines Index feiner Granularität wird in den meisten Fällen von Operationen begleitet, die den Platzbedarf verkleinern helfen. Gleichzeitig wirken sich die
im folgenden beschriebenen Verfahren auch auf die Abfragegeschwindigkeit und die
Suchergebnisse aus. [WMB94]
Case-folding: Es werden alle Großbuchstaben in Kleinbuchstaben konvertiert, erst
dann wird das Wort in den Index aufgenommen bzw. erfolgt die Suche im Index.
Der Benutzer muß sich über die genaue Schreibweise eines Suchbegriffes keine Gedanken machen, es gibt jedoch Anwendungsfälle, bei denen eine Unterscheidung
zwischen Groß- und Kleinschreibung wünschenswert ist. Beispielsweise werden
Eigennamen definitionsgemäß groß geschrieben und sollten auch in dieser Art
und Weise gesucht werden können. [Not99]
Stemming: Vor der Aufnahme in den Index und bzw. oder bei der Suche wird das
Wort auf seinen Wortstamm reduziert, es werden also Suffixes und andere Wortteile entfernt. Ungenauigkeiten im Suchbegriff werden kompensiert (z.B. Angabe
der Mehrzahl) und man erlangt auch Informationen, die bei einer exakten Interpretation der Anfrage ausgeschlossen wären. Der Benutzer muß sich bei dieser Operation jedoch bewußt sein, daß sehr große Ergebnismengen entstehen
können. [Sul99]
Sind die zu indizierenden Daten in verschiedenen Sprachen verfaßt, so ist beim
Stemming zusätzlich darauf zu achten, daß die Grammatik und die Sonderzei-
26
chen (z.B. Akzente) der jeweiligen Sprache mitberücksichtigt werden. Eliminiert
beispielsweise eine dem Stemming vorgelagerte Umwandlung des zu indizierenden Wortes in ASCII-Zeichen die Akzente, dann kann sich eine völlig andere
Bedeutung des Wortes ergeben. So haben z.B. die französischen Wörter delà und
dela einen anderen Wortstamm und sind strikt voneinander zu unterscheiden.
[CPG99]
Stopliste: Sie beinhaltet besonders häufig verwendete Wörter, die aufgrund ihrer geringen Relevanz nicht indiziert und nicht gesucht werden sollen. Die Stopwörter
hängen mitunter von der jeweiligen Anwendung ab, so treten in einem Wirtschaftsarchiv andere Wörter häufiger auf als in einer medizinischen Datenbank. [Sul99]
Thesaurus: Jedes Wort wird mit seinen Synonymen unter einem gemeinsamen Begriff im Index repräsentiert. Daraus ergeben sich hinsichtlich der Suchanfragen
dieselben Zusammenhänge wie beim Stemming. Gleichermaßen können Wörter
zu Konzepten zusammengefaßt werden, die eine thematische Suche möglich machen. [Sul99]
3.2.3.2
Suchanfrage
Abhängig von der Struktur des Index ergeben sich zahlreiche Alternativen zur Wiedergewinnung der Informationen. Nachfolgend werden die wichtigsten Suchverfahren
erläutert.
Boolsche Suche: Die Suchbegriffe werden durch die folgenden boolschen Operatoren
logisch verknüpft:
AND
OR
NOT
alle Suchbegriffe müssen im Ergebnis vorkommen
zumindest einer der Suchbegriffe muß enthalten sein
ein bestimmter Suchbegriff darf nicht vorkommen
Zusätzlich können Klammern erlaubt sein, die eine Verschachtelung der boolschen
Ausdrücke und somit komplexere Suchanfragen zulassen. Standardmäßig wird
bei mehreren Suchbegriffen häufig die OR-Verknüpfung gewählt, weiters wird AND
vor OR ausgeführt, sofern keine anderslautende Klammerung gesetzt wurde. Im
Zusammenhang mit logischen Operatoren sind noch der Inklusionsoperator +
und der Exklusionsoperator - erwähnenswert. [Ott97]
+Suchbegriff
-Suchbegriff
das Wort muß im Dokument enthalten sein
das Wort darf nicht im Dokument vorkommen
27
Umgebungsuche: Es kann festgelegt werden, in welcher näheren Umgebung von anderen Begriffen sich der Suchbegriff befinden soll. Die Grundüberlegung dabei
ist, daß nahe zusammenliegende Begriffe zumeist im gleichen Zusammenhang
erwähnt werden, wodurch man eine gezieltere Suche durchführen kann. In seiner
einfachsten Form handelt es sich um eine Phrasensuche, in diesem Fall wird nach
der exakten Reihenfolge der Suchbegriffe gesucht, es lassen sich ganze Sätze oder
Satzteile auffinden. [Ott97]
Für die Suche nach benachbarten Begriffen stehen die folgenden Abstandsoperatoren zur Verfügung.
NEAR
ADJ
Begriffe liegen innerhalb eines zu definierenden Abstandes zueinander
Phrasensuche, die Begriffe müssen direkt aufeinanderfolgen
Truncation: Wildcards ersetzen eines oder mehrere Zeichen in der Suchanfrage. Sie
können zur Erweiterung von Präfixes (z.B. steierm*), am Wortbeginn (z.B.
*mark) oder im Wortinneren (z.B. st*mark) verwendet werden. Durch die Verwendung von Platzhaltern gelingt es auch, Dokumente zu finden, die aufgrund
von Tippfehlern andernfalls nicht auffindbar wären. [Ott97]
Feldsuche: Man kann die Suche auf bestimmte Abschnitte eines Dokumentes einschränken, z.B. auf Titel, Überschriften, Links, URL’s oder Inhaltsbeschreibungen. In vielen Systemen kann man die Suche auch auf Datumsbereiche, Sprachen,
Hostnamen, Domains, Dokumentformate und ähnliches eingrenzen. [Not99]
Relevanz-Feedback: Im allgemeinen ist der Recall (siehe Abschnitt 3.2.4) eines IR
Systems begrenzt, es werden also in den seltensten Fällen alle relevanten Dokumente für eine Suchanfrage gefunden. Somit stellt sich die Frage, wie man die
ausständigen relevanten Dokumente auffinden kann. [FB92]
Eine Möglichkeit besteht darin, eine allgemeinere boolsche Anfrage zu formulieren, wodurch jedoch viele Ergebnisse mit niedriger Relevanz hinzukommen. Man
könnte auch andere Suchbegriffe verwenden, aber auch hier gibt es keine Sicherheit, daß sich die gewünschten Ergebnisse einstellen. Relevanz-Feedback soll in
diesem Problemkreis Abhilfe schaffen und so die Performance des IR Systems
positiv beeinflussen. [FB92]
Einen vielversprechenden Ansatz stellt die dynamische Gewichtung von Suchbegriffen (Query Reweighting) dar, dabei wird die Wahrscheinlichkeit miteinbezogen, mit der ein Begriff in relevanten und nichtrelevanten Dokumenten auftritt.
Die Wahrscheinlichkeiten werden aus den Anfrageergebnissen ermittelt und für
die Gewichtung neuerlicher Anfragen herangezogen, man nützt also die Rückmeldung des Systems zu einer weiteren Verbesserung des Resultates. [FB92]
Demgegenüber steht die Veränderung und Hinzunahme von Suchbegriffen (Query
Expansion) vor einer neuerlichen Suche. Die Erweiterung kann unter Verwendung
28
eines Thesaurus erfolgen, der Synonyme oder andere zu den Suchbegriffen passende Worte der Suchanfrage hinzufügt. Das Hauptproblem dabei besteht in der
Tatsache, daß diese Worte zumeist gemeinsam in denselben Dokumenten vorkommen, was keine wesentliche Verbesserung des Suchergebnisses zur Folge hat.
Eine andere Möglichkeit der Erweiterung besteht darin, aus den relevanten Ergebnissen Begriffe herauszufiltern und dem Benutzer zur Auswahl vorzulegen. Die
Auswahl kann auch automatisch getroffen werden, wobei die Anzahl der hinzugefügten Begriffe nicht zu groß sein sollte. Gute Ergebnisse werden beispielsweise
erzielt, wenn die ersten 20 dieser nach absteigender Relevanz sortierten Begriffe
der Suchanfrage hinzugefügt werden. [FB92]
Clustering: Unter einem Cluster wird im Zusammenhang mit IR Systemen eine Gruppe von Dokumenten verstanden, die untereinander eine hohe Ähnlichkeit aufweisen. Zwischen Dokumenten, die unterschiedlichen Clustern zugeordnet sind, soll
die Ähnlichkeit dagegen möglichst gering sein. [FB92]
Eine Suchanfrage wird lediglich mit den Clusterzentren verglichen, jener Cluster
der die höchste Ähnlichkeit aufweist, wird anschließend als Resultat ausgegeben.
Dieses Vorgehen reduziert die Anzahl der notwendigen Vergleichsoperationen und
damit die Suchzeit, die Qualität der Suchergebnisse hängt jedoch stark von der
Art und Weise ab, wie die Dokumentencluster gebildet werden. [FB92]
3.2.3.3
Suchergebnis
Einen besonderen Stellenwert in jedem IR System nimmt die Aufbereitung der Suchergebnisse ein. Welche Überlegungen in diesem Zusammenhang anzustellen sind und
welche Verfahren bereits realisiert sind, wird nachfolgend beschrieben.
Relevanz-Ranking: Es kommt eine Heuristik zur Anwendung, die die Ähnlichkeit
zwischen der Suchanfrage und den Dokumenten bestimmt. Als Ergebnis erhält
man eine definierbare Anzahl der ähnlichsten Dokumente, zumeist nach absteigender Relevanz sortiert. Im Laufe der Jahre wurden zahlreiche Ähnlichkeitsmaße
und Rankingstrategien erdacht [Not99]:
Beim Coordinate Matching ist die Häufigkeit des gesuchten Wortes im Dokument
für das Ranking ausschlaggebend, je häufiger es vorkommt, umso relevanter ist
es. Zusätzlich kann der Ort des Auftretens in die Berechnung einfließen, tritt
der Suchbegriff beispielsweise im Titel eines Dokumentes auf, so resultiert daraus eine höhere Bewertung als beim Auftreten am Ende des Inhaltes. Problematisch wirkt sich die Häufigkeit aus, wenn die Größe des Dokumentes außer
acht gelassen wird. Beim Term Weighting wird dieser Umstand mitberücksichtigt, die Häufigkeit des Wortes wird auf alle im Dokument enthaltenen Wörter
bezogen, darüberhinaus werden komplexere Ähnlichkeitsmaße eingesetzt. Bei der
Einbeziehung von Worthäufigkeiten in die Relevanzberechnung ist die Gefahr des
Spamming zu beachten. Dabei werden in einem Dokument einzelne Begriffe sehr
häufig wiederholt, um eine hohe Relevanz vorzutäuschen. [Not99]
29
Für HTML-Dokumente im speziellen lassen sich einige weitere Möglichkeiten zur
Festlegung der Relevanz definieren. Die Link Popularity gibt an, wieviele Links
von anderen Dokumenten auf das betreffende Dokument verweisen. Metadaten
können bevorzugt bewertet werden oder es wird überhaupt ein manuelles Ranking von Dokumenten durchgeführt. Eine Kombination aus mehreren Strategien
ist selbstverständlich auch möglich. [Not99]
Ergebnisanzeige: Wie schon erwähnt wurde, kann die Ausgabe der Suchergebnisse
nach absteigender Relevanz erfolgen, ebenso sind andere ausgewählte Sortierkriterien (alphabetisch, chronologisch, nach Domain etc.) denkbar. Welche Informationen vom System ausgegeben werden, sollte nach Möglichkeit vom Benutzer
konfigurierbar sein. Die wichtigsten Ausgabeelemente sind Dokumenttitel, Fundort, Kurzbeschreibungen, sowie Größen- und Datumsinformationen, insgesamt
sind hier der Vielfalt von möglichen Anzeigeoptionen jedoch keine Grenzen gesetzt. [Not99]
Dieser Abschnitt zeigte die Vielzahl der einem IR System innewohnenden Konzepte. Ein Gesichtspunkt, der in den bisherigen theoretischen Betrachtungen noch nicht
behandelt wurde, ist das Verhalten des Systems im laufenden Betrieb. Der nächste Abschnitt soll darüber Aufschluß geben, wie die Performance quantitativ und qualitativ
beurteilt werden kann.
3.2.4
30
Bewertung
Zur Bestimmung der Ausführungseffizienz wird die benötigte Zeit für die Indizierung,
das Update und die Suche gemessen. Für die Bewertung der Speichereffizienz wird der
benötigte Speicherbedarf ermittelt, ein gängiges Maß ist der Speicheroverhead, der folgendermaßen definiert ist [FB92]:
Speicheroverhead =
Indexgröße + Datenbankgröße
Datenbankgröße
(3.1)
Abgesehen von diesen quantitativen Messungen kann auch eine qualitative Beurteilung von IR Systemen vorgenommen werden, indem man die Relevanz der Suchergebnisse miteinbezieht. Die Relevanz eines Dokumentes unterliegt zwar einer subjektiven
Bewertung, nichtsdestotrotz haben sich zwei Maße, Vollständigkeit (Recall) und Genauigkeit (Precision), als allgemeingültig durchsetzen können. Als Ausgangspunkt dient
hier eine Suchanfrage an das IR System, bewertet wird das Suchergebnis. [FB92]
Recall =
Anzahl gef undener relevanter Dokumente
Anzahl relevanter Dokumente in Datenbank
P recision =
Anzahl gef undener relevanter Dokumente
Anzahl aller gef undener Dokumente
(3.2)
(3.3)
Die Kennwerte und zugehörigen Kurven lassen sich mit Hilfe von Testdatenbanken
und genau festgelegten Anfragen, für die zuvor eine Relevanzbeurteilung vorgenommen
wurde, experimentell ermitteln. [FB92]
Damit findet die theoretische Aufbereitung von IR Systemen ihren Abschluß. In den
kommenden Abschnitten werden aus der großen Anzahl der gegenwärtig am Markt
verfügbaren IR Systeme einige stellvertretend ausgewählt und einer Analyse zugeführt.
3.3
31
Analyse gegenwärtiger IR Systeme
Wie bereits die Theorie in Abschnitt 3.2 vermuten läßt, eröffnet sich ein breites Spektrum an IR Einsatzmöglichkeiten. Ebenso breit gefächert sind die bereits verfügbaren
Anwendungen, deren Bogen sich von einfachen, kostenlos erhältlichen Indizierern für
die private Website bis hin zu multifunktionalen Entwicklerpaketen erstreckt, die zur
Erstellung kompletter IR Lösungen in Intranet-Umgebungen großer Konzerne geeignet
sind.
Für die vorliegende Analyse werden gezielt einige IR Systeme ausgewählt, die kostenlos verfügbar und stellvertretend für ihre Anwendungsbereiche sind. Diese sind im
einzelnen:
Glimpse 4.1
Isearch 1.42
freeWAIS-sf 2.2.11
Smart 11.0
Zebra 1.0b1
Swish-e 1.3.2
Locus 0.95
Managing Gigabytes 1.2
http://glimpse.cs.arizona.edu/
http://www.etymon.com/Isearch/
http://ls6-www.informatik.uni-dortmund.de/ir/projects/freeWAIS-sf/
ftp://ftp.cs.cornell.edu/pub/smart/
http://www.indexdata.dk/zebra/
http://sunsite.berkeley.edu/SWISH-E/
http://www.locus.cz/locus/
http://www.cs.mu.oz.au/mg/
Zusätzlich wurde ein Search Development Kit praktisch getestet, das bereits im
Hyperwave Information Server5 sehr erfolgreich eingesetzt wird. Dabei handelt es sich
um das
Verity Search ’97 SDK
http://www.verity.com/products/devokit/index.html/
Nach der Festlegung der Anforderungen (siehe Abschnitt 3.3.1) erfolgt ein Vergleich
der Produkte bezüglich der Grundfunktionen (siehe Abschnitt 3.3.2) und aufgrund
ihrer besonderen Merkmale (siehe Abschnitt 3.3.3). Die Indizier- und Suchperformance
wird ebenfalls getestet und gegenübergestellt (siehe Abschnitt 3.3.4). Abschließend
werden, als sehr mächtige Alternative zu den analysierten IR Systemen, einige Search
Development Kits vorgestellt (siehe Abschnitt 3.3.5).
5
http://www.hyperwave.com/
3.3.1
32
Anforderungen
In diesem Abschnitt werden grundsätzliche Überlegungen angestellt, welche Voraussetzungen ein IR System mitbringen muß, um in einer sich laufend verändernden Umgebung eingesetzt werden zu können. Zusätzlich werden einige Ansprüche gestellt, deren
Erfüllung im Rahmen des xFIND-Projektes Vorteile bringen würden.
3.3.1.1
Allgemeine Forderungen
Frei verfügbarer Sourcecode: Dadurch werden Anpassungen an die speziellen Erfordernisse möglich, z.B. Verbesserung der Performance oder der Sicherheit.
Betriebssysteme und Netzanbindung: Das IR System sollte zumindest unter UNIX
lauffähig sein, Windows NT wäre ebenfalls wünschenswert. Die intern und extern verwendeten Protokolle sollten nach Möglichkeit anerkannten internationalen Standards genügen, im IR Bereich ist hier Z39.50 hervorzuheben. Eine
WWW-Schnittstelle, z.B. via CGI-Skript, sollte zur späteren Adaptierung vorhanden sein.
Effiziente Nutzung der Ressourcen: Der Speicher- und der Zeitbedarf für die Indizierung und die Suche entscheiden wesentlich über die Praxistauglichkeit eines
IR Systems. Diesem Punkt muß daher besondere Beachtung zukommen.
Funktionsangebot: Welche Funktionen unbedingt benötigt werden, hängt naturgemäß vom jeweiligen Einsatzbereich ab. Einige Grundfunktionen wie das inkrementelle Update, boolsche Suche, Relevanz-Ranking usw. sollten jedoch keinesfalls fehlen.
Administration: Das Erstellen eines neuen Index, aber auch das Update von bestehenden Indizes sollte sowohl manuell als auch automatisiert (z.B. mit Hilfe von
Shellskripts) auf einfache Weise durchführbar sein. Im täglichen Betrieb ergeben
sich mitunter Spezialfälle, die einige IR Systeme bereits berücksichtigen, z.B. expliziter Ausschluß bestimmter Dateien von der Indizierung oder automatisierte
Auslösungsmechanismen für eine komplette Neuindizierung.
Benutzerfreundlichkeit: Aus Benutzersicht sollte ein IR System möglichst intuitiv
zu bedienen sein, übersichtliche Suchformulare und Suchhilfen sind hier gefordert.
Die Anzeige der Suchergebnisse sollte der Benutzer selbst bestimmen können, in
jedem Fall müssen jedoch relevante Informationen rasch auffindbar sein.
Neben diesen allgemeinen Erfordernissen sind speziell für das xFIND-Projekt jene IR
Systeme von Interesse, die das SOIF-Datenformat sowie in UTF8 gespeicherte Daten unterstützen. Nachfolgend werden die Spezifikation und die Vorzüge der beiden genannten
Forderungen diskutiert.
3.3.1.2
33
Metadatenformat SOIF
In Abschnitt 3.2 wurde bereits erwähnt, daß sich die Generierung von Beschreibungsobjekten für die Originaldokumente positiv auf die Datenbankgröße und die Suchzeit
auswirkt.
Im Harvest-Suchsystem erstellt ein Gatherer6 für jedes Dokument eine Inhaltszusammenfassung. Diese enthält Attribut-Wert-Paare und wird im sogenannten Summary Object Interchange Format gespeichert [HSW96]. Das xFIND-Suchsystem [Gütl99]
verwendet ebenfalls dieses Format, deshalb soll an dieser Stelle das SOIF-Format kurz
erklärt werden.
SOIFSTROM
OBJEKT
AW-LISTE
AW-PAAR
ATTRIBUT
WERT
BEGRENZER
−→
−→
−→
−→
−→
−→
−→
OBJEKT | OBJEKT SOIFSTROM
@TYPE {URL AW-LISTE}
AW-LISTE | AW-PAAR AW-LISTE
ATTRIBUT {GRÖSSE} BEGRENZER WERT
Zeichenkette
Zeichenkette
:<tab>
Abbildung 3.7: Spezifikation SOIF-Format in BNF (Quelle: [HSW96])
Jedes SOIF-Objekt beinhaltet die URL des Dokumentes und eine Liste von AttributWert-Paaren. Nach dem Namen des Attributes steht die Länge des Inhaltes. Dieses
Format enthält aber nicht nur Teile des Originaldokumentes, ebenso können unterschiedlichste Zusatz- und Metainformationen aufgenommen werden. Welche Metainformation im SOIF-Objekt steht, hängt beim Harvest-System vom Summarizer7 des
entsprechenden Dokumentformates ab. Abbildung 3.8 zeigt ein HTML-Dokument und ein
mögliches korrespondierendes SOIF-Objekt. Bei diesem Beispiel werden unter anderem
fett gedruckte Textteile als Schlüsselwörter interpretiert und dem keywords-Attribut
zugeordnet. Die Informationen von Meta-Tags fließen ebenfalls in die entsprechenden
Attribute des SOIF-Objektes. Links werden erkannt und die Zieladresse im Attribut
url-reference abgelegt. Ähnlich wird mit den Inhalten anderer HTML-Tags und HTMLAttribute verfahren. [Neu98]
Das SOIF-Format beschreibt keine starre Konvertierung von Dokumenten, es stellt
vielmehr einen Rahmen zur Abbildung unterschiedlichster Dokumente in ein einheitliches Objekt dar, wobei die Zuordnung zu den Attributen individuell konfigurierbar
ist. [Neu98]
6
Softwaremodul, das üblicherweise am Hostrechner des Informationsservers läuft und periodisch
die dort gespeicherten Dokumente kontrolliert. [HSW96]
7
Auf ein bestimmtes Datenformat spezialisiertes Softwaremodul, z.B. HTML, Postscript, Portable
Document Format. [HSW96]
34
Wesentlicher Vorteil dieses Formates ist die einfache Verarbeitung. SOIF läßt sich
”on-the-fly” untersuchen und da es ohne spezielle Zeichen auskommt, braucht es keinen Escape-Mechanismus. Eine Menge von SOIF-Objekten läßt sich zu einem Paket
zusammenstellen, das als Strom übertragen wird. [Neu98]
Um die Vorzüge der SOIF-Objekte ausnützen zu können, sollte ein IR System dieses
Datenformat bereits unterstützen oder zumindest die Möglichkeit einer frei konfigurierbaren Feldindizierung und -suche anbieten.
<HTML>
<HEAD>
<META NAME="author" CONTENT="Dagobert Duck">
<META NAME="description" CONTENT="Mit
Einfuehrung des Euro aendert sich die
Bedeutung des Dollar als Weltwaehrung. Es
werden die zu erwartenden wirtschaftlichen
Auswirkungen auf Entenhausen untersucht.">
<META HTTP-EQUIV="KEYWORDS" CONTENT="Dollar
Euro Entenhausen">
<TITLE>Der Euro und seine Auswirkungen auf
Entenhausen </TITLE>
</HEAD>
<BODY>
<!- der inhalt des folgenden textes ist frei
erfunden und ist nicht ernst zunehmen. ->
<H1>Der Euro</H1>
<IMG SRC="/duck/bilder/duck_und_euro.jpg">
Was noch vor ein paar Jahren niemand in
<A HREF="http://www.entenhausen.org">
Entenhausen</A> fuer moeglich hielt,
ist nun Gewissheit. Die Staaten der
<A HREF="http://www.eu.gv">EU</A> bekommen
eine gemeinsame <B>Waehrung</B>.
</BODY>
</HTML>
@FILE { http://www.dagobert.eh/euro/euro.htm
time-to-live{6}:
360000
last-modification-time{9}:
921234650
refresh-rate{6}:
241920
update-time{6}:
84600
type{4}:
html
file-size{4}:
2099
md5{32}:
abcdef1234567890abcdef1234567890
gatherer-name{14}:
Weltwirtschaft
author{13}:
Dagobert Duck
body{155}:
Der Euro
Was noch vor ein paar Jahren niemand in
Entenhausen fuer moeglich hielt, ist nun
Gewissheit. Die Staaten der EU bekommen eine
gemeinsame Waehrung.
description{166}:
Mit Einfuehrung
des Euro aendert sich die Bedeutung des
Dollar als Weltwaehrung. Es werden die zu
erwartenden wirtschaftlichen Auswirkungen
auf Entenhausen untersucht
images{30}:
/duck/bilder/duck und euro.jpg
headings{8}:
Der Euro
keywords{49}:
Auswirkungen
Dollar
EU
Entenhausen
Euro
Waehrung
title{47}:
Der Euro und seine
Auswirkungen auf Entenhausen
url-reference{43}:
www.entenhausen.org
www.eu.gv
}
Abbildung 3.8: HTML-Datei und korrespondierendes SOIF-Objekt (Quelle: [Neu98])
Abschließend ist noch festzustellen, daß SOIF eine Kompatibilität zu weitverbreiteten Dokumentformaten, wie SGML, HTML, Postscript oder RTF aufweist. Dies dürfte mit
ein Grund dafür gewesen sein, daß Netscape ihr RDM (Resource Description Messaging)
Suchsyntax-Format dahingehend erweitert hat, sodaß es direkt mit SOIF-Objekten arbeiten kann. [Wei2000]
3.3.1.3
Konvertierungsformat UTF-8
Ein wesentlicher Punkt bei der Entwicklung einer Anwendung ist die Einsetzbarkeit
über Landes- und Sprachgrenzen hinweg. Eine Möglichkeit dies zu erreichen, stellt die
Verwendung von standardisierten Zeichensätzen dar. Derartig definierte Zeichensätze
35
werden letztendlich durch verschiedene Datenformate, wie beispielsweise dem hier vorgestellten UTF-8 Format, repräsentiert.
Um die Bedeutung dieses Datenformates einordnen zu können, muß man sich
zunächst mit dem übergeordneten ISO 10646 oder gleichbedeutend mit dem Unicode
Standard auseinandersetzen. Darin wird der UCS (Universal Multiple-Octet Coded
Character Set) definiert, eine Zusammenfassung aller Zeichen in allen weltweit vorhandenen geschriebenen Sprachen. Jedes Zeichen ist durch eine Bitsequenz eindeutig
identifizierbar, für die Codierung selbst werden zwei (UCS-2) oder vier Byte (UCS-4)
verwendet. [Jär96]
Bei UCS-2 lassen sich demnach 65536 Zeichen ausdrücken, dies entspricht einer
Ebene mit 256 Zeilen und 256 Spalten. Die beiden Byte dienen somit der Ansteuerung
eines Zeichens innerhalb der Ebene. Von besonderem Interesse ist die Zeile 0, sie beinhaltet dieselben Zeichen wie der ISO/IEC 8859-1 Zeichensatz, die ersten 128 Zeichen
von UCS-2 sind daher ohne jegliche Änderung mit dem ASCII-Zeichensatz identisch.
Bei UCS-4 erhöht sich die Anzahl auf beachtliche 2147483648 Zeichen (höchstwertiges
Bit wird definitionsgemäß 0 gesetzt), die Unterteilung erfolgt in 128 Gruppen mit je
256 Ebenen, die wie bei UCS-2 gehandhabt werden. Mit der UCS-2 Codierung kann
man hier demnach nur in Gruppe 0 und Ebene 0 agieren, diese bezeichnet man als BMP
(Basic Multilingual Plane). [Jär96]
UCS wurde so ausgelegt, daß es sowohl zur Datenrepräsentation in Computersystemen als auch zur Datenübertragung geeignet ist. In vielen Fällen behandeln Betriebssysteme oder Übertragungsprotokolle bestimmte Bytewerte auf besondere Weise,
z.B. als Steuer- oder Sonderzeichen. Würde man den UCS-Code einfach in 2 oder 4
Byte aufteilen, so würden sich solche ”unerwünschten”Bytewerte ergeben. Um dies zu
vermeiden wurden einige Transformationsformate (UCS Transformation Format) wie
UTF-7, UTF-8 oder UTF-16 entwickelt. [Jär96]
Nachfolgend sollen die Merkmale von UTF-8 angegeben werden, da dieses Format
auch für das xFIND-Projekt und die weitere Arbeit von Bedeutung ist: [RFC2279]
• ASCII-Codes bleiben erhalten, d.h. die ersten 128 Zeichen werden
durch ein Byte repräsentiert (Wertebereich hex. 00-7F).
• Alle anderen UCS-Codes werden durch eine Folge von zwei bis sechs
Byte (Wertebereich hex. 80-FF) ausgedrückt.
• Die Umwandlung der UCS-Zeichen in UTF-8 ermöglicht zumeist eine direkte Verwendung, ohne die Software aufwendig verändern zu müssen.
• Zeichengrenzen innerhalb eines Bytestreams sind einfach zu erkennen.
• Ein schneller Algorithmus von Boyer-Moore8 zur Suche in UTF-8 Daten
ist vorhanden.
Somit stehen die Rahmenbedingungen für die Analyse der IR Systeme fest, diese findet ihren Ausgangspunkt in der Erhebung der unterstützen Funktionen im nächsten
Abschnitt.
8
Eine Beschreibung des Algorithmus von Boyer-Moore zur Stringsuche ist auf der beiliegenden
CD-ROM oder unter http://www.dir.univ-rouen.fr/~charras/string/string.html zu finden.
3.3.2
36
Informale Gegenüberstellung
Der Vergleich der IR Systeme erfolgt anhand der grundlegenden Verfahren (siehe
Abschnitt 3.2.3) und der geforderten Merkmale (siehe Abschnitt 3.3.1). Als Basis
der Untersuchung wurde eine Studie der Lund University in Schweden herangezogen
[KABL96].
In [BS99] werden geeignete Programme speziell zur Indizierung von kleineren bis
mittelgroßen Websites (bis 10000 Dokumente) beschrieben. Bei näherer Betrachtung
gibt es viele Berührungspunkte mit der vorliegenden Analyse, so unterstützen die meisten Programme frei definierbare Feldstrukturen zur Indizierung und Suche. Weitere
Vergleichskriterien wurden aus [MS95] entnommen, hier werden bereits zwei IR Systeme, WAIS und Glimpse, einer ausführlichen Analyse unterzogen, wobei der Schwerpunkt jedoch ausschließlich auf der Verarbeitung von HTML-Dokumenten liegt.
Die Ergebnisse der Analyse sind in Tabelle 3.2 zusammengefaßt und sollen einen
raschen Überblick über die Leistungsfähigkeit der IR Systeme geben.
Funktionalität
Glimpse
Indizierung
Case-folding
Stemming
Stopliste
Thesaurus
inkrementelles Update
Volltext
HTML
SOIF
weitere Formate
numerische Daten
UTF-8
Suche
Boolean
Phrasen
Proximity
Truncation
Fielded
Relevanz-Feedback
Clustering
Misspelling Tolerance
Reguläre Ausdrücke
Term Weighting
Bereichssuche
interaktiv
WWW-Interface
Z39.50-Interface
Ausgabe
Relevanz-Ranking
Sortierung
Anzeigeoptionen
Plattform
UNIX
Windows NT
Isearch
freeWAIS-sf
Smart
•
•
•
•
•
•
•
Zebra
Swish-e
Locus
MG
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Tabelle 3.2: Funktionsumfang frei verfügbarer IR Systeme
•
3.3.3
37
Reviews
Um einen detaillierten Eindruck von den vorgestellten IR Systemen zu erhalten, wird
in diesem Abschnitt auf ihre Besonderheiten eingegangen. Für weiterführende Informationen sei auf die Dokumentation der einzelnen IR Systeme verwiesen.
3.3.3.1
Glimpse
Die hier beschriebenen Details der Global Implicit Search, kurz Glimpse9 , stammen
aus [MW93] und den mitgelieferten Man Pages. Das System wurde an der University
of Arizona ursprünglich zur Suche in lokalen Dateihierarchien entwickelt, mittlerweile
wird es allerdings auch im Rahmen vieler Webanwendungen eingesetzt. Unter anderem wird Glimpse im Harvest-Suchsystem standardmäßig zur Indizierung und Suche
verwendet [HSW96].
Ein weiteres Beispiel ist WebGlimpse, das im wesentlichen auf Glimpse basiert, wobei nunmehr die Dateien eines HTTP-Servers indiziert und die aufbereiteten Daten über
ein Web-Interface für Suchanfragen zur Verfügung gestellt werden. WebGlimpse bietet
als Besonderheit die Suche in sogenannten Nachbarschaften an. Dabei hat der Benutzer
die Möglichkeit, seine Suchanfrage in einer Suchbox zu formulieren und gleichzeitig auf
die Nachbarschaft der aktuellen HTML-Seite zu beschränken. Der Begriff der Nachbarschaft bezieht sich hier auf Seiten, die nicht weiter als eine maximale, vorher definierte
Anzahl von Links von der Seite entfernt sind, von der aus die Suche gestartet wurde.
Eine Suchbox wie sie Abbildung 3.9 zeigt, kann problemlos in jede beliebige HTML-Seite
eingebunden werden. [BS99]
Abbildung 3.9: Suchinterface von WebGlimpse (Quelle: [BS99])
Wesentliche Zielsetzungen von Glimpse sind ein geringer Speicherplatzbedarf, ein
umfassendes Angebot von Suchfunktionen und eine einfache Anpassung an spezielle
Erfordernisse. Glimpse vereinigt hierzu zwei unterschiedliche IR Ansätze, zum einen
den invertierten Index (siehe Abschnitt 3.2.2.2) und zum anderen die Stringsuche (siehe
Abschnitt 3.2.1). Zugunsten des kleineren Speicheraufwandes wird nicht jedes Wort mit
seiner exakten Position indiziert, sondern nur Verweise auf Speicherblöcke, in denen
sich das jeweilige Wort befindet. Die Unterteilung der Datensammlung in maximal
256 Speicherblöcke wird so vorgenommen, daß jeder Block inetwa die gleiche Größe
aufweist. Kommt ein Wort in einem Block mehrmals vor, so enthält der Index für
dieses Wort nur einen Verweis auf den Block. [MW93]
9
http://glimpse.cs.arizona.edu/
38
Die Indizierung geht außerordentlich rasch vonstatten (siehe Abschnitt 3.3.4), eine
Ermittlung von statistischen Kennzahlen für ein späteres Ranking der Suchergebnisse wird nicht durchgeführt. Zur Beschleunigung kann Glimpse zusätzlich vorhandenen
Hauptspeicher hervorragend ausnützen. Optional werden die Dateien vor der Indizierung geprüft, ob sie tatsächlich Text enthalten. Eine explizite Hinzunahme bzw. Ausschluß einzelner Dateien ist bei der Indizierung ebenfalls durchführbar. Bezüglich der
Indexgröße hat man die Wahl zwischen tiny (2-3 % der Datenbankgröße), small (78 %) oder medium (20-30 %), wobei ein größerer Index gleichbedeutend mit kleineren
Speicherblöcken und schnellerer Suche ist. Eine Stopliste kann während der Indizierung
automatisch erstellt werden, je nach gewählter Indexgröße gelten andere Kriterien zur
Aufnahme eines Wortes in die Liste, z.B. tiny (keine Stopworte, alles wird indiziert),
small (Wort muß in mehr als k % aller Dateien vorkommen, k ist selbst definierbar),
medium (Wort kommt pro MB öfter als k mal vor, k ist selbst definierbar). [MW93]
Bei der Suche wird zunächst der Index inspiziert, man erhält eine Liste von Blöcken,
die noch genauer durchgesehen werden müssen. Die Suche im Index und auch jene in
den Blöcken erfolgt mit Hilfe von agrep, einer verallgemeinerten Variante des UNIXTools grep zur Stringsuche. agrep ist ein überaus mächtiges Suchinstrument, das neben
den verbreiteten Funktionalitäten, wie Boolsche Suche oder Wildcards, auch speziellere
Merkmale aufweist. Eines davon ist die Misspelling Tolerance zur Suche nach Stringmustern, die eine definierbare Anzahl von Rechtschreibfehlern aufweisen dürfen. Diese
können ihre Ursache beispielsweise im Einfügen, Fehlen oder Vertauschen von einzelnen
Buchstaben haben. Weiters eröffnen reguläre Ausdrücke zahlreiche Suchmöglichkeiten,
z.B. über Buchstabenmengen, über Zahlenbereiche oder den selektiven Ausschluß einzelner Zeichen. [MW93]
Das hauptsächliche Handicap von Glimpse ist die Suchperformance (siehe Abschnitt 3.3.4). Für große Datensammlungen werden die einzelnen Speicherblöcke sehr
groß, wodurch sich die ”langsame” Stringsuche besonders stark auswirkt. Nachteilig ist
auch das Verhalten bei boolschen Verknüpfungen von in den Daten häufig auftretenden
Suchbegriffen. Hier wird im schlimmsten Fall die gesamte Datensammlung sequentiell
durchsucht, die Antwortzeit steigt dementsprechend stark an. Aus dem Blickwinkel des
xFIND-Projektes ist die bereits integrierte SOIF-Unterstützung besonders interessant.
Dadurch kann ohne jegliche Anpassung eine Suche in beliebigen Feldern, die durch
Attribute bezeichnet sind, durchgeführt werden.
3.3.3.2
39
Isearch
Dieses IR System wurde in Anlehnung an WAIS (Wide Area Information Servers, siehe
dazu Abschnitt 3.3.3.3) am CNIDR10 (Center for Networked Information Discovery and
Retrieval) entwickelt, wobei großer Wert auf einen modularen Aufbau gelegt wurde. Die
wichtigsten Komponenten sind:
• Isearch11 , das Kernstück zur Indizierung und Suche.
• Z39.50 Protocol Engine, zur Behandlung von präzisen Suchanfragen. Zusammen
mit Isearch ist diese Komponente im Isite-Paket frei verfügbar.
• Isearch-cgi, enthält Perl-Scripts zur Behandlung von Suchanfragen via HTMLFormular.
Wie schon bei Glimpse (siehe Abschnitt 3.3.3.1) gibt es bei der Indizierung einige
Optionen zur Optimierung, z.B. Einbeziehung von zusätzlichem Hauptspeicher. Die
Art und Weise, wie Isearch verschiedene Dokumentformate berücksichtigt, ist besonders interessant. Ein Dokumenttyp wird in einer C++ Klasse beschrieben, die Informationen über die Feldstruktur und das Ausgabeformat enthält. Klassen für einige
wichtige Dokumentformate werden mitgeliefert, eine Anpassung stellt keine Schwierigkeit dar. Ebenso können Klassen von Fremdanbietern (z.B. BSn München12 ) erworben
oder eigene Klassen entwickelt werden. [IS99]
Die Klassen ermöglichen eine einschränkende Suche in einzelnen Feldern, die im
Laufe der Indizierung als Unterkomponenten des jeweiligen Dokumentes erkannt und
vermerkt wurden. Für die Anzeige sind die Felder ebenfalls von Bedeutung, standardmäßig wird das Feld Brief Record ausgegeben, das je nach Dokumenttyp unterschiedliche Informationen enthält, z.B. bei HTML ist es der TITLE. Man kann aber ebenso
das Feld Full Record, d.h. das gesamte Dokument, oder eine beliebige Kombination anderer Felder ausgeben. Vor der Anzeige der Suchergebnisse erfolgt noch ein Ranking
der Dokumente zwischen den Werten 0 und 100, sowie eine absteigende Sortierung nach
diesen Werten. [IS99]
Die Architektur von Isearch beinhaltet Shells (z.B. Kommandozeilentools, GUI’s),
die Isearch-Library und die Dokumentklassen. Dieser modulare Aufbau ist natürlich ein
großer Vorteil für Projekte, die eine Anpassung an spezielle Gegebenheiten erfordern.
Neue Versionen der Isearch-Library können in eigenen Umgebungen jederzeit ältere
ersetzen, ohne dadurch bestehende Shells oder Dokumentklassen zu beeinflußen. [IS99]
In der Dokumentation wird eine Datenbankgröße bis ein Gigabyte angegeben, bis
zu der eine vernünftige Performance erwartet werden darf. Erwähnenswert ist auch,
daß unterschiedliche Dokumentformate in einem Index untergebracht werden können.
Das inkrementelle Update eines bestehenden Index wird nicht empfohlen, da es sehr
zeitaufwendig ist. [IS99]
10
http://www.cnidr.org/
http://www.etymon.com/Isearch/
12
http://www.bsn.com/
11
3.3.3.3
40
freeWAIS-sf
Dieses frei verfügbare IR System stammt von der Universität Dortmund und ist im
wesentlichen eine Weiterentwicklung des ursprünglichen WAIS (Wide Area Information
Servers). freeWAIS-sf13 wie auch WAIS enthalten Tools zur Indizierung, sowie Server
und Clients, die miteinander über ein TCP/IP-Netzwerk kommunizieren. Das dabei
verwendete zustandslose WAIS-Protokoll basiert auf dem Z39.50-88 Protokoll, einem
ANSI-Standard zum Retrieval bibliographischer Daten. [Mau96]
Die Besonderheit im Vergleich zu anderen IR Systemen ist die Unterstützung eines Relevanz-Feedbacks, um ausgehend von bereits erzielten Suchergebnissen weitere
relevante Dokumente zu finden. [Mau96]
3.3.3.4
Smart
Hierbei handelt es sich um einen Klassiker unter den IR Systemen. Smart14 (System
for Manipulating And Retrieving Text) wurde an der Cornell University entwickelt
und realisiert ein Vektorraummodell (siehe Abschnitt 3.2.1). Die Hauptintention war
es, einen Rahmen zur wissenschaftlichen Untersuchung von IR Verfahren zu schaffen.
Aufgrunddessen ist Smart einerseits sehr flexibel, andererseits ist es für keine bestimmte
Verwendung optimiert. Bei der Implementierung wurde vorallem darauf geachtet, daß
alle wichtigen IR Algorithmen integriert werden und möglichst flexibel arbeiten. Auf
die Indizier- und Suchperformance wurde weniger Wert gelegt. [SMA99]
Das wichtigste Merkmal von Smart ist das Keyword Weighting, d.i. die relative Gewichtung von Worten innerhalb der Dokumente. Die Gewichtung kann auf eine Vielzahl
von Arten erfolgen, die z.B. auf Worthäufigkeiten und/oder -verteilungen basieren. Die
derart berechneten Kennwerte erlauben die Bestimmung der Ähnlichkeit zwischen den
Dokumenten bzw. zwischen der Suchanfrage und den Dokumenten. [SMA99]
Insgesamt bietet Smart nach einer etwas aufwendigeren Einarbeitungsphase viele Experimentiermöglichkeiten. Ein praktischer Einsatz ist in beschränktem Umfang
ebenfalls möglich, allerdings sollte die zu indizierende Datensammlung mehrere 100
MB nicht überschreiten.
3.3.3.5
Zebra
Der Zebra-Server15 der dänischen Index Data verfügt über eine Z39.50-Schnittstelle,
ein Zugriff auf den Index ist mit jedem beliebigen Z39.50-Client möglich. Bei der Indizierung werden aufgrund des Dokumenttyps die im Dokument vorhandenen Felder
erkannt und getrennt vermerkt. Es werden beliebig komplexe Dokumente unterstützt,
das Basisformat weist eine zu SGML ähnliche Syntax zur Beschreibung von strukturierten Daten auf. Die Indexdateien können auf mehrere Festplatten verteilt werden,
wodurch auch sehr große Datensammlungen handhabbar werden. [ZEB99]
13
http://ls6-www.informatik.uni-dortmund.de/ir/projects/freeWAIS-sf/
ftp://ftp.cs.cornell.edu/pub/smart/
15
14
3.3.3.6
41
Swish-e
Das Simple Web Indexing System for Humans - Enhanced16 wurde in diese Analyse stellvertretend für die unzähligen Website-Indizierer aufgenommen. Dementsprechend wird die Indizierung von HTML-Dokumenten in den Mittelpunkt gestellt, andere Dokumentformate sind nicht vorgesehen und können daher nur mit Hilfe einer
Volltextindizierung erfaßt werden. Neben der Indizierung lokaler Dokumente können
auch Dokumente via HTTP (Hypertext Transfer Protocol) angeliefert und indiziert
werden [SWI99]. Weitere Einzelheiten zu Swish-e und ähnlichen Website-Tools sind
in [BS99] nachzulesen.
3.3.3.7
Locus
Dieses IR System wird als Privatprojekt eines engagierten Entwicklers betrieben.
Der Anwendungsbereich von Locus17 beschränkt sich im Augenblick auf den lokalen
Desktop, da die Indizier- und Suchperformance (siehe Abschnitt 3.3.4) für große Datenmengen, wie sie in Internetapplikationen anfallen, nicht ausreicht.
3.3.3.8
Managing Gigabytes
MG18 ist ein IR System, daß auf Grundlage des gleichnamigen Buches [WMB94] erstellt
wurde. Der Schwerpunkt liegt, dem Namen entsprechend, in der Behandlung von sehr
großen Datenmengen. Erreicht wird dies durch Kompression des Index und der Daten.
Zu Administrations- und Kontrollzwecken erstellt MG umfangreiche Statistiken über
den Indexaufbau und die Indexgröße. Zur Überwachung der Performance sind auch
Funktionen vorhanden, die z.B. die Antwortzeit für Suchanfragen messen. [WMB94]
In der bisherigen Analyse wurde ein Überblick über die Leistungen gängiger IR Systeme
geboten. Im folgenden Abschnitt soll nun das Indizier- und Suchverhalten der Produkte
anhand eines konkreten Testdatenbestandes getestet werden.
16
http://www.locus.cz/locus/
18
17
3.3.4
Performance
3.3.4.1
Allgemeine Betrachtungen
42
Bei Performanceuntersuchungen muß man eine klare Trennung zwischen Indizierung
und Suche durchführen. Die Suchperformance spielt im täglichen Umgang mit dem
IR System eine wichtige Rolle und beeinflußt die Interaktion mit dem Benutzer, eine schnelle Suche ist demnach wesentlich wichtiger als das schnelle Indizieren. Die
Performance ist auch der Hauptgrund dafür, daß für ein großes Suchsystem spezielle
IR Verfahren gegenüber traditionellen Datenbanken bevorzugt werden sollten [AV99].
Nachfolgend werden Faktoren diskutiert, die zu einer Steigerung der Performance beitragen können.
Speicherort: Die Datenbank und der Index sollten auf getrennten Festplatten gespeichert werden, dadurch minimiert sich die Bewegung der Schreib-/Leseköpfe. Es
reicht nicht aus, sie in unterschiedlichen Partitionen auf derselben Platte zu halten, dieses Vorgehen verschlechtert die Performance sogar, da i.a. abwechselnd
Zugriffe auf den Index und die Daten erfolgen. [IS99]
Bei RAID-Systemen (Redundant Array of Independent Disks) hat man die Wahl
zwischen ”schnellerem Streaming” (Auslesen oder Schreiben zusammenhängender Datenbereiche) oder ”mehr I/O-Operationen pro Sekunde”. Der zweiten Alternative ist aufgrund der Arbeitsweise eines IR Systems der Vorzug zu geben,
es handelt sich nämlich um kurze Streamphasen bei der Suche im Index und
lange Phasen, in denen ”zufällige” Positionen in der Datenbank angesteuert werden. [IS99]
Hauptspeicher: Je mehr davon vorhanden ist, umso günstiger wirkt sich dies auf
die Geschwindigkeit des Indizierungsvorganges aus. Nach Möglichkeit sollte die
Indizierung im Einbenutzerbetrieb und unter geringer Speicherbelastung durch
andere Prozesse erfolgen. Beim Suchen hat die Größe des Hauptspeichers Einfluß
auf die benötigte Zeit zur Erstellung, Bearbeitung und Sortierung von großen
Ergebnismengen. [IS99]
3.3.4.2
Beschreibung der Testumgebung
Um sich einen praktischen Eindruck der hier untersuchten IR Systeme zu verschaffen,
wurden diese lokal installiert und getestet.
Als Testplattform diente ein Personal Computer mit Intel Pentium II Prozessor,
266 MHz Taktfrequenz, 64 MB Hauptspeicher und dem Betriebssystem SuSE Linux
6.0. Um die Vergleichbarkeit der Ergebnisse zu gewährleisten, wurden alle Tests auf
Terminalebene im Einbenutzerbetrieb durchgeführt, d.h. weder XWindows noch andere nicht benötigte Prozesse wurden gestartet. Der Testdatensatz beinhaltet 10666
SOIF-Objekte (eine Datei je Objekt), die mittels eines Harvest-Gatherer aus dem Datenbestand des Steiermarkhauptservers19 generiert wurden. Die Gesamtgröße des Testdatensatzes beläuft sich auf 27,56 Megabyte.
19
http://www.steiermark.at/
43
Da Verity Search ’97 nur für die Betriebssysteme UNIX und Windows NT verfügbar
ist, nicht aber für Linux, wurde es in einem gesonderten Testlauf mit Glimpse verglichen. Als Testplattform diente hier eine Workstation mit Alpha AXP Prozessor, 500
MHz Taktfrequenz, 1 GB Hauptspeicher und Digital UNIX Betriebssystem (früher
DEC OSF/1). Der Testdatensatz wurde für diesen Vergleich auf 7996 SOIF-Objekte
gekürzt, die Gesamtgröße reduziert sich auf 23,39 Megabyte.
3.3.4.3
Indizieren
Wie bereits aus der Gegenüberstellung in Tabelle 3.2 ersichtlich, unterscheiden sich
die Produkte in zahlreichen Punkten voneinander. Für die Tests wurden die Optionen
derart gewählt, daß sich jeweils ein möglichst ähnlicher und vorallem kompletter Index
ergibt. Dazu wurden folgende Rahmenbedingungen festgelegt:
• Bis zu 10 MB zusätzlicher Hauptspeicher zur Beschleunigung des Indizierungsvorganges werden zur Verfügung gestellt.
• Der Dateityp der zu indizierenden Daten ist von vornherein bekannt. Die SOIFObjekte enthalten nur ASCII-Zeichen, daher werden etwaige Typprüfungen deaktiviert.
• Es ist ausreichend Plattenspeicher vorhanden, sodaß man keiner Einschränkung
hinsichtlich der zu indizierenden Daten (z.B. Nummern, Datumsangaben) unterliegt.
• Es erfolgt eine Volltextindizierung, da diese standardmäßig von allen Produkten
verwendet wird. Die Indizierung aufgrund einer definierten Feldstruktur der Daten, z.B. SOIF mit seinen Attribut-Werte-Paaren, wird nicht durchgeführt, da sie
erst nach einer teilweise recht aufwendigen Anpassung des jeweiligen Produktes
verfügbar ist.
Zur Beurteilung der Ausführungseffizienz wird mittels des UNIX-Kommandos time
die benötigte Gesamtzeit (elapsed time) zur Indizierung gemessen. Die Datenbankgröße
ergibt sich als Summe der Einzelgrößen aller zu indizierenden Dateien und wird in MB
angegeben. Daraus läßt sich schließlich mit Gleichung (3.4) die erzielte Indexrate in
MB/min eines IR Systems ermitteln.
Indexrate =
Datenbankgröße
Gesamtzeit
(3.4)
Die Speichereffizienz wird durch die Indexgröße in % der Datenbankgröße beschrieben, dabei werden alle bei der Indizierung generierten Hilfsstrukturen in die Berechnung
miteinbezogen.
44
In den Tabellen 3.3 und 3.4 sind die gesammelten Testergebnisse aufgelistet.
IR System
Glimpse
Isearch
Zebra
Swish-e
Locus
Gesamtzeit
[min:sec]
01:43
02:45
03:17
58:43
14:25
Indexrate
[MB/min]
16,05
10,02
8,39
0,47
1,91
Indexgröße
[%]
44,19
109,38
68,99
37,34
80,93
Einstellungen
glimpseindex -b -E -B -n -s -M 10 path
Iindex -d indexname -r -m 10 path
zebraidx -t text update path
swish-e -c configfile
cruncher
Tabelle 3.3: Performance der Indizierung unter LINUX
Wie zu erkennen ist, erreicht Glimpse die beste Indexrate, Isearch und Zebra liegen ebenfalls akzeptabel etwas dahinter. Die beiden anderen IR Systeme sind dagegen
schon deutlich abgeschlagen. Bei Glimpse hat man die Wahl zwischen drei Indexarten, für den Test wurde die Option medium gewählt, die eine möglichst schnelle Suche
erlaubt, gleichzeitig aber mehr Speicherplatz benötigt (siehe Abschnitt 3.3.3.1). Die resultierende Indexgröße ist gegenüber jener von Zebra und Locus dennoch relativ gering.
Die Indexgröße von Isearch fällt etwas aus dem Rahmen, schon aus Kostengründen ist
ein Index, der über die Größe der eigentlichen Daten hinausgeht, als problematisch zu
erachten. Man muß bei den Vergleichen jedoch immer im Auge behalten, daß bestimmte Funktionalitäten (z.B. das Relevanz-Ranking) zusätzlichen Zeit- und Platzaufwand
bei der Indizierung erfordern.
IR System
Glimpse
Verity
Gesamtzeit
[min:sec]
00:41
01:25
Indexrate
[MB/min]
32,64
15,74
Indexgröße
[%]
48,74
81,61
Einstellungen
glimpseindex -b -E -B -n -s -M 10 path
mkdemo -collection name -insert @filelist
Tabelle 3.4: Performance der Indizierung unter UNIX
Wiederum zeigt Glimpse eine sehr gute Performance. Die im Vergleich schwächeren Werte von Verity erklären sich aus der aufwendigeren Aufbereitung, die für das
Relevanz-Ranking und andere Funktionalitäten (siehe dazu Abschnitt 3.3.5.4) durchzuführen ist.
Neben der Performance muß man sich auch Gedanken darüber machen, wie man die
Indizierung bewerkstelligt, ohne dadurch den laufenden Betrieb zu stören. Einige IR
Systeme arbeiten mit Threads (siehe auch Abschnitt 3.3.5), gleichzeitiges Indizieren
und Suchen stellt hier kein Problem dar. Ist dies nicht der Fall, dann besteht eine
einfache Methode darin, z.B. jede Nacht ein Shellskript zu starten, das eine Kopie der
aktuellen Datenbank (auf einer anderen Festplatte) anlegt, darauf einen Index generiert
und schließlich die alten Dateien durch die neuen ersetzt. Durch dieses Vorgehen verliert
die Geschwindigkeit der Indizierung an Bedeutung. [IS99]
3.3.4.4
45
Suchen
Analog zum Indizieren muß auch hier eine gemeinsame Basis für die Performancetests
gefunden werden. Im ersten Schritt erfolgt eine Festlegung der getesteten Suchfunktionalitäten, hier wurde als Grundlage die einfache Suche des Steiermarkservers herangezogen. Diese umfaßt eine einfache Wortsuche, boolsche Suche (AND, OR), Verwendung von Wildcards, sowie die Suche in bestimmten Feldern (TITLE, TEXT, KEYWORD).
Als zweite Maßnahme wurde eine Abstufung aufgrund der Anzahl der Suchergebnisse durchgeführt, die Einteilung erfolgt in kein Treffer, wenige Treffer (ca. 20), einige
Treffer (ca. 100), viele Treffer (ca. 500) und sehr viele Treffer (größer 5000).
Aufgrund dieser Bedingungen wurde eine Menge von Anfragen erstellt, die eine
Messung der Suchperformance erlaubt. Die Tabellen 3.5 und 3.6 listen die Antwortzeiten (elapsed time) und die Anzahl der Treffer (Hits) auf. Hier können auch mehr
Treffer erzielt werden als ursprünglich am Steiermarkserver, die Ursache hierfür liegt
in den unterschiedlichen Indizierungsvorschriften der einzelnen Produkte.
[Hits]
Glimpse
[sec]
[Hits]
Isearch
[sec]
[Hits]
Zebra
[Hits]
Swish-e
[sec]
[Hits]
Locus
[sec]
[Hits]
einfache Wortsuche
iicm
diagonale
loipersdorf
schloßberg
weiz
leibnitz
graz
steiermark
0
0
17
28
86
144
573
6876
0,13
0,07
0,51
0,55
1,52
0,98
4,08
31,70
1
0
22
27
121
147
656
10634
3,03
1,80
2,20
1,30
1,94
1,98
3,42
61,33
1
0
25
27
124
150
679
10666
1
0
25
65
124
150
679
10666
0,14
0,23
0,24
0,16
0,27
0,26
0,76
-
1
0
25
27
124
150
679
-
0,93
0,08
2,19
1,96
4,22
5,24
22,75
147,73
0
0
15
23
71
130
543
6650
boolsche Suche
musik AND jazz
thomas AND muster
bank OR versicherung
0
4
19
0,14
0,15
0,17
1
3
22
1,69
1,66
0,24
1
3
22
0
3
22
0,20
0,19
0,17
1
3
21
0,21
0,85
0,71
0
3
15
25
284
1665
0,26
0,38
2,46
18
101
840
1,23
1,49
3,29
38
325
1600
23
317
1629
1,03
13,51
-
38
325
-
-
-
3
29
23
0,13
0,61
0,38
2
29
16
Anfrage
Wildcards
ski*
auto*
landes*
Feldsuche
t:wein
b:joanneum
k:forschung*
Tabelle 3.5: Performance der Suche unter LINUX
Die freibleibenden Felder in der Tabelle haben unterschiedliche Ursachen. Eine Feldsuche wurde nur mit Glimpse durchgeführt, da hier das SOIF-Format bereits unterstützt
wird. Zebra wurde mit Hilfe eines mitgelieferten Z39.50 Clients getestet, eine Zeitmessung war daher nicht möglich. Locus verfügt über keine Suchmöglichkeit mit Wildcards
und Swish-e klassifiziert den Suchbegriff bei zuvielen Suchergebnissen als nicht relevant.
Bei der Antwortzeit schneiden Swish-e und Glimpse sehr gut ab. Isearch hat vor
der Ausgabe ein Ranking und eine Sortierung zu erledigen, was die Zeit natürlich stark
mitbeeinflußt. Bei Locus ist ein starker Anstieg der Suchzeit mit zunehmender Trefferanzahl zu beobachten. Hier spielt auch die aufwendige Bearbeitung der Suchergeb-
46
nisse eine Rolle, es werden ANSI Escape-Sequenzen zum Highlighting der Suchbegriffe
eingefügt. Die Trefferanzahl unterscheidet sich bei allen Produkten nur unwesentlich.
Glimpse
[sec]
[Hits]
Verity
[sec]
[Hits]
einfache Wortsuche
iicm
diagonale
loipersdorf
schloßberg
weiz
leibnitz
graz
steiermark
0,52
0,10
0,12
0,11
0,13
0,15
0,33
11,14
1
0
16
18
85
106
491
7964
0,17
0,12
0,37
0,28
0,46
0,22
0,22
0,35
0
0
16
18
65
94
449
7711
boolsche Suche
musik AND jazz
thomas AND muster
bank OR versicherung
0,16
0,10
0,14
1
2
16
0,22
0,16
0,17
1
2
15
Wildcards
ski*
auto*
landes*
0,10
0,13
0,32
11
67
616
0,14
0,18
0,22
25
235
1190
Feldsuche
t:wein
b:joanneum
k:forschung*
0,07
0,19
0,13
1
22
12
Anfrage
Tabelle 3.6: Performance der Suche unter UNIX
Hinsichtlich des Antwortzeitverhaltens unterscheiden sich diese beiden IR Systeme
nur geringfügig. Beide zeigen eine sehr gute Performance, durchschnittlich betrachtet
erkennt man im Test leichte Vorteile zugunsten Glimpse. Ein wesentlicher Punkt, der
jedoch für Verity spricht, ist das gleichbleibende Anwortzeitverhalten bei kleinen und
auch großen Ergebnismengen (z.B. Vergleich der Suche nach loipersdorf und nach
steiermark).
Ebenso wie das bereits bekannte Verity SDK werden zahlreiche weitere IR Entwicklerpakete in zunehmendem Maße zur Einbindung von Suchfunktionen in bestehende
Anwendungen oder zur Realisierung völlig neuer IR Konzepte herangezogen. Einige
dieser SDK’s sollen im folgenden Abschnitt erläutert werden.
3.3.5
47
Search Development Kits
Neben den unzähligen IR Systemen, die nach einer geringfügigen Anpassung sofort
einsatzbereit sind, werden vorallem im kommerziellen Umfeld etliche IR Entwicklungspakete (SDK, Search Development Kits) angeboten. Diese ermöglichen die Erstellung
von maßgeschneiderten IR Lösungen oder auch die Einbindung moderner IR Funktionalitäten in bestehende Anwendungen. SDK’s verfügen i.a. über eine sehr ähnliche
Gliederung: [AV99]
• Den Kernbereich bilden Engines, die sich um die Indizierung, Suche und Suchergebnisse kümmern. Diese Module sind nach außen hin abgeschlossen, der
Entwickler hat keine Möglichkeit, auf das Innere Einfluß zu nehmen. Im Lieferumfang sind sie als Libraries enthalten, die alle Funktionen zum Betrieb eines
IR Systems umfassen. Die Funktionen werden entweder beim Compilieren der
Applikation oder erst zur Laufzeit (Dynamic Link Library oder Shared Library)
eingebunden.
• API’s (Application Programming Interfaces) dienen als Schnittstelle zu den Engines, die Steuerung des IR Systems erfolgt über Funktionsaufrufe. Zumeist wird
eine thematische Einteilung der API’s vorgenommen, z.B. in API’s zur Indexverwaltung, zur Suche oder zur Ergebnisaufbereitung. Sie basieren auf internationalen Standards, wodurch die Entwicklungszeiten verkürzt werden und eine
längerfristige Einsetzbarkeit der Applikationen sichergestellt ist.
• Begleitend erhält man eine sehr ausführliche Dokumentation und Programmbeispiele, die als Grundlage für eigene Entwicklungen verwendet werden können.
Bei kommerziellen Paketen wird zudem ein umfangreicher technischer Support
geleistet.
Für die nachfolgenden Analysen wurden als Informationsquellen die Produktbeschreibungen der Anbieter verwendet. Für jedes SDK werden die wichtigsten Merkmale
in Kurzform aufgelistet, die Besonderheiten werden detailliert beschrieben.
3.3.5.1
Callable Personal Librarian
CPL ist ein Entwicklerpaket der Firma PLS (Personal Library Software), die ihrerseits
kürzlich vom weltweit größten Informationsprovider AOL20 (America Online) übernommen wurde. AOL integriert schon seit geraumer Zeit auf CPL basierende IR Mechanismen in seiner Zugangssoftware. Nun wurde CPL zur freien Verfügung gestellt,
Versionen für verschiedene Plattformen stehen zum Download bereit. Die einzige Verpflichtung im Zusammenhang mit eigenen Anwendungen ist die Einbindung des Hinweises ”Powered by PLS”und eines Verweises auf AOL, Lizenzgebühren oder dergleichen
fallen nicht an. [CPL99]
20
http://www.aol.com/
48
In der nachfolgenden Tabelle 3.7 werden die wesentlichen Merkmale von CPL in Kurzform aufgelistet:
URL
Indizierung
Suche
Ausgabe
Sonstiges
Umgebung
Anwendungen
http://www.pls.com/cpl.htm
Stemming (Englisch, Französisch, Deutsch, Italienisch, Spanisch,
Japanisch), Stopliste, inkrementelles Update, Volltext,
versch. Formate (HTML,PDF,news/mail)
Boolean, Proximity, Wildcards, selbstdefinierter Thesaurus, Fielded,
Term Expansion, Bereichssuche (größer, kleiner, gleich, ungleich),
Fuzzy, Misspelling Tolerance, Query-by-Example
Relevanz-Ranking, automatische Inhaltszusammenfassung, feldbasierende
Sortierung
Unicode, spezielle Funktionen für die deutsche Sprache
kostenlos, kein Support
UNIX, NT, C-API
z.B. in AOL-Zugangssoftware integriert
Tabelle 3.7: Übersicht der Leistungen von CPL (Quellen: [CPL99] [CPG99])
CPL unterstützt die Aufteilung von Dokumentinhalten in Felder durch eine Record
Class Architektur, einige Dokumentformate sind bereits definiert, für eigene Zwecke
können selbst Record Classes erstellt werden. Die Rule-Based Tokenization erlaubt
eine Indizierung von Sonderzeichen oder Zeichensequenzen aufgrund selbst festgelegter Regeln. Um eine bessere Performance zu erreichen, können auch mehrere Dokumente in einer Datei untergebracht werden, man bildet sogenannte Multi-RecordContainer. [CPG99]
Eine schnellere Suche kann durch das Index Partitioning erzielt werden, dabei wird
das Wörterbuch vom Rest des Index getrennt und auf eine schnellere Festplatte ausgelagert. Die Suche und Administration kann über verschiedene Plattformen hinweg
erfolgen (Interoperable Database) und es können mehrere Datenbanken gleichzeitig
durchsucht werden (Virtual Database Searching). In diesem Fall erfolgt eine Zusammenführung der Ergebnisse, dies beinhaltet auch die Normalisierung von Relevanzwerten. [CPG99]
Als Suchhilfe kann das Directory Lookup genutzt werden, der Benutzer kann die im
Index erfaßten Worte durchsehen und für die Suche auswählen. Bei der Abarbeitung
der Suchanfrage erfolgt eine Query Expansion. Dabei wird eine Liste von Begriffen
generiert, die mit den Suchbegriffen in Beziehung stehen. Worte stehen dann miteinander in Beziehung, wenn sie in den Dokumenten der Datensammlung öfter bzw. zu
einem bestimmten Grad gemeinsam auftreten. Eine solche Liste kann auch dem Benutzer zur Auswahl angeboten werden, CPL führt die Auswahl selbst durch. Danach
wird mit den Suchbegriffen und den signifikantesten Worten aus der Liste eine Suche
durchgeführt. [CPG99]
Beim Query-by-Example wird sinngemäß nach allen statistisch signifikanten Worten
eines Dokumentes gesucht, d.h. ausgehend von einem interessanten Dokument können
weitere gefunden werden. Eine Fuzzy-Suche ist ebenfalls möglich, man kann festlegen,
wieviele Buchstaben in einem Suchbegriff fix stehenbleiben sollen. Die Sensitivität,
die für die Performance dieser Funktion ausschlaggebend ist, kann vom Administrator
festgelegt werden. [CPG99]
Für die Ergebnisanzeige ist die automatische Inhaltszusammenfassung der Doku-
49
mente sehr informativ. Darüber, ob hier eine Berücksichtigung verschiedener Sprachen
stattfindet und welche Mechanismen für die Zusammenfassung zur Anwendung gelangen, gibt die Dokumentation des SDK keine erschöpfende Auskunft. Eine weitere nützliche Funktion für die Darstellung der Suchergebnisse ist die feldbasierende Sortierung,
sie kann auf- oder absteigend nach einem oder mehreren Feldern erfolgen. [CPG99]
3.3.5.2
Findex
Das Full Text Indexing und Retrieval Toolkit von Lextek betont vorallem die Skalierbarkeit. Es eignet sich sowohl für kleinere Systeme mit wenig Daten und geringer
Hauptspeicherausstattung, als auch für Anwendungen, die auf Datenbeständen bis zu
ein Terabyte operieren. Tabelle 3.8 faßt die wichtigsten Kenndaten dieses Paketes zusammen [FIN99]:
URL
Indizierung
Suche
Sonstiges
Umgebung
Anwendungen
http://www.1source.com/~pollarda/findex/
auf Dokument- und Wortbasis, Stemming (Englisch),
inkrementelles Update, Indexkompression
Indexgröße 8-20% (Dokumentbasis), 45 % (Wortbasis)
Boolean, Phrasen, Proximity, Wildcards, Bereichssuche, Suche
in binären Daten, Suchhilfen (Zugriff auf Wortliste)
Unicode, EBCDIC, ASCII, ANSI, ...
kommerziell, techn. Support
UNIX, NT, ANSI C++
z.B. Management der internen Dokumentation bei MOTOROLA
Tabelle 3.8: Aufstellung der von Findex angebotenen Merkmale (Quelle: [FIN99])
Die Granularität der Indizierung kann auf Dokument- oder auf Wortebene gewählt
werden. Erstere bringt den Vorteil eines geringeren Platzbedarfes, während zweitere die
Möglichkeit einer schnellen Phrasen- und Umgebungssuche eröffnet. Indizes können bei
Bedarf auch auf mehrere Festplatten und Computer verteilt werden, der Platzbedarf
wird durch Kompression des Index aber ohnehin minimal gehalten, ein positiver Nebeneffekt davon ist die beschleunigte Suche. [FIN99]
Bei der Suche wird ein firmeneigenes Verfahren eingesetzt, daß einen Suchbegriff in
nur einem Diskzugriff (im Durchschnitt) lokalisieren kann, dies gilt auch für große Datenbestände. Eine Besonderheit ist die Suche in binären Daten, die unter anderem zur
Handhabung von verschiedenen Zeichensätzen verwendet werden kann. Weiters kann
die bei der Indizierung aufgebaute Wortliste untersucht und ausgegeben werden. Mit
diesen Funktionen sind Hilfestellungen für den Benutzer vorstellbar, z.B. könnte man
die Worte anzeigen, die mit einem bestimmten Buchstaben beginnen und eine interaktive Auswahl anbieten. Neben den zahlreich unterstützten Zeichensätzen sind auch
Funktionen zur Umwandlung von Unicode-Zeichen enthalten, beispielsweise zur Entfernung von Akzenten oder zur Konvertierung von Groß- in Kleinschreibung. [FIN99]
3.3.5.3
50
AltaVista Search Developers Kit
AltaVista ist jedem Internetbenutzer als Einstiegspunkt ins WWW geläufig, die dahinterstehende Technologie findet man in diesem SDK wieder. Man profitiert in eigenen
Anwendungen von der intuitiven und allgemein bekannten Suchsyntax und von der
hervorragenden Skalierbarkeit. [AV99]
In nachstehender Tabelle 3.9 werden die Leistungen dieses Entwicklerpaketes in kompakter Form aufgelistet:
URL
Indizierung
Suche
Sonstiges
Umgebung
Anwendungen
http://altavista.software.digital.com/search/avsdk97/index.asp
auf Dokument-, Wort- oder Feldbasis, inkrementelles Update,
numerische Daten
Indexgröße 10% (Dokumentbasis), 30 % (Wortbasis)
Boolean, Phrasen, Proximity, Wildcards (auch ”?”), Bereichssuche
(nach Datum), Fielded
Unicode (im speziellen UTF-8 Support)
kommerziell, techn. Support, Evaluation Copy
UNIX, NT, Visual Basic, C++, Java
z.B. beim FBI (Oracle Datenbank mit 250 Mio. Dokumenten)
Tabelle 3.9: Daten und Fakten zum AltaVista SDK (Quelle: [AV99])
Durch die auf Threads aufbauende Architektur kann der Index jederzeit upgedatet werden, während weiterhin Benutzeranfragen beantwortet werden. Die Indizierung
wird dadurch beschleunigt, daß neue Indexinformationen zunächst nur im Hauptspeicher untergebracht werden, erst wenn die Applikation die Anweisung dazu gibt, wird
der neu hinzugekommene Indexteil in eine Datei geschrieben. Diese Dateien werden
dann vorzugsweise in Zeiten mit geringer Systembelastung, z.B. jede Nacht, mit dem
bestehenden Index verschmolzen. [AV99]
Zur Indizierung von strukturierten Daten, das beinhaltet auch herkömmliche Datenbanken, werden selbst definierbare Filter vorgeschaltet, die den Inhalt eines Dokumentes
prüfen und aufbereiten. Auf diese Weise kann man einzelne Felder oder Feldgruppen indizieren und für die Suchanfragen verfügbar machen. Eine Besonderheit von AltaVista
ist das Verhalten bei Groß- und Kleinschreibung. Enthält ein Wort Großbuchstaben,
so wird es sowohl in seiner ursprünglichen Schreibweise als auch in Kleinschreibung in
den Index aufgenommen. Bei der Suche hat man den Vorteil, daß Worte mit Großbuchstaben immer exakt gesucht werden, bei der Verwendung von Kleinbuchstaben kann
man alle Ergebnisse erreichen. [AV99]
Interessant ist die Möglichkeit, bereits bei der Indizierung Relevanzwerte für Begriffe
angeben zu können, die beim Ranking dann berücksichtigt werden. Der Benutzer kann
bei der Suche auch Worte angeben, nach denen das Ranking explizit erfolgen soll. Das
Ranking basiert auf einem Gewichtswert, der jedem Wort der Suchanfrage zugewiesen
wird, und einer Relevanzbeurteilung jedes Dokumentes, das die Suchanfrage erfüllt.
Das Gewicht eines Wortes wird durch seine Auftrittshäufigkeit im gesamten Index bestimmt, ein weniger häufig auftretendes Wort wird dabei als relevanter erachtet und
erhält ein höheres Gewicht als ein Wort, das sehr häufig auftritt. Die Relevanzbeurteilung eines Dokumentes erfolgt nun unter Berücksichtigung der Anzahl der enthaltenen
Suchwörter und ihrer dazugehörigen Wortgewichte. Das Dokument mit den meisten
übereinstimmenden Suchwörtern und den höchsten Gewichtswerten weist somit die
51
höchste Relevanz auf. Die Position des Wortes und die Häufigkeit seines Auftretens
innerhalb eines einzelnen Dokumentes hat wenig Einfluß auf das Ranking. [AV99]
Besonders bemerkenswert ist die Tatsache, daß AltaVista als einziges Produkt dieser Analyse in der Lage ist, im UTF-8 Format vorliegende Unicode-Texte direkt zu
indizieren. Die Suche unterstützt momentan nur Latin-1, soll aber in künftigen Versionen ebenfalls auf Unicode ausgeweitet werden. Nützliche Merkmale sind weiters
die Unterstützung des ”?” Platzhalters und die Möglichkeit, bestimmte Suchanfragen
periodisch durchzuführen, wobei nur neu hinzugekommene Ergebnisse angezeigt werden. [AV99]
Wenngleich ein vollständiges Java-API erst in Aussicht gestellt wird, so sind zumindest Beispielklassen vorhanden, die eine Schnittstelle zum C-API bilden. Zu Evaluierungszwecken kann eine Vollversion des SDK via Internet heruntergeladen werden.
Für die Entwicklungsphase ist eine Development Lizenz vorgesehen, für kommerzielle Zwecke gibt es verschiedene Runtime Lizenzen, die interessanterweise mit der zu
indizierenden Datenmenge (in Gigabyte) gekoppelt werden. [AV99]
3.3.5.4
Verity Developers Kit
Hierbei handelt es sich um ein sehr vielseitiges Produkt der renommierten IR Firma
Verity. Aufgrund der zahlreichen flexiblen und innovativen Indizier- und Suchverfahren
hat dieses Paket Eingang in namhafte Anwendungen gefunden. Beispielsweise wird es
zur Realisierung der IR Funktionalität des Hyperwave Informationsservers21 eingesetzt.
Tabelle 3.10 zeigt alles Wissenswerte über das Entwicklerpaket im Überblick:
URL
Indizierung
Suche
Ausgabe
Sonstiges
Umgebung
Anwendungen
http://www.verity.com/products/devokit/index.html
Stemming, inkrementelles Update, Volltext, Metadaten, über
200 Dokumentformate
Boolean, Proximity, Fielded, selbst definierbarer Thesaurus,
Bereichssuche, Query Expansion, Konzeptsuche, Clustering,
Fuzzy, Query-by-Example u.v.a.m.
Relevanz-Ranking, automatische Inhaltszusammenfassung, Term
Highlighting
Unicode, kommerziell, techn. Support
UNIX, NT, C, aber auch C++, Java und Perl
bereits in ca. 300 Produkten integriert
Tabelle 3.10: Liste der Merkmale des Verity Developer’s Kit (Quelle: [VTY99])
Vom Prinzip her wird die Struktur und der Inhalt der vorliegenden Dokumente extrahiert und in einer sogenannten Verity Collection indiziert. Diese Collection enthält
für jedes Dokument drei Arten von Information: eine Wortliste, Metadaten und die
URL (oder die Speicheradresse im lokalen Dateisystem). Suchanfragen werden ausschließlich unter Einbeziehung dieser Collection beantwortet. Grundsätzlich handelt es
sich bei einer Collection lediglich um eine proprietäre Bezeichnung für einen traditionellen Volltextindex. [VTY99]
Das Verity Developers Kit bietet eine Vielzahl von Verfahren, die zur Auffindung
von relevanten Informationen beitragen. Es erfolgt eine automatische Erweiterung der
21
http://www.hyperwave.com/
52
Suchanfrage unter Einbeziehung eines Thesaurus, Stemming und einer linguistischen
Analyse. Daraus ergeben sich aussagekräftige Fragestellungen und folglich passendere
Ergebnisse. Ein nützliches Merkmal ist Query-by-Example, hier wird ein von einer vorangegangenen Suche geliefertes Dokument in eine neue Suchanfrage umgewandelt, um
ähnliche Dokumente zu finden. Die Verarbeitung von Multibyte-Zeichensätzen ist durch
eine flexible Plug-in Architektur vorgesehen, neben der schon realisierten UnicodeUnterstützung sind alle vorhandenen und zukünftigen Zeichensätze damit in eigene
Anwendungen integrierbar. Die Berücksichtigung der Zeichensätze bildet die Voraussetzung für sprachabhängige oder mehrsprachige Anwendungen. [VTY99]
Eine automatische Inhaltszusammenfassung wird als einfache Variante, die lediglich die ersten 400 Byte eines Dokumentes extrahiert, und als erweiterte Variante
angeboten. Zweitere bedient sich einer Reihe von Techniken, um gezielt Sätze und
Schlüsselwörter aus einem Dokument auszuwählen, die den Inhalt des Dokumentes repräsentieren. Ausgewertet werden beispielsweise die Wort- und Phrasenhäufigkeiten im
Dokument, das Auftreten von Schlüsselwörtern in Sätzen, die Position von Sätzen in
Absätzen und im gesamten Dokument. Darüberhinaus erfolgt eine lexikalische Analyse und es gelangen zusätzlich heuristische Methoden zur Anwendung. Inwieweit die
Inhaltszusammenfassung, wie auch das Stemming, für verschiedensprachige Texte anwendbar ist, konnte der Dokumentation von Verity nicht detailliert entnommen werden. [VTY99]
Mit Verity Topics kann man eigene Anwendungen mit einer Konzeptsuche ausstatten. Topics sind selbst definierbare Zuordnungsregeln von Dokumenten auf Konzepte,
auf diese Weise kann man Anfragemengen erstellen, die sich auf bestimmte Wissensbereiche beziehen. Topics für wichtige Wissensbereiche sind von zahlreichen Fremdanbietern erhältlich. [VTY99]
Verity bietet ein weiteres Paket zur Entwicklung von IR Systemen an, das Verity
K2 Toolkit. Es beinhaltet alle Vorzüge des Developers Kit, die Architektur unterscheidet sich jedoch wesentlich. Ein mehrschichtiges Modell von Clients, Server und Broker
verspricht eine lineare Skalierbarkeit, d.h. gleichbleibende Systemperformance bei steigender Datenmenge und Benutzeranzahl. Von Vorteil ist, daß verschiedenste Betriebssysteme und Hardware zusammenarbeiten können, ebenso können mehrere CPUs auf
einem Computer ausgenützt oder mehrere Computer zu einem leistungsfähigen Cluster
zusammengefaßt werden. [VTY99]
Durch konsequentes Multithreading ist das IR System jederzeit für Suchanfragen
verfügbar, selbst bei gleichzeitiger Indizierung oder Wartung. Die Architektur hat als
positiven Nebeneffekt eine Fehlertoleranz des Systems zur Folge, durch das Vorhandensein mehrerer Verarbeitungspfade kann man etwaige Fehler in Servern oder Brokern isolieren, ohne den laufenden Betrieb zu stören. Eine Remote-Überwachung und
-Administration des Systems ist ebenfalls vorgesehen. [VTY99]
3.3.5.5
53
Fulcrum SearchBuilder
Der Grundbaustein, auf den dieses SDK aufsetzt, ist der Fulcrum SearchServer, der
neben den bereits gewohnten IR Funktionen auch weitere Neuheiten aufweist. Eine
Übersicht der wichtigen Leistungen des Paketes enthält Tabelle 3.11:
URL
Indizierung
Suche
Ausgabe
Sonstiges
Umgebung
Anwendungen
http://www.fulcrum.com/english/products/sshome.htm
inkrementelles Update, versch. Formate (HTML, PDF etc.)
Boolean, Phrasen, Proximity, Wildcards, natürliche Sprache
(linguistische Analyse und Erweiterung), Intuitive Suche,
Suchhilfen
Relevanz-Ranking, Sortierung (nach Dokumentgröße, nach Autor,
LIFO, d.h. nach Datum zuletzt eingefügte Dokumente zuerst),
Term Highlighting, Dokumentviewer
Unicode, kommerziell, techn. Support
UNIX, NT, C, Visual Basic, Visual C++, Java,
API’s für ODBC und JDBC
in über 900 Firmen weltweit im Einsatz
Tabelle 3.11: Kurzbeschreibung des Fulcrum Search Builder (Quelle: [FUL99])
Ein Kontextschutz im Lese- und Schreibmodus erlaubt problemlos, eine große Anzahl von parallel zugreifenden Anwendungen zu bewältigen. Komplexe Suchanfragen, die auf mehrere sogenannte SearchServer-Tabellen zugreifen müssen, können auf
verschiedene CPUs verteilt und parallel verarbeitet werden. Die Administration des
SearchServers wird zeitgemäß durch Wizards erleichtert. [FUL99]
Der FulView-Dokumentviewer kann in eigene Anwendungen integriert werden, er
übernimmt die Darstellung von 150 verschiedenen Dokumentformaten und verfügt über
nützliche Navigationsmöglichkeiten. Die Intuitive Suche entspricht vom Prinzip her
dem Query-by-Example, man kann Textpassagen oder ein gesamtes Dokument markieren, das die Grundlage für eine Suchanfrage bildet. Als Ergebnis erhält man zur Auswahl ähnliche Informationen, die dem Interesse des Benutzers am ehesten entsprechen.
Bei den Wildcards ist positiv anzumerken, daß im Gegensatz zu vielen anderen Paketen
hier auch Platzhalter für Vor- und Zwischensilben verwendet werden können. [FUL99]
Eine Spezialität von Fulcrum ist Word Sense, das natürlichsprachige Suchanfragen
in aussagekräftige boolsche Anfragen umwandelt. Diese Konvertierung erfolgt unter
Zuhilfenahme eines umfangreichen linguistischen Regelwerkes und eines Lexikons, das
inetwa 40000 Worte und 130000 Bedeutungen beinhaltet. Bei diesem Verfahren wird
versucht, die Bedeutung der Suchanfrage herauszufinden und so bessere Suchergebnisse
zu generieren. [FUL99]
Der SearchBuilder ist für Visual Basic, C, Visual C++ und Java vorhanden und
umfaßt das API, den Viewer (für Microsoft-Umgebungen als ActiveX-Control), umfangreiche Dokumentation und Beispielprogramme. Praktischerweise sind Funktionen
für Debuggingzwecke bereits enthalten, VB-Entwickler können darüberhinaus bei Bedarf auf Steuerelemente von Fremdanbietern zurückgreifen.
Für Java-Entwickler stehen Java Objektklassen bereit, um auf einfache Weise wichtige Merkmale in eigene Anwendungen einbauen zu können, z.B. Parsing von Suchanfragen oder eine Fehlerprüfung. Die Verwendung von Java erhöht einerseits die Sicherheit und bringt zudem den Vorteil, daß Unicode von vorneherein unterstützt wird.
54
Client-Applikationen können unter Ausnützung von Java von einer zentralen Stelle aus
administriert oder upgedatet werden. [FUL99]
3.4
Zusammenfassung
Die Behandlung der IR Systeme hat gezeigt, welche Vielfalt an Möglichkeiten sich
bei der Indizierung von Dokumentdaten eröffnet. Als Grundlage für die Auswahl eines konkreten IR Systems, das im Rahmen einer Suchanwendung eingesetzt werden
soll, wurden die zugrundeliegenden Konzepte und Mechanismen der Indizierung und
Suche diskutiert. Wesentliche Merkmale, die sich auf die Praxistauglichkeit eines IR
Systems auswirken, sind das Modell, die Filestruktur und die damit eng verknüpften
Funktionalitäten zur Indizierung, Suche und Suchergebnisdarstellung.
Die allgemeinen Betrachtungen im theoretischen Teil bilden eine Basis, auf der ein
Vergleich realer IR Systeme durchführbar wird. Die Zielsetzung der vorliegende Studie
war es, die IR Systeme auf ihre Anwendbarkeit im xFIND-Suchsystem zu prüfen. Aus
diesem Grund wurden neben den generellen Ansprüchen, wie geringer Speicherbedarf
oder gute Antwortzeiten, zusätzlich einige spezielle Anforderungen formuliert, wie z.B.
Feldindizierung und -suche oder die direkte Verarbeitung von in UTF-8 gespeicherten
Daten.
Aus der großen Anzahl gängiger IR Systeme wurden stellvertretend einige Pakete ausgewählt und untersucht. In einer detaillierten Gegenüberstellung der Funktionalitäten, sowie einem praxisnahen Performancetest bezüglich Indizierung und Suche
haben sich jene Kandidaten (Glimpse, Isearch und Verity) herauskristallisiert, die als
Subsystem des xFIND-Systems geeignet erscheinen. Die Testergebnisse sind den Abschnitten 3.3.2 bis 3.3.4 zu entnehmen. Im Zuge der Untersuchung hat sich herausgestellt, daß die angebotenen IR Systeme bezogen auf das von xFIND gestellte Anforderungsprofil in einzelnen Teilbereichen Schwächen aufweisen, auf die seitens der xFINDEntwickler kein Einfluß genommen werden kann. Aufgrunddessen wurden abschließend
einige Search Development Kits betrachtet, die den Vorteil einer individuellen Anpassung mit sich bringen, wobei jedoch ein Mehraufwand an Einarbeitung und Kosten zu
berücksichtigen ist.
Ein Schwerpunkt der vorangegangenen Untersuchung war die Indizierung von strukturierten Daten. Wie wichtig eine Strukturierung im Bereich der Informationsbeschreibung und -wiederauffindung ist, zeigt das nun folgende Kapitel des Untersuchungsbereiches. Anhand von Metadaten im allgemeinen und der thematischen Klassifikation von
Dokumentinhalten im speziellen wird der Einfluß beschreibender Strukturen diskutiert.
Kapitel 4
Klassifikation von Webressourcen
Gliederung dieses Kapitels
Im letzten Teil des Untersuchungsbereiches wird die Bedeutung von Metadaten zur
Beschreibung und Wiederauffindung von Webressourcen analysiert. Besonderes Augenmerk wird auf die thematische Komponente des Inhaltes von Webressourcen gelegt,
die eine Reihe von Organisations- und Suchmöglichkeiten eröffnen.
Nach einer kurzen Einführung in Abschnitt 4.1 erfolgt in Abschnitt 4.2 eine ausführliche Ausarbeitung des Problemkreises Metadaten. Zunächst wird das den Metadaten
zugrundeliegende Konzept und die erzielte Wirkung besprochen (siehe Abschnitt 4.2.1).
In weiterer Folge wird die Verwendung von Metadaten im WWW analysiert (siehe
Abschnitt 4.2.2) und die gängigen Metadatenstandards werden vorgestellt (siehe Abschnitt 4.2.3). Um auf die bestehenden Schwierigkeiten aufmerksam zu machen, werden
auch einige kritische Beobachtungen diskutiert (siehe Abschnitt 4.2.4).
Das im xFIND-Projekt definierte Metadatenschema xQMS wird beschrieben (siehe
Abschnitt 4.2.5) und bildet die Überleitung auf die in Abschnitt 4.3 untersuchten Klassifikationssysteme. Wiederum geben einige einführende Worte einen Überblick (siehe
Abschnitt 4.3.1), im Anschluß daran erfolgt eine Studie von selbstentwickelten (siehe Abschnitt 4.3.2), fachspezifischen (siehe Abschnitt 4.3.3) und wissenschaftlichen
Themenkatalogen (siehe Abschnitt 4.3.4), in der die Vor- und Nachteile des jeweiligen Ansatzes herausgearbeiten werden. Mit Hilfe der gewonnen Erkenntnisse werden schließlich Bedingungen für die thematische Klassifikation von Webressourcen in
xFIND formuliert (siehe Abschnitt 4.3.5).
55
KAPITEL 4. KLASSIFIKATION VON WEBRESSOURCEN
4.1
56
Motivation
Das World Wide Web (WWW) stellt zweifellos eine wertvolle Informationsquelle für
jedes erdenkliche Sachgebiet dar. Die Schwierigkeit im Umgang mit dem WWW besteht darin, die passenden Informationen herauszufiltern und ihre Qualität korrekt zu
beurteilen. Die Dynamik und das exponentielle Wachstum des WWW stehen hier den
Bemühungen entgegen, die Ressourcen in geeigneter Form zu beschreiben und so die
Auffindung qualitätvoller Information zu erleichtern. [OLM98]
Ein Ansatz, der zu einer wesentlichen Verbesserung der aktuellen Situation im
WWW führen sollte, ist die zunehmende Verwendung von Metadaten zur Beschreibung von Ressourcen.
4.2
Metadaten
Noch vor wenigen Jahren war der Begriff Metadaten wenig geläufig, in der Zwischenzeit
gibt es kaum eine Publikation über elektronische Ressourcen, die das darunterliegende
Konzept nicht aufgreift. Ressourcen werden durch ihre konsistente Beschreibung effizient und gezielt suchbar gemacht, eine Vorstellung, die gerade im rasch wachsenden
und weitgehend unstrukturierten WWW von besonderer Wichtigkeit ist. [MF99]
Metadaten sind Daten über Daten, sie charakterisieren die Merkmale und die Inhalte von Ressourcen. Ein potentieller Benutzer wird dadurch in die Lage versetzt, die
Ressource anhand der Metadaten aufzufinden und einer Vorabbeurteilung zu unterziehen. Klassische Beispiele von beschreibenden Daten sind Kurzfassungen, Schlüsselworte
oder bibliographische Informationen. Metadaten dieser Art werden seit Jahrhunderten
von Bibliothekaren erzeugt und standardisiert. Mit dem Aufschwung des WWW dringt
nun die moderne Informationstechnologie in diesen Bereich vor, die Folge ist eine Fülle
von wenig kompatiblen, miteinander konkurrierenden Standards1 . [MF99]
4.2.1
Konzept
Der Begriff Metadaten bezieht sich auf Daten im weitesten Sinne, es kann sich um jede
beliebige Art von beschreibendem Material handeln, z.B. um Text, Bilder oder Musik. Das Konzept befaßt sich ganz allgemein mit dem Katalogisieren von Information,
wobei keine einschränkenden Bestimmungen darüber gemacht werden, welche Informationsteile einer Beschreibung zuzuführen sind oder mit welchem Grad an Detailliertheit
diese Beschreibung zu erfolgen hat. Heute arbeiten die meisten Suchmaschinen textbasierend, die Ressourcen werden daher in der Regel durch textuelle Metadaten beschrieben. In zukünftigen Suchsystemen wird man jedoch auch Metadaten in anderer Form
begegnen, so verlangt eine Suche in einer Bilddatenbank beispielsweise Informationen
über die in den Bildern enthaltenen Farbverteilungen, während sich eine Suche in einer
Musikdatenbank an gespeicherten Klangmustern orientiert. [MF99]
1
Milstead und Feldman beschreiben in [MF99] die Situation folgendermaßen: ”Different systems
are being developed for different–and sometimes the same–kinds of information, resulting in a chaotic
atmosphere of clashing standards.”
57
Ein Beispiel für ein bereits verwirklichtes System ist QBIC2 (Query By Image Content) von IBM, das ein Bild als Suchanfrage akzeptiert und eine Suche in einer Bilddatenbank aufgrund der extrahierten Bildinformation (Farbverteilung, Texturen usw.)
durchführt. Andere bereits eingesetzte Systeme erschließen in Bilddatenformaten vorhandene textuelle Information mit Hilfe von Texterkennungsprogrammen (OCR, Optical Character Recognition) für die Indizierung und Suche.
Zudem werden Metadaten vermehrt zur Beurteilung von Ressourcen herangezogen
werden, ein derartiger Ansatz wird auch im xFIND-Suchsystem durch Einführung des
Metadatenschemas xQMS (siehe Abschnitt 4.2.5) verfolgt. Weitere Initiativen, die es
sich zum Ziel gesetzt haben, unter Einbeziehung von Metadaten die Entwicklung von
qualitätskontrollierten Informationsdiensten voranzutreiben, sind das Projekt DESIRE3 (Development of a European Service for Information on Research and Education)
der Europäischen Union und das britische Projekt eLib4 (Electronic Libraries). Auf
Grundlage von eLib sind eine Reihe von sogenannten Informationgateways entstanden,
die jeweils einen speziellen Themenbereich abdecken und aufgrund der durch Fachleute
gesammelten und beurteilten Daten eine hohe Qualität der Information gewährleisten.
Die bekanntesten Information Gateways sind ADAM5 (Art, Design, Architecture and
Media Information Gateway), OMNI6 (Organising Medical Networked Information)
und SOSIG7 (Social Science Information Gateway). [Wei2000]
Im Zusammenhang mit dem Rating von Ressourcen gibt es mitunter Informationen,
denen in der bisherigen Entwicklung von Metadaten wenig Aufmerksamkeit geschenkt
wurde, es sind dies z.B. Angaben über Authentizität, Verfügbarkeit, Zugriffsrechte,
digitale Signaturen, Copyrightbedingungen oder andere mit einer Ressource verknüpfte
Charakteristika. [MF99]
Metadaten haben im wesentlichen die nachfolgenden Anforderungen zu erfüllen [MF99]:
beschreibende Funktion: Sie müssen das Original für den Benutzer ausreichend beschreiben, sodaß er in der Lage ist, den Inhalt, den Zweck, die Quelle und die
Bedingungen der Verwendung des Originals zu erkennen.
standardisierte Struktur und Terminologie: Im Hinblick auf eine effiziente Nutzung ist die Einführung einer einheitlichen Form und die durchgängige Verwendung eines kontrollierten Vokabulars zwingend erforderlich. Sind in einem Metadatenschema für einzelne Attribute verschiedene Beschreibungsformen zugelassen, so müssen diese unbedingt in eine einheitliche Form konvertierbar sein.
Man muß sich demnach sehr genau darüber bewußt sein, wie die Struktur auszusehen hat und in welchen Wertebereichen operiert werden soll. Die Generierung der
Metadaten kann bereits bei der Erzeugung der Ressource durch den Autor erfolgen oder
2
http://wwwqbic.almaden.ibm.com/
http://www.desire.org/
4
http://ukoln.bath.ac.uk/services/elib
5
http://adam.ac.uk/
6
http://omni.ac.uk/
7
http://sosig.ac.uk/
3
58
erst zu einem späteren Zeitpunkt als Teil der Katalogisierung. Obwohl die zweite Variante aufgrund der stark wachsenden Anzahl von Ressourcen beinahe undurchführbar
wird, gibt es ambitionierte Versuche, daß Internet zu katalogisieren. Vielfach beschränkt
man sich auf die für einen bestimmten Anwendungsbereich am besten geeigneten Sites,
neben der beschreibenden Information können hier auch Bewertungen von außenstehenden Experten einfließen. Bei der Erfassung der Metadaten durch den Autor stellt
sich die Frage, wie man die große Anzahl der mit Katalogisierung wenig vertrauten
Informationsanbieter dazu bewegt, die relativ komplizierten Standards zu lernen und
anzuwenden. Innerhalb von Firmennetzen läßt sich demgegenüber eine konsistente Anund Verwendung von Metadaten einfacher erreichen. [MF99]
Die Verwendung einer Feldstruktur und eines definierten Vokabulars erhöht die
Genauigkeit der Suchergebnisse (siehe auch Abschnitt 3.2.4, Precision), indem sie die
folgenden beiden Probleme bei der Auffindung von Information beseitigt [MF99]:
Mehrdeutigkeit: Die Mehrfachbedeutung von Wörtern erfordert die Hinzunahme einer Umgebungsbeschreibung, um die beabsichtigte Bedeutung eines Wortes zu
verstehen. Metadaten stellen eben diesen Kontext zur Verfügung.
Synonyme: Eine Menge von verschiedenen Wörtern, die dasselbe Konzept repräsentieren, wird mit Hilfe der Metadaten auf dieses eine Konzept abgebildet. Auf diese
Weise kann auch die Vollständigkeit der Suchergebnisse (siehe Abschnitt 3.2.4,
Recall) positiv beeinflußt werden. Jedes Auftreten eines verwandten Wortes wird
dem standardisierten Wort zugeordnet. Infolgedessen werden auch Dokumente
gefunden, in denen das gesuchte Wort niemals vorkommt, die jedoch zum selben
Konzept gehören.
Metadaten kombinieren die Exaktheit der boolschen Suche mit der gewünschten
Unschärfe einer statistischen oder natürlichsprachigen Suche. Statistische Suchsysteme arbeiten größtenteils auf der Basis von proprietären Ranking-Algorithmen, die
den Worten eine relative Wichtigkeit zuweisen. Derartige Gewichtswerte basieren auf
Worthäufigkeiten (innerhalb eines Dokumentes und der gesamten Datensammlung), auf
Wortpositionen (im Titel, am Textbeginn usw.) oder auf der relativen Nähe von Worten
zueinander. Bei der Relevanzberechnung werden diese Faktoren zu einem numerischen
Rankingwert zusammengefaßt, der die Position eines Dokumentes in der Ergebnisliste
bestimmt. Die Hinzunahme von Metadaten eröffnet bei der Gewichtung und Relevanzberechnung viele neue Möglichkeiten. Die Metadaten beschreiben die zentralen Themen
eines Dokumentes, folglich werden Dokumente, die Wörter der Suchanfrage in ihren
Metadaten aufweisen, höher bewertet als jene, die sie lediglich im Fließtext enthalten. Der Einfluß bzw. die relative Wichtigkeit einzelner Metadatenelemente (z.B. Titel,
Schlüsselwörter) kann für die Berechnung des Rankingwertes auch individuell konfiguriert werden, um das für eine bestimmte Suchanwendung geforderte Verhalten des
Suchsystems zu erhalten. [MF99]
4.2.2
59
Anwendung im WWW
Im Augenblick gibt es keine verpflichtenden Standards, die Verwendung von Metadaten
geschieht auf freiwilliger Basis durch die Autoren oder Anbieter von Webressourcen.
In der Arbeit von O’Neill et al. [OLM98] wurde die Verwendung von Metadaten in
Webseiten untersucht. Die Ergebnisse dieser Studie, die vom Online Computer Library
Center durchgeführt wurde, sind nachfolgenden Abschnitt zusammengefaßt.
Demnach ist die Verwendung von Metadaten auf den Homepages von öffentlichen
Websites durchaus gebräuchlich, in 70 % aller getesteten Homepages wurden Meta-Tags
gefunden. Die Bandbreite der verschiedenen Attribute zeigt aber auch, daß hier sehr
unterschiedliche Metadatensätze zur Anwendung gelangen. Bei der genaueren Analyse der Verteilung der vorhandenen Meta-Tags stellt sich auch heraus, daß die am
häufigsten auftretenden Attribute "generator", "content-type" und "author" von
HTML-Editoren wie Microsoft FrontPage oder Netscape Composer stammen. Bei den
vom Autor händisch erzeugten Attributen stehen "keywords" und "description" an
oberster Stelle, dies sind jene Metadaten, die von den meisten Suchmaschinen bevorzugt berücksichtigt werden. [OLM98]
Die Schlüsselwörter waren teilweise sehr allgemein gewählt, z.B. enthält die Beschreibung eines Internet Service Providers das Schlüsselwort ”Web”. Daraus läßt sich
schließen, daß Metadaten benützt werden, um in einem breiten Bereich möglichst hoch
im Ranking der Suchergebnisse aufzuscheinen, und nicht, um in einer relativ kleinen,
thematisch eingeschränkten Ergebnismenge enthalten zu sein. Die sehr allgemeine Beschreibung von Webressourcen ist aber auch die Folge davon, daß die Autoren mit den
vorhandenen Standards wenig vertraut sind und bei der Erstellung der Metadaten im
wesentlichen ad hoc-Entscheidungen treffen. [OLM98]
Ein ähnliches Bild bietet sich bei den Rating-Attributen. Ein PICS-Label8 (Platform for Internet Content Selection) soll darüber Auskunft geben, ob eine Ressource
etwas enthält, das für eine bestimmte Zielgruppe geeignet bzw. nicht geeignet ist. Diese
Information wird vom Autor selbst oder von einer bewertenden Institution festgelegt
und sollte den Kriterien des jeweiligen Rating-Services entsprechen. Wie sich zeigt,
wird dieses Attribut entgegen seiner eigentlichen Bestimmung, nämlich den Zugriff auf
ungeeignete Information zu verhindern, sehr oft dazu verwendet, um die Eignung der
Ressource für alle Zielgruppen anzuzeigen. Das Hauptproblem der auf Metadaten basierenden Ratingservices ist im Augenblick aber noch die geringe Akzeptanz seitens
der Autoren. [OLM98]
Die obigen Angaben bezogen sich auf Homepages, also die Einstiegsseiten von Websites. Die Untersuchung der hierarchisch darunterliegenden Webpages zeigte mit 45 %
eine geringere Verwendung von Metadaten. Vorläufig ist man bei den Informationsanbietern also darauf bedacht, zumindest für die gesamte Website und für spezielle Webbereiche und Webpages eine Beschreibung in Form von Metadaten anzubieten. [OLM98]
Welche Arten von Metadaten es gibt, wie sie definiert sind und welche Mängel sie
im Augenblick noch aufweisen, wird in den kommenden Abschnitten erläutert.
8
http://www.w3.org/PICS/
4.2.3
60
Schemata
Wie schon in den vorangegangenen Abschnitten herausgearbeitet wurde, wird die strukturierte Beschreibung von Webressourcen dringend benötigt, um eine Verbesserung der
Indizierung und Suche erzielen zu können. Die strukturierte Beschreibung wird in sogenannten Schemata geregelt, sie definieren die Bedeutung, die Eigenschaften und die
Beziehungen einer Menge von Eigenschaften untereinander. Dazu zählen u.a. die Einschränkung der Attributwerte auf zulässige Wertebereiche und die Vererbung einzelner
Attribute durch andere Schemata. [Wei2000]
Das wohl bekannteste und am weitesten verbreitete Metadatenschema ist DC
(Dublin Core), eine aus 15 Attributen zusammengesetzte Liste zur Beschreibung von
Webressourcen, die sich aus den gemeinsamen Bemühungen der internationalen Bibliotheksgemeinschaft entwickelt hat. Die aktuelle Version 1.1 wurde im Juli 1999 verabschiedet und ist in Anhang B.1 zu finden. DC-Metadaten werden vorzugsweise im
HEAD-Teil von HTML-Dokumenten untergebracht, ein Muster dafür ist in Anhang B.2
angegeben. Neben der aufwendigeren Möglichkeit, die DC-Daten händisch zu erstellen,
helfen Tools wie der Nordic Metadata Creator9 dabei, diese zu erzeugen und deren
Konsistenz zu gewährleisten. [DC99], [Koc98]
Ein weiteres Schema, LOM (Learning Object Metadata), zielt auf die Beschreibung
von traditionellen und elektronischen Unterrichtsmitteln ab. Aufgrund dieser thematischen Einschränkung kann hier sehr genau auf die speziellen Anforderungen von Lehrenden und Lernenden eingegangen werden. Diese Detailliertheit zeigt sich bei LOM mit
seinen etwa 80 Metadatenattributen recht deutlich, DC definiert demgegenüber lediglich
15 Attribute. LOM basiert auf IMS (Instructional Management System), einer übergeordneten Spezifikation, die unterschiedliche Lehr- und Lernressourcen mit Hilfe unterschiedlicher Schemata charakterisiert. Für eine ausführliche Beschreibung aktueller
Metadatenschemata und der technischen Werkzeuge, die für eine zukünftige WWWweite Anwendung in Entstehung sind, sei auf die Arbeit von [Wei2000] verwiesen.
Durch die Anwendung von Metadatenschemata zur Beschreibung von Webressourcen gelingt es, z.B. unerwünschte Webinhalte zu blockieren oder interessante Informationen zu empfehlen. Die feldbasierende vereinheitlichte Beschreibung schafft zudem
die Voraussetzungen für eine automatisierte Filterung und Auswertung eines Datenbestandes. Innerhalb des xFIND-Suchsystems soll die Filterung einerseits aufgrund
traditioneller beschreibender Attribute (z.B. nach Themengebiet oder Autor) erfolgen,
anderseits sollen die gefundenen Dokumente auch den geforderten Qualitätskriterien genügen, die in einem Schema durch bewertende Attribute charakterisiert sind.
Zu diesem Zweck wurde das spezielle Metadatenschema xQMS entwickelt, das im Abschnitt 4.2.5 vorgestellt werden wird.
9
http://www.lub.lu.se/cgi-bin/nmdc.pl
4.2.4
61
Kritische Bemerkungen
Obwohl Metadaten versprechen, die derzeitigen Probleme bei der Beschreibung und
Wiederauffindung von Webressourcen zu beseitigen, so gibt es noch eine Reihe von
Schwierigkeiten, die es zu überwinden gilt. Einige dieser Spannungsfelder, in denen man
sich im Augenblick bewegt, sollen nachfolgend in loser Ordnung aufgezählt werden.
• Die Entwicklung wie auch die Verwendung von Metadatenschemata geschieht
ausschließlich auf freiwilliger Basis. Es gibt eine große Anzahl von unterschiedlichen Projekten, die weitgehend ihre eigenen Interessen wahren möchten. Die
Koordination zwischen diesen Projekten ist wenig ausgeprägt oder findet überhaupt nicht statt. [MF99]
• Metadatenschemata wie DC entstanden aus der Erkenntnis, daß die Internetsuchmaschinen hinsichtlich der Genauigkeit der Suchergebnisse nicht optimal arbeiten. Hier wollte man rasch reagieren und mit relativ geringem Aufwand die Situation zurechtrücken. Im Vergleich zu gedrucktem Material zeigen die im Internet vorhandenen Ressourcen eine weitaus größere Artenvielfalt, wodurch eine
15 Elemente umfassende Attributmenge lediglich als kleinster gemeinsamer Nenner zur Beschreibung aller Ressourcen aufgefaßt werden kann. Die Ansicht der
Bibliotheksvertreter ist es, daß die Beschreibung von Dokumenten im weitesten
Sinne nicht einfacher sein kann, als die bereits in Bibliotheken sehr erfolgreich
durchgeführte Beschreibung von Büchern. In diesem Zusammenhang wird jedoch
auch darauf hingewiesen, daß man von den Metadaten jederzeit zum elektronischen Originaldokument gelangen kann, um weitere Informationen einzuholen.
Dies ist in traditionellen Bibliotheken zumeist nicht möglich. Die Minimalanforderung wäre es demnach, daß lediglich die Zugriffskriterien in den Metadaten in
korrekter Form vorkommen müssen. [Ever99]
• Mappings und Crosswalks zwischen den verschiedenen Schemata sollen eine Zusammenarbeit ermöglichen, tatsächlich sind sie allerdings ein Indikator für die
verfahrene Situation. [MF99]
• Es gibt im Augenblick kein Schema, das alle Anwendungsbereiche gleich gut abdeckt. Es ist durchaus denkbar, daß sich in Zukunft mehrere Schemata etablieren
werden. [MF99]
• Eine ähnliche Problematik ergibt sich für die Eigenschaftswerte der Metadatenattribute. Beispielsweise scheinen sich die LCSH (Library of Congress Subject
Headings) als ”kontrolliertes” Vokabular zur Beschreibung von Themen, Schlüsselwörtern usw. durchzusetzen, jedoch nicht aufgrund ihrer Qualität oder ihrer herausragenden Eignung für eine elektronische Suche, sondern vielmehr aus der Tatsache heraus, daß es sie gibt und man sie bereits verwenden kann. Die Zeit ist
im Bereich der Informationstechnologie ein sehr limitierter Faktor und der immer stärker werdende Wettbewerb erzwingt den Einsatz von noch nicht völlig
ausgereiften Lösungen. [MF99]
62
• Die Ansetzungsregeln für beliebig beschreibbare Attribute werden oft vernachläßigt, dabei handelt es sich um Vorschriften, welche Werte ein Attribut annehmen darf und welches Format diese Werte aufzuweisen haben. Beispielsweise
ist ein Autorfeld bei der Suche wenig hilfreich, wenn keine Konvention darüber
besteht, wann der Vorname (in abgekürzter oder ausgeschriebener Form) und
wann der Nachname unter Verwendung bestimmter Trennzeichen anzuführen
ist. [Ever99]
• Der Autor oder Erzeuger kennt sein Produkt zwar am besten, dies bedeutet
aber nicht zwangsläufig, daß er es im Umfeld der universalen Wissensordnung
korrekt beschreiben und positionieren kann oder will. Das Stichwort lautet hier
”Spamming”, d.h. der Versuch, das Ranking mit Hilfe falscher Metainformation
so zu verbessern, daß das Dokument an einer der obersten Stellen innerhalb
der Suchergebnisse aufscheint [MF99]. Die Erfassung der Metadaten durch die
unterschiedlich qualifizierten Autoren beeinflußt auch grundlegend die Konsistenz
der Informationen [Ever99].
Das Konzept der Metadaten wird internetweit sehr ausführlich diskutiert, wodurch die
zuvor genannten Kritikpunkte intensiv behandelt und möglicherweise auch rasch einer
Lösung zugeführt werden können. Einen wesentlichen Beitrag zur Entwicklung besserer
Metadatenstandards leistet auch das xFIND-Projekt, das auf die genannten Probleme,
die sich bei der Suche nach qualitativen Inhalten ergeben, eingeht. Die Beschreibung
von Webressourcen muß zum einen so korrekt und ausführlich wie möglich erfolgen,
zum anderen ist eine möglichst objektive Bewertung der Qualität anzustreben. Diese
beiden Forderungen schlagen sich in den beschreibenden und qualitätsbeurteilenden
Attributen des im nächsten Abschnitt vorgestellten Metadatenschemas nieder.
4.2.5
xFIND Quality Metadata Scheme
Ein Aspekt, dem in der Betrachtung von Metadaten bisher wenig Beachtung geschenkt
wurde, ist die Beschreibung der inhaltlichen Qualität einer Ressource. Im Rahmen
des xFIND-Projektes wurden Möglichkeiten diskutiert, derartige Informationen in die
vorhandenen Metadaten-Standards zu integrieren. Eine Zielvorstellung ist es, alle Ressourcen des xFIND-Systems mit Hilfe eines einheitlichen Metadatenschemas beschreiben und bewerten zu können. In Anlehnung an bekannte Schemata wie DC und LOM
wurde xQMS (xFIND Quality Metadata Scheme) entwickelt. xQMS erlaubt die Beurteilung von Websites, Webbereichen, Webpages und einzelnen Abschnitten innerhalb der
Webpages. Eine Kurzbeschreibung von xQMS enthält Anhang B.3, für eine detaillierte
Beschreibung über die Entstehung, Hintergründe und Perspektiven, die dieses Schema
zukünftigen Anwendungen bietet, sei auf [Wei2000] verwiesen.
Dieses Schema gestattet es dem Autor, die beschreibenden und bewertenden Metadaten zu seinen Ressourcen zunächst selbst zu erstellen. Um die Ressourcen suchbar
zu machen ist eine Anmeldung beim xFIND-Suchsystem erforderlich. Daraufhin erfolgt
eine erstmalige Indizierung in deren Verlauf die Metadaten mit einer niedrigen Priorität versehen werden, da sie noch keiner Kontrolle unterzogen wurden. Werden die
Angaben des Autors jedoch von einem Experten geprüft und gegebenenfalls geändert,
63
so erhalten sie eine höhere Priorität, die sich positiv für das Ranking einer Ressource im
Suchergebnis auswirkt. Die Metadaten haben somit in xFIND eine beschreibende und
eine beurteilende Funktion, die den Autor selbst und weitere Instanzen in die Erstellung miteinbezieht. Durch das Review10 von Metadaten kann für die Informationssuche
ein hohes Maß an Qualtität gewährleistet werden. [Wei2000]
Eine essentielle Voraussetzung für die qualitative Auswertung von Metadaten ist die
konsequente Verwendung von definiertem Vokabular für Attributwerte. Das Metadatenschema hat die Aufgabe, die Attribute, deren Bedeutung und die zulässigen Wertebereiche möglichst genau zu definieren, um die darin beschriebene Information ”maschinenverstehbar” zu machen. Tabelle 4.1 zeigt einen Auszug aus den beschreibenden
Attributen von xQMS, die Gesamtheit der Attribute ist in Anhang B.3 aufgelistet.
xQMS.Content.Title
xQMS.Content.Type
xQMS.Content.Topic
xQMS.Content.Alt Classident
xQMS.Content.Description
Name der Ressource
Art des Inhaltes der Ressource (z.B. Text, Audio)
Thema des Inhaltes der Ressource nach Dewey
zusätzlich verwendetes Klassifikationsschema
Zusammenfassung des Inhaltes der Ressource
Tabelle 4.1: Auszug aus den beschreibenden Attributen von xQMS (Quelle: [Wei2000])
Die Belegung der Attribute mit Werten kann auf unterschiedliche Art und Weise
erfolgen. Attribute wie xQMS.Content.Title oder xQMS.Content.Description unterliegen keinen Beschränkungen, die Beschreibung erfolgt durch beliebige Wörter, die den
Inhalt der Webressource charakterisieren. Attribute wie xQMS.Content.Type dürfen
nur Werte annehmen, die einer definierten Norm (z.B. den in einer erschöpfenden Liste
aufgezählten Arten einer Webressource) genügen. Zu dieser Art von Attributen zählt
auch xQMS.Content.Topic. Ihm kommt ein besonderer Stellenwert zu, da die thematische Klassifikation von Webressourcen eine Vielzahl von Möglichkeiten zur Suche und
Suchergebnisauswertung mit sich bringt. Im folgenden Abschnitt werden die Vorteile
einer thematischen Klassifikation diskutiert, die gebräuchlichsten Themenhierarchien
gegenübergestellt und auf ihre Einsetzbarkeit in Suchanwendungen untersucht.
10
wertende Beschreibung eines Experten
4.3
64
Klassifikationssysteme
Die derzeit im Internet verfügbaren Such- und Browsingdienste verwenden eine Reihe von Ordnungsaspekten zur Beschreibung und Wiederauffindung von Ressourcen.
Beliebte Kriterien sind die Ordnung nach dem Dokumenttyp, nach dem Ort der Speicherung oder nach dem Zeitpunkt der Generierung (chronologisch). Die am häufigsten
anzutreffende Ordnung erfolgt nach Sachgebieten, ein Umstand, der bereits den hohen Stellenwert einer thematischen Klassifikation in Verbindung mit Suchproblemen
verdeutlicht. [Oeh96]
Klassifikationsschemata können grob in einige Kategorien eingeteilt werden. Die
wichtigste Kategorie bilden die Universalklassifikationen, sie nehmen eine vollständige
Ordnung des Wissens vor und sollen in den folgenden Abschnitten ausführlich betrachtet werden. Weiters kommen nationale Schemata zur Anwendung, die zwar bezüglich
der Themen allgemein gehalten sind, jedoch in der Regel für ein einzelnes Land oder
geographisches Gebiet entwickelt wurden. Darüberhinaus existiert eine große Anzahl
an speziellen Klassifikationen, die bestimmte Fachbereiche sehr detailliert beschreiben.
Die letzte Gruppe bilden die selbstentwickelten Themenkataloge, die zunehmend im
Internet ihre Verbreitung finden und deshalb ebenfalls genauer analysiert werden sollen. [Koc97]
4.3.1
Grundlagen
Die Entscheidung, ob einem selbstentwickelten Themenkatalog, einem fachspezifischen
oder einem wissenschaftlichen Klassifikationsschema der Vorzug gegeben wird, hängt
vom Aufgabenbereich und der jeweiligen Zielgruppe der Anwendung ab. Für den Einsatz in einem sehr breiten, allgemein gehaltenen Wissensbereich empfiehlt sich eine
Universalklassifikation. Soll ein Service in einem eingeschränkten Fachbereich zum Einsatz kommen, dann sind spezielle oder selbstentwickelte Klassifikationen von Vorteil.
Während die letzteren hauptsächlich im privaten und kommerziellen Bereich verwendbar sind, bieten Universalklassifikationen wesentliche Vorzüge im akademischen Bereich. Es können natürlich auch verschiedene Schemata gleichzeitig zur Anwendung
kommen, Konvertierungsverfahren helfen hier bei der Zusammenführung der Themenhierarchien. [Oeh96], [Koc97]
4.3.2
Selbstentwickelte Themenhierarchien
Den für eine breite Benutzerschicht wohl wichtigsten Zugang zum WWW stellen die
Portale der großen Browsingdienste dar, allen voran Yahoo11 . Die angebotene hierarchisch geordnete Themenstruktur dieser Dienste weißt bei näherer Betrachtung einige
Eigenheiten auf, die im weiteren Verlauf auch am Beispiel des Open Directory Project
(siehe Abschnitt 4.3.2.2) von Netscape veranschaulicht werden sollen.
11
http://www.yahoo.com/
4.3.2.1
65
Vor- und Nachteile
Die wesentliche Stärke von selbstentwickelten Themenhierarchien gegenüber den weiter
unten vorgestellten Universalklassifikationen (siehe Abschnitt 4.3.4) ist die relativ hohe
Flexibilität. Änderungen in der Struktur können nach Belieben durchgeführt werden,
um so neue Wissensbereiche besser abbilden zu können. Demgegenüber stehen aber
auch Schwächen:
• Die Erstellung der Hierarchie wird von sehr subjektiven Überlegungen beeinflußt,
die Folge ist eine fehlende Konsistenz und Logik der Themenordnung. Wichtige
Kriterien bei der Erstellung der Hierarchie oder bei der Aufnahme neuer Ressourcen sind beispielweise Unterhaltungswert, Design oder Innovativität. Die anzutreffenden Klassen entsprechen somit nicht den Wissenschaftsdisziplinen, sondern vielmehr den erwarteten Nutzerinteressen, sie spiegeln also die Zielgruppe
der Dienste wider. [Oeh96], [Koc97]
• Mit den ständigen Änderungen der Struktur muß auch laufend eine Überprüfung
und Bewertung der Zweckmäßigkeit derselben erfolgen. Die Zusammenarbeit mit
anderen Klassifikationen ist aufgrund dieser Dynamik ebenfalls nur erschwert
durchführbar. [Koc97]
Wie sich die genannten Vorzüge und Schwächen in der Praxis auswirken, wird anhand eines immer beliebter werdenden Katalogdienstes im nachfolgenden Abschnitt
aufgezeigt. Dabei wird darauf eingegangen, welchen Stellenwert selbstentwickelte Themenhierarchien im exponentiell wachsenden WWW einnehmen könnten und welche
Eigenheiten bei ihrer Erstellung und Verwaltung zu beachten sind.
4.3.2.2
Open Directory Project
Das erklärte Ziel des ODP12 (Open Directory Project) ist es, das umfassendste Directory im Web zu erstellen. Um dieses ehrgeizige Ziel zu erreichen, macht man sich die
verteilte Struktur des Internet zunutze. Anstatt einer zentralen Stelle zur Verwaltung
des Directories, sind engagierte freiwillige Editoren für die Pflege der ihnen übertragenen Teilbereiche zuständig. Augenblicklich umfaßt das Open Directory über eine
Million Websites die von 19.000 Editoren in 180.000 Klassen eingeteilt wurden (Stand:
Dezember 1999), Tendenz weiterhin stark steigend. [ODP99]
Mit diesem Konzept gelingt es, dem raschen Wachstum des WWW ohne nennenswerte Einbuße an Vollständigkeit zu folgen. Neuen Entwicklungen kann unmittelbar
durch Verfeinerung oder Umstrukturierung der Themenhierarchie Rechnung getragen
werden. Durch Verteilung der Zuständigkeit auf viele Experten und kleine Fachbereiche
kann die Aktualität (wenige Dead-Links) und die Qualität gewährleistet werden. Die
Qualität bezieht sich in diesem Zusammenhang auf die Kompetenz des Informationsanbieters. Die Qualität der im Katalog gesammelten Informationen bzw. Links hängt
von den Auswahlkriterien des jeweiligen Editors und seiner fachlichen Qualifikation in
dem von ihm betreuten Themenbereich ab. Somit variiert das Angebot in den einzelnen
12
http://dmoz.org/
66
Themenbereichen sowohl in der Quantität als auch in der Qualität der Links, je nach
den Fachkenntnissen und dem freiwilligen Engagement des Betreuers. ODP registriert
die Editoren und erstellt ein Profil, das jeder Benutzer einsehen kann, um sich selbst
ein Bild über den Editor machen oder ihn bei Bedarf kontaktieren zu können. [ODP99]
Interessanterweise erscheinen die genannten Vorteile bei genauerer Betrachtung
auch als Nachteile. Die Betreuung durch die große Anzahl von unterschiedlich qualifizierten Editoren führt insgesamt zu einer eher inkonsistenten Qualität. Die Themenhierarchie unterliegt einer ständigen Veränderung und die Verfeinerung von Teilgebieten erfolgt nicht immer nach logisch-wissenschaftlichen Gesichtspunkten. [Not99]
ODP unterliegt den Open Content Vorschriften, die es gestatten, die Directory
Listings kostenlos herunterzuladen und vollständig oder in Teilen zu publizieren. Die
Themenhierarchie ist in RDF (Resource Description Format) verfügbar, Abbildung 4.1
zeigt die 15 Hauptklassen. Umstellungen in der Struktur werden getrennt vermerkt und
es wird eine Mailingliste angeboten, die über Änderungen in der Hierarchie informiert.
Tools zur Verarbeitung der ODP-Daten sind zum Teil auch verfügbar. Eine Verständigung des ODP, daß man die Daten benützt, ist nicht zwingend erforderlich. [ODP99]
Abbildung 4.1: Hauptklassen des Open Directory Project
Zwar bietet ODP eine Themenhierarchie, die den meisten Webusern bereits geläufig
ist, für die Verwendung in einem Metadatenschema birgt sie jedoch einige Nachteile.
Die fehlende eindeutige Codierung der Klassen verhindert die Einschränkung der Suche
auf Teilbereiche der Hierarchie. Eine Codierung ist darüberhinaus wünschenswert, weil
sie eine sprachunabhängige thematische Suche anhand der Klassencodes ermöglicht.
Die Regeln für die Einteilung einer Webressource in die vorhandenen Klassen werden
vom ODP nicht offengelegt und sind daher selbst festzulegen. Da es sich um einen
selbstentwickelten und sich ständig verändernden Themenkatalog handelt, stellt die
67
Konvertierung auf die bekannten und im weiteren Verlauf dieser Arbeit beschriebenen wissenschaftlichen Klassifikationsschemata (siehe Abschnitt 4.3.4) ebenfalls eine
Schwierigkeit dar. Die hier beschriebenen Nachteile wirken sich innerhalb eines Metadatenschemas problematisch aus, da sie eine konsistente thematische Beschreibung
und Beurteilung von Webressourcen behindern und eine hierarchische und sprachunabhängige Suche nicht ohne weiteres gewährleisten. Dies sind aber zwei Grundvoraussetzungen, die ein qualitätsorientierter Suchdienst, wie ihn xFIND (siehe Kapitel 2)
unter Verwendung von xQMS (siehe Abschnitt 4.2.5) darstellt, unbedingt zu erfüllen
hat.
Der Themenkatalog von ODP versucht einen möglichst großen, allgemein gehaltenen Wissensbereich abzudecken. Dazu bedient er sich einer veränder- und erweiterbaren hierarchischen Struktur, in der die Themenbereiche zeitgemäß organisiert sind,
sodaß sich auch unerfahrene Benutzer problemlos darin zurechtfinden. Im Gegensatz
zu diesem verallgemeinerten Ansatz stehen die im kommenden Abschnitt beschriebenen fachspezifischen Klassifikationen, die sich auf einen eingeschränkten Wissensbereich
spezialisieren und diesen möglichst genau und lückenlos behandeln.
4.3.3
Fachspezifische Klassifikationen
Die Mehrheit dieser Schemata wurde im Hinblick auf eine bestimmte Benutzergruppe entwickelt, sie eignen sich daher insbesondere zur Organisation spezieller Datensammlungen, wie z.B. von Journalartikeln oder Bibliographien einer konkreten wissenschaftlichen Disziplin. Sie verfügen über eine Struktur und Terminologie, die sehr eng
mit dem behandelten Fachbereich verknüpft ist, wodurch sie im Vergleich zu Universalklassifikationen (siehe Abschnitt 4.3.4) einzelne Ressourcen wesentlich exakter und
aktueller charakterisieren können. Aus diesem Grund werden sie bevorzugt in jenen Bereichen eingesetzt, die eine genauere thematische Abstufung verlangen (z.B. Medizin,
Mathematik). Denkbar und sinnvoll ist in diesem Zusammenhang, daß jene Bereiche einer übergeordneten Universalklassifikation, die nicht ausreichend genau definiert sind,
durch eine fachspezifische Klassifikation erweitert werden. Hier ist jedoch darauf zu
achten, daß nur solche Schemata zum Einsatz kommen, die von der Fachgemeinde akzeptiert sind und international verwendet werden. Einige Klassifikationen, die diese
Kriterien erfüllen, werden im folgenden angesprochen. [Koc97]
4.3.3.1
National Library of Medicine
NLM13 organisiert den Wissensbereich Medizin und die damit verwandten Wissenschaften. Das Schema kann sowohl für kleine als auch für sehr große Datensammlungen
verwendet werden, eine Anpassung an spezielle medizinische Teilgebiete kann ebenfalls
durchgeführt werden. Die Notation entspricht den Konventionen von LCC (siehe Abschnitt 4.3.4.4), wodurch NLM bei Bedarf auch als Erweiterung von LCC eingesetzt
werden kann. Eine Beispielanwendung im WWW, die NLM zur Organisation medizinischer Ressourcen verwendet, ist OMNI14 (Organising Medical Networked Information).
13
14
http://www.nlm.nih.gov/
http://www.omni.ac.uk/
4.3.3.2
68
Engineering Information Classification Codes
Ei15 ermöglicht die Katalogisierung von Publikationen aus dem Ingenieurswesen. Interessanterweise handelt es sich hier um kein hierarchisches, sondern um ein aufzählendes
numerisches Schema. Ein Beispiel, das ein an Ei angelehntes Klassifikationschema einsetzt, ist EEVL16 (Edinburgh Engineering Virtual Library).
4.3.3.3
ACM Computing Classification System
ACM CCS17 bezeichnet einen Standard der Association for Computing Machinery für
die Kategorisierung von Computerliteratur und anderen mit dem Computer im Zusammenhang stehenden Ressourcen. Das Schema wurde erstmals 1964 veröffentlicht und
hat aufgrund des sehr dynamischen Fachgebietes zahlreiche Revisionen erfahren. Die
aktuelle Version, sie stammt aus dem Jahre 1998, wird u.a. zur erweiterten Beschreibung des Themas im Metadatenschema xQMS des xFIND-Suchsystems verwendet (siehe
dazu 4.3.5). Ein weiteres Beispiel für die Anwendung dieses Schemas ist der deutsche
Katalogdienst ARIADNE18 .
Das Schema basiert auf einer Baumstruktur mit vier Ebenen. Die ersten drei Ebenen beschreiben die Struktur einer Disziplin und sind durch Buchstaben und Zahlen
codiert. Die vierte Ebene ist nicht codiert, enthält aber Themenbezeichner, die detailliert genug sind, um auch neue Entwicklungen innerhalb der jeweiligen Disziplin
abzudecken. Tabelle 4.2 zeigt ein Beispiel einer Klassifikation, die Haupt- und Unterklassen von ACM CSS sind im Anhang B.8 aufgelistet. [CCS99]
H
H.2
H.2.3
Information Systems
Database Management
Languages
Query Languages
Tabelle 4.2: Beispiel für die Klassifikation nach ACM CSS
Die 11 Hauptklassen werden nie zur unmittelbaren Klassifikation von Ressourcen
herangezogen, da sie zu allgemein gehalten sind. Neben den Themenbezeichnern auf
der Blattebene des Baumes können noch definierte allgemeine Bezeichner (z.B. Security, Standardization, Theory etc.) und implizite Bezeichner (z.B. C++, Fortran,
OS/2 etc.) verwendet werden. Das Schema bietet mit diesen zusätzlichen Bezeichnern
und den Klassen General (Allgemeines) und Miscellaneous (Sonstiges) die Möglichkeit,
auch atypische oder neue Fachbereiche entsprechend zu klassifizieren. Dennoch muß
man damit rechnen, daß eine zukünftige Version von ACM CSS aufgrund der Dynamik
dieses Wissensbereiches eine grundlegend andere Struktur aufweisen wird. [CCS99]
15
http://www.ei.org/
http://eevl.icbl.hw.ac.uk/
17
http://www.acm.org/class/
18
http://ariadne.inf.fu-berlin.de:8000/
16
4.3.3.4
69
Kritische Betrachtung von fachspezifischen Klassifikationen
Die Anwendung einer fachspezifischen Klassifikation zur thematischen Beschreibung
bringt naturgemäß Vorteile innerhalb dieses eingeschränkten Wissensbereiches. Sieht
man allerdings über den Rand dieses Wissensbereiches hinaus und betrachtet dessen
Einbettung in die Gesamtheit der Wissensordnung, so werden die folgenden Schwächen
erkennbar [Koc97]:
• Die Zusammenarbeit mit anderen Klassifikationsschemata gestaltet sich schwierig. Es werden Konvertierungsprogramme benötigt, um Zuordnungen treffen oder
Daten zwischen verschiedenen Schemata austauschen zu können.
• Die Struktur der Schemata kann für unerfahrene Benutzer schwer verständlich
sein, da u.U. Fachkenntnisse vorausgesetzt werden.
Darüberhinaus können Sammlungen von hochspezialisierten Ressourcen mitunter
Themen enthalten, die selbst in diesen detaillierten Klassifikationen nicht berücksichtigt werden. Es wurde bereits darauf hingewiesen, daß fachspezifische Klassifikationen als Ergänzung von Universalklassifikationen eingesetzt werden können. Welche Arten dieser übergeordneten Schemata es gibt und welche Bedeutung sie für zukünftige
Suchanwendungen - im Besonderen für das xFIND-Suchsystem - haben, wird in den
kommenden Abschnitten diskutiert.
4.3.4
70
Universalklassifikationen
Die ersten Universalklassifikationssysteme wurden im ausgehenden 19. Jahrhundert
zum Zwecke einer verbesserten Organisation von Bibliotheken entwickelt. Auslöser für
ihre Entstehung war der rasante Fortschritt in vielen Wissensbereichen und die damit
verbundene große Anzahl an neuerschienenen Büchern, die einer umsichtigen Einteilung
in Themenbereiche bedurften. [Koc97]
In den nachfolgenden Abschnitten sollen die wichtigsten Vertreter dieser Klassifikationen beschrieben und analysiert werden, dabei soll die Verwendbarkeit für die
Klassifikation von Internetressourcen immer im Vordergrund stehen.
4.3.4.1
Vor- und Nachteile
Die Verwendung von Universalklassifikationen in Internetanwendungen hat eine Reihe
von Vorteilen [Koc97]:
Browsing: Die Einteilung von Webressourcen in Klassen der Themenhierarchie eröffnet eine Vielzahl von effizienten und intuitiv verwendbaren Zugriffsmöglichkeiten. Einerseits kann man einfache Themenlisten anbieten, mit denen sich auch
unerfahrene Benutzer rasch zurechtfinden, andererseits lassen sich auf Basis
der Themenhierarchie innovative Such- und Navigationsmethoden entwickeln.
Die Gruppierung der Suchergebnisse entsprechend der Themenhierarchie bietet
gemäß [Koc98] einen erheblich besseren Überblick als es bei den gewohnten unstrukturierten Ergebnislisten der Volltextsuchmaschinen der Fall ist.
Verallgemeinerung und Einschränkung einer Suche: Aufgrund der hierarchischen Struktur kann man je nach Suchstrategie den Suchbereich erweitern, um so
die Vollständigkeit zu erhöhen, oder den Bereich verkleinern, um die Genauigkeit
positiv zu beeinflussen (siehe Abschnitt 3.2.4).
Kontext: Die Hinzunahme einer Klassifikation setzt die Suchterme in einen bestimmten Kontext. Dadurch bekommt man das Problem der Homonyme weitgehend
unter Kontrolle, dabei handelt es sich um gleichlautende Wörter mit unterschiedlicher Bedeutung. Beispielsweise hat das Wort ”Virus” in der Medizin eine andere
Bedeutung als im Bereich Computersoftware.
Sprachunabhängigkeit: Die Notation der wissenschaftlichen Klassifikationen ist sprachunabhängig, damit wird es möglich, auf eine derart klassifizierte Datensammlung mit Hilfe von verschiedensprachigen Indizes zuzugreifen, ohne Änderungen
in den Daten selbst durchführen zu müssen.
Partitionierung großer Datensammlungen: Große Bestände von klassifizierten
Daten lassen sich entsprechend der Hierarchie in zusammenhängende Teilbereiche
aufteilen, die unter Umständen leichter zu handhaben sind.
71
Verteilte Suche: Die Verwendung wissenschaftlicher Klassifikationen erleichtert auch
die themenbezogene Suche in heterogenen Umgebungen, da die Konvertierung
zwischen verschiedenen Schemata unterstützt wird. In [Koc98] wird auch angeführt, daß eine einheitliche Klassifikation die Zusammenführung von traditionellen Bibliotheksdiensten und internetbasierenden Services ermöglicht.
Zukunftssichere Methode: Die anerkannten Schemata werden noch für längere Zeit
im allgemeinen Gebrauch stehen, es erfolgt eine kontinuierliche Anpassung an
neu entstehende Wissensbereiche, sodaß keine Gefahr einer raschen Veralterung
besteht.
Weite Verbreitung: Da die Klassifikationen seit geraumer Zeit in Bibliotheken in
aller Welt verwendet werden, besteht bereits ein grundsätzliches Verständnis für
die Konzepte und Verwendung derartiger hierarchischer Strukturen.
Grundlage für den Aufbau und die Organisation von Wissensdatenbanken:
Die zunehmende Verwendung der Klassifikationen liefert statistische Aussagen
über Themenverteilungen und -schwerpunkte in großen Datenbeständen (Wissensdatenbanken). Diese statistischen Kennwerte können einerseits zur Verbesserung des jeweiligen Klassifikationsschemas herangezogen werden (z.B. zur Verfeinerung einzelner Bereiche in der Themenhierarchie) und andererseits entscheidend zur Weiterentwicklung neuer Hilfsmittel zur Klassifikation und Suche
beitragen. Unverzichtbar sind statistische Informationen beispielsweise bei der
automatischen Klassifikation von Ressourcen oder beim Erstellen kontrollierter
Wörterbücher, beides Werkzeuge, die den Aufbau von großen Wissensdatenbanken vereinfachen. [Koc98]
Geringer Verwaltungsaufwand: Im Vergleich zu selbstentwickelten Themenhierarchien, die eine ständigen Kontrolle und Überarbeitung verlangen, ist die Wartung
einer wissenschaftlichen Klassifikation im Rahmen einer konkreten Anwendung
weniger aufwendig. [Koc98]
Darüberhinaus gibt es exakt definierte Richtlinien für die Anwendung der Klassifikation. Diese Vorschriften beziehen sich zwar auf gedrucktes Material, sind aber
grundsätzlich auch auf elektronische Ressourcen übertragbar. [Oeh96]
Den genannten Vorzügen gegenüber stehen einige Punkte, die bei der Verwendung von
Universalklassifikationen kritisch betrachtet werden sollten [Koc97]:
Schwächen in der Ontologie: Die Struktur der Themenhierarchie scheint in einigen
Abschnitten keinen logisch-wissenschaftlichen Regeln, sondern vielmehr subjektiven Kriterien zu folgen. Die Inkonsistenzen haben zum Teil ihre Ursache in den
weit zurückliegenden Anfängen der Katalogisierung von zahlenmäßig kleinen Bibliotheksbeständen. Eine Anpassung an die Notwendigkeiten, die beispielsweise
das WWW an ein Klassifikationsschema stellt, wird bereits dahingehend durchgeführt, daß man sich von dem aufzählenden Konzept weg in Richtung aspektorientierter Klassifikation bewegt. Typische Vertreter dieser Art der Klassifikation sind Bliss (siehe Abschnitt 4.3.4.5) und die Colon Classification (siehe
72
Abschnitt 4.3.4.6). Zu den Schwächen in der Ontologie ist gemäß [Koc98] auch
die mangelnde Berücksichtigung interdisziplinärer Themenbereiche zu zählen, die
in Zukunft mit Sicherheit verstärkt auftreten werden.
Schwächen bei der Einbindung neuer Wissensbereiche: Die Entwicklung von
Universalklassifikationen obliegt zumeist großen international zusammenarbeitenden Organisationen, die Änderungen der Themenhierarchie erst nach genauen und sehr zeitintensiven Prüfungen durchführen. Dadurch kommt es zur Einschränkung der Aktualität dieser Schemata in sich rasch verändernden Wissensbereichen, wie es momentan mit dem Internet der Fall ist.
Unzeitgemäße Terminologie: Jede Klasse einer Themenhierarchie wird durch einen
Bezeichner beschrieben, der möglichst exakt definiert, für welches Thema diese
Klasse zuständig ist. Beispielsweise wird bei der Dewey Decimal Classification
die Klasse 600 mit dem Bezeichner Technology beschrieben. Da viele Klassifikationssysteme bereits Ende des 19. Jahrhunderts entstanden und nicht in allen
Themenbereichen gleich intensiv überarbeitet wurden, kann es vorkommen, daß
die textuelle Definition der Klassen teilweise etwas veraltet ist. Diesem Umstand
wird nun Rechnung getragen, indem standardisierte Bezeichner (wie die Library of Congress Subject Headings, siehe dazu auch Abschnitt 4.3.4.2) verwendet
werden, um die Klassen entsprechend dem heutigen Sprachgebrauch zu definieren. [Koc98]
Die Themenhierarchie von Universalklassifikationen bietet zwar eine weitaus höhere
Konsistenz als die von selbstentwickelten Katalogen, die Qualität der Einordnung hängt
dennoch stark von der fachlichen Qualifikation der Autoren bzw. Editoren ab, oder aber
von der Genauigkeit einer automatischen Klassifikation. [Oeh96]
Welche Universalklassifikationen in Verbindung mit dem Internet eine Rolle spielen,
wird in den nachfolgenden Abschnitten untersucht. Bisher war die Entwicklung im
WWW hauptsächlich von den wenigen bereits existierenden, oft sehr unzulänglichen,
Beispielimplementierungen geprägt [Koc98]. In der Zwischenzeit gibt es eine Fülle von
Diensten, die auf einer Vielzahl von unterschiedlichen Klassifikationen basieren.
4.3.4.2
73
Dewey Decimal Classification (DDC)
Dieses Klassifikationsschema wurde von Melvil Dewey erdacht und erstmals im Jahre
1876 herausgegeben, mittlerweile hält man bei der 4 Bände umfassenden 21. Edition.
DDC19 kommt in weitaus mehr Bibliotheken als jede andere Universalklassifikation zum
Einsatz. Im Augenblick wird es in über 135 Ländern und in mehr als 30 Übersetzungen
verwendet, im WWW gibt es ebenfalls eine Reihe von Anwendungen, die auf DDC
basieren. [DDC99]
Verantwortlich für die Be- und Überarbeitung der DDC ist die in der Library of
Congress beheimatete Decimal Classification Division. Im Rahmen ihrer Tätigkeit werden jährlich mehr als 100.000 Dokumente nach Dewey klassifiziert, aus den dabei gesammelten Erfahrungen lassen sich wertvolle Rückschlüsse auf die Praxistauglichkeit
und die notwendigen Änderungen der Themenhierarchie gewinnen. Aufgrund der erkannten Trends werden Vorschläge zur Umgestaltung erarbeitet und an das Editorial
Policy Commitee, ein internationales Konsortium bestehend aus 10 Mitgliedern, weitergeleitet. Dieses Gremium diskutiert die Vorschläge und steht den Editoren der DDC
beratend zur Seite. [DDC99]
Im Augenblick gibt es DDC als Kurz- oder als Vollversion. Die Kurzversion ist
für kleinere Bibliotheken mit bis zu 20000 Büchern geeignet, die Vollversion unterliegt von der Größe des Buchbestandes her keinen Einschränkungen und ist auch in
elektronischer Form als Dewey for Windows verfügbar. Zwischen den in unregelmäßigen Abständen erscheinenden Editionen erhält man jährlich Zusätze und Korrekturen. [DDC99]
Struktur der Themenhierarchie
Das Wissen wird bei Dewey in 10 Hauptklassen eingeteilt, jede dieser Hauptklassen
kann wiederum in 10 Unterklassen aufgeteilt sein usw. Jede Stufe dieser Hierarchie
wird durch eine Ziffer zwischen 0 und 9 ausgedrückt, eine DDC-Nummer besteht dabei
aus mindestens 3 Ziffern [FS97]. Jede DDC-Nummer wird als Dezimalbruch interpretiert, wobei der Dezimalpunkt nur fiktiv ist und zum besseren Verständnis der Struktur
verwendet wird. Ein offenkundiger Vorteil dieser Sichtweise ist die unendliche Erweiterbarkeit ohne dadurch die bestehende Hierarchie zu beeinflussen. Zur Veranschaulichung
sind die Haupt- und Unterklassen der DDC in Anhang B.4 enthalten. Für speziellere
Klassen, die über die dritte Hierarchiestufe hinausgehen, wird die Notation zur besseren
Lesbarkeit durch einen Punkt erweitert. [DDC99]
Innerhalb der strukturellen Hierarchie besteht die Vereinbarung, daß jedes Thema
einen Teil der allgemeineren übergeordneten Themen darstellt. Jede Anmerkung, die
auf einer bestimmten Ebene der Hierarchie gemacht wird, gilt ebenso für alle gleichwertigen und untergeordneten Ebenen. Unterstrichen wird dieser Zusammenhang durch
die notationelle Hierarchie, ein Beispiel dafür zeigt Tabelle 4.3. Dabei bezeichnen kurze
DDC-Nummern allgemeine (übergeordnete) Klassen, während längere DDC-Nummern
speziellere (untergeordnete) Klassen darstellen. DDC-Nummern mit gleicher Länge
charakterisieren dementsprechend gleichwertige Klassen. [DDC99]
19
http://www.oclc.org/oclc/fp/index.htm
74
600
Technology (Applied sciences)
660
Chemical engineering and related technologies
663
Beverage technology
663.2
Wine and wine making
663.22
Specific kinds of grape wine
663.222
White wine
663.223
Red wine
663.224
Sparkling wine
Tabelle 4.3: Veranschaulichung der hierarchischen Notation von
DDC (Quelle: [VGU96])
Die Zuordnung einer Ressource zu einer DDC-Klasse oder umgekehrt verlangt die
systematische und korrekte Verwendung der mitgelieferten Hilfswerkzeuge. In der aktuellen Version ist dies vorallem der relative Index, dabei handelt es sich um eine alphabetische Liste von Themen mit der jeweiligen Zuordnung der Klasse. Darüberhinaus gibt
es eine beträchtliche Anzahl von Tabellen und Schemata, die für die Katalogisierung
von speziellen Wissensbereichen notwendig sind, z.B. zur Erfassung historischer Zeitperioden oder geographischer Gebiete. Dabei ist genauestens geregelt, welches Schema
man bei welchen Basisnummern verwenden darf. Einer Ressource können natürlich
auch mehrere DDC-Klassen zugeordnet werden. [DDC99]
Bei Dewey wird jeder Klassifikationsnummer ein Themenbezeichner bzw. eine Klassendefinition zugeordnet (z.B. 660 Chemical engineering, 150 Psychology). Wie bei
jeder Art von Klassifikation, so gibt es aber auch bei Dewey mitunter Themen, die
durch die Klassendefinition nicht exakt, nicht zeitgemäß oder nicht ausreichend beschrieben werden. In diesem Fall können zur detaillierten Beschreibung des Inhaltes
einer Ressource auch Library of Congress Subject Headings20 oder Subject Headings
von der Sears List21 herangezogen werden. Subject Headings sind Bezeichner, die von
einer offiziellen Stelle, wie beispielsweise der Library of Congress, einem bestimmten
Themenbereich und damit einer bestimmten DDC-Nummer zugeordnet werden. Die
Aufnahme neuer Wissensbereiche kann somit durch die Einführung neuer Bezeichner
und die Abbildung dieser Bezeichner auf bereits vorhandene DDC-Nummern erfolgen.
[DDC99]
In der elektronischen Dewey-Version sind zu jeder DDC-Nummer die fünf am häufigsten verwendeten LCSH angeführt, d.h. jene fünf Bezeichner, die für ein bestimmtes
Themengebiet bei der Katalogisierung durch die Library of Congress bevorzugt verwendet werden. Diese Bezeichner können zusätzlich indiziert werden, was bei der Suche
auf die richtigen Themengebiete von DDC führt. [VGU96]
20
21
http://lcweb.loc.gov/cds/lcsh.html
http://www.hwwilson.com/print/searslst.htm
75
Automatische Klassifikation
Die Klassifikation ”einer” Webressource in DDC sollte unter Zuhilfenahme der mitgelieferten Hilfsmittel keine Schwierigkeiten bereiten. Die optimistische Aussicht auf
eine verbreitete Anwendung zur Klassifikation ”aller” Webressourcen bringt jedoch eine Reihe von Problemen zum Vorschein, die es noch zu lösen gilt. Die Größe und das
Wachstum des WWW schließt die händische Klassifikation, einmal abgesehen von kleinen Teilbereichen, für die Masse der Webressourcen aus. Diese wäre manuell und von
den aufzuwendenden Kosten her nicht zu bewältigen. Aus diesem Grund beschäftigen
sich zahlreiche Forschungsprojekte mit der automatischen Klassifikation von Webressourcen. Ein Beispiel dafür ist das am OCLC initiierte Scorpion-Projekt22 , in dessen
Verlauf die Eignung der DDC als Themendatenbank für eine automatische Klassifikation untersucht wurde. Die Vorgehensweise und die gewonnenen Erkenntnisse sollen
nachfolgend kurz erläutert werden, um einen Einblick in diese Art der Metadatenerfassung zu erhalten.
DDC wird elektronisch mit Hilfe des ESS (Editorial Support System) verwaltet. Die
darin vorkommenden ESS-Records beinhalten alle Informationen, die zur Herstellung
der gedruckten Version von Dewey notwendig sind. Die bereits angesprochene Themendatenbank von Scorpion wurde aus ebendiesen ESS-Records aufgebaut und bildet das
Herzstück des Systems. Als Input fungiert ein zu klassifizierendes Dokument, der Output ist eine Menge von möglichen Themen für das Dokument [TSV97]. Gemäß [Koc98]
kommen hier sogenannte Extended Concept Trees zur Anwendung, die es gestatten,
neues Vokabular mit den festgelegten DDC-Klassen zu assoziieren. Dabei wird im Dokument und bzw. oder den Metadaten nach LCSH gesucht, für die bereits eine DDCZuordnung besteht. Die Library of Congress Subject Headings wurden bereits erwähnt;
kurz zusammengefaßt handelt es sich um Bezeichner, die einem konkreten Themenbereich und damit einer konkreten DDC-Klassennummer zugeordnet sind. Im Dokument
oder in den Metadaten gefundene LCSH führen somit auf die korrespondierenden DDCKlassennummern, die umgehend zur thematischen Beschreibung übernommen oder zur
Unterstützung einer händischen Klassifikation herangezogen werden können.
Ein wichtiger Punkt in einem derartigen System ist die Klassenintegrität der Themendatenbank, d.h. jede Themendefinition in der Datenbank sollte eindeutig sein. Eine
Themendefinition ist ein Bezeichner, der das Thema einer DDC-Klasse möglichst aussagekräftig beschreibt (z.B. wird die Hauptklasse 200 mit der Themendefinition Religion
beschrieben, die Unterklasse 220 mit Bibel). Da in der getesteten Dewey-Version mehr
als 30000 Klassen definiert sind, könnte man annehmen, daß es zu einigen Überschneidungen, Mehrdeutigkeiten oder Redundanzen innerhalb der Datenbank kommt. Wie
sich im Laufe der Untersuchungen jedoch herausstellt, ist dies bei Dewey kaum der
Fall, es zeigt einen hohen Grad an Klassenintegrität, die Konzepte sind genau definiert
und voneinander unabhängig. [TSV97]
Die Hinzunahme von hierarchischer Information der DDC in die Datenbank wirkt
sich darüberhinaus sehr positiv auf die Genauigkeit der automatischen Klassifikation
aus. Man kann mit Hilfe der Hierarchie zusätzliche Zusammenhänge prüfen, z.B. ob
mehrere Wörter innerhalb eines Dokumentes mit den Themenbezeichnern einer be22
http://orc.rsch.oclc.org:6109/
76
stimmten Hauptklasse und ihrer Unterklassen übereinstimmen. Die vorgeschlagenen
Klassen weisen eine weniger breite Streuung innerhalb der Themenhierarchie auf. Zusammenfassend stellt Scorpion unter Beweis, daß DDC auch eine sehr gute Basis für
eine automatisierte Zuordnung von Themen darstellt. [TSV97]
Anwendungen von Dewey
Wie schon zu Beginn (siehe Abschnitt 4.3) erwähnt wurde, ist die Verwendbarkeit der
Schemata zur Klassifikation von Internetressourcen von besonderem Interesse. Im Zuge
einer ebenfalls am OCLC durchgeführten Studie [VGO96] wurde DDC diesbezüglich
analysiert. Ausgangspunkt dieser Analyse bildete die Datenbank des vom OCLC betriebenen Suchsystems NetFirst23 . Die darin enthaltenen Internetressourcen (zum damaligen Zeitpunkt rund 45000) wurden von Fachleuten nach Dewey klassifiziert, statistische
Auswertungen sollten darüber Aufschluß geben, was in der Verwendung von DDC zu
beachten ist und welche Möglichkeiten sich für zukünftige DDC-Anwendungen ergeben.
Zunächst wurde auf Basis der DDC-Hauptklassen ermittelt, welche und wie oft
einzelne DDC-Nummern bei der Klassifikation der Dokumente vergeben wurden. Tabelle 4.4 zeigt die Ergebnisse dieser Auswertung, dabei ist zu erkennen, daß die überwiegende Mehrheit (ca. 84%) aller Dokumente in den oder hierarchisch unterhalb der DDCHauptklassen 000, 300, 500 und 600 angesiedelt sind. Diese ungleichmäßige Verteilung
ist auf das eingeschränkte Fachgebiet von NetFirst zurückzuführen, je nach Datenbestand können sich natürlich auch andere Häufigkeitsverteilungen ergeben. [VGO96]
DDC Hauptklasse
000 Generalities
100 Philosophy & psychology
200 Religion
300 Social sciences
400 Language
500 Natural sciences & mathematics
600 Technology (Applied sciences)
700 The arts
800 Literature & rhetoric
900 Geography & history
Gesamt
Anzahl verschiedener
DDC-Nummern
3.092
255
430
6.929
226
2.327
4.666
1.698
265
1.133
21.021
in %
14,17
1,21
2,05
32,96
1,08
11,07
22,20
8,08
1,26
5,39
100,00
Anwendungshäufigkeit
8.738
373
672
15.612
414
4.591
9.093
3.209
511
2.079
45.292
in %
19,29
0,82
1,48
34,47
0,91
10,14
20,08
7,09
1,13
4,59
100,00
Tabelle 4.4: Häufigkeitsverteilung von DDC-Klassen für die NetFirstDatenbank (Quelle: [VGO96])
Etwaige Anzeigetools könnten aufgrund dieser Verteilungsdaten unterschiedliche
Hierarchieteile selektiv anzeigen oder ausblenden. Die statistischen Daten zeigen auch
an, welche DDC-Klassen am häufigsten verwendet werden. Aufgrund dieser Kenntnis könnte man diesen Klassen gezielt zeitgemäße Bezeichner (z.B. aktuelle LCSH)
zuweisen, um die Verwendbarkeit für eine bestimmte Zielgruppe zu verbessern. In weiterer Folge sind auch selbst konfigurierbare Views durch die Zuordnung neuer Bezeichner denkbar. Insgesamt ist die statistische Auswertung von DDC-klassifizierten
23
http://www.oclc.org/oclc/netfirst/
77
Datenbeständen eine wichtige Grundlage für die Verbesserung von Klassifikations- und
Suchwerkzeugen. [VGO96]
In [VGU96] wurden die am häufigsten verwendeten Klassen von Yahoo auf die
korrespondierenden Klassen in DDC gemappt. Diese Zuordnung war für die Mehrzahl
der Klassen problemlos durchzuführen, was die Eignung von DDC zur Klassifikation
von Internetressourcen einmal mehr unter Beweis stellte. Es zeigte sich auch, daß DDC
über die notwendige Tiefe verfügt, um die Ressourcen nutzbringend suchbar zu machen.
Die Liste der Anwendungsmöglichkeiten einer Universalklassifikation im Zusammenhang mit der Organisation von elektronischen Ressourcen läßt sich beliebig verlängern. So wird beispielsweise in [Mun95] die Verwendung von DDC zur Strukturierung eines lokalen Dateisystems beschrieben. Hier wird auch sehr gut nachvollziehbar,
wie ein durchschnittlicher Computeranwender mit dem Problem der Datenorganisation
bei wachsender Datenmenge umgeht. Vom ersten Ansatz einer applikationsorientierten
Einteilung der Dateien, über eine projektbezogene Strukturierung und die Einführung
selbstentwickelter Hierarchien bis hin zur Verwendung von DDC. Eine weitverbreitete,
aber falsche Einschätzung ist es, daß die Verwendung einer Universalklassifikation in einer thematisch begrenzten Anwendung, wie sie die Organisation eines Dateisystems auf
den ersten Blick darstellt, zwangsläufig zu einigen übervollen Kategorien führen muß,
während ein Großteil der Hierarchie weitgehend leer bleibt. Berücksichtigt man die jedem Bibliothekar geläufige Regel der Anwendung, wonach jede Ressource genau dorthin
klassifiziert wird, wo sie verwendet wird, dann ergibt sich eine gleichmäßige Verteilung
über die gesamte Themenhierarchie. Beispielsweise wird ein Multimedialexikon über
Vögel nicht unter dem Themenbereich Computer oder Multimedia, sondern vielmehr
unter dem Bereich Vögel klassifiziert. [Mun95]
Grundsätzlich überwiegen die positiven Aspekte von DDC, man muß sich jedoch
auch darüber im Klaren sein, daß die Hinwendung zu einer Universalklassifikation
den Anwender einerseits von vielen schwierigen Entscheidungen entbindet, andererseits aber gerade diese Entscheidungen zu einer kritischen Betrachtung der Materie
beigetragen haben. Die Klassifikationen gestatten nur wenig Individualität und Zwischentöne bei der Themenzuordnung, dies ist eben der Preis, den man für eine effiziente
Suche nach Information zu bezahlen hat. [Mun95]
4.3.4.3
Universal Decimal Classification (UDC)
Hierbei handelt es sich um eine ausführliche Erweiterung der bereits beschriebenen
DDC. UDC24 wurde von den beiden belgischen Bibliothekaren Paul Otlet und Henri
LaFontaine erstmals zwischen 1904 und 1907 in französischer Sprache veröffentlicht.
Im Laufe der Jahre wurde es stark überarbeitet und weiterentwickelt, sodaß es in der
vorliegenden Form auch zur Klassifikation von Kunst- oder Multimediaobjekten geeignet ist. Die Struktur gestattet es, neue Wissensbereiche auf einfache Art und Weise
zu integrieren. Die Notation ist sprachunabhängig, die Klassifikationscodes beinhalten
lediglich arabische Ziffern und einige sehr gebräuchliche Trennzeichen. Die Voll- und
gekürzten Versionen von UDC sind in mittlerweile 23 verschiedenen Sprachen erhältlich. Vor einigen Jahren wurde die Weiterentwicklung von UDC in neue Bahnen gelenkt.
24
http://www.udcc.org/
78
Den Kern der Klassifikation bildet nunmehr das MRF (Master Reference File), eine
internationale vielsprachige Datenbank, die jährlich upgedatet wird und als Quelle aller zukünftigen Editionen dient. Das MRF enthält etwa 61000 Klassen und kann auf
Lizenzbasis in eigenen Anwendungen eingesetzt werden. [UDC99]
Hinsichtlich der hierarchischen Struktur gilt für UDC dasselbe wie bei DDC (siehe
Abschnitt 4.3.4.2). In der Themenhierarchie, die Haupt- und Unterklassen sind im
Anhang B.5 ersichtlich, sind die Bereiche Wissenschaft und Technologie wesentlich
feiner unterteilt als beispielsweise Kunst und Sozialwissenschaften. Das Wissen wird
als zusammenhängendes System betrachtet, das sich aus miteinander in Beziehung
stehenden Teilen zusammensetzt. [UDC99]
Als Hilfsmittel zur regelkonformen Klassifizierung von Ressourcen stellt UDC einige
Tabellen zur Verfügung. Die Haupttabellen (siehe Anhang B.5) geben einen Überblick
über die Wissensgebiete und ihre hierarchische Unterteilung. Die Hilfstabellen enthalten alle anwendbaren Hilfszeichen, die zur Verbindung zweier oder mehrerer UDCKlassen verwendet werden können. Damit lassen sich Beziehungen zwischen Themen
ausdrücken und es gelingt, verwandte Konzepte und Informationen geeigneter darzustellen, als es in Klassifikationsschemata mit einer starren Themenhierarchie möglich
wäre. In Tabelle 4.5 sind einige Beispiele für die Darstellung von Beziehungen in UDC
angegeben. Zu unterscheiden sind dabei allgemeine Hilfsoperatoren, die in der gesamten Themenhierarchie anwendbar sind, und spezielle Hilfsoperatoren, die nur in klar
definierten Teilbereichen der Hierarchie auftreten dürfen. [UDC99]
Anwendung allgemeiner Hilfsoperatoren
59+636
592/599
17:7
31:[622+669](485)
59=20
17"19"
622.002.5
Zoologie und Tierzucht
alles zum Thema Zoologie (Klassen 592 bis 599)
Ethik bezogen auf Kunst
Statistiken über Bergbau und Metallurgie
in Schweden
Zoologie, wobei Dokumente in Englisch verfaßt sind
Ethik im 20. Jahrhundert (bzw. 1900 bis 1999)
Bergbau: Werkzeuge, Maschinen, Ausrüstung
Anwendung spezieller Hilfsoperatoren
62-1
547.1’13
generelle Charakteristik von Maschinen etc.
(in der Klasse Ingenieurswesen)
organisch-metallische Verbindungen
(in der Klasse Organische Chemie)
Tabelle 4.5: Beispiele für die Klassifikation nach UDC
(Quelle: [UDC99])
4.3.4.4
79
Library of Congress Classification (LCC)
Das Schema wurde ursprünglich von Herbert Putnam im Jahre 1904 eingeführt, und
wird hauptsächlich in amerikanischen Bibliotheken verwendet. LCC25 enthält eine Reihe von Mechanismen, die speziell auf die Verwaltung der umfangreichsten Buchsammlung der Vereinigten Staaten, der Library of Congress, abzielen [FS97]. Der Schwerpunkt auf amerikanische Themen zeigt sich bereits in der Aufstellung der Hauptklassen,
die im Anhang B.6 zu finden ist. In Tabelle 4.6 wird am Beispiel einiger Unterklassen
der Hauptklasse L (Erziehung) die bei LCC verwendete Notation verdeutlicht.
L
LB
LB
LC
107
1050.9-1091
2381-2391
215-238.4
LD
LF
LG
LH
LT
13-7501
1311-1537
21-961
1-9
6-1001
Erziehung allgemein, Kongresse
Theorie und Praxis der Erziehung, Psychologie
Theorie und Praxis der Erziehung, Akademische Grade
Spezielle Aspekte der Erziehung,
Gesellschaft und Schule
Institutionen, Amerikanische Universitäten
Institutionen, Österreich
Institutionen, Asien
Schulmagazine und Artikel
Lehrbücher
Tabelle 4.6: Beispiele für die Klassifikation nach LCC
(Quelle: http://lcweb.loc.gov/catdir/cpso/lcco/lcco.html)
Im Gegensatz zu allen anderen Universalklassifikationen finden sich Themenbereiche wie amerikanische Geschichte oder Militär auf der obersten Hierarchiestufe. Da das
xFIND-Projekt jedoch eine internationale Verwendbarkeit zum Ziel hat, wird LCC in
dieser Arbeit nicht weiter untersucht. Für eine umfangreiche Beschreibung von LCC
und eine Gegenüberstellung mit anderen wichtigen Klassifikationen sei auf [Dah74]
verwiesen.
25
http://lcweb.loc.gov/cds/classif.html
4.3.4.5
80
Bliss Bibliographic Classification (BC)
Dieses Schema wurde 1940 vom Amerikaner Henry E. Bliss unter der Bezeichnung BC1
erstmals veröffentlicht. Im Laufe der Zeit wurden einige starke Änderungen vorgenommen, wodurch das 1977 herausgegebene BC226 eigentlich nur mehr wenige Gemeinsamkeiten mit dem alten System teilt. BC2 steht unter Aufsicht der Bliss Classification
Association und ist durch die folgenden Merkmale charakterisiert [Bliss99]:
• Die Grundlage für jede Klassifikation bilden Aspekte, beispielsweise wird der Bereich Medizin in die Teilaspekte Typen von Menschen, Bestandteile und Systeme
des Menschen zerlegt.
• Eine konsistente Reihenfolge der Aspekte stellt sicher, daß die Position einer zusammengesetzten Klasse innerhalb der Hierarchie leicht zu finden ist. Bei der
Zusammenfassung von Aspekten wird immer Allgemeineres vor Speziellerem gereiht.
• Die Notation weist eine sehr breite Zeichenbasis auf, sie wird durch die Ziffern
1 bis 9 und die Buchstaben A bis Z gebildet. Die Codierung versucht nicht ausnahmslos die Hierarchie zu reflektieren, sie ist vielmehr bestrebt, die einzelnen
Aspekte möglichst genau auszudrücken. In dieser Hinsicht nimmt BC2 eine Sonderstellung ein, denn kein anderes allgemeine Schema kann diesen Grad der Spezialisierung erreichen, ohne dafür wesentlich längere Bezeichner verwenden zu
müssen.
QLV EL
Heimpflege älterer Personen
Es erfolgt eine Zusammenführung der Klassen QLV (ältere Personen)
und QEL (Heimpflege), wobei beide Klassen in der Hauptklasse
Q (Sozialfürsorge) liegen.
QLP KPE BCP
Zusammenarbeit Eltern und Vorschulkinder
Diese Beschreibung setzt sich zusammen aus QLP (Vorschulkinder),
QKP (Eltern), QE (Soziale Dienste) und QBC P (Zusammenarbeit).
Tabelle 4.7: Beispiele für die Klassifikation nach BC2
(Quelle: [Bliss99])
BC2 besteht aus 22 Bänden, die jeweils ein oder zwei Hauptklassen behandeln,
eine Übersicht über die Hauptklassen enthält Anhang B.7. Tabelle 4.7 listet einige
Beispiele für die Klassikation mittels BC2 auf. Dabei wird so vorgegangen, daß zunächst
in eine ”Wer”-Kategorie und danach in eine ”Was”-Kategorie eingeteilt wird. Sind
Teile der Notation für aufeinanderfolgende Klassen gleich, so können diese Teile in
der Folge weggelassen werden. Zur besseren Lesbarkeit werden in der Notation jeweils
Dreiergruppen gebildet. Abschließend ist noch anzumerken, daß im Augenblick erst 16
Bände verfügbar sind, die verbleibenden 6 Bände werden noch überarbeitet und bis
zum Jahr 2003 sukzessive veröffentlicht. [Bliss99]
26
http://www.sid.cam.ac.uk/bca/bcahome.htm
4.3.4.6
81
Colon Classification (CC)
Die CC wurde 1933 vom indischen Bibliothekar Shiyali R. Ranganathan vorgestellt
und war die erste Klassifikation, bei der das Themengebiet in Aspekte zerlegt wird.
Die Einteilung der einzelnen Aspekte in Klassen erfolgt aufgrund ihrer Verwendung
und ihrer Beziehungen, die durch einen Doppelpunkt (colon) ausgedrückt werden. Die
Einzelklassifikationen werden schließlich zu einer Gesamtklassifikation zusammengesetzt. [FS97]
Die CC basiert auf der Beobachtung, daß andere Universalklassifikationen prinzipiell versuchen, alle vorhandenen Themen erschöpfend aufzulisten und jede zu klassifizierende Ressource in eine exakt definierte Kategorie einzuteilen. Da allerdings das
vorhandene Wissen stark ansteigt, laufend neue Wissensbereiche erschlossen werden
und eine vermehrte Interdiziplinarität erkennbar ist, kann ein aufzählendes Schema
zukünftigen Anforderungen nicht mehr genügen, ein aspektorientiertes Schema dagegen schon. Bemerkenswert ist dabei, daß in der CC bereits aspektorientierte Analyseverfahren angewandt werden, die gerade in den letzten Jahren in Verbindung mit
der Speicherung und Wiedergewinnung von Information verstärkt erforscht werden.
[Gla98]
Beeinträchtigt wird das aspektorientierte Konzept der CC durch eine relativ komplexe Notation, der Zeichenvorrat enthält unter anderem auch griechische Buchstaben [Gla98]. Die nachfolgende Tabelle 4.8 enthält ein Beispiel zur Klassifikation gemäß
CC, das die Mächtigkeit und Eleganz dieses Schemas verdeutlicht. Angegeben wird
der Klassifikationsstring, seine Bedeutung in Worten und eine umgangssprachliche Beschreibung des Themas.
L,45;421:6;253:f.44’N5
Medizin,Lungen;Tuberkulose:Behandlung;Röntgenstrahlung:Forschung.Indien’1950
Beschrieben wird somit die "in Indien in den 50er Jahren
durchgeführte Forschung zur Behandlung von Lungentuberkulose
mittels Röntgenstrahlung".
Tabelle 4.8: Beispiel für die Klassifikation nach CC (Quelle: [Gla98])
Die CC bietet gegenüber anderen Klassifikationsschemata die folgenden Vorteile [Gla98]:
• Das Schema benötigt bei gleichem Grad an Detailliertheit weniger Platz als das
Schema einer vergleichbaren aufzählenden Klassifikation. Insgesamt erlaubt es
einen hohen Grad an Spezialisierung.
• Es gestattet eine Kettenindizierung, man hat damit Zugriff auf jeden einzelnen
Aspekt der Gesamtklassifikation. Dadurch ist es möglich, die Einzelaspekte beliebig umzuordnen und dennoch die korrekte Gesamtklassifikation zu erhalten.
Einen ähnlichen Mechanismus macht sich beispielsweise Yahoo zunutze, durch
die dort verwendeten symbolischen Links gelangt man über verschiedene Wege
zum selben Ergebnis. Damit begegnet man sehr effektiv den unterschiedlichen
Zugangs- und Sichtweisen der Benutzer zum und auf das Suchsystem.
4.3.5
82
xFIND und Klassifikation
Wie sich im vorangegangenen Abschnitt 4.3.4 gezeigt hat, eignen sich Universalklassifikationen auch ausgezeichnet zur Katalogisierung von Internetressourcen. Unter den
wichtigsten Vertretern bietet sich vorallem DDC aufgrund der herausgearbeiteten Vorteile (siehe Abschnitt 4.3.4.2) und der in Tabelle 4.9 ersichtlichen Merkmale für einen
Einsatz in Internetapplikationen an. Die weite Verbreitung von DDC in traditionellen Bibliotheken und die zunehmende Zahl an Services, die dieses Schema verwenden,
bestätigen die Praxistauglichkeit dieser Klassifikation sehr gut.
DDC
UDC
LCC
BC
CC
Kurzausgaben
ja
ja
nein
ja
nein
Elektr.Ausgaben
ja
ja
ja
nein
nein
Hauptsprache
engl franz/dt
engl
engl
engl
Übersetzungen
30
23
Notation
Zahlen
Zahlen Buchst.u.Zahlen Buchst. Buchst.u.Zahlen
Tabelle 4.9: Kenndaten der Universalklassifikationen (Quelle: [Dah74])
In dem vom xFIND-Suchsystem verwendeten Metadatenschema xQMS (siehe Abschnitt 4.2.5) wird daher für das Attribut xQMS.Content.Topic standardmäßig die
Dewey Decimal Classification vorausgesetzt. Eine Webressource kann durch eine beliebige Anzahl von DDC-Nummern näher charakterisiert werden, die einzelnen DDCNummern werden in einem String untergebracht und sind durch Beistriche getrennt.
Neben DDC können zusätzlich fachspezifische Klassifikationen (Abschnitt 4.3.3)
zum Einsatz kommen, um einen bestimmten Themenbereich detaillierter zu beschreiben. Von Interesse ist hier vorallem das ACM Computer Classification System (siehe
Abschnitt 4.3.3.3), das standardmäßig zur Katalogisierung von Ressourcen, die mit
dem Computer in Zusammenhang stehen, herangezogen wird. In xQMS finden spezielle Klassifikationen durch zwei zusätzliche Attribute ihre Berücksichtigung, es sind
dies xQMS.Content.Alt Topic (zusätzliche Themen gemäß des nachgenannten Klassifikationsschemas) und xQMS.Content.Alt Classident (zusätzlich verwendetes Klassifikationsschema). Das folgende Beispiel illustriert die thematische Klassifikation einer
Webressource, welche die Formulierung von Anfragen zur Suche im WWW zum Inhalt
hat.
xQMS.Content.Topic
xQMS.Content.Alt Topic
xQMS.Content.Keywords
=
=
=
=
"004, 020"
"H.3.3, H.3.4"
"ACM"
"retrieval, metadata, content"
4.4
83
Zusammenfassung
In diesem Kapitel wurde zunächst die Notwendigkeit von beschreibenden und beurteilenden Metadaten für zukünftige Suchanwendungen deutlich gemacht. Der Erfolg
der Suche und die erzielte Relevanz der Suchergebnisse hängen entscheidend davon ab,
welche Art von Metadaten erfaßt werden und welche Konventionen bei der Erfassung
einzuhalten sind. Unter diesen Voraussetzungen wurde ausgehend von der Analyse aktueller Metadatenschemata das xFIND Quality Metadata Scheme definiert.
Innerhalb dieses Schemas kommt den Attributen, die eine thematische Beschreibung
des Inhaltes einer Webressource vornehmen, besondere Bedeutung zu. Eine Gegenüberstellung von thematischen Klassifikationsschemata zeigt deren Stärken und Schwächen
auf und liefert eine Entscheidungsgrundlage für das xFIND-Projekt. Es zeigt sich, daß
selbstentwickelte Themenhierarchien i.a. nicht für die Klassifikation von akademischen
Ressourcen ausgerichtet sind, vielmehr zielen sie auf aktuelle Themengebiete ab und
sind in vielen Bereichen zu allgemein gehalten. Im Gegensatz dazu sind Universalklassifikationen und fachspezifische Klassifikationen dahingehend entwickelt, alle bzw.
spezielle Themenbereiche möglichst wissenschaftlich zu charakterisieren. Dies schließt
jedoch nicht aus, daß eine Universalklassifikation nicht auch für aktuelle Themengebiete
geeignet ist, was z.B. durch DDC unter Beweis gestellt wird.
Aufgrund der gewonnenen Erkenntnisse wurde für das xFIND-Suchsystem standardmäßig die thematische Klassifikation nach Dewey festgelegt, darüberhinaus kann
eine erweiterte Klassifikation mit einem ausgewählten Schema wie z.B. ACM CCS erfolgen. Die Untersuchungsergebnisse fließen direkt in den nachfolgenden Gestaltungsbereich ein, der die Entwicklung eines Brokerprototyps zur Aufgabe hat. Der Broker
fungiert als Informationsvermittler zwischen den anfragenden xFIND-Clients und den
thematisch, geographisch oder anderweitig gruppierten xFIND-Indexern. Nach einer
kurzen Einführung in die Theorie der Metasuche erfolgt die Dokumentation der Architektur des Broker und der wesentlichen Mechanismen zur thematischen Verteilung von
Suchanfragen, sowie zum Caching und zur Nachbearbeitung der Suchergebnisse.
Teil II
Gestaltungsbereich
84
Kapitel 5
Brokertheorie
Der Gestaltungsbereich dieser Arbeit hat den Entwurf und die Implementierung eines
Brokerprototyps für das xFIND-Suchsystem zur Aufgabe. Der Broker soll als ”Suchpunkt” für Internetbenutzer verwendbar sein, wobei eine Spezialisierung auf bestimmte
Fachgebiete und eine individuell wählbare Informationsdarstellung ermöglicht werden
soll.
Neben der Berücksichtigung der im Untersuchungsbereich herausgearbeiteten Merkmale erfahren zunächst jene Bereiche eine genauere Betrachtung, die bei der Entwicklung des Brokerprototyps unmittelbar zu beachten sind. Die Rolle des xFIND-Broker
als Kontaktstelle für die Benutzer des Suchsystems wurde in Abschnitt 2.1 bereits
erläutert. In Abwandlung und Erweiterung dieses Konzeptes lassen sich einzelne Broker
auf konkrete Anforderungen individueller Benutzer oder Benutzergruppen anpassen.
Ein sogenannter ”Personal Broker” kann sich auf bestimmte Themenbereiche spezialisieren, ebenso kann ein geographisches Gebiet abgedeckt werden oder eine projektspezifische Zusammenfassung von Indexern erfolgen. Auf diese Art und Weise kann
der Broker auf die sich ändernden Problemstellungen reagieren und so dem Benutzer
eine dynamische Hintergrundbibliothek zur Verfügung stellen. Der Broker erhält die
Information von xFIND-Indexern oder von externen Informationsdiensten, die über
xFIND-Wrapper suchbar gemacht wurden. Die Verteilung der Suchanfrage und die Zusammenführung der Information aus mehreren Quellen ist ein Konzept, das aufgrund
der verteilten Struktur des Internet selbst und der wachsenden Zahl an Informationsanbietern zunehmend wichtiger wird. In erster Näherung handelt es sich bei einem Broker
um einen sogenannten Metasuchdienst, d.h. eine übergeordnete Anwendung, die eine
Suchanfrage von einem Client entgegennimmt, sie an mehrere Suchdienste verteilt, die
Suchergebnisse einsammelt, eine Ergebniszusammenfassung durchführt und schließlich
das aufbereitete Gesamtergebnis an den Client zurückliefert.
Das Prinzip der Metasuche bildet die Basis, auf der die Mehrwertdienste (value
added services) eines Broker aufbauen. In diesem Abschnitt werden daher die Grundlagen der Metasuche erläutert, wichtige Funktionalitäten vorgestellt und anhand konkreter Metasuchdienste analysiert. Daraus lassen sich jene Kriterien ableiten, die bei
der Entwicklung des Brokerprototyps für das xFIND-Suchsystem zu berücksichtigen
sind.
85
KAPITEL 5. BROKERTHEORIE
5.1
86
Motivation der Metasuche
Es wurde bereits in der Einleitung (siehe Abschnitt 1.1) angesprochen, daß das exponentielle Wachstum der Datenmenge im WWW den Suchdienstbetreibern zunehmend
Probleme bereitet. Den Benutzerforderungen nach hoher Qualität und Vollständigkeit
der Suchergebnisse kann nicht mehr ausreichend nachgekommen werden. Um die Situation zur Vollständigkeit zu verdeutlichen, wurde in [SBS98] eine grobe Abschätzung
des Abdeckungsgrades von einzelnen Suchdiensten und Metasuchdiensten im WWW
wie nachfolgend beschrieben durchgeführt.
Server ............... Anzahl der WWW-Server
DataPerServer ........ durchschnittliche Datenmenge pro Server (in MB)
IndexedWebpages ...... Anzahl indizierter Webseiten eines Suchdienstes
TextPerPage .......... durchschnittliche Textmenge pro Webseite (in kB)
TextToDataRatio ...... Verhältnis Text zu nicht-indizierbaren Daten (in %)
TotalDataWWW
= Server * DataPerServer
TotalIndexedText = IndexedWebpages * TextPerPage
Daraus ergibt sich schließlich der von einem Suchdienst erzielte Abdeckungsgrad:
Coverage =
T otalIndexedT ext
T otalDataW W W ∗ T extT oDataRatio
(5.1)
Im Zuge der Studie werden sehr konservativ geschätzte Werte eingesetzt, wodurch sich
ein Abdeckungsgrad zwischen 8 und 40 % des gesamten im WWW indizierbaren Textes
ergibt. Daraus geht klar hervor, daß ein einzelner Suchdienst nicht in der Lage ist, die
Vollständigkeit zu gewährleisten. Da jedoch unterschiedliche Suchdienste unterschiedliche Bereiche des WWW abdecken, kann man durch den Einsatz von Metasuchdiensten
einen höheren Abdeckungsgrad erzielen. Dies soll anhand folgender Abschätzung verdeutlicht werden:
HitsMetasearch ....... Anzahl der vom Metasuchdienst gelieferten Treffer
HitsBestSinglesearch.. Anzahl der vom besten Suchdienst gelieferten Treffer
Duplicates ........... Anzahl der Duplikate, d.h. gleicher Dokumente
Ef f iciency =
HitsM etasearch − Duplicates
HitsBestSinglesearch
(5.2)
87
Die Anzahl der Duplikate variiert je nach verwendetem Erkennungsalgorithmus. Zum
Teil sind diese Algorithmen noch nicht besonders ausgereift, daher werden die Duplikate in der Berechnung nicht berücksichtigt. Unter dieser Voraussetzung ergibt sich eine
Effizienz der Metasuche zwischen 2 und 5, was bedeutet, daß die Metasuche zwischen
2 und 5 mal soviele Suchergebnisse zutage fördert wie der beste abgefragte Einzelsuchdienst.
Eine neuere, von [LG99] durchgeführte Studie, ortet eine weitere Verschlimmerung
der Situation. Abbildung 5.1 zeigt die relative Abdeckung der Suchdienste für 1050
Anfragen, die in einem bestimmten Zeitraum gestellt wurden. Die Grafik a) bezieht
die erzielten Ergebnisse auf die Gesamtabdeckung durch alle Suchdienste, Grafik b)
bezieht sie hingegen auf die geschätzte Größe des WWW (zum Zeitpunkt der Studie
ca. 800 Mio. Webseiten).
Abbildung 5.1: Abdeckungsgrad von WWW-Suchdiensten
(Quelle: [LG99])
Daraus ist ersichtlich, daß der größte Suchdienst nur noch 16 % des WWW abdeckt.
Unter Berücksichtigung von Überschneidungen der Datenbestände ergibt sich bei der
Zusammenfassung aller analysierten Suchdienste immerhin ein Gesamtabdeckungsgrad
von 42 %. Diese Studie belegt wiederum, daß Metasuchdienste dringend benötigt werden, um eine umfassendere Suche gewährleisten zu können.
5.2
88
Grundlagen der Metasuche
Der Vorzug einer umfassenderen Suche wurde rasch erkannt und so findet man im
WWW eine ganze Reihe von Metasuchdiensten. Weniger verbreitet und nicht mit Metasuchdiensten zu verwechseln sind die All-in-one-Formulare, die verschiedene Suchdienste nicht parallel sondern sequentiell abfragen und keine weiterführenden Verarbeitungsschritte (z.B. Zusammenfassen der Ergebnisse) durchführen. Bei den traditionellen Metasuchdiensten kann man eine Unterscheidung in client- und server-basierende
Lösungen vornehmen. [SBS98]
5.2.1
Client-basierende Metasuchdienste
Sie werden lokal am Computer des anfragenden Benutzers betrieben, was einerseits
bestimmte Funktionen erleichtert, z.B. das Speichern und Nachbearbeiten von Suchergebnissen, andererseits aber auch Probleme mit sich bringt. [SBS98]
last-mile-Problem: Die Internetverbindung zwischen Provider und Benutzer (lastmile) verfügt üblicherweise über eine geringe Bandbreite. Da der Metasuchdienst
lokal läuft und die Nachbearbeitung der Suchergebnisse ebenfalls lokal durchgeführt wird, müssen alle Suchergebnisse - inklusive der Duplikate - angefordert
werden, was zu sehr hohen Datenflüssen und langen Übertragungszeiten führt.
update-Problem: Suchdienstbetreiber ändern häufig ihre Ein- und Ausgabeformate,
die Software des Metasuchdienstes muß aufgrunddessen ebenfalls geändert werden. Dazu benötigt der lokal laufende Metasuchdienst eine flexible Programmstruktur, die möglichst rasch an die neuen Verhältnisse angepaßt werden kann
(z.B. Plug-ins oder gesamter Metasuchdienst als Java-Applet, dessen jeweils aktuellste Version vom Webserver geladen werden kann).
5.2.2
Server-basierende Metasuchdienste
Sie werden an beliebigen Orten im Internet betrieben und sind in der Regel wie jeder
andere Suchdienst im WWW via HTTP erreichbar. Die wesentlichen Merkmale serverbasierender Metasuchdienste sind [SBS98]:
• Parallele Abfrage mehrerer Einzel- oder auch anderer Metasuchdienste durch beliebige Clients.
• Unterstützung von boolschen Operatoren (zumindest AND und OR). Dabei ist zu
beachten, daß viele Suchdienste stillschweigend von AND auf OR umschalten, falls
für die AND-Verknüpfung keine Ergebnisse gefunden werden. Damit erhält der
Benutzer i.a. zwar einige Ergebnisse, gleichzeitig wird jedoch die Ergebniszusammenfassung des Metasuchdienstes verfälscht.
• Ergebniszusammenfassung (z.B. Ranking, Sortierung der Resultate)
• Eliminierung von Duplikaten
89
• Beschreibung der Ergebnisse. Der Metasuchdienst sollte alle Informationen an
den Benutzer weiterleiten, die er von den abgefragten Suchdiensten erhält. Eine
Filterung der Information darf nur auf ausdrückliche Anforderung des Benutzers
durchgeführt werden, um z.B. eine kompakte Darstellung zu erhalten.
• Einheitliche Bedienung. Die spezifischen Erfordernisse einzelner Suchdienste bleiben dem Benutzer verborgen.
• Vollständige Suche, d.h. es sollten möglichst alle Ergebnisse der einzelnen Suchdienste miteinbezogen werden.
Eine Auflistung aktueller Metasuchdienste nach den genannten Kriterien enthält Anhang A.3.
5.3
WWW Metasuchdienste vs. xFIND-Broker
Anhand konkreter Fallbeispiele wird nachfolgend analysiert, welche Funktionen bereits
im WWW angeboten werden. Dabei werden jene Funktionen genauer untersucht, die
auch für den xFIND-Broker von Interesse sind. Am Ende dieses Abschnittes wird beschrieben, welche dieser Funktionen in die verteilte Umgebung des xFIND-Suchsystems
integriert werden und was dabei zu beachten ist.
5.3.1
Formulierung der Suchanfrage
Die Analyse beginnt mit den Userinterfaces der Metasuchdienste, in vielen Fällen werden von den Betreibern zumindest zwei Varianten angeboten. Eine einfache Suche, die
lediglich die Eingabe von Suchwörtern erlaubt, und eine Profisuche, die viele Optionen
zur Einschränkung der Suche bereitstellt. Da die gesamte Funktionalität der Metasuchdienste von Interesse ist, wird hier immer die Profisuche betrachtet. Dabei steht nicht
das Layout der Suchformulare im Vordergrund, sondern vielmehr die Optionen und deren Werte, die u.U. sogar Rückschlüsse auf die Programmstruktur der Metasuchdienste
ermöglichen. Die Optionen lassen sich - dem Ablauf einer Suche entsprechend - in drei
Kategorien aufschlüsseln.
5.3.1.1
Optionen, die den Inhalt der Suche betreffen
• Suchworteingabe
Jedes Suchformular stellt als zentrales Element ein Textfeld zur Verfügung, in
das die Suchanfrage im Klartext eingegeben werden kann. Damit verbunden ist
eine Auswahl die angibt, wie die Suchwörter miteinander in Beziehung stehen.
Zumeist werden die boolschen Operatoren AND und OR angeboten (siehe Abbildungen 5.2 und 5.3), darüberhinaus läßt sich angeben, ob der gesamte Suchausdruck als Phrase interpretiert werden soll (siehe Abbildung 5.2). Klammerungen,
Inklusions- und Exklusionsoperatoren, sowie spezielle Operatoren sind üblicherweise nicht erlaubt.
90
Abbildung 5.2: Suchinterface Metacrawler
• Suchbereichseinschränkung
Der Benutzer kann Angaben darüber machen bzw. auswählen, wo gesucht werden
soll. Die Einschränkung erfolgt beispielsweise nach:
– Internetbereichen
z.B. WWW, Newsgroup oder MP3 (siehe Abbildungen 5.2, 5.4, 5.5)
– geographischen Gebieten
z.B. international oder nur im deutschsprachigen Raum, in bestimmten
Ländern oder Regionen (siehe Abbildung 5.2)
Abbildung 5.3: Suchinterface Highway61
91
Abbildung 5.4: Suchinterface Mamma
Abbildung 5.5: Suchinterface C4
5.3.1.2
Optionen, die die Durchführung der Suche betreffen
• Suchdienstauswahl
Der Benutzer kann entscheiden, welche Suchdienste in Anspruch genommen werden sollen. Zumeist wird vom Metasuchdienst eine Vorauswahl der besten Suchdienste getroffen, die vom Benutzer übernommen oder verändert werden kann
(siehe Abbildung 5.8). Bei Profusion1 (siehe Abbildung 5.7) kann man sich weiters für die besten oder die schnellsten drei Suchdienste entscheiden.
• Timeout
Gibt an, wie lange man maximal auf Suchergebnisse warten möchte. Diese Option hat entscheidenden Einfluß auf die Vollständigkeit einer Suche. An diesem
Punkt sei nochmals darauf hingewiesen, daß eine Metasuche in erster Linie auf
1
http://www.profusion.com/
92
Vollständigkeit und Qualität (durch zusätzliche Aufbereitung der Ergebnisse)
abzielt, was naturgemäß längere Such- und Bearbeitungszeiten mit sich bringt.
Die Timeoutwerte erstrecken sich bei einigen Metasuchdiensten daher bis in den
Minutenbereich (siehe Abbildungen 5.4 und 5.8).
• Anzahl der Ergebnisse pro Suchdienst
Es kann vorgegeben werden, wieviele Treffer die Suchdienste maximal zurückliefern sollen. Dieser Parameter hat ebenfalls eine starke Auswirkung auf die
Suchzeit, je mehr Treffer angefordert werden, umso aufwendiger gestaltet sich
die Nachbearbeitung der Ergebnisse. Abhängig von der Anzahl der befragten
Suchdienste nimmt diese Option Werte im Bereich 0 bis maximal 100 (siehe Abbildung 5.5) an.
Abbildung 5.6: Suchinterface TheBigHub
Abbildung 5.7: Suchinterface Profusion
5.3.1.3
Rückgabeoptionen
• Anzahl der Ergebnisse pro Seite
• Optionen zur Ergebnisdarstellung
z.B. standard oder kompakt, diverse Anordnungen nach Relevanz, Site oder Suchdienst (siehe Abbildung 5.2)
93
Abbildung 5.8: Suchinterface Metager
• Zusatzoptionen
– Ob beispielsweise Links, die im Suchergebnis angeklickt werden, in einem eigenen Browserfenster geöffnet werden sollen (siehe Abbildungen 5.3
und 5.8).
– Ob eine Linküberprüfung durchgeführt werden soll (siehe Abbildungen 5.7
und 5.8), diese wirkt sich sehr stark auf die Nachbearbeitungszeit aus!
– Ob Duplikate entfernt werden sollen, hat ebenfalls Auswirkung auf die Nachbearbeitungszeit!
5.3.2
Ablauf der Suche
Einige Metasuchdienste zeigen dem Benutzer Informationen über den Fortschritt der
Suche an. Man geht dabei von der Überlegung aus, daß die Benutzer eher zu warten
bereit sind, wenn sie darüber informiert werden, worauf sie warten und vorallem wie
lange noch. Die Statusmeldungen geben daher an,
• welche Suchdienste bereits geantwortet haben
• wieviele Treffer die Suchdienste geliefert haben
• die exakte Antwortzeit jedes Suchdienstes
• welche Suchdienste noch ausständig sind
94
• wie lange maximal noch gesucht wird
• ob Fehler aufgetreten sind (Fehlerursache)
Neben den sehr nützlichen Statusinformationen zeigen Metasuchdienste vermehrt aktuelle Nachrichten, Werbung, Lebensweisheiten o.ä. an, um dem Benutzer die Wartezeit
zu verkürzen. Darüberhinaus kann eine parallele Suche in lokalen Datenbanken des
Metasuchdienstes (z.B. Quicklinks zu aktuellen Themengebieten, Firmendatenbanken
oder direkte Suche im Domain Name System) sehr rasch Ergebnisse liefern, die bis zum
Eintreffen der eigentlichen Metasuchresultate durchgesehen werden können.
5.3.3
Anzeige der Suchergebnisse
Abhängig von den Optionen, die bei der Sucheingabe (siehe Abschnitt 5.3.1) gewählt
wurden, erfolgt die Ausgabe in kompakter Form, nach Suchdiensten aufgeschlüsselt
oder nach anderen Kriterien sortiert. Die optische Aufbereitung der Ergebnisse hat
selbstverständlich einen großen Einfluß darauf, wie effizient man mit dem Metasuchdienst arbeiten kann. Dennoch soll hier das Augenmerk auf die angebotene Information, unabhängig von der graphischen Anordnung oder Farbwahl, gelegt werden. Die
wesentlichen Merkmale sind:
• Suchanfrage
Es wird nocheinmal angezeigt, wonach gesucht wurde.
• Anzahl der Treffer pro Suchdienst und insgesamt
• Index der gezeigten Treffer
Dem Benutzer wird mitgeteilt, wo genau er sich in der Ergebnismenge befindet.
• Navigationsmöglichkeiten
Zur Anzeige der vorangegangenen oder nachfolgenden Treffer bzw. zur direkten
Ansteuerung einzelner Treffer.
• Views
Ein View bezeichnet ein Kriterium, nach dem die Ergebnisse gruppiert werden.
Beispiele dafür sind Gruppierungen nach Relevanz, nach Site oder nach Suchdienst (siehe Abbildung 5.9). Jeder View kann seinerseits verschiedene Dokumentattribute übersichtlich zusammenfassen und sie nach Bedarf anzeigen oder
ausblenden.
• Dokumentattribute
Alle beschreibenden Merkmale eines Dokumentes, z.B. Titel, Schlüsselwörter,
inhaltsbeschreibende und -bewertende Metadaten (siehe Abschnitt 4.2.5).
• Fundstellen
Für jedes Suchergebnis ist ersichtlich, von welchen Suchdiensten es aufgefunden
wurde (siehe Abbildungen 5.9 oben und 5.10).
95
• Relevanzinformation
Die vom Metasuchdienst ermittelte relative Wichtigkeit eines einzelnen Suchergebnisses innerhalb der Ergebnismenge (siehe Abbildung 5.11).
5.3.4
Integration in den xFIND-Broker
Der Brokerprototyp berücksichtigt alle vorgenannten und die im Abschnitt 5.2.2 angeführten Merkmale unter Einbeziehung einiger Erweiterungen und Einschränkungen.
Neben den boolschen Operatoren AND und OR stehen alle Suchoperatoren zur Verfügung,
die von den xFIND-Indexern unterstützt werden. Der Broker ”sieht” sich - im Gegensatz zu den WWW-Metasuchdiensten - mit gleichartigen Suchdiensten konfrontiert, die
ein identisches Eingabeformat akzeptieren und die Suchergebnisse in einem einheitlichen Ausgabeformat zurückliefern. Daraus ergeben sich Vereinfachungen seitens der
Benutzung (z.B. durch eine einheitliche Bedienung), aber auch seitens der technischen
Durchführung der Metasuche (z.B. wird nur ein Kommunikationsprotokoll benötigt).
Externe Suchdienste können mittels xFIND-Wrapper (siehe Kapitel 2) für den Broker
suchbar gemacht werden. Bei der vollständigen Suche erfolgt eine Einschränkung dahingehend, daß die xFIND-Indexer eine vordefinierte Maximalanzahl an Suchergebnissen
ausgeben. Im Augenblick ist diese auf 200 Ergebnisse pro Indexer festgelegt.
Abbildung 5.9: Suchergebnis Metacrawler
96
Abbildung 5.10: Suchergebnis TheBigHub
Abbildung 5.11: Suchergebnis C4
Abbildung 5.12: Suchergebnis Highway61
97
Kapitel 6
Brokerarchitektur
Der Broker ist ein eigenständiges Modul (siehe Kapitel 2), das über definierte Schnittstellen und Protokolle mit anderen Modulen im xFIND-Suchsystem kommuniziert. Die
Implementierung des Broker, wie auch aller weiteren Module im xFIND-Suchsystem,
wurde mittels der plattformunabhängigen Programmiersprache JAVA umgesetzt. Damit läßt sich der Betrieb des Suchsystems auf den verbreitetsten Plattformen ohne
Portierungsaufwand sicherstellen.
Das Brokermodul fungiert, wie in Abbildung 6.1 dargestellt, einerseits als erster
Ansprechpartner für den Benutzer, andererseits hat es Kenntnis über einen Teilbereich
des xFIND-Suchsystems. Die Zerlegung in einzelne Komponenten (Gatherer, Indexer
und Broker) und ihre Verteilung bringen eine hohe Flexibilität und eine sehr gute
Skalierbarkeit des xFIND-Systems mit sich.
Abbildung 6.1: xFIND-Broker als Vermittler zwischen Benutzer und Indexern
Auf Brokerebene richtet sich die Architektur des Systems nach den konkreten Erfordernissen einer Suchanwendung. So kann ein sogenannter Personal Broker lokal am
98
KAPITEL 6. BROKERARCHITEKTUR
99
Computer eines einzelnen Benutzers betrieben und an die individuellen Anforderungen
angepaßt werden. Die Anpassung kann der Benutzer vorläufig selbst vornehmen, indem
er einzelne Indexer in die Datenbank des Broker aufnimmt. Für die weitere Entwicklung ist eine automatisierte Anpassung aufgrund des Benutzerverhaltens (z.B. durch
eine thematische Auswertung der Suchanfragen) vorgesehen. Damit wird den sich laufend ändernden Interessen eines einzelnen Benutzers Rechnung getragen und dessen
Informationsbedarf bestmöglich gedeckt. Ebenso kann ein Broker auf einem beliebigen Host im Internet laufen und einer größeren Benutzergruppe zugänglich gemacht
werden. Im Vordergrund steht hier wiederum die Möglichkeit, eine dynamische Hintergrundbibliothek zu schaffen, die sich an den aktuellen Interessen der Gruppe orientiert
und entsprechend erweitern läßt.
Demnach kann sich ein Broker durch die Zusammenfassung von Indexern thematisch, geographisch oder aufgrund beliebiger anderer Kriterien spezialisieren. Dieses
Konzept in Verbindung mit der Einbeziehung von Metadaten zur Beschreibung und
Bewertung von Dokumenten garantiert dem Benutzer des xFIND-Suchsystems - im
Vergleich zu traditionellen, auf einem zentralistischen Ansatz basierenden, Suchdiensten - eine höhere Qualität der Suchergebnisse. In diesem Kapitel wird zunächst beschrieben, welche Schritte durchzuführen sind, um einen lauffähigen Broker zu erhalten
und in Betrieb zu nehmen. Anschließend wird das Gesamtkonzept und die Funktionsweise des Broker-Moduls anhand seiner Klassenstruktur erläutert und es wird auf die
verwendeten xFIND-Standards eingegangen.
6.1
6.1.1
Inbetriebnahme des xFIND-Broker
Brokersource
Die Komponenten des Broker sind in verschiedenen Packages im Sourcebaum des
xFIND-Projektes untergebracht. Das Hauptpackage edu.iicm.xfind.broker enthält
alle Kernklassen des Broker, eine Hierarchieebene darunter sind folgende Packages zu
finden:
• comm mit der Kommunikationsklasse XFBrokerSearchQueryComm
(siehe Abschnitt 6.2.2)
• client mit dem Referenzclient zum Brokerprototyp (siehe Abschnitt 6.3)
• util mit den Programmen zum Erstellen und Verwalten der Indexerdatenbank
des Brokerprototyps
Um einen lauffähigen Broker zu erhalten, empfiehlt es sich, alle JAVA-Dateien in den
oben genannten Packages wie in Listing 6.1 beschrieben zu kompilieren:
commandline> javac -sourcepath /PathToXFIND/ -d /DestOfClasses/ *.java
Listing 6.1: Kompilieren der xFIND-Broker-Packages
100
Weiters benötigt der Broker eine Datenbank, in der alle xFIND-Indexer verzeichnet
werden, die vom Broker kontaktiert werden können. Im Package util sind jene Programme zu finden, mit deren Hilfe eine Datenbank mit einigen Beispieleinträgen (siehe
dazu auch Abschnitt 6.1.2) erstellt werden kann. Das JAVA-Applet QueryTool erlaubt
anschließend die Anpassung der Datenbank mittels SQL-Anweisungen (siehe Abbildung 6.2). Damit läßt sich durch die gezielte Aufnahme von xFIND-Indexern in die
Datenbank eine geographische oder thematische Spezialisierung eines Broker erreichen.
Abbildung 6.2: JAVA-Applet zur Verwaltung der Indexerdatenbank
6.1.2
Brokerkonfiguration
Beim Start des Broker sind u.a. Pfad und Name der Brokerkonfigurationsdatei anzugeben. Dabei handelt es sich um eine Textdatei, die den Konventionen zur Konfiguration
von xFIND-Modulen zu folgen hat und drei Sektionen beinhaltet:
• Logging-Sektion
Hier läßt sich einstellen, welche Systemmeldungen vom Broker in welchen Dateien
und in welchem Format mitprotokolliert werden sollen. Es empfiehlt sich, in der
Entwicklungsphase möglichst viel Information ausgeben zu lassen und erst im
Anwendungsbetrieb den Logging-Level zu senken.
• Cache-Sektion
Die Cache-Konfiguration umfaßt lediglich zwei Parameter:
– maximum cache size: Gibt an, wieviel Platz der Broker-Cache auf der
Festplatte maximal belegen darf.
– cache trim size: Sollte die maximale Cachegröße überschritten werden,
so wird der Cache ”aufgeräumt”. Dabei werden jene Dateien zuerst gelöscht,
deren letzter Zugriff am längsten zurückliegt. Dies wird solange fortgesetzt,
bis die angegebene cache trim size unterschritten ist.
101
• Lookup-Sektion
Dieser Abschnitt enthält Einstellungen zur Indexerdatenbank des Broker (z.B.
Datenbanktreiber, Name der Datenbank usw.). Im Brokerprototyp wurde die frei
verfügbare Datenbank Hypersonic SQL1 - kurz hSQL - verwendet. Dabei handelt
es sich um eine reine JAVA-Datenbank, die über JDBC (Java Database Connectivity) angesteuert wird. Die Einbindung erfolgt aufgrund der in der Brokerkonfigurationsdatei angegebenen Parameter. Dieses offene Konzept erlaubt es, hSQL
zu einem späteren Zeitpunkt durch beliebige andere Datenbanken zu ersetzen.
6.1.3
Start des Broker
Sofern das xFIND-Verzeichnis ordnungsgemäß im JAVA-Klassenpfad angeführt ist, läßt
sich ein Broker auf der Kommandozeile wie in Listing 6.2 beschrieben starten:
commandline> java edu.iicm.xfind.broker.XFBrokerPortnumber Configfile
Listing 6.2: Start des xFIND-Broker von der Kommandozeile
Der Broker lauscht danach am angegebenen Port nach anfragenden Clients. Alternativ
dazu kann ein Broker auch von einem xFIND-Manager gestartet werden. Den notwendige Eintrag in der Konfigurationsdatei des xFIND-Managers zeigt Listing 6.3:
[Manager.AdditionalPrograms]
edu.iicm.xfind.broker.XFBroker Portnumber Configfile
[/Manager.AdditionalPrograms]
Listing 6.3: Start des xFIND-Broker mittels xFIND-Manager
6.2
Klassenstruktur des xFIND-Broker
Die Behandlung einer Suchanfrage durch den Broker nimmt einen weitgehend linearen
Verlauf. Ein Client verbindet sich mit dem Broker und stellt die Anfrage. Daraufhin
verteilt der Broker die Suche auf alle oder eine Teilmenge der ihm bekannten Indexer.
Die einlangenden Ergebnisse werden gesammelt und nach einer Aufbereitung an den
Client gesendet. Die in Abbildung 6.3 gezeigte Klassenstruktur spiegelt die Funktionsweise des Broker wider. In den folgenden Abschnitten werden die Aufgaben der
einzelnen Klassen und ihr Zusammenwirken ausführlich beschrieben.
6.2.1
Serverklasse XFBroker
Diese Klasse definiert alle zentralen Konstanten und ist für das ”Hochfahren” des Broker verantwortlich. Zu Beginn wird ein Brokerobjekt erzeugt und initialisiert. Dabei ist
1
http://hsql.oron.ch/
102
Abbildung 6.3: Klassenstruktur des xFIND-Broker
zu beachten, daß innerhalb einer Java Virtual Machine nur ein Brokerobjekt existieren
kann, da es sich beim Broker aus technischer Sicht um eine statische Klassenvariable
handelt. Die Initialisierung erfolgt aufgrund der Angaben in der Konfigurationsdatei
(siehe Abschnitt 6.1.2) und umfaßt die folgenden Schritte:
• Aktivierung der Logging-Aktivitäten
• Prüfung der Broker-Konfigurationsparameter
• Herstellung der Verbindung zur Indexerdatenbank
• Erzeugung und Initialisierung des Broker-Cache
103
Für den Broker-Cache gelten dieselben Voraussetzungen wie für den Broker selbst. Er
ist als statische Klassenvariable deklariert und somit einzigartig und eindeutig dem existierenden Broker zugeordnet. Die Initialisierung des Broker-Cache durchläuft folgende
Punkte:
• Prüfung und gegebenenfalls Anpassung der Cache-Konfigurationsparameter
• Anlegen eines Cache-Verzeichnisses auf der Festplatte bzw. Löschen alter Dateien
aus einem existierenden Cache-Verzeichnis
Die XFBroker-Klasse bietet weiters Methoden an, über die andere Klassen das aktuelle
Broker- oder Broker-Cache-Objekt anfordern können. Nach Abschluß der Initialisierungsphase wird ein XFServerSocket am gewünschten Port erzeugt, der Broker nimmt
seinen Betrieb auf und wartet auf ankommende Client-Verbindungen.
6.2.2
Kommunikationsklasse XFBrokerSearchQueryComm
Sobald ein Client den Broker kontaktiert, tritt diese Kommunikationsklasse in Aktion. Sie implementiert das Interface XFRequestHandlerIfc, das die Kommunikation
zwischen xFIND-Modulen allgemein deklariert. In xFIND gelangt ein auf TCP/IP basierendes Protokoll zur Anwendung, dessen Ablauf in Abbildung 6.4 skizziert wird. Sofern
die Anfrage des Client ein korrektes Format aufweist, wird ein neuer XFBrokerTaskThread gestartet.
Abbildung 6.4: xFIND-Protokoll zur Client-Server-Kommunikation
6.2.3
104
Kernklasse XFBrokerTask
Dieser Thread ist für eine einzelne Suchanfrage zuständig und bildet somit das
Kernstück des Broker. Er wird erzeugt, sobald sich ein Client mit dem Broker in
Verbindung setzt und verschwindet, wenn die vom Client angeforderte Teilmenge der
Suchergebnisse übertragen und die Gesamtmenge der Suchergebnisse in den BrokerCache geschrieben wurde. Die Abarbeitung einer Suchanfrage zeigt das Flußdiagramm
in Abbildung 6.5.
Die Anfrage des Client wird im QCF-Format2 in Form eines Arrays entgegengenommen. Daraufhin erfolgt eine Umwandlung der Anfrage in ein XFBrokerRequestObjekt (siehe Abschnitt 6.2.4), das die Abfrage einzelner Suchoptionen und damit die
Verzweigung in die verschiedenenen Programmteile vereinfacht. Die Hauptzweige des
Programms und ihr Verlauf werden nachfolgend beschrieben.
6.2.3.1
Informelle Anfrage
Der Client fordert lediglich Informationen über die Indexer an, die der Broker kennt
und absuchen kann. Daraufhin erfolgt eine Abfrage der Indexerdatenbank, die sämtliche
darin gespeicherten Daten zurückgibt.
6.2.3.2
Gecachte Suchanfrage
Handelt es sich um eine Suchanfrage, so wird zunächst versucht, diese direkt aus dem
Broker-Cache zu beantworten. Ist ein passender Eintrag vorhanden, so werden die
angeforderten Suchergebnisse aus der korrespondierenden Cache-Datei gelesen und an
den Client gesendet. Die Funktionsweise des Broker-Cache wird in Abschnitt 6.2.9 noch
genau beschrieben werden.
6.2.3.3
Neue Suchanfrage
Konnte im Broker-Cache kein Eintrag für die Suchanfrage gefunden werden, so wird
eine Metasuche mit folgendem Ablauf (siehe Abbildung 6.5) gestartet:
IndexerLookup: Die Indexerdatenbank wird befragt, welche Indexer die Suchanfrage beantworten sollten bzw. könnten. Abhängig von der Art der Indexerauswahl
(alle, nach Dewey-Themen oder nur ausgewählte Indexer) gibt die Indexerdatenbank eine Menge von Hosts (inkl. Portnummern und Zusatzinformationen) aus,
die der Broker kontaktieren muß.
QueryDistribution: Für jeden einzelnen der gefundenen Indexer wird ein
XFIndexerQuery-Thread (siehe Abschnitt 6.2.5) gestartet, der die Verbindung
herstellt, die Suchanfrage absetzt und die Suchergebnisse entgegennimmt.
2
Das Query Communication Format ist ein xFIND-spezifisches Format zum Datenaustausch zwischen xFIND-Modulen. Es basiert auf textuellen Key-Value-Paaren, wobei der Key angibt, wie der
Value vom empfangenden xFIND-Modul zu interpretieren ist (z.B. Key = Document.Title, Value =
”The Incredible xFIND-Searchsystem”)
105
WaitForThreads: Sobald alle XFIndexerQuery-Threads gestartet sind, übernimmt
eine Überwachungsmethode die Koordination. Jeder Thread teilt dieser Methode
seinen Status mit, sobald er erfolgreich abgeschlossen, unterbrochen oder aus anderen Gründen abgebrochen wurde. Wurden schließlich alle Threads beendet, so
gibt der ”Watchdog” die gesammelten Suchergebnisse zur weiteren Bearbeitung
frei.
NoResults: Wurden keine Suchergebnisse gefunden, so wird der Client sofort davon
in Kenntnis gesetzt.
Searchresults Postprocessing: Wurden Resultate gefunden, so erfolgt eine Aufbereitung der Ergebnisse in Abhängigkeit der gewählten Suchoptionen (bestimmte
Views, z.B. Sortierung nach absteigender Relevanz).
Ausgabe der Suchergebnisse: In der Suchanfrage wird vom Client ein bestimmter
Ausschnitt aus der gesamten Ergebnismenge angefordert. Nach einer Prüfung und
Anpassung der Ausgabeparameter Offset und Anzahl, werden die gewünschten
Suchergebnisse an den Client gesendet.
Caching der Suchergebnisse: Bevor die Suchergebnisse tatsächlich im Dateisystem
abgelegt werden, erfolgt eine Prüfung, ob die maximale Cachegröße erreicht ist.
Sollte dies der Fall sein, so wird der Cache zuerst bereinigt.
Caching verschiedener Views: Zusätzlich zum gewünschten View (siehe Abschnitt
5.3.4) werden auch alle verbleibenden Views gecacht, sodaß nachfolgende Anfragen des Client zeitsparend direkt aus dem Broker-Cache beantwortet werden
können.
Abbildung 6.5: Abarbeitung einer Suchanfrage durch den Broker
106
6.2.4
107
Steuerklasse XFBrokerRequest
Zu Beginn jedes XFBrokerTask-Threads (siehe Abschnitt 6.2.3) wird ein Objekt dieser
Klasse erzeugt. Die Grundlage bildet ein Array mit Key-Value-Paaren im QCF-Format,
das die Suchanfrage des Client beinhaltet. Das Array enthält sowohl Direktiven für die
Indexer als auch für den Broker, die Gliederung dieses Arrays zeigt Abbildung 6.6.
Abbildung 6.6: Array zur Broker-Indexer-Kommunikation
Die Verwendung der QCF-Brokeranweisungen, die in der QueryAttributes-Sektion untergebracht sind, ist optional. Daher werden alle Brokeranweisungen zunächst mit Defaultwerten initialisiert.
Broker.Results.Start bezeichnet den Offset innerhalb der Suchergebnisse, d.h. ab
welcher Position die Ergebnisse ausgegeben werden sollen (Default: 1).
Broker.Results.Howmany gibt an, wieviele Ergebnisse ab dem oben genannten Offset
ausgegeben werden sollen (Default: 10).
Broker.Results.Maxsearchtime legt fest, wie lange eine Suche längstens dauern darf
(Default: 20 sec.).
Broker.Distribution gibt vor, in welcher Art und Weise der Broker die Verteilung
der Suchanfrage auf die Indexer durchführt. Folgende Möglichkeiten stehen zur
Auswahl:
• all: Verteilung an alle in der Indexerdatenbank verzeichneten Indexer (ist
Default)
• dewey: Verteilung aufgrund der im Feld Subject.Topic.Dewey angegebenen
Dewey-Themen (siehe Abschnitt 4.3.4.2)
• choice: Verteilung an die manuell ausgewählten Indexer, die im Feld
Broker.Distribution.Selected eingetragen sind.
Broker.Distribution enthält die Indexer-ID’s der manuell gewählten Indexer, an die
eine Verteilung erfolgen soll (Broker.Distribution muß auf choice gesetzt sein).
Die Indexer-ID’s können durch Leerzeichen oder Beistriche voneinander getrennt
sein (Default: 0, was äquivalent zu Broker.Distribution=all ist).
108
Broker.MergeResults gibt einen sogenannten View der Suchergebnisse an, d.h. nach
welchem Kriterium die Suchergebnisse geordnet werden sollen. Mögliche Views
sind:
• linear: Nach Indexern getrennt, die Ergebnisse erscheinen in der Reihenfolge ihres Einlangens (ist Default). Duplikate werden in diesem View nicht
entfernt, in allen anderen schon.
• url: Es erfolgt eine alphabetische Sortierung nach der URL der Suchergebnisse.
• ranking: Es wird für jedes Suchergebnis ein Relevanzwert berechnet, nach
dem anschließend absteigend sortiert wird.
• date: Die Anzeige erfolgt nach Aktualität der Suchergebnisse, d.h. sie werden
nach absteigendem Datum sortiert.
Nachdem die Defaultwerte gesetzt sind, können sie durch die vom Client geforderten Werte überschrieben werden. Gleichzeitig werden die Brokeranweisungen aus der
Suchanfrage herausgefiltert, sodaß die Indexer nur ihnen bekannte Anweisungen erhalten. Außerdem wird sichergestellt, daß zumindest die URL, der Relevanzwert und
das Datum der letzten Änderung der Dokumente angefordert werden, da diese für die
Aufbereitung der Suchergebnisse erforderlich sind.
Eine weitere wichtige Aufgabe, die dem XFBrokerRequest-Objekt zukommt, ist
die Generierung eindeutiger Cache-ID’s, unter denen die Suchergebnisse im BrokerCache abgelegt werden. Dazu werden alle jene QCF-Keys und -Values zur Bildung einer
CRC32-Checksumme3 herangezogen, die eine Suchanfrage eindeutig beschreiben. Jene
QCF-Keys und -Values, die lediglich zum Navigieren innerhalb des Suchergebnisses verwendet werden, bleiben bei der Bildung der Checksumme unberücksichtigt. Dadurch
können - zumeist aufeinanderfolgende, vom gleichen Client gestellte - Suchanfragen, die
nur diese Werte verändern, direkt aus dem Broker-Cache beantwortet werden. Um verschiedene Anordnungen des Suchergebnisses ebenfalls schnell bereitstellen zu können,
generiert das XFBrokerRequest-Objekt für jeden View einen eigenen Cache-ID.
6.2.5
Anfrageklasse XFIndexerQuery
Für jeden zu kontaktierenden Indexer wird ein XFIndexerQuery-Thread gestartet. Die
Verbindung erfolgt über die xFIND-eigenen XFSockets, wobei der vom Client angegebenen Timeoutwert dem Socket mitgeteilt wird. Kommt innerhalb der angegebenen
Zeitspanne keine Verbindung zustande, so wird dies in der Statusinformation vermerkt,
der Thread wird beendet. In derselben Art und Weise wird vorgegangen, falls der
Thread beim Lesen von Ergebnissen den Timeoutwert überschreitet oder die Verbindung aus nicht vorhersehbaren Gründen unterbrochen wird.
3
Eine Checksumme ist eine Signatur, die aus einem Bytestream berechnet wird. Je nach verwendetem Algorithmus zur Berechnung der Checksumme (hier CRC32) lassen sich Änderungen im
Bytestream mit einer bestimmten, i.a. sehr hohen Wahrscheinlichkeit, erkennen. Aufgrund dieser Voraussetzung lassen sich Checksummen vorteilhaft auch für die Bildung von ID’s für Suchanfragen
heranziehen.
109
Die Kommunikation folgt dem bereits im Abschnitt 6.2.2 beschriebenen xFINDProtokoll. Den Ablauf des Datenteils des Protokolls zeigt Abbildung 6.7. Die gesammelten Daten werden gemeinsam mit Status- und Indexerinformationen in einem
XFIndexerResult-Objekt gespeichert. Die Menge aller XFIndexerResult-Objekte bildet die Basis für die Nachbearbeitung der Suchergebnisse.
Abbildung 6.7: Kommunikation zwischen Broker und Indexer
6.2.6
Ergebnisklasse XFIndexerResult
Objekte dieser Klasse kapseln das Ergebnis einer Suchanfrage an einen einzelnen Indexer. Die Komponenten sind:
• Status der Suche: erfolgreich oder fehlgeschlagen
• Indexerinformation: ein XFIndexerInfo-Objekt, das alle Merkmale des befragten Indexer enthält
• Statistik: enthält Zusatzinformation zur Suche, z.B. wieviele Ergebnisse am Indexer gefunden wurden, welche Kosten die Suche verursachte usw.
• Suchergebnisse: die eigentlichen Resultate
110
• Footer: enthält weitere Informationen zur Suche, z.B. wieviel Ergebnisse tatsächlich
zurückgeliefert wurden
Über die Methoden des XFIndexerResult-Objektes lassen sich die einzelnen Komponenten abfragen. Um die Komponenten daraufhin korrekt handhaben zu können,
wird in Abbildung 6.8 stellvertretend die Datenstruktur zur Zwischenspeicherung von
Suchergebnissen vorgestellt. Statistiken und Footer werden in derselben Art zwischengespeichert.
Abbildung 6.8: Datenstruktur zur Speicherung von Suchergebnissen
Jedes einzelne Suchergebnis wird in einer Hashtabelle untergebracht, wobei der Eintrag Broker.Results.Origin von besonderer Wichtigkeit ist, um eine Zuordnung des
Ergebnisses zu den Indexerinformationen herzustellen. Die Gesamtheit der Ergebnisse
eines Indexers werden in einem Vektor verwaltet.
6.2.7
Informationsklasse XFIndexerInfo
Ein Objekt dieser Klasse ist gleichzusetzen mit einer Zeile in der Indexerdatenbank des
Broker. Es kapselt die Beschreibung eines Indexer mit folgenden Attributen:
• Indexer-ID (ein eindeutiger numerischer Bezeichner)
• IP-Adresse und Portnummer
• Hostname
• Administrator (z.B. Email-Adresse der Kontaktperson)
• Organisation, die den Indexer betreibt
• Kurzbeschreibung
• Datum, zu dem der Indexer seinen Betrieb aufgenommen hat
111
• Dewey-Themen
Das Attribut Dewey-Themen zeigt an, welche Themengebiete auf dem Indexer zu finden
sind. Der Attributwert - ein Binärstring der Länge 100 - stellt eine Abbildung auf die ersten beiden Hierarchiestufen der Dewey Decimal Classification (siehe Abschnitt 4.3.4.2)
dar. Im folgenden Beispiel bedeutet eine 1, daß das zugehörige Themengebiet (hier 01
”Bibliography” und 02 ”Library and Information Sciences”) am Indexer vorhanden ist.
Dewey-Themen = "0110000 ......."
Dieses Schema erlaubt es dem Broker eine automatisierte thematische Vorauswahl jener
Indexer zu treffen, die für die Beantwortung einer Suchanfrage in Frage kommen.
6.2.8
Produktionsklasse XFMergeFactory
Diese Klasse besteht aus nur einer Methode, die aufgrund eines anzugebenden Bezeichners entscheidet, welcher Objekttyp erzeugt wird. Die verschiedenen Objekttypen
korrespondieren mit den verschiedenen Arten der Suchergebniszusammenfassung. Wie
in Abbildung 6.3 dargestellt, sind die einzelnen Objekttypen eine Verfeinerung der
Klasse XFMergedResult. Der Vorteil dieser Architektur liegt darin, daß die Suchergebniszusammenfassung um beliebige Objekttypen erweitert werden kann, ohne die
Programmstruktur ändern zu müssen.
6.2.8.1
Basisklasse XFMergedResult
Hier sind jene Methoden definiert, die von den abgeleiteten Objekttypen geerbt und
i.a. zur Aufbereitung der Suchergebnisse benötigt werden. Es stehen Methoden für
folgende Aufgaben zur Verfügung:
• Normalisierung der Relevanzwerte
Jeder Indexer liefert die Suchergebnisse absteigend sortiert nach ihrer kalkulierten ”Wichtigkeit” an den Broker zurück. Dabei ist zu beachten, daß es zwischen
den Ergebnissen verschiedener Indexer keinerlei gemeinsamen Bezugspunkt gibt.
Um die Ergebnisse vergleichbar zu machen und somit eine Sortierung des Gesamtergebnisses zu ermöglichen, erfolgt eine Normalisierung der Relevanzwerte, und
zwar immer auf den Maximalwert des jeweiligen Indexers.
Für die Zusammenfassung der Suchergebnisse aller Indexer ergibt sich ein relatives Ranking. Ein Vorteil davon ist der Umstand, daß die relevantesten Ergebnisse
jedes Indexer immer an oberster Stelle auftreten. Andererseits kann es vorkommen, daß einzelne Indexer nur wenig relevante Ergebnisse liefern, die durch die
Normalisierung jedoch aufgewertet werden und so die Bewertung des Gesamtergebnisses verzerren.
• Eliminierung von Duplikaten
Die Gesamtheit der Suchergebnisse wird alphabetisch nach der URL sortiert, danach werden aufeinanderfolgende gleiche URL’s zusammengefaßt. Die Herkunft
eines Suchergebnisses wird um alle Indexer-ID’s ergänzt, unter denen es aufgefunden wurde.
112
• Zusammenfassung von Statistiken und Footern
Hier erfolgt eine Kalkulation der Gesamtanzahl der Treffer, der gesamten Kosten
der Suche usw.
• Hilfsmethoden
Diese Methoden erledigen die Umwandlung von Ergebnisvektoren in Arrays und
umgekehrt.
6.2.8.2
Abgeleitete Klassen XFMergedBy...
Die eigentlichen Klassen zur Suchergebniszusammenfassung werden von der oben beschriebenen Basisklasse XFMergedResult abgeleitet. So lassen sich für zukünftige Weiterentwicklungen des Broker auf einfache Weise neue Views und Algorithmen integrieren. Im Brokerprototyp sind derzeit die folgenden abgeleiteten Klassen implementiert:
XFMergedBySource: Die Suchergebnisse werden in der Reihenfolge ihres Eintreffens (jeweils pro Indexer) zusammengefaßt. Es erfolgt hier - im Gegensatz zu den
anderen abgeleiteten Klassen - keine Eliminierung der Duplikate.
XFMergedByRanking: Absteigende Sortierung nach den normalisierten Relevanzwerten.
XFMergedByUrl: Alphabetische Sortierung nach URL.
XFMergedByDate: Absteigende Sortierung nach dem Datum und der Uhrzeit der
letzten Änderung.
6.2.9
Speicherklasse XFBrokerCache
Im Abschnitt 6.2.1 wurde erwähnt, daß dem Broker ein eindeutiges XFBrokerCacheObjekt zugeordnet wird. Dieses Objekt ist für die Verwaltung eines Festplattenverzeichnisses verantwortlich, in dem die Suchergebnisse zwischengespeichert werden. Konfiguriert wird der Broker-Cache anhand der in der Broker-Konfigurationsdatei angeführten
Parameter (siehe Abschnitt 6.1.2).
Im laufenden Betrieb werden die gecachten Suchergebnisse in einer Hashtabelle verwaltet. Als Key fungieren die aus den Suchanfragen generierten CRC32-Checksummen
(siehe Abschnitt 6.2.4), als Value wird jeweils ein XFCacheListEntry-Objekt zugeordnet. Abbildung 6.9 zeigt beispielhaft die Belegung der Hashtabelle des Broker-Cache.
Die Cache-ID eines XFCacheListEntry-Objekts entspricht der CRC32-Checksumme,
unter diesem Namen sind die zugehörigen Dateien im Cacheverzeichnis aufzufinden.
Weiters werden Datum und Uhrzeit des letzten Dateizugriffs (im Greenwich Mean Time
Format, d.h. Millisekunden seit dem 1. Jänner 1970, 0 Uhr), sowie die Gesamtgröße
der Dateien mitgeführt. Für die geplante Hintergrundverwaltung des Broker-Cache läßt
sich das Objekt um eine TTL (Time To Live) erweitern, die die Gültigkeitsdauer jedes
einzelnen gecachten Suchergebnisses bezeichnet.
113
Abbildung 6.9: Hashtabelle zur Verwaltung des Broker-Cache
6.2.9.1
Caching eines Views
Ein View ist die Anordnung eines Suchergebnisses nach einem bestimmten Kriterium
(siehe Abschnitt 5.3.4). Der Broker bietet in der aktuellen Version vier verschiedene
Views (nach Indexer, nach URL, nach Ranking und nach Aktualität) an, die getrennt
voneinander gecacht werden. Das Caching eines Views durchläuft folgende Schritte:
• Anlegen und Schreiben einer Datendatei mit wahlfreiem Zugriff
(Dateinamenserweiterung *.req)
• Anlegen und Schreiben einer Verwaltungsdatei (Dateinamenserweiterung *.map)
• Registrieren des gecachten Views in der Hashtabelle
Die Verwaltungsdatei - auch Map-Datei genannt - beinhaltet alle notwendigen Informationen, um die in der Datendatei gespeicherten Suchergebnisse schnell und gezielt
anzusteuern. Sie verwendet das xFIND-Konfigurationsformat, das sehr komfortabel
mit einem xFIND-ConfigReader verarbeitet werden kann. Ein Beispiel einer Map-Datei
zeigt Listing 6.4, die in den einzelnen Sektionen aufgelisteten Zahlen bezeichnen Offsets
in die zugehörige Req-Datei, an denen Key-Value-Paare der Suchergebnisse beginnen.
[CACHE FILE STATISTICS SECTION]
0 0 36 74 91 133 148 175 194 240
240 368 423 459 478
478
[/CACHE FILE STATISTICS SECTION]
[CACHE FILE RESULTS SECTION]
553 553 618 643 709 733 780
780 780 828 853 926 950 997
997 997 1034 1059 1133 1157 1204
1204
114
[/CACHE FILE RESULTS SECTION]
[CACHE FILE FOOTERS SECTION]
5004 5004 5028 5050
5050 5050 5072 5096 5120
5120
[/CACHE FILE FOOTERS SECTION]
[CACHE FILE HELPER SECTION]
result.hits.returned 3
[/CACHE FILE HELPER SECTION]
Listing 6.4: Map-Dateiformat des Broker-Cache
Beim Registrieren des Views wird ein neues XFCacheListEntry-Objekt angelegt und
in der Hashtabelle vermerkt. Gleichzeitig wird die vom Broker-Cache belegte Speichergröße aktualisiert.
6.2.9.2
Lesen eines Views
Aus der vom Client gestellten Suchanfrage wird eine CRC32-Checksumme gebildet.
Findet sich unter dieser Checksumme ein Eintrag in der Hashtabelle des Broker-Cache,
so wird vorerst die Zugriffszeit aktualisiert. Danach werden mit Hilfe der Map-Datei
und den vom Client angegebenen Einstellungen die passenden Sektionen aus der ReqDatei gelesen und sofort an den Client gesendet.
6.2.9.3
Bereinigen des Broker-Cache
Beim Start des Broker wird ein neues Cacheverzeichnis angelegt bzw. alte Cachedateien
werden gelöscht. Ehe die Views eines Suchergebnisses in den Cache geschrieben werden,
wird der durch den Cache belegte Festplattenplatz geprüft. Ist die maximal erlaubte
Cachegröße überschritten, so erfolgt eine Bereinigung des Cache. Dabei werden solange
jene Dateien gelöscht, deren letzter Zugriff am längsten zurückliegt, bis ein vorgegebenes Limit unterschritten ist. Parallel dazu soll in Zukunft eine Hintergrundverwaltung
des Broker-Cache dafür sorgen, daß gecachte Ergebnisse, deren Gültigkeitsdauer (Time
To Live) abgelaufen ist, in regelmäßigen Abständen aus dem Cache entfernt werden.
6.3
115
xFIND-Client
Zur Veranschaulichung der Arbeitsweise des Broker wurde ein Referenzclient in JAVA
entwickelt. Der Client wird wie in Listing 6.5 beschrieben gestartet und lauscht am
angegebenen lokalen Port nach einlangenden Verbindungen.
commandline> java edu.iicm.xfind.broker.client.XFBrokerClient LPort BHost BPort
Listing 6.5: Start des xFIND-Brokerclient von der Kommandozeile
Zur Formulierung der Suchanfrage steht das in Abbildung 6.10 gezeigte HTML-Suchformular
zur Verfügung. Es gliedert sich in drei Sektionen, die alle QCF-Keys zur Einschränkung
der Suche und zur Anforderung von Dokumentattributen beinhalten.
Abbildung 6.10: Suchformular des Referenzclient
116
In der Query-Section können Suchbegriffe eingegeben werden, die in den gewählten
Attributen der SOIF-Objekte auftreten müssen (z.B. im Titel, in den Schlüsselwörtern
usw.). Weiters kann in der Webbereichs-Zusatzinformation, die alle in xQMS definierten
Attribute umfaßt, gesucht werden. Die Hinzunahme der beschreibenden und bewertenden Metadaten ermöglicht es dem Benutzer, durch die präzisere Formulierung der
Suchanfrage nur jene Informationen anzufordern, die die geforderten Qualitätskriterien
erfüllen. Die Angabe der gewünschten Themengebiete (Attribut Site.Subject.Topic)
stellt die Suchanfrage in einen bestimmten Kontext, der falsche Suchergebnisse aufgrund von Mehrfachbedeutungen von Wörtern von vornherein ausschließt.
Die QueryAttribute-Section dient zur weiteren Einschränkung der Suche, so läßt sich
z.B. bestimmen, wieviele Suchergebnisse pro Indexer (Attribut Object.ResultLimit)
oder wieviele Zeichen rund um einen gefundenen Suchbegriff ausgegeben werden sollen
(Attribut Object.Body.CharSurroundLimit). Darüberhinaus enthält diese Sektion die
Parameter zur Steuerung des Broker (siehe Abschnitt 6.2.4).
Zuletzt kann der Benutzer in der ReturnAttributes-Section festlegen, welche Dokumentattribute von den Indexern angefordert werden sollen. Wiederum stehen alle
Merkmale der SOIF-Objekte und der Webbereichs-Zusatzinformation zur Verfügung,
zusätzlich kann ausgewählt werden, in welchem Layout und welcher Sortierung die Suchergebnisse vom Indexer an den Broker gesendet werden.
Der Webbrowser, der das HTML-Suchformular darstellt, verbindet sich via HTTP-POST
auf den lokalen Port. Daraufhin nimmt der Brokerclient die im HTTP-Request-Format
gestellte Suchanfrage entgegen und decodiert sie (Auftrennung in QCF-Keys und -Values,
Umwandlung von Sonderzeichen usw.). Im nächsten Bearbeitungsschritt werden die
QCF-Paare in einem Array untergebracht, das den Konventionen für die Kommunikation zwischen xFIND-Modulen entspricht (siehe dazu Abschnitt 6.2.4). Nachdem eine
Verbindung zum angegebenen Brokerhost und -port hergestellt wurde, erfolgt die Kommunikation gemäß dem im Abschnitt 6.2.2 bereits vorgestellten xFIND-Protokoll. Alle
Suchergebnisse, die vom Broker einlangen, werden umgehend in HTML-Tags eingebettet
und an den anfragenden Webbrowser zur Darstellung weitergeleitet.
Die tabellenförmige Ausgabe der Suchergebnisse durch den Referenzclient zeigt Abbildung 6.11. Zu Beginn der Ausgabe steht die behandelte Suchanfrage. Im Beispiel
wurde nach dem Suchbegriff ”graz” gesucht, wobei die ersten drei Ergebnisse vom
gewählten Indexer (Indexer-ID 3) in linearer Reihenfolge sortiert angefordert werden.
Die gewünschten Attribute umfassen die URL, den Titel, die Beschreibung und den Titel der Webbereichs-Zusatzinformation. Die Statistics-Section beginnt mit einem Block,
der quantitative Informationen zur Suche (z.B. Gesamtanzahl gefundener Ergebnisse,
Gesamtkosten der Suche usw.) ebenso enthält wie alle Angaben zu den involvierten Indexern. Danach folgen Blöcke mit den Statistikdaten der einzelnen Indexer. Die FooterSection folgt demselben Schema, d.h. im ersten Block stehen akkumulierte Daten, danach folgen die Daten einzelner Indexer. Die Results-Section enthält die eigentlichen
Ergebnisobjekte, wobei das Feld Broker.Results.Origin mit der Indexer-ID im ersten Statistik-Block korrespondiert. Das Datum und die Uhrzeit der letzten Änderung
(Attribut Result.Object.Last-Modification-Time) wird immer angefordert, da es
vom Broker für die Sortierung nach der Aktualität der Suchergebnisse benötigt wird.
117
Der Attributwert wird im GMT-Format (Greenwich Mean Time) zurückgeliefert, bei
dem das Datum und die Uhrzeit als verstrichene Millisekunden seit dem 1. Jänner
1970, 0 Uhr, angegeben wird.
Der Referenzclient vermittelt in Verbindung mit dem Suchformular und der in HTML
formatierten Ausgabe der Suchergebnisse einen guten Eindruck über die vielfältigen
Suchmöglichkeiten, die das xFIND-Suchsystem anbietet. Neben dem experimentellen
Konzept soll diese Beispielanwendung zukünftigen Entwicklern von Clientanwendungen
die Anbindung an den Broker verdeutlichen. Welche Clients denkbar sind und wie man
in Zukunft den Broker und das gesamte xFIND-Suchsystem sinnvoll erweitern könnte,
wird im nachfolgenden Kapitel beschrieben.
Abbildung 6.11: Ergebnisausgabe durch den Referenzclient
118
Kapitel 7
Ausblick
Die rasante Entwicklung des Internet eröffnet ungeahnte Möglichkeiten im Bereich der
Wissensverarbeitung und -wiederauffindung. Traditionelle Suchdienste haben, vorallem aufgrund der stark angestiegenen Datenmenge und Benutzerzahlen, die Grenze
ihrer Leistungsfähigkeit bereits erreicht oder überschritten. Aufgrunddessen wird in
zunehmendem Maße Forschungsaufwand zur Verbesserung der Informationsauffindung
betrieben. Das in dieser Arbeit behandelte Suchsystem xFIND beispielsweise basiert
auf einer verteilten Architektur. Das Projekt hat sich das ebenso ehrgeizige wie umfangreiche Ziel gesetzt, eine Reihe von wesentlichen Kriterien, wie Vollständigkeit, Qualität und Aktualität der Suchergebnisse bei minimaler Netz- und Serverbelastung, zu
erfüllen.
Die Umsetzung eines zukunftsweisenden Informationssystems, wie es xFIND darstellt, erfordert einen fundierten Wissensstand über aktuelle Technologien und erfolgversprechende Forschungsansätze. Ein Hauptaugenmerk bei der Konzeption wurde auf
eine offene Architektur gelegt, die eine einfache Einbindung neuartiger Module über definierte Schnittstellen und Standards ermöglicht. Unter diesen Gesichtspunkten wurde
auch der in dieser Arbeit vorgestellte Brokerprototyp entwickelt. Im Zuge des Designs
und der Umsetzung konnte ein umfangreiches Knowhow im Bereich der Metasuche
aufgebaut werden. Der Prototyp implementiert in der vorliegenden Version alle Basisfunktionalitäten, die für eine ”intelligente” verteilte Suche mit anschließender Aufbereitung der Suchergebnisse notwendig sind, um so dem Benutzer bessere Qualität und
Vollständigkeit anbieten zu können. Für den weiteren Ausbau des Broker und seines
benachbarten Umfeldes im xFIND-Suchsystem gibt es eine ganze Reihe von Wünschen
und Anregungen, die im folgenden angesprochen werden.
• Registrierung der Indexer
Gegenwärtig wird die Indexerdatenbank vom Brokeradministrator mit Hilfe einiger Tools von Hand gepflegt. Denkbar wäre eine WWW-Schnittstelle, die Indexerbetreiber zur direkten Anmeldung beim Broker in Anspruch nehmen könnten.
• Ranking der Suchergebnisse
Neben dem im Prototyp angebotenen relativen Ranking (siehe Abschnitt 6.2.8.1)
könnten weitere Algorithmen zur Ermittlung der indexerübergreifenden Relevanzwerte implementiert werden. Vielversprechende Ansätze beziehen Worthäufigkei119
KAPITEL 7. AUSBLICK
120
ten und -positionen innerhalb des Suchergebnisses in die Berechnung der Relevanzwerte mit ein.
• Erkennung von Dokumenten gleichen Inhalts
Im Verlauf der Aufbereitung und Zusammenfassung der Suchergebnisse durch
den Broker werden Duplikate anhand ihrer URL erkannt und ausgefiltert. Ein
weiterer Entwicklungsschritt wäre die Einbeziehung von MD-5 (Message Digest)
Signaturen, mit deren Hilfe sich auch identische Dokumentinhalte erkennen lassen.
• Zusätzliche Views
Bei der Aufbereitung der Suchergebnisse sind der Phantasie keine Grenzen gesetzt, sinnvolle Erweiterungen wären hierarchische Gruppierungen nach Themengebieten oder nach ausgewählten xQMS-Attributen (z.B. nach Vorwissen oder
Alter der Zielgruppe).
• Erweitertes Logging
Um auf das Benutzerverhalten rasch reagieren zu können, könnten u.U. bestimmte Merkmale der Suchanfragen (z.B. verwendete Operatoren, Anzahl der zurückgelieferten Suchergebnisse usw.) mitprotokolliert werden. Von einer Aufzeichnung
oder Veröffentlichung von Suchbegriffen ist aus rechtlichen Gründen und zum
Schutz der Privatsphäre abzusehen.
• Personalisierte Konfiguration
Als interessante Erweiterung des Broker wäre eine Benutzerdatenbank zu sehen. Registrierte Benutzer könnten darin personalisierte Suchprofile ablegen, die
z.B. festlegen, welche Indexer befragt werden sollen, ob eigens zusammengestellte Verknüpfungen verwendet werden sollen oder ob ein persönliches Layout der
Suchergebnisse gewünscht wird.
• Einbindung externer Informationsquellen
Im Laufe der Aufbereitung der Suchergebnisse könnten zusätzliche Bewertungen,
die von unabhängigen Rating-Büros angeboten werden, angefordert und in das
Gesamtergebnis miteinbezogen werden.
• Query Routing
Ein Mechanismus zur Weiterleitung von Suchanfragen an andere Broker könnte
vorteilhaft in Aktion treten, wenn die vom Broker verzeichneten Indexer nicht
erreichbar sind oder eine konkrete Suchanfrage nicht beantworten können.
• xFIND-Clients
Benutzeroberflächen haben bekanntermaßen großen Anteil am Erfolg von Informationsdiensten. Da das xFIND-Suchsystem über einen im Vergleich zu anderen
Suchdiensten außerordentlich umfangreichen Sprachschatz verfügt, könnten sich
unterschiedlichste Clients auf Teilmengen der Sprache spezialisieren. So sind Clients für Handheld-Computer, die lediglich kompakte Textinformationen abfragen,
bis hin zu Multimedia-Clients denkbar, die in Zukunft auch indizierte Audio- oder
Videodaten anfordern könnten.
Kapitel 8
Zusammenfassung
Diese Arbeit besteht aus einem Untersuchungsbereich, in dem Probleme der Informationssuche aufgezeigt und Lösungsansätze aus theoretischer Sicht erarbeitet werden,
sowie aus einem Gestaltungsbereich, in dem die gewonnenen Erkenntnisse umgesetzt
und die Praxistauglichkeit der Lösungen verifiziert werden.
Die Untersuchung wird in Kapitel 1 mit einer Beobachtung eingeleitet, wonach die
sehr starke Zunahme der Datenmenge im WWW viele Schwierigkeiten für die Informationsaufbereitung und -auffindung mit sich bringt. Aus der Sicht der Benutzer ist die
verminderte Qualität der Suchergebnisse hervorzuheben, seitens der Informationsanbieter gibt es vermehrt Probleme mit der erhöhten Netz- und Serverbelastung aufgrund
unkoordinierter Indizierung der Webdaten durch die Suchdienstbetreiber. Verschiedene
Arten von Suchdiensten werden vorgestellt, deren Schwächen schließlich durch das im
Kapitel 2 beschriebene verteilte Suchsystem xFIND beseitigt werden.
Dem Indexer als dem zentralen Element der xFIND-Architektur kommt eine besondere Bedeutung zu. In Kapitel 3 werden daher die vielfältigen Konzepte und Mechanismen der Dokumentindizierung ausführlich behandelt. Die theoretischen Betrachtungen
werden durch eine praktische Gegenüberstellung gängiger Information Retrieval Systeme und Search Development Kits ergänzt. In einem umfangreichen Verfahren werden
die unzähligen Funktionalitäten der Systeme erhoben und Performancemessungen für
die Indizierung und die Suche durchgeführt. Aus der Analyse läßt sich schließlich ableiten, welche der untersuchten IR Systeme für einen praktischen Einsatz im Rahmen
der xFIND-Indizierung geeignet sind.
In Kapitel 4 werden die Auswirkungen auf die Qualität der Suchergebnisse untersucht, wenn zur Dokumentbeschreibung zusätzlich Metadaten verwendet werden. Im
speziellen wird auf die thematische Klassifikation von Webressourcen eingegangen, d.h.
ihre inhaltliche Zuordnung zu definierten Themengebieten. Die verbreitetsten Ansätze
zur Klassifikation, sowie die mit ihrer Anwendung verbundene Vorzüge und Nachteile
werden analysiert. Den Abschluß des Untersuchungsbereiches bildet die Integration der
Dewey Decimal Classification und alternativer Themenklassifikationen in das xFIND
Quality Metadata Scheme (xQMS), daß neben inhaltsbeschreibenden auch eine Reihe
von inhaltsbewertenden Attributen aufweist.
121
KAPITEL 8. ZUSAMMENFASSUNG
122
Im Gestaltungsbereich wurde mit Hilfe der herausgearbeiteten Erkenntnisse ein
Brokerprototyp entwickelt und implementiert. Die Umsetzung erfolgte in der plattformunabhängigen Programmiersprache JAVA. Kapitel 5 motiviert die Konzeption des
xFIND-Broker anhand der sogenannten Metasuche im WWW. Es werden Parallelen
und Unterschiede zur verteilten Suche im xFIND-Suchsystem offensichtlich, die sich in
der im Kapitel 6 beschriebenen Brokerarchitektur niederschlagen. Die Klassenstruktur
des Brokerprototyps orientiert sich in erster Linie an den benötigten Arbeitsschritten
zur Behandlung einer Suchanfrage. Die wichtigsten Aufgaben des Broker werden daher in getrennten Modulen untergebracht, z.B. zur Kommunikation (Versendung und
Entgegennahme von Suchanfragen bzw. -ergebnissen), zur Verteilung der Suche an eine
qualifizierte Menge von xFIND-Indexern oder zur Nachbearbeitung der Suchergebnisse. Diese offene Architektur erlaubt eine einfache Erweiterung des Brokerprototyps, um
zukünftigen Anforderungen an das xFIND-Suchsystem gerecht werden zu können.
Teil III
Anhang
123
Anhang A
Suchhilfen im WWW
A.1
Volltextsuchdienste
Name
URL: http://www...
Größe Index (Millionen Seiten)
Funktionen
Erzwingen
Verbieten
Truncation
Umgebungssuche
Zeitliche Eingrenzung
Eingrenzung auf deutschsprachige Sites
URL/Domain
Sonstige Funktionen der Volltextsuche
Andere Suchmöglichkeiten
AltaVista
altavista.com
150
Excite
excite.com
250
FastSearch
alltheweb.com
200
+Begriff
-Begriff
Begr*
a
√NEAR b
+Begriff
-Begriff
-√
+Begriff
-Begriff
Begr*
-/-
√
√ √
/
diverse Felder,
darunter Link,
Anker, Bild etc.
Katalog, Usenet,
Bilder, Audio, Video,
Shopping-Sites,
News etc.
-/
-
√
Katalog, Usenet,
Bilder, Audio, Video,
News, diverse andere
Spezialsuchen
ftp, MP3
Name
URL: http://www...
Funktionen
Erzwingen
Verbieten
Truncation
Umgebungssuche
URL/Domain
Go
go.com
keine Angabe
Google
google.com
85
HotBot
hotbot.com
keine Angabe
+Begriff
-Begriff
Begr*
-√
Feld
Feld
begr*
-√
√ √
/
Titel
automatisch
-Begriff
Begr*
-/Link
Katalog, Usenet,
Gelbe Seiten, MP3,
Filme, Börsenkurse,
News etc., div. andere
Spezialsuchen
Linux-RessourcenSuche, US-Regierungsdokumentensuche,
Stanford-Universität(Datenbank)-Suche
124
√
√ √
/
Multimedia-Inhalte,
Titel
News, Gelbe Seiten,
E-Mail-Adressen,
Usenet, ftp,
Domainnamen
etc.
ANHANG A. SUCHHILFEN IM WWW
125
Name
URL: http://www...
Funktionen
Erzwingen
Verbieten
Truncation
Umgebungssuche
URL/Domain
Lycos
lycos.com
50
MSN Search
search.msn.com
keine Angabe
Northern Light
northernlight.com
170
+Begriff
-Begriff
Begr*
√
-√
√ √
/
Titel
+Begriff
-Begriff
Begr*
-√
+Begriff
-Begriff
Begr*
-√
√
√ √
/
Titel
√
√
News, ftp, MP3,
Börseninfos, Usenet
etc.
E-Mail, Filme,
Auktionen, Bilder,
Lexikon, Börseninfos
etc.
/Titel, Firmenname,
Zeitschriftentitel
Firmendaten
Börsenkurse,
ausgesuchte
News-Ticker
Name
URL: http://www...
Funktionen
Erzwingen
Verbieten
Truncation
Umgebungssuche
URL/Domain
Acoon
acoon.de
23,2
Aladin
aladin.de
2,4
AltaVista.de
altavista.de
24,2
+Begriff
-Begriff
Begr*
-/-
über Menü
-√
/Titel, URL
+Begriff
-Begriff
Begr*
a
√NEAR b
-
Branchensuche
√ √
/
diverse Felder,
darunter Link,
Anker, Bild etc.
News, Multimedia
Name
URL: http://www...
Funktionen
Erzwingen
Verbieten
Truncation
Umgebungssuche
URL/Domain
Crawler.de
crawler.de
6,8
Eule
eule.de
7
Excite.de
excite.de
250
Begriff1 Begriff2
Begriff1 OR Begriff2
a NEAR b
-/Kleinanzeigen,
Fahrzeuge
+Begriff
-Begriff
Begr*
-√
/Beschreibung, Titel
Fahrzeuge,
Jobs, Praktika
über Maske
über Maske
- √
-/
Auktionen, Auto,
Bildung, Communities,
Computer, Wirtschaft,
Gesundheit, Horoskope,
Immobilien, Jobs etc.
Name
URL: http://www...
Funktionen
Erzwingen
Verbieten
Truncation
Umgebungssuche
Fireball
fireball.de
8,5
Infoseek
infoseek.de
14,5
Lycos.de
lycos.de
keine Angabe
+Begriff
-Begriff
Begr*
a NEAR b
+Begriff
-Begriff
Begr*
-
+Begriff
-Begriff
a NEAR b (ADJ,
FAR, BEFORE etc.)
- √
√
/
Titel
URL/Domain
√
√ √
/
Titel, Keywords,
Autor, Herausgeber,
Hostnamen, Links
Auskunft, Verkehr,
Reisen, Bildung,
Computer, Politik,
Kunst, Länder,
Gesundheit, News etc.
- √
√
/
Titel, Servername,
Link
Katalog, News,
Börsenkurse
Auskunft, Auto,
Bildung, Computer,
Finanztipps, Fußball,
Gesundheit, Jobs,
Kids etc.
A.2
Katalogdienste
Name
LookSmart
URL: http://...
Einträge
Kategorien
Regionale Verzeichnisse
Funktionen
Erzwingen/Verbieten
Und-/Oder-Verknüpfung
Web-Suchmaschine
Name
URL: http://...
Einträge
Kategorien
Regionale Verzeichnisse
Funktionen
Erzwingen/Verbieten
Und-/Oder-Verknüpfung
Web-Suchmaschine
A.3
Snap
Yahoo
www.looksmart.com
keine Angabe
keine
Angabe
√
Open Directory
Project
dmoz.org
ca. 1,4 Mio.
ca.
√ 210.000
www.snap.com
keine Angabe
keine Angabe
nur USA
www.yahoo.com
keine Angabe
keine
Angabe
√
√
-/
-/AltaVista
√ √
√/√
/
Schnittstelle zu 23
√ √
√/√
/
Inktomi
√ √
√/√
/
Inktomi
AllesKlar
www.allesklar.de
ca. 206.000
ca. 10.300
15.000 Gemeinden
Dino
www.dino-online.de
ca. 268.000
ca. 12.500
3.300 Orte
Sharelook
www.sharelook.de
ca. 100.000
ca. 15.000
21 Städte
Web.de
web.de
ca. 224.000
ca.
√ 8.000
√
√/-√
/
Fireball
√
-/ √
√
/
lotse.de
-/√
/-
√
-/
√ √
/
AltaVista
Metasuchdienste
Name
C4
Dogpile
Highway 61
Inference Find
Mamma
Metacrawler
ProFusion
Savvy Search
The Big Hub
Adresse
http://www...
c4.com
dogpile.com
highway61.com
inference.com
mamma.com
metacrawler.com
profusion.com
savvysearch.com
thebighub.com
Name
Apollo 7
Metabot
Metacrawler.de
MetaGer
Multimeta
Metaspinner
Adresse
http://www...
apollo7.de
metabot.de
metacrawler.de
metager.de
multimeta.de
metaspinner.de
Metasuche
Netzz
metasuche.de
nettz.de
Suchen
suchen.com
TopXplorer
EZF
EvD
Mw
SZw
Qg
126
topxplorer.de
EZF
√
EvD
√
-√
-√
√
tlw.
√
√
√
√
√
√
√
√
√
AND/OR
-/√
√/-√
√/
√/-√
√/√
√/√
√/√
√/√
/
EZF
√
EvD
√
-√
√
-√
-√
√
√
√
√
√
√
√
√ √
√/√
/
√
√
√ √
/
√
√
√ √
/
Ergebniszusammenfassung
Eliminierung von Duplikaten
Maschinen wählbar
Suchzeit wählbar
Quelle wird genannt
AND/OR
√ √
√/√
√/√
√/√
√/√
√/√
/
Abgefragte
Maschinen
16
14
max. 5
6
10
11
33
100
8
Abgefragte
Maschinen
9 dt., 3 spez.
6 dt.
13 dt., 4 spez.
18 dt., 2 spez.
9 dt., 1 int.
14 dt., 18 int.,
28 spez.
3 dt.
21 dt., 16 int.,
28 spez.
15 dt., 15 int.,
5 österr.
5 int.
Mw
√
in Grp.
√
√
√
√
√
SZw
-√
√
√
√
√
-√
Mw
√
√
√
√
√
√
SZw
-√
√
-
√
√
-
√
√
-
-
Qg
√
√
√
-√
√
√
√
√
Qg
√
-√
√
√
√
√
√
√
√
Suchergebnis
mit URL,
Titel, Abstract
UTA
UTA
UTA
T
UTA
UTA
UTA
UTA
UTA
Suchergebnis
mit URL,
Titel, Abstract
UTA
UTA
UTA
UTA
TA
UTA
UTA
UTA
UT
UT
A.4
127
Sonstige Suchhilfen
Suchmaschinenverzeichnisse
Beaucoup!
Buscopio
Internet Resource Guide for
Research and Exploration
InvisibleWeb
Klug Suchen!
Linky
Search
Suchfibel
WebData
Spezielle Suchdienste
1Jump
Amnesi
Cinema
Deja
Denic
Dr.Antonius
Encarta
Encyclopaedia Britannica
Financial Times
Gelbe Seiten
Hitchhikers guide to the galaxy
Intellectual Property Network
Internet Movie Database
Juris
Lycos MP3 Search
Medline
Meyers Lexikon
URL
http://www.beaucoup.com/
http://www.buscopio.com/
Beschreibung
tausende Internet-Recherchequellen
Metaverzeichnis spanisches Internet
http://www.researchedge.com/irg/
http://www.invisibleweb.com/
http://www.klug-suchen.de/
http://stob.de/linky/
http://www.search.de/
http://www.suchfibel.de/
http://www.webdata.com/
Verzeichnis kommerzieller Anbieter
hunderte Recherchequellen
gut sortiertes Verzeichnis
etliche hundert Recherchequellen
gut sortiertes Verzeichnis
über 600 Suchmaschinen
”World Almanach”
http://www.1jump.com/
http://www.amnesi.com/
http://www.cinema.de/
http://www.deja.com/
http://www.denic.de/
http://www.dr-antonius.de/
http://www.encarta.msn.com/
http://www.britannica.com/
http://www.ft.com/
http://www.gelbe-seiten.de/
http://www.h2g2.com/
http://www.patents.ibm.com/
http://us.imdb.com/
http://www.juris.de/
http://www.mp3.lycos.com/
http://www.ncbi.nlm.nih.gov/PubMed/
http://www.iicm.edu/meyers/
MP3
MP3Meta
New York Times
Paperball
PC Webopaedia
PC Guide
Rechtschreiblexikon
Wer liefert was
Wer weiß was
WoWoWo
http://www.mp3.com/
http://www.mp3meta.com/
http://www.nyt.com/
http://www.paperball.de/
http://www.pcwebopedia.com/
http://www.pcguide.com/
http://news.lycos.de/ndr/ge/
http://www.wlwonline.de/
http://www.wer-weiss-was.de/
http://www.wowowo.de/
riesige Unternehmensdatenbank
Suchmaschine für URL’s
Kinodatenbank
Suchmaschine für Usenet-News
whois für .de-Domains
Suche im medizinischen Bereich
Online-Version des Nachschlagewerkes
kostenlose Version der Enzyklopädie
Artikeldatenbank
Branchenbuch
Lexikon
Patentdatenbank
Film- und Schauspielerdatenbank
kostenpflichtige Rechtsdatenbank
MP3 Suchmaschine
medizinische Fachdatenbank
auf drei Benutzer beschränkte
Online-Version
MP3 Suchmaschine
MP3-Metasuchmaschine
Artikeldatenbank
Zeitungsmetasuchmaschine
Akronymlexikon
PC-Lexikon
neue deutsche Rechtschreibung
Produktdatenbank
Expertendienst
Online-Shop-Suchmaschine
Anhang B
Metadaten- und
Klassifikationsschemata
B.1
Dublin Core Metadata Element Set, V1.1
Um die Konsistenz innerhalb des Schemas und mit anderen Metadatenschemata sicherzustellen, aber auch um eine klar definierte Verwendung zu gewährleisten, unterliegt die Definition der einzelnen Metadaten-Elemente den Konventionen des ISO/IEC
11179 Standards. Jedes DC-Element wird durch folgende Attribute beschrieben [DC99]:
Name
Identifier
Version
Registration Authority
Language
Definition
Obligation
Datatype
Maximum Occurrence
Comment
ein Label, das dem DC-Element zugewiesen wird
ein eindeutiger Kennzeichner
eine Versionsnummer
eine Person, Organisation etc., die das DC-Element zugelassen hat
Sprache, in der das DC-Element spezifiziert ist
eine exakte Beschreibung des Konzeptes (Semantik) des DC-Elementes
gibt an, ob das DC-Element zwingend oder optional zu verwenden ist
gibt die Art der Daten an, die der Wert des DC-Elementes annehmen darf
gibt an, wie oft das DC-Element vorkommen darf
ein Hinweis auf die korrekte Anwendung des DC-Elementes
Innerhalb der aktuellen Version ergibt sich eine Vereinfachung, da einige Attribute für
alle DC-Elemente denselben Wert annehmen. Dies sind im einzelnen [DC99]:
Version
Registration Authority
Language
Obligation
Datatype
Maximum Occurence
1.1
Dublin Core Metadata Initiative
en
Optional
Character String
Unlimited
Somit werden die DC-Elemente durch die verbleibenden Attribute Name, Identifier,
Definition und Comment eindeutig charakterisiert. Die exakte Beschreibung mit Beispielen und Empfehlungen für die Zuweisung passender Werte ist unter [DC99] zu
finden.
128
ANHANG B. METADATEN- UND KLASSIFIKATIONSSCHEMATA
129
Der Dublin Core V1.1 besteht aus folgenden 15 Elementen [DC99]:
DC.Title
DC.Creator
DC.Subject
DC.Description
DC.Publisher
DC.Contributor
DC.Date
DC.Type
DC.Format
DC.Identifier
DC.Source
DC.Language
DC.Relation
DC.Coverage
DC.Rights
B.2
Name der Ressource
Person, Organisation etc., die den Inhalt der Ressource verfaßt hat
Thema des Inhaltes der Ressource
Person, Organisation etc., die die Ressource zugänglich macht
Person, Organisation etc., die einen Beitrag zum Inhalt der Ressource geleistet hat
Datum der Erstellung, Gültigkeit etc. der Ressource
Art des Inhaltes der Ressource
physikalische oder digitale Repräsentation der Ressource
eindeutige Referenz der Ressource in einem gegebenen Kontext (z.B. ISBN)
Referenz auf eine andere Ressource, von der die aktuelle Ressource stammt oder abgeleitet wurde
Sprache, in der Inhalt der Ressource verfaßt ist
Referenz auf eine verwandte Ressource
Bereich, den der Inhalt der Ressource abdeckt (z.B. ein geographisches Gebiet, eine Zeitperiode)
Informationen zu den mit der Ressource verknüpften Rechten (z.B. Copyright)
Dublin Core Metadata Template
<HTML>
<HEAD>
<TITLE> </TITLE>
<META NAME = "DC.identifier"
SCHEME = "ISBN|ISSN|URN|etc."

CONTENT = "">
<META NAME = "DC.title"
TYPE = "alternative title"


CONTENT = "">
<META NAME = "DC.creator"
TYPE ="Name.Personal|Name.Corporate"
CONTENT = "">
<META NAME = "DC.publisher"
CONTENT = "">
<META NAME = "DC.contributors"
TYPE = "Name.Personal|Name.Corporate"
CONTENT = "">
<META NAME = "DC.subject"
SCHEME = "LCSH|MeSH|AAT|LCC|DDC|etc."

CONTENT = "">
<META NAME = "DC.description"
CONTENT = "">
<META NAME = "DC.date"
TYPE = "Date.Modified|Date.ValidTo|
Date.ValidFrom"

SCHEME = "ISO 8601|other"

CONTENT = "">
<META NAME = "DC.type"
CONTENT = "">
<META NAME = "DC.format"
TYPE = "IMT"

CONTENT = "">
Onlineversion:
<META NAME = "DC.source"
SCHEME = "ISBN|ISSN|URN|etc."

TYPE = "Source.Date"

CONTENT = "">
<META NAME = "DC.language"
SCHEME = "Z39.53|ISO 639-1"

CONTENT = "">
<META NAME = "DC.relation"
SCHEME = "ISBN|ISSN|URL|etc."
TYPE="Relation.IsParentOf|Relation.IsChildOf|
Relation.IsMemberOf"

CONTENT = "">
<META NAME = "DC.coverage"
SCHEME = "LatLong|etc."
TYPE = "Coverage.Spatial|Coverage.Temporal"

CONTENT = "">
<META NAME = "DC.rights"
SCHEME = "URL|URN"
CONTENT = "">
<LINK REL = "SCHEMA.dc"
HREF = "http://purl.org/metadata/">
</HEAD>
<BODY> . . .
http://www.libraries.psu.edu/iasweb/personal/jca/dublin/dc_templ.htm
B.3
130
xFIND Quality Metadata Scheme, V1.0
xQMS umfaßt 34 Elemente, wobei Ähnlichkeiten zu anderen Metadatenschemata (DC,
LOM) durchaus beabsichtigt sind. Eine wesentliche Erweiterung sind jene Elemente, die
ein Rating durch eine qualifizierte Person, Organisation etc. zulassen und für den Benutzer abrufbar machen. [Wei2000]
BESCHREIBENDE ATTRIBUTE
xQMS.Creator.Person
xQMS.Creator.Organisation
xQMS.Creator.Publisher
Person, die den Inhalt der Ressource verfaßt hat
Organisation, die für die Erstellung des Inhaltes verantwortlich ist
Person, Organisation etc., die die Ressource zugänglich macht
xQMS.Tech.Ident
xQMS.Tech.Scope
xQMS.Tech.Signature
Ort der Ressource (z.B. URL, URN, URI oder DOI)
Gültigkeitsbereich der Beschreibung (z.B. Webpage, Webbereich)
Checksumme für Kontrollzwecke
xQMS.Content.Type
xQMS.Content.Title
xQMS.Content.Topic
xQMS.Content.Alt Topic
xQMS.Content.Keywords
xQMS.Content.Description
xQMS.Content.Quotation
xQMS.Content.Language
Art des Inhaltes der Ressource (z.B. Text, Audio)
Name der Ressource
Thema des Inhaltes der Ressource nach Dewey
zusätzliches Thema entsprechend dem nachgenannten Schema
zusätzlich verwendetes Klassifikationsschema
frei wählbare Schlüsselwörter zum Inhalt der Ressource
Art und Weise, wie die Ressource zitiert werden soll
Sprache, in der Inhalt der Ressource verfaßt ist
xQMS.Version.Number
xQMS.Version.Prev
xQMS.Version.Next
xQMS.Version.Create
xQMS.Version.Last modified
Versionsnummer der beschriebenen Ressource
Referenzierung der vorherigen Version, Angabe der URL
Referenzierung der folgenden Version, Angabe der URL
Datum der Erstellung
Datum der letzten Aktualisierung
BEWERTENDE ATTRIBUTE
xQMS.Myop.Diction
xQMS.Myop.Audience.Age
xQMS.Myop.Audience.Knowledge
xQMS.Myop.Authority
xQMS.Myop.Accuracy.Depth
xQMS.Myop.Accuracy.Width
Ausdruck, Stil der Sprache (z.B. einfach, anspruchsvoll)
empfohlenes Mindestalter der Zielgruppe
vorausgesetztes Vorwissen der Zielgruppe
Bewertung nach wissenschaftlichem Ansehen
Informationstiefe
Informationsbreite
xQMS.Rating.Creator.Person
xQMS.Rating.Creator.Organisation
xQMS.Rating.Creator.Publisher
xQMS.Rating.Content.Language
xQMS.Rating.Version.Last modified
xQMS.Rating.Version.Time to live
xQMS.Rating.Tech.Signature
Person, die die Bewertung durchführt
Bewertungsagentur
Organisation, die die Bewertung zugänglich macht
Sprache, in der die Bewertung verfaßt ist
Datum der letzten Aktualisierung der Bewertung
Lebensdauer der Bewertung
verschlüsselte Signatur der Bewertung
B.4
Haupt- und Unterklassen von DDC
000 Generalities
010 Bibliography
020 Library & information sciences
030 General encyclopedic works
040 [unassigned]
050 General serial publications
060 General organizations & museology
070 News media, journalism, publishing
080 General collections
090 Manuscripts & rare books
100 Philosophy & psychology
110 Metaphysics
120 Epistemology, causation, humankind
130 Paranormal phenomena
140 Specific philosophical schools
150 Psychology
160 Logic
170 Ethics (Moral philosophy)
180 Ancient, medieval, Oriental philosophy
190 Modern western philosophy
200 Religion
210 Philosophy & theory of religion
220 Bible
230 Christianity, Christian theology
240 Christian moral & devotional theology
250 Christian orders & local church
260 Social & ecclesiastical theology
270 History of Christianity & Christian church
280 Christian denominations & sects
290 Comparative religion & other religions
300 Social sciences
310 Collections of general statistics
320 Political science
330 Economics
340 Law
350 Public administration & military science
360 Social problems & services; association
370 Education
380 Commerce, communications, transportation
390 Customs, etiquette, folklore
400 Language
410 Linguistics
420 English & Old English
430 Germanic languages, German
440 Romance languages, French
450 Italian, Romanian, Rhaeto-Romanic
460 Spanish & Portuguese languages
470 Italic languages, Latin
480 Hellenic languages, Classical Greek
490 Other languages
Onlineversion:
500 Natural sciences & mathematics
510 Mathematics
520 Astronomy & allied sciences
530 Physics
540 Chemistry & allied sciences
550 Earth sciences
560 Paleontology, Paleozoology
570 Life sciences, Biology
580 Plants
590 Animals
600 Technology (Applied sciences)
610 Medical sciences, Medicine
620 Engineering & allied operations
630 Agriculture & related technologies
640 Home economics & family living
650 Management & auxiliary services
660 Chemical engineering
670 Manufacturing
680 Manufacture for specific uses
690 Buildings
700 The arts, Fine and decorative arts
710 Civic & landscape art
720 Architecture
730 Plastic arts, Sculpture
740 Drawing & decorative arts
750 Painting & paintings
760 Graphic arts, Printmaking & prints
770 Photography & photographs
780 Music
790 Recreational & performing arts
800 Literature & rhetoric
810 American literature in English
820 English & Old English literatures
830 Literatures of Germanic languages
840 Literatures of Romance languages
850 Italian, Romanian, Rhaeto-Romanic
860 Spanish & Portuguese literatures
870 Italic literatures, Latin
880 Hellenic literatures, Classical Greek
890 Literatures of other languages
900 Geography & history
910 Geography & travel
920 Biography, genealogy, insignia
930 History of ancient world to ca. 499
940 General history of Europe
950 General history of Asia, Far East
960 General history of Africa
970 General history of North America
980 General history of South America
990 General history of other areas
http://www.oclc.org/oclc/fp/about/ddc21sm2.htm
131
B.5
Haupt- und Unterklassen von UDC
0 Generalities. Science and knowledge. Information. Documentation. Librarianship etc.
00 Prolegomena. Fundamentals of knowledge and culture
01 Bibliography and bibliographies. Catalogues
02 Librarianship
030 General reference works. Encyclopaedias. Dictionaries
050 Serial publications. Periodicals
06 Organizations and other types of cooperation. Congresses. Museums
070 Newspapers. The Press. Journalism
08 Polygraphies. Collective works
09 Manuscripts. Rare and remarkable works
1 Philosophy
11 Metaphysics. Fundamental problems
122/129 Special metaphysics
13 Philosophy of mind and spirit. Metaphysics of spiritual life
14 Philosophical systems and points of view.
159.9 Psychology
16 Logic. Epistemology. Theory of knowledge. Methodology of logic
17 Moral philosophy. Ethics
2 Religion. Theology
21 Natural theology
22 The Bible. Holy scripture
23 Dogmatic theology
24 Practical theology
25 Pastoral theology
26 The Christian Church in general
27 General history of the Christian Church
28 Christian churches, sects, denominations
29 Non-Christian religions
3 Social sciences
30 Theories, methodology etc. Sociography
31 Demography. Sociology. Statistics
32 Politics
33 Economics. Economic science
34 Law. Jurisprudence
35 Public administration. Government. Military affairs
36 Ensuring the mental and material necessities of life. Social aid. Insurance
37 Education. Teaching. Training. Leisure
389 Metrology. Weights and measures
39 Ethnology. Ethnography. Folklore
4 (Vacant; linguistics transferred to 81)
5 Mathematics and natural sciences
50 Generalities. Nature and conservation
51 Mathematics
52 Astronomy. Astrophysics. Space research. Geodesy
53 Physics
54 Chemistry. Crystallography. Mineralogy
55 Earth sciences. Geology. Meteorology etc.
56 Palaeontology
57 Biological sciences in general
58 Botany
59 Zoology
6 Applied sciences. Medicine. Technology
60 General questions of the applied sciences
61 Medical sciences
62 Engineering. Technology in general
63 Agriculture. Forestry. Farming etc.
64 Home economics. Domestic science. Housekeeping
65 Management and organization of industry, trade and communication
66 Chemical technology. Chemical and related industries
67 Various industries, trades and crafts
68 Assembled articles. Precision mechanisms
69 Building (construction) trade. Building materials. Building practice and procedure
132
7 The arts. Recreation. Entertainment. Sport
71 Physical planning. Regional, town and country planning. Landscaping
72 Architecture
73 Plastic arts. Sculpture
74 Drawing. Design. Applied arts and crafts
75 Painting
76 Graphic arts. Graphics
77 Photography and similar processes
78 Music
79 Recreation. Entertainment. Games. Sport
8 Language. Linguistics. Literature
80 General questions. Prosody
81 Linguistics and languages
82 Literature generally
821 Literatures of individual languages
9 Geography. Biography. History
902/908 Related sciences. Archaeology. Prehistory. Historic remains. Study of a locality
91 Geography. Exploration. Travel
913 Regional geography in general. Geography of the ancient world
914/919 Individual regions and countries of the modern world
929 Biographical and related studies. Genealogy. Heraldry etc.
93/99 History
930 Science of history. Diplomatic. Archivistics. Epigraphy. Palaeography
931/939 Ancient history
94/99 Mediaeval and modern history. History of individual countries
Onlineversion:
B.6
A
B
C
D
E
F
G
H
J
K
L
M
N
P
Q
R
S
T
U
V
Z
http://www.niss.ac.uk/resource-description/udcbrief.html
Hauptklassen von LCC
General works
Philosophy. Psychology. Religion
Auxiliary sciences of history
History: General and old world
History: America
History: America
Geography. Anthropology. Recreation
Social sciences
Political science
Law
Education
Music and books on music
Fine arts
Language and literature
Science
Medicine
Agriculture
Technology
Military science
Naval science
Library science
Onlineversion:
http://lcweb.loc.gov/catdir/cpso/lcco/lcco.html
133
B.7
2/9
A/AL
AM/AX
AY
B
C
D
E/GQ
GR
GU
GY
H
I
J
K
L/O
P
Q
R
S
T
U/V
W
X/Y
Hauptklassen von BLISS
Generalia, Phenomena, Knowledge, Information science & technology
Philosophy & Logic.
Mathematics, Probability, Statistics.
General science.
Physics, Engineering.
Chemistry, Chemical Engineering.
Space & Earth sciences, Astronomy, Geology, Geography
Biological sciences
Agriculture
Veterinary Science
Ecology
Physical Anthropology, Human biology, Health sciences.
Psychology & Psychiatry.
Education.
Society (includes Social sciences, sociology & social anthropology).
History, (includes Archaeology, biography and travel)
Religion, Occult, Morals and ethics.
Social welfare & Criminology. Rev. ed.
Politics & Public administration.
Law.
Economics & Management of economic enterprises.
Technology.
Recreation, Arts, Music
Language, Literature
Onlineversion:
B.8
http://www.sid.cam.ac.uk/bca/bcoutline.htm
Haupt- und Unterklassen von ACM CCS
A. General Literature
A.0 GENERAL
A.1 INTRODUCTORY AND SURVEY
A.2 REFERENCE (e.g., dictionaries, encyclopedias, glossaries)
A.m MISCELLANEOUS
B. Hardware
B.0 GENERAL
B.1 CONTROL STRUCTURES AND MICROPROGRAMMING
B.2 ARITHMETIC AND LOGIC STRUCTURES
B.3 MEMORY STRUCTURES
B.4 INPUT/OUTPUT AND DATA COMMUNICATIONS
B.5 REGISTER-TRANSFER-LEVEL IMPLEMENTATION
B.6 LOGIC DESIGN
B.7 INTEGRATED CIRCUITS
B.8 PERFORMANCE AND RELIABILITY
B.m MISCELLANEOUS
C. Computer Systems Organization
C.0 GENERAL
C.1 PROCESSOR ARCHITECTURES
C.2 COMPUTER-COMMUNICATION NETWORKS
C.3 SPECIAL-PURPOSE AND APPLICATION-BASED SYSTEMS
C.4 PERFORMANCE OF SYSTEMS
C.5 COMPUTER SYSTEM IMPLEMENTATION
C.m MISCELLANEOUS
D. Software
D.0 GENERAL
D.1 PROGRAMMING TECHNIQUES
D.2 SOFTWARE ENGINEERING
D.3 PROGRAMMING LANGUAGES
D.4 OPERATING SYSTEMS
D.m MISCELLANEOUS
134
E. Data
E.0 GENERAL
E.1 DATA STRUCTURES
E.2 DATA STORAGE REPRESENTATIONS
E.3 DATA ENCRYPTION
E.4 CODING AND INFORMATION THEORY
E.5 FILES
E.m MISCELLANEOUS
F. Theory of Computation
F.0 GENERAL
F.1 COMPUTATION BY ABSTRACT DEVICES
F.2 ANALYSIS OF ALGORITHMS AND PROBLEM COMPLEXITY
F.3 LOGICS AND MEANINGS OF PROGRAMS
F.4 MATHEMATICAL LOGIC AND FORMAL LANGUAGES
F.m MISCELLANEOUS
G. Mathematics of Computing
G.0 GENERAL
G.1 NUMERICAL ANALYSIS
G.2 DISCRETE MATHEMATICS
G.3 PROBABILITY AND STATISTICS
G.4 MATHEMATICAL SOFTWARE
G.m MISCELLANEOUS
H. Information Systems
H.0 GENERAL
H.1 MODELS AND PRINCIPLES
H.2 DATABASE MANAGEMENT
H.3 INFORMATION STORAGE AND RETRIEVAL
H.4 INFORMATION SYSTEMS APPLICATIONS
H.5 INFORMATION INTERFACES AND PRESENTATION (e.g., HCI)
H.m MISCELLANEOUS
I. Computing Methodologies
I.0 GENERAL
I.1 SYMBOLIC AND ALGEBRAIC MANIPULATION
I.2 ARTIFICIAL INTELLIGENCE
I.3 COMPUTER GRAPHICS
I.4 IMAGE PROCESSING AND COMPUTER VISION
I.5 PATTERN RECOGNITION
I.6 SIMULATION AND MODELING
I.7 DOCUMENT AND TEXT PROCESSING
I.m MISCELLANEOUS
J. Computer Applications
J.0 GENERAL
J.1 ADMINISTRATIVE DATA PROCESSING
J.2 PHYSICAL SCIENCES AND ENGINEERING
J.3 LIFE AND MEDICAL SCIENCES
J.4 SOCIAL AND BEHAVIORAL SCIENCES
J.5 ARTS AND HUMANITIES
J.6 COMPUTER-AIDED ENGINEERING
J.7 COMPUTERS IN OTHER SYSTEMS
J.m MISCELLANEOUS
K. Computing Milieux
K.0 GENERAL
K.1 THE COMPUTER INDUSTRY
K.2 HISTORY OF COMPUTING
K.3 COMPUTERS AND EDUCATION
K.4 COMPUTERS AND SOCIETY
K.5 LEGAL ASPECTS OF COMPUTING
K.6 MANAGEMENT OF COMPUTING AND INFORMATION SYSTEMS
K.7 THE COMPUTING PROFESSION
K.8 PERSONAL COMPUTING
K.m MISCELLANEOUS
Onlineversion:
http://www.acm.org/class/1998/overview.html
135
Anhang C
CD ROM
Als Beilage zu dieser Diplomarbeit finden Sie eine CD-ROM, die folgende Informationen
enthält:
• Diese Arbeit in elektronischer Form (PDF und HTML).
• Die im Literaturverzeichnis angeführten Quellen (soweit in elektronischer Form
verfügbar).
• Java-Quellcode des Brokerprototyps und weiterer Module des xFIND-Suchsystem.
• Dokumentation des xFIND-Suchsystems.
• Software frei verfügbarer Indexer.
• Testdaten im SOIF-Format.
Alle oben genannten Informationen sind über die Datei index.html erreichbar.
136
Abbildungsverzeichnis
1.1
Durchschnittliche Erfolgsrate der Suche im WWW . . . . . . . . . . . .
4
2.1
2.2
Gathering zentraler Suchdienste mit Hilfe von Robots und Spiders . . .
Beispielarchitektur eines xFIND-Suchsystems . . . . . . . . . . . . . . .
11
12
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
Funktionales Modell eines typischen IR Systems . . . . . . . . .
Basismodelle von IR Systemen und deren Einteilung . . . . . . .
Sortiertes Array zur Realisierung eines invertierten Files . . . .
Präfix B-Baum mit variabler Anzahl von Knotenverzweigungen .
Trie zur Verwaltung von binär beschriebenen Strings . . . . . .
Signaturfile als sequentielle Anordnung von Blocksignaturen . .
Spezifikation SOIF-Format in BNF . . . . . . . . . . . . . . . .
HTML-Datei und korrespondierendes SOIF-Objekt . . . . . . .
Suchinterface von WebGlimpse . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
16
17
19
21
21
23
33
34
37
4.1
Hauptklassen des Open Directory Project . . . . . . . . . . . . . . . . .
66
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
Abdeckungsgrad von WWW-Suchdiensten
Suchinterface Metacrawler . . . . . . . . .
Suchinterface Highway61 . . . . . . . . . .
Suchinterface Mamma . . . . . . . . . . .
Suchinterface C4 . . . . . . . . . . . . . .
Suchinterface TheBigHub . . . . . . . . .
Suchinterface Profusion . . . . . . . . . . .
Suchinterface Metager . . . . . . . . . . .
Suchergebnis Metacrawler . . . . . . . . .
Suchergebnis TheBigHub . . . . . . . . . .
Suchergebnis C4 . . . . . . . . . . . . . . .
Suchergebnis Highway61 . . . . . . . . . .
87
90
90
91
91
92
92
93
96
97
97
97
6.1
6.2
6.3
xFIND-Broker als Vermittler zwischen Benutzer und Indexern . . . . . 98
JAVA-Applet zur Verwaltung der Indexerdatenbank . . . . . . . . . . . 100
Klassenstruktur des xFIND-Broker . . . . . . . . . . . . . . . . . . . . 102
137
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
xFIND-Protokoll zur Client-Server-Kommunikation
Abarbeitung einer Suchanfrage durch den Broker .
Array zur Broker-Indexer-Kommunikation . . . . .
Kommunikation zwischen Broker und Indexer . . .
Datenstruktur zur Speicherung von Suchergebnissen
Hashtabelle zur Verwaltung des Broker-Cache . . .
Suchformular des Referenzclient . . . . . . . . . . .
Ergebnisausgabe durch den Referenzclient . . . . .
138
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
103
106
107
109
110
113
115
118
Tabellenverzeichnis
3.1
Aspekte und Aspektwerte von IR Systemen als Ergebnis einer Domain
Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Funktionsumfang frei verfügbarer IR Systeme . . . . . . . . . . . . . .
3.3 Performance der Indizierung unter LINUX . . . . . . . . . . . . . . . .
3.4 Performance der Indizierung unter UNIX . . . . . . . . . . . . . . . . .
3.5 Performance der Suche unter LINUX . . . . . . . . . . . . . . . . . . .
3.6 Performance der Suche unter UNIX . . . . . . . . . . . . . . . . . . . .
3.7 Übersicht der Leistungen von CPL . . . . . . . . . . . . . . . . . . . .
3.8 Aufstellung der von Findex angebotenen Merkmale . . . . . . . . . . .
3.9 Daten und Fakten zum AltaVista SDK . . . . . . . . . . . . . . . . . .
3.10 Liste der Merkmale des Verity Developer’s Kit . . . . . . . . . . . . . .
3.11 Kurzbeschreibung des Fulcrum Search Builder . . . . . . . . . . . . . .
17
36
44
44
45
46
48
49
50
51
53
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
63
68
74
76
78
79
80
81
82
Auszug aus den beschreibenden Attributen von xQMS . . . . . . .
Beispiel für die Klassifikation nach ACM CSS . . . . . . . . . . . .
Veranschaulichung der hierarchischen Notation von DDC . . . . . .
Häufigkeitsverteilung von DDC-Klassen für die NetFirst-Datenbank
Beispiele für die Klassifikation nach UDC . . . . . . . . . . . . . . .
Beispiele für die Klassifikation nach LCC . . . . . . . . . . . . . . .
Beispiele für die Klassifikation nach BC2 . . . . . . . . . . . . . . .
Beispiel für die Klassifikation nach CC . . . . . . . . . . . . . . . .
Einige Kenndaten der betrachteten Universalklassifikationen . . . .
139
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Listingsverzeichnis
6.1
6.2
6.3
6.4
6.5
Kompilieren der xFIND-Broker-Packages . . . . . . . .
Start des xFIND-Broker von der Kommandozeile . . .
Start des xFIND-Broker mittels xFIND-Manager . . .
Map-Dateiformat des Broker-Cache . . . . . . . . . . .
Start des xFIND-Brokerclient von der Kommandozeile
140
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
99
101
101
114
115
Literaturverzeichnis
[AV99]
AltaVista (1999). Produktbeschreibung AltaVista Search Developer’s Kit,
AltaVista Company, Palo Alto, California, USA.
http://altavista.software.digital.com/search/avsdk97/index.asp
[Bag99]
Bager, J. (1999). Orientierungslose Infosammler - Warum die Suche im Internet
oft mühsam vonstatten geht und was die Suchmaschinen-Betreiber dagegen tun,
c’t - Magazin für Computertechnik, (23) 1999, pp. 158-161.
[BC87]
Belkin, N.J., Croft, W.B. (1987). Retrieval Techniques, Annual Review of Information Science and Technology, New York, Elsevier Science Publishers,
pp. 109-145.
[BK99]
Bager, J., Kossel, A. (1999). Preissuchen - WWW-Suchmaschinen, Kataloge
und Metasucher im Vergleich, c’t - Magazin für Computertechnik, (23) 1999,
pp. 162-171.
[Bliss99]
Bliss (1999). The BLISS Bibliographic Classification, History & Description,
Bliss Classification Association.
http://www.sid.cam.ac.uk/bca/bchist.htm
[Bru93]
Brugger, J.M. (1993). Cataloging the Internet, MC journal, The journal of academic media librarianship, Vol. 1(2), ISSN 1069-6792.
http://ublib.buffalo.edu/libraries/units/cts/Internet/brugger.html
[BS99]
Borggraefe, S., Schade, O. (1999). Weniger weit weg. Programmpakete zur Indizierung der eigenen Website, iX - Magazin für professionelle Informationstechnik,
(2) 1999, pp.89-94
http://www.heise.de/ix/artikel/1999/02/089/
[CCMS96]
Chan, L.M., Comaromi, J.P., Mitchell, J.S., Satija M.P. (1996). Dewey Decimal Classification, A Practical Guide, 2nd Edition, OCLC Forest Press,
ISBN 0-910608-55-5.
[CCS99]
ACM (1999). Introduction to the ACM Computing Classification System [1998
Version], Association for Computing Machinery, New York, USA.
http://www.acm.org/class/1998/ccs98-intro.html
[CH98]
Caglayan, A.K., Harrison, C.G. (1998). Intelligente Software-Agenten: Grundlagen, Technik und praktische Anwendung im Unternehmen, Hanser Verlag,
ISBN 3-446-19269-7.
141
[CPG99]
PLS (1999). Callable Personal
America Online Inc. und PLS.
http://www.pls.com/cpl.htm
[CPL99]
PLS
(1999).
Produktbeschreibung
America Online Inc. und PLS.
[Dah74]
Dahlberg, I. (1974). Grundlagen universaler Wissensordnung, Verlag Dokumentation, Pullach bei München, ISBN 3-7940-3623-9.
[DC99]
Dublin Core (1999). Dublin Core Metadata Element Set, Version 1.1: Reference
Description, Dublin Core Metadata Initiative.
http://purl.org/DC/documents/rec-dces-19990702.htm
[DDC99]
Dewey Decimal Classification (1999). Expanded Introduction to the Dewey Decimal Classification, OCLC Online Computer Library Center.
http://www.oclc.org/oclc/fp/about/expand.htm
[Ever99]
Eversberg, B. (1999). Was sind und was sollen bibliothekarische Datenformate,
Universitätsbibliothek TU Braunschweig, ISBN 3-927115-21-5.
http://www.biblio.tu-bs.de/allegro/formate/kap107.htm
[FB92]
Frakes, W.B., Baeza-Yates, R. (1992). Information Retrieval: Data Structures
and Algorithms, Prentice-Hall, ISBN 0-13-463837-9.
[FIN99]
Findex (1999). Produktbeschreibung Findex Full Text Indexing and Retrieval
Toolkit.
http://www.1source.com/~pollarda/findex/
[FS97]
Feather, J., Sturges, P. (1997). Four Major Classification Schemes, International
Encyclopedia of Information and Library Science.
http://alexia.lis.uiuc.edu/course/fall1998/lis380/week07/cls_
scheme.html
[FUL99]
Fulcrum (1999). Produktbeschreibung Fulcrum Search Server und Search Builder.
http://www.fulcrum.com/english/products/sshome.htm
[Gla98]
Glassel, A. (1998). Was Ranganathan a Yahoo !?, University of Wisconsin,
Internet Scout Project, End User’s Corner.
http://scout.cs.wisc.edu/toolkit/enduser/archive/1998/euc-9803.
html
[GMP99]
Gütl, C., Maurer H., Pivec, M. (1998). Learning on Demand using xFIND:
An Improved Way for Ongoing and Lifelong Learning as a Smart Module
for the GENTLE Learning Environment, Institute for Information Processing
and Computer Supported new Media (IICM), Graz University of Technology,
Austria.
http://xfind.iicm.edu/research/icce99/icce99_learning_on_demand.
html
[Gütl99]
Gütl, C. (1999). xFIND 2000, Pflichtenheft und Arbeitsplan, Institut für Informationsverarbeitung und Computergestützte neue Medien (IICM), Technische
Universität Graz, Austria.
142
Librarian
6.3
Callable
Programmer’s
Personal
Guide,
Librarian,
[Gütl99a]
Gütl, C. (1999). Concept for a future-oriented Information Discovery System,
Institut für Informationsverarbeitung und Computergestützte neue Medien
(IICM), Technische Universität Graz, Austria.
http://xfind.iicm.edu/motivation/generaloverview/sld001.htm
[HSW96]
Hardy, D.R., Schwartz, M.F., Wessels, D.P. (1996). Harvest User’s Manual.
http://www.tardis.ed.ac.uk/harvest/docs/old-manual/manual.ps
[Ink2000]
Inktomi (2000). Web Surpasses One Billion Documents, Press release about a
web study conducted by Inktomi and NEC Research Institute, January 18, 2000,
Inktomi Corporation, Foster City, California, USA.
http://www.inktomi.com/new/press/billion.html
[IS99]
Isearch (1999). The complete guide to Using and Configuring the CNIDR Isearch
System, Center for Networked Information Discovery and Retrieval (CNIDR).
http://www.cnidr.org/ir/ir.html
[Jär96]
Järnefors, O. (1996). A short overview of ISO/IEC 10646 and Unicode, Royal
Institute of Technology (KTH), Stockholm, Sweden.
http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html
[KABL96]
Koch, T., Ardö, A., Brümmer, A., Lundberg, S. (1996). The building and maintenance of robot based internet search services: A review of current indexing and
data collection methods, Lund University Library, Lund, Sweden.
http://www.ub2.lu.se/desire/radar/reports/D3.11/
[Kar99]
Karzauninkat, S. (1999). Zielfahndung - Suchmaschinen, Kataloge, Spezialisten
und kommerzielle Datenbanken richtig einsetzen, c’t - Magazin für Computertechnik, (23) 1999, pp. 172-179.
http://www.heise.de/ct/99/23/172/
[Koc97]
Koch, T. (1997). The role of classification schemes in Internet resource description and discovery, Lund University Library, Lund, Sweden.
http://www.ukoln.ac.uk/metadata/desire/classification/
[Koc98]
Koch, T. (1998). Nutzung von Klassifikationssystemen zur verbesserten Beschreibung, Organisation und Suche von Internet, Publiziert in: Buch und Bibliothek
50:5 (1998), pp.326-335.
http://www.ub2.lu.se/tk/publ/bubmanus.html
[Kor99]
Korpela, J. (1999). A tutorial on character code issues, Helsinki University of
Technology (HUT), Finland, Computing Centre.
http://www.hut.fi/u/jkorpela/chars.html
[Leg99]
Legenstein, H. (1999). Qualitätsaspekte zur Wissensauffindung und Testimplementation für das xFIND System, Diplomarbeit am Institut für Informationsverarbeitung und Computergestützte neue Medien (IICM), Technische Universität
Graz, Austria.
http://www2.iicm.edu/cguetl/education/thesis/hlegen
[LG99]
Lawrence, S., Giles, C.L. (1999). Accessibility of information on the web.,
Published in NATURE, Vol.400, July 8, 1999.
http://www.neci.nec.com/~giles/html/new.stuff.html
143
[Mau96]
Maurer, H. (1996). Hyper-G now Hyperwave. The next generation web solution, Institute for Information Processing and Computer Supported new Media
(IICM), University of Technology Graz, Austria.
Addison-Wesley Publishing Company, ISBN 0-201-40346-3.
[MF99]
Millstead, J., Feldman, S. (1999). Metadata: Cataloging by Any Other Name ...,
Published in ONLINE.
http://www.onlineinc.com/onlinemag/metadata/
[MS95]
Morton, D., Silcot, S. (1995). Systems for providing searchable access to collections of HTML documents, Technical Paper, Australian WWW Conference AusWeb95.
http://www.scu.edu.au/sponsored/ausweb/ausweb95/papers/indexing/
morton/
[Mun95]
Mundie, D.A. (1995). Organizing Computer Resources, Polymath Systems, Pittsburgh.
http://www.lm.com/~mundie/CyberDewey/Organizing_computers.html
[MW93]
Manber, U., Wu, S. (1993). GLIMPSE: A Tool to Search Through Entire File
Systems, University of Arizona, Department of Computer Science.
http://glimpse.cs.arizona.edu/glimpse/glimpse.ps.Z
[Neu98]
Neussl, D. (1998). Ergänzungen des Harvest-Suchsystems im Hinblick auf Fehlertoleranz, Konfigurierbarkeit, Keyword-Relevanz und Ranking, Diplomarbeit
am Institut für Informationsverarbeitung und Computergestützte neue Medien (IICM), Technische Universität Graz, Austria.
http://www.iicm.edu/thesis/dneussl
[Not99]
Notes, G.R. (1999). Search Engine Showdown.
http://www.notess.com/search/defs/
http://www.notess.com/search/features/
http://www.notess.com/search/dir/dmoz/index.shtml
[ODP99]
Open Directory Project (1999). About the Open Directory Project.
http://dmoz.org/about.html
[Oeh96]
Oehler, A. (1996). Browsingdienste im Internet, Freie Universität Berlin, Fachbereich Philosophie und Sozialwissenschaften I, Arbeitsbereich Informationswissenschaft.
http://userpage.fu-berlin.de/~angela/bond/browsing.htm
[OLM98]
O’Neill, E.T., Lavoie, B.F., McClain, P.D. (1998). An Analysis of Metadata
Usage on the Web, Annual Review of OCLC Research, Web Characterization
Project.
http://www.oclc.org/oclc/research/publications/review98/oneill_
etal/metadata.htm
[Ott97]
Otto, M. (1997). Suchstrategien im Internet - Search Engines,Themenkataloge,
Besprechungsdienste.
International Thomson Publishing, ISBN 3-8266-0323-0.
144
[PDA91]
Prieto-Dias, R., Arango, G. (1991). Domain Analysis and Software Systems Modeling, Los Alamitos, California, IEEE Computer Society Press,
ISBN 0-81868996-X.
[RFC2279] Yergeau, F. (1998). Request for Comments 2279: UTF-8, a transformation format of ISO 10646, Network Working Group.
[SBS98]
Sander-Beuermann, W., Schomburg, M. (1998). Internet Information Retrieval
- The Further Development of Meta-Searchengine Technology, Proceedings of
the Internet Summit, Internet Society, July 22-24, Genf. Institute for Computer
Networks and Distributed Systems, University of Hannover, Germany.
http://www.uni-hannover.de/inet98/paper.html
[SMA99]
Smart (1999). Smart-Tutorial und Dokumentation, Cornell University, Computer
Science Department, New York, USA.
http://broncho.ct.monash.edu.au/~maria/Smart/hands-on-tekst.html
ftp://ftp.cs.cornell.edu/pub/smart.html
[Sul99]
Sullivan, D. (1999). Search Engine Watch.
http://www.searchenginewatch.com/facts/glossary.html
[SWI99]
Swish-e (1999). Produktbeschreibung SWISH-E, University of California, Berkeley, USA.
[TSV97]
Thompson, R., Shafer, K., Vizine-Goetz, D. (1997). Evaluating Dewey Concepts
as a Knowledge Base for Automatic Subject Assignment, OCLC Online Computer Library Center.
http://orc.rsch.oclc.org:6109/eval_dc.html
[UDC99]
Universal Decimal Classification (1999). UDC in Brief, UDC Consortium, Directory of Networked Resources.
http://www.niss.ac.uk/resource-description/udcbrief.html
http://www.udcc.org/about.htm
[VGO96]
Vizine-Goetz, D. (1996). Implications for Classifying and Document[-like Object]
Retrieval, Knowledge organization and change: proceedings of the 4th international ISKO conference, 15-18 July 1996, Washington, D.C., Rebecca Green, ed.,
INDEKS Verlag.
http://orc.rsch.oclc.org:6109/dvgisko.htm
[VGU96]
Vizine-Goetz, D. (1996). Using Library Classification Schemes for Internet Resources. OCLC Internet Cataloging Project Colloquium, Position Paper.
http://www.oclc.org/oclc/man/colloq/v-g.htm
[VTY99]
Verity (1999). Produktbeschreibung Verity Developers Kit und K2 Toolkit, Verity,
Inc., Sunnyvale, California, USA.
http://www.verity.com/products/devokit/index.html
http://www.verity.com/products/k2toolkit/index.html
145
[Wei2000]
Weitzer, J. (2000). Verwendung von Qualitäts-Metadaten zur verbesserten Wissensauffindung und Testimplementierung im xFIND System, Diplomarbeit am
Institut für Informationsverarbeitung und Computergestützte neue Medien
(IICM), Technische Universität Graz, Austria.
http://www2.iicm.edu/cguetl/education/thesis/jweitzer
[WMB94]
Witten, I.H., Moffat, A., Bell, T.C. (1994). Managing Gigabytes: Compressing and Indexing Documents and Pictures, Van Nostrand Reinhold,
ISBN 0-442-01863-0.
[ZEB99]
Zebra (1999). Zebra Server - Administrator’s Guide and Reference, Index Data,
Kopenhagen, Dänemark.
146

PDF-Version

Transcrição

Documentos relacionados

PDF / 33 kB - Forschungszentrum Jülich

Vorsorge + Anlage > Analystenmeinung HANDELSBLATT, Freitag

RE/MAX Broker/Owner Meeting in Hamburg mit

PG-Antrag - Lehrstuhl 5 für Programmiersysteme

Marketing Guide

Eklat im Leinwiger Rat - Leuphana Universität Lüneburg

Haus / Villa in Rijeka, Kvarner, Kroatien Ref : 3939/30

Aktueller Kursflyer - Food

Deanonymisierung von Profilen sozialer Netzwerke unter Nutzung

Gottes Wirken in meinem Leben