Multimedia Retrieval. Kapitel 4: XML Retrieval. Dr. Roger Weber, Informatik / CS342 / WS06/07

Transkript

1 Informatik / CS342 / WS06/07 Multimedia Retrieval Kapitel 4: XML Retrieval 4.1 XML Daten- und Dokumentensicht 4.2 Struktur was nun? 4.3 Anfrage abhängige Statistiken Dr. Roger Weber, weber@inf.ethz.ch

2 4.1 XML Daten- und Dokumentensicht Vorschlag des World Wide Web Consortiums (W3C) Seit Februar 1998 W3C Recommendation XML definiert den syntaktischen Aufbau der Dokumente die Elemente, Attribute, Entities den Zeichensatz und die Semantik des Dokumentes mit der Dokumententypdefinition (DTD) Zielsetzung von XML: Format für Austausch, Verarbeitung und Darstellung von Information im Web Anwendungen: Datenhaltung (ähnlich zu Relationen in Datenbanken) Markup für Dokumente Aus Neil Bradley: The XML companion XML HTML SGML Generalized Markup WWW Internet

3 Daten zentrierte Sicht von XML Eine DTD beschreibt die Struktur von XML Dokumenten. In der Daten zentrischen Sicht entspricht die DTD ungefähr einer Schemadefinition in NF 2 (Relationen in nonfirst-normal-form, d.h. Tupelelemente können neben den Basistypen auch Tabellen sein). In dieser Sichtweise entsprechen XML Dokumente (oder Teilbäume) den Datensätzen (Tupeln) einer Datenbank. Ähnlich wie SQL ermöglichen verschiedene XML Anfragesprachen die Selektion, Verbindung (join) und Projektion von XML Teilbäumen. Dabei stehen vor allem exakte Anfragen im Vordergrund, z.b. alle Bücher des Schriftstellers Peter Bichsel. Diese Art von Anfragen unterstützen mittlerweile auch fast alle kommerziellen Datenbanken und einige neue auf XML spezialisierte Produkte (nebst einer grossen Anzahl von Forschungsgruppen im In- und Ausland).

4 Bsp: Datensätze einer Buchhandlung bookstore book book title author price title author price The Autobiography of Benjamin Franklin firstname lastname 8.99 The Gorgias name 9.99 Benjamin Franklin Plato Flexibilität von XML

5 Anfragesprachen für Daten orientierte Sicht: XPath: W3C Standard seit 1999 (Version 1.0). XPath definiert Muster, Funktionen und Ausdrücke, um Elemente, Elementgruppen bzw. Attribute genauer zu identifizieren und zu extrahieren. Grundlegendes Konstrukt sind XPath-Ausdrücke, welche zu Werten von den Typen boolean, number, string oder node-set (ungeordnete Kollektion von Knoten ohne Duplikate) ausgewertet werden. Bsp: gib das Attribut 'Genre' aller Bücher aus: gib alle Bücher aus, die vom Autor 'Plato' stammen: /bookstore/book[author/name='plato'] gib den Nachnamen aller Autoren aus, deren Vorname 'Herman' ist: //author[first-name='herman']/last-name liefere den Preis für alle Bücher, die mind. einen Autor mit dem Vornamen 'Benjamin' haben: /bookstore/book[author/first-name='benjamin']/price

6 XQuery: Aktueller W3C-Vorschlag für eine Norm-XML-Anfragesprache. XQuery basiert auf XPath, hat Ähnlichkeit zu SQL/OQL, ist eine funktionale Sprache, ist streng typisiert basierend auf XML-Schema, erlaubt zusammengesetzte Ausdrücke und unterstützt die orthogonale Anwendung unterschiedlicher Ausdruckstypen. Das Basiskonstrukt ist der sogenannte FLWR-Ausdruck (steht für FOR-LET-WHERE-RETURN). LET $bib0 := <bib> <book year="1999" isbn="1-x"> <title>data on the Web</title> <author>abiteboul</author> <author>buneman</author> <author>suciu</author> </book> <book year="2001" isbn="1-z"> <title>xml Query</title> <author>fernandez</author> <author>suciu</author> </book>, </bib> : Bib RETURN $bib0 Typ FOR $b IN $bib0/book WHERE $b/@year/data() <= 2000 RETURN $b liefert <book year="1999" isbn="1-x"> <title>data on the Web</title> <author>abiteboul</author> <author>buneman</author> <author>suciu</author> </book> : Book*

7 Für unsere Vorlesung wäre einzig die vage Suche auf solchen Dokumenten interessant. Z.B. könnte man sich eine XML Datenbank mit PC Angeboten vorstellen, welche neben dem Preis auch verschiedene technische Daten zu den Computern enthält (z.b. Hauptspeicher, Grafikkarte, etc.). Dabei müsste die Suchmaschine die Angebote so ordnen, dass sich das Angebot, welches am besten zu meinen Zielvorstellungen passt zuoberst in der Liste befindet (z.b. möchte PC mit 3D Grafik, 256 MB Hauptspeicher, >40GB Harddisk für unter Fr.). Die Zielvorstellungen müssen allerdings nicht genau getroffen werden und es soll das beste System eruiert werden (z.b. 3D Grafik, 512MB, 80GB, Fr). Diese Art der Suche ist allerdings eng verwandt mit der nächsten Nachbar Suche des nächsten Kapitels. Ziel PC1 PC2 PC3 3D 3D 3D 3D 256MB 512MB 256MB 512MB 40GB 80GB 30GB 120GB

8 Dokumenten zentrierte Sicht In der Regel ist hier die DTD nicht immer nötig, häufig aber zur Definition der Semantik erwünscht. Im Unterschied zur Daten zentrierten Sicht enthalten solche Dokumente ganze Textdokumente oder Textfragmente in ihren Knoten. Manchmal werden Tags sogar nur als Markup verwendet, ähnlich wie bei HTML. Als weiterer Unterschied zur Daten zentrierten Sicht möchten Benutzer nun keine exakten Anfragen stellen, sondern gezielt nach dem Inhalt fragen. Z.B. welche Bücher zum Thema XML Retrieval gibt es in der Bibliothek. Dabei stellt sich das Problem, dass die Standards diese Art der Anfragen nur rudimentär unterstützen (z.b. contains-operator). Für geordnetes Retrieval fehlt jede Unterstützung. Aber: Beim Web-Retrieval (HTML <-> XML) haben wir einfach die Struktur eliminiert und dann über die Termmengen gesucht. Das könnte man ja hier auch machen! Allerdings (1): schon in HTML hat man spezielle Tags ausgenutzt, um Terme stärker zu gewichten. Das müsste man bei XML unbedingt auch tun. Bei einem Bibliotheksdatensatz, z.b., wäre ein Termvorkommen im Titel wichtiger als in der Zusammenfassung des Buches. Das müsste man berücksichtigen können. Allerdings (2): die Granularität ist bei XML Dokumenten häufig nicht auf der Dokumentenebene sondern auf der Elementenebene. Z.B. können mehrere Bucheinträge im selben XML Dokument erfasst sein. Der Suchende möchte aber nicht das ganze XML Dokument, sondern nur den relevanten Teilbaum.

9 Bsp: Bücher einer Bibliothek als XML Teilbäume bookstore medicine computer-science book book book book book book book title chapter chapter chapter chapter author author title section section title title

10 4.2 Struktur was nun? Bevor wir Retrieval auf XML Dokumenten anwenden können müssen wir zwei zentrale Probleme im Zusammenhang mit der Struktur von XML lösen: Definition der Kollektion resp. die Granularität der Antworten Charakterisierung innerer Knoten, welche nicht direkt Content enthalten

11 Definition der Kollektion: Im klassischen Textretrieval bestand eine Kollektion aus einer Menge von Dokumenten, welche mit einer Termmenge charakterisiert werden konnte. In XML Dokumenten möchte man allerdings häufig eine andere Granularität für die Antworten. Betrachte das Dokument auf der vorletzten Seite: Bei Fragen nach Büchern zu XML Retrieval will man nicht das ganze XML Dokument erhalten sondern nur die relevanten Teilbäume, d.h. Elemente mit dem Label book. Interessieren mich Bücher oder Kapitel in Büchern zum Thema XML Retrieval, so ist meine Granularität auf der Stufe book und der Stufe chapter, d.h. die Antworten können sich z.t. sogar überlappen. Bei XML Retrieval brauche ich natürlich nur Bücher im Teilbaum computerscience zu betrachten. Falls ich aber nach Medical Information Systems suche, bin ich an beiden Teilbäumen ( medicine, computer-science ) interessiert. Im folgenden definieren wir deshalb unsere Kollektion nicht über Dokumente sondern Elemente (Teilbäume in XML Dokumenten). Allerdings gibt es auch XML Datenbanken mit mehr als einem Dokument. Z.B. könnte die Bibliothek die Informatikbücher in einer ersten XML Datei verwalten und die Medizinbücher in einer zweiten Datei. Wie können wir jetzt z.b. das beste Buch zu Medical Information Systems finden? Hierzu verschmelzen wir ganz einfach die Dokumente zu einem virtuellen Universaldokument. Dabei können wir die verschiedenen XML Dokumente wiederum in einer virtuellen Hierarchie anordnen (s. nächste Seite).

12 Beispiel: Bibliotheksdaten bookstore medicine computer-science book book book book book XML Dokumente aus dem Ordner /data/medicine XML Dokumente aus dem Ordner /data/computerscience

13 Elemente: Ein Element entspricht einem Knoten/Teilbaum im XML Dokument. Im folgenden seien Elemente durch eine Dokument weit eindeutige ID gekennzeichnet. Jedes Element hat zudem einen deterministischen XPath-Ausdruck und einen nichtdeterministischen (in Bezug auf das Wiederfinden des Knotens) Pfad von der Wurzel des Dokumentes zur Wurzel des Teilbaumes des Elements. Dieser Pfad entsteht durch die Konkatenation der Namen der Eltern Knoten und des eigenen Namens. Bsp: der XPath Ausdruck /bookstore/medicine/book[2] kennzeichnet genau einen Teilbaum im Dokument (welches hier einem Buch in der Bibliothek entspricht). Der Pfadausdruck /bookstore/medicine/book beschreibt den nicht-deterministischen Weg von der Wurzel zu diesem Elementknoten. Pfadtypen: Ein Pfadtyp ist durch einen Pfadausdruck innerhalb des XML Dokumentes definiert (hier: Pfad=Konkatenation der Elementnamen). Im folgenden gehen wir nicht unbedingt davon aus, dass es eine DTD zu den Dokumenten der Kollektion gibt (ihr Vorhandensein ist aber auch kein Problem). Die Definition Pfadtyp basiert nur auf dem Pfad von der Wurzel zu den Elementen. Wie deren Teilbäume aussehen und ob sie allenfalls so gar unterschiedlich sind für die Elemente des selben Pfadtyps wollen wir hier nicht weiter definieren oder erzwingen; es spielt für unsere Verwendung von XML keine Rolle (ganz im Gegensatz zu Daten zentrierten Anfragen). Jedes Element des XML Dokumentes gehört zu genau einem Pfadtyp Pfadtypen sind gerade die Granularität unseres Retrievalmodells

14 Beschreibung der Elemente: Im Textretrieval haben wir verschiedene Retrieval Modelle kennen gelernt. Bei allen Verfahren wurden Dokumente durch einen Vektor (binär oder tf-komponenten) dargestellt. Analog müssen wir nun Elemente durch Vektoren darstellen. Dabei gehen wir konzeptionell wie folgt vor: Bei Blattknoten und bei Mixed Content (d.h. Element enthält Text und Tags) zählen wir die Termvorkommen direkt dem Element zu. Bei inneren Knoten kombinieren wir die Vorkommen von Termen aus Sub- Elementen gemäss eines vorgegebenen Gewichts. Dieses Gewicht soll die Bedeutung des Termvorkommens für das Element beschreiben Ein Beispiel für unterschiedliche Gewichte ergibt sich aus dem vorherigen Beispiel der Bücherkollektion. Für Elemente des Pfadtyps /bookstore/medicine/book sind Terme in den title Sub-Elementen wichtiger als Vorkommen in den chapter/section Sub-Elementen. Also: Sei dtf(t,e) die Termhäufigkeit von t im Inhalt, der direkt dem Element e zugeordnet ist und sub(e) die Menge der direkten und indirekten Kind-Elemente von e. Dann ist die Termhäufigkeit tf(t,e) rekursiv gegeben als tf(t,e) = dtf(t,e) + Σ s sub(e) w(e,s) dtf(t,s) Wie setzen wir nun die Gewichte?

15 Gewichte: Bei HTML war das relativ leicht, da wir uns einmal für Gewichte entscheiden mussten und diese dann für jedes Dokument verwenden können. Bei XML gibt es keine solchen universalen Gewichte. Natürlich können wir uns für bekannte Kollektionen spezielle Gewichte vorstellen. Was aber, wenn die Gewichte davon abhängen, auf welcher Granularität man Anfragen stellt (d.h. welche Pfadtypen zurückgeliefert werden sollen). So ist z.b. die Kapitelüberschrift sehr wichtig falls jemanden nach Buchkapiteln anfragt. Sucht man allerdings nach Büchern, so sind die Kapitelüberschriften nicht mehr so wichtig wie der Titel des Buches. Mit anderen Worten: wir müssen für jedes Termvorkommen in Abhängigkeit zum Pfadtyp ein Gewicht definieren (w(e,s) auf der vorherigen Seite). Der Aufwand wäre allerdings enorm (es gibt sehr viele w(e,s)-gewichte). Augmentierung: anstelle einer expliziten Gewichtszuordnung w(e,s) bestimmt man die Gewichte implizit über die Hierarchie. Dazu gewichtet man jede Kante im Elementtypenbaum (DTD, Data Guide) und berechnet das Gewicht w(e,s) durch die Multiplikation der Gewichte entlang des Pfades von e nach s. Dadurch erspart man sich einiges an Aufwand. Konzeptionell bleibt allerdings die Idee, dass ein Termvorkommen innerhalb eines Teilbaumes abhängig vom Pfadtyp und des Ortes des Vorkommens gewichtet wird. Sei child(e) die Menge er direkten Kind- Elemente von e. Damit vereinfacht sich die Formel zu: tf(t,e) = dtf(t,e) + Σ s child(e) w(e,s) tf(t,s)

16 Bsp: Augmentierung im Beispiel der Bücherkollektion e: /bookstore/medicine s: /bookstore/medicine/book/chapter/section w(e,s) = 1.0 * 0.7 * 0.5 = 0.35 bookstore medicine computer-science book 1 w(e,s) = book title author chapter chapter author title title section section title dynamic structural summary (DataGuides)

17 Speicherung: Grundsätzlich genügt es, die dtf(t,e)-werte zu speichern, da die tf(t,e)- Werte daraus berechenbar sind. Allerdings wäre es für eine beschleunigte Auswertung der Anfragen wünschenswert, wenn die tf(t,e)-werte für alle Elemente e vorhanden wären. Als Optimierung kann man auch nur die tf(t,e)-werte materialisieren, deren Elemente überhaupt in Anfragen resp. Antworten auftauchen können (z.b. bookstore müsste man nicht materialisieren): bookstore medicine computer-science book e le m te rm tf book book book book book book e le m te rm tf e le m te rm tf e le m te rm tf e le m te rm tf e le m te rm tf e le m te rm tf title e le m te rm tf author chapter e le m te rm tf e le m te rm e le m te rm tf tf e le m te rm tf e le m te rm tf chapter e le m te rm tf e le m te rm tf author title e le m te rm tf title section section title e le m te rm tf e le m te rm tf e le m te rm tf e le m te rm tf

18 Anfragen: Wie sehen nun Anfragen aus? Grundsätzlich müssen wir beschreiben, welche Elemente (Pfadtypen) wir in der Antwort haben wollen und wie sie geordnet werden sollen. Daraus ergeben sich 4 Anfragebestandteile: 1. Angabe, welche Pfadtypen in der Antwort auftauchen sollen. Dies kann mit Hilfe eines Label-Pfades (z.b. /bookstore/medicine/book) geschehen. Damit wird die Menge der möglichen Antworten auf der Typ -Ebene eingeschränkt. 2. Prädikate, welche die Instanzen der Pfadtypen erfüllen müssen. Damit wird die Menge der möglichen Antworten auf der Instanz -Ebene eingeschränkt. 1. und 2. können auch durch einen XPath-Ausdruck zusammengefasst werden (z.b. /bookstore/computer-science[author= N. Wirth']). 3. Inhaltsbasierter Anfrageteil, welcher die Ordnung der Elemente gemäss der Relevanz zur Anfrage definiert. Dies kann im einfachen Fall eine Liste von Termen sein, oder aber angereichert mit Gewichten. 4. Parameter und Gewichte für das Retrievalmodell. Diese beeinflussen die Art und Weise wie das Retrievalmodell die Elemente ordnet (wir werden dies dann noch genauer im letzten Kapitel unter Relevanz Feedback anschauen).

19 4.3 Anfrage abhängige Statistiken Bei den meisten Retrievalmodellen (Vektorraum-, aber auch Probabilistisches Retrieval) haben wir spezielle Statistiken über die Kollektion berechnet, um die Terme gemäss ihrer Ausdrucksstärke zu gewichten. Viele Arbeiten über diese Modelle wissen zu berichten, dass es sehr wichtig ist, dass die Termgewichte (idf, c i ) speziell für eine Kollektion bestimmt werden. Universale Gewichte eignen sich nur schlecht, da ein Term wie z.b. Computer unwichtig in Informatikbibliotheken ist, aber sehr charakteristisch wirkt in Medizinbüchern. In diesem Zusammenhang müssen wir uns auch die Frage stellen, wie wir die Statistiken für XML Retrieval berechnen. Wir können z.b. Statistiken über alle Elemente hinweg berechnen und diese für alle Anfragen verwenden. Allerdings erlaubt XML Retrieval eine explizite Auswahl einer Teilkollektion, welche für das Retrieval betrachtet werden soll. Im Beispiel der Bücherdatei könnte man eine Anfrage nur über den Teilbaum /bookstore/medicine laufen lassen oder über den Teilbaum /bookstore/computer-science. Es ist sofort klar, dass für das Retrieval in Teilkollektionen bessere Statistiken verwendet werden könnten: nämlich Statistiken nur über die Elemente, welche sich überhaupt für die Antwort qualifizieren können. Anfragen können aber auch auf der Instanzenebene die Elementemenge einschränken. Müssen wir also zuerst alle Elemente bestimmen, welche überhaupt in Frage kommen, um die Statistiken zu bestimmen? Prinzipiell schon.

20 Grundsätzlich: Wir bestimmen die Statistiken wie bei den klassischen Verfahren. Anstelle von Dokumenten sprechen wir aber von Elementen. Damit ändern sich auch die Begriffe: aus Dokumentenhäufigkeit (df) wird Elementenhäufigkeit (ef) und aus inverser Dokumentenhäufigkeit (idf) wird inverse Elementenhäufigkeit (ief). Die Elementenhäufigkeit ef(t) ist definiert als die Anzahl Vorkommen des Terms t in den ausgewählten Elementen, d.h. in den Elementen, welche aufgrund der Prädikate und des Pfadtyps überhaupt erst in die Antwort kommen können. Im allgemeinen Fall heisst dies, dass wir die ef / ief Statistiken erst bestimmen können, wenn wir wissen welche Elemente sich überhaupt für die Antwort qualifizieren. Im Gegensatz zum Vektorraumretrieval bedeutet dies einen Mehraufwand. Die Auswertung ist dann wie folgt: 1. Bestimme die Menge A der Elemente, welche sich aufgrund der Pfadtypen- Wahl und Prädikate für die Antwort qualifizieren (Anfragebestandteil 1 + 2). 2. Berechne für alle Terme t Q: ef(t) = e A, tf(t,e)>0 1 und N = A 3. Führe das Retrieval auf den Elementen aus A aus und ordne die Elemente gemäss ihres rsv-wertes.

21 Vorherberechnung gewisser Statistiken: Falls keine Prädikate vorhanden sind sondern nur Pfadtypen gewählt werden, so können gewisse Statistiken bereits vorherberechnet werden. Dabei kann man sich auch nur auf Pfadtypen konzentrieren, welche überhaupt in Anfragen verwendet werden. bookstore medicine computer-science 1 1 te r m book e f book te r m e f title te r m e f author chapter te r m e f te r m chapter e f author te r m title e f title section section title te r m e f te r m e f te r m e f te r m e f

22 Die Vorherberechnung muss aufgrund der tf- Werte der Elemente erfolgen. Es gibt keine einfache Möglichkeit, die ef- Werte für z.b.chapter aufgrund der ef- Werte insection und title zu bestimmen. Dabei wird natürlich davon ausgegangen, dass die tf- Werte aller Elemente materialisiert sind (andernfalls müsste man dies zur Laufzeit durchführen). Falls eine Anfrage über verschiedene Pfadtypen gestellt wird (z.b. //book, d.h. alle Knoten mit dem Labelbook), so können die ef-werte der Pfadtypen durch aufaddieren kombiniert werden. Das Retrieval vereinfacht sich dahin gehend, dass der erste Schritt der Auswertung entfällt und der zweite Schritt wesentlich günstiger ist (Summe der efwerte der Queryterme über die Menge der selektierten Pfadtypen).

23 4.4 Literatur und Links Allgemein: XML + Datenbanken S. Abiteboul, P. Buneman, D. Suciu: Data on the Web: From Relations to Semistructured Data and XML. Morgan Kaufmann 1999 M. Klettke, H. Meyer: XML und Datenbanken. dpunkt Verlag, 2002 XML und verwandte Standards: Oracle: DB2: MSSQL: Tamino: Excelon: Natix: XML Retrieval INEX: