Konzeption und Implementierung eines ... - Stephan, Daniel

auth+xml+doc=sxdoc
gpg
Konzeption und Implementierung eines
Clusteringmechanismus für ein Online
Informationssystem
instant messaging
group mail/forum
images
graphs
authenticate doc publish doc to the net
xml+doc=xdoc archive
map a:b multiple vocabularies
forward query to specialized system
crawl and index only certain websites
group chat
Diplomarbeit
Daniel Stephan
stephan@danielstephan.com
share bibliographies bibster
related docs in the net
jambalaya
search the net
protégé
eclipse rcp
webobjects
springframework
struts
webwork 2
jung
judge
weka
yellow pages
mail
job offers
networking
tables numeric
textual
graphic
binary
classify
postnuke PHP
12. August 2005
share documents docster
meta search
classify page in cluster
java
.NET
java
Paperball
specialized system
experts
communication
data entries
desktop search
nutch
crawl
rich client
web client
java algorithms
knowledge
p2p
Search Engine
technology
DataMining
Clustering
goal
prediction
description
Recommendations
Navigation
Orienteering
Teleporting
Classification
vis ually
textually
list clusters to in- or exclude from search
formulate query
create set
name sets
noname sets
information trends
purchase need (if like a then like b)
infer information from data
provide overview
Usage based
Content based
graph
list
tree
search within search results
add links to the cluster(s) the doc. belongs to
step by step navigating
navigate to similar documents
search by example
grouping search results
flat
hierarchical
alternative thesaurus
automate procedure
ordering by similarity
aid navigation
vivisim o
clusty.com
bmj.com
aaas.org

Inhaltsverzeichnis
I. Einleitung 1
1. Überblick über Inhalt und Prozesse 3
1.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Der Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . . . 5
2. Business Analyse 9
2.1. Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Herausforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Marktanalyse 15
3.1. Kriterien Auswahl . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Konkurrenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1. FIZ-Technik e.V. . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2. FIZ Karlsruhe / STN Online Services . . . . . . . . . . . 19
3.2.3. Deutsches Maritimes Kompetenz Netz (DMKN) . . . . . 20
3.2.4. HWWA - Hamburgisches Welt-Wirtschafts-Archiv . . . . 20
3.2.5. MarineTalk . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.6. MarineNet . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3. Wissenschaftliche Angebote . . . . . . . . . . . . . . . . . . . . . 23
3.3.1. Netacademy, a scientific community . . . . . . . . . . . . 23
3.3.2. SpringerLink . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.3. ACM Portal . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. Technisch Relevantes . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.1. Clusty / Vivísimo . . . . . . . . . . . . . . . . . . . . . . 29
3.4.2. carrot 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Inhaltsverzeichnis iv
II. Definition 33
4. Technische Analyse 35
4.1. Ist-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1. Komponenten und Schnittstellen . . . . . . . . . . . . . . 35
4.1.2. Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.3. Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.4. Einschränkungen . . . . . . . . . . . . . . . . . . . . . . . 42
4.2. Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.1. Oberflächenprototyp . . . . . . . . . . . . . . . . . . . . . 43
4.2.2. Prozess: Cluster erzeugen . . . . . . . . . . . . . . . . . . 45
4.2.3. Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.4. Komponenten und Schnittstellen . . . . . . . . . . . . . . 47
5. Wissenschaftliche Analyse 51
5.1. Information Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2. Knowledge Discovery in Databases . . . . . . . . . . . . . . . . . 54
5.3. Repräsentation von Dokumenten . . . . . . . . . . . . . . . . . . 56
5.3.1. Einordnung in Situation des ISL . . . . . . . . . . . . . . 57
5.3.2. Das Dokument als Wortsack (aka word-bag) . . . . . . . . 57
5.3.3. Methoden für die Beschränkung auf wesentliche Features 59
5.3.4. Latent Semantic Indexing . . . . . . . . . . . . . . . . . . 62
5.4. Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
III. Umsetzung 69
6. Statisches Modell 71
6.1. Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2. Data Access Objects . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.3. Data Access Commands . . . . . . . . . . . . . . . . . . . . . . . 75
7. Dynamisches Modell 83
7.1. Stoppworte finden . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.2. Term-Dokument-Matrix erstellen . . . . . . . . . . . . . . . . . . 84
7.3. Matrix Berechnungen . . . . . . . . . . . . . . . . . . . . . . . . 87
7.4. Cluster Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.5. Cluster Benennung und Matrizen . . . . . . . . . . . . . . . . . . 90

v Inhaltsverzeichnis
8. Verwendung des Programms 93
8.1. Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.2. Benutzeroberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.3. Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
IV. Abschluss 99
9. Ergebnisse und Fazit 101
9.1. Technische Perspektive . . . . . . . . . . . . . . . . . . . . . . . . 101
9.1.1. Testdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
9.1.2. Laufzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
9.1.3. Qualität . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9.1.4. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.2. Fachliche Perspektive . . . . . . . . . . . . . . . . . . . . . . . . . 106
9.2.1. Potentiale . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
9.2.2. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
9.3. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Glossar 111
Literaturverzeichnis 115

Inhaltsverzeichnis vi

Tabellenverzeichnis
4.1. Dataobject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2. Dataobject (Fortsetzung) . . . . . . . . . . . . . . . . . . . . . . 41
9.1. Laufzeit bei 521 Dokumenten . . . . . . . . . . . . . . . . . . . . 102
9.2. Laufzeit bei 1684 Dokumenten . . . . . . . . . . . . . . . . . . . 102

Tabellenverzeichnis viii

Abbildungsverzeichnis
1.1. Das Prototypen-Modell . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. ISL-Strategie-Komponenten . . . . . . . . . . . . . . . . . . . . . 10
3.1. Vergleichstabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Beispiel einer MarineNet Suchmaske . . . . . . . . . . . . . . . . 24
3.3. Inhalt von Drewry, angeboten von MarineNet . . . . . . . . . . . 25
3.4. Erweiterte Suche im ACM Portal . . . . . . . . . . . . . . . . . . 28
4.1. System-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2. Erfassungsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3. Rechercheprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4. Screenshot der Suchmaske . . . . . . . . . . . . . . . . . . . . . . 41
4.5. Recherche-Formular . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.6. Verweis auf ähnliche Dokumente . . . . . . . . . . . . . . . . . . 45
4.7. Clustering Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.8. Datenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.9. System-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1. Tabellarische Darstellung aus [VR79] . . . . . . . . . . . . . . . 54
5.2. KDD Prozess von Fayyad et al. . . . . . . . . . . . . . . . . . . . 55
6.1. Datenobjekte, relationale Sicht . . . . . . . . . . . . . . . . . . . 72
6.2. Datenobjekte, objektorientierte Sicht, Teil 1 . . . . . . . . . . . . 73
6.3. Datenobjekte, objektorientierte Sicht, Teil 2 . . . . . . . . . . . . 74
6.4. DAO Struktur, Teil 1 . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.5. DAO Struktur, Teil 2 . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.6. DAO Struktur, Teil 3 . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.7. Data Access Commands, Teil 1 . . . . . . . . . . . . . . . . . . . 79
6.8. Data Access Commands, Teil 2 . . . . . . . . . . . . . . . . . . . 80
6.9. Beispiel: BatchAssign Command . . . . . . . . . . . . . . . . . . 81

Abbildungsverzeichnis x
7.1. Wort Häufigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.2. Ablauf Text Analyse . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.3. Ablauf Matrix Berechnung . . . . . . . . . . . . . . . . . . . . . . 87
7.4. Ablauf Cluster Analyse . . . . . . . . . . . . . . . . . . . . . . . 89
7.5. Klassendiagramm Cluster Algorithmen . . . . . . . . . . . . . . . 91
7.6. Klassendiagramm für Matrizen und SVD Ergebnisse . . . . . . . 92
8.1. Bildschirmfoto des Cluster Browsers . . . . . . . . . . . . . . . . 94
8.2. Bildschirmfoto des Menüs . . . . . . . . . . . . . . . . . . . . . . 95
8.3. Ausschnitt der Komponentenkonfiguration . . . . . . . . . . . . . 96

Teil I.
Einleitung

1. Überblick über Inhalt und Prozesse
1.1. Einleitung
Diese Diplomarbeit entsteht in Zusammenarbeit mit dem Institut für Seever-
kehrswirtschaft und Logistik (ISL) im Rahmen der neuen sich dort entwickeln-
den Online-Strategien. Aus den Gesprächen, die mit dem ISL geführt wurden,
kristallisierte sich heraus, dass sich das ISL unter anderem als Anbieter für
spezialisierte Informationen sehen und auf dieser Basis neuartige Dienstleistun-
gen generieren möchte. Das derzeitig existierende Angebot umfasst die Litera-
turdatenbank Seabase, dabei soll es jedoch keinesfalls bleiben. Es ist geplant,
zusätzlich zu den Literaturhinweisen aus dem Fundus des ISL weitere Quellen
zu erfassen und verstärkt Online-Resourcen oder gar Informationen von Part-
nerunternehmen einzubeziehen. Zudem ergibt die ausschließliche Ausrichtung
des ISL auf Literaturhinweise aus den Bereichen Seewirtschaft und Logistik ein
vergleichsweise konzentriertes System aus Schlagworten und zugehörigen Lite-
raturhinweisen, so dass deren Unterschiede subtil sind. Die Schwierigkeit für die
Nutzer besteht darin, die richtigen Schlagworte oder Deskriptoren auszuwählen,
damit die Ergebnisse wirklich für das Suchziel relevant sind. Bei größerem Um-
fang der angebotenen Information wächst die Anforderung an die Methodik der
Recherche, auch bei großen Datenmengen hilfreiche Ergebnisse zu ermöglichen.
Aus diesem Grund entschied man sich dafür, den Kontext der Arbeit bei der Re-
cherchemethodik anzusiedeln. Die Arbeit zielt nun darauf ab, einen innovativen
Recherche-Mechanismus zu entwickeln. Mehr zum ISL findet sich in Abschnitt
2.1 (Seite 9).
Die Arbeit beginnt zunächst mit einer generellen Betrachtung der Umgebung,
in der sich das Informationssystem des ISL befindet. Dazu wurden Angebote
anderer Firmen kurz betrachtet und beschrieben, um zeigen zu können, wie sich
das Angebot des ISL (in Bezug auf die Suchmethodik) im Vergleich darstellt.
Dies geschieht in Kapitel 3 (Seite 15).
In Kapitel 6 (Seite 71) wird die Architektur der technischen Realisierung

1.2. DER PROZESS 4
beschrieben und Kapitel 9 (Seite 101) erläutert die erzielten Ergebnisse und
gibt einen Ausblick auf weitere Möglichkeiten.
Sofern in den Formulierungen dieser Arbeit der Nutzer oder beispielsweise
der Suchende angesprochen wird, so sei hiermit versichert, dass natürlich auch
weibliche Suchende und Nutzer, sprich Nutzerinnen, mit eingeschlossen sind.
1.2. Der Prozess
Im Rahmen dieser Arbeit wird ermittelt, wie ein Clustering Verfahren eingesetzt
werden kann, um Rechercheergebnisse zu optimieren. Dabei wird eine mögliche
Lösung vorgeschlagen, und für diese ein Prototyp (vgl. Seite 116 in [Bal98])
entworfen und dargestellt. Der Prototyp soll die Funktionsfähigkeit des Algo-
rithmus an einem Beispiel mit echten Daten des ISL demonstrieren. Der Ablauf
der Arbeit orientiert sich wegen der Forschungsnatur am Prototypen-Prozess-
Modell (vgl. Seiten 114ff in [Bal98]).
Das Modell wird laut Quelle unter anderem dann verwendet, wenn sich die
Realisierbarkeit nicht vorab garantieren lässt. Das Modell erlaube es zudem, den
Auftraggeber von der prinzipiellen Durchführbarkeit der Idee zu überzeugen.
Beides sind im Kontext dieser Arbeit zutreffende und überzeugende Argumente.
Abbildung 1.1 gibt die Darstellung der Quelle wieder. Der hellblaue Bereich
kennzeichnet die Aspekte, die das Prototypen-Modell anderen Modellen hin-
zufügt. ” Die Gesamtgrafik zeigt eine Ergänzung der traditionellen Modelle um
Prototypen.“ (vgl. Seite 118 in [Bal98]) Die vier Kernprozesse finden sich in den
traditionellen Modellen ebenso wieder, werden aber jeweils durch Prototypen-
Aspekte erweitert und sind deshalb nur zum Teil in den blauen Bereich gezeich-
net.
Die Quelle merkt an, eine Voraussetzung für ein erfolgreiches Umsetzen des
Modells sei die aktive Beteiligung der Endbenutzer am Prototyping-Prozess,
erwähnt aber ebenso, dass die Vorgehensweise letztlich von der untersuchten
Fragestellung abhängt. Im Rahmen dieser Diplomarbeit wurde sicherlich we-
niger Kontakt zu den Nutzern gepflegt, als dies die Erdenker des Modells im
Kopf hatten. Aber schließlich handelt es sich hierbei um eine Diplomarbeit und
um kein (wirtschaftlich motiviertes) Softwareprojekt. Das zu erreichende Ziel
ist viel eher die Darstellung der generellen Anwendbarkeit in dem konkreten
Umfeld des ISL.
Diese Arbeit vollzieht also keinen vollständigen Entwicklungsprozess, an des-

5 1.3. ENTWICKLUNGSUMGEBUNG
Kunde
Aquirieren
Demo Prototyp
Planen
Prototypen-Modell
Prototyp Labormuster Pilotsystem
Definieren Entwerfen Implementieren
Durchführbarkeitsstudie Produktmodell Produktarchitektur Produkt
Änderungen
Benutzer
Erweiterungen
Änderungen
Abbildung 1.1.: Das Prototypen-Modell
sen Ende ein einsatzfähiges Produkt steht, denn dies würde den Rahmen der
Diplomarbeit sprengen. Der Autor hat sich stattdessen auf die ersten Schritte
beschränkt. Es wird geplant, definiert und entworfen, jedoch nicht implemen-
tiert. Dementsprechend beschränkt sich die Implementierungsleistung auf die
erstellten Prototypen und Labormuster. Es gibt einen Demo-Prototypen, der
in Abschnitt 4.2 (Seite 43) dargestellt wird und einen (vertikalen) Prototypen,
der in Kapitel 6 (Seite 71) beschrieben wird.
1.3. Entwicklungsumgebung
Diese Arbeit entsteht mithilfe von spezialisierten Werkzeugen, die jeweils ihre
Aufgabe im Gesamtprozess haben. Beispielsweise werden, um die Gedanken zu
strukturieren und zielgerichteter vorzugehen, einige Mindmaps entworfen. Eine

1.3. ENTWICKLUNGSUMGEBUNG 6
Mindmap fixiert ziellos umherirrende Gedanken und ermöglicht oder erleich-
tert es, nützliche Ideen von solchen zu trennen, die das Thema nicht treffen.
Die hierfür verwendete Software heißt FreeMind und ist unter der URL free-
mind.sourceforge.net 1 herunterzuladen. Ein Exemplar einer solchen Map ist auf
der Titelseite zu sehen.
Während der Ermittlung der Anforderungen des ISL wird das generische
Werkzeug Protégé verwendet. Dieses erlaubt, eine beliebige Datenstruktur zu
definieren, und bietet automatisch passende Eingabeformulare für die verschie-
denen Datenobjekte an. Das Werkzeug ist für die Entwicklung von Ontologien
gedacht und spezialisiert sich somit begrifflich auf Dinge wie Klassen, Instanzen
und benannte Beziehungen dazwischen. Für die Dokumentation der Anforde-
rungen wird eine passende Datenstruktur mit Protégé definiert. Diese beinhaltet
Klassen wie Requirement oder Person und vervollständigt diese mit Beziehun-
gen wie ” depends-on“ zwischen Requirements oder ” needs“ zwischen Person und
Requirement. Um das Ergebnis kommunizieren zu können, wird ein einfaches
Export-Plugin entwickelt, welches die Daten in eine XML Datei exportiert, die
daraufhin mittels XSL-T in eine für gängige Browser lesbare Form (HTML und
PDF) umgewandelt werden kann. Auf diese Weise hat der Anforderungsanalyst
auf der einen Seite eine strukturierte Eingabemöglichkeit, die die Beziehungen
der Anforderungen untereinander in einer logisch formell korrekten Form ablegt,
und auf der anderen Seite kann er eine lesbare Form der Anforderungen auto-
matisch erzeugen. Dies ist jedoch durch kommerzielle Produkte, die sich auf
die Dokumentation und Verwaltung von Anforderungen spezialisieren, besser
möglich. Insbesondere können diese Werkzeuge mehrere Mandanten verwalten
und professionell Versionierung betreiben, was mit dieser generischen Art und
Weise schlecht bis gar nicht funktioniert. Protégé ist somit zwar kein perfek-
tes Werkzeug für diese Aufgabe, aber es ist kostenlos und durch eigene Plug-
ins erweiterbar. Herunterzuladen auf protege.stanford.edu 2 . Das Export-Plugin
liegt zusammen mit dem nötigen XSL-T Stylesheet und der verwendeten Klas-
senstruktur für Protégé unter dieser URL vor: www.danielstephan.com/thesis/
prot-req.zip 3 .
Zur Unterstützung des Softwaredesigns wird der Enterprise Architect von
Sparx Systems 4 in der Version 5.0 verwendet. Um Roundtrip-Engineering durchführen
1 WWW Adresse: http://freemind.sourceforge.net
2 WWW Adresse: http://protege.stanford.edu
3 WWW Adresse: http://www.danielstephan.com/thesis/prot-req.zip
4 WWW Adresse: http://www.sparxsystems.com.au/

7 1.3. ENTWICKLUNGSUMGEBUNG
zu können, muss die Software Java-Quellcode erzeugen sowie selbigen mittels
Reverse Engineering wieder einlesen können. Vergleichbare Software mit dieser
Funktion von Borland (Together 2005 for JBuilder, derzeit für EUR 1740) und
NoMagic (MagicDraw Professional, derzeit für EUR 255) erwiesen sich vergli-
chen mit dem Enterprise Architect, USD 95, als zu kostspielig.
Die Implementation verwendet die aktuellste Version der Sprache Java (ja-
va.sun.com/j2se/1.5.0 5 ) und wird mit der leistungsfähigen Open-Source Ent-
wicklungsumgebung Eclipse (www.eclipse.org 6 ) durchgeführt.
Der Text der Arbeit selber wird, der innovativen Natur ihres Inhalts folgend,
weder mit einer üblichen Textverarbeitung noch (direkt) mit Latex, des im wis-
senschaftlichen Umfeldes üblichen Textsatzsystems, verfasst. Stattdessen wird
die XML Variante des ursprünglich auf SGML basierenden Formats Docbook
verwendet (siehe www.oasis-open.org/docbook 7 ). Der Grund für diese Wahl ist
in erster Linie die Neugier des Autors. Da es sich um ein XML basiertes Format
handelt, wird der Text mit einem XML Editor verfasst. Es handelt sich bei dem
XML Editor um , der unter www.oxygenxml.com 8 zu beziehen ist.
Die Software liefert sämtliche für Docbook nötigen Stylesheets mit. Die Styles-
heets sind alternativ unter docbook.sourceforge.net/projects/xsl/ 9 zu beziehen.
Da der Autor im Rahmen des Schreibens festgestellt hat, dass die mit Docbook
erzeugten Ergebnisse nicht ausreichend perfekt gesetzt sind, hat er nach Alter-
nativen gesucht. Das Ergebnis dieser Suche kann auf www.danielstephan.com/
dbp.html 10 nachgelesen werden.
Somit existiert letztendlich der Text in Form von XML im Docbook For-
mat, der Satz jedoch wird von LATeX durchgeführt. Dank DBP existiert ein
funktionierender Prozess von XML über LATeX zu PDF.
5 WWW Adresse: http://java.sun.com/j2se/1.5.0/
6 WWW Adresse: http://www.eclipse.org/eclipse/
7 WWW Adresse: http://www.oasis-open.org/committees/tc home.php?wg abbrev=
docbook
8 WWW Adresse: http://www.oxygenxml.com
9 WWW Adresse: http://docbook.sourceforge.net/projects/xsl/
10 WWW Adresse: http://www.danielstephan.com/dbp.html

1.3. ENTWICKLUNGSUMGEBUNG 8

2. Business Analyse
2.1. Ausgangssituation
Das ISL besitzt nach eigenen Aussagen mit einem Bestand von über 80000 er-
fassten Einträgen eine der größten Literatur-Datenbanken im Bereich der See-
verkehrswirtschaft. Diese Daten hätten für das ISL bzw. für dessen Kunden
einen hohen Wert. Da Informationen per se immer mehr ausschließlich im In-
ternet gesucht würden und sich immer weniger Kunden persönlich in die Räume
des Instituts begäben, würde das nicht genutzte Potential der Datenbank im-
mer größer und der Betrieb der Datenbank infolgedessen immer teurer werden.
Daher wurde schnell klar, dass der Datenbestand ins Internet gebracht werden
muss, um hier der Nachfrage zu begegnen, der ” offline“ immer seltener entge-
gengetreten werden kann.
Belegt wurde die Einsicht durch eine Studie [ISL01], die das ISL zusammen
mit Roland Berger und PriceWaterhouseCoopers im Auftrage des Bundesmini-
steriums für Wirtschaft und Technologie (BMWi) bis Ende 2001 durchgeführt
hatte. Diese Studie belegte insbesondere den gewachsenen Stellenwert des Inter-
nets in Bezug auf die Informationsbeschaffung in Unternehmen der maritimen
Wirtschaft. Obwohl laut Studie nur 17,5% der Informationen aus dem Internet
bezogen würden (der persönliche Kontakt erbringt nach wie vor die meisten
relevanten Informationen), wäre das Internet als ein wichtiges Medium der In-
formationsbeschaffung zu sehen, weil die Tendenz zur online Nutzung immanent
gegeben sei. Der Grund der noch eher geringen Nutzung könnte im mangelhaf-
ten Angebot liegen. Die Studie stellt fest, dass mehr als 90% der Befragten
die übermäßige Informationsflut als Belastung empfänden. Die Menge an In-
formationen führe zu einem hohen Aufwand bei der Selektion der relevanten
Informationen. Zudem seien die Informationen oft nicht aktuell.
Diesen Erkenntnissen folgend wurde die Strategie etabliert, Inhalte des ISL im
Rahmen eines Portals online anzubieten und ein Geschäftsmodell zu entwickeln,
das die erkannten Herausforderungen adressiert.

2.2. ZIELE 10
Business Strategie
Profile
Selektion
Inhalte
Abbildung 2.1.: ISL-Strategie-Komponenten
Ein Ergebnis dieser Bemühungen ist bereits zum jetzigen Zeitpunkt erkenn-
bar. Und zwar werden bereits einige Angebote online verkauft. Für diesen Zweck
hat das ISL einen Online-Shop eingerichtet. Dort werden eine Handvoll re-
gelmäßiger Publikationen des ISL angeboten. Diese Publikationen werden nach
Aussage des ISL vom Markt nachgefragt. Es handelt sich dabei um vergleichs-
weise hochwertige Publikationen. Eine Publikationen wie das Jahrbuch kostet
zum Beispiel inklusive CD-ROM knapp 300 Euro. Zusätzlich gibt es das Ship-
ping Statistics and Market Review, welches 9 Mal im Jahr erscheint, jeweils mit
etwas unterschiedlichen Schwerpunkten. Es kostet inkl. CD-ROM 470 Euro pro
Jahr 1 .
2.2. Ziele
Das übergeordnete strategische Ziel des ISL ist es, Informationen anzubieten
und über deren Individualisierung Geld zu verdienen. Dieses Hauptziel lässt
sich, wie in Abbildung 2.1 dargestellt, aus drei Komponenten aufbauen, ohne
die es nicht oder schwer verwirklicht werden kann.
Ein Kernpunkt und somit die erste Komponente sind die Inhalte, die ange-
1 Stand: Juli 2005

11 2.3. HERAUSFORDERUNGEN
boten werden sollen. Hier gilt es, eine ansprechende Auswahl sicherzustellen. In
diesem Zusammenhang strebt das ISL eine Zusammenarbeit mit Partnerorgani-
sationen an, deren Inhalte zusammen mit denen des ISL in einem gemeinsamen
System angeboten werden sollen. Zudem wurde erkannt, dass die Nutzer die
Inhalte in aller Regel unverzüglich erwarten. Sofern möglich sollen somit In-
halte in digitaler Form (Volltexte, Statistiken, Tabellen) vorgehalten und vom
zahlenden Kunden auf Knopfdruck abgerufen werden.
Das Angebot kann nur dann für die Kunden interessant sein, wenn die Men-
ge an hilfreichen Inhalten groß genug ist. Diese Erkenntnis liefert im Um-
kehrschluss die Forderung, dass Kunden die gewünschten Inhalte auf einfache
Weise aus dem Fundus selektieren können müssen und somit das System ent-
sprechend mächtige Recherchemechanismen aufweist, die die zweite Komponen-
te darstellen. Diese soll die Strukturen der Informationslandschaft offensichtlich
machen und geeignete Navigationselemente bereitstellen, damit sich der Kunde
zurechtfindet und einfach eine Vielzahl für ihn relevante Inhalte finden kann.
Um das Informationsangebot wertvoller zu gestalten, soll es individuell auf
den Nutzer zugeschnitten werden, dies schließt den Kreis. Das wiederum setzt
die Existenz von individuellen Kundenprofilen voraus, auf deren Basis perso-
nalisierte Angebote maßgeschneidert werden können. Diese Angebote beinhal-
ten einen automatischen Benachrichtigungsdienst über neue Dokumente, die
zum Kundenprofil passen, der mittels E-Mail realisiert werden soll, sowie ei-
ne Möglichkeit, fehlende Informationen (unbefriedigte Nachfrage) online zu
bemängeln. Letzte Funktion soll die Kundenwünsche erkennbar machen und
das ISL in die Lage versetzen, auf die Nachfrage besser zu reagieren.
Auf diese Arbeit bezogen können natürlich nicht alle Ziele des ISL umgesetzt
werden. Daher konzentriert sie sich auf die zweite Komponente und entwickelt
eine innovative Recherchetechnologie.
2.3. Herausforderungen
Um zu verstehen, welche Herausforderungen für die Recherche in Informations-
systemen wie dem des ISL existieren, sollte man zunächst wissen, wie eine solche
Recherche abläuft. Was ist also Recherche? Recherche wird hier als Oberbegriff
für die Suche nach Informationen verstanden. Im Kontext dieser Arbeit sind
es speziell die Suchvorgänge, die mit Hilfe eines Informationssystems wie der
ISL Seabase durchgeführt werden. Aber betrachten wir einmal, wie das typische

2.3. HERAUSFORDERUNGEN 12
Nutzerverhalten während einer solchen Suche aussieht.
Der Ablauf einer typischen Recherche beginnt, sobald ein Nutzer ein Defizit
oder ein Interesse entwickelt und nach Informationen sucht, die den neu aufge-
kommenen Bedarf befriedigen. Der Nutzer wird möglicherweise nicht zuerst das
Internet aufsuchen, sondern stattdessen zunächst seine eigenen Bücher, sowie
Dateien und Datenbanken durchforsten und eventuell noch jemanden anrufen,
aber spätestens danach sucht er das Internet auf und landet hoffentlich zügig
auf den Webseiten des ISL.
Wie in [TAAK04] von Teevan et al. dargelegt wurde, gibt es für den Nutzer
im Internet im groben zwei Methoden, ans Ziel zu gelangen. Die eine Methode
besteht darin, eine möglichst exakte Suchanfrage zu formulieren, die die gesuch-
ten Informationen ausreichend exakt beschreibt, so dass das System direkt das
Gesuchte liefert. Diese Vorgehensweise nennt das genannte Paper Teleporting.
Der Nutzer teleportiert sich im übertragenen Sinne direkt zu der gewünschten
Information. Im Buch [RM02] von Rosenfeld und Morville wird es The Perfect
Catch genannt und jedoch dargelegt, dass dieses sehr simple Vorgehen alleine
oft nicht zum Ziel führt.
Dafür gibt es mehrere Gründe, zum einen weiß der Nutzer manchmal nicht
genau genug, wonach er sucht. In diesem Falle muss er seine Suche allgemeiner
halten, sich erst einmal umschauen und das Angebot ” spielerisch“ erforschen.
Anders ausgedrückt: der Nutzer muss sich zunächst orientieren und Teleporting
ist für ihn nicht möglich.
Und selbst wenn er weiß, wonach er sucht, so ist die Sprache, die er für
die Suche verwendet nicht notwendigerweise die selbe, mit der die gesuchte
Information erfasst wurde. Dabei ist mit Sprache noch nicht einmal Sprache
im Sinne von Französich oder Deutsch, sondern eher die Wortwahl gemeint, die
bei unterschiedlichen Menschen unterschiedlich ausfällt. [RM02] fragt in diesem
Zusammenhang ” ’PDA’, ’Handheld’ oder ’Handheld PC’“?
Alle hier betrachteten Autoren stellen jeweils auf ihre Weise fest, dass ein
Nutzer die Schwierigkeiten durch ein mehrschrittiges Vorgehen zu überwinden
versucht, bei dem sich Orientierung/Browsen und Direktsuche abwechseln. Tee-
van et al. nennen dies Orienteering und belegen empirisch dessen bevorzugte
Nutzung. [Bat89] nennt es Berrypicking, weil der Nutzer über verschlungene
Pfade durch den Informationsraum wandert und auf dem Wege die Beeren
pflückt, die ihn interessieren. Im Paper von Teevan et al. wird vermutet, dass
diese kombinierte, aus mehreren Schritten bestehende Suche die kognitiven Pro-

13 2.3. HERAUSFORDERUNGEN
zesse von Nutzern weniger fordert und deshalb bevorzugt wird. Sie haben empi-
risch festgestellt, dass Nutzer bevorzugen, einigen Verweisen zu folgen und sich
dadurch Schritt für Schritt dem Ziel anzunähern, anstatt eine exakte Anfrage
anzugeben und direkt zum Ziel zu gelangen. Das gilt sogar, wenn der Suchende
genau weiß, wo das Gesuchte liegt, und er oder sie sogar ohne weiteres in der
Lage wäre, die Anfrage exakt genug zu formulieren.
Ein Informationssystem sollte folglich ein mehrschrittiges, iteratives Vorge-
hen erlauben oder gar besonders unterstützen. Das ISL ist dafür bereits gut
aufgestellt, denn der gepflegte, ausführliche Thesaurus ist eine gute Grundla-
ge dafür, Orientierungshilfen anbieten zu können. Ein darüber hinausgehendes
Clustering kann dies noch verbessern.

2.3. HERAUSFORDERUNGEN 14

3. Marktanalyse
3.1. Kriterien Auswahl
Es gilt nun herauszufinden, wie die Suche in online Informationssystemen in der
Praxis vom Rest der Welt organisiert wird. Es sollen dadurch übliche Vorge-
hensweisen demonstriert und der Ansatz dieser Arbeit in einen Kontext gesetzt
werden. Dokumente, Webseiten oder Dateien in Datenbanken zu suchen ist ein
ganz zentraler Faktor, der sich mit der Zunahme der Menge an Informationen,
die sich in den Datenbanken dieser Welt verstecken, an zunehmender Wich-
tigkeit erfreut. Daher bieten so gut wie alle Informationssysteme mehr oder
weniger ausführliche Unterstützung für die Recherche in ihren Systemen an.
Die Auswahl der betrachteten Informationssysteme beinhaltet eine Reihe de-
rer, die bereits vom ISL als relevante Konkurrenz auf dem Markt erkannt wor-
den waren. Darüberhinaus werden einige allgemein bekannte Online-Dienste
betrachtet, sowie auch solche die ähnliche Ansätze in anderen Märkten verfol-
gen. All diese Dienste werden hier nach einer Reihe von Kriterien ausgewertet.
Die Kriterien stützen sich sowohl auf die technische Umsetzung des Angebots,
als auch auf dessen Wirksamkeit in Bezug auf wirtschaftliche Faktoren. Im fol-
genden sollen die Kriterien aufgelistet und erläutert werden.
Community Beinhaltet das Angebot Dienste für eine virtuelle Gemeinschaft?
Derartige Dienste erlauben die Wertschöpfung zwischen Kunden und erhöhen
somit die Wertigkeit des Angebots mit Hilfe von Netzwerkeffekten.
Zielgruppe An wen richtet sich das Angebot in erster Linie?
Erfassung Auf welche Weise kommen die Daten ins System? Erfasst der Anbie-
ter selber oder verkauft er den Zugriff auf Datenbanken anderer Firmen?
Erfassung durch Kunden Können Kunden eigene Dokumente in das System
einpflegen?

3.1. KRITERIEN AUSWAHL 16
Suche mittels boolschen Operatoren Sind Begriffe mittels UND/ODER be-
liebig kombinierbar?
Suche auf der Basis einer Taxonomie Sind die Dokumente mit Schlagworten
versehen, die untereinander in einer oder mehreren Spezialisierungsbezie-
hungen stehen (Taxonomie)?
Suche ähnlicher Begriffe möglich Ist das System in der Lage, trotz Tippfehler
sinnvolle Ergebnisse zu liefern?
Volltextsuche Suche im Volltext des Angebots ist möglich.
Clustering Der Suchmechanismus gruppiert die Suchergebnisse automatisch.
Angebot ist aktuell Ist das Angebot aktuell? Monate alte Neuigkeiten weisen
auf ein schlecht gepflegtes System hin und werden kaum Nutzer anziehen.
Viele brandaktuelle Artikel wiederum zeugen von einem erfolgreichen An-
gebot mit echtem Nutzwert .
Angebot beinhaltet digitale Dokumente Sind die Dokumente online zu bezie-
hen und zu lesen?
Angebot beinhaltet Reports über Rohdaten Steht hinter dem Angebot eine
Datenbank , deren Inhalte in Form von Tabellen und Graphen ohne text-
liche Beschreibung dargeboten werden?
Angebot beinhaltet kostenpflichtige Suchergebnisse Sind die Ergebnisse des
verwendeten Suchmechanismus kostenpflichtig?
Angebot beinhaltet kostenpflichtige Dokumente Sind einzelne Dokumente käuf-
lich zu erwerben?
Angebot beinhaltet kostenpflichtigen Systemzugang Ist der Zugang zum Sy-
stem oder zu Teilen des Systems pauschal kostenpflichtig?
Marketingplattform Es besteht eine Möglichkeit für Partner und andere Fir-
men, auf der Web Site Werbung zu machen. Sei es durch Banner oder
” sponsored news“.
Werbefinanziert Die Angebote finanzieren sich hauptsächlich durch Werbung.
Yellow Pages Das System beinhaltet Verzeichnisse von Firmen und Produkten.

17 3.2. KONKURRENTEN
Die Ergebnisse sind in Abbildung 3.1 (Seite 18) nachzulesen.
3.2. Konkurrenten
3.2.1. FIZ-Technik e.V.
FIZ Technik e.V. 1 ist ein gemeinnütziger technisch-wissenschaftlicher
Verein. Mitglieder sind: VDMA e.V. (Verband Deutscher Maschinen-
und Anlagenbau), VTDI e.V. (Textil) und FWD e.V. (Werkstoffe)
sowie die Industrieunternehmen und Forschungseinrichtungen: Ro-
bert Bosch GmbH, Stuttgart, DaimlerChrysler AG, Stuttgart, Sie-
mens AG, München, MAN B&W Diesel AG, Augsburg und Fraunhofer-
Gesellschaft, München.
Das Fachinformationszentrum Technik erstellt bibliographische Datenbanken
und bietet diese in elektronischer Form an. Dazu werden jährlich ca. 120000 Do-
kumente aus Fachzeitschriften, Tagungsbänden, Forschungsberichten und Dis-
sertationen ausgewertet und gespeichert. Über 300 Mitarbeiter sind mit dieser
Aufgabe betreut. Auch hier wird, ebenso wie beim ISL, jedes ausgewertete
Dokument mit einem Kurzreferat versehen, in Kategorien einsortiert und ver-
schlagwortet. Der dazugehörige Thesaurus umfasst jeweils etwa 50000 deutsche
und englische Begriffe.
Die Recherche in den Datenbanken ist prinzipiell kostenpflichtig. Dabei un-
terscheidet die Preisliste 2 zwischen dem normalen Zugriff über die Online-Suche
sowie einem speziellen Pauschaltarif für größere Organisationen, die die Recher-
che aus dem eigenen Intranet heraus erlauben möchten. Der Preis für den nor-
malen Zugriff setzt sich aus der Login-Gebühr von e5,40, die entsprechend bei
jedem Login-Vorgang anfällt, einer sog. Anschaltzeit, die auf eine nicht näher
spezifizierte Art und Weise aus dem Suchaufwand der Datenbank errechnet
wird (durchschnittlicher Preis ca. e100 pro Stunde), sowie einer Dokumentaus-
gabegebühr , die je nach Datenbank und Format zwischen e1,50 und e2,50
schwankt und pro angezeigter Bibliographie abgerechnet wird, zusammen. Die
Anschaltzeiten und Dokumentausgabegebühren schwanken je nach abgefragter
Datenbank, ebenso wie die Pauschalpreise. Diese schwanken für Großunterneh-
men von e3885,- bis e65200,- pro Datenbank pro Jahr. KMUs und Fachhoch-
1 WWW Adresse: http://www.fiz-technik.de
2 WWW Adresse: http://www.fiz-technik.de/download/preise.pdf

3.2. KONKURRENTEN 18
T : Techniker / Ingenieure
W : Wissenschaftler
M : Manager
Community
☑ ☑
Zielgruppe TW MTW MTW WM TMW TMW M TMW TW
Erfassung durch Anbieter ☑ ☑ ☑ ☑ ☑ ☑ ☑
Erfassung durch Kunden ☑ ☑ ☑
Suche mittels booleschen Operatoren ☑ ☑ ☑ ☑ ☑ ☑
Suche syntaktisch ähnlicher Begriffe möglich ☑ ☑ ☑ ☑ ☑
Volltextsuche ☑ ☑ ☑ ☑ ☑ ☑ ☑
Clusteranalyse ☑
Suche auf der Basis einer Taxonomie ☑ ☑
Angebot ist relativ aktuell ☑ ☑ ☑ ☑ ☑ ☑ ☑/- ☑ ☑
Angebot beinhaltet digitale Dokumente ☑ ☑ ☑ ☑ ☑ ☑
Angebot beinhaltet Reports über Rohdaten ☑
Angebot beinhaltet kostenpflichtige Suchergebnisse ☑
Angebot beinhaltet kostenpflichtige Dokumente ☑ ☑ ☑ ☑
Angebot beinhaltet kostenpflichtigen Systemzugang ☑ ☑ ☑
Marketingplattform ☑ ☑ ☑ ☑
Werbe finanziert ☑ ☑
Yellow Pages
☑ ☑ ☑ ☑ ☑ ☑
Abbildung 3.1.: Vergleichstabelle
www.fiz-technik.de
www.hwwa.de
www.dmkn.de
www.netacademy.org
www.springerlink.com
www.marinetalk.com
www.marine-net.com
www.clusty.com
portal.acm.org
Marktvergleich

19 3.2. KONKURRENTEN
schulen zahlen zwischen e788,- und e13020,-. Es gibt 10 FIZ-Technik-eigene
Datenbanken und 16/17 fremde Datenbanken, die FIZ-Technik lizensiert und
integriert hat. Der Autor stellt fest, dass das Preissystem auf ihn durch die
vielen Einzelposten abschreckend wirkt. Hier wäre eine Mischkalkulation mit
weniger einzelnen Posten eventuell eher anzuraten.
FIZ Technik nutzt Volltextsuche und erlaubt die Verknüpfung mittels bool-
schen Operatoren. Zusammen mit dem aufwendigen Thesaurus ist die Methodik
recht fortschrittlich, wenn auch kompliziert. Es wird kein Clustering durch-
geführt.
3.2.2. FIZ Karlsruhe / STN Online Services
Das FIZ Karlsruhe ist eine 1977 gegründete gemeinnützige Gesellschaft mit
dem Auftrag, Fachinformationen bereitzustellen. Dieses tut sie insbesondere
dadurch, dass sie im Rahmen des STN Online Service in Kooperation mit der
American Chemical Society (ACS) und der Japan Science and Technology Cor-
poration (JST) weltweit existierende Datenbanken in ihr System integriert. Fer-
ner werden auch eigene Datenbanken erstellt und gepflegt. Unter anderem zählt
hierzu die Zeitschriftendatenbank der Thieme Verlagsgruppe 3 sowie das System
von vascoda 4 . Die Preise 5 sind nicht sehr weit von denen von FIZ-Technik ent-
fernt und sind eher etwas höher. Die Anschaltzeit ist auch hier zu finden und
scheint ein branchenübliches Phänomen darzustellen. Auffällig ist im Vergleich
zu FIZ-Technik, dass die Gebühr für die Anzeige bzw. den Druck (Dokument-
ausgabegebühr ) drei mal so hoch ist und je nach Datenbank auch Preise von
über e20,- für diesen Posten zu sehen sind.
Der Fokus liegt hier eher in der Integration von Datenbanken (im Rahmen
von STN) sowie im Auftritt als IT Dienstleister. Dadurch ist die Anzahl der
Datenbanken wesentlich höher als bei FIZ Technik, deren Hauptarbeit in der
Erfassung und Pflege der eigenenen Datenbanken zu stecken scheint. Die genaue
Anzahl der Datenbanken geht aus der oben genannten Preisliste, in der jede
Datenbank einzeln aufgelistet ist, hervor.
3 WWW Adresse: http://www.thieme-connect.de
4 WWW Adresse: http://www.vascoda.de
5 WWW Adresse: http://www.stn-international.de/service/prices/EUROde.pdf

3.2. KONKURRENTEN 20
3.2.3. Deutsches Maritimes Kompetenz Netz (DMKN)
Das DMKN hat den Anspruch, Wissen im maritimen Umfeld zu sammeln und
verfügbar zu machen. Ins Leben gerufen hat es das Deutsche Marine Insti-
tut, die Marine-Offizier-Vereinigung (MOV) e.V. und die Marine-Offizier-Hilfe
(MOH) e.V. gemeinsam mit Kooperationspartnern. Auf der Website kann man
nach Artikeln, Studien, Berichten und ähnlichen Dokumenten recherchieren und
bekommt die Dokumente auch gleich in elektronischer Form auf den Schirm
geliefert. Zudem kann man sich im ExpertNet ein Bild von den Experten aus
Wirtschaft und Wissenschaft im Bereich der maritimen Wirtschaft und Technik
machen. Als eines der wenigen maritimen Angebote im Internet beinhaltet das
DMKN auch ein Forum , in dem sich Interessierte untereinander austauschen
können.
Interessant ist, dass das öffentliche Forum von den Nutzern dieses Systems
fast völlig ignoriert wird. Obwohl offenbar die Artikel und sonstigen informa-
tiven Beiträge regelmäßig aktualisiert werden und somit von einem lebendigen
System zeugen, gibt es keinerlei Interesse am persönlichen Austausch. Die mei-
sten im System verzeichneten Experten sind offenbar damit zufrieden, aufge-
listet worden zu sein und haben keine eigenen Beiträge ins System gebracht.
Die absolute Mehrheit der Beiträge stammt aus der Zeitschrift MarineForum,
die von den Betreibern des DMKN herausgegeben wird. Diese Erkenntnis re-
lativiert den zuerst entstandenen Eindruck eines lebendigen Systems. Offenbar
ist der größte und beinahe einzige Anbieter von Informationen im DMKN der
Betreiber des DMKNs selber.
Seit Ende 2004 beteiligt sich das ISL am DMKN und bietet im Rahmen eines
Kompetenzzentrums für die Seeverkehrswirtschaft eigene Inhalte an.
Die Recherchemöglichkeiten des DMKN erlauben Anfragen mit boolschen
Operatoren (AND/OR). Zusätzlich erlaubt das System die Suche mittels Wort
Varianten, sowie mittels einer syntaktischen Ähnlichkeit (dort Fuzzy Suche ge-
nannt).
3.2.4. HWWA - Hamburgisches Welt-Wirtschafts-Archiv
Das Hamburgische Welt-Wirtschafts-Archiv ist eine wissenschaftliche Service-
einrichtung, dessen Ziel es ist, Informationen zu sammeln, aufzubereiten, zu
bewerten und verfügbar zu machen. Es analysiert weltwirtschaftliche Fragestel-

21 3.2. KONKURRENTEN
lungen, informiert und berät. Aktueller Hinweis 6 : Das HWWA ist aktuell als
Auslaufmodell zu betrachten. Es gehörte lange Zeit zur Leibniz Gemeinschaft
und wurde damit öffentlich gefördert. Nach einigen sehr kritischen Evaluierun-
gen hat sich die Gemeinschaft jedoch dazu entschlossen, das Institut nicht weiter
zu fördern. Teile des HWWA werden zukünftig im neugegründeten Wirtschafts-
institut HWWI aufgehen und bleiben daher mindestens zum Teil erhalten.
Alle Dienstleistungen des HWWA zu beleuchten, würde zu weit führen. Im
Kontext dieser Arbeit ist allerdings der Bereich der Kataloge und der Online-
Publikationen interessant. Das HWWA bietet keine Community Features an.
Der online Zugriff wird über die URL http://webopac.hwwa.de/seitevor.htm 7
ermöglicht.
Kataloge
Das HWWA bietet online Nachweise von Büchern, Periodika, und Aufsätzen
aus Zeitschriften und Sammelwerken in gedruckter oder elektronischer Form,
Firmen und Körperschaften mit weiterführenden Links an. Ausserdem Presse-
artikel, Geschäftsberichte, Spezialsammlungen etc.
Für diesen Zweck existiert ein ausgefeilter Suchmechanismus, der auf ei-
nem komplexen Thesaurus basiert. Alle wichtigen Suchfunktionen (Ähnlichkeit,
boolsche Operationen, Volltext. . . ) sind vorhanden.
Online Publikationen
Das Angebot umfasst im Zusammenhang mit dem elektronischen Dokumen-
tenarchiv des HWWA sowohl Nachweise nicht-elektronischer Dokumente als
auch solche von elektronischen Dokumenten. Letztere sind im Archiv teilweise
im Volltext verfügbar. Dabei unterscheidet der Katalog zwischen frei verfügba-
ren, HWWA-intern verfügbaren, sowie kostenpflichtig verfügbaren Dokumen-
ten. Falls möglich verweist der Katalog auf den Anbieter des Dokumentes, bei
dem es dann bezogen werden kann. Verfügbare Volltexte liegen im PDF-Format
auf HWWA-Servern oder beim Anbieter selber. Im letzteren Fall verweist der
Katalog auf den Anbieter.
Neben den Angeboten, die über den Katalog zu erreichen sind, bietet das
HWWA spezielle Informationsdienste an. Häufig sind die Produkte online im
6 Pressemitteilung: http://idw-online.de/pages/de/news117649
7 WWW Adresse: http://webopac.hwwa.de/seitevor.htm

3.2. KONKURRENTEN 22
PDF oder HTML Format verfügbar - teilweise kostenfrei und teilweise kosten-
pflichtig.
3.2.5. MarineTalk
MarineTalk versteht sich als Informationsanbieter im maritimen Sektor. Das
Angebot umfasst Informationen über spezielle Produkte und darüber, wer sie
herstellt. Zudem werden ca. alle sechs Wochen aktuelle Entwicklungen im ma-
ritimen Sektor sowohl über neue Produkte als auch über allgemeine Themen in
den News-Bereich eingepflegt.
Das Angebot beinhaltet im Rahmen der Wer-Macht-Was-Suche (Buyers Gui-
de) Kurzvorstellungen der Unternehmen, die als Werbe-Möglichkeit für die ver-
zeichneten Unternehmen beworben werden. Den Unternehmen werden verschie-
dene Werbe-Pakete angeboten, von denen eines gratis, eines 10 USD im Monat
und eines 20 USD im Monat kostet. Im letzten Falle wird eine bis zu 6 Seiten
umfassende Firmendarstellung angeboten, während in der Gratisversion weder
Email noch Homepage des verzeichneten Unternehmens angegeben werden kann
und sich ausschließlich auf Adresse und Telefon beschränkt wird. Das mittlere
Angebot bietet die Möglichkeit, Verweise auf die Firmen Homepage sowie eine
Email Adresse hinzuzufügen und erlaubt zusätzlich, eine textliche Kurzbeschrei-
bung der Firma mit in das Listing aufzunehmen. Diese Beschreibung ist auch
für die Suche effektiv. Wie viele Kunden welches Angebot nutzen fällt laut Ma-
rineTalk allerdings unter das Geschäftsgeheimnis, so dass auf diese Information
verzichtet werden muss.
Die Suchfunktion umfasst eine Schlagwortsuche, sowie spezifische Eingren-
zungen. Beispielsweise ist es möglich, die Suche nach Anbietern auf ein Land
oder auch einen bestimmten Hafen zu beschränken. Firmen, die sich in das Ver-
zeichnis eintragen lassen möchten, haben die Möglichkeit, bis zu 50 Stichworte
anzugeben, unter denen sie gefunden werden können. Die Stichworte sind aller-
dings beliebig und unterliegen keiner festen Struktur, wie es in einem Thesaurus
der Fall wäre.
Das MarineNet bearbeitet jede Einsendung manuell und prüft insbesonde-
re die gewünschten Schlagwörter auf Duplikate. Je nach Qualität der einge-
sendeten Artikel/News wird der Beitrag entweder editiert oder auf der Basis
der eingesendeten Information neu geschrieben. Dieses Vorgehen garantiert ein
gleichbleibend hohes Qualitätsniveau der Beiträge.

23 3.3. WISSENSCHAFTLICHE ANGEBOTE
3.2.6. MarineNet
Das MarineNet ist eine japanische Unternehmung, die Informationen und Dienst-
leistungen für die maritime Wirtschaft anbietet. Der Fokus des Angebots liegt
dabei auf dem Zusammenbringen von Käufer und Verkäufer maritimer Produk-
te und Dienstleistungen. Dem entsprechend bietet das Unternehmen Schiffs-
Auktionen , Preisinformationen von Gebraucht-Schiffen sowie die Möglichkeit,
online nach Chartering-Informationen zu suchen und somit die Frage zu beant-
worten, ob im Hafen X ein geeignetes Schiff liegt, welches gechartert werden
kann. Im letzteren Falle vermittelt MarineNet kostenfrei zwischen dem Suchen-
den und dem Schiffs-Eigner bzw. stellt mindestens den Kontakt her.
Die meisten Funktionalitäten sind nur für Mitglieder des Systems (kosten-
pflichtig) zu erreichen. Es gab in keinem gratis zu erreichenden Teil des Online-
Angebots eine Suche.
Es gibt jedoch in den verschiedenen nach Bezahlung zu erreichenden Berei-
chen jeweils spezielle, auf das jeweilige Angebot zugeschnittene Suchmethoden.
Dezu gehören allerdings keine Schlagwort-Suche oder gar hinterlegte Thesauri
. Die Leistungen umfassen meistens Listen, beispielsweise von zu verkaufenden
Frachtern oder in der letzten Zeit durchgeführten Besitzänderungen etc.
Von Interesse dürfte allerdings sein, dass das MarineNet ausgewählte Sta-
tistiken aus dem Fundus der Beratungsfirma Drewry 8 in das eigene Angebot
integriert. Die Bedingungen des Nutzungsvertrages zwischen MarineNet und
Drewry fallen sicherlich unter das Geschäftsgeheimnis, so dass hier auch nicht
weiter geforscht wurde.
Dazu ist zu bemerken, dass vereinzelt veraltete Inhalte (Statistik überarbeitet
2002. . . ) im System zu finden sind.
3.3. Wissenschaftliche Angebote
3.3.1. Netacademy, a scientific community
Die Netacademy ist ein System für wissenschaftliche Gemeinschaften, das vom
MCM, Institut für Medien und Kommunikationsmanagement 9 ins Leben geru-
fen wurde und die von den Teilnehmern für die Publikation von Forschungser-
gebnissen und News genutzt wird. Auf diese Weise soll ein zentrales Repository
8 WWW Adresse: http://www.drewry.co.uk
9 WWW Adresse: http://www.mcm.unisg.ch/

3.3. WISSENSCHAFTLICHE ANGEBOTE 24
Abbildung 3.2.: Beispiel einer MarineNet Suchmaske

25 3.3. WISSENSCHAFTLICHE ANGEBOTE
Abbildung 3.3.: Inhalt von Drewry, angeboten von MarineNet

3.3. WISSENSCHAFTLICHE ANGEBOTE 26
entstehen, wodurch es Nachfragern erleichtert wird, die Dokumente zu finden.
Wissenschaftler bieten ihre Ergebnisse zwar häufig online an, tun dies aber in
der Regel über ihre Homepage . Wenn man nun die Menge der wissenschaftlich
tätigen Personen zugrunde legt und daraus die Zahl der Homepages ableitet,
wird man sicherlich eine stolze Menge an Orten im Internet ermitteln, an denen
wissenschaftliche Dokumente abgelegt sein könnten. Die Netacademy konsoli-
diert nun zumindest schon mal die Ergebnisse der teilnehmenden Wissenschaft-
ler, sofern diese Ihre Dokumente in das System einpflegen.
Viele Publikationen sind kostenlos zu bekommen, sofern man sich am System
angemeldet hat. Interessant wird es jedoch bei kostenpflichtigen Dokumenten,
die ebenso in der Netacademy registriert sind. Konkret handelt es sich dabei um
regelmäßig erscheinende Journale, die es einerseits in Form eines Abonnements
gedruckt zu kaufen gibt und deren Beiträge andererseits neben einigen weiteren
kostenpflichtigen Dokumenten einzeln über das Portal Ingenta 10 zu erwerben
sind, welches sich auf wissenschaftliche Publikationen spezialisiert hat. Einzeln
sind die Dokumente ausschließlich in elektronischer Form zu bekommen.
Über die Usability der Netacademy lässt sich streiten, aber das Prinzip des
Modells ist klar: Sämtliche kostenpflichtigen elektronischen Inhalte werden über
das größere Portal abgewickelt. Dort sind die Dokumente durch die Suchfunk-
tion einer vermutlich größeren Nutzergruppe zugänglich. Zudem werden die
Bezahlungsmodalitäten weitgehend von Ingenta übernommen, was den admi-
nistrativen Aufwand verringert.
Die Suchfunktion ist simpel gehalten und erlaubt die freie Eingabe eines oder
mehrerer Begriffe. Die Ergebnisse lassen sich auf Dokumentarten einschränken.
3.3.2. SpringerLink
Hierbei handelt es sich um das Online Informationssystem des Springer Ver-
lages, der sich in erster Linie an den professionellen und wissenschaftlichen
Nutzer wendet und hochwertige Publikationen aus dem wissenschaftlichen und
wirtschaftlichen Umfeld verlegt.
Das SpringerLink Angebot des Verlages konzentriert sich ausschließlich auf
Produkte des Verlages. Es ermöglicht dem Leser, hochwertige wissenschaftliche
Journale online zu lesen. Zu diesem Zweck bietet SpringerLink eine ausgefeilte
Suchfunktion, sowie den Zugriff auf Abstracts und Inhaltsangaben der Publika-
10 WWW Adresse: http://www.ingentaselect.com

27 3.3. WISSENSCHAFTLICHE ANGEBOTE
tionen kostenfrei an. Volltexte werden ausschließlich kostenpflichtig für 35 USD
pro Artikel angeboten.
Es gibt keine Community Features, Experten Verzeichnisse o.ä.
3.3.3. ACM Portal
Die ACM ist bereits seit langer Zeit (1947 gegründet) in der Informatik eine
feste Größe. Sie nennt sich selbst eine Society, also eine Gesellschaft. Sie strebt
an, das wissenschaftliche Arbeiten im Computing-Sektor zu unterstützen und
bietet ihren Mitgliedern einiges an Unterstützung. Sie finanziert sich vermutlich
in erster Linie über die Mitgliedsbeiträge und ihre Publikationen, die sie ver-
legt und die, so wie zum Beispiel ihr Journal ” Communications of the ACM“,
weltweit höchste Anerkennung erlangt haben.
Das Angebot umfasst neben einer langen Liste selbstverlegter Journale und
Konferenzprotokolle den Zugang zu ausgewählten Büchern und Kursen für
Software-Entwickler und Studenten, die für zahlendes Publikum sogar im Voll-
text vorliegen. Die Bücher sind nicht herunterladbar, aber jederzeit online ein-
sehbar - jedenfalls solange die Subskription der ACM-Mitgliedschaft aktiv ist.
Es gibt jedoch auch Netzwerk-Lizenzen für Firmen und Universitäten, die es
erlauben, bestimmte IP-Bereiche freizuschalten, so dass alle Zugriffe aus den
jeweiligen Netzen heraus automatisch erlaubt sind. Die hiesigen Universitäten
nutzen dieses attraktive Angebot in der Regel auch. (Der Autor dieser Zeilen
ist dennoch ACM Mitglied, denn so hat er auch von zu Hause direkten Zugriff.)
Als besonders interessant im Kontext dieser Arbeit stellt sich das ACM Por-
tal 11 dar. Es handelt sich dabei um ein Informationssystem, welches den Zugriff
auf Publikationen des ACM mit Hilfe eines Such-Mechanismus erlaubt. Die-
ses Portal integriert zusätzlich den sogenannten ACM Guide, der das Angebot
auf Publikationen anderer Verlage ausdehnt. Laut ACM Angaben beinhaltet
der Guide bibliographische Daten von mehr als 800000 Publikationen, die von
wissenschaftlichen Anbietern weltweit angeboten werden. Die Integration dieser
weltweiten Quellen beschränkt sich auf die Erfassung und Verlinkung der Pu-
blikationen. Um auf die Volltexte Zugriff zu haben, muss der Nutzer mit dem
jeweiligen Anbieter Kontakt aufnehmen und zum Beispiel das Buch kaufen,
wenn es eines ist, oder auch eine kostenpflichtige Mitgliedschaft eingehen.
Der Suchmechanismus ist wie üblich zweigeteilt. Es gibt eine einfache Suche,
die für alle kostenlos benutzbar ist, und eine erweiterte Suche (siehe Abbildung
11 WWW Adresse: http://portal.acm.org

3.3. WISSENSCHAFTLICHE ANGEBOTE 28
Abbildung 3.4.: Erweiterte Suche im ACM Portal

29 3.4. TECHNISCH RELEVANTES
3.4) für den zahlenden Kundenkreis. Bei der Benutzung des Systems fiel bereits
auf, dass oft die erweiterte Suche nötig wurde, um die gewünschten Suchergeb-
nisse hinreichend exakt zu beschreiben. Besonders wichtig wird dieses Feature
in Zusammenhang mit der Beschränkung auf 200 ausgegebene Publikationen,
denn selbst wenn sich das gesuchte Dokument in der Liste befinden müsste, so
hat man doch erst darauf Zugriff, wenn es sich unter den ersten 200 befindet.
Um das zu garantieren, sind so exakte Suchanfragen nötig, die nur durch die
erweiterte Suche möglich sind.
Die erweiterte Suche ermöglicht wie in Abbildung 3.4 gezeigt, dass die Suche
gezielt auf einzelne Felder wie zum Beispiel Autorname, ISBN oder Titel be-
schränkt werden kann. Außerdem wird eine Klassifikation angeboten ( ” CCS“),
die die Dokumente thematisch in eine hierarchische Struktur einbindet und die
natürlich auch für die Suche verwendet werden kann.
Volltexte des ACM sind direkt über das Portal online als PDF zu bekommen,
sofern es sich um Journal-Artikel oder Konferenzprotokolle handelt. Bücher
sind nicht als Volltext vorhanden. Da das ACM sehr anerkannte Journale be-
sitzt und die Artikel durchweg von hoher wissenschaftlicher Qualität sind, sind
die Volltexte bei der wissenschaftlichen Auseinandersetzung mit informations-
technischen Themen unabkömmlich. Diese Volltexte stellen also einen deutlich
wahrnehmbaren Wert dar. Daher ist der Zugriff auf sie den zahlenden Kunden
vorbehalten.
Lange Rede kurzer Sinn: das Portal ist zwar zunächst gratis zu testen. Um
es aber wirklich effektiv und erfolgreich zu nutzen, benötigt man zwingend
eine kostenpflichtige vollwertige Mitgliedschaft. Die Gratisnutzung ist somit ein
Köder für Kunden, die durch die spielerische Erforschung des Gratisbereichs
des Portals einen Eindruck des Umfanges des Angebots bekommen können.
Dieses Vorgehen kann nach Ansicht des Autors auch für das ISL eine mögliche
Herangehensweise darstellen.
3.4. Technisch Relevantes
3.4.1. Clusty / Vivísimo
Die Firma Vivísimo stellt Clustering Software her, die sie (sicherlich nicht bil-
lig) unter der Bezeichnung Vivísimo Clustering Engine (VCE) anbietet. Eine
Besonderheit des Vorgehens ist, dass das Clustering on-the-fly ausgeführt wird.
Es gibt kein vollständiges Clustering des Datenbestandes. Stattdessen werden

3.4. TECHNISCH RELEVANTES 30
ausschließlich die Such-Ergebnisse einem Ad-Hoc Clustering unterworfen. Da
das System darauf ausgerichtet ist, die Ergebnisse einer Suchmaschine zu clu-
stern, betrachtet es Titel und Abstract, den Suchmaschinen üblicherweise au-
tomatisch liefern. Laut Vivísimo beinhaltet der Clustering Algorithmus zwar
keinerlei Vorwissen (Thesauri oder Ähnliches), wurde aber von den Entwick-
lern speziell darauf ausgerichtet Cluster zu erzeugen, die beachten, ” what users
wish to see when they examine clustered documents“ (vivisimo.com 12 ).
Zudem bietet sie ein Produkt namens Clusty 13 an. Dabei handelt es sich
um eine Meta-Suchmaschine, die verschiedene Suchmaschinen abfragt, deren
Ergebnisse sammelt und mittels VCE clustert. Interessanterweise fragt Clus-
ty nicht mehr nur gewöhnliche Suchmaschinen ab, sondern erlaubt zusätz-
lich die Suche in weiteren Quellen wie zum Beispiel einer Preissuchmaschine
(www.bizrate.com 14 ) oder einer Bildersuchmaschine (picsearch.com 15 ). Es exi-
stiert somit eine gemeinsame Oberfläche für die Suche in mehreren unterschied-
lichen Quellen. Hervorzuheben ist die Integration der Kategorisierung von biz-
rate.com. Bizrate hat die Produkte in Kategorien einsortiert, wie zum Beispiel
Men’s T-Shirts oder Women’s T-Shirts bei Shirts. Diese Kategorien zeigt es
zusätzlich zu den automatisch ermittelten Clustern an. Probier-Link 16
Mit Clusty lassen sich sehr einfach eigene Erfahrungen mit Clustering Ange-
boten sammeln. Das Vorgehen von Clusty wäre nach Meinung des Autors auch
für das ISL sehr interessant.
3.4.2. carrot 2
Dies 17 ist ein Programmierframework in Java, welches sich als Experimentier-
plattform in Bezug auf das Clustering von Suchergebnissen versteht. Daher
passt es sehr gut zur Zielsetzung der Arbeit und soll hier mit aufgeführt wer-
den. Der von carrot 2 verwendete Ansatz unterscheidet sich von dieser Arbeit
insofern, als dass dort für das Clustern ein eigener Algorithmus (LINGO) ver-
wendet wird. LINGO basiert auf einem durch LSI (siehe auch Abschnitt 5.3.4)
erzeugten approximierten Datenraum, der durch die drei Matrizen T S D T dar-
12
WWW Adresse: http://vivisimo.com/docs/howitworks.pdf
13
WWW Adresse: http://clusty.com
14
WWW Adresse: http://www.bizrate.com
15
WWW Adresse: http://picsearch.com
16
WWW Adresse: http://clusty.com/search?v%3aproject=clusty-shopping&query=
shirt
17 WWW Adresse: http://www.cs.put.poznan.pl/dweiss/carrot/

31 3.4. TECHNISCH RELEVANTES
gestellt wird. Dabei ist S eine diagonale Matrix (alle Werte auf 0, außer in der
Diagonalen), die die Singulärwerte enthält. Der Unterschied ist beim Finden
der Cluster am größten. Und zwar errechnet LINGO für jeden Singulärwert
einen dazu passenden Begriff, bzw. eine dazu passende Phrase (LINGO sucht
auch nach Begriffsgruppen). Jeder gefundene Begriff wird nun flugs zum Clu-
ster erklärt. Dann werden noch die Dokumente entsprechend ihrer Ähnlichkeit
zu diesen gefundenen Clustern jeweils einem dieser Cluster zugeordnet, fertig.
Das System macht einen sehr guten Eindruck und die Idee hinter LINGO
besticht ebenso durch ihre Einfachheit wie durch ihre Effektivität.

3.4. TECHNISCH RELEVANTES 32

Teil II.
Definition

4. Technische Analyse
4.1. Ist-Analyse
Ziel ist die Klärung der derzeitigen Situation im Kontext des Seabase Infor-
mationssystems. Identifikation des aktuellen Datenmodells, Definitionen von
existierenden Schnittstellen, Identifikation der beteiligten Software Komponen-
ten sowie insbesondere die Klärung, wie die Prozesse aktuell für Erfassung und
Recherche ablaufen.
4.1.1. Komponenten und Schnittstellen
Die beiden Systeme, die hauptsächlich zusammenarbeiten, um die Systemfunk-
tionalität bereitzustellen, sind die Software Faust und der Webserver, der eine
Apache+PHP Konfiguration nutzt.
Bei Faust handelt es sich um ein Datenbanksystem mit einfachen Dokumen-
tenmanagement Funktionen, das für den Einsatz in Bibliotheken und ähnli-
chen Einrichtungen, in denen bibliographische Objekte (Dokumente, Bücher,
Zeitschriften,. . . ) erfasst und verwaltet werden müssen, optimiert ist. Die Do-
kumenttypen sind sehr weitgehend flexibel definierbar; die für die Erfassung
benötigten Felder können frei benannt und angelegt werden. Es erlaubt Ver-
knüpfungen mit Online-Quellen und das Erfassen und Speichern beliebiger di-
gitaler Dokumente. Im ISL werden zwar die digitalen Dokumente sowie die
Online-Quellen nach und nach stärker ins Blickfeld gerückt, Literaturhinweise
auf Publikationen, die in der ISL-Bibliothek tatsächlich auch in Papierform vor-
handen sind, nehmen aber nach wie vor den größten Teil des Datenbestandes
ein.
Die Schnittstelle zwischen der auf PHP basierenden Suche und der Faust-
Datenbank definiert sich über eine Textdatei, die durch ein speziell entwickeltes
Makro aus Faust heraus produziert wird. Deren Format ist sehr simpel aufge-
baut. Es besteht aus einer Textzeile pro bibliographisches Objekt. Die Textzeile
wiederum ist wie folgt aufgebaut:

4.1. IST-ANALYSE 36
id Component Model
«artifact»
Logical Model::Export data
import script
«artifact»
Index data
FAUST system
Seabase
Abbildung 4.1.: System-Komponenten
«executable»
Logical Model::
Faust
search mask
Zeile ::= Feld1 "|" ... "|" Feldx "|" Deskriptoren
Deskriptoren ::= Deskriptor ";" Deskriptoren | Deskriptor
Sie besteht somit aus x durch | getrennten Feldern und einer Liste von durch
; getrennten Deskriptoren. Um welche Felder es sich handelt und in welcher
Reihenfolge diese jeweils in den Zeilen zu finden sind ist aus Tabelle 4.1 (Seite
40) und Tabelle 4.2 (Seite 41) ersichtlich.
Damit der Zugriff auf die Daten aus der Suche heraus performant ablau-
fen kann, wird diese Textdatei zunächst eingelesen, es werden die signifikanten
Informationen erkannt (Listen von Autoren, Deskriptoren,. . . ) und in für die
Suche optimierter Form abgelegt.
4.1.2. Prozesse
Es gibt im Wesentlichen zwei Hauptprozesse. Dabei handelt es sich zum einen
um den Prozess ” Erfassung“ und den Prozess ” Recherche“. Beide sind beim ISL

37 4.1. IST-ANALYSE
aktuell im Einsatz. Die Erfassung wird von Mitarbeitern des ISL durchgeführt.
Der Prozess Erfassung (Abbildung 4.2 (Seite 38), Anwendungsfälle sind grün,
Systemzustände sind rot dargestellt und produzierte Datenobjekte in blau) be-
ginnt, sobald ein neues Dokument im ISL angeschafft wird oder der Erfassungs-
bedarf anderweitig aufkommt, z.B. durch eigene Recherchen im Internet. Ein
solches Dokument wird zunächst inhaltlich intellektuell analysiert und erfasst.
Die Ergebnisse können dann in das Faust-System eingetragen werden. Dabei
wird unter anderem eine inhaltliche Zusammenfassung (auch Kurzreferat ge-
nannt) des Dokuments im System hinterlegt. Des weiteren werden bibliogra-
phische Informationen eingegeben und das Dokument in die Begriffshierarchie
des ISL (ISL-Thesaurus) eingegliedert.
Sofern sich hierbei der Bedarf ergibt, den Thesaurus zu erweitern, wird das
getan.
Am Ende eines Arbeitstages dann wird der vierte Anwendungsfall, der Ex-
port, angestoßen. Dieser besteht im Wesentlichen aus der Auswahl eines Makros
im Faust-System, welches selbständig eine Liste mit den bibliographischen In-
formationen in eine Textdatei schreibt, die für das online Suchformular zugängig
ist.
Die Kunden reagieren auf Informationsbedarf mit einer Suchanfrage, die sie
im online Suchformular eintragen. Dabei haben sie Zugriff auf eine Schlagwort-
liste sowie auf eine Liste aller verzeichneten Autoren. Siehe Darstellung des
Ablaufs, Abbildung 4.3 (Seite 39).
Die Suchmaske, zu sehen in Abbildung 4.4 (Seite 41), erlaubt die Eingabe von
Autor, Titel, zwei Schlagworten (Deskriptoren), Erscheinungsjahr, Sachgebiet
und der Bibliothekssignatur sowie zusätzlich eines Stichwortes, nach welchem
das System in den Zusammenfassungen sucht. Alle Eingaben sind mit UND
verknüpft.
4.1.3. Datenmodell
Das Datenmodell, welches sich letztlich online wiederspiegelt, wird durch den
Export-Vorgang aus der Software Faust heraus erzeugt. Es besteht für jede
Publikation aus einer langen Liste an Feldern mit ihren Werten und einer Liste
an zugehörigen Deskriptoren. Da die Deskriptoren als Liste exportiert werden,
sind die hierarchischen Beziehungen, die im Faust existieren, online nicht mehr
verfügbar und tauchen somit auch im Datenmodell nicht auf.
Siehe Tabelle 4.1 (Seite 40).

4.1. IST-ANALYSE 38
Thesaurus
aktualisiert
Ereignis
Information
Funktion
Publikation
V
Thesaurus
V
Legende
V
V
oder
und
Thesaurus
unzureichend
Thesaurus
erweitern
Datendatei
Neue
Publikation
liegt vor.
V
Zusammenfassung
und Klassifikation
erstellen
XOR
Geschäftsschluss
Abbildung 4.2.: Erfassungsprozess
Startereignis
V
Export anstoßen
Neue
Publikation
erfasst
Klassifikation
ermittelt
Daten in Faust
eintragen
Neue Daten
liegen in Faust
vor
Endereignis

39 4.1. IST-ANALYSE
Anfrage formulieren
Suchseite aufrufen
Suchbegriffe angeben
Anfrage beantworten
Datendatei auslesen
Ranking erzeugen
Dokument selektieren
Liste mit Dokumenten zeigen
Dokument auswählen
Created by Borland® Together® Designer Community Edition
Abbildung 4.3.: Rechercheprozess
Hauptsächlich manuelle
Aktivität. Nicht extra angegeben
aber dennoch vorhanden ist die
verfügbare
Hintergrundinformation wie der
Thesaurus sowie die Liste von
Autoren, die das Angeben von
Suchbegriffen erleichtert.
Zeigt den Ablauf auf dem
Server, der anhand der Anfrage
eine sinnvolle Antwort
erarbeiten muss.
Diese Aktivität ist wieder in
erster Linie manuell.

4.1. IST-ANALYSE 40
Bezeichner Typ Zweck
Titel Text Titel des Dokuments
Jahr Text Erscheinungsjahr
ND Text eindeutige Dokumentnummer, 8-stellig
DT Text Dokumenttyp (z.B. J für Journal)
LI Text Literature Indicator (z.B. S für Selbst. Einheit)
CODE Text 6-stelliger Zeitschriftencode (Dummy)
Land Text Erscheinungsland
ISSN Text International Standard Serial Number
ISBN Text International Standard Book Number
Sprache Text Sprache der Publikation
Sprache Kurzref. Text Sprache des Kurzreferats
Bd. Text Angabe einer Bandnummer
H. Text Angabe einer Heftnummer
S. Text Angabe einer Seitennummer
Abb. Text Anzahl Abbildungen
Tab. Text Anzahl Tabellen
Lit. Text Literaturangaben (Literaturzitate)
Sig. Text Signatur der Bibliothek
Auswerter Text Mitarbeiter inhaltliche Erschließung
Erfasser Text Mitarbeiter Formalerschließung
PLZ Text Postleitzahl des Verlags
PZB Text Postzustellbezirk
Ländercode Text Land des Erscheinens
Sachgebiete Text Liste zugehöriger Sachgebiete
Titelübersetzung Text Titelübersetzung des Originaltitels
Titelanmerkung Text Titelanmerkung (z.B. Special Report)
Verfasser Text Der Verfasser (eine Person)
Korp. Verfasser Text Herausgebende Korporation oder Institution
Herausgeber Text Name des Herausgebers
Zeitschriftentitel Text Titel der Zeitschrift
Tabelle 4.1.: Dataobject

41 4.1. IST-ANALYSE
Bezeichner Typ Zweck
Abbildung 4.4.: Screenshot der Suchmaske
Erscheinungsort Text Erscheinungsort
Übergeord. Publ. Text Name der Publikation, die das Objekt beinhaltet
Verlag Text Name des Verlages
Ort Text Ort des Verlages
Str./Postf. Text Adresse des Verlages
ID-Nr Text unbekannte Nr
Freie Begriffe Text Schlagworte, die nicht im Thesaurus vorkommen
Kurzreferat Text Kurze Zusammenfassung des Inhalts
URL Text Bei online Dokumenten dessen URL
Tabelle 4.2.: Dataobject (Fortsetzung)

4.1. IST-ANALYSE 42
4.1.4. Einschränkungen
Das oben genannte Vorgehen ist etwas limitiert - alleine schon dadurch, dass die
Klassifikation aus dem Literaturerfassungssystem Faust nicht vollständig expor-
tiert wird. Der Export wird mithilfe eines Makros durchgeführt. Dieses Makro
kann mithilfe eines Faust-spezifischen Basic Dialekts entwickelt werden. Dabei
ist man natürlich generell der Mächtigkeit der API unterworfen, die Faust den
Basic Programmen bietet. Wie aus der Dokumentation der API zu entnehmen
ist, erlaubt die Sprache das Extrahieren genau eines Oberbegriffes zu einem
gefundenen Deskriptor. Falls der Thesaurus die Möglichkeit der Polyhierarchie
(das heißt, dass ein Begriff mehrere Oberbegriffe haben und somit zu mehreren
Begriffs-Klassen gleichermaßen gehören kann) nutzt, geht diese beim Export
verloren.
Gewöhnliche Hierarchien dagegen sind jedoch im Prinzip vollständig expor-
tierbar, da Faust Basic durch die Befehle desc down und desc next das Traver-
sieren der Unterbegriffe eines Begriffes erlaubt. Derzeit wird diese Möglichkeit
jedoch nicht genutzt.
Ein gebräuchliches Mittel, die Recherche in Informationssystemen zu erleich-
tern, sind sogenannte Synonymringe. Ein solcher Ring besteht aus einem Haupt-
begriff, unter welchem die Dokumente erfasst werden, und mehreren Synony-
men. Diese Synonyme können dann in der Suche anstatt des eigentlichen Begrif-
fes verwendet werden. Das ist deswegen hilfreich, weil verschiedene Menschen
mit verschiedener Vorbildung und einem unter Umständen auch unterschiedli-
chem Kulturkreis, andere Begriffe für die selbe Sache verwenden. Sofern also
bekannt ist, dass Dinge unterschiedlich benannt werden können, so macht es
Sinn, diese unterschiedlichen Benennungen als Synonym im System zu hinterle-
gen. Faust Basic erlaubt das Extrahieren genau eines Synonyms. Sind mehrere
Synonyme hinterlegt, wird nur das erste ausgelesen. Derzeit werden gar keine
Synonyme ausgelesen.
Betrachtet man das System aus der Sicht der Nutzer, fällt einem zunächst
auf, dass . . .
• . . . offenbar die Felder Stichwort und Deskriptor gleichermaßen nach in-
haltlichen Kriterien selektieren, während die genaue Wirkungsweise un-
klar bleibt. Die Angabe eines Sachgebietes stellt sogar die dritte Möglich-
keit dar, wobei diese nur sehr grob selektiert.
• . . . um Deskriptoren für die Suche verwenden zu können, der Suchende die

43 4.2. PROTOTYP
verfügbaren Deskriptoren kennen muss. Dazu wird eine Liste angeboten,
die die Deskriptoren alphabetisch sortiert anzeigt. Diese Liste beinhal-
tet eine ganze Reihe sehr spezieller Begriffe und ist sehr umfangreich.
Benutzer müssen sich folglich durch die langen Listen arbeiten und dort
passende Begriffe wählen. Der Autor findet den Prozess aufwändig und
abschreckend.
• . . . die Signatur den meisten Kunden unbekannt sein dürfte, da sie die
Erfassungsmethodik der ISL-Bibliothek wiederspiegelt und deren Kennt-
nis voraussetzt. Somit werden sie das gleichnamige Feld kaum ausfüllen
können und es kann genau so gut entfernt werden, um das Formular über-
sichtlich zu halten.
• . . . keine Volltextsuche existiert.
• . . . viele andere Felder des Datenmodells in der Suchmaske nicht angebo-
ten werden.
4.2. Prototyp
Zur Erinnerung: es soll ein Clustering Konzept dargestellt werden, mit dessen
Hilfe die Suche im System qualitativ verbessert werden kann. Dadurch soll es
möglich sein, die Struktur von Suchergebnissen besser zu überblicken und sich
aus der (eventuell sehr großen) Menge an Ergebnissen diejenigen zu selektieren,
die am ehesten in Frage kommen.
4.2.1. Oberflächenprototyp
Zunächst soll ein Modell der Benutzerschnittstelle zur Diskussion gestellt wer-
den. Dies geschieht, um frühzeitig zu demonstrieren, wie sich Abläufe und De-
signs letztendlich in einem fertigen Produkt wiederspiegeln können. Da in den
Gesprächen mit dem ISL häufig erwähnt wurde, dass Personalisierung ein The-
ma ist, wurde dies in dem nun folgenden Vorschlag mit eingebaut.
Abbildung 4.5 zeigt also einen Vorschlag, wie sich Clustering für den Benut-
zer darstellt. Dieser Vorschlag beinhaltet ein flaches Clustering der Dokumente
(keine hierarchischen Cluster). Im Folgenden werden die durch nummerierte
gelbe Kreise markierten Bereiche näher erläutert (die Nummer entspricht dem
Platz in der folgenden Aufzählung).

4.2. PROTOTYP 44
Abbildung 4.5.: Recherche-Formular
1. Dieser Block beinhaltet die für die Arbeit wesentlichen Ergebnisse, nämlich
die ermittelten Cluster. Es werden all die Cluster aufgelistet, dessen Do-
kumente sich in der Ergebnisliste wiederfinden. Dieser Block erlaubt so-
mit, die Ergebnisliste durch Mausklick (die Namen sind aktive anklickbare
Elemente) auf die Dokumente des gewählten Clusters einzuschränken. Ein
ähnliches Prinzip nutzt die Suchmaschine Clusty. Siehe auch S. 29 und S.
30.
2. Der Aktionskasten beinhaltet die Möglichkeiten, die der Nutzer hat. Alle
Aktionen beziehen sich direkt auf die Ergebnisliste bzw. die selektierten
Dokumente der Liste. Anzeigen führt dazu, dass die ausgewählten Do-
kumente in einer Detail-Ansicht dargestellt werden. Diese Funktionalität
besitzt das aktuelle System bereits in ähnlicher Form. Speichern soll dem
Nutzer erlauben, die ausgewählten Dokumente zu sichern. Damit dies
möglich ist, muss die Web Site personalisierbar sein, denn die Funktion
setzt voraus, dass sich der Nutzer in sein Profil einloggen kann und die
gewählten Dokumente dort in seinem Profil als Verweise hinterlegt wer-
den. Drucken dagegen entspricht im Wesentlichen der Funktion Anzeigen,
mit dem einzigen Unterschied, dass die Anzeige zum Beispiel in einem neu-
en Fenster auf eine Weise passiert, die für das Ausdrucken optimiert ist.

45 4.2. PROTOTYP
Abbildung 4.6.: Verweis auf ähnliche Dokumente
Der Druck-Dialog des Browsers öffnet sich automatisch.
3. Das Suchformular ist der Google-Suche nachempfunden worden, da in ei-
nem vorhergehenden Gespräch signalisiert wurde, dass die Art und Weise,
wie Google das Formular aufbaut, als sehr angenehm verständlich emp-
funden wurde. Man besitzt auf diese Weise eine sehr intuitive Möglich-
keit, Suchbegriffe mit Hilfe boolscher Logik zu kombinieren, ohne dass
eine spezielle Anfragesyntax notwenig würde. Möchte der Nutzer jedoch
eher nach bibliographischen Gesichtspunkten detailliert nach Autoren, Er-
scheinungsdatum, Verlag o.ä. suchen, so führt ihn der Verweis Erweiterte
Suche zu einem entsprechend komplexeren Suchformular.
4. Die Ergebnisliste ist entsprechend der Angabe im Suchformular auf eine
bestimmte Anzahl an Einträgen beschränkt. Sollte die Menge an Ergeb-
nissen die Anzahl übersteigen, kann der Nutzer hier die anzuzeigende Seite
auswählen und auf diese Weise in der Ergebnisliste blättern.
Um den obigen Vorschlag noch etwas zu erweitern, ließe sich für jedes einzelne
gefundene Dokument der dazugehörige Cluster anzeigen, bzw. alle Dokumente
des Clusters. In Abbildung 4.6 wird die Zeile mit einem Pfeil markiert, die den
Verweis auf den Cluster beinhaltet.
4.2.2. Prozess: Cluster erzeugen
Dieser Vorgang soll Cluster in der Datenbank anlegen, so dass jedem Cluster
eine Reihe von Dokumenten zugeordnet sind. Er teilt sich in Aktivitäten auf,
die denen des KDD Prozesses (siehe Abschnitt 5.2) entsprechen. Die folgenden
Absätze beschreiben also diesen Vorgang und entsprechen jeweils einem Ab-

4.2. PROTOTYP 46
nächstes
Dokument
Erfasser
nein
Analyse
Selektion Analyse Transformation Cluster
«realize»
Dokument analysieren
fertig?
«realize»
ja
Selektion
Dokumente
analysiert
Export aus Faust Import in Seabase DB Anfrage
Cluster
Cluster erkennen Cluster prüfen
Parameter anpassen
nein
Abbildung 4.7.: Clustering Prozess
ok?
«realize»
ja
Interpretation
Cluster speichern
schnitt des besagten KDD Prozesses. Abbildung 4.7 (Seite 46) zeigt den Ablauf
in einem UML Aktivitätsdiagramm.
Selektion ist der erste Teil von KDD. In S. 46 ist es die gleichnamige Aktivität
ganz zu Beginn. Er besteht aus den Export- und Import-Vorgängen, durch die
der Datenbestand des Systems aktualisiert wird, sowie aus dem Selektionsvor-
gang, der die zu clusternden Daten auswählt.
Preprocessing entspricht dem Extrahieren von wesentlichen Merkmalen der
Datensätze (Feature Selection) und läuft im Diagramm unter der Bezeichnung
” Analyse“. (Siehe auch Abschnitt 5.3.3.) Ergebnis dieser Aktivität ist eine Liste
von Features, die sich als Beschreibung von Datensätzen tauglich erwiesen
haben. Zudem wurden die Dokumente bereits auf der Basis dieser Features sta-
tistisch ausgewertet, so dass am Ende dieses Schrittes zum Beispiel alle nötigen
Statistiken vorliegen.
Transformation nennt sich jener Schritt, der die Daten für die Cluster Analyse
so vorbereitet, dass der Algorithmus die Daten in einem für ihn passenden

47 4.2. PROTOTYP
Format bekommt. Da der gewählte Ansatz auf dem Vektorraummodell (S. 56)
basiert, besteht das Ergebnis aus einer Menge von Dokument-Vektoren, die
insgesamt die Term-Dokument-Matrix darstellen.
Data Mining heißt der vierte KDD Schritt, der hier der Aktivität ” Cluster“
entspricht. Der Algorithmus nimmt die Vektoren als Eingabe und erzeugt eine
Reihe von Clustern. Die Anzahl der Cluster wird jedoch fest vorgegeben. Diese
Aktivität setzt voraus, dass die Qualität der Cluster überprüft wird, so dass
die Möglichkeit besteht, die Clusteranzahl anzupassen und den Algorithmus
mit diesem geänderten Parameter erneut laufen zu lassen. Es ist noch nicht
ersichtlich, wie die Laufzeit des Algorithmus sein wird. Er hat prinzipiell eine
exponentielle Laufzeitcharakteristik, so dass zu erwarten ist, dass er bei großen
Datenmengen sehr lange dauert. Dadurch könnte es sich als hilfreich erweisen,
wenn diese Zyklen manuell gesteuert werden können, damit nach Ermessen
der zuständigen Person die Struktur vorzeitig als ” ausreichend optimal“ erklärt
werden kann. Es gilt hier, ein Gleichgewicht zwischen Laufzeit (Geduld) und
Qualität herzustellen.
Interpretation wird die letzte Aktivität genannt. Sie besteht darin, Namen für
die Cluster zu vergeben, die die durch sie repräsentierten Dokumente thematisch
am besten identifizieren. Es bietet sich hier an, Begriffe aus dem Thesaurus
zu verwenden. Ergebnis dieses letzten Schrittes sind eine Liste von benannten
Clustern und deren zugeordneten Dokumenten.
4.2.3. Datenmodell
Die im System abzulegenden Informationen umfassen die Dokumente und Au-
toren sowie Terme (Deskriptoren), wie sie aus dem Faust exportiert wurden.
Im Diagramm sind aus Gründen der Übersicht nicht alle Attribute angegeben,
sondern nur die für die Cluster-Analyse Wesentlichen (welche Felder insgesamt
vorhanden sind, wurde ja bereits in der Ist-Analyse oben aufgelistet).
4.2.4. Komponenten und Schnittstellen
Das System besteht zum einen natürlich aus der Faust-Software, die vom ISL für
die Erfassung von Dokumenten verwendet wird. Diese Software exportiert wie
im Diagramm angegeben seinen Datenbestand, der von einer Import-Komponente
eingelesen wird.
Im Hintergrund des Ganzen steht eine SQL Datenbank; diese wird von der

4.2. PROTOTYP 48
parent
Writes all imported and
infered data into a SQL
database, which can be
used by client software
afterwards, to make use
of the cluster data.
Cluster
- name: String
relatesTo
Descriptor
- name: String
- language: char[2]
«artifact»
Export data
Importer
Data Access
Analyzer
belongsTo
Document
writtenBy
- faustId: int
- abstract: String
- title: String
- subject: List
Abbildung 4.8.: Datenstruktur
FAUST system
SeaCLUSTER core
Transformer
«executable»
Faust
Finds names for
the clusters.
Abbildung 4.9.: System-Komponenten
Author
- firstName: String
- lastName: String
Feature
Indexer
Interpreter
Clusterer
Produces an Index for
selected fields, to allow
potential search
applications to access
the clustering data in a
quick and optimized
manner.

49 4.2. PROTOTYP
Data Access Komponente kontrolliert. Auf welche Weise der Zugriff passieren
soll, ist an dieser Stelle offen gelassen. (Auf jeden Fall sollte es möglich sein,
PostgreSQL als Datenbanksystem zu verwenden. Das ist bei der Wahl zu be-
denken.) Das eigentliche Clustering findet in der Analyse Komponente statt,
die alle für die Analyse des Datenbestands nötigen Algorithmen beherbergt.
Der Indexer baut aus den Inhalten der Datenbank einen Index auf, der
Grundlage für zu beantwortende Suchanfragen wird. Der Clusterer ermittelt
die Cluster und legt ihre Repräsentation in der Datenbank ab. Der Analyzer
ermittelt für die Inhalte der Datenbank passende Features. Siehe dazu auch
Abschnitt 5.3.3 (Seite 59).

4.2. PROTOTYP 50

5. Wissenschaftliche Analyse
Es ist geplant, einen Clustering Algorithmus einzusetzen, um die Suche in den
Daten des ISL effektiver zu gestalten. Die Zielsetzung findet sich im Forschungs-
bereich Information Retrieval wieder, der in diesem Kapitel zunächst erläutert
werden soll. Zudem sollen alternative und/oder einfachere Methoden aufgezeigt
werden, die ebenfalls zur Verbesserung einer Suchfunktion beitragen können.
Clustering ist eben bei weitem nicht die einzige Methode, so etwas zu erreichen.
Weil die Erwähnung des Begriffs häufig Assoziationen hervorruft, die hier
nicht passen, sei eine Erläuterung des Begriffs eingeschoben. Der Begriff ” Clu-
ster“ wird in den unterschiedlichsten Kontexten verwendet. Cluster in der Wirt-
schaft werden als Verbände von Betrieben verstanden, in der Astronomie ver-
steht man unter Clustern Sternhaufen und auch die Physik und die Mathematik
verwenden jeweils eigene Bedeutungen des Begriffs. All diese Begriffe haben je-
doch eines gemeinsam: sie beschreiben die Gruppierung von etwas. Sei es von
Betrieben in der Wirtschaft oder von Sternen in der Astronomie oder gar von
Computern in der Informationstechnik, in jedem Fall handelt es sich um eine
Gruppierung oder Anhäufung von gleichartigen Dingen.
In dieser Arbeit soll Clustering für die Gruppierung von Dokumenten stehen.
Die erzeugten Gruppen lassen sich auch als Klassen von Dokumenten betrach-
ten. Die Vorgehensweise passt sich in das Forschungsfeld ” Information Retrie-
val“ ein und wird ebenfalls im Bereich ” Knowledge Discovery from Databases“
(KDD) [FPSS96] eingesetzt. Daher sollen diese beiden Felder kurz vorgestellt
werden.
5.1. Information Retrieval
Der Forschungsbereich ” Information Retrieval“ (kurz: IR) existiert in der In-
formatik bereits seit vielen Jahren. Das Buch von van Rijsbergen mit dem Titel
” Information Retrieval“ [VR79] kam beispielsweise in der ersten Ausführung
bereits 1975 heraus und die Inhalte der Thematik wurden schon vorher in Uni-

5.1. INFORMATION RETRIEVAL 52
versitäten gelehrt. Van Rijsbergen identifiziert die 1940er Jahre als die Zeit, in
der man begann, dem IR mehr Aufmerksamkeit zu schenken. Es handelt sich
also um eine Problematik, die sehr lange schon eine gewisse Wichtigkeit in der
Informatik erlangt hat und die diese nie wirklich verloren hat. Besonders seit
dem Aufkommen des Internet und den Suchmaschinen, die oft eher schlecht
als recht Dokumente aus den schier unendlichen Dokumentenmengen fischen
können, ohne die heute aber niemand auskommen könnte, hat das Thema IR
neuen Auftrieb bekommen.
IR beschäftigt sich in der Hauptsache damit, mit welchen Mechanismen sich
am besten Informationen (insbesondere Dokumente) auffinden lassen. Insbeson-
dere findet sich in der Literatur ([VR79]) die Unterscheidung, dass IR Systeme
keine Antworten, die das gesuchte Wissen direkt beinhalten, geben, sondern
ausschließlich Hinweise darüber liefern, in welchen Dokumenten jenes am wahr-
scheinlichsten zu finden sein wird. Somit sind die heutigen Suchmaschinen wie
Google, Overture oder Fireball eigentlich ganz klassische IR Systeme.
Van Rijsbergen teilt den Bereich IR in drei Teilbereiche auf, die sich für IR als
besonders wesentlich herausgestellt haben. Das sind zum einen die inhaltliche
Analyse, zum anderen die Informationsstruktur und als drittes die Bewertung.
Der erste Teilbereich ” Analyse“ beschäftigt sich damit, sinnvolle Repräsentatio-
nen (siehe auch S. 56) von Dokumenten zu finden, die von Computern verarbeit-
bar sind. Dies ist deshalb ein wichtiger Aspekt, weil die hier betrachteten Doku-
mente zum größten Teil von Menschen für Menschen geschrieben wurden und
folglich in einer natürlichsprachlichen Form vorliegen. Diese natürlichsprachli-
che Form dem Computer verständlich zu machen, ist nach wie vor unmöglich.
Es gibt sehr viele ambivalente Konstrukte in der Sprache, deren Bedeutung
sich dem menschlichen Leser erst im Kontext erschließt und mitunter aktuelles
Hintergrundwissen verlangt. Dies ähnelt in gewisser Weise ” Insider-Witzen“,
über die nur Personen mit gleichem Hintergrundwissen lachen können. Nichts-
destotrotz gibt es durchaus Bestrebungen, Texte linguistisch zu erfassen und
Satzkonstrukte zu erkennen. (An dieser Stelle schneidet sich das Fachgebiet In-
formation Retrieval mit dem der Computerlinguistik. Es lohnt sich somit, inter-
disziplinär vorzugehen.) Trotz aller Bemühungen und auch trotz aller Erfolge in
dem Bereich hat es noch immer wenig damit zu tun, dass der Computer nun den
Text ” verstehen“ könnte, so wie es ein Mensch täte. Das Ziel der Bemühungen
ist es stattdessen, den Text so zu strukturieren, dass er sich für eine automa-
tisch durchgeführte Auswertung eignet. Dabei werden Informationen aus dem

53 5.1. INFORMATION RETRIEVAL
Text extrahiert und in formelle Strukturen überführt. Diese Methoden bauen
eine Statistik über die verwendeten Begriffe auf und schlussfolgern auf der Basis
dieser Statistik. Sie sind damit zum Beispiel in der Lage, eine Wahrscheinlich-
keit zu errechnen, nach der das ausgewertete Dokument mit einer Suchanfrage
(oder anderen Dokumenten im Fundus) korreliert.
Der zweite Teilbereich, die Informationsstruktur, basiert auf dem Gedanken,
dass die unterschiedlichen Dokumente in irgend einer Form in Beziehung zu-
einander stehen. Zum Beispiel können sie thematische Ähnlichkeiten aufweisen,
vom selben Autor verfasst worden sein oder eine andere Eigenschaft aufweisen,
die sie in Beziehung stellt. Selbst die Erkenntnis, dass zwei Dokumente keinerlei
Ähnlichkeiten aufweisen, stellt eine Art von Beziehung dar.
Zu guter Letzt ist eine Metrik von Nöten, die es ermöglicht, dass verschie-
dene Methoden bewertet und verglichen werden. Es stellt sich die Frage, auf
welcher Basis die Effektivität eines IR Systems gemessen werden kann. Diese
Frage konnte bereits 1966 von Cleverdon (siehe auch [CMK66]) beantwortet
werden, der einen Katalog von mehreren Kriterien aufgestellt hatte, mit deren
Hilfe Informationssysteme bewertet werden können. Van Rijsbergen erklärt,
dass von den ermittelten Kriterien nur precision und recall für die Effektivität
von IR Systemen ausreichende Aussagekraft besitzen, weshalb sich die IR com-
munity auf diese beiden beschränkt. Precision gibt das Verhältnis zwischen der
Anzahl von tatsächlich relevanten Dokumenten und der Anzahl der insgesamt
ermittelten Dokumente an. Eine Precision von 1 hieße demnach, dass alle im
Rahmen einer Suchanfrage ermittelten Dokumente tatsächlich relevant wären,
während ein Wert von 0 dafür stünde, dass kein Dokument der Ergebnismenge
relevant wäre. Das zweite Kriterium, Recall, beschreibt das Verhältnis zwischen
der Anzahl relevanter Dokumente in der Ergebnismenge und der Anzahl rele-
vanter Dokumente im System insgesamt. Ein Wert von 0 hieße demnach, dass
von allen relevanten Dokumenten keines ausgegeben worden wäre und ein Wert
von 1 hieße, dass sich im Gegenteil sämtliche relevanten Dokumente in der
Ausgabemenge befänden.
Abbildung 5.1 zeigt, welche Kombinationen aus Ergebnissen und dessen Re-
levanz möglich sind. Diese einzelnen Mengen zueinander in Beziehung gesetzt
ergibt eine ganze Reihe mehr oder weniger sinnvolle Maßzahlen, von denen Pre-
cision und Recall jeweils eine ist. Als Beispiel sei an dieser Stelle noch zusätzlich
der Wert mit der Bezeichnung Fallout definiert, der die gegensätzliche Bedeu-
tung hat, wie Recall. Er ist 1, wenn alle existierenden unrelevanten Dokumente

We now leave the speculations about relevance and return to the promised detailed discussion of
the measurement of effectiveness. Relevance will once again be assumed to have its broader
meaning of 'aboutness' and 'appropriateness', that is, a document is ultimately determined to be
relevant or not by the user. Effectiveness is purely a measure of the ability of the system to
satisfy the user in terms of the relevance of documents retrieved. Initially, I shall concentrate on
measuring effectiveness by precision and recall; a similar analysis could be given for any pair of
equivalent measures.
5.2. KNOWLEDGE DISCOVERY IN DATABASES 54
It is helpful at this point to introduce the famous 'contingency' table which is not really a
contingency table at all.
RETRIEVED
NOT RETRIEVED
RELEVANT NON-RELEVANT
A ∩ B
A ∩ B
A ∩ B
A ∩ B
A A N
(N = number of documents in the system)
Abbildung 5.1.: Tabellarische Darstellung aus [VR79]
zurückgeliefert wurden; und er ist entsprechend 0, wenn kein unrelevantes Do-
kument zurückgeliefert wurde.
precision =
recall =
fallout =
|A ∩ B|
|B|
|A ∩ B|
|A|
� �
� �
�A ∩ B�
� �
� �
�A�
In aktuellen Forschungsbeiträgen werden die beiden Werte häufig kombiniert
und in eine Bewertungsfunktion überführt, die den beiden Werten jeweils eigene
Prioritäten gibt, wie es beispielsweise bei einem gewichteten Mittel der beiden
Werte der Fall ist. Wie die Gewichtungen verteilt werden, hängt stark von der
Domäne, sprich den vorhandenen Dokumenten und deren Struktur, ab.
Diese Arbeit beleuchtet nun hauptsächlich den zweiten Teilbereich des IR,
der sich um die Beziehungen der Dokumente untereinander kümmert.
5.2. Knowledge Discovery in Databases
Bei KDD, wie von Fayyad et. al [FPSS96] vorgeschlagen, handelt es sich um
einen Prozess, der darauf abzielt, Muster in Datenmengen zu erkennen. Die Mo-
tivation dazu ergibt sich daraus, dass diese Datenmengen immer größer werden,
und dass auch Dank des Internets und der globalen Vernetzung der Zugriff auf
diese Daten sehr wichtig geworden ist. In der Zeit des Dotcom-Booms hieß es,
nicht der Große fresse den Kleinen, sondern der Schnelle den Langsamen. Dies
ließe sich ohne weiteres auch so umdichten, dass der Wissende den Unwissen-
den frisst. Korrekte und aktuelle Informationen zu besitzen ist also ein Wettbe-
B
B

55 5.2. KNOWLEDGE DISCOVERY IN DATABASES
Abbildung 5.2.: KDD Prozess von Fayyad et al.
werbsvorteil. Leider genügt es dazu nicht, haufenweise Rohdaten zu sammeln,
denn am Ende muss ein Mensch diese Daten interpretieren können.
Große Mengen Rohdaten zu interpretieren und dort befindliche Zusammenhänge
zu erkennen, dies ist das Ziel von KDD Prozessen. Im Unterschied zum Informa-
tion Retrieval suchen KDD Prozesse explizit nach Wissen und nicht nur nach
Dokumenten, die (mit einer bestimmten oder unbestimmten Wahrscheinlich-
keit) das Wissen enthalten.
Abbildung 5.2 (Seite 55) zeigt den Prozess. Der für den Prozess wichtig-
ste Schritt ist das Data Mining. Die Schritte vorher haben zur Aufgabe, die
Daten zu selektieren und vorzubereiten, damit die Data Mining Algorithmen
überhaupt eine passende Eingabe bekommen, und danach steht nur noch der
Schritt Evaluation.
Der erste Schritt Selektion soll darstellen, dass es zunächst notwendig ist,
aus den Datenmengen eine Auswahl zu treffen, die die zu analysierenden Daten
enthält. Welche Daten in die Analyse mit einbezogen werden kann durchaus
starke Auswirkungen auf die Ergebnisse haben. Wenn wichtige Informationen
ignoriert werden, sind die Ergebnisse möglicherweise nicht repräsentativ, und
wenn zu viele unwichtige Daten mit einbezogen werden, können die Ergebnisse
verfälscht werden und Aspekte anzeigen, die für den Anwendungsfall uninteres-
sant sind. Zudem steigt häufig die Laufzeit der Algorithmen je nach Größe der
Eingabemenge, so dass schon aus rein technischen Gründen eine Eingrenzung
der Eingabe sinnvoll wird.
Danach kann es nötig sein, die Daten im Schritt Preprocessing zu säubern

5.3. REPRÄSENTATION VON DOKUMENTEN 56
oder zu konsolidieren. Beispielsweise gehört dazu, unvollständige oder fehlerhaf-
te Daten zu erkennen und zu entfernen. Auch können an dieser Stelle Summen
gebildet werden, falls diese für den Anwendungsfall anstatt der eigentlichen
Daten interessant sind. In jedem Falle wird hier bereits auf simple Weise ein
bereinigtes Modell der Daten erzeugt, das der nächste Schritt als Eingabe ver-
wendet.
Dabei handelt es sich um den Schritt Transformation. Er ist notwendig, weil
der Algorithmus üblicherweise Daten in einem speziellen, für den Ablauf des
Algorithmus optimalen, Format benötigt, in das die vorhandenen Daten erst
gewandelt werden müssen.
Der Algorithmus selber wird durch den darauf folgenden Schritt Data Mi-
ning dargestellt. Hier konzentriert sich das Forschungsinteresse, da die ande-
ren Schritte mit wohlbekanntem Programmierhandwerk ohne größere Probleme
durchgeführt werden können. Die Probleme in den obigen Schritten sind eher
organisatorischer Natur (es müssen gut ausgebildete Mitarbeiter existieren, die
nicht nur technisches sondern auch fachliches Know-how besitzen). Daten um-
zuwandeln ist beispielweise eine inzwischen sehr gut beherrschte Anforderung
an Computersysteme. Data Mining Algorithmen dagegen sind häufig mit kom-
plexer Mathematik ausgestattet und lassen sich in das vergleichsweise neue
Forschungsfeld der Künstlichen Intelligenz (KI) einordnen (kommerziell erfolg-
reiche Anwendungen ca. seit Mitte der 1980er Jahre 1 ).
Der letzte Schritt nach dem Data Mining steht für die Interpretation bzw.
Auswertung der Ausgaben des Algorithmus. Diese kann beispielsweise darin
münden, dass die Ausgaben als neue, stärker abstrahierte Daten in der Daten-
bank abgelegt werden, die später in anderen Prozessen Anwendung finden. Es
könnte jedoch ebenso eine Art Report erzeugt und präsentiert werden.
5.3. Repräsentation von Dokumenten
Auf dem Weg zu Dokumenten-Clustern stehen wir zunächst der Frage ge-
genüber, auf welche Weise die vorliegenden Dokumente im System repräsen-
tiert werden, so dass die inhaltlichen Aspekte vergleichbar werden. Hier gibt
es einige Ansätze, die von sog. Word-Bags bis hin zu linguistischen Systemen
reichen. In den meisten Fällen wird für die Repräsentation der Dokumente das
Vektorraummodell (Vector Space Model, VSM) verwendet. Dies basiert letzt-
1 Seite 24 in [RN95]

57 5.3. REPRÄSENTATION VON DOKUMENTEN
endlich auf der Idee, die Dokumente jeweils als multidimensionale Vektoren
darzustellen.
Definition: Eine Dimension des Vektors wird Feature genannt. Denn jede
Dimension beschreibt eine Eigenschaft des Dokuments auf eine zunächst nicht
näher spezifizierte Weise.
Definition: Im Vektorraummodell repräsentiert der Vektor v ein Dokument
d aus der Menge aller Dokumente D auf der Basis von n ausgewählten Features
wie folgt:
5.3.1. Einordnung in Situation des ISL
v(d) = {f1, . . . , fn} , d ∈ D (5.1)
� �� �
nfeatures
Im Falle des ISL existiert eine manuell angelegte Klassifikation auf der Basis
eines multihierarchischen Thesaurus sowie einer groben Einteilung in Sachge-
biete. Dokumente werden klassifiziert, indem sie eine Kombination an Begriffen
aus dem Thesaurus sowie ein Sachgebiet zugewiesen bekommen. Eine Klasse
definiert sich also durch die Kombination aus Begriffen sowie aus dem Sachge-
biet.
Um dies formell darzustellen sei nun K die Menge aller Klassen, S die Menge
aller Sachgebiete, D die Menge aller Dokumente und T die Menge aller Terme.
Dann lässt sich eine Funktion desc definieren, die beschreibt, welche Begriffe
aus T einem Dokument D zugeordnet werden. Und mit der Hilfe von desc lässt
sich die Menge K wie folgt definieren.
P(T ) = {X|X ⊆ T }
desc : D → P(T )
K = {(X, s)|s ∈ S, X ∈ P(T ) ∧ ∃d ∈ D, desc(d) = X} (5.2)
Die folgenden Abschnitte verwenden die hier eingeführten Bezeichnungen S,
T, D und K für die jeweilige dargestellte Problematik.
5.3.2. Das Dokument als Wortsack (aka word-bag)
Ein Text besteht aus der Menge seiner Worte. Auch wenn diese Erkenntnis
zunächst äußerst naiv klingt, so ist selbst daraus eine einfachste Repräsenta-
tion eines Dokuments möglich. In diesem einfachsten Falle ist jedem Wort ein

5.3. REPRÄSENTATION VON DOKUMENTEN 58
Feature zugeordnet. Ein Feature beschreibt dann für ” sein“ Wort die Häufigkeit
dessen Auftretens im Text. Dies folgt dem Gedanken, dass Begriffe, die häufig
vorkommen, eher dem Inhalt des Textes entsprechen als solche, die nur selten
oder gar nie im Text vorkommen. Dieser Logik folgend entsprechen Features,
die für ein bestimmtes Dokument mit einem hohen Wert ausgestattet sind,
besonders gut dem Inhalt dieses Dokuments.
Luhn [Luh58] fügt dieser Idee noch eine weitere hinzu. Und zwar schlägt
er vor, zusätzlich noch die relative Position der Wörter im Satz zu bewerten
und somit eine kombinierte Bewertung von Begriffen zu verwenden. Das ließe
sich zum Beispiel so umsetzen, dass sich benachbarte Begriffe gegenseitig Boni
geben. Dadurch erhöht sich die Bewertung eines Begriffs allein dadurch, dass
es neben einem stark bewerteten Begriff steht.
In der Praxis werden vor der statistischen Verarbeitung die betrachteten Wor-
te mindestens auf ihre Wortstämme reduziert (genannt ” Stemming“), um die
vielen Variationen, die aufgrund von Konjugationen oder unterschiedlichen Aus-
prägungen in Einzahl und Mehrzahl entstehen, auf einen gemeinsamen Begriff
zurückzuführen. Zudem werden sogenannte Stoppwörter aus der Menge der
betrachteten Begriffe entfernt, die mit ausreichender Sicherheit keine bedeu-
tungstragende Funktion haben. Dabei handelt es sich hauptsächlich um Artikel
oder Pronomen sowie einige Verben. Zum Beispiel: ” ist“, ” ein“, ” für“, ” der“
und weitere ähnliche Worte.
Spätestens dann hat man eine einfache aber wirksame Repräsentation des
Dokumenten-Inhalts geschaffen. Dennoch ist sie natürlich weit davon entfernt,
perfekt zu sein. Insbesondere erschließt sich der Sinn eines Wortes mitunter
erst aus seinem Kontext. Den Kontext nicht zu berücksichtigen, kann beson-
ders bei kurzen Texten zu falschen Schlüssen führen. Auch das Stemming ist
nicht in allen Fällen perfekt. Mitunter reduziert es Begriffe auf die gleichen
Wortstämme, die eine völlig andere Bedeutung haben. Auch andersherum wird
ein Schuh daraus: es reduziert Begriffe auf unterschiedliche Wortstämme, ob-
wohl sie völlig identische Bedeutungen haben. Weiterhin werden derart ermit-
telte Feature-Vektoren sehr groß und spannen einen riesigen Raum mit sehr
vielen Dimensionen auf. Dadurch werden Berechnungen im Vektorraum sehr
rechenintensiv. Folglich entsteht der Wunsch, die Dimensionalität der Vektoren
zu verringern und gleichzeitig die inhaltliche Übereinstimmung der Vektoren
mit der Zielsetzung des Textes zu erhöhen.

59 5.3. REPRÄSENTATION VON DOKUMENTEN
5.3.3. Methoden für die Beschränkung auf wesentliche Features
Aufgrund der genannten Beschränkungen ist es sinnvoll, nach Wegen zu suchen,
die Dimensionalität der Feature Vektoren einzuschränken. Yang und Pedersen
[YP97] sind eben dieser Frage nachgegangen und haben verschiedene Methoden
auf ihre Wirksamkeit hin überprüft. Die Gewinner der Studie sollen an dieser
Stelle kurz vorgestellt werden.
Inverse Document Frequency
Dieser Ansatz wurde bereits in [SJ72] beschrieben, wo er als ” Collection Fre-
quency Weight“ bezeichnet wurde. Die Annahme dahinter ist, dass offenbar
solche Begriffe für die Klassifikation besonders nützlich sind, die in einzelnen
Dokumenten besonders häufig vorkommen, gleichzeitig aber in der gesamten
Sammlung nur selten auftauchen. Solche Begriffe trennen einzelne Dokumente
sehr gut von anderen und sind daher von Vorteil.
idfi = log N
ni
(5.3)
Rechnerisch kann IDF recht einfach als das Verhältnis zwischen der Zahl
an Dokumenten insgesamt (N) und der Anzahl jener Dokumente, in denen der
jeweilige Begriff bzw. das Feature i vorkommt (ni) angegeben werden, so dass
letztendlich für jedes einzelne Feature ein entsprechender IDF-Wert existiert.
Um entscheiden zu können, welche Features in den meisten Dokumenten vor-
kommen und welche nicht, wäre ein Schwellenwert denkbar, der die allgemeine
Umschreibung ” die meisten“ expliziert. Features, deren IDF nun über diesem
Schwellenwert läge, könnten aus der Betrachtung ausgeschlossen werden.
Häufiger dürfte IDF jedoch als Mittel zur Gewichtung der ermittelten Häufig-
keiten angewandt werden. In dieser Funktion nennt man es auch TF-IDF, kurz
für Term Frequency and Inverse Document Frequency. Dabei multipliziert man
einfach die ermittelten Häufigkeiten (TF) eines Terms i in einem Dokument j
mit der passenden IDF für den Term i.
Information Gain
Information Gain (IG) beschreibt den Informationsgewinn, der durch ein Fea-
ture in Bezug auf die Klassifikation erbracht wird. Um den Gewinn ausdrücken
zu können, benötigt man zunächst ein Maß für den Informationsgehalt. Ein

5.3. REPRÄSENTATION VON DOKUMENTEN 60
Begriff, dessen Auftreten oder Nichtauftreten in Dokumenten eine hohe Aus-
sagekraft über die Klassifikation hat, der hat einen hohen Informationsgehalt.
Dies lässt sich wie folgt verallgemeinern und formeller ausdrücken.
Der Informationsgehalt wurde ursprünglich von Shannon [Sha48] in Bezug
auf die Kapazität von Übertragungskanälen betrachtet. Mit Kapazität ist hier
die Information, die pro Zeiteinheit maximal durch den Übertragungskanal ge-
leitet werden kann, gemeint. Seine Motivation war, formell mathematisch zu
beschreiben, wie sich Rauschen auf die Korrektheit übertragener Daten aus-
wirkt und welche Möglichkeiten es gibt, diesem Effekt entgegenzuwirken. Mit
Rauschen sind Fehler gemeint, die bei der Übertragung passieren können.
Rauschen hat die Eigenschaft, gleichmäßig verteilt nach einer bestimmten
Wahrscheinlichkeit (Signal-to-Noise-Ratio oder kurz SNR) aufzutreten. Die The-
se von Shannon bezüglich der Information ist nun, dass es bei einer bestimmten
SNR eine ganz bestimmte Menge an Information gibt, die so durch den teilweise
verrauschten Kanal geleitet werden kann, dass am anderen Ende ein rauschfrei-
es fehlerloses Ergebnis steht. Diese Menge an Information ist eine theoretische
Größe, die auch durch schlaueste Kodierungsverfahren nicht überschritten wer-
den kann.
Es gibt nun eine feste maximale Kapazität, die auf unverrauschte Weise er-
reicht wird und die systemimmanent und gegeben ist. Wie sich diese Kapazität
durch Rauschen erniedrigt, wird durch Shannons Maß für Information (auch
Entropie genannt) mathematisch errechnet. Dies hat er in einer Formel wie
folgt ausgedrückt 2 :
H = −
n�
pi log pi
i=1
(5.4)
Auf Information Retrieval übertragen lässt es sich derart, dass hierbei nach
Wegen gesucht wird, so wenige Features (entsprechend Bits) wie möglich zu
verwenden, um so viel Information wie möglich auszudrücken, um damit eine
möglichst exakte Klassifizierung zu erreichen. Der Trick dabei ist, Rauschen (in
Bezug auf die Klassifikation falsche Begriffe, Fehler, oder gleichmäßig verteilte
Begriffe) herauszurechnen.
Nun lässt sich die von Shannon ermittelte Formel für den Informationsge-
halt verwenden, um den Informationsgewinn auszudrücken, den ein bestimmter
Term t (bzw. ein bestimmtes Feature) für die Klassifikation des Dokuments
2 Beweis siehe [Sha48], Seite 28ff

61 5.3. REPRÄSENTATION VON DOKUMENTEN
einbringt. Und zwar wie folgt:
G(t) =
m�
− P (ci) log P (ci)
i=1
m�
+P (t) P (ci|t) log P (ci|t)
i=1
m�
+P (t) P (ci|t) log P (ci|t)
i=1
(5.5)
In dieser Formel bezeichnet c eine Klasse aus der Menge aller Klassen (i=1. . . m),
denen jeweils ein Dokument entweder zugeordnet wird oder nicht. Dabei ist P(c)
die Wahrscheinlichkeit oder Frequenz, mit der ein Dokument dieser Klasse c zu-
geordnet wird. P(t) ist die Frequenz des Auftretens des Terms/Features t und
P(c|t) entsprechend die Frequenz, mit der Dokumente bei vorliegendem Feature
t der Klasse c zugeordnet werden.
Mutual Information
Mutual Information (MI) beschreibt die statistische Korrelation, in diesem Fall
zwischen Features und Klassen, und ist folgendermaßen definiert.
I(t, c) = log
P (t ∧ c)
P (t) × P (c)
(5.6)
Gleichung 5.6 geht auf das Maß des gemeinsamen Informationsgehaltes von
Kullback-Leibler [KL51] zurück, das in Gleichung 5.7 dargestellt ist. Es geht von
zwei unterschiedlichen Wahrscheinlichkeitsverteilungen über eine gemeinsame
Wahrscheinlichkeitsvariable x aus, die in Beziehung gesetzt werden.
Besondere Eigenschaften: Dieses Maß ist nicht symmetrisch, so dass es eher
als Inklusion verstanden werden kann. Zudem ist zu beachten, dass es unendlich
wird, wenn die Wahrscheinlichkeit q für x 0 ist, während dies bei p für x nicht
der Fall ist.
IKL(p, q) = log p(x)
q(x)
(5.7)
Die Formel, die im allgemeinen unter der Bezeichnung Kullback-Leibler-
Divergenz bekannt ist und die auch im folgenden die Grundlage bilden soll, ent-
spricht dem erwarteten gemeinsamen Informationsgehalt. Der Erwartungswert
beschreibt den durchschnittlichen Wert einer Wahrscheinlichkeitsverteilung und

5.3. REPRÄSENTATION VON DOKUMENTEN 62
erweitert die Formel zur KL-Divergenz über eine Wahrscheinlichkeitsvariable x
mit n Ausprägungen wie folgt:
�
KL(p|q) = EpIKL(p, q) = Ep log p(x)
�
=
q(x)
n�
i
pi log pi
qi
(5.8)
Auf unsere Domäne der Klassifizierung von Termen bezogen wird aus 5.8 und
5.6 die Gleichung 5.9 für Terme t.
m�
P (t ∧ ci)
MI(t) = P (t ∧ ci) log
P (t) × P (ci)
i=1
(5.9)
Dabei beschreibt MI, wie viel Information von P(t) in P(c) und von P(c)
in P(t) enthalten ist. Sind die Wahrscheinlichkeitsverteilungen P(c) und P(t)
unabhängig voneinander, hat MI den Wert 0, ansonsten ist er positiv. Je höher
er ist, um so mehr Information ist beiden Verteilungen gemein.
Es existiert eine Abschätzung der obigen Formel auf der Basis der Anzahlen
A, B und C, sowie der Gesamtanzahl an Dokumenten N. Die Anzahlen be-
gründen sich durch Korrelationen von t und c wie folgt: t mit c (A), t ohne c
(B) sowie c ohne t (C) und münden in der Abschätzung:
Anwendung
I(t, c) ≈ log
A × N
(A + C) × (A + B)
(5.10)
Bei den drei erläuterten Maßen kommt nur DF ohne eine Lernphase aus. So-
wohl IG als auch MI basieren auf Wahrscheinlichkeitsverteilungen, die zunächst
unbekannt sind. Sie setzen voraus, dass eine Klassifikation existiert, der Do-
kumente zugeordnet sind und dass eine Menge an Termkandidaten existiert.
Nur wenn das der Fall ist, können die nötigen Wahrscheinlichkeitsverteilungen
P(c) oder P(t) überhaupt ermittelt werden. Wenn die zugrundeliegenden Daten
nicht ausreichen, ist eine Trainingsmenge ausreichender Größe mit repräsentati-
ven Dokumenten anzulegen, damit die nötigen Wahrscheinlichkeitsverteilungen
ermittelt werden können.
5.3.4. Latent Semantic Indexing
LSI [DFL + 88] arbeitet ebenso wie die meisten anderen bekannten Verfahren
mit dem Vektorraummodell und repräsentiert ein Dokument somit als Feature
Vektor.

63 5.3. REPRÄSENTATION VON DOKUMENTEN
LSI extrahiert mit Hilfe von Singular Value Decomposition (SVD) [WRR03]
aus einer Dokument-Term-Matrix n orthogonale Faktoren, aus denen die ur-
sprüngliche Matrix durch Linearkombination annähernd wiedergewonnen wer-
den kann. Bei diesem Vorgehen werden Detailinformationen ignoriert, es wird
aber davon ausgegangen, dass die den Dokumenten ” latent“ innewohnende
Struktur erhalten bleibt. Die prinzipbedingte Unschärfe sei hilfreich, da auch
Suchanfragen oft unscharf seien.
Die Idee basiert darauf, dass sich jede i*j Matrix X (i Terme, j Dokumente)
mittels SVD in die Matrizen T, S und D zerlegen lässt (siehe Gleichung 5.11), so
dass T und D zueinander orthogonale Matrizen darstellen. S ist eine diagnonale
Matrix aus einzelnen Werten (singular values) und verbindet T und D so, dass
sich mittels Linearkombination die Ursprungsmatrix X ergibt. Im Verlaufe des
Algorithmus wird die S-Matrix jedoch künstlich verkleinert. Und zwar werden
alle kleinsten Werte entfernt, so dass nur noch k (etwa 50-300) Werte übrig blei-
ben. Die nun entstandene Matrix-Struktur (i*k)(k*k)(k*j) approximiert dann
den ursprünglichen Vektorraum. Der gewählte Wert von k ist natürlich kritisch.
Wird er zu klein gewählt, werden wichtige Features entfernt, wird er zu groß
gewählt, wächst die Dimensionalität und somit die Rechendauer eventuell zu
stark.
⎛
⎞
x11
⎜
⎝
.
· · ·
. ..
x1j
.
⎟
⎠ =
xi1
⎛
· · · xij
⎞ ⎛
t11
⎜
⎝
.
· · ·
. ..
t1m
.
⎟ ⎜
⎟ ⎜
⎟ ⎜
⎠ ⎝
s11
ti1 · · · tim
X = T SD
. ..
smm
⎞ ⎛
⎟ ⎜
⎟ ⎜
⎟ ⎜
⎠ ⎝
d11 · · · d1j
.
. .. .
dm1 · · · dmj
⎞
⎟
⎠ (5.11)
Anfragen an das System werden mit LSI als Pseudo-Dokument-Vektor mo-
delliert. In dieser Form existiert ein Abstandsmaß von diesem Dokument zu an-
deren (echten) Dokumenten im Raum, auf dessen Basis das System die Antwort
formulieren kann. Weiterhin können Begriffe, die sich in der Nähe befinden, in
dem Zusammenhang als Suchbegriffe vorgeschlagen werden. Ergab die Suche zu
wenige Ergebnisse, ist es auch möglich, die Suchanfrage ohne Rückfrage durch
ähnliche Terme zu erweitern und so automatisch die Suche breiter gestalten.

5.3. REPRÄSENTATION VON DOKUMENTEN 64
Das Verfahren sei erfolgreicher als übliche Feature Selection Verfahren, müsse
aber hinter ” echten“ Clustering Ansätzen zurückstehen, inbesondere hinter dem
im Paper von Baker vorgeschlagenen Verfahren Distributional Clustering. [BM98]
Andere halten die Kombination eines Clustering Mechanismus mit LSI für
sinnvoll. U.a. sind die Autoren des Papers [XLG03] dieser Ansicht: ” [. . . ] conse-
quently, traditional data clustering methods such as K-means have to be applied
in the eigenvector spaces to find the final document clusters“(Seite 2). Diesem
Rat möchte sich der Autor dieser Arbeit gerne anschließen. Auch LINGO (siehe
Abschnitt 3.4.2 (Seite 30) und [Osi03] setzt sein Clustering Verfahren auf LSI
auf.
Wie kann nun die Berechnung eines Abstandsmaßes im SVD-Raum vonstat-
ten gehen? Um diese Frage zu beantworten, muss man sich zunächst klar ma-
chen, dass verschiedene Fragestellungen existieren, die zu verschiedenen Ver-
gleichen und damit zu verschiedenen Berechnungen führen. Zum Beispiel kann
man fragen, wie stark ein bestimmter Term mit einem bestimmten Dokument
zusammenhängt, oder man kann den Zusammenhang zweier Dokumente unter-
einander prüfen. Im Folgenden seien alle relevanten Fragestellungen mit ihren
Lösungen dargestellt (ebenfalls entnommen aus [DFL + 88]).
Term - Dokument
Dies ist an sich die simpelste Frage, die man stellen kann, denn die Antwort ist in
der zugehörigen Zelle der Ursprungsmatrix X enthalten. Wenn man nun jedoch
davon ausgeht, dass X nicht (mehr) existiert, sondern nur die drei Matrizen T,
S und D zur Verfügung stehen, dann muss der Wert durch eine entsprechende
Linearkombination der Matrizen errechnet werden. In Gleichung 5.12 sei dies
in einer Formel dargestellt. Hier wird der Zusammenhang zwischen dem Term
i und dem Dokument j errechnet.
Term - Term
|S|−1
�
k=0
tikskkdkj
(5.12)
Der Vergleich von Term zu Term findet im Zeilen-Raum statt. Jede Zeile von T
entspricht bekanntlich einem Vektor eines spezifischen Terms. Für den Vergleich
wird das Skalarprodukt bemüht, daher sieht die einfache Rechnung so aus wie
in Gleichung 5.13 dargestellt. Dabei sei angemerkt, dass die Zeilen i und j der

65 5.3. REPRÄSENTATION VON DOKUMENTEN
Term-Matrix T jeweils mit ihren Skalaren multipliziert werden, wodurch die
Achsen im Raum ihrer allgemeinen Bedeutung entsprechend verzerrt werden
(dies begründet den Faktor s 2 in der Formel).
Dokument - Dokument
|S|−1
�
k=0
tiks 2 kktjk
(5.13)
Bei diesem Vergleich gilt das selbe wie bei dem Vergleich zweier Terme, nur
dass in diesem Falle statt der Zeilen der Term-Matrix T die Spalten i und j der
Dokument-Matrix D’ verwendet werden. Siehe Gleichung 5.14.
Dokument - Pseudo-Dokument
|S|−1
�
k=0
dkis 2 kkdkj
(5.14)
Nun gibt es Situationen, in denen man auf Daten trifft, die in der Matrix X
nicht verzeichnet waren. Falls man zum Beispiel auf ein neues unbekanntes
Dokument mit dessen Vektor vneu trifft und dieses mit den bestehenden Termen
oder Dokumenten vergleichen möchte, so muss man den Vektor vneu zunächst
in den Raum der Matrix D hinein-transformieren.
Auf diese Weise können zudem SVD Strukturen iterativ erweitert werden,
ohne dass bei jeder Änderung des Datenbestandes die Matrizen komplett neu
berechnet werden müssten. Es genügt in diesem Falle, das neue Dokument in
den Vektor-Raum hineinzuprojizieren und den neuen Vektor zu der bestehenden
Dokument-Matrix D hinzufügen. Falls das Dokument neue Terme beinhaltet,
sind diese ebenfalls auf ähnliche Weise hinein zu projizieren und zu der Ma-
trix T hinzuzufügen. Der Vorgang ist jedoch nicht ganz problemlos, denn bei
jeder Änderung der D- oder T-Matrix ohne eine entsprechende Anpassung der
Diagonalmatrix S stimmt die Zuordnung ein kleines Stück weniger.
Aber gehen wir zurück zur Berechnung des Projektions-Vorganges. Man neh-
me an, es gäbe nun den besagten Dokument-Vektor vneu, welcher auf die selbe
Weise konstruiert wurde wie jene der bestehenden Dokumente in der Origi-
nalmatrix X. Er kennt somit für jeden einzelnen Term dessen gewichtete Fre-
quenz oder Auftretenshäufigkeit. Gleichung 5.15 zeigt, wie sich eine passen-
de Repräsentation dneu für den unbekannten Dokument-Vektor vneu errechnen
lässt.
−→ d neu = −→ v T neuT S −1
(5.15)

5.4. CLUSTERING 66
5.4. Clustering
Nehmen wir nun an, dass mit den obigen Techniken Feature-Vektoren für die
Dokumente so angelegt wurden, dass nur wirklich aussagekräftige Begriffe für
die weitere Verarbeitung verwendet werden. Dann sollen hier Algorithmen vor-
gestellt werden, die diese Vektoren zu Clustern zusammenfassen. Allgemein las-
sen sich Clustering Algorithmen darin unterscheiden, dass einige eine hierarchi-
sche Cluster-Struktur erzeugen, andere jedoch nicht (zum Beispiel K-means).
Zudem gibt es unterschiedliche Freiheitsgrade bei der Definition dieser Struktur.
Die einfacheren Algorithmen verlangen mindestens eine vorab festgelegte Zahl
von Clustern. Andere verwenden Thresholds als Maß, um während des Ablaufs
Entscheidungen darüber zu treffen, ob neue Cluster hinzugefügt werden müssen
und somit die Anzahl zu erhöhen ist oder nicht.
Angenommen, es existiert eine Reihe von Klassen, denen Dokumente zuge-
ordnet werden können. Dann folgt es dem intuitiven Verständnis einer Klassifi-
kation, dass ein Dokument durchaus mehreren Klassen zugeordnet werden kann.
Beispielsweise kann ein Dokument sowohl der Klasse Güterverkehr als auch der
Klasse Containertransport zugeordnet sein, da es inhaltlich beide Themen an-
spricht. Um noch einen Schritt weiterzugehen, ist es ebenso wahrscheinlich, dass
das Dokument beide Themen zu einem jeweils unterschiedlichen Grad betrach-
tet.
Modell-basierte Clustering Ansätze gehen nun davon aus, dass Modelle exi-
stieren, die die Zuordnung eines Dokuments zu einer Klasse beschreiben. Es sind
verschiedene Modelle denkbar, am verbreitetsten scheinen jedoch Gaußsche Ver-
teilungen 3 zu sein. Diese nennt man auch Normalverteilungen. Charakteristisch
für sie ist, dass sie durch eine Reihe voneinander unabhängiger Einflüsse ent-
stehen. Beispielsweise sind Messfehler in der Regel normalverteilt. Eine Reihe
gleichartiger Messungen wird jedes Mal einen ähnlichen Wert ergeben, der je-
doch vom wahren Wert wegen zufälliger Messungenauigkeiten abweicht, wobei
jede Messung von der vorherigen unabhängig ist. Die durchschnittliche Ab-
weichung wird Varianz genannt. Eine Normalverteilung wird somit durch ihre
Parameter µ (Erwartungswert) und σ (Varianz) näher definiert und auch als
N(µ,σ)-Verteilung bezeichnet. Zudem ist zu jeder Normalverteilung eine soge-
nannte Wahrscheinlichkeitsdichte ϕ wie folgt definiert.
3 Seite 393 in [DP88]

67 5.4. CLUSTERING
ϕ(x; µ; σ) = 1 (x−µ)2
−
√ e 2σ
2πσ 2 , −∞ < x < ∞ (5.16)
Jedem Cluster entspricht eine solche Verteilung und eine dazugehörige Dich-
te. Da ein Dokument zu unterschiedlichen Graden unterschiedlichen Clustern
angehören kann, muss für jedes Dokument eine Mischfunktion der unterschied-
lichen Wahrscheinlichkeitsdichten existieren, die die verschiedenen Cluster mit
unterschiedlicher Gewichtung w zusammengeführt werden. Diese ist, wie von
Bradley et al.[BFR99] erläutert, für ein Dokument x über alle k Cluster mit
Index h wie folgt definiert.
p(x) =
k�
wh · fh(x|µh, σh) (5.17)
h=1
Die Gewichte w ergeben aufsummiert 1 und entsprechen dem Anteil an Do-
kumenten, die in Cluster h gehören. Die Funktion f dagegen ist die Wahrschein-
lichkeitsdichtefunktion für die Verteilung beliebiger Dokumente x in Bezug auf
den Cluster h, parametrisiert mit der nötigen Erwartung und Varianz.
Der Algorithmus schätzt diese Formel ab, indem er ihre Parameter (beste-
hend aus den Gewichten, Erwartungen und Varianzen) mit Hilfe des Maximum
Likelihood Verfahrens derart wählt, dass die resultierende Likelihood-Funktion
maximal ist. Die Likelihood-Funktion wird über den kompletten Dokumenten-
Raum aufgestellt und stellt die Qualität ( ” how well the corresponding mixture
model fits the data“ 4 ) der geschätzten Parameter dar. Hier die Formel, bei der
Φ für die Menge aller Parameter steht:
L(Φ) = �
�
k�
�
log wh · fh(x|µh, σh)
x∈D
h=1
(5.18)
Der Ablauf besteht im Wesentlichen aus zwei Schritten[LGXZ02] [BFR99],
die sich bis zum Erreichen eines Stop-Kriteriums abwechseln und somit iterativ
die Lösung optimieren. Der erste Schritt wird häufig als E-Schritt (Gleichung
5.19) bezeichnet, während der Zweite (Gleichung 5.20) dann den M-Schritt dar-
stellt. Während des ersten Schrittes werden die Wahrscheinlichkeiten berechnet,
nach der sich Dokument x in Cluster h aufhält. Der zweite Schritt optimiert die
Parameter mit Hilfe der Ergebnisse des ersten Schritts.
4 Seite 7 in [BFR99]

5.4. CLUSTERING 68
w j
h
w j+1
h = �
µ j+1
h
Σ j+1
h
=
=
wj
h (x) = �
x∈D
�
x∈D
�
x∈D
�
x∈D
i
w j
i
w j
h (x)
w j
h (x) · x
w j
h (x)
j
· fh(x|µ h , Σj
h )
· fi(x|µ j
i
, Σj
i
w j
h (x)(x − µj+1
h )(x − µ j+1
h ) T
�
x∈D
w j
h (x)
), h = 1, . . ., k (5.19)
, h = 1, . . ., k (5.20)
Die Gleichungen Gleichung 5.19 und Gleichung 5.20 verlangen nach etwas
zusätzlicher Erläuterung. Insbesondere wird hier mit dem großen griechischen
Zeichen Sigma ein vorher unbenutztes Symbol verwendet. Es ersetzt das bis-
lang verwendete Symbol σ für die Varianz und signalisiert, dass hier dazu über-
gegangen wurde, mehrdimensionale Gaußsche Wahrscheinlichkeitsverteilungen
zu verwenden. Dies ist notwendig, da die zu clusternden Objekte komplexe
Textkörper beinhalten, die kaum auf eindimensionale Art und Weise repräsen-
tiert werden können. Daher gehen wir zu mehrdimensionalen Verteilungen über.
Der Erwartungswert µ ist analog mehrdimensional geworden und liegt nun in
Form eines Vektors vor. Die durch das Sigma dargestellte Varianz ist in der
mehrdimensionalen Form eine Kovarianzmatrix. Sonst ändert sich nichts.
Das Stopp-Kriterium wird von der oben erwähnten Likelihood Funktion ge-
liefert, sobald diese an einem lokalen Maximum konvergiert.

Teil III.
Umsetzung

6. Statisches Modell
Das System war von Beginn an eine sehr experimentelle Plattform, so dass zu
keinem Zeitpunkt eine ausführlich geplante Architektur vorlag. Während der
Forschung daran wurden ständig an verschiedenen Aspekten mehrere Alterna-
tiven ausprobiert, so dass sich inzwischen einige Design-Aspekte als sinnvoll
herauskristallisiert haben, die im Folgenden besprochen werden sollen.
6.1. Data Objects
Die Anwendung verwendet durchgehend objektorientierte Prinzipien und macht
auch für das Datenmodell keine Ausnahme. Da die Daten in einer relationalen
Datenbank abgelegt werden sollen, ist ein relationales Modell trotz grundsätz-
lich objektorientierter Ausrichtung unausweichlich. Somit gibt es hier zwei Mo-
delle, ein relationales (S. 72) und ein objektorientiertes (S. 73 und S. 74).
Es gibt hier für jedes Objekt der objektorientierten Sicht eine Tabelle in der
relationalen Sicht, so dass die Umsetzung vom Einen auf das Andere sehr un-
kompliziert ist. Dank Hibernate lässt sich diese Umsetzung deklarativ bewerk-
stelligen. Das bedeutet, dass für jedes Objekt eine Mapping Datei im XML
Format vorliegt, die von Hibernate ausgewertet wird. Es gibt keinen Code in
der Anwendung, der irgendwie Bezug auf die relationale Natur der Datenbasis
nimmt, die Umsetzung erledigt Hibernate völlig transparent.
6.2. Data Access Objects
Ein wichtiges Ziel bei der Überlegung, auf welche Weise man seinen Datenzu-
griff strukturieren möchte, ist die möglichst weitgehende Unabhängigkeit der
Zugriffsmechanismen von anderen Teilen der Anwendung. Der Grund leuchtet
sofort ein: da es so viele verschiedene Möglichkeiten des Zugriffs auf Daten gibt
(JDBC, Hibernate, XML, . . . ), die natürlich auch unterschiedliche Vor- und
Nachteile besitzen, die sich möglicherweise erst in einer späteren Phase der Ent-
wicklung bemerkbar machen, möchte man in der Lage sein, die Technik später

6.2. DATA ACCESS OBJECTS 72
DOC_CLUSTER_CT
SubSet
DESC_RELATIONS
*pfK «Column» docid: INT
*pfK «Column» clusterid: INT
«Column» probability: float(0)
*PK «column» setid: INT
«column» SETNAME: VARCHAR(80)
*pfK «column» parentDescId: INT
*pfK «column» parentDescLang: VARCHAR(2)
*pfK «column» childDescLang: VARCHAR(2)
*pfK «column» childDescId: INT
+ «PK» PK_SubSet(INT)
+PK_SubSet 1
+ «FK» FK_CLUSTER(INT)
+ «FK» FK_DOCUMENTS(INT)
+ «PK» PK_DOC_CLUSTER_CT(INT, INT)
+FK_DOCUMENTS
0..*
+ «FK» FK_DESC_CHILD(INT, VARCHAR)
+ «PK» PK_DESC_RELATIONS(INT, VARCHAR, VARCHAR, INT)
+ «FK» FK_DESC_PARENT(INT, VARCHAR)
0..*
+FK_CLUSTER
(subsetid = setid)
«FK»
(docid = docid)
«FK»
+FK_DESC_PARENT
0..*
+FK_DESC_CHILD
0..*
(clusterid = clusterid)
«FK»
+FK_DOCUMENTS_SubSet 0..*
DOCUMENTS
+PK_DOCUMENTS
1
+PK_DOC_CLUSTER
1
DOC_CLUSTER
*PK «Column» clusterid: INT
«Column» clustername: varchar(128)
«column» idx: INT
«Column» indexterms: varchar(2048)
FK «column» collectionid: INT
*PK «Column» docid: INT
«Column» abstract: varchar(40000)
«Column» abstract_lang: varchar(2)
«Column» title: varchar(256)
«column» idx: INT
FK «column» collectionid: INT
FK «column» subsetid: INT
(parentDescId = descid
parentDescLang = desclang) «FK»
(childDescId = descid
childDescLang = desclang) «FK»
1
+PK_DESCRIPTORS
1
+PK_DESCRIPTORS
DESCRIPTORS
+ «FK» FK_DOCUMENTS_Collection(INT)
+ «FK» FK_DOCUMENTS_SubSet(INT)
+ «PK» PK_DOCUMENTS(INT)
+ «FK» FK_CLUSTER_Collection(INT)
+ «PK» PK_DOC_CLUSTER(INT)
+FK_CLUSTER_Collection
+FK_DOCUMENTS_Collection 0..*
0..*
(collectionid = collectionid)
(collectionid = collectionid)
«FK»
«FK»
+PK_Collection 1 +PK_Collection 1
Collection
*PK «Column» descid: INT
*PK «Column» desclang: VARCHAR(2)
«Column» descname: varchar(64)
1
+PK_DOCUMENTS
+ «PK» PK_DESCRIPTORS(INT, VARCHAR)
+PK_DESCRIPTORS 1
(docid = docid)
«FK»
*PK «column» collectionid: INT
«column» COLLNAME: VARCHAR(80)
(docid = descid
descid = desclang) «FK»
+ «PK» PK_Collection(INT)
1
+PK_Collection
1
+PK_Collection
+FK_DESCRIPTORS +FK_DOCUMENTS
0..*
0..*
DOC_DESC_CT
(collectionid = collectionid)
«FK»
(collectionid = collectionid)
«FK»
0..*
+FK_TERM_SCHEMA_Collection
*pfK «Column» docid: INT
*pfK «Column» descid: INT
*PK «Column» desclang: VARCHAR(2)
Abbildung 6.1.: Datenobjekte, relationale Sicht
0..*
+FK_STOPWORDS_Collection
TERM_SCHEMA
STOPWORDS
+ «FK» FK_DOCUMENTS(INT)
+ «PK» PK_DOC_DESC_CT(INT, INT, VARCHAR)
+ «FK» FK_DESCRIPTORS(INT, INT)
*PK «Column» word: VARCHAR(32)
*PK «Column» lang: VARCHAR(2)
FK «column» collectionid: INT
*PK «column» termid: INT
«column» idx: INT
«column» termPart1: varchar(50)
«column» termPart2: varchar(50)
«column» termPart3: varchar(50)
FK «column» collectionid: INT
+ «FK» FK_STOPWORDS_Collection(INT)
+ «PK» PK_STOPWORDS(VARCHAR, VARCHAR)
+ «FK» FK_TERM_SCHEMA_Collection(INT)
+ «PK» PK_TERM_SCHEMA(INT)

73 6.2. DATA ACCESS OBJECTS
Serializable
db::AssignmentId
- serialVersionUID: long = 3545796602355855672L
# docid: int
# clusterid: int
# «property get» getClusterid() : int
# «property set» setClusterid(int) : void
# «property get» getDocid() : int
# «property set» setDocid(int) : void
+ equals(Object) : boolean
+ hashCode() : int
+ createFrom(Cluster, Document) : AssignmentId
-id
db::DocumentsSubSet
- name: String
- m_documents: Set
- setid: int
+ DocumentsSubSet()
+ «property get» getName() : String
+ «property set» setName(String) : void
- «property get» getSetid() : int
- «property set» setSetid(int) : void
+ «property get» getDocuments() : Set
+ «property set» setDocuments(Set) : void
-subset
db::Document
- DEFAULT_LANGUAGE: String = Locale.ENGLISH....
- abstractLang: String = DEFAULT_LANGUAGE
- abstractText: String
- assignments: List
- descriptors: List
- docid: int
- idx: Integer
- title: String
- subset: DocumentsSubSet
- collection: DocumentCollection
+ descriptorIterator() : Iterator
+ «property get» getAbstractLang() : String
+ «property get» getAbstractText() : String
+ «property get» getAssignments() : List
+ «property get» getDescriptors() : List
+ «property get» getDocid() : int
+ «property get» getTitle() : String
+ «property set» setAbstractLang(String) : void
+ «property set» setAbstractText(String) : void
+ «property set» setAssignments(List) : void
+ «property set» setDescriptors(List) : void
+ «property set» setDocid(int) : void
+ «property set» setTitle(String) : void
+ «property get» getIdx() : Integer
+ «property set» setIdx(Integer) : void
+ «property get» getCollection() : DocumentCollection
+ «property set» setCollection(DocumentCollection) : void
+ «property get» getSubset() : DocumentsSubSet
+ «property set» setSubset(DocumentsSubSet) : void
-document
db::Assignment
- cluster: Cluster
- document: Document
- id: AssignmentId
- probability: double
+ Assignment()
+ «property get» getCluster() : Cluster
+ «property get» getDocument() : Document
# «property get» getId() : AssignmentId
+ «property get» getProbability() : double
+ «property set» setCluster(Cluster) : void
+ «property set» setDocument(Document) : void
+ «property set» setId(AssignmentId) : void
+ «property set» setProbability(double) : void
Abbildung 6.2.: Datenobjekte, objektorientierte Sicht, Teil 1

6.2. DATA ACCESS OBJECTS 74
-collection
-cluster
db::DocumentCollection
- name: String
- documents: Set
- terms: Set
- stopwords: Set
- clusters: Set
- collectionid: int
+ DocumentCollection()
+ «property get» getName() : String
+ «property set» setName(String) : void
+ «property get» getDocuments() : Set
+ «property set» setDocuments(Set) : void
- «property get» getCollectionid() : int
- «property set» setCollectionid(int) : void
+ «property get» getStopwords() : Set
+ «property set» setStopwords(Set) : void
+ «property get» getTerms() : Set
+ «property set» setTerms(Set) : void
+ «property get» getClusters() : Set
+ «property set» setClusters(Set) : void
-collection
db::Cluster
- clusterid: int
- assignments: List
- collection: DocumentCollection
- name: String
- idx: int = -1
- indexterms: String
+ «property get» getIndexterms() : String
+ «property set» setIndexterms(String) : void
+ «property get» getIdx() : int
+ «property set» setIdx(int) : void
+ «property get» getClusterid() : int
+ «property get» getName() : String
+ «property set» setClusterid(int) : void
+ «property set» setName(String) : void
+ «property get» getAssignments() : List
+ «property set» setAssignments(List) : void
+ «property get» getCollection() : DocumentCollection
+ «property set» setCollection(DocumentCollection) : void
Serializable
db::DescriptorId
- serialVersionUID: long = 3257571689536435251L
# id: int = -1
- DEFAULT_LANGUAGE: String = Locale.ENGLISH....
# lang: String = DEFAULT_LANGUAGE
#id
# «property get» getId() : int
# «property set» setId(int) : void
# «property get» getLang() : String
# «property set» setLang(String) : void
+ equals(Object) : boolean
+ hashCode() : int
-collection
-collection
db::Term
- idx: int
- termid: int
- collection: DocumentCollection
+ Term()
+ Term(com.danielstephan.seacluster.Term)
+ «property get» getIdx() : int
+ «property get» getTermid() : int
+ getTermPart1() : String
+ getTermPart2() : String
+ getTermPart3() : String
+ «property set» setIdx(int) : void
+ «property set» setTermid(int) : void
+ setTermPart1(String) : void
+ setTermPart2(String) : void
+ setTermPart3(String) : void
+ «property get» getCollection() : DocumentCollection
+ «property set» setCollection(DocumentCollection) : void
Serializable
db::Stopword
- serialVersionUID: long = 3256719593660822325L
- DEFAULT_LANGUAGE: String = Locale.ENGLISH....
- id: Id = new Id()
- collection: DocumentCollection
- eq(String, String) : boolean
- hc(Object) : int
+ getLang() : String
+ getWord() : String
+ setLang(String) : void
+ setWord(String) : void
+ «property get» getId() : Id
+ «property set» setId(Id) : void
+ «property get» getCollection() : DocumentCollection
+ «property set» setCollection(DocumentCollection) : void
db::Descriptor
# documents: List
# id: DescriptorId = new DescriptorId()
# word: String
- parents: List
- children: List
+ «property set» setId(DescriptorId) : void
+ «property get» getDocuments() : List
+ getLang() : String
+ «property get» getWord() : String
+ «property set» setDocuments(List) : void
+ setLang(String) : void
+ «property set» setWord(String) : void
# «property get» getId() : DescriptorId
+ «property get» getChildren() : List
+ «property set» setChildren(List) : void
+ «property get» getParents() : List
+ «property set» setParents(List) : void
Abbildung 6.3.: Datenobjekte, objektorientierte Sicht, Teil 2
Term

75 6.3. DATA ACCESS COMMANDS
ändern zu können, ohne dass die gesamte Anwendung davon beeinträchtigt
wird. Daher führt man eine Abstraktionsschicht ein, die den Datenzugriff von
anderen Teilen der Anwendung abschottet.
Diese Schicht besteht hier aus einer Reihe von Zugriffsobjekten. Jedes dieser
Objekte bietet die Methoden an, die die Anwendung im Rahmen ihres Ablaufs
benötigt, und implementiert sie - spezifisch für eine ausgewählte Technologie.
Die hier verwendete Technologie wird durch Hibernate bereitgestellt (ein Open-
Source Projekt, es handelt sich dabei um einen objektrelationalen Mapper, kurz
ORM, der eine objektorientierte Schnittstelle für relationale Datenbanken bie-
tet).
Dies sei am Bespiel des DAOs für das Cluster Objekt dargestellt (in S. 76
und S. 77 zu sehen). Zentral für die Abstraktion ist die Trennung der Imple-
mentation (ClusterDaoImpl) von seiner Spezifikation (ClusterDao, erbend von
Dao). Die Anwendung arbeitet ausschließlich mit der Schnittstelle ClusterDao.
Die verwendete Implementation (in diesem Falle eben ClusterDaoImpl) lässt
sich jedoch deklarativ (mit Hilfe einer XML-Datei für die Konfiguration des
Systems) jederzeit ändern, ohne dass Anwendungscode davon betroffen ist. Das
Basis-Interface Dao wurde eingeführt, nachdem klar wurde, dass viele Methoden
in jedem DAO nötig werden würden. So sind diese Gemeinsamkeiten auch in der
Struktur dokumentiert. Aus den selben Gründen wurde das Objekt DaoSupport
eingeführt, das die Gemeinsamkeiten der verschiedenen DAOs für Hibernate im-
plementiert.
6.3. Data Access Commands
Während der Entwicklung hat sich herauskristallisiert, dass in den prinzipiell
eher groben Zugriffsmethoden der DAOs zu oft ähnliche Abläufe kodiert waren
und die Wiederverwendung dieser Abläufe damit eher schlecht war. Das führte
dazu, dass Code in einem DAO weitgehend optimiert wurde, weil die Notwen-
digkeit dort akut war, während in einem anderen DAO ganz ähnlicher Code
noch völlig unoptimiert vorlag. Die Code-Qualität war damit an einigen Stellen
unnötigerweise niedriger als an anderen.
Somit suchte der Autor nach Möglichkeiten, den Code ” mobiler“ und die
Struktur der Datenzugriffsschicht feingranularer zu gestalten. Die Lösung er-
schien in Form des Command Patterns (siehe dazu auch [GHJV96]). Eigentlich
ist das Command Pattern für die Entwicklung von Benutzerschnittstellen ent-

6.3. DATA ACCESS COMMANDS 76
Dao
«interface»
db::AssignmentDao
+ batchAssignment(List, List, List) : void
DaoSupport
db::AssignmentDaoImpl
- serialVersionUID: long = 3257001077261023284L
+ getEntityName() : String
+ getEntityClass() : Class
+ batchAssignment(List, List, List) : void
Dao
«interface»
db::ClusterDao
+ getOrCreateById(int) : Cluster
Abbildung 6.4.: DAO Struktur, Teil 1
db::ClusterDaoImpl
DaoSupport

77 6.3. DATA ACCESS COMMANDS
Dao
rface»
riptorDao
ocument, String) : List
r) : List
Descriptor) : void
er>
dao::DaoSupport
- log: Log = LogFactory.getL...
- _entityName: String
T
HibernateDaoSupport
Serializable
Dao
+ getObjects() : List
+ getFirstObject() : T
+ execute(Command) : S
+ getObjectsForCriteria(List) : List
+ iterate(IteratingCallback) : void
+ getById(Serializable) : T
+ getEntityClass() : Class
+ getEntityName() : String
+ getIdentityName() : String
+ iterator() : Iterator
+ removeById(Serializable) : void
+ store(T) : T
+ objectsByExample(T) : List
+ remove(T) : void
+ removeAll() : void
+ deleteByExample(T) : void
+ getQueryWithName(String) : Query
+ getQuery() : Query
+ addCriterion(Criterion) : Query
+ create(Dao) : Query
+ getDao() : Dao
DaoSupport
db::DescriptorDaoImpl
- serialVersionUID: long = 3616727175584233017L
+ findDescriptorsForDocument(Document, String) : List
+ findSameDescriptors(Descriptor) : List
+ generateId() : int
+ setAsBeingEqualTo(Descriptor, Descriptor) : void
+ store(Descriptor) : Descriptor
+ getEntityName() : String
+ getEntityClass() : Class
Iterable
Query
«interface»
dao::Dao
+ iterator() : Iterator
+ getObjects() : List
+ objectsByExample(T) : List
+ iterate(IteratingCallback) : void
+ getById(Serializable) : T
+ store(T) : T
+ remove(T) : void
+ removeAll() : void
+ deleteByExample(T) : void
+ getObjectsForCriteria(List) : List
+ getQueryWithName(String) : Query
+ getQuery() : Query
+ execute(Command) : S
«realize»
Dao

6.3. DATA ACCESS COMMANDS 78
Document>
Integer>
Dao
«interface»
db::StopwordDao
+ getWordsAsStrings() : List
+ getAll() : List
+ getWordsAsStringsForLanguage(String) : List
+ getAllForLanguage(String) : List
+ store(Stopword) : Stopword
+ iterator() : Iterator
DaoSupport
db::StopwordDaoImpl
- serialVersionUID: long = 3544389201736120633L
+ getWordsAsStrings() : List
+ getAll() : List
+ getAllForLanguage(String) : List
+ getWordsAsStringsForLanguage(String) : List
+ iterator() : Iterator
+ store(Stopword) : Stopword
+ getEntityClass() : Class
voraussetzen.
Dao
«interface»
db::TermDao
+ getSchema() : TermSchema
+ store(TermSchema) : void
DaoSupport
db::TermDaoImpl
- serialVersionUID: long = 3258415036430235700L
+ getSchema() : TermSchema
+ store(TermSchema) : void
+ getEntityName() : String
+ getEntityClass() : Class
Abbildung 6.6.: DAO Struktur, Teil 3
Der Vorgang ist in Abbildung 6.9 etwas vereinfacht dargestellt. Man muss
bei der Betrachtung des Diagramms bedenken, dass die Methode execute()
jeweils von den Commands spezifisch implementiert wird, während die Methode
execute(Command) in AbstractCommand implementiert ist. Der Grund für die
Trennung von execute() und execute(Command) liegt darin, dass Hibernate
ein Session Objekt benötigt, welches vor der Transaktion geöffnet und nach der
Transaktion geschlossen werden muss, und dass kein einzelner Command dieses
tun soll, die Session somit transparent im Hintergrund verwaltet werden muss.
Dennoch sollen die Commands eventuell Zugriff auf die Session haben (daher die
Methode getSession() in AbstractCommand). Will man nun vermeiden, dass
die Commands sich gegenseitig irgendwie die Sessions weiterreichen, muss dies
im Hintergrund passieren - in diesem Falle geschieht dies in execute(Command)
transparent.
Der aufmerksame Leser wird beim Studium des Diagrammes in Abbildung

79 6.3. DATA ACCESS COMMANDS
FetchTemplate
commands::FetchFromCollection
- collectionName: String
- config: ProcessConfiguration
+ «property get» getConfig() : ProcessConfiguration
+ «property set» setConfig(ProcessConfiguration) : void
+ fetch() : void
+ «property get» getCollectionName() : String
+ «property set» setCollectionName(String) : void
FetchTemplate
commands::FetchWithIdFile
- idFileName: String
- log: Log = LogFactory.getL...
+ FetchWithIdFile()
+ fetch() : void
- readIdsFromFile(String) : Set
+ «property get» getIdFileName() : String
+ «property set» setIdFileName(String) : void
FetchTemplate
commands::FetchRandomTemplate
- log: Log = LogFactory.getL...
- collectionName: String
- config: ProcessConfiguration
- max: int = Integer.MAX_VALUE
+ FetchRandomTemplate()
+ fetch() : void
+ «property get» getCollectionName() : String
+ «property set» setCollectionName(String) : void
+ «property get» getConfig() : ProcessConfiguration
+ «property set» setConfig(ProcessConfiguration) : void
+ getMaxResults() : int
+ setMaxResults(int) : void
dao::FetchTemplate
~ queue: BlockingQueue
- filters: List
T
AbstractCommand
+ put(T) : boolean
+ put(T, long, TimeUnit) : boolean
+ put(List) : boolean
+ execute() : T
+ fetch(FetchTemplate) : void
+ fetch() : void
~ setBlockingQueue(BlockingQueue) : void
+ add(Filter) : void
- applyFilters(T) : void
Abbildung 6.7.: Data Access Commands, Teil 1
FetchTemplate
commands::QueryForListOfIds
- log: Log = LogFactory.getL...
- idList: List
- batchSize: int = 30
+ QueryForListOfIds(List)
+ QueryForListOfIds(String)
+ QueryForListOfIds()
+ fetch() : void
- readIdsFromFile(String) : List
+ «property get» getIdList() : List
+ «property set» setIdList(List) : void

6.3. DATA ACCESS COMMANDS 80
AbstractCommand
commands::FetchAssignment
~ d: Document
~ c: Cluster
+ FetchAssignment(Document, Cluster)
+ execute() : Assignment
~getAssignmentCommand
«interface»
command::Command
+ execute() : T
«realize»
T
command::
AbstractCommand
- session: Session
AbstractCommand
commands::AssignDocumentToCluster
- log: Log = LogFactory.getL...
~ d: Document
~ c: Cluster
~ p: double
~ getAssignmentCommand: FetchAssignment
+ getFetchAssignmentCommand() : FetchAssignment
+ setFetchAssignmentCommand(FetchAssignment) : void
+ AssignDocumentToCluster(Document, Cluster, double)
+ execute() : Object
Command
HibernateCallback
+ «property get» getSession() : Session
+ execute(Command) : S
+ doInHibernate(Session) : Object
AbstractCommand
command::DeleteAllObjects
- log: Log = LogFactory.getL...
~ entityClass: Class
+ DeleteAllObjects(Class)
+ execute() : Integer
AbstractCommand
S
AbstractCommand
command::Fetch
- criteria: List
- persistentClass: Class
+ Fetch(Class)
+ Fetch(List, Class)
+ execute() : List
+ addCriterion(Criterion) : Fetch
S
command::FetchAll
- persistantClass: Class
+ FetchAll(Class)
+ execute() : List
AbstractCommand
commands::BatchAssign
- documentIds: List
- clusterIds: List
- probabilities: List
+ BatchAssign(List, List, List)
+ execute() : Object
T
command::FetchObject
- criteria: List
- persistentClass: Class
AbstractCommand
+ FetchObject(List, Class)
+ FetchObject(Class)
+ execute() : T
+ addCriterion(Criterion) : FetchObject
AbstractCommand
commands::StoreTermSchema
~ schema: TermSchema
+ StoreTermSchema(TermSchema)
+ execute() : Integer
AbstractCommand
commands::Initialize
- log: Log = LogFactory.getL...
~ obj: Object
~ prop: String
~ pd: PropertyDescriptor
+ Initialize(Object, String)
+ execute() : Object
Abbildung 6.8.: Data Access Commands, Teil 2

81 6.3. DATA ACCESS COMMANDS
Clustering Logic
«interface»
:Dao
BatchAssign(documentIds,clusterIds,probabilities)
execute(batchAssign)
execute()
batchAssign
:BatchAssign
AssignDocumentToCluster(document,cluster,probability)
assignDoc
:AssignDocumentToCluster
S:= execute(assignDoc)
execute() FetchAssignment(document,cluster)
fetchAssignment
:FetchAssignment
assignment:= execute(fetchAssignment)
execute()
assignment
Abbildung 6.9.: Beispiel: BatchAssign Command
6.8 festgestellt haben, dass AbstractCommand zusätzlich HibernateCallback
implementiert. Zur Erklärung: Dies ist die Schnittstelle zum Springframework,
und beinhaltet die Methode doInHibernate(Session). Das Springframework
und seine Schnittstellen sind in [JH04] beschrieben. Das besprochene Session
Management wird zusammen mit der Transaktionsverwaltung vom Springfra-
mework transparent durchgeführt.

6.3. DATA ACCESS COMMANDS 82

7. Dynamisches Modell
Ohne im Klassenmodell zu stark in die Tiefe zu gehen, soll hier der Ablauf dar-
gelegt werden. Ziel dieses Kapitels soll es sein zu zeigen, welche Komponenten
welche Algorithmen ausführen. Die nun folgenden Abschnitte sind entsprechend
des Ablaufes vom Rohdokument bis hin zum fertig benannten Cluster sortiert.
7.1. Stoppworte finden
Zunächst wird die Textmenge einmal auf der Suche nach Stoppworten durch-
laufen. Dabei werden alle Begriffe so gezählt, dass ein Begriff pro Dokument
nur einmal gezählt wird. Denn es ist hier vor allem interessant, in wievielen
Dokumenten die Begriffe jeweils vorkommen. Wie oft sie in den Dokumenten
vorkommen ist nicht relevant.
Abbildung 7.1 zeigt die erzielte Wortverteilung im Reuters Korpus. Die Be-
griffe wurden nach ihrer Häufigkeit sortiert, so dass eine Kurve sichtbar wird.
Man kann sehen, dass die allergrößte Menge an Begriffen sehr selten vorkommt.
Man kann auch sehen, dass ein paar wenige Begriffe extrem häufig vorkommen,
in anderen Worten sieht man die Kurve nach langer Flaute sehr stark hoch-
schnellen, so dass kaum noch eine Kurve zu erkennen ist, sondern das Gebilde
eher nach einem leeren Graph mit etwas Schmutz in der rechten unteren Ecke
aussieht. (Übrigens: Der am häufigsten auftretende Begriff ist hier ” the“.)
Diese Form der Kurve ließ sich für eine einfache Abschätzung von Stoppwor-
ten nutzen. Zunächst markiert der Algorithmus alle Worte als Stoppwort, die
nur ein oder zwei Mal auftreten, da diese offenbar keine Aussagekraft in Bezug
auf die Gemeinsamkeiten von Dokumenten besitzen, die im späteren Clustering
relevant werden. Dann, um auch die häufigsten Worte als Stoppwort zu deklarie-
ren, wird die Steigung der Kurve ermittelt. Zusammen mit einem definierbaren
Schwellenwert (ein Wert von 2.0 erschien nach einigen Experimenten als sinn-
voll) lassen sich dann alle Worte, die rechts von dem durch den Schwellenwert
gekennzeichnetet Begriff liegen, als Stoppwort deklarieren. Um kurzfristige Aus-

7.2. TERM-DOKUMENT-MATRIX ERSTELLEN 84
Häufigkeit
160000
140000
120000
100000
80000
60000
40000
20000
0
1 1392 2783 4174 5565 6956 8347 9738 11129 12520 13911 15302 16693 18084 19475 20866 22257 23648 25039 26430 27821
Term Nr
Abbildung 7.1.: Wort Häufigkeiten
reißer zu ignorieren und somit nicht zu früh einzuschreiten, werden jeweils drei
Steigungswerte gemittelt.
Sodann hat man eine Liste von Stoppworten, die in der Datenbank abgelegt
werden.
7.2. Term-Dokument-Matrix erstellen
Die später zu clusternden Texte werden zunächst vorbereitet. Die verfügbaren
Daten bestehen bekanntlich aus den Liste von Deskriptoren und Sachgebieten
und freien Begriffen, sowie aus den Kurzreferaten, die zu jedem Dokument ver-
fasst werden. Während die Listen bereits in der gewünschten Form vorliegen,
so dass jeweils ein Begriff ein Feature darstellt, muss der Text erst in seine
Bestandteile aufgebrochen werden.
Dies funktioniert folgendermaßen, dass jedes Dokument einzeln zunächst durch
einen Lexer läuft, der anhand der Interpunktionszeichen im Text selbigen in ein-
zelne Token aufteilt. Der Lexer ist in der Lage, E-Mails und WWW Adressen
zu erkennen und als eigenständige Token zu behandeln.
Die Token laufen danach durch einen SentenceDetector. Dies ist ein Ob-
jekt, welches Beginn und Ende von Sätzen anhand einer einfachen Abschätzung
(die zwar oft zutrifft, aber manchmal irrt) zu erkennen vermag. Derzeit wer-

85 7.2. TERM-DOKUMENT-MATRIX ERSTELLEN
Dokumente
einlesen
DONE
nächstes
Dokument
verarbeiten
Token
erkennen
Roh-Matrix
anlegen
Dokument
Vektoren aus den
LSI Ergebnissen
selektieren
start
Satzgrenzen
erkennen
Dokument analysieren
Wortgruppen
erkennen
Term-Frequenz-Matrix aufbauen
mittels TF-IDF
gewichten
Cluster erkennen
EM Clustering
anwenden
auf
Wortstämme
reduzieren
Abbildung 7.2.: Ablauf Text Analyse
Stopp-
Worte
entfernen
den schlicht beliebige Satzzeichen als Satzgrenzen interpretiert. Damit werden
LSI anwenden
auch Nebensätze zu eigenständigen Sätzen, ebenso wie eingeklammerte Sätze
oder Wörter. Die Erkennung dieser Sätze oder Teilsätze ist lediglich für die
Phrasen-Erkennung nötig, denn Wortfolgen mit Satzzeichen dazwischen wer-
den generell nicht als Kandidaten für Phrasen angenommen. Dieser Detector
erzeugt Sentence Objekte, die als Container für die Token des jeweiligen Satzes
fungieren.
Danach wiederum werden alle Sentence Objekte durchlaufen und auf wie-
derkehrende Wortgruppen überprüft. Kommen in einem Dokument bestimmte
Worte häufiger zusammen vor, wird für diese Wortgruppe ein Objekt Phrase
angelegt, welches ebenso wie das Sentence Objekt als Container für die der
Wortgruppe zugehörigen Worte gilt. Um zu erkennen, ob Worte mehrfach in
Cluster benennen
der gleichen Folge auftreten, werden Suffix-Arrays (ursprünglich beschrieben
von [MM90], ähnlich verwendet von [ZD04]) für die Dokumente aufgebaut. Ein
Suffix ist eine Zeichenfolge, mit der ein Text endet. Beispielsweise wären ati-

7.2. TERM-DOKUMENT-MATRIX ERSTELLEN 86
on ebenso wie ion Suffixe des Wortes Information. Somit gibt es für das Wort
Information genau elf unterschiedliche Suffixe, eins für jeden Buchstaben. Wie
von Zhang et al. dargestellt, werden zwei Suffix-Arrays benötigt - eines nor-
mal von links nach rechts (Information, nformation, formation, . . . ), und eines
genau umgekehrt von rechts nach links (Information, Informatio, Informati,
. . . ; dieses könnte wohl passender Prefix-Array genannt werden). Beide Arrays
werden sortiert (das Suffix-Array normal und das Prefix-Array umgekehrt von
rechts nach links), so dass die mehrfachen Vorkommen gleicher Wortfolgen in
der durch die Sortierung hergestellten Ordnung direkt nacheinander stehen und
somit leicht erkannt werden.
Der PhraseDetector und der SentenceDetector sind jeweils Producer.
Ein Producer erzeugt Objekte, in diesen Fällen eben Phrase oder
SentencesAndPhrases Objekte. Die verschiedenen Producer sind zusammen
mit dem Tokenizer in Reihe geschaltet. Dieser steht am Anfang der Ket-
te und bildet die Schnittstelle zum Lexer. Er ermöglicht es, über die er-
kannten Token eines Dokumentes zu iterieren und implementiert dazu die
Iterator und Iterable Interfaces. Diese gehören zum Standardumfang der
Java-Klassenbibliothek und stellen somit die übliche Art und Weise dar, wie in
Java über Datenmengen iteriert wird.
Der SentenceProducer nutzt den Tokenizer, um über die Token zu iterieren,
und erzeugt eine Reihe von Sentence Objekten. Der PhraseDetector, nach
Tokenizer und SentenceDetector das Dritte Objekt in der Kette, ruft die
Sentences vom SentenceDetector ab, indem er dessen produce() Methode
mehrfach aufruft.
Nach diesem Vorgang werden die gesammelten Token mit dem Snowball-
Stemmer 1 auf ihre Stammform zurückgeführt. Dadurch werden beispielsweise
die ähnlichen Worte ” laufen“ und ” läuft“ auf die gleiche Buchstabenfolge re-
duziert, so dass sie in der später aufgebauten Tabelle dieselbe Stelle besetzen.
Dieses ist ein übliches Vorgehen bei solchen und ähnlichen Textklassifizierungs-
aufgaben. Damit die ursprünglichen Begriffe nicht verloren gehen, wird ein Ver-
zeichnis angelegt, das für jedes ” gestemte“ Wort die dazugehörigen ursprüngli-
chen Begriffe enthält. Dieses wird später für die Benennung wichtig.
Danach wiederum werden die Token mit einer Liste von Stoppworten (sie-
he Abschnitt 7.1) verglichen. Alle Token, die in dieser Liste wiedergefunden
werden, werden an dieser Stelle fallen gelassen und tauchen somit in späteren
1 WWW Adresse: http://snowball.tartarus.org

auf
Wortstämme
reduzieren
Stopp-
Worte
entfernen
87 7.3. MATRIX BERECHNUNGEN
Roh-Matrix
anlegen
Analysen nicht auf.
DONE
Dokument
Vektoren aus den
LSI Ergebnissen
selektieren
Wortgruppen
erkennen
Term-Frequenz-Matrix aufbauen
mittels TF-IDF
gewichten
Cluster erkennen
EM Clustering
anwenden
LSI anwenden
Abbildung 7.3.: Ablauf Matrix Berechnung
Es bleiben also für das jeweilige betrachtete Dokument eine Menge von Token
übrig, sowie möglicherweise die ein oder andere Phrase. Sowohl Token als auch
Phrase nehmen die Stelle von Features ein, wie sie in Abschnitt 5.3 (Seite 56),
eingeführt wurden. Token und Phrasen werden nun gleich behandelt und eins
Cluster benennen
nach dem anderen in eine Matrix einsortiert, die dynamisch wächst. Bei jedem
neuen Feature (Token oder Phrase) wird eine Zeile hinzugefügt, während bei
jedem neuen Dokument eine neue Spalte hinzugefügt wird. War ein Feature
für das jeweilige Dokument bereits in der Matrix registriert, wird nur dessen
Zähler um eins erhöht. Auf diese Weise enthält die Matrix nach dem Durchlauf
des Algorithmus alle Häufigkeiten des Auftretens der jeweiligen Features in den
jeweiligen Dokumenten.
7.3. Matrix Berechnungen
Der letzte Schritt des vorherigen Abschnittes, also das Sammeln und zählen
der Terme und Phrasen eines Dokumentes, geht nahtlos in den ersten Schritt
dieses Abschnittes über. Alle Terme werden direkt in eine dynamisch wachsende
zweidimensionale Matrix einsortiert, so dass die Werte in den Zellen jeweils
die Häufigkeit des Auftretens eines bestimmten Terms in einem bestimmten
Dokument darstellen.
Hier muss man bedenken, dass die Matrix generell extrem spärlich besetzt ist.
Der größte Teil der Zellen beinhaltet den Wert 0. Das leuchtet ein, wenn man
sich vor Augen führt, dass für jeden möglichen Term eine Zeile in der Matrix
existieren muss, ebenso wie für jedes mögliche Dokument eine eigene Spalte
vorhanden sein muss und dass jedes Dokument nur aus kurzen Zusammen-
fassungen besteht. Dadurch werden nur eine vergleichsweise geringe Menge an
unterschiedichen Begriffen in den jeweiligen Dokumenten verwendet. Es ist zum

7.3. MATRIX BERECHNUNGEN 88
Beispiel nicht ungewöhnlich, 10.000 verschiedene Begriffe verwalten zu müssen,
während in den einzelnen Texten vielleicht nur jeweils 100 Worte vorkommen,
von denen sich sogar einige wiederholen. 9.900 Zellen wären bei dieser Annahme
auf 0, und das pro Dokument.
Rechnet man die Dokumente des ISL (>80.000) auf die zu erwartende Größe
der Matrix um, so bekommt man bei 20.000 Begriffen und 80.000 Dokumenten,
sowie 8 Bytes pro Zelle (es werden double Werte gespeichert, um die Häufig-
keitswerte mit double Gewichten multiplizieren zu können, so dass das Ergebnis
eine gewisse Genauigkeit behält) eine Datenmenge von 12.800.000.000 Bytes.
Diese Zahl sollte Motivation genug sein, die Größe zu beschränken. Die Ma-
trix wird deshalb in einer Baumstruktur abgelegt, die der von Javas TreeMap
entspricht. (Dessen Source wurde kopiert und leicht angepasst, sie wurde auf
die Datentypen long als Schlüssel und double als Wert beschränkt und opti-
miert.) Die TreeMap verwendet einen sogenannten Rot-Schwarz-Baum, dessen
Laufzeitcharakteristik für die wesentlichen Operationen O(log(n)) entspricht.
Sie legt die Daten so unter Schlüsselwerten ab, dass sie nach deren natürlicher
Ordnung sortiert sind. Der Schlüssel repräsentiert die Koordinate der Matrix,
dessen Werte gespeichert werden sollen. Er wird aus Zeilenindex + X * Spalten-
index berechnet und ist somit bis zu einer Menge von X Dokumenten eindeutig
bestimmt (die Dokumente entsprechen den Spalten). Das X darf mit dem maxi-
malen Spaltenindex multipliziert nicht über den Wertebereich von long hinaus.
Also muss X auf jeden Fall ein positiver Integer sein. Das dürfte jedoch kaum ei-
ne echte Einschränkung darstellen, schließlich ergibt das eine maximale Spalten
und Zeilenzahl von jeweils 2 hoch 31.
Nachdem diese Matrix fertig aufgebaut ist, wird sie durchlaufen und die ver-
zeichneten Werte jeweils mit Gewichten (TF-IDF, siehe Abschnitt 5.3.3 (Seite
59)) multipliziert.
Danach wiederum wird sie im Harwell-Boeing Format [DGL89] auf Platte
abgelegt, denn die integrierte LSI-Komponente GTP 2 benötigt eine Datei in
diesem Format als Eingabe. GTP liest daraufhin die Matrix ein und führt einen
SVD Algorithmus aus, der drei Matrizen ergibt, die wie in Abschnitt 5.3.4 (Seite
62) beschrieben zusammen die Ursprungsmatrix approximieren. Die Ergebnisse
schreibt GTP wiederum in eine Datei, die nun umgekehrt wieder eingelesen
werden muss. Die Ergebnisse landen in einem dafür erstellten Objekt namens
SvdResult, dieses Objekt implementiert die nötigen Funktionen, wie Begriffe
2 WWW Adresse: http://www.cs.utk.edu/ ∼ lsi/

Roh-Matrix
anlegen
Term-Frequenz-Matrix aufbauen
mittels TF-IDF
gewichten
LSI anwenden
89 7.4. CLUSTER ANALYSE
DONE
Dokument
Vektoren aus den
LSI Ergebnissen
selektieren
Cluster erkennen
EM Clustering
anwenden
Abbildung 7.4.: Ablauf Cluster Analyse
Cluster benennen
untereinander verglichen werden, Dokumente untereinander verglichen werden
und wie neue Dokumente in den Vektor-Raum ” eingefaltet“ werden, damit sie
vergleichbar sind. Die Formeln dazu stehen in Abschnitt 5.3.4.
7.4. Cluster Analyse
Aus den Ergebnissen werden die Dokumentvektoren extrahiert und an den Clu-
stering Algorithmus übergeben. Danach werden Namen vergeben.
Für die Algorithmen, die im Zusammenhang mit dem Clustering nötig
waren, wurde das Strategy-Pattern ([GHJV96]) verwendet. Jeder wichti-
ge Algorithmus, sei es für die Zuweisung von Dokumenten zu Clustern
(ClusterAssignmentStrategy) oder für das Durchführen des Clustering Algo-
rithmus (ClusterStrategy) wird mit einer Schnittstelle ausgestattet, die ihn
von dem Code, der ihn benutzt, entkoppelt. Dadurch ist es möglich, die verwen-
dete Implementation flexibel auszutauschen. Im Diagramm sind beispielsweise
zwei ClusterStrategy-Implementationen aufgeführt. Welche davon zur An-
wendung kommt, entscheidet sich sobald der ClusterContext erzeugt und mit
einer spezifischen Implementation initialisiert wurde.
Die EMClusterStrategy Klasse implementiert der Einfachheit halber gleich
zwei Schnittstellen und verhält sich als ihr eigenes Ergebnis-Objekt. Durch diese
Aufteilung der Schnittstellen ist es möglich, dass der Algorithmus nach der
Arbeit ein anderes Objekt erzeugt und dieses als Ergebnis zurückliefert. Es mag,
je nach Arbeitsweise des Algorithmus, sinnvoll sein, dies zu tun. In diesem Falle
ging es auch so und auf eine Extra-Klasse für die Ergebnisse konnte verzichtet

7.5. CLUSTER BENENNUNG UND MATRIZEN 90
werden.
7.5. Cluster Benennung und Matrizen
Zur Benennung der Cluster werden die LSI-Ergebnisse verwendet. Diese finden
sich im Code in Form eines SvdResult-Objekts wieder. Man sieht in Abbildung
7.6, dass das SvdResult Objekt Zugriff auf die Term- und Dokument-Matrizen
bietet, so wie sie vom LSI Code erzeugt worden waren. Man sieht auf dem Dia-
gramm leider nicht den Verweis auf die DiagonalMatrix Klasse. Daber handelt
es sich um eine optimierte Subklasse von Matrix, die ausschließlich Werte auf
der Diagonalen hält und zudem ihre Methoden auf die Besonderheiten von dia-
gonalen Matrizen hin optimiert hat, und die hiermit immerhin erwähnt wurde.
Um die Benennungen zu finden, wird zunächst aus den Dokumenten, die
zu dem jeweiligen Cluster gehören, ein Pseudo-Dokument-Vektor erstellt. Die-
ses ist der Cluster-Zentroid. Er errechnet sich als einfacher Mittelwert-Vektor.
Daraufhin werden zu diesem Pseudo-Vektor die Terme gesucht, die ihm am
Ähnlichsten sind. Dazu werden die Methoden (es gibt mehrere, daher Mehr-
zahl) computeTermDocumentAssociation von SvdResult verwendet. Der er-
zeugte Cluster befindet sich bereits im SVD-Raum und kann direkt anstatt
eines Dokument-Vektors verwendet werden.
Im Diagramm ist die Klasse SparseMatrix zu sehen. Diese ist hier der
Vollständigkeit halber aufgeführt, denn sie wird nur für das Ausführen des LSI-
Algorithmus benötigt. Dieser nimmt die Matrix nur in einem solchen Format
entgegen. Daher wird die Matrix vor dem LSI-Durchlauf erst in eine solche
SparseMatrix-Implementation gewandelt.

91 7.5. CLUSTER BENENNUNG UND MATRIZEN
cluster::AssignByThreshold
+ AssignByThreshold()
+ AssignByThreshold(double)
+ assign(double) : ArrayList
+ maxIndex(double) : int
cluster::ClusterStrategy
+ ClusterStrategy()
+ findClusterProbabilityDistribution(Reader) : ClusteringResult
cluster::EMClusterStrategy
cluster::ClusterAssignmentStrategy
+ ClusterAssignmentStrategy()
+ assign(double) : ArrayList
+ toArray(ArrayList) : int[]
InitializingBean
+ findClusterProbabilityDistribution(Reader) : ClusteringResult
+ probabilityDistributionForInstance(Instance) : double[]
+ numberOfInstances() : int
+ instanceAtIndex(int) : Instance
+ afterPropertiesSet() : void
-wekaInstances
analysis::
Instances
+ Instances()
+m_ClusterStrategy
+m_ClusterAssignmentStrategy
cluster::ClusterContext
+ DEFAULT_ARFF_FILE_NAME: String = "clusterInput.arff"
+ m_ClusterStrategy: ClusterStrategy
+ m_ClusterAssignmentStrategy: ClusterAssignmentStrategy
+ ClusterContext()
+ ClusterContext(ClusterStrategy, ClusterAssignmentStrategy)
+ cluster(Matrix) : ClusteringResult
+ assign(ClusteringResult, int) : int
+ assign(double) : ArrayList
«interface»
cluster::ClusteringResult
+ probabilityDistributionForInstance(Instance) : double[]
+ numberOfInstances() : int
+ instanceAtIndex(int) : Instance
cluster::KMeansStrategy
+ KMeansStrategy()
+ findClusterProbabilityDistribution(Reader) : ClusteringResult
+ probabilityDistributionForInstance(Instance) : double[]
+ numberOfInstances() : int
+ instanceAtIndex(int) : Instance
Abbildung 7.5.: Klassendiagramm Cluster Algorithmen

7.5. CLUSTER BENENNUNG UND MATRIZEN 92
«interface»
maths::IMatrix
+ set(int, int, double) : void
+ get(int, int) : double
+ getRowDimension() : int
+ getColumnDimension() : int
+ getRowDescriptors() : List
+ getColumnDescriptors() : List
+ setRowDescriptors(List) : void
+ setColumnDescriptors(List) : void
+ getColumnVector(int) : IMatrix
+ getMaximumValue() : double
+ getMinimumValue() : double
maths::SparseMatrix
+ createFrom(IMatrix) : SparseMatrix
+ createFrom(IndexedSparseMatrix) : SparseMatrix
+ createFrom(Matrix) : SparseMatrix
+ findNumberOfNonZeroValues(IMatrix) : int
# SparseMatrix()
+ getNumberOfValues() : long
+ getValues() : double[]
+ getRowIndizes() : long[]
+ getColumnPointer() : long[]
+ SparseMatrix(long, long, long, long, long, double)
+ get(int, int) : double
+ getColumnDimension() : int
+ getRowDimension() : int
+ set(int, int, double) : void
+ toDenseMatrix() : Matrix
+ toGtpGeneralObject() : General
+ getColumnVector(int) : IMatrix
+ equals(Object) : boolean
maths::Matrix
~ columnDescriptors: List
~ rowDescriptors: List
+ stringWithMinLengthOf(int, String) : String
+ Matrix(double, int)
+ Matrix(double)
+ Matrix(double, int, int)
+ Matrix(int, int)
+ Matrix(int, int, double)
+ Matrix(Jama.Matrix)
+ copy() : Matrix
+ get(int, int) : double
+ set(int, int, double) : void
+ times(Matrix) : Matrix
+ createFromTransposedVector(double) : Matrix
+ createFromVector(double) : Matrix
+ createMatrixFromColumns(int) : Matrix
+ times(DiagonalMatrix) : Matrix
+ solveTranspose(Matrix) : Matrix
+ transpose() : Matrix
+ solve(Matrix) : Matrix
~ getArray() : double[]
+ getColumnPackedCopy() : double[]
+ getColumnVectorArray(int) : double[]
+ getMeanVector(int) : Matrix
+ getSumVector(int) : Matrix
+ getColumnVector(int) : IMatrix
+ toIndexedSparseMatrix() : IndexedSparseMatrix
+ inverse() : Matrix
+ toJamaMatrix() : Jama.Matrix
+ getRowDimension() : int
+ getColumnDimension() : int
+ singularValueDecomposition() : SvdResult
+ toString() : String
+ equals(Object) : boolean
+ equals(IMatrix, IMatrix) : boolean
+ normalize() : void
+ normalizeColumns() : void
+ normalizeRows() : void
+ lengthOfColumn(int) : double
+ lengthOfRowVector(int) : double
+ computeFrobeniusNormal() : double
+ computeOverallSimilarity() : double
+v
+u
-sv
+ u: Matrix
+ v: Matrix
+ s: DiagonalMatrix
maths::AbstractMatrix
+ resetMaxMinValues() : void
~ computeMaximalValues(IMatrix) : double[]
+ computeFrobeniusNormal() : double
+ normalize() : void
+ normalizeColumns() : void
+ normalizeRows() : void
+ lengthOfColumn(int) : double
+ lengthOfRowVector(int) : double
maths::SvdResult
+ SvdResult(Matrix, DiagonalMatrix, Matrix)
+ SvdResult(Matrix, double, Matrix)
+ SvdResult()
+ dimension() : int
+ get(int, int) : double
+ set(int, int, double) : void
+ getRowDimension() : int
+ getColumnDimension() : int
+ getRowDescriptors() : List
+ getColumnDescriptors() : List
+ setRowDescriptors(List) : void
+ setColumnDescriptors(List) : void
+ rank() : int
+ rowSpaceCompare(int, int) : double
+ columnSpaceCompare(int, int) : double
+ columnSpaceCompare(int, Matrix) : double
+ computeTermDocumentAssociation(int, double) : Double
+ getRootOfS() : double[]
+ computeTermDocumentAssociations(Matrix) : Map
+ computeTermDocumentAssociations(int) : Map
+ projectVectorInColumnSpace(double) : double[]
+ projectVectorInColumnSpace(Matrix) : Matrix
+ projectVectorInRowSpace(Matrix) : Matrix
+ getColumnVector(int) : IMatrix
+ getSTimesV() : Matrix
+ equals(Object) : boolean
+ getMaximumValue() : double
+ getMinimumValue() : double
+svdResult
cluster::ClusterNamingContext
+ m_ClusterNamingStrategy: ClusterNamingStrategy
+ ClusterNamingContext(ClusterNamingStrategy)
+ nameClusters() : void
+ nameClusters(Fetch) : void
+m_ClusterNamingStrategy
cluster::ClusterNamingStrategy
+ nameCluster(ClusterNamingContext, Cluster) : void
strategies::NearestTermsNamingStrategy
+ nameCluster(ClusterNamingContext, Cluster) : void
Abbildung 7.6.: Klassendiagramm für Matrizen und SVD Ergebnisse

8. Verwendung des Programms
8.1. Installation
Für die Anwendung existiert ein Installationsprogramm, welches die nötigen
Verzeichnisse anlegt. Dieses liegt in Form eines ausführbaren JAR Archives vor,
welches unter Windows üblicherweise schlicht mittels Doppelklick gestartet wer-
den kann. Sollte das nicht funktionieren, so ist es auf der Konsole mittels java
-jar seacluster-install.jar ausführbar. Dabei ist natürlich zu beachten,
dass die java Anwendung im Pfad zugreifbar sein muss.
Nachdem es in dem gewählten Verzeichnis installiert wurde, muss es auf die zu
verwendende Datenank eingestellt werden. Im Installationsverzeichnis liegt eine
.sql Datei, die das erwartete Datenmodell in SQL beinhaltet. Sofern sich die
Datenbank nach dem SQL92 Standard richtet, sollte dieses direkt problemlos
in der Datenbank ausgeführt werden können und dort die nötigen Tabellen
anlegen. Eventuell muss es jedoch auf die Datenbank zugeschnitten werden,
dies sollte vorher evaluiert werden.
Ist die Datenbank mit den Tabellen versorgt, müssen die JDBC-Einstellungen
in der seacluster.properties Datei hinterlegt werden. Diese Datei befindet
sich ebenfalls im angelegten Installationsverzeichnis. Alle mit EDITME gekenn-
zeichneten Einstellungen müssen gesetzt werden. Dabei sind keine Gänsefüßchen
oder Klammern zu verwenden. Siehe auch Abschnitt 8.3.
Der JDBC Treiber für die verwendete Datenbank liegt üblicherweise als JAR
vor und muss nur in das lib Verzeichnis kopiert werden. Für FrontBase und
PostgreSQL liegen bereits aktuelle JDBC Treiber vor.
Nun gilt es, die DOCUMENTS Tabelle in der Datenbank mit Daten zu
füllen. Hier existiert kein allgemeingültiger Prozess, dies ist schließlich sehr
stark von den lokalen Gegebenheiten abhängig. Die Software-Architektur sieht
Import-Dienste vor, die jedoch speziell entwickelt werden müssen. Es exi-
stiert ein Import-Dienst für das Datenformat des Reuters Textkorpus (sie-
he auch Abschnitt 9.1.1 (Seite 101)). Dieser wird, falls Bedarf besteht,

8.2. BENUTZEROBERFLÄCHE 94
Abbildung 8.1.: Bildschirmfoto des Cluster Browsers
über einen Flag auf der Kommando-Zeile gestartet. Zunächst müssen die
SGML Dateien des Korpus in ein Verzeichnis namens reuters-import ko-
piert werden. Dann kann SeaCLUSTER folgendermaßen gestartet werden: java
-Dservice.importService.load -jar start.jar. Daraufhin werden die Da-
teien im import Verzeichnis eingelesen, geparst und in die Datenbank geschrie-
ben. Andere Korpora, die im gleichen Format vorliegen, mögen ebenso ein-
gelesen werden können. Für Quellen in anderen Formaten muss ein spezieller
Import-Dienst entwickelt werden. Dies ist jedoch nicht sehr aufwendig.
Nun kann SeaCLUSTER durch einen Doppelklick auf start.jar oder die
Eingabe von java -jar start.jar auf der Kommandozeile gestartet werden.
8.2. Benutzeroberfläche
Die GUI beinhaltet zunächst nur ein Menü, aus welchem der Clustering Prozess
gestartet werden kann. Wählt man den Cluster Browser () aus, öffnen sich
mehrere nebeneinanderliegende Listen und ein Textfeld, in denen jeweils die
Daten angezeigt werden. Die Art der Navigation wurde durch den File Viewer
des legendären Betriebssystems NEXTSTEP inspiriert, der sich ebenfalls durch
nebeneinander angeordnete Listen auszeichnete und keinerlei Baumdarstellung,
wie sie in modernen Systemen üblich ist, kannte.

95 8.2. BENUTZEROBERFLÄCHE
Abbildung 8.2.: Bildschirmfoto des Menüs
Wählt man einen Cluster in der linken Liste aus, werden die Dokumente in
der rechts danebenliegenden Liste angezeigt. Wählt man dort wiederum ein Do-
kument aus, wird dessen Inhalt im Textfeld daneben angezeigt. Zusätzlich wird
wiederum daneben und nun ganz rechts eine Liste mit den Begriffen gefüllt,
die laut LSI eine starke Zugehörigkeit zu dem jeweiligen Dokument aufweisen
(sortiert nach Zugehörigkeit). Die Statuszeile zeigt einen Wert, der den Zusam-
menhang des Clusters repräsentiert und die Qualität des jeweiligen Clusters
rechnerisch beweisen können soll. Je höher der Wert, desto ähnlicher sind sich
die im Cluster befindlichen Dokumente.
Abbildung 8.2 zeigt die Möglichkeiten. Der Gesamtprozess des Clusterings
wurde in drei Teilschritte aufgeteilt. compute stopwords analysiert den Daten-
bestand auf Stoppworte und speichert diese in der Datenbank ab. prep analy-
siert den Datenbestand erneut, nur wird nun der oben besprochene komplette
Analyse-Prozess durchgeführt, an dessen Ende der SVD-Algorithmus der LSI-
Komponente steht. run wiederum führt die eigentliche Clusteranalyse durch,
indem es wie angesprochen den EM-Algorithmus des WEKA-Toolkits ausführt.
Da der Zustand des Systems nach jedem Schritt vollständig auf Festplatte und
in die Datenbank gesichert wird, kann die Anwendung zwischen den Vorgängen
geschlossen und neu gestartet werden. Ebenso lässt sich z.B. der Clustering Al-
gorithmus mit verschiedenen Parametern (Zahl der Cluster) mehrfach aufrufen,
um die optimale Zahl experimentell zu ermitteln.
Der Punkt run complete führt prep und run in direkter Folge aus. Dies ist eine
Vereinfachung, da beide Vorgänge eine Weile dauern können und der Nutzer so
nicht auf das Ende des ersten Vorgangs warten muss.

KONFIGURATION 96
${strategy.documents.number}
Abbildung 8.3.: Ausschnitt der Komponentenkonfiguration
8.3. Konfiguration
In Abbildung 8.3 wird exemplarisch die Konfiguration einer Komponente ge-
zeigt. Das Format wird vom Spring Framework 1 vorgegeben, welches die Kom-
ponenten zur Laufzeit mit den jeweiligen Werten versieht und sie wie vorgegeben
initialisiert. Es handelt sich dabei um ein auf XML basierendes Format. Der Vor-
teil, solch eine Konfiguration zu verwenden, liegt in der einfachen nachträglichen
Austauschbarkeit zentraler Komponenten. Dargestellt ist in diesem Beispiel die
DocumentProducer-Komponente. Diese liest die Dokument-Daten aus der Da-
tenquelle (der Datenbank) ein und legt sie in einer FIFO-Liste (First In, First
Out) ab, aus der sich die weiteren (konsumierenden) Komponenten bedienen
können.
Der DocumentProducer delegiert das eigentliche laden der Dokumente jedoch
an eine weitere Komponente, in diesem Falle an das FetchRandomTemplate.
Diese Komponente lädt eine bestimmte Anzahl von Objekten in zufälliger Rei-
henfolge aus der Datenbank. Es ist somit zu erwarten, dass bei jedem Durch-
lauf andere Objekte aus dem Fundus geladen werden. Man sieht auch, dass die
Anzahl an Dokumenten durch eine Variable strategy.documents.number de-
finiert wird. Diese Variable wird aus einer .properties Datei (dies ist ein Stan-
dardformat der Java-Plattform für Konfigurationsdateien) eingelesen, die ent-
weder im ” home“-Verzeichnis des Nutzers oder im aktuellen Arbeitsverzeichnis
unter dem Namen seacluster.properties erwartet wird. Die Annahme, die
für diese Zweiteilung spricht, ist die, dass die Konfigurationsdatei, die durch die
1 WWW Adresse: http://www.springframework.org

97 8.3. KONFIGURATION
vielen Komponenten des Systems nur schwer überschaubar ist, selten geändert
werden muss, wohingegen die viel übersichtlichere Properties-Datei all jene Wer-
te beinhaltet, die oft angepasst werden.
Im Zuge der Entwicklung war es (beispielsweise für die Fehlersuche) notwen-
dig, vergleichbare Ergebnisse zu bekommen. Das ist nun nicht möglich, wenn bei
jedem Durchlauf eine zufällige Dokumentenmenge produziert wird. Aus diesem
Grund wurde die Komponente FetchWithIdFile entwickelt, deren Konfigura-
tion in Abbildung 8.3 auskommentiert zu sehen ist. Diese erwartet eine Liste
von IDs in einer Textdatei und lädt nur die Dokumente, die dort angegeben
wurden, in genau der in der Datei vorliegenden Reihenfolge.
Um die Anwendung benutzerfreundlicher zu gestalten, wäre es sicherlich an-
zuraten, für die Konfiguration jeweils Dialoge zu gestalten, die die Änderungen
der jeweiligen Datei(en) einfach ermöglicht. Darauf wurde jedoch zunächst ver-
zichtet.
db.jdbc.url Die JDBC URL für die Identifikation der Datenbank. Ist abhängig
von der jeweiligen verwendeten Datenbank. Beispiel für FrontBase:
jdbc:FrontBase://local/seacluster
db.jdbc.user Benutzername für die Datenbank
db.jdbc.pass Passwort für die Datenbank
db.jdbc.driver Klassenname des JDBC Treibers für die verwendete Datenbank.
Beispiel für FrontBase: com.frontbase.jdbc.FBJDriver
db.hibernate.batchsize Dies kann zur Optimierung der Datenbankzugriffe ver-
wendet werden. Hibernate versucht, bei Bedarf mehrere Objekte in einem
Rutsch aus der Datenbank zu lesen. Die Voreinstellung ist 50.
db.hibernate.dialect Hibernate besitzt für die meisten Datenbanken optimierte
Strategien. Welche Strategie verwendet werden soll, entscheidet sich hier.
Beispiel für FrontBase: org.hibernate.dialect.FrontBaseDialect
strategy.analysis.refreshTermSchema true, falls die für die Klassifizierung zu
verwendeten Terme neu ermittelt werden sollen (Voreinstellung). false
sonst.
strategy.cluster.number Anzahl zu errechnender Cluster.

8.3. KONFIGURATION 98
strategy.cluster.discretize true, falls die Werte vor dem Clustering in diskrete
Klassen eingeteilt werden sollen. false sonst (Voreinstellung).
strategy.cluster.shift true, falls die Wertebereiche so verschoben werden sol-
len, dass der größte positive Wert und der kleinste negative Wert den
selben Abstand von 0 besitzen, dass also 0 genau in der Mitte des Werte-
bereichs liegt. false sonst (Voreinstellung).
strategy.cluster.normalize true, falls der Wertebereich gestaucht oder ge-
schrumpft werden soll, so dass er sich innerhalb des Intervalls zwischen -1
und +1 befindet und diesen so gut wie möglich ausfüllt (Voreinstellung).
false sonst.
strategy.documents.number Anzahl zugrundegelegter Dokumente. -1 bedeu-
tet ” alle Dokumente“. FetchWithIdFile jedoch ignoriert diese Einstel-
lung.
strategy.idListFileName Beinhaltet den Dateinamen der Datei, die Dokument-
IDs zur Verwendung beinhaltet. Wird nur von FetchWithIdFile verwen-
det.
strategy.stopwords.threshold Legt die Steigung der Kurve in Abbildung 7.1
(Seite 84) fest, ab der Worte als Stoppwort einsortiert werden. 2.0 ist
Voreinstellung.
strategy.stopwords.includefile Legt den Dateinamen der Datei fest, aus der
das System solche Begriffe entnimmt, die auf jeden Fall ein Stoppwort
sein sollen.
strategy.stopwords.excludefile Legt den Dateinamen der Datei fest, aus der
das System solche Begriffe entnimmt, die auf keinen Fall ein Stoppwort
werden sollen. Hat im Zweifel vor includefile Vorrang.

Teil IV.
Abschluss

9. Ergebnisse und Fazit
9.1. Technische Perspektive
9.1.1. Testdaten
Um die Algorithmen testen zu können, wurde der in der Forschung oft verwen-
dete und frei zugängliche Textkorpus ” Reuters-21578“ verwendet. Dieser wurde
1990 veröffentlicht und besteht aus einer Reihe von Nachrichtentexten, die 1987
im Reuters Nachrichtendienst erschienen sind. Er wird derzeit von David D. Le-
wis verwaltet und online für Forschungszwecke angeboten, vgl. [Lew96].
Der Korpus besteht aus einer Menge von 21.578 kurzen Texten. Manche bein-
halten nicht mehr als drei Sätze, andere entsprechen vom Umfang her einer
Schreibmaschinenseite. Die Themen der Texte sind in den Bereichen Wirtschaft
und Politik angesiedelt.
9.1.2. Laufzeit
Man muss feststellen, dass Clustering mit dem EM-Algorithmus nicht sehr
schnell ist. Soviel vorweg. Es wurde zudem bereits im Kapitel Abschnitt 7.3
(Seite 87) angesprochen, dass die Matrix bei großen Datenmengen extrem groß
werden kann, so dass die Algorithmen, wie sie hier beschrieben wurden, gar
nicht mehr funktionieren. Im Falle des ISL sind die Mengen noch klein genug
(unkomprimiert gegen 12GB, komprimiert wenige hundert MB), aber ein Ende
ist definitiv in Sicht.
Große Datenmengen sind natürlich auch in Bezug auf die Laufzeit ein Pro-
blem. Der EM-Algorithmus hat eine exponentielle Laufzeitcharakteristik, so
dass die Laufzeit mit wachsender Menge an Daten immer stärker wächst. Dies
zeigt sich auch an den gesammelten Statistiken. In Tabelle 9.1 und Tabelle 9.2
seien zwei Laufzeitprotokolle gegenübergestellt.
An den beiden Tabellen wird deutlich, dass die Clustering-Zeit deutlich schnel-
ler wächst als alle anderen Faktoren. Während sich die Menge an Dokumenten

9.1. TECHNISCHE PERSPEKTIVE 102
Abschnitt Laufzeit
Parsing 60 Sek.
LSI 7 Sek.
Clustering 87 Sek.
Zuweisungen in DB sichern 48 Sek.
Cluster benennen 12 Sek.
Anzahl Features 1837 Terme
Tabelle 9.1.: Laufzeit bei 521 Dokumenten
Abschnitt Laufzeit
Parsing 182 Sek.
LSI 13 Sek.
Clustering 806 Sek.
Zuweisungen in DB sichern 152 Sek.
Cluster benennen 37 Sek.
Anzahl Features 3709 Terme
Tabelle 9.2.: Laufzeit bei 1684 Dokumenten
etwa verdreifacht hat, hat sich die Clustering-Zeit in diesem Beispiel verzehn-
facht. Es fällt auf, dass der LSI-Algorithmus im Gegensatz dazu sehr gut ska-
liert. Zur Ehrenrettung des EM-Algorithmus sollte man jedoch erwähnen, dass
die verwendete Implementation aus dem WEKA-Toolkit nicht speziell auf die
Laufzeit hin optimiert wurde. Es ließe sich dort sicherlich noch etwas verbessern.
9.1.3. Qualität
Dies ist ein Sorgenkind. Trotzdem der EM-Algorithmus komplexere Strukturen
erkennen kann, als andere, einfachere Varianten, ist es durchaus nicht leicht, ein
passendes, sinnvolles Clustering zu erreichen. Die Anzahl an Clustern ist bereits
ein Faktor. Diese muss im Falle des EM-Algorithmus zu Beginn feststehen und
hat große Auswirkungen auf das Ergebnis. Wieviele sinnvolle Gruppen lassen
sich aus einer Dokumentenmenge erzeugen, und was ist überhaupt eine sinnvolle
Gruppe? Die Fragen sind bereits für den Fachmann schwer zu beantworten, und
ein Clustering Algorithmus beantwortet sie auf seine Weise automatisch, trifft
aber nicht immer den Nagel auf den Kopf.

103 9.1. TECHNISCHE PERSPEKTIVE
Da die automatisch erzeugten Cluster rein statistisch begründet sind, fällt
es mitunter schwer, nachzuvollziehen warum nun eine bestimmte Menge an
Dokumenten zusammengruppiert wurde. Das ist immer dann der Fall, wenn
Eigenschaften bzw. Begriffe zum Clustern herangezogen wurden, die wenig in-
haltliche Aussagekraft haben. Um also qualitativ hochwertige, sinnvolle Cluster
erzeugt zu bekommen, ist es von Nöten, die Begriffe manuell zu überprüfen und
all diese als Stoppwort zu deklarieren, die generell wenig über den Inhalt der
Texte aussagen.
Um dies zu belegen, seien nun einige Beispiele dargestellt, die jeweils in ein
und demselben Cluster zusammegefasst wurden. Das erste Beispiel zeigt den
Beginn eines Textes, der offenbar vom leicht gefallenen Dollarkurs handelt und
dass sich die Händler wegen der unklaren Situation zurückgehalten haben.
” The dollar opened slightly lower in quiet trading, with dealers holding back
ahead of the outcome of this week’s top-level international monetary talks in
Washington. The dollar began here at 1.5128/5138 Swiss francs, down from
the previous 1.5185/5195 close and the 1.5180/5190 francs in New York. Ho-
wever, dealers were sceptical that anything other than a mere reaffirmation of
February’s Paris Accord was likely to emerge from Washington.“
Der nächste Absatz dagegen spricht von Schweinen. Deren Marktpreis sei
gestiegen.
” Hog prices are expected steady to 0.50 dlr higher on estimated receipts of
2,000 head, private sources said. Top seen at 51.00 to 51.50 dlrs per cwt. Sources
said the market closed stronger late yesterday and was expected to carry over
into today’s session. ” Farmers are getting in the fields here,& they said. Also,
little if any country movement was expected, they added.“
Im selben Cluster befanden sich noch Texte, die über den Börsenwert bei-
spielsweise eines Unternehmens im Markt der Kaffee-Röster berichteten. Die
Begriffe, die der Algorithmus als besonders zentral für diese Gruppierung er-
achtet hatte, waren ” higher“, ” openly“, ” lowers“ und ” Dealers“. (Diese Begriffe
werden für jeden Cluster automatisch auf der Basis der durch SVD hergestellten
Matrizen errechnet und als Bennungsvorschlag angeboten.) Man sieht daran,
dass die Veränderung von Preisen der relevante Aspekt für diese Gruppierung
war. In Bezug auf die Qualität der Cluster muss hier beachtet werden, ob dieser
Cluster, bzw. der Aspekt der ihm zugrundeliegt, auch dem Ziel entspricht, das
man mit dem Clustering ursprünglich verfolgt hat. Möglicherweise wäre es hier
interessanter, die Dokumente nach den Objekten zu gruppieren (also alles über

9.1. TECHNISCHE PERSPEKTIVE 104
Schweine gegen alles über den Dollar als Objekt, z.B.).
Würde man nun die Begriffe ” lowers“ und ” higher“ als Stoppwort deklarieren,
dann würde der Algorithmus diesen Aspekt nicht mehr sehen und die Cluster
anders zusammensetzen. Dass die sich neu ergebende Struktur wirklich besser
ist, bleibt jedoch im Einzelfall zu prüfen. Der Prozess läuft vollautomatisch ab
und kann durch Stoppworte und der vorgegebenen Anzahl von Clustern nur be-
grenzt beeinflusst werden. Dies ist sowohl seine Stärke wie auch seine Schwäche.
Stärke, weil er wenige manuelle Eingriffe erfordert. Bei großen Datenmengen ist
es schließlich nicht mehr praktikabel, die Cluster manuell anzulegen, weil es zu-
viel Aufwand erfordert. Schwäche, weil er kaum manuelle Eingriffe ermöglicht
und somit das Ziel einer perfekten Clusterstruktur verfehlen kann. Es bleibt ein
Trade-Off.
Nach all der Kritik soll aber nicht verschwiegen werden, dass mit einer mitt-
leren Anzahl von Clustern und einer automatisch definierten Menge an Stopp-
worten auch eine ganze Reihe von subjektiv sinnvollen Clustern erzeugt werden
konnten.
9.1.4. Ausblick
Was lässt sich noch verbessern? Es ließe sich ein Algorithmus implementieren,
der besser skaliert. Bradley et al. schlagen in ihrem Paper [BFR99] einen opti-
mierten Ablauf vor, der mit deutlich weniger Hauptspeicher auskommt, da er
blockweise arbeitet und daher immer nur einen bestimmten Block im Speicher
halten muss. Es würde im Sinne der Skalierbarkeit sicherlich helfen, wenn der
Algorithmus auf mehreren Rechnern verteilt ablaufen könnte. Das gleiche gilt
für die LSI-Implementation, mit dem Unterschied, dass es tatsächlich schon on-
line verfügbar ist, nur nicht in Java. Die parallele LSI-Implementation nennt
sich PGTP und ist ebenso wie die normale GTP Variante auf www.cs.utk.edu/
lsi 1 in der Software-Rubrik zu finden.
Es gibt zudem Stimmen, die den EM-Algorithmus für den Zweck, Texte zu
clustern, nicht als optimal erachten. Breunig et al. [BKKS01] beispielsweise
schlagen eine alternative Methode vor, die sogenannte ” Data Bubbles“ zusam-
men mit dem OPTICS Algorithmus [ABKS99] verwendet, um auf effizientere
Art und Weise zu einer Clusterstruktur zu gelangen, die hierarchisch sortiert
ist. Dieses Verfahren ist speziell darauf ausgelegt, auch bei großen Datenmen-
1 WWW Adresse: http://www.cs.utk.edu/ ∼ lsi

105 9.1. TECHNISCHE PERSPEKTIVE
gen noch gut genug zu funktionieren. Ein (qualitativer) Vergleich mit dem EM-
Algorithmus wäre für die Zukunft interessant.
Ferner: Um die verwendeten Begriffe exakter spezifizieren zu können, wäre es
denkbar, ein begriffliches Netz wie das WordNet [Mil95] zu integrieren. Damit
könnten thematisch ähnliche Begriffe automatisch vor dem Clustering auf den
selben Term reduziert werden. Die Hoffnung dabei ist natürlich, dass dadurch
ein qualitativ hochwertigeres Ergebnis entsteht.
Zuletzt sei die Anmerkung erlaubt, dass die aktuelle Entwicklung im Internet
von den traditionellen Klassifikationsmechanismen weggeht. Hierzu sei [Shi05]
als Lektüre genannt. Shirky erklärt hier sehr schön, welche Probleme bei fe-
sten Klassifikationssysteme mit einem fest definierten Thesaurus auftreten. Er
nennt aber auch Eigenschaften, die für ein solches festes Klassifikationssystem
sprechen:
• Geringer Umfang des Dokumentkorpus
• Formelle Kategorien
• Stabile Konzepte
• Eingeschränkte Konzepte
• Klare Domänengrenze
• Katalogisierer ist Experte im Fachgebiet
• Autoritative Quelle
• Bestimmte Nutzergruppe
• Nutzer sind Experten bzgl. der Kategorisierung
Einige dieser Eigenschaften treffen für das ISL tatsächlich zu. Beispielswei-
se ist der Umfang und die betrachtete Domäne begrenzt (verglichen mit den
Datenmengen, die Google oder Yahoo verwalten). Die Domänengrenzen ändern
sich so gut wie nie, denn das ISL hat sich auf Seeverkehrswirtschaft und Logi-
kistik spezialisiert. Die Klassifikation wird von Fachleuten des ISL verfasst und
befindet sich in einer wohldefinierten, hierarchischen Struktur und kann somit
als formell bezeichnet werden. Das ISL fungiert als autoritative Oberaufsicht
auf die Klassifikation.

9.2. FACHLICHE PERSPEKTIVE 106
Die Nutzer sind jedoch nicht fest bestimmt, es hat eine unbestimmte Menge
an Nutzern weltweit Zugriff auf das System. Es gab somit auch keine expliziten
Schulungen bezüglich der Klassifikation. Man kann nicht von Expertentum auf
Seiten der Nutzer ausgehen.
Die meisten Faktoren sind im Falle des ISL zwar für eine feste Klassifikation
ausgerichtet, die unbestimmte und ungeschulte Nutzergruppe ist aber ein wich-
tiger Faktor, der dagegen spräche. Hier sind noch weitere Forschungen sinnvoll.
9.2. Fachliche Perspektive
9.2.1. Potentiale
Angenommen, es wurden einige sinnvolle Cluster in der Datenbank angelegt.
Welche Möglichkeiten eröffnet das eigentlich?
Sei nun angenommen, dass Nutzer zu wenige Ergebnisse zu ihren Suchanfra-
gen bekommen. In diesem Falle könnte man dem entgegen wirken, in dem man
die Ergebnisliste durch jene Dokumente anreichert, die in den gleichen Clustern
wie die Dokumente der ursprünglichen Ergebnisliste verzeichnet sind. Zusam-
men mit einem sinnvollen Ranking kann diese Erweiterung der Ergebnismenge
das Such-Erlebnis verbessern.
Gibt es im Gegensatz dazu eher zu viele Ergebnisse, so können zusätzlich,
wie in Abbildung 4.5 (Seite 44) dargestellt, die Cluster daneben aufgelistet
werden. So kann der Suchende die Ergebnisse auf eine beliebige Gruppe ähn-
licher Dokumente einschränken. Er sieht so mindestens sofort, welche Cluster
wahrscheinlich nicht interessant sind, und kann sich auf die verbliebenen inter-
essanten Cluster konzentrieren. Es gibt ihm auch einen Hinweis darauf, welche
Daten im System vorhanden sind, so dass er beim zweiten Versuch eine geziel-
tere Anfrage formulieren kann.
Hat der Nutzer bereits ein relevantes Dokument gefunden, so kann das Sy-
stem ihm durch den Verweis zu dem Cluster, dem das Dokument angehört,
den direkten Zugang zu anderen (hoffentlich) ebenso relevanten Dokumenten
bieten. Auch diese Variante wurde bereits angesprochen, siehe Abbildung 4.6
(Seite 45).
Sofern zusätzlich zum Such-Formular ein Verzeichnis mit hierarchischen Ka-
tegorien angelegt werden soll, so ließe sich ein automatisch durchgeführtes Clu-
stering als Roh-Form verwenden und die Grundlage für das Verzeichnis bilden.
Die Fachleute des ISL würden sicherlich einige Cluster zusammenfassen, sowie

107 9.2. FACHLICHE PERSPEKTIVE
andere auflösen und dessen Dokumente per Hand anderweitig zuweisen, aber
dies wäre sicherlich nicht bei jedem Cluster nötig - viele wären bereits automa-
tisch richtig zusammengestellt und müssten nur noch in die richtige Kategorie
einsortiert werden. Es wäre also eine Arbeitserleichterung für das Erstellen eines
Verzeichnisses.
Als letzte Nutzungsmöglichkeit soll das sogenannte Scatter/Gather-Vorgehen
angesprochen werden. Dies besteht letztendlich daraus, dass sich der Nutzer
schrittweise seinem Ziel annähert und bei jedem Schritt neue Cluster angelegt
werden, aus denen der Nutzer einige auswählt. Diese Auswahl wird dann wieder
neu geclustert. Siehe dazu auch [HP96].
9.2.2. Ausblick
An dieser Stelle möchte der Autor über den Tellerrand hinausschauen und aktu-
elle Ereignisse im Online Publishing ansprechen, die nicht direkt mit Clustering
Techniken verknüpft sind, die im Zusammenhang mit zukünftigen Strategien für
Online-Publishing jedoch beachtet werden sollten.
Vertrieb
Das Clustering selber hat in erster Linie Auswirkungen auf die Suche und kann
wie angesprochen das Such-Ergebnis und -Erlebnis unabhängig vom gewählten
Geschäftsmodell verbessern (erhöht somit den Wert des Angebots). An dieser
Stelle soll kurz dargestellt werden, wie der Autor die Möglichkeiten des ISL
im Zusammenhang mit dem Darbieten und Verkaufen von Informationen sieht.
Die bisherigen hier betrachteten Angebote des ISL bestehen aus dem Online-
Zugriff auf die Seabase Literaturdatenbank sowie aus den über den Online-Shop
vertriebenen Publikationen wie das Jahrbuch, siehe auch Abschnitt 2.1 (Seite
9).
Was kann das ISL also tun, um neue Kunden zu gewinnen? Es ist noch zu
ermitteln, ob und inwieweit es sinnvoll ist, die Granularität des Angebots zu
verkleinern und die großen Publikationen in einzelne Reviews oder auch einzel-
ne Pakete aktueller Statistiken aufzubrechen. Diese könnten dann jeweils ein-
zeln zum kostenpflichtigen Download angeboten werden. Dies sollte geschehen,
sobald das Review geschrieben wurde oder sobald die Statistiken vollständig
vorliegen, um einen Zeitvorteil gegenüber der großen Publikation zu erwirken.
Schließlich ist jede der großen Publikationen beim Erscheinen schon mindestens

9.2. FACHLICHE PERSPEKTIVE 108
einen halben Monat alt. Als Vorbild und Inspiration für diesen Vorschlag gilt
SpringerLink 2 , siehe auch Abschnitt 3.3.2 (Seite 26). Der Springer-Verlag ver-
kauft seine Publikationen dort nicht nur komplett, sondern hält für den (gut)
zahlenden Kunden auch einzelne Artikel bereit.
Außerdem ist der Zugriff auf die Seabase Datenbank in eine kostenlose und
eine kostenpflichtige Zugangsart aufteilbar. Der kostenlose Zugang kann sich auf
einige wenige Suchmittel (insbesondere keine Cluster) und auf eingeschränkte
Ergebnisdetails beschränken. Auf diese Weise können Interessenten einen Ein-
blick in das Angebot bekommen und - ähnlich wie bei der ACM, beschrieben
in Abschnitt 3.3.3 (Seite 27) - für eine professionelle Nutzung der Datenbank
auf eine kostenpflichtige Variante des Systems zurückgreifen.
Blogging
Es mag sich zudem zukünftig auszahlen, das derzeit aufkommende Publishing-
modell der sogenannten Weblogs, kurz Blogs, zu beobachten und es auf seine
wirtschaftlichen Potentiale hin zu überprüfen. Dieses Modell ließe sich beispiels-
weise als Ersatz oder Erweiterung von Newslettern einsetzen. Blogs zeichnen
sich durch ihre Aktualität aus und werden oft täglich erweitert. Sie referenzie-
ren sich häufig gegenseitig mit Hilfe sogenannter ” Permalinks“. Ein solcher Link
verweist direkt auf einen spezifischen Artikel eines Blogs. Besonders sind hier
weniger die Inhalte oder die Eigenschaft der Verlinkung selber, die Besonderheit
ist die standardisierte Technik. Der Aufwand, ein solches Weblog anzubieten,
ist dadurch sehr stark reduziert worden. Es ist nicht einmal mehr die Kennt-
nis der Beschreibungssprache HTML notwendig. Dadurch ist eine besondere
Dynamik entstanden. Etwas Hintergrund über die typischen Inhalte von Blogs
zeigt [BI04] auf, während der Artikel von Rebecca Blood in CACM [Blo04] eine
sehr lesenswerte generelle Einführung in die Thematik gibt. Auch Nardi et al.
[NSG04] geben eine ausführliche Charakterisierung des Blogging-Phänomens.
Sie konzentrieren sich stärker darauf, welche Motivationen dahinterstehen, ein
Blog zu führen.
Es gibt noch wenig Hintergründe dazu, in welcher Form Blogs ihren Platz in
der wirtschaftlich motivierten Strategie von Unternehmen einnehmen können.
Aber das mag sich ändern. Gut geschriebene Blogs mit interessanten Inhalten
ziehen Leser an und können nach der Meinung des Autors dieser Arbeit auch
als Werbung für den Anbieter verstanden werden, sowie als Kommunikations-
2 WWW Adresse: http://www.springerlink.com

109 9.2. FACHLICHE PERSPEKTIVE
kanal des Unternehmens zu seinen Kunden dienen. Die noch unbewiesene These
des Autors lautet, dass ein Blog die Aufmerksamkeit der Nutzer auf das Un-
ternehmen und seine Dienstleistungen lenken kann. Es bleibt noch offen, ob
und wie sich weitere Erlöse mit diesem Modell generieren lassen. Aktuell wer-
den die meisten Blogs von Privatpersonen ohne wirtschaftliche Hintergedanken
verfasst. Andere stammen von Verlagen, die ihre Informationsangebote durch
Blogs anreichern, wie zum Beispiel blog.computerwoche.de 3 und hiermit der-
zeit Erfahrungen sammeln. Auch die Tagesschau hat inzwischen ein Blog, siehe
blog.tagesschau.de 4 .
In diesem Umfeld erscheinen in den letzten Wochen und Monaten zusätzlich
Audio-Blogs, auch Podcasts genannt. Diese erlauben dem Nutzer, die Beiträge
mit einem MP3-Player wie dem iPod von Apple 5 beispielweise im Zug oder im
Auto nebenbei zu hören. Diese Technik erfreut sich immer größerer Beliebtheit.
Schließlich hat man hier, in Zug und Auto, oft sehr viel Zeit, die auf diese Weise
leicht gefüllt werden kann. Mit anderen Worten: hier haben Nutzer ein Zeitfen-
ster, das noch nicht so vollständig mit Aktivitäten ausgefüllt ist. Nach Ansicht
des Autors sind Nutzer in dieser Zeit eher dazu bereit, aus persönlichem Inter-
esse heraus etwas anzuhören. Es gibt hierzu noch keine fundierten Forschungen,
es ist ein brandneues Phänomen. Als Einstieg für weitere Informationen sei hier
Adam Curry’s Weblog auf www.curry.com 6 genannt.
Noch brandaktueller sind sogenannte Videologs, kurz Vlogs. Diese erweitern
den Blog-Gedanken um Audio und Video. Wie mögliche Modelle in diesem
Bereich aussehen können, muss die Zukunft erst noch zeigen. Es gibt jedoch
bereits eine steigende Anzahl von mobilen Geräten, die in der Lage sind, Fil-
me (z.B. Nachrichtensendungen, Schulungsunterlagen oder Dokumentationen
zu speziellen Themen) in hoher Qualität wiederzugeben. Dazu wird in Kürze
wahrscheinlich auch der iPod gehören, und das obwohl Apple die letzten Jahre
wiederholt betont hatte, dass Video für den iPod keine Rolle spielen würde.
Die Playstation Portable 7 von Sony ist bereits in der Lage, Filme abzuspielen,
andere Hersteller wie Archos haben ebenfalls geeignete Produkte im Portfolio,
die dann ohne den Spielcharakter der Playstation auskommen und ein profes-
sionelleres Image haben. In welcher Form sich ein Vlog in eine Firmenstrategie
3 WWW Adresse: http://blog.computerwoche.de
4 WWW Adresse: http://blog.tagesschau.de
5 WWW Adresse: http://www.apple.com/de/ipod
6 WWW Adresse: http://www.curry.com
7 WWW Adresse: http://www.yourpsp.com

9.3. FAZIT 110
einbinden lässt, werden zukünftige Forschungen zeigen müssen.
Der Autor ist der Ansicht, dass das ISL diese neuartigen Technologien zwar
nicht sofort bedenkenlos einsetzen, aber sie dennoch beobachten sollte. Die tech-
nologischen Voraussetzungen für einen Podcast oder ein Blog sind gering, die
nötige Software ist in den meisten Fällen kostenlos zu beziehen, der Einsatz ist
nach einer kurzen Einarbeitungszeit unkompliziert.
9.3. Fazit
Diese Diplomarbeit hat die technischen und fachlichen Implikationen eines Clu-
stering Ansatzes für ein Online Informationssystem wie das des ISL betrachtet.
Dabei wurde klar, dass der Ansatz schlecht skaliert. Hoher Hauptspeicherbe-
darf und Laufzeit verlangen generell nach leistungsfähiger Hardware. Die ex-
ponentielle Laufzeitcharakteristik des hier verwendeten Clustering Algorithmus
begrenzt die sinnvolle Menge an analysierten Dokumenten auf ca. 20.000.
Fachlich wurde angesprochen, dass Clustering den Suchenden eine bessere
Übersicht über die Struktur der im Bestand befindlichen Dokumente ermöglicht.
Zudem wurde vorgeschlagen, eine automatisch erzeugte Cluster-Struktur als
Basis für ein darauf aufbauendes manuell verwaltetes Verzeichnis zu verwenden.
Zuletzt gab es noch den Hinweis, Blogs hinsichtlich der zukünftigen Publishing-
Strategie des ISL zu beobachten. Hier mögen sich moderne und wenig aufwändi-
ge Möglichkeiten in Bezug auf die technische Umsetzung auftun, um aktuelle
Inhalte darzubieten.

Glossar
API Abkürzung für Application Programming Interface. Dabei handelt es sich
um eine Programmierschnittstelle, die eine Reihe von Funktionen oder
Klassen umfasst, mit deren Hilfe auf Daten oder Funktionalitäten des
jeweiligen Systems zugegriffen werden kann. Siehe auch 8 .
Faust 5 Softwaresystem zur Erfassung von Literaturdaten, Hersteller ist Land-
wehr Software GmbH.
Lastenheft Das Lastenheft umschreibt die fachlichen Anforderungen des Auf-
traggebers umfassend. Dabei geht es technisch jedoch nicht ins Detail. Die
Norm DIN 69905 formuliert, es umfasse die Gesamtheit der Anforderun-
gen des Auftraggebers an die Lieferungen und Leistungen eines Auftrag-
nehmers. Kernaussage ist das Was im Gegensatz zum Wie.
web-basiert Auf WWW-Techniken basierende Benutzerschnittstelle habend.
Web-basierte Software wird somit in erster Linie mit dem Browser be-
dient.
relationale Datenbank Weit verbreiteter Datenbanktypus. Dem liegt der Ge-
danke zugrunde, dass die zu speichernden Daten in Tabellen abgelegt und
über spezielle Schlüssel in Relation gesetzt werden. Siehe auch de.wikipedia.org/
wiki/Relationale Datenbank 9
MySQL Eine in kleineren Projekten wegen ihrer Einfachheit und ihrer Schnel-
ligkeit sehr beliebte Open Source Datenbanksoftware (DBMS), die immer
dann gerne zum Einsatz kommt, wenn die keine für das Unternehmen
kritischen Daten gespeichert werden.
PostgreSQL Eine weitere Open Source Datenbanksoftware, die nach eigenen
Angaben mehr Funktionen als MySQL hat und besser mit komplexen Da-
8 WWW Adresse: http://de.wikipedia.org/wiki/Application Programming Interface
9 WWW Adresse: http://de.wikipedia.org/wiki/Relationale Datenbank

112
tenmodellen umgehen kann. Sie positioniert sich ausdrücklich als Daten-
bank für kritische Daten wegen der besseren Implementation von Trans-
aktionssicherheit.
Workflow Ein Workflow ist ein Prozess (alternativ Geschäftsvorfall oder allge-
mein Vorgang), der aus einzelnen Aktivitäten aufgebaut ist, die sich auf
Teile eines Geschäftsprozesses oder andere organisatorische Vorgänge be-
ziehen. Quelle: de.wikipedia.org/wiki/Workflow 10 Speziell auf dieses Pro-
jekt bezogen ist ein Workflow bzw. Vorgang ein in sich geschlossenes Ob-
jekt, welches alle Aktionen, die in Bezug auf ein bestimmtes Dokument
durchgeführt werden, zusammenfassend darstellt.
Content Management System Ein CMS ist eine Software zur Verwaltung von
beliebigen Inhalten. Häufig (so auch hier) wird der Begriff inzwischen
synonym für WCMS (Web Content Management System) genutzt. Dieses
konzentriert sich auf die Verwaltung der Inhalte von Websites. Siehe auch
de.wikipedia.org/wiki/Cms 11
Thesaurus Bei einem Thesaurus handelt es sich um eine Sammlung von Be-
griffen. Das Wort stammt aus dem Lateinischen und bedeutet dort soviel
wie Schatz. Anders als ein Wörterbuch beschreibt ein Thesaurus auch die
Beziehung der Wörter untereinander. Der Thesaurus des ISL zum Beispiel
erlaubt hierarchische Beziehungen und erlaubt mehrere Oberbegriffe.
Inbox Mit Inbox ist in Bezug auf die Email-Kommunikation der Posteingang
gemeint. Allgemein ist die Inbox ein Container, in dem alle neuen Nach-
richten gelistet werden. Jeder Nutzer des Systems bekommt Zugriff auf
eine solche Inbox, so dass er oder sie auch ohne Email am System teilneh-
men kann.
Token Als Token bezeichnet man im Zusammenhang mit Parsern zusammen-
gehörige Zeichenketten, die als solche für die Syntax der analysierten Spra-
che eine Bedeutung haben.
Lexer Lexer ist eine Kurzform des Begiffs Lexikalischer Scanner. Dieser wird
häufig als Vorstufe eines Parsers verwendet. Der Scanner nutzt einfache
10 WWW Adresse: http://de.wikipedia.org/wiki/Workflow#Workflow
11 WWW Adresse: http://de.wikipedia.org/wiki/Cms

113
Zeichensetzungsregeln, um einen Text in Token einzuteilen. Welche To-
ken extrahiert werden oder was überhaupt als Token gilt, hängt von der
Syntax der Eingabe ab, die daher vorher definiert worden sein muss.
Use-Case Der Begriff ” Use-Case“ ist oftmals gleichzusetzen mit dem im deut-
schen Sprachgebrauch eher geläufigen Begriff ” Geschäftsprozess“ oder auch
” Geschäftsvorfall“. Der Begriff ist in Zusammenhang mit der formellen visuellen
Darstellungssprache UML aufgekommen.

114

Literaturverzeichnis
[ABKS99] Ankerst, Mihael ; Breunig, Markus M. ; Kriegel, Hans-Peter ;
Sander, Jörg:
OPTICS: ordering points to identify the clustering structure.
In: SIGMOD ’99: Proceedings of the 1999 ACM SIGMOD interna-
tional conference on Management of data.
New York, NY, USA : ACM Press, 1999. –
ISBN 1–58113–084–8, S. 49–60
[Bal98] Balzert, Helmut:
Lehrbuch der Softwaretechnik - Software-Management, Software-
Qualitätssicherung, Unternehmensmodellierung.
Heidelberg, Berlin : Spektrum Akademischer Verlag GmbH, 1998
[Bal00] Balzert, Helmut:
Lehrbuch der Softwaretechnik - Software-Entwicklung.
Heidelberg, Berlin : Spektrum Akademischer Verlag GmbH, 2000
[Bat89] Bates, Marcia J.:
The Design of Browsing and Berrypicking Techniques for the Online
Search Interface.
In: Online Review 13 (1989), October, Nr. 5, 407–424.
http://www.gseis.ucla.edu/faculty/bates/berrypicking.
html
[BFR99] Bradley, Paul S. ; Fayyad, Usama M. ; Reina, Cory A.:
Scaling EM (Expectation-Maximization) Clustering to Large Data-
bases / Microsoft Research.
Redmond, WA : Microsoft Corporation, October 1999 (Technical
Report MSR–TR–98–35). –
Forschungsbericht.
Der vollständige Report kann mit Hilfe folgender

Literaturverzeichnis 116
[BI04] Bar-Ilan, Judit:
URL als PDF–Dokument heruntergeladen werden:
http://citeseer.ist.psu.edu/bradley99scaling.html
An outsider’s view on ”topic-oriented blogging”.
In: WWW Alt. ’04: Proceedings of the 13th international World Wi-
de Web conference on Alternate track papers & posters.
New York, NY, USA : ACM Press, 2004. –
ISBN 1–58113–912–8, S. 28–34
[BKKS01] Breunig, Markus M. ; Kriegel, Hans-Peter ; Kröger, Peer ;
Sander, Jörg:
Data bubbles: quality preserving performance boosting for hierar-
chical clustering.
In: SIGMOD Record (ACM Special Interest Group on Management
of Data) 30 (2001), Nr. 2, 79–90.
http://citeseer.ist.psu.edu/breunig01data.html
[Blo04] Blood, Rebecca:
How blogging software reshapes the online community.
In: Commun. ACM 47 (2004), Nr. 12, S. 53–55.
http://dx.doi.org/10.1145/1035134.1035165. –
DOI 10.1145/1035134.1035165. –
ISSN 0001–0782
[BM98] Baker, L. D. ; McCallum, Andrew K.:
Distributional clustering of words for text classification.
In: Croft, W. B. (Hrsg.) ; Moffat, Alistair (Hrsg.) ; Rijsbergen,
Cornelis J. (Hrsg.) ; Wilkinson, Ross (Hrsg.) ; Zobel, Justin
(Hrsg.): Proceedings of SIGIR-98, 21st ACM International Con-
ference on Research and Development in Information Retrieval.
ACM Press, New York, US, 96–103
[CMK66] Cleverdon, Cyril W. ; Mills, Jack ; Keen, Michael:
Factors determining the performance of indexing systems.
Bedford, England : College of Aeronautics, Cranfield University,
1966 (Aslib Cranfield research project Volume 1–Design, Part
1–Text). –
Forschungsbericht.
Der vollständige Report kann mit Hilfe folgender

117 Literaturverzeichnis
URL als PDF–Dokument heruntergeladen werden:
http://hdl.handle.net/1826/861
[DFL + 88] Dumais, S. T. ; Furnas, G. W. ; Landauer, T. K. ; Deerwester,
S. ; Harshman, R.:
Using latent semantic analysis to improve access to textual infor-
mation.
In: CHI ’88: Proceedings of the SIGCHI conference on Human fac-
tors in computing systems, ACM Press, 1988. –
ISBN 0–201–14237–6, S. 281–285
[DGL89] Duff, I. S. ; Grimes, Roger G. ; Lewis, John G.:
Sparse matrix test problems.
In: ACM Trans. Math. Softw. 15 (1989), Nr. 1, S. 1–14.
http://dx.doi.org/10.1145/62038.62043. –
DOI 10.1145/62038.62043. –
ISSN 0098–3500
[DP88] Dörfler, Willibald ; Peschek, Werner:
Einführung in die Mathematik für Informatiker.
München, Wien : Carl Hanser Verlag, 1988
[FPSS96] Fayyad, Usama M. ; Piatetsky-Shapiro, Gregory ; Smyth,
Padhraic:
From Data Mining to Knowledge Discovery in Databases.
In: AI Magazine 17 (1996), Nr. 3, S. 37–54
[GHJV96] Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlissides,
John:
Entwurfsmuster : Elemente wiederverwendbarer objektorientierter
Software.
Addison-Wesley-Longman, 1996. –
ISBN 3893199500
[HP96] Hearst, Marti A. ; Pedersen, Jan O.:
Reexamining the cluster hypothesis: scatter/gather on retrieval re-
sults.
In: SIGIR ’96: Proceedings of the 19th annual international ACM
SIGIR conference on Research and development in information
retrieval.
New York, NY, USA : ACM Press, 1996. –

Literaturverzeichnis 118
ISBN 0–89791–792–8, S. 76–84
[ISL01] Vernetzungspotenziale innerhalb der maritimen Wertschöpfungsket-
ten am Schiffbau-, Seeschifffahrts- und Hafenstandort Deutsch-
land.
Version: November 2001.
http://www.bmwa.bund.de/Redaktion/Inhalte/Pdf/Homepage
2Fdownload 2Fbranchenfocus 2FVernetzungspotenziale.
pdf,property=pdf.pdf. –
Endbericht
[JH04] Johnson, Rod ; Hoeller, Juergen:
Expert One-on-One J2EE Development without EJB.
John Wiley & Sons, 2004. –
ISBN 0764558315
[KL51] Kullback, S. ; Leibler, R.A.:
On Information and Sufficiency.
In: The Annals of Mathematical Statistics 22 (1951), March, Nr. 1,
S. 79–86
[Lew96] Lewis, David D.:
Reuters-21578, Distribution 1.0.
http://www.daviddlewis.com/resources/testcollections/
reuters21578.
Version: 1996. –
Copyright resides with Reuters Ltd.
[LGXZ02] Liu, Xin ; Gong, Yihong ; Xu, Wei ; Zhu, Shenghuo:
Document clustering with cluster refinement and model selection
capabilities.
In: SIGIR ’02: Proceedings of the 25th annual international ACM
SIGIR conference on Research and development in information
retrieval, ACM Press, 2002. –
ISBN 1–58113–561–0, S. 191–198
[Luh58] Luhn, H. P.:
The automatic creation of literature abstracts.
In: IBM Journal of Research and Development 2 (1958), Nr. 2, S.
159–165. –

119 Literaturverzeichnis
ISSN 0018–8646
[Mil95] Miller, George A.:
WordNet: a lexical database for English.
In: Commun. ACM 38 (1995), Nr. 11, S. 39–41.
http://dx.doi.org/10.1145/219717.219748. –
DOI 10.1145/219717.219748. –
ISSN 0001–0782
[MM90] Manber, Udi ; Myers, Gene:
Suffix arrays: a new method for on-line string searches.
In: SODA ’90: Proceedings of the first annual ACM-SIAM symposi-
um on Discrete algorithms.
Philadelphia, PA, USA : Society for Industrial and Applied Mathe-
matics, 1990. –
ISBN 0–89871–251–3, S. 319–327
[NSG04] Nardi, Bonnie A. ; Schiano, Diane J. ; Gumbrecht, Michelle:
Blogging as social activity, or, would you let 900 million people read
your diary?
In: CSCW ’04: Proceedings of the 2004 ACM conference on Com-
puter supported cooperative work.
New York, NY, USA : ACM Press, 2004. –
ISBN 1–58113–810–5, S. 222–231
[Osi03] Osiński, Stanis̷law:
An Algorithm For Clustering Of Web Search Results, Poznań Uni-
versity of Technology, Diplomarbeit, June 2003
[RM02] Rosenfeld, Louis ; Morville, Peter ; LeJeune, Lorrie (Hrsg.):
Information Architecture for the World Wide Web.
2.
O’Reilly Media Inc., 2002
[RN95] Russell, Stuart J. ; Norvig, Peter:
Artificial Intelligence: A Modern Approach.
Englewood Cliffs, NJ : Prentice-Hall, 1995
[Sch02] Schienmann, Bruno:
Kontinuierliches Anforderungsmanagement - Prozesse, Techniken,
Werkzeuge.

Literaturverzeichnis 120
München/Deutschland : Addison Wesley Verlag, ein Imprint der
Pearson Education Deutschland GmbH, 2002
[Sha48] Shannon, Claude E.:
A Mathematical Theory of Communication.
In: The Bell System Technical Journal 27 (1948), July, October, S.
379–423, 623–656
[Shi05] Shirky, Clay:
Ontology is Overrated: Categories, Links, and Tags.
http://shirky.com/writings/ontology overrated.html.
Version: 2005. –
gesehen am 10. August 2005
[SJ72] Sparck Jones, Karen:
A statistical interpretation of term specificity and its application in
retrieval.
In: Journal of Documentation 28 (1972), Nr. 1, S. 11–21. –
ISSN 0022 0418
[TAAK04] Teevan, Jaime ; Alvarado, Christine ; Ackerman, Mark S. ;
Karger, David R.:
The perfect search engine is not enough: a study of orienteering
behavior in directed search.
In: CHI ’04: Proceedings of the 2004 conference on Human factors
in computing systems, ACM Press. –
ISBN 1581137028, 415–422
[VR79] Van Rijsbergen, C. J.:
Information Retrieval, 2nd edition.
Version: 1979.
http://www.dcs.gla.ac.uk/Keith/Preface.html. –
Online Ressource, Abruf: 2005-07-07
[WRR03] Kapitel Singular value decomposition and principal component ana-
lysis.
In: Wall, Michael E. ; Rechtsteiner, Andreas ; Rocha, Luis M.:
A Practical Approach to Microarray Data Analysis.
Norwell, MA : Kluwer, 2003, S. 99–109
[XLG03] Xu, Wei ; Liu, Xin ; Gong, Yihong:

121 Literaturverzeichnis
Document clustering based on non-negative matrix factorization.
In: SIGIR ’03: Proceedings of the 26th annual international ACM
SIGIR conference on Research and development in informaion
retrieval.
New York, NY, USA : ACM Press, 2003. –
ISBN 1–58113–646–3, S. 267–273
[YP97] Yang, Yiming ; Pedersen, Jan O.:
A comparative study on feature selection in text categorization.
In: Fisher, Douglas H. (Hrsg.): Proceedings of ICML-97, 14th In-
ternational Conference on Machine Learning.
Nashville, US : Morgan Kaufmann Publishers, San Francisco, US,
1997, S. 412–420
[ZD04] Zhang, Dell ; Dong, Yisheng:
Semantic, Hierarchical, Online Clustering of Web Search Results.
In: Yu, Jeffrey X. (Hrsg.) ; Lin, Xuemin (Hrsg.) ; Lu, Hongjun
(Hrsg.) ; Zhang, Yanchun (Hrsg.): Advanced Web Technologies
and Applications 6th Asia-Pacific Web Conference, APWeb 2004
Bd. 3007.
Springer-Verlag GmbH. –
ISBN 3–540–21371–6, 69–78

Literaturverzeichnis 122

Index
Abonnement, 26
Abstandsmaß, 63
Algorithmus, 47
Clustering, allg., 66
LSI, 63
Analyse, 49
Anbieter, 3
Angebot
interessantes, 11
Anschaltzeit, 17, 19
Ansicht, 44
Attribut, 47
Auktion
von Schiffen, 23
Benachrichtigungsdienst, 11
Benutzerschnittstelle, 43
Bewertungsfunktion, 54
Blog, 108
boolsche Logik, 45
Boolscher Operator, 21
Browser, 45
Cluster, 47, 106
Clustering, 43, 47, 51, 64, 66
hierarchisch, 104
Konzept, 43
Laufzeit, 101
Qualität, 102
Clusty, 29, 44
Computerwoche, 109
Data Bubbles, 104
Data Mining, 47, 55, 56
Dateiformat, 35
Datenbank, 15–17, 19, 47
Literatur-, 9
Datenmenge, 54, 101
Datenmodell, 37
Design, 43
Deskriptor, 36, 37
Dienstleistung, 3
Dimensionalität, 58, 59
Distributional Clustering, 64
DMKN, 20
Dokumentausgabegebühr, 17, 19
Dokumentenarchiv, 21
Download, 107
Drucken, 44
Effektivität (von IR), 53
Entropie, 60
Erfassung, 17, 27, 37
Ergebnisliste, 44, 106
Erwartungswert, 61, 66
Evaluation, 55
Export, 37, 46
Faust, 35, 37, 47

Index 124
Feature, 46, 49, 57, 58, 61, 66
Feld, 47
Fireball, 52
FIZ Karlsruhe, 19
Forschungsergebnisse, 23
Forum, 20
Framework, 30
Frequenz, 61
Gaußsche Verteilung, 66
Gaussian Mixture Model, 67
Gebraucht-Schiffe, 23
Geschäftsmodell, 107
Gewichtung, 59
Google, 45, 52
Granularität des Angebots, 107
Hierarchie, 43
Homepage, 26
HTML, 108
Index, 49
Individualisierung, 10
Information Gain, 59
Information Retrieval, 51, 60
Informationsangebote, 109
Informationsbeschaffung, 9
Informationsgehalt, 59
Informationsgewinn, 59
Informationssystem, 3
Integration, 27
Interesse (persönlich), 109
Interpretation, 47, 56
Inverse Document Frequency, 59
iPod von Apple, 109
ISL, 11, 30
Jahrbuch, 107
Journal, 26, 27
K-Means, 66
Künstliche Intelligenz (KI), 56
Kapazität, 60
Kategorisierung, 30
Klassifikation, 29, 57, 59, 60, 62, 66
Knowledge Discovery from Databa-
ses, 51
Kommunikationskanal, 109
Konferenzprotokoll, 27
Konkurrenz, 15
Kontext, 52, 58
Korrektheit, 60
Korrelation, 61
Kriterien, 15
Kullback-Leibler, 61
Kullback-Leibler-Divergenz, 61
Kundenprofil, 11
Kurzreferat, 37
Laufzeitcharakteristik, 47
Lernphase, 62
Linearkombination, 63
LINGO, 30
linguistisch (Texte erfassen), 52
Literaturhinweis, 3
LSI, 30, 104
Möglichkeiten, 106
Matrix, 31, 63
orthogonal, 63
Mitgliedschaft, 27
Model-based Clustering, 66
MP3-Player, 109
Mutual Information, 61
Nachfrage, 11

125 Index
Netacademy, 23
Netzwerk-Lizenz, 27
Netzwerkeffekt, 15
Newsletter, 108
Normalverteilung, 66
Nutzwert, 16
Online Strategien, 3
Online-Publishing, 107
Online-Shop, 107
OPTICS, 104
Overture, 52
Pauschalpreis, 17
Permalink, 108
Personalisierung, 11, 43, 44
Playstation Portable, 109
Portal, 26, 27, 29
Potential, 108
Potentiale, 106
Precision, 53
Preisliste, 19
Preissystem, 19
Preprocessing, 46, 55
Profil, 44
Prototyp, 43
Prozess, 55
Publikation, 23, 26, 27
Qualität, 22, 47
Rauschen, 60
Recall, 53
Recherche, 3, 11, 36
Repräsentation, 52, 56, 57
Reuters, 101
Scatter/Gather, 107
Schlagwort, 3, 16, 17, 22, 23
Schwellenwert, 59
Seabase, 107
Selektion, 46, 55
Shannon, 60
Signal-to-Noise-Ratio, 60
Singular Value Decomposition (SVD),
63, 103
Skalierbarkeit, 104
Sony, 109
Stemming, 58
Stoppwort, 58, 103
Strategie, 3, 10, 109
Studie, 9
Suchanfrage, 37
Suche, 17, 63
Suchfunktion, 21, 22, 26
Suchmaschine, 30, 52
Suchmechanismus, 27
Tagesschau, 109
Tellerrand, 107
Textkorpus, 101
TF-IDF, 59
Thesaurus, 17, 21–23, 37, 47, 57
Threshold, 66
Trainingsmenge, 62
Transformation, 46, 56
Varianz, 66
Vektor, 47, 58, 59
Vektorraum, 62
Verkaufen, 107
Verzeichnis, 22, 106
Videolog, 109
virtuelle Gemeinschaft, 15
Vivísimo, 29

Index 126
Vlog, 109
Volltext, 11, 21, 27
Wahrscheinlichkeit, 53, 61
Wahrscheinlichkeitsdichte, 66
Wahrscheinlichkeitsverteilung, 61, 62
Weblog, 108
Werbe-Möglichkeit, 22
Werbung, 16
Wertschöpfung, 15
Wissen, 20
WordNet, 105
Wortstamm, 58
Zeitfenster, 109
Zugangsart, 108