Word - Das IICM - Graz University of Technology

Wissensauffindung in verteilten Systemen
Lokale Suchmaschine und Informationsaufbereitung für externe
Suchdienste
Diplomarbeit
an der
Technischen Universität Graz
vorgelegt von
Bernhard Knögler
Institut für Informationsverarbeitung und computergestützte neue Medien IICM
Technische Universität Graz
A-8010 Graz
Österreich
September 1999
© Copyright 1999, Bernhard Knögler
Begutachter: o.Univ.-Prof. Dr. Dr.h.c. Hermann Maurer
Betreuer: Dipl.-Ing. Christian Gütl
Kurzfassung
Das Internet repräsentiert heute, seit der Entwicklung einfach zu bedienender Zugriffswerkzeuge, die weltweit größte und am schnellsten wachsende unstrukturierte Wissensund Informationsdatenbank. Gerade diese Eigenschaften erschweren das Auffinden von
relevanten Informationen und verhindern die effiziente Nutzung des World Wide Web.
Aus der Notwendigkeit heraus, den Benutzern des Web die Möglichkeit zu geben,
Informationen zu einem bestimmten Thema zu finden, entstanden in den letzten Jahren
mehrere Suchdienste, die jeder für sich mehr oder weniger große Teile des World Wide
Web indizieren und eine Suche ermöglichen.
Mit den gegenwärtigen Methoden der Informationssammlung dieser Suchdienste und
der steigenden Anzahl von Dokumenten und aktiven Suchmaschinen wird die dadurch
verursachte Netz- und Serverbelastung künftig andere Anwendungen weitgehend
beeinträchtigen. In der vorliegenden Arbeit werden daher neue Forschungsansätze wie
lokale Indizes und hierarchische Suchdienste näher untersucht. Dabei werden gegenwärtige
Konzepte lokaler Informationssammlung und Konzepte zur Bereitstellung bereits
gesammelter Daten für externe, übergeordnete Suchdienste behandelt.
Die Ergebnisse des Untersuchungsbereiches führen in weiterer Folge zur Entwicklung
eines leicht portierbaren lokalen Suchdienstes, der die Bereitstellung von Informationen –
Inhalte sowie Metadaten – für externe Suchdienste ermöglicht. Zusätzlich werden die
Informationen über ein Web-Suchinterface zur Verfügung gestellt, wobei ein Index mit
einem Ranking- und Relevanzsystem und automatischer Schlüsselwortbildung aus den
Dokumenten aufgebaut wird. Die lokale Suchmaschine sowie die Schnittstellen werden
detailliert dokumentiert und zukünftige Erweiterungsmöglichkeiten aufgezeigt.
Abstract
Today, since the development of simple-to-use access tools, the Internet represents the
world's largest and fastest growing unstructured knowledge and information database.
However, exactly this very characteristic makes the discovery of relevant information
difficult and prevents efficient use of the World Wide Web. In recent years search engines
have been developed to give users the possibility to search and find certain information on
the Web. All these search services gather independently information from more or less
large parts of the Internet.
Present day methods of information collection and the ever-growing quantity of
documents and active search engines will increasingly affect future internet applications
because of repeated net- and server-load caused by information gathering. In this thesis
new approaches such as local gathering and hierarchical search services will be analysed.
Furthermore, current concepts of local search engines and concepts of providing already
gathered information for external, hierarchically higher levels of search services are
discussed.
The results of this analysis lead to the development of an easily portable local search
engine which enables providing information – contents as well as meta information – for
external search services. Additionally, the gathered information will be made available
through a Web search interface. An index with a ranking and relevance system and
automatic keyword extraction from the documents will be created. The local search engine
and the interfaces are documented in detail and future ways of extending the engine will be
discussed.
Danksagung
An dieser Stelle möchte ich mich bei all jenen Bedanken, die mir beim Erstellen dieser
Arbeit mit Trost und Hilfe zur Seite standen.
Allen voran o.Univ.-Prof. Dr. Dr. h.c. Hermann Maurer, Leiter des Instituts für
Informationsverarbeitung und computergestützte neue Medien (IICM) und Begutachter
dieser Arbeit sowie meinem Betreuer Dipl.-Ing. Christian Gütl, der mir durch wiederholte
Besprechungen und oftmaliges Korrekturlesen geholfen hat.
Ganz besonderer Dank gilt meinen Eltern Gerda und Kurt Knögler, die mein Studium
erst ermöglichten, mich all die Jahre hinweg unterstützten und mit tatkräftiger Hilfe immer
schnell bei der Stelle waren.
Ich versichere hiermit, diese Arbeit selbständig verfaßt, andere als die angegebenen
Quellen und Hilfsmittel nicht benutzt und mich auch sonst keiner unerlaubten Hilfsmittel
bedient zu haben.
Inhaltsverzeichnis
Kapitel 1
1.1
1.2
Motivation............................................................................................................................ 1
Strukturierung der Arbeit ..................................................................................................... 3
Teil I
Kapitel 2
2.1
2.2
2.3
2.4
3.3
3.4
3.5
Suchdienste ................................................................................................. 6
Lokale und verteilte Aufbereitung ......................................................... 19
Grundlagen ........................................................................................................................ 19
Vorteile der verteilten Informationsaufbereitung .............................................................. 20
3.2.1 Vollständigkeit und Aktualität ..............................................................................20
3.2.2 Netz- und Serverbelastung ....................................................................................20
3.2.3 Gliederung des Informationsraumes .....................................................................21
3.2.4 Zusatzinformationen .............................................................................................21
Nachteile der verteilten Informationsaufbereitung ............................................................ 22
Lokale Informationsaufbereitung und Suchdienste ........................................................... 22
3.4.1 Harvest ..................................................................................................................23
3.4.2 Hyperwave ............................................................................................................24
Zusammenfassung ............................................................................................................. 26
Kapitel 4
4.1
Untersuchungsbereich................................................................5
Grundlagen .......................................................................................................................... 6
2.1.1 Informationsauffindung und Aufbereitung .............................................................7
2.1.2 Bereitstellen der Informationen ..............................................................................9
Einteilung der Suchdienste ................................................................................................ 11
Schwachpunkte gängiger Suchdienste ............................................................................... 12
2.3.1 Vollständigkeit, Aktualität und Linkkonsistenz....................................................12
2.3.2 Netz- und Serverbelastung ....................................................................................13
2.3.3 Qualität und Zuverlässigkeit .................................................................................14
2.3.4 Zusatzinformationen .............................................................................................16
2.3.5 Relevanz der Informationen ..................................................................................17
Zusammenfassung ............................................................................................................. 18
Kapitel 3
3.1
3.2
Einleitung ................................................................................................... 1
Formate und Metadaten ......................................................................... 27
HTML – Hypertext Markup Language .............................................................................. 28
4.1.1 Kurzbeschreibung der Syntax ...............................................................................29
4.1.2 Meta-Tags in HTML-Dokumenten .......................................................................31
4.2
4.3
4.4
4.5
Standardisierte Metadaten.................................................................................................. 39
4.2.1 DC - Dublin Core Metadata Element Set..............................................................39
4.2.2 LOM – Learning Object Metadata ........................................................................43
4.2.3 PICS – Platform for Internet Content Selection....................................................44
Metadatenformate zum Datenaustausch ............................................................................ 46
4.3.1 SOIF – Harvest Summary Object Interchange Format ........................................46
4.3.2 XML – Extensible Markup Language ..................................................................49
4.3.3 MCF – Meta Content Framework .........................................................................55
4.3.4 RDF – Resource Description Framework .............................................................56
Ausblick ............................................................................................................................. 63
Zusammenfassung ............................................................................................................. 64
Teil II
Kapitel 5
5.1
5.2
6.4
6.5
6.6
6.7
6.8
7.2
7.3
7.4
7.5
7.6
7.7
Der Gatherer ............................................................................................ 71
Funktionsbeschreibung ...................................................................................................... 72
Beschreibung des Gathervorganges ................................................................................... 74
Konfiguration des Gatherers .............................................................................................. 75
6.3.1 Sektion Config ......................................................................................................76
6.3.2 Sektion Gather ......................................................................................................78
6.3.3 Sektion Info...........................................................................................................82
6.3.4 Sektion Disallow ...................................................................................................82
Zusatzinformationen .......................................................................................................... 83
Meta-Tag Robots ............................................................................................................... 83
Virtuelle Hosts ................................................................................................................... 85
Beispiel einer Konfigurationsdatei .................................................................................... 85
Zusammenfassung ............................................................................................................. 87
Kapitel 7
7.1
Softwaredokumentation .......................................................................... 66
Gesamtkonzept .................................................................................................................. 66
Zusammenfassung ............................................................................................................. 70
Kapitel 6
6.1
6.2
6.3
Gestaltungsbereich....................................................................65
Fehlertoleranter HTML-Konverter ....................................................... 88
Konfiguration des Konverters ............................................................................................ 89
7.1.1 Sektion ConvertTab ..............................................................................................89
7.1.2 Sektion Separator ..................................................................................................93
7.1.3 Weitere Konfiguration ..........................................................................................94
Detailaspekte des Konverters............................................................................................. 94
Performance ..................................................................................................................... 100
Unterschiede Windows/UNIX ......................................................................................... 101
Erweiterungsmöglichkeiten ............................................................................................. 101
Vollständige Konfigurationsdatei .................................................................................... 102
Zusammenfassung ........................................................................................................... 104
Kapitel 8
Das Gatherer-Collector-Interface ........................................................ 105
8.1
8.2
8.3
8.4
8.5
Funktionsbeschreibung .................................................................................................... 106
Protokollbeschreibung ..................................................................................................... 108
8.2.1 Die Willkommens-Meldung ...............................................................................108
8.2.2 Das HELLO Kommando ....................................................................................109
8.2.3 SEND-UPDATE und SEND-INFO-UPDATE ...................................................109
8.2.4 Das SET Kommando ..........................................................................................110
8.2.5 Das SEND-OBJECT Kommando .......................................................................111
8.2.6 Das INFO Kommando ........................................................................................111
8.2.7 Das HELP Kommando .......................................................................................111
8.2.8 QUIT, EXIT und BYE ........................................................................................111
Antworten und Fehlermeldungen des Interfaces ............................................................. 112
Beispiel für einen Datenaustausch ................................................................................... 114
Zusammenfassung ........................................................................................................... 115
Kapitel 9
9.1
9.2
9.3
9.4
9.5
Der Suchdienst ....................................................................................... 116
Suchabfrage ..................................................................................................................... 117
9.1.1 Suchbereich .........................................................................................................118
9.1.2 Relevanz..............................................................................................................119
9.1.3 Ausgabemöglichkeiten ........................................................................................119
9.1.4 Stoppwörter .........................................................................................................120
Konfiguration des Suchservlets ....................................................................................... 121
Implementierung .............................................................................................................. 122
Einbindung des Servlets am Beispiel des Webservers Jigsaw ......................................... 126
Zusammenfassung ........................................................................................................... 129
Kapitel 10
Datenbank – Anbindung und Aufbau ................................................. 130
10.1 Zielsetzung ....................................................................................................................... 130
10.2 Datenbankdesign.............................................................................................................. 132
10.2.1 Theorie relationaler Datenbanken .......................................................................132
10.2.2 Relationen der Dokumentenverwaltung..............................................................133
10.2.3 Dokument- und Informationsspeicherung ..........................................................136
10.3 Arbeitsweise .................................................................................................................... 137
10.3.1 Einfügen ..............................................................................................................137
10.3.2 Löschen ...............................................................................................................138
10.4 Suchabfragen ................................................................................................................... 139
10.4.1 Suchabfrage mit einem Wort ..............................................................................140
10.4.2 Boolesche Operatoren .........................................................................................141
10.4.3 Eingeschränkte Suche .........................................................................................143
10.4.4 Gewichtung gefundener Dokumente ..................................................................144
10.5 Erweiterung der Datenbank um neue Attribute ............................................................... 146
10.6 Konfiguration der Datenbank .......................................................................................... 147
10.6.1 Sektion Config ....................................................................................................147
10.6.2 WordFilter ...........................................................................................................150
10.6.3 Rating ..................................................................................................................150
10.6.4 Stoppwörter .........................................................................................................151
10.6.5 Vollständige Konfigurationsdatei .......................................................................152
10.7 Implementierung .............................................................................................................. 153
10.8 Zusammenfassung ........................................................................................................... 156
Kapitel 11
Zusätzliche Module................................................................................ 157
11.1 ConfigReader ................................................................................................................... 157
11.1.1 Implementierung .................................................................................................158
11.1.2 Programmierbeispiel ...........................................................................................159
11.2 Log und LogListener ....................................................................................................... 160
11.2.1 Konfiguration ......................................................................................................160
11.2.2 Implementierung .................................................................................................161
11.2.3 Programmierbeispiel ...........................................................................................162
11.3 StringFilter ....................................................................................................................... 163
11.4 StrTokenizer .................................................................................................................... 165
11.5 MD5 und MD5Builder..................................................................................................... 166
11.6 ListenPort......................................................................................................................... 167
11.7 SendPassword .................................................................................................................. 168
11.8 TimeDiff .......................................................................................................................... 169
11.9 Common .......................................................................................................................... 170
11.10 AVTable .......................................................................................................................... 171
11.10.1 Konfiguration ......................................................................................................171
11.10.2 Implementierung .................................................................................................173
11.11 AVTableFilter .................................................................................................................. 174
11.12 AVTableAnalyzer ............................................................................................................ 178
11.12.1 Konfiguration ......................................................................................................178
11.12.2 Implementierung .................................................................................................179
11.13 AVTableConverter .......................................................................................................... 181
11.14 Zusammenfassung ........................................................................................................... 182
Kapitel 12
Ausblick .................................................................................................. 183
Kapitel 13
Zusammenfassung ................................................................................. 185
Anhang 1...................................................................................................187
Anhang 2...................................................................................................201
Kapitel 1
Einleitung
1.1 Motivation
Seit der Entwicklung einfach zu bedienender Zugriffswerkzeuge wie Mosaic, Netscape
Navigator oder dem Internet Explorer hat sich das World Wide Web nahezu explosionsartig verbreitet. Das Informationsangebot ist in kürzester Zeit unüberschaubar gewachsen,
so daß die Suche in diesem Informationsraum die heute beinahe wichtigste, aber auch die
problematischste Anwendung des Internet geworden ist. Um dies zu Unterstreichen soll
hier die Studie von SQRiBE Technologies Corp., Kalifornien, erwähnt werden. Durch
ineffiziente Suche in Datennetzen verliert Europas Wirtschaft jährlich mehrere Milliarden
Schilling, was die Notwendigkeit der Entwicklung effizienterer Suchwerkzeuge
hervorhebt. [Hor1998]
Im folgenden wird eine kurze Einführung über die Entstehung des Internet und
insbesondere des World Wide Web gegeben, um damit die enorme Geschwindigkeit der
Entwicklung zu verdeutlichen, welche im weiteren zur Entwicklung von Suchdiensten
führte.
Das Internet
Als die Advanced Research Projects Agency1 1969 ein Projekt aus der Taufe hob, das
ein experimentelles paketvermitteltes Netzwerk implementieren sollte, da ahnte noch
niemand, daß genau dieses ARPANET das erste kleine Stückchen Straße für den erst
Jahrzehnte später entstehenden "Information Superhighway" war. Das Projekt war
hauptsächlich dafür ausgelegt, wichtige militärische Daten besser schützen zu können,
indem man die gleichen Daten auf mehreren, weit entfernten Rechnern ablegt und bei
neuen oder geänderten Daten allen angeschlossenen Rechner binnen kürzester Zeit den
aktuellen Datenstand über mehrere unabhängige Wege zukommen lassen zu können.
[EH1996]
Das Prinzip der vernetzten Rechner war aber nicht nur für militärische Zwecke
interessant. Man erkannte schnell, daß auch der akademische Betrieb vom ARPANET
1
heute Defense Advanced Research Projects Agency, DARPA, http://www.arpa.mil
KAPITEL 1 - EINLEITUNG
2
profitieren würde. Der Anschluß der akademischen Welt ans Netz erforderte eine
Trennung zwischen dem militärischen und dem zivilen Teil. So kam es, daß Anfang der
80er Jahre ein neues militärisches Datennetz, das Milnet, vom ARPANET abgekoppelt
wurde. Das ARPANET selbst wurde dem wissenschaftlichen Betrieb überlassen.
[Münz1998]
Im zivilen Teil des Netzes nahm die Anzahl der angeschlossenen Rechner im Laufe der
80er Jahre sprunghaft zu. Eine wichtige Rolle spielte dabei die amerikanische National
Science Foundation2. Diese Organisation schaffte ein Leitungs-Verbundsystem, das alle
bedeutenden wissenschaftlichen Rechenzentren des Landes miteinander verband. Einzelne
Universitätsrechner oder kleinere Rechnernetze konnten sich mit einem Rechenzentrum
verbinden und darüber in andere Netze gelangen. So entstand buchstäblich ein Netz der
Netze. Alsbald bürgerte sich auch der Name "Internet" dafür ein. Ein weiterer wichtiger
Schritt war auch die Vereinheitlichung des Datenübertragungsprotokolls. Ab 1983 wurde
ausschließlich TCP/IP3 als Übertragungsprotokoll verwendet. [Münz1998]
Doch erst mit der Entwicklung eines neuen Dienstes, des World Wide Web, hat sich das
Interesse am Internet von der wissenschaftlichen und militärischen Nutzung hin zu einer
zunehmenden Kommerzialisierung gewandelt und die Öffentlichkeit begann, auf das neue
Medium aufmerksam zu werden. [Münz1998]
Das World Wide Web
Die Geschichte des World Wide Web (WWW oder auch W3) begann um 1990 in Genf.
Tim Berners-Lee, britischer Informatiker am Genfer Hochenergieforschungszentrum
CERN4, startete zusammen mit einigen Kollegen eine Initiative, um das Internet für einen
neuartigen Informationsaustausch zwischen Wissenschaftern zu nutzen. Es ging darum,
wissenschaftliche Dokumente online sichtbar zu machen, wobei einfache Textformatierung
und das Einbinden von Grafik möglich sein sollte. Genau diese Technik ist die Grundlage
für das gesamte heutige World Wide Web mit seiner unüberschaubaren Anzahl an
Dokumenten. Das Internet repräsentiert heute, seit der Entwicklung einfach zu bedienender
Zugriffswerkzeuge, die weltweit größte und am schnellsten wachsende unstrukturierte
Wissens- und Informationsdatenbank. Die effektive Nutzung dieser Informationen erwies
sich im Laufe der Zeit als beinahe unmöglich und führte in weiterer Folge zur Entwicklung
von Suchdiensten, also Werkzeugen zum Auffinden von Dokumenten anhand bestimmter
Begriffe. [BCL+1994]
Suchdienste
Als die ersten Suchdienste 1994/95 aufgebaut wurden [SoMa1998], reagierten sie auf
folgendes offensichtliches Problem: die Anzahl der im Netz verfügbaren Informationen
und Texte hatte in exponentiellem Wachstum zugenommen (zur Zeit wird die Anzahl der
öffentlich indizierbaren Server auf 3 Millionen und die Anzahl der Dokumente auf diesen
Servern auf etwa 800 Millionen geschätzt [LG1999]) und es war in wenigen Jahren eine
riesige, den Globus umspannende Bibliothek entstanden; eine Bibliothek allerdings – man
denke sich dergleichen außerhalb der virtuellen Sphäre – ohne Katalog und ohne zentrale
2
National Science Foundation, NSF, http://www.nsf.gov
3
Transmission Control Protocol / Internet Protocol
4
Conseil Europénne pour la Recherche Nucléaire (dt. Europäische Organisation für
Kernforschung)
KAPITEL 1 - EINLEITUNG
3
Beschaffung, mit willkürlich gewählten Signaturen und ohne jede Möglichkeit, beim
Auskunftspersonal Hilfe zu finden.
Heute verfügbare Suchverfahren und die Aufbereitung der Informationen durchsuchter
Dokumente stellen in Teilbereichen hilfreiche Werkzeuge zur Verfügung. Doch mit den
gegenwärtigen Methoden und der Zunahme von Dokumenten und Suchmaschinen wird
allerdings die dadurch verursachte Netz- und Serverbelastung künftig andere Anwendungen weitgehend beeinträchtigen. Ein weiteres Problem ergibt sich durch das Wachstum
und die enorme Dynamik des Web, so daß auch größere Suchdienste immer nur einen
Bruchteil aller Dokumente erfassen können. Die Dynamik äußert sich durch einen
kontinuierlichen Wandel der Dokumente und ihrer Inhalte, durchschnittlich soll sich ein
Dokument alle 75 Tage ändern. [Bra1997]
1.2 Strukturierung der Arbeit
Aus den in Abschnitt 1.1 genannten Gründen es notwendig, neue Wege in der Auffindung und Bereitstellung von Informationen zu entwickeln und auf ihre Verwendungsmöglichkeiten hin zu untersuchen. In dieser Arbeit wird im Untersuchungsbereich (siehe
Teil I) nach einer einführenden Begriffsbestimmung und einem Überblick über gängige
Suchdienste und Systeme zur Informationsauffindung vor allem auf die Schwachpunkte
dieser Suchdienste näher eingegangen (siehe auch Kapitel 2).
Die Untersuchungen in Kapitel 3 zeigen, daß sich die meisten dieser Schwachpunkte
durch das Konzept lokaler und verteilter Informationsaufbereitung und die Eingliederung
von lokalen Modulen in hierarchische Suchstrukturen vermeiden bzw. verbessern lassen.
Vor- und Nachteile gegenüber herkömmlichen Suchmaschinen werden hier näher erläutert.
Metainformationen, also Informationen über Dokumente oder andere Objekte, werden
für Suchdienste immer wichtiger, um relevante Ergebnisse liefern zu können. Oft wird es
erst dadurch möglich, den korrekten Inhalt und Themenbezug eines Dokumentes ermitteln
zu können. Die Einbettung von Metainformationen in HTML-Dokumente wird im
Abschnitt 4.1 genauer erläutert, damit die im Gestaltungsbereich entwickelten Module für
die Extraktion und Verwendung von Metainformationen konfiguriert werden können.
Es gibt mehrere Initiativen, die Vorschläge für Metainformationen über beliebige
Objekte beschreiben, wobei heute vor allem Dublin Core oder auch LOM (siehe Abschnitt
4.2) verwendet werden. Zur Weitergabe von Daten über Dokumente beispielsweise von
Suchdienst zu Suchdienst ist es notwendig, diese in einheitlichen Formaten zu übertragen.
Dabei gibt es bereits etablierte Standardformate wie z.B. SOIF. Auf diese und auf sich
gerade in Entwicklung befindliche Formate geht Abschnitt 4.3 näher ein. Es bietet eine
Zusammenfassung von Formaten zur Weitergabe von Metainformationen wie XML, MCF
und RDF.
Die Erkenntnisse des Untersuchungsbereiches führen im Gestaltungsbereich (Teil II) zur
Entwicklung eines leicht portierbaren lokalen Suchdienstes, wobei Kapitel 5 eine
Übersicht der implementierten Module gibt. Der Informationssammler5 (siehe auch Kapitel
6) trägt Informationen – Inhalten sowie Metadaten – über Dokumente zusammen, die dann
mit einem Interface für weitere externe Suchdienste bereit gestellt werden (siehe auch
5
hier im weiteren engl. Gatherer genannt
KAPITEL 1 - EINLEITUNG
4
Kapitel 8). Die notwendigen Informationen werden von einem fehlertoleranten und
konfigurierbaren HTML-Konverter extrahiert (siehe auch Kapitel 7), wobei die
Erweiterbarkeit anhand eines Moduls zur automatischen Generation von Zusammenfassungen demonstriert wird. Zusätzlich werden die extrahierten Informationen über ein WebSuchinterface zur Verfügung gestellt (siehe auch Kapitel 9), die Indizierung erfolgt mit
variablem Ranking- und Relevanzsystem und automatischer Schlüsselwortbildung aus den
Dokumenten. Die indizierten Begriffe werden in einer relationalen Datenbank gespeichert
(siehe Kapitel 10). Im Kapitel 11 werden weitere Module, die für diese Arbeit implementiert wurden, beschrieben.
Im Ausblick werden schließlich weiterführende Ergänzungen und Einsatzmöglichkeiten
des Systems erörtert. So läßt sich zum Beispiel eine Modul zur Erkennung der in einem
Dokument verwendeten Sprache in den HTML-Konverter integrieren.
Teil I
Untersuchungsbereich
Kapitel 2
Suchdienste
Eine effektive Nutzung des World Wide Web wäre wegen der enormen Anzahl an
Dokumenten und deren kontinuierlicher Veränderung und Erweiterung ohne die Hilfe von
Suchdiensten nicht mehr möglich. Im folgenden wird versucht, einen Überblick über
gängige Ansätze und Systeme zur Wissensauffindung zu geben. Danach werden
Schwachpunkte gängiger Verfahren untersucht.
2.1 Grundlagen
Die Aufgabe der Suchdienste ist es, aus den hunderten Millionen Web-Dokumenten und
Newsgroup-Beiträgen Verweise zu den gewünschten Themen bereitzustellen. Das Internet
stellt sich als ein dynamischer Informationsraum dar, der durch ständige Änderungen bzw.
durch exponentielles Anwachsen des Informationsinhalts1 und durch eine völlige
unstrukturierte Form gekennzeichnet ist. Dabei müssen sich die Suchdienste der
Anforderung stellen, die jeweiligen Veränderungen von bestehenden Dokumenten zu
erfassen und neue Dokumente in ihren Suchindex aufzunehmen. Eine vollständige und
möglichst aktuelle Erfassung von Dokumenten wird immer nur auf einen Teilbereich des
Internet beschränkt bleiben können.
Weiters ist eine geeignete Datenaufbereitung der durchforsteten Dokumente und die
Bereitstellung eines Userinterfaces notwendig, damit die angebotenen Informationen von
den Benutzern auch gefunden werden können. Die notwendigen Komponenten eines
Suchdienstes lassen sich in drei Funktionseinheiten – Informationsauffindung (also
Durchforsten der Dokumentenstrukturen), Aufbereitung und Bereitstellung – unterteilen,
die im nachfolgenden beschrieben werden.
1
Bis 1998 verdoppelte sich die Anzahl der Dokumente alle 8 Monate [Alx1998], wobei
sich dieser Trend weiter fortsetzt. Anfang 1998 betrug die Anzahl der Dokumente im
Web 320 Millionen [LG1998] und stieg bis Juni 1999 auf über 800 Millionen an
[LG1999].
KAPITEL 2 - SUCHDIENSTE
2.1.1
7
Informationsauffindung und Aufbereitung
Bevor der Anwender die Möglichkeit der Suche hat, müssen Informationen über die
Dokumente erst gesammelt werden. Es gibt verschiedene Möglichkeiten, wie Dokumente
im World Wide Web lokalisiert werden, wobei die Grenzen durchaus fließend ineinander
übergehen und Kombinationen möglich sind. Eine Sonderstellung nehmen Informationssysteme ein, die ein integriertes Suchsystem besitzen. Ein Beispiel dafür ist das
Hyperwave-System (siehe auch Kapitel 3.4.2). Hierbei werden die Dokumente bereits
beim Einfügen indiziert, so daß die Suchinformationen immer auf dem aktuellsten Stand
sind.
Vollautomatische Auffindung
Bei dieser Methode der Informationssammlung verfolgt ein Programm ähnlich wie ein
Benutzer Hyperlinks auf Web-Seiten bzw. Verzeichnisstrukturen auf FTP-Servern. Diese
sogenannten Robots oder Spider verarbeiten vollautomatisch alle gefundenen Dokumente
und versuchen, relevante Informationen wie etwa Namen von Autoren, Titel und
Schlüsselwörter zu extrahieren. [WRD1998a]
Bei diesen Spidern handelt es sich um Programme, die das Internet kontinuierlich
durchforsten. Sie starten auf der Homepage eines bestimmten Servers, verfolgen
nacheinander alle Links und sammeln Informationen über besuchte Objekte. Auf diese
Weise bewegen sich Spider seitenweise über den Server. Trifft ein Spider auf eine neue
oder geänderte Seite, wird aus dieser eine Liste mit Schlüsselwörtern generiert und die
Datenbank der jeweiligen Suchmaschine entsprechend aktualisiert. Datensätze werden
entfernt falls die Seiten mittlerweile gelöscht wurden. Die einzige Aktion, die vom
Betreiber des Servers manuell vorgenommen werden muß, ist die einmalige Anmeldung
der Domäne. [WRD1998a]
Es gibt verschiedene Ansätze, wie relevante Informationen aus den Dokumenten
extrahiert werden. Schlüsselwörter können etwa durch einen Algorithmus festgelegt
werden, der sich an der relativen Häufigkeitsverteilung orientiert, wobei Wörter mit
geringer relativer Häufigkeit das Dokument beschreiben könnten. Wörter mit gewissen
Formatierungen (beispielsweise Überschriften oder Fettdruck) bieten ebenfalls
Ansatzpunkte, relevante Beschreibungen zu extrahieren. Auch die Verarbeitung von
sogenannten Meta-Tags im Dokument kann zusätzliche Informationen bringen (siehe auch
Kapitel 4.1.2 – Meta-Tags). Eine weitere Möglichkeit besteht darin, die gesamte VolltextInformation zu verarbeiten. In der vorliegenden Diplomarbeit ist die Extraktion von
Wörtern bzw. Dokumentteilen, die durch bestimmte Formatierungen gekennzeichnet sind,
implementiert. Zusätzlich können alle Metainformationen miteinbezogen werden.
Die durch Spider gewonnenen Informationen der jeweiligen Dokumente benötigen eine
Nachbearbeitung, vor allem um die Größe des Index zu reduzieren und so die Suche
effizienter durchführen zu können. Das Ergebnis der Reduktionen wird in einer Datenbank
indiziert und steht dann für eine Suchanfrage zur Verfügung. Einige Möglichkeiten der
Reduktion sind [Sul1999b]:
 Entfernen von zu kurzen oder zu langen Wörtern und Löschen von Duplikaten.
 Umwandeln aller Wörter in Kleinschreibung.
KAPITEL 2 - SUCHDIENSTE
8
 Reduzieren erkannter Wörter auf ihren Wortstamm. Bei dieser Methode, genannt
Stemming, werden die Endungen von Wörtern entfernt, Einzahl bzw. Mehrzahl
angepaßt und oft auch der Tempus korrigiert, wodurch eine Normalisierung der
Begriffe erreicht wird. Stemming2 funktioniert vor allem mit der englischen Sprache
und es wird sichergestellt, daß etwa bei einer Suche nach 'walk' Wörter wie 'walking',
'walked' und 'walks' gefunden werden. Damit die Suche funktioniert, wird Stemming
auch auf Wörter der Suchabfrage angewandt und dann mit der Datenbankabfrage
begonnen.
 Bedeutungssubstitution von Wörtern mit gleicher oder ähnlicher Bedeutung. Durch
Substitution bekannter Wörter auf ein Grundwort läßt sich nicht nur die Indexgröße
reduzieren, sondern auch die Erfolgsquote einer Suche erhöhen. So ist sichergestellt,
daß bei einer Suche nach 'Fell' auch Dokumente mit 'Pelz' oder 'Balg' gefunden werden.
Diese Umwandlung erfordert allerdings umfangreiches Sprachwissen des Suchdienstes,
wobei auch auf die Bedeutung der Wörter im Satzzusammenhang Rücksicht genommen
werden muß. Wie bei dem Stemming wird auch die Substitution zuerst auf die Wörter
der Suchabfrage angewendet. Diesen Mechanismus, der im Kapitel 2.3.3 noch kurz
erläutert wird, verwenden beispielsweise Excite3 oder Verity4.
 Entfernen bestimmter Wörter wie Artikel oder unerwünschter Wörter mittels einer
Stoppliste. Die Stoppliste bietet dadurch auch die Möglichkeit einer eingeschränkten
Zensur.
Aktives Anmelden einzelner Seiten
Einige wenige Suchmaschinen setzen überhaupt keine Spider ein. Hier melden die
Benutzer Dokumente beim Suchsystem an, wobei auch zusätzliche Informationen wie
beispielsweise Beschreibungen, Schlüsselwörter und vor allem die zugehörigen Kategorien
angegeben werden können. Die Dokumente werden von Expertenteams beurteilt und in die
Kategorien aufgenommen. Meist wird auch der Inhalt der Dokumente extrahiert und
indiziert. [Koch1996]
Bei diesen Systemen ist der Seitenbestand entsprechend kleiner, das Angebot aber besser
kategorisiert. Einige Suchmaschinen, zum Beispiel Infoseek, erfassen die Daten zwar per
Spider, bieten aber ein zusätzliches, redaktionell betreutes Verzeichnis an.
Redaktionelle Recherche
Die Ergebnisse von meist automatischer Auffindung werden redaktionell bearbeitet und
bieten die Möglichkeit, gute Zusammenfassungen zur Suche anzubieten. Zusätzlich
werden manuelle Suchen zu bestimmten Themenkreisen durchgeführt oder vorangemeldete Dokumente geprüft und in den Suchdienst aufgenommen. Diese Art der Informationsaufbereitung nimmt vor allem im kommerziellen Bereich einen gewissen Stellenwert ein,
da für die so gefundenen Dokumente von den Redaktionsteams meist auch eine Bewertung
vorgenommen worden ist oder unzulängliche Dokumente erst gar nicht in den Suchdienst
übernommen werden. [Koch1996]
2
Stemming ist sprachabhängig, es gibt für jede Sprache Regeln, um ein Wort auf seinen
Stamm zu reduzieren.
3
Excite, http://www.excite.com
4
Verity, http://www.verity.com
KAPITEL 2 - SUCHDIENSTE
9
Die Anbieter von sogenannten "Added-value" Diensten mit Qualitätswertungen bzw.
Reviews und manuell erstellten Inhaltsbeschreibungen werden ständig zahlreicher
(Magellan5, Excite, OCLC's NetFirst6). Es ist allerdings meist schwer, sich einen
generellen Eindruck von der Qualität und Korrektheit dieser Angaben zu machen und sie
mit den automatischen Methoden auf der Grundlage der Originaldokumente zu
vergleichen.
2.1.2 Bereitstellen der Informationen
Neben dem intelligenten Durchforsten, Sammeln und Extrahieren von relevanten
Informationen ist die Schnittstelle zum Anwender eine weitere wichtige Komponente, da
erst so eine Suche im Datenbestand ermöglicht wird. Die zwei wichtigsten Vertreter
werden im folgenden kurz beschrieben.
2.1.2.1
Suchkataloge
Die Suche in Katalogen basiert auf der Navigation in hierarchisch nach Sachgebieten
gegliederten Themen. Auf der obersten Ebene werden beispielsweise Themen wie
Gesundheit, Finanz oder Computer angeboten, die bei einer Suche gewählt werden. Das
Thema wird jetzt stufenweise verfeinert bis letztendlich eine Übersicht der zu diesem
Thema gesuchten Dokumente angezeigt wird. Da mit steigender Anzahl an Kategorien die
Navigation im Katalog erschwert wird, bieten diese Suchdienste meist auch eine Suche
nach Stichworten an. [Koch1996]
Den menschlichen Aufwand, der beim Erstellen eines Kataloges nötig ist, kann man
anhand des Katalogsuchdienstes Open Directory7 (Netscape Communications) abschätzen.
Weltweit sind etwa 13.000 Angestellte und vor allem Freiwillige damit beschäftigt, den
Katalog ständig zu erweitern, wobei die Dokumente anhand von über 100.000 Kategorien
wie Wirtschaft, Wissenschaft und Sport klassifiziert werden. [Gug1999]
2.1.2.2
Suchindizes
Diese Dienste nutzen eine Datenbank, die im Hintergrund die extrahierten Informationen
der einzelnen Dokumente bereit hält. Dies können Schlüsselwörter, Autor, Erstelldatum
aber auch der gesamte Volltext sein (siehe auch Kapitel 2.1.1 – vollautomatische Suche)
[Bag1996]. Der Benutzer des Suchdienstes kann durch Eingabe eines oder mehrerer
Suchbegriffe nach den gewünschten Informationen suchen. Die meisten Dienste sind
mittlerweile dazu übergegangen, dem Benutzer nur ein einfaches Eingabefenster
anzubieten, oft sogar ohne weitere Hilfsinformation auf der gleichen Seite. Erweiterte
Suchfunktionen (wie boolesche Verknüpfungen) oder auch Anzeigealternativen werden
meist auf anderen Seiten angeboten und sind in ihrer Vielfalt eher reduziert. [Koch1996]
5
Magellan, http://www.mckinley.com
6
Online Computer Library Center, OCLC, http://www.oclc.org
7
Open Directory Project, ODP, http://dmoz.org
KAPITEL 2 - SUCHDIENSTE
10
Die grundlegenden Suchfunktionen, die von der Mehrzahl der im World Wide Web zur
Verfügung stehenden Dienste angeboten werden, sind [Sul1999c]:
Boolesche Operatoren
Wörter können mit den Operatoren AND, OR bzw. AND NOT verknüpft werden. So kann
man mit einfachen Befehlen angeben, daß nur Dokumente gesucht werden sollen, die etwa
die Wörter 'Restaurant' AND 'Graz' enthalten. Wichtig ist auch der Operator AND NOT,
mit dem eine Suche eingeschränkt werden kann, indem man bestimmte Wörter angibt, die
nicht in den Dokumenten vorkommen sollen.
Phrasen
Manchmal ist es nötig, nach bestimmten zusammengehörigen Wörtern zu suchen. Ein
Beispiel dafür sind Filmtitel (z.B. "the next generation").
Nähe
Bei manchen Suchmaschinen kann man mit dem Operator NEAR angeben, daß ein
bestimmtes Wort in einem Dokumente in der Nähe eines anderen Wortes vorkommen soll
(z.B. Resetarits NEAR Kabarett).
Wildcards
Mit bestimmten Platzhaltern kann man nach Variationen von Wörtern suchen, wobei
manche Suchdienste automatisch mit Wildcard suchen ('sing*' findet etwa 'singen' oder
'singapur').
Feldindizierung8
Eine weitere Möglichkeit ist es, die Suche auf bestimmte Attribute wie Titel oder
Überschrift einzuschränken.
Eine etwas andere Art der Eingabe für die Suche wird zusätzlich bei AltaVista9
angeboten. Die Technologie ist von Ask Jeeves10 lizensiert und nennt sich Ask AltaVista.
Hier kann der Benutzer Fragen in Umgangssprache stellen, die mit 7 Millionen
Grundfragen (Ende 1998) in einer Datenbank verglichen werden. Als Ergebnis erhält man
wie bei Katalogdiensten von Redakteuren geprüfte Ergebnisse. [Sul1999d]
Das Suchergebnis stellt sich meist als eine nach Relevanzgrad sortierte Trefferliste dar,
zum Teil ergänzt um Bereiche des Originaldokuments oder einer automatisch generierten
Zusammenfassung. Relevanz kann sich dabei beispielsweise auf die Häufigkeit des
Vorkommens der gesuchten Wörter, auf die Position der Wörter oder auf das Vorkommen
in bestimmten Attributen wie Titel, Überschriften oder Schlüsselwörtern im Dokument
beziehen. [Kar1999a]
8
Ort des Vorkommens
9
Altavista, http://www.altavista.com
10
Ask Jeeves for Kids, http://www.ajkids.com
KAPITEL 2 - SUCHDIENSTE
11
2.2 Einteilung der Suchdienste
Die nachfolgende Einteilung orientiert sich an der Arbeit von Koch [Koch1996] und
bietet eine beispielhafte Auswahl aktueller Suchdienste:
Generelle Suchdienste für alle Arten von Web-Ressourcen

Singuläre Suchdienste
 Indexsuchdienste mit Auffindung durch Spider
Volltextindex bzw. reduzierter Volltextindex
AltaVista
http://www.altavista.com
Hotbot
http://www.hotbot.com
Excite
http://www.excite.com
Fast
http://www.alltheweb.com
InfoSeek
http://www.infoseek.com
Harvest
http://harvest.austria.eu.net/Server-in-AT/
Schlüsselwörter und Metadaten
Magellan
http://www.mckinley.com
WWW Worm
http://www.goto.com

Katalogsuchdienste durch aktives Anmelden und Redaktionsteams
Yahoo
http://www.yahoo.com
Open Directory
http://directory.mozilla.org
Dino-Online
http://www.dino-online.de
Web.de
http://web.de
Henkel
http://www.henkel.at/service/ha_www.htm

Metasuchdienste und kombinierte Suchdienste

Metasuchdienst durch simultane Nutzung mehrerer Suchdienste
MetaCrawler
http://www.metacrawler.com
InfoMarket
http://www.infomarket.com
Inference Find
http://www.infind.com

Zusammenfassung mehrerer Katalogsuchdienste
Metaindex Europa http://www.hj.se/hs/bibl/miewww/

Kombination von Index- und Katalogsuchdiensten
Lycos
http://www.lycos.com
Intelligent Agents
Verity
http://www.verity.com

Indizes für bestimmte Arten von Web-Ressourcen und bzw. oder Protokollen





Files, Software (FTP)
Filez
http://www.filez.com
FTP Search
http://ftpsearch.ntnu.no
FTP Search
http://ftp.sunet.se:8000/ftpsearch
OPAC
Online Public Access Catalog, Informationssuche in Bibliotheken
Gopher Informationssystem mit menüartiger Struktur
WAIS
Wide Area Information Servers, Verteilte Informationssuche
Z39.50
ANSI Standard für offene, verteilte Informationssysteme
KAPITEL 2 - SUCHDIENSTE
12
Die hier getroffene Einteilung soll die unterschiedlichen Möglichkeiten beim Aufbau
eines Suchsystems aufzeigen. Jedes Konzept bietet dem Anwender in Teilbereichen
Vorteile, die mehr oder weniger ausgeprägten Schwachstellen gegenüber stehen (siehe
auch Kapitel 2.3).
Die Unterschiede in der Gruppe der singulären Suchdienste sind in vielerlei Hinsicht
erheblich. Zu den Vorteilen der Katalogsuchdienste (siehe auch Abschnitt 2.1.2.1) zählt
vor allem die Auswahl der Dokumente. Autoren, Lektoren oder Benutzer des Systems
entscheiden, ob und in welchem Maß Informationsobjekte relevant sind, ob sie in den
Katalog aufgenommen und welcher Kategorie sie zugeordnet werden. Der Vorteil von
Indexsuchdiensten hingegen liegt in ihrem vergleichsweise hohen Grad an Aktualität und
Vollständigkeit (siehe auch Abschnitt 2.1.2.2). Innerhalb dieser Gruppe exisitieren
Unterschiede auf dem Gebiet der Indizierung (Volltext, Schlüsselwörter, Metadaten) und
dem thematischen und geographischen Deckungsbereich.
Ein spezielle Art der Suchdienste sind die in der Aufstellung erwähnten Metasuchdienste. Diese nutzen bei einer Suchabfrage verschiedene andere Suchdienste und
generieren von deren Ergebnissen Zusammenfassungen, die dann dem Anwender
präsentiert werden. Da die einzelnen Suchdienste oft verschiedene Teile des World Wide
Web absuchen, läßt sich so die Vollständigkeit der Abfrage verbessern. [LG1999]
2.3 Schwachpunkte gängiger Suchdienste
Heutige Suchmaschinen haben bestimmte Nachteile, auf die in diesem Abschnitt näher
eingegangen wird. Dabei wird vor allem die Vollständigkeit und Linkkonsistenz und
anschließend die bei der Indizierung auftretende Server- und Netzbelastung untersucht.
2.3.1 Vollständigkeit, Aktualität und Linkkonsistenz
Für den Benutzer des Wissensspeichers Internet ist es wichtig, daß der Suchdienst die
Dokumente vollständig und aktuell – zumindest in einem geographischen oder
thematischen Teilbereich – zur Verfügung stellt.
Suchdienste streben zumindest teilweise Vollständigkeit an. Da aber selbst die größten
Suchdienste mit einem enormen technischen Aufwand nicht ständig alle neuen Dokumente
erfassen können und die Einstiegspunkte für die weitere Linkverfolgung eine zusätzliche
Rolle spielen, läßt sich folgern, daß Vollständigkeit an zentraler Stelle niemals erreicht
werden kann. Die selben Überlegungen betreffen die Aktualität von bereits indizierten
Dokumenten, deren Inhalte sich verändert haben. Das World Wide Web ändert sich viel zu
schnell, als daß neue Informationen unmittelbar berücksichtigt werden könnten. Frühere
Suchdienste arbeiteten oft mit einem festen Turnus von mehreren Tagen bis Wochen – so
bestand kaum eine Chance, einen eben erschienenen Artikel zu finden. Infoseek und
AltaVista versuchen das Problem zu entschärfen, indem sie ohne feste Intervalle ihre
Spider zur Informationsauffindung starten. Statt dessen werden Seiten, die in der
Vergangenheit bereits häufiger aktualisiert wurden, in kürzeren Intervallen untersucht, also
die Geschwindigkeit der Informationsaktualisierung dynamisch angepaßt. [GAM1998]
[Kar1999b]
KAPITEL 2 - SUCHDIENSTE
13
Ein weiteres Problem sind nicht mehr existierende Dokumente, wobei dann die
Verweise der Suchergebnisse oftmals keine gültige Referenz mehr angeben und die
Linkkonsistenz nicht mehr garantiert ist. Die Anzahl der ungültigen Verweise ist vom
Suchdienst abhängig, und beträgt zwischen 3 und 14%. [LG1999]
Eine vollständige und möglichst aktuelle Erfassung von Dokumenten wird immer auf
einen Teilbereich des Informationsraumes im Internet beschränkt bleiben. Als Ansatz zur
Lösung dieses Problems bietet sich an, die Informationserfassung kleinerer Bereiche, etwa
auf einzelne Webserver zu beschränken. Der Server selbst könnte bereits beim Einfügen
von Dokumenten Änderungen erkennen, so wie es der Hyperwave Information Server11
ermöglicht (siehe auch Kapitel 3.4.2), und die Indizes seiner Suchdatenbanken anpassen.
Eine andere Möglichkeit bieten lokale Gatherer, Programme die am Server lokal ständig
im Hintergrund laufen und periodisch die Dokumente durchforsten. Wie aktuell und
vollständig die gesammelten Informationen sind, hängt davon ab, wie oft der Datenbestand
abgesucht wird. Diese Informationen können über geeignete Schnittstellen für übergeordnete Suchdienste bereit gehalten werden. Dieser Ansatz führt zur Entwicklung hierarchischer Topologien, an deren unterster Ebene lokale Suchdienste stehen [GAM1998].
Darüber liegende Suchmaschinen fassen die Informationen mehrerer Server entweder
geographisch oder thematisch zu größeren Suchinformationen zusammen [DGK+1998].
Dieses Grundprinzip der verteilten Datenauffindung und Aufbereitung sowie Bereitstellen
der Informationen für andere Suchdienste findet man beim Harvest-System (siehe auch
Kapitel 3.4.1) und ist auch in der vorliegenden Diplomarbeit realisiert.
Katalogsuchdienste sind nicht in der Lage, Vollständigkeit zu bieten, da die Suchinformationen von aktiver Anmeldung der Dokumente von den jeweiligen Autoren bzw. den
Recherchen von Redaktionsteams abhängen [GAM1998]. Auch ergeben sich die gleichen
Probleme wie etwa Linkinkonsistenzen oder falsche Inhalte, wenn Dokumente geändert
oder entfernt werden.
2.3.2 Netz- und Serverbelastung
Das Hauptproblem heutiger Suchdienste ist das vielfache Durchforsten des World Wide
Web von vielen Suchrobotern – auch Spider genannt – in unkoordinierter Weise. Spider
sind Programme, die entlang von WWW-Hypertext-Strukturen Dokumente automatisch
über das Web laden, verarbeiten und Referenzen auf andere Dokumente weiterverfolgen.
Sie sammeln periodisch Informationen, die dann von den Suchdiensten bereitgestellt
werden. Jeder dieser Spider holt über das Web immer wieder die Dokumente bestimmter
Server. Dabei müssen auch schon einmal geprüfte Dokumente bzw., falls der Webserver
dies unterstützt, der HTTP-Header geholt werden, um überhaupt feststellen zu können, ob
diese geändert wurden. [WRD1998a]
Eine genaue Auslastung der Netzkapazität und der Webserver durch Spider ist nicht
bekannt, doch aus verschiedenen Untersuchungen kann man zumindest auf die
Netzbelastung durch die größeren Suchdienste schließen. Tabelle 2.1 zeigt eine Auswahl
aktueller Suchdienste. Die Größe der Suchdienste, also Anzahl der indizierten Seiten,
wurde aus [Sul1999a] (Stand 1. Juli 1999), die Updaterate und die Anzahl der abgesuchten
Seiten pro Tag sind aus [Car1999] (Stand 13. Jänner 1999) entnommen.
11
Hyperwave, http://www.hyperwave.com
14
KAPITEL 2 - SUCHDIENSTE
Search
Engine
Größe in
Millionen
Seiten
Fast
Northern
Light
Alta
Vista
HotBot/
Inktomi
Infoseek
Excite
Lycos
200
160
150
110
75
55
50
Abgesuchte
Seiten pro
Tag
unbekannt
Updaterate12
unbekannt
3 Millionen 10 Millionen 10 Millionen unbekannt
2 bis 4
Wochen
1 Tag bis
1 Monat
1 Tag bis
2 Wochen
1 Tag bis
2 Monate
3 Millionen 6 Millionen
1 bis 3
Wochen
2 bis 3
Wochen
Tabelle 2.1: Vergleich aktueller Suchdienste
Eine Liste aktiver Spider, auch Web Robots genannt, ist bei Martijn Koster zu finden
und zählt zur Zeit der Erstellung dieser Diplomarbeit über 200 Einträge [WRD1998b].
Was ein Spider genau durchsucht, läßt sich beeinflussen. Der "Robots Exclusion Standard"
beschreibt, wie mittels der Datei "robots.txt" im Root-Verzeichnis eines Webservers
Robots der Zutritt zu bestimmten Verzeichnissen im Web-Angebot verwehrt wird, wobei
diese allerdings nicht von allen Such-Robots berücksichtigt wird. Für weitere Informationen über die Funktionsweise sei auf die Robots-Pages von WebCrawler. [WRD1998a]
Ein Weg, um der hohen Netz- und Serverbelastung entgegen zu steuern, ist der in dieser
Diplomarbeit vorgestellte lokale Suchdienst, der in Verbindung mit hierarchisch
zusammenarbeitenden Suchdiensten Dokumenteninformationen eines Servers in effizienter
Weise weitergeben kann. Außerdem können mehrere Suchdienste von den so aufbereiteten
Daten Gebrauch machen, ohne daß der Server zusätzlich belastet wird. Auf die Vorteile
von hierarchischen Suchverfahren wird im Kapitel 3 genauer eingegangen.
2.3.3 Qualität und Zuverlässigkeit
Für den Benutzer eines Suchdienstes wäre es wichtig, Kenntnisse über die Qualität und
Zuverlässigkeit der einzelnen Informationen zu erhalten. Recherchiert etwa ein
Kulturreiseveranstalter nach den Öffnungszeiten und Führungsmöglichkeiten des Grazer
Zeughauses, so muß sich dieser auf die Information verlassen können. Derzeit bieten nur
Suchkataloge mit recherchierten Einträgen rudimentäre Ansätze für Bewertungen, da man
davon ausgehen kann, daß die aufgenommenen Webseiten zumindest einmal von den
Redakteuren überprüft worden sind. [Dys1997]
Die Angaben über Qualität und Zuverlässigkeit werden mit der raschen Zunahme an
Dokumenten im Internet immer wichtiger. Die Bewertung von Web-Information wird
menschlichen Bearbeitern eines Suchdienstes unter Mitwirkung der Web-Site-Betreiber
12
Die Updaterate ist meist von der "Wichtigkeit" der Seiten abhängig, also wie oft
andere Dokumente darauf verweisen, oder wird aus der durchschnittlichen
Änderungsrate der Dokumente abgeleitet.
KAPITEL 2 - SUCHDIENSTE
15
vorbehalten sein13. Neben der kostenlosen Bereitstellung von Suchergebnissen könnte sich
die Bewertung von Informationen zu einem kommerziellen Geschäftsfeld in Form einer
zusätzlichen Dienstleistung entwickeln. Durch die Entwicklung eines Maßstabes für
Qualität und Zuverlässigkeit und der Zuordnung einer Kennziffer zu jedem abgesuchten
Dokument (wie z.B. PICS14) könnte dem Benutzer eine Information bereitgestellt werden,
die darüber Auskunft gibt, wie sehr man sich auf die Information verlassen kann.
[Dys1997]
Eine andere Problematik, die zu unbefriedigenden Suchergebnissen führen kann, ist der
meist triviale Mechanismus, mit dem Suchmaschinen die Stichwörter festlegen. Dabei
werden in der Regel alle Wörter zu Stichwörtern, auch wenn sie in einem irrelevanten
Zusammenhang auftauchen; lediglich "Allerweltswörter”, zum Beispiel Artikel und
Pronomen, werden ausgefiltert. Nur wenige Suchmaschinen besitzen in dieser Beziehung
eine gewisse Intelligenz. Excite15 oder Verity16 berücksichtigt immerhin auch synonyme
Wörter. So werden beim Suchbegriff "Senioren” auch Seiten gefunden, die den Text
"ältere Menschen” enthalten. Eingesetzt wird bei Excite die patentierte Technologie
Intelligent Concept Extraction17, die die zugrundeliegenden Synonymtabellen selbsttätig
generiert. [ICE1996]
Ein weiterer Schwachpunkt läßt sich bei der Verwendung automatischer Indizierung
mittels Spider aufzeigen. Durch Wiederholen bestimmter oft im World Wide Web
gesuchter Schlüsselwörter im Dokument scheinen diese Dokumente fälschlicherweise im
Suchergebnis auf, obwohl der eigentliche Inhalt womöglich gar nichts mit der wirklichen
Abfrage zu tun hat. Diese Art der Beeinträchtigung wird Keyword-Spamming genannt.
[AtAs1998]
13
Bewertungsdienste, die gleichzeitig auch Programme zum Filtern von Internetinhalten
anbieten, sind z.B.:
Microsystems (Cyper Patrol), http://www.cyberpatrol.com
Net Nanny, http://www.netnanny.com
Net Shepherd, http://www.netshepherd.com
SafeSurf, http://www.safesurf.com
Solid Oak (CYBERsitter), http://www.cybersitter.com
SurfWatch, http://www.surfwatch.com
RSACi (Recreation Software Advisory Council Internet), http://www.rsac.org
14
Platform for Internet Content Selection, PICS, http://www.w3.org/PICS/
15
Excite, http://www.excite.com
16
Verity, http://www.verity.com
17
Intelligent Concept Exctraction, ICE, http://excite.com/ice/tech.html
KAPITEL 2 - SUCHDIENSTE
16
2.3.4 Zusatzinformationen
Zusätzliche Informationen (Metainformationen) über das Dokument, wie z.B. Autor,
Erstelldatum, Empfangskreis (Benutzerkreis, Ausbildungsniveau, etc.) und Zusammenfassung sind für den Benutzer ebenfalls hilfreich. Die Kenntnisse über Verwendung
bestimmter Multimedia-Anwendungen (z.B. Real Audio) als zusätzliches Suchkriterium
oder Script-Sprachen (ActiveX) als Sicherheitskriterium werden immer größere Bedeutung
erlangen. Derzeit gibt es noch keine normierten Richtlinien für Metainformationen in
Dokumenten, aber im Laufe der Zeit haben sich einige oft verwendete Methoden
entwickelt. Leider nehmen viele aktuelle Suchdienste wie Excite, Lycos oder Northern
Light keine Notiz von diesen Informationen. [Sul1999b]
Es sind Bestrebungen im Gange, einen Standard zu schaffen, wie man diese zusätzlichen
Informationen in den Web-Seiten integrieren kann. Mehrere Arbeitsgruppen des World
Wide Web Consortium18 sind zu Zeit der Erstellung der Arbeit dabei, unter Einbeziehung
existierender Vorschläge wie PICS19, LOM20 und Dublin Core21 einen allgemeingültigen
Standard für diese Metadaten zu erarbeiten, das sogenannte Resource Description
Framework22. Zur Zeit der Erstellung dieser Diplomarbeit liegt RDF als Recommendation
vor. Eine genauere Beschreibung der hier erwähnten Standards findet sich im Kapitel 4 –
Formate und Metadaten.
Der Grundgedanke von PICS liegt in der Selektion von Informationen, die bestimmten
ausgewählten Kriterien entsprechen (z.B. Gewaltfreiheit), um damit nur bestimmte WebDokumente zugänglich zu machen. Die Information für das Rating sind in Metainformationen der HTML-Dokumente enthalten oder verweisen auf sogenannte Rating-Server, wo
die Kategorisierung der jeweiligen Seiten getroffen wird. Es wäre denkbar, bestehende
Rating-Informationen ebenfalls in den Daten-Index von Suchdiensten aufzunehmen und so
dem Benutzer mehr Informationen zur Verfügung stellen zu können. Heutige Suchdienste
verwenden allerdings nur die Meta-Angaben für Description und Keywords. Eine
Ausnahme ist der Suchdienst Fireball23, der auch Angaben wie Author, Publisher oder
Page-Type berücksichtigt. [Sul1999b] [Kar1999b]
Eine interessante Entwicklung, die man im Rahmen der Meta-Tags ausnützen kann,
stellt der Hyperwave Information Server24 zur Verfügung. Jedes Objekt in einem
Hyperwave Server hat eine Reihe von Attributen (z.B. Schlüsselwörter oder Autor), die in
der lokalen Suchmaschine indiziert und damit rasch suchbar sind. Diese Attribute können
dem jeweiligen Dokument in Form von Meta-Tags automatisch hinzugefügt werden, die
18
World Wide Web Consortium, W3C, http://www.w3.org
19
Platform for Internet Content Selection, PICS, http://www.w3.org/PICS/
20
Learning Object Metadata, LOM, siehe IEEE Learning Technology Standards
Committee, http://ltsc.ieee.org/wg12/index.html
21
Dublin Core Metadata Initiative, http://purl.org/dc/
22
Resource Description Framework, RDF, http://www.w3.org/RDF/
23
Fireball, http://www.fireball.de
24
Hyperwave, http://www.hyperwave.com
KAPITEL 2 - SUCHDIENSTE
17
damit für Spider externer Suchdienste die notwendigen Zusatzinformationen bereitstellen
(siehe auch Kapitel 3.4.2 – Hyperwave).
Ein weitere Möglichkeit, zusätzliche Informationen zu nutzen, bieten sogenannte
Recommender Systems. Die Grundidee dabei ist, bei anderen Menschen mit entsprechend
ähnlichen Interessensgebieten, wie dem Anwender, Empfehlungen einzuholen. Diese
Systeme bilden die programmtechnische Umgebung, die es ermöglicht, Dokumente mit
bestimmtem Inhalt bzw. Qualität für Benutzer mit bestimmten Interessen und Ansprüchen
zugänglich zu machen. Dabei lassen sich zwei Kategorien unterscheiden. Die Content
based Recommender Systems vergleichen dabei die tatsächlichen Inhalte oder Kurzfassungen von Dokumenten mit dem Benutzerprofil, beispielsweise einer Sammlung gewichteter
Wörter, und versuchen für den Benutzer interessante Dokumente zu finden. Die
Collaborative based Recommender Systems versuchen, Benutzer mit ähnlichen Interessen
zu finden und schlagen dann Dokumente vor, die von diesen als interessant klassifiziert
wurden. Unter anderem sind dies PHOAKS25, Referral Web26, GroupLens27, Siteseer28,
Fab29, Alexa30 und das auf Hyperwave31 aufbauende Personalised Recommender System.
Das Personalised Recommender System ist ein Collaborative System, daß es Benutzern
ermöglicht, Dokumente zu kategorisieren und zu bewerten32. Die Bewertungen werden auf
einem Hyperwave Server verwaltet, was den Vorteil mit sich bringt, die bereits
vorhandenen Such- und Sortierfunktionen von Hyperwave benutzen zu können. Um
Empfehlungen betrachten zu können, stehen einerseits das Server Interface und
andererseits ein eigenes Recommendation-Modul zur Verfügung. Das System erlaubt auch,
die Empfehlungen bestimmter anderer Benutzer besonders zu gewichten. [Hor1999]
[Leg1999]
2.3.5 Relevanz der Informationen
Relevanz kann als Grad der Übereinstimmung von nachgefragten und angebotenen
Informationen definiert werden, also wie gut das Suchergebnis mit der Abfrage
übereinstimmt. Suchdienste berechnen den Relevanzgrad mittels statistischer Verfahren
unter Nutzung der Worthäufigkeit und der Wortabstände. [Bek1996]
Die einzelnen Wörter in den jeweiligen Dokumenten sind in ihrer Wichtigkeit bzw.
Relevanz unterschiedlich. Ein automatisiertes Verfahren könnte die Wichtigkeit der
Begriffe ermitteln und für eine Zusammenfassung bzw. Schlüsselwortgenerierung sowie
für eine Sortierreihenfolge bei Suchergebnissen verwenden. Ein Ansatzpunkt ist durch die
25
PHOAKS, http://www.phoaks.com
26
Referral Web, http://www.research.att.com/~kautz/referralweb/index.html
27
GroupLens, http://www.cs.umn.edu/Research/GroupLens
28
Siteseer, http://www.imana.com/WebObjects/Siteseer
29
Fab, http://www-diglib.stanford.edu/diglib/pub/projects.shtml
30
Alexa, http://www.alexa.com
31
Hyperwave, http://www.hyperwave.com
32
Jeder Benutzer ist Mitglied einer oder mehrerer Gruppen, wobei jede Gruppe eine
Menge von Kategorien enthält, die von einem Administrator verwaltet werden; jedes
Dokument ist einer Kategorie zugeordnet.
KAPITEL 2 - SUCHDIENSTE
18
Bewertung der örtlichen Stelle des Wortes innerhalb des Dokuments gegeben [Bag1996].
Naheliegend dabei ist, daß beispielsweise Wörter in der Überschrift oder fett geschriebene
eine größere Bedeutung haben werden als im normalen Fließtext (siehe auch Abschnitt
4.1.1 – HTML). Die daraus gewonnene Maßzahl könnte als zusätzliche Information in den
Suchindex eingehen. Dieser Ansatz wurde auch in der vorliegenden Diplomarbeit gewählt,
wobei die Wörter je nach Ort des Vorkommens bewertet werden können. Dem Benutzer
wird durch automatisch erstellte Zusammenfassung bzw. die Bildung von relevanten
Schlüsselwörtern ermöglicht, aus einer großen Anzahl von Suchergebnissen eine geeignete
Auswahl zu entnehmen.
Ein weiterer Forschungsansatz ist die Zusammenfassung von Dokumenten mit ähnlichen
Indizierungsprofilen zu Dokumentenclustern. Unter der Annahme, daß Dokumente mit
ähnlichen bzw. einer großen Anzahl an gleichen Wörtern auch ähnliche Inhalte haben
werden, lassen sich entsprechende Algorithmen entwickeln. Andere Ansätze befassen sich
mit der Gruppierung von Dokumenten anhand Titeln und Beschreibungen. [ZE1998]
2.4 Zusammenfassung
Aufgrund der unüberschaubaren Anzahl an Dokumenten im World Wide Web und deren
kontinuierlicher Veränderung ist es ohne die Hilfe von Suchdiensten, also die Bereitstellung von Verweisen zu gewünschten Themen, praktisch nicht mehr möglich, relevante
Informationen zu erhalten. Die Basis dieser Suchdienste sind verschiedene Methoden der
Lokalisierung von Dokumenten und der Aufbereitung deren Inhalts. Durch aktives
Anmelden können Autoren ihre Dokumente in einen Suchdienst aufnehmen lassen. Bei der
redaktionellen Recherche verfolgen Lektoren die Hypertext-Strukturen und nehmen
passende Dokumente in ihren Suchdienst auf. Robots bzw. Spider navigieren mit Hilfe von
Hyperlinks, Menüs und Verzeichnisstrukturen im Informationsraum und verarbeiten die
aufgefundenen Dokumente automatisch.
Die Bereitstellung der Information wird durch thematische Kataloge, durch einen
Suchindex oder durch Mischformen aus beiden realisiert. Während sich der Benutzer bei
Verwendung eines Kataloges schrittweise der gewünschten Dokumentenmenge "nähert",
muß er beim Suchindex durch Angaben von Suchwörtern seine Suche formulieren. Die
Suchanfrage kann dabei mit Hilfe von booleschen Operatoren oder Wildcards modifiziert
werden. Einige Suchdienste bieten auch Unterstützung für die Suche nach Phrasen oder
beziehen die Nähe von Suchwörtern untereinander in die Auswertung mit ein (siehe
Abschnitt 2.1.2).
Gängige Suchdienste arbeiten meist unabhängig von einander und laden Daten vom
Informationsserver über das Netz, um den Inhalt zu verarbeiten und bereitzustellen. Diese
unkoordinierte, zentrale Vorgangsweise führt zu enormer Netz- und Serverlast. Weitere
Probleme liegen zum Beispiel auf dem Gebiet der Aktualität und der Qualität der
angebotenen Information. (siehe Abschnitt 2.3).
Viele der in diesem Kapitel aufgezählten Nachteile lassen sich durch die im folgenden
Kapitel vorgestellte verteilte bzw. lokale Informationssammlung, -aufbereitung und -auffindung verhindern.
Kapitel 3
Lokale und verteilte Aufbereitung
Heutige Methoden und Technologien zur Informationsauffindung im World Wide Web
kommen mit der exponentiell anwachsenden Informationsmenge von Dokumenten und
Newsgroup-Beiträgen nur mehr in Teilbereichen zurecht. Die unter anderem im letzten
Kapitel aufgezeigten Schwachstellen (siehe Abschnitt 2.3) lassen es notwendig erscheinen,
neue Forschungsansätze und innovative Verbesserungen gegenwärtiger Suchdienste zur
Wissenserfassung zu untersuchen. In diesem Kapitel wird auf die Konzepte verteilter
Datenaufbereitung und hierarchischer Suchdienste näher eingegangen und nach einer
Bewertung der Vor- und Nachteile ein Überblick über heute existierende Systeme gegeben.
3.1 Grundlagen
Im Gegensatz zu herkömmlichen Methoden (siehe auch 2.1.1), also dem Sammeln und
Aufbereiten von Informationen über Dokumente im World Wide Web von zentralen
Stellen aus (siehe Abbildung 3.1a), verfolgt die verteilte Auffindung einen anderen Ansatz.
Suchdienst
Suchdienst
Gatherer
Gatherer
InformationsServer
InformationsServer
InformationsServer
Teil a: Topologie mit unabhängigen
zentralen Gatherern
Suchdienst
Suchdienst
Gatherer
Server
Suchdienst
Gatherer
Server
Gatherer
Server
Teil b: Hierarchische Topologie mit
lokalen Gatherern
Abbildung 3.1: Herkömmliche und hierarchische Topologie von Suchdiensten
KAPITEL 3 - LOKALE UND VERTEILTE AUFBEREITUNG
20
Bei verteilten Systemen (siehe Abbildung 3.1b) sind mehrere voneinander unabhängige
Module1 für das Auffinden und die Aufbereitung der Daten zuständig. Ein oder mehrere
übergeordnete Systeme, die Suchdienste, bedienen sich der Daten und stellen sie über ein
Suchinterface zur Verfügung. [BDH+1995] [HSW1996] [GAM1998]
3.2 Vorteile der verteilten
Informationsaufbereitung
Durch die mögliche hierarchische Anordnung von Suchdiensten und die Nähe der
Gatherer – also der Programme die die Informationen sammeln – zu den aufzubereitenden
Daten ergeben sich einige Vorteile, die in diesem Abschnitt diskutiert werden.
3.2.1 Vollständigkeit und Aktualität
Die Vollständigkeit beschränkt sich beim System der verteilten Aufbereitung auf
Teilbereiche, die durch die lokalen Gatherer abgedeckt werden. Aufgrund des Wissens
über den Serverinhalt kann der Administrator lokale Gatherer individuell an die Dynamik
des Dokumentenangebotes anpassen. So können Informationsserver mit oftmaligen
Änderungen der Dokumente wesentlich häufiger durchforstet werden, was zu einem guten
Maß an Aktualität innerhalb des abgesuchten Bereiches führt. Bei geändernden
Dokumenten stimmen sonst die Suchergebnisse nicht mehr mit den tatsächlich
vorhandenen Seiten überein. [Bek1996]
Durch Weitergabe der gesammelten Informationen an übergeordnete Suchprogramme
verbessert sich die Vollständigkeit auf die Summe der durchforsteten Teilbereiche. Wenn
auch die unterschiedlichen Sammelraten an übergeordnete Suchprogramme weitergegeben
werden und diese dementsprechend ihre eigenen Datenbestände erneuern, bleibt die
Aktualität der Teilbereiche möglichst gut erhalten. Bei dem im Rahmen dieser Diplomarbeit entwickelten Suchprogramm kann die Informationssammelrate und die Zeit, die
Dokumente nach dem letzten erfolgreichen Zugriff in der Suchdatenbank verbleiben,
individuell eingestellt werden.
3.2.2 Netz- und Serverbelastung
Wie in Abschnitt 2.3.2 erläutert, durchforsten herkömmliche Suchdienste bzw. deren
Spider unabhängig voneinander das World Wide Web und fordern Dokumente so
mehrfach über das Netz an. Auch um Dokumente auf Änderungen zu überprüfen muß
zumindest ein HTTP-Header ebenfalls zu jedem Suchdienst übertragen werden. Durch das
System der verteilten Sammlung und Aufbereitung ergeben sich mehrere Möglichkeiten,
die Belastung von Internet und Webservern zu verringern. Lokale Gatherer können sich die
zu untersuchenden Dokumente über das Dateisystem holen und vermeiden so, Dokumente
mittels HTTP-Protokoll zu übertragen und den Webserver zusätzlich zu belasten.
1
hier engl. Gatherer genannt
KAPITEL 3 - LOKALE UND VERTEILTE AUFBEREITUNG
21
Eine weitere Optimierung ergibt sich durch die gesammelte Übertragung der Dokumenteninformationen an übergeordnete Suchprogramme anstatt der üblichen Einzelübertragungen. Durch zusätzliche Komprimierung kann die Datenmenge auf unter dreißig Prozent
reduziert werden. Eine weitere Reduktion erreicht man, wenn statt der Volltextinformation
Inhaltszusammenfassungen (Abstracts) erzeugt und übertragen werden. Der größte Vorteil
ist, daß das lokale Suchprogramm nur Daten über diejenigen Dokumente weitergeben muß,
die sich seit der letzten Übertragung geändert haben. Durch diese inkrementelle
Informationsweitergabe wird die Netzbelastung wesentlich verringert. [BDH+1995]
[HSW1996]
Alle erwähnten Vorteile sind in der vorliegenden Arbeit implementiert. Die Sammlung
der Informationen erfolgt über das Dateisystem, wobei automatisch Inhaltszusammenfassungen generiert werden können. Die Schnittstelle zu übergeordneten Suchsystemen
unterstützt inkrementelle Datenübertragung und die Daten können auf Anfrage zusätzlich
komprimiert werden (siehe auch Kapitel 8).
3.2.3 Gliederung des Informationsraumes
Aufgrund der Kenntnis des Administrators über die unterschiedlichen Themen, die in
verschiedenen Verzeichnissen eines Informationsservers behandelt werden, kann dieser
Gatherer für unterschiedliche Wissensgebiete einrichten. Bei der Informationssammlung
durch übergeordnete Module, die also Dokumenteninformationen von lokalen Gatherern
übernehmen, können dann entweder themenspezifisch oder nach den geographischen
Gegebenheiten Daten übernommen werden. Eine Voraussetzung dafür ist allerdings das
Wissen um den Inhalt der durchforsteten Daten eines lokalen Gatherers (siehe auch Kapitel
3.3 –Nachteile der verteilten Informationsaufbereitung).
Durch die mögliche Zusammenarbeit einzelner Gatherer in hierarchischer Struktur
nimmt der Spezialisierungsgrad jeder Stufe weiter ab, gleichzeitig erhöht sich die Anzahl
der absuchbaren Dokumente.
3.2.4 Zusatzinformationen
Die Nähe des Gatherers zu den Informationen und das Wissen der Autoren bzw. des
Administrators über die Dokumente erlaubt es, zusätzliche Informationen zur Verfügung
zu stellen. Diese Informationen können mittels Meta-Angaben (siehe Kapitel 4.1.2 – MetaTags) in den Dokumenten selbst stehen oder in eigenen Bereichen gespeichert sein, welche
dann dem Sammelprogramm bekannt gemacht werden.
Gerade auf dem Gebiet der Zusatzinformationen finden momentan viele Entwicklungen
statt. Am vielversprechendsten ist das Resource Description Framework (siehe Kapitel
4.3.4), das zusammen mit einheitlichen Namen für Meta-Angaben den Austausch von
zusätzlichen Informationen erleichtern wird. Erst Zusatzinformationen erlauben das
Zusammenarbeiten mehrerer Suchprogramme und ermöglichen eine Gruppierung
beispielsweise nach Themengebieten und Kategorien.
Durch zusätzliche Angabe des Themengebietes, dem ein Dokument zugeordnet ist,
lassen sich auch Fehler ausschließen, die auf Mehrdeutigkeiten von Suchbegriffen beruhen.
Fehlt die Möglichkeit der Angabe des Themengebietes, erhält man bei einer Suche nach
Dokumenten, die beispielsweise den Begriff Virus enthalten sollen, sowohl Verweise auf
KAPITEL 3 - LOKALE UND VERTEILTE AUFBEREITUNG
22
medizinische Seiten als auch auf Dokumente über Computerviren. Zusatzinformationen
bieten die Möglichkeit einer wesentlichen Qualitätsverbesserung der Relevanz der
ermittelten Suchergebnisse.
3.3 Nachteile der verteilten
Informationsaufbereitung
Mit der Verteilung der Aufgaben ergibt sich ein erhöhter organisatorischer Aufwand
[Neussl1998]. Um einen verteilten Suchdienst aufzubauen, ist man auf die Mitarbeit der
Informationsbieter angewiesen. Diese müssen zusätzlich zu den Webservern lokale
Gatherer installieren und warten. Je nach Menge der abzusuchenden Dokumente benötigt
das Programm Speicherplatz und Rechenleistung, so daß die dem Server zur Verfügung
stehenden Ressourcen geringer werden.
Ein weiterer Nachteil ist der relativ hohe Koordinationsaufwand um eine hierarchische
Topologie aufbauen zu können. Übergeordnete Module müssen richtig konfiguriert
werden, um aktive Gatherer abfragen zu können. Dabei ist es nötig, die Informationsserver
zu kennen, auf denen lokale Gatherer arbeiten. Ein Ansatz dazu sind zentrale Verzeichnisse mit Beschreibungen der abgesuchten Server, so daß die Möglichkeit besteht, zu
entscheiden, von welchen Gatherern die Daten abgeholt werden sollen. Die Datenweitergabe muß in einem einheitlichen Format erfolgen, wobei sich SOIF2 oder in Zukunft RDF3
anbieten. Das Harvest-System (siehe auch Abschnitt 3.4.1) kann mit entsprechender
Konfiguration in eine hierarchische Topologie eingebunden werden. [HSW1996]
3.4 Lokale Informationsaufbereitung und
Suchdienste
Durch die wachsende Anzahl von Dokumenten auf den einzelnen Webservern wird es
für den Benutzer immer schwieriger, an die gewünschte Information zu kommen.
Erleichterung schaffen in diesem Fall lokale Suchprogramme, die ähnlich AltaVista oder
Excite eine Suche nach Dokumenten ermöglichen. Der Unterschied ist, daß nur Seiten des
eigenen Webservers indiziert werden.
Lokale Suchdienste besitzen im Gegensatz zu den oben erwähnten Gatherern zusätzlich
ein Suchinterface für Web-Benutzer und ein Modul zur Indizierung der Dokumente.
Derzeit haben sich mehrere Suchprogramme etabliert, wobei im folgenden zwei Vertreter
genauer beschrieben werden. Der Nachteil ist, daß die meisten Programme nur auf
bestimmten Betriebssystemen und Plattformen lauffähig sind. Auch eine Informationsweitergabe an übergeordnete Suchdienste ist selten implementiert. Als wichtigster
Vertreter ist hier das Harvest-System zu nennen. Ein weiteres System mit interessanten
2
Harvest Summary Object Interchange Format, SOIF, siehe auch Abschnitt 4.3.1
3
Resource Description Format, RDF, http://www.w3.org/RDF/
23
KAPITEL 3 - LOKALE UND VERTEILTE AUFBEREITUNG
Funktionen ist Hyperwave, ein Document Management System, daß eine Kombination aus
Webserver und Suchsystem darstellt.
3.4.1
Harvest
Harvest geht auf ein ARPA-Projekt der University of Boulder, Colorado zurück und
wurde 1996 abgeschlossen [BDH+1995] [HSW1996]. Der Quelltext ist frei verfügbar und
wird vor allem an Universitäten oft verwendet. Eine offizielle Web-Site, die sich mit der
Weiterentwicklung von Harvest beschäftigt, ist die University of Edinburgh4.
Das Harvest System stellt eine Sammlung von Werkzeugen zur Auffindung, Aufbereitung, Verwaltung und Suche von Informationen in Netzwerken dar. Das Grundkonzept des
Harvest-Systems beruht auf der Idee der verteilten Informationsauffindung, Aufbereitung
und Bereitstellung für andere Suchdienste. Dabei lassen sich unterschiedliche Konfigurationen bilden. [BDH+1995]
Der Großteil der heute im Internet verwendeten Harvester wird aber in nicht verteilten
Suchsystemen eingesetzt und dient dazu, einzelne Webserver zu indizieren und ein
Suchinterface für Anwender bereitzustellen. Das Harvest-System bietet die Möglichkeit,
ein verteiltens, kooperatives Suchsystem mittels zweier Komponenten, dem Gatherer und
dem Broker, aufzubauen (siehe Abbildung 3.2). Die Beschreibungen in diesem Abschnitt
beruhen auf [BDH+1995] und [HSW1996].
Suchdienst
Suchdienst
Suchdienst
Gatherer
Server
Gatherer
Server
Teil a: Lokale Gatherer laufen am
Hostrechner des Webservers
Suchdienst
Gatherer
Suchdienst
Gatherer
Server
Suchdienst
InformationsServer
InformationsServer
InformationsServer
Teil b: Gatherer sammelt über das Web
Informationen für mehreren Suchdienste
Abbildung 3.2: Möglichkeiten von Harvest für verteilte und kooperative Suchsysteme
Der Gatherer
Der Gatherer sammelt und extrahiert periodisch verschiedenartige Dokumente von
einem oder mehreren Informationsservern und generiert für jedes aufgefundene Dokument
ein sogenanntes SOIF-Objekt (siehe auch Kapitel 4.3.1 – Harvest Summary Object
Interchange Format). Der Gatherer läuft üblicherweise am Hostrechner des Informationsservers wie in Abbildung 3.2a gezeigt. Pro Server ist ein Gatherer zuständig, wobei aber
auch die Möglichkeit besteht, daß ein oder mehrere Informationsserver von einem
4
University of Edinburgh, Harvest, http://www.tardis.ed.ac.uk/~harvest/
KAPITEL 3 - LOKALE UND VERTEILTE AUFBEREITUNG
24
physikalisch getrennten Gatherer durchforstet werden. Abbildung 3.2b zeigt einen
Gatherer, der Daten von drei entfernten Informationsservern über das Netz holt und diese
an übergeordnete Gatherer bzw. Suchdienste weiterleitet.
Der Broker
Der Broker fragt die ihm zugeordneten Gatherer periodisch nach Änderungen des
Informationsangebotes ab. Die erhaltenen SOIF-Objekte werden verwaltet und können
mittels externer Werkzeuge wie Glimpse indiziert werden. Der Anwender kann über das
World Wide Web mittels Suchinterface auf die Daten zugreifen.
Gatherer und Broker können nun auf unterschiedliche Weise zusammenarbeiten.
Abbildung 3.2b zeigt einen Gatherer, der über das Netz auf die Daten des Servers zugreift.
Der Vorteil einer lokalen Suche kommt hierbei nicht zum tragen. Dennoch hat diese
Konfiguration ihre Berechtigung, da aufgrund des Zusammenarbeitens mit mehreren
Brokern die Belastung für Netz und Server ebenfalls reduziert werden kann. Eine weitere
Möglichkeit ergibt sich, wenn der Gatherer direkt am Rechner des Informationsservers
plaziert wird. Hier wird einerseits die Belastung der Server reduziert 5 und andererseits
durch inkrementelle Übertragung der Änderungen und etwaige Komprimierung der
übertragenen Daten die Netzbelastung gesenkt.
Der Broker kann Informationen von mehreren Gatherern beziehen. Ein Gatherer
wiederum kann seine gesammelten Informationen an verschiedene Broker übermitteln.
Schließlich können auch Broker ihre Informationen an andere Broker weitergeben. Durch
dieses Zusammenspiel der hierarchisch angeordneten Komponenten können die Kosten für
das Auffinden und Aufbereiten der Daten minimiert werden.
3.4.2 Hyperwave
Hyperwave6 wurde an der Technischen Universität Graz vom Institute for Information
processing and Computer supported new Media7 unter dem Namen Hyper-G entwickelt. Es
unterstützt hierachische Strukturen von Hypertext- und Hypermedia-Files sowie Stichwortund Volltext-Suchen in diesen Strukturen, den sogennanten Collections. HyperwaveServer können als Document Management System und als Portal-Server für komplexe
Informationssysteme eingesetzt werden. [Hyp1998]
Im Gegensatz zum Webserver, wo ein Suchindex lediglich einen vom Administrator
einzurichtenden Zusatz darstellt und externe Suchdienste, die Daten über das Netz
auffinden und weiterverarbeiten, ist die Suchmöglichkeit in Hyperwave bereits integriert.
Nachfolgende Zusammenfassung orientiert sich an [Mau1996] und [Hyp1998].
Hyperwave setzt nicht wie gewöhnliche Server auf das Dateisystem sondern auf ein
objektorientiertes Datenbanksystem auf. Die Datenbank kann Dokumente beliebigen
Formats enthalten (HTML, Text, Grafik, Sound, Video, VRML, Java Applets, etc.),
5
Der Zugriff auf die Dokumente kann über das Dateisystem erfolgen und verbraucht
wesentlich weniger Ressourcen als der Zugriff über den Webserver.
6
Hyperwave, http://www.hyperwave.com
7
Institute for Information processing and Computer supported new Media, IICM,
http://www.iicm.edu
KAPITEL 3 - LOKALE UND VERTEILTE AUFBEREITUNG
25
welche durch das Hyperwave Information Management System entsprechend der
Anwendung aufbereitet werden.
Während ein Webserver eine unstrukturierte Sammlung von Dokumenten verwaltet, die
einzig durch Hyperlinks zusammengehalten und zugänglich gemacht wird, bietet dieses
System zusätzlich noch eine hierarchische Organisationsebene, die strukturellen Links.
Dies erleichtert u.a. die Navigation und die Zuordnung einzelner Dokumente. Alle Objekte
(Dokumente, Kollektionen, Links) werden beim Anlegen in der Datenbank gespeichert.
Durch die bidirektionale Verknüpfung der Hyperdokumente tritt das Problem der
Linkinkonsistenz nicht auf. Beim Löschen eines Dokuments werden aus der Datenbank
alle ein- und ausgehenden Verknüpfungen ebenfalls entfernt. Daraus sieht man, daß auch
Aktualität und Vollständigkeit implizit gewährleistet sind.
Die oben genannten Eigenschaften erlauben es nicht nur, die gefundenen Dokumente in
ihrer Hierarchie anzuzeigen, sondern auch die benachbarten Dokumente und ihre
Verknüpfungsbeziehungen in Form eines mit Hyperlinks versehenen Graphen auszugeben.
Suchen und Navigieren fließt ineinander über. Die Suche läßt sich auch auf einen
Teilbaum der Dokumentenstruktur beschränken, wobei sich dieser auf verschiedenen
Hyperwave-Server befinden kann. Eine Suchabfrage kann auch auf die Ergebnismenge
einer vorangegangenen Anfrage eingeschränkt werden. So kann man schrittweise die
Anfrage präzisieren.
Jedes Hyperwave-Objekt besitzt eine Vielzahl von Metainformation (Attribute). Die
Indizierung der wichtigsten Attribute (Titel, Autor, Schlüsselwörter, Datum der
Generierung etc.) macht eine gezielte Suche möglich. Boolesche Verknüpfungen werden
bei der Abfrage ebenso unterstützt wie Präfix- und Bereichssuche. Nichtindizierte
Attribute können nur in Verbindung mit einer Indexsuche verwendet werden; sie engen das
Ergebnis ein. Autoren können zu Dokumenten beliebige Attribute hinzufügen. Der
Administrator des Systems kann Attribute definieren, die dann ebenfalls indiziert und
somit absuchbar gemacht werden.
Zusätzlich zur Suche über die Metainformation ist jedes Textdokument über Volltextsuche zugänglich. Die neueren Versionen ermöglichen auch das Suchen über mehrere
Hyperwave-Server, dem Serverpool. Hyperwave kann statt der eigenen VolltextSuchmaschine auch mit dem Verity-Suchsystem konfiguriert werden. Verity verfügt über
einen Thesaurus, um auch Wörter gleicher Bedeutung in die Suche miteinbeziehen zu
können. Stemming (siehe Abschnitt 2.1.1, im Absatz Vollautomatische Auffindung) wird
ebenso angewandt wie ein Verfahren, das erlaubt, nach ähnlich klingenden Wörtern zu
suchen. Dabei ist die Suche nicht auf HTML-Dokumente beschränkt. Formate wie Word
und Excel werden ebenfalls unterstützt.
Das Hyperwave-Suchsystem ermöglicht die Verwendung sogenannter Query Objects.
Diese Suchanfragen werden im Hyperwave-Server gespeichert und periodisch ausgewertet.
Die Resultate werden via Email an den Benutzer versandt. Vordefinierte Suchen können
auch vom Benutzer zu beliebiger Zeit ausgeführt werden.
Es wäre naheliegend, die vom System indizierten Daten in geeigneter Form auch
anderen Suchsystemen zugänglich zu machen. Durch die Möglichkeit, persönliche Rechte
zu vergeben, kann eine den Bedürfnissen bzw. Zugriffsrechten entsprechende Dokumentengruppierung sowie ein entsprechendes User Interface dynamisch generiert werden.
KAPITEL 3 - LOKALE UND VERTEILTE AUFBEREITUNG
26
3.5 Zusammenfassung
In diesem Kapitel wurden nach einer Einführung in die Grundlagen lokaler Informationssammlung die Vorteile wie z.B. Vollständigkeit, Aktualität und Netz- bzw.
Serverbelastung aufgezeigt (siehe Abschnitt 3.2). Dem gegenüber stehen Nachteile wie der
erhöhte organisatorische Aufwand und der Koordinationsaufwand (siehe Abschnitt 3.3),
die aber durch die überwiegend positiven Aspekte gerechtfertigt werden.
Als Ergebnis der vorangestellten Untersuchungen wurde daher in der vorliegenden
Diplomarbeit der Ansatz der lokalen Informationsauffindung gewählt (siehe auch Teil II –
Gestaltungsbereich). Bei lokaler Informationsauffindung werden die notwendigen Daten
direkt am Webserver über das Dateisystem geholt, um die Belastung des Servers zu
reduzieren. Die Daten können wesentlich aktueller sein, da die Absuchrate individuell
einstellbar ist (siehe Kapitel 6 – Der Gatherer).
Damit die Informationen weiterverwendet werden können, wurde ebenfalls eine
Schnittstelle implementiert, über die die gesammelten Daten in komprimierter Form an
übergeordnete Suchdienste weitergegeben werden können (siehe Kapitel 8). Damit kann
mit geringer Netzbelastung ein hierarchisches System aufgebaut werden, das geographisch
oder thematisch Dokumenteninformationen sammelt und über ein Suchinterface zur
Verfügung stellt.
Das folgende Kapitel gibt einen Überblick der in der vorliegenden Arbeit verwendeten
Formate. Für die Informationsaufbereitung sind Kenntnisse über Formate wie HTML und
die eventuell darin enthaltenen Metainformationen wichtig (siehe Abschnitt 4.1). Eine der
Forderungen war es, die über die Dokumente gesammelten Informationen in Formaten wie
SOIF oder XML weitergeben zu können, wobei auch neuere Entwicklungen wie RDF
betrachtet werden (siehe Abschnitt 4.3).
Kapitel 4
Formate und Metadaten
In den Kapiteln 2 und 3 hat sich gezeigt, wie wichtig Zusatzinformationen zur Auffindung von Informationen im World Wide Web sein können, da sie es Suchdiensten
ermöglichen, relevantere Sucherergebnisse zu liefern. Um die Zusatzinformationen in den
im Gestaltungsbereich entwickelten Modulen nutzen zu können, beschreibt dieser
Abschnitt gängige Metadatenformate und geht auch auf zukünftige Entwicklungen auf dem
Gebiet der Metadaten ein. Aus den im Kapitel 3 diskutierten Vorteilen verteilter
Suchsysteme ergibt sich die Implementierung eines lokalen Gatherers (siehe Kapitel 6) mit
der Möglichkeit zur Weitergabe der Information an hierarchisch übergeordnete
Suchsysteme. Diese Struktur ermöglicht die mehrfache Verwendung schon erfaßter
Informationen und verringert die Netz- und Serverbelastung. Zur Informationsweitergabe
werden Standardformate verwendet, die ebenfalls in diesem Kapitel beschrieben werden.
Der größte Teil der Informationsträger im World Wide Web (WWW oder Web) sind
neben multimedialen Inhalten wie etwa Bildern vor allem HTML-Dokumente1. Im
Gestaltungsbereich der vorliegenden Diplomarbeit wird unter anderem ein Modul zum
Extrahieren von Informationen aus HTML-Dokumenten (siehe auch Kapitel 7 –
Fehlertoleranter HTML-Konverter) implementiert. Daher geht Abschnitt 4.1 auf die
Struktur von HTML und auf die in der Spezifikation vorgesehene Möglichkeit zur
Einbindung von Metainformationen ein2. Abschnitt 4.2 erläutert Aufbau und Inhalt
verschiedener gegenwärtig verwendeter Metadatenformate. Es gibt mehrere Initiativen, die
Metadaten für bestimmte Anwendungsgebiete definieren. Dublin Core (siehe Abschnitt
4.2.1) bietet 15 Elemente wie Autor und Publisher zur Ressourcenbeschreibung. LOM, ein
sich zum Zeitpunkt der Erstellung dieser Diplomarbeit in Entwicklung befindlicher
Standard, definiert die benötigten Attribute um ein sogenanntes Learning Object
vollständig zu beschreiben (siehe Abschnitt 4.2.2). PICS (siehe Abschnitt 4.2.2) ist ein
Framework zur Filterung von Internet-Inhalten und wurde entwickelt, um jugendfreie
1
Hypertext Markup Language, HTML
2
Vorgegebene Metadaten, also Meta-Angaben in HTML-Dokumenten sind vor allem
für Suchdienste wichtig, da Informationen wie Schlüsselwörter oder
Zusammenfassungen nicht erst aus dem Dokument extrahiert werden müssen.
Außerdem ist bei den vom Suchdienst verwendeten Algorithmen zur Ermittlung von
Schlüsselwörtern oder Inhaltsbeschreibungen nicht gewährleistet, daß die generierten
Informationen relevant bzw. korrekt sind.
KAPITEL 4 - FORMATE UND METADATEN
28
Inhalte als solche auszuzeichnen. PICS-Bewertungen können als Metadaten in HTMLDokumente integriert und daher vom HTML-Konverter extrahiert und weiterverarbeitet
werden.
Die mit dem Konverter extrahierten Informationen über bestimmte Objekte bzw.
Dokumente können zur weiteren Verwendung mit einem im Rahmen des Gestaltungsbereiches entwickeltem Modul (siehe auch Kapitel 8 – Das Gatherer-Collector-Interface) an
hierarchisch übergeordnete Suchdienste weitergegeben werden. Dabei werden schon
etablierte Standardformate wie etwa das Harvest Summary Object Interchange Format
(SOIF, siehe Abschnitt 4.3.1) verwendet. Eine interessante Entwicklung, die den gesamten
Austausch von Dokumenten beeinflussen wird, ist die Extensible Markup Language
(XML, siehe Abschnitt 4.3.2). XML ist eine vereinfachte Variante von SGML3 und
ermöglicht es, verschiedenste Typen von Dokumenten im selben Format auszudrücken.
Die Datenübertragung kann wahlweise über SOIF oder über wohlgeformtes XML
erfolgen, wobei auch zukünftige Standards leicht zu implementieren sind.
Es gibt noch weitere Entwicklungen zu Metainformationen, auf die ebenfalls in diesem
Kapitel eingegangen wird. Den vielversprechendsten Ansatz zum Austausch von
Informationen über Dokumente bietet die Arbeit des World Wide Web Consortiums auf
dem Gebiet der Metadaten4, genannt Resource Description Framework (RDF, siehe
Abschnitt 4.3.4). RDF baut auf XML auf und befindet sich zum Zeitpunkt der Erstellung
dieser Arbeit in der Endphase der Entwicklung. Es wird zusammen mit der Platform for
Internet Content Selection (PICS, siehe Abschnitt 4.2.2) die Zukunft des World Wide Web
bestimmen. Auf der Basis von XML gibt es einen weiteren Ansatz, das Meta Content
Framework (MCF, siehe Abschnitt 4.3.3). MCF ist eine Entwicklung von Apple5 bzw.
Netscape6, die aber nicht mehr weiterverfolgt wird7.
4.1 HTML – Hypertext Markup Language
Ein Teil des Gestaltungsbereichs dieser Diplomarbeit ist ein Modul zum Extrahieren von
Informationen aus HTML-Dokumenten (siehe auch Kapitel 7 – Fehlertoleranter HTMLKonverter). Zur Erleichterung der korrekten Konfiguration dieses Moduls wird hier näher
auf den Aufbau der Hypertext Markup Language eingegangen (siehe Abschnitt 4.1.1).
HTML bietet auch die Möglichkeit, Metainformationen über ein Dokument im Dokument
selbst mitzuführen. Um möglichst relevante Suchergebnisse zu erreichen, ist es für
Suchdienste wichtig, auf diese Informationen zugreifen zu können, deshalb wurde auch im
HTML-Konverter ein Mechanismus zum Extrahieren dieser Metainformationen
implementiert. Der Aufbau dieser Metainformationen wird im Abschnitt 4.1.2 erläutert.
3
The SGML/XML Web Page, http://www.oasis-open.org/cover/general.html
4
W3C Metadata Activity, http://www.w3.org/Metadata/
5
Apple, http://www.apple.com
6
Netscape, http://www.netscape.com
7
Es gibt keine neueren Arbeiten auf diesem Gebiet. Die letzte Eingabe an das W3C
erfolgte am 6. Juni 1997, http://www.w3.org/TR/NOTE-MCF-XML/
KAPITEL 4 - FORMATE UND METADATEN
4.1.1
29
Kurzbeschreibung der Syntax
HTML ist eine SGML-Anwendung, die konform ist mit ISO 8879, der Standard
Generalized Markup Language [ISO8879]. Die HTML-Spezifikation liegt zum Zeitpunkt
der Erstellung dieser Diplomarbeit in der Version 4 des W3C vor und wurde als
Beschreibungssprache für Seiten im World Wide Web entwickelt. Nachfolgende
Beschreibung bezieht sich auf diese Arbeit. [HTML40]
Einzelne Elemente eines Dokuments werden durch spezielle Markup-Befehle von den
übrigen Teilen getrennt. Die Markup-Befehle8 werden vom normalen Text dadurch
unterschieden, daß sie zwischen spitzen Klammern, also zwischen Kleiner- und
Größerzeichen eingeschlossen werden, und zwar in der Form <TAG>. Manche dieser Tags
haben auch Parameter – genannt Attribute – wie in Listing 4.1 angegeben.
<TAG ATTRIBUTE1=value ATTRIBUTE2>
Listing 4.1: HTML-Tag mit Attributen und Werten
Bei Befehlen wie TAG und den Attributen ATTRIBUTE1 und ATTRIBUTE2 ist die Großoder Kleinschreibung egal, bei dem Wert "value" trifft dies nicht immer zu. Wenn die
Argumente Sonderzeichen enthalten oder zwischen Groß- und Kleinschreibung
unterschieden werden soll, müssen sie, wie in Listing 4.2 gezeigt, in Anführungszeichen
eingeschlossen werden:
<TAG ATTRIBUTE="Value">
Listing 4.2: Attributwert eines HTML-Tags mit gemischter Groß- und Kleinschreibung
Einfache oder mehrfache Leerstellen oder Zeilenwechsel wirken (von Spezialfällen wie
Text zwischen <PRE>- und </PRE>-Tags abgesehen) jeweils so wie eine Leerstelle, das
heißt man kann Text im HTML-Dokument optisch gliedern, ohne das Aussehen des
Dokuments im Browser zu ändern.
Die meisten HTML-Befehle treten paarweise auf, mit einem Start-Tag der Form <TAG>
und einem End-Tag der Form </TAG>. Diese Befehlspaare geben jeweils die Bedeutung
des dazwischen liegenden Textes an. So ist z.B. der zwischen <H1> und </H1> stehende
Text eine Überschrift, H steht für Heading, die englische Bezeichnung für Überschrift.
Manche HTML-Befehle treten einzeln auf, also ohne einen End-Tag. Sie bezeichnen
bestimmte Elemente, die zwischen dem Text stehen. So bedeutet z.B. <HR> eine
horizontale Linie zwischen zwei Absätzen. Bei manchen Elementen kann das End-Tag
auch weggelassen werden, was eine automatisierte Auswertung zusätzlich erschwert.
Paarweise HTML-Befehle müssen immer richtig geschachtelt werden. Dies soll an
folgendem Beispiel (Listing 4.3) durch das Einrücken der Eingabezeilen veranschaulicht
werden. Man sieht auch deutlich die Grundstruktur eines HTML-Dokuments. Durch die
Tags <HEAD> und <BODY> wird zwischen allgemeinen Informationen über das Dokument
8
Markup-Befehle werden im engl. Tag genannt.
KAPITEL 4 - FORMATE UND METADATEN
30
und den eigentlichen Inhalt unterschieden.
<HTML>
<HEAD>
<TITLE>Der Titel des HTML-Files</TITLE>
</HEAD>
<BODY>
<H1>Die Überschrift</H1>
<P>Der erste Absatz.</P>
<P>
Ein <EM>betontes</EM>
Wort im zweiten Absatz.
Nach diesem Absatz kommt eine Linie:
</P>
<HR>
<P>
Das ist der letzte Absatz.
</P>
</BODY>
</HTML>
Listing 4.3: Beispiel zur Struktur eines HTML-Dokuments
Mit einem HTML-Browser wie dem Navigator von Netscape oder dem Internet Explorer
von Microsoft sieht das Dokument aus Listing 4.3 etwa wie in Abbildung 4.1 aus, wobei
der Titel des Dokuments meist in der Titelleiste des Fensters angezeigt wird.
Abbildung 4.1: Ausgabe des Dokuments aus Listing 4.3 mittels HTML-Browser
KAPITEL 4 - FORMATE UND METADATEN
31
Nicht erlaubt sind in der HTML-Definition Verschränkungen von Tags, also etwa eine
Konstruktion wie in Listing 4.4 gezeigt.
<P>xxxxxx <EM>xxxx</P>
<P>xxxx</EM> xxxxxx</P>
Statt dessen müßte man schreiben:
<P>xxxxxx <EM>xxxx</EM></P>
<P><EM>xxxx</EM> xxxxxx</P>
Listing 4.4: Verschränkte HTML-Tags und korrigierte, HTML-konforme Version
In einigen Fällen darf das End-Tag weggelassen werden, so ist beispielsweise die
explizite Angabe von </P> wie in Listing 4.3 und Listing 4.4 nicht notwendig.
Ein spezielles Tag, daß keinerlei Auswirkungen auf das Aussehen des Dokuments im
Browserfenster hat, ist das Rufzeichen, das für Kommentare verwendet werden kann (siehe
Listing 4.5). Damit das Kommentar tatsächlich von allen Browser-Versionen ignoriert
wird, sollte der Text weder die Zeichenfolge “--“ noch das Zeichen “>“ enthalten.
<!-- Kommentartext -->
Listing 4.5: Kommentar in HTML-Dokumenten
Da die Datenübertragung im Internet noch immer nicht überall mit 8 Bit erfolgt gibt es
eine Reihe von Ausdrücken9, die es erlauben, auch Zeichen darzustellen, die sonst
eventuell nicht korrekt übertragen werden, etwa "Ä" für Ä oder "ß" für 'ß'.
Genauere Informationen zur aktuellen Spezifikation finden sich auf den Seiten des
World Wide Web Consortiums [HTML40]. Zusätzlich sei auf detaillierte Einführungen zu
HTML, wie beispielsweise [Münz1998], verwiesen.
4.1.2
Meta-Tags in HTML-Dokumenten
Meta-Angaben in HTML-Dokumenten helfen das Dokument näher zu beschreiben.
Diese Angaben können von Suchdiensten verwendet werden, um die Relevanz der
Suchergebnisse zu erhöhen (siehe Abschnitte 2.3.4 und 3.2.4). Auch der in der
vorliegenden Arbeit entwickelte HTML-Konverter (siehe Kapitel 7) ist in der Lage, diese
Metainformationen zu extrahieren, wobei in diesem Abschnitt der für die richtige
Konfiguration nötige Aufbau und Inhalt der Meta-Angaben näher erläutert werden soll.
Die Beschreibungssprache HTML schreibt keine konkreten Meta-Angaben mehr vor,
sondern definiert lediglich den grundsätzlichen Aufbau einer Meta-Angabe. Zur
Standardisierung von Meta-Angaben arbeitet das W3-Konsortium statt dessen am
Resource Description Framework (siehe auch Kapitel 4.2.2).
In Meta-Angaben können verschiedene nützliche Anweisungen für WWW-Server,
WWW-Browser und automatische Suchprogramme im Internet (siehe auch Abschnitt
9
Diese Ausdrücke werden in der engl. HTML-Spezifikation Entity genannt.
KAPITEL 4 - FORMATE UND METADATEN
32
2.1.1) notiert werden. Meta-Angaben können Angaben zum Autor und zum Inhalt der
Datei enthalten. Sie können aber auch HTTP-Befehle absetzen, zum Beispiel zum
automatischen Weiterleiten des WWW-Browsers zu einer anderen Adresse. Meta-Angaben
sind nicht für persönliche Anmerkungen oder Kommentare zum Quelltext der HTMLDatei gedacht. Für solche Angaben kann man einen Kommentar definieren (siehe auch
Abschnitt 4.1.1).
Nach einer Beschreibung der Syntax von Meta-Angaben in HTML-Dokumenten werden
einige nützliche Anwendungen von Metadaten aufgezählt.
4.1.2.1
Syntax von Meta-Tags in Dokumenten
Wie bereits im Abschnitt 4.1.1 beschrieben, arbeitet HTML mit Tags, die den Inhalt
bestimmter Teile eines Dokuments klassifizieren. Die Meta-Tags hingegen machen
Angaben über das gesamte Dokument, also über Inhalt, Autor, Erstellungsdatum, etc. Der
Inhalt der Meta-Tags wird nicht im Browser angezeigt, ist aber für einige Anwendungen –
vor allem für Suchdienste – sehr nützlich (siehe auch Abschnitt 2.3.4).
Begriffe im Meta-Tag können ganz normal geschrieben werden und man muß bei
Substantiven keine Groß- und Kleinschreibungsvarianten einfügen, denn Suchdienste
suchen entweder nach dem vom Benutzer groß geschriebenen Wort oder ignorieren bei der
Eingabe eines klein geschriebenen Wortes die Groß- und Kleinschreibung.
Meta-Angaben innerhalb eines HTML-Dokuments sollten in der <HEAD>-Sektion (siehe
Abschnitt 4.1.1) stehen und haben die im Listing 4.6 gezeigte Syntax.
<META NAME="Name" CONTENT="Wert des Elementes">
Listing 4.6: Meta-Tag mit den Attributen Name und Content
Erläuterung der Attribute:
NAME
Der Inhalt dieses Elementes ist der Name des zu beschreibenden
Elementes. Diese sind leider nicht standardisiert, es gibt aber allgemein
verwendete Angaben (siehe Kapitel 4.1.2.2).
CONTENT
Das <META>-Attribut CONTENT wird verwendet, um den "Wert" des
Elementes zu beschreiben.
Zusätzliche können folgende Attribute verwendet werden:
HTTP-EQUIV
Dieses Attribut wird anstelle des Name-Attributes verwendet. HTTP
Server verwenden dieses Attribut, um Informationen für HTTP zu kodieren und senden den Inhalt (CONTENT) im Header der HTTP Antwort.
LANG
Sprachkennzeichnung basierend auf [RFC1766], Tags zur Identifikation
von Sprachen (siehe auch Abschnitt 4.1.2.4).
KAPITEL 4 - FORMATE UND METADATEN
33
Dieses Attribut benennt das Schema10, das zum interpretieren des Wertes
verwendet wird, wie z.B. im Listing 4.7.
SCHEME
<META scheme="ISBN" name="identifier" content="0-8230-2355-9">
Listing 4.7: Beispiel für ein HTML 4.0 Meta-Tag mit Angabe eines Schemas
4.1.2.2
Häufig verwendete Meta-Tags
Da es keine einheitlichen Vorgaben gibt, folgt eine Auflistung von Tags, die von den
meisten Suchdiensten ausgewertet werden [VWP1999]:
Content Type
Dieses Meta-Tag definiert die Art der Datei und den Zeichensatz, der im Dokument
verwendet wird. Listing 4.8 zeigt z.B. Text im HTML-Format mit europäischem
Zeichensatz. Der Inhalt wird im HTTP-Header bei der Weitergabe der Daten vom
Webserver zum Browser übertragen. Moderne Server und Browser werten dieses Tag aus
und stellen automatisch die Umlaute und Sonderzeichen richtig dar; sie müssen nicht im
Quelltext durch spezielle Namen (Entities, siehe Abschnitt 4.1.1) codiert werden.
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;
charset=iso-8859-1">
Listing 4.8: Meta-Tag zur Beschreibung des Content-Typs eines Dokuments
Keywords
Keywords sind die Schlüsselworte zum Inhalt des Dokuments, also zentrale Begriffe
einzelner Seiten bzw. des ganzen Projektes (Beispiel siehe Listing 4.9). Manche
Suchdienste werten vor allem dieses Tag aus. Die einzelnen Worte werden durch
Kommata getrennt, ganze Phrasen lassen sich zwischen zwei Kommata mit normalen
Leerzeichen eintragen. Dieses Tag wurde oft verwendet, um mittels Keyword-Spamming,
also mehrfacher Auflistung häufig gesuchter Begriffe, die Plazierung des Dokuments im
Suchergebnis zu verfälschen.
<META name="keywords" content="Schlagwort1, Schlagwort2,
Noch ein Schlagwort, Phrase aus vier Worten">
Listing 4.9: Meta-Tag zur Beschreibung von Schlüsselwörtern eines Dokuments
10
Das Attribute Scheme gilt nur für HTML 4.0.
KAPITEL 4 - FORMATE UND METADATEN
34
Description oder Abstract
Diese Beschreibung des Dokumenteninhalts (siehe Listing 4.10) wird oft als Suchergebnis
ausgegeben. Umlaute im Beschreibungstext sind fast überall zulässig, wenn vorher des
Meta-Tag Content-Type eingefügt wurde.
<META NAME="description" CONTENT="Beschreibung der Seite mit zwei
bis drei Sätzen und circa 250 Zeichen. Das ist in etwa die Menge
Text, die von Suchdiensten als Suchergebnis angezeigt wird.">
Listing 4.10: Meta-Tag mit kurzer Beschreibung eines Dokuments
Language
Dieses Tag gibt die im Dokument verwendete Sprache an wie beispielsweise im Listing
4.11 für Deutsch. Analog lassen sich auch andere Sprachen nach [RFC1766] auswählen
und zwar mit Buchstabencodes nach [ISO639] wie "en" für Englisch oder "fr" für
Französisch.
<META HTTP-EQUIV="Language" CONTENT="de">
Listing 4.11: Meta-Tag mit Angabe der im Tag verwendeten Sprache
Autor
Angaben zum Autor des Dokuments (siehe Listing 4.12).
<META NAME="author" CONTENT="Bernhard Knögler">
Listing 4.12: Meta-Tag mit Angabe des Autors
Copyright
Hier kann, wie in Listing 4.13 gezeigt, explizit auf das Copyright aufmerksam gemacht
werden.
<META NAME="copyright" CONTENT="Die Nachrichtenagentur">
Listing 4.13: Meta-Tag mit Angaben zum Copyright
Robots
Mit diesem Tag können Suchrobots genaue Hinweise gegeben werden, wie das Dokument
zu behandeln ist (siehe Kapitel 2.1.1 – Informationsauffindung und Aufbereitung). Leider
wird dieses Tag nur von wenigen Robots ausgewertet. Die Seite kann vom Index
ausgeschlossen ("noindex") oder eingeschlossen ("index") werden. Mit dem Parameter
"nofollow" wird der Robot angewiesen, den in der Seite enthaltenen Links nicht weiter zu
folgen, "follow" verhindert weiteres indizieren. Die Parameter können, wie in Listing 4.14
KAPITEL 4 - FORMATE UND METADATEN
35
gezeigt, auch zusammengefaßt werden.
<META name="robots" content="noindex">
<META name="robots" content="nofollow">
<META name="robots" content="index, follow">
Listing 4.14: Meta-Tags zur Beeinflussung von Robots
Besonders Frames und Steuerseiten sollen oft zwar nicht indiziert, aber die Links verfolgt
werden. Die Tags werden daher wie in Listing 4.15 entsprechend kombiniert.
<META name="robots" content="noindex, follow">
Listing 4.15: Meta-Tag für Robots zur richtigen Indizierung von Frames
Zwischenspeicherung
Dieses Tag verhindert das Zwischenspeichern von Seiten auf Proxyservern 11. Es macht nur
Sinn bei Seiten, die sehr häufig, stündlich oder täglich aktualisiert werden wie Newsseiten
oder Diskussionsforen.
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
Listing 4.16: Meta-Tag zur Verhinderung der Zwischenspeicherung auf Proxyservern
Die folgenden Meta-Angaben sind wenig verbreitet und werden auch von den meisten
Suchdiensten nicht ausgewertet:
Publisher
Der Autor eines Dokuments ist nicht immer auch derjenige, der das Dokument auch
veröffentlicht. Als Herausgeber können Verlags- und Firmennamen, die Forschungseinrichtung oder Universität, wie in Listing 4.17, vermerkt sein.
<META NAME="publisher" CONTENT="IICM, TU-Graz">
Listing 4.17: Meta-Tag mit Angaben zum Herausgeber
Page-topic
Hier kann das Thema des Dokuments anhand eines Schlagwortes eingegrenzt werden. Das
Thema entspricht in etwa der Kategorie bei Suchverzeichnissen. Leider gibt es hier keine
Standards, so daß eine maschinelle Auswertung nicht möglich ist. Mehrfacheinträge sind
11
Server, über den bestimmte Rechner auf das World Wide Web zugreifen anstatt die
Dokumente direkt anzufordern. Zur Beschleunigung werden oft häufig aufgerufene
Dokumente auf dem Server zwischengespeichert. [SM98]
36
KAPITEL 4 - FORMATE UND METADATEN
möglich, wie in Listing 4.18 gezeigt.
<META NAME="page-topic" CONTENT="Medien, Bildung, Wissenschaft">
Listing 4.18: Meta-Tag mit Angaben zum Thema des Dokuments
Page-type
Angaben zum Typ des Dokuments, beispielsweise Anleitung, Fragensammlung, Katalog,
Verzeichnis, Anzeige etc. (siehe Listing 4.19). Eine Standardisierung gibt es auch hier
nicht.
<META NAME="page-type" CONTENT="FAQ, Beschreibung,
Anleitung">
Listing 4.19: Angaben zum Typ des Dokuments
Audience
Hier wird die Zielgruppe festgelegt. Mehrfacheinträge, wie in Listing 4.20 gezeigt, sind
möglich. Auf dem Suchserver12 des European Schoolnet13 befindet sich eine Liste mit
Vorschlägen für Zielgruppen, die mit dem schulischen Bereich zu tun haben. Es sind dies
"any", "all user groups", "adminstrative staff of all kind", "parents", "pupil or student",
"tutor", "teacher" und "person involved in the production and distribution of teaching
material".
<META NAME="audience" CONTENT="Studenten, Anfänger, Kinder">
Listing 4.20: Meta-Tag mit Angaben zur Zielgruppe
4.1.2.3
Beispiel eines HTML-Dokumentes mit Meta-Tags
Die in der Head-Sektion aufgeführten Meta-Tags sind leider in den wenigsten HTMLDokumenten des World Wide Web zu finden. Ein positives Beispiel für die Anwendung
von Meta-Tags ist zeigt die Homepage der Olympischen Winterspiele 1998 in Nagano, da
praktisch alle wichtigen Meta-Tags verwendet wurden. In Listing 4.21 sieht man einen
Auszug der Homepage.
<META NAME="title" CONTENT="1998 Olympic Winter Games Homepage,
Nagano Japan - English">
<META NAME="language" CONTENT="EN">
<META http-equiv="PICS-Label" content='(PICS-1.0
"http://www.rsac.org/ratingsv01.html" l gen true comment "RSACi
North America Server" by "[email protected]" for on
"1996.04.04T08:15-0500" r (n 0 s 0 v 0 l 0)
12
EUN Search Engine, http://mother.lub.lu.se/EUN/
13
European Schoolnet, EUN, http://www.eun.org
KAPITEL 4 - FORMATE UND METADATEN
37
"http://www.classify.org/safesurf/" l by "[email protected]" r
(SS~~000 1) )'>
<META NAME="owner" CONTENT="[email protected]">
<META NAME="Reply-To" CONTENT="[email protected]">
<META NAME="security" CONTENT="public">
<META NAME="robots" CONTENT="none">
<META NAME="abstract" CONTENT="Official Olympic Winter Games Site
Nagano 1998 Powered by IBM - Experience the 1998 Winter Olympics
online! Games held from February 7-22 in Nagano, Japan. This
official Web site is the most current source for live results,
sports schedules, venue and travel details, latest news, profiles
of the participating athletes and countries, photos and video
clips, and more. Kids submit email, send postcards and play Snowlet
games. Presented by The Organizing Committee for the XVIII Olympic
Winter Games, Nagano (NAOC) and IBM. All content in both English
and Japanese. News Articles also available in French.">
<META NAME="description" CONTENT="Experience the 1998 Olympic
Winter Games in Nagano, Japan! Official site by IBM offers live
results for 68 events and nearly 3,000 athletes. In Japanese and
English.">
<META NAME="keywords" CONTENT="olympics Olympics OLYMPICS olympic
Olympic OLYMPIC japan Japan JAPAN nagano Nagano NAGANO winter
Winter WINTER games Games GAMES sport sports official results naoc
NAOC ibm IBM web site website homepage hockey figure skate skating
bobsled bobsleigh speed short track jumping ski skiing downhill
curling luge biathlon cross-country nordic combined alpine ice snow
snowboard snowboarding freestyle slalom giant snowlets video audio
realaudio pictures photography news kids venues countries 1998 98
xviii">
<META NAME="alias" CONTENT="http://www.nagano.olympic.org">
Listing 4.21: Meta-Tags der Homepage der Olympischen Winterspiele 1998
Im World Wide Web ist auch eine Anzahl Generatoren für Metadaten verfügbar, also
Formulare, in die man die gewünschten Daten eingibt und als Ergebnis HTML-SourceCode erhält. Anbieter sind etwa der Suchdienst Fireball14 oder die Suchfibel15, eine
Anleitung zur richtigen Verwendung heutiger Suchmaschinen.
4.1.2.4
Spezifikation der verwendeten Sprache
In HTML 4.0 gibt es eine neues Attribut, mit dem die verwendete Sprache angegeben
werden kann. Dieses Attribut kann für Meta-Angaben zu Schlüsselwörtern (siehe auch
Listing 4.22) oder bei solchen zur Kurzbeschreibung des Inhalts verwendet werden, um
mehrere gleichartige Angaben unter Verwendung verschiedener Landessprachen zu
machen. [HTML40]
14
Fireball Metadaten Generator, http://www.fireball.de/metagenerator_s.html
15
Suchfibel Metadaten Generator, http://www.suchfibel.de/6gefundn/6frame7.htm
38
KAPITEL 4 - FORMATE UND METADATEN
<HTML>
<HEAD>
<META
<META
<META
<META
...
NAME="keywords"
NAME="keywords"
NAME="keywords"
NAME="keywords"
LANG="de" CONTENT="Ferien, Griechenland">
LANG="en-us" CONTENT="vacation, Greece">
LANG="en" CONTENT="holiday, Greece">
LANG="fr" CONTENT="vacances, Grèce">
Listing 4.22: Beispiel für mehrsprachige Schlüsselwörter in einem HTML-Dokument
Im Beispiel werden die gleichen Stichwörter in den Sprachen Deutsch, US-Englisch,
Britisch-Englisch und Französisch definiert. Dabei wird das Attribut "LANG" benutzt, um
die Sprache anzugeben, wobei es zu den Universalattributen von HTML gehört. Als
Angabe ist ein zweistelliges Landeskürzel erlaubt16, z.B. "de" für deutsch, "en" für
englisch, "fr" für französisch, "it" für italienisch oder "es" für spanisch. Weitere
Informationen sind in den Arbeiten [RFC1766] und [ISO639] zu finden.
4.1.2.5
Automatische Weiterleitung zu einer anderen Adresse
(Forwarding)
Für das automatisierte Weiterleiten eines Anwenders von einer URL zu einer anderen
kann man das automatische Laden eines weiteren Dokuments veranlassen. Trifft ein
WWW-Browser auf einen Ausdruck wie in Listing 4.23, dann lädt der Browser nach dem
angegebenen Timeout die gewünschte Datei [HTML40]:
<HTML>
<HEAD>
<META HTTP-EQUIV="refresh" CONTENT="5;
URL=http://www.rechner.at/zielseite/">
...
</HEAD>
...
Listing 4.23: HTML-Text zum automatischen Weiterleiten von Browsern
Mit "CONTENT" bestimmt man die Anzeigedauer der aktuellen Seite in Sekunden. Die
5 in Listing 4.23 bedeutet, daß die Datei fünf Sekunden lang angezeigt wird. Danach wird
die nächste Datei aufgerufen, die mit "URL=..." spezifiziert wird. Bei einem Timeout von
0 wird das angegebene Dokument sofort geladen.
16
Ausnahme für USA: en-us
KAPITEL 4 - FORMATE UND METADATEN
39
4.2 Standardisierte Metadaten
Metadaten können von Suchdiensten dazu benutzt werden, relevantere Suchergebnisse
zu erzielen (siehe Abschnitt 2.3.4). Mit dem im Gestaltungsteil entwickelten HTMLKonverter (siehe auch Kapitel 7) können diese Metainformationen aus HTML-Dokumenten extrahiert werden, wobei in diesem Abschnitt auf heute verwendeten Formate näher
eingegangen wird. Dublin Core (siehe Abschnitt 4.2.1) definiert 15 Elemente wie Autor
und Publisher zur Ressourcenbeschreibung. PICS (siehe Abschnitt 4.2.2), ein Framework
zur Filterung von Internet-Inhalten wurde entwickelt, um jugendfreie Dokumente als
solche auszuzeichnen. LOM (siehe Abschnitt 4.2.2) definiert Standards und Vorschläge für
computerimplementierte Ausbildungs- und Trainingskomponenten.
4.2.1
DC - Dublin Core Metadata Element Set
Im Rahmen der Strukturierung von Metadaten hat es in den letzten Jahren eine Reihe
von Initiativen gegeben, von denen das sogenannte Dublin Core Metadata Element Set
nicht nur am bekanntesten ist, sondern in der internationalen Diskussion auch eine immer
größere Rolle spielt und inzwischen sicherlich zum am meisten diskutierten Ansatz
geworden ist. Dieses Metadatenmodell ist seit 1995 in interdisziplinärem Konsens
zwischen Informatikern, Wissenschaftlern und Bibliothekaren gewachsen und besteht
derzeit aus 15 Elementen zur Ressourcenbeschreibung [DCInf1998]. Es ist bewußt einfach
gehalten, damit die Produzenten von Dokumenten die entsprechenden Metadaten
gegebenenfalls selber generieren können, ohne dabei notwendigerweise auf aufwendige
und damit teure Verfahren durch geschultes Personal zurückgreifen zu müssen. Insgesamt
stellt die Dublin-Core-Initiative eine ambitionierte Reaktion auf die Herausforderung durch
das World Wide Web dar und bietet in Kombination mit XML und RDF einen
zukunftsweisenden Ansatzpunkt für eine verbesserte Informationssuche im Internet (siehe
auch Dublin Core Metadata Initiative17).
Neben dem Dublin-Core-Schema gibt es noch eine Vielzahl von weiteren Metadatenformaten, z.B. die Text Encoding Initiative18 oder Government Information Locator
Service19, die entweder an fachspezifischen Erschließungsanforderungen (etwa die Content
Standards for Digital Geospatial Metadata in den Geowissenschaften oder die Metadaten
bei IEEE20, dem Institute of Electrical and Electronic Engineers) oder an komplexeren
bibliothekarischen Regelwerken (etwa PICA21 oder die verschiedenen MARC-Formate22
wie MARC, UNIMARC, USMARC etc.) ausgerichtet sind. Gegenüber diesen Varianten
steht hinter dem Dublin-Core-Ansatz der Versuch, ein kostengünstiges, leicht handhab17
Dublin Core Metadata Initiative, http://purl.org/dc/
18
Text Encoding Initiative, TEI, http://www.uic.edu/orgs/tei/
19
Government Information Locator Service, GILS, http://www.usgs.gov/gils/
20
IEEE Metadata Info Page, http://www.llnl.gov/liv_comp/metadata/index.html
21
Project for Integrated Catalogue Automation, PICA, http://www.pica.nl/en/
22
Machine-Readable Cataloging, MARC, http://lcweb.loc.gov/marc/
KAPITEL 4 - FORMATE UND METADATEN
40
bares und doch wirkungsvolles Verfahren zu entwickeln, das auch vor der großen Zahl an
Dokumenten in elektronischen Netzen nicht kapitulieren muß. Weiterhin wird darauf
geachtet, daß die Anbindung an andere, zumeist komplexere Formate möglich ist. Dazu
wurde nicht nur die sogenannte Warwick-Framework-Architektur23 entwickelt, sondern es
wird auch verstärkt an Konvergenzen (Mappings und Crosswalks) zu anderen Formaten
gearbeitet. Das World Wide Web Consortium ist während der Erstellung der vorliegenden
Diplomarbeit dabei, das Warwick-Framework in das Resource Description Framework
(RDF, siehe auch Abschnitt 4.3.4) zu integrieren. [DCInf1998]
4.2.1.1
Einbindung der Dublin Core Basiselemente in HTML
Dublin Core umfaßt 15 Elemente, die auch in HTML verwendet werden können
[DCEl1996]. Die HTML-Spezifikationen sind generell, d.h. innerhalb von HTML-Texten
können auch andere Metadaten Sets eingebracht werden. Listing 4.24 zeigt einen Dublin
Core Eintrag in allgemeiner Darstellung innerhalb eines HTML-Dokuments. [HTML40]
<META NAME="DC.Element Name" CONTENT="Wert des Elementes">
Listing 4.24: Meta-Tag mit allgemeinem Dublin Core Eintrag in HTML
Die DC Syntax eines Elementes kann wie folgt beschrieben werden, wobei das HTMLElement <META> mit den Attributen Name und Content verwendet wird:
NAME
Der Inhalt dieses Elementes besteht aus der Kennung "DC." für Dublin
Core als Metadaten und dem Elementnamen wie z.B. "DC.TITLE".
CONTENT
Das <META>-Attribut CONTENT wird verwendet, um den "Wert" des
Elementes zu beschreiben, wie etwa:
<META .... CONTENT="Ein DC Metadaten-Eintrag">
Optional kann zusätzlich das <LINK>-Tag angegeben werden (siehe Abschnitt 4.2.1.2).
Es definiert, welches Schema (SCHEME) verwendet wurde und enthält die URL zur
Referenz-Dokumentation des benutzten Schemas. Die <META>-Elemente sind in das
HTML-Dokument eingefügt, und zwar innerhalb die <HEAD> und </HEAD>-Elemente.
Die in HTML 4.0 zusätzlich definierten Attribute für <META> haben bei Verwendung
von Dublin Core folgende Funktionen:
SCHEME
Dieses Attribut benennt das Schema, das zum interpretieren des Wertes
verwendet wird und ersetzt die zusätzliche Angabe des <LINK>-Elementes.
LANG
Sprachkennzeichnung basierend auf [RFC1766], Tags zur Identifikation
von Sprachen.
23
The Warwick Framework, http://www.dlib.org/dlib/july96/lagoze/07lagoze.html
KAPITEL 4 - FORMATE UND METADATEN
4.2.1.2
41
Beispiel eines HTML-Dokuments mit Dublin Core
Ein gutes Beispiel für die Verwendung von Dublin Core Elementen in HTML-Dokumenten gibt Listing 4.25. Es zeigt ein HTML 3.2-Dokument mit fast allen festgelegten
Dublin Core Angaben bis auf Coverage, Relation und Source. Eine vollständige Liste aller
möglichen Elemente zeigt Tabelle 4.1.
<HTML><HEAD><TITLE>Dublin Core Metadata Template</TITLE>
<META NAME="DC.Date.X-MetadataLastModified"
CONTENT="(SCHEME=ISO8601) 1997-12-01">
<LINK REL=SCHEMA.dc
HREF="http://purl.org/metadata/dublin_core_elements#date">
<META NAME="DC.Title" CONTENT="Dublin Core Metadata Template
(Nordic Metadata Project)">
<META NAME="DC.Creator.PersonalName" CONTENT="Koch, Traugott">
<META NAME="DC.Creator.PersonalName.Address" CONTENT="[email protected]">
<META NAME="DC.Creator.PersonalName.2" CONTENT="Borell, Mattias">
<META NAME="DC.Creator.PersonalName.Address.2"
CONTENT="[email protected]">
<META NAME="DC.Subject" CONTENT="Dublin Core">
<META NAME="DC.Subject" CONTENT="Nordic Metadata Project">
<META NAME="DC.Subject" CONTENT="Metadata template">
<META NAME="DC.Description" CONTENT="This service is provided by
the Nordic Metadata Project in order to asure good support for the
creation of Dublin Core metadata to the Nordic "Netpublisher" community. If you use the metadata created by this
form and follow our examples, term lists and recommendations, your
HTML documents will carry high quality metadata. To demonstrate the
usefulness of providing metadata, the "Nordic Web Index"
will properly index your page when published. The result: your
pages will be found more easily and correct.">
<META NAME="DC.Publisher" CONTENT="Nordic Metadata Project">
<META NAME="DC.Publisher.Address"
CONTENT="http://linnea.helsinki.fi/meta/">
<META NAME="DC.Contributor.PersonalName" CONTENT="Berggren">
<META NAME="DC.Date" CONTENT="(SCHEME=ISO8601) 1997-12-01">
<META NAME="DC.Type" CONTENT="Text.Form">
<META NAME="DC.Format" CONTENT="(SCHEME=IMT) text/html">
<LINK REL=SCHEMA.dc
HREF="http://purl.org/metadata/dublin_core_elements#format">
<LINK REL=SCHEMA.imt
HREF="http://sunsite.auc.dk/RFC/rfc/rfc2046.html">
<META NAME="DC.Identifier"
CONTENT="http://www.lub.lu.se/metadata/DC_creator.html">
<META NAME="DC.Language" CONTENT="(SCHEME=ISO639-1) en">
<META NAME="DC.Rights" CONTENT="Copyright">
</HEAD><BODY><H2>Dublin Core Metadata Template</H2>
<P>This service is provided by the <A
HREF="http://linnea.helsinki.fi/meta/">"Nordic Metadata
Project"</A> in order to assure good support for the creation of
Dublin Core metadata to the Nordic "Net-publisher" community.</P>
<P>Created: 1997-09-26<BR>Last update: 1998-03-17</P>
URL: http://www.lub.lu.se/metadata/DC_creator.html<BR>(C) Copyright
</BODY></HTML>
Listing 4.25: Beispiel eines HTML 3.2-Dokuments mit Dublin Core Angaben
KAPITEL 4 - FORMATE UND METADATEN
42
Tabelle 4.1 gibt eine Übersicht der im Dublin Core festgelegten Elemente [DCInf1998]:
Element
Beschreibung
Title
Titel des Dokuments, ähnlich des <TITLE>-Tags von
HTML.
Creator
Geistiger Urheber des Dokuments.
Subject
Thema, das im Dokument behandelt wird.
Description
Kurzbeschreibung des Inhalts.
Publisher
Angabe, wer für die Publikation des Dokuments
verantwortlich ist. Das kann der Autor selbst sein oder etwa
ein Verlag oder Nachfahre eines verstorbenen Autors.
Contributer
Co-Autoren, mehrere Angaben werden durch Komma
getrennt.
Date
Publikationsdatum und –zeit des Dokuments.
Type
Dokumententyp bzw. Textsorte.
Format
Datenformat bzw. Medientyp
Identifier
Eindeutige Nummer oder Bezugsadresse des Dokuments,
beispielsweise die URL.
Source
Quelle, von der die Datei abgeleitet ist.
Language
Landessprache, in der der Inhalt der Datei verfaßt ist. Kürzel
nach [RFC1766] sind möglich.
Relation
Beziehung zwischen dem aktuellem Dokument und einem
zugehörigen Editionsprojekt.
Coverage
Zeitlicher oder geographischer Bezugspunkt für den Inhalt
des Dokuments. Das kann bei geographischen Angaben etwa
ein Ort, eine Längen-/Breitengradangabe oder eine Region
sein, bei zeitlichen Angaben ein Datum oder ein Zeitalter.
Rights
Angabe zum Copyright des Dateiinhalts. Dabei kann auch
eine Internet-Adresse angegeben werden, auf der die genauen
Copyright-Angaben genannt werden.
Tabelle 4.1: Übersicht der in Dublin Core definierten Elemente
Im Rahmen der Metadaten-Aktivitäten des W3C wird daran gearbeitet, auch die Dublin
Core Spezifikationen im Resource Description Framework ausdrücken zu können und
diese so weiter zu verallgemeinern und zu standardisieren. [DCInf1998]
KAPITEL 4 - FORMATE UND METADATEN
4.2.2
43
LOM – Learning Object Metadata
LOM ist ein Projekt des IEEE Learning Technology Standards Committee (P1484)24,
einer Untergruppe des IEEE Computer Society Standards Activity Board25 und befindet
sich zum Zeitpunkt der Erstellung der Diplomarbeit in der Entwicklung. Die Spezifikation
liegt offiziell als Draft Document v2.5a26 vor, die Spezifikation aller Elemente des
Basisschemas als Version 3.527. Das Ziel des LTSC die Entwicklung von technischen
Standards, Vorschlägen für Programme und Hilfsmittel, Technologien und Designmethoden, welche die Entwicklung, Verbreitung, Wartung und Zusammenarbeit computerimplementierter Ausbildungs- und Trainingskomponenten erleichtern sollen.
Der Standard spezifiziert die Syntax und die Semantik der Learning Object Metadata
und definiert die benötigten Attribute um ein sogenanntes Learning Object vollständig zu
beschreiben. Learning Objects sind alle möglichen Objekte, digital oder nicht-digital, die
während technologieunterstützten Lernens benützt werden können. Beispiele dafür sind
rechnergestützte Trainingssysteme, interaktive Lernumgebungen, intelligente computerunterstützte Systeme für Anleitungen, örtlich entfernte Lernsysteme (Tele-Learning) und
gemeinschaftliche Lernumgebungen. Beispiele für Learning Objects sind Multimediainhalte, Anleitungen, Lernsoftware und Software-Hilfsmittel sowie Personen, Organisationen oder auch die Fälle, die während des technologieunterstützten Lernens angesprochen werden. Der Standard konzentriert sich auf die minimale Anzahl an Attributen, die
benötigt werden, um Learning Objects handhaben, lokalisieren und auswerten zu können.
[LOMWG]
Die grundlegenden Felder und Entitätstypen sind lokal erweiterbar, wobei die Felder den
Status obligatorisch oder optional haben können. Relevante Attribute der Learning Objects
umfassen Objekttyp, Autor, Besitzer, Konditionen für die Verteilung und das Format.
Wenn nötig können auch pädagogische Attribute wie Art des Unterrichts, Schwierigkeit
und Voraussetzungen inkludiert werden. Ein Objekt kann auch mehrere Sets von Learning
Object Metadaten haben. Der Standard will Sicherheit, Privatsphäre, Handel und
Auswertungen unterstützen, aber nur soweit, daß Metadatenfelder für beschreibende
Attribute zur Verfügung stehen und nicht, wie diese Features implementiert werden.
[LOMWG]
24
IEEE Learning Technology Standards Committee, LTSC
http://grouper.ieee.org/groups/ltsc/index.html oder
http://www.manta.ieee.org/p1484/index.htm
25
IEEE Computer Society Standards Activities Board
http://www.computer.org/standard/
26
LOM Draft Document v2.5a, 23. Dezember 1998,
http://ltsc.ieee.org/doc/wg12/LOMdoc2_5a.doc
27
LOM Base Scheme v3.5, 15. Juli 1999, http://ltsc.ieee.org/doc/wg12/scheme.html
KAPITEL 4 - FORMATE UND METADATEN
44
Ziele des Projektes
Das LTSC hat sich die mehrere Ziele gesetzt, die mit diesem Standard verwirklicht werden
sollen [LOMWG]:
 Suche, Evaluierung und Verwendung von Learning Objects für Lernende und Lehrer.
 Austausch und gemeinsame Nutzung von Learning Objects über jede mögliche
Technologie hinweg.
 Entwicklung von Lerneinheiten, die kombiniert und zerlegt werden können.
 Möglichkeiten für automatische Agenten um dynamisch persönliche Lektionen
individuell erstellen zu können.
 Unterstützung für andere Standards, die Learning Objects in einem offenen verteilten
Lernsystem implementieren.
 Ermöglichung aller Arten der Verteilung von Learning Objects (non-profit und profit).
 Unterstützung notwendiger Sicherheits- und Authentifizierungsmechanismen zur
Verteilung und Benützung von Learning Objects.
 Standards, die die gemeinsame Nutzung von vergleichbaren Daten über Anwendbarkeit
und Effektivität von Learning Objects ermöglichen.
 Definition eines leicht auf mehrere Bereiche und Jurisdiktionen erweiterbaren
Standards, der einfach angenommen und verwendet werden kann.
 Möglichkeiten für Ausbildungs- und Trainingsorganisationen, um Lehrinhalte in einem
standardisierten, vom Inhalt unabhängigen Format anbieten zu können.
Informationen über den aktuellen Stand der Entwicklung können über die Web-Site des
IEEE Learning Technology Standards Committee (P1484) Gruppe 12 28, der Learning
Objects Metadata Working Group [LOMWG] erhalten werden.
4.2.3
PICS – Platform for Internet Content Selection
PICS steht für "Platform for Internet Content Selection". Es handelt sich dabei um ein
standardisiertes Schema zum Bezeichnen von Internet-Inhalten. Das Schema wurde ins
Leben gerufen, um jugendfreie Internet-Inhalte als solche auszuzeichnen bzw. bestimmte
unerwünschte Inhalte auf Browser-Seite auszufiltern. Die Auszeichnungen werden PICSLabels genannt. Anbieter von WWW-Seiten können ihre WWW-Seiten entweder freiwillig
und nach eigenem Ermessen mit einem PICS-Label versehen, oder sie nehmen einen
unabhängigen PICS-Service in Anspruch, der PICS-Zertifikate für Inhalte ausstellt. [PICS]
[Dys1997]
Auf Einzelheiten des PICS-Systems wird hier nicht näher eingegangen. Informationen
findet man auf der PICS-Seite des W3-Konsortiums29. Moderne Browser30 können PICS28
IEEE Learning Technology Standards Committee Gruppe 12 ,
http://ltsc.ieee.org/wg12/index.html
29
Platform for Internet Content Selection , PICS, http://www.w3.org/PICS/
30
Microsoft Internet Explorer, IE, http://www.microsoft.com/windows/ie/
IE3: http://calvin.ptloma.edu/~spectre/evaluweb/pics.html
KAPITEL 4 - FORMATE UND METADATEN
45
Inhalte erkennen. Dazu lassen sich software-seitig Einstellungen vornehmen, zum Beispiel
durch Eltern von surfenden Kindern. So kann der Browser bei Seiten mit PICS-Lables
durch Vergleichen der Konfiguration mit dem Label erkennen, ob der Inhalt angezeigt
werden darf oder nicht. PICS-Label können direkt in HTML-Dokumente eingebunden
werden, wie in Listing 4.26 gezeigt:
<META http-equiv="PICS-Label" content='
(PICS-1.1 "http://www.gcf.org/v2.5"
labels on "1994.11.05T08:15-0500"
until "1995.12.31T23:59-0000"
for "http://w3.org/PICS/Overview.html"
ratings (suds 0.5 density 0 color/hue 1))'>
Listing 4.26: Beispiel eines PICS-Meta-Eintrags in einem HTML-Dokument
In obigem Beispiel ist die PICS-Auszeichnung im <META>-Eintrag in der <HEAD>Sektion eines HTML-Dokuments untergebracht. Die gesamte PICS-Auszeichnung wird in
einfache Anführungszeichen gesetzt und innerhalb runder Klammern eingeschlossen.
Zunächst steht die Pflichtangabe zur PICS-Version und die Angabe der URL-Adresse, wo
die Inhaltskategorisierung definiert wird, auf die hier Bezug genommen wird. Die Angaben
"labels on", "until" und "for" sind optional. Entscheidend ist aber auf jeden Fall die Angabe
"ratings", in der die eigentliche Inhaltskategorisierung notiert wird. Die Kategorisierung
wird dabei nochmals in runde Klammern eingeschlossen. Die einzelnen Befehle und ihre
Bedeutung muß der PICS-Service bereitstellen, der die PICS-Zertifikate verteilt.
[Dys1997]
Im Rahmen der Metadaten-Aktivitäten des W3C31 wird daran gearbeitet, auch die PICS
Spezifikationen im Resource Description Framework ausdrücken zu können und diese so
ebenfalls weiter zu verallgemeinern und zu standardisieren. [PICS]
IE4: http://calvin.ptloma.edu/~spectre/evaluweb/pics-ie4.html
IE5: http://www.microsoft.com/windows/ie/ratings.asp
Netscape Communicator, NS, http://home.netscape.com/de/download/index.html
NS4.05: http://home.netscape.com/de/newsref/pr/newsrelease588.html
31
W3C Metadata Activity, http://www.w3.org/Metadata/Activity.html
46
KAPITEL 4 - FORMATE UND METADATEN
4.3 Metadatenformate zum Datenaustausch
Ein Teilprogramm im Gestaltungsbereich dieser Diplomarbeit dient zur Weitergabe von
Informationen über Objekte – wie z.B. HTML-Dokumente – für verteilte Suchdienste, also
hierarchisch übergeordnete Module. Die Daten sollen in einem einheitlichen Format
übertragen werden, wobei es verschiedene Möglichkeiten gibt. In den folgenden
Abschnitten werden daher Formate wie etwa das schon etablierte SOIF (siehe Abschnitt
4.3.1) beschrieben. Eine weitere Möglichkeit ist MCF (siehe Abschnitt 4.3.3), das sich aber
nicht durchgesetzt hat. Den vielversprechendsten Ansatz bietet RDF, eine Arbeit des W3C
(siehe Abschnitt 4.3.4). Die Definition von SOIF beschreibt Syntax und Semantik von
Metainformationen, wobei RDF und MCF auf XML als Grundlage aufbauen. Abschnitt
4.3.2 gibt deshalb einen Einblick in die Struktur von XML.
4.3.1
SOIF – Harvest Summary Object Interchange
Format
Dieses Format wird vom Harvest-System und im Gestaltungsbereich der vorliegenden
Diplomarbeit zur Weitergabe von Metainformationen an hierarchisch übergeordnete
Suchdienste verwendet (siehe auch Kapitel 8). Harvest (siehe auch 3.4.1) ist eine
Sammlung von Modulen zum Sammeln, Extrahieren und Suchen von relevanten
Informationen im Internet. Das Harvest-System generiert eine Inhaltszusammenfassung
von jedem bearbeiteten Objekt und speichert diese in Form von Attribut-Wert-Paaren im
sogenannten Summary Object Interchange Format oder kurz SOIF. Die SOIF-Objekte
werden auch bei der Informationsweitergabe an übergeordnete Suchmaschinen verwendet.
Es ist möglich, mehrere Objekte seriell in einem sogenannten Stream zu übertragen.
[NK1994]
SOIF wurde wegen seiner Einfachheit oft verwendet, bietet aber nur wenige Möglichkeiten für Verallgemeinerungen. Das Summary Object Interchange Format ist nicht
standardisiert und obwohl es Erweiterungsversuche – wie beispielsweise SOIF 2 – gegeben
hat, haben sich diese nicht durchgesetzt. [Wes1995]
4.3.1.1
SOIF Beschreibung
SOIFSTROM
OBJEKT
ATTRIBUTWERT-LISTE
::=
::=
::=
ATTRIBUTWERT
TEMPLATE-TYPE
ATTRIBUTNAME
WERT
WERT-GRÖSSE
BEGRENZER
::=
::=
::=
::=
::=
::=
OBJEKT SOIFSTROM | OBJEKT
@TEMPLATE-TYPE { URL ATTRIBUTWERT-LISTE }
ATTRIBUTWERT ATTRIBUTWERT-LISTE |
ATTRIBUTWERT
ATTRIBUTNAME {WERT-GRÖSSE} BEGRENZER WERT
Alpha-Numerischer-String
Alpha-Numerischer-String
Beliebige-Daten
Zahl
":<tab>"
Listing 4.27: Formale Beschreibung des SOIF-Formates in BNF
KAPITEL 4 - FORMATE UND METADATEN
47
Wie aus Listing 4.27 ersichtlich, beinhaltet jedes SOIF-Objekt die URL des Dokuments,
also die eindeutige Adresse, unter der das Objekt erreichbar ist und eine Anzahl von
Attribut-Wert-Paaren. Nach dem Namen des Attributes steht die Länge des Inhalts. Dieses
Format enthält aber nicht nur eine Teilmenge der Informationen des Dokuments.
Unterschiedliche Zusatz- und Metainformationen können mit Hilfe der SOIF-Attribute
festgehalten werden. Welche Informationen als Attribut aufgenommen werden ist nicht
festgelegt, aber es gibt allgemein verwendete Bezeichner (siehe auch 4.3.1.2) um eine
weitere Verwendung der Daten zu ermöglichen. [HSW1996]
Das folgende Beispiel zeigt ein HTML-Dokument und eine Möglichkeit eines daraus
erzeugten SOIF-Objektes. Bei diesem Beispiel werden Metainformationen aus dem
HTML-Dokument direkt in ein entsprechendes SOIF-Attribut übernommen. Fett und
kursiv gekennzeichnete Wörter werden in ein Attribut namens Keywords übernommen,
ebenso werden Links auf andere Objekte im WWW (Bilder und Dokumente) berücksichtigt. Eine Erläuterung der vorkommenden Attribute im SOIF-Objekt ist im folgenden
Abschnitt 4.3.1.2 angegeben. Listing 4.28 zeigt ein ein HTML-Dokument und Listing 4.29
eine Möglichkeit eines daraus generierten SOIF-Objektes.
<HTML>
<HEAD>
<!-- Copyright (c) 1997, Verlag Heinz Heise -->
<TITLE>Das neue Ermaechtigungsgesetz</TITLE>
<META Name="author" Content="Artur P. Schmidt, Otto E. Roessler">
</HEAD>
<BODY>
<H1>Das neue Ermaechtigungsgesetz</H1>
<IMG SRC="/Bilder/eu.jpg">
<B>ENFOPOL oder die Entmuendigung der Buerger</B>
Es geht ein neues Gespenst um in Europa, ein Ermaechtigungsgesetz
zur Entmuendigung der Buerger. Das Papier heisst
<A
HREF="http://www.heise.de/tp/deutsch/special/enfo/6332/1.html">
ENFOPOL</A> und wurde am 03. September vom Rat der
<B>Europaeischen Union</B> als Entwurf verabschiedet.
</BODY>
</HTML>
Listing 4.28: HTML-Dokument als Beispiel zur Umwandlung in SOIF
Dieses HTML-Dokument ergibt als SOIF beispielsweise:
@FILE { http://www.ix.de/tp/enfopol.html
Headings{29}:
Das neue Ermaechtigungsgesetz
Last-Modification-Time{9}: 914875680
Pictures{16}:
/Bilder/eu.jpg
Keywords{61}:
Buerger
ENFOPOL
Entmuendigung
Europaeischen
Union
File-Size{3}:
630
Abstract{282}: Das neue Ermaechtigungsgesetz
KAPITEL 4 - FORMATE UND METADATEN
48
ENFOPOL oder die Entmuendigung der Buerger Es geht ein neues
Gespenst um in Europa, ein Ermaechtigungsgesetz zur Entmuendigung
der Buerger. Das Papier heisst ENFOPOL und wurde am 03. September
vom Rat der Europaeischen Union als Entwurf verabschiedet.
Type{4}: HTML
Author{37}:
Artur P. Schmidt und Otto E. Roessler
Body{283}: Das neue Ermaechtigungsgesetz
ENFOPOL oder die Entmuendigung der Buerger Es geht ein neues
Gespenst um in Europa, ein Ermaechtigungsgesetz zur Entmuendigung
der Buerger. Das Papier heisst ENFOPOL und wurde am 03. September
vom Rat der Europaeischen Union als Entwurf verabschiedet.
Update-Time{9}: 914876030
URL-References{57}:
http://www.heise.de/tp/deutsch/special/enfo/6332/1.html
MD5{32}: 4b0c57d92b5180441d8c4586e37edd92
Title{29}: Das neue Ermaechtigungsgesetz
}
Listing 4.29: Aus dem HTML-Dokument in Listing 4.28 erzeugtes SOIF-Objekt
4.3.1.2
Allgemein verwendete Attribute
Die im SOIF-Objekt verwendeten Attribute sind nicht standardisiert, es gibt aber eine
Anzahl allgemein verwendeter Ausdrücke, die in Tabelle 4.2 aufgelistet sind. Viele der
Attribute beziehen sich auf den Gatherer, also das Programm, welches die Informationen
über die Dokumente extrahiert hat. [HSW1996]
Attribut
Beschreibung
Abstract
Kurzfassung des Objektes
Author
Author(s) des Objektes
Description
Kurze Beschreibung des Objektes
File-Size
Anzahl Bytes im Objekt
Full-Text
Gesamtinhalt des Objektes
Gatherer-Host
Host auf dem der extrahierende Gatherer arbeitet
Gatherer-Name
Name des Gatherers der die Information extrahiert hat
Gatherer-Port
Port Nummer des Gatherers der die Informationen extrahierte
hat
Gatherer-Version
Version des Gatherers
Keywords
Extrahierte Schlüsselwörter
Last-Modification-Time
Zeit zu der das Objekt zuletzt geändert wurde (in Sekunden
seit dem 1.1.1970 0:00 GMT)
MD5
MD5 Checksumme des Objektes
KAPITEL 4 - FORMATE UND METADATEN
49
Partial-Text
Teile des Inhalts des Objektes
Refresh-Rate
Gibt an, wie oft der Gatherer versucht, den Inhalt des SOIFObjektes zu erneuern (in Sekunden relativ zur Update-Time)
Time-to-Live
Gibt an, wie lange das SOIF-Objekt gültig ist (in Sekunden
relativ zur Update-Time)
Title
Titel des Objektes
Type
Typ des Objektes. Beispiele: Archive, Audio, Awk, Backup,
Binary, C, Cheader, Command, Compressed, CompressedTar,
Configuration, Data, Directory, DotFile, Dvi, FAQ, FYI, Font,
FormattedText, GDBM, GNUCompressed,
GNUCompressedTar, HTML, Image, Internet-Draft,
MacCompressed, Mail, Makefile, ManPage, Patch, Perl,
PostScript, RCS, README, RFC, SCCS, ShellArchive, Tar,
Tcl, Tex, Text und Uuencoded.
Update-Time
Zeit zu der der Gatherer das SOIF-Objekt zuletzt erneuert
bzw. generiert hat (in Sekunden seit dem 1.1.1970 0:00 GMT)
URL
URL des Objektes
URL-References
URL Referenzen im HTML Objekt
Tabelle 4.2: Attribute des Summary Object Interchange Formates
SOIF beschreibt keine festgelegte Konvertierung von Dokumenten. Es stellt einen
Rahmen dar, mit der unterschiedlichste Dokumentenformate in ein einheitliches Objekt
abgebildet werden können. Die Zuordnung des Inhalts zu den einzelnen Attributen ist
dabei nicht festgelegt. Die Längenangabe ermöglicht es, auch binäre Daten einzutragen.
[Kni1996]
Ein Vorteil ist die Einfachheit und einfache Verarbeitungsmöglichkeit von SOIF. Da es
ohne spezielle Zeichen auskommt, braucht es keinen Escape-Mechanismus. Mehrere
SOIF-Objekte lassen sich zu einem Paket zusammenstellen. Nachteilig wirkt sich aus, daß
ein Fehler innerhalb eines Pakets alle nachfolgenden SOIF-Objekte unbrauchbar macht.
Fehlen durch Übertragungsfehler einzelne Zeichen, so stimmt die Längenangabe des
betroffenen Attributes nicht mehr und der Beginn des nachfolgenden Attributes wird nicht
mehr korrekt erkannt. [NK1994]
4.3.2
XML – Extensible Markup Language
Ein großer Schwachpunkt heute verwendeter Datenformate ist die teilweise Plattformabhängigkeit, die schlecht realisierbare Erweiterbarkeit, die komplizierte Überprüfbarkeit auf Korrektheit und die oft nicht freigegebene Verwendung. Aus diesem Grund
wird derzeit versucht, eine syntaktische Grundlage zum Austausch beliebiger allgemeiner
Datenformate und logischer Strukturen zu schaffen. Dieses Format kann im Gestaltungsbereich zur Weitergabe von Dokumenteninformationen an hierarchisch übergeordnete
Suchdienste verwendet werden (siehe auch Kapitel 8).
KAPITEL 4 - FORMATE UND METADATEN
50
Das World Wide Web Consortium32, eine Standardisierungsorganisation für das Web, ist
zur Zeit dabei, eine Grundlage für Datenformate – die sogenannte Extensible Markup
Language [XML] – und darauf aufbauende Vorschläge zu entwickeln. Zum Zeitpunkt der
Erstellung dieser Arbeit liegt XML als W3C Recommendation 1.0 vom 10. Februar 1998
vor [XML10]. Im folgenden wird ein Überblick der Entwicklung von XML gegeben und
nach einem Einblick in die Spezifikation des W3C ein Ausblick auf die Zukunft von XML
geworfen.
4.3.2.1
Entwicklung und Motivation
In den Sechzigern haben IBM-Wissenschaftler an einer Metasprache für Auszeichnungssprachen gearbeitet. Es ging darum festzulegen, wie zukünftig die Struktur und der
Inhalt von Dokumenten beschrieben werden soll. 1986 übernahm die International
Standards Organization (ISO) eine Version dieses Standards und nannte sie Standard
Generalized Markup Language (SGML). SGML bietet ein komplexes System für die
Auszeichnung von Dokumenten. SGML ist groß, mächtig und angefüllt mit Optionen, eine
Sprache, die gut geeignet ist für große Organisationen, die anspruchsvolle Standards für
ihre Dokumente benötigen. [Dün1998]
Als Anfang der Neunziger das World Wide Web entwickelt wurde, brauchte man ein
einfaches Auszeichnungssystem. Man entschloß sich, die neue Auszeichnungssprache an
SGML zu orientieren. So entstand die Hypertext Markup Language (HTML). HTML ist
ein spezieller Dokumenttyp von SGML. HTML wurde zur Basis für das aufstrebende
World Wide Web. [Dün1998]
Zwei Strömungen und Tendenzen führen dazu, daß Ende der Neunziger Jahre Standards
entstehen, die über die Beschränkungen von HTML hinausgehen. Zum einen gibt es die
Gemeinde der SGML-Anhänger, die es schon seit langem bedauert, daß die Mächtigkeit
von SGML im Web nur zum kleineren Teil zum Tragen kommt. Zum andern gibt es viele
Entwickler von Web-Programmen, die erkennen, daß sie in ihren Möglichkeiten sehr
eingeschränkt sind. Es war ein naheliegender Gedanke, daß es die Möglichkeiten von
SGML sind, die dem Web fehlen. [Dün1998]
Als man analysierte, warum die Ideen von SGML im Web bisher keinen Durchbruch
erlebt haben, war klar, daß das vor allem an der hohen Komplexität von SGML liegt. Da
SGML eine so komplexe Sprache ist, bedeutet es einen sehr großem Aufwand, Programme
zu schreiben, die SGML-Dokumente verarbeiten. Beim World Wide Web Consortium
wurde daher eine Arbeitsgruppe eingerichtet, die sich als Aufgabe vornahm, eine
vereinfachte Variante von SGML zu schaffen. Daraus entstand die Extensible Markup
Language XML [XML10].
XML ist so definiert, daß die nützlichsten Teile von SGML erhalten bleiben. Weggelassen wurden die weniger gebräuchlichen und komplizierten Teile. XML ist ebenso wie
SGML eine Metasprache für das Definieren von Dokumenttypen. Das heißt, XML ist der
Oberbegriff für die Regeln (d.h. die Syntax), die angewendet werden, wenn ein neuer
Dokumenttyp definiert wird.
32
World Wide Web Consortium, W3C, http://www.w3.org
KAPITEL 4 - FORMATE UND METADATEN
4.3.2.2
51
Dokumenttyp-Definitionen und Datenformate
Unter einem Datenformat versteht man die Gesamtheit der Richtlinien, die für das
Organisieren von Daten innerhalb einer Datei gelten. Der Begriff "Datenformat" wird
weitgehend identisch mit "Datei-Format" verwendet. Die Dokumenttyp-Definition (kurz
DTD) ist etwas ähnliches. Die DTD legt fest, wie in einer Datei des entsprechenden Typs
die Daten organisiert werden. [Dün1998]
DTDs dienen zusammen mit einer Metasprache wie SGML bzw. XML dazu, das Format
eines Dokuments zu definieren bzw. eine eigene Markup-Sprache zu beschreiben. Man
spricht von einer Applikation der entsprechenden Metasprache. HTML ist beispielsweise
eine Applikation von SGML. In den DTDs für HTML ist beispielsweise festgelegt, daß
innerhalb eines <UL>-Elementes <LI>-Elemente auftauchen können, daß <IMG>Elemente ALT-Atribute enthalten können und so weiter. Da es von HTML mehrere
Versionen gibt, sind auch mehrere DTDs für HTML entstanden. In einer DTD werden also
Strukturmerkmale für Dokumente festgelegt. Es wird festgelegt, welche Elementtypen
(genauere Erläuterung von Elementen siehe 4.3.2.3) in den Dokumenten verwendet werden
und wie Elemente ineinander verschachtelt werden können, und es wird auch angegeben,
welche Attribute zu welchen Elementen gehören und welche Attributwerte jeweils zulässig
sind. [Dün1998]
Diese Art der Definition liefert aber neben der schon erwähnten Plattformunabhängigkeit und Kontrollmöglichkeit weitere Vorteile die es bei den bisher verwendeten InselLösungen nicht gibt. Zusätzlich zur XML-Spezifikation entstehen eine Reihe von
wichtigen anderen Standards (zum Beispiel für das Verlinken von Dokumenten33 und für
den Zugriff auf den sogenannten Dokumenten-Baum34). Jedes Datenformat, das auf der
Grundlage von XML definiert wird, befindet sich somit von Anfang an in einem Umfeld,
in dem es eine Reihe von nützlichen Zusatzstandards und Programmen 35 gibt, so daß es bei
Kompatibilität und Möglichkeiten für den Datenaustausch wesentlich weniger Probleme
geben wird. [XML]
4.3.2.3
XML Spezifikation – ein Überblick
Am 10. Februar 1999 wurde die Version 1.0 der XML-Spezifikation zu einem offiziellen
Standard [XML10]. XML ist noch längst keine ausgereifte Technologie. Die Spezifikation
legt fest, wie XML funktioniert. Viele Einzelfragen sind derzeit noch nicht geklärt bzw.
befinden sich gerade in der Entwicklung. Ob XML zu einem wichtigen Thema für
Webdesigner wird, läßt sich noch nicht absehen. Letztlich sind es einige Zusatztechnologien, die für Webdesigner besonders interessant sind. An diesen Technologien (wie etwa
Extensible Style Sheets [XSL] oder Namespaces [XMLNS])wird jedoch noch gearbeitet.
Um ein Gefühl zu bekommen, wie ein XML-Dokument aussehen kann, folgt ein
Beispiel einer Bestellung einer bestimmten Person in einem Geschäft (siehe Listing 4.30).
33
XML XLink, http://www.w3.org/TR/NOTE-xlink-req/
34
Document Object Model, DOM, http://www.w3.org/MarkUp/DOM/
35
z.B. Saxon, ein Java XML Parser, http://users.iclway.co.uk/mhkay/saxon/
KAPITEL 4 - FORMATE UND METADATEN
52
Dabei werden verschiedene Waren erstanden.
<ORDER>
<SOLD-TO>
<PERSON>
<LASTNAME>Layman</LASTNAME>
<FIRSTNAME>Andrew</FIRSTNAME>
</PERSON>
</SOLD-TO>
<SOLD-ON>19970317</SOLD-ON>
<ITEM>
<PRICE>5.95</PRICE>
<BOOK>
<TITLE>Number, the Language of Science</TITLE>
<AUTHOR>Dantzig, Tobias</AUTHOR>
</BOOK>
</ITEM>
<ITEM>
<PRICE>1.50</PRICE>
<COFFEE>
<SIZE>small</SIZE>
<STYLE>cafe macchiato</STYLE>
</COFFEE>
</ITEM>
</ORDER>
Listing 4.30: Strukturbeispiel Markup Language
XML-Daten sind flexibel genug, um heterogene Strukturen kodieren zu können,
beispielsweise Bücher und Kaffee alle in der selben Bestellung. Die verschiedenen Teile
brauchen nicht alle die gleichen internen Daten (bzw. Elemente, siehe auch 4.3.2.4) zu
enthalten. XML unterscheidet zwischen wohlgeformt und gültig. Um wohlgeformt zu sein,
müssen einige elementare syntaktische Regeln eingehalten werden. Unter anderem dürfen
keine Ende-Auszeichnungen (wie etwa </ITEM>) fehlen, keine verschränkten Elemente
existieren und leere Elemente mit "/>" gekennzeichnet werden. [XML10]
Damit ein Dokument gültig wird, muß es auf eine DTD36 (siehe auch Abschnitt 4.3.2.2)
ausgerichtet werden und die Vorgaben dieser DTD einhalten. Außerdem muß es ein
sogenanntes Wurzelelement haben (hier ORDER), das korrekt mit Unterelementen
verschachtelt ist. DTD's können entweder im Dokument selber vorhanden sein oder als
Verweis auf eine externe DTD, die sich irgendwo im Internet befindet, angegeben sein.
Das Beispiel aus Listing 4.30 ist wohlgeformt, aber nicht gültig, da die DTD bzw. ein
Verweis auf die zu verwendende DTD fehlt. [XML10]
4.3.2.4
Elemente und deren Deklaration
Einige Beispiele in diesem Abschnitt sind der deutschen Version des XML Standards
von Henning Behme und Stefan Mintert entnommen [XML10]. Alle Elemente müssen für
ein gültiges Dokument in der DTD definiert werden. Listing 4.31 ist ein Beispiel für die
36
Document Type Definition
KAPITEL 4 - FORMATE UND METADATEN
53
Verwendung des Elementtyps "autor" in einem Dokument.
<autor>Joseph Roth</autor>
Listing 4.31: Verwendung des Elementtyps Autor in einem XML Dokument
Das Element setzt sich zusammen aus Start-Tag, Inhalt und End-Tag. Die Deklaration
für diesen Elementtyp in der DTD würde wie in Listing 4.32 aussehen.
<ELEMENT autor #PCDATA>
Listing 4.32: Definition des Elementtyps Autor in einer XML DTD
Hier wird "autor" deklariert. Das Schlüsselwort #PCDATA gibt an, daß der Inhalt des
Elementes aus jeder beliebigen Zeichenfolge bestehen kann. Das im Listing 4.33 gezeigte
Dokument ist (vorausgesetzt es folgt der externen DTD hallo.dtd) sowohl wohlgeformt als
auch gültig.
<?xml version="1.0"?>
<!DOCTYPE gruss SYSTEM "hallo.dtd">
<gruss>
Hallo Welt!
</gruss>
Listing 4.33: Wohlgeformtes XML Dokument mit Verweis auf externe DTD
Der System-Identifier "hallo.dtd" gibt den Uniform Resource Identifier (siehe auch
[RFC2396]) bzw. die URL (Uniform Resource Locator, also die Adresse und den Namen
im WWW) einer DTD für das Dokument an. Die Deklaration kann auch lokal angegeben
werden, wie in Listing 4.34 gezeigt.
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE gruss [
<!ELEMENT gruss (#PCDATA)>
]>
<gruss>
Hallo Welt!
</gruss>
Listing 4.34: Lokale Definition der DTD in einem XML Dokument
In der DTD muß ebenfalls das Wurzelelement (auch Dokumentelement, im Listing 4.34
"gruss") angegeben werden und mit dem ersten Element übereinstimmen, damit das
Dokument gültig ist. [XML10]
KAPITEL 4 - FORMATE UND METADATEN
4.3.2.5
54
Ausblick in die Zukunft von XML
XML kann die Grundlage für ein "neues HTML" werden. Es ist aber nicht zu erwarten,
daß HTML nicht mehr verwendet wird. Es ist immer noch die beste Möglichkeit für
einfache Dokumentenstrukturen im World Wide Web. Das "neue HTML" wird aus einer
Reihe von Modulen bestehen und kann zu jeder Zeit durch neue Module ergänzt werden.
Die folgenden Teile dieses Ausblickes wurden aus [Dün1998] entnommen.
Die Entwickler denken auch darüber nach, wie XML Dokumente, ähnlich HTML,
möglichst flexibel angezeigt werden können. Der W3C Vorschlag XSL37 ist eine Sprache
für Formatvorlagen (Stylesheets). Zwar können für die Formatierung von XMLDokumenten auch Cascading Style Sheets38 (CSS) verwendet werden, XSL soll jedoch
Möglichkeiten bieten, die über die der CSS hinausgehen. Etwa soll es mit XSL möglich
sein, in XML-Dokumenten automatisch erzeugten Text einzufügen, zum Beispiel
Seitennummern, die hochgezählt werden.
Es entstehen eine größere Zahl von Dokumenttypen (d.h. Auszeichnungssprachen), und
im Umfeld von jedem Dokumenttyp entstehen spezialisierte Anwendungen. Wenn viele
Auszeichnungssprachen nebeneinander bestehen, dann birgt das im Prinzip die Gefahr, daß
unterschiedliche Welten entstehen, die immer weiter auseinander driften. Da es sich aber
um lauter Auszeichnungssprachen handelt, die auf der Grundlage von XML definiert
werden, ist sichergestellt, daß der nötige Zusammenhalt bzw. die nötigen Gemeinsamkeiten gegeben sind.
Beispielsweise wird durch die Aktivitäten um XML herum dafür gesorgt, daß alle
Auszeichnungssprachen die selben Link-Mechanismen verwenden. Es wäre für das Web
fatal, wenn im Laufe der Zeit lauter Inseln von Dokumenten entstehen würden, die nicht
mehr untereinander verlinkt werden können. Für die Schaffung von Link-Mechanismen
sind jedoch nicht die Verfasser von DTDs zuständig. Die Link-Mechanismen, an denen
aktuell gearbeitet wird, werden früher oder später ein Bestandteil der XML-Spezifikation.
Dadurch ist sichergestellt, daß für alle XML-Dokumente die selben Mechanismen zur
Verfügung stehen.
Wenn es um die Vorzüge von XML geht, dann sind "Standardisierung" und "Offenheit"
die wichtigen Stichwörter. Offenheit bedeutet in diesem Zusammenhang, daß lauter
Auszeichnungssprachen entstehen, die leicht durchschaubar sind und daher von vielen
genutzt werden können. Ein Blick auf die DTD wird zeigen, mit welchen Datenstrukturen
man es zu tun hat. In Sachen Standardisierung stellt die Veröffentlichung des XMLStandards selbst – zusammen mit der Spezifikation für das Document Object Model39 –
bereits den wichtigsten Schritt dar. Wenn jetzt auf der Grundlage des XML-Standards
Auszeichnungssprachen geschaffen werden, dann ist sichergestellt, daß mit den
zugehörigen Dokumenten gearbeitet werden kann. Das DOM ist ein Interface, das zeigt,
wie der dynamische Zugriff auf XML-Dokumente (Inhalt und Struktur) mittels Scripts
gestaltet werden kann.
37
Extensible Style Language, XSL, http://www.w3.org/Style/XSL/
38
Cascading Style Sheets, CSS, http://www.w3.org/Style/CSS/
39
Document Object Model, DOM, http://www.w3.org/DOM/
KAPITEL 4 - FORMATE UND METADATEN
55
Wie sehen also die Dokumente der Zukunft aus? Gerne werden Beispiele wie diese
angeführt: Wenn etwa ein Dokument Daten über Autoren liefert, dann kann dafür gesorgt
werden, daß ein Klicken auf einen Namen dazu führt, daß zu dem Namen der zugehörige
Lebenslauf eingeblendet wird.
XML kann eine mögliche Erleichterung für den Einkauf in Internet-Shops werden.
Sobald man sich darauf geeinigt hat, welche Artikelbezeichnungen verwendet werden
sollen und welche Struktur die Dokumente haben sollen, in denen die Angebote geliefert
werden, dann ist es möglich, Programme zu schreiben (sogenannte Agenten), die imstande
sind, selbständig das Netz zu durchwandern und die gefundenen Preise zu vergleichen.
Dadurch könnte auch ein gewisser Zugzwang zur Einführung des neuen Formates
entstehen, wenn die Shop-Besitzer, die das entsprechende Datenformat nicht verwendet,
befürchten müssen, daß ihre Angebote von den Agenten übergangen werden.
4.3.3
MCF – Meta Content Framework
Der ursprüngliche Vorschlag dieser Definition stammt von Apple40 und wurde von
Netscape41 weitergeführt. Im bei der W3C42 eingereichten Dokument wird MCF als
Strukturbeschreibungssprache bezeichnet, wobei die Organisation der Information als
gerichteter Graph (directed labeled graph) ausgeführt ist. Knoten (node), Labels (property
type) und Arcs (Kanten, bestehend aus Quell- und Zielknoten sowie einem Label) bilden
die Grundelemente. Hinzu kommen eine Reihe vordefinierter Einheiten, welche die
Beschreibung von Beziehungen erleichtern sollen. [MCF1997]
MCF wird in der derzeitigen Form nicht mehr weiterentwickelt. Daher wird hier auch
nicht weiter darauf eingegangen. Viele Vorschläge, unter anderem auch MCF, dienen als
Grundlage für die Entwicklung von RDF, also dem Resource Description Framework.
Listing 4.35 zeigt ein MCF-Dokument in XML. "description" gehört zu den vorgegebenen
Schlüsselwörtern, während "vorname" in "notwendiges.mcf" definiert ist. [Henn1998]
<xml-mcf>
<mcf-ref XML-LINK="SIMPLE" ROLE="XML-MCF-BLOCK"
href="http://www.woauchimmer.org/notwendiges.mcf" />
<person id="Manfred_Ehrlich">
<name>Ehrlich</name>
<vorname>Manfred</vorname>
<description>Webmaster bei XYZ-Firma</description>
<email>me@xyz_firma.de</email>
<wpage unit="/leute/me" />
</person>
<!-- weitere Definitionen -->
</xml-mcf>
Listing 4.35: Beispiel einer Adressangabe in MCF mittels XML
40
Apple, http://www.apple.com
41
Netscape, http://www.netscape.com
42
World Wide Web Consortium, W3C, http://www.w3.org
KAPITEL 4 - FORMATE UND METADATEN
4.3.4
56
RDF – Resource Description Framework
Wie schon erwähnt geht die Tendenz dahin, daß das World Wide Web zum weltweiten
Wissensspeicher mit einer rasant anwachsenden Zahl von Dokumenten wird. Informationsanbieter wie Bibliotheken, Firmen und Institutionen sind zunehmend über das Internet
miteinander verbunden und die Menge des potentiell verfügbaren Wissens wächst
exponentiell, so daß die Suche nach bestimmten Informationen immer schwieriger und
aufwendiger wird (siehe auch Kapitel 2.3 – Schwachpunkte gängiger Suchdienste).
Abhilfe können Metadaten, d.h. Informationen über Informationen, schaffen, wie sie in
Form von Katalogen in Büchereien oder als Indexdateien schon lange bekannt sind. Will
man jedoch Metadaten weltweit vernetzter Informationen bereitstellen, treten eine ganze
Reihe von Schwierigkeiten auf. So weisen diese Daten keine einheitliche Struktur auf, was
mit unterschiedlichen Sprachen, Ressourcentypen und auch Traditionen zu tun hat. Früher
hatte jedes Archiv sein eigenes Klassifikations- und Beschreibungsschema. Derartige
Katalogdaten sind damit kaum international austauschbar und nicht maschinenverständlich, selbst wenn sie in digitalisierter Form vorliegen. [Schön1998]
Das Ziel der Entwicklung von RDF war es, eine einheitliche und interoperable
Möglichkeit des Datenaustausches zwischen Programmen über das Web zu schaffen,
wobei RDF sowohl für Menschen lesbar als auch leicht für Computer verständlich sein
soll. Bei dem Resource Description Framework handelt es sich um einen Standard des
W3C43, mit dem festgelegt wird, wie auf der Grundlage von XML (siehe Kapitel 4.3.2)
Metadaten beschrieben und ausgetauscht werden können. Metadaten sind Daten, die
andere Daten, zum Beispiel Dokumente, beschreiben44.
Bei RDF wurden verschiedene Entwicklungen in Hinblick auf Metadaten aufgegriffen,
wie die schon erwähnte Dublin Core Initiative (siehe Abschnitt 4.2.1), die Platform for
Internet Content Selection (siehe Abschnitt 4.2.2), das Meta Content Framework Using
XML (siehe Abschnitt 4.3.3) und die Web Collections using XML45 von Microsoft. RDF
soll den Entwicklern eine standardisierte Möglichkeit bieten, wie sie eine große Menge
von Elementen und die Beziehungen, die sie untereinander haben, notieren können. Daten,
die mit RDF erfaßt wurden, sollen ebenfalls dokumentübergreifende Suchläufe
vereinfachen. [Las1997]
Im folgenden wird nach einem Blick auf das Datenmodell näher auf die Syntax von RDF
eingegangen.
4.3.4.1
Datenmodell
Die Aufgabe von RDF ist die Beschreibung von Ressourcen, worunter beliebige Objekte
verstanden werden, die Informationen enthalten (Texte, Webseiten, Videos, etc.). Die
Ressourcen werden durch ihre URI (Uniform Resource Identifier) identifiziert. Sie haben
benannte Eigenschaften mit Werten. Die folgenden Abschnitte orientieren sich an
[Schön1998].
43
Resource Description Framework, RDF, http://www.w3.org/RDF/
44
W3C Metadata Activity, http://www.w3.org/Metadata/
45
Web Collections using XML, http://www.w3.org/TR/NOTE-XMLsubmit.html
57
KAPITEL 4 - FORMATE UND METADATEN
Jeder Ressource wird im Datenmodell über eine Eigenschaft ein Wert zugewiesen. Doch
die Unterscheidung von Ressource und Wert ist nicht immer eindeutig und von
Anwendung zu Anwendung verschieden. Ein einfaches Beispiel demonstriert das. Die
beiden Aussagen "Der Autor des Dokuments http://www.x.at/index.html ist E. U. Sebius"
bzw. "E. U. Sebius ist der Autor des Dokuments http://www.x.at/index.html" sind für einen
Menschen gleichwertig, eine Maschine würde jedoch jeweils ein anderes Objekt als
Ressource festlegen, also hier entweder das Dokument oder die Person. Im
RDF-Datenmodell weist deshalb ein Pfeil von der Ressource zum Wert der Eigenschaft.
Dieser Pfeil wird durch den Eigenschaftstyp benannt. Es ergibt sich pro Aussage (bzw.
Statement) also immer ein Datentripel (siehe Tabelle 4.3).
Teil des Statements
Beispiel
Subjekt (Resource)
http://www.x.at/index.html
Prädikat (Property, Eigenschaft)
Autor bzw. Creator
Objekt (Value)
"E. U. Sebius"
Tabelle 4.3: Beispiel für ein RDF Datentripel
Ein Datentripel kann allgemein wie in Abbildung 4.2 dargestellt werden:
Resource
Property
Value
Abbildung 4.2: Schematische Darstellung eines RDF Statements
Für das Beispiel aus Tabelle 4.3 ergibt sich Abbildung 4.3:
http://www.x.at/index.html
Creator
E. U. Sebius
Abbildung 4.3: Schematische RDF Darstellung einer Dokument-Autor Beziehung
Auf diese Weise kann die Eigenschaft einer Ressource eindeutig beschrieben werden. Es
wird, wie bei Metadaten üblich, zwischen dem Typ einer Eigenschaft (Property oder
Attribut genannt) und dem Wert unterschieden. Der Typ ist bei gleichartigen Ressourcen
derselbe, während sich die Werte i.A. unterscheiden. Mehrere Eigenschaften einer
Ressource werden zu einer Beschreibung (Description) zusammengefaßt. Im Allgemeinen
ist der Wert der Eigenschaft Autor nicht nur ein String, sondern auch selber wieder ein
Objekt (Knoten, Node), das ebenfalls Eigenschaften hat und damit bezüglich dieser
Eigenschaften die Rolle einer Ressource, wie in Abbildung 4.4, übernimmt.
Autor_1 ist eine ID, die die Person des Autors eindeutig beschreibt. Auf diese beziehen
sich dann die Eigenschaften.
58
KAPITEL 4 - FORMATE UND METADATEN
http://www.x.at/index.html
Creator
Autor_1
Name
E. U. Sebius
eMail
[email protected]
Abbildung 4.4: Schematische Darstellung der Beziehung Autor-Dokument in RDF
Das RDF definiert auch Konstrukte für erweiterte Relationen, bei denen z.B. einer
Eigenschaft mehrere Werte zugewiesen werden (geordnete Listen, ungeordnete Werte)
oder bei der der Wert selber wieder eine Eigenschaft ist. Hinsichtlich der Eigenschaftstypen gibt es eine Art Klassenkonzept. Die zu einer Domäne gehörenden Eigenschaftstypen werden in einem Schema zusammengefaßt und über das Internet zugänglich
gemacht, wo sie für Beschreibungen gleicher Ressourcenarten genutzt bzw. erweitert und
angepaßt werden können.
4.3.4.2
Syntax auf der Basis von XML
Ein Ziel der RDF Entwicklung ist neben der maschinellen Verarbeitbarkeit die
Verwendung eines von Menschen lesbaren Formates. Außerdem sollen die Daten leicht
über das Internet ausgetauscht werden können. Aus diesem Grund müssen die unter
Umständen komplexen Verknüpfungen serialisiert werden, wobei als Sprache die
Extensible Markup Language XML (siehe Kapitel 4.3.2) wegen der einfachen Erweiterbarkeit gewählt wurde. Es können aber auch andere Möglichkeiten, mit denen man dieses
Datenmodell ausdrücken kann, verwendet werden. Das Beispiel aus Tabelle 4.3 in
Abschnitt 4.3.4.1 kann in RDF wie in Listing 4.36 beschrieben werden.
<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/RDF"
xmlns:DC="http://metadata.net/rdf/DC">
<RDF:Description about="http://www.x.at/index.html">
<DC:Creator>E. U. Sebius</DC:Creator>
</RDF:Description>
</RDF:RDF>
Listing 4.36: Beziehung Autor-Dokument ausgedrückt in RDF mittels XML
Listing 4.37 zeigt die grundsätzliche Syntax für die Serialisation in EBNF (siehe auch
[RDF]).
[1] RDF
[2] description
[3] idAboutAttr
[4] aboutAttr
[5] idAttr
::= ['<rdf:RDF>'] description* ['</rdf:RDF>']
::= '<rdf:Description' idAboutAttr? '>'
propertyElt*'</rdf:Description>'
::= idAttr | aboutAttr
::= 'about="' URI-reference '"'
::= 'ID="' IDsymbol '"'
KAPITEL 4 - FORMATE UND METADATEN
[6] propertyElt
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
propName
value
resourceAttr
Qname
URI-reference
IDsymbol
name
NSprefix
string
59
::= '<' propName '>' value '</' propName '>'
| '<' propName resourceAttr '/>'
::= Qname
::= description | string
::= 'resource="' URI-reference '"'
::= [ NSprefix ':' ] name
::= string, interpreted per [URI]
::= (any legal XML name symbol)
::= (any legal XML name symbol)
::= (any legal XML namespace prefix)
::= (any text, with "<", ">", and "&" escaped)
Listing 4.37: Vereinfachte formale Beschreibung von RDF in EBNF
4.3.4.3
Namensräume
Die Bedeutung eines RDF Dokuments wird durch eine Referenz auf ein Schema bzw.
einen Namensraum (siehe auch XML Namespaces [XMLNS]) ausgedrückt. Schemata
definieren Begriffe, die in RDF-Ausdrücken verwendet werden und geben diesen eine
spezielle Bedeutung (siehe Listing 4.36, Namensräume RDF und DC). Es gibt viele
Möglichkeiten, Schemata zu definieren, wobei die Angabe in einem eigenen Dokument die
Möglichkeit schafft, allgemein benutzbare Vorlagen zu definieren, die dann weltweit
verwendet werden können. [Schön1998]
In RDF muß jede Eigenschaft, die in einer Aussage verwendet wird, in genau einem
Namensraum definiert sein. Wie aus Listing 4.36 ersichtlich, können natürlich auch
Eigenschaften mehrerer Schemata in Beschreibungen vorkommen. Listing 4.38 zeigt noch
einmal das mit Zeilennummern versehene Beispiel.
1 <?xml version="1.0"?>
2 <RDF:RDF xmlns:RDF="http://www.w3.org/RDF"
3
xmlns:DC="http://metadata.net/rdf/DC">
4
<RDF:Description about="http://www.x.at/index.html">
5
<DC:Creator>E. U. Sebius</DC:Creator>
6
</RDF:Description>
7 </RDF:RDF>
Listing 4.38: Beziehung Autor-Dokument in RDF mittels XML (numeriert)
Der Code beginnt mit einer sogenannten Processing Instruction, die das Dokument als
XML-Dokument kennzeichnet (Zeile 1). Im darauffolgenden einleitenden RDF-Tag
werden die Namensräume in Form von Attributen festlegen (Zeilen 2 und 3). Der
qualifizierte Name eines RDF-Tags besteht aus dem selbstgewählten Bezeichner für den
externen Namensraum (hier RDF und DC), einem Doppelpunkt und dem Elementnamen.
Zum Beispiel bedeutet <DC:Creator> in Zeile 5, daß die Eigenschaft Creator im Dublin
Core Schema unter der angegebenen Adresse festgelegt ist und daß der Wert "E. U.
Sebius" dieser Eigenschaft zugewiesen wird. [Schön1998]
KAPITEL 4 - FORMATE UND METADATEN
4.3.4.4
60
Abgekürzte Syntax
Der Code aus Listing 4.36 kann in eine XML-Datei eingebettet werden oder auch extern
abgelegt werden. Probleme gibt es jedoch, wenn man versucht, Metadaten auf diese Weise
in HTML einzubetten. Ein HTML-Browser kann mit den neuen Tags nicht umgehen.
Standardmäßig werden unbekannte Tags nicht dargestellt, was in diesem Fall durchaus
gewünscht ist. Die Metadaten sollen schließlich nicht auf dem Bildschirm dargestellt
werden. Was dargestellt wird, ist bei manchen Browsern der Autorenname, wenn Text in
der <HEAD>-Sektion nicht ignoriert wird. Dieser Name und gegebenenfalls weitere Werte
von Eigenschaften würden von einem Browser angezeigt. Um das zu vermeiden, schlägt
das W3C parallel zu dieser Syntax eine sogenannte Abbreviated Syntax vor, bei der alle
Metadaten in Form von Attributen innerhalb der Tags formuliert werden. Damit werden sie
von einem HTML-Browser bei der Darstellung komplett ignoriert. Die Metadaten sind
jedoch in das HTML-Dokument eingebettet und können von geeigneten Applikationen
(Suchmaschinen, Softwareagenten usw.) ausgelesen und verarbeitet werden. Listing 4.36
hat abgekürzt die Form, wie in Listing 4.39 angegeben. [Schön1998]
<RDF:RDF
xmlns:RDF="http://www.w3.org/RDF"
xmlns:DC="http://metadata.net/rdf/DC">
<RDF:Description about="http://www.x.at/index.html"
DC:Author="E. U. Sebius" />
</RDF:RDF>
Listing 4.39: Abgekürzte Schreibweise von RDF in XML
4.3.4.5
Aussagen über andere Aussagen
In RDF können ebenfalls Aussagen über andere Aussagen gemacht werden. Aussagen
können aber nur über Ressourcen gemacht werden und dazu muß die Aussage erst
modelliert werden [Las1998]. Zum Beispiel folgender Satz:
Bernhard is the creator of the resource http://www.x.at/Bernhard
In RDF ist das eine Aussage. Wenn der Satz hingegen heißt:
Helmut says that Bernhard is the creator of the resource
http://www.x.at/Bernhard
dann ist noch keine Aussage über die Ressource http://www.x.at/Bernhard
getroffen; statt dessen wurde eine Tatsache über eine Aussage von Helmut getroffen. Um
eine Aussage zu modellieren46 und in RDF auszudrücken sind vier Eigenschaften nötig:
Subject, Predicate, Object und Type [Las1998]. Für obige Aussage müssen wir zum
modellierten Statement noch eine Eigenschaft (etwa "attributedTo") mit einem
46
formell "reifizieren" genannt
KAPITEL 4 - FORMATE UND METADATEN
61
entsprechenden Wert (hier "Helmut") hinzufügen:
<rdf:RDF
xmlns:rdf="http://w3.org/TR/1999/PR-rdf-syntax-19990105#"
xmlns:a="http://descript.org/schema/">
<rdf:Description>
<rdf:subject resource="http://www.x.at/Bernhard" />
<rdf:predicate resource="http://descript.org/schema#Creator" />
<rdf:object>Bernhard</rdf:object>
<rdf:type resource="http://w3.org/TR/1999/
PR-rdf-syntax#Statement" />
<a:attributedTo>Helmut</a:attributedTo>
</rdf:Description>
</rdf:RDF>
Listing 4.40: Beispiel einer Aussage über andere Aussagen in RDF
4.3.4.6
Container
Oft ist es nötig, sich auf eine Menge (engl. Collection) von Ressourcen zu beziehen. In
RDF gibt es dazu drei Typen [Las1998]:
Bag
Unsortierte Liste von Daten oder Ressourcen, d.h. die Reihenfolge ist nicht
wichtig. Doppelte Angaben sind erlaubt.
Sequence
Sortierte Liste von Daten oder Ressourcen. Doppelte sind erlaubt. Wird zum
Beispiel verwendet, um alphabetische Sortierung von Werten darzustellen.
Alternative
Liste von Ressourcen oder Daten, die Alternativen für einen einzelnen Wert
einer Eigenschaft repräsentieren, etwa alternative Sprachübersetzungen eines Dokumententitels.
RDF benützt eine zusätzliche Ressource, die die Collection repräsentiert47. Diese
Ressource muß als Instanz einer der oben definierten Container-Klassen deklariert werden,
was mit der Eigenschaft "Type" erreicht wird. Die Spezifizierung der Zugehörigkeit von
Ressourcen zu einem Container wird durch Eigenschaften erreicht. Diese werden einfach
"_1", "_2", "_3", u.s.w. benannt. Container Ressourcen können zusätzlich auch andere
Eigenschaften haben, die dann den Container selbst beschreiben. [Las1998]
Die übliche Verwendung von Containern ist als Wert einer Eigenschaft. Bei dieser
Verwendung hat das Statement ein einzelnes Objekt unabhängig von der Anzahl
Ressourcen die zu dem Container gehören; die Ressource Container selber ist das Objekt
der Aussage. [Las1998]
47
objektorientiert auch Instanz genannt
62
KAPITEL 4 - FORMATE UND METADATEN
Um beispielsweise folgende Aussage abzubilden:
Die Studenten in Kurs 234.567 sind Bernhard, Doris, Helmut und
Kerstin
ergibt sich das RDF Modell wie in Abbildung 4.5 gezeigt.
rdf:Bag
/Kurse/234.567
/Studenten/Bernhard
Studenten
rdf:type
rdf:_1
/Studenten/Doris
rdf:_2
rdf:_3
rdf:_4
/Studenten/Helmut
/Studenten/Kerstin
Abbildung 4.5: Schematische Darstellung eines Containers in RDF
In XML ausgedrückt ergibt sich für Listing 4.41.
<rdf:RDF>
<rdf:Description about="http://uni.edu/Kurse/234.567">
<s:Studenten>
<rdf:Bag>
<rdf:li resource="http://uni.edu/Studenten/Bernhard"/>
<rdf:li resource="http://uni.edu/Studenten/Doris"/>
<rdf:li resource="http://uni.edu/Studenten/Helmut"/>
<rdf:li resource="http://uni.edu/Studenten/Kerstin"/>
</rdf:Bag>
</s:Studenten>
</rdf:Description>
</rdf:RDF>
Listing 4.41: Beispiel eines Containers in RDF
In RDF ist die Identifikation einer Ressource wichtig: alle Ressourcen werden durch
einen eindeutigen Uniform Resource Identifier [RFC2396] spezifiziert, der im Allgemeinen mit der URL gleichbedeutend sein wird.
KAPITEL 4 - FORMATE UND METADATEN
63
4.4 Ausblick
Die Dokumentenverwaltung hat bei der bisherigen Entwicklung des WWW insbesondere der Sprache HTML praktisch keine Rolle gespielt. Jetzt wird unter Führung des
World Wide Web Consortium die Arbeit mit Dokumenten im Web auf eine neue
Grundlage gestellt. Im Mittelpunkt stehen dabei die Extensible Markup Language (siehe
Abschnitt 4.3.2) und das Document Object Model [DOM1998], eine plattform- und
sprachneutrale API zur Manipulation von Dokumenten. In diesen Kontext gehören neben
RDF (siehe Abschnitt 4.3.4) auch die Extensible Style Language [XSL], eine Beschreibungssprache um XML-Dokumente darstellen zu können.
Damit soll die Basis geschaffen werden, um das WWW zukünftig als zentrales
Publikationsmedium und effizienten Informationspool nutzen zu können. Die neuen
Standards sollen Einzellösungen von Firmen zuvorkommen. Sie bieten mit ihrer
Flexibilität und Erweiterbarkeit genügend Möglichkeiten, um auf eine breite Akzeptanz bei
den Informationsanbietern zu stoßen.
Die neuen Ansätze wie XML und RDF bieten ebenfalls wesentliche Erleichterungen für
Suchdienste. Prinzipiell werden in den Datenbanken der Suchdienste Metainformationen
über alle indizierten Dokumente gehalten. Viele Archive, die jetzt über das Internet
zugänglich sind (wie etwa Bibliotheken), weisen eigene Klassifikations- und Beschreibungsschemata auf, wobei die Daten keine einheitliche Struktur haben und somit nicht
einfach von Suchdiensten verwendet werden können. Auch Unternehmen sind daran
interessiert, zusätzliche Informationen über den Inhalt ihrer Seiten zur Verfügung zu
stellen (z.B. Beschreibungen des Inhaltes oder der Änderungsrate der Dokumente). Durch
die Verwendung von standardisierten Formaten können alle diese Informationen
wesentlich einfacher ausgetauscht und verwendet werden und stellen dadurch Suchdiensten Möglichkeiten zur Verfügung, relevantere Suchergebnisse zu liefern.
KAPITEL 4 - FORMATE UND METADATEN
64
4.5 Zusammenfassung
In den Kapiteln 2 und 3 wurden die Vorteile von Metadaten bei der Suche und
Auffindung von Dokumenten und anderen Objekten aufgezeigt. Die Nutzung dieser
Metainformationen ermöglicht es den Suchdiensten, relevantere Suchergebnisse zu liefern.
In der vorliegenden Arbeit wird daher im Gestaltungsbereich (siehe Teil II) ein Modul zur
Extraktion von Informationen und Metadaten aus HTML-Dokumenten (siehe Kapitel 7 –
Fehlertoleranter HTML-Konverter) entwickelt. Für die Konfiguration dieses Modules
wurde in diesem Kapitel die Struktur von HTML und die Einbettung von Metainformationen in HTML-Dokumente näher erläutert (siehe Abschnitt 4.1). Abschnitt 4.2 beschreibt
gängige Metadatenformate wie Dublin Core (siehe Abschnitt 4.2.1), LOM (siehe Abschnitt
4.2.2) und PICS (siehe Abschnitt 4.2.2), die ebenfalls vom HTML-Konverter extrahiert
werden können.
Als Ergebnis der im Kapitel 3 diskutierten Vorteile verteilter Informationsaufbereitung
wird im Gestaltungsbereich ein System, bestehend aus mehreren verteilten Modulen zur
Datenerfassung (siehe Kapitel 6 – Der Gatherer), implementiert. Damit diese Daten
effizent genutzt werden, ermöglicht eine definierte Schnittstelle die Weitergabe der
erfaßten Informationen an übergeordnete Suchdienste (siehe Kapitel 8 – Das GathererCollector-Interface). Der Datenaustausch erfolgt dabei über Standardformate wie etwa
SOIF (siehe Abschnitt 4.3.1). Die vorliegende Arbeit ist leicht erweiterbar um die
gesammelten Daten ebenfalls in zukünftig verwendeten Formaten wie RDF auf der Basis
von XML (siehe Abschnitt 4.3.4) zur Verfügung stellen zu können. Bis zur endgültigen
Standardisierung von RDF bzw. einem für Metainformationen nutzbaren Namensraum
bietet das Programm die Möglichkeit, Daten über Dokumente in wohlgeformtem XML
(siehe Abschnitt 4.3.2) weiterzugeben.
Die nachfolgenden Kapitel im Gestaltungsbereich beschreiben das entwickelte System
und die Installation der einzelnen Komponenten. Die Funktionsweise und Konfiguration
der Module wie Gatherer, HTML-Konverter (siehe Kapitel 7) und Gatherer-CollectorInterface werden näher erläutert und deren Zusammenarbeit im Gesamtsystem dargestellt
(siehe Kapitel 5).
Teil II
Gestaltungsbereich
Kapitel 5
Softwaredokumentation
5.1 Gesamtkonzept
Wie in Kapitel 2 beschrieben, haben herkömmliche Ansätze zur Informationssammlung
im World Wide Web vielfältige Nachteile (siehe Abschnitt 2.3). Vor allem das parallele
Durchforsten des Informationsraumes von mehreren Suchdiensten gleichzeitig erhöht die
Netz- und Serverbelastung wesentlich. Ein weiterer Nachteil ergibt sich durch fehlende
Zusatzinformationen wie etwa die Seitenänderungsrate der Dokumente. Dokumente
müssen dadurch immer wieder auf Veränderungen untersucht werden, damit die Aktualität
der Suchergebnisse gewährleistet bleibt.
In Kapitel 3 wurde deswegen ein anderer Ansatz untersucht, die lokale und verteilte
Informationsauffindung, wobei sich herausgestellt hat, daß mit diesem Ansatz viele
Nachteile vermieden werden können. In einem verteilten System existieren mehrere
voneinander unabhängige Module, genannt Gatherer, die Informationen über veränderte
oder neue Dokumente sammeln. Das Durchforsten der Dokumentenstruktur kann lokal am
Webserver über das Dateisystem erfolgen und verringert so die Belastung des Servers, da
der Protokolloverhead bei Netzwerkzugriff wegfällt. Die Nähe der Module zu den zu
untersuchenden Dokumenten hat ebenfalls den Vorteil, daß sie individuell an die
Änderungsrate der Dokumente auf diesem Server angepaßt werden und somit möglichst
aktuelle Informationen zur Verfügung stellen können. Die Informationen über die
durchforsteten Dokumente werden an übergeordnete Suchdienste weitergegeben, so daß
dieselben Daten von mehreren Suchdiensten verwendet werden können. Da den einzelnen
Gatherern bekannt ist, welche Dokumente sich geändert haben bzw. neu hinzugekommen
sind, müssen jetzt nur noch diese Informationen übertragen werden, wodurch die
Netzbelastung ebenfalls reduziert werden kann.
Um diese Vorteile nutzen zu können, wurde als Ergebnis der Untersuchungen im
Gestaltungsbereich der vorliegenden Arbeit ein System zur verteilten Informationsauffindung implementiert. Die Zusatzinformationen können ebenfalls weiter übermittelt werden,
um übergeordnete Suchprogramme von der Änderungsrate einzelner Dokumente zu
informieren und somit die Möglichkeit zu geben, den Datenbestand möglichst aktuell zu
halten. Die lokal gesammelten Informationen können zusätzlich dazu benutzt werden, den
67
KAPITEL 5 - SOFTWAREDOKUMENTATION
Webserver absuchbar zu machen. Ein ebenfalls entwickeltes Suchinterface ermöglicht
dabei die Eingabe von Stichwörtern zur Suche nach Dokumenten.
Alle entwickelten Module sind in der Programmiersprache Java implemetiert, um eine
einfache Portierung auf alle für Web-Server existierenden Plattformen zu ermöglichen,
wobei die Weitergabe der Informationen über ein in einem Projekt der ARPA entwickeltes
Interface erfolgt (siehe Abschnitt 3.4.1 – Harvest). Ein weiteres Modul indiziert die
Informationen, wobei eine gezielte Suche nach bestimmten Dokumenten über das
implementierte Web-Suchinterface mittels Eingabe von Suchbegriffen erfolgen kann.
Für einen groben Überblick werden die Komponenten kurz erläutert. Weitere Details zur
Funktionsweise und Konfiguration der einzelnen Softwaremodule folgen in den
angegebenen Kapiteln. Abbildung 5.1 zeigt die Zusammenarbeit der Module beim
Gathervorgang unter Verwendung des Dateisystems.
SendPassword
ListenPort
AVT
Gatherer
AVT
DB (Database)
AVTable
Analyzer
AVT
AVT
AVTableFilter
HTMLConverter
AVT
serialisiert
relationale
Datenbank
MD5Builder
MD5
HTML / Text
Dokumente
Datenbank
Dateisystem
Abbildung 5.1: Zusammenarbeit der Module bei einem Gathervorgang
Der Gatherer (siehe Kapitel 6) ermöglicht das Durchforsten von Dokumentenstrukturen
und kann dazu entweder das Dateisystem oder HTTP zur Übertragung der Daten über das
Internet verwenden. Die Dokumente und darin enthaltene Metainformationen werden mit
Hilfe des HTML-Konverters (Kapitel 7) in ein AVTable-Objekt (siehe Kapitel 11.10)
konvertiert. Ein AVTable-Objekt (in den Abbildungen mit AVT bezeichnet) ist eine
Attribut-Wert-Tabelle1, die alle relevanten Daten eines Objektes, wie etwa Schlüsselwörter
oder auch den gesamten Dokumententext selber, beinhalten kann. Dieses Zwischenformat
zum Informationsaustausch nimmt eine zentrale Stellung ein und dient fast allen Modulen
als Arbeitsgrundlage. Der MD5-Builder (siehe Kapitel 11.5) erzeugt die für verschiedene
Aufgaben notwendige MD5-Checksumme.
Das Modul AVTableFilter (siehe Kapitel 11.11) dient dazu, die einzelnen Attribute wie
etwa Body (Volltext) oder Schlüsselwörter in der AVTable nachträglich zu organisieren
1
Engl. attribute value table.
68
KAPITEL 5 - SOFTWAREDOKUMENTATION
und unnötige Attribute zu löschen. Die so umgewandelten Dokumente werden an das
Datenbank-Modul (siehe Kapitel 10) übergeben und in eine relationale Datenbank
eingefügt. Um eine Suche nach allen in den Dokumenten vorkommenden Wörter zu
ermöglichen, kann das Modul AVTableAnalyzer (siehe Kapitel 11.12) Begriffe in
einzelnen Attributen einer AVTable ermitteln. Diese werden bei entsprechender
Konfiguration ebenfalls in der Datenbank indiziert. Die Module ListenPort und
SendPassword dienen zum Beenden des Gatherers.
Damit die gesammelten Informationen über die Dokumente weitergegeben werden
können, stellt das CollectorInterface (siehe Kapitel 8) eine Schnittstelle zur Verfügung.
Übergeordnete Suchdienste können die Informationen hier übernehmen und brauchen
diese nicht selbst zu analysieren. Die Daten können auf Wunsch komprimiert übertragen
werden, um die benötigte Bandbreite zu reduzieren. Außerdem ist eine inkrementelle
Datenweitergabe möglich, also nur die Übermittlung neuer oder geänderter Dokumente.
Abbildung 5.2 zeigt eine Übersicht der dabei beteiligten Module. Mehrere Clients
können gleichzeitig Daten anfordern, wobei das CollectorInterface für jeden Client einen
eigenen CollectorThread startet. Die Auswertung der einzelnen Befehle erfolgt im Modul
CollectorProtocol. Das für die Übertragung zu verwendende Dokumentenformat kann
gewählt werden, wobei die gespeicherten AVTable-Objekte mit dem Modul AVTableConverter (siehe Kapitel 11.13) beispielsweise in SOIF umgewandelt werden. Das
Protokoll ist textbasiert und die einzelnen Kommandos werden im Klartext übertragen.
Internet
...
ListenPort
CollectorThreads
Collector
Protocol
AVT
AVTable
Converter
Collector
Interface
AVT
AVTable
Analyzer
DB (Database)
AVT
serialisiert
relationale
Datenbank
Datenbank
Dateisystem
Abbildung 5.2: Zusammenarbeit der Module des Collector-Interfaces
Eine Suche nach Dokumenten im lokalen Datenbestand kann über die implementierte
Suchfunktionalität durchgeführt werden. Das Suchservlet (siehe Kapitel 9) bietet die
Möglichkeit, über ein World Wide Web Formular Begriffe mit logischen Operatoren
verknüpft einzugeben und in bestimmten Attributen zu suchen. Die ermittelten Dokumente
69
KAPITEL 5 - SOFTWAREDOKUMENTATION
werden dann nach Wichtigkeit oder Änderungsdatum sortiert und ausgegeben. Der
Informationsaustausch innerhalb des Programmes ist in Abbildung 5.3 zu sehen.
Internet
...
Webserver
SearchServlet
AVT
DB (Database)
AVTable
Analyzer
AVT
serialisiert
Dokumente
Datenbank
relationale
Datenbank
Dateisystem
Abbildung 5.3: Zusammenarbeit der Module des SearchServlets
Zur Unterstützung der Datenaufbereitung und zum Vereinheitlichen der Konfiguration
wurden zusätzlich noch weitere Module entwickelt, die im folgenden kurz beschrieben
werden. Common (siehe Kapitel 0) enthält Konstanten und Funktionen, die von mehreren
anderen Programmteilen verwendet werden. Der ConfigReader (siehe Kapitel 11.1) dient
dazu, Konfigurationsdateien, die auch in mehrere Sektionen unterteilt sein können,
auszulesen. Das Modul Log (siehe Kapitel 11.2) bietet Methoden, um Meldungen und
Fehlermeldungen in Log-Dateien zu schreiben.
Ein weiteres Modul berechnet die MD5-Checksumme (siehe Kapitel 11.5) einer
Zeichenkette. ListenPort (siehe Kapitel 11.6) wartet an einem bestimmten Port auf die
Eingabe eines Paßwortes und wird dazu verwendet, einzelne Module wie den Gatherer
oder das CollectorInterface mit einem Terminalprogramm über das Netzwerk zu beenden.
Mit SendPassword (siehe Kapitel 11.7) kann dieser Vorgang automatisiert werden wobei
kein Terminalprogramm mehr benötigt wird. Das Modul StringFilter (siehe Kapitel 11.3)
bietet mehrere statische Methoden, um Zeichenketten zu bearbeiten. StrTokenizer (siehe
Kapitel 11.4) ist eine Erweiterung des StringTokenizers und kann Teile von Zeichenketten,
die in Anführungszeichen oder Hochkomma stehen, als einzelnes Token behandeln.
TimeDiff (siehe Kapitel 11.8) berechnet den Unterschied zwischen Systemzeit und der Zeit
der letzten Änderung einer Datei.
KAPITEL 5 - SOFTWAREDOKUMENTATION
70
Installationsvoraussetzungen
Das komplette Programmpaket ist in der Programmiersprache Java implementiert, was
eine einfache Portierung auf beliebige Plattformen erlaubt. Zum ordnungsgemäßen
Funktionieren des Programmes ist eine Java-Umgebung wie JDK 1.1.8 oder JRE 1.1.8
bzw. Java 2 (vormals JDK 1.2) nötig.
Die Dokumente werden in einer relationalen Datenbank verwaltet. Dazu kann jede
beliebige relationale Datenbank-Engine verwendet werden, die eine JDBC-Schnittstelle
zur Verfügung stellt. Bei der Programmierung wurde darauf geachtet, nur ein Minimum an
SQL-Befehlen zu verwenden, da nicht jede Datenbank den vollen SQL-Befehlssatz
unterstützt.
Alle Programmteile sollten über den Klassenpfad von Java erreicht werden können,
sonst wird eine entsprechende Fehlermeldung ausgegeben. Bei Verwendung der
Suchfunktionalität ist ebenfalls das JSDK (Java Servlet Development Kit ab Version 2.0)
nötig. Es kann sein, daß in zukünftigen Versionen von Java JSDK bereits implementiert ist.
Die Installation des Servlets wird ebenfalls näher beschrieben (siehe Kapitel 9).
5.2 Zusammenfassung
In diesem Kapitel wurden die Vorteile eines verteilten Systems zur Informationsauffindung zusammengefaßt, die zur Implementierung der im Gestaltungsbereich entwickelten Module führen. Ein Überblick über die beim Gathervorgang zusammenarbeitenden
Module wurde gegeben und das intern verwendete Datenformat kurz erläutert. Das
Zusammenspiel der Programmteile zur Weitergabe der gesammelten Informationen an
übergeordnete Suchdienste wurde ebenfalls erklärt. Mit Hilfe dieser Programmteile können
die Informationen, die sich seit der letzten Datenübertragung geändert haben, von
übergeordneten Suchdiensten angefordert werden.
Eine weitere Möglichkeit, den lokalen Datenbestand zu nutzen stellt die entwickelte
Suchhilfe dar, die ebenfalls kurz beschrieben wurde. Über ein Webformular kann der
Anwender Suchbegriffe eingeben und erhält eine Liste der gefundenen Dokumente, wobei
die Dokumente nach Relevanz oder Änderungsdatum sortiert ausgegeben werden können.
In den folgenden Kapiteln wird auf die einzelnen Module, wie Gatherer (siehe Kapitel
6), HTML-Konverter (siehe Kapitel 7) und das Gatherer-Collector-Interface (siehe Kapitel
8) näher eingegangen. Dabei werden Funktionsweise und Konfiguration genau erklärt und
Beispiele für die Konfiguration gegeben. Kapitel 9 erläutert die Installation des
Suchservlets am Beispiel des Webservers Jigsaw und Kapitel 10 geht detailliert auf die
Struktur der verwendeten Datentabellen in der relationalen Datenbank ein. Dabei werden
auch die Vorgänge beim Einfügen oder Löschen eines Dokumentes beschrieben. Kapitel
11 gibt einen Überblick über weitere im Rahmen der Diplomarbeit entwickelten Module.
Kapitel 6
Der Gatherer
Der Gatherer ist für die eigentliche Beschaffung bzw. das Sammeln der DokumentenInformationen verantwortlich. Dazu wird neben dem Zugriff über das Dateisystem auch
HTTP1 unterstützt, so daß der Gatherer nicht notwendigerweise auf den zu indizierenden
Hosts lokal installiert sein muß, sondern wenn gewünscht, auch über das Web Daten
sammeln kann. Nach Möglichkeit sollte der Gatherer aber lokal auf dem zu durchforstenden Rechner arbeiten, auf dem die gewünschten Informationen liegen, da dann keine
aufwendigen Netzprotokolle verwendet werden müssen und verschiedene Vorteile genutzt
werden können (siehe Abschnitt 3.2). Dies gilt insbesonders bei größeren Datenmengen ab
etwa 1000 Objekten. Der Inhalt der empfangenen Dateien wird dann je nach Dateityp
(HTML oder Text) in ein zur weiteren Verarbeitung nötiges Format umgewandelt und in
einer Datenbank abgespeichert. Zusätzlich können alle Dokumente indiziert werden, um
Statistiken und Suchen im Datenbestand zu ermöglichen.
Unterstützt werden alle relationalen Datenbanken, die ein JDBC-Interface2 bieten, wobei
die JDBC-Unterstützung heute ein wichtiges Feature von Database Engines ist und
praktisch bei allen bekannten Datenbankprodukten mitgeliefert wird oder als Update
installiert werden kann. JAVA bietet außerdem eine JDBC-ODBC3 Schnittstelle, mit der
ebenfalls ein breiter Bereich von Datenbankprodukten abgedeckt wird. Der Nachteil ist,
daß hier eine zusätzliche Verwaltungsschicht verwendet wird und diese einen Performanceverlust bewirken kann. Die Konfiguration des Gatherers zur Verwendung einer
bestimmten Datenbank wird im Kapitel 10 erklärt.
Für die Konfiguration eines einfachen Gatherers genügt die Angabe der URLs, die
indiziert werden sollen, deren lokale Entsprechung im Dateisystem und ein paar
ergänzenden Informationen (siehe Abschnitt 6.3). Bei lokaler Verarbeitung wird auf
Verzeichnisse und deren Unterverzeichnisse zugegriffen. Wird auf HTML-Dokumente via
HTTP zugegriffen, können weitere Dokumente mittels Linkverfolgung ermittelt werden.
Das Verfahren der Linkverfolgung führt u.U. zur Erzeugung großer Datenmengen, darum
wurden standardmäßig einige Einschränkungen vorgenommen, die jedoch durch
verschiedene Optionen verändert werden können. Unter anderem kann bestimmt werden,
1
Hypertext Transfer Protocol, HTTP
2
JDBC, die Schnittstelle der Programmiersprache JAVA zu relationalen Datenbanken.
3
Open Database Connectivity, ODBC
KAPITEL 6 - DER GATHERER
72
wie viele Dokumente pro Durchgang durchforstet werden sollen, wie viele verschiedene
Hosts angesprochen werden dürfen oder bis zu welcher Tiefe (Verzeichnis- oder Linktiefe)
Dokumente verfolgt werden sollen. In der Konfigurationsdatei kann zusätzlich angegeben
werden, welche URLs nicht bearbeitet werden sollen. So können ganze Unterverzeichnisse
oder Teilbereiche von Servern selektiv ausgeschlossen werden.
Um ein regelmäßiges Update der Daten zu erhalten wird in der Konfigurationsdatei des
Gatherers der Zeitpunkt angegeben, zu dem mit dem Gathervorgang begonnen werden soll.
Hier sollten keine "runden" Stunden angegeben werden, um ein Überschneiden der
Startzeit mit anderen Systemdiensten zu vermeiden. Weiters ist noch die Angabe der Zeit
zwischen den Gatherzeitpunkten erforderlich, also nach welcher Zeit wieder mit dem
Gathern begonnen werden soll. Diese sollte sich daran orientieren, wie aktuell der
Datenbestand sein soll bzw. wie häufig sich die Dokumente ändern. Der Gatherer kann
somit an die Web-Site individuell angepaßt werden.
Damit die vom Gatherer gesammelten Dokumente weiterverwendet werden können, ist
eine Umwandlung in ein Metaformat notwendig. Gegenstand der vorliegenden Arbeit ist
es, einen Text- und einen HTML-Konverter zu implementieren, wobei der Gatherer
einfach erweitert werden kann, um Informationen aus anderen Formaten zu extrahieren.
Das Ergebnis des Konvertiervorganges ist ein Objekt AVTable (siehe Abschnitt 11.10).
Dieses ist im Grunde eine einfache Attribut-Wert-Tabelle und wird zum Datenaustausch
zwischen den einzelnen Modulen verwendet.
Eine weitere interessante Möglichkeit des Gatherers ist die Verarbeitung von Zusatzinformationen, die bestimmten HTML-Dokumenten oder ganzen Dokumentenstrukturen
zugeordnet werden können (siehe Abschnitt 6.4). Diese Zustatzinformationen sind
beispielsweise die Update-Frequenz einer Seite, die Mail-Adresse des Autors oder die
zuständige Redaktion. Die Informationen können verwendet werden, um genauere
Informationen über eine Web-Site zu erhalten, so daß etwa bei einer Suche bzw. im
Suchergebnis nichtrelevante Sites sofort als solche erkannt werden.
Auf die gesammelten Dokumenteninformationen kann über ein sogenanntes GathererCollector-Interface (siehe Kapitel 8) zugegriffen werden. Diese Informationen werden zur
Verfügung gestellt, damit andere Suchsysteme die Dokumente nicht neu durchforsten
müssen und die schon erarbeiteten Daten übernehmen können. Bisher wird ein großer Teil
der Web-Seiten gleichzeitig von mehreren Suchmaschinen abgesucht, was die Netzbelastung enorm erhöht. In Zukunft wird es nötig sein, einen Standard zu entwickeln, der es
erlaubt, einmal gesammelte Informationen mehrfach verwenden zu können. Ein kleiner
Schritt in diese Richtung ist dieses Interface. Es ist vom Interface des Harvest-Systems
(siehe Kapitel 3.4.1 – Harvest) abgeleitet und zu diesem kompatibel. Damit wird der
Datenaustausch mit übergeordneten Suchsystemen, die Informationen von mehreren unter
Umständen lokalen Gatherern sammeln, ermöglicht. Das Interface wurde erweitert, so daß
auch die oben erwähnten Zusatzinformationen abgerufen werden können.
6.1 Funktionsbeschreibung
Der Start des Gathervorganges erfolgt zu einem mittels Konfigurationsdatei einstellbaren Zeitpunkt. Alternativ kann beim Aufruf des Programms in der Kommandozeile eine
Startzeit angegeben werden, wobei dann die Angabe in der Konfigurationsdatei ignoriert
wird. Das Schlüsselwort "now" anstatt einer Zeitangabe veranlaßt den Gatherer, sofort mit
KAPITEL 6 - DER GATHERER
73
der Datensammlung zu beginnen. Das allgemeine Format für den Aufruf zeigt Listing 6.1.
java –Duser.timezone=ECT Gatherer [HH:mm|now] [-StandardLog Name]
[-ErrorLog Name]
Listing 6.1: Aufrufparameter des Gatherers
Der Parameter für die Java Virtual Machine –Duser.timezone=ECT ist unter Linux mit
Kernel 2.0.36 mit JDK 1.1.7A4 nötig, da sonst die bei den meisten europäischen Systemen
eingestellte Zeit CET nicht korrekt übernommen wird und in den Logdateien falsche
Ereigniszeiten eingetragen werden. Mit den Parametern StandardLog und ErrorLog können
alternative Logdateien angegeben werden. Fehlen diese Parameter, werden die Namen aus
der Konfigurationsdatei Log.cfg genommen.
Soll der Gatherer auf Unix Systemen auch nach dem Logout noch aktiv bleiben, so kann
man den Befehl "nohup"5, wie in Listing 6.2 gezeigt, verwenden:
nohup java –Duser.timezone=ECT Gatherer [HH:mm|now]
[-StandardLog Name] [-ErrorLog Name]
Listing 6.2: Start des Gatherers unter Unix
In der Konfigurationsdatei des Gatherers sind zwei Einträge, die zum Abbruch des
Programmes wichtig sind: Admin-Port und Password. Admin-Port gibt die Portnummer
des Administrator Interfaces an (siehe auch Kapitel 11.6). Um den Gatherer zu beenden,
erstellt man mit einem herkömmlichen Terminalprogramm, wie etwa Telnet, eine
Verbindung zu dem Rechner und Admin-Port auf dem er ausgeführt wird. Die Begrüßungsmeldung des Administrator Interfaces sieht man in Listing 6.3.
Administrator Interface
Please enter password for shutdown.
Password:
Listing 6.3: Meldung des Administrator Interfaces bei Beendigung des Gatherers
Nach Eingabe des korrekten Paßwortes (wie in der Konfigurationsdatei angegeben)
beendet der Gatherer den eventuell gerade aktiven Gathervorgang. Um das Interface über
die Kommandozeile zu beenden gibt es ebenfalls ein Programm. Mit dem Aufruf des in
Listing 6.4 gezeigten Moduls läuft die oben beschriebene Prozedur (Verbindung zum
Administrator-Port) automatisch ab und es wird eine entsprechende Erfolgs- bzw.
Fehlermeldung ausgegeben (siehe auch Kapitel 11.7).
java SendPassword [Hostname] Portnummer Password
Listing 6.4: Aufruf des Programms SendPassword zum Beenden des Gatherers
4
Java Linux, http://www.blackdown.org/
5
Engl. "no hang up" steht für nicht auflegen.
KAPITEL 6 - DER GATHERER
74
6.2 Beschreibung des Gathervorganges
Der Start des Gathervorganges erfolgt zu einem mittels Konfigurationsdatei (siehe
Abschnitt 6.3.1) bzw. Kommandozeile einstellbaren Zeitpunkt. Der Gatherer beginnt nun,
alle Dokumente und Verzeichnisse, die in der Sektion Gather der Konfigurationsdatei
aufgelistet sind, zu durchforsten. Dabei wird die Reihenfolge der Einträge beibehalten.
Scheinen im Laufe des Gathervorganges Dokumente bzw. URLs auf, die schon bearbeitet
wurden, was bei Überschneidung von Verzeichnisteilbäumen oder Links, die auf die selbe
Seite zeigen, leicht vorkommen kann, dann werden diese übergangen. Übernommen wird
ein Dokument nur einmal, und zwar mit den konfigurierten Einstellungen (siehe auch
Abschnitt 6.3.2), wie etwa der Time-To-Live des gerade aktiven Eintrages.
Um zu verstehen, wie der Gatherer arbeitet, ist es nötig, die verwendeten Begriffe wie
Last-Modification-Time, Update-Time und Time-To-Live genauer zu erklären. Alle Zeiten
werden in Sekunden angegeben und beziehen sich auf Mitternacht, 1. Jänner 1970 GMT.
In der Datenbank werden diese Zeitangaben als Long gespeichert, wobei praktisch alle
Datenbanken vorzeichenbehaftete 32-Bit Zahlen verwenden. Daraus resultiert ein Jahr2038-Problem6 bei vielen Computern, da hier ein Überlauf auf negative Zahlen stattfindet
(bei vorzeichenlosen Systemen wird das Problem erst 2106 auftreten). Java-intern werden
64 Bit für Long verwendet, das Problem läßt sich also mit Verwendung von Datenbanken
umgehen, die ebenfalls 64 Bit für Long verwenden.
Die Last-Modification-Time eines Dokuments ist die Zeit, zu der es das letzte Mal
bearbeitet wurde. Ändert sich diese Zeit, wurde also das Dokument mit großer Wahrscheinlichkeit geändert7. Die Update-Time eines Dokuments gibt an, wann es zuletzt mit
dem Gatherer auf Veränderungen überprüft wurde. Die Time-To-Live gibt an, wie lange
das Dokument nach dem letzten erfolgreichen Update noch in der Datenbank verbleiben
soll. Wird ein Dokument nicht mehr gefunden (weil es zum Beispiel gerade bearbeitet wird
und derzeit nicht zugreifbar ist), wird die Update-Time nicht mehr aktualisiert. Wird das
Dokument bei mehreren aufeinanderfolgenden Gathervorgängen nicht gefunden, wird es
nach Ablauf der Time-To-Live aus der Datenbank entfernt. Durch diese Methode werden
die Datenbankeinträge konsistent gehalten.
Um zu ermitteln, ob sich ein Dokument seit dem letzten Gathervorgang geändert hat,
prüft der Gatherer die Last-Modification-Time. Diese wird bei lokalem Zugriff über das
Dateisystem korrekt zurückgegeben. Wird auf Dokumente aber mittels HTTP zugegriffen,
kann es unter Umständen Probleme geben. Manche Webserver geben die Last-Modification-Time nicht im HTTP-Header an. Ist das der Fall, wird automatisch die MD5Checksumme [RFC1321] der Datei gebildet, wobei aber das gesamte Dokument
angefordert werden muß. Diese Checksumme ist eine 16-Byte Zahl, mit der Unterschiede
zwischen Dateien festgestellt werden können, auch wenn die Abweichung nur wenige
Zeichen beträgt.
Bei der Behandlung von Dokumenten durch den Gatherer gibt es drei Möglichkeiten:

Werden neue Dokumente entdeckt oder sind bereits gesammelte Dokumente verändert
worden, dann werden diese in die Datenbank übernommen.
6
Der Überlauf erfolgt am 19. Jänner 2038 4:14:07 GMT+1:00.
7
Die Dateizeit kann auch geändert werden, ohne daß sich der Inhalt der Datei ändert.
KAPITEL 6 - DER GATHERER
75

Trifft der Gatherer auf unveränderte Dokumente, dann wird nur der erneute
Gatherzeitpunkt des Dokuments in der Datenbank und im Objekt selber vermerkt (dies
geschieht im Attribut Update-Time).

Wurden Dokumente gelöscht, oder kann auf diese im Moment nicht zugegriffen
werden, dann ist keine Aktualisierung möglich. Damit die Dokumente aber nicht sofort
aus der Datenbank gelöscht werden, kann man die Zeit in Sekunden, die das Dokument
in der Datenbank seit dem letzten erfolgeichen Update erhalten bleiben soll, mit einem
Parameter festlegen (Time-To-Live). Erst wenn diese Zeit überschritten ist, fällt das
Dokument aus dem Datenbestand.
Die gefundenen Dokumente werden in eine Datenbank übernommen, wobei der
Gatherer im Zuge der vorliegenden Arbeit HTML- und Textdokumente unterstützt. Hier
kann aber leicht eine Funktion zur Erkennung des Dokumenten- bzw. Dateiformates
implementiert und der entsprechende Konverter gestartet werden. Im anschließenden
Arbeitsgang werden alle Dokumente, die nicht mehr im Dateisystem oder im Web
gefunden wurden und deren Time-To-Live abgelaufen ist, aus der Datenbank entfernt. Das
gleiche Prinzip der Dokumentenbearbeitung wird bei den Zusatzinformationsdateien
verwendet (siehe Kapitel 10.2.2.2 – Zusatzinformationen). Hier wird in analoger Weise mit
Last-Modified-Time, Time-To-Live und MD5-Checksummen gearbeitet.
Ist der gesamte Vorgang abgeschlossen, wird die Zeit bis zum nächsten Start des
Gatherers berechnet. Diese ergibt sich aus der Refresh-Rate (angegeben in der Konfigurationsdatei des Gatherers) und ist die Zeit zwischen dem Start des gerade abgeschlossenen
Vorganges und dem nächsten Sammeldurchgang. Der Gatherer ist zwischen den
Gathervorgängen inaktiv und verbraucht keine Rechenzeit.
Zum Beenden des Gatherers kann zu einem beliebigen Zeitpunkt über das Administrator-Interface der Befehl zum Abbruch gegeben werden. Die Port-Nummer und das nötige
Paßwort sind in der Konfigurationsdatei des Gatherers angegeben (siehe auch Abschnitt
6.3.1). Das Interface ist textbasiert und man kann mit einem herkömmlichen Terminalprogramm wie Telnet das Paßwort eingeben. Ist das Paßwort korrekt, wird der Gatherer
beendet. Mit dem Programm SendPassword (siehe Abschnitt 11.7) kann dieser Prozeß wie
in Listing 6.4 gezeigt automatisiert werden.
6.3 Konfiguration des Gatherers
Der Gatherer ist flexibel konfigurierbar und erlaubt das Durchforsten von Dokumenten
und Zusatzinformationsdateien zu regelmäßigen Zeitpunkten. In der ersten Sektion
(Config) können allgemeine Parameter wie der Name des Gatherers oder der Gathererstartzeit angegeben werden. Sektion Gather beschreibt alle zu bearbeitenden Dokumente
bzw. Dokumentstrukturen8, wobei die Bearbeitungstiefe einfach konfiguriert werden kann.
Eine weitere Sektion (Disallow) gibt URLs an, die vom Gatherer ignoriert werden sollen.
Sektion Info ist gleich aufgebaut wie Sektion Gather, beschreibt aber Zusatzinformationen
zu Dokumenten bzw. Dokumentenstrukturen.
8
Bei Angabe eines Verzeichnisses oder über Linkverfolgung können pro Eintrag
mehrere Dokumente durchforstet werden.
KAPITEL 6 - DER GATHERER
76
6.3.1 Sektion Config
In dieser Sektion werden alle für den Gatherer notwendigen Konfigurationsdaten, wie
der Name des Gatherers und die Gatherzeiten angegeben.
Name
Der Name dieses Gatherers. Dadurch ist es, wenn mehrere Gatherer Informationen
sammeln und die Informationen von einem übergeordneten Broker übernommen werden,
später möglich, herauszufinden, von welchem Gatherer diese Informationen stammen.
Gatherer-Name und Gatherer-Version werden als Attribut-Wert-Paare in die Dokumenteninformation übernommen.
Version
Die aktuelle Version des Gatherers. Sie sollte nur bei Softwareänderungen angepaßt
werden, so daß man feststellen kann, mit welcher Version die einzelnen Dokumente
bearbeitet wurden.
StartTime
Der Gatherer beginnt bei Programmstart nicht sofort mit seiner Arbeit, sondern erst zur
angegebenen Startzeit. Diese liegt innerhalb 24 Stunden ab dem Programmstart. Wird
beispielsweise der Gatherer um 15:00 aufgerufen und der Parameter Gatherer-Start ist auf
13:10 gesetzt, dann beginnt der Gathervorgang am nächsten Tag um 13:10. Der GathererStart sollte auf Zeiten mit geringer Web-Site- bzw. Rechneraktivität gelegt werden,
beispielsweise um 03:10 morgens für europäische Server9.
Refresh-Rate
Damit die Aktualität der Dokumente gewährleistet ist, müssen diese regelmäßig auf
Änderungen überprüft werden. Die Zeit in Sekunden zwischen den einzelnen Gathervorgängen wird mit diesem Parameter festgelegt und wird jeweils von der letzten Startzeit
weg gerechnet. Ist etwa eine Aktualisierung alle 24 Stunden gewünscht, dann gibt man
24*60*60 = 86400 Sekunden an. Der Start des Gathervorganges erfolgt dann ab der
Startzeit (z.B. 3:10) alle 24 Stunden und zwar immer um 3:10. Dauert der Gathervorgang
länger als die Refresh-Rate, dann werden ein oder mehrere Aktualisierungen ausgelassen.
Der darauffolgende Start erfolgt zur nächsten gültigen Startzeit, d.h. Gatherer-Start +
n*Refresh-Rate.
Time-To-Live
Der Gatherer aktualisiert bei jedem Arbeitsgang die Dokumente in der Datenbank. Sind
Dokumente in der Datenbank, die nicht aktualisiert werden konnten, werden diese nach
einer gewissen Zeit ab dem letzten erfolgreichen Update aus der Datenbank gelöscht.
Diese Zeit ist die Time-To-Live und wird in Sekunden angegeben. Sie ist der Defaultwert
für Dokumente, in der Sektion Gather kann man für Dokumente jeweils eine eigene Zeit
eintragen. Der Parameter Time-To-Live ist notwendig, da kurzzeitig Verzeichnisse nicht
zugreifbar sein können, wenn etwa Dokumente bearbeitet werden. Falls gerade ein
9
Der Grund für die Startverschiebung um 10 Minuten zur vollen Stunde ist schon
beschrieben worden; es soll nur ein überschneiden der Arbeitszeit mit anderen
Systemdiensten, die zur vollen Stunde starten, vermieden werden.
KAPITEL 6 - DER GATHERER
77
Gathervorgang stattfindet, würden alle Dokumente in dem gesperrten Verzeichnis aus der
Datenbank gelöscht werden, auch wenn sich keine Änderung ergibt. Die Time-To-Live
sollte daher mindestens doppelt so groß sein wie die Zeit zwischen zwei Gathervorgängen.
Änderungen dieses Parameters wirken sich nur auf neue bzw. geänderte Dokumente aus,
da die Time-To-Live individuell zu jedem Dokument in der Datenbank gespeichert wird
und erst bei einem Neueintrag wieder übernommen wird.
CheckMD5
Ist dieser Parameter ungleich 0, wird auf jeden Fall neben der Last-Modification-Time
auch die MD5-Checksumme des Dokuments auf Veränderungen geprüft. Normalerweise
ist es nicht nötig10, diese Funktion zu aktivieren, außer es gibt Probleme und Dokumente
werden immer wieder neu in die Datenbank übernommen obwohl keine Änderungen
vorgenommen wurden.
File-Time-Factor und File-Time-Offset
Von Java aus kann zwar auf die Last-Modification-Time einer Datei im Dateisystem
zugegriffen werden, doch wird diese (bis JDK 1.1.7, Windows NT) nicht in die richtige
Systemzeit umgerechnet, so daß kein Vergleich mit der aktuellen Zeit möglich ist. Aus
diesem Grund kann man mit dem Programm TimeDiff (siehe Kapitel 11.8 – TimeDiff) den
Unterschied der Systemzeit zur Dateizeit berechnen. Das Ergebnis der Berechnung trägt
man mit diesen beiden Parametern in die Konfigurationsdatei des Gatherers ein. Dateizeit
und Systemzeit kann man dann nach der Formel in Listing 6.5 ineinander umrechnen.
SystemTime = FileTime / File-Time-Factor – File-Time-Offset
Listing 6.5: Formel zur Umrechnung von Filezeit in Systemzeit
File-Time-Offset wird in Stunden angegeben, File-Time-Factor ist ein Umrechnungsfaktor,
falls die Zeitskalen unterschiedlich sind (z.B. Dateizeit in Sekunden und Systemzeit in
Millisekunden).
URL-Attribute
Wenn mittels HTTP Dokumente über das Netz bearbeitet werden und von diesem
Dokument ausgehend weitere Links verfolgt werden sollen, muß der Gatherer das Attribut
kennen, in dem mit dem HTML-Konverter die URLs abgelegt worden sind. Der
Attributname der URLs kann aus der Konfigurationsdatei für den Konverter entnommen
werden (zum Beispiel aus dem Eintrag für A:Href) und wird meistens URL-References
genannt.
Admin-Port und Password
Admin-Port gibt die Portnummer des Administrator-Zuganges an und Password das
Kennwort zum Beenden des Gatherers. Um den Gatherer zu beenden erstellt man mit
einem herkömmlichen Terminalprogramm wie Telnet eine Verbindung zu dem Rechner
und Admin-Port auf dem das Interface läuft. Nach Eingabe des korrekten Paßwortes wird
der Gatherer beendet. Mit dem Programm SendPassword (siehe Abschnitt 11.7) kann
dieser Prozeß automatisiert werden.
10
sofern das Last-Modification-Time Attribut verläßlich existiert.
78
KAPITEL 6 - DER GATHERER
Type
Mit diesem Parameter wird angegeben, ob der Gatherer nur Dokumente sammeln soll,
damit auf sie über das Gatherer-Collector-Interface (siehe Kapitel 8) zugegriffen werden
kann, oder ob die im Dokument vorkommenden Wörter indiziert werden sollen. Nur mit
eingeschalteter Indizierung ist eine Suche über das Suchservlet (siehe auch Kapitel 9)
möglich. Die Indizierung wird bei Angabe von "Index" aktiviert, jeder andere Wert
deaktiviert sie.
Das Listing 6.6 zeigt eine Beispielkonfiguration dieser Sektion.
[Config]
Name
Version
StartTime
Type
Refresh-Rate
Time-To-Live
Admin-Port
Password
URL-Attribute
File-Time-Factor
File-Time-Offset
CheckMD5
Kulturgatherer
1.0
17:47
NoIndex
60000
10
9002
dodo
URL-References
1
0
no
Listing 6.6: Beispiel einer Konfiguration der Config-Sektion des Gatherers
6.3.2 Sektion Gather
In dieser Sektion werden alle zu bearbeitenden Dokumente festgelegt. Jede Zeile dieser
Sektion bildet einen Eintrag, der entweder eine lokale Datei, eine lokales Verzeichnis oder
eine URL im Web beschreibt. Ein Eintrag hat die in Listing 6.7 angegebene Form.
HTTP-URL [[file:///]lokales File oder Verzeichnis] [DepthMax=a]
[URLMax=b] [HostMax=c] [TTL=d]
Listing 6.7: Format eines Eintrags der Sektion Gather der Konfigurationsdatei

HTTP-URL
Das ist die Adresse der zu bearbeitenden Seite auf dem Webserver, unter der das
Dokument über das Web mittels HTTP-Gateway erreichbar ist. Die erste Implementierung unterstützt nur das HTTP-Protokoll. Verweise auf Verzeichnisse sollten mit
einem Slash '/' abgeschlossen werden, wobei das nur bei zusätzlicher Angabe eines
lokalen Verweises von Bedeutung ist. Eine eventuell angegebene Portnummer des
Servers kann durch Doppelpunkt vom Servernamen getrennt angegeben werden.

Lokale Datei oder Verzeichnis
Wird zusätzlich dieser Parameter angegeben, wird das Dokument nicht über das Web
sondern lokal über das Dateisystem geholt. Dadurch müssen keine aufwendigen
79
KAPITEL 6 - DER GATHERER
Netzprotokolle verwendet werden. Der Parameter gibt ein lokales Verzeichnis bzw.
eine lokale Datei an, deren Entsprechung im Netz die HTTP-URL ist. Dabei bleibt es
dem Anwender freigestellt, ob er die URL-Schreibweise mit 'file:///' verwendet oder
nur den Pfad angibt. Es gibt keinen Unterschied bei Pfadangaben unter MS-DOS bzw.
Windows oder UNIX; bei beiden sollte als Trennzeichen zwischen den Verzeichnissen
das Zeichen Slash '/ verwendet werden, Backslash wird aber ebenfalls akzeptiert.
Verweise auf Verzeichnisse müssen mit einem Slash abgeschlossen werden.
Bei gleichzeitiger Angabe einer HTTP-URL und eines lokalen Verweises sind einige
Besonderheiten, wie in Tabelle 6.1 gezeigt, zu beachten.
HTTP-URL Lokale URL Besonderheiten
Datei
Datei
Keine Besonderheiten.
Datei
Verzeichnis
Wenn die HTTP-URL auf eine Datei im Web verweist,
die lokale URL aber auf ein Verzeichnis, wird
automatisch versucht, diese Datei in dem angegebenen
lokalen Verzeichnis zu finden. Sollte die HTTP-URL
eigentlich auf ein Verzeichnis verweisen und ist nur
der abschließende Slash zur Kennzeichnung des
Verzeichnisses nicht eingetragen worden, greift der
Gatherer jetzt auf eine falsche Datei zu.
Verzeichnis
Datei
Wird ebenfalls akzeptiert, da es im Web Standard ist,
bei Zugriff auf eine URL, die auf ein bestimmtes
Verzeichnis verweist, gleich ein Dokument zu
retournieren (meist index.html).
Verzeichnis
Verzeichnis
Abschließender Slash muß unbedingt angeben werden
(siehe auch Datei/Verzeichnis Problem).
Tabelle 6.1: Besonderheiten der Sektion Gather der Gathererkonfigurationsdatei

DepthMax
Hier gibt es zwei mögliche Interpretationen dieses Wertes. Wird lokal über das
Dateisystem zugegriffen und ist der lokale Verweis ein Verzeichnis, beschreibt dieser
Wert die Verzeichnistiefe, bis zu der ausgehend vom lokalen Verweis Dokumente
gesucht werden sollen. Null heißt, daß nur das angegebene Verzeichnis bearbeitet wird.
Bei Tiefe Eins wird auch noch eine Ebene aller Unterverzeichnisse untersucht. Ist nur
die HTTP-URL angegeben und keine lokale Entsprechung, werden weitere Dokumente
mittels Linkverfolgung ermittelt. Dabei werden alle Links, die aus dem Dokument
geparst werden und im Attribut URL-Attribute enthalten sind (siehe auch Sektion
Config im Kapitel 6.3.1) untersucht. Tiefe Null bedeutet, daß nur das aktuelle Dokument untersucht wird. Bei Tiefe Eins werden ebenfalls alle Dokumente, auf die das
aktuelle Dokument Referenzen hat, abgesucht. Der Default-Wert ist Null.

URLMax
Mit diesem Parameter kann man die Obergrenze der Anzahl zu untersuchender
Dokumente des aktuellen Eintrages festlegen. Auch wenn die zu untersuchende Tiefe
bei einem Eintrag nur gering ist, kann die Anzahl Dokumente schon sehr groß werden,
80
KAPITEL 6 - DER GATHERER
da die Struktur eines Webservers mehr in die Breite als in die Tiefe geht. Es ist immer
ratsam, die maximal zu bearbeitenden Dokumente anzugeben. Der Default-Wert ist 50.

HostMax
Dieser Parameter hat nur Bedeutung, wenn Dokumente über HTTP geholt werden. Bei
lokaler Ermittlung von Dokumenten werden nur Verzeichnisse untersucht und es gibt
keine Möglichkeit, daß Dokumenten von anderen Hosts bearbeitet werden. Werden
aber Links verfolgt, können diese sehr wohl auf andere Hosts verweisen. Die Anzahl
der untersuchten Hosts kann mit diesem Parameter eingeschränkt werden. Default ist 1.

TTL – Time to Live
Zeit in Sekunden, die Dokumente nach dem letzten erfolgreichen Update noch in der
Datenbank verbleiben sollen, bevor sie gelöscht werden. Wird dieser Parameter nicht
angegeben, wird die Time-To-Live in der Sektion Config (siehe auch Kapitel 6.3.1)
verwendet.
Ein spezieller Wert für DepthMax, URLMax und HostMax ist INF11. Damit kann die
Begrenzung für obige Parameter aufgehoben werden. Vorsicht: Es sei darauf hingewiesen,
daß die untersuchte Datenmenge leicht sehr groß werden kann, wenn keine Begrenzung
mehr vorhanden ist! Eine Auflistung der Default-Werte gibt Tabelle 6.2.
Parameter
Default
Bedeutung
DepthMax
0
Nur die angegebene Datei, das angegebene
Verzeichnis bzw. die angegebene URL wird
bearbeitet.
URLMax
50
Maximal werden 50 URLs untersucht.
HostMax
1
Nur ein Host wird abgesucht.
TTL
Time-To-Live
Time-To-Live der allgemeinen Parameter des
Gatherers wird übernommen.
Tabelle 6.2: Defaultwerte in der Sektion Gather der Gathererkonfigurationsdatei
In folgendem Beispiel (Listing 6.8) sind Einträge für die Sektion Gather aufgeführt. Der
erste Eintrag untersucht das Lokale Verzeichnis "d:\Webserver\html\". Dabei werden
nur höchstens 50 Dokumente gesammelt und nicht in Unterverzeichnisse verzweigt. Wird
beispielsweise im Verzeichnis die Datei "Graz.html" gefunden, erhält sie in der
Datenbank den Uniform Resource Locator http://www.server.com/Graz.html. Der
zweite Eintrag konfiguriert den Gatherer zur Sammlung von maximal 5 Dokumenten des
Web-Servers www.remotehost.edu.
Sollen wieder Dokumente über das Dateisystem abgesucht und auch auf Unterverzeichnisse zugegriffen werden können, dann gibt man, wie im dritten Eintrag in Listing
6.8, die gewünschte maximale Verzeichnistiefe an.
[Gather]
http://www.server.com/
11
d:\Webserver\html\
INF steht für infinitive, engl. für unendlich.
KAPITEL 6 - DER GATHERER
http://www.remotehost.edu
URLMax=5 HostMax=1
http://www.localhost.com/
/Webserver/Home/ DepthMax=2 URLMax=20
http://www.somehost.at/
/WebDir/index.html
http://www.java.com/java/
file:///d:/java/projects/
http://host.at/ /test/ URLMax=INF DepthMax=INF (ACHTUNG, Anzahl!)
http://www.myhost.at/MP3.html
/MyDir/MP3.html TTL=700000
Listing 6.8: Beispiel einer Konfiguration der Gather-Sektion des Gatherers
Zu den gesammelten Objekten werden vom Gatherer folgende Attribute hinzugefügt:

Gatherer-Name

Gatherer-Version

Hostname der Rechners, auf dem der Gatherer läuft

Refresh-Rate

Time-To-Live des Objektes
Listing 6.9 zeigt ein SOIF-Objekt mit vom Gatherer zusätzlich erzeugten Attributen.
@FILE { http://www.heise.de/tp/enfopol.html
Gatherer-Name{22}:
Heise Verlag
Gatherer-Host{17}:
www.heise.de
Gatherer-Version{3}: 1.0
Headings{29}:
Das neue Ermaechtigungsgesetz
Last-Modification-Time{9}: 914875680
Update-Time{9}: 914876030
Time-to-Live{7}:
1296000
Refresh-Rate{6}:
604800
Pictures{16}:
/Bilder/eu.jpg
Keywords{61}:
ENFOPOL
Entmuendigung
Europaeischen
Union
File-Size{3}:
630
Type{4}: HTML
Author{37}:
Artur P. Schmidt und Otto E. Roessler
Body{283}: Das neue Ermaechtigungsgesetz
ENFOPOL oder die Entmuendigung der Buerger Es geht ein neues
Gespenst um in Europa, ein Ermaechtigungsgesetz zur Entmuendigung
der Buerger. Das Papier heisst ENFOPOL und wurde am 03. September
vom Rat der Europaeischen Union als Entwurf verabschiedet.
URL-References{57}:
http://www.heise.de/tp/deutsch/special/enfo/6332/1.html
MD5{32}: 4b0c57d92b5180441d8c4586e37edd92
Title{29}: Das neue Ermaechtigungsgesetz
}
Listing 6.9: SOIF mit vom Gatherer hinzugefügten Attributen; diese sind grau unterlegt
81
82
KAPITEL 6 - DER GATHERER
6.3.3 Sektion Info
In dieser Sektion werden die einzelnen Zusatzinformationsdateien angegeben (siehe
auch Abschnitt 6.4). Jede Zeile besteht aus zwei URL-Referenzen. Die erste gibt die URL
an, für die die Informationen der Datei gelten, auf die sich die zweite URL bezieht. Per
Definition kann die Informationsdatei für alle untergeordneten Objekte in der Dokumentenstruktur gelten. Werden dann für eines dieser Dokumente andere oder erweiterte
Informationen benötigt, kann man zusätzliche Informationsdateien eintragen. Listing 6.10
verdeutlicht das, indem zuerst Informationen für einen gesamten Server definiert
(Steiermark) und anschließend detailliertere Angaben zum Bereich Graz gemacht werden.
[Info]
http://www.styria.at/
http://www.styria.at/Graz
/infofiles/Steiermark.info
/infofiles/Graz.info
Listing 6.10: Beispiel einer Konfiguration der Info-Sektion des Gatherers
Die Informationsdateien können genau so wie die Dokumente über das GathererCollector-Interface abgefragt werden (siehe Kapitel 8 – Das Gatherer-Collector-Interface).
Das Dateiformat für Zusatzinformationen ist im Abschnitt 6.4 spezifiziert.
6.3.4 Sektion Disallow
Die Einträge dieser Sektion geben URLs bzw. Teile von URLs an, die nicht vom
Gatherer besucht werden sollen. So lassen sich ganz leicht komplette Unterverzeichnisse
oder Teilbereiche von Servern ausschließen. Jede URL, die mit einem der angegebenen
Einträge beginnt, wird nicht bearbeitet. Dabei ist der Pfad und die Dateiangabe case
sensitiv, der Hostname und das Protokoll nicht. Die Definition der Sperre orientiert sich
am Disallow-Teil der Robots-Empfehlung des WWW-Konsortiums [WRD1998a]. Diese
Empfehlung dient dazu, automatische Suchprogramme, die Informationen über Dokumente
im Web sammeln, von bestimmten Sites bzw. Teilbereichen fernzuhalten und zwar mittels
einer Datei namens Robots.txt im Root-Verzeichnis der Web-Site. Eine Erweiterung des
Gatherers wäre ein zusätzlicher Parameter in der Sektion Gather, der angibt, wo für lokale
Gathervorgänge, die jeweilige Robot-Datei zu finden ist. Das Meta-Tag Robots in den
Dokumenten wird hingegen vom Gatherer beachtet (siehe Abschnitt 6.5).
Die Defaultportnummer bei Verwendung des HTTP-Protokolls ist 80 und wird auch in
dieser Sektion berücksichtigt. Die Einträge http://server/ und http://server:80
sind also ident. Zwischen Hostangaben mit Namen und Hostangaben mittels IP-Adresse
wird unterschieden. Verhindert man also etwa den Zugriff auf http://server/, kann der
Gatherer unter Umständen noch immer mit http://x.y.z.c/ auf diesen Server
zugreifen. Listing 6.11 zeigt, wie man Bereiche vom Gathervorgang ausschließt.
[Disallow]
http://www.site.com/DiesesFileUndOderVerzeichnisNicht
http://www.site.com:8080/DiesesVerzeichnisNicht/
Listing 6.11: Beispiel einer Konfiguration der Disallow-Sektion des Gatherers
KAPITEL 6 - DER GATHERER
83
6.4 Zusatzinformationen
Zusätzliche Informationen über Dokumente oder über ganze Web-Sites können für
Anwender bei der Suche sehr nützlich sein. Die Information, die man durch das
Konvertieren und automatisierte Extrahieren der Dokumente bekommt ist oftmals nicht
ausreichend, um den Inhalt einer Seite zu beschreiben. Aus diesem Grund ist es notwendig,
zusätzliche Beschreibungen über den Server oder die Web-Site mitzuberücksichtigen
(siehe Abschnitte 2.3.4 und 3.2.4). In diesen Beschreibungen können noch weitere
Informationen, wie Webmaster, Update-Frequenz, Bezüge und Verweise zu anderen
Datenbanken etc. enthalten sein.
Diese Informationsdateien können bestimmten URLs zugeordnet werden und gelten
entweder für ganze Web-Sites (etwa die allgemeine Beschreibung des Gesamtinhalts eines
Servers) oder für einzelne HTML-Dokumente. Das Übernehmen der Informationsdaten in
die Datenbank geschieht nach dem selben Prinzip wie bei Dokumenten (siehe Kapitel
6.3.2). Es werden nur neue oder geänderte Informationsdateien abgearbeitet, bei bereits
bearbeiteten Dateien wird nur die Update-Time korrigiert. Nicht mehr gefundene
Informationsdateien werden nach Ablaufen der Time-To-Live der Sektion Config bezogen
auf die letzte Update-Time aus der Datenbank entfernt.
Jede Zeile einer Informationsdatei beschreibt ein Attribut mit zugehörigem Wert (siehe
Listing 6.12). Dabei können beispielsweise Verweise auf ähnliche Informationen oder
Quellenangaben bzw. Bewertungen zur Wichtigkeit inkludiert sein.
update
priority
info
other info
author
=
=
=
=
=
weekly
high
News in the computer world
http://www.ix.de/newsticker
[email protected]
Listing 6.12: Beispiel einer Informationsdatei
6.5 Meta-Tag Robots
Das Meta-Tag Robots (siehe auch Kapitel 4.1.2 – Meta-Tags) in Dokumenten gibt einige
Vorschläge, wie der Gatherer mit diesem Dokument verfahren soll. Das Tag wird, wie in
Listing 6.13 gezeigt, in der Head-Sektion angegeben.
<!doctype html public "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>Funny Bones - Candy Company Ltd.</title>
<meta name="robots" content="index, nofollow">
<meta name="descrition" content=" { ... text ... } ">
</head> { ... }
</html>
Listing 6.13: Beispiel eines HTML-Dokuments mit Robots-Tag
KAPITEL 6 - DER GATHERER
84
Tabelle 6.3 zeigt eine Aufstellung möglicher Werte:
Wert
Bedeutung
INDEX
Indizieren dieses Dokuments.
NOINDEX
Dieses Dokument nicht indizieren.
FOLLOW
Verfolgen der Links in diesem Dokument.
NOFOLLOW
Links in diesem Dokument nicht verfolgen.
NONE
Dieses Dokument mit all seinen Links ignorieren.
ALL
Bearbeitung des Dokuments ist freigestellt.
Tabelle 6.3: Bedeutung des Inhalts des Robots-Tag
Logische Kombinationen dieser Attributwerte können, durch Kommata getrennt,
aneinander gereiht werden. Das Beispiel in Listing 6.14 bedeutet "indiziere dieses
Dokument, doch verfolge nicht seine Links".
<meta name="robots" content="INDEX, NOFOLLOW">
Listing 6.14: Meta-Tag Robots mit kombinierten Attributwerten
Da es viele unklare Kombinationen gibt, wie etwa INDEX und NONE gemeinsam,
wurden in diesem Projekt verschiedene Einschränkungen getroffen. Tabelle 6.4 gibt zeigt
eine Aufstellung, welche Werte werden vom Gatherer beachtet bzw. ignoriert werden.
Damit das Robot-Tag ausgewertet werden kann, sollte der HTML-Konverter so
konfiguriert werden, daß das Tag nicht gelöscht wird (siehe auch Abschnitt 7.1 –
Konfiguration des Konverters).
Wert
Reaktion des Gatherers
INDEX
Dieser Wert wird ignoriert. Das Dokument wird nur indiziert, wenn in
der Kofigurationsdatei des Gatherers als Typ Index angegeben ist.
NOINDEX
Das Dokument wird nicht indiziert.
FOLLOW
Wert wird ignoriert. Links im Dokument werden innerhalb der in der
Konfigurationsdatei angegebenen Grenzen verfolgt.
NOFOLLOW
Links im Dokument werden nicht verfolgt. Dieser Wert hat nur
Bedeutung, wenn über HTTP Dokumente verfolgt werden. Bei Zugriff
über das Dateisystem wird dieser Wert ignoriert.
NONE
Dieses Dokument mit all seinen Links wird ignoriert.
ALL
Wert wird ignoriert.
Tabelle 6.4: Reaktion des Gatherers auf Werte des Robots-Tags
85
KAPITEL 6 - DER GATHERER
6.6 Virtuelle Hosts
Der Gatherer ist auch in der Lage, mit virtuellen Hosts zu arbeiten. Für aussenstehende
sind virtuelle Hosts genauso unter einem bestimmten Rechnernamen erreichbar wie
normale Server. Der Unterschied ist, daß sich die virtuellen Web-Sites physikalisch auf ein
und demselben Rechner befinden und dieser unter verschiedenen Domains erreichbar ist.
Die Unterscheidung kann ein Webserver anhand der in der HTTP-Anforderung
übergebenen Adresse vornehmen. Auf dem Webserver sind die einzelnen Seiten der
virtuellen Server einfach in verschiedenen Verzeichnissen abgelegt, so daß über das
Dateisystem ein einfacher Zugriff auf die einzelnen Web-Sites möglich ist (siehe Listing
6.15).
[Adresses]
http://www.steiermark.com
http://www.graz.at
/WWW/steiermark/ urlmax=100 depthmax=2
/WWW/graz/
urlmax=inf depthmax=1
Listing 6.15: Beispiel der Konfigurationsdatei des Gatherers mit virtuellen Servern
6.7 Beispiel einer Konfigurationsdatei
Listing 6.16 zeigt ein Beispiel einer vollständigen Konfigurationsdatei für den Gatherer.
# Configurationfile Gatherer
#
# Refresh-Rate and Time-to-Live in seconds.
# Time-To-Live is the time an object stays in the database
# after the last successful update. Gatherer-Start is 24 hour
# time. Gatherer-Type is 'Index' or 'NoIndex'.
# Types other than 'Index' extract only documents for the
# Collector-Interface and no search or documents (e.g. using
# servlets) is possible.
[Config]
Name
TestGatherer
Version
1.0
StartTime
01:10
Type
Index
Refresh-Rate
86400
Time-To-Live
432000
Admin-Port
9002
Password
secret
# Name of reference-attribute for gathering into deep
# over http. Gatherer follows references automatically.
URL-Attribute
URL-References
# Difference file-time to system-time.
KAPITEL 6 - DER GATHERER
# Values for file-time can be estimated with utility DiffCalc.
# File-Time-Offset is measured in hours.
File-Time-Factor
1
File-Time-Offset
0
# Last-Modified-Time of the file-system is updated correctly,
# but not all Webservers return the correct Last-Modified# Time in the header field of the HTTP transmission. If
# necessary testing for modifications by MD5 checksum can
# be enabled with value <> 0, no or false.
CheckMD5
no
# Addresses to gather.
# Usage:
# URL [[file:///]localDirectoryOrFile] [DepthMax=x] [TTL=y]
#
[URLMax=a] [HostMax=b]
# - URL (http) of a document or directory. Directories must be
#
terminated with a slash.
# - localDirectoryOrFile is path to a local directory or file.
#
If this is specified the local directory tree is searched
#
and the gatherer does not follow url-references in the
#
documents. If URL specifies a file and
#
localDirectoryOrFile a directory then the same filename
#
is assumend (http://server/file /directory is
#
expanded to http://server/file /directory/file).
# - DepthMax to search in the directory tree (zero means only
#
actual directory) or depth of links to follow in the
#
documents (one means follow max one link). Default is
#
zero.
# - TTL is the time an object should remain in the database
#
after the last successful update (default: Time-To-Live
#
in [Config]).
# - URLMax number of URLs to gather max. Default is 50.
# - HostMax number of Hosts to gather max. Default is 1.
#
HostMax is ignored if the localhost (filesystem)
#
is to be searched.
#
# A special value for DepthMax, URLMax and HostMax is INF
# (infinitive) which means unlimited (be careful with that!).
#
# Example:
# http://serv.com:8080/ [file:///]d:/servdir/ DepthMax=INF
#
URLMax=5 TTL=100 HostMax=2
#
[Adresses]
http://www.test.com /java/javatut/ urlmax=100 depthmax=1
http://www.server.at d:\ urlmax=inf depthmax=inf
http://www.server.at c:\
http://www.test.at
http://www.ix.de/newsticker depthmax=5 urlmax=50 hostmax=5
# This section is for meta information files. The first
# parameter in each line is a Web address (http://) the
# second one is the URL of the info file (http:// or
86
87
KAPITEL 6 - DER GATHERER
# file:/// or directory/file).
[Info]
http://www.test.com/
http://www.ix.de/newsticker
file:///infos/javatut.info
\infos\news\ticker.info
# Values of this section specify a partial URL that is not to
# be visited. This can be a full path, or a partial path; any
# URL that starts with this string will not be retrieved.
# Protocol and hostname are case insensitive, path is not.
# For example:
# http://www.site.com/help disallows both
#
http://www.site.com/helpme.htm and
#
http://www.site.com/help/index.html,
# whereas http://www.site.com/help/ would disallow
#
http://www.site.com/help/index.html but allow
#
http://www.site.com/help.html.
[Disallow]
http://www.site.com:8000/NotThisFileOrDirectory
http://www.site.com/NotThisDirectory/
http://www.site.at/nothingThatStartsLikeThis
Listing 6.16: Beispiel einer vollständigen Konfigurationsdatei des Gatherers
Diese Datei konfiguriert einen Gatherer, wobei alle durchforsteten Dokumente auch
indiziert werden. Teils werden Dokumente über das Dateisystem geholt und teils mittels
HTTP. Zwei Informationsdateien zu den gesammelten Dokumenten werden ebenfalls in
die Datenbank aufgenommen.
6.8 Zusammenfassung
In diesem Kapitel wurde die Funktionsweise des Gatherers und die Konfiguration der
einzelnen Funktionskomponenten anhand von Beispielen genau erklärt. Der Gatherer ist
für die eigentliche Beschaffung bzw. das Sammeln der Informationen verantwortlich.
Neben dem Zugriff über das Dateisystem wird auch HTTP unterstützt. Bei lokaler
Verarbeitung mittels Dateisystem wird auf Verzeichnisse und deren Unterverzeichnisse
zugegriffen. Werden HTML-Dokumente via HTTP durchforstet, können weitere
Dokumente mittels Linkverfolgung ermittelt werden. Der eigentliche Vorteil einer
verteilten Informationsauffindung kommt aber erst bei lokaler Verarbeitung zum Tragen,
da hier, wie im Untersuchungsbereich gezeigt, signifikante Verbesserungen bei Serverund Netzbelastungen erreicht werden können (siehe auch Kapitel 3).
Der Gatherer ist flexibel konfigurierbar (siehe Abschnitt 6.3) und kann neben den
Dokumenten auch Zusatzinformationsdateien (siehe Abschnitt 6.4) bearbeiten. Der Zugriff
auf Dokumentenstrukturen von virtuellen Hosts ist ebenfalls möglich (siehe Abschnitt 6.6).
Mit Hilfe des im folgenden Kapitel beschriebenen HTML-Konverters (siehe Kapitel 7)
erzeugt der Gatherer ein zur weiteren Verarbeitung benötigtes Metaformat AVTable (siehe
auch Kapitel 11.10), das alle über ein Dokument oder Objekt bekannten Informationen
enthält. Dieses Metaformat dient, wie im Kapitel 5 angedeutet, als Grundlage des
Datenaustauschs innerhalb der Komponenten dieses Projekts.
Kapitel 7
Fehlertoleranter HTML-Konverter
Der Hauptteil aller Dokumente, die im World Wide Web angeboten werden, ist in der
Hypertext-Markup-Language, kurz HTML (siehe auch Abschnitt 4.1), verfügbar. HTML
ist eine Beschreibungssprache, die in einem Text bestimmte Passagen mittels Tags
kennzeichnet und damit formatiert, z.B. eine Überschrift hervorhebt.
Der hier beschriebene Konverter dient zur Umwandlung des HTML-Formates in eine
Form, die es erleichtert, auf einzelne Elemente dieser Seiten zuzugreifen. Werte von
HTML-Tags bzw. Informationen zwischen diesen Tags können einem beliebigen Attribut1
zugeordnet werden, wobei der Konverter den Inhalt der Tags auf die Attribute aufteilt
(siehe auch Abschnitt 11.10 – AVTable). So ist es etwa möglich, alle Überschriften in
einem Attribut zusammenfassen zu lassen, wobei dieses Attribut dann einen guten
Überblick über den Inhalt eines Dokuments geben kann. Es ist ebenfalls möglich,
automatisch Schlüsselwörter zu extrahieren, indem man beispielsweise alle kursiven oder
fettgedruckten Textstellen in ein eigenes Keyword-Attribut übernimmt. Der Konverter ist
frei konfigurierbar und kann mit beliebigen Tags arbeiten. Das Einsatzgebiet ist daher
nicht auf HTML beschränkt und es kann jede auf SGML aufbauende Markup-Sprache
ausgewertet werden.
Ein Großteil der HTML-Seiten ist mittels Texteditoren erstellt worden und viele der
Seiten im WWW entsprechen nicht der sehr rigorosen HTML-Spezifikation HTML 3.2
[HTML32] bzw. HTML 4.0 [HTML40]. Damit trotz der Nichteinhaltung der Spezifikation
möglichst alle Informationen aus einem HTML-Dokument extrahiert werden, wurde in
dieser Diplomarbeit ein Konverter entwickelt, der mit den auftretenden Fehlern möglichst
tolerant umgeht.
Der Konverter kann nicht nur HTML- sondern auch Textdateien behandeln, wobei die
Objekte in der vorliegenden Version anhand der Endung unterschieden werden. Aus
HTML-Dateien können wesentlich mehr Informationen extrahiert werden als aus
Textdateien. Dateien können, da der Konverter als Übergabeparameter eine URL (Uniform
Resource Locator, definiert in [RFC1738]) erwartet, entweder aus dem Dateisystem oder
über das Web geholt und konvertiert werden.
1
Attribute sind beispielsweise Überschrift, Titel und Schlüsselwörter. Sie bezeichnen
logische Teile eines Objektes und geben diesem eine einfache Struktur.
KAPITEL 7 - FEHLERTOLERANTER HTML-KONVERTER
89
Eine Erweiterungsmöglichkeit wäre ein Modul zur Ermittlung des Dateityps durch
Analyse des Dokumenteninhalts2. Es kann vom Gatherer aufgerufen werden, um zu
entscheiden, welcher Konverter aktiviert werden soll. In diesem Fall muß im Konverter die
Typenerkennung deaktiviert werden. Werden die Daten mittels HTTP geholt, kann der
MIME-Typ zur Erkennung herangezogen werden.
7.1 Konfiguration des Konverters
Der Konverter ist frei konfigurierbar, um einen möglichst flexiblen Einsatz zu gewährleisten. Prinzipiell kann angegeben werden, in welche Attribute der Attribut-Wert-Tabelle
welcher Teil eines Dokumentes extrahiert werden soll. Dies geschieht in der Sektion
ConvertTab der Konfigurationsdatei des Konverters. Die zweite wichtige Sektion,
Separator, gibt an, wie ein bestimmtes Attribut, beispielsweise Body (also Volltext)
zusätzlich gegliedert werden soll, um die Erkennung der ursprünglichen Struktur eines
Dokumentes zu ermöglichen, z.B. Absätze und Überschriften (siehe Abschnitt 7.1.2).
Diese Sektionen werden im folgenden erklärt.
Für die vollständige Konfiguration sind auch die Konfigurationsdateien der AVTable
(siehe auch Abschnitt 11.10) und des AVTableFilters (siehe auch Abschnitt 11.11) zu
beachten. Diese Module werden vom Konverter aufgerufen und erlauben die Konfiguration des Aussehens einzelner Attribute, also ob ein Attribut aus einzelnen Wörtern besteht
(für Schlüsselwörter) oder aus bestimmten Zeilen (Überschriften). Eine Nachbearbeitung
der einzelnen Attribute ist über die Konfiguration des AVTableFilters möglich. Das Modul
erlaubt es, Attribute zusammenzufügen, umzubenennen oder auch zu löschen. Attribute
wie Schlüsselwörter können sortiert und Duplikate entfernt werden.
7.1.1 Sektion ConvertTab
Die ConvertTab ist eine Art Übersetzungstabelle. Sie gibt an, welche Tags aus einem
HTML-Dokument extrahiert (Source-Tag) und unter welchem Namen (DestinationAttribute) der Inhalt dieser Tags zusammengefaßt werden soll. Tags sind nicht casesensitiv. Die Destination-Attribute sind case-sensitive, also 'Body' und 'body' ergeben
unterschiedliche Ziele. Der Konverter beachtet nur Tags, die in der ConvertTab
vorkommen, alle anderen Tags, also auch ungültige, werden ignoriert, womit die
Fehlertoleranz erhöht wird. Pro Zeile kann nur ein HTML-Tag angegeben werden, es sind
aber mehrere Destination-Attribute möglich, die durch Beistriche voneinander zu trennen
sind. Es gibt dabei die in den folgenden Abschnitten beschriebenen Besonderheiten und
reservierte Tags bzw. Attribute.
2
So ein Modul wird auch "Magic Number Test" genannt und wird verwendet, anhand
bestimmter Bytefolgen bzw. des Dateiinhalts den Typ einer Datei zu bestimmen.
KAPITEL 7 - FEHLERTOLERANTER HTML-KONVERTER
90
Source-Tags
NoTag
Steht für Text außerhalb aller Tags. Fehlertolerante Browser zeigen auch Text an, der, was
laut Spezifikation nicht erlaubt ist, außerhalb des <HTML>-Tags steht. Mit NoTag kann man
auch auf diesen Text zugreifen. NoTag muß nicht angegeben werden. Der Parser nimmt
standardmäßig NoTag mit Destination-Attribut Body an.
Tag:Attribut
Steht für den Inhalt eines bestimmten Attributes in einem Tag. Um beispielsweise aus
<IMG SRC="/images/ball.gif"> die URL des angezeigten Bildes zu erhalten,
verwendet man den in Listing 7.1 angegebenen Eintrag.
[ConvertTab]
Img:Src
Pictures
Listing 7.1: Eintrag der ConvertTab zum Extrahieren von Verweisen auf Bildern
Tag:Code
Ein Spezialfall ist, wenn aus einem HTML-Tag das Attribut Code extrahiert werden soll.
Um die richtige Adresse des Objektes zu bekommen, auf welches sich das Attribut Code
bezieht, ist es notwendig, ebenfalls den Inhalt des Attributes Codebase zu berücksichtigen,
da die vollständige URL des Objektes sich aus Codebase & Code zusammensetzt. Das ist
beispielsweise im Applet-Tag der Fall. Eine andere Möglichkeit ist, daß nur mehr das
Attribut Codebase vorhanden ist. All diese Fälle werden vom Konverter korrekt
berücksichtigt. Ein Beispiel (siehe Listing 7.2) erläutert die Extraktion.
[ConvertTab]
Applet:Code
Object:Code
Applets
Objects
ergibt aus dem nachstehendem HTML-Code:
<APPLET CODE=Simple.class CODEBASE="example/" WIDTH=500 HEIGHT=20>
<OBJECT id=iegrad1 type="application/x-oleobject"
codebase="http://server.com/ie/object2.ocx#version=4" w=500 h=50>
folgendes Ergebnis:
Applets example/Simple.class
Objects http://server.com/ie/object2.ocx#version=4
Listing 7.2: Beispiel zur Extraktion von Code und Codebase aus HTML-Tags
Script:Language
wird verwendet, um aus dem HTML-Tag Script das Attribut Language zu extrahieren.
Dort ist die Art der verwendeten Scriptsprache angeführt, wobei dieses Attribut nicht
notwendigerweise vorhanden werden muß. Bei Fehlen des Attributs wird der Default-Wert
KAPITEL 7 - FEHLERTOLERANTER HTML-KONVERTER
91
JavaScript in das angegebene Destination-Attribut eingetragen. Diese Annahme entspricht
dem Standardverhalten der gängigen Browser.
Destination-Attribute
Parent
Text wird zusätzlich an das nächstäußere Attribut übergeben (siehe erläuterndes Beispiel
zur Funktionsweise des Konverters).
Ignore
Der Text zwischen den Tags eines bestimmten Attributs wird ignoriert.
&Name
Text wird aus dem Attribut 'Name' genommen, was vor allem bei Meta-Tags verwendet
werden kann (siehe Abschnitt 4.1.2). Dies erläutert Listing 7.3.
HTML-Tag:
<META NAME="Abstract" CONTENT="Das ist eine Zusammenfassung.">
Konvertierungstabelle:
[ConvertTab]
Meta:Content
&Name
Wird extrahiert zu:
Meta:abstract
Das ist eine Zusammenfassung.
Listing 7.3: Beispiel zur Extraktion des Inhalts von Attributen in HTML-Tags
Erläuterndes Beispiel zur Funktionsweise des Konverters
Die Arbeitsweise des Konverters wird anhand folgendem Beispiels erklärt. Ein
Konvertierungsvorgang mit der in Listing 7.4 angegebenen ConvertTab erzeugt bei
bestimmten Inhalten nicht verwendbare Ergebnisse.
Konvertierungstabelle:
[ConvertTab]
Body
Text
B
Keywords
Ausschnitt aus einem HTML-Dokument:
<BODY>Das ist ein <B>Test</B> des Konverters.</BODY>
Wird extrahiert zu:
Text
Das ist ein des Konverters.
Keywords
Test
Listing 7.4: Beispiel für falsche Konfiguration des Konverters
KAPITEL 7 - FEHLERTOLERANTER HTML-KONVERTER
92
Man sieht, daß im Text-Attribut ein Wort fehlt und dieses nur in das Attribut Keywords
übernommen wurde. Aus diesem Grund gibt es das reservierte Destination-Attribut Parent,
das den Text auch an das nächstäußere Tag (hier Body) übergibt. Für die korrekte Funktion
sollte die ConvertTab daher so wie in Listing 7.5 aussehen.
Konvertierungstabelle:
[ConvertTab]
Body
Text
B
Keywords, Parent
Ausschnitt aus einem HTML-Dokument:
<BODY>Das ist ein <B>Test</B> des Konverters.</BODY>
Damit ergibt sich:
Text
Das ist ein Test des Konverters.
Keywords
Test
Listing 7.5: Korrekte Konfiguration der Konvertierungstabelle des Konverters
Beispiel einer vollständigen Konvertierungstabelle
Das Listing 7.6 zeigt eine vollständige Konvertierungs-Sektion.
# Source-Tag
Destination-Attribute
#-------------------------------------[ConvertTab]
NoTag
Body
HTML
Body
Head
Body
Body
Body
Title
Title
A:HRef
URL-References
A
ExtraKeywords, Parent
B
ExtraKeywords, Parent
Em
ExtraKeywords, Parent
I
ExtraKeywords, Parent
TT
ExtraKeywords, Parent
UL
ExtraKeywords, Parent
Strong
ExtraKeywords, Parent
Cite
References
Frame:Src
URL-References
Link:HRef
URL-References
Meta:Content
&Name
Meta:Content
&HTTP-Equiv
H1
Headings, Parent
H2
Headings, Parent
H3
Headings, Parent
H4
Headings, Parent
H5
Headings, Parent
H6
Headings, Parent
#Code
Ignore
Style
Ignore
Map
Ignore
Img:Src
Pictures
KAPITEL 7 - FEHLERTOLERANTER HTML-KONVERTER
Object
Object:Code
Applet
Applet:Code
93
Ignore
ActiveX
Ignore
Applets
# Script is ignored by default. The following line is just
# for the sake of completeness.
Script
Ignore
# If the Language-Attribute is missing, the default value
# JavaScript is taken.
Script:Language
Scripts
# The following HRef is base of all relative URL-references.
# Filter AddDocBase(DocBase) should be called afterwards (in
# section [Filter]) with all attributes containing references
# in order to add the DocBase to all relative references.
Base:HRef
DocBase
Listing 7.6: Beispiel einer Konvertierungstabelle des HTML-Konverters
7.1.2 Sektion Separator
Diese Sektion dient dazu, den Inhalt eines Attributes zusätzlich zu unterteilen. Im
Speziellen wird diese Funktion verwendet, um beim Auftreten bestimmter Tags im HTMLFile zusätzliche Zeilenvorschübe zu einem Attribut hinzuzufügen um dieses zu gliedern
und die Lesbarkeit zu erhöhen. Dieses Attribut wird meistens der Body (Volltext) sein.
Die erste Zeile der Sektion gibt das zu unterteilende Attribut an. Dabei ist auf die
korrekte Groß- und Kleinschreibung zu achten. Wenn also in der Sektion ConvertTab als
Volltextattribut "Body" angegeben ist, dann ist auch hier "Body" in die erste Zeile zu
schreiben. Die nachfolgenden Zeilen bestehen aus einer Anzahl Tags, durch Beistrich
voneinander getrennt. Anschließend wird durch Whitespace getrennt von den Tags noch
die Anzahl der anzufügenden Zeilenvorschübe angegeben.
Das Beispiel in Listing 7.7 unterteilt den Text so, daß Überschriften und Absätze,
Zeilenumbrüche und Aufzählungen erkannt werden können. Horizontale Trennlinien und
Unterteilungen (Divisions) trennen ebenfalls Textteile durch Zeilenvorschub.
[Separator]
Body
H1, H2, H3, H4, H5, H6
/H1, /H2, /H3, /H4, /H5, /H6
P, /P
Table
HR
BR
DIV
LI
2
1
1
1
1
1
1
1
Listing 7.7: Beispiel einer Konfiguration der Separator-Sektion des HTML-Konverters
KAPITEL 7 - FEHLERTOLERANTER HTML-KONVERTER
94
Durch diese Zuordnung ist es möglich, im Body die einzelnen Absätze und Überschriften zu erkennen. Zusätzlich werden auch Absätze sichtbar, die durch horizontale Linien
(HR) oder Break (BR) voneinander getrennt sind.
7.1.3 Weitere Konfiguration
Zur vollständigen Konfiguration des HTML-Konverters müssen noch Module wie
AVTable und AVTableFilter angepaßt werden.
Konfiguration der AVTable
Die aus einem Dokument extrahierten Daten werden einzelnen Attribute zugeordnet. Die
Attribut-Wert-Tabelle kann nun so konfiguriert werden, daß die Daten unterschiedlich an
vorhandene Daten angefügt werden. Es gibt die Möglichkeit, jedes Wort in eine Zeile zu
schreiben, was vor allem für Schlüsselwörter verwendet wird. Um Überschriften oder
ähnliches zu extrahieren, kann man den Text zwischen Anfangs- und Endtag in jeweils
eine Zeile extrahieren. Zum Extrahieren des Textes in ein Attribut ohne Einfluß von Tags
dient die dritte Methode, die vor allem für das Body-Attribut verwendet wird. Eine genaue
Beschreibung der Konfigurationsmöglichkeiten ist im Kapitel 11.10 – AVTable
angegeben.
Konfiguration des AVTableFilters
Nachdem die Attribute extrahiert wurden, ist teilweise noch eine Nachbearbeitung nötig,
um beispielsweise doppelte Einträge bei Bildern und Verweisen zu löschen oder ein
Abstract zu bilden. Dazu dient das Modul AVTableFilter, welches im Kapitel 11.11 –
AVTableFilter genau beschrieben wird.
7.2 Detailaspekte des Konverters
Im folgenden werden einige Besonderheiten des Konverters genauer beschrieben. Dabei
wird ausgeführt, welche Dateien konvertiert werden können und welches Format das
Konvertierungsergebnis hat.
Konvertierbare Dateien
Der Konverter kann sowohl HTML- als auch Text-Dateien behandeln, wobei die
Dateien anhand der Endung unterschieden werden. Als HTML gelten die Endungen "htm"
und "html", als Text gelten "txt" und "text". Dabei ist es egal, ob Groß- oder Kleinbuchstaben in der Endung vorkommen. Zur Umwandlung von anderen Dokumenten bzw.
Dateien, wie etwa PostScript, müssen eigene Module implementiert werden. Diese können
bei Bedarf vom Gatherer aufgerufen werden.
95
KAPITEL 7 - FEHLERTOLERANTER HTML-KONVERTER
Uniform Resource Locator
Der Konverter erwartet als Übergabeparameter eine URL3. Je nach angegebenem
Protokoll wird ein Objekt entweder über das Dateisystem (bei Parametern in der Form
file:///Pfad/File) oder über das Internet (http://Rechner:Port/Pfad/File)
geholt und konvertiert. Unter DOS bzw. Windows können für File-URLs sowohl die
üblichen Backslashes ("\") als auch Slashes verwendet werden.
Format des Konvertierungsergebnisses
Als Rückgabeparameter erzeugt der Konverter ein Objekt AVTable4 (siehe auch Kapitel
11.10). Dieses Objekt besteht aus einer Anzahl Attributen mit den dazugehörigen Daten
und kann in ein beliebiges Datenaustauschformat konvertiert werden, wie etwa SOIF
(siehe Kapitel 4.3.1).
Konvertieren spezieller Zeichen
In HTML-Dokumenten können Zeichen auf bis zu drei verschiedene Arten angegeben
werden. Zum Beispiel kann das non-breaking Space als   oder   oder
hexadezimal als   im Dokument vorkommen. Damit der Konverter einzelne Wörter
unterscheiden kann, um z.B. die Keywords zu extrahieren, ist es nötig, alle Sonderzeichen
die ein Whitespace repräsentieren, also Zeichen, die einen Abstand zum vorigen Zeichen
ergeben, in Leerzeichen umzuwandeln. Die Problematik läßt sich am besten anhand eines
Beispiels zeigen.
In dem in Listing 7.8 angegebenem Satz sind die einzelnen Wörter ohne weitere
Bearbeitung nicht erkennbarDas	sind  alles  Keywords.
Listing 7.8: Beispiel für HTML-Text mit durch Spezialzeichen getrennten Wörtern
Dieser Satz erscheint nach der Umwandlung und Normalisierung (Zusammenfassung
mehrfacher Whitespace zu einem einzigen Space) durch den Konverter wie in Listing 7.9
gezeigt.
Das sind alles Keywords.
Listing 7.9: Konvertierter und normalisierter Text aus Listing 7.8
Die vom Konverter berücksichtigten Zeichen für Whitespace sind in Tabelle 7.1
aufgelistet.
HTML-Zeichenfolge
Entsprechung
3
Der Uniform Resource Locator ist definiert in [RFC1738].
4
Eine AVTable ist eine Attribut-Wert-Tabelle und nimmt Daten zu bestimmten
Attributen wie Schlüsselwörtern oder Überschriften auf.
96
KAPITEL 7 - FEHLERTOLERANTER HTML-KONVERTER
  und hexadezimal  
Leerzeichen

 bzw. 
Wagenrücklauf

 und 

Zeilenvorschub
	
Tabulator
  und  
Non-breaking Space
Tabelle 7.1: HTML-Zeichenfolgen, die dem Zeichen Whitespace entsprechen
Die Zeichen und deren Codierung ist in [ISO88591] spezifiziert. Der Konverter führt die
Umwandlung in Leerzeichen automatisch durch, wodurch im Ergebnis nur Plain-Text und
nicht umgewandelte Zeichen (wie ä) stehen. Wenn gewünscht, können alle
Sonderzeichen nach ISO 8859-1 konvertiert werden. Dazu ist es nötig, im Source-Code die
Konstante TRANSLATION auf true zu setzen und neu zu kompilieren.
Scripts
Scripts sind interpretierbare Programme inmitten eines HTML-Dokuments, wobei es
mehrere Scriptsprachen gibt. Die Art der verwendeten Scriptsprache ist im LanguageAttribut des Script-Tags anführt, wobei ohne Angabe dieses Attributs der Default-Wert
JavaScript ist. Auf die Art der Scriptsprache kann man daher in der Sektion ConvertTab
mit dem Befehl Script:Language zugreifen, um den Script-Typ in ein Attribut schreiben zu
lassen. Innerhalb von Scripts können wieder HTML-Tags vorkommen, wobei das Ergebnis
der Ausgabe aber vom Script abhängt. Aus diesem Grund wird das gesamte Script bis zum
Scriptende-Tag ignoriert. Die Angabe 'Script Ignore' in der Sektion ConvertTab ist
voreingestellt und kann auf keinen anderen Wert geändert werden. Listing 7.10 zeigt einen
Script-Eintrag:
<script language="JavaScript">
<!-document.writeln ("Last Modified: ",document.lastModified,"<p>");
// -->
</script>
Listing 7.10: Beispiel eines Script-Tags in einem HTML-Dokument
Kommentare
Innerhalb von HTML-Dokumenten gibt es Kommentare, die nicht zur Ausgabe
bestimmt sind. Diese werden vom Konverter automatisch ignoriert, wobei es aber einige
Besonderheiten zu beachten gibt, die sich Aufgrund unterschiedlicher Verhaltensweisen
der Browser (Netscape Navigator Version 3.01 und Internet Explorer Version 4.01)
ergeben haben. Daran orientiert sich auch der hier vorgestellte Konverter.
Beginnt das Tag mit der Zeichenfolge "<!—" (nur ein einzelner Bindestrich), dann wird
der ganze nachfolgende Text bis zur nächsten auftretenden Zeichenfolge "-->" ignoriert.
Beginnt der Kommentar hingegen mit "<!" ignoriert der Konverter alles bis zum nächsten
auftretenden Zeichen ">". Bei fehlerhaften Kommentarangaben mit zusätzlichem
KAPITEL 7 - FEHLERTOLERANTER HTML-KONVERTER
97
Leerzeichen vor dem Rufzeichen wie in "< !" wird der Text bis zum abschließenden
Zeichen zur Kennzeichnung des Tagendes ">" ignoriert5.
NoTag
Alle gängigen Browser zeigen auch Text an, der außerhalb aller Tags steht, obwohl das
nicht konform mit der HTML-Spezifikation ist. Man geht davon aus, daß alles, was in
einer HTML-Datei steht, auch ausgegeben werden soll, so daß die Fehlertoleranz
möglichst hoch ist.
Um mit der ConvertTab auch auf Text zugreifen zu können, der nicht innerhalb eines
Tags mit zugehörigem Ende-Tag steht, gibt es NoTag. NoTag ist defaultmäßig dem
Destination-Attribut Body zugeordnet, d.h. der Text wird automatisch in das Body-Attribut
übernommen. Will man, daß der Konverter diesen Text ignoriert, muß man in der Sektion
ConvertTab die Zeile 'NoTag Ignore' dazufügen.
Laut HTML-Spezifikation sollte der in Listing 7.11 grau unterlegte Text ignoriert
werden:
Dieser Text wird auch angezeigt!
<HTML>
<HEAD>
<TITLE>
Der Titel des HTML-Files
</TITLE>
</HEAD>
Dieser sollte eigentlich auch ignoriert werden.
<BODY>
:
:
</BODY>
</HTML>
Angezeigter Text.
Listing 7.11: Text außerhalb der erlaubten Positionen in einem HTML-Dokument
Attribute in HTML-Tags
Normalerweise werden Werte, die Großbuchstaben oder Leerzeichen beinhalten, in
Anführungszeichen ( " ) eingeschlossen. Treten aber Anführungszeichen innerhalb des
Wertes auf, wird manchmal auch das Hochkomma ( ' ), wie in Listing 7.12 gezeigt,
verwendet. Der Konverter erkennt automatisch die Art der Einschließung und extrahiert
die richtigen Werte aus dem Tag.
<TAG Attribut='Wert mit Space und "'>
Listing 7.12: HTML-Tag mit Anführungszeichen im Wert eines Attributes
5
Ein Leerzeichen nach dem Zeichen zur Kennzeichnung von Tags "< " wird als
fehlerhaftes Tag interpretiert und das gesamte Tag mit allen Attributen ignoriert.
KAPITEL 7 - FEHLERTOLERANTER HTML-KONVERTER
98
Spezielle Attribute des Konverters
Der Konverter erzeugt zusätzlich selbst spezielle Attribute, die das Dokument genauer
spezifizieren (siehe Tabelle 7.2). Diese Informationen (Last-Modification-Time und MD5)
werden später unter anderem verwendet, um zu prüfen, ob sich die Datei seit dem letzten
Konvertiervorgang geändert hat. Erst bei einer Änderung wird der Konverter erneut
aufgerufen.
Attributname
Bedeutung
Type
Typ des Dokuments (HTML oder Text)
File-Size
Größe des Text- oder HTML-Dokuments in Byte
MD5
MD5 Checksumme des Dokuments
Update-Time
Konvertierungszeit des Dokuments in Sekunden seit Mitternacht
1.1.1970 GMT.
Last-ModificationTime
Zeit in Sekunden seit Mitternacht 1.1.1970 GMT, zu der das
Dokument zuletzt geändert wurde. Ist die übergebene URL eine
Datei im Dateisystem, wird die Last-Modification-Time der Datei
verwendet, ansonsten wird versucht, das Last-Modified Feld im
Header der HTTP-Übertragung auszuwerten. Ist dieses nicht
vorhanden, wird die aktuelle Uhrzeit verwendet. In diesen Fällen
kann der Gatherer so konfiguriert werden, daß als Kriterium für
die Änderung eines Dokumentes die MD5-Prüfsumme verwendet
wird.
Tabelle 7.2: Auflistung der zusätzlichen Attribute, die vom Konverter erzeugt werden
Keywords unterschiedlicher Priorität
Wenn nötig, kann man auch sehr einfach eine Abstufung der Wichtigkeit von Keywords
einführen und Keywords unterschiedlicher Priorität erzeugen. Ist man der Meinung, daß
Wörter, die fett oder mit dem Tag Strong ausgegeben werden wichtiger sind als solche, die
kursiv oder betont6 erscheinen, kann man diesen unterschiedliche Attribute zuweisen.
Listing 7.13 zeigt eine Konfigurationsdatei (Sektion ConvertTab), die Keywords mit drei
unterschiedlichen Prioritäten erzeugt (KeyLow, KeyMed, KeyHigh):
[ConvertTab]
NoTag
HTML
Head
Body
Title
B
Strong
Em
6
Body
Body
Body
Body
Title
KeyHigh, Parent
KeyHigh, Parent
KeyMed, Parent
Betont oder engl. emphasized. Das entsprechende HTML-Tag ist <EM>.
KAPITEL 7 - FEHLERTOLERANTER HTML-KONVERTER
I
A
TT
UL
A:HRef
Frame:Src
Link:HRef
H1
H2
H3
H4
H5
H6
Meta:Content
Meta:Content
99
KeyMed, Parent
KeyLow, Parent
KeyLow, Parent
KeyLow, Parent
URL-References
URL-References
URL-References
Headings, Parent
Headings, Parent
Headings, Parent
Headings, Parent
Headings, Parent
Headings, Parent
&Name
&HTTP-Equiv
Listing 7.13: Konfiguration der ConvertTab für unterschiedliche Keyword-Prioritäten
Die verschiedenen Keywords können nun in einem übergeordneten Modul ausgewertet
werden. Zum Beispiel ist es jetzt möglich, in einem Suchmodul Dokumente, in denen die
gesuchten Wörter vorkommen nach der Wichtigkeit bzw. dem Vorkommen der Keywords
in KeyHigh, KeyMed und KeyHigh zu sortieren.
Nicht ordnungsgemäß verwendete Tags
Der Konverter arbeitet stackorientiert. Alle Tags, die in der Sektion ConvertTab der
Konfigurationsdatei vorkommen, werden, sobald sie in der HTML-Datei aufscheinen, auf
einen Stack gelegt. Sobald ein Ende-Tag gefunden wird, werden alle offenen Tags, die
nicht ordnungsgemäß (ohne Verschränkung) geschlossen wurden, automatisch vom Stack
genommen. Damit schließt der Konverter von vornherein verschränkte Tags aus. Listing
7.14 zeigt, wie der Konverter Verschränkungen interpretiert.
<H1>Das ist ein <B>Heading</H1>Hier beginnt </B>Text.
Wird vom Konverter interpretiert als:
<H1>Das ist ein <B>Heading</B></H1>Hier beginnt Text.
Listing 7.14: Interpretation des Konverters von verschränkten HTML-Tags
Damit es aber möglich ist, nicht geschlossene Tags zu korrigieren, muß der Konverter
gültige Tags erkennen. Da der Konverter nur Tags kennt, die in der Sektion ConvertTab
vorkommen, ist es ratsam, alle notwendigen Tags – auch Tags wie HTML, HEAD und
BODY – anzugeben, um beispielsweise die Erkennung eines nicht geschlossenen TitleTags zu ermöglichen (siehe Listing 7.15). Normalerweise würde die Zeile "NoTag Body"
genügen, um den gesamten Text dem Attribut Body zuzuweisen.
100
KAPITEL 7 - FEHLERTOLERANTER HTML-KONVERTER
[ConvertTab]
NoTag
HTML
Head
Body
Title
Body
Body
Body
Body
Title
Listing 7.15: Konfiguration der Sektion ConvertTab zur Arbeitsweise des Konverters
7.3 Performance
Der Konverter ist, wie das gesamte Projekt, in der Programmiersprache Java implementiert, um eine leichte Portierung auf beliebige Plattformen zu erleichtern. Der Quellcode
eines Java Programmes (z.B. Dateiname File.java) wird mit einem Compiler in
sogenannten Byte-Code umgewandelt. Dieser Byte-Code (File.class) wird dann vom JavaInterpreter der jeweiligen Plattform (Solaris, Windows NT, etc.) interpretiert und damit
ausgeführt [Shiff1999]. Schleifen und Programmteile müssen also immer wieder in
Maschinensprache übersetzt werden. Java-Interpreter sind daher wie aus Tabelle 7.3
ersichtlich noch relativ langsam. Zum Beispiel benötigt der Konverter mit dem Sun Java
Development Kit 1.1.6 unter Windows NT auf einem 225 MHz Pentium Prozessor 25,2
Sekunden zum konvertieren einer 200 KB großen HTML-Datei (diese entspricht in etwa
einer 80-seitigen Diplomarbeit nach HTML konvertiert). Davon entfällt ein Drittel der Zeit
auf das Erzeugen der MD5-Checksumme und das Ausführen der Filter.
Java Virtual Machine
(Angaben in Sekunden)
Konvertieren
Filtern
MD5
berechnen
Gesamt
JDK 1.1.3 Solaris
21,5
6,6
5,0
33,1
JDK 1.1.8 Windows NT
15,7
5,9
3,6
25,2
SYMCJIT
Windows NT (JIT)
6,4
1,6
1
9
Tabelle 7.3: Vergleich der Konvertierungszeiten diverser Interpreter und Compiler
Derzeit arbeiten einige Firmen daran, sogenannte Just-In-Time (JIT) Compiler zu
entwickeln7. Ein normaler Interpreter interpretiert Byte-Code immer wieder neu. JIT
Compiler übersetzen ebenfalls zur Laufzeit Java-Byte-Code in Maschinensprache, können
aber diese dann immer wieder verwenden, ohne neu zu übersetzen. Mit der Version eines
7
Sun arbeitet an einer Technologie namens HotSpot (siehe http://java.sun.com)
Symantec und IBM (http://www.ibm.com/java) haben ebenfalls Versionen von JITCompilern entwickelt.
101
KAPITEL 7 - FEHLERTOLERANTER HTML-KONVERTER
JIT-Compilers von Sun bzw. Symantec wird obige HTML-Datei in 9 Sekunden
konvertiert8. Eine durchschnittliche Datei wird im Zehntel-Sekunden-Bereich bearbeitet.
7.4 Unterschiede Windows/UNIX
Der Konverter funktioniert ohne Neukompilierung auf allen Betriebssystemen, für die
eine Java Virtual Machine (JVM) implementiert ist. Ein Unterschied ist, wie schon im
Abschnitt 7.2 unter Unifor Resource Locator erwähnt, daß unter Windows bei File-URLs
auch Backslashes möglich sind (JDK 1.1.6). Aufgrund der Kompatibilität sollten aber
überall Slashes verwendet werden, so daß Konfigurationsdateien einfach übernommen
werden können.
Ein weiterer Punkt ist die Unterschiedliche Behandlung von Newline in den Betriebssystemen. Unter Windows besteht Newline aus Carriage Return und Line Feed unter Unix
genügt Line Feed. Da etwa durch die Gliederung im Body-Attribut Newlines eingefügt
werden, sind Unterschiede bei unter UNIX und Windows erstellten Attribut-ValueObjekten möglich. Java ist relativ flexibel beim Einlesen von Dateien und behandelt DOSund Unix-Textdateien gleich, so daß etwa Informationsdateien ohne Änderung
übernommen werden können.
Unter DOS/Windows ist die Groß- und Kleinschreibung der Verzeichnisnamen und
Dateinamen nicht relevant. Unix und alle davon abgeleiteten Betriebssysteme unterscheiden Dateien mit unterschiedlicher Schreibweise. Dateinamen und Verzeichnisse
sollten immer in der korrekten Schreibweise angegeben werden.
7.5 Erweiterungsmöglichkeiten
Da Filter relativ flexibel eingebunden werden können, ist es leicht möglich, weitere
Programme, wie etwa ein Modul zur Erkennung der in einem Dokument verwendeten
Sprache, in den HTML-Konverter zu integrieren. Dieses Modul kann dann den Inhalt
verschiedener Attribute analysieren, wie das ähnlich mit dem Abstract-Filter (siehe Kapitel
11.11) realisiert wurde. Listing 7.16 zeigt die Sektionen ConvertTab und Filter bei
Verwendung eines Modules zur Extraktion der im Dokument verwendeten Sprache.
[ConvertTab]
Div:Lang
P:Lang
Meta:Content
Meta:Content
[Filter]
Meta:Language, Language, Body
Meta:Language
Language
Language
&Name
&HTTP-Equiv
ExtractLanguage(Language)
Delete
Listing 7.16: Beispielkonfiguration der ConvertTab-Sektion des HTML-Konverters
8
Man kann davon ausgehen, daß die Performance der Compiler in Zukunft noch weiter
steigen wird und sollte die Entwicklung der Just-In-Time Compiler weiter beobachten.
KAPITEL 7 - FEHLERTOLERANTER HTML-KONVERTER
102
Laut HTML-Spezifikation kann bei verschiedenen Tags wie <DIV> oder <P> zusätzlich
als Attribut die Sprache angegeben werden. Diese Wörter können mittels obiger
ConvertTab extrahiert werden. Auch Angaben in Meta-Tags sollten berücksichtigt werden,
da es auch hier Angaben zur Sprache (engl. Language) geben kann. Dem Filter werden
dann Attribute wie hier Meta:Language, Language und Body übergeben.
Der Filter sollte zuerst ein eventuell vorhandenes Meta-Tag auswerten. Dann kann die
Information auch aus Tags wie <DIV LANG="EN"> oder <P LANG="EN"> (die hier in das
Attribut Language extrahiert wurden) gewonnen werden. Sind diese Möglichkeiten
ausgeschöpft, muß der Filter Begriffe aus dem Body auswerten und von diesen auf die
richtige Sprache schließen. Weitere Informationen zu Sprach-Tags kann man in
[RFC1766] – "Tags for the Identification of Languages" finden.
7.6 Vollständige Konfigurationsdatei
Die Konfigurationsdatei des HTML-Konverters besteht also aus zwei Sektionen. Die
Sektion ConvertTab beschreibt, welche Elemente eines HTML-Dokumentes in welche
Attribute der Attribut-Wert-Tabelle übernommen werden sollen. Für ein bestimmtes
Attribut gibt es mit der Sektion Separator die Möglichkeit der Gliederung eines
bestimmten Attributes. Damit kann beispielsweise das Volltext-Attribut Body nach dem
Aussehen des ursprünglichen Dokumentes gestaltet werden. Listing 7.17 zeigt eine
vollständige Konfigurationsdatei.
# Convert-Table
# This table defines which HTML-Tag contents will be added to
# attributes. Attributes are case sensitive. Tags are not.
# Attributes not specified here will be ignored.
#
# Source-Tag
# Name
... Name of the HTML-tag
# NoTag
... Text outside tags (default, destination
#
is Body)
# Tag:Attribut ... Content of a certain attribute
# Tag:Code
... Content of codebase & code attributes
#
# Destination-Attribute
# Name
... Name of the attribute
# Ignore
... Text will be ignored
# Parent
... Text will be handed over to parent tag
# &Name
... Text will be taken out of attribute
#
'Name'. Destination is Tag:&Name. These
#
attributes can be renamed (look
#
section [Filter]).
#
# Multiple destination-attributes must be separated by comma.
#
# Source-Tag
Destination-Attribute
#-------------------------------------[ConvertTab]
NoTag
Body
KAPITEL 7 - FEHLERTOLERANTER HTML-KONVERTER
HTML
Head
Body
Title
A:HRef
A
B
Em
I
TT
UL
Strong
Cite
Frame:Src
Link:HRef
Meta:Content
Meta:Content
H1
H2
H3
H4
H5
H6
#Code
Style
Map
Img:Src
Object
Object:Code
Applet
Applet:Code
Body
Body
Body
Title
URL-References
ExtraKeywords, Parent
ExtraKeywords, Parent
ExtraKeywords, Parent
ExtraKeywords, Parent
ExtraKeywords, Parent
ExtraKeywords, Parent
ExtraKeywords, Parent
References
URL-References
URL-References
&Name
&HTTP-Equiv
Headings, Parent
Headings, Parent
Headings, Parent
Headings, Parent
Headings, Parent
Headings, Parent
Ignore
Ignore
Ignore
Pictures
Ignore
ActiveX
Ignore
Applets
# Script is ignored by default. The following line is just
# for the sake of completeness.
Script
Ignore
# If the Language-Attribute is missing, the default value
# JavaScript is taken.
Script:Language
Scripts
# The following HRef is base of all relative URL-references.
# Filter AddDocBase(DocBase) should be called afterwards (in
# section [Filter]) with all attributes containing references
# in order to add the DocBase to all relative references.
Base:HRef
DocBase
# This section is used to separate the content of an
# attribute. The first line is the name of the attribute.
# The other lines tell how many NewLines are to add in the
# attribute if one of the tags is encountered.
[Separator]
Body
H1, H2, H3, H4, H5, H6
2
/H1, /H2, /H3, /H4, /H5, /H6
1
P, /P
1
103
KAPITEL 7 - FEHLERTOLERANTER HTML-KONVERTER
Table
HR
BR
DIV
LI
104
1
1
1
1
1
Listing 7.17: Beispiel einer vollständigen Konfigurationsdatei des HTML-Konverters
7.7 Zusammenfassung
In diesem Kapitel wurde die Funktionsweise des Konverters und die Konfiguration der
einzelnen Funktionskomponenten anhand von Beispielen genau erklärt. Der Konverter ist
für die Umwandlung von HTML- und Textdokumenten zuständig und kann Dokumente
entweder über HTTP oder das Dateisystem übertragen. Beliebige Tags in HTMLDokumenten können extrahiert werden, wobei es durch die flexible Konfiguration
ebenfalls möglich ist, Text aus Attributen von HTML-Tags zu erhalten. Diese Möglichkeit
kann vor allem dazu verwendet werden, Zusatzinformationen über Dokumente aus MetaTags (siehe Kapitel 4.1.2) auszuwerten.
Vor allem zur Gliederung des extrahierten Gesamttextes gibt es die Möglichkeit, diesen
Body je nach Formatierung des Originaldokumentes zu unterteilen. So können etwa
Überschriften, Absätze oder Tabellen durch zusätzliche Zeilenvorschübe hervorgehoben
werden und die ursprüngliche Struktur bleibt ansatzweise erhalten.
Die vom Konverter extrahierten Informationen werden in einem Objekt AVTable (siehe
auch Kapitel 11.10) zusammengefasst. Die AVTabel enthält dabei alle über ein Dokument
bekannten Informationen und dient, wie im Kapitel 5 angedeutet, als Grundlage des
Datenaustauschs innerhalb der Komponenten dieses Projekts.
In den nächsten Kapiteln werden die verschiedenen Möglichkeiten beschrieben, wie auf
die mittels Gatherer und HTML-Konverter gesammelten Daten zugegriffen werden kann.
Dazu gibt es einerseits ein Interface um Dokumente und Informationen über das Internet
an übergeordnete Suchdienste zu übertragen (siehe Kapitel 8) und andererseits eine
Beispielimplementierung eines Suchinterfaces, um Dokumente mittels Eingabe von
Stichworten über die indizierten Wörter suchen und finden zu können (siehe Kapitel 9).
Kapitel 8
Das Gatherer-Collector-Interface
Das Gatherer-Collector-Interface bietet die Möglichkeit, über das Internet auf vom
Gatherer gesammelte Daten zugreifen zu können. Diese Daten sind einerseits Informationen über die durchforsteten Dokumente und andererseits Zusatzinformationen, die
bestimmten Dokumenten zugeordnet sein können. Diese Informationen werden zur
Verfügung gestellt, damit andere Suchsysteme die bereits durchforsteten Dokumente nicht
selbst über das Web anfordern müssen und die schon erarbeiteten Daten effizient
übernehmen können.
Wie in den Ergebnissen des Untersuchungsbereiches gezeigt, kann dadurch eine
signifikante Reduktion der Netz- und Serverbelastung erreicht werden (siehe auch
Abschnitt 3.2.2), da ein großer Teil der Web-Seiten heutzutage gleichzeitig von mehreren
Suchmaschinen durchforstet wird (siehe auch Abschnitt 2.3). Es ist zweckmäßig, einen
Standard zu entwickeln, der es erlaubt, einmal gesammelte Informationen mehrfach
verwenden zu können. Ein Schritt in diese Richtung ist das in dieser Arbeit implementierte
Interface. Es ist vom Gatherer-Collector-Interface des Harvest-Systems (siehe auch Kapitel
3.4.1 – Harvest) abgeleitet und zu diesem kompatibel. Das Interface wurde aber so
erweitert, daß auch die im letzten Absatz erwähnten Zusatzinformationen abgerufen
werden können.
Als Basis für diese Implementierung dient die letzte Version (Protokoll 0.2.3 vom
30.1.1996) des Harvest-Systems. Um möglichst ressourcenschonend arbeiten zu können,
wurden Erweiterungen wie die Möglichkeit der Begrenzung der parallel nutzbaren
Verbindungen und Timeouts eingebaut. Timeouts dient dazu, ungenutzte Verbindungen
nach einer bestimmten Zeit automatisch zu beenden und die Verbindung wieder
freizugeben.
Damit nicht immer alle jemals gesammelten Daten übertragen werden, unterstützt das
Protokoll die Möglichkeit, nur jeweils alle Objekte auszugeben, die seit einem bestimmten
Zeitpunkt erzeugt bzw. geändert worden sind (inkrementelle Datenübertragung). Dadurch
wird eine erheblich Reduzierung der zu transportierenden Daten erreicht. Das Protokoll
bietet außerdem die Möglichkeit, die gesammelten Daten komprimiert zu übertragen, was
die Netzbelastung um weitere 80 Prozent gegenüber einer unkomprimierten Übertragung
reduzieren kann1.
1
Komprimierung einer durchschnittlichen Textdatei mittels gzip
KAPITEL 8 - DAS GATHERER-COLLECTOR-INTERFACE
106
Da die Befehle im Klartext übertragen werden, kann die Abfrage der Daten mit einem
einfachen Terminalprogramm (beispielsweise Telnet) erfolgen. Daraus ergibt sich auch die
Offenheit des Protokolls für Erweiterungen ohne die Kompatibilität zu älteren Versionen
aufzugeben. Als Beispielimplementierung wurden dem Protokoll Befehle zum Einstellen
des gewünschten Datenformates für die Übertragung hinzugefügt. Derzeit bietet das
Interface die Möglichkeit, Daten als SOIF (das von Harvest verwendete Format – siehe
Kapitel 4.3.1) oder als XML (siehe Kapitel 4.3.2) auszugeben. Tabelle 8.1 zeigt die vom
Collector Interface unterstützten Kommandos.
Kommando
Beschreibung
HELLO <Hostname>
Begrüßung.
HELP
Ausgabe aller unterstützten Befehle.
INFO
Informationen über den Gatherer.
SEND-OBJECT <OID>
Ausgabe eines bestimmten Objektes (Objekt ID).
SEND-UPDATE <Time>
Ausgabe aller Objektbeschreibungen, die seit
<Time> erzeugt bzw. geändert wurden.
SEND-INFO-UPDATE <Time>
Ausgabe aller Objektinformationen, die seit <Time>
erzeugt bzw. geändert wurden.
SET compression | nocomp
Aktivieren/Deaktivieren von GNU Zip
komprimierten Transfers.
SET soif | xml
Daten als SOIF oder XML ausgeben.
QUIT | BYE | EXIT
Verbindung schließen.
Tabelle 8.1: Kommandos des Collector Interfaces
Nach einer kurzen Beschreibung des Programms, des Protokolls und der einzelnen
Befehle folgt eine Auflistung der möglichen Fehlermeldungen. Außerdem werden einige
Beispiele für den Datenaustausch gegeben.
8.1 Funktionsbeschreibung
Das Interface ist multithreaded programmiert, um den gleichzeitigen Zugriff mehrerer
Gatherer zu ermöglichen wobei die maximale Anzahl der gleichzeitig möglichen Klienten
in der Konfigurationsdatei angegeben wird. Der Start des Servers für das Interface erfolgt
mit dem in Listing 8.1 gezeigten Aufruf. Die Reihenfolge der Parameter ist dabei nicht
relevant.
java –Duser.timezone=ECT CollectorInterface [Portnummer]
[-StandardLog Name] [-ErrorLog Name]
Listing 8.1: Aufrufparameter des Collector Interfaces
KAPITEL 8 - DAS GATHERER-COLLECTOR-INTERFACE
107
Der Parameter für die Java Virtual Machine –Duser.timezone=ECT ist unter Linux mit
Kernel 2.0.36 mit JDK 1.1.7A nötig, da sonst die bei den meisten europäischen Systemen
eingestellte Zeit CET nicht korrekt übernommen wird und in den Logdateien falsche
Ereigniszeiten eingetragen werden. Soll der Server auf Unix Systemen auch nach dem
Logout noch aktiv bleiben, so kann man den Befehl 'nohup', wie in Listing 8.2 gezeigt,
verwendet werden.
nohup java –Duser.timezone=ECT CollectorInterface [Portnummer]
[-StandardLog Name] [-ErrorLog Name]
Listing 8.2: Start des Collector Interfaces mit nohup
Ohne Angabe von Parametern wird die Portnummer aus der Konfigurationsdatei
CollectorInterface.cfg verwendet. Sind die ebenfalls optionalen Parameter für Fehler- und
Standardlogdatei nicht vorhanden, werden die Namen aus der Konfigurationsdatei Log.cfg
verwendet. Die Datei CollectorInterface.cfg hat folgend aufgelisteten Inhalt und kann mit
einem Texteditor an die Bedürfnisse des Benutzers angepaßt werden. Listing 8.3 gibt ein
Beispiel der Konfigurationssektion für das Collector Interface.
# Configuration for Collector-Interface
# Admin-Port is text-based for Shutdown (telnet).
[Config]
Max-Connections
2
Data-Port
9002
Admin-Port
9003
Password
dodo
Listing 8.3: Beispiel der Konfigurationsdatei des Collector Interfaces
Der Parameter Data-Port gibt die Portnummer an, über die das Collector-Interface
erreichbar ist. Mit Max-Connections kann man die maximal mögliche Anzahl gleichzeitig
abfragender Klienten beschränken. Admin-Port gibt wie beim Gatherer (siehe Kapitel 6)
die Portnummer des Administrator-Zuganges an. Um das Collector-Interface zu beenden,
erstellt man mit einem herkömmlichen Terminalprogramm, wie Telnet, eine Verbindung
zu dem Rechner und Admin-Port auf dem das Interface läuft. Der Administrator-Zugang
meldet sich wie in Listing 8.4 gezeigt.
Administrator Interface
Please enter password for shutdown.
Password:
Listing 8.4: Ausgabe des Administrator Interfaces
Nach Eingabe des korrekten Paßwortes beendet der Server die Verbindung. Verbindungen zu etwaigen Klienten werden nach Beendigung des gerade ausgeführten
Kommandos abgebrochen. Um das Interface über die Kommandozeile zu beenden gibt es
ein eigenes Modul. Mit dem wie in Listing 8.5 gezeigten Aufruf läuft die oben
beschriebene Prozedur (Verbindung zum Administrator-Port) automatisch ab und es wird
KAPITEL 8 - DAS GATHERER-COLLECTOR-INTERFACE
108
eine entsprechende Erfolgs- bzw. Fehlermeldung ausgegeben (siehe 11.7).
java SendPassword [Hostname] Portnummer Password
Listing 8.5: Aufruf des Moduls SendPassword zum Beenden des Collector Interfaces
Die Abfrage der Daten erfolgt mittels JDBC über die in Konfigurationsdatei DataBase.cfg angegebenen Datenbank (siehe auch Kapitel 10). Fehler- und Erfolgsmeldungen
des Interfaceprogrammes werden in Log-Dateien mitprotokolliert. Durch die flexible Art
der Datenbankanbindung mittels JDBC kann eine beliebige relationale Datenbank
verwendet werden. Einzige Voraussetzung ist das Vorhandensein eines JDBC-Treibers
oder zumindest eines ODBJ-Treibers, da Java eine JDBC-ODBC-Bridge implementiert
hat.
8.2 Protokollbeschreibung
Das Protokoll ist textbasiert. Nach der Willkommensmeldung des Servers kann der
Klient Kommandos zum Server senden, wobei der Server nach der Ausführung jedes
Kommandos mit einer Fehler- oder Erfolgsmeldung antwortet. Die ersten drei Zeichen
enthalten einen Fehlercode, der Rest der Meldung wird im Klartext gesendet. Wird vom
Klienten für fünf Minuten kein Kommando empfangen, dann beendet der Server die
Verbindung automatisch. Das ist nötig, um ein längeres Blockieren des Interface zu
verhindern bzw. um irrtümlich offengelassene Verbindungen zu beenden und die
benötigten Ressourcen wieder freizugeben.
8.2.1 Die Willkommens-Meldung
Sobald die Verbindung zum Server des Interfaces hergestellt worden ist, meldet sich
dieser, wie in Listing 8.6 gezeigt, mit Informationen über den Servernamen, der Version
des verwendeten Protokolls und einer Anfrage nach dem Rechnernamen des Klienten.
000 – HELLO <Version> <Server Host> [port <Port>]- are you <Client
Host>?
Beispiel:
000 - HELLO 0.2.5 test.server.at [port 8080] - are you
test.client.at?
Listing 8.6: Beispiel einer Willkommens-Meldung des Collector Interfaces
KAPITEL 8 - DAS GATHERER-COLLECTOR-INTERFACE
109
8.2.2 Das HELLO Kommando
Auf die Willkommens-Meldung des Servers sollte der Klient mit dem HELLO
Kommando antworten. Diese Antwort ist aber nicht zwingend nötig und kann auch
weggelassen werden, da sie keinen Einfluß auf den weiteren Verlauf der Kommunikation
hat. Als Parameter muß der Rechnernamen des Klienten angegeben werden (siehe Listing
8.7).
HELLO <Client Host>
Beispiel:
HELLO test.client.at
Listing 8.7: Beispiel für das HELLO Kommando des Collector Interfaces
8.2.3 SEND-UPDATE und SEND-INFO-UPDATE
Mit dem Kommando SEND-UPDATE kann man alle Dokumente ausgeben lassen, die
seit einem bestimmten Zeitpunkt erzeugt oder geändert worden sind. Um sich etwa alle
Dokumente ausgeben zu lassen, die der Gatherer gesammelt hat, wird man den in Listing
8.8 gezeigten Befehl mit Angabe der Zeit Null verwenden.
SEND-UPDATE <Time>
Beispiel:
SEND-UPDATE 0
Listing 8.8: Beispiel für das SEND-UPDATE Kommando des Collector Interfaces
Die Zeit wird in Sekunden spezifiziert und bezieht sich auf den 1. Jänner 1970 0:00
GMT. Um beispielsweise alle Dokumentdaten zu erhalten, die seit einer Woche neu
dazugekommen sind bzw. sich innerhalb der letzten Woche geändert haben, verwendet
man die Zeitangabe aus Listing 8.9.
t = aktuelle Zeit in Sekunden minus 60*60*24*7
Listing 8.9: Zeitberechnung zur Ausgabe aller neuen Dokumente der letzten Woche
Die Struktur der Ausgabe eines SEND-UPDATE Kommandos wird in Listing 8.10
gezeigt.
400 – Sending all Object Descriptions since tttt.
@DELETE { }
@REFRESH { }
@UPDATE {
KAPITEL 8 - DAS GATHERER-COLLECTOR-INTERFACE
110
@FILE { /* Beschreibung für Objekt 1 */
}
...
@FILE { /* Beschreibung für Objekt n */
}
}
499 - Sent n object descriptions (x bytes).
Listing 8.10: Beispiel der Ausgabe des SEND-UPDATE Kommandos
Da in der aktuellen Version (Protokoll 0.2.3 vom 30.1.1996) des Harvest-Interfaces nur
die @UPDATE Sektion implementiert ist, wurde auch in der vorliegenden Diplomarbeit
auf eine Erweiterung verzichtet. Mittels des SET Kommandos (siehe auch Abschnitt 8.2.4)
kann die Ausgabe dieses Kommandos beeinflußt werden. Unter anderem kann angegeben
werden, ob die Dokumentendaten komprimiert übertragen werden sollen (GZIP). Bei
eingeschalteter Kompression wird die Verbindung automatisch am Ende der Übertragung
beendet. Das ist nötig, damit der Klient nicht auf die Ende-Meldung warten muß
(üblicherweise die Meldung 499), sondern die Daten sofort zum Dekomprimierungsprogramm weiterleiten kann. Die komprimierte Ausgabe hat folgende Struktur (Listing
8.11):
400 – Sending all Object Descriptions since tttt.
...
GNU komprimierte Daten
...
Socket am Ende der Übertragung geschlossen
Listing 8.11: Beispiel der Ausgabe des SEND-UPDATE Kommandos
Um nicht die Dokumente selber, sondern deren Zusatzinformationen zu erhalten, nimmt
man den Befehl SEND-INFO-UPDATE, wobei die Verwendung vollkommen analog zu
SEND-UPDATE ist.
8.2.4 Das SET Kommando
Mit diesem Kommando beeinflußt man die Ausgabe von SEND-UPDATE, SENDINFO-UPDATE, INFO und SEND-OBJECT. Tabelle 8.2 zeigt die möglichen Parameter
des SET Kommandos.
Parameter
Funktion
SOIF
Die Ausgabe aller Dokumentendaten erfolgt im SOIF-Format.
XML
Die Ausgabe erfolgt im XML-Format.
COMPRESSION
Alle Dokumentendaten für die Ausgabe mittels SEND-UPDATE
und SEND-INFO-UPDATE werden mittels GZIP komprimiert.
NOCOMP
Keine Komprimierung der auszugebenden Dokumentendaten.
Tabelle 8.2: Parameter des SET Kommandos
KAPITEL 8 - DAS GATHERER-COLLECTOR-INTERFACE
111
8.2.5 Das SEND-OBJECT Kommando
Dieses Kommando wurde aus Kompatibilitätsgründen implementiert. Als Parameter
wird eine Objekt-Identifikationsnummer erwartet. Diese Nummer wird aber nur Gathererintern verwendet, womit das Kommando nur für Testzwecke interessant ist. Das zur
Objektnummer gehörende Dokument wird zurückgegeben.
8.2.6 Das INFO Kommando
Allgemeine Informationen über den Gatherer werden ausgegeben. Listing 8.12 zeigt ein
Beispiel einer Ausgabe des INFO Kommandos.
@GATHERER { http://rd.cs.colorado.edu/gatherer.soif
Gatherer-Host{22}:
powell.cs.colorado.edu
Gatherer-Name{39}:
Global - Selected Text - WWW Home Pages
Gatherer-Port{4}:
1171
Gatherer-Version{3}: 0.1
Last-Modification-Time{9}: 772263506
Refresh-Rate{6}:
604800
Time-to-Live{7}:
2419200
Update-Time{9}: 772263510
}
600 – Finished sending INFO.
Listing 8.12: Beispiel der Ausgabe des INFO Kommandos
8.2.7 Das HELP Kommando
Eine Auflistung aller Kommandos wird ausgegeben (siehe Abschnitt 8.3).
8.2.8 QUIT, EXIT und BYE
Diese Kommandos beenden die Übertragung. Der Server gibt eine Meldung aus, die die
Anzahl der Übertragenen Bytes angibt und beendet die Verbindung (siehe Listing 8.13).
999 -
Later, <Host>. <Anzahl> bytes transmitted.
Listing 8.13: Ausgabe des Interfaces bei Beendigung der Übertragung
KAPITEL 8 - DAS GATHERER-COLLECTOR-INTERFACE
112
8.3 Antworten und Fehlermeldungen des
Interfaces
In diesem Kapitel werden alle möglichen Antworten des Collector Interfaces auf
bestimmte Kommandos aufgezeigt und eine kurze Erklärung der jeweiligen Meldung
gegeben.
Allgemeines
000 001 002 003 004 005 007 008 -
HELLO <Version> <Server Host> [port <P>]
- are you <Client Host>?
Unknown Command: <letztes Kommando>
Unimplemented Command.
Kommando nicht implementiert.
Access denied for <Host>.
Klient nicht erlaubt. Derzeit nicht implementiert.
Warning: no reverse DNS pointer for <Host>.
Derzeit keine Verwendung.
Sorry, this Gatherer has a fatal internal error.
Tritt bei einem Fehler des Gatherers auf.
Timeout. Connection closed.
Zu lange kein Kommando vom Klienten erhalten. Server
schließt die Verbindung.
Maximum number of connections reached. Try again later.
Zu viele Klienten sind mit dem Server verbunden. Die
Verbindung wird automatisch geschlossen.
HELLO Kommando
100 101 102 –
Pleased to meet you <Hostname>.
Begrüßung erfolgreich.
Invalid Usage - HELLO <Hostname>.
Falsche Verwendung des Kommandos.
Warning: DNS told me <Hostname1>, not <Hostname2>.
Falsche Angabe des Hostnamens.
SEND-OBJECT Kommando
300 301 302 399 -
Sending Object <Nr>.
Meldung, bevor Objekt Nummer <Nr> gesendet wird.
Invalid Object <Nr>.
Objekt Nummer <Nr> falsch.
Invalid Usage - SEND-OBJECT <Object-ID>.
Falsche Verwendung des Kommandos.
Sent Object <Nr> (<Anzahl> bytes).
Object erfolgreich gesendet.
113
KAPITEL 8 - DAS GATHERER-COLLECTOR-INTERFACE
SEND-UPDATE, SEND-INFO-UPDATE Kommando
400 401 401 499 -
Sending all Object Descriptions since <Timestamp>.
Meldung, bevor Objekte gesendet werden.
Invalid Usage - SEND-UPDATE <Timestamp>.
Falsche Verwendung des Kommandos.
Invalid Usage - SEND-INFO-UPDATE <Timestamp>.
Falsche Verwendung des Kommandos.
Sent <Nr> object descriptions (<Anzahl> bytes).
Anzahl von erfolgreich ausgegebenen Dokumenten und Bytes.
SET Kommando
500 501 -
Set mode: <aktivierter/deaktivierter Mode>
Diese Meldung wird ausgegeben, wenn das Kommando
erfolgreich ausgeführt werden konnte.
Invalid Usage - SET <compression|nocompression|soif|xml>
Kein gültiger Parameter für Kommando erkannt.
INFO Kommando
600 601 602 -
Finished sending INFO.
Information erfolgreich ausgegeben.
Invalid Usage – INFO.
Falsche Verwendung des Kommandos.
INFO is unavailable for this Gatherer.
Keine Informationen über diesen Gatherer vorhanden.
QUIT, EXIT und BYE
999 -
Later, <Host>. <Anzahl> bytes transmitted.
Bei Beendigung der Verbindung wird noch die Anzahl
insgesamt gesendeter Bytes ausgegeben.
HELP Kommando
Die Ausgabe des HELP Kommandos sieht etwa so aus:
200
200
200
200
200
200
-
List of Available Commands
HELLO <hostname>
HELP
INFO
SEND-OBJECT <oid>
SEND-UPDATE <time>
-
200 200 200 -
SEND-INFO-UPDATE <time>
-
200 -
SET compression|nocomp
-
200 200 -
SET soif|xml
QUIT|BYE|EXIT
-
(Version 0.2.5):
Friendly Greeting
This message
Information about Gatherer
Send an Object Description
Send all Object Descriptions
that have been changed/created
since time
Send all Informations that
have been changed/created since
time
Enable/Disable GNU zip
compressed xfer
Output data as SOIF/XML
Close session
KAPITEL 8 - DAS GATHERER-COLLECTOR-INTERFACE
114
8.4 Beispiel für einen Datenaustausch
Listing 8.14 zeigt die typische Kommunikation eines Klienten mit dem Server. Die
Kommandos des Klienten sind grau hinterlegt. Üblicherweise wird vor dem SENDUPDATE Kommando noch ein SET COMPRESSION ausgeführt, was zusätzlich zur
komprimierten Datenübertragung den automatischen Verbindungsabbruch aktiviert, so daß
das abschließende QUIT nicht mehr nötig ist.
000 - HELLO 0.2.5 gatherer.at [port 8080] - are you collector.at?
hello collector.at
100 - Pleased to meet you collector.at.
send-update 0
400 - Sending all Object Descriptions since 0.
@DELETE { }
@REFRESH { }
@UPDATE {
@FILE { http://testfilefile/file.html
Headings{14}:
Global Program
Last-Modification-Time{9}:
914786084
Gatherer-Host{6}:
beavis
Gatherer-Name{21}:
Isch Bin Ein Gatherer
Keywords{19}:
bundles
resource
File-Size{3}:
563
Time-To-Live{6}:
300000
Abstract{300}: Global Program
A global program isolates these items and localizes them--that is,
provides a valid version of each item for each supported locale.
The JDK provides several classes that make managing localesensitive data a breeze. To isolate locale-sensitive data you put
them into resource bundles.
Type{4}:
HTML
Body{371}:
Global Program
A global program isolates these items and localizes them--that is,
provides a valid version of each item for each supported locale.
The JDK provides several classes that make managing localesensitive data a breeze. To isolate locale-sensitive data you put
them into resource bundles. The JDK provides three resource
bundling classes to help you do this.
Update-Time{9}: 914786168
MD5{32}:
04aea9f1211114cd89adba798db48ba6
Title{30}:
Managing Locale-Sensitive Data
Gatherer-Version{3}:
1.0
Refresh-Rate{2}:
60
}
}
499 - Sent 1 object descriptions (1224 bytes).
quit
999 - Later, collector.at. 1372 bytes transmitted.
Listing 8.14: Beispiel eines Datenaustausches über das Collector-Interface
KAPITEL 8 - DAS GATHERER-COLLECTOR-INTERFACE
115
8.5 Zusammenfassung
In diesem Kapitel wird das Gatherer-Kollektor-Interface detailliert beschrieben. Dieses
Interface bietet die Möglichkeit, über das Internet auf vom Gatherer gesammelte Daten
zugreifen zu können und diese so auch von mehreren übergeordneten Suchdiensten
verwenden zu können. Implementiert wurden ebenfalls Funktionen, die eine inkrementelle
Datenübertragung ermöglichen. Dabei werden nur Informationen über Objekte
weitergegeben, die sich seit einem bestimmten Zeitpunkt verändert haben.
Dadurch kann eine signifikante Reduktion der Netz- und Serverbelastung erreicht
werden (siehe auch Abschnitt 3.2.2). Eine weitere Reduktion ergibt sich durch die auf
Wunsch komprimierte Übertragung, mit der die Datenmenge je nach Inhalt auf etwa ein
Drittel verringert werden kann.
Eine weitere Möglichkeit, die Menge der vom Gatherer gesammelten Informationen
nutzen zu können, wird im folgenden in Kapitel 9 erläutert. Der in der vorliegenden
Diplomarbeit implementierte Suchdienst kann bei entsprechender Konfiguration Teile der
Informationen durchforsteter Dokumente indizieren. Diese Daten werden vom Suchdienst
dazu benutzt, dem Anwender die Möglichkeit zu geben, durch Eingabe von Stichworten
bestimmte Dokumente im Datenbestand zu suchen.
Kapitel 9
Der Suchdienst
In der vorliegenden Diplomarbeit wurde ein indexorientierter Suchdienst implementiert
(siehe auch Kapitel 2.1.2.2), um die Informationen über vom Gatherer durchforstete
Dokumente zusätzlich nutzen zu können. Wörter aus beliebige Attributen werden bei
entsprechender Konfiguration (siehe auch Kapitel 6.3.1 – Sektion Config der Konfiguration des Gatherers, Parameter Type) in einer Datenbank indiziert und stehen für
Suchabfragen zur Verfügung. Der Aufbau der Datenbank und die beim Einfügen bzw.
Löschen von Dokumenten notwendigen Operationen werden im Kapitel 10 genau erläutert.
Die Abfrage der gewünschten Informationen erfolgt über ein World Wide Web
Formular (siehe Abschnitt 9.1), wobei die eingegebenen Stichwörter und zusätzliche Daten
wie Sortierreihenfolge der gefundenen Dokumente u.s.w. an ein Servlet übergeben werden.
Servlets sind Java-Programme, die im Gegensatz zu Java-Applets nicht beim Anwender
ausgeführt werden, sondern auf der Serverseite. Dadurch lassen sich alle Möglichkeiten
nutzen, die von der Programmiersprache Java geboten werden wie etwa die Verwendung
einer beliebigen Datenbank via JDBC.
Die Methode des Datenzugriffs mittels Servlets läßt sich mit dem Zugriff über das
Common Gateway Interface (CGI) und CGI-Scripts vergleichen wobei sich aber einige
Vorteile ergeben. Servlets benötigen nicht für jeden Klientenzugriff einen eigenen Prozeß,
sondern laufen in einem Thread ab. Dadurch ergibt sich eine höhere Performance
gegenüber Skripts, weil keine Umschaltung des Prozeßkontextes wie bei CGI oder auch
Fast-CGI mehr durchgeführt werden muß. Beim herkömmlichen CGI-Ansatz muß
zusätzlich zur Kontextumschaltung bei jeder Anwenderanfrage noch Start-up und
Initialisierungscode ausgeführt werden.
Das Ergebnis der Suchabfrage wird vom Servlet über das Webgateway als HTMLDokument an den Browser zurückgegeben. Das Dokument enthält einige statistische Daten
über die Abfrage sowie eine sortierte Auflistung aller gefundenen Dokumente wie bei
Suchdiensten üblich. Das Suchergebnis kann dabei durch Verändern bestimmter Parameter
im Suchformular, wie etwa der Sortierreihenfolge oder der anzuzeigenden Attribute in
gewissen Grenzen beeinflußt werden (siehe Abschnitt 9.1.3).
117
KAPITEL 9 - DER SUCHDIENST
Abbildung 9.1 zeigt die Zusammenarbeit von Webgateway, Datenbank und Browser bei
einer Suchabfrage. Dabei ist zu beachten, daß die Datenbank für den Index nicht auf dem
selben Server installiert sein muß und so dessen Ressourcen nicht in Anspruch nimmt.
WWW Klient
WWW Gateway
Java
Servlet
Browser
Java
Applet
JDBC/ODBC
Interface
DB Server
Database
Server
HTTP
Server
DB
HTML
Seiten
Java
Applets
Abbildung 9.1: Kommunikation Browser – HTTP-Server – Servlet – Datenbank
Abschnitt 9.2 zeigt die Konfiguration des Suchservlets und Abschnitt 9.4 zeigt die
Einbindung des Servlets in einen Webserver anhand des frei verfügbaren Jigsaw1.
Abschnitt 9.3 erläutert Details der Programmierung des Servlets.
9.1 Suchabfrage
Die Eingabe der Suchdaten erfolgt, wie in der Einleitung erwähnt, über ein Web
Formular. Eine entsprechende Implementierung des Suchservlets ermöglicht die Eingabe
mehrerer Suchbegriffe. Die Wörter können dabei zusätzlich mit booleschen Operatoren
verknüpft werden, um die Suche weiter zu verfeinern, wobei AND, OR und AND NOT
(jeweils in Großbuchstaben) zur Verfügung stehen. Standardmäßig werden die Suchwörter
mit AND verknüpft, so daß in gefundenen Dokumenten alle angegebenen Wörter
vorkommen müssen. Die Auswertung erfolgt dabei von links nach rechts, wobei alle
Operatoren die gleiche Priorität haben.
Die Suchgeschwindigkeit in der Datenbank nimmt mit der Anzahl der Wörter ab. Daher
sollten bei der Suche möglichst wenige aber dafür signifikante Begriffe verwendet werden.
Mittels Wildcards kann die Suche erweitert werden. Implementiert sind '*' oder '%'
(Platzhalter für beliebige Zeichenfolgen) und '?' oder '_' (Platzhalter für einzelnes Zeichen).
In diesem Abschnitt werden die einzelnen Teile des Suchformulares genauer beschrieben. Im Suchbereich kann angegeben werden, in welchen Attributen eines Dokumentes
nach den eingegebenen Stichwörtern gesucht werden soll. Wird nur in einem Attribut
gesucht, kann eine Schranke angegeben werden, ab der Wörter in der Suchabfrage nicht
1
W3C Web Server Jigsaw, http://www.w3.org/Jigsaw/
KAPITEL 9 - DER SUCHDIENST
118
mehr relevant sind (also wenn sie in zu vielen Dokumenten vorkommen). Die Ausgabe
kann nach verschiedenen Kriterien sortiert werden wobei zusätzlich die Wahl der
auszugebenden Attribute möglich ist.
Abbildung 9.2 zeigt die Ausgabe des Webformulars auf einem Webbrowser (der
dazugehörige HTML-Quelltext ist aus Listing 9.4 in Abschnitt 9.3 ersichtlich). Die
Eingabe der Suchbegriffe inklusive boolescher Verknüpfungen erfolgt in der Textbox in
der oberen Hälfte des Formulars.
Abbildung 9.2: Suchformular für Datenbankzugriff mittels Servlet
9.1.1 Suchbereich
In der unteren Hälfte des Suchformulars kann gewählt werden, wo im Dokument nach
den gewünschten Begriffen gesucht werden soll (engl. search scope). Zur Auswahl stehen:

Content
Hier wird das gesamte Dokument auf Vorhandensein der Begriffe geprüft.
Die Volltextsuche ist vor allem wichtig, wenn Begriffe nur in Teilbereichen von Dokumenten vorkommen und nicht im Titel oder den Überschriften.

Title
Suche im Titel des Dokuments (wird bei den gängigen Browsern in der
Titelleiste des Fensters angezeigt).

Keywords Suche in den Schlüsselwörtern. Wie Schlüsselwörter aus dem Dokument
extrahiert werden, hängt von der Konfiguration des HTML-Konverters
(siehe Kapitel 7 – Fehlertoleranter HTML-Konverter) ab. Beispielsweise
können fett oder anders hervorgehobene Wörter als Keywords übernommen werden.
KAPITEL 9 - DER SUCHDIENST

Headings
119
Ist dieses Feld aktiviert, werden alle Dokumente ausgegeben, in denen die
eingegebenen Begriffe in den Überschriften vorkommen. Überschriften
geben einen Überblick über den Inhalt eines Dokuments, wodurch die
Wahrscheinlichkeit 'wichtige' Wörter zu enthalten groß ist.
Das Projekt ist flexibel programmiert, so daß nur durch Hinzufügen zusätzlicher
Suchziele eine Suche auch in diesen möglich ist ohne das Servlet oder die anderen
Programmteile ändern zu müssen. So kann einfach nach vorkommenden Verweisen wie
etwa auf Bilder oder Applets gesucht werden. Eine genauere Beschreibung erfolgt im
Kapitel 9.3.
9.1.2 Relevanz
Im Formular kann man auch eine Schranke für die zu suchenden Wörter bestimmen, um
eventuell nicht relevante Suchbegriffe auszuschließen. Die Beschränkung funktioniert nur
für Wörter in einem bestimmten Suchbereich, also etwa Schlüsselwörter.
Wörter sind für eine Suche nicht relevant, wenn sie in einer großen Anzahl an Dokumenten vorkommen. Wird etwa auf einem Heimatkundeserver nach dem Wort Österreich
gesucht, kann man annehmen, daß der Begriff auf fast allen Seiten vorkommt. Um solche
Wörter von vornherein auszuschließen, kann man eine prozentuelle Schranke angeben.
Wörter, die in mehr als der angegebenen Anzahl an Dokumenten vorkommen, werden bei
der Suchabfrage ignoriert. Werden nicht relevante Wörter erkannt, wird das in der
Ergebnisliste angezeigt.
9.1.3 Ausgabemöglichkeiten
Die Art der Ausgabe der Dokumente kann mit den Schaltflächen Search output
beeinflußt werden, wobei auf Wunsch des Benutzers zusätzlich zu den wichtigsten
Angaben wie Titel, URL, Größe des Dokuments und Datum der letzten Veränderung
folgende Informationen ausgegeben werden können:

Description Eine kurze Beschreibung der Dokumente wird ausgegeben. Die
Beschreibung kann mittels Filtern im HTML-Konverter erzeugt werden
und hat eine Länge von etwa 200 Zeichen. Dabei wird entweder der erste
Absatz oder eine Zusammenfassung der Überschriften des Dokuments
verwendet.

Keywords
Alle aus dem Dokument extrahierten Schlüsselwörter. Diese Liste wird
direkt aus der Attribut-Wert-Tabelle übernommen. Die Relevanz wird
nicht berücksichtigt.
Die Ausgabe der Daten über die gefundenen Dokumente erfolgt als HTML-Dokument
wobei interessante Daten wie die Anzahl der Dokumente in der Datenbank, die Anzahl der
indizierten Wörter und die Zeit in Sekunden des Datenbankzugriffs angegeben sind.
Zusätzlich ist die Anzahl der mit der Suchabfrage übereinstimmenden Dokumente
angeführt. Der Titel und die URL sind Hyperlinks und können sofort per Mausklick
weiterverfolgt werden. Abbildung 9.3 gibt ein Beispielergebnis für eine erfolgreiche
Suche.
120
KAPITEL 9 - DER SUCHDIENST
Die Reihenfolge der Dokumente kann im Suchformular geändert werden. Zur Auswahl
stehen folgende Möglichkeiten:

Importance
Sortieren der Dokumente nach der Wichtigkeit (hier auch als
Rating bezeichnet). Die vorkommenden Wörter werden dabei
nach dem Ort des Vorkommens (wie etwa Titel, Überschrift, etc.)
beurteilt, wobei die Gewichtung in einer Konfigurationsdatei angegeben werden kann (siehe Kapitel 9.2- Konfiguration).

Modification Date
Die Dokumente werden nach dem Datum der letzten Änderung
sortiert ausgegeben, wobei neuere Dokumente zuerst ausgegeben
werden.
Abbildung 9.3: Beispielausgabe einer erfolgreichen Suchabfrage
9.1.4 Stoppwörter
In der Konfigurationsdatei der Datenbank können auch unerwünschte oder sinnlose
Suchbegriffe aufgelistet werden. Ist etwa jemand nicht einverstanden, daß auf seinem
Server nach den Begriffen "Sodom" und "Gomorrha" gesucht wird oder sollen Wörter wie
"oder", "mein" und "unser" ausgeschlossen werden, kann man die Anwendung
entsprechend konfigurieren (siehe auch Abschnitt 10.6.4). Die Stoppwörter lassen sich
jederzeit nachträglich ändern, da die Indizierung unabhängig von der Stoppwortliste ist.
KAPITEL 9 - DER SUCHDIENST
121
Sollen bestimmte Wörter von vornherein von der Indizierung ausgeschlossen, also gar
nicht in die Datenbank übernommen werden, muß das Datenbankmodul entsprechend
Konfiguriert werden. Dabei bietet sich etwa die Möglichkeit, zu lange oder zu kurze
Wörter (wie die englischen Begriffe "is", "a" oder "at") einfach durch Angabe des
entsprechenden Filters ausschließen (siehe auch Abschnitt 10.6.2).
9.2 Konfiguration des Suchservlets
Die Konfigurationsparameter des Suchservlets werden in der Datei Database.cfg
spezifiziert. In dieser Datei wird unter anderem festgelegt, welche Datenbank auf welchem
Server verwendet werden soll (siehe Kapitel 10.6 – Konfiguration). Listing 9.1 zeigt ein
Beispiel der Konfigurationsdatei.
# Database Configuration File
[Config]
# Database access
Driver
postgresql.Driver
URL
jdbc:postgresql:test
: (vollständige Parameterliste siehe Kapitel Datenbank)
# Attributes for SearchServlet
Title
Title
Summary
Abstract
Keywords Keywords
# Rating value is additive. If word occurs in heading
# and body it will be rated in body and heading.
# Attribute Rating MaxCount
[Rating]
Body
1
Title
3
3
Headings
3
6
Keywords
4
6
# Each word which will be indexed by the database is passed
# through the following filters.
# Available filters:
# LowerCase ...... convert all words to lowercase
# DeleteNumbers .. numbers are ignored
# DelSmall(x) .... all words smaller or equal x characters are
#
ignored
# DelLong(x) ..... all words larger or equal x characters are
#
ignored
[WordFilter]
LowerCase
DelSmall(2)
DelLong(25)
Listing 9.1: Beispiel einer Konfigurationsdatei für das Suchservlet
KAPITEL 9 - DER SUCHDIENST
122
Das Suchservlet benötigt für die Ausgabe der gefundenen Dokumente im Suchergebnis
die Inhalte mehrere Attribute. Benötigte Attribute sind Title, Summary und Keywords. Da
im HTML-Konverter die Namen dieser Attribute nicht festgelegt sind, gibt es in der
Config-Sektion der Konfigurationsdatei eine Übersetzungstabelle. Durch diese Angaben
kann in Kombination mit dem HTML-Konverter flexibel auf die Anforderungen der
Suchdatenbank reagiert werden. So ist es etwa möglich, mit dem HTML-Konverter
mehrere Attribute für Schlüsselwörter mit unterschiedlicher Wichtigkeit zu erzeugen.
Zusätzlich kann ein weiteres Attribut erstellt werden, das alle Schlüsselwörter vereint
(siehe HTML-Konverter Filter join). Jetzt können nur durch Änderung der Konfigurationsdatei, wie in Listing 9.2, die zu verwendenden Schlüsselwörter gewählt werden, also
etwa nur die mit der größten Wichtigkeit.
[Config]
Title
Summary
Keywords
# oder
Keywords
Title
Abstract
ImportantKeywords
AllKeywords
Listing 9.2: Servletkonfiguration mit unterschiedlichen Attributen für Schlüsselwörter
Eine weitere Möglichkeit, das Suchergebnis zu beeinflussen, besteht darin, Wörter in
verschiedenen Positionen in den Dokumenten unterschiedlich zu gewichten. Der Sinn der
Gewichtung besteht darin, daß Wörter in Überschriften mit großer Wahrscheinlichkeit
relevanter den Inhalt des Dokuments beschreiben als Wörter an beliebiger Stelle in den
Absätzen und dadurch höheres Gewicht haben sollten.
Das Gewicht der einzelnen Wörter ist in der Rating-Sektion der Konfigurationsdatei
spezifiziert. Wie ein Dokument bewertet wird, ist im Kapitel 10.4.4 – Gewichtung
gefundener Dokumente näher erklärt. Zusätzlich gibt es in der Konfigurationsdatei auch
die Möglichkeit der Angabe eines Maximalwertes. Dieser gibt an, wie oft ein bestimmtes
Wort maximal beispielsweise in den Schlüsselwörtern vorkommen darf, ist also zur
Verhinderung von Keyword-Spamming geeignet. Keyword-Spamming wird verwendet,
um ein Dokument möglichst weit vorne im Suchergebnis zu reihen. Das wird mit
vielfacher Angabe bestimmter Schlüsselwörter, die unter Umständen gar nichts mit dem
wirklichen Dokumenteninhalt zu tun haben, erreicht.
Der Maximalwert und die Gewichtung wird bei jedem Neustart des Servlets ausgelesen.
Die Konfigurationsdatei kann also zum Erzielen eines besseren Ergebnisses im Nachhinein
geändert werden, ohne daß die Datenbank beeinflußt wird und die Dokumente neu
indiziert werden müssen.
9.3 Implementierung
Um Daten vom Benutzer zum Server zu übermitteln, wurde die Get-Methode verwendet.
Die zu suchenden Begriffe und das gewünschte Ausgabeformat werden dabei in der URL
an das Servlet übergeben. Die Post-Methode ist zur Übergabe größerer Datenmengen
gedacht und wird hier nicht verwendet.
KAPITEL 9 - DER SUCHDIENST
123
Die Datenbank ist so flexibel programmiert, daß in der Rating-Sektion einfach Attribute
(Erklärung der Bezeichnung Attribut siehe Kapitel 7 – Fehlertoleranter HTML-Konverter)
hinzugefügt werden können. Die Vorgehensweise dazu wird im Kapitel 10.5 –
Erweiterung der Datenbank um neue Attribute genauer erläutert. Dabei ist aber zu
beachten, daß die komplette Datenbank gelöscht werden muß; sie wird beim nächsten
Zugriff automatisch neu erzeugt. Es genügt, die Datenbank mit in Listing 9.3 gezeigten
Kommando zu löschen, wobei vorher eine Sicherheitsabfrage mit "y" bzw. "n"2
beantwortet werden muß.
java –Duser.timezone=ECT DB destroy [-StandardLog Name]
[-ErrorLog Name]
Listing 9.3: Aufruf eines Moduls zum Löschen der Datenbank
Das HTML-Dokument muß für die Suchabfrage um die neuen Attribute erweitert
werden, damit diese in die Suche einbezogen werden können (siehe nächster Abschnitt).
Listing 9.4 zeigt die HTML-Datei zum Aufruf des Suchservlets. Falls sich das Servlet in
einem anderen Verzeichnis befindet, muß der Pfad im HTML-Tag <FORM> entsprechend
angepaßt werden.
<HTML>
<HEAD>
<TITLE>Search</TITLE>
</HEAD>
<BODY>
<FORM METHOD="GET" ACTION="/servlets/SearchServlet">
<TABLE BORDER="0" WIDTH="540" CELLPADDING="4" CELLSPACING="0"
BGCOLOR="#23ca81">
<TR>
<TD ALIGN="LEFT" BGCOLOR="#23ca81">Search for</TD>
<TD><INPUT TYPE="TEXT" NAME="SEARCH_WORDS" SIZE="35"><BR>
<FONT size=-2>
Enter one or more words separated by spaces. Use "*"
or "?" or "%" or "_" as wildcards. Use AND, OR
and AND NOT as boolean operators.
</FONT></TD>
<TD ALIGN="RIGHT"><INPUT TYPE="SUBMIT" NAME="SEARCH"
CHECKED="CHECKED" VALUE=" Search ">
</TD>
</TR>
</TABLE>
<TABLE BORDER="0" WIDTH="540" CELLPADDING="3" CELLSPACING="0"
BGCOLOR="#239d62">
<TR>
<TD VALIGN="TOP" NOWRAP="NOWRAP">
<P>Search in<BR>
<INPUT TYPE="CHECKBOX" NAME="SEARCH_ATTR"
VALUE="Body"> Content (Full Text Search)<BR>
2
"y" steht für yes, "n" für no
124
KAPITEL 9 - DER SUCHDIENST
<INPUT TYPE="CHECKBOX" NAME="SEARCH_ATTR" VALUE="Title"
CHECKED="CHECKED"> Title<BR>
<INPUT TYPE="CHECKBOX" NAME="SEARCH_ATTR"
VALUE="Keywords" CHECKED="CHECKED"> Keywords<BR>
<INPUT TYPE="CHECKBOX" NAME="SEARCH_ATTR"
VALUE="Headings"> Headings<BR>
</P>
</TD>
<TD VALIGN="TOP" NOWRAP="NOWRAP">
<P>Search output<BR>
<INPUT TYPE="CHECKBOX" NAME="SEARCH_VIEW" VALUE="D"
CHECKED="CHECKED"> Description<BR>
<INPUT TYPE="CHECKBOX" NAME="SEARCH_VIEW" VALUE="K">
Keywords<BR>
</P>
<P>Sort the results by<BR>
<SELECT NAME="SEARCH_ORDER">
<OPTION value="RATING"
SELECTED="SELECTED">Importance</OPTION>
<OPTION value="LASTMODTIME">Modification
Date</OPTION></SELECT>
</P>
</TD>
</TR>
</TABLE>
</FORM>
</BODY>
</HTML>
Listing 9.4: Beispiel HTML-Dokument für ein Suchformular
9.3.1.1
Erweiterung der Suche um neue Attribute
Wird die Datenbank um bestimmte Attribute erweitert (siehe Kapitel auch 10.5), so ist
es nicht nötig, am Servlet Änderungen vorzunehmen, da es sich automatisch an die neuen
Gegebenheiten anpaßt. Zu beachten ist nur, daß der Name des Attributs im HTMLSuchformular mit der Bezeichnung in der Datenbank übereinstimmt. In der Konfigurationsdatei ist in der Sektion Rating ein neues Attribut, Applets, angegeben (siehe Listing
9.5).
# Attribute
[Rating]
Body
Title
Headings
Keywords
Applets
Rating
MaxCount
1
3
3
4
1
3
6
6
1
Listing 9.5: Erweiterte Rating-Sektion der Datenbankkonfigurationsdatei
KAPITEL 9 - DER SUCHDIENST
125
Dieses Attribut kann verwendet werden, um z.B. nach Dokumenten zu suchen, die ein
bestimmtes Java-Applet verwenden. Kandidaten dafür wären beispielsweise die ClassDateien BLUESCREEN, INSPECTCLIENT3 und ATTACKER, die auf dem Zielcomputer
unerwünschte Effekte haben. Dabei ist zu beachten, daß das Attribut vom HTMLKonverter auch extrahiert wird. Das HTML-Dokument muß ebenfalls angepaßt werden,
wobei das neue Attribut mit der in Listing 9.6 gezeigten Zeile an der richtigen Stelle
eingetragen werden muß.
<INPUT TYPE="CHECKBOX" NAME="SEARCH_ATTR" VALUE="Applets"> Java
Applets<BR>
Listing 9.6: Zeile im Suchformular bei Einfügen eines neuen Attributes
Nach dem kompletten Löschen der Datenbank kann mit dem Neuindizieren der Daten
begonnen werden, wobei jetzt auch die Namen der vorkommenden Applets berücksichtigt
werden. Der Anwender kann sofort nach Dokumenten, die bestimmte Applets verwenden,
suchen.
9.3.1.2
Beispiel einer SQL Abfrage
Das Suchservlet erzeugt aus den Angaben des Benutzers ein SQL Statement zur Abfrage
der Datenbank, wobei der Aufbau der Datenbank aus Kapitel 10.2.2 entnommen werden
kann. Aus der Suchangabe "taxi OR cab" in Schlüsselwörtern oder im Titel ergibt sich die
in Listing 9.7 gezeigte Abfrage.
SELECT DOCS.ID,URL,LASTMODTIME,WORDDOC.Title,WORDDOC.Keywords FROM
DOCS,WORDDOC,WORDS WHERE (WORD='taxi' OR WORD='cab') AND
WORDDOC.WORDID=WORDS.ID AND WORDDOC.DOCID=DOCS.ID AND
(WORDDOC.Title>0 OR WORDDOC.Keywords>0)
Listing 9.7: SQL Statement zur Suche nach bestimmten Dokumenten
Bei Verknüpfungen mit AND bzw. AND NOT werden zwei bzw. mehrere SQLAbfragen erzeugt und die Dokumente logisch miteinander verknüpft, da sonst die
Berechnung der richtigen Gewichtung der Dokumente nur schwer von der Datenbank
selbst durchgeführt werden kann. Auch wurde, wie in Kapitel 10 erläutert, die Abfrage auf
Verwendung eines Minimums an SQL-Befehlen optimiert, um die Verwendung möglichst
vieler SQL-Backends zu erlauben. Als Verknüpfung zweier SQL-Tabellen sollte
normalerweise INNER JOIN verwendet werden, was die Performance der Abfrage bei
bestimmten Datenbanken deutlich erhöhen könnte. Der SQL-Backend von Microsoft
Access (Jet Database Engine 3.5) zeigt hingegen bei mittleren Tabellen (40.000 Wörter)
keine wesentliche Verbesserung, was darauf schließen läßt, daß die Abfrage programmintern gleich behandelt wird.
Werden bei den Wörtern Wildcards wie '*' oder '%' (Platzhalter für beliebige Zeichenfolgen) und '?' oder '_' (Platzhalter für einzelnes Zeichen) verwendet, so muß bei SQLAbfragen der LIKE-Operator anstatt des '='-Operators verwendet werden. Die regulären
Ausdrücke werden vom Servlet erkannt und die SELECT-Anweisung entsprechend
KAPITEL 9 - DER SUCHDIENST
126
aufgebaut. Weitere Beispiele für mögliche Suchabfragen und die dabei zu verwendenden
SQL-Statements werden im Kapitel 10.4 – Suchabfragen ausführlich erklärt.
9.4 Einbindung des Servlets am Beispiel des
Webservers Jigsaw
Damit Servlets überhaupt verwendet werden können, müssen diese zuerst in einen
Webserver eingebunden werden. Dabei ist zu beachten, daß noch nicht alle verfügbaren
Webserver mit Servlets arbeiten können. In der vorliegenden Diplomarbeit wurde der frei
verfügbare Webserver Jigsaw beispielhaft gewählt, der vom World Wide Web Consortium
zur Verfügung gestellt wird3. Nach der Installation des Servers (Entpacken) kann das
Servlet SearchServlet.class in das Verzeichnis Jigsaw/Jigsaw/WWW/servlet/ kopiert
werden. Dies ist ab der Jigsaw Version 2.0.2 (März 1999) das Standardverzeichnis für
Servlets. Servlets werden darin automatisch erkannt.
Die Datei Search.html muß ebenfalls in ein Verzeichnis kopiert werden, so daß diese
über einen Browser aufgerufen werden kann. Als Verzeichnisse bieten sich
Jigsaw/Jigsaw/WWW/ oder auch Jigsaw/Jigsaw/WWW/servlet/ an, da HTMLDokumente automatisch von Servlets unterschieden werden. Vor dem ersten Aufruf von
Jigsaw muß die Installationsroutine gestartet werden. Davor sollte man aber den
Klassenpfad entsprechend setzen und zwar müssen folgende Archive und Verzeichnisse
erreichbar sein:
 jigsaw.zip,
 jigadmin.jar,
 jdsk.jar und
 das Verzeichnis mit den Klassen der vorliegenden Diplomarbeit.
Die Angabe des Klassenpfades ist dabei systemabhängig. Für Windows und Unix ergeben
sich beispielsweise die in Listing 9.8 gezeigten Pfade.
Windows:
set classpath=.;c:\programme\Jigsaw\classes\jigadmin.jar;
c:\programme\Jigsaw\classes\jigsaw.zip;d:\java\jsdk2.0\lib\jsdk.jar
;d:\java\projects\jarvester\
Unix:
classpath=.:/java/Jigsaw/classes/jigadmin.jar:/java/Jigsaw/classes/
jigsaw.zip:/java/jsdk2.0/lib/jsdk.jar:/java/projects/jarvester/
Listing 9.8: Klassenpfadangaben für Jigsaw unter Windows und Unix
Danach kann die Installationsroutine im Verzeichnis Jigsaw/Jigsaw des Webservers
aufgerufen und anschließend der Webserver gestartet werden (siehe Listing 9.9). Dabei ist
3
W3C Web Server Jigsaw, http://www.w3.org/Jigsaw/
KAPITEL 9 - DER SUCHDIENST
127
zu beachten, daß der Parameter –root auf das korrekte Installationsverzeichnis zeigt.
Installation:
java Install.class
Start des Webservers:
java org.w3c.jigsaw.Main -root /java/Jigsaw/Jigsaw
Listing 9.9: Aufruf der Installationsroutine und Start von Jigsaw
Damit das Servlet auf die Konfigurationsdatei für die Datenbank zugreifen kann, muß
nun mit dem Initialisierungsparameter DB_CFG_PATH der korrekte Pfad angegeben werden,
wie nachfolgend beschrieben wird. Der Dateiname der Konfigurationsdatei ist im Modul
Common angegeben (siehe auch Kapitel 0).
Nach Aufruf des Administrationsprogrammes (siehe Listing 9.10) und Eingabe des
korrekten Usernamens und Paßwortes (z.B. User Admin, Paßwort Admin) bei Verwendung von Java 2 (ehemals Version 1.2) öffnet sich das in Abbildung 9.4 gezeigte Fenster.
java org.w3c.jigadmin.Main -root /java/Jigsaw/Jigsaw
http://host:8009
Listing 9.10: Aufruf des Administrationsprogrammes von Jigsaw
Abbildung 9.4: Konfiguration des Suchservlets in Jigsaw
Ist Java in der Version 1.1.X installiert, kann man auch eine Version des Administrationsprogrammes ohne Verwendung der erst in Java 2 eingeführten Swing-Library starten.
128
KAPITEL 9 - DER SUCHDIENST
Der dabei zu verwendende Aufruf ist in Listing 9.11 zu sehen.
java org.w3c.jigadm.Main -root /java/Jigsaw/Jigsaw http://host:8009
Listing 9.11: Aufruf des Administrationsprogrammes von Jigsaw ohne Swing
Das Interface bietet die gleiche Funktionalität, aber Darstellung und Handling differieren. Jetzt kann der Initialisierungsparameter für das SearchServlet konfiguriert werden.
Dazu markiert man den Eintrag für SearchServlet (siehe Abbildung 9.4 links unten) und
aktiviert die Schaltfläche zum Editieren der Objekteigenschaften. Daraufhin öffnet sich das
in Abbildung 9.5 dargestellte Fenster. Im unteren Bereich befinden sich die Servlet
Parameter. Durch Klick auf die Schaltfläche Edit kann man den Parameter DB_CFG_PATH
eingeben, beispielsweise mit den in Listing 9.12 gezeigten Werten.
Unix:
/java/projects/jarvester/
Windows:
d:\java\projects\jarvester
Listing 9.12: Werte für Servlet Parameter DB_CFG_PATH in Jigsaw
Der abschließende Slash oder Backslash kann weggelassen werden, er wird
vom Servlet automatisch angenommen.
Es ist darauf zu achten, daß die Eingaben
mit Commit (links unten im Fenster) und
anschließendem Klick auf die Schaltfläche Save (im Admin-Fenster neben
Stop) zu bestätigen und zu speichern
sind, da sonst keine Änderungen
übernommen werden.
Zusätzlich muß noch das JSDK ab
Version 2.0 vorhanden sein, wobei man
aber nur das Archiv jsdk.jar benötigt.
Dieses muß, wie oben gezeigt, ebenfalls
über den Klassenpfad erreichbar sein.
Wie im Kapitel 9.3 beschrieben worden
ist, muß darauf geachtet werden, daß im
Suchformular Search.html der korrekte
Pfad (relativ zum Dokumentenverzeichnis des Webservers) des Servlets
angegeben ist.
Abbildung 9.5: Konfiguration der Parameter des Searchservlets
KAPITEL 9 - DER SUCHDIENST
129
9.5 Zusammenfassung
In diesem Kapitel wurde der Suchdienst näher erläutert. Dieser ermöglicht über ein
Webformular die Suche nach bestimmten Dokumenten im vom Gatherer erfaßten
Datenbestand. Der Gatherer muß entsprechend konfiguriert werden, um alle durchforsteten
Dokumente der Datenbank zum Indizieren zu übergeben (siehe Kapitel 6.3.1). Die
indizierten Daten werden in einer relationalen Datenbank zwischengespeichert und stehen
für Abfragen zur Verfügung. Die Abfrage erfolgt dabei über ein Servlet mit JDBC
Anbindung, wobei dabei die im Formular eingegebenen Daten verwendet werden.
Die gefundenen Dokumente werden als HTML-Dokument an den Browser zurückgegeben. Dabei werden zusätzlich statistische Informationen über die Abfrage, wie die Anzahl
der gefundenen Dokumente und eine sortierte Auflistung aller gefundenen Dokumente,
angezeigt. Das Suchergebnis kann dabei durch Verändern bestimmter Parameter im
Suchformular, wie etwa der Sortierreihenfolge (Datum der letzten Änderung oder
Relevanz des Dokumentes) und der anzuzeigenden Attribute beeinflußt werden (siehe
Abschnitt 9.1). Abschnitt 9.2 behandelte die Konfiguration des Suchservlets und Abschnitt
9.4 zeigte die Einbindung des Servlets in einen Webserver. In Abschnitt 9.3 wurden einige
programmiertechnische Details des Servlets behandelt.
Im folgenden Kapitel 10 wird die Anbindung der Module an eine beliebige relationale
Datenbank erläutert. Nach einer Einführung in die Struktur der Datenbank und die
Konfiguration werden die Vorgänge beim Einfügen und Löschen von Dokumenten in die
Datenbank beschrieben. Beispiele für Suchabfragen und Details zur Implementierung
schließen das Kapitel ab.
Kapitel 10
Datenbank – Anbindung und Aufbau
Die vorangegangenen Kapitel haben sich damit befaßt, wie Informationen und
Metainformationen über Dokumente gesammelt (siehe Kapitel 6 – Der Gatherer) und
extrahiert werden (siehe Kapitel 7 – Fehlertoleranter HTML-Konverter). Um diese
Informationen nutzen zu können, wurden in der vorliegenden Arbeit Schnittstellen wie das
Gatherer-Collector-Interface (siehe Kapitel 8) und der Suchdienst, der es ermöglicht, über
ein Webinterface mittels Eingabe von Stichwörtern nach bestimmten Dokumenten im
Datenbestand suchen zu können, behandelt.
Die extrahierten Informationen der Dokumente werden in einer Datenbank verwaltet.
Dieses Kapitel beschreibt die verwendeten Datenstrukturen und zeigt die Vorgänge auf, die
beim Einfügen und Löschen von Dokumenten bzw. bei Indizieren der darin vorkommenden Begriffe ablaufen. Zuerst werden die Anforderungen an die Datenbank und der daraus
resultierende Aufbau der Implementierung beschrieben und danach Beispiele für Abfragen
gegeben.
10.1 Zielsetzung
Die Behandlung von Dokumenten- und Zusatzinformationen, Indizierung aller
vorkommenden Wörter, Bewertung der gefundenen Dokumente und Relevanz der
Suchwörter werden in diesem Kapitel genauer spezifiziert. Die hier beschriebenen Ziele
sind in der vorliegenden Diplomarbeit implementiert.
Dokumenteninformationen
Die Datenbank soll die Verwaltung der gesammelten Dokumente ermöglichen.
Dokumente, die seit dem letzten Gatherdurchgang geändert wurden, sollen schnell erkannt
werden. Es soll ein Mechanismus eingebaut werden, um eine inkrementelle Weitergabe1
neuer Dokumente zu ermöglicht. Dazu bietet sich das Datum der letzten Änderung an.
Ebenso soll die Möglichkeit bestehen, Dokumente, auf die seit einer bestimmten
Zeitspanne nicht mehr zugegriffen werden kann, zu erkennen und bei Bedarf zu löschen.
1
Zur Reduzierung der über das Netz zu transportierenden Daten ist die Möglichkeit, nur
seit der letzten Übertragung geänderte Dokumente abzufragen, notwendig.
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
131
Die Verweilzeit ist notwendig, da Dokumente kurzzeitig nicht mehr erreichbar sein
können, weil beispielsweise gerade Änderungen vorgenommen werden oder das Dokument
kurzzeitig nicht verfügbar ist.
Die Dokumente selber sollen analysiert werden und ebenfalls auf Abruf bereit stehen.
Auf unterschiedliche Attribute wie Überschriften, Titel, Zusammenfassungen oder
Schlüsselwörter soll bei eventuellen Abfragen schnell zugegriffen werden können.
Zusatzinformationen
Zusätzlich zu den Dokumenten sollen ebenfalls einer bestimmten URL zugeordnete
Zusatzinformationen verwaltet werden. Diese Informationen können nicht immer, wie das
etwa bei HTML der Fall ist, in die beschriebenen Objekte selbst integriert werden, darum
soll die Möglichkeit zusätzlicher externer Informationsdateien implementiert werden. Bei
den Zusatzinformationsdateien gelten dabei ähnliche Kriterien wie bei den Dokumenten
selbst, geänderte bzw. gelöschte Informationen sollen einfach erkannt werden. Die
Zusatzinformationen können dann von übergeordneten Suchmodulen dazu verwendet
werden, den Anwender bei der Such nach bestimmten Dokumenten zu unterstützen (siehe
auch Abschnitt 2.3.4).
Index aller vorkommenden Wörter
Die gesammelten Dokumente sollen nach bestimmten Wörtern durchsucht werden
können. Dazu ist es nötig, einen Index aller vorkommenden Wörter zu bilden und damit
eine Verbindung Dokument – Wort herzustellen. Ebenfalls soll eine Suche in verschiedenen Attributen eines Dokuments wie Volltext, Überschriften oder Schlüsselwörtern
ermöglicht werden.
Bewertung (Ranking) der Suchergebnisse
Die gefundenen Dokumente sollen bewertet und nach Wichtigkeit sortiert werden
können. Das Gewicht hängt dabei von der Anzahl der im Dokument gefundenen
Suchbegriffe ab und von der Position der Worte im Dokument. Dabei sollen etwa Begriffe
in Überschriften mehr Gewicht haben als solche, die wahllos im Text vorkommen (siehe
auch Abschnitt 2.3.5).
Relevanzbeurteilung der Suchwörter
Ist die Suchmaschine etwa einem bestimmten Webserver oder Thema zugeordnet, dann
ist es wahrscheinlich, daß bestimmte Begriffe auf praktisch allen Dokumenten vorkommen
und daher für die Suche logischerweise nicht relevant sind. Die Datenbank soll eine
Erkennung solcher Wörter ermöglichen und so die Relevanz der gefundenen Dokumente
im Suchergebnis erhöhen (siehe auch Abschnitt 2.3.5).
Statisch kann die Ausscheidung bestimmter Wörter mittels Stoppliste geschehen. Bei
dynamischer Relevanz muß die Anzahl der Dokumente ermittelt werden können, in denen
das gesuchte Wort vorkommt und zwar nach unterschiedlichen Attributen getrennt. Es
kann sein, daß ein Wort als Schlüsselwort in fast allen Dokumenten vorkommt, aber im
Titel nur selten und daher dort relevanter ist.
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
132
10.2 Datenbankdesign
Relationale Datenbanksysteme verfügen heute über Zugriffsmechanismen, die es
erlauben, effizient auch nach Textteilen zu suchen, wobei als Abfragesprache meist SQL
verwendet wird. Alle großen Datenbankanbieter bieten JDBC2 Interfaces bzw. sind dabei,
diese zu entwickeln. Dieses Interface bietet die Möglichkeit, von der in dieser Diplomarbeit verwendeten Programmiersprache Java mittels SQL auf die Datenbank zuzugreifen.
Nach einer kurzen Einführung in die Grundprinzipien relationaler Datenbanken werden
die einzelnen verwendeten Relationen erläutert.
10.2.1 Theorie relationaler Datenbanken
Bei relationalen Datenbanken werden Daten in Tabellen (sogenannten Relationen)
abgelegt. Dabei entspricht jede Zeile einem Datensatz bzw. Objekt. Die Spalten enthalten
die Attribute der Objekte. [Dat1986]
Damit Datenbankanomalien vermieden werden, müssen die Relationen den Normalformen entsprechen. Die erste Normalform besagt, daß die Attributtypen elementar sein
müssen, das heißt, zusammengesetzte Typen wie Felder oder Strukturen sind nicht erlaubt.
Da aber Dokumente im Allgemeinen eine beliebige Anzahl von Wörtern beinhalten,
können diese nicht als Attribute direkt dem Dokument zugeordnet werden. Zuordnungen
von Dokument zu erhaltenen Wörtern sind nicht durch eine Zeile realisierbar. Pro Wort im
Dokument ist jeweils ein eigener Eintrag in einer Tabelle notwendig. Doch auch diese
Form ist noch nicht zielführend, da leicht Redundanzen auftreten und unnötig Speicher
verbraucht wird (siehe Tabelle 10.1). [Dat1986]
Wort
Häufigkeit im
Dokument
Gesamthäufigkeit
...
...
...
http://test.at/Euro.html
Haus
2
11
http://test.at/Euro.html
Euro
5
47
http://server/Haus.html
Haus
6
11
...
...
...
Dokument URL
...
...
Tabelle 10.1: Relation mit redundanten Einträgen
Bei einer Änderung eines Dokuments müßten ebenfalls alle zugehörigen Zeilen geändert
werden, sonst kommt es zu Inkonsistenzen der Daten und die Integrität der Datenbank ist
nicht mehr gewährleistet.
2
JDBC ist ein eigenständiger Begriff, den man sich von Java Database Connectivity
abgeleitet vorstellen kann.
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
133
Dieses Problem kann man durch Einführung der zweiten Normalform lösen. Dazu teilt
man die Tabelle auf und stellt Verbindungen zwischen den Tabellen mit sogenannten
eindeutigen Schlüsseln her. Ein Schlüssel ist die kleinste Attributmenge, die ein Objekt
einer Tabelle eindeutig bestimmt. Die zweite Normalform besagt, daß kein Nichtschlüsselattribut nur von einem Teil des Schlüssels abhängig sein darf. In obiger Tabelle wären die
URL des Dokuments und das Wort gemeinsam der Schlüssel, das Attribut Gesamthäufigkeit ist aber nur vom Wort abhängig. [Dat1986]
Die Häufigkeit im Dokument hingegen ist vom gesamten Schlüssel abhängig. Es gibt
weitere Normalformen, die beim Datenbankdesign zu berücksichtigen sind [Dat1986], die
aber hier keine weitere Rolle spielen. Durch Aufteilen der Relation ergeben sich die in
Tabelle 10.2 gezeigten Tabellen, die jeweils über die Identifikationsnummer miteinander in
Beziehung stehen.
Dokumententabelle
Dok.
URL
ID
Worttabelle
Wort
Wort
ID
Dokument-Wort-Tabelle
Gesamthäufigkeit
Dok. Wort Häufigkeit im
ID
ID
Dokument
...
...
...
...
...
...
...
...
6
http://test.at/Euro.htm
11
euro
47
6
11
5
10
http://server/Haus.html
99
haus
11
6
99
2
...
...
...
...
...
10
99
6
...
...
...
...
...
...
...
...
Tabelle 10.2: Aufgeteilte Relationen ohne Redundanzen (2. Normalform)
10.2.2 Relationen der Dokumentenverwaltung
In diesem Abschnitt werden die einzelnen Tabellen der Dokumentenverwaltung und des
Suchindex genauer beschrieben. Der darauf folgende Abschnitt 10.3 erläutert, wie das
Aufnehmen der Dokumente und Zusatzinformationen in die Datenbank, die Indizierung
und die Abfrage der zu suchenden Daten durchgeführt wird.
Prinzipiell wurde jedes Objekt der Problemstellung, also Dokumente, Informationen und
Wörter in den einzelnen Attributen in einer Relation abgebildet, damit die in Abschnitt
10.2.1 beschriebene Normalform erreicht wird. Eine weitere Relation wird benötigt, um
Beziehungen und Beziehungseigenschaften zwischen zwei Objekten darzustellen. So steht
in einer solchen Tabelle etwa welches Wort in welchem Dokument wie oft vorkommt.
10.2.2.1 Dokumente
Diese Relation enthält alle für den Gatherer nötigen Daten, damit dieser entscheiden
kann, ob ein Dokument neuerlich indiziert werden soll oder nicht. Neben einer eindeutigen
Identifikationsnummer enthält die Tabelle die URL eines Objektes (siehe Tabelle 10.3).
Abschnitt 10.2.3 beschreibt, wie die generierten und extrahierten Informationen der
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
134
analysierten Dokumente gespeichert werden.
ID URL
MD5
UPDATETIME TTL
LASTMODTIME
...
...
...
...
...
...
7
http://test.at/Set.html
b749b5a4...
923433021
100000 889182982
8
http://eur.at/index.htm 3df345a9...
923433032
300000 888407416
...
...
...
...
...
...
Tabelle 10.3: Struktur der Dokumentenrelation
Die Last-Modification-Time eines Dokuments ist die Zeit, zu der es das letzte Mal
bearbeitet wurde und wird in Sekunden seit dem 1.1.1970 0:00 GMT angegeben. Die
Update-Time eines Dokuments gibt an, wann es zuletzt mit dem Gatherer auf Veränderungen überprüft wurde. Die Time-To-Live (TTL) gibt an, wie lange das Dokument nach dem
letzten erfolgreichen Update noch in der Datenbank verbleiben soll. Wird ein Dokument
nicht mehr gefunden (weil es zum Beispiel gerade bearbeitet wird und derzeit nicht
zugreifbar ist), wird die Update-Time nicht mehr aktualisiert. Wird das Dokument bei
mehreren aufeinanderfolgenden Gathervorgängen nicht gefunden, wird es nach Ablauf der
Time-To-Live aus der Datenbank entfernt.
Um zu ermitteln, ob sich ein Dokument seit dem letzten Gathervorgang geändert hat,
prüft der Gatherer die Last-Modification-Time. Diese wird bei lokalem Zugriff über das
Dateisystem korrekt zurückgegeben. Wird auf Dokumente aber mittels HTTP zugegriffen,
kann es unter Umständen Probleme geben, da manche Webserver die Last-ModificationTime nicht im HTTP-Header angeben. Ist das der Fall, wird automatisch die MD5Checksumme der Datei gebildet und Änderungen können ebenfalls festgestellt werden. Die
Dokumentenrelation wird in den Beispielen der folgenden Abschnitte Docs genannt.
10.2.2.2 Zusatzinformationen
Die Zusatzinformationen werden genau gleich behandelt wie die Dokumente selbst. Der
einzige Unterschied besteht in der Interpretation der Werte selbst. Ein Informationsdokument beschreibt nicht nur die URL, die es darstellt näher, sondern auch alle Dokumente,
die mit dieser URL beginnen. So sind zum Beispiel Beschreibungen des Inhalts eines
kompletten Servers als auch einzelner Teilbereiche sowie einzelner Dokumente möglich.
Tabelle 10.4 demonstriert das. Der erste Fall ist die Beschreibung einer ganzen Web-Site,
im zweiten Fall wird ein Teil des Web-Servers beschrieben. Die dritte Zeile beschreibt ein
einzelnes Dokument. Der Aufbau der Zusatzinformationsdateien ist im Kapitel 6.4 –
Zusatzinformationen näher erläutert.
ID URL
MD5
UPDATETIME TTL
LASTMODTIME
... ...
...
...
...
...
6 http://test.at/
c799b5a4...
923434021
220000 899182982
9 http://test.at/users
3fff34559...
923434032
360000 898407416
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
135
7 http://test.at/Start.htm 3df345a9...
923433032
300000 888407416
... ...
...
...
...
...
Tabelle 10.4: Struktur der Zusatzinformationsrelation
10.2.2.3 Wörter
In dieser Relation werden die in den Dokumenten vorkommenden Begriffe gespeichert.
Neben einer eindeutigen Identifikationsnummer und dem eigentlichen Wort sind noch
diverse Zähler in der Tabelle, die angeben, wie oft die einzelnen Wörter in allen indizierten
Dokumenten in verschiedenen Attributen wie Überschriften und Schlüsselwörtern
vorkommen (siehe Tabelle 10.5). Die Art und Anzahl der Attribute in der Datenbank hängt
dabei von den Angaben in der Rating-Sektion der Konfigurationsdatei der Datenbank ab.
Bei erstmaligem Erzeugen der Datenbank, also beispielsweise beim ersten Aufruf des
Gatherers werden die Tabellen automatisch aufgebaut, so daß alle gewünschten Attribute
indiziert werden können.
Werden die Angaben in der Rating-Sektion, also die Namen bzw. die Anzahl der
Attribute geändert, dann muß die Datenbank neu aufgebaut werden. Die Vorgehensweise
ist im Kapitel 10.5 – Erweiterung der Datenbank um neue Attribute genauer beschrieben.
ID
WORD
Body
Title
Headings
Keywords
...
...
...
...
...
...
1000
euro
4
1
1
0
1444
haus
4
0
0
2
1557
test
1
0
0
2
...
...
...
...
...
...
Tabelle 10.5: Struktur der Wortrelation
Beim Indizieren werden die Wörter eines Dokuments in diese Tabelle eingetragen und
die Zähler entsprechend gesetzt. Ist das Wort schon in der Datenbank vorhanden, werden
nur die Zähler entsprechend erhöht. Bei Löschen eines Dokuments werden die Zähler
reduziert. Haben alle Zähler den Wert Null, ist dieses Wort in keinem Dokument mehr
vorhanden. Der Eintrag bleibt jedoch bestehen, was den Aufwand des Löschens und
eventuell Neueintragens erspart. Die Tabelle wird in den folgenden Abschnitten Words
genannt.
Damit möglichst nur aussagekräftige Wörter in die Datenbank aufgenommen werden,
wurde noch ein spezieller Wortfilter implementiert, um etwa zu kurze (z.B. nur aus einem
Buchstaben bestehende) oder zu lange Wörter von vornherein ausschließen zu können. Als
wichtiger Filter ist hier LowerCase zu nennen, damit in der Datenbank nicht unnötig
verschiedene Schreibweisen ein und desselben Wortes vorkommen (etwa 'gestern' und
'Gestern'). Das hat zur Folge, daß natürlich kein Unterschied zwischen Groß- und
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
136
Kleinschreibung gemacht wird und so bei der Suche auch nicht danach unterschieden wird.
Die Filter werden im Abschnitt 10.6.2 näher beschrieben.
Erweiterungsmöglichkeit
Hier bieten sich auch Ansätze für Erweiterungsmöglichkeiten, da leicht ein Synonymfilter oder Filter, die Wörter auf ihren Wortstamm reduzieren (Stemming, siehe auch
Abschnitt 2.1.1), eingebaut werden können.
10.2.2.4 Wort-Dokument-Beziehung
Diese Relation stellt die Verbindung zwischen Worten und Dokumenten her. Jeder
Eintrag enthält eine Wort- und eine Dokumentenidentifikationsnummer jenes Dokuments,
in dem das Wort vorkommt. Beide Nummern bilden den Schlüssel für diese Relation. Die
zusätzlichen Informationen, wie Keywords, enthalten Zähler, die angeben, wie oft das
Wort in einem Dokument im entsprechenden Attribut vorkommen (siehe Tabelle 10.6).
Die Anzahl der Attribute hängt, wie bei der Wortrelation, von der Rating-Sektion der
Konfigurationsdatei der Datenbank ab (siehe Kapitel 10.6.3).
WORDID
DOCID
Body
Title
Headings
Keywords
...
...
...
...
...
...
1000
8
4
1
1
0
1444
7
4
0
0
2
1557
7
1
0
0
2
...
...
...
...
...
...
Tabelle 10.6: Struktur der Wort-Dokumentenrelation
Anhand der Zählerinformation kann bei Abfragen bestimmt werden, ob das gesuchte
Wort in den Schlüsselwörtern oder im Titel vorkommt. Die Tabelle wird im folgenden mit
dem Namen WordDoc bezeichnet.
10.2.3 Dokument- und Informationsspeicherung
Alle gesammelten Dokumente und Informationsdateien werden in einem speziellen
Format in einem Verzeichnis abgelegt. Der Name des Verzeichnisses ist in der
Konfigurationsdatei der Datenbank angegeben. Das Format ist flexibel, so daß beliebige
Attribut-Wert-Paare in den Objekten vorkommen können. Da alle Dokumente eine
eindeutige Identifikationsnummer haben, wird diese zur Erzeugung der Dateinamen
verwendet. Das Dokument mit der Nummer 10 wird etwa unter dem Namen id10.doc im
angegebenen Verzeichnis gespeichert. Informationsdateien bekommen die Endung ".inf",
eine Datei hat beispielsweise den Namen "id399.inf".
Die Abspeicherung der Daten in einem allgemeinen Format hat den Vorteil, daß die
Daten auf Wunsch (über das zur Verfügung stehende Interface, siehe Kapitel 8 – Das
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
137
Gatherer-Collector-Interface) in einem beliebigen Format wie etwa SOIF oder XML
ausgegeben werden können (siehe Kapitel 11.13 – AVTableConverter).
10.3 Arbeitsweise
Nachdem im vorangegangenen Abschnitt die logische Struktur der Datenbank aufgezeigt wurde, wird nun besprochen, wie diese Struktur für die Indizierung und Speicherung
verwendet wird. Die einzelnen Datenbankoperationen wie Einfügen und Löschen werden
detailliert behandelt.
10.3.1 Einfügen
Ein Dokument beeinflußt die Relationen für Wörter, Dokumente und die WortDokument-Tabelle. Informationsdateien werden in die Relation für Informationen
aufgenommen, wobei diese Relation die selbe Funktion wie die für Dokumente hat. Das
Einfügen und Löschen erfolgt analog und wird hier nicht näher erläutert.
Einfügen in die Dokumentenrelation
Ist das Dokument schon in der Relation vorhanden, wird die Last-Modification-Time
geprüft. Das ist die Zeit, zu der es das letzte Mal bearbeitet wurde. Differiert diese Zeit von
der in der Datenbank gespeicherten, wurde also das Dokument mit großer Wahrscheinlichkeit geändert und muß neu indiziert werden. Dazu wird das Dokument komplett aus der
Datenbank entfernt wie im Kapitel 10.3.2 beschrieben und mit der selben Dokumentennummer wieder neu eingefügt. Hat sich das Dokument seit dem letzten Einfügevorgang
nicht geändert, muß nur die Update-Time neu gesetzt werden. Die Update-Time eines
Dokuments gibt an, wann es zuletzt auf Veränderungen geprüft wurde.
Falls das Dokument noch nicht vorhanden ist, wird ein neuer Eintrag mit neuer
Dokumentennummer erzeugt und die korrekten Werte für MD5-Checksumme, UpdateTime und Time-To-Live eingetragen. Die Time-To-Live gibt an, wie lange das Dokument
nach dem letzten erfolgreichen Update noch in der Datenbank verbleiben soll. Wird ein
Dokument nicht mehr gefunden (weil es zum Beispiel gerade bearbeitet wird und derzeit
nicht zugreifbar ist), wird die Update-Time nicht mehr aktualisiert. Wird das Dokument bei
mehreren aufeinanderfolgenden Gathervorgängen nicht gefunden, wird es nach Ablauf der
Time-To-Live aus der Datenbank entfernt.
Eine neue Dokumentennummer ist immer um eins höher als die höchste bisher
verwendete, auch wenn ein Dokument mit niedriger Nummer gelöscht wurde und diese
frei wäre. Das bedeutet aber keine wirkliche Einschränkung, wenn man annimmt, daß die
Dokumentennummer eine Long-Zahl ist. Auch wenn pro Tag eine Million Dokumente
gelöscht werden und ebenfalls eine Million neu dazukommen (keine Änderungen der
Dokumente, da hier die Nummer des geänderten Dokuments beibehalten wird), dann kann
der Gatherer 5*1010 Jahre ohne Neustart laufen.
Einfügen in die Wortrelation
Die einzelnen Wörter werden nach den in der Rating-Sektion angegebenen Attributen
analysiert und gezählt. Damit möglichst nur aussagekräftige Wörter in die Datenbank
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
138
aufgenommen werden, werden sie erst durch einen Wortfilter geschickt. Diese Angaben
sind in der Sektion WordFilter zu finden.
Danach werden die Wörter einzeln in die Datenbank eingefügt. Ist ein Wort schon
vorhanden, dann werden nur die jeweiligen Zähler der Attribute (also beispielsweise Body
oder Keywords) um eins erhöht, da dieses Wort nun einem weiteren Dokument zugeordnet
wird. Kommt etwa das Wort im Dokumenttitel vor, dann wird das Tabellenattribut Title
um eins inkrementiert (d.h. die Häufigkeit des Wortes wird hier nicht berücksichtigt).
Falls das Wort nicht gefunden wurde, wird ein neuer Eintrag in der Tabelle erstellt. Hier
wird ebenfalls die höchste verwendete Wortnummer ermittelt, um eins erhöht und dem
neuen Wort zugewiesen. Die höchste Nummer wird pro Dokument nur einmal geholt, da
die weiteren freien Nummern einfach durch inkrementieren erhalten werden können. Die
Attributzähler des neuen Eintrages werden auf Eins beziehungsweise Null gesetzt, je
nachdem, ob das Wort im entsprechenden Attribut vorkommt oder nicht.
Einfügen in die Wort-Dokument-Relation
Für jedes Wort im Dokument wird ein Eintrag in der Wort-Dokument-Tabelle erstellt.
Er enthält die Dokument- und die Wort-Identifikationsnummer und die Anzahl des
Auftretens des Wortes im Dokument in den einzelnen Attributen. Hier wird die Häufigkeit
der Wörter im Dokument vermerkt. Kommt ein Wort dreimal im Volltext vor und einmal
im Titel, so wird Body auf 3 und Title auf 1 gesetzt.
10.3.2 Löschen
Die Löschoperation wird aufgerufen, wenn ein Dokument mit gleicher URL und
jüngeren Datums in die Datenbank aufgenommen werden soll, bzw. wenn Dokumente
nicht mehr existieren und die Time-To-Live abgelaufen ist. Für Informationsdateien gilt
dasselbe, nur bezieht sich der Löschvorgang auf die Informationsdateienrelation.
Löschen aus der Dokumentenrelation
Ist der zu löschende Eintrag vorhanden, wird er aus der Tabelle gelöscht.
Löschen aus der Wort-Dokument-Relation
Die Einträge in dieser Relation werden gelöscht. Davor werden aber die Attributzähler
zur Ermittlung der zu ändernden Zähler in der Wortrelation verwendet.
Behandlung der Wortrelation
Bei allen Wörtern, die aus der Wort-Dokument-Relation gelöscht werden, werden hier
die entsprechenden Attributzählern angepaßt. Ist ein Attributzähler in der Wort-DokumentRelation größer als Null, wird der jeweilige Attributzähler im Eintrag der Worttabelle des
Wortes um eins verkleinert. Hat zum Beispiel der Attributzähler Body der WortDokumenten-Relation den Wert fünf, muß der Attributzähler Body der Worttabelle um
eins verkleinert werden. Das Wort kommt also in einem Dokument weniger im Volltext
vor.
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
139
10.4 Suchabfragen
Abfragen an die Datenbank werden mittels SQL über das JDBC-Interface von Java
ausgeführt. Mit dem SQL-Befehl SELECT lassen sich Zeilen einer Tabelle ausgeben.
Welche Zeilen ausgegeben werden sollen, lassen sich mit einer WHERE-Klausel
bestimmen. Da Wort- und Dokumentattribute aufgrund der zweiten Normalform in
unterschiedlichen Tabellen verwaltet werden, muß die Suche nach einem Dokument immer
über drei Tabellen erfolgen. SQL bietet die Möglichkeit, das Kreuzprodukt von Tabellen
mittels der Join-Operation zu bilden [Barn1997]. Hierbei wird eine neue, temporäre
Tabelle erzeugt, die alle möglichen Zeilenkombinationen beinhaltet. Die SQL-Abfrage ist
in Listing 10.1 gezeigt.
SELECT DOCS.*, WORDDOC.*, WORDS.*
FROM WORDDOC, WORDS, DOCS;
Listing 10.1: SELECT-Statement zur Verknüpfung mehrerer Tabellen
Tabelle 10.7 zeigt das Kreuzprodukt aus den drei in Tabelle 10.2 im Abschnitt 10.2.1
angegebenen Beispieltabellen.
DOCS
ID
URL
...
6
6
6
6
6
6
10
10
10
10
10
10
...
...
http://test.at/Euro.html
http://test.at/Euro.html
http://test.at/Euro.html
http://test.at/Euro.html
http://test.at/Euro.html
http://test.at/Euro.html
http://server/Haus.html
http://server/Haus.html
http://server/Haus.html
http://server/Haus.html
http://server/Haus.html
http://server/Haus.html
...
WORD DOC Dok. WORD WORDS. Ges.
ID
ID Häufkt
ID
Häufkt
...
99
99
99
99
11
11
99
99
99
99
11
11
...
...
10
10
6
6
6
6
10
10
6
6
6
6
...
...
6
6
2
2
5
5
6
6
2
2
5
5
...
...
haus
euro
haus
euro
haus
euro
haus
euro
haus
euro
haus
euro
...
...
99
11
99
11
99
11
99
11
99
11
99
11
...
...
11
47
11
47
11
47
11
47
11
47
11
47
...
Tabelle 10.7: Kreuzprodukt dreier Tabellen
Wie man sieht, ergeben sich alle möglichen Kombinationen (2 mal 2 mal 3). So steht
zum Beispiel das Wort "euro" gemeinsam in einer Zeile mit "http://test.at/Haus.html",
obwohl das Wort in diesem Dokument gar nicht vorkommt. Aus diesem Grund muß mit
einer Where-Klausel beschrieben werden (siehe Beispiel in Listing 10.2), welche Zeilen
der ursprünglichen Tabellen logisch zusammengehören [Barn1997]. Im Fall des Index
werden Zeilen nur dann zusammengelegt, wenn die Identifikationsnummern gleich sind.
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
140
Das Ergebnis des SELECT-Statements zeigt Tabelle 10.8.
SELECT DOCS.*, WORDDOC.*, WORDS.*
FROM WORDDOC, WORDS, DOCS
WHERE DOCS.ID=WORDDOC.DOCID AND WORDS.ID=WORDDOC.WORDID
Listing 10.2: SELECT-Statement mit Where-Klausel
DOCS
ID
URL
...
6
6
10
...
...
http://test.at/Euro.html
http://test.at/Euro.html
http://server/Haus.html
...
WORD DOC Dok. WORD WORDS. Ges.
ID
ID Häufkt
ID
Häufkt
...
99
11
99
...
...
6
6
10
...
...
2
5
6
...
...
haus
euro
haus
...
...
99
11
99
...
...
11
47
11
...
Tabelle 10.8: Mit Where-Klausel eingeschränktes Kreuzprodukt dreier Tabellen
Bei vielen Datenbanksystemen besteht ebenfalls die Möglichkeit mehrere Tabellen zu
verknüpfen. Dabei wird der JOIN-Operator verwendet. Da Join allerdings nicht bei allen
SQL-Backends implementiert ist und die Software möglichst universell einsetzbar sein
soll, wurde darauf geachtet, nur unbedingt notwendige Operatoren zu verwenden. Um mit
dem JOIN-Operator aus der Datenbank die URL eines Dokuments zu bekommen, die ein
bestimmtes Wort enthält, kann man den in Listing 10.3 gezeigten Befehl verwenden.
SELECT DOCS.URL
FROM (WORDDOC INNER JOIN WORDS ON WORDDOC.WORDID = WORDS.ID) INNER
JOIN DOCS ON WORDDOC.DOCID = DOCS.ID
WHERE (((WORDS.WORD)="euro"))
Listing 10.3: SELECT-Statement mit Join-Operator
Diese Art der Abfrage kann die Performance bei bestimmten Datenbanken deutlich
erhöhen. Der SQL-Backend von Microsoft Access (Jet Database Engine 3.5) zeigt
hingegen bei mittleren Tabellen mit etwa 40.000 Wörtern keine wesentliche Verbesserung,
was darauf schließen läßt, daß die Abfrage intern gleich wie Abfragen mit WHERE
behandelt werden dürfte.
Die nachfolgenden Abschnitte geben Beispiele für Suchabfragen bei bestimmten
Aufgabenstellungen und wurden entnommen aus [Neussl1998]. Die Funktionsweise der
verschiedenen SQL-Befehle wird in [Barn1997] anhand von Beispielen genauer erläutert.
10.4.1 Suchabfrage mit einem Wort
Wird nach einem Dokument gesucht, das ein bestimmtes Wort enthalten soll, werden
wie im letzten Abschnitt gezeigt, die Dokument-, die Wort- und die Wort-DokumentTabelle miteinander verknüpft. Zusätzlich werden die einzelnen Datensätze mit der
WHERE-Klausel so eingeschränkt, daß die Dokumenten- und Wortidentifikations-
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
141
nummern übereinstimmen. Eine weitere Bedingung in der Klausel gibt schließlich an,
welches Wort in der Zeile vorhanden sein muß. Die Abfrage aus Listing 10.4 liefert mit
den Beispiel-Tabellen aus Abschnitt 10.2.1 das Ergebnis "http://test.at/Euro.html".
SELECT DOCS.URL
FROM WORDDOC, WORDS, DOCS
WHERE DOCS.ID=WORDDOC.DOCID AND WORDS.ID=WORDDOC.WORDID
AND WORDS.WORD="euro"
Listing 10.4: SELECT-Statement für eine Suchabfrage mit einem Wort
Direkt nach dem SELECT wird angegeben, welche Attribute der Tabelle zurückgeliefert
werden soll. In diesem Beispiel ist es die URL des gefundenen Dokuments. Das SQLSchlüsselwort FROM wird gefolgt von den Namen der Tabellen, die miteinander verknüpft
werden sollen. Die WHERE-Klausel legt fest, daß die Identifikationsnummer der
Dokumenttabelle gleich der Dokumentenidentifikationsnummer in der Wort-DokumentTabelle sein muß. Das gleiche gilt für die Wortidentifikationsnummer. Schließlich wird
festgelegt, welches Wort gesucht wird (hier "euro").
Werden Platzhalter verwendet wie '*' oder '%' (Platzhalter für beliebige Zeichenfolgen)
und '?' oder '_' (Platzhalter für einzelnes Zeichen), so muß in SQL statt des '='-Operators
der LIKE-Operator verwendet werden (siehe Listing 10.5).
... AND WORDS.WORD LIKE "eur%"
Listing 10.5: Verwendung des LIKE-Operators
10.4.2 Boolesche Operatoren
In diesem Abschnitt werden die Abfragen beschrieben, die bei Verwendung mehrerer
Suchwörter, die mit booleschen Operatoren verknüpft sind, verwendet werden können.
Verknüpfung mit ODER
Um Dokumente zu finden, in denen ein bestimmtes Wort ODER ein anderes Wort
vorkommt, erweitert man einfach die Abfrage, wie in Listing 10.6 gezeigt, um die
gewünschten Wörter.
SELECT DOCS.URL
FROM WORDDOC, WORDS, DOCS
WHERE DOCS.ID=WORDDOC.DOCID AND WORDS.ID=WORDDOC.WORDID
AND (WORDS.WORD="euro" OR WORDS.WORD="haus")
Listing 10.6: SELECT-Statement bei mehreren mit ODER verknüpften Wörtern
So können beliebig viele Wörter mit ODER verknüpft werden, ohne mehrfache
Abfragen starten zu müssen. Für kompliziertere Abfragen gibt es in manchen SQLBackends auch die Möglichkeit, Mengenoperatoren einzusetzen. Um wieder möglichst
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
142
universell einsetzbar zu sein, wurde in der vorliegenden Arbeit auf INTERSECT bzw.
UNION verzichtet. Listing 10.7 zeigt die Abfrage aus Listing 10.6 bei Verwendung von
UNION.
SELECT DOCS.URL
FROM WORDDOC, WORDS, DOCS
WHERE DOCS.ID=WORDDOC.DOCID AND WORDS.ID=WORDDOC.WORDID
AND WORDS.WORD="euro"
UNION
SELECT DOCS.URL
FROM WORDDOC, WORDS, DOCS
WHERE DOCS.ID=WORDDOC.DOCID AND WORDS.ID=WORDDOC.WORDID
AND WORDS.WORD="haus"
Listing 10.7: SELECT-Statement mit UNION-Operator statt ODER
Verknüpfung mit UND
Ohne die Verwendung von Mengenoperatoren ist die Abfrage von Informationen, die
mehrere Bedingungen haben, welche sich auf das gleiche Attribut beziehen, nicht mehr
möglich. Eine Abfrage mit (WORDS.WORD="euro" AND WORDS.WORD="haus")
würde sich selbst ausschließen. In der vorliegenden Arbeit wurden daher für UND bzw.
UND NICHT jeweils eigene Abfragen an die Datenbank erstellt und die Ergebnisse
verknüpft. Die Abfrage mit Mengenoperatoren ist in Listing 10.8 zu sehen, wobei der
Durchschnitt zweier Mengen ermittelt wird.
SELECT DOCS.URL
FROM WORDDOC, WORDS, DOCS
WHERE DOCS.ID=WORDDOC.DOCID AND WORDS.ID=WORDDOC.WORDID
AND WORDS.WORD="euro"
INTERSECT
SELECT DOCS.URL
FROM WORDDOC, WORDS, DOCS
WHERE DOCS.ID=WORDDOC.DOCID AND WORDS.ID=WORDDOC.WORDID
AND WORDS.WORD="haus"
Listing 10.8: SELECT-Statement mit INTERSECT-Operator statt UND
Verknüpfung mit UND NICHT
Hier gibt es die Möglichkeit, Wörter mit einem sogenannten SUB-SELECT auszuschließen (siehe Listing 10.9). Doch auch hier besteht die Einschränkung, daß SUBSELECTs nicht allgemein implementiert sind. Deshalb wurde auch hier auf möglichst
einfache Implementierung Wert gelegt und die logische Verknüpfung selber durchgeführt.
SELECT DOCS.URL
FROM WORDDOC, WORDS, DOCS
WHERE DOCS.ID=WORDDOC.DOCID AND WORDS.ID=WORDDOC.WORDID
AND WORDS.WORD="euro"
AND DOCS.ID NOT IN
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
143
(SELECT ID FROM WORDS, WORDS WHERE WORDDOC.WORDID=WORDS.ID AND
WORD="haus")
Listing 10.9: SELECT-Statement mit SUB-SELECT statt UND NICHT
10.4.3 Eingeschränkte Suche
Die Suche kann zusätzlich noch auf einzelne Attribute beschränkt werden. Die
Implementierung einer Abfrage zur Beurteilung der Relevanz einzelner Wörter wird in
diesem Abschnitt ebenfalls erläutert.
Einschränkung auf Attribute
Durch eine zusätzliche Bedingung in der WHERE-Klausel läßt sich die Suche von
Wörtern in Dokumenten auf bestimmte Attribute einschränken. In folgendem Beispiel muß
der Suchbegriff "euro" im Titel vorkommen. Der Attribut-Zähler Title in der Tabelle
WordDoc gibt an, wie oft der Begriff in einem Dokument im Titel vorkommt und muß
daher größer gleich eins sein (Listing 10.10).
SELECT DOCS.URL
FROM WORDDOC, WORDS, DOCS
WHERE DOCS.ID=WORDDOC.DOCID AND WORDS.ID=WORDDOC.WORDID
AND WORDS.WORD="euro" AND WORDS.TITLE > 0
Listing 10.10: Einschränkung der Suche auf bestimmte Attribute
Beachtung der Relevanz einzelner Wörter
In der Worttabelle wird unter anderem die Anzahl der Dokumente mitgeführt, die das
jeweilige Wort in einem Attribut wie Body (Volltext) oder Schlüsselwort enthalten. Mit
Hilfe dieses Eintrages läßt sich ein Relevanzfilter realisieren. So kann festgelegt werden, in
wie vielen Dokumenten ein bestimmtes Wort höchstens vorkommen darf, damit es noch
eine gewisse Aussagekraft hat. Da es nicht Sinn macht, eine fixe Anzahl an Dokumenten
anzugeben, muß vorher die aktuelle Anzahl an Dokumenten in der Datenbank ermittelt
werden. Das kann mit dem in Listing 10.11 gezeigten Statement erfolgen.
SELECT COUNT(ID) FROM DOCS
Listing 10.11: Ermittlung der Anzahl Dokumente in der Datenbank
Ein Beispiel verdeutlicht die Einschränkung. Wählt man als Relevanzgrenze beispielsweise 50% und sind in der Datenbank 4000 Dokumente enthalten, dann ist es nicht
sinnvoll, etwa nach "euro" als Schlüsselwort zu suchen, wenn mehr als 2000 Dokumente
dieses Wort als Schlüsselbegriff haben. Die Anzahl der Dokumente, die "euro" als
Schlüsselwort haben, kann man mit der Abfrage aus Listing 10.12 ermitteln. Ist das
Ergebnis größer als 2000, dann sollte der Begriff von der Suche ausgeschlossen werden.
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
144
SELECT KEYWORDS FROM WORDS WHERE WORD="euro"
Listing 10.12: Ermittlung der Anzahl Dokumente die ein Wort als Schlüsselwort haben
Listing 10.13 zeigt ein Beispiel, wie sich alle relevanten Schlüsselwörter eines
bestimmten Dokuments ermitteln lassen. Als Relevanzkriterium gelten wieder die gerade
getroffenen Annahmen.
SELECT WORD
FROM WORDDOC, WORDS, DOCS
WHERE DOCS.ID=WORDDOC.DOCID AND WORDS.ID=WORDDOC.WORDID
AND URL="http://test.at/Euro.html" AND WORDS.KEYWORDS < 2000
Listing 10.13: Ermittlung aller relevanten Schlüsselwörter eines Dokumentes
Stoppwörter
Die Datenbank bietet auch die Möglichkeit, Stoppwörter zu definieren. Diese werden
einfach in der Konfigurationsdatei der Datenbank aufgeführt. Das Modul Datenbank stellt
Funktionen zur Verfügung, mit denen sich feststellen läßt, ob ein Begriff in dieser Liste
vorkommt. Stoppwörter können unerwünschte Wörter oder Pronomen bzw. Füllwörter
sein, die auf die Suche wenig Einfluß haben. Die Stoppwörter können auch im Nachhinein
geändert werden. Das Programm, das eine Suche in der Datenbank ausführt, also
beispielsweise ein Suchservlet (siehe Kapitel 9 – Der Suchdienst), sollte vorher prüfen, ob
ein Suchbegriff von der Suche ausgeschlossen werden soll oder nicht und erst dann die
SQL-Abfragen durchführen.
10.4.4 Gewichtung gefundener Dokumente
Da in der Wort-Dokument-Tabelle festgehalten wird, wie oft ein einzelnes Wort getrennt
nach Attributen vorkommt, kann ermittelt werden, wie interessant das Dokument für den
Benutzer ist. Je öfter ein Suchbegriff vorkommt, desto wahrscheinlicher ist es, daß das
Dokument Inhalte zum gewünschten Thema liefern kann. Dabei gibt es die Möglichkeit,
Wörter in verschiedenen Positionen in den Dokumenten unterschiedlich zu gewichten. Der
Sinn der Gewichtung besteht darin, daß Wörter in Überschriften mit großer Wahrscheinlichkeit relevanter den Inhalt des Dokuments beschreiben als Wörter an beliebiger Stelle in
den Absätzen. In der Rating-Sektion der Konfigurationsdatei (siehe Listing 10.14) wird das
Gewicht der einzelnen Wörter spezifiziert.
# Attribute
[Rating]
Body
Title
Headings
Keywords
Rating
MaxCount
1
3
3
4
3
6
6
Listing 10.14: Rating-Sektion der Konfigurationsdatei der Datenbank
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
145
In diesem Beispiel zählt ein Schlüsselwort viermal mehr als ein Wort, daß irgendwo im
Text vorkommt. Auch Titel und Überschriften sind extra gewichtet. Mit einem Beispiel
wird klarer, wie das Gewicht eines Dokuments bestimmt wird. Abbildung 10.1 zeigt ein
HTML-Dokument. Der Dokumententitel läßt sich aus dem Fenstertitel ablesen.
Überschriften sind größer als der übrige Text, Schlüsselwörter (Keywords) sind fett
ausgegeben gedruckt. Mit der Gewichtung, wie in Listing 10.14 angegeben, erhält das in
Abbildung 10.1 gezeigte Dokument bei einer Suche nach dem Begriff "Ermaechtigungsgesetz" im Volltext den Wert 2, da das Wort zweimal vorkommt (Zum Volltext gehören
ebenfalls die Überschriften, das Gewicht für ein Wort ist 1).
Abbildung 10.1: Beispieldokument zur Gewichtung von Dokumenten
Eine Suche nach "ENFOPOL" im Volltext liefert ebenfalls 2 (Gewichtung für Wörter im
Body bzw. Volltext ist 1); wird hingegen etwa in den Schlüsselwörtern und im Volltext
gesucht, addieren sich die vorkommenden Werte. Ein Beispiel demonstriert das.
"ENFOPOL" zählt als Schlüsselwort die Wertigkeit 4, was zusammen mit dem schon
berechneten Gewicht 2 für das Wort im Volltext das Dokumentengesamtgewicht 6 ergibt.
Werden zur Suche mehrere Wörter herangezogen (egal, ob mit AND bzw. OR verknüpft) zählt ebenfalls die Summe der Wertungen der einzelnen Wörter. Eine Suche in
Titel, Überschriften, Volltext und Schlüsselwörtern nach "Ermaechtigungsgesetz AND
ENFOPOL" ergibt den in Tabelle 10.9 ermittelten Wert.
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
146
Suchwort
Titel
Überschrift
Schlüsselwort
Volltext
Wertung
Ermaechtigungsgesetz
1*4
1*3
0
2*1
9
ENFOPOL
0
0
1*3
2*1
5
Gesamt
14
Tabelle 10.9: Beispiel einer Dokumentenbewertung bei der Suche
Ein Problem bei der Bewertung von Dokumenten ist das sogenannte Keyword Spamming. Durch mehrmaliges Wiederholen von Wörtern, nach denen in den Suchmaschinen
am häufigsten gesucht wird, läßt sich ein bestimmtes Dokument sehr hoch reihen, ohne
daß das Dokument irgend etwas mit dem Suchbegriff zu tun haben muß. Dadurch können
etwa Seiten von Erotik-Anbietern ganz oben in den Suchergebnissen häufig verwendeter
medizinischer Begriffe erscheinen. Um das Keyword Spamming zu unterbinden oder
zumindest einzuschränken, kann man in der Konfigurationsdatei die Anzahl, wie oft ein
bestimmtes Wort maximal gewertet wird, begrenzen. Die Begrenzung gibt man in der
selben Sektion wie die Gewichtung an. Läßt man die zweite Zahl weg, so gibt es keine
Obergrenze. Im Fall der oben gezeigten Attributangaben bedeutet das, daß ein bestimmtes
Wort im Titel nur maximal drei mal gezählt wird. Ein im Titel gefundenes Wort kann also
höchstens das Gewicht neun (Anzahl drei mal Rating 3) zum Dokument beitragen. In den
Keywords kann ein vorkommendes Wort höchstens mit dem Wert 4*6=24 zur Gesamtbewertung beitragen.
10.5 Erweiterung der Datenbank um neue
Attribute
Die Datenbank ist flexibel programmiert, so daß in der Rating-Sektion (siehe Abschnitt
10.6.3 bzw. 10.4.4) einfach Attribute hinzugefügt werden können ohne das Programm zu
ändern. Dabei ist aber zu beachten, daß die komplette Datenbank gelöscht und neu
initialisiert werden muß und alle schon indizierten Daten verloren gehen. Da die
Datenbank automatisch erzeugt wird, genügt es, sie mit dem in Listing 10.15 gezeigten
Kommando zu löschen.
java –Duser.timezone=ECT DB destroy [-StandardLog Name]
[-ErrorLog Name]
Listing 10.15: Kommando zum Löschen der Datenbank
Nach einer Sicherheitsabfrage werden alle Daten gelöscht und beim nächsten Start des
Gatherers neu mit den erweiterten Attributen angelegt. In der Konfigurationsdatei muß
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
147
zuvor in der Sektion Rating ein neues Attribut angegeben bzw. die vorhandenen geändert
werden. Listing 10.16 zeigt eine mit dem Attribut Applets erweiterte Rating-Sektion.
# Attribute
[Rating]
Body
Title
Headings
Keywords
Applets
Rating
MaxCount
1
3
3
4
1
3
6
6
1
Listing 10.16: Erweiterung der Rating-Sektion der Datenbankkonfigurationsdatei
Alle Programmteile, wie das Suchservlet (siehe Kapitel 9) bzw. die Funktionen zum
Ermitteln der Anzahl der Wörter in den einzelnen Attributen, passen sich an die neue
Konfiguration an und es müssen keine Änderungen am Programmcode vorgenommen
werden.
10.6 Konfiguration der Datenbank
In diesem Kapitel wird die Konfiguration der Datenbank genauer beschrieben. Die erste
Sektion, Config, gibt die relationale Datenbank an, die verwendet werden soll und
beschreibt außerdem einige Datenbank-spezifische Parameter. In der Sektion WordFilter
können Filter angegeben werden, die verhindern, daß unerwünschte Wörter in die
Datenbank aufgenommen werden. Die Sektion Rating definiert die Gewichtung einzelner
Wörter für Suchabfragen und StopWords listet alle Wörter, die bei der Suche ignoriert
werden sollen. Auch beim implementierten Suchservlet genügt es, das Suchformular
minimal zu Ändern um eine Suche zu ermöglichen.
10.6.1 Sektion Config
Damit die Software möglichst universell einsetzbar ist und trotz der Unterschiede mit
verschiedenen Datenbanken zusammenarbeiten kann, ist die Angabe folgender Parameter
nötig:
Driver
In Java benötigt man zwei Angaben, um die Datenbank zu spezifizieren, die verwendet
werden soll. Die erste ist der Name des JDBC-Treibers (in der Konfigurationsdatei hat der
Parameter die Bezeichnung Driver). Im JDK von Sun für Windows ist ein Treiber für
ODBC inkludiert, über den der Zugriff auf alle ODBC-Datenbanken möglich ist
(sun.jdbc.odbc.JdbcOdbcDriver). Bei anderen Datenbanken wird heute meist ein JDBCTreiber mitgeliefert, um von Java aus auf die Datenbank zugreifen zu können.
URL, User und Password
Der zweite Parameter spezifiziert den Namen der Datenbank, da über einen bestimmten
Datenbanktreiber auch mehrere Datenbanken angesprochen werden können (z.B.
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
148
jdbc:odbc:JarvesterDB). Dieser Parameter wird in Java URL genannt. Die Form der URL
ist der Beschreibung der jeweiligen Datenbanksoftware zu entnehmen. Bei manchen
Implementierungen muß ebenfalls die User-Kennung und ein Paßwort angeben werden.
Quote und Escape
Wenn in SQL in eine Datenbank Text eingefügt werden soll bzw. nach bestimmtem Text
gesucht wird, dann muß dieser Text in Anführungszeichen stehen. Das verwendete
Zeichen ist aber von Datenbank zu Datenbank verschieden. Der Parameter Quote definiert
dieses Anführungszeichen. Es kann sein, daß in die Datenbank Wörter übernommen
werden sollen, die Sonderzeichen enthalten. Wenn das Sonderzeichen gleich dem
Anführungszeichen ist, gibt es Probleme. Aus diesem Grund wird davor ein spezielles
Escapezeichen eingefügt. Das Escapezeichen wird mit dem Parameter Escape in der
Konfigurationsdatei festgelegt.
NumName, NumMin und NumMax
Für die Identifikationsnummern der Wörter und Dokumente ist bei der Erstellung der
Datenbank die Angabe eines Datentyps nötig, wobei zumindest ein vier Byte großes
Integer verlangt wird. Jede Datenbank hat einen anderen Namen für diesen Datentyp,
darum wird der Datentyp mit dem Parameter NumName angegeben. Da auch längere
Zahlen möglich sind oder Zahlen ohne Vorzeichen gibt man mit NumMin und NumMax
das Minimum und Maximum des zu verwendenden Zahlenbereiches an.
DataDir
Die indizierten und analysierten Dokumente werden in einem eigenen Format in einem
Verzeichnis abgespeichert. Dieses Format kann einfach in SOIF oder XML umgewandelt
werden. Das Verzeichnis wird mit dem Parameter DataDir angegeben, wobei darauf zu
achten ist, daß unter Linux Java Version 1.1.7A die Verwendung von "~" als Verweis auf
das Home-Directory nicht funktioniert. Statt dessen wird im aktuellen Verzeichnis ein
neues Verzeichnis mit dem Namen "~" angelegt.
Listing 10.17 gibt ein Beispiel für den Zugriff auf eine MS Jet 3.5 Datenbank (Access)
über ODBJ.
#
#
#
#
Database Configuration File
Database driver name, URL, user, password, SQL quote character
and SQL escape character for quote inside quote. NumName is name
of number in SQL database.
[Config]
# Config for ODBC-Database
Driver
sun.jdbc.odbc.JdbcOdbcDriver
URL
jdbc:odbc:JarvesterDB
User
Jarvest
Password Jarvest
# Definitions for database characteristics
Quote
'
Escape
'
# This datatype should be at least 4 byte signed int
# (Minimum -2147483648, Maximum 2147483647)
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
NumName
NumMin
NumMax
DataDir
149
LONG
-2147483647
2147483647
d:/jarvest/data
Listing 10.17: Beispiel der Config-Sektion der Konfigurationsdatei für ODBC
Nötige Angaben für PostgreSQL und InstantDB (einer in Java programmierten
relationalen Datenbank) zeigt Listing 10.18.
# Config for PostgreSQL
Driver
postgresql.Driver
URL
jdbc:postgresql:JarvesterDB
User
knoegler
Password jarvest
Quote
'
Escape
'
NumName
int
NumMin
0
NumMax
2147483647
DataDir
/home/knoegler/data
# Config for InstantDB
Driver
jdbc.idbDriver
URL
jdbc:idb:DataBase.prp
NumName
LONG
Quote
"
Escape
\
User
Test
Password Test
NumMin
0
NumMax
2147483647
DataDir
/home/knoegler/data
Listing 10.18: Beispiel der Config-Sektion für PostgreSQL und InstantDB
Title, Summary und Keywords
Die Namen der vom HTML-Konverter extrahierten Attribute sind nicht festgelegt.
Module, wie der Suchdienst (siehe Kapitel 9), benötigen die Namen bestimmter Attribute
wie etwa der Kurzfassung eines Dokuments. Eine Anwendung dieser Übersetzungstabelle
bei Vorhandensein mehrerer Schlüsselwortattribute zeigt Abschnitt 9.2. Listing 10.19 gibt
ein Beispiel für die Zuordnung der Parameter Title, Summary und Keywords zu den
entsprechenden vom HTML-Konverter extrahierten Daten.
# Attributes for SearchServlet
Title
Title
Summary
Abstract
Keywords Keywords
Listing 10.19: Attribute der Datenbankkonfigurationsdatei für Suchprogramme
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
150
10.6.2 WordFilter
Es ist nicht sinnvoll, alle Wörter in die Datenbank aufzunehmen, da darunter die
Performance leidet und Begriffe für die Suche möglicherweise nicht relevant sind.
Implementiert sind Filter, die zu kurze (z.B. nur aus einem oder zwei Buchstaben
bestehend) oder zu lange Wörter von vornherein ausschließen. Die dazugehörigen Filter
heißen DelSmall und DelLong, wobei DelSmall(3) alle Wörter ausschließt, die drei oder
weniger Buchstaben haben. DelLong(25) ignoriert alle Wörter, die 25 oder mehr
Buchstaben haben. Als ein weiterer wichtiger Filter ist LowerCase zu nennen, damit in der
Datenbank nicht unnötig verschiedene Schreibweisen eines Wortes vorkommen (etwa
'gestern' und 'Gestern'). Das hat zur Folge, daß natürlich kein Unterschied zwischen Großund Kleinschreibung gemacht wird und so bei der Suche auch nicht danach unterschieden
wird. Ein Beispiel der Sektion zeigt Listing 10.20.
Hier bieten sich auch Ansätze für Erweiterungsmöglichkeiten, da leicht ein Synonymfilter oder Filter, die Wörter auf ihren Wortstamm reduzieren eingebaut werden können. So
können etwa Wörter wie "Rind", "Kuh", "Rinder", "Rindvieh", "Kühe" etc. alle auf einen
einzigen Begriff reduziert werden. Das hat unter anderem den Vorteil, daß wenn der
Benutzer nach einem bestimmten Dokument sucht, aber in diesem nur Synonyme seines
Suchbegriffes vorkommen, das Dokument trotzdem gefunden wird.
# Each word which will be indexed by the database is passed
# through the following filters. Available filters are:
# LowerCase ... convert all words to lowercase.
# DeleteNumbers numbers are ignored.
# DelSmall(x) . all words smaller or equal x characters are
#
ignored.
# DelLong(x) .. all words larger or equal x characters are ignored.
[WordFilter]
LowerCase
DelSmall(2)
DelLong(25)
Listing 10.20: Beispiel der WordFilter-Sektion der Datenbankkonfigurationsdatei
10.6.3 Rating
Die genaue Bedeutung der Werte dieser Sektion wird im Abschnitt 10.4.4 – Gewichtung
gefundener Dokumente erklärt. Listing 10.21 zeigt ein Beispiel dieser Sektion.
# Rating value is additive. If word occurs in heading
# and body it will be rated in body and heading.
# Attribute Rating MaxCount
[Rating]
Body
1
Title
3
3
Headings
3
6
Keywords
4
5
Listing 10.21: Beispiel der Rating-Sektion der Datenbankkonfigurationsdatei
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
151
10.6.4 Stoppwörter
Oft ist es nicht notwendig, oder soll unterbunden werden, nach bestimmten einzelnen
Wörtern suchen zu können. Anbieter des Suchdienstes können sich kurzzeitig dafür
entscheiden, bestimmte Wörter aus der Suche auszuschließen. Dazu bietet die Datenbank
die Möglichkeit, Stoppwörter zu definieren. Diese werden einfach in der Konfigurationsdatei aufgeführt. Das Modul Datenbank stellt Funktionen zur Verfügung, mit denen sich
feststellen läßt, ob ein Begriff in dieser Liste vorkommt. So kann ein Suchprogramm leicht
prüfen, ob ein Begriff ignoriert werden soll (siehe Listing 10.22).
# The following list contains words which should be ignored
# during search. These words do not influence indexing. So
# changes can be done after indexing without the need to
# reindex all the documents.
# Sometimes it is necessary to exclude special words. These
# stop words are for example four letter words or similar.
# Stop words are not case sensitive.
[StopWords]
Sodom
Gomorrha
Listing 10.22: Beispiel der StopWords-Sektion der Datenbankkonfigurationsdatei
Das Problem ist, daß solche Listen immer nur für eine bestimmte Sprache verwendet
werden können. Listing 10.23 zeigt eine Stoppwortliste für den englischsprachigen Raum.
a about above across adj after again against all almost alone along
also although always am among an and another any anybody anyone
anything anywhere apart are around as aside at away be because been
before behind being below besides between beyond both but by can
cannot could deep did do does doing done down downwards during each
either else enough etc even ever every everybody everyone except
far few for forth from get gets got had hardly has have having her
here herself him himself his how however i if in indeed instead
into inward is it its itself just kept many maybe might mine more
most mostly much must myself near neither next no nobody none nor
not nothing nowhere of off often on only onto or other others ought
our ours out outside over own p per please plus pp quite rather
really said seem self selves several shall she should since so some
somebody somewhat still such than that the their theirs them
themselves then there therefore these they this thorough thoroughly
those through thus to together too toward towards under until up
upon v very was well were what whatever when whenever where whether
which while who whom whose will with within without would yet young
your yourself
Listing 10.23: Stoppwortliste für den englischsprachigen Raum
Stoppwörter haben keinen Einfluß auf die Indizierung der Dokumente. Sie können daher
im Nachhinein geändert werden. Das Programm, das die Suche ausführt, sollte vorher
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
152
prüfen, ob ein Suchbegriff von der Suche ausgeschlossen werden soll oder nicht und erst
dann die SQL-Abfragen durchführen. Stoppwörter sind nicht case-sensitive.
10.6.5 Vollständige Konfigurationsdatei
In Listing 10.24 ist eine vollständige Konfigurationsdatei der Datenbank aufgelistet.
# Database Configuration File
# Database driver name, URL, user, password, SQL quote
# character and SQL escape character for quote inside quote.
# NumName is name of number in SQL database.
[Config]
# Config for PostgreSQL
Driver
postgresql.Driver
URL
jdbc:postgresql:JarvesterDB
User
knoegler
Password jarvest
# Definitions for database characteristics
Quote
'
Escape
'
# This datatype should be at least 4 byte signed int
# (Minimum -2147483647, Maximum 2147483647)
# Some Databases have problems using –2147483648 as minimum.
NumName
int
NumMin
0
NumMax
2147483647
DataDir
/home/knoegler/data
# Attributes for SearchServlet
Title
Title
Summary
Abstract
Keywords Keywords
# Each word which will be indexed by the database is passed
# through the following filters.
# Available filters:
# LowerCase ...... convert all words to lowercase.
# DeleteNumbers .. numbers are ignored.
# DelSmall(x) .... all words smaller or equal x characters are
#
ignored.
# DelLong(x) ..... all words larger or equal x characters are
#
ignored.
[WordFilter]
LowerCase
DelSmall(2)
DelLong(25)
# Rating value is additive. If word occurs in heading
# and body it will be rated in body and heading.
#
# Attribute Rating MaxCount
[Rating]
Body
1
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
Title
Headings
Keywords
3
3
4
153
3
6
5
# The following list contains words which should be ignored
# during searching. These words do not influence indexing. So
# changes can be done after indexing without the need to
# reindex all the documents. Sometimes it is necessary to
# exclude special words. These stop words are for
# example four letter words or similar. Stop words are not
# case sensitive.
[StopWords]
Sodom
Gomorrha
Listing 10.24: Beispiel einer vollständigen Datenbankkonfigurationsdatei
10.7 Implementierung
Alle nötigen Relationen werden beim Initialisieren des Datenbankmoduls automatisch
erstellt, sobald die Initialisierungsfunktion aufgerufen wird. Auch Indizes für schnelleren
Datenbankzugriff werden erstellt. Dabei wird berücksichtigt, welche Attribute der
analysierten Dokumente (beispielsweise Überschriften oder Schlüsselwörter) indiziert
werden sollen. Die Attribute werden dabei aus der Rating-Sektion der Datenbankkonfigurationsdatei übernommen.
Wichtig ist auch die Verwendung des Konzeptes der SQL-Transaktion, welche es
ermöglicht, daß komplexe, zusammengesetzte Datenbankmanipulationen entweder als
Ganzes oder gar nicht durchgeführt werden. Wird zum Beispiel ein Dokument entfernt,
müssen auch alle Wort-Dokument-Beziehungen gelöscht werden. Tritt während dieser
Operationen ein Fehler auf, wird vom Datenbanksystem auf Wunsch der alte Zustand vor
Beginn der Transaktion wieder hergestellt. Erst nachdem alle Transaktionen fehlerlos
verlaufen sind, gibt man das Kommando, die Transaktionen auch wirklich in die
Datenbank zu übernehmen. Mit Hilfe des Transaktionskonzeptes werden zusammengesetzte Operationen somit "atomar". Alle Funktionen dieser Projektarbeit benützen, sofern
sinnvoll, Transaktionen.
Die Namen der Tabellen und einzelnen Datentypen sind am Anfang des Moduls
definiert und können einfach geändert werden. Im folgenden werden einige Funktionen des
Datenbankmoduls beschrieben.
init()
Initialisieren der Datenbank. Init muß vor Aufruf der anderen Funktionen ausgeführt
werden. Dabei wird die Konfigurationsdatei eingelesen und ausgewertet. Zuerst wird
geprüft, ob die Relationen schon existieren und wenn nicht, werden diese neu angelegt.
Zusätzlich werden zur Optimierung des Datenbankzugriffes Indizes angelegt. Die
Verbindung zur Datenbank wird aufgebaut.
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
154
boolean putAVTable(String url, AVTable AVTab, int choice, Gatherer g, boolean
doIndex)
Diese Funktion fügt ein zu einer bestimmten URL gehörendes AVTable-Objekt in die
Datenbank ein. Dieses Objekt besteht aus einer Anzahl Attribut-Wert-Paaren, wie etwa
Schlüsselwörter oder Volltext. Mit dem Parameter doIndex kann bei Dokumenten
angegeben werden, ob einzelne Wörter in der Datenbank indiziert werden sollen. Der
Gatherer muß eine Funktion namens continueGathering() zur Verfügung stellen, die
true oder false liefert, je nachdem, ob der Vorgang abgebrochen werden soll oder nicht.
Das ist nötig, da der Indiziervorgang längere Zeit in Anspruch nehmen kann, das
Hauptprogramm aber beendet werden soll.
long getNumberOfDocsContainingWord(Statement stmt, String word, String attr)
Diese Funktion gibt die Anzahl Dokumente zurück, in denen ein bestimmtes Wort in
einem bestimmten Attribut vorkommt. Sie dient dazu, festzustellen, ob ein Wort relevant
ist, oder in zu vielen Dokumenten vorkommt. Suchprogramme können so ermitteln, ob es
sinnvoll ist, einen Suchbegriff zuzulassen oder nicht.
String getObjectMD5(String url, int choice) throws SQLException
Die MD5-Checksumme einer bestimmten Objekts wird zurückgegeben. Dabei kann mit
dem Parameter choice gewählt werden, ob auf Dokumente (DOC) oder Informationsdateien (INFO) zugegriffen werden soll. Diese Funktion kann dazu verwendet werden,
Dokumente auf Änderungen zu prüfen, wenn das Datum der letzten Modifikation nicht
ermittelbar ist.
long getObjectUpdateTime(String url, int choice) throws SQLException
Diese Funktion gibt die Zeit des letzten Updates eines Dokuments bzw. einer Informationsdatei zurück. Ein Dokument sollte neu in die Datenbank aufgenommen werden, wenn
das Datum der letzten Änderung neuer ist als die letzte Update-Time. Mit dem Parameter
choice kann gewählt werden, ob auf Dokumente (DOC) oder Informationsdateien (INFO)
zugegriffen werden soll.
boolean updateObject(String url, int choice)
Die Update-Time eines Objektes in der Datenbank wird aktualisiert und auf die aktuelle
Systemzeit gesetzt.
void deleteExpiredObjects(long time, int choice, Gatherer g, boolean delIndex)
Löscht alle Objekte aus der Datenbank, deren Update-Time + Time-To-Live kleiner als die
aktuelle Systemzeit ist. So können Dokumente, die seit längerer Zeit nicht mehr erreichbar
sind, aus der Datenbank entfernt werden.
AVTable getAVTable(long id, int choice) throws IOException
Wenn die datenbankinterne Dokumentenidentifikationsnummer bekannt ist, kann mit
dieser Funktion das entsprechende Dokument aus der Datenbank geholt werden.
AVTable getAVTable(String url, int choice)
Das Dokument bzw. die Informationsdatei mit der angegebenen URL wird zurückgeliefert,
bzw. null, wenn es nicht existiert.
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
155
String getObjectURL(long objID, int choice)
Diese Funktion liefert zu einer Identifikationsnummer die entsprechende URL zurück oder
null, wenn das Objekt nicht existiert.
Connection getConnection()
Die verwendete Verbindung zur Datenbank wird zurückgegeben.
long getNumberOfDocs()
Ermittlung der Gesamtanzahl der in der Datenbank vorhandenen Dokumente.
long getNumberOfDocs(Statement stmt)
Ermittlung der Gesamtanzahl der in der Datenbank vorhandenen Dokumente, wenn ein
eigenes Statement verwendet werden soll.
long getNumberOfWords(Statement stmt)
Ermittlung der Gesamtanzahl der in der Datenbank vorhandenen Wörter.
String initDataBaseParams(String path)
Initialisieren der Datenbank und auslesen der Datenbankkonfigurationsdatei. Hier werden
keine Ausgaben in Log-Dateien gemacht, sondern nur ein Fehlerstring zurückgegeben,
damit diese Funktion auch von Servlets verwendet werden kann.
finalizeDB()
Diese Funktion beendet die Verbindung zur Datenbank und sollte am Ende des
Programmes aufgerufen werden.
main(String args[])
Diese Funktion bietet ein einfaches Kommandozeileninterface, um SQL-Abfragen und
SQL-Kommandos eingeben zu können.
KAPITEL 10 - DATENBANK – ANBINDUNG UND AUFBAU
156
10.8 Zusammenfassung
In diesem Kapitel wurde erläutert, wie die vom Gatherer (siehe Kapitel 6) gesammelten
Dokumente und Informationsdateien verwaltet werden. Zusätzlich wurde auf die
Vorgehensweise bei der Indizierung aller in den Dokumenten vorkommenden Wörter
genauer eingegangen. Die Indizierung ermöglicht Suchabfragen, um von einzelnen
Wörtern auf Dokumente schließen zu können, in denen diese Wörter vorkommen.
Die einzelnen Objekte, also Dokumente, Informationsdateien und Wörter werden ebenso
wie die Beziehungen dieser Objekte untereinander in jeweils einer Relation verwaltet.
Zusätzlich werden Eigenschaften der Objekte mitgeführt, die es erlauben, die Anzahl der
Dokumente zu ermitteln, in denen ein bestimmtes Wort in einem Attribut wie etwa Titel
oder Überschrift vorkommt. Auch wird mitgeführt, wie oft ein Wort in einem bestimmten
Dokument vorkommt. Der Index ermöglicht es ebenfalls, aufgrund der in den einzelnen
Relationen mitgeführten Daten relevante Schlüsselwörter zu filtern und Dokumente
entsprechend ihrer Wichtigkeit im Suchergebnis zu reihen.
Im nächsten Kapitel werden die übrigen Module des Programmes, wie etwa eine Klasse
zum Auslesen von Konfigurationsdateien oder ein Modul zum Erzeugen von Protokolldateien, näher erklärt und kurz auf deren wichtigste Funktionen eingegangen.
Kapitel 11
Zusätzliche Module
Im Rahmen der vorliegenden Arbeit wurde die Entwicklung von zusätzlichen Klassen
notwendig. Unter anderem wurden eine Klasse zum Auslesen von Konfigurationsdateien,
verschiedene Methoden zur Filterung von Strings und ein erweiterter String-Tokenizer
implementiert. Die Module werden im folgenden genauer beschrieben und Konfiguration
und Programmierschnittstellen kurz erläutert.
11.1 ConfigReader
Diese Klasse dient zum kontrollierten Auslesen von Konfigurationsdateien. Die
Konfigurationsdateien können durch die Zeichenfolge "[Sektionsname]" in einzelne
Sektionen unterteilt werden, wobei die Möglichkeit besteht, diese einzeln auszulesen.
Kommentarzeilen sind durch das Zeichen "#" gekennzeichnet und werden beim Auslesen
ignoriert. Listing 11.1 zeigt eine Konfigurationsdatei mit Kommentaren und verschiedenen
Sektionen.
# Configuration HTMLParser
# 1998 - Bernhard Knoegler
#
# Convert-Table
# This table defines which HTML-Tag contents will be added to
# attributes. Attributes are case sensitive. Tags are not.
# Attributes not specified here will be ignored.
#
# Source-Tag
Destination-Attribute
#-------------------------------------[ConvertTab]
NoTag
Body
HTML
Body
Head
Body
H1
Headings, Parent
Applet:Code
Applets
# The Add-section is used to describe how text is appended to
KAPITEL 11 - ZUSÄTZLICHE MODULE
158
# destination-attributes during converting. Multiple
# attributes must be separated by commas. A special tag is
# Default. It is used for all tags not mentioned in this
# section.
#------------------------------------------------------------[Add]
Default
AddLine
Body
AddGroup
Keywords, ExtraKeywords
AddWords
Meta:Keywords
AddWords
Listing 11.1: Beispiel einer Konfigurationsdatei
11.1.1 Implementierung
Folgende Methoden stehen zum Auslesen der Konfigurationsdateien zur Verfügung:
ConfigReader(String Filename)
Dem Objekt wird mit dem Konstruktor der Name der Konfigurationsdatei übergeben.
Kann die Datei nicht zum Lesen geöffnet werden, wird eine IOException ausgelöst. Nach
der Initialisierung ist keine spezielle Sektion ausgewählt und es können alle Zeilen
ausgelesen werden.
boolean setSection(String Sektionsname)
Das Auslesen der Zeilen kann auf eine bestimmte Sektion beschränkt werden. Die
Methode nextLine() liefert dann nur die Daten in der angegebenen Sektion. Wird
anstelle des Sektionsnamen null übergeben, können alle Zeilen der Datei ohne Rücksicht
auf Sektionen ausgelesen werden. Die Methode liefert true zurück, wenn die gewünschte
Sektion in der Datei existiert, sonst false.
String nextLine()
Diese Methode liefert die nächste Zeile in der ausgewählten Sektion, wobei Kommentarzeilen übergangen werden. Ist keine Zeile mehr verfügbar, wird null zurückgegeben.
boolean hasMoreLines()
Testet, ob noch weitere Zeilen in der Sektion oder Datei vorhanden sind. Wenn ja, wird
true retourniert, sonst false.
Vector separateString(String s)
Diese statische Funktion dient dazu, einen String (beispielsweise eine Zeile der
Konfigurationsdatei) aufzuteilen. Wenn Wörter durch einen Beistrich getrennt sind,
werden diese in einen Vektor geschrieben. Ist das nächste Wort durch Space oder
Tabulator vom vorigen getrennt, wird ein neuer Vektor begonnen. Zurückgegeben wird
ein Vektor aus diesen Vektoren. Listing 11.2 verdeutlicht die Funktion.
KAPITEL 11 - ZUSÄTZLICHE MODULE
159
Zeilen mit dem Aussehen:
text1, text2
text3, text4
werden in folgenden Vektor aus zwei Stringvektoren umgewandelt:
Vektor(Vektor(text1, text2),Vektor(text3, text4))
Listing 11.2: Beispiel zur Separation eines Strings in Vektoren
int getParamNumber(String paramName, String[] paramNames)
Diese statische Funktion gibt den Index eines Parameters in einem Stringarray zurück.
Wird der Parameter nicht gefunden, wird -1 retourniert.
main(String[] args)
Diese Funktion ist ebenfalls implementiert und ermöglicht es, mit dem in Listing 11.3
gezeigten Aufruf die Funktion der Klasse zu testen. Die Ausgabe aller in der Datei oder in
der angegebenen Sektion vorkommenden Zeilen (bis auf Kommentarzeilen) erfolgt dabei
auf die Standardausgabe.
java –Duser.timezone=ECT CollectorInterface Filename [Sectionname]
Listing 11.3: Aufruf des ConfigReader zum Test der Klasse
11.1.2 Programmierbeispiel
Die Verwendung der Klasse läßt sich mit dem Programmierbeispiel in Listing 11.4
verdeutlichen.
String[] parNames = {"param1", "param2", "param3");
String[] params = new String[parNames.length];
ConfigReader cr = null;
try {cr = new ConfigReader("Konfigdatei");}
catch (IOException e) {
return("Error opening configuration file.");
}
try {
if (!cr.setSection("Sektionsname"))
return("Error. Section [Sektionsname] not found.");
while (cr.hasMoreLines()) {
String line = cr.nextLine().trim();
StringTokenizer t = new StringTokenizer(line);
if (t.countTokens() != 2) {
return("Error in configuration file.\n" +
"Line must have parameter name and " +
"value.\n\nLine:\n" + line);
}
int num =
ConfigReader.getParamNumber(t.nextToken(),parNames);
if (num == -1) {
KAPITEL 11 - ZUSÄTZLICHE MODULE
160
StringBuffer names = new StringBuffer();
for (int i=0; i<parNames.length; i++)
names.append(parNames[i] + "\n");
return("Error in configuration file.\n" +
"Parameter unknown.\nKnown parameters are:\n" +
names +"\nLine:\n" + line);
}
params[num] = t.nextToken("\r\n").trim();
}
}
catch (IOException e) {
return("Error reading configuration file.\n" + e);
}
Listing 11.4: Programmierbeispiel mit ConfigReader
Durch die offene Programmierung kann die Klasse jederzeit leicht um eigene Funktionen erweitert werden, um etwa besondere Formen von Konfigurationszeilen, wie bei
SeparateString, auszuwerten.
11.2 Log und LogListener
Die Klasse Log bietet statische Methoden, um Meldungen in Logdateien auszugeben.
Dabei werden zwei Logdateien unterstützt – eine für Standardmeldungen und eine für
Fehlermeldungen. Die Klasse bietet auch die Möglichkeit, alle Meldungen an einen
Listener zu übergeben. So kann ein anderes Modul etwa alle Meldungen auch in ein
Fenster auf dem Bildschirm ausgeben, um den Anwender zu informieren.
11.2.1 Konfiguration
In der Konfigurationsdatei Log.cfg werden folgende Parameter erwartet:

StandardLog
Parameter für Pfad und Dateiname für Standardmeldungen.

ErrorLog
Parameter für Pfad und Dateiname für Fehlermeldungen.

LogTime
Dieser Parameter gibt an, ob der Zeitpunkt der Meldung mitprotokolliert werden soll.
Die Ausgabe erfolgt in der Form yyyy/MM/dd HH:mm:ss. "0", "no" oder "false"
verhindern die Protokollierung, alle anderen Werte erlauben sie.

ModuleNameLen
Zusammen mit den Meldungen wird die Übergabe eines Namens erwartet. Dieser
Name sollte das Modul, von dem die Meldung stammt, näher spezifizieren. Damit kann
der Anwender eine genauere Zuordnung der Meldung treffen.
Ein Beispiel für die Konfiguration des Log-Moduls zeigt Listing 11.5.
KAPITEL 11 - ZUSÄTZLICHE MODULE
161
# Configuration file for logging function
# Log filename and path
[Config]
StandardLog
./standard.log
ErrorLog
./error.log
# Log the time of event. Values are 0, no or false disable
# time logging. All other values enable time logging.
LogTime
yes
# Length of name of module which logs message
ModuleNameLen
8
Listing 11.5: Beispiel der Konfigurationsdatei Log.cfg für das Modul Log
Das Modul ermöglicht auch die Auswertung von Kommandozeilenparametern um die in
der Konfigurationsdatei angegebenen Pfad und Dateinamen zu umgehen. Eine genaue
Beschreibung befindet sich im Abschnitt 11.2.2 bei der Erläuterung der Funktion init.
11.2.2 Implementierung
Dieser Abschnitt beschreibt die Methoden der Klasse Log. Vor der ersten Verwendung
der Ausgabemethoden sollte das Modul mit init() oder initLog() initialisiert werden,
damit die Konfigurationsdatei eingelesen werden kann. Folgende Funktionen stehen zur
Verfügung:
init(String[] args)
Der Aufruf dieser Funktion ist notwendig, bevor die Funktionen zum Ausgeben der
Meldungen verwendet werden. Die Funktion wertet auch eventuelle Kommandozeilenparameter aus, mit denen man den Logdateien individuelle Namen zuweisen kann. Die
Verwendung der Parameter sieht man in Listing 11.6. Werden keine Parameter angegeben,
bzw. der Wert null übergeben, verwendet die Initialisierungsfunktion die Pfade und
Namen aus der Konfigurationsdatei Log.cfg. Tritt während der Initialisierung ein Fehler
auf, wird eine Fehlermeldung auf Standardout ausgegeben und die Java Virtual Machine
(JVM) beendet.
java –Duser.timezone=ECT Log [-StandardLog Name] [-ErrorLog Name]
Listing 11.6: Beispiel für Aufruf des Moduls Log
String initLog(String[] args)
Hier wird die gleiche Funktionalität wie bei init() geboten, eine eventuelle Fehlermeldung wird als String retourniert. Trat kein Fehler auf, wird null zurückgegeben.
KAPITEL 11 - ZUSÄTZLICHE MODULE
162
setLogListener(LogListener l)
Ein Listener kann gesetzt werden, dessen Funktion logMessage(String m) alle
Meldungen übergeben werden. So können übergeordnete Module alle Meldungen
mitprotokollieren und damit die Ausgabe aller aktuellen Meldungen auf dem Bildschirm
realisieren.
error(String Modulname, String Meldung)
Error erzeugt eine Meldung in der Fehlerlogdatei.
error(String Modulname, String Meldung, Throwable e)
Error erzeugt eine Meldung in der Fehlerlogdatei. Dabei kann eine Exception übergeben
werden, deren Meldungstext ebenfalls in die Datei übernommen wird.
message(String Modulname, String Meldung)
Message erzeugt eine Meldung in der Standardlogdatei.
close()
Schließt alle Logdateien.
main(String[] args)
Die Funktion main dient zum Test der Klasse und schreibt je zwei Mitteilungen in die
Konfigurationsdateien für Fehler- und Standardmeldungen.
11.2.3 Programmierbeispiel
Ein Ausschnitt aus einem Java Programm verdeutlicht die Verwendung des Moduls
(siehe Listing 11.7). Um Java Fehlermeldungen abzufangen, wird vorher auf Vorhandensein der benötigten Klassen geprüft. Die Funktion checkForClass("Classname") der
Klasse Common prüft, ob die Java Virtual Machine Zugriff auf die Klasse Log hat und
beendet bei einem Fehler das Programm mit einer Fehlermeldung.
public static void main(String[] args) {
// Auf Vorhandensein der Klasse Common prüfen
try {Class.forName("Common");}
catch (ClassNotFoundException e) {
System.out.println("Error loading class. Common not found.");
System.out.println("Please check class path.");
System.exit(0);
}
// Restliche Klassen prüfen
Common.checkForClass("Log");
Log.init(args);
Log.message("Testmodul", "Starting program.");
ConfigReader cr = null;
try {cr = new ConfigReader(Common.GATHERERCONFIG);}
catch (IOException e) {
Log.error("Testmodul", "Error opening config file. ", e);
Common.fatalError("Error opening configuration file.");
163
KAPITEL 11 - ZUSÄTZLICHE MODULE
}
:
Log.message("Testmodul", "Shutting down.");
Log.close();
}
Listing 11.7: Beispielprogramm zur Verwendung der Klasse Log
Listing
11.8
zeigt eine Beispielausgabe
ModuleNameLen=8 und LogTime=yes.
Log:
AVTable:
AVFilter:
HTMLConv:
Gatherer:
DataBase:
DataBase:
Gatherer:
Gatherer:
Gatherer:
Gatherer:
1999/03/20
1999/03/20
1999/03/20
1999/03/20
1999/03/20
1999/03/20
1999/03/20
1999/03/20
1999/03/20
1999/03/20
1999/03/20
des
Moduls
mit
den
Parametern
20:31:26:
20:31:27:
20:31:27:
20:31:27:
20:31:28:
20:31:28:
20:31:28:
20:31:29:
20:31:29:
20:31:29:
20:31:31:
Initializing logging functions.
Initializing attribute-value table.
Initializing attribute-value filter.
Initializing converter.
Initializing gatherer.
Initializing database.
Connecting to jdbc:odbc:GatherDB.
Starting gatherer.
Next gathering at 1999/03/20 20:31.
Gathering started.
Converting and
storing http://test.com/test.
Gatherer: 1999/03/20 20:32:12: Gathering finished. 5 documents
in database.
Gatherer: 1999/03/20 20:32:12: Shutting down gatherer.
DataBase: 1999/03/20 20:32:12: Closing connection to database.
Listing 11.8: Beispiel einer mit dem Modul Log erzeugten Logdatei.
11.3 StringFilter
Diese Klasse bietet statische Funktionen zur Filterung von Zeichenketten wie etwa zum
Reduzieren multipler Whitespaces zu einem, Ersetzen von Zeichenketten oder Umwandeln
von HTML-Bezeichnern in den ISO 8859-1 Zeichensatz. Folgende Funktionen werden
unterstützt:
String cleanString(String raw, boolean doTrans)
Diese Funktion faßt in Zeichenketten aus HTML-Dokumenten mehrere Whitespaces (also
Wagenrücklauf, Zeilenvorschub, Tabulator, Leerzeichen etc.) zu einem zusammen. Dabei
werden auch alle HTML-Kodierungen die Whitespaces ergeben, wie beispielsweise #32
(Leerzeichen), #9 oder #x9 (Tabulator) oder #160 (non breaking whitespace), berücksichtigt. Auf Wunsch (Übergabeparameter doTrans gleich true) werden Sonderzeichen und
Spezialzeichen in Characters umgewandelt. Sonderzeichen haben die Form &aaaaaa; (wie
ö für das Zeichen "ö") und &#aaaa; bzw. ꪪ für hexadezimale Angaben.
Laut ISO 8859-1 nicht darstellbare Zeichen mit Codes von 127 bis 159 (dezimal) werden
dann ignoriert. Listing 11.9 zeigt ein Beispiel und soll die Funktion dieser Methode
164
KAPITEL 11 - ZUSÄTZLICHE MODULE
verdeutlichen.
Zeichenkette vor der Umwandlung:
Da&#115 	   s ist der   
säubernde String &lt Test > Ā &test;.
zu
Das Ergebnis ist dann folgende ISO 8859-1 Zeichenkette:
Das s ist der zu säubernde String < Test > Ā &test;.
Listing 11.9: Beispiel der Funktion cleanString
String escapeQuotesAndBackslashes(String raw, char quote, char escape)
Kommt im String raw ein Quote-Zeichen vor, wird das Zeichen escape davor plaziert.
Kommt escape selbst vor, wird ebenfalls escape eingefügt. Diese Funktion wird vor
allem verwendet, um Zeichenketten für SQL aufzubereiten. Da SQL-Kommandos selber
Zeichenketten sind, ist es nötig, übergebene Zeichenketten so umzuwandeln, daß der SQLBackend die Zeichen korrekt erhält (siehe Listing 11.10).
Der folgende Text:
Test mit "Anführung" und Backslashes \
wird mit Quote=' " ' und Escape='\' beispielsweise umgewandelt in:
Test mit \"Anführung\" und Backslashes \\
und kann in SQL-Statements verwendet werden:
insert into datatable values ("Test mit \"Anführung\" und
Backslashes \\")
Listing 11.10: Beispiel für Funktion escapeQuotesAndBackslashes
replaceString(String raw, String search, String replace)
In der Zeichenkette raw werden alle Zeichenketten search ersetzt durch replace.
String clearPunctuation(String raw)
Alle Zeichen, die keine Buchstaben oder Ziffern sind, werden von Anfang und Ende der
Zeichenkette entfernt.
String delNumbers(String raw)
Alle Zeichenketten, die keine Zahl (Integer oder Float) sind, werden zurückgegeben,
ansonsten wird eine leere Zeichenkette retourniert.
String hexToString(String raw)
Zeichenketten der Form "AB3F7E" werden in Buchstaben zurückgewandelt, wobei jeweils
zwei Zeichen zu einem zusammengefasst (0-255) werden.
String stringToHex(String raw)
Zeichenketten wie "Hallo" werden in Zeichenketten wie "48616c6c6f" umgewandelt.
KAPITEL 11 - ZUSÄTZLICHE MODULE
165
String doubleToString(double Zahl, int anz)
Double Zahl wird in Zeichenkette umgewandelt, wobei höchstens die angegebene Anzahl
an Nachkommastellen berücksichtigt wird (ohne Rundung).
String delimToNewline(String raw)
Wörter in Zeichenketten werden durch Zeilenvorschub voneinander getrennt. Dabei
werden Sonderzeichen wie "," oder "." als Trennzeichen zwischen Wörtern berücksichtigt.
String encodeRFC1738(String raw)
Umwandeln von Zeichenketten laut RFC 17381. Dabei werden sogenannte unsichere
Zeichen wie etwa Leerzeichen zu "%20" umgewandelt, "%" zu "%%". Das wird vor allem
bei URLs verwendet (siehe Listing 11.11).
Die Zeichenkette:
Unsafe Characters wie >%< werden hier gewandelt.
wird zu:
Unsafe%20Characters%20wie%20%3e%25%3c%20werden%20hier%20gewandelt.
Listing 11.11: Umwandeln von Zeichen laut RFC 1738
String decodeRFC1738(String raw)
Zeichenketten werden laut RFC 1738 dekodiert. "%%" wird in "%" umgewandelt. "%xy"
in 8-Bit Zeichen mit dem hexadezimalen Wert xy.
11.4 StrTokenizer
Diese Klasse bietet die selbe Grundfunktionalität wie die Standardklasse StringTokenizer,
wurde aber um einige Methoden erweitert. Dabei sind Funktionen zum beliebigen
Wechseln von Delimitern, zum Rückgängig machen des letzten geholten Tokens und zum
Extrahieren von in Anführungszeichen angegebenen Textteilen.
setDelimiters(String delim)
Mit dieser Methode werden die Trennzeichen angegeben, die die einzelnen Token
voneinander trennen.
undoNextToken()
Der letzte Aufruf der Methode nextToken() wird rückgängig gemacht. Diese Methode
wird vor allem in Verbindung mit nextWord() verwendet.
1
Unsichere Zeichen sind in RFC 1738 definiert und sollten umgewandelt werden, um
sicheres Funktionieren aller Anwendungen zu gewährleisten. Diese Zeichen sind alle
nicht US-ASCII Zeichen bzw. alle Zeichen zwischen 0x00 und 0x1F und
<>\"#%{}|\\^~[]`' sowie das Leerzeichen.
KAPITEL 11 - ZUSÄTZLICHE MODULE
166
nextWord()
Diese Methode gibt das nächste Token zurück beziehungsweise, wenn das Token mit den
Anführungszeichen >"< oder >'< beginnt, den von diesen Anführungszeichen eingeschlossenen Text.
String getTillChar(char stopCharacter)
Alle Zeichen bis zum angegebenen stopCharacter oder bis zum Ende der Zeichenkette
werden zurückgegeben.
11.5 MD5 und MD5Builder
Die verwendete Java Version 1.1.8 besitzt keine Klassen zur Erzeugung von
Checksummen (diese Funktionalität bietet erst Java 2). Die Klasse MD5 bietet Methoden
zur Bildung der MD5-Summe beliebiger Daten laut RFC 1321. Die Klasse ist unter der
GNU Library General Public License verfügbar und wurde programmiert von Santeri
Paavolainen2. Listing 11.12 zeigt ein Beispielprogramm zur Verwendung der Klasse.
md5 = new MD5();
BufferedReader in = new BufferedReader(new InputStreamReader(is));
int c = in.read();
while (c != -1)
{
md5.Update(c);
c = in.read();
}
in.close();
System.out.println(md5Sum = MD5.asHex(md5.Final()));
Listing 11.12: Beispielprogramm zur Verwendung der Klasse MD5
Die Klasse MD5Builder dient zur Erzeugung der MD5-Summe beliebiger File- oder
URL-Objekte. Der Inhalt der Dateien wird dabei im Hauptspeicher zwischengespeichert
und kann bei Bedarf abgefragt werden. So muß das Dokument bei einer etwaigen
Weiterverwendung nicht extra wieder eingelesen oder über das Netzwerk geholt werden.
Der MD5Builder akzeptiert als Konstruktor entweder ein File-Objekt, eine URL oder
eine schon vorhandene URLConnection. Die erzeugte MD5-Prüfsumme und die
eingelesenen Daten können dann über eine der beiden folgenden Methoden abgerufen
werden:
String getMD5()
Ausgeben der MD5-Prüfsumme als String mit Hexadezimalzahlen.
2
Santeri Paavolainen, Helsinki Finland, http://www.cs.hut.fi/~santtu/java/
KAPITEL 11 - ZUSÄTZLICHE MODULE
167
String getData()
Ausgeben der gelesenen Daten.
Mit diesem Modul kann die MD5-Prüfsumme von beliebigen Datenquellen einfach
erstellt werden. Die gelesenen Daten werden im Speicher behalten (Cache) und
ermöglichen so ohne weitere Laufwerk- oder Netzwerkzugriffe einen schnellen Zugriff.
11.6 ListenPort
Dieses Modul stellt eine Funktion zur Verfügung, die an einem beliebigen TCP/IP Port
auf die Eingabe eines korrekten Paßwortes wartet. Das Interface kommuniziert in Klartext
mit dem Klienten, so daß der Anwender auch Telnet oder ähnliche Programme verwenden
kann, um das Paßwort einzugeben.
boolean waitPassword(String name, int port, String pass)
Listing 11.13: Funktion zum Warten auf ein bestimmtes Paßwort.
Die in Listing 11.13 gezeigte Funktion akzeptiert immer nur eine Klientenverbindung
auf einmal. Tritt bei der Initialisierung ein Fehler auf, so gibt die Funktion den Wert false
zurück. Wird ein korrektes Paßwort eingegeben, retourniert die Funktion true. Die
Ausgabe der Funktion hat dabei etwa das in Abbildung 11.1 gezeigte Aussehen.
Abbildung 11.1: Terminalausgabe der Funktion WaitPassword
Werden vom Klienten keine Zeichen erhalten, so beendet die Funktion die Verbindung
automatisch nach 15 Sekunden, um die Verbindung nicht unnötig zu blockieren und die
Ressourcen wieder freizugeben. Bei Eingabe eines falschen Paßwortes erhält der Klient die
Möglichkeit, seine Eingabe zu Wiederholen. Nach drei falschen Versuchen beendet die
Funktion automatisch die Verbindung. Im Modul ist auch die Funktion main implementiert, so daß es direkt gestartet werden kann, um waitPassword auszuprobieren.
KAPITEL 11 - ZUSÄTZLICHE MODULE
168
11.7 SendPassword
Um zum Beenden von Gatherer oder Collector-Interface nicht extra ein Terminalprogramm starten zu müssen, gibt es die Möglichkeit die Kommunikation mit dem Modul
ListenPort zur Übergabe des Shutdown-Passwortes vom Java-Programm SendPasswort
erledigen zu lassen.
java SendPassword [Hostname] Portnumber Password
Listing 11.14: Start des Moduls SendPassword
Mit dem in Listing 11.14 gezeigten Aufruf versucht das Modul eine Verbindung mit
dem angegebenen Host und Port aufzubauen. Ohne Angabe des Parameters Hostname wird
angenommen, daß die Verbindung am lokalen Rechner aufgebaut werden soll. Der Verlauf
der Kommunikation wird auf dem Bildschirm mit ausgegeben und der Anwender auf
etwaige Fehler aufmerksam gemacht. Die Ausgabe bei erfolgreich übergebenem Paßwort
zeigt Listing 11.15.
D:\Java\Projects\HTMLParser>j SendPassword.class 9000 hallo
Trying to shut down application on localhost:9000.
Sent shutdown to application on host localhost, port 9000.
D:\Java\Projects\HTMLParser>
Listing 11.15: Bildschirmausgabe von SendPassword bei erfolgreichem Shutdown
Bei nicht korrektem Port oder Hostnamen bzw. falschem Paßwort wird eine entsprechende Meldung ausgegeben. Ein Beispiel ist in Listing 11.16 zu sehen.
D:\Java\Projects\HTMLParser>j SendPassword.class 9000 hall
Trying to shut down application on localhost:9000.
Shutdown of application on host localhost, port 9000 not
successful.
Wrong password. Please try again.
D:\Java\Projects\HTMLParser>j SendPassword.class 9001 hallo
Trying to shut down application on localhost:9001.
Error. Couldn't get I/O for connection to localhost:9001.
D:\Java\Projects\HTMLParser>
Listing 11.16: Bildschirmausgabe von SendPassword bei nicht korrekten Angaben
Das Modul arbeitet mit ListenPort zusammen und kann direkt in eigenen Programmen
verwendet werden.
169
KAPITEL 11 - ZUSÄTZLICHE MODULE
11.8 TimeDiff
Bei den unterschiedlichen Implementierungen und Umsetzungen von Java auf verschiedene Plattformen gibt es nicht immer einheitliche Verhaltensweisen. Es gibt in Java die
Möglichkeit, die Last Modification Time einer Datei auszulesen. Diese Funktion ist leider
systemabhängig3 und gibt bei vielen Systemen die Anzahl Millisekunden seit dem
1.1.1970 0:00 GMT und der Zeit der letzten Modifikation der Datei zurück.
Mit einer weiteren Funktion kann die aktuelle Systemzeit ermittelt werden, wobei hier
auf jeden Fall die Millisekunden seit dem 1.1.1970 0:00 UTC als Basis dienen. Nun hat
man aber keine Möglichkeit, wenn man die wirkliche Erzeugungszeit einer Datei wissen
will, diese ohne zusätzlichen Aufwand zu bestimmen. Bei JDK 1.1.7A unter Linux 2.0.36
gibt es da keine Schwierigkeiten. Hier stimmen die beiden Zeiten überein. Die Windows
NT/98 Implementierungen von JDK 1.1.7A und älter geben leider, je nachdem ob gerade
Winter- oder Sommerzeit ist, unterschiedliche Werte im Vergleich zur Systemzeit aus.
Diese Werte kann man mit dem Modul TimeDiff ermitteln, wobei angenommen wird,
daß sich die Unterschiede im ganzzahligen Stundenbereich befinden. Zusätzlich wird
geprüft, ob es auch Unterschiede in der Größenordnung beider Werte gibt. So ist es bei
manchen JDK Implementierungen durchaus möglich, daß hier Sekunden statt Millisekunden zurückgegeben werden. Der Unterschied wird dabei auf eine Zehnerpotenz gerundet.
Tabelle 11.1 zeigt die Ausgabe des Programmes auf unterschiedlichen Plattformen und
zu unterschiedlichen Zeiten (Sommer, Winter).
Betriebssystem
Systemzeit
Faktor
Offset in Stunden
Linux JDK 1.1.7A
Sommer/Winter
1
0
Windows 98/NT
JDK 1.1.7A
Sommer
1
2
Winter
1
1
Tabelle 11.1: Unterschiede in der Systemzeit gegenüber der Erzeugungszeit einer Datei
Die Zeit Offset gibt dabei den Unterschied von Dateizeit zu Systemzeit an, also das
Ergebnis der Subtraktion Dateizeit-Systemzeit. Der Faktor ist das gerundete Ergebnis
Dateizeit/Systemzeit. Die so ermittelten Werte können in die Konfigurationsdatei des
Gatherers Gatherer.cfg (siehe Abschnitt 6.3.1) eingetragen werden, z.B. wie in Listing
11.17 gezeigt.
[Config]
File-Time-Factor
File-Time-Offset
1
1
Listing 11.17: Unterschied Dateizeit-Systemzeit in der Gathererkonfigurationsdatei
3
Siehe JDK Dokumentationen Version 1.1.7 und älter. Objekt java.io.File, Methode
lastModified().
170
KAPITEL 11 - ZUSÄTZLICHE MODULE
11.9 Common
In diesem Modul befinden sich Konstanten und Methoden, die in mehreren anderen
Modulen benötigt werden. Unter anderem sind hier die Namen aller Konfigurationsdateien
zentral aufgelistet und können nach Wunsch geändert werden. Die Namen der Sektionen in
den einzelnen Dateien können ebenfalls angepaßt werden.
Es ist beispielsweise möglich, die derzeit in sieben einzelne Konfigurationsdateien
aufgeteilten Parameter, die für das Programm nötig sind, in eine einzelne Datei zu
verlagern. Dabei ist natürlich darauf zu achten, daß jeder Sektionsname einmalig ist. Das
Modul Common hat dann etwa das in Listing 11.18 gezeigte Aussehen.
public class Common {
public static final String
CONVERTERCONFIG
= "Jarvest.cfg",
C_CONVERT_SECT
= "ConvertTab",
C_SEPARATOR_SECT
= "Separator",
AVTABLECONFIG
AV_CONFIG_SECT
= "Jarvest.cfg",
= "AVTableConfig",
AVTABLEFILTERCONFIG = "Jarvest.cfg",
FILT_CONFIG_SECT
= "AVFilterConfig",
GATHERERCONFIG
G_CONFIG_SECT
G_GATHER_SECT
G_INFO_SECT
G_DISALLOW_SECT
=
=
=
=
=
"Jarvest.cfg",
"GatherConfig",
"Adresses",
"Info",
"Disallow",
COLLCONFIG
COLL_CONFIG_SECT
= "Jarvest.cfg",
= "CollectorConfig",
DATABASECONFIG
DB_CONFIG_SECT
= "Jarvest.cfg",
= "DatabaseConfig",
AVANALYZERCONFIG
AN_RATING_SECT
AN_WORDFILTER_SECT
AN_STOPWORD_SECT
=
=
=
=
"Jarvest.cfg",
"Rating",
"WordFilter",
"StopWords",
LOGCONFIG
= "Jarvest.cfg",
LOG_CONFIG_SECT
= "LogConfig",
:
: restliches Programm
Listing 11.18: Klasse Common bei Verwendung einer einzelnen Konfigurationsdatei
Die Funktion checkForClass(String classname) prüft, ob die Java Virtual
Machine (JVM) auf die Klasse "classname" zugreifen kann, sich diese also im
Klassenpfad befindet. Wenn nicht, wird die JVM mit einer Fehlermeldung abgebrochen.
Diese Funktion kann also dazu verwendet werden, beim Start einer Klasse auf das
KAPITEL 11 - ZUSÄTZLICHE MODULE
171
Vorhandensein aller benötigten Klassen zu prüfen. Ist eine Klasse nicht erreichbar, wird
der Anwender darauf aufmerksam gemacht, daß die Installation nicht vollständig oder
fehlerhaft ist.
11.10 AVTable
Dieses Objekt speichert Attribut-Wert-Paare und wird im gesamten Projekt zum
Datenaustausch über Dokumente verwendet. Jedes Attribut kann bestimmte Daten
aufnehmen, also beispielsweise Schlüsselwörter oder Überschriften (Keywords oder
Headings sind dann beispielsweise Attributnamen). Die Daten müssen einem Attribut nicht
komplett übergeben werden, sondern können auch segmentiert sein. In der Konfigurationsdatei wird dabei angegeben, wie die Segmente an vorhandene Daten angefügt werden
sollen. Bei Überschriften etwa kann eingestellt werden, daß diese automatisch in eine neue
Zeile, also durch Zeilenvorschub vom letzten Eintrag getrennt, geschrieben wird. Die
Daten sind als Stringbuffer implementiert, um ein schnelles Anfügen zu gewährleisten.
Attributnamen sind case-sensitive.
Werden neben dem HTML- und Textkonverter andere Konverter implementiert, also
beispielsweise ein PDF-Konverter, muß dieser als Ergebnis eine AVTable liefern, damit
das Dokument weiterverarbeitet werden kann.
11.10.1 Konfiguration
Die Einträge in der Konfigurationsdatei beschreiben, wie Textteile an schon vorhandene
Werte in Attributen angefügt werden sollen. Es gibt die Möglichkeit, jedes Wort eines
anzufügenden Textes in eine Zeile zu schreiben, was vor allem für Keywords verwendet
wird. Die im Kapitel 11.11 – AVTableFilter beschriebenen Filter arbeiten dann ebenfalls
mit einzelnen Zeilen, beispielsweise um Schlüsselwörter zu sortieren oder doppelte Wörter
zu löschen. Um Überschriften oder ähnliches zu extrahieren, kann man den Text zwischen
Anfangs- und Endtag in jeweils eine Zeile extrahieren. Zum Extrahieren des Textes in ein
Attribut ohne Einfluß von Tags dient die dritte Methode, die vor allem für das BodyAttribut (Volltext) verwendet werden kann. Die einzelnen Methoden werden im folgenden
Abschnitt erläutert. Listing 11.19 zeigt eine Konfigurationsdatei der AVTable.
# Configuration file for AVTable.
# This file is used to describe how text is appended to
# destination-attributes during converting (method
# addToAttribute of AVTable). Multiple attributes must be
# separated by commas. A special tag is Default. It is used
# for all tags not mentioned in this section.
# Attributes with ':' are not case sensitive.
#
# Types:
# - AddGroup
Separate text by spaces (used for body)
# - AddLine
Separate text by newlines (for headings)
# - AddWords
Separate each word by newline (for keywords)
#
#-------------------------------------------------------------
172
KAPITEL 11 - ZUSÄTZLICHE MODULE
[Config]
Default
Body
Keywords, ExtraKeywords
Meta:Keywords
AddLine
AddGroup
AddWords
AddWords
Listing 11.19: Beispiel der Kofigurationsdatei der AVTable
Eine Zeile in der Konfigurationsdatei beschreibt, mit welcher Methode Text zu einem
bestimmten Attribut dazugefügt wird. Dazu werden in einer Zeile ein oder mehrere
Attributnamen und die gewünschte Addierfunktion angegeben. Attributnamen müssen
durch Beistrich voneinander getrennt werden, die Addierfunktion wird durch Whitespace
von den Attributnamen getrennt. Als Addierfunktionen stehen AddWords, AddLine und
AddGroup zur Verfügung, um Text wortweise, zeilenweise oder als Ganzes hinzuzufügen.
Ein spezielles Attribut ist 'Default', dessen Addierfunktion auf alle nicht in der Sektion
Add erwähnten Attribute angewendet wird. Die zur Verfügung stehenden Funktionen
werden nun näher beschrieben:
AddLine
Jeder mit der Methode setValue(String attribute, String text) an ein
Attribut angefügte Text wird durch genau einen Zeilenvorschub vom zuletzt angefügten
Text getrennt. Diese Methode ist vor allem für Überschriften interessant.
AddGroup
Text wird nur durch Space vom letzten Text getrennt. Wird vor allem bei Volltext
benützt.
AddWords
Bei jedem angefügten Text werden die einzelnen Wörter durch genau einen Zeilenvorschub voneinander getrennt. Die Zeichenkette wird dabei bei allen Zeichen, die keine
Buchstaben sind, aufgespalten. Diese Methode ist vor allem bei Schlüsselwörtern sinnvoll.
Attributnamen sind case sensitiv, bis auf zusammengesetzte Attribute mit Doppelpunkt.
Da die Namen dieser Attribute direkt aus dem HTML-Text entnommen werden, steht die
Schreibweise nicht fest (Groß- oder Kleinbuchstaben). Im Beispiel wirkt also
Meta:Keywords auch auf Meta:keywords. Wird die Größe der Buchstaben berücksichtigt,
kann es passieren, daß mehrfache Attribute, die eigentlich zusammengehören, erzeugt
werden und zwar, wenn im HTML-Dokument zwei oder mehrere META-Angaben zum
selben Attribut sind, die aber unterschiedlich geschrieben wurden (Keywords und
keywords).
Die Attributnamen von Meta-Tags sind grundsätzlich nicht festgelegt. Damit man mit
diesen Informationen dennoch arbeiten kann, gibt es einige allgemein übliche Namen.
Kapitel 4.1.2 - Meta-Tags zeigt eine Auflistung und Beispiele häufig verwendeter Tags, so
daß eine Auswertung mit dem HTML-Konverter oder anderen Modulen möglich wird.
KAPITEL 11 - ZUSÄTZLICHE MODULE
173
11.10.2 Implementierung
Es stehen mehrere Methoden zur Verfügung, um Daten an vorhandene Attributwerte
anzufügen, den Inhalt eines Attributes abzufragen oder Attribute zu löschen. Wichtig ist
der Aufruf der Funktion init(), damit die Konfigurationsdatei eingelesen werden kann.
boolean containsAttribute(String attribute)
Diese Funktion prüft, ob ein bestimmtes Attribut in der AVTable existiert.
Enumeration attributes()
Eine Auflistung aller Attribute wird retourniert.
int size()
Liefert die Anzahl der Attribute.
String getValue(String attribute)
Gibt den Wert eines bestimmten Attributs zurück.
setValue(String attribute, String text)
Im Objekt wird ein Attribut mit einem bestimmten Inhalt erzeugt und ein vorhandenes
Attribut gleichen Namens überschrieben.
setValueIgnoreCase(String attribute, String text)
Schreibt Daten in die Attribut-Wert-Tabelle. Der Attributname wird an einen eventuell
schon vorhandenen Namen mit anderer Groß-/Kleinschreibung angepaßt. Diese Funktion
wird verwendet, um bei eventuell vorhandenen HTML-Attributen wie Metadaten keine
mehrdeutigen Attribute zu erzeugen (keywords, Keywords, ...).
removeAttribute(String attribute)
Löscht ein Attribut.
setExtracted(String attribute, boolean extracted)
Diese Funktion setzt für ein bestimmtes Attribut einen Merker. Dieser Marker kann dazu
verwendet werden, um doppeltes Anfügen des gleichen Wertes an dasselbe Attribut zu
verhindern.
clearAllExtracted()
Löscht alle mit der Methode setExtracted() gesetzten Merker.
boolean getExtracted(String attribute)
Retourniert den mit setExtracted() gesetzten Merker eines bestimmten Attributes.
setAddNewline(String attribute, boolean addNewline)
Setzt den Merker AddNewline eines bestimmten Attributes.
KAPITEL 11 - ZUSÄTZLICHE MODULE
174
addToAttribute(String attribute, String text)
Fügt Text zu einem bestimmten Attribut dazu. Es wird automatisch die in der Konfigurationsdatei definierte Methode verwendet (AddWords, AddLine, AddGroup).
ensureNewlines(String attribute, int number, boolean allowAtBeginning)
Diese Funktion sorgt dafür, daß die angegebene Anzahl Zeilenvorschübe an den
Attributwert angefügt wird. Sind schon Zeilenvorschübe vorhanden, werden diese
ebenfalls berücksichtigt. Mit dem Parameter allowAtBeginning wird angegeben, ob
auch bei leerem Attribut (noch kein Wert) Zeilenvorschübe angefügt werden sollen.
init()
Diese Funktion wertet die Konfigurationsdatei aus und muß vor Aufruf bzw. Erzeugen
eines AVTable-Objektes aufgerufen werden. Die Funktion ist statisch definiert und wird
nicht automatisch mit dem Objekt-Konstruktor gestartet, damit die Konfigurationsdatei nur
einmal eingelesen werden muß und für alle Instanzierungen verwendet werden kann.
Die AVTable wird von mehreren Modulen verwendet; sie wird beispielsweise zum
Einfügen und Indizieren an die Datenbank übergeben. Das im folgenden beschriebene
Modul AVTableFilter bietet Funktionen, um Attribute der AVTable im Nachhinein zu
beeinflussen.
11.11 AVTableFilter
Dieses Objekt stellt Methoden zur Verfügung, mit denen die einzelnen Attribute einer
AVTable (z.B. Body, Keywords) beeinflußt werden können. Es sind Filter implementiert,
die Wörter sortieren, die Attribute löschen oder zusammenfügen oder doppelte Wörter
entfernen. Hier bietet sich die Möglichkeit, neue oder erweiterte Filter zu programmieren.
Als Beispiel wurde ein Filter zur Bildung eines Abstracts (d.h. einer Inhaltszusammenfassung) implementiert (siehe filterMakeAbstract).
Die Einträge in der Konfigurationsdatei des AVTableFilters bestehen aus einer Anzahl
von Attributen, durch Beistrich voneinander getrennt. Anschließend wird durch
Whitespace getrennt von den Attributen die Art des Filters angegeben. Attributnamen sind
case sensitiv, bis auf zusammengesetzte Attribute mit Doppelpunkt (siehe Abschnitt 7.1.3).
Folgende Filterfunktionen stehen zur Verfügung:
Sort
Die Zeilen eines Attributes werden alphabetisch sortiert. Das dient vor allem dazu,
Attribute zu bearbeiten, in denen in je einer Zeile ein einzelnes Wort steht (Keywords). Als
Sortieralgorithmus wird ein schneller Quicksort verwendet.
DelDouble
Sortiert die Zeilen eines Attributes alphabetisch und löscht doppelt vorkommende Zeilen.
Dieser Filter kann für Keywords oder URL-References verwendet werden.
175
KAPITEL 11 - ZUSÄTZLICHE MODULE
Delete
Löscht die angegebenen Attribute.
Join(Destination-Attribut)
Dieser Filter dient dazu, mehrere Attribute zu einem neuen zusammenzufügen, wobei
dieses vorher nicht existieren muß. Wird nur ein zu bearbeitendes Attribut angegeben,
kann man Join dazu verwenden, ein Attribut auf ein anderes zu kopieren. Existieren die
angegebenen Attribute nicht, dann wird nur ein eventuell vorhandenes Destination-Attribut
gelöscht.
DeleteNumbers
Löscht Zeilen in einem Attribut, die nur aus Zahlen (Fließkomma oder Ganzzahlen)
bestehen. Dieser Filter wird verwendet, um etwa Zahlen als Keywords auszuschließen.
DelSmall(Length)
Löscht Zeilen, die kürzer oder gleich der angegebenen Länge sind. Dieser Filter kann
verwendet werden, um nicht relevante Schlüsselwörter auszuschließen, wie etwa er, es,
das, als, vor, auf, und u.s.w.
DelLong(Length)
Löscht Zeilen, die gleich viele oder mehr Zeichen als die angegebenen Länge haben. Kann
verwendet werden, um zu lange Wörter auszuschließen.
LowerCase
Ändert alle Zeichen in einem Attribut auf Kleinbuchstaben. Schlüsselwörter können mit
diesem Filter in Kleinbuchstaben gewandelt und anschließend mit DelDouble doppelte
gelöscht werden. So werden unterschiedliche Schreibweisen, wie "Gestern" und "gestern"
ausgeschlossen.
MakeAbstract(Destination-Attribute)
Dieser Filter wird benützt, um ein Abstract oder eine Description eines Dokuments zu
erzeugen. Momentan prüft dieser Filter, ob das erste angegebene Attribut existiert, und
verwendet dieses. Ansonsten werden vom zweiten Attribut die ersten Zeichen genommen
und als Abstract verwendet. Es ist sinnvoll, als erstes Attribut z.B. Meta:Abstract
anzugeben, falls irgendwo in dem Dokument ein Meta-Tag ein Abstract ergibt. Als zweites
Attribut kann, wie in Listing 11.20 gezeigt, Body oder Headings verwendet werden.
Meta:Abstract, Body
MakeAbstract(Abstract)
Listing 11.20: Eintrag der Konfigurationsdatei des AVFilters für MakeAbstract
Der Filter ist modular programmiert und kann einfach erweitert werden, um etwa in einem
Attribut (z.B. Body) nach einem Absatz mit der Überschrift Abstract zu suchen und dann
diesen zu verwenden.
KAPITEL 11 - ZUSÄTZLICHE MODULE
176
Encode1738
Zeilen werden nach RFC1738 kodiert, um unsichere Zeichen in URLs zu vermeiden. Diese
können entstehen, wenn Referenzen in HTML-Dokumenten nicht entsprechend angegeben
sind.
Decode1738
Wenn URLs kodiert im Dokument vohanden sind, diese aber im Klartext benötigt werden,
kann man diesen Filter verwenden.
AddDocBase(Attribute-with-DocBase)
Manchmal wird in Dokumenten das Tag "Base" mit dem Tag HRef verwendet. Alle
relativen Referenzen innerhalb des Dokuments beziehen sich dann auf die unter Base:HRef
angegebene Basisreferenz. Wenn diese mittels der Sektion ConvertTab extrahiert wurde,
dann kann mit diesem Filter die Basisreferenz zu allen gefundenen relativen Referenzen
dazugefügt werden. Dieser Filter wird vor allem auf die Attribute URL-References oder
Pictures oder auch ActiveX und Applets angewendet.
DelSelfRefs
Dieser Filter löscht alle Zeilen in einem Attribut, die mit dem Zeichen '#' beginnen. Dieser
Filter wird vor allem bei URL-Referenzen verwendet, um Zeilen zu löschen, die auf eine
Sektion im gleichen Dokument verweisen.
Eine mögliche Konfigurationsdatei für AVFilter ist im Listing 11.21 zu sehen.
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Configuration for AVTableFilter.
The following filters are applied to attributes of AVTables.
Filters are:
- Sort
Sort lines of an attribute (for e.g.
keywords).
- Delete
Delete an attribute.
- DelDouble
Delete equal lines.
- Join(Dest)
Join one or more attributes to a
single one.
- Encode1738
Code with RFC1738 (convert unsave
characters in URLs)
- Decode1738
Decode with RFC1738 (some references
are 1738-encoded)
- DeleteNumbers
Delete lines with numbers (e.g.
for keywords).
- DelSmall(x)
Delete lines with x or less characters.
(e.g. deleting short keywords: he,
it, of...)
- DelLong(x)
Delete all lines with number of
characters greater or equal x.
- LowerCase
Change all characters to lowercase.
- MakeAbstract(Dest) Creates a destination-attribute. This
filter is used to create an abstract
or a description of the document.
For example if the first attribute
exists it will be used as abstract
otherwise the first some characters of
177
KAPITEL 11 - ZUSÄTZLICHE MODULE
#
the second attribute are used (it is
#
useful to take body or headings).
# - AddDocBase(Base)
If attribute 'Base' exists add to all
#
relative URLs the absolute address
#
contained in Base.
# - DelSelfRefs
This filter deletes lines starting
#
with '#'. It is used to delete self#
references e.g. in the attribute
#
url-references.
#
# Attributes must be separated by commas. One filter per
# line is allowed. Attributes with ':' are not case sensitive.
#
# Example:
# Meta:Keywords
Join(Keywords)
#------------------------------------------------------------[Config]
Meta:Keywords
DelSmall(3)
Meta:Keywords
DelLong(30)
Meta:Keywords
SortDelDouble
# Attention: If Meta-Tag with keywords exist the self
# extracted keywords will be overwritten.
Keywords
DelSmall(3)
Keywords
DelLong(30)
# If you are going to use rating in keywords you should NOT
# use SortDelDouble, because otherwise it is not possible to
# count how often a word occurs here.
Keywords
Sort
URL-References
URL-References
URL-References
SortDelDouble
DelSelfRefs
AddDocBase(DocBase)
Pictures
Pictures
SortDelDouble
AddDocBase(DocBase)
ActiveX, Applets
DocBase
AddDocBase(DocBase)
Delete
Scripts, ActiveX, Applets
SortDelDouble
Meta:Abstract, Body
Meta:Abstract
MakeAbstract(Abstract)
Delete
Listing 11.21: Beispiel einer Konfigurationsdatei des AVFilter-Moduls
Nach der Ausführung aller in der Konfigurationsdatei angegebenen Filter werden alle
leeren Attribute gelöscht um unnötig belegten Speicherplatz freizugeben. Zusätzlich
werden alle zusammengesetzten Attribute wie Meta:Keywords umgewandelt in Attribute
ohne den Zusatz vor dem Doppelpunkt, hier also in Keywords. Ist schon ein Attribut mit
diesem Namen vorhanden (auch wenn Groß- und Kleinbuchstaben unterschiedlich sind),
wird dieses überschrieben. Die Umwandlung wird durchgeführt, da alle Angaben der
178
KAPITEL 11 - ZUSÄTZLICHE MODULE
Attribut-Wert-Tabelle Meta-Angaben sind und nicht von den Meta-Angaben, die direkt im
Dokument gemacht werden, unterschieden werden.
Sollen die selbstständig extrahierten Keywords und die eventuell in einem Meta-Tag
angegebenen Keywords verwendet werden, dann kann man die beiden Attribute
miteinander verbinden. Die Vorgehensweise dabei ist in Listing 11.22 zu sehen. Dabei
werden alle Schlüsselwörter aus Meta-Tags und alle selbst extrahierten Wörter in einem
einzigen Attribut zusammengefaßt und nicht mehr benötigte Attribute gelöscht.
[Config]
Meta:Keywords, Keywords
Meta:Keywords
Keywords
Keywords
Keywords
Join(Keywords)
Delete
DelSmall(3)
DelLong(30)
Sort
Listing 11.22: Konfiguration bei Berücksichtigung von Meta-Keywords
11.12 AVTableAnalyzer
Dieses Modul erzeugt aus einem Objekt AVTable Worttabellen. Diese Tabellen sind
Hashtables mit Wörtern als Key und einem Integerarray, das die Anzahl der einzelnen
Wörter in den verschiedenen Attributen der AVTable repräsentiert (z.B. im Body,
Keywords). Die Worttabellen werden verwendet, um Dokumente zu indizieren; die Wörter
und zugehörigen Zähler werden in der Datenbank gespeichert.
Alle Zeichen werden in das ISO 8859-1 Character-Set abgebildet, um eine eindeutige
Identifizierung der Wörter zu ermöglichen. Das Wort Fön kann sonst als Fön,
Fön oder auch Fön usw. dargestellt werden. Erstens wird so erst eine Suche
nach dem Wort ermöglicht und zweitens wird die Anzahl der Wörter in der Datenbank
reduziert, da es für jeden Buchstaben zumindest drei Darstellungsmöglichkeiten gibt.
Das Modul bietet außerdem eine Anzahl Filter, um die Wörter noch weiter einzuschränken. Einerseits können die Wörter in Kleinbuchstaben gewandelt oder zu lange bzw. zu
kurze Wörter ausgeschlossen werden. Auf Wunsch können auch alle Arten von Zahlen
vom Analyseprogramm ignoriert werden.
11.12.1 Konfiguration
Zwei Sektionen der Konfigurationsdatei werden ausgewertet: WordFilter und Rating.
Diese wurden, um die Anzahl der Konfigurationsdateien zu verringern und da sie
thematisch dazu passen, in der Konfigurationsdatei der Datenbank untergebracht. Für eine
genaue Beschreibung der Sektion WordFilter sei auf Kapitel 10.6.2 und für Rating auf
Kapitel 10.6.3 und 10.4.4 verwiesen.
KAPITEL 11 - ZUSÄTZLICHE MODULE
179
11.12.2 Implementierung
Es stehen mehrere Methoden zur Verfügung, um etwa die Anzahl der Wörter in
bestimmten Attributen zu ermitteln oder auch Stoppwörter zu erkennen. Wichtig ist der
Aufruf der Funktion init(), damit die Konfigurationsdateien eingelesen werden können.
init()
Diese Funktion initialisiert den Analyzer. Die Rating- und WordFilter-Sektionen der
Konfigurationsdatei werden eingelesen und ausgewertet. Diese Funktion muß vor der
ersten Instanzierung der Klasse aufgerufen werden und beendet bei einem Fehler die JVM.
String initRatingParams(String path)
Die Rating-Parameter können bei Bedarf eingelesen werden. Diese Funktion liefert
etwaige Fehlermeldungen als String zurück. Tritt kein Fehler auf, wird null retourniert.
Suchprogramme wie etwa Suchservlets verwenden diese Funktion, da das Programm (also
der Webservers) nicht abgebrochen werden soll wie bei Funktion init().
String initWordFilterParams(String path)
Die WordFilter-Parameter können auf Bedarf eingelesen werden. Diese Funktion liefert
etwaige Fehlermeldungen als String zurück. Tritt kein Fehler auf, wird null retourniert.
initWordFilterParams wird verwendet, damit das Programm (etwa der Webserver) nicht
abgebrochen wird.
AVTableAnalyzer(AVTable av)
Der Konstruktor des AVTableAnalyzer-Objektes. Als Parameter muß die zu analysierende
AVTable übergeben werden.
Vector getRatingTab()
Die Tabelle mit Werten aus der Rating-Sektion der Konfigurationsdatei wird zurückgegeben. Diese Funktion wird benötigt, wenn man die Gewichtung der Wörter in den einzelnen
Attributen ermitteln will. Retourniert wird ein Vektor aus AttribRating-Objekten. Die
Klassendefinition zeigt Listing 11.23.
class AttribRating
{
public String attrib = null;
public int
rating;
public int
maxCount = Integer.MAX_VALUE;
}
Listing 11.23: Klassendefinition eines AttribRating-Objektes
Dieses Objekt beschreibt wie Wörter in den einzelnen Attributen (Body, Keywords, etc.)
zu gewichten sind. Zusätzlich ist noch eine Maximalgrenze vorgesehen, um KeywordSpamming einschränken zu können.
180
KAPITEL 11 - ZUSÄTZLICHE MODULE
AttribRating getAttribRating(String attr)
Ein zu einem bestimmten Attributnamen gehörendes Rating-Objekt wird zurückgegeben
bzw. null, wenn das Attribut nicht existiert.
Hashtable countWords()
Diese Funktion analysiert das mit dem Konstruktor übergebene Dokument. Zurückgegeben
wird eine Hashtable, welche als Schlüssel alle in den zu bewertenden Attributen
vorkommenden Wörter enthält. Als Daten in der Hashtable werden pro Wort Zähler
zurückgegeben, die die Anzahl des Wortes in den einzelnen Attributen angibt. Tabelle 11.2
zeigt ein mögliches Ergebnis, wenn Wörter in den Attributen Body (Volltext), Keywords
(Schlüsselwörtern), Titel und Headings (Überschriften) gezählt werden.
Key
Daten der Hashtable (Integer-Array)
Body
Keywords
Title
Headings
haus
2
0
0
2
euro
5
1
0
0
...
...
...
...
...
Tabelle 11.2: Beispiel eines mit AVTableAnalyzer analysierten Dokuments
String wordFilter(String word)
Ein Wort wird mittels der in der WordFilter-Sektion angegebenen Filter bearbeitet. Wird
der Begriff ausgefiltert, wird ein Leerstring retourniert.
String initStopWordTab(String path)
Diese Funktion liest aus der Konfigurationsdatei die Stoppwörter ein. Etwaige Fehlermeldungen werden als String zurückgegeben bzw. null, wenn kein Fehler aufgetreten ist.
boolean isStopWord(String word)
Vor Aufruf dieser Funktion sollte initStopWordTab(String path) aufgerufen werden,
um die Begriffe aus der Konfigurationsdatei einzulesen. Ein bestimmtes Wort wird geprüft
und bei Übereinstimmung mit einem Stoppwort den Wert true zurückzugeben.
main(String[] args)
Diese Funktion dient zur Überprüfung des Moduls und gibt, wenn die Initialisierung ohne
Fehler beendet werden kann, die eingelesenen Konfigurationsdaten aus.
KAPITEL 11 - ZUSÄTZLICHE MODULE
181
11.13 AVTableConverter
Der AVTable-Konverter stellt Funktionen zur Verfügung, um die Attribut-Wert-Tabelle
(siehe Kapitel 11.10) in verschiedene andere Formate umzuwandeln. Formate wie
Properties können ebenfalls in AVTables umgewandelt werden.
String AVTableToSOIF(String url, AVTable AVTab)
Die AVTable wird als SOIF-Objekt zurückgegeben.
String AVTableToXML(String url, AVTable AVTab)
Die AVTable wird in wohlgeformtem XML zurückgegeben.
String AVTableToAVString(AVTable av)
Diese Funktion dient dazu, ein AVTable-Objekt in eine Zeichenkette umzuwandeln.
Normalerweise dienen die Serialisierungsfunktionen von Java dazu, ein Objekt in ein
Format umzuwandeln, das es erlaubt, das Objekt beispielsweise in einer Datei zu
speichern. Leider ist es zumindest bis JDK 1.1.7A nicht möglich, TeilObjekte größer als 64
KB zu serialisieren. Deshalb mußten eigene Funktionen implementiert werden. Hier
werden die Objekte in eine Zeichenkette, wie in Listing 11.24 gezeigt, umgewandelt. Nach
A(ttribut) und V(alue) ist jeweils die Länge in Zeichen der einzelnen Sektionen angegeben.
[Axx]aaa[Vyy]bbb[Azz]ccc[Vkk]ddd
[A4]Body[V17]Das ist der Body.[A8]Keywords[V10]...
Listing 11.24: Serialisierte AVTable
AVTable AVStringToAVTable(String avString)
Zeichenketten der Form [Axx]aaa[Vyy]bbb[Azz]ccc[Vkk]ddd u.s.w. werden wieder in
AVTable-Objekte umgewandelt.
AVTable PropertiesToAVTable(String avString)
Eine Zeichenkette, die auch mehrere Zeilen der Form attribute=value enthält, wird in
eine AV-Table umgewandelt.
KAPITEL 11 - ZUSÄTZLICHE MODULE
182
11.14 Zusammenfassung
In diesem Kapitel wurden notwendige Zusatzmodule beschrieben. Der ConfigReader
(siehe Abschnitt 11.1) unterstützt das Einlesen von Kofigurationsdateien. Das Modul Log
(siehe Abschnitt 11.2) besitzt Methoden, die es erlauben, bestimmte Meldungen in
Protokolldateien zu schreiben.
Der Stringfilter aus Abschnitt 11.3 bietet verschiedene Funktionen zum Modifizieren
von Zeichenketten. Abschnitt 11.5 beschreibt Module zum erzeugen der MD5Checksumme und Abschnitte 11.6 und 11.7 behandeln Module zum Beenden von
Programmen über das Netzwerk. TimeDiff (Abschnitt 11.8) berechnet den Unterschied
zwischen System- und Dateizeit. Common (siehe Abschnitt 11.9) beeinhaltet allgemein
verwendete Methoden. Die AVTable (siehe Abschnitt 11.10) ist ein allgemeines Format
zum Austausch von Dokumenteninformationen zwischen praktisch allen implementierten
Programmteilen. Abschnitte 11.11, 11.12 und 11.13 beschreiben Module, mit denen sich
AVTable-Objekte bearbeiten und umwandeln lassen.
Im Anschluß folgt Kapitel 12, welches einen Ausblick mit Erweiterungsmöglichkeiten
der implementierten Programme gibt. Die einzelnen Module werden dabei getrennt
betrachtet. Kapitel 13 faßt die vorliegenden Arbeit zusammen und streicht die wesentlichen
Inhalte von Untersuchungs- und Gestaltungsbereich nochmals heraus. Der Anhang enthält
ein Verzeichnis aller Abbildungen, Tabellen, Listings und der verwendeten Referenzen.
Weitere Referenzen sind im Anhang unter normativer und informativer Literatur
aufgeführt. Alle Referenzen sind, soweit in elektronischer Form verfügbar, auf der
beiliegenden CD-ROM im Verzeichnis "Referenzen" zu finden.
Kapitel 12
Ausblick
Aufgrund der einfachen Erweiterbarkeit der in den letzten Kapiteln beschriebenen Arbeit
ergeben sich verschiedene Möglichkeiten, die Module weiter zu verbessern. Ein nächster
Schritt wird sein, die Einbindung von zusätzlichen Modulen mittels Java Factories so
flexibel wie möglich zu gestalten. Die folgenden Absätze beschreiben Ideen zur
Erweiterung einzelner Programmteile.
Gatherer
Durch Hinzufügen weiterer Konvertermodule (beispielsweise für PDF1 oder für
zukünftige Standards wie XHTML2) können Informationen über zusätzliche Dokumente in
den Datenbestand des Gatherers aufgenommen und so die Vollständigkeit erhöht werden.
Ein Modul zur Ermittlung des Dateityps durch Analyse des Dokumenteninhalts und der
Dateinamenerweiterung ermöglicht den Aufruf des benötigten Konverters. Werden die
Daten über HTTP angefordert, kann der MIME-Typ zur Erkennung des Dateiformates
herangezogen werden.
Es ist auch denkbar, Konverter für multimediale Objekte einzubinden. Es gibt Programme3, die Videosequenzen analysieren und aufgrund des Szenenwechsels Schnappschüsse extrahieren [EG1999]. Diese Schnappschussfolgen von Videos oder verkleinerte
Darstellungen von Bildobjekten könnten ebenfalls in die Gathererdatenbank aufgenommen
und bei einer Suchanfrage zusätzlich im Suchergebnis angezeigt werden.
Die im Root-Verzeichnis eines Servers liegende Datei Robots.txt wird in der vorliegenden Version nicht ausgewertet. Eine Erweiterung des Gatherers kann diese Datei
berücksichtigen. Dazu ist für die lokale Installation ein zusätzlicher Parameter in der
Sektion Gather notwendig, der angibt, wo die jeweilige Robot-Datei zu finden ist. Das ist
nötig, da dem Gatherer nur der zu untersuchende Dokumentenbereich bekannt ist und nicht
das Root-Verzeichnis der Dokumente.
1
Portable Document Format von Adobe Systems, PDF,
http://partners.adobe.com/asn/developer/PDFS/TN/PDFSPEC.PDF
2
XHTML 1.0, The Extensible HyperText Markup Language,
http://www.w3.org/TR/xhtml1/
3
Virage, http://www.virage.com
Excalibur, http://www.excalib.com
KAPITEL 12 - AUSBLICK
184
HTML-Konverter
Wie in Abschnitt 7.5 erläutert wäre es ebenfalls für Suchdienste hilfreich, die im
Dokument verwendete Sprache zu kennen. Dazu kann ein Modul in den HTML-Konverter
integriert werden, daß den Inhalt verschiedener Attribute analysieren kann. Eine
Möglichkeit ist, daß das Meta-Tag Language im Dokument selbst definiert ist. Ist das nicht
der Fall, dann kann beispielsweise durch Betrachtung der im Body verwendeten Wörter
mit hoher Wahrscheinlichkeit auf die verwendete Sprache geschlossen werden.
Gatherer-Collector-Interface
Derzeit besteht die Möglichkeit, die gesammelten Informationen als SOIF oder in
wohlgeformtem XML weiterzugeben. Bei Entwicklung weiterer Formate wie RDF bzw.
einem für Metainformationen nutzbaren Namensraum kann das Interface entsprechend
erweitert werden.
Datenbank
Hier bieten sich Ansätze für Erweiterungsmöglichkeiten, wie etwa ein Synonymfilter
oder Filter, die Wörter auf ihren Wortstamm reduzieren können. So werden etwa Wörter
wie "Rind", "Kuh", "Rinder", "Rindvieh", "Kühe" etc. alle auf einen einzigen Begriff
reduziert, was neben dem verminderten Speicherbedarf auch den Vorteil hat, daß wenn der
Benutzer nach einem bestimmten Dokument sucht, aber in diesem nur Synonyme seines
Suchbegriffes vorkommen, das Dokument trotzdem gefunden wird.
Suchservlet
In einer weiteren Ausbaustufe könnten durch Anpassungen und Erweiterungen der
Benutzerschnittstelle die Möglichkeiten des Gatherers bezüglich Zusatzinformationen
weiter ausgeschöpft werden. In der Ergebnispräsentation müßten diese Dokument- und
Serverinformationen berücksichtigt werden. Bei entsprechender Erweiterung der
Datenbank auf Kurzfassungen von multimedialen Inhalten, könnten diese ebenfalls im
Suchergebnis dargestellt werden und so dem Anwender die Suche erleichtern.
Die Suche kann auf weitere Attribute ausgedehnt werden. Dazu muß die Datenbank
entsprechend erweitert werden, was sich durch die implementierten Methoden nur durch
Ändern der Konfigurationsdateien bewerkstelligen läßt (siehe Kapitel auch 10.5). Das
Suchservlet paßt sich automatisch an die neuen Gegebenheiten an, lediglich das
Suchformular muß geändert werden (siehe Abschnitt 9.3.1.1).
Die Implementierung eines Suchwizards würde die schrittweise Führung des Anwenders
zur gewünschten Suchanfrage hin ermöglichen und so von vornherein helfen, unerwünschte Ergebnisse zu vermeiden. Auch eine nachträgliche Verfeinerung bzw. Suche in
den schon angezeigten Ergebnissen läßt sich so realisieren.
Kapitel 13
Zusammenfassung
Seit der Entwicklung des World Wide Web um 1990 ist das Informationsangebot im
Internet in kürzester Zeit unüberschaubar gewachsen. Mit Einführung einfach zu
bedienender Zugriffswerkzeuge, der Webbrowser, hat sich das Interesse am Internet von
der wissenschaftlichen und militärischen Nutzung hin zu einer zunehmenden Kommerzialisierung gewandelt und repräsentiert heute die weltweit größte und am schnellsten
wachsende unstrukturierte Wissens- und Informationsdatenbank (siehe Kapitel 1).
Die effektive Nutzung dieser Informationen erwies sich im Laufe der Zeit als beinahe
unmöglich und Zeitschriften sowie private Anwender begannen damit, gedruckte
Internetverzeichnisse und Listen von interessanten Webservern zu veröffentlichen. Die
immer schneller steigende Anzahl an Servern führte in weiterer Folge zur Entwicklung von
Suchdiensten, also automatisierten Werkzeugen zum Auffinden von Dokumenten und
anderen Objekten anhand bestimmter Begriffe.
Heutzutage ist eine Anzahl Suchdienste wie AltaVista oder Excite damit beschäftigt,
sich unabhängig von einander durchs Netz zu arbeiten und die Informationen über ein
Suchinterface bereit zu stellen. Sie verfolgen Hyperlinks, laden jeder für sich Dokumente
und extrahieren deren Inhalt. Wie aus dem Untersuchungsbereich hervorgeht, schränkt die
dadurch verursachte Belastung des Internet und der Informationsserver andere Dienste in
ihrer Leistung ein (siehe Kapitel 2). Das Web wächst, so daß dieses Suchkonzept immer
problematischer wird. Nicht nur die Auffindung, auch die Suche nach relevanter und
adäquater Information wird aufgrund der Größe, Unstrukturiertheit und Dynamik des
Informationsangebotes zunehmend schwieriger.
In Kapitel 3 werden daher neue Konzepte wie verteilte Datenaufbereitung und hierarchisch gegliederte Dienste näher untersucht und deren Vor- und Nachteile im Gegensatz zu
gängigen Suchdiensten betrachtet. Bei verteilter Datenaufbereitung gibt es mehrere
voneinander unabhängige Module, die jeweils lokal auf dem Hostrechner eines
Informationsservers installiert sind und diesen nach neuen oder veränderten Dokumenten
durchforsten. Die Module extrahieren Dokumenteninformationen und können komprimierte Inhaltsbeschreibungen an hierarchisch übergeordnete Module über das Internet
weitergeben. Diese Strategie reduziert Netz- und Serverlast und die Informationen können
durch die Nähe zu den Informationen wesentlich aktueller gehalten werden. Ein weiterer
Vorteil ist, daß die erhaltenen Informationen zwischen den übergeordneten Modulen selbst
ausgetauscht werden können und so die Daten mehrfach Verwendung finden. Als
KAPITEL 13 - ZUSAMMENFASSUNG
186
Nachteile stehen dem genannten der erhöhte Organisations- und Koordinationsaufwand
gegenüber, die aber durch die überwiegend positiven Aspekte gerechtfertigt werden.
Die Ergebnisse des Untersuchungsbereichs führen im Gestaltungsbereich der vorliegenden Arbeit zur Implementierung eines System zur verteilten Informationsaufbereitung. Ein
in der Programmiersprache Java programmierter und damit leicht portierbarer lokaler
Gatherer (siehe Kapitel 6), der individuell an die durchschnittliche Änderungsrate der
Daten auf dem Server angepaßt werden kann, durchforstet die Webdokumente und
speichert Änderungen in einer Datenbank. Mit Hilfe des fehlertoleranten HTMLKonverters (siehe Kapitel 7) können dabei alle notwendigen Informationen aus HTMLDokumenten extrahiert werden. Der Konverter unterstützt die automatische Extraktion von
Schlüsselwörtern oder auch Metadaten wie Dublin Core oder LOM (siehe Kapitel 4) und
die Generierung von Abstracts.
Die Untersuchungsergebnisse zeigen ebenfalls, wie wichtig zusätzliche Informationen
über Dokumente für relevante Suchergebnisse sein können (siehe Abschnitte 2.3.4 und
3.2.4). Der Gatherer bietet daher auch die Möglichkeit, Zusatzinformationen für einzelne
Dokumente aber auch für ganze Serverbereiche bereitstellen zu können. Um die vom
Gatherer ermittelten Informationen und Zusatzinformationen weiterverwenden zu können,
wurde eine Schnittstelle implementiert, die die inkrementelle und komprimierte
Weitergabe der Daten ermöglicht (siehe Kapitel 8). Die inkrementelle Datenübertragung
ermöglicht es, nur Informationen über die Dokumente weiterzugeben, die sich seit einem
bestimmten Zeitpunkt geändert haben und somit die Netzbelastung zu reduzieren. Die
Schnittstelle ist eine Erweiterung der Schnittstelle des Harvest-Systems (siehe Abschnitt
3.4.1), daher kann der Harvest-Broker dazu verwendet werden, um vom Gatherer
Informationen zu übernehmen.
Die extrahierten Informationen können zusätzlich dazu benutzt werden, eine lokale
Suchfunktionalität einzurichten und so den Webserver direkt und ohne Umweg über
Suchdienste für Informationsrecherchen zugänglich zu machen. In der vorliegenden Arbeit
wurde ein Modul zur Indizierung aller in den durchforsteten Dokumenten vorkommenden
Begriffe implementiert, welche in einer Datenbank abgespeichert werden. Kapitel 10
erläutert die Struktur und zeigt die Vorgänge beim Einfügen und Löschen von Dokumenten. Ein ebenfalls entwickeltes Suchservlet ermöglicht über ein Webformular die Eingabe
von Stichwörtern zur Suche nach Dokumenten (siehe Kapitel 9). Dabei gibt es die
Möglichkeit, die Begriffe mit logischen Operatoren zu verknüpfen und die Suche auf
bestimmte Attribute einzuschränken. Die gefundenen Dokumente werden nach Wichtigkeit
oder Änderungsdatum sortiert und als HTML-Dokument ausgegeben.
Die vorliegende Diplomarbeit ermöglicht die Realisierung eines Systems zur verteilten
Datenaufbereitung. Lokale Gatherer durchforsten den Dokumentenbestand von Servern
mit minimaler Belastung des Webservers und stellen die Informationen über Schnittstellen
zur Verfügung. Durch die inkrementelle und komprimierte Übertragung der Informationen
auch an mehrere übergeordnete Broker kann die Belastung des Netzwerks signifikant
reduziert werden. Die Gatherer können dabei vom Broker nach geographischen oder
thematischen Gesichtspunkten ausgewählt und deren Daten zusammengefaßt werden.
Anhang 1
Literaturverzeichnis
[Alx1998]
Alexa Web Navigation Service
Web Spawns 1.5 Million Pages Daily According to Findings from
Alexa Internet
San Francisco, Kalifornien, 31. August 1998
http://www.alexa.com/company/inthenews/webfacts.html
[AtAs1998]
Athenia Associates
How Software Agents and Search Engines Work
Ann Arbor, Michigan, 20. Mai 1998
http://www.webreference.com/content/search/how.html
[Bag1996]
Jo Bager
Wortschätze heben. Volltext-Retrievalsystem
c't, Heinz Heise GmbH & Co KG, Hannover, 8/1996, S. 160 ff
[Barn1997]
Welland Barn
SQL – Structured Query Language
Gretton, Northamptonshire, Jänner 1997
http://www.cs.unibo.it/~ciaccia/COURSES/RESOURCES/SQLTutorial/
[Bek1996]
Bekavac, Bernhard
Der findet. WWW-Suchmaschinen und Kataloge
iX, Heinz Heise GmbH & Co KG, Hannover, 7/1996, S. 102 ff
[BCL+1994] Tim Berners-Lee, Robert Cailliau, Ari Luotonen, Henrik Frystyk Nielsen,
Arthur Secret
The World Wide Web. Communications of the ACM
Volume 37(8), August 1994, S. 76-82.
[BDH+1995] Mic Bowman, Peter B. Danzig, Udi Manber, Michael F. Schwartz, Darren
R. Hardy, Duane P. Wessels
Harvest: A Scalable, Customizable Discovery and Access System
Technical Report CU-CS-732-94, Department of Computer Science
University of Colorado, Boulder, 12. März 1995
ftp://ftp.cs.colorado.edu/pub/cs/techreports/schwartz/Harvest.Jour.ps.Z
[Bra1997]
D. Brake
Lost in Cyperspace
New Scientists, IPC Magazines Limited, London, 28. Juni 1997
http://www.newscientist.com/keysites/networld/lost.html
187
[Car1999]
Ron Carnell
Searching the Web, Features Chart
The Win Mill, 13. Jänner 1999
http://rcarnell.com/search/search107.htm
[Dat1986]
C. J. Date
An Introduction to Database Systems
Addison-Wesley, 1986
[DCEl1996] Metadaten-Elemente des Dublin Core
Max-Planck-Institut für Bildungsforschung, Berlin, 18. Dezember 1996
http://www.mpib-berlin.mpg.de/DOK/metatagd.htm
[DCInf1998] Dublin Core Informationen
Niedersächsische Staats- und Universitätsbibliothek Göttingen,
13. November 1998
http://www2.sub.uni-goettingen.de/dublin.html
[DOM1998] Document Object Model (DOM) Level 1 Specification, W3C
11. Dezember 1998
http://www.w3.org/DOM
[Dün1998]
Dünhölter, Kuno
Das Web automatisieren mit XML, 1. September 1998
http://members.aol.com/xmldoku
[Dys1997]
Esther Dyson
Release 2.0, Die Internet-Gesellschaft
Droemer Knaur, München, Oktober 1997
[EH1996]
Die Geschichte des Internet
internet magazin
Markt Schwaben Everts & Hagedorn GmbH, 1/96, S. 100 ff
[EG1999]
John P. Eakins, Margaret E. Graham
Content-based Image Retrieval, A report to the JISC Technology Applications Programme, Institute for Image Data Research
University of Northumbria at Newcastle, Jänner 1999
http://www.unn.ac.uk/iidr/report.html
[DGK+1998] Thomas Dietinger, Christian Gütl, Bernhard Knögler, Dietmar Neussl,
Klaus Schmaranz
Dynamic Background Libraries - New Developments In Distance Education
Using HIKS (Hierarchical Interactive Knowledge System)
Proceedings of ICCE98 (International Conference on Computers
in Education), Oktober 1998
www.iicm.edu/jucs_5_1/dynamic_background_libraries_new/paper.html
[GAM1998] Christian Gütl, Keith Andrews, Herman Maurer
Future Information Harvesting and Processing on the Web
IICM, Graz University of Technology, Austria, Februar 1998
http://www2.iicm.edu/~cguetl/papers/fihap/
188
[Gug1999]
Connie Guglielmo
Netscape Improves Search Service
ZDNet, Inter@ctive Week, 24. Juni 1999
http://www.zdnet.com/intweek/stories/news/0,4164,2281524,00.html
[Hor1998]
Horizont
Studie: Europas Wirtschaft verliert jährlich 50 Milliarden DM
durch unnötige Suche
SQRiBE Technologies, 3. August 1998
http://www.horizont.net/archiv/horizont_net/show.prl?params=keyword%3
Dsquribe%26all%3D1%26type%3D0%26laufzeit%3D0&id=6660
[Hor1999]
Juergen Horwath
Personalised Recommender System
Diplomarbeit, Technische Universität Graz, Jänner 1999
[HSW1996]
Darren R. Hardy, Michael F. Schwartz, Duane P. Wessels
Harvest 1.4pl2 User Manual
University of Edingburgh, 31. Jänner 1996
http://www.tardis.ed.ac.uk/~harvest/docs/old-manual/
[Henn1998]
Henning Behme
Mauerwerk en détail
iX, Heinz Heise GmbH & CO KG, Hannover, 1/1998, S. 116 ff
http://www.ix.de/ix/artikel/1998/01/116/artikel.html
[Hyp1998]
Hyperwave Installation Guide Version 2.6, 1998
[ICE1996]
Information Retrieval Technology and Intelligent Concept Extraction
A Technology Backgrounder from Excite
Excite, Inc., 1996
http://excite.com/ice/tech.html
[Kar1999a]
Stefan Karzauninkat
Ergebnisse gewichten.
http://www.suchfibel.de/5technik/5frame5.htm
[Kar1999b]
Stefan Karzauninkat
Vergleich der Features für Webmaster.
http://www.suchfibel.de/3allgem/3frame6.htm
[Kni1996]
John Knight
Review of Summary Object Interchange Format
Department of Computer Science at Loughborough University of Technology, 21. Mai 1996
http://www.roads.lut.ac.uk/RADAR/soif-review.html
[Koch1996]
Traugott Koch
Suchmaschinen im Internet
Weiter auf dem Weg zur virtuellen Bibliothek! Bibliotheken nutzen das Internet. Erste INETBIB-Tagung in der UB Dortmund, 11. März 1996
Lund Univ. Library, Development Dept. NetLab
http://www.ub2.lu.se/tk/demos/DO9603-manus.html
http://www.ub2.lu.se/tk/demos/DO9603-meng.html
189
[Las1997]
Ora Lassila
Introduction to RDF Metadata
Nokia Research Center, 13. November 1997
http://www.w3.org/TR/NOTE-rdf-simple-intro-971113.html
[Las1998]
Ora Lassila
RDF Model and Syntax Specification
Nokia Research Center, 8. Oktober 1998
http://www.w3.org/TR/PR-rdf-syntax/
[Leg1999]
Herbert Legenstein
Qualitätsaspekte zur Wissensauffindung und Testimplementation für das
xFIND System
Diplomarbeit, Technische Universität Graz, 1999
[LG1998]
Steve Lawrence, C. Lee Giles
How big is the Web
NEC Research Institute, Princeton, New Jersey, 3. April 1998
http://www.neci.nj.nec.com/homepages/lawrence/websize.html
[LG1999]
Steve Lawrence, C. Lee Giles
Accessibility of information on the web
Nature, Macmillan Publishers Ltd 1999, Vol. 400, 8.7.1999
http://www.wwwmetrics.com
[Mau1996]
Hermann Maurer
Hyperwave The Next Generation Web Solution, 1996
[MCF1997]
Tim Bray, R. V. Guha
An MCF Tutorial
Netscape, 22. Dezember 1997
http://www.imsproject.org/technical/Metadata/History/MCF-tutorial.html
[Münz1998] Stefan Münz
SelfHTML Version 7.0, 27. April 1998
http://www.teamone.de/selfaktuell
[Neussl1998] Dietmar Neussl
Weiterentwicklung von Werkzeugen zur Wissensauffindung im
World-Wide-Web
Diplomarbeit, Technische Universität Graz, September 1998
http://www2.iicm.edu/cguetl/education/thesis/dneussl
[NK1994]
Christian Neuss, Robert E. Kent
Conceptual Analysis of Resource Meta-Information, 1994
http://www.igd.fhg.de/www/www95/papers/94/www3.html
[Schön1998] Eckhardt Schön
Das Resource Description Framework (RDF) - ein neuer Weg zur
Verwaltung von Metadaten im Netz
Technische Universität Ilmenau, 1998
http://www.prakinf.tu-ilmenau.de/mik98/eschoen.ps
190
[Shiff1999]
Hank Shiffman
Boosting Java Performance: Native Code & JIT Compilers
Mountain View, California , 9. April 1999
http://www.disordered.org/Java-JIT.html
[SM1998]
André Sonderegger, Peter Meier
Proxyserver
Kantonalen Techniker/innen-Schule für Informatik, 1998
http://clara.rol3.com/~u0334364/proxy.htm
[SoMa1998] Wes Sonnenreich, Tim Macinta
Web Developer.Com: Guide to Search Engines
The Sonnenreich Corporation, Somerville, Massachusetts, Februar 1998
http://gsd.mit.edu/~history/search/engine/history.html
[Sul1999a]
Danny Sullivan
Search Engine Sizes
internet.com Corp, Westport, Connecticut, 1. Juli 1999
http://searchenginewatch.internet.com/reports/sizes.html
[Sul1999b]
Danny Sullivan
Search Engine Features For Web Masters
internet.com Corp, Westport, Connecticut, 6. Juli 1999
http://searchenginewatch.internet.com/webmasters/features.html
[Sul1999c]
Danny Sullivan
Power Searching For Anyone
internet.com Corp, Westport, Connecticut, 1999
http://www.searchenginewatch.com/facts/powersearch.html
[Sul1999d]
Danny Sullivan
AltaVista Debuts Search Features
The Search Engine Report
internet.com Corp, Westport, Connecticut, 4. November 1998
http://searchenginewatch.com/sereport/9811-altavista.html
[VWP1999]
Vancouver Web Pages
A Dictionary of HTML META Tags
Vancouver, 30. Juli 1999
http://vancouver-webpages.com/META/metatags.detail.html
[Wes1995]
D. Wessels
Thoughts and proposals on the second-generation SOIF syntax
Boulder, Colorado, 24. August 1995
http://ircache.nlanr.net/~wessels/Harvest/soif2.html
[WRD1998a] The Web Robots Database
http://info.webcrawler.com/mak/projects/robots/faq.html
[WRD1998b] Database of Web Robots
http://info.webcrawler.com/mak/projects/robots/active/html/index.html
[ZE1998]
Oren Zamir and Oren Etzioni
Web Document Clustering: A Feasibility Demonstration
University of Washington, Seattle, Washington, 1998
http://zhadum.cs.washington.edu/zamir/sigir98.zip
191
Normative und informative Literatur
[HTML32]
HTML Spezifikation 3.2, W3C, 14. Jänner 1997
http://www.w3.org/TR/REC-html32
[HTML40]
HTML Spezifikation 4.0, W3C, 24. April 1998
http://www.w3.org/TR/REC-html40/
[LOMWG]
IEEE Learning Technology Standards Committee,
Learning Objects Metadata Working Group
http://ltsc.ieee.org/wg12/
[PICS]
Platform for Internet Content Selection
http://www.w3.org/PICS/
[RDF]
Resource Description Framework
RDF Model and Syntax Specification, 22. Februar 1999
http://www.w3.org/TR/REC-rdf-syntax/
RDF Schema Specification, 3. März 1999
http://www.w3.org/TR/PR-rdf-schema/
[RFC1321]
Ronald L. Rivest
The MD5 Message-Digest Algorithm, April 1992
http://www.faqs.org/rfcs/rfc1321.html
[RFC1738]
T. Berners-Lee, L. Masinter, M. McCahill
Uniform Resource Locators, Dezember 1994
http://www.faqs.org/rfcs/rfc1738.html
[RFC1766]
H. Alvestrand
Tags for the Identification of Languages, März 1995
http://www.faqs.org/rfcs/rfc1766.html
[RFC2396]
T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter
Uniform Resource Identifiers, August 1998
http://www.faqs.org/rfcs/rfc2396.html
[XML]
Allgemeine Links zu XML Informationen:
Offizielle Seiten des W3C
http://www.w3.org/XML/
XML in der Praxis (deutsch) http://www.mintert.com/xml/
Datachannel XML Seiten
http://www.datachannel.com/xml_resources/
Heise Verlag iX XML Seiten http://www.heise.de/ix/raven/Web/xml/
Netgr@phics XML Seiten
http://www.net-graphics.de/Noframe/XML/
XML Informationen
http://www.xml.com
[XML10]
XML Recommendation Version 1.0 des W3-Konsortiums, 10. Februar 1998
http://www.w3.org/TR/REC-xml
Deutsche Übersetzung, 1998
http://www.mintert.com/xml/trans/REC-xml-19980210-de.html
192
[XMLNS]
XML Namespace, 14. Jänner 1999
http://www.w3.org/TR/REC-xml-names/
[XSL]
Extensible Stylesheet Language (XSL)
http://www.w3.org/Style/XSL/
ISO Normierungen und Spezifikationen sind nicht im World Wide Web zu finden, da
die ISO vom Verkauf von Unterlagen finanziert wird und es keine Online publizierten
ISO-Spezifikationen geben darf. Die Internationale Organisation für Standardisierung
findet man unter folgender Adresse:
[ISO]
International Organization for Standardization
http://www.iso.ch
[ISO639]
ISO 639:1988 (E/F) - Code for the representation of names of languages The International Organization for Standardization, 1st edition, 1988 17
pages Prepared by ISO/TC 37 - Terminology (principles and coordination)
http://www.rupprecht.de/dokulinks/iso639.htm
http://www.iso.ch/cate/d4766.html
[ISO3166]
"Codes for the representation of names of countries", ISO 3166:1993
[ISO88591]
Character Set Encoding (Latin 1)
"Information processing -- 8-bit single-byte coded graphic character sets -Part 1: Latin alphabet No. 1", ISO 8859-1:1987
[ISO8879]
ISO SGML Specification
http://www.w3.org/TR/references.html#ref-ISO8879
[ISO10646]
"Information Technology - Universal Multiple- Octet Coded Character Set
(UCS) - Part 1: Architecture and Basic Multilingual Plane", ISO/IEC
10646-1:1993. Die jetzige Spezifikation inkludiert die ersten fünf Zusätze
zu ISO/IEC 10646-1:1993
193
Tabellenverzeichnis
Tabelle 2.1: Vergleich aktueller Suchdienste ...................................................................... 14
Tabelle 4.1: Übersicht der in Dublin Core definierten Elemente ........................................ 42
Tabelle 4.2: Attribute des Summary Object Interchange Formates .................................... 49
Tabelle 4.3: Beispiel für ein RDF Datentripel ..................................................................... 57
Tabelle 6.1: Besonderheiten der Sektion Gather der Gathererkonfigurationsdatei ............. 79
Tabelle 6.2: Defaultwerte in der Sektion Gather der Gathererkonfigurationsdatei ............. 80
Tabelle 6.3: Bedeutung des Inhalts des Robots-Tag ........................................................... 84
Tabelle 6.4: Reaktion des Gatherers auf Werte des Robots-Tags ....................................... 84
Tabelle 7.1: HTML-Zeichenfolgen, die dem Zeichen Whitespace entsprechen ................. 96
Tabelle 7.2: Auflistung der zusätzlichen Attribute, die vom Konverter erzeugt werden .... 98
Tabelle 7.3: Vergleich der Konvertierungszeiten diverser Interpreter und Compiler ....... 100
Tabelle 8.1: Kommandos des Collector Interfaces ............................................................ 106
Tabelle 8.2: Parameter des SET Kommandos ................................................................... 110
Tabelle 10.1: Relation mit redundanten Einträgen ............................................................ 132
Tabelle 10.2: Aufgeteilte Relationen ohne Redundanzen (2. Normalform) ...................... 133
Tabelle 10.3: Struktur der Dokumentenrelation ................................................................ 134
Tabelle 10.4: Struktur der Zusatzinformationsrelation...................................................... 135
Tabelle 10.5: Struktur der Wortrelation ............................................................................ 135
Tabelle 10.6: Struktur der Wort-Dokumentenrelation ...................................................... 136
Tabelle 10.7: Kreuzprodukt dreier Tabellen ...................................................................... 139
Tabelle 10.8: Mit Where-Klausel eingeschränktes Kreuzprodukt dreier Tabellen ........... 140
Tabelle 10.9: Beispiel einer Dokumentenbewertung bei der Suche .................................. 146
Tabelle 11.1: Unterschiede in der Systemzeit gegenüber der Erzeugungszeit einer Datei 169
Tabelle 11.2: Beispiel eines mit AVTableAnalyzer analysierten Dokuments .................. 180
194
Abbildungsverzeichnis
Abbildung 3.1: Herkömmliche und hierarchische Topologie von Suchdiensten ................ 19
Abbildung 3.2: Möglichkeiten von Harvest für verteilte und kooperative Suchsysteme .... 23
Abbildung 4.1: Ausgabe des Dokuments aus Listing 4.3 mittels HTML-Browser ............ 30
Abbildung 4.2: Schematische Darstellung eines RDF Statements ...................................... 57
Abbildung 4.3: Schematische RDF Darstellung einer Dokument-Autor Beziehung .......... 57
Abbildung 4.4: Schematische Darstellung der Beziehung Autor-Dokument in RDF ......... 58
Abbildung 4.5: Schematische Darstellung eines Containers in RDF .................................. 62
Abbildung 5.1: Zusammenarbeit der Module bei einem Gathervorgang ............................ 67
Abbildung 5.2: Zusammenarbeit der Module des Collector-Interfaces .............................. 68
Abbildung 5.3: Zusammenarbeit der Module des SearchServlets ...................................... 69
Abbildung 9.1: Kommunikation Browser – HTTP-Server – Servlet – Datenbank ........... 117
Abbildung 9.2: Suchformular für Datenbankzugriff mittels Servlet ................................. 118
Abbildung 9.3: Beispielausgabe einer erfolgreichen Suchabfrage .................................... 120
Abbildung 9.4: Konfiguration des Suchservlets in Jigsaw ................................................ 127
Abbildung 9.5: Konfiguration der Parameter des Searchservlets ...................................... 128
Abbildung 10.1: Beispieldokument zur Gewichtung von Dokumenten ............................ 145
Abbildung 11.1: Terminalausgabe der Funktion WaitPassword ....................................... 167
195
Verzeichnis der Listings
Listing 4.1: HTML-Tag mit Attributen und Werten ........................................................... 29
Listing 4.2: Attributwert eines HTML-Tags mit gemischter Groß- und Kleinschreibung . 29
Listing 4.3: Beispiel zur Struktur eines HTML-Dokuments ............................................... 30
Listing 4.4: Verschränkte HTML-Tags und korrigierte, HTML-konforme Version .......... 31
Listing 4.5: Kommentar in HTML-Dokumenten ................................................................ 31
Listing 4.6: Meta-Tag mit den Attributen Name und Content ............................................ 32
Listing 4.7: Beispiel für ein HTML 4.0 Meta-Tag mit Angabe eines Schemas .................. 33
Listing 4.8: Meta-Tag zur Beschreibung des Content-Typs eines Dokuments ................... 33
Listing 4.9: Meta-Tag zur Beschreibung von Schlüsselwörtern eines Dokuments ............. 33
Listing 4.10: Meta-Tag mit kurzer Beschreibung eines Dokuments ................................... 34
Listing 4.11: Meta-Tag mit Angabe der im Tag verwendeten Sprache .............................. 34
Listing 4.12: Meta-Tag mit Angabe des Autors .................................................................. 34
Listing 4.13: Meta-Tag mit Angaben zum Copyright ......................................................... 34
Listing 4.14: Meta-Tags zur Beeinflussung von Robots ..................................................... 35
Listing 4.15: Meta-Tag für Robots zur richtigen Indizierung von Frames ......................... 35
Listing 4.16: Meta-Tag zur Verhinderung der Zwischenspeicherung auf Proxyservern .... 35
Listing 4.17: Meta-Tag mit Angaben zum Herausgeber ..................................................... 35
Listing 4.18: Meta-Tag mit Angaben zum Thema des Dokuments..................................... 36
Listing 4.19: Angaben zum Typ des Dokuments ................................................................ 36
Listing 4.20: Meta-Tag mit Angaben zur Zielgruppe .......................................................... 36
Listing 4.21: Meta-Tags der Homepage der Olympischen Winterspiele 1998 ................... 37
Listing 4.22: Beispiel für mehrsprachige Schlüsselwörter in einem HTML-Dokument .... 38
Listing 4.23: HTML-Text zum automatischen Weiterleiten von Browsern........................ 38
Listing 4.24: Meta-Tag mit allgemeinem Dublin Core Eintrag in HTML .......................... 40
Listing 4.25: Beispiel eines HTML 3.2-Dokuments mit Dublin Core Angaben ................. 41
Listing 4.26: Beispiel eines PICS-Meta-Eintrags in einem HTML-Dokument .................. 45
Listing 4.27: Formale Beschreibung des SOIF-Formates in BNF ...................................... 46
Listing 4.28: HTML-Dokument als Beispiel zur Umwandlung in SOIF ............................ 47
Listing 4.29: Aus dem HTML-Dokument in Listing 4.28 erzeugtes SOIF-Objekt ............ 48
Listing 4.30: Strukturbeispiel Markup Language ................................................................ 52
196
Listing 4.31: Verwendung des Elementtyps Autor in einem XML Dokument ................... 53
Listing 4.32: Definition des Elementtyps Autor in einer XML DTD ................................. 53
Listing 4.33: Wohlgeformtes XML Dokument mit Verweis auf externe DTD .................. 53
Listing 4.34: Lokale Definition der DTD in einem XML Dokument ................................. 53
Listing 4.35: Beispiel einer Adressangabe in MCF mittels XML ....................................... 55
Listing 4.36: Beziehung Autor-Dokument ausgedrückt in RDF mittels XML ................... 58
Listing 4.37: Vereinfachte formale Beschreibung von RDF in EBNF ................................ 59
Listing 4.38: Beziehung Autor-Dokument in RDF mittels XML (numeriert) .................... 59
Listing 4.39: Abgekürzte Schreibweise von RDF in XML ................................................. 60
Listing 4.40: Beispiel einer Aussage über andere Aussagen in RDF .................................. 61
Listing 4.41: Beispiel eines Containers in RDF .................................................................. 62
Listing 6.1: Aufrufparameter des Gatherers ........................................................................ 73
Listing 6.2: Start des Gatherers unter Unix ......................................................................... 73
Listing 6.3: Meldung des Administrator Interfaces bei Beendigung des Gatherers ............ 73
Listing 6.4: Aufruf des Programms SendPassword zum Beenden des Gatherers ............... 73
Listing 6.5: Formel zur Umrechnung von Filezeit in Systemzeit........................................ 77
Listing 6.6: Beispiel einer Konfiguration der Config-Sektion des Gatherers ..................... 78
Listing 6.7: Format eines Eintrags der Sektion Gather der Konfigurationsdatei ................ 78
Listing 6.8: Beispiel einer Konfiguration der Gather-Sektion des Gatherers ...................... 81
Listing 6.9: SOIF mit vom Gatherer hinzugefügten Attributen; diese sind grau unterlegt . 81
Listing 6.10: Beispiel einer Konfiguration der Info-Sektion des Gatherers ........................ 82
Listing 6.11: Beispiel einer Konfiguration der Disallow-Sektion des Gatherers ................ 82
Listing 6.12: Beispiel einer Informationsdatei .................................................................... 83
Listing 6.13: Beispiel eines HTML-Dokuments mit Robots-Tag ....................................... 83
Listing 6.14: Meta-Tag Robots mit kombinierten Attributwerten ...................................... 84
Listing 6.15: Beispiel der Konfigurationsdatei des Gatherers mit virtuellen Servern ......... 85
Listing 6.16: Beispiel einer vollständigen Konfigurationsdatei des Gatherers ................... 87
Listing 7.1: Eintrag der ConvertTab zum Extrahieren von Verweisen auf Bildern ............ 90
Listing 7.2: Beispiel zur Extraktion von Code und Codebase aus HTML-Tags ................. 90
Listing 7.3: Beispiel zur Extraktion des Inhalts von Attributen in HTML-Tags ................ 91
Listing 7.4: Beispiel für falsche Konfiguration des Konverters .......................................... 91
Listing 7.5: Korrekte Konfiguration der Konvertierungstabelle des Konverters ................ 92
Listing 7.6: Beispiel einer Konvertierungstabelle des HTML-Konverters ......................... 93
Listing 7.7: Beispiel einer Konfiguration der Separator-Sektion des HTML-Konverters .. 93
Listing 7.8: Beispiel für HTML-Text mit durch Spezialzeichen getrennten Wörtern ........ 95
197
Listing 7.9: Konvertierter und normalisierter Text aus Listing 7.8 ..................................... 95
Listing 7.10: Beispiel eines Script-Tags in einem HTML-Dokument ................................ 96
Listing 7.11: Text außerhalb der erlaubten Positionen in einem HTML-Dokument .......... 97
Listing 7.12: HTML-Tag mit Anführungszeichen im Wert eines Attributes ...................... 97
Listing 7.13: Konfiguration der ConvertTab für unterschiedliche Keyword-Prioritäten .... 99
Listing 7.14: Interpretation des Konverters von verschränkten HTML-Tags ..................... 99
Listing 7.15: Konfiguration der Sektion ConvertTab zur Arbeitsweise des Konverters ... 100
Listing 7.16: Beispielkonfiguration der ConvertTab-Sektion des HTML-Konverters ..... 101
Listing 7.17: Beispiel einer vollständigen Konfigurationsdatei des HTML-Konverters .. 104
Listing 8.1: Aufrufparameter des Collector Interfaces ...................................................... 106
Listing 8.2: Start des Collector Interfaces mit nohup ........................................................ 107
Listing 8.3: Beispiel der Konfigurationsdatei des Collector Interfaces ............................. 107
Listing 8.4: Ausgabe des Administrator Interfaces ........................................................... 107
Listing 8.5: Aufruf des Moduls SendPassword zum Beenden des Collector Interfaces ... 108
Listing 8.6: Beispiel einer Willkommens-Meldung des Collector Interfaces ................... 108
Listing 8.7: Beispiel für das HELLO Kommando des Collector Interfaces ...................... 109
Listing 8.8: Beispiel für das SEND-UPDATE Kommando des Collector Interfaces ....... 109
Listing 8.9: Zeitberechnung zur Ausgabe aller neuen Dokumente der letzten Woche ..... 109
Listing 8.10: Beispiel der Ausgabe des SEND-UPDATE Kommandos ........................... 110
Listing 8.11: Beispiel der Ausgabe des SEND-UPDATE Kommandos ........................... 110
Listing 8.12: Beispiel der Ausgabe des INFO Kommandos ............................................. 111
Listing 8.13: Ausgabe des Interfaces bei Beendigung der Übertragung ........................... 111
Listing 8.14: Beispiel eines Datenaustausches über das Collector-Interface .................... 114
Listing 9.1: Beispiel einer Konfigurationsdatei für das Suchservlet ................................. 121
Listing 9.2: Servletkonfiguration mit unterschiedlichen Attributen für Schlüsselwörter . 122
Listing 9.3: Aufruf eines Moduls zum Löschen der Datenbank ........................................ 123
Listing 9.4: Beispiel HTML-Dokument für ein Suchformular .......................................... 124
Listing 9.5: Erweiterte Rating-Sektion der Datenbankkonfigurationsdatei ...................... 124
Listing 9.6: Zeile im Suchformular bei Einfügen eines neuen Attributes ......................... 125
Listing 9.7: SQL Statement zur Suche nach bestimmten Dokumenten ............................ 125
Listing 9.8: Klassenpfadangaben für Jigsaw unter Windows und Unix ............................ 126
Listing 9.9: Aufruf der Installationsroutine und Start von Jigsaw .................................... 127
Listing 9.10: Aufruf des Administrationsprogrammes von Jigsaw ................................... 127
Listing 9.11: Aufruf des Administrationsprogrammes von Jigsaw ohne Swing ............... 127
Listing 9.12: Werte für Servlet Parameter DB_CFG_PATH in Jigsaw ............................ 128
198
Listing 10.1: SELECT-Statement zur Verknüpfung mehrerer Tabellen ........................... 139
Listing 10.2: SELECT-Statement mit Where-Klausel ...................................................... 140
Listing 10.3: SELECT-Statement mit Join-Operator ........................................................ 140
Listing 10.4: SELECT-Statement für eine Suchabfrage mit einem Wort ......................... 141
Listing 10.5: Verwendung des LIKE-Operators................................................................ 141
Listing 10.6: SELECT-Statement bei mehreren mit ODER verknüpften Wörtern ........... 141
Listing 10.7: SELECT-Statement mit UNION-Operator statt ODER .............................. 142
Listing 10.8: SELECT-Statement mit INTERSECT-Operator statt UND ........................ 142
Listing 10.9: SELECT-Statement mit SUB-SELECT statt UND NICHT ........................ 143
Listing 10.10: Einschränkung der Suche auf bestimmte Attribute .................................... 143
Listing 10.11: Ermittlung der Anzahl Dokumente in der Datenbank................................ 143
Listing 10.12: Ermittlung der Anzahl Dokumente die ein Wort als Schlüsselwort haben 144
Listing 10.13: Ermittlung aller relevanten Schlüsselwörter eines Dokumentes ................ 144
Listing 10.14: Rating-Sektion der Konfigurationsdatei der Datenbank ............................ 144
Listing 10.15: Kommando zum Löschen der Datenbank .................................................. 146
Listing 10.16: Erweiterung der Rating-Sektion der Datenbankkonfigurationsdatei ......... 147
Listing 10.17: Beispiel der Config-Sektion der Konfigurationsdatei für ODBC .............. 149
Listing 10.18: Beispiel der Config-Sektion für PostgreSQL und InstantDB .................... 149
Listing 10.19: Attribute der Datenbankkonfigurationsdatei für Suchprogramme ............. 149
Listing 10.20: Beispiel der WordFilter-Sektion der Datenbankkonfigurationsdatei ......... 150
Listing 10.21: Beispiel der Rating-Sektion der Datenbankkonfigurationsdatei ................ 150
Listing 10.22: Beispiel der StopWords-Sektion der Datenbankkonfigurationsdatei ........ 151
Listing 10.23: Stoppwortliste für den englischsprachigen Raum ...................................... 151
Listing 10.24: Beispiel einer vollständigen Datenbankkonfigurationsdatei ...................... 153
Listing 11.1: Beispiel einer Konfigurationsdatei ............................................................... 158
Listing 11.2: Beispiel zur Separation eines Strings in Vektoren ....................................... 159
Listing 11.3: Aufruf des ConfigReader zum Test der Klasse ............................................ 159
Listing 11.4: Programmierbeispiel mit ConfigReader ...................................................... 160
Listing 11.5: Beispiel der Konfigurationsdatei Log.cfg für das Modul Log ..................... 161
Listing 11.6: Beispiel für Aufruf des Moduls Log ............................................................ 161
Listing 11.7: Beispielprogramm zur Verwendung der Klasse Log ................................... 163
Listing 11.8: Beispiel einer mit dem Modul Log erzeugten Logdatei. .............................. 163
Listing 11.9: Beispiel der Funktion cleanString ................................................................ 164
Listing 11.10: Beispiel für Funktion escapeQuotesAndBackslashes ................................ 164
Listing 11.11: Umwandeln von Zeichen laut RFC 1738 ................................................... 165
199
Listing 11.12: Beispielprogramm zur Verwendung der Klasse MD5 ............................... 166
Listing 11.13: Funktion zum Warten auf ein bestimmtes Paßwort. .................................. 167
Listing 11.14: Start des Moduls SendPassword ................................................................ 168
Listing 11.15: Bildschirmausgabe von SendPassword bei erfolgreichem Shutdown ....... 168
Listing 11.16: Bildschirmausgabe von SendPassword bei nicht korrekten Angaben ....... 168
Listing 11.17: Unterschied Dateizeit-Systemzeit in der Gathererkonfigurationsdatei ...... 169
Listing 11.18: Klasse Common bei Verwendung einer einzelnen Konfigurationsdatei ... 170
Listing 11.19: Beispiel der Kofigurationsdatei der AVTable ............................................ 172
Listing 11.20: Eintrag der Konfigurationsdatei des AVFilters für MakeAbstract ............ 175
Listing 11.21: Beispiel einer Konfigurationsdatei des AVFilter-Moduls ......................... 177
Listing 11.22: Konfiguration bei Berücksichtigung von Meta-Keywords ........................ 178
Listing 11.23: Klassendefinition eines AttribRating-Objektes.......................................... 179
Listing 11.24: Serialisierte AVTable ................................................................................. 181
200
Anhang 2
CD-ROM
Inhalt:
Referenzen, soweit in elektronischer Form verfügbar
Vorliegende Arbeit
Sourcecode
201