Wandler in digitalen Bibliotheken: Vollautomatische Generierung

Wandler in digitalen Bibliotheken:
Vollautomatische Generierung
Diplomarbeit
von
Guido Sautter
Verantwortlicher Gutachter: Prof. Dr. Peter Lockemann
Betreuer: Dipl.-Inform. Michael Christoffel
Tag der Ausgabe: 01. Mai 2004
Tag der Abgabe: 16. Oktober 2004

Kurzfassung
Aufgrund der Heterogenität vieler digitaler Bibliotheken spielen in der heutigen Zeit
integrierende Meta-Suchsysteme eine große Rolle, da sie den Benutzer befähigen, seine
Anfrage gleichzeitig an mehrere Informationsquellen zu richten und sich so schnell einen
Überblick zu verschaffen. Damit sich ein solches Suchsystem am Markt durchsetzen kann,
müssen zum einen bestehende Informationsquellen auf einfache Art und Weise unter
Wahrung ihrer Unabhängigkeit in werden können. Zum anderen muß aber auch die
Einbindung der Quellen, die jederzeit Änderungen erfahren können, so gekapselt werden, daß
diese Änderungen die Arbeitsweise des Suchsystems nicht beeinträchtigen.
Diese Diplomarbeit befaßt sich mit dieser Problematik hinsichtlich eines bestehenden
Recherchesystems im Bereich der Literaturrecherche und -beschaffung, dem UniCats-i-
System, in dem ein Wandler die Heterogenität der digitalen Bibliotheken kapselt. Ziel der
Arbeit sind der Entwurf und die Realisierung zum einen eines vollautomatischen Generators,
der das System bei Veränderungen an den Informationsquellen von administrativen Eingriffen
unabhängig macht, zum anderen eines Wandler-Generators, der eine Generierung von
Wandlern durch einen Benutzer ermöglicht, wobei dieser in einem möglichst hohen Grad von
automatischen Verfahren unterstützt wird und im Idealfall nur eine Kontrollfunktion ausübt.
Der Wandler soll fehlertolerant gegenüber der Informationsquelle sein und durch den Einsatz
regulärer Ausdrücke die gewünschten Daten punktgenau extrahieren können.
Dies konnte durch die Umsetzung und Automatisierung des Ansatzes Generation by Example
erreicht werden, bei dem der Benutzer lediglich eine ihm vertraute Beispielrecherche auf der
Informationsquelle durchführt bzw. eine solche von der Automatik auf Basis von
Beispieldaten durchführen läßt. Der Wandler-Generator erzeugt aus den dabei gewonnenen
Informationen den vollständige Wandler. Zusätzlich wurde eine Wandler-Komponente
realisiert, die die erzeugten Wandler zur Extraktion von Informationen aus der jeweils
beschriebenen Informationsquelle nutzt und perfekt auf den Wandler-Generator abgestimmt
ist. Für die punktgenaue Extraktion der gewünschten Daten wurde eine reguläre Sprache
entwickelt, deren Ausdrücke in die pfadbasierten Extraktionsinformationen des Wandlers
integriert sind. Der Generator für diese Ausdrücke ist in die Automatismen des Wandler-
Generators eingeschlossen. Die Wandler-Komponente enthält einen Interpreter, der die
Ausdrücke zur Extraktion einzelner Daten aus Zeichenketten einsetzt.

Erklärung
Hiermit erkläre ich, daß ich die vorliegende Diplomarbeit ohne unzulässige Hilfe erstellt und
alle verwendeten Literaturquellen angegeben habe.
Karlsruhe, den 16. Oktober 2004

Inhaltsverzeichnis
fuck
1. Einleitung ....................................................................................................... 1
1.1 Motivation ..................................................................................................................1
1.2 Aufgabenstellung ....................................................................................................... 2
1.3 Gliederung der Arbeit................................................................................................. 2
2. Grundlagen ..................................................................................................... 5
2.1 Agenten ...................................................................................................................... 5
2.2 Webservices ............................................................................................................... 6
2.2.1 SOAP.................................................................................................................. 6
2.2.2 WSDL................................................................................................................. 7
2.2.3 WSCL................................................................................................................. 8
2.2.4 UDDI.................................................................................................................. 9
2.3 SGML......................................................................................................................... 9
2.4 HTML......................................................................................................................... 9
2.5 XML......................................................................................................................... 10
2.6 DOM......................................................................................................................... 10
2.7 Baumdarstellung eines HTML-Dokumentes ........................................................... 10
2.8 Vergleich von HTML-Dokumenten......................................................................... 12
2.9 Hierarchische Pfadausdrücke ................................................................................... 15
2.9.1 Bisherige Definition ......................................................................................... 16
2.9.2 Reguläre Ausdrücke zur Extraktion von Teilstrings ........................................ 17
2.9.3 Erweiterung der Hierarchischen Pfadausdrücke .............................................. 19
2.10 Wandler ....................................................................................................................20
3. Das UniCats-i-Projekt .................................................................................. 23
3.1 Der Aufbau des UniCats-i-Systems ......................................................................... 23
3.1.1 Die Agentenarchitektur .................................................................................... 23
3.1.2 Der Aufbau einer Gemeinschaft....................................................................... 25
3.2 Der Anbieteragent (AA) im Speziellen.................................................................... 28
3.3 Die Rolle des Generatoragenten (GA) ..................................................................... 30
4. Verwandte Projekte und Arbeiten ................................................................ 31
4.1 W4F.......................................................................................................................... 31
4.1.1 Projektvorstellung ............................................................................................ 31
4.1.2 Generierungshilfsmittel.................................................................................... 31
4.1.3 Beurteilung....................................................................................................... 34
4.2 XWRAP ................................................................................................................... 34
4.2.1 Projektvorstellung ............................................................................................ 34
4.2.2 Generierungshilfsmittel.................................................................................... 35
4.2.3 Beurteilung....................................................................................................... 36
4.3 Lixto ......................................................................................................................... 37
4.3.1 Projektvorstellung ............................................................................................ 37
4.3.2 Generierungshilfsmittel.................................................................................... 38
4.3.3 Beurteilung....................................................................................................... 39
4.4 ROADRUNNER ...................................................................................................... 39
4.4.1 Projektvorstellung ............................................................................................ 39
4.4.2 Bewertung ........................................................................................................ 41
4.5 Wandler in digitalen Bibliotheken: Semi-Automatische Generierung und
Evaluationsstrategien ............................................................................................... 41
4.5.1 Projektvorstellung ............................................................................................ 41
i

4.5.2 Generierungshilfsmittel.................................................................................... 42
4.5.3 Beurteilung....................................................................................................... 43
4.6 Fazit.......................................................................................................................... 43
5. Entwurf ......................................................................................................... 45
5.1 Automatisierungspotential der Generierungsverfahren ........................................... 45
5.1.1 Generation by Example.................................................................................... 45
5.1.2 ACME .............................................................................................................. 45
5.1.3 Fazit.................................................................................................................. 46
5.2 Genereller Ablauf des Generierungsprozesses......................................................... 46
5.3 Finden und Auswahl eines Suchformulars............................................................... 47
5.3.1 Formulare in HTML-Dokumenten................................................................... 47
5.3.2 Finden von Suchformularen............................................................................. 48
5.3.3 Auswahl eines Suchformulares ........................................................................ 49
5.4 Analyse des Suchformulars...................................................................................... 50
5.4.1 Genereller Ablauf............................................................................................. 51
5.4.2 Klassifizierung der Suchfelder (Textfelder)..................................................... 51
5.4.3 Klassifizierung der Auswahlfelder................................................................... 53
5.4.4 Behandlung der restlichen Eingabefelder ........................................................ 56
5.4.5 Durchführen einer Suche über das Formular ................................................... 57
5.5 Generierung der Pfade für Suchen mit einem Treffer.............................................. 58
5.5.1 Genereller Ablauf............................................................................................. 58
5.5.2 Generierung der Suchanfrage........................................................................... 58
5.5.3 Generierung der Pfade...................................................................................... 59
5.6 Generierung der Pfade für Suchen mit mehreren Treffern....................................... 60
5.6.1 Genereller Ablauf............................................................................................. 61
5.6.2 Generierung der Suchanfrage........................................................................... 61
5.6.3 Generierung der Pfade...................................................................................... 62
5.7 Generierung regulärer Ausdrücke ............................................................................ 65
5.7.1 Genereller Ablauf............................................................................................. 65
5.7.2 Finden und Optimierung der Grenzstrings....................................................... 65
5.7.3 Erzeugung und Optimierung der Ausdrücke.................................................... 67
5.8 Resultierende Anforderungen an Generierungs-Basisdaten .................................... 69
5.8.1 Heuristik-Daten zu Formular-Analyse ............................................................. 69
5.8.2 Heuristik-Daten zur Generierung regulärer Ausdrücke ................................... 69
5.8.3 Beispiel-Daten für die Pfad-Generierung......................................................... 70
5.9 Zusammenarbeit der Generator-Agenten ................................................................. 70
5.9.1 Möglichkeiten zur Zusammenarbeit................................................................. 70
5.9.2 Übergabe / Übernahme einer Anfrage ............................................................. 71
5.10 Anforderungen an den GeneratorAgenten ............................................................... 72
6. Implementierung........................................................................................... 73
6.1 Allgemeine Überlegungen........................................................................................ 73
6.2 Das Paket generatorAgent........................................................................................ 74
6.2.1 Die Klasse GeneratorAgent.............................................................................. 74
6.2.2 Die Klasse RequestHandler.............................................................................. 74
6.2.3 Die Klasse ContextGenerator........................................................................... 74
6.2.4 Die Klasse IoTool............................................................................................. 74
6.2.5 Die Klasse PAContextRequest......................................................................... 74
6.2.6 Die Klasse GAContextRequest ........................................................................ 74
6.2.7 Die Klasse GaWebServiceInterface ................................................................. 75
ii

6.3 Das Paket generatorAgent.extractionTools.............................................................. 75
6.3.1 Die Klasse DataExtractor ................................................................................. 75
6.3.2 Die Klasse DataExtractionThread.................................................................... 75
6.3.3 Die Klasse LayerDataExtractor........................................................................ 75
6.3.4 Die Klasse LayerDataExtractionThread........................................................... 75
6.3.5 Die Klasse QueryPlan ...................................................................................... 75
6.3.6 Die Klasse ProviderQueryResult ..................................................................... 76
6.3.7 Die Klasse SearchField .................................................................................... 76
6.3.8 Die Klasse SearchQueryGenerator................................................................... 76
6.4 Das Paket generatorAgent.tree................................................................................. 76
6.4.1 Die Klasse AbstractParser................................................................................ 76
6.4.2 Die Klasse FastParser....................................................................................... 76
6.4.3 Die Klasse Parser ............................................................................................. 76
6.4.4 Die Klasse SecureParser................................................................................... 76
6.4.5 Die Klasse StringStack..................................................................................... 77
6.4.6 Die Schnittstelle LanguageDescription............................................................ 77
6.4.7 Die Klasse Html ............................................................................................... 77
6.4.8 Die Klasse SourceFile ...................................................................................... 77
6.4.9 Die Klasse ParseTreeNode............................................................................... 77
6.4.10 Die Klasse ParseTreeCrawler........................................................................... 77
6.4.11 Die Klasse HtmlParser ..................................................................................... 78
6.4.12 Die Klasse SourceFileParser ............................................................................ 78
6.5 Das Paket generatorAgent.util.................................................................................. 78
6.5.1 Die Klasse GenerateDataContainer.................................................................. 78
6.5.2 Die Klasse SearchFormContainer .................................................................... 78
6.5.3 Die Klasse SearchFieldContainer..................................................................... 78
6.5.4 Die Klasse OptionFieldContainer .................................................................... 78
6.5.5 Die Klasse QueryPartContainer ....................................................................... 79
6.5.6 Die Klasse LayerContainer .............................................................................. 79
6.5.7 Die Klasse LayerCascadeContainer ................................................................. 79
6.5.8 Die Klasse RegExGenerateContainer .............................................................. 79
6.5.9 Die Klasse ResultPart....................................................................................... 79
6.5.10 Die Klasse ProtocolVector............................................................................... 79
6.6 Das Paket generatorAgent.ws .................................................................................. 79
7. Werkzeuge.................................................................................................... 81
7.1 Das Generator-Werkzeug......................................................................................... 81
7.1.1 Das Paket generatorAgent.applet ..................................................................... 81
7.1.2 Das Werkzeug .................................................................................................. 88
7.2 Das Basisdaten-Werkzeug...................................................................................... 104
7.2.1 Das Paket generatorAgent.dataEditor ............................................................ 104
7.2.2 Das Werkzeug ................................................................................................ 105
8. Evaluierung................................................................................................. 111
9. Zusammenfassung und Ausblick................................................................ 113
9.1 Zusammenfassung.................................................................................................. 113
9.2 Ausblick ................................................................................................................. 114
Anhang .............................................................................................................. 115
A Definition der Quellenbeschreibung .............................................................................. 115
B Definition der Basisdaten für die Generierung............................................................... 120
iii

Abbildungsverzeichnis
Abbildung 2.1: Seite im Browser............................................................................................. 10
Abbildung 2.2: Quelltext der Seite (gekürzt)........................................................................... 11
Abbildung 2.3: HTML-Baum der Seite (gekürzt, BR-Tags ausgelassen)................................ 12
Abbildung 2.4: Vergleich von HTML-Dokumenten................................................................ 13
Abbildung 2.5: Editierdistanz zweier Bäume in String-Repräsentation .................................. 14
Abbildung 2.6: Vergleich von HTML-Bäumen rekursiv über ihre Ebenen ............................ 15
Abbildung 3.1: Architektur der UniCats-i-Umgebung ............................................................ 24
Abbildung 3.2: Aufbau der UniCats-i-Gemeinschaft .............................................................. 25
Abbildung 3.3: Struktur des Kommunikationsmoduls............................................................. 26
Abbildung 3.4: Struktur eines Agenten.................................................................................... 28
Abbildung 3.5: Struktur einer Quellenbeschreibung................................................................ 29
Abbildung 4.1: Schichten-Architektur der W4F ...................................................................... 32
Abbildung 4.2: W4F Formular Wizzard .................................................................................. 32
Abbildung 4.3: W4F Extraction Wizzard ................................................................................ 33
Abbildung 4.4: Fertig gestellter W4F Wandler........................................................................ 33
Abbildung 4.5: Start-Ansicht des XWRAP-Werkzeuges ........................................................ 35
Abbildung 4.6: Überblick über extrahierte Elemente .............................................................. 36
Abbildung 4.7: Detail der Ansicht zur Benennung extrahierter Elemente .............................. 36
Abbildung 4.8: Zusammenspiel der Lixto-Komponenten........................................................ 37
Abbildung 4.9: Beispielseite im Lixto-Browser ...................................................................... 38
Abbildung 4.10: Hauptmenu des Interactive Pattern Builder ................................................. 38
Abbildung 4.11: Elog-Code eines Lixto-Wandlers.................................................................. 38
Abbildung 4.12: Vergleich zweier HTML-Dokumente einer Klasse ...................................... 39
Abbildung 4.13: Architektur des ROADRUNNER-Systems.......................................................... 40
Abbildung 4.14: Ablauf der Generierung ................................................................................ 42
Abbildung 4.15: Generierungs-Werkzeug ............................................................................... 42
Abbildung 5.1: Prozess der Wandler-Generierung .................................................................. 47
Abbildung 5.2: Generierung der Pfade zu Datenelementen..................................................... 59
Abbildung 5.3: Struktur einer Ergebnis-Liste.......................................................................... 62
Abbildung 5.4: Listen-Basispfad.............................................................................................. 64
Abbildung 5.5: Übergabe / Übernahme einer Anfrage – Ablauf ............................................. 71
Abbildung 6.1: Grob-Architektur des GA................................................................................ 73
Abbildung 7.1: Ansicht zur Suche der Startseite ..................................................................... 89
Abbildung 7.2: Auswahl des Modus für die Suche eines Formulares ..................................... 89
Abbildung 7.3: Dialog zum Laden der Basisdaten-Datei ........................................................ 90
Abbildung 7.4: Ansicht zur Auswahl eines Suchformulares ................................................... 91
Abbildung 7.5: Auswahl des Modus für die Analyse des Suchformulares.............................. 91
Abbildung 7.6: Fenster zur Veränderung der Vorbelegung des Suchformulares .................... 92
Abbildung 7.7: Ansicht zur Klassifizierung der Suchfelder in Standardeinstellung ............... 92
Abbildung 7.8: Ansicht zur Klassifizierung der Auswahlfelder und ihrer Optionen............... 93
Abbildung 7.9: Auswahl des Modus für die Generierung der Pfade für Suchen mit einem
Treffer............................................................................................................................... 94
Abbildung 7.10: Ansicht zu Eingabe oder Auswahl der Suchkriterien ................................... 94
Abbildung 7.11: Ansicht zur Generierung von Informationsschichten und Pfaden ................ 95
Abbildung 7.12: Ansicht zur Ergänzung der Pfade um Reguläre Ausdrücke.......................... 96
Abbildung 7.13: Auswahl des Modus für die Generierung der Pfade für Suchen mit mehreren
Treffern............................................................................................................................. 97
Abbildung 7.14: Fenster zur manuellen Änderung der Pfade.................................................. 97
Abbildung 7.15: Anzeige des durch einen Pfad extrahierten Textstückes............................... 98
v

Abbildung 7.16: Fenster zur Anzeige einer Informationsschicht ............................................ 98
Abbildung 7.17: Ansicht zu Eingabe oder Auswahl der Suchkriterien ................................... 98
Abbildung 7.18: Ansicht zur Generierung von Informationsschichten und Pfaden .............. 100
Abbildung 7.19: Ansicht zur Ergänzung der Pfade um Reguläre Ausdrücke........................ 100
Abbildung 7.20: Anzeige des durch eine Regulären Ausdruck aus einem Gesamtstring
extrahierten Teilstrings................................................................................................... 101
Abbildung 7.21: Ansicht am Ende des Generierungsablaufes............................................... 101
Abbildung 7.22: Fenster zur manuellen Änderung der Pfade................................................ 102
Abbildung 7.23: Fenster zur manuellen Änderung der Quellenbeschreibung ....................... 102
Abbildung 7.24: Dialog zum Speichern einer generierten Quellenbeschreibung.................. 103
Abbildung 7.25: Fenster zum Testeinsatz der erzeugten Quellenbeschreibung .................... 103
Abbildung 7.26: Ansicht zur Eingabe und Änderung eines Generierungs-Beispieles für
Suchen mit einem Treffer............................................................................................... 105
Abbildung 7.27: PopUp zur Änderung bestehender Werte.................................................... 105
Abbildung 7.28: Ansicht zur Eingabe und Änderung eines Generierungs-Beispieles für
Suchen mit mehreren Treffern ....................................................................................... 106
Abbildung 7.29: Ansicht zur Eingabe der für dieses Generierungs-Beispiel zu verwendenden
Suchfelder....................................................................................................................... 107
Abbildung 7.30: Ansicht zur Änderung bestimmter Basiswerte............................................ 107
Abbildung 7.31: Ansicht zur Eingabe der für die Kein-Ergebnis-Suche zu verwendenden
Suchfelder....................................................................................................................... 108
Abbildung 7.32: Ansicht zur Eingabe von Heuristikwerten zur Erkennung der Bedeutung
einzelner Optionen in Auswahlfeldern........................................................................... 108
Abbildung 7.33: Ansicht zur Eingabe von Zeichen und Bindewörtern, die mit hoher
Wahrscheinlichkeit innerhalb der Werte von Datenelementen auftreten....................... 109
vi

Tabellenverzeichnis
Tabelle 3.1: Auflistung aller möglichen Agentenzustände ...................................................... 27
Tabelle 5.1: Formular-Elemente in HTML .............................................................................. 48
vii

viii

1. Einleitung
1.1 Motivation
Die globale Vernetzung mit einem ständig wachsenden Angebot an Informationsanbietern
beinhaltet für den informationssuchenden Menschen eine Fülle von Möglichkeiten. Längst
sind ihm Schlagworte wie digitale Bibliotheken oder Online-Buchvertriebe geläufig, und er
besitzt das nötige Wissen, diese Möglichkeiten der Informationssuche einzusetzen, ohne dabei
von Öffnungszeiten von Gebäuden oder Institutionen abhängig zu sein.
Mit dem steigenden Angebot der vorhandenen Informationen und Dienste manifestieren sich
jedoch auch einige Probleme für den Benutzer:
• Aus der Menge aller Informationsanbieter muß der Benutzer die für ihn potentiell
interessanten Quellen erst herausfiltern. Dies bedeutet für ihn nicht nur einen hohen
zeitlichen Aufwand, sondern stellt für ungeübte Benutzer eine oft nur schwer
überwindbare Hürde dar.
• Handelt es sich um kostenpflichtige Informationen, möchte der Benutzer in der Regel
einen Kostenvergleich aufstellen. Dies ist jedoch im allgemeinen nur sequentiell durch
Besuch aller potentiellen Informationsquellen möglich, also mit einem zeitlich hohen
Aufwand verbunden. Ist bereits die Informationssuche an sich kostenpflichtig, ist es
dem Benutzer kaum möglich, die entstehenden Kosten im voraus abzuschätzen.
• Neue Informationsanbieter haben das Problem, sich dem Benutzer geeignet
anzubieten, da bereits existierende Anbieter durch ihren Bekanntheitsgrad mehr
Benutzer anziehen. Existieren bessere und im Falle kostenpflichtiger Quellen
günstigere Anbieter, ist es zum Vorteil von Benutzer und Anbieter, wenn ersterer über
das Vorhandensein des zweiten in Kenntnis gesetzt wird.
• Unterschiedliche Darstellung und Bedienung der Informationsquellen zwingen den
Benutzer, den Umgang mit jeder Informationsquelle zunächst zu erlernen. Zudem
erfordern Änderungen hinsichtlich der Darstellung und Bedienung, die in den Quellen
von Zeit zu Zeit auftreten können, ein erneutes Umlernen.
• Bei der gleichen Informationssuche in verschiedenen Quellen müssen die
Suchparameter jedesmal erneut vom Benutzer angegeben werden. Zudem existieren
beim Benutzer meist immer gleichbleibende Suchkriterien, welche die Recherche stets
einschränken, wie zum Beispiel die verwendete Sprache oder Zahlungsarten. Diese
Informationen will der Benutzer nur einmal festlegen müssen und sicher sein, da die
dadurch gegebenen Einschränkungen bei jeder Informationssuche beachtet werden.
Einige Dienstanbieter begegnen diesen Problemen durch den Versuch, Recherchesysteme
oder Meta-Suchdienste zu etablieren. Diese Recherchesysteme erlauben es dem Benutzer im
allgemeinen, zeitgleich und über ein und dieselbe Benutzerschnittstelle – oft sogar mit einer
einzigen Suchanfrage – in verschiedenen Informationsquellen zu recherchieren und somit auf
einfache Art und Weise die Angebote verschiedener Anbieter zu vergleichen. Auf der anderen
Seite können sich die Informationsanbieter in ein solches System einbinden und auf direktem
Weg den Benutzer erreichen.
Ein bereits existierendes Recherchesystem ist das UniCats-i-System der Universität
Karlsruhe. In diesem System erfolgt die Anbindung der einzelnen Anbieter und Quellen von
Informationen über Wandler, die auf die Internetseiten der Anbieter zugreifen. Die
semiautomatische Generierung dieser Wandler, die in vorangegangenen Arbeiten [Schneider
2001] realisiert wurde, stellt einen großen Fortschritt gegenüber der sehr fehlerträchtigen und
zeitaufwendigen manuellen Generierung dar. Allerdings steht das System auch bei Einsatz
dieses Verfahrens noch vor einer Reihe von Problemen:
1

• Eine kleine Änderung auf Anbieterseite kann im schlimmsten Fall zu einem
kompletten Ausfall der Anbindung an diesen Anbieter führen, den zu beheben das
System nicht selbst in der Lage ist. In jedem Fall wird ein administrativer Eingriff zur
Anpassung des betroffenen Wandlers notwendig, um dessen korrekte Funktion sicher-
oder wiederherzustellen. Dies ist durch die bestehenden Werkzeuge zwar ohne
besonders großen Aufwand zu erledigen, aber bis die Notwendigkeit des Eingriffs von
einem Administrator bemerkt wird, ist die Anbindung an den betroffenen Anbieter
fehlerhaft oder ausgefallen.
• Gerade in einem späteren, groß dimensionierten praktischen Einsatz-Szenario des
UniCats-i-Systems mit Hunderten oder gar Tausenden von Anbietern kann dies eine
längere Zeit in Anspruch nehmen. Dies zu vermeiden, zieht durch die Notwendigkeit
der regelmäßigen Funktionskontrolle aller Anbieter-Anbindungen einen erheblichem
Administrationsaufwand nach sich.
• Der Ausfall der Anbindung eines Anbieters führt zum einen zu dessen
Benachteiligung gegenüber seinen Konkurrenten, zum anderen zu einer
unvollständigen Information des Kunden.
Eine Generierung und Anpassung der Wandler durch einen in das System integrierten
vollautomatischen Generator kann die oben genannten Probleme beheben. Zudem kann die
Anbindung neuer Anbieter und Quellen im Idealfall allein durch Angabe der Einstiegsseite in
Form einer URL erfolgen, da die Generierung eines passenden Wandlers durch den
vollautomatischen Generator selbständig erfolgt.
1.2 Aufgabenstellung
Im Rahmen der vorliegenden Arbeit soll ein vollautomatischer Wandler-Generator entworfen,
implementiert und getestet werden. Dieser soll sowohl als eigenständiger Teil des UniCats-i-
Systems in Form eines Agenten als auch im Rahmen eines vom System unabhängigen
Werkzeuges einsetzbar sein. Die generierten Quellenbeschreibungen sollen den Wandler-
Agenten des UniCats-i-Systems befähigen, ohne sonstige Anpassungen durch das Stellen von
Suchanfragen und das anschließende Auslesen der Suchergebnisse auf die beschriebene
Informationsquelle zuzugreifen und sie somit in das UniCats-i-System zu integrieren und für
seine Benutzer verfügbar zu machen.
Die bisherigen Möglichkeiten des Wandlers und des im Rahmen von [Schneider 2001]
realisierten Generators sollen um folgende Fähigkeiten ergänzt werden:
• Neben der Suchen über HTML-Formulare mit der Standard-Methode GET soll auch
die Suche über Formulare mit der Methode POST ermöglicht werden. Dies wird
aufgrund der immer komplexer werdenden Suchformulare notwendig, die zur
Übertragung ihrer Vielzahl von Variablen in zunehmendem Maße die Methode POST
zur Anwendung bringen.
• Sind mehrere Informationen nur innerhalb eines Strings als Gesamtheit verfügbar, so
ist es dem bestehenden Wandler nicht möglich, auf diese einzeln zuzugreifen. Der zu
schaffende Generator soll in der Lage sein, reguläre Ausdrücke zu generieren, deren
Anwendung auf einen solchen Gesamtstring jeweils eine einzelne Information
heraustrennt und sie somit einzeln verfügbar macht.
1.3 Gliederung der Arbeit
In Kapitel 2 werden zunächst einige Grundlagen dargestellt, die das Umfeld dieser Arbeit
wesentlich beeinflussen.
Kapitel 3 stellt des UniCats-i-System vor, in dessen Rahmen die in dieser Arbeit entworfenen
und implementierten Software-Komponenten eingesetzt werden sollen. Dabei werden
2

insbesondere die Rolle des Generator-Agenten im Zusammenspiel der UniCats-i-Agenten und
die sich daraus ergebenden Anforderungen an diesen Agenten beleuchtet.
Da neben dem UniCats-i-System auch andere Recherchesysteme existieren, die Anbieter von
Informationen mithilfe von Wandlern integrieren, werden in Kapitel 4 solche Projekte speziell
daraufhin untersucht, welche Ansätze sie zur Generierung dieser Wandler verfolgen und
welche Werkzeuge dabei zum Einsatz kommen. Ebenso wird der bereits existierende
Wandler-Generator des UniCats-i-Systems untersucht.
In Kapitel 5 wird auf Basis der Anforderungen der Aufgabenstellung sowie der in den
Kapiteln 3 und 4 gezogenen Schlüsse ein vollautomatischer Wandler-Generator konzipiert.
Das Konzept wird anschließend zu einem konkreten Entwurf weiterentwickelt.
Kapitel 6 beschäftigt sich mit der Implementierung des in Kapitel 5 erstellten Entwurfes.
Dabei wird sowohl auf die Umsetzung der Algorithmen eingegangen als auch auf die zu ihrer
Realisierung notwendigen implementierten Zusatzpakete, abstrakten Datentypen und
Hilfsstrukturen.
Die dem Benutzer zur Verfügung gestellten Werkzeuge zur interaktiven Anwendung der
Ergebnisse dieser Arbeit werden in Kapitel 7 beschrieben. Dabei wird insbesondere auf ihre
Funktionsweise und Bedienung eingegangen.
Kapitel 8 beschäftigt sich mit der Evaluierung der im Rahmen der Arbeit erstellten
Komponenten und Werkzeuge.
Die Zusammenfassung und der Ausblick des Kapitels 9 bilden den Schlußpunkt der Arbeit.
3

2. Grundlagen
In diesem Kapitel werden einige Grundlagen behandelt, die das Umfeld dieser Arbeit
bestimmen und daher näher erläutert werden sollen.
Das UniCats-i-System setzt sich aus Agenten zusammen, deren Kommunikation auf der Basis
von Webservices abläuft. Daher spielen beide Technologien für diese Arbeite eine
gleichermaßen entscheidende Rolle und sollen hier erklärt werden.
Die Markierungssprache HyperText Markup Language (HTML) stellt den gängigen Standard
für die Formatierung im Internet angebotener Informationen dar. Damit ist sie die Sprache, in
der die Eingabe der Wandler formatiert ist und auf der Wandler und damit auch der zu
schaffende Wandler-Generator arbeiten müssen. Sie ist daher von großer Bedeutung für diese
Arbeit. Die Struktur einer Markierungssprache läßt sich wiederum durch eine
Definitionssprache wie die Standard Generalized Markup Language (SGML) oder die
eXtensible Markup Language (XML), einer Untermenge von SGML, beschreiben. HTML-
Dokumente wie auch durch XML definierte Dokumenttypen können durch das Document
Object Model (DOM) beschrieben werden.
Aufgrund der Möglichkeit, HTLM- und XML-Dokumente mithilfe des DOM zu beschreiben,
lassen sie sich durch einen geeigneten Parser in eine zum Dokument äquivalente
Baumdarstellung überführen. Diese ist für die Arbeit besonders wichtig, da für Bäume
effiziente Algorithmen und Pfad-basierte Anfragesprachen über hierarchische Pfadausdrücke
existieren und sie somit eine gute Arbeitsgrundlage für Wandler darstellen. Ebenso wird auf
Möglichkeiten zum Vergleichen von HTML-Dokumenten eingegangen.
Die Kenntnis von Wandlern schließlich ist für deren Generierung logischerweise
unabdingbar. Daher soll hier kurz erläutert werden, was genau unter Wandlern zu verstehen
ist und welche Aufgaben sie erfüllen. Auf unterschiedliche Ansätze und Funktionsprinzipien
von Wandlern wird in einem späteren Kapitel dieser Arbeit eingegangen.
2.1 Agenten
Ein Agent ist ein Stück Software, welches selbständig auf gewisse Ereignisse und Einflüsse
von außen reagieren kann. Ein Agent agiert autonom. Dies stellt insofern einen Vorteil
gegenüber einem herkömmlichen System dar, als daß ein Agent eventuell auf nicht
vorhersehbare Ereignisse reagieren kann, wohingegen solche in einem herkömmlichen
System im schlimmsten Fall einen Absturz verursachen können.
Eine eindeutige Definition eines Agenten ist schwer zu finden. Eine sehr neutrale Definition
von Wooldridge und Jennings [Wooldridge 2000] lautet folgendermaßen:
„An Agent is a computer system that is situated in some environment, and that
is capable of autonomous action in this environment in order to meet its design
objectives.“
Wooldridge [Wooldridge 2002] beschreibt zusätzlich intelligente Agenten, die ein flexibles
Verhalten aufweisen.
Diese Flexibilität zeichnet sich durch folgende Eigenschaften aus:
• Reaktivität: Die Fähigkeit, auf wahrgenommene Veränderungen der Umgebung -
unter Berücksichtigung der verfolgten Ziele - zeitlich angemessen reagieren zu
können.
• Proaktivität: Die Fähigkeit, Handlungen aus eigenem Antrieb zu initiieren, um Ziele
zu erreichen.
• Soziale Kompetenz: Die Fähigkeiten, die zur Interaktion mit anderen Agenten
notwendig bzw. förderlich sind und auf diesem Weg letztlich das Erreichen von Zielen
begünstigen mögen, etwa durch Kommunikation, Koordination und Kooperation.
5

„Es ist anzumerken, daß insbesondere die Balance zwischen Reaktivität und
Proaktivität ein schwieriges Unterfangen ist, welches selbst Menschen Probleme
bereitet. Auf der einen Seite sollen bestimmte Ziele erreicht werden, auf der
anderen Seite muß man auf eine ständig wechselnden Umgebung reagieren und
dabei die eigenen Ziele ständig anpassen. Eine der Eigenschaften alleine zu
erreichen, ist dagegen recht einfach; erst die Kombination macht die
Schwierigkeit aus.“ [Dinkloh 2003].
2.2 Webservices
”Ein Webservice ist eine über das Netzwerk zugängliche Schnittstelle zu
Anwendungsfunktionen, die mit Hilfe von Standardtechniken des Internets
realisiert wird.“[Snell 2002]
Ein Webservice ist somit – praktisch gesprochen – eine Methode oder eine Prozedur, die man
auf einem beliebigen Rechner in einem Netzwerk ausführen kann. Sie kann auf einem
Rechner in einer beliebigen Programmiersprache implementiert sein. Da die Schnittstellen
sich an einen Standard halten, ist Interoperabilität zwischen verschiedenen Betriebssystemen
möglich.
”Webservices sind ein nachrichtenorientiertes System. Die einzige
Einschränkung, der Webservices unterliegen, besteht darin, daß sie Nachrichten
mit Hilfe einer Kombination von Standard-Internetprotokollen senden und
empfangen können müssen.“[Snell 2002]
Nach außen gesehen verhält sich ein Webservice wie eine Blackbox. Es wird eine Nachricht
hineingeschickt, diese wird intern bearbeitet und es wird eine Antwort zurückgegeben. UDDI,
WSDL und SOAP stellen die zentralen Elemente für den Bau von allgemein einsetzbaren
Schnittstellen für Webservices dar. Diese benötigen eine zentrale Registrierung. Dazu
gründeten Ariba, IBM und Microsoft die UDDI-Initiative, der mittlerweile über 220 weitere
Unternehmen beigetreten sind. Um einen Webservice nutzbar machen zu können, muß eine
Beschreibung von ihm existieren, die darstellt, wie er über das Internet kommunizieren kann.
Die Beschreibung definiert zum einen den inhaltlichen Aufbau der Nachrichten, die sie
austauschen. Hier nahm das WWW-Konsortium [W3C] den Vorschlag Web Service
Description Language (WSDL) an, den unter anderem HP, IBM, Intel, Microsoft, Oracle und
SAP einreichten. Zum anderen müssen sich die Webservices auf ein einheitliches Transport-
Protokoll einigen. Dieses definiert, wie Webservices ihre Nachrichten über das Internet
verschicken. Hier kommt SOAP ins Spiel, das festlegt, wie die Services über HTTP XML-
Nachrichten austauschen.
2.2.1 SOAP
Das Simple Object Access Protokoll (SOAP) hat sich als ein Standard bei der Übertragung
von Nachrichten zwischen Anwendungen – speziell auch für Webservices – etabliert. Es stellt
lediglich eine feste „Verpackungseinheit“ für einzelne Objektdaten dar, welche durch ein
Netzwerk, respektive das Internet gesendet werden. Durch diese einheitliche „Verpackung“
ist es letztendlich irrelevant, in welcher Programmiersprache ein Webservice implementiert
ist, entscheidend ist lediglich, daß sich die Implementierung an den SOAP Standard hält.
„SOAP ist XML. Das heißt, SOAP ist eine Anwendung der XML-Spezifikation.
SOAP stützt sich in Definition und Arbeitsweise stark auf XML-Standards wie
XML-Schema und XML-Namespaces.“[Snell 2002]
Eine SOAP-Nachricht besteht immer aus einem Request- und einem Response-Teil. Die
beiden Nachrichten sind gleich aufgebaut, unterscheiden sich jedoch in Bezug auf den Inhalt.
6

Als erstes enthält die SOAP-Nachricht einen HTTP-Header, der aber für die Ausführung eines
Webservice keinerlei relevante Informationen enthält. Daraufhin folgt ein Teil, der zum einen
den Namen der aufgerufenen Funktion bzw. Methode beinhaltet, zum anderen Typen und
Werte der übergebenen Parameter. Ein beispielhafter Request könnte folgendes Aussehen
besitzen:
42
2.2.2 WSDL
In der Web Service Description Language (WSDL) wird beschrieben, welche Informationen in
den SOAP-Nachrichten sein müssen. WSDL beruht auf XML und beschreibt, wie der
Versender eine Nachricht strukturieren muß. Ein Webservice definiert mit Hilfe von WSDL
also seine Schnittstellen. Er legt fest, welche Nachrichten er annimmt, welche Informationen
(Parameter) die Nachricht enthalten muß und welche Antworten er mit welchen Parametern
zurückgibt. Damit bildet WSDL eine Interface Definition Language (IDL) für Webservices.
Die Definition von WSDL erfolgt im W3C [W3C] unabhängig von einer bestimmten
Transportschicht. Derzeit werden WSDL über so genannte Bindings drei Transport-
Möglichkeiten zugeordnet: SOAP, HTTP und MIME (Multi Purpose Internet Mail
Extensions). Der generelle Aufbau einer WSDL-Beschreibung für einen einfachen Webservice
ist wie folgt:
• Typdefinitionen
• Nachrichtendefinition
• Porttypdefinition
• Bindungen
• Dienstdefinition
Dies sei an folgender einfacher Methode erläutert:
public class example {
private int verbosity = 5;
private String url =
"http://localhost:8079/example/services/example";
}
public String getUserNameFromID(int id) {
return "User" + id;
}
In der Typdefinition der WSDL Beschreibung können individuelle Typen definiert werden,
welche an dem Funktionsaufruf beteiligt sind [W3C, Walsh 2002]. In obrigem Beispiel ist
dies nicht notwendig, da keine nicht-primitiven Datentypen am Funktionsaufruf beteiligt sind.
Im nächsten Abschnitt, der Nachrichtendefinition, werden die eingehenden und ausgehenden
Nachrichten spezifiziert. Dies beinhaltet die Übergabeparameter und den Rückgabewert.
7

In der sogenannten Porttypdefinition wird die Reihenfolge der zu übergebenden Parameter
festgelegt. Dazu kommt die Angabe, welche der vorher definierten Nachrichten Eingabe-
bzw. Ausgabenachrichten sind. Im Beispiel ist getUserNameFromIDRequest die eingehende
und getUserNameFromIDResponse die ausgehende Nachricht.
In den Bindings wird festgelegt, welches Protokoll zur Übertragung der Daten verwendet
werden soll. Zur Auswahl stehen Erweiterungen von SOAP, HTTP GET/POST und MIME. In
den Bindings muß genau ein Protokoll definiert werden. Im Beispiel ist dies eine Erweiterung
zu SOAP.
In der Dienstdefinition wird die Adresse angegeben, unter welcher der Webservice bzw. das
dazugehörige Binding später erreichbar ist. Dies beinhaltet auch die Angabe eines Ports.
2.2.3 WSCL
Für den Zugriff auf einen Webservice spielt die Reihenfolge der Nachrichten, in der diese
ausgetauscht werden, eine entscheidende Rolle. WSDL kann diese nicht definieren, da es nur
Schnittstellen und keine Interaktionen beschreibt. Aus diesem Grunde wurde die WebService
Conservations Language (WSCL) eingeführt. WSCL-Dokumente beschreiben die Reihenfolge,
in der die XML-Nachrichten für den ordnungsgemäßen Ablauf eines Webservice-Zugriffs
8

ausgetauscht werden müssen. Damit ermöglicht WSCL auch die Veröffentlichung von
komplexen Webservices, bei denen ein Zugriff nicht nur aus einer Anfrage und einer Antwort
besteht. Sobald WSDL-Definitionen in der UDDI-Registry veröffentlicht werden, legt ein
Webservice-Anbieter entsprechende WSCL-Beschreibungen in der Registry ab. Ein
zugreifendes Programm lädt dann die entsprechenden Definitionen.
2.2.4 UDDI
Nachdem eine Beschreibung eines Webservice erzeugt wurde, muß ein potentieller Nutzer in
die Lage versetzt werden, diesen Dienst finden zu können. Dazu dient das UDDI-Projekt
(Universal Description, Discovery, and Integration), welches ein durchsuchbares Register
von Diensten und deren Beschreibungen darstellt.
„UDDI besteht aus zwei Teilen: Einer Registry aller Metadaten eines
Webservice (einschließlich eines Verweises auf die WSDL-Beschreibung eines
Dienstes) sowie aus einer Reihe von WSDL-Port-Typ-Definitionen zum
Verändern und Durchsuchen dieser Registratur.“ [Snell 2002].
2.3 SGML
Die Standard Generalized Markup Language (SGML) [Rieger 1995, Goldfarb 1991] ist ein
ISO-Standard zur Beschreibung von Dokumentstrukturen. Sie ist zugleich als standardisiertes
Dateiformat zum Austausch von Dokumenten zu sehen. SGML erlaubt dabei durch einen
(programmier-)sprachlichen Ansatz, ein Regelwerk für Dokumente (Document Type
Definition, DTD) festzulegen, bei dem Syntax und Semantik getrennt definiert werden
können. SGML standardisiert jedoch nur die Sprache zum Entwickeln eines solchen
Regelwerkes, nicht das Regelwerk selbst. Für ein Dokument ist es nicht ausreichend zu sagen,
es liegt im SGML-Format vor, vielmehr ist logisch betrachtet die DTD ein Teil des
Dokuments.
2.4 HTML
Die HyperText Markup Language (HTML) [W3C] ist das Format, in dem die Text- und
Hypertext-Informationen im Internet gespeichert und übertragen werden und ist mittels der
Sprachdefinition SGML definiert, entspricht also einem SGML-Document-Type. HTML
unterstützt ein logisches Markup, bei dem die logische Bedeutung der Textteile festgelegt
wird, so da sie von einem Web-Browser in einer geeigneten Art und Weise interpretiert und
dargestellt werden können. HTML ist eine eingebettete Sprache, was bedeutet, die HTML-
Befehle werden im Dokument selbst plaziert.
Die HTML-Befehle, welche dieses logische Markup beschreiben, werden auch Tags genannt.
Ein Tag besteht dabei aus einem Tag-Namen und einer optionalen Reihe von Tag-Attributen
und wird von einem Paar spitzer Klammern („< .... >“) umrahmt. Die meisten Tags bestehen
aus einem Anfangs- und einem Ende-Tag und beeinflussen nur den Textabschnitt, der sich
zwischen diesen beiden Teilen befindet. Das Ende-Tag besitzt den gleichen Tag-Namen hinter
einem normalen Schrägstrich („/“), die Attribute entfallen.
...
Des weiteren existieren auch einige HTML-Befehle ohne Ende-Tag, welche den kompletten
nachfolgenden Dokumentteil beeinflussen und aus diesem Grund keine End-Markierung
benötigen, oder aber für sich stehen und keine weiteren Tags enthalten können.
9

2.5 XML
Die eXtensible Markup Language (XML) [W3C] ist eine Untermenge von SGML und eignet
sich ebenfalls zur Definition von Dokumenttypen. Die Syntax, Struktur und Bedeutung der
Tags wird in XML wie in SGML mit einer Document Type Definition (DTD) oder einem
Schema definiert. Wie die Elemente sichtbar dargestellt werden sollen, kann mit der
eXtensible Stylesheet Language (XSL) oder durch Cascading Style Sheets (CCS) definiert
werden. Die Grundidee von XML ist letztlich, die logische Bedeutung von Daten,
Informationen und Texten festzulegen. XML unterscheidet sich von HTML unter anderem
dadurch, daß Informationsanbieter eigene Tags und deren Attribute nach Bedarf selbst
definieren können. Durch die gegenüber HTML deutlich strengere Syntax von XML ist es
zudem wesentlich einfacher und effizienter, XML-Dokumente auszutauschen und innerhalb
von Programmen weiterzuverarbeiten.
2.6 DOM
Das Document Object Model (DOM) [W3C] des WWW-Konsortiums ist eine plattform- und
sprachunabhängige Schnittstellendefinition, welche es erlaubt, sowohl XML- als auch HTML-
Dokumente zu beschreiben. Es ermöglicht dabei sowohl einen dynamischen Zugriff, als auch
die dynamische Bearbeitung der Dokumente und hat sich mittlerweile in zahlreichen
Implementierungen dieser Schnittstellendefinitionen bewährt.
Die DOM-Spezifikation ist in drei Teile untergliedert: Das Kernmodul, das HTML-Modul und
das XML-Modul. Die Schnittstellen des Kernmoduls sind minimal gehalten und repräsentieren
dabei strukturierte Dokumente. Sie sind somit die Basis für Zugriffe sowohl auf XML-, als
auch auf HTML-Dokumente. Das HTML- und das XML-Modul unterstützen eine zusätzliche,
auf spezielle Bedürfnisse des Dokumenttyps angepaßte Sicht und erlauben einen leichteren
direkteren Zugriff auf das jeweilige Dokument.
DOM wurde bisher in drei Stufen (Levels) entwickelt: Stufe 1 definiert das Kern-, HTML- und
XML-Modell. Stufe 2 enthält ein Style Sheet Object Model mitsamt der Funktionalität, diese
Style Sheets eines Dokuments zu bearbeiten. Zudem enthält diese Stufe die Möglichkeit,
Dokumente zu traversieren, definiert ein Modell zur Ereignissteuerung und unterstützt XML-
Namensräume. Stufe 3 definiert das Laden und Speichern von Dokumenten sowie die zu den
Dokumenten gehörenden Modelle wie eine DTD. Weiterhin realisiert sie Sichten auf
Dokumente und deren Formatierung und ermöglicht Ereignisse und Ereignisgruppen.
2.7 Baumdarstellung eines HTML-Dokumentes
Abbildung 2.1: Seite im Browser
10

Jedes korrekte HTML-Dokument kann auf eine Baumdarstellung, genauer auf eine Tag-
Hierarchie abgebildet werden [Flanagan 1998]. Dieser Baum ist so aufzubauen, daß ein
innerer Tag stets Kind des nächst äußeren Tags ist. Die Abbildungen 2.1, 2.2 und 2.3 zeigen
eine Seite in einem gängigen Browser, den Quelltext dieser Seite sowie seine
Baumdarstellung.
Eine wichtige Eigenschaft von HTML-Dokumenten und HTML-Bäumen ist, daß eine
äquivalente Abbildung von korrekten HTML-Dokumenten in die zugehörigen
Baumdarstellungen möglich ist. Korrekt bedeutet hier die Einhaltung der dem HTML-
Standard zugrundeliegenden Sprachdefinitionen, was in der Realität jedoch in der Regel nicht
gewährleistet ist. Mittels fehlertoleranter Parser lassen sich auch nicht korrekte HTML-
Dokumente in Baumdarstellungen überführen, die zu einer korrekten Version des
Dokumentes äquivalent sind.
Der HTML-Baum besitzt drei Arten von Knoten: Den Wurzelknoten, die internen Knoten und
die Blattknoten. Entspricht der Knoten einem normalen HTML-Tag, so ist der Knotenname
gleich dem Tag-Namen, ansonsten handelt es sich um eine Textpassage und der Knoten erhält
den Namen PcData und hat die Textpassage zum Inhalt. Der Wurzelknoten besitzt keinen
Vaterknoten und repräsentiert das -Tag. Interne Knoten repräsentieren die
textumschließenden Tags, bestehend aus Anfangs- und Ende-Tags, und können auf
Kindknoten verweisen. Blattknoten dürfen keine Kindknoten besitzen und repräsentieren
Textpassagen oder Tags, die für sich alleine stehen und nicht weiter verschachtelt werden
können (z.B. oder ).
Abbildung 2.2: Quelltext der Seite (gekürzt)
11

Abbildung 2.3: HTML-Baum der Seite (gekürzt, BR-Tags ausgelassen)
Eine weitere wichtige Eigenschaft ist die Rekonstruierbarkeit. Sie besagt, daß das Original-
Dokument wieder aus dem HTML-Baum durch eine Tiefensuche gewonnen werden kann,
indem die Knotennamen aneinander gereiht und verknüpft werden, wobei natürlich bei
textumschließenden Tags zu jedem Anfangs-Tag nach den enthaltenen Tags auch ein Ende-
Tag gesetzt werden muß. Dieses Verfahren stellt also die äquivalente Rückabbildung eines
HTML-Baumes in das zugehörige HTML-Dokument dar. Die Abbildung eines (nicht
unbedingt korrekten) HTML-Dokumentes in einen HTML-Baum und dann zurück in ein
korrektes HTML-Dokument kann folglich auch zur Korrektur von Fehlern in HTML-
Dokumenten genutzt werde.
2.8 Vergleich von HTML-Dokumenten
An einigen Stellen dieser Arbeit werden Möglichkeiten zum Vergleich von HTML-
Dokumenten benötigt. Zieht man ihre Baum-Darstellung mit in Betracht, so ergeben sich drei
Varianten:
• Der einfachste und exakteste Vergleich wäre die simple Überprüfung, ob die String-
Repräsentationen der HTML-Dokumente übereinstimmt. Dabei würde sich allerdings
bereits durch den Austausch eines Banners oder durch die Änderung eines Sitzungs-
Schlüssels in einem versteckten Feld eines Formulars () eine
Ungleichheit ergeben. Eine Gleichheit im Sinne dieses Verfahrens existiert lediglich
bei vollkommen identischen HTML-Dokumenten. Sind dynamische Inhalte enthalten,
wird dieser Fall nur sehr selten eintreten.
• Anhand der Baum-Darstellungen der HTML-Dokumente läßt sich eine syntaktische
Gleichheit definieren: Zwei HTML-Dokumente sind dann gleich, wenn ihre Baum-
Darstellungen übereinstimmen. Als Kriterium der Übereinstimmung zweier Knoten
wird lediglich die Gleichheit der durch sie repräsentierten HTML-Tags herangezogen,
nicht aber ihre Parameter oder, bei PcData-Knoten, ihr Wert. Dadurch wird eine
12

Abstraktion der Gleichheit vom dargestellten Inhalt der HTML-Dokumente erreicht.
Das bedeutet, es spielt keine Rolle, welcher Text oder welche Graphik angezeigt wird,
sehr wohl aber, an welcher Stelle innerhalb der Struktur des Dokumentes die Anzeige
erfolgt und welches Aussehen der Text hat. Abbildung 2.4 veranschaulicht diese Art
des Vergleiches: Baum 1 und Baum 2 sind syntaktisch gleich, obwohl die Inhalte der
PcData-Knoten – und damit die String-Repräsentation der HTML-Dokumente – nicht
übereinstimmen. Baum 1 und Baum 3 dagegen sind trotz identischer Inhalte in den
PcData-Knoten syntaktisch nicht gleich, da in Baum 3 im linken Zweig ein das
HTML-Tag repräsentierender Knoten hinzu gekommen ist. Baum 1 und
Baum 4 sind syntaktisch nicht gleich, da in Baum 4 die Struktur der Tabelle in drei
-Zweige gegliedert ist, gegenüber zwei -Zweigen in Baum 1.
• Die syntaktische Gleichheit läßt sich auf eine strukturelle Gleichheit reduzieren,
indem beim Vergleich der HTML-Bäume nur solche Knoten beachtet werden, die ein
HTML-Tag mit Auswirkung auf die Struktur des HTML-Dokumentes repräsentieren
(z.B. , ), nicht aber solche, die für HTML-Tags zur Beeinflussung des
Aussehens von dargestelltem Text stehen (z.B. , ). Das bedeutet, daß
Baum 1 und Baum 3 (syntaktisch nicht gleich, siehe oben) strukturell gleich sind, da
der in Baum 3 gegenüber Baum 1 hinzu gekommene das HTML-Tag
repräsentierende Knoten nicht beachtet wird. Baum 1 und Baum 4 sind dagegen auch
strukturell nicht gleich, da der Unterschied hier in einem das HTML-Tag
repräsentierenden Knoten besteht.
Abbildung 2.4: Vergleich von HTML-Dokumenten
Bisher wurde lediglich die Gleichheit von HTML-Dokumenten betrachtet. An manchen
Stellen ist jedoch auch der Grad der Ähnlichkeit zweier HTML-Dokumente von Interesse.
Unter Einbeziehung der Baum-Darstellung ergeben sich wiederum drei Möglichkeiten, die zu
den oben zur Feststellung der Gleichheit angeführten quasi identisch sind. Der einzige
Unterschied besteht darin, daß nicht auf Gleichheit getestet wird, sondern eine graduelle
Einstufung der Ähnlichkeit der verglichenen HTML-Dokumente gewünscht ist.
13

Für den Vergleich der String-Repräsentationen kann ihre minimale Editierdistanz (für deren
Bestimmung existieren effiziente Algorithmen wie die Levenshtein-Distanz) zur mittleren
Länge beider Strings ins Verhältnis gesetzt werden. Bei den beiden auf der Baum-Darstellung
basierenden Vergleichsverfahren ist diese allerdings nicht ohne weiteres anwendbar. Eine
Möglichkeit besteht darin, beide Bäume in Tiefen- und / oder Breitensuche zu traversieren
und in eine Art String-Darstellung umzuwandeln, wobei jedes durch einen Knoten
repräsentierte HTML-Tag auf ein Zeichen abgebildet wird: gleiche Tags auf das jeweils
gleiche Zeichen, unterschiedliche immer auf unterschiedliche. Zwischen diesen beiden
Zeichenketten ließe sich nun wiederum die minimale Editierdistanz bestimmen und zu ihrer
mittleren Länge ins Verhältnis setzen.
Abbildung 2.5: Editierdistanz zweier Bäume in String-Repräsentation
Dabei ergibt sich allerdings das Problem, daß Unterschiede immer gleich stark gewichtet
werden, egal, wie nahe sie bei der Wurzel des Baumes liegen oder wie weit entfernt von
dieser. Abbildung 2.5 verdeutlicht dies: Eine Änderung an der Struktur des HTML-
Dokumentes wird in gleichem Maße als Unterschied gewertet wie eine Änderung am
Erscheinungsbild eines Stückes dargestellten Textes. Diese Diskrepanz läßt sich vermeiden,
wenn der Vergleich der Bäume rekursiv über die Baum-Ebenen durchgeführt wird (Ebene:
Menge aller Knoten mit gleicher Pfadlänge zur Wurzel). Dies erfolgt auf Basis folgender zwei
Regeln:
• Verglichen werden immer Knoten, die sich auf der gleichen Ebene befinden und
gleiche HTML-Tags repräsentieren.
• Zwei Knoten sind immer so gleich wie das Mittel ihrer Kind-Knoten, gewichtet nach
der Anzahl der Knoten in den Teilbäumen unter ihnen. Ist mindestens einer der beiden
Knoten ein Blatt-Knoten, so werden lediglich die durch sie repräsentierten HTML-
Tags verglichen. Bei gleichen HTML-Tags ist die Gleichheit 1, sonst 0. Hat ein
Knoten keinen Vergleichs-Partner, wird der Vergleich als 0 gewertet. Haben beide
14

Knoten mehrere Kind-Knoten, so wird die Zuordnung dieser zueinander gewertet, die
die höchste Ähnlichkeit ergibt.
Auf diese Art werden die beiden zu vergleichenden HTML-Bäume von der Wurzel zu den
Blättern in Beziehung zueinander gesetzt, um anschließend den Grad der Ähnlichkeit von den
Blättern zur Wurzel zu berechnen. Abbildung 2.6 veranschaulicht dieses Verfahren. Baum 1
und Baum 2 unterscheiden sich lediglich in einem das HTML-Tag
repräsentierenden Knoten, Baum 3 und Baum 4 dagegen in der Struktur der Teilbäume unter
dem Wurzelknoten, der das HTML-Tag repräsentiert. Das Vergleichsverfahren
findet für Baum 1 und Baum 2 eine Ähnlichkeit von 59%, für Baum 3 und Baum 4 dagegen
nur 53%. Die Änderung am Aussehen eines Dargestellten Text-Stückes durch das Einfügen
des HTML-Tags vermindert die Ähnlichkeit zweier HTML-Dokumente also nicht
so stark wie eine Umorganisation in der Struktur einer Tabelle.
Abbildung 2.6: Vergleich von HTML-Bäumen rekursiv über ihre Ebenen
2.9 Hierarchische Pfadausdrücke
Hierarchische Pfadausdrücke [Bak 1999, Bodor 1999] verfolgen einen Ansatz, der eine
hierarchiebasierte Navigation durch den HTML-Baum der Informationsquelle erlaubt und
somit die Informationsextraktion aus einem Knoten dieses Baumes ermöglicht. Zunächst wird
die bisher verwendete Definition erläutert, anschließend wird sie so erweitert, daß die an diese
Arbeit gestellten Anforderungen damit umsetzbar sind.
15

2.9.1 Bisherige Definition
Der in [Schneider 2001] verwendete Pfadausdruck besitzt folgende Syntax:
ZAHL ::= 0 | ...
INDEX ::= ZAHL | *
KNAME ::= {Menge aller HTML-Tags}
KNOTEN ::= KNAME[INDEX]
OP ::= attlist[INDEX] | #PCDATA
AUSDRUCK ::= (KNOTEN)+ OP
Wie aus der Syntaxdefinition ersichtlich ist, besteht ein Ausdruck aus ein oder mehreren
hintereinander gekoppelten Knotenausdrücken und einer abschließenden Operation auf dem
oder den zuletzt erreichten Knoten. Der Knotenausdruck besteht hierbei aus dem Namen eines
HTML-Tags und der Angabe eines Index in eckigen Klammern, wobei der Index eine
natürliche Zahl ( ≥ 0 ) oder ein Stern (*) ist. Die Navigation durch den HTML-Baum wird
dabei so beschrieben, daß der Knotenname mit dem Tag-Namen des augenblicklich erreichten
Knotens übereinstimmt und der Index den oder die Kindknoten beschreibt. Der erste
Knotenname lautet dabei grundsätzlich html und beschreibt die Wurzel des HTML-Baums.
Obwohl die Bestimmung der Kindknoten und somit auch die gesamte Navigation durch die
Indizes allein vollzogen werden kann, wird die Angabe des nächsten Knotennamens dazu
verwendet, den jeweils erreichten Knoten zu verifizieren, da der erreichte Knoten mit dem
angegebenen Knotennamen übereinstimmen muß. Der Index selbst indiziert den Kindknoten
in fortlaufender Numerierung und beginnt bei attributlosen Knoten bei [0], bei
attributbehafteten Knoten bei [1]. In letzterem Fall ist der Index [0] für die
Attributextraktion reserviert. Ist der Index durch einen Stern ausgedrückt, wird an der Stelle
im Baum verzweigt und die Navigation bei allen Kindknoten mit folgendem geforderten
Knotennamen fortgesetzt. Dementsprechend ist auch nicht ein einzelner Knoten zu erwarten,
sondern eine Knotenmenge. Die letzte Angabe des Ausdrucks ist eine Knotenoperation, wobei
zum einen durch den attlist[]-Operator Attribute extrahiert werden können, zum anderen
der Inhalt eines PcData-Knotens extrahiert werden kann. Die Angabe des Attributs geschieht
analog wie die Knotenindizierung, in fortlaufender Numerierung.
Anhand des Beispiel-Dokumentes aus Abschnitt 2.7 wird erklärt, wie ein bestimmter Teil des
HTML-Dokumentes mithilfe eines hierarchischen Pfadausdrucks ausgewählt werden kann.
Als Beispiel stehen hier drei hierarchische Pfadausdrücke mit ihren Ergebnissen.
Anfrage : html[1]body[0]table[1]tr[1]td[3]#PCDATA
Ergebnis : ["ISBN 0-596-00283-1"]
Anfrage : html[1]body[0]table[1]tr[1]td[7]a[1]#PCDATA
Ergebnis : ["UB Karlsruhe"]
Anfrage : html[1]body[0]table[1]tr[1]td[*]a[1]#PCDATA
Ergebnis : ["UB Karlsruhe", "Volltext / Multimedia"]
Nachteile dieser Pfadausdruck sind folgende:
• Eine Lesbarkeit für den Benutzer geht wegen der uneinheitlichen Indizierungsweise
(Indizes bei attributlosen und attributbehafteten Knoten) verloren.
• Die Extraktion von Knoten-Attributen, z.B. des href-Parameters eines Knotens, der
das HTML-Tag repräsentiert, ist unsicher, da die Reihenfolge der Parameter von
HTML-Tags und damit die der Knoten-Attribute nicht fest definiert ist.
• Das *-Index kann nur einmal per Ausdruck vorkommen - keine ausreichende HTML-
Syntax ist damit gesichert (Man betrachte etwa eine Anfrage wie „allen Bücher aller
Autoren über Java“).
• Die direkt Anwendung regulärer Ausdrücke auf das Ergebnis einer Anfrage ist nicht
vorgesehen.
16

2.9.2 Reguläre Ausdrücke zur Extraktion von Teilstrings
Eine der wichtigsten Anforderungen an diese Arbeit ist, den Wandler in die Lage zu
versetzen, einzelne Datenelemente (Teilstrings) aus Strings extrahieren zu können. Dazu
wurden reguläre Ausdrücke entwickelt, die auf Strings angewendet werden können. Sie haben
folgende Form:
GRENZE ::= {Menge alle Zeichenketten}
ZIEL ::= {?} + | § | *{?} + | {?} + *
RESTL ::= {+} + | *GRENZE | GRENZE
RESTR ::= {+} + | GRENZE* | GRENZE
AUSDRUCK ::= {RESTL} * ZIEL{RESTR} *
Die Idee dabei ist, den String, aus dem eine Teil extrahiert werden soll, anhand von immer
vorhandenen, zwischen den veränderlichen Datenelementen stehenden Zeichenfolgen
(Grenzstring, GRENZE) zu zerlegen. Dabei haben die Zeichen §, ?, * und + besondere
Bedeutungen:
• §: Der zu extrahierende Teilstring (Zielstring), sofern dieser eine variable Länge hat,
beispielsweise der Titel eines Buches
• ?: Ein Zeichen des zu extrahierenden Teilstrings (Zielstring), sofern dieser eine feste
Länge hat, wie etwa das Erscheinungsjahr eines Buches oder seine ISBN-Nummer
• *: Ein nicht zu extrahierender Teilstring (Abfallstring), sofern dieser eine variable
Länge hat, ein gerade nicht zu extrahierendes Datenelement variabler Länge
• +: Ein Zeichen eines nicht zu extrahierenden Teilstrings (Abfallstring), sofern dieser
eine feste Länge hat
Die Anwendung auf einen Eingabestring erfolgt von links nach rechts mittels folgendem
Algorithmus:
So lange unbearbeitete Teile des Regulären Ausdrucks vorhanden sind {
Erster Teil ist Abfallstring variabler Länge (*)
Nächster Teil ist Zielstring fester Länge ({?} + )
Eingabestring endet mit Zielstring fester Länge
Zielstring zurückgeben
Übernächster Teil ist ein Abfallstring fester Länge ({+} + )
Eingabestring endet mit dem Abfallstring fester Länge
Zielstring zurückgeben
Drittnächster Teil ist ein Grenzstring (GRENZE)
Grenzstring und alles danach abschneiden
Übernächster Teil ist ein Grenzstring (GRENZE)
Grenzstring und alles danach abschneiden
Nächster Teil ist ein Grenzstring (GRENZE)
Grenzstring und alles davor abschneiden
Zielstring variabler Länge (§)
Eingabestring endet mit dem Zielstring variabler Länge
Zielstring zurückgeben
Nächster Teil ist ein Abfallstring fester Länge ({+} + )
Eingabestring endet mit dem Abfallstring fester Länge
Zielstring zurückgeben
Übernächster Teil ist ein Grenzstring (GRENZE)
Zielstring zurückgeben
Nächster Teil ist ein Grenzstring (GRENZE)
Zielstring zurückgeben
Zielstring fester Länge ({?} + )
Zielstring zurückgeben
Abfallstring fester Länge ({+} + )
Abfallstring vom Anfang des Eingabestrings entfernen
Grenzstring (GRENZE)
Grenzstring vom Anfang des Eingabestrings entfernen
}
17

An folgenden Beispielen soll die Anwendung dieser Regulären Ausdrücke auf einen
Eingabestring verdeutlicht werden:
Eingabestring: Java in a nutshell : a desktop quick reference ;
[covers Java 1.4] / David Flanagan. - 4. ed.. - Cambridge ; Köln :
O'Reilly, 2002. - XXI, 969 S.; (engl.)
Regulärer Ausdruck: § / *
Ergebnis: Java in a nutshell : a desktop quick reference ; [covers
Java 1.4]
Eingabestring: (wie oben)
Regulärer Ausdruck: * / §. - *
Ergebnis: David Flanagan
Eingabestring: (wie oben)
Regulärer Ausdruck: *. - *. - §++++++. - *
Ergebnis: Cambridge ; Köln : O’Reilly
Eingabestring: (wie oben)
Regulärer Ausdruck: *. - *. - *????. - *
Ergebnis: 2002
Eingabestring: Java in a nutshell / David Flanagan, 2002
Regulärer Ausdruck: § / *
Ergebnis: Java in a nutshell
Eingabestring: (wie oben)
Regulärer Ausdruck: * / §++++++
Ergebnis: David Flanagan
Eingabestring: (wie oben)
Regulärer Ausdruck: *????
Ergebnis: 2002
Die Anwendung des Ausdrucks „*. - *. - §++++++. - *“ auf den Eingabestring „Java
in a nutshell : a desktop quick reference ; [covers Java 1.4] / David
Flanagan. - 4. ed.. - Cambridge ; Köln : O'Reilly, 2002. - XXI, 969 S.;
(engl.)“ soll an dieser Stelle noch einmal genau und in ihren einzelnen Schritten betrachtet
werden:
Eingabestring = Java in a nutshell : a desktop quick reference ;
[covers Java 1.4] / David Flanagan. - 4. ed.. - Cambridge ; Köln :
O'Reilly, 2002. - XXI, 969 S.; (engl.)
Regulärer Ausdruck: *. - *. - §++++++. - *
*. - *. - §++++++. - * zerfällt in:
* (Abfallstring variabler Länge)
. – (Grenzstring)
* (Abfallstring variabler Länge)
. – (Grenzstring)
§ (Zielstring variabler Länge)
++++++ (Abfallstring fester Länge)
. – (Grenzstring)
* (Abfallstring variabler Länge)
Anwendung *. - auf Eingabestring �
Eingabestring = 4. ed.. - Cambridge ; Köln : O'Reilly, 2002. - XXI,
969 S.; (engl.)
Anwendung *. - auf Eingabestring �
Eingabestring = Cambridge ; Köln : O'Reilly, 2002. - XXI, 969 S.;
(engl.)
Anwendung §++++++. - auf Eingabestring �
Ergebnis = Cambridge ; Köln : O'Reilly
18

2.9.3 Erweiterung der Hierarchischen Pfadausdrücke
Der in Abschnitt 2.9.1 vorgestellte Ansatz der hierarchischen Pfadausdrücke wird für diese
Arbeit etwas abgewandelt und erweitert, um den gestellten Anforderungen (z.B. nach der
Fähigkeit zur Anwendung regulärer Ausdrücke auf den Inhalt von PcData-Knoten) gerecht
werden zu können und die aufgezählten Nachteile zu beseitigen:
ZAHL ::= 0 | ...
BEREICH ::= ZAHL-ZAHL | ZAHL-*
INDEXTEIL ::= ZAHL | BEREICH
INDEX ::= * | INDEXTEIL | INDEXTEIL, INDEXTEIL, ...
KNAME ::= {Menge aller HTML-Tags}
KNOTEN ::= KNAME | [INDEX] | KNAME[INDEX] |
WERT ::= "Wert", Wert beliebige Zeichenkette
ENDKNOTEN ::= KNOTEN | WERT[INDEX] | WERT
ATTNAME ::= {Menge aller Attribute aller HTML-Tags}
REGEX ::= {Menge aller Regulären Ausdrücke aus 2.9.2}
OP ::= ATTNAME | (REGEX) | ATTNAME(REGEX)
PFAD ::= {KNOTEN.} * + ENDKNOTEN
AUSDRUCK ::= PFAD | PFAD + OP
Die Indizierung der Kindknoten beginnt dabei immer bei 0. Die Pfadausdrücke werden wie
folgt interpretiert:
• Ist [INDEX] in einem KNOTEN oder im ENDKNOTEN nicht angegeben, so wird dies als
[0] interpretiert.
• Ist INDEX gleich *, so werden dadurch alle Kind-Knoten des aktuellen Knotens
adressiert.
• Ein BEREICH entspricht der Aufzählung aller ZAHLen zwischen den beiden
angegebenen. 4-7 entspricht z.B. 4,5,6,7. Ist die zweite ZAHL durch einen * ersetzt,
so wird an dessen Stelle dynamisch die Anzahl der Kind-Knoten des aktuellen
Knotens eingesetzt. Ist die zweite ZAHL kleiner als die erste, so werden sie vertauscht.
• Besteht INDEX aus mehreren INDEXTEILen, so werden dadurch alle durch einen der
INDEXTEILe adressierten Kind-Knoten adressiert. Dieser Aufbau von INDEX entspricht
damit einer einschränkenderen Variante von *.
• [INDEX] adressiert den INDEX-ten Kind-Knoten des aktuellen Knotens, wenn kein
KNAME oder WERT angegeben ist.
• KNAME[INDEX] adressiert den INDEX-ten Kind-Knoten des aktuellen Knotens, dessen
Typ KNAME ist.
• WERT[INDEX] adressiert den nach Tiefensuche INDEX-ten PcData-Knoten im Teilbaum
unter dem aktuellen Knoten, dessen Wert die Zeichenfolge Wert enthält.
• Ist OP nicht angegeben, wird der Wert des Knotens zurückgegeben. Außer bei Knoten
vom Typ PcData ist dieser immer leer.
• Hat OP die Form (REGEX), so wird REGEX auf den Wert des Knotens angewendet und
das Ergebnis zurückgegeben.
• Hat OP die Form ATTNAME, so wird der Wert des Attributes ATTNAME zurückgegeben,
falls dieses gesetzt ist, andernfalls ParameterNotSet.
• Hat OP die Form ATTNAME(REGEX), so wird REGEX auf den Wert des Attributes
ATTNAME angewendet und das Ergebnis zurückgegeben.
Anhand des Beispiel-Dokumentes aus Abschnitt 2.7 wird erklärt, wie ein bestimmter Teil des
HTML-Dokumentes mithilfe eines hierarchischen Pfadausdrucks ausgewählt werden kann.
Als Beispiel steht hier eine Reihe von hierarchischen Pfadausdrücken mit ihren Ergebnissen.
Die ersten drei sind die den Beispielen aus Abschnitt 2.9.1 entsprechenden.
19

Anfrage : html[0].body[0].table[0].tr[0].td[0].PcData[1]
Ergebnis : ["ISBN 0-596-00283-1"]
Anfrage : html[0].body[0].table[0].tr[0].td[0].a[0].PcData[0]
Ergebnis : ["UB Karlsruhe"]
Anfrage : html[0].body[0].table[0].tr[0].td[0].a[*].PcData[0]
Ergebnis : ["UB Karlsruhe", "Volltext / Multimedia"]
Anfrage : html[0].body[0].table[0].tr[0].td[0]."ISBN"[0]
Ergebnis : ["ISBN 0-596-00283-1"]
Anfrage : html.body.table."ISBN"
Ergebnis : ["ISBN 0-596-00283-1"]
Anfrage : html[0].body[0].table[0].tr[0].td[0]."ISBN"[0](+++++§)
Ergebnis : ["0-596-00283-1"]
Anfrage : html[0].body[0].table[0].tr[0].td[0].a[0]href
Ergebnis : [href-Parameter des -Knotens als String]
2.10 Wandler
Zunächst ist zu klären, was genau im Zusammenhang mit Software unter einem Wandler zu
verstehen ist. Bei [TFD] findet sich folgende Definition:
„Aus informatischer Sicht beschreibt das Wort Wandler eine Komponente, die
festlegt, wie eine ihr übergebene Code-Sequenz ausgeführt wird.
Der Wandler fungiert als Schnittstelle zwischen seinem Aufrufer und der ihm
übergebenen Code-Sequenz. Dies kann zum einen der Kompatibilität dienen, z.B.
wenn der zu wandelnde Code in einer anderen Programmiersprache oder unter
anderen Aufruf-Bedingungen vorliegt als der ausführende, zum zweiten der
Sicherheit, z.B. um den ausführenden Code vom Aufruf bestimmter Funktionen oder
Methoden innerhalb der zu wandelnden Codes abzuhalten, und zum dritten der
Emulation einer bestimmten Umgebung für den zu wandelnden Code durch den
Wandler, z.B. zur Interpretation von Skriptsprachen innerhalb eines Web-Browsers.
Der letztliche Sinn besteht darin, den zu wandelnden Code ausschließlich über den
Wandler zugreifbar zu machen.“
Diese Definition greift deutlich weiter, als man den Begriff Wrapper landläufig versteht, wird
er doch in der Regel Programmen, Komponenten und Skripten zugeordnet, die der Extraktion
von Informationen aus Internetseiten dienen. Obrige Definition schließt dagegen auch jegliche
Interpreter und Virtual Machines mit ein. Streng genommen kann man sogar das Geheimnis-
Prinzip objektorientierter Programmiersprachen wie Java unter die Definition fassen, sind
doch als private deklarierte Variablen und Methoden der Objekte von außerhalb nur indirekt
über nicht so deklarierte Methoden zugreifbar, wenn überhaupt.
Es finden sich aber auch Definitionen, die der landläufigen Interpretation deutlich näher
kommen und den Begriff des Wrappers mit der Weiterverarbeitung von Internetseiten durch
spezielle Komponenten in Zusammenhang bringen:
• [Azavant 2000] „[Wandler sind] Software-Komponenten, die im Internet [über
HTML-Seiten] veröffentlichte Informationen in eine Applikation integrieren”
• [Cohen 1999] „Ein Wandler ist ein spezielles Programm, das Informationen aus
Internetseiten eines bestimmten Formates extrahiert.”
• [Grieser 2000] „Intuitiv betrachtet beschreiben Wandler, wie sich weitestgehend
unstrukturierte Informationen (Text, Bilder, ...) in einen syntaktischen Rahmen
fassen lassen. Umgekehrt legten sie damit implizit fest, wie diese Informationen
in semi-strukturierten Quellen lokalisiert und aus diesen extrahiert werden
können.“
20

• [Kuhlins 2004] „Im Problembereich der automatisierten Informationsextraktion
aus HTML-Seiten des WWW versteht man unter Wrappern spezialisierte
Softwareroutinen, die im Wesentlichen drei Aufgaben erfüllen: Erstens müssen
sie HTML-Seiten von einer Website herunterladen. Zweitens die gewünschten
Daten in den Seiten lokalisieren sowie extrahieren. Und drittens die so
gewonnenen Daten in einem geeignet strukturierten Ausgabeformat zur weiteren
Manipulation zur Verfügung stellen. Die Daten können dann von anderen
Anwendungen eingelesen und weiterverarbeitet werden.“
Diese letzten vier Definitionen legen folgendes Fazit nahe: Die Informationen auf
Internetseiten sind für das intuitive Verständnis durch Menschen aufgearbeitet und
strukturiert, nicht für die Lesbarkeit durch Software. Der Begriff des Wandlers beschreibt
Programme, Komponenten und Skripte, die diese Lücke überbrücken. Welche technischen
Ansätze dabei zur Anwendung kommen, wir in einem späteren Kapitel dieser Arbeit
beleuchtet.
21

3. Das UniCats-i-Projekt
In diesem Kapitel soll zunächst das UniCats-i-System als Ganzes beschrieben werden, da es
das Umfeld für den späteren Einsatz der im Rahmen dieser Arbeit zu erstellenden
Komponenten und Werkzeuge darstellt. Anschließend wird der Anbieter-Agent beschrieben,
der den Wandler enthält und mit dem der zu schaffende Generator-Agent daher direkt
zusammenarbeiten soll. Abschließend wird die Rolle des zu schaffenden Generator-Agenten
in Bezug auf das gesamte UniCats-i-System beleuchtet.
Ziel des Projektes UniCats-i ist die Entwicklung einer Infrastruktur für offene Märkte. Die
Anwendungsdomäne sind Märkte der wissenschaftlichen Literaturversorgung [Christoffel
2003]. Eine Vielzahl von Anbietern und Diensten existierender Informationsquellen im
Bibliotheksbereich sollen mittels der UniCats-i-Umgebung einheitlich den Benutzern zur
Verfügung gestellt werden. Somit soll das jeweilige Erlernen der verschiedenen Schnittstellen
umgangen werden und die Einarbeitungszeit erheblich verkürzt werden.
Die UniCats-i-Umgebung besteht aus den folgenden Teilnehmern:
• Anbieter: Anbieter stellen Dienste zur Suche und Beschaffung wissenschaftlicher
Literatur bereit. Zu den Anbietern zählen Bibliotheken, Verlage und Buchhändler.
• Kunden: Kunden aus dem wissenschaftlichen Bereich suchen wissenschaftliche
Literatur für wissenschaftliche Zwecke. Kunden sind Hochschulangehörige,
Studierende und Forschende.
• Kundenorganisationen: Kundenorganisationen vertreten die Interessen von
Kundengruppen, wie beispielsweise Hochschulen oder Firmen.
• Finanzorganisationen: Finanzorganisationen führen die Finanzdienstleistungen
zwischen Marktteilnehmern aus, wie beispielsweise Banken.
3.1 Der Aufbau des UniCats-i-Systems
3.1.1 Die Agentenarchitektur
Die UniCats-i-Umgebung basiert auf einer Agentenarchitektur und besteht aus mehreren
miteinander kommunizierenden UniCats-i-Agenten. Agenten sind selbständig agierende
Softwareanwendungen. Jeder dieser Agenten besitzt einen Agententyp, der die Aufgabe des
Agenten und seine Schnittstelle bestimmt. Im folgenden werden die einzelnen Agententypen
vorgestellt und ihre Funktionsweise erläutert.
• Systemverwaltungsagent (SVA): Der SVA dient zur Überwachung der UniCats-i-
Umgebung. Im Fehlerfall wird der SVA informiert und kann in das Geschehen
eingreifen.
• Agentennamenagent (ANA): Der ANA verwaltet das Agentennamenregister.
• Gruppennamenagent (GNA): Der GNA verwaltet das Gruppennamenregister.
• Kundenschnittstellenagent (KSA): Der KSA ist für den Benutzerzugang
verantwortlich und stellt die Benutzerschnittstelle zur Verfügung.
• Kundenauthentifizierungsagent (KAA): Der KAA verwaltet die Zugangsnamen und
Paßwörter der Kunden.
• Kundenagent (KA): Der KA ist für die Ausführung der Literaturanfrage und für die
Bereitstellung des persönlichen Arbeitsplatzes jedes Kunden verantwortlich. Am
persönlichen Arbeitsplatz kann der Kunde Anfragen und Ergebnisse planen, ansehen
und bearbeiten.
• Anbietervermittlungsagent (AVA): Der AVA sucht für eine Literaturanfrage einen
geeigneten Anbieter.
23

• Integrationsagent (IA): Der IA stellt Anfragen parallel an mehrere Anbieter und fügt
die Ergebnisse zu einer einheitlichen Ergebnisliste zusammen.
• Anbieteragent (AA): Ein AA ist genau einem Anbieter zugewiesen und bietet ihm
eine Schnittstelle zum System.
• Kundenorganisationsagent (KOA): Der KOA leitet Anfragen von Kunden, die zu
Organisationen gehören, weiter und benutzt dabei besondere Konditionen der
Benutzerorganisation.
• Zahlungsagent (ZA): Der ZA stellt Verbindungen zu Banken her und überwacht die
Ausführung finanzieller Transaktionen.
• Rechnungsagent (RA): Der RA ist für die Rechnungsstellung und die Überwachung
der Zahlungsabwicklungen zuständig.
• Agentenauthentifizierungsagent (AAA): Der AAA hält Register, in denen
Zertifikate der Vertrauenswürdigkeit und Zuverlässigkeit der Agenten enthalten sind.
• Generatoragent (GA): Der GA sichert die Anbindung der Anbieter durch den AA. Er
ist fähig, den AA an eine veränderte Web-Schnittstelle anzupassen. Der GA wird im
Rahmen diese Arbeit entwickelt.
Jeder Agent gehört zu genau einer UniCats-i-Gemeinschaft. Die Gemeinschaften agieren auf
Anweisungen der Agenten. In der UniCats-i-Umgebung können mehrere Gemeinschaften
existieren. Die verschiedenen Gemeinschaften können auf beliebig vielen Rechnern verteilt
sein. Die Kommunikation erfolgt über das Internet. Um die Gemeinschaften eindeutig
identifizieren zu können, besitzen alle Gemeinschaften eine Adresse, die aus der IP-Adresse
des Rechners und dem dazugehörigen Port besteht. Die Agenten sind durch ihren
Agentennamen identifizierbar, der innerhalb der Gemeinschaft und eines Agentenregisters
eindeutig ist.
Neben den erwähnten Gemeinschaften und den Agenten gibt es auch UniCats-i-Gruppen, die
mehrere Agenten beinhalten können. Ein Agent kann dabei mehreren Gruppen angehören.
Die Gruppen besitzen einen Gruppennamen, der innerhalb des Gruppenregisters eindeutig ist.
Abbildung 3.1: Architektur der UniCats-i-Umgebung
24

3.1.2 Der Aufbau einer Gemeinschaft
Die UniCats-i-Gemeinschaft besteht im Wesentlichen aus dem Verwaltungsmodul, dem
Kommunikationsmodul, dem Sicherheitsmodul und einem Agentencontainer, der einen oder
mehrere Agenten halten kann. Alle erwähnten Komponenten besitzen für Test- und
Wartungszwecke eine graphische Benutzeroberfläche, die Systemsteuerung. Abbildung 3.2
zeigt grafisch den Aufbau der UniCats-i-Gemeinschaft.
Abbildung 3.2: Aufbau der UniCats-i-Gemeinschaft
3.1.2.1 Das Verwaltungsmodul
Das Verwaltungsmodul (engl. AdministrationModule) ist für das Auslesen der
Konfigurationsdatei der Gemeinschaft zuständig. In dieser Konfigurationsdatei sind unter
anderem die Adresse der Gemeinschaft, der Name der Log-Datei, das zu verwendende
Debuglevel und eine Liste aller Konfigurationsdateien der zu startenden Agenten angegeben.
Mit diesen Informationen startet das Verwaltungsmodul das Kommunikationsmodul, die
Systemsteuerung des Verwaltungsmoduls und den Agentencontainer mit den zugehörigen
Agenten. Außerdem ist das Verwaltungsmodul für das ordnungsgemäße Beenden des Systems
verantwortlich. Dabei wird über den Agentencontainer das Herunterfahren aller Agenten
eingeleitet. Sobald alle Agenten gelöscht wurden, gilt die Gemeinschaft als beendet.
3.1.2.2 Das Kommunikationsmodul
Einen zweiten wichtigen Teil der Gemeinschaft stellt das Kommunikationsmodul dar. Um zu
kommunizieren, tauschen Agenten untereinander Nachrichten durch Webservices aus. Dabei
existieren drei Arten von Nachrichten:
• Agentenkommunikation: Sie findet zwischen zwei Agenten statt.
• Gruppenkommunikation: Sie findet zwischen einem Agenten und allen Mitgliedern
einer Gruppe statt, in der der Agent Mitglied ist.
25

• Gemeinschaftskommunikation: Sie findet zwischen einem Agenten und einer
Gemeinschaft statt.
Die Kommunikation wird durch das Kommunikationsmodul unterstützt. Möchte ein Agent
eine Nachricht versenden, so wird diese nicht an den Empfänger direkt gesendet, sondern an
das Kommunikationsmodul. Das Kommunikationsmodul entscheidet darüber, ob die
Nachricht lokal, das heißt innerhalb der Gemeinschaft, verschickt werden muß. Ist dies nicht
der Fall, so wird die Nachricht extern über WebServices verschickt. Über die Lokalität
entscheidet das Kommunikationsmodul mit Hilfe des Agentrepository, welches die
Referenzen aller in der Gemeinschaft existierenden Agenten enthält. Die Informationen über
zugehörige Agenten erhält das Kommunikationsmodul von dem Verwaltungsmodul.
Eine Nachricht beinhaltet neben dem Nachrichteninhalt und der Angabe des empfangenden
Agenten als zusätzliche Informationen den Typ der Nachricht, die Daten des Senders, die
Nachrichtenidentifikationsnummer, die Kontextidentifikationsnummer sowie einen
Zeitstempel. Bei Gruppen- oder Gemeinschaftskommunikation werden außerdem die Daten
zur Gruppe und eine Liste aller Gruppenmitglieder, beziehungsweise die Adresse der
Gemeinschaft mit übergeben.
Außerdem verfügt das Kommunikationsmodul für den Testbetrieb über ein Communication-
ControlPanel, einer Benutzerschnittstelle zur Überwachung und Ansicht der ablaufenden
Kommunikation. Die nachfolgende Abbildung 12 zeigt die Struktur des
Kommunikationsmoduls.
Abbildung 3.3: Struktur des Kommunikationsmoduls
3.1.2.3 Das Sicherheitsmodul
Das Sicherheitsmodul ist für die Sicherheit innerhalb einer UniCats-i-Gemeinschaft
zuständig. Es besitzt ein erworbenes Zertifikat, mit Hilfe dessen es weitere Zertifikate bei
Anforderung ausstellen kann. Diese Zertifikate werden vom Kundenauthentifizierungsagenten
und vom Agentenauthentifizierungsagenten benötigt, um ihrerseits Ausweise für Kunden
bzw. Agenten ausstellen zu können. Da ein Zertifikat nicht gespeichert wird und bei Beenden
26

des Agenten verfällt, ist es für einen Agenten notwendig, bei jedem Neustart ein neues
Zertifikat beim Sicherheitsmodul anzufordern. Außerdem verfügt das Sicherheitsmodul über
eine Sperrliste, mit Hilfe dessen das Sicherheitsmodul ausgestellten Zertifikaten die Gültigkeit
entziehen kann. Somit kann auf Fehlverhalten reagiert werden.
3.1.2.4 Der Agent
Der Agentencontainer beinhaltet alle Instanzen der Gemeinschaft zugehörigen Agenten. Der
Agentencontainer ist für das Erzeugen der Agenten verantwortlich. Darüber hinaus kann der
Agentencontainer auch während der Laufzeit neue Agenten hinzufügen.
Ein Agent erhält vom Agentencontainer eine Referenz auf das Verwaltungsmodul und das
Kommunikationsmodul, um auf deren Methoden zugreifen zu können. Des Weiteren wird
eine Referenz auf den Dateinamen der Konfigurationsdatei übergeben, in der die
Konfiguration des Agenten beschrieben ist. Die Konfiguration des Agenten beinhaltet die
persönlichen Daten des Agenten, eine Liste mit den bekannten Agenten, eine Liste mit den
bekannten Gemeinschaften und eine Liste mit den bekannten Gruppen einschließlich der
jeweiligen Gruppenmitglieder. Diese Listen sind in den zugehörigen Repositories abgelegt:
• Das AgentRepository beinhaltet zu jedem bekannten Agenten den internen Namen
des Agenten und seine Daten, bestehend aus Name, Typ und Adresse.
• Das GroupRepository beinhaltet zu jeder bekannten Gruppe den internen Namen,
eine Liste mit allen Gruppenmitgliedern sowie die Daten zur Gruppe, bestehend aus
dem Namen der Gruppe.
• Das CommunityRepository beinhaltet die Adresse zu jeder bekannten Gemeinschaft.
• In dem ContextRepository sind die aktiven Kontexte aller Agenten aufgelistet. Jeder
Kontext besteht aus einer Sammlung zusammenhängender Nachrichten. Durch die
Verwendung von Kontexten ist es dem Agenten möglich, empfangene oder gesendete
Nachrichten in Zusammenhänge einzuordnen.
Des weiteren wird der Dateiname des Agenten abgespeichert und sein Status gesetzt. Ein
Agent kann während der Laufzeit mehrere Zustände einnehmen, die mit ihrer Bedeutung in
Tabelle 2 aufgelistet sind. Der Startzustand eines Agenten ist immer Active.
Zustand Bedeutung
Active Der Agent ist bereit Aufträge anzunehmen.
Busy Der Agent nimmt Aufträge nur eingeschränkt
entgegen.
Ill Der Agent befindet sich im Fehlerfall und
nimmt Aufträge nur eingeschränkt entgegen.
Stopped Der Agent nimmt nur Nachrichten der
Systemverwaltung entgegen.
Shutdown Der Agent nimmt keine Aufträge entgegen.
Tabelle 3.1: Auflistung aller möglichen Agentenzustände
Des Weiteren besitzt ein Agent einen Zähler, der die Nachrichtenidentifkationsnummer sowie
die Kontextidentifikationsnummer berechnet. Diese werden für den Versand von Nachrichten
benötigt.
Ebenso wie das Verwaltungsmodul und das Kommunikationsmodul besitzt jeder Agent eine
eigene Systemsteuerung, um Wartungsarbeiten und Testläufe zu unterstützen. Über diese
Systemsteuerung kann der Agent gesteuert werden, Nachrichten versendet werden und
Informationen über die Repositories des Agenten eingeholt werden. Je nach Agententyp kann
von der Systemsteuerung aus auf weitere agententypische Funktionen zugegriffen werden.
27

Abbildung 3.4 stellt die allgemeine Struktur eines Agenten dar:
Abbildung 3.4: Struktur eines Agenten
3.2 Der Anbieteragent (AA) im Speziellen
In diesem Absatz wird näher auf die Rolle des Anbieteragenten innerhalb des UniCats-i-
Systems eingegangen.
Der Anbieteragent fungiert als Bindeglied zwischen dem Anbieter einerseits und dem
UniCats-i-System andererseits. Er muß daher in der Lage sein, Suchanfragen an den Anbieter
zu stellen, die er im UniCats-i-internen Format erhält, sowie die Ergebnisse der Suche vom
Anbieter zu lesen und sie in das UniCats-i-interne Format umzuwandeln. Als Schnittstelle
nutzt er dabei die Internetseite des Anbieters. Durch die individuelle, zudem auf menschliche
Benutzer ausgelegte Gestaltung dieser Seiten und die daraus resultierende Heterogenität
ergibt sich dabei eine Reihe von Problemen:
• Die UniCats-i-internen Suchanfragen müssen in eine Anfrage an den Internet-Server
des Anbieters übersetzt werden, die beim Ausfüllen eines Suchformulars mit den
entsprechenden Suchkriterien durch einen menschlichen Benutzer und das
anschließende Abschicken des Formulars durch einen Browser generiert würde.
• Aus der als Antwort auf diese Anfrage erhaltenen HTML-Seite müssen die Ergebnisse
der Suche extrahiert und in das UniCats-i-interne Format übersetzt werden. Diese
Seiten sind wiederum auf die Lesbarkeit durch menschliche Benutzer hin abgestimmt
und daher teilweise kaum strukturiert. Sie werden oftmals dynamisch generiert,
ebenso wie die Hyperlinks zu Seiten mit weiteren Ergebnissen oder Ergebnis-Details.
Zur Überwindung dieser Probleme ist ein auf jeden Anbieter individuell angepaßter Wandler
notwendig. Diese individuelle Anpassung ist über eine für jeden Anbieter individuelle
Quellenbeschreibung realisiert, so daß der Anbieteragent selbst nicht angepaßt werden muß.
Vielmehr wird er durch die Quellenbeschreibung in die Lage versetzt, Suchanfragen über ein
Formular des darin beschriebenen Anbieters zu stellen und anschließend die Ergebnisse der
28

Suche zu lesen und im UniCats-i-internen Format zurückzuliefern. Abbildung 3.5 zeigt die
Struktur einer solchen Quellenbeschreibung, die komplette Form ist aus Anhang A ersichtlich.
...
...
...
...
...
Abbildung 3.5: Struktur einer Quellenbeschreibung
Wie aus der Abbildung bereits ersichtlich ist, besteht eine Quellenbeschreibung aus fünf
Hauptteilen:
• Der Metadaten-Teil () enthält allgemeine Informationen über den
beschriebenen Anbieter: Den Namen des Anbieters in Form der URL seines Internet-
Auftritts, das Erstellungsdatum der Quellenbeschreibung, die Angabe, ob die Suche
bei diesem Anbieter kostenpflichtig ist, sowie eine Liste der Informationen, die über
bei diesem Anbieter gefundene Literatur verfügbaren sind.
• Der Suchkosten-Teil () gibt bei kostenpflichtigen Anbietern die
Kosten für eine Suche und für die Bereitstellung der Ergebnisse an. Bei nicht
kostenpflichtigen Anbietern ist er leer.
• Der Suchdaten-Teil () beschreibt die Umsetzung einer Anfrage im
UniCats-i-internen Format auf ein bestimmtes Suchformular des Anbieters,
insbesondere die Belegung der Variablen des Formulars mit den Suchwerten und
weiteren, teilweise im Formular selbst gegebenen Daten.
• Der Einzelergebnis-Teil () enthält die Daten, die notwendig
sind, um Informationen über das Suchergebnis aus der Ergebnisseite zu extrahieren,
sofern die Suche nur einen Treffer ergab. Diese spezielle Betrachtung ist notwendig,
da sich eine solche Ergebnisseite bei vielen Anbietern von der einer Suche mit
mehreren Treffern unterscheidet.
• Der Ergebnislisten-Teil () enthält die Daten, die notwendig sind,
um Informationen über die Suchergebnisse aus der Ergebnisseite einer Suche zu
extrahieren, sofern die Suche mehrere Treffer ergab. Dies ist der als allgemein
angenommene Fall. Lediglich bei Versagen der Daten dieses Teils greift der
Anbieteragent auf den Einzelergebnis-Teil zurück.
Die Daten für das Auslesen der Informationen über die Suchergebnisse aus den
Ergebnisseiten liegen in Form von Pfadausdrücken vor, die die einzelnen Teilinformationen
im HTML-Baum der Ergebnisseite adressieren. Auch die Hyperlinks zu Seiten mit weiteren
Ergebnissen oder Ergebnis-Details sind durch Pfadausdrücke adressiert. Dies ermöglicht ein
dynamisches Auslesen der verlinkten URLs aus dem HTML-Baum der Suchergebnisseite,
wodurch das Problem dynamisch generierter Hyperlinks gelöst wird.
29

3.3 Die Rolle des Generatoragenten (GA)
Der Generatoragent hat innerhalb des UniCats-i-Systems die Aufgabe, die korrekte Funktion
der Anbieter-Anbindung durch die Anbieteragenten zu sichern. So lange diese gegeben ist,
besteht für ihn kein Grund, aktiv zu werden. Fällt aber die Anbindung eines Anbieters aus, so
ist er in der Lage, diese durch die Generierung einer neuen Quellenbeschreibung
wiederherzustellen.
Ein solcher Ausfall der Anbindung führt zum einen zur Benachteiligung des betroffenen
Anbieters gegenüber seinen Konkurrenten, zum anderen zu einer unvollständigen Information
des Kunden. Es können mehrere Faktoren dafür verantwortlich sein:
• Das Ausführen von Suchanfragen funktioniert nicht mehr. Dies kann dann auftreten,
wenn das im Suchdaten-Teil der Quellenbeschreibung beschriebene Suchformular
nicht mehr existiert oder wenn es derart verändert wurde, daß ihm die Beschreibung
nicht mehr entspricht.
• Die Ergebnisse der Suche können nicht mehr gelesen werden. Dies kann auftreten,
wenn die Struktur der Suchergebnisseiten geändert wurde, so daß die in
Einzelergebnis- und Ergebnislisten-Teil der Quellenbeschreibung angegebenen
Pfadausdrücke im HTML-Baum der Suchergebnisseite entweder ins Leere oder nicht
zu den gewünschten Informationen führen. Eine weitere mögliche Ursache ist, daß die
Suche aufgrund von Änderungen am Formular zwar noch funktioniert, aber keine oder
nicht die gewünschten Ergebnisse liefert.
• Der Internet-Server des Anbieters ist für den betroffenen Anbieteragenten
(vorübergehend) nicht erreichbar. Dafür kann ein Netzwerk-Problem auf Seiten des
Agenten oder auf Seiten des Anbieters verantwortlich sein.
Einen durch Netzwerk-Probleme bedingten Ausfall kann das UniCats-i-System ebenso wenig
selbst beheben wie jedes andere Software-System. Wohl aber ist der Generatoragent in der
Lage, die Probleme zu beheben, die aus anbieterseitigen Änderungen am benutzten
Suchformular oder an der Struktur der Ergebnis-Darstellung resultieren. Vom betroffenen
Anbieteragenten benachrichtigt untersucht er zu diesem Zweck die Internet-Seiten des
betroffenen Anbieters, generiert eine neue Quellenbeschreibung, mit der der Anbieteragent
wieder in die Lage versetzt wird, korrekt auf den betroffenen Anbieter zugreifen zu können,
und liefert diese an ihn zurück.
30

4. Verwandte Projekte und Arbeiten
In diesem Kapitel werden Projekte vorgestellt und untersucht, die sich mit der automatischen
Generierung von Wandlern beschäftigen. Insbesondere wird dabei auf die jeweils verfolgten
Ansätze und die angewandten Verfahren eingegangen. Diese werden auf die UniCats-ispezifischen
Anforderungen hin geprüft, um anschließend ihre Anwendbarkeit im Rahmen
der Realisierung eine vollautomatischen Wandler-Generators zu beurteilen.
4.1 W4F
Die World Wide Web Wrapper Factory (W4F) [W4F] ist aus zwei Gründen interessant für
diese Arbeit: Zum einen bietet dieses Projekt ein Konzept eines flexiblen Wandlers zur
Informationsextraktion, zum anderen stellt es Werkzeuge zur Generierung solcher Wandler
zur Verfügung. Nach einer kurzen Projektvorstellung werden diese Generierungswerkzeuge
anhand ihrer Nützlichkeit untersucht und bewertet.
4.1.1 Projektvorstellung
Die Architektur der W4F ist in drei Schichten unterteilt [Sahuguet 2000]:
• Retrieval Rules: Die Retrieval Rules beschreiben das Laden von Seiten aus dem
Internet. Diese werden anschließend in eine DOM-Struktur geparst (siehe auch Kapitel
2.7).
• Extraction Rules: Die Extraction Rules dienen der Informationsgewinnung aus
geladenen HTML-Dokumenten. In ihnen kommt die im Rahmen des W4F-Projektes
entwickelte HTML Extraction Language (HEL) zur Anwendung [Sahuguet 1998].
Diese ermöglicht eine genaue Adressierung der zu extrahierenden Informationen im
HTML-Baum. Die Extraktion geschieht dabei durch die Zuordnung eines HEL-
Pfadausdrucks zu einem Variablennamen. Die Ergebnisse der Pfadausdrücke werden
in geschachtelten Zeichenketten (Nested String List, kurz NSL) zurückgegeben, wobei
die Dimension der Ergebnistupel durch den Pfadausdruck festgelegt ist. Die
Pfadausdrücke unterstützen sowohl eine Hierarchie-basierte als auch eine
Dokumentfluß-basierte Navigation gemäß der Tiefensuche im Baum. Auf die durch
die Knotennavigation erreichten Knoten können anschließend spezielle
Knotenoperatoren angewendet werden, unter anderem die Textrückgabe bei den
PcData-Blattknoten, die Quellcoderückgabe bei normalen Knoten, die
Attributrückgabe bei attributbehafteten Knoten sowie weitere für die
Informationsgewinnung nützliche Operatoren.
• Mapping Rules: Die Mapping Rules beschreiben die Umsetzung der Nested String
List in ein Java-Objekt, das an die anfragende Komponente zurückgegeben wird. Eine
Ausgabe in XML ist nur über Umwege möglich.
Diese Architektur erlaubt allerdings keine Definition verschiedenartiger HTML-Dokumente
in einem Extraktionsvorgang. Folglich ist die Navigation über verschieden aufgebaute
HTML-Seiten nicht möglich, wodurch auch die Extraktion verteilter Information
ausgeschlossen wird. Die erzeugten Wandler sind somit als Seitenparser zu verstehen. Eine
Ausnahme bildet der Spezialfall, daß die Informationen auf mehreren Seiten gleichen
Aufbaus verteilt sind, was z.B. bei einer auf mehrere Seiten gleicher Struktur verteilten
Ergebnisliste zutrifft. Hier kann ein rekursives Vorgehen definiert werden.
4.1.2 Generierungshilfsmittel
Der Benutzer wird bei der Erstellung oben genannter Regeln von einer Reihe von
Werkzeugen unterstützt [Sahuguet 2000], deren Zusammenwirken aus Abbildung 4.1
31

ersichtlich ist. Es existiert jedoch kein Gesamt-Werkzeug, das alle diese Einzel-Werkzeuge
integriert und so die Möglichkeit bietet, einen kompletten Wandler zu generieren. Die Einzel-
Werkzeuge werden im folgenden kurz vorgestellt.
Abbildung 4.1: Schichten-Architektur der W4F
Zum Erzeugen der Retrieval Rules steht dem Benutzer ein Werkzeug zur Anzeige der
Formularseite und somit der zugehörigen Retrieval Rule in einem Web-Browser zur
Verfügung, der sogenannten Formular Wizzard (siehe Abbildung 4.2). Die Retrieval Rule
muß dabei nicht manuell entwickelt werden, wodurch für den Nutzer im Optimalfall generell
keine Kenntnisse über den Aufbau von Retrieval Rules notwendig sind. Es besteht jedoch
keine Möglichkeit, die gewonnene Retrieval Rule automatisch in einen generierten Wandler
zu übernehmen. Dies muß vom Benutzer manuell vorgenommen werden. Zudem beherrscht
dieses Werkzeug keine Frames, was den Einsatz auf Internet-Seiten ohne solche limitiert.
Abbildung 4.2: W4F Formular Wizzard
Das Entwickeln der Extraction Rules wird durch den Extraction Wizzard (siehe Abbildung
4.3) erleichtert, der die ursprünglich geladene HTML-Seite so modifiziert, daß bei Anzeige in
einem Browser bei Mauskontakt den HEL-Pfadausdruck der entsprechenden Stelle anzeigt.
Damit ist es jedem Benutzer ohne Kenntnis von HEL-Sprache und HTML-Tags möglich,
32

Extraction Rules zu entwickeln. Diese werden ihm gewohnten Browseransicht der HTML-
Seite angezeigt. Dieses Werkzeug ist jedoch auf den Internet Explorer beschränkt und
funktioniert zudem nicht bei allen HTML-Tags, z.B. nicht bei Knöpfen. Zudem werden einige
mächtige Operatoren der HEL-Sprache nicht genutzt, die zur Informationsgewinnung sehr
nützlich sind und oft zur Erstellung der gewünschten Extraction Rules benötigt werden.
Außerdem ist es nicht möglich, die erstellten Extraction Rules automatisch in einen zu
generierenden Wandler zu übernehmen. Dies muß der Benutzer wiederum manuell ausführen.
Abbildung 4.3: W4F Extraction Wizzard
Als letztes Werkzeug steht dem Benutzer der Construction Wizzard zur Verfügung, der die
Schichten der Architektur graphisch visualisiert. Er erlaubt die manuelle Eingabe der
Retrieval- und Extraction Rules und zeigt die Ausgabe der Ergebnisse graphisch in Form
eines Baumes an. Die anderen Werkzeuge sind jedoch nicht eingebunden, was die Erstellung
der Regeln wesentlich erschwert. Somit handelt es sich im eigentlichen Sinne nur um einen
Editor mit eingebauter graphischer Visualisierung der Ergebnisse.
Abbildung 4.4: Fertig gestellter W4F Wandler
33

4.1.3 Beurteilung
Die W4F bietet eine Reihe interessanter Ideen zur Gewinnung von Informationen aus dem
Internet, die sich jedoch leider auf einzelne Seiten bzw. der rekursiven Anwendung der
Informationsgewinnung auf gleichartig strukturierte Seiten beschränken. Zur Generierung
eines Wandlers werden dem Benutzer nützliche Werkzeuge zur Verfügung gestellt, ohne
diese jedoch zu einem Gesamt-Werkzeug zu integrieren.
Einige Ideen des W4F-Projektes kommen in dem im Rahmen dieser Arbeit entwickelten
Generierungs-Werkzeug zur Anwendung, nicht jedoch im vollautomatischen Wandler-
Generator.
4.2 XWRAP
Das eXtensible Wrapper Generation System (XWRAP) [XWRAP] des Oregon Graduate
Institute of Science and Technology ist ein XML-basiertes Software-System zur semiautomatischen
Generierung eines Wandlers für webbasierte Informationsquellen. Eine für
diese Arbeit interessante Eigenschaft dieses Projekts ist die vollständige Generierung eines
Wandlers durch ein einziges graphisches Werkzeug. Dieses Werkzeug wird nach einer kurzen
Projektvorstellung näher betrachtet.
4.2.1 Projektvorstellung
Die Generierung eines Wandler mit XWRAP erfolgt in mehrere aufeinander folgenden
Phasen:
• Phase 1 - Objekt- und Element-Extraktion: In dieser Phase wird eine Element-
Extraktions-Komponente generiert, die ein HTML- Dokument in ein XML-Dokument
konvertiert. Die Code-Erzeugung für diese Komponente läuft in folgenden Schritten
ab:
o Zuerst gibt der Benutzer die URL der Internet-Seite an, die er bearbeiten will.
o Anschließend kann der Benutzer über die geöffnete Seite navigieren, wie er es
aus einem normalen Browser gewohnt ist, um die Seite zu finden, für die
letztendlich ein Wandler erzeugt werden soll.
o Nach dem Klick auf den Generierungs-Knopf sucht das Werkzeug im
gewählten HTML-Dokument automatisch nach Objekten und Elementen und
teilt es dadurch auf. Dabei lernt das Werkzeug einige Objekt- und Element-
Extraktions-Heuristiken, die später den Kern der Extraktions-Komponente
bilden. Liefern diese automatisch generierten Extraktions-Heuristiken nicht die
gewünschten Ergebnisse, so kann der Benutzer sie mit Hilfe der Oberfläche
anpassen. Dies geschieht mittels Baumpfad-basierter regulärer Ausdrücke.
o Anschließend kann der Benutzer jedes extrahierte Datenelement benennen,
seinen Datentyp und auch die Gruppierung zu Objekten anpassen.
o Zum Schluß dieser Phase generiert das Werkzeug den Code eine Java-
Komponente, die als Eingabe eine URL erhält und die Extraktionsergebnisse
mit den vom Benutzer spezifizierten Benennungen als XML-Dokument
zurückliefert. Erfolgt der Zugang zum gewünschten HTML-Dokument über
die HTTP-Methode POST, muß in der Eingabe zusätzlich ein Anfrage-String
übergeben werden.
• Phase 2 - Suchformular-Extraktion: In dieser Phase kann der Benutzer die in Phase
1 generierte Komponente insofern erweitern, daß sie aus gegebenen Stichworten die
URL des gewünschten HTML-Dokumentes selbst erzeugen kann. Zu diesem Zweck
markiert er die dynamischen Teile der URL und des Anfrage-Strings und benennt sie
34

mit Stichworten. Das Werkzeug generiert anschließend den Code einer Java-
Komponente, die gegebene Stichworte in einen Anfrage-String umsetzt.
• Phase 3 - Code-Integration: In dieser letzten Phase werden die beiden generierten
Komponenten zu einer integriert. Das Ergebnis ist eine Komponente, die als Eingabe
Stichworte erhält, diese intern in eine URL übersetzt und die aus dem durch diese
adressierten HTML-Dokument extrahierten Daten in dem vom Benutzer spezifizierten
XML-Format zurückliefert. Zusätzlich hat der Benutzer die Möglichkeit, den
generierten Wandler über die XWRAP-Seite allgemein zugänglich und so auch für
andere benutzbar zu machen.
Es ist jedoch anzumerken, daß mit XWRAP nur ein Seitenparser vorliegt, der die Generierung
eines Wandler nur für strukturell gleiche HTML-Seiten erlaubt.
4.2.2 Generierungshilfsmittel
XWRAP stellt ein Werkzeug zur Verfügung, in dessen graphischer Benutzeroberfläche alle
zur Generierung eines Wandlers erforderlichen Hilfsmittel integriert sind (siehe Abbildung
4.5). Dabei wird dem Benutzer das geladene HTML-Dokument in einer Browserdarstellung
angezeigt, die ihm die aus dem Alltag vertraute Ansicht zur Verfügung stellt. Der Vorgang
der Generierung verfolgt den Ansatz Generation by Example. Hierbei wird die Extraktion der
gewünschten Information anhand einer Beispielextraktion durchgeführt (Abbildungen 4.6 und
4.7 zeigen zwei der beteiligten Ansichten) und daraufhin von dieser einzelnen Extraktion auf
die allgemeine Extraktion geschlossen. Anhand dieser durchgeführten Analyse wird
anschließend der Wrapper generiert. Dies macht die Generierung für den Benutzer einfach,
besonders dadurch, daß kein Spezialwissen erforderlich ist. Zudem existiert ein Test-
Werkzeug, mit dem der erzeugte Wandlers auf strukturell gleichartigen, inhaltlich jedoch
verschiedenen HTML-Dokumenten getestet werden kann.
Abbildung 4.5: Start-Ansicht des XWRAP-Werkzeuges
35

Abbildung 4.6: Überblick über extrahierte Elemente
Abbildung 4.7: Detail der Ansicht zur Benennung extrahierter Elemente
4.2.3 Beurteilung
Mit XWRAP liegt lediglich ein Seitenparser vor, wodurch keine Generierung eines Wandlers
zur Extraktion verteilter Information möglich ist. Allerdings sind einige interessante Konzepte
verwendet worden. Zum einen ist hier die graphische Benutzeroberfläche zu nennen, die die
vollständige Generierung eines Wandlers in einem Werkzeug vereint. Einige dieser Konzepte
36

werden dabei in den in dieser Diplomarbeit realisierten Generierungs-Werkzeug
übernommen. Zum anderen erweist sich das Vorgehen Generation by Example als intuitiv
und für den Benutzer als leicht erlernbar. Zudem läßt es sich mit Hilfe von geeigneten
Basisdaten automatisieren, was im Hinblick auf den im Rahmen dieser Arbeit realisierten
vollautomatischen Wandler-Generator interessant wird.
4.3 Lixto
Der Lixto Visual Wrapper [Baumgartner 2001, LIXTO] der Lixto Software GmbH (diese ging
als Spin-Off aus dem Lixto-Projekt der Technischen Universität Wien hervor) bietet ein
komplettes Werkzeug zu interaktiven Generierung von Wandlern. Für diese Arbeit ist Lixto
vor allem insofern interessant, daß es die Extraktion von über mehrere HTML-Dokumente
verteilten Informationen ermöglicht. Nach einer kurzen Projektvorstellung werden die
Generierungs- und Extraktionsmechanismen näher betrachtet.
4.3.1 Projektvorstellung
Das komplette Lixto-Paket besteht aus mehreren Teilen, deren Zusammenspiel Abbildung 4.8
veranschaulicht:
• Der Interactive Pattern Builder ist das Werkzeug, mit dem der Benutzer einen
Wandler generiert. Dies geschieht durch die Definition so genannter Pattern in
hierarchischer Reihenfolge, deren Namen gewöhnliche XML-Namen sind. Jedes
Pattern besteht aus einem oder mehreren Filtern, die jeweils bestimmte Informationen
in einem HTML-Dokument adressieren und durch zusätzliche Bedingungen
eingrenzbar sind. Der Benutzer verwendet dabei Beispielseiten, um gewünschte
Informationen aus dem HTML-Dokument zu isolieren. Die Patterns, genauer die
Filter, durch die sie definiert sind, werden anschließend automatisch in die Lixtointerne
Sprache Elog übersetzt. Diese besteht aus Baumpfad-basierten regulären
Ausdrücken, die einem Datenelement-Namen zugeordnet sind.
• Der Extractor stellt den Interpreter für die in Elog vorliegenden Wandler dar. Er
generiert aus HTML-Dokumenten entsprechend dem Elog-Wandler eine so genannte
Pattern Instance Base, eine Baum-förmige Datenstruktur, die die extrahierten Daten in
hierarchischer Ordnung enthält.
• Der XML-Translator überführt die Pattern Instance Base in eine vom Benutzer
definierte XML-Darstellung, die ebenfalls aus mehreren Hierarchie-Ebenen bestehen
kann.
Abbildung 4.8: Zusammenspiel der Lixto-Komponenten
37

4.3.2 Generierungshilfsmittel
Lixto stellt mit dem Interactive Pattern Builder ein Werkzeug zur Verfügung, das den
Benutzer durch alle Schritte der Generierung führt (siehe Abbildung 4.9). Dabei wird dem
Benutzer das geladene HTML-Dokument in einer Browserdarstellung angezeigt, die ihm die
vertraute Ansicht zur Verfügung stellt. Der Vorgang der Generierung erfolgt auch in Lixto
nach dem Prinzip Generation by Example. Abbildung 4.10 zeigt das Hauptmenu des
Interactive Pattern Builder, über das alle notwendigen Funktionen erreichbar sind. In
Abbildung 4.11 ist der mit Hilfe des Interactive Pattern Builder generierte Elog-Code eines
Lixto-Wandlers dargestellt.
Abbildung 4.9: Beispielseite im Lixto-Browser
Abbildung 4.10: Hauptmenu des Interactive Pattern Builder
Abbildung 4.11: Elog-Code eines Lixto-Wandlers
38

4.3.3 Beurteilung
Der Lixto Visual Wrapper ist für diese Arbeit in zweierlei Hinsicht interessant. Zum einen ist
er fähig, über mehrere HTML-Dokumente verteilte zusammengehörige Informationen zu
extrahieren, wobei diese in hierarchischer Ordnung ausgewertet werden. Zum anderen ist
seine Architektur so ausgelegt, daß die Hauptkomponente des letztendlichen Wandlers, der
Extractor, nicht auf jede Internet-Seite individuell angepaßt, sondern lediglich mit einer
individuell generierten Steuerdatei konfiguriert werden muß. Dies stellt eine wesentliche
Parallele zur Architektur des UniCats-i-Wandlers dar, der ebenfalls durch eine individuell
generierte Quellenbeschreibung konfiguriert wird und selbst nicht angepaßt werden muß.
4.4 ROADRUNNER
Das ROADRUNNER-Projekt der Universität Rom [Crescenzi 2001] bietet eine Ansatz zur
vollautomatischen Generierung von Wandlern. Einige für diese Arbeit interessante Aspekte
sollen hier näher betrachtet werden.
4.4.1 Projektvorstellung
Das ROADRUNNER-Projekt zielt darauf ab, Daten automatisch aus großen HTML-
Dokumenten zu extrahieren. Das Augenmerk ist dabei vor allem auf Internet-Seiten gerichtet,
die große Datenmengen in einer mittelmäßig komplexen Struktur darstellen. Dabei wird als
Eingabe lediglich eine Start-URL übergeben, die Ausgabe der extrahierten Daten erfolgt in
einer Datenbank-ähnlichen Formatierung.
Den im Rahmen dieses Projektes entwickelten Verfahren liegen einige Annahmen über
Internet-Seiten zugrunde, die große Datenmengen anzeigen:
• Die angezeigten Daten sind in einer Datenbank gespeichert, und die HTML-
Dokumente werden über Skripte dynamisch generiert.
• Die fraglichen Internet-Seiten enthalten mehrere verschiedene Klassen von HTML-
Dokumenten, wobei immer diejenigen HTML-Dokumente zu einer Klasse
zusammengefaßt werden, die durch dasselbe Skript generiert wurden.
Abbildung 4.12: Vergleich zweier HTML-Dokumente einer Klasse
39

Aufgrund dieser Annahmen betrachtet das ROADRUNNER-Projekt die dynamische
Generierung von HTML-Dokumenten aus in einer Datenbank gespeicherten Daten durch ein
Skript als eine Kodierung des Datenbank-Inhaltes in HTML. Folglich wird umgekehrt die
Extraktion der Daten und ihre Umformung in ein Datenbank-ähnliches Schema durch einen
Wandler als Dekodierung verstanden, quasi als Umkehrfunktion des Skriptes, durch das das
HTML-Dokument generiert wurde. Der ROADRUNNER -Wandler basiert dabei auf regulären
Ausdrücken bzw. regulären Grammatiken, die mit der Einschränkung versehen sind, keine
UNION-Operationen enthalten zu dürfen.
Diese Grammatiken werden, jeweils für eine Klasse von HTML-Dokumenten, anhand der
Betrachtung mehrerer Beispiel-Dokumente dieser Klasse generiert. Das Verfahren trägt den
Namen Align, Collapse, Match and Extract (ACME) und basiert auf dem Finden von
Gemeinsamkeiten und Unterschieden zwischen den Beispiel-Dokumenten (siehe Abbildung
4.12). Dabei werden die Gemeinsamkeiten als zugrunde liegende Struktur, die Unterschiede
als die zu extrahierenden Datenelemente interpretiert. Bei diesem vollautomatischen Prozeß
sind einige Aspekte zu beachten:
• Da das ACME-Verfahren auf dem Vergleich von HTML-Dokumenten derselben
Klasse basiert, müssen die von einer Internet-Seite kommenden HTML-Dokumente
zuerst in Klassen eingeteilt werden.
• Internet-Seiten können auch HTML-Dokumente enthalten, die in ihrer Klasse allein
stehen. Bei diesen kann die Vergleichstechnik nicht angewandt werden, so daß ein
spezielles Verfahren für sie benötigt wird.
• Da die Lokalisierung der relevanten Datenelemente in den HTML-Dokumenten
lediglich auf dem Finden von Unterschieden zwischen den Beispiel-Dokumenten
beruht, muß die Bedeutung der extrahierten Datenelemente später noch geklärt
werden.
Abbildung 4.13: Architektur des ROADRUNNER-Systems
40

Die Architektur des ROADRUNNER -Systems (siehe Abbildung 4.13) löst diese Probleme in
mehreren Schritten. Das System besteht aus folgenden Komponenten:
• Der Classifier nimmt die Einteilung der HTML-Dokumente in die Klassen vor. Er
enthält eine Crawler, der über die zu untersuchende Internet-Seite navigiert. Zudem
verfügt er über Heuristiken, die die Einteilung der durch den Crawler geladenen
HTML-Dokumente in Klassen steuern.
• Die Generierung von Wandlern für die HTML-Dokumente einer Klasse erfolgt im
Aligner, der das ACME-Verfahren implementiert.
• Einzel-Dokumente werden im Expander bearbeitet. Dieser wendet andere Verfahren
an als der Aligner, die ohne den Vergleich zweier HTML-Dokumente auskommen.
• Am Ende des Generierungsprozesses bestimmt der Labler die Bedeutung der
extrahierten Datenelemente.
4.4.2 Bewertung
Das ACME-Verfahren bietet einen interessanten Ansatz zur vollautomatischen Generierung
von Wandlern. Vor allem die Einteilung der Ergebnisdokumente in Klassen ist ein wichtiger
Aspekt, der zwar in anderen Wandler-Generatoren ebenfalls implizit enthalten ist, dort aber
nie explizit zum Ausdruck kommt oder gar umgesetzt wird. Allerdings läßt es einige Fragen
offen. Erstens bleibt ungeklärt, mithilfe welcher Daten der Crawler z.B. Suchanfragen
ausführen soll, um mehrere HTML-Dokumente einer Klasse zu erhalten. Gibt es keinerlei
Anhaltspunkte, welche Art von Daten auf der zu bearbeitenden Internet-Seite veröffentlicht
werden, so ist es kaum möglich, entsprechende Beispiel-Daten zur Verfügung zu stellen.
Zudem ist kein Verfahren zur Analyse von (Such-) Formularen vorhanden, wodurch das
Ausführen von Suchanfragen generell extrem erschwert wird. Zweitens ist die Extraktion von
über mehrere HTML-Dokumente verteilten zusammengehörigen Informationen durch das
ROADRUNNER -System nicht vorgesehen. Drittens basiert das Verfahren zur Feststellung der
Bedeutung extrahierter Datenelemente auf Heuristiken, wobei kein Verfahren zum Abfangen
dabei auftretender Fehler vorgesehen ist. Viertens steht kein Werkzeug zu Verfügung, mit
dem die generierten Wandler geprüft und im Fehlerfall korrigiert oder bei Versagen des
automatischen Verfahrens manuell oder semi-automatisch erzeugt werden können.
4.5 Wandler in digitalen Bibliotheken: Semi-Automatische Generierung
und Evaluationsstrategien
Der von Jürgen Schneider [Schneider 2001] für das UniCats-i-Projektes realisierte semiautomatischen
Wandler-Generator ist als direkter Vorgänger des im Rahmen dieser Arbeit
realisierten Generators zu sehen. Er bietet ein komplettes Werkzeug zu interaktiven
Generierung eines Wandlers. Nach einer kurzen Projektvorstellung wird dieses Werkzeug
näher beleuchtet.
4.5.1 Projektvorstellung
Die Generierung eines Wandlers, genauer gesagt einer Quellenbeschreibung für den UniCatsi-Wandler,
läuft in mehreren Schritten ab (siehe Abbildung 4.14):
• Nach der Eingabe eine URL wird das durch diese adressierte HTML-Dokument
geladen.
• Von dieser Startseite ausgehend navigiert der Benutzer über die Internet-Seite, um
Suchformulare zu finden. Nach der Auswahl eines Formulars wird dieses analysiert
und versetzt den Benutzer somit in die Lage, durch die Eingabe von Suchbegriffen
Beispiel-Suchen durchführen zu können.
41

• Im Ergebnis-Dokument der Suche markiert der Benutzer nun zu extrahierende
Datenelemente und führt durch einen Knopf die Extraktion durch. Des weiteren hat er
die Möglichkeit, Hyperlinks zu verfolgen und so zu weiteren HTML-Dokumenten mit
zusätzlichen Informationen zu den Treffern der durchgeführten Suche oder zu
weiteren Treffern zu gelangen.
Abbildung 4.14: Ablauf der Generierung
Die Generierung erfolgt nach dem Prinzip der Generation by Example, wobei der Benutzer
eine Beispiel-Suche ausführt. Die Analyse der Ergebnis-Dokumente dieser Suche wird
anschließend auf die Ergebnis-Dokumente einer beliebigen Suche über dasselbe Formular
verallgemeinert. Die Adressierung der Datenelemente und auch der Hyperlinks zu weiteren
HTML-Dokumenten mit zusätzlichen Informationen erfolgt über Pfade in der
Baumdarstellung der HTML-Dokumente.
Abbildung 4.15: Generierungs-Werkzeug
4.5.2 Generierungshilfsmittel
Die Generierung eines Wandlers, genauer gesagt einer Quellenbeschreibung für den UniCatsi-Wandler,
wird in diesem Projekt durch ein graphisches interaktives Werkzeug unterstützt,
42

das den Benutzer durch alle Generierungsschritte führt. Das gerade bearbeitete HTML-
Dokument wird dabei in mehreren Ansichten dargestellt:
• Die Baum-Ansicht zeigt die Baumdarstellung des aktuellen HTML-Dokumentes.
• Die Inhalts-Ansicht zeigt die in diesem Generierungsschritt extrahierbaren Inhalte des
aktuellen HTML-Dokumentes.
• Die Browser-Ansicht zeigt das aktuelle HTML-Dokument in der dem Benutzer
vertrauten Form an. Sie besitzt allerdings keine interaktiven Funktionen. Insbesondere
kann der Benutzer nicht in vertrauter Art und Weise über die Hyperlinks navigieren.
Zudem bietet das Werkzeug mehrere Sichten auf die in Generierung befindliche
Quellenbeschreibung und die Protokollausgaben der Hintergrund-Komponenten. Abbildung
4.15 zeigt die Oberfläche des Werkzeugs.
4.5.3 Beurteilung
Dieser Wandler-Generator ist durch die vertraute Browser-Ansicht leicht zu bedienen und
führt interaktiv durch den Generierungs-Prozeß. Das realisierte Prinzip der Generation by
Example ist für den Benutzer einfach und leicht verständlich. Die Extraktion über mehrere
HTML-Dokumente verteilter zusammengehöriger Informationen ist möglich. Die Mehrfach-
Darstellung eines HTML-Dokumentes in Baum-, Inhalts- und Browser-Ansicht findet sich in
weiterentwickelter Form in dem im Rahmen dieser Arbeit realisierten interaktiven Wandler-
Generator wieder.
Nachteilig ist zum einen die fehlende Möglichkeit zur Navigation über Hyperlinks in der dem
Benutzer vertrauten Browser-Ansicht zu vermerken. Zum anderen würde eine gleichzeitige
Anzeige aller HTML-Dokumente, auf denen zu extrahierende Datenelemente lokalisiert
wurden oder werden, den Überblick erleichtern. Zuletzt bleiben im Bereich des
Suchformulars noch zwei Frage offen. Zum einen, wie der Wandler eine UniCats-i-interne
Anfrage auf das beschriebene Suchformular übersetzen soll, da die generierte
Quellenbeschreibung keine Angaben über die Bedeutung der Eingabefelder für die Suche
enthält. Zum anderen ist der Umgang mit versteckten Eingaben ()
nicht geklärt. Diese sollten bei jeder Anfrage dynamisch geladen werden, da sie unter
anderem eventuell Sitzungs-Schlüssel enthalten können, ohne die eine Anfrage nicht
funktioniert.
4.6 Fazit
In den betrachteten Projekten finden sich viele für diese Arbeit interessante Ansätze.
Insbesondere das Prinzip der Generation by Example hat sich in vier der fünf Projekte
bewährt. Die Integration des gesamten Generierungs-Prozesses und dessen Unterstützung in
einem kompletten Werkzeug ist ebenfalls ein wichtiger Aspekt in drei der fünf betrachteten
Projekte. Bis auf ROADRUNNER beschäftigen sich jedoch alle ausschließlich mit der semiautomatischen
Generierung von Wandlern durch einen von einem oder mehreren Werkzeugen
unterstützten Benutzer, Ansätze zur vollständigen Automatisierung der umgesetzten
Verfahren fehlen völlig. Umgekehrt läßt der im Rahmen des ROADRUNNER-Projektes
realisierte Ansatz allerdings so viele Fragen offen (siehe Abschnitt 4.4.2), daß von einer
Verwendung desselben in den im Rahmen dieser Arbeit realisierten Komponenten und
Werkzeuge abgesehen werden sollte.
43

5. Entwurf
In diesem Kapitel werden Ansätze zur Generierung von Wandlern daraufhin untersucht,
inwiefern sie für eine vollständige Automatisierung in Frage kommen. Ein besonderes
Augenmerk liegt dabei auch auf den Möglichkeiten, die sie zur Analyse von Suchformularen
vorsehen. Anschließend wird auf Basis der angestellten Überlegungen ein vollautomatisches
Verfahren zur Generierung von Wandlern entworfen.
5.1 Automatisierungspotential der Generierungsverfahren
In Kapitel 4 finden sich unterschiedliche Ansätze zur Generierung von Wandlern. In der
Mehrzahl sind sie semi-automatisch und werden vom Benutzer mithilfe von Werkzeugen
durchgeführt, aber es findet sich auch eine bereits vollautomatisches Verfahren. Hier soll nun
untersucht werden, inwiefern sich diese Verfahren verändern und weiterentwickeln lassen, um
die Anforderungen zu erfüllen, die an den im Rahmen dieser Arbeit zu entwickelnden
Wandler-Generator gestellt sind (siehe auch Abschnitt 1.2):
• Analyse von Suchformularen
• Generierung regulärer Ausdrücke zum Heraustrennen einzelner Datenelemente aus
Strings
• vollständiger Automatismus
5.1.1 Generation by Example
Das Generierungs-Verfahren Generation by Example basiert auf einer vom Benutzer
durchgeführten Beispiel-Suche, wobei im Ergebnis-Dokument und, falls das Werkzeug dies
erlaubt, in von dort aus über Hyperlinks erreichbaren HTML-Dokumenten die zu
extrahierenden Datenelemente markiert werden. Die so gewonnenen Extraktionsregeln
werden anschließend auf alle Ergebnis-Dokumente von Suchanfragen über das verwendete
Formular und die in diesen verlinkten HTML-Dokumente verallgemeinert.
Ein möglicher Ansatz zur Automatisierung dieses Verfahrens wäre, die Suche nicht durch den
Benutzer durchführen zu lassen, sondern nach vorgegebenen Begriffen zu suchen, bei denen
der Inhalt des Ergebnis-Dokumentes – also die zu extrahierenden Datenelemente – bereits
bekannt ist. Sucht man z.B. nach der ISBN-Nummer eines Buches, so stehen die restlichen
Merkmale des Suchergebnisses (Autor, Titel, Verlag, etc) bereits fest. Diese bekannten
Datenelemente können anschließend im Ergebnis-Dokument der Suche und in über
Hyperlinks von diesem aus erreichbaren HTML-Dokumenten lokalisiert werden, ohne daß sie
durch den Benutzer markiert werden, z.B. durch eine Tiefensuche über die Werte der PcData-
Knoten in der Baumdarstellung der Ergebnis-Dokumente. Die Beispiel-Daten selbst könnten
etwa aus einer einem vollautomatischen Wandler-Generator zur Verfügung stehenden Datei
stammen.
5.1.2 ACME
Das ACME-Verfahren zur Generierung von Wandlern ist bereits voll automatisiert. Um den
Anforderungen an den Wandler-Generator gerecht zu werden, der im Rahmen dieser Arbeit
realisiert werden soll, müssen allerdings andere Fragen geklärt werden.
Erstens muß eine Möglichkeit geschaffen werden, dem Generator mehrere HTML-
Dokumente einer Klasse zur Analyse zur Verfügung zu stellen. Dies könnte wiederum durch
eine Suche nach gegebenen Beispiel-Daten erfolgen. Zweitens muß das Verfahren um eine
Technik zur Extraktion von über mehrere HTML-Dokumente verteilten zusammengehörigen
Informationen erweitert werden. Dabei ist auch zu beachten, wie das Seitenvergleichs-
Verfahren um das Auffinden von Hyperlinks zu HTML-Dokumenten mit diesen weiteren
45

Informationen erweitert werden kann. Drittens muß ein sicherer Weg gefunden werden, die
Bedeutung der extrahierten Datenelemente festzustellen. Dies könnte etwa wiederum durch
entsprechende Beispiel-Daten erfolgen.
5.1.3 Fazit
Die besondere Stärke des ACME-Verfahrens besteht gerade darin, keinerlei Kenntnis über
den Inhalt der zu bearbeitenden Internet-Seiten zu benötigen. Werden aber für den Bezug der
zur Generierung notwendigen HTML-Dokumente Beispiel-Daten benötigt, so müssen diese
sicherlich zumindest grob auf den Inhalt der zu bearbeitenden Internet-Seite abgestimmt sein.
Wären die Beispiel-Daten z.B. die Titel von Büchern, so würden sie für die Internet-Seite
eines Online-Buchvertriebes sicherlich ihren Zweck erfüllen. Bei der Internet-Seite einer
Online-Bibliothek für PDF-Dokumente wäre ein auf diese Beispiel-Daten gestützter Versuch
zur Generierung eines Wandlers dagegen mit großer Wahrscheinlichkeit zum Scheitern
verurteilt.
Damit büßt das ACME-Verfahren den Vorteil der Inhalts- und Daten-Unabhängigkeit ein, der
es bei all seiner Komplexität gegenüber der recht simplen Generation by Example
auszeichnet.
Letztlich erscheint die Automatisierung des Verfahrens Generation by Example auf Basis der
in Abschnitt 5.1.1 angestellten Überlegungen deutlich einfacher realisierbar zu sein als eine
Erweiterung des ACME-Verfahrens um die in Abschnitt 5.1.2 herausgestellten Punkte. Daher
wird dieser Ansatz im folgenden ausgearbeitet und später in einem vollautomatischen
Wandler-Generator umgesetzt.
5.2 Genereller Ablauf des Generierungsprozesses
Nachdem nun die Entscheidung für die Automatisierung des Ansatzes Generation by Example
mithilfe von Beispiel-Daten gefallen ist, soll der generelle Ablauf eines Generierungs-
Vorganges genauer betrachtet werden. Das hier entwickelte generelle Verfahren wird später
in seinen einzelnen Schritten genauer ausgearbeitet und in den Entwurf von Algorithmen zu
seiner Durchführung umgesetzt.
Der Vorgang der Generierung eines Wandlers soll als Eingabe lediglich die URL der zu
bearbeitenden Internet-Seite benötigen. Er kann in mehrere Schritte unterteilt werden (siehe
auch Abbildung 5.1):
• Zunächst wird das durch dies eingegebene URL adressierte HTML-Dokument geladen
(Startseite). Es dient als Einstiegspunkt für die komplette restliche Generierung.
• Ausgehend von dieser Startseite muß nun als erstes ein Suchformular gefunden
werden. Dieses ist für die Durchführung von Beispiel-Anfragen logischerweise
unabdingbar.
• Sobald ein Suchformular lokalisiert wurde, gilt es, dieses genauer zu analysieren.
Dabei ist zu klären, wie die Felder des Formulars auszufüllen sind und an welche URL
die Anfrage geschickt werden muß.
• Als nächstes erscheint es nun sinnvoll, eine Suche mit nur einem Treffer auszuführen
und das Ergebnis-Dokument sowie die auf diesem verlinkten HTML-Dokumente zu
analysieren. Dies ist notwendig, da sich Ergebnis-Dokumente von Suchen mit einem
Treffer oftmals von solchen von Suchen mit mehreren Treffern unterscheiden. So
zeigen Einzelergebnis-Dokumente oftmals Detailinformationen an, die von
Ergebnislisten-Dokumenten erst nach Verfolgen eines Hyperlinks erreichbar sind, also
dort ein verlinktes HTML-Dokument mit weiteren Informationen darstellen. Daher
können die aus der Analyse dieses Ergebnis-Dokumentes gewonnenen Daten im
nächsten Schritt mit großer Wahrscheinlichkeit wiederverwendet werden.
46

• Den Abschluß der Analyse-Schritte bildet eine möglichst allgemeine Beispiel-Suche
mit mehreren Treffern. Das Ergebnis-Dokument dieser Suche stellt den allgemeinen
Fall dar. Es wird, ebenso wie die von ihm aus über Hyperlinks erreichbaren HTML-
Dokumente, auf zu extrahierende Datenelemente hin analysiert. Wird dabei ein
verlinktes HTML-Dokument gefunden, das dem Ergebnis-Dokument der Suche mit
einem Treffer gleicht, so können die Analyse-Ergebnisse aus dieser Beispiel-Suche
wiederverwendet werden.
• Die in den vorhergehenden Generierungsschritten gesammelten Analyse-Daten
werden abschließend in eine Quellenbeschreibung für die bearbeitete Internet-Seite
umgesetzt. Dabei fließen die Beschreibung des Suchformulars sowie die Extraktions-
Regeln für die Ergebnis-Dokumente von Suchen mit einem und mit mehreren Treffern
ein.
Abbildung 5.1: Prozeß der Wandler-Generierung
In den folgenden Abschnitten werden nun die einzelnen Schritte der Generierung eines
Wandlers bzw. einer Quellenbeschreibung für einen durch eine solche konfigurierbaren
Wandler genauer betrachtet. Insbesondere wird dabei auf die Automatisierung dieser Schritte
und die dabei zu beachtenden Probleme eingegangen.
5.3 Finden und Auswahl eines Suchformulars
Zunächst wird das durch dies eingegebene URL adressierte HTML-Dokument geladen
(Startseite). Es dient als Einstiegspunkt für die komplette restliche Generierung. Ausgehend
von dieser Startseite muß nun als erstes ein Suchformular gefunden werden. Dieses ist für die
Durchführung von Beispiel-Anfragen logischerweise unabdingbar.
5.3.1 Formulare in HTML-Dokumenten
Formulare können in HTML-Dokumenten für unterschiedliche Zwecke verwendet werden:
• Für Einträge in Gästebüchern von Internet-Seiten
• Zum Eintrag in einem Mailing-Liste oder zum Bestellen von Newslettern
• Um Kunden eine Feedback-Möglichkeit zu bieten
• Bei Online-Mailprovidern zum Verfassen und Absenden von eMails
• Zur Anmeldung an einem Online-Dienst, wenn ein Login benötigt wird
• Bei Recherche-Systemen jeder Art – ob Suchmaschine oder Online-Anbieter
irgendwelcher Produkte – zur Eingabe von Suchkriterien und zum Durchführen der
Suche
Diese Liste erhebt keinen Anspruch auf Vollständigkeit, es sind sicherlich noch eine Vielzahl
anderer Einsatzmöglichkeiten für Formulare denkbar. Technisch dagegen unterscheiden sich
all diese Formulare nicht, im Quellcode eines HTML-Dokumentes sind sie alle nach
demselben Muster aufgebaut. Sie beginnen mit einem -Tag und enden mit einem
-Tag. Zwischen diesen beiden Tags enthalten sie, eventuell neben anderen HTML-
Elementen, in der Regel auch spezielle Formular-Elemente. Dies sind HTML-Elemente, die
47

nur innerhalb von Formularen eine Funktion haben, sieht man von Skript-Teilen eines
HTML-Dokumentes einmal ab. Tabelle 5.1 gibt einen Überblick über die Formular-Elemente.
Repräsentiert ein einzeiliges Textfeld. Das Attribut NAME
definiert den Attributnamen, VALUE definiert einen
Vorgabewert.
Identisch mit dem einzeiligen Textfeld, jedoch wird auf
dem Bildschirm die Eingabe nur als Folge von Sternchen
dargestellt. Die Eingabe wird jedoch weiterhin als Klartext
zum Server übertragen.
Steht für einen markierbaren Kasten. Das Attribut NAME
repräsentiert den Attributnamen, wobei erlaubt ist,
mehreren Auswahlkästen den gleichen Namen zu geben
und somit eine Mehrfachauswahl zuzulassen. Mit dem
Attribut VALUE kann der Wert angegeben werden, der bei
gesetzter Markierung übertragen wird. Das Attribut
CHECKED legt die Voreinstellung auf markiert.
Identisch mit TYPE="RADIO", erlaubt jedoch bei
mehreren Auswahlmöglichkeiten mit gleichem Namen nur
eine einzige Auswahl aus den zur Verfügung stehenden
Möglichkeiten.
Definiert einen Parameter mitsamt einer Belegung, auf
den der Benutzer keinen Einfluß hat. Mit den Attributen
NAME und VALUE wird der Parameter mitsamt dem Wert
definiert und übertragen.
Repräsentiert einen Knopf, der die Datenübertragung
auslöst, wenn er gedrückt wird. Das Attribut VALUE legt
den sichtbaren Namen des Knopfes fest.
Steht für einen Knopf, der sämtliche Formulareingaben
zurücksetzt. VALUE steht für die Aufschrift des Knopfes.
Verhält sich wie ein TYPE="SUBMIT", aber anstatt eines
Knopfes wird eine Graphik angezeigt, welche durch
Angabe der URL im Attribut SRC gegeben ist.
Repräsentiert ein mehrzeiliges Texteingabefeld. Die
Attribute ROWS und COLS definieren Aussehen und Größe.
Es muß mit dem Ende-Tag abgeschlossen
werden. Zwischen und steht
der Vorgabetext.
Erstellt ein Auswahlfeld, das eine Selektion unter
mehreren Vorgaben erlaubt, wobei durch das Attribut
NAME der Name angegeben wird. Es wird durch das Ende-
Tag abgeschlossen und enthält im Innern die
Auswahloptionen. Diese werden mit dem Tag
definiert, gefolgt von dem angezeigten Text der Option.
Das Attribut VALUE gibt den übertragenen Parameterwert
an, und SELECTED bestimmt, ob es sich um die Vorgabe
handelt. Der Parameter MULTIPLE erlaubt die
gleichzeitige Anwahl mehrerer Punkte.
Tabelle 5.1: Formular-Elemente in HTML
5.3.2 Finden von Suchformularen
Aufgrund der im letzten Abschnitt festgestellten Eigenschaften ist es wenig problematisch,
Formulare in HTML-Dokumenten ausfindig zu machen. Es genügt, den HTML-Baum des
48

Dokumentes nach den Knoten zu durchsuchen, die ein -Tag repräsentieren, die
Teilbäume unterhalb dieser Knoten repräsentieren dann den Inhalt des jeweiligen Formulars.
Allerdings genügt es zur Generierung eines Wandlers nicht, einfach irgendein Formular zu
finden, vielmehr muß eines für die Suche nach Literatur bei dem jeweils gerade bearbeiteten
Anbieter ausfindig gemacht werden. Daher wird ein Verfahren benötigt, das feststellt, ob es
sich bei einem Formular um ein solches zur Literatursuche handelt.
Bestimmte Formulare können aufgrund von Eigenschaften, die für Suchformulare allgemein
annehmbar sind, ohne weitere Tests ausgeschlossen werden:
• Suchformulare dienen nicht der Anmeldung an Online-Diensten, die einen Login
benötigen. Es existieren zwar durchaus Online-Anbieter von Literatur, bei denen eine
Suche nur nach einem Login möglich ist. Dieser erfolgt jedoch zuallermeist separat,
nicht über das Suchformular.
• Suchformulare bieten die Möglichkeit, die gesuchte Literatur durch die Eingabe von
Suchkriterien in Text-Feldern () zu charakterisieren.
• Das auf Anfragen von Suchformularen zurückerhaltene Ergebnis-Dokument ist von
den gemachten Eingaben abhängig. Daher können Formulare ausgeschlossen werden,
bei denen dies nicht der Fall ist.
Die ersten beiden Kriterien sind leicht zu überprüfen. Login- Formulare lassen sich daran
erkennen, daß sie ein Paßwort-Feld () enthalten, und das
Vorhandensein von Text-Feldern in einem Formular ist ebenfalls einfach zu prüfen.
Die Abhängigkeit des Ergebnis-Dokumentes von den gemachten Eingaben festzustellen ist
dagegen etwas komplizierter. Der Weg führt hier über das Ausfüllen des ersten Text-Feldes
mit mindestens zwei unterschiedlichen Test-Suchbegriffen, das jeweils anschließendes
Abschicken des Formulars und den Vergleich der jeweils erhaltenen Ergebnis-Dokumente.
Wählt man dabei den ersten Test-Suchbegriff so, daß eine Suche im Produkt-Katalog eines
beliebigen Online-Anbieters, im speziellen auch eines solchen von Literatur, mit Sicherheit
keinen Treffer liefert (beispielsweise „azbycxdwevfugthsirjqkplomn“), alle weiteren dagegen
so, daß eine Suche mit sehr großer Wahrscheinlichkeit mindestens einen Treffer liefert (z.B.
„Java“, „Physik“, „Goethe“ etc), so kann mit an Sicherheit grenzender Wahrscheinlichkeit
ausgeschlossen werden, daß es sich um ein Suchformular handelt, wenn alle weiteren
Ergebnis-Dokumente mit dem ersten übereinstimmen.
Als Vergleichskriterium ist in diesem Zusammenhang die Übereinstimmung der Baum-
Darstellungen der HTML-Dokumente sinnvoll, da gerade bei kommerziellen Anbietern viele
Dokumente dynamische Inhalte haben, die zufällig eingefügt werden und nicht von Eingaben
in einem Formular abhängen (z.B. Werbe-Banner). Zudem werden die Formular-Eingaben
teilweise in dem als Antwort erhaltenen HTML-Dokument wiederholt. Daher wäre bei einem
Vergleich der String-Repräsentationen das Risiko zu groß, in diesem Kontext gleiche Seiten
als ungleich einzustufen. Handelt es sich bei dem betrachteten Formular z.B. um ein Bestell-
Formular für einen Newsletter, so könnte das nach dem Abschicken des Formulars erhaltene
HTML-Dokument etwa eine Text-Passage wie „Herzlich willkommen bei unserem
kostenlosen Benachrichtigungsservice, Herr #NAME#. Sie werden ...“ enthalten, wobei
#NAME# der zuvor zufällig im Namensfeld eingegebene Beispiel-Suchbegriff wäre.
5.3.3 Auswahl eines Suchformulars
Bei vielen Anbietern ist direkt auf der Startseite eine Schnellsuche plaziert. In von dort aus
über Hyperlinks erreichbaren HTML-Dokumenten finden sich aber oftmals weitere
Suchformulare, die eine deutlich genauere Charakterisierung der gesuchten Literatur zulassen,
indem sie z.B. die Eingabe mehrerer Suchkriterien und deren logische Verknüpfung
untereinander erlauben. Es erscheint daher sinnvoll, nicht das erste gefundene Suchformular
49

zu verwenden, sondern erst einige Suchformulare zu sammeln und anschließend eines
auszuwählen.
Dies ist durch ein Verfolgen der Hyperlinks auf der Startseite und der Suche von Formularen
in den durch diese adressierten HTML-Dokumenten realisierbar, eventuell kann dieses
Verfahren sogar rekursiv bis zu einer bestimmten Tiefe angewandt werden. Dabei besteht
allerdings das Risiko, z.B. über Werbe-Banner oder eine Link-Liste zu den Internet-Seiten
anderer Anbieter zu gelangen. Da für das Generierungs-Verfahren nur Formulare interessant
sind, die der Suche bei dem gerade bearbeiteten Anbieter dienen, muß das Verlassen von
dessen Internet-Seite während der Formular-Suche vermieden werden. Dies ist durch eine
Überprüfung der Hyperlinks zu realisieren, die deren Verfolgung ausschließt, falls sie die
gerade bearbeitete Internet-Seite verlassen. Die Überprüfung erfolgt gegen die Basis-URL der
bearbeiteten Seite, und zwar insofern, als daß diese mindestens zur Hälfte zusammenhängend
in der URL des Hyperlinks enthalten sein muß. Eine Überprüfung gegen die Basis-URL
„www.buchladen.de“ würde beispielsweise das Verfolgen des Hyperlinks zu der URL
„suche.buchladen.de“ zulassen, das dessen zu „www.buchladen.de/suche“ ebenso, das dessen
zu „www.buch.de“ dagegen nicht.
Wurden nun aus mehreren HTML-Dokumenten eine Anzahl von Formularen isoliert und
solche ausgeschlossen, die nicht der Suche bei dem gerade bearbeiteten Anbieter dienen, so
muß unter den verbliebenen nun das Formular ausgefiltert werden, das für den weiteren
Generierungs-Prozeß und später auch durch den Wandler verwendet werden soll. Hier ist das
Ziel, das vielseitigste Formular zu wählen, so daß der Wandler die ihm übergebenen
Suchkriterien später möglichst genau auf eine Suchanfrage abbilden kann. Für die Beurteilung
der Vielseitigkeit eines Formulars können mehrere Kriterien herangezogen werden:
• Die Anzahl der Text-Felder () legt die Anzahl der in eine
Anfrage einbringbaren Suchkriterien fest (ein Kriterium je Text-Feld). Daher dient sie
als wichtigstes Kriterium für die Vielseitigkeit eines Suchformulars.
• In vielen Formularen kann die Bedeutung der Suchfelder, also z.B. auf welches
Datenelement der eingegebene Suchbegriff angewendet wird, über Auswahl-Felder
() beeinflußt werden. Dies erhöht die Vielseitigkeit der Suche insofern, als
daß mehr Datenelemente als Such-Kriterien zur Verfügung stehen. Daher dient die
Anzahl der Auswahl-Felder ebenfalls ein wichtiges Kriterium.
• Über versteckte Eingaben () steuern viele Formulare
Sitzungen und Server-seitige Heuristiken, die die Qualität der Suchergebnisse
verbessern. Dies trägt zwar nicht direkt zur Vielseitigkeit des Formulars bei, die
Anzahl der versteckten Eingaben kann aber dennoch als Kriterium genutzt werden.
• Das Verhalten eines Suchformulars läßt sich oft auch durch Einstellungen
beeinflussen, die über weitere Eingabe-Felder (, ) vorzunehmen sind. Auch diese tragen zu seiner Vielseitigkeit bei.
Insofern kann auch die Anzahl der Eingabefelder insgesamt als Kriterium
herangezogen werden.
Die Auswahl des weiterverwendeten Suchformulars erfolgt nun durch sequentielle
Anwendung dieser Kriterien. Dabei werden die in Frage kommenden Formulare so lange
miteinander verglichen, bis nur noch eines übrig ist, zuerst nach der Anzahl der Text-Felder,
herrscht hier Gleichheit, nach der Anzahl der Auswahl-Felder, usw. Das verbliebene
Suchformular wird dann für den restlichen Generierungs-Prozeß und später auch durch den
Wandler benutzt.
5.4 Analyse des Suchformulars
Ist nun die Entscheidung für ein bestimmtes der gefundenen Suchformulare gefallen, so
besteht der nächste Schritt darin, die Funktionsweise dieses Formulars möglichst genau zu
50

erforschen, so daß der Wandler später die Suchanfragen des UniCats-i-Systems möglichst
genau darauf umsetzen kann, um ein optimales Suchergebnis im Sinne der Anfrage zu
erzielen.
5.4.1 Genereller Ablauf
Neben den eigentlichen Suchfeldern (Textfeldern) sind in einem Suchformular mit großer
Wahrscheinlichkeit noch weitere Formular-Elemente (siehe Tabelle 5.1) zur Eingabe von
Daten vorhanden. Diese beeinflussen das Verhalten des Formulars und damit das Ergebnis der
Suche oft entscheidend. Insbesondere Auswahlfelder sind an dieser Stelle von Interesse, da
über solche oft zum einen die logische Verknüpfung der einzelnen Suchkriterien gesteuert
werden kann, zum anderen auch die Bedeutung der Suchfelder, d.h. auf welches
Datenelement der eingegebene Wert als Suchkriterium angewandt wird. Insgesamt sind
folgende Punkte zu klären:
• Zunächst ist zu klären, an welche URL ist die Suchanfrage zu schicken ist und über
welche HTTP-Methode (GET oder POST) sie versendet werden muß.
• Weiterhin ist wichtig, welches Suchfeld in den Standard-Einstellungen des Formulars
den eingegebenen Suchwert auf welches Datenelement anwendet. Dies ist
insbesondere dann so, wenn die Bedeutung der Suchfelder nicht durch Auswahlfelder
beeinflußbar ist.
• Sind Auswahlfelder vorhanden, so ist zunächst ihre Funktion innerhalb des
Suchformulars zu klären, d.h. ob sie die Bedeutung der Suchfelder beeinflussen, die
logische Verknüpfung der eingegebenen Suchkriterien, oder einen anderen
Suchparameter. In den ersten beiden Fällen ist weiterhin festzustellen, die Bedeutung
welches Suchfeldes bzw. die logische Verknüpfung welcher Suchkriterien ein
bestimmtes Auswahlfeld beeinflußt und welche Funktion die einzelnen in ihm
enthaltenen Optionen besitzen. Im letzten Fall ist die generelle Funktion des
Auswahlfeldes für die Suche zu klären.
• Zuletzt muß die Bedeutung der weiteren vorhandenen Formular-Elemente
herausgefunden werden.
Die erste Frage wird durch die Parameter ACTION (URL zum Abschicken der Anfrage) und
METHOD (HTTP-Methode zur Parameterübergabe) des -Tags beantwortet. Lediglich die
URL ist, falls relativ gegeben, durch die Basis-URL der gerade untersuchten Internet-Seite zu
ergänzen. Auf Möglichkeiten zur Umsetzung der anderen Punkte und dabei gegebenen
Einschränkungen soll in den nächsten Abschnitten eingegangen werden.
5.4.2 Klassifizierung der Suchfelder (Textfelder)
Um eine sinnvolle Suchanfrage mit brauchbarem Ergebnis über ein Suchformular stellen zu
können, ist es notwendig, die Bedeutung der einzelnen Suchfelder zu kennen, d.h. auf welches
Datenelement der jeweils eingegebene Wert als Suchkriterium angewandt wird. So wäre z.B.
das Suchergebnis mit Sicherheit nicht verwendbar im Sinne der Suchwünsche des Benutzers,
wenn der Name eines Autors als Kriterium in ein Suchfeld eingetragen wird, das für die
Suche über die Titel der verfügbaren Bücher vorgesehen ist.
Einem menschlichen Benutzer erschließt sich die Bedeutung der einzelnen Suchfelder in der
Regel durch eine geeignete Beschriftung des Formulars. Er erkennt die Zugehörigkeit eines
Stückes dargestellten Textes zu einem Suchfeld durch die räumliche Anordnung. Aus dem
Quellcode des HTML-Dokumentes und auch aus seiner Baum-Darstellung ist diese jedoch
nicht ohne weiteres zu erschließen, da zum einen die Beschriftungen kaum von anderem im
Formular dargestelltem Text (z.B. den Beschriftungen anderer Eingabefelder) zu
unterscheiden sind, zum zweiten die räumliche Anordnung von Formular zu Formular sehr
unterschiedlich ausfallen kann, so daß sich an dieser Stelle keine Regeln aufstellen lassen, und
51

zum dritten die gleiche räumliche Anordnung der Formularelemente in der Browser-
Darstellung durch verschiedene sehr unterschiedliche Strukturen im HTML-Dokument
erreicht werden kann. Es ist sogar denkbar, daß die Beschriftung gar nicht als Klartext im
Quellcode des HTML-Dokumentes vorliegt, sondern etwa durch innerhalb des Formulars
eingeblendete Bilder oder Grafiken dargestellt wird.
Eine weitere Möglichkeit ist, die einzelnen Suchfelder durch mehrfache Suchanfragen nach
geeigneten Suchwerten zu testen, deren Bedeutung bekannt ist. Die Überprüfung der
Suchergebnisse kann dann Anhaltspunkte für die Bedeutung des Suchfeldes liefern. In diesem
Zusammenhang ist zuallererst von Interesse, ob die Suche Treffer hatte oder nicht. Dies läßt
sich anhand des Ergebnis-Dokumentes über den Vergleich von HTML-Dokumenten (siehe
Abschnitt 2.8) feststellen, sofern das Aussehen eines solchen einer Suche ohne Treffer
bekannt ist. Dies kann erreicht werden, indem man vor der Suche nach Suchwerten mit
bekannter Bedeutung eine Suche nach einem Wert durchführt, für den die Suche im Produkt-
Katalog eines beliebigen Online-Anbieters, im speziellen auch eines solchen von Literatur,
mit Sicherheit keinen Treffer liefert (z.B. „azbycxdwevfugthsirjqkplomn“, siehe auch
Abschnitt 5.3.2). Das Ergebnis-Dokument dieser Suche wird im folgenden als Kein-Treffer-
Dokument bezeichnet.
Die Klassifizierung jedes Suchfeldes, also die Feststellung seiner Bedeutung, funktioniert nun
durch Suchanfragen nach Suchwerten mit bekannter Bedeutung. Gleicht das Ergebnis-
Dokument nicht dem Kein-Treffer-Dokument, so ist über das Suchfeld mit großer
Wahrscheinlichkeit eine Suche mit dem Datenelement als Kriterium möglich, das der
Bedeutung des verwendeten Suchwertes entspricht. Ergeben sich auf diese Weise mehrere als
Kriterium benutzbare Datenelemente, handelt es sich mit großer Wahrscheinlichkeit um ein
Freitext-Feld. Bei diesem Verfahren zur Klassifizierung gibt es allerdings noch einige Punkte
zu beachten, die die Qualität des Ergebnisses entscheidend beeinflussen können.
• So ist etwa eine einzige Test-Suche je bekannte Bedeutung / Datenelement nicht
ausreichend, um ein aussagekräftiges Ergebnis zu erzielen. Es steht dann nicht fest, ob
nur dieser bestimmte Test-Suchwert keine Treffer liefert, oder das durch ihn
repräsentierte Datenelement über das Suchfeld generell nicht als Suchkriterium
angewendet werden kann. Folglich sind je Datenelement mehrere Test-Anfragen
notwendig. Die Anzahl der Erfolgreichen Test-Anfragen je Datenelement werden
anschließend ausgewertet, und die Bedeutung des Suchfeldes wird als das
Datenelement klassifiziert, zu dem die meisten Test-Anfragen Treffer geliefert haben.
• Um eine Verzerrung der Klassifizierung zu vermeiden, sollten die gewählten Test-
Suchwerte zudem jeweils zusammenhängende Gruppen bilden, wobei zu jedem
Datenelement in jeder Gruppe ein Test-Suchwert vorhanden ist. Dies ist z.B. zu
erreichen, indem man jeweils die zu einem bestimmten Buch gehörigen
Datenelemente (Titel, Autor, Verlag, ISBN-Nummer, Erscheinungsjahr, etc)
verwendet. Andernfalls könnte das Ergebnis dadurch verfälscht werden, daß sich zu
einem stark selektiven Datenelement (z.B. der ISBN-Nummer) zu 80% der Test-
Suchwerte ein Treffer im Katalog des untersuchten Anbieters befindet, zu einem
anderen (z.B. dem Titel) aber nur zu 30% der Test-Suchwerte. Dies kann im
schlimmsten Fall zur Einstufung eines Freitext-Suchfeldes zu einem bestimmten
Datenelement hin führen.
• Zuletzt ist noch zu beachten, daß Test-Anfragen Treffer liefern können, obwohl das
durch den verwendeten Test-Suchwert repräsentierte Datenelement über das Suchfeld
eigentlich nicht als Kriterium angewandt werden kann. Dies tritt dann ein, wenn der
Test-Suchwert im Wert eines Datenelementes enthalten ist, das über das Suchfeld als
Kriterium angewandt werden kann. So kann etwa das Erscheinungsjahr eines Buches
sehr wohl im Titel eines anderen enthalten sein, oder der Verlag trägt einen Namen,
der auch der Name eines Autors ist. Um diese der Natur der Datenelemente
52

innewohnende Problematik zu umgehen, muß die Wahrscheinlichkeit dieser
eingebetteten Treffer bei der Auswertung der Anzahl der Test-Anfragen mit Treffern
je Datenelement berücksichtigt werden. Dies geschieht durch Ignorieren der Test-
Anfragen mit Treffern für das Datenelement mit höherer Wahrscheinlichkeit von
eingebetteten Treffern. So wird z.B. ein Suchfeld mit Treffern bei Test-Anfragen nach
Test-Suchwerten für die Datenelemente Titel und Erscheinungsjahr so klassifiziert, als
ob es nur für die Test-Suchwerte für Titel Treffer geliefert hätte, da ein
Erscheinungsjahr (z.B. „2003“) deutlich wahrscheinlicher in einem Buchtitel
(beispielsweise „Fischer Weltalmanach 2003“) enthalten ist als umgekehrt. Der
umgekehrte Fall ist bei entsprechender Wahl der Test-Suchwerte annähernd
auszuschließen. Allerdings ist bei der Auswahl der Test-Suchwerte zu beachten, daß
für mindestens zwei der durch sie repräsentierten Datenelemente nicht von
eingebetteten Treffern auszugehen sein darf. Andernfalls würden alle Suchen mit
Treffern auf einem Freitext-Feld als eingebettete Treffer eingestuft, bis auf die nach
Test-Suchbegriffen, die das eine Datenelement mit der geringsten Wahrscheinlichkeit
für eingebettete Treffer repräsentieren. Damit würden Freitext-Felder zwangsläufig
immer so klassifiziert, als würden sie nur dieses eine Datenelement als Suchkriterium
anwenden.
Die Auswertung der Anzahl der Test-Anfragen mit Treffern je Datenelement läuft nach
folgenden Kriterien:
• Die Test-Anfragen mit Treffern nach Test-Suchwerten für ein Datenelement werden
ignoriert, sofern die Anzahl der Test-Anfragen mit Treffern nach Test-Suchwerten für
ein anderes Datenelement mindestens doppelt so groß ist.
• Des weiteren werden Test-Anfragen mit Treffern nach Test-Suchwerten für
Datenelemente ignoriert, deren Wahrscheinlichkeit für eingebettete Treffer in einem
anderen Datenelement groß ist, für dessen Test-Suchwerte mindestens genauso viele
Test-Anfragen Treffer geliefert haben.
Ist nach dieser Eliminierung unter den Datenelementen, für die die Test-Anfrage nach
mindestens einem ihrer Test-Suchwerte Treffer geliefert hat, nur noch ein Datenelement
übrig, so wird das Suchfeld so klassifiziert, daß es der Anwendung dieses Datenelementes als
Kriterium dient. Ist mehr als ein Datenelement übrig, wird es als Freitext-Feld klassifiziert.
5.4.3 Klassifizierung der Auswahlfelder
Auswahlfelder liefern of einen großen Beitrag zur Vielseitigkeit eines Suchformulars. Sie
dienen oft zur Festlegung des Datenelementes, auf das der in einem Suchfeld eingegebene
Suchwert als Kriterium angewandt wird. Zudem werden sie zur logischen Verknüpfung der in
den einzelnen Suchfeldern eingegebenen Kriterien genutzt. Des weiteren können sie auch in
anderer Weise zur Steuerung eines Suchformulars verwendet werden. Bei der Analyse der
Auswahlfelder sind folgende Punkte von Interesse:
• Zunächst ist zu klären, in welcher Weise ein Auswahlfeld das Verhalten des
Suchformulars beeinflußt, also ob es das von einem Suchfeld als Kriterium
angewandte Datenelement (Element-Auswahl), die logische Verknüpfung von
Suchkriterien (Verknüpfungs-Auswahl) oder etwas anderes (Allgemeine Auswahl)
beeinflußt.
• Dann muß in den ersten beiden Fällen festgestellt werden, die von welchem Suchfeld
als Kriterium angewandte Datenelement bzw. die logische Verknüpfung der über
welche Suchfelder eingegebenen Suchkriterien das Auswahlfeld steuert. Im letzten
Fall muß herausgefunden werden, inwiefern es das Verhalten des Suchformulars
überhaupt steuert.
53

• Zuletzt ist die Bedeutung der einzelnen im Auswahlfeld enthaltenen Optionen zu
klären.
Der erste Punkt läßt sich am besten nach der Klärung des letzten beurteilen, da Auswahlfelder
in vielen Formularen ohne jede Beschriftung dastehen und ihre Bedeutung sich dem Benutzer
allein durch die darin zur Auswahl stehenden Optionen erklärt. Die enthaltenen Optionen
bieten im Falle einer automatischen Analyse zudem den Vorteil, im Quellcode des HTML-
Dokumentes als Klartext (lediglich die HTML-spezifische Kodierung von Sonderzeichen ist
zu beachten) vorzuliegen und dem Auswahlfeld eindeutig zugeordnet zu sein. Auch die
Standard-Einstellung ist leicht zu ermitteln: Ist keine der Optionen eines Auswahlfeldes mit
dem Standardauswahl-Parameter SELECTED markiert, so ist standardmäßig die erste Option
ausgewählt. Somit sollte zunächst versucht werden, die Bedeutung der Optionen eines
Auswahlfeldes zu bestimmen, um dann von dieser auf die Bedeutung des Auswahlfeldes
selbst zu schließen.
Das primäre Ziel hierbei ist die Erkennung von Element- und Verknüpfungs-Auswahlen.
Diese tragen zum einen in hohem Maße dazu bei, System-interne Suchanfragen genau auf das
Suchformular umsetzen zu können, zum anderen entstammen die in ihnen enthaltenen
Optionen in der Regel einer recht kleinen Menge von Begriffen, die die für Literatur
relevanten Datenelemente (z.B. Titel, Autor) und die Konjunktionen zum Ausdruck logischer
Verknüpfungen (z.B. „und“, „oder“) umfaßt. Dies schafft die Möglichkeit, die Optionen
mithilfe von Heuristik-Daten zu identifizieren, die die UniCats-i-internen Bezeichner für
Datenelemente und logische Verknüpfungen den im Literatur-Umfeld dafür verwendeten
Begriffen zuordnet. Aufgrund der identifizierten Optionen läßt sich nun auch eine Aussage
darüber treffen, ob es sich um eine Element-, eine Verknüpfungs- oder eben um eine
allgemeine Auswahl handelt.
Allerdings ist dabei nicht auszuschließen, daß sich auch unter den Optionen einer allgemeinen
Auswahl ein Begriff befindet, der erkannt wird und damit zur Einstufung dieses
Auswahlfeldes als Element- oder Verknüpfungs-Auswahl führt. Um die Wahrscheinlichkeit
einer solchen Fehlerkennung zu reduzieren, kann nun zunächst festgelegt werden, daß der
Heuristik-Wert (z.B. „und“) die gesamte Option darstellen muß und es nicht genügt, wenn er
im Wert der Option enthalten ist. Dadurch wird etwa die Erkennung der Option „Spezial- und
Sonderangebote“ als Option für den UniCats-i-interen Verknüpfungs-Operator „and“ und
damit die Einstufung des sie enthaltenden Auswahlfeldes als Verknüpfungs-Auswahl
vermieden. Weiterhin kann die Durchsetzung folgender Annahmen helfen, die sich aus der
Betrachtung vieler Suchformulare mit Element- und Verknüpfungs-Auswahlen ergeben:
• Wenn Element-Auswahlen in einem Suchformular vorhanden sind, so ist für jedes
Suchfeld genau eine solche vorhanden. Dies bedeutet insbesondere, daß genau so viele
Element-Auswahlen wie Suchfelder Vorhanden sind.
• Wenn Verknüpfungs-Auswahlen in einem Suchformular vorhanden sind, so ist für
jedes Suchfeld genau eine solche vorhanden. Diese dient, je nach Position (vor oder
nach dem Suchfeld) zu dessen logischer Verknüpfung mit dem nachfolgenden oder
vorangehenden. Bei Verknüpfung zum vorangehenden Suchfeld ist eventuell das erste
ohne Verknüpfungs-Option, bei Verknüpfung zum nachfolgenden Suchfeld eventuell
das letzte. Dies bedeutet insbesondere, daß in einem Suchformular genauso gleich
viele Verknüpfungs-Optionen vorhanden sind wie Suchfelder oder genau eine
weniger.
Wurden insgesamt weniger Auswahlfelder als Element-Auswahlen eingestuft als Suchfelder
vorhanden sind, so kann aufgrund der ersten Annahme davon ausgegangen werden, daß diese
Einstufungen fehlerhaft waren und es sich um allgemeine Auswahlen handelt. Wurden
insgesamt weniger Auswahlfelder als Verknüpfungs-Auswahlen eingestuft als die Anzahl der
Suchfelder minus eins, so kann aufgrund der zweiten Annahme davon ausgegangen werden,
54

daß diese Einstufungen fehlerhaft waren und es sich um allgemeine Auswahlen handelt.
Wurden dagegen mehr Auswahlfelder als Element- oder Verknüpfungs-Auswahlen eingestuft
als nach obrigen Annahmen zulässig, so kann deren Anzahl per Ausschluß-Verfahren
reduziert werden, wodurch irrtümliches Erkennen von Auswahlfeldern als solche korrigiert
wird. Bei diesem Verfahren können mehrere Kriterien in Bezug auf die enthaltenen Optionen
angewandt werden:
• Es kann angenommen werden, daß in einer Element- oder Verknüpfungs-Auswahl
aufgrund der kleinen Menge von möglichen enthaltenen Optionen bei entsprechender
Auswahl der Heuristik-Daten entweder mindestens die Hälfte der enthaltenen
Optionen durch deren Anwendung erkannt wird oder sich mindestens die Hälfte der
vorhandenen Heuristik-Daten in den Optionen wiederfindet. Ist beides nicht der Fall,
so kann davon ausgegangen werden, daß es sich bei den erkannten Optionen um
Zufallstreffer handelt und die Auswahlfelder eigentlich Allgemeine Auswahlen sind.
• Die Beobachtung zeigt, daß die Element-Auswahlen in Bezug auf die jeweils
enthaltenen Optionen in der Regel übereinstimmen. Findet sich unter den als Element-
Auswahlen eingestuften Auswahlfeldern eine Gruppe von solchen, in denen dieselben
Optionen bei der Anwendung der Heuristik-Daten erkannt wurden, und enthält diese
Gruppe eine Anzahl von potentiellen Element-Auswahlen, die mit der Anzahl der
Suchfelder übereinstimmt, so kann daher davon ausgegangen werden, daß es sich
hierbei um die korrekt erkannten Element-Auswahlen handelt. Damit sind alle anderen
als Element-Auswahlen eingestuften Auswahlfelder fälschlicherweise so behandelt
worden und können als Allgemeine Auswahlen eingestuft werden.
• Dieselbe Beobachtung gilt mit derselben Schlußfolgerung auch für Verknüpfungs-
Auswahlen, allerdings mit der Erweiterung, daß die Anzahl derer in der Gruppe von
solchen, in denen dieselben Optionen bei der Anwendung der Heuristik-Daten erkannt
wurden, auch um eins geringer sein darf als die Anzahl der Suchfelder im Formular.
• Sind nach Überprüfung dieser drei Annahmen noch immer mehr Auswahlfelder als
Element- oder Verknüpfungs-Auswahlen eingestuft als nach Anzahl der vorhandenen
Suchfelder zulässig, so kann der Anteil der durch Anwendung der Heuristik-Daten
erkannten an den vorhandenen Optionen zum Ausschluß weiterer Auswahlfelder
genutzt werden. Auch der Anteil der in mehreren Auswahlfeldern erkannten an den
vorhandenen Optionen kann aufgrund der zweiten und dritten Annahme als Kriterium
genutzt werden. Ersteres Ausschluß-Verfahren ist insbesondere dann notwendig, wenn
das Formular nur ein Suchfeld enthält, letzteres ist bei Vorhandensein mehrerer
Suchfelder gut anwendbar. Die jeweils ausgeschlossenen Auswahlfelder werden als
Allgemeine Auswahlen eingestuft.
Nach der Klassifizierung der Auswahlfelder in Element-, Verknüpfungs- und allgemeine
Auswahlen müssen die der ersten beiden Gruppen zu den Suchfeldern des Formulars
zugeordnet werden. Dies wiederum ist durch Testanfragen möglich, indem ein Suchfeld mit
einem Test-Suchwert ausgefüllt wird und anschließend Test-Anfragen mit mehreren Optionen
einer Element-Auswahl durchgeführt werden. Alle anderen Auswahlfelder des Formulars
werden mit ihren Standard-Optionen belegt, egal zu welcher Gruppe sie gehören, um so
unerwünschte Effekte durch nicht ausgefüllte Felder zu vermeiden. Der Vergleich der
jeweiligen Ergebnis-Dokumente klärt dann die Beziehung der Element-Auswahl zum
verwendeten Suchfeld: Sind die Ergebnis-Dokumente alle gleich, hat die verwendete
Element-Auswahl wahrscheinlich keine Auswirkungen auf die Bedeutung des verwendeten
Suchfeldes, andernfalls hat sie eine Bedeutung. Auf diese Weise kann nach und nach eine Art
Abhängigkeitsmatrix für Element-Auswahlen einerseits und Suchfelder andererseits erstellt
werden, aus der dann die Zugehörigkeit der Element-Auswahlen zu den Suchfeldern
abgelesen werden kann. Dasselbe Verfahren kann auch für die Verknüpfungs-Auswahlen
55

angewandt werden, wobei hier immer zwei aufeinander folgende Suchfelder mit Test-
Suchwerten zu belegen sind.
Dieses Verfahren ist allerdings sehr aufwendig. Dem Benutzer erschließt sich die
Zugehörigkeit der Element- und Verknüpfungs-Auswahlen zu den Suchfeldern dagegen durch
deren räumliche Anordnung im Suchformular. Geht man nun davon aus, daß die Anordnung
zusammengehöriger Teile (je ein Suchfeld, eine Element- und eine Verknüpfungs-Auswahl)
zueinander jeweils gleich ist, eröffnet sich eine deutlich einfachere Möglichkeit: Sind
Gruppen von Tags in der Browser-Darstellug eines HTML-Dokumentes in
korrespondierenden Mustern angeordnet, so stehen die in den einzelnen Ausprägungen dieser
Muster dargestellten einzelnen Tags in der Baum-Darstellung des HTML-Dokumentes in
derselben Tiefensuch-Reihenfolge. Dies bedeutet in diesem speziellen Fall, daß die zu den
Element- und Verknüpfungs-Auswahlen korrespondierenden Knoten in der Baum-Darstellung
des das Formular enthaltenden HTML-Dokumentes in derselben Tiefensuch-Reihenfolge
stehen wie die zu den Suchfeldern korrespondierenden, zu denen sie gehören. Durch diese
Eigenschaft ist die Zuordnung deutlich einfacher und schneller zu vollziehen als durch das
Verfahren der Test-Suche. Für die korrekte Zuordnung der Verknüpfungs-Auswahlen ist
allerdings noch zu klären, ob sie das im zugehörigen Suchfeld eingegebene Suchkriterium
logisch mit dem im nächsten oder dem im vorhergehenden eingegebenen verknüpfen. Ein
Benutzer würde eine vor dem Suchfeld stehende Verknüpfungs-Auswahl als logische
Verknüpfung zum vorigen Suchfeld interpretieren, eine dahinter stehende als solche zum
nächsten. Dies kann als Anhaltspunkt genutzt werde. Steht ein Tag in der Browser-
Darstellung eines HTML-Dokumentes vor einem anderen, so liegt sein korrespondierende
Knoten in der Baum-Darstellung des Dokumentes in Tiefensuch-Reihenfolge vor dem des
anderen. Liegt nun also der zur ersten Verknüpfungs-Auswahl korrespondierende Knoten in
der Baum-Darstellung des das Formular enthaltenden HTML-Dokumentes vor dem des ersten
Suchfeldes, so stehen die Verknüpfungs-Auswahlen im Formular vor den Suchfeldern und
verbinden diese logisch mit dem jeweils vorhergehenden, andernfalls stehen sie dahinter und
verbinden diese logisch mit dem jeweils nächsten.
Durch die Zuordnung der Element-Auswahlen zu den Suchfeldern ergibt sich eine neue
Möglichkeit zur Klassifizierung der Suchfelder in den Standard-Einstellungen des Formulars:
Statt des aufwendigen Testsuch-Verfahrens, das in Abschnitt 5.4.2 entwickelt wurde, kann
nun einfach die standardmäßig ausgewählte Option der zu einem Suchfeld gehörenden
Element-Auswahl ausgelesen werden, sofern diese durch die Anwendung der Heuristik-Daten
erkannt wurde. Dafür ist es allerdings notwendig, die Reihenfolge der Arbeitsschritte insofern
zu verändern, als daß zuerst die Auswahl- und erst anschließend die Suchfelder klassifiziert
werden.
Zuletzt bleibt noch die weitere Behandlung der als allgemeine Auswahlen klassifizierten
Auswahlfelder zu klären. Deren mögliche Bedeutung kann jedoch so unterschiedlich
ausfallen, daß eine genaue Bestimmung durch oben entwickelte Verfahren auf Basis von
Heuristik-Daten quasi nicht möglich ist. Zudem können sie für die Umsetzung von UniCats-iinternen
Suchanfragen kaum genutzt werden, da ihre Funktion und ihr Vorhandensein über
die unterschiedlichen Anbieter derart variiert, daß dem UniCats-i-Benutzer, dessen Anfrage ja
an viele Anbieter gestellt werden können soll, kaum Optionen zur Verfügung gestellt werden
können, die ihre Möglichkeiten nutzen. Daher werden diese Auswahlfelder bei jeder
Suchanfrage jeweils mit ihrer standardmäßig ausgewählten Optionen belegt.
5.4.4 Behandlung der restlichen Eingabefelder
Nachdem die Bedeutung von Suchfeldern () und Auswahlfeldern
() geklärt ist, bleibt nun noch, die von Checkboxen (),
Radio-Knöpfen () und versteckten Eingaben () herauszufinden. Die Bedeutung von Knöpfen (,
56

und ) ist trivialerweise klar. Mehrzeilige
Textfelder ( ... ) treten in Suchformularen nur mit sehr geringer
Wahrscheinlichkeit auf und werden hier daher nicht näher betrachtet.
Versteckte Eingaben sind vom Benutzer nicht zu beeinflussen und sollten daher auch von
einer über das Formular suchenden Software-Komponente nicht verändert werden. Da sie
jedoch für die Funktion eines Formulars respektive für die des Skriptes, das Server-seitig die
eingegebenen Daten weiterverarbeitet, oft einen wichtige Rolle spielen, müssen sie
unverändert übertragen werden. Zudem werden sie vielfach dynamisch erzeugt (z.B.
Sitzungs-Schlüssel), wodurch es notwendig wird, vor jeder Suchanfrage das das Formular
enthaltende HTML-Dokument zu laden und sie auszulesen, um ihre Aktualität zu
gewährleisten.
Die Bedeutung von Checkboxen und Radio-Knöpfen erschließt sich dem Benutzer über die
Beschriftung des Formulars. Dadurch gilt für sie Ähnliches wie für nicht durch Element-
Auswahlen beschriftete Suchfeldern: Ihre Bedeutung ist nur durch extrem aufwendige
Verfahren zu bestimmen, zumal ihre genaue Funktion für die Suche im Gegensatz zu der der
Suchfelder extrem unterschiedlich sein kann. Eine Klassifizierung über die Beobachtung von
Veränderungen am Ergebnis-Dokument einer Suche ist somit quasi ausgeschlossen, da
keinerlei Anhaltspunkt besteht, welcher Art diese Veränderung sein könnte. Aus diesem
Grund werden diese Formular-Elemente so behandelt wie allgemeine Auswahlen: Sie werden
bei jeder Suchanfrage mit ihrer Standard-Einstellung belegt.
5.4.5 Durchführen einer Suche über das Formular
Nach der Analyse des gewählten Suchformulars steht für dieses eine sehr komplexe
Beschreibung mit einer Fülle verschiedener Einstellungsmöglichkeiten zur Verfügung.
Dadurch kann eine UniCats-i-interne Suchanfrage zum einen zwar sehr genau auf das
Formular übersetzt werden, zum anderen ist diese Übersetzung allerdings recht komplex.
Gerade wenn nicht jedes Datenelement über jedes Suchfeld als Kriterium genutzt werden
kann, ist es je nach Anfrage sogar sehr komplex, die einzelnen Suchbedingungen auf die
Suchfelder zu verteilen. Zudem sind nicht in jedem Formular alle Datenelemente als Kriterien
anwendbar. Daher muß immer auch entschieden werden, welche der in der UniCats-i-internen
Suchanfrage spezifizierten Kriterien über das Formular überhaupt anwendbar sind und
welchen dies nicht zutrifft. Diese müssen dann auf Freitext-Felder übersetzt werden, sofern
solche in genügender Anzahl verfügbar sind. Andenfalls bleibt nicht anderes übrig, als die
betroffenen Kriterien in der auf das Formular übersetzten Suchanfrage nicht zu
berücksichtigen. Dasselbe gilt, wenn die Anzahl der in der UniCats-i-internen Suchanfrage
spezifizierten Kriterien die der Suchfelder im Formular übersteigt. Zudem muß vor jedem
Stellen einer Suchanfrage das das Formular enthaltene HTML-Dokument geladen werden, um
eventuell vorhandene Versteckte Eingaben samt ihren Werten auszulesen, da diese dynamisch
sein können (z.B. Sitzungs-Schlüssel). Auch die URL zum Abschicken der Anfrage kann sich
von Mal zu Mal unterscheiden, wenn z.B. für jede Sitzung auf dem Server des Anbieters
dynamisch ein eigenes Verzeichnis angelegt wird, und muß daher für jede Anfrage neu
ausgelesen werden.
Das Stellen von Suchanfragen ist zwar genau wie das Lesen der Ergebnisse Aufgabe des
Wandlers, doch ist es auch für den weiteren Prozeß der Generierung notwendig, Suchanfragen
über das gewählte Formular stellen zu können. Daher wird eine separate Komponente
geschaffen, die die besagte Übersetzung vornimmt. Diese soll die Beschreibung des
Formulars laden und dadurch in die Lage versetzt werden, Suchanfragen von der UniCats-iinternen
Form auf das Formular zu überführen, ähnlich wie der Wandler durch das Laden der
Quellenbeschreibung zum Zugriff auf einen bestimmten Anbieter befähigt wird. Diese
Komponente soll später auch vom Wandler selbst zum Stellen von Suchanfragen an den durch
57

ihn repräsentierten Anbieter benutzt werden. Sie wird im folgenden als Anfrage-Generator
bezeichnet.
5.5 Generierung der Pfade für Suchen mit einem Treffer
Nach Abschluß der Analyse des Suchformulars ist der Generator nun in der Lage,
zielgerichtete Suchanfragen an die Internet-Seite des untersuchten Anbieters zu stellen. Dies
bedeutet insbesondere, daß nun das Prinzip der Generation by Example zur Untersuchung der
Ergebnis-Dokumente von Suchanfragen und von diesen aus über Hyperlinks erreichbare
HTML-Dokumente angewandt werden kann.
Zunächst werden die Ergebnis-Dokumente solcher Suchanfragen behandelt, die nur einen
einzigen Treffer liefern. Dies ist notwendig, da sich solche Ergebnis-Dokumente oftmals von
denen von Suchanfragen mit mehreren Treffern unterscheiden. So zeigen Einzelergebnis-
Dokumente oftmals Detailinformationen an, die von Ergebnislisten-Dokumenten erst nach
Verfolgen eines Hyperlinks erreichbar sind, also dort ein verlinktes HTML-Dokument mit
weiteren Informationen darstellen. Daher können die aus der Analyse dieses Ergebnis-
Dokumentes gewonnenen Daten bei der Generierung der Pfade für Suchen mit mehreren
Treffern mit großer Wahrscheinlichkeit wiederverwendet werden.
5.5.1 Genereller Ablauf
Die Generierung der Pfadausdrücke, die der Extraktion von Datenelementen aus dem
Ergebnis-Dokument einer Suchanfrage mit einem Treffer dienen, verläuft in mehreren
Schritten:
• Zunächst muß eine Suchanfrage erzeugt werden, die genau einen Treffer liefert, d.h.
zu deren Kriterien genau ein Buch existiert, das diese erfüllt.
• Anschließend wird diese Suchanfrage durch den Anfrage-Generator auf das
untersuchte Formular übersetzt und an die Internet-Seite des untersuchten Anbieters
gestellt.
• Nun muß festgestellt werden, ob die Suche erfolgreich war, d.h. ob sie den erwarteten
Treffer geliefert hat. Dies erfolgt durch den Vergleich des erhaltenen Ergebnis-
Dokumentes mit dem schon bei der Formular-Analyse eingesetzten Kein-Treffer-
Dokument. Sind diese beiden HTML-Dokumente verschieden, so hat die Suchanfrage
einen Treffer geliefert, d.h. das gesuchte Buch ist im Katalog des untersuchten
Anbieters enthalten und die Analyse kann fortgesetzt werden. Andernfalls muß eine
neue Suchanfrage nach einem anderen Buch gestellt werden.
• Nun können die das gesuchte Buch beschreibenden Datenelemente wie z.B. Titel und
Autor im Ergebnis-Dokument lokalisiert werden, um aus den gefundenen Positionen
(PcData-Knoten) anschließend Pfadausdrücke zu generieren, die die Extraktion dieser
Datenelemente aus dem Ergebnis-Dokument einer Suche bei dem untersuchten
Anbieter erlauben, sofern diese genau einen Treffer geliefert hat.
In den folgenden Abschnitten werden die einzelnen Schritte genau untersucht und Verfahren
zu ihrer Umsetzung entwickelt.
5.5.2 Generierung der Suchanfrage
Bei der Generierung der Suchanfrage ist es besonders wichtig, daß die Suche genau einen
Treffer liefert. Dies bedeutet im Literatur-Umfeld, daß die Anfrage so konkret sein muß, daß
nur eine bestimmte Ausgabe eines bestimmten Buches die angegebenen Kriterien erfüllt. Dies
ist dadurch zu erreichen, daß Datenelemente mit hoher Selektivität als Suchkriterien
verwendet werden, also beispielsweise ISBN-Nummer und Titel.
58

Optimal ist eine Suche mit einem für Literatur eindeutigen Schlüssel als Kriterien-
Kombination, wobei diese Eigenschaft nur der ISBN-Nummer zugeschrieben werden kann.
Die Kombination aus Titel, Autor und Erscheinungsjahr kommt ihr zwar recht nahe, doch ist
es gerade im Bereich wissenschaftlicher Literatur nicht unüblich, daß ein Buch noch im
selben Jahr übersetzt wird und auch in einer anderen Sprache erscheint. Sind beim
untersuchten Anbieter beide Versionen verfügbar, so liefert die Suche mehr als einen Treffer.
Welche Datenelemente als Kriterien zur Anwendung kommen können, unterscheidet sich
zudem von Anbieter zu Anbieter bzw. von Formular zu Formular. Es ist daher sinnvoll, alle
verfügbaren Datenelemente des als Beispiel verwendeten Buches mit einer ihrer Selektivität
entsprechenden Priorisierung als Suchkriterien anzugeben, wobei das selektivste am
wichtigsten eingestuft wird. Die Auswahl der Kriterien, die letztlich in der auf das Formular
übersetzen Suchanfrage berücksichtigten werden, nimmt der Anfrage-Generator gemäß der
als Kriterium verfügbaren Datenelemente und der Anzahl der möglichen Kriterien vor.
5.5.3 Generierung der Pfade
Durch den Vergleich des Ergebnis-Dokumentes mit dem Kein-Treffer-Dokument wird nun
festgestellt, ob die Suchanfrage nach dem als Beispiel gewählten Buch dieses als Treffer
geliefert hat oder nicht. Von ersterem kann ausgegangen werden, wenn die HTML-
Dokumente verschieden sind, letzteres ist an ihrer strukturellen Gleichheit zu erkennen und
tritt dann ein, wenn es nicht im Katalog des untersuchten Anbieters enthalten ist. In diesem
Fall muß ein anderes Buch als Beispiel herangezogen und eine neue Suchanfrage generiert,
übersetzt und gestellt werden.
Abbildung 5.2: Generierung der Pfade zu Datenelementen
Hat die Suche nun genau eine Treffer geliefert, so bedeutet dies, daß das Ergebnis-Dokument
Informationen enthält, die das als Beispiel gewählte Buch beschreiben. Insbesondere sind also
die Werte von Datenelementen wie etwa Titel und Autor einerseits bekannt, andererseits in
diesem HTML-Dokument enthalten und können daher per Suche über die PcData-Knoten in
der Baum-Darstellung des Ergebnis-Dokumentes lokalisiert werden. Nun kann die Kenntnis
59

der die Datenelemente enthaltenden PcData-Knoten dazu genutzt werden, um Pfadausdrücke
zu generieren, die diese Knoten adressieren, und diese den Datenelementen zuzuweisen.
Abbildung 5.2 verdeutlicht dieses Verfahren.
Wurden auf diese Weise alle bekannten und im Ergebnis-Dokument enthaltenen
Datenelemente lokalisiert und in sie adressierende Pfade umgesetzt, so besteht die nächste
Aufgabe darin, dasselbe Verfahren aus von diesem aus über Hyperlinks erreichbare HTML-
Dokumente anzuwenden und so weitere Datenelemente für die Extraktion verfügbar zu
machen. Dazu werden zunächst alle im Ergebnis-Dokument enthaltenen Hyperlinks gesucht
(Knoten, die ein -Tag repräsentieren) und anschließend die durch sie (den href-Parameter
der -Knoten) adressierten HTML-Dokumente geladen. Anschließend können sie, genau
wie schon das Ergebnis-Dokument, nach den für das Beispiel-Buch bekannten Werten der
Datenelemente durchsucht werden. Enthält ein Dokument Datenelemente, die im Ergebnis-
Dokument nicht enthalten sind, so ist es als Lieferant zusätzlicher Informationen einzustufen
und wird beibehalten, andernfalls braucht es nicht weiter beachtet zu werden und wird
gelöscht. Dieses Vorgehen kann nun rekursiv angewendet werden, um alle verfügbaren
Informationen ausfindig zu machen.
Wurden nun vom Ergebnis-Dokument über Hyperlinks direkt oder indirekt erreichbaren
HTML-Dokumentes mit weiteren Informationen gefunden, so ist als nächstes zu klären, wie
diese für die Extraktion zugänglich gemacht werden können. Die einfachste Möglichkeit wäre
die Speicherung der Hyperlink-URLs. Da diese aber oft dynamisch generiert werden und
somit von einem Ergebnis-Dokument zum anderen variieren können, führt dieses Vorgehen
zur Extraktion falscher Informationen oder dazu, daß das adressierte Dokument gar nicht
mehr existiert. Es ist daher sehr instabil und somit wenig zweckdienlich. Eine weitere
Möglichkeit besteht in der Speicherung der Pfade der Knoten, die die Hyperlinks in der
Baum-Darstellung der HTML-Dokumente repräsentieren. Dadurch kann die konkrete URL
bei jedem Extraktionsvorgang dynamisch ausgelesen werden und ist damit in jedem Fall
aktuell und korrekt. Erleichtert wird dies noch durch die Fähigkeit der verwendeten
Pfadausdrücke, Knoten-Parameter direkt zu adressieren.
Das Ergebnis dieses rekursiven Verfahrens aus Generierung von Pfaden und Verfolgung der
vorhandenen Hyperlinks ist eine Kaskade von HTML-Dokumenten, wobei jedes als eine
Informationsschicht oder kurz Schicht bezeichnet wird. Diese stellt eine Baumstruktur dar,
deren Wurzel das Ergebnis-Dokument ist. Die Vater-Kind-Beziehung entsteht dadurch, daß
als Vater-Dokument eines HTML-Dokumentes immer jenes angesehen wird, das den
Hyperlink enthält, der es adressiert.
Die Beschreibung einer Schicht enthält die aus dieser extrahierbaren Datenelemente sowie
deren Pfade. Der Pfad des den Hyperlink zu einer Schicht repräsentierenden Knotens in der
Baum-Darstellung der jeweiligen Vater-Schicht wird als Adresse der Schicht bezeichnet.
Diese wird in der Beschreibung der Kind-Schicht gespeichert, ist aber in der Vater-Schicht
auszuführen.
5.6 Generierung der Pfade für Suchen mit mehreren Treffern
Abschließend muß nun das Ergebnis-Dokument einer allgemeinen Suchanfrage mit einer
unbestimmten Anzahl von Treffern analysiert werden. Dieses stellt den allgemeinen Fall dar.
Es wird, ebenso wie die von ihm aus über Hyperlinks erreichbaren HTML-Dokumente, auf zu
extrahierende Datenelemente hin analysiert. Wird dabei ein verlinktes HTML-Dokument
gefunden, das dem Ergebnis-Dokument der Suchanfrage mit einem Treffer gleicht, so können
die Ergebnisse aus diesem Generierungsschritt wiederverwendet werden. Es gilt allerdings
noch zu beachten, daß das Ergebnis einer Suchanfrage mit vielen Treffern oft als Liste
angezeigt wird und daß diese Liste oft in bestimmte Intervalle (Teillisten) unterteilt ist, so daß
das Ergebnis-Dokument z.B. nur die ersten 30 Treffer der Suche enthält und die nächste
Teilliste über einen Hyperlink erreichbar ist.
60

5.6.1 Genereller Ablauf
Die Generierung der Pfadausdrücke, die der Extraktion von Datenelementen aus dem
Ergebnis-Dokument einer allgemeinen Suchanfrage mit einer unbestimmten Anzahl von
Treffern dienen, verläuft ebenfalls in mehreren Schritten:
• Zunächst muß eine Suchanfrage erzeugt werden, die eine große Anzahl von Treffern
liefert. Gleichzeitig ist aber darauf zu achten, daß die Treffermenge überschaubar
genug bleibt, um eine gewisse Anzahl der Treffer voraussagen zu können.
• Anschließend wird diese Suchanfrage durch den Anfrage-Generator auf das
untersuchte Formular übersetzt und an die Internet-Seite des untersuchten Anbieters
gestellt.
• Nun muß festgestellt werden, ob die Suche erfolgreich war, d.h. ob sie mehr als einen
Treffer geliefert hat. Dies erfolgt durch den Vergleich des erhaltenen Ergebnis-
Dokumentes mit dem Kein-Treffer-Dokument und dem Ergebnis-Dokument der
Suchanfrage mit einem Treffer. Ist das Ergebnis-Dokument von diesen beiden HTML-
Dokumente verschieden, so hat die Suchanfrage mehr als einen Treffer geliefert, d.h.
zu dem verwendeten Suchbegriff sind mehrere Bücher im Katalog des untersuchten
Anbieters enthalten und die Analyse kann fortgesetzt werden. Andernfalls muß eine
neue Suchanfrage mit einem anderen Suchbegriff gestellt werden.
• Nun können die Datenelemente wie etwa Titel und Autor im Ergebnis-Dokument
lokalisiert werden, die die für den verwendeten Suchbegriff als Treffer vermuteten
Bücher beschreibenden, um aus den gefundenen Positionen (PcData-Knoten)
anschließend Pfadausdrücke zu generieren, die die Extraktion dieser Datenelemente
aus dem Ergebnis-Dokument einer Suche bei dem untersuchten Anbieter erlauben,
sofern diese mehrere Treffer geliefert hat.
• Zuletzt müssen noch einige weitere Daten in Bezug auf die Ergebnis-Liste ermittelt
werden, die die allgemeine Struktur der Teillisten beschreiben: Die verallgemeinerte
Position des ersten und des letzten Treffers in der jeweiligen Teilliste, die Anzahl der
pro Teil-Liste angezeigten Treffer und der Hyperlink zu nächsten Teilliste.
In den folgenden Abschnitten werden die einzelnen Schritte genau untersucht und Verfahren
zu ihrer Umsetzung entwickelt.
5.6.2 Generierung der Suchanfrage
Bei der Generierung der Suchanfrage für mehrere Treffer muß gesichert werden, daß sie
einerseits eine gewisse Anzahl von Treffern liefert, diese aber andererseits nicht so groß ist,
daß keine genügend hohe Anzahl der Treffer mehr vorhergesagt werden kann. Dies ist
deshalb notwendig, um auf der einen Seite sicherzustellen, daß die Treffer mindestens den
ersten Teil (d.h. dem Ergebnis-Dokument) der oft mehrteiligen Ergebnisliste einer solchen
Suche füllen und damit der Hyperlink zum nächsten Teil der Liste bestimmt werden kann, auf
der anderen Seite aber im Ergebnis-Dokument genügend bekannte Informationen vorhanden
sind, die identifiziert werden können.
An dieser Stelle ist die Selektivität der einzelnen Datenelemente wenig hilfreich. So liefert
eine Suchanfrage, die die am wenigsten selektiven Datenelemente (z.B. Erscheinungsjahr,
Verlag) als Kriterium nutzt, in der Regel eine zu große Anzahl von Treffern, um noch
genügend viele vorhersagen zu können, zumal die jeweils bei einem konkreten Anbieter
vorhandenen Bücher je nach dessen Spezialisierung auf eine bestimmte Sparte von Literatur
sehr unterschiedlich sein können. Werden dagegen Datenelemente mit hoher Selektivität als
Kriterium herangezogen, so sind mit großer Wahrscheinlichkeit nicht genügend Treffer
vorhanden. Für diese Suchanfrage ist also ein spezieller Beispiel-Suchwert erforderlich, der
eine genügend große Anzahl von Treffern aus einem genügend überschaubaren Umfeld, d.h.
61

zu einem speziellen Thema liefert (z.B. „Java Enterprise“, „Theoretische Physik“). Dieser
Beispiel-Suchwert muß dann über ein Freitext-Feld gesucht werden, da ja Stichwörter oder
Kurzbeschreibungen Bücher als Kriterium dienen sollen, nicht konkrete Daten wie Titel,
Autor oder Verlag. Mit Kenntnis der aktuellen Standardwerke zu diesem Thema, die mit
großer Wahrscheinlichkeit bei jedem Anbieter verfügbar sind, besteht nun eine gute Chance,
eine genügend große Anzahl von Treffern identifizieren zu können. Die Übersetzung dieser
Anfrage auf das Formular kann wiederum vom Anfrage-Generator übernommen werden.
5.6.3 Generierung der Pfade
Durch den Vergleich des Ergebnis-Dokumentes mit dem Kein-Treffer-Dokument und dem
Ergebnis-Dokument der Suchanfrage mit einem Treffer wird nun festgestellt, ob die
Suchanfrage nach dem Beispiel-Suchwert mehrere Treffer geliefert hat oder nicht. Von
ersterem kann ausgegangen werden, wenn das Ergebnis-Dokument von beiden anderen
HTML-Dokumenten verschieden ist, letzteres ist an seiner strukturellen Gleichheit mit einem
der beiden zu erkennen und tritt dann ein, wenn zu dem gewählten Beispiel-Suchwert nicht
genügen Bücher im Katalog des untersuchten Anbieters enthalten sind. In diesem Fall muß
ein anderer Beispiel-Suchwert benutzt und eine neue Suchanfrage generiert, übersetzt und
gestellt werden.
Abbildung 5.3: Struktur einer Ergebnis-Liste
Hat die Suche aber mehrere Treffer geliefert, so bedeutet dies, daß das Ergebnis-Dokument
mit großer Wahrscheinlichkeit Informationen enthält, die einige der vorhergesehenen Treffer
beschreiben. Insbesondere sind also die Werte von Datenelementen wie Titel und Autor
einerseits für die vorhergesagten Treffer bekannt, andererseits mit großer Wahrscheinlichkeit
in diesem HTML-Dokument enthalten und können daher per Suche über die PcData-Knoten
in der Baum-Darstellung des Ergebnis-Dokumentes lokalisiert werden. Nun kann die
Kenntnis der die Datenelemente enthaltenden PcData-Knoten dazu genutzt werden, um
Pfadausdrücke zu generieren, die diese Knoten adressieren, und diese den Datenelementen
zuzuweisen. Dies geschieht analog zu Abschnitt 5.5.3, allerdings noch ohne das Verfolgen
62

von Hyperlinks und mit dem Unterschied, daß zu jedem Datenelement mehrere Pfade
existieren, nämlich zu jedem vorhergesagten Treffer, der tatsächlich im ersten Teil der
Ergebnis-Liste enthalten ist, je einer.
Dies ist nicht das Ziel der Generierung, denn diese soll pro Datenelement und Schicht einen
Pfad ergeben, aber eine wichtige Grundlage für den nächsten Schritt. Bei der Mehrzahl der
Anbieter werden die Treffer-Listen durch ein Skript dynamisch generiert, was insbesondere
bedeutet, daß die je Treffer angezeigten Informationen in das immer gleiche Struktur-Muster
(im folgenden Treffer-Struktur genannt) eingefügt werden und dadurch innerhalb desselben
alle gleich strukturiert sind. Anschließend werden die Ausprägungen der Treffer-Struktur,
also die Informationen zu je einem Treffer, in eine größere Rahmenstruktur eingefügt. Dies
führt dazu, daß alle Ausprägungen der Treffer-Struktur in der Baum-Darstellung des
Ergebnis-Dokumentes der Suchanfrage einen gemeinsamen Vater-Knoten haben. Dieser wird
als Listen-Kopfknoten bezeichnet, der Wurzelknoten einer Ausprägung der Treffer-Struktur
wird mit Treffer-Kopfknoten benannt. Abbildung 5.3 veranschaulicht diese Struktur.
Um nun nicht nur die Pfade zu den korrekt vorausgesagten Treffern generieren zu können,
sondern solche, die die Extraktion der Datenelemente aller in der Liste vorhandenen Treffer
erlauben, ist es notwendig, zunächst den Listen-Kopfknoten ausfindig zu machen, um bei der
Extraktion über dessen Kind-Knoten, die Treffer-Kopfknoten, iterieren und die
Datenelemente aus den einzelnen Ausprägungen der Treffer-Struktur extrahieren zu können.
Der Pfad des Listen-Kopfknotens ergibt sich nun durch die Bestimmung des längsten
gemeinsamen Pfades der Pfade für ein Datenelement, für das in mindestens zwei Treffern ein
Beispiel-Wert identifiziert wurde, so daß auch mindestens zwei Pfade existieren. Diese
unterscheiden sich nämlich genau in dem Schritt, der den Übergang vom Listen-Kopfknoten
auf den jeweiligen Treffer-Kopfknoten ausdrückt. Zuvor verlaufen sie gemeinsam bis zum
Listen-Kopfknoten, und auch anschließend verlaufen sie, dann innerhalb der jeweiligen
Ausprägung der Treffer-Struktur, analog. Der gemeinsame Pfad bis zum Listen-Kopfknoten
wird als Listen-Basispfad bezeichnet, der Pfad innerhalb der Treffer-Struktur ist der
eigentliche Pfad des Datenelementes in dieser Schicht. Abbildung 5.4 verdeutlicht diesen
Sachverhalt.
Nun muß noch herausgefunden werden, welche der Kindknoten des Listen-Kopfknotens
extrahierbare Daten enthalten. Dies muß nicht immer jeder seiner Kindknoten sein, sie
können bei jedem beliebigen Index größer oder gleich null beginnen sowohl
aufeinanderfolgend als auch in regelmäßigen Abständen größer eins angeordnet sein. Wohl
aber sind einige seiner Kindknoten bekannt, die extrahierbare Daten enthalten: Die Treffer-
Kopfknoten der identifizierten Treffer. Ihre Indizes geben erste Hinweise auf den Abstand der
Treffer-Kopfknoten (im folgenden Treffer-Abstand genannt): Er ist in jedem Fall der größte
gemeinsame Teiler der Indizes der Treffer-Kopfknoten der identifizierten Treffer oder ein
Teiler von diesem. Ergibt die Berechnung dieses ggT 1, so steht der Treffer-Abstand fest. Ist
er größer, so müssen er und alle seine Teile überprüft werden. Es ist sinnvoll, dies in
aufsteigender Reihenfolge durchzuführen, denn ist die Prüfung bei 1 bereits positiv, so
können alle weiteren entfallen. Eine Prüfung kann erfolgen, indem der Teilbaum unter dem
Treffer-Kopfknoten des ersten identifizierten Treffers (Baum der Treffer-Struktur) in
Schritten des gerade geprüften potentiellen Abstandes mit den Teilbäumen unter den anderen
Treffer-Kopfknoten verglichen wird, bis der Index des Treffer-Kopfknotens des letzten
identifizierten Treffers erreicht ist. Sind alle diese Teilbäume syntaktisch gleich, so ist der
Treffer-Abstand kleiner oder gleich dem gerade geprüften potentiellen Abstand, falls nicht,
wird der nächst größere potentielle Abstand geprüft.
63

Abbildung 5.4: Listen-Basispfad
Steht erst einmal der Abstand der Indizes aller Treffer-Kopfknoten fest, so läßt sich auch der
Index des ersten in der Liste und ihre Anzahl bestimmen. Wandert man vom Treffer-
Kopfknoten des ersten identifizierten Treffers in der Liste in Schritten des Treffer-Abstandes
nach oben (Index absteigend), so ist der Index des ersten Treffer-Kopfknotens in der Liste
der, für den letztmalig zum einen der Teilbaum unter ihm mit dem unter dem Treffer-
Kopfknoten des ersten identifizierten Treffers syntaktisch gleich, zum anderen der Index
größer null ist (dieser Index wird im folgenden Treffer-Anfang genannt). Wandert man
dagegen vom Treffer-Kopfknoten des letzten identifizierten Treffers in der Liste in Schritten
des Treffer-Abstandes nach unten (Index aufsteigend), so ist der Index des letzten Treffer-
Kopfknotens in der Liste der, für den letztmalig zum einen der Teilbaum unter ihm mit dem
unter dem Treffer-Kopfknoten des letzten identifizierten Treffers syntaktisch gleich, zum
anderen der Index kleiner der Anzahl der Kindknoten des Listen-Kopfknotens ist (dieser
Index wird im folgenden Treffer-Ende genannt). Die Treffer-Anzahl in der Liste berechnet
sich dann zu ((Treffer-Ende - Treffer-Anfang) / Treffer-Abstand) + 1.
Als nächstes gilt es, den Hyperlink zur nächsten Teilliste ausfindig zu machen. In der Regel
befindet sich dieser nicht innerhalb der Treffer der Suchanfrage, d.h. der ihn in der Baum-
Darstellung des Ergebnis-Dokumentes repräsentierende Knoten befindet sich nicht im
Teilbaum unterhalb des Listen-Kopfknotens. Des weiteren kann davon ausgegangen werden,
daß das die nächste Teil-Liste enthaltende HTML-Dokument zum Ergebnis-Dokument eine
hohe syntaktische Ähnlichkeit aufweist, da es ein vom gleichen Skript mit Inhalten befüllt
wurde, lediglich mit anderen Informationen. Die einfachste Möglichkeit zum Auffinden
dieses Hyperlinks ist also, alle Hyperlinks des Ergebnis-Dokumentes zu verfolgen, die sich
nicht im Teilbaum unter dem Listen-Kopfknoten befinden, und die erhaltenen HTML-
Dokumente mit dem Ergebnis-Dokument syntaktisch zu vergleichen. Das diesem syntaktisch
ähnlichste wird als dasjenige angenommen, das die nächste Teilliste enthält. Der Hyperlink
dorthin wird in Form des Pfades gespeichert, der den ihn in der Baum-Darstellung des
64

Ergebnis-Dokumentes repräsentierenden Knoten adressiert, aus denselben Gründen wie die
Hyperlinks zu Kind-Schichten.
Zuletzt müssen die über Hyperlinks erreichbaren HTML-Dokumente mit weiteren
Informationen untersucht werden. Diese sind für jeden der in der Teil-Liste aufgeführten
Treffer der Suchanfrage unterschiedlich, weshalb davon ausgegangen werden kann, daß sich
die diese Hyperlinks repräsentierenden Knoten für die einzelnen Treffer in den Teilbäumen
unterhalb der jeweiligen Treffer-Kopfknoten befinden. Daher werden die Hyperlinks in den
Teilbäumen unter den Treffer-Kopfknoten der identifizierten Treffer verfolgt, und es wird
jeweils durch rekursive Identifikation der Datenelemente und Verfolgung der Hyperlinks eine
Kaskade von Schichten erstellt. Diese Kaskaden werden anschließend verglichen und
zusammengeführt. In der Regel sind sie insofern gleich, daß jede dieselbe Abfolge von
Schichten und innerhalb dieser dieselben Datenelemente enthält. Falls Unterschiede bestehen,
werden diese in eine Vereinigungsmenge der in den Kaskaden enthaltenen Schichten und der
in den Schichten enthaltenen Datenelement-Pfade überführt, so daß kein Datenelement für die
Extraktion verloren geht. Wird dabei ein HTML-Dokument erreicht, das dem Ergebnis-
Dokument der Suchanfrage mit einem Treffer gleicht, so kann die dort generierte Kaskade
wiederverwendet werden.
5.7 Generierung regulärer Ausdrücke
Eine der Hauptanforderungen an diese Arbeit ist, Datenelemente mithilfe regulärer Ausdrücke
aus Strings extrahieren zu können. Die Form und Funktion dieser Ausdrücke wurde in
Abschnitt 2.9.2 vorgestellt. Nun wird noch ein Verfahren benötigt, um aus einem
Gesamtstring, der mehrere bekannte Werte von Datenelementen enthält, für jedes dieser
Datenelemente einen regulären Ausdruck zu generieren, der zur Extraktion des jeweiligen
Wertes auf einen beliebigen Gesamtstring angewendet werden kann, dessen Form dem
Beispiel-String gleicht.
5.7.1 Genereller Ablauf
Die Generierung regulärer Ausdrücke zur Extraktion von Datenelementen aus einem
Gesamtstring verläuft in mehreren Schritten:
• Zunächst muß die Struktur des Gesamtstrings herausgefunden werden, um von den
konkret enthaltenen Werten von Datenelementen zu abstrahieren. Dadurch wird einen
Extraktion der verbliebenen Teile des Gesamtstrings möglich, die nicht die
enthaltenen Datenelemente darstellen. Aus diesen werden die Grenzstrings erzeugt.
• Sind die Grenzstrings gefunden, so kann anschließend für jedes im Gesamtstring
identifizierte Datenelement ein regulärer Ausdruck nach 2.9.2 erzeugt werden, dessen
Anwendung auf einen String von der Form des Gesamtstrings das jeweilige
Datenelement extrahiert. Anschließend können die erzeugten Ausdrücke noch
optimiert werden, um eine schnelle und sichere Ausführung zu gewährleisten. Dabei
kann Wissen über das jeweilige Datenelement genutzt werden, zu dessen Extraktion
der Ausdruck dient.
In den folgenden Abschnitten werden die einzelnen Schritte genau untersucht und Verfahren
zu ihrer Umsetzung entwickelt.
5.7.2 Finden und Optimierung der Grenzstrings
Zur Extraktion der Datenelemente sind in erster Linie die Grenzstrings wichtig, die diese
voneinander trennen. Sie spiegeln quasi die Struktur des Gesamtstrings wider. Zu ihrer
Extraktion können zunächst die Werte aller erkannten Datenelemente im Gesamtstring durch
Tags für die Datenelemente selbst ersetzt werden. Bei Datenelementen fester Länge werden
diese durch ein führendes ! markiert. Folgendes Beispiel verdeutlicht diesen Vorgang:
65

Gesamtstring:
Java in a nutshell : a desktop quick reference ; [covers Java 1.4] /
David Flanagan. - 4. ed.. - Cambridge ; Köln : O'Reilly, 2002. - XXI,
969 S.; (engl.)
Erkannte Werte von Datenelementen:
- Titel: Java in a nutshell : a desktop quick reference ; [covers
Java 1.4]
- Autor: David Flanagan
- Verlag: Cambridge ; Köln : O'Reilly
- Erscheinungsjahr: 2002
Gesamtstring nach Ersetzung dieser Werte:
/ . - 4. ed.. - , . - XXI,
969 S.; (engl.)
Nun zeigt sich die Struktur des Gesamtstrings schon deutlicher. Allerdings kann er noch
immer veränderliche Teilstrings enthalten, etwa Werte von Datenelementen, die nicht erkannt
wurden. Diese stellen Inhalte dar und können nicht zur Strukturierung verwendet werden.
Daher müssen sie ebenfalls entfernt werden. Sie sind aber nicht ohne weiteres identifizierbar,
können also nicht wie die erkannten Werte einfach ersetzt werden. Daher muß ein anderer
Weg gefunden werden. Die Beobachtung zeigt, daß Gesamtstrings oft durch wiederkehrende
Zeichen(folgen) zwischen den Werten der enthaltenen Datenelemente strukturiert sind. Diese
wiederkehrenden Zeichenfolgen können zur Identifikation der bisher nicht erkannten
Datenelemente genutzt werden. Zudem haben Werte von Datenelementen die Eigenschaft, als
Träger von Informationen für den Benutzer zu großen Anteilen aus Buchstaben und Ziffern zu
bestehen, wohingegen die strukturierenden Zeichenfolgen einen hohen Anteil von
Interpunktionszeichen aufweisen. Eine Möglichkeit besteht nun darin, alle Teilstrings aller
noch nicht als Wert eines Datenelementes identifizierten Teilstrings zu bilden und
anschließend ihre Häufigkeit innerhalb des Gesamtstrings zu bestimmen. Teilstrings, die Teil
anderer Teilstrings sind und dieselbe Häufigkeit wie diese besitzen, können ausgeschlossen
werden. In obrigen Beispiel würden nach dieser Eliminierung folgende Teilstrings übrig
bleiben:
Teilstring Häufigkeit
/ 1
. - 4. ed.. - 1
. - XXI, 969 S.; (engl.) 1
, 2
. - 3
Nun kann noch die oben genannte Eigenschaft der Datenelemente zur Eliminierung weiterer
Teilstrings genutzt werden, daß sie einen hohen Anteil von Buchstaben und Ziffern
aufweisen. Entfernt werden alle Teilstrings, bei denen dieser Anteil mindestens die Hälfte
ausmacht. Da wiederkehrenden Zeichenfolgen gesucht werden, können zudem alle Teilstrings
mit der Häufigkeit 1 eliminiert werden. Auch einzelne Zeichen sind nicht von Interesse und
werden daher entfernt, wenn sie mit hoher Wahrscheinlichkeit auch innerhalb der Werte von
Datenelementen auftreten können. Das Beispiel hat danach folgende Form:
Teilstring Häufigkeit
. - 3
Nun kann der Gesamtstring noch einmal bearbeitet werden, wobei alle Teilstrings, die mit
einer der gefundenen strukturierenden Zeichenfolgen beginnen und enden und dazwischen zu
mindestens der Hälfte aus Buchstaben und Ziffern bestehen, insofern substituiert, als daß der
Teil zwischen den strukturierenden Zeichenfolgen als unbekanntes Datenelement eingestuft
wird. Beginnt der Teilstring am Ende des Gesamtstrings mit einer strukturierenden
66

Zeichenfolge und besteht danach zu mindestens der Hälfte aus Buchstaben und Ziffern, so
wird der zweitere Teil ebenfalls als unbekanntes Datenelement eingestuft. Endet der
Teilstring am Anfang des Gesamtstrings mit einer strukturierenden Zeichenfolge und besteht
davor zu mindestens der Hälfte aus Buchstaben und Ziffern, so wird auch hier der zweitere
Teil als unbekanntes Datenelement eingestuft. Das Beispiel hat nach diesen Schritten
folgende Form:
Gesamtstring nach Ersetzung dieser Werte:
/ . - . - , . -
Die nun noch zwischen den Datenelementen verbliebenen Zeichenfolgen werden bei der
Erzeugung der Regulären Ausdrücke als Grenzstrings benutzt.
5.7.3 Erzeugung und Optimierung der Ausdrücke
Nun da die Abgrenzung der Datenelemente untereinander geklärt ist, können reguläre
Ausdrücke gemäß Abschnitt 2.9.2 zur Extraktion jeweils eines Datenelementes erzeugt
werden. Dabei stellt das zu extrahierende Datenelement den Zielstring dar, alle anderen
stehen für Abfallstrings. Die Erzeugung des Rohausdrucks geschieht durch einfaches
Einsetzen der entsprechenden Zeichen (§, *, {?} + , {+} + ) für die Tags der Datenelemente:
Gesamtstring mit Tags:
/ . - . - , . -
Rohausdruck für Titel:
§ / *. - *. - *, ++++. - *
Rohausdruck für Autor:
* / §. - *. - *, ++++. - *
Rohausdruck für Verlag:
* / *. - *. - §, ++++. - *
Rohausdruck für Erscheinungsjahr:
* / *. - *. - *, ????. - *
Diese Roh-Ausdrücke können jedoch bei der Anwendung noch einige Fehler verursachen,
zumal sie eventuell noch nicht der Spezifikation aus Abschnitt 2.9.2 entsprechen. Bei den
Ausdrücken im Beispiel würde etwa die Extraktion des Erscheinungsjahres scheitern, wenn
der Verlagsname ein , enthält, da dann die ersten vier Zeichen nach diesem extrahiert
würden. Daher müssen sie optimiert werden, wobei zum einen die Position des Zielstrings
eine Rolle spielt, zum zweiten dessen Länge (fix oder variabel), zum dritten, ob dieser immer
von einer bestimmten Zeichenfolge begleitet wird (z.B. ISBN bei der ISBN-Nummer, € oder $
beim Preis) und zum vierten die Beschaffenheit der Grenzstrings. Letztere wird wie folgt
benannt:
• Ein Grenzstring ist unsicher, wenn er nur aus einem Nicht-Leerzeichen besteht und
dieses mit großer Wahrscheinlichkeit auch zur Interpunktion innerhalb der Werte von
Datenelementen vorkommen kann, z.B. ,.
• Ein Grenzstring ist sicher, wenn er aus mehr als einem Nicht-Leerzeichen besteht,
beispielsweise . -.
• Ein Grenzstring ist einmalig, wenn er sicher ist und im Gesamtstring nur einmal
vorkommt.
• Ein Grenzstring ist bekannt, wenn es sich dabei um eine Zeichenfolge handelt, die
immer in Verbindung mit einem bestimmten Datenelement auftritt, z.B. ISBN bei der
ISBN-Nummer, € oder $ beim Preis.
Mit diesen Begriffen lassen sich folgende Regeln zur Optimierung der Rohausdrücke
aufstellen. Sie ergeben sich aus dem Algorithmus, der die Ausdrücke auf Strings anwendet.
67

• Regel 1: Endet der Gesamtstring mit einem Zielstring fester Länge, kann der
komplette Ausdruck vorhergehende durch * ersetzt werden.
• Regel 2: Beginnt der Gesamtstring mit einem Zielstring fester Länge, kann der
komplette nachfolgende Ausdruck durch * ersetzt werden.
• Regel 3: Geht einem Zielstring fester Länge ein einmaliger oder bekannter
Grenzstring voran, kann der komplette vorangehende und nachfolgende Ausdruck
durch * ersetzt werden.
• Regel 4: Folgt auf einen Zielstring fester Länge ein einmaliger oder bekannter
Grenzstring, kann der komplette vorangehende und nachfolgende Ausdruck durch *
ersetzt werden.
• Regel 5: Geht einem Zielstring fester Länge ein sicherer Grenzstring voran, kann der
Rest des Ausdrucks durch * ersetzt werden.
• Regel 6: Folgt auf einen Zielstring fester Länge ein sicherer Grenzstring, kann ein
dem Zielstring vorangehender unsicherer Grenzstring durch * ersetzt werden.
• Regel 7: Geht einem Zielstring ein einmaliger oder bekannter Grenzstring voran, kann
der komplette vorhergehende Ausdruck durch * ersetzt werden.
• Regel 8: Folgt auf einen Zielstring ein sicherer oder bekannter Grenzstring, kann der
komplette nachfolgende Ausdruck durch * ersetzt werden.
• Regel 8.1: Folgt auf einen Zielstring ein Grenzstring und dann ein Abfallstring
variabler Länge, kann der komplette nachfolgende Ausdruck durch * ersetzt werden.
• Regel 9: Geht einem Zielstring ein unsicherer Grenzstring voran und dann ein
Abfallstring fester Länge, kann der unsichere Grenzstring dem Abfallstring fester
Länge zugeschlagen werden, sofern der Ausdruck mit dem Abfallstring fester Länge
beginnt oder dem Abfallstring fester Länge ein sicherer Grenzstring vorangeht.
• Regel 10: Folgt auf den Zielstring ein unsicherer Grenzstring und dann ein
Abfallstring fester Länge, kann der unsichere Grenzstring dem Abfallstring fester
Länge zugeschlagen werden, sofern der Ausdruck mit dem Abfallstring fester Länge
endet oder auf den Abfallstring fester Länge ein sicherer Grenzstring folgt.
• Regel 11: ** kann durch * ersetzt werden.
• Regel 12: *+...+* kann durch ** ersetzt werden, dann über Regel 11 durch *.
Die Anwendung dieser Regeln soll am Beispiel der weiter oben erzeugten Roh-Ausdrücke
verdeutlicht werden.
Ausdruck für Titel:
§ / *. - *. - *, ++++. - * /Regel 8.1
§ / *
Ausdruck für Autor:
* / §. - *. - *, ++++. - * /Regel 8
* / §. - *
Ausdruck für Verlag:
* / *. - *. - §, ++++. - * /Regel 10
* / *. - *. - §++++++. - *
Ausdruck für Erscheinungsjahr:
* / *. - *. - *, ????. - * /Regel 6
* / *. - *. - **????. - * /Regel 11
* / *. - *. - *????. - *
Um diese Ausdrücke können die Pfade der Datenelemente nun ergänzt werden, falls mehrere
Datenelemente durch denselben Pfad adressiert werden. Dadurch kann dann dennoch jedes
Datenelement einzeln extrahiert werden.
68

5.8 Resultierende Anforderungen an Generierungs-Basisdaten
Der in den letzten Abschnitten entwickelte Generierungs-Prozeß ist in hohem Maße von
Basis-Daten abhängig, z.B. von den Heuristiken zur Erkennung der Optionen in einem
Auswahlfeld, den Beispiel-Suchwerte zur Generierung der Pfade oder dem Wissen um immer
mit bestimmten Datenelementen auftretende Zeichenketten. In diesem Abschnitte werden die
notwendigen Daten zusammengefaßt, um eine Generierungs-Basisdatei erzeugen zu können.
Generell lassen sich die Basisdaten in drei Gruppen unterteilen:
• Die Heuristik-Daten für die Analyse von Suchformularen
• Die Heuristik-Daten zur Generierung Regulärer Ausdrücke
• Die Beispiel-Daten für die Generierung der Pfade in den Ergebnis-Dokumenten von
Suchanfragen mit einem und mit mehreren Treffern
Jede dieser Gruppen wird im folgenden einzeln behandelt. Des weiteren sind aber auch noch
einige Daten notwendig, die keiner von ihnen zuzuordnen sind, da sie zum einen einzeln
dastehen, zum anderen in mehreren Bereichen benötigt werden:
• Der UniCats-i-interne Name für Freitext-Felder muß speziell angegeben werden, da er
keinem Beispiel-Wert eines Datenelementes zugeordnet werden kann und damit nicht
über dessen Namen für die Bezeichnung von Suchfeldern zur Verfügung steht.
• Die für Eingebettete Treffer in Frage kommenden Datenelemente sind bei der Analyse
von Suchformularen notwendig, können aber nicht direkt den Heuristik-Daten
zugeordnet werden.
• Die Selektivität der einzelnen Datenelemente wird bei der Erzeugung der Beispiel-
Anfragen zur Generierung der Pfade benötigt, kann aber auch nicht direkt den
Beispiel-Daten zugeordnet werden.
• Der Beispiel-Suchwert für Suchanfragen, die keinen Treffer liefern sollen, wird zum
Erzeugen des Kein-Treffer-Dokumentes benötigt. Er muß einen Wert haben, zu dem
mit an Sicherheit grenzender Wahrscheinlichkeit in keinem noch so umfangreichen
Produkt-Katalog ein Artikel vorhanden ist. Dies sollte daher kein auch noch so
ungebräuchliches Wort sein, sondern eine nicht zu kurze, keinen Sinn ergebende
Abfolge von Buchstaben und Ziffern.
• Zudem ist von Interesse, auf welches Datenelement obriger Suchwert als Kriterium
angewandt werden soll, um keinen Konflikt mit Eingabe-Überprüfungen und
Längenbeschränkungen von Suchfeldern zu riskieren.
5.8.1 Heuristik-Daten zu Formular-Analyse
Bei der Analyse von Suchformularen werden Heuristik-Daten zur Erkennung der Optionen in
Auswahlfeldern benötigt. Diese müssen die UniCats-i-internen Bezeichnungen der
Datenelemente und logischen Verknüpfungsarten den in Suchformularen für diese
verwendeten Namen zuordnen. Dabei können pro internem Begriff durchaus mehrere
mögliche Namen angegeben werden. Es ist zudem sinnvoll, mehrere Sprachen zu
berücksichtigen.
5.8.2 Heuristik-Daten zur Generierung regulärer Ausdrücke
Bei der Generierung der regulären Ausdrücke zur Extraktion der Werte einzelner
Datenelemente aus einem Gesamtstring wird Zusatzwissen über Eigenschaften der einzelnen
Datenelemente benötigt. Zuerst ist von Interesse, welche Datenelemente immer dieselbe
Länge haben. Zweitens ist die Kenntnis von Zeichenfolgen wichtig, die immer als Begleiter
bestimmter Datenelemente auftreten. Drittens muß bekannt sein, welche
Interpunktionszeichen mit großer Wahrscheinlichkeit auch innerhalb der Werte von
Datenelementen anzutreffen sind, um die Sicherheit der Grenzstrings einschätzen zu können.
69

5.8.3 Beispiel-Daten für die Pfad-Generierung
Zur Generierung der Pfade zur Extraktion der Werte von Datenelementen aus Ergebnis-
Dokumenten von Suchanfragen mit einem und solchen mit mehreren Treffern werden Sätze
von Beispiel-Daten benötigt. In jedem Satz sind die Werte der Datenelemente angegeben, die
ein bestimmtes Buch beschreiben. Dabei können pro Datenelement mehrere konkrete Werte
vorhanden sein, die mögliche Darstellungsformen ein und derselben Information darstellen.
Das Beispiel zeigt einen solchen Satz:
creator = Flanagan
creator = Flanagan, D.
creator = Flanagan, David
creator = D. Flanagan
creator = David Flanagan
title = Java in a nutshell
title = Java in a nutshell : a desktop quick reference
title =
Java in a nutshell : a desktop quick reference ; [covers Java 1.4]
date = 2002
identifier = 0-596-00283-1
publisher = O'Reilly
publisher = Cambridge ; Köln : O'Reilly
publisher = Beijing : O'Reilly
Bei der Angabe von mehreren möglichen Werten für ein Datenelement ist die Reihenfolge
wichtig, da immer nur der jeweils erste für Test-Anfragen bei der Klassifizierung von
Suchfeldern verwendet wird, um eine Schieflage bezüglich der Anzahl zu vermeiden. Der
erste Wert je Datenelement ist zudem der, der beim Erzeugen der Suchanfrage für die
Generierung der Pfade zur Extraktion der Datenelemente aus dem Ergebnis-Dokument einer
Suche mit einem Treffer benutzt wird.
Die Beispiel-Daten für die Generierung der Pfade zur Extraktion der Datenelemente aus dem
Ergebnis-Dokument einer Suche mit mehreren Treffern bestehen aus Gruppen solcher Sätze.
Dabei ist jeder Gruppe ein Beispiel-Suchbegriff zugeordnet. Die in der Gruppe enthaltenen
Sätze beinhalten die Werte der Datenelemente zur Beschreibung solcher Bücher, die bei einer
Suche nach dem Beispiel-Suchwert mit großer Wahrscheinlichkeit als Treffer auftreten.
Zudem sind die Datenelemente angegeben, auf die der Beispiel-Suchwert am besten als
Suchkriterium angewandt wird, um die gewünschten Treffer zu erhalten.
5.9 Zusammenarbeit der Generator-Agenten
Um die volle Mächtigkeit der Struktur eines Agentensystems nutzen zu können, benötigen die
einzelnen GAs untereinander ein gewisses „Sozialverhalten“. Da die vollautomatische
Generierung einer Quellenbeschreibung nach dem in diesem Kapitel entworfenen Verfahren
zudem einen sehr zeitaufwendigen Prozeß darstellt, sollte eine mehrfache gleichzeitige
Durchführung für denselben Anbieter vermieden werden. In diesem Abschnitte werden
Möglichkeiten erörtert, wie dies zu erreichen ist.
5.9.1 Möglichkeiten zur Zusammenarbeit
Prinzipiell sind fünf Konstellationen denkbar, in denen die Generierung einer
Quellenbeschreibung nicht durch den GA selbst durchgeführt werden muß, der die Anfrage
erhalten hat, bzw. in denen ein solches Verhalten nicht optimal wäre:
• Der GA hat für den fraglichen Anbieter bereits eine aktuelle Quellenbeschreibung
generiert. Dann kann diese sofort zurückgegeben werden.
70

• Der GA ist bereits dabei, für den fraglichen Anbieter eine aktuelle
Quellenbeschreibung zu generieren. Dann kann diese auch an den zweiten
anfragenden AA geliefert werden, sobald die Generierung abgeschlossen ist.
• Ein anderer GA hat für den fraglichen Anbieter bereits eine aktuelle
Quellenbeschreibung generiert. Diese könnte an den anfragenden AA zurückgegeben
werden, falls sie dem angefragten GA bekannt wäre.
• Ein anderer GA ist bereits dabei, für den fraglichen Anbieter eine aktuelle
Quellenbeschreibung zu generieren. Diese könnte nach ihrer Fertigstellung an den
anfragenden AA zurückgegeben werden, falls sie dem angefragten GA bekannt wäre.
• Es liegt keine aktuelle Quellenbeschreibung für den fraglichen Anbieter vor, der
angefragte GA ist aber deutlich stärker ausgelastet als ein anderer GA. In diesem Fall
wäre es günstiger für das Gesamtsystem, wenn der weniger ausgelastete GA die
Generierung durchführt.
Die ersten beiden Fälle können im GA lokal behandelt werden. Bei Eingang einer Anfrage
von einem AA muß lediglich geprüft werden, ob bereits eine aktuelle Quellenbeschreibung
vorliegt oder sich in Generierung befindet. Dazu muß der GA lediglich die generierten
Quellenbeschreibungen speichern, um sie quasi als Archiv zur Verfügung zu haben.
Die zweiten beiden Fälle laufen ähnlich ab, allerdings nicht lokal im GA. Vielmehr wird der
GA bei Eingang einer Anfrage von einem AA bei allen anderen ihm bekannten GAs
nachfragen, ob sie eine aktuelle Quellenbeschreibung für den fraglichen Anbieter in ihrem
Archiv haben oder sich eine solche gerade in Generierung befindet.
Der letzte Fall ist dagegen etwas komplexer, da hier der Aufwand der Generierung in jedem
Fall betrieben werden muß und die Anfrage somit nicht einfach weitergereicht werden kann.
Zunächst ist zu klären, ob einer der bekannten GAs wenig genug ausgelastet ist, um bereit zur
Übernahme der Anfrage zu sein. Anschließend ist aber auch sicherzustellen, daß nicht
mehrere wenig ausgelastete GAs gleichzeitig dieselbe Anfrage übernehmen, da dies
wiederum eine mehrfache gleichzeitige Bearbeitung desselben Anbieters zur Folge hätte.
Dieser Übergabe / Übernahme-Vorgang wird im folgenden Abschnitt behandelt.
Abbildung 5.5: Übergabe / Übernahme einer Anfrage – Ablauf
5.9.2 Übergabe / Übernahme einer Anfrage
Um eine dynamische Lastverteilung unter den GAs zu erreichen, muß eine Möglichkeit
geschaffen werden, die Bearbeitung von Anfragen, also die Generierung von
Quellenbeschreibungen, von einem GA zu einem anderen zu übergeben. Dabei muß
sichergestellt werden, daß nicht mehrere GAs gleichzeitig eine Anfrage übernehmen und mit
der Generierung beginnen. Hierzu empfiehlt sich das Prinzip des doppelten Handschlages,
also eine Abfolge von Anfrage, Antwort und Bestätigung.
71

Übertragen auf das Problem der dynamischen Lastverteilung unter den GAs bedeutet dies,
daß der angefragte GA zunächst bei allen ihm bekannten GAs anfragt, ob diese bereit sind,
die Generierung einer Quellenbeschreibung zu übernehmen. Diese prüfen dann, ob sie
aufgrund ihrer aktuellen eigenen Auslastung zu einer Übernahme bereit sind und senden dem
anfragenden GA eine Zu- oder Absage, wobei die Zusage die aktuelle Auslastung des GA
enthält. Der angefragte GA wählt dann unter den GAs, die eine Übernahme zugesagt haben,
den am wenigsten ausgelasteten aus und sendet diesem eine positive Bestätigung, daß er mit
der Generierung der Quellenbeschreibung beginnen kann. Alle anderen zur Übernahme
bereiten GAs erhalten eine negative Bestätigung, und sie brauchen keine Generierung
durchzuführen. Abbildung 5.5 verdeutlicht den Vorgang.
5.10 Anforderungen an den GeneratorAgenten
Die in den letzten Abschnitten entworfenen Verfahren zur vollautomatischen Generierung
einer Quellenbeschreibung auf Basis von Beispiel-Daten nach dem Prinzip der Generation by
Example allein durch die Angabe einer Einstiegs-URL müssen nun in den GA integriert
werden. Hinzu kommt die Fähigkeit der dynamischen Lastverteilung der GAs untereinander.
Daraus ergeben sich eine Reihe von Anforderungen:
• Der GA muß fähig sein, die zur Generierung der Quellenbeschreibung benötigten
Beispiel- und Heuristik-Daten zur Verfügung zu stellen, sie also beispielsweise aus
einer Datei einzulesen.
• Das Verfahren zur dynamischen Lastverteilung muß im GA umgesetzt werden.
Insbesondere bedeutet dies, daß er die Fähigkeit zur Einschätzung seiner aktuellen
Auslastung besitzen muß, um sich für oder gegen eine Übergabe / Übernahme
entscheiden zu können.
• Der GA muß fähig sein, das Verfahren zur Generierung einer Quellenbeschreibung
auf eine gegebene Einstiegs-URL anwenden zu können. Falls dieses fehlschlägt, sollte
er zudem einen Administrator benachrichtigen können, so daß dieser die Generierung
mithilfe des Generator-Werkzeuges durchführen kann.
• Zur Durchführung der Generierung muß der GA auf Internet-Seiten zugreifen,
insbesondere also HTTP-Anfragen über GET oder POST ausführen können.
• Zudem muß er fertige Quellenbeschreibungen nicht nur an den anfragenden AA
zurückliefern, sondern auch in einem Archiv speichern, sie also z.B. in Dateien
ablegen können.
• Zuletzt ist wichtig, daß der GA auch während der Durchführung von aufwendigen
Schritten der Generierung noch in der Lage ist, Nachrichten anderer Agenten zu
empfangen und zu beantworten.
72

6. Implementierung
Im letzten Kapitel wurden die Verfahren entworfen, mit deren Hilfe das Hauptziel dieser
Arbeit, die vollautomatische Generierung einer Quellenbeschreibung, erreicht werden kann.
Dieses Kapitel geht auf die Realisierung und Implementierung der dazu notwendigen
Algorithmen sowie der zu deren Unterstützung notwendigen Datenstrukturen und Hilfspakete
ein.
6.1 Allgemeine Überlegungen
Bevor damit begonnen werden kann, die einzelnen Algorithmen und Datenstrukturen zu
implementieren, ist zunächst die allgemeine Architektur des zu realisierenden GA und des
diesen unterstützenden Generator-Werkzeuges zu klären. Dabei sind mehrere Punkte zu
beachten:
• Die Verfahren zu vollautomatischen Generierung einer Quellenbeschreibung sollen
sowohl dem GA zur komplette autonomen Ausführung des Generierungs-Prozesses
als auch dem Generator-Werkzeug zur vollautomatischen Ausführung von Teilen
desselben zur Verfügung stehen. Daher sollten die Algorithmen nicht im GA selbst,
sondern in einer eigenen Komponente implementiert werden, die benötigten
Datenstrukturen sollten ein eigenes Paket bilden.
• Die Generierungs-Algorithmen sind teilweise sehr zeitaufwendig. Daher empfiehlt es
sich nicht, diese vom GA selbst durchführen zu lassen, da in diesem Fall zumindest
für die Zeit der Ausführung eines Generierungsschrittes nicht in der Lage wäre,
Anfragen entgegenzunehmen und sonstige Kommunikationsprozesse durchzuführen.
Sie sollten vielmehr in einem mit dem GA verbundenen eigenen Prozeß ablaufen.
• Die Algorithmen und Datenstrukturen zur Unterstützung der erweiterten
hierarchischen Pfadausdrücke (siehe Abschnitt 2.9.3) und regulären Ausdrücke (siehe
Abschnitt 2.9.2) sowie zum Vergleich von HTML-Dokumenten (siehe Abschnitt 2.8)
stellen die Basis der Algorithmen zur Generierung der Quellenbeschreibung dar. Ihre
Implementierung kann allerdings nur schwerlich auf der Basis eines bestehenden
Baum-Paketes wie JDOM erfolgen. Andererseits schränkt eine Implementierung
innerhalb der Generator-Komponenten die Wiederverwendbarkeit extrem ein. Daher
sollten diese Algorithmen und die dafür notwendigen Datenstrukturen in einem
eigenen Paket realisiert werden. Dies schließt auch den Parser mit ein, der die
Baumstruktur aus einem in String-Darstellung vorliegenden HTML oder XML-
Dokument aufbaut.
Diese Überlegungen legen die in Abbildung 6.1 dargestellte Architektur nahe.
Abbildung 6.1: Grob-Architektur des GA
73

6.2 Das Paket generatorAgent
Das Paket generatorAgent enthält die Implementierungen des GA, die Generator- und die
IO-Bibliothek sowie die Work-Objekte zur Repräsentation laufender Anfragen im GA. Die
einzelnen Klassen werden in den folgenden Abschnitten behandelt.
6.2.1 Die Klasse GeneratorAgent
Die Klasse GeneratorAgent erbt von der allgemeinen UniCats-i-Agentenklasse
de.unicats.agents.Agent und implementiert den GA selbst. Sie beinhaltet Methoden zur
Beantwortung eingehender Nachrichten, zur Bearbeitung von Anfragen sowie für die
dynamische Lastverteilung der GAs untereinander. Darin ist auch das Bestreben
eingeschlossen, möglichst viele andere GAs zu kennen, um mit ihnen zusammenarbeiten zu
können.
Die in Bearbeitung befindlichen Anfragen werden von den auf externe Bearbeitung wartenden
oder darin befindlichen separat verwaltet, um letztere nicht in die Berechnung der aktuellen
Auslastung des GA einfließen zu lassen. Die Generierung dieser Quellenbeschreibungen
wurde von anderem GA übernommen, oder ein Administrator wurde über ein Fehlschlagen
der vollautomatischen Generierung einer Quellenbeschreibung benachrichtigt.
6.2.2 Die Klasse RequestHandler
Die Klasse RequestHandler übernimmt das Management der eigentlichen Generierung von
Quellenbeschreibungen und steuert die Ausführung der Generierungs-Algorithmen. Damit
stellt sie den dem GA zugeordneten Generator dar.
6.2.3 Die Klasse ContextGenerator
Die Klasse ContextGenerator enthält die Algorithmen zur vollautomatischen Generierung
einer Quellenbeschreibung aus einer gegebenen Einstiegs-URL auf Basis von Beispiel- und
Heuristik-Daten. Diese sind static implementiert, so das ContextGenerator nicht instanziiert
werden muß.
6.2.4 Die Klasse IoTool
Die Klasse IoTool stellt die Methoden zur externen Kommunikation zur Verfügung. Dies
beinhaltet das Lesen und Schreiben von Dateien, das Laden von HTML-Dokumenten aus dem
Internet inklusive der Behandlung von Page-Forwards und HTTP-Header-basierten Sessions,
das Abschicken ausgefüllter Suchformulare über die HTTP-Methoden GET und POST und
das Versenden von eMails.
6.2.5 Die Klasse PAContextRequest
Die Klasse PAContextRequest repräsentiert in der Warteschlange des GA die Anfrage eines
AA. Sie enthält bis auf den Konstruktor keine Methoden, sondern ausschließlich Daten. Diese
umfassen die Einstiegs-URL, die zur Generierung notwendigen Beispiel- und Heuristik-Daten
sowie Zwischen- und Endergebnisse des Generierungs-Prozesses.
6.2.6 Die Klasse GAContextRequest
Die Klasse GAContextRequest repräsentiert in der Warteschlange des GA die Anfrage eines
anderen GA nach einer archivierten Quellenbeschreibung oder Kommunikationsschritte bei
der Übergabe / Übernahme von Anfragen zwischen GAs. Sie enthält neben dem Konstruktor
ebenfalls keine Methoden, sondern lediglich Daten, die der Koordination der des Übergabe /
Übernahme-Prozesses und dem Loadbalancing zwischen den GAs dienen.
74

6.2.7 Die Klasse GaWebServiceInterface
Die Klasse GAWebServiceInterface stellt dem Generierungs-Werkzeug die Möglichkeit
zum Zugriff auf die zur automatischen Generierung notwendigen Beispiel- und Heuristik-
Daten sowie auf Internet-Seiten zur Verfügung, sofern dieses aus einer Benachrichtigung über
die fehlgeschlagene vollautomatische Generierung einer Quellenbeschreibung als Applet
innerhalb eines HTML-Dokumentes gestartet wurde.
6.3 Das Paket generatorAgent.extractionTools
Das Paket generatorAgent.extractionTools stellt die Implementierung eines Extraktors
zur Verfügung, der einen durch eine Quellenbeschreibung konfigurierbaren Wandler
realisiert. Dieser enthält sowohl den Anfrage-Generator, der auch separat verwendet werden
kann, als auch eine Multithread-basierte Komponente zum Aufruf der Ergebnis-Dokumente
und der von diesen aus über Hyperlinks erreichbaren HTML-Dokumente und zur Extraktion
der Datenelemente aus den geladenen Dokumenten anhand der Quellenbeschreibung.
6.3.1 Die Klasse DataExtractor
Die Klasse DataExtractor dient der Ausführung einer Suchanfrage und der Extraktion von
Daten aus dem Ergebnis-Dokument einer Suche und der Koordination der Daten-Extraktion
aus den von diesem aus über Hyperlinks erreichbaren HTML-Dokumenten. Die Methoden zur
Benachrichtigung des umgebenden Objektes über den Status und den Abschluß der
Bearbeitung einer Suchanfrage sollten durch Vererbung überschrieben werden. Zu ihrer
Instanziierung ist eine vollständige Quellenbeschreibung notwendig.
6.3.2 Die Klasse DataExtractionThread
Die Klasse DataExtractionThread übernimmt für ein DataExtractor-Objekt die
Extraktion der Daten aus dem Ergebnis-Dokument einer bestimmten Suchanfrage sowie die
Koordination der Daten-Extraktion aus den von diesem aus über Hyperlinks erreichbaren
HTML-Dokumenten. Der Thread terminiert, wenn die Anfrage abgearbeitet ist.
6.3.3 Die Klasse LayerDataExtractor
Die Klasse LayerDataExtractor dient der Extraktion der Daten aus einem vom Ergebnis-
Dokument einer Suchanfrage über Hyperlinks erreichbaren HTML-Dokument. Zu ihrer
Instanziierung ist die Beschreibung einer Informationsschicht aus der Quellenbeschreibung
notwendig.
6.3.4 Die Klasse LayerDataExtractionThread
Die Klasse LayerDataExtractionThread übernimmt für ein LayerDataExtractor-Objekt
die Extraction der Daten aus einem über Hyperlinks vom Ergebnis-Dokument einer
Suchanfrage aus erreichten HTML-Dokument. Der Thread terminiert, wenn alle in der
Quellenbeschreibung beschriebenen Daten extrahiert sind oder der Timeout für das Laden des
HTML-Dokumentes abgelaufen ist.
6.3.5 Die Klasse QueryPlan
Die Klasse QueryPlan erbt von LayerDataExtractorVector und dient der Koordination der
Daten-Extraktion aus den vom Ergebnis-Dokument einer Suchanfrage aus über Hyperlinks
erreichbaren HTML-Dokumenten. Ihre Instanzen werden benutzt um sicherzustellen, daß
möglichst wenige Informationsschichten angesprochen werden, um die in der Suchanfrage
verlangten Datenelemente zu den einzelnen Ergebnissen zu extrahieren.
75

6.3.6 Die Klasse ProviderQueryResult
Die Klasse ProviderQueryResult repräsentiert im Extraktor die einzelnen Suchanfragen.
Eine Instanz dieser Klasse enthält zum einen die Anfrage und die verlangten Datenelemente,
die für jedes Ergebnis extrahiert werden sollen, zum anderen werden die Ergebnisse darin
gespeichert. Insbesondere dient sie damit der Kommunikation zwischen den einzelnen
Extraktions-Threads.
6.3.7 Die Klasse SearchField
Die Klasse SearchField repräsentiert im Anfrage-Generator ein einzelnes Suchfeld
zusammen mit der ihm zugeordneten Element- und, falls vorhanden, Verknüpfungs-Auswahl.
Zur Instanziierung dieser Klasse ist der ein Suchfeld beschreibende Teil einer
Quellenbeschreibung notwendig. Eine Instanz setzt einen ihr zugewiesenen Teil einer Anfrage
auf das entsprechende Suchfeld um, wobei die Werte der Element- und, falls vorhanden,
Verknüpfungs-Auswahl gesetzte werden.
6.3.8 Die Klasse SearchQueryGenerator
Die Klasse SearchQueryGenerator implementiert den Anfrage-Generator, der eine Anfrage
vom UniCats-i-internen Format auf ein bestimmtes Suchformular übersetzt und das als
Antwort erhaltene HTML-Dokument als String zurückliefert. Zur Instanziierung dieser Klasse
ist eine Quellenbeschreibung notwendig, die mindestens die Beschreibung des Suchformulars
enthält.
6.4 Das Paket generatorAgent.tree
Das Paket generatorAgent.tree enthält die Implementierung der Baumalgorithmen-
Bibliothek, den Parser und die zur Repräsentation der Bäume notwendigen Klassen. Es bildet
damit die Basis für sämtliche Algorithmen des Generierungsprozesses.
6.4.1 Die Klasse AbstractParser
Die Klasse AbstractParser enthält die Implementierung eines allgemeinen SGML-Parsers.
Die Methoden zur Überprüfung der Singularität eines Tags und der Definition, ob ein Tag
Kind eines anderen sein kann, sind abstrakt implementiert. Die Klasse enthält die Fähigkeit,
Ende-Tags umzusortieren, falls diese in der falschen Reihenfolge auftreten.
6.4.2 Die Klasse FastParser
Die Klasse FastParser erbt von AbstractParser und implementiert die beiden abstrakten
Methoden derart, daß kein Tag singulär ist und jedes Tag Kind jedes anderen Tags sein kann.
Durch das Fehlen jeglicher Überprüfung erreicht der Parser eine sehr hohe Geschwindigkeit.
6.4.3 Die Klasse Parser
Die Klasse Parser erbt ebenfalls von AbstractParser. Sie implementiert die beiden
abstrakten Methoden derart, daß die in HTML standardmäßig singulären Tags als singulär
erkannt werden und jedes Tag Kind jedes anderen Tags sein kann, außer von sich selbst bzw.
einem Tag gleichen Namens.
6.4.4 Die Klasse SecureParser
Auch die Klasse SecureParser erbt von AbstractParser. Sie implementiert die beiden
abstrakten Methoden derart, daß durch eine Sprachbeschreibung (LanguageDescription)
definiert werden kann, welche Tags singulär sind und welche Tags Kind welcher Tags sein
76

können. Ist keine LanguageDescription angegeben, werden die Verfahren der Klasse
Parser angewendet.
6.4.5 Die Klasse StringStack
Die Klasse StringStack stellt dem AbstractParser einen auf Strings spezialisierten Keller zur
Verfügung. Insbesondere nimmt sie die Typ-Umwandlungen innerhalb vor, weshalb diese im
AbstractParser selbst nicht mehr beachtet werden müssen.
6.4.6 Die Schnittstelle LanguageDescription
Die Schnittstelle LanguageDescription definiert Methoden zum Holen der singulären Tags
und der möglichen Vater-Tags zu einem gegebenen Tag. Sie stellt den abstrakten Fall der
Definition einer SGML-konformen Sprache für den SecureParser dar.
6.4.7 Die Klasse Html
Die Klasse Html implementiert die Schnittstelle LanguageDescription mit einer auf HTMLabgestimmten
Sprachdefinition. Sie enthält eine Liste der in HTML als singulär definierten
sowie der dort oft singulär verwendeten Tags. Die Überprüfung, ob ein bestimmtes Tag Kind
eines anderen sein kann, erfolgt aufgrund einer Positiv-Liste. Damit ist eine Instanz von
SecureParser, die mit einer Instanz dieser Implementierung der LanguageDescripion-
Schnittstelle gespeist wurde, fähig, fehlerbehaftete HTML-Dokumente in eine Baumstruktur
zu parsen, die zu einer XHTML-konformen Variante des Dokumentes äquivalent ist.
6.4.8 Die Klasse SourceFile
Die Klasse SourceFile implementiert ebenfalls die Schnittstelle LanguageDescription. Sie
definiert allerdings nur solche Tags als singulär, die im Sinne von XML als solche markiert
sind. Jedes Tag kann Kind jedes anderen Tags sein.
6.4.9 Die Klasse ParseTreeNode
Die Instanzen der Klasse ParseTreeNode repräsentieren die Knoten in von den Parsern aus
Strings gewonnenen HTML- oder XML-Bäumen. Die Klasse stellt Methoden zur Abfrage des
Knoten-Typs (repräsentiertes Tag), des Knoten-Wertes (außer bei PcData-Knoten ein
Leerstring) und der Werte von Parametern (z.B. der in href angegebenen Adresse) zur
Verfügung. Kind-Knoten können hinzugefügt und typspezifisch oder -unspezifisch abgerufen
werden. Das Setzen von Parametern ist ebenfalls möglich. Zusätzlich ist ein Knoten in der
Lage, den Teilbaum unter sich zu durchsuchen und Hierarchische Pfadausdrücke nach 2.9 auf
ihn auszuführen.
Eine weitere Fähigkeit der Knoten besteht darin, sich selbst und den Teilbaum unter ihnen als
XML-String (eine Zeichenkette ohne Zeilenumbrüche), als XML-Struktur (mit Tabulatoren
eingerückte umgebrochene Struktur von Tags und Werten) und als HTML-Code (eingerückte
umgebrochene Struktur von Tags mit Parametern und Werten) auszugeben.
Mit dieser Fähigkeit einer von ihr erzeugten Baumstruktur wird eine mit einer Instanz von
HTML gespeiste Instanz von SecureParser zu einem Konverter von fehlerbehafteten HTML-
Dokumenten in XHTML-konforme Dokumente.
6.4.10 Die Klasse ParseTreeCrawler
Die Klasse ParseTreeCrawler enthält Baum-Algorithmen, die auf von einer der Instanzen
der Unterklassen von AbstarctParser erzeugte Baumstrukturen angewendet werden können.
Diese beinhalten Suchalgorithmen über die Typen (repräsentierte Tags) und Werte der
Knoten, Algorithmen zur Ausführung von hierarchischen Pfadausdrücken und regulären
Ausdrücken, die Ausgabe ganzer Bäume in der Reihenfolge von Tiefen und Breitensuche
77

sowie die in Abschnitt 2.8 entworfenen Algorithmen zum syntaktischen und strukturellen
Vergleich von HTML-Dokumenten.
6.4.11 Die Klasse HtmlParser
Die Klasse HtmlParser stellt als static implementierte Methoden zur Umwandlung von
Strings in Baumstrukturen zur Verfügung. Sie bietet damit die Möglichkeit, die direkte
Instanziierung einer Unterklasse von AbstractParser zu vermeiden, wobei allerdings die in
den Methoden ausgeführten Instanziierungen derselben auf HTML spezialisiert sind.
Zusätzlich können die Protokoll-Einträge eines parse-Vorganges in das Protokoll einer
Anfrage (PAContextRequest) übernommen werden.
6.4.12 Die Klasse SourceFileParser
Die Klasse HtmlParser stellt als static implementierte Methoden zur Umwandlung von
Strings in Baumstrukturen zur Verfügung. Sie bietet damit die Möglichkeit, die direkte
Instanziierung einer Unterklasse von AbstractParser zu vermeiden, wobei allerdings die in
den Methoden ausgeführten Instanziierungen derselben auf XML spezialisiert sind. Zusätzlich
können die Protokoll-Einträge eines parse-Vorganges in das Protokoll einer Anfrage
(PAContextRequest) übernommen werden.
6.5 Das Paket generatorAgent.util
Das Paket ganeratorAgent.util beinhaltet die von den Algorithmen zur vollautomatischen
Generierung einer Quellenbeschreibung sowie die von anderen Komponenten benötigten
Klassen zur Repräsentation komplexer und spezialisierter Datenstrukturen. Bis auf die
Konstruktoren stellt keine Klasse Methoden zur Verfügung; sie sind lediglich als Container
für Daten vorgesehen.
Die Klassen generatorAgent.util.*Vector stellen auf einen bestimmten Datentyp
spezialisierte Sonderfälle von java.util.Vector dar, die die Typ-Umwandlungen intern
vornehmen und diese somit in den sie verwendenden Komponenten einsparen.
6.5.1 Die Klasse GenerateDataContainer
Die Instanzen der Klasse GenerateDataContainer beinhalten einen bei der
vollautomatischen Generierung einer Quellenbeschreibung verwendeten Satz
zusammengehöriger Beispiel-Daten oder auch eine Gruppe von dort verwendeten Sätzen von
Beispiel-Daten.
6.5.2 Die Klasse SearchFormContainer
Die Klasse SearchFormContainer wird verwendet, um bei der Suche und Analyse von
Suchformularen diese zu repräsentieren und die im Zuge ihrer Bewertung gewonnenen Daten
zu speichern.
6.5.3 Die Klasse SearchFieldContainer
Die Klasse SerachFieldContainer dient bei der Analyse von Suchformularen der Haltung
und Auswertung von Daten, die zur Klassifizierung eines einzelnen Suchfeldes benötigt
werden.
6.5.4 Die Klasse OptionFieldContainer
Die Klasse OptionFieldContainer wird bei der Analyse von Auswahl-Feldern zur Haltung
und Auswertung von über diese gewonnenen Daten verwendet.
78

6.5.5 Die Klasse QueryPartContainer
Die Instanzen der Klasse QueryPartContainer dienen dem Anfrage-Generator dazu, die zu
Suchfeldern zugewiesenen einzelnen Kriterien einer UniCtas-i-internen Anfrage darzustellen.
Sie beinhalten dabei sowohl das als Kriterium verwendete Datenelement mitsamt dem
Suchwert als auch, falls verfügbar, die logische Verknüpfung zum über das nachfolgende
Suchfeld eingegebene Kriterium.
6.5.6 Die Klasse LayerContainer
Die Klasse LayerContainer wird im Rahmen des Generierungs-Prozesses dazu verwendet,
eine Informationsschicht zu repräsentieren. Dies beinhaltet sowohl die Baumdarstellung des
zugrunde liegenden HTML-Dokumentes als auch die identifizierten Datenelemente und die
zugehörigen Pfadausdrücke.
6.5.7 Die Klasse LayerCascadeContainer
Die Klasse LayerCascadeContainer repräsentiert innerhalb des Generierungs-Prozesses eine
Kaskade von Informationsschichten.
6.5.8 Die Klasse RegExGenerateContainer
Die Instanzen der Klasse RegExGenerateContainer nehmen im Zuge der Generierung der
Pfadausdrücke die zu Erzeugung der Regulären Ausdrücke notwendigen Daten auf und
dienen dabei ebenfalls der Rückgabe der Ergebnisse.
6.5.9 Die Klasse ResultPart
Die Instanzen der Klasse ResultPart repräsentieren während der Bearbeitung einer
Suchanfrage die einzelnen Ergebnisse.
6.5.10 Die Klasse ProtocolVector
Die Klasse ProtocolVector stellt ein Protokoll mit beliebig vielen Einträgen zur Verfügung,
das zur Dokumentation des Generierungsprozesses verwendet werden kann. Eine Instanz
dieser Klasse ist dabei in der Lage, anhand der Wichtigkeit eines Eintrages zu entscheiden, ob
dieser gespeichert wird oder nicht. Einträge anderer Instanzen (z.B. derer von verwendeten
Komponenten) können übernommen werden. Zur Reduktion des Bedarfs an Speicher können
bei Erreichen einer bestimmten (definierbaren) Anzahl von Einträgen ältere in eine Datei
ausgelagert werden.
6.6 Das Paket generatorAgent.ws
Die Klassen des Paketes generatorAgent.ws werden von java2wsdl und wsdl2java
automatisch erzeugt. Sie bilden die Basis, die dem Generator-Werkzeug, sofern es über den in
einer eMail an einen Administrator enthaltenen Hyperlink als Applet gestartet wurde, über
WebServices zum einen den Zugriff auf die zur Generierung notwendigen Beispiel- und
Heuristik-Daten ermöglicht, zum anderen den durch den Betrieb als Applet beschränkten
Zugriff auf die Internet-Seite des fraglichen Anbieters.
79

7. Werkzeuge
Im Rahmen dieser Arbeit wurde nicht nur der GA entworfen und implementiert, sondern auch
eine Generator-Werkzeug zur semi-automatischen Generierung einer Quellenbeschreibung
geschaffen, das bei Fehlschlagen des vollautomatischen Prozesses angewendet werden kann.
Zudem erscheint aufgrund der Komplexität der für die vollautomatische Generierung
notwendigen Beispiel- und Heuristik-Daten ein Editor für diese sinnvoll. Beide Werkzeuge
werden in diesem Kapitel vorgestellt.
7.1 Das Generator-Werkzeug
Das Generator-Werkzeug dient zur semi-automatischen Generierung von
Quellenbeschreibungen durch einen Benutzer. Er kann dabei die einzelnen Schritte auch
vollautomatisch durchführen lassen, sofern er Beispiel- und Heuristik-Daten geladen hat. In
diesem Fall muß er lediglich die angezeigten Zwischenergebnisse überprüfen und
gegebenenfalls korrigieren.
Das Generator-Werkzeug kann sowohl als eigenständige Anwendung betrieben werden als
auch als Applet innerhalb eines HTML-Dokumentes. Letztere Möglichkeit kommt zum
Einsatz, wenn die vollautomatische Generierung einer Quellenbeschreibung durch den GA
aus irgendeinem Grund fehlgeschlagen ist. In diesem Fall wird ein Administrator per eMail
über das Scheitern des GA benachrichtigt, wobei diese einen Hyperlink zu einem vom GA
dynamisch erstellten HTML-Dokument enthält, das das Generierungs-Werkzeug enthält. Der
Administrator muß dann lediglich den Hyperlink öffnen und kann die Generierung direkt im
Browser vornahmen. Aufgrund der restriktiven Sicherheitsbestimmungen für Applets müssen
die HTML-Dokumente während der Generierung über den GA geholt werden, und auch die
Beispiel- und Heuristik-Daten müssen von dort geladen werden. Letztlich muß die fertige
Quellenbeschreibung an den GA zurückgegeben werden, damit dieser sie archivieren und
dem anfragenden AA zur Verfügung stellen kann. Alle diese Kommunikationsaufgaben
werden über vom GA angebotene WebServices realisiert, die das Applet aufrufen kann.
Bei der Gestaltung der Benutzeroberfläche des Generator-Werkzeuges wurden die
Verbesserungsvorschläge berücksichtigt, die im Rahmen des Evaluierungsexperimentes für
seinen Vorgänger [Schneider 2001] gemacht wurden. Dabei wurden die als positiv bewerteten
Aspekte aufgegriffen und verfeinert, die als negativ oder fehlend bewerteten weitestgehend
entfernt. So wurde die Darstellung von HTML-Dokumenten in Browser-, Baum- und
zusätzlich Text-Ansicht mit relevanten Bausteinen beibehalten, die von manchen
Testbenutzern als verwirrend empfundene Anzeige der bisher generierten
Quellenbeschreibung ist dagegen nur noch über einen Menupunkt erreichbar statt permanent
sichtbar zu sein, und die Generierung wird Schritt für Schritt im Stil eines Wizzards
durchgeführt. Dabei können mehrere Anbieter parallel bearbeitet werden.
7.1.1 Das Paket generatorAgent.applet
Das Paket generatorAgent.applet beinhaltet die vom Generator-Werkzeug benötigten
Klassen. Diese umfassen sowohl die zur Darstellung der Benutzeroberfläche benötigten
Komponenten wie auch die zur Kommunikation mit einem GA (im Betrieb als Applet) und
zum Laden von Basisdaten und Speichern fertiger Quellenbeschreibungen (im Betrieb als
Anwendung). Hinzu kommt die Integration der in der Klasse ContextGenerator
implementierten Generierungs-Automatismen. Verwendet werden daneben weitere Klassen
aus dem Paket generatorAgent sowie solche aus den Paketen generatorAgent.util und
generatorAgent.tree.
81

7.1.1.1 Die Klasse GeneratorApplet
Die Klasse GeneratorApplet bildet die Basis für das Generierungs-Werkzeug. Sie stellt
Grundfunktionen wie die Menu- und Statusleiste zur Verfügung und zeigt den aktuell
bearbeiteten Generierungs-Prozeß an. Diese Klasse erbt von JApplet, wodurch der Betrieb
des Generator-Werkzeuges als Applet ermöglicht wird, sieht aber auch den Betrieb als
eigenständige Anwendung vor.
7.1.1.2 Die Klasse ContextGeneratorWizzard
Die Klasse ContextGeneratorWizzard bildet den Kontainer für die Generierung einer
Quellenbeschreibung. Sie steuert den Ablauf des Generierungs-Prozesses und führt den
Benutzer Schritt für Schritt von der Auswahl und Analyse eines Suchformulars zur
Generierung der Pfade zur Extraktion der Werte der Datenelemente hin zu einer fertigen
Quellenbeschreibung. Dabei kann der Benutzer bei jedem Schritt der Generierung
entscheiden, ob er diesen von den zur Verfügung stehenden Automatismen ausführen lassen
will, oder ob er ihn selbst durchführen möchte. Bei der Wahl letzterer Option stehen ihm
weitere Automatismen zur Verfügung, die Teile der Generierung vornehmen.
7.1.1.3 Die Klasse StartPageFinder
Die Klasse StartPageFinder stellt eine Ansicht dar, die dem Finden eines Einstiegs-HTML-
Dokumentes zur Generierung einer Quellenbeschreibung dient. Über den Knopf
GenerateContext kann der Benutzer den Generierungs-Prozeß initialisieren, ausgehend vom
aktuellen HTML-Dokument.
7.1.1.4 Die Klasse ManuallyOrAutomaticallyChooser
Die Klasse ManuallyOrAutomaticallyChooser ist als abstract implementiert, kann also
selbst nicht instanziiert werden. Sie bildet die Basis für die Ansichten, in denen der Benutzer
entscheiden kann, ob und inwiefern er den nächsten Schritte der Generierung selbst ausführen
oder ihn den Automatismen des Generierungs-Werkzeuges überlassen möchte. Zusätzlich
werden die Ergebnisse des letzten Schrittes angezeigt, und es besteht die Möglichkeit, diese
zu verwerfen und den Schritt nochmals auszuführen.
Zu beachten ist hierbei, daß die Automatismen nur dann zur Verfügung stehen, wenn die
dafür notwendigen Beispiel- und Heuristik-Daten geladen wurden. Ist dies noch nicht
geschehen, so ist der Knopf zur automatischen Ausführung des nächsten Generierungs-
Schrittes deaktiviert, dafür ist der Knopf zum Laden der Beispiel- und Heuristik-Daten aktiv.
7.1.1.5 Die Klasse FindFormMoaChooser
Die Klasse FindFormMoaChooser erbt von ManuallyOrAutomaticallyChooser. Sie zeigt
die gewählte Startseite an und bietet dem Benutzer die Wahl, ob er sich selbst auf die Suche
nach einem Suchformular machen möchte, oder ob die Automatismen der Generierung ein
Suchformular finden und auswählen sollen.
7.1.1.6 Die Klasse ClassifyFormMoaChooser
Die Klasse ClassifyFormMoaChooser erbt von ManuallyOrAutomaticallyChooser. Sie
zeigt nach der Auswahl eines Suchformulars dieses an und bietet dem Benutzer die Wahl, ob
er die Klassifizierung der Suchfelder und, falls vorhanden, der Auswahlfelder und er in ihnen
enthaltenen Optionen manuell durchführen will, oder ob er sie den Automatismen des
Generators überlassen möchte. Zudem bietet sie die Option, die Auswahl rückgängig zu
machen und sich erneut auf die Suche nach einem Suchformular zu begeben. Des weiteren
kann die Vorbelegung der Felder des Formulars verändert werden.
82

7.1.1.7 Die Klasse SingleResultPathsMoaChooser
Die Klasse ListResultMoaChooser erbt von ManuallyOrAutomaticallyChooser. Sie zeigt
die nach der Auswahl und Analyse des Suchformulars verfügbaren Suchmöglichkeiten an und
bietet dem Benutzer die Wahl, ob er die Generierung der Pfade zur Extraktion der Werte von
Datenelementen aus Ergebnis-Dokumenten von Suchanfragen mit einem Treffer und den von
dort aus über Hyperlinks erreichbaren HTML-Dokumenten den Automatismen des Generator-
Werkzeuges überlassen möchte, oder ob er sie selbst durchführen will. Des weiteren kann der
Benutzer bei letzterer Option wählen, ob er die Daten für die Suchanfrage selbst eingeben
möchte, oder ob sie aus einem der auch von den Automatismen benutzten Generierungs-
Beispielen erzeugt werden sollen. Bei einer aus Beispieldaten erzeugten Anfrage kann die
Generierung der Pfade auf Wunsch automatisch erfolgen. Zudem bietet sie die Möglichkeit,
die im letzten Schritt durchgeführte Analyse des gewählten Suchformulars zu verwerfen und
sie erneut durchzuführen.
7.1.1.8 Die Klasse ListResultPathsMoaChooser
Die Klasse ListResultMoaChooser erbt von ManuallyOrAutomaticallyChooser. Sie zeigt
nach der Generierung der Pfade zur Extraktion der Werte von Datenelementen aus Ergebnis-
Dokumenten von Suchanfragen mit einem Treffer und den von dort aus über Hyperlinks
erreichbaren HTML-Dokumenten diese Pfade an und bietet dem Benutzer die Wahl, ob er die
Generierung der Pfade zur Extraktion der Werte von Datenelementen aus Ergebnis-
Dokumenten von Suchanfragen mit mehreren Treffern und den von dort aus über Hyperlinks
erreichbaren HTML-Dokumenten den Automatismen des Generator-Werkzeuges überlassen
möchte, oder ob er sie selbst durchführen will. Des weiteren kann der Benutzer bei letzterer
Option wählen, ob er die Daten für die Suchanfrage selbst eingeben möchte, oder ob sie aus
einem der auch von den Automatismen benutzten Generierungs-Beispielen erzeugt werden
sollen. Bei einer aus Beispieldaten erzeugten Anfrage kann die Generierung der Pfade auf
Wunsch automatisch erfolgen. Zudem bietet sie die Möglichkeit, die im letzten Schritt
generierten Pfade manuell zu ändern oder sie zu verwerfen und ihre Generierung erneut
durchzuführen.
7.1.1.9 Die Klasse ContextFinished
Die Klasse ContextFinished erbt von ManuallyOrAutomaticallyChooser. Sie bietet dem
Benutzer die Möglichkeit, die generierte Quellenbeschreibung zu speichern oder sie zu
verwerfen. Zudem stellt sie die Option zur Verfügung, die Generierung der Pfade zur
Extraktion von Werten von Datenelementen aus dem Ergebnis-Dokument einer Suche mit
mehreren Treffern und den vom dort auf über Hyperlinks erreichbaren HTML-Dokumenten
zu verwerfen und erneut durchzuführen oder diese Pfade manuell zu verändern.
7.1.1.10 Die Klasse ContextPreview
Die Klasse ContextPreview dient zur Anzeige der bisher generierten Teile der
Quellenbeschreibung. In dieser Vorschau hat der Benutzer nach einer Sicherheitsabfrage die
Möglichkeit, die Quellenbeschreibung direkt in ihrem Code zu verändern.
7.1.1.11 Die Klasse SearchFormFinder
Die Klasse SearchFormFinder dient der Darstellung von HTML-Dokumenten während der
Suche nach einem Suchformular. Sie bietet die Möglichkeit zur Extraktion eines oder aller in
einem HTML-Dokument enthaltenen Formulare und zeigt alle im Laufe des Suchvorganges
extrahierten in einer Liste an.
83

7.1.1.12 Die Klasse SearchFormDisplay
Die Klasse SearchFormDisplay dient der Anzeige eines Suchformulars innerhalb des
Auswahl- und Klassifizierungs-Vorganges. Dies beinhaltet sowohl die Darstellung des
Formulars in einer Browser-Ansicht als auch die anderer wichtiger das Formular betreffender
Daten wie den Pfad seines Wurzelknotens im HTML-Dokument und dessen URL oder seine
in ihrer standardmäßigen Einstellung festgehaltenen Felder.
7.1.1.13 Die Klasse SearchFormLister
Die Klasse SearchFormLister erbt von SearchFormDispaly. Sie dient während der Suche
nach einem Suchformular der Darstellung eines bestimmten Formulare in der Liste der
extrahierten und bietet die Möglichkeit zur Auswahl des angezeigten Suchformulars.
7.1.1.14 Die Klasse FixFieldsEditor
Die Klasse FixFieldsEditor bietet dem Benutzer die Möglichkeit, die Standard-Belegung
der Felder des ausgewählten Suchformulars zu verändern.
7.1.1.15 Die Klasse FieldDisplayLine
Die Instanzen der Klasse FieldDisplayLine repräsentieren innerhalb einer Instanz von
FixFieldsEditor ein einzelnes Eingabefeld des dort dargestellten Formulars.
7.1.1.16 Die Klasse SearchFieldClassifier
Die Klasse OptionFieldClassifier erbt von SerachFormDisplay. Sie zeigt das gewählte
Suchformular an und dient der Klassifizierung der in diesem enthaltenen Suchfelder nach dem
von ihnen als Kriterium angewendeten Datenelement.
7.1.1.17 Die Klasse SearchFieldClassifierLine
Die Klasse SearchFieldClassifierLine dient der Klassifizierung eines Suchfeldes nach
dem Datenelement, auf das der eingegebene Suchwert als Kriterium angewendet wird.
7.1.1.18 Die Klasse OptionFieldClassifier
Die Klasse OptionFieldClassifier erbt von SearchFormDisplay. Sie zeigt das gewählte
Suchformular an und dient der Zuordnung der in diesem enthaltenen Auswahlfelder zu den
Suchfeldern als Element- oder Verknüpfungs-Auswahl sowie der Klassifizierung der jeweils
enthaltenen Optionen. Dabei hat der Benutzer auch die Möglichkeit, ein Auswahlfeld als
Allgemeine Auswahl einzustufen.
7.1.1.19 Die Klasse OptionFieldClassifierPanel
Die Klasse OptionFieldClassifierPanel dient der Zuordnung eines einzelnen
Auswahlfeldes zu einem Suchfeld sowie der Klassifizierung der in ihm enthaltenen Optionen.
7.1.1.20 Die Klasse OptionClassifierLine
Die Klasse OptionClassifierLine dient der Klassifizierung einer einzelnen in einem
Auswahlfeld angezeigten Option nach dem von ihr repräsentierten Datenelement oder der von
ihr repräsentierten logischen Verknüpfung zweier Suchkriterien. Dabei hat der Benutzer
sowohl die Möglichkeit, ein Datenelement oder eine logische Verknüpfung aus einem
Auswahlfeld zu wählen, als auch die, selbst eines oder eine einzugeben.
84

7.1.1.21 Die Klasse SearchPanel
Die Klasse SearchPanel dient zur Darstellung eines Suchformulars für die während der
Generierung einzugebenden Suchanfragen. Es beinhaltet Suchfelder sowie Element- und
Verknüpfungs-Auswahlen des gewählten Formulars.
7.1.1.22 Die Schnittstelle SearchPanelHost
Die Schnittstelle SearchPanelHost garantiert einer enthaltenen Instanz von SearchPanel,
daß die Komponente zur Reaktion auf das Abschicken einer Suchanfrage fähig ist.
7.1.1.23 Die Klasse SearchPanelLine
Die Instanzen der Klasse SearchPanelLine repräsentieren innerhalb einer Instanz von
SearchPanel ein Suchfeld mit zugeordneter Element- und, falls vorhanden, Verknüpfungs-
Auswahl.
7.1.1.24 Die Klasse SearchPanelSimpleLine
Die Instanzen der Klasse SearchPanelLine repräsentieren innerhalb einer Instanz von
SearchPanel ein Suchfeld ohne zugeordnete Element- und Verknüpfungs-Auswahl. Sie
kommen zum Einsatz, wenn letztere beide nicht verfügbar sind.
7.1.1.25 Die Klasse SearchAutomationPanel
Die Klasse SearchAutomationPanel stellt bei geladenen Generierungs-Basisdaten die
Auswahl zwischen der manuellen Eingabe der Suchdaten und der Erzeugung der Anfrage aus
den Daten eines Generierungs-Beispiels zur Verfügung. Ist letztere Option gewählt, so kann
zum einem das verwendete Beispiel ausgewählt, zum anderen die automatische Generierung
von Pfaden in den einzelnen Informationsschichten aktiviert werden.
7.1.1.26 Die Klasse ResultPathsGenerator
Die Klasse ResultPathsGenerator ist als abstract implementiert, kann also nicht selbst
instanziiert werden. Sie bildet die Basis der Ansichten für die Generierung der Pfade zur
Extraktion der Werte von Datenelementen aus den Ergebnis-Dokumenten von Suchanfragen
und den von dort aus über Hyperlinks erreichbaren HTML-Dokumenten.
7.1.1.27 Die Klasse SingleResultPathsGenerator
Die Klasse SingleResultPathsGenerator erbt von ResultPathsGenerator und dient
speziell der Generierung der Pfade zur Extraktion der Werte von Datenelementen aus
Ergebnis-Dokumenten von Suchanfragen mit einem Treffer und den von dort aus über
Hyperlinks erreichbaren HTML-Dokumenten.
7.1.1.28 Die Klasse ListResultPathsGenerator
Die Klasse ListResultPathsGenerator erbt von ResultPathsGenerator und dient speziell
der Generierung der Pfade zur Extraktion der Werte von Datenelementen aus Ergebnis-
Dokumenten von Suchanfragen mit mehreren Treffern und den von dort aus über Hyperlinks
erreichbaren HTML-Dokumenten.
7.1.1.29 Die Klasse DataPathsEditor
Die Klasse DataPathsEditor bietet dem Benutzer die Möglichkeit, erzeugte Pfade zur
Extraktion der Werte von Datenelementen aus dem Ergebnis-Dokument einer Suchanfrage
und den von dort aus über Hyperlinks erreichbaren HTML-Dokumenten manuell zu
verändern.
85

7.1.1.30 Die Klasse LayerPathDisplay
Die Instanzen der Klasse LayerPathDisplay stellen innerhalb einer Instanz von
DataPathsEditor die Daten jeweils einer einzelnen Informationsschicht dar und bieten die
Möglichkeit, diese manuell zu ändern.
7.1.1.31 Die Klasse PathDisplayLine
Eine Instanz der Klasse PathDiaplayLine repräsentiert innerhalb einer Instanz von
LayerPathDiaplay den Pfad zur Extraktion der Werte eines bestimmten Datenelementes aus
der jeweiligen Informationsschicht. Dieser kann manuell geändert und getestet werden.
7.1.1.32 Die Schnittstelle DataPathsEditorHost
Die Schnittstelle DataPathsEditorHost garantiert einer Instanz von DataPathsEditor, daß
die diese enthaltende Komponente zum Speichern von manuell veränderten Pfaden zur
Extraktion der Werte von Datenelementen aus dem Ergebnis-Dokument einer Suchanfrage
und den von dort aus über Hyperlinks erreichbaren HTML-Dokumenten fähig ist.
7.1.1.33 Die Klasse LayerDisplay
Die Klasse LayerPathDisplay dient bei der manuellen Änderung von Pfaden zur Extraktion
der Werte von Datenelementen aus dem Ergebnis-Dokument einer Suchanfrage und den von
dort aus über Hyperlinks erreichbaren HTML-Dokumenten in einer Instanz von
DataPathsEditor der Darstellung einzelner Informationsschichten in der aus gängigen
Browsern gewohnten Ansicht sowie der Ansicht als Baum. Zudem kann der Quelltext des
HTML-Dokumentes angezeigt werden.
7.1.1.34 Die Klasse ContextChecker
Die Klasse ContextChecker dient der Überprüfung einer Erzeugten Quellenbeschreibung.
Sie Stellt eine Möglichkeit zur Eingabe einer Suchanfrage, zur Auswahl der gewünschten
Datenelemente und Beschränkung der Suche auf eine Maximalzahl von Ergebnissen zur
Verfügung. Nach der Bearbeitung der Anfrage werden die Ergebnisse in tabellarischer Form
angezeigt.
7.1.1.35 Die Klasse CheckerDataExtractor
Die Klasse CheckerDataExtraktor erbt von DataExtractor und überschreibt die Methoden
zur Benachrichtigung des umgebenden Objektes über den Status und den Abschluß der
Bearbeitung einer Suchanfrage in der Art, daß die umgebende Instanz von ContextChecker
benachrichtigt wird.
7.1.1.36 Die Klasse DummyTableModel
Die Klasse DummyTableModel dient in den Instanzen von ContextChecker der Vorbelegung
der Ergebnis-Tabelle mit einem Inhalt, der seine Funktion erklärt. Dieser wird bis zum
Ausführen der ersten Suchanfrage angezeigt.
7.1.1.37 Die Klasse ResultTableModel
Die Klasse ResultTableModel implementiert die Schnittstelle TableModel und ermöglicht
damit die Darstellung der in einer Instanz von ProviderQueryResult enthaltenen
Ergebnisdaten in einer JTable-Komponente.
86

7.1.1.38 Die Klasse LayerPanel
Die Klasse LayerPanel dient der Darstellung einzelner Informationsschichten bei der
Generierung der Pfade zur Extraktion von Datenelementen aus Ergebnis-Dokumenten von
Suchanfragen und den von dort aus über Hyperlinks erreichbaren HTML-Dokumenten. Sie
beinhaltet die Anzeige des jeweiligen HTML-Dokumentes in einer Instanz von
LayerBrowsePanel und die Möglichkeiten zur Extraktion von Datenelementen und zur
Generierung von Pfaden sowie eine Liste der bisher generierten Pfade.
7.1.1.39 Die Klasse LayerBrowsePanel
Die Klasse LayerBrowsePanel erbt von TreeBrowsePanel. Sie verändert letztere Klasse in
ihrer Reaktion auf die Aktivierung eines Hyperlinks in einer der Ansichten. Die neue Seite
wird dadurch nicht mehr in derselben Maske geöffnet, sondern in einer neuen.
7.1.1.40 Die Klasse ListLayerPanel
Die Klasse ListLayerPanel erbt von LayerPanel. Sie dient speziell zur Darstellung des
Ergebnis-Dokumentes einer Suchanfrage mit mehreren Treffern und erweitert LayerPanel um
eine zusätzlich angezeigte Instanz von ListDataPanel zur Eingabe der speziell in dieser
Informationsschicht benötigten Daten.
7.1.1.41 Die Klasse ListDataPanel
Die Klasse ListDataPanel dient der Extraktion und Darstellung der speziell für das
Ergebnis-Dokument einer Suche mit mehreren Treffern notwendigen Daten. Sie bietet
Möglichkeiten zur Eingabe von Treffer-Anzahl, Treffer-Abstand und Treffer-Anfang sowie
dem Pfad des Hyperlinks zur nächsten Teil-Liste mit weiteren Treffern der Suchanfrage.
7.1.1.42 Die Klasse DataPathListLine
Die Instanzen der Klasse DataPathListLine repräsentieren in der Pfadliste einer Instanz von
LayerPanel einen einzelnen Pfad eines identifizierten Datenelementes und stellen dieses
samt dem aktuellen Wert und dem Pfad selbst dar. Zudem hat der Benutzer die Möglichkeit,
den Pfad zu löschen.
7.1.1.43 Die Klasse RegExGeneratorPanel
Die Klasse RegExGeneratorPanel stellt die Ansicht dar, in der das Generator-Werkzeug den
Benutzer zur Eingabe von regulären Ausdrücken für alle diejenigen Datenelemente auffordert,
die ihren Pfad mit einem anderen Datenelement gemeinsam haben.
7.1.1.44 Die Klasse RegExGeneratorLine
Die Klasse RegExGeneratorLine stellt die Eingabeaufforderung für einen regulären
Ausdruck zur Extraktion eines bestimmten Datenelementes aus einem Gesamtstring dar.
Dabei hat der Benutzer die Möglichkeit, den eingegebenen Ausdruck zu testen, um
sicherzustellen, daß seine Anwendung den gewünschten Teil des jeweiligen Gesamtstrings
extrahiert.
7.1.1.45 Die Klasse TreeBrowsePanel
Die Klasse TreeBrowsePanel stellt einen Browser dar, der das jeweils aktuelle HTML-
Dokument, bei dem es sich auch um eine Frame-Seite handeln kann, sowohl in der aus
anderen Browsern gewohnten Ansicht anzeigt als auch in einer Baum-Ansicht und einer Text-
Ansicht, die die im jeweiligen Schritt relevanten Inhalte darstellt. Zur Navigation können –
wie aus anderen Browsern gewohnt – Vorwärts- und Rückwärts-Funktionen sowie Hyperlinks
und die direkte Eingabe von URLs verwendet werden. Jede Instanz von TreeBrowsePanel
87

kann bei ihrer Erzeugung durch eine Instanz von javax.swing.JPanel oder einer
Unterklasse davon erweitert werden, die zusätzliche Funktionen enthält.
7.1.1.46 Die Klasse DummyTreeModel
Die Klasse DummyTreeModel dient in den Instanzen von TreeBrowsePanel der Vorbelegung
der Baum-Ansicht mit einem Inhalt, der dessen Funktion erklärt. Dieser wird bis zum Öffnen
des ersten HTML-Dokumentes angezeigt.
7.1.1.47 Die Klasse ParseTreeModel
Die Klasse ParseTreeModel implementiert die Schnittstelle TreeModel und ermöglicht damit
die Darstellung eines durch einen der Parser aus den Paket generatorAgent.tree erzeugten
Baumes in einer JTree-Komponente.
7.1.1.48 Die Klasse SetProxyWindow
Die Klasse SetProxyWindow stellt eine Maske zur Eingabe eines ProxyServers und des Ports
zur Verfügung, auf dem er angesprochen werden muß.
7.1.2 Das Werkzeug
Anhand der Generierung einer Quellenbeschreibung soll in diesem Abschnitt die
Funktionsweise des Generator-Werkzeuges erläutert werden. Diese erfolgt Schritt für Schritt
im Stil eines Wizzards, so daß der Benutzer immer nur diejenigen Informationen und
Eingabemöglichkeiten zur Verfügung hat, die im jeweiligen Schritt benötigt werden. Durch
einen Zurück-Knopf kann jeder Schritt verworfen und erneut ausgeführt werden.
Der aktuelle Stand der Quellenbeschreibung ist zu jedem Zeitpunkt der Generierung über den
Menüpunkt Window � ContextPreview abrufbar. Zudem können ohne weiteres mehrere
Quellenbeschreibungen parallel generiert werden. Dies erfolgt unabhängig voneinander, d.h.
die einzelnen Generierungsabläufe beeinflussen einander nicht.
Während bei der Generierung einer Quellenbeschreibung im GeneratorAgenten die URL der
Startseite durch die Anfrage des AnbieterAgenten vorgegeben ist, hat der Benutzer im
Generator-Werkzeug die Möglichkeit, diese selbst zu bestimmen. Dazu dient die in
Abbildung 7.1 dargestellte Ansicht. Wird das Werkzeug auf die Benachrichtigung eines
GeneratorAgenten hin geöffnet, also nur zur Lösung eines in dessen vollautomatischem
Generierungsablauf aufgetretenen Problems, so ist die Startseite wiederum durch die zu
bearbeitende Anfrage vorgegeben, so daß diese Ansicht nicht benötigt wird.
Ihr unterer Teil (die Browser-Ansicht) funktioniert wie ein gewohnter Browser. Im Adreß-
Feld kann eine URL eingegeben und das von ihr adressierte HTML-Dokument durch einen
Klick auf Open URL geladen werden. Ebenso kann über die im angezeigten HTML-
Dokument enthaltenen Hyperlinks navigiert werden. Die Knöpfe Back und Forward
erlauben das Vor- und Zurückspringen zwischen den bereits früher geladenen HTML-
Dokumenten. Durch einen Klick auf Show Code wird die Browser-Ansicht dazu veranlaßt,
statt dem aktuellen HTML-Dokument dessen Quelltext anzuzeigen, ein erneuter Klick auf
diesen Knopf (er trägt nun die Aufschrift Show HTML) schaltet zur Seitenansicht zurück.
Die beiden oberen Teile bieten dem Benutzer zusätzlich Informationen über das aktuell
angezeigte HTML-Dokument. Die Ansicht im linken oberen Teil (die Baum-Ansicht) zeigt
den zu der korrekten Version des aktuellen Dokumentes äquivalenten HTML-Baum an. Wird
hier ein einen Hyperlink repräsentierender Knoten oder einer seiner Kindknoten markiert, so
kann der Hyperlink durch den Knopf Open Link From Tree verfolgt werden. Die Ansicht im
rechten oberen Teil (die Text-Ansicht) präsentiert dem Benutzer die im jeweiligen Schritt der
Generierung relevanten Inhalte des aktuell angezeigten HTML-Dokumentes. Während der
Suche nach der Startseite sind dies die enthaltenen Hyperlinks, die auch über diese Ansicht
verfolgt werden können.
88

Abbildung 7.1: Ansicht zur Suche der Startseite
Abbildung 7.2: Auswahl des Modus für die Suche eines Formulars
89

Ist eine Seite gefunden, von der der Benutzer den Generierungsprozeß beginnen möchte, so
kann er diesen durch einen Klick auf den Knopf Create Context For Actual URL starten.
Hierdurch gelangt man in die in Abbildung 7.2 dargestellte Ansicht. Diese zeigt die gewählte
Startseite noch einmal an, wobei hier keine interaktiven Funktionen zur Verfügung stehen.
Der Benutzer kann nun wählen, ob er selbst über die Startseite und die darin enthaltenen
Hyperlinks navigieren und das zu verwendende Suchformular bestimmen möchte (Knopf
Manually), oder ob das Werkzeug diesen Schritt automatisch durchführen soll (Knopf
Automatically). Letztere Option ist nur nach dem Laden einer Basisdaten-Datei wählbar.
Dies geschieht durch den Knopf Load Source File und den durch diesen geöffneten Dialog
(siehe Abbildung 7.3).
Abbildung 7.3: Dialog zum Laden der Basisdaten-Datei
Wählt der Benutzer die Option Manually, so gelangt er in die in Abbildung 7.4 dargestellte
Ansicht. Ihr linker Teil entspricht von der Funktion her der Ansicht zur Auswahl der
Startseite, wobei die direkte Eingabe einer URL allerdings nicht möglich ist. Da das das
verwendete Suchformular enthaltende HTML-Dokument über Hyperlinks von der Startseite
aus erreichbar sein muß, kann nur über diese navigiert werden. Die Text-Ansicht zeigt die
jeweils im aktuell angezeigten Dokument enthaltenen Formulare an.
Über den Knopf Extract Forms können alle im aktuell angezeigten HTML-Dokument
enthaltenen Formulare extrahiert werden. Expand Forms expandiert in der Baum-Ansicht
alle diese Formulare, von wo aus sie einzeln durch Markierung des das FORM-Tag
repräsentierenden Knotens oder einer seiner direkten oder indirekten Kindknoten über den
Knopf Extract Selected Form extrahiert werden können.
Der rechte Teil der Ansicht zeigt alle bisher aus den besuchten HTML-Dokumenten
extrahierten Formulare und bietet dem Benutzer so einen Überblick. Über Discart Form kann
ein Formular verworfen und so aus der Übersicht entfernt werden. Der Knopf Choose Form
wählt das jeweilige Formular aus, und der Benutzer gelangt in die in Abbildung 7.5
dargestellte Ansicht.
Wurde die Option Automatically gewählt, so führt das Werkzeug die Suche und Auswahl des
Suchformulars selbständig durch. Der Benutzer gelangt direkt zu der in Abbildung 7.5
dargestellten Ansicht, wo ihm das Ergebnis des Schrittes angezeigt wird.
Hier wird das gewählte Formular noch einmal angezeigt, und der Benutzer kann wählen, ob er
es manuell analysieren möchte (Knopf Manually), oder ob das Generator-Werkzeug diesen
Schritt automatisch ausführen soll (Knopf Automatically). Letztere Option steht wiederum
nur dann zur Verfügung, wenn eine Basisdaten-Datei geladen wurde, was auch hier über den
Knopf Load Source File geschehen kann. Über Choose Again läßt sich die Auswahl des
Suchformulars rückgängig machen, und der Benutzer gelangt wieder in die in Abbildung 7.2
dargestellte Ansicht.
90

Abbildung 7.4: Ansicht zur Auswahl eines Suchformulars
Abbildung 7.5: Auswahl des Modus für die Analyse des Suchformulars
91

Zudem kann die standardmäßig Vorbelegung der einzelnen Felder des Formulars verändert
werden. Dies ist über das in Abbildung 7.6 dargestellte Fenster möglich. Dieses wird über den
Knopf Edit Form erreicht. Sein linker Teil zeigt das Formular in der aus einem Browser
gewohnten Form an. Im rechten Teil sind die in ihm enthaltenen Checkboxen, Radio-Knöpfe
und Auswahlfelder dargestellt. Sie können bedient werden, und eine gemachte Änderung läßt
sich durch den Knopf Actualize Form in das Formular übertragen. Der Knopf Update Form
überträgt sämtliche Änderungen in das Formular. Die Rückkehr in die Hauptansicht erfolgt
über die Knöpf Close oder Save Changes, wobei ersterer die gemachten Änderungen verwirft
und letzterer sie speichert.
Abbildung 7.6: Fenster zur Veränderung der Vorbelegung des Suchformulars
Abbildung 7.7: Ansicht zur Klassifizierung der Suchfelder in Standardeinstellung
92

Wählt der Benutzer die manuelle Analyse des Suchformulars, so kann er jedem der darin
enthaltenen Text-Felder zunächst das von diesen in der Standardeinstellung als Kriterium
angewandte Datenelement zuweisen. Dies geschieht in der in Abbildung 7.7 dargestellten
Ansicht. Deren oberer Teil zeigt wiederum das Formular an, die Zuweisung der
Datenelemente erfolgt über die Eingabefelder im unteren. Hier kann der Benutzer das
Datenelement entweder aus einer Auswahl wählen oder es selbst eingeben und über den
Knopf Add zur Auswahl hinzufügen, wobei es dann automatisch ausgewählt ist. Ist die
Zuweisung der Datenelemente zu den Suchfeldern abgeschlossen, so gelangt der Benutzer
über den Knopf Classification Finished zum nächsten Teilschritt.
Enthält das Formular Auswahl-Felder, so besteht dieser in deren Zuweisung zu den
Suchfeldern, ihrer Klassifizierung als Element- oder Verknüpfungs-Auswahl und der
Klassifizierung der jeweils enthaltenen Optionen. Dies geschieht in der in Abbildung 7.8
dargestellten Ansicht. Der obere Teil zeigt wiederum das Formular an. Im unteren ist für jedes
Auswahl-Feld ein Register vorhanden, das mit dessen Name betitelt ist.
Jedes Register zeigt in seinem oberen Teil das jeweilige Auswahl-Feld an. Hier kann
festgelegt werden, ob es sich um eine Element- oder ein Verknüpfungs-Auswahl handelt, oder
um keines von beidem. Hier kann auch angegeben werden, das Verhalten welcher Suchfeldes
das Auswahl-Feld beeinflußt, wobei die einzelnen Suchfelder sowie die zusätzlichen
Optionen Alle und Keines zur Verfügung stehen. Im unteren Teil sind die in dem Auswahl-
Feld enthaltenen Optionen dargestellt, denen der Benutzer eine Bedeutung zuweisen kann.
Diese kann entweder aus einer Auswahl gewählt, oder aber von ihm selbst eingeben und über
den Knopf Add zur Auswahl hinzufügen werden, wobei sie dann automatisch ausgewählt ist.
Ist eine Basisdaten-Datei geladen, so werden die Bedeutungen der Suchfelder, die
Klassifizierung der Auswahl-Felder, ihre Zuordnung zu den Suchfeldern und die Bedeutung
der in ihnen enthaltenen Optionen vorbelegt, sofern die automatische Erkennung erfolgreich
ist. Als unknown eingestufte Suchfelder und Optionen werden am Ende der Klassifizierung
entfernt, da sie ohne Kenntnis ihrer Bedeutung ohne weiteren Nutzen sind.
Abbildung 7.8: Ansicht zur Klassifizierung der Auswahlfelder und ihrer Optionen
93

Abbildung 7.9: Auswahl des Modus für die Generierung der Pfade für Suchen mit einem Treffer
Über den Knopf Classification Finished gelangt der Benutzer in die in Abbildung 7.9
dargestellte Ansicht. Die Entscheidung für die automatische Analyse des Suchformulars führt
ihn direkt dorthin.
Abbildung 7.10: Ansicht zu Eingabe oder Auswahl der Suchkriterien
94

Diese Ansicht zeigt im oberen Teil das Suchformular, so wie es für die Anwendung zur
Verfügung steht. Der Benutzer kann wählen, ob er die Generierung der Pfade zur Extraktion
der Werte von Datenelementen aus dem Ergebnis-Dokument einer Suche mit einem Treffer
und den von dort aus über Hyperlinks erreichbaren HTML-Dokumenten manuell ausführen
möchte (Knopf Manually), oder ob das Generator-Werkzeug diesen Schritt automatisch
durchführen soll (Knopf Automatically). Auch hier steht letztere Option nur dann zur
Verfügung, wenn eine Basisdaten-Datei geladen ist, was auch hier über den Knopf Load
Source File möglich ist. Ist der Benutzer mit dem Ergebnis der Analyse des Suchformulars
nicht zufrieden, so kann er diese erneut durchführen, indem er über den Knopf Change
Search Data zu der in Abbildung 7.5 dargestellten Ansicht zurückspringt.
Wählt der Benutzer die Option manuell, so kann er in der in Abbildung 7.10 dargestellten
Ansicht die Suchanfrage entweder selbst in das Suchformular eingeben, oder er kann sich,
sofern eine Basisdaten-Datei geladen ist, für die Verwendung eines Generierungs-Beispieles
entscheiden. Die aus dem gewählten Beispiel generierte Suchanfrage wird ihm im Formular
angezeigt. In diesem Fall kann er zudem die automatische Suche nach den Werten von
Datenelementen in den einzelnen Informationsschichten aktivieren. Die Suche wird über den
Knopf Perform Search durchgeführt, und der Benutzer gelangt in die in Abbildung 7.11
dargestellte Ansicht.
Diese Ansicht enthält für jede Informationsschicht ein Register. Im oberen Teil eines solchen
wird das HTML-Dokument der jeweiligen Schicht in Browser-, Baum- und Text-Ansicht
dargestellt. Der untere enthält die zur Generierung von Pfaden benötigten Knöpfe und
Eingabefelder sowie eine Liste der bisher erzeugten Pfade.
Die Aktivierung eines Hyperlinks in der Browser-Ansicht öffnet eine neue
Informationsschicht mit dem durch diesen adressierten HTML-Dokument. Dies läßt sich auch
durch die Markierung eines einen Hyperlink repräsentierenden Knotens in der Baum-Ansicht
und den Klick auf den Knopf Create Layer erreichen. Jeder Informationsschicht bis auf die
des Ergebnis-Dokumentes kann über den Knopf Discart Layer verworfen werden.
Abbildung 7.11: Ansicht zur Generierung von Informationsschichten und Pfaden
95

Die Generierung der Pfade erfolgt durch die Markierung eines Textstückes in der Browser-
oder Text-Ansicht, dessen Extraktion durch den Knopf Extract Data, die Auswahl oder
Eingabe des Datenelementes, zu dem der extrahierte Wert gehört, und den anschließenden
Klick auf den Knopf Create Path, durch den der Pfad erzeugt wird, der den extrahierten Wert
im HTML-Dokument der Informationsschicht adressiert. Ist der Wert mehrfach im Dokument
enthalten, so werden mehrere Pfade erzeugt. Die bisher generierten Pfade werden in der Liste
oberhalb der Knöpfe und Eingabefelder zu ihrer Erzeugung angezeigt und können jeweils
über den Knopf Discart Path verworfen werden.
Über den Knopf Refine Your Search kann der Benutzer zur Eingabe der Suchanfrage
zurückspringen (Ansicht in Abbildung 7.10). Der Schritt wird durch einen Klick auf
Generation Finished abgeschlossen. Anschließend prüft das Generator-Werkzeug, ob in
einer der Informationsschichten ein Pfad existiert, der mehrerer Werte unterschiedlicher
Datenelemente adressiert. Falls nicht, gelangt der Benutzer in die in Abbildung 7.13
dargestellte Ansicht. Falls aber mindestens ein solcher Pfad gefunden wird, so wird der
Benutzer in der in Abbildung 7.12 dargestellten Ansicht ausgefordert, diese Pfade um
reguläre Ausdrücke zu ergänzen, die die Extraktion der Werte der einzelnen Datenelemente
aus den durch die fraglichen Pfade adressierten Gesamtstrings erlauben.
Der Benutzer kann den jeweils eingegebenen Regulären Ausdruck über den Knopf Test
RegEx testweise auf den Gesamtstring ausführen und anhand des Ergebnisses feststellen, ob
er das gewünschte Ergebnis liefert, also ob der gewünschte Wert extrahiert wird. Ist eine
Basisdaten-Datei geladen, so werden die Eingabefelder mit automatisch generierten
Regulären Ausdrücken vorbelegt. Über den Knopf Finished kann der Benutzer diesen
Teilschritt beenden und gelangt in die in Abbildung 7.13 dargestellte Ansicht. Wählt er die
automatische Generierung der Pfade, gelangt er direkt dorthin.
Abbildung 7.12: Ansicht zur Ergänzung der Pfade um Reguläre Ausdrücke
Hier werden die in den einzelnen Informationsschichten durch die generierten Pfade
extrahierbaren Datenelemente sowie die Pfade selbst angezeigt. Der Benutzer kann wählen,
ob er die Generierung der Pfade zur Extraktion der Werte von Datenelementen aus dem
Ergebnis-Dokument einer Suche mit mehreren Treffern und den von dort aus über Hyperlinks
96

erreichbaren HTML-Dokumenten manuell ausführen möchte (Knopf Manually), oder ob das
Generator-Werkzeug diesen Schritt automatisch durchführen soll (Knopf Automatically).
Auch hier steht letztere Option nur dann zur Verfügung, wenn eine Basisdaten-Datei geladen
ist, was auch hier über den Knopf Load Source File möglich ist.
Abbildung 7.13: Auswahl des Modus für die Generierung der Pfade für Suchen mit mehreren
Treffern
Durch den Knopf Change On Result können die generierten Informationsschichten und
Pfade insgesamt verworfen werden, und der Benutzer gelangt zurück zu der in Abbildung 7.9
dargestellten Ansicht zur Auswahl des Suchmodus.
Über den Knopf Edit Paths gelangt der Benutzer in das in Abbildung 7.14 dargestellte
Fenster, wo er die Pfade manuell ändern und anpassen kann.
Abbildung 7.14: Fenster zur manuellen Änderung der Pfade
Ein angepaßter Pfad kann über den Knopf Test Path testweise angewendet werden, wobei der
Benutzer anhand des extrahierten Wertes seine korrekte Funktion prüfen kann. Dessen
Anzeige erfolgt in einem PopUp der in Abbildung 7.15 Form. Ist der extrahierte Wert nicht
mehr korrekt, so kann der Pfad über Reset Path auf den Ausgangswert zurückgesetzt werden.
97

Abbildung 7.15: Anzeige des durch einen Pfad extrahierten Textstückes
Abbildung 7.16: Fenster zur Anzeige einer Informationsschicht
Durch einen Klick auf Display Layer kann sich der Benutzer das HTML-Dokument der
jeweiligen Informationsschicht in dem in Abbildung 7.16 dargestellten Fenster in Browser-
und Baum-Ansicht anzeigen lassen. Die Text-Ansicht entfällt hier, da das Fenster lediglich
der Anzeige dient und daher keine für Interaktionen relevanten Inhalte besitzt.
Die Anpassung der Pfade läßt sich durch die Knöpfe Close oder Save Changes beenden.
Beide schießen das Fenster, ersterer führt zur Verwerfung der Änderungen, zweiterer
speichert sie.
Abbildung 7.17: Ansicht zu Eingabe oder Auswahl der Suchkriterien
98

Wählt der Benutzer Manually, so kann er in der in Abbildung 7.17 dargestellten Ansicht die
Suchanfrage entweder selbst in das Suchformular eingeben, oder er kann sich, sofern eine
Basisdaten-Datei geladen ist, für die Verwendung eines Generierungs-Beispieles entscheiden.
Die aus dem gewählten Beispiel generierte Suchanfrage wird ihm im Formular angezeigt. In
diesem Fall kann er zudem die automatische Suche nach den Werten von Datenelementen in
den einzelnen Informationsschichten aktivieren. Die Suche wird über den Knopf Perform
Search durchgeführt, und der Benutzer gelangt in die in Abbildung 7.18 dargestellte Ansicht.
Diese Ansicht enthält für jede Informationsschicht ein Register. Im oberen Teil eines solchen
wird das HTML-Dokument der jeweiligen Schicht in Browser-, Baum- und Text-Ansicht
dargestellt. Der untere enthält die zur Generierung von Pfaden benötigten Knöpfe und
Eingabefelder sowie eine Liste der bisher erzeugten Pfade.
Die Aktivierung eines Hyperlinks in der Browser-Ansicht öffnet eine neue
Informationsschicht mit dem durch diesen adressierten HTML-Dokument. Dies läßt sich auch
durch die Markierung eines einen Hyperlink repräsentierenden Knotens in der Baum-Ansicht
und den Klick auf den Knopf Create Layer erreichen. Jeder Informationsschicht bis auf die
des Ergebnis-Dokumentes kann über den Knopf Discart Layer verworfen werden.
Die Generierung der Pfade erfolgt durch die Markierung eines Textstückes in der Browser-
oder Text-Ansicht, dessen Extraktion durch den Knopf Extract Data, die Auswahl oder
Eingabe des Datenelementes, zu dem der extrahierte Wert gehört, und den anschließenden
Klick auf den Knopf Create Path, durch den der Pfad erzeugt wird, der den extrahierten Wert
im HTML-Dokument der Informationsschicht adressiert. Ist der Wert mehrfach im Dokument
enthalten, so werden mehrere Pfade erzeugt. Die bisher generierten Pfade werden in der Liste
oberhalb der Knöpfe und Eingabefelder zu ihrer Erzeugung angezeigt und können jeweils
über den Knopf Discart Path verworfen werden.
Das Register der Informationsschicht des Ergebnis-Dokumentes enthält zusätzlich Felder zur
Eingabe der Anzahl der in einem Teil der Ergebnisliste angezeigten Treffer sowie ihren
Beginn und Abstand im zu diesem äquivalenten Baum. Zusätzlich kann der Pfad zum den
Hyperlink zum nächsten Teil der Ergebnisliste repräsentierenden Knoten angegeben werden.
Dies ist durch die Markierung eines einen Hyperlink repräsentierenden Knotens in der Baum-
Ansicht und den anschließenden Klick auf Take Marked Node As Link To Next List
möglich, oder durch die Verfolgung eines Hyperlinks in der Browser-Ansicht und einen Klick
auf Is Next List im Register der sich daraufhin öffnenden Informationsschicht.
Findet der Benutzer eine Informationsschicht mit Detail-Informationen zu einem der Treffer
der Suche, die dem Ergebnis-Dokument der Suche mit einem Treffer gleicht, so kann er die
erneute Generierung der Pfade umgehen, indem er über den Knopf Reuse Layers die dort
erzeugten Pfade wiederverwendet.
Über den Knopf Refine Your Search kann der Benutzer zur Eingabe der Suchanfrage
zurückspringen (Ansicht in Abbildung 7.17). Der Schritt wird durch einen Klick auf
Generation Finished abgeschlossen. Anschließend prüft das Generator-Werkzeug, ob in
einer der Informationsschichten ein Pfad existiert, der mehrere Werte unterschiedlicher
Datenelemente adressiert. Falls nicht, gelangt der Benutzer in die in Abbildung 7.13
dargestellte Ansicht. Falls aber mindestens ein solcher Pfad gefunden wird, so wird der
Benutzer in der in Abbildung 7.12 dargestellten Ansicht ausgefordert, diese Pfade um
Reguläre Ausdrücke zu ergänzen, die die Extraktion der Werte der einzelnen Datenelemente
aus den durch die fraglichen Pfade adressierten Gesamtstrings erlauben.
Der Benutzer kann den jeweils eingegebenen Regulären Ausdruck über den Knopf Test
RegEx testweise auf den Gesamtstring ausführen und anhand des Ergebnisses feststellen, ob
er das gewünschte Ergebnis liefert, also ob der gewünschte Wert extrahiert wird. Die Anzeige
des extrahierten Teilstrings erfolgt in einem PopUp der in Abbildung 7.20 dargestellten Form.
Ist eine Basisdaten-Datei geladen, so werden die Eingabefelder mit automatisch generierten
Regulären Ausdrücken vorbelegt. Über den Knopf Finished kann der Benutzer diesen
99

Teilschritt beenden und gelangt in die in Abbildung 7.21 dargestellte Ansicht. Wählt er die
automatische Generierung der Pfade, gelangt er direkt dorthin.
Abbildung 7.18: Ansicht zur Generierung von Informationsschichten und Pfaden
Abbildung 7.19: Ansicht zur Ergänzung der Pfade um Reguläre Ausdrücke
Die in Abbildung 7.21 dargestellte Ansicht zeigt dem Benutzer die im letzten Schritt
generierten Informationsschichten und die aus diesen durch die erzeugten Pfade
extrahierbaren Datenelemente sowie die Pfade selbst an.
Durch den Knopf Change List Result können die generierten Informationsschichten und
Pfade insgesamt verworfen werden, und der Benutzer gelangt zurück zu der in Abbildung
7.13 dargestellten Ansicht zur Auswahl des Generierungs-Modus.
100

Abbildung 7.20: Anzeige des durch eine Regulären Ausdruck aus einem Gesamtstring
extrahierten Teilstrings
Über den Knopf Edit Paths gelangt der Benutzer in das in Abbildung 7.22 dargestellte
Fenster, wo er die Pfade manuell ändern und anpassen kann. Ein angepaßter Pfad kann über
den Knopf Test Path testweise angewendet werden, wobei der Benutzer anhand des
extrahierten Wertes seine korrekte Funktion prüfen kann. Ist der extrahierte Wert nicht mehr
korrekt, so kann der Pfad über Reset Path auf den Ausgangswert zurückgesetzt werden.
Abbildung 7.21: Ansicht am Ende des Generierungsablaufes
Durch einen Klick auf Display Layer kann sich der Benutzer das HTML-Dokument der
jeweiligen Informationsschicht in einem weiteren Fenster in Browser- und Baum-Ansicht
anzeigen lassen. Die Text-Ansicht entfällt hier, da das Fenster lediglich der Anzeige dient und
daher keine für Interaktionen relevanten Inhalte besitzt.
101

Die Anpassung der Pfade läßt sich durch die Knöpfe Close oder Save Changes beenden.
Beide schießen das Fenster, ersterer führt zur Verwerfung der Änderungen, zweiterer
speichert sie.
Abbildung 7.22: Fenster zur manuellen Änderung der Pfade
Der Knopf Edit Context öffnet nach einer Sicherheitsabfrage ein Fenster, in dem die
generierte Quellenbeschreibung direkt manuell verändert werden kann. Dies ist in Abbildung
7.23 dargestellt.
Abbildung 7.23: Fenster zur manuellen Änderung der Quellenbeschreibung
102

Über den Knopf Save Context gelangt der Benutzer in den in Abbildung 7.24 dargestellten
Dialog zum Speichern der generierten Quellenbeschreibung, über Close Context kann er sie
insgesamt verwerfen.
Abbildung 7.24: Dialog zum Speichern einer generierten Quellenbeschreibung
Über den Knopf Test Context kann der Benutzer das in Abbildung 7.25 dargestellte Fenster
zum Test der soeben erstellten Quellenbeschreibung öffnen. Die im oberen Bereich
eingegebenen Suchanfragen werden ausgewertet und die Ergebnisse im unteren Bereich in
tabellarischer Form präsentiert.
Abbildung 7.25: Fenster zum Testeinsatz der erzeugten Quellenbeschreibung
103

7.2 Das Basisdaten-Werkzeug
Das Basisdaten-Werkzeug stellt einen Editor für die Beispiel- und Heuristik-Daten dar, die für
die vollautomatische Generierung von Quellenbeschreibungen benötigt werden. Insbesondere
wird durch den Einsatz eines Editors sichergestellt, daß diese Daten korrekt formatiert und
damit für den Generator lesbar sind. Gleichzeitig muß der Benutzer sich keinerlei Gedanken
mehr um diese Formatierung machen. In diesem Abschnitt wird zunächst die Architektur des
Editors und anschließend seine Funktion vorgestellt.
7.2.1 Das Paket generatorAgent.dataEditor
Das Paket generatorAgent.dataEditor beinhaltet die vom Editor benötigten Klassen.
Diese umfassen sowohl die Komponenten zum Einlesen und Speichern von Basisdaten-
Dateien als auch die zur Darstellung, Eingabe und Änderung der Daten. Verwendet werden
Klassen aus den Paketen generatorAgent, generatorAgent.util und
generatorAgent.tree.
7.2.1.1 Die Klasse GenerateDataEditor
Die Klasse GenerateDataEditor bildet die Basis des Editors. Sie enthält die Funktionen zum
Laden und Speichern von Basisdaten-Dateien und hält die Daten der gerade geöffneten.
7.2.1.2 Die Klasse EditorMain
Die Klasse EditorMain stellt den Rahmen der Benutzeroberfläche des Editors dar. Sie stellt
Menus und weitere Grundfunktionen wie eine Statusleiste zur Verfügung.
7.2.1.3 Die Klasse SrExampleEditor
Die Klasse SrExampleEditor stellt eine Maske für die Eingabe und Änderung eines Satzes
von Beispiel-Werten für die Generierung der Pfade im Ergebnis-Dokument von Suchanfragen
mit einem Treffer zur Verfügung.
7.2.1.4 Die Klasse LrExampleEditor
Die Klasse LrExampleEditor stellt eine Maske für die Eingabe und Änderung eines
Beispiel-Suchwertes sowie einer Gruppe von Sätzen von Beispiel-Werten (wahrscheinliche
Treffer) für die Generierung der Pfade im Ergebnis-Dokument von Suchanfragen mit
mehreren Treffern zur Verfügung.
7.2.1.5 Die Klasse ElementListEditPanel
Die Klasse ElementListEditPanel stellt eine Maske zur Verwaltung einer Gruppe von
Werten zur Verfügung.
7.2.1.6 Die Klasse ElementValueEditPanel
Die Klasse ElementValueEditPanel stellt eine Maske zur Verwaltung einer Gruppe von
Datenelementen mit jeweils mehreren zugeordneten Werten zur Verfügung.
7.2.1.7 Die Klasse ElementValueList
Die Klasse ElementValueList realisiert eine Liste von Werten. Diese können innerhalb der
Liste verändert und gelöscht werden. Zudem ist die Reihenfolge der Werte änderbar, indem
einzelne nach oben oder unten verschoben werden können.
7.2.1.8 Die Klasse ElementValueListLine
Die Instanzen der Klasse ElementValueListLine bilden die einzelnen Zeilen der Liste in
einer Instanz von ElementValueList.
104

7.2.1.9 Die Klasse StandardMetaDataLine
Die Klasse StandardMetaDataLine stellt eine Komponente zur abgesicherten Änderung
eines Wertes dar. Die Absicherung erfolgt über die Möglichkeit, eine fehlerhafte Änderung
rückgängig zu machen.
7.2.1.10 Die Schnittstelle StatusBarHost
Die Schnittstelle StatusBarHost garantiert einer Komponente den Zugriff auf die Statusleiste.
7.2.2 Das Werkzeug
Das Basisdaten-Werkzeug dient der Eingabe und Änderung der für die Automatismen der
Generierung notwendigen Beispiel- und Heuristik-Daten (siehe Anhang B). In diesem
Abschnitt werden die einzelnen Ansichten des Werkzeuges sowie die Bedeutung der darin
änderbaren Daten erklärt.
Abbildung 7.26: Ansicht zur Eingabe und Änderung eines Generierungs-Beispieles für Suchen
mit einem Treffer
Die in Abbildung 7.26 dargestellte Ansicht dient der Eingabe und Änderung von Beispielen
zur Generierung der Pfade zur Extraktion der Werte von Datenelementen aus dem Ergebnis-
Dokument einer Suche mit einem Treffer und den von dort aus über Hyperlinks erreichbaren
HTML-Dokumenten. Jedes Beispiel wird in einem Register angezeigt und kann über Delete
Example gelöscht werden. Der Knopf Add New Example fügt ein neues leeres Register zur
Eingabe eines neuen Beispiels hinzu, Delete All Examples löscht alle Beispiele.
Abbildung 7.27: PopUp zur Änderung bestehender Werte
105

Die Eingabe eines neuen Datenelementes erfolgt über das Feld New Data Element. Über das
Feld New Element Value können zu dem gerade ausgewählten Datenelement Werte
hinzugefügt werden. In der Liste darunter werden die vorhandenen Werte angezeigt und
können gelöscht und verändert werden. Die Änderung erfolgt über ein PopUp der in
Abbildung 7.27 dargestellten Form. Zusätzlich kann die Reihenfolge der Werte geändert
werden. Dies ist notwendig, da immer der erste Wert bei der Generierung von Suchanfragen
benutzt wird. Das Vorhandensein mehrerer Werte wird dadurch erforderlich, daß ihre
Darstellung auf der Internetseite eines untersuchten Anbieters in mehreren Formen erfolgen
kann (beispielsweise kann der Name als Vorname Nachname oder Nachname, Vorname
angezeigt werden).
Abbildung 7.28: Ansicht zur Eingabe und Änderung eines Generierungs-Beispieles für Suchen
mit mehreren Treffern
Die in Abbildung 7.28 dargestellte Ansicht dient der Eingabe und Änderung von Beispielen
zur Generierung der Pfade zur Extraktion der Werte von Datenelementen aus dem Ergebnis-
Dokument einer Suche mit mehreren Treffern und den von dort aus über Hyperlinks
erreichbaren HTML-Dokumenten. Jedes Beispiel wird in einem Register angezeigt und kann
über Delete Example gelöscht werden. Der Knopf Add New Example fügt ein neues leeres
Register zur Eingabe eines neuen Beispiels hinzu, Delete All Examples löscht alle Beispiele.
Diese Beispiele bestehen aus mehreren Teil-Beispielen, die je einen wahrscheinlichen Treffer
einer Suche nach dem unter Generate Search Value angegebenen Suchbegriff darstellen. Die
Register zur Anzeige und Bearbeitung der einzelnen Teil-Beispiele gleichen denen für
Eingabe und Änderung von Beispielen zur Generierung der Pfade zur Extraktion der Werte
von Datenelementen aus dem Ergebnis-Dokument einer Suche mit einem Treffer und den von
dort aus über Hyperlinks erreichbaren HTML-Dokumenten: Die Eingabe eines neuen
Datenelementes erfolgt über das Feld New Data Element. Über das Feld New Element Value
können zu dem gerade ausgewählten Datenelement Werte hinzugefügt werden. In der Liste
darunter werden die vorhandenen Werte angezeigt und können gelöscht und verändert
werden.
106

Abbildung 7.29: Ansicht zur Eingabe der für dieses Generierungs-Beispiel zu verwendenden
Suchfelder
Zusätzlich muß bei Beispielen zur Generierung der Pfade zur Extraktion der Werte von
Datenelementen aus dem Ergebnis-Dokument einer Suche mit mehreren Treffern und den von
dort aus über Hyperlinks erreichbaren HTML-Dokumenten festgelegt werden, auf welche
Datenelemente der Beispiel-Suchbegriff als Kriterium angewendet werden kann. Dies erfolgt
in dem eigenen Register Search Fields. Die Eingabe eines neuen Datenelementes erfolgt über
das Feld New Search Field. In der Liste darunter werden die vorhandenen Datenelemente
angezeigt und können gelöscht und verändert werden. Die Änderung erfolgt über ein PopUp.
Zusätzlich kann die Reihenfolge der Datenelemente geändert werden.
Abbildung 7.30: Ansicht zur Änderung bestimmter Basiswerte
Der Bereich zur Eingabe und Änderung der Metadaten ist in Abbildung 7.29 dargestellt und
hat mehrere Teile:
Unter Basic Data können Einzelwerte wie der Suchbegriff für Kein-Ergebnis-Suchen und der
Name von Freitext-Felder, der als Name eines Datenelementes in einem Generierungs-
107

Beispiel nicht auftritt, eingegeben und geändert werde. Hinzu kommen die Nested Elements,
wo Datenelemente angegeben werden können, deren Werte mit großer Wahrscheinlichkeit in
den Werten anderer Datenelemente enthalten sein können, und Element Selectivity zur
Eingabe der Selektivität der einzelnen Datenelemente sowie No Result Fields, wo festgelegt
wird, auf welche Datenelemente der angegeben Wert bei der Kein-Ergebnis-Suche als
Kriterium angewendet werden soll (siehe Abbildung 7.30).
Abbildung 7.31: Ansicht zur Eingabe der für die Kein-Ergebnis-Suche zu verwendenden
Suchfelder
Unter Form Heuristics werden die Heuristikdaten zur Erkennung der Optionen in Auswahl-
Feldern von Suchformularen angezeigt und können geändert werden. Sie sind unterteilt in die
für Element- (Register Option Field Heuristics, siehe Abbildung 7.32) und die für
Verknüpfungs-Auswahlen (Register Boolean Field Heuristics). Es können für jede Bedeutung
mehrere mögliche Werte der Option angegeben werden, etwa mehrere Sprachen.
Abbildung 7.32: Ansicht zur Eingabe von Heuristikwerten zur Erkennung der Bedeutung
einzelner Optionen in Auswahlfeldern
108

Unter RegEx Heuristics schließlich erfolgt die Eingabe und Änderung der Heuristikdaten für
die Generierung Regulärer Ausdrücke. Diese gliedern sich in eine Liste der Datenelemente,
deren Werte eine definierte Länge haben (Register Fix Length Data Elements), z.B. die ISBN-
Nummer, eine Liste von mit großer Wahrscheinlichkeit innerhalb der Werte von
Datenelementen auftretenden Interpunktionszeichen und Bindewörtern (Register Data Value
Interpunction, siehe Abbildung 7.33) sowie Listen von Datenelementen, die immer von
bestimmten Zeichenfolgen angeführt oder abgeschlossen werden, und diesen Zeichenfolgen
selbst (Register Left Bordered Data Elements und Right Bordered Data Elements).
Abbildung 7.33: Ansicht zur Eingabe von Zeichen und Bindewörtern, die mit hoher
Wahrscheinlichkeit innerhalb der Werte von Datenelementen auftreten
Über das Menu File lassen sich Beispieldaten-Dateien zum Ändern laden und anschließend
wieder speichern sowie neue eröffnen.
109

110

8. Evaluierung
Durch seine Fähigkeit zur Arbeit mit heutzutage im Internet weit verbreiteten Techniken wie
Frames, Page-Forwards und Sessions kann der im Rahmen dieser Arbeit implementierte
Wandler-Generator zur Analyse der Internetseiten vieler Online-Anbieter von Literatur
genutzt werden.
Die Grenzen der Automatik zeigen sich vor allem beim Auffinden eines geeigneten
Suchformulars, da eine Breitensuche über Hyperlinks – ausgehend von der Startseite – schnell
zu einer schwer überschaubar großen Anzahl von HTML-Dokumenten und Formularen führt.
Gerade bei kommerziellen Anbietern kommen hierbei durch die in der Regel große Anzahl
von Hyperlinks pro HTML-Dokument (amazon.de: > 50) selbst bei Eliminierung doppelt
gefundener URLs Probleme auf.
Ein weiteres Manko an Flexibilität gegenüber der durch das Werkzeug gestützten
Generierung stellt die Modifikation des gewählten Suchformulars dar. Während die
Automatik als allgemeine Auswahl klassifizierte Auswahlfelder immer in der vorgegebenen
Standardeinstellung beläßt, kann bei Verwendung des Werkzeuges die Funktion des
Formulars durch Änderung der vom Anfrage-Generator nicht genutzten Eingabefelder
(allgemeine Auswahlen, Checkboxen etc) stark beeinflußt werden. So lassen sich über das
erweiterte Suchformular der Universitätsbibliothek Karlsruhe beispielsweise durch
Veränderung der Katalog-Auswahl über ein Duzend verschiedene Anbieter von Literatur
anbinden. Diese Möglichkeit bleibt der Automatik verschlossen, da die Optionen allgemeiner
Auswahlen bei weitem zu vielfältig sind, um durch Heuristiken ergründbar zu sein.
Auf der anderen Seite stellt die Automatik innerhalb des Generierungs-Werkzeuges eine
große Erleichterung für den Benutzer dar. Gerade bei der Klassifizierung von
Auswahlfeldern, ihrer Zuordnung zu den Suchfeldern und der Klassifizierung der in ihnen
enthaltenen Optionen erweist sie sich als sehr hilfreich und zuverlässig.
Bei der Generierung der Pfade und regulären Ausdrücke zur Extraktion der Daten erfüllt die
Automatik ebenso zuverlässig ihren Dienst. Allerdings ist sie gerade in diesen beiden
Schritten der Generierung in hohem Maß von der Qualität der verfügbaren Basisdaten
abhängig. Ist keines der bekannten Suchbeispiele im Katalog des gerade untersuchten
Anbieters vorhanden, so kann die Generierung der Pfade nicht erfolgen, da kein Ergebnis-
Dokument mit enthaltenen bekannten Werten verfügbar ist.
Eine eingehende Evaluierung wurde durch die Anbindung zahlreicher Anbieter an das
UniCats-i-System durchgeführt, die Ergebnisse sind in [Steinhart 2004] nachzulesen.
111

112

9. Zusammenfassung und Ausblick
In diesem abschließenden Kapitel werden die Ergebnisse dieser Arbeit noch einmal
zusammengefaßt. Anschließend wird ein Ausblick auf Möglichkeiten zum weiteren Einsatz
der implementierten Komponenten und zu ihrer Erweiterung gegeben.
9.1 Zusammenfassung
Das Hauptziel dieser Arbeit war es, einen Wandler-Generator zu realisieren, der in der Lage
ist, auf einfache Art und Weise Quellenbeschreibungen zu generieren und umzusetzen, um
somit digitale Informationsquellen in das UniCats-i-System einzubinden.
Dabei sollte zum einen eine vollautomatische Generierung realisiert werden, die, durchgeführt
von einem Generatoragenten, das System bei Veränderungen an den Quellen von
administrativen Eingriffen unabhängig macht. Zum anderen sollte ein Werkzeug geschaffen
werden, das eine Generierung von Quellenbeschreibungen durch einen Benutzer ermöglicht,
wobei dieser in einem möglichst hohen Grad von automatischen Verfahren unterstützt wird
und im Idealfall nur eine Kontrollfunktion ausübt. Dies konnte durch die Umsetzung und
Automatisierung des Ansatzes Generation by Example erreicht werden, bei dem der Benutzer
lediglich eine ihm vertraute Beispielrecherche auf der Informationsquelle durchführt bzw.
eine solche von der Automatik auf Basis von Beispieldaten durchführen läßt. Der Wandler-
Generator erzeugt aus den dabei gewonnenen Informationen die vollständige
Quellenbeschreibung. Zusätzlich wurde eine Wandler-Komponente realisiert, die die
Quellenbeschreibungen zur Extraktion von Informationen aus der jeweils beschriebenen
Informationsquelle nutzt und perfekt auf den Wandler-Generator abgestimmt ist.
Die zweite wichtige Aufgabe war die Entwicklung regulärer Ausdrücke, die eine genaue
Heraustrennung einzelner Informationen aus einem Gesamtstring ermöglicht, um einzelne
Datenelemente punktgenau aus der Informationsquelle extrahieren zu können. Zu diesem
Zweck wurde eine reguläre Sprache entwickelt, deren Ausdrücke in die pfadbasierten
Extraktionsinformationen der Quellenbeschreibung integriert sind. Der Generator für diese
Ausdrücke ist in die Automatismen des Wandler-Generators eingeschlossen. Die Wandler-
Komponente enthält einen Interpreter, der die Ausdrücke zur Extraktion von Datenelementen
aus Gesamtstrings einsetzt.
Weiterhin sollte der Wandlergenerator so realisiert werden, daß zur Bedienung des Generators
wenig oder kein Expertenwissen vorausgesetzt werden muß. Dies konnte durch möglichst
einfache Sichten auf die komplexen Zusammenhänge des Wandlerumfelds erreicht werden,
wobei sich an manchen Stellen der Blick auf etwas komplexere Daten nicht vermeiden ließ.
Die Bedienung sollte zudem möglichst übersichtlich gestaltet werden, um so eine lange
Einarbeitungszeit für den Benutzer zu vermeiden. Dieses Ziel konnte durch die Umsetzung
des Wandler-Generators in Form eines Wizzards erreicht werden, der den Benutzer Schritt für
Schritt durch den Generierungsprozesses leitet und jeweils nur die im jeweiligen Schritt
gerade relevanten Informationen und Ansichten anzeigt.
Die Wandler-Komponente wird durch eine Quellenbeschreibung konfiguriert und somit in die
Lage versetzt, Suchanfragen an den beschriebenen Anbieter zu stellen und die Ergebnisse zu
Extrahieren. Hierbei konnte durch den Einsatz von Parallelität eine hohe Geschwindigkeit
erreicht werden.
Da Wandler-Generator und Wandler-Komponente plattformunabhängig betrieben werden
sollen, wurden sie vollständig in der Programmiersprache JAVA entwickelt; die
Quellenbeschreibung basiert auf XML. Somit die Plattformunabhängigkeit sichergestellt.
113

9.2 Ausblick
Der hier vorgestellte Wandler-Generator erlaubt – in Verbindung mit der Wandler-
Komponente – in erster Linie das Einbinden von digitalen Informationsquellen zur
Literatursuche in das UniCats-i-System. Es ist jedoch aufgrund der sehr allgemeinen
Beschaffenheit des Systems durchaus möglich, andere Einsatzfelder zu erschließen. Für ein
reibungsloses Funktionieren der Automatismen wären lediglich andere Basisdaten notwendig,
angepaßt auf das jeweilige Umfeld.
Weitere Gebiete sind durchaus denkbar, jedoch unterliegt der UniCats-i-Wandler momentan
noch der Einschränkung, daß ein Suchformular stets der Einstieg in die Informationsquelle
darstellen muß. Befreit man den Wandler von dieser Einschränkung, erschließen sich weitere
Einsatzfelder. Daher sollte in zukünftigen Entwicklungen sowohl der UniCats-i-Wandler als
auch der hier entwickelte Wandler-Generator erweitert und noch flexibler gemacht werden.
Beispielsweise könnten auf diese Weise Börsen- und Wetterdaten in regelmäßigen Intervallen
abgefragt und über Zwischenschritte dem Benutzer einer Anwendung angeboten werden, so
daß dieser über jeweils aktuelle Informationen verfügt, ohne selbst im Internet nach Ihnen
suchen zu müssen.
Des weiteren sollten Wandler-Generator und -Komponenten neben der bereits
implementierten Beherrschung von Frames und Sessions zur Arbeit mit weiteren Internet-
Technologien befähigt werden, die in der Zukunft auf den Seiten vieler Anbieter von Online-
Informationen Verwendung finden werden. Hier wären vor allem JavaScript, JSP uns ASP zu
nennen, aber auch Applets und Flash können eine Rolle spielen.
Auf der Seite der eingesetzten Basis-Techniken wäre eine Ergänzung der regulären
Ausdrücke um optionale Teile wünschenswert, da sich gezeigt hat, daß die Informationen
auch innerhalb der Internet-Seite eines Anbieters nicht immer komplett gleich strukturiert sind
und bisweilen Datenelemente fehlen. Die automatische Generierung kann allgemein noch
deutlich in ihrer Stabilität gesteigert werden, indem während des Vorgangs mehrere Ergebnis-
Dokumente untersucht und die Analyse-Resultate zu einer Quellenbeschreibung
zusammengeführt werden, deren Pfad- und reguläre Ausdrücke optionale Teile enthalten und
so mehrere ähnliche, aber leicht unterschiedliche Repräsentationen der gesuchten
Informationen abdecken.
Bei der automatischen Generierung besteht eine der wichtigsten Voraussetzungen darin, daß
die verwendeten Beispiel-Daten im Katalog des jeweiligen Anbieters vorhanden sind. Hier
ließe sich zumindest für die Anpassung des Wandlers an Veränderungen an der Internetseite
des Anbieters in der Form vorsorgen, als daß der Wandler bei erfolgreichen Anfragen einen
Teil der Suchergebnisse speichert, um sie bei einer späteren automatischen Anpassung als
Beispiel-Daten nutzen zu können.
114

Anhang
A Definition der Quellenbeschreibung
Zur individuellen Konfiguration des Wandlers auf die jeweiligen Anbieter werden
Quellenbeschreibungen genutzt. Diese haben folgende Struktur:
MetaData
SearchData
SearchCosts
SingleResultData
ListResultData
Der Bereich MetaData enthält allgemeine Informationen:
Name
TimeStamp
Costs
Separator
Data
• Name ist der Name der beschriebenen Informationsquelle, gewöhnlich die URL der
Startseite.
• TimeStamp gibt den Zeitpunkt an, an dem die Generierung der Quellenbeschreibung
abgeschlossen wurde.
• Costs enthält die Information, ob eine Suche in dieser Informationsquelle
kostenpflichtig ist. Falls ja, so sind die genauen Kosten dem Bereich SearchCosts zu
entnehmen.
• Separator stellt das Trennzeichen für Datenlisten dar.
• Data enthält eine Liste der insgesamt in dieser Informationsquelle verfügbaren
Datenelemente, mit denen die Ergebnisse einer Suche beschrieben werden.
Im Bereich SearchCosts werden bei Quellen, in denen die Suche nach Informationen
kostenpflichtig ist, die Kosten der Suche je Informationsschicht angegeben. Bei allen übrigen
Informationsquellen ist dieser Bereich leer:
Price
...
• Price stellt den Preis für den einmaligen Aufruf der Informationsschicht LayerName
dar. Dieser Eintrag ist für jede Informationsschicht einmal vorhanden.
115

Der Bereich SearchData beinhaltet die für die Suche bei dem beschriebenen Anbieter
notwendigen Informationen:
SearchURL
FixFields
Hidden
FormURL
FormPath
AvailableFields
FieldName
...
MultiName
Option
OptionData
• SearchURL gibt die URL an, an die die Formulardaten geschickt werden. Da dies nur
bei GET-Formularen korrekt funktioniert, wird diese Angabe nicht mehr benutzt.
• FixFields enthält die Belegung der Formularfelder, die bei einer Suche über die
Standardeinstellungen durch den Anfrage-Generator nicht verändert werden
(Auswahlen, Checkboxen, Radiobuttons).
• Hidden liefert die Information, ob das verwendete Suchformular versteckte Eingaben
enthält.
• FormURL gibt die URL des HTML-Dokumentes an, in dem das verwendete
Suchformular enthalten ist.
• FormPath enthält den Pfad des -Knotens in der Baumdarstellung dieses
HTML-Dokumentes.
• AvailableFields gibt die in den Standardeinstellungen des Formulars als
Suchkriterien nutzbaren Datenelemente an.
• FieldName gibt den Namen des Formularfelder, dem der Wert des Datenelementes
DataElement zugewiesen werden muß. Dieser Eintrag ist für jedes Datenelement in
AvailableFields einmal vorhanden.
• MultiName ist die systeminterne Bezeichnung für Freitext-Felder.
• Option gibt an, ob im verwendeten Formular eine erweiterte Suche unter
Einbeziehung von Element- und Verknüpfungs-Auswahlen verfügbar ist. Falls ja, so
sind die dafür notwendigen Daten in OptionData abgelegt. Falls nicht, ist dieser
Bereich leer.
• OptionData enthält die Informationen für eine erweiterte Suche unter Einbeziehung
von Element- und Verknüpfungs-Auswahlen (siehe nächster Absatz).
Der Teilbereich OptionSearchData von SearchData enthält die Informationen für eine
erweiterte Suche unter Einbeziehung von Element- und Verknüpfungs-Auswahlen:
FixFields
LinkAv
StandardLinkAv
StandardLink
LinkFields
Fields
FieldData
116

• FixFields enthält die Belegung der Formularfelder, die bei einer erweiterten Suche
durch den Anfrage-Generator nicht verändert werden (allgemeine Auswahlen,
Checkboxen, Radiobuttons).
• LinkAv gibt an, ob Verknüpfungs-Auswahlen verfügbar sind
• StandardLinkAv gibt an, ob die Standardeinstellung aller Verknüpfungs-Auswahlen
im Formular übereinstimmt.
• StandardLink enthält die Standardeinstellung aller Verknüpfungs-Auswahlen im
Formular, falls diese übereinstimmt.
• LinkFields gibt die Belegung der Verknüpfungsfelder des Formulars in
Standardeinstellung an.
• Fields enthält eine Liste der verfügbaren Suchfelder
• FieldData enthält die Informationen zur Belegung der zum Suchfeld FieldName
gehörigen Element- und, falls vorhanden, Verknüpfungs-Auswahl für die erweiterte
Suche (siehe nächster Absatz). Dieser Eintrag ist für jedes Feld aus Fields einmal
vorhanden.
Der Teilbereich "FieldName"Options von OptionSearchData enthält die Informationen für
die Belegung der zu den Suchfeld FieldName gehörigen Element- und, falls vorhanden,
Verknüpfungs-Auswahl:
Field
AvOptions
OptValue

Der Bereich SingleResultData enthält die Informationen zur Extraktion der Ergebnisdaten
aus dem Ergebnis-Dokument einer Suchanfrage mit einem Treffer und den von dort aus über
Hyperlinks erreichbaren HTML-Dokumenten:
ListAvData
ListBasePath
ListDataPath
Layers
AvData
Parent
AddressPath
BasePath
DataPath
• ListAvData enthält eine Liste der aus dem Ergebnis-Dokument einer Suchanfrage mit
einem Treffer extrahierbaren Datenelemente.
• ListBasePath stellt den Pfad zum Wurzelknoten ListResultHead des Teilbaumes des
zum Ergebnis-Dokument äquivalenten HTML-Baumes dar, in dem alle extrahierbaren
Datenelemente liegen.
• ListDataPath enthält den Pfad von ListResultHead zum Datenelement ListElement.
Dieser Eintrag ist für jedes in ListAvData aufgeführte Datenelement einmal
vorhanden.
• Layers enthält die Anzahl L der verfügbaren Informationsschichten, die vom
Ergebnis-Dokument über Hyperlinks erreichbar sind. Diese sind mit Layer1 bis
LayerL benannt.
• AvData enthält eine Liste der aus der Informationsschicht LayerName extrahierbaren
Datenelemente.
• Parent gibt den Namen der Informationsschicht an, die den Hyperlink zu dieser
enthält.
• AddressPath gibt den Pfad vom ResultHead in der Informationsschicht Parent zum
Hyperlink zu dieser Informationsschicht an.
• ResultBasePath stellt den Pfad zum Wurzelknoten ResultHead des Teilbaumes des
zum HTML-Dokument der Informationsschicht äquivalenten HTML-Baumes dar, in
dem alle extrahierbaren Datenelemente liegen.
• DataPath gibt den Pfad von ResultHead zum Datenelement Element. Dieser Eintrag
ist für jedes in AvData aufgeführte Datenelement einmal vorhanden.
Der Bereich ListResultData enthält die Informationen zur Extraktion der Ergebnisdaten aus
dem Ergebnis-Dokument einer Suchanfrage mit mehreren Treffern und den von dort aus über
Hyperlinks erreichbaren HTML-Dokumenten:
ListAvData
ListBasePath
RSI
RS
NOR
NextList
ListDataPath
Layers
118

AvData
Parent
AddressPath
BasePath
DataPath
• ListAvData enthält eine Liste der aus dem Ergebnis-Dokument einer Suchanfrage mit
mehreren Treffern extrahierbaren Datenelemente.
• ListBasePath stellt den Pfad zum Wurzelknoten ListResultHead des Teilbaumes des
zum Ergebnis-Dokument äquivalenten HTML-Baumes dar, unter dem die Liste der
Ergebnisse aufgefächert ist, sowie den Typ seiner Kindknoten, unter denen die
Teilbäume mit den einzelnen Ergebnissen liegen.
• RSI gibt den typspezifischen Index des Kindknotens von ListResultHead an, unter
dem das erste Ergebnis lieg
• RS ist der Abstand der typspezifischen Indizes der Kindknoten von ListResultHead, in
denen die Ergebnisse liegen.
• NOR gibt die Anzahl der Ergebnisse an, die in einer Teilliste enthalten sind.
• NextList gibt den Pfad zum Knoten mit dem Hyperlink an, der zum HTML-
Dokument mit der jeweils nächsten Teilliste von Ergebnissen führt, falls die
Suchanfrage mehr als NOR Treffer geliefert hat.
• ListDataPath enthält den Pfad des zu einem einzelnen Ergebnis gehörigen
Kindknotens von ListResultHead zum Datenelement ListElement des jeweiligen
Ergebnisses. Dieser Eintrag ist für jedes in ListAvData aufgeführte Datenelement
einmal vorhanden.
• Layers enthält die Anzahl L der verfügbaren Informationsschichten, die vom
Ergebnis-Dokument über Hyperlinks erreichbar sind. Diese sind mit Layer1 bis
LayerL benannt.
• AvData enthält eine Liste der aus der Informationsschicht LayerName extrahierbaren
Datenelemente.
• Parent gibt den Namen der Informationsschicht an, die den Hyperlink zu dieser
enthält.
• AddressPath gibt den Pfad vom ResultHead in der Informationsschicht Parent zum
Hyperlink zu dieser Informationsschicht an.
• ResultBasePath stellt den Pfad zum Wurzelknoten ResultHead des Teilbaumes des
zum HTML-Dokument der Informationsschicht äquivalenten HTML-Baumes dar, in
dem alle extrahierbaren Datenelemente liegen.
• DataPath gibt den Pfad von ResultHead zum Datenelement Element. Dieser Eintrag
ist für jedes in AvData aufgeführte Datenelement einmal vorhanden.
119

B Definition der Basisdaten für die Generierung
Die für die vollautomatische Generierung von Quellenbeschreibungen notwendigen
Basisdaten werden ebenfalls in einer Datei gespeichert. Diese hat folgende Struktur:
MultiName
Separator
Marker
NoResValue
Nested
Selectivity
NoResFields
FormHeuristics
RegExHeuristics
SingleResultGenData
ListResultGenData
• MultiName gibt den Namen für ein Freitext-Suchfeld an.
• Separator stellt das Trennzeichen für Datenlisten dar.
• Marker bezeichnet das Markierungszeichen für Alternativ-Werte von Datenelementen.
Es wird zur Wahrung der Eindeutigkeit benutzt, wenn mehr als ein Beispielwert für
ein Datenelement innerhalb eines Beispiels vorhanden ist.
• NoResValue gibt den Suchwert für die Kein-Ergebnis-Seite an.
• NoResFields stellt eine Liste von Datenelementen dar, auf die NoResValue als
Suchkriterium angewendet werden soll, geordnet nach absteigender Priorität.
• Nested enthält eine Liste der Datenelemente, für die eingebettete Treffer
wahrscheinlich sind, geordnet nach aufsteigender Wahrscheinlichkeit für einen
solchen.
• Selectivity enthält eine Liste verwendeter Datenelemente, geordnet nach
aufsteigender Selektivität.
Der Bereich FormHeuristics enthält die zur Analyse von Suchformularen notwendigen
Heuristikdaten:
AvFieldHeu
DEValues
AvBoolHeu
LOValues
• AvFieldHeu enthält eine Liste der Datenelemente, für deren Erkennung in Element-
Auswahlen Heuristikdaten vorhanden sind.
120

• DEValue gibt eine Liste möglicher Optionen einer Element-Auswahl an, die für das
Datenelement DataElement stehen können. Dieser Eintrag ist für jedes in AvFieldHeu
aufgeführte Datenelement einmal vorhanden.
• AvBoolHeu enthält eine Liste der logischen Verknüpfungen, für deren Erkennung in
Verknüpfungs-Auswahlen Heuristikdaten vorhanden sind.
• LOValue gibt eine Liste möglicher Optionen einer Verknüpfungs-Auswahl an, die für
die logische Verknüpfung LinkOption stehen können. Dieser Eintrag ist für jede in
AvBoolHeu aufgeführte logische Verknüpfung einmal vorhanden.
Der Bereich RegExHeuristics enthält die zur automatischen Generierung regulärer
Ausdrücke erforderlichen Heuristikdaten:
FixLength
LeftBord
LeftBordString
RightBord
RightBordString
Interpunct
• FixLength enthält eine Liste von Datenelementen, deren Werte eine feste Länge
haben.
• LeftBord stellt eine Liste der Datenelemente dar, die oft von einer bestimmten
Zeichenfolge angeführt werden.
• LeftBordString ist die zugehörige Liste dieser führenden Zeichenfolgen.
• RightBord enthält eine Liste von Datenelementen, auf die oft eine bestimmte
Zeichenfolge folgt.
• RightBordString ist die Liste dieser Zeichenfolgen.
• Interpunct ist eine Verkettung von mit hoher Wahrscheinlichkeit innerhalb der
Werte von Datenelementen auftretenden Interpunktionszeichen sowie einigen
Bindeworten, die dieselbe Eigenschaft aufweisen.
Der Bereich SingelResultGenerateData enthält die Beispieldaten zur Generierung der
Pfade zur Extraktion von Datenelementen aus dem Ergebnis-Dokument einer Suchanfrage mit
einem Treffer und dem von diesem aus über Hyperlinks erreichbaren HTML-Dokumenten:
ExNum
SearchValue
AvGenData
GDEValue
• ExNum gibt die Anzahl N der verfügbaren Sätze von Beispieldaten an. Für jede Zahl
von 1 bis N ist ein GenerateExampe"Number"-Block vorhanden.
• SearchValue gibt den Suchwert für die Suchanfrage an, die den Treffer liefert, der
durch die vorhandenen Beispieldaten beschrieben ist. Dieser Wert wird nicht mehr
benutzt, da die Suchanfrage direkt aus den Beispielwerten generiert wird.
• AvGenData enthält eine Liste der Datenelemente, für die Beispielwerte verfügbar sind.
• GDEValue gibt den Beispielwert für das Datenelement DataElement an. Dieser
Eintrag ist für jedes in AvGenData aufgeführte Datenelement einmal vorhanden.
121

Der Bereich ListResultGenerateData enthält die Beispieldaten zur Generierung der Pfade
zur Extraktion von Datenelementen aus dem Ergebnis-Dokument einer Suchanfrage mit
mehreren Treffern und dem von diesem aus über Hyperlinks erreichbaren HTML-
Dokumenten:
ExNum
SearchValue
SearchFields
ExPartNum
PartAvGenData
GDEValue
• ExNum gibt die Anzahl N der verfügbaren Sätze von Beispieldaten an. Für jede Zahl
von 1 bis N ist ein GenerateExampe"Number"-Block vorhanden.
• SearchValue gibt den Suchwert für die Suchanfrage an, die mit großer
Wahrscheinlichkeit unter anderen die Treffer liefert, die durch die vorhandenen
Beispieldaten beschrieben sind.
• SearchFields enthält eine Liste der Datenelemente, auf die SearchValue als
Suchkriterium angewendet werden kann, sortiert nach absteigender Priorität.
• ExPartNum gibt die Anzahl T der in einem Beispiel vorhandenen Beispielteile an. Für
jede Zahl von 1 bis T ist ein ExamplePart"PartNumber"-Block vorhanden.
• PartAvGenData enthält eine Liste der Datenelemente, für die Beispielwerte im
jeweiligen Beispielteil verfügbar sind.
• GDEValue gibt den Beispielwert für das Datenelement DataElement an. Dieser
Eintrag ist für jedes in PartAvGenData aufgeführte Datenelement einmal vorhanden.
122

Literaturverzeichnis
[Azavant 2000] Fabien Azavant: Building Intelligent Web Applications Using
Lightweight Wrappers, Data and Knowledge Engineering 3 (36), 2000
[Bak 1999] Attila Bak: Erstellung einer Wrappers zum Parsen von HTML-Seiten,
Diplomarbeit Universität Karlsruhe, IPD und Technische Universität
Budapest, Elementi Villamossagtan Tanszék, 1999
[Baumgartner 2001] Robert Baumgartner: Visual Web Information Extraction with Lixto,
27th Conference on VLDB, Rom, 2001
[Bodor 1999] András Bodor: Konzeption und Implementierung eines
Wrappergenerators für das UniCats-Project, Diplomarbeit Universität
Karlsruhe, IPD und Technische Universität Budapest, Elementi
Villamossagtan Tanszék, Mai 1999
[Christoffel 2003] Michael Christoffel, Guido Wojke, Max Gensthaler: How Many Small
Libraries Can be a Large Library in: Proceedings of the 5th Russian
Conference on Digital Libraries, St. Petersburg, 2003
[Cohen 1999] William W. Cohen: Learning Page-Independent Heuristics for
Extracting Data from Web Pages in Computer Networks, Proceeding of
the eighth international conference on World Wide Web, Toronto, 1999
[Crescenzi 2001] Valter Crescenzi: Towards Automatic Data Extraction From Large Web
Sites, 27th Conference on VLDB, Rom, 2001
[Dinkloh 2003] Martin Dinkloh: Ein werkzeugunterstütztes konversationsbasiertes
Bausteinkonzept für Multiagentensysteme, Diplomarbeit Uni Karlsruhe,
IPD, 2003
[Flanagan 1998] David Flanagan: JavaScript: The Definitive Guide, O'Reilly and
Associatios, 3rd edition, 1998
[Goldfarb 1991] Charles G. Goldfarb: HyTime: A Standard for Structured Hypermedia
Exchange, IEEE Computer 1991
[Grieser 2000] Gunter Grieser: A Unifying Approach to HTML Wrapper
Representation and Learning, Proceedings of the Third International
Conference on Discovery Science, Kyoto, Japan, 2000
[Kuhlins 2004] Internet-Seite Wrapper Development Tools:
http://www.wifo.uni-mannheim.de/~kuhlins/wrappertools/
[LIXTO] Homepage der Lixto Software GmbH: http://www.lixto.com/
[Rieger 1995] Wolfgang Rieger: SGML für die Praxis, Ansatz und Einsatz von
ISO8879, Springer, 1995
[Sahuguet 1998] Arnaud Sahuguet, Fabien Azavant: W4F: a WysiWyg Web Wrapper
Factory, University of Pennsylvania (unpublished), 1998
[Sahuguet 2000] Arnaud Sahuguet, Fabien Azavant: World Wide Web Wrapper Factory
(W4F) Manual, 2000
[Schneider 2001] Jürgen Schneider: Wandler in digitalen Bibliotheken: Semiautomatische
Generierung und Evaluationsstrategien, Diplomarbeit
Universität Karlsruhe, IPD, 2001
[Snell 2002] James Snell, Doug Tidwell, Pavel Kilchenko, Webservice-
Programmierung mit SOAP, O’Reilly Verlag, 2002
[Steinhart 2004] Michael Steinhart: Anbindung unterschiedlicher Anbieter an das
UniCats-i-System, Diplomarbeit Universität Karlsruhe, IPD, 2004
[TFD] The Free Dictionary: http://computing-dictionary.thefreedictionary.com
[W3C] World Wide Web Consortium Homepage: http://www.w3.org
[W4F] W4F Homepage: http://db.cis.upenn.edu/W4F/
123

[Walsh 2002] Aaron E. Walsh, UDDI, SOAP, and WSDL: The Web Services
Specification Reference Book, Prentice Hall, 2002
[Wooldridge 2000] Michael Wooldridge, Nicholas R. Jennings und David Kinny. The Gaia
Methodology for Agent-Oriented Analysis and Design. Autonomous
Agents and Multi-Agent Systems, 3(3):285-312, 2000
[Wooldridge 2002] Michael Wooldridge, An Introduction to Multiagent Systems, John
Wiley & Sons, 2002.
[XWRAP] XWRAP Homepage: http://www.cse.ogi.edu/sysl/projects/XWRAP/
124

Danksagungen
Ich danke meinem Betreuer Dipl.-Inform. Michael Christoffel und dem gesamten UniCats-i-
Team für die engagierte fachkundige Unterstützung in Problemen und Fragen aller Art, die
sich im Umfeld der Entwicklung und Implementierung ergeben haben.
Ich danke Herrn Prof. Dr. Nikolaus Deussen für seine Hilfe beim Entwurf des Generators für
die regulären Ausdrücke.
Ich danke Frau Dipl.-Üb. Nora Over für ihre Hilfe bei der Realisierung der Mehrsprachigkeit
der Heuristik-Daten.
Ich danke meinen Eltern, die mir durch ihre jahrelange Unterstützung mein Studium erst
ermöglicht haben.
125