Extraktion von Ergebnisseiten in Webinformationssystemen auf der Basis von Layoutanalyse

Technische Universität BerlinFakultät IV � Elektrotechnik und InformatikComputergestützte Informationssysteme (CIS)

Diplomarbeit

Extraktion von Ergebnisseiten in

Webinformationssystemen auf der Basis von

Layoutanalyse

Florian Luft

Erstgutachter : PD Dr. habil. Martin Groÿe-Rhode

Zweitgutachterin : Dr.-Ing. Susanne Busse

Eingereicht am : 10. Juli 2008

Eidesstattliche Erklärung

Hiermit erkläre ich an Eides statt, daÿ ich diese Diplomarbeit selbstständig und ohne un-erlaubte fremde Hilfe angefertigt, keine anderen als die angegebenen Quellen benutzt sowieZitate aus anderen Arbeiten an den betre�enden Stellen als solche gekennzeichnet habe.

Berlin, den 10. Juli 2008Florian Luft

Danksagung

An dieser Stelle möchte ich mich bei allen Mitarbeitern der CIS-Gruppe bedanken, die mich beidieser Diplomarbeit unterstützt haben. Allen voran Martin Groÿe-Rhode für die Begutachtungder Arbeit sowie Susanne Busse und Thomas Kabisch ohne deren Vorarbeiten und Ideen dieseArbeit nicht möglich gewesen wäre. Thomas Kabisch danke ich auch für die Unterstützung,die er mir nach dem Ausscheiden als Mitarbeiter in seiner Freizeit hat zukommen lassen. Desweiteren bedanke ich mich bei Lutz Friedel für die unermüdliche Arbeit zur Bereitstellung dertechnischen Infrastruktur sowie Helko Glathe, der mich nicht nur mit Ideen sondern auch alsLeidensgenosse und Freund unterstützt hat.Groÿem Dank bin ich auch meiner Familie verp�ichtet insbesondere meinen Eltern Marianne

Karbig-Luft und Hans Luft, die mir mit ihrer langjährigen Unterstützung in vielen Bereichendas Studium in Berlin und im Ausland ermöglicht und mich gerade in der Endphase derDiplomarbeit noch intensiver unterstützt haben. Sei es durch Korrekturlesen und Anbringenvon Formulierungsvorschlägen oder einfach nur durch mütterliche Fürsorge. Meiner Freun-din Katja Streubel gebührt ebenfalls groÿer Dank für die unermüdliche Arbeit, die sie imHintergrund geleistet hat, um mich so gut es ging zu unterstützen.

3

Inhaltsverzeichnis

1. Einleitung 101.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2. Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3. Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2. Hintergrund und Grundlagen 122.1. Informationssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.1. Informationsintegration . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.2. Zugri� auf Informationssysteme . . . . . . . . . . . . . . . . . . . . . 13

2.2. Web + IS = Webinformationssystem (WIS) . . . . . . . . . . . . . . . . . . 152.2.1. De�nition von Webinformationssystemen . . . . . . . . . . . . . . . . 162.2.2. Aufbau von Webinformationssystemen . . . . . . . . . . . . . . . . . 172.2.3. Schwierigkeiten bei Webinformationssystemen als Datenquelle . . . . . 182.2.4. Ergebnispräsentation in WIS . . . . . . . . . . . . . . . . . . . . . . 192.2.5. Extraktion von WIS-Interfaces . . . . . . . . . . . . . . . . . . . . . 21

2.3. Vorhandene Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.1. HTML-basierte Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.2. Visuelle Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3.3. Einordnung des Algorithmus . . . . . . . . . . . . . . . . . . . . . . . 27

3. Konzeption eines Extraktionsalgorithmus 283.1. Page-Metamodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1.1. Class of Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1.2. Bounding Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1.3. Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.1.4. Separator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.1.5. Labeled Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.1.6. Labeled Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.1.7. Labeled Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2. Überblick über den Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . 363.3. Tokenization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3.1. Vergleich von Farben . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4. Identi�zierung des Datenbereichs . . . . . . . . . . . . . . . . . . . . . . . . 42

3.4.1. Arbeitsweise des RoadRunners . . . . . . . . . . . . . . . . . . . . . 443.4.2. Abgleich von RoadRunner-Variants und Token . . . . . . . . . . . . . 47

3.5. Erkennung von Separatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4

Inhaltsverzeichnis

3.5.1. Berechnung der Separatoren durch Projektion . . . . . . . . . . . . . 503.6. Hierarchische Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.6.1. Identi�zierung vertikal ausgerichteter Elemente . . . . . . . . . . . . . 533.6.2. Zuordnung von Labels . . . . . . . . . . . . . . . . . . . . . . . . . . 543.6.3. Zuordnung von Spalten-übergreifenden Labels . . . . . . . . . . . . . 553.6.4. Gliederung in Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.7. Repräsentation der Hierarchie als Baum . . . . . . . . . . . . . . . . . . . . 60

4. Implementierung eines Prototyps 634.1. Systemaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.2. Beschreibung der Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.2.1. RoadRunner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.2.2. Rendering-Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.2.3. Tokenizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.2.4. Integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.2.5. Separator Finder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.2.6. Hierarchy Finder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.2.7. Treebuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.3. Grenzen des Prototyps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5. Benutzung des Prototyps 775.1. Installation und Einrichtung . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.1.1. Anpassen von Pfaden . . . . . . . . . . . . . . . . . . . . . . . . . . 775.2. Durchführung eines Beispiellaufs . . . . . . . . . . . . . . . . . . . . . . . . 78

5.2.1. Erstellen von Testdaten . . . . . . . . . . . . . . . . . . . . . . . . . 785.2.2. Starten des DetailPageExtractors . . . . . . . . . . . . . . . . . . . . 805.2.3. Ö�nen der Baumvisualisierung . . . . . . . . . . . . . . . . . . . . . 81

6. Zusammenfassung und Ausblick 836.1. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836.2. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836.3. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Literaturverzeichnis 85

A. Ausgabe des DetailPageExtractors 89

B. Inhalt der CD 92

5

Tabellenverzeichnis

2.1. Vor- und Nachteile materialisierter und virtueller Integration [20] . . . . . . . 142.2. Beispiel einer Datenquelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3. Tabellentyp 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4. Tabellentyp 1a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.5. Tabellentyp 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1. Token-Typen und ihre Eigenschaften . . . . . . . . . . . . . . . . . . . . . . 333.2. Beispiel: Aircraft Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.3. Hierarchieebenen der Seitenelemente . . . . . . . . . . . . . . . . . . . . . . 60

4.1. Zuordnung der Token-IDs zum jeweiligen Token-Typ . . . . . . . . . . . . . . 68

6

Abbildungsverzeichnis

2.1. Webinterface zur Datenquelle aus Tabelle 2.2 . . . . . . . . . . . . . . . . . 152.2. genereller Aufbau einer Deep Web-Quelle [18] . . . . . . . . . . . . . . . . . 172.3. Beispiel: implizit angegebene Metadaten . . . . . . . . . . . . . . . . . . . . 182.4. Beispiel: Webinterfaces der Domäne �Flugbuchung� . . . . . . . . . . . . . . 202.5. von Firefox gerenderte Darstellung von Listing 2.3 . . . . . . . . . . . . . . . 222.6. Beispiel: syntaktische vs. intendierte Hierarchie aus [21] . . . . . . . . . . . . 232.7. Beispiel für nicht identi�zierbares Gruppenlabel aus [19] . . . . . . . . . . . . 24

3.1. Vom Extraktionsalgorithmus auswertbares Seitenlayout . . . . . . . . . . . . 283.2. Darstellung des Szenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3. Page-Metamodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4. Beispiel einer �Class of Pages� . . . . . . . . . . . . . . . . . . . . . . . . . . 313.5. Überlagerung mehrerer Styles . . . . . . . . . . . . . . . . . . . . . . . . . . 393.6. Variation des Euklidischen Abstands im RGB-Farbraum [28] . . . . . . . . . . 403.7. Beispiel für zwei nahezu gleiche Farben f und g . . . . . . . . . . . . . . . . 423.8. Beispiel für zwei Farben f und g der gleichen Farbfamilie . . . . . . . . . . . . 423.9. RoadRunner-Variants plus Bounding Boxes . . . . . . . . . . . . . . . . . 433.10. kleinste gemeinsame Bounding Box aller RoadRunner-Variants . . . . . . . 433.11. vorläu�ger Datenbereich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.12. Anfrageergebnisse an www.aa.com . . . . . . . . . . . . . . . . . . . . . . . 443.13. Erkennung von Mismatches durch RoadRunner . . . . . . . . . . . . . . . 463.14. Ausschnitt aus www.heise.de . . . . . . . . . . . . . . . . . . . . . . . . . . 483.15. Air Iceland-Webseite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.16. Projektion auf die x- und y-Achse . . . . . . . . . . . . . . . . . . . . . . . . 503.17. Nicht identi�zierbarer Separator auf der American Airlines-Seite . . . . . . . . 533.18. vertikal zueinander ausgerichtete Texttoken mit Abweichung um ε . . . . . . 543.19. Labeled Columns und die dazugehörigen Labels . . . . . . . . . . . . . . . . 553.20. Labeled Multi Column-Kandidaten . . . . . . . . . . . . . . . . . . . . . . . 563.21. Idealfall eines Spalten-übergreifenden Labels . . . . . . . . . . . . . . . . . . 573.22. linksausgerichtete Spalten-übergreifende Labels . . . . . . . . . . . . . . . . 573.23. unvollständig indenti�zierbares Spalten-übergreifendes Label . . . . . . . . . . 583.24. Repräsentation von AA.com als Baum . . . . . . . . . . . . . . . . . . . . . 62

4.1. Paketübersicht: DetailPageExtractor . . . . . . . . . . . . . . . . . . . . . . 644.2. Klassendiagramm: DetailPageExtractor . . . . . . . . . . . . . . . . . . . . . 65

5.1. Run Dialog von Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7

Abbildungsverzeichnis

5.2. Visualisierung des Baums im Browser . . . . . . . . . . . . . . . . . . . . . . 82

8

Listings

2.1. Ausgabe für DESC student . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2. Ausgabe für SELECT * FROM Student WHERE Geschlecht='w' . . . . . . . 152.3. Quellcode der Tabelle aus Abbildung 2.5 . . . . . . . . . . . . . . . . . . . . 23

3.1. Ausgabe der Rendering-Engine . . . . . . . . . . . . . . . . . . . . . . . . . 393.2. Ausschnitt aus der Ausgabe von RoadRunner . . . . . . . . . . . . . . . . 46

4.1. Auslesen aller Token T mit Hilfe der Rendering-Engine . . . . . . . . . . . . 674.2. Abfragen der Eigenschaften eines einzelnen Tokens t . . . . . . . . . . . . . . 674.3. Abfragen der Bounding Box des Tokens t . . . . . . . . . . . . . . . . . . . 674.4. Abfragen der Style-Informationen des Texttokens tt . . . . . . . . . . . . . . 684.5. Pseudocode: Berechnung des Datenbereichs . . . . . . . . . . . . . . . . . . 704.6. Pseudocode: Projektion auf die y-Achse . . . . . . . . . . . . . . . . . . . . 71

5.1. gekürzte Ausgabe des DetailPageExtractors: Texttoken-Variant-Korrespondenzen 805.2. gekürzte Ausgabe des DetailPageExtractors: Labeled Columns . . . . . . . . 805.3. gekürzte Ausgabe des DetailPageExtractors: Labeled Multi Columns . . . . . 815.4. gekürzte Ausgabe des DetailPageExtractors: Labeled Multi Columns . . . . . 81

A.1. Ausgabe des DetailPageExtractors . . . . . . . . . . . . . . . . . . . . . . . 89

9

1. Einleitung

1.1. Motivation

Das Internet � insbesondere das World Wide Web (WWW) � und die hiermit bereitgestelltenoder übertragenen Informationen spielen heute eine groÿe wirtschaftliche Rolle. Vor allemin den Bereichen Business-to-Business (B2B) sowie Business-to-Customer (B2C) steigt dieBedeutung und mit ihr die Menge der bereitgestellten Informationen stetig.Ein Groÿteil dieser Informationen be�ndet sich schon heute in (Unternehmens-)Datenbanken

und wird bei Bedarf über ein Web Query Interface im Internet bereitgestellt. Häu�g wird indiesem Zusammenhang von Deep Web oder Hidden Web gesprochen. Studien gehen voneinem Faktor 500-550 gegenüber Informationen auf statischen Webseiten � auch als SurfaceWeb bezeichnet � aus [3].Damit aus diesen Informationen ein möglichst hoher wirtschaftlicher Nutzen gezogen wer-

den kann, ist es notwendig, diese Informationen automatisch zu sammeln und weiterzuverar-beiten, indem sie in Webinformationssysteme oder auch andere Informationssysteme integriertwerden. Die manuelle Erstellung der hierfür verwendetenWrapper scheidet aufgrund der dyna-mischen Eigenschaften und der groÿen Masse von Deep Web-Seiten von vornherein aus. Wasbleibt, ist die automatische Generierung der Wrapper, welche aber teilweise mit den gleichenProblemen (häu�ge Veränderungen der Quellen) wie die manuelle Erstellung der Wrapper zukämpfen hat. Die Folgen sind häu�ge, zeit- und kostenintensive Anpassungen der generiertenWrapper.Analysiert man Webseiten des Deep Webs, so stellt man fest, daÿ sie sich bezüglich der von

ihnen verwendeten Terminologie, der Seitenstruktur und des Layouts einer eng begrenztenAnzahl von Mustern zuordnen lassen. Dieses Wissen kann man nun wiederum nutzen, umdas Schema der Quelle zu extrahieren. Mit Hilfe dieses Schemas lassen sich weitestgehendänderungsresistente Wrapper generieren, da diese nur noch dem Schema der Quelle folgen,welches sich in der Regel nicht oder nur sehr selten ändert [18].Die Gröÿe des Deep Webs ist in den letzten Jahren stetig gestiegen, so daÿ davon aus-

zugehen ist, daÿ es immer wichtiger wird, Deep Web-Quellen in andere Informationssystemzu integrieren und die hierfür notwendigen Wrapper möglichst kostensparend zu erzeugen.Daÿ sich der Suchmaschinen-Gigant Google mittlerweile aktiv der Deep Web-Indizierung wid-met, zeigt welchen Stellenwert das Deep Web gegenüber dem Hidden Web in naher Zukunftvermutlich haben wird [24].

10

1.2. Ziel

Das Ziel dieser Diplomarbeit ist es, einen Algorithmus zu konzipieren und prototypisch zuimplementieren, der die Hierarchie des Interfaces einer Deep Web-Quelle extrahiert. Der Al-gorithmus beschränkt sich hierbei auf die Ergebnisrepräsentation (Result Page) der Quelle.Deep Web-Quellen weisen neben einer syntaktischen Hierarchie, die sich direkt aus dem

Quellcode ableiten läÿt, auch eine intendierte Hierarchie auf. Diese entspricht weitestgehendder Wahrnehmung eines menschlichen Benutzers der Quelle. Das Ziel des Algorithmus ist es,diese zu extrahieren und als Baum darzustellen. Der Fokus liegt dabei auf Ergebnisseiten, aufdenen die Daten in tabellarischer Form präsentiert werden.Um sein Ziel möglichst ohne die direkte Interpretation des Quellcodes der Deep Web-Quelle

zu erreichen, soll der Algorithmus von visuellen Merkmalen Gebrauch machen, die auch einmenschlicher Nutzer zur Interpretation der Hierarchie verwenden würde. Das Ziel ist es, der Artund Weise menschlicher Interpretation durch Verwendung diverser optischer Anhaltspunktemöglichst nahe zu kommen.

1.3. Gliederung der Arbeit

Die Arbeit beschäftigt sich zu Beginn mit den Grundlagen von Informationssystemen insbe-sondere mit der Spezialisierung der Webinformationssysteme. Es wird ein kurzer Überblicküber den Aufbau und die Zugri�smöglichkeiten auf diese gegeben. Insbesondere wird dabeiauf die Schwierigkeiten, die sich aus der besonderen Bescha�enheit von Webinformationssys-temen ergeben, eingegangen. Anschlieÿend werden einige Verfahren vorgestellt, mit denen esmöglich ist, diese Probleme zu lösen oder zu umgehen.In Kapitel 3 wird auf die Extraktion von Schemata aus Webquellen eingegangen. Hier liegt

der Schwerpunkt insbesondere auf der Konzeption des Algorithmus, der dies auf der Basisvon visuellen Merkmalen für tabellenorientierte Ergebnisseiten ermöglicht.Nachdem in Kapitel 3 der Entwurf des Algorithmus im Vordergrund stand, beschreibt Ka-

pitel 4 die Implementierung des zuvor entworfenen Algorithmus. Dabei wird weniger auf denAlgorithmus selbst eingegangen sondern vielmehr auf den Systemaufbau und Implementie-rungsdetails. Soweit notwendig werden auch einige Teile des Algorithmus aus implementie-rungstechnischer Sicht beschrieben.In Kapitel 5 folgt eine praxisorientierte Beschreibung des Algorithmus aus Nutzersicht.

Dabei wird die Einrichtung des implementierten Prototyps, die Erstellung von Testdaten sowiedie Anwendung des Prototyps erklärt.Den Abschluÿ bildet mit Kapitel 6 eine Zusammenfassung der Arbeit sowie der daraus

gewonnenen Kenntnisse. Es wird ferner ein Ausblick gegeben, welche Veränderungen undOptimierungen am bestehenden Protoypen notwendig erscheinen, um dessen Robustheit zusteigern.

11

2. Hintergrund und Grundlagen

In diesem Kapitel wird zunächst ein kurzer Überblick über Informationsysteme im Allgemei-nen und einige speziellere Informationssysteme gegeben, sofern diese für die weitere Arbeitrelevant sind. Des Weiteren werden einige Verfahren zur Extraktion von Daten aus Webseitenvorgestellt, aus denen sich der Algorithmus aus Kapitel 3 ableitet. Zum Abschluÿ folgt dieDe�nition und Beschreibung einiger für das Verständnis der Arbeit wichtiger Begri�e.

2.1. Informationssysteme

Informationssysteme (IS) dienen vor allem dazu, Informationen zu speichern, aufzubereitenund über de�nierte Schnittstellen dem Nutzer zur Verfügung zu stellen. Dabei ist es zu-nächst egal, um welche Art von Nutzer es sich handelt. Es kann sich je nach Einsatzzweckdes Informationssystems um einen menschlichen Benutzer oder auch um ein anderes Systemhandeln.Eine Form von Informationssystemen bilden Webinformationssysteme. Sie bestehen in der

Regel aus einem System zur Datenhaltung, welchem häu�g ein Datenbankmanagementsys-tem (DBMS) zu Grunde liegt, und einer Nutzerschnittstelle in Form eines HTML-Formularsauf einer Webseite, welche durch einen Webserver, der direkten Zugri� auf die Daten hat,ausgeliefert wird. Neben einem DBMS können die zur Verfügung gestellten Daten auch inanderen Formen wie z. B. in Form von XML-Dateien gehalten werden. Unabhängig von derArt der Datenhaltung ist ein direkter Zugri� auf diese Daten nur durch den Webserver nichtjedoch von auÿen möglich. Es erscheint nach auÿen vollständig integriert. Da diese Gattungvon Informationssystemen für die vorliegende Arbeit von gröÿerer Bedeutung sind, wird ihnenmit Abschnitt 2.2 ein eigener Abschnitt gewidmet.Die Art der Datenquelle eines Informationssystems ist relativ frei wählbar, so lange sie sich

in irgendeiner Art und Weise maschinell auslesen läÿt. Jedoch lassen sich semistrukturierteoder besser noch strukturierte Daten einfacher verarbeiten als gänzlich unstrukturierte Daten,wie z. B. ein natürlichsprachlicher Text. Aber selbst dies ist mit geeigneten Methoden möglich.Als Datenquellen kommen somit auch andere IS in Frage. Genau genommen handelt es sichbei DBMS, die häu�g als Datenquelle zum Einsatz kommen, ebenfalls um Informationssys-teme. Werden mehrere Informationssysteme in einem IS zusammengefaÿt, spricht man vonInformationsintegration.

2.1.1. Informationsintegration

Informationsintegration läÿt sich in zwei Arten � die materialisierte Integration und die virtuel-le Integration � unterscheiden. Sie unterscheiden sich vor allem im Ort, an dem die integriertenDaten gehalten werden. Bei der materialisierten Integration werden die Daten der Quell-IS in

12

einem integrierten IS materialisiert, also zwischengespeichert. Häu�g wird hierzu ein DBMSgenutzt. Alle Anfragen werden nur noch auf diesen integrierten, materialisierten Daten be-antwortet. Die eigentlichen Quellen werden nur noch für, meist periodische, Updates derintegrierten Daten benötigt. Der Vorteil dieser Art von Integration liegt in einer kurzen Ant-wortszeit und der vergleichsweise geringen Komplexität der Anfragen, da diese, nach erfolgterMaterialisierung, nur an ein IS gestellt werden. Ferner können im Zuge der Materialisierungder Daten diese bereinigt (Erkennung von Dubletten, Beseitigung von Kon�ikten) werden. DieNachteile der materialisierten Integration liegen u. a. in ihrer geringeren Aktualität gegenüberden Quellen. Oftmals werden materialisiert integrierte IS nur zu bestimmten Zeitpunkten ausden Quellen aktualisiert, was einerseits zur Folge hat, daÿ sich eine Zeitspanne ergibt, in derdas integrierte IS und die Quellen keine synchronen Datenstände haben. Andererseits lassensich die Anfragen an die Quellen auf diese Art und Weise planen. Klassische Vertreter aufmaterialisierter Integration beruhender Informationssysteme sind Data Warehouses.Im Gegensatz zur materialisierten Integration steht die virtuelle Integration. Bei der vir-

tuellen Integration werden die zu integrierenden Daten nicht an einem Ort zusammengefaÿtsondern verbleiben an ihrem Ursprungsort. Dies hat u. a. zur Folge, daÿ jede Anfrage andas integrierte IS von diesem in Teilanfragen an die einzelnen Quellen zerlegt und an die-se gesendet werden muÿ. Anschlieÿend müssen die Ergebnisse der Einzelanfragen wieder zueinem Gesamtergebnis integriert werden. Da die Datenquellen direkt auf Anfragen antwor-ten, spricht man hierbei auch von synchroner Datenbereitstellung oder Pull-Modus. Aufgrunddieser Tatsache erreichen die integrierten Daten eine sehr hohe Aktualität, da sie quasi mitjeder Anfrage neu integriert werden und Anfragen somit immer gegen den aktuellen Stand derQuelle beantwortet werden. Der Preis, der hierfür zu zahlen ist, ist u. a. die nur sehr schwer bisgar nicht umsetzbare Möglichkeit, die zu integrierenden Daten zu bereinigen. Ferner kann espassieren, daÿ Quellen aufgrund von Netzwerkproblemen nicht zur Verfügung stehen oder eszu sehr langen Antwortszeiten kommt. Anfragen an virtuell integrierte Systeme werden somitin der Regel langsamer beantwortet als bei materialisiert integrierten Systemen. Im Gegensatzzu diesen ist in der Regel nur ein lesender Zugri� auf die Daten der Quellsysteme möglich, dadie Quellen oftmals nicht �wissen�, daÿ sie Quelle eines integrierten Informationssystems sind.Stellt die Quelle nicht von sich aus schreibenden Zugri� zur Verfügung, so kann dies auch einintegriertes IS nicht leisten.Die Vor- und Nachteile von materialisierter und virtueller Informationsintegration fasst Ta-

belle 2.1 zusammen [20].

2.1.2. Zugri� auf Informationssysteme

Der Zugri� auf Informationssysteme erfolgt über eine Schnittstelle, die die Datenquelle nachauÿen hin kapselt und so den Zugri� steuern und eventuell limitieren kann. Relationale Daten-bankmanagmentsysteme stellen oft mehrere solcher Schnittstellen zur Verfügung. Eine dieserSchnittstellen ist ein SQL-Interface, über das der Nutzer unter Einbeziehung der Metadatender Datenquelle Zugri� erhält.1 Die Metadaten einer Datenquelle beschreiben deren Nutzda-

1SQL = Structured Query Language: Datenbanksprache zur De�nition, Abfrage und Manipulation in rela-tionalen Datenbanken

13

Materialisiert Virtuell

Aktualität niedrig: abhängig von derUpdatefrequenz

hoch: immer aktuell

Antwortszeit niedrig: lokale Bearbeitung hoch: NetzwerkverkehrKomplexität niedrig: wie DBMS hoch: AnfrageplanungAutonomie Beantwortung von Anfragen Bereitstellung von Load-

DateienAnfragemöglichkeiten unbeschränkt: volles SQL beschränkt (bei beschränk-

ten Quellen)Read/Write beides möglich nur lesendSpeicherbedarf hoch: gesamter Datenbe-

standniedrig: nur Metadaten

Belastung der Quellen hoch, aber planbar eher niedrig, schlecht plan-bar

Datenreinigung möglich nicht möglich

Tabelle 2.1.: Vor- und Nachteile materialisierter und virtueller Integration [20]

ten.2 Geht man von einer einfachen Datenquelle, wie sie Tabelle 2.2 darstellen soll, aus, sowären die Metadaten u. a. der Name der Datenquelle (�Student�) sowie die Spaltenüberschrif-ten (�MatNr�, �Name�, �VName�, �GebDat�, �Geschlecht�). Ergänzt würden diese noch um dieDatentypen, der enthaltenen Elemente. Hat der Nutzer keine Kenntnisse über die Metadatender Datenquelle, so kann er sie sich mithilfe eines SQL-Befehls verscha�en. Ein einfaches

Student MatNr Name VName GebDat Geschlecht123456 Muster Max 29.02.1980 m456789 Müller Lieschen 24.12.1985 w234567 Otto Ernst 11.07.1988 m

Tabelle 2.2.: Beispiel einer Datenquelle

DESC student im SQL-Interpreter ausgeführt liefert die Metadaten der Datenquelle (sieheListing 2.1). Mit Hilfe dieser kann der Nutzer nun eine gezielte Anfrage an die Datenquellestellen. Beispielsweise könnte er eine Liste aller weiblichen Studenten mit dem SQL-StatementSELECT * FROM Student WHERE Geschlecht='w' extrahieren. Das Ergebnis dieser Anfra-ge zeigt Listing 2.2. Der Benutzer ist durch die Metadaten in der Lage, die Nutzdaten zunutzen und zu interpretieren.Ersetzt man das SQL-Interface3 durch eine Webseite mit einem entsprechenden Formular

als Schnittstelle (Abbildung 2.1), so hat der Nutzer ebenfalls Zugri� auf die Metadaten derDatenquelle. Wenn auch in anderer Form. Die Labels der Eingabefelder entsprechen in diesemFall den Metadaten. Durch ihre implizite Zuordnung zu bestimmten Feldern, ist es dem Nutzer

2Griech.: meta = �über� (im übertragenden Sinn)3Engl.: interface = Schnittstelle

14

höher als der der auf konventionellen Webseiten bereitgestellten Informationen. WIS werdendabei häu�g in einem anderen WIS integriert. So gibt es z. B. WIS, die mehrere Suchma-schinen integrieren und deren Ergebnisse einer Anfrage in einer aggregierten Ergebnislistepräsentieren.4 Ein anderes Beispiel eines integrierten WIS ist iGoogle.5 iGoogle bietet u. a.die Möglichkeit, viele verschiedene WIS (Nachrichtenseiten, Wetterberichte, . . . ) unter einerOber�äche zu integrieren. Im Gegensatz zum vorherigen Beispiel �ndet hier der Zugri� navi-gierend statt. Beiden genannten Beispielen ist die Art der Integration gemeinsam. Es handeltsich hierbei um eine virtuelle Integration.Bevor auf die Schwierigkeiten bei der Nutzung von WIS als Datenquelle eingegangen werden

kann, ist es notwendig, eine De�nition für Webinformationssysteme zu �nden.

2.2.1. De�nition von Webinformationssystemen

In der Literatur stöÿt man � wie so oft � auf viele verschiedene De�nitionen, die häu�g ihrenFokus auf unterschiedliche Bestandteile eines WIS legen. So ist die folgende De�nition von[10] noch recht allgemein gehalten.

�We de�ne a Web application as any software application that depends on theWeb for its correct execution.�[10]

Demzufolge würden auch Webcrawler6 als WIS betrachtet. Da ein Webcrawler in der Regelüber keine wirkliche Benutzerschnittstelle verfügt, oder wenn dann, einmal gestartet, nursehr eingeschränkte bis gar keine Nutzerinteraktionen ermöglicht, stellt er nur bedingt einWIS dar. Etwas genauer in dem Punkt ist da die folgende De�nition von [11]. Sie rückt denIS-Gesichtspunkt mehr in den Fokus.

�A WIS is an Information System providing facilities to access complex dataand interactive services via the Web.�[11]

Allerdings läÿt diese weitestgehend o�en, auf welche Art und Weise der Zugri� auf die Datenund Services erfolgt. Die letzte De�nition von [15] ist in diesem Punkt noch ein biÿchengenauer.

�(A) `Web Information System' or `WIS' [. . . ] (is) a computer-supported in-formation system, utilizing the technology of the WWW, and accessed by themajority of its users via a browser.�[15]

Sie stellt neben dem IS-Schwerpunkt vor allem die Art des Zugri�s in den Fokus. Demnachist die Standardzugri�svariante auf ein WIS der Zugri� via Webbrowser.

4MetaGer � http://meta.rrzn.uni-hannover.de/5http://www.google.de/ig6Engl. to crawl = krabbeln, ein Programm, das durchs Web �krabbelt� (es durchsucht), indem es Hyperlinksauf Webseiten folgt und sich so von Seite zu Seite bewegt.

16

http://meta.rrzn.uni-hannover.de/

http://www.google.de/ig

2.2.2. Aufbau von Webinformationssystemen

Die meisten Webinformationssysteme folgen in der Regel einem gemeinsamen schematischenAufbau wie ihn Abbildung 2.2 zeigt. Wie alle Informationssysteme verfügen auch sie über eineDatenhaltungsebene (im unteren Teil der Abbildung dargestellt), die nach auÿen hin nichtsichtbar ist. Häu�g handelt es sich hierbei um ein relationales DBMS.

Abbildung 2.2.: genereller Aufbau einer Deep Web-Quelle [18]

Die Schnittstelle nach auÿen zum Benutzer hin bildet ein Webinterface, welches sich grob inzwei Teile � QueryInterface (QI) und ResultInterface (RI) � unterteilen läÿt. Das QI (im linkenTeil der Abbildung) besteht dabei aus ein oder mehreren Formularen, über die Anfragen andas dahinterliegende Speichersystem gestellt werden können. Die Verwendung von Formularenschränkt die Art der an das Speichersystem stellbaren Anfragen oftmals dahingehend ein, daÿkeine Ad-Hoc-Anfragen sondern nur durch die Struktur des Formulars �vorde�nierte� Anfragengestellt werden können. In diesem Punkt unterscheiden sich WIS von anderen IS. Betrachtetman das QI in Abbildung 2.3, so sieht man, daÿ die einzige Anfrage, die an das Speichersystemgestellt werden kann, eine Abfrage möglicher Flugverbindungen zwischen zwei Flughäfen undihrer Preise pro Person zu bestimmten Zeitpunkten ist. Alternativ kann in diesem Beispieldurch einen Klick auf einen der Karteireiter im oberen Teil des QI auf ein anderes QI (Hoteloder Mietwagen) umgeschaltet werden.Die Präsentation der Anfrageergebnisse erfolgt durch das ResultInterface, welches sich im

rechten Teil der Abbildung 2.2 be�ndet. Häu�g werden die Ergebnisse in mehreren Schrittenpräsentiert. Ein gängiges Vorgehen hierbei ist es, erst eine Übersicht aller auf die Anfrage zu-tre�enden Datensätze zu präsentieren. Diese Übersicht wird auch als ResultPage bezeichnet(mittig in der Abbildung dargestellt). Nach Auswahl eines Datensatzes werden dem Benut-zer alle weiteren Details des Datensatzes angezeigt. In diesem Fall spricht man von einer

17

DetailPage (ganz rechts in der Abbildung).Den genauen Aufbau dieser DetailPages beschreibt Abschnitt 2.2.4 auf Seite 19. Auf die

Untersuchung ihrer Struktur und die damit möglich gewordene Extraktion einer Hierarchiekonzentriert sich diese Arbeit.

2.2.3. Schwierigkeiten bei Webinformationssystemen als Datenquelle

Ausgehend von der letzten De�nition eines WIS, läÿt sich vermuten, daÿ der Zugri� auf einWIS durch ein anderes IS nicht vorgesehen ist. Entsprechend ist die Gestaltung der Schnitt-stelle nach auÿen mehr auf die Bedürfnisse eines menschlichen Nutzers ausgelegt als auf dieIntegrierbarkeit durch ein anderes IS. In der Praxis bedeutet dies, daÿ auf die Datenquelleeines WIS nur mit Hilfe eines Webinterfaces zugegri�en werden kann. Um jedoch sowohlsinnvolle Anfragen an die Datenquelle stellen als auch die extrahierten Daten interpretierenzu können, ist es, wie bereits in Abschnitt 2.1.2 dargestellt, notwendig über Kenntnisse derMetadaten der Quelle zu verfügen.Die Metadaten einer Datenquelle �nden sich häu�g in Form von Labels oder anderen opti-

schen Hinweisen. Bei WIS kann es zudem vorkommen, daÿ Metadaten nicht explizit angege-ben werden sondern sich diese vielmehr aus dem Gesamtkontext ableiten lassen � also implizitangegeben werden. Die Abbildung 2.3 zeigt die Benutzerschnittstelle des WIS der Swiss In-ternational Air Lines. Ohne das Wissen, daÿ es sich (i) um das WIS einer Fluggesellschafthandelt sowie (ii) daÿ Fluggesellschaften von Flughäfen aus operieren, wäre es schwierig, inErfahrung zu bringen, daÿ die mit �From� und �To� beschriebenen Eingabefelder einen Flug-hafen oder eine Stadt mit Flughafen voraussetzen. Es könnte sich ja beispielsweise auch umFelder zur Eingabe von Zeiträumen handeln, was in diesem Fall durch die nachfolgenden Fel-der ausgeschlossen werden kann. Dieses Wissen wird auch als Domänenwissen bezeichnet.

Abbildung 2.3.: Beispiel: implizit angegebene Metadaten

Erschwerend kommt auch hinzu, daÿ die Benutzerschnittstellen von im Internet zugängli-chen WIS miteinander in Konkurrenz stehen. Sie sind sowohl Zugangspunkt zu einem IS als

18

auch gleichzeitig Werbemedium [15, 6, 31]. Daraus kann man ableiten, daÿ die Gestaltungeines Userinterfaces für ein WIS eher darauf ausgerichtet ist, den Benutzer zu binden, ihmjedoch zugleich auch eine möglichst einfache und intuitive Bedienung zu ermöglichen, kurz �ihn zu befriedigen.Dem gegenüber stehen Benutzerschnittstellen klassischer IS. Diese folgen in der Regel,

sofern es sich um gra�sche handelt, klaren Konzepten und Richtlinien. Als Beispiel wären dieApple Human Interface Guidelines und Windows Vista User Experience Guidelines zu nennen[1, 26]. Beide sollen gewährleisten, daÿ die Bedienbarkeit der Userinterfaces der Anwendungenfür die jeweiligen Betriebssysteme nicht von deren Art der Bedienung abweicht. Es existiertsomit eine Art Standard für die Gestaltung der Benutzerschnittstellen. Darüberhinaus verfügendie Ober�ächen gängiger Betriebssysteme über Standardbausteine (Widgets), die häu�g fürdie Entwicklung genutzt werden. Für den Fall, daÿ kein direkter Zugri� auf die Datenquelleeines klassischen IS besteht, kann das Wissen über diese Widgets genutzt werden, um einensog. �screen scraper� zu bauen.Im Gegensatz dazu stehen die Userinterfaces von WIS. Für sie existieren keine konkre-

ten Guidelines, wie sie für die Gestaltung von Anwendungen für bestimmte Betriebssystemeexistieren. Es existieren allenfalls Best-Practices.7 Es dürfte auch äuÿerst schwierig werden,allgemeingültige Richtlinien für die Gestaltung von Webinterfaces zu verfassen, da sich dieHeterogenität des WWWs auch auf seine Nutzer überträgt. So �ndet man eine Vielzahl vonWebbrowsern und Betriebssystemen vor, die teilweise zu anderen Darstellungen führen oderdiese sogar erfordern. Man stelle sich nur die Betrachtung einer Webseite am Monitor und dieBetrachtung der gleichen Webseite auf einem mobilen Endgerät mit einer deutlich geringerenBildschirmau�ösung vor. Dann wird deutlich, daÿ die Webseite für die Darstellung auf einemmobilen Endgerät angepaÿt werden muÿ und somit anderen Designrichtlinien zu folgen hat,als eine Webseite, die auf die Darstellung am Monitor ausgerichtet ist. Dennoch kann mannach der Auswertung mehrerer Webinterfaces erkennen, daÿ zumindestens die Seiten einerDomäne gewissen Gestaltungsmustern folgen wie die Abbildungen 2.4(a) und 2.4(b) zeigen.Abbildung 2.4(c) weicht dagegen auch von diesen domänenspezi�schen Gestaltungsmusternab.

2.2.4. Ergebnispräsentation in WIS

Ein Groÿteil der Webinterfaces aus der Domäne Flugbuchung ist � zumindest was die Präsen-tation der Ergebnisse angeht � sehr stark tabellenorientiert. Dem gegenüber stehen datensatz-orientierte Layouts, wie sie beispielsweise bei Suchmaschinen oder News-Seiten (Abbildung3.14(a) auf Seite 48) und Blogs8 zu �nden sind. Die Darstellung der Tabellen variieren hinge-gen. So gibt es Tabellenformen, die dem Muster von Tabelle 2.3 (Tabellentyp 1) folgen oderin Abwandlung mit spaltenübergreifenden Labels dem Muster von Tabelle 2.4 (Tabellentyp1a).Des weiteren existieren auch Tabellenformen, bei denen zwar klar und deutlich eine tabel-

larische Struktur erkennbar ist, die jedoch von dem Grundprinzip einer Tabelle abweichen. Sie

7Engl.: bewährte Praxis, Erfolgsrezept8Engl.: Abk. für Weblog (Kreuzung aus World Wide Web und Log), ö�entlich im WWW geführtes �Tage-buch�

19

(a) Delta Airlines

(b) Lufthansa

(c) Air Berlin

Abbildung 2.4.: Beispiel: Webinterfaces der Domäne �Flugbuchung�

Flight No. Departing Date & Time Arriving Date & Time Meals Stops Aircraft

. . . . . . . . . . . . . . . . . . . . . . . .

Tabelle 2.3.: Tabellentyp 1

20

Flight No. Departing Arriving Meals Stops AircraftCity Date & Time City Date & Time

. . . . . . . . . . . . . . . . . . . . . . . .

Tabelle 2.4.: Tabellentyp 1a

enthalten, im Gegensatz zu den Tabellentypen 1 und 1a, keine spaltenbezogenen Labels (einLabel je Spalte, alle Zellen einer Spalte haben die gleichen Eigenschaften) sondern zellen-bezogene Labels. Jede Zelle enthält zusätzlich neben einem oder mehreren Werten auch einoder mehrere Labels. Dennoch gruppieren Spalten bei diesen Tabellentypen gleichstrukturier-te Zellen. Tabellen dieser Struktur werden im Tabellentyp 2 (Tabelle 2.5) zusammengefaÿt.

Flugdetails

Ab�ug: Ankunft: Reisezeit: Meilen: Flug: . . .. . . . . . . . . . . . Flugzeug: . . .. . . . . . . . . . . . Tarif: . . .. . . . . . . . . . . . Mahlzeit: . . .Ab�ug: Ankunft: Reisezeit: Meilen: Flug: . . .. . . . . . . . . . . . . . .

Tabelle 2.5.: Tabellentyp 2

Alle hier dargestellten Tabellentypen können in Anzahl und Inhalt ihrer Spalten variieren.Die hier dargestellten Spaltenbeschriftungen sind zufällig gewählt.Diese Strukuren lassen sich mit geeigneten Verfahren erkennen und zur Extrahierung von

Metadaten sowie von Abhängigkeiten untereinander nutzen. Diese Erkenntnisse wiederumkönnen zur Generierung von Wrappern für ein WIS genutzt werden. Die automatische Gene-rierung von Wrappern ist gerade im Zusammenhang mit WIS als Datenquellen sehr sinnvoll,da sich diese recht häu�g ändern.

2.2.5. Extraktion von WIS-Interfaces

In der Literatur gibt es unterschiedliche Verfahren, um Daten aus Quellen des Deep Webs

zu extrahieren. Bevor man jedoch einen genaueren Blick auf das Vorgehen der einzelnenVerfahren werfen kann, gilt es zunächst die Unterschiede der Inhalte des Deep Webs zuerkennen.Grundsätzlich lassen sich die Inhalte der Datenbanken einer Deep Web-Seite (Web Databa-

se) in zwei Kategorien � unstrukturiert und strukturiert � einteilen. Unstrukturierte Daten sinddabei natürlichsprachliche Texte (z. B. News-Artikel), Bilder, Töne sowie Filme. Ein weitausgröÿerer Anteil fällt jedoch auf die strukturierten Daten ab. Sie zeichnen sich dadurch aus, daÿsie einem Schema folgen und als �attribute-value�- oder �labeled-value�-Paare vorliegen.9 Ak-

9�attribute-value� und �labeled-value� sind Synonyme

21

tuellen Untersuchungen zur Folge existieren etwa dreimal mehr strukturierte Web Databases

als unstrukturierte [14].Im Gegensatz zu unstrukturierten Daten enthalten strukturierte Daten häu�g eine Hierar-

chie. Diese wird nach auÿen hin oft implizit durch optische Merkmale (Tabellen, Überschriften,Formatierungen, . . . ) dargestellt. Intern wird sie durch das Schema der Web Database abge-bildet. Diese Hierarchie sollte bei der Extraktion der Daten möglichst erhalten bleiben, da siewichtige Zusatzinformationen für die weitere Verwendung der Daten enthält.Was bedeutet dies nun für die Extraktion von Daten aus diesen Quellen? Unstrukturierte

Daten lassen sich zunächst relativ einfach extrahieren, da sie als ein Datenobjekt betrachtetwerden, wohingegen ihre weitere Nutzung aufgrund der fehlenden Struktur schwieriger ist.Hierfür bieten sich z. B. Textmining-Verfahren an. Bei strukturierten Daten verhält es sichgenau umgekehrt. Die Extraktion ist schwieriger, da auch die Hierarchie extrahiert werdenmuÿ, jedoch lassen sie sich anschlieÿend aufgrund der bekannten Hierarchie relativ einfachnutzen.Dies klingt zunächst verwirrend, da man zu der Annahme neigt, daÿ HTML aufgrund seiner

Struktur doch eine Hierarchie enthält. Das stimmt so auch, jedoch handelt es sich hierbei umdie syntaktische Hierarchie und nicht um die intendierte Hierarchie. Der Unterschied beiderHierarchien liegt darin, daÿ die intendierte Hierachie die Hierarchie ist, die ein menschlicherBetrachter wahrnimmt und zur Interpretation der präsentierten Daten verwendet. Die syntak-tische Hierarchie ergibt sich dagegen aus der Schachtelung der HTML-Elemente. Diese muÿjedoch nicht zwangsläu�g mit der intendierten Hierarchie übereinstimmen [21].Ein Beispiel aus [21] verdeutlicht dies. Die in Abbildung 2.5 dargestellte HTML-Tabelle

wird aus dem HTML-Code in Listing 2.3 erzeugt. Abbildung 2.6(a) zeigt die dazugehörigesyntaktische Hierarchie, die anhand des HTML-Codes extrahiert wurde. Es läÿt sich leichterkennen, daÿ sie mit der intendierten Hierarchie (Abbildung 2.6(b)) nur sehr wenig gemeinhat.

Abbildung 2.5.: von Firefox gerenderte Darstellung von Listing 2.3

2.3. Vorhandene Verfahren

In der Literatur �nden häu�g zwei verschiedene Ansätze Erwähnung, um die intendierte Hier-archie zu erkennen. Zum Einen sind dies HTML-basierte Verfahren, die basierend auf demHTML-Code der Webseite, in der Regel in Form eines DOM-Trees, versuchen, strukturelle undvisuelle Informationen zu extrahieren [19, 21, 22], aus welchen sich die intendierte Hierarchie

22

1 <TABLE borde r="1"2 summary="This t a b l e g i v e s some s t a t i s t i c s about . . . ">3 <CAPTION><EM>A t e s t t a b l e w i th merged c e l l s</EM></CAPTION>4 <TR><TH rowspan="2"><TH co l span="2">Average5 <TH rowspan="2">Red<BR>eye s6 <TR><TH>he i g h t<TH>weight7 <TR><TH>Males<TD>1.9<TD>0.003<TD>40%8 <TR><TH>Females<TD>1.7<TD>0.002<TD>43%9 </TABLE>

Listing 2.3: Quellcode der Tabelle aus Abbildung 2.5

(a) syntaktische Hierarchie der HTML-Tabelle ausAbbildung 2.5

(b) intendierte Hierarchie der HTML-Tabelle ausAbbildung 2.5

Abbildung 2.6.: Beispiel: syntaktische vs. intendierte Hierarchie aus [21]

interpretieren läÿt. Zum Anderen sind dies rein visuelle Ansätze, die basierend auf den Ko-ordinaten der Seitenelemente, meist in Form von sogenannten Bounding Boxes, und anderenvisuellen Merkmalen (Trennlinien, Übergänge der Hintergrundfarbe, etc.) versuchen, Datenzu extrahieren [4, 23, 30, 12, 32, 34, 35, 2, 33]. Darüber hinaus gibt es auch Mischformen, beidenen auf den Quellcode zurückgegri�en wird, um die visuelle Interpretation zu unterstützen[27]. Im folgenden werden einige dieser Verfahren vorgestellt und auf die weitere Verwendunghin untersucht.

2.3.1. HTML-basierte Ansätze

Ein Groÿteil der HTML-basierten Ansätze sowie der Mischformen [19, 27, 22] arbeitet zu-nächst nach dem gleichen Schema. Im ersten Schritt wird die zu untersuchende Webseite bzw.das Interface eines WIS in kleine Bruchstücke (�Chunks�, �Token�) zerlegt. Dies geschieht mit-tels Analyse des Quellcodes. So bildet in [19] jedes HTML-Tag sowie darin eingeschlossenerText ein sog. Chunk. Ferner werden horizontale Linien als eine Art Separator behandelt, sodaÿ zwischen zwei horizontalen Linien eingeschlossener Text ebenfalls als Chunk betrachtetwird. Neben kleineren Unterschieden bei der Zerlegung, die auf die abweichenden Bedürfnisseder unterschiedlichen Algorithmen zurückzuführen sind, liegen die gröÿeren Unterschiede inder folgenden Verarbeitung der Bruchstücke. Abweichend von den beiden genannten Algo-rithmen verzichtet [21] darauf, die Webseite zu zerlegen. Es werden vielmehr nur die Tabellender Webseite als Ganzes extrahiert.In [19] wird mittels acht verschiedener Algorithmen (N-Gram Matching, Letter/Word,

23

Word/Letter, Substring, Tables, Previous, Following und NULL-Algorithm) versucht, eine Be-ziehung zwischen Formularelementen und den dazugehörigen Beschriftungen (Labels) herzu-stellen, wobei der Letter/Word- sowie der Substring-Algorithmus Abwandlungen des N-Gram-Matching-Algorithmusses sind. Am interessantesten für die Problemstellung dieser Arbeit istjedoch der Table-Algorithmus. Dieser versucht in einer Tabelle eingebetteten Formularelemen-ten ein Label zuzuordnen. Dazu überprüft er zunächst, ob sich innerhalb der Tabellenzelle,in der sich das Formularfeld be�ndet, auch ein Text be�ndet. Ist dies der Fall, so wird ange-nommen, daÿ es sich dabei um ein Label für dieses Formularfeld handelt. Be�ndet sich auÿerdem Formularfeld kein weiteres Element in der Tabellenzelle, so wird in der unmittelbar linksangrenzenden Tabllenzelle nach einem Text gesucht. Ist auch diese Suche nicht erfolgreich,so werden nacheinander die umliegenden Zellen (1. oben, 2. unten, 3. rechts) durchsucht.Durch Kombination der Algorithmen miteiander wird versucht, die Genauigkeit zu erhöhen.Dies macht Sinn, da nicht alle Algorithmen konstant gleich gut Label-Value-Paare auf denverschiedenen Seiten erkennen und so dennoch eine relativ hohe Erkennungsrate erreicht wer-den kann. Schwächen hat der Algorithmus insbesondere bei der Gruppierung von Elementen,sofern es sich nicht um eine Gruppe von Radiobuttons handelt. Zusammengehörige Radio-buttons werden im Allgemeinen mit dem selben HTML-Label gekennzeichnet, so daÿ dieRendering-Engine des Browsers diese als Gruppe identi�zieren kann. Der in [19] beschriebe-ne Algorithmus wertet diese HTML-Labels aus und kann so eine Gruppierung vornehmen.Im Gegensatz dazu kann das Gruppenlabel in Abbildung 2.7 nicht erkannt werden, da ausdem Quellcode nicht hervorgeht, daÿ die Textfelder mit ihren zugehörigen Labels eine Gruppebilden und somit über ein Gruppenlabel (�Home Address�) verfügen.

Abbildung 2.7.: Beispiel für nicht identi�zierbares Gruppenlabel aus [19]

Das oben beschriebene Problem zeigt das Dilemma, in dem sich rein HTML-basierte An-sätze be�nden. Der HTML-Code einer Webseite läÿt nur sehr wenige bis keine Rückschlüsseüber die Zusammengehörigkeit von Elementen zu. So müssen z. B. zwei im Quellcode unmit-telbar aufeinander folgende Elemente nicht zwangsläu�g in der gleichen Reihenfolge auf dergerenderten Webseite erscheinen.Ein weiteres Problem hebt [21] hervor. Das beschriebene Verfahren stöÿt an seine Gren-

zen, sobald der Autor der Webseite keine oder nur unzureichende Zusatzinformationen in dieTabelle eingebettet hat. So bezeichnet z. B. das HTML-Tag <TH> in Listing 2.3 explizit eineSpaltenüberschrift oder das Tag <CAPTION> explizit die Tabellenüberschrift. Fehlen diese Zu-satzinformationen, was heute im Zeitalter von Cascading Stylesheets (CSS) durchaus keineSeltenheit ist, scheitert der Algorithmus, da keine expliziten Labels mehr gefunden werdenkönnen, oder neigt zu Fehlern, da die Zellen der ersten Zeile der Tabelle als Spaltenüber-schriften verwendet werden.

24

Die Gründe hierfür liegen u. a. in der Bescha�enheit von HTML. HTML wurde für dieDarstellung von Webseiten, die von menschlichen Benutzern betrachtet werden, entwickeltund nicht für die maschinelle Auswertung. Aufgrund dessen enthält HTML nur sehr wenigebis gar keine Informationen über semantische Strukturen [32]. Die wenigen zur Verfügungstehenden Möglichkeiten, diese Strukturen auszudrücken, werden häu�g wie beschrieben nichtgenutzt.

2.3.2. Visuelle Ansätze

Visuelle Ansätze haben gegenüber rein HTML-basierten Verfahren einige Vorteile. So führt diestetige Weiterentwicklung von HTML unter Umständen dazu, daÿ HTML-Tags verschiedenerVersionen unterschiedliche Verhaltensweisen haben. Dies führt zwangsläu�g zur Notwendig-keit von stetigen Anpassungen bereits implementierter Verfahren. Ferner führt der vermehrteEinsatz von Cascading Stylesheets (CSS) sowie Skripten wie Javascript zur Gestaltung vonWebseiten dazu, daÿ rein HTML-basierte Verfahren eine geringere Erkennungsrate haben, dasie beide Techniken nicht berücksichtigen und nur auf dem reinen HTML-Code arbeiten [23].Visuelle Verfahren greifen zwar in der Regel auch auf einen DOM-Tree der Webseite zu-

rück, jedoch basiert dieser meistens nicht auf dem HTML-Code sondern auf dem �normierten�XHTML-Code der Webseite. Teilweise wird dieser Code mit Koordinaten der einzelnen Sei-tenelemente erweitert.Ein weiterer Vorteil visuell arbeitender Verfahren liegt darin, daÿ sie sich das grundsätzliche

Layout einer Webseite zu Nutzen machen können, wie es ein menschlicher Benutzer aufgrundseiner �Erfahrung� mit Webseiten in der Regel auch tut. Untersuchungen haben gezeigt,daÿ sich Navigationselemente häu�g auf der linken Seite und/oder oberhalb des Hauptin-haltsbereichs be�nden. Der gröÿte Teil einer Webseite wird meistens durch den Hauptinhaltdominiert. Alle Bereiche sind in der Regel deutlich durch Separatoren voneinander getrennt.Als Separatoren kommen neben Linien (horizontal und vertikal) sowohl Wechsel in der Hin-tergrundfarbe und Schriftart/-farbe sowie vergröÿerte Abstände (sog. blank areas) als auchunter gewissen Umständen Bilder in Frage [23, 32].[12] beschreibt ein Verfahren zum Separieren von Webseiten in Inhaltsblöcke basierend auf

diesen Merkmalen mit Hilfe von Projektionen. Dazu werden im ersten Schritt die Koordinatender einzelnen Seitenelemente bestimmt. Anschlieÿend werden anhand dieser Koordinaten zweiProjektionen auf die x- sowie auf die y-Achse durchgeführt. Die Projektionen ergeben gra-phisch dargestellt eine Wellenform, welche an einigen Stellen Täler (Minima) aufweist. DieseStellen geben, sofern ihre Breite über einem bestimmten Schwellwert liegt, die Position vonhorizontalen und vertikalen Separatoren an, die die Webseite in Inhaltsblöcke teilen. Um zuverhindern, daÿ Separatoren Blöcke gleichen Inhalts teilen, werden abschlieÿend alle Blöckeanhand von Style-Informationen auf Layoutgleichheit untersucht und gegebenenfalls wiederzusammengefaÿt.Ein ähnliches Verfahren beschreibt [32]. Die Autoren versuchen mit Hilfe einer auf optischen

Merkmalen basierenden Ähnlichkeitsanalyse gleiche Elemente einer Webseite zu erkennen undzu gruppieren. Sie gehen dabei von der Annahme aus, daÿ sich ähnlichsehende Elementeeinen gemeinsamen Inhaltsblock bilden. Dazu wird die Webseite zunächst in Elemente gleicherKategorien (einfaches Objekt, Container-Objekt, Group-Objekt, List-Objekt und strukturiertes

25

Dokument) anhand des Quellcodes zerlegt. Anschlieÿend werden diese Elemente anhand ihreroptischen Merkmale, welche durch Verwendung eines HTML-Parsers erkannt werden, mitdem DBSCAN-Algorithmus [9] geclustert und die Häu�gkeit, mit der die Cluster auftreten,bestimmt. Die identi�zierten Muster mit der gröÿten Häu�gkeit bilden die Inhaltsblöcke einerWebseite.[2] beschäftigt sich mit dem Problem der Zuordnung von Labels zu bereits extrahierten

Daten (Variants), wie sie durch das vom RoadRunner-Framework [5] generierte Wrapperproduziert werden. Diese automatisch extrahierten Daten verfügten bisher nur über generischeLabels, da die Zurodnung von aussagekräftigen Labels nur schwer ohne Benutzerinteraktionumsetzbar war. Um die Zuordnung vornehmen zu können, werden zunächst für alle Vari-ants und Invariants10 die sie umschlieÿenden Rechtecke (sog. Bounding Boxes) berechnet.Anschlieÿend wird die Lage (Ausrichtung und Abstand) der Invariants und Variants zueinan-der bestimmt und als Score für das jeweilige Invariant-Variant-Paar festgehalten. Wobei dieScore-Funktion so gestaltet ist, daÿ sie ein Minimum hat, wenn Invariant und Variant perfektzueinander ausgerichtet sind (horizontal oder vertikal auf einer Linie), und ein Maximum,wenn sie diagonal zueinander ausgerichtet sind. Die Paare mit dem geringsten Score bildenein Label-Value-Paar, wobei die Invariante das Label und die Variante den Wert darstellt.Der ganze Algorithmus basiert auf der Beobachtung, daÿ Labels und die zugehörigen Werterelativ dicht beieinander liegen und daÿ ein Label in der Regel horizontal, vertikal oder zen-triert zum dazugehörigen Wert ausgerichtet ist. Ferner sind Labels meistens links oder überdem entsprechenden Wert platziert und nicht durch andere Labels oder Variants von �ihrem�Wert getrennt. Daÿ diese Annahme nicht immer stimmen muÿ und somit den Algorithmusfehlschlagen läÿt, wird aus Abbildung 2.4(a) (Seite 20) ersichtlich. Dort be�ndet sich zwi-schen dem Label und dem dazugehörigen Wert noch eine weitere Variante (�Berlin-Tegel,Germany. . . �).Der in [33] vorgestellte Algorithmus dient im Gegensatz zu [2] dazu, Datensätze aus einer

Webseite basierend auf ihrer Baumdarstellung zu extrahieren. Zunächst wird dazu anhandder Positionen der einzelnen HTML-Tags auf der gerenderten Webseite ein sog. Tag-Treeberechnet. Dieser Tag-Tree basiert auf der Beobachtung, daÿ HTML-Tags häu�g ineinanderverschachtelt sind, so z. B. bei der Darstellung von Tabellen, und daher als Baumstruktur dar-gestellt werden können. In einer früheren Version des Algorithmus [22] wurde dieser Tag-Treenoch direkt aus dem Quellcode extrahiert, so daÿ dieser nicht zwangsläu�g mit der gerendertenDarstellung konform gehen muÿte. Der Algorithmus macht sich ferner die weitere Erkenntniszu Nutze, daÿ Datensätze auf einer Webseite in der Regel durch ähnliche Tag-Sequenzenausgedrückt werden. Diese müssen jedoch nicht zwangsläu�g identisch sein. Ausgehend vondiesen Beobachtungen werden zunächst nur die Datenregionen � es kann durchaus mehr alseine existieren � der Webseite bestimmt, welche sich aus gleichartigen Datensätzen ergeben.Diese werden durch gleiche (generalisierte) Knoten des Tag-Trees beschrieben. Knoten sind indiesem Fall gleich, wenn ihre Edit-Distanz11 gleich ist. Daraus resultiert auch die Einschrän-kung, daÿ eine Webseite mindestens zwei Datensätze enthalten muÿ, damit der Algorithmus

10�konstante� Textsymbole einer Class of Pages11Maÿ für Unterschied zweier Zeichenketten z1, z2 basierend auf der minimalen Anzahl der Operationen, die

notwendig sind, um z1 in z2 oder umgekehrt zu überführen

26

ordnungsgemäÿ angewendet werden kann. Nach der Identi�kation der Datenregionen, werdeninnerhalb dieser einzelne Datensätze identi�ziert, wobei sich diese nicht auf einen (generali-sierten) Knoten beschränken müssen. Jeder dieser Datensätze stellt selbst wieder einen Baumdar. Alle Datensatzbäume einer Datenregion werden nun miteiander verglichen und gegebe-nenfalls miteinander zu einem Gesamtbaum vereinigt. Eine Vereinigung �ndet nur statt, wenndas Zusammenführen zweier Bäume eindeutig möglich ist. Die Blätter des Gesamtbaums bil-den die Menge aller möglichen Attribute, die ein Datensatz enthalten kann. Welche dieserAttribute jeder einzelne Datensatz enthält, geht aus dem entsprechenden Datensatzbaumhervor, welcher ein Teilbaum des Gesamtbaums ist. Im Gegensatz zu [2] und [5] hat dieserAlgorithmus den Vorteil, daÿ eine einzige Instanz (Variablenbelegung) der Webseite ausreicht,um Daten zu extrahieren.

2.3.3. Einordnung des Algorithmus

Ausgehend von den in den Abschnitten 2.3.1 und 2.3.2 vorgestellten Algorithmen wird inKapitel 3 ein Algorithmus entworfen, der vor allem die Struktur von komplexen Tabellenerkennen soll und als Baum ähnlich dem aus Abbildung 2.6(b) auf Seite 23 darstellen soll.Der Algorithmus macht dabei vor allem von den in [12, 5, 2] vorgestellten Verfahren Ge-

brauch.

27

3. Konzeption eines

Extraktionsalgorithmus

Das nachfolgende Kapitel beschreibt den eigentlichen Extraktionsalgorithmus, wobei nochnicht auf implementierungstechnische Details eingegangen wird. Diese sind Bestandteil desKapitels 4.Der in diesem Kapitel beschriebene Algorithmus verarbeitet nur Webseiten, die bestimmte

Voraussetzungen erfüllen. Es muÿ sich bei diesen um Webseiten des Deep Webs oder statischeWebseiten handeln, die sich jeweils in eine Class of Pages (siehe Abschnitt 3.1.1) einordnenlassen, da der Algorithmus mindestens zwei gleichartige Seiten benötigt, um die variablenDaten zu erkennen. Des weiteren berücksichtigt der Algorithmus nur Webseiten, auf denendie Daten in tabellarischer Form dargestellt werden (Abbildung 3.1) und den Tabellentypen1 und 1a zuordbar sind (siehe Abschnitt 2.2.3). Ferner wurde er primär für die Verarbeitungvon Detailseiten entwickelt, lieÿe sich aber prinzipiell auch für die Verarbeitung von Über-sichtsseiten nutzen. Jedoch können die Ergebnisse in diesem Fall u. U. fehlerhafter sein alsbei Detailseiten. Unter Detailseiten versteht man solche Seiten, die, am Beispiel einer Flugbu-chung erklärt, nach Auswahl eines bestimmten Flugpaares auf einer Übersichtseite (Abbildung3.4(c)), das ausgewählte Flugpaar und eventuell weitere Informationen (Kosten, Namen derReisenden, . . . ) darstellt (Abbildung 3.4(a)).

(a) American Airlines (b) Air Iceland (c) American Trans Air

Abbildung 3.1.: Vom Extraktionsalgorithmus auswertbares Seitenlayout

Die Verarbeitung der Detailseiten erfolgt in mehreren Schritten teils parallel, wie die sche-matische Darstellung in Abbildung 3.2 zeigt. Zunächst wird eine Menge von DetailseitenDP (|DP | ≥ 2), welche alle Instanzen einer Class of Pages sind, in die RoadRunner-Komponente hineingegeben. Parallel dazu wird die erste Instanz dp1 aus der Menge DP in

28

die Rendering-Engine eines Webbrowsers, in diesem Fall der des Internet Explorers, gegeben.Anstelle der ersten Instanz dp1 könnte auch jede andere Instanz aus der Menge DP in dieRendering-Engine gegeben werden, da alle Instanzen dem gleichen Schema folgen und sichnur in ihren Variants unterscheiden (siehe De�nition einer Class of Pages, Abschnitt 3.1.1).Die ge�lterte Ausgabe der Rendering-Engine wird im Anschluÿ mit der XML-Ausgabe desRoadRunners in der Integrator-Komponente zusammengeführt. Ausgehend vom Ergebnisdieser Zusammenführung berechnet der Separator Finder alle Separatoren, so daÿ der Hierar-chy Finder im Anschluÿ die Hierarchie der einzelnen Komponenten der Detailseite bestimmenkann. Abschlieÿend erzeugt die Treebuilder-Komponente aus dieser Hierarchie einen Baumsowohl als XML-Ausgabe als auch als gra�sche Darstellung.

3.1. Page-Metamodell

Die nachfolgend erklärten Begri�e sind von zentraler Bedeutung für das Verständnis des indieser Arbeit beschriebenen Extraktionsalgorithmus, so daÿ sie an dieser Stelle gesondertde�niert werden. Die Beschreibungen basieren auf dem in Abbildung 3.3 gezeigten Page-Metamodell, das eine Weiterentwicklung des Layout-Metamodells aus [18] ist.

3.1.1. Class of Pages

De�nition: Eine �Class of Pages� fasst Webseiten, die auf dem gleichen HTML-

Grundgerüst basieren, zusammen. [5]

Alle Webseiten einer Class of Pages zeichnen sich durch ein einheitliches Layout aus undunterscheiden sich lediglich durch die dargestellten Informationen. Sie werden in der Regeldurch ein und dasselbe Skript mit Daten aus einem Datenbankmanagementsystem gefüllt.Die beiden in Abbildung 3.4(a) und Abbildung 3.4(b) dargestellten Seiten bilden eine Class

of Pages, wohingegen die in Abbildung 3.4(c) gezeigte Seite nicht zu dieser Class of Pagesgehört. Sie stammt zwar von der gleichen Webseite, basiert aber auf einem anderen Layoutund stellt andere Informationen dar.

3.1.2. Bounding Box

De�nition: Eine Bounding Box ist ein jedes Element umschlieÿender imaginärer

Rahmen, der dessen Gröÿe sowie Position eindeutig beschreibt.

Die Lage einer Bounding Box wird durch die Position zweier Punkte p1, p2 im zweidimen-sionalen Raum beschrieben, wobei einer der Punkte die linke, obere Ecke (p1) und der anderedie rechte, untere Ecke (p2) bezeichnet. Das durch diese Punkte aufgespannte Rechteck stelltdie Bounding Box dar, welche durch das Quadtupel (xp1 , yp1 , xp2 , yp2) eindeutig beschriebenwerden kann.Die Koordinaten dieser beiden Punkte basieren auf einem kartesischen Koordinatensystem,

dessen Zeichenebene durch die Menge

N2 = {(x, y) |x, y ∈ N\ {0}}

29

Abbildung 3.2.: Darstellung des Szenarios

30

Abbildung 3.3.: Page-Metamodell

(a) (b) (c)

Abbildung 3.4.: Beispiel einer �Class of Pages�

31

beschrieben wird. Der Koordinatenursprung liegt im Punkt O (1, 1). Darüber hinaus weist diey-Achse nach unten, so daÿ der Ursprung O in der oberen, linken Ecke liegt.Die Länge l sowie die Höhe h einer Bounding Box b und somit des durch sie eingeschlossenen

Elements errechnen sich wie folgt aus den Koordinaten der beiden Punkte p1, p2:

l(b) = xp2 − xp1

h(b) = yp2 − yp1

Die Länge l entspricht somit der Ausdehnung der Bounding Box in horizontale Richtung, dieHöhe h entsprechend der Ausdehnung in vertikaler Richtung.

3.1.3. Token

De�nition: Ein Token ist das kleinstmögliche, nicht komplexe, auf einer Webseite

vorkommende Element.

Token werden vor allem durch die Koordinaten der sie umspannenden Bounding Box sowieeinen Typ beschrieben. Beim Typ eines Tokens unterscheidet man zwischen unspezi�ziertenToken, Texttoken, Imagetoken, Formtoken sowie Separatoren. Auf letztere wird in Abschnitt3.1.4 noch genauer eingegangen, da sie sich deutlich von den anderen Tokentypen unter-scheiden. Bis auf Separatoren repräsentieren alle Token ein in der gerenderten Darstellungder Webseite angezeigtes Stück HTML-Code. Token können ferner auch durch zusätzlicheStyleinformationen beschrieben werden. Tabelle 3.1 listet die wichtigsten Eigenschaften dereinzelnen Tokentypen auf.Von den hier benannten Typen sind insbesondere Texttoken sowie Separatoren für diese

Arbeit von Bedeutung.

Texttoken

Als Texttoken werden Token bezeichnet, deren Inhalt aus einer Zeichenfolge besteht. DieseZeichenfolge kann grundsätzlich auch mehrzeilig sein, wird aber in diesem Fall zwecks einerbesseren Verarbeitbarkeit auf mehrere einzeilige Texttoken heruntergebrochen. Texttoken ver-fügen ferner über einen Style, der u. a. die farbliche Darstellung (Vorder- und Hintergrund)sowie die Schriftart beschreibt.

3.1.4. Separator

De�nition: Ein Separator ist ein spezielles Token, das aufgrund seiner Beschaf-

fenheit eine optische Trennung benachbarter Token erzeugt. Er enthält keine

inhaltlichen Informationen.

Separatoren sind Sonderformen von Token. Sie unterscheiden sich von allen anderen Token

dadurch, daÿ sie auÿer einer Bounding Box über keine weiteren Informationen verfügen. ImGegensatz zu allen anderen Token lassen sie sich nicht durch die Rendering-Engine aus einerWebseite extrahieren sondern müssen berechnet werden.

32

Token-Typ Eigenschaften Styleinformationen

Token• allgemeines Token• nicht durch andereToken-Typen erfaÿt

nein

Texttoken• enthält Zeichenfolge• einoder mehrzeilig

ja

Imagetoken• enthält Bilddaten

ja

Formtoken• enthält Formularelement

ja

Separator• enthält keine Informatio-nen• keine Überlagerung mitanderen Token

nein

Tabelle 3.1.: Token-Typen und ihre Eigenschaften

33

Das Hauptmerkmal eines Separators ist die optische Trennung benachbarter Elemente.Dies geschieht zum Einen durch einen vergröÿerten Abstand zwischen den Elementen alsauch zum Anderen durch Linien, die nicht zu einer Tabelle gehören, sowie durch Wechsel derHintergrundfarbe. Separatoren können sowohl horizontal als auch vertikal verlaufen. Für sieist eine Mindeststärke τ festgelegt, die je nach Ausrichtung der Höhe (horizontal) oder derBreite (vertikal) entspricht.Ein Separator kann weder ein anderes Token überlagern noch selbst durch eins überlagert

werden.

3.1.5. Labeled Element

De�nition: Ein Labeled Element ist ein abstraktes Layout-Element, welches ei-

ne Generalisierung von Labeled Columns und Labeled Tables darstellt. Labeled

Elements können sowohl vertikal als auch horizontal zueinander angeordnet sein.

Labeled Elements sind eine Erweiterung von Token. Sie können sich aus einem existieren-den Token ableiten, müssen es aber nicht. Wie diese verfügen auch sie über eine Bounding

Box sowie Styleinformationen. Im Gegensatz zu Token können sie über bis zu zwei Labelsverfügen, welche selbst wiederum Labeled Elements sind. Ein Label kann sich entweder linksoder oberhalb eines Labeled Elements be�nden. Labels unterhalb oder rechts eines Labe-

led Elements werden nicht berücksichtigt, da diese, aufgrund der allgemein vorherrschendenLeserichtung von links nach rechts bzw. von oben nach unten, sehr selten vorkommen.Darüber hinaus hat jedes Labeled Element vier sog. Scope Bounding Boxes, die sich rechts

und links sowie ober- und unterhalb des Labeled Elements be�nden. Sie haben eine festeGröÿe, die sich anhand der Gröÿe der Bounding Box des Labeled Elements sowie anhand derfür Separatoren festgelegten Mindeststärke τ berechnet.Die Länge der Scope Bounding Boxes, die sich ober- oder unterhalb des Labeled Elements

be�nden, ist mit der Länge seiner Bounding Box identisch. Die Höhe h der Scope Bounding

Box berechnet sich durch h = τ − 1. Analog erfolgt die Berechnung für Scope Bounding

Boxes links und rechts eines Labeled Elements. Die Länge l errechnet sich aus l = τ − 1.

3.1.6. Labeled Column

De�nition: Eine Labeled Column ist ein komplexes Layout-Element, das aus

mindestens zwei vertikal zueinander ausgerichteten Labeled Elements besteht.

Eine Labeled Column ist selbst ein Labeled Element.

Labeled Columns gruppieren Labeled Elements, die sowohl vertikal zueinander ausgerichtetsind und nicht durch einen oder mehrere Separatoren voneinander getrennt sind, zu einemneuen Labeled Element zusammen. Dieses Labeled Element bildet eine Tabellenspalte, daherder Name Labeled Column. Genau wie jedes andere Labeled Element können Labeled Columns

auch über ein Label verfügen, wobei sie im Gegensatz zu diesen nur über ein Label oberhalbihrer Bounding Box verfügen können. Existiert ein Label, so gehört es ebenfalls zur Mengeder enthaltenen Labeled Elements.

34

Die Bounding Box einer Labeled Column errechnet sich aus den Bounding Boxes derenthaltenen Labeled Elements, wobei sich ein eventuell vorhandenes Label innerhalb dieserBounding Box be�ndet. Sei LE′ = {le0, le1, . . . , len} die Menge aller in der Labeled Column

lc enthaltenen Labeled Elements, wobei le0 das Label ist, sowie B′ = {b0, b1, . . . , bn} dieMenge ihrer Bounding Boxes, so gilt für die Bounding Box b von lc:

b = (xp1 , yp1 , xp2 , yp2) wobeixp1 = min (xp1 (le0,...,n))yp1 = min (yp1 (le0,...,n))xp2 = max (xp2 (le0,...,n))yp2 = max (yp2 (le0,...,n))

Labeled Multi Column

De�nition: Eine Labeled Multi Column ist eine Spezialisierung einer Labeled

Column. Sie besteht aus mehreren, mindestens jedoch zwei, Labeled Columns, die

horizontal zueinander ausgerichtet sind und in einem inhaltlichen Zusammenhang

zueinander stehen.

Eine Labeled Multi Column ist sowohl eine Aggregation als auch eine Spezialisierung vonLabeled Columns. Sie enthält im Gegensatz zu einer Labeled Column keine Labeled Elements

sondern ausschlieÿlich Labeled Columns. Diese müssen horizontal zueiander ausgerichtet sein.Sie dürfen unterschiedlich hoch sein, jedoch müssen sich ihre Oberkanten an der gleicheny-Position (+/- einer Abweichung von ε) be�nden. Eine Labeled Column kann maximal Be-standteil einer Labeled Multi Column sein. Eine Labeled Multi Column selbst kann jedochwiederum Bestandteil einer weiteren Labeled Multi Column sein.Da eine Labeled Multi Column eine Spezialisierung einer Labeled Column ist, verfügt sie

ebenfalls über ein Label. Auch hier gilt, daÿ sich dieses nur oberhalb der Labeled Multi

Column be�nden kann. Ferner gilt für dieses Label, daÿ es alle in der Labeled Multi Column

enthaltenen Labeled Columns überspannt.Die Bounding Box einer Labeled Multi Column berechnet sich analog der einer Labeled

Column.

3.1.7. Labeled Table

De�nition: Eine Labeled Table ist ein komplexes Layout-Element. Sie gruppiert

mehrere, mindestens jedoch eine, Labeled Columns, welche horizontal zueinander

ausgerichtet sind, zusammen.

Eine Labeled Table kann neben Labeled Columns auch Labeled Multi Columns aggregieren,da es sich hierbei lediglich um eine Spezialisierung erstgenannter handelt. In jedem Fall müssenLabeled Columns, um zu einer Labeled Table zu gehören, horizontal zueinander ausgerichtetsein. Dabei dürfen sie nicht durch vertikale Separatoren voneinander getrennt sein.

35

Da es sich bei einer Labeled Table um eine Spezialisierung eines Labeled Elements han-delt, verfügt sie ebenfalls über eine Bounding Box , vier Scope-Bounding Boxes, sowie einLabel, welches sich oberhalb der Labeled Table und innerhalb der oberen Scope-Bounding

Box be�ndet. Ferner darf dieses nicht durch einen Separator von der Labeled Table getrenntsein. Die Gröÿe ihrer Bounding Box berechnet sich analog derer von Labeled Columns (siehe3.1.6).Jedes Labeled Element, egal ob Labeled Element, Labeled Column oder Labeled Multi

Column kann maximal Bestandteil einer Labeled Table sein. Labeled Elements, die Teil einerLabeled Column oder Labeled Multi Column sind, die wiederum Bestandteil einer LabeledTable sind, gehören ebenfalls dieser Labeled Table an.

3.2. Überblick über den Algorithmus

Der Algorithmus ist unterteilt in die folgenden fünf Schritte, die hier kurz und im weiterenVerlauf des Kapitels tiefgehender beschrieben werden.

HTML-Preprocessing/Tokenization Die zu untersuchende Seite wird mittels der Rendering-Engine eines Webbrowsers in eine Liste von Token zerlegt und nach Texttoken ge�ltert.Für jedes Token werden ferner Style-Informationen extrahiert.

Bestimmung des Datenbereichs Der Datenbereich wird bestimmt, indem alle variablenAnteile der Seite durch den RoadRunner-Algorithmus bestimmt werden [5]. Hierzuwird die zuvor in Token zerlegte Seite mit mindestens einer weiteren Seite (beide Seitenmüssen zur gleichen Class of Pages gehören) in diesen hineingegeben. Anschlieÿendwerden diese variablen Anteile mit den zuvor erkannten Texttoken abgeglichen und ihrekleinste gemeinsame Bounding Box bestimmt.

Erkennung von Separatoren Um Separatoren, die die zu untersuchende Seite visuell inBlöcke unterteilen, erkennen zu können, wird ein Projektionsverfahren angewandt. DieNutzung von Separatoren für die Auswertung der Seite beruht auf der Beobachtung,daÿ diese optischen Merkmale von menschlichen Benutzern zur Orientierung auf derSeite und zur Gliederung dieser benutzt werden. Sie geben somit gute Hinweise für dieweitere Verarbeitung.

Labelling und Grouping Jedes der zuvor erkannten Texttokens hat eine feste Position aufder Webseite. Da es sich bei diesen um tabellenorientierte Seiten handelt, lassen sichmehrere Texttoken �nden, die vertikal zueinander ausgerichtet sind. Jede dieser Grup-pen wird durch ein Label, das sich oberhalb dieser Gruppe be�ndet, beschrieben. DerAlgorithmus gruppiert zunächst alle Texttoken spaltenweise und weist jeder Spalte dannein Label zu. Er ist vor allem Lage, Labels zu �nden, die sich über mehrere Spaltenerstrecken. Alle Spalten werden ferner zu Tabellen gruppiert.

Visualisierung Der letzte Schritt besteht darin, die zuvor erkannten Zusammenhänge ausTexttokens, Spalten, Labels und Tabellen in eine Baumdarstellung zu überführen.

36

3.3. Tokenization

Der Schritt der Tokenization dient dazu, die zu untersuchende Webseite möglichst darstel-lungsgetreu in ihre Bestandteile (Token) zu zerlegen. Darüberhinaus werden diesen Token fürdie weitere Verarbeitung notwendige Zusatzinformationen annotiert (siehe 3.1.3).Die Zerlegung der Webseite in Token geschieht durch die Rendering-Engine eines Webbrow-

ser. Der Rendering-Engine kommen dabei mehrere Aufgaben zu. Zum Einen arbeitet sie wieeine Art Filter, indem sie den HTML-Code sowie ggf. verwendete Cascading Stylesheets (CSS)und Javascript-Code interpretiert und darstellt, wobei sich ihre Filterwirkung darin zeigt, daÿsie auch nicht standardkonformen HTML-Code nachvollziehbar und gleichbleibend interpre-tiert. Die Art der Interpretation hängt dabei sehr stark von der verwendeten Rendering-Engineab.Eine weitere Aufgabe der Rendering-Engine ist es, den Zugri� auf jedes einzelne Element

der Webseite, dessen Inhalt sowie dessen Eigenschaften über eine API zu ermöglichen. Die fürden weiteren Verlauf des in diesem Kapitel beschriebenen Verfahrens wichtigen Zusatzinfor-mationen sind die Koordinaten der Bounding Box von jedem Element sowie die Informationenüber die Darstellung des Elements (�Style�).Die relevanten Style-Informationen sind:

Vordergrundfarbe (foreground-color) Die Vordergrundfarbe eines Elements ist eine Far-be aus dem RGB-Farbraum. Diese wird entweder durch Angabe der Anteile der dreiRGB-Komponenten Rot, Grün und Blau oder durch die direkte Angabe eines Farbna-mens oder durch Verwendung einer entsprechenden Systemvariablen, welche die entspre-chend eingestellte Farbe des Betriebssystems enthält, festgelegt. Die Angabe der Antei-le der Grundfarben erfolgt in der Regel in hexadezimaler Schreibweise (z. B. #FF2200),sie kann aber auch in dezimaler (rgb(255,34,0)) oder in prozentualer Schreibweise(rgb(100%,13%,0%)) erfolgen.

Hintergrundfarbe (background-color) Die Hintergrundfarbe verhält sich analog zur Vor-dergrundfarbe mit dem Unterschied, daÿ sie zusätzlich den Wert transparent anneh-men kann. Dieser Wert bewirkt, daÿ das zugehörige Element quasi durchsichtig ist undhinterlappende Elemente weiterhin sichtbar sind.

Schriftgröÿe (font-size) Die Schriftgröÿe eines Elements kann entweder relativ oder ab-solut festgelegt sein. Relative Gröÿenangaben beziehen sich in der Regel auf die entspre-chende Gröÿe des übergeordneten Elements. Absolute Gröÿenangaben können nume-risch unter Verwendung der Maÿeinheiten Punkt (pt), Pica (pc), Inch (in), Millimeter(mm), Zentimeter (cm) sowie Pixel (px) festgelegt werden. Ferner kann die De�nitionüber Schlüsselwörter (small, medium, large, . . . ) erfolgen.

Schriftstil (font-style) Das Attribut Schriftstil legt fest, ob der entsprechend formatierteText normal (normal), schräggestellt (oblique) oder kursiv (italic) dargestellt wird.Es bezeichnet den Grad der Neigung der Schrift.

Schriftgewicht (font-weight) Die Stärke und Dicke einer Schrift werden im Attribut Schrift-gewicht zusammengefaÿt. Das Schriftgewicht kann entweder durch die Schlüsselwör-

37

ter normal (normales Schriftgewicht), lighter (dünneres Schriftgewicht), bold (fett)oder bolder (extra-fett) festgelegt werden oder alternativ durch numerische Werte von100 bis 900. In diesem Fall entspricht 100 extra-dünn, 400 normal und 900 extrafett.

Schriftfamilie (font-family) Die Schriftfamilie eines Elements kann neben einer einzelnenSchriftart wie z. B. �Arial� auch eine Liste von Alternativ-Schriftarten enthalten. Diesewerden bei Nichtverfügbarkeit der erstgenannten Schriftart gemäÿ ihrer Listenpositionfür die Darstellung verwendet. Üblicherweise �ndet dieses Vorgehen Verwendung, umeine annähernd gleiche Darstellung trotz fehlender Schriftarten zu gewährleisten. Häu-�g �ndet man als Wert für die Schriftfamilie �Arial, Helvetica, sans-serif�, wobei dieersten beiden Schriftarten konkrete Schriftarten sind und die letzte eine sog. generischeSchriftart ist.

Anzeige (display) Das display-Attribut eines Elements beein�uÿt die Darstellung des Ele-ments. Sollte das Element nicht sichtbar sein (display:none), so deutet in der Dar-stellung der Webseite nichts auf dieses Element hin. Es wird kein Platzhalter de�niert.Das Attribut dient ferner dazu, das Verhalten des Elements im Text�uÿ zu beein�ussen.

Sichtbarkeit (visibility) Die Sichtbarkeit eines Elements verhält sich ähnlich wie Display.Beide Attribute unterscheiden sich jedoch in der Art der Darstellung bzw. Nichtdarstel-lung von Elementen mit den Werten hidden oder collapse. Das Attribut visibilitysorgt in diesem Fall dafür, daÿ der für das entsprechende Element benötigte Platz frei-gehalten wird.

Schichtposition bei Überlappung (z-index) Der z-Index eines Elements gibt die Schicht-position innerhalb eines Stapels sich überlappender Elemente an. Dabei liegt das Ele-ment mit dem gröÿten Wert an oberster Stelle und ist somit vollständig sichtbar. Jekleiner der Wert des z-Index, desto weiter unten oder hinten liegt ein Element. Es wirdteilweise oder auch vollständig durch andere Elemente überlappt.

Alle diese Informationen werden von der Rendering-Engine aus den zugehörigen Stylesheetsund/oder evtl. verwendeter formatierender HTML-Tags (<font>, <b>, . . . ) extrahiert undinterpretiert. Eine detailiertere Beschreibung der einzelnen Parameter liefert [29].Zu beachten ist hierbei jedoch, daÿ die gerenderte Darstellung geschachtelter Elemente

teilweise erheblich von der durch die Stylesheet-De�nition festgelegten Darstellung abweichenkann. Der Grund hierfür ist in der Regel, daÿ die Stylesheet-De�nition des umschlieÿendenElements an das �Kind�-Element vererbt wird und somit dessen eigene Style-De�nition über-schrieben wird. Das in Abbildung 3.5 gezeigte Beispiel und die dazugehörige Ausgabe derRendering-Engine (Listing 3.1) verdeutlichen dies.Die Hintergrundfarbe der Tabellenzelle ist im Stylesheet als #afc8e7 festgelegt, wohingegen

die Hintergrundfarbe des Textes als transparent de�niert wurde. Durch die Überlagerungbeider Elemente und die Transparenz des Hintergrunds des obersten Elements wird dem Be-trachter suggeriert, daÿ der Hintergrund des Textes ebenfalls die Farbe #afc8e7 haben müÿte.Daÿ dies nicht der Fall ist, stellt man bei der isolierten Betrachtung des Textelements fest. Umverlässliche Aussagen über die Style-Eigenschaften eines Elements im Hinblick auf die kon-

38

Abbildung 3.5.: Überlagerung mehrerer Styles

krete Darstellung im Webbrowser tre�en zu können, ist es somit notwendig, die Überlagerungund Schachtelung von Elementen zu berücksichtigen.Bevor die extrahierten Token weiterverarbeitet werden können, müssen etwaige Dubletten

aufgespürt und bereinigt werden. Diesen Schritt bezeichnet man als Pruning. Unter Dublet-ten versteht man in diesem Zusammenhang auch Token, die zwar formal betrachtet zweiverschiedene Token darstellen, jedoch aufgrund der Schachtelung ihrer Bounding Boxes alsidentisch betrachtet werden können, da die Bounding Box des einen Tokens die Bounding

Box des anderen Tokens vollständig enthält. In diesem Fall wird das innere Token beibehaltenund das äuÿere verworfen.Betrachtet man die Token, die durch die Rendering-Engine für das in Abbildung 3.5 gezeigte

Beispiel extrahiert wurden (Listing 3.1), so läÿt sich erkennen, daÿ dieses Token zweimalexistiert. Einmal als Tabellenzelle (Zeilen 1 und 2) und einmal als Texttoken (Zeilen 3 und 4).Beim Vergleich der Bounding Box-Koordinaten (in eckigen Klammern) fällt ferner auf, daÿdie Bounding Box der Tabellenzelle die Bounding Box des Texttokens vollständig umschlieÿt.Formal läÿt sich dies durch folgende Formel ausdrücken

contains(t1, t2) =

wahr, für xp1(t1) < xp1(t2) ∧ yp1(t1) < yp1(t2)∧

xp2(t1) > xp2(t2) ∧ yp2(t1) > yp2(t2)falsch, für alle anderen Fälle

wobei t1 und t2 Token der Menge T seien und die Funktion contains die Frage beantwortet, obt2 vollständig in t1 enthalten ist. Darüberhinaus läÿt sich auch die in Abbildung 3.5 dargestellteProblematik von überlagerten Styles erkennen.

1 (#437:TD) L i n e s : 1 [ 284 , 403 , 336 , 436 ] F l i g h t2 Number ,#000000 ,# afc8e7 ,11 px , normal , 400 , A r i a l , H e l v e t i c a , sans−s e r i f , b lock ,

i n h e r i t |3 (#438:DIV) L i n e s : 2 [ 285 , 404 , 334 , 432 ] F l i g h t4 Number ,#000000 , t r a n s p a r e n t , 11 px , normal , 400 , a r i a l , h e l v e t i c a , sans−s e r i f , b lock

, i n h e r i t |

Listing 3.1: Ausgabe der Rendering-Engine

Im Anschluÿ an die Zerlegung der Webseite in Token und das Pruning erfolgt eine Filte-rung der Token in Abhängigkeit von der Art der Token (siehe 3.1.3). Mehrzeilige Texttoken

werden dabei in einzeilige Texttoken aufgesplittet, indem jede Zeile ein neues Texttoken mitentsprechender Bounding Box bildet, wobei die Summe der einzelnen Bounding Boxes die

39

Ursprungs-Bounding Box ergibt. Die Style-Informationen werden im Gegensatz hierzu einfachkopiert. Für die nachfolgenden Schritte sind nur Texttoken von Bedeutung, so daÿ diese her-ausge�ltert werden und in einer Liste gespeichert werden. Diese Liste entspricht der MengeTT für die TT ⊆ T gilt, wobei T die Menge aller einzeiliger Token ist.

3.3.1. Vergleich von Farben

Jedes Token verfügt über zwei Farbattribute � die Hintergrundfarbe sowie die Vordergrund-farbe (siehe 3.1.3). Beide Attribute können bei der weiteren Verarbeitung der Token einenHinweis geben, ob Token zusammengehören oder über ähnliche Eigenschaften, wie dies z. B.bei Tabellenlabels der Fall ist, verfügen. Dabei führt der Vergleich zweier Farben zu ähnlichenProblemen, wie der Vergleich zweier Gleitkommazahlen. Im Gegensatz zu letzteren lassensich zwei Farben noch relativ leicht auf absolute Gleichheit überprüfen, indem die einzelnenFarbparameter (abhängig vom jeweiligen Farbraum) verglichen werden. Ungleich schwierigerwird es, wenn zwei Farben formal betrachtet voneinander verschieden sind, jedoch durch denBenutzer als gleich wahrgenommen werden oder der Benutzer aufgrund seines Wissens zweiverschiedene Farben einer Farbfamilie zuordnen kann. Um zwei Farben miteinander zu ver-gleichen und auf Ähnlichkeit zu prüfen, gibt es verschiedene Verfahren, die meistens abhängigvom Farbraum sind. Im Folgenden wird ein Verfahren für den Vergleich zweier Farben imRGB-Farbraum beschrieben.Die Farbwerte der beiden Attribute werden, wie im World Wide Web üblich, im RGB-

Farbraum dargestellt. Der RGB-Farbraum ist jedoch sehr schlecht geeignet, um die Abständezwischen zwei Farben zu berechnen. Der pragmatische Ansatz, den euklidischen Abstandzweier Farbvektoren zu berechnen, liefert, wie [28] gezeigt haben, nur sehr unzureichendeErgebnisse. Die Ursache hierfür liegt in der Bescha�enheit des RGB-Farbraums. Abbildung3.6 zeigt ein Teilergebnis der Untersuchungen aus [28]. Die Farbe in der oberen linken Eckeist die Referenzfarbe mit der alle weiteren dargestellten Farben verglichen wurden. In diesemFall ein vollgesättigtes Gelb (#FFFF00). Von links nach rechts und von oben nach unten fol-gen die Farben, die der Referenzfarbe dem euklidischen Abstand nach am ähnlichsten seinmüÿten. In der unteren rechten Ecke be�ndet sich somit die Farbe, die am wenigsten Ähn-lichkeit zur Referenz haben sollte. Wie zu erkennen ist, gibt es erhebliche Sprünge innerhalbder Testdaten, aus denen man den Rückschluÿ ziehen kann, daÿ Farben, deren euklidischerAbstand zueinander gering ist, die sich also theoretisch sehr ähnlich sein sollten, dies nichtzwangsläu�g sein müssen.

Abbildung 3.6.: Variation des Euklidischen Abstands im RGB-Farbraum [28]

Der RGB-Farbraum ist ein dreidimensionaler Raum, dessen drei Achsen die Grundfarben

40

Rot, Grün und Blau darstellen und jeweils einen Wertebereich von [0 . . . 255] haben. Farben

werden folglich als dreidimensionaler Vektor

rgb

dargestellt. Was jedoch fehlt, sind Informa-

tionen über die Intensität sowie die Sättigung der einzelnen Farben. Diese Informationen sindjedoch notwendig, um eine verlässliche Aussage über die Ähnlichkeit zweier Farben tre�en zukönnen.In diesem Fall wäre eine Konvertierung der beiden Farben in den HSI-Farbraum (Hue=Farb-

ton, Saturation=Sättigung, Intensity= Intensität) sinnvoll. Die Darstellung der Farben indiesem Farbraum orientiert sich eng an der Farbrezeption des menschlichen Auges. EinzelneFarben lassen sich durch Beimischung von weiÿem Licht (Sättigung) zu einer Spektralfarbe(Farbton bestimmend) sowie durch Variation der Lichtstärke (Intensität) erzeugen. Wobei dieLichtstärke weit weniger Ein�uÿ auf die Farbdarstellung hat als der Farbton und die Sättigung.Da jedoch die Konvertierung von Farben des RGB-Farbraums in den HSI-Farbraum mit

einem zusätzlichen Aufwand verbunden ist, wird ein Verfahren verwendet, daÿ die Zusam-menhänge von H, S und I auf den RGB-Farbraum adaptiert. Das in [13] beschriebene Ver-fahren basiert auf der Annahme, daÿ H und S zweier Farben P = [R,G,B] und P ′ =[KR,KG,KB]′, die sich im RGB-Farbraum nur durch den konstant proportionalen FaktorK unterscheiden, äquivalent sind. Der einzige Unterschied beider Farben liegt in I, so daÿI 6= I ′ gilt.Ausgehend von dieser Beobachtung kann nun ein hue and saturation similarity coe�cient

r(f, g) ∈ [0, 1] berechnet werden, wobei f und g Farbvektoren im RGB-Farbraum sind.

r(f, g) =〈f, g〉‖f‖ ‖g‖

(3.1)

Beide Vektoren haben die gleiche Ausrichtung, wenn r(f, g) = 1 gilt. Ansonsten gilt je kleinerr(f, g) ist desto gröÿer ist der Winkel zwischen beiden Vektoren. Oder je gröÿer der Wert vonr(f, g) ist desto gröÿer ist der Gleicheitsgrad beider Farben.Alleine auf Basis von r(f, g) die Gleichheit oder Ähnlichkeit zweier Farben zu bestimmen ist

unzureichend, da auch die Intensität, wenn auch deutlich geringer, Ein�uÿ auf die Darstellungeiner Farbe hat. Bei geringen Unterschieden der Intensitäten I und I ′ lassen sich Farbendennoch zu Farbfamilien gruppieren. Deutliche Unterschiede der Intensitäten sorgen dafür,daÿ sich Farben für menschliche Betrachter nicht mehr gruppieren lassen, da sie o�ensichtlichin der Farbdarstellung deutlich voneinander abweichen. Insofern ist es notwendig, ebenfalls einGleichheitsmaÿ für die Intensität zu de�nieren, den intensity similarity coe�cient k(f, g) ∈[0, 1].

k(f, g) = 1− |f1 + f2 + f3 − g1 − g2 − g3|C

, mit C = 765 (3.2)

Wie bereits bei r(f, g) gilt auch hier, wenn k(f, g) = 1 dann sind die Intensitäten der Farbenf und g gleich (I = I ′). Je kleiner k(f, g) desto gröÿer die Abweichung der Intensitätenvoneinander.Durch Zusammenfassung des hue and saturation similarity coe�cients sowie des intesity

similarity coe�cients zu einem color similarity coe�cient s(f, g) mit einer entsprechenden

41

Gewichtung, läÿt sich die Gleichheit bzw. Ähnlichkeit zweier Farben bestimmen.

s(f, g) = α1 × r(f, g) + α2 × k(f, g) (3.3)

Wobei α1 + α2 = 1, α1 > 0, α2 > 0 sowie α1 > α2 gelten muÿ. Durch geschickte Wahl derGewichte α1 und α2 läÿt sich ein ähnlicher Ein�uÿ beider Faktoren auf das Gesamtergebniserzielen, wie es beim menschlichen Auge der Fall ist. In diesem Fall α1 = 0, 7 und α2 = 0, 3.Zwei Farben sind gleich oder nur ähnlich, das heiÿt, beide Farben sind vom menschlichen

Auge zu einer durch den Farbton bestimmten Farbfamilie zuordbar und unterscheiden sich inder subjektiven Farbwahnehmung nur gerinfügig (Abbildung 3.7), wenn s(f, g) über einembestimmten Schwellwert Ts (similarity) oder Tcf (color family) liegt, wobei hier Ts > Tcf gilt.

s(f, g) ≥ Ts, f und g sind nahezu gleich,

Ts > s(f, g) ≥ Tcf , f und g gehören zur selben Farbfamilie,

s(f, g) < Tcf , f und g sind ungleich.

(3.4)

In der Praxis haben sich Ts = 0, 97 und Tcf = 0, 84 als sinnvoll erwiesen. Beide Werte wurdenempirisch ermittelt.

#FF0000 #FF2200s(f, g) ≈ 0, 98

Abbildung 3.7.: Beispiel für zwei nahezu gleiche Farben f und g

#FF0000 #FF9900s(f, g) ≈ 0, 84

Abbildung 3.8.: Beispiel für zwei Farben f und g der gleichen Farbfamilie

3.4. Identi�zierung des Datenbereichs

Die in dieser Arbeit betrachteten Webseiten zeichnen sich unter anderem dadurch aus, daÿsie sowohl statischen als auch dynamischen Inhalt enthalten und innerhalb einer Quelle immerdie gleiche Struktur haben. [5] spricht in diesem Fall davon, daÿ sie zur selben Class of Pages

gehören. Der dynamische Inhalt ist dabei abhängig von einer bestimmten Variablenbelegung,welche in der Regel durch einen Link oder eine Interaktion (Abschicken eines Formulars,. . . ) auf der Vorgängerseite festgelegt wurde. Wohingegen der statische Anteil des Inhaltsunabhängig von einer bestimmten Variablenbelegung ist und somit bei jeder Variablenbelegunggleich bleibt.Neben erklärenden Texten und Navigationselementen (Menüs o. ä.) gehören vor allem La-

bels zum statischen Inhalt. Die sichere Identi�kation von Labels ist wichtig für die weitereVerarbeitung der dynamischen Inhalte. Dynamische Inhalte sind oftmals �anonym� und erge-ben nur in Verbindung mit einem entsprechenden Label eine semantische Einheit.

42

In [2] wird ein Verfahren zur Identi�kation von Labels beschrieben, das basierend auf visuel-len Gesichtspunkten diesen Datenwerten zuordnet. Es handelt sich dabei um eine Ergänzungdes in [5] beschriebenen RoadRunners. Da der in [2] beschriebene Algorithmus jedochWerten nur Labels zuordnen kann, wenn diese in einer �achen Hierarchie wie in Tabelle 2.3vorkommen und nicht in einer mehrstu�gen Hierarchie wie in Tabelle 2.4, wird an dieser Stel-le nur die RoadRunner-Komponente verwendet, dessen Ergebnisse Rückschlüsse auf denDatenbereich, auf den sich im weiteren Verlauf die Untersuchungen konzentrieren werden,zulassen. Anstelle des in [2] beschriebenen Labellers tritt ein Labelling-Algorithmus, der inAbschnitt 3.6.2 genauer beschrieben wird.Die Identi�zierung des Datenbereichs erfolgt iterativ. Zunächst wird der RoadRunner

benutzt, um alle dynamischen Inhalte innerhalb einer Class of Pages zu identi�zieren (Ab-bildung 3.9). Diese geben einen ersten Hinweis darauf, an welcher Stelle der Seite sich derDatenbereich be�nden könnte. Dazu werden alle zuvor als dynamisch erkannten Inhalte mitBounding Boxes versehen (siehe Abschnitt 3.4.2). Um diese Bounding Boxes wird die kleinstemögliche Bounding Box gelegt, die alle anderen umschlieÿt (Abbildung 3.10). Die Grenzendieser Bounding Box werden anschlieÿend in alle vier Richtungen um einen Wert ε erwei-tert (Abbildung 3.11). Die nun entstandene Bounding Box bildet den Datenbereich und dieAusgangsbasis für die Berechnung von Separatoren (siehe Abschnitt 3.5).

Abbildung 3.9.: RoadRunner-Variants plus Bounding Boxes

Abbildung 3.10.: kleinste gemeinsame Bounding Box aller RoadRunner-Variants

Zu beachten ist, daÿ eine Webseite im Zusammenhang mit dem in dieser Arbeit konzipiertenAlgorithmus über maximal einen Datenbereich verfügen kann. Dieser Datenbereich selbstkann durch Separatoren in mehrere Teilbereiche unterteilt werden. Jeder dieser Teilbereichewird somit sowohl durch die Grenzen des Gesamtdatenbereichs als auch durch Separatoren

begrenzt.

43

Abbildung 3.11.: vorläu�ger Datenbereich

3.4.1. Arbeitsweise des RoadRunners

Der RoadRunner-Algorithmus beschreibt ein Verfahren zur automatischen Generierungvon Wrappern für Webseiten des Deep Webs. Dabei macht er sich die Eigenschaft dieserSeiten zu nutze, daÿ Seiten der gleichen Class of Pages meistens aus einem immer gleichenHTML-Grundgerüst bestehen, welches mittels eines Skripts mit Daten aus einem Datenbank-managementsystem (DBMS) gefüllt wird. Der Unterschied zweier Seiten der gleichen Class of

Pages liegt somit lediglich in den dargestellten Daten (Abbildung 3.4.1). Eine Besonderheitdes RoadRunners ist, daÿ er a priori kein Wissen über den Aufbau der zu untersuchendenWebseiten benötigt sowie einmal gestartet ohne jegliche Nutzerinteraktion auskommt.

(a) Ergebnis der ersten Anfrage

(b) Ergebnis der zweiten Anfrage

Abbildung 3.12.: Anfrageergebnisse an www.aa.com

Die Extraktion der dynamischen Anteile einer Webseite (Variants) erfolgt mit Hilfe einerauf der Untersuchung der Gleichartigkeit bzw. Verschiedenheit basierenden Mustererkennung(pattern discovery). Dem RoadRunner werden dazu mindestens zwei voneinander verschie-

44

www.aa.com

dene Seiten p1, p2 der gleichen Class of Pages C übergeben (Abbildung 3.4.1). Die Seitenwerden zunächst von HTML in XHTML überführt, um sich später den sehr strikten Umgangvon XHTML mit Tags zu nutze machen zu können [25]. HTML selbst geht sehr �lax� mitTags um. So ist es z. B. teilweise möglich, auf schlieÿende Tags zu verzichten oder eigentlichbenötigte Tags in einem HTML-Dokument wie das <body>-Tag wegzulassen. Ferner ist inXHTML für alle Elemente ohne Inhalt (<br>, <hr>, . . . ) ein schlieÿendes Tag (</br>, </hr>,. . . ) zwingend, wobei auch nur die Variante eines schlieÿenden Tags (<br />, <hr />, . . . )ausreicht.Im Anschluÿ werden die Seiten einer lexikalischen Analyse unterzogen und in Token zerlegt.1

Ein RoadRunner-Token kann dabei entweder aus einem reinen String bestehen oder auseinem HTML-Tag.Nach der lexikalischen Analyse werden beide Seiten anhand ihrer Token verglichen. Die Sei-

te p1 bildet dabei die Referenz, gegen die alle weiteren Seiten verglichen werden. Aus ihr wirdferner der initiale Wrapper für Seiten der Class of Pages C abgeleitet. Stöÿt RoadRunnerbeim Vergleich der Seiten auf einen Unterschied, so versucht er den Wrapper soweit zu gene-ralisieren, daÿ auch dieser Unterschied vom Wrapper erfaÿt wird. Die Art des Unterschieds isthierbei ausschlaggebend für die Art und Weise der Generalisierung. Sie liefert ferner wichtigeHinweise darüber, um welche Art von Daten es sich handelt.RoadRunner unterscheidet zwischen zwei verschiedenen Arten von Unterschieden: �String

mismatch� und �Tag mismatch�. Ein �String mismatch� tritt z. B. in den Abbildungen 3.12(a)und 3.12(b) beim Ab�ugort auf. In Abbildung 3.12(a) startet der Flug in Los Angeles, in Abbil-dung 3.12(b) hingegen in New York. Dieser �String mismatch� legt die Vermutung nahe, daÿer aufgrund unterschiedlicher Werte eines Datenbankfelds zustande kommt. RoadRunnergeht daher bei �String mismatches� davon aus, daÿ es sich um Felder einer Datenbank handelt,welche sich nur durch eine abweichende Variablenbelegung unterscheiden.Die Bewertung eines �Tag mismatches� hingegen ist weit weniger trivial als die eines �String

mismatches�. Ein �Tag mismatch� kann zum Einen Indiz für ein optionales Seitenelement undzum Anderen Indiz für eine Wiederholungsgruppe sein. Die genaue Unterscheidung ist dabeiabhängig von der Struktur der den �Tag mismatch� umgebenden Token. Auf eine weiterfüh-rende Erklärung der Bewertung von �Type mismatches� wird an dieser Stelle verzichtet, da fürden weiteren Verlauf des in diesem Kapitel beschriebenen Algorithmus nur die Indenti�kationvon Datenbankfeldern durch RoadRunner relevant ist.RoadRunner erzeugt neben einem Wrapper für die gegebene Class of Pages auch eine

Liste aller identi�zierten Variants in Form eines XML-Dokuments (Listing 3.2).Obwohl RoadRunner ein HTML-basierter Algorithmus ist, läÿt er sich ohne Beeinträch-

tigung des Ergebnisses des Gesamtalgorithmus für die Erkennung von Variants einsetzen. Wiebeschrieben sind hierfür nur �String mismatches� von Bedeutung. Diese sind weitestgehendunabhängig von den sie umgebenen HTML-Tags wie aus Abbildung 3.13 ersichtlich wird.Sämtliche Texte, die auf einer Webseite erscheinen, �nden sich mit Ausnahme von Flash-Animationen, als Bilder dargestellte Texte oder durch clientseitige Skripte erzeugte Texte imQuellcode der Seite wieder.

1Token im Zusammenhang mit RoadRunner unterscheiden sich von den in Abschnitt 3.1.3 beschriebenenToken.

45

1 <a t t r i b u t e l a b e l="_E_">AMERICAN EAGLE</ a t t r i b u t e>2 <a t t r i b u t e l a b e l="_F_">280</ a t t r i b u t e>3 <a t t r i b u t e l a b e l="_G_">LAX Los Ange l e s</ a t t r i b u t e>4 <a t t r i b u t e l a b e l="_H_">Nov 20 , 2007</ a t t r i b u t e>5 <a t t r i b u t e l a b e l="_I_">09 :05 AM</ a t t r i b u t e>6 <a t t r i b u t e l a b e l="_J_">MIA Miami</ a t t r i b u t e>7 <a t t r i b u t e l a b e l="_K_">Nov 20 , 2007</ a t t r i b u t e>8 <a t t r i b u t e l a b e l="_L_">04 :55 PM</ a t t r i b u t e>9 <a t t r i b u t e l a b e l="_M_">763</ a t t r i b u t e>10 <a t t r i b u t e l a b e l="_N_">978</ a t t r i b u t e>11 <a t t r i b u t e l a b e l="_O_">MIA Miami</ a t t r i b u t e>12 <a t t r i b u t e l a b e l="_P_">Nov 22 , 2007</ a t t r i b u t e>13 <a t t r i b u t e l a b e l="_Q_">08 :30 PM</ a t t r i b u t e>14 <a t t r i b u t e l a b e l="_R_">LAX Los Ange l e s</ a t t r i b u t e>15 <a t t r i b u t e l a b e l="_S_">Nov 22 , 2007</ a t t r i b u t e>16 <a t t r i b u t e l a b e l="_T_">11 :10 PM</ a t t r i b u t e>17 <a t t r i b u t e l a b e l="_U_">757</ a t t r i b u t e>

Listing 3.2: Ausschnitt aus der Ausgabe von RoadRunner

Abbildung 3.13.: Erkennung von Mismatches durch RoadRunner

46

Grenzen von RoadRunner

Leider stöÿt der vom RoadRunner verfolgte Ansatz an Grenzen, wenn Daten nicht in Formvon �Strings� vorliegen, sondern wie im Beispiel in Abbildung 3.4.1 in Form von Bildern. Indiesem Fall wird die Fluggesellschaft durch ein Logo in Form eines Bilds dargestellt, welchesvom RoadRunner zwar als solches erkannt wird, es jedoch nicht ausgewertet werden kann.Hierzu müÿte man sich Techniken aus der Computer Vision zu nutze machen, welche jedochnicht im RoadRunner implementiert sind. Die Fluggesellschaft wird im Beispiel dennochals Variant erkannt, da der Name der Fluggesellschaft zusätzlich zum Logo als Text vorliegtund somit vom RoadRunner erkannt werden kann. Ein weiteres Problem tritt auf, wennsich relevante Informationen wiederholen, da diese dann nicht als Variant erkannt werden.Angenommen in Abbildung 3.12(a) würde es anstelle von �AMERICAN EAGLE� �AMERICANAIRLINES� heiÿen, so hätte dies zur Folge, daÿ die entsprechenden Token nicht als Variantmarkiert werden würden. Als Konsequenz darauf würden wichtige Informationen verlorengehenund die Festlegung des Datenbereichs später fehlerhaft sein.

3.4.2. Abgleich von RoadRunner-Variants und Token

Die Menge RV der von RoadRunner identi�zierten Variants bildet die Grundlage für dieBestimmung des Datenbereichs. Dafür wird ein Abgleich zwischen der Menge und den ge-�lterten Texttoken aus Abschnitt 3.3 durchgeführt. Der Abgleich basiert auf dem Vergleichdes Textes der RoadRunner-Variant mit dem Text des Texttokens. Beide Texte wurdenzuvor normalisiert (entfernen der führenden und nachfolgenden Leerzeichen). Passen sowohldas Texttoken als auch die entsprechende Variant zueinander, wird das Texttoken als Vari-ant markiert. Die Menge aller Variants, die ein Texttoken als Pendant haben, wird mit Vbezeichnet. Für sie gilt V = RV ∩ TT .Da jedes als Variant markierte Texttoken per De�nition (siehe 3.1.3) über eine Bounding

Box verfügt, läÿt sich anhand der Bounding Boxes der Variants der Bereich bestimmen, indem sich vermutlich alle Datenbankfelder be�nden. Dazu werden alle Bounding Boxes zueiner groÿen Bounding Box aufaddiert. Diese Bounding Box ist gleichbedeutend mit demDatenbereich (Data Region).

3.5. Erkennung von Separatoren

Betrachtet man Webseiten ohne dabei zunächst auf den Inhalt zu achten, ist man relativschnell in der Lage, relevante Bereiche zu erkennen oder einzelne �Datensätze�, so z. B. beieiner Suchmaschine, zu erkennen und voneinander abzugrenzen. Neben einer gewissen Erfah-rung, die man als Benutzer im Laufe der Zeit mit Webseiten gesammelt hat, unterstützenauch optische Merkmale diese separierende Wahrnehmung. Eine groÿe Rolle spielt dabei dieVerwendung von Farben und anderen Style-Elementen. Darüberhinaus können schon weitaussimplere Mittel zu einer optischen Abgrenzung von Seitenelementen zueiander führen. Oft-mals geschieht dies durch einen vergröÿerten Abstand benachbarter Elemente. Das Beispiel inAbbildung 3.14(a) zeigt dies recht anschaulich. Aufgrund der Skalierung der Abbildung ist esfast unmöglich, den Inhalt zu entzi�ern. Dennoch kann ein Mensch beim Betrachten dieses

47

Beispiels sofort erkennen, daÿ sich diese Webseite in mehrere Blöcke unterteilt, wobei dermittlere Block vermutlich den �Hauptinhalt� enthält (Abbildung 3.14(b)). Dieser wiederumbesteht vermutlich aus mehreren inhaltlich voneinander verschiedenen Elementen, erkennbaran dem gröÿeren Abstand zwischen diesen Elementen. Selbst über die Struktur der einzelnenElemente in diesem Block könnte man eine Aussage tre�en. Intuitiv würde man als Nut-zer vermuten, daÿ es sich bei den blau abgesetzten Zeilen um Überschriften handeln könnte(Abbildung 3.14(c)).

(a)

(b) (c)

Abbildung 3.14.: Ausschnitt aus www.heise.de

Gerade diese Beobachtungen über die Separierung von Webseiten kann man sich bei derGenerierung von Wrappern zu nutze mache. So würde eine spaltenweise Gruppierung dereinzelnen Token, der in Abbildung 3.15 gezeigten Webseite, dazuführen, daÿ die Token derSpalte �Departure� der oberen Tabelle mit den Token der Spalte �FAE - RKV� der unterenTabelle zu einem Element zusammengefaÿt werden würden. Würde man später diesem Ele-ment ein Label zuordnen, wäre dies mit gröÿter Wahrscheinlichkeit �Departure�. Da es sichjedoch bei der unteren Tabelle nicht um die Darstellung einer Flugpaarung handelt, in dessenZusammenhang �Departure� Sinn ergeben würde, sondern vielmehr um die Darstellung derPreise für eine bestimmte Strecke, wäre diese Zuordnung falsch.Für den menschlichen Benutzer ist es aufgrund der Struktur, des Abstands zwischen den

Tabellen und den Überschriften zu den beiden Tabellen relativ leicht ersichtlich, daÿ es sichwohl um zwei weitestgehend voneinander unabhängige Tabellen handeln muÿ und eine Grup-pierung der oben beschriebenen Token zu einer Spalte keinen Sinn ergeben wird. Alleine dieTatsache, daÿ beide Tabellen deutlich voneinader abgesetzt sind, reicht schon aus, um dies zuerkennen. Daher ist in der De�nition einer Spalte (Abschnitt 3.1.6) festgelegt, daÿ eine Spaltenicht durch einen Separator (Abschnitt 3.1.4) unterbrochen sein darf. Im beschriebenen Fallsind deswegen die Spalten �Departure� und �FAE - RKV�, obwohl sie vertikal zueinander aus-

48

www.heise.de

Abbildung 3.15.: Air Iceland-Webseite

49

gerichtet sind, trotzdem voneinander unabhängig, so daÿ beiden ein eigenes Label zugeordnetwerden kann. Daraus läÿt sich ferner aufgrund der De�nition einer Tabelle (Abschnitt 3.1.7)ableiten, daÿ sie zu zwei verschiedenen Tabellen gehören müssen.Ausgehend von diesen beschriebenen Beobachtungen werden für diese Arbeit die folgenden

drei Separationsmerkmale festgelegt, die im folgenden Abschnitt untersucht werden:

1. deutlicher Abstand (mehr als zehn Pixel) zwischen benachbarten Elementen,

2. Wechsel der Hintergrundfarbe,

3. horizontale oder vertikale Linien.

3.5.1. Berechnung der Separatoren durch Projektion

Der De�nition eines Separators (3.1.4) folgend, darf sich an dessen Position kein weiteresElement be�nden. Die Bereiche, in denen sich keine Elemente be�nden, lassen sich mittelszweier Projektionen auf die x- und die y-Achse des in Abschnitt 3.1.2 beschriebenen Koordi-natensystems und der Berechnung lokaler Extrema berechnen. Bei diesem Verfahren handeltes sich um eine Abwandlung des in [12] beschriebenen Verfahrens.

Abbildung 3.16.: Projektion auf die x- und y-Achse

Zunächst wird jedes Token t der Menge T (T repräsentiert in diesem Fall die Menge allerauf der Webseite vorkommenden Token) auf die x- sowie auf die y-Achse projeziert. Das

50

Gewicht w(t) des Tokens t setzt sich dabei je nach Projektionsrichtung aus der Höhe h(t)des Tokens (Projektion auf die x-Achse) oder aus der Länge l(t) des Tokens (Projektion aufdie y-Achse) zusammen. Für die Projektion p gilt somit:

p(x) =n∑

i=0

Kx∑j=0

h(tj) Projektion auf die x-Achse,

p(y) =n∑

i=0

Ky∑j=0

l(tj) Projektion auf die y-Achse.

wobei Kx = ‖Tx‖ bzw. Ky = ‖Ty‖ sei und Tx bzw. Ty die Menge aller Token t an der Stellex bzw. y sei. Für Tx und Ty gilt ferner Tx, Ty ⊆ T . Des weiteren sei n die maximale Breite(x-Achse) bzw. die maximale Höhe (y-Achse) der Webseite.Neben den Gewichten der einzelnen Token werden auch Wechsel der Hintergrundfarbe be-

rücksichtigt. Ein Wechsel der Hintergrundfarbe bewirkt eine Verringerung des Gesamtgewichtsan dieser Stelle um den Faktor ε = 0, 5. Dabei werden nur solche Farbwechsel berücksichtigt,deren Unterschiede deutlich erkennbar sind. Farben die sich sehr ähnlich sind und daher vommenschlichen Benutzer kaum als unterschiedlich wahrgenommen werden, werden als gleichbehandelt (Abbildung 3.7). Um diese Unterschiede messen zu können, wurde in Abschnitt3.3.1 ein color similarity coe�cient s(f, g) de�niert. Alle Farbpaare (f, g), für deren color

similarity coe�cient s (f, g) ≥ 0, 97 gilt, werden demnach als gleich betrachtet.2

Bei der oben beschriebenen Herangehensweise an Farbwechsel tritt ein Problem auf: Waswürde passieren, wenn die Hintergrundfarbe an der Stelle y = 1 #000000, an den Stelleny = 2 . . . 5 #FFFFFF und an der Stelle y = 6 wieder #000000 wäre? Zunächst würde derProjektionsalgorithmus an der Stelle y = 2 einen Farbwechsel feststellen und das Gewichtentsprechend um den Faktor ε verringern. An der Stelle y = 3 würde es aber demnachkeinen Farbwechsel geben, da sowohl die Stelle y = 2 als auch die Stelle y = 3 die gleicheHintergrundfarbe #000000 haben. Der nächste Farbwechsel würde erst wieder an der Stelley = 6 erkannt werden. Nämlich von #000000 nach #FFFFFF. Dies führt dazu, daÿ sichdas Gewicht nur jeweils an den Flanken ändert, nicht jedoch dazwischen. Um Separatorenverläÿlich erkennen zu können, müssen auch die Stellen zwischen den Flanken berücksichtigwerden. Damit der Projektionsalgorithmus an dieser Stelle nicht �verwirrt� wird, wird dasGewicht so lange um den Faktor ε verringert, bis es zum nächsten Farbwechsel kommt.Ferner gilt es bei der Betrachtung von Farbwechseln zu beachten, daÿ diese isoliert betrach-

tet nur eine sehr schwache Aussagekraft über das mögliche Vorhandensein von Separatorenhaben. Daher folgt aus der Indenti�ktaion eines Farbwechsels nur in Kombination mit derIdenti�kation eines der anderen Merkmale (Abstand oder Linie) ein Separator.Die Berücksichtigung von horizontalen Linien, die nicht Bestandteil einer Tabelle sind,

ausgedrückt durch das HTML-Tag <hr>, erfolgt, indem an der entsprechenden Stelle einabsolutes Minimum erzeugt wird (p(y) = −1). Da sowohl horizontale als auch vertikaleLinien eine deutliche optische Trennung von Elementen bewirken, ist es an dieser Stelle nichtnotwendig, weitere Separierungsmerkmale zu berücksichtigen.Anschlieÿend werden für beide Projektionen die absoluten Extrema berechnet. An Stellen

mit absoluten Minima be�nden sich wahrscheinlich Separatoren. Sicher kann dies jedoch nur

2Beim color similarity coe�cient handelt es sich um eine einheitenlose Gröÿe.

51

bestimmt werden, indem auch die Nullstellen der Projektionen berechnet werden. Liegt ander Stelle eines Minimas auch eine Nullstelle vor, so existiert an dieser Stelle ein Separator.Um zu verhindern, daÿ einzelne �zufällige� Minima sowie Nullstellen zu der Schluÿfolge-

rung führen, daÿ ein Separator an dieser Stelle existiert, ist für Separatoren per De�nitioneine Mindeststärke von zehn Pixeln festgelegt (siehe 3.1.4). Eine Ausnahme bilden lediglichhorizontale Linien, da diese aufgrund ihrer optischen Merkmale als Separator de�niert sind.Um diese dennoch verläÿlich durch Berechnung absoluter Minima als Separatoren erkennenzu können, gilt für die Projektion p an dieser Stelle p(y) < 0. �Zufällige� Minima und Null-stellen können entstehen, wenn z. B. an einer Stelle der Webseite kein Element platziert ist,der Abstand zu umliegenden Elementen aber so gering ist, daÿ er nicht als optischer Trennerwahrgenommen wird. Der Abstand zwischen dem Werbebanner und der darunterliegendendünnen, horizontalen Linie in Abbildung 3.14(a) ist so ein Fall.

Grenzen des Projektionsverfahrens

Das hier beschriebene Verfahren stöÿt an die Grenzen, wenn ein Separator nicht durchgängigist. Ohne Modi�kation wäre es mit diesem Verfahren nicht möglich, die Separatoren zwi-schen einzelnen News-Artikeln in Abbildung 3.14(a) zu identi�zieren, da diese jeweils durchrechts und links benachbarte Blöcke (in Abbildung 3.14(b) grün dargestellt) unterbrochenwerden. Um dieses Problem zu umgehen, wurde in Abschnitt 3.4 der Datenbereich (dataregion) ermittelt. Da dieser relativ eng um die als Variant erkannten Token gelegt ist, ist dieWahrscheinlichkeit geringer, daÿ Separatoren nicht durchgängig sind. Auszuschlieÿen ist diesdennoch nicht.Ein weiteres Problem tritt bei zwar für menschliche Nutzer aufgrund von kurzen Unterbre-

chungen deutlich wahrnehmbaren Separatoren, die jedoch nicht durch Projektion erkennbarsind, auf. In Abbildung 3.17 ist ein deutlicher Abstand zwischen beiden Tabellen erkennbar(rot markiert). Dieser wird jedoch durch die Überschrift �Fare Summary� sowie �?� unter-brochen. Dieses Problem könnte man im Falle des Beispiels umgehen, indem man den Wertfür die Dicke eines Separators verringert. Allerdings würde dies bei anderen Beispielen unterUmständen dazuführen, daÿ sich innerhalb von Tabellen Separatoren indenti�zieren lassenwürden, obwohl vom menschlichen Benutzer klar erkennbar ist, daÿ es sich lediglich um einenvergröÿerten Zeilenabstand handelt. Die Dicke eines Separators läÿt sich also nicht beliebigverringern.

3.6. Hierarchische Gliederung

Die bisher beschriebenen Schritte haben bereits einige Informationen über die zu untersuchen-den Webseiten heraus�ltern können. Ein ganz wichtiger Punkt wurde aber bisher auÿer achtgelassen: die Hierarchie der Elemente zueinander. Gerade die tabellarische Repräsentation derErgebnisse liefert einige Anhaltspunkte über die Zusammengehörigkeit von Elementen.Bei der tabellarischen Repräsentation kann man in der Regel davon ausgehen, daÿ alle

Elemente einer Spalte gleiche Eigenschaften haben und in irgendeiner Weise zusammenge-hören mit Ausnahme von Labeln. Diese geben allen Elementen einer Spalte einen �Sinn�.

52

Abbildung 3.17.: Nicht identi�zierbarer Separator auf der American Airlines-Seite

Die Elemente einer Spalte und eines zugehörigen Labels bilden sozusagen eine semantischeEinheit. Daher werden zunächst vertikal zueinander ausgerichtete Elemente identi�ziert (Ab-schnit 3.6.1). Im Anschluÿ daran werden diesen nun entstandenen Spalten Labels zugeordnet(Abschnitt 3.6.2). Dabei werden auch solche Labels berücksichtig, die über mehrere Spaltengehen (Abschnitt 3.6.3). Da Spalten zunächst ohne Berücksichtigung der Zugehörigkeit zuTabellen gebildet und mit Labeln versehen werden, gilt es, basierend auf den Positionen derSpalten diese zu Tabellen zusammenzufassen (Abschnitt 3.6.4).

3.6.1. Identi�zierung vertikal ausgerichteter Elemente

Ein Bestandteil von Tabellen sind neben Zeilen und Labels Spalten. Spalten repräsentieren beiden in dieser Arbeit untersuchten Webseiten, ähnlich wie bei relationalen Datenbanksystemen,Attribute. Sie liefern wichtige Informationen über den Inhalt der angezeigten Daten. Daher istdas Au�nden von vertikal zueinander ausgerichteten Elementen, welche eine Tabellenspaltebilden, von groÿer Bedeutung.Die Analyse der Elemente beschränkt sich zunächst auf die Menge V aller Texttoken, die

ein RoadRunner-Variant als Pendant haben. Die Anzahl der Elemente dieser Menge istin der Regel relativ gering (≈20), so daÿ eine ausreichende Performanz gewährleistet werdenkann.Das Hauptmerkmal für die Ausrichtung der Texttoken ist die Position der linken Kante

der Bounding Box . Stehen die linken Kanten der Bounding Boxes zweier Texttoken tt1, tt2aufeinander, d. h., die Stellen der linken, oberen Ecke der Bounding Box sind gleich, so sindtt1 und tt2 vertikal zueinander ausgerichtet. Dies gilt ebenfalls, wenn die Abweichung derlinken Kanten der Bounding Boxes voneinander den Wert ε nicht überschreitet (Abbildung3.18). In der Praxis hat sich ε = 2 als sinnvoll herausgestellt.Sollten sich keine Texttoken �nden lassen, deren linken Kanten der Bounding Boxes über-

einander stehen, so erfolgt eine Ausrichtung anhand der Mittelpunkte der Bounding Boxes.Auch hier gilt wieder, daÿ zwei Bounding Boxes vertikal zueinander ausgerichtet sind, wenndie maximale Abweichung kleiner oder gleich ε ist.

53

Abbildung 3.18.: vertikal zueinander ausgerichtete Texttoken mit Abweichung um ε

In jedem Fall, egal ob die Ausrichtung über die linke Kante oder den Mittelpunkt derBounding Box erfolgt, gilt, daÿ eine Spalte weder durch einen Separator unterbrochen werdendarf noch ein Labeled Element, das nicht zur Spalte gehört, sich zwischen ihren Elementenbe�nden darf. In diesem Fall handelt es sich um zwei voneinander unabhängige Spalten.Daher ist es zwingend notwendig, beim Vergleich der Ausrichtung zweier Texttoken ebenfallszu überprüfen, ob sich zwischen beiden ein Separator be�ndet.

3.6.2. Zuordnung von Labels

Eine Spalte ist zunächst nur eine Ansammlung von mehr oder weniger �zufällig� übereinanderangeordneten Elementen. Diese Elemente haben in der Regel einen Wert, über den keinegenaueren Aussagen getro�en werden können, da hierzu die Informationen fehlen, um welcheArt von Wert (Preis, Datum, Ab�ugort, . . . ) es sich handelt. Die einzige Vermutung, die manaus der Tabelleneigenschaft ableiten kann, ist, daÿ es ich bei den zu einer Spalte gruppiertenElementen um gleichartige Elemente handeln muÿ. Für eine weitere Verarbeitung reicht dieseInformation jedoch meistens nicht aus. Die einzelnen Elemente sowie die Spalte sind somitweitestgehend nutzlos.Anders würde es aussehen, wenn über die Elemente oder zumindestens über die Spalte wei-

tere Informationen vorliegen würden. Dabei ist es ausreichend, nur die Spalte als Repräsentantder einzelnen Elemente zu betrachten, da diese verschiedene Werte eines Attributs zusam-menfasst (siehe Abschnitt 3.6.1). Erhält eine Spalte nun einen Sinn in Form eines Labels, sokönnen die in ihr zusammengefaÿten Elemente ausgewertet werden.Eine Spalte kann über maximal ein Label verfügen. Als Label kommen nur Elemente in

Frage, die sich oberhalb der Spalte be�nden. Diese müssen, wie alle anderen Elemente derSpalte, vertikal zu dieser ausgerichtet sein. Dabei gelten die gleichen Kriterien für eine vertikaleAusrichtung wie beim Bilden von Spalten (siehe Abschnitt 3.6.1). Darüberhinaus kann einLabel nur zu einer Spalte gehören, wenn es sich in unmittelbarer Nachbarschaft zu dieserbe�ndet. D. h., zwischen Label und Spalte darf sich kein Separator be�nden.Ein weiteres Merkmal, welches bei der Label�ndung eine Rolle spielt, sind Farben. So

müssen alle Labels benachbarter Spalten die gleiche Hintergrundfarbe haben oder diese muÿsich zumindest in der gleichen Farbfamilie be�nden (siehe Abschnitt 3.3.1). Der Grund hierfürist die häu�ge optische Abgrenzung von Tabellenüberschriften (Labels) zum Rest der Tabellemittels unterschiedlicher Hintergrundfarben.Finden sich mehrere Label-Kandidaten, auf die die beschriebenen Eigenschaften zutre�en,

so gibt der vertikale Abstand zwischen der Bounding Box der Spalte und der Bounding Box

des Label-Kandidaten den Ausschlag. Der Label-Kandidat mit dem geringsten Abstand ist

54

das Label der Spalte.Wurde ein Label für eine Spalte gefunden, so erweitert es diese Spalte. Die Bounding

Box der Spalte vergröÿert sich entsprechend (Abschnitt 3.1.6). In Abbildung 3.19 sind diebisherigen Bounding Boxes aller Labeled Columns grün markiert, die Bounding Boxes deridenti�zierten Labels sind rot markiert. Die Abbildung stellt den Zustand vor der Erweite-rung der Bounding Boxes der Labeled Columns dar. Abbildung 3.20 stellt den Zustand nachder Erweiterung der Bounding Boxes dar. Ein Label kann somit nur Label zu einer Spal-te (Labeled Column) sein. Eine Ausnahme bilden die im nächsten Abschnitt beschriebenenSpalten-übergreifenden Labels.

Abbildung 3.19.: Labeled Columns und die dazugehörigen Labels

Die Menge aller möglichen Labels L ergibt sich aus der Menge aller Texttoken TT sowieder Menge aller RoadRunner-Variants V . Dabei fallen alle Texttoken, die gleichzeitig einRoadRunner-Variant sind, aus dieser Menge heraus, so daÿ L = TT\V gilt. Die Ursa-che hierfür liegt in den Eigenschaften von RoadRunner-Variants begründet. Ein Road-Runner-Variant spiegelt den momentanen Wert eines Attributs wieder. Dieser kann bei eineranderen Abfrage jedoch ganz anders sein, was in ein Widerspruch zu den Eigenschaften einesLabels wäre. Ein Label ist unabhänig von der durchgeführten Abfrage innerhalb einer Classof Pages. Es ist konstant.

3.6.3. Zuordnung von Spalten-übergreifenden Labels

Neben dem oben beschriebenen Fall, daÿ eine Spalte ein Label besitzen kann und dieses Labelauch nur Bestandteil dieser Spalte sein kann, gibt es einen weiteren Fall. Manchmal kann esvorkommen, daÿ ein Label mehrere Spalten überspannt. Die Spalten werden quasi unter die-sem Label zusammengefaÿt. Daraus resultiert, daÿ sie in irgendeiner Weise Gemeinsamkeitenaufweisen und/oder eine Einheit bilden.Die Label �Departing� und �Arriving� der in Abbildung 3.4.1 dargestellten Tabellen binden

jeweils die Spalten �City� und �Date & Time� zusammen. Ohne die Zuordnung eines Spaltenübergreifenden Labels wäre es nicht möglich, festzustellen welche der in jeder Tabelle zweimalvorkommenden Spalten welchen Ort und welche Zeit bestimmt. Sie sind homonym. Durchdie Zuordnung von Spalten übergreifenden Labels ist es jedoch möglich, die eine Spalte ein-deutig als Ab�ugort sowie Ab�ugzeit & -datum und die andere als Ankunftsort & -datum zuidenti�zieren.Spalten, die von einem gemeinsamen Label überspannt werden, bilden zusammen ein Labe-

led Multi Column (Abbildung 3.21). Jede Spalte, die in einer Labeled Multi Column enthaltenist, ist für sich betrachtet eine Labeled Column. Sie verfügt somit auch über ein eigenes Label.

55

Im beschriebenen Beispiel wären dies jeweils die mit �City� und �Date & Time� überschriebe-nen Spalten.Das Au�nden von Spalten übergreifenden Labels und das Gruppieren mehrerer Spalten zu

einer Labeled Multi Column erfolgt mittels eines mehrstu�gen Algorithmus. Die Ausgangs-menge hierfür bilden alle Labeled Columns, die bereits über ein eigenes Label verfügen. Diesesind in Abbildung 3.20 grün umrandet, ihre Labels rot.

Abbildung 3.20.: Labeled Multi Column-Kandidaten

Zunächst werden alle benachbarten Spalten identi�ziert, deren Oberkante sich auf gleicherHöhe be�ndet, d. h., die y-Werte der Punkte p1 ihrer Bounding Boxes sind gleich bzw. weichennur um den Wert ε voneinander ab. Nur Spalten, deren Oberkanten sich auf gleicher Höhebe�nden, können auch von einem gemeinsamen Label überspannt werden. Im Beispiel ausAbbildung 3.20 sind dies die jeweils die Spalten �City� und �Date & Time�. Die Gesamthöhe hder Spalten oder genauer ihrer Bounding Boxes hat hingegen keinen Ein�uÿ auf ein gemein-sames Label, da sich dieses immer oberhalb einer Spalte be�ndet und somit die Unterkantender Spalten voneinander abweichen können.Im nächsten Schritt wird jeder einzelnen Spalte ein Label zugeordnet. Im Gegensatz zu

einfachen Spaltenlabels (siehe Abschnitt 3.6.2) gelten für Spalten übergreifende Labels ab-weichende Bedingungen, wann ein Texttoken ein solches darstellen kann. In diesem Fall darfsich das Texttoken nicht vollständig in der oberen Scope Bounding Box der Spalte be�nden.Andernfalls könnte es nicht gleichzeitig ein Label für eine benachbarte Spalte sein (vgl. dieAbbildungen 3.21 und 3.22(b)). Daraus leitet sich auch die nächste Anforderung ab. So muÿdie Bounding Box eines potentiellen Label-Kandidaten horizontal über die obere Scope Boun-ding Box der Spalte hinausragen. Alle Spalten, deren Scope Bounding Boxes in horizontalerRichtung von der Bounding Box des Labels angeschnitten werden, werden zu einer LabeledMulti Column zusammengefaÿt.Diese Annahme kann jedoch in bestimmten Fällen auch dazuführen, daÿ gar kein Label

gefunden werden kann. Der Idealfall eines über zwei Spalten zentrierten Labels wird durchdie oben genannten Bedingungen vollständig erfasst (Abbildung 3.21). Problematisch kannes mit Labels, die links ausgerichtet sind, werden. Solange die Bounding Box des Labels groÿgenug ist und horizontal über die Scope Bounding Box der Spalte hinausragt, stellt dies nochkein Problem dar (Abbildung 3.22(a)). Ist jedoch die Bounding Box des Labels kürzer als

56

die obere Scope Bounding Box der Spalte, so würde das Label nicht erkannt werden, da dieBounding Box des Labels vollständig von der Scope Bounding Box der Spalte umschlossenwird (Abbildung 3.22(b)). Ähnliches kann passieren, wenn ein zentriertes Label über mehrals zwei Spalten geht. Werden die Scope Bounding Boxes der auÿenliegenden Spalten nichtmehr durch die Bounding Box des Labels angeschnitten, so lassen sich diese später nicht einerLabeled Multi Column zuordnen (Abbildung 3.23).

Abbildung 3.21.: Idealfall eines Spalten-übergreifenden Labels

(a) als Spalten-übergreifendes Label identi�zierbar (b) nicht als Spalten-übergreifendes Labelidenti�zierbar

Abbildung 3.22.: linksausgerichtete Spalten-übergreifende Labels

Um beim Auftreten dieser Probleme trotzdem ein Label �nden zu können, wird die Annahmegetro�en, daÿ bei einem links ausgerichteten Label alle Spalten, die sich rechts des Labelsbe�nden und deren Oberkanten sich auf der gleichen Höhe be�nden, bis zum Auftreten einesweiteren Labels, diesem zugeordnet werden.Darüberhinaus spielt neben der horizontalen Position des Labels im Verhältnis zur Position

57

Abbildung 3.23.: unvollständig indenti�zierbares Spalten-übergreifendes Label

der Spalten auch die vertikale Position eine Rolle. Auch bei Spalten-übergreifenden Labelsgilt die Festlegung, daÿ sich diese nur oberhalb der durch sie überspannten Spalten be�ndenkönnen. Formal bedeutet dies, daÿ die y-Koordinate des Punkts p2 der Bounding Box desLabels kleiner oder gleich der y-Koordinate des Punkts p1 der Bounding Box der Spalte seinmuÿ. Des weiteren darf sich zwischen dem Label und der Spaltenoberkante kein weiteres Text-token be�nden, d. h., das Texttoken, dessen Unterkante seiner Bounding Box den kleinstenvertikalen Abstand zur Oberkante der Bounding Box der Spalte hat und auf das die obenbeschriebenen Bedingungen zutre�en, ist das Label.Im letzten Schritt erfolgt die endgültige Zusammenfassung der Spalten zu einer Labeled

Multi Column, dessen Label in den vorherigen Schritten bestimmt wurde. Da zunächst jederSpalte, die vermutlich einer Labeled Multi Column angehören könnte, ein Label, welches auchbenachbarte Spalten überspannt, zugeordnet wurde, kann dieses nun zur Identi�ktation derzusammengruppierbaren Spalten genutzt werden. Alle Spalten (Labeled Columns), denen einidentisches Label zugeordnet wurde, werden zu einer Labeled Multi Column zusammengefaÿt.Durch rekursive Anwendung des Algorithmus auf bereits identi�zierte Labeled Multi Co-

lumns, können beliebig viele geschachtelte Labels erkannt werden.

3.6.4. Gliederung in Tabellen

Bisher wurden Texttoken nur zu Spalten jeglicher Ausprägung zusammengefaÿt. Jede Spaltefür sich genommen, bildet eine Einheit aus ihrem Label und den enthaltenen Elementen, diejedoch, abgesehen von den zu einer Labeled Multi Column zusammengefaÿten Spalten, inkeiner (inhaltlichen) Beziehung zu ihren Nachbarn steht. Zweifelsfrei lassen sich aus diesenisolierten Spalten auch schon Informationen extrahieren, deren Nutzwert jedoch aufgrundder fehlenden Einordnung in einem Gesamtkontext, relativ gering ist. Betrachtet man dieSpalte �Aircraft Type� in Abbildung 3.4.1 isoliert, so hat man schlichtweg eine Aufzählungvon Flugzeugtypen. Nur was nützt einem diese Information? Die Spalte könnte wie im Beispiel

58

zu einer Tabelle gehören, die eine spezi�zierte Flugverbindung darstellt. Ebenso gut könntesie zu einer Tabelle gehören, die spezi�sche Informationen über Flugzeugmuster bereitstelltwie Tabelle 3.2. Um den vollen Nutzen aus den in den einzelnen Spalten enthaltenen Daten

Aircraft Type Manufactor Engines PAX MTOW . . .#Eng Manufactor

763 Boeing 2 Rolls Royce 269 186.800 kg . . .757 Boeing 2 Pratt & Whitney 200 115.665 kg . . .M80 McDonald Douglas 2 General Electric 152 67.812 kg . . .. . . . . . . . . . . . . . . . . . . . .

Tabelle 3.2.: Beispiel: Aircraft Type

ziehen zu können, ist also notwendig, diese in einen Gesamtkontext einzuordnen. In der Regelgeschieht dies, indem Spalten zu Tabellen zusammengefaÿt werden. Alle Spalten zusammenbeschreiben dabei irgendetwas, für das die Tabelle als Oberbegri� steht. Bei den genanntenBeispielen ist dies einmal eine Flugverbindung zwischen zwei Orten an einem bestimmtenDatum sowie die Beschreibung eines Flugzeugmusters mit Angaben über deren Hersteller, dieTriebwerke, maximaler Passagierzahl und maximalem Ab�uggewicht.Der Oberbegri�, für den eine Tabelle steht, �ndet sich häu�g als Label zur Tabelle. Im Ge-

gensatz zu Spaltenlabels müssen Tabellenlabels nicht zwangsläu�g über der Tabelle stehen.Die Position ist abhängig vom Gesamtkontext der Webseite. Auf sehr textlastigen Webseiten(Artikelverö�entlichungen, Nachrichtenseiten, . . . ) �ndet man häu�g � ähnlich wie in dieserArbeit � Tabellenunterschriften. Auf datendominierten Webseiten hingegen werden Tabellen-labels meistens als Überschrift dargestellt. Da es sich bei den in dieser Arbeit betrachtetenSeiten um letztgenanntere handelt, kommen nur Überschriften als Tabellenlabels infrage. An-dere Positionen werden nicht berücksichtigt.Die Gruppierung der Spalten (Labeled Columns und Labeled Multi Columns) zu Tabel-

len (Labeled Tables) erfolgt auf Basis der Positionen der Bounding Boxes der Spalten sowieaufgrund der umliegenden Separatoren. Alle Spalten, deren Oberkanten der Bounding Boxes

sich auf gleicher Höhe mit einer maximalen Abweichung ε be�nden, kommen für die Gruppie-rung zu einer Tabelle infrage. Eine Tabelle darf dabei weder durch horizontale noch vertikaleSeparatoren unterbrochen werden, noch dürfen sich irgendwelche anderen Token zwischenden einzelnen Spalten be�nden. Um dies zu verhindern, müssen die Bounding Boxes be-nachbarter Spalten über eine gemeinsame senkrechte Kante verfügen. Vertikale Separatoren

begrenzen die Tabelle nach links und rechts, horizontale nach oben und unten. Die Gröÿe einerTabelle kann somit maximal der Fläche des Rechtecks, dessen Kanten durch vier Separato-ren repräsentiert werden, entsprechen. Die Ränder der Webseite sind dabei mit Separatorengleichzusetzen, so daÿ eine Tabelle maximal die Gröÿe der Gesamtseite aufweisen kann.Die Bestimmung eines Tabellenlabels erfolgt in ähnlicher Art und Weise wie die Bestim-

mung von Spaltenlabels. Zunächst kommen nur Texttoken als Labels infrage, deren Bounding

Box sich innerhalb der oberen Scope Bounding Box der Tabelle be�ndet. Sollte diese Bedin-gung auf mehrere Texttoken zutre�en, so wird zunächst das Texttoken mit dem geringstenvertikalen Abstand als Label verwendet. Gibt es hingegen mehrere Texttoken mit dem glei-

59

chen vertikalen Abstand, ist die horizontale Entfernung vom Mittelpunkt der Scope BoundingBox ausschlaggebend. Je kleiner dieser Abstand, desto eher kommt das Texttoken als Labelin Frage. Wobei hierbei nur Texttoken berücksichtigt werden, die sich links vom Mittelpunktder Scope Bounding Box be�nden. Generell gilt ferner, daÿ die Länge des Labels > 1 seinmuÿ, sofern es nicht aus einem Buchstaben oder einer Zahl besteht. Somit werden Labels,die nur aus einem Satzzeichen oder einem anderen Zeichen, das weder Buchstabe noch Zi�erist, ausgeschlossen. Numerierungen als Labels sind aber weiterhin möglich.

3.7. Repräsentation der Hierarchie als Baum

In Abschnitt 3.6 wurden verschiedene Elemente einer Webseite identi�ziert. Jedes dieser Ele-mente gehört zu einer anderen Hierarchieebene, welche Elemente einer niedrigeren Ebene alsKindelemente enthalten kann. Tabelle 3.3 zeigt die unterschiedlichen Hierarchiebenen und diedarin enthaltenen Seitenelemente.

Ebene Elemente Kardinalität

0 Webseite 11 Labeled Tables 0...n2 Labeled Multi Columns 0...n3 Labeled Columns 0...n4 Token 1...n

Tabelle 3.3.: Hierarchieebenen der Seitenelemente

Zwischen diesen Ebenen existieren Abhängigkeiten, die sich als Regeln formulieren lassen.Teilweise lassen sich diese aus dem in Abbildung 3.3 gezeigten Meta-Modell ableiten. ImFolgenden werden alle Regeln beschrieben. In Klammern stehen die jeweiligen Ebenen, dievoneinader abhängig sind. Es wird ebenfalls die Richtung angegeben, für die die Abhängigkeitgilt, da diese in der Regel nicht umkehrbar ist.

Existenz einer Webseite (Ebene 0) Es existiert immer genau eine Webseite w, die Ele-mente der Hierarchieebenen 1, 2 , 3 und 4 aggregieren kann.

Existenz eines Tokens (Ebene 0 → 4, Ebene 4 → 0, 3) Existiert eine Webseite w, soexistiert auch mindestens ein Token t.Existiert ein Token t, so existiert genau eine Webseite w, die dieses aggregiert. Fernerkann eine Labeled Column lc existieren, die dieses ebenfalls aggregiert.

Bildung einer Labeled Column (Ebene 3 → 4) Eine Labeled Column lc läÿt sich ausmindestens einem Token t, welches ungleich ihrem Label ist, bilden.

Bildung einer Labeled Multi Column (Ebene 2 → 3) Existiert eine Labeled Multi Co-

lumn lmc, so enthält diese mindestens zwei Labeled Columns lc1, lc2. Ferner kann sieals Label ein Token t enthalten.

60

Bildung einer Labeled Table (Ebene 1 → 2, 3) Existiert eine Labeled Table lt, so ent-hält diese mindestens zwei Labeled Columns lc1, lc2 oder mindestens eine Labeled Multi

Column lmc. Ferner kann sie als Label ein Token t enthalten.

Existenz einer Labeled Column oder Labeled Multi Column (Ebene 2, 3 → 1) Existierteine Labeled Column lc oder eine Labeled Multi Column lmc, so muÿ auch eine LabeledTable lt existieren, die diese aggregiert.

Existenz einer Labeled Table (Ebene 1 → 0) Existiert eine Labeled Table lt, so muÿauch eine Webseite w existieren, die diese aggregiert.

Basierend auf diesen Regeln lassen sich die in Abschnitt 3.6 identi�zierten Elemente als Baumdarstellen. Den Wurzelknoten des Baums bildet die Webseite w. Innere Knoten werden durchElemente der Hierarchieebenen 1, 2 und 3 repräsentiert. Die Blätter des Baums werden durchToken gebildet. Alle Kanten des Baums sind ungerichtet und nicht gewichtet. Sowohl derWurzelknoten als auch innere Knoten können beliebig viele Kindelemente enthalten.Die Abbildungen 3.24(a), 3.24(b) und 3.24(c) zeigen einen solchen Baum anhand des An-

frageergebnisses der American Airlines-Webseite. Rot hinterlegte Elemente spiegeln das Wur-zelelement, in diesem Fall die URL der Webseite, wieder, blau hinterlegte Elemente entspre-chen Labeled Tables, gelb hinterlegte Elemente Labeled Multi Columns und grün hinterlegteElemente Labeled Columns. Die Werte der Knoten entsprechen dem Label des dargestelltenElements.

61

(a) Wurzelknoten mit angedeuteten Teilbäumen

(b) linker Teilbaum

(c) rechter Teilbaum

Abbildung 3.24.: Repräsentation von AA.com als Baum

62

4. Implementierung eines Prototyps

Nachdem im vorherigen Kapitel der Transformatiosnalgorithmus beschrieben wurde, soll diesernun prototypisch implementiert werden. Der Prototyp gliedert sich dabei in mehrere Kompo-nenten, die im weiteren Verlauf beschrieben werden. Teilweise wurde auf bereits existierendeKomponenten aus anderen Arbeiten oder auch auf industrielle Produkte zurückgegri�en. Aufdiese Fälle wird entsprechend hingewiesen. Sofern deren genaue Beschreibung für das Ver-ständnis nicht notwendig ist, wird darauf verzichtet.Der gesamte Prototyp wurde in Java unter der Zuhilfenahme des Standard Widget Tool-

kits (SWT) der Eclipse-Plattform entwickelt. Grundsätzlich ist er somit plattformunabhängig.Aufgrund der in dieser Arbeit verwendeten Rendering-Engine des Internet Explorers ist derPrototyp derzeit nur auf Windows-Plattformen lau�ähig, wobei er auf Windows XP getes-tet wurde. Inwiefern er auch unter anderen Windows-Versionen lau�ähig ist, wurde nichtuntersucht.

4.1. Systemaufbau

Die Implementierung des Systems gliedert sich in die vier Pakete detailpage, tokens, utilund ole (Abbildung 4.1) sowie in die externe Komponente RoadRunner. Das Paket detail-page bildet das �Hauptpaket�. Es enthält die Klassen DetailPageExtractor , in welcher sichdie main()-Methode be�ndet, RRParser , LabeledElement , LabeledColumn, LabeledTable,InternalNode sowie Projection. In ihm sind sämtliche Funktionalitäten zusammengefaÿt, diebenötigt werden, um die intendierte Hierarchie (siehe Abschnitt 2.2.5) der Ergebnisseite zuextrahieren.Das Paket tokens enthält die Klassen TokenExtractor , TokenProcessor , Token, Text-

Token, FormToken, ImageToken und Separator . Es fasst einerseits die Funktionalitätenzusammen, die benötigt werden, um die Token von einer Webseite zu extrahieren (TokenEx-tractor und TokenProcessor), und andererseits alle Token-Typen als datenhaltende Klassen.Es ist abhängig vom Paket ole, dessen Funktionalität von der Klasse TokenExtractor zumAnsteuern der Rendering-Engine benötigt wird.Das Paket util enthält eine Reihe von Hilfsklassen (Util , Color , Style) sowie die Klasse

BoundingBox . Die Klasse Color enthält neben der De�nition eines Datentyps �Color� vorallem die Implementation des in Abschnitt 3.3.1 beschriebenen Algorithmus zum Vergleichzweier Farben im RGB-Farbraum. Die Klasse Style ist eine reine datenhaltende Klasse. DieKlasse BoundingBox enthält neben einem Datentyp �BoundingBox� vor allem Methoden, umdie diversen Beziehungen (Abstand, Ausrichtung, Schachtelung, . . . ) zweier Bounding Boxes

zueinander zu bestimmen.Das Paket ole enthält lediglich die Klasse OleObject , welche OLE-spezi�sche Methoden zu-

sammenfasst. In erster Linie sind dies Methoden zum Kapseln von API-Aufrufen bzw. um den

63

Zugri� auf die API zu vereinfachen. Diese Klasse wurde unverändert aus einem existierendenProjekt übernommen [17].

Abbildung 4.1.: Paketübersicht: DetailPageExtractor

4.2. Beschreibung der Komponenten

Das Gesamtsystem gliedert sich inhaltlich in drei groÿe Blöcke: Preprocessing, Processing undPostprocessing. Die RoadRunner-Komponente, die Rendering-Engine und der Tokenizerwerden zum Preprocessing gerechnet, wobei die Rendering-Engine als Teil des Tokenizersangesehen werden kann. Die eigentliche Logik des Prototyps steckt im zweiten Block � demProcessing. Dessen Bestandteile sind der Integrator, der Separator Finder sowie der HierarchyAnalyzer. Den letzten Block � das Postprocessing � bildet der Treebuilder. Einen Überblickhierüber gibt Abbildung 3.2 auf Seite 30.

4.2.1. RoadRunner

Die RoadRunner-Komponente wird als externe Komponente benutzt, um Variants zu er-kennen und diese als XML-Dokument abzulegen. Sie wird nicht direkt vom DetailPageExtrac-

tor eingebunden, sondern muÿ vielmehr gesondert aufgerufen werden. Daher taucht sie auchnicht im Klassendiagramm (Abbildung 4.2) respektive in der Paketübersicht (Abbildung 4.1)als Systembestandteil auf. Ferner wird auf eine Erklärung ihrer Funktion aus implementati-onstechnischer Sicht verzichtet [2, 5].

4.2.2. Rendering-Engine

Die Rendering-Engine dient, wie bereits in Abschnitt 3.3 beschrieben, dazu, die Webseite inToken zu zerlegen. Für die Implementierung des Prototyps war es wichtig, daÿ die Rendering-

64

Abbildung4.2.:Klassendiagramm:DetailPageExtractor

65

Engine eine API1 zur Verfügung stellt, über die auf die einzelnen Seitenelemente und derenEigenschaften zugegri�en werden kann. Grundsätzlich gilt dies für die meisten auf dem Marktbe�ndlichen Rendering-Engines (Gecko, Internet Explorer, Opera, Safari), jedoch sind derenAPIs häu�g schlecht dokumentiert, so daÿ eine sinnvolle Verwendung sehr schwierig ist. Da-her �el die Wahl auf die Rendering-Engine des Internet Explorers, deren API ausführlich imNetz dokumentiert ist.2 Insbesondere die Interfaces IHTMLCurrentStyle3 sowie IHTMLEle-

ment2 4 sind hierbei von Bedeutung. Das erstgenannte dient in erster Linie dazu, die relevantenStyle-Informationen des Tokens auszulesen, das letztgenannte stellt Methoden zum Auslesender Bounding Box des Tokens bereit. Die Verwendung der Rendering-Engine des InternetExplorers führt zu dem Nachteil, daÿ der Prototyp nunmehr nur noch auf Windows-Systemenausgeführt werden kann. Ob auch andere Betriebssysteme, auf denen der Internet Explorerverfügbar ist, hierfür in Frage kommen, wurde nicht getestet.Um die Rendering-Engine unter Java nutzen zu können, bedarf es einer Kapselung des

OLE-Aufrufs.5 Die hierzu notwendigen Methoden stellt das Standard Widget Toolkits (SWT)zur Verfügung. Dazu wird ein Container erstellt, der den Internet Explorer als OLE-Objektzunächst einbettet. Er besteht aus zwei Teilen; einem OleFrame, der für die Platzierung undGröÿe des Fensters sowie für eventuelle Veränderungen des Menüs zuständig ist, sowie einerOleControlSite, die die Steuerung des Internet Explorers über ActiveX ermöglicht.Zur Steuerung des Browsers ist ferner noch die Erzeugung eines OleAutomation-Objekts

notwendig, um Browser-spezi�sche Kommandos wie das Ö�nen einer Seite oder vor- undzurücknavigieren an den Browser durchzureichen. Das Auslesen der einzelnen Seitenelemente(Token) erfolgt innerhalb eines Eventhandlers des OleControlSite-Objekts. [16]Alle für die Einbindung der Rendering-Engine notwendigen Methodenaufrufe be�nden sich

in der Klasse TokenExtractor des Pakets tokens. Voraussetzung für die Nutzung des SWTs istdas Einbinden der Bibliothek org.eclipse.swt.win32.win32.x86_???.jar . �???� steht hierbeibei der Verwendung von Eclipse 3.3.2 für �3.3.3.v3349�.

4.2.3. Tokenizer

Der Tokenizer übernimmt die Anbindung und Steuerung der Rendering-Engine über ihre ge-kapselten Schnittstellen. Zunächst extrahiert er alle Token T , die auf der zu untersuchen-den Webseite vorkommen (Listing 4.1), sobald diese vollständig durch die Rendering-Enginegeladen wurde, und weist ihnen eine fortlaufende ID zu. Dazu wird mittels der MethodegetSubObjectByProperty der Klasse OleObject aus dem Paket ole auf durch die API derRendering-Engine bereitgestellte Objekte zugegri�en. In diesem Fall auf die geladene Seite(Listing 4.1, Zeile 2) und anschlieÿend auf alle Elemente dieser Seite (Listing 4.1, Zeile 3). DieToken-IDs sind abhängig von der Token-Art in Kategorien eingeteilt, die Tabelle 4.1 au�istet.

Nach dem erfolgreichen Auslesen aller Token T von der Seite, wird jedes Token t aus der

1Engl.: Abk. für �Application Programming Interface� = Schnittstelle zur Systemprogrammierung2http://msdn.microsoft.com/en-us/library/aa155133.aspx [letzter Besuch: 02.07.2008]3http://msdn.microsoft.com/en-us/library/aa704104.aspx [letzter Besuch: 02.07.2008]4http://msdn.microsoft.com/en-us/library/aa703984(VS.85).aspx [letzter Besuch: 02.07.2008]5Engl.: Abk. für �Object Linking and Embedding�

66

http://msdn.microsoft.com/en-us/library/aa155133.aspx


http://msdn.microsoft.com/en-us/library/aa703984(VS.85).aspx

1 OleObjec t o l eB rowse r = new OleObjec t ( webBrowser ) ;2 OleObjec t oleHtmlDocument = o l eBrowse r . ge tSubObjec tByProper ty ( "Document" ) ;3 OleObjec t o l eE l emen t s = oleHtmlDocument . ge tSubObjec tByProper ty ( " a l l " ) ;

Listing 4.1: Auslesen aller Token T mit Hilfe der Rendering-Engine

Menge T auf seinen Typ untersucht. Das entscheidene Kriterium für den Typ eines Tokensist sein HTML-Tag, welches in Zeile 2 des Listing 4.2 ausgelesen wird. Die Tags <SELECT>,<INPUT> sowie <TEXTAREA> identi�zieren Formtoken, das Tag <IMG> steht für ein Imageto-

ken. Alle anderen hier nicht aufgeführten Tags erzeugen ein Texttoken.

1 OleObjec t o l e I t em = o l eE l emen t s . getSubObjectByMethod ( " i tem" , " i ndex " , i ) ;2 S t r i n g tag = o l e I t em . g e t S t rP r o p e r t y ( "tagName" ) ;

Listing 4.2: Abfragen der Eigenschaften eines einzelnen Tokens t

Für jedes Token egal welchen Typs wird anschlieÿend die Bounding Box abgefragt (Listing4.3, Zeile 1). Jede Bounding Box wird, wie in Abschnitt 3.1.2 beschrieben, durch zwei Punktep1 und p2 aufgespannt. Die Koordinaten dieser Punkte werden in den Zeilen 2 und 3 sowiein den Zeilen 4 und 5 des Listing 4.3 abgefragt.

1 OleObjec t o leBound ingbox = o l e I t em . getSubObjectByMethod ( "ge tBound i ngC l i e n tRec t " ) ;

2 i n t l e f t = I n t e g e r . p a r s e I n t ( o leBound ingbox . g e t S t rP r o p e r t y ( " l e f t " ) ) ;3 i n t top = I n t e g e r . p a r s e I n t ( o leBound ingbox . g e t S t rP r o p e r t y ( " top " ) ) ;4 i n t r i g h t = I n t e g e r . p a r s e I n t ( o leBound ingbox . g e t S t rP r o p e r t y ( " r i g h t " ) ) ;5 i n t bottom = I n t e g e r . p a r s e I n t ( o leBound ingbox . g e t S t rP r o p e r t y ( "bottom" ) ) ;

Listing 4.3: Abfragen der Bounding Box des Tokens t

Abschlieÿend werden für jedes Token t aus der Menge T alle in Abschnitt 3.3 beschriebenenStyle-Informationen abgefragt (Listing 4.4). Dies erfolgt in ähnlicher Art und Weise wie bereitsdie Abfrage der Bounding Box für jedes Token. Maÿgeblich sind hier die Methoden bzw.Variablen des Interfaces IHTMLCurrentStyle der API des Internet Explorers.Die so extrahierten Token werden zunächst in einer Liste, die der Menge aller Token T

entspricht, zusammengefaÿt. Diese Liste muÿ, bevor sie an den Integrator weitergereicht wird,noch ge�ltert und bereinigt werden. Dies geschieht � im Gegensatz zur Extraktion, welche mitHilfe der Klasse TokenExtractor durchgeführt wurde � mit Hilfe der Klasse TokenProcessor .Der TokenProcessor überprüft zunächst mit Hilfe der Methode �lterTokens() jedes Text-

token tt aus der Menge T dahingehend, ob es teilweise in einem anderen Texttoken dieserMenge enthalten ist. Ist dies der Fall, so wird das Texttoken tt aus der Menge T entfernt.Somit ist gewährleistet, das nur �komplette� Token und keine Token-Artefakte in die spätereUntersuchung der Webseite ein�ieÿen. Dies könnte u. U. dazu führen, daÿ Token und Road-Runner-Variants nicht zusammengeführt werden könnten oder Labels nur in Bruchstückenerkannt werden würden. Ferner werden alle �leeren� Token aus der Menge T entfernt. �Leere�

67

1 OleObjec t o l e S t y l e s h e e t = o l e I t em . getSubObjec tByProper ty ( " c u r r e n t S t y l e " ) ;2 S t r i n g f gCo l o r = o l e S t y l e s h e e t . g e t S t rP r o p e r t y ( " c o l o r " ) ;3 S t r i n g bgCo lo r = o l e S t y l e s h e e t . g e t S t rP r o p e r t y ( " backgroundCo lo r " ) ;4 S t r i n g f o n t S i z e = o l e S t y l e s h e e t . g e t S t rP r o p e r t y ( " f o n t S i z e " ) ;5 S t r i n g f o n t S t y l e = o l e S t y l e s h e e t . g e t S t rP r o p e r t y ( " f o n t S t y l e " ) ;6 S t r i n g fontWeight = o l e S t y l e s h e e t . g e t S t rP r o p e r t y ( " fontWeight " ) ;7 S t r i n g f on tFam i l y = o l e S t y l e s h e e t . g e t S t rP r o p e r t y ( " f on tFam i l y " ) ;8 S t r i n g d i s p l a y = o l e S t y l e s h e e t . g e t S t rP r o p e r t y ( " d i s p l a y " ) ;9 S t r i n g v i s i b i l i t y = o l e S t y l e s h e e t . g e t S t rP r o p e r t y ( " v i s i b i l i t y " ) ;10 S t r i n g z I ndex = o l e S t y l e s h e e t . g e t S t rP r o p e r t y ( " z I ndex " ) ;

Listing 4.4: Abfragen der Style-Informationen des Texttokens tt

Token sind Token, deren Bounding Box keine Pixel enthält, oder Texttoken, die keinen Textenthalten (dies ist möglich, da Texttoken der �Default-Tokentyp� ist) oder die durch Setzendes Style-Attributs Display:none nicht dargestellt werden und für die in der gerendertenDarstellung kein Platzhalter vorgesehen ist.Ferner sorgt der TokenProcessor dafür, daÿ alle mehrzeiligen Texttoken in einzeilige Text-

token unter entsprechender Anpassung der Bounding Boxes aufgeteilt werden. Der hierfürnotwendige Algorithmus ist in der Methode splitMultiLineTokens() implementiert.Die Klasse TokenProcessor wurde weitestgehend unter geringen Anpassungen aus einem

vorhandenen Projekt übernommen [17].

Typ ID

unspezi�ziertes Token, LabeledElement < 10000LabeledColumn ≥ 10000LabeledMultiColumn ≥ 20000vertikaler Separator ≥ 30000horizontaler Separator ≥ 40000LabeledTable ≥ 50000Wurzelelement des Baums 60000

Tabelle 4.1.: Zuordnung der Token-IDs zum jeweiligen Token-Typ

4.2.4. Integrator

Die Integrator-Komponente dient dazu, alle von RoadRunner identi�zierten Variants mitdurch die Rendering-Engine extrahierten Token abzugleichen. Dies geschieht in zwei Schritten.Zunächst wird mittels einer Instanz der RRParser -Klasse die Datei xx0_Dataset.xml6 für

die zu untersuchende Seite eingelesen. Diese Datei enthält alle vonRoadRunner identi�zier-ten Variants der Beispielseite. Der RRParser nutzt dabei das Java Document Object Model

(JDOM), welches eine Anpassung des Document Object Models (DOM) für Java ist. ImGegensatz zum Original-DOM, welches Programmiersprachen-unabhängig ist, handelt es sich

6�xx� ist durch den Namen der zu untersuchenden Seite zu ersetzen.

68

bei JDOM um eine speziell auf Java zugeschnittene Implementierung. Sie nutzt Java-eigeneDatenstrukturen und Methodenaufrufe, was in einer gesteigerten Performanz gegenüber DOMresultiert.Entsprechend der Anzahl der mit RoadRunner untersuchten Instanzen der Beispielseite

enthält die Datei xx0_Dataset.xml <instance>-Blöcke. Diese Blöcke enthalten unterhalbdes Knotens <and> eine Liste der Variants, gekennzeichnet durch das Tag <attribute>

(siehe auch Listing 3.2 auf Seite Seite 46). Alle so gekennzeichneten Elemente werden als Listeextrahiert. In der derzeitigen Implementierung werden nur die Variants des ersten <instance>-Blocks extrahiert. Alle weiteren werden nicht beachtet. Entsprechend �ndet auch nur einAbgleich mit der ersten Instanz der Beispielseite (xx1.htm) statt.Die Liste der extrahierten Elemente wird mit der vom Tokenizer erzeugten Liste aller Text-

token abgeglichen. Der Abgleich erfolgt dabei auf der Basis eines Textvergleichs. Hierzu wirdder Text der Variant (z. B. �AMERICAN EAGLE�, Listing 3.2, Zeile 1) normalisiert, d. h., alleLeerzeichen vor und nach dem Text entfernt, sowie alle innerhalb des Textes vorkommendenLeerzeichen auf eins reduziert. Anschlieÿend wird überprüft, ob dieser normalisierte Text Be-standteil eines der Texttoken ist. Ist dies der Fall, so wird das korrespondierende Texttoken

als Variant markiert, indem das Attribut rrVariant des Texttokens auf true gesetzt wird.Im Anschluÿ daran werden alle als Variant markierten Texttoken in Labeled Elements über-

führt. Dabei werden alle Texttoken, deren IDs gleich sind, zuvor zu einem mehrzeiligen Text-

token zusammengefaÿt. Die Anzahl der Zeilen des neuen Tokens entspricht der Anzahl derTexttoken mit gleicher ID. Dieser Schritt ist notwendig, da der Tokenizer alle mehrzeiligenToken unter Beibehaltung ihrer ID auf einzeilige herunterbricht. Existierte beispielsweise zuvorein zweizeiliges Token mit der ID 345, so wird dieses durch den Tokenizer auf zwei einzeiligeToken, die jeweils die ID 345 haben, aufgesplittet. Für den Vergleich mit den von Road-Runner erkannten Variants ist dies durchaus nützlich, da RoadRunner nur einzeiligeVariants kennt. Für die weitere Verarbeitung ist dies hingegen hinderlich.

4.2.5. Separator Finder

Die Separator Finder-Komponente besteht aus den Methoden calcDataRegion und collectSe-parators, welche in der Klasse DetailPageExtractor im Paket detailpage implementiert sind.Darüberhinaus gehört die Klasse Projection aus dem gleichen Paket zur Separator Finder-Komponente.Die Methode calcDataRegion berechnet zunächst ausgehend von der Menge aller Paare

von RoadRunner-Variants und Texttoken, bezeichnet mit V , den Datenbereich. Dieserwird als Bounding Box repräsentiert und mit dr bezeichnet. Sei nun V = {v0, v1, . . . , vn}und |V | die Anzahl der Elemente, die in dieser Menge enthalten sind, sowie die Menge BB ={bbi|bbi = bb (vi) , v ∈ V, i ∈ N} die Menge der dazugehörigen Bounding Boxes, so läÿt sichder Datenbereich mit εx = 200 und εy = 300, wie in Listing 4.5 beschrieben, bestimmen.Zunächst wird in den Zeilen 4 bis 11 die kleinste, gemeinsame Bounding Box aller Elementeder Menge V bestimmt. Die linke Grenze dieser Bounding Box wird durch die linke Grenze desam weitesten links gelegenen Variants vleft (xp1 (vleft) ist minimal), die rechte Grenze analogdurch die rechte Grenze des am weitesten rechts gelegenen Variants vright (xp2 (vright) istmaximal), die obere Grenze durch die obere Grenze des am weitesten oben gelegenen Variants

69

vtop (yp1 (vtop) ist minimal) und die untere Grenze entsprechend durch die untere Kante derBounding Box des am weitesten unten gelegenen Variants vbottom (yp2 (vbottom) ist maximal)bestimmt. Anschlieÿend (ab Zeile 14) wird diese Bounding Box durch Verschieben der linkenund rechten Kanten um εx Pixel in x-Richtung bzw. der oberen und unteren Kanten umεy Pixel vergröÿert, wobei der linke und obere Seitenrand die maximale Ausdehnung desDatenbereichs in diese Richtungen darstellen.

1 Let dr = (left, top, right, bottom) be theDataregion with left = 10000 , top = 10000 , right = 0 , bottom = 0

2 Let bbi be the current Bounding Box from BB with i ∈ N ∧ i = 03 // summarize a l l BoundingBoxes to a l a r g e one4 do beg in

5 i f left (bbi) < left then left = left (bbi) f i

6 i f top (bbi) < top then top = top (bbi) f i

7 i f right (bbi) > right then right = right (bbi) f i

8 i f bottom (bbi) > bottom then bottom = bottom (bbi) f i

9

10 i = i+ 111 wh i l e ( i < |V |)12

13 // expand da t a r e g i o n14 i f left− εx < 0 then left = 0 e l s e left = left− εx f i

15 i f top− εy < 0 then top = 0 e l s e top = top− εy f i

16 right = right+ εx17 bottom = bottom+ εy18

19 r e t u r n dr

Listing 4.5: Pseudocode: Berechnung des Datenbereichs

Im Anschluÿ an die Berechnung des Datenbereichs erfolgt das Starten zweier Projektio-nen durch die Methode collectSeparators, wobei in der konkreten Implementierung nur dasVorhandensein eines Tokens nicht jedoch etwaige Farbwechsel berücksichtigt werden. DasListing 4.6 beschreibt exemplarisch die Projektion in y-Richtung. Dazu wird für jede Stelleentlang der y-Achse die Breite (�width�) jedes an dieser Stelle vorhandenen Tokens aufaddiert.In der derzeitigen Implementierung werden beide Projektionen sequentiell abgearbeitet. Dieparallele Berechnung beider Projektionen wäre eine denkbare Verbesserung, die sich jedochkaum spürbar auf die Performanz auswirken dürfte, da die Mengen, die für die Berechnungder Projektion durchlaufen werden, durch die vorherige Einschränkung des Datenbereichs nurwenige Elemente enthalten.Nach erfolgter Projektion werden für jede der beiden Projektionen die Minima und Nullstel-

len berechnet. Dies geschieht durch Aufruf der jeweiligen Member-Funktionen �ndSeparator()der Projektionen. Das Ergebnis sind zwei Listen, die alle horizontalen Separatoren als Spezia-lisierung eines Tokens und alle vertikalen enthalten. Wie Token auch enthalten Separatoren

eine ID. Zur besseren Unterscheidbarkeit erhalten vertikale Separatoren eine fortlaufende ID,die gröÿer als 30000 ist. Horizontale Separatoren erhalten entsprechend eine ID, die gröÿerals 40000 ist. Eine Übersicht über die Verteilung der IDs der Token gibt Tabelle 4.1.

70

1 I nput : dr , the calculated dataregion ;2 T ′ ⊆ T , the subset of all Token located inside the dataregion dr3 Output : a set of projections {p}4

5 Let pi be the projection to the y-axis at position i with i ∈ [top, bottom]6 Let P be the set of all projections pi

7 f o r each (t ∈ T ′ ) do

8 i = top (bb (t))9 do beg in

10 pi = pi + width (bb (t))11 i = i+ 112 wh i l e ( i ≤ bottom (bb (t)))13 r o f

14

15 r e t u r n P

Listing 4.6: Pseudocode: Projektion auf die y-Achse

4.2.6. Hierarchy Finder

Die Hierarchy Finder-Komponente bildet den Schwerpunkt der Implementierung. In ihr stecktder Groÿteil der Programmlogik. Bestandteil dieser Komponente sind die folgenden Methodender Klasse DetailPageExtractor . Sie werden innerhalb der main()-Methode bzw. von einerder aufgeführten Methoden in der untenstehenden Reihenfolge aufgerufen und sequentiellausgeführt.

buildCols() Diese Methode gruppiert alle Labeled Elements anhand der linken Kanten ihrerBounding Boxes zu Spalten zusammen. Dabei werden insbesondere horizontale Sepa-

ratoren als obere und untere Spaltengrenzen berücksichtigt. Sie greift dabei direkt aufdie drei Listen labeledElements, hSeparators und columns zu, die den Mengen V(Menge aller Texttokens, die ein korrespondierendes RoadRunner-Variant haben),Shoriz (Menge aller horizontalen Separatoren) und LC (Menge aller Labeled Columns)entsprechen. Die Methode isColAlign() zur Überprüfung, ob zwei Bounding Boxes ver-tikal zueinander ausgerichtet sind, ist Bestandteil der Klasse BoundingBox , die bis aufkleine Modi�kationen vollständig übernommen wurde. In ihr ist auch der Schwellwertε = 2 für die maximale zulässige Verschiebung der linken Kanten, um noch als vertikalausgerichtet zu gelten, de�niert.

assignColumLabels() Diese Methode startet für jedes Element der Menge LC die Me-thode �ndLabelCandidate() und weist ihm das von dieser Methode zurückgegebeneLabel zu.

�ndLabelCandidate(BoundingBox bb) Diese Methode erwartet als Parameter die Boun-ding Box der Spalte, für die ein Label gesucht werden soll. Die Rückgabe besteht auseinem einoder mehrzeiligen Labeled Element, welches das Label der Spalte ist. DiesesLabeled Element wird zuvor durch die Methode combineToken() aus dem der Spalteno-berkante nächstgelegenen Texttoken und seinen eventuell vorhandenen �Geschwistern�erzeugt.

71

Zum Au�nden eines Labels sind zwei Iterationen über die Menge TT aller Texttokenvorgesehen, wobei die zweite nur durchgeführt wird, wenn zuvor kein Label gefundenwurde. Während der ersten Iteration werden linksausgerichtete Labels gesucht. Soll-te diese Suche erfolglos bleiben, so werden in der zweiten Iteration zentrierte Labelsgesucht. Das Kriterium dafür, ob das Label im Verhältnis zur Spalte linksausgerichtetist, ist wie bei der Gruppierung zu Spalten die linke Kante der Bounding Box . Die-se Überprüfung wird mit der Member-Methode isColAlign() der Klasse BoundingBoxvorgenommen. Ob ein Label zentriert zur Splate ist, hängt davon ab, ob die Mittelpunk-te der Label-Bounding Box und der Spalten-Bounding Box mit einer Abweichung vonε = 2 vertikal zueinander ausgerichtet sind. Die Berechnung der Mittelpunkte erfolgtmittels der Member-Methode getColCenter() der BoundingBox -Klasse, wobei diesenur die benötigte x-Koordinate des Mittelpunkts der Bounding Box berechnet.

Bei beiden Iterationen wird jeweils zusätzlich geprüft, ob ein potentielles Label nichtschon Bestandteil der Spalte ist, indem die Member-Methode contains() auf die Boun-ding Boxes der Spalte und des Labelkandidaten angewandt wird. Ferner wird mittelsder Member-Methode above() die Position der Bounding Box des Labelkandidaten mitder der Spalten-Bounding Box verglichen. Zusätzlich wird mittels der Methode horiz-Divided überprüft, ob sich zwischen beiden Bounding Boxes ein horizontaler Separatorbe�ndet. Abschlieÿend wird überprüft, ob der aktuelle Labelkandidat näher an der Ober-kante der Spalten-Bounding Box liegt als alle bisher untersuchten.

Sind alle Überprüfungen erfolgreich, so wird der Spalte das Label mittels der Member-Methode addTopLabel() zugeordnet. Diese Methode bewirkt einerseits, daÿ die Member-Variable topLabel der Instanz der Spalte mit dem entsprechenden Label belegt wird, undandererseits führt sie eine Umorganisation der Liste cells der LabeledColumn-Instanzdurch, indem alle in ihr enthaltenen Elemente um eine Indexposition nach hinten ge-schoben werden und das Label an Position 0 eingefügt wird. Anschlieÿend wird dieBounding Box neu berechnet, so daÿ nun auch das Label in dieser enthalten ist.

combineToken(TextToken tok) Die Methode combineToken überprüft zunächst, ob einweiteres Texttoken mit der gleichen ID des übergebenen Texttokens in der Menge TTexistiert. Ist dies der Fall, so werden diese miteinander zu einem mehrzeiligen Labeled

Element kombiniert und zurückgegeben. Existiert kein zweites Texttoken mit dieser ID,so wird das übergebene Texttoken in ein Labeled Element umgewandelt und zurückge-geben.

Mehrzeilige Texttoken werden wie beschrieben im Zuge der Tokenization in einzeiligeTexttoken aufgespaltet. Da jedoch alle hieraus entstehenden Texttoken ihre ursprüng-liche ID beibehalten und somit �Geschwister� sind, ist es mögliche, diese ID zum Ver-einigen der Fragmente zu nutzen.

�ndMultiColumnCandidates() Die Methode �ndMultiColumnCandidates() markiertalle Labeled Columns, die als potentieller Bestandteil einer Labeled Multi Column infrage kommen, indem das Attribut multiColCandidate der jeweiligen Instanz der KlasseLabeledColumn auf �true� gesetzt wird. Ausschlaggebend ist die Position der Oberkante

72

der Spalten im Vergleich zur höchsten Oberkante einer Spalte aus der Menge LC, wel-che durch die Liste columns repäsentiert wird. Die Bestimmung dieses Referenzpunktserfolgt durch Aufruf der Methode maxColHeight().

buildMultiCols() Diese Methode gruppiert in zwei Schritten Labeled Columns zu Labeled

Multi Columns zusammen, indem sie im ersten Schritt alle mit der Methode �nd-

MultiColumnCandidates() als Kandidaten markierten Labeled Columns mit einem zu-sätzlichen Label versieht. Im zweiten Schritt werden alle Labeled Columns, für die einLabel gefunden werden konnte, anhand gleicher Labels zu einer Labeled Multi Column

zusammengefaÿt.

Zunächst werden mit Hilfe der Methode getMultiColCandidates() alle Labeled Co-

lumns, deren Attribut multiColCandidate �true� ist, aus der Liste der Labeled Columns

(columns) extrahiert und deren Referenzen in eine neue Liste kopiert. Diese bildet dieGrundlage für die weitere Ausführung der Methode. Im ersten Durchlauf durch dieseListe wird für jedes Element der Liste ein Texttoken gesucht, welches die Bedingungenfür ein Spalten-übergreifendes Label erfüllt. Wird zu einer Spalte aus dieser Liste keinLabel gefunden, wird das Attribut multiColCandidate dieser LabeledColumn-Instanzauf �false� gesetzt.

Im zweiten Schritt wird als erstes die Liste der Labeled Multi Column-Kandidaten durcherneuten Aufruf der Methode getMultiColCandidates() aktualisiert, da infolge der vor-herigen Untersuchungen u. U. Spalten aus dieser Liste herausgefallen sein könnten. An-schlieÿend werden alle Elemente dieser Liste, sofern sie nicht schon Bestandteil einerLabeled Multi Column sind, auf gleiche Labels untersucht und zusammengefasst, wennihre Labels gleich sind. Um Instanzen der Klasse LabeledColumn als Bestandteil einerLabeled Multi Column zu markieren, wird das Attribut colAligned auf �true� gesetzt.

Labeled Multi Columns sind aus implementierungstechnischer Sicht nur Labeled Co-

lumns. Entsprechend werden sie auf Instanzen der Klasse LabeledColumn abgebildet,wobei die Liste cells anstelle von Instanzen der Klasse LabeledElement Instanzen derKlasse LabeledColumns enthält. Um diese Instanzen dennoch ohne groÿen Aufwand alsLabeled Multi Columns identi�zieren zu können, ist bei ihnen des Attribut multiColumnauf �true� gesetzt und ihre ID stammt aus dem 20000er-Bereich (siehe Tabelle 4.1).Wie alle Instanzen der Klasse LabeledColumn sind auch sie Element der columns-Listeder Klasse DetailPageExtractor . Daher ist es möglich, daÿ Labeled Multi Columns

selbst wieder Bestandteil einer weiteren Labeled Multi Column sein können. Ein erneu-ter Aufruf der Methoden �ndMultiColumnCandidates() und buildMultiCols() würdediese Zuordnung vornehmen, sofern diese auf der Seite existiert.

buildTables() Die Methode buildTables() gruppiert alle Elemente der Liste columns zu Ta-bellen, die durch Instanzen der Klasse LabeledTable repräsentiert werden. Jede dieserLabeledTable-Instanzen ist wiederum Element der Liste labeledTables der Klasse Detail-PageExtractor . Jede LabeledTable-Instanz enthält eine Liste (columns) aller Spalten,deren Oberkanten in einer Zeile ausgerichtet sind. Die Ausrichtung der Spalten wirdmittels der Member-Methode isRowAlign() der BoundingBox -Klasse überprüft. Dortist auch die maximale Toleranz von ε = 2 Pixel für die Ausrichtung festgelegt.

73

Spalten, die sich keiner bereits existierenden Tabelle zuordnen lassen, erzeugen eineneue Tabelle, sofern sie nicht Bestandteil einer Labeled Multi Column sind. Dies wirddurch Abfragen des Attributs colAligned überprüft. Ist dies �true�, so ist die SpalteBestandteil einer Labeled Multi Column und es wird keine neue Tabelle erzeugt.

assignTabLabels() Die Methode assignTabLabels() versucht, jeder zuvor erkannten Ta-belle ein Label zuzuordnen. Dazu wird für jede dieser Tabellen aus der Liste aller Text-tokens (processedTTokens) ein Texttoken herausge�ltert, welches sich innerhalb deroberen Scope Bounding Box der Tabelle be�ndet. Die hierfür notwendige Überprüfungerfolgt mit der Member-Methode contains() der Klasse BoundingBox . Im nächstenSchritt wird mittels der Member-Methode getColDistance(), welche ebenfalls aus derBoundingBox -Klasse stammt, die Entfernung zur oberen Kante der Bounding Box

der Tabelle überprüft. Ist diese minimal gegenüber den bisher untersuchten möglichenLabels, so werden für dieses Texttoken keine weiteren Kriterien mehr überprüft. Andern-falls wird anschlieÿend überprüft, ob sich das Texttoken horizontal zentriert in der ScopeBounding Box be�ndet. Ist dies nicht der Fall, so wird durch Vergleich der Positionen derMittelpunkte der Bounding Boxes des Texttokens und der Scope Bounding Box über-prüft, ob sich das Texttoken links vom Mittelpunkt be�ndet. Die Position der BoundingBox-Mittelpunkte wird mit der Member-Methode getColCenter() berechnet. Be�ndetsich das Texttoken links vom Mittelpunkt der Scope Bounding Box , wird abschlieÿendnoch überprüft, ob es aus mindestens einem Buchstaben oder einer Zi�er besteht. Hierzuwird es, sofern seine Länge = 1 ist, gegen den regulären Ausdruck �\p{Punct}+� getes-tet, der besagt, daÿ ein Zeichen der Menge �!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~�mindestens einmal vorkommt. Schlägt dieser Test fehl, so enthält das einstellige Text-

token keines dieser Zeichen und kommt als Tabellenlabel in Frage.

4.2.7. Treebuilder

Die Treebuilder-Komponente besteht aus der Klasse TreeGenerator sowie aus den Member-Methoden printTree() und printXmlNode(). Beide Methoden sind sowohl in der KlasseLabeledElement als auch in der Klasse InternalNode implementiert. Die Generierung desBaums wird durch Erzeugen einer Instanz der TreeGenerator -Klasse sowie durch Aufrufenihrer Member-Methode printTree() angestoÿen.Die Erzeugung des Baums erfolgt rekursiv, indem die printTree()-Methode des Wurzelele-

ments aufgerufen wird. Das Wurzelelement wurde bereits beim Instanziieren der TreeGene-rator -Klasse erzeugt und ist eine Instanz der Klasse InternalNode. Seine ID ist 60000 (sieheTabelle 4.1). Die Kinder des Wurzelelements sind alle zuvor identi�zierten Tabellen vom TypLabeledTable, welcher eine Erweiterung der InternalNode-Klasse ist. Durch rekursives Auf-rufen der printTree()-Methode der Kindelemente wird der Baum erzeugt und ausgegeben.Handelt es sich bei einem der Kindelemente um eins vom Typ LabeledColumn, so wird dessenerstes Kindelement (gespeichert in der Liste cells) übersprungen, da es sich hierbei um dasSpaltenlabel handelt.Abschlieÿend wird durch die printTree()-Methode der TreeGenerator -Instanz die Methode

persistXML gestartet. Diese erzeugt zunächst eine XML-Darstellung des Baums und legt diese

74

anschlieÿend unterhalb des Projektverzeichnisses im Verzeichnis web als tree.xml ab. MitHilfe einer Reihe von HTML-Seiten und Javascript-Code kann der Baum anschlieÿend durchÖ�nen der Datei FrameTree.html in einem Browser7 visualisiert werden.Ein Groÿteil der Treebuilder-Komponente wurde aus einem anderen Projekt übernommen

und nur an die Rahmenbedingungen dieser Arbeit angepaÿt [17].

4.3. Grenzen des Prototyps

Der Prototyp stöÿt insbesondere während des Preprocessings desöfteren an seine Grenzen.Werden Informationen nicht als Text dargestellt, der sich an irgendeiner Stelle im Seiten-quelltext wieder�ndet, ist der RoadRunner nicht in der Lage, diese zu untersuchen undeventuell als Variant zu erkennen. Dieser Fall tritt vor allem dann auf, wenn Text in Gra�keneingebettet ist oder wenn die Information selbst nicht textuell sondern nur durch eine Gra�k inForm eines Logos oder Piktogramms dargestellt wird. Nicht verarbeitbar sind darüberhinausSeiteninhalte, die in Form einer Flash-Animation8 präsentiert werden oder durch client-seitigesJavascript erzeugt werden. Der Grund hierfür liegt einerseits in der nicht vorhandenen Unter-stützung dieser Techniken durch den RoadRunner. Andererseits werden diese Technikenzwar durch die Rendering-Engine erkannt, jedoch nur mit Hilfe von Zusatzprogrammen ausge-führt. Die Rendering-Engine liefert für beide Techniken u. U. eine Bounding Box und weitereInformationen, jedoch beziehen sich diese nicht auf die durch diese Techniken dargestelltenInhalte, sondern vielmehr auf den �Platzhalter� für das Javascript oder die Flash-Animation.Ein weiteres Problem tritt auf, wenn auf mehreren Seiten einer Class of Pages identische

Informationen vorkommen. Bei denen für diese Arbeit hauptsächlich untersuchten Buchungs-seiten von Fluggesellschaften ist dies in der Regel der Name der Fluggesellschaft. Werden dieFlüge nicht durch Partner-Airlines durchgeführt, so taucht bei jedem Flug als durchführendeFluggesellschaft die selbe Information auf. Da die Identi�kation von Variants jedoch auf derErkennung von Unterschieden basiert und bei gleichen Informationen kein Unterschied exis-tiert, können diese Informationen nicht als Variant erkannt werden. Die Abbildungen 3.12(a)und 3.12(b) auf Seite 44 zeigen so einen Fall. Der Carrier ist für fast jeden Flug �AmericanAirlines�. Der Vergleich beider Seiten würde zumindest für die erste Verbindung �AmericanEagle� bzw. �American Airlines� noch als Unterschied hervorbringen, bei der zweiten Flug-verbindung ist jedoch der Carrier beide Male �American Airlines�, so daÿ kein Unterschiedmehr existiert und folglich auch kein Variant existiert. Dieser Umstand führt leider in derKonsequenz zu unvollständigen Ergebnissen.Darüberhinaus berücksichtigt der Prototyp derzeit keine Farbinformationen bei der Projekti-

on. Dies liegt vor allem daran, daÿ diese Informationen zwar über die API der Rendering-Engineabfragbar sind, sie aber aufgrund von Überlagerung mehrerer Elemente nicht unbedingt derDarstellung auf der Webseite entsprechen müssen. Da das Preprocessing derzeit nur eine zwei-dimensionale �Sicht� auf die zu untersuchenden Seiten hat, wird infolgedessen nur die obersteSchicht der Seite für die Untersuchungen herangezogen. (Farb-)Informationen aus weiter un-ten liegenden Schichten, die aufgrund eventuell vorhandener Transparenz der Schichten auch

7Am besten eignet sich hierfür der Internet Explorer mit aktivierten Skripten.8Adobe Flash, Vektorgra�k-basierte Technik um Animationen oder interaktive Webseiten zu gestalten

75

in der oberen Schicht sichtbar sind, werden somit nicht berücksichtigt. Abbildung 3.5 aufSeite 39 zeigt so einen Fall.

76

5. Benutzung des Prototyps

Dieses Kapitel beschreibt zunächst die grundlegenden Schritte, die für die Installation desDetailPageExtractors notwendig sind. Anschlieÿend wird eine kurze Einführung in seine Be-nutzung anhand eines Beispiels gegeben.Da die Entwicklung maÿgeblich mit Hilfe der Entwicklungsplattform Eclipse1 stattgefunden

hat, beziehen sich alle Erklärungen und Beschreibungen in diesem Kapitel auf die derzeitaktuelle Version (Europa 3.3.2). Die Ausführung ohne Eclipse ist dennoch möglich, sofernalle benötigten Bibliotheken, die teilweise Bestandteil von Eclipse sind, vorhanden sind. Desweiteren ist der Prototyp des DetailPageExtractors nur unter Windows lau�ähig.

5.1. Installation und Einrichtung

Zur Installation des DetailPageExtractors ist es zunächst notwendig, den Inhalt des Ver-zeichnisses /DetailPageExtractor auf der beiliegenden CD in Eclipse als neues Projekt zuimportieren. Am einfachsten geht dies mit der Option �Existing Projects into Workspace�. DasWurzelverzeichnis des DetailPageExtractors enthält bereits die von Eclipse hierfür benötigtenDateien .classpath sowie .project.

5.1.1. Anpassen von Pfaden

Als nächstes muÿ der Java Build Path in den Project Properties angepaÿt werden. Hierbei istdarauf zu achten, daÿ die Bibliothek org.eclipse.swt.win32.win32.x86_3.3.3.v3349.jar ausdem /plugins-Verzeichnis von Eclipse eingebunden wird. Je nach Eclipse-Version kann dieVersionsnummer der Bibliothek variieren. Dies sollte jedoch keinen Ein�uÿ auf die Ausführungdes DetailPageExtractors haben.Des weiteren muÿ in der Klasse DetailPageExtractor der Wert der Kostanten DP_PATH

auf den absoluten Pfad zu den zu untersuchenden Webseiten gesetzt werden. Basierend aufdiesem Wert wird später die an den Internet Explorer zu übergebene URL der Webseite sowieder Pfad zur gespeicherten Ausgabe des RoadRunners konstruiert. Daher ist es wichtig,daÿ die Pfadangabe mit einem �/� endet. Neuere Versionen des Internet Explorers erforderndarüber hinaus die explizite Angabe des Protokolls (file:///).Damit ist die Einrichtung des DetailPageExtractors abgeschlossen. Bei Verwendung der im

Unterverzeichnis /detailpages liegenden vorbereiteten Testdaten kann der DetailPageEx-tractor wie in Abschnitt 5.2.2 beschrieben gestartet werden. Sollen andere Webseiten als diebereits vorbereiteten untersucht werden, so müssen zunächst noch Testdaten erzeugt werden(siehe Abschnitt 5.2.1).

1http://www.eclipse.org [letzter Besuch: 07.07.2008]

77

http://www.eclipse.org

5.2. Durchführung eines Beispiellaufs

Nach erfolgter Installation und Einrichtung des DetailPageExtractor wird im Folgenden dieDurchführung eines exemplarischen Beispiellaufs beschrieben. Die nachfolgenden Schrittemüssen für jedes Testdatenset wiederholt werden. Wurde ein Testdatenset einmal erstellt,kann bei einer erneuten Ausführung des DetailPageExtractor auf das Erstellen von Testdaten(Abschnitt 5.2.1) verzichtet werden.

5.2.1. Erstellen von Testdaten

Zunächst müssen mindestens zwei verschiedene Instanzen einer Class of Pages abgespeichertwerden. Die gängigen Webbrowser bieten hierfür einen Befehl in der Art �Seite speichern un-ter. . . � an. Beide Instanzen müssen einen einheitlichen Namen haben, der sich nur durch einefortlaufende Nummer (startend bei �1�) unterscheidet. Die verschiedenen Instanzen solltenmöglichst keine bis wenige gleiche Daten enthalten, da der RoadRunner sonst möglicher-weise nicht alle Variants identi�zieren kann.Es ist zwingend erforderlich, daÿ alle Instanzen im Unterverzeichnis /detailpages des

Stammverzeichnisses /DetailPageExtractor abgelegt werden, wobei jede Class of Pages

in einem eigenen Unterverzeichnis liegen muÿ. Für die Class of Pages �American Airlines�,bezeichnet mit �aa�, mit zwei Instanzen sähe der relevante Teil des Verzeichnisbaums somitwie folgt aus.

/ DetailPageExtractor

/ detailpages

/ aa

aa1.htm

aa2.htm

Extrahieren der Variants mit Hilfe von RoadRunner

Im nächsten Schritt werden aus diesen beiden Instanzen mit Hilfe des RoadRunners alleVariants extrahiert. Hierzu ist es sinnvoll, den RoadRunner als Projekt in Eclipse zu im-portieren. Der Quellcode sowie alle benötigten Bibliotheken be�ndet sich auf der beiliegendenCD im Verzeichnis /RoadRunner und den darunter liegenden Unterverzeichnissen.Nach dem erfolgreichen Importieren in Eclipse ö�net man zunächst noch den �Run Dialog�

(Abbildung 5.1) durch den Menü-Befehl �Run → Open Run Dialog. . . �, um RoadRunner

für die Ausführung benötigte Parameter übergeben zu können. Im Run Dialog wählt manals Projekt �RoadRunner� und als Main Class �roadrunner.Shell� aus. Anschlieÿend gibt manim Dialog �(x)=Arguments�, welcher sich durch Klicken auf den gleichnamigen Karteireiterö�net, die zum Starten notwendigen Argumente im Feld �Programm arguments� ein. Für daskonkrete Beispiel lauten diese Parameter:

-Naa /DetailPageExtractor/detailpages/aa/aa1.htm

/DetailPageExtractor/detailpages/aa/aa2.htm

78

Die Option -N legt hierbei den Namen, den RoadRunner dem durch ihn erstellten Wrappergibt, fest. Dieser Name sollte sinnvollerweise identisch mit dem Namen der Testseiten sein.

Abbildung 5.1.: Run Dialog von Eclipse

Die Ausgabe von RoadRunner für das o. g. Beispiel be�ndet sich nach erfolgreichemDurchlauf im Verzeichnis /output/aa unterhalb des RoadRunner-Stammverzeichnisses.Dort �ndet sich eine Datei namens aa0_DataSet.xml. In ihr sind alle erkannten Variantsenthalten. Diese Datei muÿ nun in das Verzeichnis /output, das unterhalb des Verzeichnisses/aa angelegt werden muÿ, kopiert werden. Der resultierende Verzeichnisbaum sieht wie folgtaus.


/ detailpages

/ aa

/ output ←aa0_DataSet.xml

aa1.htm

aa2.htm

79

5.2.2. Starten des DetailPageExtractors

Nachdem die Testdaten nun erstellt wurden, kann der DetailPageExtractor ausgeführt werden.Dazu muÿ in der Klasse DetailPageExtractor der Wert der Kostante DP_NAME auf �aa� gesetztwerden. Anschlieÿend kann der DetailPageExtractor durch Auswahl des Menü-Befehls �Run→ Run� ausgeführt werden.Nach dem Starten des DetailPageExtractors ö�net sich nach kurzer Zeit ein Fenster, in

dem die erste Testseite � in diesem Fall aa1.htm � dargestellt wird. Bei dem Fenster handeltes sich um eine Instanz des Internet Explorers. Diese Fenster muÿ geschlossen werden, sobalddie Ausgabe auf der Konsole stoppt. Bis zu dem Zeitpunkt wurden alle Token mit ihrenStyle-Informationen ausgegeben. Dies entspricht weitesgehend dem Preprocessing.Nach dem Schlieÿen des Fensters setzt sich die Ausgabe auf der Konsole fort. Nun folgen

die Ausgaben des Processings. Zunächst folgt die Ausgabe aller Texttoken, die ein korrespon-dierendes RoadRunner-Variant haben (siehe Listing 5.1). Der Wert nach dem �#� stelltdie ID des Tokens und die Werte in eckigen Klammern die Koordinaten der Bounding Box

dar. Nach dem Doppelpunkt folgen die Style-Informationen.

1 t #462[144 ,464 ,282 ,477]AMERICAN EAGLE,#000000 , t r a n s p a r e n t , 10 px , normal , 400 ,a r i a l , h e l v e t i c a , sans−s e r i f , b lock , i n h e r i t , 0

2 t #464[285 ,451 ,334 ,464]280 ,#000000 , t r a n s pa r e n t , 10 px , normal , 400 , a r i a l ,h e l v e t i c a , sans−s e r i f , b lock , i n h e r i t , 0

3 t #466[337 ,451 ,442 ,464]LAX Los Ange les ,#000000 , t r a n s pa r e n t , 10 px , normal , 400 ,a r i a l , h e l v e t i c a , sans−s e r i f , b lock , i n h e r i t , 0

4 t #468[445 ,445 ,528 ,457]Nov 20 , 2007 ,#000000 , t r a n s p a r e n t , 10 px , normal , 400 ,a r i a l , h e l v e t i c a , sans−s e r i f , b lock , i n h e r i t , 0

5 t #471[531 ,451 ,636 ,464]MIA Miami ,#000000 , t r a n s p a r e n t , 10 px , normal , 400 , a r i a l ,h e l v e t i c a , sans−s e r i f , b lock , i n h e r i t , 0

Listing 5.1: gekürzte Ausgabe des DetailPageExtractors: Texttoken-Variant-Korrespondenzen

Weitere Ausgaben sind alle identi�zierten Spalten (Listing 5.2 und Listing 5.3). Ihre Ausga-be beinhaltet neben der Bounding Box , das Label (durch �L#. . . � gekennzeichnet) und alleenthaltenen Labeled Elements. Anhand der ID läÿt sich erkennen, ob es sich um eine LabeledColumn (ID ≥10000) oder eine Labeled Multi Column (ID ≥20000) handelt.

1 Columns2 =======3 #10462 [144 ,404 ,282 ,477 ] : L#436 C a r r i e r : #462 AMERICAN EAGLE ,4 #10464 [285 ,404 ,334 ,506 ] : L#438 F l i g h t5 Number : #464 280 , #485 978 ,6 #10466 [337 ,421 ,442 ,506 ] : L#449 C i t y : #466 LAX Los Ange les , #487 MIA Miami ,7 #10468 [445 ,421 ,528 ,512 ] : L#451 Date & Time : #468 Nov 20 , 20078 09 :05 AM, #489 Nov 22 , 20079 08 :30 PM,10 #10471 [531 ,421 ,636 ,506 ] : L#453 C i t y : #471 MIA Miami , #492 LAX Los Ange les ,

Listing 5.2: gekürzte Ausgabe des DetailPageExtractors: Labeled Columns

80

1 #20466 [337 ,404 ,528 ,512 ] : L#441 Depa r t i ng : C#10466 Ci ty , C#10468 Date & Time2 #20471 [531 ,404 ,722 ,512 ] : L#443 A r r i v i n g : C#10471 Ci ty , C#10473 Date & Time ,

Listing 5.3: gekürzte Ausgabe des DetailPageExtractors: Labeled Multi Columns

Im Anschluÿ folgen die Ausgabe der Data Region, der Separatoren sowie aller Labeled Multi

Column-Kandidaten. Diese folgen ähnlichen Darstellungsmustern, wie die zuvor beschriebe-nen. Abschlieÿend folgt die Ausgabe aller identi�zierten Tabellen (siehe Listing 5.4) mit denin ihnen enthaltenen Spalten (nur IDs). Damit ist die Ausgabe des Processings abgeschlossen.

1 Tab le s2 ======3 #50462 [144 ,404 ,774 ,512 ] : Table 1 : L#415 Your I t i n e r a r y : #10462 , #10464 ,

#10476 , #20466 , #20471 ,4 #50553 [146 ,549 ,773 ,643 ] : Table 12 : L#508 Fare Summary : #20553 , #20553 ,

Listing 5.4: gekürzte Ausgabe des DetailPageExtractors: Labeled Multi Columns

Die letzte Ausgabe auf der Konsole ist die Ausgabe des Treebuilders (siehe Listing A.1 abZeile 71).

5.2.3. Ö�nen der Baumvisualisierung

Um den von der Treebuilder-Komponente erzeugten Baum visualisieren zu lassen, muÿ nunnoch die Datei FrameTree.html im Verzeichnis /web unterhalb des Wurzelverzeichnissesdes DetailPageExtractors in einem Browser geö�net werden. Hierfür emp�ehlt sich der Inter-net Explorer, da Firefox (Version 3.0) mit dem verwendeten Javascript nicht zurechtkommt.Abbildung 5.2 zeigt die gra�sche Darstellung des Baums.Auf der linken Seite der Anzeige ist der extrahierte Baum dargestellt. Durch Klicken auf

einen der Knoten wird im rechten der Teil der Anzeige die Bounding Box des Knotens in deruntersuchten Seite grün eingezeichnet. Läÿt man den Mouse-Cursor einen kurzen Momentauf einem Knoten verweilen, blendet sich ein Tooltip mit allen Informationen über den Knotenein. Diese Informationen bestehen vor allem aus den Koordinaten der Bounding Box und derLabels.

81

Abbildung 5.2.: Visualisierung des Baums im Browser

82

6. Zusammenfassung und Ausblick

Zum Abschluÿ der Arbeit gibt dieses Kapitel noch einmal eine kurze Zusammenfassung überdie Ziele und inwiefern diese erreicht wurden. Im Ausblick werden ferner mögliche Lösungswegeaufgezeigt, um die während der Umsetzung aufgetretenen Probleme zu umgehen oder zu lösen.

6.1. Zusammenfassung

In dieser Arbeit wurde zunächst eine kurze Einführung in die Integration von Informations-systemen gegeben. Insbesondere lag der Schwerpunkt auf Webinformationssystemen und denProblemen, die aus ihren nach auÿen hin sehr eingeschränkten Schnittstellen im Hinblick aufihre Integration auftreten. Ferner wurden verschiedene existierende Ansätze � vor allem nichtHTML-basierte � zum Lösen dieser Probleme vorgestellt.Darüberhinaus wurde ein Algorithmus zum Extrahieren der intendierten Hierarchie auf Er-

gebnisseiten konzipiert, welcher weitestgehend auf der Verwendung von visuellen Merkmalenbasiert. Der Schwerpunkt lag insbesondere auf der Erkennung von mehrstu�gen Hierarchi-en. Dieser Algorithmus wurde prototypisch implementiert, um die generelle Machbarkeit zudemonstrieren.

6.2. Fazit

Webinformationssysteme als Datenquellen für andere Informationssysteme zu nutzen ist undbleibt eine Herausforderung. Insbesondere die Extraktion der Schemata bzw. der Hierarchiender dargestellten Daten ist nicht trivial selbst bei verhältnismäÿig einfach aufgebauten Seiten,bei denen die Hierarchie sehr o�ensichtlich in Form von Tabellen dargestellt ist.Der Ansatz, die Daten und ihre intendierte Hierarchie weitestgehend ohne Berücksichtigung

des Quellcodes zu extrahieren, geht tendenziell in die richtige Richtung, da es mittlerweilefast keine Webseite mehr gibt, die nur noch aus reinem HTML-Code besteht. Die meistenSeiten nutzen Cascading Stylesheets (CSS), die die Darstellung massiv beein�ussen könnenund somit verhindern, daÿ verläÿliche Rückschlüsse über die Hierarchie aus dem Quellcodegezogen werden können. Visuelle Verfahren sind hier deutlich robuster gegenüber rein HTML-basierten.Die Arbeit hat auch gezeigt, daÿ es, sofern man Kenntnisse über den grundlegenden Aufbau

der zu untersuchenden Seiten hat, möglich ist, eine hierarchische Gliederung basierend aufvisuellen Merkmalen zu extrahieren. Selbst eine mehrstu�ge Gliederung � Stichwort Spalten-übergreifende Labels � stellt prinzipiell kein Problem dar, sofern diese eindeutig interpretierbarist, d. h., die Bounding Box des übergeordneten Elements alle untergeordneten Elementeüberspannt.

83

Eine weitere Erkenntis, die diese Arbeit gebracht hat, ist der Ein�uÿ der Qualität der Roh-daten auf die Berechnung der Hierarchie. Dies führt zum Einen bei der Verwendung desRoadRunners zum Erkennen von Variants dazu, daÿ dieser auf Seiten, die sehr viel Javas-cript verwenden oder Informationen in Gra�ken verklausulieren, nicht alle Variants erkennt.Zum Anderen führt das konsequente Aus�ltern von Token-Dubletten dazu, daÿ u. U. wichtigeStyle-Informationen und Bounding Boxes aus überlagerten Elementen verlorengehen, was vorallem bei der Berechnung von Separatoren und der Zuweisung von Labels problematisch ist.Ein groÿes Problem stellt auch die Auswertung von Flash-basierten Webseiten dar. Keines

der hier beschriebenen Verfahren ist in der Lage diese auszuwerten.

6.3. Ausblick

Die Arbeit hat einen prinzipiell funktionierenden Algorithmus hervorgebracht, der allerdingsan vielen Stellen durch zuvor beschriebene Probleme �aus dem Tritt� gebracht wird. Nebender Lösung dieser Probleme gibt es natürlich noch weitere Optimierungsmöglichkeiten.Ganz oben auf der Liste der Verbesserungen sollte die Steigerung der Qualität der Rohdaten

stehen. Gerade die Erkennung von Variants ist bei Javascript-lastigen Webseiten schwierig.Eine Möglichkeit dies zu umgehen, wäre eine Art gra�schen RoadRunner zu bauen, deridentische Token auf unterschiedlichen Instanzen einer Class of Pages heraus�ltert und nurnoch die Menge der Variants übrigläÿt. Theoretisch sollten sich auf allen Seiten einer Classof Pages identische Token �nden lassen, da diese Seiten in der Regel durch ein einheitlichesSkript erzeugt werden.Des weiteren könnte die Abkehr von einer zweidimensionalen Sicht auf die zu untersu-

chende Webseite zu einer Art dreidimensionalen Schichtenmodell der Seite Verbesserung imBezug auf die Erkennbarkeit der wirklichen Darstellung bringen. D. h., Token die von ande-ren Token überlagert werden, sollten dennoch, sofern sie sichtbar sind, berücksichtig werden.Ihre Bounding Box ist oftmals um wenige Pixel gröÿer, was durchaus entscheidend bei derErkennung von Separatoren sein kann. Momentan kann es vorkommen, daÿ selbst zwischeneinzelnen Zeilen einer Tabelle Separatoren erkannt werden, da nicht die Bounding Boxes derTabellenzellen ausschlaggebend sind sondern die ihrer Inhalte.Wie beschriebenen ist es derzeit nicht möglich, Informationen, die in Bildern oder Gra�ken

repräsentiert werden, in die Analyse miteinzubeziehen. Zumindest für Text, der in Bildernenthalten ist, könnte man mit Hilfe von OCR-Algorithmen1 versuchen, diesen zu extrahierenund für die weitere Analyse zu nutzen.Um derzeit nicht berücksichtigte Flash-Inhalte dennoch mit einzubeziehen, wäre ein An-

satz, die von Adobe Flash bereitgestellten Möglichkeiten zum Erstellen von barrierefreienFlash-Animationen zu nutzen, sofern sie vom Autor der Animation berücksichtigt wurden.Da es derzeit viele verschiedene Best-Practices gibt, um Flash-Animationen barrierefrei bzw.für Suchmaschinen indizierbar zu gestalten, von denen einige im Adobe Accessibility DesignCenter2 beschrieben werden, dürfte sich die Entwicklung eines entsprechenden Algorithmusvoraussichtlich sehr aufwendig gestalten.

1Engl.: Abk. für Optical Character Recognition, Texterkennung2http://www.adobe.com/de/accessibility/ [letzter Besuch: 07.07.2008]

84

http://www.adobe.com/de/accessibility/

Literaturverzeichnis

[1] Apple Inc.: Apple Human Interface Guidelines. Apple Inc., 2008.� http://developer.apple.com/documentation/UserExperience/Conceptual/

AppleHIGuidelines/OSXHIGuidelines.pdf

[2] Arlotta, Luigi ; Crescenzi, Valter ; Mecca, Giansalvatore ; Merialdo, Paolo:Automated Annotation of Data Extracted from Large Web Sites. In: 6th International

Workshop on the Web and Databases (WebDB'03), ACM New York, NY, USA, Juni2003, S. 7�12

[3] Bergman, Michael K.: The Deep Web: Surfacing Hidden Value. August 2001.� http://brightplanet.com/resources/details/deepweb.html [letzter Besuch:08.07.2008]

[4] Cai, Deng ;Yu, Shipeng ;Wen, Ji-Rong ;Ma, Wei-Ying: Extracting Content Structurefor Web Pages Based on Visual Representation. In: Web Technologies and Applications:

5th Asia-Paci�c Web Conference, APWeb 2003, Xian, China, April 23-25, 2003. Procee-

dings Bd. 2642/2003, Springer Berlin / Heidelberg, 2003 (Lecture Notes in ComputerScience), S. 406�417

[5] Crescenzi, Valter ;Mecca, Giansalvatore ;Merialdo, Paolo: RoadRunner: TowardsAutomatic Data Extraction from Large Web Sites. In: Proceedings of 27th International

Conference on Very Large Data Bases, 2001, 109�118

[6] Deshpande, Yogesh ; Hansen, Steve: Web Engineering: Creating a Discipline amongDisciplines. In: IEEE MultiMedia 8 (2001), Nr. 2, S. 82�87. http://dx.doi.org/http://dx.doi.org/10.1109/93.917974. � DOI http://dx.doi.org/10.1109/93.917974. �ISSN 1070�986X

[7] Dragut, Eduard ; Wu, Wensheng ; Sistla, Prasad ; Yu, Clement ; Meng, Weiyi:Merging Source Query Interfaces onWeb Databases. In: icde 0 (2006), S. 46. ISBN0�7695�2570�9

[8] Dragut, Eduard C. ; Yu, Clement ; Meng, Weiyi: Meaningful labeling of integratedquery interfaces. In: VLDB '06: Proceedings of the 32nd international conference on

Very large data bases, VLDB Endowment, 2006, S. 679�690

[9] Ester, Martin ; Kriegel, Hans-Peter ; Sander, Jörg ; Xu, Xiaowei: A density-basedalgorithm for discovering clusters in large spatial databases with noise. In: KDD '96:

Proceedings of the second international conference on Knowledge Discovery and Data

Mining, AAAI Press, 1996, S. 226�231

85

http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/OSXHIGuidelines.pdf

http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/OSXHIGuidelines.pdf

http://brightplanet.com/resources/details/deepweb.html

http://dx.doi.org/http://dx.doi.org/10.1109/93.917974

http://dx.doi.org/http://dx.doi.org/10.1109/93.917974

[10] Gellersen, Hans-W. ; Gaedke, Martin: Object-Oriented Web Application Deve-lopment. In: IEEE Internet Computing 03 (1999), Nr. 1, S. 60�68. http://dx.

doi.org/http://doi.ieeecomputersociety.org/10.1109/4236.747323. � DOIhttp://doi.ieeecomputersociety.org/10.1109/4236.747323. � ISSN 1089�7801

[11] Gnaho, Christophe: Web-Based Information Systems Development - A User CenteredEngineering Approach. In: Web Engineering, Software Engineering and Web Application

Development. London, UK : Springer-Verlag, 2001. � ISBN 3�540�42130�0, S. 105�118

[12] Gu, Xiao-Dong ; Chen, Jinlin ; Ma, Wei-Ying ; Chen, Guo-Liang: Visual BasedContent Understanding towards Web Adaptation. In: AH '02: Proceedings of the Second

International Conference on Adaptive Hypermedia and Adaptive Web-Based Systems.London, UK : Springer-Verlag, 2002. � ISBN 3�540�43737�1, S. 164�173

[13] Han, Xiaowei ; Li, Junsheng ; Li, Yanping ; Xu, Xinhe: An Approach of Color Ob-ject Searching for Vision System of Soccer Robot. In: Proceedings of the 2004 IEEE

International Conference on Robotics and Biomimetics. Shenyang, China, August 22-262004

[14] He, Bin ; Patel, Mitesh ; Zhang, Zhen ; Chang, Kevin Chen-Chuan: Accessing thedeep web. In: Communication of the ACM 50 (2007), Mai, Nr. 5, S. 94�101. � ISSN0001�0782

[15] Holck, Jesper: 4 Perspectives on Web Information Systems. In: HICSS '03: Proceedings

of the 36th Annual Hawaii International Conference on System Sciences (HICSS'03) -

Track 8. Washington, DC, USA : IEEE Computer Society, 2003. � ISBN 0�7695�1874�5,S. 265.2

[16] Irvine, Veronika: ActiveX Support In SWT. März 2001. � http://www.eclipse.org/

articles/article.php?file=Article-ActivexSupportInSwt/index.html [letz-ter Besuch: 23.06.2008]

[17] Kabisch, Thomas: DeepWebExtractor. 2008. � private Mitteilung

[18] Kabisch, Thomas ; Busse, Susanne: Modelling Patterns for Deep Web WrapperGeneration. In: Fourth International Workshop on Web Information Systems Modeling,2007, S. 19�30

[19] Kaljuvee, Oliver ; Buyukkokten, Orkut ; Garcia-Molina, Hector ; Paepcke,Andreas: E�cient Web form entry on PDAs. In: WWW '01: Proceedings of the 10th

international conference on World Wide Web, 2001. � ISBN 1�58113�348�0, S. 663�672

[20] Leser, Ulf ; Naumann, Felix: Informationsintegration. dpunkt.verlag, 2007. � ISBN3�89864�400�6

[21] Lim, Seung-Jin ; Ng, Yiu-Kai: An automated approach for retrieving hierarchical datafrom HTML tables. In: CIKM '99: Proceedings of the eighth international conference

on Information and knowledge management. New York, NY, USA : ACM, 1999. � ISBN1�58113�146�1, S. 466�474

86

http://dx.doi.org/http://doi.ieeecomputersociety.org/10.1109/4236.747323

http://dx.doi.org/http://doi.ieeecomputersociety.org/10.1109/4236.747323

http://www.eclipse.org/articles/article.php?file=Article-ActivexSupportInSwt/index.html

http://www.eclipse.org/articles/article.php?file=Article-ActivexSupportInSwt/index.html

[22] Liu, Bing ;Grossman, Robert ; Zhai, Yanhong: Mining data records in Web pages. In:KDD '03: Proceedings of the ninth ACM SIGKDD international conference on Knowledge

discovery and data mining. New York, NY, USA : ACM, 2003. � ISBN 1�58113�737�0,S. 601�606

[23] Liu, Wei ;Meng, Xiaofeng ;Meng, Weiyi: Vision-based Web Data Records Extraction.In: Proceedings of the 9th SIGMOD International Workshop on Web and Databases

(SIGMOD-WebDB2006), 2006

[24] Madhavan, Jayant ; Halevy, Alon: Crawling through HTML forms. Google Web-master Central Blog, April 2008. � http://googlewebmastercentral.blogspot.

com/2008/04/crawling-through-html-forms.html [letzter Besuch: 08.05.2008]

[25] McCarron, Shane ; Ishikawa, Masayasu: XHTML 1.1 - Module-based XHTML -

Second Edition. W3C, Februar 2007. � http://www.w3.org/TR/xhtml11/ [letzterBesuch: 14.05.2008]

[26] Microsoft Corporation: Windows Vista User Experience Guidelines. MicrosoftCorporation, 2007. � http://msdn.microsoft.com/en-us/library/aa511258.aspx

[27] Raghavan, Sriram ; Garcia-Molina, Hector: Crawling the Hidden Web. In: Procee-dings of the Twenty-seventh International Conference on Very Large Databases, 2001

[28] Sarifuddin, M. ; Missaoui, Rokia: A New Perceptually Uniform Color Space withAssociated Color Similarity Measure for Content-Based Image and Video Retrieval, 2005

[29] SELFHTML e. V.: SELFHTML 8.1.2. März 2007. � http://de.selfhtml.org/

[letzter Besuch: 07.05.2008]

[30] Simon, Kai ; Lausen, Georg: ViPER: Augmenting Automatic Information Extractionwith Visual Perceptions. In: Proceedings of the 2005 ACM CIKM Conference on In-

formation and Knowledge Management. Bremen, GERMANY : ACM Press, November2005. � ISBN 1�59593�140�6, S. 381�388

[31] Singh, Surendra N. ; Dalal, Nikunj P.: Web home pages as advertisements. In:Commun. ACM 42 (1999), Nr. 8, S. 91�98. http://dx.doi.org/http://doi.acm.

org/10.1145/310930.310978. � DOI http://doi.acm.org/10.1145/310930.310978. �ISSN 0001�0782

[32] Yang, Yudong ; Zhang, HongJiang: HTML Page Analysis Based on Visual Cues. In:icdar 00 (2001), S. 859�864. ISBN 0�7695�1263�1

[33] Zhai, Yanhong ; Liu, Bing: Web data extraction based on partial tree alignment. In:WWW '05: Proceedings of the 14th international conference on World Wide Web. NewYork, NY, USA : ACM, 2005. � ISBN 1�59593�046�9, S. 76�85

[34] Zhang, Zhen ; He, Bin ; Chang, Kevin Chen-Chuan: Understanding Web queryinterfaces: best-e�ort parsing with hidden syntax. In: SIGMOD '04: Proceedings of the

87

http://googlewebmastercentral.blogspot.com/2008/04/crawling-through-html-forms.html

http://googlewebmastercentral.blogspot.com/2008/04/crawling-through-html-forms.html

http://www.w3.org/TR/xhtml11/


http://de.selfhtml.org/

http://dx.doi.org/http://doi.acm.org/10.1145/310930.310978

http://dx.doi.org/http://doi.acm.org/10.1145/310930.310978

2004 ACM SIGMOD international conference on Management of data. New York, NY,USA : ACM, 2004. � ISBN 1�58113�859�8, S. 107�118

[35] Zhao, Hongkun ; Meng, Weiyi ; Wu, Zonghuan ; Raghavan, Vijay ; Yu, Clement:Fully automatic wrapper generation for search engines. In: WWW '05: Proceedings of

the 14th international conference on World Wide Web, ACM New York, NY, USA, 2005.� ISBN 1�59593�046�9, S. 66�75

88

A. Ausgabe des DetailPageExtractors

Nachfolgend die Ausgabe des DetailPageExtractors für den in Abschnitt 5.2 beschriebenenBeispiellauf.

1 Texttoken = Va r i a n t s2 ====================3 t #462[144 ,464 ,282 ,477]AMERICAN EAGLE,#000000 , t r a n s p a r e n t , 10 px , normal , 400 ,

a r i a l , h e l v e t i c a , sans−s e r i f , b lock , i n h e r i t , 04 t #464[285 ,451 ,334 ,464]280 ,#000000 , t r a n s pa r e n t , 10 px , normal , 400 , a r i a l ,

h e l v e t i c a , sans−s e r i f , b lock , i n h e r i t , 05 t #466[337 ,451 ,442 ,464]LAX Los Ange les ,#000000 , t r a n s pa r e n t , 10 px , normal , 400 ,

a r i a l , h e l v e t i c a , sans−s e r i f , b lock , i n h e r i t , 06 t #468[445 ,445 ,528 ,457]Nov 20 , 2007 ,#000000 , t r a n s p a r e n t , 10 px , normal , 400 ,

a r i a l , h e l v e t i c a , sans−s e r i f , b lock , i n h e r i t , 07 t #471[531 ,451 ,636 ,464]MIA Miami ,#000000 , t r a n s p a r e n t , 10 px , normal , 400 , a r i a l ,

h e l v e t i c a , sans−s e r i f , b lock , i n h e r i t , 08 t #473[639 ,445 ,722 ,457]Nov 20 , 2007 ,#000000 , t r a n s p a r e n t , 10 px , normal , 400 ,


h e l v e t i c a , sans−s e r i f , b lock , i n h e r i t , 010 t #485[285 ,493 ,334 ,506]978 ,#000000 , t r a n s pa r e n t , 10 px , normal , 400 , a r i a l ,

h e l v e t i c a , sans−s e r i f , b lock , i n h e r i t , 011 t #487[337 ,493 ,442 ,506]MIA Miami ,#000000 , t r a n s p a r e n t , 10 px , normal , 400 , a r i a l ,

h e l v e t i c a , sans−s e r i f , b lock , i n h e r i t , 012 t #489[445 ,487 ,528 ,499]Nov 22 , 2007 ,#000000 , t r a n s p a r e n t , 10 px , normal , 400 ,

a r i a l , h e l v e t i c a , sans−s e r i f , b lock , i n h e r i t , 013 t #492[531 ,493 ,636 ,506]LAX Los Ange les ,#000000 , t r a n s pa r e n t , 10 px , normal , 400 ,

a r i a l , h e l v e t i c a , sans−s e r i f , b lock , i n h e r i t , 014 t #494[639 ,487 ,722 ,499]Nov 22 , 2007 ,#000000 , t r a n s p a r e n t , 10 px , normal , 400 ,


h e l v e t i c a , sans−s e r i f , b lock , i n h e r i t , 016 t #553[313 ,608 ,473 ,621 ]453 .00 USD,#000000 , t r a n s p a r e n t , 10 px , normal , 400 , a r i a l ,




h e l v e t i c a , sans−s e r i f , b lock , i n h e r i t , 020 #Labe l ed Elements : 1721 Columns22 =======23 #10462 [144 ,404 ,282 ,477 ] : L#436 C a r r i e r : #462 AMERICAN EAGLE ,24 #10464 [285 ,404 ,334 ,506 ] : L#438 F l i g h t25 Number : #464 280 , #485 978 ,26 #10466 [337 ,421 ,442 ,506 ] : L#449 C i t y : #466 LAX Los Ange les , #487 MIA Miami ,

89

27 #10468 [445 ,421 ,528 ,512 ] : L#451 Date & Time : #468 Nov 20 , 200728 09 :05 AM, #489 Nov 22 , 200729 08 :30 PM,30 #10471 [531 ,421 ,636 ,506 ] : L#453 C i t y : #471 MIA Miami , #492 LAX Los Ange les ,31 #10473 [639 ,421 ,722 ,512 ] : L#455 Date & Time : #473 Nov 20 , 200732 04 :55 PM, #494 Nov 22 , 200733 11 :10 PM,34 #10476 [725 ,404 ,774 ,506 ] : L#445 A i r c r a f t35 Type : #476 763 , #497 757 ,36 #10553 [313 ,571 ,473 ,621 ] : L#537 Fare pe r Person : #553 453 .00 USD,37 #10557 [480 ,571 ,640 ,621 ] : L#542 Add i t i o n a l Taxes and Fees pe r Person : #557

20 .80 USD,38 #10560 [647 ,571 ,773 ,643 ] : L#545 Tota l P r i c e : #560 473 .80 USD, #568 473 .80

USD,39 #20466 [337 ,404 ,528 ,512 ] : L#441 Depa r t i ng : C#10466 Ci ty , C#10468 Date & Time40 #20471 [531 ,404 ,722 ,512 ] : L#443 A r r i v i n g : C#10471 Ci ty , C#10473 Date & Time ,41 #20553 [146 ,549 ,773 ,643 ] : L#525 Average Fare pe r Person − 453 .00 USD: C

#10553 Fare pe r Person , C#10557 Add i t i o n a l Taxes and Fees pe r Person , C#10560 Tota l P r i c e ,

42 #Columns : 1343 Data r e g i o n44 ===========45 [ 0 , 1 45 , 974 , 943 ] , w idth : 974 , h e i g h t : 79846 V e r t i c a l s e p a r a t o r s47 ===================48 #30000[128 ,145 ,141 ,943]49 #30001[782 ,145 ,939 ,943]50 Ho r i z o n t a l s e p a r a t o r s51 =====================52 #40000[0 ,520 ,974 ,530]53 Mult i−Column cand i d a t e s54 =======================55 #10466 [337 ,421 ,442 ,506 ] : L#449 C i t y : #466 LAX Los Ange les , #487 MIA Miami ,56 #10468 [445 ,421 ,528 ,512 ] : L#451 Date & Time : #468 Nov 20 , 200757 09 :05 AM, #489 Nov 22 , 200758 08 :30 PM,59 #10471 [531 ,421 ,636 ,506 ] : L#453 C i t y : #471 MIA Miami , #492 LAX Los Ange les ,60 #10473 [639 ,421 ,722 ,512 ] : L#455 Date & Time : #473 Nov 20 , 200761 04 :55 PM, #494 Nov 22 , 200762 11 :10 PM,63 #10553 [313 ,571 ,473 ,621 ] : L#537 Fare pe r Person : #553 453 .00 USD,64 #10557 [480 ,571 ,640 ,621 ] : L#542 Add i t i o n a l Taxes and Fees pe r Person : #557

20 .80 USD,65 #10560 [647 ,571 ,773 ,643 ] : L#545 Tota l P r i c e : #560 473 .80 USD, #568 473 .80

USD,66 #Mult i−Columns : 767 Tab le s68 ======69 #50462 [144 ,404 ,774 ,512 ] : Table 1 : L#415 Your I t i n e r a r y : #10462 , #10464 ,

#10476 , #20466 , #20471 ,70 #50553 [146 ,549 ,773 ,643 ] : Table 12 : L#508 Fare Summary : #20553 , #20553 ,71 ∗∗∗ Tree ∗∗∗72 ============73 60000 n u l l

90

74 50462 [144 ,404 ,774 ,512 ]75 10462 [144 ,404 ,282 ,477 ]76 462 [144 ,464 ,282 ,477 ]77 10464 [285 ,404 ,334 ,506 ]78 464 [285 ,451 ,334 ,464 ]79 485 [285 ,493 ,334 ,506 ]80 10476 [725 ,404 ,774 ,506 ]81 476 [725 ,451 ,774 ,464 ]82 497 [725 ,493 ,774 ,506 ]83 20466 [337 ,404 ,528 ,512 ]84 10466 [337 ,421 ,442 ,506 ]85 466 [337 ,451 ,442 ,464 ]86 487 [337 ,493 ,442 ,506 ]87 10468 [445 ,421 ,528 ,512 ]88 468 [445 ,445 ,528 ,470 ]89 489 [445 ,487 ,528 ,512 ]90 20471 [531 ,404 ,722 ,512 ]91 10471 [531 ,421 ,636 ,506 ]92 471 [531 ,451 ,636 ,464 ]93 492 [531 ,493 ,636 ,506 ]94 10473 [639 ,421 ,722 ,512 ]95 473 [639 ,445 ,722 ,470 ]96 494 [639 ,487 ,722 ,512 ]97 50553 [146 ,549 ,773 ,643 ]98 20553 [146 ,549 ,773 ,643 ]99 10553 [313 ,571 ,473 ,621 ]100 553 [313 ,608 ,473 ,621 ]101 10557 [480 ,571 ,640 ,621 ]102 557 [480 ,608 ,640 ,621 ]103 10560 [647 ,571 ,773 ,643 ]104 560 [647 ,608 ,773 ,621 ]105 568 [647 ,628 ,773 ,643 ]106 20553 [146 ,549 ,773 ,643 ]107 10553 [313 ,571 ,473 ,621 ]108 553 [313 ,608 ,473 ,621 ]109 10557 [480 ,571 ,640 ,621 ]110 557 [480 ,608 ,640 ,621 ]111 10560 [647 ,571 ,773 ,643 ]112 560 [647 ,608 ,773 ,621 ]113 568 [647 ,628 ,773 ,643 ]

Listing A.1: Ausgabe des DetailPageExtractors

91

B. Inhalt der CD

Die beiligende CD enthält mehrere Verzeichnisse mit den folgenden Inhalten:


Das komplette Eclipse-Projektverzeichnis des DetailPageExtractors inklusive des Java-Quellcodes, allen benötigten Bibliotheken, die nicht im Lieferumfang von Eclipse enthal-ten sind, der Quellcodedokumentation im Javadoc-Format sowie einigen Beispielseiten.

/ Diplomarbeit-LaTeX

Die LATEX-Quellen aus denen dieses Dokument erzeugt wurde. Im Unterverzeichnis/images be�ndet sich ferner, neben allen in diesem Dokument verwandten Gra�ken,das in Abbildung 4.2 gezeigte Klassendiagramm des DetailPageExtractors.

/ Diplomarbeit-PDF

Dieses Dokument als Adobe PDF-Datei.

/ RoadRunner

Der Quellcode des RoadRunners als Eclipse-Projekt.

92

Extraktion von Ergebnisseiten in Webinformationssystemen auf der Basis von Layoutanalyse

Documents

Transcript of Extraktion von Ergebnisseiten in Webinformationssystemen auf der Basis von Layoutanalyse