Schriftliche Ausarbeitung zum Referat - Universität Konstanz
Schriftliche Ausarbeitung zum Referat - Universität Konstanz
Schriftliche Ausarbeitung zum Referat - Universität Konstanz
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Gliederung<br />
<strong>Schriftliche</strong> <strong>Ausarbeitung</strong> <strong>zum</strong> <strong>Referat</strong><br />
Integration von Web-Datenquellen<br />
Michael Bohner<br />
<strong>Universität</strong> <strong>Konstanz</strong>, Seminar Data on the Web SS2001<br />
bei Prof. Dr. Marc Scholl<br />
1. Einleitung<br />
1.1. Motivation für die Integration von Web-Datenquellen<br />
1.2. Problematik<br />
2. Grundsätzlicher Lösungsansatz: Mittelschicht<br />
2.1 Data Warehouse<br />
2.2 Middleware / Informationsintegrationssysteme<br />
3. Wrapper<br />
3.1 Definition und Aufgaben<br />
3.2 Logisches Modell<br />
3.3 Konzept<br />
3.4 Vor- und Nachteile des Wrappings<br />
3.5 Erzeugung von Wrappern<br />
3.6 Beispiel XWRAP: System zur Erzeugung von Wrappern<br />
4. Mediatoren<br />
4.1 Definition und Aufgaben<br />
4.2 Architektur und funktionale Aspekte<br />
4.3 Anfrageverarbeitung<br />
4.4 Erstellung eines globalen Schemas<br />
4.5 Information Manifold: Beispiel für den Einsatz von Mediator-Technik<br />
5. Informationsintegrationssysteme auf dem Web<br />
5.1 Entwicklung<br />
5.2 Praktische Aspekte<br />
6. Literaturverzeichnis<br />
1
1. Einleitung<br />
1.1 Motivation<br />
Der überwältigende Erfolg des World Wide Web ist zugleich auch die Ursache eines seiner<br />
größten derzeitigen Probleme: Die ständig wachsende Informationsmenge wird zunehmend<br />
unüberschaubar und kann mit herkömmlichen Navigations- und Suchmethoden nicht mehr<br />
umfassend und effizient erschlossen werden. Bei diesen Methoden (überwiegend<br />
Schlüsselwortsuche und benutzergesteuertes Browsing) wird das Web üblicherweise als<br />
verlinkte Sammlung unstrukturierter Dokumente angesehen. Tatsächlich nimmt jedoch die<br />
Zahl strukturierter und semi-strukturierter Datenquellen im WWW, die beispielsweise<br />
Produktinformationen, Wirtschafts- und wissenschaftliche Informationen enthalten, ständig<br />
zu. Bei der manuellen Erschließung derartiger Quellen bzw. der Erschließung mittels<br />
Indexierung und Schlüsselwortsuche bleibt deren zugrundeliegende Struktur allerdings<br />
weitgehend ungenutzt. Ein sehr viele effizientere Nutzung wäre möglich, wenn komplexe<br />
Abfragen an die Datenquellen abgesetzt werden könnten.<br />
Ferner ist der Benutzer bisher meist gezwungen, auf jede Datenquelle manuell zuzugreifen.<br />
Das bedeutet, dass er über eine Liste möglicher Quellen verfügen und entscheiden muss,<br />
welche davon er benutzen möchte. Anschließend muss er mit jeder Quelle einzeln<br />
interagieren und die Informationen aus verschiedenen Quellen manuell kombinieren. Neben<br />
der Erschwernis für den menschlichen Nutzer betrifft dies insbesondere auch die<br />
automatisierte Informationsgewinnung: Die Erstellung und Wartung von maßgeschneiderten<br />
Parsingprogrammen für eine Vielzahl sich häufig ändernder Websites dürfte selten mit<br />
lohnendem Aufwand zu realisieren sein.<br />
Ein wesentlicher Schritt auf dem Weg zu einer effizienten Informationsgewinnung im WWW<br />
wäre daher die Nutzung der Daten in den Quellen zur Beantwortung komplexer Anfragen<br />
kombiniert mit der Bereitstellung einer einheitlichen, zentralen Schnittstelle für alle (in Frage<br />
kommenden) Informationsquellen. Dies setzt jedoch die Integration verschiedener<br />
Datenquellen im Web voraus.[Levy, Rajaraman, Ordille 1996] S. 1f<br />
1.2 Problematik<br />
Die bei der Integration auftretenden Schwierigkeiten sind v. a. mit der großen Heterogenität<br />
der Web-Datenquellen verbunden. Im wesentlichen stellen sich folgende Probleme<br />
[Wiederhold 92]:<br />
Heterogenität bei der Repräsentation und Struktur der Daten (Data Mismatch):<br />
Hierbei können u. a. folgende Fälle unterschieden werden:<br />
- Unterschiede bei der Benennung eines Realweltgegenstandes:<br />
Beispiel: Dasselbe Buch wird einer Quelle unter Alan Turing: The Enigma<br />
(Referenz für Leser) und in einer anderen unter QA29.T8H63 (Referenz für<br />
Bibliothekare) geführt.<br />
- Unterschiedliche Konzeptualisierungen in verschiedenen Quellen:<br />
Dabei handelt es sich häufig um einen unterschiedlichen Abdeckungsgrad in<br />
zeitlicher, räumlicher oder sonstiger inhaltlicher Hinsicht. Insbesondere bei der<br />
2
Verwendung gleichlautender Begriffe in unterschiedlichen Domänen ist aber auch<br />
eine völlig unterschiedliche Semantik denkbar.<br />
Beispiel: Zwei Online-Shops verwenden den Begriff PC. In einem Fall sind jedoch<br />
alle Personal Computer gemeint, während die andere Quelle unter dem Begriff nur<br />
IBM kompatible PCs versteht.<br />
- Unterschiedlicher Grad der Granularität<br />
Beispiel: Quelle mit Familieneinkommen (im Zusammenhang mit Besteuerung) vs.<br />
Quelle mit persönlichem Einkommen (im Zusammenhang mit Berufstätigkeit)<br />
Überlappungen und Inkonsistenzen zwischen mehreren Datenquellen:<br />
Falls zur Beantwortung einer Anfrage Antworten aus mehreren Datenquellen kombiniert<br />
werden sollen, tritt zusätzlich das Problem der inhaltlichen Überlappungen und<br />
Inkonsistenzen zwischen verschiedenen Quellen auf.<br />
Unterschiede in den inhaltlichen Antwortfähigkeiten<br />
Auf manchen Quellen sind eventuell nur Teile der Abfragen möglich, die auf anderen Quellen<br />
abgesetzt werden können bzw. eine Abfrage ist nur möglich, wenn die Anfrage bestimmte<br />
Schlüsselinhalte enthält.<br />
Unterschiede in den Zugriffssprachen und der technischen Verfügbarkeit<br />
Hierzu zählen insbesondere Zugriffsprotokolle, Zugriffsgeschwindigkeit und zeitliche<br />
Verfügbarkeit.<br />
2. Grundsätzlicher Lösungsansatz: Mittelschicht<br />
Der grundlegende Ansatz zur Lösung des Datenintegrationsproblems im Web ist ein<br />
„Mehrschichten-Konzept“ (multitier approach). Das bedeutet, dass unter Abkehr von der<br />
klassischen Client/Server-Architektur in Datenbanksystemen eine zusätzliche Schicht<br />
zwischen den Datenquellen und den abfragenden Systemen eingezogen wird (Abbildung 1).<br />
Client Client Client<br />
Abbildung 1: Lösungskonzept: Mittelschicht<br />
Mittelschicht<br />
Server Server Server<br />
3
Die unterste Schicht besteht aus den Datenquellen. Dies können konventionelle<br />
Datenbankserver aber auch alle sonstigen Systeme sein, die in irgendeiner Weise Objekte mit<br />
Informationen enthalten, auf die von außerhalb zugegriffen werden kann. In dieser sehr<br />
allgemeinen Bedeutung wird der Begriff hier auch weiter verwendet werden.<br />
Die oberste Schicht, die Client-Schicht besteht aus Benutzerschnittstellen oder Anwendungen,<br />
die Daten verarbeiten. Dazwischen können sich eine oder mehrere Mittelschichten befinden,<br />
die für die Transformation und Integration und ggf. sonstige Veredelung der Daten sorgen.<br />
[Abiteboul, Buneman, Suci 2000] S. 5f<br />
Für die Mittelschicht, die letztlich das Integrationsproblem löst, gibt es prinzipiell zwei<br />
Ansätze:<br />
2.1 Data Warehouse<br />
Eine mögliche Form der Mittelschicht stellt ein Data Warehouse dar. Bei diesem Ansatz<br />
werden die Daten aus den verschiedenen Quellen extrahiert, in der gewünschten Form<br />
aufbereitet und vereinheitlicht und in einer speziell dafür entworfenen Datenbank (dem<br />
Warehouse) abgespeichert. Das Data Warehouse bietet nun eine integrierte Sicht auf die<br />
Daten und kann effizient von den client-Anwendungen abgefragt werden. Dieses Konzept<br />
wird jedoch vor allem dazu angewandt, um konsistente, integrierte Sichten auf Daten aus<br />
verschiedenen Quellen eines Unternehmens zu bieten und somit fundierte und schnelle<br />
Managemententscheidungen zu ermöglichen. Ein Schwerpunkt liegt dabei auf der<br />
interaktiven Exploration der in das Data Warehouse eingebrachten Datenbestände (Online<br />
Analytical Processing). Diese Daten können allerdings auch aus Datenquellen im Web<br />
stammen (Stichwort: Web Farming) und ein Data Warehouse könnte selbst eine Datenquelle<br />
darstellen, auf die - z. B. in Kombination mit dem nachfolgend beschriebenen Konzept – über<br />
das Web zugegriffen wird.<br />
Abbildung 2: Lösungsansatz: Data Warehouse<br />
2.2 Middleware / Informationsintegrationssysteme<br />
Bei diesem Ansatz werden Anfragen des Clients durch die Middleware in eine auf die<br />
Datenquellen passende Form umgeschrieben und direkt auf den Quellen ausgeführt, wobei die<br />
4
Anfragen ggf. in mehrere Teilanfragen aufgespaltet werden. Teilergebnisse verschiedener<br />
Quellen werden wiederum durch die Middleware integriert, bevor sie an den Client<br />
zurückgegeben werden. Die Bearbeitung von Anfrage und Antwort geschieht on-the-fly – in<br />
der Middleware werden grundsätzlich keine Daten gespeichert. Dieses Konzept der<br />
Datenintegration bietet sich v. a. an, wenn die Aktualität der Daten kritisch ist und es<br />
schwierig oder unmöglich ist, die gesamten Daten aus den Quellen zu laden. Es ist daher im<br />
Gegensatz <strong>zum</strong> Data Warehouse besonders interessant für die Integration von Daten aus<br />
Webquellen, welche dadurch gekennzeichnet sind, dass ein Speichern der gesamten Daten der<br />
Quelle meistens nicht möglich ist und nur bedingt Mechanismen für automatische Updates<br />
zur Verfügung stehen. Die nachfolgenden Ausführungen konzentrieren sich daher auf<br />
Konzepte und Beispiele aus dem Bereich der Middleware.<br />
Abbildung 3: Lösungsansatz: Middleware<br />
Die in diesem Zusammenhang auftauchenden Begriffe werden leider noch nicht völlig<br />
einheitlich verwendet. So fassen [Abiteboul, Buneman, Suci 2000] auch das Data Warehouse<br />
unter den Begriff Middleware und verwenden für den vorliegenden Ansatz „Mediator<br />
System“. Andere Definitionen stellen hingegen darauf ab, dass es sich bei Middleware um<br />
Verbindungssoftware handelt, die es verschiedenen ehemals unabhängigen Anwendungen<br />
erlaubt, über ein Netzwerk miteinander zu interagieren. (z. B. [Foreman et al 1997]). Da<br />
Mediatoren häufig nur einen Teil der Aufgaben der Mittelschicht wahrnehmen – wie<br />
nachstehend gezeigt werden soll – wird hier für den Ansatz der on-the-fly durchgeführten<br />
Informationsintegration Middleware oder der allgemeinere Begriff<br />
Informationsintegrationssystem (entsprechend auch [Cohen 1999] verwendet werden.<br />
Im Rahmen von Informationsintegrationssysteme können zwei weitere grundlegende<br />
Konzepte unterschieden werden, die sich Teilaspekten des Integrationsproblemes annehmen.<br />
Hierbei handelt es sich um die Ansätze Wrapper und Mediatoren, die nachfolgend behandelt<br />
werden sollen. Obwohl es auch hier zu begrifflichen Überlappungen kommt, kann eine<br />
allgemeine Unterscheidung dahingehend erfolgen, dass bei den Wrappern, das erwähnte<br />
Problem der Erschließung einer Datenquelle für eine Abfragesprache im Vordergrund steht,<br />
während Mediatoren auf die Schaffung einer zentralen Schnittstelle für mehrere Quellen und<br />
deren integrierte Auswertung abzielen.<br />
5
3. Wrapper<br />
3.1 Definition/Aufgaben<br />
Bei Wrappern handelt es sich um einen Typ von Software, der eine Datenquelle so einkapselt,<br />
dass sie bequemer nutzbar ist, als die ursprüngliche, nicht verpackte Datenquelle.<br />
Wrapper können für folgende Aufgaben eingesetzt werden:<br />
- Schaffung einer vereinfachten Schnittstelle für eine Datenquelle<br />
- Vereinheitlichung der Schnittstellen verschiedener Quellen<br />
- Erhöhung der Funktionalität einer Datenquelle<br />
- Offenlegung von internen Schnittstellen einer Quelle<br />
3.2 Logisches Modell<br />
Alle Wrapper basieren auf dem folgenden logischen Grundmodell:<br />
Die betrachtete Datenquelle wird normalerweise mit einer Sprache Z angesprochen und liefert<br />
Resultate, die in Modell W ausgedrückt sind. Die Anwendung möchte aber die Sprache X<br />
verwenden und erwartet Antworten, die in Modell Y ausgedrückt sind. Der Wrapper<br />
konvertiert Befehle aus der Sprache X in die Sprache Z und Antwortdaten aus dem Modell W<br />
in das Modell Y, welches die Anwendung weiter verarbeiten kann.<br />
Applikation<br />
Sprache X Sprache Z<br />
Datenmodell Y<br />
Abbildung 4: Logisches Modell eines Wrappers<br />
Wrapper<br />
Datenmodell W<br />
Ein typisches Beispiel für den Einsatz von Wrappern für die Datenintegration im Web stellt<br />
folgendes Szenario dar:<br />
Datenquelle<br />
Datenquelle ist eine Website mit Produktinformationen. Die HTML-Seiten dieser Site werden<br />
zwar mit Hilfe einer Datenbank generiert, auf diese kann jedoch nicht direkt zugegriffen<br />
werden. Die einzige Sprache die die Quelle versteht, sind HTTP-Requests; als Antworten gibt<br />
sie HTML-Seiten zurück. Die Applikation benutzt jedoch eine XML-Querysprache und<br />
erwartet die Rückgabe entsprechender Datensätze. Der Wrapper fragt daher die HTML-Seiten<br />
der Datenquelle ab und transformiert die relevanten Inhalte in XML-Dokumente. Somit bietet<br />
er der Applikation eine XML-Schnittstelle, die entsprechende Queries auf die gewrappte<br />
Datenquelle möglich macht.<br />
6
3.3 Konzept<br />
Ein Wrapper ist immer genau einer Datenquelle zugeordnet, d. h. er kann genau die<br />
Datenquelle verwalten, für die er erstellt wurde.<br />
Ein weiteres wesentliches Merkmal des Wrappings ist, dass die Kapselung nur für die<br />
Beziehung zwischen der Datenquelle und den Anwendungen gilt, die den Wrapper benutzen.<br />
Somit behalten alle verwendeten Datenquellen ihre logische und physische Unabhängigkeit.<br />
Dies hat den Vorteil, dass Anwendungen, die direkt auf die Datenquelle zugreifen, durch das<br />
Wrapping nicht beeinträchtigt werden.<br />
Es sind grundsätzlich zwei Einsatzszenarien für Wrapper denkbar:<br />
- Einzelne Wrapper<br />
Wie in obiger Abbildung dargestellt steht eine Applikation direkt über einem<br />
Wrapper. Sie ruft diesen direkt auf, um Daten der gekapselten Quelle abzufragen.<br />
- Wrapper in Informationsintegrationssystemen<br />
Wrapper werden in einem System mit mehreren heterogenen Datenquellen<br />
eingesetzt, um jeweils eine Datenquelle in der Form einzukapseln, dass sie der<br />
gemeinsamen Schnittstelle entspricht, die das System für alle Datenquellen erwartet.<br />
I. d. R. existiert noch eine Art Vermittlungsmodul, in Form eines oder mehrerer<br />
Mediatoren, welches die Anfragen der Anwendung entgegennimmt, den Einsatz der<br />
einzelnen gewrappten Datenquellen plant, über die Wrapper auf die Datenquellen<br />
zugreift und die Ergebnisse zurückgibt. Eine derartige Architektur ist typisch für<br />
Informationsintegrationssysteme wie z. B. TSIMMIS [Garcia-Molina et al 1997].<br />
Anwendung<br />
Mediator<br />
Wrapper<br />
Datenquellen<br />
Abbildung 5: Wrapper in Informationsintegrationssystemen<br />
7
Neben der Grundfunktionalität Anfragen entgegenzunehmen und Ergebnisse zu liefern,<br />
können Wrapper zusätzlich mit komplexeren Funktionalitäten ausgestattet sein. Hierbei sind<br />
insbesondere die Eigenschaften, Updates der Datenquelle zu ermöglichen, Anmeldungen von<br />
Anwendungen beim Wrapper zu unterstützen und Auskunft über die eigenen<br />
Anfragefähigkeiten zu geben, zu nennen.<br />
3.4 Vor- und Nachteile des Wrappings<br />
Vorteile des Wrappings<br />
- Unabhängigkeit zwischen Anwendung und Quelle<br />
Die unabhängige Entwicklung der Clientanwendungen und der Web-Datenquellen,<br />
wird vereinfacht, da Veränderungen in der inneren Architektur der Datenquelle<br />
nicht mehr zwangsläufig Veränderungen der Clientanwendung nach sich ziehen<br />
müssen. Die Datenquelle kann somit verändert werden, ohne dass ihre Entwertung<br />
befürchtet werden muss, da ein Reengineering der Clients zu aufwendig wäre.<br />
Andererseits kann bei der Fortentwicklung des Clienten auf der durch den Wrapper<br />
dauerhaft angebotenen Schnittstelle aufgebaut werden, ohne dass auf Details der<br />
Quelle Rücksicht genommen werden muss. In beiden Fällen ist zwar der Wrapper<br />
anzupassen. Dies ist jedoch mit deutlich weniger Aufwand verbunden, da der<br />
Wrapper gerade auf das Transformationsproblem spezialisiert ist und in der Regel<br />
so konstruiert wird, dass Anpassungen leicht möglich sind.<br />
- Überwindung der Heterogenität<br />
Bei dem erwähnten Einsatz von Wrappern in Informationsintegrationssystemen<br />
leisten diese einen wesentlichen Beitrag zur Überwindung der Heterogenität. Neben<br />
ihrer Grundfunktionaliät, eine bestimmte Datenquelle für eine Abfragemöglichkeit<br />
zugänglich zu machen, gewährleisten die Wrapper gleichzeitig, dass sich die<br />
Anwendung bzw. das Vermittlungsmodul nicht um Unterschiede bei Datenformaten<br />
oder Zugriffssprachen verschiedener Quellen kümmern muss. Jeder Datenquelle ist<br />
ein eigener Wrapper zugeordnet, der sicherstellt, dass die Quelle mit der<br />
systemeinheitlichen Sprache angesprochen werden kann.<br />
- Gute Skalierbarkeit<br />
Middleware-Systeme, die Wrapping verwenden sind gut skalierbar. Soll eine neue<br />
Datenquelle integriert werden, so wird sie einfach über einen Wrapper angebunden.<br />
Wrapper sind aufgrund ihres einfachen Aufbaus meist relativ leicht zu erstellen.<br />
- Kostenersparnis<br />
Dies folgt aus den oben genannten Punkten. Vor allem die Unabhängigkeit von<br />
Anwendung und Quelle bedeutet eine deutliche Verringerung des Aufwands bei<br />
Weiterentwicklungen.<br />
- Unabhängigkeit der Datenquellen<br />
Eine Datenquelle, die für eine bestimmte Anwendung gewrappt ist, behält wie<br />
erwähnt ihre physische und logische Unabhängigkeit. Damit können andere<br />
Applikationen, die direkt auf sie zugreifen, dies nach wie vor - ohne Änderung ihrer<br />
Implementierung - tun.<br />
8
Nachteile des Wrappings<br />
- Schlechtere Performance<br />
Der Zugriff auf die Datenquelle erfolgt beim Wrapping indirekt im Gegensatz <strong>zum</strong><br />
direkten Zugriff ohne Wrapping. Dadurch wird der Zugriff langsamer. Insbesondere<br />
bei Systemen mit hohen Zugriffszahlen kann die Effizienz der Wrapper daher<br />
entscheidend sein.<br />
- Aktualität der Wrapper erforderlich<br />
Mit Veränderungen der Anwendung müssen ggf. auch die Wrapper angepasst<br />
werden, da Aktualität der Wrapper Grundvoraussetzung für das Funktionieren des<br />
Abfragesystems ist. Daraus können zusätzliche Kosten entstehen, wenn das<br />
Wrapping-System nicht gut konzipiert wurde.<br />
3.5 Erzeugung von Wrappern<br />
Bislang gibt es noch keine Standards über die interne Architektur von Wrappern.<br />
Insbesondere ist nicht geregelt, wie ein Wrapper von einer Anwendung bzw. einem<br />
Middleware-System angesprochen werden soll, d. h. es gibt keine Vereinbarungen über die<br />
Abfragesprachen (seitens der Anwendung) oder das Datenmodell der Wrapper. Der<br />
Austausch von Wrappern oder Wrapperkomponenten zwischen Systemen ist damit noch<br />
weitgehend ausgeschlossen.<br />
Es wird jedoch intensiv an Ansätzen zur automatischen bzw. halbautomatischen Generierung<br />
von Wrappern, insbesondere für das Web, geforscht.<br />
Dies hängt damit zusammen, dass die Programmierung von Wrappern „von Hand“ eine Reihe<br />
von Nachteilen mit sich bringt:<br />
- Inhalt und Struktur der Quellen im Web variieren sehr stark. Das bedeutet, dass<br />
jeder benötigte Wrapper von Grund auf neu geschrieben werden muss, da eine<br />
Wiederverwendung nicht möglich ist. Dies ist besonders gravierend angesichts der<br />
Tatsache, dass Informationsintegrationssysteme mit möglichst guter Skalierbarkeit<br />
(ausgehend von mindestens 100 Quellen) angestrebt werden.<br />
- Die Struktur von Online-Informationen wechselt regelmäßig, so dass häufige<br />
Anpassungen nötig sind.<br />
- Manuelle Entwicklung und Pflege von Wrappern ist generell sehr arbeitsaufwendig<br />
und fehleranfällig.<br />
Systeme zur Generierung von Wrappern für das WWW verwenden in der Regel deklarative<br />
Informationsextraktionsregeln, die der Benutzer in einer dafür konzipierten Sprache eingeben<br />
oder anhand einer Beispielseite der zu wrappenden Quelle mit Hilfe eines graphischen<br />
Interfaces spezifizieren kann. Basierend auf den Regeln wird anschließend der Wrappercode<br />
automatisch generiert. Beispiele für solche System sind W4F [Sahuguet, Azavant 1999] und<br />
XWRAP [Liu, Pu, Han 2000], welches nachfolgend vorgestellt werden soll.<br />
3.6 Beispiel XWRAP: System zur Erzeugung von Wrappern<br />
Bei XWRAP handelt es sich um ein interaktives System zur halbautomatischen Konstruktion<br />
von Wrappern für Webquellen. Die zu konstruierenden Wrapper sind darauf ausgelegt,<br />
implizite Metadaten über Informationsinhalte in den HTML-Seiten der Quellen zu extrahieren<br />
9
und als XML-Tags in den gewrappten Dokumenten zu kodieren. Die Transformation von<br />
HTML in programmfreundliches XML ermöglicht den Zugriff von Anwendungen auf die<br />
Quellen mit XML-Querysprachen. Vorlage für die automatische Wrappergenerierung ist eine<br />
vom Benutzer anzugebende typische Beispielseite der zu wrappenden Datenquelle.<br />
Architektur:<br />
Abbildung 6: Architektur von XWRAP<br />
Komponenten:<br />
Syntaktische Strukturnormalisierung (Syntactical Structure Normalication)<br />
Diese Komponente ruft das vom Benutzer vorgegebene Dokument ab und generiert zugleich<br />
Regeln für den Abruf, die in den Wrappercode übernommen werden. Anschließend wird die<br />
Syntax der Seite überprüft und evtl. Fehler im HTML-Text korrigiert (z. B. fehlende oder<br />
nutzlose Tags, unerlaubtes Schachteln bestimmter Elemente). Ferner wird die Seite geparst<br />
und ein „syntaktischer Token-Baum“ erstellt, wobei die inneren Knoten des Baumes aus den<br />
identifizierten HTML-Tags oder Paaren von Tags bestehen und die Blätter aus semantischen<br />
Tokens, d. h. den zwischen den Tags stehenden Inhalten.<br />
Informationsextraktion (Information Extraction)<br />
In diesem Schritt werden deklarative Informationsextraktionsregeln erzeugt. Der Benutzer<br />
markiert über ein interaktives, graphisches Interface interessante Regionen, interessante<br />
semantische Tokens und interessante Hierarchiestrukturen (z. B. Tabellen) im syntaktischen<br />
Token-Baum. Aus jedem Schritt generiert das System jeweils eine Menge von<br />
Extraktionsregeln, die in einer XML-Template-basierten Sprache beschreiben, wie<br />
interessante Informationen aus der Quelle gewonnen werden können. Dank des graphischen<br />
Interfaces ist der Benutzer nicht gezwungen, selbst Informationsextraktionsregeln in einer<br />
deklarativen Sprache zu formulieren.<br />
Codegenerierung (Code Generation)<br />
In dieser Phase wird anhand der zuvor erstellten Regeln der Programmcode für den Wrapper<br />
erzeugt. Die Trennung der Informationsextraktionssemantik von der Codegenerierung<br />
erleichtert die Erweiterung, Wartung und Anpassung der Wrapperprogramme. Zur<br />
Generierung benutzt des System eine Komponentenbibliothek mit Grundbausteinen für<br />
Wrapperprogramme<br />
10
Testen und Verpacken (Testing and Packaging)<br />
Zum Testen des generierten Programms kann der Benutzer eine Reihe von alternativen URLs<br />
der zu wrappenden Quelle eingeben. Für jede URL führt das Testmodul die syntaktische<br />
Strukturnormalisierung und Informationsextraktion durch, um zu prüfen, ob neue<br />
Extraktionsregeln oder Updates für bestehende abgeleitet werden können. Ggf. wird der<br />
Wrappercode neu generiert.<br />
4. Mediatoren<br />
Es wurde bereits erwähnt, dass Mediatoren einen Teil der Middleware darstellen und sich im<br />
Gegensatz zu Wrappern, die auf eine Datenquelle spezialisiert sind, auf den Aspekt des<br />
zentralen und effizienten Zugriffs auf mehrere heterogene Quellen konzentrieren.<br />
4.1 Definition / Aufgaben<br />
Definition:<br />
Der Begriff des Mediators wurde von [Wiederhold 1992] als Architekturkomponente in<br />
zukünftigen Informationssystemen eingeführt. In der ursprünglichen Definition wurde ein<br />
Mediator als komplexe Softwarekomponente beschrieben, die Daten „vereinfacht, abstrahiert,<br />
reduziert, mischt und erklärt“ [Wiederhold 1992]. In der Folgezeit hat sich jedoch eine engere<br />
Interpretation des Begriffes herausgebildet, derzufolge ein Mediator „Daten aus einer oder<br />
mehreren Quellen mit Hilfe einer deklarativen Spezifikation integriert und transformiert“<br />
[Abiteboul, Buneman, Suci 2000]<br />
Aufgaben<br />
- Auswahl geeigneter Quellen für eine eingehende Query<br />
- Erstellen eines Query-Planes, in dem festgelegt wird, welche Quellen in welcher<br />
Reihenfolge abgefragt werden.<br />
- Ggf. Anpassen der Query an die Abfragemöglichkeiten der einzelnen Quellen<br />
(query rewriting)<br />
- Durchführen des Query-Planes<br />
- Kombination und Integration der Teilergebnisse<br />
11
4.2 Architektur und funktionale Aspekte<br />
Abbildung 7: Architektur eines Mediators<br />
Verhältnis Wrapper - Mediator<br />
Wie bereits im Zusammenhang mit den Einsatzmöglichkeiten von Wrappern dargestellt,<br />
treten Mediatoren in Informationsintegrationssystemen häufig in Kombination mit Wrappern<br />
auf, wobei sich die Wrapper an der Schnittstelle zwischen Mediator und Datenquelle<br />
befinden, wie u. a. an der vorstehenden Abbildung ersichtlich.<br />
Grundsätzlich ist davon auszugehen, dass die Wrapper hierbei eine einheitliche Schnittstelle<br />
zu Verfügung stellen, während der Mediator die Anfragen auf die Quellen aufteilt und Daten<br />
aus den verschiedenen Quellen integriert. Es sind jedoch Variationen in der Aufteilung<br />
möglich, wobei die Extreme durch die beiden folgenden Fälle dargestellt werden:<br />
Fat Wrapper:<br />
Diese Wrapper erhalten den Teil der Anfrage der für die jeweilige Datenquelle relevant ist,<br />
ausgedrückt in der globalen Anfragesprache. Neben der Übersetzung der globalen<br />
Anfragesprache in die Schnittstellensprache der Datenquelle ist auch die gesamte strukturelle<br />
und semantische Anpassung durch den Fat Wrapper zu implementieren. Dies hat zur Folge,<br />
dass der Mediator schlank und performant bleiben kann, da er nur die passende Datenquelle<br />
finden, die Anfrage in einzelne Unteranfragen aufteilen und ggf. die Ergebnisse<br />
zusammenfassen muss. Andererseits ist die Erweiterung des Systems um eine neue<br />
Datenquelle aufwendig, da viel Funktionalität in dem für diese Quelle neu zu konstruierenden<br />
Wrapper implementiert werden muss.<br />
Thin Wrapper:<br />
Im Gegensatz zu den Fat Wrappern werden bei den Thin Wrappern so viele Aufgaben wie<br />
möglich vom Mediator übernommen. Dies setzt jedoch voraus, dass der Mediator eine Reihe<br />
12
von Modellen, Schemata und Verfahren der Datenquellen kennt. Die Performanz des<br />
Mediators ist dadurch offensichtlich schlechter als bei Fat Wrappern, da er größere Teile der<br />
Anfrageverarbeitung übernimmt. Dafür ist es einfach, neue Datenquellen hinzuzufügen,<br />
wodurch eine gute Erweiterbarkeit des Systems gewährleistet wird.<br />
Schnittstelle Anwendung – Mediator<br />
Anfragesprache:<br />
Benutzer greifen selten direkt, sondern über eine entsprechende Anwendung auf den Mediator<br />
zu. Ferner ist die Funktionalität, die der Mediator den zugreifenden Anwendungen zur<br />
Verfügung stellt, sehr vielfältig. Daher kommt für diese Schnittstelle vor allem eine<br />
Anfragesprache in Betracht, die die vielfältigen Funktionen des Mediators abdeckt und<br />
garantiert, dass Anwendungen diese in einfacher Weise nutzen und deren Ergebnisse<br />
einheitlich auswerten können. Eine solche Sprache könnte ähnlich den Sprachen sein, die<br />
relationale oder objektorientierte Datenbanken bereitstellen, also z. B. SQL.<br />
Es sind allerdings folgende zusätzlich Anforderungen zu berücksichtigen:<br />
- Unterstützung verschiedener Anfragetypen:<br />
Sowohl die vorhandenen Informationsbedürfnisse als auch die Web-Datenquellen<br />
sind äußerst verschieden. Neben exakten Anfragen, wie sie von Datenbanksystemen<br />
bekannt sind, sollten daher auch vage Anfragen möglich sein. Dies spielt<br />
insbesondere auch in den Fällen eine Rolle, in denen die Struktur der Datenquellen<br />
dem Anfragenden nicht bekannt ist oder semi- bzw. unstrukturierte Datenquellen<br />
vorliegen.<br />
- Schemaabhängigkeit<br />
Da der Benutzer nicht gezwungen sein soll, das spezifischen Schema jeder<br />
einzelnen Quelle zu kennen und zu berücksichtigen, wird i. d. R. ein globales<br />
Schema (world view) definiert, welches eine integrierte Sicht über alle Quellen<br />
bietet (siehe auch Metadaten-Repository). Die Anfragesprache sollte die Anfrage in<br />
Abhängigkeit von diesem globalen Schema ermöglichen.<br />
- Zugriff auf Metadaten:<br />
Um die Schemaabhängigkeit überhaupt gewährleisten zu können, muss die<br />
Anfragesprache einen Zugriff auf die Metadaten des Systems ermöglichen.<br />
Ergebnispräsentation:<br />
Im Falle vager Anfragen besteht das Ergebnis nicht wie in einem Datenbanksystem aus allen<br />
Datensätzen, die der Anfrage entsprechen. Es handelt sich vielmehr - wie bei Information-<br />
Retrieval-Systemen - um alle Ergebnisse, die dem Mediator relevant erscheinen. Der<br />
Mediator muss neben der Ausgabe exakter Ergebnisse auch über entsprechende<br />
Ausgabetechniken wie „Ranked List“ und Berücksichtigung von „Relevance Feedback“<br />
verfügen.<br />
Metadaten – Repository<br />
Um beurteilen zu können, welche Quellen für die Beantwortung einer Anfrage geeignet sind,<br />
wie die Anfrage ggf. aufzuteilen und durchzuführen und wie die Teilergebnisse zu integrieren<br />
sind, benötigt der Mediator Schemata und Metainformationen über die verfügbaren Quellen.<br />
13
Die Metainformationen werden wie erwähnt i. d. R. in einer globalen Sicht vereint, welche<br />
zugleich als Schema dient, gegen das der Benutzer seine Anfragen stellt. Zur Speicherung<br />
dieser Informationen dient das Metadaten-Repository des Mediators. Bei der Verwendung<br />
von Fat Wrappern würde ein Teil der Metainformationen aus dem Repository in die Wrapper<br />
verlagert.<br />
Kombination von Mediatoren<br />
Neben einer Architektur mit einem zentralen Mediator sind auch Systeme denkbar, in denen<br />
eine Vielzahl von Mediatoren eingesetzt ist, die jeweils auf eine bestimmte Domäne oder<br />
einen Aufgabenbereich spezialisiert sind. Dabei greifen Mediatoren ebenso wie<br />
Anwendungen auf andere Mediatoren zurück. Eine solche Architektur erhöht die Flexibilität<br />
und Erweiterbarkeit, stellt jedoch auch erheblich höhere Anforderungen an die Koordination<br />
und die Kommunikation zwischen den Komponenten.<br />
4.3 Anfrageverarbeitung<br />
Die Anfrageverarbeitung kann im wesentlichen in drei Schritte eingeteilt werden:<br />
1. Auswahl der Quellen<br />
Der erste Schritt bei der Verarbeitung einer Anfrage besteht darin festzustellen, welche<br />
der vorhandenen Datenquellen Informationen zu einem Gesamtergebnis beitragen<br />
könnten. Dies wird vor allem durch die in den Quellen vorhandenen Attribute und<br />
eventuelle Beschränkungen des Wertebereichs bestimmt. Bei der Auswahl können<br />
jedoch auch Verfügbarkeit und Performanz der Quellen eine Rolle spielen.<br />
2. Anfrageaufteilung und -optimierung<br />
Aufbauend auf den ausgewählten Quellen werden nun Query-Pläne erstellt, in denen<br />
festgelegt wird, welche Teilabfragen auf welchen Quellen ausgeführt werden und in<br />
welcher Reihenfolge diese Teilabfragen erfolgen müssen.<br />
Bei der Aufteilung ist zusätzlich zur Frage, ob eine Quelle allgemein einen Beitrag<br />
leisten kann, auch die Semantik zu berücksichtigen. D. h. es ist zu analysieren, in<br />
welchem Verhältnis die Attribute einer Quelle zu denen der Anfrage und/oder anderer<br />
Quellen stehen. Derartige semantische Unterschiede werden i. d. R. im Vorfeld mit<br />
Hilfe von semantische Abbildungen zwischen den Inhalten der Datenquellen und der<br />
integrierten Gesamtsicht modelliert. In dieser Phase können potentielle Quellen auch<br />
wieder entfallen, da das von ihnen gelieferte Teilergebnis nicht sinnvoll mit<br />
Teilergebnissen aus anderen Quellen zu einem Gesamtergebnis kombiniert werden<br />
kann. Die einzelnen Pläne werden nun nach Performanzkriterien optimiert. Falls<br />
festgestellt werden kann, dass mehrer Pläne ein identisches Ergebnis liefern, wird<br />
unter diesen außerdem der kostengünstigste ausgewählt.<br />
3. Anfrageausführung und Ergebnisintegration<br />
In diesem Schritt werden die Pläne ausgeführt, indem die jeweils relevanten Daten aus<br />
den Quellen ausgelesen und verarbeitet werden. Ähnlich wie bei Datenbanksystemen<br />
müssen diese korreliert und selektiert werden, sowie Abstraktionen und Aggregationen<br />
durchgeführt werden.<br />
Hier spielt erneut das Problem der semantischen Heterogenitäten eine entscheidende<br />
Rolle. Die bei der Anfragebearbeitung erkannten Konflikte müssen mit Hilfe<br />
entsprechender Integrationsregeln für die Transformation und Verarbeitung der<br />
14
Ergebnisse beseitigt werden. Finden sich in den Datenquellen neben semantischen<br />
auch strukturelle Unterschiede (z. B. einerseits Speicherung einer Information als<br />
Attribut, andererseits als eigene Relation) dann müssen ggf. auch<br />
Schematransformationen durchgeführt werden.<br />
Beispiel für die Erstellung eines Query Plans:<br />
Gegeben seien folgende Informationsquellen auf dem Web in der Domäne Fahrzeugkauf:<br />
Quelle Input Output<br />
1: Gebrauchtwagen Kategorie oder Modell Modell, Jahr, Preis,<br />
optional: Preisbereich,Baujahr Kontaktinformationen<br />
2: Luxuswagen ab 20000 $ Kategorie<br />
Modell, Jahr, Preis,<br />
optional: Preisbereich Kontaktinformationen<br />
3: Oldtimer (älter als 1950) Modell<br />
Modell, Jahr, Preis,<br />
optional: Baujahr<br />
Kontaktinformationen<br />
4: Motorräder Modell<br />
Modell, Jahr, Preis,<br />
optional: Preisbereich Kontaktinformationen<br />
5: Modellbeschreibungen Modell und Jahr Beschreibung<br />
An das System wird folgende Anfrage gestellt:<br />
Gesucht sind Preis und Beschreibungen für zu verkaufende Sportwagen, die nach 1992 gebaut<br />
wurden.<br />
Auswahl der Quellen:<br />
- Quelle 4 ist offensichtlich nicht relevant, da sie keine Autos enthält.<br />
- Quelle 3 ist aufgrund ihres Wertebereichs nicht interessant, da sie nur vor 1950<br />
gebaute Fahrzeuge enthält.<br />
- In Frage kommen offensichtlich Quellen 1, 2 und 5.<br />
Damit können folgende Query Pläne erstellt werden:<br />
Plan 1:<br />
- Befrage Quelle 1 nach Modell, Jahr und Preis für alle Sportwagen, die nach 1992<br />
produziert wurden.<br />
- Erhalte eine Beschreibung von Quelle 5 für jedes Modell<br />
- Produziere eine Menge von -Tupeln.<br />
Plan 2:<br />
- Frage Quelle 2 nach den Modellen, Baujahren und Preisen für Sportwagen.<br />
- Wähle aus den -Tupeln, die sich ergeben, diejenigen aus, bei<br />
denen das Jahr >= 1992.<br />
- Erhalte eine Beschreibung von Quelle 5 für jedes Modell der ausgewählten Tupel<br />
- Produziere eine Menge von -Tupeln<br />
Die Antwort auf die Anfrage ist die Vereinigung der beiden Tupelmengen.<br />
4.4 Erstellung eines globalen Schemas<br />
Da der Benutzer seine Anfragen in der Regel in der Form des globalen Schemas stellt, die<br />
Daten zur Beantwortung jedoch in externen Quellen gespeichert sind, hängt die Qualität eines<br />
Mediationssystems entscheidend von Beschreibungen ab, die die Inhalte einer Quelle mit den<br />
15
Klassen, Attributen und Relationen des globalen Schemas in Beziehung setzen. Für eine<br />
effiziente Abwicklung der Anfrageverarbeitung kommt es insbesondere auch darauf an, die<br />
semantischen Unterschiede zwischen den Quellen zu erkennen und entsprechend zu<br />
modellieren.<br />
Hierzu werden Abbildungsvorschriften zwischen den Datenschemata der Quellen und dem<br />
globalen Schema verwendet, wobei u. a. folgende Fälle unterschieden werden können:<br />
(Als Beispiel dient ein Informationsintegrationssystem für Online-Angebote von Immobilien)<br />
- Ein Schemaelement (bestehend aus Attribut und zugehörigem Wert) eines<br />
Quellschemas kann 1:1 auf ein Schemaelement des globalen Schemas abgebildet<br />
werden.<br />
Beispiel: Abbildung von Listenpreis (Quellschema) auf Preis (globales Schema)<br />
- Ein Element des einen Schemas entspricht mehreren Elementen des anderen.<br />
Beispiel: Anzahl Badezimmer (globales Schema) entspricht der Summe der Anzahl<br />
der Elemente „vollständige Badezimmer“ und „halbe Badezimmer“ (Quellschema).<br />
- Element eines Schemas entspricht dem Wert eines Elementes in dem anderen<br />
Beispiel: Element „behindertengerecht“ mit Wert ja/nein (Quellschema) entspricht<br />
dem Wert („behindertengerechte Ausstattung“) des Elementes „Extras“ (globales<br />
Schema).<br />
Derartige semantische Mappings, die für jede Quelle vorgenommen werden müssen, stellen<br />
ein erhebliches Hindernis für die Datenintegration dar, da die manuelle Erstellung der<br />
Abbildungsvorschriften arbeitsaufwendig und fehlerhaft ist. Es gibt daher Ansätze, die<br />
Mappings mit Methoden des maschinellen Lernens (halb)automatisch zu ermitteln. [Doan,<br />
Domingos, Levy 2000] schlagen dazu ein System vor, welches anhand von manuellen<br />
Beispielmappings für einige Quellen lernt und mit Hilfe des gelernten Wissens Mappings für<br />
weitere Quellen vorschlägt.<br />
Dabei werden folgende Möglichkeiten des Lernens eingesetzt:<br />
(Beispiel ist nochmals das Informationsintegrationssystem für Online-Angebote von<br />
Immobilien)<br />
- Ähnlichkeit von Attributnamen, berechnet mit TF/IDF-Ähnlichkeitsmaß<br />
Beispiel: Vergleich der Elemente „Kontakttelefon“ (Quellschema) und<br />
„Maklertelefon“ (globales Schema) indiziert Matching<br />
- Eigenschaften der Daten (Zuordnung mit Hilfe eines naiven Bayes Klassifikators)<br />
Beispiele:<br />
- Kleine numerische Werte weisen eher auf das Attribut Zimmerzahl als das<br />
Attribut Preis hin.<br />
- Bei Telefonnummern mit ähnlichen Zifferfolgen handelt es sich eher um<br />
Bürotelefone.<br />
- Abstand der Elemente:<br />
Beispiel:<br />
- Langes Textfeld am Anfang eines Hauseintrages weist auf eine Beschreibung<br />
der Immobilie hin.<br />
- Maklertelefon steht meist in der Nähe der Adresse des Maklerbüros.<br />
16
4.5 Information Manifold – Beispiel für den Einsatz von Mediator-Technik<br />
Information Manifold ist ein implementiertes Informationsintegrationssystem der Stanford<br />
University [Levy, Rajaraman, Ordille 1996], welches einheitlichen Zugang zu einer<br />
Sammlung von mehr als 100 Quellen bietet, von denen sich ein großer Teil auf dem WWW<br />
befindet. Der wissenschaftliche Schwerpunkt des Systems liegt auf der Mediator-Komponente<br />
und dabei insbesondere auf effizienten Methoden zur Auswahl von Quellen und Erstellung<br />
von Query Plänen.<br />
Integrierte Sicht / Auswahl von Quellen<br />
Information Manifold benutzt das bei Mediatoren übliche Instrument eines globalen Schemas,<br />
um eine integrierte Sicht zu bieten, gegen die der Benutzer Anfragen stellen kann. In der<br />
Regel werden derartige integrierte Sichten als Query über den Quellen gesehen (global as<br />
view). Dies entspricht auch der natürlichen Konstruktion einer Sicht, indem von den<br />
Originaldaten ausgegangen wird. Dieser Ansatz hat jedoch den Nachteil, dass er sehr<br />
laufzeitintensiv sein kann. Bei n Quellen müssen ggf. n² Interaktionen zwischen den Quellen<br />
ausgeführt werden, um eine Sicht zu konstruieren.<br />
Bei Information Manifold wird ein entgegengesetzter Ansatz verfolgt: Die Quellen werden als<br />
Sichten auf den integrierten Daten beschrieben (local as view). Dies hat den Vorteil, dass bei<br />
n Quellen nur n Sichten benötigt werden. Ferner können die oft feingranularen Unterschiede<br />
zwischen den Quellen besser modelliert werden, da in der Definition einer Sicht, die eine<br />
Quelle beschreibt, die Bedingungen exakt angegeben werden können, die alle Tupel der<br />
fraglichen Relation charakterisieren. Ausgehend von diesen exakten Beschreibung ist eine<br />
effiziente Auswahl der Quellen möglich, die für die Beantwortung einer Anfrage relevant<br />
sind.<br />
Im umgekehrten Falle, in dem das globale Schema als Query über den Quellen angesehen<br />
wird, können dagegen nur beschränkt Detailbeschreibungen der Quellen einfließen, wenn das<br />
globale Schema überschaubar gehalten werden soll. Ein weiterer Vorteil des vorliegenden<br />
Ansatzes ist, dass Quellen bequem hinzugefügt werden können, ohne dass die<br />
Beschreibungen der bisherigen Quellen geändert bzw. eine fest vordefinierte Gesamtsicht<br />
angepasst werden müsste. Nachteil hingegen ist, dass das globale Schema selbst eine<br />
minimale Instanz darstellt, die konsistent mit allen Definitionen ist. Die eigentliche<br />
Mächtigkeit der Mediator-Datenbank ist in den auf bekannten Zuständen der Quellen<br />
basierenden Sichtendefinitionen spezifiziert. Eine solche Spezifikation ist jedoch<br />
zwangsläufig unvollständig.<br />
Erstellung von Query-Plänen<br />
Zur Erstellung von Query-Plänen werden die Fähigkeiten der Quellen mit Hilfe von<br />
sogenannten Capability Records beschrieben. Diese spezifizieren für jede Quelle den<br />
möglichen Input, den möglichen Output und die Fähigkeit Selektionen vorzunehmen.<br />
Dadurch kann die Erstellung von Query-Plänen in zwei Phasen erfolgen: Zunächst werden<br />
alle semantisch korrekten Pläne ermittelt, d. h. alle Pläne, die die als Sichten beschriebenen<br />
Quellen benutzen und eine Antwort auf die Anfrage liefern. Anschließend werden die<br />
Teilpläne unter Berücksichtigung der Antwortfähigkeiten der Quellen so angeordnet, dass sie<br />
auch tatsächlich ausführbar sind.<br />
17
5. Informationsintegrationssysteme auf dem Web<br />
Die vorstehend beschriebenen Konzepte Wrapper und Mediator bilden die zentralen<br />
Bestandteile typischer Informationsintegrationssysteme auf dem Web und bestimmen<br />
wesentlich den Entwicklungsaufwand, die Leistungsfähigkeit und die Skalierbarkeit eines<br />
solchen Systems. Weitere Aspekte der Unterhaltung eines Informationsintegrationssystems<br />
auf dem Web wurden durch [Cohen 1999] untersucht.<br />
Zu diesem Zweck hat der Autor über mehrere Monate hinweg zwei webbasierte Informationsintegrationssysteme<br />
unterhalten, die gemeinsam datenbankähnliche Abfragen zu den<br />
Informationen auf mehr als 50 Websites (mehrere 1000 Einzelseiten) unterstützten.<br />
5.1 Entwicklung<br />
Bei der Entwicklung wurde in folgenden Schritten vorgegangen:<br />
1. Ermitteln relevanter Informationsquellen für eine Domäne<br />
2. Aufbau eines globalen Schemas<br />
3. Modellierung und Wrapping der einzelnen Websites<br />
4. Aufbau einer Abfrageschnittstelle <strong>zum</strong> globalen Schema<br />
5. Unterhaltungsphase: Wartung v. a. der einzelnen Wrapper und bei Bedarf Hinzufügen<br />
neuer Informationsquellen<br />
Vor der Erstellung der Gesamtsysteme wurden zunächst in entsprechender Weise<br />
anfänglicher Prototypen mit 5-10 der relevantesten Websites einer Domäne entwickelt und<br />
die Realisierbarkeit bezogen auf die gewählte Domäne evaluiert<br />
5.2 Praktische Aspekte<br />
Bei Entwicklung und Unterhaltung der Systeme wurden im wesentlichen folgende<br />
Beobachtungen gemacht:<br />
Grundsätzliche Realisierbarkeit<br />
Ein Informationsintegrationssystem in dieser Größenordnung ist grundsätzlich realisierbar.<br />
Besondere Hürden stellen jedoch v. a. die nachstehenden Aspekte dar:<br />
- Die Kosten für die Ermittlung von Informationsquellen steigen überproportional mit<br />
der Größe des Integrationssystems. D. h. einige wichtige Quellen eines Gebietes<br />
sind schnell gefunden. Die Ermittlung weiterer Quellen mit dem Ziel einer guten<br />
Abdeckung der Domäne ist jedoch zunehmend schwierig.<br />
- Auch die Komplexität beim Aufbau eines globalen Schemas nimmt mit der Zahl der<br />
berücksichtigten Quellen stark zu. Es sind zunehmend Abwägungen zu treffen, ob<br />
feine semantische Unterschiede zwischen Quellen modelliert werden sollen oder<br />
nicht. Im ersten Fall wird die Informationsextraktion zunehmend komplex, während<br />
im zweiten eventuell interessante Abfragen nicht ausgedrückt werden können.<br />
- Die Entwicklung eines Systems setzt noch viel Expertenwissen auf dem Gebiet der<br />
Informationsintegration voraus. Damit dies auch Nichtexperten möglich ist, wären<br />
zunächst bessere Tools erforderlich.<br />
18
Unterhaltung<br />
Für die Unterhaltung der Systeme wird mehr Zeit und Energie benötigt als für die anfängliche<br />
Entwicklung. Die Forschungsaktivitäten sollten daher auf Tools erweitert werden, die nicht<br />
nur die (halb)automatische Entwicklung, sondern auch eine entsprechende Unterhaltung<br />
unterstützen.<br />
Skalierbarkeit<br />
Generell gibt es einen Tradeoff zwischen der Anzahl der integrierten Quellen und der Tiefe<br />
des über eine Quelle vorhandenen Metawissens. D. h. der Aufbau von<br />
Informationsintegrationssystemen, die mehrere hundert oder tausend Websites abdecken<br />
sollen, wird extrem schwierig, da allein der Aufwand für die Erstellung und Unterhaltung des<br />
globalen Schemas und die Pflege des Zugriffswissens enorm aufwendig wäre. Eine mögliche<br />
Lösung für dieses Problem der Skalierbarkeit wäre der Aufbau einer Konföderation kleinerer<br />
spezialisierter Informationsintegrationssysteme. Hierbei wären allerdings neue Probleme wie<br />
die der gemeinsamen Anfragesprache und der Verteilung der Anfragen zu lösen.<br />
6. Literaturverzeichnis<br />
[Abiteboul, Buneman, Suci 2000] Abiteboul, Serge; Buneman, Peter, Suci, Dan: Data on the<br />
Web: From Relations to Semistructured Data and XML. San Francisco (Morgan Kaufmann<br />
Publishers) 2000<br />
[Cohen 1997] Cohen, William: Some practical observations on integration of Web<br />
information. Proc. WebDB99.<br />
Online verfügbar unter:<br />
http://www.rocq.inria.fr/~cluet/WEBDB/procwebdb99.html<br />
[Doan, Domingos, Levy 2000] Doan, AnHai; Domingos, Pedro; Levy, Alon: Learning<br />
Source Descriptions for Data Integration. Proceedings of the 3 rd International Workshop “The<br />
Web and Databases (WebDB), 2000<br />
Online verfügbar unter:<br />
http://www.research.att.com/conf/webdb2000/program.html<br />
[Foreman et al 1997] Foreman, John; Brune, Kimberly; McMillan, Patricia; Rosenstein,<br />
Robert: Software Technology Reference Guide – A Prototype. Pittsburgh (Software<br />
Engineering Institute, Carnegie Mellon University, 1997<br />
[Garcia-Molina et al 1997] Garcia-Molina, Hector; Papakonstantinou, Yannis; Quass,<br />
Dallan; Rajaraman, Anand; Sagiv, Yehoshua; Ullman, Jeffrey; Vassalos, Vasilis; Widom,<br />
Jennifer: The TSIMMIS Approach to Mediation: Data Models and Languages. Journal of<br />
Intelligent Systems, Volume 8, Number 2, S. 117-132, März/April 1997.<br />
[Levy, Rajaraman, Ordille 1996] Levy, Alon; Rajaraman, Anand; Ordille, Joann: Querying<br />
Heterogeneous Information Sources Using Source Descriptions. Bombay (Proceedings of<br />
22th Conference on Very Large Databases, S. 251-262) 1996.<br />
19
[Liu, Pu, Han 2000] Liu, Ling; Pu, Calton; Han, Wei: XWRAP: An XML-enabled Wrapper<br />
Construction System for Web Information Sources. ICDE 611-621, 2000.<br />
Auch online verfügbar unter:<br />
http://www.cc.gatech.edu/projects/dil/XWRAP/<br />
[Sahuguet, Azavant 1999] Sahuguet, Arnaud; Azavant, Fabien: WysiWyg Web Wrapper<br />
Factory (W4F). Proceedings of WWW Conference 1999.<br />
Sie auch online-Informationen unter:<br />
http://db.cis.upenn.edu/W4F<br />
[Wiederhold 1992] Wiederhold, Gio: Mediators in the Architecture of Future Information<br />
Systems. IEEE Computer Magazin, 25(3):38-49, März 1992.<br />
Auch online verfügbar unter:<br />
http://www-db.stanford.edu/pub/gio/gio-papers.html<br />
[Wells 1996] Wells, David: Wrappers. Survey, Object Services and Consulting, Inc., 1996.<br />
Online verfügbar unter:<br />
http://www.objs.com/survey/wrap.htm<br />
20