Deutsch

Informatik / 251-0341-00 / 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, [email protected]
4.1 XML – Daten- und Dokumentensicht
Aus Neil Bradley: The XML companion
•
•
•
•
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
•
Ä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).
•
Eine DTD beschreibt die Struktur von XML Dokumenten. In der Daten zentrischen
Sicht entspricht die DTD ungefähr einer Schemadefinition in NF2 (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.
•
Daten zentrierte Sicht von XML
Bsp: Datensätze einer Buchhandlung
Flexibilität
von XML
•
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:
/bookstore/book/@genre
• 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
– 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).
liefert
<book year="1999" isbn="1-X">
<title>Data on the Web</title>
<author>Abiteboul</author>
<author>Buneman</author>
<author>Suciu</author>
</book>
: Book*
FOR $b IN $bib0/book
WHERE $b/@year/data() <= 2000
RETURN $b
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
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 1000.- Fr.). Die Zielvorstellungen
müssen allerdings nicht genau getroffen werden und es soll das beste System eruiert
werden (z.B. 3D Grafik, 512MB, 80GB, 1020.- Fr). Diese Art der Suche ist allerdings
eng verwandt mit der nächsten Nachbar Suche des nächsten Kapitels.
PC3
3D
512MB
120GB
1200.-
PC2
3D
256MB
30GB
700.-
PC1
3D
512MB
80GB
1020.-
Ziel
3D
256MB
40GB
1000.-
•
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.
•
Bsp: Bücher einer Bibliothek als XML Teilbäume
bookstore
medicine
book
computer-science
book
title
book
chapter
author
book
chapter
book
book
book
chapter
chapter
author
...
...
...
...
...
...
title
section
section
title
title
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
•
•
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).
Beispiel: Bibliotheksdaten
bookstore
medicine
book
book
XML Dokumente aus dem Ordner
/data/ComputerScience
XML Dokumente aus dem
Ordner /data/Medicine
book
book
book
computer-science
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
•
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.
•
•
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 SubElementen 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?
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 KindElemente von e. Damit vereinfacht sich die Formel zu:
w(e,s) tf(t,s)
s child(e)
Σ∈
tf(t,e) = dtf(t,e) +
•
– 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
0.5
computer-science
0.5
1
1
w(e,s) = 0.35
book
0.9
title
0
0.7
author
0.7
chapter
0.9
title
book
0.5
section
0
author
chapter
0.5
section
0.9
title
0.9
title
dynamic structural summary (DataGuides)
•
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
book
te rm
author
tf
te rm
te rm
tf
te rm
te r m
tf
e le m
...
tf
book
e le m
...
te rm
tf
book
e le m
...
te r m
tf
e le m
. ..
e le m
. ..
tf
te rm
e le m
...
tf
te r m
book
tf
te r m
tf
e le m
...
te r m
tf
e le m
...
te r m
tf
e le m
. ..
title
te rm
tf
author
e le m
...
te r m
tf
tf
te r m
title
section
section
te rm
chapter
e le m
...
title
te rm
book
e le m
...
chapter
e le m
. ..
e le m
. ..
e le m
.. .
tf
tf
e le m
.. .
te rm
tf
e le m
.. .
te rm
tf
title
e le m
...
book
e le m
. ..
tf
te r m
e le m
...
book
computer-science
•
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).
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, ci) 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.
•
•
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 PfadtypenWahl 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.
•
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
0.5
computer-science
0.5
1
1
book
te rm
…
ef
0.9
title
te rm
…
0.5
te rm
…
ef
section
ef
te rm
…
ef
te rm
…
0.9
ef
title
section
te rm
…
title
te rm
…
ef
0.5
0.9
author
chapter
chapter
ef
0
ef
te rm
…
ef
author
0.7
te rm
…
0.7
title
0
0.9
ef
te rm
…
book
– 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
in section 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 Label book), 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).
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: http://www.w3.org
– Oracle: http://www.oracle.com/
– DB2: http://www-3.ibm.com/software/data/db2/
– MSSQL: http://www.microsoft.com/sql
– Tamino: http://www.softwareag.com/tamino/
– Excelon: http://www.exln.com/
– Natix: http://pi3.informatik.uni-mannheim.de/staff/mitarbeiter/moer/natix.html
XML Retrieval
– INEX: http://qmir.dcs.qmw.ac.uk/INEX/index.html