Inhaltsverzeichnis - sebis

Inhaltsverzeichnis
1 Einleitung und Motivation
1.1
1.2
Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . .
Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Verwandte Systeme
2.1
2.2
2.3
2.4
Social Bookmarking mit del.icio.us . . . . . . . . . . .
Das Social Network von facebook.de . . . . . . . . . .
Automatische Bewertung von Blogs bei technorati.com
Abgrenzung zum Kompetenznetz . . . . . . . . . . . .
3 Anforderungen
3.1
3.2
Funktionale Anforderungen . . . . . . . . . .
3.1.1 Überblick . . . . . . . . . . . . . . . .
3.1.2 Paket: Benutzerverwaltung . . . . . .
3.1.3 Paket: Bewertung und Kategorisierung
3.1.4 Paket: Suche . . . . . . . . . . . . . .
Nichtfunktionale Anforderungen . . . . . . . .
4.1
4.2
4.3
4.4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Entitäten . . . . . . . . . . . . . . . . . . . . . .
4.1.2 Beziehungen zwischen Entitäten . . . . . . . . .
Objektorientierter Entwurf . . . . . . . . . . . . . . . . .
4.2.1 Konzeptioneller Entwurf . . . . . . . . . . . . . .
4.2.2 Implementierungsnaher Entwurf . . . . . . . . .
Bewertungsinferenz . . . . . . . . . . . . . . . . . . . . .
4.3.1 Grundannahmen zur Bewertungsinferenz . . . . .
4.3.2 Ein einfacher Kalkül zur Bewertungsinferenz . . .
4.3.3 Diskussion der Bewertungsinferenz . . . . . . . .
Beziehungen zwischen Kompetenzfeldern . . . . . . . . .
4.4.1 Repräsentation von Kompetenzfelder durch Tags
4.4.2 Beziehungen zwischen Tags . . . . . . . . . . . .
4.4.3 Berechnung der Ähnlichkeit zwischen Tags . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Lösungsentwurf
.
.
.
.
.
.
.
.
.
.
3
4
4
6
6
7
9
10
12
12
13
14
15
18
19
21
21
22
23
25
25
28
33
33
35
41
43
43
44
44
4.4.4
4.4.5
Automatische Erstellung hierarchischer Beziehungen .
Diskussion und weiterführende Konzepte . . . . . . . .
5 Implementierung
5.1
5.2
5.3
Entwurf und Implementierung des Inferenzalgorithmus . . . .
5.1.1 Verwendete Datenstrukturen . . . . . . . . . . . . . .
5.1.2 Implementierung in Java . . . . . . . . . . . . . . . . .
Implementierung der automatischen Beziehungsgenerierung zwischen Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Verwendete Datenstrukturen . . . . . . . . . . . . . .
5.2.2 Implementierung in Java . . . . . . . . . . . . . . . . .
Implementierung der Benutzerschnittstelle als Webanwendung
6 Zusammenfassung und Ausblick
6.1
Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
46
49
51
51
52
53
57
57
59
61
67
68
Kapitel 1
Einleitung und Motivation
Das Internet, bzw. genauer das World Web Web, hat sich vom urspünglichen Netzwerk zum Austausch von Forschungsergebnissen zwischen einer
handvoll wissenschaftlicher Einrichtungen und Universitäten (BL89) zu der
gröÿten, öentlich zugänglichen Informationsquelle entwickelt. Die Anzahl
der Benutzer, und mit ihnen die Anzahl der publizierten Inhalte, ist seitdem
stark gewachsen und umfasst laut aktuellen Schätzungen über 27 Milliarden
Webseiten1 .
Einher mit diesem Wachstum des Internets rückt die Frage nach der Qualität der angebotenen Inhalte zunehmends in den Vordergrund. So gibt es
zu den meisten nachgefragten Themen im Internet ein weites Spektrum an
qualitativ unterschiedlichen Informationen, wobei deren Qualität für NichtFachkundige oft nur schwer einschätzbar ist.
Einen vielversprechenden Ansatz in diesem Zusammenhang stellen reputationsbasierte Lösungen zur Bewertung von Inhalten dar. Reputation stellt
nach (Ar08) die Auÿenbewertung des eigenen Verhaltens dar und besteht aus
zwei grundlegenden Teilen. Zum einen die Bewertung durch andere Teilnehmer und zum anderen die Bestätigung dieser Aussagen durch eine anerkannte
Autorität. Für eine stabile Reputationsplattform wird danach neben einem
glaubhaften Bewertungssystem, welches Vertrauen schaen und Missbrauch
vorbeugen soll, eine glaubwürdige Autorität benötigt, die diese Bewertungsaussagen stützt.
Der Aufbau einer reputationsbasierten Kooperationsplattform zur Bewertung und Bewertungsermittlerung der Qualität von Dokumenten im Web
kann somit einen Beitrag dazu leisten, Informationen im Internet besser ein1
Aktuelle Schätzungen basierend auf den von groÿen Suchmaschinen erfassten Webseiten, online abrufbar unter http://www.worldwidewebsize.com
3
schätzen zu können, ohne selber ein tiefgehendes Verständnis der nachgefragen Thematik vorauszusetzen.
1.1
Aufgabenstellung
Grundlegendes Ziel dieser Arbeit ist die Konzeption und prototypische Realisierung eines Kompetenznetz-Systems, das Nutzern helfen soll, vertrauenswürdige Aussagen über Inhalte im Web zu erhalten. Dazu soll das System
neben den Aussagen von Personen zu Inhalten auf einem Kompetenzfeld
und den Aussagen von Personen zu Kompetenzen anderer Personen auch
die Beziehungen (z.B. Teilkompetenz) der Kompetenzfelder untereinander
berücksichtigen.
Aus diesen Elementaraussagen sollen dann durch Anwendung eines Inferenzmechanismus weitere Aussagen generiert werden, um somit z.B. eine Bewertung zu einem Webinhalt aus der Aussage einer dem Nutzer bekannten
Person zum Inhalt sowie der Kompetenzaussage des Nutzers dieser Person
gegenüber, abzuleiten.
Im Rahmen dieser Arbeit sollen dabei die Anforderungen an ein solches
Kompetenznetz-System erhoben und ein solches System prototypisch realisiert werden. Dabei sind besonders die Funktionen bereits bestehender Systeme mit verwandten Aufgaben zu berücksichtigen und auf Relevanz für das
Kompetenznetz-System zu überprüfen. Im anschlieÿenden Software-Entwurf
sind diese Funktionen in objektorientierter Weise umzusetzen. Eine abschlieÿende prototypische Realisierung der Kernbestandteile des Systems zeigt die
Umsetzbarkeit in der Praxis auf.
1.2
Gliederung
Die vorliegende Arbeit gliedert sich wie folgt. In Kapitel 2 beschreiben wir
verwandte Systeme, die für diese Arbeit relevant sind. Dabei gehen wir auf
Gemeinsamkeiten zu Systeme aus den Bereichen Social Bookmarking, Social
Networks sowie Online-Bewertung ein, zeigen aber auch auf, inwiefern sie
sich davon unterscheiden.
Kapitel 3 zeigt die Anforderungen an ein Kompetenznetz-System auf, wobei
zunächst die funktionalen Anforderungen mithilfe von Anwendungsfalldiagrammen beschrieben werden. Anschlieÿend denieren wir die nichtfunktionalen Anforderungen an die Kooperationsplattform.
4
Kapitel 4 beinhaltet den eigentlichen Lösungsentwurf des Systems und beschreibt ausgewählte Lösungsbausteine detaillierter. Dabei wird zunächst ein
Datenmodell entwickelt, das in einen objektorientierten Entwurf überführt
und anschlieÿend um Implementierungsdetails erweitert wird. Des weiteren
wird der in dieser Arbeit verwendete Inferenzmechanismus vorgestellt und
in einem Kalkül formalisiert. Abschlieÿend wird auf die Bedeutung von Tags
zur Repräsentation von Kompetenzfeldern eingegangen, und erläutert, wie
mögliche Beziehungen zwischen Tags ermittelt werden können.
Details zur Implementierung von Kernbestandteilen des Systems werden in
Kapitel 5 beschrieben. Dabei wird neben dem Inferenzmechanismus und der
automatischen Generierung von Ähnlichkeitsbeziehungen zwischen Kompetenzfeldern die Realisierung der Benutzerschnittstelle beschrieben.
Kapitel 6 fasst die Erkenntnisse dieser Arbeit zusammen. Darüber hinaus
werden Aspekte aufgezeigt, die nicht adressiert werden konnten, und Perspektiven für die weitere Erforschung sowie die Weiterentwicklung des Systems gegeben.
5
Kapitel 2
Verwandte Systeme
Gegenwärtig existiert bereits eine Vielzahl von Web 2.0 Anwendungen in
den Bereichen Social Networks, Social Bookmarking sowie automatisierter
Bewertungs- und Empfehlungssystemen von Weblogs. Die Anwendungen in
diesen Bereichen stellen ähnliche Funktionen bereit wie die Kooperationsplattform, welche im Rahmen vorliegender Arbeit entwickelt werden soll.
Demnach lässt sich eine konzeptionelle Abgrenzung treen, die in diesem
Kapitel diskutiert werden soll. Dabei erfolgt im Vorfeld eine Vorstellung bestehender Web 2.0-Konzepte jeweils anhand eines ausgewählten Vertreters.
Hierbei wird auch auf deren Realisierungsaspekte eingegangen, sofern dies
für die Arbeit relevant ist.
Zuerst stellen wir die Plattform del.icio.us vor, die ein erweitertes, kooperatives Konzept zur Verwaltung von Lesezeichen, welches als Social Bookmarking
bezeichnet wird, implementiert. Danach wird das Social Network facebook.de
vorgestellt. Das letzte vorgestellte System stellt hierbei technorati.com dar,
eine Webanwendung, die automatisch Weblogs erfasst und bewertet.
Der letzte Abschnitt dieses Kapitels diskutiert abschlieÿend die Gemeinsamkeiten der bestehenden Systeme zum Zielsystem der Arbeit und stellt die
bedeutsamen Unterschiede heraus.
2.1
Social Bookmarking mit del.icio.us
Die Webanwendung del.icio.us, welche in Abbildung 2.1 dargestellt ist, realisisert die Idee des Social Bookmarking (Ha05), welche die konventionelle
Lesezeichenverwaltung, wie sie beispielsweise in gängigen Webbrowsern implementiert ist, erweitert. Dabei werden die vom Benutzer erstellten Lesezei6
Abbildung 2.1: Die Social Bookmarking Software del.icio.us
chen nicht lokal auf dem eigenen Rechner sondern online auf der Plattform
gespeichert und verwaltet. Den Lesezeichen werden zusätzlich vom Benutzer
erstellte Stichwörter, sogenannte Tags, zugeordnet. Dies dient der Klassikation von Lesezeichen und erleichtert deren Suche.
Dies allein wäre auch mit einer konventionellen Lesezeichenverwaltung möglich. Einen weiteren wesentlichen Aspekt des Social Bookmarking bildet die
zentrale Speicherung der Lesezeichen und Tags, wodurch es möglich wird diese zwischen verschiedenen Benutzern zu teilen. So ist es bei del.icio.us möglich, gezielt nach Tags zu suchen, woraufhin die Lesezeichen aller Benutzer
angezeigt werden. Im Gegensatz zu Suchmaschinen können somit nicht nur
Informationen gefunden werden, die zu einem oder mehreren Tags passen,
sondern diese werden oft auch nach bestimmten Kriterien, wie im Beispiel
von del.icio.us die Anzahl der Benutzer die eine Seite als Lesezeichen haben,
sortiert. Darauf aufbauend lässt sich eine Rangliste mit nach Beliebtheit (im
Sinne der Anzahl der Benutzer die diese Seite als Lesezeichen hinzugefügt
haben) sortierter Lesezeichen erstellen.
2.2
Das Social Network von facebook.de
Stellvertretend für den Bereich der Social Networks (We96) wird hier facebook.de (vgl. Abbildung 2.2), der deutsche Ableger von facebook.com, unter7
Abbildung 2.2: Der Startbildschirm für angemeldete Benutzer bei facebook.de
sucht. Neben facebook existieren noch viele weitere Plattformen wie
XING.com, regional fokussierte Plattform wie lokalisten.de oder auf eine
besondere Benutzergruppe zugschnittene Plattformen wie studivz.de, wobei
allen derartigen Systemen die selbe Grundidee zueigen ist, welche nachfolgend erklärt wird.
Bei Social Networks im Allgemeinen geht es darum, andere Personen zu suchen und nden, um mit diesen in Kontakt zu treten oder bleiben. Dazu
muss man in der Regel zuerst ein eigenens Benutzerprol anlegen. Dann
fügt der Benutzer (bereits vorhandene) soziale Kontakte (bei facebook.de
Freundschaften genannt) zu seinem Prol hinzu, so dass die sozialen Kontakte ebenfalls im Prol abgebildet werden und somit ein Netzwerk entsteht.
Dies ermöglicht eine einfache Suche in den sozialen Netzwerke von Bekannten und Freunden und das Kennenlernen sowie der Nachrichtenaustausch mit
anderen Benutzern. Das Aunden von Personen wird bei facebook.de über
deren Benutzernamen, realen Namen oder die bei facebook.de registrierte
E-Mailadresse ermöglicht.
Bei facebook.de werden dem Benutzer zahlreiche Möglichkeiten gegeben, sein
Prol möglichst fein auszuarbeiten. So können neben dem Angaben zu seiner
Person einschlieÿlich Vorlieben, Hobbies, momentane Aktivität, etc. auch
Bilder und sogar Videos in einem persönlichen, virtuellen Album hochgeladen
8
und darauf andere Personen aus dem Netzwerk markiert werden. Nutzern
wird bei Aufruf eines Prols angezeigt, über welche Personen man diese
kennt. Daneben können Gruppen erstellt werden, denen mehrere Personen
beitreten können, entweder durch Anfrage beim Ersteller der Gruppe oder
durch Einladung.
Social Networks unterliegen dabei dem von (Mi67) betrachteten Kleine-WeltPhänomen. Untersuchungen zufolge ist jeder Mensch auf der Welt mit jedem
anderen über eine überraschend kurze Kette von Bekanntschaftsbeziehungen
verbunden, wobei in den Experimenten von Milgram eine durchschnittliche
Pfadlänge von aufgerundet sechs ermittelt wurde. Auch wenn sich aufgrund
der Natur von Social Networks dieses Phänomen nicht uneingeschränkt anwenden lässt, da in einem Softwaresystem nicht alle Bekanntschaftsbeziehungen abgebildet sind, bewirkt die Darstellung des kurzen Bekanntschaftspfades zu jedem registrierten Mitglied ein Gemeinschaftsgefühl und fördert den
Community-Gedanken.
Social Networks wie facebook.de haben sich in letzter Zeit massiv verbreitet, wobei im Grunde die Möglichkeiten, die diese bieten, bereits vorhanden
waren, allerdings nie in einer derart integrativen Art wie in Form der oben
genannten Plattformen, zu denen auch facebook.de zählt.
2.3
Automatische Bewertung von Blogs bei technorati.com
Technorati.com ist eine bekannte Webanwendung, die eine Suchmaschine mit
Bewertungsmechanismus für Weblogs zur Verfügung stellt. Weblogs, oder
kurz Blogs, sind virtuelle Tagebücher, die öentlich zugänglich gemacht werden. Von den Autoren, Blogger genannt, werden die Einträge verfasst, die sie
für wichtig erachten. Dabei ist es bei Blogs üblich, dass sich die Inhalte häug
ändern, und dass zu den Einträgen zumeist eine Kommentarfunktion angeboten wird. Dabei wird häug in den Blogeinträgen selbst, aber auch in den
dazu erstellten Kommentaren, in Form von Links auf andere Blogs verwiesen. Die Spannweite von Blogs ist enorm. Es gibt kleine Blogs, die eigentlich
nur für einen kleineren Kreis von Leuten geschrieben wurden, als auch groÿe
und einuÿreiche Blogs, z.B. von Politikern, welche die Unmittelbarkeit zur
Bevölkerung nutzen wollen.
Technorati.com dient dabei als Plattform zur Anzeige von Einträgen aus
einer Vielzahl von Blogs, wobei mittels einer Suchfunktion interessante Einträge schneller gefunden werden können. Dies geschieht unter Nutzung einer
Bewertungsfunktion für die Einträge, um die interessantesten davon auf der
9
Abbildung 2.3: Ein Blogeintrag bei technorati.com
ersten Seite bzw. schneller erreichbar anzuzeigen. Da aufgrund der hohen
Anzahl der berücksichtigten Blogs eine manuelle Bewertung, z.B. durch eine
Redaktion, nicht praktikabel ist, wird diese Bewertung automatisch erzeugt.
Dabei wird von technorati.com die Anzahl der Blogs, die auf das zu bewertende Blog verweisen, ermittelt, wobei dies dann als Metrik für die Beliebtheit eines Blogs gewertet wird. Dies wird bei technorati.com als Authority
bezeichnet. Abbildung 2.3 zeigt die Plattform mit Blogeinträgen und dem
dazugehörigen Authority -Wert.
2.4
Abgrenzung zum Kompetenznetz
All die in diesem Kapitel vorgestellten Systeme sind in gewissem Maÿe mit
dem in der Arbeit zu entwickelnden Kompetenznetzsystem verwandt:
• Das hier zu entwickelnde System soll Benutzeraussagen über andere
Benutzer zulassen, also handelt es sich um eine Erweiterung eines in
Abschnitt 2.2 am Beispiel von facebook.de beschriebenen Social Networks.
• Ebenfalls sollen Informationen im World Wide Web bewertet werden, wozu eine Verwaltung dieser Dokumente ähnlich der Plattform
del.icio.us (vgl. Abschnitt 2.1) mithilfe von Lesezeichen für die Kooperationsplattform benötigt wird.
10
• Darüber hinaus soll auch eine Bewertung für nicht selbst bewertete
Dokumente erzeugt werden. Im optimalen Fall passiert dies wie bei
technorati.com (vgl. Abschnitt 2.3) vom System automatisch, d.h. ohne
Zutun des Benutzers.
Trotz all dieser Gemeinsamkeiten ist das Ziel dieser Arbeit kein Nachbau
bereits existierender Systeme. Vielmehr sollen die Funktionen dieser drei
Teile miteinander verbunden und dadruch ein Mehrwert für die Benutzer
geschaen werden.
So beinhaltet die Kooperationsplattform zwar im Kern ein Social Network,
allerdings wird dieses durch eine Lesezeichenverwaltung ähnlich der von
del.icio.us sowie die Bewertungsfunktionalität, sowohl für Benutzer als auch
Dokumente, erweitert. Zusätzlich wird erst durch die Verbindung dieser Mechanismen ermöglicht, vertrauenswürdige Aussagen über Dokumente zu erlangen, die man selbst nie bewertet hat, was über die einfache Bewertungsbildung bei technorati.com hinausgeht.
11
Kapitel 3
Anforderungen
In diesem Kapitel werden die Anforderungen zum Aufbau eines reputationsbasierten Kompentenznetzwerks erhoben. Dabei wird nach (So04) zwischen
funktionalen sowie nichtfunktionalen Anforderungen unterschieden.
Zunächst werden die funktionalen Anforderungen behandelt. Dabei werden
die Notationselemente, die nachfolgend zur Anwendung kommen, erläutert.
Anschlieÿend wird ein Überblick über das zu realisierende System gegeben,
und danach die funktionalen Anforderungen der einzelnen Teile anhand von
Diagrammen und Beschreibungen im Detail erläutert.
Abschlieÿend werden die nichtfunktionalen Anforderungen an die Kooperationsplattform beschrieben. Diese nehmen direkten Einuÿ auf weitere Entwurfsentscheidungen der Software, worauf in Kapitel 4.2 nochmals eingegangen wird.
3.1
Funktionale Anforderungen
Zur Beschreibung der funktionalen Anforderungen werden Anwendungsfalldiagramme (engl. use-case diagrams ) verwendet, welche Abstraktionen von
konkreten Anwendungsszenarien darstellen und sich im Software-Engineering
für die Anforderungsanalyse als besonders geeignet erwiesen haben. Die graphische Notation von Anwendungsfalldiagrammen entspricht dabei dem weitverbreiteten UML2 Standard (OM07).
Dabei wird der Standard, wie bei (BD03) verwendet, um den Stereotyp initiate erweitert. Dieser Stereotyp kann Beziehungen zwischen Akteuren und
Anwendungsfällen annotierten. Dabei drückt er aus, dass ein Akteur einen
12
gewissen Anwendungsfall von sich aus initiert, d.h. er gibt den entscheidenden Impuls (z.B. durch einen Mausklick), der den Anwendungsfall startet.
Dies ist bei Anwendungsfällen, die nicht mit diesem Stereotyp annotiert sind,
nicht unmittelbar der Fall. So könnte beispielsweise ein Anwendungsfall vom
System selbst gestartet werden und erst dann den Akteur miteinbeziehen.
Ergänzend zur graphischen Notation mittels UML werden die Anwendungsfälle in natürlicher Sprache beschrieben und in der Form UCxx eindeutig
durchnummeriert. Dies ist insofern hilfreich, dass im weiteren Verlauf der
Arbeit auf einzelne Anforderungen referenziert werden kann.
3.1.1
Überblick
Bevor nun die funktionalen Anforderungen an das System detailliert erläutert
werden, soll zunächst ein kurzer Überblick helfen, die nachfolgend im Detail
beschriebenen Teile besser im Kontext der gesamten Anwendung einordnen
zu können.
Zur besseren Gliederung der Anforderungen unterteilen wir das System in
Pakete. Diese Pakete (annotiert mit dem UML Stereotyp package) haben die Aufgabe, zusammengehörige oder funktional ähnliche Anforderungen in Form von Anwendungsfällen zu gruppieren. Tauchen in mehreren
Diagrammen gleichnamige Pakete oder Anwendungsfälle auf, so handelt es
sich tatsächlich um das selbe Paket bzw. den selben Anwendungsfall. Die
Anwendungsfälle verteilen sich dabei auf die folgenden Pakete:
Benutzerverwaltung
Zur Benutzerverwaltung gehören alle funktionalen
Anforderungen rund um das Benutzerkonto eines Benutzers, der aktiv
in Interaktion mit dem System steht. Hierzu zählen auch Anwendungsfälle im Zusammenhang mit der Authentizierung von Benutzern sowie
das eigentliche Anlegen von Benutzerkonten, also die Benutzerverwaltung im engeren Sinne.
13
Bewertung und Kategorisierung
Die Bewertung und Kategorisierung
umfasst alle Anwendungsfälle, die sowohl mit der Bewertung von Dokumenten als auch von anderen Benutzern in Zusammenhang stehen.
Desweiteren beinhaltet sie die Anwendungsfälle, die der Verwaltung
von Zuordnungen (Kategorisierung ) von Bewertungen zu Kompetenzfeldern dienen.
Inferenz
Die Aufgabe der Inferenz ist es, aus den vorhandenen Bewertungen von Benutzern und Dokumenten sowie den Beziehungen zwischen
Benutzern eine vertrauenswürdige Aussage über andere, als vom Benutzer selbst bewertete, Dokumente zu erhalten. Das Paket Inferenz
enthält konsequent nur einen Anwendungsfall Bewertung inferieren,
dessen Funktionsweise in Abschnitt 4.3 erläutert wird. Deswegen wird
auf eine Erläuterung zu diesem Anwendungsfall nachfolgend verzichtet.
Suche
Zur Suche gehören alle Anwendungsfälle, die sich der Aundung
von Dokumenten und Benutzern zuordnen lassen. Dabei kann nach
verschiedenen Kritieren wie Kompetenzfeldern und Benutzern sowie
nach Benutzerdetails wie Vorname, Nachname etc. gesucht werden.
3.1.2
Paket: Benutzerverwaltung
Die Anwendungsfälle der Benutzerverwaltung sind in dem Anwendungsfalldiagramm in Abbildung 3.1 dargestellt. Die Anwendungsfälle sind wie folgt:
UC01 Registrieren
Dieser Anwendungsfall ermöglicht die Erstellung eines
Benutzerkontos. Dabei muss ein Benutzer seine Daten wie gewünschter
Benutzername, Passwort und E-Mailadresse angeben. Dabei wird dem
Benutzer direkt im Anschluÿ eine Bestätigungsnachricht zugesendet,
mit der er sein Konto durch einen darin enthaltenen Link aktivieren
kann. Bei einer erfolgreichen Aktivierung wird die Aktion Anmelden
ausgeführt, wobei der Benutzername sowie das Passwort automatisch
übergeben werden.
UC02 Anmelden
Der Benutzer meldet sich am System mit seinem Benutzernamen und Passwort an. Der Anwendungsfall Anmelden ist die
Grundvoraussetzung für alle anderen Anwendungsfälle auÿer Registrieren. Nach erfolgreichem Abschluss dieses Anwendungsfalls wird der
Benutzer vom System erkannt.
UC03 Abmelden
Der Benutzer kann sich zu jedem Zeitpunkt vom System
abmelden. Ab diesem Zeitpunkt wird er vom System nicht länger als
ein bestimmter Benutzer erkannt.
14
Abbildung 3.1: Anwendungsfalldiagramm der Benutzerverwaltung
UC04 Einladen
Benutzer haben die Möglichkeit andere Benutzer, die noch
nicht registriert sind, in das Kompetenznetz einzuladen. Dazu wird der
Name sowie die E-Mailadresse des einzuladenden Benutzers angegeben.
Das Einladen einer Person erfordert auch das Bewerten der einzuladenden Person. Siehe dazu UC09 Benutzer bewerten in Abschnitt 3.1.3.
UC05 Eigenes Prol bearbeiten Angemeldete Benutzer können ihre persönlichen Daten ändern.
Der Anwendungsfall Benutzer bewerten wird in Abschnitt 3.1.3 beschrieben.
3.1.3
Paket: Bewertung und Kategorisierung
Die Anwendungsfälle der Bewertung und Kategorisierung sind der Übersicht
halber auf zwei Diagramme verteilt. Das Anwendungsfalldiagramm in Abbildung 3.2 zeigt dabei die Kernaktivitäten der Bewertungsabfrage sowie
Bewertungserstellung. Die Anwendungsfälle sind wie folgt:
UC06 Dokumentbewertung abfragen
Dieser Anwendungsfall beschreibt die
Anfrage des Benutzers, eine Bewertung zu einem bestimmten Doku15
Abbildung 3.2: Anwendungsfalldiagramm der Bewertungen und Inferenzen
ment zu erhalten. Dies kann durch ein einfaches Laden der entsprechenden Seite und ein entsprechendes Browser-Plugin realisiert werden als
auch durch eine direkte Angabe eines Uniform Resource Locator (URL).
Die Abfrage von Bewertungen impliziert immer, dass eine Bewertung
für das angefragte Dokument erstellt wird, weshalb der Anwendungsfall Bewertung inferieren eingeschlossen wird.
UC07 Bewertung inferieren
In diesem Anwendungsfall, der ohne Benutzereinwirkung stattndet, wird vom System eine Bewertung mittels eines
Inferenzmechanismus generiert. Der Inferenzmechanismus wird in Abschnitt 4.3 beschrieben.
UC08 Dokument bewerten
Dieser Anwendungsfall beschreibt, dass ein Benutzer ein Dokument bewerten möchte. Dabei gibt der Benutzer neben
der Web-Adresse (URL) des Dokuments auch die gewünschte Bewertung auf einer Bewertungsskala an. Durch den eingeschlossenen Anwendungsfall UC10 Angabe von Kompetenzfeldern (Tagging) erfolgt
die Angabe eines Kompetenzfeldes.
UC09 Benutzer bewerten Dieser Anwendungsfall tritt auf, wenn ein Benut-
zer einen anderen Benutzer bewerten möchte. Dabei gibt der Benutzer
neben dem zu bewertenden Benutzer sowie der gewünschten Bewertung auf einer Bewertungsskala auch die Kompetenzfelder an, die er
der Bewertung zuordnen will, weshalb der Anwendungsfall UC11 eingeschlossen ist.
UC10 Angabe von Kompetenzfeldern (Tagging) Bei diesem Anwendungsfall
ordnet der Benutzer anderen Benutzern bzw. Dokumenten Kompetenzfelder in Form von Schlagwörtern (Tags ) zu.
16
Abbildung 3.3: Anwendungsfalldiagramm der Bewertungsverwaltung
Anzumerken ist hierbei, dass es keinen Anwendungsfall für die Abfrage von
inferierten Benutzer bewertungen gibt. Wir erachten eine Möglichkeit zur Abfrage dieser Informationen als unvorteilhaft und möglicherweise schädlich für
den Aufbau der Nutzer-Community.
Die weiteren Anwendungsfälle, die sich mit der Verwaltung von vorhandenen
Bewertungen befassen, sind in Abbildung 3.3 dargestellt:
UC12 Bewertung anzeigen
Dieser Anwendungsfall ist ein abstrakter Anwendungsfall zum Anzeigen der vom Benutzer eigens vergebenen Bewertungen, der durch folgende konkrete Anwendungsfälle spezialisiert
wird:
UC12a Benutzerbewertung anzeigen Bei diesem Anwendungsfall werden dem Benutzer die bisher von ihm vorgenommenen Benutzerbewertungen angezeigt. Dabei wird ihm die Möglichkeit gegeben,
diese zu ändern oder zu löschen (siehe dazu UC13 Bewertung
ändern bzw. UC14 Bewertung löschen ).
UC12b Dokumentbewertung anzeigen Bei diesem Anwendungsfall werden dem Benutzer die bisher von ihm vorgenommenen Dokumentbewertungen angezeigt. Dabei wird ihm die Möglichkeit gegeben,
diese zu ändern oder zu löschen (siehe dazu UC13 Bewertung
ändern bzw. UC14 Bewertung löschen ).
17
Abbildung 3.4: Anwendungsfalldiagramm der Suchfunktionen
UC13 Bewertung ändern
Der Benutzer kann die von ihm vorgenommenen
Benutzer- und Dokumentbewertungen ändern, indem er die neue, gewünschte Bewertung angibt. Dieser Anwendungsfall enthält den Anwendungsfall UC12 Bewertung anzeigen und wird aktiviert sobald der
Benutzer diese Aktion bei der Bewertungsanzeige auslöst.
UC14 Bewertung löschen
Der Benutzer kann die von ihm vorgenommenen
Benutzer- und Dokumentbewertungen löschen. Dieser Anwendungsfall
enthält den Anwendungsfall UC12 Bewertung anzeigen und wird aktiviert sobald der Benutzer diese Aktion bei der Bewertungsanzeige
auslöst.
3.1.4
Paket: Suche
Die Anwendungsfälle für die Suche sind in dem Anwendungsfalldiagramm in
Abbildung 3.4 dargestellt. Die Anwendungsfälle sind wie folgt:
UC21 Benutzer suchen
Dieser Anwendungsfall ist ein abstrakter Anwendungsfall zum Suchen nach Benutzern, wobei die Ergebnisse nach der
vom Benutzer abgegebenen Bewertung, sofern vorhanden, sortiert werden. Dafür wird der Anwendungsfall UC12a Benutzerbewertung anzeigen eingeschlossen. Der Anwendungsfall wird durch folgende konkrete
Anwendungsfälle realisiert:
UC21a Benutzer nach Schlagwort suchen Sucht nach Benutzern durch
die Angabe von Schlagworten
18
UC21b Benutzer nach Details suchen
Sucht nach Benutzern durch
die Angabe von Details wie Name oder eMail-Adresse.
Durch eine geeignete Navigation ist ein Übergang zum Anwendungsfall
UC09 Benutzer bewerten möglich (siehe Abschnitt 3.1.3).
UC22 Dokument suchen Benutzer suchen
Dieser Anwendungsfall ist ein
abstrakter Anwendungsfall zum Suchen nach Dokumenten, wobei die
Ergebnisse nach der ermittelten Bewertung sortiert werden. Dafür wird
der Anwendungsfall UC06 Dokumentbewertung abfragen eingeschlossen. Der Anwendungsfall wird durch folgende konkrete Anwendungsfälle realisiert:
UC22a Dokumente nach Schlagwort suchen
durch die Angabe von Schlagworten
Sucht nach Dokumenten
UC22b Dokumente nach Benutzer suchen
Sucht nach (bewerteten)
Dokumenten eines bestimmten Benutzers
Ein Navigationsmechanismus erlaubt den Eintritt in den Anwendungsfall UC08 Dokument bewerten (siehe Abschnitt 3.1.3).
3.2
Nichtfunktionale Anforderungen
Nichtfunktionale Anforderungen beschreiben nach (BD03) "Aspekte des
Systems, die nicht unmittelbar in Bezug zu seiner Funktionalität stehen.
Dabei betreen nichtfunktionale Abhängigkeiten häug mehr als nur einen
Aspekt des Systems". Obwohl sie keinen direkten Funktionsbezug aufweisen,
können sie für den Erfolg des Gesamtsystems entscheident sein, wie in (So04)
beschrieben. Häug haben nichtfunktionale Anforderungen groÿen Einuss
auf den Systementwurf. Analog zu den funktionalen Anforderungen werden
sie in der Folge mit NRxx durchnummiert, da im weiteren Verlauf noch auf
diese referenziert werden soll. Auf eine Einordnung, wie in (BD03) nach dem
FURPS+1 Modell vorgeschlagen, wird hier aufgrund der geringen Anzahl an
nichtfunktionalen Anforderungen verzichtet, welche sich wie folgt darstellen:
NR01 Verfügbarkeit und Zuverlässigkeit
Das System muss eine Verfügbarkeit von mindestens 99% aufweisen. Dies ist nötig, um eine hohe Akzeptanz beim Benutzer zu erreichen.
1
Das FURPS+ Modell wird im USP Prozess (JBR99) verwendet. FURPS steht dabei für die benutzten Kategorien Functionality, Usability, Reliability, Performance sowie
Supportability, wobei das + für Unterkategorien steht.
19
NR02 Antwortzeiten
Die Antwortzeiten für alle Anwendungsfälle müssen
weniger als 4 Sekunden betragen, wobei die Antwortzeiten für erwartet häug nachgefragte Anwendungsfälle, z.B. die Suche nach Dokumenten und Benutzern sowie die Anzeige von Dokumentbewertungen
(einschlieÿlich der Inferenz), 2 Sekunden nicht überschreiten darf. Ziel
ist hierbei ebenfalls, die Akzeptanz durch den Benutzer zu fördern.
NR03 Flexibler Objektentwurf
Der Objektentwurf soll so gestaltet sein,
dass gewisse Mechanismen, wie der Inferenzmechanismus oder die Beziehungsverwaltung zwischen Kompetenzfeldern, exibel austauschbar
sind. Damit soll erreicht werden, dass diese Konzepte zu einem späteren Zeitpunkt einfach und ohne groÿe Zeitaufwände ersetzt werden
können.
NR04 Technologische Basis Als technologische Basis soll die Java Enterprise Edition (Java EE) Plattform verwendet werden. Dabei bieten sich
insbesondere Java Server Pages (JSP) zur Realisierung der Benutzerschnittstelle sowie Enterprise Java Beans (EJB) für die persistente
Datenhaltung an.
NR05 Browser-Kompatibilität
Die Funktionen, die durch die Anwendungsfälle deniert wurden, sollen unter allen weitverbreiteten Webbrowsern
(Internet Explorer 7.0+, Firefox 2.0+, Opera 9+) fehlerfrei darstellbar
sein. Darüber hinaus soll die Möglichkeit zur Anbindung an BrowserErweiterungen (Addons ) durch das System oen gestaltet werden.
20
Kapitel 4
Lösungsentwurf
Dieses Kapitel beschreibt den von uns gewählten Lösungsentwurf für ein reputationsbasiertes Kompetenznetz, wobei aber Details der Implementierung
erst im nachfolgenden Kapitel genauer erläutert werden.
In der Folge werden das Datenmodell und darauf aufbauend der konzeptionelle Objektentwurf näher vorgestellt. Die Ergebnisse daraus werden dann
im implementierungsnahen Objektentwurf erweitert und verfeinert.
Anschlieÿend beschreiben wir wichtige Lösungsbestandteile im Detail. Hierzu
zählt neben der zentralen Komponente zum Inferieren von Bewertungen auch
der Baustein zum Aufbau einer Taxonomie zwischen Kompetenzfeldern.
4.1
Datenmodell
Der erste logische Schritt unseres Lösungsansatzes liegt im Datenmodell. Ziel
des Datenmodells ist es, die in unserem Entwurf vorkommenden Daten so
zu strukturieren, dass eine persistente Datenhaltung ermöglicht wird. Dabei verwenden wir das relationale Datenmodell (Co70). Unsere konkreten
Anforderungen an das Datenmodell umfassen folgende:
•
Das Datenmodell muss ausnahmslos alle persistent zu speichernden Daten erfassen. Persistent zu speichernden Daten sind
die Daten, die von der Anwendung über eine Benutzersitzung hinaus
gebraucht werden.
•
Abstrakte Datentypen aus der Anforderungsanalyse werden
auf konkrete Typen übersetzt. Dabei richten sich die verwendete21
ten Datentypen nach dem SQL-92 Standard. Die Umsetzung soll dabei
keine semantischen Änderungen zwischen den abstrakten und den konkreten Typen im Datenmodell vornehmen.
•
Beziehungen zwischen Entitäten sollen im Datenmodell erkennbar sein. Durch Verwendung des relationalen Datenmodells ist
es möglich durch den Einsatz von Fremdschlüsseln, Entitäten anderen
Entitäten zuzuordnen. Dabei sind 1:1, 1:n, n:m Beziehungen zwischen
Entitäten möglich.
4.1.1
Entitäten
Wir haben während der Datenanalyse folgende Entitäten einschlieÿlich ihrer
Attribute erfasst:
Benutzer
Die Entität Benutzer (engl. user ) repräsentiert einen dem System bekannten Benutzer. Die Identikation geschieht dabei über eine
benutzerspezische Identikationsnummer. Weitere Attribute des Benutzers sind sein gewählter Benutzername, sein Passwort, sein Vorund Nachname, seine E-Mail-Adresse, seine Anschrift sowie eine kurze
Selbstbeschreibung, wobei alle diese Attribute als Zeichenketten entsprechender Länge repräsentiert werden. Der Aktivierungscode wird
für die Aktivierung bei einer Selbstregistrierung oder einer Einladung
durch einen anderen Benutzer verwendet. Der an das System übergebene Aktivierungscode muss dabei dem in der Datenbank gespeicherten
Code entsprechen. Bei bereits aktivierten Benutzern bzw. Benutzern,
die eine Einladung annehmen wird dem Attribut eine leere Zeichenkette zugewiesen. Die Repräsentation in der Datenbank erfolgt ebenfalls
als Zeichenkette entsprechender Länge.
Benutzerbewertungen
Die Entität Benutzerbewertung (engl. user_rating )
repräsentiert eine Bewertung, die von einem Benutzer über einen anderen Benutzer abgegeben wurde. Attribute einer Benutzerbewertung
stellen dabei die vergebene Bewertung selbst als auch das Datum der
Bewertungsabgabe dar.
Dokumente
Zu bewertende oder als Lesezeichen gespeicherte Dokumente
werden durch die Entität Dokumente (engl. documents ) repräsentiert.
Dokumente werden eindeutig durch ihren Uniform Resource Locator
(URL) (BLMM94) identiziert. Als weiteres Attribut wird jedem Dokument ein Titel zugeordnet, der das Dokument beschreiben soll. Beide
Attribute werden dabei als Zeichenketten variabler Länge gespeichert.
22
Dokumentbewertungen
Bewertungen zu Dokumenten werden durch die
Entität Dokumentbewertung (engl. document_ratings ) repräsentiert.
Dabei sind neben der Bewertung selber das Datum der Bewertung
sowie ein Hashcode des bewerteten Dokuments zum Zeitpunkt der Bewertung Attribute der Dokumentbewertung. Konzeptuell betrachtet
stellt der Hashcode eine Dokumenteigenschaft dar1 , wurde jedoch in
die Entität Dokumentbewertung aufgenommen, da erst in dieser der
Bezug zur Dokumentversion wichtig wird. Entsprechend existiert zu
verschiedenen Versionen nur ein Eintrag in Dokumente. Dies hat den
Vorteil, dass redundante Einträge bei der Entität Dokument verhindert
werden.
Tags
Die Entität Tags repräsentiert die Kompentenzfelder unseres Systems
in Form von Stichworten bzw. Stichphrasen. Das einzige Attribut dieser
Entität ist die Phrase selbst, welche als Zeichenkette gegebener Länge
abgespeichert wird.
4.1.2
Beziehungen zwischen Entitäten
Nachfolgend werden die von uns denierten Beziehungen zwischen den Entitäten und deren Kardinalitäten beschrieben werden. Darüber hinaus wird
angegeben, durch welche Attribute die Beziehung realisiert wird und was
Gründe und Auswirkungen der Beziehung sind. Im Mittelpunkt des Beziehungsgeechts im Datenmodell stehen die Entitäten Benutzerbewertungen
und Dokumentbewertungen. Deshalb werden nachfolgend die Beziehungen
ausgehend von diesen beiden Entitäten beschrieben.
Beziehungen der Entität Dokumentbewertungen
Folgende Beziehungen gehen von der Entität Dokumentbewertungen (engl.
document_ratings ) aus:
Beziehung zu Dokumenten
Zu jedem Dokument gehören eine bis mehrere Dokumentbewertungen, wohingegen zu jeder Dokumentbewertung
genau ein Dokument gehört.
Beziehung zu Benutzern
Zu jeder Dokumentbewertung gehört genau ein
Benutzer, wohingegen zu jedem Benutzer keine bis mehrere Dokumentbewertungen gehören. Dadurch wird erzwungen, dass jede Bewertung
genau einem Benutzer zugeordnet werden kann, und somit anonyme
Bewertungen ausgeschlossen werden.
1
Ein Hashcode berechnet sich geeignet durch eine Hashfunktion (Co01)
23
Beziehung zu Tags
Zu jeder Dokumentbewertung gehört genau ein Tag,
und ein Tag kann zu mehreren Dokumentbewertungen gehören. Der
Grund, warum man zu einer Bewertung nur ein Tag (welches ein Kompetenzfeld repräsentiert) zuordnen kann, ist, dass für jedes Kompetenzfeld eine eigene Bewertung abgegeben werden kann. Somit ist es
durchaus möglich, dass ein Benutzer zum gleichen Dokument mehrere
Bewertungen für verschiedene Tags anlegt, allerdings ist zu einem Tag
maximal eine Bewertung möglich.
Beziehungen der Entität Benutzerbewertungen
Folgende Beziehungen gehen von der Entität Benutzerbewertungen (engl.
user_ratings ) aus:
Beziehung zu bewerteten Benutzern
Jede Benutzerbewertung hat als
Bewertungsgegenstand den bewerteten Benutzer, d.h. den Benutzer für
den die Bewertung erstellt wurde. Zu jeder Benutzerbewertung gehört
genau ein bewerteter Benutzer, wohingegen ein Benutzer in keiner,
einer oder mehreren Benutzerbewertungen bewertet werden kann.
Beziehung zu bewertenden Benutzern
Jede Benutzerbewertung hat andererseits aber auch einen Benutzer, der die Bewertung abgibt, den
bewertenden Benutzer. Dabei hat jede Benutzerbewertung genau einen
solchen Benutzer, der die Wertung abgibt, aber jeder Benutzer kann
keinen, einen oder mehrere Benutzer bewerten. Analog den Dokumentbewertungen wird durch die Erzwingung der Existenz eines bewertenden Benutzers sichergestellt, dass keine anonymen Bewertungen möglich sind.
Beziehung zu Tags
Benutzerbewertungen beziehen sich analog zu Dokumentbewertungen ebenfalls auf Kompetenzfelder, die in unserem System durch Tags repräsentiert werden. Dabei wird einer Benutzerbewertung genau ein Tag zugeordnet, allerdings kann ein Tag zu keinem,
einem oder mehreren Benutzerbewertungen zugeordnet werden. Exakt wie bei den Dokumentbewertungen wird hiermit ermöglicht, dass
Bewertungen zu einem Benutzer unter unterschiedlichen Kompetenzfeldern (repräsentiert durch Tags) auch unterschiedlich sein können.
Abbildung 4.1 bildet das Datenmodell in der Krähenfussnotation2 ab.
2
Auch als Martin-Notation bekannt. Dabei werden die Kardinalitäten durch 0 (Null),
| (Eins) bzw. dem Krähenfuÿ (beliebig viele) gekennzeichnet. Bei jeder Beziehung stehen zwei Kardinalitäten hintereinander, die das minimale bzw. das maximale Auftreten
beschreiben.
24
Abbildung 4.1: Das Datenmodell in der Krähenfussnotation
4.2
Objektorientierter Entwurf
Das im vorangegangenen Kapitel erarbeitete Datenmodell stellt nun die
Grundlage für den objektorientierten Entwurf dar. Dabei unterscheiden wir
nachfolgend zwischen einem konzeptionellen Entwurf, der auf dem eben erwähnten Datenmodell sowie den in Abschnitt 3.1 denierten funktionalen
Anforderungen basiert, sowie einem implementierungsnahen Entwurf, der
den konzeptionellen Entwurf um Details der Implementierung erweitert. Die
Grundlage hierfür bilden die nichtfunktionalen Abhängigkeiten aus Abschnitt
3.2 sowie Einschränkungen durch die Zielplattform.
Die Entwürfe werden in einem Klassendiagramm nach UML2 Notation (OM07)
visualisiert. Da wir uns als bei der Zielsprache auf Java festgelegt haben, verwenden wir die dort unterstützten Datentypen für den Entwurf.
4.2.1
Konzeptioneller Entwurf
Ausgangspunkt für den konzeptionellen Entwurf stellt das Datenmodell dar.
Die Entitäten aus diesem wurden als Klassen übernommen. Die Attribute der
Entitäten wurden durch einen entsprechenden Datentyp der Programmiersprache Java ersetzt und den jeweiligen Klassen hinzugefügt. Beziehungen
werden im konzeptionellen Klassendiagramm als Assoziationen modelliert,
wobei deren Kardinalitäten durch die in UML verwendeten Multiplizitäten
ersetzt wurden. Ergänzt werden diese Assoziationen durch entsprechende
25
Rollennamen an den Enden.
Die Methoden der Klassen gehen dabei aus den funktionalen Anforderungen aus Abschnitt 3.1 hervor und sollen hier kurz vorgestellt werden. Dabei
verzichten wir auf die Beschreibung von get und set-Methoden, die lediglich private Attribute auslesen bzw. setzen. Konsequent werden die Klassen
UserRating und DocumentRating, welche keine weiteren Methoden beinhalten, nicht im Detail erläutert.
Methoden der Klasse UserManager
Die Klasse UserManager setzt die in Abschnitt 3.1.2 denierten Anwendungsfälle zur Benutzerverwaltung wie Registrierung sowie An- und Abmeldung
um. Die Klasse hat dabei keine Entsprechung im Datenmodell, da sie lediglich Funktionalität in Form von Methoden zur Verfügung stellt und eine
persistente Speicherung von Instanzen dieser Klasse nicht vorgesehen ist.
Deshalb wurden die Methoden von der Klasse User in unserem konzeptuellen Entwurf getrennt.
Die Methoden register, login sowie logout sind für die Registrierung respektive für die An- und Abmeldung zuständig. Bei der Registrierung notwendige Angaben sind der Benutzername, das gewünschte Password sowie
die E-Mailadresse. Die Methode invite wird dazu verwendet, noch nicht
registrierte Kontake von Benutzern einzuladen, sich der Kooperationsplattform anzuschlieÿen. Dazu muss der Name des einzuladenen Benutzers sowie dessen E-Mailadresse als Parameter an die Methode übergeben werden.
Zusätzlich muss auch noch eine Bewertung für den einzuladenen Benutzer
erstellt werden.
Sowohl bei der Registrierung als auch bei Einladung zur Kooperationsplattform muss der neue Benutzer sein Konto (und gegebenenfalls damit die Einladung selbst) durch den in der E-Mail angegebenen Link bestätigen, der einen
zum Zeitpunkt der Registrierung generierten Aktivierungscode enthält. Die
Methode activate bekommt den Aktivierungscode sowie den Benutzernamen als Parameter übergeben und prüft, ob der übergebene Aktivierungscode mit dem in der Datenbank gespeicherten Wert identisch ist. Ist das der
Fall wird das Konto aktiviert und der Benutzer mithilfe der Methode login
angemeldet.
26
Methoden der Klasse User
Instanzen der Klasse User stellen einen (im System registrierten) Benutzer
dar. Das Hinzufügen und Entfernen von Benutzerbewertungen (vgl. Anwendungsfälle in Abschnitt 3.1.3) wird von den Methoden rate sowie unrate
realisiert. Dabei werden diese Methoden auf dem zu bewertenden Benutzer
(User-Objekt) aufgerufen, wobei der gerade am System angemeldete Benutzer als bewertender Benutzer übergeben wird. Dabei wird der Methode rate
des weiteren neben der eigentlichen Bewertung noch das Kompetenzfeld in
Form eines Tags, unter dem der Benutzer bewertet wird, übergeben.
Die Methoden searchByTags sowie searchByDetails implementieren die in
Abschnitt 3.1.4 denierten Anwendungsfälle für die Suche von Benutzern.
Bei der Methode searchByTags wird dabei eine Menge von Tags angegeben, und die Benutzer zurückgegeben, die unter allen Tags bewertet wurden. Bei der Methode searchByDetails werden ein oder mehrere Details
der gesuchten Person übergeben, wobei ebenfalls nur die Personen ins Resultat übernommen werden, für die alle angegebenen Details erfüllt werden.
Sollen gewisse Details nicht berücksichtigt werden, müssen diese mit dem
Wert null übergeben werden. Wir modellieren diese Methoden als statisch,
da sie unabhängig von einem bestimmten Benutzer (Instanz ) sind, sondern
Funktionalität auf der Menge aller Benutzer darstellen.
Methoden der Klasse Document
Das Hinzufügen und Entfernen von Dokumentbewertungen funktioniert analog zu den Benutzerbewertungen. Es werden die gleichnamigen Methoden
rate und unrate sowie entsprechende Parameter verwendet.
Da Dokumente im Internet zu unterschiedlichen Zeitpunkten verschiedene
Inhalte haben können, Dokumentbewertungen sich aber auf den Moment
der Bewertungsabgabe beziehen, brauchen wir einen Mechanismus der eine
Momentaufnahme des Dokuments zu speichert. Eine komplette Kopie des
Dokuments wäre zwar die naheliegendste Lösung, ist aber aufgrund des Umfangs aktueller Internetinhalte nicht praktikabel. So speichern wir lediglich
einen Hashwert des Dokuments. Die Generierung dieses Hashwertes erfolgt
mittels der Methode hash, die das Ergebnis als Zeichenkette zurückliefert.
Bei der Bewertung eines Dokuments wird dieser Hashcode dann der Dokumentbewertung hinzugefügt.
Der statischen Methode getDocument wird eine URL als Parameter übergeben, die in unserem System ein Dokument eindeutig identiziert, und gibt
daraufhin, sofern vorhanden, das entsprechende Dokumentobjekt zurück.
27
Dies ist erforderlich, da viele Methoden ein Objekt der Klasse Document
erwarten, von dem die URL bekannt ist.
Die Methoden searchByTags sowie searchByUser implementieren die in Abschnitt 3.1.4 denierten Anwendungsfälle für die Suche von Dokumenten. Bei
der Methode searchByTags wird dabei eine Menge von Tags angegeben, wobei nur die Dokumente als Resultat zurückgeliefert werden, die mit allen
Tags annotiert sind. Bei der Methode searchByUser wird ein bestimmter
Benutzer übergeben und die von ihm bewerteten Dokumente zurückgeliefert. Wir modellieren diese Methoden als statisch, da sie unabhängig von
einem bestimmten Dokument (Instanz ) sind, sondern Funktionalität auf der
Menge aller Dokumente darstellen.
Methoden der Klasse Tag
Kompetenzfelder werden in unserem System durch Tags dargestellt, die wiederum durch die Klasse Tag repräsentiert werden.
Die statische Methode getTag, welche nicht mit der gleichnamigen Methode
ohne Parameter verwechselt werden darf, dient dazu, ein Tag welches im
System bereits vorhanden ist, zurückzugeben. Dazu wird der Methode die
Phrase des Tags als Parameter übergeben. Dies ist erforderlich, weil viele
Methoden Objekte vom Typ Tag statt der Zeichenkette selbst erwarten.
Die Methode getRelatedTags dient dazu Tags, welche mit dem aktuellen
Tag-Objekt verwandt sind, abzufragen. Details zu dieser Funktion werden in
Abschnitt 4.4.4 diskutiert. Generell gibt es Beziehungen zwischen Tags, und
diesen Umstand versuchen wir uns zunutze zu machen, indem wir ihn z.B. bei
der Suche nach Tags oder die Einbeziehung von Bewertungen ähnlicher bzw.
verwandter Kompetenzfelder in den Inferenzmechanismus, berücksichtigen.
4.2.2
Implementierungsnaher Entwurf
Aufbauend auf dem konzeptuellen Entwurf soll dieser nachfolgend um implementierungstechnische Aspekte verfeinert werden. Dabei werden Entwurfsmuster (Ga95) verwendet. Die Entwurfsentscheidungen, die bei der Verfeinerung zum implementierungsnahen Entwurf getroen wurden, sind u.a. stark
abhängig von den nichtfunktionalen Anforderungen (vgl. Abschnitt 3.2) beeinusst. Nachfolgend sollen diese Entscheidungen erläutert werden, wobei
zunächst auf die relevanten Teile des Klassendiagramms eingegangen wird,
und zum Schluss dieses Abschnitts die einzelnen Teile in einem Klassendiagramm integriert werden.
28
Abbildung 4.2: Konzeptionelles Klassendiagramm in UML Notation
Verwendung des Singleton Pattern für die Klasse UserManager
Die Klasse UserManager hat die Aufgabe, die Registrierung, An- und Abmeldung sowie die Einladung von Benutzern zu bearbeiten, ohne aber ihren
eigenen Zustand persistent zu speichern. Eine solche Hilfsklasse, die lediglich
Funktionalität zur Verfügung stellt, könnte man mit statischen Methoden
und Eigenschaften entwerfen.
Eine wesentlich elegantere Lösung wird von (Ga95) durch Einsatz des Singleton Design-Pattern vorgeschlagen. Dabei wird auf die Verwendung von statischen Methoden (mit einer Ausnahme) verzichtet, stattdessen wird sichergestellt, dass jederzeit (maximal) genau eine Instanz dieser Klasse existiert.
Zusätzlich wird ein globaler Zugangspunkt zu der Klasse (mit Hilfe einer
einzigen statischen Methode) angeboten.
In unserer Klasse UserManager nutzen wir das Singleton-Pattern wie folgt.
Wir denieren ein statisches Attribut instance vom Typ UserManager, welches eine Referenz auf das einzige UserManager-Objekt darstellt. Zugri auf
den UserManager erhalten wir durch die statische Methode getInstance,
welche den Wert des Klassenattributs instance zurückgibt. Sollte das
UserManager Objekt dabei nicht existieren, wird es zuvor erstellt und die
Referenz darauf im Attribut instance gespeichert. Um sicherzustellen, dass
keine weiteren Instanzen dieser Klasse erzeugt werden, wird der einzige Konstruktor (der Standardkonstruktor) als private deklariert. Abbildung 4.3
zeigt die Klasse UserManager.
29
Abbildung 4.3: Die verfeinerte Klasse UserManager
Austauschbarer Inferenzmechanismus durch das Strategy Pattern
In Abschnitt 3.2 haben wir mit NR03 die Anforderung nach einem exiblen
Objektentwurf formuliert, der unter anderem die Berücksichtigung der Austauschbarkeit des Inferenzmechanismus fordert. Dieser Anforderung soll hier
Rechnung getragen werden, indem wir eine weiteres Design Pattern nach
(Ga95) verwenden: das Strategy Pattern. Bei diesem Entwurfsmuster wird
eine Familie von Algorithmen austauschbar gemacht sowie die Realisierung
des Algorithmus vom Clients entkoppelt. In diesem Zusammenhang sei angemerkt, dass wir eine kleine Variation des Musters verwenden, indem wir
anstatt abstrakter Klassen Interfaces benutzen.
Realisiert wird dieses Pattern durch die Denition des Interfaces
DeductionStrategy, das eine Methode calculateRating deniert. Dieser
Methode wird neben dem Benutzer (User), der die Bewertung abfragen
will, das Dokument (Document) mitsamt Kompetenzfeld (Tag) übergeben,
für welches die Bewertung abgefragt werden soll. Der Rückgabe der Methode ist die Bewertung, die wie alle anderen Bewertungen in unserem System
als Flieÿkommazahl (Java Datentyp double) dargestellt wird. Jeder zu unserer Anwendung kompatible Inferenzmechanismus muss nun lediglich dieses Interface und somit die gerade beschriebene Methode calculateRating,
implementieren, wobei der interne Inferenzmechanismus beliebig realisiert
sein kann. Den von uns entwickelten Inferenzalgorihmus bezeichnen wir als
CompetenceDeductionStrategy. Er wird ausführlich in Abschnitt 4.3 beschrieben.
Zusätzlich wird die Klasse Document um ein statisches Attribut
deductionStrategy vom oben beschriebenen Interfacetyp DeductionStrategy
ergänzt, wobei alle Klassen erlaubt sind, die dieses Interface implementieren.
30
Abbildung 4.4: Anwendungs des Strategy Patterns auf den Inferenzmechanismus
Die Methode getRating der Klasse Document, die für die Abfrage von Dokumentbewertungen zuständig ist, ruft ihrerseits nun die Methode
; calculateRating auf dem Objekt3 deductionStrategy auf. Dabei wird
der gerade angemeldete Benutzer sowie das Dokument, auf welchem die
getRating-Methode aufgerufen wurde, übergeben. Durch einfaches Austauschen der Objektreferenz in deductionStrategy kann der Inferenzmechanismus somit ausgetauscht werden.
Abbildung 4.4 zeigt die Auswirkungen auf die Klasse Document sowie die
Erweiterung durch die neue Interfacedenition sowie unsere Implementierungsklasse namens CompetenceDeductionStrategy.
Erweiterung der Klasse Tag zur Unterstützung von Klassikationsbeziehungen
Der konzeptuelle Entwurf lässt sich hinsichtlich der möglichen Beziehungen
zwischen Kompetenzfeldern wie folgt verfeinern. Es können zwischen Kompetenzfeldern, bzw. deren Repräsentation als Tags, Beziehungen bestehen.
Beispielsweise bestehen Beziehungen zwischen Kompetenzfeldern, die Teilkompetenzen darstellen und somit anderen Kompetenzfeldern untergeordnet sind, also ein hierarchisches Klassikationssystem bilden. Ein anderes
Beispiel wäre, dass gewisse Kompetenzfelder in einer Ähnlichkeitsbeziehung
zueinander stehen, die lediglich aussagt, dass zwei Kompetenzfelder sich inhaltlich ähnlich sind. Diese Beziehungseigenschaften können dann sowohl bei
der Inferenz als auch bei der Suche von Dokumenten herangezogen werden.
So ist es bei der Inferenz einer Bewertung möglich, Subkompetenzfelder entsprechend mit zu betrachten.
3
Präziser gesagt wird das Objekt, auf welches die Referenz des Attributs
deductionStrategy zeigt, aufgerufen.
31
Abbildung 4.5: Erweiterung der Strukturbeziehungen bei Tags
Wir denieren zur allgemeinen Repräsentation von Beziehungen zwischen
Tags die abstrakte Klasse TagRelationship, die auf zwei Tags (TagA und
TagB) verweist und geschützte (protected) Attribute für den Namen der
Beziehung sowie ein Flag das angibt, ob es sich bei dem Beziehungstyp
um eine symmetrische Beziehung handelt, besitzt. Symmetrische Beziehungen sagen aus, dass wenn die Beziehung von TagA zu TagB gilt, dann gilt
diese Beziehung auch von TagB zu TagA. Die Ähnlichkeitsbeziehung ist ein
Beispiel für eine symmetrische Beziehung, wogegen hierarchische Beziehungen nicht symmetrisch sind. Um eigene Beziehungstypen zu erstellen genügt es, diese von der Klasse TagRelationship abzuleiten. So denieren
wir die Beziehungstypen ParentRelationship, ChildRelationship sowie
SimilarityRelationship, welcher noch ein zusätzliches Attribut
(similarityCoeff) hat, das den Grad der Ähnlichkeit zweier Tags angibt.
Der Algorithmus zur Auswertung von Beziehungen wird analog dem vorangegangenen Abschnitt mithilfe des Strategy Patterns entkoppelt. Abbildung
4.5 zeigt den für die Tags relevanten Ausschnitt des Klassendiagramms. Für
genauere Erläuterungen zur Funktionsweise der Klassikationsbeziehungen
von Tags sei auf Abschnitt 4.4 verwiesen, der dies detailiert beschreibt.
In diesem Zusammenhang sollte beachtet werden, dass eine Neuberechnung
der Beziehungen zwischen Tags bei jeder Anfrage einen erheblichen Aufwand generieren kann, vorallem in den nach NR02 der nichtfunktionalen
Anforderungen (vgl. Abschnitt 3.2) zeitkritischen Anwendungsfällen der Dokumentsuche sowie Inferenz. Mit der persistenten Speicherung der Beziehungen wären aber weitreichende Erweiterungen des Datenmodells verbunden.
32
Abbildung 4.6: Überblick des implementierungsnahen Klassendiagramms
Integration der besprochenen Konzepte
Abbildung 4.6 zeigt das implementierungsnahe Klassendiagramm, bei welchem die besprochenen Erweiterungen in das konzeptuelle Klassendiagramm
(vgl. Abbildung 4.2) integriert wurden.
4.3
Bewertungsinferenz
Die zentrale Komponente der Kooperationsplattform ist der Mechanismus
zur Inferenz von Bewertungen, welchem dieser Abschnitt gewidmet ist. Dabei werden wir zunächst Grundannahmen treen, wie sich unser Mechanismus verhalten soll. Diese Grundannahmen werden daraufhin in einem Kalkül
durch geeignete Regeln formalisiert. Abschlieÿend wird der von uns entworfene Inferenzmechanismus kritisch diskutiert sowie mögliche alternative Herangehensweisen vorgestellt.
4.3.1
Grundannahmen zur Bewertungsinferenz
Grundsätzlich soll es die Bewertungsinferenz ermöglichen, vertrauenswürdige
Aussagen über Dokumente zu erlangen, die der Benutzer nicht selbst bewertet hat. Dies geschieht über das soziale Netzwerk zu anderen Benutzern,
33
die ebenfalls wie Dokumente, unter bestimmten Kompetenzfeldern bewertet
werden, sowie deren Bewertungen für das angefragte Dokument.
Dabei basiert der von uns zu entwickelnde Inferenzmechanismus auf folgenden Annahmen, welche zur späteren Referenzierbarkeit eindeutig durchnummeriert wurden:
•
IN01
•
IN02
•
IN03
•
IN04 Dokument- und Benutzerbewertungen, die über einen kürzeren
Benutzer- und Dokumentbewertungen werden auf einer Ordinalskala von 1 bis 5 Sternen vergeben, wobei ein Stern für ein äuÿerst
schwache, positive Bewertung und fünf Sterne für eine äuÿerst starke,
positive Bewertung steht.
Existiert für das angefragte Dokument eine vom Benutzer erstellte Dokumentbewertung, wird diese direkt als Endbewertung der
Inferenz übernommen. Analog wird für mit dem Ausgangsbenutzer direkt benachbarten Benutzer die vorhandene Benutzerbewertung übernommen.
Dokumentbewertungen, die von Benutzern mit stärker positiver Bewertung stammen, sollen auch im Ergebnis entsprechend stärker
berücksichtigt werden.
Pfad von Benutzerknoten erreichbar sind, sollen stärker berücksichtigt
werden als Bewertungen, die über sehr lange Benutzerbewertungsketten erreichbar sind.
•
IN05
•
IN06 Sollte bei einer Dokumentbewertung der Hashwert des aktuellen
Kreise in den Bewertungsgraphen zwischen Benutzern dürfen
weder positive noch negative Auswirkungen auf die Endbewertung haben
Dokuments von dem Hashwert zum Zeitpunkt der Bewertungserstellung abweichen wird dem Benutzer der Hinweis gegeben, dass sich der
Dokumentinhalt möglicherweise geändert hat.
•
IN07
•
IN08 Sollte kein Pfad zwischen dem Ausgangsbenutzer und dem an-
Sollten Dokument- und Benutzerbewertungen ähnlicher Kompetenzfelder mithilfe der generierten Taxonomie (vgl. Abschnitt 4.4)
einbezogen werden, wird deren Einuss auf die Endbewertung reduziert, wobei der Grad der Reduktion vom Grad der Ähnlichkeit der
Kompetenzfelder abhängen sollte.
gefragten Dokument möglich sein, wird dem Benutzer mitgeteilt, dass
eine Bewertung für das vorliegende Dokument nicht möglich sei.
34
4.3.2
Ein einfacher Kalkül zur Bewertungsinferenz
Aufbauend auf den im vorherigen Abschnitt denierten Grundannahmen
sollen diese nun in einem Kalkül formalisiert werden. Dies geschieht schrittweise, wobei wir von einer Formalisierung der Ausgangssituation ausgehen
und über die Inferenz von Benutzerbewertungen auf die Inferenz der Dokumentbewertungen kommen. Dabei werden die im vorangegangenen Abschnitt
denierten Annahmen über das Verhalten des Inferenzmechanismus' an den
relevanten Stellen aufgegrien.
Grundlegende Denitionen
Zunächst sollen die grundsätzlichen Elemente unseres Kalküls vorgestellt
werden. Als Ausgangspunkt haben wir eine Menge von Benutzern U, eine
Menge von Tags T, eine Ordinalskala für Bewertungen, deren diskrete Wert
durch die Menge R mit totaler Ordnung repräsentiert werden, sowie eine
Menge an Dokumenten D.
Für Zwischenergebnisse in der Berechnung von gewichteten Durchschnittsbewertungen (z.B. nach IN03) verwenden wir Flieÿkommawerte, welche wir
durch die Menge R beschreiben. Für die Anzeige des Endergebnisses verwenden wir die Rundungsfunktion r : R → R, welche jedem Flieÿkommawert ihren gerundeten Wert auf der Ordinalskala zuordnet (IN01). Die Verwendung
der Menge R stellt dabei stärkere Anforderungen an die Skala der Bewertungen. Um das Kalkül jedoch einfach und anschaulich zu halten wird auf eine
komplexe, skalentreue Behandlung verzichtet.
Die Zuordnung von Tags zu Benutzerbewertungen stellt eine Teilmenge des
kartesischen Produkts aus dem bewertenden Benutzer der Menge U, dem
bewerteten Benutzer der Menge U sowie dem zugeordneten Tag der Menge
T dar:
EU ⊆ U × U × T
(4.1)
Analog dazu wird eine Zuordnung eines Tags der Menge T von einem Benutzer der Menge U zu einem Dokument der Menge D deniert:
ED ⊆ U × D × T
(4.2)
Die eigentliche Bewertung ist eine surjektive Funktion RU von EU auf Bewertungen R im Falle von Benutzerbewertungen, bzw. die (ebenfalls surjektive)
Funktion RD von ED auf Bewertungen R für Dokumentbewertungen:
RU : EU → R
35
(4.3)
RD : ED → R
(4.4)
Diese Denition als surjektive Funktionen gewährleistet, dass jede Zuordnung von Benutzern sowie Dokumenten zu Tags auch eine Bewertung beinhaltet. Ebenfalls wird durch die Modellierung als Funktion sichergestellt,
dass es zu jeder solchen Zuordnung maximal eine Bewertung gibt, oder anders ausgedrückt, dass man einen Benutzer bzw. ein Dokument unter einem
Kompetenzfeld nur mit einer Bewertung versehen kann.
Ziel unseres Inferenzkalküls ist es, eine (inferierte) Bewertungsfunktion vom
Benutzer u ∈ U unter dem Kompetenzfeld t ∈ T für das Dokument d ∈ D zu
schaen. Die Denition dieser Funktion lautet wie folgt:
RD : U × D × T → R
(4.5)
Dazu muss in einem vorherigen Schritt eine Bewertung für andere Benutzer
inferiert werden, welche sich analog denieren lässt:
RU : U × U × T → R
(4.6)
Der von uns gewählte Lösungsweg beruht darauf, ausgehend von einem Benutzer u, Bewertungen RU für andere Benutzer auf Grundlage abgegebener
Benutzerbewertungen zu inferieren. Die Bewertung RD für das angefragte
Dokument d wird dann aus Dokumentbewertungen von Benutzern, deren
Benutzerbewertungen wir im vorherigen Schritt berechnet haben, inferiert
und anschlieÿend auf R gerundet.
Bevor wir nun im Detail erläutern, wie wir diese Bewertungen inferieren,
befassen wir uns zunächst mit der Wahl eines geeigneten Kompetenzfeldes
t, unter dem die Inferenz geführt wird.
Wahl eines geeigneten Kompetenzfeldes
Bei der Wahl eines geeigneten Kompetenzfeldes sollen zwei Fälle unterschieden werden. Zum einen hat der Benutzer die Möglichkeit, das von ihm gewünschte Kompetenzfeld, unter welchem die Inferenz durchgeführt wird, direkt anzugeben. Zum anderen soll es ihm aber auch möglich sein, die Wahl
eines Kompetenzfeldes, welches auf das gesuchte Dokument d ∈ D geeignet
zutrit, durch die Kooperationsplattform durchführen zu lassen,
In diesem Fall wählen wir jenes Kompetenzfeld t, welches die meisten Dokumentbewertungen von Benutzern u0 ∈ U erhalten hat. Präziser ausge36
drück wählen wir jenes Kompetenzfeld t, welches unter der Voraussetzung
(u0 , d, t) ∈ ED für beliebigen Benutzer u0 ∈ U am häugsten in ED für das
angefragte Dokument d vorkommt. Sollte dies für kein Kompetenzfeld t ∈ T
möglich sein, so besteht keine Bewertung für das angefragte Dokument und
somit ist die Inferenz einer Bewertung für das angefragte Dokument nicht
möglich.
Berücksichtigung von Pfadlängen durch Sphären
Um die Kompetenzbeziehungen zwischen Benutzern in unserem Kompetenznetz besser erläutern zu können, denieren wir uns zunächst eine Hilfsfunktion EU (t) : T → P(U × U):
EU (t) = {(u1 , u2 ) | (u1 , u2 , t) ∈ EU }
(4.7)
Ausgehend davon beschreibt für ein beliebiges t ∈ T das Tupel (U, EU (t))
einen gerichteten Graphen, dessen Knoten durch RU mit Bewertungen versehen werden, die ein (positives) Maÿ für das Vertrauen in die Kompetenz
des entsprechenden Benutzers im Gebiet t darstellen.
Nun sollen nach IN04 die Anzahl der Stationen, oder eben die Pfadlänge
in oben genanntem Graphen, bei der Bewertungsinferenz mit berücksichtigt werden, weshalb wir das Konzept der Sphäre verwenden. Der Abstand
d(u, u0 ) zwischen zwei Benutzern ist dabei als die minimale Pfadlänge zwischen ihnen deniert. Dabei denieren wir den Abstand für Knoten, die unter
vom Ausgangsbenutzer u unter dem Kompetenzfeld t nicht erreichbar sind,
als ∞.
Um die in IN05 geforderte Kreisfreiheit der Bewertungen zu erreichen, legen
wir fest, dass für einen Benutzer mit Abstand n vom Startbenutzer nur Benutzerbewertungen geringerer Abstände, also < n, verwendet werden. Zum
Einen ergibt sich dadurch, dass für Benutzer des Radius n nur Bewertungen
von Benutzern des Radius n − 1 berücksichtigt werden müssen4 und somit
eine Gewichtung von Pfadlängen wegfällt, zum Anderen impliziert dies auch,
dass die geforderte Kreisfreiheit sichergestellt wird. Diese Denition wird in
der Diskussion in Abschnitt 4.3.3 nochmals aufgegrien.
Abbildung 4.7 veranschaulicht dieses Konzept, wobei die roten Kanten Benutzerbewertungen darstellen, die zwar im System vorhanden sein können,
4
Würden Benutzerbewertungen von Benutzern mit Abstand n0 ≤ n−2 vorliegen, würde
der Benutzer auf Radius n0 + 1 liegen, wobei n0 + 1 < n gilt.
37
Abbildung 4.7: Anwendung des Sphärenkonzepts auf das Kompetenznetzwerk
aber aus dem im vorherigen Abschnitt erläuterten Grund nicht berücksichtigt werden.
Um nun eine Reduzierung der Bewertungsstärke nach IN04 abhängig von
der Pfadlänge zu bewirken, wird entsprechemd dem Abstand eine Dämpungsfunktion angewendet. Diese berechnet den Dämpfungsfaktor g(n) abhängig
vom Abstand n zum Ausgangsbenutzer u. Wir haben dabei folgende Anforderungen an die Dämpfungsfunktion:
• Nach IN02 sollen Bewertungen, die vom anfragenden Benutzer u selbst
ausgehen, übernommen werden, ohne andere Bewertungen zu berücksichtigen. Eine Dämpfungsfunktion soll deshalb für einen Radius echt
kleiner Eins das Ergebnis 1 liefern, das ausdrückt, dass diese Bewertung
als einziges und damit in voller Stärke in das Endergebnis eingeht.
• Nach dem von (Mi67) vorgestellten Kleine-Welt-Phänomen kennt jede
Person jede andere über eine maximale Länge von 6 Kanten. Deshalb
sollen alle Bewertungen von Benutzern, die weiter als Radius 5 vom
Ursprungsbenutzer u entfernt sind, nicht in die Inferenz einbezogen
werden.
• Da die Aussagekraft von Bewertungen nach IN04 mit der Länge der
Kette singt, muss unsere Dämpfungsfunktion streng monoton fallend
sein.
In diesem Inferenzkalkül verwenden wir folgende Dämpfungsfunktion:
38
( 1,
g(n) =
2
2n ,
0,
für n < 1
für 1 ≤ n ≤ 5
für n > 5
(4.8)
Neben der Erfüllung der Anforderungen zeichnet sich unsere Dämpfungsfunktion durch eine stärkere negative Steigung5 im Vergleich zu einer linearen Dämpfungsfunktion aus, die mit zunehmendem Radius exponentiell
steigt. Auf unser Inferenzkalkül angewendet bedeutet dies, dass die engeren
Radien das Inferenzergebnis erheblich (exponentiell) stärker beeinussen als
die weiteren Radien. So hat eine Bewertung eines Benutzers mit Radius 1
eine vierfach( 223 ) so hohe Aussagekraft wie eine Bewertung eines Benutzers
mit Radius 3.
Inferenz von Benutzerbewertungen
Die in den vorhergehenden Abschnitten entwickelten Konzepte sollen zunächst auf die Inferenz von Benutzerbewertungen angewendet werden, welche die Voraussetzung für die spätere Inferenz der Dokumentbewertungen
darstellen.
In IN02 wird verlangt, dass die vom Ausgangsbenutzer u erstellte Werte
für alle direkt benachbarten Benutzer ohne weitere Anwendung von Inferenzberechnungen übernommen wird. Dies geschieht durch eine kanonische
Einbettung von RU in RU :
∀e ∈ EU : RU (u) = RU (e)
(4.9)
Für alle Benutzer, für die keine direkte Bewertung durch den Ausgangsbenutzer besteht d.h. ∀u0 : (u, u0 ) ∈
/ EU (t), berechnet sich die inferierten Benutzerbewertung aus dem arithmetischen Mittel der (inferierten) Benutzerbewertungen RU (u, v, t) der Vorgänger v und der Bewertung des Vorgängers
zum zu inferierenden Benutzer Ru (v, u0 , d):
0
v∈Uu0 ,d,t [RU (v, u , d)
P
RU
(u, u0 , t)
=
+ RU (u, v, t)]
2 | Uu0 ,d,t |
(4.10)
5
Die Steigung beträgt g 0 (n) = −2 log 0.5 · 0.5n , und somit werden für gröÿere Radien n
die Funktionswerte exponentiell kleiner. Die negative Steigung linearer Dämpfungsfunktionen ist dagegen konstant.
39
Abbildung 4.8: Allgemeine Struktur und Beispiel der Inferenz von Benutzerbewertungen
Abbildung 4.9: Beispiel für die Inferenz der Dokumentbewertung
mit Uu,u0 ,t = {v ∈ U | (v, u0 , t) ∈ Eu ∧ d(u, v) < d(u, u0 )}, die Menge alle Vorgänger des Benutzers u0 repräsentiert.
Abbildung 4.8 zeigt im rechten Teil die allgemeine Struktur der Benutzerbewertungen auf und veranschaulicht dies im linken Teil durch ein einfaches
Beispiel.
Inferenz von Dokumentbewertungen
Der nale Schritt des Inferenzkalküls befasst sich damit, die bereits inferierten Benutzerbewertungen RU vom Ausgangsbenutzer u mit den im System
vorhandenen Dokumentbewertungen RD geeignet zu kombinieren, so dass
eine möglichst aussagekräftige Bewertung RD über das Dokument d für den
Benutzer u inferiert wird.
Zunächst soll aber der triviale Fall betrachtet werden, dass der Ausgangsbenutzer das nachgefragte Dokument selbst bewertet hat. Dabei soll dann die
vom ihm erstellte Bewertung ohne Anwendung von Inferenzmechanismen,
wie in Anforderung IN02 beschrieben, übernommen werden. Dies wird analog der Inferenz von Benutzerbewertungen mittels einer kanonischen Einbet40
tung von RD in RD bewerkstelligt:
∀e ∈ ED : RD (e) = RD (e)
(4.11)
Der eigentliche Nutzen der Kooperationsplattform liegt aber darin, Dokumentbewertungen für nicht eigens bewertete Dokumente zu bekommen. Dazu
bilden wir wieder das arithmetische Mittel, müssen es allerdings entsprechend
den Anforderungen IN03 und IN04 gewichten, wobei wir zur Gewichtung
der Pfadlängen nach IN04 die Gewichtungsfunktion g(n) verwenden. Die
inferierte Bewertung für ein Dokument d unter einem Kompetenzfeld t von
einem Ausgangsbenutzer u ausgehend berechnet sich daher wie folgt:
P
RD (u, d, t) =
g(nu0 ) · RD (u0 , d, t) · RU (u, u0 , t)
P
0
v∈Ud,t g(nv ) · RU (u, u , t)
u0 ∈Ud,t
(4.12)
n
o
mit Ud,t = v ∈ U | (v, d, t) ∈ Ed ∧ RU (u, v, t) als die Menge der Benutzer,
für die eine Benutzerbewertung vorliegt (und somit vom Ausgangsbenutzer u
erreichbar ist) und die das Dokument d unter dem Kompetenzfeld t bewertet
haben.
Abbildung 4.9 soll dies veranschaulichen, indem das Beispiel aus dem vorherigen Abschnitt um die Dokumentbewertungen erweitert wird.
4.3.3
Diskussion der Bewertungsinferenz
Einleitend für die Diskussion der Bewertungsinferenz sei zu erwähnen, dass
es sicher keine triviale Aufgabe ist, das menschliche Verhalten bei der Bewertungsndung zu unbekannten Inhalten aufgrund von Aussagen anderer
abzubilden, zumal dies sicher auch von Mensch zu Mensch verschieden ist.
Deswegen sei auch darauf hingewiesen, dass die mit IN01-IN07 Annahmen
keinen Anspruch auf Vollständigkeit oder Universalität erheben, sondern lediglich als Ausgangspunkt für die prototypische Realisierung dienen. Deshalb wurde bereits im Abschnitt 3.2 mit der nichtfunktionalen Anforderung
NR03 Flexibler Objektentwurf festgelegt, dass sich dieser Inferenzmechanismus austauschen lassen soll.
Eines der Kernkonzepte des vorgestellten Kalküls ist die Nutzung von Spähren in Graphen. In diesem Zusammenhang wird auch festgelegt, dass Benutzerbewertungen lediglich von einem Radius tiefergelegenen Benutzern bewertet werden können. Natürlich stellt dies eine Vereinfachung dar, die neben
41
Abbildung 4.10: Das dargestellte Beispiel der Bewertungsinferenz für einen
Benutzer T soll mit Hilfe der Beschränkung auf kleinere Radien für Benutzerbewertungen verhindert werden.
dem Vorteil der Kreisfreiheit (siehe Anforderung IN05) vorallem deswegen
gewählt wurde, weil wir verhindern wollten, dass Benutzer höherer Entfernungen zum Ausgangsbenutzer die Bewertungen von Benutzern geringerer
Entfernungen beeinussen. Vorallem soll dabei der in Abbildung 4.10 abgebildete Fall vermieden werden, dass Benutzer höherer Radien die Bewertungen direkter Vorfahren beeinussen.
Die Verwendung des gewichteten arithmetischen Mittels bei der Inferenz von
Dokumentbewertungen kann in Zusammenspiel mit der von uns gewählten
Dämpfungsfunktion g(n) zu unerwarteten Ergebnissen führen. Dabei wird
für Dokumente, sofern die Benutzerbewertungen die in die Dokumentbewertungen eingehen allesamt von Benutzern der gleichen (oder allgemein zumindest naheliegenden) Radien stammen, die gleiche Bewertung generiert.
Dies folgt daraus, dass die Pfadlänge die Gewichtung lediglich im Hinblick zu
anderen Benutzern ändert. Dies würde sich durch die Einführung einer zweiten Bewertungsskala, der Bewertungsaussagekraft, vermeiden lassen, wovon
aber aufgrund der hohen zusätzlich entstehenden Komplexität im Verhältnis
zum Mehrwert für den Benutzer abgesehen wurde. Alternativ liese sich auch
eine subtraktive Dämpfung der Dokumentbewertungen mit zunehmendem
Abstand einführen.
Einen weiteren Diskussionspunkt stellt der vorgestellte Mechanismus zur
Auswahl des Kompetenzfeldes t dar, unter dem die Inferenz durchgeführt
wird. Dabei kann dieser unter gewissen Rahmenbedingungen kritisch sein.
Dies ist dann der Fall, wenn entweder zu einem Dokument d nur eine geringe Anzahl an Bewertungen vorliegt und somit die Menge ED entsprechend
gering ist, da die Wahrscheinlichkeit hier eine Inferenz unter einem darin
enthaltenen Tag t durchführen zu können ebenfalls gering ist.
Die Anforderung nach der Berücksichtigung verwandter Kompetenzfelder
(IN07) könnte den Inferenzmechanismus robuster machen, im Hinblick dar42
auf, dass sowohl für die eigentliche Bewertungsinferenz als auch die Wahl
eines geeigneten Kompetenzfeldes weniger Bewertungen benötigt würden.
Dies brächte vorallem in der Anfangsphase des Systems einen erheblichen
Mehrwert für die Benutzer. Allerdings sei hierbei auch auf Gefahren dieser Methode verwiesen. Zum einen würde eine weitere, maschinell schwer
quantizierbare Einuÿgröÿe die Akzeptanz beim Benutzern aufgrund der
zunehmenden Komplexität mindern. Zum anderen würde dies auch die Frage aufwerfen, in wie weit diese Klassikationsbeziehungen im Gegensatz zu
den anderen Einuÿgröÿen das Ergebnis beeinussen dürfen, so dass das
Endergebnis noch vertretbar ist.
4.4
Beziehungen zwischen Kompetenzfeldern
Dieser Abschnitt befasst sich mit der Repräsentation von Kompetenzfeldern
durch Tags sowie dem Aufbau einer Beziehungsstruktur. Dabei wird zuerst
die Verwendung von Tags als geeignete Darstellung begründet. Anschlieÿend
wird der Begri der Beziehungen zwischen Tags im Zusammenhang mit dem
hier zu entwickelnden System vorgestellt, einschlieÿlich der Vorstellung eines Verfahrens zur automatischen Generierung von Ähnlichkeitsbeziehungen
zwischen Tags. Weiterführende Konzepte, welche über den Rahmen dieser
Arbeit hinaus gehen, werden am Schluss dieses Abschnitts skizziert.
4.4.1
Repräsentation von Kompetenzfelder durch Tags
Die Abbildung von Kompetenzfeldern wird, wie bereits mehrfach erläutert,
in unserem System durch die Verwendung einzelner Wörter bzw. Phrasen,
sogenannter Tags, realisiert. Tags zeichnen sich dabei dadurch aus, dass sie
für Benutzer nicht vordeniert sind, sondern von ihnen frei gewählt werden
können. Obwohl sich dadurch Nachteile wie die Gefahr qualitativ minderwertiger6 oder gar schädlicher Tags ergeben, wird durch den Ansatz eine Reihe
von positiven Eekten erreicht, wie von (Se07) skizziert. Dazu zählt, dass
Tagsysteme sehr gut skalieren, die Einbeziehung der Benutzer deren Partizpationswillen steigert sowie der Pegeaufwand minimal gehalten wird oder
im optimalen Fall komplett wegfällt.
Generell sind wir der Meinung, dass die Vorteile der Verwendung von Tags
überwiegen, vorallem unter Berücksichtigung dass Nachteile wie qualitativ
minderwertiger Tags sich durch Anwendung wissenschaftlicher Forschungsresultate, wie von (Se07) skizziert, minimieren lassen.
6
Bei der in (Se07) erforschten Onlinecommunity wurden 21% der Tags als nicht anzeigewürdig eingestuft
43
4.4.2
Beziehungen zwischen Tags
Da sich Tags als Kompetenzfeldrepräsentation sowohl direkt auf die Benutzerals auch auf die Dokumentbewertungen beziehen, sowie bei der Suche nach
Dokumenten verwendet werden, sind sie für das zu realisierende System von
zentraler Bedeutung. In der Realität sind aber nicht alle Kompetenzfelder
bzw. Tags voneinander unabhängig, sondern es können vielfältige Beziehungen zwischen ihnen bestehen. Beispielsweise können Tags in hierarchischer Beziehung zueinander stehen. Weitere Beispiele sind die SynonymieBeziehung (Tags beziehen sich auf das selbe Konzept) oder die Ähnlichkeitsbeziehung (Tags beziehen sich auf ähnliche Konzepte).
Sowohl bei der Inferenz von Bewertungen als auch bei der Abfrage von Dokumenten können diese Beziehungen zwischen Tags vorteilhaft genutzt werden.
So kann durch sie die Inferenz auf verwandte Tags ausweitet werden, um für
eine gröÿere Menge von Zielobjekten Aussagen treen zu können. Dies führt
besonders im Anfangsstadium einer solchen Plattform mit anfangs wenigen
Bewertungen zu einer Vielzahl von Dokumenten im Internet zu besseren Resultaten. Ebenfalls könnte die Einbeziehung von Beziehungen zwischen Tags
die Anzahl der Suchergebnisse bei einer Dokumentsuche nach Tags erhöhen.
Dabei wählen wir für diese Arbeit den Ansatz der Folksonomy (Ma04), eine Wortneubildung aus Folk und Taxonomy. Im Gegensatz zu traditionellen
Ansätzen, die von einem verwalteten Vokubalar mit einer fest vorgegebenen Taxonomie ausgehen, nutzt dieser Ansatz die Möglichkeiten, Metadaten
durch die Community, genauer gesagt deren Annotation von Objekten mit
Tags, zu gewinnen, woraus dann bottom-up ein Beziehungsgeecht generiert
werden kann.
Nachfolgend soll zunächst gezeigt werden, wie sich auf Basis von mit Tags
annotierten Objekten ein Ähnlichkeitsgraph konstruieren lässt, aus dem sich
Ähnlichkeitsbeziehungen zwischen Tags ablesen lassen. Darauf aufbauend
wird das Verfahren von (HGM06) erläutert, welches aus dem Ähnlichkeitsgraphen eine hierarchische Folksonomie ableiten kann.
4.4.3
Berechnung der Ähnlichkeit zwischen Tags
Die folgenden Ausführungen basieren auf Ähnlichkeitsbeziehungen zwischen
Tags. Diese Ähnlichkeitsbeziehungen, wenngleich weniger aussagekräftig wie
beispielsweise hierarchische Beziehungen, unterliegen dem praktischen Vorteil, dass sie durch einfache Analyse automatisch generiert werden können.
Dabei wurden durch empirische Studien (HGM06) deren praktischer Nutzen
aufgezeigt.
44
Für unsere Generierung von Ähnlichkeitsbeziehungen gehen wir davon aus,
dass wir allgemein Objekte (o1 , o2 , . . . ∈ O) haben, die im vorliegenden Fall
Benutzer oder Dokumente sind. Diese werden von Benutzern (u1 , u2 , . . . ∈ U)
mit Tags (t1 , t2 . . . ∈ T) versehen.
Die Ähnlichkeitsbeziehungen zwischen Tags wird dabei durch einen ungerichteten Graphen G, den Ähnlichkeitsgraphen (engl. similarity graph ), dargestellt, wobei Tags dessen Knoten und Ähnlichkeitsbeziehungen zwischen
Tag-Paaren dessen Kanten darstellen. Dabei werden nur die Ähnlichkeitsbeziehungen zwischen Tags als Kanten in den Graph übernommen, deren
Ähnlichkeitsmaÿ über einem bestimmten Grenzwert, dem SimilarityThreshold thsimilarity , liegen.
Entscheidend für die Ermittlung der Ähnlichkeit ist somit die Wahl eines
geeigneten Maÿes. Dabei bietet sich das Kosinus-Ähnlichkeitsmaÿ (cosine
similarity ) an, welches häug zum Vergleich der Ähnlichkeiten von zwei Dokumenten verwendet wird (vgl. (SB87)). Dazu aggregieren wir unsere Tags
in Tag-Vektoren, wobei vtl [om ] angibt, wie oft das Objekt om mit dem Tag
tl versehen wurde. Das Kosinus-Ähnlichkeitsmaÿ zweier Vektoren A und B
ist deniert als7 :
Θ = arccos
A·B
|A| · |B|
(4.13)
Das Ergebnis ist der Winkel zwischen den beiden Vektoren im Bereich [0; π],
wobei der Winkel π2 ausdrückt, dass keinerlei Ähnlichkeit besteht. Umgekehrt bedeutet ein Winkel 0 respektive π maximale Ähnlichkeit (absolute
Gleichheit).
Require: similarity threshold thsimilarity ; function for cosine similarity calculation cosSim
V ← ∅; E ← ∅
f o r a l l t ∈ T do
V ← V ∩ {t}
f o r a l l u ∈ T \ {t} do
i f cosSim ( vt , vu ) ∈/ ]thsimilarity ; π − thsimilarity [
E ← E ∩ {( t , u)}
then
end i f
end f o r a l l
end f o r a l l
Listing 4.1: Algorithmus zur Generierung des Ähnlichkeitsgraphen
7
A · B stellt dabei das Skalarprodukt der Vektoren A und B dar
45
Abbildung 4.11: Generierung des Ähnlichkeitsgraphen auf Grundlage des
Kosinus Ähnlichkeitsmaÿes mit einem Grenzwert thsimilarity von 0.70.
Der in Listing 4.1 skizzierte Algorithmus generiert ausgehend von einer Funktion cosSim zur Berechnung des Kosinus-Ähnlichkeitsmaÿes nach 4.13 sowie
dem Ähnlichkeitsgrenzwert thsimilarity den Ähnlichkeitsgraph G(V, E). Die
Laufzeit liegt dabei in Θ(|T|2 ), wobei an dieser Stelle darauf hingewiesen sei,
dass dabei keinerlei Optimierungen angewendet wurden. Neben den Kanten kann der Algorithmus optional noch erweitert werden, um das Ergebnis
von cosSim noch als Ähnlichkeitskoezient gespeichert werden kann, wie im
Klassendiagramm in Abbildung 4.5 bereits angedeutet wurde.
Das Verfahren wird dabei in Abbildung 4.11 mit einem verwendeteten Grenzwert thsimilarity von 0.70 dargestellt. Die Werte der Ergebnisse der cosine
similarity sind dabei im linken Teil eingetragen, wobei die roten Kanten unter dem Grenzwert liegen und deshalb aus dem Ähnlichkeitsgraphen (rechts)
entfernt wurden.
4.4.4
Automatische Erstellung hierarchischer Beziehungen
Das im vorherigen Abschnitt dargestellte Verfahren lässt sich erweitern, um
auf Grundlage der Ähnlichkeit zwischen Tag-Paaren hierarische Beziehungen
zu generieren, wie in (HGM06) dargestellt.
Hierfür wird das graphentheoretische Konzept der Zentralität eines Knotens
(vertex centrality ) verwendet, welches ein Maÿ für die relative Bedeutung
eines Knoten in einem Graphen G(E, V ) darstellt.
Dabei gibt es verschiedene Denitionen von Zentralität. Der auf dem Grad
des Knotens basierende Zentralitätbegri (degree centrality ) gibt an, wieviele
Kanten zum Knoten inzidieren. Der Vorteil dieser Methode ist, dass diese
46
eine einfache und ezient Berechnung ermöglich, wobei die Laufzeit bei einer
geeigneten Repräsentation des Graphen in Θ(|E|) liegt.
Der bei der Netzwerkanalyse präferierte Begri der Zentralität bezieht sich
aber auf den durchschnittlichen Abstand eines Knotens zu allen anderen
Knoten, die sogennante closeness centrality. Dabei wird das arithmetische
Mittel aus der Distanz zwischen einem Knoten v und allen anderen Knoten
des Graphen V \ {v} berechnet:
P
c(v) =
t∈V \{v} dG (v, t)
n−1
(4.14)
Dabei bezeichnet n den von v erreichbaren Teilgraphen von G, so dass n =
|V | gilt, sofern der Graph zusammenhängend ist. Der Wert dG bezeichnet
die Distanz zwischen zwei Knoten im Graphen G. Je kleiner der Wert von
c(v) für einen Knoten v ∈ V ausfällt, desto höher dessen Zentralität.8
Der Algorithmus in Listing 4.2 zur Generierung eines hierarchischen Beziehungsgeechts erfordert eine Liste aller Tags t0 , . . . , tn ∈ T, sortiert nach
ihrer Zentralität. Zunächst wird der Graph G, der das Ergebnis in Form
eines hierarchischen Beziehungsbaums darstellt, mit einem Wurzel-Element
root und einer leeren Menge (∅) an Kanten initalisiert. Danach wird aus
der sortierten Liste der erste, d.h. der zentralste verbleibende Tag ausgelesen und mit allen anderen Knoten, die sich momentan in G benden,
verglichen. Dabei wird mit Hilfe der Funktion sinCos das ähnlichste Tag,
das sog. Kandidaten-Tag (maxCandidate), sowie dessen Ähnlichkeitsgrad
(maxCandidateVal) ermittelt. Dieser wird dann mit einem Grenzwert thtaxonomy 9
verglichen, der bestimmt, wann ein Tag dem Kandidaten-Tag oder direkt der
Wurzel untergeordnet wird.
Die Laufzeit des Algorithmus selber liegt in Θ(|T|2 ), allerdings ist die genaue Berechnung der Zentralität zeitaufwendig. Es gibt jedoch eziente Approximationen zur schnellen Berechnung der Zentralität, wie in (Br01) und
(EW01) beschrieben.
In diesem Zusammenhang muss aber auch darauf hingewiesen werden, dass
dieser Algorithmus einige Grundannahmen über die Beschaenheit der Tags
macht. Zum einen gehen (HGM06) davon aus, dass die hierarchischen Beziehungen bereits in den Kanten des Ähnlichkeitsgraphen (vgl. Abschnitt 4.4.3)
vorhanden sind. Andererseits existieren im Ähnlichkeitsgraphen Kanten, die
8
Hierbei sei darauf hingewiesen, dass in manchen Fällen auch der Kehrwert 1/c(v)
verwendet wird. Dies ist aber für die vorliegende Arbeit ausdrücklich nicht der Fall.
9
(HGM06) haben dabei gute Ergebnisse mit einem thtaxonomy Grenzwert von 0.099,
weshalb dieser an der Stelle empfohlen werden soll.
47
G ← h r o o t , ∅i
for i = 1 . . . | Lcentrality | do
ti ← Lcentrality [i]
maxCandidateVal ← 0
f o r a l l tj ∈ g e t V e r t i c e s ( G ) do
i f cosSim ( ti , tj ) > maxCandidateVal
maxCandidateVal ← s ( ti , tj )
maxCandidate ← tj
end i f
end f o r a l l
i f maxCandidateVal
> thtaxonomy
G ← G ∪ hmaxCandidate, ti i
else
G ← G ∪ hroot, ti i
then
then
end i f
end f o r a l l
Listing 4.2: Algorithmus zur automatischen Generierung eines hierarchischen
Beziehungsbaums
Abbildung 4.12: Generierung eines hierarchischen Beziehungsbaums (rechts)
aus dem Ähnlichkeitsgraphen (links).
48
keine Bedeutung in der zugrundeliegenden Hierarchie haben. Diese werden
als Störkanten (noisy connections ) bezeichnet wird. Ohne diese Annahmen
wäre allerdings keine Hierarchiebildung auf Basis des Ähnlichkeitsgraphen
möglich, und die Resulte in der Praxis scheinen diese Methode zu bestätigen
(HGM06).
Eine Anwendung des Verfahrens wird in Abbildung 4.12 dargestellt. Dabei ist
links der Ähnlichkeitsgraph als Ausgangspunkt abgebildet, woraus der rechts
dargestellte Beziehungsbaum erstellt wird. Dabei sieht man, wie die zentralen
Knoten in der Hierarchie höher eingeordnet werden sowie die Störkanten
(noisy edges ) wegfallen.
4.4.5
Diskussion und weiterführende Konzepte
Auch wenn der im vorherigen Absatz beschriebene Ansatz sehr vielversprechend aussehen mag, so muss an dieser Stelle auf einige mit ihm verbundene
Probleme eingegangen werden. Zwar wurden die Ergebnisse bei groÿen Webseiten bestätigt, allerdings sind dabei gewisse Kennzahlen zu beachten. Dazu
zählt neben der Dichte (engl. density ),
Annotierte Objekte
Objekte
(4.15)
die beschreibt wie häug Benutzer Objekte mit Tags annotieren, sowie die
Überlappung (engl. overlap ),
Gemeinsam annotierte Objekte
Annotierte Objekte
(4.16)
die beschreibt wie häug Benutzer Objekte annotieren, die bereits von anderen annotiert wurden.
Dabei haben die Ergebnisse aus der Praxis gezeigt (HGM06), dass die automatische Generierung hierarchischer Beziehungen auf Grundlage des Ähnlichkeitsgraphes stark von einer hohen Dichte und einer hohen Überlappung
protiert. Da eine Bewertung eines Dokuments immer auch eine Annotation einschlieÿt, sollte der Wert für die Dichte nicht zu niedrig ausfallen10 .
Aufgrund der Tatsache, dass es eine praktisch unbegrenzte Anzahl an Dokumenten im Internet gibt, könnte jedoch für den Groÿteil der bewerteten
Dokumente die Überlappung äuÿerst niedrig sein.
10
Zumindest aber ist die Dichte zu jeder Zeit ≥ 1.0, da eine Bewertung immer auch eine
Annotation einschlieÿt
49
Vorallem in der Anfangsphase des Kompetenznetzes könnte aufgrund der
geringen Anwendbarkeit der vorgestellten Methode für eingeschränkte Nutzbarkeit sorgen. Angesichts dieser Tatsache sollte man überlegen, ob nicht
die Beschränkung auf den Ähnlichkeitsgraphen gewählt werden sollte, oder
sogar (zumindest anfangs) auf die Verwendung von benutzerdenierten Tags
zugunsten eines vorgegebenen, von Experten gepegtem Vokabular, dem sog.
library Ansatz, verzichtet werden sollte. Die Vorteile der Verbesserungen von
Ergebnissen bei geringer Anzahl von Benutzern, einer einheitlichen (und optimalerweise fehlerfreien), Hierarchie sowie geringem Rechenaufwand würden
jedoch einige Nachteile gegenüberstehen. So skalieren diese Expertensysteme
schlecht mit der Anzahl der Benutzer. Darüber hinaus hemmt das vordenierte Vokabular die Partizipation der Mitglieder, was dem Wachstum der
Community ebenfalls entgegenwirken kann.
Deshalb empfehlen wir trotz bekannter Schwächen die Verwendung von Tags,
da unserer Meinung nach deren Vorteile überwiegen. In diesem Zusammenhang sollte auch auf das Problem von qualitativ minderwertigen Tags wie
Spam, Beleidigungen, etc. eingegangen werden. Dabei lässt sich dieses Problem durch eine Erweiterung der von uns vorgestellten Ansätze verringern,
wie von (Se07) beschrieben. Dabei werden dem Benutzer die Möglichkeit gegeben, Tags als positiv oder negativ (mit Hilfe kleiner Icons) zu bewerten.
Durch die Auswertung dieser Daten wird dann ermöglicht, zu entscheiden,
welche Tags qualitativ hochwertiger sind.
50
Kapitel 5
Implementierung
Die prototypische Implementierung der Kooperationsplattform soll deren
Machbarkeit in der Praxis aufzeigen. Dazu wurden wichtige Lösungsbestandteile mittels der objektorientierten Programmiersprache Java realisiert. Zunächst wird dabei auf die Realisierung des Algorithmus' zur Inferenz von
Bewertungen eingegangen. Anschlieÿend wird die Implementierung der automatischen Erstellung der Ähnlichkeitsbeziehung für Kompetenzfelder erläutert. Das Kapitel schlieÿt mit einer kurzen Erläuterung, wie die Benutzerschnittstelle mittels der Plattform Toro realisiert werden kann.
Das Vorgehen bei der Implementierung des Inferenzalgorithmus und der automatischen Beziehungserstellung ist ähnlich. Zunächst werden die verwendeten Datenstrukturen vorgestellt und deren Implementierung in Java skizziert. Darauf aufbauend wird die Implementierung der Algorithmen anhand
des Quelltextes erläutert.
Die Realisierung der Benutzerschnittstelle mittels der Plattform hebt sich
von den anderen Abschnitten insofern ab, als dass hier nicht genauer auf
einzelne Implementierungsdetails eingeht, sondern vielmehr versucht, einen
Überblick über die Implementierung der Benutzerschnittstelle mittels der
Plattform Toro zu geben. Eine genauere Abhandlung zu diesem Thema würde den Rahmen dieser Arbeit sprengen.
5.1
Entwurf und Implementierung des Inferenzalgorithmus
Ziel der Inferenz ist es, aus den im System vorhandenen Benutzer- und Dokumentbewertungen Aussagen für nicht eigens bewertete Dokumente zu ge51
winnen. Dazu haben wir in Abschnitt 4.3 Grundannahmen an einen solchen
Algorithmus formuliert und diese anschlieÿend in einem Kalkül formalisiert.
Darauf aufbauend werden nun geeignete Datenstrukturen gewählt, anhand
derer der Kalkül in einem Algorithmus umgesetzt wird.
5.1.1
Verwendete Datenstrukturen
Bei dem von uns vorgestellten Verfahren operieren wir auf einem Graphen,
wobei es allerdings zwei Arten von Knoten, Benutzerknoten und Dokumentknoten, gibt. Wir verzichten an dieser Stelle auf die expliziete Repräsentation
des vollständigen Graphen. Dieser wäre lediglich für dessen Darstellung erforderlich, für die eigentliche Inferenz reichen lokale Knoten jedoch aus. Dabei
muss angemerkt werden, dass für eine Berechnung der Benutzerbewertungen dessen direkte Vorgänger bekannt sein müssen, weshalb eine implizite
Speicherung der Kanten des Benutzergraphen erzwungen wird.
Die Benutzerknoten werden als eigene Klasse UserNode implementiert, die als
wesentliche Bestandteile neben dem Benutzer, auf den sie sich beziehen, eine Liste mit Vorgängern enthält, die ebenfalls Objekte der Klasse UserNote
sind, bei denen aber zusätzlich eine Benutzerbewertung (userRating) und eine
Kantenbewertung (edgeRating) angegeben werden müssen. Neben Methoden
zum Hinzufügen eines Vorgängers oder Abrufen der Liste alle Vorgänger
überschreibt die Klasse die Methode equals, die wahr ist, wenn die beiden
Benutzer, auf die sich das UserNote Objekt bezieht, identisch sind. Die Implementierung zeigt Listing 5.1.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
public c l a s s UserNode {
private User u ;
public double u s e r R a t i n g ;
public double ed ge Ra ti ng ;
// r e c u r s i v e d e f i n i t i o n o f p r e d e c e s s o r s
private L i s t <UserNode> pred ;
public UserNode ( User u ) {
this . u = u ;
this . pred = new A r r a y L i s t <UserNode >() ;
}
public void a d d P r e d e s s e c o r ( User u , double predRating , double
15
16
17
18
19
}
userRating ) {
UserNode un = new UserNode ( u ) ;
un . u s e r R a t i n g = p redR ati ng ;
un . edg eR at in g = u s e r R a t i n g ;
this . pred . add ( un ) ;
52
20
public L i s t <UserNode> g e t A l l P r e d e s s e c o r s ( ) {
return pred ;
21
22
}
23
24
public User g e t U s e r ( ) {
return this . u ;
25
26
}
27
28
public boolean e q u a l s ( Object o ) {
i f ( o instanceof UserNode ) {
return ( ( UserNode ) o ) . g e t U s e r ( ) . e q u a l s ( this . g e t U s e r ( ) ) ;
29
30
31
}
32
33
34
35
}
}
return f a l s e ;
Listing 5.1: Datenstruktur zur Repräsentation von Benutzerknoten
Die Klasse DocumentNode repräsentiert Dokumentbewertungen. Attribute sind
der bewertungsabgebende Benutzer, dessen Abstand zum Startbenutzer und
seine Benutzerbewertung sowie die abgegebene Dokumentbewewertung. Listing 5.2 zeigt deren Implementierung.
1
public c l a s s DocumentNode {
User u s e r ;
2
double u s e r R a t i n g ;
double docRating ;
int r a d i u s ;
3
4
5
6
public DocumentNode ( User u , double ur , double dr , int r ) {
this . u s e r = u ;
this . u s e r R a t i n g = ur ;
this . docRating = dr ;
this . r a d i u s = r ;
7
8
9
10
11
12
13
}
}
Listing 5.2: Datenstruktur zur Repräsentation von Dokumentknoten
5.1.2
Implementierung in Java
Die Implementierung der Bewertungsinferenz orientiert sich eng an dem in
Abschnitt 4.3 vorgestellten Kalkül. Listing 5.3 zeigt, wie dieser implementiert
wurde.
1
public c l a s s CompetenceDeductionStrategy implements
DeductionStrategy {
2
53
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
private f i n a l int MAX_RADIUS = 6 ;
private Tag t a g ;
public double g e t R a t i n g ( User u , Document d , Tag t ) {
// g e t d e f a u l t competence f i e l d i f none s p e c i f i e d
this . t a g = ( t == null ) ? this . g e t D e f a u l t C o m p e t e n c e F i e l d ( u , d
) : t;
// check f o r d i r e c t document r a t i n g
i f ( u . getDocuments ( ) . c o n t a i n s ( d ) ) {
for ( DocumentRating r : d . g e t R a t i n g s ( ) )
{
i f ( r . g e t U s e r ( ) . e q u a l s ( u ) && r . getTag ( ) . e q u a l s ( this . t a g ) )
return r . g e t R a t i n g ( ) ;
}
}
// b r e a d t h f i r s t s e a r c h on u s e r s
L i s t <UserNode> curQueue = new A r r a y L i s t <UserNode >() ;
L i s t <UserNode> u s e r V i s i t e d = new A r r a y L i s t <UserNode >() ;
L i s t <DocumentNode> docNotes = new A r r a y L i s t <DocumentNode >() ;
curQueue . add ( new UserNode ( u ) ) ;
for ( int n = 0 ; n < MAX_RADIUS; n++) {
L i s t <UserNode> nextQueue = new A r r a y L i s t <UserNode >() ;
for ( UserNode curNote : curQueue ) {
// i g n o r e a l r e a d y expanded nodes ( IN05 )
i f ( u s e r V i s i t e d . c o n t a i n s ( curNote ) )
continue ;
double r_user = curNote . g e t U s e r ( ) . e q u a l s ( u ) ? 5 . 0 :
d e d u c t U s e r R a t i n g ( curNote ) ;
L i s t <Document> user_docs = curNote . g e t U s e r ( ) .
getDocuments ( ) ;
// e x t r a c t document r a t i n g s from u s e r graph
i f ( user_docs . c o n t a i n s ( d ) ) {
for ( DocumentRating dr : user_docs . g e t ( user_docs .
indexOf ( d ) ) . g e t R a t i n g s ( ) ) {
i f ( dr . g e t U s e r ( ) . e q u a l s ( curNote . g e t U s e r ( ) ) && dr .
getTag ( ) . e q u a l s ( this . t a g ) ) {
docNotes . add ( new DocumentNode ( curNote . g e t U s e r ( ) ,
r_user , dr . g e t R a t i n g ( ) , n ) ) ;
}
}
}
for ( UserRating r : curNote . g e t U s e r ( ) . g e t U s e r R a t i n g s ( ) ) {
// add c u r r e n t node a s p r e d e c e s s o r s f o r s u b s e q u e n t
nodes
i f ( r . getTag ( ) . e q u a l s ( this . t a g ) ) {
UserNode n o t e = new UserNode ( r . g e t U s e r _ r a t e d ( ) ) ;
int i = nextQueue . indexOf ( n o t e ) ;
i f ( i >= 0 ) {
n o t e = nextQueue . g e t ( i ) ;
n o t e . a d d P r e d e s s e c o r ( curNote . g e t U s e r ( ) , r_user , r .
54
getRating () ) ;
} else {
n o t e . a d d P r e d e s s e c o r ( curNote . g e t U s e r ( ) , r_user , r .
getRating () ) ;
nextQueue . add ( n o t e ) ;
}
50
51
52
53
}
}
u s e r V i s i t e d . add ( curNote ) ;
54
55
56
}
curQueue = nextQueue ;
57
58
59
60
61
62
63
64
}
private double d e d u c t U s e r R a t i n g ( UserNode u ) {
L i s t <UserNode> pred = u . g e t A l l P r e d e s s e c o r s ( ) ;
65
double r = 0 . 0 ;
for ( UserNode p : pred ) {
66
67
68
}
69
70
71
72
73
74
75
}
// r e t u r n ( round ) i n f e r r e d r a t i n g based on e x t r a c t e d
document nodes
return r ( deductDocumentRating ( docNotes ) ) ;
}
return ( r / 2 ∗ pred . s i z e ( ) ) ;
private double deductDocumentRating ( L i s t <DocumentNode> dn ) {
double n = 0 . 0 , d = 0 . 0 ;
for ( DocumentNode doc : dn ) {
76
77
}
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
r += p . u s e r R a t i n g + p . e dge Ra ti ng ;
}
n += ( g ( doc . r a d i u s ) ∗ doc . u s e r R a t i n g ∗ doc . docRating ) ;
d += ( g ( doc . r a d i u s ) ∗ doc . u s e r R a t i n g ) ;
return ( n/d ) ;
private double g ( int n ) {
i f ( 1 <= n && n <= 5 )
return ( 2 / Math . pow ( 2 . 0 , n ) ) ;
return 0 . 0 ;
}
private int r ( double r ) {
return ( int ) Math . round ( r ) ;
}
private Tag g e t D e f a u l t C o m p e t e n c e F i e l d ( User u , Document d ) {
Map<Tag , I n t e g e r > c = new HashMap<Tag , I n t e g e r >() ;
int max = 0 , v a l u e = 0 ;
Tag t_max = null ;
for ( DocumentRating dr : d . g e t R a t i n g s ( ) ) {
i f ( c . c o n t a i n s K e y ( dr . getTag ( ) ) ) {
v a l u e = c . g e t ( dr . getTag ( ) ) + 1 ;
} else {
value = 1;
55
101
102
103
104
105
106
}
107
108
}
109
110
112
113
return t_max ;
public Tag getTag ( ) {
return this . t a g ;
111
114
}
c . put ( dr . getTag ( ) , v a l u e ) ;
i f ( v a l u e > max) {
max = v a l u e ;
t_max = dr . getTag ( ) ;
}
}
}
Listing 5.3: Implementierung des Algorthmus zur Bewertungsinferenz
Die Hauptmethode des Algorithmus stellt dabei getRating dar, welche als
Parameter den Ausgangsbenutzer u, das abgefragte Dokument d sowie das
Kompetenzfeld t, welches optional vom Algorthmus (Z. 9) gewählt werden
kann, bekommt. Dazu wird zunächst (Z. 11-18) geprüft, ob eine unmittelbare
Dokumentbewertung für den Ausgangsbenutzer vorliegt und diese gegebenenfalls zurückgegeben.
Sollte keine direkte Bewertung verfügbar sein muss eine Bewertung inferiert
werden. Dazu starten wir eine Breitensuche1 (Z. 20), die bis zu einem denierten maximalen Radius MAX_RADIUS unserer Sphäre (vgl. Abschnitt 4.3)
arbeitet.
Dabei wird während jeder Iteration zunächst die Benutzerbewertung für den
gerade betrachteten Benutzer curUser mittels der Methode deductUserRating
(vgl. Z. 64) nach Formel 4.10 inferiert (Z. 32). Danach wird überprüft, ob
dieser Benutzer für das gesuchte Dokument d eine Bewertung abgegeben hat
(Z. 35-41). Ist dies der Fall, so wird diese zusammen mit dem bewerteten
Benutzer, der inferierten Benutzerbewertung und dem aktuellen Abstand in
einem DocumentNode Objekt gespeichert (Z. 38). Zum Ende jeder Iteration
(Z. 42-55) werden die Nachfolger des Benutzers durch UserNode Objekte repräsentiert, wobei der aktuelle Benutzerknoten als Vorgänger hinzugefügt
wird.
Mittels
der ermittelten DocumentNode Objekte und der Methode
deductDocumentRating (Z. 73), die die Formel 4.12 implementiert, wird die
inferierte Dokumentbewertung zurückgeliefert.
1
Wie beispielsweise in (Co01) erläutert.
56
5.2
Implementierung der automatischen Beziehungsgenerierung zwischen Tags
Ein weiterer wichtiger Lösungsbestandteil der Implementierung stellt die automatische Generierung eines Beziehungsgeechts zwischen Tags dar. Dabei
soll, wie in Abschnitt 4.4.3 beschrieben, aus den im System vorhandenen
Tags mithilfe des Algorithmus 4.1 ein Ähnlichkeitsgraph erstellt werden, in
dem Ähnlichkeitsbeziehungen zwischen Paaren von Tags ablesbar sind.
Dazu werden zunächst die dafür verwendeten Datenstrukturen mitsamt ihrer Implementierung vorgestellt. Anschlieÿend wird auf diesen der gerade
erwähnte Algorthmus mittels Java realisiert.
5.2.1
Verwendete Datenstrukturen
Zu Repräsentation des Ähnlichkeitsgraphen verwenden wir eine Datenstruktur für einen Graph, der über eine Art objektorientierte Implementierung
der Adjazenzlisten nach (St07) darstellt.
Dazu denieren wir zunächst eine Klasse Vertex, die Knoten unseres Graphen darstellt. Dieser Knoten hat dabei eine Liste adjacencyList, welche zu
ihm benachbarte Knoten beinhaltet. Neben den trivialen Operationen wie
Hinzufügen von Nachbarknoten oder Abrufen dieser überschreiben wir die
Methode equals der Basisklasse Object, die unsere Knoten zueinander vergleichbar machen soll, wobei zwei Knoten identisch sind, sofern sie gleiche
Namen haben. Listing 5.4 zeigt die Implementierung:
1
2
3
4
5
6
7
8
9
public c l a s s Vertex {
private S t r i n g name = "" ;
// L i s t o f d i r e c t n e i g h b o r s r e a c h a b l e from t h i s v e r t e x
private L i s t <Vertex> a d j a c e n c y L i s t = new A r r a y L i s t <Vertex >() ;
public boolean e q u a l s ( Object o b j ) {
i f ( o b j instanceof Vertex ) {
return ( ( Vertex ) o b j ) . name . e q u a l s ( this . name ) ;
}
10
11
12
13
14
15
16
17
18
}
return f a l s e ;
public S t r i n g getName ( ) {
return name ;
}
public void setName ( S t r i n g name ) {
57
19
}
20
21
public void addAdjacentVertex ( Vertex v ) {
22
23
}
24
25
27
29
a d j a c e n c y L i s t . add ( v ) ;
public L i s t <Vertex> g e t A d j a c e n t V e r t i c e s ( ) {
return a d j a c e n c y L i s t ;
26
28
this . name = name ;
}
}
Listing 5.4: Datenstruktur
Ähnlichkeitsgraphen
zur
Repräsentation
von
Knoten
des
Der Ähnlichkeitsgraph wird mittels der Klasse Graph repräsentiert, der die
erwartete Funktionalität in Form von Hinzufügen und Abrufen von Knoten
und Kanten bereitstellt. Das Entfernen von Knoten oder Kanten wurde nicht
berücksichtigt, da es in unserem Algorithmus nicht verwendet wird. Listing
5.5 zeigt die Implementierung:
1
2
3
public c l a s s Graph {
private boolean d i r e c t e d = f a l s e ;
private Set<Vertex> V = new HashSet<Vertex >() ;
4
5
6
7
8
9
public Vertex g e t V e r t e x ( S t r i n g name ) {
for ( Vertex v : this .V) {
i f ( v . getName ( ) . e q u a l s ( name ) ) {
return v ;
10
}
11
12
13
14
15
}
17
18
19
20
21
23
24
25
}
27
28
30
Vertex v = g e t V e r t e x ( name ) ;
i f ( v == null ) {
v = new Vertex ( ) ;
v . setName ( name ) ;
}
V. add ( v ) ;
return v ;
public void addEdge ( Vertex a , Vertex b ) {
26
29
return null ;
public Vertex addVertex ( S t r i n g name ) {
16
22
}
}
a . addAdjacentVertex ( b ) ;
if (! directed ) {
b . addAdjacentVertex ( a ) ;
}
58
31
public L i s t <Vertex> g e t A d j a c e n t V e r t i c e s ( Vertex v ) {
return v . g e t A d j a c e n t V e r t i c e s ( ) ;
32
33
}
34
35
public boolean i s D i r e c t e d ( ) {
return d i r e c t e d ;
36
37
}
38
39
public void s e t D i r e c t e d ( boolean d i r e c t e d ) {
this . d i r e c t e d = d i r e c t e d ;
40
41
42
43
}
}
Listing 5.5: Datenstruktur zur Repräsentation des Ähnlichkeitsgraphen
5.2.2
Implementierung in Java
Die im vorangegangenen Abschnitt vorgestellten Datenstrukturen stellen zusammen mit dem in Abschnitt 4.4.3 vorgestellten Algorithmus zur Konstruktion des Ähnlichkeitsgraphen die Grundlage für dessen Implementierung dar.
Listing 5.6 zeigt dessen Realisierung:
1
2
3
4
5
6
7
8
9
10
11
public c l a s s S i m i l a r i t y S t r a t e g y implements
TagRelationshipStrategy {
private Graph s i m i l a r i t y G r a p h = new Graph ( ) ;
private double t h _ s i m i l a r i t y = 0 . 8 ;
public S i m i l a r i t y S t r a t e g y ( ) {
}
public S i m i l a r i t y R e l a t i o n s h i p [ ] g e t R e l a t e d T a g s ( Tag t ) {
L i s t <S i m i l a r i t y R e l a t i o n s h i p > t r s = new A r r a y L i s t <
12
13
14
15
16
17
18
19
20
21
s i m i l a r i t y G r a p h . s e t D i r e c t e d ( true ) ;
}
S i m i l a r i t y R e l a t i o n s h i p >() ;
buildSimiliartyGraph () ;
for ( Vertex v : s i m i l a r i t y G r a p h . g e t A d j a c e n t V e r t i c e s (
s i m i l a r i t y G r a p h . g e t V e r t e x ( t . getTag ( ) ) ) ) {
t r s . add ( new S i m i l a r i t y R e l a t i o n s h i p ( t , Tag . getTag ( v . getName
() ) , 0.0) ) ;
}
S i m i l a r i t y R e l a t i o n s h i p [ ] t r s _ a r r a y = new
SimilarityRelationship [ trs . size () ] ;
t r s . toArray ( t r s _ a r r a y ) ;
return t r s _ a r r a y ;
private void b u i l d S i m i l i a r t y G r a p h ( ) {
59
L i s t <Tag> t a g s = Tag . g e t A l l T a g s ( ) ;
22
for ( Tag t : t a g s ) {
23
24
25
26
27
28
29
30
31
32
33
}
34
35
}
private L i s t <I n t e g e r > b u i l d T a g V e c t o r ( Tag a ) {
L i s t <I n t e g e r > v_a = new A r r a y L i s t <I n t e g e r >() ;
for ( Document d : Document . getAllDocuments ( ) ) {
int count = 0 ;
for ( DocumentRating r : d . g e t R a t i n g s ( ) ) {
i f ( r . getTag ( ) . e q u a l s ( a ) ) {
36
37
38
39
40
41
42
}
43
44
45
}
46
47
}
48
49
}
v_a . add ( new I n t e g e r ( count ) ) ;
return v_a ;
I t e r a t o r <I n t e g e r > i_A = A. i t e r a t o r ( ) ;
I t e r a t o r <I n t e g e r > i_B = B . i t e r a t o r ( ) ;
while ( i_A . hasNext ( ) ) {
double a = i_A . next ( ) . doubleValue ( ) ;
double b = i_B . next ( ) . doubleValue ( ) ;
sumA += a ∗ a ;
sumB += b ∗ b ;
AB += a ∗ b ;
}
double magnA = Math . s q r t (sumA) ;
double magnB = Math . s q r t (sumB) ;
52
53
54
55
56
57
58
59
60
61
62
63
64
66
count++;
private double cosSim ( L i s t <I n t e g e r > A, L i s t <I n t e g e r > B) {
double AB = 0 . 0 , sumA = 0 . 0 , sumB = 0 . 0 ;
50
51
65
Vertex v = s i m i l a r i t y G r a p h . addVertex ( t . getTag ( ) ) ;
for ( Tag u : t a g s ) {
double cosSim = cosSim ( b u i l d T a g V e c t o r ( t ) , b u i l d T a g V e c t o r
(u) ) ;
i f ( ! t . e q u a l s ( u ) && ( cosSim <= t h _ s i m i l a r i t y | | cosSim
>= Math . PI − t h _ s i m i l a r i t y ) ) {
Vertex s = s i m i l a r i t y G r a p h . addVertex ( u . getTag ( ) ) ;
// Add edge ( t , u ) t o graph
s i m i l a r i t y G r a p h . addEdge ( v , s ) ;
}
}
}
}
return Math . a c o s (AB / (magnA ∗ magnB) ) ;
Listing 5.6: Datenstruktur zur Repräsentation von Dokumentknoten
Die Methode getRelatedTags (Z. 10) stellt den Einsprungspunkt für die Generierung des Beziehungsgeechts dar, die durch das Interface TagRelationshipStrategy
festgelegt ist.
60
Darin wird zunächst der Ähnlichkeitsgraph mittels der Methode buildSimilarityGraph
(Z. 21) konstruiert. Dabei wird über alle vorhandene Tags iteriert (Z. 23)
und jeweils dem Graphen, sofern noch nicht vorhanden, hinzugefügt (Z. 24).
Anschlieÿend wird in einer inneren Schleife (Z. 25) wieder über alle Tags
iteriert, um aus diesen Tag-Vektoren (Z. 26) zu konstruieren und anschlieÿend deren Ähnlichkeit mittels dem Kosinus-Ähnlichkeitsmaÿes (Z. 26-27) zu
vergleichen. Sollte dabei das Ähnlichkeitsmaÿ in einem Bereich, der durch
th_similarity deniert wird, liegen, so wird das Tag der inneren Schleife (sofern noch nicht vorhanden) (Z. 28) sowie eine Kante zwischen diesem Tag
und dem der äuÿeren Schleife (Z. 30) dem Graphen hinzugefügt.
5.3
Implementierung der Benutzerschnittstelle als
Webanwendung
Zur Realisierung der Benutzerschnittstelle als Webanwendung verwenden
wir, wie in NR04 Technologische Basis (vgl. Abschnitt 3.2) beschrieben,
Java Enterprise Edition (Java EE) Technologie. Dabei richten wir uns nach
dem Model/View/Controller (MVC) Architekturmuster (KP88). Die Datenbasis, also das Model, wird durch objektrelationales Mapping mittels Entity
Beans implementiert, und die Präsentation (View ) durch Java Server Pages
realisiert. Die Verbindung zwischen diesen beiden Teilen (Controller ) wird
mittels Servlets realisiert.
Um einen Überblick über die Realisierung als Webanwendung zu bekommen, soll nachfolgend der Anwendungsfall UC06 Dokumentbewertung abfragen beispielhaft für die Anwendungsfälle der Kooperationsplattform vorgestellt werden. Ausgangspunkt ist dabei die in Abbildung 5.1 dargestellte
HTML-Benutzerschnittstelle, bei der ein (angemeldeter) Benutzer neben der
obligatorischen Angabe des abzufragenden Dokuments (URL) auch optional
ein Kompetenzfeld in Form eines Tags in einem Formular eingibt.
Beim Abschicken dieser Anfrage wird auf dem Web- und Anwendungsserver
ein unter der Zieladresse des Formulars registriertes Servlet, im vorliegenden
Fall QueryRatingServlet, aufgerufen. Da die Daten an den Webserver per
POST Methode des HTTP Protokolls (BLFF) übertragen werden, muss die
Methode doPost der Basisklasse HttpServlet überschrieben werden. Darin
werden zunächst Validierungen auf den Eingabedaten durchgeführt. Sollten
dabei Fehler auftreten wird die Anfrage mit einer Fehlermeldung an das Formular mittels RequestDispatcher Objekt zurückgeleitet. Ansonsten wird
mit Hilfe des in Abschnitt 5.1 erläuterten Inferenzalgorithmus eine Bewertung für das angefragte Dokument ermittelt und an eine Java Server Page
zur Anzeige der Resultate weitergeleitet. Listing 5.7 zeigt die Implementie61
Abbildung 5.1: Benutzerschnittstelle zur Abfrage von Dokumentbewewertungen
62
rung des Servlets:
1
2
3
4
5
6
public c l a s s Q u e r y R a t i n g S e r v l e t extends H t t p S e r v l e t {
@PersistenceContext
private EntityManager em ;
protected void doPost ( H t t p S e r v l e t R e q u e s t req ,
HttpServletResponse resp )
throws S e r v l e t E x c e p t i o n , IOException {
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
L i s t <S t r i n g > f a u l t s = new A r r a y L i s t <S t r i n g >() ;
L i s t <S t r i n g > w a r n i n g s = new A r r a y L i s t <S t r i n g >() ;
User u = User . g e t U s e r ( UserManager . g e t I n s t a n c e ( ) .
getCurrentUserName ( r e q ) ) ;
i f ( u == null ) {
f a u l t s . add ( new S t r i n g ( " P o l l i n g document r a t i n g s r e q u i r e s
logon " ) ) ;
}
Document d = Document . getDocument ( ( S t r i n g ) r e q . getP arameter (
" url ") ) ;
i f ( d == null ) {
f a u l t s . add ( new S t r i n g ( "The r e q u e s t e d document has not been
rated yet " ) ) ;
}
Tag t = Tag . getTag ( ( S t r i n g ) r e q . getPara meter ( " t a g " ) ) ;
i f ( t == null && ! ( r e q . getParamete r ( " t a g " ) . e q u a l s ( "" ) ) ) {
// u s e r e x p l i c i t l y s t a t e d d e s i r e d t a g s , but no r a t i n g s
exist
w a r n i n g s . add ( new S t r i n g ( "No r a t i n g s f o r t h e d e s i r e d t a g
a v a i l a b l e . Most p o p u l a r t a g used i n s t e a d . " ) ) ;
}
i f ( f a u l t s . s i z e ( ) > 0) {
29
30
31
32
33
34
35
36
37
38
39
40
}
req . setAttribute ( " f a u l t s " , f a u l t s ) ;
r e q . g e t R e q u e s t D i s p a t c h e r ( " q u e r y _ r a t i n g . j s p " ) . f o r w a r d ( req ,
resp ) ;
// i n f e r document r a t i n g u s i n g t h e
CompetenceDeductionStrategy
D e d u c t i o n S t r a t e g y ds = new CompetenceDeductionStrategy ( ) ;
Document . s e t D e d u c t i o n S t r a t e g y ( ds ) ;
double r = d . g e t R a t i n g ( u , d , t ) ;
Set<Document> r e s u l t = new HashSet<Document >() ; r e s u l t . add ( d
);
Map<Document , Double> r a t i n g s = new HashMap<Document , Double
>() ; r a t i n g s . put ( d , r ) ;
Map<Document , Tag> t a g s = new HashMap<Document , Tag>() ; t a g s
63
. put ( d , ( ( CompetenceDeductionStrategy ) ds ) . getTag ( ) ) ;
41
42
43
44
45
46
47
48
49
}
}
// s e t a t t r i b u t e s and f o r w a r d t o s p e c i f i e d j s p
req . setAttribute ( " r e s u l t " , r e s u l t ) ;
req . setAttribute ( " r a t i n g s " , r a t i n g s ) ;
req . setAttribute ( " tags " , tags ) ;
req . s e t A t t r i b u t e ( " warnings " , warnings ) ;
r e q . g e t R e q u e s t D i s p a t c h e r ( " document_result . j s p " ) . f o r w a r d ( req ,
resp ) ;
Listing 5.7: Die Implementierung der Anfragebearbeitung in einem Servlet
Die Anzeige der Ergebnisse erfolgt wie erwähnt mittels der Java Server Pages. Diese bestehen im Grunde aus HTML-Markup, in dem Java Code eingebettet werden kann. Die Implementierung der in Abbildung 5.2 dargestellten
Ausgabe der Abfrageergebnisse zeigt Listing 5.8:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<%@ page import=" de . tum . s e b i s . competenceWeb . e n t i t i e s . ∗ " %>
<%@ page import=" j a v a . u t i l . ∗ " %>
<%
Set<Document> r e s u l t = ( S e t<Document>) r e q u e s t . g e t A t t r i b u t e ( "
result ") ;
Map<Document , Double> r a t i n g s = (Map<Document , Double>)
request . getAttribute (" ratings ") ;
Map<Document , Tag> t a g s = (Map<Document , Tag>) r e q u e s t .
getAttribute (" tags ") ;
boolean a = true ;
%>
<html>
<head>
< t i t l e >CompetenceWeb</ t i t l e >
<meta http −e q u i v=" c o n t e n t −type " content=" t e x t / html ; c h a r s e t=
i s o −8859 −1" />
< link r e l =" s t y l e s h e e t " type=" t e x t / c s s " href="main . c s s ">
</ head>
<body>
< !−− HEADER −−>
<%@ i n c l u d e f i l e =" h e a d e r . j s p f " %>
< !−− CONTENT −−>
<table c l a s s=" content_frame " align=" c e n t e r " style=" h e i g h t : 600
px ; ">< tr><td>
<div style=" c l e a r : both ; v e r t i c a l − a l i g n : top ; ">
<h1>S e a r c h R e s u l t s</ h1>
<%
// P r i n t w a r n i n g s i f p r e s e n t
i f ( r e q u e s t . g e t A t t r i b u t e ( " w a r n i n g s " ) != null ) {
64
out . p r i n t ( "<t a b l e width=\"90%\" c e l l p a d d i n g =\" 5\ " a l i g n
=\" center \ " c l a s s =\" warning \ ">" ) ;
for ( String w : ( L i s t <String>) r e q u e s t . g e t A t t r i b u t e ( "
warnings " ) ) {
out . p r i n t ( "<t r ><td><b>Warning</b>: " + w + "</td></t r >
") ;
}
out . p r i n t ( "</t a b l e >" ) ;
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
}
%>
<table width="90%" align=" c e n t e r " cellpadding=" 4 "
cellspacing=" 0">
< tr><td colspan=" 4 " c l a s s="td_h2">Document S e a r c h R e s u l t (<
%= r e s u l t . s i z e ( ) %> Documents found )</ td></ tr>
< tr style=" background − c o l o r : #dddddd ; "><td><b>Document URL</
b></ td><td><b>Rating</b></ td><td><b>Tag used</b></ td><td>
<b>Action</ b></ td></ tr>
<% for ( Document r : r e s u l t ) { %>
<% i f ( a ) out . p r i n t ( "<t r >" ) ; else out . p r i n t ( "<t r s t y l e =\"
background−color : #e e e e e e ; \ ">" ) ; a = ! a ; %>
<%= "<td>" + r . g e t U r l ( ) + "</td>" %>
<%
out . p r i n t ( "<td>" ) ;
i f ( r a t i n g s . g e t ( r ) < 1 . 0 ) out . p r i n t ( "None" ) ;
else i f ( r a t i n g s . g e t ( r ) < 1 . 5 ) out . p r i n t ( "<img s r c =\"
img / r a t i n g 1 . g i f \ " />" ) ;
else i f ( r a t i n g s . g e t ( r ) < 2 . 5 ) out . p r i n t ( "<img s r c =\"
img / r a t i n g 2 . g i f \ " />" ) ;
else i f ( r a t i n g s . g e t ( r ) < 3 . 5 ) out . p r i n t ( "<img s r c =\"
img / r a t i n g 3 . g i f \ " />" ) ;
else i f ( r a t i n g s . g e t ( r ) < 4 . 5 ) out . p r i n t ( "<img s r c =\"
img / r a t i n g 4 . g i f \ " />" ) ;
else i f ( r a t i n g s . g e t ( r ) < 5 . 5 ) out . p r i n t ( "<img s r c =\"
img / r a t i n g 5 . g i f \ " />" ) ;
out . p r i n t ( "</td>" ) ;
i f ( r a t i n g s . g e t ( r ) < 1 . 0 ) out . p r i n t ( "<td>n/a</td>" ) ;
else
out . p r i n t ( "<td>" + t a g s . g e t ( r ) . getTag ( ) + "
</td>" ) ;
%>
<%= "</td>"
+ "<td><a h r e f =\" h t t p : // " + r . g e t U r l ( ) + "\" t a r g e t =\"
new\"> V i s i t </a> | <a h r e f =\" r a t e . j s p ? u r l =" + r . g e t U r l
( ) + "\">Rate</a></td >"
+ "</t r >" %>
<% } %>
</ table>
<br /><br />
</ div>
</ td></ tr></ table>
< !−− FOOTER −−>
<%@ i n c l u d e f i l e =" f o o t e r . j s p f " %>
</ body>
65
Abbildung 5.2: Benutzerschnittstelle zur Anzeige von Suchergebnissen samt
Bewertungsinferenz
66
</ html>
Listing 5.8: Java Server Page (JSP) zur Anzeige der Abfrageresultate
Die Implementierung der weiteren Anwendungsfälle der Kooperationsplattform verläuft dem hier vorgestellten Beispiel ähnlich. Eine ausführliche Darstellung dieser würde den Rahmen dieser Arbeit allerdings sprengen.
66
Kapitel 6
Zusammenfassung und
Ausblick
Zum Abschluss dieser Arbeit sollen zunächst deren wesentlichen Inhalte zusammengefasst werden, um darauf aufbauend Ausblicke auf weiterführende
Aspekte zu geben.
In Kapitel 2 haben wir verwandte Systeme aus den Bereichen Social Network,
Social Bookmarking und der Bewertungsbilung für Internetinhalte kurz vor-
gestellt. Dabei wurde auch aufgezeigt, inwiefern die in dieser Arbeits zu entwickelnde Kooperationsplattform über eine Nachbildung bekannter Systeme
hinausgeht und einen Mehrwert für Benutzer darstellt.
Die Anforderungen an diese Kooperationsplattform wurden in Kapitel 3 erhoben. Dabei wurden zunächst anhand von Anwendungsfalldiagrammen die
funktionalen Anforderungen dargestellt, wobei hier eine erste Einteilung von
Anwendungsfällen in Pakete vorgenommen wurde. Kapitel 3 schloss mit der
Erhebung der nichtfunktionalen Anforderungen ab.
Zu Beginn von Kapitel 4 wurde das unserer Arbeit zugrundeliegende Datenmodell deniert. Darauf aufbauend wurde anschlieÿend ein objektorientierter
Entwurf erstellt. Dabei wurde zunächst ein konzeptionelles Klassendiagramm
enwickelt, welches in einem nachfolgenden Schritt um Entwurfsentscheidungen durch Design Patterns verfeinert wurde. Im zweiten Teil des Kapitels
4 wurden dann die Lösungsbausteine Inferenzmechanismus sowie Klassikationsbeziehungen zwischen Tags detailierter erläutert. Bei ersterem wurden
aufbauend auf allgemeinen Anforderungen an einen Inferenzmechanismus
ein einfacher Kalkül für einen solchen erstellt, welcher anschlieÿend kritisch
disktutiert wurde. Nach einer kurzen Einführung in die Kompetenzfeldrepräsentation mittels Tags wurde dann auf den Mehrwert durch die Verwendung
67
von Beziehungen zwischen Tags hingewiesen. Daraufhin wurde ein Verfahren
vorgestellt, um Ähnlichkeitsbeziehungen zwischen Tags sowie darauf aufbauend hierarchische Beziehungen automatisch zu generieren.
Kapitel 5 hat die prototypische Implementierung von Kernkomponenten des
Kompetenznetzsystems detailierter beschrieben. Dabei wurden die verwendeten Datenstrukturen, die Realisierung des Inferenzmechanismus sowie das
Verfahren zur Bestimmung von Ähnlichkeitsbeziehungen zwischen Tags beschrieben. Darüber hinaus wurde kurz aufgezeigt, wie die Benutzerschnittstelle als Webanwendung umgesetzt werden kann.
6.1
Ausblick
Neben den in der Arbeit diskutierten Aspekten der Kooperationsplattform
existiert noch eine Vielzahl interessanter Überlegungen. welche in der Folge
angesprochen werden sollen. Dieser Ausblick soll dabei zum einen dem interessierten Leser helfen, diese Arbeit in Beziehung zu anderen Arbeiten und
somit auch in einen Gesamtkontext einzuordnen, liefert zum anderen aber
auch Ansatzpunkte für weiterführende Arbeiten zu diesem Themenbereich.
Von zentraler Bedeutung für den Erfolg der reputationsbasierten Kooperationsplattform ist die Schaung einer groÿen Community. Eng damit verbunden ist der in der Betriebswirtschaftslehre geprägte Begri der positiven
Netzeekte (vgl. (PRW03)). Dieser besagt, dass durch jeden weiteren Netzteilnehmer sich der Wert des gesamten Netzes und somit auch der Nutzen
für alle bisherigen Teilnehmer steigt. Dies tritt in der von uns beschriebenen Kooperationsplattform besonders stark auf, da durch die Einschränkung
von Bewertungen auf Kompetenzfelder die Aussagekraft zwar zunimmt, der
Suchraum der Inferenzanfragen aber zum Teil erheblich eingeschränkt wird,
und somit nach dem von uns vorgestellten Inferenzmechanismuis eine hohe
Anzahl von Bewertungen nicht nur die Qualität der inferierten Bewertung
erhöht, sondern in vielen Fällen erst ermöglicht.
Eine der möglichen Maÿnahmen zur Erhöhung der Attraktivität der Plattform wäre die Einbeziehungen mehrerer Strategien bei der Denition von
Beziehungen zwischen Kompetenzfeldern. So würde es sich, wie in Abschnitt
4.4.4 skizziert, anbieten, zu unterschiedlichen Verbreitungsstadien der Plattform unterschiedliche Herangehensweisen zu berücksichtigen. In der Anlaufphase würde sich ein von Experten verwaltetes, überschaubares Vokabular
mit Kompetenzfeldern und deren Beziehungen untereinander anbieten, um
potentiellen Mitgliedern den Einstieg zu erleichtern und die Anzahl der Inhalte, für die eine Bewertung möglich ist, zu erhöhen. Mit zunehmender
Anzahl der Mitglieder sollte dann allerdings der Übergang zu einer Folkso68
nomy (Ma04), wie beispielsweise in Abschnitt 4.4.4 vorgestellt, vollzogen
werden, um die Einbindung der existierenden Benutzer zu erhöhen und somit das Wachstum der Community weiter voranzutreiben. Dabei sollten die
angedachten Lösungen auf Benutzerfreundlichkeit und Zweckmäÿigkeit geprüft werden, so wie der entsprechende Übergangszeitpunkt entsprechend
sorgfältig gewählt werden, um ein optimales Wachstum zu erreichen.
Die in dieser Arbeit vorgestellte prototypische Realisierung von Kernkomponenten muss für einen praxisdienlichen Einsatz noch unter den Gesichtspunkten der Benutzerfreundlichkeit (Usability ) sowie der Leistungsfähigkeit
(Performance ) untersucht werden. Zum einen sollte, wie beispielsweise in
(Pa03) beschrieben, die Benutzerfreundlichkeit analysiert und die Kooperationsplattform darauf optimiert werden. Zum anderen sollte Transparenz
über die im Hintergrund ablaufenden Prozesse der Bewertungsbildung dem
Benutzer anschaulich vermittelt werden. Unter dem Gesichtspunkt der Leistungsfähigkeit sei nochmals auf die nichtfunktionalen Anforderungen verwiesen (siehe NR02 Antwortzeiten, Abschnitt 3.2), für die Optimierungen
an der in dieser Arbeit vorgestellten prototypischen Implementierung nötig
werden könnten. Zum einen bieten sich hierfür Caching -Verfahren (IC97),
vor allem für die Abfrage von Dokumentenbewertungen und Generierung
der Klassikationsbeziehungen zwischen Tags, an, da diese in einem System
mit einer hohen Anzahl von Benutzern in (relativ) kurzen Zeitintervallen
nicht allzu groÿen Schwankungen unterliegen sollten. Zum anderen würde
sich die Untersuchung der häug verwendeten Algorithmen auf Optimierbarkeit empfehlen.
Einen weiteren zu untersuchenden Aspekt stellen der im Abschnitt 4.3 aufgezeigte Inferenzkalkül und die ihm zu Grunde liegenden Annahmen dar.
Hier jedoch sehen wir kaum Möglichkeiten Fortschritte theoretisch zu erzielen. Vielmehr könnten hier empirische Methoden zum Einsatz kommen.
Aufgrund der Tatsache, dass die Abbildung von Bewertungsableitung zum
einen eine äuÿerst komplexe Aufgabe ist, die zum anderen von Mensch zu
Mensch auch noch unterschiedlich als rational angesehen wird, erhebt diese
Arbeit nicht den Anspruch, den optimalen Ansatz gefunden zu haben. Vielmehr wird hier ein relativ einfacher Kalkül vorgestellt, auf dem aufbauend
erst durch die wissenschaftliche Anwendung von Ergebnissen des praktischen
Einsatzes dieser Kooperationsplattform die Güte des Kalküls feststellbar und
somit verbesserbar ist. Dies wird durch die vorgestellte exible Softwarearchitektur geeignet unterstützt.
Diese Arbeit gibt also eine Art Einführung in das spannende Thema der reputationsbasierten Plattform zur netzwerkbasierten Bewertungsndung für
Web-Inhalte, deren praktische Umsetzbarkeit hier lediglich gezeigt wird. Die
Verzierung der hier getroenen Annahmen und Mechanismen in einem
69
groÿen Praxiseinsatz bleibt diese Arbeit aber schuldig. Die daraus generierten Resultate und Weiterentwicklungen könnten einen Beitrag dazu leisten,
dem quantitativen Wachstum eine exible Methode der benutzergenerierten
Qualitätssicherung entgegenzustellen.
70
Literaturverzeichnis
[Ar08] Arnold, H.:. Virtuelle Welten im Internet, Kapitel Virtuelle Identitäten und Reputation - Reputation als zentrales Element im
Web der Zukunft. Huethig GmbH, 2008.
[BD03] Bruegge, B.; Dutoit, A. H.:. Object-Oriented Software Engineering: Using UML, Patterns and Java, Second Edition. PrenticeHall, Inc., Upper Saddle River, NJ, USA, 2003. 0130471100.
[BL89] Berners-Lee, T.:. Information Management: A Proposal. Conseil
Européen pour la Recherche Nucléaire (CERN), March, 1989.
[BLFF] Berners-Lee, T.; Fielding, R.; Frystyk, H.:. Hypertext Transfer Protocol. Work in progress of the HTTP working group
of the IETF.< URL: ftp://nic. merit. edu/documents/internetdrafts/draft-elding-http-spec-00. txt.
[BLMM94] Berners-Lee, T.; Masinter, L.; McCahill, M.:. RFC1738 - Uniform Resource Locators (URL). Bericht, Network Working
Group, 1994.
[Br01] Brandes, U.:. A faster algorithm for betweenness centrality. Journal of Mathematical Sociology, 25(2):163177, 2001.
[Co70] Codd, E. F.:. A relational model of data for large shared data
banks. Commun. ACM, 13(6):377387, 1970.
[Co01] Cormen, T.:. Introduction to Algorithms. MIT Press, 2001.
[EW01] Eppstein, D.; Wang, J.:. Fast approximation of centrality. Sym-
posium on Discrete Algorithms: Proceedings of the twelfth annual
ACM-SIAM symposium on Discrete algorithms, 7(09):228229,
2001.
[Ga95] Gamma, E. et al.:. Design Patterns. elements of Reusable ObjectOriented Software. Addison-Wesley Professional, 1995.
71
[GH05] Golder, S.; Huberman, B.:. The Structure of Collaborative Tagging Systems. Arxiv preprint cs.DL/0508082, 2005.
[Ha05] Hammond, T. et al.:. Social Bookmarking Tools (I). D-Lib Magazine, 11(4):10829873, 2005.
[HGM06] Heymann, P.; Garcia-Molina, H.:. Collaborative creation of communal hierarchical taxonomies in social tagging systems. Bericht,
Technical Report 2006-10, Stanford University, April 2006, 2006.
[Hi05] Hitz, M. et al.:. UML@Work. dpunkt.verlag, 3. Auage, 2005.
[IC97] Iyengar, A.; Challenger, J.:. Improving Web Server Performance
by Caching Dynamic Data. In USENIX Symposium on Internet
Technologies and Systems, 1997.
[JBR99] Jacobson, I.; Booch, G.; Rumbaugh, J.:. The Unied Software
Development Process. Addison-Wesley, 1999.
[KP88] Krasner, G.; Pope, S.:. A cookbook for using the model-view
controller user interface paradigm in Smalltalk-80. Journal of
Object-Oriented Programming, 1(3):2649, 1988.
[Ma04] Mathes, A.:. Folksonomies-Cooperative Classication and Communication Through Shared Metadata. Computer Mediated
Communication, LIS590CMC (Doctoral Seminar), Graduate
School of Library and Information Science, University of Illinois
Urbana-Champaign, December, 2004.
[Mi67] Milgram, S.:. The Small World Problem. Mai 1967:6067, 1967.
[Of02] Outt, J.:. Quality Attributes of Web Software Applications. IEEE SOFTWARE, Seiten 2532, 2002.
[OM07] OMG, O. M. G.:. UML 2.1.2. 2007.
[Pa03] Palmer, J.:. Web Site Usability, Design, and Performance Metrics. Information Systems Research, 13(2):151167, 2003.
[Po] Poter, M.:. Hash-Algorithmen.
[PRW03] Picot, A.; Reichwald, R.; Wigand, R. T.:. Die grenzenlose Unternehmung. Dr. The. Gabler GmbH, 2003.
[SB87] Salton, G.; Buckley, C.:. Term Weighting Approaches in Automatic Text Retrieval. Bericht, Ithaca, NY, USA, 1987.
[Se07] Sen, S. et al.:. The quest for quality tags. Proceedings of the
2007 international ACM conference on Conference on supporting
group work, 07:361370, 2007.
72
[So04] Sommerville, I.:. Software-Engineering, 7th Edition. Pearson
Education, 2004.
[St07] Steger, A.:. Diskrete Strukturen: Band 1: Kombinatorik, Graphentheorie, Algebra. Springer, 2007.
[We96] Wellman, B. et al.:. Computer Networks as Social Networks:
Collaborative Work, Telework, and Virtual Community. Annual
Reviews in Sociology, 22(1):213238, 1996.
73