Volltext

Semiautomatische Pflege von Wrappern
Andrea Ernst-Gerlach
12. Februar 2004

Inhaltsverzeichnis
1 Einleitung 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Informationssuche in digitalen Bibliotheken 4
2.1 Aufbau von digitalen Bibliotheken . . . . . . . . . . . . . . . . . . . . . 4
2.2 Vorstellung des MIND-Projektes . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Wrapperarchitektur in MIND . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Aufgaben eines Wrappers . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 Informationsgewinnung von Wrappern . . . . . . . . . . . . . . . 10
2.4 Herkömmliche Erstellung/Pflege von Wrappern . . . . . . . . . . . . . . 12
2.4.1 Bisheriges Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.2 Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Verwandte Arbeiten 15
3.1 ShopBot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.2 Produktunabhängige Architektur . . . . . . . . . . . . . . . . . . 16
3.1.3 Erstellung der Anbieterbeschreibung . . . . . . . . . . . . . . . . 18
i

INHALTSVERZEICHNIS
3.1.4 Shopping-Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.5 Fazit zum ShopBot . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Wrapper Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1 Verifizierung von Wrappern . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 Wrapper-Reinduktion . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3 Fazit zur Wrapper Maintenance . . . . . . . . . . . . . . . . . . . 25
3.3 Fazit zu verwandten Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . 26
4 Rahmen für das Wrapperwerkzeug 27
4.1 Vorhandene Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Grundannahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.1 Ergebnisse der Anfragen . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.2 Anfragestruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.3 Wrappertypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3 Vorstellung des Wrappertoolkits von Rupp . . . . . . . . . . . . . . . . . 30
4.3.1 Die Crawlerkomponente . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.2 Die Tidykomponente . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.3 Die Parserkomponente . . . . . . . . . . . . . . . . . . . . . . . . 34
5 Ideen für die Entwicklung eines eigenen Wrapperwerkzeugs 37
5.1 Vorüberlegungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2 XPath-Ausdrücke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3 Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.4 Generalisierung von XPath-Ausdrücken . . . . . . . . . . . . . . . . . . 39
5.5 Text mit Unterelementen . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.6 Indikatoren für unsichere Schema-Attribute . . . . . . . . . . . . . . . . 40
5.7 Trennung der einzelnen Ergebnisse . . . . . . . . . . . . . . . . . . . . . 42
5.8 Nutzung des Wrappertoolkits . . . . . . . . . . . . . . . . . . . . . . . . 44
ii

INHALTSVERZEICHNIS
6 Vorgehensweise des Reinduction-Tools 46
6.1 Vorgehensweise bei Übersichtsseiten . . . . . . . . . . . . . . . . . . . . 46
6.1.1 Überprüfung der Anfragestruktur und der Logdateien . . . . . . 48
6.1.2 Suche des Templates . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.1.3 Laden der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.1.4 Freie Suche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.1.5 Behandlung von unsicheren Schema-Attributen . . . . . . . . . . 51
6.1.6 Finden der Iterationen . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1.6.1 Bildung der globalen Iterationen . . . . . . . . . . . . . 53
6.1.6.2 Bildung der lokalen Iterationen . . . . . . . . . . . . . . 54
6.1.7 Finden der Extraktionen . . . . . . . . . . . . . . . . . . . . . . . 54
6.1.8 Trennung von Schema-Attributen . . . . . . . . . . . . . . . . . . 57
6.1.9 Bildung von regulären Ausdrücken . . . . . . . . . . . . . . . . . 58
6.1.10 Präzisieren der Iterationen . . . . . . . . . . . . . . . . . . . . . . 58
6.1.11 Testen der neuen Konfigurationsdatei . . . . . . . . . . . . . . . . 59
6.2 Vorgehensweise bei Detailseiten . . . . . . . . . . . . . . . . . . . . . . . 61
6.2.1 Laden der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2.2 Behandlung der unsicheren Schema-Attribute . . . . . . . . . . . 63
6.2.3 Finden der Extraktionen . . . . . . . . . . . . . . . . . . . . . . . 63
7 Evaluierung der Ergebnisse 64
7.1 Evaluierungsmöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.1.1 Evaluierung anhand gebrochener Wrapper . . . . . . . . . . . . . 64
7.1.2 Evaluierung anhand funktionierender Wrapper . . . . . . . . . . 65
7.1.3 Evaluierung anhand von manuell generierten Logdateien . . . . . 65
7.1.4 Evaluierung mit künstlich gebrochenen Wrappern . . . . . . . . . 65
7.1.5 Evaluierung für Daffodil-Wrapper . . . . . . . . . . . . . . . . . . 65
iii

INHALTSVERZEICHNIS
7.2 Evaluierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.2.1 Evaluierung anhand funktionierender Wrapper . . . . . . . . . . 66
7.2.2 Evaluierung anhand von manuell generierten Logdateien . . . . . 67
7.2.3 Evaluierung mit künstlich gebrochenen Wrappern . . . . . . . . . 68
7.2.4 Evaluierung für Daffodil-Wrapper . . . . . . . . . . . . . . . . . . 68
7.2.5 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.3 Bewertung des Wrapperwerkzeugs . . . . . . . . . . . . . . . . . . . . . 69
7.4 Weitere Aspekte der Bewertung . . . . . . . . . . . . . . . . . . . . . . . 70
8 Übertragbarkeit des Wrapperwerkzeugs 72
8.1 Übertragbarkeit auf nicht reguläre Wrapper . . . . . . . . . . . . . . . . 72
8.2 Übertragbarkeit auf allgemeine Wrapper . . . . . . . . . . . . . . . . . . 73
8.3 Übertragbarkeit auf die Erstellung neuer Wrapper . . . . . . . . . . . . . 74
9 Fazit und Ausblick 75
9.1 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
9.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
9.2.1 Überarbeitung der Anfragestruktur . . . . . . . . . . . . . . . . . 78
9.2.2 Verifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
9.2.3 Übertragbarkeit auf allgemeine Wrapper . . . . . . . . . . . . . . 80
9.2.4 Tool zur Erstellung von Logdateien . . . . . . . . . . . . . . . . . 80
9.2.5 Verbesserung der regulären Ausdrücke und der Trennung von Attributen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
9.2.6 Tool zur Nachbearbeitung von fehlerhaften Konfigurationsdateien 81
9.2.7 Suche nach Ergebnissen auf den nachfolgenden Seiten . . . . . . 81
iv

Kapitel 1
Einleitung
1.1 Motivation
Mit zunehmender Verbreitung des Internets ist auch die Menge der dort verfügbaren
digitalen Bibliotheken gestiegen. Allerdings sind die Angebote wegen der großen Anzahl
an unterschiedlichen sowie zudem auch heterogenen Bibliotheken häufig nicht effektiv
nutzbar. Deswegen kommen für eine erfolgreiche Suche meistens mehrere digitale Bibliotheken
zum Einsatz. Die einzelnen Resultate müssen dabei manuell zusammengefaßt
und die Suche muß in anderen Bibliotheken fortgesetzt werden.
Das Projekt MIND (Multimedia International Digital Libraries) behebt dieses Problem,
indem es passende Datenbanken für multimediale internationale digitale Bibliotheken
auswählt und die erzielten Retrievalergebnisse miteinander kombiniert. Hierdurch erhält
der Benutzer den Eindruck, daß es sich um eine einzige digitale Bibliothek und nicht
um die Verknüpfung verschiedener Bibliotheken handelt.
Ein zentraler Bestandteil der digitalen Bibliotheken in MIND sind Wrapper. Sie übernehmen
die Aufgabe aus der HTML(Hypertext Markup Language)-Seite, die nach einer
Anfrage in den meisten Fällen zurückgeliefert wird, die gewünschten Informationen zu
selektieren. Weil die HTML-Seiten von digitalen Bibliotheken aus Datenbanken generiert
werden, bildet ein Wrapper die Umkehrfunktion, die aus einer HTML-Seite wieder
eine Datenbank generiert.
Die Daten auf den HTML-Seiten sind aber wenig strukturiert, da HTML lediglich eine
Seitenbeschreibungssprache ist und keine Strukturierung der Daten enthält. Deswegen
wird ein Wrapper immer speziell für eine HTML-Seite erstellt. Wrapper enthalten eine
Beschreibung, an welcher Stelle die gesuchten Informationen zu finden sind. Da es sich
1

KAPITEL 1. EINLEITUNG
bei HTML-Seiten um semistrukturierte Daten handelt, wird diese zur Beschreibung genutzt.
Dadurch wird im Falle einer Layoutänderung der Webseite durch den Betreiber
für den Wrapper ebenfalls eine Überarbeitung erforderlich sein, weil der Wrapper nicht
mehr die gewünschten Informationen extrahiert. In diesem Fall spricht man von einem
gebrochenen Wrapper. Eine Webseite wird im Durchschnitt zweimal pro Jahr geändert
[Kno]. Dadurch entstehen hohe Kosten für die Pflege von Wrappern, insbesondere
weil die Erstellung der meisten Wrapper manuell erfolgt. Bei einer Überarbeitung eines
Wrapper wird zunächst einmal überprüft, ob sich auch die Anfragestruktur geändert
hat, und diese wird ggf. neu erstellt. Danach muß eine neue Beschreibung der Webseite
angefertigt werden, die eine Selektion der einzelnen Informationen ermöglicht.
1.2 Ziel der Arbeit
Es existieren eine ganze Reihe von Arbeiten, die sich mit der automatischen Erstellung
von Wrappern, der sog. Wrapperinduktion, befassen. Allerdings haben sich nur wenige
mit der Wrapperreinduktion auseinandergesetzt, die sich mit der automatischen Pflege
von Wrappern beschäftigt. Diese ist ein Speziallfall der Wrapperinduktion, bei der
bereits ein Wrapper existiert, der aber gebrochen ist. Weil dieser selbst, bzw. in Form
von mitgeloggten Anfrageergebnissen, Informationen zur Erstellung des neuen Wrappers
liefern kann, ist das Problem der Wrapperreinduktion einfacher zu lösen.
Das Ziel der Diplomarbeit ist die Erarbeitung von Ideen für eine semiautomatische
Pflege von Wrappern. Anhand der entwickelten Ideen soll dann ein Prototyp für ein
Wrappertool erstellt werden. Dazu stehen mitgeloggte Anfragen und deren zugehörige
Ergebnisse zur Verfügung, damit das Wrappertool schon über Angaben verfügt, welche
Informationen auf den Webseiten zu finden sein könnten.
Voraussetzung für die Entwicklung eines entsprechenden Tools ist es, Annahmen zu der
Gestaltung von Webseiten zu treffen. Deswegen ist die Entwicklung eines Tools, das
automatisch für jede digitale Bibliothek einen neuen Wrapper erstellt, nicht möglich.
Angestrebt wird daher, in möglichst vielen Fällen einen neuen Wrapper, bzw. zumindest
ein Grundgerüst für einen Wrapper, zu erstellen. Außerdem sollen auch Kriterien
erarbeitet werden, mit denen der Benutzer von vornherein Bibliotheken erkennt, daß
keine automatische Erstellung eines neuen Wrappers möglich ist. Darüber hinaus soll
das Tool in den Fällen, in denen es zum Einsatz kommt, auch Aussagen treffen können,
ob der neue Wrapper korrekt arbeitet. Dies ist möglich, da die Ergebnisse aus den
Logdateien, die im Rahmen der Erstellung des neuen Wrappers auf den Ergebnisseiten
der digitalen Bibliothek wiedergefunden wurden, bei einem Test des neuen Wrappers
ebenfalls zurückgeliefert werden müssen. Anhand des speziell für MIND-Wrapper ent-
2

KAPITEL 1. EINLEITUNG
wickelten Wrappertools sollen die Lösungsmöglichkeiten bei der Pflege von allgemeinen
Wrappern für HTML-Dokumente aufgezeigt werden.
1.3 Gliederung
In der Einleitung wird das Thema der Arbeit erläutert und das Ziel der Arbeit festgelegt.
Das 2. Kapitel befaßt sich mit der Informationssuche in digitalen Bibliotheken.
Hierzu wird der Aufbau von digitalen Bibliotheken erläutert. Anschließend wird das
MIND-Projekt vorgestellt, in dessen Rahmen das Wrappertool zu entwickeln ist. Besonders
detailliert wird dabei auf die Wrapperarchitektur und die bisherige Erstellung
von Wrappern eingegangen. Um Ideen für die Erstellung eines Wrappertools zu entwickeln,
werden im darauffolgenden Kapitel Arbeiten und Systeme vorgestellt, die sich
ebenfalls mit der Wrapperinduktion beschäftigen.
Im 4. Kapitel wird der Rahmen für das zu entwickelnde Wrapperwerkzeug abgesteckt,
indem die zur Verfügung stehenden Daten und Tools vorgestellt werden. Des weiteren
werden einige Grundannahmen getroffen, die die jeweiligen digitalen Bibliotheken erfüllen
müssen. Das nächste Kapitel befaßt sich mit der Entwicklung von Ideen für das
neue Wrapperwerkzeug. Im 6. Kapitel wird die Vorgehensweise des Werkzeugs erläutert.
Das 7. Kapitel beschäftigt sich mit den Evaluierungsmöglichkeiten der konkreten
Evaluierung des entwickelten Tools und nimmt auch eine Bewertung vor.
Im Anschluß daran überprüft ein weiteres Kapitel, inwieweit das neue Wrapperwerkzeug
auf andere Wrapper übertragbar ist. Kapitel 9 stellt die Ergebnisse der vorliegenden
Arbeit dar. Den Abschluß bildet ein Ausblick auf die Erweiterungsmöglichkeiten des
entwickelten Wrappertools sowie auf Rahmenbedingungen, die den erfolgreichen Einsatz
des Tools erleichtern.
3

Kapitel 2
Informationssuche in digitalen
Bibliotheken
Im folgenden wird zunächst der Aufbau von digitalen Bibliotheken beschrieben und im
Anschluß daran das MIND-Projekt vorgestellt. Das Augenmerk richtet sich dabei besonders
auf die Aufgaben von Wrappern und deren momentane Erstellung. Zum Abschluß
des Kapitels werden die Probleme bei der bisherigen Wrappererstellung aufgeführt.
2.1 Aufbau von digitalen Bibliotheken
Digitale Bibliotheken stellen Daten in elektronischer Form zur Verfügung. Diese Informationen
können mit verschiedenen Suchfunktionen abgerufen werden. Die Darstellung
der Informationen, z. B. von Volltexten, ist ebenfalls möglich. Dabei kann der Zugriff
kostenpflichtig oder auf bestimmte Benutzergruppen beschränkt sein. Im folgenden ist
nur die Suche relevant. Eine Vielzahl der Angebote steht im Internet zur freien Verfügung.
Bei digitalen Bibliotheken handelt es sich um semistrukturierte Quellen. Darunter versteht
man Quellen, die nicht auf einer definierten Grammatik oder einem Schema basieren,
die aber über eine implizite Grammatik verfügen. Diese Grammatik ermöglicht
es, die relevanten Informationen aus der Bibliothek zu entnehmen.
Bei der Suche in einer digitalen Bibliothek wird ein Formular verwendet (s. Abb. 2.1).
Darin sind die Suchkriterien anhand der Namensbeschreibung der suchbaren Attribute
einzutragen. Je nach Formular können auch mehrere Attribute angegeben werden, die
entweder mit fest definierten oder vom Benutzer ausgewählten boolschen Operatoren zu
4

KAPITEL 2. INFORMATIONSSUCHE IN DIGITALEN BIBLIOTHEKEN
Abbildung 2.1: Suchformular einer digitalen Bibliothek
Quelle: http://www.kfki.hu/~arthp/index1.html
5

KAPITEL 2. INFORMATIONSSUCHE IN DIGITALEN BIBLIOTHEKEN
verknüpfen sind. Teilweise kann in diesen Anfrageformularen auch die Form der Ergebnisseiten
festgelegt werden. Dies gilt z. B. für die Anzahl der pro Seite anzuzeigenden
Ergebnisse. Nach dem Abschicken eines Formulars wird in der Datenbank der digitalen
Bibliothek gesucht, wobei z. B. CGI-Skripte oder Servlets zum Einsatz kommen. Bei
erfolgreicher Suche gelangt der Benutzer zu den Ergebnisseiten. Diese lassen sich in
Übersichtsseiten und Detailseiten gliedern.
Auf der Übersichtsseite (s. Abb. 2.2) werden mehrere Ergebnisse in Kurzform untereinander
angezeigt. Meistens erfolgt die Darstellung der Ergebnisse in einer Tabellenoder
Listenstruktur. Dabei handelt es sich um Informationstupel, die weitestgehend dieselbe
Struktur aufweisen. Dazu gehört auch ein Link zu weiteren Details, sofern mehr
Informationen zu diesem Ergebnis verfügbar sind. Die einzelnen Kurzinformationen zu
einem Ergebnis werden hier häufig innerhalb einer Zeile angezeigt. Um die Darstellung
der Ergebnisse übersichtlicher zu gestalten, werden die einzelnen Attribute dabei häufig
durch Satzzeichen (z. B. Kommata) oder optisch (z. B. durch Fett- oder Kursivschrift)
getrennt. Es kann aber auch vorkommen, daß vor den Attributen Text enthalten ist,
der das Attribut kennzeichnet. Dies kann z. B. der Name des Attributes sein:
Author: Fuhr
Title: Information Retrieval
In solchen Fällen wird oft auf die optische Hervorhebung verzichtet.
Im Gegensatz zur Übersichtsseite sind auf einer Detailseite (s. Abb. 2.3) nur Informationen
zu einem einzelnen Ergebnis dargestellt. Dabei sind die Informationen ausführlicher.
So handelt es sich hier häufiger auch um Fließtexte oder Bilder. Die Trennung der einzelnen
Einträge erfolgt auf der Detailseite neben den Tabellen und Listen, auch häufig
einfach durch Zeilenumbrüche. Deutlich seltener als auf der Übersichtsseite sind auf der
Detailseite mehrere Informationen in einer Zeile zu finden.
2.2 Vorstellung des MIND-Projektes
Digitale Bibliotheken stehen im Internet in großer Anzahl zur Verfügung. Probleme bei
deren Nutzung ergeben sich vor allem bei der Auswahl der passenden Bibliothek, weil
die Parameter für die Bewertung der einzelnen Bibliotheken nicht bekannt sind. Das
MIND-Projekt behebt die Probleme, die bei der Nutzung von heterogenen, verteilten
digitalen Bibliotheken entstehen [NF03b].
Das System setzt sich dabei aus mehreren Komponenten zusammen, die aufeinander
aufbauen. Die MIND-Architektur ist in Abbildung 2.4 dargestellt. Die Anfragen stellt
6

KAPITEL 2. INFORMATIONSSUCHE IN DIGITALEN BIBLIOTHEKEN
Abbildung 2.2: Übersichtsseite einer digitalen Bibliothek
Quelle: http://www.kfki.hu/~arthp/index1.html
7

KAPITEL 2. INFORMATIONSSUCHE IN DIGITALEN BIBLIOTHEKEN
Abbildung 2.3: Detailseite einer digitalen Bibliothek
Quelle: //www.kfki.hu/~arthp/index1.html
8

KAPITEL 2. INFORMATIONSSUCHE IN DIGITALEN BIBLIOTHEKEN
User Interface
Dispatcher
Wrapper 1 Wrapper 2
DL 1 DL 2
Abbildung 2.4: MIND-Architektur
Quelle: [NF03b]
der Anwender an das Benutzerinterface. Dieses Interface leitet die Anfrage an einen Vermittler,
den sog. Dispatcher, weiter. Anhand von Güteparametern, wie z. B. Quantität,
Qualität und Relevanz, wählt der Dispatcher die passenden Bibliotheken aus. Die dazugehörigen
Wrapper stellen letztendlich die Anfrage an die ausgewählten Bibliotheken
und übergeben die Ergebnisse an den Dispatcher. Dieser faßt die Ergebnisse zusammen
und überführt sie in ein einheitliches Format. Das Resultat der Suche wird dann im
Benutzerinterface angezeigt.
2.3 Wrapperarchitektur in MIND
2.3.1 Aufgaben eines Wrappers
Grundlage eines jeden Wrappers ist die Annahme, daß die Daten automatisch aus einer
Datenbank bzw. aus den XML(Extended Markup Language)-Dokumenten generiert
werden, weshalb der Seitenaufbau eine gewisse Regelmäßigkeit besitzt. Wrapper sollen
die ursprünglichen Informationen aus den Datenbanken bzw. aus den XML-Dokumenten
wieder herstellen. Die Informationen werden also zunächst mit einer Funktion von der
Datenbank auf die HTML-Seiten abgebildet. Der Wrapper stellt nun die Umkehrfunktion
dar, der die Informationen aus der HTML-Seite auf ein XML-Format abbildet.
9

KAPITEL 2. INFORMATIONSSUCHE IN DIGITALEN BIBLIOTHEKEN
Ein Wrapper soll aus einer Webseite einer digitalen Bibliothek Informationen gemäß
einer vorher spezifizierten Anfrage herausfiltern. Dazu stellt ein Benutzer mit Hilfe des
Formulars auf der Webseite der digitalen Bibliothek eine Anfrage an die Webseite. Die
meisten Webseiten liegen im HTML-Format vor. Darüber hinaus existieren auch digitale
Bibliotheken, die das Anfrageergebnis im XML-Format zurückliefern. Weil die
Markupsprache XML die Semantik des Textes mit enthält, entfallen die im folgenden
beschriebenen Probleme, weshalb sie nicht weiter betrachtet werden. Das Ergebnis der
Anfrage ist zunächst eine Übersichtsseite (s. 2.1). Diese kann auf weitere Übersichtsseiten
verweisen.
Die Übersichtsseiten enthalten die URLs(Uniform Resource Locator) zu den einzelnen
Detailseiten sowie nähere Informationen zu den Ergebnissen. Der Wrapper muß als
erstes diese Übersichtsseite parsen und die dort verfügbaren Ergebnisse lokalisieren und
anschließend herausfiltern. Gleiches gilt für die Detailseite, falls bei der Anfrage nicht
nur eine Zusammenfassung, sondern das komplette Ergebnis gewünscht wurde. Die so
gewonnenen Daten werden danach an andere Anwendungen zur weiteren Verarbeitung
übergeben.
2.3.2 Informationsgewinnung von Wrappern
Systeme zur Wrapperinduktion nutzen Layoutinformationen von Webseiten, um Datenextraktionsregeln
zu erstellen und sind deswegen anfällig bei Layoutänderungen durch
ein Neudesign der Seiten. Es kann vorkommen, daß ein Wrapper zwar weiterhin Daten
extrahiert, diese aber nun fehlerhaft sind. Eine Änderung der Ausgabe des Wrappers
ist allerdings auch aufgrund von Formatänderungen möglich. Ein Beispiel hierfür ist die
Darstellung von Währungsangaben bei Preisen nach der Umstellung auf Euro.
Die Wrapper für das MIND-Projekt sind in der Programmiersprache Java geschrieben,
für die es eine große Anzahl von frei verfügbaren Bibliotheken gibt. Das Ergebnis einer
Anfrage an MIND wird im XML-Format gespeichert. Bei XML handelt es sich um eine
Metasprache, mit der Dokumenttypen definiert werden können [McL]. Eine Dokumenttypdefinition
(DTD) definiert Regeln, die für ein XML-Dokument dieses Typs gelten
müssen. Die DTD legt somit fest, welche Elemente in einem XML-Dokument enthalten
sein dürfen. Dabei können die Elemente anhand gewisser Regeln selbst definiert werden.
Die Markupsprache XML zeichnet sich insbesondere durch eine Trennung von Logischer
und Layout-Struktur aus. XML ermöglicht eine Serialisierung von strukturierten Datenbeständen.
Durch die in XML enthaltene logische Struktur ist es leicht möglich, die
gefundenen Informationen strukturiert abzuspeichern und zu einem späteren Zeitpunkt
wieder darauf zuzugreifen.
10

KAPITEL 2. INFORMATIONSSUCHE IN DIGITALEN BIBLIOTHEKEN
Jeder MIND-Wrapper basiert auf einem MIND-Schema [NF03a]. Das Schema gibt an,
welche Attribute als Informationen aus den Webseiten der zugrundeliegenden Bibliothek
herausgezogen werden können. Ein Schema-Attribut wird durch einen Namen (z. B.
Author), einen Datentyp (z. B. Text oder Date) und einen Medientyp (z. B. Text oder
Image) beschrieben. Darüber hinaus enthält jedes Schema eine Liste von Prädikaten,
die auch leer sein kann. Enthält die Liste jedoch Prädikate, so ist eine Suche nach
diesem Schema-Attribut möglich und die Liste gibt an, welche Prädikate bei der Suche
zugelassen sind. Die möglichen Prädikate für ein Schema-Attribut werden dabei durch
dessen Datentyp festgelegt.
Beispiele für Prädikate wären z. B. exact und stemming für Schema-Attribute vom
Datentyp String. Dabei bedeutet exact, daß eine genaue Übereinstimmung für eine
erfolgreiche Suche notwendig ist. Dagegen gibt das Prädikat stemming an, daß lediglich
eine identische Stammform erforderlich ist. Zusätzlich gibt es noch eine Beschreibung,
die allerdings für den MIND-Wrapper selbst keine Bedeutung hat, sondern lediglich eine
kurze Information über das Schema-Attribut darstellt.
Um die HTML-Seiten besser parsen zu können, werden sie vom Wrapper zunächst in
XHTML(Extensible HyperText Markup Language) umgewandelt. Dieses Format hat
den Vorteil, daß es konform zu XML ist, weil es den Syntaxregeln von XML entspricht.
Dadurch können XTHML-Dokumente mit den Standard-Werkzeugen für XML betrachtet,
bearbeitet und validiert werden. 1 Dazu gehören auch die für XML verfügbaren
Java-Klassen.
Zur Selektion der Information aus einer Webseite benutzen die Wrapper XPath(XML
Path Language)-Ausdrücke. XPath erzeugt ein XML-Dokument als Baumstruktur. Mit
Hilfe von XPath-Ausdrücken kann ein Knoten in einem XML-Dokument gefunden werden
und sein Inhalt extrahiert werden. Dazu ist es möglich, die Lage in Abhängigkeit zu
anderen Knoten anzugegeben. Generell existiert ein Unterschied zwischen einer Adressierung
mit absoluten und relativen Pfadausdrücken. Absolute XPath-Ausdrücke beginnen
mit dem Wurzelknoten, während ein relativer XPath-Ausdruck immer bei dem
gerade aktuellen Knoten, dem sog. Kontextknoten, mit der Suche beginnt. Jeder Knoten
kann dann durch seine Position im Baum angesprochen werden. Der folgende XPath-
Ausdruck selektiert z. B. in einem Buch im 2. Kapitel im 4. Abschnitt den 17. Absatz
[Mün].
//buch/kapitel[2]/abschnitt[4]/absatz[17]
Fehlen die Positionsangaben so wird jeweils das erste Element selektiert.
1 s. http://www.w3.org/TR/2000/REC-xhtml1-20000126/
11

KAPITEL 2. INFORMATIONSSUCHE IN DIGITALEN BIBLIOTHEKEN
XPath bietet darüber hinaus noch eine Funktionsbibliothek an, mit deren Hilfe eine
nähere Spezifizierung des gesuchten Knotens möglich ist. Den Funktionen müssen teilweise
noch Argumente übergeben werden, damit sie ihre Aufgabe wahrnehmen können.
z. B. kann mit der Funktion contains() überprüft werden, ob der selektierte Knoten
eine Zeichenkette enthält.
//b[contains(.,’author’)]
Mit der Hilfe von Funktionen ist es möglich, anzugegeben, an welcher Position in Abhängigkeit
zu einem Bezugsknoten ein zu selektierendes Element stehen soll. So können
z. B. ausgehend von einem Knoten der erste Geschwisterknoten und, falls es sich um eine
Iteration handelt, sogar alle nachfolgenden Geschwisterknoten mit Hilfe eines XPath-
Ausdrucks extrahiert werden. Des weiteren kann ein Knoten ausgewählt werden, der
einen bestimmten String enthält.
2.4 Herkömmliche Erstellung/Pflege von Wrappern
Nachdem im letzen Abschnitt die Architektur von Wrappern erläutert wurde, befaßt sich
der folgende Teil mit der bisherigen Wrappererstellung und Überarbeitung eines nicht
mehr funktionierenden Wrappers. Daran schließt sich eine Beleuchtung der Probleme
an, die sich aus dieser Vorgehensweise ergeben.
2.4.1 Bisheriges Verfahren
Es existieren 3 Möglichkeiten bei der Erstellung eines Wrappers [Bir]:
• manuell: Bei einer manuellen Erstellung wird die für eine Anfrage zurückgelieferte
Webseite vom Programmierer analysiert und der Wrapper von Hand erstellt,
• semiautomatisch: Bei der semiautomatischen Vorgehensweise wird einem Tool gezeigt,
wo die zu selektierenden Informationen aufzufinden sind. Mit Hilfe dieser
Informationen erstellt das Tool dann den Wrapper. Dieser findet danach automatisch
die Struktur, mit der die Informationen selektiert werden können,
• automatisch: Bei der automatischen Wrappergenerierung kommen Methoden des
maschinellen Lernens zum Einsatz. Damit wird der Wrapper automatisch anhand
von vorliegenden Beispieltexten erstellt.
12

KAPITEL 2. INFORMATIONSSUCHE IN DIGITALEN BIBLIOTHEKEN
Die Entwicklung der Wrapper für MIND erfolgt bisher manuell. Um einen Wrapper
zu erzeugen, ist zunächst ein MIND-Schema (s. 2.3.2) zu schreiben. Dazu werden die
gewünschten Schema-Attribute aus den Ergebnisseiten festgelegt. Des weiteren werden
mit Hilfe des Anfrageformulars die Schema-Attribute bestimmt, nach denen eine Suche
möglich ist. Danach kann ein Grundgerüst für den Wrapper automatisch generiert
werden. In diesem Grundgerüst ist die Anfrage an die Webseite zu formulieren. Dazu
wird die HTML-Seite, die das Anfrageformular enthält, untersucht und festgestellt, aus
welchen Attributen die Anfrage bestehen muß. Im Wrappergrundgerüst wird die URL
mit den Attributen zusammengebaut.
Im Anschluß daran wird aus dem HTML-Code, den eine aufgerufene URL zurückliefert,
ein XHTML-Baum erzeugt. Anhand dessen geordneter Darstellung müssen die XPath-
Ausdrücke einschließlich der Iterationen manuell gefunden werden. Dabei wird zunächst
für jedes Ergebnis eine ID zur eindeutigen Identifizierung festgelegt. Dies ist bei den
MIND-Wrappern die URL der Detailseite. Danach ist ggf. eine Nachbearbeitung der
Ergebnisse erforderlich, falls der durch den XPath-Ausdruck selektierte Knoten nicht
gewünschte Zeichen enthält.
Abschließend ist dafür zu sorgen, daß nicht nur die Ergebnisse aus der ersten Übersichtsseite
aufgerufen werden, sondern auch, soweit vorhanden, die auf den darauffolgenden
Übersichtsseiten. Außerdem muß die gewünschte Anzahl an Ergebnissen zurückgeliefert
werden. Sind weniger Resultate gefunden worden als angefordert waren, dürfen natürlich
nur die angezeigt werden, die tatsächlich der Anfrage entsprechen.
Falls eine Überarbeitung des Wrappers erforderlich ist, müssen in dem relativ unübersichtlichen
Java-Code die XPath-Ausdrücke ausfindig gemacht und adaptiert werden.
Die Verwendung von XPath-Ausdrücken zum Parsen der Dokumente ist deutlich einfacher
und eleganter als der Durchlauf durch Dokumente mit dem Document Object
Model (DOM). Allerdings geht dies zu Lasten der Effizienz. Nach der Überarbeitung der
XPath-Ausdrücke sind ggf. Passagen im Java-Code zu überarbeiten, die überflüssigen
Text von den Schema-Attributen abtrennen.
2.4.2 Probleme
Das Problem bei der herkömmlichen Wrappererstellung besteht im hohen Aufwand,
sowohl beim Erstellen eines Wrappers für eine neue digitalen Bibliothek als auch bei
deren Pflege. Diese resultieren aus dem beträchtlichen manuellen Aufwand, der durch
das Parsen des HTML-Codes entsteht. Da HTML eine layoutorientierte Markupsprache
ist, die keinerlei Hinweise zur Semantik der darin enthaltenen Informationen enthält,
besteht das Problem vor allem darin, die gesuchten Informationen in der HTML-Seite zu
lokalisieren. Die Wrapper sind stark an das Layout einer Webseite gebunden, wodurch
13

KAPITEL 2. INFORMATIONSSUCHE IN DIGITALEN BIBLIOTHEKEN
schon kleine Layoutänderungen eine Überarbeitung des Wrappers erforderlich machen.
Die vorliegende Diplomarbeit wird sich mit diesem Problem auseinandersetzen und
versuchen, mit Hilfe mitgeloggter Daten von alten Anfragen semiautomatisch aus den
neuen HTML-Seiten wieder einen funktionierenden Wrapper zu erstellen.
14

Kapitel 3
Verwandte Arbeiten
Es existieren eine Reihe von Projekten, die sich mit der Wrapperinduktion beschäftigen.
Dagegen befassen sich mit der Wrapperpflege nur einzelne Arbeiten. Um Ideen für
ein eigenes Wrapperwerkzeug zu entwickeln, wurde zunächst anhand von ausgewählten
Arbeiten die Vorgehensweise beim Aufbau der Anfrage bzw. bei der Wrappererstellung
und -pflege aufgezeigt.
3.1 ShopBot
An der Universität von Washington wurde von Doorenbos, Etzioni und Weld der Agent
ShopBot zum Preisvergleich beim Online-Shopping entwickelt [DEW97]. Der Agent soll
zu einem bestimmten Produkt Webseiten finden, auf denen dieses Produkt erhältlich
ist. Der ShopBot Agent besteht aus zwei Komponenten: einer Lernkomponente und
einer Shopping-Komponente. Die Lernkomponente benötigt als Eingabe die Webseiten
von mehreren Online-Händlern. Der ShopBot erfaßt daraufhin automatisch offline
die Struktur, die sog. Vendor Description, nach der bei diesen Händlern ein Einkauf
abgewickelt wird. Die Lernphase des ShopBot muß für jeden Online-Händler lediglich
einmal durchlaufen werden. Dabei wird ein Wrapper erstellt, der die gewünschten Daten
aus der Webseite herausfiltert. Die Shopping- oder Vergleichsphase ruft dann die Beschreibungen
für die verschiedenen Online-Händler auf und vergleicht deren Ergebnisse
miteinander. Die zweite Phase stellt somit die eigentliche Nutzung dar.
15

KAPITEL 3. VERWANDTE ARBEITEN
3.1.1 Grundlagen
Für den Vergleich von Einkaufspreisen hat der ShopBot zu einem Anbieter folgende
Informationen zur Verfügung:
• eine Beschreibung der Domain, die Informationen über die Produktattribute zur
Verfügung stellt. Mit Hilfe dieser Beschreibung können verschiedene Produkte
sowie Varianten desselben Produkts unterschieden werden,
• eine Liste von URLs möglicher Anbieter,
• ein Attribut A, wie z. B. den Preis, anhand dessen der Benutzer die Anbieter
vergleichen möchte,
• eine Spezifikation des gewünschten Produktes mit Termen für die Werte der ausgewählten
Attribute.
Der ShopBot soll dann die Anbieter bestimmen, bei denen das gewünschte Produkt
verfügbar ist. Dabei werden die Anbieter anhand von Attribut A sortiert. Wird z. B.
nach dem billigsten 17-Zoll-Monitor gesucht, ist nach dem Preis zu sortieren.
Grundlage des ShopBot sind folgende Gesetzmäßigkeiten bei der Gestaltung der Webseiten:
• Online-Shops werden so gestaltet, daß die Benutzer die Produkte schnell finden
können,
• damit die Benutzer die Seiten als zusammengehörig wahrnehmen, bevorzugen die
Anbieter eine jeweils eigenständige und einheitliche Gestaltung der Webseiten,
• um dem Käufer das Verständnis der Kataloge zu erleichtern, werden Leerzeichen
benutzt.
3.1.2 Produktunabhängige Architektur
Die Architektur des ShopBots ist dabei unabhängig vom Produkt. Um eine neue Domain
in den Vergleich mit einzubeziehen, ist lediglich eine Beschreibung für die Domain
erforderlich. Die hierin enthaltene Beschreibung läßt sich in drei Kategorien einteilen:
• eine Beschreibung der Attribute eines Produkts, z. B. Produktname, Hersteller
und Preis,
16

KAPITEL 3. VERWANDTE ARBEITEN
DOMAIN
DESCRIPT
URLs of
POSSIBLE
VENDORS
SHOPBOT LEARNER
For each vendor
Search for indices
For each potential index
For each sample product
Query on attributes
Accumulate responses
Analyze
Product attributes
Result of search
ONLINE
VENDORS
VENDOR
DESCRIPT
Abbildung 3.1: Lernmodul des ShopBot
Quelle: [DEW97]
• eine Heuristik, um die Webseiten der Anbieter zu verstehen. Hier werden reguläre
Ausdrücke benutzt, um die Attribute auf den Anbieterseiten zu lokalisieren,
• das Wissen, wie eine Webseite geladen wird. Hierzu werden Test-Anfragen mit
beliebten Produkten gestellt.
Mit Hilfe dieser Beschreibung ist der ShopBot in der Lage, Preisvergleiche durchzuführen.
17

KAPITEL 3. VERWANDTE ARBEITEN
3.1.3 Erstellung der Anbieterbeschreibung
Eine besondere Neuentwicklung beim ShopBot ist das Lernmodul ( s. Abb. 3.1). Es erstellt
automatisch eine Beschreibung für Online-Händler, die dem System nicht bekannt
sind. Bei der Entwicklung der Anbieterbeschreibung existieren drei Probleme:
• die Identifizierung eines geeigneten Suchformulars,
• die Entscheidung, wie dieses Formular auszufüllen ist,
• die Feststellung, in welchem Format die Produktbeschreibungen auf der Ergebnisseite
vorliegen.
Diese drei Probleme bauen aufeinander auf. Demzufolge zieht z. B. eine fehlerhafte
Entscheidung bei der Identifizierung des Suchformulars Fehler bei den nachfolgenden
Entscheidungen nach sich.
Eine Anbieterbeschreibung muß folgende Informationen enthalten:
• die URL der Seite, die das Anfrageformular enthält,
• eine Funktion, die die Produktattribute auf die Felder des Formulars abbildet,
• Funktionen, die die Produktinformationen einer Seite extrahieren können.
Zunächst versucht das Lernmodul, auf der gegebenen Domain HTML-Formulare zu finden,
die für die Anfrage geeignet sind. Dazu werden alle Links rekursiv nach Formularen
durchsucht. Für jedes dieser Formulare wird daraufhin die Wahrscheinlichkeit geschätzt,
ob es die Informationen für den gewünschten Preisvergleich zur Verfügung stellen kann.
Dazu muß allerdings ermittelt werden, wie die Formulare auszufüllen sind.
Die Suche nach dem richtigen Formular gliedert sich in drei Teilprobleme:
• Zunächst wird mit Hilfe eines Dummys für einen Produktnamen herausgearbeitet,
welche Seite zurückgeliefert wird, wenn zu der Suchanfrage keine Produkte
gefunden werden können. Die meisten Webservices liefern hierfür eine Standardfehlerseite.
• Anschließend werden mit Hilfe der Formulare Test-Anfragen nach beliebten Produkten
gestellt, wobei das Lernmodul entscheiden muß, wie das einzelne Formular
auszufüllen ist. Dazu wird die Domainbeschreibung herangezogen. Die zur
Auswahl stehenden Formulare werden nun mit Test-Anfragen geprüft und das
18

KAPITEL 3. VERWANDTE ARBEITEN
Ergebnis wird mit dem Template für fehlende Ergebnisse verglichen. Liefert der
überwiegende Teil der Anfragen für ein Formular keine Ergebnisse, schließt das
Lernmodul daraus, daß das Formular nicht für die Produktsuche geeignet ist.
• Darauf folgt eine Analyse der Produktbeschreibungen. Dazu werden die positiven
Anfragen als Trainingsdaten benutzt. Auf der Ergebnisseite sind ein oder mehrere
Produktbeschreibungen enthalten, die der Anfrage entsprechen. Jede dieser
Produktbeschreibungen enthält Informationen zu einem speziellen Produkt. Danach
wird nach einem Template gesucht, das aus nicht relevanten Teilen besteht,
die sich im Kopf- oder Fußbereich befinden und auf allen Ergebnisseiten identisch
sind. Dies gilt z. B. häufig für die Seitennavigation.
Auf Basis dieser Grundlagen geht das Lernmodul davon aus, daß jede Beschreibung
mit einer neuen Zeile beginnt. Deswegen wird der HTML-Code zunächst in logische
Zeilen unterteilt, die nur durch Leerzeichen gegliedert sind. Zu den Grundannahmen
gehört ebenfalls, daß jedes Produkt im selben Format dargestellt wird. Deswegen wird
für jede logische Zeile eine Zeilenbeschreibung erstellt, indem die Argumente aus dem
HTML-Element entfernt und alle durch dieselbe Variable ersetzt werden, z. B.
texttexttext
Zum Schluß benutzt das Lernmodul einen heuristischen Ranking-Prozeß, um die Zeile
auszuwählen, die am wahrscheinlichsten nach einer Produktbeschreibung aussieht. Diese
Heuristik nutzt die Tatsache aus, daß die Test-Anfragen für beliebte Produkte sind und
die Anbieter in der Regel verschiedene Versionen eines Produktes vorrätig haben. Das
führt zu einer Fülle von Produktbeschreibungen auf einer erfolgreichen Seite.
Das Lernmodul wiederholt die beschriebene Prozedur mit jedem Formular. Anhand dieser
Ergebnisse wird dann für die einzelnen Formulare geschätzt, wie erfolgreich sie beim
Vergleich von Produkten sind. Als Parameter wird die Zeilenbeschreibung, die für die
entsprechende Ergebnisseite ausgewählt wurde, mit in die Berechnung einbezogen. Nach
der Bestimmung des Formulars mit dem besten Ranking wird die Anbieterbeschreibung
erstellt. Hierfür benötigt das Lernmodul normalerweise 5 - 15 Minuten.
3.1.4 Shopping-Modul
Das Shopping-Modul ist im Gegensatz zum Lernmodul auf häufige Aufrufe von verschiedenen
Nutzern ausgerichtet. Hat das Shopping-Modul über die GUI(Graphical User
Interface) eine Anfrage erhalten, füllt es für jeden Webservice das Formular aus und
übermittelt es. Bei jeder nicht leeren Ergebnisseite werden daraufhin Kopf- und Fußteil
19

KAPITEL 3. VERWANDTE ARBEITEN
entfernt. Der verbliebene HTML-Code wird daraufhin überprüft, ob das gelernte Format
der Produktbeschreibung darin enthalten ist. Die auf diese Weise erzielten Ergebnisse
werden sortiert und dem Benutzer zusammengefaßt ausgegeben.
3.1.5 Fazit zum ShopBot
Der Vorteil beim ShopBot ist, daß er keine anspruchsvolle Prozessierung der natürlichen
Sprache benötigt, um die Performance zu erreichen. Dabei braucht er lediglich ein geringes
Wissen über die einzelnen Produktdomains. Allerdings wurden dafür zahlreiche
Einschränkungen gemacht. Die produktunabhängige Architektur des ShopBot läßt sich
auch bei MIND wiederfinden, weil lediglich eine Wrapperbeschreibrung erforderlich ist,
um eine neue digitale Bibliothek bei der Suche in MIND mit einzubinden.
Im Prinzip sind die zwei Phasen des ShopBot ebenfalls beim MIND-Projekt zu finden.
Die Lernphase, in der die Vendor Description erstellt wird, entspricht der Phase, in
der beim MIND-Projekt die Erstellung eines Wrappers erfolgt. Allerdings werden die
Wrapper momentan noch überwiegend manuell erstellt. Mit dem geplanten Wrappertool
wäre dieser Schritt dann zumindest semiautomatisch und somit vergleichbar. Zu
den Auswirkungen von Layoutänderungen in der Shopping-Phase konnten keine Informationen
gefunden werden. Allerdings ist davon auszugehen, daß diese Problematik der
eines gebrochenen Wrappers entspricht und eine Überarbeitung der Anbieterbeschreibung
erfordert.
Die Shopping-Phase ist vergleichbar mit der Nutzungsphase beim MIND-Projekt. Statt
verschiedener Preise werden beim MIND-Projekt die zu einer Anfrage gesammelten Informationen
dargestellt, damit für Nutzer eine Vergleichsmöglichkeit besteht. Die Webseiten
der digitalen Bibliotheken in MIND, zumindest die im folgenden betrachteten,
liegen im HTML-Format vor. Die Grundannahmen zur Gestaltung von Webseiten, die
dem ShopBot zugrunde liegen, gelten auch für digitale Bibliotheken.
Bei der Erstellung der Anbieterbeschreibung hängen die Suche nach dem richtigen Anfrageformular
und die Identifizierung der Produktinformationen voneinander ab. Da
bei der Pflege von MIND-Wrappern mitgeloggte Ergebnisse zur Verfügung stehen, ist
in diesem Fall eine separate Betrachtung der Probleme möglich, weil die erstellte Anfragestruktur
anhand der vorhandenen Ergebnisse überprüft werden kann. Dabei muß
lediglich festgestellt werden, ob mitgeloggte Ergebnisse auf der mit der Anfragestruktur
erreichten Seite enthalten sind. Dies erfordert noch keine Beschreibung der Ergebnisse.
Aufgrund der überwiegend manuellen Erstellung von MIND-Wrappern erfolgt bei der
bisherigen Vorgehensweise ebenfalls eine schrittweise Erstellung des Wrappers.
Die Annahmen zu den nicht relevanten Teilen im Kopf- und Fußbereich einer Webseite
20

KAPITEL 3. VERWANDTE ARBEITEN
gelten auch für digitale Bibliotheken. Deswegen sollte die Suche nach einem Template
in dem zu erstellten Wrappertool ebenfalls erfolgen.
3.2 Wrapper Maintenance
Lerman, Minton und Knoblock haben sich mit der Pflege von Wrappern befaßt [Usc].
Diese teilen sie in die zwei Bereiche „Verifikation“ und „Reinduktion“ ein. Die Verifikation
bemerkt, wenn der Wrapper gebrochen ist. Die Reinduktion übernimmt daraufhin die
Überarbeitung des Wrappers. Abb. 3.2 stellt den sich daraus ergebenden Lebenszyklus
eines Wrappers dar.
Ein Wrapperinduktionssystem bekommt Webseiten zusammen mit den Beispieldaten,
die extrahiert werden sollen. Erstellt wird dann ein Wrapper, der angibt, wie die gesuchten
Daten zu lokalisieren sind. Mit Hilfe dieses Wrappers können dann Daten selektiert
werden. In regelmäßigen Zeitabständen kommt die Verifikation von Wrappern zum Einsatz.
Sie testet anhand der vorliegenden Beispieldaten, ob der Wrapper noch korrekt
arbeitet. Ist dies nicht der Fall, wird automatisch die Reinduktion in Gang gesetzt und
anhand der Beispieldaten ein neuer Wrapper erstellt.
Dieser Ansatz arbeitet bei der Erstellung von Wrappern auf Wort- bzw. Tokenebene.
Die Token bestehen aus einem Alphabet, das sich aus verschiedenen Typen von Zeichen
zusammensetzt. Dazu gehören z. B. Buchstaben, Zahlen und Satzzeichen. Anhand der
Zeichentypen werden die Token in syntaktische Kategorien eingeteilt, die eine Hierarchie
bilden (s. Abb. 3.3). Die Einteilung in die Kategorien läßt Rückschlüsse auf die
Informationen zu, die das Token enthält. So ist z. B. eine fünfstellige Zahl häufig eine
Postleitzahl.
Um die Struktur eines Daten- bzw. Formularfeldes zu erfassen, werden nur die Muster
am Anfang und am Ende des Datenfeldes, dem sog. Datenprototyp, untersucht. Gerade
an diesen Positionen treten die meisten Gesetzmäßigkeiten auf. Anhand von positiven
Beispielen wird eine charakteristische Beschreibung oder ein Muster gelernt. Mit Hilfe
von Hypothesen wird getestet, ob dieses Muster gültig ist. Dazu wird der DataProG-
Algorithmus eingesetzt. Dieser findet statistisch signifikante Muster in einer Menge von
Tokensequenzen. Dazu wird der Text mit dem DataProG-Algorithmus in Token zerlegt.
Diese werden in syntaktische Kategorien eingeteilt. Die Muster werden in einem
Präfixbaum codiert (s. 3.4), indem jeder Knoten für einen Tokentyp steht.
Der DataProG-Algorithmus arbeitet mit Signifikanzbeurteilungen, um dem Baum Knoten
hinzuzufügen oder sie zu entfernen. Jeder Pfad beginnt beim Wurzelknoten und
entspricht einem gültigen Muster, das vom Algorithmus gefunden wurde. In der ersten
21

KAPITEL 3. VERWANDTE ARBEITEN
Pages to
be labeled
GUI
Web
pages
Labeled
Web pages
Wrapper
Induction
System
Wrapper
Extracted
data
Change
detected
Automatic
Re-labeling
Wrapper
Verification
Reinduction System
Abbildung 3.2: Lebenszyklus eines Wrappers
Quelle: [Usc]
22

KAPITEL 3. VERWANDTE ARBEITEN
TOKEN
PUNCT
ALPHANUM
HTML
ALPHA
NUMBER
UPPER LOWER SMALL MEDIUM LARGE
ALLCAPS
1Digit 2Digit 3Digit
CA
Boulevard
310
Abbildung 3.3: Auszug aus der syntaktischen Hierarchie der Tokentypen
Quelle: eigene Darstellung nach [Usc]
Phase wächst der Baum schrittweise, indem alle signifikanten Spezialisierungen gesucht
werden. Die weniger signifikanten Muster derselben Länge werden dann wieder aus dem
Baum entfernt. Im letzten Schritt sind dann alle verbliebenen signifikanten Muster des
Baumes zu extrahieren. Abb. 3.4 enthält einen Baum, der die Struktur von Adressen
beschreibt. Dabei bilden die Knoten mit den gestrichelten Linien weniger signifikante
Muster. Deswegen sind sie wieder aus dem Baum zu entfernen.
3.2.1 Verifizierung von Wrappern
Das System zur Verifizierung nutzt mitgeloggte Daten von alten Anfragen, bei denen sicher
ist, daß sie korrekt extrahiert wurden. Die Anfragen zu diesen Daten werden an die
geänderte Webseite gestellt. Die zurückgelieferten Ergebnisseiten dienen als Trainingsbeispiele.
Für jedes Feld der Trainingsbeispiele wird mit dem Algorithmus ein Vektor ⃗ k
berechnet. Dieser berücksichtigt den häufigsten Anfang bzw. das häufigste Ende. In der
Verifikationsphase wird nun anhand von neuen Testdaten auf die gleiche Weise ein zweiter
Vektor ⃗r berechnet. Wenn die beiden Vektoren ⃗ k und ⃗r statistisch übereinstimmen,
arbeitet der Wrapper noch korrekt. Andernfalls ist die Überprüfung fehlgeschlagen.
Für jeden Wrapper erfolgt etwa einmal pro Woche eine Speicherung der Ergebnisse von
15-30 Fragen. Die neuen Ergebnisse werden mit den richtigen Ausgaben der Wrapper
verglichen.
23

KAPITEL 3. VERWANDTE ARBEITEN
ROOT
NUMBER
UPPER
ALPHANUM ALPHA
UPPER Boulevard Street
Abbildung 3.4: Musterbaum, der die Struktur von Adressen beschreibt
Quelle: eigene Darstellung nach [Usc]
3.2.2 Wrapper-Reinduktion
Stellt das Verifikationsystem fest, daß der Wrapper nicht mehr korrekt arbeitet, wird
direkt das System zur Reinduktion aufgerufen. Dieses basiert auf der Annahme, daß
sich das Format der Daten nicht geändert hat. Viele Seiten benutzen Templates, die
nur noch mit den Ergebnissen einer Datenbankabfrage ausgefüllt werden, um Webseiten
automatisch zu generieren. Demzufolge sind die Daten nicht im Template enthalten. Der
Algorithmus für die Ermittlung des Templates sucht nach allen Sequenzen von Token,
die auf jeder Seite genau einmal vorkommen und mindestens drei Token enthalten.
Im Reinduktionsalgorithmus werden zunächst mit dem DataProGAlgorithmus die Startund
Endmuster gelernt, die die Trainingsbeispiele beschreiben. Als Trainingsbeispiele
werden noch richtig extrahierte mitgeloggte Daten benutzt. Mit diesen Mustern werden
mögliche Datenfelder in der neuen Seite identifiziert. Zusätzlich wird noch die durchschnittliche
Anzahl der Token in den Trainingsdaten bestimmt. Für jede neue Seite
wird nun überprüft, ob sie mit einem der Muster beginnt bzw. endet. Textsegmente, die
deutlich von der berechneten durchschnittlichen Anzahl der Token abweichen, finden
dabei keine Berücksichtigung.
Die gelernten Muster sind allerdings oft zu allgemein. Um dieses Problem zu minimieren,
werden von vornherein Annahmen über die Struktur von Webseiten getroffen.
24

KAPITEL 3. VERWANDTE ARBEITEN
Man geht davon aus, daß Beispiele für dasselbe Datenfeld auf jeder Seite annähernd
an derselben Position und im selben Zusammenhang stehen. Außerdem wurde bereits
angenommen, daß die Informationen nicht im Template zu finden sind. Deswegen sind
Kandidaten, die Teile des Templates extrahieren, auszuschließen. Eine gegebene Information
ist entweder immer für den Benutzer sichtbar, oder sie ist immer unsichtbar.
Letzteres trifft ein, wenn die Information ein HTML-Attribut ist. Deswegen erfolgt zusätzlich
zu jedem Kandidaten die Erstellung eines Vektors, der den Kontext und die
Position im Template bestimmt. Dazu wird noch festgehalten, ob der Kandidat für den
Benutzer sichtbar ist oder ob er Teil eines HTML-Elementes ist. Nachdem die Kandidaten
und die zugehörigen Vektoren bestimmt sind, erfolgt eine Einteilung in Gruppen.
Dabei werden die Extraktionskandidaten in einer Gruppe durch denselben zugehörigen
Vektor beschrieben.
Im folgenden werden die Gruppen nun anhand ihrer Ähnlichkeit zu den Trainingsdaten
bewertet. Die am höchsten bewertete Gruppe enthält vermutlich das richtige Beispiel
für das Datenfeld. Diese Methode setzt voraus, daß bei einer Layoutänderung ein Teil
der Daten unverändert bleibt. Dabei dürfen sich die Daten nicht, wie z. B. bei Wetterinformationen,
häufig ändern. Konnten für keine Gruppe Übereinstimmungen gefunden
werden, kommt die zweite Bewertungmethode zum Einsatz. Dabei ist die Gruppe mit
der größten Ähnlichkeit zu den Trainingsbeispielen zu suchen. Dabei basieren die Trainingsbeispiele
auf den aus den Trainingsdaten gelernten Mustern.
Zum Schluß des Reinduktionsprozesses werden die Extraktionen in der höchsten Rankinggruppe
durch den Einsatz des STALKER-Wrapper-Induktionsalgorithmus für die
neuen Webseiten unterstützt. Dieser Algorithmus lernt die Extraktionsregeln für die
neuen Seiten, wenn er die richtigen Beispiele für die Felder bekommt.
3.2.3 Fazit zur Wrapper Maintenance
Der vorgestellte Ansatz erzielt zwar recht gute Ergebnisse, die Entwicklung erfolgte allerdings
speziell für Detailseiten. Handelt es sich um Übersichtsseiten, so ist dieser Ansatz
deswegen nicht immer erfolgreich. Da im Rahmen des MIND-Projektes sehr häufig nur
die Übersichtsseiten aufgerufen werden, stellt dies einen entscheidenden Nachteil dar.
Das Ziel des vorgestellten Ansatzes ist nicht nur eine semiautomatische, sondern eine
automatische Wrapperpflege. Dabei berücksichtigt der Ansatz allerdings nur Layoutänderungen
und keine Modifizierung der Anfragen.
Trotzdem enthält der Aufbau mit den Stufen der Verifikation und der Reinduktion des
Wrappers Ideen, die im folgenden genutzt werden sollten. Bei den MIND-Wrappern stehen
auch mitgeloggte Daten zur Verfügung, somit kann ebenfalls ein Verifikationsmodul
zum Einsatz kommen. Allerdings ist der Vergleich von Mustern nicht erforderlich, weil
25

KAPITEL 3. VERWANDTE ARBEITEN
für MIND Methoden entwickelt wurden, um die mitgeloggten Daten im selben Format
aufzurufen, wie die gerade angefragten. Hierdurch wird die Verifikation erheblich
vereinfacht.
Bei der Reinduktion werden, wie bereits beim ShopBot, Templates identifiziert und von
der Suche ausgeschlossen. Diese sollten, wie bereits beim ShopBot erwähnt, auch bei
dem zu entwickelnden Wrappertool zum Einsatz kommen. Im Unterschied zum ShopBot
werden hier allerdings nicht nur identische Kopf- und Fußbereiche zum Template gezählt,
sondern jede Sequenz von mindestens drei Token, die genau einmal in jeder Seite
enthalten ist. Des weiteren gelten die Annahmen zur Struktur von Webseiten bezüglich
Position und Zusammenhang von Datenfeldern sowie zur Sichtbarkeit von Informationen
auch für digitale Bibliotheken. Weil MIND-Wrapper die Extraktion mit Hilfe von
XPath vornehmen, wird die konkrete Vorgehensweise allerdings anders als beim gerade
vorgestellten Ansatz sein.
3.3 Fazit zu verwandten Arbeiten
Der ShopBot hat durch seinen zweistufigen Aufbau mit der Erstellung der Anbieterbeschreibung
und der Nutzungsphase starke Ähnlichkeiten zum bisherigen Aufbau von
MIND. Durch das zu entwickelnde Wrappertool könnte dieser Aufbau um die Stufen der
Verifikation und Reinduktion ergänzt werden. Dabei werden sich diese beiden Stufen an
die Vorgehensweise des Ansatzes zur Wrapper Maintenance anlehnen.
Allerdings konnten, mit Ausnahme von Daffodil (s. 4.3) und MIND, keine Beispiele
gefunden werden, in denen die Wrapper mit XPath-Ausdrücken arbeiten. Dies ist ein
wesentlicher Unterschied zwischen dem zu bearbeitenden Problem und den betrachteten
Wrapperwerkzeugen.
Die Vor- und Nachteile der unterschiedlichen Vorgehensweisen der vorgestellten Ansätze
bei der Definition des Templates sind für das zu entwickelnde Reinduction-Tool noch
näher zu untersuchen (s. 5.3).
Die Schritte zur Identifizierung eines Suchformulars sowie die Prüfung, wie dieses auszufüllen
ist, können bei einem Tool zur Pflege von Wrappern sogar entfallen, wenn sich
nur das Layout der digitalen Bibliothek und nicht die Struktur der Anfrage geändert
hat.
26

Kapitel 4
Rahmen für das Wrapperwerkzeug
Um ein Werkzeug für semiautomatische Wrapperpflege zu entwickeln, ist zunächst einmal
festzustellen, welche Datengrundlagen bei der Überarbeitung eines Wrappers genutzt
werden könnten. Daran schließen sich einige Grundannahmen an, die die Aufgabe
klarer strukturieren. Des weiteren wird ein Tool vorgestellt, das bei der Erstellung eines
neuen Wrapperwerkzeugs in die Überlegungen miteinbezogen werden sollte.
4.1 Vorhandene Daten
MIND-Wrapper verwenden intern eine eigene Datenstruktur. Nach dem Laden der entsprechenden
Logdateien ist mit den für MIND entwickelten Methoden wieder ein Zugriff
auf die Datenstrukturen möglich. Das Logging der alten Anfragen und Ergebnisse erfolgt
bei MIND standardmäßig. Falls weitere Daten für die semiautomatischen Pflege notwendig
sind, ist eine entsprechende Erweiterung des Loggings möglich. Um den neuen
Wrapper zu erstellen, könnten so insgesamt folgende Datengrundlagen genutzt werden:
• Die alten Anfragen: Mit ihnen wurde nach den vorhandenen Dokumenten gefragt.
Durch die Anfragen könnte garantiert werden, daß die Test-Anfragen auch zu
verschiedenen Schema-Attributen gestellt werden. Auf diese Weise könnten auch
evtl. Unterschiede bei Anfragen nach verschiedenen Schema-Attributen Berücksichtigung
finden.
• Die URLs der alten Anfragen: Sie werden dazu benötigt, dieselben Anfragen an
die überarbeitete digitale Bibliothek zu stellen. Zwar könnten die URLs auch aus
dem alten Wrapper entnommen werden, allerdings liegt dieser im Java-Code vor.
27

KAPITEL 4. RAHMEN FÜR DAS WRAPPERWERKZEUG
Weil Java-Code zum einen schlecht zu parsen ist und zum anderen dabei der Zusammenbau
der URL nachträglich nachvollzogen werden muß, ist es einfacher, die
URL direkt zur Laufzeit mitzuloggen und diese in einer separaten Datei abzuspeichern.
• Die Ergebnisse der alten Anfrage: Diese sind von entscheidender Bedeutung, weil
sie bei gleicher Anfrage auch auf der neuen Seite zu finden sind (s. 4.2). Hierbei
handelt es sich entweder um Zusammenfassungen oder Dokumente. Unter Zusammenfassungen
sind in diesem Fall Daten zu verstehen, die ausschließlich von der
Übersichtsseite selektiert worden sind. Dagegen werden bei den Dokumenten auch
die Ergebnisse miteinbezogen, die auf der Detailseite zu finden sind.
• Der alten Wrapper: Dieser liegt in einem maschinenlesbarem Format vor. Der
alte Wrapper kann aufgrund der darin enthaltenen XPath-Ausdrücke von Nutzen
sein. Es ist zu überprüfen, ob zumindest noch ein Teil eines Ausdrucks wieder zu
verwerten ist.
Darüber hinaus enthält der Wrapper reguläre Ausdrücke, die auch daraufhin zu
prüfen sind, ob eine weitere Nutzung möglich ist. Falls innerhalb des Textknotens,
der durch den bereits gefundenen XPath-Ausdruck extrahiert wird, überflüssiger
Text enthalten ist, können die regulären Ausdrücke aus dem alten Wrapper auf
ihre Funktionstüchtigkeit getestet werden.
• Die zugehörigen alten HTML-Seiten: Aus ihnen geht die ehemalige Reihenfolge der
Schema-Attribute hervor. Daraus könnten evtl. Rückschlüsse auf die Reihenfolge
der Schema-Attribute in der geänderten digitalen Bibliothek gezogen werden.
Wie bereits schon bei dem Logging von URLs erwähnt, ist es grundsätzlich schwierig,
Informationen aus dem Java-Code zu extrahieren. Deswegen sollte das Reinduction-Tool
möglichst ohne den Java-Code des Wrappers auskommen. Dadurch wird die Übertragbarkeit
des zu entwickelnden Tools auf die Erstellung neuer Wrapper vereinfacht.
Eine Nutzung der alten HTML-Seiten würde die Übertragbarkeit auf die Erstellung neuer
Wrapper ebenfalls erschweren. Außerdem kann die Reihenfolge der Schema-Attribute
auf der alten Webseite nur ein Indiz und kein sicherer Indikator sein, weil sich die Reihenfolge
der Schema-Attribute bei der Überarbeitung des Webservices ebenfalls geändert
haben kann. Demzufolge sollten auch die HTML-Seiten zunächst einmal nicht berücksichtigt
werden.
28

KAPITEL 4. RAHMEN FÜR DAS WRAPPERWERKZEUG
4.2 Grundannahmen
Im folgenden werden einige Annahmen bzw. Einschränkungen zur Eingrenzung der Problematik
vorgenommen. Das so vereinfachte Problem stellt eine Teilmenge des ursprünglichen
Problems dar. Kapitel 8.2 beschreibt, inwieweit das entwickelte Wrapperwerkzeug
sich auch auf Wrapper anwenden läßt, für die diese Einschränkungen nicht gelten.
4.2.1 Ergebnisse der Anfragen
Um das Problem überschaubarer zu gestalten wird beim weiteren Vorgehen von einer
Änderung des Seitenlayouts ausgegangen, nach der die alten Ergebnisse der Anfragen
weiterhin auf den HTML-Seiten der digitalen Bibliothek zu finden sind. Allerdings könnten
zusätzliche Informationen hinzugekommen sein.
Bei der Verwendung alter Logdateien kann es vorkommen, daß sich die Ergebnisse,
die zum Zeitpunkt der Erstellung der Logdatei auf der ersten Ergebnisseite zu finden
waren, nun auf einer der darauffolgenden Seite stehen bzw. sich sogar auf mehrere Übersichtsseiten
verteilen. Dazu kann es kommen, wenn die digitale Bibliothek um weitere
Dokumente ergänzt wird. Dadurch sind Dokumente nicht mehr auf der Seite mit der
gesuchten URL enthalten, sondern sind nur noch von der ursprünglichen Seite aus erreichbar.
Dazu müßten allerdings die entsprechenden URLs aus der Webseite extrahiert
werden.
Um dieses Problem erst einmal zu minimieren, könnten zunächst nur die jeweils aktuellsten
Logdateien geladen werden. Bei diesen ist die Wahrscheinlichkeit größer, daß die
mitgeloggten Ergebnisse auf der ersten Übersichtsseite enthalten sind. Dadurch steigen
auch die Aussichten für das zu entwickelnde Tool, erfolgreich zu arbeiten.
4.2.2 Anfragestruktur
Die Struktur der Anfrage wird sich seltener ändern als das Layout einer HTML-Seite.
Außerdem ist der Arbeitsaufwand für die manuelle Erstellung der Anfragestrukur erheblich
geringer als der Aufwand, der bei einem Wrapper auf die Erstellung des Parsers
verwendet wird. Des weiteren kommen bei der Überarbeitung der Anfragestruktur andere
Techniken zum Einsatz als bei der Erstellung des Parsers. Infolgedessen wird vorausgesetzt,
daß sich die Struktur der Anfrage nicht verändert bzw. dieses vor dem Einsatz
des zu entwickelnden Wrapperwerkzeugs überprüft und ggf. manuell überarbeitet wird
(s. 6.1.1). Deswegen ist dieses Problem ebenfalls zunächst zu vernachlässigen.
29

KAPITEL 4. RAHMEN FÜR DAS WRAPPERWERKZEUG
4.2.3 Wrappertypen
Es wird zwischen regulären und nicht regulären Wrappern unterschieden. Dazwischen
sind noch Wrapper anzusiedeln die nur teilweise regulär sind.
Bei einem regulären Wrapper unterscheidet sich der Seitenaufbau für verschiedene Anfragen
nicht. Die Ergebnisse weisen alle dieselbe Struktur auf. Dadurch können die
Schema-Attribute auf den verschiedenen Seiten immer durch dieselben XPath-Ausdrücke
selektiert werden. Reguläre Wrapper sind vergleichsweise einfach zu erstellen.
Bei einem nicht regulären Wrapper existiert dagegen nicht für jedes Dokument jedes
Schema-Attribut. Dem gegenüber kann es hier wiederum Schema-Attribute geben, die in
einzelnen Datensätzen mehrfach vorkommen. Wenn die einzelnen Schema-Attribute auf
der Webseite nur durch Zeilenumbrüche getrennt sind bzw. sogar zu mehreren in einer
Zeile stehen, variiert, je nach Vorkommenshäufigkeit der einzelnen Schema-Attribute,
ihre Position auf der Webseite. Dadurch ist der Wrapper schwer zu erstellen, weil auch
der XPath-Ausdruck variiert. Zunächst einmal sind in diesem Fall die möglichen Kombinationen
von Schema-Attributen ausfindig zu machen. Danach muß festgestellt werden,
wie es möglich ist, die gefundenen Kombinationen voneinander zu unterscheiden und
die Schema-Attribute somit richtig zuzuordnen. Ein weiteres Beispiel für einen nicht
regulären Wrapper ist eine sich ändernde Reihenfolge der Schema-Attribute. Darüber
hinaus kann es auch noch Ausnahmen geben. Hierunter fallen z. B. Schema-Attribute,
die sonst nicht vorkommen, und Schreibfehler. Ein Beispiel für einen nicht regulären
Wrapper ist der Wrapper der National Gallery of Art von Washington D. C. (s. Abb.
4.1).
Bei einem nicht regulären Wrapper kann es unter Umständen auch sinnvoll sein, selten
vorkommende Kombinationen von Schema-Attributen zu vernachlässigen, weil dadurch
insgesamt die Quote der richtigen Zuordnungen zu den Schema-Attributen erhöht wird.
Bereits die manuelle Erstellung von Wrappern für nicht reguläre Webseiten gestaltet sich
problematisch. Demzufolge wird die Entwicklung eines Tools zur semiautomatischen
Pflege von Wrappern deutlich schwieriger. Damit die zu bearbeitende Aufgabe nicht
zu komplex wird, werden die Probleme mit nicht regulären Wrappern zunächst einmal
vernachlässigt und eine reguläre Struktur vorausgesetzt.
4.3 Vorstellung des Wrappertoolkits von Rupp
Im Rahmen seiner Diplomarbeit zum Thema “Wrapper für digitale Bibliotheken in
Daffodil“ [Rup02] hat Markus Rupp ein Wrappertoolkit entwickelt. Es ermöglicht eine
30

KAPITEL 4. RAHMEN FÜR DAS WRAPPERWERKZEUG
Abbildung 4.1: Auszüge aus Detailseiten
der National Gallery of Art von Washington D. C.
Quelle: http://www.nga.gov
31

KAPITEL 4. RAHMEN FÜR DAS WRAPPERWERKZEUG
einfache und effiziente Erstellung von Wrappern für digitale Bibliotheken des Daffodil-
Projektes sowie eine einfachere Wartung von bereits erstellten Wrappern.
Bei dem Daffodil Projekt handelt es sich um ein nutzerorientiertes Zugangssystem für
heterogene digitale Bibliotheken [Daf]. Zusätzlich zur parallelen Suche in mehreren digitalen
Bibliotheken bietet Daffodil auch noch eine strategische Unterstützung des Benutzers
bei der Suche nach Informationen. Mit diesem Projekt soll der Zugang zu digitalen
Bibliotheken erleichtert werden, damit eine effektive Nutzung möglich ist.
Das Wrappertoolkit ist in der Programmiersprache Java implementiert. Für jeden Seitentyp
einer digitalen Bibliothek muß dabei eine Konfigurationsdatei (s. Abb. 4.3) im
XML-Format erstellt werden, die dann vom Toolkit aufgerufen wird. Das Toolkit gliedert
sich in die drei Komponenten Crawler, Tidy und Parser (s. Abb. 4.2).
4.3.1 Die Crawlerkomponente
Die Konfigurationsdatei bekommt innerhalb des fetch Elementes die URL der zu parsenden
Seite und die Parameter GET bzw. Post. Statt der direkten Angabe in der Konfigurationsdatei
können dem Wrappertoolkit die Daten auch beim Aufruf als Variable
übergeben werden. Das fetch Element in der Konfigurationsdatei bewirkt die Aktivierung
des Crawlers. Dieser ruft daraufhin die Webseite auf und liefert das zu parsende
Dokument zurück. Im folgenden Beispiel wird der Paramter die Anfrage-Methode GET
übergeben. Der URL der zu parsenden Seite ist eine Variable zugewiesen. Im Anschluß
daran wird noch die Codierung der URL festgelegt. Diese dient zur einheitlichen Darstellung
der URL.
4.3.2 Die Tidykomponente
Innerhalb des clean Elementes in der Konfigurationsdatei werden zunächst Angaben
zur Umwandlung von Entitäten gemacht. Anschließend erfolgt der Aufruf der Tidykomponente.
Diese wandelt das HTML-Dokument, das der Crawler zurückgeliefert hat,
mit Hilfe der Javabibliothek Tidy in XHTML um. Allerdings werden dabei von Tidy
einige HTML-Entitäten nicht ersetzt. Es ist in diesem Fall nicht möglich, die Entitäten
einwandfrei zu dekodieren, deswegen sind diese vor der Umwandlung zu ersetzen.
Das folgende Beispiel substituiert z. B. Leerzeichen, die in HTML mit „ “ codiert
werden:
32

KAPITEL 4. RAHMEN FÜR DAS WRAPPERWERKZEUG
Hash
Crawler
Tidy
XPath
&
reguläre
Ausdrücke
WWW
HTML
Dokument
XHTML
Dokument
Java
Objekt
High
Speed
Disk
Abbildung 4.2: Arbeitsweise des Wrappertoolkits
Quelle: [Rup02]
33

KAPITEL 4. RAHMEN FÜR DAS WRAPPERWERKZEUG
Für eine Vielzahl von digitalen Bibliotheken ist allerdings keine zusätzliche Codierung
von HTML-Entitäten erforderlich, bevor die Tidykomponente aufgerufen wird. Deswegen
ist nur ein leeres clean Element in der Konfigurationsdatei enthalten. Als Ergebnis
der Tidykomponente wird ein XML-Dokument-Objekt zurückgegeben.
4.3.3 Die Parserkomponente
Darauf folgt mit dem parse Element der interessanteste Teil der Konfigurationsdatei. In
diesem werden einzelne Knoten des XHTML-Baums mit Hilfe von XPath-Ausdrücken
extrahiert und das Resultat wird jeweils einem Schlüssel zugewiesen. Das erzielte Ergebnis
kann mit Hilfe von regulären Ausdrücken bearbeitet werden. Innerhalb des parse
Elementes sind auch Iterationen möglich, wodurch nicht nur der erste Knoten auf einer
Seite gefunden werden kann, auf die der XPath-Ausdruck zutrifft, sondern auch alle
folgenden.
Bei dem nachstehenden Beispiel umfaßt die Iteration mehrere Extraktionen. Dabei
werden alle Knoten durchlaufen die durch den XPath-Ausdruck //tr/td/p/b/a selektiert
werden. Ausgehend von diesen Knotextknoten werden dann jeweils mit den
Xpath-Ausdrücken für die XML-Attribute detaillink und author die Knoten für die
Schema-Attribute extrahiert. Im Normallfall ist der XPath-Ausdruck ein XML-Attribut
des XML-Elementes text. Handelt es sich bei dem zu selektierenden Element um eine
URL, ist der XPath-Ausdruck dabei ein XML-Attribut des XML-Elementes url. Dieses
wandelt relative URLs in absolute um.
Auf diese Weise können mehrere Dokumente selektiert werden, die jeweils ein XML-
Attribut der oben vorkommenden Extraktionen enthalten. In diesem Beispiel kann jedes
Dokument die XML-Attribute „detaillink“ und „author“ besitzen. Im Gegensatz
34

KAPITEL 4. RAHMEN FÜR DAS WRAPPERWERKZEUG
dazu ist die Iteration im folgenden Beispiel in der Extraktion enthalten. Diese Variante
wird verwendet, wenn auf einer Webseite nur ein Dokument enthalten ist und einzelne
Schema-Attribute mehrfach vorkommen.
Für Text, der sich z. B. aufgrund von optischen Hervorhebungen über mehrere Unterelemente
erstreckt, bietet das Toolkit auch die Möglichkeit, den gewünschten Text ohne
Berücksichtigung der weiteren Baumstruktur zu extrahieren.
Existieren für ein Schema-Attribut mehrere Einträge innerhalb eines Knotens, so können
diese mit Hilfe des Elementes split und eines hierin enthaltenen regulären Ausdrucks
getrennt werden. Das folgende Beispiel ist für Webseiten gedacht, bei denen die Autoren
durch ein Semikolon zu trennen sind.
Durch das substitute Element, sowie die darin enthaltenen regulären Ausdrücke, können
überflüssige Inhalte der Knoten abgetrennt werden. Das untenstehende Beispiel
entfernt von dem Inhalt des selektierten Knotens alle runden Klammern. Enthält das
XML-Attribut replacewith keine Argumente, kann es auch entfallen.
Das Toolkit ruft bei Angabe des Elementes parse die Parserkomponete auf. Diese Komponente
des Toolkits liefert bei Iterationen, die über alle Extraktionen durchgeführt
werden, eine Instanz der Javaklasse java.util.Vector zurück, die mehrere Instanzen
35

KAPITEL 4. RAHMEN FÜR DAS WRAPPERWERKZEUG
Abbildung 4.3: Beispiel einer Konfigurationsdatei
Quelle: eigene Darstellung
der Javaklasse java.util.Hashtable enthält. Falls keine Iteration vorkommt, bzw. nur
Iterationen für einzelne Extraktionen, wird direkt eine Instanz der Klasse Hashtable
zurückgeliefert. Existieren Iterationen für einzelne Extraktionen, so ist für diese in der
zurückgelieferten Hashtable ein Vektor enthalten.
36

Kapitel 5
Ideen für die Entwicklung eines
eigenen Wrapperwerkzeugs
Bei der Entwicklung eines Wrapperwerkzeugs wird eine induktive Vorgehensweise angestrebt.
Dazu werden mit Hilfe der mitgeloggten Daten die benötigten XPath- und
regulären Ausdrücke für die geänderte digitale Bibliothek gefunden, und es wird daraus
semiautomatisch ein neuer Wrapper erstellt.
5.1 Vorüberlegungen
Grundsätzlich existieren zwei mögliche Vorgehensweisen, um die passenden XPath-
Ausdrücke zu finden [Mor99]:
• Generalisierung: Die Generalisierung geht bottom-up vor. Hierzu wird mit der
speziellsten Hypothese begonnen. Im vorliegenden Fall könnten hierfür z. B. die
XPath-Ausdrücke aus dem Wrapper selektiert werden. Solange nicht alle zutreffenden
Beispiele abgedeckt sind, ist eine weitere Generalisierung erforderlich. Andernfalls
ist die Suche zu beenden. Eine Verallgemeinerung der XPath-Ausdrücke
kann daher durch die Entfernung des jeweils ersten Elementes erfolgen.
• Spezialisierung: Bei der Spezialisierung ist die Vorgehensweise dagegen top-down.
Dazu wird mit der allgemeinsten Hypothese gestartet. Im gegebenen Fall sind das
der XPath-Ausruck //* für die Textknoten bzw. //@* für die Attributknoten. Mit
diesen ist eine Suche in allen Text- bzw. allen Attributknoten eines Dokumentes
37

KAPITEL 5. IDEEN FÜR DIE ENTWICKLUNG EINES EIGENEN
WRAPPERWERKZEUGS
möglich. Diese Hypothese deckt im ersten Schritt neben den gewünschten Ergebnissen
wahrscheinlich auch unpassende Beispiele mit ab. Deswegen ist eine weitere
Spezialisierung erforderlich. Bei einer Spezialisierung sind mögliche Erweiterungen
für die aktuell verwendeten XPath-Ausdrücke zu suchen, bis der passende
XPath-Ausdruck gefunden wird, der nur die gesuchten Ergebnisse herausfiltert.
Die Methode der Spezialisierung verspricht größere Erfolge, weil sie eine Liste mit Kandidaten
für die Xpath-Ausdrücke zurückgibt. Da die alten Ergebnisse noch auf den aktuellen
Seiten zu finden sein müssen (s. 4.2.1), sind auch die passenden XPath-Ausdrücke
unter den Kandidaten. Diese Listen sind schrittweise zu reduzieren. Für die verbliebenen
eindeutigen XPath-Ausdrücke muß dann wieder eine Generalisierung gefunden werden,
die es ermöglicht, jedes Schema-Attribut eines Typs zu selektieren.
5.2 XPath-Ausdrücke
Wie bereits im Abschnitt 2.3.2 beschrieben, wird zwischen relativen und absoluten
XPath-Ausdrücken unterschieden. Bei relativen XPath-Ausdrücken ist schwerer nachzuvollziehen,
welche Knoten sie extrahieren. Dafür sind sie bei Layoutänderungen weniger
anfällig, weil der direkte Bezug zum Wurzelknoten fehlt. Absolute XPath-Ausdrücke
haben, zumindest bei automatischer Generierung, den Vorteil der Eindeutigkeit. Somit
kann für alle XPath-Ausdrücke eines Dokumentes die Reihenfolge bestimmt werden.
Dies könnte bei der Suche nach den mitgeloggten Dokumenten von Vorteil sein, weil
den eindeutig zugeordneten Schema-Attributen die Anordnung der Dokumente auf der
angefragten Webseite entnommen werden kann. Deswegen wird nachfolgend mit absoluten
Lokalisierungspfaden gearbeitet.
Sind allerdings Dokumente bzw. Schema-Attribute mehrfach auf einer Webseite enthalten,
so ist zunächst die Bildung von Iterationen notwendig. In diesem Fall muß, ausgehend
von einem Kontextknoten, weiter extrahiert werden, weshalb bei den Extraktionen
relative XPath-Ausdrücke Verwendung finden.
5.3 Template
Weil die HTML-Seiten der digitalen Bibliotheken automatisch aus einer Datenbasis generiert
werden, sind für jeden Webservice bei verschiedenen Anfragen einige Teile der
Ergebnisseiten immer gleich (s. Kap. 3). Dies gilt z. B. häufig für die Seitennavigation.
Es handelt sich gewissermaßen um ein Template, das nur mit den jeweils aktuellen
Daten zu füllen ist. Um den Aufwand für die Suche nach den Schema-Attributen zu
38

KAPITEL 5. IDEEN FÜR DIE ENTWICKLUNG EINES EIGENEN
WRAPPERWERKZEUGS
reduzieren, sollte zunächst einmal das Template ausfindig gemacht werden. Die Teile
des Templates, die zwischen den Ergebnissen stehen, können dabei Hinweise zur Lokalisierung
der Resultate liefern und sollten somit im folgenden Verarbeitungsprozess
zur Verfügung stehen. Insofern sind nur die Teile des Templates, die vor bzw. nach den
Ergebnissen stehen, von der weiteren Betrachtung auszuschließen. Dadurch kann die
Suche nach dem Template aus der Suche nach Übereinstimmungen am Anfang und am
Ende der HTML-Seite bestehen. Hier wird also die Verfahrensweise des ShopBot der
des Ansatzes zur Wrapper Maintenance vorgezogen.
5.4 Generalisierung von XPath-Ausdrücken
Im Zuge dieser Diplomarbeit soll herausgearbeitet werden, wie sich XPath-Ausdrücke
generalisieren lassen. Die Generalisierung läßt sich als die Aufgabe beschreiben, mehrere
XPath-Ausdrücke zu einem zu verschmelzen, um sie für die Iterationen und Extraktionen
zu benutzen. Die generalisierten Ausdrücke sollen alle Dokumente bzw. Schema-
Attribute, die auf einer Webseite enthalten sind, extrahieren. Dagegen repräsentieren
die vorhandenen XPath-Ausdrücke nur einzelne Dokumente bzw. Schema-Attribute. Insofern
bilden sie eine Teilmenge der entsprechenden Generalisierungen. Für die Generalisierung
muß der gemeinsame Stamm, das evtl. vorhandene gemeinsame Ende sowie die
unterscheidende Stelle erkannt werden, um sie dann in einer Iteration bzw. Extraktion
nutzen zu können. Im folgenden Beispiel ist /html/body[1]/dl[1]/dt der gemeinsame
Stamm, der zur Bildung der Iteration zu nutzen ist. Weil über alle Knoten iteriert werden
soll, entfällt die Positionsangabe beim letzten Element des XPath-Ausdrucks für
die Iteration. Der verbliebene XPath-Ausdruck /b[1]/text() wird dann zur Extraktion
benutzt.
/html/body[1]/dl[1]/dt[1]/b[1]/text()
/html/body[1]/dl[1]/dt[2]/b[1]/text()
Dabei bildet der Knoten, der jeweils von der Iteration selektiert wird, den Kontextknoten,
von dem aus die XML-Elemente zu suchen sind, die durch den XPath-Ausdruck
für Extraktion adressiert werden. Probleme kann es vor allem dann geben, wenn vor
dem ersten interessanten Eintrag weitere stehen, für die die gleichen XPath-Ausdrücke
gelten, die aber nicht mit zurück gegeben werden sollen. Dies kann beispielsweise der
Fall sein, wenn zu Beginn der Ergebnisseite gesponserte Resultate stehen, die nicht mit
zum Ergebnis der Anfrage gehören. Dann muß überprüft werden, ob der letzte nicht
interessierende Knoten vor, bzw. der erste nicht mehr interessierende Knoten nach den
gesuchten Ergebnissen durch einen XPath-Ausdruck automatisch zu identifizieren ist.
39

KAPITEL 5. IDEEN FÜR DIE ENTWICKLUNG EINES EIGENEN
WRAPPERWERKZEUGS
In diesem Fall können dann mit Hilfe von komplexen Achsenbeziehungen die richtigen
Einträge selektiert werden. Allerdings dürften diese XPath-Ausdrücke schwer automatisch
zu generieren sein, weil eine Trennung zwischen Dokumenten vorgenommen werden
muß, deren HTML-Code dieselbe Strukturierung aufweist.
Eine Änderung des Knotentyps ist nicht zu erwarten. Zwar kann der Inhalt eines Attributknotens
bei einer Layoutänderung zusätzlich auch als Textknoten in der Webseite
enthalten sein, jedoch wird das vermutlich eher selten auftreten. Deswegen läßt sich
häufig zumindest ein Teil des XPath-Ausdruckes wieder verwenden. Dies gilt für die
Suche nach Links, bei denen der XPath-Ausdruck immer auf a/@href enden wird, und
für die Suche nach Schema-Attributen zu Bildern, deren XPath-Ausdrücke immer auf
img/@src, img/@width und img/@height enden werden.
5.5 Text mit Unterelementen
Es kann eine Unterscheidung zwischen Informationen, die sich nur innerhalb eines einzelnen
XML-Elementes befinden, und solchen, die sich über mehrere XML-Elemente
erstrecken, getroffen werden.
Vor allem bei Fließtexten erstrecken sich die Informationen über mehrere XML-Elemente.
Dabei werden z. B. in einem logisch zusammenhängendem Text verschiedene Schriftarten
verwendet oder Hyperlinks zu weiteren Informationen in den Text eingebaut, so daß
sich der Text über mehrere XML-Elemente erstreckt. Das Problem besteht nun darin,
einen passenden XPath-Ausdruck zu finden, der alle benötigen XML-Elemente, aber
gleichzeitig auch nur diese, abdeckt. Bei der bisherigen Wrappererstellung muß noch
gesondert verfahren werden, damit der Inhalt von mehreren XML-Elementen selektiert
wird. Im Toolkit ist diese Funktion bereits enthalten, somit entfällt bei dessen Nutzung
eine Sonderbehandlung.
5.6 Indikatoren für unsichere Schema-Attribute
Ist der Wert eines Schema-Attributes auf einer Webseite nur einmal enthalten, läßt es
sich eindeutig zuordnen. Also handelt es sich hier um ein sicheres Schema-Attribut.
Es könnten zu einem gesuchten Schema-Attribut aber auch mehrere XPath-Ausdrücke
gefunden werden. In diesem Fall handelt es sich um unsichere Schema-Attribute. Das
Problem der Zuordnung von unsicheren Schema-Attributen wird in stärkerem Maße auf
den Übersichtsseiten zu finden sein. Falls z. B. nach einem Autor gesucht wird, so kommt
der Name des Autors bei den meisten digitalen Bibliotheken in jedem Ergebnistupel vor.
40

KAPITEL 5. IDEEN FÜR DIE ENTWICKLUNG EINES EIGENEN
WRAPPERWERKZEUGS
Somit wird es schwierig sein, den passenden XPath-Ausdruck für das jeweilige Tupel zu
finden.
Auf den Detailseiten können ebenfalls unsichere Attribute enthalten sein. Da auf diesen
Seiten allerdings nur einzelne Dokumente vorkommen, wird die Anzahl der Kandidaten
für die XPath-Ausdrücke geringer sein als auf den Übersichtsseiten. Außerdem wird hier
das Problem eher in einem erneuten Vorkommen der Schema-Attribute in einem anderem
Zusammenhang bestehen, dies gilt insbesondere für Zahlen. Eine häufige Variante
ist aber auch, daß das Schema-Attribut author, z. B. in einem Porträt des Autors, noch
einmal in der Webseite enthalten ist.
Durch den Ausschluß einer Suche innerhalb des Templates wird sich die Anzahl der
mehrfachen Fundstellen für Schema-Attribute bereits von vornherein reduzieren. Für die
unsicheren Schema-Attribute müssen Methoden zur Reduzierung der XPath-Ausdrücke
gefunden werden. Dazu könnten die folgenden Verfahren eingesetzt werden:
• Es wird der XPath-Ausdruck gewählt, der die größte Ähnlichkeit zum alten Ausdruck
aufweist. Dabei müßte allerdings noch ein Bewertungsmaß für diese Ähnlichkeit
gefunden werden.
• Es wird der XPath-Ausdruck gewählt, der den anderen neuen Ausdrücken am
ähnlichsten ist. Sind z. B. zwei XPath-Ausdrücke folgender Art gefunden worden
table/tr/td/b()
p/text()
und existieren bereits einige zugeordnete Schema-Attribute mit Ausdrücken folgender
Art:
table/tr/td/...
dann ist es wahrscheinlicher, daß der erste XPath-Ausdruck stimmt. Dies gilt
insbesondere, wenn die alten Ausdrücke für die Schema-Attribute ebenfalls Ähnlichkeiten
aufwiesen. Das trifft vor allem für Ausdrücke zu, die zum selben Ergebnistupel
gehören. Bei diesem Verfahren muß wiederum noch ein Maß für die
Ähnlichkeit entwickelt werden.
• Stimmt einer der gefundenen XPath-Ausdrücke bis auf die Elemente für die optische
Hervorhebung mit dem alten Ausdruck überein, so ist dieser zu bevorzugen.
• Werden für genügend Dokumente auf den Übersichtsseiten zumindest einzelne
Schema-Attribute eindeutig zugewiesen, können anhand dieser XPath-Ausdrücke
41

KAPITEL 5. IDEEN FÜR DIE ENTWICKLUNG EINES EIGENEN
WRAPPERWERKZEUGS
die Positionen der Dokumente auf der Webseite bestimmt werden. Weil zwischen
Schema-Attributen eines Dokumentes ein räumlicher Bezug besteht, kann durch
die Positionen der Dokumente eine Reduzierung der XPath-Ausdrücke erfolgen.
Beispielsweise werden Schema-Attribute des ersten Dokumentes ausschließlich vor
dem ersten Schema-Attribut des zweiten Dokumentes zu finden sein.
• Sind die Dokumentgrenzen bereits eindeutig identifiziert und liegen für Schema-
Attribute innerhalb dieser Dokumentgrenzen noch mehrere Kandidaten für die
Dokumente, kann eine Zuordnung anhand der Reihenfolge der Schema-Attribute
in anderen Dokumenten vorgenommen werden. Dabei kann der Vergleich auch mit
Dokumenten von anderen Anfrageergebnissen erfolgen.
Schwierigkeiten könnte es bei dem Ansatz mit der Sortierung der Dokumente geben,
wenn mehrere Dokumente in einer Zeile stehen, wie z. B. bei dem Wrapper für Fine
Arts Museums of San Francisco (FAMSF) in Abb. 5.1. In diesem Beispiel sind 6 Tabellenspalten
enthalten, wobei je drei Spalten zu einem Dokument gehören. Das Problem
würde deutlich einfacher, wenn sich Dokumente nur über eine Spalte erstrecken. Probleme
sind hier bei der Erstellung der Iteration zu erwarten. Deswegen müßte manuell
überprüft werden, ob diese Problematik bei der jeweiligen digitalen Bibliothek auftreten
kann. Weil dieses Phänomen auch optisch wahrzunehmen ist, stellt die Überprüfung
aber kein größeres Problem dar.
Der Vorteil der letzten beiden Ansätze besteht darin, daß kein vorhandener Wrapper benötigt
wird. Somit ist der Einsatz nicht nur bei der Pflege von Wrappern, sondern, unter
Zuhilfenahme von manuell erzeugten Logdateien, auch bei der Erstellung von Wrappern
möglich. Allerdings könnte die Verfolgung dieser Ansätze problematisch werden, wenn
alle vorhandenen Anfragen relativ wenig Ergebnisse zurückliefern sollten bzw. wenn relativ
wenig Anfragen vorliegen. Wegen der besseren Eignung für die Erzeugung neuer
Wrapper fällt die Entscheidung zunächst auf die beiden letzten Ansätze. Dabei sollte
bei der Umsetzung eine mögliche Erweiterung des Reinduction-Tools berücksichtigt
werden, damit bei Bedarf die anderen Möglichkeiten zur Behandlung von unsicheren
Attributen anschließend zum Einsatz kommen könnten. Auf diese Weise könnte eine
weitere Reduzierung der verbliebenen Kandidaten vorgenommen werden.
5.7 Trennung der einzelnen Ergebnisse
Die einzelnen Ergebnisse auf der Übersichtsseite starten meistens mit einer neuen Zeile,
die durch ein HTML-Element spezifiziert wird. Dafür kommt nur eine geringe Anzahl
an Tags wie z. B. , in Frage. Alternativ ist die Gliederung mit einer Tabelle
42

KAPITEL 5. IDEEN FÜR DIE ENTWICKLUNG EINES EIGENEN
WRAPPERWERKZEUGS
Abbildung 5.1: Digitale Bibliothek mit zweispaltigem Aufbau
Quelle: http://www.thinker.org/
43

KAPITEL 5. IDEEN FÜR DIE ENTWICKLUNG EINES EIGENEN
WRAPPERWERKZEUGS
möglich. Die verschiedenen Ergebnisse werden dabei einen ähnlichen Aufbau aufweisen.
Weitaus wichtiger ist allerdings die Tatsache, daß die einzelnen Schema-Attribute eines
Ergebnisses einen räumlichen Bezug zueinander haben müssen, um vom Benutzer auch
als eine Einheit wahrgenommen zu werden. Dieser räumliche Bezug muß sich in der
Positionierung der XPath-Ausdrücke zueinander widerspiegeln.
5.8 Nutzung des Wrappertoolkits
Die Entwicklung des Wrappertoolkits erfolgte zwar explizit für das Daffodil-Projekt,
aber eine Nutzung im Rahmen anderer Projekte wurde bei der Entwicklung mit eingeplant.
So kann das Wrappertoolkit auch von den MIND-Wrappern aufgerufen werden.
Dieses Vorgehen ist nicht nur für die zu überarbeitenden Wrapper, sondern generell auch
für neu zu erstellende MIND-Wrapper zu empfehlen, weil durch die Nutzung des Toolkits
in den Java-Klassen der jeweiligen Wrapper ein vermehrter Einsatz von Vererbung
möglich ist. Dadurch werden die speziellen Klassen für die einzelnen MIND-Wrapper
übersichtlicher und so wird auch die Erstellung effektiver.
Bei einer Nutzung des Toolkits müssen, wenn ein Wrapper gebrochen ist, lediglich die
Konfigurationsdateien, die für jeden Seitentyp einer digitalen Bibliothek zu erzeugen
sind, jeweils neu verfaßt werden. Diese sind im XML-Format verfaßt, welches übersichtlicher
als der Java-Code ist. Dadurch wird die Wrappererstellung und -pflege durch
das Tool erheblich erleichtert und ist somit meist ohne Programmiererfahrung durchführbar.
Dies gilt vor allem für die Pflege, weil oftmals nur noch XML- und XPath-
Kenntnisse benötigt werden. Wenn die Schlüssel in den Konfigurationsdateien entsprechend
der Schema-Attributnamen im MIND-Schema vergeben werden, können innerhalb
des MIND-Wrappers direkt die Schema-Attribute gesetzt werden. Hierdurch wird die
Überschaubarkeit des Wrappers weiter gesteigert.
Bei einem Einsatz des Toolkits im Rahmen des MIND-Projektes wird die Suche nach den
XPath-Ausdrücken nicht nur wegen der größeren Übersichtlichkeit vereinfacht, sondern
auch, weil die Konfigurationsdatei eigenständig getestet werden kann, ohne eine ständige
neuerliche Kompilierung des Wrappers zu erfordern. Insofern wird angestrebt, die alten
MIND-Wrapper auf die Nutzung des Toolkits umzustellen. Deswegen kann im folgenden
davon ausgegangen werden, daß der zur Verfügung stehende alte MIND-Wrapper bereits
das Toolkit nutzt.
Mit dieser Voraussetzung ist das Ziel für das zu entwickelnde Reinduction-Tool die Erstellung
einer neuen Konfigurationsdatei für gebrochene Wrapper. Deshalb ist das zu
entwickelnde Reinduction-Tool für digitale Bibliotheken, deren Komplexität keinen Einsatz
des Wrappertoolkits ermöglicht, ebenfalls nicht einsetzbar. Dies wird keine weitere
44

KAPITEL 5. IDEEN FÜR DIE ENTWICKLUNG EINES EIGENEN
WRAPPERWERKZEUGS
Beschränkung darstellen, weil es nur für nicht reguläre digitale Bibliotheken zutrifft,
und diese Bibliotheken werden zunächst einmal nicht betrachtet (s. 4.2.3).
Bei einer weitergehenden Evaluierung des Toolkits in bezug auf die MIND-Wrapper
müßte deswegen noch untersucht werden, wie das Toolkit bei nicht regulären digitalen
Bibliotheken einzusetzen ist, damit die Grenzen des zu entwickelnden Tools besser
bestimmt werden können.
Grundsätzlich ist der Einsatz des Toolkits immer dann möglich ist, wenn für alle Schema-
Attribute XPath-Ausdrücke gefunden werden, die immer für diese Schema-Attribute
gelten. Dazu müssen die Positionen der Schema-Attribute eindeutig anhand von XPath-
Ausdrücken identifizierbar sein. Für die National Gallery of Art ist dies beispielsweise
nicht möglich, deshalb wird das zu entwickelnde Reinduction-Tool für diese digitale
Bibliothek nicht einsetzbar sein.
45

Kapitel 6
Vorgehensweise des
Reinduction-Tools
Im folgenden wird auf die Vorgehensweise des Reinduction-Tools bei der Pflege eines gebrochenen
Wrappers eingegangen. Dabei unterscheidet sich die Vorgehensweise je nachdem,
ob es sich um eine Übersichts- oder eine Detailseite handelt.
6.1 Vorgehensweise bei Übersichtsseiten
Als erstes wird die Vorgehensweise für Übersichtsseiten vorgestellt (s. Abb. 6.4). Zunächst
muß überprüft werden, ob eine Überarbeitung der Anfragestruktur und der Logdateien
erforderlich ist. Im nächsten Schritt erfolgt die Suche nach dem Template. Anschließend
werden die zur Verfügung stehenden Daten geladen. Der Reihe nach werden
dann mit der freien Suche nach den Ergebnissen der alten Anfrage für jedes Schema-
Attribut Kandidaten für die XPath-Ausdrücke identifiziert. Falls dabei für Schema-
Attribute keine eindeutige Zuordnung möglich ist, muß eine Behandlung dieser unsicheren
Schema-Attribute erfolgen. Dies geschieht im ersten Schritt mit einer Einteilung in
Intervalle, in denen die XPath-Ausdrücke liegen müssen. Dazu werden Intervallgrenzen
anhand der Schema-Attribute bestimmt, die für ein Dokument eindeutig zugeordnet
werden konnten.
Ist die Behandlung der unsicheren Schema-Attribute abgeschlossen, müssen die möglichen
Iterationen gefunden werden. Mit Hilfe der Iterationen kann sichergestellt werden,
daß die einzelnen Dokumente als eine Einheit zu identifizieren sind. In Abhängigkeit
von den möglichen Iterationen werden nun die Extraktionen bestimmt. Daraufhin wird
46

KAPITEL 6. VORGEHENSWEISE DES REINDUCTION-TOOLS
Überprüfung der Anfragestruktur
und der Logdateien
Suchen der Templates
Laden der Daten
Freie Suche
Behandlung der unsicheren Attribute
Finden der Iterationen
Finden der Extraktionen
Trennung von Schema-Attributen
Bildung von regulären Ausdrücken
Präzisieren der Iterationen
Test der Konfigurationsdatei
Abbildung 6.1: Vorgehensweise des Wrappertools
Quelle: eigene Darstellung 47

KAPITEL 6. VORGEHENSWEISE DES REINDUCTION-TOOLS
überprüft, ob die zurückgelieferten Ergebnisse der XPath-Ausdrücke eine weitere Bearbeitung
erfordern. Dies ist z. B. der Fall, wenn zwei Schema-Attribute desselben Typs
im selben Knoten zu finden sind. Daran schließt sich für Schema-Attribute, bei denen
der XPath-Ausdruck zuviel selektiert hat, eine Suche nach regulären Ausdrücken an.
Abschließend wird eine neue Konfigurationsdatei erstellt und getestet.
Konnten keine Iterationen gebildet werden, wird der Prozeß mit dem Laden der Daten
erneut begonnen. Das Reinduction-Tool wiederholt die oben beschriebene Vorgehensweise
solange, bis eine Konfigurationsdatei gefunden werden konnte oder alle Logdateien
getestet wurden.
6.1.1 Überprüfung der Anfragestruktur und der Logdateien
Vor dem Einsatz des eigentlichen Wrapperwerkzeugs ist manuell zu überprüfen, ob sich
die Struktur der Anfrage geändert hat. Wenn dies der Fall ist, muß diese ebenfalls manuell
in der Java-Klasse überarbeitet werden. Weil das Tool auch mit den mitgeloggten
alten Anfragestrukturen arbeitet, müssen darüber hinaus auch aus den vorhandenen
Logdateien für die URLs der alten Anfragen Dateien mit den aktuellen URLs erzeugt
werden.
Anschließend müssen die Logdateien, die nach der Layoutänderung der Webseite entstanden
sind, manuell entfernt werden, weil diese zwangsläufig auf einem nicht mehr
funktionierenden Wrapper basieren. Wenn bei fehlerhaften Anfrageergebnissen das entwickelte
Wrapperwerkzeug zügig zum Einsatz kommt bzw. zumindest der Zeitpunkt
festgehalten wird, zu dem der Wrapper das erste Mal fehlerhaft gearbeitet hat, sollten
diese Logdateien schnell ausfindig zu machen sein.
6.1.2 Suche des Templates
Erst nach den beschriebenen Schritten wird das Reinduction-Tool gestartet. Als erstes
wird das Template bestimmt, damit die Teile, die auf jeder Ergebnisseite enthalten
sind, von der Ergebnissuche ausgeschlossen werden (s. 5.3). Für die Suche nach dem
Template werden zwei Anfragen an die digitale Bibliothek gestellt. Die zurückgelieferten
HTML-Seiten werden zunächst in einen XHTML-Baum umgewandelt. Die beiden
Bäume werden dann schrittweise verglichen. Bei Übereinstimmungen von Knoten am
Anfang bzw. am Ende des Dokumentes werden die absoluten XPath-Ausdrücke für die
entsprechenden Knoten in einer Liste festgehalten. Da es sich hierbei um automatisch
generierte Ausdrücke handelt, sind sie auch eindeutig (s. 5.2).
48

KAPITEL 6. VORGEHENSWEISE DES REINDUCTION-TOOLS
Anhand von weiteren Anfragen wird überprüft, ob die zugehörigen Webseiten auch
dieselben Übereinstimmungen aufweisen. Ist dies nicht der Fall, so werden die nicht
übereinstimmenden Knoten aus der Liste für das Template wieder entfernt.
6.1.3 Laden der Daten
Zunächst müssen die mitgeloggten alten Daten geladen werden, damit sie im weiteren
Verarbeitungsprozeß zur Verfügung stehen.
Weil Ergebnisseiten vorkommen können, die nicht alle Schema-Attribute beinhalten,
kann es dementsprechend auch Logdateien geben, die nicht alle Schema-Attribute enthalten.
Damit die zu erzeugende Konfigurationsdatei auch alle möglichen
Schema-Attribute umfaßt, wird zunächst einmal überpüft, welche Schema-Attribute in
den Logdateien enthalten sind. Danach wird eine Logdatei mit Ergebnissen geladen, die
alle Schema-Attribute beinhaltet.
Zu der ausgewählten Ergebnisdatei wird die zugehörige URL geladen und aufgerufen.
Dabei ist es möglich, mit Hilfe der in MIND vorhandenen Java-Methoden, auf Ergebnisse
zuzugreifen.
6.1.4 Freie Suche
Die Ermittlung der Schema-Attributwerte erfolgt mit der freien Suche. Dazu werden
zunächst die Schema-Attributwerte aus den alten Ergebnissen in der neuen Webseite gesucht.
Weil aus den mitgeloggten Daten nicht hervorgeht, ob die Schema-Attributwerte
aus einem Text- oder einem Attributknoten extrahiert wurden, sind bei der freien Suche
sowohl die Text- als auch die Attributknoten daraufhin zu überprüfen, ob sie das
Schema-Attribut enthalten. Um die Zahl der unsicheren Schema-Attribute möglichst
klein zu halten, wird zunächst versucht, ein XML-Element bzw. XML-Attribut zu finden,
das exakt mit dem Schema-Attributwert übereinstimmt. Wenn diese Suche nicht
erfolgreich ist, wird nach einem XML-Element bzw. XML-Attribut gesucht, das den
Schema-Attributwert enthält.
Ist bei einem Schema-Attribut keine der beiden Suchvarianten erfolgreich, wird davon
ausgegangen, daß das Dokument nicht mehr auf der Webseite enthalten ist. Bei der Erstellung
einer neuen Konfigurationsdatei findet es dann keine weitere Berücksichtigung.
Diese Vorgehensweise ist zwar sehr restriktiv, aber da es sehr ähnliche Dokumente geben
kann (s. 4.1), wird auf diese Weise die falsche Zuordung der anderen Schema-Attribute
verhindert.
49

KAPITEL 6. VORGEHENSWEISE DES REINDUCTION-TOOLS
Abbildung 6.2: Beispiel für die Ähnlichkeit von Dokumenten
Quelle: http://www.kfki.hu/~arthp/index1.html
50

KAPITEL 6. VORGEHENSWEISE DES REINDUCTION-TOOLS
Die einzige Ausnahme bildet hier der Link zu den Details, weil dieser auch nur eine
vom Wrapper erzeugte ID sein kann, falls es zu einem mitgeloggten Dokument keine
Detailseiten gab. Bei der freien Suche wird davon ausgegangen, daß die URLs zu den
evtl. vorhandenen Detailseiten, wie in MIND üblich, in den Logdateien als Teil der
Dokument-ID enthalten sind. Die Links werden dementsprechend aus der Dokument-
ID herausgefiltert. Das Toolkit wandelt die in einer Webseite enthaltenen relativen URLs
in absolute URLs, sofern sie als URL und nicht als Text selektiert werden. Deswegen
müssen die in den Logdateien enthaltenen absoluten URLs vor Beginn der freien Suche
wieder in relative URLs umgewandelt werden, weil nur diese auch auf der HTML-Seite
zu finden sind.
6.1.5 Behandlung von unsicheren Schema-Attributen
Wie bereits in Abschnitt 5.6 erwähnt, tritt das Problem der unsicheren Schema-Attribute
vor allem auf den Übersichtsseiten auf. Dabei stehen die Schema-Attribute zu den einzelnen
Datensätzen in räumlichem Bezug zueinander. Außerdem kann in den meisten
Fällen für jeden mitgeloggten Datensatz zumindest ein Schema-Attribut eindeutig zugeordnet
werden. Das trifft zum einen für den Detaillink zu, falls er in der Seite enthalten
ist, zum anderen aber häufig auch für den Titel. Dabei ist nicht entscheidend, ob immer
dasselbe Schema-Attribut zugeordnet werden kann. Wichtig ist die Existentenz eines
sicheren Schema-Attributes für ausreichend viele mitgeloggte Datensätze. Eine exakte
Angabe der Anzahl der ausreichenden Datensätze ist nicht möglich, weil diese von der
Anzahl der Dokumente auf der Webseite und ihren Positionen abhängt.
Durch diese Schema-Attribute können die gefundenen Dokumente nach ihrem Vorkommen
auf der Webseite geordnet werden. Hierzu werden die Positionen der XPath-
Ausdrücke für die sicheren Schema-Attribute in der Webseite bestimmt. Dazu wird eine
geordnete Liste erstellt, in der für jeden Knoten des zur Webseite gehörigen XHTML-
Baumes der entsprechende XPath-Ausdruck enthalten ist.
Jeweils das erste richtig zugeordnete Schema-Attribut eines Dokumentes bildet nun die
Intervallgrenze, bis zu dem Schema-Attribute des vorangegangenen Dokumentes auftreten
können. Dementsprechend gibt das letzte eindeutig zugeordnete Schema-Attribut
eine Intervallgrenze für die XPath-Ausdrücke der darauffolgenden Dokumente an. Zwischen
diesen Intervallgrenzen können nur Schema-Attribute des Dokumentes enthalten
sein, zu dem die Intervallgrenzen gehören. Falls für ein Dokument nur ein Schema-
Attribut eindeutig zugewiesen werden konnte, fallen diese beiden Intervallgrenzen zusammen.
Wird z. B. bei den Dokumenten 1 bis 4 die Titel eindeutig zugeordnet, so
können die Schema-Attribute des zweiten Dokumentes frühestens nach dem Titel des
ersten Dokumentes zu finden sein. Zugleich müssen sie aber vor dem Titel des dritten
Dokumentes in der Webseite enthalten sein. Für das dritte Dokument müssen die
51

KAPITEL 6. VORGEHENSWEISE DES REINDUCTION-TOOLS
Nottelmann, Henrik; Fuhr, Norbert
(2002)
Titel 1
Nottelmann, H.; Fuhr, N.
(2003)
Titel 2
Nottelmann, H.; Fuhr, N.
(2003)
Titel 3
Nottelmann, H.; Pala, P.
(2003)
Titel 4
Abbildung 6.3: Intervallverfahren
Quelle: eigene Darstellung
52

KAPITEL 6. VORGEHENSWEISE DES REINDUCTION-TOOLS
XPath-Ausdrücke dementsprechend zwischen den Titels des zweiten und des vierten
Dokumentes zu finden sein (s. Abb. 6.3).
Wenn die XPath-Ausdrücke außerhalb der Intervallgrenzen liegen, können mit diesem
Verfahren die Listen mit den Kandidaten für die XPath-Ausdrücke z. T. erheblich gekürzt
werden. Nachdem die Listen für die Kandidaten auf diese Weise reduziert wurden,
sind die XPath-Ausdrücke der bereits eindeutig zugeordneten Schema-Attribute aus den
Kandidatenlisten der anderen Schema-Attribute zu entfernen. Dies passiert allerdings
nur bei den Schema-Attributen, die nicht zum selben Dokument gehören, weil innerhalb
eines Dokumentes eine Selektierung von zwei Schema-Attributen durch den selben
XPath-Ausdruck möglich ist. Dies kann z. B. der Fall sein, wenn sie in einem Textknoten
stehen und nur durch Satzzeichen voneinander getrennt sind (s. 6.1.8).
Weil sich die Intervallgrenzen der aufeinanderfolgenden Dokumente evtl. überschneiden,
können Schema-Attribute, die in benachbarten Dokumenten identisch sind, noch nicht
immer eindeutig zugeordnen werden. Deswegen wird das Verfahren ggf. mehrfach mit
den sich aus dieser Vorgehensweise ergebenden neuen Intervallgrenzen wiederholt, bis
keine Reduzierung der XPath-Kandidaten mehr erfolgt bzw. allen Schema-Attributen
ein XPath-Ausdruck eindeutig zugeordnet werden konnte. Im weiteren Verlauf werden
nur noch die eindeutig zugewiesenen Kandidaten für XPath-Ausdrücke betrachtet.
6.1.6 Finden der Iterationen
Damit eine Chance besteht, eine Iteration zu bilden, müssen jeweils zwei Beispiele eines
Schema-Attributes eindeutig zugeordnet sein. Ist dies nicht der Fall, muß für die
Erstellung einer Konfigurationsdatei eine andere Logdatei ausgewählt werden. Nachfolgend
wird zwischen globaler und lokaler Iterationen unterschieden. Mit der globalen
Iteration können mehrere Dokumente selektiert werden. Dagegen ermöglicht die lokale
Iteration die Extraktion von Schema-Attributen, die mehrfach in einem Dokument
vorkommen und durch unterschiedliche XPath-Ausdrücke adressiert werden.
6.1.6.1 Bildung der globalen Iterationen
Die Suche nach einer globalen Iteration ist notwendig, wenn mehrere Dokumente auf
einer Seite enthalten sind oder es zu einem oder mehreren Schema-Attributen mehrere
Ergebnisse auf einer Seite gibt. Mehrere Dokumente sind im Normalfall auf den Übersichtsseiten
enthalten, mehrfaches Vorkommen von Schema-Attributen wird dagegen
vor allem auf den Detailseiten zu finden sein.
Um die Iteration zu finden, muß zunächst für zwei Vorkommen desselben Schema-
Attributs der gemeinsame Stamm und ggf. ein gemeinsames Ende ausfindig gemacht
53

KAPITEL 6. VORGEHENSWEISE DES REINDUCTION-TOOLS
werden (s. 5.4). Wegen der automatisch generierten XPath-Ausdrücke kann dabei ein
Stringvergleich zum Einsatz kommen. Hierbei bildet der gemeinsame Stamm die Basis
für die Iteration. Weil nicht immer alle Dokumente auf einer Seite auch mitgeloggt sind
bzw. zusätzliche Dokumente hinzugekommen sein könnten, werden bei einem späteren
Test der Konfigurationsdatei evtl. auch noch andere als die gesuchten Dokumente von
der Iteration zurückgeliefert.
6.1.6.2 Bildung der lokalen Iterationen
Sind in den Dokumenten Schema-Attribute mehrfach enthalten und werden sie durch
verschiedene XPath-Ausdrücke selektiert, müssen für diese Schema-Attribute ebenfalls
noch Iterationen gebildet werden. Die gilt z. B. für die Autorennamen im folgenden
Beispiel:
MIND resource selection framework and methods
Nottelmann, Henrik
Fuhr, Norbert
Weil die Iterationen in diesem Fall den Schema-Attributen zugeordnet werden, können
mehrere Iterationen in einer Konfigurationsdatei enthalten sein. Zunächst wird festgestellt,
welche Schema-Attribute mehrfach in einem Dokument auftreten und deren
Selektierung gleichzeitig auf verschiedenen XPath-Ausdrücken basiert. Die Iterationen
selbst werden dabei nach demselben Prinzip gebildet wie die globalen Iterationen.
6.1.7 Finden der Extraktionen
Beim Fehlen des schließenden Teils der Elemente im HTML-Code kann es Probleme
geben, weil Tidy bei der Umwandlung in XHTML den fehlenden Teil selbst setzen muß.
Dadurch kann in einem Dokument eine zusätzliche Tabelle definiert sein, während dies
bei den anderen Dokumenten auf denselben Webseiten nicht der Fall ist. Infolgedessen
unterscheiden sich die XPath-Ausdrücke für das entsprechende Schema-Attribut trotz
eindeutiger Zuweisung an mehr als nur einer Stelle. Ist dies der Fall und beginnen einige
der XPath-Ausdrücke mit der Iteration, so werden nur diese zur Bildung der Iteration
54

KAPITEL 6. VORGEHENSWEISE DES REINDUCTION-TOOLS
herangezogen. Auf diese Weise kann z. B. verhindert werden, daß die Extraktion nach
einer Tabelle sucht, die in den meisten Fällen gar nicht vorhanden ist.
In Abhängigkeit von den gefundenen Iterationen werden die Extraktionen für die einzelnen
Schema-Attribute bestimmt. Falls die Iteration mit dem Beginn der XPath-
Ausdrücke für ein Schema-Attribut übereinstimmt, ist eine andere Vorgehensweise zur
Identifikation der Extraktion erforderlich als bei fehlender Übereinstimmung.
Ist die Deckungsgleichheit für ein Schema-Attribut gegeben, so wird zunächst dieser
Stamm aus dem XPath-Ausdruck entfernt. Daraufhin wird von dem ersten verbliebenen
XML-Element die Positionsangabe entfernt. Anschließend ist der verbliebene XPath-
Ausdruck vorne noch um .// zu ergänzen, damit die Extraktion an dem Knoten beginnt,
der jeweils von der Iteration selektiert wurde.
Beginnen die XPath-Ausdrücke für ein Schema-Attribut nicht mit der Iteration, so werden
nur die XML-Elemente entfernt, die mit der Iteration übereinstimmen. Danach wird
festgestellt, ob das Schema-Attribut, mit dem die Iteration erstellt wurde, in der Ergebnisseite
vor oder nach dem gerade behandelten Schema-Attribut auf der Webseite zu
finden ist. Steht die Iteration im XHTML-Dokument vor dem Schema-Attribut, wird der
verbliebene XPath-Ausdruck um .//following:: ansonsten um .//preceding:: ergänzt.
Danach wird für das erste verbliebene XML-Element überprüft, wie oft das XML-
Element zwischen der Iteration und dem bearbeiteten Schema-Attribut vorkommt. Die
Positionsangabe des entsprechenden XML-Elementes wird daraufhin durch den berechneten
Wert ersetzt. Dieses Verfahren bewirkt, daß ausgehend von dem jeweils durch die
Iteration bestimmten Knoten, entsprechend der Postionsangabe das nachfolgende bzw.
vorangegangene erste XML-Element für die Extraktion genommen wird. Ausgehend von
diesem Knoten wird dann nach dem verbliebenen XPath-Ausdruck gesucht.
Diese Vorgehensweise verhindert die Extraktion des entsprechenden Schema-Attributes
des darauffolgenden bzw. vorangegangenen Dokumentes, wenn ein Schema-Attribut für
ein Dokument nicht existiert.
Für jedes Schema-Attribut wird daraufhin noch überprüft, ob eine lokale Iteration erforderlich
ist. Ist dies der Fall, wird von der Extraktion noch der Pfad der lokalen
Iteration entfernt und die Anpassung für die Suche nach dem neuen Kontextknoten
vorgenommen.
Liegen für das Schema-Attribut title z. B. folgende XPath-Ausdrücke vor:
/html/body[1]/dl[1]/dt[1]/b[1]/text()
/html/body[1]/dl[1]/dt[2]/b[1]/text()
für den author die nachstehenden XPath-Ausdrücke:
55

KAPITEL 6. VORGEHENSWEISE DES REINDUCTION-TOOLS
/html/body[1]/dl[1]/dt[1]/a[1]/text()
/html/body[1]/dl[1]/dt[1]/a[2]/text()
/html/body[1]/dl[1]/dt[2]/a[1]/text()
/html/body[1]/dl[1]/dt[2]/a[2]/text()
und für den detaillink folgende Ausdrücke:
/html/body[1]/dl[1]/dd[1]/a[1]/@href
/html/body[1]/dl[1]/dd[2]/a[1]/@href
Dann ergibt sich aus der zuvor beschriebenen Vorgehensweise der folgende Teil der
Konfigurationsdatei:
Zwar sollte das Reinduction-Tool zunächst nicht beachten, daß nicht für jedes Dokument
alle Attribute vorkommen (s. 4.2.3). Allerdings können mit der folgenden Berücksichtigung
des Links- bzw. Rechtskontextes einige falsche Zuordnungen vermieden werden.
Häufig wird der Schema-Attributname vor dem eigentlichen Schema-Attributwert in
der Webseite stehen. Wenn für ein Dokument, wie im folgenden Beispiel die Schema-
Attribute title, author und form mit folgendem HTML dagestellt werden, und wie
im zweiten Beispiel, im darauf folgenden Dokument der author unbekannt ist:
56

KAPITEL 6. VORGEHENSWEISE DES REINDUCTION-TOOLS
Madonna and Child with a Pomegranate
Leonardo da Vinci
form:oil on panel, 16.5 x 13.4 cm
View of Fondi
form:pen and brown ink on laid paper, 19.9 x 29.9 cm
dann wird mit dem folgenden XPath-Ausdruck das Schema-Attribut form zuverlässig
zugeordnet, obwohl sich die Position der Textknoten ändert:
//text()[preceding::b[1]=’form:’]
Gleichzeitig wird mit dem nachstehenden XPath-Ausdruck sichergestellt, daß für das
Schema-Attribut author nicht derselbe Knoten selektiert wird.
//text()[preceding::b[1]!=’form:’]
6.1.8 Trennung von Schema-Attributen
Wenn für einen Datensatz mehrere gleichartige Schema-Attribute existieren, können sie
in einem Knoten enthalten sein. Dies gilt vor allem für die Übersichtsseite. Wenn z.
B. ein Artikel von mehreren Autoren geschrieben wurde, erfolgt die optische Trennung
meistens durch ein Komma oder Semikolon und ein Leerzeichen. In diesem Fall lassen
sich alle durch denselben XPath-Ausdruck selektieren. Hier muß herausgefunden werden,
wie die Schema-Attribute voreinander zu trennen sind, und die ensprechende split
Anweisung muß dann in der neuen Konfigurationsdatei eingefügt werden.
In folgendem Beispiel würden die Autorennamen beispielsweise anhand des Semikolons
und des Leerzeichens gesplittet.
Nottelmann, Henrik; Fuhr, Norbert
Um festzustellen, bei welchen Zeichen eine Trennung vorzunehmen ist, wird zunächst
der Text ab dem Wert des zweiten Schema-Attributes aus dem Knoteninhalt entfernt.
Aus dem verbliebenen Text wird dann der überflüssige Teil bis zum Ende des ersten
Schema-Attributes entfernt. Anhand des verbliebenen Teils muß dann die Trennung
vorgenommen werden. Das Toolkit erlaubt allerdings nur die Aufteilung durch einzelne
Zeichen. Reicht dies nicht aus, so werden die Trennzeichen zunächst durch # ersetzt.
Mit dem #-Zeichen wird dann die Trennung vorgenommen. Auf diese Weise ergibt sich
der folgende Teil der Konfigurationsdatei:
57

KAPITEL 6. VORGEHENSWEISE DES REINDUCTION-TOOLS
6.1.9 Bildung von regulären Ausdrücken
Sind die XPath-Ausdrücke, die die gewünschten Ergebnisse zurückliefern, gefunden,
ist zu überprüfen, ob reguläre Ausdrücke erforderlich sind. Dies ist der Fall, wenn die
Ergebnisse noch mit Daten verknüpft sind, die nicht zu der gewünschten Information
gehören. Mit Hilfe der regulären Ausdrücke kann das Ergebnis dann nachbearbeitet
werden.
Das Reinduction-Tool kann mit regulären Ausdrücken sowohl vor als auch nach einem
Schema-Attribut Text entfernen. Dazu werden zunächst die Werte für alle Schema-
Attribute, deren Extraktion durch denselben Knoten erfolgt, beseitigt. Abhängig von der
Position wird dabei der vorhergehende bzw. nachfolgende Text ebenfalls mit entfernt.
Anschließend wird aus den verbliebenen Zeichen vor bzw. nach dem Wert des Schema-
Attributes der reguläre Ausdruck gebildet. Ist z. B. der folgende Knoteninhalt gegeben:
Oil on panel, 246 x 243 cm; from 1481-82
So ergibt sich das nachstehende XML-Element für das Schema-Attribut form:
6.1.10 Präzisieren der Iterationen
Mit den bisherigen Ergebnissen wird die Konfigurationsdatei erzeugt. Selektiert diese
noch leere Dokumente, ist häufig noch eine Präzision der erstellten Iterationen erforderlich.
Dazu werden zunächst alle Extraktionen, die Kindknoten der Iteration sind,
daraufhin geprüft, ob sie mit demselben XML-Element beginnen. Ist dies der Fall, so
wird der XPath-Ausdruck für die Iteration um die Bedingung ergänzt, daß die durch die
Iteration selektierten Knoten das erste XML-Element aus den geprüften Extraktionen
enthalten. Im folgendem Beispiel werden nach der Präzisierung des Ausdrucks von den
bisher ausgewählten Knoten nur noch die selektiert, die einen td-Kindknoten besitzen.
Auf diese Weise kann die Extraktion von den Tabellenüberschriften, die durch th-Tags
definiert sind, verhindert werden.
58

KAPITEL 6. VORGEHENSWEISE DES REINDUCTION-TOOLS
/html/body[1]/center[2]/table[1]/tr
⇒/html/body[1]/center[2]/table[1]/tr[td]
Durch die Einbeziehung aller Extraktionen, die Kindknoten der Iteration sind, wird die
Präzisierung anhand eines Schema-Attributes verhindert, das nicht für jedes Dokument
vorhanden ist. Es steht zu erwarten, daß auf diese Weise häufiger die richtige Ergänzung
vorgenommen wird.
Im Anschluß daran wird mit der Konfigurationsdatei getestet, ob für das Schema-
Attribut, mit dem die Iteration gebildet wurde, leere Attributwerte selektiert werden.
Ist dies der Fall, wird überprüft, ob die nicht leeren Attributwerte in gleichmäßigen
Abständen (z. B. bei jedem zweiten Dokument) auftreten. In diesem Fall wird der
XPath-Operator mod verwendet. Dieser liefert den Rest bei der ganzzahligen Division.
Wird ein Knoten in einem XPath-Ausdruck um diesen Knoten ergänzt, so legt der Divisor
fest, in welchen Abständen die Knoten selektiert werden. Wird z. B der folgende
XPath-Ausdruck um den unten dargestellten Operator mod ergänzt, hat dies zur Folge,
daß nicht mehr alle Knoten selektiert werden, auf die der Ausdruck zutrifft, sondern
nur noch jeder zweite.
/html/body[1]/dl[1]/dd
⇒/html/body[1]/dl[1]/dd[position() mod 2 = 0 ]
Dabei wird durch den Rest der Division der Knoten festgelegt, der als erstes selektiert
wird. So legt der Rest 0 fest, daß die Knoten an geraden Positionen selektiert werden.
Ist der Rest hingegen 1, werden nur die Knoten an ungerade Positionen extrahiert.
6.1.11 Testen der neuen Konfigurationsdatei
Sind die vorangegangenen Schritte erfolgreich abgeschlossen, wird die Konfigurationsdatei
vom Reinduction-Tool selbst getestet. Dazu werden die gefundenen Dokumente
aus den Logdateien mit der Ausgabe der Toolkits verglichen. Dabei werden auf der
Konsole Meldungen ausgegeben, die den Benutzer über die vermutlich falsch erkannten
Schema-Attribute informieren. Des weiteren erfolgt eine Ausgabe, wenn Dokumente bei
der Suche auf der Webseite gefunden wurden, diese aber von der Konfigurationsdatei
nicht bzw. nur fehlerhaft extrahiert wurden.
Sind nicht für alle Ergebnisse die passenden XPath-Ausdrücke gefunden worden, ist eine
manuelle Weiterbearbeitung der neu erstellten Konfigurationsdatei erforderlich. Meldet
das Reinduction-Tool die Erstellung einer korrekten Konfigurationsdatei, sollte trotzdem
vor allem zu Beginn der Nutzung des Reinduction-Tools die Korrektheit manuell
59

KAPITEL 6. VORGEHENSWEISE DES REINDUCTION-TOOLS
überprüft werden. Weil bei der Entwicklung des Reinduction-Tools einige Annahmen bezüglich
der Struktur des XHTML getroffen werden mußten, werden nicht alle möglichen
Strukturen im Reinduction-Tool berücksichtigt sein. Durch die manuelle Überprüfung
der Konfigurationsdatei können eventuelle Probleme des Reinduction-Tools, die bei der
Evaluierung nicht aufgetreten sind, gefunden und behoben werden. Auf diese Weise ist
eine schrittweise Weiterentwicklung des Reinduction-Tools möglich. Nachfolgend ist ein
Beispiel für eine durch das Reinduction-Tool erstellte Konfigurationsdatei dargestellt.
60

KAPITEL 6. VORGEHENSWEISE DES REINDUCTION-TOOLS
6.2 Vorgehensweise bei Detailseiten
Weil die Detailseiten im Gegensatz zu den Übersichtsseiten aus einzelnen Dokumenten
bestehen, unterscheidet sich die Vorgehensweise des Reinduction-Tools bei der Erstellung
einer Konfigurationsdatei von der bei Übersichtsseiten. Im Rahmen dieser Diplomarbeit
wurde nur der Teil des Reinduction-Tools für die Übersichtsseiten umgesetzt.
Deswegen wird nachfolgend nur die angestrebte Vorgehensweise erläutert. Die grobe
Struktur (s. 6.4) bleibt von diesen Änderungen allerdings unberührt. Eine Ausnahme
bildet hier der Präzisierungsschritt der Iteration. Dieser Schritt kann entfallen, da die
Iterationen nur noch bei der Selektion von mehrfach vorkommenden Schema-Attributen
innerhalb eines Dokumentes genutzt werden. Zwischen diesen ist allerdings ein starker
räumlicher Bezug zu erwarten, deshalb reicht eine einfache Erstellung der Iterationen
aus.
Vor dem Start des Reinduction-Tools muß weiterhin manuell überprüft werden, ob die
Anfragestruktur und die Logdateien eine Überarbeitung erfordern. Daran schließt sich
ebenfalls die Suche nach dem Template an. Beim Laden der Daten werden, im Unterschied
zu den Übersichtsseiten, die Logdateien für die einzelnen Dokumente geladen.
Anschließend erfolgt analog zur Vorgehensweise bei den Übersichtsseiten die freie Suche.
Allerdings werden bei dieser die Schema-Attribute aus allen Logdateien gesucht.
Es ist davon auszugehen, daß die Wahrscheinlichkeit mehrfach auf einer Seite vorkommender
Schema-Attributwerte mit steigender Länge des Schema-Attributwertes sinkt.
Deswegen erfolgt die Behandlung der unsicheren Schema-Attribute nicht mit dem Intervallverfahren,
sondern durch die Sortierung der Schema-Attribute eines Dokumentes
nach absteigender Länge.
Die Iterationen werden auf den Detailseiten nur noch dazu verwendet, um einzelne
Schema-Attribute zu selektieren, die mehrfach vorkommen. Dabei bleiben die Prinzipien
für die Bildung von Iterationen jedoch identisch. Im Anschluß an die Iterationen
werden die Extraktionen gebildet. Dabei besteht ein Unterschied zur Vorgehensweise bei
den Übersichtsseiten, weil die Positionen der XPath-Ausdrücke für die Schema-Attribute
in den verschiedenen Dokumenten möglichst identisch sein sollten. Der weitere Ablauf
ist mit Ausnahme der fehlenden Präzision der Iterationen analog zu der Vorgehensweise
bei den Übersichtsseiten. Allerdings entfällt bei den Detailseiten die Wiederholung
des Verfahrens aufgrund der parallelen Verwendung der Logdateien. Wegen des ähnlichen
Ablaufs werden im folgenden nur noch die Schritte näher erläutert, die sich vom
Verfahren bei Übersichtsseiten unterscheiden.
61

KAPITEL 6. VORGEHENSWEISE DES REINDUCTION-TOOLS
Überprüfung der Anfragestruktur
und der Logdateien
Suchen der Templates
Laden der Daten
Freie Suche
Behandlung der unsicheren Attribute
Finden der Iterationen
Finden der Extraktionen
Trennung von Schema-Attributen
Bildung von regulären Ausdrücken
Test der Konfigurationsdatei
Abbildung 6.4: Vorgehensweise des Wrappertools
62
Quelle: eigene Darstellung

KAPITEL 6. VORGEHENSWEISE DES REINDUCTION-TOOLS
6.2.1 Laden der Daten
Die erste Änderung betrifft das Laden der Daten. Hier werden nun nicht mehr die Result-
Dateien, sondern die Document-Dateien geladen. Da die Bezeichnungen der Document-
Dateien mit den URLs, unter denen diese Dateien zu finden sind, übereinstimmen,
werden beim Laden der Document-Dateien auch gleichzeitig die URLs geladen. Hierbei
werden die Dateien nicht, wie bei den Übersichtsseiten, nacheinander abgearbeitet
bis der Test für die Konfigurationsdatei erfolgreich verläuft. Weil jede Datei nur ein
Dokument enthält, werden nun alle verfügbaren Logdateien gleichzeitig geladen und
untersucht, damit bei den Extraktionen und Iterationen auch ein Vergleich der XPath-
Ausdrücke möglich ist.
6.2.2 Behandlung der unsicheren Schema-Attribute
Die Wahrscheinlichkeit für kürzere Schema-Attributwerte, wie z. B. Namen oder Datumsangaben,
häufiger auf der Detailseite vorzukommen, ist relativ hoch. Deswegen sollte
für jeden Schema-Attributwert des Anfrageergebnisses aus einer Logdatei die Länge
bestimmt werden. Danach sind die Schema-Attribute eines Ergebnisses mit Hilfe eines
Sortieralgorithmus der Länge nach zu ordnen. Anschließend sollte die Suche jeweils bei
dem Schema-Attribut mit dem längsten Wert begonnen werden, das noch nicht gesucht
wurde. Die Stellen des XHTML-Dokumentes, an denen gefundene Schema-Attribute
stehen, die bereits eindeutig zugewiesen werden konnten, sollten bei den nachfolgenden
Suchprozessen nicht mehr berücksichtigt werden. Mit dieser Vorgehensweise senkt sich
die Wahrscheinlichkeit, unsichere Schema-Attribute zu finden.
6.2.3 Finden der Extraktionen
Weil jede Detailseite nur ein Dokument enthält, müssen die XPath-Ausdrücke für die
einzelnen Schema-Attribute mit denen von anderen Anfragen verglichen werden. Handelt
es sich, wie vorausgesetzt (s. 4.2.3), um einen regulären Wrapper, müssen sich die
Schema-Attribute für alle Anfragen an derselben Position befinden. Demzufolge müssen
die gefundenen XPath-Ausdrücke für die Schema-Attribute auch übereinstimmen. Ist
dies der Fall, können die gefundenen XPath-Ausdrücke unverändert bleiben. Ansonsten
wird nach Übereinstimmungen im vorhergehenden bzw. nachfolgenden Textknoten
gesucht.
63

Kapitel 7
Evaluierung der Ergebnisse
Im folgenden Kapitel sollen die entwickelten Ideen anhand des erstellten Reinduction-
Tools getestet werden. Um bei der Evaluierung wirklich aussagekräftige Ergebnisse erzielen
zu können, muß das Reinduction-Tool anhand hinreichend vieler Datensätze getestet
werden. Dies ist im Rahmen einer Diplomarbeit nicht in dem eigentlich erforderlichem
Maße zu leisten. Die folgende Evaluierung soll deswegen anhand einiger Wrapper die
Qualität des entwickelten Tools bewerten.
7.1 Evaluierungsmöglichkeiten
Grundsätzlich kommt eine Evaluierung anhand von gebrochenen und funktionierenden
Wrappern in Frage. Darüber hinaus kann ein Wrapper für die Evaluierung auch künstlich
gebrochen werden. Weiterhin besteht auch noch die Möglichkeit, für eine neue digitale
Bibliothek manuell Logdateien zu erstellen.
7.1.1 Evaluierung anhand gebrochener Wrapper
Weil das Reinduction-Tool in erster Linie für die Pflege von Wrappern entwickelt wurde,
sollte die Evaluierung auch anhand eines gebrochenen Wrappers erfolgen. Falls dabei
nicht gewünschte Ergebnisse erzielt worden sind, sollte nach der Ursache geforscht werden.
So könnte es sich z. B. um einen nicht regulären Wrapper handeln. Da in dem zur
Verfügung stehenden Entwicklungszeitraum allerdings kein Wrapper gebrochen wurde,
konnte diese Evaluierungsmethode nicht zum Einsatz kommen.
64

KAPITEL 7. EVALUIERUNG DER ERGEBNISSE
7.1.2 Evaluierung anhand funktionierender Wrapper
Als Alternative zur Evaluierung mit gebrochenen Wrappern bietet sich die Evaluierung
anhand von digitalen Bibliotheken an, für die bereits ein funktionierender Wrapper
existiert. Weil das Reinduction-Tool nicht auf die alte Konfigurationsdatei zurückgreift,
reicht diese Evaluierungsform vollkommen aus. Dieses Verfahren hat im Vergleich zu
den im folgenden dargestellten Methoden den Vorteil, daß gleichzeitig getestet werden
kann, ob die Aktualität der Logdateien eine Rolle spielt. Dieses Vorgehen ist deswegen
mit der Evaluierung anhand von gebrochenen Wrappern vergleichbar.
7.1.3 Evaluierung anhand von manuell generierten Logdateien
Eine weitere Möglichkeit ist es, zu neuen digitalen Bibliotheken manuell Logdateien
erstellen zu lassen. Dazu werden Testanfragen an die digitale Bibliothek gestellt. Von
den Ergebnisseiten werden manuell die Schema-Attribute extrahiert und im Format der
MIND-Logdateien mit Hilfe eines Editors in eine Datei geschrieben. Weil die Erzeugung
der Logdateien explizit erfolgt, um das Reinduction-Tool einzusetzen, wird die
Aktualität der Logdateien bei dieser Evaluierungsmethode nur eine geringe Rolle spielen.
Eine erfolgreiche Evaluierung mit manuell erzeugten Logdateien würde die Eignung
des Reinduction-Tools auch zur Erstellung neuer Wrapper zeigen.
7.1.4 Evaluierung mit künstlich gebrochenen Wrappern
Die letzte Methode zur Evaluierung ist, für eine digitale Bibliothek eine neue HTML-
Ansicht erstellen zu lassen. Sie stellt einen Dummy für eine Layoutänderung der ursprünglichen
Bibliothek dar. Als Datengrundlage können hier die Logdateien eines bereits
vorhandenen Wrappers dienen. Somit stehen gleichzeitig die Logdateien mit den
Ergebnissen zur Verfügung. Dadurch ist die Voraussetzung für das Reinduction-Tool
erfüllt, daß die mitgeloggten Dokumente auf den Seiten wieder zu finden sein müssen.
Lediglich die mitgeloggten URLs müssen entsprechend der Adresse der neu erzeugten
digitalen Bibliothek angepaßt werden. Diese Evaluierungsmethode hat den Vorteil, daß
die Seiten leicht zu verändern sind. Somit können die Ergebnisse des Tools auch in
Abhängigkeit von kleinen Layoutänderungen schrittweise untersucht werden.
7.1.5 Evaluierung für Daffodil-Wrapper
Einige der digitalen Bibliotheken aus dem Daffodil-Projekt stehen auch in MIND zur
Verfügung. Für diese Bibliotheken werden die Anfragen von MIND an Daffodil weitergeleitet.
MIND erhält dann auch lediglich das Ergebnis der Anfrage von Daffodil. Diese
65

KAPITEL 7. EVALUIERUNG DER ERGEBNISSE
Evaluierungsmethode kann erste Hinweise auf die Einsatzmöglichkeiten des entwickelten
Tools bei allgemeinen Wrappern geben.
7.2 Evaluierung
Im folgendem Abschnitt werden nun die Ergebnisse für die vorgestellten Evaluierungsmöglichkeiten
beschrieben. Da es eine Vielzahl von Möglichkeiten gibt, einen Knoten zu
selektieren, kommen grundsätzlich mehrere Lösungen in Frage. Dabei ist es durchaus
möglich, daß die erzeugte Konfigurationsdatei Bedingungen enthält, die nicht notwendig,
deren Erstellung aber die Arbeit des Reinduction-Tools insgesamt verbessert. Weil
diese nicht notwendigen Bedingungen aber die Selektierung der Schema-Attribute nicht
negativ beeinflußt, spielen sie bei der Bewertung allerdings keine Rolle. Das Kriterium
hierfür ist lediglich die Korrektheit der Konfigurationsdatei. Diese ist gegeben, wenn alle
Schema-Attribute, die auf der Webseite enthalten sind, richtig erkannt werden. Dabei
wird nicht berücksichtigt, ob sie in der Logdatei enthalten sind. Außerdem sollen durch
die Evaluierung auch evtl. noch bestehende Probleme des Tools herausgearbeitet werden,
damit im weiteren Verlauf noch eine Erarbeitung von Verbesserungsvorschlägen
erfolgen kann.
7.2.1 Evaluierung anhand funktionierender Wrapper
Weil das Reinduction-Tool HTML-Seiten parsen muß, stehen für die Evaluierung anhand
von funktionierenden Wrappern 12 Wrapper aus dem MIND Projekt zur Auswahl.
Dabei scheidet der Wrapper für die National Gallery of Art in Washington von vornherein
aus, weil er zu unregulär ist (s. 4.2.3). Außerdem wird der Wrapper für die Fine
Arts Museums of San Francisco auch Probleme bereiten, weil die Ergebnisse in zwei
Spalten angezeigt werden (s. 5.6). Getestet wurde die Pflege von Wrappern anhand der
digitalenen Bibliotheken 1 (BIBDB) und der Web Gallery of Art 2 . (WebArt)
Die BIBDB umfaßt bibliographische Referenzen zum Information Retrieval und verwandten
Themengebieten. Bei dem Test sortierte das Reinduction-Tool eine Logdatei
aus, weil sie nicht alle Schema-Attribute enthielt. Im Anschluß daran konnte dann mit
der ersten Logdatei eine korrekte Konfigurationsdatei erstellt werden. Die Bewertung
durch das Tool selbst verlief ebenfalls positiv.
Die Bibiliothek WebArt enthält digitale Reproduktionen von Bildern und Skulpturen europäischer
Künstler. Im ersten Versuch konnte keine Konfigurationsdatei erstellt werden.
1 http://www.is.informatik.uni-duisburg.de/bib/bibdb.html
2 http://www.kfki.hu/~arthp/index1.html
66

KAPITEL 7. EVALUIERUNG DER ERGEBNISSE
Eine Überprüfung der Logdateien ergab, daß das Schema-Attribut image-url die URLs
von Thumbnails enthielt, die von MIND generiert wurden. Dadurch müssen bei der Nutzung
von MIND die dort gespeicherten Bilder bei der nächsten Anfrage nicht mehr von
der WebArt-Webseite übertragen werden. Damit das Schema-Attribut image-url auch
auf der Webseite enthalten ist, wurden in der Konfigurationsdatei die in der Webseite
enthaltenen URLs eingetragen.
Hierauf erzeugte das Tool zwar eine Konfigurationsdatei, konnte diese jedoch nicht testen.
Eine Untersuchung der Ausgaben des Reinduction-Tools ergab, daß die Dokument-
ID auf der Seite nicht gefunden werden konnte. Die Konfigurationsdatei enthielt mit
Ausnahme der Dokument-ID alle Schema-Attribute und selektierte auch die richtigen
Informationen. Ein Vergleich der Ausgaben der Logdateien mit den Ergebnissen auf der
Webseite ergab eine Änderung des Links zu den Detailseiten nach der Erstellung der
Logdatei. Allerdings hatte diese Änderung keine Auswirkungen auf den im Einsatz befindlichen
Wrapper, weil die Position der Dokument-ID sich nicht verändert hat. Nach
einer erneuten manuellen Korrektur der Logdateien konnte eine korrekte Konfigurationsdatei
erstellt werden, die auch die Dokument-ID richtig selektiert.
7.2.2 Evaluierung anhand von manuell generierten Logdateien
Hier stand mit dem Art Atlas 3 (ArtAtlas) eine digitale Bibliothek mit Galeristen zur
Verfügung. Bei der Evaluierung konnte erfolgreich eine Konfigurationsdatei erstellt werden.
Allerdings ist die Dokument-ID nicht wie vorausgesetzt in der Webseite enthalten.
Deswegen kann das Reinduction-Tool die Konfigurationsdateien nicht selbst testen. Eine
manuelle Überprüfung der Konfigurationsdatei hat deren Funktionfähigkeit allerdings
nachgewiesen.
Die Bibliothek Computer Science Bibliographies 4 (csbib) beinhaltet wissenschaftliche
Arbeiten. Beim Test des Reinduktion-Tools wurden zwei Konfigurationsdateien erzeugt.
Wie im obigen Beispiel war die Dokument-ID nicht in der Webseite enthalten. Aufgrund
des fehlenden Selbsttests ist kein Ausschluß einer Datei möglich. Eine Überprüfung der
beiden Konfigurationsdateien hat ergeben, daß die eine korrekt und die andere aufgrund
von unsauberem HTML eine fehlerhafte Iteration enthält. Dies zieht automatisch auch
nicht korrekte Extraktionen nach sich. Allerdings wäre die letzte Datei entfernt worden,
wenn die Dokument-ID in der Webseite wäre.
3 http://artatlas.com/
4 http://liinwww.ira.uka.de/bibliography/
67

KAPITEL 7. EVALUIERUNG DER ERGEBNISSE
7.2.3 Evaluierung mit künstlich gebrochenen Wrappern
Für diese Evaluierungmöglichkeit wurde für die Bibliotheken BIBDB_Test und WebArt_Test
ein anderes Layout erstellt. Die Bibliotheken basieren dabei auf denselben
Logdateien wie die Bibliotheken BIBDB und WebArt (s. 7.2.1). Bei der BIBDB_Test
wurde die Listenstruktur, die bei der BIBDB zur Gliederung genutzt wird, durch eine
Tabellenstruktur ersetzt. Beim Layout von WebArt_Test wird wie in der ursprünglichen
Bibliothek eine Tabellenstruktur verwendet. Allerdings muß nur jede zweite Zeile extrahiert
werden. Darüber hinaus ist die Bildung von regulären Ausdrücken erforderlich.
Für beide Bibliotheken konnten korrekte Konfigurationsdateien erstellt werden. Dabei
verliefen auch die Selbsttests des Reinduction-Tools positiv.
7.2.4 Evaluierung für Daffodil-Wrapper
Zum Abschluß der Evaluierung wurde noch Citeseer 5 getestet. Citeseer enthält ebenfalls
wissentschaftliche Arbeiten. Zum Zeitpunkt der Evaluierung hatte Citeseer Kapazitätsprobleme,
wodurch eine Evaluierung anhand von Citeseer selbst nicht möglich war. Statt
dessen wurde eine Seite mit den Daten von Citeseer in einem neu erstellten Layout getestet.
Bei Citeseer handelt es sich eigentlich um einen Daffodil-Wrapper, an den MIND Anfragen
stellen kann. Diese werden dann von Daffodil bearbeitet und die Ergebnisse
an MIND weitergeleitet. Das Logging für die zum MIND-Projekt gehörenden Daffofil-
Wrapper wird in der Datenstruktur von MIND vorgenommen. Allerdings besteht die
Dokument-ID bei Daffodil aus dem Titel und nicht wie bei MIND selbst aus dem Detaillink.
Bei dem Titel werden jedoch die Leerzeichen entfernt und alle Großbuchstaben
durch kleine Buchstaben ersetzt. Der so bearbeitete Titel ist allerdings nicht mehr in
dem XHTML-Code zu finden. Dadurch kann das Reinduction-Tool die erzeugte Konfigurationsdatei
nicht testen, weil keine eindeutige Zuordnung möglich ist. Weil die manuelle
Überprüfung eine korrekte Erstellung der Konfigurationsdatei ergab, verhinderte
die nicht auf der Webseite enthaltene Dokument-ID zunächst den erfolgreichen Abschluß
der Evaluierung.
Um dieses Problem zu beheben, wurde das Reinduction-Tool erweitert. Bei allen Schema-
Attributen werden nun die Leerzeichen entfernt und die Großbuchstaben in Kleinbuchstaben
umgewandelt. Ist das Resultat mit der Dokument-ID identisch, wird in den
geladenen Dokumenten die Dokument-ID durch den Wert des Schema-Attributes ersetzt.
Die Dokument-ID bleibt dabei in den Logdateien unverändert. Dadurch ist die
Dokument-ID wieder im XHTML-Code zu finden. Beim Testen kann für das jeweilige
5 http://citeseer.nj.nec.com/cs
68

KAPITEL 7. EVALUIERUNG DER ERGEBNISSE
gefundene Dokument anhand der Dokument-ID das entsprechende Dokument aus der
Logdatei identifiziert werden. Dessen Schema-Attributwerte müssen mit den gerade gefundenen
übereinstimmen, wenn eine korrekte Konfigurationsdatei erstellt wurde. Nach
dieser Anpassung konnte auch der letzte Schritt erfolgreich getestet werden.
7.2.5 Performance
Die Evaluierung wurde mit einem 1,8-GHz Rechner unter Nutzung eines DSL-Anschlusses
durchgeführt. Die Zeit für die Erstellung der Konfigurationsdateien betrug 1-10 Minuten.
Weil in allen Dokumenten der mitgeloggten Result-Dateien die enthaltenen Schema-
Attribute geprüft werden, damit die zu erzeugende Konfigurationsdatei auch alle notwendigen
Schema-Attribute enthält, ergeben sich große Unterschiede in der Performance
des Reinduction-Tools.
Um den Aufwand zu minimieren, könnten statt dessen, wenn sich sehr viele Logdateien
angesammelt haben, auch nur die aktuellsten Logdateien bei der Erstellung der neuen
Konfigurationsdatei miteinbezogen werden. Allerdings könnte sich diese Vorgehensweise
negativ auf die Präzision auswirken. Zum anderen macht sich auch bemerkbar, wie
viele Daten die angefragte Webseite enthält. Da diese beiden Punkte nicht unabhängig
von einander sind, weil eine große Menge an Dokumenten in der Logdatei häufig mit
einer großen Anzahl an Dokumenten in der Webseite verbunden ist, werden sie oftmals
gleichzeitig auftreten. Dadurch hat z. B. die Erstellung der Konfigurationsdateien
für WebArt deutlich länger gedauert als die der anderen digitalen Bibliotheken. Eine
manuelle Erstellung von Konfigurationsdateien dauert etwa 4 Arbeitsstunden [Rup02].
Die manuelle Überprüfung einer erstellten Konfigurationsdatei dauert etwa 20 Minuten
Bei einer Laufzeit von 10 Minuten des Reinduction-Tools ist es somit möglich, in einer
halben Stunde eine neue Konfigurationsdatei zu erstellen.
7.3 Bewertung des Wrapperwerkzeugs
Bei der Evaluierung gab es Probleme, weil die Werte der Schema-Attribute nicht auf
den Webseiten der digitalen Bibliotheken enthalten waren. Als problematisch erwies
sich ebenfalls die Veränderung der Daten, die in der Webseite enthalten sind, wie z. B.
die Detaillinks bei WebArt. Um diese Probleme in Zukunft zu vermeiden, sollten die
Logdateien erstellt werden, bevor die Veränderung der Daten erfolgt. Die Probleme, die
sich aus den fehlenden Dokument-IDs ergeben, können ebenfalls gelöst werden, indem
als Dokument-IDs Daten genommen werden, die in der Webseite enthalten sind.
69

KAPITEL 7. EVALUIERUNG DER ERGEBNISSE
Für alle ausgewählten digitalen Bibliotheken konnten, ggf. nach einer Anpassung der
Logdateien an die Voraussetzungen, korrekte Konfigurationsdateien erzeugt werden. Die
Vermutung, daß die Qualität der semiautomatisch erstellten Konfigurationdatei stark
von der Anzahl der vorhandenen Anfragen und den zugehörigen Ergebnissen abhängt,
konnte nicht bestätigt werden. Ein Ausnahme bildete hier die BIBDB, weil in der ersten
Logdatei ein Schema-Attribut in keinem der Dokumente enthalten war.
Probleme gab es, wenn im HTML-Code die schließenden Teile der HTML-Elemente
fehlten. Weil diese bei XHTML-Dokumenten notwendig sind, muß Tidy bei der Umwandlung
in XHTML entscheiden, wo ein Element endet. Dabei werden die schließenden
Teile der Elemente teilweise an die falsche Stelle gesetzt. So wird z. B. für ein Dokument
eine zusätzliche Tabelle definiert, während das bei den anderen Dokumenten auf
derselben Webseite nicht der Fall ist. Dadurch ist es schwierig, eine funktionierende
Konfigurationsdatei automatisch zu erstellen. Zwar wurden bereits einige Vorkehrungen
im Reinduction-Tool getroffen (s. 6.1.7), jedoch sollten die genauen Auswirkungen
von unsauberen HTML bei der Umwandlung in XHTML durch Tidy noch näher untersucht
werden. Dadurch könnte das Reinduction-Tool im Hinblick auf die zu erwartenden
Probleme, die vor allem bei der Erstellung der Extraktionen auftreten, verändert werden.
7.4 Weitere Aspekte der Bewertung
Im folgenden Abschnitt werden einige Aspekte beschrieben, die noch weiter zu untersuchen
sind. Deweiteren wird auf einige Punkte hingewiesen, die für das Reinduction-Tool
bisher nocht nicht realisiert wurden, die allerdings bei den getesteten digitalen Bibliotheken
nicht notwendig waren.
Im Rahmen einer detaillierten Evaluierung sollte auch überprüft werden, wie das
Reinduction-Tool auf ein schlechteres Verhältnis von mitgeloggten Dokumenten zu Dokumenten
auf einer Seite insgesamt reagiert. Wichtig ist aber auch die Position der
mitgeloggten Dokumente. Sind z. B. drei mitgeloggte Dokumente vorhanden, aber die
Ergebnisseite liefert 100 Dokumente zurück, so besteht ein gravierender Unterschied, ob
die drei mitgeloggten Datensätze am Anfang der Übersichtsseite stehen oder ob sie sich
gleichmäßig über die Übersichtsseite verteilen. Im ersten Fall könnte es möglich sein,
die ersten beiden Datensätze zuzuordnen. Im zweiten Fall wird nur eine Reduzierung
der Kandidaten für die XPath-Ausdrücke möglich sein. Prinzipiell ist der Erfolg größer,
je mehr mitgeloggte Daten für die entsprechende Übersichtsseite vorhanden sind.
Hierzu könnte die Anzahl der auf einer Seite gesuchten mitgeloggten Daten schrittweise
reduziert werden. Zudem könnten die überprüften Webseiten gespeichert und manuell
verändert werden, um die Probleme des Tools zu lokalisieren.
70

KAPITEL 7. EVALUIERUNG DER ERGEBNISSE
Besonders problematisch wird allerdings eine Verteilung der mitgeloggten Ergebnisse
auf mehrere Übersichtsseiten sein. Dies gilt insbesondere, wenn kein bzw. nur eines
der mitgeloggten Ergebnisse auf der ersten Übersichtsseite zu finden ist. Dieses Problem
wird vor allem bei Wrappern für Webservices auftreten, bei denen die Datenbasis
großen Änderungen unterliegt. Allerdings hängt das Ergebnis in diesem Fall auch von
der gestellten Anfrage ab. Es wird bei einer Anfrage nach ”President” viel schwieriger
sein, die alten Ergebnisse wiederzufinden als bei einer Suche nach ”Retrieval”, weil im
ersten Fall das Ergebnis deutlich schneller auf nachfolgenden Übersichtsseiten zu finden
sein wird als im zweiten Fall. Wenn bei der gestellten Anfrage die erläuterten Probleme
auftreten, wird zunächst einmal versucht, mit anderen Anfragen zu arbeiten. Bei
einem Wrapper für ein Kunstmuseum wird die Fluktuation der Daten dagegen generell
deutlich geringer ausfallen.
Das Reinduction-Tool kann momentan nur Schema-Attribute finden, deren Inhalt auf
der Webseite ohne störende Zeichen innerhalb des Schema-Attributes vorkommen. Um
diese Einschränkung aufzuheben, müßte jedes Schema-Attribut in Token zerlegt werden
und die Suche nach den einzelnen Token erfolgen. Aus den XPath-Ausdrücken für die
einzelnen Token muß ein XPath-Ausdruck gebildet werden, der alle Token selektiert. Der
Inhalt, den dieser XPath-Ausdruck zurück liefert, muß noch mit regulären Ausdrücken
bearbeitet werden. Könnte das Schema-Attribut auch in zwei Schema-Attribute aufgeteilt
werden und sind die störenden Zeichen nur zwischen den Schema-Attributen und
nicht innerhalb der Schema-Attribute, so kommt das Reinduction-Tool damit klar, wenn
diese Schema-Attribute in den Logdateien auch getrennt enthalten sind.
Die Tidykomponente der Konfigurationsdatei bekommt vom Reinduction-Tool keine
Elemente zugewiesen, somit wird die Ersetzung der Entitäten ausschließlich von Tidy
vorgenommen. Allerdings war bei den getesteten Beispielen auch keine zusätzliche
Umwandlung, wie z. B. die Entfernung von störenden Leerzeichen, erforderlich.
Findet das Reinduction-Tool kein einziges Schema-Attribut wieder, so ist dies ein deutliches
Indiz für eine akute Einschränkung der Webseiten in ihrer Funktionalität. Das
kann z. B. durch eine Überlastung des Servers oder den Ausfall eines Datenbank-Servers
bedingt sein. Allerdings handelt es sich hierbei um ein grundsätzliches Problem, das bei
der Erstellung von Wrappern immer auftreten kann. Deswegen ist es bei der Bewertung
des Reinduction-Tools zu vernachlässigen.
71

Kapitel 8
Übertragbarkeit des
Wrapperwerkzeugs
Im folgenden Kapitel werden die Anwendungsmöglichkeiten des Reinduction-Tools auf
andere Wrappertypen untersucht. Dabei werden die drei Fälle der Übertragbarkeit auf
nicht reguläre Wrapper, auf allgemeine Wrapper sowie die Einsatzmöglichkeiten bei der
Erstellung neuer Wrapper diskutiert.
8.1 Übertragbarkeit auf nicht reguläre Wrapper
Ist ein Wrapper nicht regulär wie die vom Toolkit behandelten, wird das Setzen der
Schema-Attribute mit Hilfe von Iterationen über die zurückgelieferten Ergebnisse der
Toolkits meistens nicht funktionieren. Diese Fälle erfordern innerhalb des
MIND-Wrappers noch eine Überprüfung, ob die XPath-Ausdrücke tatsächlich die richtigen
Schema-Attribute gefunden haben. Insofern ist bei einem Einsatz des Reinduction-
Tools bei nicht regulären Wrappern eine Nachbearbeitung erforderlich. Allerdings gibt
es nicht reguläre Wrapper, bei denen eine Generalisierung der XPath-Ausdrücke für
einzelne Schema-Attribute möglich ist. Für diese Schema-Attribute wird dann der entsprechende
Teil der Konfigurationsdatei erstellt. Speziell für die nicht regulären Wrapper
könnte noch eine Erweiterung für das Reinduction-Tool erzeugt werden, die versucht,
alle eindeutig zugewiesenen XPath-Ausdrücke der Schema-Attribute, die noch nicht in
der Konfigurationsdatei berücksichtigt worden sind, unabhängig von den zugehörigen
Schema-Attributen zusammenzufassen. Diese Ausdrücke können dann ohne konkreten
Schema-Attributnamen in die Konfigurationsdatei übernommen werden. Die Zuordnung
der Schema-Attribute ist dann im Java-Code zu ändern.
72

KAPITEL 8. ÜBERTRAGBARKEIT DES WRAPPERWERKZEUGS
Ist die digitale Bibliothek nach der Änderung des Layouts der HTML-Seite auf dieselbe
Art unregulär wie vor der Layoutänderung, kann die Nachbearbeitung des Java-Codes
entfallen. Bei dem aktuellen Wrapper für die National Gallery of Art in Washington
werden z. B. für die Detailseite Knoten mit verschiedenen XPath-Ausdrücken selektiert.
Danach wird mit Hilfe von regulären Ausdrücken überprüft, welches Schema-Attribut
an welcher Stelle steht. Würden sich lediglich die XPath-Ausdrücke und nicht die Bedingungen,
nach denen die einzelnen Schema-Attribute zugeordnet werden, ändern, so
könnte das entwickelte Wrapperwerkzeug mit der beschriebenen Erweiterung auch ohne
Nachbearbeitung durchaus erfolgreich eingesetzt werden.
8.2 Übertragbarkeit auf allgemeine Wrapper
Das Ziel des entwickelten Tools ist die Erstellung einer neuen Konfigurationsdatei für
das Wrapper Toolkit. Insofern ist die Grundvoraussetzung für die Übertragbarkeit auf
allgemeine Wrapper, daß diese Wrapper mit dem Toolkit arbeiten. Im folgenden Abschnitt
wird für die einzelnen Schritte des Reinduction-Tools untersucht, ob sie bei
allgemeinen Wrappern angepaßt werden müssen.
Weil die Überprüfung der Anfragestruktur ein manueller Arbeitsschritt ist, muß hier
keine Änderung erfolgen. Da die von MIND mitgeloggten Daten in einer speziell entwickelten
Datenstruktur vorliegen, arbeitet das Reinduction-Tool ebenfalls mit dieser
Datenstruktur. Deswegen müssen bei allgemeinen Wrappern die Logdateien ebenfalls in
diesem Format vorliegen. Dazu ist eine Erweiterung der Wrapper um ein entsprechendes
Logging erforderlich. Sind diese Dateien vorhanden, ist das Laden der Daten kein Problem.
Beim Laden der Dateiseiten wird von einer Übereinstimmung des Dateinamens
und der URL der Ergebnisseite ausgegangen. Deswegen ist es besonders wichtig, daß
die Dateinamen die URL auch beinhalten. Ansonsten muß das Reinduction-Tool beim
Laden der Daten angepaßt werden, damit wie bei den Übersichtsseiten ebenfalls die
Logdatei mit der URL geladen werden kann.
Die weiteren Arbeitsschritte aus der Vorgehensweise verwenden die geladenen Daten
bzw. die aktuellen Daten der neu gestellten Anfrage. Deswegen sind hier bei der Übertragbarkeit
auf andere Wrapper keine Probleme zu erwarten. Die zweite Voraussetzung
bei der Übertragbarkeit auf allgemeine Wrapper ist die Erstellung der Logdateien im
Format der MIND-Logdateien. Hierbei wäre noch näher zu untersuchen, inwieweit die
Erstellung des benötigten Formates der jeweiligen Logdateien zu Problemen bei allgemeinen
Wrappern führen könnte. Bei der Evaluierung von Wrappern aus dem Daffodil-
Projekt stellte sich z. B. die unterschiedliche Zuweisung der Dokument-ID als Schwierigkeit
heraus (s. 7.1.5). Allerdings ist dieses Problem bereits behoben worden, d. h. es
gibt bei allgemeinen Wrappern mehr Möglichkeiten bei der Zuordnung der ID.
73

KAPITEL 8. ÜBERTRAGBARKEIT DES WRAPPERWERKZEUGS
Als Alternative zur Anpassung des Loggings selbst könnte noch ein Tool zur Vorprozessierung
entwickelt werden, das die Logdateien der allgemeinen Wrapper auf die Datenstruktur
von MIND abbildet. Allerdings muß in diesem Fall für jeden neuen Logdateityp
eine Anpassung dieses Vorprozessierungstools vorgenommen werden.
8.3 Übertragbarkeit auf die Erstellung neuer Wrapper
Nachfolgend wird die Erstellung einer Konfigurationsdatei für neue digitale Bibliotheken
unter Verwendung des Reinduction-Tools beschrieben. Falls sich die Anfragestruktur
verändert hat, wurde sie bei zu pflegenden Wrappern manuell neu erstellt. Dieser Teil
läßt sich insofern problemlos auch auf die Erstellung von neuen Wrappern übertragen.
Das gleiche gilt für die Suche nach dem Template.
Vor dem Laden von Daten müßten vorhandene Daten simuliert werden. Dazu würden
die Ergebnisse manuell aus der Seite ausgelesen und im Format von mitgeloggten Daten
gespeichert. Diese Eingabe könnte einfach mit Hilfe eines Editors erfolgen.
Bei der Sortierung der Schema-Attribute und der freien Suche könnte wie bei der Pflege
von Wrappern verfahren werden. Die Suche nach regulären Ausdrücken könnte ebenfalls
zum Einsatz kommen. Zum Abschluß ließe sich ebenfalls, wie gewohnt, die Konfigurationsdatei
erstellen und testen. Somit besteht der wesentliche Unterschied zwischen der
Pflege von Wrappern und der Erstellung von neuen Wrappern in den nicht zur Verügung
stehenden Logdateien. Bei der Erstellung von neuen Wrappern müßten selbstverständlich
auch die anderen Schritte, die zur Erzeugung eines Wrappers erforderlich sind,
durchgeführt werden. Bei MIND wären das z. B. die Erstellung des MIND-Schemas
und der zugehörigen Java-Klassen. Da das entwickelte Reinduction-Tool ohne die Konfigurationsdatei
des gebrochenen Wrappers auskommt, läßt es sich unter den genannten
Voraussetzungen auch bei der Erzeugung von neuen Wrappern nutzen (s. 7.2.2).
74

Kapitel 9
Fazit und Ausblick
Im letzten Kapitel werden die Ergebnisse der vorliegenden Diplomarbeit zusammengefaßt
und einer kritischen Betrachtung unterzogen. Im Anschluß daran werden noch
Ideen für die Erweiterung und Optimierung des Reinduction-Tools vorgestellt.
9.1 Fazit
In der vorliegenden Arbeit wurde zunächst der Aufbau von digitalen Bibliotheken untersucht.
Dabei wurden Unterschiede zwischen Übersichts- und Detailseiten festgestellt.
Diese bezogen sich auf die Anzahl der in den Seiten enthaltenen Dokumente. Das MIND-
Projekt faßt heterogene, verteilte digitale Bibliotheken zusammen, indem es Anfragen
an geeignete digitale Bibliotheken weiterleitet. Für jede Bibliothek existiert dabei ein
Wrapper, der die Ergebnisse der Anfrage aus den Webseiten extrahiert. Die Wrapper
nutzen dafür die Struktur der HTML-Seiten, um die Informationen mit Hilfe von XPath-
Ausdrücken zu selektieren. Bisher erfolgt die Erstellung der Wrapper manuell. Dabei
besteht die größte Schwierigkeit darin, die passenden XPath-Ausdrücke zu finden. Die
Nutzung der Struktur der HTML-Seiten, zu der keine Alternative existiert, hat allerdings
den Nachteil, daß eine Layoutänderung der Webseite in den meisten Fällen eine
Überarbeitung des Wrappers nach sich zieht. In den vorherigen Kapiteln wurde deswegen
an der Entwicklung eines Tools für eine semiautomatische Pflege von Wrappern
gearbeitet.
Aus der Untersuchung von verwandten Arbeiten ergaben sich Ideen für die Erstellung
des Reinduction-Tools. Im Unterschied zu den Wrappern des MIND-Projektes arbeiten
die Wrapper in den vorgestellten Arbeiten jedoch nicht mit XPath-Ausdrücken. Es
75

KAPITEL 9. FAZIT UND AUSBLICK
wurde untersucht, welche Datengrundlagen dem zu entwickelnden Tool zur Verfügung
gestellt werden könnten. Im weiteren Verlauf der Arbeit kristallisierte sich heraus, daß
die Logdateien der Ergebnisse sowie deren URLs benötigt werden. Bei der Entwicklung
des Reinduction-Tools wurde vorausgesetzt, daß die Inhalte der Dokumente aus den
Logdateien weiterhin in den Webseiten enthalten sind. Das Tool wurde nur für reguläre
Wrapper entwickelt. Bei diesen Wrappern sind die Informationen bei allen Dokumenten
an denselben Positionen zu finden. Weil seltener eine Änderung der Struktur der
Anfrage als der des Layouts der Webseiten erwartet wird, wurde die Überarbeitung der
Anfragestruktur von den weiteren Überlegungen zur Entwicklung des Tools ausgeschlossen.
Im Anschluß daran wurde das Wrappertoolkit vorgestellt, das eine Vereinfachung bei der
Wrappererstellung ermöglicht. Im Mittelpunkt steht dabei die Entwicklung einer Konfigurationsdatei.
Diese muß im XML-Format erstellt werden und beinhaltet die XPathund
regulären Ausdrücke, die zur Selektierung der Daten genutzt werden. Dabei werden
diese vom Java-Code losgelöst. Die Erstellung von XML-Dateien gestaltet sich einfacher
als die Generierung von Java-Code. Dies gilt insbesondere bei einer automatischen
Erstellung. Deswegen wurde im folgenden die Nutzung des Toolkits vorausgesetzt. Bei
einer Layoutänderung ist lediglich die Konfigurationsdatei zu überarbeiten. Deswegen
wurde eine semiautomatische Überarbeitung der Konfigurationsdatei angestrebt.
Das Tool arbeitet zunächst mit absoluten XPath-Ausdrücken, weil diese aufgrund ihrer
automatischen Generierung untereinander vergleichbar sind. Bei Bedarf werden sie im
Verlauf in relative Ausdrücke umgewandelt. Bereits aus der Untersuchung der weiterführenden
Arbeiten hat sich ergeben, daß die Teile der Webseiten, die sich nicht ändern,
von der Suche nach den Schema-Attributen der Dokumente auszuschließen sind.
In einer Vielzahl der Fälle werden die Werte der Schema-Attribute mehrfach auf den
Webseiten enthalten sein. Deswegen wurden Verfahren entwickelt, mit denen für unsichere
Schema-Attribute der passende XPath-Ausdruck zugeordnet werden kann.
Auf der Basis dieser Überlegungen wurde für die Übersichtsseiten ein Prototyp des
Reinduction-Tools erstellt. Der zentrale Punkt ist hierbei die Behandlung der unsicheren
Schema-Attribute. Dabei kommt ein Intervallverfahren zum Einsatz, das anhand von
sicheren Schema-Attributen eine Reihenfolge der Dokumente erstellt und Intervallgrenzen
für diese Dokumente bestimmt. Durch eine schrittweise Verkleinerung der Intervalle
werden die Kandidaten für die unsicheren Schema-Attribute reduziert. Auf Basis der
eindeutig zugewiesenen Xpath-Ausdrücke werden dann nacheinander die einzelnen Teile
der Konfigurationsdatei zugewiesen. Das Reinduction-Tool kann die erzeugte Konfigurationsdatei
selber testen. Dazu werden die Ergebnisse der Logdatei, die auch auf der
Webseite enthalten waren, mit den Ergebnissen der Konfigurationsdatei verglichen.
76

KAPITEL 9. FAZIT UND AUSBLICK
Die Evaluierung des umgesetzten Teils des Reinduction-Tools ergab, daß für alle getesteten
digitalen Bibliotheken eine korrekte Konfigurationsdatei erzeugt werden konnte.
Allerdings wurden dafür teilweise manuelle Korrekturen der Logdateien vorgenommen.
Das Logging sollte deswegen im Hinblick auf die automatisierte Pflege von Wrappern
erfolgen, bevor die Daten verändert werden. Des weiteren sollten die Dokument-IDs so
ausgewählt werden, daß sie in den Webseiten enthalten sind. Die Untersuchungen zur
Übertragbarkeit der entwickelten Ideen ergaben eine notwendige Nachbearbeitung der
erzeugten Konfigurationsdatei bei nicht regulären Wrappern. Alternativ ist auch eine
Weiterentwicklung des Reinduction-Tools denkbar. Bei allgemeinen Wrappern sowie für
die Erstellung neuer Wrapper wird die Nutzung des Toolkits für eine Übertragbarkeit
vorausgesetzt. Zusätzlich müssen die mitgeloggten Ergebnisse im MIND-Format zur
Verfügung gestellt werden.
Das entwickelte Reinduction-Tool wird jedoch nicht für jede digitale Bibliothek eine
neue Konfigurationsdatei erzeugen können. Dies gilt nicht nur für die bereits angesprochenen,
nicht regulären digitalen Bibliotheken, sondern auch für Schema-Attribute, zu
deren Selektion mehrere reguläre Ausdrücke nacheinander erforderlich sind. Weil das
Reinduction-Tool die Struktur des HTML ausnutzt, um die Daten zu finden, sind Annahmen
zu dieser Struktur gemacht worden. Aufgrund der Vielzahl von Gestaltungsmöglichkeiten
von HTML wird es auch digitale Bibliotheken geben, für die diese Annahmen
nicht zutreffen. In diesen Fällen wird eine Nachbearbeitung der generierten Konfigurationsdatei
erforderlich sein. Deswegen sollten die erzeugten Konfigurationsdateien
vor allem in der ersten Einsatzzeit noch manuell überprüft werden. Das Reinduction-
Tool sollte anhand der dabei festgestellten Probleme weiterentwickelt werden, um dessen
Möglichkeiten bei der Erstellung von Konfigurationsdateien weiter zu verbessern.
In der vorliegenden Arbeit wurde ein Prototyp für die semitautomatische Pflege von
Wrappern erstellt. Bei der Evaluierung hat sich dieser Prototyp als leistungsfähig erwiesen.
Ein Vorteil des vorgestellten semiautomatischen Ansatzes besteht darin, daß
zur Laufzeit des Reinduction-Tools keine Eingriffe des Benutzers erforderlich sind. Die
manuellen Arbeitsschritte „Überarbeitung der Anfragestruktur“ und „Überprüfung der
Konfigurationsdatei“ kommen vor bzw. nach dem Reinduction-Tool zum Einsatz. Außerdem
kann das Tool selbst bereits Aussagen zur Qualität der Logdatei treffen. Weil
der gewählte Ansatz den alten Wrapper nicht benötigt, ist auch eine Übertragbarkeit
auf allgemeine Wrapper und die Erstellung von neuen Wrappern möglich.
Zwar ist die Performance des Reinduction-Tools recht unterschiedlich, allerdings wird
die Arbeitszeit des Benutzers, im Falle einer erfolgreichen Erzeugung einer Konfigurationsdatei,
auf jeden Fall erheblich reduziert. Der Benutzer muß sich dann lediglich noch
von der Funktionsfähigkeit der Konfigurationsdatei überzeugen. Da das Reinduction-
Tool nach dem Start keine Interaktion erfordert, kann der Benutzer sich während der
77

KAPITEL 9. FAZIT UND AUSBLICK
Laufzeit mit anderem befassen. Durch das Reinduction-Tool ergibt sich somit eine
Arbeitszeit- und Kostenersparnis.
9.2 Ausblick
Im nächsten Abschnitt werden einige Ideen beschrieben, mit denen besserere Konfigurationsdateien
erstellt werden können. Außerdem werden Überlegungen für breitere
Einsatzmöglichkeiten des Tools vorgestellt.
9.2.1 Überarbeitung der Anfragestruktur
Ein Nachteil des entwickelten Tools ist die vorgesehene manuelle Korrektur der Logdateien
für die alten URLs, falls sich die Anfragestruktur geändert hat. Die Überarbeitung
bleibt auch bei automatischer Erstellung der neuen Anfrage weiterhin erforderlich. Eine
Verbesserung des Tools kann erzielt werden, indem es um eine semiautomatische
Überprüfung und Überarbeitung der Anfragestruktur erweitert wird. Hierzu könnten
die Methoden von Kushmerick [Kus] zum Lernen von Anfragestrukturen von Webformularen
angewendet werden. Um das Ausfüllen eines Webformulars zu lernen, müssen
eine Menge von gekennzeichneten Formularen und Feldern mit den zugehörigen Domains
bzw. den zugehörigen Datentypen für jedes Feld eingegeben werden. Ausgegeben
wird eine Funktion, die ein nicht gekennzeichnetes Formular auf die zugehörige Domain
und die zugehörigen Datentypen für die einzelnen Felder abbildet.
Ein Webfomular umfaßt mindestens ein Feld, wobei jedes Feld wiederum ein oder mehrere
Terme umfaßt. Unter dem Begriff Term werden Wörter, Tags, Attribute und andere
Token eines HTML-Dokumentes verstanden. Bei Instanzen von Webformularen handelt
es sich folglich um strukturierte Objekte. Das Ziel des Algorithmus ist es somit,
die zugrundeliegende Struktur zu finden, in dem ein Formular und seine Felder einer
bestehenden Klassifizierung zugeordnet werden. Dazu wird zunächst die Kategorie D
der Domain bestimmt (z. B. Suche nach Büchern). Anschließend wird der Datentyp T
entsprechend der semantischen Kategorie (z. B. Buchtitel) klassifiziert.
Um die Abbildungsfunktion zu erhalten, wird ein Bayesches Netzwerk verwendet, mit
diesem wird der Datentyp von jedem Feld, basierend auf seinen Termen, bestimmt.
Gleichzeitig wird die Domain des Formulars bestimmt, indem die Datentypen der einzelnen
Felder ermittelt werden. Durch die Betrachtung des Problems als Bayesches Inferenznetzwerk
kann die Maximum-Likelihood-Wahrscheinlichkeit von allen Vorhersagen
simultan bestimmt werden.
78

KAPITEL 9. FAZIT UND AUSBLICK
Das generative Modell wird dabei auf einen Baum abgebildet, in dem die Domain den
Wurzelknoten bildet. Die Kinder stellen die Datentypen eines jeden Feldes dar. Deren
Kinder stellen wiederum die Terme dar, mit denen ein Feld codiert wird. Dabei sind sowohl
die Wahrscheinlichkeit für die Domain als auch die bedingten Wahrscheinlichkeiten
der Datentypen in Abhängigkeit von der Domain zu schätzen. Die Parameter können anhand
ihres Vorkommens in den Trainingsdaten bestimmt werden. Die Tabelle mit den
bedingten Wahrscheinlichkeiten für jeden Knoten hängt direkt mit den zu lernenden
Parametern zusammen. Dabei sind die Tabellen mit bedingten Wahrscheinlichkeiten
für alle Datentypen- und Termknoten identisch. Ist ein Bayesches Netzwerk gegeben,
werden die Terme in jedem Feld beobachtet und danach die Maximum Likelihood-
Wahrscheinlichtkeit für Formular-, Domain- und Felddatentypen folgerichtig anhand
dieser Indizien berechnet.
Am Ende dieses Verfahrens von Kushmerick könnte mit den mitgeloggten alten Anfragen
und Ergebnissen von MIND überprüft werden, ob das Ausfüllen des Formulars
korrekt gelernt wurde. Dazu könnte das Formular mit den alten Anfragen ausgefüllt
werden. Auf der Ergebnisseite müßten dann die mitgeloggten Dokumente enthalten
sein.
9.2.2 Verifikation
Um die Probleme durch nicht mehr aktuelle Logdateien zu minimieren, könnten Anfragen
für die einzelnen digitalen Bibliotheken regelmäßig mit Hilfe eines Cron-Jobs gestellt
werden. Bei einem Cron-Job handelt es sich um einen Dämonen. Unter diesem Begriff
werden Programme zusammengefaßt, die automatisch immer wiederkehrende Aufgaben
bearbeiten. Im Fall eines Cron-Jobs werden Kommandos zu einem festgelegten Zeitpunkt
ausgeführt [SH96]. Dazu prüft der Dämon einmal pro Minute, ob zum aktuellen
Zeitpunkt Kommandos auszuführen sind. Mit Hilfe eines Cron-Jobs können auch Tools
gestartet werden. Die Wrapper könnten mit Hilfe der mitgeloggten Anfragen in den
query-Dateien mit einem Cron-Job gestartet werden.
Um die Pflege von Wrappern zu optimieren, könnte das Tool ebenfalls per Cron-Job die
Korrektheit der Logdateien überprüfen. Die mitgeloggten Dokumente würden dann mit
den jeweils letzten Logdateien zu den Anfragen verglichen. Wenn die Anfragen täglich
per Cron-Job gestellt und Anfragen ausgewählt werden, die sich nicht häufig ändern,
müßten immer noch einige Dokumente in der Logdatei enthalten sein. Ist dies nicht der
Fall, so sollte automatisch überprüft werden, ob der Wrapper gebrochen ist.
Ist der Wrapper gebrochen, werden automatisch alle Logdateien entfernt, deren Erstellung
nach der letzten Überprüfung des Wrappers erfolgte. Im Anschluß daran wird das
79

KAPITEL 9. FAZIT UND AUSBLICK
Reinduction-Tool aufgerufen. Dazu könnte das Tool ebenfalls automatisch eine Meldung
zum Ergebnis der Erstellung der neuen Konfigurationsdatei in Form einer E-Mail
verschicken. Der Empfänger muß dann lediglich noch die manuelle Überprüfung durchführen.
Dadurch ist eine deutliche Reduzierung der Reaktions- und Reparaturzeit bei
gebrochenen Wrappern erreichbar.
9.2.3 Übertragbarkeit auf allgemeine Wrapper
Als Voraussetzungen für die Übertragbarkeit des Reinduction-Tools auf allgemeine Wrapper
wurden die Nutzung des Toolkits und ein Logging im MIND-Format herausgestellt
(s. 8.2). Die Daffodil-Wrapper erfüllen die erste Voraussetzung bereits, deswegen sollten
die Wrapper im Hinblick auf eine Verwendung des Reinduction-Tools zügig um ein
Logging im MIND-Format erweitert werden.
9.2.4 Tool zur Erstellung von Logdateien
Um den Einsatz des Reinduction-Tools bei Erzeugung von neuen Wrappern zu erleichtern,
könnte ein weiteres Tool entwickelt werden, das den Benutzer bei der Erstellung
der Logdateien unterstützt. Eine einfache Lösung wäre ein Tool zur Erstellung eines
Grundgerüstes für die Logdateien, die der Benutzer lediglich in einem Editor mit konkreten
Ergebnissen füllen muß.
Eine weitergehende Variante könnte eine graphische Oberfläche sein, die mit der Angabe
einer Webseite und der digitalen Bibliothek gestartet wird. In dieser GUI sollten
die möglichen Schema-Attribute aus dem MIND-Schema der digitalen Bibliothek angezeigt
werden. Des weiteren werden wahlweise nur die sichtbaren Elemente des HTML-
Baums oder der ganze HTML-Baum dargestellt. Der Benutzer könnte dann den einzelnen
Schema-Attributen Werte aus dem HTML-Baum zuweisen. Dabei muß auch eine
Zuordnung der Werte zu Dokumenten möglich sein. Anschließend werden aus den dort
eingegebenen Daten die Logdateien erzeugt.
9.2.5 Verbesserung der regulären Ausdrücke und der Trennung von
Attributen
Das Reinduction-Tool ist nicht in der Lage, mehrere reguläre Ausdrücke ineinander
zu schachteln. Liefern die erstellten automatisch generierten regulären Ausdrücke kein
befriedigendes Ergebnis, so können häufig vorkommende reguläre Ausdrücke getestet
80

KAPITEL 9. FAZIT UND AUSBLICK
werden, die in einer Methode des Reinduction-Tools bzw. einer separaten Datei zusammengefaßt
sind. Beispiele hierfür wären Ausdrücke, die überflüssige Satzzeichen sowie
evtl. auch vorhergehenden bzw. darauffolgenden Text abtrennen.
Eine weitere Möglichkeit wäre es, eine Datei zu erstellen, in der reguläre Ausdrücke
gespeichert werden. Bei jedem Aufruf des Reinduction-Tools könnten die regulären
Ausdrücke aus der Konfigurationsdatei des aktuellen Wrappers oder allen vorhandenen
Konfigurationsdateien daraufhin überprüft werden, ob sie bereits in der Datei mit
den regulären Ausdrücken gespeichert sind. Ist dies nicht der Fall, sind sie in der Datei
abzulegen. Ist nun ein gefundenes Schema-Attribut noch mit regulären Ausdrücken zu
behandeln, können zunächst die Ausdrücke aus der Datei getestet werden. Wird keine
der genannten Methoden durch das Reinduction-Tool als erfolgreich bewertet, so ist der
reguläre Ausdruck manuell zu erstellen.
Zur Optimierung der Trennung von Attributen können die vorgeschlagenen Vorgehensweisen
ebenfalls benutzt werden. Die beste Variante wäre allerdings, gezielt Beispiele zu
untersuchen, bei denen geschachtelte reguläre Ausdrücke notwendig sind und anhand
der so gewonnenen Erkenntnisse das Reinduction-Tool zu erweitern.
9.2.6 Tool zur Nachbearbeitung von fehlerhaften Konfigurationsdateien
Manuelle Änderungen der erzeugten Konfigurationsdatei könnten durch eine GUI unterstützt
werden. Die GUI könnte z. B. die Kandidaten für die XPath-Ausdrücke anzeigen,
die das Tool gefunden hat. Der Benutzer müßte lediglich noch den passenden Kandidaten
auswählen, wobei sofort eine Markierung der entsprechenden Stellen im ebenfalls
angezeigten XHTML-Baum erfolgt.
Bei der Überarbeitung der regulären Ausdrücke ist ebenfalls eine GUI-unterstützte Hilfe
denkbar. Dazu könnte z. B. ein Textfeld zur Verfügung stehen, in dem ein regulärer
Ausdruck direkt erzeugt werden kann. Außerdem könnten auch Funktionen vorhanden
sein, die die Erstellung regulärer Ausdrücke unterstützen.
9.2.7 Suche nach Ergebnissen auf den nachfolgenden Seiten
Bei der Evaluierung konnten keine Probleme durch nicht mehr gefundene Dokumente
festgestellt werden. Deswegen wurde die Suche nach den Ergebnissen auf den nachfolgenden
Seiten nicht implementiert. Falls die mitgeloggten Daten nicht mehr auf der
ersten Seite zu finden sind, ist auf der gegebenen Seite zunächst eine Suche nach Links zu
weiteren Seiten erforderlich. Dazu werden alle Links auf der Webseite gesucht. Von den
81

KAPITEL 9. FAZIT UND AUSBLICK
gefundenen Links kommen diejenigen für die eindeutig zugeordneten Schema-Attribute
nicht mehr in Frage. Die verbliebenen Links müssen daraufhin überprüft werden, ob sie
zu der URL der durchsuchten Webseite eine semantische Ähnlichkeit aufweisen. Häufig
unterscheiden sie sich nur in einer Umgebungsvariablen. Weitere Indizien für URLs sind
Bezeichnungen für die URLs, wie z. B. nächste Seite oder Zahlen.
Die Seiten der verbliebenen URLs werden aufgerufen, und es wird überprüft, ob das
Template mit dem der ersten Übersichtsseite übereinstimmt. Danach kann das
Reinduction-Tool wie gewohnt arbeiten. Diese Erweiterung des Reinduction-Tools stellt
eine Alternative zu der täglichen Anfrage per Cron-Job dar.
82

Literaturverzeichnis
[Bir]
http://www-ai.cs.uni-dortmund.de
/LEHRE/SEMINARE/INFORMATIONSEXTRAKTION/birkmann.pdf.
[Daf] http://www.daffodil.de. Daffodil -.
[DEW97] Doorenbos, Robert B., Oren Etzioni und Daniel S. Weld: A Scalable
Comparison-Shopping Agent for the World-Wide Web. In: Johnson,
W. Lewis und Barbara Hayes-Roth (Herausgeber): Proceedings of the
First International Conference on Autonomous Agents (Agents’97), Seiten
39–48, Marina del Rey, CA, USA, 1997. ACM Press.
[Kno]
[Kus]
[McL]
[Mün]
Knoblock, Craig: Wrapper Validation and Maintenance.
Kushmerick, Nicholas: Learning to invoke Web forms and services.
McLaughin, B.: Java und XML.
Münz, Stefan. http://selfhtml.teamone.de/.
[Mor99] Morik, K.: Maschinelles Lernen. 1999.
[NF03a]
[NF03b]
[Rup02]
[SH96]
Nottelmann, H. und N. Fuhr: Combining DAML+OIL, XSLT and probabilistic
logics for uncertain schema mappings in MIND. 2003.
Nottelmann, H. und N. Fuhr: The MIND Architecture for Heterogeneous
Multimedia Federated Digital Libraries. 2003.
Rupp, Markus: Wrapper für digitale Bibliotheken in Daffodil. Diplomarbeit,
Universität Dortmund, Fachbereich Informatik, 2002.
Sebastian Hetze, Dirk Hohndel, Martin Müller Olaf Kirch: LinuX,
Anwenderhandbuch und Leitfaden für die Systemverwaltung. LunetIX,
1996.
83

LITERATURVERZEICHNIS
[Usc]
Usc, Kristina Lerman: Wrapper Maintenance: A Machine Learning Approach.
84

Abbildungsverzeichnis
2.1 Suchformular einer digitalen Bibliothek . . . . . . . . . . . . . . . . . . . 5
2.2 Übersichtsseite einer digitalen Bibliothek . . . . . . . . . . . . . . . . . . 7
2.3 Detailseite einer digitalen Bibliothek . . . . . . . . . . . . . . . . . . . . 8
2.4 MIND-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Lernmodul des ShopBot . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Lebenszyklus eines Wrappers . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Auszug aus der syntaktischen Hierarchie der Tokentypen . . . . . . . . . 23
3.4 Musterbaum, der die Struktur von Adressen beschreibt . . . . . . . . . . 24
4.1 Auszüge aus Detailseiten
der National Gallery of Art von Washington D. C. . . . . . . . . . . . . 31
4.2 Arbeitsweise des Wrappertoolkits . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Beispiel einer Konfigurationsdatei . . . . . . . . . . . . . . . . . . . . . . 36
5.1 Digitale Bibliothek mit zweispaltigem Aufbau . . . . . . . . . . . . . . . 43
6.1 Vorgehensweise des Wrappertools . . . . . . . . . . . . . . . . . . . . . . 47
6.2 Beispiel für die Ähnlichkeit von Dokumenten . . . . . . . . . . . . . . . 50
6.3 Intervallverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.4 Vorgehensweise des Wrappertools . . . . . . . . . . . . . . . . . . . . . . 62
85