Community-Unterstützungssysteme - Architektur und Interoperabilität

Transcription

Technische Universität München
Fakultät für Informatik
Community-Unterstützungssysteme Architektur und Interoperabilität
Michael Koch
Dezember 2003
ii
Zusammenfassung
In dieser Arbeit wird aus Sicht der Angewandten Informatik das Thema „Software zur Unterstützung
von Communities“ aufgearbeitet und ein neues Architekturkonzept für zukünftige Generationen von
Community-Unterstützungssystemen hergeleitet und ausgeführt.
Wörtlich bedeutet der Begriff „Community“ Gemeinschaft. Dies kann geographisch interpretiert
werden als eine Gruppe von Menschen, die in derselben Region oder am selben Ort leben, oder
sich auf Menschen beziehen, die gemeinsame Interessen haben oder an einer gemeinsamen Aufgabe
arbeiten.
Online-Medien und Web-Plattformen können solche Communities unterstützen oder auch rein virtuelle Communities erst ermöglichen. Dabei unterstützen die Systeme im wesentlichen den Informationsfluss zwischen den Community-Mitgliedern und das Zueinanderfinden der Mitglieder.
Eine wichtige Forderung an Community-Unterstützungssysteme ist Interoperabilitität zwischen verschiedenen Instanzen der Systeme. Diese Interoperabilität wird von heutigen Systemen aber nur
selten bereitgestellt:
Benutzer müssen sich explizit bei verschiedenen Community-Unterstützungssystemen registrieren und ihre Profilinformationen wie z.B. demographische Inforrmationen und Informationen zu den Interessen immer wieder aufs neue angeben.
Es gibt keine Möglichkeit für Community-Plattformen, untereinander Information auszutauschen, bzw. für Benutzer, neue Information automatisch an verschiedene Community-Plattformen zu verteilen und Information automatisch bei verschiedenen Community-Plattformen
abzufragen.
Das in dieser Arbeit motivierte Architekturkonzept liefert mehrere Lösungsbeiträge für die Forderung
nach Interoperabilität. Erstens wird eine Lösung für die anwendungsübergreifende Nutzung von
Benutzerprofilen erarbeitet und zweitens ein Modularisierungskonzept für Community-Unterstützungssysteme vorgestellt, welches sowohl den Aufbau neuer Plattformen unterstützt als auch eine
plattformübergreifende Nutzung von Daten und Diensten erlaubt.
Die Arbeit stellt eine aktualisierte Fassung meiner Habilitationsschrift von Februar 2003 dar und steht
im Kontext meiner langjährigen Beschäftigung mit Groupware und Community-Unterstützungssystemen
(Communityware) an der Technischen Universität München und am Xerox Research Centre Europe
(XRCE) in Grenoble. In die Konzepte sind Erfahrungen aus der Entwicklung und der Einführung
verschiedener konkreter Systeme und Plattformen, insbesondere des Cobricks-Systems (siehe hierzu
http://www.cobricks.de/) eingeflossen.
Danken möchte ich an dieser Stelle vor allem meinen Kollegen an der Technischen Universität München und am Xerox Research Centre Europe für die fruchtbare Zusammenarbeit in den letzten Jahren.
iii
Besonders nennen möchte ich dabei Herrn Wolfgang Wörndl, mit dem ich an Aspekten des Identitätsmanagements und der Privatheit gearbeitet habe, sowie Herrn Georg Groh und Herrn Michael
Galla, die die Hauptlast der Entwicklungen in den Projekten „Community Online Services and Mobile Solutions“ (Cosmos) und „Telekooperation in Beziehungsnetzwerken für informationsbezogene
Dienstleistungen“ (TiBiD) getragen haben und dabei einen entscheidenden Beitrag zur Konkretisierung des Architekturkonzeptes geleistet haben. Mein Dank gilt natürlich auch Herrn Prof. Dr. Johann
Schlichter, der mir ermöglicht hat, in seiner Gruppe an der Technischen Universität München sehr
frei an den Themen der Community-Unterstützung zu arbeiten und mir dabei immer mit Rat und Tat
zur Seite stand.
iv
Inhaltsverzeichnis
1 Einleitung
1
1.1
Einführung und Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Communities und Community-Unterstützung . . . . . . . . . . . . . . . . . . . . .
2
1.2.1
Communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2.2
Community-Unterstützung . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3
Problembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.4
Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.5
Verwandte Themenbereiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.6
Aufbau der Arbeit und Einordnung der eigenen Veröffentlichungen . . . . . . . . . .
7
2 Community-Unterstützung
2.1
13
Community aus unterschiedlichen Perspektiven . . . . . . . . . . . . . . . . . . . .
13
2.1.1
Gemeinschaften in der Soziologie . . . . . . . . . . . . . . . . . . . . . . .
14
2.1.2
Gemeinschaften aus technischer Sicht . . . . . . . . . . . . . . . . . . . . .
19
2.1.3
Kategorisierungen zu Communities . . . . . . . . . . . . . . . . . . . . . .
19
2.1.4
Zusammenfassung und Konsolidierung . . . . . . . . . . . . . . . . . . . .
21
2.2
Virtuelle Communities (Online-Communities) . . . . . . . . . . . . . . . . . . . . .
21
2.3
Community-Unterstützungssysteme . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.3.1
Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.3.2
Anwendungsklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.3.3
Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.3.4
Community-Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
Anforderungen an Community-Unterstützungssysteme . . . . . . . . . . . . . . . .
29
2.4.1
Anforderungsschwerpunkte . . . . . . . . . . . . . . . . . . . . . . . . . .
29
2.4.2
Unterstützungsfunktionalitäten . . . . . . . . . . . . . . . . . . . . . . . . .
31
2.4
3 Modularisierung von Community-Unterstützungssystemen
3.1
33
Grundkonzepte der Modularisierung . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.1.1
Entwurfsmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.1.2
Verteilte Anwendungen und Komponenten . . . . . . . . . . . . . . . . . .
37
v
Inhaltsverzeichnis
3.1.3
3.2
3.3
3.4
Agenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Datenkonzepte
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
3.2.1
Wissensrepräsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.2.2
Benutzerbeiträge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.2.3
Domäneninformation - Kategorisierung . . . . . . . . . . . . . . . . . . . .
50
3.2.4
Benutzerdaten
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
3.2.5
Nutzung von Ontologien und Kontext-Information . . . . . . . . . . . . . .
53
3.2.6
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
Community-Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
3.3.1
Komponenten und Funktionalitäten . . . . . . . . . . . . . . . . . . . . . .
55
3.3.2
Benutzerprofilverwaltung
. . . . . . . . . . . . . . . . . . . . . . . . . . .
57
3.3.3
Inhalteverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
3.3.4
Kategorien und Benutzerlisten . . . . . . . . . . . . . . . . . . . . . . . . .
59
3.3.5
Kontexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
3.3.6
Mitteilungsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
3.3.7
Awareness und Matchmaking . . . . . . . . . . . . . . . . . . . . . . . . .
61
3.3.8
Personalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
Konfigurierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4 Benutzerprofile und Benutzerprofilspeicherung
4.1
4.2
4.3
4.4
vi
38
69
Struktur und Nutzung von Benutzerprofilen . . . . . . . . . . . . . . . . . . . . . .
70
4.1.1
Erhebung der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
4.1.2
Nutzung von Profilen - Personalisierung . . . . . . . . . . . . . . . . . . . .
72
4.1.3
Präsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
Benutzerprofilspeicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
4.2.1
Anwendungsunabhängige Profilspeicherung . . . . . . . . . . . . . . . . . .
73
4.2.2
Infomediaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
4.2.3
Server-basierte Benutzerprofildatenbanken . . . . . . . . . . . . . . . . . .
75
4.2.4
Liberty Alliance Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
4.2.5
Benutzerprofil-Austausch
. . . . . . . . . . . . . . . . . . . . . . . . . . .
76
4.2.6
IDRepository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
Modellierung von Benutzerprofilen . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
4.3.1
Standardisierungsbestrebungen . . . . . . . . . . . . . . . . . . . . . . . . .
78
4.3.2
Profil-Metamodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
4.3.3
Profilmodell
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
Privatheit und Zugriffskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
4.4.1
Zugriffskontrolle in einer Plattform . . . . . . . . . . . . . . . . . . . . . .
89
4.4.2
Zugriffskontrolle zwischen Plattformen . . . . . . . . . . . . . . . . . . . .
91
4.4.3
Transparenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
Inhaltsverzeichnis
5 Prototypsysteme und erste Erfahrungen
95
5.1
IDRepository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
5.2
Informationsdrehscheibe(n) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
5.3
CommunityItemsTool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
5.4
UnternehmerTUM - TUMmelplatz . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
5.5
Studiosity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.6
Produktkonfigurations-Community . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.7
Austausch von Inhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6 Zusammenfassung und Ausblick
105
6.1
Zusammenfassung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.2
Datenmodellierung und Semantic Web . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.3
Web-Services und Benutzeragenten
6.4
Kategorisierung und Unter-Communities . . . . . . . . . . . . . . . . . . . . . . . . 107
6.5
Mobile Communities und ubiquitäre Benutzungsschnittstellen . . . . . . . . . . . . 107
. . . . . . . . . . . . . . . . . . . . . . . . . . 106
Literaturverzeichnis
109
Index
119
vii
Inhaltsverzeichnis
viii
Kapitel 1
Einleitung
„Das globale Dorf wird wohl wahr, aber anders, als man sich das einmal
vorgestellt hatte. Es wird nicht die Welt zu einem einzigen großen Dorf,
sondern die ganze Informationsgesellschaft splittert sich auf in lauter kleine
Dörfer, deren Bewohner über die ganze Welt verstreut sind: statt des einen
globalen Dorfs viele global verteilte Dörfer.“,
(Zimmer 2000, S.40)
Kapitelinhalt
1.1
1.2
1.3
1.4
1.5
1.6
1.1
Einführung und Überblick . . . . . . . . . . . . . . . . . . . . . . .
Communities und Community-Unterstützung . . . . . . . . . . . .
Problembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . .
Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verwandte Themenbereiche . . . . . . . . . . . . . . . . . . . . . .
Aufbau der Arbeit und Einordnung der eigenen Veröffentlichungen
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
4
4
5
7
Einführung und Überblick
Eines der wichtigsten Merkmale des Menschen ist sein Bestreben nach Kommunikation mit anderen Menschen, insbesondere mit Gleichgesinnten. Vor diesem Hintergrund kann auch der aktuelle
Internetboom nicht weiter überraschen, denn das Medium Internet bietet fast grenzenlose Kommunikationsmöglichkeiten.
So hat sich das Internet in den letzten Jahren von einem „kleinen“ Netz für Computerspezialisten
zu einem Netz für jedermann gewandelt. Dies belegen unter anderem die weltweit immer schneller
steigende Benutzeranzahl (2 Mio. 1993, 27 Mio. 1996, 50 Mio. 1997, 150 Mio. 2000, 250 Mio. 2002
– je nach Quelle variieren diese Zahlen aufgrund von Problemen bei der Erhebung stark). Ähnlich
verläuft die Entwicklung bei den Dienstangeboten. Gründe für diesen Boom sind unter anderem
der konkrete Kommunikationsnutzen, die massiven Marketingkampagnen der Internet Service Provider (wie z.B. AOL und T-Online) und netzbezogenen Dienstleister (wie z.B. IBM), die staatlichen
Förderungen (wie z.B. die Bürgernetzförderung oder die Vernetzung von Schulen), die zunehmende
Verbreitung moderner Kommunikations- und Computertechnik in Firmen sowie Privathaushalten und
die steigende Benutzerfreundlichkeit der benötigten Zugangssoftware.
Mit der Änderung des Profils der Benutzer weg vom Computer-Spezialisten hin zum Normalbürger
hat sich auch das Angebotsprofil im Internet, insbesondere im heute wichtigsten Bestandteil, dem
1
1 Einleitung
World-Wide-Web, entscheidend geändert. Statt purer wissenschaftlicher Informationen dominieren
heute Kommunikations-, Unterhaltungs- und Verkaufsangebote das World-Wide-Web.
Nachdem immer mehr Benutzer und immer mehr Dienste im Internet verfügbar werden, beginnen
Computer und Netze, eine Art soziale Umgebung zu bilden, in der Menschen sich selbst darstellen,
sich mit anderen treffen, Informationen austauschen, Geschäfte machen, gemeinsam auf Informationssuche gehen können. Computernetze werden „bevölkert“ und „bewohnt“, von Menschen und
ihren Software-Agenten. Sie bilden eine neue Art von Lebensraum. Wie der reale Lebensraum werden Infrastruktur und Dienste gebraucht, Orientierungsmittel, Mittel andere Personen zu finden, seine
Privatsphäre zu schützen (Hoschka u. a. 2001).
Diese Infrastruktur stellen momentan einerseits allgemeine Kommunikationsdienste wie E-Mail dar,
und auf der anderen Seite sogenannte Community-Plattformen (oder Online-Communities). Die ersten dieser Online-Communities entstanden in den USA, meist ohne reales Pendant. Es gibt aber
auch einige teilweise oder komplett mit real existierenden Gemeinschaften identische virtuelle Gemeinschaften bzw. Unterstützungs-Plattformen für reale Gemeinschaften, wie z.B. die oft als Urvater
bezeichnete virtuelle Gemeinschaft „The Well“ 1 (gegründet 1986 durch die Point Foundation). Diese
Gemeinschaft hat heute über zehntausend aktive Mitglieder, obwohl sie sich über einen monatlichen
Mitgliedsbeitrag finanziert.
1.2
Communities und Community-Unterstützung
Hintergrund von Community-Plattformen oder Online-Communities ist die Bereitstellung einer Kommunikationsmöglichkeit für eine durch einen Kontext definierte Menge von Personen. Der gemeinsame Kontext ermöglicht die effiziente Nutzung der Kommunikationsmedien zum Informationsaustausch und zum Finden von Gleichgesinnten oder Experten in einem bestimmten Gebiet.
Eine solche Gruppe von Personen, die sich durch einen gemeinsamen Kontext auszeichnen, bezeichnet man im Rückgriff auf Begriffe der Soziologie üblicherweise als Gemeinschaft oder Community 2 .
1.2.1
Communities
Communities sind also Gruppen von Personen mit einem gemeinsamen Kontext. Weiterhin wird
meist noch eine Kommunikationsmöglichkeit (Kommunikationskanal) und der Wille oder das Bewußtsein zur Mitgliedschaft (freiwillige Zugehörigkeit) sowie eine Kooperation der Community-Mitglieder gefordert. Eine detailliertere Auseinandersetzung mit dem Begriff der Community findet sich
in Kapitel 2 dieser Arbeit.
Bei Communities handelt es sich um keine neue Erfindung aus dem Bereich der Anwendungen vernetzter Rechner. Das Konzept ist untrennbar mit der Kommunikation und Zusammenarbeit zwischen
Menschen verbunden. Dabei wurden bisher meist durch räumliche Nähe definierte Communities
betrachtet, z.B. Dorfgemeinschaften oder Nachbarschafts-Communities, oder durch gemeinsame Interessen und Ziele definierte Communities wie Jagdgemeinschaften oder Sportvereine.
Der Nutzen von Communities für ihre Mitglieder war und ist seit jeher die gegenseitige Hilfe und die
gemeinsame Nutzung von Ressourcen. Das Community-Mitglied ist nicht mehr auf sein eigenes Wis1
2
2
Well: Whole Earth (e)Lectronic Link, siehe http://www.well.com/ oder (Hafner 2001)
Ich bleibe in der weiteren Arbeit hauptsächlich bei dem englischen Begriff „Community“, der sich in der einschlägigen
Literatur durchgesetzt hat.
1.2 Communities und Community-Unterstützung
sen und seine eigenen Fähigkeiten beschränkt, sondern kann auf den Erfahrungs- und Wissensschatz
der gesamten Gemeinschaft zur Erreichung seiner Ziele zurückgreifen. Der Wert von Communities
liegt dabei nur teilweise in der Information, die von den Mitgliedern zusammengetragen wird, sondern mehr in den Mitgliedern selbst, die für die Beantwortung von Fragen erreicht werden können.
1.2.2
Community-Unterstützung
Klassische Gemeinschaften finden Unterstützung für ihre Aufgaben des Informationstransfers und
Findens von Kommunikations- oder Kooperationspartnern (Matchmaking) in regelmäßigen Treffen,
Zeitschriften oder Schwarzen Brettern und Club-Räumen. Mit Online-Medien und Web-Plattformen
können nun auch Gemeinschaften über räumliche Entfernungen hinweg unterstützt werden. Damit
wird der Wirkungsbereich einer Gemeinschaft erhöht oder manche Gemeinschaften gar erst ermöglicht (z.B. wenn zu wenig potentielle Community-Mitglieder in erreichbarer Nähe leben).
Unter Community-Unterstützungssystemen versteht man Software mit Funktionen zur Unterstützung
des Informationsflusses zwischen den Community-Mitgliedern und des Zueinanderfindens der Mitglieder. Heute handelt es sich dabei meist um Web-basierte Software. Die Software wird in Form
von einzelnen Web-Plattformen betrieben. Diese stellen Kommunikations- und Koordinationsdienste bereit und verarbeiten zur Personalisierung dieser Dienste und zur Präsentation des Benutzers
gegenüber anderen Community-Mitgliedern Benutzerprofile.
Die Nutzung solcher Community-Plattformen sollte so einfach sein wie die „Nutzung“ klassischer
Community-Unterstützungswerkzeuge. Insbesondere sollte das für das Wechseln zwischen Community-Plattformen gelten. In der Realität finden sich hier aber meist proprietäre, voneinander isolierte
Lösungen, die häufig nicht einmal die Grundbedürfnisse der Interaktion in Communities berücksichtigen.
Community-Unterstützungssysteme und -Plattformen
Im Zusammenhang mit Community-Unterstützung werden teilweise verschiedene Begriffe synonym
und gleiche Begriffe mit unterschiedlicher Bedeutung benutzt. An dieser Stelle sollen deshalb die im
weiteren zu verwendenden Begriffe für diese Arbeit genauer spezifiziert werden.
Unter einer Community-Plattform verstehe ich dabei keine allgemeine Systemplattform wie einen
Desktop-PC, sondern im Sinne Verteilter Anwendungen eine konkrete Instanz einer Netz-basierten
Unterstützungssoftware, die meist als Client-Server-System realisiert ist und von den Mitgliedern
einer Community zur Kommunikation untereinander benutzt werden kann. Client-Rechner und die
Client-Software werden nicht mit zur Plattform gezählt. Eine Ausnahme hiervon gibt es nur, falls zur
Benutzung der Anwendung proprietäre Client-Software oder Hardware eingesetzt wird.
Unter einem Community-Unterstützungssystem verstehe ich ein bestimmtes Softwareprodukt mit
Funktionalitäten zur Unterstützung von Communities. Wird die Software für eine bestimmte Community oder für eine bestimmte Gruppe von Communities betrieben, dann entsteht dabei eine Community-Plattform als Instanz des Community-Unterstützungssystems.
Die drei Kernbegriffe definieren sich also folgendermaßen:
Community: Gruppe von Personen mit gemeinsamem Kontext (siehe hierzu auch Abschnitt
1.2.1 und Kapitel 2)
3
1 Einleitung
Community-Unterstützungssystem: Software, die zur Unterstützung (oder Ermöglichung) von
Communities eingesetzt werden kann.
Community-Plattform: Instanz eines Community-Unterstützungssystems, d.h. ein CommunityUnterstützungssystem, das für eine bestimmte Community betrieben wird. Bei proprietärer Benutzungsschnittstelle schließt der Plattform-Begriff dabei die Client-seitige Soft- und Hardware
mit ein.
Online-Community: Gruppe von Personen, die (ausschließlich) über eine (Web-basierte) Community-Plattform interagieren; wird oft auch als Synonym für die (Web-basierte) CommunityPlattform benutzt (siehe hierzu auch Abschnitt 2.2).
1.3
Problembeschreibung
Eine wichtige Forderung für den Einsatz von Community-Unterstützungssystemen ist die Interoperabilität zwischen verschiedenen Instanzen der Systeme (also den Plattformen) sowie zwischen verschiedenen Systemen selbst. Diese Interoperabilität wird von heutigen Systemen und Plattformen
aber nur selten bereitgestellt:
Benutzer müssen sich explizit auf verschiedenen Community-Plattformen registrieren und ihre
Profilinformationen wie z.B. demographische Informationen und Interessen immer wieder neu
angeben.
Es gibt keine Möglichkeit für Community-Plattformen, Information untereinander auszutauschen, bzw. für Benutzer, neue Information automatisch an verschiedene Communities zu verteilen und Information automatisch bei verschiedenen Communities abzufragen.
Die Isolation der Plattformen voneinander ist insbesondere deshalb problematisch, da Menschen seit
jeher Mitglied in mehr als einer Community sind. Verschiedene soziologische Muster beruhen gar
auf der gleichzeitigen Mitgliedschaft von Menschen in verschiedenen Communities (siehe auch Abschnitt 2.1.1, S.17). Wenn durch proprietäre Plattformen der Austausch zwischen Communities und
der Wiedereinstieg von „Community-Pendlern“ in eine Community erschwert wird, dann ist dadurch
der Nutzen solcher Unterstützungssoftware in Frage gestellt.
Neben der Lösung des konkreten Interoperabilitätsproblems besteht weiterhin Bedarf an einer grundlegenden Betrachtung des Anwendungsbereichs „Community-Unterstützung“. Bestehende Plattformen nähern sich dieser Aufgabe meist zu sehr von aus anderen Bereichen stammenden Konzepten.
So wird häufig eine Community „um einen Online-Shop herum“ gebaut oder als Ergänzung zu einer
Web-Site eingeführt. Auch wenn solche Konzepte hin und wieder erfolgreich sind, nutzen sie das
eigentliche Potential von Community-Unterstützung kaum aus.
1.4
Zielsetzung
Entsprechend der im vorherigen Abschnitt beschriebenen Probleme im Kontext von CommunityUnterstützung war das Ziel meiner Forschungstätigkeit zunächst, den Bereich Community-Unterstützung mit Motivation und Triebkräften näher zu beleuchten und die Charakteristika von Community-Unterstützungssystemen herauszuarbeiten.
4
1.5 Verwandte Themenbereiche
Im zweiten Schritt sollten dann Lösungen für das Problem der Interoperabilität entwickelt werden
und die Lösungsideen in der Praxis erprobt werden. Konkret soll eine Architektur und Komponenten
für ein modulares Community-Unterstützungssystem konzipiert werden. Den Begriff Architektur definiere ich nach (Buschmann u. a. 1996, S.384) als „a description of the subsystems and components
of a software system and the relationships between them“. Als Teilthema sollte dabei insbesondere
auf die gemeinsame Nutzung von Benutzerprofilinformation und die Definition von anwendungsübergreifenden Benutzerprofilmodellen eingegangen werden.
1.5
Verwandte Themenbereiche
Das Thema „Community-Unterstützung“ steht nicht isoliert im Spektrum der Angewandten Informatik. Die engsten Verbindungen und Überschneidungen gibt es mit den Themenbereichen Wissensmanagement und Rechnergestützte Gruppenarbeit.
Wissensmanagement
Während sich aktuelle Arbeiten im Bereich Wissensmanagement hauptsächlich mit der Externalisierung von Wissen und der Erschließung des Zugriffs auf externalisiertes Wissen beschäftigt (Borghoff
und Pareschi 1998a), geht der Bereich Community-Unterstützung das selbe Thema von Seiten der
Benutzer her an. Hier liegt der Hauptaugenmerk auf dem Zusammenbringen von Menschen zum
direkten Wissensaustausch. Dabei werden aber auch semi-strukturierte Daten von Benutzern erfasst
und durchsuchbar gemacht. Im Unterschied zum puren Wissensmanagement sieht man hier aber
hauptsächlich „warme“ Information, d.h. Information, die mit Personen verbunden ist, z.B. ein (subjektiver) Kommentar zu einem Objekt.
Rechnergestützte Gruppenarbeit, CSCW
Der Bereich Rechnergestützte Gruppenarbeit (Computer-Supported Cooperative Work, CSCW) beschäftigt sich hauptsächlich mit der Unterstützung von Arbeitsgruppen (Borghoff und Pareschi 1998b;
Borghoff und Schlichter 2000). Darunter versteht man Gruppen von Personen, die an einer gemeinsamen (Teil-)Aufgabe arbeiten. Im Unterschied zu Communities kennen sich die Mitglieder dieser
Gruppen meist sehr gut, interagieren häufig miteinander, und die Hauptherausforderung besteht nicht
im Finden von Personen oder in der Weitergabe von Information an Interessierte, sondern in der
Koordination auf gemeinsamen Artefakten.
Auch das Thema der Modularisierung und Interoperabilität ist in der Informatik nicht komplett neu.
Hier gibt es bereits einige Arbeiten in den Bereichen Software-Engineering, Software-Frameworks,
Anwendungsintegration und Agenten.
Software-Engineering, Modulare Programmierung
Schon seit den 1960er Jahren beschäftigt sich die Informatik unter dem Begriff „Software Engineering“ mit der ingenieurmäßigen Erstellung von Software. Dabei waren auch die Aufteilung von
Softwarepaketen in (wiederverwendbare) Module oder Komponenten und die klare Definition von
Schnittstellen zwischen diesen Komponenten ein wichtiges Thema.
5
1 Einleitung
Einige Erkenntnisse dieses Forschungsgebietes werden in Kapitel 3 aufgegriffen um die Grundlagen
für die Definition einer generischen Community-Unterstützungsarchitektur zu legen.
Software-Frameworks, Entwurfsmuster
Das Thema der Modularisierung wurde in Richtung Software-Frameworks weiterentwickelt. Darunter versteht man Sammlungen von Basisklassen, die Ablauflogik enthalten und einfach durch Spezialisierung von Klassen oder durch Erweiterung auf definierten Schnittstellen auf eine bestimmte
Anwendung hin spezialisiert werden können. In diesem Zusammenhang ist auch das Thema „Anpassbarkeit“ zu nennen. Hier geht es um die einfache Adaptierung von Software.
Während Software-Frameworks eine technische Lösung für generalisierte Software bieten, widmen
sich Entwurfsmuster (Design-Patterns) demselben Problem von der konzeptionellen, designerischen
Seite. Sie stellen Muster für Software-Design dar.
In Kapitel 3 wird näher auf Aspekte von Software-Frameworks und Entwurfsmuster eingegangen, die
im hier behandelten Kontext eine Rolle spielen.
Anwendungsintegration
In der Wirtschaftsinformatik gibt es einen Arbeitsbereich namens „Anwendungssystem-Integration
(application integration)“, welcher sich mit der Verknüpfung heterogener Informationssysteme beschäftigt (Mantel und Schlissler 2002).
Eines der größten Probleme bei der Anwendungssystem-Integration ist dabei die Bewältigung der
fachlichen Heterogenität. Hierfür werden standardisierte XML-Geschäftsvokabulare und Geschäftsprozessstandards betrachtet. Mit ebXML, RosettaNet und OASIS sind hier bereits vielversprechende
Standardisierungsbemühungen zu finden.
Weiterhin werden im Zusammenhang mit der Anwendungssystem-Integration verschiedene neue
Technologien aus den Verteilten Anwendungen (z.B. Web-Services) aufgegriffen.
Die in Kapitel 3 dokumentierte Erarbeitung von allgemeinen Datenkonzepten und Schnittstellen geht
auch auf diese Arbeiten näher ein.
Agenten
Dem Problem der Definition möglichst flexibler Schnittstellen widmen sich die Aktivitäten im Bereich der Software-Agenten. Hier wurde das Paradigma für die Kapselung von Funktionalität (klassische Modularisierung) um die Kapselung von Absichten und Wissen erweitert und eine Kommunikationsschnittstelle mit höherer Semantik spezifiziert.
Die Datenmodellierungskonzepte, die in Kapitel 3 vorgestellt werden, sind den Schnittstellen- und
Datenmodellierungskonzepten aus dem Agentenumfeld angelehnt. Dazu wird das Thema (Software-)
Agenten in Abschnitt 3.1.3 näher diskutiert.
Künstliche Intelligenz
Agenten sind aus dem großen Bereich der Künstlichen Intelligenz hervorgegangen. Hier sind vor
allem Bestrebungen zur Kodierung von Wissen und von Absichten oder Plänen zu erwähnen, die
6
1.6 Aufbau der Arbeit und Einordnung der eigenen Veröffentlichungen
auch bei der Definition von offenen Schnittstellen zwischen Komponenten eines Community-Unterstützungssystems eine Rolle spielen werden.
1.6
Aufbau der Arbeit und Einordnung der eigenen
Veröffentlichungen
Zur Erreichung der im Abschnitt 1.4 angesprochenen Ziele habe ich mich in meiner Forschungstätigkeit mit folgenden Aufgaben beschäftigt (siehe auch Abschnitt 2.4 für eine ausführliche Motivation
der verschiedenen Anforderungen an Community-Unterstützungssysteme und eine Strukturierung der
dazu notwendigen Arbeiten):
Definition von Community-Unterstützung und Herleitung der Anforderungen an CommunityUnterstützungssysteme,
Modularisierung von Community-Unterstützungssystemen,
Interoperabilität zwischen Community-Unterstützungssystemen (d.h. der Fähigkeit heterogener Systeme gemeinsam Daten zu nutzen bzw. Daten auszutauschen),
im Zusammenhang mit Interoperabilität speziell die gemeinsame Nutzung von Benutzerprofilen durch mehrere Anwendungen und die Möglichkeiten der Benutzerkontrolle und Privatheit
in diesem Kontext,
Personalisierung oder allgemein Kontextanpassung von Inhalten und (Kommunikations-)Funktionalitäten und
mobilen oder nicht-Standard-Benutzungsschnittstellen für Community-Unterstützungssysteme.
Meine ausführlichen Arbeiten hierzu sind in verschiedenen Veröffentlichungen dokumentiert (siehe
das kommentierte Publikationsverzeichnis weiter unten in diesem Abschnitt). Ziel dieser zusammenfassenden Darstellung der Forschungstätigkeiten ist es, die wichtigsten Teilbereiche der auf die
verschiedenen Veröffentlichungen verteilten Arbeiten an einer Stelle zusammenzufassen und dabei
noch etwas weiterzuentwickeln.
Nach dieser Einleitung fasse ich in Kapitel 2 dazu zuerst Grundbetrachtungen zu Communities und
Community-Unterstützung zusammen und stelle die in meiner Arbeit abgeleiteten allgemeinen Funktionalitäten von Community-Unterstützungssystemen dar.
Anschließend gehe ich in Kapitel 3 auf die bei meiner Beschäftigung mit Community-Unterstützung
erarbeitete Architektur für Community-Unterstützungssysteme ein. Aus den in Kapitel 2 motivierten
Anforderungen werden Datenstrukturen und Dienstschnittstellen herausgearbeitet und detailliert.
In Kapitel 4 gehe ich speziell auf den Austausch und zur gemeinsamen Nutzung von Benutzerprofilen
ein. Hier diskutiere ich die erarbeitete Lösung, das IDRepository, und gebe einen Überblick über die
verschiedenen Design- und Technologie-Aspekte, die hierbei eine Rolle spielen.
Zur Konkretisierung und Evaluierung der Konzepte wurden einige Community-Unterstützungsplattformen aufgebaut und begleitet. In Kapitel 5 werden die wichtigsten dieser Plattformen kurz vorgestellt und auf spezielle Erkenntnisse eingegangen, die an den jeweiligen Beispielen herausgearbeitet
werden konnten.
7
1 Einleitung
Die Arbeit schließt mit einer kurzen Zusammenfassung und einem Ausblick in Kapitel 6.
Nachfolgend sind die Hauptarbeiten ((Koch und Wörndl 2001), (Koch 2002b), (Koch 2002c), (Koch
2002e), (Koch 2002f), (Koch u. a. 2002a), (Koch und Möslein 2003) und (Koch 2003a)) und alle
anderen Veröffentlichungen, die im Kontext dieses Arbeitsgebietes stehen, aufgelistet. Um sie in den
Forschungskontext zu stellen, werden die einzelnen Veröffentlichungen nach den Bereichen sortiert
präsentiert, zu denen sie jeweils ihren Hauptbeitrag liefern.
Funktionalitäten und Architektur allgemein
Die Erarbeitung und Darstellung der allgemeinen Charakteristika von Community-Unterstützungssystemen und die daraus abgeleitete Architektur für diese Systeme stellt den Kern dieser Arbeit
dar. Bei der Architektur wird insbesondere auf den Aspekt der Agenten-basierten Modellierung von
Community-Unterstützungssystemen und auf die spezielle Bedeutung der anwendungsübergreifenden Benutzerprofilverwaltung eingegangen. Weitere Aspekte, die in Zusammenhang mit der Architektur angesprochen werden, sind der komponentenbasierte Aufbau von Kooperationsdiensten und
die Anpassbarkeit von solchen Anwendungen. Die Architektur wurde im Projekt Cobricks (Community Bricks - Bausteine zum Aufbau von Community-Unterstützungssystemen) und seinen Unterprojekten wie Caiman und Pace3 implementiert und zur Realisierung verschiedener Prototypplattformen
eingesetzt.
Die Hauptarbeiten zu Charakteristika von Community-Unterstützungssystemen und zur Architektur
sind in (Koch 2002b), (Koch 2002e), (Koch 2002f), (Koch u. a. 2002a) und (Borghoff u. a. 2001)
dokumentiert. Neben ihrem Beitrag zur Definition der Anforderungen an Community-Unterstützung
(Kapitel 2) stellen all diese Arbeiten das Fundament für Kapitel 3 dieser Arbeit dar. Dort findet sich
neben einer ausführlichen Zusammenfassung auch eine Ergänzung dieser Arbeiten. Weitere wichtige Beiträge finden sich in Veröffentlichungen zu Anwendungen der Basisarchitektur in konkreten
Plattformen. Diese sind im entsprechenden Abschnitt weiter unten aufgeführt.
(Koch 2002b) Michael Koch: An Architecture for Community Support Platforms - Modularization
and Integration. Proc. 6th Intl. Conf. on Work With Display Units - World Wide Work (WWDU2002),
H. Luczak, A. E. Cakir, G. Cakir (Hrsg.), Berchtesgaden, Mai 2002, S.533-535.
In diesem Artikel werden die generischen Community-Dienste der Cobricks-Plattform vorgestellt und
verschiedene Herausforderungen der Interoperabilität diskutiert.
(Koch 2002e) Michael Koch: Interoperable Community Platforms and Identity Management in the
University Domain. International Journal on Media Management, 4(1), Jun. 2002, S.21-30.
Dieser Artikel diskutiert die Anwendung von Community-Plattformen im Universitätsumfeld. Aus den
Spezifika des Umfeldes werden verschiedene Anforderungen an die Interoperabilität von CommunityPlattformen abgeleitet und Lösungen zu Herstellung der Interoperabilität vorgestellt. Weiterhin werden
die ersten Ergebnisse des Einsatzes der Prototypplattformen aus dem Universitätsumfeld vorgestellt.
(Koch 2002f) Michael Koch: Requirements for Community Support Systems - Modularization, Integration and Ubiquitous User Interfaces. Journal of Behaviour and Information Technology, 21(5), 2002,
S.327-332.
Eine Weiterentwicklung von (Koch 2002b) - Es werden allgemeine Anforderungen an CommunityUnterstützungssysteme erarbeitet und die Cobricks-Architektur als Lösung für einen Teil der Anforderungen vorgestellt.
3
8
Siehe hierzu die Cobricks-Projektseiten unter http://www.cobricks.de/cobricks/.
(Koch u. a. 2002a) Michael Koch, Georg Groh, Christian Hillebrand, Natalie Fremuth: Mobile Support
for Lifestyle Communities. Arbeitspapier Nr. 34 des Lehrstuhls für Allg. und Ind. Betriebswirtschaftslehre (AIB), Technische Universität München, ISSN 0942-5098, Nov. 2002.
Dieser Bericht motiviert die Architektur und die Funktionalitäten der Plattform für die Unterstützung
mobiler Communities im Projekt Cosmos.
(Borghoff u. a. 2001) Uwe M. Borghoff, Michael Koch, Martin S. Lacher, Johann H. Schlichter, Knut
Weißer: Informationsmanagement und Communities - Überblick und Darstellung zweier Projekte der
IMC-Gruppe München. Informatik Forschung und Entwicklung, 16(2), Jul. 2001, S.103-109.
Dieser Beitrag beschreibt die zusammen mit der Bundeswehruniversität München (in der IMC Gruppe)
erarbeitete Agenten-basierte Architektur für Community-Unterstützungssysteme.
(Koch 2001a) Michael Koch: Community-Support-Systeme. In: CSCW-Kompendium, G. Schwabe, N.
Streitz, R. Unland (Hrsg.), Springer Verlag, Berlin, 2001, S.286-296.
In diesem Buchbeitrag werden allgemeine Unterstützungsfunktionen für Communities dargestellt.
(Lacher u. a. 2001) Martin S. Lacher, Michael Koch, Wolfgang Wörndl: A Framework for Personalizable Community Web Portals. Proc. Human-Computer Interaction International, New Orleans, LA, Aug.
2001.
Dieser Beitrag beschreibt ein System zur Personalisierung der Web-Benutzungsschnittstelle von Community-Portalen.
(Koch 2000) Michael Koch: Cobricks - Eine agentenbasierte Infrastruktur für Community-Anwendungen.
Proc. Deutsche Computer-Supported Cooperative Work Konferenz (D-CSCW 2000), R. Reichwald, J.
Schlichter (Hrsg.), München, Sep. 2000, Teubner Verlag, Stuttgart, S.265-266.
Dieser Artikel diskutiert erste Ideen zur Cobricks-Plattform.
(Koch und Lacher 2000) Michael Koch, Martin S. Lacher: Integrating Community Services - A Common Infrastructure Proposal. Proc. Knowledge-Based Intelligent Engineering Systems and Allied Technologies, Brighton, UK, Aug. 2000, S.56-59.
Dieser Beitrag beschreibt erste Ansätze zur allgemeinen Architektur für Community-Unterstützungssysteme. Dabei wird noch der streng agentenbasierte Ansatz verfolgt, der später fallengelassen worden
ist.
(Lacher und Koch 2000) Martin S. Lacher, Michael Koch: An Agent-based Knowledge Management
Framework. Proc. AAAI Spring Symposium 2000, Stanford, CA, März 2000, S.145-147.
Dieser Beitrag stellt eine agentenbasierte Community-Unterstützungsarchitektur vor, die hauptsächlich
auf die Anwendung für Wissensmanagement-Plattformen ausgerichtet ist. Viele Grundkonzepte dieser
Architektur sind eng mit der Cobricks-Architektur verwandt.
(Lacher u. a. 2000) Martin S. Lacher, Wolfgang, Wörndl, Michael Koch, Harald Brede: Ontology mapping in community support systems. Technischer Bericht, Fakultät für Informatik, Technische Universität München, Mai 2000.
Dieser Beitrag stellt eine Lösung zur Abbildung verschiedener Inhalts-Kategorisierungen in CommunityUnterstützungssystemen vor.
(Koch und Teege 1999) Michael Koch, Gunnar Teege: Support for Tailoring CSCW Systems: Adaptation by Composition. Proc. 7th Euromicro Workshop on Parallel and Distributed Processing, Funchal,
Portugal, Feb. 1999, IEEE Press, S.146-152.
Dieser Beitrag beschreibt, wie man aspekt-basierte Anpassung mit komponenten-basierter Anpassung
kombinieren kann. Die Ansätze wurden im Gruppeneditor Iris eingesetzt, stellen aber auch eine wichtige
Grundlage für die Anpassungskonzepte bei den Cobricks-Diensten dar.
9
1 Einleitung
(Koch 1998) Michael Koch: Knowledge Management and Knowledge Agents in Campiello. Proc.
Workshop on Intelligent Agents in CSCW, B. Lees, H. J. Müller, C. Branki (Hrsg.), Sep. 1998, Fachbereich Informatik, Universität Dortmund, S.44-52.
Dieser Beitrag beschreibt erste Ideen zur Konzeption einer agentenbasierten Unterstützungsarchitektur
für Communities.
Benutzerprofile
Bei den Architekturüberlegungen ist die anwendungsunabhängige Verwaltung von Benutzerprofilinformation besonders herauszustellen. Nachfolgend aufgeführte Veröffentlichungen gehen speziell auf
dieses Thema ein und arbeiten besonders den Aspekt der Wahrung der Privatsphäre und deren technische Unterstützung heraus. Dabei wird das Thema sowohl allgemein behandelt (Koch und Wörndl
2001), als auch im Kontext verschiedener konkreter Anwendungsszenarien (z.B. die Personalisierung
von Produktvorschlägen in (Koch 2002d)),
Die Hauptarbeiten in diesem Bereich sind (Koch und Wörndl 2001), (Koch 2002c) und (Koch und
Möslein 2003). Diese und die nachfolgend zusätzlich aufgeführten Arbeiten bilden die Grundlage zu
Kapitel 4.
(Koch und Möslein 2003) Michael Koch, Kathrin Möslein: User Representation in E-Commerce and
Collaboration Applications. Proc. 16th Bled eCommerce Conference., S. 649 - 661, Jun. 2003.
Dieser Beitrag baut auf (Koch 2002c) auf und stellt die Anforderungen an Identitätsmanagement für
E-Commerce- und Collaboration-Anwendungen heraus.
(Wörndl u. a. 2003) Wolfgang Wörndl, Johann Zehentner, Michael Koch: Vergleich des Umgangs mit
Privatheit bei Passport und Liberty Alliance. Proc. GI Jahrestagung Informatik 2003 - Teiltagung
Sicherheit, Sep. 2003.
Dieser Beitrag vergleicht die Identitätsmanagement-Lösungen von Microsoft (Passport) und von der
Liberty Alliance hinsichtlich ihrer Unterstützung für Privatheit (Benutzerkontrolle).
(Schubert und Koch 2003) Petra Schubert, Michael Koch: Collaboration Platforms for Virtual Student
Communities. Proc. Hawaii International Conference on System Science (HICSS-36), Jan. 2003.
In diesem Beitrag werden die Anforderungen an Benutzerprofile an Beispiel von zwei Kooperationsplattformen für Studierende herausgearbeitet.
(Koch 2002c) Michael Koch: Global Identity Management to Boost Personalization. Proc. Research
Symposium on Emerging Electronic Markets, P. Schubert, U. Leimstoll (Hrsg.), Basel, Schweiz, Sep.
2002, Institut für Angewandte Betriebsökonomie, Fachhochschule beider Basel, S.137-147.
Dieser Beitrag stellt die Bedeutung von globaler Benutzerprofilverwaltung für Online-Dienste und dabei
speziell für die Personalisierung und für kleine Betreiber heraus. Es werden ausführlich verwandte
Aktivitäten diskutiert und die IDRepository-Lösung vorgestellt.
(Koch u. a. 2002b) Michael Koch, Kathrin Möslein, Petra Schubert: Communities and Personalization
for Individual Products. Proc. British Academy of Management Annual Conference (BAM2002), Sep.
2002.
In diesem Beitrag wird die Bedeutung und grundlegende Funktionsweise von globaler Benutzerprofilverwaltung für zukünftige Plattformen zum Design individualisierter Produkte diskutiert.
(Koch 2002d) Michael Koch: Globale Benutzerprofile und kundenindividuelle Produkte. Proc. Liechtensteinisches Wirtschaftsinformatik-Symposium 2002, Vaduz, Liechtenstein, Jun. 2002.
Dieser Beitrag beschreibt die IDRepository-Lösung im Zusammenhang mit der Individualisierung von
Produkten.
10
(Koch und Schubert 2002) Michael Koch, Petra Schubert: Personalization and Community Communication for Customer Support. Proc. 6th Intl. Conf. on Work With Display Units - World Wide Work
(WWDU2002), H. Luczak, A. E. Cakir, G. Cakir (Hrsg.), Berchtesgaden, Mai 2002, S.530-532.
Dieser Beitrag greift das Thema Personalisierung auf und diskutiert Anforderungen an die Benutzerprofilverwaltung.
(Koch und Wörndl 2001) Michael Koch, Wolfgang Wörndl: Community Support and Identity Management. Proc. Europ. Conf. on Computer-Supported Cooperative Work (ECSCW2001), Bonn, Sep. 2001,
S.319-338.
In diesem Beitrag wird das Grundkonzept des IDRepositories und die Aushandlung von Zugriffsrechten
beschrieben.
Community-Unterstützungsplattformen
Die Überlegungen zu Community-Unterstützungssystemen wurden in mehreren Anwendungsbereichen praxisnah erprobt. Dazu wurden sowohl die allgemeinen Überlegungen zu Anforderungen mit
den konkreten Situation in den verschiedenen Bereichen in Einklang gebracht, als auch die erarbeiteten Konzepte zu Funktionalitäten und Architektur früh umgesetzt und in der Praxis evaluiert und
weiterentwickelt.
Die nachfolgend aufgelisteten Veröffentlichungen beschreiben die Anforderungen und Ergebnisse
aus den Bereichen:
Anwendung von Community-Unterstützung beim Finden von Geschäftspartnern (Projekt „Telekooperation in Beziehungsnetzwerken für informationsbezogene Dienstleistungen“ (TiBiD))
Unterstützung der Kommunikation in Communities im Universitätsumfeld (Projekte „Informationsdrehscheibe“, „UnternehmerTUM“ und „TUMmelplatz“)
Unterstützung von Freizeit-Communities (Projekt „Community Online Services and Mobile
Solutions“ (COSMOS))
Produkt-Communities und Generierung von personalisierten Produktempfehlungen (Projekt
„Generierung und Adaption von personalisierter Produktinformation“ im SFB582)
Wissensmanagement in lose gekoppelten Arbeitsgruppen (Projekt „CommunityItemsTool“)
Die Plattformen und die damit gemachten Erfahrungen sind auch in Kapitel 5 dieser Arbeit kurz
beschrieben.
(Koch 2003a) Michael Koch: Community Support in Universities - The Drehscheibe Project. Proc. Intl.
Conf. on Communities and Technologies, M. Huysman, E. Wenger, V. Wulf (Hrsg.), S. 445 - 464, Sep.
2003.
Beschreibung des Drehscheibe-Systems zur Unterstützung von Communities im Universitätsumfeld sowie erster Erfahrungen vom Einsatz des Systems.
(Stegmann u. a. 2003) Rosmary Stegmann, Michael Koch, Martin Lacher, Thomas Leckner und Volker Renneberg: Generating Personalized Recommendations in a Model-Based Product Configurator
System. Proc. Intl. Joint Conf. On Artificial Intelligence (IJCAI) - Workshop on Configuration, Aug.
2003.
Motivation und Beschreibung des Aufbaus eines Systems zum Einsatz von Personalisierung bei der
Konfiguration von kundenspezifischen Produkten.
11
1 Einleitung
(Piller u. a. 2003) Frank Piller, Michael Koch, Kathrin Möslein und Petra Schubert: Managing High
Variety - How to Overcome the Mass Confusion Phenomenon of Customer Co-Design. Proc. 3rd Annual
Conf. of the European Academy of Management (EURAM2003), Apr. 2003.
Allgemeine Überlegungen zur Anwendung von (automatischer) Personalisierung bei der Konfiguration
speziell auf den Kunden angepasster Produkte.
(Leckner u. a. 2003) Thomas Leckner, Michael Koch, Martin Lacher und Rosmary Stegmann: Personalization meets Mass Customization - Support for the Configuration and Design of Individualized
Products. Proc. Intl. Conf. on Enterprise Information Systems (ICEIS2003), Apr. 2003.
Entwurf eines Systems zur Unterstützung von Kunden bei der Auswahl individualisierter Güter. Neben dem Entwurf des Gesamtsystems wird vor allem auf Benutzerprofile, Produktmodelle und deren
Kombination zur Erzeugung personalisierter Empfehlungen eingegangen.
(Schubert und Koch 2003) Petra Schubert, Michael Koch: Collaboration Platforms for Virtual Student
Communities. Proc. Hawaii International Conference on System Science (HICSS-36), Jan. 2003.
Beschreibung der Unterstützung von Studierenden (durch mobile Schnittstellen) im Projekt Cosmos.
Darstellung aus Sicht von Personalisierung und Erhebung bzw. Nutzung von Benutzerprofilen.
(Koch u. a. 2002a) Michael Koch, Georg Groh, Christian Hillebrand, Natalie Fremuth: Mobile Support
for Lifestyle Communities. Arbeitspapier Nr.34 des Lehrstuhls für Allg. und Ind. Betriebswirtschaftslehre (AIB), Technische Universität München, ISSN 0942-5098, Nov. 2002.
Details zur Implementierung der Cosmos-Infrastruktur und zur Pilotierung im Bereich Lifestyle.
(Koch 2002b) Michael Koch, Georg Groh, Christian Hillebrand: Mobile Communities - Extending
Online Communities into the Real World. Proc. Americas Conf. on Information Systems (AMCIS2002),
Dallas, TX, Aug. 2002.
Beschreibung der Cosmos-Plattformen zur Unterstützung mobiler Communities in den Bereichen Lifestyle und Healthcare.
(Koch 2002e) Michael Koch: Interoperable Community Platforms and Identity Management in the
University Domain. International Journal on Media Management, 4(1), Jun. 2002, S.21-30.
Beschreibung verschiedener Community-Plattformen (und Möglichkeiten dazu) im Universitätsumfeld.
(Koch und Lacher 2001) Michael Koch, Martin S. Lacher: The Comovie Movie Recommender - An
Interoperable Community Support Application. Proc. Human-Computer Interaction International, New
Orleans, LA, Aug. 2001.
Beschreibung einer Plattform für Kino-Communities mit spezieller Berücksichtigung der Empfehlungskomponente mit kollaborativem Filtern.
(Koch u. a. 2001b) Michael Koch, Martin Lacher, Wolfgang Wörndl: The CommunityItemsTool - Interoperable Community Support in Practice. Proc. Workshop on Web-based Infrastructures and Coordination Architectures for Collaborative Entreprises (WETICE 2001), Cambridge, MA, Jun. 2001.
Beschreibung einer Wissensmanagement-Anwendung zum Austausch von Literaturreferenzen, Bookmarks und Kommentaren dazu in einer Community of Practice.
(Koch u. a. 2001c) Michael Koch, Martin Lacher, Wolfgang Wörndl: Das CommunityItemsTool - Interoperable Unterstützung von Interessens-Communities in der Praxis. Proc. 3. Liechtensteinisches
Wirtschaftsinformatik-Symposium, B. Britzelmaier, S. Geberl, S. Weinmann (Hrsg.), Vaduz, Liechtenstein, Mai 2001, Teubner, Stuttgart, S.147-157.
Beschreibung einer Wissensmanagement-Anwendung zum Austausch von Literaturreferenzen, Bookmarks und Kommentaren dazu in einer Community of Practice (Vorarbeit zu (Koch u. a. 2001b)).
12
Kapitel 2
Community-Unterstützung
„Internet-Communities sind keine Internet-Seiten, auf denen sich Menschen
treffen, sondern sie bestehen aus den Menschen, die sich dort treffen.“,
(Schmidt 2000, S.35)
In diesem Kapitel behandle ich das Thema Community und Community-Unterstützung. Ziel
dabei ist es herauszuarbeiten, was ein Community-Unterstützungssystem überhaupt ist, welche
Funktionalitäten dafür charakterisierend sind und welche Anforderungen an zukünftige Community-Unterstützungssysteme gestellt werden. Diese Anforderungen werden dann in den weiteren
Kapiteln aufgegriffen und daraus das neue Architekturkonzept für Community-Unterstützungssysteme hergeleitet.
Kapitelinhalt
2.1
2.1
2.2
Community aus unterschiedlichen Perspektiven . . . . . . . . . . . . . . . . . 13
Virtuelle Communities (Online-Communities) . . . . . . . . . . . . . . . . . . 21
2.3
2.4
Community-Unterstützungssysteme . . . . . . . . . . . . . . . . . . . . . . . . 23
Anforderungen an Community-Unterstützungssysteme . . . . . . . . . . . . . 29
Community aus unterschiedlichen Perspektiven
In den 1950er Jahren wurden knapp hundert verschiedene Definitionen für den Begriff „Community“
gezählt (Hillery 1955, S.118). Heute sind es dank der Einbeziehung elektronischer Kommunikationskanäle in das Bild und durch die Verwässerung des Begriffs in und über die Werbung sicher noch viel
mehr. Figallo drückt dies in folgendem Zitat sehr prägnant aus:
„I saw the word community being associated with so many different things that I began to wonder
if the idea was in danger of being watered down into meaningless jargon“. (Figallo 1998)
Einen ersten Eindruck dafür, was man unter „Community“ versteht, findet sich durch Nachschlagen
des Begriffs im Wörterbuch. In dictionary.com werden beispielsweise folgende Definitionen gegeben:
„A group of people living in the same locality and under the same government.“.
13
oder
„A group of people having common interests.“.
Im folgenden sollen diese Definitionen noch weiter untermauert werden, um eine Basis für die Ableitung von Unterstützungsmöglichkeiten zu gewinnen. Dazu betrachte ich verschiedene historische
und neuere Arbeiten rund um den Begriff „Gemeinschaft“. Nachdem Gemeinschaften im Kontext
von Computernetzen in einer Vielzahl bisheriger Publikationen rein aus dem Blickwinkel des sozialen Interaktionsinteresses gesehen werden (z.B. (Turkle 1995; Rheingold 1993; Stoll 1995; Schuler
1996; Parks und Floyd 1996; Hauben und Hauben 1997)) gebe ich im Folgenden zuerst einen sehr
knappen Überblick auf die Bedeutung des Begriffs in der Soziologie. Die Ausführungen orientieren
sich dabei teilweise an (Schubert 2000).
2.1.1
Gemeinschaften in der Soziologie
Der Begriff „Gemeinschaft“ ist in der Soziologie mit vielen unterschiedlichen Bedeutungen versehen. Die folgenden Basiskonzepte sind den meisten Definitionen gemeinsam: (1) „Gemeinschaften
handeln von Menschen“, (2) „sozialer Interaktion“ und (3) „gemeinsamen Bindungen“.
Weiterhin herrscht Einigkeit, dass ein menschliches Wesen, das einen normalen Sozialisierungsprozess durchlaufen hat, sich durch eine natürliche Affinität zu einer Gemeinschaft auszeichnet:
„The truth is that the world is made of people. People out of communities are like fish
out of water or plants out of soil.“ (Agre 2001)
Die Mitgliedschaft in einer oder mehreren sozialen Gruppen ist für die meisten Menschen ein wesentlicher Bestandteil ihres Lebens.
Gemeinschaft und Gesellschaft
Bis der Soziologe Ferdinand Tönnies 1887 die Unterscheidung zwischen Gemeinschaft und Gesellschaft aufbrachte (Tönnies 1991), wurde der Begriff der Gemeinschaft lange Zeit als zentrales Element sozialer Netzwerke angesehen. Tönnies beschreibt, dass sich das Individuum in der modernen
Gesellschaft immer in zwei Typen sozialer Bindung befindet. Zum einen in einer Verbindung, die
durch gewachsene Strukturen und Zugehörigkeitsgefühl geprägt ist: Familie, Nachbarschaft, Volk.
Diesen Typus nennt Tönnies „Gemeinschaft“. Dagegen steht die „Gesellschaft“, ein Bindungstyp,
der vor allem durch Nutzenüberlegungen bestimmt wird: Ökonomische und politische Verbindungen, Vereine und Versammlungen.
Tönnis beschreibt also Gemeinschaft als einen organischen Sinn von Gemeinsamkeiten, Kameradschaft und Familie, zusammengehalten durch Verständnis, Konsens und Sprache. Nach Tönnies ist
Gemeinschaft überall dort vorhanden, „wo immer Menschen in organischer Weise durch ihren Willen miteinander verbunden sind und einander bejahen“. Gesellschaft stellt er dem gegenüber als
Hyperindividualismus dar, in welchem Beziehungen zwischen Leuten mechanisch, transitorisch und
kontraktorieniert sind. Die Gemeinschaft stiftet für ihre Mitglieder Geborgenheit und Schutz, verpflichtet sie jedoch auch moralisch, etwas für sie zu leisten. Eine rein passive Haltung, also ein
Herumlungern (engl. „lurking“) wird in der Regel nicht toleriert.
Eine ähnliche Haltung vertritt auch Dyson (1997), die zwischen „Community“ und „Culture“ unterscheidet. Sie schreibt:
14
2.1 Community aus unterschiedlichen Perspektiven
„Communities often have a culture, but there is an important disctinction between culture
and community. Culture is a set of rules, perceptions, language, history, and the like. It is
embodied in books and songs, pleople’s mind, and websites [..] By contrast, a community
is a set of relationships.“ (Dyson 1997)
Dyson führt als weitere Eigenschaft, die eine Community ausmacht „die menschliche Interaktion“
an. Eine Gemeinschaft hängt von den Menschen ab, die sie formen. Sie ist nicht passiv sondern
ihre Mitglieder investieren in ihre Existenz. Um ein Mitglied zu sein, muss man in der Gemeinschaft
präsent sein, zu ihr beitragen und den anderen Mitgliedern bekannt sein.
Gemeinschaft als soziales Netzwerk
Van Vliet und Burgers (1987) beschreiben Gemeinschaften als Zusammenwirken der konstituierenden Elemente „soziale Interaktion“ und ein gemeinsames „Werte- und Symbolsystem“. Der Mensch
strebt in seinem Inneren nach Ordnung. Er bewegt sich lieber im gesicherten Gefüge einer Gruppe
bekannter Menschen als alleine als Individuum. Ein heute zu beobachtender Trend ist die Abnahme
in der Anzahl an Communities. Dieser Wegfall der sozialen Gemeinschaft ist begleitet von einem
steigenden Bedürfnis nach Ersatz-Gemeinschaften (z.B. realisiert über elektronische Medien).
Schubert (2000) greift die Beschreibung von van Vliet und Burgers auf und definiert:
„Gemeinschaften sind Zusammenschlüsse von Mitgliedern mit übereinstimmenden Moralund Zielvorstellungen, die auf der Grundlage eines institutionellen Rahmenwerks (implementierte Organisation (Protokolle, Rollen)) in einem gemeinsamen semantischen Raum
(gemeinsames Werte- und Symbolsystem (Sprache)) miteinander in Beziehung treten (Interaktion).“ (Schubert 2000, S.72)
Bei den für die Herausbildung einer Community notwendigen Übereinstimmungen (Gemeinsamkeiten) zwischen den Mitgliedern wird häufig zwischen verschiedenen Typen unterschieden. Schuler
(1996) unterscheidet hier beispielsweise drei verschiedene Arten von Gemeinschaften:
Gemeinschaften aufgrund geographischer Zusammengehörigkeit
Gruppen mit gemeinsamen Interessen (Interessensgemeinschaften)
Zusammenhalt von Gruppenmitgliedern durch Gemeinschaftsgefühl
Dies wurde nicht immer so gesehen. In frühen Arbeiten wurde hier meist nur die geographische
Zusammengehörigkeit (gemeinsame geographische Umgebung) diskutiert (Hillery 1955). Erst in
neueren Arbeiten verliert der gemeinsame Ort als charakterisierender und einigender Faktor immer
mehr an Bedeutung. Stattdessen werden persönliche Beziehungen, über die Menschen miteinander
verwoben sind, immer wichtiger. Nicht mehr Orte, sondern soziale Netzwerke, basierend auf gemeinsamen Interessen, werden als Grundlage für Communities gesehen. Wellman und Gulia meinen
hierzu in (Wellman und Gulia 1999):
„... communities do not have to be solidary groups of densely knit neighbors but could
also exist as social networks on kin, friends, and workmates who do not necessarily live
in the same neighborhoods.“
15
Carotenuto u. a. (1999) definieren Community ähnlich, aber mit leicht unterschiedlichem Fokus:
„A community is a voluntary association of people who are not directly dependent on
each other for success.“
Auch wenn die Mitglieder einer Community nicht direkt voneinander abhängig sind, identifizieren
viele Autoren „gemeinschaftliches Handeln“ als wichtiges, dem „sozialen Netzwerk“-Aspekt entstammendes Charakteristikum von Communities. So sieht auch Wenger (1998) bei Communities
gemeinsame Handlungen und das Lernen bei diesen Handlungen als die zentralen Elemente an:
„Members of a community are informally bound by what they do together from engaging
in lunchtime discussions to solving difficult problems and by what they have learned
through their mutual engagement in these activities.“
Wenger beschreibt Communities also nicht anhand von Eigenschaften, sondern legt einen Grund für
den Zusammenschluss von Personen zu einer Community dar: Gemeinsame Aktivitäten sowie der
daraus resultierende Lernerfolg für den Einzelnen.
Diese Definition ist mit dem von Wenger geprägten „Community of Practice“-Konzept verbunden.
Basierend auf diesen Konzept kann auch folgende Beschreibung gewählt werden: Communities als
„informelle Personengruppen oder -netzwerke, die aufgrund gemeinsamer Interessen und/oder Problemstellungen über einen längeren Zeitraum hinweg miteinander kommunizieren, kooperieren, Wissen und Erfahrungen austauschen, neues Wissen schaffen und dabei voneinander lernen.“
Diese Charakterisierung einer Community als eine Gruppe von Personen, die sich im Rahmen eines
gemeinsamen Kontextes (gemeinsames Thema, gemeinsamer Ort) gegenseitig helfen, greift auch
Greenspun (1999) auf wenn er definiert „A community is a group of people with varying degrees of
expertise in which the experts attempt to help the novices improve their skills“.
Identität und Gewahrsein
Schon im Abschnitt zu Gemeinschaft und Gesellschaft wurden Interaktion und Identität als Schlüsselfunktionen sozialer Gemeinschaften herausgestellt. Identität ist dabei aus soziologischer Sicht
das „dauernde innere Sich-Selbst-Gleichsein, die Kontinuität des Selbsterlebens eines Individuums,
die im wesentlichen durch die dauerhafte Übernahme bestimmter sozialer Rollen und Gruppenmitgliedschaften sowie durch die gesellschaftliche Anerkennung als jemand, der die betreffenden Rollen
innehat bzw. zu der betreffenden Gruppe gehört, hergestellt wurde“ (Köhntopp 2000). Die Mitglieder
einer Gemeinschaft müssen also miteinander interagieren, anderen Mitgliedern (partiell) bekannt sein
und ihre Identität in der Gemeinschaft durch Kontinuität bewahren.
Fehlende oder unausgeglichene Interaktion und Präsenz den anderen gegenüber führt zu einem nach
Außen gerichteten Verlangen oder psychischer Beklemmung. Identität hilft einer Person, sich im
sozialen Gefüge einzuordnen, was den Kontext oder Ankerpunkt für ihr Benehmen und Handeln
bildet.
Ishida (1998) stellt beispielsweise als charakteristische Eigenschaft von Communities das Wir-Gefühl
in der Community heraus, also eine Art Bewußtsein über die Existenz der Community. Auch Mynatt
u. a. (1997) betonen neben der Interaktion das Mitgliedschaftsgefühl und die Grenzen:
16
„[A community] is a social grouping which exhibit in varying degrees: shared spatial
relations, social conventions, a sense of membership and boundaries, and an ongoing
rhythm of social interaction.“ (Mynatt u. a. 1997, S.211)
Das Bewußtsein über die Existenz der Community ist eng verbunden mit dem Bewußtsein über die
Existenz und Identität anderer Community-Mitglieder. Das klassische Gruppen-Gewahrsein (group
awareness) spielt also auch bei Communities eine wichtige Rolle (Schlichter u. a. 1998).
Beim Thema Identität ist auch das Thema Anonymität anzusprechen. Nicht wenige Autoren sehen
die durch Anonymität erreichte Senkung der Hemmschwelle zur Kontaktaufnahme als die Chance zu
einem wahren Miteinander im Internet an. Die Vorteile von Anonymität sind unbestritten. Allerdings
behindert Anonymität zugleich eine wirkungsvolle soziale Kontrolle sowie den Aufbau von sozialen Bindungen zwischen Community-Mitgliedern. Ebenso ist es nur schwer möglich, Beiträge von
anonym agierenden Community-Mitgliedern einzuschätzen. Donath u. a. (1999) schreibt hierzu:
„For assessing the reliability of information and the trustworthiness of a confidant, identity is essential. And care of one’s identity, one’s reputation is fundamental to the formation of community.“
In vielen Communities (speziell in solchen, die sich nicht direkt treffen) hat sich aus diesen Gründen
eine Mittelweg etabliert. Die Mitglieder sind in der Community unter einem eindeutigen Pseudonym
bekannt, das aber nicht unbedingt einen Rückschluss auf ihre wirkliche Identität zulässt.
Rollen in Communities
Der amerikanische Autor Gladwell (2000) nähert sich der Charakterisierung von Communities von
einer Rollen-basierten Sichtweise. Er geht u.a. auf die Informationsübermittlung und Zusammenarbeit in Communities ein und nennt drei wichtige Typen von Rollen für Community-Mitglieder:
Mavens, Salesmen und Connectors. Vorweggenommen sei hier schon erwähnt, dass die drei Rollen meist nicht zur klaren Kategorisierung der Mitglieder einer Community herangezogen werden
können. Häufig deckt ein und dieselbe Person mehrere Rollen ab. Die Rollen sind aber sehr hilfreich, wenn es darum geht zu reflektieren, wie der Wissensaustausch in und zwischen Communities
funktioniert und welche Unterstützungsmöglichkeiten dafür angeboten werden könnten und sollten.
Weiterhin sei vorausgeschickt, dass die von Gladwell herausgearbeiteten Rollen auf einer anderen
Ebene zu sehen sind als die in Kapitel 4 behandelten Benutzerrollen. Während es sich bei letzterem
um ein Hilfmittel zur Definition von Zugriffsrechten handelt, fassen die Rollen von Gladwell wichtige
Aufgaben und Kommunikationsmuster bei der Interaktion in Communities zusammen.
Mavens
Mit „maven“ (engl. für „Kenner“) sind die Mitglieder einer Community gemeint, die in einem bestimmten Bereich Expertenwissen besitzen. Das sind z.B. die Personen, die man fragt, wenn man
eine Kaufentscheidung treffen will.
Salesmen
Diese Rolle sorgt dafür, dass die Tipps von Mavens zur Meinung einer größeren Masse von Menschen werden. Salesmen (engl. für „Verkäufer“) besitzen vielleicht kein Expertenwissen, können
aber Empfehlungen so begeistert weitergeben, dass sie von den Empfängern gerne aufgenommen
werden.
17
Information
Community A
Maven
Connector
Maven
Information
Salesman
Maven
Community B
Information
Abbildung 2.1: Mavens als Informationsentdecker und Salesmen als Verteiler in einer Community,
Connector als Schnittstelle zwischen Communities
Im Gegensatz zum Maven weiß der Salesman nicht, welche Produkte wirklich unter bestimmten
Kriterien die Besten sind. Wenn er aber von einem Produkt begeistert ist (und dazu muss er es noch
nicht einmal gekauft haben), dann wird er dies weitererzählen und seine Begeisterung weitertragen.
Connectoren
Zu guter letzt braucht man noch Personen, die Trends aus einer Community heraus in eine andere
tragen. Connectoren sind dazu in verschiedenen Gruppen und wandeln Information aus einer Gruppe
in Informationen um, die für die andere Gruppe relevant ist.
Den Connector macht nicht nur aus, dass er Mitglied in den verschiedenen Gruppen ist, sondern
er muss auch die Fähigkeit haben, Leute und Ideen aus den verschiedenen Bereichen zusammen zu
bringen.
Gruban (2001) beschreibt in diesem Zusammenhang folgendes Beispiel: Hat sich durch Mavens und
Salesmen in einer Gruppe von Technikbegeisterten herumgesprochen, dass ein bestimmtes Mobiltelefon besonders interessante Funktionen hat, so bleibt diese Information zunächst in dieser Gruppe.
Bekommt aber der Connector mit, dass sich in der Theatergruppe jemand ein Mobiltelefon kaufen
will, so besinnt er sich auf die Gespräche in der Technikgruppe und empfiehlt demjenigen ein Gerät,
das auf seine Anforderungen – im Gegensatz zu den Spielereien, die einem Techniker wichtig sind –
passt.
Auf Communities bezogen heißt das, dass es Personen geben muss, die Information von draußen in
die Community hinein tragen, diese aber so anpassen, dass sie für die Mitglieder relevant sind. Diese
Aufgabe übernehmen Connectoren, die gleichzeitig wiederum Erfahrungen aus der Community in
andere Communities mitnehmen.
Mit der Rolle der Connectoren wurde auch schon der Umstand angesprochen, dass Communities
keine voneinander isolierten Inseln darstellen. Normalerweise ist eine Person Mitglied in mehr als
einer Community und kann damit als Connector den Wissensaustausch zwischen den Communities
unterstützen. Die Mitgliedschaft in mehreren Communities wirft aber auch Anforderungen an die
Unterstützung von Communities auf. Wir werden diesen Aspekt am Ende dieses Kapitels nochmal
aufgreifen.
18
2.1.2
Gemeinschaften aus technischer Sicht
Neben diesen, sehr auf „Mensch und Gesellschaft“ konzentrierten Definitionsversuchen für den Community-Begriff, gibt es auch noch „technischere“ Definitionen, die Community allgemein als eine
Menge von Agenten mit einem gemeinsamen Protokoll beschreiben.
Lechner u. a. (2001) schreiben dazu beispielsweise:
„Eine Gemeinschaft wird - aus technischer Sicht betrachtet - durch ein Medium und eine
Menge von Agenten konstituiert und ist charakterisiert durch den logischen Raum mit
Syntax und Semantik, durch ein Kanalsystem für den Transport von Informationen und
eine Organisation mit Rollen und Protokollen. Die Nachrichten, die ausgetauscht werden, dienen dem Austausch von Wissen, der (unverbindlichen) Kommunikation von Absichten, der Verhandlung von Verträgen und der Erfüllung von Verträgen. Unter Agenten
verstehen wir Menschen, Softwareartefakte und alle organisatorischen Einheiten, die auf
einem Markt auftreten können.“
Eine technische Motivation haben auch konstruktive Definitionen des Begriffs Community anhand
von konkreten Aktivitäten, die zwischen den Community-Mitgliedern bzw. Agenten stattfinden. Entsprechend der Grunddefinition von Community steht hier das gemeinschaftliche Handeln zuoberst.
Um gemeinschaftlich Handeln zu können, müssen die Community-Mitglieder miteinander kommunizieren. Dazu müssen sie geeignete Kommunikationspartner identifizieren und dann die Kommunikation mit den Kommunikationspartner abwickeln. Nach dieser Betrachtung stellt eine Community
einen Kontext dar, in dem das Finden von Interaktionspartnern und die Abwicklung von Interaktion
zur Durchführung von partiellem gemeinschaftlichem Handeln möglich wird.
Solche Definitionen erlauben einen einfachen Übergang zu Anforderungen an Unterstützungstechnologie (worauf wir später in diesem Kapitel auch noch zurückkommen werden).
2.1.3
Kategorisierungen zu Communities
In einschlägigen Arbeiten zu Community-Unterstützung wird immer wieder versucht, die Menge
möglicher Communities anhand einiger Hauptcharakteristika in verschiedene Typen zu unterteilen
und für diese Typen dann spezielle Unterstützungslösungen zu definieren. In (Carotenuto u. a. 1999)
werden beispielsweise die beiden Charakteristika „Fokus“ und „Gemeinsamkeiten“ herausgegriffen.
Beim Fokus wird unterschieden zwischen einem engen Fokus und einem breiten Fokus, bei den
Gemeinsamkeiten werden die beiden Ausprägungen „gemeinsame Aktivitäten“ und „gemeinsamen
Interessen“ berücksichtigt.
Diese Unterscheidung führt zu folgenden Typen von Communities 1 :
Community of Interest (gemeinsame Interessen und breiter Fokus)
Community of Practice (gemeinsame Aktivitäten)
Community of Purpose (gemeinsame Interessen und enger Fokus)
1
Zusätzlich zu den hier aufgelisteten drei Community-Typen wird in (Carotenuto u. a. 1999) als Verfeinerung der ’Community of Purpose’ noch der Typ ’Community of Passion’ eingeführt.
19
Community of Interest (COI)
Communities of Interest haben einen diffusen Fokus auf eine Menge gemeinsamer Interessen. Eine
solche Community bündelt also Personen mit Wissen über und Interessen an bestimmten breit gefassten Themengebieten. Die Hauptmotivation für die Mitgliedschaft ist es über ein Themengebiet auf
dem Laufenden zu bleiben, Informationen im Kontext der Interessen auszutauschen und Wissensträger zu identifizieren Ishida (1998).
Community of Purpose
Von Community of Purpose spricht man, wenn es einen engen Fokus auf ein gemeinsames Interesse
gibt. Im Gegensatz zur Community of Interest steht hier nicht das allgemeine Gewahrsein über die
Entwicklungen in einem breiten Themengebiet im Vordergrund, sondern meist die (gegenseitige)
Erfüllung ganz konkreter (Informations-)Bedürfnisse. Beispiele für solche konkreten Bedürfnisse
sind die Organisation gemeinsamer Veranstaltungen oder die Erstellung gemeinsamer (Software-)
Produkte.
Community of Practice (COP)
Im Gegensatz zur Community of Interest besteht die Gemeinsamkeit bei der Community of Practice
nicht nur aus einem gemeinsamen Interesse, sondern aus Aktivitäten, die gemeinsam durchgeführt
werden oder aus gleiche Aktivitäten, welche die Community-Mitglieder (mehr oder weniger) unabhängig voneinander durchführen.
Die Grunddefinition zu Community of Practice stammt von E. Wenger:
„In a nutshell, a community of practice is a group of people who share an interest in a domain of
human endeavor and engage in a process of collective learning that creates bonds between them:
a tribe, a garage band, a group of engineers working on similar problems.“. (Wenger 1998)
Wenger nennt drei essentielle Charakteristika für Communities of Practice:
das Fachgebiet (the domain)
Es gibt ein Minimum an Wissen, das eine Person haben muss, um Mitglied zu sein. Personen mit zu geringem Wissen über das Fachgebiet können den Austauschprozess nicht sinnvoll
unterstützen.
die Gemeinschaft (the community)
Die einzelnen Personen teilen ihr Wissen mit den anderen und sie unterstützen einander beim
Wissenserwerb. Das macht sie zu einer Gemeinschaft.
die Aktivität (the practice)
Die Mitglieder haben sich um eine Aktivität herum eine gemeinsame Wissensbasis zur praktischen Problemlösung geschaffen. Dabei kann es sich z.B. um Erfahrungsberichte, Werkzeuge
oder Vorgehensweisen handeln.
Für Communities of Practice reicht also das relativ unscharfe Ziel und der Willen zum gemeinsamen
Wissenerwerb aus.
20
2.2 Virtuelle Communities (Online-Communities)
2.1.4
Zusammenfassung und Konsolidierung
Allen hier angesprochenen Definitionen ist gemeinsam, dass sich Menschen freiwillig zusammenschließen, um gegenseitig von der Gemeinschaft mit anderen auf die eine oder andere Art zu profitieren. Die Community bildet ein Netzwerk zwischen Menschen, das sich durch eine (wie auch
immer geartete) Gemeinsamkeit der Mitglieder sowie der Interaktion zwischen ihnen definiert. Dieses soziale Netzwerk bildet die Grundlage für gemeinsame Aktivitäten, für das Lernen in der Gruppe,
etc.
Giorgio de Michelis hat die Ideen zu Community in Referaten auf der i3 Summerschool in Ivrea
(August 2001) und auf der Dienstleistungstagung des BMBF (Oktober 2001, (de Michelis 2001))
sehr gut zusammengefasst. Er sieht eine Community vom Standpunkt des Wertes, den sie für ihre
Mitglieder hat: „A community is where social value is created“. Diesen Wert sieht er in
(1) „social ties consituting a flexible and diversified help network“ und
(2) „shared knowledge and memory creating a strong social identity“.
Eine Community stellt also eine soziale Identität zur Verfügung, bietet einen Platz zum Leben und
zum Lernen und stellt ein Hilfsnetzwerk zur Verfügung.
Von Seiten der Soziologie sagt de Michelis weiterhin:
„A community is a social aggregate, whose members share an experience, a practice, a
tradition, a place, and a language.“
Wichtig sind ihm dabei vor allem die gemeinsame Sprache und Traditionen (gemeinsame Historie),
sowie das Gewahrsein eines gemeinsamen Platzes. Diese Definition knüpft eng an die technische
Definitionen von Lechner u.a. im vorherigen Abschnittes an. Bei Lechner u.a. war der gemeinsame
Platz durch ein Kanalsystem für den Transport von Informationen, die gemeinsame Sprache durch
einen (gemeinsamen) logischen Raum mit Syntax und Semantik definiert.
In dieser Arbeit soll keine neue Definition von Community eingeführt werden, sondern hauptsächlich
auf die eben genannten Schwerpunkte von de Michelis Bezug genommen werden. Diese Charakterisierung als Netzwerk zum Informationsaustausch und zur gegenseitigen Hilfe, mit Grenzen und
Gemeinsamkeiten der Mitglieder sowie mit Identität und Awareness eignet sich sehr gut dazu, aktuelle Entwicklungen zu beschreiben und Funktionalitäten für Unterstützungswerkzeuge abzuleiten.
2.2
Virtuelle Communities (Online-Communities)
„If it’s there and you can see it it’s REAL
If it’s there and you can’t see it it’s TRANSPARENT
If it’s not there and you can see it it’s VIRTUAL
If it’s not there and you can’t see it it’s GONE!“
Der Begriff „Virtual Community“ geht auf H. Rheingold zurück. Er stellt in seinem 1993 erschienenen gleichnamigen Buch erstmals eine Beziehung zwischen dem Virtuellen der Mailboxen bzw. des
Internets und dem Begriff Community her (Rheingold 1993). Rheingold beschreibt Diskussionen einer kleinen Gruppe von Menschen mit Zugang zu Online-Systemen über verschiedene Themen. Jede
Themengruppe hatte ihren eigenen Bereich und so wurden die ersten Communities geboren, die sich
nur aus ihrer Diskussion über vernetzte Rechner kannten.
21
Die Grundidee der Virtuellen Community ist aber schon so alt wie die Vernetzung von Rechnern
selbst. J.C.R. Licklider, der die Idee vom Internet entscheidend prägte, schrieb bereits in den 1960ern:
„... life will be happier for the on-line individual because the people with whom one
interacts most strongly will be selected more by commonality of interests and goals than
be accidents of proximity.“ (Licklider und Taylor 1968)
David Bohnett, einer der Mitbegründer von GeoCities – eine der größten Plattformen für virtuelle
Gemeinschaften – definiert den Begriff der virtuellen Gemeinschaft folgendermaßen:
„Wir definieren eine Gemeinschaft durch vier Komponenten: erstens das gemeinsame Interesse, zweitens das positive Feedback, entweder psychologisch oder ökonomisch (das
positive Feedback, das aus dem Einstieg und der Teilnahme an der Gemeinschaft entsteht), drittens die ökonomische Infrastruktur, die den Erhalt und das Wachstum der Gemeinschaft unterstützt, und viertens Mechanismen, die bestimmen, wie sich Mitglieder
in die Gemeinschaft einbringen sollen und müssen. Der letzte Punkt ist meiner Meinung
nach auch der Lackmustest, ob man eine Site wirklich als Community bezeichnen kann.“
(Krempl 1998)
Carotenuto u. a. (1999) beschreibt Virtuelle Communities schließlich als Communities, in denen der
überwiegende Teil der Kommunikation und Interaktion zwischen den Community-Mitgliedern mittels elektronischer Medien stattfindet. Synonym zu dieser technischen Definition wird häufig auch
der Begriff „Network Community“ benutzt. So beschreiben Carroll u. a. (1996) eine Network Community als: „a group of people whose communication and collaboration over networks strengthens
their shared goals and concerns.“.
Während die bisher erwähnten Arbeiten Virtuelle Communities rein aus der Sicht der Stärkung oder
Ermöglichung beliebiger Gemeinschaften sehen, beschäftigen sich andere Arbeiten speziell mit Virtuellen Communities als Modell zur Unterstützung von Beziehungen zwischen Verkäufern und Käufern im Electronic Commerce (Armstrong u. a. 1995; Hagel und Armstrong 1997; Figallo 1998; Lechner u. a. 1998; Schubert und Koch 2002).
Bei Virtuellen Communities handelt es sich also um Communities, deren Mitglieder nur oder zumindest überwiegend über elektronische Kommunikationsmittel kommunizieren.
Trotz der grundlegend gleichen Definition gibt es einige wichtige Unterschiede zwischen realen und
virtuellen Gemeinschaften:
Im Gegensatz zu realen Gemeinschaften unterliegen virtuelle Gemeinschaften Einschränkungen in der Kommunikation. Da ihre Mitglieder größtenteils rein textorientiert kommunizieren
(kein Audio und kein Video), können einige Elemente der menschlichen Kommunikation, die
nonverbalen Elemente wie z.B. Gesten und Gesichtsausdrücke, nicht übertragen werden. Um
dies abzumildern werden ersatzweise in den Text eingebettete Symbole, sogenannte Emoticons, verwendet.
Die Textbasiertheit, verbunden damit, dass die Mitglieder nur sehr selten Details zu ihrer realen
Identität preisgeben müssen, hat den Nebeneffekt, dass viele Merkmale der Mitglieder wie z.B.
Aussehen, Alter, Aussprache, Geschlecht, gesellschaftliche Stellung und Umfeld, Bildungsstand, die in realen Gemeinschaften oft gruppenbestimmend sind, in virtuellen Gemeinschaften nur eine untergeordnete Rolle spielen. Damit ergibt sich gegenüber realen Gemeinschaften
eine Art von Anonymität (Wood und Smith 2001), die sowohl positiv als auch negativ wirken
kann (siehe hierzu auch den Abschnitt zu Identität und Gewahrsein auf S.16).
22
2.3 Community-Unterstützungssysteme
Eine Grundvoraussetzung für das Funktionieren einer Gemeinschaft ist ein starkes Gruppenbewußtsein, die sogenannte „Group Awareness“. Gruppenbewußtsein wird in erster Linie durch
die Kenntnis der Zusammensetzung der Gruppe bei jedem Mitglied erreicht. In realen Gemeinschaften mit angemessener Größe ist diese Kenntnis aufgrund des direkten Kontakts selbstverständlich. In virtuellen Gemeinschaften wird meist versucht mit Hilfe von Listen und Profilen
der anwesenden Mitglieder diese Problematik zumindest teilweise zu kompensieren.
Die moderne Kommunikationstechnik ermöglicht es virtuellen Gemeinschaften, im Gegensatz
zu realen, über sehr große Distanzen hinweg zu existieren und funktionieren. Der geographische Standort der einzelnen Mitglieder ist in virtuellen Gemeinschaften größtenteils unwichtig.
Einzige Voraussetzung ist ein Netzzugang am jeweiligen Standort des Mitglieds. Auf Basis der
zunehmenden mobilen Kommunikationstechnik ist nicht nur der Standort unwichtig, es wird
desweiteren möglich gleichzeitig mobil zu sein und an Gemeinschaften teilzunehmen. Virtuelle Gemeinschaften sind somit gegenüber realen Gemeinschaften orts- und zeitunabhängig.
Durch die damit erreichte größere Reichweite werden manche Gemeinschaften erst möglich.
Ein Beispiel hierfür sind Communities von Personen, die an seltenen Krankheiten leiden. Hier
findet sich häufig in weitem Umkreis um den Wohnort keine andere Person mit demselben
Leiden (Leimeister u. a. 2002, 2003).
Der Einsatz von vernetzten Rechner zur Unterstützung von Communities wird vielfach noch mit dem
„Schaffen“ von rein virtuellen Gemeinschaften gleichgesetzt. Betrachtet man allerdings konkrete Anwendungsfälle, dann findet man meist Gemeinschaften, die größtenteils ohne Rechnerunterstützung
miteinander interagieren und die Anwendungen auf vernetzten Rechensystemen (z.B. dem Internet)
lediglich zur Unterstützung und Bereicherung ihrer Interaktion einsetzen. Auch bei Communities,
die als rein virtuelle Community begonnen haben, entwickeln sich häufig Tendenzen sich persönlich
zu treffen. Der Bereich der Community-Unterstützung umfasst also mehr als die Bereitstellung von
Portalen für weit verteilte Gruppen.
2.3
Community-Unterstützungssysteme
Der Begriff „Community“ steht für Gruppen von Personen, die Gemeinsamkeiten haben und sich gegenseitig unterstützen. Die Idee hinter Community-Unterstützung ist es erstens, diesen Gruppen eine
Möglichkeit zur (orts- und zeitunabhängigen) Kommunikation zu geben, und zweitens, die Kenntnis
von Existenz und Zusammensetzung dieser Gruppen zu nutzen, um die Mitglieder der Community
oder andere Personen bei individuellen oder kollaborativen Aufgaben zu unterstützen.
Generell sind sowohl für stationäre als auch mobile Communities gewisse Dienste von besonderem
Interesse, die in engem Zusammenhang mit den Merkmalen stehen, die solche Communities definieren. In diesem Abschnitt geben wir zuerst eine Übersicht über Community-Unterstützung und
Unterstützungswerkzeuge und betrachten dann, welche Dienste zur Community-Unterstützung benötigt werden.
2.3.1
Historie
Community-Unterstützung begann nicht erst mit der Verfügbarkeit vernetzter Computer. Unterstützung für die Bildung und Pflege einer Community kann allgemein in klassische, nicht durch (vernetzte) Rechner unterstützte Ansätze wie private Briefe, Flugblätter, (Mitglieder-)Zeitschriften, Schwarze
23
Bretter, spezielle Radio- und Fernsehprogramme, und Ansätze, die auf vernetzten Rechnern basieren
(Bulletin Boards, MUDs, MOOs, Community-Netzwerke), unterteilt werden.
Beide Varianten der Community-Unterstützung haben Vorteile und Nachteile. Der klassische Ansatz
zeichnet sich durch Verfügbarkeit, Vertrautheit und Einfachheit der Nutzung aus. Für elektronische
Medien spricht die Dynamik, die Geschwindigkeit, die Leichtigkeit der Replikation und Verteilung
sowie die potentielle Reichweite. Nachteile sind die Nutzungsbarrieren, Probleme mit dem Zugriff
und eine geringe Verfügbarkeit.
Die Nutzung vernetzter Rechner zur Unterstützung von Communities kann in die Anfänge des Internet zurückverfolgt werden. Der zweite Dienst des Internet-Vorläufers Arpanet, der File-TransferService (FTP), wurde bald nachdem er verfügbar war „missbraucht“, um asynchrone Nachrichten von
einer Person zur anderen zu übertragen – E-Mail war erfunden. Mailinglisten folgten und bald waren
Foren-Dienste (Newsgroups) verfügbar – sowohl im Arpanet als auch auf alternativen Netzwerken,
die durch lose gekoppelte Rechner gebildet wurden (z.B. FidoNet).
Besonders hervorzuheben sind hier die Entwicklungen der sogenannten Community-Netzwerke. Diese sind in den 1980er Jahren in USA in Form von Bulletin-Board Systemen entstanden. Eine Besonderheit daran war, dass die Zielgruppe nicht eine homogene Gruppe von Technikbegeisterten war,
sondern eine durch räumliche Zusammengehörigkeit (Nachbarschaft) definierte Gruppe von „Normalbürgern“. Aus diesem Grund bestanden die Dienste der Community-Netzwerk-Betreiber nicht
nur aus der Bereitstellung und Moderation der Bulletin-Boards, sondern auch aus Unterstützung beim
Zugang zu den Systemen oder zum Internet.
Schuler (1995) beschreibt Community-Netzwerke folgendermaßen:
„Community networks are an attempt to use computer network technology to address the
needs of the community.“
Ein Community-Netzwerk wird also klar als Werkzeug gesehen, das eine bestehende, reale Community unterstützen soll. Als frühe Beispiele für Community-Netzwerke seien Big Sky Telegraph
genannt, das die Kommunikation zwischen Lehrern in den ländlichen Gegenden von Montana, USA,
unterstützte, oder das Public Electronic Network (PEN) in Santa Monica, USA, das den Bürgern
von Santa Monica einen Online-Zugang zur Stadtverwaltung bereitstellte. Ein weiteres oft zitiertes
Beispiel ist das Seattle Community Network (www.scn.org).
In Europa entstanden erste Community-Netzwerke Anfang der 1990er Jahre. Besonders zu erwähnen
ist hier „de digitale Stad Amsterdam“ (1994) und das Milano Civic Network.
Seit dem Siegeszug des World-Wide-Web entwickeln sich viele der bisher auf proprietärer ClientSoftware basierenden Bulletin-Board-Systeme und Community-Netzwerke zu Web-basierten Diensten.
Auch sind viele neue Plattformen mit ähnlichen Funktionalitäten (d.h. Publikation von Beiträgen und
von Kommentaren zu Beiträgen, Chat) entstanden. Weiterhin haben sich verschiedene andere Anwendungsklassen und nicht-Web-basierte Dienste entwickelt deren Haupt- oder Nebenziel die Unterstützung von Communities ist.
2.3.2
Anwendungsklassen
Bei Community-Unterstützungssystemen auf Basis vernetzter Rechner kann man verschiedene Anwendungsklassen identifizieren. News- und Chat-Systeme stellen einen Treffpunkt und ein Kommunikationsmedium bereit. Buddylist-Systeme liefern detaillierte Awareness-Information. OnlineCommunities bieten einen Ort zum Kommunizieren und eine breite Palette an Funktionalität, um
24
Community-Information zu publizieren und abzufragen. Recommender-Systeme nutzen Benutzerprofile und Bewertungen, die Benutzer vergeben haben, um Empfehlungen zu berechnen. Andere
Systeme konzentrieren sich auf das Finden von Experten oder auf explizites Matchmaking.
News- und Chat-Systeme
Diese Systeme gibt es schon seit den Anfängen der Vernetzung von Rechnern. Es handelt sich um
(Verteilte) Anwendungen, in denen (synchron oder asynchron) textbasierte Diskussionen zu bestimmten Themen (Interessensbereiche) geführt werden können. Eines der ersten und immer noch stark
genutzten asynchronen Systeme dieser Art ist „Usenet News“. Bei synchronen Plattformen ist das
System IRC (Internet Relay Chat) das Bekannteste. Ein Beispiel für eine neuerere (Web-basierte)
asynchrone Plattform ist unter www.communityware.com zu finden. Die Anwendungen unterstützen
sowohl den Austausch von Information als auch das Matchmaking über Awareness, da man durch
nicht anonyme Beiträge auf andere Community-Mitglieder aufmerksam werden kann, um dann direkt mit ihnen in Kontakt zu treten.
Als ältesten Community-Dienst im Internet finden sich bei den News- und Chat-Systemen auch die
breitesten Architekturvarianten. Das Spektrum reicht von Systemen, die nur auf einem (Web-)Server
zugänglich sind, bis hin zu einer Internet-weiten Vernetzung verschiedener Server wie bei UsenetNews oder IRC. Für die weltweit verteilten Dienste gibt es inzwischen auch verschiedene Lösungen
zur Integration in Web-Umgebungen (z.B. Google Groups, www.google.de). Eine interessante Zwischenlösung ist weiterhin das Coolboard Community System (www.coolboard.com). Hier werden
zwar eigenständige Bulletin-Boards auf unterschiedlichen Web-Servern eingerichtet, verschiedene
Boards können aber verbunden werden. Immer wenn eine Nachricht auf einem Board publiziert
wird, erscheint sie auch auf den anderen damit verbundenen Boards.
Buddylist-Systeme
Hierunter versteht man Systeme, die einem nach dem Anmelden anzeigen, welche seiner Kollegen
oder Freunde gerade online erreichbar sind. Diese Werkzeuge liefern also Awarenessinformation
zu den Mitgliedern einer meist explizit definierten Community oder eines Teams. Oft wird noch
zusätzliche Information zur Erreichbarkeit der Personen angegeben, z.B. ob eine Person im Büro
anwesend ist, gerade in einer Besprechung sitzt oder außerhalb des Büros unterwegs ist. Weiterhin
ist meist eine Verbindung zu Chat- oder Mail-Systemen integriert. Bekannte Beispiele für solche
Systeme sind ICQ oder AOL Instant Messenger. Siehe (Michalski 1997) für mehr Information zu
dieser Anwendungsklasse.
Recommender, Matchmaker
Dies sind Systeme, die versuchen, die Vorlieben eines Benutzers herauszufinden und ihm dann Vorschläge zu machen, die ihn interessieren könnten. Grundlage der Empfehlungsgenerierung sind normalerweise Benutzerprofile, die in inhaltsbasierten (regelbasierten) oder kollaborativen Filterverfahren dazu verwendet werden, aus einer Menge von Möglichkeiten (z.B. Produkte oder Nachrichten)
die für den Benutzer passenden auszuwählen.
Diese Systemklasse zählt zum Bereich der Community-Unterstützungssysteme, da häufig Informationen zu den Beziehungen von Benutzern untereinander zur Filterung herangezogen werden, oder
25
Informationen aus einem gemeinsamen (Community-)Informationsraum zur Durchführung oder zur
Ergänzung der Empfehlung benutzt werden. Siehe hierzu auch die weiterführenden Hinweise zum
„Partizipativen Produktkatalog“ im folgenden Abschnitt zu Online-Shops. Beispiele für Empfehlungssysteme sind MovieCritic, MovieLens (Sarwar u. a. 2000) und die verschiedensten Personalisierungs- und Empfehlungsanwendungen im Bereich des Electronic Commerce (z.B. die Buchempfehlung bei Amazon.com (Linden u. a. 2003)).
Neben dem Empfehlen von Informationen oder Produkten können Recommender-Systeme auch andere Personen empfehlen. D.h. auf andere Personen (in der Community) hinweisen, die in einer
bestimmten Frage helfen könnten oder mit denen sich ein Kontakt generell lohnen könnte. Solche
Matchmaking-System nutzen Kenntnisse von Beziehungen und Interessen um Benutzer zu finden,
die gleiche Interessen oder sonstige Gemeinsamkeiten haben. Teilweise findet sich auch eine Analyse und Visualisierung von Beziehungen zwischen Benutzern basierend auf Rohdaten wie dem Protokoll von E-Mail-Kommunikation. Beispiele aus der Systemklasse der Matchmaker sind Yenta (Foner
1997) und ReferralWeb (Kautz u. a. 1997).
Community-Portale
Häufig werden verschiedene Community-Funktionalitäten in andere Systeme integriert bzw. um andere Funktionen herum gruppiert. Das beste Beispiel dazu sind Portale und Online-Shops mit Community-Funktionalität oder (Web-)Informations-Portale mit Community-Funktionalität.
Online-Shops
Der Fokus bei Online-Shops ist der Vertrieb eines bestimmten Sortiments von Produkten. Motiviert
von (Hagel und Armstrong 1997) haben verschiedene Betreiber von Online-Shops ihre Dienste mit
Community-Funktionalität ergänzt. Ziele dabei waren die Erhöhung der Kundenbindung und die
Verbesserung der Kundenbetreuung durch Ermöglichung der Kommunikation unter den Kunden. Als
Möglichkeiten des gemeinschaftlichen Handelns wurden dabei vor allem der Informationsaustausch
unter den Kunden und das gemeinschaftliche Bestellen von Waren betrachtet. Hagel und Armstrong
(1997) gehen in diesem Zusammenhang auch darauf ein, dass diese Schaffung von Kommunikationsmöglichkeiten für Kunden die Machtverteilung zwischen Produzenten und Kunden deutlich verändert.
Schubert (2000) beschreibt sehr detailliert das Konzept hinter der Nutzung von Community-Funktionalität bei Online-Shops. Sie betitelt das generalisierte Konzept dabei mit „Partizipativer Produktkatalog“. Grundkonzepte hierbei sind die Ermöglichung und Zugänglichmachung von Produktbewertungen durch und für Kunden. Meist wird dieser Dienst noch um Empfehlungsfunktionen ergänzt.
Ein prominentes Beispiel, das viele solche Community-Funktionalitäten umsetzt ist der Online-Shop
von Amazon.com.
Informations-Portale
(Web-)Informations-Portale bieten meist ein Informationsangebot, das von einem Editor-Team oder
Fremdanbietern zusammengestellt und gepflegt wird. Neben der Möglichkeit zur personalisierten
Auswahl aus dem redaktionellen Informationsangebot werden auch solche Portale vielfach um die
Möglichkeit zum Informationsaustausch zwischen den Benutzern ergänzt. Beispiele hierfür sind Foren zu den einzelnen redaktionellen Inhalten bei heise.de oder zeit.de. In Anlehnung an die Diskussion zu Online-Shops kann dies als „Partizipativer Produktkatalog“ für Informationsprodukte betrachtet
26
werden. Neben der Anreicherung der Informationen bietet diese Funktionalität dabei auch wieder die
Möglichkeit, durch Awareness andere Personen zu finden.
Wissensmanagement
Einer der Nutzen von Beteiligung in Communities war die Erweiterung des eigenen Wissens- und
Erfahrungsschatzes auf den der ganzen Community. Die Mitglieder der Community arbeiten gemeinschaftlich an Austausch und der Nutzbarmachung von Wissen. Die Community bietet einen
Kontext für eingestellte Information und in der Community agierende Personen und sorgt dadurch
für eine automatische Vorfilterung.
Viele Anwendungen zum Wissenmanagement in Unternehmen stützen sich deshalb auf CommunityKonzepte. Dienste in solchen Wissenmanagement-Anwendungen sind die Bereitstellung von Kommunikationsmöglichkeiten und Matchmaking-Funktionalitäten. Beispiele für solche Anwendungen
sind das ShareNet-System bei Siemens ICN und Eureka bei Xerox. Nachdem es sich hierbei um
Communities handelt, die meist um die Gemeinsamkeit einer Tätigkeit bzw. eines Verfahrens herum
gruppiert sind, spricht man häufig auch von „Communities of Practice“ (Wenger 1998).
2.3.3
Abgrenzung
Community-Unterstützungssysteme decken einen breiten Bereich von Funktionalitäten ab. Trotzdem lohnt sich die Abgrenzung von einigen anderen verwandten Konzepten, speziell Groupware und
Portale.
Communityware versus Groupware
Mit „Groupware“ werden Werkzeuge zur Unterstützung von Arbeitsgruppen bezeichnet (Borghoff
und Schlichter 2000). Dabei wird angenommen, dass eine Arbeitsgruppe aus einer eher kleinen
Zahl von Personen besteht, die sich gegenseitig kennen, ein gemeinsames Ziel verfolgen bzw. in
einen gemeinsamen Prozess eingebunden sind. Der Fokus der Anwendungen liegt meist auf der
Unterstützung von Koordination zwischen den Gruppenmitgliedern.
Community-Unterstützungssysteme dagegen gehen von einer (größeren) lose gekoppelten Gruppe
von Personen aus, die sich eher nicht alle gegenseitig kennen. Hauptfunktionalitäten sind deshalb das
Finden von Personen und die Kommunikation an sich. Die Unterstützung von Koordination spielt bei
der Unterstützung von Communities kaum eine Rolle.
Communityware versus Portale
Neben Groupware haben Portale die größte Ähnlichkeit zu Community-Unterstützungssystemen.
Portale haben als Hauptmerkmale, dass sie einen gemeinsamen Einstiegspunkt zu Diensten bilden,
der für jeden Benutzer personalisierbar ist. Momentan sind diese Dienste hauptsächlich die Bereitstellung redaktioneller Inhalte sowie von Transaktionsdiensten (z.B. die Abwicklung von Bestellungen
oder Anmeldungen).
Normalerweise isolieren Portale ihre Benutzer voneinander. Die Kommunikation zwischen den Benutzern oder das Gewahrsein von anderen Benutzern wird also nicht unterstützt. Wie im vorhergehen-
27
den Unterabschnitt ausgeführt, ist allerdings ein Zusammenwachsen von Portalen und CommunityUnterstützungssystemen zu bemerken. Um die redaktionellen Inhalte und Transaktionsdienste herum
werden Kommunikations- und Awareness-Funktionalitäten bereitgestellt.
2.3.4
Community-Frameworks
Zusätzlich zu den in Abschnitt 2.3.2 aufgeführten konkreten Anwendungen und Plattformen gibt es
weiterhin verschiedene kommerzielle und nicht-kommerzielle Lösungen zur Vereinfachung des Aufbaus von Community-Plattformen. Solche Lösungen sind meist Web-basiert, stellen Basisfunktionalitäten wie Benutzerverwaltung und Inhalteverwaltung bereit und erlauben eine mehr oder weniger
einfache Erweiterung und Konfiguration.
Beispiele für Community-Frameworks sind das ArsDigita Community System und der Cassiopeia
Community Application Server (www.cassiopeia.com). Auch dieser Klasse zuzurechen sind der
Web-Applikationsserver Zope (www.zope.org) und Web-basierte Groupware-Portale wie phpGroupware (www.phpgroupware.org).
Nachdem sich diese Lösungen im Kontext von Community-Unterstützung teilweise ähnlichen Probleme gestellt haben, wie die dieser Arbeit zugrundeliegende Systementwicklung (einfacher Aufbau
von Plattformen, einfache Anpassbarkeit), können die dort realisierten Lösungen in manchen (implementierungsnahen) Bereichen als Anregung benutzt werden.
Zum ArsDigita Community System legt Greenspun (1999) zum Beispiel bereits 1999 eine erste pragmatische Lösung für eine modulare Architektur vor. Er definiert
„The big solution is a configurable set of software modules that will
1. keep a database of users, how to contact them, and how private they want their personal
information kept
2. keep a database of site content, who contributed it, and how each piece relates to the others
3. keep track of which users have looked at which pieces of content
4. keep track of which users are costing the community time and money
5. keep track of how users are coming into the site and which external links they are selecting
(clickthroughs)
6. if a commercial site, keep track of which advertisers’ banner ads have been served and to
whom and whether or not they were effective
7. help the site maintainers keep in contact with different classes of users“
Diese Aufstellung zeigt ein klares Verständnis der Charakteristika von Community-Unterstützung,
und entspricht in großen Teilen bereits dem Vorschlag, den ich in Abschnitt 2.4.2 mache und in
Kapitel 3 detailliere.
Trotz des Nutzens von Community-Frameworks als Anregung, insbesondere für technische Teillösungen zur Konfigurierbarkeit einer Plattform, finden sich dort bisher noch keine Lösungen für die
eigentlich gewünschte Interoperabilität. So wird insbesondere bei der Definition der Komponetenschnittstellen und Datenmodelle wenig Wert auf Generalität gelegt.
28
2.4 Anforderungen an Community-Unterstützungssysteme
2.4
2.4.1
Anforderungen an Community-Unterstützungssysteme
Anforderungsschwerpunkte
Aus den in diesem Kapitel dargestellten allgemeinen Betrachtungen zu Communities ergeben sich
verschiedene Anforderungen an deren Unterstützung. Um die Anforderungsschwerpunkte herauszuarbeiten, fasse ich im Folgenden die wichtigsten Charakteristika von Communities und der Aktivität
in Communities zusammen und bespreche kurz die daraus folgenden Anforderungen an CommunityUnterstützungssysteme und -Plattformen.
1. Personen sind normalerweise Mitglieder in verschiedenen Communities
Für Community-Unterstützungs-Plattformen bedeutet dies, dass es einfach sein sollte verschiedene Plattformen parallel zu nutzen. Der aktuelle Stand ist hier nicht befriedigend. Auch mit
intuitiven Web-Benutzungsschnittstellen und einer Single-Sign-On-Lösung (d.h. dasselbe Login und dasselbe Passwort auf allen Plattformen) ist der Aufwand, regelmäßig mit verschiedenen Plattformen zu interagieren zu groß für die meisten Benutzer. Es gibt einen großen
Bedarf an nicht-interaktiven Werkzeugen oder Benutzungsschnittstellen zum einfachen Veröffentlichen von Informationen auf verschiedenen Plattformen und zum einfachen Abfragen von
Informationen bei verschiedenen Plattformen.
Hierfür schlagen wir eine Trennung von Benutzungsschnittstelle und Community-Diensten
vor, die eine Realisierung von persönlichen Informationsagenten zum Zugriff auf verschiedene
Plattformen erlaubt. Eine Alternative dazu wäre der Zugriff auf alle Informationen über eine
der Plattformen, die dafür Informationen von den anderen Plattformen bezieht. Auch hier hätte
man nur eine Benutzungsschnittstelle, die der Benutzer zu bedienen hat. Erste Ansätze zur
Vereinfachung der Interaktion mit verschiedenen Plattformen sind auch schon darin zu sehen,
dass Notifikationen aus den Plattformen auf einer E-Mail-Adresse gebündelt werden können.
2. Communities können ad-hoc und durch jedermann initiiert werden
Dies bedeutet für Unterstützungsplattformen, dass es möglich sein muss, sie einfach einzurichten und anzupassen. Um dies möglich zu machen wird eine modulare und einfach anpassbare
Grundarchitektur für Community-Unterstützungssysteme benötigt.
3. Persönliche Interaktion und Wissen über andere Mitglieder ist wichtig in einer Community
Community-Unterstützung bedeutet nicht, dass von Mitgliedern Information gesammelt wird
und diese Information anderen Mitgliedern anonym zur Verfügung gestellt wird. Der Austausch von Information in einer Community sollte immer als Kommunikation zwischen Autor
der Information und Konsument der Information gesehen werden. Die Verbindung einer Information mit dem Autor ist insbesondere wichtig für die Interpretation der (oft subjektiven)
Aussagen. Ein weiter Grund für die Notwendigkeit einer engen Verknüpfung zwischen Information und Autor ist die Nutzung von publizierter Information zur Identifikation von potentiellen Partnern für direkte Kommunikation und für die Vermittlung von Awareness zu Aktivitäten
von Community-Mitglieder.
Im Zusammenhang mit über Communities ausgetauschte Information und auch getrennt davon ist also die Identifikation von anderen Mitgliedern und die Vermittlung von Informationen
zu anderen Mitgliedern eine wichtige Funktion von Communities. Aus diesem Grund müssen
29
Community-Unterstützungssysteme Zugriff auf die Profile andere Benutzer bereitstellen. Neben Fragen der Aquise und Kodierung solcher Informationen wirft dies vor allem Probleme
bezüglich der Wahrung der Privatsphäre der Community-Mitglieder auf.
4. Interaktion mit Community-Unterstützungssystemen passiert nicht nur von Desktop-PCs aus
Der Zugriff auf Community-Plattformen muss von überall aus und während verschiedenster
Tätigkeit möglich sein. Speziell wird mobiler und ubiquitäre Zugang zu Community-Plattformen benötigt. Dies schließt auch Benutzungsschnittstellen ein, die von mehreren Personen
gleichzeitig genutzt werden können (wie Tapeten-ähnliche berührungssensitive große Wandbildschirme).
Aus diesen grundlegenden Anforderungen ergeben sich die wichtigsten Arbeitsgebiete im Zusammenhang mit der Bereitstellung von Community-Unterstützung:
Schaffung einer modularen Architektur um eine einfache Anpassbarkeit, Interoperabilität und
Nutzung mehrerer Plattformen über eine Benutzungsschnittstelle zu erlauben.
Realisierung einer plattform-übergreifenden Verwaltung von Benutzerprofilen und Zugriffsrechten darauf und Nutzung dieser Information für die Bereitstellung von Awareness und Personalisierung.
Entwurf ubiquitärer und mobiler Benutzungsschnittstellen zum Zugriff auf die CommunityPlattformen.
Modularisierung,
Interoperabilität
CommunityUnterstützung
Benutzerprofile,
Awareness, Personalisierung
ubiquitäre
Benutzungsschnittstellen
Abbildung 2.2: Arbeitsgebiete im Zusammenhang mit Community-Unterstützungssystemen
In der weiteren Arbeit werden die ersten beiden Arbeitsgebiete näher behandelt und Lösungen dafür
hergeleitet. Neue und ubiquitäre Benutzungsschnittstellen für Community-Unterstützungssysteme
werden nicht näher behandelt. Durch die mit der Modularisierung kommende Trennung von Diensten
und Benutzungsschnittstellen ist es allerdings sehr einfach möglich, verschiedenste ubiquitäre Schnittstellen zu realisieren. In (Koch u. a. 2001d), (Koch und Schlichter 2001), (Agostini u. a. 2000), (Grasso u. a. 2000), (Grasso u. a. 1999), (Koch u. a. 1999) und (Grasso u. a. 1998) sind meine bisherigen
Arbeiten in diesem Bereich dokumentiert.
30
2.4 Anforderungen an Community-Unterstützungssysteme
2.4.2
Unterstützungsfunktionalitäten
Nach der Behandlung von Communities und Community-Unterstützung soll in diesem Abschnitt eine
Verallgemeinerung der Unterstützungsfunktionalitäten vorgenommen werden, um eine Grundlage für
die Konzeption einer generischen Unterstützungsplattform zu legen.
De Michelis (2001) führt folgende allgemeinen Ideen zur Community-Unterstützung aus:
„support practice (not rules)“
„support the learning process (community knowledge)“
„integrate places, create new places“
„support communities (plural!) - take into account that people live in many communities continous movement“
In den vorhergehenden Abschnitten wurde Community-Unterstützung als Unterstützung einer Gruppe von Personen bei der Kommunikation untereinander und beim Sich-Finden beschrieben. Die dabei
herausgearbeiteten Hauptfunktionalitäten für Community-Unterstützung sind:
Unterstützung der direkten Kommunikation zwischen Community-Mitgliedern (über eine Community-Plattform)
Unterstützung der indirekten Kommunikation zwischen Community-Mitgliedern durch Möglichkeiten zum Publizieren und Recherchieren von Information - Im Gegensatz zu reinen Informationsystemen ist hier wichtig, dass die Verbindung zwischen publizierendem Benutzer
und Information erhalten und einfach nachvollziehbar bleibt. Es handelt sich bei der auf
Community-Plattformen publizierten Information nämlich meist um subjektive Information
mit Bezug zum publizierenden Benutzer (um „warme“ Information) - hierzu zählt auch die
Möglichkeit Kommentare zu Informations-Items zu publizieren.
Unterstützung des Findens von anderen Community-Mitgliedern (zum Zwecke der direkten
Kommunikation) - Wie bei der indirekten Kommunikation kann dies über Pull-Mechanismen
oder über Push-Mechanismen (Empfehlungen, Awareness) geschehen.
Bereitstellung von Awareness über Benutzer und Aktivitäten auf der Plattform - Es werden
proaktiv und personalisiert Informationen über möglicherweise interessante Informationen und
Kontakte dargestellt.
Aus diesen grundlegenden Unterstützungskonzepten und den Erfahrungen bei der Umsetzung verschiedener Plattformen (siehe hierzu auch Abschnitt 3.6) ist die im folgenden motivierte Strukturierung für die Funktionalitäten einer Community-Plattform (und damit eines generischen CommunityUnterstützungssystems) entstanden.
Eine Community-Plattform muss zuerst einmal synchrone und asynchrone direkte Kommunikationskanäle bieten. Dabei sind verschiedene Möglichkeiten zur Adressierung von Kommunikationsempfängern und zum Erreichbarkeitsmanagement vorzusehen (Koch u. a. 2002a). Dieser Funktionalitätsblock wird in der Mitteilungsverwaltung abgedeckt.
31
Für die indirekte Kommunikation ist es notwendig, Informationen zu publizieren und über längere
Zeit für potentielle Interessenten zu speichern und zur Erstellung von Anmerkungen verfügbar zu halten. Diese Funktionalität mit den Pull- und Push-Mechanismen zum Zugriff darauf (inkl. Awareness)
ist in der Inhalteverwaltung realisiert.
Für die Personalisierung und Empfehlungsgenerierung der Kommunikations- und Inhaltsdienste werden Informationen über die Community-Mitglieder benötigt. Ein weiterer Anwendungsbereich für
Mitgliederdaten ist das Matchmaking und die Mitglieder-Awareness. Aus diesem Grund muss eine
Community-Plattform als zentrale Komponente eine Mitgliederprofilverwaltung besitzen. Die Mitgliederprofilverwaltung muss transparent für die Mitglieder sein, zu denen Daten gespeichert sind
und muss auch für andere Mitglieder (eingeschränkt) zugänglich sein.
Welche Benutzer der Plattform zusammen gehören, wird in Benutzerlisten verwaltet. Dies trägt dem
Umstand Rechnung, dass eine Plattform häufig mehrere Communities bedient, bzw. sich in einer
Community offene und geschlossene Unter-Communities entwickeln.
Zusammengefasst ergeben sich also folgende Funktionalitäten für ein Community-Unterstützungssystem:
Inhalteverwaltung
Kategorienverwaltung und Benutzerlistenverwaltung
Mitteilungsmanagement
Awareness/Matchmaking
Personalisierung, Empfehlungsgenerierung (für Mitteilungen und Inhaltsverwaltung)
Diese Funktionen sollten über verschiedene Benutzungsschnittstellen zugänglich sein. Im folgenden
Kapitel 3 wird diese Aufteilung als Basis für ein Modularisierungkonzept für Community-Unterstützungssysteme wieder aufgegriffen. Als zusätzlicher Dienst wird dort auch noch die Kontextverwaltung
eingeführt.
32
Kapitel 3
Modularisierung von
Community-Unterstützungssystemen
„People cannot share knowledge if they do not speak a common language.“,
(Davenport und Prusak 1998)
Ein Ziel dieser Arbeit ist es, ein Konzept für interoperable Community-Unterstützungssysteme
zu erarbeiten. Dabei soll sowohl der Aufbau neuer Unterstützungsplattformen aus vorhandenen Bausteinen, als auch die Zusammenarbeit mehrerer Plattformen und die Zusammenarbeit
von Client-Werkzeugen mit Community-Plattformen möglich sein. Grundidee dazu ist die komponentenorientierte Konstruktion von Community-Plattform, d.h. die Aufteilung von Community-Plattformen entsprechend ihren Hauptfunktionalitäten in generische Module, die über klare
Schnittstellen verfügen und sich einfach kombinieren, konfigurieren und nutzen lassen. In diesem
Kapitel wird die in meiner Arbeit abgeleitete Architektur für Community-Unterstützungssysteme vorgestellt und es werden die Systeme präsentiert und diskutiert, die Teile der Architektur
umsetzen.
Kapitelinhalt
3.1
3.2
3.3
3.4
Grundkonzepte der Modularisierung
Datenkonzepte . . . . . . . . . . . . .
Community-Dienste . . . . . . . . . .
Konfigurierung . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
40
54
64
Grundidee des Architekturkonzeptes für Community-Unterstützungssysteme ist es, Komponentenkonzepte und Modularisierung so zu nutzen, dass Community-Unterstützungssysteme aus generischen Bausteinen aufgebaut und angepasst werden können, sowie einfach erweitert werden können.
Durch offene Schnittstellen soll erreicht werden, dass Community-Unterstützungssysteme einfach
miteinander kommunizieren können und von verschiedensten Werkzeugen aus angesprochen werden
können (nicht nur von Web-Browsern aus). Dazu ist die Identifikation von konkreten Komponenten
und die Modellierung von allgemeinen Schnittstellen und Datenstrukturen notwendig. Nach einer
Einführung in die Themen Modularisierung und Agenten-basierter Modellierung (Abschnitt 3.1) wird
deshalb in diesem Kapitel aus den Anforderungen an Community-Unterstützung eine Aufteilung in
Komponenten zusammen mit den jeweiligen Schnittstellen hergeleitet und ausgeführt (Abschnitte 3.2
und 3.3), sowie auf die Konfigurierung der Komponenten allgemein eingegangen (Abschnitt 3.4).
Basis dieses Kapitels sind die im Projekt Cobricks und seinen Unterprojekten erarbeiteten und getesteten Unterstützungsfunktionalitäten und Architekturkonzepte. Dieses Kapitel fasst die in folgenden
33
Veröffentlichungen erarbeiteten und dokumentierten Ergebnisse konsistent zusammen und führt sie
weiter: (Koch 2002b), (Koch 2002e), (Koch 2002f), (Koch u. a. 2002a), (Borghoff u. a. 2001), (Koch
2001a), (Koch u. a. 2001a), (Koch u. a. 2001b), (Koch u. a. 2001c), (Koch und Lacher 2001), (Koch
2000) und (Koch und Lacher 2000). Insbesondere werden in diesem Abschnitt die Schnittstellen und
Datenstrukturen des erarbeiteten Architekturmodells konkretisiert. Bei der Konzeption des Modells
für Community-Unterstützungssysteme wurden dabei viele Ideen aus dem Umfeld der Agentenmodellierung und -programmierung aufgegriffen. Aus diesem Grund werden diese Themen auch im
ersten Abschnitt dieses Kapitels ausführlich aufgegriffen. Die Realisierung selbst ist dann allerdings
als einfache Komponenten-Lösung mit klassischen Schnittstellen ausgeführt.
3.1
Grundkonzepte der Modularisierung
Das Thema „Modularisierung“ bei Software ist so alt wie die Programmierung selbst. Das Ziel dabei
ist es meist ein Softwaresystem in Komponenten zu zerlegen bzw. aus Komponenten aufzubauen, die
wiederverwendbar sind,
einfach testbar sind,
zu verschiedenen Anwendungen kombinierbar sind.
Hieraus leitet sich auch die Grunddefinition von „Komponente“ ab. Eine Komponente besteht aus
verschiedenen (Software-)Artefakten. Sie ist wiederverwendbar, abgeschlossen, stellt Dienste über
wohldefinierte Schnittstellen zur Verfügung, verbirgt ihre Realisierung und kann in Kombination mit
anderen Komponenten eingesetzt werden, die zur Zeit der Entwicklung nicht unbedingt vorhersehbar
sind. Szyperski (1998, S.34) schreibt beispielsweise:
„A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is
subject to composition by third parties.“
Im Zusammenhang mit Software-Engineering und Entwurfsmethoden wurde dabei vor allem auf
Schnittstellenbeschreibung und auf allgemeine Vorgehensmodelle zum Finden geeigneter Komponenten oder Module eingegangen.
Herausforderungen und mögliche Probleme beim Entwurf von komponentenbasierten Systemen werden in verschiedenen Veröffentlichungen diskutiert (z.B. (Sparling 2000; Overhage 2002)). Overhage
(2002) gibt schlussfolgernd drei Gründe dafür an, warum sich die Umsetzung von komponentenorientierten Anwendungsentwicklungen in der Praxis als schwierig erwiesen hat:
Mangel an technischen Standards
Fehlen einer (konzeptionellen) Komponenten-Terminologie mit einheitlichem Spezifikationsrahmen
Fehlen fachlicher Standards
34
3.1 Grundkonzepte der Modularisierung
Ein weiteres Problem mit komponentenorientierten Systemen ist, dass die für eine klare Entkoppelung der Komponenten notwendige strenge Kontrolle der Beziehungen zwischen Daten über die
Komponentengrenzen hinweg häufig vernachlässigt worden ist.
In dieser Arbeit soll für den konkreten Anwendungsbereich der Community-Unterstützungssysteme
eine geeignete Modularisierung gefunden werden, d.h. ein fachlicher Standard für diesen Bereich entwickelt werden. Dabei wird vor allem auf die Anforderungen an Community-Unterstützungssysteme
eingegangen, die in Kapitel 2 erarbeitet worden sind. Im Folgenden werden zuerst die zu benutzenden Grundkonzepte diskutiert (Abschnitt 3.1) und dann die Datenstrukturen und die Modularisierung
für den Community-Unterstützungsbereich konkret motiviert (Abschnitte 3.2 und 3.3).
Möglich gemacht haben Modularisierung die Einführung von (rekursiven) Prozeduraufrufen und lokalen Variablen in die Konzepte von Programmiersprachen. Neuere Konzepte und wichtige Technologien im Zusammenhang mit Modularisierung sind dabei:
Entwurfsmuster (Design-Patterns)
Verteilte Anwendungen (RPC, SOAP, Web-Services)
Agenten
Diese Technologien realisieren dabei verschiedene Abstraktionsebenen: Entwurfsmuster werden zur
Darstellung allgemeiner Konzepte der Zusammenarbeit verwendet. Die Arbeiten um Agenten beschäftigen sich mit der Modellierung von komplexen Zusammenarbeitsbeziehungen und mit der
Realisierung dieser Interaktion auf hohem Abstraktionsniveau. Im Kontext Verteilter Anwendungen
(bzw. Verteilter Objekte) werden schließlich Möglichkeiten zur Realisierung verteilter Komponentensysteme auf niedrigem Abstraktionsniveau untersucht und realisiert.
Nachfolgend werden diese Grundtechnologien der Modularisierung kurz dargestellt und ihre Anwendung im Bereich der Community-Unterstützungssysteme diskutiert. Im folgenden Abschnitt beginnt
dann die Vorstellung und Motivation einer konkreten Lösung für den Anwendungsbereich.
3.1.1
Entwurfsmuster
Beim Entwurf von (objektorientierten) Softwaresystemen stellt sich die Aufgabe, passende Objekte
zu finden und diese in der richtigen Granularität in Klassen umzusetzen und Beziehungen zwischen
ihnen zu definieren. Das Problem dabei ist, dass eine große Erfahrung zum Finden guter Lösungen für
komplexe Entwürfe notwendig ist. Dieses Expertenwissen war nur sehr schwer zu dokumentieren.
Mit „Design Patterns“ (Entwurfsmuster) wurde auf der OOPSLA-Konferenz 1987 die schon seit
längerem in der Architektur benutzte Idee, Entwurfsmuster zur Darstellung von Designerfahrung zu
benutzen, vom Softwareengineering aufgegriffen und „software design patterns“ eingeführt. Im Jahr
1995 erschien dann das vielbeachtete Buch „Design Patterns“ von Gamma et al. mit einer Sammlung
von Entwurfsmustern für Software.
Entwurfsmuster sind allgemein ein Konzept um immer wieder auftretende Probleme sowie bewährte
Lösungen schriftlich zu dokumentieren. In strukturierter Form wird festgehalten, in welchem Kontext das Problem auftritt, welche Anforderungen zu beachten sind und welche Lösungen sich dafür
anbieten.
Entwurfsmuster kann man für die Entwicklung jeder Art von Softwaresystem einsetzen. Im Kontext
von Community-Unterstützungssystemen würden sich Entwurfsmuster anbieten, um Kombinationen
35
von verschiedenen Funktionalitäten und Entwurfsoptionen bei der Gestaltung einer CommunityUnterstützungsanwendung festzuhalten. Ähnliche Arbeiten hat Borchers (2000) für Interaktionsdesign durchgeführt. Auch für Human-Computer-Interaction (HCI) und Groupware allgemein gibt
es schon Ansätze zur Beschreibung von Basiskonzepten mit Entwurfsmustern (siehe hierzu (Erickson 2000; Schuemmer u. a. 2002)). Nachfolgend als Beispiel eine Pattern-Beschreibung des RoomKonzeptes aus dem Groupware-Bereich (Schuemmer u. a. 2002):
NAME ROOM
INTENT Provide the group with a place, where they can meet for collaboration.
FAMILY Collaborative Virtual Environment
Also Known As Area, Place
PROBLEM When distributed users want to collaborate, they have to deal with many technical issues
to initiate the collaboration. They have to set up communication channels and make the shared
material available to all group members. Results of the shared collaboration often need to be captured
for later reference. All these tasks are error-prone and require technical expertise, which users often
don’t have.
SCENARIO (...)
CONTEXT Users are distributed and want to work synchronously together using communication
channels and documents. Communication takes place using external tools that introduce additional
overhead regarding the connection management. Documents cannot easily be shared because the
group has no common place to leave the documents. There are technological novices in the group,
which need a simple to use interface to find and join cooperation.
SOLUTION Therefore: Model a virtual place for collaboration as a room, which can hold documents
and participants. Ensure that users, who are in the same room at the same time, can communicate by
means of a communication channel that is automatically established between all users in the room.
Make sure that all users can perceive all documents that are in the room. That includes that changes
on these documents are visible to all members in the room.
PARTICIPANTS The room contains users and documents and provides a communication channel
as well as shared editors. Each room has a well-defined border that defines, what is in the room and
what is outside the room. A room has an identification that allows the user to find it. (...)
RELATED PATTERNS
– Door: Doors are means for controlling the access to a room and therefore providing the rooms
participants with privacy. They also help to interpret a set of rooms as a coherent world, in
which interaction can take place.
– (...)
– Shared Workspace: A shared workspace allows the users to work synchronously on a shared
document. Often shared workspaces form the document-interface of a room. This then means
that a room contains the document that is edited in the shared workspace.
Die Idee von Entwurfsmustern für Community-Unterstützungssysteme soll in dieser Arbeit aber nicht
weiter verfolgt werden. Patterns sind für den Entwurf neuer Systeme gedacht – zur Kommunikation und zum Erfahrungsaustausch zwischen (Software-) Designern. Reale Einsatzpotentiale für
Community-Unterstützungssysteme sind eher bei der Kombination von Funktionalitäten für eine konkrete Plattform und weniger beim Entwurf von generischen Softwarekomponenten zu erwarten. Wir
werden also mit klassischen Methoden generische Community-Unterstützungskomponenten entwerfen und diese dann mit verschiedenen Methoden kombinieren und anpassen. Zu letzterem könnten
Pattern-Ideen später einen interessanten Beitrag liefern.
36
3.1.2
Verteilte Anwendungen und Komponenten
Komponentenorientierte Systeme zeichnen sich durch die zentrale Eigenschaft aus, dass die Komponenten nur über klar definierte Schnittstellen von anderen Teilen des Systems abhängig sind. Für
einen ausführlichen Überblick über Komponenten(technologien) siehe (Szyperski 1998).
Unter einer verteilten Anwendung versteht man ein Softwaresystem, das sich aus verschiedenen
Komponenten zusammensetzt, welche potentiell auf verschiedene Rechner verteilt werden können,
und welche zur Erfüllung ihrer Aufgabe miteinander kommunizieren müssen (Borghoff und Schlichter 2000). Durch die Aufteilung der Komponenten auf verschiedene Adressräume und heterogene
Ausführungsumgebungen besteht bei Verteilten Systemen eine besondere Notwendigkeit zur klaren
Definition von Schnittstellen zwischen den Komponenten.
Erste Technologien zur Unterstützung der Realisierung von Verteilten Systemen waren entfernte Prozeduraufrufe (Remote Procedure Calls, RPC). Zusammen mit Objekt- und Komponentenmodellen
wie DCOM und Corba stellt dies die technische Grundlage für die Zusammenstellung einer Anwendung aus verschiedenen Komponenten dar.
Aufbauend auf diesen Basisdiensten sind inzwischen weiterreichende Technologien wie EnterpriseJava-Beans (EJB) oder Web-Services verfügbar. Dabei handelt es sich meist um Frameworks aus
einem RPC-Mechanismus (RMI bei EJB, SOAP bei Web-Services) zusammen mit Standards für das
Finden und Ansprechen von Objekten und für das Publizieren von Schnittstellen.
Unter Web-Services versteht man beispielsweise Software-Komponenten, die mittels Internet-Standards wie XML und SOAP interagieren. Sie können von anderen Web-Services genutzt werden, von
Service-Providern für beliebige Nutzer angeboten werden oder auch für die Benutzung durch Endbenutzer direkt ausgestattet werden. Im Vergleich zu klassischen Web-Angeboten sollen mit WebServices der eigentliche Dienst und die Benutzungsschnittstelle getrennt werden. Für eine detailierte
technische Beschreibung zu Web-Services sei auf die Seiten des World-Wide-Web-Consortiums W3C
unter www.w3c.org verwiesen.
Gemeinsam ist all diesen Konzepten, dass Komponenten mit ihren technischen Schnittstellen modelliert werden. Dabei geht man heute meist von Objekten und Funktionsschnittstellen dieser Objekte
(bzw. der Klassen aus denen sie instantiiert sind) aus. Folgendes Beispiel zeigt eine Beschreibung
einer Schnittstelle in Corba-IDL:
module idrepository {
typedef sequence<string> StringList;
interface IDRepositoryCorbaInterface {
string getDataGroup(in string identityID,
in string datagrouppath);
void putDataGroup(in string identityID,
in string datagrouppath,
in string xml);
StringList getGroupPaths(in string identityID);
StringList getUserProfileList();
};
};
Die Grundidee der Trennung von Client und Server, von Basisdienst und Benutzungsschnittstelle soll
auch für die Konzeption einer Community-Unterstützungs-Infrastruktur herangezogen werden. Die
Dienstkomponenten sollten völlig unabhängig von möglichen Benutzungsschnittstellen sein.
37
Hauptnachteil der heutigen Komponentenkonzepte ist die auf niedriger Abstraktionsebene gehaltene
Schnittstellen-Semantik. Durch eine entsprechend abstrakte Definition der Schnittstelle und allgemeine Datenstrukturen lässt sich dieses Problem allerdings mildern. Siehe hierzu auch den folgenden
Abschnitt zu Agenten(-schnittstellen).
3.1.3
Agenten
Ein Agent ist charakterisiert als eine abgrenzbare Softwareeinheit, die zur Erreichung der von ihrem
Benutzer oder Entwickler vorgegebenen Ziele und unter der Wahrung seiner Interessen flexibel und
autonom mit ihrer Umgebung und anderen Agenten interagiert (Weiß 2001).
Ausgehend von diesem Agentenkonzept zielt agentenorientiertes Software-Engineering vor allem auf
Anwendungen ab, die mindestens eines der folgenden Merkmale aufweisen:
Es sind viele dynamisch interagierende Komponenten involviert,
die nicht unbedingt alle a priori bekannt sind
die eine Fremdkontrolle nicht oder nur beschränkt gestatten (z.B. aufgrund individueller und
konfliktträchtiger Ziele, Interessen, Rechte und Pflichten)
zwischen denen elaborierte Kommunikations- und Koordinationsprozesse erforderlich sind.
Solche Anwendungen finden sich mit zunehmender Rechnervernetzung und Plattform-Interoperabilität in verschiedensten Bereichen.
Es gibt drei herausragende Merkmale von Agenten: Flexibilität, Autonomie und Interaktivität. Dabei
bedeutet Flexibilität, dass ein Agent sowohl zu reaktivem (d.h. Umweltveränderungen in angemessener Zeit berücksichtigendem) als auch zu proaktivem (d.h. in Hinblick auf Zwischen- und Endziele
vorausschauendem) Verhalten fähig ist. Autonomie besagt, dass ein Agent bei Bedarf selbständig und
unabhängig Entscheidungen über von ihm auszuführende zielrelevante Handlungen treffen kann und
in diesem Sinn Kontrolle über seinen internen Zustand und sein Verhalten besitzt. Schließlich impliziert Interaktivität insbesondere, dass Agenten auf hohem Niveau in Wechselwirkung treten können, also etwa im Rahmen von automatisierten Verhandlungen, Vertragsabschlüssen und verteilten
Planungs- und Problemlösungsprozessen.
Eine weitgehend akzeptierte Minimaldefinition für den Begriff Agent ist:
„An autonomous agent is a system situated within and a part of an environment that
senses that environment and acts on it, over time, in pursuit of its own agenda and so as
to effect what it senses in the future.“ (Franklin und Graesser 1996)
Im Gegensatz zu (verteilten) Objekten, welche nur Identität, Zustand und Verhalten kapseln, kapseln Agenten zusätzlich noch Freiheitsgrade und Ziele und bieten eine flexiblere Kommunikationsschnittstelle. Es handelt sich nicht um zwei konkurrierende Modelle, sondern um zwei qualitativ
verschiedene Abstraktionsebenen. Das Agenten- und das Objektkonzept ermöglichen auf qualitativ
verschiedenen Ebenen gleichermaßen relevante System- und Entwicklungssichten, die sich sinnvoll
ergänzen statt gegenseitig ausschließen (Weiß 2001).
Die Eigenschaft der Kommunikation ist für alle Agenten existentiell. Die Kommunikation schafft für
den Agenten die Voraussetzung, die Umwelt wahrzunehmen und diese über den eigenen Zustand zu
38
informieren bzw. Aufgaben zu übernehmen. Zur Umwelt des Agenten zählt das ihn „beherbergende“
Agentensystem, die Benutzer des Agentensystems und andere Agenten, welche auf dem beherbergenden oder einem anderen Agentensystem agieren.
Die Kommunikation zwischen Agenten stellt deshalb den umfangreichsten Teil der Forschung zu
Agenten dar. Es wird unterschieden zwischen den Kommunikationsmechanismen, welche sich mit
den technischen Details des Versendens, Transportierens und des Entgegennehmens von Nachrichten
beschäftigen, und der Kommunikationssprache, die sich mit Syntax und Semantik einer Sprache für
den Austausch von Wissen beschäftigt. Ziel bei letzterem ist die Formalisierung von Konversationen
zwischen Agenten ohne zuviel Ausdrucksmächtigkeit zu verlieren. Diese Ansätze sind auch für die
Konzeption von Community-Unterstützungssystemen interessant. Einerseits könnten die Komponenten des Systems als Agenten modelliert werden, die untereinander interagieren, andererseits könnten
Benutzeragenten mit den (Agenten-)Komponenten des Systems interagieren.
Die Grundidee bei der notwendigen Formalisierung der Kommunikation zwischen Agenten orientiert
sich an Versuchen zur Analyse menschlicher Konversationen in der Sprechakttheorie. Diese Ansätze
gehen zurück auf den Philosophen Ludwig Wittgenstein (1889-1951). Ausgehend von den Arbeiten
Wittgensteins und Entwicklungen der Sprachphilosophie haben in den 1960er Jahren die Philosophen
John Austin (1911-1960) und John R. Searle (geb. 1932) die heutige Sprechakttheorie begründet
(Searle 1969, 1979). Grundlage ist dabei die Analyse der Sprache als bedeutungsvolle Handlungen
(Akte) von Kommunikationspartnern. Im einzelnen beschäftigt sich die Sprechakttheorie mit der
Frage, wie sich Äußerungen auf die Zukunft des Sprechers und der Zuhörer auswirken, sowie mit der
Frage, welche Handlungen durch Wortfolgen veranlasst werden.
Die Anwendung von Sprechakten in der Agentenkommunikation sieht so aus, dass zwischen Agenten
ausgetauschte Nachrichten als Sprechakte markiert werden und damit (formal) spezifiziert wird, was
der Sender mit dieser Nachricht erreichen möchte. Im Kopf der Nachricht ist der Typ des Sprechakts
explizit mittels vordefinierter Schlüsselworte spezifiziert. Ebenso finden sich im Nachrichtenkopf
Referenzen auf die Nachrichten auf die Bezug genommen wird sowie Angaben über Sender und
Empfänger der Nachricht. Neben dem Nachrichtenkopf gibt es noch einen Nachrichtenrumpf mit
Aussagen oder Anfragen. Diese sind in einer Sprache formuliert, die neben der Domäne, über die in
dieser Sprache Aussagen und Anfragen formuliert werden können, auch im Nachrichtenkopf spezifiziert ist. Neben den Sprechakten ist hier die Trennung von Domänendefinition und von der Formulierung von Aussagen (über beliebige Domänen) sehr wichtig für die allgemeine Einsetzbarkeit und
Erweiterbarkeit der Schnittstelle (Singh 1994, 1998).
Zur Modellierung der Daten wird häufig auf Logik-Sprachen zurückgegriffen, bei der Modellierung
der Domänen auf das Konzept der Ontologien (siehe hierzu den Abschnitt 3.2.1 zu Wissensrepräsentation). Folgende Beispiele zeigen Ausschnitte von FIPA-ACL Nachrichten mit der Prädikatbasierten Inhaltssprache SL:
Nachfrage nach Item-Anmerkungen, deren Attribut „rating“ den Wert 3 hat:
REQUEST, ontology=community-item, language=sl2
content=’(=(iota ?x (is-item-annotation ?x (set)
(set (has-value(rating 3))))))’
Eintragen einer neuen Item-Anmerkung:
INFORM, ontology=community-item, language=sl2
content=’(add :item-annotation (item-annotation
:itemid=12 :rating=3))’
39
Für die Modellierung von Komponenten für die Community-Unterstützung würde sich der bei Agenten verfolgte Schnittstellen-Ansatz anbieten. Das heißt, eine Modellierung von Kommunikation als
einfache Sprechakte auf der Basis einer allgemeinen Repräsentation allgemeiner Datenkonzepte.
An der abstrakten Schnittstelle zwischen den Komponenten müssen
Informationen und Aussagen zu Grundkonzepten von Communities und Community-Informationen ausgetauscht (abgefragt, mitgeteilt) werden können, und
Aktionen auf Community-Objekten ausgelöst werden können.
Es stellt sich allerdings die Frage, ob die Lösung in Form „echter“ Agenten realisiert werden soll, oder
in Form „normaler“ verteilter Softwarekomponenten. Der Unterschied liegt hauptsächlich in der Bereitstellung von Schnittstellen über RPCs anstelle von Agenten-Kommunikationssprachen. Die Idee
der Sprechakte und der Trennung von Domänendefinition und Formulierung von Aussagen in bzw.
über eine Domäne kann in beiden Fällen realisiert werden. Nachdem die in dieser Habilitationsschrift
dokumentierte Arbeit im Kontext einiger konkreter Projekte steht, in denen einsatzfähige und robuste Systeme entwickelt werden sollten, die Agententechnologie (Agenten-Kommunikationssprachen
und Agentenplattformen) aber erstens noch nicht so ausgereift scheint und zweitens keinen besonderen Mehrwert bietet, haben wir uns für die klassische Lösung mit (Agenten-ähnlichen) generischen
Datenstrukturen entschieden.
Im weiteren soll dieser Ansatz weiterverfolgt werden. Es sollen die Grunddatenkonzepte in Communities identifiziert und modelliert werden (Abschnitt 3.2) und dann Komponenten identifiziert werden,
deren Schnittstellen mit diesen Datentypen arbeiten (Abschnitt 3.3). Bei der Modellierung von Komponentenschnittstellen wird dabei der strenge Agentenansatz etwas aufgebrochen und Aktionen als
domänenspezifische Performative in Form von (entfernten) Funktionsaufrufen und Callbacks modelliert (siehe hierzu auch Abschnitt 3.3).
3.2
Datenkonzepte
Nach der kurzen Diskussion verschiedener Modularisierungskonzepte und verwandter Themen soll
im weiteren Kapitel das für Community-Unterstützungssysteme entwickelte Modularisierungskonzept vorgestellt werden. Wie zuvor motiviert worden ist, sind dazu zuerst die Grunddatenkonzepte,
die über die Schnittstellen auszutauschen sind zu identifizieren und zu modellieren. In diesem Abschnitt sollen deshalb diese Konzepte ausgehend von der allgemeinen Funktionalitätsbetrachtung in
Kapitel 2 herausgearbeitet werden.
Betrachtet man die Aktivitäten in Communities und die Aufgaben von Community-Unterstützung,
dann lassen sich drei grobe Bereiche für Datenkonzepte unterscheiden:
1. Benutzerbeiträge (also was die Community-Mitglieder publizieren),
2. Benutzerrepräsentationen (also wie die Community-Mitglieder selbst im System repräsentiert
sind), und
3. Domänenrepräsentation, d.h. die Strukturierung der konkreten Anwendungsdomäne - zur Einordnung und Verbindung von Instanzen der Benutzer- und Inhaltskonzepte.
40
3.2 Datenkonzepte
Dieses Ergebnis deckt sich auch mit pragmatischen Ergebnissen früherer Arbeiten, wie z.B. von
Greenspun (1999), der als Kernmodule einer Community-Plattform identifiziert: „1) User Database,
2) Content Database, 3) User/Content Map“.
Die Datenkonzepte sollten möglichst allgemein modelliert werden, um verschiedene Verwendungen
und eine einfache Erweiterung zu unterstützen. Zur Modellierung solcher Datenkonzepte bieten sich
erprobte Verfahren und Werkzeuge aus dem Bereich der Wissenrepräsentation an. Bevor wir die
identifizierten Datenkonzeptbereiche weiter detailieren, wird deshalb im nächsten Abschnitt zuerst
allgemein auf Methoden zur Wissensrepräsentation eingegangen und eine geeignete Methode ausgewählt.
3.2.1
Wissensrepräsentation
Über die Komponentenschnittstellen sollen Fakten und Fragen kommuniziert werden. Ein entscheidender Aspekt dabei ist die Darstellung der Information in den Fakten und die Darstellung der Fragen.
Es handelt sich hierbei allgemein um Fragestellungen der Wissensrepräsentation.
Wissensrepräsentation ist die symbolische Darstellung von Wissen in bzw. über einen Gegenstandsbereich. Dabei unterscheidet man meist zwischen deklarativer und prozeduraler Wissensrepräsentation.
Deklarative Darstellungen von Wissensinhalten geben Beschreibungen von Sachverhalten, die keine
Angaben über Konstruktion und Gebrauch von Wissen enthalten - Beispiel: „[email protected] arbeitet an der Technischen Universität München“ (Fakt) oder „Konferenzbände sind Publikationen“
(Regel). Prozedurale Wissensdarstellungen dagegen beschreiben Verfahren zur Konstruktion, Verknüpfung und Anwendung von Wissen - beispielsweise ein Verfahren zur Berechnung der Summe
zweier Zahlen. In diesem Abschnitt gehe ich nur auf die deklarative Wissensrepräsentation ein.
Ziel von deklarativen Konstrukten ist es, möglichst allgemein Wissen über Objekte auszudrücken
bzw. abzufragen. Zur Definition von Objekten werden dabei häufig Frames genutzt. Darunter versteht man eine allgemeine Folge von hierarchisch organisierten Attribut-Wert-Paaren. Eine Sprache
um allgemeine Aussagen zu treffen ist häufig auf Basis der Prädikatenlogik aufgebaut. Hierbei nimmt
man meist Vereinfachungen gegenüber der allgemeinen Prädikatenlogik vor. Im FIPA-ACL-Standard
ist beispielsweise mit SL eine Prolog-ähnliche Sprache zur Formulierung von Aussagen in verschieden mächtigen Variationen (SL0, SL1, SL2, SL) beschrieben.
Neben den eben erwähnten Basiskonzepten Frames und Prädikatenlogik gibt es noch verschiedene
andere verwandte Konzepte zur deklarativen Wissensrepräsentation. Zu nennen sind hier insbesondere Semantische Netze, Objekt-Attribut-Wert-Tripel und Ontologien (Fensel 2001; Hesse 2002). Im
weiteren werden die wichtigsten Konzepte, Frames und Prädikatenlogik noch etwas genauer behandelt. Dann gehe ich noch auf Ontologien als verallgemeinerndes Konzept ein.
Frames
Bei Frames handelt es sich um einen Ansatz aus der objektzentrierten Wissenrepräsentation. Mit
einem Frame lassen sich Strukturen in Objekten und Beziehungen zwischen Objekten darstellen.
Dazu sind Frames als Aggregation von Aspekten (sogenannte „Slots“) definiert, die zusammen ein
stereotypes Objekt, eine stereotype Handlung oder ein stereotypes Ereignis repräsentieren. Dieses
Konzept ist vergleichbar mit Objektklassen und deren (Objekt-)Attribute. Die Slots oder Attribute
können wieder von komplexem Wert sein (d.h. ein anderes Frame enthalten). Zusätzlich zu Namen
und Wertebereich der Attribute kann angegeben werden, ob die Attribute optional sind, und es können
41
Default-Werte für Attribute definiert werden. Ein Frame beschreibt also eine Objektklasse und legt
durch die Definition von Attributen typische Merkmale dieser Klasse fest.
Neben der Nutzung von Frames in Frames zur Definition des Datentyps eines Slots können Frames in
(Vererbungs-)Hierarchien organisiert werden (is-a-Beziehung). Ein von einem anderen abgeleiteter
Frame erbt die Definition aller Attribute und Einschränkungen oder Defaultbelegungen des ElternFrames und kann selbst zusätzliche Attribute definieren oder Einschränkungen enger definieren.
Beispiel:
(defframe :user (slots (:firstname String) (:gender [’m’,’w’])))
(defframe :muser of :user (slots (:gender ’m’) (:beard Boolean)))
Prädikatenlogik
Im Gegensatz zu den objektzentrierten Frames handelt es sich bei der Prädikatenlogik um einen nichtobjektzentrierten Ansatz.
Die Logik wurde als Mittel zur Formalisierung des intuitiven Schlussfolgerungsbegriffs entwickelt.
Dazu entstanden eine Reihe von Kalkülen (logikbasierte Wissensrepräsentationsformalismen), die es
erlauben aus Axiomen mittels Ableitungsregeln Theoreme herzuleiten bzw. zu beweisen. Der für die
Wissensrepräsentation bedeutendste und der theoretisch fundierteste Kalkül ist die Prädikatenlogik
erster Ordnung. Obwohl diese weder in formalen Wissenspezifikationssprachen noch in Repräsentationssprachen in ihre ursprünglichen Form verwendet wird, dient sie häufig als Bezugspunkt oder als
Ausgangspunkt zur Entwicklung spezieller, den Anforderungen realen Domänen- oder Anwendungswissens angepasster Variationen oder Erweiterungen.
Basis der Prädikatenlogik ist die Aussagenlogik. In der Aussagenlogik werden atomare Aussagen,
wie z.B. A=„Der Mond kreist um die Erde“ und B=„Die Sonne kreist um die Erde“ durch Verknüpfungszeichen UND, ODER und NICHT zu komplexeren Aussagen, sog. Formeln, zusammengesetzt.
Ziel ist dabei die Bestimmung der Wahrheitswerte von Formeln, ohne die Aussagen inhaltlich zu
interpretieren.
Die Prädikatenlogik stellt eine Erweiterung der Aussagenlogik dar. Durch Einbeziehung von Variablen, Funktionszeichen, Prädikatzeichen (z.B. =,>,<) und Quantoren (für alle, es existiert) zusätzlich
zu den oben genannten Verknüpfungszeichen, ist es möglich, sehr komplexe mathematische Sätze zu
formulieren, welche auch Wissen kodieren können.
Ein Nachteil der nicht-objektzentrierten Wissensrepräsentation in regelbasierten Systemen ist die
mangelnde Strukturiertheit: Ausschließlich die Regeln beinhalten aktives Wissen. Bei den Fakten
hingegen handelt es sich um eine unstrukturierte und passive Menge. So stehen die in Fakten festgelegten Definitionen zweier Attribute desselben Objektes zuerst einmal isoliert nebeneinander. Eine
bessere Strukturierung gibt es in der objektzentrierten Wissensrepräsentation. Hier werden die Fakten
zu Strukturen zusammengefasst.
Als Verbindung der beiden Formen der Wissensrepräsentation sind sogenannte Beschreibungslogiken
(description logics) entstanden. Hierbei handelt es sich um Einschränkungen der Prädikatenlogik
(z.B. Verzicht auf Variablen) die um strukturierte Informationsobjekte erweitert wurden. Auf die
strukturierte Information kann zugegriffen werden und es können damit Deduktionen durchgeführt
werden.
Im Kontext von Beschreibungslogiken findet sich üblicherweise auch die Zweiteilung einer Wissensbasis in
42
3.2 Datenkonzepte
Terminologie (TBox)
Hierunter versteht man die Definition von Konzepten und Axiomen in der Domäne, die das
zugrundeliegende Modell definieren und benutzt werden können um aus Fakten neues Wissen abzuleiten. Solche Definitionen können in Form von Prädikatdefinitionen mit oder ohne
Quantoren erfolgen.
Beispiel:
is-publisher(item(X), A), has-category(X, C) ->
has-interest(A, C)
Aussagen über Einschränkungen (ABox)
Hierunter versteht man Fakten, also konkrete Aussagen über Instanzen. Häufig unterscheidet
man noch zwischen Konzepteinschränkungen, also der Definition, dass ein Objekt Instanz eines
bestimmten Konzeptes ist, und Rolleneinschränkungen, also der Definition, dass zwei Objekte
auf eine bestimmte Art miteinender in Beziehung stehen. Diese verschiedenen Typen von
Einschränkungen lassen sich aber auch als die Anwendung ein- und mehrstelliger Prädikate
sehen.
Beispiele:
is-publisher(’item-12’, ’kochm’)
item(’item-12’)
Ontologien
Der Begriff Ontologie1 steht für ein allgemeines Konzept, das verschiedene Aspekte unterschiedlicher Hilfsmittel zur Handhabung von Wissen zusammenfasst. Ontologien erlauben Ableitungen (semantische Netze), benutzen Klassifizierungen (Taxonomien), beschrieben Begriffe, auf die sich eine
Gruppe von Benutzern geeinigt hat (Thesauri), und sie dienen der Navigation in Wissensbeständen
(Verzeichnisstrukturen und Topic Maps).
Staab (2002) definiert Ontologien als formale Modelle einer Anwendungsdomäne, die dazu dienen,
den Austausch und das Teilen von Wissen zu erleichtern. Neben dieser auf (Gruber 1993) zurückgehenden Definition finden sich viele Definitionsversuche des Begriffs Ontologie über die Funktion
(siehe hierzu auch (Fensel 2001)):
„facilitate knowledge sharing an reuse“
„provide explicit conceptualization that describes semantics of data“
„provide shared and common understanding of domain that can be communicated between
people and application systems“
„provide machine-processabel semantics of information sources that can be communicated
between different agents (software and humans)“
1
Das Wort ’Ontologie’ ist zusammengesetzt aus dem Griechischen ’ontos’ für Sein und ’logos’ für Wort. Es ist eine
vergleichsweise neue Bezeichnung aus dem 19. Jahrhundert, die benutzt wird, um die Lehre vom Sein zu unterscheiden
von der Lehre des Seienden in den Naturwissenschaften. Die ursprünglich von Aristoteles benutzte Bezeichnung war
’Kategorie’. Aristoteles verwendete Kategorien, um alles, worüber gesprochen werden kann, zu klassifizieren.
43
„implemented artefact that attempts to constrain the indended meaning of a vocabulary“
Auf der methodischen Seite werden Techniken der objektorientierten Modellierung konsequent so
weiterentwickelt, dass die Modelle nicht bloß zur Strukturierung von Software dienen, sondern auch
ein explizites Element der Benutzungsschnittstelle darstellen und zur Laufzeit verwendet werden.
Auf der soziokulturellen Seite erfordern Ontologien daher die Einigung einer Gruppe von Anwendern
auf die jeweiligen Begriffe und deren Zusammenhänge.
Von diesen allgemeinen Betrachtungen wollen wir zu einer konstruktiven Definition von Ontologien
kommen. Dazu betrachten wir, welche Mittel zur Strukturierung einer Domäne in Ontologien zur
Verfügung stehen. Aktuelle Ontologie-Ansätze unterscheiden hier zwischen:
Konzepten, die wichtige Begriffe definieren und strukturieren (Klassen, Entitäten)
Eigenschaften der Konzepte (Slots, Attribute, Rollen)
Beziehungen zwischen den Konzepten
Regeln zur Generierung von zusätzlichem Wissen
Teil der Modellierung von Konzepten, Eigenschaften und Beziehungen ist dabei auch die Festlegung
der Vokabulare von Termen und Relationen.
Im Vergleich zu Frames und Prädikatenlogik sind Ontologien am ehesten mit Beschreibungslogiken
vergleichbar. Sie vereinen die Definition von strukturierten Konzepten mit der Definition von Regeln
mit denen man über Deduktion neues Wissen generieren kann.
Ontologien sind üblicherweise über Ontologie-Beschreibungssprachen definiert. Solche Beschreibungssprachen können sehr einfach (nur Definition von Konzepten), Frame-basiert (Konzepte und
Eigenschaften) oder logikbasiert sein. Beispiele für Beschreibungssprachen sind CycL (Lenat und
Guha 1990; Lenat 1995) und KIF (Genesereth 1991) als Repräsentanten der auf Prädikatenlogik basierten Sprachen, Ontolingua (Gruber 1992) und Frame-Logik (Kifer u. a. 1995) als Frame-basierte
Ansätze mit einem Prädikatenlogik-Framework. Entity-Relationship-Diagramme und UML Klassendiagramme können auch als Ontologie-Beschreibungssprachen gesehen werden. Siehe beispielsweise (Meersman 1999) für eine nähere Diskussion der Zusammenhänge und Unterschiede von Ontologien und Datenbankmodellen.
Frame-Logik wird beispielsweise als Beschreibungssprache bei Ontobroker genutzt (Fensel 2001,
S.28f). Es handelt sich dabei um eine Sprache zur Spezifikation objektorientierter Datenbanken,
Frame-Systemen und Logikprogrammen (Kifer u. a. 1995). Frame-Logik integriert verschiedene konzeptuelle Modellierungsmechanismen in ein kohärentes Logik-Framework. Dazu stellt Frame-Logik
Klassen, Attribute mit Wertebereichsbeschränkungen, is-a-Hierarchien mit verschiedenen Kombinationsmöglichkeiten und Logik-Axiome zur weiteren Spezifikation von Beziehungen zwischen den
Elementen der Ontologie und ihrer Instanzen zur Verfügung.
Wissensrepräsentation für Community-Unterstützungs-Komponenten
Von den verschiedenen Konzepten zur Modellierung allgemeiner Informationen scheint das Ontologie-Konzept das vielversprechendste zu sein. Es vereint objektzentrierte Strukturierung von Informationen sowie allgemeinere Ansätze der Prädikatenlogik zur Regel-basierten Erweiterung des
44
3.2 Datenkonzepte
Informationsraums. Insbesondere ist von Vorteil, dass zu Ontologien momentan im Kontext des Forschungsbereichs „Semantic Web“ vielfältige Konzeptions- und Implementierungsarbeiten laufen. So
werden auch die Anwendungen von Ontologien in Wissensmanagement-Portalen und Online-Communities untersucht (Staab u. a. 2000).
Für die Wissensrepräsentation in und zwischen den zu konzipierenden Community-UnterstützungsKomponenten wird deshalb ein Ontologie-basierter Ansatz gewählt. Daten werden als Objekte mit
Slots (Attributen) und als Beziehungen zwischen diesen Objekten definiert.
Dabei wird folgende Konkretisierung vorgenommen:
Konzepte werden als Klassen (Frames) definiert.
Zwischen den Konzepten können ‘is-a’-Beziehungen definiert werden.
Weitere Beziehungen zwischen Konzepten können optional über Regeln repräsentiert werden.
Zu den Konzepten werden Attribute definiert. Eine Attributdefinition beinhaltet die Definition
von Attributnamen, Wertebereich und von optionalen Default-Werten.
Manche der Attribute definieren Beziehungen zwischen konkreten Instanzen der Konzepte Ein Beispiel dafür ist das Attribut “publisher” bei Inhalten, über das eine Beziehung zu konkreten Benutzern (Benutzerobjekten) hergestellt wird.
Durch Regeln können über die Attribute (Wertebereiche, explizite Beziehungen zwischen Instanzen) hinausgehende Informationen repräsentiert werden.
In der weiteren Arbeit identifiziere ich nun zuerst die Basisdatenkonzepte und modelliere diese mit
ihren Attributen und Beziehungen untereinander. Bei Bedarf werden dazu dann auch noch Regeln
angegeben, die komplexe Abhängigkeiten kodieren oder neue Konzepte definieren. Durch geeignete
Wahl der Konzepte und Regeln ist die angestrebte Generalität und einfache Erweiterbarkeit realisierbar.
Verwandte Arbeiten zur Informationsmodellierung in einem speziellen Anwendungsbereich finden
sich bei der Erarbeitung von Datenrepräsentationsstandards (Festlegungen von Konzepten und Vokabularen) für andere Domänen. Dies wurde in letzter Zeit vor allem für Domänen rund um Electronic
Business und Customer Relationship Management vorangetrieben. Beispiele für solche Standards
sind ebXML (siehe dazu www.ebxml.org) oder das BizTalk-Framework von Microsoft.
3.2.2
Benutzerbeiträge
Bei Beiträgen eines Benutzers zum Community-Informationsraum können die folgenden Basistypen
unterschieden werden:
Neue Information zur Kenntnisnahme durch (nicht genauer spezifizierte) andere CommunityMitglieder
Kommentare und Bewertungen zu existierenden Informationen (auch wieder zur Kenntnisnahme aller Mitglieder)
Mitteilungen an eine spezifische Empfängergruppe
45
Informationen zu sich selbst (zur Kenntnisnahme durch andere Mitglieder)
Bei Informationen zum Benutzer selbst handelt es sich um Benutzerprofilinformationen. Diese werden in Abschnitt 3.2.4 und in Kapitel 4 näher behandelt. Es bleiben als Benutzerbeiträge noch Informationen für den Community-Informationsraum, Kommentare zu diesen Informationen im Community-Informationsraum und Mitteilungen. Während Mitteilungen an eine spezifische Untermenge
der Community-Mitglieder gerichtet sind, die zum Zeitpunkt des Abschickens festgestellt wird (vergleichbar zu E-Mail), stehen Informationen und Kommentare zu Informationen allen Mitgliedern
einer (Unter-)Community zur Verfügung und werden persistent auch für zukünftige Mitglieder gespeichert.
J. Koch (2002a, S.44) definiert im Zusammenhang mit der Ermittlung von Benutzerinteressen Artefakte und Items als „Instanz einer Repräsentation von Information, mit der der Nutzer zu tun hat“. Wir
schränken im Folgenden den Item-Begriff ein auf Informationen, die von Community-Mitgliedern
explizit für andere Community-Mitglieder publiziert worden sind.
Informations-Items
Ein Vorteil von Community-Informationssystemen ist die Möglichkeit der automatischen Filterung
von Informationen - und dadurch die Handhabbarmachung größerer Informationsmengen.
Um eine Filterung und Suche im Informationsraum zu erlauben, sollten die Informationen zumindest
semi-strukturiert sein. D.h. neben den (Freitext-)Inhalten, die nur für andere Benutzer bestimmt sind,
müssen strukturierte Meta-Informationen enthalten sein, die automatisch ausgewertet werden können.
Nachdem es verschiedene Informationstypen mit verschiedenen Meta-Informationen geben kann,
empfiehlt sich eine Typisierung der Informations-Objekte (oder (Informations-)Items, wie sie im Weiteren genannt werden). Jedem Item-Typ sind eine Menge von notwendigen und optionalen Attributen
zugeordnet, welche auch Freitext oder sonstige unstrukturierte Daten enthalten können.
Bei der Realisierung unserer verschiedenen Beispiel-Plattformen (siehe Kapitel 5) haben wir beispielsweise die folgenden Typen identifiziert und ausgeführt:
Mitteilung
Terminankündigung - mit verschiedenen Untertypen für die Art des Termins, der angekündigt
wird (z.B. einmalig, regelmäßig)
Bookmark
Literaturreferenz - mit verschiedenen Untertypen für Zeitschriftenartikel, Bücher, Konferenzbände, Beiträge in Konferenzbänden etc.
Konferenzankündigung
Jobankündigung
Projektankündigung - mit Untertypen für die einzelnen Projekte, z.B. an der Universität Systementwicklungsprojekte und Diplomarbeiten
Wie man an den Beispielen sieht, handelt es sich bei den Typen um einen Wald von Typkonzepten,
die teilweise aufeinander aufbauen bzw. voneinander abgeleitet sind.
46
3.2 Datenkonzepte
Damit die Verwaltung der Information nicht in durch Typen getrennte Bereiche zerfällt, sondern über
Typgrenzen hinweg funktioniert, ist es notwendig eine gemeinsame Menge von Attributen für alle
Items festzulegen. Aus den Anforderungen an die Attribute der einzelnen Typen haben wir deshalb
folgende Basisattribute für alle Typen abgeleitet:
Titel (title)
Abstract/Beschreibung (content)
Gültigkeitsdatum (expirationdate)
Zeitraum (startdate, enddate)
Ort (location)
Attribute wie Titel und Beschreibung müssen dabei in mehreren Sprachversionen vorliegen können.
Die Attribute zur Spezifikation eines Ort und einer Zeit(spanne) werden vor allem für kontextsensitive Dienste wie im Projekt Cosmos (siehe Abschnitt 5.5) benötigt. Neben den Basisattributen sind
noch Attribute notwendig, die Informationen über den Erzeuger eines Items, das Erzeugungsdatum,
Identität des Benutzers, der die letzte Änderung vorgenommen hat, und Datum der letzten Änderung
geben.
Das Grundkonzept des Items wird also folgendermaßen modelliert:
ITEM
Slot
title[sprache]
Beschreibung
Titel in unterschiedlichen Sprachversionen
Typ
String
content[sprache]
Textinhalt (unstrukturiert) des Items in
unterschiedlichen Sprachversionen
String
startdate
Bei Veranstaltung der Zeitpunkt des Starts,
ansonsten Termin, ab dem die Mitteilung
anderen zu Kenntnis gebracht werden soll
Bei Veranstaltungen der Endezeitpunkt
Zeitpunkt bis zu dem die Mitteilung
aktuell ist, d.h. ab dem sie nicht mehr
angezeigt werden soll und automatisch
gelöscht werden kann
Ort auf den sich das Item bezieht
Ersteller des Items
DateTime
enddate
expirationdate
location
creatorlogin
creationdate
updatelogin
updatedate
Zeitpunkt der Erstellung
Benutzer, der die letzte Änderung am Item
durchgeführt hat
Zeitpunkt der letzten Änderung
Wertebereich
Kodierung der
Sprache nach
ISO 639 (siehe
auch RFC1766)
Kodierung der
Sprache nach
ISO 639
DateTime
DateTime
Coordinates
USER
DateTime
USER
Referenz
auf
Konzept USER
Referenz
auf
Konzept USER
DateTime
Durch die Attribute ‘creatorlogin’ und ‘updatelogin’ werden Beziehungen zum Konzept USER definiert:
47
is-created-by(ITEM, USER), is-creator(USER, ITEM)
is-updated-by(ITEM, USER), has-updated(USER, ITEM)
Neben den Standarddatentypen String, Text und DateTime werden dabei die Datentypen USER und
Coordinates benutzt. USER verweist auf einen registrierten Benutzer und Coordinates gibt Information zu einem Ort. Die Kodierung von Ortsinformation wurde im Projekt Cosmos erarbeitet (siehe
hierzu u.a. (Groh 2002) und (Koch u. a. 2002a)).
Basierend auf dem allgemeinen Item-Frame können Frames für spezielle Item-Typen definiert werden. Dabei können, wie bei Frames besprochen, zusätzliche Attribute definiert oder die Wertebereiche
bzw. Defaultwerte vorhandener Attribute geändert werden. Neben den besprochenen Attributen muss
zu einem Item also auch immer gespeichert werden, auf welcher Klasse (Item-Typ) es basiert.
Item-Attachments
In der praktischen Anwendung hat sich gezeigt, dass die Items sehr hilfreich zur Kodierung von
Community-Wissen sind. Benutzer haben aber häufig den Wunsch geäußert, zu Items noch Binärdateien oder Links auf Informationen und Dateien außerhalb des Community-Informationsraums
speichern zu können. Um dies zu ermöglichen, wurde das Item-Modell noch um sogenannte ItemAttachments erweitert, welche solche Links oder Binärdateien kodieren.
ITEMATTACHMENT
Slot
Beschreibung
title
Titel/Teaser des Anhangs (eventuell
wieder in unterschiedlichen
Sprachbersionen)
mimetype
(Medien-)Typ des Anhangs
size
uri
content
publisher
publisheddate
Länge des Anhangs in Bytes
URI-Verweis auf externen Anhang
Inhalt bei lokalen Anhängen
Benutzer, der den Anhang dem Item
zugeordnet hat
Zeitpunkt der Erstellung/Zuordnung des
Anhangs
Typ
String
Wertebereich
String
Typname nach
RFC2046, 2048
Integer
RFC2396
Blob
USER
Referenz
auf
Konzept USER
DateTime
Wie beim Konzept Item definieren manche der Attribute wieder Beziehungen zum Konzept Benutzer. Nicht als Attribute aufgenommen sind zusätzliche Informationen, welche eine Beziehung zum
Konzept Item definieren:
USER
is-publisher(USER, ITEMATTACHMENT),
is-published-by(ITEMATTACHMENT, USER)
ITEM
has-attachment(ITEM, ITEMATTACHMENT),
is-attachment-from(ITEMATTACHMENT, ITEM)
48
3.2 Datenkonzepte
Item-Kommentare
Eine Community lebt von „warmer“ (d.h. personenbezogener) Information und von der Kommentierung der Information (d.h. von indirekten Konversationen basierend auf Informationsitems). Kommentare könnten als eigenständige Items gesehen werden, die über eine spezielle Beziehung mit den
Item, die sie kommentieren in Beziehung stehen. Dadurch ließen sich beliebige Verbindungen zwischen Items und Kommentaren und auch zwischen Kommentaren selbst modellieren. In der Praxis
hat sich allerdings gezeigt, dass es sinnvoll ist, Kommentare zu Items als eigenes Konzept vorzusehen.
Dies kann wahlweise als Ableitung vom Item-Konzept oder unabhängig davon geschehen. Wir haben
uns dafür entschieden Item-Kommentare als Spezialisierung des Item-Konzeptes zu modellieren. Damit stehen die vielen Möglichkeiten von Items (z.B. Anhänge) automatisch auf für Item-Kommentare
zur Verfügung. Außerdem ist es damit einfach möglich Kommentare zu Kommentaren zu nutzen.
Der erste Typ von Kommentar, der hier vorzusehen ist, ist der Freitextkommentar. D.h. ein Kommentar in Form von frei eingegebenem Text (oder als Grafik, Audio oder Video), der nur zur Interpretation
durch andere Benutzer vorgesehen ist. Hierbei sind zwei Varianten möglich:
Konversation: Jeder Benutzer darf zu jedem Item mehr als einen Kommentar abgeben - die
Kommentare werden entweder chronologisch sortiert oder falls sie auf vorhergehende Kommentare bezogen sind in Baumstrukturen organisiert. Das Informationsitem stellt in diesem
Fall nur noch einen Kontext für die Konversation dar.
Kommentar: Jeder Benutzer darf zu jedem Item genau einen Kommentar abgeben. Das publizieren eines neuen Kommentars (einer neuen Bewertung) überschreibt den bisher gesetzten
Kommentar.
Freitextkommentare unterstützen die (indirekte) Kommunikation zwischen den Community-Mitgliedern im Kontext von Informationsitems. Sie erlauben allerdings keine automatische Gewinnung von
Information zu den Benutzern oder automatische Zusammenfassung. Zu diesem Zweck werden häufig zusätzlich zur Freitexteingabe konkrete Bewertungen von Items erlaubt. Diese Information kann
dann automatisch ausgewertet werden.
ITEMANNOTATION extends ITEM
Slot
Beschreibung
rating
Bewertung des Items
Typ
Real
Wertebereich
[0, 1]
Kommentare erben vom Konzept Item Beziehungen zu User und ItemAttachment. Zusätzlich stehen
sie zum Konzept Item folgendermaßen in Beziehung:
ITEM
annotation-for-item(ITEMANNOTATION, ITEM),
has-annotation(ITEM, ITEMANNOTATION)
Beispiel für weitere Informationen, die über Regeln aus den vorhandenen Informationen gewonnen
werden können:
has-annotated(USER(x), ITEM(i)):
es gibt ITEMANNOTATION(a):
49
has-annotation(i, a), is-publisher(x, a)
is-co-annotator(USER(x), USER(y)):
es gibt ITEM(i):
has-annotated(x, i) AND has-annotated(y, i)
Mitteilungen
Am Anfang dieses Abschnitts wurde unterschieden zwischen Informationen, die Community-Mitglieder (außerhalb eines speziellen Kontextes) für nicht näher definierte Benutzergruppen beitragen die Items -, Kommentare zu diesen Items und Mitteilungen an eine mehr oder weniger genau spezifizierte Menge von Benutzern.
Der Unterschied zwischen Items und Mitteilungen war, dass Items in den Community-Informationsraum aufgenommen werden, während Mitteilungen nur der spezifizierten Mitgliedergruppe zugestellt
werden und Mitgliedern, die später hinzukommen nicht mehr zur Verfügung stehen.
Was bei Items Attribute bzw. Meta-Informationen sind, ist bei Mitteilungen die Empfängerspezifikation. In den verschiedenen Projekten wurden dazu die folgenden Anforderungen erarbeitet:
konkrete Empfängerliste
Empfänger durch Attribute definiert
– Standort der Empfänger
– beliebige andere Benutzerattribute
MESSAGE
Slot
subject
content
recipientspec
sender
sendtime
Beschreibung
Titel der Nachricht
Inhalt der Nachricht
Spezifikation der Empfänger
der Nachricht
Typ
String
Text
String
Sender der Nachricht
Zeitpunkt des Versendens
USER
DateTime
Wertebereich
Abfrage über Attribute im
Benutzerprofil (siehe auch
Abschnitt 4.4.1)
Referenz auf Konzept USER
Durch das Attribut ‘sender’ wird eine Beziehung zum Konzept USER definiert:
is-sent-by(MESSAGE, USER), is-sender(USER, MESSAGE).
3.2.3
Domäneninformation - Kategorisierung
Im Informationsmanagement hat sich in den letzten Jahren eine zweistufige Auszeichnung von Information durchgesetzt. Einerseits werden Informationsobjekte Meta-Informationen zugeordnet um eine Suche und Filterung zu erlauben. Diese Meta-Informationen sind in Item-Typ-Schemata
festgehalten. Auf der anderen Seite werden häufig als spezielle Meta-Information Einordnungen in
Kategorien vorgesehen. Das bedeutet, dass eine Menge von Kategorien definiert wird und Items einer
oder mehrere dieser Kategorien zugeordnet werden können.
50
3.2 Datenkonzepte
Bei Kategorien handelt es sich allgemein um eine Strukturierung der Domäne über Konzepte mit
Attributen wie Titel (in verschiedenen Sprachen), die untereinander in Beziehung stehen können. Mit
der Relation sub-category() können die Kategorien in einem Wald angeordnet werden, mit der
Relation related-to() können Beziehungen zwischen den Kategorien dokumentiert werden, die
nicht in den Baumstrukturen zum Ausdruck kommen.
In dieser Arbeit beschränken wir uns auf Kategorien und Itemtypen als Mittel der Domänenmodellierung. Über Kategorien werden von Benutzer beigetragene Informationen und Benutzer selbst mit
der Domäne und damit wieder miteinander in Beziehung gebracht.
Kategorien können entweder durch die Designer einer Community-Plattform vorgegeben werden
oder sogar dynamisch von den Community-Mitgliedern erzeugt und ergänzt werden. Ansätze dazu finden sich beispielsweise in (Farquhar u. a. 1995).
CATEGORY
Slot
title[sprache]
Typ
String
Wertebereich
creator
Beschreibung
Name der Kategorie in verschiedenen
Sprachversionen
Erzeuger der Kategorie
USER
Referenz
auf
Konzept USER
creationtime
Zeitpunkt der Erzeugung der Kategorie
DateTime
Kategorien dienen hauptsächlich der Einordnung der Kernkonzepte Item und USER:
CATEGORY
sub-category(CATEGORY, CATEGORY)
related-to(CATEGORY, CATEGORY)
ITEM
is-of-category(ITEM, CATEGORY)
USER
is-interested-in(USER, CATEGORY)
Über die Kategorien können dann weitere Beziehungen definiert werden:
is-interested-in(USER x, ITEM i):
is-interested-in(x, CATEGORY(c)), is-of-category(i, c)
3.2.4
Benutzerdaten
Neben Benutzerbeiträgen müssen Daten zu den Benutzern (Community-Mitgliedern) selbst gespeichert werden. Solche Daten werden von der Plattform selbst für Matchmaking und Personalisierung
benötigt und werden im Rahmen von Awareness-Funktionalitäten anderen Benutzern präsentiert.
Wir unterscheiden bei Benutzerdaten Daten zu einem einzelnen Benutzer (die sogenannten Benutzerprofile) und Daten zur Untergliederung der Benutzer in Untergruppen.
Benutzerprofile
Das Thema Benutzerprofile wird ausführlich in Kapitel 4 behandelt. Dort werden u.a. auch die wichtigsten Teile eines Benutzerprofils motiviert und ausgearbeitet. Konkret handelt es sich dabei um
51
demographische Daten
Informationen zu Interessen
Informationen zu Bewertungen
Informationen zu Beziehungen zu anderen Benutzern
Informationen zu Voreinstellungen/Präferenzen
PIM-Informationen
Zu den Informationen zu Beziehungen zu anderen Benutzern gehören die auf vielen CommunityPlattformen zu findenden Buddylisten. Dabei handelt es sich um Listen von Benutzern, zu denen
der Profil-Eigentümer in einer speziellen Beziehung steht. Die Art der Beziehung wird durch den
Namen der Liste ausgedrückt. Jeder Benutzer kann eine oder mehrere persönliche Buddylisten anlegen. Durch die Ermöglichung verschiedener Buddylisten haben wir eine allgemeine Möglichkeit zur
Erfassung von Beziehungen zwischen Community-Mitgliedern geschaffen. In Abschnitt 4.3.3 wird
dieses Thema noch weiter ausgeführt.
Nachfolgende eine vereinfachte Modellierung eines Benutzerprofils als Menge von Attributen:
USER
Slot
basic.firstname
basic.lastname
basic.gender
pim.network.buddylist.family
...
Beschreibung
Vorname
Nachname
Geschlecht
Buddylist ’family’
Typ
String
String
Character
Set of USER
Wertebereich
’m’, ’w’
Im Buddylist-Attribut ist dabei eine Beziehung zwischen USER-Instanzen definiert:
USER
is-buddy-of(USER, LISTNAME, USER)
Untergruppen
In Communities finden sich häufig verschiedene nicht-disjunkte Untergruppen (Sub-Communities),
die Mitglieder zusammenfassen, die sich mit einem Teilaspekt der ganzen Community beschäftigen.
Diese Information und die dadurch ausgedrückte Beziehung der Mitglieder einer solchen Untergruppe soll dokumentiert werden um darüber Mitteilungen adressieren zu können, Items in den Zugriffsrechten einzuschränken oder spezielle Awareness-Informationen anzeigen zu können.
Zur Dokumentation dieses Zusammenhangs haben wir sogenannte „SharedBuddyLists“ eingeführt.
Wie der Name schon sagt, handelt es sich dabei nach dem Modell der Buddylists um Listen von
Mitgliedern, die unter einem bestimmten Titel geführt werden. Im Gegensatz zu Buddylists sind
diese Listen aber nicht einem speziellen Benutzerprofil zugeordnet, sondern sind für alle Personen,
die auf der Liste aufgeführt sind, (lesend und schreiben) zugänglich. Während persönliche Buddylists
Teil des Profils eines Benutzers sind und nur von diesem gepflegt und eingesehen werden können, sind
52
3.2 Datenkonzepte
SharedBuddyLists öffentlich sichtbar (wenn nicht explizit eingeschränkt) und jedes Mitglieder einer
SharedBuddyList kann andere Community-Mitglieder auf die Liste setzen.
Neben der Analogie zu Buddylists kann auch eine Analogie zu Kategorien gesehen werden. Bei SharedBuddyLists handelt es sich um Kategorien, denen nicht nur ein Name, sondern auch eine Menge
von Mitgliedern zugeordnet ist. Nachdem SharedBuddyLists wie Kategorien zur Spezifikation von
Interesse und zur Spezifikation von Empfängern für Nachrichten benutzt werden sollen, modellieren
wir sie als Spezialisierung von Kategorien.
SHARED-BUDDYLIST extends CATEGORY
Slot
Beschreibung
access
Zugang und Sichtbarkeit
Typ
String
Wertebereich
[public, closed,
invisible]
Benutzer stehen zum Konzept SHARED-BUDDYLIST über die Beziehung is-member-of() in
Verbindung:
is-member-of(USER, SHARED-BUDDYLIST)
3.2.5
Nutzung von Ontologien und Kontext-Information
Die drei Basis-Datenkonzepte User, Item und Category werden also als Attribut-Wert Paare dargestellt. Zu jedem der Datenkonzepte gibt es eine Hierarchie von Klassen, welche definieren, welche
Attribute mit welchem Datentyp in der Klasse definiert sind. In unserer Prototypimplementierung
sind diese Klassen für jedes der Datenkonzepte durch eine eigene Ontologie definiert.
Einen wichtigen Teil der Attribute machen bei allen drei Basis-Datenkonzepten die Attribute aus, die
auf andere Datenkonzepte verweisen. Dabei sind Verweise auf ein konkretes Entity oder auf eine
Menge von Entities möglich. Wir haben in der Prototypimplementierung weiterhin vorgesehen, dass
man angeben kann, von welcher Unterklasse die referenzierten Entitäten sein müssen. Mit diesem
Hilfsmittel können alle in den vorhergehenden Abschnitten besprochenen Attribute definiert werden.
Bei der Nutzung solcher Referenzen hat sich insbesondere bei USER-USER Referenzen (siehe hierzu
auch das folgende Kapitel), aber auch bei anderen Referenztypen gezeigt, dass zur automatischen
Nutzung noch zusätzliche Information über den Typ der Referenz oder Beziehung notwendig ist. Wir
haben dies durch die Aufwertung der Referenzen zu einem zusätzlichen Basis-Datenkonzept, den
sogenannten „Kontexten“ (Context), gelöst.
Ein Kontext stellt die Verbindung eines Quellobjekts zu einem oder mehreren Zielobjekten dar. Neben
der Festlegung der Typen von Quell- und Zielobjekten können zu einem Kontextobjekt wie bei allen
anderen Datenkonzepten weitere Attribute definiert werden. Auch können und sollen verschiedene
Klassen für Kontextobjekte definiert werden. Beispielklassen für Kontextobjekte wären die UserUserSet-Beziehung und davon abgeleitet die Buddylist-Beziehung (mit dem Attribut des BuddylistNamens). Bei Attributen, welche auf andere Datenkonzepte verweisen, wird nun die Kontextklasse
angegeben um die Beziehung näher zu spezifizieren.
Genauere Informationen zu dem Kontextkonzept und seiner Realisierung finden Sie in der Spezifikation zum Cobricks-2 System2 .
2
Siehe http://www.cobricks.de/
53
3.2.6
Zusammenfassung
In diesem Abschnitt haben wir eine in Inhalts-, Benutzer- und Domänen-Konzepte unterteilte Framebasierte Modellierung der Basisdatenkonzepte bei der Community-Unterstützung und der Beziehungen zwischen diesen Konzepten vorgestellt (siehe auch Abbildung 3.1). Als zusätzliches Konzept zur
Beschreibung der wichtigen Referenzen zwischen den Datenkonzepten wurden die Kontexte eingführt, welche wie die anderen Basisdatenkonzepte Frame-basiert modelliert wurden. Diese FrameModellierung für alle Datenkonzepte ist einfach um Regeln für eine Ontologie-basierte Modellierung
erweiterbar.
Item
buddylist
published-by
Item
Annotation
User
ItemAttachment
f- o ry
i s go
te
ca
i nt
er
es
in t edme
mb
o f er-
Item
Item
User
annotates
Context
SharedBuddy
List
Category
related-to
subcategory
Category
Abbildung 3.1: Datenkonzepte und Verbindungen der Konzepte
3.3
Community-Dienste
Ziel dieses Kapitels ist es, Komponenten und Schnittstellen zu identifizieren, mit deren Hilfe einfach
adaptierbare Community-Plattformen aufgebaut werden können, die dann auch einfach miteinander
interagieren können. Im vorangegangenen Abschnitt wurden dazu als ersten Schritt die Datenkonzepte identifiziert und modelliert. In diesem Abschnitt sollen die Komponenten der Plattform selbst
herausgearbeitet werden. Über die Beschreibung in diesem Abschnitt hinausgehende Details finden
Sie in der Spezifikation der Prototypimplementierung zu dieser Arbeit, dem Cobricks-System 3 .
3
Siehe hierzu http://www.cobricks.de/
54
3.3 Community-Dienste
3.3.1
Komponenten und Funktionalitäten
Bei der Identifikation der Komponenten werden die schon in Kapitel 2 ausgearbeiteten Basisdienste
herangezogen:
Inhalteverwaltung
Kategorienverwaltung und Benutzerlistenverwaltung
Kontextverwaltung
Awareness/Matchmaking
Personalisierung
Die Grundmodule orientieren sich also entweder an den Basisdaten, die in der Plattform verwaltet werden sollen, und machen diese über öffentliche Methoden nach außen verfügbar (für andere
Komponenten oder andere Plattformen), oder an Basisdiensten, die dem Benutzer zur Unterstützung
angeboten werden sollen.
Der im letzten Abschnitt angesprochenen großen Bedeutung der Referenzen zwischen den Datenobjekten tragen wir durch eine zusätzliche Komponente zur Verwaltung der Kontexte Rechnung. Hier
wird alle Kontextinformation (explizite und implizit in den anderen Komponenten definierte) an einer
Stelle gesammelt und zur Verfügung gestellt.
Nachdem Komponenten unabhängig von einer Benutzungsschnittstelle sein sollten und für mehrere
Benutzungsschnittstellen zur Verfügung stehen sollten, gibt es zusätzlich noch Komponenten zur
Realisierung von Benutzerinteraktion. Weiterhin existieren noch Komponenten zur Realisierung von
Datenaustausch mit anderen Plattformen (siehe Abbildung 3.2).
Web portal
Personalisierung
Inhalte
und
Anmerkungen
Kategorien
Matchmaking
Benutzerprofil
Kontexte
Mitteilungen
Import/
Export
Abbildung 3.2: Community-Unterstützungssystem Architekturüberblick
Wie in Kapitel 4 noch ausführlich diskutiert wird, verfolgen wir bei der Benutzerdatenverwaltung
einen Ansatz, der Datenspeicherung und Dienste voneinander trennt. Aus diesem Grund ist die Verwaltung ausgelagert. In den Plattformen gibt es nur eine Komponente, welche die Daten der lokal
registrierten Benutzer zwischenspeichert.
55
Ein ähnlicher Ansatz wäre auch bei der Datenverwaltung für Items vorstellbar. Hier wird aber eine Plattform-zentrierte Verwaltung verfolgt. Grund dafür ist, dass die auf Community-Plattformen
gesammelten Informationen meist sehr speziell für die Community erstellt sind oder von den Mitgliedern gar nicht nach außen weitergegeben werden wollen. In unserem Modell ist ein Datenaustausch
zwischen Plattformen vorgesehen. Beim Einsatz von Prototypen der Plattform haben wir aber festgestellt, dass nur wenig Interesse an dieser Funktionalität besteht. Stattdessen wird der Ansatz des
Ansprechens mehrerer Plattformen über Benutzer-Agenten weiter verfolgt (siehe auch Abbildung
3.3).
Web portal
Personalisierung
HTTP
Kategorien
Inhalte
und
Anmerkungen Kontexte
Matchmaking
Benutzerprofil
Mitteilungen
BenutzerAgent
RPC
Import/
Export
RPC
Web portal
Personalisierung
Kategorien
Inhalte
und
Anmerkungen Kontexte
IDRepository
Matchmaking
Benutzerprofil
Mitteilungen
Import/
Export
Abbildung 3.3: Interaktion mit und zwischen Community-Plattformen
Unser Grundmodell für modulare, parametrisierbare Community-Plattformen sieht also folgendermaßen aus:
zentrale Benutzerprofilverwaltung (IDRepository)
verschiedene Community-Plattformen
– Benutzerprofilcache
– Inhalteverwaltung
– Kategorienverwaltung und Benutzerlistenverwaltung
– Kontextverwaltung
– Mitteilungsmanagement
– Awareness/Matchmaking
– Personalisierung
– Web-Benutzungsschnittstelle (für Web-Zugriff auf die eine Community-Plattform)
– Datenaustauschkomponente (zum Austausch mit anderen Plattformen)
verschiedene Endbenutzer-Clients (Benutzer-Agenten), die auf ein oder mehrere Plattformen
zugreifen
56
Die Aufteilung von Benutzerprofilverwaltung, Community-Plattform und Endbenutzer-Clients spiegelt eine mögliche Aufteilung auf Rechner und Verantwortungsbereiche wieder.
Die Komponenten kommunizieren über klare Schnittstellen miteinander. Dabei sind sowohl direkte
Funktionsaufrufe als auch der Empfang von Ereignismeldungen möglich. In folgenden Abschnitten
werden die einzelnen Komponenten noch näher herausgearbeitet.
3.3.2
Ein zentraler Dienst bei der Community-Unterstützung ist die Erfassung und Verfügbar-Machung von
Information zu den Community-Mitgliedern. Dabei ist zu unterscheiden zwischen der Bereitstellung
für Dienste der Plattform wie die Personalisierung und der Bereitstellung direkt für andere Benutzer
(für Awareness-Dienste).
Herausforderungen bei der Handhabung von Benutzerprofilen sind neben der Modellierung der Informationen die Beschaffung der Information und die Garantierung der vom Benutzer gewünschten
Privatheit.
Dieses Thema soll in diesem Abschnitt nur gestreift werden. Es wird separat in Kapitel 4 dieser
Arbeit behandelt.
(Lokale) Rechteverwaltung
Ein Teil der Benutzerprofilverwaltung ist die Funktionalität, die lokale Zugriffsrechte auf einer Plattform definiert. Die Grundphilosophie bei Communities ist dazu zuerst einmal, dass alle Mitglieder
dieselben Rechte haben. Eine sinnvolle Festlegung wäre hier:
Jeder (angemeldete) Benutzer darf Inhalte erzeugen
Jeder Benutzer darf (beliebige) Inhalte annotieren
Jeder Benutzer darf die von ihm erzeugten Inhalte und Annotationen modifizieren und löschen
Jeder Benutzer darf Mitteilungen versenden
Jeder Benutzer darf die (öffentlichen) Informationen zu anderen Benutzern durchsuchen und
einsehen
Jeder Benutzer darf Kategorien anlegen, editieren und löschen
In der Praxis hat sich allerdings gezeigt, dass teilweise Nutzer (Administratoren, Moderatoren) mit
zusätzlichen Rechten ausgestattet werden sollen und teilweise Rechte eingeschränkt werden sollen.
Aus diesem Grund haben wir uns dazu entschlossen, die Rechte nicht fest in die Plattform zu kodieren, sondern separat als Teil der lokalen Benutzerverwaltung zu verwalten. Konkret sind für die
einzelnen Objekte, die auf einer Plattform existieren, und alle Aktionen, die auf ihnen möglich sind,
Rechte (capabilities) definiert. Diese Liste ist für neue Komponenten erweiterbar. Rechte können
der breiten Basis an Arbeiten zu rollenbasierter Zugriffskontrolle (z.B. (Ferraiolo und Kuhn 1992))
folgend in Form von Rollen zusammengefasst werden und dann Benutzern zugewiesen werden.
57
USERComponent
searchUser(query) -> Set of USER
getUserAttribute(USER, aname) -> Object
setUserAttribute(USER, aname, avalue)
getUserModel(USER) -> USERMODEL
createUser() -> USER
deleteUser(USER)
getPermissions(USER) -> Set of CAPABILITY
checkPermission(USER, CAPABILITY)
addPermission(USER, CAPABILITY)
removePermission(USER, CAPABILITY)
3.3.3
Inhalteverwaltung
Aufgabe der Inhalteverwaltung ist die Verwaltung im vorherigen Hauptabschnitt behandelten Items
und aller Daten, die mit diesen Items zu tun haben. Das sind im einzelnen:
Items und Item-Anmerkungen (Instanzen)
Item-Anhänge
Einordnungen von Items in Kategorien (allgemein (Kontext-)Referenzen von Items auf andere
Datenobjekte)
Diese Daten müssen erzeugt, abgefragt, aktualisiert und gelöscht werden können. Hierfür müssen an
der Schnittstelle der Komponente Methoden angeboten werden.
Um die Berücksichtigung der Zugriffsrechte zu garantieren, ist es nun notwendig, dass die Identität
des aufrufenden Benutzers bei der Durchführung der Anfrage bekannt ist. Nachdem die Durchführung der Authentifizierung von der konkreten Benutzungsschnittstelle abhängig ist, müssen hier verschiedene Möglichkeiten vorgesehen werden. Dies wird durch folgendes zweistufige Vorgehen realisiert: Auf der untersten Ebene gibt es eine Funktion, die die Identität des aufrufenden Benutzers als
Aufrufparameter geliefert bekommt. Diese Funktion kann aber nur innerhalb des Prozesskontextes
aufgerufen werden (also beispielsweise von der Web-UI-Komponente, welche die Authentifizierung
durchgeführt hat). Nach Außen bietet die Komponente oder die Komponentenplattform eine entsprechende Funktion an, welche die Identität eindeutig ermittelt und diese Information an die innere
Schicht weitergibt.
Die konkrete Abwicklung des Zugriffs und des Umgangs mit Items wird in der Benutzungsschnittstelle realisiert. In der Item-Komponente müssen aber die Basis-Unterstützungsmöglichkeiten vorgesehen werden: Pull-Zugriff, d.h. der Benutzer (bzw. sein Client) fragt explizit nach Items, die einer
gewissen Spezifikation genügen, und Push-Zugriff, d.h. der Benutzer oder sein Client haben implizit
oder explizit Interesse registriert und erhalten automatische Mitteilungen zu neuen oder gerade zum
Kontext passenden Items.
Sowohl beim Pull- als auch beim Push-Zugriff stellt sich die Frage, wie Anfragen an die Daten
(Suchanfragen) spezifiziert werden können. Wichtig hier ist, dass keine Einschränkungen für spätere
Erweiterungen der Datenmodelle entstehen. Nachdem die Inhaltedaten auch mit Benutzerdaten und
Kategoriendaten in Verbindung stehen, sollten Anfragen auch auf diese Beziehungen ausgedehnt
58
werden können. Wir haben hierzu eine Lösung entwickelt, die auf allgemeinen Abfragesprachen
basiert. Diese Lösung wird in Abschnitt 3.4 näher vorgestellt.
Während Pull-Zugriffe einfach durch Methodenaufruf realisiert werden, muss für Push-Zugriff noch
mehr festgelegt werden. Als Grundannahme wird dazu davon ausgegangen, dass alle Information
über Interessen (sowohl explizit ausgesprochene Abonnements als auch implizit aus anderen Informationen zum Benutzer ableitbare Informationen) im Benutzerprofil gespeichert sind und somit von
der Benutzerprofilkomponente verwaltet werden. Die Funktionalität um aus Neuigkeiten Mitteilungen zu generieren, könnte nun in der Item-Komponente, in der Benutzerprofilkomponente, in der
Message-Komponente oder in einer neuen Komponente angesiedelt werden. Nachdem eine solche
Komponente, die aus Benutzerinteressen und Ereignissen Mitteilungen generiert nicht nur auf ItemEreignisse beschränkt sein sollte, verbietet sich eine Ansiedlung in der Item-Komponente. Nachdem
es sich allgemein um ein „über Ereignisse in der Community auf dem Laufenden bleiben“ handelt,
haben wir uns dafür entschieden, die Funktionalität in einer neuen Awareness-Komponente anzusiedeln (siehe hierzu auch Abschnitt 3.3.6).
ITEMComponent
createItem(USER, ITEMTYPE) -> ITEM
deleteItem(USER, ITEM)
updateItem(USER, ITEM, aname, avalue)
addItemAnnotation(USER, ITEM, ITEMANNOTATION)
removeItemAnnotation(ITEMANNOTATION)
updateItemAnnotation(ITEMANNOTATION, aname, avalue)
addItemAttachment(USER, ITEM, ITEMATTACHMENT)
removeItemAttachment(ITEMATTACHMENT)
updateItemAttachment(ITEMATTACHMENT, aname, avalue)
searchItems(query) -> Set of ITEM
getItemModel(ITEM) -> ITEMMODEL
3.3.4
Kategorien und Benutzerlisten
Zur Kategorisierung von Information und zur Gruppierung von Community-Mitgliedern in Untergruppen wurden im vorherigen Kapitel mit Kategorien und SharedUserList zwei eng verwandte Konzepte eingeführt. Im Grund handelt es sich dabei nur um verschiedene Klassen des allgemeinen
Kategorien-Konzeptes.
Die CategoryComponent hat die Aufgabe solche Kategorien und die Beziehungen dazwischen zu verwalten. Neben den Basisfunktionen können hier weiterhin Funktionen zur kollaborativen Erstellung
von Kategorienbäumen und zur Abbildung von Kategorien aufeinander angeboten werden.
So wurde im CommunityItemsTool ein Ansatz getestet, der jedem Community-Mitglied eine eigene Kategorisierung erlaubt. Neben einer Community-Kategorisierung gibt es also noch die einzelnen User-Kategorisierungen (User-Folder). Im Projekt Caiman (Dissertationsprojekt von Martin
Lacher) wird gerade untersucht, wie automatische Unterstützung bei der Abbildung verschiedener
Kategorisierungen (Taxonomien) aufeinander realisiert werden kann. Neben der Anwendung in der
Community-Plattform (zum Abbilden persönlicher Kategorisierungen aufeinander) kann diese Lösung auch in der Import/Export-Komponente zur Abbildung mehrerer Community-Kategorisierungen
aufeinander angewandt werden.
59
CATEGORYComponent
createCategory() -> CATEGORY
deleteCategory(CATEGORY)
updateCategory(CATEGORY, attributes)
searchCategories(query) -> Set of CATEGORY
createSharedBuddyList() -> SHARED-BUDDYLIST
addToSharedBuddyList(SHARED-BUDDYLIST, USER)
removeFromSharedBuddyList(SHARED-BUDDYLIST, USER)
getCategoryModel(CATEGORY) -> CATEGORYMODEL
3.3.5
Kontexte
Bei Kontexten handelt es sich um Referenzen zwischen Datenobjekten, also um Beziehungen von
einem Datenobjekt (User, Item oder Category) zu einem oder mehreren Datenobjekten vom selben
Typ oder von einemunterschiedlichen Typ.
Kontexte können wie alle anderen Datenkonzept mit Attributen näher beschrieben werden und sind
in einer Ontologie mit unterschiedlichen Kontext-Klassen definiert.
Die ContextComponent hat die Aufgabe eine explizite Verwaltung von Kontexten zu erlauben, sowie
den Zugriff auf explizit definierte Kontexte und auf implizit in den anderen Komponenten definierte
Kontexte zu erlauben.
CONTEXTComponent
createContext() -> CONTEXT
deleteContext(CONTEXT)
updateContext(CONTEXT, attributes)
searchContext(query) -> Set of CONTEXT
getContextModel(CONTEXT) -> CONTEXT
3.3.6
Neben der indirekten Kommunikation über Inhalte stellt die direkte Kommunikation zwischen den
Community-Mitgliedern eine wichtige Unterstützungsmöglichkeit dar.
Wie schon in Abschnitt 3.2 diskutiert worden ist, sind hier Freitext-Mitteilungen mit verschiedener Adressatenspezifikation notwendig. Die Adressaten sollen sowohl durch Aufzählung, als auch
durch Spezifikation anhand von Kontextattributen spezifiziert werden können. Zur Ausgestaltung der
Mitteilungsfunktionalität sind vor allem noch die Themen Zustellungskanäle und Kommunikationspräferenzen bzw. Privatheit zu besprechen.
Unter Zustellungskanälen bzw. Kommunikationskanälen versteht man verschiedene Wege, auf denen Mitteilungen die Community-Mitglieder erreichen können. Die Realisierung und die Auswahl
der Kanäle könnte einer externen Messaging-Lösung übertragen werden. Wir haben uns aber dafür entschieden, das Kanalmanagement in der Community-Plattform selbst abzuwickeln, da nur
hier ausreichend Information zu Zweck der Kommunikation und zu den Kommunikationspartnern
(und ihren Beziehungen untereinander) vorhanden ist. Aus diesem Grund ist es in der MessageKomponente möglich, verschiedene Kommunikationskanäle anzusprechen. Momentan werden die
60
folgenden Kanäle unterstützt (eine modulare Erweiterung ist aber einfach möglich):
lokale Mailbox (in Message-Komponente verwaltet)
E-Mail
Instant Messaging / volatile Notifikationen
SMS
Um eine Erweiterung dieser Kanalliste zuzulassen, werden die Kanäle nach groben Kriterien klassifiziert: Pull (Interne Mailbox, E-Mail), Push-wichtig (SMS), Push-wenn-gerade-online (Messaging,
volatile Notifikationen). Mit Hilfe von benutzerspezifischen Regeln kann für Nachrichten basierend
auf den Nachrichtenattributen und den Attributen im Benutzerprofil des Absenders und des Empfängers festgelegt werden, welchen Weg Nachrichten nehmen. Ein Beispiel für eine solche Regeldefinition ist in Abschnitt 4.4.1 für Benutzerprofil-Zugriffsrechte angegeben. Weitere Information zu den
Mitteilungsregeln finden sich in der Entwicklerdokumentation zum Projekt Cosmos (Groh 2002).
Neben Community-Mitgliedern als Nachrichtenversender gibt es noch den Spezialfall, dass die Plattform selbst Nachrichten an Benutzer verschickt. Dies geschieht aufgrund von implizit oder explizit
geäußerten Präferenzen angestoßen durch Ereignisse, die durch Benutzeraktionen auf der Plattform
ausgelöst werden. Nachdem es sich dabei um eine Awareness-Funktionalität handelt, ist die konkrete
Funktionalität in der Awareness-Komponente realisiert.
MESSAGEComponent
sendMessage(USER, MESSAGE)
getMessagesFromLocalMailbox() -> Set of MESSAGE
deleteMessageFromLocalMailbox(MESSAGE)
Die Spezifikation der Empfänger und der Wichtigkeit einer Mitteilung erfolgt als Attribute im MESSAGE-Objekt, das der sendMessage()-Methode mitgegeben wird.
3.3.7
Awareness und Matchmaking
Eine wichtige Rolle von Community-Unterstützung ist die Unterstützung der Community-Mitglieder
beim Finden von anderen Mitgliedern. Dazu können zwei Klassen von Funktionen eingesetzt werden: Durch Awareness-Funktionen wird ein Benutzer informiert, was auf der Community-Plattform
passiert und was andere Mitglieder gerade machen, beim Matchmaking wird versucht aus den Informationen über die Mitglieder auf Anfrage oder proaktiv direkt mögliche Kommunikationspartner
vorzuschlagen.
Awareness
Unter Awareness versteht man das Wissen über Aktivitäten anderer, das für die eigene Tätigkeit relevant sein kann. Awareness ist ein innerer Zustand einer Benutzerin oder eines Benutzers, der in der
Kenntnis von historischen Daten, aktuellen Zustandsbeschreibungen und in Erwartung über das zukünftige Verhalten eines verteilten Kooperationssystems (Computersystem und Kooperationspartner)
61
besteht (Hoffmann 2002). Die klassische Definition dazu aus dem Bereich der Rechnergestützten
Gruppenarbeit geht zurück auf Dourish und Bellotti:
„Awareness is an understanding of the activities of others to provide a context for your
own activities.“ (Dourish und Bellotti 1992)
Das Thema Awareness ist stark mit den Benutzungsschnittstellen verbunden. Es geht vielfach darum, Information, die von den verschiedenen Komponenten geliefert wird (z.B. über den Autor eines Items) prominent anzuzeigen und darüber eine einfache Verbindung zu Community-Mitgliedern
oder Informationen herzustellen. Awareness-Funktionen werden deshalb vielfach in der Benutzungsschnittstellen-Komponente unter Abstützung auf die einzelnen „Fachkomponenten“ realisiert.
Zusätzlich zu den (Fach-)Komponenten-spezifischen Awareness-Funktionen gibt es aber doch einige
Grundfunktionalitäten, die in einer spezifischen Awareness-Komponente realisiert werden können:
Filterung von Informationen und proaktive Bereitstellung von Information.
Filterung von Informationen bedeutet dabei eine Awareness-spezifische Personalisierung, d.h. die
Auswahl von Informationen, die abhängig vom aktuellen (Nutzungs-)Kontext angezeigt werden sollen. Diese kontextabhängige Anzeige kann proaktiv erfolgen (Push) oder auf Anfrage des Benutzers
(Pull). Die Filterung von Awareness-Information kann durch Erweiterung der Funktionen der Personalisierungskomponente realisiert werden. Neben der Auswahl aus den aktuellen und vergangenen
Ereignissen können hier auch zukünftige Ereignisse vorhergesagt werden, d.h. Informationen bzw.
Vorhersagen bereitgestellt werden, die Benutzern beim Aufbau von Erwartungen zu zukünftigen Ereignissen und Entwicklungen unterstützen (Hoffmann 2002).
Der Begriff proaktive Information ist schon mehrfach angesprochen worden. Darunter versteht man
die Erzeugung von Hinweisen auf Aktivitäten und Informationen in der Plattform für einen speziellen Benutzer und die automatische (ungefragte) Anzeige bzw. Zustellung dieser Information (Push).
Diese Informationen werden basierend auf impliziten und expliziten Abonnements im Benutzerprofil
erzeugt und per Messaging an den Benutzer weitergeleitet.
In den Bereich Abonnements fallen beispielsweise auch die sogenannten „Subscriptions“, die es auf
vielen Plattformen gibt. Hier werden explizit Kategorien als Interessenskategorien markiert oder
allgemeine Abfragen mit dem Wunsch registriert, Items, die zu diesen Abfragen publiziert werden,
direkt an den Benutzer weiterzuleiten. Neben dieser expliziten Form des Abonnements sind aber
auch verschiedene Arten der Auswertung von Kontext- und Benutzerprofilattributen denkbar um neue
Ereignisse oder schon länger vorhandene Information zuzustellen. Diese Funktionalitäten sind in der
Awareness-Komponente gesammelt.
Matchmaking
Beim Matchmaking wird Profilinformation verschiedener Community-Mitglieder mittels geeigneter
Algorithmen miteinander verglichen um automatisch Vorschläge für potentielle Kommunikationspartner zu generieren, die dann an der Benutzungsschnittstelle angezeigt werden können oder zu
proaktiven Mitteilungen führen können.
Eine wichtige Teilfunktionalität ist dabei die Berechnung von Benutzerkorrelationen. Hierzu werden
Bewertungen, die Benutzer zu Objekten (z.B. Informationen auf der Plattform oder externe Objekte
wie Kinofilme) abgegeben haben, zusammengefasst und mit statistischen (Korrelations-)Methoden
daraus eine Ähnlichkeit zwischen den Benutzern (hinsichtlich ihrer Interessen) berechnet. Die Ähnlichkeit wird dabei meist in Form eines Korellationskoeffizienten im Wertebereich von -1 (absolut
62
gegensätzlich) bis +1 (absolut gleichartig) angegeben. Diese Information kann entweder für kollaborative Filterverfahren oder für die direkte Ermittlung von potentiellen Kommunikationspartnern
genutzt werden.
Matchmaking und Awareness werden momentan zusammen in einer Komponente realisiert. Die
Awareness/Matchmaking-Komponente stellt allgemeine Funktionen zur Generierung von Vorschlägen zur Verfügung. Dabei arbeitet sie mit der Personalisierungskomponente zusammen.
AWARENESSMATCHMAKINGComponent
setAwarenessFilter(USER, query)
generateUserMatches(USER, query) -> Set of USER
Die Methode generateUserMatches() liefert Empfehlungen für Benutzer, die unter den Rahmenbedingungen der angegebenen Anfrage mit dem anfragenden Benutzer übereinstimmen.
Zusätzlich zu diesen Methoden gibt es noch Verbindungen zu allen Komponenten, die Awarenessrelevante Ereignisse erzeugen, und zur Messaging-Komponente und den Benutzungsschnittstellen
zur Mitteilung von Awareness-Information.
3.3.8
Personalisierung
Die Ausrichtung verschiedener Funktionalitäten oder Elemente der Benutzungsschnittstelle auf die
persönlichen Interessen des Benutzers wurde bereits an verschiedenen Stellen angesprochen. Die
Personalisierungskomponente stellt allgemeine Funktionen zur Ermöglichung von Personalisierung
zur Verfügung. Durch Erweiterung der Komponente in konkreten Plattformen oder durch Realisierung neuer Komponenten basierend auf diesen Funktionalitäten können einfach domänenspezifische
Personalisierungfunktionen erreicht werden.
Die Funktionalität, die zu den Basiskomponenten gerechnet wird, ist
Berechnung von Benutzerkorrellationen basierend auf Bewertungen (siehe Matchmaking-Komponente)
Generierung von Vorschlägen nach verschiedenen Filterverfahren - hierzu gehören sowohl regelbasierte als auch kollaborative Verfahren
Um eine möglichst generische Kombination von Filterverfahren zu erlauben unterstützt die Komponente die Definition von allgemeinen Workflows für die Generierung von Empfehlungen.
PERSONALIZATIONComponent
generateRecommendation(USER, query) -> Set of ITEM
Personalisierung und Personalisierungsmethoden werden ausführlich in folgenden Veröffentlichungen besprochen: (Koch u. a. 2002b), (Koch und Schubert 2002), (Schubert und Koch 2002) und (Koch
2001b). Ein Einsatz ist bisher vor allem in der Cosmos-Plattform und der SFB582-Plattform erfolgt
(siehe Abschnitte 5.5 und 5.6).
63
3.4
Konfigurierung
Damit aus den generischen Komponenten verschiedene Plattformen realisiert werden können, muss
eine einfache Konfigurierung möglich sein. Allgemein verstehen wir hierunter
eine Festlegung der benutzten Komponenten,
eine Definition der Beziehungen zwischen den Komponenten und
eine Parametrisierung der Komponenten
um die resultierende Plattform auf die konkreten Bedürfnisse der unterstützten Community einzustellen.
Parametrisierung bedeutet dabei, dass während der Implementierung einer Komponente einige Einstellungen offen gelassen worden sind und zur Laufzeit belegt werden können. Ein Beispiel dafür ist
das Setzen von konkreten Ontologien für die Datentypen.
In den folgenden Unterabschnitten bespreche ich die Konfiguration und Parametrisierung verschiedener Teile der Community-Plattform:
Benutzungsschnittstelle
Datenkonzepte (Ontologien)
Abfragesprache
Komponentenfunktionalität
Konfiguration der Benutzungsschnittstelle
An der Benutzungsschnittstelle treffen Layout, Inhalt und Ablauflogik zusammen. Schon in Smalltalk80 wurde hier das sogenannte Model/View/Controller (MVC) Pattern propagiert um die drei Aspekte
in der Implementierung voneinander zu trennen (Krasner und Pope 1988). Das Pattern findet sich
in der einen oder anderen Form in allen Frameworks zur Programmierung von (graphischen) Benutzungsschnittstellen wieder.
Die Grundidee verschiedener Aktivitäten in den letzten Jahren war die Bereitstellung von Konzepten,
die eine Aufteilung der verschiedenen Aspekte auf verschiedene Personen erlauben:
Designer legt Layout fest
Domänenexperte legt Inhaltsstruktur fest
Programmierer realisiert Logik
Zur Trennung von Layout und Inhalt gibt es inzwischen verschiedene Stylesheet-Konzepte. D.h. der
Inhalt wird in einer Auszeichnungssprache (z.B. eine XML-Darstellung von Datenstrukturen) logisch
ausgezeichnet und über Stylesheet-Regeln (z.B. XSLT) werden die Datenelemente umsortiert und mit
Layoutattributen angereichert. So kann aus XML-Datenstrukturen einfach eine HTML-Darstellung
der Daten generiert werden.
Auch zur Trennung von Layout, Inhalt und Logik gibt es bereits einige Ansätze:
64
3.4 Konfigurierung
Java Server Pages (JSP): Model = Java Beans = Content, View = Java Server Pages = Layout,
Controller = Java Servlet = Logik
Cocoon (XML, XSLT, Servlets)
Template Engines (z.B.. Velocity, WebMacro, HTML++)
Grundidee bei allen aufgelisteten Technologien ist es, die Funktionalität (Logik) in Komponenten zu
realisieren, welche über Prozeduraufrufe angesprochen werden. In Inhalts-Templates werden dann
die Prozeduraufrufe eingebettet. Beim Layout der Seiten werden die Ergebnisse (welche z.B. in einer
XML-Darstellung geliefert werden können) über Stylesheets in die Darstellung eingebaut.
Für die Community-Unterstützungs-Plattformen haben wir eine generische Web-Benutzungsschnittstelle geschaffen, welche die Trennung von Logik-Komponenten und Darstellungs-Templates realisiert.
Die Konfiguration der generischen Web-Benutzungsschnittstelle über Templates sieht folgendermaßen aus. Die Web-UI bietet nur die Funktionalität zum Parsen von Web-Templates. Solche Templates
werden wie normale Web-Seiten im Webspace der Web-UI abgelegt (und so einer URI zugeordnet).
Der Webspace kann dabei im Dateisystem oder in einem Datenbanksystem realisiert sein. Die Templates beinhalten erstens HTML- oder WML-Code und zweitens Aufrufe von öffentlichen Methoden
beliebiger Komponenten in der Plattform. Die aufgerufenen Methoden liefern ihre Ergebnisse als
XML-Dokumente oder die Web-UI sorgt dafür, dass eine Umwandlung in XML-Dokumente erfolgt.
Zum Funktionsaufruf wird im Template dann noch ein XSLT-Stylesheet angegeben, das die Umwandlung der XML-Ergebnisse in HTML, WML etc. steuert.
Mit dieser generischen Web-Benutzungsschnittstelle können ohne Programmierung beliebige Seiten
erstellt werden, die beliebige Komponenten aufrufen und deren Ergebnisse beliebig darstellen.
Die Behandlung von Benutzereingaben wird ähnlich gehandhabt. Hier wird in den Formularen auf
den HTML-Seiten eine generische URL aufgerufen, welche von der Web-UI behandelt wird. Beim
Aufruf wird angegeben, welche Funktion aufzurufen ist und wie die Anfrageparameter auf Funktionsparameter abgebildet werden.
Für einige Fälle sind in der Web-UI spezielle Funktionen implementiert, die die Funktionalität mehrere Komponenten zusammenfassen. Grundsätzlich ist es aber auch möglich ohne neue Funktionen
in der UI-Komponente auszukommen.
Auch eine Berücksichtigung der Domäneninformation an der Benutzungsschnittstelle ist möglich.
Hierzu kann die Auswahl der formatierenden Stylesheets von Rückgabewerten der aufgerufenen
Funktion abhängig gemacht werden. Wird als ein Rückgabewert (spezielles Element im XMLRückgabedokument) der Datentyp eines Items oder eine Kategorie angegeben, dann kann die Ausgabe davon abhängig gemacht werden.
Konfiguration der Datenkonzepte
Wichtiger noch als die Benutzungsschnittstelle ist die Konfiguration der Gesamtfunktionalität. Hierzu
ist durch die starke Generalisierung der Datenkonzepte in Abschnitt 3.2 der Hauptgrundstein gelegt
worden. So ist es einfach möglich, die Grundkonzepte Item, User, Category, Context und Message
entsprechend der Anforderungen der unterstützten Community auszufüllen.
65
Die Datenkonzepte werden durch Parametrisierung der Komponenten gesetzt. Dazu müssen die Konzepte aber in Dateien kodiert werden. Zur Kodierung solcher Information gibt es bereits einige Darstellungsstandards.
Zuerst sind hier XML-Document-Type-Definitionen (DTDs) und XML-Schema zu nennen um eine
Grammatik für allgemeine Datenstrukturen zu definieren. Gegenüber DTDs hat XML-Schema hat
den Vorteil, dass das Schema selbst in XML definiert ist. Zur Trennung von Daten und Beziehungen
zwischen Daten wurde RDF (Ressource Description Framework) definiert. Als Standards zur Darstellung von allgemeinen Ontologien sind schließlich noch XOL (Karp u. a. 1999) und DAML+OIL
(siehe www.daml.org) zu erwähnen.
Für die Prototypplattformen wurde vorerst eine einfache Lösung zur Kodierung der Datenstrukturen in einer XML-basierten Ontologiebeschreibung gewählt. An einer Erweiterung für allgemeine
Ontologien (mit RDF und DAML+OIL) wird gerade gearbeitet.
Abfragesprache
Neben der Kodierung der Datenstrukturen und der Regeln dazu ist es auch notwendig, eine allgemeine Abfragesprache (engl. query language) zur Formulierung von domänenspezifischen Abfragen
bereitzustellen (für den Programmierer oder Konfigurator von speziellen Komponenten und für den
Endbenutzer).
Allgemein handelt es bei Abfragesprachen um formale Sprachen zum Abrufen von Daten aus einer Datenbank. Standardisierte Abfragesprachen gibt es für den Abruf von Daten aus relationalen
Datenbanken (SQL - Structured Query Language) oder objektrelationalen bzw. objektbasierten Datenbanken (SQL3 und OQL - Object Query Language).
Neben den Lösungen für strukturierte Daten gibt es auch erste Standards für die Formulierung von
Abfragen auf semi-strukturierten Datenbeständen. Dabei werden die Daten meist als XML-Dokumente modelliert. Beispiele für Abfragesprachen zu XML-Dokument-Datenbanken sind:
XQL und XPath: XPath-Ausdrücke wählen Teile von XML-Dokumenten aus - XQL ist eine
Variante von XPath, speziell zur Abfrage von XML-Dokumenten.
XML-QL: XML-QL lehnt sich an Abfragesprachen aus der Datenbank-Community an und ist
ähnlich wie SQL aufgebaut; so ist das Basiskonstrukt von XML-QL „WHERE pattern IN uri
CONSTRUCT pattern“.
Neben diesen Abfragesprachen für strukturierte und semi-strukturierte Datenbestände gibt es noch
die Möglichkeit, die Daten als Logik-Programme zu interpretieren und Abfragen mittels Deduktionsregeln zu formulieren. Ein Beispiel hierzu sind Frame-Logik-Ausdrücke. Frame-Logik ist eine
mächtige Sprache, die deduktive und objektorientierte Konzepte miteinander verbindet. Durch den
deduktiven Anteil wird eine Definition von Daten durch Regeln erlaubt und damit rekursive Anfragen ermöglicht, durch den objektorientierten Anteil ist es möglich Anfragen auf komplex strukturierte
Objekte mit Objektidentität, die hierarchisch angeordneten Klassen zugeordnet sind, durchzuführen.
Schließlich gibt es auch noch Konzepte, die Metadatenkonzepte bei semi-strukturierten Daten (XML)
und Logik-Abfragesprachen kombinieren. Ein Beispiel dafür ist Metalog (Marchiori und Saarela
1998).
66
3.4 Konfigurierung
Für die bisherigen Prototypplattformen wurde folgende Lösung gewählt: Die Daten, auf die eine
Anfrage auszuführen sind, werden anhand des Datenmodells auf virtuelle XML-Dokument abgebildet. Dabei werden Referenzen aufgelöst und die Zieldaten als XML-Unterdokumente aufgenommen.
Eine Anfrage wird dann einfach als reduzierter XPath-Ausdruck auf der Menge aller virtuellen Dokumente dargestellt.
Nachfolgend ein Beispiel für ein solches virtuelles XML-Dokument:
item
typeshort msg /typeshort
title Ein Test für eine Nachricht /title
url http://www11.in.tum.de/index.html /url
author
/author
content
/content
location
/location
origin
/origin
publisheddate ... /publisheddate
startdate ... /startdate
expirationdate ... /expirationdate
publisher
person
login test@localhost /login
vorname
/vorname
nachname
/nachname
lastlogin ... /lastlogin
/person
/publisher
annotations
annotation
id
/id
title
/title
content
/content
language
/language
rating
/rating
publisheddate ... /publisheddate
publisher
person
/person
/publisher
/annotation
/annotations
categories
category 1 /category
/categories
/item
Anfragen können dann als XPath-Ausdrücke angegeben werden. Für obiges Dokument wären also
beispielsweise folgende Anfragen denkbar:
67
/item/annotations/annotation/publisher/login=’test@localhost’
/item[typeshort=’msg’ and publisheddate<TODAY-10]
/item[typeshort=’msg’] and /item/categories[category in 12,13]
Konfiguration der Komponenten
Neben den Freiheiten der Datenstrukturen bieten die Komponenten noch die Möglichkeit, sie weiterzuentwickeln, basierend auf ihren Diensten neue Komponenten zu entwickeln und in die Plattform
einzubinden, und sie selbst zu parametrisieren.
Schon die Grundidee der Komponentenorientiertheit beinhaltet, dass konkrete Anwendungssysteme
mit minimalem Entwicklungsaufwand durch das mit wenig Rahmen-Code unterstützte Zusammenfügen von Komponenten und Parametrisierung erstellt werden können.
Im Bereich der Groupware gab es einige Arbeiten, die sich mit Anpassbarkeit und Konfigurierbarkeit durch Komponentenkonzepte beschäftigt haben. Zu nennen sind hier insbesondere (ter Hofte
1998), (Teege 1998) und (Stiemerling 2000). Während ter Hofte und Stiemerling den streng komponentenorientierten Ansatz mit Parametrisierung verfolgen, findet sich bei Teege ein aspektorientierter
Ansatz, die „Featurekombination“.
In unseren Prototypplattformen werden die ausgewählten Komponenten(-implementierungen) in einem allgemeinen Komponentenframework instantiiert und verfügbar gehalten. Das Komponentenframework erhält dazu als Parametrisierung eine Liste der zu instantiierenden Komponenten und die
Namen der Klassen, aus denen sie instantiiert werden sollen.
Komponenten erhalten bei der Instantiierung sowohl die Attribute, mit denen das Framework parametrisiert worden ist, als auch eine zusätzliche Menge von Attributen zur Parametrisierung der
konkreten Komponente. Diese Attribute können in Konfigurationsdateien bereitgestellt werden und
können zu Anpassungen wie dem Setzen von Datenbank-Zugangsparametern oder Quelldateien für
die Datentypdefinition genutzt werden.
68
Kapitel 4
Benutzerprofile und
Benutzerprofilspeicherung
„Press Ctrl + Alt + Delete to log on.“,
Microsoft Windows NT opening screen
Eine wichtige Funktionalität bei Community-Unterstützungssystemen ist die Speicherung und
Nutzung von Benutzerprofilen. Aus diesem Grund nimmt diese Funktionalität bei der Konzeption einer generischen Community-Unterstützungsplattform eine zentrale Rolle ein. In diesem
Kapitel führe ich in das Thema Benutzerprofile näher ein und leite ab, wie die Handhabung von
Benutzerprofilen für zukünftige Community-Unterstützungssysteme aussehen sollte. Weiterhin
wird die im Cobricks-Projekt entwickelte und umgesetzte Lösung vorgestellt.
Kapitelinhalt
4.1
Struktur und Nutzung von Benutzerprofilen . . . . . . . . . . . . . . . . . . . 70
4.2
Benutzerprofilspeicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.3
Modellierung von Benutzerprofilen . . . . . . . . . . . . . . . . . . . . . . . . 77
4.4
Privatheit und Zugriffskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Das Thema Benutzerprofilverwaltung beinhaltet neben technischen Aspekten immer mehr auch die
Betrachtung von Vertrauen – sowohl Vertrauen in technische Lösungen als auch in die Betreiber von
Diensten, die Profilinformationen speichern und nutzen. Wie später noch ausführlicher motiviert
wird, verfolgen wir zur Erlangung des Vertrauens der Profileigentümer einen benutzerzentrierten Ansatz bei der Profilverwaltung. Aus diesem Grund sprechen wir häufig auch von Identitätsmanagement
anstelle von Benutzerprofilverwaltung.
Um ein benutzerzentriertes Identitätsmanagement-System zu entwerfen, müssen die folgenden Aspekte behandelt werden
Architektur des Systems
Standard für die Kodierung von Benutzerprofilinformation
Privatheits-Aspekte (Spezifikation und Aushandlung von Zugriffsrechten)
Kryptographische Verfahren zur Authentifizierung von Identitäten und Pseudonymen
69
Nach einer Einführung zur Struktur und Nutzung von Benutzerprofilen behandle ich in Abschnitt 4.2
die Architektur des Systems. Der folgende Abschnitt 4.3 geht auf die Modellierung von Benutzerprofilinformation ein und der darauf folgende Abschnitt 4.4 auf Zugriffskontrolle und PrivatheitsAspekte. Auf kryptographische Verfahren zur Authentifizierung wird in dieser Arbeit nicht weiter
eingegangen.
Allgemeine Information zu Struktur und Nutzung von Benutzerprofilen ist in (Schubert und Koch
2002) zu finden. Eine Beschreibung der konkreten Lösung im Rahmen des Cobricks-Projektes ist
vor allem in (Koch und Wörndl 2001), (Koch 2002e) und (Koch und Möslein 2003) dokumentiert.
Dieses Kapitel fasst die in diesen Veröffentlichungen erarbeiteten Ergebnisse konsistent zusammen
und führt sie weiter. Insbesondere wird ein konkretes Metamodell und Modell für Benutzerprofile
vorgestellt und die Realisierung der Benutzerprofil-Komponente und des IDRepositories in Cobricks
beschrieben.
4.1
Struktur und Nutzung von Benutzerprofilen
Unter Benutzerprofilen versteht man eine Sammlung von Information, die einen bestimmten Benutzer näher beschreibt oder charakterisiert. Solche Information wird in Community-Plattformen für
folgende Zwecke benötigt:
Personalisierung
Präsentation des Benutzers gegenüber anderen Benutzern; Daten für die Nutzung durch andere
Benutzer; z.B. Geschenkliste, Buch-/DVD-Listen, (öffentlicher) Kalender
Speicherung von Daten für die spätere Nutzung durch den Benutzer selbst; z.B. Kalender,
Kontaktliste
Im Gegensatz zu anderen Systemen, die auf Benutzerprofile hauptsächlich zur Ergänzung der Grundfunktionalität durch Personalisierung zurückgreifen, stellt die Nutzung und Bereitstellung von Information über die Benutzer bei Community-Unterstützungssystemen eine zentrale Funktionalität dar.
Alle Funktionsbereiche, die in Kapitel 2 vorgestellt worden sind, beruhen mehr oder weniger auf der
Nutzung oder Bereitstellung von Profilinformation.
Bevor ich auf die Spezifika der Profilnutzung in Community-Unterstützungssystemen zurückkomme,
gehe ich im Folgenden zuerst kurz auf mögliche Datenquellen ein (Erhebung der Daten) und behandle
dann kurz die mögliche Nutzung von Benutzerprofildaten. Siehe hierzu auch (Koch 2002c), (Koch
u. a. 2002b), (Koch und Schubert 2002), (Schubert und Koch 2002), (Koch 2001b) und (Leckner u. a.
2003).
4.1.1
Erhebung der Daten
Angaben durch den Benutzer
Ein Ansatz zur Erhebung von Benutzerdaten beruht darauf, den Benutzer direkt (z.B. mit Fragebogenformularen) zu befragen und mit den erhaltenen Informationen das Benutzerprofil zu füllen.
Diese Art und Weise der Datenerhebung bietet sich insbesondere bei demographischen Informationen
an, die kaum aus den Aktivitäten des Benutzers abgeleitet werden können. Auch angewendet wird
70
4.1 Struktur und Nutzung von Benutzerprofilen
das Verfahren bei der Erhebung von Information zu den Interessen eines Benutzers. Dazu wählen
Benutzer aus einer vorgegebenen Liste von Themen oder Kategorien eine Untermenge aus.
Neben der einfachen Implementierbarkeit wird häufig eine hohe Datenqualität als Vorteil des Verfahrens genannt. Dem steht allerdings gegenüber, dass Benutzer wegen Zweifel an der Datenschutzerklärung (privacy policy) des Datensammlers und an dem Nutzen, den eine Preisgabe der Daten für sie
selbst hat, häufig keine oder bewusst falsche Daten angeben. Neben den Problemen mit der Motivation des Benutzers bezüglich Aufwand und Privatsphäre finden sich gerade bei Freitextangaben oder
bei einer Auswahl aus einer großen Menge von Alternativen unterschiedliche Interpretationen der
Benutzer, die eine Vergleichbarkeit und Verwertbarkeit der gesammelten Daten schwierig machen.
Bei GroupLens (Resnick u. a. 1994; Sarwar u. a. 1998), einem Filtersystem für Usenet News, muss der
Benutzer z.B. jeden gelesenen Artikel bewerten. Die Bewertungen gehen ins Profil des Benutzers und
werden mit Information-Retrieval-Methoden (u.a. kollaboratives Filtern) analysiert um diesem und
allen anderen Benutzern Vorschläge zu machen. Um den Benutzer von dem zusätzlichen Aufwand,
jeden Artikel zu bewerten, zu befreien, wurde versucht aus der Zeitdauer, die ein Benutzer einen
Newsartikel angezeigt hat, das Interesse an diesem Dokument abzuleiten.
Eine andere Informationsquelle wird bei Siteseer (Rucker und Polanco 1997), einem Empfehlungssystem für Web-Seiten, ausgenutzt. Siteseer geht davon aus, dass Benutzer die Web-Seiten, die sie
besonders interessieren, in ihre Bookmark-Liste aufnehmen, und verwendet die Aufnahme in die
Bookmark-Liste als implizite Interessensbekundung. Eine solche Wiederverwendung von Information, die der Benutzer sowieso verwaltet, findet sich teilweise auch bei elektronischen Terminkalendern
und elektronischen Adresslisten.
Beobachtung des Benutzers
Ohne Aufwand (und teilweise auch ohne Wissen) des Benutzers kann das Benutzerprofil durch Beobachtung der Aktivitäten des Benutzers auf einem Portal oder sonstigem Web-Angebot erstellt werden.
Die beiden wichtigsten Informationsquellen in der Praxis sind der sogenannte „Clickstream“, also
Information zu den Web-Seiten, die ein Benutzer besucht hat, und die „Transaktionshistorie“, d.h.
die Aktivitäten und bei Online-Shops vor allem Bestellungen, die ein Benutzer auf einer Website
ausgeführt hat.
Beim der Auswertung von Clickstream-Daten besteht das Hauptproblem darin, dass eine klare Zuordnung zwischen Web-Seiten und Interessen oder Attributen des Benutzerprofils definiert werden muss.
Auch ist hier schwierig zu klären, ob eine Seite nur versehentlich oder aus Absicht besucht worden
ist, und ob die besuchte Seite dem Interessensprofil des Benutzers entspricht. Auch die Messung der
Zeit zwischen dem Betreten und dem Verlassen einer Web-Seite (soweit überhaupt möglich) liefert
nur einen Ansatzpunkt für das Interesse des Benutzers an der Seite. Eine ausführliche Betrachtung
dieses Themas liefert (Koch 2002a).
Das Problem bei Nutzung von Daten aus der Transaktionshistorie ist hauptsächlich, dass ein Benutzer
auch im Auftrag anderer Personen handeln kann, und dies häufig unter derselben Identität ausführt
unter der er auch für sich agiert.
Ein weiteres Problem bei der Beobachtung des Benutzers ergibt sich durch die rechtliche Situation.
Das Teledienstdatenschutzgesetz (TDDSG) fordert erstens die Beschränkung auf ein Minimum an zu
speichernden Daten und erlaubt nur die zweckgebundene Speicherung und Verwendung. Weiterhin
schreibt das Gesetz für viele Fälle eine explizite Einwilligung des Benutzers vor und fordert die
Bereitstellung einer umfassenden Auskunftsmöglichkeit für den Benutzer (Gentsch 2002).
71
4.1.2
Nutzung von Profilen - Personalisierung
Eine Anwendung von Benutzerprofilen ist die Personalisierung von Diensten. Unter Personalisierung
versteht man dabei die (automatische) Auswahl aus einer Reihe von Alternativen mit dem Ziel, die
Alternativen zu wählen, die dem Benutzer den größten Nutzen bringt.
Hierbei ist zu unterscheiden zwischen der Auswahl aus verschiedenen Varianten und der Generierung
einer komplett neuen Variante. Ziel der Auswahl kann dabei Information, Diensteigenschaften oder
Vorbelegungen bei Diensten sein.
Bei den Auswahlverfahren ist zu unterscheiden zwischen inhaltsbasierter Filterung und kollaborativer
Filterung.
Inhaltsbasierte Filter
Bei der inhaltsbasierten Filterung werden konkrete Attribute der auszuwählenden Alternativen (z.B.
Items) mit konkreten Attributen des Benutzerprofils des anfragenden Benutzers verglichen. So können Web-Seiten nach Kategorien klassifiziert sein. Diese Metainformation kann dann mit den explizit
als Interessen ausgewählten Kategorien im Benutzerprofil verglichen werden.
Der Vergleich von Inhalt und Benutzerprofil kann regelbasiert erfolgen, binär (wenn die Daten strukturiert vorliegen und aus denselben Domänen stammen), oder über Ähnlichkeitsmaße zwischen einzelnen Attributen oder ganzen Teilen des Profils (z.B. über Vektorraummodelle) wenn die Daten nicht
strukturiert vorliegen.
Die Nachteile des inhaltsbasierten Filterns liegen darin, dass die Alternativen explizit klassifiziert
werden müssen (von der Möglichkeit der automatischen Extraktion solcher Klassifikationsinformation abgesehen). Weiterhin muss diese Klassifizierung allgemein und objektiv sein. So haben die
Verfahren grundsätzliche Probleme bei der Auswahl nach subjektiven Kriterien (z.B.: „Suche einen
Film, der mir gefallen könnte“).
Kollaborative Filter
Beim kollaborativen Filtern versucht man die Nachteile des inhaltsbasierten Filterns zu umgehen, indem die Erfahrungen anderer Benutzer mit berücksichtigt werden. Grundidee dabei ist es Mundpropaganda (word of mouth) in elektronischen Information- und Kommunikationssystemen nachzubilden. Bei der Suche nach Information wird also direkt oder indirekt auf die Erfahrung zurückgegriffen,
die andere Benutzer gemacht haben.
Entsprechend dem Unterschied zwischen direktem und indirektem Zugriff auf andere Benutzer zur
Erzeugung oder Abfrage von Empfehlungen ist zwischen interaktiven Verfahren und automatischen
Verfahren zu unterscheiden. Beim interaktiven kollaborativen Filtern interagieren die Benutzer bei
der Suche nach Information explizit miteinander. Sie tauschen also direkt untereinander Empfehlungen aus (Twidale u. a. 1997; Twidale und Nichols 1996; Nichols 1997).
Die Methode des automatischen kollaborativen Filterns stützt sich auf die Annahme, dass Personen,
die in der Vergangenheit gleicher Meinung waren, voraussichtlich auch zukünftig gleicher Meinung
sein werden. Dabei wird mit Ähnlichkeitsmaßen zwischen Profilen gearbeitet. Es werden Bewertungen von Benutzern erfasst, daraus mit statischen Korrelationsverfahren Benutzer mit ähnlichen
72
4.2 Benutzerprofilspeicherung
Interessen automatisch identifiziert und schließlich die Empfehlungen von ähnlichen Benutzern untereinander ausgetauscht. Die Erfassung der Bewertungen kann explizit durch Abfrage beim Benutzer
oder implizit durch Beobachtung des Benutzers erfolgen.
Weiterführende Information zu kollaborativem Filtern findet sich beispielweise in (Koch 2001b) oder
(Grasso u. a. 1999).
4.1.3
Präsentation
Neben der Personalisierung von Diensten dienen Benutzerprofile noch zur Präsentation der Identität
eines Benutzers gegenüber anderen Benutzern. Ein Sonderfall dabei ist die Präsentation gegenüber
einem Dienst mit anderen Zielen als der Personalisierung, z.B. die Weitergabe von Zahlungsinformation oder Lieferadresse an einen Online-Shop.
Im Gegensatz zur Personalisierung ist bei der Präsentation wichtig, welche Daten wem angezeigt werden. Dies sollte durch den Eigentümer des Benutzerprofils, also den Benutzer selbst, konfigurierbar
sein. Zur Unterstützung der Entscheidung stellen Dienste teilweise Datenschutzerklärungen (privacy
policy) bereit, in denen definiert ist, wie sie mit den bereitgestellten Daten umgehen. Benutzer können
abhängig von Datenschutzerklärungen oder abhängig vom den Diensten selbst Einstellungen treffen,
ob ein Datum keinem, einem eingeschränkten (z.B. über eine Buddyliste definierten Benutzerkreis)
oder allen Benutzern angezeigt werden darf.
4.2
4.2.1
Benutzerprofilspeicherung
Anwendungsunabhängige Profilspeicherung
Benutzerprofile werden heute üblicherweise verteilt bei den verschiedenen Diensten gespeichert, die
sie nutzen. So speichern amazon.com oder bn.com beispielsweise die Interessen und Kaufhistorien
ihrer Kunden um Empfehlungen generieren zu können.
Diese Verschmelzung von Profilspeicherung und Profilnutzung weist verschiedene Probleme auf:
Ein Benutzer muss für verschiedene Dienste dieselben Informationen wieder und wieder bereitstellen.
Dienste können nicht sofort beim ersten Kontakt Empfehlungen geben oder Personalisierung
anbieten, da sie erst (implizit oder explizit) Daten sammeln müssen - „Kaltstartproblem“. Gerade kleine Dienste haben keine Möglichkeit, den Benutzer lange genug zu binden, um ausreichend Informationen für eine Personalisierung zu gewinnen.
Benutzer haben wenig Kontrolle darüber, welche persönlichen Daten gesammelt werden und
welche Daten wo gespeichert sind. Dadurch entwickelt sich kein Vertrauen in die Dienste und
Benutzer geben häufig falsche Information an.
Ein Ansatz zur Lösung der angesprochenen Probleme ist es, die Kontrolle über Benutzerprofile den
Benutzern selbst zurückzugeben (um das Vertrauensproblem zu lösen) und eine Nutzung derselben
Profile durch verschiedene Anwendungen zu erlauben (um das Kaltstartproblem zu lösen).
Zur Umsetzung dieser Ideen muss die Nutzung von Benutzerprofilen (in den Community-Plattformen
oder allgemein in Personalisierungsdiensten) von der Speicherung getrennt werden. Dies eröffnet die
73
Möglichkeit der Mehrfachnutzung von Profilen und stellt eine einzige Stelle zur Verfügung, an der
Zugriffskontrolle und Benutzer-Awareness (darüber, wer welche Information nutzt) in einer Weise
implementiert werden kann, so dass die Besitzer der Daten dem Speicherungsdienst vertrauen und
gesetzliche Rahmenbedingungen erfüllt werden (Koch 2002c; Koch und Wörndl 2001).
Identitäten, Identitätsmanagement
Wenn man diese benutzerzentrierte Sichtweise einnimmt, spricht man üblicherweise nicht mehr von
Benutzerprofilen und Benutzerprofilverwaltung, sondern von Identitäten und Identitätsmanagement.
Der Begriff Identität wurde schon bei der Diskussion der Schlüsselfaktoren sozialer Gemeinschaften
in Kapitel 2 eingeführt (siehe S.16). Aus soziologischer Sicht versteht man darunter “dauernde innere
Sich-Selbst-Gleichsein, die Kontinuität des Selbsterlebens eines Individuums“ (Köhntopp 2000). Im
technischen Sinne entspricht eine Identität einem Benutzerprofil. Sie kann als Menge von Attributen,
die eine Person näher beschreiben, dargestellt werden.
Unter Identitätsmanagement versteht man dann allgemein das Verfügbarmachen der Information und
die Kontrolle, welche Information welchen Anwendungen zur Verfügung steht. Identitätsmanagement ist etwas, das offline tagtäglich passiert wenn wir entscheiden, was wir Gesprächspartnern über
uns mitteilen. Dabei wird normalerweise der situative Kontext, die Rolle in der man agiert und die Beziehungen zu den Interaktionspartnern berücksichtigt. Als Resultat werden unterschiedlichen Interaktionspartnern unterschiedliche Teilmengen der Identitäts-Attribute verfügbar gemacht. In manchen
Fällen ist eine Person in verschiedenen Kontexten sogar unter unterschiedlichen Namen bekannt, z.B.
durch die Nutzung spezieller Namen, Spitznamen oder Pseudonyme (Köhntopp und Berthold 2000).
Ähnliche Funktionalitäten sind auch in der digitalen Welt gefragt. Ein Identitätsmanagement-System
sollte Personen erlauben, verschiedene Identitäten und Rollen zu definieren und persönliche Daten
dazu zu speichern. Dazu sollte definierbar sein, wem diese Information zur Verfügung gestellt werden
sollen. Herausforderungen, die sich dabei unter anderem ergeben sind die Wahrung der Aktualität
der Information in verschiedenen (digitalen) Identitäten eines Benutzers und die Übersicht darüber,
welche Information welchem Dienst zur Verfügung gestellt worden ist (Awareness).
Erste Ansätze zur Unterstützung von Identitätsmanagement können sowohl in der Industrie als auch
in der Forschung gefunden werden. In den folgenden Abschnitten werde ich diese Lösungen kurz
vorstellen und dann ein Resumee für unsere eigene Lösung ziehen.
4.2.2
Infomediaries
Sogenannte „Infomediaries“ implementieren die Client-seitige Benutzerprofilspeicherung. Infomediaries sind (kleine) Anwendungen auf dem Client-Computer, die Benutzerprofile verwalten und
Dienste wie das automatische Ausfüllen von Web-Formularen bieten oder über Standardprotokolle
wie P3P Server-Anwendungen Information zur Verfügung stellen können (Cranor 1999). Beispiele
für Infomediaries sind Jotter (www.jotter.com) oder Persona (www.persona.com).
Ziel bei der Entwicklung von Infomediaries war es, ein höheres Vertrauen des Benutzers zu gewinnen, da die Information nahe beim Benutzer gespeichert ist und Zugriffe darauf kontrolliert werden
können. Die Client-seitige Profilspeicherung weist aber auch Probleme auf. Das Hauptproblem von
Client-seitigen Infomediaries ist die fehlende Portabilität (Mulligan und Schwartz 2000). Die Information ist an den Client-Rechner gebunden. Information, die auf einem Rechner gespeichert ist (z.B.
am Arbeitsplatz), kann nicht von einem anderen Rechner (z.B. zu Hause oder auf einem mobilen
74
4.2 Benutzerprofilspeicherung
Gerät) aus genutzt werden. Ein weiteres Problem mit heutigen Infomediary-Lösungen ist, dass die
Definition von Zugriffsrechten zwar möglich, meist aber zu komplex für die normale Nutzung ist.
4.2.3
Server-basierte Benutzerprofildatenbanken
Die Speicherung der Benutzerprofile in einem (von den Profil-nutzenden Anwendungen getrennten)
zentralen Server löst die Probleme mit der fehlenden Portabilität. Während die Infomediaries eine
Kontrolle des Benutzers über die Profilinformation bieten, sind die existierenden Server-basierten
Lösungen aber meist sehr Dienst-zentriert.
Die Historie von Server-Lösungen reicht zurück zu Authentifizierungsdiensten für mehrere Anwendungen wie Kerberos (Steiner u. a. 1988). In solchen Single-Sign-On Lösungen teilen sich mehrere
Server einen Dienst zur Authentifizierung von Benutzern. Oft wurde dabei der Authentifizierungsdienst um die Verwaltung von Benutzerprofilen erweitert, die allen angeschlossenen Diensten zur
Verfügung gestellt wurden.
Heute bieten verschiedenen Software-Hersteller Single-Sign-On Lösungen für Intranets an. Die Lösungen bauen meist auf (X.500) Verzeichnisdiensten auf oder erlauben zumindest einen Zugriff über
das LDAP Protokoll.
Globale Lösungen wie DigitalMe (www.digitalme.com) von Novell, Microsoft Passport (www.passport.com) oder der ScreenName-Dienst von AOL (my.screenname.aol.com) erweitern den ServerAnsatz auf das ganze Internet. Der Kern dieser Dienste ist meist ein zentraler Profilserver. Benutzer
können ihre persönlichen Daten dort über Web-Formulare eingeben und pflegen. Dienste, die von
den Betreibern der zentralen Server zertifiziert worden sind, können dann auf die Profilinformation
zugreifen (z.B. wenn ein Benutzer sich bei ihnen anmelden will).
Ein Microsoft Passport Account fasst beispielsweise folgende Daten zusammen:
PUID (.NET Passport Unique ID)
Vor- und Nachname
E-Mail-Adresse und/oder Telefonnummer
Demographische Daten: Land, Postleitzahl, Zeitzone, bevorzugte Sprache, Verfügbarkeit, Beruf, Geburtsdatum und Geschlecht
Wallet: Kreditkartentyp, Kreditkartennummer, Rechnungsadresse, Lieferadresse
Credentials:
– standard: E-Mail Adresse, Passwort, geheime Frage und Antwort
– alternativ: Telefonnummer und 6-stellige PIN
– stark: vierstelliger Sicherheitsschlüssel, drei geheime Fragen und Antworten
4.2.4
Liberty Alliance Projekt
Neben den großen zentralisierten Identitätsmanagement-Netzwerken wir Microsoft Passport gibt es
noch einige kleinere Ansätze. Beispiele sind XNS (www.xns.org) und Live-Id.org (www.live-id.org).
Diese Unternehmen verfolgen hauptsächlich den Ansatz einer föderierten Speicherung, d.h. einer
75
Speicherung der Profile auf unterschiedlichen Server, die von unterschiedlichen Unternehmen betrieben werden.
Um Interoperabilität zwischen den Plattformen zu ermöglichen, haben sich die kleinen Identitätsmanagement-Anbieter und andere Firmen, die bereits größere Identifikationsdienste auf dem Internet
anbieten wie AOL, eBay, MSN oder Visa in der Liberty Alliance zusammengeschlossen.
Die Liberty Alliance (siehe http://www.projectliberty.org/) definiert gerade einen Standard zur Repräsentation von Identitäten, zur Authentifizierung von Benutzern und zur Abwicklung von Zugriffsbeschränkungen auf Benutzerprofilen. Das Ziel der Standardisierung ist es Diensten zu ermöglichen,
Benutzerprofilinformation einfach untereinander austauschen zu können.
4.2.5
Benutzerprofil-Austausch
Neben den in den vorherigen Abschnitten erwähnten Diensten gibt es im kommerziellen Umfeld noch
weitere Arbeiten und Angebote zum Austausch und zur Synchronisation von Benutzerprofilinformation zwischen Benutzern oder zwischen Anwendungen eines Benutzers.
Beispiele für die Replikation von Benutzerdaten zwischen Benutzern sind Austauschdienste für Visitenkarten (z.B. www.cardxchange.net). In diesen Diensten können Benutzer Kontaktinformation (und
zusätzliche Attribute) speichern und eine Untermenge (View) dieser Information explizit bestimmten anderen Benutzern verfügbar machen. Wenn die Information von Eigentümer der elektronischen
Visitenkarte geändert wird, dann wird diese Änderung an allen Stellen nachgezogen oder die Interessenten an der Information werden über E-Mail benachrichtigt. Ähnliche Funktionalität ist auch in
kommerzielle Community-Plattformen integriert. So bieten verschiedene Alumni-Plattformen eine
Notifikation über Adressänderungen von Co-Alumni.
Austausch und Synchronisation von PIM-Daten (Personal Information Management - Terminkalender, Adressbuch, Todo-Listen und Notizen) war bisher durch die große Zahl von proprietären Protokollen auf dem Markt beschränkt. Mit SyncML (www.syncml.org) wurde hier kürzlich ein offener
Industriestandard für die Synchronisation von PIM-Daten über verschiedene Netzwerke, Anwendungen und Geräte geschaffen.
4.2.6
IDRepository
Die Anforderungen, die am Anfang dieses Abschnitts aufgeführt worden sind (Vertrauen in Dienste,
Vermeidung des Kaltstartproblems durch Mehrfachnutzung), liesen sich am besten durch einen föderierten Dienst zur Profilspeicherung lösen, der unter Benutzerkontrolle steht. Leider bieten keine der
aktuellen Ansätze eine solche Lösung.
Vor allem fehlt bei den zentralen Ansätzen eine ausreichende Einbeziehung des Benutzers. Dies zeigt
sich in der Datendefinition für das Profil (meist nur E-Commerce Information wie Lieferinformation
und Zahlungsinformation), der fehlenden Möglichkeit, Zugriffsrechte zu definieren, und der Konzentration auf einen Profilspeicherungs-Betreiber.
Wir haben uns deshalb zum Ziel gesetzt, eine eigene benutzerzentrierte Lösung zu konzipieren.
Die Kernkomponente unseres Ansatzes ist das sogenannte IDRepository. In einer IDRepositoryInstanz können ein oder mehrere Identitäten gespeichert werden. Über Schnittstellen oder zusätzliche Komponenten stellt das IDRepository diese Daten dem Besitzer der Identität und autorisierten
Diensten zur Verfügung (siehe Abbildung 4.1).
76
4.3 Modellierung von Benutzerprofilen
Benutzer
erzeugt
und
verwaltet
Profile
IDRepository
(Web-)Dienst
Lesen
Profile
Benachrichtigen
Schreiben
Profil
Cache
Dienstzugriff
Abbildung 4.1: Trennung von Profilspeicherung und -nutzung
Bei der Gestaltung einer globalen IDRepository-Lösung hat man mehrere Möglichkeiten. Die beiden
Extreme sind die Installation eines zentralen Identitäts-Servers für alle Identitäten aller Personen und
die Installation von mehreren Servern pro Person (für die verschiedenen Pseudonyme).
Nachdem eine zentrale Lösung auf Akzeptanzprobleme stoßen würde, wird die wirkliche Lösung
wohl eher zwischen diesen Extremen liegen. Es wird mehrere Identitäts-Provider geben - Dienste,
die solche Server betreiben (siehe Abbildung 4.2). Diese Server arbeiten entweder im Netzwerk oder
werden von den Clients direkt angesprochen. Ein gutes Beispiel hierfür stellt der Domain-NameService oder das X.500 Directory Server Netzwerk dar.
Ähnliche föderierte Ansätze werden in dienstzentrierter Weise auch gerade von der Liberty Alliance
entwickelt. Sobald die Spezifikation der Liberty Alliance veröffentlicht ist und erste Dienste verfügbar sind, soll geprüft werden, ob das benutzerzentrierte IDRepository mit den dienstzentrierten
Liberty Alliance Servern in einem Netzwerk zusammenarbeiten kann.
Um es Benutzern zu ermöglichen, verschiedene Identitäten auf verschiedenen IDRepositories anzulegen, und manche Informationen trotzdem nur an einer Stelle zu pflegen, erlaubt es das Konzept
schließlich noch, Teile von Profilen miteinander zu verknüpfen. Durch die Definition von Propagierungsregeln wird festgelegt, ob und wie Änderungen an einem Profil an andere Profile weitergegeben
werden (siehe hierzu auch Abbildung 4.2).
Weitere Details zur Grundarchitektur der Benutzerprofilverwaltung mit dem IDRepository sind in
(Koch und Wörndl 2001) und (Koch 2002e) zu finden. Einen Überblick zur Implementierung des
IDRepositories bietet Abschnitt 5.1.
4.3
Modellierung von Benutzerprofilen
Bei aktuellen Beispielen der Nutzung von Benutzerprofilen in Anwendungen findet sich meist eine
anwendungsspezifische, proprietäre Modellierung des Profils. Neben der Domäne ist die Modellierung meist auch auf die speziell in dieser Anwendung verwendeten (Personalisierung-)Algorithmen
abgestimmt. Für eine dienstübergreifende Nutzung von Profilinformation ist es aber notwendig, eine
generische Modellierung der Profilinformationen zu definieren, die eine Nutzung in verschiedenen
Kontexten erlaubt. Gelingt dies nicht, dann entwickelt sich das globale Profil zu einer überschnei-
77
IDRepository
Dienst
IDRepository
IDRepository
Benutzer
Kopie im
Cache
Datenpropagierung
zwischen
Identitäten
Abbildung 4.2: Verteilung der Profilspeicherung
dungsfreien Sammlung der Einzelprofile der einzelnen Anwendungen und viele der im vorhergehenden Abschnitt motivierten Vorteile der Trennung von Benutzerprofilspeicherung und Profilnutzung
ließen sich nicht realisieren.
Zum Thema Benutzermodellierung gibt es einen breiten Fundus von Arbeiten rund um den Forschungsbereich Künstliche Intelligenz. Während die meisten der Arbeiten sich mit proprietären
Profilmodellen für spezielle Expertensysteme beschäftigen, gibt es auch ein paar Ansätze zur allgemeinen Modellierung von Benutzerwissen, Benutzererwartungen und anderen Benutzerattributen.
In (Kay 1995) wird beispielsweise ein Attribut-Wert-Paar basierter Ansatz hierzu vorgestellt. Eine
sehr gute Übersicht zu den verschiedenen Aktivitäten im Bereich der Benutzermodellierung der letzten zwanzig Jahre bieten auch (Kobsa 2001) und (Fink und Kobsa 2000). Bei Profilmodellen, die für
die Nutzung durch mehrere Anwendungen vorgesehen sind, werden dabei meist Attribut-Wert-Paare
mit einfachen Attributwerten (d.h. Werten vom Typ String, Integer oder Boolean) verwendet. Die eigentliche Modellierung steckt in den Namen der Attribute, die je nach Anwendungsdomäne definiert
sind (Fink und Kobsa 2002).
Neben den akademischen Arbeiten im Bereich der Künstlichen Intelligenz gibt es auch noch verschiedene Bestrebungen zur Standardisierung von Benutzerprofilen aus der Industrie. In folgendem
Abschnitt diskutiere ich zuerst solche Standardisierungsaktivitäten etwas näher. Dann wird das für
Community-Unterstützungssysteme erarbeitete Benutzerprofil-Metamodell und -Modell vorgestellt
und einzelne Bereiche des Profilmodells näher herausgearbeitet.
4.3.1
Standardisierungsbestrebungen
Aktuelle Aktivitäten zur Standardisierung von Benutzerprofilinformationen finden sich vor allem im
E-Commerce-Bereich und konzentrieren sich auf die dort notwendigen Attribute. So behandelt das
System „Microsoft Wallet“ (als Teil von Microsoft Passport) Attribute wie Lieferadresse und Zahlungsinformation. Electronic-Customer-Relationship-Systeme wie zum Beispiel „Customer Profile
Exchange Net“ behandeln mehr die Standardisierung von in ERP- und CRM-Systemen vorhandenen
Daten.
78
Erwähnenswerte Standardisierungsbestrebungen sind weiterhin OPS, P3P, vCARD, ECML (www.
ecml.org) und Customer Profile Exchange Net CPEX. Von diesen Bestrebungen werden im Folgenden
die drei wichtigsten vCard, OPS und P3P kurz vorgestellt und diskutiert.
vCard
vCard ist ein zeilenorientiertes Textformat zur Kodierung von allgemeinen Visitenkarten, d.h. von
Teilen eines Benutzerprofils, die an andere Benutzer weitergegeben werden sollen. Zusammen mit
anderen Standards wie vCalender und vTodo wurde vCard vom nicht mehr existierenden Versit Konsortium entwickelt und ist inzwischen in Internet-RFCs dokumentiert (RFC2425 und RFC2426 für
vCard Version 3.0).
Jede Zeile in einer vCard-Datei setzt sich zusammen aus einem Attributnamen, einem Doppelpunkt
und einem Attributwert. Mehrere Werte zu einem Attribut können durch Komma getrennt angegeben
werden.
BEGIN:VCARD
VERSION:2.1
N:Koch;Michael
EMAIL;INTERNET:[email protected]
END:VCARD
Neben dem Defaulttyp STRING definiert vCard für Attributwerte noch die Datentypen BINARY,
PHONE-NUMBER (nach CCITT E.163 und CCITT X.121) und UTC-OFFSET (Coordinated Universal Time). Weiterhin ist es noch möglich, Attributwerte mit Trennzeichen (Strichpunkt) zu strukturieren (siehe hierzu z.B. das „N“-Attribut in obigem Beispiel).
Bei konkreten Attributnamen definiert vCard die folgenden:
Identifikationsinformation
– FN: Formatierter Text, der den Namen des vCard Inhabers darstellt
– N: Strukturiertes Attribut mit den Komponenten des Namens: Familienname, Vorname, zusätzliche Namen, Titel, nachgestellte Titel.
– NICKNAME
– PHOTO
– BDAY (z.B. BDAY:1996-04-15 oder BDAY:1987-09-27T08:30:00-06:00)
Lieferadressinformation
– LABEL: Formatierter Text, der die Lieferadresse darstellt
– ADR: Strukturiertes Attribut mit den Komponenten einer Adresse: Postfach, Adresszusatz, Straße, Stadt, Region, Postleitzahl, Land, TYPE = dom(domestic), intl(international delivery), postal,
parcel, home, work, pref(preferred delivery address),
z.B. ADR;TYPE=dom,home,postal;;123 Main Street;Any Town;CA;91921-1234
Telekommunikationsinformation
– TEL: TYPE = home, msg(voice messaging support), work, pref, voice, fax, cell, video, pager,
bbs, modem, car, isdn, pcs,
z.B. TEL;TYPE=work,voice,pref,msg:+1-213-555-1234
79
– EMAIL: TYPE=internet,x400,pref
– MAILER: Typ der E-Mail Software, die vom Benutzer genutzt wird
Geographische Information
– TZ: time zone, UCT offset, z.B. TZ:-05:00, TZ;VALUE=text:-05:00;EST
– GEO: Globale Position des Objekts, zu dem die vCard gehört - Strukturierter Wert, der aus zwei
Teilwerten (Fließkommazahlen) besteht: Länge und Breite, z.B. GEO:37.386013;-122.082932
Organisationsinformationen
– TITLE: Job/Funktions-Beschreibung (nach X.520)
– ROLE: Rollenbeschreibung (nach X.520)
– LOGO:
– AGENT: Verweis auf einen Vertreter oder auf eine Ressource, die mit der vCard assoziiert ist, z.B.
AGENT;VALUE=uri:CID:[email protected]
– ORG: X.520 Organisationsname
Beschreibende Information
– CATEGORIES: Kategorien zur Beschreibung der vCard,
z.B: CATEGORIES:TRAVEL AGENT,INTERNET,IETF
– NOTE: X.520 Beschreibungsattribut
– PRODID, UID, URL, REV, VERSION
Sicherheitsinformation
– CLASS: Zugriffsklassen; PUBLIC,PRIVATE,CONFIDENTIAL
– KEY: Public Key oder Zertifikat
Eine Erweiterung der Attributemenge ist nach einem Mechanismus, der in RFC2045 vorgestellt ist,
möglich. Zusätzlich können auch nicht registrierte private Attribute verwendet werden. Solche Attribute werden mit einem vorangestellten ’X-’ im Namen gekennzeichnet.
Open Profiling Standard - OPS
OPS ist ein erster Vorschlag zur Standardisierung der Erstellung, Speicherung und Verwendung von
Benutzerprofilen im Internet (Juni 1997). Zur Erreichung einer möglichst breiten Akzeptanz wurde
dabei versucht, auf bestehende Standards wie vCard zurückzugreifen (Hensley u. a. 1997).
Die Daten werden als Attribute mit ihrem zugehörigen Wert gespeichert. Mehrere dieser AttributWert-Paare können zu sogenannten Sektionen zusammengefasst werden. Damit wird eine hierarchische Organisation der Benutzerprofildaten erreicht. Ein Profil ist definiert als eine hierarchische
Struktur von benamten Sektionen und Untersektionen.
Zu den im Standard definierten Sektionen gehören ’Globally Unique ID’, ’Pairwise Unique IDs’,
’Demographics’, ’Contact and personal information’, ’Currency’ und ’User agent preferences’. In
diesen Sektionen sind folgende Attribute definiert:
Demographische Informationen (Sektion DEMO)
– C (country)
– ZIP
80
– AGE
– G (gender)
– SN (preferred screen name)
Kontaktinformation (Sektion CONT)
– FN (formatted name)
– N (name)
– PHOTO (photograph)
– PHOTO.TYPE
– BDAY
– ADR
– LABEL
– TEL
– EMAIL
– MAILER
– TZ (time zone)
– GEO (geographic position)
– TITLE
– ROLE (business category)
– LOGO
– AGENT
– ORG
Neben der Profilstruktur wird auch die Struktur des Gesamtsystems festgeschrieben. Dabei sollen die Profildaten beim Benutzer selbst gespeichert werden. OPS entspricht dabei dem CookieMechanismus heutiger Web-Browser (es erlaubt einem Server Daten auf einem OPS-Client zu speichern und zu lesen).
P3P - Platform for Privacy Preferences
P3P definiert hauptsächlich ein Protokoll zur Aushandlung von Zugriffsrechten auf Benutzerprofile
(siehe hierzu auch Abschnitt 4.4.2). Daneben werden aber auch Standards für die Strukturierung und
Darstellung von Benutzerprofilen vorgegeben.
Ähnlich wie OPS legt auch P3P einen hierarchisch strukturierten Attributraum zugrunde. Der Attributraum ist grob in die Bereiche ’user’, ’dynamic’ und ’thirdparty’ unterteilt. Dabei dienen die
Attributnamen im Bereich ’dynamic’ hauptsächlich zum Referenzieren von Daten, die der Dienst
speichern darf oder nicht speichern soll. Eine zentrale Speicherung dieser Daten ist nicht vorgesehen
und es ist auch keine Kodierung dafür definiert. Nachfolgend eine Liste der Hauptattribute, die der
Standard in den Bereichen definiert:
user.name
user.bdate
user.login
81
user.cert
user.gender
user.employer
user.jobtitle
user.home-info
user.business-info
dynamic.clickstream
dynamic.httpd
dynamic.clientenvents
dynamic.cookies
dynamic.miscdata
dynamic.searchtext
dynamic.interactionrecord
thirdparty.*
Die einzelnen Attribute haben teilweise komplexe Datenstrukturen als Werte. Damit wird eine weitere
Untergliederung des Attributbaumes definiert. So haben die beiden Attribute user.home-info und
user.business-info den Datentyp contact, welcher folgende Unterattribute definiert:
postal
postal.name
postal.street
postal.city
postal.stateprov
postal.postalcode
postal.country
postal.organization
telecom
telecom.telephone
telecom.fax
telecom.mobile
telecom.pager
online
online.email
82
online.uri
4.3.2
Profil-Metamodell
Den Anregungen aus den vorgestellten Standardisierungsbestrebungen folgend, soll das allgemeine
Profilmodell für Community-Unterstützungssysteme als Menge von Attribut-Wert-Paaren mit einem
hierarchisch strukturierten Attribut-Namensraum aufgebaut werden.
Der Aufbau ist dabei grundsätzlich identisch zu den Datenmodellen für Item und Category (siehe Kapitel 3). Mit dem hierarchischen Namensraum für Attributnamen und zusätzlicher Metainformation
zu den Attributen gibt es aber doch einige Erweiterungen. Aus diesem Grund soll an dieser Stelle
zuerst das Profil-Metamodell konkretisiert werden. Unter Metamodell verstehe ich dabei die Regeln,
denen ein allgemeines Profilmodell folgt (und damit auch die Regeln, nach denen ein Profilmodell
erweitert werden kann). Das Metamodell beschreibt also, wie ein Profilmodell aufgebaut sein kann
und was in einem Profilmodell auf welche Weise dargestellt werden kann. Das Profilmodell legt dann
die Attributnamen und Detailinformation zu den Attributen (z.B. Datentypen) fest. Daten zu einem
bestimmten Benutzer werden schließlich in Profilinstanzen gespeichert.
Grundstruktur
Ein Profilmodell besteht aus einer Menge von Attributen mit Unterattributen, angeordnet in einer
hierarchischen Struktur. Ein Attribut entspricht einem Knoten in einem Profilbaum (Blatt oder Zwischenknoten). In Instanzen des Modells können sowohl Blätter wie auch Zwischenknoten einen
konkreten Wert (Attributwert) besitzen.
Bei manchen Attributen bzw. Unterbäumen des Profilbaums kann es wünschenswert sein, verschiedene Varianten zu speichern. Neben der Privatadresse soll beispielsweise noch die Büroadresse oder
eine Urlaubsadresse gespeichert werden. Obwohl dies durch zwei verschiedene, aber gleich aufgebaute Äste im Profilbaum möglich wäre, hat sich in der praktischen Anwendung gezeigt, dass zur
Ermöglichung eines effizienten Zugriffs auf Varianten eine explizite Modellierung im Profilmodell
sinnvoll ist.
Im Profilmodell soll deswegen definiert werden können, dass zu bestimmten Knoten verschiedene
Varianten möglich sind. Wird für den Knoten ’contact’ die Verwendung von Varianten zugelassen,
dann könnten in einer Profilinstanz beispielsweise sowohl Informationen zu ’contact[work].*’ als
auch zu ’contact[private].*’ gespeichert werden.
Attribut-Metainformation
In verschiedenen Anwendungen finden sich Ansätze, zu Profilattributen Zusatzinformationen zu speichern, die eine Verwendung der eigentlichen Attributwerte unterstützen. Ein Beispiel für solche Metainformation sind Angaben über die Zuverlässigkeit eines Attributwertes. Also beispielsweise eine
Unterscheidung, ob der Wert explizit vom Benutzer eingegeben worden ist, oder ob er aus anderen
Daten abgeleitet worden ist.
Bei Benutzerprofilen, die von mehreren Anwendungen geändert werden können, spielt als weitere
Metainformation auch die Herkunft der Profilinformation eine Rolle, also eine Referenz auf die Anwendung, die diese Information gesetzt hat. Teilweise könnte hier sogar eine Nachprüfbarkeit dieser
Information mittels kryptographischen Verfahren gewünscht sein (Koch und Wörndl 2001).
Bei Metainformationen zu Profilattributen gibt es Metaattribute, die für jedes Attribut im Benutzerprofil Sinn machen und solche, welche vielleicht nur für domänenspezifische Attribute relevant sind.
83
Aus diesem Grund soll keine feste Menge von Metainformationen festgelegt werden, sondern die
dynamische Definition beliebiger Attribute erlaubt werden.
Attribut-Datentypen
Die verschiedenen angedachten Anwendungen von Benutzerprofilen machen verschiedenste Datentypen für Attribute notwendig. Dabei sehen wir zunächst einmal von einfachen geschachtelten Datenstrukturen ab. Diese sollten mit Hilfe der hierarchisch strukturierten Attributnamen als verschiedene
Attribute modelliert werden (vgl. die Definition von ’contact’ bei P3P).
Die Anforderungen in den aktuell untersuchten Anwendungen machen momentan folgende Attributdatentypen notwendig: String, Integer, Real, Boolean, Mengen von Basistypen, Listen von Basistypen, gewichtete Listen von Basistypen, (Hash-)Maps von Basistypen. Neben den Basistypen sind als
Datentypen weiterhin einzelne oder Mengen von Referenzen auf Objekte vom Typ User, Item oder
Category gefordert.
Zusätzlich zur Angabe eines Datentyps kann bei einem Attribut auch noch eine Einschränkung der
Wertemenge definiert werden. So können Attribute vom Typ String sein, aber nur eine beschränkte
Menge von Werten zulassen.
Schließlich soll es auch noch möglich sein, Defaultwerte für Attribute zu definieren, also Werte, die
zurückgegeben werden, wenn kein expliziter Wert gesetzt ist. Hierbei sind auch geeignete Werte für
die Attribut-Metainformation zu definieren.
4.3.3
Profilmodell
Ein Profilmodell definiert ausgehend vom Metamodell konkrete Attributnamen, Datentypen zu den
Attributen, sowie mögliche Werte und Default-Werte. In diesem Abschnitt soll das für Cobricks
verwendete Profilmodell vorgestellt werden.
Von den oben vorgestellten Standards definiert P3P die breiteste Menge von Attributen. Aus diesem
Grund wird das in P3P definierte Schema als Grundlage für die Entwicklung eines Profilstandards für
Community-Unterstützungssysteme verwendet und erweitert.
Aus der Beschäftigung mit Community-Unterstützung und Electronic Commerce konnten folgende
Teilbereiche für Benutzerprofile identifiziert und konkretisiert werden:
Demographische Information (z. B. Name, Geburtsdatum, Familienstand, Jahreseinkommen)
Adress-/Kontaktinformation
Zahlungsinformation (z.B. Bank- und Kreditkartendaten)
Beziehungsinformation (z.B. Freundes- oder Kontaktlisten oder allgemeine Adressbücher)
Information zu den Interessen, Qualifikationen
Dienstspezifische Präferenzen und Konfigurationseinstellungen
Datenschutzpräferenzen
Verhaltenshistorie ((Web-)Besuchshistorie, Kaufhistorien)
84
Bewertungen (von Items)
Kalenderinformationen (Agenda)
Nachfolgend ein Überblick über das in unseren Prototypplattformen benutzte gemeinsame Benutzerprofilmodell mit einer Auswahl von konkreten Attributen aus den verschiedenen Teilbereichen:
basic.personal.firstname (String)
basic.personal.lastname (String)
basic.personal.maidenname (String)
basic.personal.languagespoken
basic.demographics.incomelevel (String, [low, middle, high, very high])
basic.demographics.education (String, [])
basic.demographics.gender ([male, female])
basic.demographics.martialstatus
([single, married, divorced, widowed, unknown])
basic.demographics.birthdate (Date)
basic.demographics.smoker ([yes, no])
basic.demographics.nationality.passportnumber (String)
basic.demographics.nationality.primaryresidency ([yes, no])
basic.contact[work,private] - Varianten
basic.contact.timezone (String, ISO 8601)
basic.contact.postal.name (String)
basic.contact.postal.street (String)
basic.contact.postal.city (String)
basic.contact.postal.stateprov (String)
basic.contact.postal.postalcode (String)
basic.contact.postal.country (String, ISO 3166)
basic.contact.postal.type ([pobox, street])
basic.contact.telecom.telephone.intcode (String)
basic.contact.telecom.telephone.number (String)
basic.contact.telecom.telephone.comment (String)
basic.contact.telecom.telephone.usage.type (String)
basic.contact.telecom.telephone.usage.availabletimes
([morning, afternoon, day, anytime])
basic.contact.telecom.telephone.usage.availabledays
([weekdays, weekends, anyday])
basic.contact.telecom.fax.*
basic.contact.telecom.mobile.*
basic.contact.telecom.pager.*
basic.contact.online.email (String)
basic.contact.online.uri (String)
basic.business.employmentstatus
([employed, selfemployed, unemployed, retired, student, homemaker])
basic.business.jobtitle
basic.business.employer
basic.business.department
basic.finance.card.number
basic.finance.card.type
basic.finance.card.expdate
basic.finance.card.owner
basic.finance.account.number
basic.finance.account.bank
basic.finance.account.bankid
basic.finance.account.comment
basic.certificate
85
basic.location
interests.basic.auto
interests.basic.career
interests.basic.entertainment
interests.basic.hobby.sports
interests.basic.hobby.craft
interests.basic.hobby.cooking
interests.basic.hobby.yard-garden
interests.basic.exercise
interests.basic.living
interests.basic.music
interests.basic.news
interests.basic.pets
interests.basic.politics
interests.basic.religion
interests.basic.sex
interests.basic.sports
interests.basic.travel
interests.TAXONOMYID.*
interests.giftlist
pim.bookmarks
pim.calendar.*
pim.files
pim.fitness
pim.food
pim.health
pim.military
pim.network
pim.network.buddylist.LISTNAME (Set of USER)
pim.network.banlist.LISTNAME (Set of USER)
pim.network.adressbook
pim.network.community
pim.network.memberships
pim.tasks
pim.traffic
privacy.alertsetting
privacy.policy
rating.OBJECTCLASS.OBJECTID
application.APPID.*
appliance.APPID.*
preference.language
preference.radio-station
history.APPID.clickstream
history.APPID.lastsearchstring
history.APPID.lastlogin
Die konkrete Definition aller Attribute geht weit über das hinaus, was in dieser Arbeit dargestellt werden kann. In diesem Abschnitt soll nur noch auf allgemeine Herausforderungen und Lösungsmöglichkeiten bei Informationen aus den drei Bereichen Interessensinformation, Beziehungsinformation
und Bewertungsinformation eingegangen werden.
86
Interessensinformation
Ein zentrales Element von Benutzerprofilen ist die Kodierung von Information zu den Interessen des
Benutzers. Dies kann als Verbindung des Benutzerkonzeptes mit der Anwendungsdomäne gesehen
werden. Hier ist es also notwendig, zu den verschiedenen Unterkonzepten in der Anwendungsdomäne
zu speichern, ob der Benutzer daran interessiert ist, ihnen eher gleichgültig gegenübersteht, oder
explizit nicht daran interessiert ist.
Dem Grundsatz der Aufteilung in möglichst viele Attribute folgend, legen wir für alle Konzepte der
Domäne im Teilbaum ’interests.’ einzelne Attribute an. In diesen Attributen wird dann das Wissen über das entsprechende Interesse des Benutzers kodiert. Wie in Kapitel 3 beschrieben worden
ist, ist die Domäne momentan als Menge von hierarchisch strukturierten Kategorien kodiert. Manche dieser Kategorien können als „SharedBuddyLists“ explizit Mitglieder haben. Die den Kategorien entsprechenden Attribute im Benutzerprofil könnten demnach folgendermaßen aufgebaut sein:
’interests.’+Kategorienname. Alternativ dazu erlauben wir auch die Speicherung einer Menge von
Category-Referenzen in einem Profilattribut. Damit kann grundsätzlich dasselbe Ergebnis erreicht
werden. Über die Kontextklassen kann sogar die Semantik der Interessensbeziehung eingegrenzt
werden.
Ein Problem bei dieser Lösung ist, dass auf jeder Plattform unterschiedliche Kategorien definiert
werden können. Damit ist keine plattformübergreifende Kodierung und Nutzung der Interessensinformation möglich. Als Lösung hierzu haben wir eine sehr allgemeine Kategorienmenge für alle
Community-Plattformen definiert, nach der Interessen im ’interests.basic’-Teilbaum definiert werden
können. Jede Plattform kann daraus Rückschlüsse auf die Interessen an ihren konkreten Kategorien ziehen (und umgekehrt). Auch können hier die schon angesprochenen Verfahren zur automatischen Abbildung verschiedener Kategorienbäume aufeinander zur Anwendung kommen. Zusätzlich
kann jede Anwendung ihre speziellen Interessensinformationen noch im Teilbaum ’application’ speichern bzw. Informationen zu anwendungsübergreifend definierten Taxonomien in Teilbäumen ’interests.TAXONOMYID’.
Zur Kodierung des konkreten Interesses an einer Kategorie gibt es auch verschiedene Ansätze. In
(Fink und Kobsa 2002) wird eine Möglichkeit zur Kodierung von Interessen mit verschiedenen (normalisierten) Wahrscheinlichkeiten, die durch verschiedene Vorhersageverfahren gewonnen werden,
vorgestellt. Wir greifen dies auf und kodieren das Interesse an einer Kategorie als ganze Zahl im Bereich von ’0’ bis ’100’. Dabei bedeutet ’100’ hohes Interesse, ’50’ Gleichgültigkeit und ’0’ absolut
kein Interesse. Wenn keine Information über das Interesse vorhanden ist, dann bleibt das Attribut
undefiniert. Neben dem Attributwert wird über die Metainformationen noch die Zuverlässigkeit des
Wertes (confidence) charakterisiert. Aus den Informationen kann bei Bedarf über Regeln ein binärer
Wert ermittelt werden.
Beziehungsinformation
Unter Beziehungsinformation versteht man Information über die Beziehungen zwischen den einzelnen Benutzern. Quelle solcher Beziehungen können gemeinsame Interessen oder auch ein gemeinsamer Freundeskreis oder verwandschaftliche Bande sein.
Den Beispielen verschiedener Community-Unterstützungssysteme folgend, sehen wir hier zuerst einmal Informationen über Buddylisten vor. Diese werden als Listen von Benutzeridentifikatoren in
Attributen der Form ’pim.network.buddylist.LISTNAME’ gespeichert.
87
Auch zu den Beziehungsinformationen zählen kann man die Informationen in den SharedBuddyLists. Weiterhin sind in den verschiedenen Item-Daten Informationen verborgen, die auf Beziehungen schließen lassen. Diese sind natürliche Kandidaten für eine Definition solcher Beziehungen über
Regeln. Schließlich können Beziehungen auch noch über das Konzept der Kategorien modelliert
werden (durch Interessensbeziehungen zwischen Usern und Kategorien).
Die allgemeinste Form der Speicherung von Beziehungsinformation bieten dabei aber die Benutzerprofilattribute, die Listen von Referenzen auf Benutzerobjekte speichern (wie Buddylist). Durch
die Möglichkeit der weiteren Spezifikation mit Kontextklassen kann hier eine Anreicherung der Beziehungsinformation mit Semantikinformation erreicht werden und zwischen verschiedenen Beziehungsklassen unterschieden werden. Die Realisierung mit den Kontexklassen folgt dabei allgemeineren Überlegungen aus dem Dissertationsprojekt von Michael Galla.
Bewertungsinformation
Informationen darüber, wie Benutzer bestimmte Objekte oder Informationen bewerten, liefern wichtige Aussagen über die Interessen eines Benutzers und können beim aktiven und beim automatischen
kollaborativen Filtern eingesetzt werden.
Zu diesem Zweck kann erstens die Kommentierung bzw. Bewertung von Items (ITEMANNOTATION) als Teil des Benutzerprofils betrachtet werden. Über die Items hinaus muss es aber möglich
sein, Bewertungen zu beliebigen Objekten zu speichern. Die Hauptherausforderung dabei ist das
Finden von eindeutigen Identifikatoren für Objekte. Eine vielversprechende Lösung hierzu ist es,
sich auf bestehende Identifikationssysteme zu stützen. Ähnlich wie bei der Definition von URIs
(RFC2396), die prinzipiell dasselbe Ziel verfolgen, setzt sich der Identifikator eines Objektes dann
aus einem Identifikator für das konkrete Identifizierungsschema und dem in diesem Schema erstellen Identifikator zusammen. Für das Beispiel Bücher bietet sich das ISBN-Identifikationssystem an,
bei Kinofilmen könnte man die Identifikation in der Internet Movie Database IMDB verwenden.
Bewertungen werden dann im Benutzerprofil in der Sektion ’rating’ mit Untersektionen für verschiedene Objekttypen gespeichert. Nach den Schlüsselworten folgt ein Kennzeichner für das Identifikationsschema und dann die Identifikation in diesem Schema, z.B. ’rating.books.isbn.3540669841’,
’rating.movies.imdb.0295297’.
Neben dem Aufbau der Attributnamen ist weiterhin der Aufbau der Attributwerte von Belang. Für die
Anwendung beim automatischen kollaborativen Filtern benötigen wir eine numerische Bewertung.
Hier hat sich in vergleichbaren Systemen in den letzten Jahren die 5er oder 7er-Skala durchgesetzt.
Daneben gibt es noch Prozentwerte von 0 bis 100. Für unsere Anwendungen unterstützen wir durch
entsprechende Datentypen beliebige Skalen und speichern die Information intern als Prozentwert.
Zusätzlich zu der eigentlichen Bewertung kann im Profil auch noch ein Kommentar gespeichert werden (für das nicht-automatische kollaborative Filtern). Dieser Kommentar wird (falls vorhanden) im
Unterattribut ’rating.*.comment’ gespeichert.
4.4
Privatheit und Zugriffskontrolle
Die Trennung der Speicherung und der Nutzung von Benutzerprofilen ermöglicht deren Wiederverwendung, trägt aber nicht notwendigerweise zu einer Ermöglichung von Privatheit für die Benutzer
bei. Hierzu werden ein Zugriffskontrollsystem und Zugriffstransparenz benötigt.
88
4.4 Privatheit und Zugriffskontrolle
4.4.1
Zugriffskontrolle in einer Plattform
Nachdem Benutzerprofile auf Community-Plattformen nicht nur zur Nutzung durch die Plattform
selbst (z.B. zur Personalisierung) gespeichert werden, sondern auch zur Präsentation gegenüber anderen Benutzern vorgesehen sind (Awareness, Matchmaking), spielt die Definition von Zugriffsrechten
bezüglich Endbenutzern eine große Rolle. Darunter versteht man Möglichkeiten zur Kontrolle der
Datennutzung auf Benutzerebene.
Grundsätzlich könnten zu diesem Zweck erprobte Methoden zur Spezifikation von Zugriffsrechten,
wie zum Beispiel die rollenbasierte Zugriffskontrolle (role based access control, (Ferraiolo und Kuhn
1992)) eingesetzt werden. Diese Methoden erlauben meist eine Zusammenfassung von Benutzern in
Gruppen (Rollen) und eine Vergabe von mehr oder weniger feinen Rechten auf Daten an einzelne
Benutzer oder solche Gruppen. Einen ähnlichen Ansatz haben wir bereits allgemein für die Regelung
des Zugriffs auf Dienste und Items realisiert (siehe Abschnitt 3.3.2).
Sikkel stellt in (Sikkel 1997; Sikkel und Stiemerling 1998) eine gute Übersicht über Zugriffskontrolle
allgemein dar und wendet die Verfahren auf kollaborative Systeme (speziell den BSCW-Server) an.
Dabei werden unter anderem verschiedene Möglichkeiten der Definition von Rollen und Gruppen besprochen. In unserem Fall könnten hier die schon vorhandenen Möglichkeiten der Gruppendefinition
mittels Buddylisten und SharedBuddyLists genutzt werden und auf Teilbaum- oder Attributebene
Zugriffsrechte spezifiziert werden.
Im Gegensatz zur allgemeinen Zugriffskontrolle, bei der es nur darum geht zu entscheiden, ob ein Zugriff erlaubt werden soll oder nicht, gibt es beim Zugriff auf Benutzerprofilinformation eine weitere
Anforderung. Es sollte möglich sein, für verschiedene Zugreifer verschiedene Varianten (Granularitäten) der Information zurückzuliefern. Ein Beispiel dafür ist die Anforderung, dass die Information
über den momentanen Aufenthaltsort eines Benutzers nur einer kleine Gruppe im Detail zur Verfügung gestellt werden. Die anderen Community-Mitglieder sollen nur sehen können, in welcher Stadt
sich der Benutzer gerade aufhält.
Diese erweiterten Anforderungen lassen sich mit allgemeinen Regeln zum Profil erfüllen. Wenn
ein Benutzer ein Attribut auslesen möchte, dann wird ein Regelsatz ausgewertet, der das Profil des
anfragenden Benutzers und das angefragte Profil als Eingabe erhält. Der anfragende Benutzer erhält
eine Antwort entsprechend der Regelauswertung.
Grundsätzlich entsprechen Regeln dabei Funktionen, die für eine Menge von Eingabewerten einen
Ausgabewert festlegen.
Beispiele für Bedingungen, von denen der Ausgabewert abhängen kann, sind folgende:
Ist anfragender Benutzer im Radius von x Metern?
Ist anfragender Benutzer Mitglied in einer persönlichen Buddylist?
Ist anfragender Benutzer Mitglied in der SharedBuddyList y?
Neben dem Namen des anfragenden Benutzers muss folglich auch das Benutzerprofil des anfragenden
und des angefragten Benutzers bei der Regeldefinition zur Verfügung stehen.
Allgemein definieren wir folgende beiden Funktionen:
attrvalue(userid, attrname)
attrvalue(userid, attrname, auserid)
89
Die erste Funktion liefert den Wert eines Attributs attrname aus dem Profil eines bestimmten
Benutzers userid. Dies kann entweder durch Zurückgriff auf einen gespeicherten Wert (Faktenwissen) erfolgen, oder durch Ableitung aus Regeln (z.B. Ableitung des Aufenthaltsortes aus dem
Terminkalender).
Die zweite Funktion liefert den Wert, den ein bestimmter anfragender Benutzer auserid sehen darf.
Bei der Definition von Regeln für dieses Prädikat sind drei Fälle zu unterscheiden:
Im einfachsten Fall ist attrvalue(userid, attrname, auserid) = attrvalue(userid, attrvalue), es wird
also als Antwort schlicht der eigentliche Wert des Attributs zurückgegeben.
Ein weiterer wichtiger Spezialfall ist, dass die Antwort nur von der Identität des anfragenden
Benutzers, nicht aber von dessen Benutzerprofil abhängt.
Der allgemeinste Fall ist schließlich, dass die Auswertung sowohl von der Identität des aufrufenden Benutzers als auch von Werten dessen Benutzerprofils abhängig ist.
Bei der Definition der Regeln sollte es sowohl für Vergleichsoperationen als auch für die Ermittlung
des zurückzugebenden Wertes möglich sein, verschiedene Funktionen zu verwenden. Im Projekt
Cosmos wurde dies insbesondere für die Lokalitätsinformation angewandt. So wurden Funktionen
definiert, welche die Entfernung zwischen Benutzern berechnen (z.B. distance(userid.location, auserid.location) < 4000) oder solche, die eine Lokalitätsinformation vergröbern (z.B. location-granularity(userid.location, ’town’)). Siehe hierzu auch (Groh 2002).
Mit den Regeln können Kommunikationspräferenzen modelliert werden, Zugriffsrechte und Zugriffsgranularitäten für bestimmte Benutzergruppen gesetzt werden, und das automatische Setzen von location oder ähnlichen Attributen nach Zeit oder anderen Parametern erreicht werden. Für alle Zwecke
sind die Regeln gleich aufgebaut. Sinnvolle Beispiele für Regeln (in natürlicher Sprache) sind beispielsweise:
Gib allen Usern auf meiner Buddyliste, die sich in einer Entfernung von 200 Meter um meinen
Aufenthaltsort befinden, meinen aktuellen Standort.
Gib allen anderen Usern meinen aktuellen Standort nicht
Gib allen anderen Usern von meinen aktuellen Standort nur die Stadt
Zwischen 0800 und 2000 Uhr setze Erreichbarkeitsstatus auf ’NurMessagePull’
Zwischen 0800 und 2000 Uhr setze Erreichbarkeitsstatus auf ’NurMessagePull’ für User deren
Interessen das Keyword ’Sport’ enthält und auf ’nein’ für alle anderen User
Ein Problem mit dieser allgemeinen Möglichkeit zur Definition von Privatheitsregeln liegt in der
Benutzbarkeit. Um eine Akzeptanz bei den Benutzern zu erreichen, muss hier sowohl an intuitiven
Benutzungsschnittstellen als auch an einfachen Möglichkeiten zur Vorbelegung gearbeitet werden.
Im Projekt Cosmos wurde hierzu beispielsweise eine Sammlung von Regelpakten entwickelt, die
verschiedene Privatheitsanforderungen erfüllen:
Complete Privacy: Dieses Paket hat für alle persönlichen, statischen und dynamischen Attribute
(Voller Name, Adressen, Telefonnummern, E-Mail, Ort, etc.) die Regel:
attrvalue(userid, attrname, auserid) = nil
90
Strong Privacy: Dieses Paket hat für alle persönlichen, statischen und dynamischen Attribute
(Voller Name, Adressen, Telefonnummern, E-Mail, Ort, etc.) die Regel:
attrvalue(userid, attrname, auserid) = nil.
Ausnahmen sind der volle Name und die E-Mail-Adresse mit der Regel
attrvalue(userid, ’basic.contact.online.email’, ’*’) =
attrvalue(userid, ’basic.contact.online.email’)
Buddylist: Hat für alle Attribute die Regeln
attrvalue(userid, attrname, auserid) =
isInBuddylist(auserid, userid.buddylist):
attrvalue(userid, attrname)
und
NOT isInBuddylist(auserid, userid.buddylist): nil.
Ausnahmen gibt es wieder für den vollen Namen und die E-Mail-Adresse.
Die konkret gewählten und angepassten Regeln sind Teil des Profils und können somit zwischen
verschiedenen Plattformen geteilt werden.
4.4.2
Zugriffskontrolle zwischen Plattformen
Wenn die Zugriffskontrolle in einer Plattform, also die endbenutzerbasierte Zugriffskontrolle gelöst
ist, stellt sich noch die Aufgabe, welchen Plattformen überhaupt Information zugänglich gemacht
werden soll, und wieviel Information zugänglich gemacht werden soll. Hintergrund dieser Anforderungen ist, dass die Plattformen verschiedene Ziele verfolgen, und die Information (neben der
Präsentation gegenüber Benutzern) zu verschiedenen Zwecken einsetzen.
P3P - Platform for Privacy Preferences
Eine wichtige Entwicklung im Bereich der Abwicklung von Zugriffsrechten zwischen Plattformen
ist P3P (Cranor u. a. 2000). Nachdem unsere Lösung eng auf P3P aufbaut, soll in diesem Abschnitt
zuerst kurz P3P vorgestellt werden, bevor genauer auf die vorgeschlagene Lösung eingegangen wird.
P3P liegt folgendes Szenario zugrunde: Der Benutzer stelle sein persönliches Profil auf seinem lokalen Web-Browser zur Verfügung. Mit dem Browser nutzt er verschiedene Dienste im Web, welche
Informationen aus dem Profil des Benutzers benötigen. Zur Ermöglichung einer automatischen Abwicklung beschreibt jede Anwendung genau, welche Daten zu einem Benutzer sie benötigt und wozu
sie sie benötigt. Diese Beschreibung (privacy policy) wird in XML codiert. Auf der anderen Seite
spezifiziert der Benutzer einmal seine Präferenzen bezüglich seiner Privatsphäre, also welchen Anwendungen für welchen Zweck welche Daten bekommen können. Der Browser des Benutzers kann
dann mit den Präferenzen und der Policy selbständig entscheiden, welche Daten übertragen werden
sollen und welche nicht.
Der Standard definiert dazu das Aushandlungsprotokoll und Datenstrukturen für Policy und Verhandlung (siehe auch Seite 81).
Obwohl P3P einen Mechanismus zur Verfügung stellt, der sicherstellt, dass Informationen nur im
Rahmen einer Vereinbarung ausgetauscht werden, so bietet das Protokoll jedoch keinen Mechanismus zur Überprüfung an, ob der Dienst die Daten wirklich nur in der angegebenen Art und Weise
verwendet. Dazu werden weitere Organisationen ins Spiel gebracht, die die verschiedenen Dienste
überprüfen und ihnen ggf. ein Gütesiegel geben. z.B. TRUSTe.
91
IDRepository - Tickets und automatische Aushandlung
Bei der Trennung von Client und Profilspeicherung, wie in unserem Fall vorgesehen, ergibt sich das
Problem der Autorisierung von Profilzugriffen. Hierzu haben wir verschiedenen Beispielen aus dem
Bereich der Verteilen Systeme (z.B. Kerberos (Steiner u. a. 1988)) folgend, sogenannte Zugriffstickets
eingeführt. Die Tickets kodieren welche Daten der Dienst in welcher Weise (nur lesend, schreibend)
zugreifen kann und können vom Dienst als Legitimation beim Zugriff auf das IDRepository genutzt
werden.
Die einfachste Möglichkeit zur Vergabe der Tickets ist es, diese explizit vom Eigentümer eines Profils
für den Dienst auszustellen, der Zugriff auf Teile des Profils haben soll. Die Übergabe von Tickets
kann also explizit beim Registrieren bei Diensten erfolgen. Notwendig ist hierzu eine einfache Möglichkeit, Tickets zu erzeugen. Bei Web-basierten Diensten kann der Dienst, der ein Ticket erhalten
möchte, beispielsweise einen Verweis auf die Web-Benutzungsschnittstelle des Profil-Repositories
zur Verfügung stellen, die bereits die geforderten Rechte kodiert. Der Benutzer braucht sich dann nur
noch gegenüber dem Profilserver zu authentifizieren und die Anfrage bestätigen.
Zusätzlich zur expliziten Vergabe können wir aber auch die Ideen von P3P aufgreifen und eine automatische Vergabe von Tickets über den Vergleich von Datenschutzerklärungen der Dienste und
Privacy-Präferenzen des Benutzers realisieren. Dazu stellt der Benutzer im IDRepository Regeln ein,
nach denen entschieden werden kann, welchen Diensten Tickets für welche Rechte gegeben werden
können. Dienste liefern dann ihre Privacy Policy, d.h. eine kodierte Aussage, welche Daten sie haben
möchten, und was sie damit anfangen wollen. Entsprechend den Regeln kann das IDRepository dann
Zugriffs-Tickets ausstellen und übermitteln.
Eine Erweiterung der P3P-Konzepte und erste Ideen zu Zugriffs-Tickets sind in (Wörndl 2002),
(Wörndl und Koch 2002) und (Wörndl 2001) dokumentiert.
Wie schon bei der Vorstellung von P3P angeklungen ist, kann der plattformübergreifende Austausch
von Profilinformationen nicht nur von der Technologieseite her gesehen werden. Nachdem Benutzerprofilinformation anderen Akteuren zur Verfügung gestellt wird, kann technisch nicht verhindert
werden, dass diese diese Information weitergeben. So müssen rechtliche und Vertrauensbarrieren
aufgebaut werden. Erste Ansätze dazu sind die Zertifizierung von Profildatennutzern.
Von großer Wichtigkeit ist auch die spezielle Berücksichtigung von Benutzungsschnittstellen. Erfahrungen mit konfigurierbaren Anwendungen zeigen, dass vielfach die Funktionalität nicht genutzt
wird, weil sie zu unintuitiv oder schwer zugänglich ist. Gerade beim Konfigurieren von Rechten
und der Übersucht über Zugriffe auf das Profil ist es aber essentiell für das Vertrauen des Benutzers
in die Technologie, dass er das Gefühl hat, die Technologie bedienen zu können. Hierzu sind neue
Benutzungsschnittstellenkonzepte notwendig.
Communities bzw. die Kenntnis der Community-Zugehörigkeit selbst können bei der Definition von
Zugriffsrechten helfen.
Weiterführende Information zu diesen Themenbereichen ist in folgenden Veröffentlichungen dokumentiert: (Koch 2002c), (Koch 2002d), (Wörndl und Koch 2002) und (Koch und Wörndl 2001).
4.4.3
Transparenz
Neben der benutzerfreundlichen Spezifikation von Zugriffsrechten ist für den Aufbau von Vertrauen
in die Profilverwaltung noch notwendig, dass Besitzer eines Profils schnell und einfach Überblick
92
über die Nutzung des Profils erhalten können. Diese Transparenz über gespeicherte Daten und Nutzung der Daten ist sogar im rechtlichen Rahmen zur Benutzerdatenspeicherung, dem Teledienstdatenschutzgesetz (TDDSG) festgeschrieben (Gentsch 2002).
Zum Überblick über die Profilnutzung gehört Information darüber, welche Information aus welchem
Grund welchen Diensten zur Verfügung gestellt worden ist, und wo momentan Information aus dem
Profil zwischengespeichert wird.
Solche Information kann beim Profilserver erfasst und gespeichert werden. Auch die Bereitstellung
sollte dann am besten auch über die Benutzungsschnittstelle des Profilservers geschehen. Neben der
Möglichkeit, diese Information aktiv einzusehen, sollte weiterhin die Möglichkeit geboten werden,
E-Mail-Benachrichtigungen zu bestimmten Ereignissen zu abonnieren.
93
94
Kapitel 5
Prototypsysteme und erste Erfahrungen
„Beware of bugs in the above code; I have only proved it correct, not tried it.“,
(Knuth 1977)
Die Überlegungen in den vorherigen Kapiteln entstanden aus einer längeren Beschäftigung mit
Community-Plattformen. Dabei wurden auch mehrere Plattformen realisiert oder deren Realisierung begleitet. In diesem Kapitel werden die Erfahrungen, die bei der Anwendung der allgemeinen Konzepte auf reale Plattformen gewonnen worden sind dargestellt und herausgearbeitet, wo
Interoperabilitätspotentiale verwirklicht werden konnten.
Kapitelinhalt
5.1
5.2
5.3
5.4
5.5
5.6
5.7
IDRepository . . . . . . . . . . . . .
Informationsdrehscheibe(n) . . . . .
CommunityItemsTool . . . . . . . .
UnternehmerTUM - TUMmelplatz .
Studiosity . . . . . . . . . . . . . . .
Produktkonfigurations-Community
Austausch von Inhalten . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
96
97
99
99
101
102
102
Die Dienste, die in Abschnitt 3.3 ausgeführt worden sind, wurden im Projekt Cobricks 1 als JavaKomponenten realisiert. Basis des Cobricks-Systems ist ein (Web-)Applikations-Server und ein
komponentenübergreifender Messaging & RPC-Dienst, sowie ein einfacher Komponenten-LookupDienst. Durch die Trennung von Benutzungsschnittstelle und Anwendungskomponenten konnten
verschiedene Benutzungsschnittstellen-Frameworks erprobt werden, u.a. eine Template-basierte Eigenentwicklung. Das dabei entstandene Framework wurde von Anfang an zur Realisierung verschiedenster Prototypplattformen verwendet. An diesen Plattformen wurden die Konzepte weiterentwickelt und verfeinert.
Die verschiedenen Plattformen im Rahmen von Cobricks sind in folgenden Veröffentlichungen dokumentiert: (Koch 2002b), (Koch 2002d), (Koch 2002e), (Koch u. a. 2002a), (Koch u. a. 2002b), (Koch
und Schubert 2002), (Koch u. a. 2001a), (Koch u. a. 2001b), (Koch u. a. 2001c), (Koch und Lacher
2001), (Eisentraut u. a. 2001), (Reichwald u. a. 2001), (Koch u. a. 2000) und (Möslein u. a. 2000).
In diesem Abschnitt werden die wichtigsten Plattformen und die bei ihrem Einsatz abgeleiteten Designentscheidungen für die Realisierung allgemeiner Community-Unterstützungssysteme kurz skizziert.
1
Siehe auch www.cobricks.de.
95
5.1
IDRepository
Die in Kapitel 4 erarbeiteten Konzepte zur Benutzerprofilverwaltung und zur Modellierung von Benutzerprofilen wurden im Rahmen des Cobricks-Projektes umgesetzt und sind mit verschiedenen der
nachfolgend vorgestellten Prototypplattformen in Einsatz.
Web portal
Personalisierung
HTTP
Kategorien
Inhalte
und
Anmerkungen
Kontext
Matchmaking
Benutzerprofil
Mitteilungen
RPC
IDControl
Import/
Export
HTTP
IDRepository
IDCockpit
Abbildung 5.1: Trennung von Profilspeicherung und -nutzung
Konkret wurde zuerst eine Lösung für einen Profilserver nach den in Abschnitt 4.2 diskutierten
Konzepten realisiert. Der sogenannte IDRepository-Server ermöglicht die Verwaltung von mehreren Identitäten und stellt einen Zugriff darauf über verschiedene Schnittstellen (RMI, Corba, WebServices) zur Verfügung.
Für die eigentlichen Community-Plattformen wurde eine Benutzerprofil-Komponente entwickelt,
welche Profile vom IDRepository anfordert, diese Daten lokal zwischenspeichert und Änderungen
wieder an das IDRepository zurückschreibt. Neben diesen Funktionalitäten realisiert die Benutzerprofil-Komponente auch die in Kapitel 3 besprochenen Funktionen zur Definition und Verwaltung
lokaler Rechte.
USERComponent
searchUser(query) -> Set of USER
getUserAttribute(USER, aname) -> Object
setUserAttribute(USER, aname, avalue)
getUserModel(USER) -> USERMODEL
createUser() -> USER
deleteUser(USER)
getPermissions(USER) -> Set of CAPABILITY
checkPermission(USER, CAPABILITY)
addPermission(USER, CAPABILITY)
removePermission(USER, CAPABILITY)
96
5.2 Informationsdrehscheibe(n)
Sowohl IDRepository als auch die User-Komponente realisieren das in Abschnitt 4.3.3 vorgestellte
Profilmodell. An der Schnittstelle der Komponente wird neben einem Zugriff auf die Profildaten vor
allem auch Zugriff auf das Profilmodell selbst angeboten.
Über eine Web-Schnittstelle des IDRepository-Servers (IDCockpit) ist es möglich, explizite Zugriffsrechte zu konfigurieren und Zugriffstickets zu erzeugen. Weiterhin kann über die Web-Schnittstelle
die Historie bisheriger Zugriffe auf das Profil eingesehen werden (Transparenz).
Eine optionale Client-seitige Anwendung (IDControl) kann genutzt werden, um einfach zwischen
Identitäten zu wechseln und weitere Aspekte der Privatsphäre zu kontrollieren.
Abbildung 5.1 zeigt alle implementierten Komponenten im Zusammenhang mit dem IDRepository im
Überblick. Weitere Details zur Implementierung der Komponenten sind in (Koch und Möslein 2003)
sowie in der Implementierungsdokumentation und verschiedenen White Papers zum IDRepository zu
finden.
5.2
Informationsdrehscheibe(n)
Die erste Prototypentwicklung im Rahmen der Community-Aktivitäten war die Entwicklung einer
Web-Plattform für Communities an Universitäten. Die Arbeit an dieser Plattform begann 1997 mit
einem einfachen Web-basierten Informationsdienst zu Lehrveranstaltungen, der über die Jahre sukzessive um Funktionalitäten zur Unterstützung von Kommunikation erweitert wurde. Eingesetzt wird
das Produkt inzwischen an der Fakultät für Informatik und der Fakultät für Wirtschaftswissenschaften der Technischen Universität München, sowie an der Fakultät für Informatik der Universität der
Bundeswehr München.
Im einzelnen bietet diese Plattform folgende Möglichkeiten:
1. Einrichten von Community-Bereichen (Unter-Communities): Jeder angemeldete Benutzer der
Plattform kann einen neuen Community-Bereich einrichten. Einem solchen Bereich können
erstens andere Benutzer der Plattform als Mitglieder zugeordnet werden. Bei offenen Communities kann jeder Benutzer selbst entscheiden, ob er oder sie Mitglied werden möchte, bei
geschlossenen Communities ist eine explizite Einladung durch die Administratoren der Community notwendig. Weitere Attribute der Community bestimmen, ob nur Mitglieder Information in der Community publizieren dürfen und ob die Community in den Plattformlisten
erscheint. Neben strukturierter Information, die der Community zugeordnet werden kann (siehe nächsten Punkt), besitzt eine Community eine frei gestaltbare Homepage (auf der beliebige
Untermengen der Community-Information angezeigt werden können) sowie beliebige weitere
statische Web-Seiten, die von den Community-Mitgliedern editiert werden können.
2. Publizieren von strukturierten Informationen: Die wichtigste Funktionalität neben dem Einrichten von Community-Bereichen ist das Publizieren von Information. Hier stehen verschiedene (frei erweiterbare) Informationstypen zur Verfügung. Momentan sind dies Mitteilungen,
Terminankündigungen, Bookmarks, Projekte, Konversationen und spezielle Ankündigungstypen für den Lehrbetrieb wie z.B. Diplomarbeitsankündigungen. Solche Informations-Items
können von jedem Benutzer erzeugt werden und einer beliebigen Menge von Communities
zugeordnet werden. Diese Zuordnung von Inhalten zu mehr als einer Community stellt eine
wichtige Funktionalität der Plattform dar.
97
3. Kommunikation und Matchmaking: Den (semi-)strukturierten Informationen in den CommunityBereichen können von den Mitgliedern öffentliche Anmerkungen angehängt werden. Damit
wird eine asynchrone Kommunikation zwischen den Mitgliedern möglich. Anwendungsbeispiele dafür ist beispielsweise die Diskussion von Fragen in Lehrveranstaltungen. Neben diesen
asynchronen Konversationen bietet die Plattform kein weitere Unterstützung direkter Kommunikation. Hier wird angenommen, dass die Mitglieder andere Medien (E-Mail, Telefon, ...)
nutzen. Die Plattform vermittelt nur die Kontaktinformation.
Die Plattform setzt die Komponenten Item, Category, Awareness, User, Message ein. Zusätzlich
wurde noch eine Course-Komponente geschaffen, mit der Veranstaltungsdaten und Stundenplaninformation verwaltet werden können. Die Benutzungsschnittstelle ist mit Hilfe der generischen WebKomponente realisiert.
Abbildung 5.2: Drehscheibe Informatik
Der Fokus der Arbeit an den Drehscheibe-Plattformen lag neben der Web-Benutzungsschnittstelle
auf der Realisierung von flexiblen Möglichkeiten zum Einrichten neuer Kategorien sowie der Bereitstellung von Awareness über neue Informationen und über Benutzer. Hierzu wurden verschiedene
Möglichkeiten zum Abonnieren von Ereignismeldungen und von Zusammenfassungen (Newslettern)
von Ereignismeldungen realisiert.
Erfahrungen bei der Nutzung
Eine einzige Installation der Drehscheibe könnte theoretisch alle Anwendungsbereiche an der Universität abdecken. Jedoch ergeben sich bei diesem Vorgehen nach Erfahrungen Widerstände bei Verantwortlichen aus verschiedenen eigenständigen Bereichen. Die Nutzung einer Plattform durch alle
wird als eine Einschränkung der Individualität und Gestaltungsfreiheit gesehen und ist oft organisatorisch nur schwer durchsetzbar. Momentan sind deshalb neben vielen anderen Plattformen auch
zwei getrennte Instanzen der Drehscheibe im Einsatz, sowohl an der Fakultät für Informatik, an der
das System konzipiert wurde und seit vier Jahren entwickelt wird, als auch an der Fakultät für Wirtschaftswissenschaften.
98
5.3 CommunityItemsTool
Das Nutzerverhalten bei den beiden laufenden Instanzen ist sehr unterschiedlich. Während an der Fakultät für Informatik die Plattform hauptsächlich dazu benutzt wird, Mitteilungen von den Lehrenden
an die Studierenden zu übermitteln, wird die Plattform an der Fakultät für Wirtschaftswissenschaften
besonders zur Kommunikation unter den Studierenden genutzt. Es haben sich trotz gleicher Funktionalitäten unterschiedliche Nutzungsschwerpunkte entwickelt. Ein Grund könnte die unterschiedliche
Zusammensetzung der Studierenden und die räumliche Verteilung sein. Während es sich bei der Informatik hauptsächlich um Studierende des Erststudienganges handelt, setzen sich die Studenten der
Wirtschaftsfakultät aus vergleichsweise älteren Personen des managementorientierten-, betriebswirtschaftlichen Aufbaustudiums (MBA) zusammen. Neben dem Altersunterschied unterscheiden sich
die beiden Gruppen auch in Bezug auf die örtliche Verteilung. Während die meisten Lehrveranstaltungen der Informatikstudierenden in einem überschaubaren Bereich des Campus stattfinden, sind
die des MBA räumlich über die unterschiedlichen Standorte der TUM verteilt.
Weitere Informationen zur Drehscheibe-Plattform und den Erfahrungen damit finden sich in (Koch
2002e) und (Koch 2003a)
5.3
CommunityItemsTool
Parallel zu den Informationsdrehscheiben ist eine Community-Plattform zum Wissensmanagement
entstanden, mit der in einer (wissenschaftlichen) Arbeitsgruppe Bookmarks und Literaturreferenzen
ausgetauscht werden können.
Das sogenannte CommunityItemsTool setzt auf dieselbe Basis auf wie die Drehscheiben (insbesondere Item- und Category-Komponente). Beim CommunityItemsTool wurde dabei vor allem mit der
Kategorisierung von Informationen experimentiert. Benutzer können Items in eigene Folder einordnen und auch die Folder anderer Benutzer durchsehen. Damit ist es möglich den Kontext nachzuvollziehen in dem ein Benutzer ein Item sieht. Private Folder wurden dabei wie öffentliche Kategorien
mit dem Datenkonzept der Kategorien realisiert.
Die speziellen Funktionalitäten zum Verwalten und Browsen verschiedener Kategorisierungen wurden inzwischen auch in die Drehscheiben eingebaut - werden aber noch nicht vollständig an der
Benutzungsschnittstelle angeboten.
Weitere Informationen zur CommunityItemsTool-Plattform und den Erfahrungen damit finden sich
in (Koch u. a. 2001b) und (Koch u. a. 2001c).
5.4
UnternehmerTUM - TUMmelplatz
Auf den Drehscheiben wurde auch ein Alumni-Bereich eingerichtet. Hier ist es möglich, Jahrgangslisten einzusehen und, falls gestattet, Kontaktinformationen zu ehemaligen Mitstudenten zu finden.
Weiterhin können Mitteilungen an Ehemalige verbreitet werden und es gibt die Möglichkeit, sich
untereinander auszutauschen.
Die Technischen Universität München hat sich in den letzten Jahren zur Aufgabe gemacht, das Netzwerk der ehemaligen TUM Studenten zu stärken. Dazu wurde in der Universitätsverwaltung ein
Alumni & Career Center initiiert. Die Gruppe pflegt eine offline Alumni-Datenbank, organisiert eine
Reihe von Veranstaltungen und unterstützt die Alumni-Vereinigungen der einzelnen Studiengänge.
Zusätzlich zum Alumni & Career Center gibt es noch eine weitere Institution, die sich mit Alumni
99
beschäftigt, die UnternehmerTUM GmbH. Die UnternehmerTUM ist daran interessiert ein Netzwerk
von Ehemaligen aufzubauen, die Unternehmen gegründet haben oder an einer Gründung interessiert
sind.
Im Rahmen der Community-Aktivitäten wurde zusammen mit UnternehmerTUM im Rahmen des
Projektes „Telekooperation in Beziehungsnetzwerken für informationsbezogene Dienstleistungen“
(TiBiD)2 eine Plattform aufgebaut, die (potentiellen) Entrepreneuren Informationen und Unterstützung beim Finden von Partnern bietet. Ziel ist es, das unternehmerische Denken und Handeln bei den
Studierenden und wissenschaftlichen Mitarbeitern der Universität zu fördern. Auf der CommunityPlattform (die offline Aktivitäten begleitet und unterstützt) haben Studierende, wissenschaftliche
Mitarbeiter, Alumni und Externe die Möglichkeit, miteinander zu kommunizieren und Informationen zum Thema Unternehmertum zu sammeln. Neben dem Fokus auf die TUM wurden in diese
Community-Plattform auch externe Gruppen integriert, die sich mit Entrepreneurship beschäftigen,
z.B. der Münchner Businessplanwettbewerb.
Der Fokus der Unterstützung liegt in der Entrepreneurship-Plattform im Matchmaking. Zur Realisierung wurden hauptsächlich die Komponenten Item, Category, Message benutzt. Bei der Benutzungsschnittstelle wurde nicht auf die generische Web-Komponente des Cobricks-Projektes zurückgegriffen, sondern eine eigene Lösung mit Mitteln eines speziellen Community-Applikations-Servers (dem
Cassiopeia Community-Applikations-Server) realisiert.
Abbildung 5.3: UnternehmerTUM Plattform
Parallel zu den UnternehmerTUM-Aktivitäten wurde mit dem Alumni & Career Center an der Konzeption einer (Kommunikations-)Plattform für alle Alumni der Technischen Universität München
begonnen. Auf dieser Plattform, die unter dem Namen „TUMmelplatz“ geführt wird, sollen vor allem fakultätsübergreifende Funktionen und speziell Kommunikationsfunktionen angeboten werden,
wie sie in den Fakultätsplattformen (z.B. Drehscheibe) noch nicht unterstützt werden. Unter anderem wird in diesem Kontext auch die offline Alumni-Datenbank online gebracht - erstens um das
Matchmaking und das Finden von Co-Alumni zu ermöglichen und zweitens um eine Pflege der Daten
durch die Alumni selbst ermöglichen.
2
Das Projekt TiBiD wird von Bundesministerium für Bildung und Forschung (BMBF) unterstützt (FKZ 01 HG 9991/2).
Siehe auch www.tibid.de.
100
5.5 Studiosity
Weitere Informationen zur TUMmelplatz-Plattform und den Erfahrungen damit finden sich in (Koch
2002e) und (Koch u. a. 2001a).
5.5
Studiosity
Im Projekt „Community Online Services and Mobile Solutions“ (Cosmos) 3 ist unser Ziel eine technische Basis für die Unterstützung von mobilen Communities in den Bereichen Lifestyle und Healthcare zu schaffen und in Prototypcommunities zu testen.
Im Lifestyle-Bereich konzentrieren wir uns dabei auf die Unterstützung kleiner (offener oder geschlossener) Untergruppen. Dabei sollen speziell Community-Mitglieder darin unterstützt werden,
ihre Lifestyle-Aktivitäten zu koordinieren. Dabei fokussieren wir auf Community-zentrierte Positionierung und Präsentation von Positionsinformation sowie Messaging und Inhaltsdienste, die von der
Positionsinformation Nutzen ziehen.
Konkrete Dienste konzentrieren sich auf
Koordination von Aktivitäten und Austausch von Information um Veranstaltungen
Awareness zu Lokalitätsinformation in Unter-Communities
Positions- und Verfügbarkeits-bezogene Kommunikation
Abbildung 5.4: Studiosity Plattform (Lifestyle-Community)
Der Fokus dieser Aktivitäten richtet sich also auf reiche Kontext-Information (Position und Verfügbarkeit) und mobile Endgeräte. Neben der Ermittlung von Positionsinformation spielen dabei vor
allem Regeln zur Definition von Zugriffsrechten und zur Konfiguration der Mitteilungsfunktionalität.
3
Das Projekt Cosmos wird vom Bundesministerium für Bildung und Forschung (BMBF) unterstützt (FKZ 01HW0107 01HW0110). Siehe auch www.cosmos-community.org.
101
Die Lösung wurde mit den üblichen Komponenten (Item, Message, Category, User, Personalization)
realisiert. Für die Lokalitätsinformation wurde die User-Komponente um eine spezielle Unterkomponente für die Ermittlung von Lokalitätsinformation (LocationManager) erweitert.
Weitere Informationen zur Cosmos-Plattform und den Erfahrungen damit finden sich in (Koch 2002b),
(Hillebrand u. a. 2002) und (Koch u. a. 2002a).
5.6
Produktkonfigurations-Community
Im Projekt „Generierung und interaktive Anpassung von personalisierter Produktinformation“ im
Sonderforschungsbereich Marktnahe Produktion individualisierter Produkte (SFB582) 4 arbeiten wir
an einer Community-Plattform zur Unterstützung der Konfiguration von personalisierten Produkten.
Neben der klassischen Kommunikationsunterstützung wird hier vor allem auf die Personalisierung
Wert gelegt.
Konkret sind die folgenden Funktionalitäten vorgesehen:
Produkt-Community: Rund um vorhandene Produkte und Produktkomponenten können Kommentare erfasst und ausgetauscht werden. Über Bewertungen von Komponenten wird eine
Unterstützung von (kollaborativer) Filterung erreicht.
Produkt-Konfigurator: Basierend auf einem Produktmodell und den Informationen, die über
einen Benutzer vorhanden sind, wird über verschiedene Personalisierungsmethoden versucht
Vorschläge für personalisierte Produkte zu erzeugen und den Benutzer bei der Anpassung von
Produktvorschlägen zu unterstützen.
Zusätzlich zu den Standardkomponenten wird in der Konfigurations-Community noch eine spezialisierte Produkt(modell)-Komponente eingesetzt.
Basierend auf der erweiterten Inhaltskomponente wird in diesem Projekt stark an Personalisierungsmethoden gearbeitet. Hierfür wird gerade eine modulare Lösung für die Personalisierungs-Komponente erarbeitet.
Als zweiter Grundstein neben Produktmodell und Personalisierungsmethoden erfolgt in diesem Projekt eine starke Konzentration auf Benutzermodellierung und dem Import von Benutzerprofilen. Hintergrund ist die Idee, dass schon beim ersten Kontakt mit einer neuen Firma durch Import des Benutzerprofils aus anderen Quellen konkrete Empfehlungen generiert werden können.
Weitere Informationen zur SFB582-Plattform und den Erfahrungen damit finden sich in (Koch 2002d),
(Koch u. a. 2002b), (Schubert und Koch 2002), (Leckner u. a. 2003), (Piller u. a. 2003) und (Stegmann
u. a. 2003).
5.7
Austausch von Inhalten
In den letzten Abschnitten wurden verschiedenen Plattformen vorgestellt, an denen verschiedene Anforderungen an Community-Unterstützungsplattformen erarbeitet worden sind und an denen erste
4
Der Sonderforschungsbereich 582 wird von der Deutschen Forschungsgemeinschaft (DFG) gefördert. Siehe auch
www.sfb582.de.
102
5.7 Austausch von Inhalten
Konzepte erprobt worden sind. Ziel der Plattformentwicklungen war dabei neben der Ermöglichung
eines einfachen Aufbaus die Ermöglichung des Austausches von Inhalten zwischen Plattformen.
Unter Inhalten verstehen wir strukturierte Daten und Kommentare, die von den Mitgliedern einer
Community gesammelt werden und auch für andere Communities von Interesse sind, in unserem
Fall also Items. Bei der Realisierung haben wir momentan den Weg gewählt, dass sowohl Quell- als
auch Ziel-Community explizit festlegen müssen, für welche Inhalte ein Austausch stattfindet. Dann
werden neue Inhalte über ein definiertes XML/HTTP-Format an die Ziel-Communities geschickt.
TUMmelplatz
Studenten und Alumni
Externe
Plattformen
IDRepository
Andere
Universitätsplattformen und
Datenbanken
Gruppenplattformen
Fakultätsplattformen
Abbildung 5.5: TUM Plattformen
Eine Möglichkeit, automatisch zu bestimmen, für welche Communities neue Informationen interessant sind, wäre die Anwendung verschiedener Klassifizierungsmethoden des Wissensmanagement.
Gegen einen Einsatz solcher Methoden spricht allerdings der Anspruch von Communities, über den
von den Mitgliedern erstellten Inhalt und dessen Verwendung selbst zu entscheiden. Der Austausch
wird momentan hauptsächlich dann eingesetzt, wenn ein und dieselbe Community auf verschiedenen
Plattformen „zu Hause“ ist. Beispiele dafür sind die Anbieter der Veranstaltungen für den Nebenfach Wirtschaftswissenschaften im Informatik-Diplomstudiengang auf der Plattform der Betriebswirtschaftslehre und die Studierenden der Informatik auf der Plattform der Informatik. Genauso gibt
es auf der BWL-Plattform eine aktive Freizeit-Community, die sich mit der Freizeit-Community auf
der Informatik-Plattform austauscht. Für die im entstehen begriffenen Plattformen ist bisher eher ein
informationstypbezogener Austausch geplant, z.B. ein Austausch von Job-Ankündigungen von den
Fakultätsplattformen zum TUMmelplatz.
103
104
Kapitel 6
Zusammenfassung und Ausblick
„Perhaps the biggest single misconception about virtual communities is,
that they can be created.“,
(source unknown)
6.1
Zusammenfassung
Das Ziel dieser Arbeit war es, ein besseres Verständnis des Anwendungsbereichs Community-Unterstützung zu erarbeiten und eine Software-Architektur zur einfachen Realisierung (interoperabler)
Community-Unterstützungssysteme zu konzipieren.
Dazu habe ich in Kapitel 2 zuerst den Bereich Community-Unterstützung mit Motivation und Triebkräften näher beleuchtet und die Kernpunkte von Community-Unterstützungssystemen herausgearbeitet.
Zur Erleichterung des Aufbaus von Community-Unterstützungssystemen wurde in Kapitel 3 aus den
verschiedenen Anforderungen und Erfahrungen eine Grundarchitektur für solche Systeme konzipiert
und umgesetzt. Kernpunkte der Architektur waren die Definition und Ausarbeitung von Unterstützungskomponenten und die Definition allgemeiner Datenstrukturen für die Unterstützung. Speziell
wurde dabei die Modellierung und Speicherung von Benutzerprofilinformation behandelt (Kapitel 4).
Die iterative Umsetzung und Erprobung der Architektur in verschiedenen Projekten hat die praktische
Verwendbarkeit und Relevanz der Ergebnisse gezeigt.
Zukünftige Aktivitäten sind in der Ausarbeitung und weiteren Verfeinerung der Dienste und Konfigurationsmöglichkeiten, sowie im Ausbau der Unterstützung für die Benutzerprofilverwaltung zu
sehen.
Bei der Verfeinerung der Dienste arbeiten wir momentan hauptsächlich an verschiedenen Werkzeugen
für die Item-Verwaltung und an einer besseren Konfigurierbarkeit des Gesamtsystems. Diese Aktivitäten gehen Hand in Hand mit der Vorbereitung der Bereitstellung von Cobricks als Open-Source
System.
Beim Ausbau der Benutzerprofilverwaltung wird hauptsächlich an einer Integration vorhandener
Standards und Infrastrukturen (wie dem neuen Standard der Liberty Alliance) und an Benutzungsschnittstellen zur einfachen Spezifikation von Zugriffsrechten und zur Bereitstellung von Transparenz
gearbeitet. Letzteres sehen wir als zentralen Punkt für die Nutzbarkeit eines solchen Systems und für
den Aufbau von Vertrauen in ein solches System.
105
In den weiteren Unterkapiteln gehe ich noch auf einige weitere, parallel angelaufene und zukünftige
Aktivitäten im Zusammenhang mit Community-Unterstützung ein.
6.2
Datenmodellierung und Semantic Web
Wie schon in Kapitel 3 und Kapitel 4 angesprochen worden ist, wurde für die Modellierung der Basiskonzepte eine Lösung gewählt, die neben der Modellierung allgemeiner Datenstrukturen auch noch
die Spezifikation von Semantik-Information als Regeln und damit die Ermöglichung von automatischer Deduktion zusätzlicher Information ermöglicht.
Diese Möglichkeiten wurden bisher nur in wenigen Fällen genutzt (z.B. bei der Definition von Zugriffsregeln bei Benutzerprofilen). Die Dienste müssen immer noch in hohem Maße implizites Wissen
über die Semantik der Daten prozedural kodieren. Durch eine weitreichendere deklarative Spezifikation und Nutzung der Semantik der Daten, die vor allem Zusammenhänge und Einschränkungen in
einer Beschreibungslogik definiert (zusätzliches Regelwissen), könnte einiges von dem prozeduralen
Wissen in den Programmen in die Datendefinition selbst verlagert werden.
Dabei kann von vielen Aktivitäten im Rahmen des „Semantic Web“ profitiert werden. Diese Forschungs- und Entwicklungsaktivitäten versuchen das bestehende World-Wide-Web zu verbessern, in
dem nicht mehr nur die Syntax von Dokumenten und anderen Informationsträgern ausgewertet wird,
sondern auch eine maschinen-verarbeitbare Repräsentation von Zusammenhängen und Bedeutung
realisiert wird.
Neben der weiteren Integration von Regeln für die Repräsentation von Zugriffsrechten auf Benutzerprofile oder für die Kodierung von Awareness-Abonnements gibt es hier die Möglichkeit der Nutzung
von Werkzeugen aus dem Semantic-Web-Bereich für die Konfiguration von Community-Plattformen.
Dieser Bereich soll Inhalt weiterer Forschungen in der Zukunft sein.
Durch verstärkte Verlagerung der prozeduralen Komponenten in die Daten selbst wird hier ein Weg
eingeschlagen, den der Forschungsbereich der Künstlichen Intelligenz schon beschritten hat. Als Extrema könnte man hier anstreben alle Funktionalität in den Daten zu kodieren und die CommunityPlattformen nur noch als Inferenz-Maschinen zu gestalten, auf denen die Fakten und Regeln der
Daten aufeinandertreffen. Wie sich aber schon in den Forschungen zur Künstlichen Intelligenz gezeigt hat, gibt es bei diesem Ansatz wesentliche Umsetzungs- und Effizienzprobleme. Aus diesem
Grund wollen wir diesen Ansatz vorläufig nicht weiter verfolgen und halten an einer Kodierung von
Funktionalität in prozedural orientierten Community-Plattformen fest.
6.3
Web-Services und Benutzeragenten
In Kapitel 3 wurde als Technologie für die Realisierung von Komponenten und zum Zugriff auf
die Komponenten die Web-Services Technologie vorgestellt. Eine grundsätzliche Möglichkeit zum
Zugriff auf die Komponenten über die Web-Services-Schnittstelle SOAP ist in den Prototypen bereits
realisiert. Auch können die Komponenten in UDDI-Repositories registriert werden.
Noch nicht gelöst sind Fragen der Authentifizierung an der Web-Services-Schnittstelle und Spezifikation der Dienstsemantik in Web-Services-Verzeichnisdiensten. Letzteres ist insbesonders dann wichtig, wenn Benutzeragenten über Verzeichnisdienste selbst nach passenden Community-Plattformen
106
6.4 Kategorisierung und Unter-Communities
suchen. Hierzu ist zum Beispiel eine Spezifikation der auf der Community behandelten Themen über
globale Kataloge notwendig.
Die Konzeption von Client-seitigen Benutzeragenten, die auf mehrere Community-Plattformen zugreifen, wirft weiterhin verschiedenste Fragen aus dem Bereich der Präsentation von Informationen
und zur Benutzerinteraktion auf, die in zukünftigen Projekten bearbeitet werden sollen.
6.4
Kategorisierung und Unter-Communities
In Kapitel 3 wurde als eine der drei Konzeptbereiche die Kodierung von Domänenwissen vorgestellt. Als Lösung wurde dazu die Definition von hierarchisch strukturierten Kategorien und UnterCommunities (SharedBuddylists) vorgeschlagen.
Die Zuordnung von Benutzern und Informationen zu solchen Kategorien können diese sowohl zur
Auswahl von Empfängern für Informationen und Nachrichten als auch zur Definition von Zugriffsrechten herangezogen werden. Kategorien können sowohl zur Auszeichnung von Community-Wissen
benutzt werden als auch von Community-Mitgliedern dazu verwendet werden, das Interesse an gewissen Inhalten zu erklären.
Das Hauptproblem bei der Kategorisierung in Systemen, die von mehreren Benutzern genutzt werden, ist generell die Definition eines für alle akzeptablen und arbeitsfähigen Kategorienraums. Jeder
Benutzer neigt normalerweise dazu, explizit oder implizit seine eigene Kategorisierung einzuführen.
Neben dem strikten Vorschreiben zentral erstellter Kategorisierungen gibt es hier die Lösungsidee
der Unterstützung einer kollaborativen Erstellung und Erweiterung einer Kategorisierung durch alle
Community-Mitglieder. Weiterhin wird die automatische Abbildung von Kategorisierungen aufeinander untersucht (Projekt Caiman). Damit könnte erreicht werden, dass Community-Mitglieder oder
Untergruppen eigene Kategorisierungen für Inhalte und Interessen führen und Einordnungen eines
Benutzers automatisch in Einordnungen anderer Benutzer oder in eine globale Einordnung umgeschrieben werden.
Neben dem Einsatz in einzelnen Plattformen sind solche Mechanismen insbesondere beim Austausch
von Informationen und Benutzerprofilen zwischen Plattformen und bei der Nutzung mehrerer Plattformen von einem Benutzeragenten aus relevant.
Mechanismen für eine automatische Abbildung werden im Promotionsprojekt Caiman von Martin
Lacher erarbeitet. Erste Ergebnisse im Kontext der Community-Unterstützung sind beispielsweise in
(Lacher u. a. 2000) veröffentlicht.
6.5
Mobile Communities und ubiquitäre
Benutzungsschnittstellen
Die Unterstützung von Community-Kommunikation sollte nicht nur auf Situationen beschränkt sein,
bei denen ein Internet-fähiger Desktop-PC verfügbar ist. Gerade durch die Bereitstellung von mächtigen Möglichkeiten zum Zugriff auf Community-Wissen und auf andere Community-Mitglieder von
mobilen Endgeräten aus eröffnen sich neue Möglichkeiten.
Insbesondere kann durch mobile und ubiquitäre Benutzungsschnittstellen die „Reichweite“ von Community-Plattformen erhöht werden. Durch die Beschränkung auf den Desktop erreicht man nämlich
107
einige Personen überhaupt nicht und schränkt den direkten Zugriff auf Personen auf bestimmte Situationen ein. So ist es der beste Zeitpunkt zum Erfassen von Meinungen zu einem Kinofilm direkt
nachdem man den Film gesehen hat und nicht erst sobald man wieder am Rechner sitzt.
In verschiedenen Projekten wird diesem Thema nachgegangen. Im Projekt Campiello habe ich selbst
an neuen Benutzungsschnittstellen für Tourismus-Communities mitgearbeitet, im Projekt Cosmos
arbeiten wir gerade noch an neuen Erkenntnissen zu Lifestyle- und Healthcare-Communities.
Campiello (Esprit LTR Project 25572) wurde von September 1997 bis August 2000 von Partnern
aus Frankreich, Italien und Griechenland durchgeführt (Koch u. a. 2001d; Agostini u. a. 2000; Grasso
u. a. 2000, 1999; Koch u. a. 1999; Grasso u. a. 1998).
Ausgangspunkt für Campiello waren stark touristisch frequentierte Städte. Dabei wurden die Städte
Chania auf Kreta und Venedig in Italien als Testfeld ausgewählt. Ein Problem in solchen Städten ist,
dass die früheren, jetzigen und zukünftigen Besucher dieser Städte kaum eine Möglichkeit haben,
vom Wissen der anderen zu profitieren, und dass ferner auch zwischen Touristen und Einheimischen
kaum Möglichkeiten zum gegenseitigen Informationsaustausch gegeben sind.
Es handelt sich hierbei um ein besonders ausgeprägtes „Reichweitenproblem“. Ziel von Campiello
war die Verbesserung des aktuellen Zustands durch Bereitstellung eines Informationssystems mit neuartigen Interaktionsmöglichkeiten und verschiedenen Benutzungsschnittstellen. Insbesondere wurde
dabei an der Nutzung von Papier-Formularen und von großen Bildschirmen gearbeitet.
Auch im Rahmen des Cobricks-Projektes wurden bereits erste Arbeiten zur Einbeziehung mobiler
und ubiquitärer Schnittstellen unternommen. Erstens sind hier die mobilen Schnittstellen im Projekt Cosmos (Studiosity) zu nennen (siehe Abschnitt 5.5). Zweitens wurden verschiedene Ideen zur
Nutzung von großen Wandbildschirmen aus Campiello weiterentwickelt (Koch 2003b).
108
1 (Agostini u. a. 2000) AGOSTINI, A. ; G IANNELLA, V. ; G RASSO, A. ; KOCH, M. ; S NOWDON, D. ; VAL PIANI , A.: Reinforcing and Opening Communities Through Innovative Technologies. S. 380–403. In:
G URSTEIN, M. (Hrsg.): Community Informatics, Idea Group Publishing, Hershey, 2000
2 (Agre 2001) AGRE, P.: Networking on the Network. 2001. – Arbeitsbericht - Online verfügbar unter
http://dlis.gseis.ucla.edu/people/pagre/network.html
3 (Armstrong u. a. 1995) A RMSTRONG, R. ; F REITAG, D. ; J OACHIMS, T. ; M ITCHELL, T.: WebWatcher - A
Learning Apprentice for the World Wide Web. In: Proc. AAAI Spring Symposium, März 1995
4 (Borchers 2000) B ORCHERS, J. O.: A pattern approach to interaction design. In: Symposium on Designing
Interactive Systems: processes, practices, methods, and techniques, Aug. 2000
5 (Borghoff u. a. 2001) B ORGHOFF, U. M. ; KOCH, M. ; L ACHER, M. S. ; S CHLICHTER, J. H. ; W EISSER, K.:
Informationsmanagement und Communities - Überblick und Darstellung zweier Projekte der IMC-Gruppe
München. In: Informatik Forschung und Entwicklung 16 (2001), Jul., Nr. 2, S. 103–109
6 (Borghoff und Pareschi 1998a) B ORGHOFF, U. M. ; PARESCHI, R.: Information Technology for Knowledge
Management. Springer Verlag, Berlin, 1998
7 (Borghoff und Pareschi 1998b) B ORGHOFF, U. M. (Hrsg.) ; PARESCHI, R. (Hrsg.): Information Technology
for Knowledge Management. Springer Verlag, Berlin, 1998
8 (Borghoff und Schlichter 2000)
Work. Springer, 2000
B ORGHOFF, U. M. ; S CHLICHTER, J. H.: Computer-Supported Cooperative
9 (Buschmann u. a. 1996) B USCHMANN, F. ; M EUNIER, R. ; ROHNERT, H. ; S OMMERLAD, P. ; S TAL, M.:
Pattern-oriented Software Architecture, Vol. 1: A System of Patterns. John Wiley and Sons, 1996
10 (Carotenuto u. a. 1999) C AROTENUTO, L. ; E TIENNE, W. ; F ONTAINE, M. ; F RIEDMAN, J. ; N EWBERG,
H. ; M ULLER, M. ; S IMPSON, M. ; S LUSHER, J. ; S TEVENSON, K.: CommunitySpace: Towards flexible
support for voluntary knowledge communities. In: Proc. Workshop on Workspace Models for Collaboration,
Apr. 1999
11 (Carroll u. a. 1996) C ARROLL, J. M. ; L AUGHTON, S. ; ROSSON, M. B.: Network Communities. In: Proc.
Conf. on Human Factors in Computing Systems: Conference Companion, 1996, S. 357–358
12 (Cranor u. a. 2000) C RANOR, L. ; L ANGHEINRICH, M. ; M ARCHIORI, M. ; P RESLER -M ARSHALL, M. ;
R EAGLE, J.: The Platform for Privacy Preferences 1.0 (P3P1.0) Specification / W3C. W3C, Dez. 2000. –
Forschungsbericht. W3C Candidate Recommendation
13 (Cranor 1999) C RANOR, L. F.: Agents of Choice: Tools that Facilitate Notice and Choice about Web Site
Data Practices. In: Proc. 21st Intl. Conf. on Privacy and Personal Data Protection, Sep. 1999, S. 19–25
14 (Davenport und Prusak 1998)
School Press, 1998
DAVENPORT, T. H. ; P RUSAK, L.: Working knowledge. Harvard Business
109
15 (Donath u. a. 1999) D ONATH, J. ; K ARAHALIOS, K. ; V IEGAS, F.: Visualizing Conversation. In: Proc.
Hawaii International Conf. on System Sciences (HICSS-32), 1999
16 (Dourish und Bellotti 1992)
D OURISH, P. ; B ELLOTTI, V.: Awareness and Coordination in Shared
Workspaces. In: T URNER, J. (Hrsg.) ; K RAUT, R. E. (Hrsg.): Proc. Intl. Conf. on Computer-Supported
Cooperative Work, ACM Press, New York, NY, Okt. 1992, S. 107–114
17 (Dyson 1997)
York, 1997
DYSON, E.: Release 2.0 - A Design for Living in the Digital Age. Broadway Books, New
18 (Eisentraut u. a. 2001) E ISENTRAUT, R. ; KOCH, M. ; M ÖSLEIN, K.: Building Trust and Reputation in
Communities and Virtual Enterprises. In: S TRONG, D. (Hrsg.) ; S TRAUB, D. (Hrsg.): Proc. 7th Americas
Conf. on Information Systems (AMCIS2001), Association for Information Systems, Aug. 2001, S. 1506–
1509
19 (Erickson 2000) E RICKSON, T.: Towards a Pattern Language for Interaction Design. In: L UFF, P. (Hrsg.) ;
H INDMARSH, J. (Hrsg.) ; H EATH, C. (Hrsg.): Workplace Studies: Recovering Work Practice and Informing
Systems, Cambridge: Cambridge University Press, 2000
20 (Farquhar u. a. 1995) FARQUHAR, A. ; F IKES, R. ; P RATT, W. ; R ICE, J.: Collaborative Ontology Construction for Information Integration / Knowledge Systems Laboratory Department of Computer Science,
Stanford University. Knowledge Systems Laboratory Department of Computer Science, Stanford University,
Aug. 1995. – Forschungsbericht
21 (Fensel 2001) F ENSEL, D.: Ontologies: A Silver Bullet for Knowledge Management and Electronic Commerce. Springer, 2001
22 (Ferraiolo und Kuhn 1992) F ERRAIOLO, D. F. ; K UHN, D. R.: Role Based Access Control. In: Proc. 15th
National Computer Security Conference, 1992
23 (Figallo 1998) F IGALLO, C.: Customer Loyality, and Maintaining a Competitive Edge. Wiley Computer
Publishing, New York, 1998
24 (Fink und Kobsa 2000) F INK, J. ; KOBSA, A.: A Review and Analysis of Commercial User Modeling
Servers for Personalization on the World Wide Web. In: User Modeling and User-Adapted Interaction 10
(2000), S. 209–249
25 (Fink und Kobsa 2002) F INK, J. ; KOBSA, A.: User Modeling for Personalized City Tours. In: Artificial
Intelligence Review 18 (2002), Nr. 1, S. 33–74
26 (Foner 1997) F ONER, L. N.: Yenta - A Multi-Agent, Referral-Based Matchmaking System. In: Proc. 1st
International Conference on Autonomous Agents, Feb. 1997
27 (Franklin und Graesser 1996) F RANKLIN, S. ; G RAESSER, A.: Is It an Agent, or just a Program? - A
Taxonomy for Autonomous Agents. In: Proc. 3rd International Workshop on Agent Theories, Architectures,
and Languages, Springer Verlag, Berlin, 1996
28 (Gamma u. a. 1995)
Wesley, 1995
G AMMA, E. ; H ELM, R. ; J OHNSON, R. ; V LISSIDES, J.: Design Patterns. Addison-
29 (Genesereth 1991) G ENESERETH, M. R.: Knowledge Interchange Format. In: A LLENT, J. (Hrsg.): Proc.
Second Intl. Conf. on the Principles of Knowledge Representation and Reasoning, Morgan Kaufman Publishers, 1991, S. 238–249
30 (Gentsch 2002) G ENTSCH, P.: Virtuelle Kundenpflege: Tools, Techniken und Gesetze. In: iX - Magazin für
Professionelle Informationstechnik (2002), Dez., Nr. 12, S. 77–81
110
31 (Gladwell 2000)
G LADWELL, M.: The Tipping Point. Little, Brown and Company, Boston, 2000
32 (Grasso u. a. 1999) G RASSO, A. ; KOCH, M. ; R ANCATI, A.: Augmenting Recommender Systems by
Embedding Interfaces into Practices. In: H AYNE, S. C. (Hrsg.): Proc. Intl. Conf. on Supporting Group Work
(GROUP99), ACM Press, Nov. 1999, S. 267–275
33 (Grasso u. a. 1998) G RASSO, A. ; KOCH, M. ; S NOWDON, D.: Campiello - New user interface approaches
for community networks. In: S CHULER, D. (Hrsg.): Proc. Workshop Designing Across Borders: The
Community Design of Community Networks, Nov. 1998
34 (Grasso u. a. 2000) G RASSO, A. ; S NOWDON, D. ; KOCH, M.: Extending the Services and the Accessibility
of Community Networks. S. 401–415. In: I SHUDA, T. (Hrsg.) ; I SBISTER, K. (Hrsg.): Digital Cities Technologies, Experiences, and Future Perspectives, Springer Verlag, Berlin, Lecture Notes in Computer
Science 1765, März 2000
35 (Greenspun 1999) G REENSPUN, P.: Scalable Systems for Online Communities. In: G REENSPUN, P. (Hrsg.):
Philip and Alex’s Guide to Web Publishing, Morgan Kaufmann Publishers, 1999
36 (Groh 2002)
G ROH, G.:
Cosmos Plattformkonzept.
2002. –
http://sunschlichter3.informatik.tu-muenchen.de/planung/planung.html
Online verfügbar unter
37 (Gruban 2001) G RUBAN, P.: Von Business zu Communities. S. 11–40. In: G RUBAN, P. (Hrsg.): Business
Communities, Markt und Technik, 2001
38 (Gruber 1992) G RUBER, T. R.: Ontolingua: A Mechanism to support Portable Ontologies / Stanford
University. Stanford University, 1992. – Forschungsbericht
39 (Gruber 1993) G RUBER, T. R.: Toward Principles for the Design of Ontologies Used for Knowledge Sharing
/ Stanford University. Stanford University, August 1993. – Forschungsbericht
40 (Hafner 2001) H AFNER, K.: The Well - A Story of Love, Death and Real Life in the Seminal Online
Community. Carroll and Graf, New York, Apr. 2001
41 (Hagel und Armstrong 1997) H AGEL, J. ; A RMSTRONG, A. G.: net gain - expanding markets through
virtual communities. Harvard Business School Press, 1997
42 (Hauben und Hauben 1997) H AUBEN, M. ; H AUBEN, R.: Netizens: On the History and Impact of Usenet
and the Internet. IEEE Computer Society Press, Los Alamitos CA, 1997
43 (Hensley u. a. 1997) H ENSLEY, P. ; M ETRAL, M. ; S HARDANAND ., U. ; C ONVERSE, D. ; AND, M. M.: Proposal for an Open Profiling Standard / World Wide Web Consortium (W3C). World Wide Web Consortium
(W3C), Jun. 1997. – Forschungsbericht. http://www.w3.org/TR/NOTE-OPS-FrameWork.html
44 (Hesse 2002)
H ESSE, M.: Ontologie(n). In: Informatik Spektrum 16 (2002), Dez., S. 477–480
45 (Hillebrand u. a. 2002) H ILLEBRAND, C. ; G ROH, G. ; KOCH, M.: Mobile Communities - Extending
Online Communities into the Real World. In: H AMPE, J. F. (Hrsg.) ; S CHWABE, G. (Hrsg.): Mobile and
Collaborative Business 2002 Bd. P-16, Sep. 2002, S. 7–18
46 (Hillery 1955) H ILLERY, G. A.: Definitions of Community: Areas of Agreement. In: Rural Sociology 20
(1955), S. 111–123
47 (Hoffmann 2002) H OFFMANN, M.: Vorhersagen und Optionen darstellen - Wie prospektive Mechanismen
Zukunftsawareness fördern. In: H ERCZEG, M. (Hrsg.) ; P RINZ, W. (Hrsg.) ; O BERQUELLE, H. (Hrsg.):
Proc. Mensch und Computer 2002, Teubner, Stuttgart, 2002, S. 245–254
111
48 (ter Hofte 1998) H OFTE, G. H. ter: Working apart together: Foundations for component groupware. Telematica Instituut, Enschede, the Netherlands, 1998 (Telematica Instituut Fundamental Research Series
001)
49 (Hoschka u. a. 2001) H OSCHKA, P. ; P RINZ, W. ; PANKOKE -BABATZ, U.: Der Computer als soziales
Medium. S. 276–285. In: S CHWABE, G. (Hrsg.) ; S TREITZ, N. (Hrsg.) ; U NLAND, R. (Hrsg.): CSCWKompendium, Springer, 2001
50 (Ishida 1998)
I SHIDA, T.: Community Computing. John Wiley and Sons, 1998
51 (Karp u. a. 1999) K ARP, P. D. ; C HAUDHRI, V. K. ; T HOMERE, J.: XOL: An XML-Based Ontology
Exchange Language / Pangea Systems Inc. Pangea Systems Inc., Jul. 1999. – Forschungsbericht
52 (Kautz u. a. 1997) K AUTZ, H. ; S ELMAN, B. ; S HAH, M.: Referral Web: combining social networks and
collaborative filtering. In: Communications of the ACM 40 (1997), März, Nr. 3, S. 63–65
53 (Kay 1995) K AY, J.: The um Toolkit for reusable, long term user models. In: User Modeling and UserAdapted Interaction 4 (1995), Nr. 3, S. 149–196
54 (Köhntopp 2000) KÖHNTOPP, M.: Identitätsmanagement. In: BÄUMLER, H. (Hrsg.) ; B REINLINGER, A.
(Hrsg.) ; S CHRADER, H. (Hrsg.): Datenschutz von A-Z, Luchterhand, Neuwied, 2000
55 (Köhntopp und Berthold 2000) KÖHNTOPP, M. ; B ERTHOLD, O.: Identity Management Based On P3P. In:
F EDERRATH, H. (Hrsg.): Workshop on Design Issues in Anonymity and Unobservability, 2000, S. 127–145
56 (Kifer u. a. 1995) K IFER, M. ; L AUSEN, G. ; W U, J.: Logical Foundations of Object-Oriented and FrameBased Languages. In: Journal of the ACM 42 (1995), Nr. 4, S. 741–843
57 (Knuth 1977) K NUTH, D.: Notes on the van Emde Boas construction of priority deques: An instructive use
of recursion. März 1977. – Memorandum
58 (Kobsa 2001) KOBSA, A.: Generic User Modeling Systems. In: User Modeling and User-Adapted Interaction 11 (2001), S. 49–63
59 (Koch 2002a) KOCH, J. H.: Unterstützung der Formierung und Analyse von virtuellen Communities, Dept.
of Computer Science, Technische Universität München, Dissertation, Jul. 2002. – ISBN 3-631-50288-5
60 (Koch 1998) KOCH, M.: Knowledge Management and Knowledge Agents in Campiello. In: L EES, B.
(Hrsg.) ; M ÜLLER, H. J. (Hrsg.) ; B RANKI, C. (Hrsg.): Proc. Workshop on Intelligent Agents in CSCW,
Fachbereich Informatik, Universität Dortmund, Dortmund, Deutschland, Sep. 1998, S. 44–52
61 (Koch 2000) KOCH, M.: Cobricks - Eine agentenbasierte Infrastruktur für Community-Anwendungen.
In: R EICHWALD, R. (Hrsg.) ; S CHLICHTER, J. (Hrsg.): Proc. Deutsche Computer-Supported Cooperative
Work Konferenz (D-CSCW 2000), Teubner Verlag, Stuttgart, Sep. 2000 (Berichte des German Chapter of
the ACM), S. 265–266
62 (Koch 2001a) KOCH, M.: Community-Support-Systeme. S. 286–296. In: S CHWABE, G. (Hrsg.) ; S TREITZ,
N. (Hrsg.) ; U NLAND, R. (Hrsg.): CSCW-Kompendium, Springer Verlag, Berlin, 2001
63 (Koch 2001b) KOCH, M.: Kollaboratives Filtern. S. 351–357. In: S CHWABE, G. (Hrsg.) ; S TREITZ, N.
(Hrsg.) ; U NLAND, R. (Hrsg.): CSCW-Kompendium, Springer Verlag, Berlin, 2001
64 (Koch 2002b) KOCH, M.: An Architecture for Community Support Platforms - Modularization and Integration. In: L UCZAK, H. (Hrsg.) ; C AKIR, A. E. (Hrsg.) ; C AKIR, G. (Hrsg.): Proc. 6th Intl. Conf. on Work
With Display Units - World Wide Work (WWDU2002), Mai 2002, S. 533–535
112
65 (Koch 2002c) KOCH, M.: Global Identity Management to Boost Personalization. In: S CHUBERT, P. (Hrsg.) ;
L EIMSTOLL, U. (Hrsg.): Proc. Research Symposium on Emerging Electronic Markets, Institute for Business
Economics (IAB), University of Applied Sciences Basel, Sep. 2002, S. 137–147
66 (Koch 2002d) KOCH, M.: Globale Benutzerprofile und kundenindividuelle Produkte. In: B RITZELMAIER,
B. (Hrsg.) ; G EBERL, S. (Hrsg.) ; W EINMANN, S. (Hrsg.): Proc. Liechtensteinisches WirtschaftsinformatikSymposium 2002: Der Mensch im Netz - Ubiquitous Computing, Teubner, Jun. 2002, S. 137–146
67 (Koch 2002e) KOCH, M.: Interoperable Community Platforms and Identity Management in the University
Domain. In: Intl. Journal on Media Management 4 (2002), Jul., Nr. 1, S. 21–30
68 (Koch 2002f) KOCH, M.: Requirements for Community Support Systems - Modularization, Integration
and Ubiquitous User Interfaces. In: Journal of Behaviour and Information Technology 21 (2002), Nr. 5,
S. 327–332
69 (Koch 2003a) KOCH, M.: Community Support in Universities - The Drehscheibe Project. In: Proc. Intl.
Conf. on Communities and Technologies, Sep. 2003, S. 445–464
70 (Koch 2003b) KOCH, M.: Designing Communication and Matchmaking Support for Physical Places of
Exchange. In: Proc. European Conf. on Computer-Supported Cooperative Work, Workshop Moving From
Analysis to Design: Social Networks in the CSCW Context, Sep. 2003
71 (Koch u. a. 2001a) KOCH, M. ; G ALLA, M. ; S CHÖNENBERGER, H.: Interoperable Community-Plattformen
und Identitätsmanagement im Universitätsumfeld. In: E NGELIEN, M. (Hrsg.) ; H OMANN, J. (Hrsg.): Proc.
Workshop Gemeinschaften in Neuen Medien (GeNeMe2001), Josef Eul Verlag, Lohmar, Sep. 2001, S. 215–
236
72 (Koch u. a. 2002a) KOCH, M. ; G ROH, G. ; H ILLEBRAND, C. ; F REMUTH, N.: Mobile Support for Lifestyle
Communities / Lehrstuhl für Allg. und Ind. Betriebswirtschaftslehre (AIB), TU München. Lehrstuhl für
Allg. und Ind. Betriebswirtschaftslehre (AIB), TU München, Nov. 2002. – Forschungsbericht. ISSN 09425098
73 (Koch u. a. 2001b) KOCH, M. ; L ACHER, M. ; W ÖRNDL, W.: The CommunityItemsTool - Interoperable
Community Support in Practice. In: Proc. WETICE-2001 - Workshop on Web-based Infrastructures and
Coordination Architectures for Collaborative Entreprises, Jun. 2001
74 (Koch u. a. 2001c) KOCH, M. ; L ACHER, M. ; W ÖRNDL, W.: Das CommunityItemsTool - Interoperable
Unterstützung von Interessens-Communities in der Praxis. In: W EINMANN, B. B. S. G. S. (Hrsg.): Proc. 3.
Liechtensteinisches Wirtschaftsinformatik-Symposium, Teubner, Stuttgart, Mai 2001, S. 147–157
75 (Koch und Lacher 2000) KOCH, M. ; L ACHER, M. S.: Integrating Community Services - A Common Infrastructure Proposal. In: Proc. Knowledge-Based Intelligent Engineering Systems and Allied Technologies,
Aug. 2000, S. 56–59
76 (Koch und Lacher 2001) KOCH, M. ; L ACHER, M. S.: The Comovie Movie Recommender - An Interoperable Community Support Application. In: Proc. Human-Computer Interaction International, Aug. 2001
77 (Koch und Möslein 2003) KOCH, M. ; M ÖSLEIN, K.: User Representation in E-Commerce and Collaboration Applications. In: Proc. 16th Bled eCommerce Conference, Jun. 2003, S. 649–661
78 (Koch u. a. 2002b) KOCH, M. ; M ÖSLEIN, K. ; S CHUBERT, P.: Communities and Personalization for
Individual Products. In: Proc. British Academy of Management Annual Conference (BAM2002), Sep. 2002
79 (Koch u. a. 2000)
KOCH, M. ; M ÖSLEIN, K. ; WAGNER, M.: Vertrauen und Reputation in OnlineAnwendungen und virtuellen Gemeinschaften. In: E NGELIEN, M. (Hrsg.) ; N EUMANN, D. (Hrsg.): Virtuelle
Organisation und Neue Medien - Workshop Gemeinschaften in Neuen Medien (GeNeMe2000), Eul Verlag,
Lohmar, Okt. 2000, S. 69–84
113
80 (Koch u. a. 1999) KOCH, M. ; R ANCATI, A. ; G RASSO, A. ; S NOWDON, D.: Paper User-Interfaces for
Local Community Support. In: B ULLINGER, H. (Hrsg.) ; Z IEGLER, J. (Hrsg.): Proc. Human-Computer
Interaction International 99 Vol.2, Lawrence Erlbaum Publishers, London, Aug. 1999, S. 417–421
81 (Koch und Schlichter 2001) KOCH, M. ; S CHLICHTER, J.: Ubiquitous Computing. S. 507–517. In:
S CHWABE, G. (Hrsg.) ; S TREITZ, N. (Hrsg.) ; U NLAND, R. (Hrsg.): CSCW-Kompendium, Springer-Verlag,
Berlin, 2001
82 (Koch und Schubert 2002) KOCH, M. ; S CHUBERT, P.: Personalization and Community Communication
for Customer Support. In: L UCZAK, H. (Hrsg.) ; C AKIR, A. E. (Hrsg.) ; C AKIR, G. (Hrsg.): Proc. 6th Intl.
Conf. on Work With Display Units - World Wide Work (WWDU2002), Mai 2002, S. 530–532
83 (Koch u. a. 2001d) KOCH, M. ; S NOWDON, D. ; G RASSO, A.: Neue Benutzungsschnittstellen für die
Unterstützung von Arbeits- und Freizeit-Communities. In: Zeitschrift für Arbeitswissenschaft 55 (2001),
Jun., Nr. 2, S. 124–129
84 (Koch und Teege 1999) KOCH, M. ; T EEGE, G.: Support for Tailoring CSCW Systems: Adaptation by
Composition. In: Proc. 7th Euromicro Workshop on Parallel and Distributed Processing, IEEE Press, Feb.
1999, S. 146–152
85 (Koch und Wörndl 2001) KOCH, M. ; W ÖRNDL, W.: Community Support and Identity Management. In:
Proc. Europ. Conference on Computer-Supported Cooperative Work (ECSCW2001), Sep. 2001, S. 319–338
86 (Krasner und Pope 1988) K RASNER, G. E. ; P OPE, S. T.: A cookbook for using the model-view controller
user interface paradigm in Smalltalk-80. In: Journal of Object-Oriented Programming 1 (1988), Aug.,
Nr. 3, S. 26–49
87 (Krempl 1998) K REMPL, S.: Wir haben den Kommerz schon immer begrüßt. In: Telepolis - Magazin der
Netzkultur (1998)
88 (Lacher und Koch 2000) L ACHER, M. S. ; KOCH, M.: An Agent-based Knowledge Management Framework. In: Proc. AAAI Spring Symposium 2000, März 2000, S. 145–147
89 (Lacher u. a. 2001) L ACHER, M. S. ; KOCH, M. ; W ÖRNDL, W.: A Framework for Personalizable Community Web Portals. In: Proc. Human-Computer Interaction International, Aug 2001
90 (Lacher u. a. 2000) L ACHER, M. S. ; W ÖRNDL, W. ; KOCH, M. ; B REDE, H.: Ontology Mapping in
Community Support Systems / Dept. of Computer Science, Technische Universität München, Munich.
Dept. of Computer Science, Technische Universität München, Munich, Mai 2000. – Forschungsbericht
91 (Lechner u. a. 2001) L ECHNER, U. ; H UMMEL, J. ; K NYPHAUSEN, C. zu Inn-und: Peer-to-Peer Architekturen für Kollaboration in Communities. In: E NGELIEN, M. (Hrsg.) ; H OMANN, J. (Hrsg.): Proc. Workshop
Gemeinschaften in Neuen Medien (GeNeMe2001), Josef Eul Verlag, Lohmar, Sep. 2001, S. 237–254
92 (Lechner u. a. 1998) L ECHNER, U. ; S CHMID, B. ; S CHUBERT, P. ; Z IMMERMANN, H.: Die Bedeutung
von Virtual Business Communities für das Management von neuen Geschäftsmedien. In: E NGELIEN, M.
(Hrsg.) ; B ENDER, K. (Hrsg.): Proc. Gemeinschaften in Neuen Medien (GeNeMe98), Josef Eul Verlag,
Lohmar, 1998, S. 203–219
93 (Leckner u. a. 2003) L ECKNER, T. ; KOCH, M. ; L ACHER, M. ; S TEGMANN, R.: Personalization meets
Mass Customization - Support for the Configuration and Design of Individualized Products. In: Proc. Intl.
Conf. on Enterprise Information Systems (ICEIS2003), Apr. 2003
94 (Leimeister u. a. 2002)
L EIMEISTER, J. M. ; A RNOLD, Y. ; K RCMAR, H.: Developing CommunityPlatforms for Cancer Patients - The Cosmos-Project. In: Proc. (Virtual) Community Informatics Workshop
held in conjunction with the International Conf. on Information Systems (ICIS) 2002, Dez. 2002
114
95 (Leimeister u. a. 2003) L EIMEISTER, J. M. ; DAUM, M. ; K RCMAR, H.: Towards M-Communities: The
Case of Cosmos Healthcare. In: Proc. Hawaii International Conference on System Sciences (HICSS-36),
2003
96 (Lenat 1995) L ENAT, D.: Cyc: A Large-Scale Investment in Knowledge Infrastructure. In: Communications
of the ACM 38 (1995), Nov., Nr. 11
97 (Lenat und Guha 1990) L ENAT, D. B. ; G UHA, R. V.: Building large knowledge-based systems - Representation and inference in the Cyc project. Addison-Wesley, Reading, MA, 1990
98 (Licklider und Taylor 1968) L ICKLIDER, J. C. R. ; TAYLOR, R.: The Computer as a Communication Device.
In: Science and Technology (1968), Apr.
99 (Linden u. a. 2003) L INDEN, G. ; S MITH, B. ; YORK, J.: Amazon.com Recommendations - Item-to-Item
Collaborative Filtering. In: IEEE Internet Computing 7 (2003), Jan., Nr. 1, S. 76–80
100 (Mantel und Schlissler 2002) M ANTEL, S. ; S CHLISSLER, M.: Application Integration. In: Wirtschaftsinformatik 44 (2002), S. 171–174
101 (Marchiori und Saarela 1998) M ARCHIORI, M. ; S AARELA, J.: Query + Metadat + Logic = Metalog. Dez.
1998. – Proc. Conf. on Query Languages (QL’98)
102 (Meersman 1999) M EERSMAN, R. A.: The use of lexicons and other computer-linguistic tools in semantics,
design and cooperation of data. In: Z HANG, Y. (Hrsg.): Proc. CODAS Conference, Springer Verlag, Berlin,
1999
103 (Michalski 1997)
M ICHALSKI, J.: Buddy Lists. In: Release 1.0 (1997), Jul., Nr. 6
104 (de Michelis 2001) M ICHELIS, G. de ; C REMERS, A. B. (Hrsg.): Services and Communities in the Information Society. Okt. 2001. – Vortrag auf 4. Dienstleistungstagung des BMBF, 16.10.2002, Bonn
105 (Möslein u. a. 2000) M ÖSLEIN, K. ; KOCH, M. ; E ISENTRAUT, R.: Telekooperation in Beziehungsnetzwerken für informationsbezogene Dienstleistungen. In: R EICHWALD, R. (Hrsg.) ; S CHLICHTER, J. (Hrsg.):
Proc. Deutsche Computer-Supported Cooperative Work Konferenz (D-CSCW 2000), Teubner Verlag, Stuttgart, Sep. 2000 (Berichte des German Chapter of the ACM), S. 275–276
106 (Mulligan und Schwartz 2000) M ULLIGAN, D. ; S CHWARTZ, A.: Your place or mine? In: Computers,
freedom and privacy: challenging the assumptions, Apr. 2000, S. 81–84
107 (Mynatt u. a. 1997) M YNATT, E. D. ; A DLER, A. ; I TO, M. ; ODAY, V. L.: Design for Network Communities. In: Proc. ACM SIGCHI Conf. on Human Factors in Compting Systems, 1997
108 (Nichols 1997) N ICHOLS, D. M.: Implicit Rating and Filtering. In: Proc. Fifth DELOS Workshop on
Filtering and Collaborative Filtering, Nov. 1997
109 (Overhage 2002) OVERHAGE, S.: Die Spezifikation - kritischer Erfolgsfaktor der Komponentenorientierung. In: T UROWSKI, K. (Hrsg.): Proc. Workshop Komponentenorientierte betriebliche Anwendungssysteme, 2002, S. 1–17
110 (Parks und Floyd 1996) PARKS, M. R. ; F LOYD, K.: Making Friends in Cyberspace. In: Journal on
Computer-Mediated Communication (JCMC) 1 (1996), Nr. 4
111 (Piller u. a. 2003) P ILLER, F. ; KOCH, M. ; M ÖSLEIN, K. ; S CHUBERT, P.: Managing High Variety - How
to Overcome the Mass Confusion Phenomenon of Customer Co-Design. In: Proc. 3rd Annual Conf. of the
European Academy of Management (EURAM2003), Apr. 2003
115
112 (Reichwald u. a. 2001) R EICHWALD, R. ; M ÖSLEIN, K. M. ; KOCH, M. ; P ILLER, F. T.: From Tele-Work
to Tele-Communities: The Past, Present and Future of Telecooperation. In: D ERBEL, F. (Hrsg.) ; D ERBEL,
N. (Hrsg.) ; K ANOUN, O. (Hrsg.) ; T OURKI, R. (Hrsg.) ; T RÄNKLER, H. (Hrsg.): Proc. Conf. on Smart
Systems and Devices, SOGIC, Sfax, März 2001, S. 27–33
113 (Resnick u. a. 1994) R ESNICK, P. ; I ACOVOU, N. ; S UCHAK, M. ; B ERGSTROM, P. ; R IEDL, J.: GroupLens
- An Open Architecture for Collaborative Filtering of Netnews. In: F URUTA, R. (Hrsg.) ; N EUWIRTH,
C. M. (Hrsg.): Proc. Intl. Conf. on Computer-Supported Cooperative Work, ACM Press, New York, NY,
Okt. 1994, S. 175–186
114 (Rheingold 1993)
R HEINGOLD, H.: The Virtual Community. Addison-Wesley, 1993
115 (Rucker und Polanco 1997) RUCKER, J. ; P OLANCO, M. J.: Siteseer: personalized navigation for the Web.
In: Communications of the ACM 40 (1997), März, Nr. 3, S. 73–76
116 (Sarwar u. a. 2000) S ARWAR, B. ; K ARYPIS, G. ; KONSTAN, J. ; R IEDL, J.: Analysis of Recommendation
Algorithms for E-Commerce. In: Proc. ACM Conference on Electronic Commerce, 2000, S. 158–167
117 (Sarwar u. a. 1998) S ARWAR, B. M. ; KONSTAN, J. A. ; B ORCHERS, A. ; H ERLOCKER, J. ; M ILLER, B. ;
R IEDL, J.: Using Filtering Agents to Improve Prediction Quality in the GroupLens Research Collaborative
Filteri. In: Proc. Conf. on Computer-Supported Cooperative Work, ACM Press, Nov. 1998, S. 345–354
118 (Schlichter u. a. 1998) S CHLICHTER, J. ; KOCH, M. ; X U, C.: Awareness - The Common Link Between
Groupware and Community Support Systems. In: I SHIDA, T. (Hrsg.): Community Computing and Support
Systems, Springer Verlag, Jun. 1998 (Lecture Notes in Computer Science 1519), S. 77–93
119 (Schmidt 2000) S CHMIDT, M. P.: Knowledge Communities - Mit virtuellen Wissensmärkten Wissen in
Unternehmen effektiv nutzen. München: Addison-Wesley, 2000
120 (Schubert 2000) S CHUBERT, P.: Virtuelle Transaktionsgemeinschaften im Electronic Commerce. Josef Eul
Verlag, Lohmar, 2000
121 (Schubert und Koch 2002) S CHUBERT, P. ; KOCH, M.: The Power of Personalization: Customer Collaboration and Virtual Communities. In: Proc. Americas Conf. on Information Systems (AMCIS2002), Aug.
2002
122 (Schubert und Koch 2003) S CHUBERT, P. ; KOCH, M.: Collaboration Platforms for Virtual Student Communities. In: Proc. Hawaii International Conference on System Science (HICSS-36), Jan. 2003
123 (Schuemmer u. a. 2002) S CHUEMMER, T. ; F ERNANDEZ, A. ; H OLMER, T.: The Caloge of GroupwarePatterns. Sep. 2002. – Online catalog at http://www.groupware-patterns.org/
124 (Schuler 1995) S CHULER, D.: Creating Public Space in Cyberspace - The Rise of the new Community
Networks. In: Internet World (1995), Dez.
125 (Schuler 1996)
1996
S CHULER, D.: New Community Networks - Wired for Change. Addison-Wesley, New York,
126 (Searle 1969) S EARLE, J.: Speech Acts: An Essay in the Philosophy of Language. Cambridge University
Press, New York, 1969
127 (Searle 1979) S EARLE, J.: Expression and Meaning: Studies in the Theory of Speech Acts. Cambridge
University Press, New York, 1979
128 (Sikkel 1997) S IKKEL, K.: A Group-based Authorization Model for Cooperative Systems. In: H UGHES,
J. A. (Hrsg.) ; P RINZ, W. (Hrsg.) ; RODDEN, T. (Hrsg.) ; S CHMIDT, K. (Hrsg.): Proc. Europ. Conf. on
Computer-Supported Cooperative Work, Kluwer Academic Publishers, Dordrecht, Sep. 1997, S. 345–360
116
129 (Sikkel und Stiemerling 1998) S IKKEL, K. ; S TIEMERLING, O.: User-Oriented Authorization in Collaborative Environments. In: Proc. Intl. Conf. on the Design of Cooperative Systems, Mai 1998
130 (Singh 1994) S INGH, M. P. ; C ARBONELL, J. G. (Hrsg.) ; S IEKMANN, J. (Hrsg.): Lecture Notes in Artificial
Intelligence. Bd. 799: Multiagent Systems. Springer Verlag, Berlin, 1994
131 (Singh 1998) S INGH, M. P.: Agent Communication Languages: Rethinking the Principles. In: IEEE
Computer 31 (1998), Dez., Nr. 12, S. 40–47
132 (Sparling 2000) S PARLING, M.: Lessons Learned Through Six Years of Component-Based Development.
In: Communications of the ACM 43 (2000), Okt., Nr. 10, S. 47–53
133 (Staab 2002) S TAAB, S.: Wissensmanagement mit Ontologien und Metadaten. In: Informatik Spektrum 20
(2002), Jun., Nr. 3, S. 294–209
134 (Staab u. a. 2000) S TAAB, S. ; A NGELE, J. ; D ECKER, S. ; E RDMANN, M. ; H OTHO, A. ; M ÄDCHE, A. ;
S CHNURR, H. ; S TUDER, R. ; S URE, Y.: Semantic Community Web Portals. In: Computer Networks (2000),
Mai. – Special Issue: WWW9 - Proc. of the 9th Intl. WWW Conference, Amsterdam, The Netherlands
135 (Stegmann u. a. 2003) S TEGMANN, R. ; KOCH, M. ; L ACHER, M. ; L ECKNER, T. ; R ENNEBERG, V.:
Generating Personalized Recommendations in a Model-Based Product Configurator System. In: Proc. Intl.
Joint Conf. On Artificial Intelligence (IJCAI) - Workshop on Configuration, Aug. 2003
136 (Steiner u. a. 1988) S TEINER, J. G. ; N EUMAN, B. C. ; S CHILLER, J.: Kerberos: An Authentication Service
for Open Network Systems. In: Proc. of the Winter 1988 Usenix Conf., Feb. 1988
137 (Stiemerling 2000)
tation, 2000
S TIEMERLING, O.: Component-Based Tailorability, Universitaet Bonn, Bonn, Disser-
138 (Stoll 1995) S TOLL, C.: Silicon Snake Oil - Second Thoughts on the Information Highway. Doubleday,
New York, 1995
139 (Szyperski 1998)
S ZYPERSKI, C.: Component Software. Addison Wesley Longman Ltd., 1998
140 (Teege 1998) T EEGE, G.: Individuelle Groupware - Gestaltung durch Endbenutzer. Deutscher Universitäts
Verlag, Wiesbaden, 1998. – zugl.: Habilitationsschrift, Technische Universität München
141 (Tönnies 1991) T ÖNNIES, F.: Gemeinschaft und Gesellschaft, Grundbegriffe der reinen Soziologie. Wissenschaftliche Buchgesellschaft, Darmstadt, 1991. – Orginalwerk entstand 1887
142 (Turkle 1995)
York, 1995
T URKLE, S.: Life on the Screen: Identity in the Age of the Internet. Simon and Schuster, New
143 (Twidale und Nichols 1996) T WIDALE, M. B. ; N ICHOLS, D. M.: Interfaces to support collaboration in
information retrieval. In: J OHNSON, C. (Hrsg.) ; D UNLOP, M. (Hrsg.): Proc. BCS IR and HCI Workshop,
1996, S. 25–28
144 (Twidale u. a. 1997) T WIDALE, M. B. ; N ICHOLS, D. M. ; PAICE, C. D.: Browsing is a Collaborative
Process. In: Information Processing and Management 33 (1997), Nr. 6, S. 761–783
145 (van Vliet und Burgers 1987) V LIET, W. van ; B URGERS, J.: Communities in transition: From the industrial to the postindustrial era. In: A LTMAN, I. (Hrsg.) ; WANDERSMAN, A. (Hrsg.): Neighborhood and
Community Environments, Plenum Press, New York, 1987
146 (Weiß 2001) W EISS, G.: Agentenorientiertes Software Engineering. In: Informatik Spektrum 24 (2001),
Nr. 2, S. 98–101
117
147 (Wellman und Gulia 1999) W ELLMAN, B. ; G ULIA, M.: Net Surfers dont ride alone: Virtual Communities
as Communities. In: KOLLOCK, P. (Hrsg.) ; S MITH, M. (Hrsg.): Communities and Cyberspace, Routledge,
1999
148 (Wenger 1998) W ENGER, E.: Communities of Practice: Learning, Meaning and Identity. Cambridge
University Press, 1998
149 (Wood und Smith 2001) W OOD, A. F. ; S MITH, M. J.: Online Communication - Linking Technology, Identity
and Culture. Lawrence Erlbaum, Mahwah, London, 2001
150 (Wörndl 2001) W ÖRNDL, W.: Privatheit und Zugriffskontrolle bei Agenten-basierter Verwaltung von Benutzerprofilen / Institut für Informatik, Technische Universität München. Institut für Informatik, Technische
Universität München, Nov. 2001. – Forschungsbericht
151 (Wörndl 2002) W ÖRNDL, W.: Using P3P to Negotiate Access Rights To User Profiles. In: Proc. Workshop
on the Future of P3P, Nov. 2002
152 (Wörndl und Koch 2002) W ÖRNDL, W. ; KOCH, M.: Privatheit bei Verwaltung von Benutzerprofilen. In:
Proc. Mensch und Computer 2002, Teubner, Sep. 2002, S. 395–396
153 (Wörndl u. a. 2003) W ÖRNDL, W. ; Z EHENTNER, J. ; KOCH, M.: Vergleich des Umgangs mit Privatheit
bei Passport und Liberty Alliance. In: Proc. GI Jahrestagung Informatik 2003 - Teiltagung Sicherheit, Sep.
2003
154 (Zimmer 2000) Z IMMER, D. E.: Die Bibliothek der Zukunft - Text und Schrift in den Zeiten des Internet.
Hoffmann und Campe, 2000
118
Index
Abfragesprachen, 59, 66
Abonnement, 59, 62, 98, 106
ABox, 43
Adaptierung, 6
Agenten, 6, 35, 38
Benutzeragent, siehe Benutzeragent
Definition, 38
Merkmale, 38
Agentenkommunikation, 39
FIPA-ACL, 41
Alumni, 76, 99
amazon.com, 26, 73
Angewandte Informatik, 5
Anmerkung, 32
Anonymität, 17, 22
Anpassbarkeit, 6, 8, 68
Anwendungsintegration, 6
Arbeitsgruppen, 5
Architektur
Definition, 5
Arpanet, 24
ArsDigita Community System, 28
Aussagenlogik, 42
Authentifizierung, 58, 92
Autorisierung, 92
Awareness, 17, 23, 25, 29–32, 51, 57, 61, 62,
70, 74, 92
Definition, 62
Bekanntheit, 15
Benutzeragent, 39, 106
Benutzerbeiträge, 45
Benutzerdaten, siehe Benutzerprofil
Benutzerlisten, 59
Benutzerprofil, 10, 23, 25, 51, 57, 69, 96
Austausch, 76
Awareness, 74
Bewertungen, siehe Bewertungen
Beziehungen, 87
Datengewinnung, 70
Definition, 70
Interessen, 87
Mehrfachnutzung, 74
Metamodell, 83
Modell, 84
Modellierung, 77
Speicherung, 73
Standards, 78
Vertrauen, 73
Benutzerprofilverwaltung, 57, 69, 96
Benutzungsschnittstelle, 30, 64
Beschreibungslogik, 42, 44
Bewertungen, 62, 71, 72, 88
BizTalk, 45
Bookmarks, 71, 99
BSCW, 89
Buddylist, 24, 25, 52, 87, 89
Bulletin-Board, 24, siehe Schwarzes Brett, 25
Caiman, 8, 59, 107
Campiello, 108
Capabilities, 57
Cassiopeia Community Application Server, 28
Chat, 24
Clickstream, 71
Client/Server, 3, 37
Cobricks, 8, 54, 70, 95
Community
Bildung, 29
Definition, 13
Grenzen, 16
Plattform
Definition, 3
Rollen, 17
System
Definition, 3
Untergruppen, 52
Community of Interest, 20
Community of Practice, 16, 20, 27
Community of Purpose, 20
119
Index
Community-Netzwerk, 24
De Digitale Stad Amsterdam, 24
Milano Civic Network, 24
Seattle Community Network, 24
Community-Unterstützung, 23
Anforderungen, 29
Buddylist, 25
Chat, 25
Framework, 28
Geschichte, 23
Matchmaking, 25
News, 25
Online-Shops, 26
Portale, 26
Recommender, 25
Software, 23
CommunityItemsTool, 11, 59, 99
Communityware, 27
Connectoren, 18
Context, siehe Kontext
Corba, 37, 96
IDL, 37
Cosmos, iv, 11, 47, 48, 90, 101, 108
CPEX, 78
CRM, 78
CSCW, siehe Rechnergestützte Gruppenarbeit
CycL, 44
DAML+OIL, 66
Datenbankmodell, 44
Entity-Relationship-Diagramm, siehe EntityRelationship-Diagramm
Datenmodellierung, 40
Datenschutz, 71, 93
Datenschutzerklärung, siehe Privacy Policy
DCOM, 37
Deduktion, 44, 66, 106
Design Pattern, siehe Entwurfsmuster
DigitalMe, 75
DNS, 77
Domäne, 50
Repräsentation, 40
Drehscheibe, siehe Informationsdrehscheibe
E-Commerce, siehe Electronic Commerce
E-Mail, 2
ebXML, 6, 45
120
EJB, 37
Electronic Commerce, 22, 26, 76, 78
Emoticons, 22
Entity-Relationship-Diagramm, 44
Entrepreneurship, 100
Entwurfsmuster, 6, 35
Beispiel, 36
für Groupware, 36
Model/View/Controler, 64
Erreichbarkeitsmanagement, 31, 90
Eureka, 27
F-Logik, siehe Frame-Logik
Featurekombination, 68
FidoNet, 24
Filtern, 46, 62
inhaltsbasiert, 72
kollaborativ, 63, 71, 72, 88
automatisch, 72
interaktiv, 72
Filterverfahren, 25
Fragebogen, 70
Frame-Logik, 44, 66
Frames, 41, 44
FTP, 24
Gemeinschaft, 2
als soziales Netzwerk, 15
Identität, 16
in der Soziologie, 14
Kategorisierungen, 19
technische Sicht, 19
und Gesellschaft, 14
Gemeinschaftliches Handeln, 16
Gesellschaft, 14
Gewahrsein, siehe Awareness
Google Groups, 25
GroupLens, 71
Groupware, 27, 28, 36
Gruppenbewußtsein, siehe Awareness
Herumlungern, siehe Lurking
Human-Computer-Interaction, 36
ICQ, 25
IDCockpit, 97
IDControl, 97
Identität, 15, 16, 22, 74
Index
Identitätsmanagement, 69, 74, 75
IDRepository, 56, 70, 76, 92, 96
Infomediaries, 74
Information
semi-strukturiert, 46
warm, 5, 49
Informationsdrehscheibe, 11, 97
Instant Messenger, 25
Interaktion, 15
Interaktionsdesign, 36
Internet Movie Database, 88
Interoperabilität, 4, 30, 102
Intranet, 75
IRC, 25
Item, 46
Anhänge, 48
Kommentare, 49
Java Server Pages, 65
Jotter, 74
Logik
Aussagenlogik, siehe Aussagenlogik
Beschreibungslogik, siehe Beschreibungslogik
Kalkül, 42
Prädikatenlogik, siehe Prädikatenlogik
Lurker, siehe Lurking
Lurking, 14
Mailinglisten, 24
Matchmaking, 3, 25, 62
Mavens, 17
Meta-Informationen, 46
Metalog, 66
Microsoft Passport, 75, 78
Microsoft Wallet, 78
Mitteilungen, 45, 50, 60
Model/View/Controler, 64
Modularisierung, 5, 34
MOO, 24
MovieCritic, 26
MovieLens, 26
MUD, 24
Mundpropaganda, 72
Kameradschaft, 14
Kategorien, 43, 50, 59
Kategorisierung, 50
Kerberos, 75, 92
KIF, 44
Klassifizierungen, 43
Kommentar, 45, 88
Kommunikationskanal, 2, 31, 60
E-Mail, 61
Instant Messaging, 61
lokale Mailbox, 61
Präferenz, 60
SMS, 61
Komponenten, 5, 34, 37
Definition, 34
Konfiguration, 64
Benutzungsschnittstelle, 64
Kontext, 53, 60
Koordination, 27
Korrelation, 72
Kultur, 14
Künstliche Intelligenz, 6, 78, 106
OASIS, 6
Objekte
verteilt, 35
Online-Community, siehe Virtuelle Community, 45
Online-Shop, 4, 26, 71, 73
Ontobroker, 44
Ontolingua, 44
Ontologie, 41, 43, 53, 64
Beschreibung, 44
OPS - Open Profiling Standard, 80
OQL, 66
Ortsinformation, 47, 48, 101
LDAP, 75
Liberty Alliance, 75, 77, 105
Literaturreferenzen, 99
Live-Id.org, 75
P3P, 74, 81, 91
Pace, 8
Partizipativer Produktkatalog, 26
Passport, siehe Microsoft Passport
Nachrichten, siehe Mitteilungen
Newsgroups, 24
Newsletter, 98
Notifikation, 29, 61, 76
121
Index
Pattern, siehe Entwurfsmuster
Persona, 74
Personalisierung, 7, 10, 26, 57, 62, 63, 70, 72,
102
Kaltstart-Problem, 73
phpGroupware, 28
PIM, 76
Portale, 26, 27
Privacy Policy, 71, 73, 91, 92
Privatheit, 60, 69, 88
Privatsphäre, 30
Produktkonfiguration, 102
Prolog, 41
Prädikatenlogik, 41, 42, 44
Pseudonyme, 17, 69, 77
Pull-Informationslieferung, 59, 62
Push-Informationslieferung, 59, 62
Query-Sprache, siehe Abfragesprachen
Rating, siehe Bewertungen
Rechnergestützte Gruppenarbeit, 5, 62
Rechteverwaltung, 57
Recommender-Systeme, 25
Referral Web, 26
Regeln, 41, 42, 44, 45, 87–89
Reichweite, 23, 107
Reputation, 17
RFC
1766 Tags for the Identification of Languages, 47
2045 MIME Part One: Format of Internet
Message Bodies, 80
2046 MIME Part Two: Media Types, 48
2048 MIME Part Four: Registration Procedures, 48
2396 Uniform Resource Identifiers (URI),
48, 88
2425 A MIME Content-Type for Directory Information, 79
2426 vCard MIME Directory Profile, 79
RMI, 96
RosettaNet, 6
RPC, 37, 40, 95
Salesmen, 17
Schnittstellen, 5, 34
Schwarzes Brett, 3, 24, 25
122
ScreenName, 75
Semantic Web, 45, 106
Semantische Netze, 41, 43
SFB582, 11, 102
SharedBuddyList, 52, 88, 89
ShareNet, 27
Single-Sign-O n, 29
Siteseer, 71
Slots, 41
Smalltalk, 64
SOAP, 37, 106
Software-Engineering, 5, 34
Software-Frameworks, 6
Sprechakte, 39
Sprechakttheorie, 39
SQL, 66
Studiosity, 101, 108
Stylesheets, 64
Subscription, siehe Abonnement
SyncML, 76
Taxonomie, 43, 59, 87
TBox, 43
Teledienstdatenschutzgesetz, 71, 93
Templates, 65
Terminkalender, 71
Thesauri, 43
TiBiD, iv, 11, 100
Topic Maps, 43
Transaktionshistorie, 71
Transparenz, 92, 97
TRUSTe, 91
TUM
Alumni & Career Center, 99
UnternehmerTUM, 100
TUMmelplatz, 11, 99, 100
UDDI, 106
UML
Klassendiagramm, 44
Unter-Community, 101
UnternehmerTUM, 11, 99
Usenet News, 71
vCard, 79, 80
Velocity, 65
Versit Konsortium, 79
Verteilte Anwendungen, 3, 6, 35, 37
Index
Verteilte Systeme, 92
Vertrauen, 17, 69, 73
Virtuelle Community, 2, 15, 21
Virtuelle Gemeinschaft, siehe Virtuelle Community
Visitenkarten, 76
W3C, 37
Wandbildschirme, 30, 108
Web-Services, 6, 37, 96, 106
Well, 2
Wertesystem, 15
Wirtschaftsinformatik, 6
Wissensmanagement, 5, 11, 20, 27, 45, 99
Wissensrepräsentation, 41
Beschreibungslogik, siehe Beschreibungslogik
deklarativ, 41
Frames, siehe Frames
für Community-Unterstützung, 44
Ontologien, siehe Ontologien
prozedural, 41
Prädikatenlogik, siehe Prädikatenlogik
Word of mouth, 72
X.500, 75, 77
Xerox Research Centre Europe, iii
XML-QL, 66
XNS, 75
XOL, 66
XPath, 66
XQL, 66
XSLT, 64
Yenta, 26
Zertifizierung, 75, 91
Zope, 28
Zugriffskontrolle, 88
extern, 91
intern, 89
rollenbasiert, 57
Zugriffsrechte, 69, 89–91, 97
lokal, 57
Zugriffstickets, 92, 97
123

Community-Unterstützungssysteme - Architektur und Interoperabilität

Transcription

Similar documents

4. Workshop WISO Mein Geld - Gewinnen Sie einen Überblick

Kongressprogramm

WISO Mein Geld

Dipl.-Inf. Martin Steckermeier

Themen 1999: Zukunftstechnologie Brennstoffzelle

ProClim– Flash - Naturwissenschaften Schweiz