Yahoo für das Invisible Web - uni-due.de · Kapitel 1 Einleitung Im Studienprojekt „Yahoo für...

Universität Duisburg-Essen, Campus DuisburgInstitut für Informatik und interaktive Systeme

Fachgebiet Informationssysteme

Studienprojekt

Yahoo für das Invisible WebScatter/Gather-Clustering für semistrukturierte Daten

Prof. Dr. Norbert FuhrDipl.-Inform. Gudrun Fischer

(Wintersemester 2003/04)

Invisible Web Explorer(InveX)

Abschlussbericht

Michael ChojnackiTing Li

André NurzenskiZhihong Tang

19. April 2004

Inhaltsverzeichnis

1 Einleitung 6

2 Hintergrund 9

2.1 Das Deep Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.1 Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.2 Arten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.3 Derzeitiger Zugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Browsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.1 Arten von Browsing . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.2 Statisches vs. Dynamisches Browsing . . . . . . . . . . . . . . . . . 13

2.3 Vorprozessierte Scatter/Gather-Variante . . . . . . . . . . . . . . . . . . . 142.3.1 Cluster-Hierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.2 Änderung der Scatter/Gather-Browsing-Methode . . . . . . . . . . 162.3.3 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.3.1 Generierung der Hierarchie . . . . . . . . . . . . . . . . . 172.3.3.2 Meta-Profile und Truncation . . . . . . . . . . . . . . . . 18

2.3.4 Veränderungsmöglichkeit . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Das InveX-Werkzeug 20

3.1 Preprocessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2 Datenstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1 grundlegende Datenstruktur . . . . . . . . . . . . . . . . . . . . . . 243.2.2 Speichersystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.3 Ähnlichkeitsmaß . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.2.4 Termgewicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2

INHALTSVERZEICHNIS 3

3.3 Clustering/Scatter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.1 Flat Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.3.2 Hierarchical Clustering . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.4 InveX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.5 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Beispielsession 43

5 Tests und Interpretation 48

5.1 Test 1 (Clusterqualität und Skalierbarkeit) . . . . . . . . . . . . . . . . . . 485.2 Test 2 (Zeitaufwand Präprozessor) . . . . . . . . . . . . . . . . . . . . . . . 505.3 Test 3 (Clusterqualität) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6 Zusammenfassung und Ausblick 55

Literatur 56

A Übersicht der Konfigurationswerte 59

Abbildungsverzeichnis

3.1 Invex Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 UML Sequenzdiagramm: Preprocessor . . . . . . . . . . . . . . . . . . . . 233.3 Klassendiagramm Datenstruktur . . . . . . . . . . . . . . . . . . . . . . . . 253.4 Klassendiagramm Speichersystem . . . . . . . . . . . . . . . . . . . . . . . 293.5 Tabellen in der Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.6 Klassendiagramm Ähnlichkeitsmaß . . . . . . . . . . . . . . . . . . . . . . 323.7 Klassendiagramm Termgewicht . . . . . . . . . . . . . . . . . . . . . . . . 333.8 Klassendiagramm Flat-Clustering . . . . . . . . . . . . . . . . . . . . . . . 363.9 Sequenzdiagramm Modul Invex . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1 Initiale Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2 Auswahl zweier Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3 Detaillierte Beschreibung eines Clusterings . . . . . . . . . . . . . . . . . . 454.4 Beschreibung eines Beispieldokumentes im XML-Format . . . . . . . . . . 47

5.1 Preprocessor - mittlerer Zeitaufwand bei 5 Clustern . . . . . . . . . . . . . 505.2 Preprocessor - mittlerer Zeitaufwand bei 10 Clustern . . . . . . . . . . . . 515.3 Aussagekräftige Terme unter den ersten 5 . . . . . . . . . . . . . . . . . . . 535.4 Aussagekräftige Terme unter den ersten 10 . . . . . . . . . . . . . . . . . . 535.5 Aussagekräftige Terme unter den ersten 15 . . . . . . . . . . . . . . . . . . 54

4

Tabellenverzeichnis

5.1 Zeitaufwand Preprocessor in Minuten . . . . . . . . . . . . . . . . . . . . . 50

A.1 Konfigurationwerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59A.2 Konfigurationwerte Database . . . . . . . . . . . . . . . . . . . . . . . . . . 60A.3 Konfigurationwert Buckshot . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5

Kapitel 1

Einleitung

Im Studienprojekt „Yahoo für das Invisible Web“ haben wir uns mit dem Browsen in se-mistrukturierten Dokumenten beschäftigt und ein Werkzeug entwickelt, das dieses Brow-sen in beliebigen Dokumentenkollektionen ermöglicht. Wir haben uns hierbei auf Daten imXML-Format beschränkt, das Prinzip ist aber auch auf andere Formate übertragbar.

Das Invisible bzw. Deep Web ist der Teil des WWW, der nicht von Suchmaschinen inde-xiert wird und somit auch nicht durch diese zugänglich ist. Der Umfang an Informationenim Deep Web ist ca. 500 mal größer als im Surface Web, wovon ca. 95 Prozent kostenlos fürdie Öffentlichkeit zugänglich sind. Der gesamte Datenbestand beträgt in etwa 7.500 Ter-abyte, die in vielen verschiedenen Quellen abgelegt sind [Ber01]. Eine weiterere Eigenschaftdes Deep Web ist sein dynamischer Charakter, d.h. Dokumente werden laufend hinzuge-fügt, entfernt oder geändert/ergänzt. Eine detaillierte Beschreibung der Eigenschaften desDeep Web ist in 2.1 zu finden.

Ein Beispiel für eine Quelle im Deep Web sind die Open Archives. Hier werden eineVielzahl von verschiedensten Dokumentenbeschreibungen im XML-Format angeboten, diebeispielsweise den Autor, den Titel oder eine Inhaltsübersicht enthalten können. In diesenBeschreibungen kann aber Aufgrund der oben angesprochenen fehlenden Indexierung nichtgesucht werden. Sollen nun relevante Dokumente identifiziert werden, müsste ein Benutzerentweder jede einzelne Beschreibung sichten oder stichprobenartig auf ihre Relevanz hinprüfen.

Da ein solcher Aufwand aber ab einer bestimmten Anzahl von Dokumenten nicht mehrpraktikabel ist, sollte nun ein geeignetes Verfahren entwickelt werden, um eine beliebigeAuswahl von Dokumenten und Informationen aus den verschiedenen Quellen sinnvoll sich-

6

KAPITEL 1. EINLEITUNG 7

ten zu können. Einem Benutzer sollte also die Möglichkeit gegeben werden, planvoll undstrukturiert in dieser Menge von Dokumenten zu browsen, um sich einen Überblick überThemen und Inhalte verschaffen zu können. Dieses Browsing kann auf verschiedene Artenstattfinden, in 2.2 werden diese Arten näher erläutert.

Um einen solchen Überblick zu erlauben, sollten die Dokumente nach ihren Inhaltengruppiert und strukturiert werden, um so die Auswahl geeigneter Dokumente oder Doku-mentgruppen zu erleichtern. Eine Möglichkeit, einen solche Übersicht zu erstellen, wäreein statisches Verzeichnis, in dem die Dokumente beispielsweise nach Kategorien aufgeteiltwurden. Ein Beispiel für ein solches Verzeichnis ist das Web-Verzeichnis von Yahoo, das einethematisch gegliederte Sammlung von Web-Seiten enthält. Die im ersten Ansatz angespro-chene Dynamik und die Freiheit des Benutzers, eine beliebige Auswahl von Dokumentenzu betrachten, verhindern allerdings diesen Ansatz des statischen Browsings. Ein für unserProblem sinnvolles Browsing-Verfahren sollte also, ausgehend von einer beliebigen Doku-mentenmenge, automatisch eine Gruppierung von ähnlichen Dokumenten vornehmen, unddiese Gruppen dem Benutzer zur weiteren Analyse anzeigen können. Somit sollte in un-serem Fall ein dynamisches Browsing-Verfahren zur Anwendung kommen, in 2.2.2 werdendie Unterschiede beider Verfahren näher erläutert.

Als Ansatz für ein solches Verfahren wurde deshalb das in [CPKT92] beschriebeneScatter/Gather-Verfahren gewählt. Bei diesem Verfahren wird die übergebene Dokumen-tenkollektion zu Beginn in eine vorher festgelegte Anzahl von Gruppen/Clustern aufgeteiltund dem Benutzer Beschreibungen dieser Gruppen präsentiert. Der Benutzer kann nunim weiteren für ihn interessante Gruppen auswählen und diese erneut gruppieren lassen.Dadurch wird eine immer feinere Aufteilung der Dokumente nach ihren Inhalten erreicht.Dieser Vorgang kann so lange wiederholt werden, bis in den erzeugten Gruppen nur nochjeweils ein Dokument vorhanden ist. Da dieses Verfahren aber für größere Dokumentenkol-lektionen (> 100) nicht schnell genug ist, wurde dieser Ansatz, wie in [CKP93] beschrieben,zu einem vorprozessierten Browsing-Verfahren erweitert. Eine detaillierte Übersicht überdas Verfahren und die notwendigen Anpassungen wird in 2.3 gegeben.

Das Ergebnis dieses Projekts ist das InveX-Werkzeug (Invisible Web Explorer), dasauf dem Prinzip eines vorprozessierten Scatter/Gather-Verfahrens basiert. Dieses Werk-zeug ermöglicht es nun, in einer Kollektion von beliebigen XML-Dokumenten dynamischzu browsen. Dabei spielt es keine Rolle, ob diese XML-Dokumente nur Beschreibungen vonDokumenten (Metadaten) oder vollständige Dokumente enthalten. In Kapitel 3 beschreiben

KAPITEL 1. EINLEITUNG 8

wir die Implementierung des InveX-Werkzeugs, d.h. die Implementierung einer vorprozes-sierten Scatter/Gather-Variante basierend auf einem hierarchischen Cluster-Algorithmus.Darauf folgend zeigen wir die Funktionsweise und die Ausführung des InveX-Werkzeugsanhand einer Beispielsession (Kapitel 4). Die ermittelten Testergebnisse sowie die Qualitätund Skalierbarkeit werden in Kapitel 5 diskutiert, zum Abschluss folgen dann noch eineZusammenfassung und ein Ausblick (Kapitel 6).

Kapitel 2

Hintergrund

Bevor wir detaillierter auf unser in der Einleitung angesprochene Browsing-Werkzeug einge-hen, sollen in diesem Kapitel zunächst einige Eigenschaften und Hintergrundinformationenzum Deep Web (2.1) sowie zum Browsing allgemein gegeben werden (2.2). Die hier ange-sprochenen Punkte verdeutlichen, warum Cluster-basiertes Browsing ein sinnvoller Ansatzist, um sich einen Überblick über Inhalte von Dokumenten aus dem Deep Web zu verschaf-fen.

Im weiteren werden hier Grundlagen aus einer früheren Arbeit erörtert, auf denen dasvon uns entwickelte InveX-Werkzeug basiert (2.3).

2.1 Das Deep Web

Deep Web ist eine Bezeichnung für die im Internet nicht über normale Suchmaschinenauffindbaren Informationen. Analog hierzu existiert das so genannte Surface Web, das vonSuchmaschinen indexiert wird und somit auch über diese zugänglich ist. Das Deep Webwird auch als Invisible Web bezeichnet.

Im folgenden werden die Eigenschaften und verschiedenen Arten des Deep Web be-schrieben sowie die derzeitigen Zugriffsmethoden erläutert.

2.1.1 Eigenschaften

Nach einer Studie der Firma BrightPlanet (siehe [dGU04]) hat das Deep Web folgendeEigenschaften:

9

KAPITEL 2. HINTERGRUND 10

• Es existieren mehr als 100 000 Deep Websites.

• Das Deep Web ist die am schnellsten wachsende Kategorie im Web.

• Die gesamte Qualität des Deep Web ist 1000 bis 2000 mal größer als der Durschnittnormaler Webseiten.

• Mehr als die Hälfte des Deep Web ist in themenspezifischen Datenbanken angesiedelt.

• Über 95 Prozent des Deep Web sind für die Öffentlichkeit zugänglich, ohne dassGebühren entrichtet werden müssen.

• Im Deep Web verbergen sich 7 500 Terabyte an Informationen, im Gegensatz zu 19Terrabyte im Surface Web.

2.1.2 Arten

In [Hei03] werden 5 Typen von Deep Web definiert:

• Opaque Web Das Opaque Web besteht aus Dateien, die in Suchmaschinenindizesaufgenommen werden könnten, aber (momentan) nicht werden. Dies ist nicht durchgrundsätzliche technische Hürden begründet, sondern durch die Performance, diePraktikabilität und durch die Aufwand-Nutzen-Relation.

• Private Web Das Private Web besteht aus Dateien, die grundsätzlich in Suchma-schinenindizes aufgenommen werden könnten, aber aufgrund der Zugangseinschrän-kungen (z.B. Passworte oder gewollte Robot-Abweisungen), die durch den Anbietergesetzt werden, nicht aufgenommen werden sollen.

• Proprietary Web Das Proprietary Web besteht aus Dateien, die zwar technisch vonSuchmaschinen indexiert werden könnten, die aber nur Personen zugänglich sind, diebestimmten Nutzungsbedingungen in Form einer Registrierung zugestimmt haben(kostenlos oder kostenpflichtig).

• Invisible Web Das Invisible Web besteht aus Dateien, die durch Suchmaschinenindexiert werden könnten, aber aus technischen, strategischen oder kaufmännischenGründen der Suchmaschinenbetreiber nicht indexiert werden.


• Truly Invisible Web Das Truly Invisible Web besteht aus Dateien, die aus tech-nischen Gründen durch Art der Datenvorhaltung von Suchmaschinen nicht indexiertwerden können. Zum Biespiel:

– Web-Seiten in Dateiformaten, die Crawlers (derzeit) nicht verarbeiten können(Flash, Shockwave, ausführbare Dateien, Text auf Bildern, Bildinhalte).

– Dynamische Web-Seiten

– Daten in Datenbanken wie Dialog, Lexis-Nexis, Dow Jones, GENIOS und GBI.

Im diesem Projekt werden Daten und Dokumente aus dem echten Invisible Web (Typfünf) betrachtet.

2.1.3 Derzeitiger Zugriff

Das Deep Web ist den Suchrobotern oder Spidern der Suchmaschinen nicht zugänglich. Beider Recherche in solchen Datenbanken fungiert das WWW nur als Schnittstelle, das dieAnfrage an den externen Rechner weiterleitet und das Ergebnis im HTML-Format anzeigt.Zur Ermittlung von Datenbanken stehen nach [dGU04] folgende Hilfsmittel zur Verfügung:

• Die Suche nach Datenbanken mit entsprechenden Suchbegriffen über Suchmaschi-nen, um so Einstiegs- oder Hinweisseiten zu den Datenbanken zu ermitteln.

• Die Nutzung bekannter Linklisten zu Datenbanken, die zumeist von öffentlichen Bi-bliotheken erstellt werden. So bieten zum Beispiel die Universitätsbibliothek Bochumund die Hamburger Öffentlichen Bücherhallen jeweils eine umfangreiche Zusammen-stellung an.

• Spezialdienste zur Erschließung von Datenbanken wie www.completeplanet.com.Hier sind über 100.000 Datenbanken und Spezialsuchmaschinen zu allen Sachgebietenaufgeführt.

• Agenten-Software für den PC wie LexiBot von BrightPlanet. Damit können 2.200Datenbanken gleichzeitig durchsucht werden, und das Programm bietet Hilfe für dieFilterung und Verfeinerung der Suche.


Die hier beschriebenen Zugriffsmethoden erlauben lediglich, nach Quellen im Deep Web,also Datenbanken oder Datenbeständen, zu suchen. Ein Browsing und somit die Möglich-keit, mehr über den Inhalt der Quellen zu erfahren, ist damit nicht möglich. Im nächstenAbschnitt sollen deshalb zunächst einige allgemeine Informationen zum Browsing gegebenwerden, und danach ein Ansatz zum Browsen in XML-Dokumenten aus Quellen im DeepWeb vorgestellt werden.

2.2 Browsing

Da sich dieses Projekt mit dem Browsen in Dokumentenkollektionen aus dem Deep Webbeschäftigen, sollen in diesem Abschnitt zunächst die verschiedenen Zielsetzungen einerBrowsing-Session beschrieben werden. Außerdem wird noch auf den Unterschied zwischendem in der Einleitung erwähnten statischen und dynamischen Browsing näher eingegangen.Anschließend stellen wir das Verfahren aus einer früheren Arbeit vor, das die Grundlagefür unser Browsing-Werkzeug bildet.

2.2.1 Arten von Browsing

Die Zielsetzung einer Browsing-Session kann variieren, in [Sac03] werden verschiedene Zielewie folgt unterschieden:

• gerichtetes, zielorientiertes Browsen: Es werden Antworten auf relativ präziseFragen gesucht.

• gerichtetes Browsen mit Mitnahmeeffekt: Auf der Suche nach bestimmten In-formationen stößt man auf thematisch verwandte Informationen, nach denen manursprünglich nicht gezielt gesucht hat. Man verfolgt sein ursprüngliches Suchziel wei-ter, nimmt dabei aber zusätzliche Informationen auf.

• gerichtetes Browsen mit Serendipity-Effekt: Auf der Suche nach einer bestimm-ten Information wird man von einer anderen Information so sehr vom eigentlichenSuchziel abgelenkt, dass das ursprüngliche Ziel uninteressant wird.

• scan browse: Der Hypertext wird überflogen, um Informationen zu sammeln, diemit einem relativ unscharfen Ziel übereinstimmen.


• review browse: Das Ziel besteht darin, interessante Informationen in ein mentalesModell zu integrieren.

• assoziatives Browsen: Es wird nicht gezielt nach Informationen gesucht, sondernman lässt sich vom Angebot leiten, bis kein Anreiz mehr vorhanden ist, weiterenAngeboten zu folgen.

• ungerichtetes Browsen: Diese Art des Browsens ist zu beobachten, wenn man sichzwar bewusst ist, dass man zur Lösung eines Problems Informationen benötigt, manaber noch nicht genau weiß, welche.

Das Suchen ist ein anderes Verfahren, aus einer Kollektion von Dokumenten relevantenInformatione zu erhalten. Allerdings basiert das Suchen auf vorher bekannten Informatio-nen wie z.B. Schlüsselwörtern, Autor, Verlag, usw., während Browsing auch dann eingesetztwerden kann, wenn noch nichts über die Kollektion bekannt ist. Wenn ein Mangel an not-wendigen Informationen wie z.B. Unkenntnis von speziellen Begriffen oder Themengebietenvorliegt, dann ist das Browsing bevorzugt.

2.2.2 Statisches vs. Dynamisches Browsing

Nach den verschiedenen Strukturen, durch die man navigiert, kann man Browsing auch instatisches und dynamisches Browsing unterteilen.

Beim statischen Browsing gibt es in der Regel eine statische Struktur, die nach gewis-senen Kriterien (z.B. über Themen und Inhalten) eine Aufteilung und somit einen Überblicküber die Dokumente verschafft. Der Benutzer kann durch diese Struktur navigieren und dieDokumente browsen. Ein Beispiel für eine solche statische Struktur ist das Web-Verzeichnisvon Yahoo!. Es werden zuerst themenspezifisch verschiedene Kategorien und Subkategori-en manuell erstellt. Dadurch entsteht ein Verzeichnisbaum. Die Web-Seiten werden jeweilsbewertet und in dem Verzeichnisbaum eingegliedert. Der Benutzer kann dann leicht durchden Baum zu den relevanten Seiten navigieren. Ein Beispiel für ein Kategoriepfad ist Tiere→ Fische → Barsch.

Ein Nachteil des statischen Browsings ist der statische Aufbau, d.h. der Benutzer hatnur die Möglichkeit, durch eine vorhandene statische Struktur zu navigieren. Das läßt sicheiner dynamischen Kollektion schwer anpassen. Dynamische Änderungen der Kollektion,wenn z.B. Dokumente zu einem völlig neuen Themengebiet hinzukommen, spiegeln sich


nicht unbedingt wieder. Beim dynamischen Browsing dagegen wird die Struktur erstwährend der Interaktion mit dem Benutzer erzeugt. Ein Nachteil dieser Methode ist dielängere Wartezeit, dafür ist die Struktur jedoch immer automatisch auf den aktuellen Inhaltder Kolletion zugeschnitten.

Im Projekt geht es um das Browsen in Dokumentenmengen aus dem echten InvisibleWeb. Das bedeutet, dass die Daten, durch die man browsen möchte, zahlreich und dyna-misch ausgewählt sind. Dafür ist eine statische Struktur nicht geeignet, deswegen brauchenwir zum Browsing eine Möglichkeit, die Struktur dynamisch zu erzeugen. Eine solche Mög-lichkeit bietet das Scatter/Gather-Paradigma in [CPKT92].

Die Struktur, die bei Scatter/Gather dynamisch erzeugt wird, ist jeweils eine Mengevon Clustern. Jeder Browsing-Schritt besteht dabei aus zwei Phasen, einer Scatter-Phaseund einer Gather-Phase. In der Scatter-Phase wird die Dokumentenmenge in eine vorge-gebene Anzahl von Clustern zerlegt und die resultierenden Cluster werden dem Benutzerangezeigt. In der Gather-Phase wählt der Benutzer einen oder mehrere für ihn interessanteCluster aus, die dann zusammengemischt werden und die Ausgangsmenge für den nächstenBrowseschritt bilden.

2.3 Vorprozessierte Scatter/Gather-Variante

Ein wichtiger Aspekt beim Scatter/Gather-Browsing sind schnelle Clustering-Algorithmenund effektive Cluster-Beschreibungen. Die allgemein bekannten Algorithmen, deren Lauf-zeit zur Größe der Kollektion quadratisch ist, sind offenbar für große Kollektionen zu teuer.Um eine gute interaktive Performance zu erzielen, wird in diesem Abschnitt eine Methodezur Beschleunigung von Scatter/Gather [CKP93] vorgestellt. Hierbei handelt es sich umeine vorprozessierte Scatter/Gather-Variante, deren Laufzeit für große Kollektionen fastlinear ist.

Bevor die Datenstruktur näher erläutert wird, soll zuerst eine Hypothese betrachtetwerden:

• Cluster-Refinement-Hypothese: Ähnliche Dokumente, die sich bei einem feinenClustering in einem Cluster befinden, werden auch bei einem groben Clustering ineinem Cluster erfasst.

Im folgenden Abschnitt stellen wir zunächst die Datenstruktur, die der modifizierten


Variante von Scatter/Gather aus [CKP93] zugrunde liegt. Danach gehen wir auf die nötigenÄnderungen im Scatter/Gather-Verfahren ein. Anschließend wird noch die Implementie-rung kurz erläutert.

2.3.1 Cluster-Hierarchie

Die Datenstruktur basiert auf einer Cluster-Hierarchie, die durch klassisches agglomera-tives oder partitionierendes Clustering produziert werden kann. Als Ergebnis erhält maneine Baumstruktur. Dieser Baum wird rekursiv entweder als Blatt (entspricht einem ein-zelnen Dokument) oder als Baum (dessen Unterbäume wieder Cluster-Hierarchien sind)beschrieben. Ein Clustering-Algorithmus produziert solch einen Baum, in dem jeder in-terne Knoten der Agglomeration der Dokumente entspricht, die von den Kindern diesesKnotens dargestellt werden. Somit haben Dokumente, die ähnlich sind, einen gemeinsamenVorfahr unten im Baum, während sich die Vorfahren von Dokumenten, die einander wenigähnlich sind, nahe der Wurzel befinden. Zu unseren Zwecken ist es auch wünschenswert,dass der Baum verhältnismäßig ausgeglichen ist, um den Zeitaufwand beim Browsing zuverkürzen.

Ein interner Knoten der Cluster-Hierarchie entspricht einem Cluster und somit einerMenge von Dokumenten. Dokumente werden in [CPKT92] in Form von Profilen repräsen-tiert, die dort aus den häufigsten Termen und deren Anzahl im Dokument bestehen. In[CKP93] werden nun Cluster ebenfalls durch Profile repräsentiert, die sich aus den Profi-len der in ihnen enthaltenen Dokumente berechnen. Einen solchen Cluster-Repräsentantennennen wir Metadokument. Die Datenstruktur, die für die modifizierte Scatter/Gather-Variante aufgebaut wird, ist eine Baumhierarchie von Metadokumenten, mit den ursprüng-lichen Dokumenten als Blättern.

Die Kinder eines Metadokumentes sind dort wiederum Metadokumente und entsprechenden Clustern, die aus den Dokumenten ihres Elternknotens gebildet wurden. Die Cluster-Refinement-Hypothese lässt daher erwarten, dass ein Clustering der Metadokument-Kindereines Knotens ein ähnliches Ergebnis liefert wie ein Clustering der ursprünglichen vomKnoten repräsentierten Dokumente. Im nächsten Abschnitt beschreiben wir, wie sich dieseEigenschaft nutzen lässt, um für den Zeitaufwand jedes einzelnen Scatter-Schrittes einekonstante Höchstgrenze zu garantieren.


2.3.2 Änderung der Scatter/Gather-Browsing-Methode

Wenn der Zeitaufwand für das Clustern von n Objekten nur von n abhängt, und wenn Mdie höchste Anzahl von Objekten ist, die wir innerhalb der vorgegebenen Zeit clustern kön-nen, dann wäre das Ziel erreicht, wenn wir in jedem Scatter-Schritt höchstens M Objekteclustern müssen.

Für die modifizierte Scatter/Gather-Variante aus [CKP93] wird zunächst offline eineMetadokument-Hierarchie berechnet. Die Wurzel dieser Metadokument-Hierarchie ist ei-ne Repräsentation der gesamten Dokumentenkollektion. Ihre Kinder sind Repräsentanteneines ersten Clusterings der Kollektion. Ein solches Clustering ist auch die Ausgangsba-sis einer Scatter/Gather-Sitzung. Dem Anwender werden daher nun zu Anfang die di-rekt unter der Wurzel befindlichen Metadokumente gezeigt. Da Metadokumente Cluster-Repräsentationen sind, ändert sich in der Darstellung (und damit für den Anwender) nichts.

Wie bisher wählt der Anwender nun einen oder mehrere Cluster (in Wahrheit Meta-dokumente) aus, um die darin befindlichen Dokumente erneut clustern zu lassen. DieseMenge nennen wir Fokus Set. Die darin befindlichen Metadokumente repräsentieren je-weils eine Menge von Dokumenten. Gleichzeitig besitzen sie innerhalb der vorprozessiertenMetadokument-Hierarchie Kinder, die wiederum Metadokumente sind. Ein Metadokumentund seine Kinder repräsentieren insgesamt dieselbe Menge von Dokumenten, allerdingsbilden die Kinder zusammen eine genauere Darstellung der Dokumentenmenge als dasEltern-Metadokument es kann. Wenn wir also im Fokus Set ein Metadokument durch seineMetadokument-Kinder ersetzen, so stellt das Fokus Set danach eine genauere Repräsen-tation der zu clusternden Dokumente dar. Außerdem können wir als Heuristik annehmen,dass ein Dokument innerhalb einer Dokumentenmenge von einem Metadokument umsoungenauer repräsentiert wird, desto mehr andere Dokumente das Metadokument ebenfallsrepräsentiert. Je größer (in der Anzahl der Dokumente) ein Metadokument also ist, destoungenauer ist es auch als Repräsentant. Daher wählen wir im Fokus Set (im folgendenauch als F bezeichnet) jeweils das größte Metadokument aus und ersetzen es durch seineMetadokument-Kinder, bis die Anzahl der Objekte im Fokus Set M erreicht, die Maximal-zahl von Objekten, die wir in der festgelegten zeit clustern können:

while F has fewer than M meta-documents

Find the meta-document D in F with the most leaves

Replace D by its children in the hierarchy


Wenn der Verzweigungsfaktor in der Metadokument-Hierarchie k ist, dann enthält dasFokus Set nach dieser Erweiterung höchstens M + k − 1 = M ′ Metadokumente, die wei-terhin die Dokumente repräsentieren, die der Anwender clustern lassen möchte. Nach derCluster-Refinement-Hypothese kann man statt der Dokumente nun die Metadokumenteclustern und dabei ein ähnliches Ergebnis erhalten. Als Ergebnis werden die entstandenenCluster präsentiert, aus denen der Anwender wieder einige für den nächsten Scatter-Schrittauswählen kann. Für den Anwender ändert sich somit nichts. Die ausgewählten Cluster sindnun jedoch schon Mengen von Metadokumenten und bilden vereinigt das neue Fokus Set.

Insgesamt werden bei dieser modifizierten Variante von Scatter/Gather anstatt einerbeliebig großen Zahl von Dokumenten bei jedem Scatter-Schritt jeweils maximal M ′ Me-tadokumente geclustert, d.h. es gibt nun eine obere Zeitgrenze für den Clustering-Schritt.

2.3.3 Implementierung

Im folgenden Absatz werden noch einige Details bei der Implementierung betrachtet unddiskutiert.

2.3.3.1 Generierung der Hierarchie

Weil die Laufzeit eines agglomerativen Clusterings quadratisch ist, verwendet man statt-dessen partitionierende Clustering-Algorithmen, wie z.B. Buckshot oder Fractionation, diein [CPKT92] beschrieben werden. Sie clustern die Dokumente in k Gruppen in einem li-nearen Zeitaufwand O(k · n). Solche partitionierenden Verfahren können leicht verwendetwerden, um eine Cluster-Hierarchie zu erzeugen: Man erzeugt ein erstes, grobes Cluste-ring und wendet den Algorithmus dann rekursiv auf jeden einzelnen Cluster wieder an undstoppt an den einzelnen Dokumenten. Wird ein Verzweigungsfaktor k gegeben, partitioniertman die gesamte Kollektion in k Gruppen mit einem Zeitaufwand von O(k · n). Jede die-ser Gruppen betrachtet man wieder als Subkollektion, die wieder in k Sub-Subkollektionenpartitioniert wird. Diese Schritte werden so lange fortgeführt, bis die Hierarchie vollständigaufgebaut ist. Die Gesamtkosten aller Clusterings auf jeder Schicht sind O(k ·n) und es gibtinsgesamt O(logn) Schichten. Somit wird das gesamte Verfahren mit einem Zeitaufwandvon O(k · n · logn) durchgeführt.


2.3.3.2 Meta-Profile und Truncation

Wie oben bereits erwähnt wurde, kann ein interner Knoten in einer Cluster-Hierarchieeinem Metadokument entsprechen, d.h seine Kinder sind wieder eine Menge von Doku-menten bzw. Metadokumenten. Einzelne Dokumente werden als eine Menge von Wort-Gewicht-Paaren, d.h. hoch-dimensionalen aber dünn besetzten Vektoren oder Profilen re-präsentiert. In [CKP93] werden Profile von Metadokumenten als Summe der Profile ihrerKinder berechnet.

Der Zeitaufwand unserer partitionierenden Algorithmen für das Clustering einer Mengevon n Objekten in k Cluster ist nur dann O(k · n), wenn der Zeitaufwand für die Berech-nung der Ähnlichkeit zweier Objekte konstant ist. Die Ähnlichkeit zwischen Dokumenten,die man hier verwendet, ist ein inneres Produkt (Kosinusmaß) der Dokument-Profile undkann in linearer Zeit zur Profilgröße berechnet werden. Bei größeren Profilen nimmt auchder Aufwand für die Ähnlichkeitsberechnung zu. Wenn ein Metadokument-Profil alle Infor-mationen aus seinen Dokumenten enthielte, dann würde die Profilgröße mit der Größe derDokumentenkollektion wachsen, d.h. der Zeitaufwand für Ähnlichkeitsberechnungen wärenicht konstant, sondern linear zur Kollektionsgröße.

Um dieses Problem zu lösen, kann man die Metadokument-Profile abschneiden (trun-cate), so dass nur noch die wichtigsten Terme eingeschlossen werden. In [CPKT92] sinddies die häufigsten Terme.

2.3.4 Veränderungsmöglichkeit

Wie oben erwähnt wurde, ist das Kosinusmaß eine Möglichkeit, um die Dokumentenähn-lichkeit zu berechnen. Dieses Maß ist auch das in unserem Projekt verwendete Ähnlichkeits-maß. Es basiert auf dem Vektorraummodell. Alternativ sind auch andere Maße vorstellbar,z.B. ein probabilistisches, das die Wahrscheinlichkeit angibt, dass zwei Dokumente in den-selben Cluster gehören.

Als Termgewichtungen wurden zwei Gewichte in unserem Projekt betrachtet. Die eineVariante verwendet wie in [CPKT92] als Termgewicht die Termfrequenz, die andere Varian-te schätzt den Informationsgehalt des Terms im aktuellen Cluster im Vergleich zum Infor-mationsgehalt desselben Terms im Rest der Kollektion. Beide Termgewichtungen werdenin 3.2.4 näher erläutert. In Kapitel 5 werden 3 Tests über die verschieden Kombinationenvon Kosinusmaß und Termgewichtung gemacht, um das zu zeigen, welche Kombination


bessere Retrievalqualität liefert.

Kapitel 3

Das InveX-Werkzeug

In den folgenden 5 Modulen wollen wir den Kern des InveX-Werkzeugs, das auf der imvorherigen Kapitel vorgestellten Thoerie basiert, detailliert beschreiben. Im ersten Modulwird der Preprocessor (Abschnitt 3.1), der die Vorprozessierung der Dokumente übernimmtund dadurch die verbesserte Laufzeit von Scatter/Gather überhaupt erst ermöglicht, dar-gestellt. Darauf folgend wird das Modul Datenstrukturen (Abschnitt 3.2) beschrieben. Die-ses Modul unterstützt die Abläufe in den einzelnen Algorithmen durch die Bereitstellunggrundsätzlicher Funktionalitäten von Cluster-Objekten. In Abschnitt 3.3 werden die ver-schiedenen Algorithmen vorgestellt, die die von uns definierten Datenstrukturen benutzen,um die Cluster aus der Kollektion zu generieren. Während die Abläufe der Algorithmennur im Hintergrund eine Rolle spielen, ist nur die GUI für den Benutzer sichtbar. DieGUI spricht das InveX-Werkzeug über die in Abschnitt 3.4 beschriebene Schnittstelle an.Abschließend wird das Modul Config erläutert, das das Auslesen der InveX-spezifischenKonfiguration ermöglicht.

Die einzelnen Module und ihre Interaktion sind in Abbildung 3.1 dargestellt.

3.1 Preprocessor

Die Klasse Preprocessor (invex.Preprocessor) beschreibt eine Prozedur zur Erzeugungeiner Baum-Hierarchie. Hier finden die Methoden run(), finalize(), createFromFile(),cluster() und generateAndSaveSingletonMetaDocuments() Verwendung.Im Folgenden werden die einzelnen Methoden detailliert beschrieben:

• run()

20

KAPITEL 3. DAS INVEX-WERKZEUG 21

Abbildung 3.1: Invex Aufbau

Die Kernmethode, die von der main() Methode aufgerufen wird und die Subpro-zeduren generateAndSaveSingletonMetaDocuments() und cluster(Collection)miteinander verbindet. Vor der Generierung der Baumstruktur werden zunächst dierealen Dokumente eingelesen und als SingletonMetaDocuments gespeichert. Als IDwird dabei der Dateiname des Dokuments genutzt. Danach folgt die eigentliche Gene-rierung der Baumstruktur. Nach dem Aufbau der Baumstruktur wird die Verbindungzum Speichersystem durch Aufrufen der Methode finalize() geschlossen. In dieserMethode wird die Methode info() der Klasse Logger eingesetzt, um einige Informa-tionen z.B. Anfang und Ende einer Subprozedur zu veranschaulichen und gleichzeitigdie Laufzeit dieser Prozedur zu berechnen. Dies geschieht, indem die Differenz zwi-schen der Anfangs- und Endzeit berechnet wird.

• generateAndSaveSingletonMetaDocuments()Diese Methode wird für die Vorbereitung zur Generierung der Baumstruktur ge-nutzt. Hier wird eine rekursive Methode aufgerufen, um das Datenverzeichnis (wird inder Konfigurationsdatei festgelegt) und alle Unterverzeichnisse nach Dokumenten zudurchsuchen. Für jedes gefundene Dokument wird die Methode createFromFile()


aufgerufen und ein SingletonMetaDocument erzeugt, das dann im Speichersystemabgelegt wird. Als Ergebnis wird eine Menge von SingletonMetaDocuments zurück-gegeben.

• createFromFile()Wird von der Methode generateAndSaveSingletonMetaDocuments() aufgerufen,um ein SingletonMetaDocument auf Basis eines realen Dokuments zu erzeugen. MitHilfe der Methode generateProfile() der Klasse SingletonMetaDocument wer-den die zugehörigen Profile, d.h. die wichtigsten Terme und eine Beschreibung fürdieses Dokument, generiert. Durch die Betrachtung der wichtigsten Terme anstattaller Terme wird Rechenaufwand für Berechnungen sowie Speicherplatz eingespart.Schließlich werden die erzeugten SingletonMetaDocumente im Speichersystem ab-gespeichert. Um Fehler anzuzeigen, werden während dieses Ablaufs die Methodenerror() und warn() der Klasse Logger genutzt.

• cluster()In dieser Methode wird die Baumstruktur der Dokumentenkollektion erzeugt. Durchrekursive Anwendung arbeitet diese Methode wie ein hierarchischer Clusteralgorith-mus, der auf Basis eines flachen Clusteralgorithmus (hier Buckshot) die Clusteringsauf jeder Ebene der Hierarchie durchführt. Für eine detaillierte Beschreibung derClustering-Verfahren und der Algorithmen siehe 3.3. Zum Schluss werden die Meta-dokumente im Speichersystem abgelegt.

(Es wird zuerst auch die Methode cluster(Metadocument, Collection) aufgerufenund danach die abstrakte Methode des Interface FlatClustering implementiert.Intuitiv werden die Kinder des aktuellen Clusters erzeugt. Sind solche Kinder nichtvom Typ SingletonMetaDocument, wird diese Methode rekursiv aufgerufen und ihrezugehörigen Meta-Dokumente als Kinder unter dem Vorfahr angehängt.)

• finalize()Die Methode finalize() enthält nur einen Befehl, nämlich storage.disconnect(),um die Verbindung zum Speichersystem nach dem Aufbau der Baumstruktur zuschließen und die zugehörige Variable auf null zu setzen.

Im Sequenzdiagramm 3.2 sind die oben beschriebenen Methoden veranschaulicht dar-gestellt.


Abbildung 3.2: UML Sequenzdiagramm: Preprocessor


3.2 Datenstrukturen

Die Aufgabe des Moduls Datenstrukturen ist die Unterstützung der Abläufe in den ein-zelnen Algorithmen durch die Bereitstellung grundsätzlicher Funktionalitäten von Cluster-Objekten. Dazu gehören die grundlegende Datenstruktur, die Datenspeicherung und dieBerechnung eines Ähnlichkeitsmaßes auf Basis eines Termgewichts. Daher besteht diesesModul aus den Submodulen

• data - Beinhaltet die grundlegende Datenstruktur, die verantwortlich für die Daten-haltung und für Funktionalitäten von Cluster-Objekten ist.

• storage - Ermöglicht die Speicherung der Datenstrukturen in einem Speichersystem.

• similarity - Besteht aus Ähnlichkeitsmaßen, die bei der Berechnung der Clusterverwendet werden.

• weight - Ist verantwortlich für die Berechnung von Termgewichten, die von Ähnlich-keitsmaßen genutzt werden.

Im Folgenden werden die einzelnen Submodule und ihre Interaktion beschrieben.

3.2.1 grundlegende Datenstruktur

Abbildung 3.3 zeigt ein Klassendiagramm der zur grundlegenden Datenstruktur gehören-den Klassen und ihrer wichtigsten Methoden. Dies sind DataObject, Term, Item, Cluster,MetaDocument und SingletonMetaDocument. Fehlerfälle innerhalb der Datenstrukturenwerden durch eine DataException angezeigt.

DataObject

DataObject (invex.data.DataObject) stellt die Oberklasse aller Datenstruktur-Klassen dar.Sie kapselt alle Methoden des Loggings, sodass der genutzte Logging-Mechanismus mitwenig Aufwand auszutauschen ist.


Abbildung 3.3: Klassendiagramm Datenstruktur


Term

Ein Term (invex.data.Term) besteht aus einer Zeichenfolge (dem eigentlichen Term), derTermhäufigkeit und dem Termgewicht. Die Methoden equals() und hashCode() der Klas-se Object wurden überschrieben, sodass die Zeichenfolge als eindeutige Identifikation einesTerms ausreicht. Dies ermöglicht eine leichte Kontrolle, ob zwei Terme identisch sind odernicht. Dieser Mechanismus wird unter anderem innerhalb der Methode contains() einerCollection und bei HashMaps genutzt.

Um ein leichtes Sortieren einer Liste von Termen zu ermöglichen, implementiert Termdas Interface Comparable. Dabei ist ein Term „kleiner“ als ein anderer, wenn sein Ge-wicht höher ist. Somit ergibt sich eine absteigende Sortierreihenfolge beim Aufruf vonCollections.sort(). Term stellt, außer den schon genannten Methoden, Zugriffsmetho-den auf den eigentlichen Term, seine Häufigkeit und sein Gewicht zur Verfügung.

Item

Ein Item (invex.data.Item) ist das allgemeinste clusterbare Objekt. Es beinhaltet eineBeschreibung über sich selbst, eine Liste der höchstgewichtigsten Terme, die dazugehörigeeuklidische Norm (siehe auch 3.2.3 CosineMeasure) sowie die Anzahl der Dokumente, diedurch dieses Item abgedeckt werden. Außer den Zugriffsmethoden für diese Attribute sinddie Methoden distance(), truncate() und generateProfile() in Item implementiert.

• distance()Bestimmt auf Basis des in der Konfigurationsdatei (siehe Kapitel 3.5) angegebenenÄhnlichkeitsmaßes die Ähnlichkeit zwischen diesem und einem weiteren Item. DasÄhnlichkeitsmaß, z.B. das Kosinusmaß (Klasse CosineMeasure), ist für alle Itemsidentisch und wird nur ein Mal instantiiert. Je kleiner die Distanz zweier Items ist,desto größer ist ihre Ähnlichkeit.

• truncate()Sortiert die gespeicherten Terme und schneidet die Liste der Terme ab einem in derKonfigurationsdatei anzugegebenen Wert k ab. Zusätzlich werden alle Terme abge-schnitten, die das gleiche Gewicht haben wie der Term k. Dadurch kann es passieren,dass nach dem Abschneiden keine Terme mehr vorhanden sind. In diesem Fall wirdso abgeschnitten, dass genau k Terme vorhanden sind.


• generateProfile()Die euklidische Norm des Termgewichtvektors wird beim ersten Zugriff oder bei expli-zitem Aufruf der Methode generateProfile() auf Basis der Terme mit dem höchs-ten Gewicht bestimmt.

Damit alle Unterklassen, insbesondere MetaDocument und SingletonMetaDocument,ein eindeutiges Identifikationsmerkmal (eine Zeichenkette) verwalten können, wird dieseMöglichkeit direkt in Item geschaffen und die dazugehörige equals() Methode implemen-tiert.

Cluster

Die Klasse Cluster (invex.data.Cluster) besteht aus einer Menge von Items, den „Kindern“des Clusters, sowie aus Beispieldokumenten (Items), die repräsentativ für dieses Clustersind. Zusätzlich besitzt Cluster alle Funktionalitäten von Item, d.h. die Klasse erbt vonItem. Cluster überschreibt die Methode generateProfile(), wodurch die Beschreibung,die wichtigsten Terme, die Beispieldokumente, die euklidische Norm sowie die Anzahl derDokumente auf Basis der Kinder bestimmt werden. Außerdem bietet Cluster Methodenzum Berechnen des Zentroiden und des Medoiden. Ein Zentroid wird berechnet, indemder Durchschnitt der häufigsten Terme aller Kinder gebildet wird und diese Liste auf diegewünschte Anzahl an Termen abgeschnitten wird. Ein Medoid ist das Item mit geringstemAbstand, d.h. größter Ähnlichkeit, zum Zentroiden.

MetaDocument

Ein MetaDocument (invex.data.MetaDocument) ist ein spezielles Cluster. Ein wesentli-cher Unterschied zu Cluster besteht darin, wie auf die Kinder bzw. Beispieldokumentezugegriffen wird. Beim Cluster werden die wirklichen Item-Objekte gespeichert, im Falledes MetaDocument nur die jeweiligen IDs. Dies ist möglich, da ein Metadokument nur Ob-jekte vom Typ MetaDocument bzw. SingletonMetaDocument, die eindeutige IDs besitzen,verwalten kann. Beim Zugriff auf die verwalteten Items werden diese aus dem genutz-ten Speichersystem (Storage) geladen. Bei Bedarf wird einem neuen MetaDocument eineeindeutige ID vom Speichersystem zugewiesen.


SingletonMetaDocument

Ein SingletonMetaDocument (invex.data.SingletonMetaDocument) stellt einen Wrapperfür die wirklichen zu clusternden Dokumente dar. Beim Erzeugen eines solchen Objektswird die Record-ID eines Records übergeben. Beim Aufruf der generateProfile() Metho-de wird mit Hilfe einer RecordFactory (invex.record.RecordFactory) der Record erzeugt.Dieser Record stellt dabei eine abstrakte Darstellung des zu clusternden Dokuments dar,Zugriffsmethoden werden durch das Interface Record (invex.record.Record) bereitsgestellt.Darauf folgend werden die Terme aus denen der Record besteht (inkl. ihrer Häufigkeit) so-wie eine Beschreibung dieses Records bestimmt. Die übergebene eindeutige Record-ID wirdzur eindeutigen Identifikation eines SingletonMetaDocuments genutzt.

DataException

Fehlerfälle innerhalb der Datenstrukturen werden, wie schon weiter oben angesprochen,durch eine DataException (invex.data.DataException) angezeigt. DataException ist eineRuntimeExcpetion, so dass sie nicht explizit abgefangen werden muss und in den meistenFällen zum Abbruch der Verarbeitung führt.

3.2.2 Speichersystem

Das Speichersystem ist durch das Interface Storage gekapselt. Dieses stellt die benö-tigten Methoden zum Öffnen und Schließen einer Verbindung zum Speichersystem so-wie Methoden zum Speichern von Items und damit auch von MetaDocumenten sowieSingletonMetaDocumenten zur Verfügung. Jedes Speichersystem, das potenziell genutztwerden können soll, muss dieses Interface implementieren. Abbildung 3.4 zeigt das zumModul Speichersystem gehöhrende Klassendiagramm.

Storage

Wie schon weiter oben erwähnt, stellt das Interface Storage (invex.data.storage.Storage)die benötigten Methoden zum Zugriff auf ein Speichersystem zur Verfügung. Dies sind imeinzelnen:

• connect()Stellt eine Verbindung zum Speichersystem her.


Abbildung 3.4: Klassendiagramm Speichersystem

• disconnect()Schließt eine geöffnete Verbindung zum Speichersystem.

• save(Item)Speichert ein Item im Speichersystem ab.

• load(String)Lädt ein Item mit bestimmter ID aus dem Speichersystem.

• setRoot(Cluster)Speichert das Root-Element des Baumes im Speichersystem ab. Das Root-Elementmuss dabei vom Typ Cluster sein.

• getRoot()Lädt ein bereits abgespeichertes Root-Element.

• generateID()Generiert eindeutige IDs.

• purge()Löscht alle gespeicherten Daten aus dem Speichersystem.


StorageFactory

Um auf ein konkretes Speichersystem zuzugreifen, wird die StorageFactory genutzt (in-vex.data.storage.StorageFactory). Diese verwaltet das Singleton Storage und erzeugt beimersten Zugriff ein neues Storage-Objekt. Das genutzte Storage kann in der Konfigurations-datei (3.5) angegeben werden. Zur Auswahl stehen zur Zeit das Datenbank-Storage unddas Hauptspeicher-Storage.

AbstractStorage

Das AbstractStorage (invex.data.storage.AbstractStorage) bildet die Oberklasse der bis-her implementierten Storages. Diese Klasse übernimmt die Generierung der eindeutigenIDs. Diese sind allerdings nur während eines Programmdurchlaufs eindeutig, da sie durcheinen statischen Zähler bestimmt werden.

Database

Die Klasse Database (invex.data.storage.Database) speichert Metadokumente und Single-tonmetadokumente in einer Datenbank. Diese kann durch die im Anhang A beschriebenenKonfigurationswerte angegeben werden. Die genutzten Tabellen in der Datenbank zeigtAbbildung 3.5.

Abbildung 3.5: Tabellen in der Datenbank


In der Tabelle Item werden allgemeine Informationen zu den einzelnen Items gespei-chert. Dazu gehören die Beschreibung und die Anzahl der Dokumente, die dieses Itemabdeckt. Die zu einem Item gehörenden Terme werden inkl. Häufigkeit und Gewicht inder Tabelle FrequentTerms abgelegt. Dazu kommt noch die Anzahl der Dokumente imCluster, die den Term beinhalten (fc). Dieser Wert kann später für die Berechnung vonTermgewichten genutzt werden. Die Beziehungen eines Items zu seinen Kindern bzw. Bei-spieldokumenten werden in den Tabellen Children und ExampleDocuments gespeichert.Beim Aufruf der Methode connect() wird die Verbindung zur Datenbank hergestellt undüberprüft, ob die genannten Tabellen existieren. Falls nicht, werden diese automatisch er-zeugt.Beim Speichern (Methode save()) wird zunächst unterschieden, ob das zu speicherndeItem ein Metadokument oder Singletonmetadokument ist. Im Falle eines Metadokumentswerden die zugehörigen allgemeinen Informationen, die Terme, die Kinder sowie die Bei-spieldokumente gespeichert. Da Singletonmetadokumente keine Kinder und keine Beispiel-dokumente besitzen, werden lediglich die allgemeinen Informationen und die Terme ge-sichert. Vor dem Speichern eines Items wird eine evtl. vorhandene alte Version aus derDatenbank gelöscht und dann die neue Version gespeichert. Damit können durch das mehr-fache Speichern eines Items keine Inkonsistenzen entstehen.Wenn ein Item geladen werden soll, wird auf Basis des Vorhandenseins von Kindern in derTabelle children entschieden, ob es sich um ein Metadokument bzw. um ein Singleton-metadokument handelt. In jedem Fall wird eine neue Instanz des jeweiligen Typs erzeugtund die entsprechenden Daten aus der Datenbank gelesen. Die Methode load() gibt dasneu erzeugte und mit Daten bestückte Item zurück.

MemoryStorage

Das MemoryStorage (invex.data.storage.MemoryStorage) stellt alle von Storage geforder-ten Methoden zur Verfügung. Dabei werden die Objekte in einer HashMap und somit nichtpersistent gespeichert. Diese Klasse dient daher nur zu Testzwecken.

StorageException

Fehler, die während der Verarbeitung innerhalb einer Speichersystem-Klasse auftreten,werden durch eine StorageException (invex.data.storage.StorageException) angezeigt.


StorageException erbt wie DataException von RuntimeExcpetion.

3.2.3 Ähnlichkeitsmaß

Ähnlichkeitsmaße müssen das Interface SimilarityMeasure implementieren, um auch hierdie Austauschbarkeit zu garantieren. Die Struktur des Submoduls ist in Abbildung 3.6gezeigt.

Abbildung 3.6: Klassendiagramm Ähnlichkeitsmaß

SimilarityMeasure

Das Interface SimilarityMeasure (invex.data.similarity.SimilarityMeasure) besteht nuraus einer Methode, nämlich der Methode similarity(). Diese bestimmt die Ähnlichkeitvon einem Item zu einem weiteren Item. Allgemein gilt: Je kleiner die Distanz zweier Itemsist, desto größer ist ihre Ähnlichkeit.

SimilarityMeasureFactory

Auch in diesem Submodul (invex.data.similarity.SimilarityMeasureFactory) wird eine Fac-tory genutzt, um ein Ähnlichkeitsmaß auf Basis der Konfigurationsdatei zu instantiieren.Das Ähnlichkeitsmaß ist dabei ebenfalls ein Singleton und ist somit für alle Items identisch.


CosineMeasure

CosineMeasure (invex.data.similarity.CosineMeasure) berechnet das Kosinusmaß zweierItems auf Basis der Termgewichte (Submodul Termgewicht 3.2.4) ihrer Terme. Dazu wer-den die euklidischen Normen der Termgewichtvektoren der Items genutzt. Damit der Be-griff der Distanz bei maximaler Unähnlichkeit (Kosinusmaß beträgt -1) anschaulich bleibt,wird das Kosinusmaß auf das Intervall [0, 1] abgebildet.

3.2.4 Termgewicht

Das Modul Termgewicht ist analog zum Modul Ähnlichkeitsmaß aufgebaut (siehe Abbil-dung 3.7). Zur Zeit sind zwei unterschiedliche Termgewichte implementiert: NormalWeightund RelativeInformationWeight.

Abbildung 3.7: Klassendiagramm Termgewicht

Weight

Im Interface Weight (invex.data.weight.Weight) wird die Methode generateWeights() de-finiert. Diese generiert die Termgewichte der Terme einer gegebenen Menge von Items. DerRückgabewert ist eine Menge von Items bei deren Termen das Termgewicht neu berechnetwurde.

WeightFactory

Die WeightFactory (invex.data.weight.WeightFactory) dient dazu, ein Weight auf Basisder Konfigurationsdatei siehe 3.5) zu instantiieren.


NormalWeight

Beim NormalWeight (invex.data.weight.NormalWeight) wird für jeden Term die Häufigkeitals Gewicht angenommen. Daher besteht das Generieren hierbei nur aus dem Umkopierendieses Werts.

RelativeInformationWeight

Das RelativeInformationWeight (invex.data.weight.RelativeInformationWeight) berech-net die Termgewichte auf Basis einer gegebenen Kollektion. Bei der Berechnung muss be-rücksichtigt werden, dass sich die Kollektionen durch wiederholtes Scatter/Gather ständigverändern können. Dies ist durch die Auswahl einiger Dokumente (Scatter) aus der aktuel-len Kollektion und dem Bilden einer neuen Basis-Kollektion (Gather) begründet. Um dasRelativeInformationWeight zu berechnen, wird daher der Informationsgehalt des Termsin dem zugehörigen Cluster in Bezug zum Informationsgehalt des Terms im Rest der (neu-en) Kollektion gesetzt. Dieser Wert wird dann noch mit der Anzahl der Dokumente inder aktuellen Kollektion, die den Term beinhalten, gewichtet. Insgesamt wird also folgendeFormel zur Generierung der Termgewichte genutzt:

fc ·[log

(fc + k

−1

Nc + 1

)− log

(f − fc + 1− k−1

N −Nc + 1

)]

fc =̂ Anzahl der Dokumente im Item, die den Term enthalten(1, falls kein Cluster)Nc =̂ Anzahl der Dokumente im Item(1, falls kein Cluster)f =̂ Anzahl der Dokumente in der aktuellen Kollektion, die den Term enthaltenN =̂ Anzahl der Dokumente in der aktuellen Kollektionk =̂ Anzahl der Items in der aktuellen Kollektion

3.3 Clustering/Scatter

In diesem Kapitel wird eine Kernkomponente des InveX-Werkzeugs, nämlich das ModulClustering, näher erläutert. Dieses Modul stellt Methoden zur Verfügung, die Gruppen(Cluster) aus einer Kollektion von Dokumenten erzeugen. Grundsätzlich wird zwischenzwei Arten von Clustering unterschieden:

• einfaches oder flaches Clustering (Flat Clustering)


• hierarchisches Clustering (Hierarchical Clustering)

Die Clustering-Methoden werden bei jedem Iterationsschritt im InveX-Werkzeug benötigt,um die ausgewählten Dokumente erneut zu gruppieren. Die Routinen werden außerdemzur Erstellung der initialen Partition benötigt.

Bei den einzelnen InveX-Schritten findet das flache Clustering Verwendung, das inAbschnitt 3.3.1 behandelt wird. In Abschnitt 3.3.2 wird das hierarchische Clustering nähererläutert, auf das bei der Erstellung der initialen Partition zurückgegriffen wird.

3.3.1 Flat Clustering

Das Flat Clustering erzeugt eine flache Cluster-Struktur, die generierten Cluster enthaltenalso keine „Untercluster“. Klassen, die Methoden zur Erzeugung eines flachen Clusteringsenthalten, müssen das Interface FlatClustering implementieren. Die Struktur dieses Sub-moduls wird in Abbildung 3.8 veranschaulicht.

Anhand des Diagramms kann man erkennen, dass in diesem Submodul zwei Flat-Clustering-Algorithmen implementiert sind. Hiervon wird allerdings nur Buckshot direktverwendet. AggloClustering dient als Clustersubroutine für Buckshot. Beide Cluster-routinen implementieren das Interface FlatClustering und sind somit leicht austausch-bar. Die FlatClusteringFactory instantiiert unter Verwendung der Konfigurationsdateiein Flat-Clustering-Objekt; tritt hierbei ein Fehler auf, so wird eine Exception vom TypFlatClusteringException ausgelöst.

FlatClustering

Das Interface FlatClustering (invex.clustering.FlatClustering) enthält nur die Methodecluster(). Diese Methode erwartet als Eingabe eine Menge von Objekten vom Typ Itemund liefert eine Menge von Objekten vom Typ Cluster zurück.

AggloClustering

Die Klasse AggloClustering (invex.clustering.AggloClustering) stellt ein agglomerativesClustering auf Basis eines Ähnlichkeitsmaßes (siehe 3.2.3) zur Verfügung. Hierzu wird zu-erst jedes Item durch aufrufen der Methode initialise() zu einem neuen Cluster hinzu-gefügt. Hiernach wird die „Ähnlichkeit“ jedes Clusters zu allen anderen Clustern berechnet


Abbildung 3.8: Klassendiagramm Flat-Clustering


und die beiden ähnlichsten Cluster werden vereinigt. Die Berechnung der Ähnlichkeit findetin der Methode averageSimilarity() statt, die ihrerseits auf die Methode distanceSum()zurückgreift. Im Folgenden werden noch einmal kurz die jeweiligen Methoden beschrieben.

• cluster(Collection)Verwendet die Methoden initialise() und averageSimilarity() um die über-gebene Menge von Items zu „clustern“. Hier werden auch die ähnlichen Cluster zueinem neuen Cluster zusammengefasst. Die Methode liefert eine Menge von Clusternzurück.

• initialise(Collection)Hier wird jedes Item aus der Kollektion zu jeweils einem neuen Cluster hinzugefügt.

• averageSimilarity(Cluster, Cluster)Berechnet die „durchschnittliche Ähnlichkeit“ zweier Cluster und gibt diese an denAufrufer zurück. Hierzu wird die Methode distanceSum() verwendet, an die alleDokumente der beiden Cluster übergeben werden.

• distanceSum(ArrayList)Bestimmt die Summe der Abstände aller Dokumentenpaare.

Buckshot

In der Klasse Buckshot (invex.clustering.Buckshot) wurde ein Clustering-Algorithmus im-plementiert, der auf Basis von Stichproben (Umfang der Stichprobe:

√k · n, wobei k die

gewünschte Anzahl von Clustern und n die Anzahl der Dokumente in der Kollektion dar-stellt) aus einer Dokumentenkollektion Zentren von Clustern generiert. Hierzu verwendetBuckshot eine Clustersubroutine, nämlich ein in der Klasse AggloClustering implemen-tiertes agglomeratives Clustering. Die zufällig ausgewählte Stichprobe wird unter Verwen-dung der Clustersubroutine geclustert, und die Zentren der so entstandenen Cluster werdenausgegeben.

Nachdem die Zentren generiert wurden, werden alle Dokumente durch Aufrufen derMethode assignToNearest() ihrem jeweils nächsten Zentrum zugewiesen. Dieses Verfah-ren macht den Algorithmus im Vergleich zum agglomerativen Clustering schneller, was ihnsomit wesentlich effektiver für die häufig wiederkehrenden InveX-Schritte macht.

Im Nachfolgenden noch eine kurze Beschreibung der wichtigsten Methoden in Buckshot:


• cluster(Collection)Ruft die Methoden getSample(), clusterSubroutine(), assignToNearest() undrefine() auf. Als Ergebnis liefert die Methode k Cluster zurück.

• getSample(Collection)Wählt zufällig eine Menge von Dokumenten vom Umfang

√k · n aus der übergebenen

Kollektion aus und gibt diese zurück.

• clusterSubroutine(Collection)Erhält als Parameter die in getSample() gewählten Dokumente, clustert diese underzeugt eine Menge, die die Zentren dieser Cluster beinhaltet.

• assignToNearest(Collection, Collection)Überprüft den „Abstand“ jedes Dokuments zu den übergebenen Zentren. Jedes Do-kument wird dem Zentrum mit dem kleinsten Abstand zugeordnet.

• refine(Collection)Hier werden die erzeugten Cluster verfeinert. Dazu werden die Zentren der erzeugtenCluster bestimmt und assignToNearest() erneut aufgerufen; diesmal mit den neuermittelten Zentren. Das Ergebnis ist wieder eine Menge von Clustern

FlatClusteringFactory

Die FlatClusteringFactory (invex.clustering.FlatClusteringFactory) instantiiert bei Auf-ruf der Methode getFlatClustering() ein Objekt vom Typ FlatClustering, indem derentsprechende Schlüssel in der Konfigurationsdatei ausgewertet wird. Ist der Schlüssel nichtvorhanden, wird stattdessen defaultmäßig das AggloClustering verwendet.

ClusteringException

Tritt beim Generieren des Objekts in der FlatClusteringFactory ein Fehler auf, wird eineException vom Typ ClusteringException (invex.clustering.ClusteringException) ausge-löst. ClusteringException erbt von RuntimeException.


3.3.2 Hierarchical Clustering

Ein hierarchisches Clustering erzeugt eine Hierarchie von Clustern. Im Gegensatz zumflachen Clustering, bei dem nur disjunkte Cluster auftreten, unterscheidet man hier folgendeClustertypen:

1. disjunkte Cluster

2. Cluster, die in einem größeren Cluster enthalten sind

3. Cluster, die aus der Vereinigung bereits bestehender Cluster gebildet werden

Diese Form des Clusterings findet bei der vorprozessierten Scatter/Gather-Variante Ver-wendung, die in Abschnitt 2.3 näher erläutert wurde. Auf Basis dieser Theorien setztder Preprocessor (siehe 3.1) auf, weshalb dieser nun auch das entsprechende InterfaceHierarchicalClustering (invex.clustering.HierarchicalClustering) implementiert.

3.4 InveX

Dieses Modul besteht lediglich aus der Klasse Invex (invex.Invex), die die primäre Schnitt-stelle zwischen den einzelnen Komponenten und Modulen des InveX-Werkzeugs bildet.Nach dem Start der InveXGUIApplication (invex.gui.InveXGUIApplication), also der gra-fischen Benutzeroberfläche, wird ein Objekt dieses Typs instantiiert. Dabei wird nun auchfestgelegt, welcher Flat-Clustering-Algorithmus verwendet wird, und wie groß die maxi-male Anzahl an Metadokumenten bei den einzelnen InveX-Schritten ist, die tatsächlichgeclustert werden. Außerdem wird hier eine Verbindung zur Datenbank aufgebaut, in derdie Informationen aus dem Präprozessor-Lauf (siehe Abschnitte 2.3 und 3.1) gespeichertsind.

Werden jetzt in der Benutzeroberfläche ein oder mehrere Cluster ausgewählt und derKnopf Gather&Scatter angeklickt, wird die Methode refine() aufgerufen. Hier werdendie ausgewählten Cluster vereinigt, Metadokumente expandiert und die Dokumente er-neut geclustert. Dazu verwendet refine() (in dieser Reihenfolge) die privaten Methodengather(), expand() und scatter(). Eine detailliertere Beschreibung der Arbeitsweisedieser Methoden wird im nachfolgenden Absatz gegeben:


• gather(Collection)Die Methode gather() erzeugt eine Menge mit allen Dokumenten der in der Benut-zeroberfläche ausgewählten Cluster. Die zurückgegebene Menge enthält also Objektevom Typ MetaDocument und SingletonMetaDocument.

• expand(Collection)Danach wird diese Kollektion an die Methode expand() übergeben. Hier wird nundas jeweils größte Metadokument, also das mit den meisten „Kindern“, durch ebendiese Kinder ersetzt. Dies wird so lange wiederholt, bis die Anzahl der Items in derMenge größer oder gleich dem Wert der Variablen maxNumberOfMD (default: 100) ist.Die Methode wird ebenfalls verlassen, wenn alle Objekte in der Menge nur noch vomTyp SingletonMetaDocument sind, also nicht mehr expandiert werden können.

• scatter(Collection)In dieser Methode werden die Dokumente geclustert, die Profile der neu gebildetenCluster generiert, und die Cluster anschließend an den Aufrufer zurückgegeben.

Eine detaillierte Übersicht der Abläufe in diesem Modul findet sich in Abbildung 3.9.

3.5 Konfiguration

Das InveX-Werkzeug besitzt eine Konfigurationsdatei, in der alle Module nach dem Bau-kastenprinzip zusammengesetzt werden können. Die Konfiguration wird von der KlasseConfig verwaltet. Config bietet verschiedene statische Zugriffsmethoden auf die einzelnenKonfigurationswerte. Dies sind

• get(String)Sucht nach dem angebenen Schlüssel und gibt den gefundenen Wert als String zu-rück. Falls kein Wert gefunden wurde, wird null zurückgegeben.

• getBoolean(String)Nutzt get(String) und konvertiert den zurückgegebenen Wert auf einen booleschen-Wert.

• getInteger(String)Nutzt get(String) und konvertiert den zurückgegebenen Wert auf einen integer-Wert.


Abbildung 3.9: Sequenzdiagramm Modul Invex


Zu jeder dieser Methoden existiert eine erweiterte Methode, der zusätzlich ein Default-Wert übergeben werden kann. Falls kein Wert für den Schlüssel gefunden wurde, wirddieser Default-Wert zurückgegeben. Somit ist es nicht nötig, in anderen Klassen das Vor-handensein eines Schlüssel-Wert Paares zu überprüfen. Im Anhang A ist eine kompletteÜbersicht aller Konfigurationswerte zu finden.

Kapitel 4

Beispielsession

In diesem Kapitel wollen wir ein kleines Beispiel vorstellen, um die Arbeitsweise unse-res Werkzeugs zu veranschaulichen. Als Beispielkollektion haben wir ca. 300 Dokumenteaus 3 Kollektionen (Interviews, Literatur und Fotobeschreibungen) ausgewählt. DieDokumente dieser Beispielkollektion wurden in 7 Cluster eingeteilt, wobei 75 Terme proDokument genutzt wurden. Das RelativeInformationWeight wurde hierbei zur Gewich-tung der Terme verwendet.

Klickt man auf den Knopf Scatter/Gather auf der GUI, sieht man auf der linken Seiteinsgesamt 7 initiale Cluster, die jeweils durch die wichtigsten Terme und Beispieldokumentebeschrieben sind. Dies wird in Abbildung 4.1 gezeigt.

Man kann jetzt einen oder mehrere Cluster auswählen. Während der Auswahl siehtman jeweils auf der rechten Seite die zu dieser Auswahl gehörenden Informationen, alsowieder Terme und Beispieldokumente. Abbildung 4.2 zeigt, dass sich die Anzeige auf derrechten Seite dynamisch an die aktuelle Auswahl anpasst. In diesem Fall wurden Cluster3 und 4 ausgewählt. Durch die Anzeige der wichtigsten Terme bekommt man einen Über-blick über die ausgewählten Cluster und kann somit entscheiden, ob diese für das weitereBrowsen geeignet scheinen. Wenn das erste Clustering für die Suche ungeeignet scheint,weil dieses Clustering z.B. unausgewogen ist, können auch einfach alle Cluster ausgewähltund neu geclustert werden. Die neue Aufteilung nach dem Scatter/Gather-Schritt zeigt dieAbbildung 4.3.

Wenn man jetzt auf das Clustering mit 11 Dokumenten klickt und sich ein Beispieldo-kument, z.B. The Semi-Attached Couple, anschauen will, klickt man auf den Link in derDetailansicht. Daraufhin wird die detaillierte Beschreibung im XML-Format gezeigt (Ab-

43

KAPITEL 4. BEISPIELSESSION 44

Abbildung 4.1: Initiale Cluster


Abbildung 4.2: Auswahl zweier Clustering

Abbildung 4.3: Detaillierte Beschreibung eines Clusterings


bildung 4.4). Durch den Undo-Knopf ist es jeder Zeit möglich, einen Scatter/Gather Schrittrückgängig zu machen. Um ganz von vorne zu beginnen, schließt man das Werkzeug undöffnet es wieder. Dadurch wird wieder das initiale-Clustering angezeigt.


Abbildung 4.4: Beschreibung eines Beispieldokumentes im XML-Format

Kapitel 5

Tests und Interpretation

In diesem Kapitel beschäftigen wir uns mit der Evaluierung des nunmehr einsatzberei-ten InveX-Werkzeugs. Dazu stellen wir in den nächsten Abschnitten drei unterschiedlicheTestverfahren und die daraus gewonnen Ergebnisse und Erkenntnisse vor.

Ziel des ersten Testlaufs (Abschnitt 5.1) und der vorherigen, hier nicht näher beschrie-benen Prä-Tests war es, gute Konfigurationswerte zu ermitteln und Fehler in der Softwareaufzudecken. Zusätzlich haben wir bei diesen Testläufen auch auf die Qualität der erzeugtenCluster geachtet, da diese unmittelbar mit der Anzahl der verwendeten Terme (SchlüsselfrequentTermCount) zusammenhängt.

Beim zweiten Testlauf (Abschnitt 5.2) ging es darum, die Leistungsfähigkeit des Präpro-zessors mit den beiden zur Verfügung stehenden Termgewichtungen einzuschätzen.

Im dritten Test (Abschnitt 5.3) haben wir unser Augenmerk auf die Qualität der bei-den verschiedenen Termgewichtungen gelegt. Dazu wurden hier erstmals Meinungen vonPersonen eingeholt, die nicht in direkter Verbindung mit dem Projekt stehen.

5.1 Test 1 (Clusterqualität und Skalierbarkeit)

In diesem Testverfahren wurden die Laufzeiten für den Präprozessor und das Online-Clustering gemessen. Gleichzeitig wurde die Qualität der erzeugten Cluster subjektiv vonuns bewertet und somit die einzelnen Konfigurationseinstellungen in „sinnvolle“ und „wenigsinvolle“ Kombinationen eingeteilt.

Die dem Test zugrunde liegende Dokumentenkollektion bestand aus 1002 Dokumen-ten. Diese Dokumente waren Datensätze mit Dublin-Core Metadaten zu mathematischen

48

KAPITEL 5. TESTS UND INTERPRETATION 49

Veröffentlichungen im XML-Format. Da es sich nur um Metadaten handelte, sind die Da-tensätze im Vergleich zu Volltexten sehr kurz (ca. 100 Terme pro Datensatz). Bei derTermgewichtung wurde das RelativeInformationWeight Verwendet. Wichtige Konfigu-rationseinstellungen, die die oben erwähnten Eigenschaften des InveX-Werkzeugs direkt be-einflussen können, sind die Schlüssel frequentTermCount und desiredNumberOfClusters.Aus diesem Grund wurden für diese Schlüssel verschiedene Werte ausprobiert. Die Wertefür frequentTermCount und desiredNumberOfClusters wurden jeweils paarweise mit-einander kombiniert. Folgenden Konfigurationswerte wurden bei den einzelnen Testläufenverwendet:

• frequentTermCount: 10 / 20 / 50 / 100

• desiredNumberOfClusters: 3 / 5 / 10

• maxNumberOfMD: 100

• exampleDocumentsCount: 3

Für eine Erläuterung der einzelnen Konfigurationsschlüssel siehe Anhang A. Die Resultatedieses Tests können in folgenden Punkten zusammengefasst werden:

• Der Zeitaufwand für das Online-Clustering ist bei jeder Konfigurationseinstellungakzeptabel (unter 3 Sekunden).

• Die guten Werte für das Online-Clustering belegen, dass sich die Vorprozessierungbewährt hat.

• Der Wert 10 bei frequentTermCount ist wenig sinvoll, da hier unausgewogene Clusterentstehen.

• Bei 20 Termen treten häufig noch unausgewogene Cluster auf, 50 bis 100 Termeliefern gute Ergebnisse.

Die Messwerte für den Zeitaufwand des Präprozessors sind in der nachfolgenden Tabelledargestellt:


ClusterTerms 3 5 7

20 11 11 7

50 8 9 12

100 14 15 19

Tabelle 5.1: Zeitaufwand Preprocessor in Minuten

5.2 Test 2 (Zeitaufwand Präprozessor)

Der zweite Test veranschaulicht den Zeitaufwand beim Präprozessor in Abhängigkeit zumverwendeten Weight-Algorithmus. Die beiden Diagramme zeigen diesen Zeitaufwand beijeweils 5 oder 10 generierten Clustern. Als Grundlage für diesen Test diente die schon ausder Beispielsession (Kapitel 4) bekannte Dokumentenkollektion mit ca. 300 Dokumentenaus drei verschiedenen Themengebieten.Die getesteten Algorithmen sind NormalWeight und RelativeInformationWeight.

Abbildung 5.1: Preprocessor - mittlerer Zeitaufwand bei 5 Clustern


In Diagramm 5.1 kann man erkennen, dass sich der Zeitaufwand bei den verschiede-nen Weight-Algorithmen kaum von einander unterscheidet. Die kürzeste Laufzeit für denPräprozessor unter Verwendung des NormalWeight beträgt hier gut vier Minuten, unterVerwendung des RelativeInformationWeight gut viereinhalb Minuten.

Abbildung 5.2: Preprocessor - mittlerer Zeitaufwand bei 10 Clustern

Bei 5.2 sind die Abweichung der Laufzeit schon etwas deutlicher zu erkennen. Diegeringste Laufzeit unter Verwendung von NormalWeight beträgt hier gut fünf Minuten,mit RelativeInformationWeight sind es schon fast sieben Minuten.

Als Schlussfolgerung aus diesen Ergebnissen ergibt sich, dass die Laufzeit des Präpro-zessors beim RelativeInformationWeight zwar immer geringfügig höher ist, dies aberkeine Einschränkung für seine Verwendung beim Präprozessor darstellt, da sich der höhereZeitaufwand im Bereich von maximal 25% bewegt.

Die im Vergleich zu 5.1 abweichenden Ergebnisse lassen sich durch die Verwendungeines neuen Datenbank-Treibers erklären, der eine bis zu 30% höhere Performance erzielte.


5.3 Test 3 (Clusterqualität)

Zusätzlich zur reinen Performance des Werkzeugs, legen wir Wert auf die Qualität der gene-rierten Cluster. So war es für uns interessant zu erfahren, ob sich ein Qualitätsunterschiedbei der Verwendung verschiedener Weight-Algorithmen (in unserem Fall NormalWeightund RelativeInformationWeight) herausstellt.

Um diese Qualität unabhängig bewerten zu können, haben wir eine Reihe von Proban-den gebeten, uns ihren subjektiven Eindruck zur Qualität der Cluster mitzuteilen, sowiesonstige Auffälligkeiten aufzuzeigen. An dem Test nahmen 14 Personen teil, davon 2 weib-lich. 11 der Testpersonen sind im Bereich „Informatik“ tätig bzw. haben Erfahrungen indiesem Bereich, Englischkenntnisse wurden vorausgestzt. Zur Vorbereitung auf diesen Testwurde die schon schon aus der Beispielsession (Abschnitt 4) bekannte Dokumentenkollek-tion ausgewählt. Die Dokumente wurden unter Verwendung des NormalWeight und einemfrequentTermCount von 75 in sieben Cluster aufgeteilt. Die Clusterbeschreibungen der sogenerierten Cluster wurden dann ausgegeben und schriftlich festgehalten. Danach wurdendie Termlisten der einzelnen Cluster mit dem RelativeInformationWeight neu gewichtet,die neuen Clusterbeschreibungen wieder ausgegeben und ebenfalls schriftlich festgehalten.

Den Probanden wurden dann die beiden verschiedenen Clusterbeschreibung der siebenCluster vorgelegt, welche aus 3 Beispieldokumenten sowie den 15 höchstgewichteten Ter-men bestand. Aufgabe war es nun, die Terme anzukreuzen, die für das Verständnis desjeweiligen Clusters nützlich zu sein scheinen, sowie immer eine der jeweils zwei Clusterbe-schreibungen anzukreuzen, die nach Meinung der Probanden „besser“ ist.

Die drei Diagramme 5.3, 5.4 und 5.5 veranschaulichen jeweils das Verhältnis der ange-kreuzten Terme unter Berücksichtigung der ersten 5, 10 und aller 15 Terme.

Wie z.B. in Abbildung 5.3, Cluster 1 zu erkennen ist, ist hier der Anteil der aussagekräf-tigen Terme aus der Gewichtung mit dem RelativeInformationWeight um beinahe 15%höher als beim NormalWeight, was in etwa einem zusätzlich angekreuzten Term bei allenProbanden entspricht. Allgemein ergibt sich, dass das RelativeInformationWeight etwas„bessere“ Terme liefert bzw. relevante Terme höher Gewichtet als das NormalWeight. Aller-dings wurde von den Probanden die subjektive Gesamtqualität der Clusterbeschreibungenfür keine der beiden Gewichtungen deutlich besser bewertet.

Weitere Erkenntnisse aus dem zusätzlichen Feedback von den Probanden waren, dassdas Stemming der Terme schlecht für die Anzeige der Clusterbeschreibung geeignet ist.


Abbildung 5.3: Aussagekräftige Terme unter den ersten 5




Besser wären hier Vollformen oder Phrasen. Im Übrigen wurde uns mitgeteilt, dass dieBeispieldokumente sehr viel mehr Beachtung finden als die einzelnen Terme. Hier wärees sicherlich von Vorteil, mehr Beispieldokumente in die Clusterbeschreibung aufzuneh-men. Dies kann schon ohne weiteres über den Schlüssel exampleDocumentsCount in derKonfigurationsdatei erreicht werden.

Kapitel 6

Zusammenfassung und Ausblick

In diesem Studienprojekt haben wir, motiviert durch die fehlende Indexierung von Do-kumenten im Deep Web, ein Werkzeug für dynamisches, Cluster-basiertes Browsing inXML-Kollektionen entwickelt. Dieses Werkzeug wurde als Framework realisiert, das nachdem Prinzip eines vorprozessierten Scatter/Gather-Verfahrens arbeitet. Die Vorprozessie-rung haben wir durch einen hierarchischen Buckshot-Algorithmus realisiert, mit dem Me-tadokumente erzeugt und in einer Datenbank gespeichert werden. Für die für Buckshotbenötigte Bestimmung von Zentroiden haben wir ein agglomeratives Clustering genutzt.Die Ergebnis-Clusterings des Scatter/Gather werden durch eine zu Daffodil [FKSM02]kompatible Swing-Oberfläche dem Benutzer zur weiteren Verfeinerung angezeigt.

Die aus der Literatur bekannte vorprozessierte Scatter/Gather-Variante, die es erlaubtScatter/Gather-Schritte in einem fast konstanten Zeitaufwand durchzuführen, wurde vonuns durch die Integration verschiedener Termgewichte erweitert.

Durch den modularen Aufbau des Frameworks ist es möglich, auch andere Cluster-Algorithmen, Ähnlichkeitsmaße und Termgewichte einzubinden. Dadurch können verschie-dene Kombinationen von Algorithmen hinsichtlich Clusterqualität und Performance eva-luiert werden.

In mehreren, verschiedenen Testläufen haben wir zunächst sinnvolle Konfigurationswer-te für unser Werkzeug ermittelt, und es anschließend hinsichtlich der Qualität der Clusterund der Laufzeit des Präprozessors untersucht.

Verbesserungswürdig ist die Darstellung der eigentlichen Dokumente, da diese bisherohne Formatierung oder ähnliches angezeigt werden. Aus den Testergebnissen geht hervor,dass für die Darstellung der Cluster die Anzeige der „gestemmten“ Terme nicht sinnvoll

55

KAPITEL 6. ZUSAMMENFASSUNG UND AUSBLICK 56

ist. Daher ist die Anzeige von Vollformen oder sogar Phrasen zu empfehlen. Für die Aus-wahl der Vollformen bzw. Phrasen kann man von einer aus der Kollektion abgeleitetenWahrscheinlichkeitsverteilung ausgehen, um die wahrscheinlichste Vollform bzw. Phraseanzeigen zu können. Außerdem sollte der Benutzer entscheiden können, wie viele Termeund Beispieldokumente für die Beschreibung der Cluster angezeigt werden sollen.

Die Einbettung von InveX in eine Client/Server- oder Peer-to-Peer-Architektur istdenkbar, um ein verteiltes Scatter/Gather durchführen zu können. In diesem Zusammen-hang ist auch die Erweiterung um die Möglichkeit von dynamischen Kollektionen oder auchverteilten Quellen einzuordnen. Hierbei muss besonders auf die Vorprozessierung geachtetwerden, die dann ein dynamisches Ändern der Metadokumente ermöglichen muss.

Die Oberfläche, auf der die Cluster der Dokumente dargestellt werden, wurde kompa-tibel zu Daffodil implementiert. Dadurch ist es leicht, InveX in Daffodil zu integrieren undfür das Clustern von Ergebnislisten unter Berücksichtigung der Anfrage zu nutzen. Dafürkann InveX um das Clustern nach Perspektiven (Autor, Titel, Abstract usw.) erweitertwerden und so den Zugang zu den Ergebnisdokumenten erleichtern. Beispielsweise könntedurch die Autor-Perspektive die Suche nach Dokumenten des gleichen Autors (innerhalbder Suchergebnisse) vereinfacht werden, da sich diese im gleichen Cluster befinden würden.

Das in diesem Studienprojekt entwickelte Basis-Framework für das Browsen in se-mistrukturierten Daten kann in zukünftigen Arbeiten (Diplomarbeiten, Studienarbeitenund Studienprojekte) einfach erweitert werden und für weiterführende Forschungen alsBasiskomponente dienen.

Literaturverzeichnis

[Ber01] Michael K. Berman. Deep Content - The Deep Web: Surfacing Hidden Value,2001. http://brightplanet.com/pdf/deepwebwhitepaper.pdf.

[CKP93] D.R. Cutting, D.R. Karger, and J.O. Pedersen. Constant Interaction-TimeScatter/ Gather Browsing of Very Large Document Collections. In Proceedingsof the Sixteenth Annual International ACM SIGIR Conference on Researchand Development in Information Retrieval, pages 126–134, New York, 1993.http://citeseer.nj.nec.com/cutting93constant.html.

[CPKT92] D.R. Cutting, J.O. Pedersen, D. Karger, and J.W. Tukey. Scatter/gather: ACluster-based Approach to Browsing Large Document Collections. In Procee-dings of the Fifteenth Annual International ACM SIGIR Conference on Re-search and Development in Information Retrieval, pages 318–329, New York,1992. http://citeseer.nj.nec.com/cutting92scattergather.html.

[dGU04] Zentrales Informationssystem der Gesetzlichen Unfallversicherung. Deep Web,2004. http://www.hvbg.de/d/ziguv/service/internet/deepweb.html.

[FKSM02] Norbert Fuhr, Claus-Peter Klas, Andre Schaefer, and Peter Mutschke. Daf-fodil: An Integrated Desktop for Supporting High-Level Search Activities inFederated Digital Libraries. In Research and Advanced Technology for DigitalLibraries. 6th European Conference, ECDL 2002, pages 597–612, Heidelberg etal., 2002. Springer.

[Hei03] Christian Heinisch. Verborgene Informationsquellen im Internet Das InvisibleWeb, 2003. http://www.informationsbewaeltigung.de/edv68heinisch1.pdf.

57

http://brightplanet.com/pdf/deepwebwhitepaper.pdfhttp://citeseer.nj.nec.com/cutting93constant.htmlhttp://citeseer.nj.nec.com/cutting92scattergather.htmlhttp://www.hvbg.de/d/ziguv/service/internet/deepweb.htmlhttp://www.informationsbewaeltigung.de/edv68heinisch1.pdfhttp://www.informationsbewaeltigung.de/edv68heinisch1.pdf

LITERATURVERZEICHNIS 58

[Sac03] Werner Sacher. Bildungstheoretische Aspekte multimedialen Lernens, 2003.http://www-user.tu-chemnitz.de/~koring/quellen/media01/sacher01.

html.

http://www-user.tu-chemnitz.de/~koring/quellen/media01/sacher01.htmlhttp://www-user.tu-chemnitz.de/~koring/quellen/media01/sacher01.html

Anhang A

Übersicht der Konfigurationswerte

Schlüssel Beschreibung

data das Verzeichnis, in dem die als XML-Dateien verfügbaren

Open Archive Records gespeichert sind

schema das Schema der Records

flatClustering der voll-qualifizierende Klassenname des zu nutzenden fla-

chen Clustering, das während der Scatter/Gather genutzt

wird

similarityMeasure der voll-qualifizierende Klassenname des zu nutzenden Ähn-

lichkeitsmaßes

weight der voll-qualifizierende Klassenname des zu nutzenden Term-

gewichts

storage der voll-qualifizierende Klassenname des zu nutzenden Spei-

chersystems

frequentTermCount Anzahl der Terme die ein Item speichern soll

exampleDocumentsCount Anzahl der Beispieldokumente, die ein Cluster besitzen soll

desiredNumberOfClusters Anzahl der Cluster, die ein flaches Clustering generieren soll

maxNumberOfMD maximale Anzahl von Clustern, die während des Scat-

ter/Gather gebildet werden sollen

Tabelle A.1: Konfigurationwerte

59

ANHANG A. ÜBERSICHT DER KONFIGURATIONSWERTE 60


database.driver Klassenname des Datenbanktreibers

database.url Provider-URL

database.user Benutzername

database.password Kennwort

database.connectionTimeout Zeit in Stunden nach der die Verbindung zur Datenbank neu

aufgebaut wird (Default: 12).

Tabelle A.2: Konfigurationwerte Database


buckshot.subroutine Die von Buckshot zu nutzende Cluster-Subroutine

Tabelle A.3: Konfigurationwert Buckshot

EinleitungHintergrundDas Deep WebEigenschaftenArtenDerzeitiger Zugriff

BrowsingArten von BrowsingStatisches vs. Dynamisches Browsing

Vorprozessierte Scatter/Gather-VarianteCluster-HierarchieÄnderung der Scatter/Gather-Browsing-MethodeImplementierungGenerierung der HierarchieMeta-Profile und Truncation

Veränderungsmöglichkeit

Das InveX-WerkzeugPreprocessorDatenstrukturengrundlegende DatenstrukturSpeichersystemÄhnlichkeitsmaßTermgewicht

Clustering/ScatterFlat ClusteringHierarchical Clustering

InveXKonfiguration

BeispielsessionTests und InterpretationTest 1 (Clusterqualität und Skalierbarkeit)Test 2 (Zeitaufwand Präprozessor)Test 3 (Clusterqualität)

Zusammenfassung und AusblickLiteraturÜbersicht der Konfigurationswerte

Yahoo für das Invisible Web - uni-due.de · Kapitel 1 Einleitung Im Studienprojekt „Yahoo für...

Documents

Transcript of Yahoo für das Invisible Web - uni-due.de · Kapitel 1 Einleitung Im Studienprojekt „Yahoo für...