Schriftliche Ausarbeitung zum Referat - Universität Konstanz

Gliederung 

Schriftliche Ausarbeitung zum Referat 

Integration von Web-Datenquellen 

Michael Bohner 

Universität Konstanz, Seminar Data on the Web SS2001 

bei Prof. Dr. Marc Scholl 

1. Einleitung 

1.1. Motivation für die Integration von Web-Datenquellen 

1.2. Problematik 

2. Grundsätzlicher Lösungsansatz: Mittelschicht 

2.1 Data Warehouse 

2.2 Middleware / Informationsintegrationssysteme 

3. Wrapper 

3.1 Definition und Aufgaben 

3.2 Logisches Modell 

3.3 Konzept 

3.4 Vor- und Nachteile des Wrappings 

3.5 Erzeugung von Wrappern 

3.6 Beispiel XWRAP: System zur Erzeugung von Wrappern 

4. Mediatoren 

4.1 Definition und Aufgaben 

4.2 Architektur und funktionale Aspekte 

4.3 Anfrageverarbeitung 

4.4 Erstellung eines globalen Schemas 

4.5 Information Manifold: Beispiel für den Einsatz von Mediator-Technik 

5. Informationsintegrationssysteme auf dem Web 

5.1 Entwicklung 

5.2 Praktische Aspekte 

6. Literaturverzeichnis 

1

1. Einleitung 

1.1 Motivation 

Der überwältigende Erfolg des World Wide Web ist zugleich auch die Ursache eines seiner 

größten derzeitigen Probleme: Die ständig wachsende Informationsmenge wird zunehmend 

unüberschaubar und kann mit herkömmlichen Navigations- und Suchmethoden nicht mehr 

umfassend und effizient erschlossen werden. Bei diesen Methoden (überwiegend 

Schlüsselwortsuche und benutzergesteuertes Browsing) wird das Web üblicherweise als 

verlinkte Sammlung unstrukturierter Dokumente angesehen. Tatsächlich nimmt jedoch die 

Zahl strukturierter und semi-strukturierter Datenquellen im WWW, die beispielsweise 

Produktinformationen, Wirtschafts- und wissenschaftliche Informationen enthalten, ständig 

zu. Bei der manuellen Erschließung derartiger Quellen bzw. der Erschließung mittels 

Indexierung und Schlüsselwortsuche bleibt deren zugrundeliegende Struktur allerdings 

weitgehend ungenutzt. Ein sehr viele effizientere Nutzung wäre möglich, wenn komplexe 

Abfragen an die Datenquellen abgesetzt werden könnten. 

Ferner ist der Benutzer bisher meist gezwungen, auf jede Datenquelle manuell zuzugreifen. 

Das bedeutet, dass er über eine Liste möglicher Quellen verfügen und entscheiden muss, 

welche davon er benutzen möchte. Anschließend muss er mit jeder Quelle einzeln 

interagieren und die Informationen aus verschiedenen Quellen manuell kombinieren. Neben 

der Erschwernis für den menschlichen Nutzer betrifft dies insbesondere auch die 

automatisierte Informationsgewinnung: Die Erstellung und Wartung von maßgeschneiderten 

Parsingprogrammen für eine Vielzahl sich häufig ändernder Websites dürfte selten mit 

lohnendem Aufwand zu realisieren sein. 

Ein wesentlicher Schritt auf dem Weg zu einer effizienten Informationsgewinnung im WWW 

wäre daher die Nutzung der Daten in den Quellen zur Beantwortung komplexer Anfragen 

kombiniert mit der Bereitstellung einer einheitlichen, zentralen Schnittstelle für alle (in Frage 

kommenden) Informationsquellen. Dies setzt jedoch die Integration verschiedener 

Datenquellen im Web voraus.[Levy, Rajaraman, Ordille 1996] S. 1f 

1.2 Problematik 

Die bei der Integration auftretenden Schwierigkeiten sind v. a. mit der großen Heterogenität 

der Web-Datenquellen verbunden. Im wesentlichen stellen sich folgende Probleme 

[Wiederhold 92]: 

Heterogenität bei der Repräsentation und Struktur der Daten (Data Mismatch): 

Hierbei können u. a. folgende Fälle unterschieden werden: 

- Unterschiede bei der Benennung eines Realweltgegenstandes: 

Beispiel: Dasselbe Buch wird einer Quelle unter Alan Turing: The Enigma 

(Referenz für Leser) und in einer anderen unter QA29.T8H63 (Referenz für 

Bibliothekare) geführt. 

- Unterschiedliche Konzeptualisierungen in verschiedenen Quellen: 

Dabei handelt es sich häufig um einen unterschiedlichen Abdeckungsgrad in 

zeitlicher, räumlicher oder sonstiger inhaltlicher Hinsicht. Insbesondere bei der 

2

Verwendung gleichlautender Begriffe in unterschiedlichen Domänen ist aber auch 

eine völlig unterschiedliche Semantik denkbar. 

Beispiel: Zwei Online-Shops verwenden den Begriff PC. In einem Fall sind jedoch 

alle Personal Computer gemeint, während die andere Quelle unter dem Begriff nur 

IBM kompatible PCs versteht. 

- Unterschiedlicher Grad der Granularität 

Beispiel: Quelle mit Familieneinkommen (im Zusammenhang mit Besteuerung) vs. 

Quelle mit persönlichem Einkommen (im Zusammenhang mit Berufstätigkeit) 

Überlappungen und Inkonsistenzen zwischen mehreren Datenquellen: 

Falls zur Beantwortung einer Anfrage Antworten aus mehreren Datenquellen kombiniert 

werden sollen, tritt zusätzlich das Problem der inhaltlichen Überlappungen und 

Inkonsistenzen zwischen verschiedenen Quellen auf. 

Unterschiede in den inhaltlichen Antwortfähigkeiten 

Auf manchen Quellen sind eventuell nur Teile der Abfragen möglich, die auf anderen Quellen 

abgesetzt werden können bzw. eine Abfrage ist nur möglich, wenn die Anfrage bestimmte 

Schlüsselinhalte enthält. 

Unterschiede in den Zugriffssprachen und der technischen Verfügbarkeit 

Hierzu zählen insbesondere Zugriffsprotokolle, Zugriffsgeschwindigkeit und zeitliche 

Verfügbarkeit. 

2. Grundsätzlicher Lösungsansatz: Mittelschicht 

Der grundlegende Ansatz zur Lösung des Datenintegrationsproblems im Web ist ein 

„Mehrschichten-Konzept“ (multitier approach). Das bedeutet, dass unter Abkehr von der 

klassischen Client/Server-Architektur in Datenbanksystemen eine zusätzliche Schicht 

zwischen den Datenquellen und den abfragenden Systemen eingezogen wird (Abbildung 1). 

Client Client Client 

Abbildung 1: Lösungskonzept: Mittelschicht 

Mittelschicht 

Server Server Server 

3

Die unterste Schicht besteht aus den Datenquellen. Dies können konventionelle 

Datenbankserver aber auch alle sonstigen Systeme sein, die in irgendeiner Weise Objekte mit 

Informationen enthalten, auf die von außerhalb zugegriffen werden kann. In dieser sehr 

allgemeinen Bedeutung wird der Begriff hier auch weiter verwendet werden. 

Die oberste Schicht, die Client-Schicht besteht aus Benutzerschnittstellen oder Anwendungen, 

die Daten verarbeiten. Dazwischen können sich eine oder mehrere Mittelschichten befinden, 

die für die Transformation und Integration und ggf. sonstige Veredelung der Daten sorgen. 

[Abiteboul, Buneman, Suci 2000] S. 5f 

Für die Mittelschicht, die letztlich das Integrationsproblem löst, gibt es prinzipiell zwei 

Ansätze: 

2.1 Data Warehouse 

Eine mögliche Form der Mittelschicht stellt ein Data Warehouse dar. Bei diesem Ansatz 

werden die Daten aus den verschiedenen Quellen extrahiert, in der gewünschten Form 

aufbereitet und vereinheitlicht und in einer speziell dafür entworfenen Datenbank (dem 

Warehouse) abgespeichert. Das Data Warehouse bietet nun eine integrierte Sicht auf die 

Daten und kann effizient von den client-Anwendungen abgefragt werden. Dieses Konzept 

wird jedoch vor allem dazu angewandt, um konsistente, integrierte Sichten auf Daten aus 

verschiedenen Quellen eines Unternehmens zu bieten und somit fundierte und schnelle 

Managemententscheidungen zu ermöglichen. Ein Schwerpunkt liegt dabei auf der 

interaktiven Exploration der in das Data Warehouse eingebrachten Datenbestände (Online 

Analytical Processing). Diese Daten können allerdings auch aus Datenquellen im Web 

stammen (Stichwort: Web Farming) und ein Data Warehouse könnte selbst eine Datenquelle 

darstellen, auf die - z. B. in Kombination mit dem nachfolgend beschriebenen Konzept – über 

das Web zugegriffen wird. 

Abbildung 2: Lösungsansatz: Data Warehouse 

2.2 Middleware / Informationsintegrationssysteme 

Bei diesem Ansatz werden Anfragen des Clients durch die Middleware in eine auf die 

Datenquellen passende Form umgeschrieben und direkt auf den Quellen ausgeführt, wobei die 

4

Anfragen ggf. in mehrere Teilanfragen aufgespaltet werden. Teilergebnisse verschiedener 

Quellen werden wiederum durch die Middleware integriert, bevor sie an den Client 

zurückgegeben werden. Die Bearbeitung von Anfrage und Antwort geschieht on-the-fly – in 

der Middleware werden grundsätzlich keine Daten gespeichert. Dieses Konzept der 

Datenintegration bietet sich v. a. an, wenn die Aktualität der Daten kritisch ist und es 

schwierig oder unmöglich ist, die gesamten Daten aus den Quellen zu laden. Es ist daher im 

Gegensatz zum Data Warehouse besonders interessant für die Integration von Daten aus 

Webquellen, welche dadurch gekennzeichnet sind, dass ein Speichern der gesamten Daten der 

Quelle meistens nicht möglich ist und nur bedingt Mechanismen für automatische Updates 

zur Verfügung stehen. Die nachfolgenden Ausführungen konzentrieren sich daher auf 

Konzepte und Beispiele aus dem Bereich der Middleware. 

Abbildung 3: Lösungsansatz: Middleware 

Die in diesem Zusammenhang auftauchenden Begriffe werden leider noch nicht völlig 

einheitlich verwendet. So fassen [Abiteboul, Buneman, Suci 2000] auch das Data Warehouse 

unter den Begriff Middleware und verwenden für den vorliegenden Ansatz „Mediator 

System“. Andere Definitionen stellen hingegen darauf ab, dass es sich bei Middleware um 

Verbindungssoftware handelt, die es verschiedenen ehemals unabhängigen Anwendungen 

erlaubt, über ein Netzwerk miteinander zu interagieren. (z. B. [Foreman et al 1997]). Da 

Mediatoren häufig nur einen Teil der Aufgaben der Mittelschicht wahrnehmen – wie 

nachstehend gezeigt werden soll – wird hier für den Ansatz der on-the-fly durchgeführten 

Informationsintegration Middleware oder der allgemeinere Begriff 

Informationsintegrationssystem (entsprechend auch [Cohen 1999] verwendet werden. 

Im Rahmen von Informationsintegrationssysteme können zwei weitere grundlegende 

Konzepte unterschieden werden, die sich Teilaspekten des Integrationsproblemes annehmen. 

Hierbei handelt es sich um die Ansätze Wrapper und Mediatoren, die nachfolgend behandelt 

werden sollen. Obwohl es auch hier zu begrifflichen Überlappungen kommt, kann eine 

allgemeine Unterscheidung dahingehend erfolgen, dass bei den Wrappern, das erwähnte 

Problem der Erschließung einer Datenquelle für eine Abfragesprache im Vordergrund steht, 

während Mediatoren auf die Schaffung einer zentralen Schnittstelle für mehrere Quellen und 

deren integrierte Auswertung abzielen. 

5

3. Wrapper 

3.1 Definition/Aufgaben 

Bei Wrappern handelt es sich um einen Typ von Software, der eine Datenquelle so einkapselt, 

dass sie bequemer nutzbar ist, als die ursprüngliche, nicht verpackte Datenquelle. 

Wrapper können für folgende Aufgaben eingesetzt werden: 

- Schaffung einer vereinfachten Schnittstelle für eine Datenquelle 

- Vereinheitlichung der Schnittstellen verschiedener Quellen 

- Erhöhung der Funktionalität einer Datenquelle 

- Offenlegung von internen Schnittstellen einer Quelle 

3.2 Logisches Modell 

Alle Wrapper basieren auf dem folgenden logischen Grundmodell: 

Die betrachtete Datenquelle wird normalerweise mit einer Sprache Z angesprochen und liefert 

Resultate, die in Modell W ausgedrückt sind. Die Anwendung möchte aber die Sprache X 

verwenden und erwartet Antworten, die in Modell Y ausgedrückt sind. Der Wrapper 

konvertiert Befehle aus der Sprache X in die Sprache Z und Antwortdaten aus dem Modell W 

in das Modell Y, welches die Anwendung weiter verarbeiten kann. 

Applikation 

Sprache X Sprache Z 

Datenmodell Y 

Abbildung 4: Logisches Modell eines Wrappers 

Wrapper 

Datenmodell W 

Ein typisches Beispiel für den Einsatz von Wrappern für die Datenintegration im Web stellt 

folgendes Szenario dar: 

Datenquelle 

Datenquelle ist eine Website mit Produktinformationen. Die HTML-Seiten dieser Site werden 

zwar mit Hilfe einer Datenbank generiert, auf diese kann jedoch nicht direkt zugegriffen 

werden. Die einzige Sprache die die Quelle versteht, sind HTTP-Requests; als Antworten gibt 

sie HTML-Seiten zurück. Die Applikation benutzt jedoch eine XML-Querysprache und 

erwartet die Rückgabe entsprechender Datensätze. Der Wrapper fragt daher die HTML-Seiten 

der Datenquelle ab und transformiert die relevanten Inhalte in XML-Dokumente. Somit bietet 

er der Applikation eine XML-Schnittstelle, die entsprechende Queries auf die gewrappte 

Datenquelle möglich macht. 

6

3.3 Konzept 

Ein Wrapper ist immer genau einer Datenquelle zugeordnet, d. h. er kann genau die 

Datenquelle verwalten, für die er erstellt wurde. 

Ein weiteres wesentliches Merkmal des Wrappings ist, dass die Kapselung nur für die 

Beziehung zwischen der Datenquelle und den Anwendungen gilt, die den Wrapper benutzen. 

Somit behalten alle verwendeten Datenquellen ihre logische und physische Unabhängigkeit. 

Dies hat den Vorteil, dass Anwendungen, die direkt auf die Datenquelle zugreifen, durch das 

Wrapping nicht beeinträchtigt werden. 

Es sind grundsätzlich zwei Einsatzszenarien für Wrapper denkbar: 

- Einzelne Wrapper 

Wie in obiger Abbildung dargestellt steht eine Applikation direkt über einem 

Wrapper. Sie ruft diesen direkt auf, um Daten der gekapselten Quelle abzufragen. 

- Wrapper in Informationsintegrationssystemen 

Wrapper werden in einem System mit mehreren heterogenen Datenquellen 

eingesetzt, um jeweils eine Datenquelle in der Form einzukapseln, dass sie der 

gemeinsamen Schnittstelle entspricht, die das System für alle Datenquellen erwartet. 

I. d. R. existiert noch eine Art Vermittlungsmodul, in Form eines oder mehrerer 

Mediatoren, welches die Anfragen der Anwendung entgegennimmt, den Einsatz der 

einzelnen gewrappten Datenquellen plant, über die Wrapper auf die Datenquellen 

zugreift und die Ergebnisse zurückgibt. Eine derartige Architektur ist typisch für 

Informationsintegrationssysteme wie z. B. TSIMMIS [Garcia-Molina et al 1997]. 

Anwendung 

Mediator 

Wrapper 

Datenquellen 

Abbildung 5: Wrapper in Informationsintegrationssystemen 

7

Neben der Grundfunktionalität Anfragen entgegenzunehmen und Ergebnisse zu liefern, 

können Wrapper zusätzlich mit komplexeren Funktionalitäten ausgestattet sein. Hierbei sind 

insbesondere die Eigenschaften, Updates der Datenquelle zu ermöglichen, Anmeldungen von 

Anwendungen beim Wrapper zu unterstützen und Auskunft über die eigenen 

Anfragefähigkeiten zu geben, zu nennen. 

3.4 Vor- und Nachteile des Wrappings 

Vorteile des Wrappings 

- Unabhängigkeit zwischen Anwendung und Quelle 

Die unabhängige Entwicklung der Clientanwendungen und der Web-Datenquellen, 

wird vereinfacht, da Veränderungen in der inneren Architektur der Datenquelle 

nicht mehr zwangsläufig Veränderungen der Clientanwendung nach sich ziehen 

müssen. Die Datenquelle kann somit verändert werden, ohne dass ihre Entwertung 

befürchtet werden muss, da ein Reengineering der Clients zu aufwendig wäre. 

Andererseits kann bei der Fortentwicklung des Clienten auf der durch den Wrapper 

dauerhaft angebotenen Schnittstelle aufgebaut werden, ohne dass auf Details der 

Quelle Rücksicht genommen werden muss. In beiden Fällen ist zwar der Wrapper 

anzupassen. Dies ist jedoch mit deutlich weniger Aufwand verbunden, da der 

Wrapper gerade auf das Transformationsproblem spezialisiert ist und in der Regel 

so konstruiert wird, dass Anpassungen leicht möglich sind. 

- Überwindung der Heterogenität 

Bei dem erwähnten Einsatz von Wrappern in Informationsintegrationssystemen 

leisten diese einen wesentlichen Beitrag zur Überwindung der Heterogenität. Neben 

ihrer Grundfunktionaliät, eine bestimmte Datenquelle für eine Abfragemöglichkeit 

zugänglich zu machen, gewährleisten die Wrapper gleichzeitig, dass sich die 

Anwendung bzw. das Vermittlungsmodul nicht um Unterschiede bei Datenformaten 

oder Zugriffssprachen verschiedener Quellen kümmern muss. Jeder Datenquelle ist 

ein eigener Wrapper zugeordnet, der sicherstellt, dass die Quelle mit der 

systemeinheitlichen Sprache angesprochen werden kann. 

- Gute Skalierbarkeit 

Middleware-Systeme, die Wrapping verwenden sind gut skalierbar. Soll eine neue 

Datenquelle integriert werden, so wird sie einfach über einen Wrapper angebunden. 

Wrapper sind aufgrund ihres einfachen Aufbaus meist relativ leicht zu erstellen. 

- Kostenersparnis 

Dies folgt aus den oben genannten Punkten. Vor allem die Unabhängigkeit von 

Anwendung und Quelle bedeutet eine deutliche Verringerung des Aufwands bei 

Weiterentwicklungen. 

- Unabhängigkeit der Datenquellen 

Eine Datenquelle, die für eine bestimmte Anwendung gewrappt ist, behält wie 

erwähnt ihre physische und logische Unabhängigkeit. Damit können andere 

Applikationen, die direkt auf sie zugreifen, dies nach wie vor - ohne Änderung ihrer 

Implementierung - tun. 

8

Nachteile des Wrappings 

- Schlechtere Performance 

Der Zugriff auf die Datenquelle erfolgt beim Wrapping indirekt im Gegensatz zum 

direkten Zugriff ohne Wrapping. Dadurch wird der Zugriff langsamer. Insbesondere 

bei Systemen mit hohen Zugriffszahlen kann die Effizienz der Wrapper daher 

entscheidend sein. 

- Aktualität der Wrapper erforderlich 

Mit Veränderungen der Anwendung müssen ggf. auch die Wrapper angepasst 

werden, da Aktualität der Wrapper Grundvoraussetzung für das Funktionieren des 

Abfragesystems ist. Daraus können zusätzliche Kosten entstehen, wenn das 

Wrapping-System nicht gut konzipiert wurde. 

3.5 Erzeugung von Wrappern 

Bislang gibt es noch keine Standards über die interne Architektur von Wrappern. 

Insbesondere ist nicht geregelt, wie ein Wrapper von einer Anwendung bzw. einem 

Middleware-System angesprochen werden soll, d. h. es gibt keine Vereinbarungen über die 

Abfragesprachen (seitens der Anwendung) oder das Datenmodell der Wrapper. Der 

Austausch von Wrappern oder Wrapperkomponenten zwischen Systemen ist damit noch 

weitgehend ausgeschlossen. 

Es wird jedoch intensiv an Ansätzen zur automatischen bzw. halbautomatischen Generierung 

von Wrappern, insbesondere für das Web, geforscht. 

Dies hängt damit zusammen, dass die Programmierung von Wrappern „von Hand“ eine Reihe 

von Nachteilen mit sich bringt: 

- Inhalt und Struktur der Quellen im Web variieren sehr stark. Das bedeutet, dass 

jeder benötigte Wrapper von Grund auf neu geschrieben werden muss, da eine 

Wiederverwendung nicht möglich ist. Dies ist besonders gravierend angesichts der 

Tatsache, dass Informationsintegrationssysteme mit möglichst guter Skalierbarkeit 

(ausgehend von mindestens 100 Quellen) angestrebt werden. 

- Die Struktur von Online-Informationen wechselt regelmäßig, so dass häufige 

Anpassungen nötig sind. 

- Manuelle Entwicklung und Pflege von Wrappern ist generell sehr arbeitsaufwendig 

und fehleranfällig. 

Systeme zur Generierung von Wrappern für das WWW verwenden in der Regel deklarative 

Informationsextraktionsregeln, die der Benutzer in einer dafür konzipierten Sprache eingeben 

oder anhand einer Beispielseite der zu wrappenden Quelle mit Hilfe eines graphischen 

Interfaces spezifizieren kann. Basierend auf den Regeln wird anschließend der Wrappercode 

automatisch generiert. Beispiele für solche System sind W4F [Sahuguet, Azavant 1999] und 

XWRAP [Liu, Pu, Han 2000], welches nachfolgend vorgestellt werden soll. 

3.6 Beispiel XWRAP: System zur Erzeugung von Wrappern 

Bei XWRAP handelt es sich um ein interaktives System zur halbautomatischen Konstruktion 

von Wrappern für Webquellen. Die zu konstruierenden Wrapper sind darauf ausgelegt, 

implizite Metadaten über Informationsinhalte in den HTML-Seiten der Quellen zu extrahieren 

9

und als XML-Tags in den gewrappten Dokumenten zu kodieren. Die Transformation von 

HTML in programmfreundliches XML ermöglicht den Zugriff von Anwendungen auf die 

Quellen mit XML-Querysprachen. Vorlage für die automatische Wrappergenerierung ist eine 

vom Benutzer anzugebende typische Beispielseite der zu wrappenden Datenquelle. 

Architektur: 

Abbildung 6: Architektur von XWRAP 

Komponenten: 

Syntaktische Strukturnormalisierung (Syntactical Structure Normalication) 

Diese Komponente ruft das vom Benutzer vorgegebene Dokument ab und generiert zugleich 

Regeln für den Abruf, die in den Wrappercode übernommen werden. Anschließend wird die 

Syntax der Seite überprüft und evtl. Fehler im HTML-Text korrigiert (z. B. fehlende oder 

nutzlose Tags, unerlaubtes Schachteln bestimmter Elemente). Ferner wird die Seite geparst 

und ein „syntaktischer Token-Baum“ erstellt, wobei die inneren Knoten des Baumes aus den 

identifizierten HTML-Tags oder Paaren von Tags bestehen und die Blätter aus semantischen 

Tokens, d. h. den zwischen den Tags stehenden Inhalten. 

Informationsextraktion (Information Extraction) 

In diesem Schritt werden deklarative Informationsextraktionsregeln erzeugt. Der Benutzer 

markiert über ein interaktives, graphisches Interface interessante Regionen, interessante 

semantische Tokens und interessante Hierarchiestrukturen (z. B. Tabellen) im syntaktischen 

Token-Baum. Aus jedem Schritt generiert das System jeweils eine Menge von 

Extraktionsregeln, die in einer XML-Template-basierten Sprache beschreiben, wie 

interessante Informationen aus der Quelle gewonnen werden können. Dank des graphischen 

Interfaces ist der Benutzer nicht gezwungen, selbst Informationsextraktionsregeln in einer 

deklarativen Sprache zu formulieren. 

Codegenerierung (Code Generation) 

In dieser Phase wird anhand der zuvor erstellten Regeln der Programmcode für den Wrapper 

erzeugt. Die Trennung der Informationsextraktionssemantik von der Codegenerierung 

erleichtert die Erweiterung, Wartung und Anpassung der Wrapperprogramme. Zur 

Generierung benutzt des System eine Komponentenbibliothek mit Grundbausteinen für 

Wrapperprogramme 

10

Testen und Verpacken (Testing and Packaging) 

Zum Testen des generierten Programms kann der Benutzer eine Reihe von alternativen URLs 

der zu wrappenden Quelle eingeben. Für jede URL führt das Testmodul die syntaktische 

Strukturnormalisierung und Informationsextraktion durch, um zu prüfen, ob neue 

Extraktionsregeln oder Updates für bestehende abgeleitet werden können. Ggf. wird der 

Wrappercode neu generiert. 

4. Mediatoren 

Es wurde bereits erwähnt, dass Mediatoren einen Teil der Middleware darstellen und sich im 

Gegensatz zu Wrappern, die auf eine Datenquelle spezialisiert sind, auf den Aspekt des 

zentralen und effizienten Zugriffs auf mehrere heterogene Quellen konzentrieren. 

4.1 Definition / Aufgaben 

Definition: 

Der Begriff des Mediators wurde von [Wiederhold 1992] als Architekturkomponente in 

zukünftigen Informationssystemen eingeführt. In der ursprünglichen Definition wurde ein 

Mediator als komplexe Softwarekomponente beschrieben, die Daten „vereinfacht, abstrahiert, 

reduziert, mischt und erklärt“ [Wiederhold 1992]. In der Folgezeit hat sich jedoch eine engere 

Interpretation des Begriffes herausgebildet, derzufolge ein Mediator „Daten aus einer oder 

mehreren Quellen mit Hilfe einer deklarativen Spezifikation integriert und transformiert“ 

[Abiteboul, Buneman, Suci 2000] 

Aufgaben 

- Auswahl geeigneter Quellen für eine eingehende Query 

- Erstellen eines Query-Planes, in dem festgelegt wird, welche Quellen in welcher 

Reihenfolge abgefragt werden. 

- Ggf. Anpassen der Query an die Abfragemöglichkeiten der einzelnen Quellen 

(query rewriting) 

- Durchführen des Query-Planes 

- Kombination und Integration der Teilergebnisse 

11

4.2 Architektur und funktionale Aspekte 

Abbildung 7: Architektur eines Mediators 

Verhältnis Wrapper - Mediator 

Wie bereits im Zusammenhang mit den Einsatzmöglichkeiten von Wrappern dargestellt, 

treten Mediatoren in Informationsintegrationssystemen häufig in Kombination mit Wrappern 

auf, wobei sich die Wrapper an der Schnittstelle zwischen Mediator und Datenquelle 

befinden, wie u. a. an der vorstehenden Abbildung ersichtlich. 

Grundsätzlich ist davon auszugehen, dass die Wrapper hierbei eine einheitliche Schnittstelle 

zu Verfügung stellen, während der Mediator die Anfragen auf die Quellen aufteilt und Daten 

aus den verschiedenen Quellen integriert. Es sind jedoch Variationen in der Aufteilung 

möglich, wobei die Extreme durch die beiden folgenden Fälle dargestellt werden: 

Fat Wrapper: 

Diese Wrapper erhalten den Teil der Anfrage der für die jeweilige Datenquelle relevant ist, 

ausgedrückt in der globalen Anfragesprache. Neben der Übersetzung der globalen 

Anfragesprache in die Schnittstellensprache der Datenquelle ist auch die gesamte strukturelle 

und semantische Anpassung durch den Fat Wrapper zu implementieren. Dies hat zur Folge, 

dass der Mediator schlank und performant bleiben kann, da er nur die passende Datenquelle 

finden, die Anfrage in einzelne Unteranfragen aufteilen und ggf. die Ergebnisse 

zusammenfassen muss. Andererseits ist die Erweiterung des Systems um eine neue 

Datenquelle aufwendig, da viel Funktionalität in dem für diese Quelle neu zu konstruierenden 

Wrapper implementiert werden muss. 

Thin Wrapper: 

Im Gegensatz zu den Fat Wrappern werden bei den Thin Wrappern so viele Aufgaben wie 

möglich vom Mediator übernommen. Dies setzt jedoch voraus, dass der Mediator eine Reihe 

12

von Modellen, Schemata und Verfahren der Datenquellen kennt. Die Performanz des 

Mediators ist dadurch offensichtlich schlechter als bei Fat Wrappern, da er größere Teile der 

Anfrageverarbeitung übernimmt. Dafür ist es einfach, neue Datenquellen hinzuzufügen, 

wodurch eine gute Erweiterbarkeit des Systems gewährleistet wird. 

Schnittstelle Anwendung – Mediator 

Anfragesprache: 

Benutzer greifen selten direkt, sondern über eine entsprechende Anwendung auf den Mediator 

zu. Ferner ist die Funktionalität, die der Mediator den zugreifenden Anwendungen zur 

Verfügung stellt, sehr vielfältig. Daher kommt für diese Schnittstelle vor allem eine 

Anfragesprache in Betracht, die die vielfältigen Funktionen des Mediators abdeckt und 

garantiert, dass Anwendungen diese in einfacher Weise nutzen und deren Ergebnisse 

einheitlich auswerten können. Eine solche Sprache könnte ähnlich den Sprachen sein, die 

relationale oder objektorientierte Datenbanken bereitstellen, also z. B. SQL. 

Es sind allerdings folgende zusätzlich Anforderungen zu berücksichtigen: 

- Unterstützung verschiedener Anfragetypen: 

Sowohl die vorhandenen Informationsbedürfnisse als auch die Web-Datenquellen 

sind äußerst verschieden. Neben exakten Anfragen, wie sie von Datenbanksystemen 

bekannt sind, sollten daher auch vage Anfragen möglich sein. Dies spielt 

insbesondere auch in den Fällen eine Rolle, in denen die Struktur der Datenquellen 

dem Anfragenden nicht bekannt ist oder semi- bzw. unstrukturierte Datenquellen 

vorliegen. 

- Schemaabhängigkeit 

Da der Benutzer nicht gezwungen sein soll, das spezifischen Schema jeder 

einzelnen Quelle zu kennen und zu berücksichtigen, wird i. d. R. ein globales 

Schema (world view) definiert, welches eine integrierte Sicht über alle Quellen 

bietet (siehe auch Metadaten-Repository). Die Anfragesprache sollte die Anfrage in 

Abhängigkeit von diesem globalen Schema ermöglichen. 

- Zugriff auf Metadaten: 

Um die Schemaabhängigkeit überhaupt gewährleisten zu können, muss die 

Anfragesprache einen Zugriff auf die Metadaten des Systems ermöglichen. 

Ergebnispräsentation: 

Im Falle vager Anfragen besteht das Ergebnis nicht wie in einem Datenbanksystem aus allen 

Datensätzen, die der Anfrage entsprechen. Es handelt sich vielmehr - wie bei Information- 

Retrieval-Systemen - um alle Ergebnisse, die dem Mediator relevant erscheinen. Der 

Mediator muss neben der Ausgabe exakter Ergebnisse auch über entsprechende 

Ausgabetechniken wie „Ranked List“ und Berücksichtigung von „Relevance Feedback“ 

verfügen. 

Metadaten – Repository 

Um beurteilen zu können, welche Quellen für die Beantwortung einer Anfrage geeignet sind, 

wie die Anfrage ggf. aufzuteilen und durchzuführen und wie die Teilergebnisse zu integrieren 

sind, benötigt der Mediator Schemata und Metainformationen über die verfügbaren Quellen. 

13

Die Metainformationen werden wie erwähnt i. d. R. in einer globalen Sicht vereint, welche 

zugleich als Schema dient, gegen das der Benutzer seine Anfragen stellt. Zur Speicherung 

dieser Informationen dient das Metadaten-Repository des Mediators. Bei der Verwendung 

von Fat Wrappern würde ein Teil der Metainformationen aus dem Repository in die Wrapper 

verlagert. 

Kombination von Mediatoren 

Neben einer Architektur mit einem zentralen Mediator sind auch Systeme denkbar, in denen 

eine Vielzahl von Mediatoren eingesetzt ist, die jeweils auf eine bestimmte Domäne oder 

einen Aufgabenbereich spezialisiert sind. Dabei greifen Mediatoren ebenso wie 

Anwendungen auf andere Mediatoren zurück. Eine solche Architektur erhöht die Flexibilität 

und Erweiterbarkeit, stellt jedoch auch erheblich höhere Anforderungen an die Koordination 

und die Kommunikation zwischen den Komponenten. 

4.3 Anfrageverarbeitung 

Die Anfrageverarbeitung kann im wesentlichen in drei Schritte eingeteilt werden: 

1. Auswahl der Quellen 

Der erste Schritt bei der Verarbeitung einer Anfrage besteht darin festzustellen, welche 

der vorhandenen Datenquellen Informationen zu einem Gesamtergebnis beitragen 

könnten. Dies wird vor allem durch die in den Quellen vorhandenen Attribute und 

eventuelle Beschränkungen des Wertebereichs bestimmt. Bei der Auswahl können 

jedoch auch Verfügbarkeit und Performanz der Quellen eine Rolle spielen. 

2. Anfrageaufteilung und -optimierung 

Aufbauend auf den ausgewählten Quellen werden nun Query-Pläne erstellt, in denen 

festgelegt wird, welche Teilabfragen auf welchen Quellen ausgeführt werden und in 

welcher Reihenfolge diese Teilabfragen erfolgen müssen. 

Bei der Aufteilung ist zusätzlich zur Frage, ob eine Quelle allgemein einen Beitrag 

leisten kann, auch die Semantik zu berücksichtigen. D. h. es ist zu analysieren, in 

welchem Verhältnis die Attribute einer Quelle zu denen der Anfrage und/oder anderer 

Quellen stehen. Derartige semantische Unterschiede werden i. d. R. im Vorfeld mit 

Hilfe von semantische Abbildungen zwischen den Inhalten der Datenquellen und der 

integrierten Gesamtsicht modelliert. In dieser Phase können potentielle Quellen auch 

wieder entfallen, da das von ihnen gelieferte Teilergebnis nicht sinnvoll mit 

Teilergebnissen aus anderen Quellen zu einem Gesamtergebnis kombiniert werden 

kann. Die einzelnen Pläne werden nun nach Performanzkriterien optimiert. Falls 

festgestellt werden kann, dass mehrer Pläne ein identisches Ergebnis liefern, wird 

unter diesen außerdem der kostengünstigste ausgewählt. 

3. Anfrageausführung und Ergebnisintegration 

In diesem Schritt werden die Pläne ausgeführt, indem die jeweils relevanten Daten aus 

den Quellen ausgelesen und verarbeitet werden. Ähnlich wie bei Datenbanksystemen 

müssen diese korreliert und selektiert werden, sowie Abstraktionen und Aggregationen 

durchgeführt werden. 

Hier spielt erneut das Problem der semantischen Heterogenitäten eine entscheidende 

Rolle. Die bei der Anfragebearbeitung erkannten Konflikte müssen mit Hilfe 

entsprechender Integrationsregeln für die Transformation und Verarbeitung der 

14

Ergebnisse beseitigt werden. Finden sich in den Datenquellen neben semantischen 

auch strukturelle Unterschiede (z. B. einerseits Speicherung einer Information als 

Attribut, andererseits als eigene Relation) dann müssen ggf. auch 

Schematransformationen durchgeführt werden. 

Beispiel für die Erstellung eines Query Plans: 

Gegeben seien folgende Informationsquellen auf dem Web in der Domäne Fahrzeugkauf: 

Quelle Input Output 

1: Gebrauchtwagen Kategorie oder Modell Modell, Jahr, Preis, 

optional: Preisbereich,Baujahr Kontaktinformationen 

2: Luxuswagen ab 20000 $ Kategorie 

Modell, Jahr, Preis, 

optional: Preisbereich Kontaktinformationen 

3: Oldtimer (älter als 1950) Modell 


optional: Baujahr 

Kontaktinformationen 

4: Motorräder Modell 


optional: Preisbereich Kontaktinformationen 

5: Modellbeschreibungen Modell und Jahr Beschreibung 

An das System wird folgende Anfrage gestellt: 

Gesucht sind Preis und Beschreibungen für zu verkaufende Sportwagen, die nach 1992 gebaut 

wurden. 

Auswahl der Quellen: 

- Quelle 4 ist offensichtlich nicht relevant, da sie keine Autos enthält. 

- Quelle 3 ist aufgrund ihres Wertebereichs nicht interessant, da sie nur vor 1950 

gebaute Fahrzeuge enthält. 

- In Frage kommen offensichtlich Quellen 1, 2 und 5. 

Damit können folgende Query Pläne erstellt werden: 

Plan 1: 

- Befrage Quelle 1 nach Modell, Jahr und Preis für alle Sportwagen, die nach 1992 

produziert wurden. 

- Erhalte eine Beschreibung von Quelle 5 für jedes Modell 

- Produziere eine Menge von -Tupeln. 

Plan 2: 

- Frage Quelle 2 nach den Modellen, Baujahren und Preisen für Sportwagen. 

- Wähle aus den -Tupeln, die sich ergeben, diejenigen aus, bei 

denen das Jahr >= 1992. 

- Erhalte eine Beschreibung von Quelle 5 für jedes Modell der ausgewählten Tupel 

- Produziere eine Menge von -Tupeln 

Die Antwort auf die Anfrage ist die Vereinigung der beiden Tupelmengen. 

4.4 Erstellung eines globalen Schemas 

Da der Benutzer seine Anfragen in der Regel in der Form des globalen Schemas stellt, die 

Daten zur Beantwortung jedoch in externen Quellen gespeichert sind, hängt die Qualität eines 

Mediationssystems entscheidend von Beschreibungen ab, die die Inhalte einer Quelle mit den 

15

Klassen, Attributen und Relationen des globalen Schemas in Beziehung setzen. Für eine 

effiziente Abwicklung der Anfrageverarbeitung kommt es insbesondere auch darauf an, die 

semantischen Unterschiede zwischen den Quellen zu erkennen und entsprechend zu 

modellieren. 

Hierzu werden Abbildungsvorschriften zwischen den Datenschemata der Quellen und dem 

globalen Schema verwendet, wobei u. a. folgende Fälle unterschieden werden können: 

(Als Beispiel dient ein Informationsintegrationssystem für Online-Angebote von Immobilien) 

- Ein Schemaelement (bestehend aus Attribut und zugehörigem Wert) eines 

Quellschemas kann 1:1 auf ein Schemaelement des globalen Schemas abgebildet 

werden. 

Beispiel: Abbildung von Listenpreis (Quellschema) auf Preis (globales Schema) 

- Ein Element des einen Schemas entspricht mehreren Elementen des anderen. 

Beispiel: Anzahl Badezimmer (globales Schema) entspricht der Summe der Anzahl 

der Elemente „vollständige Badezimmer“ und „halbe Badezimmer“ (Quellschema). 

- Element eines Schemas entspricht dem Wert eines Elementes in dem anderen 

Beispiel: Element „behindertengerecht“ mit Wert ja/nein (Quellschema) entspricht 

dem Wert („behindertengerechte Ausstattung“) des Elementes „Extras“ (globales 

Schema). 

Derartige semantische Mappings, die für jede Quelle vorgenommen werden müssen, stellen 

ein erhebliches Hindernis für die Datenintegration dar, da die manuelle Erstellung der 

Abbildungsvorschriften arbeitsaufwendig und fehlerhaft ist. Es gibt daher Ansätze, die 

Mappings mit Methoden des maschinellen Lernens (halb)automatisch zu ermitteln. [Doan, 

Domingos, Levy 2000] schlagen dazu ein System vor, welches anhand von manuellen 

Beispielmappings für einige Quellen lernt und mit Hilfe des gelernten Wissens Mappings für 

weitere Quellen vorschlägt. 

Dabei werden folgende Möglichkeiten des Lernens eingesetzt: 

(Beispiel ist nochmals das Informationsintegrationssystem für Online-Angebote von 

Immobilien) 

- Ähnlichkeit von Attributnamen, berechnet mit TF/IDF-Ähnlichkeitsmaß 

Beispiel: Vergleich der Elemente „Kontakttelefon“ (Quellschema) und 

„Maklertelefon“ (globales Schema) indiziert Matching 

- Eigenschaften der Daten (Zuordnung mit Hilfe eines naiven Bayes Klassifikators) 

Beispiele: 

- Kleine numerische Werte weisen eher auf das Attribut Zimmerzahl als das 

Attribut Preis hin. 

- Bei Telefonnummern mit ähnlichen Zifferfolgen handelt es sich eher um 

Bürotelefone. 

- Abstand der Elemente: 

Beispiel: 

- Langes Textfeld am Anfang eines Hauseintrages weist auf eine Beschreibung 

der Immobilie hin. 

- Maklertelefon steht meist in der Nähe der Adresse des Maklerbüros. 

16

4.5 Information Manifold – Beispiel für den Einsatz von Mediator-Technik 

Information Manifold ist ein implementiertes Informationsintegrationssystem der Stanford 

University [Levy, Rajaraman, Ordille 1996], welches einheitlichen Zugang zu einer 

Sammlung von mehr als 100 Quellen bietet, von denen sich ein großer Teil auf dem WWW 

befindet. Der wissenschaftliche Schwerpunkt des Systems liegt auf der Mediator-Komponente 

und dabei insbesondere auf effizienten Methoden zur Auswahl von Quellen und Erstellung 

von Query Plänen. 

Integrierte Sicht / Auswahl von Quellen 

Information Manifold benutzt das bei Mediatoren übliche Instrument eines globalen Schemas, 

um eine integrierte Sicht zu bieten, gegen die der Benutzer Anfragen stellen kann. In der 

Regel werden derartige integrierte Sichten als Query über den Quellen gesehen (global as 

view). Dies entspricht auch der natürlichen Konstruktion einer Sicht, indem von den 

Originaldaten ausgegangen wird. Dieser Ansatz hat jedoch den Nachteil, dass er sehr 

laufzeitintensiv sein kann. Bei n Quellen müssen ggf. n² Interaktionen zwischen den Quellen 

ausgeführt werden, um eine Sicht zu konstruieren. 

Bei Information Manifold wird ein entgegengesetzter Ansatz verfolgt: Die Quellen werden als 

Sichten auf den integrierten Daten beschrieben (local as view). Dies hat den Vorteil, dass bei 

n Quellen nur n Sichten benötigt werden. Ferner können die oft feingranularen Unterschiede 

zwischen den Quellen besser modelliert werden, da in der Definition einer Sicht, die eine 

Quelle beschreibt, die Bedingungen exakt angegeben werden können, die alle Tupel der 

fraglichen Relation charakterisieren. Ausgehend von diesen exakten Beschreibung ist eine 

effiziente Auswahl der Quellen möglich, die für die Beantwortung einer Anfrage relevant 

sind. 

Im umgekehrten Falle, in dem das globale Schema als Query über den Quellen angesehen 

wird, können dagegen nur beschränkt Detailbeschreibungen der Quellen einfließen, wenn das 

globale Schema überschaubar gehalten werden soll. Ein weiterer Vorteil des vorliegenden 

Ansatzes ist, dass Quellen bequem hinzugefügt werden können, ohne dass die 

Beschreibungen der bisherigen Quellen geändert bzw. eine fest vordefinierte Gesamtsicht 

angepasst werden müsste. Nachteil hingegen ist, dass das globale Schema selbst eine 

minimale Instanz darstellt, die konsistent mit allen Definitionen ist. Die eigentliche 

Mächtigkeit der Mediator-Datenbank ist in den auf bekannten Zuständen der Quellen 

basierenden Sichtendefinitionen spezifiziert. Eine solche Spezifikation ist jedoch 

zwangsläufig unvollständig. 

Erstellung von Query-Plänen 

Zur Erstellung von Query-Plänen werden die Fähigkeiten der Quellen mit Hilfe von 

sogenannten Capability Records beschrieben. Diese spezifizieren für jede Quelle den 

möglichen Input, den möglichen Output und die Fähigkeit Selektionen vorzunehmen. 

Dadurch kann die Erstellung von Query-Plänen in zwei Phasen erfolgen: Zunächst werden 

alle semantisch korrekten Pläne ermittelt, d. h. alle Pläne, die die als Sichten beschriebenen 

Quellen benutzen und eine Antwort auf die Anfrage liefern. Anschließend werden die 

Teilpläne unter Berücksichtigung der Antwortfähigkeiten der Quellen so angeordnet, dass sie 

auch tatsächlich ausführbar sind. 

17

5. Informationsintegrationssysteme auf dem Web 

Die vorstehend beschriebenen Konzepte Wrapper und Mediator bilden die zentralen 

Bestandteile typischer Informationsintegrationssysteme auf dem Web und bestimmen 

wesentlich den Entwicklungsaufwand, die Leistungsfähigkeit und die Skalierbarkeit eines 

solchen Systems. Weitere Aspekte der Unterhaltung eines Informationsintegrationssystems 

auf dem Web wurden durch [Cohen 1999] untersucht. 

Zu diesem Zweck hat der Autor über mehrere Monate hinweg zwei webbasierte Informationsintegrationssysteme 

unterhalten, die gemeinsam datenbankähnliche Abfragen zu den 

Informationen auf mehr als 50 Websites (mehrere 1000 Einzelseiten) unterstützten. 

5.1 Entwicklung 

Bei der Entwicklung wurde in folgenden Schritten vorgegangen: 

1. Ermitteln relevanter Informationsquellen für eine Domäne 

2. Aufbau eines globalen Schemas 

3. Modellierung und Wrapping der einzelnen Websites 

4. Aufbau einer Abfrageschnittstelle zum globalen Schema 

5. Unterhaltungsphase: Wartung v. a. der einzelnen Wrapper und bei Bedarf Hinzufügen 

neuer Informationsquellen 

Vor der Erstellung der Gesamtsysteme wurden zunächst in entsprechender Weise 

anfänglicher Prototypen mit 5-10 der relevantesten Websites einer Domäne entwickelt und 

die Realisierbarkeit bezogen auf die gewählte Domäne evaluiert 

5.2 Praktische Aspekte 

Bei Entwicklung und Unterhaltung der Systeme wurden im wesentlichen folgende 

Beobachtungen gemacht: 

Grundsätzliche Realisierbarkeit 

Ein Informationsintegrationssystem in dieser Größenordnung ist grundsätzlich realisierbar. 

Besondere Hürden stellen jedoch v. a. die nachstehenden Aspekte dar: 

- Die Kosten für die Ermittlung von Informationsquellen steigen überproportional mit 

der Größe des Integrationssystems. D. h. einige wichtige Quellen eines Gebietes 

sind schnell gefunden. Die Ermittlung weiterer Quellen mit dem Ziel einer guten 

Abdeckung der Domäne ist jedoch zunehmend schwierig. 

- Auch die Komplexität beim Aufbau eines globalen Schemas nimmt mit der Zahl der 

berücksichtigten Quellen stark zu. Es sind zunehmend Abwägungen zu treffen, ob 

feine semantische Unterschiede zwischen Quellen modelliert werden sollen oder 

nicht. Im ersten Fall wird die Informationsextraktion zunehmend komplex, während 

im zweiten eventuell interessante Abfragen nicht ausgedrückt werden können. 

- Die Entwicklung eines Systems setzt noch viel Expertenwissen auf dem Gebiet der 

Informationsintegration voraus. Damit dies auch Nichtexperten möglich ist, wären 

zunächst bessere Tools erforderlich. 

18

Unterhaltung 

Für die Unterhaltung der Systeme wird mehr Zeit und Energie benötigt als für die anfängliche 

Entwicklung. Die Forschungsaktivitäten sollten daher auf Tools erweitert werden, die nicht 

nur die (halb)automatische Entwicklung, sondern auch eine entsprechende Unterhaltung 

unterstützen. 

Skalierbarkeit 

Generell gibt es einen Tradeoff zwischen der Anzahl der integrierten Quellen und der Tiefe 

des über eine Quelle vorhandenen Metawissens. D. h. der Aufbau von 

Informationsintegrationssystemen, die mehrere hundert oder tausend Websites abdecken 

sollen, wird extrem schwierig, da allein der Aufwand für die Erstellung und Unterhaltung des 

globalen Schemas und die Pflege des Zugriffswissens enorm aufwendig wäre. Eine mögliche 

Lösung für dieses Problem der Skalierbarkeit wäre der Aufbau einer Konföderation kleinerer 

spezialisierter Informationsintegrationssysteme. Hierbei wären allerdings neue Probleme wie 

die der gemeinsamen Anfragesprache und der Verteilung der Anfragen zu lösen. 

6. Literaturverzeichnis 

[Abiteboul, Buneman, Suci 2000] Abiteboul, Serge; Buneman, Peter, Suci, Dan: Data on the 

Web: From Relations to Semistructured Data and XML. San Francisco (Morgan Kaufmann 

Publishers) 2000 

[Cohen 1997] Cohen, William: Some practical observations on integration of Web 

information. Proc. WebDB99. 

Online verfügbar unter: 

http://www.rocq.inria.fr/~cluet/WEBDB/procwebdb99.html 

[Doan, Domingos, Levy 2000] Doan, AnHai; Domingos, Pedro; Levy, Alon: Learning 

Source Descriptions for Data Integration. Proceedings of the 3 rd International Workshop “The 

Web and Databases (WebDB), 2000 


http://www.research.att.com/conf/webdb2000/program.html 

[Foreman et al 1997] Foreman, John; Brune, Kimberly; McMillan, Patricia; Rosenstein, 

Robert: Software Technology Reference Guide – A Prototype. Pittsburgh (Software 

Engineering Institute, Carnegie Mellon University, 1997 

[Garcia-Molina et al 1997] Garcia-Molina, Hector; Papakonstantinou, Yannis; Quass, 

Dallan; Rajaraman, Anand; Sagiv, Yehoshua; Ullman, Jeffrey; Vassalos, Vasilis; Widom, 

Jennifer: The TSIMMIS Approach to Mediation: Data Models and Languages. Journal of 

Intelligent Systems, Volume 8, Number 2, S. 117-132, März/April 1997. 

[Levy, Rajaraman, Ordille 1996] Levy, Alon; Rajaraman, Anand; Ordille, Joann: Querying 

Heterogeneous Information Sources Using Source Descriptions. Bombay (Proceedings of 

22th Conference on Very Large Databases, S. 251-262) 1996. 

19

[Liu, Pu, Han 2000] Liu, Ling; Pu, Calton; Han, Wei: XWRAP: An XML-enabled Wrapper 

Construction System for Web Information Sources. ICDE 611-621, 2000. 

Auch online verfügbar unter: 

http://www.cc.gatech.edu/projects/dil/XWRAP/ 

[Sahuguet, Azavant 1999] Sahuguet, Arnaud; Azavant, Fabien: WysiWyg Web Wrapper 

Factory (W4F). Proceedings of WWW Conference 1999. 

Sie auch online-Informationen unter: 

http://db.cis.upenn.edu/W4F 

[Wiederhold 1992] Wiederhold, Gio: Mediators in the Architecture of Future Information 

Systems. IEEE Computer Magazin, 25(3):38-49, März 1992. 

Auch online verfügbar unter: 

http://www-db.stanford.edu/pub/gio/gio-papers.html 

[Wells 1996] Wells, David: Wrappers. Survey, Object Services and Consulting, Inc., 1996. 


http://www.objs.com/survey/wrap.htm 

20

Schriftliche Ausarbeitung zum Referat - Universität Konstanz

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?