Cluster-basiertes Browsing in Peer-to-Peer-Netzen

Transkript

1 Diplomarbeit Cluster-basiertes Browsing in Peer-to-Peer-Netzen André Nurzenski Diplomarbeit im Vertiefungsgebiet Unterstützende Informationssysteme des Studiengangs Angewandte Informatik an der Universität Duisburg-Essen Betreuer: Prof. Dr. Norbert Fuhr Institut für Informatik und Interaktive Systeme Fachgebiet Informationssysteme

2

3 Kurzfassung Inhalt dieser Arbeit ist die Entwicklung eines Verfahrens für Cluster-basiertes Browsing in Peer-to-Peer-Netzen auf der Grundlage des in [CPKT92] vorgestellten Scatter/Gather- Verfahrens sowie dessen prototypische Implementierung einschlieÿlich einer Evaluierung des so entstandenen Prototyps. Das zu entwickelnde Verfahren soll dabei die beiden wichtigen Faktoren in einer Peer-to-Peer-Umgebung, namentlich Dynamik und Verteiltheit berücksichtigen und auf der in [CKP93] erläuterten vorprozessierten Variante von Scatter/Gather basieren. Zum Einstieg werden zunächst die notwendigen Grundlagen aus den Bereichen Information Retrieval, Text-Clustering und Peer-to-Peer-Netze, sowie ein Auszug aus der aktuellen Forschung im Bereich des Verteilten Information Retrieval vorgestellt. Auf dieser Grundlage werden dann Browsing-Strategien in P2P-Umgebungen auf Basis von Szenarien aus Benutzersicht entwickelt, aus denen dann ein Gesamtkonzept für Browsing in Peer-to-Peer-Netzen hergeleitet wird. Weiterhin werden hier noch die notwendigen Dienste deniert, die zur Realisierung der im Konzept identizierten Funktionen und Strategien benötigt werden. Auf Basis des entwickelten Verfahrens wird dann eine prototypische Implementierung unter Verwendung des in [CLNT04] beschriebenen Browsing-Frameworks InveX-Werkzeug umgesetzt. Dabei werden vorhandene Komponenten für Browsing in P2P-Netzen angepasst, die identizierten Dienste implementiert und in das angepasste Werkzeug integriert. Abschlieÿend wird der so entwickelte Prototyp noch hinsichtlich einiger Faktoren und Problematiken evaluiert, die sich durch den Einsatz in einer P2P-Umgebung ergeben. Dies sind im Einzelnen der Informationsgehalt des aus der gesamten Dokumentenmenge erzeugten Clusterings (globales Clustering), die Bewertung der Retrieval-Qualität bei der automatischen Selektion einer Datenquelle im Netzwerk (Peer) hinsichtlich einer Anfrage, und die Messung des in einer P2P-Umgebung auftretenden Datenaufkommens sowie des damit verbundenen Zeitaufwands für die Erzeugung des globalen Clusterings. i

4

5 Inhaltsverzeichnis Kurzfassung i 1. Einleitung Aufgabenstellung Gliederung dieser Arbeit Grundlagen Information Retrieval Text-Clustering Das Vektorraummodell Verfahren der Termextraktion Scatter/Gather-Browsing Vorprozessiertes Scatter/Gather Das InveX-Werkzeug Peer-to-Peer-Technologie Die Client/Server-Architektur Die Peer-to-Peer-Architektur Reine Peer-to-Peer-Netze Hybride Peer-to-Peer-Netze JXTA TM -Technologie Distributed Information Retrieval Das klassische Information Retrieval Das klassische Distributed Information Retrieval State-of-the-Art bei Information Retrieval in Peer-to-Peer-Netzen Clustering in P2P-Netzen auf Grundlage von Concept Maps Query Routing in P2P-Netzen Das Projekt Pepper Browsing in Peer-to-Peer-Netzen Entwicklung und Verzierung von Browsing-Strategien Ausgangspunkt und Ziele Browsing-Strategien Benutzerbefragung Identizierung der notwendigen Funktionen Ablauf einer Browsing-Sitzung Klassisches Scatter/Gather in P2P-Umgebungen Optimierter Ansatz auf Basis von vorprozessiertem Scatter/Gather iii

6 Inhaltsverzeichnis 3.3. Denition der Browsing-Dienste Browsing-Dienste für Hubs Browsing-Dienste für Peers Prototypische Implementierung Anpassung des InveX-Werkzeugs Komponenten und Module des InveX-Werkzeugs Änderung und Erweiterung betroener Komponenten Implementierung der identizierten Browsing-Dienste Kommunikationsschicht Browsing-Dienste für Hubs Browsing-Dienste für Peers Integration der Dienste in das InveX-Werkzeug Evaluierung Aufbau, Metriken und Ziele in den Testserien Evaluierungsziele Aufbau und Dokumentenbasis OAI-Dokumentenkollektion ACM-Klassizierte-Dokumentenkollektion Durchgeführte Testreihen Evaluierungsmetriken Ergebnisse der Testreihen Informationsgehalt des globalen Clusterings Retrieval-Qualität bei der automatischen Selektion Datenaufkommen und Zeitaufwand Ergebnisanalyse Auswertung Schlussfolgerungen für den Einsatz Zusammenfassung und Ausblick 79 A. Kongurationsschlüssel 83 B. Befragungsbogen für die Nutzerumfrage 85 C. Dokumentenkollektionen 91 D. Evaluierungsergebnisse (tabellarisch) 95 D.1. Globales Clustering D.2. Automatische Selektion von Datenquellen D.3. Datenaufkommen und Zeitaufwand bei Ladevorgängen Abbildungsverzeichnis 107 Tabellenverzeichnis 109 Literaturverzeichnis 111 iv

7 1. Einleitung In unserer heutigen Gesellschaft ist Information 1 ein immer wichtiger werdender Faktor. Nahezu jeder wird im Laufe seines Lebens mit der Situation konfrontiert, ein Informationsdezit ausgleichen zu müssen, sei es im beruichen oder im privaten Umfeld. So repräsentiert schon eine einfache Anfrage an eine beliebige Suchmaschine im Internet ein Informationsdezit und damit verbunden den Versuch, einen Ausgleich dieses Dezits herbeizuführen. Zusätzlich steigt der Bedarf, bei jeder Entscheidung möglichst viel Information in möglichst kurzer Zeit zu erlangen, stetig an. Um nun einem Suchenden eine zentrale Anlaufstelle mit einem möglichst breiten Spektrum an Themen anzubieten, können Dokumente 2, die Information zu den verschiedensten Themen beinhalten, beispielsweise in Bibliotheken abgelegt werden. Um in einem solchen Angebot die gezielte Suche nach bestimmten, thematisch ähnlichen Dokumenten zu ermöglichen, gibt es eine Vielzahl von Ansätzen. So können diese zum Beispiel nach den Themen die sie behandeln gruppiert, und eine Übersicht über die Gruppierung in Katalogen bereitgestellt werden (Universitätsbibliothek). Da aber gerade wissenschaftliche Arbeiten häug versuchen, verschiedene Themen miteinander zu verbinden, ist eine solche Gruppierung in der Regel nicht eindeutig zu gestalten und daher unzureichend. Zur Unterstützung eines Suchenden müssen diesem also leistungsfähige Werkzeuge zur Verfügung gestellt werden, die die Aufgabe der Filterung der gesuchten Information aus dem gesamten Informationsbestand automatisiert vornehmen können. Mit den daraus resultierenden Aufgaben und Problematiken beschäftigt sich das Gebiet des Information Retrieval (IR). Hier werden Modelle und Verfahren entwickelt, die einen Suchenden bei seiner Suche in Informationsquellen unterstützen sollen. Eine Informationsquelle wird häug durch ein Informationssystem (IS) realisiert. Ein solches IS übernimmt dabei die Verwaltung der Information, d.h. die Repräsentation, die Speicherung und die Organisation. Zusätzlich umfasst die Aufgabe von IR auch den Zugri auf Information [SM83a]. Werden in einem IS beide Bereiche, also Verwaltung und Zugri realisiert, so spricht man von einem Information- Retrieval-System (IRS). In den letzten zehn Jahren hat das Internet immer mehr an Bedeutung gewonnen. Hierdurch ist es möglich geworden, Information abzurufen, die sich an praktisch jedem beliebigen Ort weltweit benden kann. Eine räumliche Beschränkung bei der Suche und Beschaung von Information ist also faktisch nicht mehr vorhanden. Auch hat jede Person mit Zugang zum Internet die Möglichkeit, eigene Ressourcen für alle anderen Teilnehmer im Netz anzubieten. In diesem Zusammenhang ist seit einiger Zeit der Begri des Peer-to-Peer-Netzes (P2P-Netzes) häug anzutreen. P2P-Netze sind dabei spontane Verbindungen von Clients, denen eine zentrale Instanz (ein zentraler Server) fehlt. In solchen Netzen können die angeschlossenen Systeme 1 Da Information keine exakt quantizierbare Gröÿe ist, gibt es auch den Plural Informationen nicht. Es kann nur zwischen mehr oder weniger Information unterschieden werden. [Fuh04] 2 Im weiteren wird nicht mehr zwischen einzelnen Medien unterschieden, sondern beispielsweise Bücher, Zeitschriften, Zeitungsberichte, Web-Seiten, aber auch Audio- oder Viedoaufzeichnungen als Dokumente bezeichnet. 1

8 1. Einleitung beliebige Ressourcen mit den anderen Teilnehmern im Netz teilen. Beispiele für P2P-Netze, in denen beliebige Computerdateien angeboten werden können, sind Gnutella, KaZaa und edonkey. Soll in einem P2P-Netz einen inhaltliche Suche in Dokumenten angeboten werden, so müssen auch hier dem Suchenden unterstützende Verfahren wie bei einem IRS zur Verfügung stehen. Solche Verfahren können Suche und/oder Browsing realisieren. Bei der Suche in einem Dokumentenbestand setzt ein Suchender eine Suchanfrage an das IRS ab und erhält eine vom System generierte Rangordnung von Dokumenten. In dieser Rangordnung sind die Dokumente nach ihrer Relevanz zur Anfrage sortiert, wobei relevantere Dokumente an vorderster Stelle stehen. Ein Beispiel für ein solches IRS ist die Web-Suchmaschine Google 3. Browsing hingegen erlaubt einem Suchenden, in der angebotenen Dokumentenmenge strukturiert zu navigieren, und ermöglicht so ein exploratives Vorgehen bei der Suche nach relevanten Dokumenten. Vorteil hierbei ist, dass keine initiale Suchanfrage an das System gestellt werden muss. Ein einfaches Beispiel hierfür ist der Online-Dienst Yahoo! 4, der ein manuell gepegtes Web-Verzeichnis anbietet, in dem Web-Seiten nach den von ihnen behandelten Themen gruppiert sind. Für Browsing kann aber auch das Verfahren des sog. Dokumenten-Clustering zum Einsatz kommen. Hierbei werden Dokumente automatisch nach ihrer Ähnlichkeit (basierend auf vorher festgelegten Kriterien) in Cluster (deutsch: Gruppen) zusammengefasst, und so eine Dokumentenstruktur erzeugt Aufgabenstellung Im Projekt Pepper [Pep04] werden Peer-to-Peer-Architekturen für die föderierte Suche in komplexen digitalen Bibliotheken entwickelt. Zusätzlich zur Suche ist auch eine Browsing- Funktionalität wünschenswert. Im Praxisprojekt Invisible Web [CLNT04] wurde ein Cluster-basiertes Browsing-Werkzeug für beliebige XML-Kollektionen 5 entwickelt. Dabei wurde eine vorprozessierte Variante des Scatter/Gather-Algorithmus [CKP93] verwendet, die die jeweilige Kollektion vor dem Browsing oine als Cluster-Hierarchie aufbereitet. Das Browsing geschieht dann gröÿtenteils auf komprimierten Darstellungen (Prolen) von Dokumenten-Clustern, anstatt auf der Dokumentenmenge selbst. Im Rahmen dieser Diplomarbeit soll Scatter/Gather-Browsing für ein Peer-to-Peer-Netz umgesetzt werden. Clustering-Algorithmen und ein Scatter/Gather-Werkzeug sind schon vorhanden. Es fehlt ein Verfahren, um Cluster von verschiedenen Knoten einzusammeln und daraus eine Gesamtdarstellung zu generieren, sowie die Möglichkeit, eigene, lokale Cluster zu exportieren Gliederung dieser Arbeit Zur Lösung der Aufgabenstellung und der in diesem Zusammenhang aufgedeckten Problematiken gliedert sich diese Arbeit in die Kapitel Grundlagen, Browsing in Peer-to-Peer- Netzen, Prototypische Implementierung und Evaluierung

9 1.2. Gliederung dieser Arbeit Grundlagen Im Kapitel Grundlagen werden die dieser Arbeit zu Grunde liegenden Technologien und Verfahren detailliert beschrieben. Dadurch soll das zum Verständnis der weiteren Kapitel benötigte Basiswissen vermittelt werden. Hier werden unter anderem das verwendete Retrieval-Modell, das verwendete Browsing-Verfahren sowie Details über P2P-Netze allgemein und eine konkrete P2P-Architektur beschrieben. Weiterhin wird hier ein kurzer Überblick über den aktuellen Stand der Forschung zum Thema Verteiltes Information Retrieval gegeben. Browsing in Peer-to-Peer-Netzen Nach der Vermittlung des notwendigen Basiswissens wird in diesem Kapitel ein Konzept für Browsing in Peer-to-Peer-Netzen erarbeitet. Dabei werden zunächst auf Basis des erweiterten Systemverhaltens denkbare Browsing-Szenarien vorgestellt, die auch im weiteren zur Identizierung der zum Browsing notwendigen Funktionalitäten eingesetzt werden. Hierbei werden auch die auftretenden Problematiken berücksichtigt und Lösungsansätze vorgestellt. Im weiteren werden dann die allgemeinen Funktionen in konkreten Diensten umgesetzt, die Browsing in P2P-Netzen ermöglichen sollen. Prototypische Implementierung Basierend auf dem im vorigen Kapitel vorgestellten Konzept wurde ein funktionsfähiger Prototyp einer Peer-to-Peer-Browsing-Software umgesetzt. Dabei werden zunächst die durchgeführten Anpassungen an dem als Basis für die Implementierung verwendeten InveX-Werkzeugs erläutert. Anschlieÿend wird auf die Implementierungsdetails der einzelnen Funktionen dieses Prototyps eingegangen. Zum Abschluss erfolgt noch eine Beschreibung der Vorgehensweise bei der Integration des Prototyps in das InveX-Werkzeug. Evaluierung Im letzten Teil dieser Arbeit wurde der Prototyp noch hinsichtlich der im Verlauf der Konzeptentwicklung aufgeworfenen Fragen und Problemstellungen evaluiert. Die Tests wurde dabei mit unterschiedlichen Dokumentenkollektion in zwei verschiedenen Testumgebungen durchgeführt. Der Fokus der Evaluierung lag dabei auf der Analyse der generierten Gesamtübersicht auf den Hubs, hinsichtlich ihrer Repräsentation der im Netzwerk angebotenen Dokumentenkollektionen. Weiterhin wurden noch die im Rahmen des Konzepts herausgearbeiteten Strategien aus Information-Retrieval-Sicht bewertet sowie auch die durch den Peer-to-Peer-Ansatz enstehenden Datenübertragungen berücksichtigt. 3

10

11 2. Grundlagen Bevor auf das Konzept des Cluster-basierten Browsings in Peer-to-Peer-Netzen eingegangen wird, sollen in diesem Kapitel zunächst einige essentielle Grundkenntnisse vermittelt werden. Ausgehend von diesen Basis-Techniken kann dann zum Konzept und zur prototypischen Implementierung übergegangen werden. Dabei wird zu Beginn erst einmal der grundlegende Aufgabenbereich von Information Retrieval erläutert sowie auf die Zugrismöglichkeiten eingegangen, die einem Suchenden am Ausgangspunkt seiner Suche zur Verfügung stehen. Im weiteren wird dann das Prinzip des Dokumenten-Clusterings beschrieben und ein Verfahren für Browsing in Dokumentenkollektionen vorgestellt. Zum Abschluss werden dann der Aufbau und generelle Eigenschaften von Peer-to-Peer-Netzen angesprochen sowie einige aktuelle Ansätze zum Thema Distibuted Information Retrieval erläutert Information Retrieval Wie schon in der Einleitung kurz angesprochen, beschäftigt sich das Gebiet des Information Retrieval (IR) mit der Entwicklung von Verfahren und Methoden zur Unterstützung eines Suchenden beim Zugri auf Information. Traditionell wird dabei die Suche in groÿen Textbeständen betrachtet, die sich mit Ausnahme von Eigennamen stets auf Textinhalte bezieht [Fuh93]. IR kann in diesem Zusammenhang also als inhaltliche Suche in Texten interpretiert werden [Fuh04]. Diese Interpretation gibt zwar nur einen Teilbereich des IR wieder, ist aber als Grundlage für diese Arbeit ausreichend. Eine detaillierte Beschreibung aller Einsatzgebiete von IR ist in [Fuh04] zu nden. Im Gegensatz zur Suche in reinen Datenbanksystemen, die auf jede Anfrage stets eine korrekte und vollständige Antwort liefern, müssen beim IR, bedingt durch die inhaltliche Suche, die beiden Faktoren Vagheit und Unsicherheit berücksichtigt werden [Fuh93]. Vagheit bezieht sich dabei auf Anfragen an ein System und bedeutet, dass ein Suchender sein Informationsbedürfnis in der Regel nicht vollständig oder korrekt (nur vage) ausdrücken kann. So ist meist ein Mangel an Kenntnis der Fachbegrie eine Ursache für unvollständige Anfragen. Ein System liefert daher auf eine vage Anfrage meist sehr viele und für den Anwender wenig interessante Dokumente zurück. Die Folge ist, dass mehrere Anfragen an das System gestellt werden müssen, wobei die Anfragen entweder vom Anwender selbst oder vom System aufgrund einer vom Anwender abgegebenen Bewertung angepasst werden. Suche kann also auch als iterativer Prozess interpretiert werden, wobei die Anfrage aufgrund der durchgeführten Anpassungen bei jedem Iterationsschritt schärfer im Bezug zum Informationsbedürfnis wird. [Fuh04]. Der Faktor Unsicherheit (oder auch Unvollständigkeit) bezieht sich auf die Objektrepräsentation des verwendeten Systems. Diese Problematik wird deutlich, wenn beispielsweise Textdokumente, die Homographen 1 oder Polyseme 2 enthalten, betrachtet werden. Hier kann durch 1 Verschieden gesprochene Wörter mit gleicher Schreibweise - Tenor: Sänger / Ausdrucksweise [Fuh04] 2 Wörter mit mehreren Bedeutungen - Bank: Sitzgelegenheit / Geldinstitut [Fuh04] 5

12 2. Grundlagen eine unzureichende Repräsentation nicht eindeutig auf die inhaltliche Bedeutung geschlossen, und somit fehlerhafte Antworten produziert werden [Fuh04]. Einem Suchenden müssen daher leistungsfähige Systeme zur Verfügung gestellt werden, welche die oben angesprochenen Problematiken hinsichtlich einer inhaltlichen Suche berücksichtigen und dem Anwender unterstützende Funktionalitäten anbieten. Information-Retrieval-Systeme Die zentrale Anlaufstelle für einen Suchenden bildet dabei ein Information-Retrieval-System (IRS). Ein solches System kann grob in zwei Komponente unterteilt werden. Die erste Komponenten bzw. die erste Stufe eines IRSs bildet das Informationssystem (IS). Im IS sind die zu verwaltenden Objekte bzw. Metadaten 3 über diese abgelegt. In einer digitalen Bibliothek nden sich beispielsweise vollständige Objekte wie etwa digitalisierte Bücher, Zeitschriften oder wissenschaftliche Dokumente, wobei das IS einer echten Bibliothek häug nur Metadaten des eingelagerten Dokumentenbestands beinhaltet. Die Menge aller in einem IS verwalteten Objekte bezeichnet man häug als Kollektion [Fuh93]. Da in digitalen Bibliotheken in der Regel nur Dokumente abgelegt werden, spricht man in diesem Zusammenhang von Dokumentenkollektionen. Ein IS kann z.b. durch eine Datenbank (DB) realisiert werden, da eine DB die zur Verwaltung notwendige Funktionalität bereitstellt. Dies umfasst die Bereiche Repräsentation, Organisation und Speicherung der Information [Cho04a]. In einem solchen IS wäre nun lediglich eine Suche auf der Ebene der Daten möglich. Dazu müsste ein Suchender bereits essentielle Details wie etwa Titel, Autor etc. eines für ihn interessanten Dokuments kennen. Die zweite Komponenten eines IRSs ist daher für den inhaltlichen Zugri auf die im IS abgelegte Information zuständig. In dieser Komponente sind also die im IR entwickelten Verfahren realisiert. Hier werden nun zwei grundlegende Zugrisverfahren unterschieden, mit denen eine inhaltliche Suche in der auf dem System abgelegten Information möglich ist. Zum einen ist dies die Suche, zum anderen das Browsen (deutsch: stöbern) in der verwalteten Kollektion. Zur Verdeutlichung der Arbeitsweise und der Unterschiede beider Zugrisverfahren werden diese im folgenden Abschnitt im Detail vorgestellt. Suche Bei einer Suche erwartet das IRS als Benutzerinteraktion die Eingabe einer Suchanfrage, die das Informationsbedürfnis des Suchenden repräsentiert. Innerhalb des Systems bendet sich die Information in Form von Objekten (beispielsweise Web-Seiten) in einer vom System verarbeitbaren Repräsentationsform. Wird nun eine Anfrage abgesetzt, so wird diese in dieselbe Repräsentationsform wie die gespeicherten Objekte umgewandelt und mit diesen verglichen. Als Ergebnis erhält der Suchende eine Liste mit bewerteten Objekten, wobei die Objekte aufgrund ihrer Bewertung in der Liste sortiert sind. Hoch bewertete Objekte stehen so in der Liste sehr weit oben, wo hingegen niedrig bewertete Objekte am Ende der Liste zu nden sind. Wie schon oben angesprochen, wird dieses Verfahren in der Regel mehrfach wiederholt, so dass Suche als ein iterativer Prozess angesehen werden kann. Die Suchmaschine Google ist ein Beispiel für ein IRS, das als Zugrisverfahren auf seinen Informationsbestand (nämlich eine Kollektion von Web-Seiten) das Verfahren der Suche anbietet. Als Anfrage werden hier Suchbegrie eingegeben, die das Informationsbedürfnis des Suchenden beschreiben. Das Ergebnis einer Anfrage ist eine Liste mit Web-Seiten, die dieser Anfrage am ähnlichsten (also am ehesten relevant) sind. 3 Metadaten sind Beschreibungen von Objekten und beinhalten beispielsweise Titel, Autor(en), Erscheinungsjahr und einen inhaltliche Zusammenfassung (Abstract). 6

13 2.2. Text-Clustering Browsing Beim Browsing präsentiert das IRS dem Suchenden eine strukturierte Übersicht über alle im System verwalteten Objekte. Als Benutzerinteraktion wird hier die Auswahl einer interessant erscheinenden Teilmenge erwartet, die ein Anwender nach dem Betrachten der Übersicht als für sich relevant einstuft. Da hier keine Anfrageformulierung erforderlich ist, entfällt das Problem der Vagheit. In der Regel sind mehrere Schritte bis zum Erreichen der gewünschten Information erforderlich, bzw. kann auch hier eine Anpassung des Informationsbedürfnises vorgenommen werden, weshalb Browsing ebenfalls als iterativer Prozess interpretiert wird. Browsing kann dazu verwendet werden, sich einen Überblick über das gesuchte Gebiet zu verschaen und wird deshalb häug als Ergänzung zur Suche verwendet. Der Aufbau einer solchen Struktur kann dabei entwender manuell, beispielsweise durch Experten, oder automatisch vom System erfolgen. Der Vorteil der erstgenannten Vorgehensweise besteht darin, das durch die manuelle Zuordnung eine genaue Einschätzung des Inhalts eines Objekts vorgenommen wurde und das Problem der Unsicherheit weitestgehend vermieden wird [Cho04a]. Beispiele für solche manuell erzeugten Strukturen sind das Web-Verzeichnis von Yahoo! und die ACM-Klassikation 4. Bei der ACM-Klassikation werden Dokumente mit informatischem Hintergrund nach Themen gruppiert. Bei Yahoo! sind Web-Seiten jeweils einem Begri zugeordnet, die bis zur ersten Ebene des Verzeichnisses selbst auch Oberbegrien zugeordnet sind. So ist beispielsweise die Suche nach Web-Seiten zum Thema Rennfahrer in der Formel Eins intuitiv durchzuführen: Sport - Motorsport - Formel Eins - Rennfahrer. Da die Erzeugung und die manuelle Pege einer solchen Struktur ab einer gewissen Datenmenge sehr aufwändig und damit kostenintensiv ist, bieten sich für solche Fälle automatisch erzeugte Strukturen an. Bei diesem Ansatz wird die Struktur anhand von vorher festgelegten Kriterien vollständig vom System generiert. Eine solche Struktur kann beispielsweise aus gruppierten Objekten bestehen, wobei als Gruppierungskriterium die inhaltliche Ähnlichkeit berücksichtigt wird. Für diese Aufgabe kann das sog. Dokumenten-Clustering verwendet werden. Desweiteren kann beim Brwosing noch zwischen statischem und dynamischem Browsing unterschieden werden. Beim statischen Browsing ist die Struktur statisch und unabhängig von den Benutzereingaben aufgebaut. Ein Beispiel für eine solche statische Struktur ist wiederum das Web-Verzeichnis von Yahoo!. Ein Nachteil des statischen Aufbaus ist es, dass bei einer Vielzahl von Änderungen an der zugrundeliegenden Kollektion die Struktur ständig angepasst werden muss, um immer den aktuellen Stand wiederzugeben. Dynamisches Browsing hingegen bietet den Vorteil, dass die Struktur erst bei der Interaktion mit einem Benutzer auf Basis von dessen Eingaben erzeugt wird. So werden Änderungen an der dem Browsing zugrundeliegenden Kollektion bei jeder Sitzung erfasst und in der dynamisch erstellten Struktur wiedergegeben. [CLNT04] Für dynamisches Browsing kann nun das Verfahren des Text-Clustering verwendet werden, das eine spezielle Variante des Dokumenten-Clusterings darstellt. Eine Beschreibung dieses Verfahres und der genaue Ablauf von dynamischem Browsing ist daher im nächsten Abschnitt zu nden Text-Clustering Hier soll nun im weiteren das Verfahren des Text-Clustering vorgestellt werden. Dieses Verfahren eignet sich, wie im vorigen Abschnitt angesprochen, als technische Grundlage für dynamisches 4 7

14 2. Grundlagen Browsing. Clustering ist im Prinzip nicht auf (Text-)Dokumente beschränkt, im Rahmen dieser Arbeit reicht aber die Betrachtung dieses Spezialfalls aus. Eine allgemeinere Beschreibung des Cluster-Retrievals ist in [Fuh04] zu nden. Ziel des Verfahrens ist es nun, ähnliche Dokumente automatisch in einer endlichen Menge von Clustern (deutsch: Gruppen) zusammenzufassen. Dabei sollen die Dokumente einer Gruppe untereinander möglichst ähnlich, Dokumente aus verschiedenen Gruppen jedoch möglichst unähnlich zu einander sein [Cho03]. Zur Legitimation dient dabei die schon in [vrj73] experimentell nachgewiesene Cluster-Hypothese: closely associated documents tend to be relevant to the same requests (deutsch: Ähnliche Dokumente tendieren dazu, relevant im Bezug zu den gleichen Anfragen zu sein.) Im Gegensatz zu anderen Retrieval-Verfahren, die als Ausgangspunkt eine vom Benutzer vorgegebene Anfrage erwarten, ist bei diesem Verfahren keine initiale Benutzereingabe erforderlich. Vielmehr kommt hier ein sog. Ähnlichkeitsmaÿ sowie ein Algorithmus zum Einsatz, um die Gruppierung der Dokumente vorzunehmen. Des weiteren müssen die zu gruppierenden Dokumente in ein vorgegebenes Datenmodell überführt werden, auf das die beiden vorgenannten Komponenten aufsetzen. Alle drei Teilbereiche werden in weiteren Verlauf dieses Kapitels noch detailliert beschrieben. Zunächst aber soll das in Abbildung 2.1 aus [Cho03] dargestellte Beispiel-Clustering betrachtet werden. Abbildung 2.1.: Beispiel-Clusterings In dieser Abbildung sind drei verschiedene Clustering-Szenarien zu erkennen. Die schwarzen Punkte repräsentieren Dokumente, die in einer durch zwei Unterscheidungskriterien aufgespannten Ebene liegen. Auf den Achsen wird dabei der Wert des jeweiligen Kriteriums abgetragen. Hier soll zunächst kein konkretes Kriterium angegeben, sondern das Ganze nur abstrakt betrachtet werden. Das linke Bild zeigt die Ausgangsposition nach der Bewertung der Dokumente durch die Unterscheidungskriterien. Das mittlere und das rechte Bild zeigen dann die Situation, nachdem ein Clustering-Algorithmus auf die Dokumente angewendet wurde. Eine gestrichelte Linie begrenzt dabei einen Cluster. Am Beispiel des mittleren Bildes kann man erkennen, dass die Dokumente innerhalb eines Clusters weit verstreut sind und somit nicht maximale Ähnlichkeit zueinander haben. Beim rechten Bild hingegen kann man ein gutes (in diesem Beispiel sogar perfektes) Clustering erkennen. Hier sind alle Dokumente mit maximaler Ähnlichkeit zueinander im selben Cluster zusammengefasst worden. 8

15 2.2. Text-Clustering Nachdem die Dokumente in Gruppen eingeteilt wurden, muss für jede Gruppe noch eine Beschreibung erzeugt werden. Diese Beschreibung sollte stellvertretend für alle Dokumente in dieser Gruppe sein, und einem Betrachter so einen guten Anhaltspunkt geben, welche Dokumente bzw. welche Thematiken in der Gruppe zusammengefasst wurden. Da die Gruppen ja automatisiert vom System generiert wurden und das gesamte Verfahren ohne manuelle Eingrie auskommen soll, muss die Beschreibung ebenfalls automatisch erzeugt werden. Hierzu kann der Zentroid oder Medoid 5 des jeweiligen Clusters verwendet werden. Der Zentroid ist ein virtuelles Dokument im Zentrum des Clusters. Anschaulich betrachtet stellt er den geometrischen Mittelpunkt eines Clusters dar. Der Medoid ist das dem Zentroid am nächsten gelegene und damit das ihm ähnlichste Dokument. In Abbildung 2.2 aus [Cho04a] sind die Zentroiden (rote Punkte) und Medoiden (rot umrandete Punkte) der Cluster im Kontext des einleitenden Beispiels dargestellt. Abbildung 2.2.: Zentroid vs. Medoid Im weiteren Verlauf dieses Kapitels wird jetzt das Konzept eines Clustering-Verfahrens basierend auf dem Vektorraummodell beschrieben und die einzelnen Aufgabenbereiche dieses Konzepts hervorgehoben Das Vektorraummodell Um Clustering für Dokumente zu realisieren, muss zunächst ein grundlegendes Modell festgelegt werden, auf dem alle benötigten Komponenten aufbauen. Dabei kann für die Clustering- Verfahren das Vektorraummodell (VRM) nach [SWY75] verwendet werdet. Hier werden die Dokumente als Punkte in einem n-dimensionalen Vektorraum aufgefasst, wobei die Dimension des Raumes durch die Anzahl der Unterscheidungskriterien bestimmt wird. Diese geometrische Interpretation macht das Modell sehr anschaulich [Fuh04]. Bei der Implementierung eines auf dem VRM basierenden Clustering-Verfahrens müssen drei Kernbereiche berücksichtigt werden: Datenmodell Das Datenmodell umfasst die Speicherung und Verwaltung der betrachteten Dokumente. Dazu gehören sowohl die Eigenschaften der Dokumente selbst (beispielsweise Titel, Autor, Erscheinungsjahr etc.) als auch die später benötigten Unterscheidungskriterien, im weiteren auch Fea- 5 Der Begri Medoid ist aus den Begrien Median und Zentroid zusammengesetzt. 9

16 2. Grundlagen tures genannt. Im Fall des Text-Clustering sind diese Features in der Regel Terme, die in den Dokumenten vorkommen. Beim Vektorraummodell werden die betroenen Dokumente durch Vektoren beschrieben, die die vorher festgelegten Unterscheidungskriterien, also Features, enthalten. Beim Text-Clustering sind das in der Regel Terme, die im Dokument enthalten sind. Des weiteren können diese Terme noch gewichtet werden, um die inhaltlichen Schwerpunkte der Dokumente besser herauszustellen. Im einfachsten Fall entsprechen die Gewichte der Häugkeit des jeweiligen Terms im Dokument [BEX02]. Die Dokumente werden dabei durch den jeweiligen Vektor d i mit i = 1,..., n beschrieben, wobei n für die Anzahl der zu betrachtenden Dokumente steht. Tabelle 2.1 zeigt auszugsweise die Verteilung von sechs Termen auf drei Dokumente. Term d 1 d 2 d 3 programming language informatik example learn debug Tabelle 2.1.: Beispiel-Dokumentenbeschreibung Ausgehend von diesem Beispiel lässt sich erkennen, dass ein Datenmodell die zu betrachtenden Objekte, in diesem Fall Dokumente, wie auch die zu den Dokumenten gehörenden Unterscheidungskriterien, hier Terme mit zugehöriger Häugkeit, speichern und verwalten können muss. Ähnlichkeitsmaÿe Nachdem im letzten Abschnitt deutlich gemacht wurde, wie eine Dokumentenbeschreibung inklusive Unterscheidungskriterien aufgebaut ist, wird nun erläutert, wie mit Hilfe dieser Kriterien die Ähnlichkeit von Objekten bzw. Dokumenten untereinander bestimmt werden kann. Für diesen Zweck kommen sogenannte Ähnlichkeitsmaÿe zum Einsatz, die unter Verwendung der vorhandenen Dokumenten-Features automatisch die Ähnlichkeit von einem Dokument zu einem anderen Dokument bestimmen können. In [SM83a] werden beispeilsweise fünf verschiedene Maÿe vorgestellt, im einzelnen sind dies das Dice-Maÿ, das Jaccard-Maÿ, das Überschneidungsmaÿ, das asymetrische Maÿ sowie das Kosinusmaÿ. Cluster-Algorithmen Auf die oben angesprochenen Ähnlichkeitsmaÿe können nun Cluster-Algorithmen zurückgreifen. Durch diese Algorithmen wird die eigentliche Gruppierung aller betroenen Dokumente vorgenommen. Nach [Fuh04] existieren prinzipiell zwei wesentliche Strategien, zum einen agglomeratives Clustering, zum anderen partitionierendes Clustering. Bei beiden Strategien bezeichnet n die Anzahl der zu gruppierenden Dokumente. Agglomeratives Clustering Das agglomerative Clustering geht von einem vorgegebenen Schwellenwert α für die Ähnlichkeit zwischen Cluster und Dokument aus. Hierbei wird ein 10

17 2.2. Text-Clustering Dokument zu einem Cluster hinzugefügt, falls dieser vorgegebene Schwellenwert überschritten wird. Ist noch kein Cluster vorhanden, wird ein neuer erzeugt und das Dokument diesem hinzugefügt. Nach einem einmaligen Durchlauf aller Dokumente ist das Clustering erzeugt. Die Anzahl der erzeugten Cluster kann hierbei nicht im vorhinein festgelegt werden, da diese vom Schwellenwert abhängen. [Cho04a] Allgemein lässt sich zur Bewertung dieser Strategie festhalten, dass agglomerative Cluster- Algorithmen sehr exakt arbeiten und somit gute Clustering-Ergebnisse produzieren. Nachteilig wirkt sich allerdings ihr hoher Aufwand von O(n 2 ) aus, da hier die paarweise Ähnlichkeit aller Dokumente berechnet werden muss. [Cho04a] Partitionierendes Clustering Beim partitionierenden Clustering kann, anders als beim vorhergehenden Verfahren, die Anzahl der zu bildenden Cluster im vorhinein bestimmt werden. Zu Beginn bestimmt das Verfahren k seed-dokumente (deutsch: Saat), wobei k die Anzahl der bildenden Cluster darstellt. Die seed-dokumente müssen hinreichend unterschiedlich sein. Jedes dieser Dokumente bildet den Kern eines der Cluster C 1,..., C k. Die übrigen Dokumente werden dann zum jeweils ähnlichsten Cluster hinzugefügt. Nach [Fuh04] beträgt bei diesem Verfahren der Aufwand nur noch O(kn), die Qualität der Cluster hängt allerdings stark von den ausgewählten seed-dokumenten ab. Hierarchisches Clustering Das Ergebnis der beiden gerade vorgestellten Clustering-Verfahren ist immer eine ache Cluster-Struktur. Allerdings kann man Cluster-Strukturen auch hierarchisch aufbauen, und somit in mehrere Ebenen unterteilen. Mit den beiden oben angesprochenen Cluster-Algorithmen kann nun auch eine solches hierarchisches Clustering realisiert werden. Um dies zu erreichen, werden die Verfahren iterativ angewendet, um die in der vorhergehenden Stufe gebildeten Cluster weiter zu zerlegen [Fuh04]. Ergebnis eines solchen Clusterings ist eine baumförmige Cluster-Struktur. Abbildung 2.3 aus [Cho04a] verdeutlicht noch einmal den Unterschied zwischen einem achen und einem hierarchischen Clustering. Abbildung 2.3.: Flaches und hierarchisches Clustering Verfahren der Termextraktion Nachdem nun die einzelnen Komponenten des Text-Clustering erläutert wurden, soll in diesem Abschnitt noch einmal auf das Thema Unterscheidungskriterien bzw. Features eingegangen 11

18 2. Grundlagen werden. Wie schon in erwähnt, bietet sich beim Dokumenten-Clustering die Verwendung von Termen als sog. Dokumenten-Features an. Im weiteren wird jetzt erläutert, wie diese Terme automatisch aus Dokumenten extrahiert werden und welche Möglichkeiten existieren, den Informationsgehalt 6 eines Terms durch Gewichtung zu bewerten. Termnormalisierung Bevor die einzelnen Terme im Datenmodell abgelegt werden, müssen diese aus den Dokumenten extrahiert und normalisiert werden. Termnormalisierung bedeutet, dass ein in seiner Ursprungsform vorliegender Text so umgewandelt wird, dass nach Abschluss des Prozesses nur noch eine Menge von Einzeltermen in Stammform (z.b. Flugzeuge -> Flugzeug) vorliegt, die den Ursprungstext repräsentieren. Auÿerdem sind in dieser Menge keine Wörter mehr vorhanden, die nur einen geringen Informationsgehalt besitzen (beispielsweise und, das, nach etc.). Abschlieÿend wird noch eine Gewichtung jedes einzelnen Terms der so gewonnenen Termmenge vorgenommen. Termgewichtung Die Termgewichtung ist ein Maÿ für den Informationsgehalt eines Term. Der Informationsgehalt eines Terms repräsentiert dabei die Relevanz des Terms im jeweiligen Dokument bzw. im Bezug zur Dokumentenkollektion. Nach [Luh58] steht die Vorkommenshäugkeit eines Terms in einem Dokument in Bezug zu seinem Informationsgehalt. Daher kann, wie auch schon in 2.2.1, die Termhäugkeit (tf ) als Gewicht verwendet werden. [Cho04a] tw 1 := tf Hiernach ist ein Term, der häug in einem Dokument vorkommt, wichtiger als ein Term, der nur selten vorkommt. Des weiteren muss auch das Vorkommen eines Terms in der gesamten Kollektion berücksichtigt werden. Insgesamt lässt sich festhalten, dass die besten Terme diejenigen sind, die häug in einzelnen Dokumenten vorkommen, aber nur selten in der gesamten Kollektion [Sal88]. Um dies zu berücksichtigen, können die Gewichte als Produkt aus der Termhäugkeit und einem Faktor, der die Dokumentenhäugkeit repräsentiert, berechnet werden. Dazu betrachten wird hier nach [Sal88] die inverse Dokumentenhäugkeit (idf ). Diese ist für einen Term T j in einem Dokument D i deniert als idf ij := log N n j, wobei N für die Gröÿe der Kollektion und n j für die Anzahl der Dokumente stehen, in denen der Term T j vorkommt. Ingesamt ergibt sich also für das Gewicht: tw 2 := tf idf Nach [SS95] kommen wichtige Terme in besonders langen Dokumenten häuger vor als in kürzeren. Aus diesem Grund wird noch das tw 2 durch die euklidische Norm des Dokumentenvektors normalisiert [Cho04a]: tw 3 := tf idf d 2 6 Der Informationsgehalt eines Terms soll ein Maÿ dafür sein, wie relevant der Term im Kontext zum Dokument in dem er vorkommt bzw. zur gesamten Dokumentenkollektion ist. 12

19 2.2. Text-Clustering Scatter/Gather-Browsing In [CPKT92] wird nun ein Browsing-Verfahren vorgestellt, für welches das oben erläuterte Clustering-Verfahren auf Basis des Vektorraummodells verwendet werden kann. Kernprinzip dieses Verfahrens ist es, dass Cluster nicht statisch berechnet werden, sondern dynamisch während der interaktiven Browsing-Sitzung. Jeder Suchschritt in dieser Sitzung besteht dabei aus zwei Phasen, einer Scatter-Phase (deutsch: zerstreuen) und einer Gather-Phase (deutsch: einsammeln). In der Scatter-Phase wird die Dokumentenkollektion in eine vorher festgelegte Anzahl von Clustern zerlegt und dem Benutzer Beschreibungen dieser Cluster angezeigt. In der Gather- Phase wählt der Benutzer beliebig viele für ihn interessante Cluster aus. Die ausgewählten Cluster bilden dann die neue Ausgangskollektion für den nächsten Suchschritt [Fuh04]. Abbildung 2.4 aus [Cho04a] veranschaulicht einen solchen Suchschritt schematisch. Die farbigen Punkte stehen dabei für Dokumente, die Farben signalisieren ihre thematische Ausrichtung. Gleichfarbige Dokumente behandeln also den gleichen thematischen Sachverhalt. Abbildung 2.4.: Suchschritt im Scatter/Gather-Verfahren Vorprozessiertes Scatter/Gather Da beim Scatter/Gather-Verfahren, wie schon oben angesprochen, Text-Clustering und damit entsprechende Algorithmen (siehe 2.2.1) zum Einsatz kommen, ist die Anzahl der zu Gruppierenden Dokumente ein entscheidender Faktor für den Zeitaufwand bei einem Scatter-Schritt. So müssten eben bei einer beispielsweise Dokumente umfassenden Kollektion im ersten Schritt alle Dokumente gruppiert werden, was einen erheblichen und somit für einen Benutzer inakzeptablen Zeitaufwand nach sich zieht. Dieser Zeitaufwand verringert sich im weiteren Verlauf erst nach einigen Scatter/Gather-Schritten auf ein akzeptablen Wert, da ja durch die Gather-Phasen die Anzahl der betrachteten Dokumente geringer wird und somit auch immer weniger Dokumente gruppiert werden müssen. Um dieser Problematik entgegenzuwirken, wurde in [CKP93] eine vorprozessierte Variante von Scatter/Gather vorgestellt, um einen nahezu konstanten Zeitaufwand bei den Scatter/Gather-Schritten in Dokumentenkollektionen unterschiedlichster Gröÿe zu erreichen. Dazu wird vor der eigentlichen Browsing-Sitzung eine Vorprozessierung der gesamten Dokumentenkollektion durchgeführt. Bei dieser Vorprozessierung wird mit Hilfe der klassischen Cluster- Algorithmen eine hierarchische Dokumentenstruktur in Form eines Baums generiert, in dem 13

20 2. Grundlagen sog. Metadokumente die Knoten innerhalb der Baumstruktur darstellen und eine komprimierte Darstellung 7 der Inhalte ihrer Kinder enthalten. Die ursprünglichen Dokumente sind im Baum als Blätter vorhanden. In Abbildung 2.5 ist exemplarisch eine solche Baumstruktur abgebildet, wobei rote Punkte für Metadokumente und grüne Punkte für echte Dokumente stehen. Abbildung 2.5.: Hierarchische Dokumentenstruktur beim vorprozessierten Scatter/Gather Das Browsing selbst ndet dann nicht mehr direkt auf der gesamten Dokumentenmenge, sondern vielmehr auf den bei der Vorprozessierung generierten Metadokumenten bzw. deren Prolen statt. Dadurch wird jede Scatter-Phase in nahezu konstantem Zeitaufwand durchgeführt Das InveX-Werkzeug Im Studienprojekt Yahoo für das Invisible Web [CLNT04] wurde ein Browsing-Werkzeug für beliebige XML-Dokumente auf Basis des Scatter/Gather-Verfahrens entwickelt. Als theoretische Grundlage kommt hier die im vorigen Abschnitt vorgestellte vorprozessierte Variante von Scatter/Gather nach [CKP93] zum Einsatz. Die Vorprozessierung kann aber als eigenständiger Vorgang betrachtet werden, so das sich am prinzipiellen Ablauf des eigentlichen Browsing- Verfahrens nichts ändert und damit die Beschreibung in auch hierfür als gültig angesehen werden kann. Allgemeiner Aufbau Das hier entwickelte Werkzeug, im weiteren InveX-Werkzeug genannt (InveX = Invisible Web Explorer), ist ein modular aufgebautes Framework. In diesem Framework wurden verschiedene Cluster-Algorithmen, ein Ähnlichkeitsmaÿ, eine Datenstruktur, Speicherkomponenten sowie verschiedene Termgewichte realisiert. Momentan bietet dieses Werkzeug die notwendige Funktionalität, um im Rahmen der Vorprozessierung eine hierarchische Dokumentenstruktur einer lokal abgelegten XML-Dokumentenkollektion zu erzeugen und unter Verwendung dieser Struktur darin nach dem Scatter/Gather-Verfahren zu browsen. Für die im Rahmen dieser Arbeit zu realisierende prototypische Implementierung soll das InveX-Werkzeug als Basis dienen und erweitert werden, um Cluster-basiertes Browsing auch in Peer-to-Peer-Netzen zu ermöglichen. 7 Diese komprimierten Darstellungen werden auch Prole genannt. Ein Prol kann beispielsweise aus den häugsten Termen, der Anzahl der repräsentierten Dokumente sowie einigen Beispieltiteln bestehen. 14

21 2.2. Text-Clustering Implementierte Algorithmen und Verfahren Da in den folgenden Kapiteln häug auf die Komponenten des InveX-Werkzeugs eingegangen wird, soll an dieser Stelle noch ein Überblick über die momentan vorhandenen, in den jeweiligen Modulen implementierten Verfahren und Algorithmen aus den Bereichen Termgewichtungsmaÿe, Ähnlichkeitsmaÿe und Clustering-Algorithmen gegeben werden. In Abbildung 4.1 werden dieses Bereiche durch das grüngefärbte Modul repräsentiert. Normal Weight Das Normal Weight beschreibt die einfachste Möglichkeit, einen Term mit einem Gewicht zu versehen. Hierbei wird lediglich die Häugkeit betrachtet, mit der ein Term in einem Dokument vorkommt. Das Normal Weight entspricht also genau dem Termgewicht tw 1 in Abschnitt Relative Information Weight Beim Relative Information Weight werden die Termgewichte auf Basis einer gegebenen Kollektion berechnet. Dabei wird berücksichtigt, dass sich die Kollektion bei jedem Scatter/Gather-Schritt ändert. Um das Termgewicht zu berechnen, wird daher der Informationsgehalt des Terms im zugehörigen Cluster in Bezug zum Informationsgehalt des Terms im Rest der (neuen) Kollektion gesetzt. Dieser Wert wird dann noch mit der Anzahl der Dokumente in der aktuellen Kollektion, die den Term beinhalten, gewichtet. [CLNT04] Kosinusmaÿ Das Kosinusmaÿ ist eine Kennzier für den Winkel zwischen zwei Dokumenten- Vektoren, welche die Unterscheidungskriterien beinhalten (siehe Tabelle 2.1). Für nichtnegative Vektorelemente liegt der Wert dieses Maÿes im Intervall [0, 1], wobei 0 für unähnlichste und 1 für gleiche Dokumente (auf Basis der Unterscheidungskriterien) steht. Das Kosinusmaÿ ist wie folgt deniert: sim cos (d i, d j ) := d i d j d i 2 d j 2 Der Vollständigkeit halber ist noch anzumerken, dass in der Gleichung für das Skalarprodukt und 2 für die euklidische Norm, also die Länge eines Vektors, stehen. Agglomeratives Clustering Bei der hier implementierten Variante eines agglomerativen Clusterings wird, ausgehend von einer Menge von gegebenen Dokumenten, eine vorher festgesetzte Anzahl von Clustern erzeugt. Dabei wird zu Beginn jedes Dokument genau einem Cluster zugeordnet, so dass der Algorithmus mit einer Menge von Clustern startet, die alle genau ein Dokument enthalten. Anschlieÿend wird die paarweise Ähnlichkeit aller Cluster bestimmt, und die beiden jeweils ähnlichsten Cluster werden zu einem Neuen zusammengefasst. Dieser letzte Arbeitsschritt wird so lange wiederholt, bis die gewünschte Anzahl von Clustern erzeugt worden ist. Buckshot Der Buckshot-Algorithmus arbeitet in mehreren Schritten, um mit geringerem Aufwand als beim agglomerativen Clustering eine Gruppierung der Dokumente vorzunehmen. Dazu verwendet er zunächst das implementierte agglomerative Clustering, um eine zufällig ausgewählte Stichprobe von Dokumenten aus der gegebenen Kollektion in einer vorgegebenen Anzahl von Clustern zu gruppieren. Die Stichprobe hat dabei den Umfang k n, wobei k für die gewünschte Anzahl von Clustern und n für die Anzahl aller Dokumente in der Kollektion steht. Anschlieÿend werden die Zentren der so erzeugten Cluster extrahiert 15

22 2. Grundlagen und alle Dokumente ihrem jeweils ähnlichsten Zentrum zugewiesen. Abschlieÿend wird das Clustering noch verfeinert, indem erneut die Zentren der aktuellen Cluster extrahiert, und alle Dokumente wieder ihrem jeweils ähnlichsten Zentrum zugewiesen werden Peer-to-Peer-Technologie In diesem Abschnitt soll nun noch der zweite groÿe Teilbereich, der eine Grundlage für diese Arbeit bildet, vorgestellt werden, nämlich das Konzept der P2P-Technologie. Dazu wird zunächst das Client/Server-Prinzip angesprochen, das die bislang dominierende Systemarchitektur bildet und als klassisches Konzept für viele Einsatzgebiete verwendet wird. Anschlieÿend wird auf das P2P-Prinzip eingegangen und die prägnanten Unterschiede beider Architekturen herausgearbeitet. Weiterhin wird kurz auf die Vor- und Nachteile der P2P-Architektur eingegangen sowie zwei Kongurationen von P2P-Netzen beschrieben. Zum Abschluss wird dann noch die von Sun Microsystems, Inc. 8 initiierte P2P-Technologie JXTA TM9 vorgestellt, die im Rahmen des gleichnamigen Projekts weiterentwickelt wird Die Client/Server-Architektur Seit Mitte der 80er Jahre dominiert im Bereich der Netzwerkarchitektur das Client/Server- Prinzip. Bei dieser Architektur verbinden sich die Clients unter Verwendung eines spezischen Kommunikationsprotokolls, beispielsweise ist hier das File Transfer Protocol (FTP) zu nennen, mit einem Server, um Zugri auf eine bestimmte Ressource zu erhalten. Die Hauptaufgabe bei der Bereitstellung und Bearbeitung übernimmt dabei der Server, während ein Client keinen Einuss auf die Bearbeitung nehmen kann und sich so bis zur Beantwortung einer Anfrage quasi im Leerlauf bendet. Beim Client/Server-Prinzip nimmt ein Client also nur eine passive Rolle ein: Er kann Dienste von einem Server abrufen, selbst aber einem anderen Client keine zur Verfügung stellen. In Abbildung 2.6 aus [Wil02] ist die die logische Struktur einer Client/Server- Architektur abgebildet. Ein entscheidender Nachteil dieser Architektur ist die Tatsache, das beim Ausfall eines Servers automatisch alle Dienste, die er bereitgestellt hat, nicht mehr zur Verfügung stehen. Daher spricht man im Zusammenhang mit Client/Server-Architekturen auch häug vom Single Point of Failure. Ein solcher Ausfall muss dabei nicht ausschlieÿlich technischer Natur sein, sondern kann durchaus auch auf ein zu hohes Datenaufkommen durch eine groÿe Anzahl von Anfragen zurückzuführen sein [Wil02] Die Peer-to-Peer-Architektur Peer-to-Peer-Technologie soll nun jedem an einem Netzwerk angeschlossenen Gerät ermöglichen, Dienste für andere Geräte zu Verfügung zu stellen. Verfügt ein Gerät über einen solchen Mechanismus und schlieÿt sich mit anderen Geräten zu einem Netzwerk zusammen, so bilden diese Geräte ein P2P-Netzwerk, in dem jedes Gerät Peer genannt wird. Auf einem einzelnen physikalischen System können zwar mehrere logische Peers laufen, dies kann aber als Spezialfall angesehen werden und soll hier nur der Vollständigkeit halber erwähnt werden. Abbildung 2.7 aus [Wil02] veranschaulicht den Aufbau eines solchen Netzes

23 2.3. Peer-to-Peer-Technologie Abbildung 2.6.: Logischer Aufbau der Client/Server-Architektur Beim direkten Vergleich mit der Client/Server-Architektur lässt sich erkennen, dass hier keine zentralisierten Geräte existieren, sondern alle Geräte Dienste zur Verfügung stellen und abrufen können. In einem solchen Netzwerk nehmen alle vorhandenen Geräte gleichberechtigte Positionen ein. Man könnte einen Peer also sowohl als Server als auch als Client interpretieren. Nach [YGM01] wird ein Peer bzw. ein Netzwerkknoten daher auch als Servent 10 bezeichnet. P2P-Netze enthalten also keine zentrale Komponente und beseitigen somit den von Client/Server-Prinzip bekannten Single Point of Failure. Damit ergibt sich eine wesentlich höhere Ausfallsicherheit und Verfügbarkeit des gesamten Systems. Weiterhin fallen in der Summe geringere Kosten an, da die benötigten Ressourcen meist schon vorhanden sind [Eis02]. Allerdings entstehen durch die Verwendung dieser Technologie auch wieder neue Problematiken und Fragestellungen. Auf die im Zusammenhang mit dieser Arbeit entstehenden Problemstellungen wird während der Entwicklung des Konzepts in Kapitel 3 eingegangen, eine allgemeine Übersicht über diese Theamtik mit Lösungsvorschlägen ist in [DGMY03] zu nden. Die meisten der heutige Anwendungen, die auf P2P-Technologie aufsetzen, können in eine der folgenden drei Hauptkategorien eingeteilt werden [Wil02]: Instant Messaging Diese Art von Programmen erlaubt es Anwendern zu sehen, ob ihre Freunde gerade online sind, und ermöglicht dann direkte Kommunikation mit ihnen. Diese Kommunikation kann die Übertragung von Nachrichten oder die Übermittlung von Dateien beinhalten. Beispiele für diese Programme sind in der AOL Instant Messenger 11, ICQ Instant Messenger 12 oder der MSN Messenger Das Wort ist aus den Begrien server und client abgeleitet

24 2. Grundlagen Abbildung 2.7.: Logischer Aufbau der P2P-Architektur File Sharing Mit diesen Applikationen kann ein Anwender beliebige Dateien im Netzwerk anbieten und selbst nach interessanten Dateien suchen sowie diese bei Bedarf herunterladen. Programme und Netzwerke, die diese Funktionalität bereitstellen, sind beispielsweise der emule P2P-Client 14, der KaZaA P2P-Client 15 und das Gnutella-Netzwerk 16. Distributed Computing Beim Distributed Computing geht es darum, ungenutzte Rechenkapazitäten von Systemen im Netzwerk für ein bestimmtes Ziel zu nutzen. Dies wird z.b. in den Projekten Great Internet Mersenne Prime Search (GIMPS) 17 und 18 verwirklicht. P2P-Technologie wird also in den drei oben genannten Kategorien am häugsten eingesetzt. Allerdings kann in einem P2P-Netzwerk die Verfügbarkeit eines Peers und damit seiner Dienste/Ressourcen nicht garantiert werden. In einem Client/Server-Netzwerk sind die Server immer mit dem Netz verbunden und somit theoretisch auch immer verfügbar 19. Den dynamischen Faktor in einem solchen Netz bilden hier die Clients, die sich im Normalfall nur mit dem Netz verbinden, um Dienste/Ressourcen der Server in Anspruch zu nehmen. Da in einem P2P-Netz die Peers beide Eigenschaften übernehmen, ist hier die Dynamik ein entscheidender, limitierender Faktor. Ein Teilnehmer eines solchen Netzes hat also keine Garantie, dass die von ihm gesuchten/gewünschten Dienste oder Ressourcen gerade verfügbar sind. Ausgehend von diesem dynamischen Verhalten werden P2P-Netze laut [TAA + 03] häug auch als ad hoc Netzwerke bezeichnet. Um speziell diese Problematik zu entschärfen, gibt es Eine angestrebter Wert ist in der Regel eine Verfügbarkeit von mind. 99.9% pro Jahr, was einem Gesamtausfall von ca. einem halben Tag entsprechen würde. 18

25 2.3. Peer-to-Peer-Technologie gerade für die oben angesprochenen Einsatzgebiete unterschiedliche Kongurationen von P2P- Netzen. In dieser Arbeit sollen aber nur zwei der am häugsten eingesetzten Kongurationen vorgestellt werden. Bevor nun im nächsten Abschnitt auf die beiden unterschiedlichen Kongurationen der Netzwerktopologie näher eingegangen wird, verdeutlicht Tabelle 2.2 noch einmal kurz die prägnanten Unterschiede beider Architekturen. Client/Server Dynamik nur bei Clients, Server sind permanent erreichbar Direkte Verbindungen nur zwischen Clients und Servern Nur Server bieten Dienste im Netzwerk an Clients rufen Dienste auf Server ab Server stellen einen Single Point of Failure dar; Ausfallsicherheit kann nur durch Redundanz bei Servern verbessert werden Daten auf Servern immer verfügbar Peer-to-Peer Hohe Dynamik bei allen Netzwerkteilnehmern (Peers) Direkte Verbindung zwischen alle Geräten (Peers) im Netzwerk Alle Peers bieten Dienste im Netzwerk an Peers können Dienste auf anderen Peers in Anspruch nehmen Durch Verteilung der Dienste auf alle Peers hohe Erreichbarkeit und geringes Ausfallrisiko Individuelle Daten auf einzelnen Peers durch hohe Dynamik nicht immer verfügbar Tabelle 2.2.: Client/Server vs. Peer-to-Peer Reine Peer-to-Peer-Netze In einem reinen P2P-Netz sind alle Netzwerkteilnehmer (Peers) gleichberechtigt. Hier nimmt jeder Peer die gleichen Aufgaben wie alle anderen wahr. Da in einem solchen Netzwerk keine zentralen Dienste, wie beispielsweise ein Login-Dienst oder eine Ressourcenverwaltung existieren, müssen zunächst andere Peers gefunden werden, um dem Netzwerk beitreten zu können. Dies kann z.b. über Broadcast-Nachrichten erreicht werden, um so Informationen über Nachbar- Peers zu erhalten. Jeder Peer sieht also nur einen kleinen Ausschnitt des gesamten Netzwerkes. Werden in einem solchen Netz beispielsweise Suchanfragen gestellt, so übermittelt ein anfragender Peer diese zunächst an die ihm bekannten Peers, wonach diese die Anfrage dann an alle ihnen bekannten Peers weiterleiten usw. Um in einem solchen Netzwerk Dienste oder Ressourcen zu entdecken, muss man also zunächst mit einer ausreichend groÿe Anzahl von anderen Netzwerkteilnehmern in Kontakt treten. Da in einem solchen Fall das Netzwerk tatsächlich mit Anfragen überutet wird, spricht man bei Algorithmen, die ein solches Verfahren realisieren, auch von ooding-algorithmen 20. Das File-Sharing-Netzwerk Gnutella arbeitet beispielsweise nach dem Prinzip der reinen P2P-Netze. 20 Bei solchen Algorithmen ist problematisch, dass sie schlecht skalieren und sehr viele Ressourcen verbrauchen. Daher wird bei diesen Verfahren häug ein Suchbaum aufgespannt, dessen Tiefe und damit die Laufzeit einer Anfrage festgelegt werden kann. So kann die entstehende hohe Netzwerkbelastung zumindest rudimentär kontrolliert und damit begrenzt werden 19

26 2. Grundlagen Hybride Peer-to-Peer-Netze Einen anderen Ansatz verfolgen die sog. hybriden P2P-Netze. Wie der Name schon sagt, handelt es sich hierbei um hybride Netzwerke, in denen also Konzepte aus der Client/Server-Architektur wie auch aus der P2P-Architektur verwendet werden. Demnach gilt hier nicht mehr das Prinzip, dass alle Netzwerkteilnehmer die selben Aufgaben wahrnehmen. Vielmehr übernehmen hier einige Systeme Verwaltungsaufgaben im Netzwerk. Diese Systeme haben je nach P2P-Netz unterschiedliche Bezeichnungen, meistens werden sie aber als Server, Super-Peer oder Super- Node bezeichnet. Die Aufgaben solcher Systeme können je nach Einsatzgebiet unterschiedlich ausfallen. So wird in eigentlich jedem Fall die Anmeldung am Netzwerk über sie abgewickelt. In File-Sharing- Netzen werden zusätzlich die angebotenen Dateien auf diesen Systemen indexiert (emule), beim distributed computing werden hier die zu bearbeitenden Rechenfragmente erstellt. Eine solche Architektur ermöglicht höhere Geschwindigkeiten bei Anfragen, Login- Prozeduren, etc. Zusätzlich kommt die Problematik der hohen Dynamik nicht mehr so stark zum Tragen wie noch bei den reinen P2P-Netzen, da hier immer die Kommunikation mit den zentralisierten Systemen möglich ist. Dies erlaubt bespielsweise, bestimmte Ressourcen über den Verzeichnisdienst zu nden obwohl die entsprechenden Peers gerade nicht mit dem Netzwerk verbunden sind. Ein Zugri auf diese Ressourcen ist dann natürlich erst wieder möglich, wenn der entsprechende Peer sich wieder mit dem Netzwerk verbindet. Zum Abschluss verdeutlicht Abbildung 2.8 aus [Wil02] den Aufbau dieser Architektur noch einmal schematisch. Abbildung 2.8.: Hybrides P2P-Netz JXTA TM -Technologie Nachdem im vorigen Abschnitt zwei unterschiedliche Netzwerkarchitekturen näher betrachtet wurden, soll nun eine konkrete Technologie für P2P-Netze vorgestellt werden. Im Open-Source- 20

27 2.3. Peer-to-Peer-Technologie Projekt JXTA 21 werden Basistechnologien für die Realisierung von einfachen, kleinen und exiblen Mechanismen zur Umsetzung von P2P-Funktionalität entwickelt [SM01]. Das Projekt wurde von Sun Microsystems eingeführt und deniert in erster Linie eine kleine Menge von Protokollen, die P2P-Arbeitsweisen ermöglichen. Da JXTA selbst keine API darstellt, ist es programmiersprachenunabhängig und auf jedem netzwerkfähigen Gerät (PCs, Handys, PDAs, etc.) einsetzbar [GOT02]. Da die JXTA-Protokolle auch netzwerkunabhängig sind, können somit auch netzwerkübergreifende Verbindungen erstellt werden. Es entsteht also ein virtuelles Netzwerk, in dem auf logischer Ebene direkte Kommunikation zwischen den Teilnehmern möglich ist (vgl. Abbildung 2.9 aus [TAA + 03]). Für die Programmiersprachen Java und C++ sind Implementierungen der JXTA-Basiskonzepte auf der Homepage des Projekts verfügbar. Abbildung 2.9.: JXTA Virtual Network Architektur Die Architektur von JXTA ist in drei Schichten aufgeteilt, wie in Abbildung 2.10 aus [Gon02] zu erkennen ist. Dies sind im einzelnen die Schichten JXTA Core, JXTA Services und JXTA Application. Im folgenden werden diese drei Schichten kurz vorgestellt, Details zu den darin enthaltenen Konzepten (kursiv hervorgehoben) sind im Anschluss an diesen Abschnitt zu nden. JXTA Core In dieser Schicht sind Grundmechanismen und Funktionen angesiedelt, die zur Einbettung von beliebigen Endgeräten erforderlich sind. Hiermit wird P2P-Funktionalität erst ermöglicht. Dies umfasst unter anderem die Bereiche Peers, Peer Groups, Pipes, etc. [SM03] JXTA Services Dieser Schicht werden Netzwerkdienste zugeordnet, die nicht absolut notwendig für den Betrieb einer P2P-Umgebung, jedoch üblich oder wünschenswert sind [SM03]. So ndet man hier beispielsweise den Discovery Service, der das Suchen von Peers erlaubt, und den Membership-Service, der den Beitritt zu einer Peer Group ermöglicht [Cho04b]. 21 JXTA ist ein Synonym für den englischen Begri juxtapose, der soviel wie nebeneinander bedeutet. Gemeint ist damit, dass sowohl die klassische Client/Server- wie auch die P2P-Architektur immer nebeneinander existieren und sich keine der beiden für alle Anwendungsgebiete durchsetzen wird [Cho04b]. 21

28 2. Grundlagen Abbildung 2.10.: JXTA-Architektur JXTA Application In der Applikationsschicht benden sich Anwendungen, die auf der JXTA- Technologie basieren und die JXTA-Dienste verwenden. Somit ist jede auf JXTA-Basis entwickelte Anwendung Teil dieser Architekturschicht. Konzepte Im weiteren sollen hier noch kurz einige der im vorigen Abschnitt erwähnten Grundkonzepte vorgestellt werden, auf denen die durch JXTA denierten Protokolle basieren. Diese Konzepte beschreiben den eigentlichen Aufbau der JXTA-Technologie. Als Quelle für die folgenden Beschreibungen dienten die Arbeiten [SM03] und [Cho04b]. Peers Ein Peer ist ein beliebiges Netzwerkgerät, welches ein oder mehrere JXTA-Protokolle implementiert, wobei mehrere Peers auf einem Gerät laufen können. Jeder Peer arbeitet unabhängig und asynchron von allen anderen Peers und besitzt eine eindeutige ID. Peer Groups Bei einer Peer Group handelt es sich um eine Ansammlung von Peers, die sich auf eine Menge von allgemeinen Diensten geeinigt haben. Peers können dabei mehr als einer Peer Group angehören. Kommunikation zwischen Peers ist nur möglich, wenn sie derselben Peer Group angehören. Die allgemeinste Peer Group ist die Net Peer Group, die Basisdienste anbietet und der standardmäÿig alle Peers im Netzwerk angehören. Auf Grundlage dieser Dienste ist also Kommunikation zwischen allen Netzwerkteilnehmern möglich. Network-Services Dieses Konzept kapselt alle im Netzwerk verfügbaren Dienste. Dabei wird zwischen Peer-Diensten und Peer-Group-Diensten unterschieden. Ein Peer-Dienst läuft nur auf einem einzelnen Peer und wird von ihm im Netz angeboten. Andere Peers können danach suchen und ihn in Anspruch nehmen. Peer-Group-Dienste laufen auf allen Peers der zugehörigen Peer Group. Hierdurch sind sie allen Peers bekannt und müssen somit auch nicht gesucht werden. Pipes Pipes sind asynchrone und unidirektionale Nachrichten-Transfer-Mechanismen zwischen verschiedenen Peers. Sie sind also ein virtueller Kommunikationskanal, und können Peers verbinden die keine direkte physikalische Verbindung haben. Jede Pipe besitzt einen Endpunkt, der entweder Input Pipe (Empfang) oder Output Pipe (Senden) genannt wird. Sie können in Unicast Pipes (1 zu 1) und Propagate Pipes (1 zu n) unterteilt werden. 22

29 2.4. Distributed Information Retrieval Messages Eine Message (deutsch: Nachricht) stellt die Basiseinheit für den Datenaustausch zwischen Peers dar. Sie werden über den Pipe Service gesendet und empfangen. Eine Nachricht kann dabei binär oder im XML-Format kodiert sein. Advertisements Alle JXTA-Ressourcen (Peers, Pipes, Services etc.) werden durch Advertisements veröentlicht. Advertisements enthalten Metadaten zu einer bestimmten Ressource und werden durch XML-Dokumente repräsentiert. Peers können Ressourcen lokalisieren, indem sie nach dem zugehörigen Advertisement suchen. Jeder Ressourcen-Typ hat dabei sein eigenes Advertisement. So enthält beispielsweise ein Peer Advertisement den Namen des Peers, seine ID und verfügbare Endpunkt-Adressen. IDs Um JXTA-Ressourcen wie beispielsweise Peers, Peer Groups und Pipes eindeutig identi- zieren zu können, erhalten sie eine sog. JXTA-ID. Eine solche ID ist 128 Bit lang und wird zufällig generiert. Bei der Erzeugung ieÿt auch durch Hash-Funktionen gewonnene ressourcenspezische Information mit in die ID ein, so dass die Wahrscheinlichkeit für doppelte IDs sehr gering ist.ein Beispiel für eine JXTA Peer ID ist: urn:jxta:uuid a f3bc76ff13c2414cbc0ab663666da53903 Zusätzlich zu den Konzepten werden hier noch kurz zwei spezielle Peers vorgestellt, die eine besondere Position bei der Verwaltung der Netzwerktopologie einnehmen. Dabei handelt es sich um die sog. Relay- und Rendezvous Peers. Die folgenden Beschreibungen wurden aus [TAA + 03] abgeleitet. Rendezvous Peers unterstützen andere Peers bei ihrer Suche nach Ressourcen, indem sie Suchanfragen weiterleiten. Ein solcher Rendezvous Peer sieht dabei nur Anfragen aus Peer Groups, bei denen er selbst auch Mitglied ist. In einer Peer Group muss mindestens ein Rendezvous Peer vorhanden sein, nach oben sind hier keine Grenzen gesetzt (das Maximum ist natürlich die Anzahl aller Peers in der Peer Group). Ein Relay Peer ist für das Routing (deutsch: Weiterleiten) von Nachrichten im JXTA-Netzwerk zuständig. Ist beispielsweise eine direkte Verbindung zweier Peers nicht möglich, weil sich ein Peer in einer NAT-Umgebung 22 bendet, erfolgt die Kommunikation über einen Relay Peer. Relay Peers verbinden also verschiedene physische oder logische Netzwerke miteinander und erzeugen so ein zusammenhängendes, virtuelles Netzwerk (vgl. Abbildung 2.9). Beide Funktionalitäten sind als Dienste realisiert und können von jedem Peer angeboten werden. Ein einzelner Peer kann dabei auch beide Dienste anbieten und daher sowohl als Rendezvous- wie auch Relay Peer fungieren Distributed Information Retrieval Nachdem bisher die Bereiche Information Retrieval und P2P-Technologie getrennt betrachtet wurden, soll in diesem Abschnitt nun eine Verbindung zwischen beiden Themengebieten hergestellt werden, und zwar durch das Forschungsgebiet des Distributed Information Retrieval (deutsch: Verteiltes IR), zu dem auch das Thema dieser Arbeit gezählt werden kann. Dazu soll zunächst das klassische IR kurz erläutert werden, um die Motivation für die Erschlieÿung dieses Forschungsgebietes zu verdeutlichen. Danach wird ein Blick auf das sog. klassische verteilte Retrieval geworfen, das den ersten Evolutionsschritt in diesem Gebiet markiert, sich allerdings 22 NAT steht für Network Address Translation und wird häug verwendet, um Geräten in lokalen Netzwerken den Zugang zum Internet zu ermöglichen. 23

30 2. Grundlagen noch sehr stark am klassischen IR orientiert. Zuletzt werden dann einige Ansätze vorgestellt, die sich mit der Entwicklung von Technologien für IR in P2P-Umgebungen beschäftigt und damit tatsächliches verteiltes Retrieval realisiert Das klassische Information Retrieval Die klassische Architektur eines Information-Retrieval-Systems basiert auf dem Client/Server- Prinzip, es existiert hier also ein zentrales System. Dieses System übernimmt nun alle anfallenden Aufgaben (siehe Abbildung 2.11 aus [Eis02]). So sind auf dem Server die im System verfügbaren Dokumente abgelegt, der damit für die Speicherung und Verwaltung dieser Dokumente verantwortlich ist. Weiterhin werden hier auch alle im Zusammenhang mit IR anfallenden Aufgaben durchgeführt. Dies betrit beispielsweise die Indexierung von Dokumenten, die Ähnlichkeitssuche oder das Ranking der Ergebnismengen. Abbildung 2.11.: Klassisches IR Aus diesem klassischen Modell ergeben sich nun einige mögliche Probleme. Zunächst stellt der Server, wie in jeder Client/Server-Umgebung, einen Single Point of Failure dar. Bei einem Systemausfall wären also weder die Dokumente noch die IR-Dienste erreichbar. Weiterhin verfügt ein zentrales System nur über begrenzte Ressourcen, was das System nur begrenzt skalierbar 23 macht. Auch die Kosten für die Hardware müssen berücksichtigt werden, da diese mit zunehmender Leistungsfähigkeit überproportional ansteigen. Um nun diese durch die Architektur bedingten Problematiken aufzulösen, mussten neue Ansätze gefunden werden die auch eine Veränderung der Architekturen mit sich bringen. Als erster Schritt in diese Richtung wurde das klassische Distributed IR eingeführt. [HE02] Das klassische Distributed Information Retrieval Das klassische verteilte IR stellt eine Art Hybrid-System dar, basierend auf Konzepten aus dem klassischen und dem verteilten IR. Gemeint ist damit ein Ansatz, bei dem ein Client eine Anfrage an einen Server übermittelt. Dieser fungiert als Proxy 24 und schickt die Anfrage 23 Ein System skaliert gut, wenn es beispielsweise bei der zehnfachen Nenn-Last (d.h. Leistung) mit ca. den zehnfachen Ressourcen auskommt. Ein schlecht skalierendes System hingegen würde vielleicht bei doppelter Last bereits die zehnfachen Ressourcen benötigen, und bei zehnfacher Last komplett versagen [Wik04]. 24 Ein Proxy bzw. Proxyserver fungiert als Zwischenstation zwischen einem anfragenden Client und einem angefragten Server. Im einfachsten Fall leitet der Proxy die Daten einfach weiter, üblicherweise hat er aber noch (wie in diesem Fall) weitergehende Funktionen [Wik04]. 24

31 2.4. Distributed Information Retrieval an weitere IR-Systeme. Die Ergebnisse werden auf dem Proxy zwischengespeichert, in eine einheitliche Repräsentation überführt und von Duplikaten befreit. Dieser Ansatz erlaubt zumindest eine verteilte Datenhaltung, es besteht aber weiterhin das Problem des Single Point of Failure. Im übrigen sind mit diesem System nur geringe Performance-Zugewinne zu erwarten, da ja nur die Datenhaltung verteilt wurde, die eigentlichen IR-Aufgaben aber immer noch von jedem einzelnen System wahrgenommen werden müssen. Weiterhin muss die Verwaltung der Dokumente zentral auf jedem Server vorgenommen werden. Abbildung 2.12 verdeutlicht den Aufbau eines solchen Systems [Eis02]. Abbildung 2.12.: Klassisches Verteiltes IR In [GFK00] wird ein agentenbasiertes System mit dem Namen Daodil (Distributed Agents for User-Friendly Access of Digital Libraries) vorgestellt, welches auf der Basis der oben beschriebenen Architektur IR für eine Vielzahl von im Internet frei verfügbaren digitalen Bibliotheken ermöglicht. Daodil fungiert dabei aus Benutzersicht als eine einzige, virtuelle digitale Bibliothek, die alle Kollektionen aus den angeschlossenen Bibliotheken durch die Bereitstellung von unterstützenden Funktionen durchsuchbar macht. Weiterführende Informationen zu dem Projekt sind über dessen Web-Seite [Daf04] zu erhalten State-of-the-Art bei Information Retrieval in Peer-to-Peer-Netzen Der vorgenannte Ansatz erlaubt zwar, wie schon erwähnt, eine verteilte Datenhaltung. Er ermöglicht aber immer noch kein vollständiges, verteiltes Information Retrieval, da ja die IR- Aufgaben weiterhin auf einem zentralen Gerät durchgeführt werden. Daher muss für verteiltes Retrieval auch eine entsprechende, eben verteilte, Umgebung vorhanden sein, in der dann die für IR notwendigen Verfahren und Methoden implementiert werden. Zusätzlich müssen bei der Implementierung solcher Verfahren auch die, bedingt durch die verteilte Umgebung, neu aufgekommenen Fragen hinsichtlich der veränderten Rahmenbedingungen berücksichtigt werden. Aus diesem Grund sollen an dieser Stelle einige Forschungsarbeiten vorgestellt werden, die sich mit dem Gebiet des Information Retrieval in P2P-Netzen beschäftigen Clustering in P2P-Netzen auf Grundlage von Concept Maps In einem P2P-Netzwerk spiegelt ein Peer normalerweise die Interessen seines Benutzers wider. Dies wären im Kontext eines File-Sharing-Netzwerkes beispielsweise favorisierte Musikstücke oder Texte. In [GKS03a] wird nun ein Ansatz vorgestellt, der auf sog. Concept Maps (deutsch: 25

32 2. Grundlagen Konzept-Karten) basiert. Dabei wird erläutert, wie solche Konzept-Karten dazu verwendet werden können, um einzelne Peers in ähnliche Interessensgruppen aufzuteilen. Beim klassischen Information Retrieval werden primär die Daten und weniger die Quellen selbst betrachtet. Die oben angesprochene Eigenschaft von Geräten in P2P-Netzwerken würde es nun erlauben, nicht Daten sondern die Quellen selbst in ähnlichen Interessengruppen zu gruppieren. Dazu müssten die Quellen allerdings ihren Benutzer in einer vom Computer verwendbaren Art und Weise repräsentieren. In [GKS03b] wird nun folgende Hypothese aufgestellt: Durch geeignete Experimente ist es möglich, die Assoziationen zwischen den mentalen Konzepten einer Person zu ermitteln und daraus eine Konzept-Karte zu erstellen, in der Konzepte und Assoziationen als Knoten und gerichtete Kanten eines Graphen veranschaulicht werden. Unterschiede und Gemeinsamkeiten in Interessen, Sozialisation und vielleicht sogar Charakter einzelner Personen spiegeln sich in den Unterschieden und Gemeinsamkeiten der Konzept-Karten wieder. Daher können Konzept-Karten für die Personalisierung von Software eingesetzt werden. Ein so personalisierter P2P-Client könnte geeignete Tauschpartner anhand der Gemeinsamkeiten auswählen und vorschlagen. Unter Verwendung geeigneter Metriken kann nun der Abstand solcher Konzept-Karten gemessen und somit ihrer Ähnlichkeit bestimmt werden. Damit ist es möglich, eine Vielzahl solcher Karten in Gruppen von ähnlichen Karten einzuteilen [GKS03b] Query Routing in P2P-Netzen In einem P2P-Netz stellt in der Regel jeder Peer Ressourcen für alle Benutzer im Netzwerk zur Verfügung. Wird nun eine Anfrage formuliert, muss diese an die anderen Netzwerkteilnehmer übermittelt werden. Ein einfacher Ansatz wäre die Überutung des Netzes (Query Flooding), um eine möglichst groÿe Anzahl von Peers zu erreichen und somit die Wahrscheinlichkeit zu erhöhen, relevante Dokumente zu nden. Solche Flooding-Verfahren haben allerdings einige Nachteile (siehe ) und sollten daher in der Praxis vermieden werden. In [EHM03] wird nun auf das sich durch die Verteiltheit der Ressourcen ergebende Problem der Weiterleitung von Anfragen eingegangen und ein Lösungsansatz vorgestellt. Der folgende Text basiert dabei zum göÿten Teil auf [Eis03]. Bei diesem Ansatz wird vorgeschlagen, Anfragen nur an solche Peers weiterzuleiten, die auch mit hoher Wahrscheinlichkeit relevante Dokumente zur entsprechenden Anfrage liefern können. Um dies zu ermöglichen, muss ein Peer Information über die Ressourcen auf den anderen Peers besitzen. Da der Austausch vollständiger Kollektionsbeschreibungen aufgrund der damit verbundenen Datenmenge nicht praktikabel erscheint, sollen stattdessen kompakte Repräsentationen verwendet werden. Für eine solche Repräsentation wird hier nun vorgeschlagen, ein globales Clustering der Dokumente zu erstellen. Da dieser Ansatz für reine P2P-Netze vorgesehen ist, entfällt hier die Möglichkeit, einigen dedizierten Peers die Rolle eines globalen Verzeichnisses zuzuweisen. Stattdessen erstellt jeder Peer ein Clustering seiner eigenen Dokumentenkollektion. Soll nun auf einen Peer ein globales Clustering erstellt werden, so übermittelt dieser seine eigenen Cluster- Zentroiden in Form einer Anfrage an Peers in seiner Nachbarschaft. Diese leiten nun ihrerseits die Anfrage an Peers in ihrer Nachbarschaft weiter. Ist kein weiterer Peer in der Nachbarschaft vorhanden, so verbindet ein Peer seine eigenen Zentroiden mit den in der Anfrage übermittelten Zentroiden und liefert dieses Ergebnis an den anfragenden Peer zurück. Dieser Vorgang 26

33 2.4. Distributed Information Retrieval wird iterativ weitergeführt, bis der initiale Peer das Ergebnis erhalten hat, und somit über ein globales Clustering der einzelnen Kollektionen aller Peers verfügt Das Projekt Pepper Im Projekt Pepper 25 werden Dienste für die föderierte Suche in vielen, komplexen, und nur lose gekoppelten digitalen Bibliotheken (DBen) in P2P-Architekturen entwickelt. Dabei geht es um die Lösung der im Zusammenhang mit föderierten DBen bestehenden Problematiken [Fuh99]. So unterscheiden sich solche Bibliotheken beispielsweise in Bezug auf das Schema, das ihre Dokumente verwenden. Die nun folgende Beschreibung der Aufgaben und Ziele des Projekts orientiert sich hauptsächlich an der Beschreibung, die auf der Projektwebseite zu nden ist (siehe Fuÿnote). Unter der Voraussetzung, dass es weder möglich noch erstrebenswert ist, Homogenität bei diesen DBen durchzusetzen, werden im Rahmen des Projekts Methoden entwickelt, welche die Übersetzung von Anfragen und Dokumenten von einem Schema in ein anderes realisieren. Des Weiteren erfordern P2P-Netze Dienste, die das Weiterleiten von Anfragen im Netz ezient steuern. Um diesem Punkt Rechnung zu tragen, sollen Methoden für inhaltsbezogene Routing-Services implementiert, und die hieraus resultierenden neuen Fragestellugen (z.b. die Aufgabenstellung, ob eine Anfrage lokal behandelt werden kann oder im Netz weitergeleitet wird) behandelt werden. Um eine Interoperabilität mit anderen Arbeiten zu gewährleisten, bildet die Grundlage für die zu entwicklenden Methoden das derzeit auch in zahlreichen weiteren Projekten verwendete und im vorgigen Abschnitt vorgestellte P2P-Framework JXTA. Abbildung 2.13.: Schematischer Aufbau des P2P-Netzes im Projekt Pepper Die für das Projekt benötigte Basisarchitektur für Resource Selection in P2P-Netzen wird dabei aus Hubs und Service Provider Peers bestehen. Das P2P-Netzwerk hat also eine hybride Struktur (vgl ). Die einzelnen Komponenten werden dabei anhand ihrer Dienste und Aufgaben unterschieden, die sie im Netzwerk anbieten bzw. wahrnehmen. Ein Peer ist hier immer mit maximal einem Hub verbunden. Abbildung 2.13 verdeutlicht diesen Aufbau schematisch. Die notwendigen Implementierungen (grundlegender Klassen für Hubs und Suchservices etc.) werden im Rahmen der Diplomarbeit [Tit04a] durchgeführt

34 2. Grundlagen Verzeichnisknoten (Hub) Hubs sind eine spezielle Form von Peers, denen eine bestimmte statische Aufgabe zugeteilt wurde. In diesem Fall verbinden sich andere Peers mit ihnen und registrieren dort ihre bereitgestellten Dienste. Hubs übernehmen also eine Verzeichnisfunktion, und sind somit beispielsweise für das Weiterleiten von Anfragen im Netzwerk verantwortlich. Da Hubs häug eine groÿe Menge von Aufgaben übernehmen müssen, steht ihnen in der Regel eine hohe Rechenleistung zur Verfügung. Service Provider Peer (Peer) Peers stellen die meisten Dienste im Netz bereit. Auch werden hier die im Netzwerk angebotenen Ressourcen abgelegt. Peers verbinden sich ausschlieÿlich mit Hubs, d.h es gibt keine direkten Verbindungen zwischen zwei Peers. In [Tit04b] wurde eine Übersicht über die geplante Implementierung der Dienste in der Basisarchitektur gegeben. Da sich die Entwicklung zu diesem Zeitpunkt noch im Anfangsstadium befand, sind spätere Änderungen im Rahmen der Implementierung nicht auszuschlieÿen. Die Übersicht stellt also lediglich einen zu diesem Zeitpunkt gültigen Ansatz dar. In Abbildung 2.14 ist dieser Ansatz schematisch dargestellt. Abbildung 2.14.: Dienste in der Basisarchitektur im Projekt Pepper 28

35 3. Browsing in Peer-to-Peer-Netzen Auf Basis der im vorigen Kapitel vermittelten Grundlagen wird hier nun ein Konzept für Clusterbasiertes Browsing innerhalb einer P2P-Umgebung vorgestellt. Für den Bereich des Clusterbasierten Browsings kommt dabei das in Abschnitt vorgestellte Scatter/Gather-Verfahren zum Einsatz. Die Entwicklung des Konzepts ist in mehrere Teilbereiche gegliedert und beginnt mit dem Entwurf von denkbaren Browsing-Strategien unter Berücksichtigung des erweiterten Systemverhaltens innerhalb einer P2P-Umgebung. Basierend auf diesen Strategien wird dann der technische Ablauf des Browsings beleuchtet, um so die notwendigen Funktionalitäten zu identizieren. Den Abschluss des Konzepts bilden konkrete Browsing-Dienste, welche die identizierten Funktionalitäten umsetzen und in einer P2P-Umgebung zur Verfügung stellen Entwicklung und Verzierung von Browsing-Strategien Der erste Schritt bei der Realisierung von Cluster-basiertem Browsing in P2P-Netzen ist die Entwicklung von Strategien, um so denkbare Zugrispfade aufzuzeigen. Dabei werden zunächst zwei wichtige Faktoren angesprochen, die durch die Verwendung einer P2P-Umgebung auftreten können und ergänzend hierzu die sich ergebenden Ziele erläutert. Im zweiten Teil werden dann die tatsächlichen Strategien vorgestellt, nach denen ein Anwender in den vorhanden Kollektionen nach dem Scatter/Gather-Prinzip browsen kann. Da diese Strategien nur einige mögliche Zugrispfade wiederspiegeln und ihnen keine konkreten Szenarien zu Grunde liegen, wird im letzten Abschnitt noch eine Benutzerbefragung durchgeführt, die eben auf Basis von konkreten Szenarien die Strategiewahl der Benutzer aufzeigt und so deren tatsächliche Nützlichkeit bewertet Ausgangspunkt und Ziele Anders als beim im Studienprojekt Yahoo für das Invisible Web entwickelten InveX- Werkzeug (vgl. [CLNT04] und 2.2.5), dessen Funktionalität sich momentan auf eine Ein- Gerät-Umgebung 1 beschränkt, muss in einer P2P-Umgebung ein erweitertes Systemverhalten berücksichtigt werden. Dieses erweiterte Systemverhalten lässt sich, in Ergänzung zu klassischen Client/Server-Systemen, durch die Faktoren Verteiltheit und Dynamik beschreiben. Verteiltheit Da in einer P2P-Umgebung viele Peers Ressourcen im Netzwerk anbieten, sind diese nicht mehr an einer zentralen Stelle abgelegt, sondern über das gesamte Netzwerk verteilt. In der Regel möchte aber ein Anwender auf sämtliche zur Verfügung stehenden 1 Durch den modularen Aufbau des Werkzeugs kann beim Einsatz einer netzwerkfähigen Datenbank als Speichersystem (beispielsweise der Open-Source-Datenbank MySQL ( nach dem Client/Server-Prinzip gebrowsed werden. Der Server übernimmt dann die Datenhaltung und die Berechnung der Cluster, der Client die Präsentation über die GUI. Am grundlegenden Systemverhalten ändert dies aber nichts. 29

36 3. Browsing in Peer-to-Peer-Netzen Ressourcen zugreifen können. Somit muss ein System mit diesem Zustand umgehen und ein Verfahren für den Zugri auf die verteilten Ressourcen anbieten können. Dynamik In einer P2P-Umgebung können Peers zu jeder Zeit das Netzwerk verlassen oder sich dem Netzwerk anschlieÿen. Da die Zeitpunkte dieser Ereignisse nicht vorhersagbar sind, kann die Verfügbarkeit von Geräten und damit ihrer Ressourcen, in diesem Fall der auf ihnen abgelegten Dokumente, nicht garantiert werden. Auch dieser Faktor muss von einem System berücksichtigt werden. Weiterhin sind nicht nur die Geräte innerhalb der P2P-Umgebung von einer gewissen Dynamik betroen, sondern auch die auf den Peers abgelegten Dokumentenkollektionen. So kann sich zu jeder Zeit der Inhalt einer Kollektionen ändern, sei es durch Hinzufügen, Ändern oder Löschen eines oder mehrerer Dokumente. Dieses Verhalten ist zwar nicht P2P-spezisch und tritt auch bei Client/Server-Umgebungen auf. Hier ist der Vorgang allerdings überschaubarer, da in der Regel die Änderungen nur auf einem Gerät bzw. nur von einer einzigen Person vorgenommen werden. Eine Änderung an einem Netzwerkknoten sollte also durch das System wahrgenommen und an die anderen Teilnehmer weitergegeben werden, um so immer den tatsächlichen Ist-Zustand wiederzuspiegeln. Der Faktor Verteiltheit bietet aus technischer Sicht einen grundlegenden Vorteil im Gegensatz zu klassischen System-Architekturen. Durch diese Eigenschaft ist das System beispielsweise robuster gegenüber Angrien, da hier im allgemeinen kein Single Point of Failure existiert. Weiterhin kann die Verfügbarkeit von Ressourcen beispielsweise durch gezielte Verteilung von Kopien im System erhöht werden. Allerdings sollte es Ziel sein, einen Benutzer bei seiner Interaktion mit dem System nicht mit der tatsächlichen physischen Verteiltheit zu konfrontieren, ihn also nicht in die Lage zu versetzten, sämtliche Datenquellen 2 einzeln und selbsttätig durchsuchen zu müssen. Vielmehr sollten ihm bei der Benutzung des Systems je nach eigener Präferenz verschiedene Sichten auf den Datenbestand zur Verfügung stehen und ihm so eine entsprechende Unterstützung ermöglichen. Weiterhin sollte ein Benuzter die im Netzwerk stetig vorhandene Dynamik (Peer- und Dokumentendynamik) nicht wahrnehmen. Das bedeutet: er sollte nur Ressourcen angezeigt bekommen, die auch wirklich (zumindest zum Zeitpunkt seiner Anfrage) verfügbar und damit abrufbar sind. Auÿerdem sollte seine Sicht auf die Kollektionen auch immer deren aktuellen Zustand widerspiegeln. Sind nach Beendigung einer Browsing-Sitzung beispielsweise von 9 interessanten Dokumenten nur 5 wirklich abrufbar, so ist dies ein äuÿerst unbefriedigender Zustand. In Abbildung 3.1 wird noch einmal das erweiterte Systemverhalten mit den Faktoren Verteiltheit und Dynamik skizziert. Nachdem diese beiden relevanten Faktoren sowie die daraus resultierenden Ziele betrachtet wurden, sollen nun die konkreten Zugrismöglichkeiten auf die Dokumente und damit die Strategien betrachtet werden. Bei diesen Strategien wird vorausgesetzt, dass die aus den angesprochenen Faktoren resultierenden Ziele gelten und ein Anwender weder mit der physikalischen Verteiltheit noch mit der möglicherweise auftretenden Dynamik konfrontiert wird. Die Strategien liefern daher nur eine abstrakte Beschreibung der einzelnen Abläufe, die Denition der notwendigen Funktionen sowie deren konkrete Umsetzung wird in den Abschnitten 3.2 und 3.3 behandelt. 2 Als Datenquelle bezeichnet man ein Repository (deutsch: Aufbewahrungsort), in dem Ressourcen abgelegt sind. Dabei kann es sich sowohl um ein einzelnes Gerät, als auch um einen logischen Zusammenschluss von mehreren Geräten handeln. Im Kontext dieser Arbeit ist damit aber in der Regel immer ein Peer gemeint. 30

37 3.1. Entwicklung und Verzierung von Browsing-Strategien Abbildung 3.1.: Schematische Darstellung des erweiterten Systemverhaltens Browsing-Strategien Basierend auf dem im vorigen Abschnitt analysierten erweiterten Systemverhalten stellt sich unter Berücksichtigung der dort herausgearbeiteten Faktoren nun die Frage, mit welchen Vorgehensweisen ein Anwender mit einem solchen System interagieren kann. Ein wichtiger zu berücksichtigender Faktor sind dabei die potentiellen Ziele eines Anwenders. Da sich die Ziele abhängig von der Situationen eines Anwenders entwickeln ist es sinnvoll, ihm in solchen Fällen verschiedene Vorgehensweisen anzubieten. So macht es beispielsweise einen Unterschied, ob sich ein Anwender einen Überblick über alle im Netzwerk verfügbaren Themen verschaen will oder aber nur Dokumente zu einer bestimmten Thematik sucht. Da Browsing einem Anwender durch exploratives Vorgehen erlaubt, sich in einem unbekannten Datenbestand einen Überblick zu verschaen, sollen hier nun einige denkbare Strategien vorgestellt werden, die jeweils eine andere, mögliche Zielsetzung der Anwender realisieren. Welche Zielsetzungen dies sind, wird zu Beginn der Beschreibung jeder einzelnen Strategie anhand eines konkreten Beispiels erläutert. Da sich diese Arbeit mit Cluster-basiertem Browsing beschäftigt und als Grundlage hierfür das Scatter/Gather-Verfahren zum Einsatz kommt, ist der eigentliche Ablauf der Browsing- Sitzungen in jedem Fall wie in beschrieben und damit bei allen denkbaren Strategien identisch. Allerdings erlaubt die in einer P2P-Umgebung existierende Verteiltheit der Datenquellen verschiedene Vorgehensweisen bei deren Auswahl zu realisieren und ermöglicht damit verschiedene Sichten auf die im System abgelegten Kollektionen. In Abbildung 3.2 sind drei denkbare Sichten auf die Kollektionen im System dargestellt, aus denen nun die unterschiedlichen Zugris-Strategien in Abhängigkeit von den Zielen eines Anwenders abgeleitet werden. Die unterschiedlichen Farbgebungen in der Abbildung werden in der Beschreibung der Strategien erläutert. Strategie 1 - Browsing in gesamter Kollektion: Diese Strategie beschreibt den einfachsten Fall von Browsing in P2P-Umgebungen und kann auch als Verallgemeinerung des originalen Scatter/Gather-Verfahrens auf P2P-Umgebungen verstanden werden. Da diese Strategie immer dann zum Einsatz kommen kann, wenn groÿe Dokumentenkollektionen erforscht werden sollen, wird an dieser Stelle kein konkretes Beispiel für die Zielsetzung gegeben. Hierbei fasst das System den gesamten Dokumentenbestand als eine einzige Kollektion auf. Einem Anwender wird hier eine vorher festgelegte Anzahl von Gruppen 31

38 3. Browsing in Peer-to-Peer-Netzen Abbildung 3.2.: Mögliche Sichten auf die im System abgelegten Kollektionen angezeigt, in denen sämtliche Dokumente nach ihrer inhaltlichen Ähnlichkeit gruppiert sind. Ansonsten nden hier keine weiteren Abgrenzungen statt. In diesen Gruppen kann nun nach dem Scatter/Gather-Prinzip nach Belieben in die Tiefe gebrowsed werden. In Abbildung 3.2 ist diese Sicht auf das System mit S 1 bezeichnet. Strategie 2 - Automatische Selektion interessanter Kollektionen/Datenquellen: Hat ein Anwender bereits eine konkrete Vorstellung darüber, in welchem Themengebiet eine gesuchte Information zu nden ist, so muss er sich nicht mehr mit dem gesamten Dokumentenbestand befassen. Stattdessen kann er sein Informationsbedürfnis beschreiben, wonach ihm dann vom System automatisch eine potentiell interessante Dokumentenkollektion/Datenquelle zur weiteren Durchsicht präsentiert wird. Ein denkbares Einsatzgebiet für diese Strategie wäre ein redaktionelles Umfeld, bei dem Dokumente über viele bereits recherchierte Themen im Netzwerk abgelegt sind, jedoch eine Information zu einem bestimmten Thema für einen Artikel/Bericht gesucht wird. Durch die so erfolgte Reduzierung der zu betrachtenden Dokumente erhöht sich die Übersicht, da ja hier nur ein kleiner Ausschnitt aus der Gesamtmenge betrachtet wird. In Sicht S 2 auf das System sind exemplarisch drei interessante Kollektionen/Datenquellen blau eingefärbt, eine intensivere Farbe bedeutet hier eine höhere thematische Relevanz für den Benutzer 3. Strategie 3 - Gruppierung der vorhandenen Datenquellen: Die vorherrschende Verteilung der Dokumente auf viele Peers macht es möglich, jeden Peer im Netzwerk als eine einzelne, kleine Dokumentenkollektion zu betrachten, welche die Interessen ihres Besitzers widerspiegeln. Ausgangspunkt dieser Strategie ist daher das Ziel eines Anwenders, sich einen Überblick über die Peers zu verschaen, die Dokumente zu ähnlichen Thematiken enthalten. Dabei werden diese Peers in Gruppen zusammengefasst, so dass dem Anwender eine diskrete Darstellung der verfügbaren Thematiken präsentiert wird. So könnten beispielsweise 3 Die angesprochene thematische Relevanz steht hier für eine systeminterne Relevanz, die durch das verwendete Maÿ bestimmt wird. Sie spiegelt nicht die situative Relevanz wieder, d.h. eine vom System hoch bewertete Kollektion ist für einen Benutzer nicht automatisch auch nützlich. [Fuh04] 32

39 3.1. Entwicklung und Verzierung von Browsing-Strategien Schnittmengen bei in verschiedenen Bereichen arbeitenden Abteilungen entdeckt, und damit nicht nur interessante Dokumente, sondern auch Ansprechpartner gefunden werden. Weiterhin kann hier nun wieder in die Tiefe gebrowsed werden, um so die Gruppierung der Peers noch weiter zu verfeinern. Abbildung 3.2, S 3 zeigt eine bildhafte Darstellung dieser Sicht. Ergänzend für alle Strategien ist hier noch zu erwähnen, dass ein Anwender die Möglichkeit haben sollte, zu jeder Zeit interessante Dokumente oder Kollektionen in einer persönlichen Handbibliothek abzulegen und hierauf auch nach Abschluss einer Browsing-Sitzung zuzugreifen. Denkbar wäre weiterhin, einem Anwender die Auswahl einer Browsing-Strategie nicht nur zu Beginn einer Sitzung, sondern auch im Verlauf dieser, einen Wechsel in eine andere Strategie zu ermöglichen. So könnte er sich beispielsweise zunächst einen Überblick über die verfügbaren Thematiken verschaen, um dann eine thematisch interessante Kollektion auszuwählen und darin weiter nach relevanten Dokumenten zu browsen Benutzerbefragung Im Rahmen dieser Diplomarbeit wurden Strategien entwickelt, die verschiedene Zugrispfade auf in P2P-Umgebungen abgelegte Dokumentenkollektionen beschreiben. Diese Strategien sind dabei abhängig von den gewünschten Zielen eines Anwenders gestaltet und ermöglichen die Identizierung der notwendigen, vom System bereitgestellten Funktionen. Um bei der Entwicklung eines Systems zum Browsing in P2P-Umgebungen die richtigen Funktionen bereitzustellen, muss zunächst geklärt werden, welche Strategien für einen Benutzer in konkreten Situationen nützlich sind und damit der Informationsndung dienen. Mit Hilfe dieser Erkenntnisse können dann die notwendigen Funktionen abgeleitet und bei der Realisierung des Systems berücksichtigt und implementiert werden. Vorgehensweise Da die im vorigen Abschnitt vorgestellten Strategien auf theoretischen Ansätzen beruhen und unabhängig von konkreten Szenarien entstanden sind, war es interessant herauszunden, ob eine kleine Anzahl von potentiellen Benutzern im Rahmen einiger konkreter Szenarien zur Informationsgewinnung tatsächlich nach diesen Strategien vorgehen würde. Weiterhin sollten Anregungen gesammelt werden, inwiefern diese Strategien noch erweitert werden können bzw. ob eventuell sogar völlig neue Strategien in diesem Zusammenhang sinnvoll erscheinen. Zu diesem Zweck wurde sechs Probanden der in Anhang B hinterlegte Befragungsbogen vorgelegt. Alle sechs Probanden haben akademische Vorkenntnisse, wobei jeweils drei dem Bereich der Informatik bzw. der Germanistik zuzurechnen sind. Die Wahl el hier bewusst auf diesen Personenkreis, da diese im Laufe ihres Studiums bzw. innerhalb ihres Tätigkeitsbereichs häug mit Informationsbeschaung und Literaturrechere konfrontiert werden und sich somit besser in die in den Szenarien vorgegebenen Situationen hineinversetzen können. Im Befragungsbogen werden drei Szenarien vorgestellt, die sich jeweils aus einer konkreten Situation mit zugehöriger Aufgabe und Zielsetzung zusammensetzen. Um die festgelegte Zielsetzung zu erreichen, sollten die Probanden anhand eines Ablaufdiagramms die einzelnen Schritte aufzeigen, die sie intuitiv auch bei der Iteraktion mit einer Software durchführen würden. Die gewählten Schritte wurden anschlieÿend mit den entwickelten Strategien verglichen, um so Übereinstimmungen zwischen beiden Vorgehensweisen zu nden. Von den drei Szenarien sind die ersten beiden nur für jeweils eine Probandengruppe bestimmt, das dritte Szenario ist 33

40 3. Browsing in Peer-to-Peer-Netzen für beide Gruppen ausgelegt. Somit werden also jeweils zwei Szenarien von den beiden Gruppen bearbeitet. Da auch die geeignete Repräsentation der Cluster einen wichtigen Faktor für Benutzer darstellt, sollten die Probanden bei der Bearbeitung des Befragungsbogens angeben, welche Information Sie sich bei der Betrachtung der Cluster wünschen. Um den Probanden eine Vorstellung davon zu vermitteln, wie eine solche Repräsentation aussehen kann, wurden dem Befragungsbogen Abbildungen des InveX-Werkzeugs beigefügt, die als prototypische Repräsentationen fungieren. Auf dieser Basis sollten die Probanden nun Änderungen/Ergänzugen der Repräsentationsform aufzeigen. Auswertung In den folgenden drei Tabellen sind die Ergebnisse der Befragung kompakt abgebildet. Die Probanden sind hier anonym mit Testperson X benannt, eine Bezeichnung ist aber fest einer bestimmten Person zugeordnet. So steht beispielsweise Testperson 1 in Tabelle 3.1 und 3.3 für den selben Probanden. Die Nummerierung der Strategien erfolgte hier in der selben Weise wie schon in Abschnitt Das X in einer Zeile bedeutet, dass sich ein Proband bei dem entsprechenden Szenario entweder für eine vorgegebene Strategie entschieden, oder aber einen alternativen Weg aufgezeigt hat. Weiterhin ist Szenario X auch Strategie X zugeordnet, d.h. wählt eine Probandin/ein Proband zu Szenario 1 auch Strategie 1 aus, so würde dies genau den Erwartungen entsprechen. Die Details zu den einzelnen Szenarien sind im Befragungsbogen (Anhang B) zu nden. Testperson 1 Testperson 2 Testperson 3 Strategie 1 Strategie 2 Strategie 3 Alternative X X X Tabelle 3.1.: Benutzer-Feedback zu Szenario 1 Testperson 4 Testperson 5 Testperson 6 Strategie 1 Strategie 2 Strategie 3 Alternative X X X Tabelle 3.2.: Benutzer-Feedback zu Szenario 2 Fazit Zusammenfassend lässt sich anhand der drei Ergebnistabellen erkennen, dass in keiner Situation eine alternative Vorgehensweise von den Probanden gewählt wurde. Ob diese Tatsache ein Indiz dafür ist, dass die vorgegebenen Schritte genau den Vorstellungen der Probanden entsprachen oder aber andere Gründe für dieses Verhalten verantwortlich waren, lässt sich durch diese Befragung nicht abschlieÿend klären. Insgesamt sprechen die Ergebnisse dafür, dass die entwickelten Strategien von einem potentiellen Benutzerkreis als sinnvoll erachtet werden. Bei Szenario 1 und 34

41 3.2. Identizierung der notwendigen Funktionen Testperson 1 Testperson 2 Testperson 3 Testperson 4 Testperson 5 Testperson 6 Strategie 1 Strategie 2 Strategie 3 Alternative X X X X X X Tabelle 3.3.: Benutzer-Feedback zu Szenario 3 3 wurde die beabsichtigte Vorgehensweise von den meisten Probanden eingehalten, lediglich bei Szenario 2 wurden andere Strategien zum Erreichen der Ziele gewählt. Auch spricht die Wahl einer anderen Strategie als der erwarteten nicht gegen die Nützlichkeit der Strategien, sondern ist vielmehr auf die Unschärfe der einzelnen Szenarien zurückzuführen. Ein weiterer wichtiger Faktor war das Feedback der Probanden zur Frage, welche zusätzliche Information sie sich bei der Präsentation der Cluster wünschen. Diese Frage wurde den Probanden zusätzlich zur Strategiebewertung gestellt und ndet sich nicht in den obigen Tabellen wieder, sondern wurde separat behandelt und ausgewertet. Im folgenden sind die einzelnen Anregungen aufgeführt, wobei die häugsten an vorderster Stelle zu nden sind. Für die Repräsentation sind die gekürzten Terme (term-stemming) wenig geeignet. Dies wurde bereits im Berichtsheft zum Studienprojekt Invisble Web ([CLNT04]) bemängelt, aus dem dieser Prototyp stammt. Ein Anwender sollte die Möglichkeit haben, während der Browsing-Sitzung zwischen einer dokumenten- und datenquellenorientierten Beschreibung der einzelnen Gruppen zu wechseln. Jede Gruppe sollte als Attribut eine Beschreibung der Computer (Computername und Anwender) enthalten, auf denen die zugehörigen Dokumente abgelegt sind. Dies soll die Kontaktaufnahme mit dem Besitzer eines Dokuments ermöglichen. Insgesamt lässt sich festhalten, dass der in dieser Arbeit zu entwickelnde Prototyp auf Basis der im vorigen Abschnitt vorgestellten Strategien realisiert werden kann. Unter Verwendung dieses Prototyps wäre dann eine weitergehende Bewertung durch eine gröÿere Anzahl von Probanden denkbar, um ein entsprechendes Feedback im Bereich der Präsentation und der Zugrispfade zu erhalten. Dies ist ezienter, da die Probanden so direkt mit der Software interagieren können und sich nicht in abstrakte Szenarien hineinversetzen müssen. Da der Schwerpunkt dieser Arbeit aber auf der Information-Retrieval-Sicht von Clustering in P2P-Netzen liegt, wird dies in diesem Rahmen nicht mehr umgesetzt Identizierung der notwendigen Funktionen Nach der Entwicklung der Browsing-Strategien muss ein System nun die technischen Voraussetzungen zur Verfügung stellen, damit ein Benutzer auch tatsächlich nach diesen Strategien mit dem System interagieren kann. Dazu müssen eine Reihe von Funktionen in das System 35

42 3. Browsing in Peer-to-Peer-Netzen implementiert werden. Um die einzelnen Funktionen gezielt zu identizieren, wird in diesem Abschnitt der technische Ablauf von Browsing in P2P-Netzen beleuchtet. Dazu werden die Abläufe auf technischer Ebene durchgespielt, die einzelnen Funktionen herausgearbeitet und eventuell aufgetretene Problemstellungen mit Lösungsansätzen erläutert. In Kapitel 3.3 werden dann Dienste vorgestellt, welche die hier beschriebenen Funktionen umsetzen Ablauf einer Browsing-Sitzung Zur Identizierung der Funktionen ist es sinnvoll, den denkbaren Ablauf einer Browsing-Sitzung direkt aus Benutzersicht durchzuspielen. Daher beschreibt die folgende Aufzählung die Handlungen und Eingaben eines Benutzers. Zusätzlich wird noch erläutert, welche Aufgaben das System nach einer solchen Interaktion wahrnimmt. Zur Identizierung der Funktionen reicht die Vorstellung dieser Abläufe aus, da sich die Strategien nur bei der Selektion der gewünschten Information unterscheiden und somit lediglich zu Beginn einer Sitzung andere Eingaben erforderlich sind. Zu Beginn einer Sitzung önet der Anwender die grasche Benutzeroberäche seines Browsing-Werkzeugs. Nun wird ihm ein Dialog angezeigt, in dem er eine für seine Ziele geeignete Strategie auswählen kann. Abhängig von der gewählten Strategie wird vom Benutzer noch eine weitere Eingabe verlangt. Die durchgeführten Eingaben werden vom System verarbeitet und notwendige Schritte (intern und netzwerkweit) ausgeführt, um die für die jeweiligen Strategien notwendigen Daten zu erhalten. Wurden alle benötigten Daten gesammelt/erzeugt, werden diese dem Benutzer als Cluster in seiner Benutzeroberäche angezeigt. Diese Cluster können nun ausgewählt und verfeinert werden, um mehr Information über die enthaltenen Dokumente/Datenquellen zu erhalten. Bei jedem dieser Schritte werden dann vom System erneut die notwendigen Aufgaben durchgefüht, um benötigte Daten zu sammeln bzw. zu erzeugen. Um die oben dargestellten Abläufe umzusetzen, wird als Grundlage das Browsing-Verfahren Scatter/Gather verwendet. Dieses wurde schon in Abschnitt vorgestellt, das Verfahren war bisher aber nicht für verteiltes IR in P2P-Umgebungen ausgelegt. In den folgenden Abschnitten soll das Verfahren deshalb für diese Technologie angepasst und dementsprechend erweitert werden Klassisches Scatter/Gather in P2P-Umgebungen Der einfachste Ansatz für Cluster-basiertes Browsing in P2P-Netzen wäre die analoge Übertragung des Scatter/Gather-Verfahren auf P2P-Umgebungen. Damit könnten die oben dargestelleten Abläufe realisiert werden, das System würde also die notwendigen Funktionen bereitstellen. 36

43 3.2. Identizierung der notwendigen Funktionen Im folgenden wird nun aufgezeigt, wie ein solcher Ansatz für reine P2P-Netze zu verwirklichen wäre. Dabei wird hier der allgemeine Ablauf von Scatter/Gather auf P2P-Umgebungen übertragen, ohne dabei spezielle Netzwerkkongurationen oder Browsing-Strategien zu berücksichtigen. Möchte ein Anwender in den im Netz verfügbaren Dokumenten nach dem Scatter/Gather- Prinzip browsen, so schlieÿt er sich zunächst dem Netzwerk an. Bevor nun das eigentlich Browsing beginnen kann, muss der Peer die Dokumente von allen im Netzwerk vorhandenen Peers einsammeln und lokal bei sich ablegen. Da der anfragende Peer nur seine direkte Nachbarschaft kennt, wird die Anfrage durch einen ooding-algorithmus im Netzwerk verbreitet. Details zu diesem Verfahren wurden schon in Abschnitt erläutert. Die gesammelten Dokumente sowie die eventuell lokal vorhandenen Dokumente werden dann vom eigenen System nach ihrer inhaltlichen Ähnlichkeit gruppiert und dem Anwender präsentiert. Ab diesem Punkt wäre der weitere Ablauf wie in Abschnitt beschrieben. Da bei diesem Ansatz die Dokumente alle lokal abgelegt wurden, sind keine weiteren Verbindungen zu anderen Netzwerkteilnehmern erforderlich. Hierdurch wird sichergestellt, dass auch alle angezeigten Dokumente tatsächlich verfügbar sind. Weiterhin kommt ein Anwender auch nicht mit der Verteiltheit der Dokumente in Kontakt, da er mit dem Prozess des Einsammelns ja nicht direkt konfrontiert wird, sondern das System diese Aufgabe übernimmt. Problematisch sind hier allerdings zwei Faktoren: Zum einen ist das Einsammeln aller Dokumente ab einer bestimmten Dokumentenmenge in Verbindung mit einer entsprechenden Netzwerkanbindung nicht mehr praktikabel, da hier der Zeitaufwand proportional zur Dokumentenanzahl ansteigt. Im übrigen ist das klassische Scatter/Gather-Verfahren ab einer bestimmten Dokumentenmenge ebenfalls nicht mehr praktisch anwendbar, da sich hier der Aufwand der Cluster-Algorithmen mit steigender Dokumentenanzahl erhöht und damit der Zeitaufwand ebenfalls stetig ansteigt. Der zweite Faktor betrit die im Netzwerk vorhandene Dynamik. Dabei soll auch hier zwischen Peer- und Dokumentendynamik unterschieden werden. Um immer mit den aktuellsten Kollektionen zu arbeiten, wären zwei Ansätze denkbar. Zum einen könnten die eingesammelten Dokumente nach Beendigung der Browsing-Sitzung vom eigenen Peer wieder gelöscht werden. Dadurch würde es notwendig, bei jeder Browsing-Sitzung alle Dokumente erneut abzurufen, was ab einer groÿer Dokumentenanzahl ebenfalls nicht praktikabel wäre. Zum anderen könnten Peers Änderungen an ihren Kollektionen bzw. ihr Ausscheiden aus dem Netzwerk den anderen Teilnehmern signalisieren. Aufgrund der ooding-technik würde dann aber die Netzwerkbelastung bei zunehmender Dynamik ebenfalls stark ansteigen, was im schlechtesten Fall Peers mit einer langsamen Netzwerkanbindung blockieren würde. Aufgrund der angesprochenen Problematiken ist dieser Ansatz für eine praktische Anwendung wenig geeignet und soll deshalb nicht weiter verfolgt werden. Stattdessen wird ein weiterer Ansatz vorgestellt, der auf die genannten Problematiken eingeht und damit eine bessere Grundlage für die weitere Entwicklung des Konzepts darstellt Optimierter Ansatz auf Basis von vorprozessiertem Scatter/Gather Um den beim vorhergehenden Ansatz identizierten Geschwindigkeits- und Erreichbarkeitsproblemen Rechnung zu tragen, werden hier zwei wesentliche Grundkonzepte abgeändert. Zunächst soll hier eine vorprozessierte Variante des Scatter/Gather-Verfahrens betrachtet werden. Hierbei wird die Geschwindigkeitsproblematik bei sehr groÿen Dokumentenkollektionen dadurch beseitigt, dass ein Anwender nicht mehr mit den Dokumenten selbst, sondern mit komprimierten 37

44 3. Browsing in Peer-to-Peer-Netzen Darstellungen bzw. Prolen der Kollektionen arbeitet. Diese Prole werden dabei in derselben Form wie die Dokumente repräsentiert, in Abschnitt wurde diese Variante detailliert vorgestellt. Weiterhin basiert hier die P2P-Technologie nicht mehr auf reinen P2P-Netzen, sondern es wird ein hybrider Ansatz verfolgt. Dabei wird zwischen zwei Komponenten im Netzwerk unterschieden, nämlich den Hubs und den Peers, die damit auch unterschiedliche Aufgaben im Netzwerk wahrnehmen können. Mit diesen veränderten Grundkonzepten lassen sich nun die aufgedeckte Problematik der Erreichbarkeit aller Peers und der groÿen Datenmengen dadurch entschärfen, dass Informationen über die im Netzwerk vorhandenen Kollektionen an einer zentralen Stelle abgelegt werden. Dabei wird zunächst die jetzt vorhandene Zwei-Komponenten-Struktur derart genutzt, das eine Geräteklasse solche zentralen Verwaltungsaufgaben wahrnimmt. Dies kann im betrachteten, hybriden Netzwerk durch eine Verzeichnisfunktion der Hubs realisiert werden. Für den Aufbau eines solchen Verzeichnisses bieten sich weiterhin die durch das zweite veränderte Grundkonzept, dem vorprozessierten Scatter/Gather-Verfahren, generierten komprimierten Darstellungen an, welche durch die sog. Metadokumente 4 repräsentiert werden. Da diese spezielle Form von Dokumenten die gleiche Information wie die echten Dokumente enthält, sind sie mit ihnen vergleichbar und können vom System wie diese behandelt werden. Da die Metadokumente aber auch eine hierarchische Struktur bilden, enthält jedes dieser Dokumente zusätzlich noch eine Information über untergeordnete (Meta)Dokumente. Soll nun eine Browsing-Sitzung gestartet werden, so wird hierzu das auf einem Hub abgelegte Verzeichnis genutzt. Das eigentliche Browsing ndet also, wie bei der vorprozessierten Scatter/Gather-Variante auch, unter Verwendung der Prole, also der Metadokumente, statt. Je nach Auswahl der Cluster werden dann im Verlauf der Browsing-Sitzung weitere (Meta)Dokumente von den entsprechenden Peers nachgeladen. Da hier immer nur die tatsächlich benötigte Information übertragen wird, bleibt das Datenaufkommen insgesamt deutlich geringer als beim in vorgestellten Ansatz. Um diese Funktion zu ermöglichen, wird vorausgesetzt, dass sich ein Peer nach seinem Beitritt zum Netzwerk sofort mit einem Hub verbindet, Daten über seine Kollektion an den Hub liefert und auch von dort seine zum Browsing benötigte Information erhält. Weitere Geräte im Netzwerk muss dieser Peer daher zunächst nicht aunden. Auf dem Hub sind dabei Informationen zu allen im Netzwerk vorhandenen Kollektionen abgelegt. Sind mehrere Hubs im Netzwerk vorhanden, tauschen sie ihre Information untereinander aus. Aufgabe eines Hubs ist es dann, diese gesammelte Information in geeigneter Form zu einer Gesamtübersicht, also zu einem globalen bzw. netzwerkweiten Clustering, zu kombinieren. In Tabelle 3.4 werden die einzelnen Aufgabenfelder noch einmal kompakt dargestellt. Da bei diesem Ansatz mit Prolen anstelle der tatsächlichen Dokumente gearbeitet wird, ist damit das Problem des hohen Datenaufkommens durch die Inter-Peer-Kommunikation gelöst. Allerdings müssen hier die Faktoren Peer- und Dokumentendynamik genauer betrachtet werden. Werden Kollektionen aktualisiert oder verlassen Peers das Netzwerk, so muss das auf den Hubs abgelegte Verzeichnis entsprechend angepasst werden, sonst würde das Verzeichnis ja nur einen kurzen zeitlichen Ausschnitt der Kollektionen im Netzwerk wiedergeben. Weiterhin muss noch untersucht werden, ob die verwendeten komprimierten Darstellungen genügend Information enthalten, um die repräsentierten Dokumente/Kollektionen ausreichend zu beschreiben. Diese 4 Metadokumente enthalten, wie der Name schon sagt, Meta-Informationen über die Dokumente die sie repräsentieren. Der im InveX-Werkzeug verwendete Typ besteht beispielsweise aus der Anzahl der enthaltenen Dokumente, einigen Dokumententiteln, den am höchsten gewichteten Termen sowie den Namen der Dokumentenkollektionen mit deren zugehöriger Dokumentenanzahl. 38

45 3.2. Identizierung der notwendigen Funktionen Peer Repository für Dokumente Bereitstellung einer GUI für Benutzerinteraktionen Abrufen der Gesamtübersicht vom verbundenen Hub Clustern von (Meta)Dokumenten (Meta)Dokumente zu Peers/Hubs übertragen (Meta)Dokumente von Peers/Hubs laden Hub Nur Verzeichnisfunktion Kombinieren der verfügbaren Kollektionen zu einem globalen Clustering Übertragen dieses Clusterings zu anfragenden Geräten Clustern von (Meta)Dokumenten Tabelle 3.4.: Funktionsübersicht von Peers und Hubs Themen werden bei der konkreten Umsetzung der Funktionen im folgenden Abschnitt weiter behandelt. Zum Abschluss diese Unterkapitels sollen hier aber noch einmal, basierend auf den abgeleiteten Funktionen, die genauen technischen Abläufe einer Browsing-Sitzung durchgespielt werden. In Abbildung 3.3 sind diese Abläufe grasch dargestellt, beginnend bei dem Beitritt eines Peers zum Netzwerk bis zum Beenden der Sitzung. Abbildung 3.3.: Technischen Sicht auf P2P-Browsing 1. Tritt ein Peer dem Netzwerk bei, verbindet er sich sofort mit einem beliebigen Hub. Daraufhin fordert der Hub eine komprimierte Darstellung bzw. das Prol der Dokumentenkollektion auf dem Peer an. 2. Ist auf dem Peer noch keine komprimierte Darstellung gespeichert, so erzeugt er eine und übermittelt diese dann an den anfragenden Hub. 3. Hat der Hub das angeforderte Prol vom Peer erhalten, so signalisiert er den anderen Hubs im Netzwerk die Änderung und übermittelt direkt das neue Prol an alle im Netzwerk 39

46 3. Browsing in Peer-to-Peer-Netzen vorhandenen Hubs. Nach der Übermittlung verwendet er dann das neu erhaltene Prol, um dieses mit seinen, wenn vorhanden, bereits gespeicherten Prolen zu kombinieren und daraus ein neues, globales Clustering zu erstellen. Die anderen Hubs verfahren nach dem Erhalt des Prols nach dem selben Muster. Eine Änderung an einem Punkt des Netzwerkes wird also direkt durch ein Push-Verfahren 5 im Netzwerk propagiert. 4. Will nun ein Client in den Kollektionen im Netzwerk browsen, so fordert er von seinem Hub das globale Clustering an. 5. Der Hub übermittelt daraufhin sein erzeugtes Clustering an den anfragenden Peer. Dieses Clustering bildet nun die Grundlage für den ersten Scatter/Gather-Schritt. 6. Je nach Auswahl des Benutzers müssen bei jedem Browsing-Schritt Dokumente nachgeladen werden. Dazu baut der Peer direkte Verbindungen zu den jeweiligen Peers auf, die die benötigten Dokumente zu Verfügung stellen. Dieser Vorgang wird so lange wiederholt, bis die Browsing-Sitzung beendet wird Denition der Browsing-Dienste In diesem Abschnitt sollen nun die identizierten, notwendigen Funktionen konkret für die jeweiligen Netzwerkkomponenten umgesetzt werden. Dies geschieht durch die Denition von Browsing-Diensten, welche die beschriebenen Funktionen kapseln und in einer P2P-Umgebung zu Verfügung stellen. Diese Dienste versetzen also einen Benutzer in die Lage, nach dem Scatter/Gather-Verfahren in den im System vorhandenen Dokumentenkollektionen zu browsen. Die Denition dieser Dienste ist gleichzeitig auch der letzte Schritt bei der Entwicklung des Gesamtkonzepts, unter dessen Verwendung im nächsten Kaptitel die prototypische Implementierung erfolgen soll Browsing-Dienste für Hubs In der hier betrachteten hybriden P2P-Umgebung übernehmen die Hubs, wie schon im vorigen Abschnitt angesprochen, die Funktion eines globalen Verzeichnisses. Dieses globale Verzeichnis soll eine aktuelle Übersicht über alle im Netzwerk verfügbaren Dokumente bzw. Kollektionen enthalten. Je nach ausgewählter Browsing-Strategie wird dann auf Anfrage das Verzeichnis oder ein ausgewählter Teil an den entsprechenden Peer übermittelt, der dann weitere benötigte (Meta)Dokumente direkt von den involvierten Peers nachladen kann. Dabei wird die allgemeine P2P-Funktionalität (Aufbau/Annahme von Verbindungen, etc.) bei der Entwicklung der Dienste als gegeben angesehen. Aus welchen Daten ein solches Verzeichnis aufgebaut werden kann, nämlich aus den im Rahmen der vorprozessierten Scatter/Gather-Variante erzeugten Prolen, wurde schon im vorigen Abschnitt angesprochen. Allerdings müssen bei der Verwendung eines solchen Verzeichnisses einige Faktoren berücksichtigt werden, um mit den in Abschnitt denierten Zielen konform zu bleiben: 1. Ist der Informationsgehalt eines solchen Verzeichnisses ausreichend? 5 Beim Push-Verfahren werden Daten ohne direkte Anfrage an eine Teilmenge von Teilnehmern einer Domäne übermittelt. Einen gegensätzlichen Ansatz verfolgt das Pull-Verfahren, bei dem Daten immer explizit angefordert werden müssen. 40

47 3.3. Denition der Browsing-Dienste 2. Wie wird auf die im Netzwerk vorherrschende Dynamik reagiert? Informationsgehalt des Verzeichnisses Zur Erzeugung des globalen Clusterings, auf deren Grundlage ja das eigentlich Browsing stattnden soll, wird die bei der vorprozessierten Scatter/Gather-Variante generierte Cluster-Hierarchie verwendet. Dabei muss zunächst jeder Peer, der dem Netzwerk beitritt, eine solche Hierarchie seiner eigenen Dokumentenkollektion erzeugen. In dieser Hierarchie stellt das Wurzelelement eine komprimierte Darstellung der gesamten Dokumentenkollektion des Peers dar. Dieses Wurzelelement beschreibt also in kompakter Form die thematische Ausrichtung der Kollektion und damit auch des zugehörigen Peers. Die Anzahl der Kinder des Wurzelelements entspricht der Anzahl Cluster, die erzeugt werden sollten und kann vorher von einem Anwender angegeben werden. Um nun das globale Clustering zu generieren, überträgt ein Peer, sobald er dem Netzwerk beitritt, Teile seiner Cluster-Hierarchie an den mit ihm verbundenen Hub. Allerdings ist hier noch nicht unmittelbar klar, wie viel tatsächlich übermittelt werden muss, um genügend Information über die eigene Kollektion zur Verfügung zu stellen. Zunächst soll hier deshalb davon ausgegangen werden, dass jeder Peer die oberste Ebene seiner Cluster-Hierarchie an den entsprechenden Hub übermittelt. Abbildung 3.4 zeigt einen Ausschnitt aus einer solchen Hierarchie, der rot umrandete Bereich kennzeichnet dabei deren oberste Ebene. Abbildung 3.4.: Oberste Ebene einer Cluster-Hierarchie Nun ist allerdings leicht einzusehen, dass der Informationsgehalt der Metadokumente in dieser obersten Ebene stark von der Gröÿe und der thematischen Beschaenheit der Kollektion abhängig ist. So werden beispielsweise bei thematisch sehr homogenen Kollektionen mehr Details benötigt, um eine genauere Dierenzierung der einzelnen Thematiken vorzunehmen als bei einer durchweg heterogenen Kollektion. Daher müsste untersucht werden, ob bei solchen Kollektionen mehr Information für die Erzeugung der Übersicht übermittelt werden sollte. Da es sich bei den Metadokumenten ja um komprimierte Darstellungen von Teilen einer Dokumentenkollektion handelt, könnte dies realisiert werden, indem nicht nur die oberste Ebene der Hierarchie berücksichtigt wird, sondern auch noch weitere Ebenen bei der Erstellung des globalen Clusterings mit einbezogen werden. Diese müsste allerdings im Kontext dazu stehen, ob der höhere Informationsgehalt tatsächlich einen praktischen Nutzen mit sich bringt und das hierdurch entstehende höhere Datenaufkommen rechtfertigt. Hat ein Hub alle Prole seiner angeschlossenen Peers eingesammelt, so kann er hieraus jetzt ein Clustering erzeugen, indem er diese gesammelten Prole erneut gruppiert. Allerdings würde 41

48 3. Browsing in Peer-to-Peer-Netzen dieses Clustering ja nur Kollektionen seiner eigenen Nachbarschaft enthalten und nicht des gesamten Netzwerks, da er ja im allgemeinen nur mit einigen Peers im Netzwerk verbunden ist. Also benötigt er noch die Clusterings der anderen Hubs, um dann alle Daten zu kombinieren und das angestrebte globale Clustering zu erstellen. Dazu verwaltet jeder Hub eine Liste aller anderen Hubs, um von diesen die notwendige Information anzufordern. Hat er die anderen Clusterings erhalten, die ja auch wieder aus einer Menge von Prolen bestehen, werden diese zusammen mit seinen eigenen Daten erneu gruppiert. Das Ergebnis dieses Vorgangs ist das gewünschte, netzwerkweite Clustering. In Abbildung 3.5 wird noch einmal skizziert, welche Kenntnisse ein Hub von seiner Nachbarschaft hat. Diese Kenntnis wird im weiteren auch als Horizont eines Hubs bezeichnet. Abbildung 3.5.: Horizont eines einzelnen Hubs Peer- und Dokumentendynamik Wurde auf den Hubs nach der oben beschriebenen Vorgehensweise ein globales Clustering erstellt, soll hier nun die Frage geklärt werden, bei welchen Änderungen im Netzwerk bzw. an den Dokumentenkollektionen eine Aktualisierung dieses Clusterings durchgeführt werden muss. Die Peer-Dynamik stellt dabei den einfachsten Fall eines verändernden Ereignisses im Netzwerk dar. Tritt ein Peer dem Netz bei, so überträgt er die benötigte Information zu seiner Kollektion sofort an den mit ihm verbundenen Hub, da er ja sonst nicht ins Browsing mit einbezogen werden könnte. Der verbundene Hub erstellt daraufhin sein Clustering neu und informiert auch die verbleibenden Hubs, damit diese ebenfalls eine Aktualisierung vornehmen können, und die neue Kollektion im Netzwerk bekannt wird. Verlässt ein Peer dagegen das Netz, so sind auch seine Ressourcen nicht mehr verfügbar. Folglich muss das Verzeichnis bei einem solchen Ereignis sofort aktualisiert werden. Dies kann dadurch erfolgen, dass ein Peer sein Ausscheiden seinem Hub mitteilt, dieser die zum Peer zugehörige Information aus seinem Datenbestand entfernt und seine Übersicht mit der verblei- 42

49 3.3. Denition der Browsing-Dienste benden Information neu erstellt. Weiterhin würde er noch allen anderen Hubs das Ausscheiden des Peers mitteilen, damit diese ihren Datenbestand ebenfalls aktualisieren können. Folglich muss also bei jeder Peer-Änderung eine Aktualisierung des Verzeichnisses durchgeführt werden. Bei Veränderungen an den Kollektionen auf den Peers wären mehrere Ansätze denkbar, da der Zeitaufwand für den Durchlauf des Präprozessors, der ja die Cluster-Hierarchie erzeugt, bei steigenden Kollektionsgröÿen ebenfalls ansteigt, und ein Peer in diesem Zeitraum dem Netzwerk nicht mehr zur Verfügung stehen würde. Daher werden hier einige Ansätze vorgestellt, wie auf Veränderungen an den Dokumentenkollektionen reagiert werden könnte. Der entstehende praktische Nutzen müsste allerdings noch genauer untersucht werden. Der einfachste Fall wäre auch hier eine Aktualisierung des Verzeichnisses, sobald eine Änderung an einer Kollektion durchgeführt wurde. Diese Aktualisierung könnte nach der Änderung automatisch vom System durchgeführt, oder manuell vom Benutzer angestoÿen werden. Dabei besteht allerdings wieder die Gefahr, dass bei häugen Aktualisierungen sehr viel Verwaltungs-Overhead durch den entstehenden Zeitaufwand für die Präprozessor- Läufe entsteht. Weiterhin wäre es denkbar, die Aktualisierung nach einer vorher festgelegten Zeitspanne durchzuführen. Dies würde einen kalkulierbaren Zeitrahmen ermöglichen, und könnte auÿerdem individuell für jeden Peer festgelegt werden. So könnte ein Aktualisierungslauf beispielsweise Nachts oder an Wochenenden durchgeführt werden. Allerdings kann es hier vorkommen, dass Änderungen erst nach einer gewissen Zeit sichtbar sind und das Verzeichnis somit nicht mehr den aktuellen Zustand im Netzwerk wiedergibt. Im Rahmen dieser einfachen Ansätze könnte auch die Anzahl der durchgeführten Änderungen eine Rolle spielen. So könnte ein Schwellenwert festgelegt werden, nach dessen Erreichen die Aktualisierung der Hierarchie erfolgt. Hier tritt allerdings auch wieder das Problem des inkonsistenten Zustands des Gesamtverzeichnisses auf. Weiterhin kann dierenziert werden, welcher Art die Veränderung an der Dokumentensammlung eines Peers ist. Dabei können die folgenden drei Verwaltungsvorgänge unterschieden werden, nämlich das Hinzufügen, Ändern und Löschen von Dokumenten. Änderungen an Dokumenten kommen, mal abgesehen von eventuellen Fehlerkorrekturen, in der Praxis eigentlich nicht vor. Da aber auch bei Fehlerkorrekturen keine inhaltlichen Änderungen auftreten, soll dieser Verwaltungsvorgang nicht weiter betrachtet werden. Die beiden anderen Vorgänge machen allerdings eine Aktualisierung erforderlich, da sonst entweder neue Dokumente nicht gefunden oder entfernte Dokumente nicht mehr abgerufen werden können. Die oben vorgestellten Ansätze gehen allesamt von einer vollständigen Neuerstellung der Cluster-Hierarchie bei Änderungen aus. Da dies aber, wie schon erwähnt, bei steigender Dokumentenanzahl zunehmend zeitaufwändiger wird, wäre ein Ansatz vorstellbar, bei dem nur die gewünschten Änderungen in die Hierarchie eingepegt werden. Auf diese Thematik soll aber im Rahmen dieser Arbeit nicht näher eingegangen werden, sondern stattdessen bei einer Aktualisierung einer Dokumentenmenge auf einem Peer das globale Clustering, wie im ersten Ansatz beschrieben, auf den Hubs immer neu erstellt werden. Im weiteren werden jetzt die einzelnen Dienste vorgestellt, die ein Hub bereitstellen muss, um die entwickelten Browsing-Strategien umsetzen zu können. 43

50 3. Browsing in Peer-to-Peer-Netzen Clustering Service Um eine beliebige Dokumentenmenge nach ihrer inhaltlichen Änhlichkeit zu gruppieren, wird ein Clustering Servcie benötigt. Dieser Dienst erwartet als Eingabe eine Menge von systemlesbaren Dokumenten, und fasst diese auf Basis eines internen Maÿes in Gruppen zusammen. Alle weiteren Dienste, die Cluster erzeugen, greifen auf diesen Dienst zurück. Global Clustering Service Der Global Clustering Service ist für das Erzeugen eines netzwerkweiten Clusterings zuständig. Verbindet sich ein Peer mit dem Hub, so fordert er die oberste Ebene der Cluster-Hierarchie des Peers an. Diese kombiniert er dann mit den vorhandenen Prolen der bereits verbundenen Peers bzw. der anderen bekannten Hubs und erzeugt so ein globales Clustering der Dokumente im Netzwerk. Das so erzeugte Clustering wird dann auf dem Hub gespeichert. Startet ein Peer nun eine netzwerkweite Browsing-Sitzung, so übermittelt er eine Anfrage an seinen Hub, der ihm dann sein lokal gespeichertes, globales Clustering übermittelt. Resource Selection Service Initiiert ein Peer eine Verbindung zu einem Hub, so übermittelt er auch das Wurzelelement seiner Cluster-Hierarchie (Cluster-Zentroid). Auf diesen Zentroid greift unter anderem der Resource Selection Service zurück, wenn eine Anfrage bezüglich einer automatischen Selektion an den Hub übermittelt wird. Wird eine automatische Selektion einer Datenquelle im Netzwerk initiiert, so vergleicht dieser Dienst die Anfrage mit allen gespeicherten Zentroiden und liefert die Datenquelle zurück, die nach dem systeminternen Maÿ am ähnlichsten zur gestellten Anfrage ist. Soll eine Kollektion automatisch ausgewählt werden, vergleicht der Dienst die Anfrage mit den Clustern des globalen Clusterings und liefert auch hier den ähnlichsten Cluster zurück. Data Source Clustering Service Die P2P-Architektur macht es möglich, auch einzelne Datenquellen als eigene Dokumentenkollektionen zu betrachten. Daher fasst derdata Source Clustering Service die im Netzwerk vorhandenen Datenquellen nach ihrer Ähnlichkeit in Gruppen zusammen. Für diesen Vorgang verwendet auch dieser Dienst die beim Verbindungsaufbau übertragenen Peer-Zentroiden. Bei einer entsprechenden Anfrage übermittelt der Dienst seine erzeugte Gruppierung an den anfragenden Peer. Zum Abschluss soll noch kurz das Zusammenspiel der einzelnen Komponenten bei der Realisierung der Verzeichnisfunktion vorgestellt werden. Dazu sind in Abbildung 3.6 die einzelnen Komponenten aufgeführt und deren Interaktionen mit den jeweiligen anderen Komponenten veranschaulicht Browsing-Dienste für Peers Neben den Hubs müssen auch auf den Peers Dienste implementiert werden, um die Browsing- Funktionalität zu realisieren. Dabei gibt es Überschneidungen bei den Funktionen von Hubs und Peers, so dass einige Module sowohl auf den Peers wie auch auf den Hubs benötigt werden. Hierzu zählt beispielsweise der Clustering Service, also ein Dienst, der das Gruppieren von (Meta)Dokumenten nach deren inhaltlicher Ähnlichkeit vornehmen kann. Daher wird dieser Dienst hier nicht mehr explizit erwähnt. Im weiteren werden die konkreten Dienste eines Peers jetzt vorgestellt, in Abbildung 3.7 ist das Zusammenspiel der einzelnen Dienste abgebildet. 44

51 3.3. Denition der Browsing-Dienste Abbildung 3.6.: Zusammenspiel der Komponenten bei Hubs Preprocessing Service Der Preprocessing Service erzeugt aus einer gegebenen Dokumentenmenge eine Cluster-Hierarchie. Diese wird dann im verwendeten Speichersystem des Peers abgelegt. Bei den notwendigen Cluster-Schritten kommt der Clustering Service zu Einsatz. Visualization Service (GUI) Da an einem Peer ja auch Browsing-Sitzungen durchgeführt werden können, muss dem Benutzer eine Schnittstelle für solche Interaktionen zur Verfügung stehen. Dies wird durch den Visualization Service gewährleistet. Er verarbeitet eingehende Clusterings und stellt eine grasche Oberäche bereit, mit der die zugehörigen Cluster- Beschreibungen visualisiert und Cluster für weitere Browsing-Schritte ausgewählt werden können. Abbildung 3.7.: Zusammenspiel der Komponenten bei Peers 45

52

53 4. Prototypische Implementierung Auf der Grundlage des im vorigen Abschnitt entwickelten Konzepts für Cluster-basiertes Browsing in P2P-Netzen wird in diesem Kapitel nun die prototypische Umsetzung dieses Konzepts vorgestellt. Für diese Umsetzung wird als Basis das schon in den Grundlagen angesprochene Browsing-Framework InveX-Werkzeug verwendet. Um hiermit Browsing in P2P-Netzen zu realisieren, müssen zunächst einige elementare Veränderungen und Anpassungen an diesem Werkezeug durchgeführt werden. Dieser Teil wird im ersten Abschnitt behandelt. Des weiteren müssen die im Rahmen Konzeptentwicklung identizierten Browsing-Dienste implementiert werden. Eine detaillierte Beschreibung dieser Implementierung ist im zweiten Abschnitt zu nden. Zum Abschluss müssen die implementierten Dienste noch in das angepasste Werkzeug integriert werden. Im letzten Abschnitt werden daher die zur Integration notwendigen Schritte erläutert Anpassung des InveX-Werkzeugs Bevor mit der eigentlichen Implementierung der Browsing-Dienste und den zugehörigen Komponenten begonnen werden konnte, mussten zunächst einige elementare Änderungen am InveX- Werkzeug vorgenommen werden. Diese Änderungen sind notwendig, da ja nun Daten zwischen Netzwerkteilnehmern ausgetauscht werden müssen, und hierfür zusätzliche Information benötigt wird, die über die vorhandene Implementierung hinausgeht. Bevor die einzelnen Änderungen und Erweiterungen angegangen werden, soll zunächst ein Überblick über einige wichtige Komponenten des aktuellen InveX-Werkzeugs gegeben werden, die dann teilweise auch Gegenstand der Erweiterungen sind. Dieser Überblick ist allerdings bewusst sehr kurz gehalten und soll nur der weiteren Orientierung dienen Komponenten und Module des InveX-Werkzeugs Die nun folgende Aufzählung dient dazu, einen Überblick über die Komponenten und Module des InveX-Werkzeugs zu bekommen. Dies ist notwendig, da in den folgenden Abschnitten dieses Kapitels häug auf die bereits vorhandenen Implementierungen des originalen Werkzeugs verwiesen wird. Dabei wird primär der Aufgabenbereich der Komponenten beleuchtet, und keine Beschreibung der genauen Funktionsweise gegeben, da eine detaillierte Übersicht über alle Komponenten in [CLNT04] zu nden ist. Abbildung 4.1 aus [CLNT04] zeigt die Unterteilung des Werkzeugs in die einzelnen Komponenten und veranschaulicht so dessen modularen Aufbau. Preprocessor Der Präprozessor ist für das Einlesen der zu clusternden Dokumente und die Erzeugung der zum Browsing benötigten Cluster-Hierarchie zuständig. Zur persistenten Speicherung der erzeugten Hierarchie verwendet er ein im Storage-Modul implementiertes Speichersystem. 47

54 4. Prototypische Implementierung Abbildung 4.1.: Übersicht über den modularen Aufbau des originalen InveX-Werkzeugs Storage Im Storage-Modul können verschiedene Speichersysteme zur persistenten Speicherung der erzeugten Daten realisiert werden. In der aktuellen Version sind dies zwei verschiedene Ansätze, namentlich sind dies MemoryStorage auf Hauptspeicherbasis und Database auf Basis einer SQL-Datenbank. Cluster Das Modul Cluster stellt Methoden bereit, die das eigentliche Clustern einer vorgegebenen Dokumentenmenge vornehmen. Daher sind hier die Algorithmen, Termgewichtungsmaÿe und Ähnlichkeitsmaÿe enthalten. Datenstruktur Die Datenstruktur bildet das Rückgrat des Werkzeugs. Auf Basis der hier enthaltenen Klassen werden Objekte erzeugt, die verschiedene Datenstrukturen repräsentieren. So sind hier die benötigten Klassen für Cluster (Cluster), Metadokumente (MetaDocument) und normale Dokumente (SingletonMetaDocument) realisiert. Die Oberklasse dieser Objekte bildet die Klasse Item. Ein Item ist also das Allgemeinste, vom InveX-Werkzeug clusterbare Objekt. InveX Da beim Scatter/Gather-Verfahren ja durch Auswahl und erneutem Gruppieren interessanter Cluster die Darstellung schrittweise verfeinert wird, stellt auch das InveX-Werkzeug Methoden für diesen Vorgang bereit. Diese Methoden fassen die Auswahl des Benutzers als neue Ausgangskollektion zusammen, expandieren diese bei Bedarf und gruppieren sie dann erneut. GUI Um das Ergebnis des Clusterings grasch auszugeben und weitere Cluster selektieren zu können, stellt dieses Modul die hierfür benötigten Klassen und Methoden bereit. 48

55 4.1. Anpassung des InveX-Werkzeugs Änderung und Erweiterung betroener Komponenten Bevor die einzelnen Dienste in das originale InveX-Werkzeug integriert werden konnten, mussten an diesem eine Reihe von Änderungen durchgeführt werden. In diesem Abschnitt sollen daher diese Änderungen und Erweiterungen kurz erläutert werden. Die Reihenfolge, in der die folgende Beschreibung hier vorliegt, entspricht dabei nicht unbedingt der tatsächlichen Reihenfolge, in der die Änderungen durchgeführt wurden. Dies ist aber in diesem Kontext unerheblich. Anpassungen für verteilte Umgebungen Der wichtigste Teil der Erweiterungen betraf den Bereich der nun notwendig werdenden Ladevorgänge, um Daten von anderen Netzwerkknoten abzurufen bzw. zu anderen Knoten übertragen zu können. Der erste Schritt war dabei die Implementierung des Interface Serializable, um die Daten so als übertragbar zu kennzeichnen. Diese Erweiterung wurde bei den Klassen Item, Cluster, MetaDocument, SingletonMetaDocument, Term, TermFeatures und XMLRecord durchgeführt. Weiterhin musste berücksichtigt werden, dass beispielsweise beim gloablen Clustering die verwendeten Daten ja von allen mit einem Hub verbundenen Peers stammen. Nun müssen aber bei einem verfeinernden Browsing-Schritt Daten nachgeladen werden. Dies wurde bisher durch Zugrie auf das Storage-Modul erreicht, da ja alle benötigten Daten immer lokal vorhanden waren. So stellten auch die bisher verwendeten IDs (Name des zugrundeliegenden Dokuments für ein SingletonMetaDocument und eine durch einen statischen Zähler erzeugte Zahl für ein MetaDocument) für die clusterbaren Objekte in einer lokalen Umgebung kein Problem dar. Der Ansatz eines statischen Zählers als eindeutige ID für erzeugte Metadokumente ist natürlich in einer verteilten Umgebung nicht realistisch. Da ja von einem solchen Objekt auch bekannt sein musste, auf welchem Netzwerkknoten es abgelegt ist, um es bei Bedarf von dort wieder zu laden, wurde folgender Ansatz gewählt: Die ID eines clusterbaren Objektes besteht nach der Erweiterung aus zwei Komponenten, die durch das Trennzeichen :: von einander abgegrenzt werden. Links von dem Trennzeichen steht der eindeutige Bezeichner des Hosts dieses Objekts (Name, IP-Adresse etc), rechts davon die bisher auch verwendeten IDs. Eine ID für ein Metadokument hat also beispielsweise die Form ::578. Somit ist bei einer eindeutigen Bezeichnung für einen Host gewährleistet, dass die IDs im gesamten Netzwerk eindeutig sind. Der zu verwendende Host-Bezeichner wird dabei in der Kongurationsdatei unter dem Schlüssel idprefix angegeben. Um diesen Bezeichner in jede erzeugte ID zu integrieren, wurden die entsprechenden Methoden in den Klassen AbstractStorage und SingletonMetaDocument angepasst. Im Kontext zur Erweiterung der ID wurde dann in der Klasse MetaDocument bei allen Methoden, in denen ein Zugri auf das Storage-Modul stattndet, eine Abfrage eingebaut, die anhand der Host-ID überprüft ob das gewünschte Objekt lokal verfügbar ist oder über das Netzwerk geladen werden muss. Wird ein Zugri über das Netzwerk erforderlich, wird die entsprechende Methode aus der Kommunikationsschicht aufgerufen. Eine detaillierte Übersicht über die einzelnen Methoden dieser Schicht und ihrer genaue Funktionen wird im nächsten Abschnitt (4.2.1) gegeben. Anpassungen für die verschiedenen Browsing-Strategien Da die im Rahmen der Konzeption entwickelten Browsing-Strategien in dieser prototypischen Implementierung umgesetzt werden sollen, muss berücksichtigt werden, dass nun verschiedene Sichten auf den Dokumentenbestand im Netzwerk möglich sein müssen. So muss beispielsweise beim globalen Clustering eine an- 49

56 4. Prototypische Implementierung dere Cluster-Menge verwendet werden als bei der automatischen Selektion einer Datenquelle. Um dies zu ermöglichen, wurde in der Klasse InveXTool die Methode createview() um eine Abfrage erweitert die es erlaubt, bei deren Instanzierung die zu verwendende Cluster-Menge zu übergeben. Dies geschieht anhand von booleschen Variablen, die anzeigen, welche Cluster- Menge für die Browsing-Sitzung verwendet werden soll. Um alle entwickelten Browsing-Strategien im Prototyp zu realisieren, muss auch die Sicht auf die im Netzwerk vorhandenen Datenquellen ermöglicht werden. In der ursprünglichen Implementierung wird beim Einlesen der Dokumentenkollektion bereits ein Feld datasources in der Klasse Item erzeugt. Bei den OAI-Kollektionen enthalten die XML-Dokumente beispielsweise einen Attribut, in dem der Name der zugehörigen Kollektion abgelegt ist. Bisher wird nur dieses Attribut ausgelesen und im Feld datasources gespeichert. Dieser Mechanismus wurde nun dahingehend erweitert, dass auch eine Information über den Peer, auf dem das entsprechende Dokument abgelegt ist, in diesem Feld gespeichert werden kann. Dazu wird der Host-Bezeichner verwendet, mit dem auch schon die ID eines clusterbaren Objekts erweitert wurde (Kongurationsschlüssel idprefix). Um einem Benutzer die Kontrolle darüber zu geben, welche Information sein Peer im Netzwerk preisgibt, kann über die Schlüssel usecollectionidentifier und usepeeridentifier die Verwendung einer bestimmten Information zugelassen oder untersagt werden. Die GUI wertet dann, abhängig von der gewählten Strategie, die verfügbare Information aus. Evaluierungsspezische Erweiterungen Da für die spätere Evaluierung des Prototyps auch ACM-klassizierte Dokumente aus der CompuScience Kollektion verwendet werden sollten, musste noch eine Anpassung vorgenommen werden, um Dokumente dieses Typs verarbeiten zu können. Dies hat zwar nicht unmittelbar etwas mit verteiltem Browsing zu tun, soll aber, da hierdurch eine erweiterte Funktionalität bereitgestellt wird, trotzdem erwähnt werden. Um aus den XML-Dokumenten der Kollektion Objekte vom Typ SingletonMetaDocument zu erstellen, musste in dieser Klasse eine weitere generateprofile()-methode implementiert werden. Diese Methode akzeptiert als Parameter Objekte vom Typ CompuScienceItem, die mit dem CompuScienceReader aus den eigentlichen Dokumenten erstellt wurden. Die beiden letztgenannten Klassen wurden im Rahmen der Arbeit [Cho04a] erstellt und von dort übernommen. Damit alle benötigten Attribute bei der Erstellung eines SingletonMetaDocuments übernommen werden, wurde CompuScienceItem noch um die Methode extracttermvector() erweitert, welche die Terme aus den Dokumenten extrahiert und normalisiert. Die Methode basiert auf der gleichnamigen Methode der bereits im Werkzeug vorhandenen Klasse AbstractRecord. Weiterhin wurde der Präprozessor noch um die Methode createfromcompusciencefile erweitert, um das geladene CompuScience-Dokumente korrekt zu verabeiten. Ein Kongurationsschlüssel (iscompusciencecollection) gibt an, in welchem Format die zu verarbeitenden Dokumente vorliegen und übergibt sie so an die zugehörige Methode Implementierung der identizierten Browsing-Dienste Nach den notwendigen Änderungen und Erweiterungen am InveX-Werkzeug wurden die identizierten Browsing-Dienste implementiert. In diesem Abschnitt werden daher nun die Klassen und ihre zugehörigen Methoden vorgestellt, durch welche die Dienste realisiert werden. Die den 50

57 4.2. Implementierung der identizierten Browsing-Dienste Diensten entsprechenden Klassen sind dabei genauso benannt, wie dies bei deren Denition im vorigen Kapitel der Fall war Kommunikationsschicht Um in einer Netzwerkumgebung Kommunikation nach dem P2P-Paradigma zu ermöglichen, muss eine Kommunikationsschicht vorhanden sein, welche die Kommunikation zwischen den einzelnen Teilnehmern ermöglicht. Um diese Kommunikation zu realisieren, können verschiedene Ansätze und Architekturen verwendet werden. So könnte beispielsweise die in den Grundlagen vorgestellte P2P-Technologie JXTA verwendet werden. Aber auch die Programmiersprache Java selbst bietet mit den Klassen Socket und ServerSocket eine einfache Möglichkeit, bidirektionale Kommunikation zwischen Geräten in einer Netzwerkumgebung zu realisieren. Um zunächst eine einfache Implementierung ohne Verwaltungs-Overhead zu verwirklichen, wird für die Kommunikationsschicht des Prototyps auf das von Java bereitgestellte Socket-Konzept zurückgegrien. Das Klassendiagramm in Abbildung 4.2 zeigt, wie diese Kommunikationsschicht aufgebaut ist. Abbildung 4.2.: Klassendiagramm der Kommunikationsschicht Das Interface CommunicationLayer stellt eine Reihe von Basismethoden bereit, die von den einzelnen Diensten in Anspruch genommen werden können. Wann immer eine Kommunikation zwischen zwei Netzwerkteilnehmern erforderlich wird (Peer - Peer, Hub - Peer, Peer - Hub oder Hub - Hub), werden von den jeweiligen Komponenten und Diensten die hier bereitgestellten Methoden verwendet. Diese Methoden werden nun im einzelnen kurz vorgestellt. Dabei wird allerdings nur deren abstrakte Funktionalität beschrieben und nicht die konkrete Implementierung auf Socket-Basis, da ja die Funktionen unabhängig von der verwendeten Kommunikationsschicht zur Verfügung stehen müssen. 51

58 4. Prototypische Implementierung connect() Die Methode connect() wird von einem Peer aufgerufen, der sich mit einem Hub im Netzwerk verbinden möchte. Als Parameter wird dabei der Name/die Adresse des Hubs übergeben. Diese Methode übermittelt dabei lediglich den Verbindungswunsch und noch keine Peer-spezischen Daten. Die Methode liefert true zurück, falls der Verbindungswunsch erfolgreich gesendet wurde. Die Adresse des Hubs, mit dem eine Verbindung hergestellt werden soll, muss in der Kongurationsdatei unter dem Schlüssel addressofhub angegeben werden. disconnect() Der Aufruf dieser Methode von einem Peer signalisiert dem angeschlossenen Hub, dass eine bestehende Verbindung getrennt und alle Peer-spezischen Daten entfernt werden sollen. Wurde die Verbindung erfolgreich getrennt, wird true an den Aufrufer dieser Methode zurückgegeben. Da ein disconnect() etwas Zeit in Anspruch nimmt, wird ein Flag gesetzt, so dass andere Peers in dieser Zeit ihre Verbindung nicht regulär trennen können. Dies soll Inkonsistenzen in den Daten verhindern. reportconnecttootherhub() Sind im Netzwerk noch andere Hubs vorhanden, so müssen diese über ein erfolgreiches Hinzukommen eines neuen Peers informiert werden, um die Konsistenz der Daten auf den Hubs zu gewährleisten. Der Hub, bei dem ein Verbindungswunsch eingeht, ruft diese Methode auf. Verbindet sich also ein Peer mit einem Hub und sind andere Hubs im Netzwerk vorhanden, so sorgt diese Methode dafür, dass der als Parameter spezizierte Nachbar-Hub alle notwendigen Daten erhält. Die Methode sollte für alle vorhandenen Nachbar-Hubs aufgerufen werden. Falls der entsprechende Hub weitere Hubs kontaktieren soll, so ist dies in der Kongurationsdatei anzugeben. Hierzu dienen die Schlüssel otherhubsonnetwork und adressesofotherhubs. reportdisconnecttootherhub() Analog zur Vorherigen wird diese Methode aufgerufen, wenn ein Peer das Netzwerk verlässt. Um auch hier die Konsistenz zu erhalten, wird der als Parameter spezizierte Nachbar-Hub darüber informiert, welche Daten er aus seinem lokalen Speicher zu entfernen hat. Auch diese Methode sollte für alle vorhandenen Nachbar-Hubs aufgerufen werden. gethostid() Eine elementare Methode, die primär von den anderen Methoden in diesem Interface genutzt wird. Hier wird aus der übergebenen ID die zugehörige Adresse des Hosts extrahiert und zurückgegeben. loadremoteitem() Der Aufruf dieser Methode erfolgt vom Storage-Modul des InveX- Werkzeugs. Hierdurch wird das durch den Parameter recordid repräsentierte Item von einem Remote-Peer geladen und an den Aufrufer zurückgegeben. Die Adresse des Hosts dieses Items wird entweder durch die Methode gethostid aus der recordid extrahiert, oder zusätzlich zur ID übergeben. saveitemremotely() Speichert ein Item auf einem Peer im Netzwerk. Die ID des Items enthält die Adresse des Peers, auf dem es gespeichert werden soll. Der Rückgabewert ist true, wenn das Item korrket gespeichert wurde. Auch diese Methode wird vom Storage-Modul verwendet. loadremoterecord() Um sich im Verlauf einer Browsing-Sitzung auch einzelne Dokumente anschauen zu können, müssen diese vom jeweiligen Peer geladen werden können. Diese 52

59 4.2. Implementierung der identizierten Browsing-Dienste Methode läd das der übergebenen ID entsprechende Dokument und liefert es zurück. Die benötigte Adresse wird wiederum aus der ID extrahiert. getcenteritem() Der Aufruf dieser Methode liefert ein Item zurück, welches die lokale Dokumetenkollektion eines Peers repräsentiert. Die Adresse des gewünschten Peers ist als Parameter zu übergeben. getcentercluster() Hier wird ein Cluster zurückgeliefert, der die lokale Dokumentenkollektion eines Peers repräsentiert. Auch hier wird die Adresse des gewünschten Peers als Parameter übergeben. getglobalclustering() Wird auf einem Peer eine globale Browsing-Sitzung initiert, so benötigt dieser Peer das aktuelle globale Clustering von seinem Hub. Durch diese Methode stellt er eine Anfrage und erhält das vom Hub generierte globale Clustering für die Browsing- Sitzung. getsummarizeddatasources() Analog dazu wird bei einer Browsing-Sitzung mit Sicht auf Datenquellen das aktuelle Clustering aller Datenquellen benötigt. Diese Methode lädt dieses Clustering vom entsprechenden Hub. selectcollection() Soll eine automatische Selektion einer interessanten Kollektion in Bezug zu einer Anfrage durchgeführt werden, so ruft ein Peer diese Methode auf und übergibt als Parameter die gestellte Anfrage. Der zugehörige Hub führt dann die Selektion durch und liefert die entsprechende Kollektion für eine Browsing-Sitzung zurück. selectdatasource() Diese Methode arbeitet analog zur Vorherigen, nur dass hier der Hub in Bezug zu einer Anfrage eine interessante Datenquelle für eine Browsing-Sitzung zurückliefert. Die Klasse SocketCommunication implementiert nun die hier denierten Methoden auf Basis von Java-Sockets. Die in den Methoden denierten Anfragen werden bei dieser Implementierung durch Objekte der Klasse String repräsentiert. Diese konkrete Klasse kann über die CommunicationLayerFactory instanziert werden. Dazu wird in der Kongurationsdatei unter dem Schlüssel commlayer lediglich der voll-qualizierende Klassenname der zu nutzenden Klasse angegeben. Die Factory erzeugt dann ein zugehöriges Objekt. Tritt hierbei ein Fehler auf, wird eine Exception von Typ CommunicationLayerException ausgelöst. Da die in der Klasse SocketCommunication implementierten Methoden für ihre Anfragen Java-Sockets verwenden, müssen die Kommunikationsdienste auf den Hubs und Peers auch auf der Basis von Sockets realisiert werden, um eingehende Anfragen verarbeiten zu können. Im weiteren werden daher jetzt die auf den Hubs und Peers implementierten Dienste vorgestellt Browsing-Dienste für Hubs In diesem Abschnitt werden nun die Implementierungsdetails zum Hub-Service sowie zu den aus Kapitel 3 hervorgegangenen Browsing-Dienste behandelt. Die Funktionen der einzelnen Dieste wurden dabei in Klassen gleichen Namens gekapselt. Eine zentrale Komponente markiert die Klasse HubService, welche die eingehenden Verbindungen behandelt und ihrerseits die benötigten Dienste aufruft. Abbildung 4.3 verdeutlicht diesen Aufbau in Form eines Klassendiagramms. 53

60 4. Prototypische Implementierung Abbildung 4.3.: Klassendiagramm der Hub-Dienste HubService Die Klasse HubService stellt, wie oben schon erwähnt, die zentrale Funktion eines Hubs bereit. Sie enthält eine main()-methode, die ihrerseits ein ServerSocket instanziert, der auf einem festgelegten Port (hier 46893) auf eingehende Verbindungen lauscht. Auÿerdem werden hier alle Browsing-relevanten Daten in internen Listen abgespeichert. Wird eine Verbindung aufgebaut, wird ein eigener Thread aus der Klasse HubServiceThread erzeugt, der den eingehenden Verbindungswunsch weiter behandelt. Dazu wird er an seine private Methode handlerequest weitergegeben. So ein Verbindungswunsch wird dabei immer von einer Methode der Klasse SocketCommunication initiiert, da in ihr ja alle benötigten Anfragen gekapselt sind. Je nach Art der Anfrage ruft der Thread nun weitere Methoden auf, um die entsprechende Anfrage zu befriedigen. Auch diese Methoden sind in der Klasse SocketCommunication abgelegt. Bei einer connect()-anfrage werden beispielsweise zunächst die benötigten Daten vom Peer abgefragt und in internen Listen der Klasse HubService abgelegt. Danach gibt der Thread die entsprechenden Daten an den GlobalClusteringService und den DataSourceClusteringService weiter, um die benötigten Clusterings zu erstellen. Waren diese Vorgänge erfolgreich, gilt der Peer als mit dem Hub verbunden und die Clusterings sind auf dem aktuellen Stand. GlobalClusteringService In dieser Klasse wird der Dienst für die Generierung eines globalen Clusterings realisiert. Diese Aufgabe übernimmt die einzige Methode in Klasse, nämlich generateglobalclustering(). Als Parameter wird eine Menge von Items erwartet, aus denen ein globales Clustering erstellt werden soll. In dieser Implementierung sind dies die Top-Level-Cluster der Peers im Netzwerk. Für den Cluster-Vorgang wird die Methode 54

61 4.2. Implementierung der identizierten Browsing-Dienste refine() aus dem Interface InveX verwendet. Soll für das Clustering eine gröÿere Datenbasis verwendet werden, so muss dies in der Kongurationsdatei des Hubs unter dem Schlüssel maxnumberofmd angegeben werden. Die Methode refine() lädt dann so lange weitere Items nach, bis die vorgegebene Anzahl erreicht wurde. Wie viele Cluster erzeugt werden sollen, wird durch den Schlüssel desirednumberofclusters bestimmt. Das Ergebnis dieses Vorganges wird in Form einer Collection an den Aufrufer zurückgegeben. DataSourceClusteringService Diese Klasse stellt Funktionen bereit, die das Gruppieren der Datenquellen nach deren inhaltlicher Ähnlichkeit vornimmt. Dies wird durch die Methode summarizedatasources() umgesetzt. Dazu wird ihr eine Menge von Clustern übergeben, die jeweils eine Datenquelle beschreiben. Durch die aus dem refine()-prozess extrahierte Methode scatter() werden die Datenquellen nun gruppiert. Nach Abschluss wird dann eine Menge mit den erzeugte Clustern zurückgeliefert. ResourceSelectionService In ResourceSelectionService sind Methoden implementiert, welche die automatische Selektion einer Kollektion oder Datenquelle anhand einer Anfrage durchführen. Dazu werden die systeminternen Ähnlichkeitsmaÿe verwendet. In dieser Klasse behandeln nun zwei Methoden die entsprechenden Anfragen, namentlich selectcollection() und selectdatasource. Beide greifen zur Berechnung der Ähnlichkeit auf die private Methode calculatesimilarity zu und unterscheiden sich nur dahingehend, mit welchen Daten sie die gestellte Anfrage vergleichen. So verwendet selectcollection() das globale Clustering, um einen zur Anfrage interessanten Cluster zu selektieren. selectdatasource hingegen greift auf die gespeicherten Beschreibungen der Peers zu, um die Selektion durchzuführen. Zurückgeliefert wird dann von beiden Methoden der jeweils beste Treer, wurde nichts zur Anfrage relevantes gefunden wird null zurückgegeben Browsing-Dienste für Peers Neben den Hubs müssen auch die Peers einige Dienste anbieten, um Cluster-basiertes Browsing zu realisieren. Der wichtigste Teil liegt dabei in der Fähigkeit, (Meta)Dokumente von anderen Netzwerkteilnehmern zu laden oder bei Bedarf zu übertragen. PeerService Die Klasse PeerService ist für die Annahme von Verbindungen von anderen Netzwerkteilnehmern zuständig. Sie wird über die main()-methode gestartet und instanziert, genau wie die Klasse HubService, ein ServerSocket, um eingehende Verbindungen anzunehmen. Dabei wird auch hier für jede Verbindung ein eigener Thread aus PeerServiceThread erzeugt. Da die Hauptfunktionalität eines Peers nur darin besteht, Daten für andere Teilnehmer bereitzustellen oder von anderen abzurufen, wird hier keine weitere Funktionalität benötigt. Um Anfragen an andere Geräte zu versenden, wird auch beim PeerService die Klasse SocketCommunication verwendet. PreprocessingService Der PreprocessingService entspricht der Klasse Preprocessor des originalen InveX-Werkzeugs. Die einzige in diesem Rahmen durchgeführte Änderung ist die Namensänderung, um der Betrachtungsweise als Dienst Rechnung zu tragen. Dieser Dienst erzeugt aus einer Menge lokal abgelegter Dokumente eine Cluster-Hierarchie und legt diese im lokalen Storage-Modul ab. 55

62 4. Prototypische Implementierung 4.3. Integration der Dienste in das InveX-Werkzeug Nachdem erläutert wurde, welche Änderungen und Erweiterungen am InveX-Werkzeug durchgeführt und die technischen Details der Implementierung der Browsing-Dienste beleuchtet wurden, soll hier nun die Integration dieser Dienste in das angepasste InveX-Werkzeug beschrieben werden. Da ja nun zwei unterschiedliche Geräteklassen (Peers und Hubs) vorhanden sind und auÿerdem eine Reihe von vorher nicht vorhandenen Browsing-Strategien zur Verfügung stehen, müssen hier die verschiedenen Funktionen dierenziert werden. Integration der Hub-Dienste Die Integration der Hub-Dienste erfordert keinen weiteren Eingri in das Browsing-Werkzeug. Die Klasse HubService beinhaltet eine main()-methode, durch die der Hub-Service gestartet werden kann. Soll also ein Gerät im Netzwerk die Funktion eines Hubs übernehmen, so muss lediglich diese Methode aufgerufen werden. Sämtliche umgebungsspezische Parameter werden über die lokale Kongurationsdatei deniert. Nach erfolgreichem Start kann das Gerät dann eingehende Anfragen verarbeiten und bei Bedarf mit den Methoden der Klasse SocketCommunication entsprechende Antworten senden. Integration der Peer-Dienste Auch bei der Integration der Peer-Dienste sind keine weiteren Schritte notwendig. Sollen von einem Gerät Daten im Netzwerk angeboten werden, so wird einfach die PeerService-Klasse ausgeführt. Auf Basis der in der Kongurationsdatei abgelegten Daten wird dann eine Verbindung mit dem spezizierten Hub hergestellt und alle notwendigen Daten übermittelt. Ist dies erfolgreich geschehen, kann der Peer ab sofort Anfragen entgegennehmen und Daten an andere Geräte im Netzwerk übermitteln. Eine Benutzerschnittstelle für die verschiedenen Funktionen Durch die Integration der Hubund Peer-Dienste sind die entsprechenden Geräte nun in der Lage, Anfragen von anderen Geräten anzunehmen, zu verarbeiten und angefragte Daten zu übermitteln. Damit sind aber zunächst nur die technischen Hintergrundabläufe geregelt, die während einer Browsing-Sitzung auftreten. Beim ursprünglichen InveX-Werkzeug wurde zum Starten einer Browsing-Sitzung nun direkt die grasche Benutzeroberäche gestartet und das lokal erzeugte Clustering verwendet. Da hier aber verschiedene Strategien zur Verfügung stehen, wurde eine zentrale Komponente entwickelt, mit der die gewünschten Funktionen ausgeführt werden können. Dies sind im einzelnen das Ausführen des Präprozessors, der Beginn einer lokalen oder globalen Browsing-Sitzung, eine Browsing-Sitzung auf der Ebene der Datenquellen oder die automatische Selektion einer Kollektion/Datenquelle. Das Klassendiagramm in Abbildung 4.4 veranschaulicht, welche Komponenten für die Bereitstellung dieser Funktionen verwendet werden. Die zentrale Komponente bildet hier die Klasse InveXLauncher. Je nach Auswahl des Benutzers startet sie weitere Komponenten, übermittelt Anfragen an Hubs und speichert von den Hubs erhaltene Daten. Die folgende Aufzählung beschreibt die Auswahlmöglichkeiten, die einem Benutzer nach dem Start der Komponente zur Verfügung stehen und durch die Klasse InveXLauncherGUI visualisiert werden. Ausführen des Präprozessors Die Auswahl dieses Punktes startet den PreprocessingService, der eine Cluster- Hierarchie unter Verwendung der lokalen Dokumentenkollektion erstellt. 56

63 4.3. Integration der Dienste in das InveX-Werkzeug Abbildung 4.4.: Klassendiagramm der zentralen Benutzerschnittstelle Lokale Browsing-Sitzung Basierend auf der lokal abgelegten Cluster-Hierarchie wird die Klasse InveXGUIApplication gestartet, um eine lokale Browsing-Sitzung durchzuführen. Globale Browsing-Sitzung Bei dieser Wahl wird eine Anfrage an den verbundenen Hub übermittelt, um die für die Browsing-Sitzung benötigte Cluster-Menge des globalen Clusterings anzufordern. Wurde diese Cluster-Menge übermittelt, startet der InveXLauncher die grasche Benutzerober- äche und übergibt ihr als Ausgangsmenge die geladene Daten. Browsing-Sitzung auf der Grundlage von Datenquellen Hier werden prinzipiell die selben Anfragen gestellt, wie beim vorigen Punkt. Allerdings wird hier eine andere Cluster-Menge angefordet und als Basis für die Browsing-Sitzung verwendet. Automatische Selektion einer Kollektion Soll eine automatische Selektion durchgeführt werden, wird zunächst ein Eingabefeld (ResourceSelectionGUI) eingeblendet, damit der Benutzer sein Informationsbedürfnis beschreiben kann. Unter Verwendung der eingegebenen Terme wird ein temporäres Item erstellt und an den Hub übermittelt. Dies ist notwendig, damit auf Basis des systeminternen Ähnlichkeitsmaÿes ein Vergleich durchgeführt werden kann. Der Hub vergleicht dann das erhaltene Objekt mit den einzelnen Clustern des globalen Clusterings und liefert den Ähnlichsten zurück. Nach Erhalt dieser Daten wird die grasche Benutzeroberäche gestartet und die erhaltenen Daten als Ausgangspunkt verwendet. Automatische Selektion einer Datenquelle Die Vorgänge werden analog zur vorigen Auswahl ausgeführt, jedoch vergleicht hier der 57

64 4. Prototypische Implementierung Hub die Daten des Benutzers mit den Prolen der Datenquellen im Netzwerk und liefert dann den besten Treer zurück. Parallel zur Umsetzung und Implementierung des Prototyps wurden eine Reihe von Funktionstest durchgeführt. Diese Funktionstests haben gezeigt, dass der Prototyp im Rahmen dieser Tests nützliche Ergebnisse liefert und somit von einer korrekten Funktionsweise ausgegangen werden kann. Dieser Teil wurde bewusst parallel zur Implementierung durchgeführt, da die im folgenden Kapitel durchgeführte Evaluierung primär auf die Retrieval-Qualität von Clusterbasiertem Browsing in P2P-Netzen fokussiert ist. 58

65 5. Evaluierung Nach der Erarbeitung des Konzepts und einer darauf basierenden prototypischen Implementierung, wurden mit dem so entstandenen Prototyp eine Reihe von Tests durchgeführt. Wichtiger Aspekt bei diesen Tests war die Betrachtung der Clusterings, bei denen durch den Einsatz innerhalb einer P2P-Umgebung zusätzliche Faktoren berücksichtigt werden mussten. Dazu wurden Tests in zwei unterschiedlichen Testumgebungen durchgeführt, und relevante Parameter bei jedem Testlauf verändert, um so eventuell auftretende Veränderungen beobachten zu können. In diesem Kapitel wird nun der gesamte Ablauf der durchgeführten Tests vorgestellt, beginnend mit den Details zum Aufbau der beiden Testumgebungen über die Durchführung und Ergebnisse der einzelnen Tests bis hin zu deren Auswertung und sich hieraus ergebende Schlussfolgerungen und Thesen. An dieser Stelle soll auch darauf hingewiesen werden, dass im Rahmen der in diesem Kapitel behandelten Evaluierung des Prototyps keine funktionale Überprüfung stattgefunden hat. Diese wurde bereits parallel zur Entwicklung der einzelnen Dienste vorgenommen Aufbau, Metriken und Ziele in den Testserien Wie schon in der Kapiteleinleitung angesprochen, wurden mit dem Prototyp eine Serie von Tests in zwei unterschiedlichen Netzwerkumgebungen durchgeführt. In diesem Abschnitt soll daher zunächst erläutert werden, welche Ziele bei der Evaluierung überhaupt verfolgt wurden. Weiterhin wird der Aufbau der einzelnen Evaluierungsszenarien einschlieÿlich aller relevanten Parameter, wie die verwendeten Dokumentenkollektionen oder Kongurationseinstellungen, detailliert beschrieben. Zuletzt werden noch die Metriken vorgestellt, nach denen die erhaltenen Resultate ausgewertet wurden. Die so gewonnenen Evaluierungsergebnisse und deren Interpretation nden sich dann in den nächsten beiden Abschnitten Evaluierungsziele Da der Prototyp zur Realisierung von Browsing in P2P-Netzen ja komprimierte Darstellungen der Dokumentenkollektionen auf den Peers verwendet, soll im Rahmen dieser Evaluierung untersucht werden, wie hoch der Informationsgehalt in den generierten Cluster-Beschreibungen ist. Informationsgehalt bedeutet in diesem Zusammenhang bespielsweise, ob auch kleine Dokumentenkollektion noch in den Gesamtübersichten zu entdecken sind, also ausreichend Information vorhanden ist. Bei diesem Test wird von der Annahme ausgegangen, dass ein Benutzer nur Cluster auswählt, wenn diese aufgrund ihrer Beschreibung auch als interessant im Bezug zu seinem Informationsbedürfnis erscheinen. Da dies der wichtigste Teil dieser Evaluierung ist, wird er entsprechend intensiv behandelt. Weiterhin wird in diesem Kapitel untersucht, wie hoch die Retrieval-Qualität bei der automatischen Selektion von Datenquellen ist. Dies ist ein interessanter Aspekt, da die automatische Selektion einerseits dazu verwendet werden kann, die zum Browsing verwendete Datenmenge zu 59

66 5. Evaluierung reduzieren und andererseits die Möglichkeit bietet, eine Resource Selection im vorhandenen Datenbestand durchzuführen. Zusätzlich soll noch, bedingt durch die verteilte Umgebung, das Datenaufkommen und der Zeitaufwand der hier notwendigen Ladevorgänge in verschiedenen Situationen gemessen werden. Die in dieser Evaluierung angestrebten Ziele sind also die Messung und Bewertung des Informationsgehalts des globalen Clusterings, der Retrieval-Qualität der automatischen Selektion von Datenquellen sowie auch des Datenaufkommens und des Zeitaufwands beim globalen Clustering. Die Qualität des verwendeten Cluster-Algorithmus (Buckshot) wird im Rahmen dieser Arbeit nicht mehr explizit untersucht, da dies bereits in [Cho04a] ausführlich geschehen ist, und sich der Algorithmus als nützlich erwiesen hat. Allerdings wird bei der Auswertung der Ergebnisse auch angegeben, wie viele Dokumente einer bestimmten Kollektion in einem Cluster zusammengefasst wurden, und somit ein Rückschluss auf die Qualität der erzeugten Cluster ermöglicht Aufbau und Dokumentenbasis Um die Evaluierung im Rahmen der vorgegebenen Ziele durchzuführen, wurden eine Reihe von Testaufbauten mit unterschiedlichen Eigenschaften und Parametern verwendet. Als Basis wurde zwei verschiedene Testumgebungen verwendet. Die Erste setzt sich aus einem Hub und fünf Peers zusammen, in der Zweiten waren zwei Hubs und acht Peers vorhanden. In jeder dieser beiden Testumgebungen wurden die selben Testreihen durchgeführt. Da ja für die Generierung des globalen Clusterings im einfachsten Fall nur die oberste Cluster- Hierarchie jedes einzelnen Peers verwendet wird, wurde nun bei den Testläufen die Anzahl der zu verwendenden Metadokumente sukkzessiv erhöht. Dies wurde durch Anpassung des Kongurationswerts maxnumberofmd (siehe Anhang A) erreicht. Der Wert wurde dabei für jeden Test verändert. Insgesamt wurden fünf Testläufe mit den Werten 0, 25, 50, 75 und 100 durchgeführt. Höhere Werte schienen nicht mehr praktikabel, da parallel zur Erhöhung des Wertes auch die notwendigen Datenübertragungen sowie auch der benötigte Zeitaufwand immer weiter anstiegen. Die genauen Werte werden später bei der Evaluierung des Datenaufkommens in Abschnitt vorgestellt. Durch die Anpassung dieses Wertes stand bei jedem Durchlauf eine gröÿere Datenbasis für die Erzeugung des globalen Clustering zur Verfügung. Dabei wurde jeweils das Metadokument mit den meisten Kindern expandiert (d.h. durch seine Kinder ersetzt), bis die im Kongurationsschlüssel maxnumberofmd angegebene Anzahl von clusterbaren Objekten (Item) erreicht wurde. Diese Vorgehensweise wurde auch schon beim klassischen vorprozessierten Scatter/Gather-Verfahren angewendet, um mehr Information über ein Metadokument zu erhalten. Die schon vorhandenen Top-Level-Metadokumente jedes Peers werden dabei nicht berücksichtigt, so dass der Wert von maxnumberofmd nicht fälschlicherweise schon durch eine ausreichend groÿen Anzahl von Peers erreicht wird. Somit werden also die vorhandenen Metadokumente immer mindestens um den angegebenen Wert erweitert OAI-Dokumentenkollektion Neben der Änderung der verwendeten Informationsbasis für das globale Clustering wurde noch ein weiterer Faktor bei den einzelnen Testläufen angepasst, nämlich die Verteilung der verwen- 60

67 5.1. Aufbau, Metriken und Ziele in den Testserien deten Dokumentenkollektionen auf die einzelnen Peers. Zwar sollte in dieser Arbeit nicht, wie schon erwähnt, der Cluster-Algorithmus selbst evaluiert werden. Trotzdem erschien es sinnvoll, diesen Parameter in einer P2P-Umgebung zu verändern und zu beobachten, wie sich das globale Clustering und die automatische Selektion von Datenquellen bei homogen bzw. heterogen verteilten Kollektionen verhalten. Eine Begründung hierfür liegt in der Verwendung von komprimierten Darstellungen der Kollektionen jedes Peers, die sich natürlich in Abhängigkeit der ihnen zugrunde liegenden Dokumentenbasis ändern, und somit Einuss auf das Ergebnis eines globalen Clusterings nehmen. Um diese Faktoren nun zu berücksichtigen, wurde jedem Peer eine Kollektion aus den Open Archives mit einem bestimmten Thema zugeteilt, und die Verteilung der Dokumente bei jeder neuen Testreihe verändert. So enthielt zu Beginn jeder Peer 100% der Dokumente aus der ihm zugeteilten Kollektion. Im weiteren Verlauf der Tests wurde diese Anzahl dann auf 50% und 0% reduziert und die freien Dokumente auf die anderen Peers verteilt. Dabei wurde darauf geachtet, dass die Mächtigkeit der Dokumentenmenge auf jedem Peer in etwa konstant gehalten wurde. In den Tabellen 5.1 und 5.2 ist die Anzahl der jeweiligen Dokumente pro Kollektion und Peer aufgelistet, beginnend mit einer vollständig homogenen Verteilung der Dokumente auf die zugewiesenen Peers. Kollektion Peer 1 Peer 2 Peer 3 Peer 4 Peer 5 0%ige Verteilung auf andere Peers MathPreprints BioMedCentral arxiv Cern CaltechOH %ige Verteilung auf andere Peers MathPreprints BioMedCentral arxiv Cern CaltechOH %ige Verteilung auf andere Peers MathPreprints BioMedCentral arxiv Cern CaltechOH Tabelle 5.1.: Verteilung der OAI-Dokumente auf die Peers ACM-Klassizierte-Dokumentenkollektion Um die Resultate nicht nur auf eine Dokumentenkollektion übertragen zu können, wurden die oben angesprochenen Tests auch noch mit einem weiteren Datensatz durchgeführt. Hierbei handelte es sich um eine auf Basis der ACM-Klassikation gruppierte Dokumentenkollektion. Die 61

68 5. Evaluierung Kollektion Peer 6 Peer 7 Peer 8 0%ige Verteilung auf andere Peers Aim CompSciPreprints TU-Chemnitz %ige Verteilung auf andere Peers Aim CompSciPreprints TU-Chemnitz %ige Verteilung auf andere Peers Aim CompSciPreprints TU-Chemnitz Tabelle 5.2.: Verteilung der OAI-Dokumente auf die Peers 6-8 Verteilung der klassizierten Dokumente ist den Tabellen 5.3 und 5.4 zu entnehmen. Dabei wurden nur vollständige Klassen auf den einzelnen Peers abgelegt und somit keine Dokumente einer Klasse auf mehreren Peers verteilt. Dies ist in soweit nicht problematisch, da ja die einzelnen Klassen schon auf den Peers gruppiert werden und damit in einigen Fällen heterogene Cluster entstehen. Bei der Generierung des globalen Clusterings liegt somit eine ausreichend heterogene Verteilung vor. Diese Vorgehensweise sollte auch den Aufwand reduzieren, da bei dieser Gesamtkollektion bei jedem Testlauf immerhin siebzehn Einzelkollektionen berücksichtigt werden mussten. Kollektion Peer 1 Peer 2 Peer 3 Peer 4 Peer 5 A.0 X A.m X B.6.2 X C.1 X C.4 X C.m X D.1 X D.m X E.1 X E.m X F.m X G.1.0 X G.1.9 X I.2.7 X I.3.5 X J.4 X J.6 X Tabelle 5.3.: Verteilung der ACM-Klassizierten Dokumente auf die Peers

69 5.1. Aufbau, Metriken und Ziele in den Testserien Kollektion Peer 1 Peer 2 Peer 3 Peer 4 Peer 5 Peer 6 Peer 7 Peer 8 A.0 X A.m X B.6.2 C.1 X C.4 X C.m X D.1 X D.m X E.1 X E.m X F.m X G.1.0 X G.1.9 I.2.7 X I.3.5 X J.4 X J.6 X Tabelle 5.4.: Verteilung der ACM-Klassizierten Dokumente auf die Peers Durchgeführte Testreihen In Anhang C sind detaillierte Übersichten über die verwendeten Kollektionen zu nden, inklusive einer kurzen inhaltlichen Beschreibung. Insgesamt wurde im Rahmen der Evaluierung unter Berücksichtigung aller Konstellationen 60 verschiedene Einzeltests durchgeführt. Im folgenden sind diese Testreihen noch einmal zusammengefasst aufgeführt und nach den veränderten Faktoren gegliedert: 1 Hub, 5 Peers OAI-Dokumentenkollektion (2968 Dokumente) 0%ige Verteilung, 5 Cluster, Erweiterung um 0, 25, 50, 75 und 100 Items 50%ige Verteilung, 5 Cluster, Erweiterung um 0, 25, 50, 75 und 100 Items 100%ige Verteilung, 5 Cluster, Erweiterung um 0, 25, 50, 75 und 100 Items ACM-Klassizierte-Dokumentenkollektion (3117 Dokumente) 2 Hubs, 8 Peers Zufällige Verteilung, 5 Cluster, Erweiterung um 0, 25, 50, 75 und 100 Items OAI-Dokumentenkollektion (3797 Dokumente) 0%ige Verteilung, 4 Cluster, Erweiterung um 0, 25, 50, 75 und 100 Items 50%ige Verteilung, 4 Cluster, Erweiterung um 0, 25, 50, 75 und 100 Items 100%ige Verteilung, 4 Cluster, Erweiterung um 0, 25, 50, 75 und 100 Items ACM-Klassizierte-Dokumentenkollektion (3117 Dokumente) Zufällige Verteilung, 4 Cluster, Erweiterung um 0, 25, 50, 75 und 100 Items X X 63

70 5. Evaluierung Die oben vorgestellten Testreihen wurden dabei alle mit den selben Kongurationseinstellungen für das P2P-Browsing-Tool durchgeführt. Dabei wurde als Algorithmus (flatclustering) für die Vorprozessesierung und während der Clustering-Durchläufe Buckshot verwendet. Für die Gewichtung der Terme während des Clusterings und auch für die Präsentation der Cluster (weight und weight.label) wurde das Relative-Information-Weight genutzt. Weiterhin enthielt jedes Item maximal 50 Terme (frequenttermcount). Als Ähnlichkeitsmaÿ (similaritymeasure) kam bei allen diesbezüglichen Operationen das Kosinusmaÿ zu Einsatz. Details zu den einzelnen Kongurationsschlüsseln sind in Anhang A zu nden Evaluierungsmetriken Um die vorgestellten Evaluierungsziele in den verschiedenen Testszenarien erreichen zu können, muss noch ein einheitlicher Maÿstab festgelegt werden, nach dem die Messung und anschlieÿende Bewertung der gewonnenen Resultate erfolgen kann. Der verwendete Maÿstab orientiert sich dabei natürlich an den jeweils angestrebten Evaluierungszielen. Informationsgehalt des globalen Clusterings Zur Bewertung des Informationsgehalts eines globalen Clusterings wird die Beschreibung eines erzeugten Clusters verwendet. Eine solche Beschreibung besteht aus der Anzahl der Dokumente im Cluster, Beispielsdokumenten, den höchstgewichteten Termen sowie den Datenquellen, aus denen die Dokumente stammen. Für die Evaluierung werden von dieser Information nur die Terme einer Cluster-Repräsentation berücksichtig, da allein sie den thematischen Inhalt eines Clusters beschreiben können. Unsere hier verwendete Cluster-Beschreibung hat also die Form C l = {t 1,..., t n }, wobei l für die Anzahl der Cluster und n für die Anzahl der Terme steht. Um nun zu bewerten, ob ein Cluster die enthaltenen Dokumente aussreichend repäsentiert, müssen auch die Kollektionen durch ihre Terme beschrieben werden. Um dies zu erreichen, wurden die Kollektionen einzeln geclustert und vom entstandenen Cluster-Zentroiden die zehn höchstgewichteten Terme extrahiert. Jede verwendete Dokumentenkollektion wird also durch K x = {t 1,..., t 10 } beschrieben, wobei x für den Namen der jeweiligen Kollektion steht. An dieser Stelle soll noch erwähnt werden, dass diese zehn Terme im allgemeinen nicht alle Dokumente einer Kollektion repräsentieren können, sondern immer nur als Repräsentation der gesamten Kollektion verstanden werden sollen. Für die im Rahmen dieser Arbeit durchgeführten Testreihen wurde diese Anzahl aber als nützliche und verwendbare Repräsentation eines möglichen Informationsbedürfnisses angesehen. Die Veränderung der Anzahl dieser Terme und die Beobachtung des Einusses auf die Evaluierungsergebnisse stellt einen weiterern interessanten Aspekt dar, der bedingt durch den vorgegebenen Zeitrahmen und der damit verbundenen notwendigen Fokussierung auf bestimmte Bereiche hier aber nicht weiter verfolgt wurde. Um nun zu bewerten, wie hoch der Informationsgehalt einer Cluster-Beschreibung hinsichtlich der enthaltenen Dokumente ist, wird für jeden Cluster die Mächtigkeit der Schnittmenge aus der Cluster-Beschreibung C l und den Kollektionsbeschreibungen K x bestimmt. Die hier möglichen Ergebnisse liegen im Interval [0, 10], wobei 10 für einen vollständigen und 0 für keinen Informationsgehalt steht. Da ja durch den Testaufbau bekannt ist, welche Dokumente (einer Kollektion) auf welchen Peers abgelegt wurden, ndet eine solche Bewertung natürlich nur bei solchen Cluster-Kollektion-Paaren statt, wo auch Dokumente einer Kollektion im Cluster enthalten sind. 64

71 5.1. Aufbau, Metriken und Ziele in den Testserien Retrieval-Qualität der automatischen Selektion von Datenquellen Der zweite Aspekt dieser Evaluierung ist die Bewertung der Retrieval-Qualität bei einer automatischen Selektion einer Datenquelle vom System. Bei der automatischen Selektion wird vom Benutzer die Eingabe von thematisch relevanten Wörtern erwartet. Die im Rahmen der vorhergehenden Metrik entwickelte Repräsentation K x einer Dokumentenkollektion kommt auch hier zu Einsatz, nämlich als Eingabemenge bei der automatischen Selektion. Da ja durch die Testaufbauten bekannt ist, welche Dokumente einer Kollektion auf welchem Peer abgelegt wurden, kann so ermittelt werden, ob die zurückgelieferte Datenquelle dem erwarteten Ergebnis entspricht. Dabei wird im folgenden davon ausgegangen, dass die Datenquelle optimal ist, welche die meisten Dokumente der für die Anfrage verwendeten Kollektion enthält. Bei den Dokumenten der OAI-Kollektionen wird als Bewertungskriterium eine Zahl aus dem Intervall [0, i] angegeben, wobei i für die Anzahl der Datenquellen (also Peers) im Netzwerk steht. Die vorhandenen Datenquellen werden nach der Anzahl ihrer kollektionsbezogenen Dokumente auf dieses Intervall abgebildet, wobei i für die optimalste Auswahl steht. Enthält also beispielsweise eine Datenquelle die zweitgröÿte Anzahl von Dokumenten einer bestimmten Kollektion, so wird diese auf den zweitgröÿten Wert abgebildet. Wird keine automatische Auswahl vorgenommen, wird der Wert 0 vergeben. Da bei der ACM-Klassizierten Dokumentenkollektion immer nur vollständige Kollektionen auf den Peers abgelegt wurden, wird hier lediglich gemessen, ob der auf Basis der eingegebenen Terme ausgewählte Peer jener Peer ist, auf dem auch die zu den Termen gehörende Kollektion abgelegt wurde. Ist dies der Fall, wird in der Ergebnistabelle ein 'X' eingetragen. Wurde ein Peer ausgewählt, der nicht die betreende Kollektion enthält, wird dies durch ein '(X)' signalisiert. Wurde gar keine Peer selektiert, bleibt die entsprechende Tabellenzeile leer. Durch diese Vorgehensweise wird automatisch auch der Informationgehalt der erzeugten Cluster bewertet, da bei der Auswahl der Datenquellen die Cluster-Zentroiden der Peers verwendet werden. Wird beispielsweise bei einer sehr heterogenen Verteilung der Dokumente jener Peer ausgewählt, auf welchem die meisten Dokumente der für die Anfrage verwendeten Dokumentenkollektion abgelegt sind, so ist dies ein Hinweis dafür, dass der Informationsgehalt der Cluster-Beschreibungen für diese Zwecke ausreichend ist. Da hier aber immer nur ein Cluster betrachtet wird, ist dies nur als Ergänzung zur Bewertung des Informationsgehalts der Cluster-Beschreibungen anzusehen. Datenaufkommen und Zeitaufwand beim globalen Clustering Ergänzend zur Evaluierung der Retrieval-Qualität wurden auch die in einer P2P-Umgebung notwendigen Ladevorgänge und die damit verbundenen Faktoren Datenaufkommen und Zeitaufwand untersucht. Für diesen Teil der Evaluierung wurden allerdings keine eigenen Tests erstellt, sondern parallel zur Durchführung der anderen Testreihen Messungen bezüglich dieser beiden Faktoren durchgeführt. Alle Messungen wurden in einer Fast-Ethernet-Umgebung (100 Mbit/s, full duplex) durchgeführt, wobei die Peers und Hubs über entsprechende Switches angebunden waren. Die Messung des Datenaufkommens erfolgte mit Bordmitteln des eingesetzten Betriebsystems (Windows XP), namentlich mit dem Programm Task-Manager, das die Anzahl der übertragenen und empfangenen Bytes für eine beliebige Netzwerkschnittstelle anzeigen kann. Das Datenaufkommen wurde dann bei verschiedenen Übertragungssituationen gemessen, beispielsweise bei der Übertragung eines Datenobjekts zu einem anfragenden Peer, oder bei der Generierung 65

72 5. Evaluierung des globalen Clusterings auf einem Hub. Die Messungen erfolgten dabei unter Verwendung der zu diesem Zeitpunkt implementierten Kommunikationsschnittstelle auf Java-Socket-Basis. Weiterhin wurden noch diverse Messungen hinsichtlich des Zeitsaufwands bei verschiedenen Vorgängen durchgeführt. So sollte beispielsweise überprüft werden, wie sich der Zeitaufwand für die Erstellung eines globalen Clusterings auf den Hubs verändert, wenn unterschiedlich viel Ressourcen als Datenbasis genutzt werden. Das Ergebnis einer Messung wird dann in der Form data(x) = y bzw. time(x) = z beschrieben, wobei x für den jeweiligen Test, y für die Anzahl der übertragenen Bytes und z für die Dauer des Vorgangs x in Sekunden stehen. Jede Messung wurde fünf Mal wiederholt und der sich ergebende Mittelwert als Ergebnis der Messung verwendet. Damit sollten eventuelle, durch anderweitige Programme verursachte Beeinträchtigungen der Messungen kompensiert werden Ergebnisse der Testreihen Nachdem im letzten Abschnitt der Aufbau, die Ziele und die Metriken der unterschiedlichen Testreihen erläutert wurden, sollen an dieser Stelle nun die gewonnenen Testergebnisse vorgestellt werden. Aufgrund der groÿen Anzahl, und auch zum besseren Verständnis, sind die Ergebnisse in Form von Diagrammen visualisiert und nach ihrer Zugehörigkeit zu einer bestimmten Testreihe zusammengefasst worden. Diese Darstellungsform bietet auch die Möglichkeit, etwaige Zusammenhänge direkt aus den so zusammengefassten Diagrammen abzulesen. Durch die kompakte Darstellung sind in den einzelnen Diagrammen nicht alle der zu jedem Test gehörenden Parameter enthalten. Welche dieser Parameter nicht abgebildet wurden und welche Einschränkungen sich hieraus bei der Bewertung ergeben können, wird im zur Testreihe gehörenden Abschnitt erwähnt. Der festgelegte Zeitrahmen für diesen Teil der Arbeit macht aber eine einschränkende Betrachtung notwendig. Eine weitergehende Analyse der Daten und deren Interpretation in verschiedenen Kontexten wäre sicherlich interessant. Eine vollständige Auistung aller Ergebnisdaten mit allen dazugehörigen Paramtern ist in tabellarischer Form in Anhang D zu nden Informationsgehalt des globalen Clusterings Zunächst werden die Ergebnisse der gröÿten Testreihe, nämlich die Ergebnisse zum Informationsgehalt des globalen Clusterings, betrachtet. Da aus dieser Testreihe sehr viele Einzelergebnisse hervorgegangen sind, wird im folgenden versucht, diese Ergebnisse kompakt und übersichtlich darzustellen. Dies erfolgt durch die Visualisierung der eigentlich nur aus Zahlen bestehenden Ergebnisse in Form von Diagrammen. Da die Darstellungsform der Diagramme begrenzt ist, können hier nicht alle Ergebnisfaktoren dargestellt werden. Um welche Faktoren es sich dabei handelt, ist den kommenden Erläuterungen zu den Diagrammen zu entnehmen. Eine tabellarische Auistung aller Evaluierungsergebnisse dieser Testserie mit allen Ergebnisfaktoren ist im Anhang unter Abschnitt D.1 zu nden. Auf den nächsten Seiten sind nun eine Reihe von Abbildungen zu nden, welche die oben erwähnten Ergebnisdiagramme enthalten. Um eine bessere Übersicht zu gewährleisten, enthält jede Abbildung alle Diagramme eines Testdurchlaufs. Bei einem Testdurchlauf ist die verwendete Dokumentenkollektion sowie die Verteilung der Dokumente auf den Peers konstant. Variiert wird hier nur die für das globale Clustering verwendete Datenbasis. Für jeden Test sind dies also im einzelnen fünf Diagramme (Säulendiagramme), die jeweils den Informationsgehalt aller 66

73 5.2. Ergebnisse der Testreihen Abbildung 5.1.: Globales Clustering - 1 Hub, 5 Peers - 0% verteilte OAI-Kollektion erzeugten Cluster hinsichtlich der enthaltenen Dokumente unter Verwendung von 0, 25, 50, 75 und 100 zusätzlichen Items als Datenbasis darstellen. Weiterhin enthält jede Abbildung ein Diagramm über den Verlauf des gesamten gemessenen Informationsgehalts je Kollektion nach der Variierung der verwendeten Datenbasis (Liniendiagramm). Hierdurch soll ermittelt werden, ob sich die Gesamtzahl der repräsentierten Kollektionen bei einer gröÿeren Datenbasis erhöht und somit der Informationsgehalt steigt. Da die Diagramme auf einer recht kompakten Fläche untergebracht sind, die eigentlichen Diagramme aber möglichst groÿ erscheinen sollen, fällt die Beschriftung der Achsen entsprechend spärlich aus. Aus diesem Grund werden die Bedeutungen der einzelnen Werte und Variablen an dieser Stelle erläutert. In den Säulendiagrammen wird der Informationgehalt jedes Clusters hinsichtlich einer in dem Cluster enthaltenen Kollektion abgetragen. Dieser Wert berechnet sich in der ersten Testumgebung (1 Hub, 5 Peers) unter Verwendung der OAI-Dokumentenkollektion als 5 x=1 C l K x und mit der ACM-Dokumentenkollektion als 17 x=1 C l K x für l = 1,..., 5. Diese Werte sind in den Diagrammen als Informationsgehalt des Clusters bezeichnet. Die 67

74 5. Evaluierung Abbildung 5.2.: Globales Clustering - 1 Hub, 5 Peers - 50% verteilte OAI-Kollektion Höhe der Säulen entspricht also der Summe der ermittelten Beträge der Schnittmengen eines Clusters mit den enthaltenen Kollektionen. Die Farben einer Säule dierenzieren dabei den Anteil einer enthaltenen Kollektion am gesamten Informationsgehalt. Ist nur ein sehr kleiner Anteil (der abgetragene Wert beträgt 0,25) der Säule in der Farbe einer Kollektion, so sind zwar Dokumente der Kollektion im Cluster enthalten, jedoch ndet sich kein einziger kollektionsbeschreibender Term in der Cluster-Beschreibung. Kommt eine Farbe nicht in einer Säule vor, so ist kein Dokument dieser Kollektion im Cluster enthalten. Ein in den Diagrammen nicht widergegebener Faktor ist die Anzahl der kollektionsbezogenen Dokumente in den Clustern. Dieser Faktor ist aber bei der Zielsetzung dieser Testreihe auch nicht so sehr von Bedeutung, da ja der Informationsgehalt von der Anzahl der enthaltenen Dokumente weitestgehend unabhängig sein sollte. Im Verlaufsdiagramm (Liniendiagramm) ist das Verhältnis der in der Cluster-Beschreibung enthaltenen Kollektionen in Bezug zu allen Kollektionen im Cluster dargestellt. Sind also in einem Cluster Dokumente aus vier Kollektionen vorhanden und zwei Kollektionen durch die 68

75 5.2. Ergebnisse der Testreihen Abbildung 5.3.: Globales Clustering - 1 Hub, 5 Peers - 100% verteilte OAI-Kollektion Cluster-Beschreibung repräsentiert, so würde dies den Wert 2 4 = 0, 5 ergeben. Die ermittelten Werte liegen also im Interval [0, 1]. Hierdurch lässt sich die Entwicklung der Cluster- Beschreibungen in Bezug zu den durchgeführten Veränderungen darstellen. So kann mit Hilfe dieses Diagramms erkannt werden, ob durch die Vergröÿerung der Datenbasis signikante Veränderungen auftreten, ohne die Gesamtzahl des Informationsgehalts zu berücksichtigen, da dies ja schon in den Balkendiagrammen dargestellt wird. Bedingt durch die groÿe Anzahl an verwendeten Klassikationen lassen sich die Ergebnisse der Tests mit der ACM-Dokumentenkollektion nicht in derselben Art und Weise darstellen, wie dies zuvor mit den OAI-Kollektionen geschehen ist. So müssten allein für die siebzehn Klassikationen siebzehn Farben zur Dierenzierung verwendet werden, was keine übersichtliche Darstellung erlauben würde. Daher wird bei dieser Testreihe nur gemessen, ob sich durch die Erhöhung der Datenbasis signikante Änderungen in den Cluster-Beschreibungen ergeben. Dazu wird (wie auch in den Verlaufdiagrammen der OAI-Kollektionen) das Verhältnis der vorhandenen Kollektionsbeschreibungen in Bezug zu allen in einem Cluster vorhandenen Kollektionen 69

76 5. Evaluierung Abbildung 5.4.: Globales Clustering - ACM-Kollektion betrachtet. Da sich bei den Dokumenten der ACM-Kollektion trotz der unterschiedlichen thematischen Ausrichtung viele Terme überschneiden (beispielsweise 'system', 'computer', 'software' etc.) und diese dann auch in den Cluster-Beschreibungen zu nden sind, wird hier eine Kollektion nur als in der Cluster-Beschreibung enthalten bewertet, wenn mehr als zwei Terme aus Cluster- und Kollektionsbeschreibung übereinstimmen. Diese Zahl ist natürlich rein heuristisch bestimmt, jedoch zeigt eine Analyse der Ergebnistabellen in Anhang D.1, dass eben sehr viele Kollektion nur durch ein oder zwei Terme beschrieben werden. Daher wird hier angenommen, das dies mit hoher Wahrscheinlichkeit an der thematischen Ähnlichkeit der Kollektionen untereinander liegt. Die resultierenden Diagramme aus der 1 Hub, 5 Peer und 2 Hub, 8 Peer Umgebung sind in Abbildung 5.4 dargestellt. Da in der zweiten Testumgebung (2 Hubs, 8 Peers) eine andere Anzahl von Clustern erzeugt und auch die OAI-Dokumentenkollektion erweitert wurde, berechnet sich der Informationsgehalt unter Berücksichtigung der veränderten Parameter hierbei wie folgt: Bei der OAI-Dokumentenkollektion aus 8 x=1 C l K x, bei der ACM-Dokumentenkollektion aus 17 x=1 C l K x für l = 1,..., 4. 70

77 5.2. Ergebnisse der Testreihen Abbildung 5.5.: Globales Clustering - 2 Hubs, 8 Peers - 0% verteilte OAI-Kollektion Weiterhin soll an dieser Stelle erwähnt werden, dass in dieser Testumgebung nur der Informationsgehalt des globalen Clusterings eines Hubs untersucht wird, da in der hier verwendeten Implementierung die Hubs auf die gleiche Datenbasis zugreifen. Somit ändert sich am Ziel dieser Testserie, nämlich den Einuss der Datenbasis auf den Informationsgehalt zu untersuchen, nichts. Daher wird das globale Clustering auf dem zweiten Hub nicht weiter untersucht Retrieval-Qualität bei der automatischen Selektion Für die Bewertung der Retrieval-Qualität wurde ja ermittelt, welche Datenquelle hinsichtlich einer Reihe von spezischen Anfragen zurückgeliefert wird. Diese Anfragen bestanden dabei aus den 10 beschreibenden Termen einer Kollektion und wurden für jede in der Testumgebung verwendete Kollektion durchgeführt. Da ja durch die Beschreibung des Aufbaus der Testumgebungen bekannt ist, welche Dokumente einer Kollektion auf welchen Datenquellen abgelegt 71

78 5. Evaluierung Abbildung 5.6.: Globales Clustering - 2 Hubs, 8 Peers - 50% verteilte OAI-Kollektion sind, konnte nun also gemessen werden, ob und in wie weit die selektierte Datenquelle relevante Dokumente im Bezug zur Anfrage beeinhaltet. Um auch hier die gesammelten Resultate in den Kontext der einzelnen Testläufe zu stellen, werden diese ebenfalls mit Hilfe von Diagrammen visualisiert (Abbildung 5.8). Da bei der OAI- Kollektion auch einzelne Dokumente einer Kollektion auf den Peers verteilt wurden, werden die Ergebnisse dieser Tests in Form von Balkendiagrammen dargestellt. Der abgetragene Wert entspricht dabei der Relevanz der selektierten Datenquelle hinsichtlich der zugehörigen Anfrage. Dies wurde für alle drei Verteilungsstufen durchgeführt. Der maximal erreichbare Wert beträgt im ersten Diagramm 5, im zweiten Diagramm 8 Punkte. Da bei der ACM-Kollektion nur vollständige Kollektionen auf den Peers abgelegt wurden und somit eigentlich nur eine optimale Datenquelle existiert, wird hier lediglich gemessen, ob diese ausgewählt wurde. Dazu wird in den Liniendiagrammen der Verlauf der Selektion je Kollektion abgetragen. Eine grüne Linie repräsentiert den optimalen Verlauf, die rote die tatsächlich gemessenen Werte. Eine vollstän- 72

79 5.2. Ergebnisse der Testreihen Abbildung 5.7.: Globales Clustering - 2 Hubs, 8 Peers - 100% verteilte OAI-Kollektion dige Auistung der Ergebnisse dieser Testreihe ist wiederum im Anhang unter Abschnitt D.2 zu nden Datenaufkommen und Zeitaufwand Neben den Testreihen aus Retrieval-Sicht wurde auch noch eine Testreihe hinsichtlich der in einer P2P-Umgebung notwendigen Ladevorgänge und des daraus resultierenden gesteigerten Zeitaufwands durchgeführt. Die ermittelten Ergebnisse sind in Abbildung 5.9 in Form eines Balken- und Verlaufsdiagramms dargestellt. Das Verlaufdiagramm spiegelt das Datenaufkommen bei einer Reihe von verschiedenen Ladevorgängen wieder. Die abgetragenen Werte stehen dabei für die Anzahl der übertragenen Bytes beim Laden der korrespondierenden Menge von Items. Im Balkendiagramm ist der Zeitaufwand für das Erstellen eines globalen Clusterings sowie die Aufteilung dieses Vorgangs auf die Teilvorgänge Ladevorgänge und Clustering dargestellt. 73

80 5. Evaluierung Abbildung 5.8.: Automatische Selektion von Datenquellen In den verschiedenen Testläufen wurde dabei eine unterschiedlich groÿe Datenbasis betrachtet, um den Verlauf des Zeitaufwands bewerten zu können. Alle Werte dieser Testreihe (Datenaufkommen und Zeitaufwand) sind in Tabellenform in Anhang D.3 hinterlegt. Nachdem in diesem Abschnitt der Schwerpunkt darauf gelegt wurde vorzustellen, in welcher Form die gesammelten Daten ausgewertet und welche Schwerpunkte bei der Auswertung gesetzt wurden, erfolgt nun im kommenden Abschnitt eine Analyse dieser Daten, einhergehend mit einer Interpretation eventuell vorhandener Zusammenhänge Ergebnisanalyse Auf Basis der gewonnen Daten erfolgt hier nun deren Auswertung im Hinblick auf die Ziele der jeweiligen Testreihen. Anschlieÿend wird geprüft, ob sich aus den erhaltenen Ergebnissen Verallgemeinerungen ableiten lassen und Schlussfolgerungen gezogen werden können und welche Auswirkungen sich daraus für zukünftige Einsatzfelder ergeben. Dabei werden primär die in den Diagrammen visualisierten Ergebnisdaten verwendet, teilweise wird aber auch auf Daten aus den Ergebnistabellen in Anhang D zurückgegrien Auswertung Die hier durchgeführte Auswertung bezieht sich natürlich auf die Annahme, dass der Inhalt der Dokumente einer Kollektion durch die vorher festgelegte Kollektionsbeschreibung adequat widergegeben wird. Diese bewusst vorgenommene Verallgemeinerung der Dokumente einer Kollektion sollte es möglich machen, eine Bewertung auch bei einer Gröÿenordnung von mehreren Tausend Dokumenten durchzuführen, da ja sonst für jedes Dokument eine eigene Beschrei- 74

81 5.3. Ergebnisanalyse Abbildung 5.9.: Datenaufkommen und Zeitaufwand bung benötigt worden wäre. Die Auswertung der Testergebnisse ist daher im Kontext dieser verallgemeinernden Annahme zu sehen. Informationsgehalt des globalen Clusterings In diesem Abschnitt erfolgt nun die Auswertung der zur Testreihe Informationsgehalt des globalen Clusterings gehörenden Ergebnisdaten. Der therotisch erreichbare Maximalwert des Informationsgehalts eines Clusters liegt hier bei 10 Punkten je enthaltener Dokumentenkollektion, bei einer absoluten Obergrenze von 50 Punkten. Diese Obergrenze wird durch die Gesamtzahl der Terme in der Clusterbeschreibung festgelegt. Sind in einem Cluster also beispielsweise Dokumente aus vier verschiedenen Kollektionen enthalten, so würde der maximal erreichbare Wert bei 40 Punkten liegen, da ja jede Kollektion per Denition durch je 10 Terme beschrieben wird. Dabei muss beachtet werden, dass hier als Maÿstab lediglich die in Abschnitt vorgestellten Metriken zum Einsatz kommen. Das bedeutet, dass die Ergebnisse aus einer anderen 75

82 5. Evaluierung Sichtweise auch anders bewertet werden können. Enthält beispielsweise Cluster a Dokumente aus vier verschiedenen Kollektionen, und hat einen gemessenen Informationsgehalt von 33 Punkten, so würde dies nach dem hier angewandten Verfahren als ein sehr gutes Ergebnis bewertet werden. Betrachtet man aber einen Cluster b im Kontext des Clustering-Algorithmus, so würde man davon ausgehen, dass im Optimalfall nur Dokumente einer einzigen Kollektion im Cluster enthalten sind. Damit könnte sein Informationsgehalt höchsten 10 Punkte betragen, man würde aber unter Berücksichtigung der geänderten Betrachtungsweise Cluster b trotzdem besser bewerten als Cluster a. Da im Rahmen dieser Evaluierung das Clustering selbst nicht explizit betrachtet wird, ist der Informationsgehalt einziger Bewertungsmaÿstab. Bei der Analyse der Balkendiagramme in Abbildung 5.1 bis Abbildung 5.7 fällt nun zunächst auf, dass im Verlauf der Vergröÿerung der Datenbasis keine absoulte Erhöhung des Informationsgehalts festzustellen ist. D.h. die Anzahl der Terme in den Cluster-Beschreibungen, die mit den Kollektionsbeschreibungen übereinstimmen, vergöÿert sich nicht deutlich. Dies ist allerdings noch kein Hinweis darauf, dass eine Vergröÿerung der Datenbasis keinen Einuss auf den Informationsgehalt eines Clusters hat. So könnten beispielsweise in einem Cluster mit Dokumenten aus vier Kollektionen ohne Erweiterung der Dokumentenbasis zwei Kollektionen mit je 6 Termen repräsentiert sein, nach deren Erhöhung aber alle vier Kollektionen mit je 3 Termen. Somit hätte sich der Gesamtwert nicht verändert, die Cluster-Repräsentation wäre aber in diesem Fall trotzdem deutlich besser. Daher wird nun betrachtet, wie sich der Informationsgehalt auf die Kollektionen in den Clustern verteilt. Hier lässt sich erkennen, dass in den meisten Fällen bei den einzelnen Balken, die ja den Informationsgehalt eines Clusters widergeben, höchstens zwei Farben dominieren. Dass bedeutet, dass in diesen Clustern die den Farben entsprechenden Kollektionen gut durch Cluster-Beschreibung repräsentiert werden. Häug sind jedoch noch Dokumente anderer Kollektionen in den Clustern vorhanden, die in den Cluster-Beschreibungen kaum oder gar nicht zu nden sind. Ein Blick auf die Ergebnistabellen im Anhang zeigt nun, dass dies in fast allen Fällen jene Dokumente sind, die im Cluster nur in einer geringen Anzahl vorhanden sind. Dokumente mit einem sehr hohen Anteil im Cluster sind dagegen im allgemeinen ausreichend durch die Cluster-Beschreibung repäsentiert. Da dieser Zusammenhang auch in den Diagrammen mit vergröÿerter Dokumentenbasis zu nden ist, ergeben sich also durch die Vergröÿerung keine signikanten Verbesserungen. Dieser Eindruck wird auch durch den in den Liniendiagrammen widergegebenen Verlauf des Informationsgehalts bestätigt. Hier wird ja nicht der Gesamtwert des Informationsgehalts gemessen, sondern der Anteil der in der Cluster-Beschreibung enthaltenen Kollektionen in Bezug zu allen Kollektionen im Cluster gesetzt. So ist auch bei Betrachtung dieser Diagramme zu erkennen, dass die gemessenen Werte nicht durch die durchgeführten Änderungen beeinusst werden. Mit einer vergröÿerten Datenbasis werden also keine besseren Ergebnisse erzielt. Zusammenfassend lässt sich sagen, dass Dokumente mit einem hohen Anteil im Cluster gut durch die Cluster-Beschreibung repräsentiert werden. Dokumente mit einem geringen Anteil im Cluster sind dagegen auch unter Verwendung einer vergröÿerten Datenbasis kaum oder gar nicht vertreten. Man kann sie zwar nach mehreren verfeinernden Browsing-Schritten erreichen, eine gezielte Auswahl der/des korrekten Cluster(s) ist allerdings aufgrund der mangelnden Beschreibung in den meisten Fällen nicht möglich. Ein Vergröÿerung der für das globale Clustering verwendeten Datenbasis bringt keine Verbesserung dieser Problematik. 76

83 5.3. Ergebnisanalyse Retrieval-Qualität bei der automatischen Selektion Bei dieser Testreihe ging es darum, die Retrieval-Qualität der automatischen Selektion einer Datenquelle auf Basis einer Benutzeranfrage zu bewerten. Interessant war es hier zu sehen, ob bei einer steigenden Verteilung der Dokumente einer Kollektion im Netzwerk weiterhin die Datenquelle zurückgeliefert wird, die am wahrscheinlichsten zur Anfrage relevante Dokumente liefern kann. Per Denition war dies die Datenquelle, auf der die gröÿte Anzahl von Dokumenten der zur Anfrage relevanten Kollektion abgelegt wurde. In Abbildung 5.8 sind nun auf den oberen Diagrammen die gemessen Werte bei steigender Verteilung der OAI-Kollektion im Netzwerk abgebildet. Die unteren beiden Diagramme stellen nur den Anteil der in der Cluster-Beschreibung enthaltenen Kollektionen in Bezug zu allen Kollektionen im Cluster dar. Dies ist hier ausreichend, da ja die ACM-Kollektionen nur vollständig auf die einzelnen Peers verteilt wurden und somit nur eine optimale Datenquelle existiert. An den oberen Diagrammen ist nun zu erkennen, dass bei keinerlei Verteilung der Dokumente einer Kollektion immer die Datenquelle zurückgeliefert wird, auf der die Dokumente auch tatsächlich abgelegt wurden. Bei einer wachsenden Verteilung verschlechtert sich dieses Verhalten zwar, es werden aber immernoch überdurchschnittliche Datenquellen selektiert. Allerdings ist deutlich zu sehen, dass in der Umgebung mit 8 Peers keine guten Ergebnisse mehr erzielt werden, wenn die beiden Kollektionen mit der geringsten Dokumentenmenge einen hohen Verteilungsgrad aufweisen. Also tritt auch hier die Problematik auf, dass das Finden von Dokumenten mit einem geringen Anteil an der Gesamtmenge Schwierigkeiten bereitet. Bei der Versuchsreihe mit der ACM-Kollektion tritt diese Problematik nicht so deutlich hervor. Dies liegt aller Wahrscheinlichkeit nach daran, dass auf den Peers immer nur vollständige Kollektionen abgelegt wurden. Die Problematik trat ja bei der OAI-Kollektion auch erst bei steigender Verteilung auf. Da eine hohe Verteilung in der Praxis aber der Regelfall sein wird, ergibt sich hieraus schon eine Einschränkung für den weiteren Einsatz. Datenaufkommen und Zeitaufwand Im letzten Teil dieser Evaluierung ging es um das Analysieren des bei Ladevorgängen benötigten Datenaufkommens und des Zeitaufwands bei der Erzeugung des globalen Clusterings. Beim Datenaufkommen ist dabei ein linearer Anstieg gemessen worden. Das obere Diagramm in Abbildung 5.9 verzerrt diesen Verlauf, da die Skalierung der X-Achse über den gesamten Verlauf nicht konstant bleibt. Im unteren Diagramm ist zu erkennen, dass die Ladevorgänge bis zu einer Gröÿenordnung von 50 Items keinen groÿen Einuss auf die Gesamtzeit haben. Ab einer Anzahl von etwa 75 Items ändert sich dies allerdings und so machen die Ladevorgänge bei einer Datenbasis von 100 Items schon ca. 2 3 der Gesamtzeit aus Schlussfolgerungen für den Einsatz Die gesammelten Daten zeigen, dass mit der Untersuchung des Informationsgehalts der Cluster- Beschreibungen ein wichtiger Punkt untersucht wurde. So besteht tatsächlich das Problem, dass Kollektionen mit einer geringen Anzahl von Dokumenten bei der Erstellung des globalen Clusterings nicht oder nur unzureichend durch die Cluster-Beschreibungen repräsentiert werden. Da dies ein Umstand ist, der von den Benutzern eines solchen P2P-Netzwerkes nicht gesteuert werden kann, stellt dies eine Einschränkung für Cluster-basiertes Browsing in P2P-Netzen dar. 77

84 5. Evaluierung Da die hier vorgeschlagene Problemlösung, nämlich die Erweiterung der verwendeten Datenbasis, nach den Ergebnissen dieser Evaluierung keine signikaten Veränderungen bewirkt, müsste dieser Punkt weiter untersucht werden. Bis zur Lösung des Problems ergeben sich beim Einsatz die genannten Einschränkungen. Da die Qualität der erzeugten Cluster nicht explizit durch eine eigene Testreihe untersucht wurde, jedoch rudimentär aus den gesammelten Daten abzulesen ist, soll an dieser Stelle eine kurze Einschätzung dieser Thematik gegeben werden. So zeigt ein Blick auf die Ergebnisse im Anhang, dass in den meisten Fällen Cluster entstehen, die den gröÿten Anteil der Dokumente einer Kollektion enthalten. Diese Beobachtung ist sowohl bei einer geringen, als auch bei einer sehr groÿen Verteilung der Dokumente auf die Peers zu machen. Da dies dem erwarteten Ergebnis bei der Cluster-Generierung entspricht, sprechen diese Beobachtungen für eine korrekte Umsetzung der vorprozessierten Scatter/Gather-Variante für P2P-Umgebungen. Die Analyse der Retrival-Qualität bei der automatischen Selektion von Datenquellen hat gezeigt, dass in den meisten Fällen sinnvolle Ergebnisse zurückgeliefert werden. Die Beobachtung, dass die Ergbnisse bei Kollektionen mit einer geringen Dokumentenanzahl hier schlechter sind als bei Kollektionen mit einer groÿen Anzahl von Dokumenten, ist ursächlich auf die Problematik mit dem Informationsgehalt der Cluster-Beschreibungen zurückzuführen. Der für die automatische Selektion verwendete Cluster-Zentroid wird auf die selbe Art und Weise erzeugt wie alle anderen Cluster. Somit lässt sich ein Zusammenhang zwischen Cluster-Beschreibung und den Ergebnissen der automatischen Selektion herstellen. Eine Verbesserung der Cluster- Beschreibungen hätte also auch unmittelbaren Einuss auf die Retrieval-Qualität bei der automatischen Selektion. Der letzte Teilbereich dieser Evaluierung war die Messung der in P2P-Netzen notwendigen Datenübertragungen und deren Einuss auf den Zeitaufwand bei der Generierung des globalen Clusterings. Die gewonnenen Daten haben gezeigt, dass selbst bei einer Erweiterung der Datenbasis eine noch akzeptable Menge von Daten übertragen wird. Nach diesen Ergebnissen könnte also dieses Werkzeug nicht nur in internen Hochgeschwindigkeitsnetzen, sondern auch über das Internet verwendet werden. Eine Breitbandanbindung (mind. 1 MBit/s) sollte aber vorhanden sein. Allerdings muss in diesem Zusammenhang auch noch das Systemverhalten bei einer steigenden Anzahl von Netzwerkteilnehmern überprüft werden, sprich wie häug ein Hub das globale Clustering aufgrund der Dynamik im Netzwerk neu erstellen muss. 78

85 6. Zusammenfassung und Ausblick Im Rahmen dieser Arbeit wurde ein Konzept entwickelt, um Cluster-basiertes Browsing in Peer-to-Peer-Netzen zu realisieren. Diesem Konzept liegt das vorprozessierte Scatter/Gather- Verfahren zu Grunde, das für den Einsatz in verteilten Umgebungen verallgemeinert wurde. Die aus dem Konzept hervorgegangenen Browsing-Dienste basieren auf einer Reihe von entworfenen Browsing-Strategien, die hinsichtlich ihrer Nützlichkeit in einer kurzen Benutzerumfrage veriziert wurden. Auf der Grundlage der entwickelten Browsing-Dienste wurde unter Verwendung des InveX- Werkzeugs ein Prototyp implementiert, der verteiltes Browsing nach dem Scatter/Gather- Verfahren in Peer-to-Peer-Umgebungen ermöglicht. Die parallel zur Implementierung durchgeführten Funktionstests haben gezeigt, dass der Prototyp im Hinblick auf die im Konzept angestrebten Ziele nützliche Ergebnisse liefert. Die Realisierung des Prototyps kann daher als ein Proof-of-Concept angesehen werden. Einige der im Zusammenhang mit der Konzeptentwicklung aufgeworfenen Fragen wurden in einer abschlieÿenden Evaluierung genauer behandelt. So wurde die Frage untersucht, ob die für das globale Clustering verwendete Datenmenge einen hinreichend hohen Informationsgehalt bereitstellt, um beispielsweise auch kleine Dokumentenkollektionen im globalen Clustering noch ausreichend zu beschreiben. Weiterhin wurden auch die durch die verteilte Umgebung notwendigen Datenübertragungen analysiert. Dabei wurde überprüft, wie groÿ das Datenaufkommen bei verschiedenen Szenarien ist und welchen zeitlichen Anteil diese Übertragungen bei der Erstellung des globalen Clusterings ausmachen. Die in verteilten Umgebungen mögliche, und in den Browsing-Diensten auch realisierte Resource Selection von interessanten Datenquellen auf Basis einer Anfrage, wurde ebenfalls noch untersucht. Ausblick Die im Rahmen dieser Arbeit entwickelten Browsing-Strategien wurden lediglich in einer sehr geringen Anzahl potentiellen Benutzern zur Bewertung vorgelegt. Einschränkend war hier auch die Tatsache, dass die Bewertung vor der eigentlichen Implementierung durchgeführt und somit nur auf einer abstrakten Ebene vorgenommen werden konnte. Eine vollständige Evaluierung des Prototyps und damit auch der Strategien aus Benutzersicht erscheint daher sinnvoll. Die Implementierung des Prototyps wurde in dieser Arbeit auf der Basis von Java-Sockets realisiert. Damit ist zwar Kommunikation auf P2P-Basis möglich, jedoch sind hier keine Funktionen wie beispielsweise Verwaltungsfunktionen verfügbar. Eine angepasste Implementierung könnte daher unter Verwendung von JXTA-Technologie erfolgen. Somit würden automatisch eine Reihe elementarer P2P-Konzepte zur Verfügung stehen. Denkbar wäre auch eine Integration der entwickelten Dienste in das Projekt Pepper, um dessen Architektur mit einer Browsing- Komponente zu erweitern. Synergieeekte könnten hier im Bereich der Resource Selection erzielt werden. 79

86 6. Zusammenfassung und Ausblick Bei der Entwicklung der Browsing-Dienste für Hubs wurde bisher nur eine ache Cluster- Struktur auf dem Hub generiert. Bei einer Browsing-Sitzung werden daher direkt im ersten Schritt eine Reihe von Peers kontaktiert, um benötigte Daten nachzuladen. Diese Vorgehensweise könnte in einer groÿen Netzwerkumgebung mit vielen Teilnehmern eine groÿe Anzahl von Datenübermittlungen notwendig machen. Ein denkbarer Ansatz wäre es, auch auf dem Hub eine Cluster-Hierarchie zu generieren, um so die ersten Browsing-Schritte primär auf einem leistungsstarken Gerät durchzuführen. Allerdings würde dies tendentiell wieder mehr in Richtung Client/Server-Architektur gehen. Die im Verlauf der Evaluierung aufgedeckte Problematik mit dem Informationsgehalt einer Cluster-Beschreibung sollte weiter untersucht werden. So könnte die Qualität der Cluster- Beschreibungen bei der Verwendung eines anderen Cluster-Algorithmus beobachtet werden. Weiterhin könnte erforscht werden, welche Ergebnisse erzielt würden, wenn keine vorgegebene Anzahl von Clustern generiert werden soll, sondern bei hinreichend groÿen Unterschieden neue Cluster erzeugt werden. Auch der Einsatz eines anderen Termgewichts sollte untersucht werden. Bei der aktuellen Implementierung könnte zusätzlich noch analysiert werden, wie sich die Cluster-Beschreibungen bei weiteren Browsing-Schritten entwicklen und so beobachtet werden, wann eine bisher nicht vertretene Kollektion in der Beschreibung eines Clusters wiederzunden ist. 80

87 Anhang 81

88

89 A. Kongurationsschlüssel Klassisches InveX-Werkzeug Schlüssel data iscompusciencecollection usecollectionidentifier flatclustering similaritymeasure weight storage frequenttermcount exampledocumentscount desirednumberofclusters maxnumberofmd Beschreibung Pfad zum Verzeichnis, in dem die zu verwendenden Dateien im XML-Format abgelegt sind Gibt an, ob die einzulesenden Dokumente ACM-Klassizierte CompuScience-Dokumente sind oder nicht. Mögliche Werte sind true oder false. Gibt an, ob die aus einem Dokument extrahierte Kollektionsbezeichnung im InveX-Werkzeug unter dem Punkt Collections angezeigt werden soll. Mögliche Werte sind true oder false. Vollqualizierender Klassenname des achen Clustering, das während der Scatter/Gather-Schritte genutzt wird Vollqualizierender Klassenname des Ähnlichkeitsmaÿes Vollqualizierender Klassenname des Termgewichts Vollqualizierender Klassenname des Speichersystems Anzahl der Terme, die ein Item speichern soll Anzahl der Beispieldokumente, die ein Cluster besitzen soll Anzahl der Cluster, die ein aches Clustering generieren soll Obergrenze der Anzahl von MD für einen Scatter/Gather-Schritt Tabelle A.1.: Programmweite Kongurationsschlüssel Schlüssel database.driver database.url database.user database.password database.connectiontimeout Beschreibung Voll-qualizierender Klassenname des Datenbanktreibers URL der Datenbank: API:DATABASE://IP/NAME Benutzername Kennwort Zeit in Stunden für Neuaufbau der Datenbankverbindung Tabelle A.2.: Kongurationsschlüssel des Speichersystems Database Schlüssel buckshot.subroutine Beschreibung Voll-qualizierender Klassenname der von Buckshot zu nutzenden Cluster-Subroutine Tabelle A.3.: Kongurationsschlüssel des Clustering-Verfahrens Buckshot 83

90 A. Kongurationsschlüssel P2P-Erweiterte Version des InveX-Werkzeugs Schlüssel Beschreibung commlayer Voll-qualizierender Klassenname der für Peer-to-Peer- Funktionalität zu nutzenden Kommunikationsschicht. Jedes Gerät im Netzwerk muss die selbe Kommunikationsschicht verwenden, um mit anderen Geräten kommunizieren zu können. Tabelle A.4.: Allgemeine P2P-Kongurationsschlüssel Schlüssel idprefix addressofhub usepeeridentifier Beschreibung Gibt ein Präx an, welches der ID aller eingelesenen/erzeugen Dokumente/Metadokumente vorangestellt wird. Mit dieser ID kann die Datenquelle, in welcher dieses (Meta)Dokument abgelegt ist, eindeutig identiziert werden. Das Präx ist daher entweder die IP-Adresse der Datenquelle oder ein im Netzwerk eindeutiger Peer-Name. Eindeutiger Name/Adresse des Hubs im Netzwerk, mit dem sich der eigene Peer verbinden soll. Ein Peer kann immer nur mit genau einem Hub verbunden sein. Gibt an, ob der in der Konguration unter idprefix angebene eindeutige Peer-Identizierer im InveX-Werkzeug unter dem Punkt Data Source angezeigt werden soll. Mögliche Werte sind true oder false. Tabelle A.5.: Peer-Spezische-Kongurationsschlüssel Schlüssel otherhubsonnetwork addressesofotherhubs Beschreibung Gibt an, ob sich im Netzwerk noch andere Hubs benden als der eigene. Falls ja, muss in der Konguration der Schlüssel addressesofotherhubs existieren und mindestens einen Wert enthalten. Mögliche Werte sind true oder false. Gibt die Adressen/eindeutige Bezeichner der anderen Hubs im Netzwerk an. Die einzelnen Werte werden durch Doppelpunkte (':') getrennt. Tabelle A.6.: Hub-Spezische-Kongurationsschlüssel 84

91 B. Befragungsbogen für die Nutzerumfrage Mit Hilfe dieses Befragungsbogens sollen Sie, liebe Probandin/lieber Proband, die im Rahmen dieser Diplomarbeit entworfenen Browsing-Strategien hinsichtlich ihrer Nützlichkeit überprüfen. Dazu werden Ihnen konkrete Situationen vorgestellt, in denen Sie, bedingt durch eine gestellte Aufgabe, ein Informationsdezit ausgleichen müssen. Die konkreten Situationen werden dabei durch Szenarien repräsentiert, die als globale Aufgabe eine Recherche in organisationsinternen Dokumentenarchiven beinhalten. Dabei wird davon ausgegangen, dass im jeweiligen Umfeld jeder Mitarbeiter Dokumente auf seinem eigenen PC abgelegt hat, wobei die PCs mittels P2P- Technologie miteinander vernetzt sind. Der Begri Dokument umfasst dabei alle denkbaren Ausprägungen von Texten wie beispielsweise Berichte, Artikel, Bücher, Web-Seiten etc. Ihre Aufgabe ist es nun, anhand eines vorgelegten Ablaufdiagramms mit verschiedenen Auswahlmöglichkeiten einen von Ihnen bevorzugten Weg zum erreichen der Ziele aufzuzeigen. Dies sollten die gleichen Schritte sein, die Sie intuitiv auch bei der Benutzung einer Software durchführen würden. Gleichzeitig haben Sie zu jeder Zeit die Möglichkeit, nicht nur einen vorgegebenen Schritt zu wählen, sondern auch eigene Ideen einzubringen und so vielleicht fehlende Funktionen aufzuzeigen. Zusätzlich werden bei einigen Schritten Verweise auf Abbildungen zu einer prototypischen Benutzeroberäche angegeben, bei denen Sie angeben sollen ob diese Form für Sie bereits ausreichend ist oder ob Sie sich noch weitere Informationen wünschen. Szenario 1 - Datenbankadministrator(in) in einem Unternehmen Situation: Einstieg als neue(r) Mitarbeiter(in) in die Abteilung. Aufgabe: Einarbeitung in die verwendeten Software-Produkte und Technologien durch Sichtung des internen Dokumentenbestands. Ziel: Gewinnen einer Gesamtübersicht und identizieren von interessanten Dokumenten Szenario 2 - Redakteur(in) bei einem Zeitschriftenverlag Situation: Sie sind rmenintern in eine neue Redaktion gewechselt. Aufgabe: Machen Sie sich mit den Themen vertraut, die in den letzten zwei Jahren Gegenstand der Berichterstattung waren. Ziel: Erforschen der behandelten Thematiken Szenario 3 - Student(in) an einer (Fach-)Hochschule Situation: Teilnahme an einem Seminar im gewählten Schwerpunktfach. Aufgabe: Das gewähltes Thema ist im Rahmen einer Seminararbeit zu bearbeiten. Ziel: Finden von themenspezischen Dokumenten 85

92 B. Befragungsbogen für die Nutzerumfrage 86