Below is a TXT version of a PhD thesis (in German) by Daniel Kinzler. It describes software that can crawl Wikipedia in order to extract cross-lingual terminology information.

It is licensed unded GFDL.

Universität Leipzig
Fakultät für Mathematik und Informatik
Institut für Informatik
Automatischer Aufbau
eines multilingualen Thesaurus
durch Extraktion semantischer
und lexikalischer Relationen
aus der Wikipedia
Diplomarbeit
Leipzig, Mai 2008 Vorgelegt von:
Daniel Kinzler
Studiengang Informatik
Kurzreferat
Die vorliegende Diplomarbeit beschreibt und analysiert Methoden, um aus den Datenbeständen der
Wikipedia in verschiedenen Sprachen einen multilingualen Thesaurus zu erstellen. Dabei sollen insbesondere
die Beziehungen zwischen Termen (Wörtern, Wortformen, Phrasen) zu sprachunabhängigen
Konzepten extrahiert werden sowie die Beziehungen zwischen solchen Konzepten, speziell Beziehungen
der Über- bzw. Unterordnung (Subsumtion) sowie der semantischen Verwandtheit und Ähnlichkeit. Zu
diesem Zweck werden die Anforderungen sowie die verfügbaren Rohdaten analysiert, ein Prototyp zur
Extraktion der gewünschten Daten entwickelt und die mit dem Prototyp gewonnenen Daten in Bezug auf
die zuvor formulierten Anforderungen evaluiert.
Schlagwörter
Wikipedia; Thesaurus; Sprachverarbeitung; Information Retrieval; Übersetzung
CR-Klassifikation
H.3.1 Content Analysis and Indexing
H.3.3 Information Search and Retrieval
I.2.7 Natural Language Processing
Diese Diplomarbeit steht unter der GNU-Lizenz für freie Dokumentation 1.2 (GFDL).
Sie wurde am 28. Mai 2008 mit LATEX gesetzt, Urheber ist Daniel Kinzler.
Detaillierte Angaben zur Lizenz finden sich im Kapitel Lizenz ab Seite 207.
Zitation: Daniel Kinzler, Automatischer Aufbau eines multilingualen Thesaurus durch Extraktion semantischer und
lexikalischer Relationen aus der Wikipedia, Diplomarbeit an der Abteilung für Automatische Sprachverarbeitung, Institut für
Informatik, Universität Leipzig, 2008.
@mastersthesis{ kinzler2008th,
author = "Daniel Kinzler",
title = "Automatischer Aufbau eines multilingualen Thesaurus durch Extraktion
semantischer und lexikalischer Relationen aus der Wikipedia",
school = "Universit\"{a}t Leipzig",
year = "2008",
url = "http://brightbyte.de/papers/2008/DA/WikiWord.pdf"
}
URI: <http://brightbyte.de/papers/2008/DA/WikiWord.pdf>
Inhaltsverzeichnis
I. Einleitung 1
1. Grundlagen 2
1.1. Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Wikipedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Thesauri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2. Einordnung 14
2.1. Untersuchung von Struktur und Qualität der Wikipedia . . . . . . . . . . . . . . 14
2.2. Maschinenlesbare Wissensbasen . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3. Automatische Disambiguierung und semantische Verwandtheit . . . . . . . . . . 17
2.4. Erzeugung von Thesauri und Taxonomien . . . . . . . . . . . . . . . . . . . . . 18
2.5. Wissensextraktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6. Named Entity Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7. Eigenschaften von WikiWord . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
II. Entwurf 23
3. Idee 24
4. Ablauf 25
4.1. Analyse von Wiki-Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2. Aufbau des lokalen Datenmodells . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3. Zusammenführen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4. Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
III. Implementation 32
5. Anforderungen 33
5.1. Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2. Rahmenbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6. Plattform 35
6.1. Laufzeitumgebung: Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2. Datenbank: MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.3. Austauschformat: SKOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Inhaltsverzeichnis iv
7. Framework 37
7.1. Import-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.2. Ablauf und Parallelisierung (Pipeline) . . . . . . . . . . . . . . . . . . . . . . . 38
8. Analyse des Wiki-Textes 40
8.1. Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.2. Mechanismen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.3. Bereinigen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.4. Extraktion von Vorlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.5. Ressourcenklassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.6. Konzeptklassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.7. Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.8. Extraktion von Glossen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.9. Terme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.10. Begriffsklärungsseiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
9. Verarbeitung 53
9.1. Import von Wiki-Seiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.1.1. Konzepte aus Abschnitten . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.1.2. Kategorien und Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . 59
9.1.3. Nachbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
9.2. Zusammenführen des multilingualen Thesaurus . . . . . . . . . . . . . . . . . . 67
9.2.1. Import der Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
9.2.2. Aufbau der sprachübergreifenden Konzepte . . . . . . . . . . . . . . . . 68
9.2.3. Nachbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
9.3. Aufbau der statistischen Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.4. Vorbereitung von Konzeptdaten für den schnellen Zugriff . . . . . . . . . . . . . 74
10. Export 75
10.1. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
10.2. Vokabulare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
10.3. Abbildung des Datenmodells auf RDF . . . . . . . . . . . . . . . . . . . . . . . 81
10.4. Cutoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
10.5. Topic Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
IV. Evaluation 89
11. Statistischer Überblick 90
11.1. Datenbasis und Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
11.2. Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
11.3. Multilinguale Thesauri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
11.4. Verteilung von Termfrequenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
11.5. Verteilung von Knotengraden . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
11.6. Auswertung des Exports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Inhaltsverzeichnis v
12. Akkuratheit der Konzepte 102
12.1. Auswertung der Klassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
12.2. Auswertung der Subsumtion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
12.3. Auswertung der Ähnlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
12.4. Auswertung der Verwandtheit . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
12.5. Auswertung der Termzuordnung . . . . . . . . . . . . . . . . . . . . . . . . . . 108
12.6. Auswertung der Glossen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
13. Analyse von Begriffsklärungsseiten 117
14. Verwandtheit und Disambiguierung 119
14.1. Semantische Verwandtheit zwischen Konzepten . . . . . . . . . . . . . . . . . . 119
14.2. Disambiguierung durch Maximierung der Kohärenz . . . . . . . . . . . . . . . . 125
14.3. Semantische Verwandtheit zwischen Termen . . . . . . . . . . . . . . . . . . . . 129
15. Zusammenfassung 131
15.1. Besonderheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
15.2. Ergebnis und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
V. Anhang 135
A. Wiki-Text 136
A.1. HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
A.2. Einfache Textformatierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
A.3. Wiki-Links und Bilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
A.4. Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
A.5. Vorlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
A.6. Magic Words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
A.7. Parser-Functions und Extension-Tags . . . . . . . . . . . . . . . . . . . . . . . . 141
B. Kommandozeilenschnittstelle 142
B.1. Anwenderschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
B.2. Parameter und Optionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
B.3. Aufruf der einzelnen Programme . . . . . . . . . . . . . . . . . . . . . . . . . . 144
B.4. Datenbank-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
B.5. Konfiguration (Tweaks) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
B.6. Ablaufsteuerung (Agenda) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
B.7. Anpassung an einzelne Wikis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
C. Datenbank 148
C.1. Datenbankstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
C.2. Datenbanktabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
C.3. Zugriffsschicht für die Datenabfrage . . . . . . . . . . . . . . . . . . . . . . . . 158
C.4. Zugriffsschicht für die Datenspeicherung und Verarbeitung . . . . . . . . . . . . 159
Inhaltsverzeichnis vi
D. Datenstrukturen 162
D.1. WikiPage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
D.2. Transferobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
E. Algorithmen 165
E.1. Extraktion von Wiki-Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
E.2. Extraktion von Glossen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
E.3. Analyse von Begriffsklärungsseiten . . . . . . . . . . . . . . . . . . . . . . . . 169
E.4. Zusammenführen von sprachübergreifenden Konzepten . . . . . . . . . . . . . . 172
E.5. Algorithmus zum Entfernen von Zyklen . . . . . . . . . . . . . . . . . . . . . . 175
F. Daten 179
F.1. Wiki-Dumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
F.2. Datenbank-Dumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
F.3. RDF-Dumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
F.4. Bewertungsdaten und Statistiken . . . . . . . . . . . . . . . . . . . . . . . . . . 183
F.5. Daten für Grafiken und Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . 187
G. Quellcode 188
G.1. WikiWord Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
G.2. Verwendete Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
G.3. Bündel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
G.4. Kompilieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
G.5. TeX-Quellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Literaturverzeichnis 194
VI. Rechtliches 206
Lizenz 207
Erklärung 213
Menon:
Und auf welche Weise willst du denn dasjenige suchen, Sokrates, wovon du
überhaupt gar nicht weißt, was es ist?
Denn als welches Besondere von allem, was du nicht weißt, willst du es dir
denn vorlegen und so suchen?
Oder wenn du es auch noch so gut träfest, wie willst du denn erkennen, daß
es dieses ist, was du nicht wußtest?
. . .
Sokrates:
Da die ganze Natur unter sich verwandt ist
und die Seele alles innegehabt hat:
so hindert nichts, daß, wer nur an ein einziges erinnert wird,
was bei den Menschen Lernen heißt,
alles übrige selbst auffinde, wenn er nur tapfer ist
und nicht ermüdet im Suchen.
Denn das Suchen und Lernen ist demnach ganz und gar Erinnerung.
— Platon1
1Platon: Menon; Übersetzung von Friedrich Schleiermacher
Teil I.
Einleitung
1. Grundlagen
Die automatische Verarbeitung von natürlichsprachlichen Texten hat in den letzten Jahren
an Bedeutung gewonnen: Aus der immer größer werdenden Flut von Texten erwächst die
Notwendigkeit, bessere Methoden zu entwickeln, um Texte automatisch zu erfassen, zu filtern,
zu suchen, zu indizieren und zusammenzufassen. Dabei hat sich gezeigt, dass neben geeigneten
Verfahren und ausreichender Speicher- und Verarbeitungskapazität auch maschinell verarbeitbares
Wissen von entscheidender Bedeutung für die Verarbeitung natürlicher Sprache ist
[GABRILOVICH (2006), IDE UND VERONIS (1998)]. Solches Wissen reicht von formalen Ontologien, wie sie
in Expertensystemen und zur Wissensrepräsentation für Künstliche Intelligenz eingesetzt werden,
zu „weichem“, „flachem“ Sprachwissen, z. B. darüber, was ein Name ist, wo ein Satz endet oder
welche Wörter in welcher Sprache für welches Konzept stehen.
Der Nutzen, den so genanntes Weltwissen für Softwaresysteme hat, wird in der Knowledge as
Power Hypothesis von B. G. Buchanan zusammengefasst [BUCHANAN UND FEIGENBAUM (1982)]:
The power of an intelligent program to perform its task well depends primarily on the
quantity and quality of knowledge it has about that task.
Und D.B. Lenat sagt über die Notwendigkeit zu generalisieren, also den Nutzen seiner
Begriffshierarchie [LENAT UND FEIGENBAUM (1991)]:
To behave intelligently in unexpected situations, an agent must be capable of falling
back on increasingly general knowledge.
Weiter sagt Lenat, dass Programme ohne Wissen sehr anfällig (brittle) seien, und nur Aufgaben
bewältigen können, die vom Programmierer vollständig vorhergesehen wurden [LENAT U. A. (1990)].
Ziel der vorliegenden Diplomarbeit ist es nun, eine Sammlung solchen Wissens, nämlich einen
Thesaurus, automatisch aus dem Datenbestand der Wikipedia zu erzeugen. Die Wikipedia bietet
sich für diesen Zweck an, da sie einen großen, aktuellen und wohlstrukturierten Korpus darstellt,
der zudem frei und in einer Vielzahl von Sprachen verfügbar ist.
Die Idee ist, ein Softwaresystem (im Folgenden: WikiWord) zu entwerfen, das in der Lage ist,
Wissen über Bezeichnungen für und die Beziehungen zwischen Konzepten aus der Wikipedia zu
extrahieren. Dieses Wissen ist in der Struktur und den Inhalten der Wikipedia mehr oder weniger
explizit enthalten: Beziehungen werden durch spezielle syntaktische Konstrukte (Markup)
sowie Konventionen über den Aufbau und die Formatierung von Inhalten repräsentiert. Ziel dieser
Diplomarbeit ist es, Methoden zur Auswertung dieser Strukturen zu entwerfen und zu evaluieren,
insbesondere solche Methoden, die ohne eine Betrachtung von natürlicher Sprache, also
der eigentlichen textuellen Inhalte, auskommen. Ein Entwurf für ein Softwaresystem, das
solche Methoden umsetzt, ist in .II beschrieben, detaillierte Informationen über die konkrete
Implementation von WikiWord finden sich unter .III. Die Evaluation wird in .IV erläutert.
1. Grundlagen 3
Bevor der Entwurf und die Implementation von WikiWord dargelegt werden können, werden in
den verbleibenden Abschnitten dieses Kapitels Grundbegriffe geklärt (.1.1), ein Überblick über
wichtige Eigenschaften der Wikipedia geboten (.1.2) sowie verschiedene Arten und Aspekte von
Thesauri betrachtet (.1.3). Das folgende Kapitel gibt dann eine Übersicht über den Stand der
Forschung in Hinblick auf die automatische Erstellung von Thesauri im Allgemeinen und die
Extraktion von Wissen aus der Wikipedia im Speziellen (.2).
1.1. Begriffe
Zunächst eine kurze Übersicht über Begriffe, die in dieser Arbeit spezielle Bedeutung haben:
Wiki: Im Allgemeinen eine Webseite, die von jedem frei bearbeitet werden kann [LEUF UND
CUNNINGHAM (2001)]; im Speziellen ein bestimmtes Wikipedia-Projekt (siehe unten).
Wikipedia: Ein Projekt zur kooperativen Erstellung einer Enzyklopädie unter Verwendung der
Wiki-Technologie (.1.2). Je nach Kontext bezeichnet Wikipedia ein bestimmtes Wikipedia-
Projekt in einer bestimmten Sprache (siehe unten).
MediaWiki: MediaWiki ist die Software, auf der dieWikipedia-Wikis basieren und die für diesen
Zweck von der Wikimedia Foundation entwickelt wird [MW:ABOUT]. MediaWiki ist freie
Software, lizenziert unter der GPL [GPL].
Wikimedia: DieWikimedia Foundation ist eine gemeinnützige Stiftung mit Sitz in St. Petersburg,
Florida, USA, deren Zweck die Förderung von freiem Wissen ist [WM:ABOUT, OKD, FCW].
Sie betreibt Anfang 2008 über 750 Wiki-Projekte [M:SITES, WM:PROJECTS] zu unterschiedlichen
Themen in unterschiedlichen Sprachen, unter anderem auch die Wikipedia-Projekte.
WikiWord: Das im Rahmen dieser Diplomarbeit entwickelte Softwaresystem zur automatischen
Extraktion eines multilingualen Thesaurus aus der Wikipedia.
Projekt: Ein (Wiki-)Projekt ist eine konkrete Website, auf der ein Wiki-System verwendet wird
und eine Gemeinschaft von Benutzern gemeinsam Inhalte zu einem bestimmten Thema erstellt
— zum Beispiel die deutschsprachige Wikipedia (de.wikipedia.org). Im Falle der
Wikipedia korrespondiert ein konkretes Projekt jeweils mit einer Sprache, in der enzyklopädische
Inhalte erstellt werden. Diese Inhalte dienen als Korpus im Sinne dieser Arbeit (siehe
unten).
Sprache: EinWikipedia-Projekt ist immer mit der Sprache assoziiert, in der seine Inhalte verfasst
sind. Jeder Sprache ist ein Code zugeordnet, der als Präfix für Language-Links und als
Subdomain dient (.1.2). Diese Codes folgen imWesentlichen der ISO 639-1 Norm [ISO:639-
1 (2002), M:SITES]. Zum Beispiel verwendet die deutschsprachige Wikipedia den Code de
(und damit die Domain de.wikipedia.org). Ein Sprach-Code identifiziert also auch ein
Wiki-Projekt und damit einen Korpus, aus dem ein (lokaler) Datensatz für den Thesaurus
extrahiert werden kann.
1. Grundlagen 4
Korpus: Ein Korpus ist im Kontext dieser Arbeit eine Sammlung von Wiki-Seiten, die
Gegenstand der Analyse zwecks Erzeugung eines (lokalen) Datensatzes für den Thesaurus
sein kann. Ein Korpus ist immer einer Sprache und einem Wiki-Projekt zugeordnet; mit
dem einer Sprache zugeordneten Korpus ist daher die Menge von Wiki-Seiten gemeint, die
in dem zu der Sprache gehörigen Wikipedia-Projekt enthalten sind.
Seite: Eine (Wiki-)Seite ist eine (Wiki-)Text-Ressource mit einem eindeutigen Namen innerhalb
einesWiki-Projektes und damit einer eindeutigen URL. Sie kann analysiert werden, um aus
ihr Informationen zu gewinnen, die dann zum Aufbau eines Thesaurus verwendet werden
können (siehe .8).
Im Folgenden werden die Namen von Wiki-Seiten serifenlos und kursiv gesetzt, zum
Beispiel: Sprachwissenschaft.
Artikel: Ein Artikel ist eine Wiki-Seite, die ein Konzept definiert. Nicht alle Seiten sind
Artikel, prominente Gegenbeispiele sind Weiterleitungen (Redirects), Begriffsklärungen
(Disambiguations) und Kategorien (siehe .1.2, .8.5); weitere Gegenbeispiele sind Wiki-
Seiten, die im Zuge dieser Arbeit nicht betrachtet werden, wie zum Beispiel Benutzerseiten.
Konzept: Ein Konzept ist im Kontext dieser Arbeit ein (abstrakter oder konkreter)
Betrachtungsgegenstand, in der Wikipedia insbesondere Gegenstand von Artikeln.
Konzepte haben eine Menge von Termen als Bezeichnungen, sie sind somit die Bedeutung
der ihnen zugeordneten Terme, also das Bezeichnete (auch Signifikat, fr. Signifé) im
Sinne der Semiotik de Saussures [DE SAUSSURE (2001), S. 76FF]. Ein wesentlicher Aspekt dieser
Arbeit ist es, diese Beziehung zwischen Konzept und Term zu explizieren, also eine
Bedeutungsrelation aufzubauen. Gemeinsam mit den Beziehungen zwischen Konzepten
bildet die Bedeutungsrelation einen konzeptorientierten Thesaurus [MATTHEWS (2003)] (siehe
.4.2).
Im Folgenden werden die Namen von Konzepten in Kapitälchen gesetzt, zum Beispiel:
SPRACHWISSENSCHAFT.
Term: Ein Term ist im Kontext dieser Arbeit ein Wort oder eine Wortgruppe bzw. Phrase, die
benutzt wird, um auf ein Konzept Bezug zu nehmen—das heißt, er ist eine Bezeichnung für
ein Konzept, also das Bezeichnende (auch Signifikant, fr. Signifiant) im Sinne der Semiotik
de Saussures [DE SAUSSURE (2001), S. 76FF]. Unterschiedliche Wortformen und Schreibweisen
werden dabei als unterschiedliche Terme betrachtet, selbst dann, wenn sie sich nur in der
Großschreibung unterscheiden. Die Bedeutungsrelation zwischen Termen und Konzepten
ist ein wesentlicher Aspekt dieser Arbeit (siehe .4.2 und .8.9).
Im Folgenden werden Terme kursiv und in Anführungszeichen gesetzt, zum Beispiel:
„Sprachwissenschaft“.
Dump: Ein (Wikipedia-)Dump ist eine Datei, die eine Menge von Wikipedia-Seiten enthält,
das heißt, sie beinhaltet den Wiki-Text der betreffenden Seiten sowie die dazugehörige
Meta-Information, eingebettet in eine dafür entworfene XML-Struktur [MW:XML].
Dumps der Wikipedia-Inhalte werden periodisch alle paar Monate erstellt und zur
freien Weiternutzung angeboten [WM:DOWNLOAD]. Es gibt für jede Wikipedia unterschiedliche
Dumps, die verschiedene Mengen von Seiten enthalten. Für diese
1. Grundlagen 5
Arbeit sind diejenigen Dumps relevant, die alle Seiten im Hauptnamensraum (die
„Artikel“) sowie alle Kategorieseiten beinhalten, wobei nur die aktuelle Revision jeder
Seite benötigt wird. Die für diese Anwendung zugeschnittenen Dumps folgen
dem Namensschema wikiname-datum-pages-articles.xml, also zum Beispiel
dewiki-20080320-pages-articles.xml für den Dump der deutschsprachigen
Wikipedia vom 20. März 2008, der die aktuelle Version aller Seiten im Hauptnamensraum
sowie Kategorien und Vorlagen enthält.
Datensatz: Im Zusammenhang dieser Diplomarbeit ist ein Datensatz eine Sammlung von
Informationen über Konzepte und Terme und ihre Beziehungen zueinander. Datensätze gibt
es in zwei Ausprägungen: Lokale (sprachspezifische) Datensätze enthalten die Daten, die
aus einem Korpus in einer bestimmten Sprache extrahiert wurden, sie repräsentieren damit
einen monolingualen Thesaurus (siehe .4.2). Globale Datensätze kombinieren mehrere lokale
Datensätze zu einem multilingualen Thesaurus, indem sie äquivalente Konzepte aus
den einzelnen Sprachen zu jeweils einem sprachunabhängigen Konzept zusammenfassen
(siehe .4.3).
Datensätze werden typischerweise nach dem Wiki benannt, auf dessen Basis sie erstellt
wurden.
Kollektion: Im Zusammenhang dieser Diplomarbeit ist eine Kollektion eine Menge von
Datensätzen, die zusammen einen multilingualen Thesaurus bilden. Eine Kollektion enthält
einen lokalen Datensatz pro betrachteter Sprache sowie einen globalen Datensatz, der
die Konzepte aus den lokalen Datensätzen miteinander verbindet.
Wie in .10.1 beschrieben, wird der Name der Kollektion verwendet, um einen universell
eindeutigen Bezeichner (URI) für den Datensatz zu erzeugen. Es ist daher zweckmäßig,
aussagekräftige und eindeutige Namen für Kollektionen zu verwenden, insbesondere solche,
die Informationen über die verwendeten Wikis, deren Version und eventuelle thematische
Ausschnitte enthalten.
1.2. Wikipedia
Wikipedia ist eine Online-Enzyklopädie, die von Tausenden von Benutzern in Kollaboration erstellt
wird [FIEBIG (2005)]. Sie beruht auf dem „Wiki-Prinzip“, also der Idee, dass jeder, auch ohne
Anmeldung, die Inhalte sofort bearbeiten und erweitern kann [LEUF UND CUNNINGHAM (2001)].Wikipedia
verwendet zu diesem Zweck die MediaWiki-Software [MW:ABOUT], die von der Wikimedia
Foundation [WM:ABOUT] für diesen Zweck entwickelt wird.
Wikipedia zählt Anfang 2008, nur sieben Jahre nach ihrer Gründung im Jahre 2001, mit bis zu
fünfundsechzigtausend Seitenaufrufen pro Sekunde zu den zehn meistgenutzten Webseiten weltweit
[WM:SURVEY (2008), WM:10M (2008)]. Wikipedia-Projekte gibt es in über 250 Sprachen mit
insgesamt über zehn Millionen Artikeln1 [WM:10M (2008), M:SITES, WM:PROJECTS], davon über
1Nach der internen Zählweise von MediaWiki: Alle Artikel im Hauptnamensraum, die keine Weiterleitung sind und
mindestens einen Wiki-Link enthalten; Begriffsklärungsseiten werden also mitgezählt.
1. Grundlagen 6
zwei Millionen in der englischsprachigen und über siebenhunderttausend in der deutschsprachigen
Wikipedia [WM:2M (2007), WP:STATS]. Alle Inhalte sind unter der GFDL lizenziert [GFDL] und
damit frei verwendbar [OKD, FCW]. Der gesamte Korpus der Wikipedia wird periodisch als XML
[MW:XML] in so genannte Dumps exportiert und zur Weiternutzung angeboten [WM:DOWNLOAD].
Die kollaborative Natur von Wikipedia erlaubt eine hohe Aktualität der Inhalte sowie ein rapides
Wachstum der thematischen Abdeckung. Die Anzahl der Seiten in einer Sprache folgt in der Regel
zunächst einer exponentiellen Wachstumskurve [VOSS (2005B)] und scheint sich mittlerweile zu linearem
Wachstum abzuflachen [WP:STATS]. Für die Zukunft ist damit zu rechnen, dass sich das
Wachstum noch weiter verlangsamt, so dass sich insgesamt eine logistische Funktion(„S-Kurve“)
für dasWachstum ergibt. Die Qualität einzelner Artikel in der Wikipedia ist recht unterschiedlich,
insgesamt jedoch mit der Qualität traditioneller Enzyklopädien vergleichbar [GILES (2005)].
Einträge in der Wikipedia sind recht uniform und folgen gewissen Konventionen: insbesondere
beschreibt jede Seite genau ein Konzept [WP:ARTIKEL] (Ausnahmen sind Weiterleitungen und
Begriffsklärungsseiten, siehe unten) und beginnt mit einer Begriffsdefinition (Glosse) [WP:WSIGA].
Da es sich bei der Wikipedia um eine Enzyklopädie handelt, enthält sie vor allem Substantive,
Nominalphrasen und Eigennamen; Verben und Adjektive kommen dagegen kaum vor. Für eine
Verwendung im Bereich des Information Retrieval ist das kaum problematisch (und eventuell
sogar von Vorteil), da zur Klassifikation und Indexierung von Dokumenten ohnehin hauptsächlich
Substantive verwendet werden, weil diese gut geeignet sind, den thematischen Inhalt eines
Dokumentes wiederzugeben, siehe [SYED U. A. (2008), HEPP U. A. (2006), EIRON UND MCCURLEY (2003)] sowie
[WP:V]. Insbesondere enthält die Wikipedia im Gegensatz zu manuell erstellten Thesauri und
Wörterbüchern eine große Zahl von Einträgen über Orte, Personen, Werke und Organisationen
— sie eignet sich daher besonders, um Informationen zu Eigennamen (proper nouns bzw. Named
Entities) zu finden. Auch enthält sie eine Vielzahl von Fachausdrücken aus den verschiedensten
Fachbereichen, die in der Regel in allgemeinen Thesauri und Wörterbüchern nicht enthalten sind.
Eine weitere Eigenheit der Wikipedia betrifft die Granularität ihrer Einträge: zwar deckt die
Wikipedia einen weiten Bereich menschlichenWissens ab, da sie aber eine Enzyklopädie ist, bleiben
die Einträge aus lexikographischer Sicht eher grob: zum Beispiel werden die Begriffe „physikalisch“
und „Physiker“ mit unter den Eintrag für „Physik“ gefasst. Diese Art von Ungenauigkeit
ist aber in Hinblick auf die Indexierung und Klassifikation von Dokumenten, also für eine „oberflächliche“
Analyse von Texten, eher hilfreich als schädlich (vergleiche [IDE UND VERONIS (1998),
S. 22] und [WILKS U. A. (1996), S. 59]). Die fachliche, taxonomische Granularität aber (ob z. B. die
„Atomphysik“ einen eigenen Artikel hat oder mit unter „Physik“ behandelt wird) hängt vor allem
von der Gesamtgröße der Wikipedia ab und variiert damit stark zwischen den verschiedenen
Sprachen — ein Umstand, den es bei der Erstellung des globalen Datensatzes zu berücksichtigen
gilt (siehe .4.3 und .9.2).
Weitere Funktionen, Eigenschaften und Konventionen, die Wikipedia zu einer exzellenten
Ressource für lexikalisch-semantische Informationen machen und im Zusammenhang mit dieser
Arbeit wichtig sind, seien im Folgenden genannt:
Seiten: Ein Wiki enthält ein Netzwerk von (Hypertext-)Seiten, die untereinander eng über
Hyperlinks verknüpft sind [BELLOMI UND BONATO (2005B)]. Jede Seite hat einen eindeutigen
1. Grundlagen 7
Namen, über den sie innerhalb des Wikis über Wiki-Links angesprochen werden kann [LEUF
UND CUNNINGHAM (2001)] und der als URL-Suffix dient, so dass eine eindeutige URI [RFC:3986
(2005)] für diese Seite entsteht.
Der Name der Seite ist in derWikipedia das enzyklopädische Lemma des Artikels. Im Zuge
der vorliegenden Arbeit wird der Seitenname als eindeutiger Bezeichner sowohl für die Seite
(also Ressource) als auch für das Konzept, das auf der Seite beschrieben wird, verwendet
[W3C (2005), BERNERS-LEE (1998)].Welches von beiden gemeint ist, ist im Kontext eindeutig, für
eine externe Darstellung muss aber klar zwischen diesen unterschieden werden; mehr dazu
in Kapitel .10.
Für den Fall, dass die „natürliche“ Bezeichnung zweier Konzepte derselbe Term ist,
wird durch einen sogenannten Klammerzusatz als Qualifikator ein eindeutiges Lemma geschaffen
(ein Klammer-Lemma) [WP:NK]. So wird zum Beispiel zwischen Bock_(Gestell),
Bock_(Turngerät), Bock_(Insel) und Bock_(Dudelsack) sowie Bock_(Familienname) unterschieden
(das Tier dagegen wird unter Huftiere behandelt). In einem solchen Fall gibt
es zusätzlich eine Begriffsklärungsseite (siehe unten), die diese Bedeutungen aufzählt —
sie würde entweder den Namen ohne Klammerzusatz tragen (Bock), oder den Zusatz
„Begriffsklärung“ (also Bock_(Begriffsklärung)) [WP:BKL].
Wiki-Text: Wikis verwenden eine Markup-Sprache, genannt Wiki-Text, die sich im
Funktionsumfang an HTML orientiert, aber leichter für Menschen zu lesen und zu
bearbeiten sein soll [LEUF UND CUNNINGHAM (2001)]. „Wiki-Text“ ist als allgemeine Bezeichnung
zu verstehen, die konkreten Markup-Sprachen verschiedener Wiki-Systeme unterscheiden
sich zum Teil erheblich voneinander. Im Kontext dieser Arbeit ist mit Wiki-Text die von
MediaWiki verwendete Markup-Sprache gemeint (.A).
Beispiele für Wiki-Text werden im Folgenden kursiv in einer nichtproportionalen Schrift
gesetzt, zum Beispiel: [[Sprachwissenschaft]].
Die Art und Weise, wie Wiki-Markup in der Wikipedia verwendet wird [WP:WSIGA], ist
im Vergleich zu Webseiten im Allgemeinen relativ reich an Semantik. Insbesondere die
Verwendung von Vorlagen sowie die Zuweisung von Kategorien sind im Kontext dieser
Arbeit sehr nützlich.
Wiki-Links: Ein wichtiger Aspekt von Wikis ist die leichte Verknüpfbarkeit von Seiten untereinander
[WP:V]. MediaWiki verwendet für diesen Zweck Wiki-Links, die als Name des
Zielartikels in doppelten eckigen Klammern geschrieben werden, z. B. [[Sprache]]. Die
Syntax ist in .A.3 genauer beschrieben. Wiki-Links, die auf eine Seite zeigen, die nicht
existiert, werden von MediaWiki rot dargestellt. Solche „roten Links“ sind nicht als Fehler
zu werten, sondern vielmehr als ein Hinweis auf fehlende Inhalte [WP:RL].
Der Link-Text ist eine wichtige Quelle für die Zuordnung von Termen (dem Link-Text) zu
Konzepten (dem Link-Ziel), das heißt, für den Aufbau der Bedeutungsrelation (siehe .8.7):
Der Link-Text verhält sich zum Link-Ziel ähnlich wie der Titel der Seite (also das Lemma)
zu ihrem Inhalt (dem Konzept) [MIHALCEA (2007)] sowie [CRASWELL U. A. (2001), EIRON UND MCCURLEY
(2003), KRAFT UND ZIEN (2004)].
Namensräume: MediaWiki unterstützt (und Wikipedia nutzt) Namensräume für Wiki-Seiten,
um Seiten mit unterschiedlicher Funktion voneinander zu trennen und Namenskonflikte zu
1. Grundlagen 8
vermeiden [WP:NS]. MediaWiki gibt eine Anzahl von Namensräumen fest vor, darunter solche
für Benutzerseiten, Projektseiten, Hilfeseiten, Kategorien und einige mehr [MW:NS].
Jedem Namensraum ist zudem ein entsprechender Diskussionsnamensraum zugeordnet
(und jeder Seite entsprechend potentiell eine Diskussionsseite, die dazu dient, die Arbeit an
der Seite zu koordinieren). Namensräume werden über einen Präfix am Seitennamen adressiert:
Der Link [[Hilfe:Formatieren]] verweist auf eine Seite im Namensraum Hilfe,
die sich mit Textformatierung befasst. Die Namen (Präfixe) der Namensräume sind sprachabhängig,
eine Liste der Namen der verwendeten Namensräume ist in jedem XML-Dump
enthalten.
Der eigentliche Inhalt des Wikis, im Falle der Wikipedia die enzyklopädische Information,
befindet sich auf Seiten im Hauptnamensraum, dem kein Präfix (oder genauer, der leere
String als Präfix) zugeordnet ist. Seiten im Hauptnamensraum werden auch als Artikel bezeichnet,
insbesondere dann, wenn sie keine Weiterleitungen und keine Begriffsklärungen
sind, wenn sie also ein Konzept beschreiben. Solche Artikel beinhalten das Sachwissen der
Wikipedia.
Interwiki-Links: Auch Verknüpfungen auf andereWikis sind mittels sogenannter Interwiki-Links
bequem möglich: für jedes Wiki, das als Ziel von Interwiki-Links dienen soll, muss dafür
ein Präfix zugewiesen werden, der bei der Definition des Wiki-Links verwendet wird (siehe
.A.3).
Language-Links: Interwiki-Links mit bestimmten Präfixen, die als Sprachcodes definiert sind,
werden besonders behandelt: Sie werden als Verknüpfungen auf eine äquivalente Seite in
einer anderen Sprache in einem anderen Wiki interpretiert (siehe .A.3).
Kategorien: Kategorien erlauben es, Wiki-Seiten zu Gruppen zusammenzufassen. Eine Seite
kann zu beliebig vielen Kategorien gehören und jeder Kategorie ist eine Kategorieseite zugeordnet,
über die sie beschrieben und selbst wieder Kategorien zugeordnet werden kann
[WP:KAT]. Um einer Seite eine Kategorie zuzuweisen, wird auf der Seite einfach ein Wiki-
Link auf diese Kategorie eingefügt, siehe .A.3. Sort-Keys (Sortierschlüssel), die bei der
Zuweisung von Kategorien angegeben wurden, sind eine wichtige Quelle für die Terme, die
einem Konzept zuzuordnen sind (siehe auch .9.1).
Per Konvention bilden Kategorien in der Wikipedia eine thematische Polyhierarchie
[WP:KAT], sie lassen sich damit als semantische Relation der Über- bzw. Unterordnung
(Subsumtion) zwischen den von den Seiten beschriebenen Konzepten interpretieren. Zum
Beispiel wäre das speziellere Konzept UNSINN dem allgemeineren Konzept SEMANTIK untergeordnet.
Dabei ist die Art der Unterordnung unspezifiziert, die Relation bildet also keine
Taxonomie und lässt sich auch nur sehr eingeschränkt in Ontologien verwenden (vergleiche
[PONZETTO UND STRUBE (2007B)]). Diese Relation entspricht der Hyponym-Relation in einem
klassischen, Term-basierten Thesaurus, bzw. der NT/BT-Relation nach ISO 2788 [ISO:2788
(1986)]. Sie bildet zusammen mit der Bedeutungsrelation den Kern des Thesaurus (siehe
.4.2). Zu beachten ist dabei, dass die MediaWiki-Software Zyklen in der Kategoriestruktur
zulässt—diese sind zwar per Konvention unerwünscht, können aber vorkommen und müssen
bei der Erstellung des Thesaurus entfernt werden (siehe .9.1.3).
1. Grundlagen 9
Neben den inhaltlich relevanten Kategorien existieren in der Wikipedia eine Vielzahl von
Wartungskategorien wie zum Beispiel Kategorie:Wikipedia:Lückenhaft, die sich auf die
Seite beziehen, nicht auf das beschriebene Konzept. Solche Kategorien sollten zur Erstellung
eines Thesaurus nicht verwendet werden und werden daher beim Import nach Möglichkeit
ignoriert (siehe .9.1).
Weiterleitungen: Weiterleitungen (Redirects) definieren einen Alias für einen Seitentitel (siehe
.A.6 für eine Beschreibung der Syntax). Eine Wiki-Seite kann über diesen Mechanismus
unter mehreren Namen erreichbar sein. Zum Beispiel könnte USA eine Weiterleitung
auf Vereinigte Staaten von Amerika sein [WP:WL]. Weiterleitungen sind eine wichtige
Quelle für Informationen darüber, welche alternativen Bezeichnungen (Terme) für welche
Konzepte verwendet werden (.A.6).
Vorlagen: MediaWiki unterstützt Vorlagen (Templates) als eine Methode, den Inhalt einer Wiki-
Seite in eine andere einzubinden (siehe .A.5). Beim Einbinden von Vorlagen können sogenannte
Vorlagen-Parameter verwendet werden: Sie erlauben es, beim Einbinden konkrete
Werte anzugeben, die dann für Platzhalter eingesetzt werden, die im Wiki-Text der Vorlage
verwendet wurden [WP:VOR].
Vorlagen werden in der Wikipedia für verschiedene Zwecke benutzt: zur einheitlichen
Anzeige von strukturierten Daten (in sogenannten Infoboxen oder Taxoboxen [WP:IB]),
als Navigationselement zu verwandten Themen (sogenannten Navileisten, [WP:NAVI]), als
Markierung für Probleme mit einer Seite, als Formatierungshilfe im laufenden Text sowie
für diverse andere Zwecke [WP:TB]. Unter anderem werden Vorlagen auch verwendet,
um besondere Arten von Seiten zu kennzeichnen, insbesondere zum Beispiel
Begriffsklärungsseiten. Sie sind daher besonders nützlich, um solche besonderen Seiten zu
erkennen.
Vorlagen sind Gegenstand diverser Arbeiten über die Wikipedia, insbesondere können
Infoboxen leicht für eine Wissensextraktion verwendet werden, die Eigenschaft-Wert-Paare
für die Eigenschaften des Artikelgegenstandes liefert (z. B. bei Auer u. a. (2007), siehe
auch .2.5). In der vorliegenden Arbeit werden Vorlagen jedoch fast ausschließlich zur
Identifikation von Ressourcen- und Konzepttypen verwendet (siehe .8.5 bzw. .8.6 sowie
.8.4).
Magic Words: MediaWiki verwendet zwei Arten von Magic Words: „Variablen“, die Zugriff auf
kontext- oder projektspezifischeWerte bieten und „Optionen“, die die Verarbeitung der Seite
beeinflussen (siehe .A.6).
Die meisten Magic Words werden für den Zweck dieser Arbeit ignoriert; manche
Variablen aber, insbesondere eben der Seitenname, werden vor der Bearbeitung durch
den betreffenden konkreten Wert ersetzt (siehe .8.3). Einige weitere werden ähnlich wie
Vorlagen interpretiert, um zusätzliche Informationen zu gewinnen — Beispiele hierfür
sind {{DISPLAYTITLE:...}} und {{DEFAULTSORT:...}} (vergleiche .8.4). Ein weiteres
Beispiel für Magic Words, die vonWikiWord verwendet werden, sind die Markierungen
für Weiterleitungsseiten, siehe .A.6.
Extension-Tags und Parser-Functions: MediaWiki bietet zwei Möglichkeiten für die
Erweiterung des Wiki-Text-Markups an: Extension-Tags verwenden Tags der Form
1. Grundlagen 10
<mytag>...</mytag>, Parser-Functions verwenden vorlagenartige Strukturen der Form
{{#mytag:argument}} (siehe auch .A.7). Beide Formen werden bei der Analyse von
Wiki-Text im Rahmen dieser Arbeit vollständig ignoriert (siehe .8.3).
Begriffsklärungen: Begriffsklärungsseiten (Disambiguierungen) sind eine wichtige Konvention
in Wikipedia-Projekten: Gibt es mehrere unterschiedliche Bedeutungen zu einem Term, so
wird für diesen Term eine Begriffsklärungsseite angelegt, die alle Bedeutungen des Terms
aufzählt [WP:BKL]. Dazu wird in der Regel eine Listenstruktur verwendet, die in jeder Zeile
eine Glosse für eine der Bedeutungen hat und auf den entsprechenden Artikel verweist.
Wie schon oben erwähnt, wird die Begriffsklärungsseite entweder direkt mit dem fraglichen
Term als Name angelegt oder mit dem Zusatz (Begriffsklärung) —in letzterem Fall enthält
per Konvention die Seite ohne Namenszusatz (die Seite zur Hauptbedeutung des Terms)
einen Verweis auf die Begriffsklärungsseite.
Wie auch Weiterleitungen sind Begriffsklärungen im Kontext dieser Arbeit eine wichtige
Quelle für die Bedeutungsrelation, also um alle Bedeutungen eines Terms und umgekehrt
alle Bezeichnungen für ein Konzept zu finden (siehe .8.10).
1.3. Thesauri
Ein Thesaurus ist traditionell eine Sammlung von Termen (Wörtern), ihrer Beziehungen und
Definitionen. Die verschiedenen Beziehungen dienen insbesondere dazu, den passendsten Term
für einen Gegenstand, das heißt, die beste Bezeichnung für ein Konzept zu finden. Ein Thesaurus
ist daher besonders als Struktur für ein kontrolliertes Vokabular geeignet, das zur Indexierung von
Dokumenten verwendet werden soll.
Thesauri definieren in der Regel zumindest eine Äquivalenzbeziehung zwischen synonymen
und pseudo-synonymen (also für den Zweck der Indexierung gleichwertigen) Termen, eine
(poly-)hierarchische Subsumtionsbeziehung zwischen allgemeinen und speziellen Termen sowie
häufig eine Assoziationsbeziehung zwischen semantisch verwandten Termen [STOCK (2007), S. 283FF].
Die ISO definiert insbesondere die folgenden Relationen [ISO:2788 (1986)]:
UF bzw. USE: Used For bzw. Use gibt an, dass ein Term anstelle eines anderen verwendet werden
soll — über diese Relation wird der Deskriptor (Preferred Term) aus einer Menge von
(Pseudo-)Synonymen (einem sogenannten SynSet) festgelegt.
BT bzw. NT: Broader Term bzw. Narrower Term gibt an, dass ein Term allgemeiner bzw. spezieller
als ein anderer, das heißt, ein Hyperonym bzw. Hyponym zu diesem ist.
RT: Related Term gibt an, dass ein Term mit einem anderen semantisch verwandt ist. Diese
Beziehung besteht häufig unter anderem zwischen Kohyponymen.
Synonyme können so direkt modelliert werden, Homonyme dagegen nicht: häufig werden sie
disambiguiert, indem ein Qualifikator als Zusatz angehängt wird, entweder direkt als Teil des
Terms oder über eine spezielle Relation.
1. Grundlagen 11
Die hierarchische Beziehung (Hyponymiebeziehung) in einem Thesaurus ist häufig als Taxonomie
angelegt, also als eine strenge thematische Gliederung, über die Terme in Sachgebiete eingeordnet
werden. Die Hyponymiebeziehung kann auch als Polyhierarchie angelegt sein, so dass sich insgesamt
ein gerichteter, azyklischer Graph als Struktur bildet, anstelle eines einfachen Baums. Die
Semantik der Hyponymiebeziehung ist in der Regel nicht weiter spezifiziert, meist handelt es sich
um eine Vermengung der Abstraktionsbeziehung (subtype), der Instanzbeziehung (is-a), der
Aggregationsbeziehung (part-of) und gelegentlich der Attributbeziehung (property-of) [VOSS
(2006), PONZETTO (2007)].
Im Kontext der automatischen Verarbeitung von Wissen, Sprachen und Dokumenten erweist es
sich als hilfreich, eine weitere Ebene der Indirektion einzuführen und so zu einem „konzeptorientierten
Thesaurus“ zu gelangen, der auf einem Konzept-Term-Netzwerk basiert statt auf einem
reinen Netzwerk von Termen [JOHNSTON U. A. (1998), MATTHEWS (2003), W3C (2005)]. So ergibt sich ein
Wissensorganisationssystem (Knowledge Organisation System, KOS). Dieses Modell scheint insbesondere
auch besser auf die Datenstruktur derWikipedia zu passen: Es werden die semantischen
Beziehungen zwischen Konzepten direkt modelliert und zusätzlich angegeben, welche Terme zu
welchem Konzept gehören (vergleiche [VAN ASSEM U. A. (2006), GREGOROWICZ UND KRAMER (2006)]). Die
Beziehungen zwischen Termen (Homonym, Synonym) ergeben sich dann implizit (.4.2). Ein ähnliches
Modell wird auch von WordNet verwendet, in dem Konzepte durch SynSets repräsentiert
und semantische Beziehungen zwischen SynSets statt zwischen Termen modelliert werden [MILLER
(1995), FELLBAUM (1998), WORDNET].
In einem solchen konzeptorientierten Thesaurus gibt es nun vor allem die folgenden Beziehungen:
Bedeutung: Verbindet einen Term mit einer Anzahl von Konzepten (Bedeutungen), bzw. ein
Konzept mit einer Anzahl von Termen (Bezeichnungen). Daraus ergibt sich implizit die
Synonymie oder Homonymie von Termen.
Subsumtion: Verbindet allgemeinere mit spezielleren Konzepten, analog zu der
Hyponymierelation zwischen Termen.
Verwandtheit: Verbindet verwandte Konzepte, z. B. solche, die zu einem gemeinsamen
Themengebiet gehören oder häufig im selben Kontext verwendet werden.
Ähnlichkeit: Verbindet ähnliche Konzepte, z. B. solche, die zu einem gewissen Grade austauschbar
sind. Ähnliche Konzepte sind häufig Kohyponyme. Für eine Abgrenzung von semantischer
Verwandtheit und Ähnlichkeit siehe [ZESCH U. A. (2007B)].
Die semantischen Beziehungen in einem solchen Thesaurus sind aber weiterhin relativ „schwach“:
Wie schon oben für die Hyponymierelation, ist auch hier im Gegensatz zu den Relationen in einer
Ontologie nichts über die Art der Subsumtion (Subtyp, Instanz, Teil etc.) oder der Verwandtheit
bekannt [PONZETTO UND STRUBE (2007B), HEPP U. A. (2006)]. Auch können Relationen nicht reifiziert oder
klassifiziert werden. Solche schwachen Beziehungen sind aber für die Zwecke des Information
Retrieval in aller Regel ausreichend.
Ziel dieser Diplomarbeit ist es nun, einen solchen konzeptorientierten Thesaurus auf Grundlage
des Datenbestandes der Wikipedia vollautomatisch zu erstellen.
1. Grundlagen 12
1.4. Nutzen
Der Nutzen von Thesauri (insbesondere der konzeptorientierten Art) für die automatische
Sprachverarbeitung und für das Information Retrieval liegt in der Überbrückung der Semantic
Gap zwischen dem bloßen Text als Folge von Zeichen und dem konzeptuellen Inhalt von
Dokumenten [DAVULCU U. A. (2006), GREGOROWICZ UND KRAMER (2006)]. Handelt es sich um einen multilingualen
Thesaurus, kann auf dieseWeise auch die Kluft zwischen verschiedenen Sprachen überwunden
werden: Verschiedene Terme (Wörter und Phrasen) aus verschiedenen Sprachen werden
auf eine relativ kleine Menge wohldefinierter Konzepte abgebildet, die untereinander in Beziehung
stehen. Die in einem Dokument behandelten Konzepte werden so einer automatischen Analyse zugänglich.
Konkret kann ein maschinenlesbarer, multilingualer, konzeptorientierter Thesaurus insbesondere
in den folgenden Bereichen nützlich sein:
1. Für das klassische Information Retrieval ist es vorteilhaft, statt Termen abstrakte Konzepte
für die Indexierung von Dokumenten verwenden zu können: so lassen sich Unterschiede in
Sprache und Terminologie leicht überbrücken. Häufig werden Konzepte als Mengen von
Termen modelliert, die durch Clustering-Verfahren gewonnen wurden, wie beim Latent
Semantic Indexing (LSI) [DEERWESTER U. A. (1990), KUMAR U. A. (2006)]. Die Verwendung eines konzeptorientierten
Thesaurus erlaubt es dagegen, menschliches Wissen über die Zuordnung
von Termen zu Konzepten zu nutzen (siehe .2.4 und insbesondere [MILNE UND NICHOLS (2007)]).
Neben der klassischen Dokumentensuche profitieren auch Aufgaben wie Resource Selection
und Topic Tracking von diesem Ansatz.
2. Ein Thesaurus auf Basis der Wikipedia eignet sich besonders für die Named Entity
Recognition (NER), da Wikipedia im Gegensatz zu klassischen Wörterbüchern eine große
Zahl von Einträgen zu Orten, Personen und Organisationen hat (siehe .2.6).
3. Die Informationen über ähnliche, verwandte und übergeordnete Konzepte, die in einem
Thesaurus enthalten sind, können unter anderem für eine gezielte Query Expansion verwendet
werden [MILNE UND NICHOLS (2007)]. Es ist zu erwarten, dass dies besonders dann effektiv ist,
wenn die Indexierung und Abfrage anhand von Konzepten statt von Termen erfolgt, da so
Mehrdeutigkeiten vermieden werden können [SYED U. A. (2008)].
4. Die Verwandtheitsbeziehungen zwischen Konzepten können auch verwendet werden, um
Terme im Kontext zu disambiguieren: Für eine Menge von Termen kann die Bedeutung
jedes Terms so gewählt werden, dass die Bedeutungen (Konzepte) gut zueinander passen
— auf diese Weise lässt sich mit großer Wahrscheinlichkeit die intendierte Bedeutung der
Terme finden [MIHALCEA (2007), STRUBE UND PONZETTO (2006), CUCERZAN (2007)], siehe .2.3. Diese
Bedeutungszuweisung ist neben der Anwendung auf Suchanfragen auch wichtig bei der
Wissensextraktion, dem Topic Tracking sowie der automatischen Übersetzung.
5. Ein multilingualer Thesaurus kann auch als Basis für ein Übersetzungswörterbuch oder
gar ein automatisches Übersetzungssystem dienen. Die aus der Wikipedia gewonnenen
Informationen bieten hier eine nützliche Ergänzung zu traditionellen Wörterbüchern, da sie
1. Grundlagen 13
eine große Zahl von Fachbegriffen sowie viele Namen für Orte und Personen abdecken, die
in manuell gepflegten Wörterbüchern in der Regel fehlen.
6. Ein aus der Wikipedia gewonnener multilingualer Thesaurus kann auch als Basis für eine
(teil-)manuelle Erstellung von Wörterbüchern, Taxonomien und Ontologien dienen. Für
Ontologien und Wissensrepräsentationssysteme wie DBpedia oder YAGO kann es auch
möglich sein, Informationen aus der Wikipedia automatisch zu integrieren (siehe .2.2 und
.2.5).
7. Viele der weiter unten in .2 beschriebenen Systeme und Verfahren verwenden als Grundlage
eine aus derWikipedia extrahierte Struktur, die deutlich weniger Informationen berücksichtigt
als WikiWord. Sie könnten vermutlich davon profitieren, WikiWord als Werkzeug für
die Extraktion der Wikipedia-Struktur zu verwenden, um dann die betreffenden Verfahren
auf diese reichere Struktur anzuwenden.
Ein wichtiger Aspekt des in der vorliegenden Diplomarbeit vorgeschlagenen Ansatzes ist es, dass
der Aufbau des Thesaurus aus denWikipedia-Daten vollautomatisch und verhältnismäßig schnell2
erfolgt: Die manuelle Wartung eines Thesaurus ist sehr aufwändig und teuer, um so mehr, je mehr
Fachgebiete der Thesaurus abdecken soll. So ist es kaum möglich, einen Thesaurus auf dem neusten
Stand zu halten, insbesondere in Hinblick auf neue Technologien oder auch aktuell wichtige
Organisationen und Personen. Schon deshalb decken die meisten Thesauri nur einen eng eingegrenzten
Fachbereich ab und enthalten nur relativ wenige Terme bzw. Konzepte: WordNet zum
Beispiel enthält etwa 117 000 Konzepte (SynSets) [WORDNET], MeSH kennt nur 24 767 Konzepte
[MESH] (siehe auch .2.2).
Ein Thesaurus, der automatisch aus Wikipedia-Daten erstellt wird, hat diese Probleme nicht:
Wikipedia ist sehr aktuell und deckt sehr weite Bereiche des menschlichenWissens ab [RUIZ-CASADO
U. A. (2005), VOSS (2005B)] (WikiWord liefert etwa 6 Millionen Konzepte und 12 Millionen Terme für
die englische Sprache, vergleiche .11.2). Insbesondere sind genau solche Themenbereiche abgedeckt,
die im Augenblick besonders im öffentlichen Bewusstsein stehen und daher besonders
interessant sind für das Information Retrieval (vergleiche [SYED U. A. (2008), HEPP U. A. (2006), MILNE UND
NICHOLS (2007)]). Zudem stehen die Daten unter einer freien Lizenz und sind in einer Vielzahl von
Sprachen verfügbar.
Ein multilingualer, konzeptorientierter Thesaurus auf Wikipedia-Basis besitzt also das Potential,
für wichtige Aufgaben des Information Retrieval und der automatischen Sprachverarbeitung eine
breite, aktuelle und qualitativ hochwertige Datenbasis zu liefern. Außerdem kann er verwendet
werden, um existierende, manuell gewartete Thesauri zu ergänzen und zu erweitern.
2Einige Tage bis Wochen auf einem üblichen Datenbanksystem, siehe .11.1.
2. Einordnung
Im Folgenden wird ein Überblick über den Stand der Forschung in Bereichen gegeben, die
in Bezug auf den Gegenstand der vorliegenden Arbeit besonders relevant sind. Insbesondere
werden Arbeiten betrachtet, die entweder die Wikipedia selbst zum Gegenstand haben oder
Inhalte und Struktur der Wikipedia nutzen, um Aufgaben aus dem Bereich der automatischen
Sprachverarbeitung und des Information Retrieval zu bewältigen.
2.1. Untersuchung von Struktur und Qualität der Wikipedia
Die Wikipedia findet seit dem Jahr 2005 zunehmend Beachtung in der Forschung, sowohl
als Gegenstand von Untersuchungen als auch als Datenbasis oder Korpus für Verfahren zur
Bewältigung einer Vielzahl von unterschiedlichen Aufgaben.
Im Bereich der Arbeiten, die allgemeine Eigenschaften der Wikipedia untersuchen, wie zum
Beispiel das Wachstum oder die Verknüpfungsstruktur, sind vor allem die Arbeiten von J. Voß
zu nennen [VOSS (2005A), VOSS (2005B)] sowie ein Vortrag von J. Wales, dem Gründer1 der Wikipedia
[WALES (2004)]. A. Capocci et. Al. untersuchen die Eigenschaften der Wikipedia insbesondere in
Hinblick auf das Modell des Preferential Attachment [CAPOCCI U. A. (2006)], während F. Bellomi und
R. Bonato gängige Algorithmen wie HITS und PageRank zur Bestimmung der Relevanz bzw.
Autorität auf die Wikipedia anwenden [BELLOMI UND BONATO (2005B), BELLOMI UND BONATO (2005A)].
Gegen die Verwendung der Wikipedia als Datenbasis für Verfahren der Wissens- und
Sprachverarbeitung gab es lange Zeit (und gibt es zum Teil noch immer) den Vorbehalt, dass
die Qualität der Inhalte zu schlecht oder zumindest zu unzuverlässig sei, um sie bedenkenlos
verwenden zu können. Anlass für diese kritische Haltung war und ist zumeist der Umstand,
dass die Wikipedia jederzeit von jedermann frei bearbeitet werden kann und Vorkehrungen zur
Qualitätssicherung wie in einem traditionellen Redaktionssystem weitgehend fehlen. Dem wurde
von Seiten der Wikimedia Foundation sowie der Nutzer der Wikipedia entgegengehalten,
dass neben dem Einbringen neuer Informationen eben auch die redaktionellen Aufgaben wie
Qualitätssicherung von jedermann übernommen werden können und auch tatsächlich übernommen
werden [WALES (2004)]. Seit dem Jahr 2006 ist es erklärtes Ziel der Wikipedia, die Qualität
und Verlässlichkeit der Artikel zu verbessern [WP:100K]. In der Wikipedia werden seit ihrer
Gründung, aber besonders seit 2006, immer neue Strukturen und Verfahren entwickelt, um die
Qualität der Artikel zu verbessern. Beispiele aus der deutschsprachigen Wikipedia sind das
Qualitätssicherungsprojekt [WP:QS], die Auszeichnung von exzellenten Artikeln [WP:EA] sowie, als
Experiment seit Mai 2008, das Verfahren der gesichteten Versionen [WP:GS]: Änderungen, die von
anonymen oder neuen Benutzern vorgenommen werden, werden nicht mehr sofort, sondern erst
nach einer ersten (oberflächlichen) Prüfung der Allgemeinheit präsentiert.
1Oder Mitbegründer. Ob die Erfindung der Wikipedia alleine Jimmy Wales zuzuschreiben ist, oder inwieweit die Idee
auf Larry Sanger zurückgeht, ist Gegenstand eines andauernden Streits zwischen eben jenen.
2. Einordnung 15
Die erste und wohl bekannteste Studie zur Qualität der Inhalte der Wikipedia wurde von
J. Giles im Jahr 2005 für die Zeitschrift Nature durchgeführt [GILES (2005)]. Giles vergleicht
hier eine Anzahl von Artikeln aus der Wikipedia mit den entsprechenden Einträgen in der
Encyclopaedia Britannica und kommt zu dem Ergebnis, dass die Wikipedia dem traditionellen
Nachschlagewerk in Bezug auf die Qualität kaum unterlegen und in Bezug auf die
Ausführlichkeit der Beschreibungen und die Abdeckung von aktuellen Themen gar überlegen ist.
Diese Untersuchung hatte zur Folge, dass die Wikipedia zunehmend als ernstzunehmende und
verlässliche Wissensbasis betrachtet und untersucht wurde.
Detailliertere und differenziertere Untersuchungen zur Qualität der Wikipedia wurden vor allem
von R. Hammwöhner durchgeführt [HAMMW¨OHNER (2007A), HAMMW¨OHNER (2007B), HAMMW¨OHNER (2007)].
Hierbei wurde insbesondere deutlich, dass die Qualität einzelner Artikel stark divergiert: es gibt
in Bezug auf die untersuchten Eigenschaften sowohl Beispiele sehr geringer, wie auch sehr hoher
Qualität. Diese Untersuchungen beruhen zum Teil auf den Kriterien, die von Stvilia et. Al. für die
Evaluation von Enzyklopädien entwickelt wurden [STVILIA U. A. (2005)]. Probleme sieht Hammwöhner
besonders im Bereich der Wissensorganisation zum Beispiel in Form des Kategoriesystems, welches
insbesondere für die englischsprachige Wikipedia als schlecht strukturiert und zum Teil fehlerhaft
befunden wurde. Er schlägt vor, die Kategoriestrukturen aus mehrerenWikipedias über die
Language-Links, die sie verbinden, zu vergleichen und auf diese Weise Probleme aufzudecken
und zu beseitigen [HAMMW¨OHNER (2007B)].
2.2. Maschinenlesbare Wissensbasen
Es existieren bereits einige Versuche, eine maschinenlesbare Wissensbasis zur Verfügung zu stellen,
die als Grundlage für ein weites Feld an Verfahren aus den Bereichen der automatischen
Sprachverarbeitung, des Information Retrieval, aber auch der Wissensrepräsentation und künstlichen
Intelligenz dienen können. Zwei der ältesten und bekanntesten Systeme dieser Art sind Cyc
und WordNet:
Das Cyc-Projekt bietet eine manuell gepflegte, logikbasierte Ontologie mit etwa 300 000
Konzepten und 3 000 000 Verknüpfungen bzw. Aussagen über diese Konzepte (47 000 Konzepte
und 300 000 Aussagen in der Open-Source-Version OpenCyc) [LENAT U. A. (1990), CYC, OPENCYC].
Es wird seit 1984 unter der Leitung von D. Lenat entwickelt und hat seine Wurzeln in der klassischen
KI-Forschung. Ziel des Cyc-Projektes ist es, Softwaresystemen Zugang zu „gesundem
Menschenverstand“ („Common Sense“), also Weltwissen, zu bieten. Neben der Ontologie enthält
es auch ein Lexikon, das (englische) Terme auf Konzepte der Ontologie abbildet.
WordNet ist ein von Hand erzeugtes semantisches Lexikon der englischen Sprache, es besteht
aus etwa 117 000 SynSets (Konzepten) mit etwa 155 000 Wörtern [MILLER (1995), FELLBAUM (1998),
WORDNET]. Zwischen den Konzepten sind die für Thesauri üblichen Relationen definiert, wie allgemeiner/
spezieller und verwandt sowie einige speziellere, wie Aggregationsbeziehung (part-of ).
WordNet stammt aus dem Bereich der automatischen Sprachverarbeitung, es wird seit 1985 von
G. A. Miller und in jüngerer Zeit von C. Fellbaum betreut.
Eine neuere Entwicklung stellt SUMO (Suggested Upper Merged Ontology) dar, das eine gemeinsame
standardisierte „obere“ Ontologie für verschiedene Anwendungen im Bereich Suche,
2. Einordnung 16
automatisches Schließen sowie automatische Sprachverarbeitung bieten soll [NILES UND PEASE (2001),
SUMO, IEEE:SUO-WG]. SUMO wird seit dem Jahr 2000 vom IEEE entwickelt und enthält Anfang
2008 etwa 20 000 handverlesene Konzepte und 70 000 Aussagen (Axiome). Für SUMO gibt es
eine vollständige Abbildung auf WordNet, mit deren Hilfe Wörter der englischen Sprache an die
abstrakten Konzepte der Ontologie gebunden werden können.
Lange vor solchen maschinenlesbaren Wissensbasen, die auf die Verwendung im Bereich
der automatischen Sprachverarbeitung und künstlichen Intelligenz ausgerichtet sind, gab es
Klassifikationssysteme bzw. kontrollierte Vokabulare für die Indexierung von Dokumenten, insbesondere
für die Verwendung in Bibliotheken. Einige prominente Beispiele sind DDC (Dewey
Decimal Classification [DEWEY (1965), DDC]) und die komplexere UDC (Universal Decimal
Classification [OTLET UND FONTAINE (1905), UDC]) sowie die LLC (Library of Congress Classification
[LCC, CHAN (1986)]). In Deutschland ist außerdem die ASB (Allgemeine Systematik für Öffentliche
Bibliotheken [VBNW (2003)]) verbreitet.
Neben diesen breit angelegten Systemen gibt es eine Vielzahl von fachspezifischen Thesauri,
die für die Indexierung von Dokumenten in bestimmten Fachbereichen und/oder für bestimmte
Institutionen entwickelt wurden. Bekannte Beispiele dafür sind unter anderem MeSH (die Medical
Subject Headings der United States National Library of Medicine [LIPSCOMB (2000), MESH], das von
MEDLINE und PubMed für Arbeiten im Bereich Medizin und Biologie verwendet wird) und die
CR Classification (das ACM Computing Classification System für die Klassifikation von Arbeiten
aus dem Bereich Informatik und Informationstechnologie [COULTER U. A. (1998), CCS]).
Wissensbasen, die auf Informationen aus der Wikipedia beruhen, sind in den letzten Jahren ebenfalls
entstanden. Zu nennen sind hier einerseits YAGO, dasWordNet als ein strukturelles Rückgrat
verwendet, um die Inhalte der Wikipedia zu organisieren [YAGO]. Andererseits ist DBpedia zu erwähnen,
welches strukturierte Daten wie Attribut-Wert-Paare aus der Wikipedia extrahiert und in
einer RDF-Datenbank ablegt [DBPEDIA]. Diese beiden Datenbasen, sowie die Systeme, mit deren
Hilfe sie erstellt wurden, werden in .2.4 bzw. .2.5 noch etwas genauer betrachtet.
Ein weiteres derartiges Projekt ist Freebase, dessen Ziel es ist, eine frei zugängliche Datenbank zu
schaffen, in dem dasWissen derWelt verknüpft ist [FREEBASE]. Die Idee ist es, Daten aus unterschiedlichen
Quellen miteinander zu kombinieren und über eine einheitliche Schnittstelle zugänglich zu
machen. Freebase enthält Daten unter anderem aus der Wikipedia, aus PubMed2, dem CIA World
Factbook3 und diversen anderen Quellen.
Ziel von WikiWord ist es nun, Daten zu liefern, die solche Systeme ergänzen und bereichern
können. Insbesondere die Möglichkeit, Terme aus unterschiedlichen Sprachen auf ein gemeinsames
abstraktes Konzept abzubilden, sowie eine Vielzahl von Bezeichnungen für dasselbe
Konzept in jeder Sprache zu unterstützen, soll einen Beitrag dazu leisten, die Inhalte solcher
Wissensdatenbanken auf natürlichsprachliche Texte wie Dokumente oder Suchanfragen anwenden
zu können.
2<http://www.pubmedcentral.nih.gov/>
3<https://www.cia.gov/library/publications/the-world-factbook/index.html/>
2. Einordnung 17
2.3. Automatische Disambiguierung und semantische
Verwandtheit
Zwei eng miteinander verwandte Aufgaben aus dem Bereich der automatischen
Sprachverarbeitung und des Information Retrieval, die beide ein gewisses Maß an Weltwissen
benötigen, sind die automatische Disambiguierung (Sinnzuweisung, Bedeutungszuweisung) von
Termen sowie die Bestimmung des Grades der semantischen Verwandtheit und Ähnlichkeit
von Termen bzw. Konzepten. Die Datenbasis, die für diese Aufgaben benötigt wird, ist ein
Assoziationsnetz von Termen und/oder Konzepten, wie es durch einen Thesaurus gegeben ist.
Die Wikipedia erfreut sich in jüngster Zeit wachsender Beliebtheit als Grundlage für die automatische
Erstellung einer solchen Datenbasis, da sie ein weites Feld von Themen abdeckt und dabei
sehr aktuell ist. Zu nennen sind hier zunächst die Arbeiten von M. Strube und S. P. Ponzetto, die
Verfahren zur Extraktion von Thesauri und Taxonomien aus der Wikipedia entwickelt [PONZETTO
(2007), PONZETTO UND STRUBE (2007B)] und verschiedene Methoden zur Berechnung der semantischen
Verwandtheit zwischen Konzepten evaluiert haben [PONZETTO UND STRUBE (2007C), STRUBE UND PONZETTO
(2006), PONZETTO UND STRUBE (2007A)]. Hierbei wurden vor allem die Kategoriestruktur der Wikipedia
sowie die Querverweise zwischen Artikeln verwendet.
R. Mihalcea dagegen betrachtet vor allem die Beziehung zwischen Link-Text und Link-Ziel und
interpretiert diese als Bedeutungsannotation (Sense-Tags) [MIHALCEA (2007)]. Konkret verwendet er
Wikipedia als Trainingsmenge für einen Klassifikator zur automatischen Bedeutungsannotation.
E. Gabrilovich verwendet verschiedene Eigenschaften von Wikipedia-Artikeln, um einen
Klassifikator zu trainieren, der Dokumente kategorisiert [GABRILOVICH (2006), GABRILOVICH UNDMARKOVITCH
(2006), GABRILOVICH UND MARKOVITCH (2007)]. Ebenfalls mit der Klassifikation von Dokumenten mit Hilfe
der Informationen aus derWikipedia befasst sich P. Schönhofen [SCH¨ONHOFEN (2006)]. A. Krizhanovsky
verwendet die Struktur vonWikipedia, um ähnliche Seiten zu gruppieren und so Synonymgruppen
zu finden [KRIZHANOVSKY (2006)].
Die Forschung von T. Zesch und I. Gurevych gilt besonders der Berechnung von semantischer
Verwandtheit und der Evaluation von Wikipedia als Datenbasis für diesen Zweck, im Vergleich
unter anderem zu WordNet [ZESCH U. A. (2007A), ZESCH U. A. (2007B), ZESCH UND GUREVYCH (2007)], besonders
unter Verwendung der Kategoriestruktur. Auf diese Arbeiten wird insbesondere bei der Evaluation
in Kapitel .14 Bezug genommen.
K. Nakayama et. Al. untersuchen neben Maßen für die semantische Verwandtheit auch Maße für
die Relevanz und Zentralität von Konzepten, insbesondere auf Basis der Struktur der Querverweise
über Wiki-Links [NAKAYAMA U. A. (2007B), NAKAYAMA U. A. (2007A)]. Dabei untersuchen sie unter anderem,
inwieweit sich eine Beschränkung der Suchtiefe bei der Analyse der Verknüpfungsstruktur auf die
Ergebnisse auswirkt.
Die Evaluation all dieser Ansätze zeigt jeweils, dassWikipedia als Datenbasis für solche Aufgaben
beachtliche Ergebnisse liefert, in der Präzision häufig an manuell gewartete Wissensnetze wie
WordNet heran reicht und diesen in Bezug auf die Abdeckung von Spezialausdrücken oder aktuellen
Themen sogar überlegen ist.
In diesem Zusammenhang ebenfalls erwähnenswert sind die Arbeiten von M. Jarmasz und
S. Szpakowicz, die Roget’s Thesaurus auf seinen Nutzen für die Bestimmung semantischer
2. Einordnung 18
Verwandtheit untersucht haben [JARMASZ UND SZPAKOWICZ (2001), JARMASZ UND SZPAKOWICZ (2003)]. Dabei
haben sie insbesondere den Wert einer reichen Taxonomie für diese Aufgabe herausgestellt.
2.4. Erzeugung von Thesauri und Taxonomien
Die Idee, Wikipedia als lexikalisch-semantische Datenbasis zur Erstellung von Thesauri und
Taxonomien zu verwenden, ist schon verschiedentlich Gegenstand der Forschung gewesen. Auch
die oben beschriebenen Systeme zur Untersuchung von semantischer Verwandtheit verwenden alle
ein Thesaurus-artiges Assoziationsnetzwerk, insbesondere die Arbeiten von M. Strube und S. P.
Ponzetto, die von E. Gabrilovich, von T. Zesch und I. Gurevych sowie die von K. Nakayama et. Al.
Im Folgenden werden einige Untersuchungen aufgeführt, die den Aufbau eines Thesaurus oder
einer Taxonomie unmittelbar zum Ziel haben.
A. Gregorowicz und M. A. Kramer bauen auf Grundlage der Wikipedia ein Term-Konzept-
Netzwerk auf, das Relationen zwischen Konzepten sowie die Zuordnungen von Termen zu
Konzepten enthält, sehr ähnlich der Struktur, die auch in der vorliegenden Diplomarbeit verwendet
wird [GREGOROWICZ UND KRAMER (2006)]. D. Milne et. Al. untersuchen eine ähnliche Struktur insbesondere
in Hinblick auf eine Verwendung für die Indexierung von Dokumenten und das Information
Retrieval [MILNE U. A. (2006), MILNE UND NICHOLS (2007), MILNE U. A. (2007)]. Sie entwickeln eine wissensbasierte
Suchmaschine namens Koru, um die Eignung der aus der Wikipedia gewonnenen Daten für
Indexierung und Suche zu demonstrieren.
J. Voß untersucht, wie sich das Kategoriesystem der Wikipedia zu anderen Indexierungs- und
Klassifikationssystemen verhält [VOSS (2006)]. M. Ruiz-Casado et. Al. ordnen Wikipedia-Einträge
automatisch WordNet-SynSets zu und evaluieren die relative Abdeckung und Granularität dieser
beiden Wissensbasen [RUIZ-CASADO U. A. (2005)]. F. M. Suchanek et. Al. kombinieren ebenfalls
Wikipedia und WordNet, allerdings mit dem Ziel, Wikipedia-Einträge als Individuen bzw.
Instanzen von Klassen zu verwenden, die von WordNet-Einträgen gebildet werden [SUCHANEK U. A.
(2007)]. Auf diese Weise entsteht eine neue Wissensstruktur, YAGO, die die Wohlstrukturiertheit
von WordNet mit der Informationsfülle und Aktualität der Wikipedia verbinden soll.
Z. Syed et. Al. verwenden die Einträge der Wikipedia als Vokabular zur Indexierung von
Dokumenten. Die durch Querverweise zwischen Artikeln gegebene Assoziation von Themen
wird zur Bestimmung relevanter Konzepte zu einer Suchanfrage genutzt, indem das Verfahren
der Spearding Activation auf die Verknüpfungsstruktur angewendet wird [SYED U. A. (2008)]. M.
Hepp et. Al. untersuchen, inwieweit sich Wikipedia-Einträge bzw. ihre URLs als Bezeichner für
Konzepte zur Indexierung von Dokumenten eignen [HEPP U. A. (2006)]. Sie betrachten dabei unter
anderem, wie sich das Konzept, das mit einer gegebenen URL bzw. URI verbunden ist, über die
Zeit verändert.
L. Muchnik et. Al. beschreiben ein Modell für die Hierarchisierung von Netzwerken im
Allgemeinen, und validieren es unter anderem am Beispiel der Wikipedia, indem sie allein auf
Grund der Struktur der Querverweise eine Taxonomie der Artikel aufbauen und diese mit der
Kategoriestruktur vergleichen [MUCHNIK U. A. (2007)]. Eines der Maße für die lokale Bestimmung
der Zentralität von Konzepten, die dabei entwickelt wurden, nämlich der Local Hierarchy Score
(LHS), wird auch im Rahmen dieser Arbeit verwendet (.9.3).
2. Einordnung 19
E.M. van Mullige et. Al. entwickeln eine Erweiterung der MediaWiki-Software, mit deren Hilfe die
komplexen, hoch strukturierten Daten eines multilingualen Wörterbuches und Thesaurus namens
OmegaWiki (ehemals WiktionaryZ) kollaborativ in einem Wiki verwaltet und bearbeitet werden
können [VAN MULLIGEN U. A. (2006), OMEGAWIKI]. Die MediaWiki-Erweiterung, Wikidata, auf der diese
Anwendung basiert, wurde vornehmlich für den Einsatz in OmegaWiki entwickelt. Sie dient vor
allem der Verwaltung von relationalen Datensätzen in einem Wiki. Dabei liegt der Fokus, anders
als bei dem weiter unten erwähnten Semantic MediaWiki, darauf, eine komplexe aber fest
vorgegebene Datenbankstruktur mit Inhalten zu füllen. Zu diesem Zweck werden spezialisierte
Eingabehilfen bereitgestellt.
2.5. Wissensextraktion
Wikipedia kann auch als Grundlage für die Erzeugung einer Wissensbasis dienen, die über ein
bloßes Assoziationsnetzwerk und einfache Subsumtionsbeziehungen hinausgeht: durch geeignete
Verfahren lassen sich Attribut-Wert-Paare sowie semantisch bedeutsame Relationen zwischen
Entitäten bzw. Konzepten extrahieren. In den letzten Jahren wurden verschiedene Versuche unternommen,
diese Informationen zugänglich zu machen.
S. Auer, J. Lehmann et. Al. haben ein System namens DBpedia entwickelt, das Attributwerte sowie
semantische Relationen aus der Wikipedia extrahiert, vor allem durch Auswertung spezieller
Vorlagen, so genannter Infoboxen [AUER U. A. (2007), AUER UND LEHMANN (2007), DBPEDIA]. Diese bieten
strukturierte Daten in einer Form an, die bereits weitgehend dem Modell von Attribut-Wert-Paaren
entspricht [WP:IB]. DBpedia stellt die so gewonnenen Daten als eineWissensbasis im RDF-Format
[W3C:RDF (2004)] bereit und bietet eine Abfrageschnittstelle, die komplexe logikbasierte Abfragen
auf der Basis von SPARQL [W3C:SPARQL (2008)] erlaubt.
Auch D. P. T. Nguyen et. Al. verwenden Infoboxen zur Gewinnung von strukturierten Daten sowie
zur Klassifikation von Artikeln bzw. von Konzepten [NGUYEN U. A. (2007)]. F. Wu und D. S. Weld
benutzen ebenfalls die Informationen aus Infoboxen, trainieren aber ein System zur Erkennung
von Textmustern darauf, Informationen aus dem Fließtext mit denen aus Infoboxen abzugleichen
und gegebenenfalls Infoboxen zu ergänzen oder zu erzeugen [WU UND WELD (2007)].
Neben der Forschung zur Extraktion von Daten aus der Wikipedia gibt es auch Versuche, Wiki-
Systeme so zu erweitern, dass sie unmittelbar zur Erzeugung und Pflege von strukturierten, semantisch
bedeutsamen und maschinenlesbaren Daten verwendet werden können. Der wohl bekannteste
Versuch ist wohl der von M. Krötzsch et. Al., welche mit Semantic MediaWiki eine Erweiterung
von MediaWiki entwickelt haben, mit dessen Hilfe strukturierte Daten wie semantische Relationen
und Attributwerte direkt in einem Wiki-System verwaltet und bearbeitet werden können [KR¨OTZSCH
U. A. (2005), KR¨OTZSCH U. A. (2007), SMW]. Sie schlagen vor, dieses System auch für die Wikipedia selbst
zu verwenden. T. Redmann und H. Thomas untersuchen, wie sich Topic Maps [GARSHOL (2004),
ISO:13250 (2003)] mit Hilfe eines Wiki-Systems bearbeiten lassen, und wie sich umgekehrt die typischen
Strukturen einesWikis in Form einer Topic Map speichern lassen [REDMANN UND THOMAS (2007)].
R. Witte und T. Gitzinger schlagen vor, Mustererkennung und automatische Sprachverarbeitung
direkt in Wiki-Systeme zu integrieren, um so den Aufbau einer Wissensbasis aus Texten sowie
2. Einordnung 20
umgekehrt die Beschreibung von strukturierten Daten in Texten als interaktiven Prozess zu gestalten
[WITTE UND GITZINGER (2007)].
2.6. Named Entity Recognition
Eine wichtige Aufgabe im Bereich der automatischen Sprachverarbeitung sowie des Information
Retrieval ist die Erkennung und Disambiguierung von Named Entities, also vor allem von
(Eigennamen von) Personen, Orten, Organisationen und ähnlichem. Wikipedia enthält, genau wie
andere Enzyklopädien, eine große Zahl von Einträgen über eben solche Konzepte, und bietet sich
daher als Datenbasis für eine Erkennung solcher Named Entities an.
S. Cucerzan und W. Dakka untersuchten Methoden zur Disambiguierung von Namen sowie zur
Klassifikation von Dokumenten unter Verwendung von Verfahren des maschinellen Lernens, konkret
eines naiven Bayes-Klassifikators sowie Support Vector Machines (SVM). Dabei wurden unter
anderem Informationen aus den Seitentiteln,Weiterleitungen, Begriffsklärungsseiten sowie aus
dem Link-Text von Wiki-Links verwendet [DAKKA UND CUCERZAN (2008), CUCERZAN (2007)]. Einen ähnlichen
Ansatz verfolgen R. Bunescu und M. Pasca, die ebenfalls SVM auf der Basis von Wikipedia
für die Erkennung von Named Entities trainieren [BUNESCU UND PASCA (2006)].
A. Toral und R. Munoz entwarfen ein System zum automatischen Aufbau eines Gazetteers aus der
Wikipedia, indem sie ähnlich wie F. M. Suchanek Beschreibungen von Instanzen aus derWikipedia
mit Klassen aus WordNet kombinierten [TORAL UND MUNOZ (2007), TORAL UND MUNOZ (2006)]. J. Kazama
und K. Torisawa präsentieren eine Methode zur Erkennung und Klassifikation von Wikipedia-
Seiten über Named Entities, die auf der Analyse des ersten Satzes von Wikipedia-Artikeln beruht
[KAZAMA UND TORISAWA (2007)].
2.7. Eigenschaften von WikiWord
Dieser Abschnitt gibt einen kurzen Überblick über die Eigenschaften der WikiWord-Software,
die im Rahmen dieser Diplomarbeit entwickelt wurde. Dabei werden insbesondere solche
Eigenschaften betrachtet, die WikiWord zu den oben erwähnten Arbeiten in Beziehung setzen
bzw. von ihnen abgrenzen.
• WikiWord erzeugt einen konzeptorientierten Thesaurus, also ein Netzwerk von Konzepten,
die durch Relationen wie Subsumtion, Verwandtheit und Ähnlichkeit verbunden sind,
mit einer zusätzlichen Bedeutungsrelation, die Terme mit Konzepten assoziiert und als
Lexikon dient (vergleiche [GREGOROWICZ UND KRAMER (2006)]). Die meisten der oben beschriebenen
Systeme zum Aufbau eines Thesaurus aus der Wikipedia (zum Beispiel die Arbeiten
von T. Zesch und I. Gurevych) übergehen die Bedeutungsrelation weitgehend und befassen
sich kaum mit der Identifikation verschiedener Bezeichnungen für Konzepte. In der Regel
erschöpft sich die Behandlung von Synonymien in der Auflösung von Weiterleitungen, wie
sie in der Wikipedia definiert sind.
2. Einordnung 21
• WikiWord erzeugt einen multilingualen Thesaurus, indem es Language-Links verwendet,
um Artikel über dasselbe Konzept in unterschiedlichen Wikipedias zu identifizieren und zu
vereinigen. Eine solche Konsolidierung der Informationen aus unterschiedlichenWikipedias
zu einer sprachübergreifenden Wissensbasis wurde in den oben erwähnten Studien bislang
nicht untersucht. Lediglich [AUER U. A. (2007)] verwendet einige Informationen aus unterschiedlichen
Wikipedias, wobei die Grundstruktur an die englischsprachige Wikipedia
gebunden bleibt.
• WikiWord verwendet neben Seitentiteln und Weiterleitungsseiten auch
Begriffsklärungsseiten sowie insbesondere auch Link-Text, um die verschiedenen
Bezeichnungen für ein Konzept zu ermitteln und zu gewichten. Link-Text wird in den
oben erwähnten Arbeiten zur Erzeugung eines Thesaurus kaum erwähnt, lediglich die
Forschung zur Named Entity Recognition scheint sich dieser Informationsquelle bisher
bedient zu haben (z. B. S. Cucerzan und W. Dakka). Dadurch deckt WikiWord eine
Vielzahl von Bezeichnungen ab, die anderweitig schwer zu erfassen sind, darunter viele
Mehrwortphrasen, Abkürzungen, flektierte Formen sowie ungenaue oder synekdotische
Verwendungen von Termen.
• WikiWord liefert zu vielen Konzepten den ersten Satz des entsprechenden Wikipedia-
Artikels als Glosse in den gegebenen Sprachen. Die oben erwähnten Verfahren nutzen meist
den ersten Absatz als Glosse, statt nur des ersten Satzes, was zu mehr „Rauschen“ führt.
Zudem wird sie häufig lediglich zur Bestimmung der semantischen Verwandtheit oder ähnlichem
herangezogen und nicht als Eigenschaft eines Konzeptes im Resultat wiedergegeben.
• WikiWord verzichtet auf eine Analyse natürlicher Sprache, nicht einmal
Stammformreduktion (Stemming) oder Wortarterkennung (POS-Tagging) kommen
zum Einsatz. Das verwendete einfache Pattern Matching beschränkt sich auf Muster, die
bestimmte Markup-Konstrukte und Strukturmerkmale von Wikipedia-Seiten erkennen.
Das einzige verwendete Verfahren, das entfernt auf Sprachverarbeitung beruht, ist das zur
Erkennung von Satzenden: Dieses wird verwendet, um Glossen aus denWikipedia-Artikeln
zu extrahieren.
• WikiWord extrahiert keine Attribut-Wert-Paare oder andere strukturierte Daten aus Vorlagen
wie Infoboxen oder ähnlichem. Während Wikipedia eine reiche Quelle für diese Art von
Informationen ist, soll die Auswertung dieser Daten Projekten wie DBpedia überlassen bleiben
(vergleiche .2.5).
• WikiWord verwendet kein maschinelles Lernen und kaum statistische Heuristiken4.
Stattdessen werden Strukturen und Konventionen, die in den verschiedenen Wikipedia-
Projekten anzutreffen sind, explizit modelliert und ausgewertet. So kann die Investition
menschlichen Urteils, die in der Struktur der Wikipedia enthalten ist, direkt genutzt werden.
• WikiWord berücksichtigt Konzepte, die nur als Abschnitte von Artikeln repräsentiert sind,
sowie Konzepte, die zwar referenziert werden, jedoch (noch) keinen eigenen Artikel haben.
4eine erwähnenswerte Heuristik mag das Cutoff-Verfahren sein, das in .10.4 beschrieben ist.
2. Einordnung 22
Damit wird eine deutlich größere Zahl von Konzepten berücksichtigt, wobei allerdings zu
vielen davon kaum Informationen vorliegen. Solche „schwachen“ Konzepte werden von
WikiWord gekennzeichnet und können daher bei Bedarf ignoriert werden.
• WikiWord liefert zusätzlich zu der Subsumtionsrelation eine grobe Typisierung der
Konzepte, die insbesondere verschiedene Arten von Named Entities identifizieren, zum
Beispiel Personen, Orte, Zeitpunkte und Lebensformen. Diese Typen können zur Filterung
der Konzepte je nach Anwendungsgebiet verwendet werden.
• WikiWord konsolidiert Konzepte aus Artikeln mit Konzepten, die in der Wikipedia durch
Kategorien repräsentiert sind.
Insgesamt versucht WikiWord, möglichst viele lexikalisch-semantische Informationen, die in der
Wikipedia kodiert sind, zugänglich zu machen. Dabei berührt es viele Bereiche, die von den oben
beschriebenen Arbeiten über die Erzeugung von Taxonomien und Thesauri aus der Wikipedia
behandelt werden, sowie auch von Arbeiten, die sich mit Named Entity Recognition befassen.
WikiWord verzichtet auf heuristische und statistische Verfahren und beschränkt sich weitgehend
auf die bloße Extraktion und Repräsentation der Daten. Die meisten der oben erwähnten
Verfahren könnten auf die von WikiWord extrahierten Daten angewendet werden, statt die Daten
der Wikipedia direkt zu benutzen — es wäre zu untersuchen, inwiefern sie von den zusätzlichen
von WikiWord berücksichtigten Strukturen und Konventionen der Wikipedia profitieren. Die von
WikiWord erzeugte Datenbasis ist aber auch als eigenständiger, multilingualer, konzeptorientierter
Thesaurus nützlich für Aufgaben wie Indexierung, Disambiguierung und Bestimmung von semantischer
Ähnlichkeit (vergleiche .IV).
Teil II.
Entwurf
3. Idee
Das zu erstellende Softwaresystem WikiWord soll in effizienter Weise die für einen multilingualen,
konzeptorientierten Thesaurus benötigten Relationen aus demWiki-Text extrahieren (für eine
detaillierte Aufstellung von Anforderungen, siehe .5). Die Grundidee ist dabei, die Extraktion im
Wesentlichen auf die unterschiedlichen Arten von Hyperlinks, die in Wikipedia-Artikeln vorkommen,
zu beschränken (.A.3):
• Einfache Wiki-Links liefern Informationen über den semantischen Kontext von Konzepten
— sie können unter anderem verwendet werden, um semantische Verwandtheit zu bestimmen
(vergleiche .2.3, .2.4 und insbesondere [GREGOROWICZ UND KRAMER (2006)]).
• Der Link-Text liefert zudem Informationen über Bezeichnungen, die für das Konzept (das
Link-Ziel) verwendet werden (vergleiche .2.3 und besonders [MIHALCEA (2007), EIRON UND
MCCURLEY (2003), KRAFT UND ZIEN (2004)]).
• Kategorisierungs-Links liefern die Subsumtionsrelation (vergleiche .2.3 und .2.4, insbesondere
[PONZETTO UND STRUBE (2007B)])
• Language-Links verbinden Beschreibungen des gleichen Konzeptes in unterschiedlichen
Sprachen — aus ihnen kann auf die semantische Ähnlichkeit von Konzepten geschlossen
werden, sowohl innerhalb einer Sprache als auch zwischen verschiedenen Sprachen.
Sie können daher verwendet werden, um einen multilingualen Thesaurus aufzubauen, indem
ähnliche Konzepte aus unterschiedlichen Sprachen zu sprachübergreifenden Konzepten
zusammengefasst werden (siehe .4.3). Dieser Ansatz wurde in den eingangs erwähnten
Arbeiten noch nicht untersucht.
Neben den Links können noch weitere Eigenschaften betrachtet werden, zum Beispiel die auf
einer Seite verwendeten Vorlagen. Sie können zur Klassifikation von Seiten und Konzepten
(.8.5 bzw. .8.6) verwendet werden, vergleiche .2.6. Weiterleitungen und Begriffsklärungsseiten
sowie bestimmte Magic Words können verwendet werden, um Konzepten zusätzliche Terme
(Bezeichnungen) zuzuweisen (siehe .8.9 und .8.10 sowie .9.1).
Dieser Ansatz, der sich auf Wiki-Links und andere Markup-Elemente konzentriert, umgeht
eine Anzahl von Schwierigkeiten, die bei den klassischen Methoden der automatischen
Thesaurusgenerierung auftreten (vergleiche [NAKAYAMA U. A. (2007A)]): insbesondere findet keine
Analyse natürlicher Sprache statt und selbst auf der lexikalischen Ebene werden problematische
Aufgaben wie Stammformreduktion (Stemming) vermieden. Zudem wird anstelle von statistischen
Verfahren und Heuristiken vor allem direkt menschliches Wissen genutzt, das über Regeln und
Konventionen in den Wikipedia-Seiten kodiert ist (vergleiche .1.2, .8, .9.1).
4. Ablauf
Wiki-Text
Analyse
Ressourcen
Verarbeitung
Lok. Konzepte
Zusammenf.
Glob. Konzepte
Export
Thesaurus
Abb. 4.1: Transformationen
Das Vorgehen von WikiWord lässt sich als eine Folge von Datentransformationen betrachten: In
Abb. 4.1 ist eine Aneinanderreihung von Datenmodellen und Verarbeitungsschritten dargestellt,
in der jeweils ein Transformationsschritt die Daten von einem Modell in ein anderes überführt1.
Die Implementation von WikiWord folgt grob dieser Struktur (.7.1), in der konkreten Umsetzung
wurden allerdings einige der Schritte verschachtelt und parallelisiert (.7.2).
Die einzelnen Transformationen sowie die resultierenden Datenmodelle sind im Folgenden beschrieben.
4.1. Analyse von Wiki-Text
Die erste Transformation ist die Analyse des Wiki-Textes (.1.2) aus dem XML-Dump (vergleiche
[WM:DOWNLOAD, MW:XML]). Hierbei werden die relevanten Informationen aus dem Wiki-Text
extrahiert und in das Ressourcenmodell überführt, das die Wiki-Seite repräsentiert und direkten
Zugriff auf Eigenschaften dieser Seite bietet. Dabei entfällt ein Großteil des textlichen Inhalts, die
Seite wird als eine ungeordnete Sammlung von Features wie Wiki-Links, Kategorien, Vorlagen
und so weiter betrachtet.
Das Ressourcenmodell bietet insbesondere Zugang zu folgenden Eigenschaften der Wiki-Seite:
• der Titel der Seite, sowie der Namensraum, zu dem die Seite gehört.
1die grafische Aufteilung in mehrere Spalten erfolgt lediglich aus Platzgründen.
4. Ablauf 26
• der Text der Seite, in verschiedenen Verarbeitungsstufen, vom unveränderten Wiki-Text bis
zu reinem Fließtext ohne Markup, siehe .8.3.
• alleWiki-Links, also alleWiki-Seiten, auf die diese Seite verweist, mitsamt dem Link-Text
jedes Verweises. Der Mechanismus zur Extraktion der Wiki-Links ist in .8.7 beschrieben.
MancheWiki-Links haben eine spezielle Semantik (siehe .A.3) und werden daher auch von
WikiWord gesondert interpretiert. Solche besonderen Wiki-Links definieren:
– die Kategorien, denen die Seite zugeordnet ist.
– die Language-Links, die auf der Seite definiert sind.
• alle Abschnitte (Überschriften) der Seite.
• die Vorlagen, die auf der Seite verwendet werden, samt den Parametern ihrer Verwendung
(.A.5). Das Verfahren, mit dem die Vorlagen extrahiert werden, ist in .8.4 beschrieben.
Diese Informationen werden größtenteils durch einfaches Pattern-Matching auf Basis des Wiki-
Textes gewonnen. Auf Grund dieser Basisinformationen werden (ebenfalls imWesentlichen durch
Pattern-Matching) weitere, speziellere Eigenschaften bestimmt:
• der Typ der Seite. Diese Eigenschaft bestimmt, wie die Seite weiter verarbeitet wird.
Mögliche Typen von Seiten sind: Artikel, Weiterleitung, Begriffsklärung, Liste sowie
Kategorie. Details dieser Klassifikation sind in .8.5 beschrieben.
• der Typ des Konzeptes, das die Seite beschreibt, falls sie ein Artikel ist. Diese Klassifikation
hat keinen Einfluss auf die weitere Verarbeitung der Daten, kann aber bei der Verwendung
des Thesaurus nützlich sein, insbesondere für die Aufgabe der Named Entity Recognition.
Mögliche Typen von Konzepten sind: Ort, Person, Organisation, Name, Zeitpunkt, Zahl,
Lebensform und sonstige. Details der Konzeptklassifikation sind in .8.6 beschrieben.
• eine Menge von Termen, die als Bezeichnung für das Konzept direkt aus der Seite selbst,
insbesondere aus ihrem Titel, abgeleitet werden können (für Details, siehe .8.9).
• der erste Satz des Textes der Seite, zur Verwendung als Definition (Glosse) für das Konzept,
das der Artikel beschreibt. Für das Verfahren zur Extraktion des ersten Satzes, siehe .8.8.
• Bedeutungslinks, also Wiki-Links auf einer Begriffsklärungsseite, die auf eine der möglichen
Bedeutungen des zu klärenden Begriffs zeigen. Der Algorithmus zur Extraktion von
Bedeutungslinks ist in .8.10 beschrieben.
• das Ziel der Weiterleitung, falls die Seite eine Weiterleitung ist.
Die verwendeten Muster zur Erkennung bestimmter Informationen im Wiki-Text sind zum Teil
Wiki-spezifisch. Zu beachten ist, dass sie zum größten Teil nicht ad hoc bestimmt wurden, sondern
die vorgegebene Syntax des Wiki-Markups (.A) oder explizite Konventionen und Richtlinien der
einzelnen Wiki-Projekte nachbilden (vergleiche [WP:ARTIKEL, WP:KAT, WP:BKL]).
Die Verfahren, die verwendet werden werden, um die einzelnen Eigenschaften der Wiki-Seite zu
bestimmten, wird in .8 beschrieben. Das Ressourcenmodell selbst ist in .D.1 definiert.
4. Ablauf 27
4.2. Aufbau des lokalen Datenmodells
Concept
Term
meaning
broader
(a) Relationen
A B
C D
a
b c d e
f g h
(b) Struktur
Abb. 4.2: Datenmodell
Die zweite Transformation ist die Verarbeitung der Informationen aus dem Ressourcenmodell,
also der Import in das lokale Datenmodell (das Konzeptmodell). In diesem Schritt werden die
Informationen aus der Wikipedia als Elemente eines Thesaurus interpretiert (.9.1).
Das lokale Datenmodell definiert die Struktur eines monolingualen, konzeptorientierten
Thesaurus. Konkrete lokale Datensätze, also konkrete monolinguale Thesauri, werden in dieser
Struktur gespeichert. Das Datenmodell ist ein Term-Konzept-Netzwerk (Abb. 4.2), es enthält
Beziehungen zwischen Termen und Konzepten (die Bedeutungsrelation) und zwischen verschiedenen
Konzepten (zum Beispiel Subsumtion oder Verwandtheit), wie in Abb. 4.2(a) dargestellt.
Beziehungen zwischen Termen ergeben sich implizit. Dieses Modell ähnelt den Strukturen, die
in der Literatur für ähnliche Zwecke vorgeschlagen wurden, insbesondere z. B. in [GREGOROWICZ UND
KRAMER (2006)] und anderen Arbeiten, die in .2.4 vorgestellt wurden. Die Umsetzung dieses Modells
als Schema für ein relationales Datenbanksystem ist in .C.1 beschrieben.
Im Einzelnen besteht das Modell aus den folgenden Elementen:
Terme: Terme (in Abb. 4.2(b) als Kreise dargestellt) sind lexikalische Einheiten: Wörter,
Wortformen, Wortgruppen, Phrasen, Namen und so weiter. Jeder Term existiert nur einmal
in einem Datensatz (also höchstens einmal pro Sprache). Terme sind Bezeichnungen für
Konzepte.
Konzepte: Konzepte (in Abb. 4.2(b) eckige Kästchen) sind logische Einheiten: sie repräsentieren
(abstrakte oder konkrete) Dinge. Konzepte sind Bedeutungen von Termen.
Zu jedem Konzept werden neben seiner Identität weitere Eigenschaften gespeichert, unter
anderem ein Name zur Anzeige in einer Benutzerschnittstelle und der Typ des Konzeptes
(wie oben im Abschnitt über das Ressourcenmodell beschrieben), sowie weitere sekundäre
Eigenschaften wie ein IDF-Wert (.9.3).
Bedeutungsrelation: Die Bedeutungsrelation (in Abb. 4.2(b) als durchgezogene Linien dargestellt)
verbindet Terme und Konzepte, zum Beispiel die Terme a, b und c mit Konzept
A. Dabei können beliebig viele Terme einem Konzept und beliebig viele Konzepte einem
4. Ablauf 28
Term zugeordnet sein. Die Bedeutungsrelation dient der Überbrückung der Semantic Gap
zwischen dem Text als Folge von Wörtern und demWissen über Konzepte (siehe dazu auch
[SUCHANEK U. A. (2007)] und wieder [GREGOROWICZ UND KRAMER (2006)]). Die Bedeutungsrelation ist
gewichtet, konkret wird angegeben, wie oft welche Bezeichnung für welches Konzept verwendet
wurde.
Die gepunkteten Verbindungen in der Abbildung ergeben sich implizit aus der
Bedeutungsrelation: Sie zeigt Synonymie zwischen zwei Termen, die beide über die
Bedeutungsrelation mit demselben Konzept verbunden sind (zum Beispiel a und b
wegen ihrer Verbindung zu A) und Homonymie zwischen Konzepten, die über die
Bedeutungsrelation mit demselben Term verbunden sind (zum Beispiel zwischen A und C
wegen ihrer Verbindung zu b und c)2.
Subsumtionsrelation: Die Subsumtionsrelation (in Abb. 4.2(b) als Pfeil dargestellt) verbindet
allgemeinere mit spezielleren Konzepten. Sie ist irreflexiv und antisymmetrisch, sowie
konzeptionell transitiv, und bildet auf der Menge der Konzepte einen gerichteten azyklischen
Graphen. Idealerweise (aber nicht notwendigerweise) sind alle Konzepte von einer
einzigen „Wurzel“ aus erreichbar. Die konkrete Semantik der Subsumtion bleibt unbestimmt,
die Relation beinhaltet so unterschiedliche Beziehungen wie Abstraktion (subtype),
Instanziierung (is-a), Aggregation (part-of ) und gelegentlich auch Attribution (property-of );
siehe dazu [VOSS (2006), PONZETTO UND STRUBE (2007B), HAMMW¨OHNER (2007)] sowie weitere Arbeiten,
die in .2.4 erwähnt wurden. Diese Relation entspricht der Hyponymiebeziehung zwischen
Termen, also der BT/NT-Beziehung nach ISO [ISO:2788 (1986)].
Verwandtheit und Ähnlichkeit: Die semantische Verwandtheit und Ähnlichkeit von Konzepten
(in Abb. 4.2(b) eine gestrichelte Linie) ist eine symmetrische Beziehung. Sie ist unter anderem
für die automatische Disambiguierung von Termen sowie für die Aufgabe der Query
Expansion nützlich (vergleiche dazu die Arbeiten, die in .2.3 vorgestellt wurden, insbesondere
[ZESCH U. A. (2007B)] und [STRUBE UND PONZETTO (2006)]).
Lokale Datensätze werden in einer relationalen Datenbank abgelegt (siehe .C.1), für die programmatische
Verwendung einzelner Konzepte gibt es aber auch eine objektorientierte Repräsentation
als Transferobjekte der Datenzugriffsschicht (siehe .C.3). Jedes Konzept wird als Objekt dargestellt,
das Zugriff auf die Eigenschaften des Konzeptes bietet, unter anderem auf alle
Bezeichnungen für das Konzept sowie auf verwandte und untergeordnete Konzepte (.D.2).
Die Beziehungen des lokalen Datenmodells werden aus dem Ressourcenmodell aufgebaut, das
heißt, die in den einzelnen Ressourcen (Wiki-Seiten) enthaltenen Informationen werden als
Beziehungen im lokalen Datenmodell (also im Thesaurus) interpretiert und dann als solche gespeichert.
Insbesondere werden folgende Interpretationen vorgenommen:
• Seiten, die keineWeiterleitungen, Begriffsklärungen, Listen, Kategorien oder andere besondere
Seiten sind, werden als Artikel betrachtet, das heißt, es wird angenommen, dass sie
genau ein Konzept beschreiben. Entsprechend wird für jeden Artikel ein Konzept im lokalen
Datensatz angelegt, mit dem Konzepttyp, den das Ressourcenmodell für diese Seite
2Der Übersichtlichkeit halber wurden nicht alle Beziehungen, die sich so ergeben, in der Abbildung dargestellt.
4. Ablauf 29
bestimmt hat; das entspricht dem Vorgehen in der Literatur, wie in den Arbeiten in .2.3 und
.2.4 beschrieben.
• die Subsumtionsrelation wird direkt aus den Kategorien abgeleitet, denen eine Seite zugeordnet
ist. Dabei wird nicht zwischen Kategorieseiten und Artikeln unterschieden, das heißt,
Kategorien sind ebenfalls einfach Konzepte (.9.1). Auch das entspricht im Wesentlichen
dem, was laut .2.4 das übliche Vorgehen ist.
• die Verwandtheit von Konzepten wird aufgrund von Querverweisen (Wiki-Links) zwischen
Artikeln bestimmt: wenn zwei Artikel sich gegenseitig über Wiki-Links referenzieren, wird
davon ausgegangen, dass die Konzepte, die diese Artikel beschreiben, miteinander verwandt
sind [GREGOROWICZ UND KRAMER (2006)], siehe .9.1.3.
• die Ähnlichkeit von Konzepten wird über die Language-Links bestimmt: wenn zwei Artikel
über Language-Links denselben Artikel in einer anderen Sprache referenzieren, so werden
die Konzepte, die diese beiden Artikel beschreiben, als ähnlich angesehen. Der Grund
ist, dass Language-Links immer auf ähnliche (oder, idealerweise, äquivalente) Artikel verweisen
[WP:INTERLANG], und die Ähnlichkeitsbeziehung als transitiv und symmetrisch betrachtet
wird. Language-Links wurden in [HAMMW¨OHNER (2007B)] untersucht, der Ansatz, sie
zur Bestimmung von semantischer Ähnlichkeit zu verwenden, scheint jedoch noch nicht
verfolgt worden zu sein.
• die Bezeichnungen (Terme) für ein Konzept werden aus einer Vielzahl von Quellen bestimmt,
unter anderem:
– aus dem Titel des Artikels, sowie der Verwendung des Magic Words DISPLAYTITLE.
Letzteres wurde in der Literatur bislang nicht betrachtet.
– aus den Titeln von Weiterleitungen, die auf den Artikel verweisen.
Weiterleitungsseiten werden von so gut wie allen Arbeiten zur Struktur von
Wikipedia betrachtet, vergleiche .2.3 und .2.4.
– aus den Titeln von Begriffsklärungsseiten, die auf den Artikel verweisen.
Begriffsklärungsseiten werden in der Literatur ebenfalls häufig berücksichtigt,
vergleiche z. B. [PONZETTO UND STRUBE (2007C)].
– aus dem Link-Text von Wiki-Links, die auf den Artikel verweisen. Diese Information
wurde bei der Analyse der Wikipedia bislang kaum genutzt (mit der Ausnahme von
[MIHALCEA (2007)] sowie einigen Arbeiten zur Named Entity Recognition, siehe .2.6),
obwohl sie für das Information Retrieval sehr wertvoll sein kann (vergleiche [EIRON UND
MCCURLEY (2003), KRAFT UND ZIEN (2004)]).
– aus Sort-Keys, die bei der Kategorisierung des Artikels angegeben wurden, sowie
der Verwendung des Magic Words DEFAULTSORT. Diese Quellen für alternative
Bezeichnungen wurden in der Literatur bisher nicht untersucht.
Die Interpretation von Informationen aus dem Wiki-Text ist in .9.1 näher beschrieben. Nach
dem Import der Daten aus den einzelnen Seiten der Wikipedia findet eine Nachbereitung statt
(.9.1.3). Dabei werden insbesondere Weiterleitungen und Kategorisierungs-Aliase aufgelöst (siehe
.9.1.3 und .9.1.2) sowie die Verwandtheit und Ähnlichkeit von Konzepten berechnet (.9.1.3).
Das Ergebnis ist ein lokaler Datensatz, der einen monolingualen Thesaurus repräsentiert.
4. Ablauf 30
4.3. Zusammenführen
Die dritte Transformation ist das Zusammenführen der einzelnen lokalen Datensätze zu einem globalen
Datensatz: Gruppen von untereinander ähnlichen Konzepten aus unterschiedlichen Sprachen
werden zu jeweils einem sprachunabhängigen Konzept vereinigt. Eine solche Methode zum
Aufbau eines multilingualen Thesaurus wurde in den eingangs erwähnten Arbeiten nicht beschrieben.
Das globale Datenmodell enthält vor allem Informationen darüber, welche Konzepte aus den einzelnen
sprachspezifischen Datensätzen zu einem sprachunabhängigen Konzept zusammengefasst
wurden und wie die Beziehungen zwischen den lokalen Konzepten auf die globalen Konzepte
abgebildet wurden (siehe .C.1). Zusammen mit den lokalen Datensätzen, auf die er sich bezieht,
bildet der globale Datensatz eine Kollektion, die einen multilingualen Thesaurus repräsentiert.
Jedes Konzept im globalen Datensatz ist eine Menge von lokalen Konzepten, die aus jeder
Sprache (höchstens) ein Konzept enthält. Sprachspezifische Eigenschaften (insbesondere Terme
und Glossen) werden in dem globalen Datensatz nicht noch einmal abgelegt — statt dessen werden
sie bei Bedarf dem betreffenden lokalen Datensatz entnommen.
Die Hauptaufgabe beim Aufbau des globalen Datensatzes ist es also, Gruppen von Konzepten aus
unterschiedlichen Sprachen (also lokalen Datensätzen) zu finden, die sich möglichst ähnlich sind,
bzw. idealerweise zueinander äquivalent. Dabei ist die unter Umständen sehr unterschiedliche
Granularität und Abdeckung der Wikipedias in den einzelnen Sprachen zu berücksichtigen. Der
hierfür verwendete Algorithmus lässt sich wie folgt zusammenfassen:
1. Nimm alle Konzepte aus allen Sprachen der Kollektion vorläufig in den multilingualen
Thesaurus auf.
2. Bestimme, welche Konzepte über einen Language-Link direkt auf ein anderes Konzept
in dem multilingualen Thesaurus, der ja Konzepte aus unterschiedlichen Sprachen enthält,
verweisen. Auf diese Weise werden Paare von ähnlichen Konzepten im multilingualen
Thesaurus markiert.
3. Bestimme, welche Paare von Konzepten sich auf diese Weise gegenseitig referenzieren. Da
die über einen Language-Link referenzierten Konzepte im Allgemeinen entweder äquivalent
oder allgemeiner sind als das betreffende Konzept selbst, ist davon auszugehen, dass
zwei Konzepte, die sich gegenseitig auf dieseWeise referenzieren, äquivalent sind oder sich
zumindest stark ähneln. Dieses Vorgehen ist analog zu der Methode, die [GREGOROWICZ UND
KRAMER (2006)] folgend zur Bestimmung verwandter Konzepte innerhalb einer Sprache verwendet
wurde.
4. Vereinige Paare solcher Konzepte, wobei alle Eigenschaften und Relationen der beiden
Konzepte zusammengefasst werden. Dabei wird mitgeführt, welche Sprachen das vereinigte
Konzept abdeckt. Jede Sprache darf in dem resultierenden sprachübergreifenden Konzept
höchstens einmal vorkommen.
4. Ablauf 31
5. Vereinige so lange, bis kein solches Paare von Konzepten mehr vorhanden ist, das vereinigt
werden kann. Sind zwei Konzepte zwar durch gegenseitige Language-Links verbunden,
aber die Mengen der von ihnen bereits abgedeckten Sprachen überlappen sich, so stehen
diese beiden Konzepte in Konflikt zueinander und können nicht vereinigt werden. Solche
Konzepte sind sich in der Regel sehr ähnlich (siehe auch .11.3).
Dieses Verfahren ist in .9.2 genauer beschrieben. Auf das eigentliche Zusammenführen folgt auch
hier eine Nachbereitungsphase zur Konsolidierung der Daten (.9.2.3). Dabei werden aufgrund der
neu bestimmten Beziehungen zwischen den sprachübergreifenden Konzepten die Verwandtheit
und Ähnlichkeit der Konzepte neu berechnet.
4.4. Export
Die vierte und letzte Transformation ist der Export der lokalen und globalen Datensätze in
eine extern weiterverwendbare Form, nämlich das Thesaurus-Modell (siehe .10). Es repräsentiert
die aus der Wikipedia extrahierten Beziehungen in einer standardisierten, für andere
Softwaresysteme nützlichen Form, nämlich RDF/SKOS (.10.3). Die Modellierung der
Thesaurusdaten in RDF/SKOS folgt insbesondere [GREGOROWICZ UND KRAMER (2006), VAN ASSEM U. A. (2006),
W3C (2005)].
Teil III.
Implementation
5. Anforderungen
Im Folgenden werden die Anforderungen aufgeführt, die an WikiWord, das System zur automatischen
Extraktion eines multilingualen Thesaurus aus der Wikipedia, gestellt werden.
5.1. Aufgaben
WikiWord soll in der Lage sein, auf Basis des Wikipedia-Korpus die folgenden Informationen
effizient zu liefern:
1. Eine Liste der Konzepte (Bedeutungen) die zu einem Term (Bezeichnung, Wort, Phrase)
einer bestimmten Sprache gehören, mit Ranking nach Häufigkeit/Wahrscheinlichkeit.
2. Eine Liste aller Terme (Bezeichnungen, Wörter, Phrasen) für ein Konzept in einer gegebenen
Sprache, mit Ranking nach Häufigkeit/Wahrscheinlichkeit.
3. Übersetzungen eines Terms aus einer Sprache in eine andere, gegebenenfalls getrennt für
unterschiedliche Bedeutungen. Das ergibt sich aus einer Kombination der beiden vorausgegangenen
Punkte: a) Finden aller möglichen Bedeutungen eines Terms in einer Sprache,
b) Anzeige aller Bedeutungen mit jeweils allen möglichen Bezeichnungen in einer anderen
Sprache.
4. Über- bzw. untergeordnete Konzepte zu einem gegebenen Konzept, wobei diese
Subsumtionsrelation azyklisch sein soll.
5. Eine grobe, sprachunabhängige Klassifikation von Konzepten, also Zuordnung eines von
einigen wenigen fest vorgegebenen Typen (z. B. Person, Ort, Zeit, etc).
6. Die semantische Verwandtheit (Semantic Relatedness, SR) zwischen zwei gegebenen
Konzepten.
7. Eine Zuweisung einer Bedeutung (Konzept) zu jeweils einem Term in einer Menge von
Termen (Disambiguierung im Kontext).
8. Eine Glosse (Definitionssatz) zu (möglichst) jedem Konzept.
5.2. Rahmenbedingungen
1. Als Eingabe soll ausschließlich der Wiki-Text (.A) von den Seiten der Wikipedia dienen,
wie er in den Wikipedia XML-Dumps enthalten ist [MW:XML, WM:DOWNLOAD]. Zur
Verarbeitung soll nur ein Minimum von sprach- und Wikipedia-spezifischem Wissen benötigt
werden.
5. Anforderungen 34
2. Die Extraktion der gewünschten Daten sowie ihre Verarbeitung und Überführung in die
für die Nutzung gewünschte Form soll hinreichend effizient sein: das Verfahren muss auf
eine Datenbasis von mehreren Millionen Dateien anwendbar sein und in annehmbarer Zeit
terminieren. Anzustreben ist dabei ein in Bezug auf die Anzahl der im Korpus enthaltenen
Links subquadratischer Zeit- und Platzaufwand.
3. Die Daten sollen zur weiteren Nutzung in einem relationalen Datenbanksystem abgelegt
werden, in einer Form, die eine effiziente Abfrage bezüglich der intendierten Datennutzung
erlaubt.
4. Die erzeugten Daten sollen in bestehende Thesaurus- oder Wörterbuchsysteme integrierbar
sein.
5. Das Softwaresystem soll leicht anzupassen und zu erweitern sein. Insbesondere soll die
Software ohne Schwierigkeiten an Änderungen der Konventionen einzelner Wikipedias, an
der Wiki-Text-Syntax oder an dem für die Dumps verwendeten XML Format angepasst
werden können.
6. Das Softwaresystem soll auf verschiedenen Betriebssystemen lauffähig bzw. leicht portierbar
sein.
6. Plattform
WikiWord, das System zur Extraktion eines multilingualen Thesaurus, soll leistungsfähig, flexibel
und portierbar sein. In Hinblick darauf sind vor allem zwei Dinge als Basis für die Implementation
auszuwählen: Die Programmiersprache (und Laufzeitumgebung) sowie die Persistenzplattform
zur Datenspeicherung. In Hinblick auf die Weiterverwendbarkeit der Daten muss eine für die
Weiternutzung durch Dritte geeignete externe Darstellung gefunden werden.
6.1. Laufzeitumgebung: Java
Als Programmiersprache und Laufzeitumgebung wurde Java gewählt, unter anderem aus folgenden
Gründen:
• Java verbindet gute Performanz mit einem hohen Grad an Abstraktion und Modularität.
• Java bietet eine große Auswahl frei verfügbarer Bibliotheken.
• Java ist im akademischen Umfeld weit verbreitet wegen seiner guten Lesbarkeit und wohldefinierten
Semantik.
6.2. Datenbank: MySQL
Als internes Speichersystem wurde ein relationales Datenbanksystem gewählt, nämlich MySQL
[MYSQL]:
• Die zu speichernden Daten sind relationaler Natur.
• Ein relationales Datenbanksystem bietet effizienten Zugriff auch bei sehr großen
Datenmengen.
• Die Nutzung eines Datenbanksystems vermeidet zusätzlichen Programmieraufwand für die
Persistenzlogik.
• MySQL ist freie Software und läuft auf allen verbreiteten Betriebssystemen.
• MySQL ist für den Umgang mit sehr großen Datenmengen wohl erprobt und gilt als verhältnismäßig
performant.
Die Anbindung von MySQL an die Java-Anwendung erfolgt über Javas Standard
Datenbankschnittstelle, JDBC [JDBC], und wird durch eine Datenzugriffsschicht (DAO) gekapselt
(siehe .C.3).
6. Plattform 36
6.3. Austauschformat: SKOS
Als Datenformat für den Austausch und die Weiterverwendung des erstellten Thesaurus wurde
SKOS [W3C:SKOS (2004), MILES (2005B)] gewählt, insbesondere aus den folgenden Gründen
[GREGOROWICZ UND KRAMER (2006), VAN ASSEM U. A. (2006), W3C (2005)]:
• SKOS ist ein vorgeschlagener W3C-Standard und baut auf den wohlbekannten Standards
XML, RDF und OWL auf.
• SKOS wurde für die Repräsentation von Thesauri und Wissensnetzen entworfen und eignet
sich daher sehr gut für die vorliegenden Daten.
• SKOS ist (im Gegensatz zu dem ISO-Modellen [ISO:2788 (1986)]) konzeptorientiert und passt
daher gut zu dem verwendeten Datenmodell.
• SKOS wird von einer Vielzahl von Systemen zur Sprach- und Wissensverarbeitung unterstützt.
7. Framework
In den vorangegangenen Kapiteln wurde ein grober Entwurf für die Funktionalität von
WikiWord entwickelt (.3) und die zu bewältigenden Aufgaben sowie die zu berücksichtigenden
Rahmenbedingungen spezifiziert (.5). Dieses Kapitel gibt nun einen Überblick über die zu diesem
Zweck entwickelten Softwarekomponenten (siehe Anhang G für Zugang zum Quellcode). Eine
Beschreibung der Kommandozeilenschnittstelle für WikiWord findet sich in Anhang B.
7.1. Import-Architektur
Dieser Abschnitt gibt eine Übersicht über die wichtigsten Klassen und Komponenten von
WikiWord. Im Zentrum der Betrachtung steht dabei ImportConcepts, das Programm zur
Extraktion der Thesaurusdaten aus dem Wiki-Text.
Die Programme, die die Kommandozeilenschnittstelle vonWikiWord bilden, sowie die Parameter
und Optionen für ihren Aufruf sind in Anhang B beschrieben. Weitere Möglichkeiten zur
Konfiguration bieten die sogenannten Tweak-Werte, siehe .B.5. Eine Auflistung der relevanten
Klassen und Packages ist in .G gegeben.
Die Basis für alle Programme der Kommandozeilenschnittstelle von WikiWord ist
die Klasse CliApp: Sie stellt Basisfunktionalität unter anderem zur Verarbeitung von
Kommandozeilenparametern und zur Ausgabe von Log-Nachrichten bereit. Alle in .B.1 erwähnten
Import-Programme mit Ausnahme von ExportSkos, bauen auf der von CliApp
abgeleiteten Klasse ImportApp auf: dieses bietet Unterstützung für die Verwendung des Agenda-
Systems zur Ablaufkontrolle (siehe Anhang B.6) sowie für die Erzeugung eines geeigneten
Datenzugriffsobjektes für die Interaktion mit der Datenbank (siehe .C.3).
Eine genauere Betrachtung verdient die Klasse ImportDump, auf der auch ImportConcepts basiert,
welches der Einstiegspunkt für einen Großteil der Extraktionslogik ist. ImportDump ist von
ImportApp abgeleitet und bildet das Framework für eine Consumer-Producer-Architektur für
den Import von Daten: Eine Implementation des Interfaces ImportDriver liest „Seiten“ aus einer
Datenquelle und übergibt sie, eine nach der anderen, an eine Implementation des Interfaces
WikiWordImporter, die die Daten dann weiter verarbeitet. Die Klasse AbstractImporter
bildet die Basis für Implementationen dieses Interfaces und bietet Funktionen insbesondere
für die Ablaufsteuerung über das Agenda-Objekt sowie für die Umsetzung allgemeiner
Kommandozeilenparameter.
Im Normalfall sollen die Wiki-Seiten aus einem Wikipedia-Dump gelesen werden [MW:XML].
Dies wird von der Klasse DumpImportDriver umgesetzt (einer Implementation des Interfaces
ImportDriver), die ihrerseits auf die MWDumper-Bibliothek von Wikimedia zurückgreift
[MW:DUMPER]: Sie verarbeitet die XML-Struktur und ruft für jede enthaltene Wiki-Seite die
Methode handlePage auf dem WikiWordImporter auf. Dabei wird die XML-Datei automatisch
dekomprimiert, sollte dies erforderlich ein1.
1Unterstützt werden die weit verbreiteten Formate GZip und BZip2.
7. Framework 38
Für die Analyse des Wiki-Textes und den Import der so gewonnenen Ressourcen in das lokale
Datenmodell verwendet das Programm ImportConcepts die Klasse ConceptImporter als
Implementation von WikiWordImporter. Diese überführt den rohen Wiki-Text zunächst unter
Verwendung von WikiTextAnalyzer in das Ressourcenmodell (siehe .4.1, .8, .D.1), interpretiert
die Eigenschaften der Ressource (.4.2, .9.1) und schreibt das Ergebnis dann in das lokale
Datenmodell, ein Datenzugriffsobjekt des Typs LocalConceptStoreBuilder (siehe und .C.4).
Die Interaktion von DumpImportDriver, ConceptImporter, WikiTextAnalyzer und
LocalConceptStoreBuilder wird im nächsten Abschnitt genauer erläutert.
7.2. Ablauf und Parallelisierung (Pipeline)
main:DumpImportDriver read read read
imperter:ConceptImporter handlePage
handle
(queue)
handlePage
handle
(queue)
handlePage
handle
(queue)
flusher:DatabaseLocalStoreBuilder
store
(buffer)
flush
store store
(buffer)
Abb. 7.1: Parallelisierung: die Import-Pipeline
Die Aufgabe von ImportConcepts lässt sich in zwei Abschnitte gliedern: den eigentlichen
Datenimport, also das Lesen, Interpretieren und Speichern der Daten, und die Nachbereitung, also
die Konsolidierung der Daten. Der Datenimport ist selbst in mehrere Schritte gegliedert, von denen
einige parallel ausgeführt werden können—diese Parallelisierung soll hier näher beschrieben
werden.
Die am Datenimport beteiligten Komponenten sind DumpImportDriver,
ConceptImporterWikiTextAnalyzer und LocalConceptStoreBuilder bzw.
DatabaseLocalConceptStoreBuilder. Diese Komponenten arbeiten zum Teil parallel
(siehe Abb. 7.1) und sind wie folgt gekoppelt:
Im Haupt-Thread des ImportConcepts-Programms wird die runImport-Methode von
DumpImportDriver aufgerufen — sie ist der Einstiegspunkt für den gesamten Datenimport.
DumpImportDriver extrahiert mit Hilfe der MWDumper-Bibliothek den Wiki-Text der einzelnen
Seiten aus der XML-Struktur der Dump-Datei. Der Wiki-Text jeder Seite wird dann,
zusammen mit der zugehörigen Metainformation wie dem Seitentitel, in eine Warteschlange
eingefügt, aus der er, gemäß dem Consumer-Producer-Muster, von einem anderen Thread
herausgenommen wird, der ihn dann an die Methode handlePage von ConceptImporter
übergibt. Die Warteschlange ist auf n Einträge beschränkt: wenn sich schon n unbearbeitete
Einträge in der Warteschlange befinden, wenn der Producer (DumpImportDriver) einen Eintrag
7. Framework 39
hinzufügen will, so wird dieser blockiert, bis der Consumer (ConceptImporter) einen Eintrag
aus der Warteschlange entnommen hat. Die Länge der Warteschlange ist per Default 8 und
kann über den Tweak-Wert dumpdriver.pageImportQueue konfiguriert werden — die Länge
ist aber relativ unerheblich, da die Warteschlange in der Regel voll und der Producer-Thread
blockiert ist. Die Warteschlange dient also nicht als Puffer, sondern lediglich der Entkopplung
der beiden Aktivitäten, die eine parallele Ausführung erlaubt; eine Entkopplung nach dem
Rendezvous-Muster wäre hier ebenfalls ausreichend. Wird dumpdriver.pageImportQueue auf
0 gesetzt, so wird der Import „durchgekoppelt“ und keine Warteschlange verwendet — in diesem
Fall ruft der DumpImportDriver direkt die Methode handlePage von ConceptImporter auf.
Wie oben beschrieben, wird der ConceptImporter in einem eigenen Thread betrieben und
aus einer Warteschlange bedient. Für jeden Eintrag aus der Warteschlange wird die Methode
handlePage mit dem Wiki-Text und den zugehörigen Metadaten wie dem Seitentitel aufgerufen.
Diese Methode verwendet nun zunächst den WikiTextAnalyzer, um den Wiki-Text in das
Ressourcenmodell, implementiert durch WikiTextAnalyzer.WikiPage (siehe .D.1), zu überführen,
das heißt, den Text zu parsen und die relevanten Features (.4.1) wie Wiki-Links, verwendete
Vorlagen etc. zu extrahieren. Die so bestimmten Eigenschaften werden dann interpretiert
und entsprechende Informationen werden zur Speicherung an die Datenzugriffsschicht übergeben
(siehe .9.1 und .C.4).
Die datenbankbasierte Implementation der Datenzugriffsschicht (DAO),
DatabaseLocalConceptStoreBuilder, verwendet intern für jede Datenbanktabelle einen
Puffer, in dem neue Einträge zwischengespeichert werden. Ist ein Puffer voll, so wird er in eine
Warteschlange gelegt und ein neuer Puffer für die betreffende Tabelle verwendet. Ein separater
Thread arbeitet im Hintergrund die Puffer aus der Warteschlange ab, indem er einen nach
dem anderen entnimmt und an die Datenbank weiterleitet. Das entspricht einer asynchronen
Flush-Funktion für die Puffer. Bei einem expliziten Aufruf der Methode flush werden die Puffer
aller Tabellen in die Warteschlange des Flush-Threads gelegt und dann gewartet, bis alle Daten in
die Datenbank geschrieben wurden.
Die Länge der Warteschlange für die asynchronen Flush-Funktion ist per Default 4 und kann über
den Tweak-Wert dbstore.backgroundFlushQueue konfiguriert werden — die Länge ist aber
relativ unerheblich, da die Warteschlange in der Regel leer sein sollte, da nur recht selten Einträge
in ihr abgelegt werden. Sollte die Warteschlange häufig voll sein und damit den Arbeitsthread
blockieren, sollte die Größe der Einfügepuffer erhöht werden — das kann über den Tweak-
Wert dbstore.insertionBufferFactor geschehen. Dabei ist allerdings zu beachten, dass die
Größe jedes einzelnen Puffers durch die MySQL-Konfigurationsvariable max_allowed_packet
begrenzt ist — gegebenenfalls muss auch diese erhöht werden. Die Warteschlange dient also
vornehmlich der Entkopplung der langwierigen Flush-Operation, so dass diese parallel zur
Analyse des Wiki-Textes ausgeführt werden kann. Wird dbstore.backgroundFlushQueue
auf 0 gesetzt, so wird die Flush-Operation „durchgekoppelt“ und keine Warteschlange verwendet
— in diesem Fall muss der Arbeitsthread warten, während volle Einfügepuffer in
die Datenbank übertragen werden. Werden die Tweak-Werte dbstore.useEntityBuffer und
dbstore.useRelationBuffer auf false gesetzt, so wird für das Einfügen in die Datenbank
gar kein Puffer benutzt, jeder Eintrag wird sofort übertragen. Dieser Modus ist allerdings sehr
langsam und nur für die Fehlersuche sinnvoll.
8. Analyse des Wiki-Textes
Dieses Kapitel beschreibt, wie der Wiki-Text analysiert wird, um alle für WikiWord relevanten
Eigenschaften (Features) zu extrahieren und wie diese Eigenschaften im Ressourcenmodell
repräsentiert werden. Relevante Eigenschaften sind unter anderem die Wiki-Links (inklusive
Kategorisierung, Language-Links etc., siehe .A.3), der Einleitungssatz (Glosse) und die verwendeten
Vorlagen und ihre Parameter (.A.5).
Die Logik zur Analyse von Wiki-Text (und, soweit notwendig, von natürlicher Sprache),
sind im Java Package de.brightbyte.wikiword.analyzer implementiert. Das Package de.
brightbyte.wikiword.wikis enthält Klassen, die das sprach- bzw. projektspezifische Wissen
repräsentieren, das notwendig ist, um denWiki-Text zu analysieren. Die in diesen Packages implementierten
Regeln und Muster basieren auf Informationen darüber, wieWiki-Text im Allgemeinen
und Wikipedia-Seiten im Speziellen aufgebaut sind. Insbesondere repräsentieren sie:
1. Die Wiki-Text Markup Syntax, wie von MediaWiki festgelegt (Anhang A). Diese Regeln
sind, soweit sie für WikiWord relevant sind, fest in PlainTextAnalyzer kodiert.
2. Die Konventionen und Richtlinien der einzelnen Wiki-Projekte, die zum Beispiel festlegen,
wie Artikel strukturiert werden [WP:ARTIKEL], wie Kategorien zu verwenden sind
[WP:KAT] oder wann und wie Begriffsklärungsseiten anzulegen sind [WP:BKL]. Diese Regeln
sind, soweit sie für WikiWord relevant sind, zumeist in der projektspezifischen Subklasse
von WikiConfiguration definiert, zum Teil aber auch fest in WikiTextAnalyzer kodiert.
3. Beobachtungen darüber, wann bestimmte Textmuster auftreten oder wie das Wiki-Text-
Markup verwendet wird. Das sind zum Beispiel die Menge der in einer Sprache häufig
auftretenden Abkürzungen, wichtig für das Erkennen des Endes der Glosse — diese
Information ist als sprachspezifisches Wissen in der betreffenden Subklasse von
LanguageConfiguration abgelegt. Ein anderes Beispiel sind Vorlagen, die häufig inline
im Text verwendet werden und daher vor der Verarbeitung aufgelöst werden sollten.
Sie sind mit den anderen projektspezifischen Informationen in einer Subklasse von
WikiConfiguration definiert.
Zu beachten ist, dass WikiWord ad-hoc-Heuristiken nach Möglichkeit vermeidet und statt dessen
versucht, direkt explizite Konventionen zu modellieren. So profitiert WikiWord stärker von
der Intention der Autoren des Wiki-Textes und ist weniger auf die Intuition des Programmierers
angewiesen.
8.1. Klassen
Dieser Abschnitt beschreibt die Klassen, die für die Analyse des Wiki-Textes und eine
Übertragung in das Ressourcenmodell wichtig sind.
8. Analyse des Wiki-Textes 41
PlainTextAnalyzer: Die Klasse PlainTextAnalyzer bietet einfache Funktionen zur Analyse
natürlichsprachlicher Texte, insbesondere eine Methode zur Extraktion des ersten Satzes
aus einem Text, und eine Funktion zur Extraktion einzelner Wörter aus einer Zeichenkette.
Instanzen von PlainTextAnalyzer sollten über die Methode getPlainTextAnalyzer
erzeugt werden: Sie lädt die für die gegebene Sprache passende Implementation und
Konfiguration. Die Default-Implementation funktioniert bei entsprechender Konfiguration
über eine LanguageConfiguration für die meisten europäischen Sprachen.
LanguageConfiguration: Die Klasse LanguageConfiguration repräsentiert eine
Konfiguration von PlainTextAnalyzer für eine bestimmte Sprache. Die wichtigste
sprachspezifische Information, die diese Klasse kapselt, ist ein Muster für
häufig verwendete Abkürzungen dieser Sprache, das bei der Satzgrenzenerkennung
verwendet wird. Für Deutsch und Englisch sind Konfigurationen im Package
de.brightbyte.wikiword.wikis definiert, für weitere Sprachen wie Französisch,
Niederländisch und Norwegisch ist eine rudimentäre Basiskonfiguration vorhanden.
WikiTextAnalyzer: Die Klasse WikiTextAnalyzer enthält Logik für die Verarbeitung vieler
Aspekte des von MediaWiki verwendeten Wiki-Text-Markups (.A). Insbesondere bietet
sie Methoden für den Zugriff auf Wiki-Links, Vorlagen und Artikelabschnitte, sowie
Funktionalität zum Entfernen von Wiki-Markup, um „einfachen“ Text zur weiteren
Verarbeitung zu erzeugen. Instanzen von WikiTextAnalyzer sollten über die Methode
getWikiTextAnalyzer erzeugt werden: Sie lädt die für den gegebenen Korpus passende
Implementation und Konfiguration.
WikiTextAnalyzer.WikiPage: Die Klasse WikiTextAnalyzer.WikiPage repräsentiert eine
Seite imWiki und implementiert damit das Ressourcenmodell vonWikiWord (.4.1). Sie bietet
Zugriff auf die verschiedenen Eigenschaften der Seite, wie sie von WikiTextAnalyzer
erkannt wurden. Diese sind im Anhang D.1 beschrieben.
WikiConfiguration: Die Klasse WikiConfiguration repräsentiert eine Konfiguration von
WikiTextAnalyzer für ein bestimmtes Wiki-Projekt. Sie enthält Wissen über diverse
Konfigurationen und Konventionen für das betreffende Wiki. Konfigurationen sind im
Package de.brightbyte.wikiword.wikis vorhanden für die deutschsprachige (de.
wikipedia.org) und die englischsprachige Wikipedia (en.wikipedia.org) sowie rudimentär
angelegt für die französischsprachige (fr.wikipedia.org), niederländischsprachige
(nl.wikipedia.org) und norwegischsprachige (no.wikipedia.org).
WikiTextSniffer: Die Klasse WikiTextSniffer erlaubt es, typische Elemente vonWiki-Text
zu erkennen. Das ist nützlich für Sanity-Checks: so sollten zum Beispiel Konzeptnamen und
Terme, die ausWiki-Links extrahiert wurden, keinenWiki-Text mehr enthalten. Tun sie das
doch, werden sie ignoriert. Das sollte nur dann auftreten, wennWiki-Markup auf inkorrekte
oder sehr ungewöhnliche Weise verwendet wurde.
Die Klassen und Dateien, die zur Konfiguration Wiki-spezifischer Werte und Muster verwendet
werden, sind in Anhang B.7 beschrieben.
8. Analyse des Wiki-Textes 42
8.2. Mechanismen
Zur Verarbeitung des Wiki-Textes werden verschiedene Techniken verwendet, hauptsächlich aber
Mustererkennung (Pattern Matching), wobei die Muster nicht unbedingt direkt auf den vollen
Wiki-Text angewendet werden, sondern zum Teil auf schon vorverarbeiteten Text oder Textstücke.
Um die verschiedenen Muster und Regeln in WikiConfiguration zu definieren, werden vor
allem die folgenden Klassen verwendet:
Pattern: Ein regulärer Ausdruck, in Javas eigener Implementation [JAVA:RE]. Wird für einfache
Mustererkennung im Text verwendet.
AbstractAnalyzer.Mangler: Ein Interface für Klassen, die Text manipulieren, also
Ersetzungen irgendeiner Form durchführen. Standard-Implementationen dieses Interfaces
sind WikiTextAnalyzer.BoxStripManger zum Entfernen von Blockstrukturen
aus Wiki-Text .8.3, WikiTextAnalyzer.EntityDecodeManger zum Auflösen
von HTML Character References [W3C:HTML (1999)] und AbstractAnalyzer.
RegularExpressionMangler, der beliebige Textersetzungen auf der Basis von regulären
Ausdrücken vornimmt.
AbstractAnalyzer.SuccessiveMangler: Ebenfalls ein Interface für Klassen, die Text manipulieren.
SuccessiveMangler hat dabei zusätzlich die Eigenschaft, dass er den gegebenen
Text nicht unbedingt bis zum Ende verarbeitet und dass die Verarbeitung dort fortgesetzt
werden kann, wo sie unterbrochen wurde. So kann der Text sukzessive verarbeitet werden,
genau so weit, wie das Ergebnis tatsächlich benötigt wird. Die bereits erwähnte Klasse
WikiTextAnalyzer.BoxStripManger zum Entfernen von Blockstrukturen ausWiki-Text
implementiert dieses Interface zusätzlich zu AbstractAnalyzer.Mangler — das ist insbesondere
für das Aufspüren des ersten Absatzes eines Artikels nützlich.
AbstractAnalyzer.Armorer: Interface für Klassen, die Teile des Textes durch Platzhalter ersetzen,
um sie so vor weiteren Verarbeitungsschritten zu schützen. Das ist insbesondere für
Abschnitte imWiki-Text sinnvoll, die als verbatim markiert sind, auf die also die Regeln des
Wiki-Markup nicht angewendet werden sollen (.8.3). Das sind insbesondere Kommentare
sowie Text in <nowiki>- und <pre>-Tags (siehe .A). Die Standard-Implementation dieses Interfaces ist AbstractAnalyzer.RegularExpressionArmorer — sie identifiziert zu schützende Teile des Wiki-Textes mit Hilfe eines regulären Ausdrucks. WikiTextAnalyzer.Sensor: Interface für Klassen, die eine WikiPage auf Grund einer ihrer Eigenschaften klassifizieren: die Methode sense gibt zurück, ob der Sensor zu der gegebenen WikiPage passt; die Methode getValue liefert den Wert, der der Seite gegebenenfalls zugeordnet werden soll. Für dieses Interface gibt es eine ganze Reihe von Implementationen: HasCategorySensor: Stellt fest, ob die Seite zu einer bestimmten Kategorie gehört. HasCategoryLikeSensor: stellt fest, ob die Seite zu einer Kategorie gehört, deren Name zu einem bestimmten regulären Ausdruck passt. 8. Analyse des Wiki-Textes 43 HasSectionSensor: Stellt fest, ob die Seite einen Abschnitt mit einem bestimmten Namen hat. HasSectionLikeSensor: stellt fest, ob die Seite einen Abschnitt hat, dessen Name zu einem bestimmten regulären Ausdruck passt. HasTemplateSensor: Stellt fest, ob die Seite eine bestimmte Vorlage verwendet. Optional kann auch verlangt werden, dass die Vorlage mit einem bestimmten Parameter verwendet wird und dass diesem Parameter ein bestimmter Wert zugewiesen wurde. HasTemplateLikeSensor: Stellt fest, ob wenn die Seite eine Vorlage verwendet, deren Name zu einem bestimmten regulären Ausdruck passt. Optional kann auch verlangt werden, dass die Vorlage mit einem bestimmten Parameter verwendet wird und dass der Wert, der diesem Parameter zugewiesen wurde, zu einem bestimmten regulären Ausdruck passt. RegularExpressionCleanedTextSensor: Stellt fest, ob der bereinigte Text der Seite (.8.3) zu einem bestimmten regulären Ausdruck passt. RegularExpressionTitleSensor: Stellt fest, ob der Titel der Seite zu einem bestimmten regulären Ausdruck passt. Sensoren dieser Art werden vornehmlich für die Klassifikation von Ressourcen und Konzepten verwendet (siehe .8.5 bzw. .8.6). Mit diesen Mitteln lassen sich die Eigenheiten eines Wikipedia-Projektes ausdrücken und in einer Subklasse von WikiConfiguration festhalten, auf die WikiTextAnalyzer bei der Analyse von Wiki-Text zurückgreifen kann. 8.3. Bereinigen Für die Verarbeitung von Wiki-Text ist es nützlich, bestimmte Arten oder Aspekte des Wiki- Markups vorab zu entfernen. Wie in .D.1 erwähnt, kennt WikiWord vier Versionen des Wiki- Textes: text: der unveränderte Wiki-Text. cleanedText: der Wiki-Text ohne störende Elemente, nach Anwendung von WikiTextAnalyzer.stripClutter. Diese Form des Textes ist die Basis für die weitere Analyse (Extraktion von Vorlagen, Links, Kategorien etc). flatText: der Wiki-Text ohne Blöcke, nach Anwendung von WikiTextAnalyzer. stripBoxes. Diese Form des Textes ist die Basis für die weitere Analyse auf der Textebene (Extraktion der Glosse, von Absätzen etc.). plainText: der Text nach dem Entfernen sämtlicher Markup-Elemente, also nach Anwendung von WikiTextAnalyzer.stripMarkup. Diese Form des Textes kann für eine weitere Verarbeitung auf der Ebene natürlicher Sprache verwendet werden. 8. Analyse des Wiki-Textes 44 Die einzelnen Methoden zum Bereinigen des Textes werden im Folgenden näher erläutert: WikiTextAnalyzer.stripClutter: Diese Methode entfernt oder transformiert alle solchen Wiki-Text-Elemente, die für die Analyse im Rahmen dieser Arbeit unnötig oder störend sind, und ruft dann WikiTextAnalyzer.resolveMagic auf. Alle anderen Analysemethoden werden auf den so bereinigten Text angewendet (oder auf eine weiter bereinigte Version). Vollständig entfernt werden <gallery>-Blöcke, alle eingebundenen Bilder (also Wiki-Links in den Image-Namensraum) [MW:IMAGES] (.A.3) sowie alle Optionen der Form .*? [MW:MAGIC] (.A.6). Definiert werden diese Ersetzungen durch WikiConfiguration.stripClutterManglers. Ebenfalls durch WikiConfiguration.stripClutterManglers werden Ersetzungen definiert, die wohlbekannte, wikispezifische Vorlagen ersetzen, insbesondere Formatierungshilfen, die inline im Text verwendet werden. Für die englischsprachige Wikipedia werden zum Beispiel unter Anderem folgende Ersetzungen vorgenommen: {{dot}} durch „·“ (Unicode U+00B7), {{sub|xxx}} durch „xxx“ und {{frac|a|b}} durch „a/b“. Zudem wird eine Vielzahl von Vorlagen einfach entfernt, zum Beispiel {{fact}}, das in der englischen Wikipedia auf eine unbelegte Aussage hinweist. Wichtig ist auch, dass in diesem Schritt Vorlagen ersetzt werden, die Teile von Markup-Konstrukten enthalten, die für die weitere Verarbeitung benötigt werden: In der englischsprachigen Wikipedia muss zum Beispiel die Vorlage {{wrapper}} durch „{|“ (Tabellenanfang) und {{end}} durch „|}“ (Tabellenende) ersetzt werden. Einige Arten von Wiki-Text-Konstrukten werden nicht einfach entfernt oder umgewandelt, sondern durch einen Platzhalter ersetzt, so dass sie zwar von der weiteren Verarbeitung ausgeschlossen sind, aber später wieder eingefügt werden können (Armoring): das ist vor allem für Blöcke der Fall, in denen Wiki-Text-Markup keine Anwendung findet, per Default also bei Kommentaren (<!.*?>) sowie bei <nowiki>- und <pre>-Blöcken (.A). Diese Blöcke werden durch WikiConfiguration.stripClutterArmorers festgelegt. WikiTextAnalyzer.resolveMagic: Diese Methode ersetzt einige Magic Words durch ihren konkreten Wert [MW:MAGIC]: sie verwendet den in WikiConfiguration.magicPattern definierten regulären Ausdruck, um solche Magic Words zu finden, und ruft dann WikiTextAnalyzer.evaluateMagic auf, um ihren Wert zu ermitteln. Ersetzt werden solche Magic Words, die als Variablen für verschiedene Versionen des Seitentitels oder des Namensraumes der Seite funktionieren, konkret solche, die zu folgendem regulären Ausdruck passen: \{\{\s*((FULL|SUB|BASE)?PAGENAMEE?|NAMESPACEE?)\s*\}\} . Andere Magic Words werden später genau wie Vorlagen behandelt (wenn sie der Vorlagen-Syntax folgen, siehe .8.4), oder wurden vorher bereits von WikiTextAnalyzer. stripClutter entfernt (im Fall von Optionen wie NOTOC). WikiTextAnalyzer.stripBoxes: Diese Methode liefert den „eigentlichen“ Inhalt der Wiki- Seite (den Fließtext), ohne Bilder, Tabellen, Infoboxen, Hinweise und dergleichen, aber noch mit Markup zur Textformatierung sowie Wiki-Links. Die Ersetzungen, die anzuwenden sind, um das zu erreichen, werden von WikiConfiguration.stripBoxesManglers 8. Analyse des Wiki-Textes 45 definiert. Als Eingabe wird Text erwartet, der bereits durch WikiTextAnalyzer. stripClutter bereinigt wurde. Per Default enthält stripBoxesManglers genau einen Mangler, nämlich eine Instanz von WikiTextAnalyzer.BoxStripMangler: Er entfernt alle expliziten Blockstrukturen, also Tabellen, Vorlagen (soweit nicht bereits ersetzt) sowie <div>- und <center>- Blöcke; diese werden in der Wikipedia fast nie im Fließtext des Artikels verwendet, sondern nur für „Kästen“ (Floats), Warnungen, Hinweise, usw. (<p>-Blöcke dagegen kommen manchmal im Fließtext vor, und werden eher selten für Floats verwendet). Das Entfernen der Blockstrukturen erfolgt durch rekursives Parsen anhand der öffnenden und schließenden Elemente der einzelnen Strukturen, implementiert als Kellerautomat in WikiTextAnalyzer.BoxStripMangler.mangle. WikiTextAnalyzer.stripMarkup: Diese Methode entfernt alle Markup-Elemente aus einem Text — als Eingabe wird Text erwartet, der bereits durch WikiTextAnalyzer. stripBoxes bereinigt wurde. Die Ersetzungen, die anzuwenden sind, um das zu erreichen, werden von WikiConfiguration.stripMarkupManglers definiert. Per Default werden folgende Ersetzungen durchgeführt: • Zeilen, die nur aus  bestehen, definieren horizontale Trennlinien; sie werden entfernt. • Alle Wiki-Links werden durch ihren Link-Text ersetzt. • Alle externen Links werden durch ihren Link-Text ersetzt oder, wenn kein Link-Text angegeben ist, durch die URL, auf die sie verweisen. • Doppelpunkte am Anfang einer Zeile werden durch eine entsprechende Anzahl Tabs ersetzt (Unicode U+0009). • Alle Gruppen von zwei oder drei aufeinanderfolgenden Apostrophen (Unicode U+0027) werden entfernt. • Alle verbleibenden XML-artigen Tags werden entfernt—dabei bleibt gegebenenfalls der Text zwischen Start- und End-Tag erhalten. • Alle HTML-artige Entity-Referenzen werden unter Verwendung von WikiTextAnalyzer.EntityDecodeMangler.mangle dekodiert [W3C:HTML (1999)]. 8.4. Extraktion von Vorlagen WikiWord analysiert auch die Verwendung von Vorlagen (Templates) auf Wiki-Seiten (.A), vornehmlich, weil diese einen guten Anhaltspunkt für die Klassifikation der Seite bzw. des Konzeptes bietet. Die Verarbeitung der Vorlagen ist in WikiTextAnalyzer.extractTemplates implementiert; sie ist konzeptionell als Kellerautomat umgesetzt, wobei allerdings verschachtelt auftretende Vorlagen lediglich gezählt werden. Nur die Verwendung auf der „obersten“ Ebene wird registriert und gespeichert. 8. Analyse des Wiki-Textes 46 Die Vorlagen, die auf einer Wiki-Seite verwendet werden, werden als Datenstruktur vom Typ java.util.Map repräsentiert; die Schlüssel in der Map sind die normalisierten Namen der verwendeten Vorlagen, die den Schlüsseln zugeordneten Werte sind selbst wieder Maps, die die Parameter der Vorlage als Schlüssel-Wert-Paare enthalten; unbenannte (positionale) Parameter werden, wie in MediaWiki selbst, mit 1 beginnend durchnummeriert. Die Repräsentation in einer Map hat zur Folge, dass, sollte eine Vorlage auf derselben Seite mehrfach verwendet werden, nur das letzte Auftreten der Vorlage beachtet wird. Zwar kommt es recht häufig vor, dass Vorlagen mehrfach verwendet werden, jedoch trifft dies kaum auf die Art von Vorlage zu, die vonWikiWord von Interesse für die Klassifikation der Seite wäre — oder es ist für die Klassifikation zumindest unerheblich, wie oft die Vorlage auf der Seite vorkommt. Vorlagen, deren Name mit „#“ beginnt, werden als Parser Functions erkannt und übergangen. Vorlagen, deren Namen einen Doppelpunkt „:“ enthält, werden daraufhin untersucht, ob der Teil vor dem Doppelpunkt der Name eines relevanten Magic Words ist (WikiTextAnalyzer. getMagicTemplateId) — falls das der Fall ist, wird der Schlüssel auf den kanonischen Namen des Magic Words gesetzt und der Teil des ursprünglichen Namens, der auf den Doppelpunkt folgt, als Parameter mit dem Namen „0“ interpretiert. Auf diese Wiese lässt sich insbesondere die Verwendung von {{DISPLAYTITLE:...}} und {{DEFAULTSORT:...}} festhalten (siehe .A.6); diese Information kann später zur Bestimmung der Bezeichnungen für ein Konzept beitragen (siehe .8.9 und .9.1). 8.5. Ressourcenklassifikation Die Methode WikiTextAnalyzer.determineResourceType bestimmt den ResourceType: Das heißt, sie weist einerWiki-Seite (Ressource) einen Typ aus einer fest vorgegebenen Menge zu (vergleiche .4.1). Von diesem Typ hängt die weitere Verarbeitung der Seite ab, siehe .9.1. Die Zuweisung wird in WikiConfiguration.resourceTypeSensors definiert, die Regeln sind im Allgemeinen Wiki-spezifisch. Die folgenden Typen werden verwendet: ARTICLE: Die Ressource ist ein Artikel, das heißt, sie beschreibt ein Konzept. Solche Seiten liefern den eigentlichen enzyklopädischen Inhalt der Wikipedia. Dieser Typ wird allen Seiten zugewiesen, die zu keinem der anderen Typen passen. REDIRECT: Die Ressource definiert eine Weiterleitung auf eine andere Seite (also einen Alias für das entsprechende Konzept). Dieser Typ wird allen Seiten zugeordnet, die zu dem in WikiConfig.redirectPattern festgelegten Muster passen. DISAMBIG: Die Ressource ist eine Begriffsklärungsseite, das heißt, sie führt verschiedene Bedeutungen eines Terms auf (.8.10). Seiten dieses Typs lassen sich meist an der Verwendung einer speziellen Vorlage erkennen: in der deutschsprachigen Wikipedia zum Beispiel wird dieser Typ allen Seiten zugewiesen, die die Vorlage {{Begriffsklärung}} enthalten. LIST: Die Ressource ist eine explizite Liste von Seiten (und damit Konzepten) mit einer bestimmten Eigenschaft. Seiten dieses Typs lassen sich meist an ihrem Titel oder einer ihrer 8. Analyse des Wiki-Textes 47 Kategorien erkennen: in der deutschsprachigen Wikipedia zum Beispiel wird dieser Typ allen Seiten zugewiesen, die in einer Kategorie sind, die Liste heißt oder deren Name mit Liste_ beginnt. CATEGORY: Die Ressource ist eine Kategorie, das heißt, eine Sammlung von Seiten bzw. Konzepten, die dem Konzept, das die Kategorie selbst repräsentiert, untergeordnet sind. Dieser Typ wird allen Seiten aus dem Kategorie-Namensraum zugewiesen, das heißt, sie werden an ihrem Titel erkannt. BAD: Die Seite ist als problematisch markiert; das betrifft vor allem so genannte Löschkandidaten [WP:LR], also Seiten, die aus irgendeinem Grund zur Löschung aus der Wikipedia vorgeschlagen wurden. Seiten dieses Typs lassen sich meist über die Verwendung einer speziellen Vorlage erkennen: in der deutschsprachigen Wikipedia zum Beispiel wird dieser Typ unter Anderem allen Seiten zugewiesen, die die Vorlage {{Löschen}} enthalten. 8.6. Konzeptklassifikation Konzepten wird während des Imports ein ConceptType aus einer fest vorgegebenen Menge von Typen zugewiesen. Diese Konzepttypen sind unabhängig von der Sprache und dem Wiki (bzw. Korpus) und dienen einer groben Filterung der Konzepte je nach Anwendungsbereich, insbesondere für die Named Entity Recognition [DAKKA UND CUCERZAN (2008), TORAL UND MUNOZ (2006)]. Sie werden von der Methode WikiTextAnalyzer.determineConceptType unter Verwendung der Sensoren in WikiConfiguration.conceptTypeSensors bestimmt. Die folgenden Konzepttypen sind definiert: UNKNOWN: Unbekannter Typ — wird verwendet, wenn der Konzepttyp nicht bestimmt werden konnte, weil es keine beschreibende Ressource (also keine Wiki-Seite) zu dem Konzept gibt. Das kommt insbesondere für solche Konzepte vor, die im Wiki zwar referenziert, aber nicht erklärt werden (insbesondere also „rote Links“ und Navigationskategorien, .9.1). PLACE: Orte, Regionen, geografische Einheiten. Solche Einträge könnten für den Aufbau bzw. die Erweiterung eines Gazetteers verwendet werden und sind besonders für Aufgaben wie Named Entity Recognition und damit Topic-Tracking nützlich. Beim Aufbau eines Wörterbuches dagegen können Orte gegebenenfalls ausgelassen werden. PERSON: Natürliche Personen. Solche Einträge könnten für den Aufbau bzw. die Erweiterung eines Personenregisters verwendet werden und sind ebenfalls besonders für Aufgaben wie Named Entity Recognition und damit Topic-Tracking nützlich. Beim Aufbau eines Wörterbuches dagegen sollten Personen in der Regel nicht aufgenommen werden. ORGANISATION: Organisationen wie Firmen, Regierungs- und Nichtregierungsorganisationen (NGOs), etc. Auch solche Einträge sind besonders für Aufgaben wie Named Entity Recognition und damit Topic-Tracking nützlich. Beim Aufbau eines Wörterbuches dagegen sollten Organisationen meist nicht aufgenommen werden. 8. Analyse des Wiki-Textes 48 NAME: Vor- oder Nachnamen an sich (nicht die betreffenden Personen). Solche Einträge könnten für den Aufbau bzw. die Erweiterung eines Namenslexikons verwendet werden und sind unter Umständen für Aufgaben wie Named Entity Recognition und damit Topic-Tracking nützlich. Beim Aufbau eines Wörterbuches dagegen können Namen im Allgemeinen ausgelassen werden. TIME: Zeitperioden (wie z. B. 15. JAHRHUNDERT) oder auch ein wiederkehrendes Datum (wie z. B. 6. APRIL). Solche Einträge könnten für den Aufbau bzw. die Erweiterung eines Almanachs verwendet werden. Beim Aufbau eines Wörterbuches dagegen sollten sie nicht verwendet werden. NUMBER: Zahlen an sich. Diese können beim Aufbau eines Wörterbuches in der Regel übergangen werden. LIFEFORM: Lebensformen, also biologische Taxa, Klassen, Familien, Rassen usw. von Tieren und Pflanzen. Diese können beim Aufbau eines Wörterbuches unter Umständen ausgelassen werden. OTHER: Sonstige Konzepte—alle, denen keiner der oben angegebenen Typen zugeordnet werden konnte. ALIAS: Pseudo-Konzept für Aliase; wird nur aus technischen Gründen vorübergehend benötigt (.A.6) und sollte im fertigen Thesaurus nicht vorkommen. Die Zuordnung von Konzepttypen wird in .12.1 evaluiert. 8.7. Links Wiki-Links (.A.3) sind eine reiche Informationsquelle: sie bieten Zugang zu menschlichem Urteil darüber, welche Konzepte für das Verständnis eines anderen Konzeptes relevant sind (durch Querverweise, [WP:V] sowie [ZESCH U. A. (2007A), PONZETTO UND STRUBE (2007C), GREGOROWICZ UND KRAMER (2006)]), sowie welche Bezeichnung (Term) für welches Konzept geeignet ist (durch den Link- Text, [MIHALCEA (2007)] sowie [CRASWELL U. A. (2001), EIRON UND MCCURLEY (2003), KRAFT UND ZIEN (2004)]). Die Methode WikiTextAnalyzer.extractLinks extrahiert alleWiki-Links aus dem gegebenen Text. Der Text sollte bereits mit stripClutter bereinigt worden sein. Der genaue Algorithmus ist in Anhang E.1 beschrieben. Die WikiLink-Objekte, die dabei erzeugt werden, haben insbesondere die folgenden Eigenschaften (vergleiche .A.3): interwiki: der Präfix für Interwiki-Links (null, falls der Link kein Interwiki-Link ist). namespace: die ID des Namensraumes, in den der Link verweist, wie von WikiTextAnalyzer. getNamespaceId geliefert (siehe auch .B.7). 8. Analyse des Wiki-Textes 49 page: der Titel der Seite, auf die der Link zeigt (ohne Namensraum, Interwiki-Präfix, Abschnitt, etc.) in normalisierter Form (also mit Unterstrichen statt Leerzeichen und dem ersten Buchstaben als Großbuchstaben). section: der Abschnitts-Anker (bzw. das „Dokumentenfragment“ nach der URL-Spezifikation) auf der Zielseite in normalisierter Form (oder null, wenn auf keinen Abschnitt verwiesen wird). text: der verwendete Link-Text (Label). Falls nicht explizit ein Link-Text angegeben wurde, so wird der Text, der zur Angabe des Link-Zieles verwendet wurde, als Link-Text angenommen und gegebenenfalls der Link-Trail angehängt. Ist der Link ein Kategorisierungslink, hat also die Eigenschaft magic den Wert CATEGORY, so gibt die Eigenschaft text den Sort-Key für die Kategorisierung an. impliedText: ist true genau dann, wenn der Text nicht explizit angegeben wurde, sondern aus dem Link-Ziel geschlossen wurde. magic: gibt an, inwiefern der Link „magisch“ ist, dass heißt, ob er eine spezielle Semantik hat. Die möglichen Werte werden von WikitextAnalyzer.LinkMagic definiert: NONE: „normaler“ Wiki-Link, keine „Magic“. CATEGORY: Zuweisung einer Kategorie an die Seite, die den Link enthält. IMAGE: Einbinden eines Bildes; da Bilder schon von stripClutter entfernt werden, sollte das hier nicht vorkommen. LANGUAGE: Verknüpfung mit einer (semantisch) äquivalenten Seite in einer anderen Sprache. Dabei ist zu beachten, dass z. B. ein Link in den Kategorie-Namensraum auch ohne die Kategorisierungssemantik vorkommen kann, nämlich genau dann, wenn er mit einem führenden Doppelpunkt definiert wurde, also in der Form [[:Category:Baum]]. Dasselbe gilt analog für Links in den Image-Namensraum und auch für Links mit Interwiki-Präfix (siehe auch .A.3). Die so extrahierten Links dienen, je nach ihrer magic, zur Bestimmung der semantischen Verwandtheit von Konzepten (.9.1.3), dem Zusammenführen von äquivalenten Konzepten aus unterschiedlichenWikipedias (.9.2.2), dem Aufbau der Subsumtionsrelation oder, unter Verwendung des Link-Textes, der Zuordnung von Termen zu Konzepten (.9.1). Sie sind damit von zentraler Bedeutung für den Aufbau des Thesaurus, da sie nahezu alle betrachteten Relationen direkt oder indirekt definieren. 8.8. Extraktion von Glossen Definitionssätze (Glossen) können in einem Artikel recht einfach gefunden werden: per Konvention [WP:WSIGA] definiert der erste Satz immer den Gegenstand des Artikels. Den 8. Analyse des Wiki-Textes 50 ersten Satz zu finden, ist allerdings nicht ganz trivial: aus dem bereinigten Text (nach WikiTextAnalyzer.stripClutter) wird zunächst der erste Absatz extrahiert, also der Text bis zur ersten leeren Zeile, oder der ersten Überschrift. Diese Arbeit erledigt die Methode WikiTextAnalyzer.extractFirstParagraph, welche auf WikiConfiguration. extractParagraphMangler zurückgreift. Per Default ist das eine speziell konfigurierte Instanz von WikiTextAnalyzer.BoxStripMangler, die nach Entfernen aller Blöcke (siehe .8.3) nur den ersten Absatz liefert—der Rest des Textes wird aus Effizienzgründen nicht weiter behandelt. Der so gewonnene erste Absatz wird dann mittels WikiTextAnalyzer.stripMarkup weiter bereinigt, so dass nur noch reiner Text ohne Markup übrig bleibt. Zusätzlich werden weitere Elemente mittels LanguageConfiguration.sentenceManglers entfernt, per Default insbesondere alle geklammerten Teilsätze. Aus dem bereinigten ersten Absatz wird dann der erste Satz als Glosse extrahiert. Der Algorithmus für diese Aufgabe ist in Anhang E.2 detailliert beschrieben. Bei den so extrahierten Sätzen handelt es sich fast immer um Definitionssätze der Form „X ist/sind/ war (ein) Y“; allerdings kommt es vor, dass die Aussagekraft der Definition zu wünschen übrig lässt — zum Beispiel lautet der Einleitungssatz für den Artikel Weltoffenheit1: „Weltoffenheit ist ein Begriff aus der philosophischen Anthropologie.“ — dieser Satz beschreibt nicht, was WELTOFFENHEIT ist, sondern lediglich, welcher Fachbereich sie untersucht. Aber selbst diese Art der Ungenauigkeit ist verhältnismäßig selten (.12). Eine mögliche Lösung wäre es, den ganzen ersten Absatz als Definition zu verwenden oder zumindest zusätzlich vorzuhalten, wie es in der Literatur vorgeschlagen wurde (vergleiche die Arbeiten in .2.4, z. B. [STRUBE UND PONZETTO (2006)]). Im Falle des Artikels Weltoffenheit wäre das zielführend, der Absatz lautet als Ganzes: Weltoffenheit ist ein Begriff aus der philosophischen Anthropologie. Er bezeichnet die Entbundenheit des Menschen von organischen Zwängen (Trieben) und seiner unmittelbaren Umwelt und betont seine Öffnung hin zu einer von ihm selbst hervorgebrachten kulturellen Welt. Hiermit einher geht, dass der Mensch ohne festgelegte Verhaltensmuster geboren wird und sich Verhaltenssicherheit in der Welt immer erst erwerben muss. Der erste Absatz enthält aber fast immer auch Text, der nicht Teil der Definition des Artikelgegenstandes ist: der zweite Satz in obigem Beispiel vervollständigt die Definition, der dritte jedoch ist schon eine Einlassung, die über eine bloße Definition hinausgeht. Immer den gesamten Absatz zu verwenden würde also das Signal-Rausch-Verhältnis in Bezug auf die Forderung, eine Definition des Konzeptes zu finden (.5.1), verschlechtern. Das oben beschriebene Verfahren zur Extraktion von Glossen wird in .12.6 evaluiert. 8.9. Terme Terme, die als Bezeichnungen für ein bestimmtes Konzept dienen, werden aus verschiedenen Quellen bestimmt, zum Beispiel aus dem Link-Text (siehe .8.7, vergleiche [MIHALCEA (2007)]), 1In der deutschsprachigen Wikipedia, zum Zeitpunkt des Erstellens dieser Arbeit: <http://de.wikipedia.org/w/index.php?title=Weltoffenheit&oldid=44584462> 8. Analyse des Wiki-Textes 51 aus Weiterleitungen (siehe .8.5) oder aus Begriffsklärungen (siehe .8.10). Aber auch aus dem Artikel selbst können schon Bezeichnungen gewonnen werden: das ist die Aufgabe der Methode PlainTextAnalyzer.determinePageTerms (bzw. PlainTextAnalyzer.getPageTerms). Sie bestimmt Bezeichnungen für das Konzept des Artikels per Default aus zwei Quellen: 1. Aus dem „Basisnamen“ des Artikels, wie er von PlainTextAnalyzer. determineBaseName zurückgegeben wird. Der „Basisname“ ist der Titel des Artikels, der mittels der Muster in WikiConfiguration.titleSuffixPattern und WikiConfiguration.titlePrefixPattern bereinigt wurde — per Default wird dabei insbesondere der geklammerte Suffix vom Titel entfernt, falls vorhanden: aus Leiter_(Gerät) wird also „Leiter“. Um die entsprechenden Terme zu erhalten, werden außerdem alle Unterstriche durch Leerzeichen ersetzt, aus Albert_Einstein wird also „Albert Einstein“. 2. Aus dem Magic Word DISPLAYTITLE, das eine alternative Bezeichnung für das Konzept definiert (siehe auch .A.6). Diese Magic Words werden bei der Extraktion der Vorlagen evaluiert (siehe .8.4). Zusätzliche Terme können aus den Sort-Keys bestimmt werden, die bei der Kategorisierung der Seite verwendet wurden (zugänglich über die Methode WikiPage.getCategories) sowie aus der Verwendung des Magic Words DEFAULTSORT (zugänglich über die Methode PlainTextAnalyzer.getDefaultSortKey), siehe .A.3 und .A.6. Der Analyzer definiert außerdem eine Methode zur Bestimmung „schlechter“ Terme, nämlich WikiTextAnalyzer.isBadTerm. Per Default ist das lediglich ein „Sanity-Check“ der Länge des Terms: diese wird mit WikiConfiguration.minTermLength und WikiConfiguration. maxTermLength verglichen. 8.10. Begriffsklärungsseiten Begriffsklärungsseiten (Disambiguierungen) dienen in der Wikipedia dazu, die möglichen Bedeutungen eines Terms aufzuzählen [WP:BKL]. Um daraus eine Liste von Konzepten zu erzeugen, müssen aus dem Wiki-Text der Begriffsklärungsseite alle Wiki-Links (und damit alle Konzepte) ausgelesen werden, die auf einen Artikel verweisen, der eine der möglichen Bedeutungen beschreibt. Das Problem besteht darin, dass Begriffsklärungsseiten noch weitere Wiki-Links enthalten können, insbesondere Querverweise und Links auf Kontext-Begriffe (vergleiche die in .2.4 beschriebenen Arbeiten, insbesondere [DAKKA UND CUCERZAN (2008), ZESCH U. A. (2007A), PONZETTO UND STRUBE (2007C)]). Diejenigen Links auf der Begriffsklärungsseite zu finden, die auf die einzelnen Bedeutungen verweisen, ist Aufgabe der Methode WikiTextAnalyzer.extractDisambigLinks. Der Standard- Ansatz macht dabei zwei wesentliche Annahmen: • die Begriffsklärungsseite enthält eine Liste von Bedeutungen derart, dass in jeder (relevanten) Zeile (höchstens) ein Link steht, der auf eine Bedeutung des zu klärenden Terms zeigt. 8. Analyse des Wiki-Textes 52 • enthält eine Zeile mehr als einen Link, so ist der Link mit der größten lexikographischen Ähnlichkeit zu dem zu klärenden Term auch der, der auf eine Bedeutung dieses Terms verweist. Auf Basis dieser Annahmen wurde der Algorithmus zur Extraktion der Bedeutungslinks aus der Begriffsklärungsseite entwickelt, der in .E.3 beschrieben ist. Die Ergebnisse dieses Verfahrens werden in .13 evaluiert. Auf diese Weise werden aus Wiki-Seiten diejenigen Eigenschaften extrahiert, die für den Aufbau eines (zunächst monolingualen) Thesaurus relevant sind. Diese Eigenschaften werden durch ein WikiPage-Objekt repräsentiert und von der Klasse ConceptImporter dann hinsichtlich ihrer Bedeutung für das Thesaurusmodell interpretiert (siehe .9.1). Die so gewonnenen Entitäten und Relationen werden in einem lokalen Datensatz abgelegt (siehe .C.1 und .C.4). 9. Verarbeitung Im Kapitel FRAMEWORK (.7) wurde erklärt, wie WikiWord aufgebaut ist und wie der Import- Prozess als Ganzes abläuft, in ANALYSE DES WIKI-TEXTES (.8) wurde gezeigt, wie Informationen aus dem Wiki-Text extrahiert werden. Dieses Kapitel soll nun erläutern, wie aufgrund dieser Informationen ein Thesaurus aufgebaut werden kann. 9.1. Import von Wiki-Seiten Der Import von Wiki-Seiten in den lokalen Datensatz (das Konzeptmodell) wird von der Methode handlePage in der Klasse ConceptImporter gesteuert: sie initiiert die Umwandlung der Wiki- Textes in ein Ressourcenobjekt vom Typ WikiPage (siehe .4.1 bzw. .8 und .D.1) und interpretiert anschießend die Eigenschaften des Ressourcenobjekts, um daraus die Relationen eines Thesaurus aufzubauen. Diese werden dann im lokalen Datenmodell abgelegt, das durch ein Datenzugriffsobjekt vom Typ LocalConceptStoreBuilder modelliert wird (siehe .C.4). Diese Interpretation der Ressourceneigenschaften als Informationen über die Konzepte, Terme und Relationen eines Thesaurus soll nun hier genauer erklärt werden. Vorab ist zu bemerken, dass Relationen im Datenmodell zum Teil mit Metainformationen über ihre Herkunft versehen sind (vergleiche z. B. .C.2 und .C.2): insbesondere wird häufig die ID der Ressource (Wiki-Seite) gespeichert, aus der eine Beziehung abgeleitet wurde, sowie in einigen Fällen zusätzlich die Regel, nach der die Relation extrahiert wurde. Die Regeln sind in der Enumeration ExtractionRule definiert; sie werden in diesem Kapitel an den betreffenden Stellen genannt. Bei der Interpretation der Ressourceneigenschaften werden unter anderem die folgenden Aspekte betrachtet: Kategorisierung: Von den Wiki-Links der Seite (.8.7) werden diejenigen betrachtet, deren magic Property den Wert LinkMagic.CATEGORY hat (.8.7, .A.3). Diese Kategorisierungslinks auf der Seite werden als Angabe von Konzepten interpretiert, die dem Konzept, das von der Seite selbst repräsentiert wird, übergeordnet sind: sie sind also eine Manifestation der Subsumtionsrelation (vergleiche [WP:KAT] sowie die in .2.4 vorgestellten Arbeiten, insbesondere [VOSS (2006), PONZETTO UND STRUBE (2007B), GREGOROWICZ UND KRAMER (2006)]). Für jeden dieser Links wird die Methode LocalConceptStore.storeConceptBroader aufgerufen (.C.4), um diese Zuordnung im lokalen Datenmodell festzuhalten (Regel ExtractionRule.BROADER_FROM_CAT). Die Zuordnung von übergeordneten Konzepten wird unter Umständen im Nachbereitungsschritt noch überarbeitet (.9.1.3), insbesondere werden Kategorisierungs- Aliase aufgelöst (siehe .9.1.2). Ein Problem, das bei der Interpretation der Kategoriestruktur von Wikipedia auftreten kann, sind so genannte Wartungskategorien, die sich nicht auf den Inhalt (das 9. Verarbeitung 54 Konzept) der Seite beziehen, sondern auf die Seite selbst — zum Beispiel die Kategorie Kategorie:Wikipedia:Lückenhaft [VOSS (2006)]. Solche Kategorien sind für einen Thesaurus nicht von Belang und können sogar irreführend sein, da sie inhaltliche Verwandtschaft suggerieren, wo keine solche existiert. WikiWord umgeht dieses Problem auf einfache Weise: Wartungskategorien werden so gut wie nie direkt einem Artikel zugewiesen, sie stammen fast immer aus einer Vorlage, die zur Markierung des Artikels verwendet wurde. Da WikiWord den Inhalt von Vorlagen aber nicht auswertet, tauchenWartungskategorien in den von WikiWord gefundenen Wiki-Links gar nicht auf. Eine weitere Art von Kategorie, die für einen Thesaurus von zweifelhaftem Wert sind, sind Navigationskategorien [GREGOROWICZ UND KRAMER (2006), HAMMW¨OHNER (2007)]. Das sind häufig sogenannte Schnittmengenkategorien, die solche Artikel enthalten, denen zwei Eigenschaften gemein sind, zum Beispiel Kategorie:Fluss_in_Bayern oder Kategorie:Politiker_(19._Jahrhundert). Oder es handelt sich um Metakategorien, die Kategorien mit ähnlicher Struktur zusammenfassen, zum Beispiel Kategorie:Fluss_nach_Staat oder Kategorie:Person_nach_Epoche. Solche Navigationskategorien werden von WikiWord als vollwertige Konzepte behandelt — zwar sind sie als eigenständige Begriffe eher ungebräuchlich oder gar künstlich, dennoch liefern sie über ihre Zuordnung von über- und untergeordneten Konzepten Informationen über die semantischen Verwandtheitsbeziehungen und können überdies auch im Thesaurus der Navigation dienen. Die Kategoriestruktur derWikipedia soll zwar per Konvention (poly-)hierarchisch sein, diese Anforderung wird aber von MediaWiki nicht geprüft. So kann die Struktur insbesondere auch Zyklen enthalten [HAMMW¨OHNER (2007)]. Diese werden von WikiWord während der Nachbereitung entfernt (.9.1.3). Link-Text Terme: Es werden alle Wiki-Links der Seite betrachtet (.8.7) und für jeden Link per LocalConceptStore.storeReference wird ein Eintrag im lokalen Datenmodell vorgenommen, der das Konzept, auf das der Link verweist, als Bedeutung mit dem verwendeten Link-Text verbindet (siehe auch .8.9). Die Verwendung eines Link-Textes für eine Referenz auf einen bestimmten Artikel wird also als Zuordnung einer Bezeichnung an das Konzept interpretiert, das der Ziel-Artikel beschreibt (vergleiche [WP:V, MIHALCEA (2007)] sowie [CRASWELL U. A. (2001), EIRON UNDMCCURLEY (2003), KRAFT UND ZIEN (2004)]): zum Beispiel würde [[Vereinigte Staaten|USA]] dafür sorgen, dass der Term „USA“ dem Konzept VEREINIGTE_STAATEN zugeordnet wird. Diese Extraktionsregel wird mit ExtractionRule.TERM_FROM_LINK identifiziert. Links, deren magic-Property nicht LinkMagic.NONE ist oder die in einen anderen Namensraum oder gar auf ein anderes Wiki verweisen, werden dabei übergangen. Für alle anderen Link-Ziele wird zunächst angenommen, dass es Artikel sind, die Konzepte beschreiben, es sich also um Seiten mit dem Typ ResourceType.ARTICLE handele. Im Nachbereitungsschritt (.9.1.3) werden dann Links auf Weiterleitungsseiten aufgelöst (DatabaseLocalConceptStoreBuilder.finishAliases), sowie alle Links auf andere Typen von Ressourcen, insbesondere auf Begriffsklärungen und als „schlecht“ markierte Seiten, entfernt (DatabaseLocalConceptStoreBuilder.finishBadLinks). 9. Verarbeitung 55 Neben der Nutzung der Zuordnung von Link-Text zu Link-Ziel zum Aufbau der Bedeutungsrelation dienen Wiki-Links auch dazu, den semantischen Kontext von Konzepten zu definieren (siehe auch .2.3): Querverweise zwischen Artikeln werden mit der Methode LocalConceptStore.storeLink gespeichert, die sowohl die Bedeutungszuweisung als auch die Assoziation von Konzepten berücksichtigt (vergleiche .C.2). Diese Information wird später vor allem zur Bestimmung der semantischen Verwandtheit verwendet (.9.1.3). Seitennamen: Eine Wiki-Seite selbst definiert bereits Terme, die als Bezeichnung für das Konzept der Seite dienen. Diesen Term zu bestimmen, ist Aufgabe von WikiPage.getPageTerms (siehe .8.9), Termzuordnungen auf dieser Basis werden mit ExtractionRule.TERM_FROM_TITLE identifiziert. Der erste Term wird aus dem Seitentitel bestimmt, gegebenenfalls bereinigt von einem Klammerzusatz. Falls nicht nur ein Titel, sondern ein ganzer Artikel zur Verfügung steht, liefert die Methode WikiPage.getPageTerms zusätzlich Terme, die mit Hilfe des Magic Words DISPLAYTITLE angegeben wurden (.A.6). Während der Verarbeitung werden die Konzeptnamen, Terme und Definitionstexte (Glossen) Sanity Checks unterzogen, um zu verhindern, dass fehlerhafte Daten in den Thesaurus aufgenommen werden. Im Einzelnen werden geprüft: 1. Die Länge von Konzeptnamen und Ressourcennamen. Sie muss zwischen den Werten liegen, die durch WikiConfiguration.minNameLength und WikiConfiguration. maxNameLength liegen (gemessen in Zeichen) — Terme und Namen, die zu kurz oder zu lang sind, werden übergangen. Per Default liegt der Minimalwert bei 1 und der Maximalwert bei 128. DatabaseLocalStoreBuilder verlangt zusätzlich, dass Namen in UTF-8-kodierter Form [UNICODE (2007), S. 103] nicht länger als 255 Byte sein dürfen, sonst werden sie abgeschnitten1. Diese Beschränkung ergibt sich aus den technischen Vorgaben der Datenbankstruktur (.C.1). 2. Die Länge von Termen. Es gelten dieselben Beschränkungen wie für Konzeptnamen, nur dass gegen die Werte von WikiConfiguration.minTermLength und WikiConfiguration.maxTermLength geprüft wird. Auch die Begrenzung auf maximal 255 Byte effektive Länge gilt für Terme. 3. Die Länge von Definitionstexten. DatabaseLocalStoreBuilder verlangt, dass der Name in UTF-8-kodierter Form nicht länger sein als 8192 Byte (8KB) sein darf — längere Texte werden abgeschnitten. 4. Terme und Konzeptnamen dürfen kein Markup enthalten, sonst werden sie übergangen — geprüft wird das mit Hilfe eines WikiTextSniffer-Objektes. Die Prüfung ist insbesondere darauf ausgelegt, auch Markup-Teile zu erkennen, die aus fehlerhafter Verwendung der Wiki-Text-Syntax herrühren. So kann es vorkommen, dass Konzepte und Terme mit 1Dabei ist zu beachten, dass jedes Zeichen in UTF-8 bis zu vier Bytes benötigt. Für lateinische Buchstaben wird jedoch nur ein Byte pro Zeichen benötigt, für Umlaute und andere in Europa übliche diakritische Zeichen typischerweise zwei. 9. Verarbeitung 56 legitimem, aber „verdächtigem“ Inhalt übergangen werden — das ist jedoch recht selten. Definitionstexte, die Markup enthalten, sind erlaubt, lösen aber eine Warnung aus. Die Interpretation der Eigenschaften der Ressource, repräsentiert durch ein WikiPage-Objekt, hängt stark vom Typ der Ressource ab, wie er von WikiTextAnalyzer bestimmt wurde (siehe .8.5). Die Verarbeitung beginnt in jeden Fall damit, dass in der Tabelle resource ein Eintrag für diese Ressource (bzw. Wiki-Seite) gespeichert wird. Das weitere Vorgehen ist für die einzelnen Ressourcetypen wie folgt definiert: Kategorieseiten (CATEGORY): Für Kategorieseiten wird lediglich der Kategorisierungsaspekt der Seite betrachtet, wie oben beschrieben. Zu beachten ist dabei, dass für die Kategorie zunächst kein Konzepteintrag angelegt wird, obwohl Kategorien grundsätzlich als Konzepte interpretiert werden. Der Grund ist, dass es eine Artikelseite geben könnte, die dieses Konzept beschreibt (siehe dazu .9.1.2). Existiert keine solche Artikelseite, so wird im Nachbereitungsschritt finishMissingRessources ein Konzepteintrag vom Typ ConceptType.UNKNOWN für das Kategorie-Konzept erstellt (.9.1.3), allerdings erst nachdem alle Kategorisierungsaliase aufgelöst wurden (.9.1.2). Eine weitere Information in Kategorieseiten, deren Verarbeitung vielversprechend ist, sind die Language-Links. Sie referenzieren Kategorien in anderen Wikis (also in anderen Sprachen) und könnten die Verknüpfungen zwischen den Artikeln unterschiedlicher Sprachen ergänzen [HAMMW¨OHNER (2007B)]. Die Auswertung dieser Information wurde hier jedoch aufgrund technischer Schwierigkeiten nicht weiter verfolgt und verbleibt als Gegenstand zukünftiger Forschung. Artikelseiten (ARTICLE): Da Artikelseiten per Definition stets ein Konzept beschreiben, wird zuerst die Methode LocalConceptStore.storeConcept aufgerufen, um einen Eintrag für das betreffende Konzept anzulegen. Der volle Seitentitel dient dabei als eindeutiger Bezeichner des Konzeptes. Dann wird die Definition des Konzeptes (die Glosse) aus dem Artikeltext extrahiert (.8.8) und mittels LocalConceptStore.storeDefinition im lokalen Datenmodell abgelegt. Als nächstes werden alle Wiki-Links der Seite bestimmt (.8.7). Auf dieser Grundlage werden die Link-Text-Terme gespeichert und die Kategorisierung bestimmt, wie oben beschrieben. Zusätzlich werden noch die folgenden Aspekte betrachtet: 1. Querverweise zwischen Artikeln werden als Referenzbeziehung bzw. Assoziation zwischen Konzepten interpretiert. Daher wird beim Speichern der Link-Text- Terme statt der Methode LocalConceptStore.storeReference die Methode LocalConceptStore.storeLink verwendet, die, zusätzlich zu der Beziehung zwischen Link-Text und Ziel-Konzept, eine Beziehung zwischen dem im Artikel beschriebenen Quell-Konzept und dem Ziel-Konzept herstellt (vergleiche .C.2). Diese Daten dienen unter anderem der Berechnung der semantischen Verwandtheit zwischen Termen (.9.1.3). 2. Wiki-Links können auch auf Teile von Seiten verweisen — solche Abschnitte, die als Verweis-Ziele dienen, werden als eigene Konzepte interpretiert, die dem Konzept, das vom Gesamtartikel beschrieben wird, untergeordnet sind (.9.1.1). 9. Verarbeitung 57 3. Bei der Kategorisierung angegebene Sort-Keys werden verwendet, um dem Konzept, auf das sich der Artikel bezieht, per LocalConceptStore.storeReference weitere Terme zuzuordnen (ExtractionRule.TERM_FROM_SORTKEY). So würde zum Beispiel die Angabe [[Kategorie:Pazifist|Einstein, Albert]] auf der Seite Albert_Einstein dafür sorgen, dass der Term „Einstein, Albert“ dem Konzept ALBERT_EINSTEIN zugeordnet wird (.A.3). Der Sort-Key wird ebenfalls berücksichtigt, wenn er über das Magic Word DEFAULTSORT angegeben wurde (zugänglich über die Methode PlainTextAnalyzer.getDefaultSortKey, siehe auch .A.6). 4. Bei der Bestimmung der Kategorisierung des Artikels kann der Artikel als Hauptartikel der betreffenden Kategorie erkannt werden, also als der Artikel, der das Konzept definiert, auf das sich die Kategorie bezieht: siehe .9.1.2. In diesem Fall wird zusätzlich der Name der Kategorie als Term für das Konzept des Artikels gespeichert (ExtractionRule.TERM_FROM_CAT_NAME). 5. Language-Links, also Wiki-Links, die den magic-Wert LinkMagic.LANGUAGE haben, werden als Verweise auf eine Beschreibung desselben oder eines ähnlichen Konzeptes in einer anderen Sprache interpretiert (siehe .A.3 sowie [WP:INTERLANG]). Diese Verweise werden mittels LocalConceptStore.storeLanguageLink im lokalen Datenmodell abgelegt. Sie dienen der Berechnung der semantischen Ähnlichkeit zwischen Termen sowie dem Zusammenführen von sprachspezifischen zu sprachübergreifenden Konzepten (.9.2.2). Begriffsklärungsseiten (DISAMBIG): Zunächst werden die Link-Text-Terme auf der Seite interpretiert, wie oben beschrieben. Dann werden alle Disambiguierungslinks bestimmt (.8.10), also Verweise auf Artikel, die eine der Bedeutungen definieren, die zum Titel der Begriffsklärungsseite passen. Jeder dieser Bedeutungen wird nun mittels LocalConceptStore.storeReference der Name der Begriffsklärungsseite als Bezeichnung zugewiesen (ExtractionRule.TERM_FROM_ DISAMBIG). Der Name der Begriffsklärungsseite wird also als Bezeichnung für diejenigen Konzepte interpretiert, die die Begriffsklärung als mögliche Bedeutungen auflistet. Das entspricht genau der Intention von Begriffsklärungsseiten, wie sie in [WP:BKL] beschrieben ist (vergleiche auch [STRUBE UND PONZETTO (2006), GREGOROWICZ UND KRAMER (2006)]). Weiterleitungsseiten (REDIRECT): Über die Methode WikiPage.getRedirect wird die Zielseite der Weiterleitung bestimmt. Mittels LocalConceptStore.storeReference wird dann der Name der Weiterleitungsseite als Bezeichnung für das Konzept registriert, auf das dieWeiterleitung zeigt (ExtractionRule.TERM_FROM_REDIRECT). Dabei kann es durchaus vorkommen, dass der Name derWeiterleitung eigentlich für ein Konzept steht, das dem Zielkonzept untergeordnet ist—das kann aber bei der Interpretation von Link-Text genauso geschehen; auch scheint diese Art von Fehlern keinen allzu problematischen Einfluss auf das Ergebnis zu haben, siehe .12.5. Häufig tritt dieser Fall zum Beispiel für Stadtteile auf, die keinen eigenen Artikel haben, sondern in dem Artikel beschrieben werden, der sich mit der Stadt als Ganzes befasst. Zusätzlich wird mittels LocalConceptStore.storeConcept ein vorläufiger Konzepteintrag vom Typ ALIAS angelegt und per LocalConceptStore. 9. Verarbeitung 58 storeConceptAlias als Alias für das Zielkonzept registriert. Der vorläufige Konzepteintrag ist aus technischen Gründen notwendig, er wird in der Nachbereitungsphase von der Methode LocalConceptStore.finishAliases zur Auflösung von Referenzen auf die Weiterleitungsseite verwendet und dann gelöscht (siehe .9.1.3). Listen (LIST): Für Listen werden lediglich die Link-Text-Terme interpretiert. Konzeptionell könnten aus Listenartikeln auch Einträge für die Subsumtionsrelation gefolgert werden: Einträge in einer Liste von X würden dann als X untergeordnet interpretiert. Dabei ergeben sich allerdings zwei Probleme: 1. Das übergeordnete Konzept, zu dem die Liste gehört, müsste namentlich identifiziert und gegebenenfalls mit der Liste assoziiert werden. Die Extraktion des Konzeptnamens aus dem Listentitel wäre für einfache Fälle machbar, z. B. für Titel der Form Liste_der_X — bei manchen Titeln würde das aber fehlschlagen, z. B. bei der Seite Comicformat, einer Auflistung unterschiedlicher Comic-Formate. Eine Zuordnung zu dem entsprechenden Artikel, der dieses Konzept beschreibt, kann aber bei mehrdeutigen Namen schwierig sein. 2. Listenartikel sind sehr unterschiedlich formatiert. Einfache Aufzählungen könnten leicht verarbeitet werden, Listenartikel sind aber häufig in Abschnitte gegliedert. Zum Teil sind Listen auch als Tabellen formatiert, bei denen die Bedeutung einzelner Spalten nicht automatisch zu erkennen ist (z. B. bei den Seiten Marientitel und Präfixe_von_Schiffsnamen2). Manchmal sind die Auflistungen hierarchisch, mit Über- und Untereinträgen. Alles in allem gibt es, anders als bei Begriffsklärungsseiten, keine einheitliche Struktur für Listenartikel, so dass es schwierig ist, sie sinnvoll zu verarbeiten. 3. Ein Problem mit der Erkennung von Listenartikeln ist, dass zum Teil Seiten als Listen klassifiziert werden, die selbst keine Liste sind, sondern eine Liste beschreiben, zum Beispiel Rote_Liste_gefährdeter_Arten. In manchen Fällen trifft sogar beides zu: der Artikel beschreibt eine Liste und enthält die Liste selbst — was eine Unterscheidung vollends unmöglich macht. Da es parallel zu einem Listenartikel in der Regel auch eine Kategorie mit ähnlichem Umfang gibt, lohnt sich der Versuch, die Listenartikel zu interpretieren, kaum. In der vorliegenden Implementation von WikiWord wird deshalb die Verknüpfungsstruktur von Seiten, die als Liste erkannt wurden, nicht untersucht. Schlechte Seiten (BAD): Seiten, die zur Löschung vorgeschlagen wurden [WP:LR] oder anderweitig als problematisch markiert sind, werden ignoriert. 9.1.1. Konzepte aus Abschnitten MediaWiki erlaubt (genau wie HTML) Verknüpfungen auf „Anker“ [W3C:HTML (1999)], also auf bestimmte Stellen innerhalb eines Artikels bzw., in URI-Terminologie, auf Dokument-Fragmente 2Beides nebenbei auch Beispiele für schwer zu interpretierende Titel. 9. Verarbeitung 59 [RFC:3986 (2005)]. In MediaWiki erzeugt jede Überschrift einen Anker, es ist also möglich, Wiki- Links direkt auf einzelne Abschnitte von Artikeln zu setzen (siehe auch .8.7 und .A.3). Solche Verknüpfungen auf Abschnitte werden vor allem dann verwendet, wenn auf ein spezielles Konzept verwiesen werden soll, das in diesem Abschnitt beschrieben ist und keinen eigenen Artikel hat; dabei handelt es sich in der Regel um ein dem Thema des Gesamtartikels untergeordnetes Konzept. So könnte z. B. der Wiki-Link [[Myanmar#Geschichte|Burmesische Geschichte]] auftreten: er verweist unter dem Term „Burmesische Geschichte“ auf das Konzept MYANMAR#GESCHICHTE, welches im Abschnitt Geschichte im Artikel Myanmar behandelt wird — wir gehen davon aus, dass es sich dabei um ein Konzept handelt, das auf irgendeine Art ein „Teil“ des Konzeptes MYANMAR ist, diesem also über die Subsumtionsrelation untergeordnet ist. Allerdings ist es schwierig, über ein solches Konzept, das aus einem Seitenabschnitt entstanden ist, mehr zu sagen, als dass es dem Konzept, das der Gesamtartikel beschreibt, untergeordnet ist: ein solcher Abschnitt enthält in der Regel keinen Definitionssatz und er kann auch nicht einzeln kategorisiert werden; selbst die Zuordnung von Templates wäre schwierig. So wird auf eine weitere Analyse des Abschnitts verzichtet: Konzepte, die sich aus Verweisen auf Abschnitte ergeben, werden lediglich vorgemerkt (.C.2) und dann in der Nachbereitung des Imports als Konzepteinträge von unbekanntem Typ (ConceptType.UNKNOWN) erzeugt und ihrem Oberkonzept zugeordnet (.9.1.3). 9.1.2. Kategorien und Konzepte Wie oben beschrieben, versteht WikiWord Kategorien zwar als Konzepte in so fern, als dass die Kategorisierung als eine Unterordnung eines Konzepts unter ein anderes im Sinne der Subsumtionsrelation interpretiert wird. Jedoch erzeugt WikiWord für Kategorie-Seiten zunächst keinen eigenen Konzepteintrag, da es einen Artikel geben könnte, der das Konzept näher beschreibt— ein solcher Artikel wird Hauptartikel der Kategorie genannt. Es ist nun wünschenswert, die Kategorie und ihren Hauptartikel als Repräsentationen desselben Konzeptes zu interpretieren und ihre Eigenschaften zu vereinigen. Dabei sind drei Fälle zu unterscheiden: 1. Es gibt einen Artikel (also eine Seite mit dem Typ ARTICLE), der genau den gleichen Titel hat wie die Kategorie (ohne Namensraum-Präfix, aber gegebenenfalls mit Klammerzusatz). Dann geht WikiWord davon aus, dass dieser Artikel der Hauptartikel der Kategorie ist, das heißt, dass sie sich auch auf dasselbe Konzept beziehen. Da der Titel als eindeutiger Bezeichner für das Konzept dient, zeigen in diesem Fall alle Verknüpfungen der Kategorie automatisch auf das betreffende Konzept, es ist keine weitere Anpassung notwendig. 2. Es gibt einen Hauptartikel für die Kategorie, aber er hat einen anderen Titel. Dies ist der kritische Fall, der unten näher betrachtet wird. 3. Es wurde kein zu der Kategorie passender Artikel gefunden. In diesem Fall wird während der Nachbereitung im Schritt finishMissingConcepts ein „leeres“ Konzept vom Typ ConceptType.UNKNOWN für die Kategorie erstellt. Die einzige Information, die über dieses 9. Verarbeitung 60 Konzept bekannt ist, ist seine Position in dem durch die Subsumtionsrelation beschriebenen Unterordnungsgraphen. Das ist besonders für Navigationskategorien der Fall, kann aber auch dann auftreten, wenn die Heuristik zur Bestimmung eines passenden Artikels fehlschlägt oder ein solcher Artikel einfach fehlt. Der kritische Fall ist nun der, dass es zwar einen Hauptartikel für die Kategorie gibt, der Titel dieses Artikels aber von dem Titel der Kategorie verschieden ist. Besonders häufig kommt dies in Projekten vor, die per Konvention für Kategorien den Plural verwenden, während für Artikel der Singular benutzt wird — das ist zum Beispiel in der englischsprachigen Wikipedia der Fall. Ansonsten tritt dieses Problem oft dann auf, wenn der Titel des Hauptartikels einen Klammerzusatz trägt, die Kategorie aber nicht (die Seite mit dem entsprechenden Titel ohne Klammerzusatz im Hauptnamensraum ist dann in der Regel eine Begriffsklärungsseite). Es gilt nun einerseits, diesen Fall zu erkennen, also Artikel korrekt als Hauptartikel von Kategorien zu identifizieren und entsprechend zuzuordnen, und andererseits, die durch die Unterschiedlichkeit der Titel verursachte Inkonsistenz in den Relationen zu beseitigen: das bedeutet, den Titel der Kategorie als Alias für das Konzept des Hauptartikels zu behandeln. Die Heuristik, um Hauptartikel von Kategorien zu erkennen, basiert auf den zur Kategorisierung verwendeten Sort-Keys: Per Konvention ist der Hauptartikel einer Kategorie dieser direkt zugeordnet und zwar unter Verwendung eines speziellen Sort-Keys, der dafür sorgt, dass der Artikel in der Kategorie ganz vorne, vor allen anderen Seiten aufgeführt wird; konkret werden dafür einzelne Sonderzeichen verwendet, die in der Kollationsreihenfolge vor den alphanumerischen Zeichen stehen. Welche Sort-Keys als Markierung für Hauptartikel interpretiert werden, wird von WikiConfiguration.mainArtikeMarkerPattern festgelegt — per Default wird der reguläre Ausdruck ¬esc then 31: magic B LinkMagic.LANGUAGE; . setze magic auf LANGUAGE 32: end if 33: end if 34: end if 35: if ¬text then . Falls kein Link-Text angegeben wurde... 36: implied B true; . Merke, dass impliziter Link-Text verwendet wird 37: if magic = LinkMagic.Category then . Falls der Link Kategorisierungssemantik hat... 38: . setze den Link-Text (hier: Sortierschlüssel). . . 39: . auf den Namen der Seite, die den Link enthält 40: text B context; 41: else . sonst... 42: text B target; . setze den Link-Text auf das ursprünglich angegebene Link-Ziel 43: end if 44: end if 45: . Falls der Link keine Kategorisierungssemantik hat... 46: if tail [a-z]+(-[a-z]+)*$ verglichen — dieses Muster ist weit gefasst und kann dazu führen, dass einige Links fälschlich als Interwiki-Links klassifiziert werden. Allerdings sind Seitennamen, die einen Doppelpunkt nicht als Trennzeichen für den Namensraum, sondern im eigentlichen Namen haben, recht selten. WikiTextAnalyzer.isInterlanguagePrefix gibt true zurück, falls eine gegebene Zeichenkette ein Interlanguage-Präfix ist, das heißt also, ob es sich um einen bekannten Sprach-Code handelt. Die Sprach-Codes werden durch die Property-Datei E. Algorithmen 167 Languages.properties im Package de.brightbyte.wikiword definiert. Die dort aufgeführten Codes und Namen sind der entsprechenden Datei in MediaWiki entnommen, nämlich languages/Names.php. WikiTextAnalyzer.getNamespaceId gibt die numerische ID für einen gegebenen Namensraum zurück (oder Namespace.NONE, wenn kein solcher Namensraum bekannt ist). Die kanonischen Namensräume sind in der Property-Datei Namespaces.properties im Package de.brightbyte.wikiword definiert. Die für ein konkretes Wiki-Projekt gültigen Namensräume und Namensraumnamen werden dem Abschnitt <namespaces> des XML-Dumps entnommen [MW:XML]. WikiTextAnalyzer.normalizeTitle normalisiert einen Seitentitel: der erste Buchstabe wird in einen Großbuchstaben umgewandelt, und alle Leerzeichen durch Unterstriche (_) ersetzt. Die page-Eigenschaft des resultierenden WikiLink-Objekts wird dann mittels WikiTextAnalyzer.isBadLinkTarget geprüft — diese Methode benutzt das in WikiConfiguration.badLinkPattern festgelegte Muster, um fehlerhafte Links zu erkennen. Per Default werden vor allem solche Links ausgefiltert, deren Ziel (WikiTextAnalyzer.WikiLink.getPage()) „schlechte“ Zeichen enthält, wie z. B. „{“ oder „}“, „[“ oder „]“, „|“, usw. Auch Link-Ziele, die vor dem ersten Leerzeichen einen Doppelpunkt enthalten, der nicht von einem Leerzeichen gefolgt wird, werden als „schlecht“ betrachtet. Diese Regel fängt Links ab, die einen unbekannten Interwiki-Präfix oder einen Pseudo-Namensraum verwenden. Insbesondere werden so die sogenannten Shortcut-Redirects auf Projektseiten ausgefiltert, wie sie in vielen Wikipedias verwendet werden: WP:LK als Abkürzung für Wikipedia:Löschkandidaten, usw. Falls isBadLinkTarget also true liefert, wird der Link verworfen, ansonsten wird er der Liste hinzugefügt, die am Ende von extractLinks zurückgegeben wird. E.2. Extraktion von Glossen Per Konvention ist der erste Satz in einem Wikipedia-Artikel eine Definition des Konzeptes, das der Artikel beschreibt. Um also eine Glosse für dieses Konzept zu erhalten, kann einfach dieser erste Satz extrahiert werden. Um das zu erreichen, wird zunächst mit Hilfe von WikiTextAnalyzer. extractFirstParagraph der erste Absatz der Seite bestimmt. Dieser Absatz wird dann über das Muster LanguageConfiguration.sentencePattern in „Schnipsel“ (Chunks) zerlegt. Einem Puffer wird dann immer ein Schnipsel hinzugefügt, solange das Ende des Puffers auf das Muster in LanguageConfiguration.sentenceTailGluePattern passt (oder der Puffer leer ist), oder der Anfang des nächsten Schnipsels zu LanguageConfiguration. E. Algorithmen 168 sentenceFollowGluePattern passt. Der erste Satz gilt als gefunden, wenn keine der beiden Bedingungen mehr zutrifft, oder es keine weiteren Schnipsel gibt. In Pseudocode: 1: procedure EXTRACTFIRSTSENTENCE(text) 2: apply sentenceManglers to text; . Entferne unerwünschten Text 3: s = „“; . Starte mit leerem Satz 4: chunk = first chunk in text matching sentencePattern; . Finde ersten Schnipsel 5: while chunk do . Solang noch Schnipsel übrig sind. . . 6: s B append(s, chunk); . hänge Schnipsel an den Satz an 7: if next thing in text is a linebreak then . Ein Zeilenumbruch beendet den Satz 8: break; 9: end if 10: chunk = next chunk if text matching sentencePattern; . Finde nächsten Schnipsel 11: if s matches sentenceTailGlue then 12: continue; . Satzende verlangt nach Verlängerung 13: end if 14: if chunk matches sentenceFollowGlue then 15: continue; . Nächster Schnipsel verlangt nach Verlängerung 16: end if 17: break; . Sonst ist der Satz fertig. 18: end while 19: return return s; 20: end procedure Der obige Pseudocode verwendet die folgenden Konfigurationsvariablen: LanguageConfiguration.sentenceManglers dienen der Vorverarbeitung des Textes vor der Satzerkennung. Sie entfernen unerwünschte Elemente, per Default vor allem Textstücke in Klammern, die die Erkennung von Satzenden verkomplizieren würden. Geklammerte Teile des ersten Satzes enthalten meist etymologische Erläuterungen oder die Lebensdaten von Personen, also Informationen, die für eine Definition des Konzeptes nicht relevant sind. LanguageConfiguration.sentencePattern ist ein Muster zur vorläufigen Satzerkennung, also zur Zerlegung des Absatzes in „Schnipsel“. Es erkennt potentielle Satzenden, per Default Zeilenenden und Punkte dann, wenn auf sie ein Leerzeichen folgt. Andere Zeichen, die in freiem Text ein Satzende anzeigen können (also Ausrufungszeichen und Fragezeichen) kommen in der Wikipedia in dieser Funktion kaum vor und sollten vor allem niemals den einleitenden Definitionssatz abschließen — daher werden sie hier nicht beachtet. LanguageConfiguration.sentenceTailGlue definiert ein Muster, das „unechte“ Satzenden erkennt: falls das Ende des bisher gefundene Textes auf dieses Muster passt, so ist der Satz vermutlich noch nicht vollständig und es sollte ein weiterer „Schnipsel“ angehängt werden. Diese Muster enthält vor allem Abkürzungen, die mit einem Punkt enden, insbesondere solche, die auch häufig in Definitionssätzen vorkommen, wie z. B. Dr. („Doktor“) oder geb. („geboren“). LanguageConfiguration.sentenceFollowGlue definiert ein Muster, das Satzfortsetzungen findet: falls der Anfang des nächsten „Chunks“ auf dieses Muster passt, so sollte er an E. Algorithmen 169 den bereits gefundenen Text angehängt werden. Dieses Muster passt per Default auf alle Kleinbuchstaben, also Zeichen in der Unicode-Kategorie Ll [UNICODE (2007), S. 139]. Auf diese Weise kann recht zuverlässig der erste Satz im Fließtext eines Wikipedia-Artikels gefunden werden (.12.6). In einigen Fällen werden aber Satzgrenzen nicht erkannt, es werden also die ersten beiden Sätze zurückgegeben: das ist insbesondere dann der Fall, wenn der erste Satz mit einer Abkürzung endet, zum Beispiel mit „etc.“, was aber auf Grund der Natur des Definitionssatzes selten ist. E.3. Analyse von Begriffsklärungsseiten Bei der Analyse von Begriffsklärungsseiten ist das Ziel, von allen Wiki-Links auf der Seite diejenigen zu finden, die auf Bedeutungen des zu klärenden Begriffes verweisen. Das vorgeschlagene Verfahren ist darauf ausgerichtet, in einfachen Fällen mit geringem Aufwand schnell ein Resultat zu liefern, in „schwierigen“ Fällen aber dennoch präzise Ergebnisse zu erzielen. Sie arbeitet wie folgt: 1: procedure EXTRACTDISAMBIGLINKS(title, text) . Finde alle Links zu Bedeutungen 2: links B ;; 3: if disambigS tripS ectionPattern then . Falls ein bestimmter Abschnitt ignoriert werden soll. . . 4: text =stripSections(text, disambigS tripS ection); . . . . entferne ihn. 5: end if 6: name B determineBaseName(title); . Bestimme den zu klärenden Term 7: for line matching disambigLinePattern do . Für alle relevanten Zeilen. . . 8: link =determineDisambigTarget(name, line); . . . . finde den richtigen Link in der Zeile 9: if link then . Falls ein solcher Link gefunden wurde. . . 10: add link to links; . . . . füge ihn zu der Ergebnisliste hinzu 11: end if 12: end for 13: end procedure 14: procedure DETERMINEDISAMBIGTARGET(term, line) . Finde den Bedeutungslink in einer Zeile 15: for pattern in disambigLinkPatterns do . Für alle speziellen Link-Muster. . . 16: if line matches pattern then . . . . prüfe ob das Muster passt 17: return a link constructed from the match; . Falls ja, gib den entsprechenden Link zurück 18: end if 19: end for 20: . Weiter, falls mittels disambigLinkPatterns kein Link gefunden wurde. 21: links B extractLinks(term, line); . Extrahiere alle Links aus der Zeile 22: if size(links) = 0 then . Falls es keine Links in der Zeile gibt. . . 23: return null; . . . . gib null zurück 24: else if size(links) = 1 then . Falls es nur genau einen Link in der Zeile gibt. . . 25: return links[0]; . . . . gib diesen zurück 26: end if 27: . Alle Links, die „irgendwo“ den Term enthalten 28: links2 B {link 2 links|S ubS tringLinkFilter.matches(name, link)}; 29: if size(links2) > 0 then . Falls es solche Links gibt. . . 30: if size(links2) = 1 then . falls es genau einen solchen Link gibt. . . 31: return links2[0]; . . . . gib diesen zurück. . . 32: end iflinks B links2; . ansonsten betrachte im weiteren nur noch die gefilterte Liste E. Algorithmen 170 33: end if 34: . Falls es keine solchen Links gab, wird weiter die ungefilterte Liste von Links verwendet 35: for link 2 links do . Für jeden Link. . . 36: . . . . berechne, wie gut er zu dem Term passt 37: match[link] B DefaultLinkSimilarityMeasure.measure(term, link); 38: end for 39: best B link 2 links|bestmatch[link]; . Link, der am besten zu dem Term passt 40: . Wenn selbst beste Ähnlichkeit zu gering. . . 41: if match[best] < minDisambigLinkS imilarity then 42: return null; . . . . dann gib null zurück 43: end if 44: return best; 45: end procedure Der oben beschriebene Algorithmus verwendet die folgenden Funktionen und Konfigurationsparameter: WikiConfiguration.disambigStripSectionPattern ist ein Muster für die Namen von Abschnitten, die bei der Verarbeitung von Begriffsklärungsseiten ignoriert werden sollen. Insbesondere sind das Abschnitte für Querverweise, also z. B. für die deutschsprachige Wikipedia Siehe auch und für die englischsprachige See also. Gegebenenfalls wird die Methode WikiTextAnalyzer.stripSections verwendet, um jeden Abschnitt zu entfernen, auf den dieses Muster passt. WikiTextAnalyzer.determineBaseName gibt, wie bereits oben (in .8.9) beschrieben, den Titel ohne Klammerzusatz zurück. Im Fall einer Begriffsklärungsseite ist das der zu klärende, mehrdeutige Term. WikiConfiguration.disambigLinePattern ist ein Muster für solche Zeilen auf einer Begriffsklärungsseite, die typischerweise Links auf Bedeutungen des zu klärenden Terms haben. Per Konvention werden Bedeutungen in Listen aufgezählt, per Default werden also Zeilen betrachtet, die mit „*“ oder „#“ beginnen — allerdings sollten Zeilen ignoriert werden, die mit einem Doppelpunkt enden, da diese in der Regel keine Bedeutung auflisten, sondern einen Abschnitt in der Bedeutungsliste bezeichnen. Der reguläre Ausdruck für Disambiguierungszeilen ist per Default (y, x) 2 langre f }; 5: repeat . das Zusammenführen ist in „Runden“ aufgeteilt 6: replace B findMergeCandidates(concepts, similar); 7: . Neue, vereinigte Konzepte wurden hinzugefügt, die alten wurden aber noch erhalten 8: . replace enthält nun Paare von Konzept-IDs, die als Abbildung von den IDs der alten 9: . auf die IDs der neuen, vereinigten Konzepte dient. Die neuen, vereinigten Konzepte 10: . wurden in concepts aufgenommen. 11: performMerge(replace, similar); . Vereinigte Konzepte in allen Relationen ersetzen 12: until replace = ; 13: end procedure 14: procedure FINDMERGECANDIDATES(concepts, similar) . Finde zu vereinigende Konzepte 15: stop B ;; . Stoppliste von bereits verarbeiteten Konzepten 16: replace B ;; . Liste von ausstehenden Ersetzungen 17: for x 2 concepts do 18: if x 2 stop then . während dieser Runde bereits verarbeitet 19: continue; 20: end if 21: stop.add(x); . als verarbeitet markieren 22: sim B {y 2 concepts | (x, y) 2 similar}; . Ähnliche Konzepte 23: for y 2 concepts do 24: if y 2 stop then . während dieser Runde bereits verarbeitet 25: continue; 26: end if 27: stop.add(y); . als verarbeitet markieren 28: if (x.language_bits&y.language_bits) > 0) then . Konflikt, Vereinigen nicht möglich; 29: similar.remove( (x, y) ); 30: continue; 31: end if 32: m B createMergedConcept(x, y); . vereinigtes Konzept erzeugen 33: concepts.add(m); . vereinigtes Konzept hinzufügen 34: replace.add( (x,m) ); . zur Ersetzung vormerken 35: merge.add( (y,m) ); . zur Ersetzung vormerken 36: end for 37: end for 38: return replace; 39: end procedure 40: procedure PERFORMMERGE(replace, similar) . Ersetzt Referenzen von alten Konzepten 41: Ersetze alle Vorkommen der alten einzelnen Konzepte in replace durch die neuen, 42: vereinigten, in allen Relationen inklusive similar. 43: Auch die Tabellen origin und relation werden entsprechend angepasst. 44: Nach der Ersetzung, lösche die entstandenen Schleifen aus allen Relationen. 45: Lösche nun die alten Konzepte. 46: end procedure 47: procedure CREATEMERGEDCONCEPT(x, y) . Erzeuge kombiniertes Konzept 48: z B new Concept(); . Erzeuge neues Konzeptobjekt 49: z.name B x.name + „|i + y.name; . Konkatenation der beiden Namen 50: z.language_bits B x.language_bits|y.language_bits; . Bit-OR der Language-Bits 51: if x.type = UNKNOWN _ x.type = OTHER then . Wenn x keinen spezifischen Typ hat. . . 52: z.type B y.type; . . . . dann verwendet den Typ von y 53: else if y.type = UNKNOWN _ y.type = OTHER then . Wenn y keinen spezifischen Typ hat. . . 54: z.type B x.type; . . . . dann verwendet den Typ von x 55: else y.ltype = UNKNOWN _ y.type = OTHER . Wenn beide einen spezifischen Typ haben. . . E. Algorithmen 174 56: if x.type , y.type then . Wenn zwei Konzepte vereinigt werden, die unterschiedliche, spezifische . Konzepttypen haben, ist das ein Hinweis auf einen Fehler. 57: log type conflict. 58: end if 59: z.type B x.type; . . . . Verwendet den Typ von x 60: end if 61: return z; 62: end procedure Das Zusammenführen findet also in „Runden“ statt: In jeder Runde werden zunächst alle Konzepte durchlaufen und für jedes nach einem „Partner“ zum Zusammenführen gesucht. Dann werden alle solchen Paare von Partnern zu neuen Konzepten zusammengeführt und sämtliche Referenzen auf die alten Konzepte durch eine Referenz auf das neue, kombinierte Konzept ersetzt. Wird in einer Runde kein zu vereinigendes Paar mehr gefunden, terminiert der Algorithmus. Dabei ist zu beachten, dass jedes der globalen Konzepte immer eine Menge von sprachspezifischen Konzepten ist, wobei die Größe dieser Menge durch die Anzahl der betrachteten Sprachen begrenzt ist, da ja aus jeder Sprache höchstens ein lokales Konzept zu einem globalen Konzept gehören kann. Andererseits wächst die Größe dieser Mengen bei jeder Runde an: in der ersten Zusammenführungsrunde entstehen Gruppen der Größe zwei, in der zweiten Zusammenführungsrunde entstehen Gruppen der Größe von mindestens drei bis höchstens vier, in der dritten Runde zwischen mindestens vier bis höchstens acht, und so weiter. Damit ist klar, dass die Anzahl der betrachteten Sprachen auch die Anzahl der maximal notwendigen Vereinigungsrunden begrenzt. Auch die Anzahl der maximal zu betrachtenden Partner für jedes Konzept ist durch die Anzahl der Sprachen beschränkt, da die Partner ja durch gegenseitige Verknüpfung über Language- Links bestimmt werden, pro Sprache und Artikel aber nur ein Language-Link zulässig ist. Ist nun k die Anzahl der Sprachen und n die Anzahl der Konzepte, so ist die Laufzeit des Vereinigungsalgorithmus beschränkt durch O(k · n) — beachtet man den Aufwand der Lookups für die verschiedenen Mengen, ergibt sich O(k · n · log(n)). E. Algorithmen 175 E.5. Algorithmus zum schnellen Entfernen aller Zyklen aus einem gerichteten Graphen Die Kategoriestruktur der Wikipedia ist per Konvention als (gerichteter) azyklischer Graph angelegt. In der Praxis kommen durchaus Zyklen vor, die gefunden und entfernt werden müssen, um eine Thesaurus-Relation der Über- bzw. Unterordnung zu erhalten, die den Kriterien für eine Halbordnung genügt. Hier wird nun ein Algorithmus vorgestellt, der diese Aufgabe auf einem Graphen mit potentiell mehreren Millionen Knoten effizient bewältigen kann. Die Grundidee ist, alle möglichen Pfade durch den Graphen zu durchlaufen und dabei auf Zyklen zu untersuchen: Ausgehend von allen „Wurzeln“ (Knoten ohne eingehende Kanten) wird mittels Tiefensuche jeder Knoten besucht; liegt der nächste Knoten bereits auf dem aktuellen Pfad, so ist ein „Backlink“, und damit ein Zyklus gefunden. Zu beachten ist, dass jeder Knoten nur einmal besucht werden muss: ist ein Knoten einmal abgearbeitet (und damit auch alle von diesem Knoten aus erreichbaren Knoten), so ist der Knoten nicht (mehr) Teil eines Zyklus, und es ist auch kein Zyklus (mehr) von ihm aus erreichbar. Wird der Knoten also später beim Durchlaufen eines anderen Pfades noch einmal gefunden, muss er nicht mehr bearbeitet werden: Die Tiefensuche beschränkt sich damit auf einen Spanning Tree des Graphen. Damit liegt der Aufwand des Algorithmus bei O(n), wobei n die Anzahl der Knoten ist. Zunächst wird der Graph so normiert, dass es nur noch eine einzige „Wurzel“ (Knoten ohne eingehende Kanten) gibt: Es wird ein neuer Knoten als „Elternknoten“ aller bisherigen Wurzeln eingefügt; Hat der Graph bislang gar keine Wurzel, so wird ein beliebiger Knoten aus jedem separaten Teilbaum als Kind des künstlichen Wurzelknotens bestimmt. Ausgehend von dieser Wurzel wird nun eine Tiefensuche durchgeführt, wobei der Pfad von der Wurzel zum aktuellen Knoten mitgeführt wird. Bei jedem Schritt wird zunächst geprüft, ob der aktuelle Knoten bereits in der Menge der bereits verarbeiteten Knoten ist:Wenn nicht, so wird der Knoten dieser Menge hinzugefügt und dann die Tiefensuche rekursiv fortgesetzt.Wenn der Knoten aber bereits vorher einmal bearbeitet wurde, so wird geprüft, ob er auch Teil des aktuellen Pfades ist, ob also ein „Backlink“ gefunden wurde. Wenn das so ist, so wird diese Kante entfernt. In jedem Fall aber wird die rekursive Suche abgebrochen, wenn der Knoten schon einmal bearbeitet worden ist. Der aktuelle Pfad, der von der Wurzel aus durch den Graph genommen wurde, wird bei der Tiefensuche mitgeführt. Ist nun der für den nächsten Schritt vorgesehene Knoten bereits in dem Pfad zu diesem Knoten enthalten, so ist ein „Backlink“, und damit ein Zyklus, gefunden. Um den Zyklus zu beheben, wird nun einfach der soeben gefundene „Backlink“ entfernt—auf dieseWeise entstehen keine Inseln, alle Knoten auf dem Pfad bleiben weiter von der Wurzel aus erreichbar. In der Praxis hat sich gezeigt, dass es sich lohnt, den Graphen vor der Anwendung dieses Algorithmus zunächst so zu reduzieren, dass er keine „losen Enden“ mehr hat. Die Idee ist, dass ein „Blatt“ (ein Knoten ohne ausgehende Kanten) auf der Suche nach Zyklen nicht zu betrachtet werden braucht. Solche Knoten können also sofort entfernt werden — und zwar wiederholt, solange, bis keine „Blätter“ mehr vorhanden sind und jeder verbleibende „Ast“ des Graphen durch einen Zyklus abgeschlossen wird. E. Algorithmen 176 Algorithm 1 Beseitigen von Zyklen 1: G = (V, E); . Ein Graph mit Knoten V und Kanten E 2: X = ;; . Die Menge von schon bearbeiteten Knoten 3: P = (); . Liste, die den aktuellen Pfad speichert 4: r = makeRoot(G); . Künstliche Wurzel einfügen 5: decycle(E, X, P, r); 6: procedure DECYCLE(E, X, P, n) 7: if n 2 X then . Schon einmal bearbeitet 8: if n 2 P then . Liegt auf dem Pfad 9: E.remove(P.last, n); . Zyklus gefunden! 10: end if 11: else 12: X B X [ n; . Als bearbeitet markieren 13: P.append(n); . Knoten an Pfad anhängen 14: for m 2 m : (n,m) 2 E do . Für alle Kinder 15: decycle(E, X, P,m); . Rekursiv aufrufen 16: end for 17: P.remove(n); . Knoten von Pfad entfernen 18: end if 19: end procedure Algorithm 2 Reduktion des Graphen 1: procedure PRUNE(G = (V, E)) . Ein Graph mit Knoten V und Kanten E 2: while 9v 2 V : @(v,w) 2 E do . Solange es blätter gibt 3: for v 2 V : @(v,w) 2 E do . Für jedes Blatt. . . 4: G.remove(v); . Entferne es 5: end for 6: end while 7: end procedure E. Algorithmen 177 Realisieren lässt sich dieser Ansatz wie folgt: Solange es Blätter im Graphen gibt, wird die Menge aller Blätter durchlaufen, und jedes Blatt entfernt (Alg. 2). Die äußere Schleife ist notwendig, da ja durch das Entfernen eines Blattes neue Blätter entstehen können. Der Aufwand der inneren Schleife liegt bei n Schritten; die Anzahl von Iterationen der äußeren Schleife ergibt sich aus der Länge des längsten Pfades von einerWurzel zu einem Blatt—im schlechtesten Fall also ebenfalls n, im Fall eines balancierten Baumes oder eines Small-World Graphen, wie der Kategorie-Struktur der Wikipedia [VOSS (2006), VOSS (2005B)], aber nur log(n). Beispiel 1 2 3 4 5 6 7 8 9 (a) Ausgangsdaten 1 2 3 4 6 7 9 (b) Reduzieren 1 2 3 4 6 7 (c) Weiter Abb. E.1: Reduzieren des Graphen Sei ein Graph mit neun Knoten, n1 – n9, gegeben; n1 ist der künstlich hinzugefügteWurzelknoten, er wurde über den „Proto-Wurzeln“ n2 und n3 eingehängt. Der Graph enthält zwei (sich überlappende) Zyklen: (n3, n7, n6) und (n3, n4, n7, n6). Zunächst soll der Graph reduziert werden: Im ersten Schritt werden nun alle Blätter markiert (n5 und n8, siehe Abb. E.1(a)) und entfernt. Im ersten Schritt werden wieder alle Blätter markiert (n9, Abb. E.1(b)) und entfernt. Nun gibt es keine Blätter mehr (Abb. E.1(c)) und der eigentliche Algorithmus zum finden von Zyklen wird gestartet. Ausgehend von der Wurzel n1 wird mittels Tiefensuche der Graph durchlaufen. Bei dem Schritt von n7 zu n6 wird erkannt, dass n7 bereits auf dem aktuellen Pfad (n1, n2, n6, n3, n7) liegt: somit ist ein Zyklus gefunden, der zu entfernende „Backlink“ ist die Kante (n7, n6) (Abb. E.2(a)). Die Tiefensuche wird dann fortgesetzt: der nächste interessante Schritt ist der von n4 nach n7: er wird nicht vollzogen, weil n7 als „schon bearbeitet“ markiert ist. Dasselbe gilt für den Schritt von n1 nach n3. Damit ist der Algorithmus beendet (Abb. E.2(b)): alle Zyklen sind beseitigt, die verwendeten Kanten bilden einen Spanning Tree über dem Graphen. Anwendung Das hier beschriebene Vorgehen ist also eine Tiefensuche in einem gerichteten Graph, während der Zyklen in diesem Graph gefunden und beseitigt werden. Die naive Tiefensuche wurde optimiert a) durch Beschränkung auf einen Spanning Tree und b) durch Reduktion des Graphen durch iteratives Entfernen aller Blätter. Der resultierende Algorithmus ist geeignet, Zyklen aus großen Graphen E. Algorithmen 178 1 2 3 6 7 4 (a) Zyklus gefunden 1 2 3 4 6 7 (b) Spanning Tree Abb. E.2: Entfernen von Zyklen effizient zu entfernen. Das wird im Rahmen dieser Arbeit dazu verwendet, unerwünschte zyklische Verknüpfungen aus der Kategoriestruktur der Wikipedia zu entfernen, um zu einer Halbordnung von über- bzw. untergeordneten Konzepten zu gelangen. Eine Implementation dieses Algorithmus befindet sich in der Klasse CycleFinder im Package de.brightbyte.wikiword.store.builder und wird in der Methode deleteBroaderCycles in der Klasse DatabaseWikiWordConceptStoreBuilder in demselben Package verwendet. Im Experiment ergab sich eine Laufzeit von unter 30 Sekunden für einen Graph mit 65 000 Knoten und 2 Millionen Kanten, wobei etwa 500 Zyklen gefunden wurden1. 1Angaben für die Anwendung auf die deutschsprachige Wikipedia F. Daten F.1. Wiki-Dumps Wikipedia-Dumps Wikipedia-Dumps [MW:XML], die die Grundlage für die Experimente in .IV bilden, stehen auf den Servern der Wikimedia Foundation zur Verfügung [WM:DOWNLOAD]: • Der Dump der aktuellen Artikelversionen der englischsprachigen Wikipedia (en) vom 3. Januar 2008, <http://download.wikimedia.org/enwiki/20080103/ enwiki-20080103-pages-articles.xml.bz2> (3,2 GB komprimiert, MD5: c04f8a1474a88ddfa3c6965fc5169208). • Der Dump der aktuellen Artikelversionen der deutschsprachigen Wikipedia (de) vom 20. März 2008, <http://download.wikimedia.org/dewiki/20080320/ dewiki-20080320-pages-articles.xml.bz2> (1,1 GB komprimiert, MD5: 28f939fee350eac9c7a98c820fe0140e). • Der Dump der aktuellen Artikelversionen der französischsprachigen Wikipedia (fr) vom 23. März 2008, <http://download.wikimedia.org/frwiki/20080323/ frwiki-20080323-pages-articles.xml.bz2> (783,5 MB komprimiert, MD5: 7776cfdd7f237f8522a6606110f155c9). • Der Dump der aktuellen Artikelversionen der niederländischsprachigen Wikipedia (nl) vom 10. März 2008, <http://download.wikimedia.org/nlwiki/20080310/ nlwiki-20080310-pages-articles.xml.bz2> (315,0 MB komprimiert, MD5: 2e7e2fb9a3e2d77a68b32d4dc895c9d8). • Der Dump der aktuellen Artikelversionen der norwegischsprachigen Wikipedia (no) vom 11. März 2008, <http://download.wikimedia.org/nowiki/20080311/ nowiki-20080311-pages-articles.xml.bz2> (120,9 MB komprimiert, MD5: f61d04b1505ba97f4f0ee2bc9484105a). • Der Dump der aktuellen Artikelversionen der Wikipedia in einfachem Englisch (simple) vom 16. März 2008, <http://download.wikimedia.org/simplewiki/20080316/ simplewiki-20080316-pages-articles.xml.bz2> (22,3 MB komprimiert, MD5: 9f78f72ffc00b73d817df240806fa806). • Der Dump der aktuellen Artikelversionen der plattdeutschen Wikipedia (nds) vom 19. März 2008, <http://download.wikimedia.org/ndswiki/20080319/ ndswiki-20080319-pages-articles.xml.bz2> (7,2 MB komprimiert, MD5: 3c3b30ec70c66a8d9bcee1df75bc9427). Die Inhalte der Dumps stehen unter der GNU Free Documentation License [GFDL], die Liste der jeweiligen Autoren kann den betreffenden Wikipedia-Seiten entnommen werden. F. Daten 180 Thematische Auszüge aus der Wikipedia Als übersichtliche Datenbasis für Experimente wurden fünf thematische Auszüge aus jeweils vier bis sechs Wikipedias erstellt. Ziel war es, die Themen so zu wählen, dass die Abdeckung in den einzelnen Wikipedias in etwa vergleichbar ist. Unter /wikidumps/ auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/wikidumps/> sind Dumps für die folgenden Themen abgelegt: animals: Seiten zum Thema Haustier (bzw. Nutztier). Die englischsprachige Wikipedia fehlt hier, da die entsprechende Kategorie nicht hinreichend abgegrenzt ist. Die norwegischsprachige fehlt ebenfalls, da dort keine entsprechende Kategorie existiert. color: Seiten zum Thema Farbe. Bei diesem Thema ist die Korrelation der Artikel recht gut, die in den verschiedenen Wikipedias behandelten Konzepte entsprechen einander weitgehend. logic: Seiten zum Thema Logik. Welche Konzepte zum Thema Logik gehören, differiert stark zwischen den Projekten. mountains: Seiten zum Thema Berge. Hier zeigt sich ein starker geografischer Bias: es werden vor allem Berge behandelt, die sich im Sprachgebiet der betreffenden Wikipedia befinden. popes: Seiten zum Thema Päpste. Ähnlich wie bei Farben ergibt sich hier eine gute Abgrenzung und starke Korrelation zwischen den Wikis. Wie bereits oben erwähnt stehen die aus der Wikipedia stammenden Inhalt unter der GNU Free Documentation License [GFDL]. F.2. Datenbank-Dumps SQL-Dumps von Thesauri für thematische Auszüge Für die Thesauri, die aus den oben genannten thematischen Auszügen (.F.1) erzeugt wurden, stehen unter /sqldumps/ auf der beiliegenden CD oder online unter <http://brightbyte. de/DA/sqldumps/> SQL-Dumps zur Verfügung: animals: wikiword-animals.sql.bz2, 9.4MB color: wikiword-color.sql.bz2, 4.4MB logic: wikiword-logic.sql.bz2, 19.7MB mountains: wikiword-mountains.sql.bz2, 58.2MB popes: wikiword-popes.sql.bz2, 7.9MB Die Konventionen für die Tabellennamen sowie die Struktur der einzelnen Tabellen sind in .C beschrieben. F. Daten 181 SQL-Dumps für die aus der Wikipedia erstellten Thesauri Dieselben Daten stehen noch einmal unter <http://aspra27.informatik.uni-leipzig.de/ ~dkinzler/sqldumps/> zur Verfügung, dort ist jedoch auch die Datei wikiword-full.sql. bz2 enthalten: sie ist 11GB groß und enthält die Thesaurus-Daten, die aus den Wikipedias gewonnen wurden. Alle Thesaurusdaten stehen berechtigten Benutzern auch in der Datenbank dkinzlerdb auf aspra5.informatik.uni-leipzig.de zur Verfügung. Die Konventionen für die Tabellennamen sowie die Struktur der einzelnen Tabellen sind in .C beschrieben. In der Datenbank befinden sich zum Beispiel die folgenden Tabellen: full_de_* sind die Tabellen, die den monolingualen Thesaurus enthalten, der aus der deutschsprachigen Wikipedia extrahiert wurde (Datensatz de in der Kollektion full). Die Tabelle full_de_meaning zum Beispiel enthält die Bedeutungsrelation dieses Thesaurus, sie assoziiert Konzepte mit ihren Bezeichnungen. full_en_* sind die Tabellen, die den monolingualen Thesaurus enthalten, der aus der englischsprachigen Wikipedia extrahiert wurde (Datensatz en in der Kollektion full). Die Tabelle full_en_broader zum Beispiel enthält die Subsumtionsrelation dieses Thesaurus, sie setzt allgemeinere mit spezielleren Konzepten in Beziehung. full_thesaurus_* sind die Tabellen, die den multilingualen Thesaurus enthalten, der aus allen monolingualen Thesauri in der Kollektion erstellt wurde (Datensatz thesaurus in der Kollektion full). Die Tabelle full_thesaurus_relation zum Beispiel enthält verschiedene assoziative Beziehungen zwischen Konzepten, zum Beispiel Ähnlichkeit (in den Feldern langmatch und langref) sowie Verwandtheit (im Feld bilink). full_top3_* sind die Tabellen, die den multilingualen Thesaurus enthalten, der aus den Thesauri en, de und fr erstellt wurde (Datensatz top3 in der Kollektion full). Die Tabelle full_top3_degree zum Beispiel enthält verschiedene Scores und Rangangaben, insbesondere in Bezug auf Knotengrade. Hinweis: Diese Daten werden zum Zweck der Begutachtung der Diplomarbeit vorübergehend bereitgestellt. Sie sind unter Umständen nicht von ausserhalb der Universität Leipzig und/oder nicht für längere Zeit zugänglich. F.3. RDF-Dumps Die Thesauri, die zur Erprobung vonWikiWord und für die in .IV beschriebene Evaluation erzeugt wurden, stehen auch als RDF-Dateien zur Verfügung. Die Repräsentation der Thesauri als RDF ist in .10 beschrieben, die Dateien sind im Turtle-Format [BACKETT (2007)] serialisiert und mit BZip2 komprimiert. Die Dateinamen geben wieder, mit welchen Optionen für ExportRdf die Dumps erzeugt wurden: Dateien mit der Endung ww.n3.bz2 wurden mit der Default-Einstellung, also unter Verwendung F. Daten 182 des WikiWord-Vokabulars und ohne Cutoff, erzeugt. ww2.n3.bz2 verwendet einen Cutoff-Wert von 2, skos.n3.bz2 wurde ohne Cutoff erzeugt und verwendet nur das SKOS-Vokabular. Das RDF-Schema [W3C:RDFS (2000)] für das WikiWord-Vokabular mit der URI <http:// brightbyte.de/vocab/wikiword> ist unter /WikiWord/WikiWord/src/main/wikiword. rdf auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/WikiWord/ WikiWord/src/main/wikiword.rdf> verfügbar. RDF-Dumps von Thesauri für thematische Auszüge Für die Thesauri, die aus den oben genannten thematischen Auszügen (.F.1) erzeugt wurden, stehen unter /rdfdumps/ auf der beiliegenden CD oder online unter <http://brightbyte. de/DA/rdfdumps/> RDF-Dumps zur Verfügung. RDF-Dumps für aus der Wikipedia erstellten Thesauri Dieselben Daten stehen noch einmal unter <http://aspra27.informatik.uni-leipzig.de/ ~dkinzler/rdfdumps/> zur Verfügung, dort sind jedoch auch die RDF-Dateien für die Thesauri enthalten, die aus denWikipedias gewonnen wurden. Die Dateinamen dieser Dumps beginnen mit full_, gefolgt vom Namen des Korpus bzw. Thesaurus: • Monolinguale Thesauri: full_en_, full_de_, full_fr_, full_nl_, full_no_, full_ nds_ und full_simple_ sind die Präfixe für die Thesauri, die direkt aus den entsprechenden Wikipedias erstellt wurden. • Multilinguale Thesauri: full_thesaurus_ ist der Präfix für den Thesaurus, der aus allen oben genannten lokalen Thesauri erstellt wurde; full_top3_ ist der Präfix für den Thesaurus aus den drei größtenWikipedias (en, de, fr) und full_top5_ für den Thesaurus aus den fünf „reifen“Wikipedias aus der obigen Liste(en, de, fr, nl, no). Die RDF-Dumps der multilingualen Thesauri sind jeweils zwischen 900 und 1 300 Megabyte groß. Hinweis: Diese Daten werden zum Zweck der Begutachtung der Diplomarbeit vorübergehend bereitgestellt. Sie sind unter Umständen nicht von ausserhalb der Universität Leipzig und/oder nicht für längere Zeit zugänglich. Beispiele für RDF-Daten Ein Beispiel für die Darstellung eines Konzeptes, nämlich KARPFEN, mit Hilfe von RDF/SKOS und dem WikiWord-Vokabular: @base <h t t p : / / b r i g h t b y t e . de / vocab / wikiword / c o n c e p t / from / h t t p : / / de . wi k i p e d i a . org / wi ki /> . @pr e f ix : <h t t p : / / b r i g h t b y t e . de / vocab / wikiword / c o n c e p t / from / h t t p : / / de . wi k i p e d i a . org / wi ki /> . @pr e f ix d ewi k i : <h t t p : / / de . wi k i p e d i a . org / wi ki /> . @pr e f ix sk os : <h t t p : / /www.w3 . org / 2 0 0 4 / 0 2 / sk os / c o r e #> . F. Daten 183 @pr e f ix ww: <h t t p : / / b r i g h t b y t e . de / vocab / wikiword #> . @pr e f ix wwct : <h t t p : / / b r i g h t b y t e . de / vocab / wikiword / conc ept -type #> . : Ka rpf en r d f : type sk os : Concept ; sk os : a l t L a b e l " Cy p r i n u s  c a r p i o "@de ; sk os : a l t L a b e l " Ka rpf en "@de ; sk os : a l t L a b e l " Ka r p f e n s "@de ; sk os : a l t L a b e l " Le d e r k a r p f e n "@de ; sk os : a l t L a b e l " Na c k t k a r p f e n "@de ; sk os : a l t L a b e l " Sc h u p p e n k a r p f e n "@de ; sk os : a l t L a b e l " S p i e g e l k a r p f e n "@de ; sk os : a l t L a b e l "Wi l d k a r p f e n "@de ; sk os : a l t L a b e l " Z e i l k a r p f e n "@de ; sk os : d e f i n i t i o n "Der Ka rpf en  i s t  e i n e  F i s c h a r t  aus  d e r  F ami l i e  d e r  Ka r p f e n f i s c h e . "@de ; sk os : d e f i n i t i o n d ewi k i : Ka rpf en ; sk os : inScheme <h t t p : / / b r i g h t b y t e . de / vocab / wikiword / d a t a s e t / * / a n ima l s : de> ; sk os : b r o a d e r : Ha u s t i e r ; sk os : b r o a d e r : Ka r p f e n a r t i g e ; sk os : b r o a d e r : S p e i s e f i s c h _ u n d _Me e r e s f r u c h t ; ww: d i s p l a y L a b e l " Ka rpf en "@de ; ww: idfRank 16210 ; ww: i d f S c o r e 7.77359446736019 ; ww: i nDe g r e e 8 . 0 ; ww: inRank 772 ; ww: lhsRank 16204 ; ww: l h s S c o r e 0.293862558415189 ; ww: l i n kDe g r e e 7 7 . 0 ; ww: l i n kRa n k 111 ; ww: outDegr e e 6 9 . 0 ; ww: outRank 82 ; ww: s imi l a r : Koi ; ww: type wwct :LIFEFORM . F.4. Bewertungsdaten und Statistiken Zur Evaluation von WikiWord wurden verschiedene Stichproben (Batches) gewählt und dann einzelne Eigenschaften und Aspekte der Elemente in den Stichproben manuell bewertet. Diese Bewertungen wurden für die statistische Auswertung in Survey-Tabellen gespeichert. Diese stehen in /sqldumps/ auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/ sqldumps/> als Tab-separierte Liste (TSV) mit Namen der Form *_survey.tsv zur Verfügung. Die einzelnen Stichproben und Bewertungen sind im Folgenden beschrieben. Alle Survey-Tabellen haben die folgenden Felder: timestamp: Zeitpunkt, zu dem die Bewertung vorgenommen wurde. batch: Name der Stichprobe oder des Satzes von Bewertungen. seq: Sequenznummer der Bewertung innerhalb des Satzes. property: Bewertete Eigenschaft. value: Bewerteter Wert, wie von WikiWord vorgegeben. F. Daten 184 assessment: Bewertung. Die möglichen Werte sind je nach bewerteter Eigenschaft unterschiedlich. Die einzelnen Survey-Tabellen können zusätzliche Felder haben, die die Einträge in der Bewertungstabelle mit Einträgen in der Datenstruktur von WikiWord verbinden. Bewertung der Konzepteigenschaften: concept_survey Die Tabelle concept_survey dient der Erhebung von Bewertungen von Konzepteigenschaften, wie sie in .12 besprochen wurden. Sie hat die folgenden zusätzlichen Felder: concept: Die ID des bewerteten Konzeptes, als Verweis in die Tabelle concept (.C.2). concept_name: Der Name des bewerteten Konzeptes, als Verweis in die Tabelle concept. In dieser Tabelle befinden sich für lokale Datensätze Bewertungen für die folgenden Eigenschaften: terms: Bewertung der Termzuordnung, wie in .12.5 besprochen. Die möglichen Bewertungen sind dort aufgezählt. type: Bewertung der Termzuordnung, wie in .12.1 besprochen. Die möglichen Bewertungen sind dort aufgezählt. gloss: Bewertung der Termzuordnung, wie in .12.6 besprochen. Die möglichen Bewertungen sind dort aufgezählt. broader und narrower: Bewertung der Termzuordnung, wie in .12.2 besprochen. Die möglichen Bewertungen sind dort aufgezählt. related und similar: Bewertung der Termzuordnung, wie in .12.4 und .12.3 besprochen. Die möglichen Bewertungen sind dort aufgezählt. Konkret sind diese Informationen in den Dateien full_de_concept_survey.tsv (für den deutschsprachigen Thesaurus) und full_en_concept_survey.tsv (für den englischsprachigen Thesaurus) enthalten, die unter der oben genannten URL verfügbar sind. Für globale Datensätze dagegen wird nur eine Eigenschaft von Konzepten bewertet: merging: Bewertung der Konzeptzusammenfassung, wie in .11.3 besprochen. Die möglichen Bewertungen sind: OPTIMAL: Bestmögliche Kombination von sprachspezifischen Konzepten. FUZZY: Bestmögliche Kombination von sprachspezifischen Konzepten, enthält aber Konzepte, die nur „fast“ zu den anderen passen. F. Daten 185 LONE: Das globale Konzept besteht nur aus einem einzigen lokalen Konzept, und es gibt auch keine Kandidaten für eine Vereinigung (also keine ähnlichen Konzepte). LACKING: Die Kombination von sprachspezifischen Konzepten ist korrekt, es wurden aber ähnliche Konzepte übergangen, die mit aufgenommen werden sollten. BAD: Die Menge von sprachspezifischen Konzepten enthält mindestens ein Konzept, das falsch zugeordnet wurde und nicht zu den anderen passt. Konkret sind diese Informationen in der Datei full_thesaurus_concept_survey.tsv enthalten, die unter der oben genannten URL verfügbar ist. Bewertung der Analyse von Begriffsklärungsseiten: resource_survey Die Tabelle concept_survey dient der Erhebung von Bewertungen von Ressourceneigenschaften, wie sie in .13 besprochen wurden. Sie hat das folgende zusätzliche Feld: resource_name: Der Name der bewerteten Wiki-Seite, als Verweis in die Tabelle resource (.C.2). Für die Evaluation der Analyse von Begriffsklärungsseiten wurde die Eigenschaft link bewertet, die angibt, ob ein Wiki-Link auf der Begriffsklärungsseite auf eine der Bedeutungen der Begriffsklärung zeigt und ob dies korrekt erkannt wurde. Die möglichen Bewertungen sind in .13 definiert. Konkret sind diese Informationen in den Dateien full_de_resource_survey.tsv (für den deutschsprachigen Thesaurus) und full_en_resource_survey.tsv (für den englischsprachigen Thesaurus) enthalten, die unter /sqldumps/ auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/sqldumps/> verfügbar sind. Bewertung der automatischen Disambiguierung und Bestimmung der semantischen Verwandtheit Die Tabelle relatedness_survey dient der Bewertung von Bedeutungszuweisungen und Verwandtheitswerten, wie sie in .14 besprochen wurden. Sie hat die folgenden zusätzlichen Felder: term_a und term_b sind die beiden Terme, deren Verwandtheit bestimmt werden soll. concept_a und concept_b sind die Konzepte, die den beiden obigen Termen zugeordnet wurden, manuell oder automatisch. Darf auch NULL sein, falls ein Konzept nicht gefunden wurde. F. Daten 186 is_nn ist 1, falls beide Terme Substantive sind. Paare von Substantiven werden bei der Evaluation (auch) getrennt betrachtet. found ist 1, falls für beide Terme Konzepte gefunden wurden. relatedness ist einWert für die Verwandtheit der beiden Terme bzw. der beiden Konzepte, nach irgendeinem Bewertungsverfahren, auf irgendeiner Skala. score ist eine normierte Version des Werte im Feld relatedness: r0 B r-—r / r. Vom Originalwert wird also der Mittelwert abgezogen und das Ergebnis durch die Standardabweichung geteilt. So ergeben sich Werte, die unabhängig von der Bewertungsskala und einer eventuellen systematischen Verzerrung direkt verglichen werden können, zumindest bezüglich ihres Vorzeichens, das angibt, ob die Verwandtheit zweier Terme bzw. Konzepte für „überdurchschnittlich“ oder „unterdurchschnittlich“ befunden wurde. Die Evaluation des in .14.1 vorgestellten Verfahrens zur automatischen Disambiguierung und Bestimmung der semantischen Verwandtheit wurde auf der Basis eines Vergleichsdatensatzes durchgeführt, der von Zesch und Gurevych erstellt wurde: Der Datensatz ZG2221 [ZESCH UND GUREVYCH (2006)] enthält 222 Wortpaare, die von 24 Probanden in Hinblick auf ihre semantische Verwandtheit auf einer Skala von 0 bis 4 bewertet wurden. Die folgende Tabelle zeigt, was für Bewertungssätze (Batches) auf dieser Basis erstellt wurden: ZG222 enthält die Originaldaten aus [ZESCH UND GUREVYCH (2006)], lediglich das score-Feld wurde berechnet. Dieser Satz enthält keine Bedeutungszuweisung, concept_a und concept_b sind leer. ZG222-manual enthält manuelle Konzeptzuweisungen zu den Termen in ZG222, vorgenommen durch den Autor. Diese Zuweisungen sollten möglichst denen ähnlich sein, die von den Probanden bei der Erstellung von ZG222 implizit vorgenommen wurden. Ob dies gelungen ist, ist allerdings kaum zu prüfen. Dieser Umstand wurde in .14.1 noch näher betrachtet. ZG222-manual-concepts-* sind Datensätze, die die semantische Verwandtheit der manuell gewählten Konzepte enthalten, berechnet mit unterschiedlichen Parametern (siehe unten). ZG222-coherence-* sind Datensätze, in denen die Bedeutungszuweisung aufgrund einer Maximierung der Verwandtheit der Konzepte (Kohärenz), bestimmt unter Verwendung unterschiedlicher Parameter, durchgeführt wurde (siehe .14.2). ZG222-popularity-* sind Datensätze, in denen immer die meist verwendete Bedeutung für jeden Term verwendet wurde, und dann die Verwandtheit der Konzepte unter Verwendung unterschiedlicher Parameter bestimmt wurde. Die Parameter, die zur Bestimmung der semantischen Verwandtheit von Konzepten verwendet wurden, sind in den Namen der Datensätze wiedergegeben: 1Verfügbar unter <http://www.ukp.tu-darmstadt.de/data/semRelDatasets>. F. Daten 187
[+]

• cosine sind Datensätze mit Verwandtheitswerten, die unter Verwendung des Kosinus-Maßes

zum Vergleich der Featurevektoren der beiden Konzepte berechnet wurden.
[+]

• tanimoto sind Datensätze mit Verwandtheitswerten, die unter Verwendung einer gewichteten

Tanimoto-Ähnlichkeit (.14.1) zum Vergleich der Featurevektoren der beiden Konzepte berechnet wurden.
[+]

• weighted-* sind Datensätze, bei denen die Einträge in den Featurevektoren für die

Bestimmung der Verwandtheit nach IDF- bzw. LHS-Werten der Konzepte gewichtet wurden. Die Ergebnisse diese Verfahrens sind durchweg schlechter als die, die mit ungewichteten Featurevektoren erzielt wurden. Daher wurden diese Daten in .14.1 nicht weiter erwähnt.
[+]

• unweighted-* sind Datensätze, bei denen die Einträge in den Featurevektoren für die

Bestimmung der Verwandtheit ohne Gewichtung vorgenommen wurden. -pop=\textit{p}- sind Datensätze, bei denen bei der Bestimmung der Verwandtheit der Konzepte die Frequenz berücksichtigt wurde, mit der der betreffende Term für dieses Konzept verwendet wurde. p ist also der Popularitäts-Bias, wie in .14.2 beschrieben. Dateien mit verschiedenen Kombinationen dieser Eigenschaften stehen in /sqldumps/ auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/sqldumps/> zur Verfügung. F.5. Daten für Grafiken und Tabellen Die Daten, die für die Erstellung von Grafiken und Tabellen in dieser Arbeit (insbesondere im Evaluationsteil) verwendet wurden, stehen unter /WikiWord/WikiWordThesis/ Diplomarbeit/Daten/ auf der beiliegenden CD oder online unter <http://brightbyte. de/DA/WikiWord/WikiWordThesis/Diplomarbeit/Daten/> zur Verfügung. Die folgenden Datenformate wurden verwendet: R: Skriptdatei für GNU-R [GNU-R]. Solche Skripte werden verwendet, um eine Grafik im PDFFormat zu erzeugen, die im Allgemeinen bis auf die Dateiendung denselben Namen trägt. Als Datenbasis wird eine *.data-Datei verwendet. data: Tabellen im TSV-Format (Tab-Separated Values), also als Textdateien, wobei Zeilen der Tabelle als Textzeile in der Datei gespeichert sind und die einzelnen Werte durch Tabulatoren (ASCII-Code 0x09) getrennt sind. Texte sind in UTF-8 kodiert. tsv: Ebenfalls Tabellen im TSV-Format, wie oben beschrieben. Allerdings enthalten diese Dateien zum Teil kein „reines“ TSV: sie können TeX-Markup enthalten sowie Hinweise auf horizontale Trennlinien in der Form von Zeilen, die nur eine Folge von „– –“ enthalten. Solche Dateien werden mit Hilfe des Skriptes tsv2tex, das beim Rendern dieses Dokumentes automatisch angesprochen wird, in TeX-Dateien umgewandelt. G. Quellcode Dieses Kapitel bietet einen Überblick über den Quellcode von WikiWord. Es wird beschrieben, wie das Programm strukturiert ist, welche Bibliotheken verwendet werden, wo der Quelltext erhältlich ist sowie wie er verwendet werden kann. G.1. WikiWord Packages Dieser Abschnitt bietet eine kurze Übersicht über die Java-Packages, aus denenWikiWord besteht. Zunächst seien die Packages für den Kern von WikiWord genannt: de.brightbyte.wikiword definiert Klassen wie z. B. Corpus und Namespace, die WikiWords Kern-Konzepte modellieren, sowie Hilfsklassen wie CliApp (die Basis für die Kommandozeilenschnittstelle von WikiWord, siehe .7.1) und TweakSet (für Konfigurationsparameter, siehe .B.5). Das Package enthält außerdem Property-Dateien mit den vorgegebenen Konzepttypen (ConceptTypes.properties), Sprachcodes (Languages.properties) und Namensräumen (Namespaces.properties). de.brightbyte.wikiword.disambig enthält Klassen zur automatischen Sinnzuweisung an Terme im Kontext (Disambiguierung) sowie die dafür benötigten Klassen zur Bestimmung von semantischer Verwandtheit zwischen Konzepten (.14). de.brightbyte.wikiword.model enthält Modell-Klassen, die Konzepte und Ressourcen sowie Referenzen auf Terme und Konzepte repräsentieren. Instanzen dieser Klassen dienen als Transferobjekte bei Abfrage von Thesaurusdaten aus der Datenbank (DAO-Schicht, siehe .C.3). de.brightbyte.wikiword.query enthält die Kommandozeilenschnittstellen und Hilfsklassen für die Abfrage von Thesaurusdaten. Diese sind vor allem für Test und Evaluation von WikiWord nützlich. de.brightbyte.wikiword.rdf enthält die Kommandozeilenschnittstellen und Hilfsklassen für den Datenexport nach RDF/SKOS (siehe .10). de.brightbyte.wikiword.schema enthält Hilfsklassen, die die Datenbank-Schemata für die einzelnen Store-Klassen der DAO-Schicht definieren: Jede Schema-Klasse stellt einen Satz von Datenbanktabellen und den zugehörigen Datenfeldern bereit (.C.2). Sie definiert außerdem die Logik für eine Konsistenzprüfung der Daten sowie für die Erhebung einer einfachen Statistik über die enthaltenen Daten. Diese Klassen werden von den Datenzugriffsobjekten (DAOs) in de.brightbyte.wikiword.store und de.brightbyte.wikiword.store. builder benutzt. de.brightbyte.wikiword.store enthält die Definition der einzelnen Datenzugriffsobjekte (DAOs) für die Abfrage und Nutzung der Thesaurusdaten (siehe .9.1 und .C.3). G. Quellcode 189 Dieser Kern von WikiWord umfasst 134 Klassen und über 11 000 Zeilen Programmcode. Die Logik für den Import von Daten bzw. den Aufbau des Thesaurus ist in den folgenden Packages implementiert: de.brightbyte.wikiword.analyzer enthält die Klassen, die die Analyse von Wiki-Text implementieren, also zum Aufbau des Ressourcenmodells aus den Rohdaten (siehe .8). de.brightbyte.wikiword.builder enthält die Kommandozeilenschnittstelle für den Aufbau des Thesaurus sowie Hilfsklassen der Import-Architektur (siehe .B.1 und .7.1) de.brightbyte.wikiword.store.builder enthält die Definition der einzelnen Datenzugriffsobjekte (DAOs) für den Aufbau und die Konsolidierung der Thesaurusdaten (siehe .9.2 und .C.4). de.brightbyte.wikiword.wikis enthält die Konfiguration für die einzelnen Wikis, also Wissen über deren spezielle Einrichtung und Konventionen, sowie sprachspezifisches Wissen. Diese Informationen werden für die Analyse des Wiki-Textes verwendet (.8). Die Logik für den Import von Daten umfasst 121 Klassen und über 14 000 Zeilen Programmcode. Zusätzliche Logik für Experimente mit und für die Evaluation von WikiWord (.IV) befindet sich in den folgenden Packages: de.brightbyte.wikiword.eval enthält die Kommandozeilenschnittstelle für die Evaluation von WikiWord. de.brightbyte.wikiword.schema enthält die Schema-Definition und die DAO-Schicht für die Evaluation, also insbesondere für die Speicherung der in Experimenten erhobenen Daten und deren statistische Auswertung. Die Funktionen für die Evaluation umfasst 43 Klassen und über 5 000 Zeilen Programmcode. Der Programmcode von WikiWord steht unter der GNU General Public License [GPL] und kann frei genutzt werden (siehe LIZENZ, S. 207). Für eine Aufstellung der verwendeten Programmbibliotheken siehe .G.2. Für die URLs, unter denenWikiWord verfügbar ist, siehe .G.3. Eine kurze Anweisung zum Kompilieren von WikiWord findet sich in .G.4. G.2. Verwendete Bibliotheken WikiWord verwendet neben den von Java bereitgestellten Standardklassen eine Anzahl von Bibliotheken, die Standard-Aufgaben übernehmen. Diese sind: JUnit ist ein Unit-Testing-Framework für Java (<http://www.junit.org/>). Es wird nur zur Kompilierung und Ausführung der Testklassen von WikiWord benötigt. JUnit steht unter der Common Public License [CPL]. G. Quellcode 190 Connector/J ist der offizielle JDBC-Treiber für MySQL (<http://www.mysql.com/ products/connector/j/>). Er wird nur zur Laufzeit für den Zugriff auf MySQLDatenbanken benötigt. Connector/J steht unter der GNU General Public License [GPL]. MWDumper ist ein Programm bzw. eine Bibliothek zum Lesen und Schreiben von MediaWiki- Dumps [MW:DUMPER, MW:XML]. Er wird für den Import von MediaWiki-Dumps in WikiWord benötigt. MWDumper wird von der Wikimedia Foundation entwickelt und steht unter der GNU General Public License [GPL]. MWDumper benötigt seinerseits einige zusätzliche Bibliotheken: swing-layout ist eine Erweiterung der Layout-Klassen Swing, Javas Bibliothek für grafische Benutzeroberflächen (<https://swing-layout.dev.java.net/>). Diese Bibliothek wird für die Kompilierung von MWDumper benötigt und im interaktiven Modus von MWDumper eingesetzt. Dieser wird jedoch im Kontext von WikiWord nicht verwendet, so dass diese Bibliothek zur Laufzeit nicht unbedingt benötigt wird. Swing-layout steht unter der GNU Lesser General Public License [LGPL]. Der PostgreSQL JDBC Driver ist der offizielle JDBC-Treiber für PostgreSQL (<http:// jdbc.postgresql.org/>). Er wird von MWDumper lediglich zur Laufzeit benötigt, um auf PostgreSQL-Datenbanken zuzugreifen – was im Kontext vonWikiWord nicht notwendig ist. Der PostgreSQL JDBC Driver steht unter der BSD License [BSDL]. Xerces ist eine Bibliothek für die Verarbeitung von XML (<http://xerces.apache.org/ xerces2-j/>). Sie wird von MWDumper zur Laufzeit zur schnelleren Verarbeitung der MediaWiki-Dumps verwendet. Fehlt diese Bibliothek, so wird Javas integrierter XMLParser verwendet, der etwas langsamer ist. Xerces wird von der Apache Software Foundation entwickelt und steht unter der Apache Software License [ASL]. XML-Commons ist eine Hilfsbibliothek zur Verarbeitung von XML (<http://xml.apache. org/commons/>). Wie Apache Xerces wird sie von MWDumper zur Laufzeit zur Verarbeitung von XML verwendet, wird aber nicht unbedingt benötigt. XML-Commons wird von der Apache Software Foundation entwickelt und steht unter der Apache Software License [ASL]. WikiWord verwendet einige Bibliotheken, die ebenfalls vom Autor entwickelt wurden, aber unabhängig von und zeitlich vor dieser Diplomarbeit. Sie dienen allgemeinen Aufgaben und enthalten keinen Code, der sich auf die Verarbeitung von Wiki-Text oder den Aufbau eines Thesaurus bezieht. BrightByteUtil enthält diverse Hilfsklassen, unter Anderem zur Arbeit mit Strings, Collections, XML, HTML sowie für die Verarbeitung von dünnbesetzten Matrizen und Vektoren. BrightByteDB enthält Hilfsklassen für die Arbeit mit relationalen Datenbanken, insbesondere MySQL. G. Quellcode 191 BrightByteRDF enthält ein Framework zur Erzeugung und Verarbeitung von RDF-Dateien. Diese Bibliotheken stehen unter der GNU Lesser General Public License [LGPL]. Der Quellcode sowie verschiedene Archivdateien stehen unter <http://brightbyte.de/TK/DA/> bereit. Diese Abhängigkeiten sind über die Datei pom.xml in jedem Projekt definiert und können so mit Hilfe von Apache Maven [MVN] automatisch aufgelöst werden (siehe auch .G.4). G.3. Bündel Der Quellcode von WikiWord steht an den folgenden Orten zur Verfügung: • Das Verzeichnis /WikiWord/WikiWord/ auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/WikiWord/WikiWord/> enthält die Quellen für den Kern von WikiWord. Diese Dateien befinden sich auch in einem Archiv unter /WikiWord-0. 1-src.tar.gz auf der beiliegenden CD oder online unter <http://brightbyte.de/ DA/WikiWord-0.1-src.tar.gz>. • Das Verzeichnis /WikiWord/WikiWordBuilder/ auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/WikiWord/WikiWordBuilder/> enthält die Quellen für das System zum Aufbau von Thesauri. Diese Dateien befinden sich auch in einem Archiv unter /WikiWordBuilder-0.1-src.tar.gz auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/WikiWordBuilder-0.1-src.tar.gz>. • Das Verzeichnis /WikiWord/WikiWordEval/ auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/WikiWord/WikiWordEval/> enthält die Quellen für die Logik zur Evaluation von WikiWord. Diese Dateien befinden sich auch in einem Archiv unter /WikiWordEval-0.1-src.tar.gz auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/WikiWordEval-0.1-src.tar.gz>. Dabei ist zu beachten, dass WikiWordBuilder und WikiWordEval beide vom Kern WikiWord, aber nicht voneinander abhängig sind. Die drei Komponenten von WikiWord stehen auch in bereits kompilierter Form zur Verfügung: • Die Datei /bin/WikiWord-0.1/lib/WikiWord-0.1.jar auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/bin/WikiWord-0.1/lib/WikiWord-0.1. jar> enthält den Kern von WikiWord als Programmbibliothek. Ein Archiv, das alle benötigten Bibliotheken und Hilfsdateien enthält, befindet sich unter /WikiWord-0. 1-bin-dep.tar.gz auf der beiliegenden CD oder online unter <http://brightbyte. de/DA/WikiWord-0.1-bin-dep.tar.gz>. G. Quellcode 192 • Die Datei /bin/WikiWordBuilder-0.1/lib/WikiWordBuilder-0.1.jar auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/bin/ WikiWordBuilder-0.1/lib/WikiWordBuilder-0.1.jar> enthält das System zum Aufbau von Thesauri als Programmbibliothek. Ein Archiv, das alle benötigten Bibliotheken und Hilfsdateien enthält, befindet sich unter /WikiWordBuilder-0.1-bin-dep.tar.gz auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/ WikiWordBuilder-0.1-bin-dep.tar.gz>. • Die Datei /bin/WikiWordEval-0.1/lib/WikiWordEval-0.1.jar auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/bin/WikiWordEval-0.1/ lib/WikiWordEval-0.1.jar> enthält die Logik zur Evaluation von WikiWord als Programmbibliothek. Ein Archiv, das alle benötigten Bibliotheken und Hilfsdateien enthält, befindet sich unter /WikiWordEval-0.1-bin-dep.tar.gz auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/WikiWordEval-0.1-bin-dep.tar.gz>. G.4. Kompilieren WikiWord ist in Java implementiert. Als Build-System, um aus dem Quellcode Programme und Bibliotheken zur erzeugen, wurde Apache Maven [MVN] verwendet. Dieses System hat insbesondere den Vorzug, dass es automatisch Abhängigkeiten zwischen Programmbibliotheken verwaltet und auflöst. Allerdings ist das nur möglich, wenn alle benötigten Bibliotheken in einem Repository verfügbar sind, entweder lokal oder online. Die BrightByte- und WikiWord-Bibliotheken sind in keinem Online-Repository abgelegt und müssen daher explizit lokal installiert werden, um mit Maven genutzt werden zu können. Um eine Komponente vonWikiWord (oder ein anderes Maven- Projekt) zu kompilieren, zu testen und lokal zu installieren, dient der folgende Befehl, auszuführen im Basisverzeichnis des Projektes, das auch die Datei pom.xml enthält: mvn install Damit steht die entsprechende Bibliothek (JAR-Datei) für die Benutzung durch andere Programme im Maven-Repository bereit. Des Weiteren stehen die folgenden Kommandos zur Verfügung: clean löscht alle temporären Daten und erzwingt eine vollständige Neukompilierung aller Dateien. compile kompiliert die Programmdateien. test führt alle Uni-Tests aus. Um für die einzelnen Module bzw. Bibliotheken Bündel zu erzeugen, eignet sich das folgende Kommando: mvn assembly:assembly G. Quellcode 193 Dieser Befehl ist ebenfalls im Basisverzeichnis des betreffenden Projektes auszuführen. Die erzeugten Bündel werden im Verzeichnis target abgelegt. Die Bündel mit der Endung
[+]

• bin-dep.tar.gz enthalten vollständige Installationen mit allen benötigten Bibliotheken und

Hilfsdateien. G.5. TeX-Quellen Die vorliegende Diplomarbeit wurde mit Hilfe des Textsatzsystems LATEX geschrieben, der Quelltext ist unter /WikiWord/WikiWordThesis/Diplomarbeit/ auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/WikiWord/WikiWordThesis/ Diplomarbeit/> oder als Archiv unter /WikiWordThesis-tex.tar.gz auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/WikiWordThesis-tex.tar.gz> verfügbar. Als Build-System für die Erzeugung einer druckfertigen PDF-Datei aus den TeX-Dateien und anderen Quellen wurde Apache Ant [ANT] verwendet. Das Build-Skript für Ant, build.xml, definiert insbesondere die folgenden Kommandos (targets): clean löscht alle temporären Daten und erzwingt eine vollständige Neuerzeugung aller Dateien. build erzeugt aus den Quelldateien eine druckfertige PDF-Datei. Diese wird unter target/WikiWord.pdf abgelegt. Für den Build-Prozess werden diverse externe Programme sowie zusätzliche Module für TeX und MetaPost benötigt. Eine Aufstellung befindet sich in der Datei BUILDING, auch zu finden unter /WikiWord/WikiWordThesis/BUILDING auf der beiliegenden CD oder online unter <http: //brightbyte.de/DA/WikiWord/WikiWordThesis/BUILDING>. Das Build-Skript wurde für die Verwendung unter Linux entwickelt, für eine Ausführung unter Windows sind vermutlich diverse Anpassungen notwendig. Die Version von LATEX, die für die Erstellung dieser Arbeit verwendet wurde, ist LaTeX2e bzw. pdfeTeX 3.141592, wie von tetex bereitgestellt. Soll eine andere Implementation verwendet werden, können unter Umständen kleine Anpassungen notwendig sein. Der Text dieser Diplomarbeit steht unter der GNU Free Documentation License [GFDL] und kann frei genutzt werden (siehe LIZENZ, S. 207). Literaturverzeichnis Hinweis: Es wurden sowohl Print- wie Online-Ressourcen berücksichtigt. Insebsondere ist eine Vielzahl vonWikipedia- Seiten zitiert, die Wikipedia-Konventionen erklären, die für diese Arbeit wichtig sind. ANT : Apache Ant. – URL http://ant.apache.org/ ASL : Apache License, Version 2.0. – URL http://www.apache.org/licenses/LICENSE-2.0 van Assem u. a. 2006 ASSEM, Mark van ; MALAIS´E, Véronique ; MILES, Alistair ; SCHREIBER, Guus: A Method to Convert Thesauri to SKOS. In: The Semantic Web: Research and Applications (2006), S. 95– 109. – URL http://dx.doi.org/10.1007/11762256_10 Auer und Lehmann 2007 AUER, Sören ; LEHMANN, Jens: What have Innsbruck and Leipzig in common? Extracting Semantics from Wiki Content. In: Proc. 4th European Semantic Web Conf (2007), S. 503– 517. – URL http://dx.doi.org/10.1007/978-3-540-72667-8_36 Auer u. a. 2007 AUER, Sören ; BIZER, C. ; KOBILAROV, G. ; LEHMANN, Jens ; CYGANIAK, R. ; IVES, Z.: DBpedia: A Nucleus for aWeb of Open Data. In: 6th Int’l Semantic Web Conference, Busan, Korea, Nov (2007) Backett 2007 BACKETT, David: Turtle – Terse RDF Triple Language. 2007. – URL http://www. dajobe.org/2004/01/turtle/ Barabasi und Albert 1999 BARABASI, A. L. ; ALBERT, R.: Emergence of scaling in random networks. In: Science 286 (1999), Oktober, Nr. 5439, S. 509–512. – URL http://view.ncbi.nlm.nih.gov/ pubmed/10521342. – ISSN 0036-8075 Bellomi und Bonato 2005a BELLOMI, F. ; BONATO, R.: Lexical authorities in an encyclopedic corpus: a case study with wikipedia. In: International Colloquium on ‘Word structure and lexical systems: models and applications’, URL http://www.fran.it/blog/2005/01/ lexical-authorities-in-encyclopedic.html, 2005 Bellomi und Bonato 2005b BELLOMI, F ; BONATO, R: Network Analysis forWikipedia. In: Proceedings of Wikimania 2005 (2005). – URL http://www.fran.it/articles/wikimania_bellomi_bonato. pdf Berners-Lee 1998 BERNERS-LEE, Tim: Cool URIs don’t change. 1998. – URL http://www.w3.org/ Provider/Style/URI.html Biemann u. a. 2004 BIEMANN, C. ; BORDAG, S. ; HEYER, G. ; QUASTHOFF, U. ; WOLFF, C.: Languageindependent Methods for Compiling Monolingual Lexical Data. In: Proceedings of CicLING, Springer, 2004, S. 215–228 Black 2006 BLACK, J.: Creating a common ground for URI meaning using socially constructed web sites. In: Proceedings of Identity, Reference, and the Web Workshop (IMW06), URL http://www.ibiblio. org/hhalpin/irw2006/jblack.pdf, 2006 BSDL : BSD License. – URL http://www.opensource.org/licenses/bsd-license.php Buchanan und Feigenbaum 1982 BUCHANAN, B. G. ; FEIGENBAUM, E. A.: Forward. In: DTIC Research Report (1982), Nr. ADF650104 Literaturverzeichnis 195 Bunescu und Pasca 2006 BUNESCU, Razvan ; PASCA, Marius: Using Encyclopedic Knowledge for Named Entity Disambiguation. In: 11th Conference of the European Chapter of the Association for Computational Linguistics, URL http://www.cs.utexas.edu/~ml/publication/paper.cgi? paper=encyc-eacl-06.ps.gz, April 2006, S. 9–16 Capocci u. a. 2006 CAPOCCI, A. ; SERVEDIO, V. D. P. ; COLAIORI, F. ; BURIOL, L. S. ; DONATO, D. ; LEONARDI, S. ; CALDARELLI, G.: Preferential attachment in the growth of social networks: the case of Wikipedia. Februar 2006. – URL http://arxiv.org/abs/physics/0602026 CCS : Computing Classification System. – URL http://www.acm.org/class/ Chan 1986 CHAN, L. M.: Library of Congress Classification as an Online Retrieval Tool: Potentials and Limitations. In: Information Technology and Libraries 5 (1986), Nr. 3, S. 181–92 Coulter u. a. 1998 COULTER, N. ; FRENCH, J. ; GLINERT, E. ; HORTON, T. ; MEAD, N. ; RADA, R. ; RALSTON, A. ; RODKIN, C. ; ROUS, B. ; AND, A. T.: Computing Classification System 1998: Current Status and Future Maintenance Report of the CCS Update Committee. In: Computing Reviews (1998), S. 1 CPL : Common Public License - v 1.0. – URL http://www.opensource.org/licenses/cpl1.0. txt Craswell u. a. 2001 CRASWELL, N. ; HAWKING, D. ; ROBERTSON, S.: Effective Site Finding using Link Anchor Information. In: SIGIR’01, URL http://pigfish.vic.cmis.csiro.au/~nickc//pubs/ sigir01.pdf, 2001 Cucerzan 2007 CUCERZAN, S.: Large-Scale Named Entity Disambiguation Based onWikipedia Data. In: EMNLP 2007: Empirical Methods in Natural Language Processing, June 28-30, 2007, Prague, Czech Republic (2007) CYC : Cyc. – URL http://www.cyc.com/ Dakka und Cucerzan 2008 DAKKA, Wisam ; CUCERZAN, Silviu: Augmenting Wikipedia with Named Entity Tags. In: IJCNLP, URL http://research.microsoft.com/users/silviu/Papers/ ijcnlp08.pdf, 2008 Davulcu u. a. 2006 DAVULCU, H. ; NGUYEN, H. V. ; RAMACHANDRAN, V.: Boosting Item Findability: Bridging the Semantic Gap Between Search Phrases and Item Information. In: International Journal of Intelligent Information Technologies 2 (2006), Nr. 3, S. 1–20. – URL http://www.public.asu. edu/~hdavulcu/ICEIS05.pdf DBpedia : DBpedia. – URL http://dbpedia.org/ DCME 2008 : Dublin Core Metadata Element Set, Version 1.1. 2008. – URL http://dublincore. org/documents/dces/ DDC : Dewey Decimal Classification. – URL http://www.oclc.org/dewey/ Deerwester u. a. 1990 DEERWESTER, S. ; DUMAIS, S. T. ; FURNAS, G.W. ; LANDAUER, T. K. ; HARSHMAN, R.: Indexing by latent semantic analysis. In: Journal of the American Society for Information Science 41 (1990), Nr. 6, S. 391–407 Dewey 1965 DEWEY, M.: Dewey; Decimal classification and relative index. In: New York; Lake Placid Club Education Foundation, 1965, 2 s..(2480) p. Tablas (1965) Literaturverzeichnis 196 Eiron und Mccurley 2003 EIRON, N. ; MCCURLEY, K.: Analysis of anchor text for web search. 2003. – URL http://www.mccurley.org/papers/anchor.pdf Evert 2004 EVERT, S.: A simple LNRE model for random character sequences. In: Proceedings of JADT (2004), S. 411–422 FCW : Definition of Free Cultural Works v1.0. – URL http://freedomdefined.org/Definition Fellbaum 1998 FELLBAUM, C.: WordNet: an electronic lexical database. Cambridge, MA : MIT Press, 1998 Fiebig 2005 FIEBIG, H.: Wikipedia - Das Buch. Berlin : Zenodot Verl.-Ges., 2005. – ISBN 3-86640-001-2 Freebase : Freebase. – URL http://www.freebase.com/ Gabrilovich und Markovitch 2006 GABRILOVICH, E. ; MARKOVITCH, S.: Overcoming the brittleness bottleneck using Wikipedia: Enhancing text categorization with encyclopedic knowledge. In: Proceedings of the Twenty-First National Conference on Artificial Intelligence, Boston, MA (2006) Gabrilovich und Markovitch 2007 GABRILOVICH, E. ;MARKOVITCH, S.: Computing Semantic Relatedness using Wikipedia-based Explicit Semantic Analysis. In: Proceedings of the 20th International Joint Conference on Artificial Intelligence (2007), S. 6–12 Gabrilovich 2006 GABRILOVICH, Evgeniy: Feature Generation for Textual Information Using World Knowledge, The Technion - Israel Institute of Technology, Dissertation, 2006. – URL http://www. hpl.hp.com/techreports/2007/HPL-2007-182.pdf. Garshol 2004 GARSHOL, Lars M.: Metadata? Thesauri? Taxonomies? Topic Maps!: Making sense of it all. In: Journal of Information Science 30 (2004), Nr. 4, S. 378–391. – URL http://jis.sagepub. com/cgi/content/abstract/30/4/378 GFDL : GNU Free Documentation License. – URL http://www.gnu.org/licenses/fdl.html Giles 2005 GILES, Jim: Internet encyclopaedias go head to head. In: Nature 438 (2005), S. 900–901. – URL http://www.nature.com/nature/journal/v438/n7070/pdf/438900a.pdf GNU-R : GNU-R. – URL http://www.r-project.org/ GPL : GNU General Public License. – URL http://www.gnu.org/copyleft/gpl.html Gregorowicz und Kramer 2006 GREGOROWICZ, Andrew ; KRAMER, Mark A.: Mining a Large-Scale Term-Concept Network fromWikipedia / Mitre. URL http://www.mitre.org/work/tech_papers/ tech_papers_06/06_1028/06_1028.pdf, 2006. – Forschungsbericht Halpin 2006 HALPIN, H.: Identity, Reference, and Meaning on theWeb. In: Proceedings of the Workshop on Identity, Meaning and the Web (IMW06), URL http://www.ra.ethz.ch/CDstore/www2006/ www.ibiblio.org/hhalpin/irw2006/hhalpin.pdf, 2006 Hammwöhner 2007 HAMMW¨OHNER, Rainer: SemanticWikipedia - Checking the Premises. In: The Social Semantic Web 2007 - Proceedings of the 1st Conference on Social Semantic Web. Bonn : Gesellschaft für Informatik, 2007 (Lecture Notes in Informatics) Hammwöhner 2007a HAMMW¨OHNER, R.: Qualitätsaspekte der Wikipedia. In: Kommunikation@ gesellschaft 8 (2007). – Wikis - Diskurse, Theorien und Anwendungen Literaturverzeichnis 197 Hammwöhner 2007b HAMMW¨OHNER, Rainer: Interlingual Aspects if Wikipedia’s Quality. In: ROBBERT, Mary A. (Hrsg.) ; MARKUS, M. L. (Hrsg.) ; KLEIN, Barbara (Hrsg.): 12th International Conference on Information Quality (ICIQ-2007), M.I.T., 2007. – URL http://mitiq.mit.edu/iciq/PDF/ INTERLINGUAL%20ASPECTS%20OF%20WIKIPEDIAS%20QUALITY.pdf. – Universität Regensburg Hepp u. a. 2006 HEPP, M. ; BACHLECHNER, D. ; SIORPAES, K.: Harvesting Wiki Consensus - Using Wikipedia Entries as Ontology Elements. In: First Workshop on Semantic Wikis (2006) Heyer u. a. 2006 HEYER, Gerhard ; QUASTHOFF, Uwe ; WITTIG, Thomas: Text Mining: Wissensrohstoff Text. W3L, 2006. – ISBN 3-937137-30-0 Ide und Veronis 1998 IDE, Nancy ; VERONIS, Jean: Word Sense Disambiguation: The State of the Art. In: Computational Linguistics 24 (1998), S. 1–40. – URL http://sites.univ-provence.fr/veronis/ pdf/1998wsd.pdf IEEE:SUO-WG : Standard Upper Ontology Working Group. – URL http://suo.ieee.org/ ISO:13250 2003 : ISO/IEC 13250:2003 – Information technology – SGML applications – Topic maps. 2003. – URL http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail. htm?csnumber=38068 ISO:2788 1986 : ISO 2788:1986 – Documentation – Guidelines for the establishment and development of monolingual thesauri. 1986. – URL http://www.iso.org/iso/iso_catalogue/catalogue_ tc/catalogue_detail.htm?csnumber=7776 ISO:639-1 2002 : ISO 639-1:2002 – Codes for the representation of names of languages – Part 1: Alpha- 2 code. 2002. – URL http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_ detail.htm?csnumber=22109 ISO:646 1991 : ISO/IEC 646:1991 – Information technology – ISO 7-bit coded character set for information interchange. 1991. – URL http://www.iso.org/iso/iso_catalogue/catalogue_tc/ catalogue_detail.htm?csnumber=4777 Jarmasz und Szpakowicz 2001 JARMASZ, M. ; SZPAKOWICZ, S.: Roget’s Thesaurus as an Electronic Lexical Knowledge Base, Bialystok, 2001 (NIE BEZ ZNACZENIA. Prace ofiarowane Profesorowi Zygmuntowi Saloniemu z okazji). – URL http://www.site.uottawa.ca/~mjarmasz/pubs/ TR-2000-02.pdf Jarmasz und Szpakowicz 2003 JARMASZ, Mario ; SZPAKOWICZ, Stan: Roget’s thesaurus and semantic similarity. In: Conference on Recent Advances in Natural Language Processing, URL http://www. site.uottawa.ca/~mjarmasz/pubs/jarmasz_roget_sim.pdf, 2003, S. 212–219 JAVA:DAO : Core J2EE Patterns - Data Access Object. – URL http://java.sun.com/ blueprints/corej2eepatterns/Patterns/DataAccessObject.html JAVA:RE : Pattern. – URL http://java.sun.com/javase/6/docs/api/java/util/regex/ Pattern.html JDBC : JDK 6 Java Database Connectivity (JDBC) – related APIs & Developer Guides. – URL http://java.sun.com/javase/6/docs/technotes/guides/jdbc/ Johnston u. a. 1998 JOHNSTON, D. ; NELSON, S. J. ; SCHULMAN, J. L. A. ; SAVAGE, A. G. ; POWELL, T. P.: Redefining a Thesaurus: Term-Centric No More. In: Proceedings of the 1998 AMIA Annual Symposium, American Medical Informatics Association, 1998. – URL http://www.amia.org/pubs/symposia/ D004917.PDF Literaturverzeichnis 198 Kazama und Torisawa 2007 KAZAMA, Jun’ichi ; TORISAWA, Kentaro: Exploiting Wikipedia as External Knowledge for Named Entity Recognition. In: Joint Conference on Empirical Methods in Natural Language Processing and Computational Natural Language Learning, URL http://www.aclweb. org/anthology-new/D/D07/D07-1073.pdf, 2007, S. 698–707 Kraft und Zien 2004 KRAFT, Reiner ; ZIEN, Jason: Mining anchor text for query refinement. In: WWW ’04: Proceedings of the 13th international conference on World Wide Web, ACM Press, 2004, S. 666– 674. – URL http://portal.acm.org/citation.cfm?id=988763. – ISBN 1-58113-844-X Krizhanovsky 2006 KRIZHANOVSKY, A.: Synonym search in Wikipedia: Synarcher. Juni 2006. – URL http://arxiv.org/abs/cs.IR/0606097 Krötzsch u. a. 2005 KR¨OTZSCH, M. ; VRANDECIC, D. ; V¨OLKEL, M.: Wikipedia and the Semantic Web - The Missing Links. 2005. – URL http://citeseer.ist.psu.edu/krotzsch05wikipedia.html Krötzsch u. a. 2007 KR¨OTZSCH, Markus ; VRANDECIC, Denny ; V¨OLKEL, Max ; HALLER, Heiko ; STUDER, Rudi: Semantic Wikipedia. In: Journal of Web Semantics (2007), Dezember. – URL hhttp://www. aifb.uni-karlsruhe.de/Publikationen/showPublikation_english?publ_id=1551 Kumar u. a. 2006 KUMAR, C. A. ; GUPTA, A. ; BATOOL, M. ; TREHAN, S.: Latent Semantic Indexing-Based Intelligent Information Retrieval System for Digital Libraries. In: Journal of Computing and Information technology 14 (2006), Nr. 3, S. 191 LCC : Library of Congress Classification. – URL http://www.loc.gov/catdir/cpso/lcc.html Lenat und Feigenbaum 1991 LENAT, D. B. ; FEIGENBAUM, E. A.: On the thresholds of knowledge. In: Artificial Intelligence 47 (1991), Nr. 1-3, S. 185–250 Lenat u. a. 1990 LENAT, D. B. ; GUHA, RV ; PITTMAN, K. ; PRATT, D. ; SHEPHERD, M.: Cyc: toward programs with common sense. In: Communications of the ACM 33 (1990), Nr. 8, S. 30–49 Leuf und Cunningham 2001 LEUF, Bo ; CUNNINGHAM, Ward: The Wiki Way: Collaboration and Sharing on the Internet. Addison-Wesley Professional, April 2001. – ISBN 0-201-71499-X Levenshtein 1966 LEVENSHTEIN, VI: Binary Codes Capable of Correcting Deletions, Insertions and Reversals. In: Soviet Physics Doklady 10 (1966), S. 707 LGPL : GNU Lesser General Public License. – URL http://www.gnu.org/licenses/lgpl-3.0. html Lipscomb 2000 LIPSCOMB, C. E.: Medical Subject Headings (MeSH). In: Bulletin of the Medical Library Association 88 (2000), Nr. 3, S. 265 Mahn und Biemann 2005 MAHN, Marek ; BIEMANN, Chris: Tuning Co-occurrences of Higher Orders for Generating Ontology Extension Candidates. In: ICML-Workshop on Ontology Learning, August 2005 Maicher 2007 MAICHER, Lutz: The Impact of Semantic Handshakes, Universität Leipzig, Diplomarbeit, 2007. – 140–151 S. – URL http://dx.doi.org/10.1007/978-3-540-71945-8_13 Matthews 2003 MATTHEWS, B. ; MILES, A. ; WILSON, M.: Modelling Thesauri for the Semantic Web. 2003. – URL http://www.w3c.rl.ac.uk/SWAD/papers/thesaurus/swdbpaper.html. – CCLRC, Rutherford Appleton Laboratory, Didcot, OXON OX11 0QX, UK MeSH : Medical Subject Headings. – URL http://www.nlm.nih.gov/mesh/ Literaturverzeichnis 199 Mihalcea u. a. 2004 MIHALCEA, R. ; CHKLOVSKI, T. ; KILGARRIFF, A.: The Senseval-3 English lexical sample task. In: Proceedings of SENSEVAL-3: Third International Workshop on the Evaluation of Systems for the Semantic Analysis of Text [CD-ROM], 2004, S. 25–28 Mihalcea 2007 MIHALCEA, Rada: Using Wikipedia for Automatic Word Sense Disambiguation. In: Proceedings of NAACL HLT 2007, URL http://www.cs.unt.edu/~rada/papers/mihalcea. naacl07.pdf, 2007 Miles 2005a MILES, A.: Working around the identity crisis. 2005. – URL http://esw.w3.org/topic/ SkosDev/IdentityCrisis Miles 2005b MILES, Alistair: SKOS: Simple Knowledge Organisation for the Web. In: Cataloging & Classification Quarterly (2005), April. – URL http://www.ingentaconnect.com/content/ haworth/ccq/2007/00000043/F0020003/art00005 Miller 1995 MILLER, G. A.: WordNet: A Lexical Database for English. In: Communications of the ACM 38 (1995), Nr. 11, S. 39 Milne u. a. 2006 MILNE, David ; MEDELYAN, Olena ; WITTEN, Ian H.: Mining Domain-Specific Thesauri from Wikipedia: A case study. In: ACM International Conference on Web Intelligence (WI 2006 Main Conference Proceedings)(WI’06), URL http://csdl.computer.org/dl/proceedings/wi/2006/ 2747/00/274700442.pdf, 2006, S. 442–448 Milne u. a. 2007 MILNE, David ; WITTEN, Ian H. ; NICHOLS, David M.: Extracting corpus specific knowledge bases from Wikipedia / University of Waikato. URL http://researchcommons.waikato.ac. nz/cms_papers/46/, 2007 (Working Paper 03/2007). – Forschungsbericht Milne und Nichols 2007 MILNE, Ian H. Witten D. ; NICHOLS, David M.: A Knowledge-Based Search Engine Powered by Wikipedia. In: CIKM ‘07, URL http://www.cs.waikato.ac.nz/%7Ednk2/ publications/cikm07.pdf, 2007 M:SITES : Wikimedia wikis. – URL http://meta.wikimedia.org/wiki/Special:SiteMatrix Muchnik u. a. 2007 MUCHNIK, Lev ; ITZHACK, Royi ; SOLOMON, Sorin ; LOUZOUN, Yoram: Self-emergence of knowledge trees: Extraction of the Wikipedia hierarchies. In: Physical Review E (Statistical, Nonlinear, and Soft Matter Physics) 76 (2007), Nr. 1. – URL http://scitation.aip.org/getabs/servlet/GetabsServlet?prog=normal\&id= PLEEE8000076000001016106000001\&idtype=cvips\&gifs=yes van Mulligen u. a. 2006 MULLIGEN, E. M. van ; M¨OLLER, E. ; ROES, P. J. ; WEEBER, M. ; MEIJSSEN, G. ; CHICHESTER, C. ; MONS, B.: An Online Ontology: WiktionaryZ. In: Proceedings of Knowledge Representation in Medicine (KR-MED) 2006, 2006 MVN : Apache Maven. – URL http://maven.apache.org/ MW:ABOUT : Welcome to MediaWiki.org. – URL http://www.mediawiki.org/wiki/MediaWiki MW:DUMPER : MWDumper. – URL http://www.mediawiki.org/wiki/MWDumper MW:EDIT : Help:Editing. – URL http://meta.wikimedia.org/wiki/Help:Editing MW:IMAGES : Help:Images. – URL http://www.mediawiki.org/wiki/Help:Images MW:MAGIC : Help:Magic words. – URL http://www.mediawiki.org/wiki/Help:Magic_words Literaturverzeichnis 200 MW:NS : Manual:Namespace. – URL http://www.mediawiki.org/wiki/Manual:Namespace MW:SPEC : MediaWiki markup spec project. – URL http://www.mediawiki.org/wiki/Markup_ spec MW:XML : Help:Export. – URL http://meta.wikimedia.org/wiki/Help:Export MYSQL : MySQL. – URL http://mysql.com/ Nakayama u. a. 2007a NAKAYAMA, Kotaro ; HARA, Takahiro ; NISHIO, Shojiro: A Thesaurus Construction Method from Large Scale Web Dictionaries. In: aina 00 (2007), S. 932–939 Nakayama u. a. 2007b NAKAYAMA, Kotaro ; HARA, Takahiro ; NISHIO, Shojiro: Wikipedia Mining for an Association Web Thesaurus Construction. In: BENATALLAH, Boualem (Hrsg.) ; CASATI, Fabio (Hrsg.) ; GEORGAKOPOULOS, Dimitrios (Hrsg.) ; BARTOLINI, Claudio (Hrsg.) ; SADIQ,Wasim (Hrsg.) ; GODART, Claude (Hrsg.): WISE Bd. 4831, Springer, 2007, S. 322–334. – URL http://dblp.uni-trier.de/db/conf/ wise/wise2007.html#NakayamaHN07 Nguyen u. a. 2007 NGUYEN, D. P. T. ; MATSUO, Y. ; ISHIZUKA, M.: Exploiting Syntactic and Semantic Information for Relation Extraction from Wikipedia. In: IJCAI Workshop on Text-Mining & Link-Analysis (TextLink 2007) (2007). – URL http://www.miv.t.u-tokyo.ac.jp/papers/ dat-IJCAI07-TextLinkWS.pdf Nguyen und Ishizuka 2007 NGUYEN, Yutaka Matsuo Dat P. T. ; ISHIZUKA, Mitsuru: Relation Extraction from Wikipedia Using Subtree Mining. In: AAAI ‘07, URL http://www.miv.t.u-tokyo.ac.jp/ papers/dat-AAAI07.pdf, 2007 Niles und Pease 2001 NILES, I. ; PEASE, A.: Towards a standard upper ontology. In: Proceedings of the international conference on Formal Ontology in Information Systems-Volume 2001 (2001), S. 2–9 Nock 2004 NOCK, C.: Data Access Patterns: Database Interactions in Object-Oriented Applications. Addison-Wesley Professional, 2004 OKD : Open Knowledge Definition v1.0. – URL http://www.opendefinition.org/1.0/ OmegaWiki : OmegaWiki. – URL http://www.omegawiki.org/ OpenCYC : OpenCyc. – URL http://www.opencyc.org/ Otlet und Fontaine 1905 OTLET, P. ; FONTAINE, H. L.: Universal Decimal Classification. In: Institut International de Bibliographie, Brussels (1905) Pepper und Schwab 2003 PEPPER, S. ; SCHWAB, S.: Curing the Web’s Identity Crisis: Subject Indicators for RDF. In: XML Conference (2003), S. 2006–04. – URL http://www.ontopia.net/topicmaps/ materials/identitycrisis.html Ponzetto und Strube 2007a PONZETTO, S. P. ; STRUBE, M.: An API for Measuring the Relatedness of Words in Wikipedia. In: Companion Volume to the Proceedings of the 45th Annual Meeting of the Association for Computational Linguistics (2007), S. 23–30 Ponzetto und Strube 2007b PONZETTO, Simone P. ; STRUBE, Michael: Deriving a large scale taxonomy from wikipedia. In: Proceedings of the 22nd National Conference on Artificial Intelligence, URL http: //www.eml-research.de/english/homes/strube/papers/aaai07.pdf, 2007 Literaturverzeichnis 201 Ponzetto und Strube 2007c PONZETTO, Simone P. ; STRUBE, Michael: Knowledge Derived from Wikipedia for Computing Semantic Relatedness. In: Journal of Artificial Intelligence Research 30 (2007), S. 181–212 Ponzetto 2007 PONZETTO, Simone P.: Creating a Knowledge Base from a Collaboratively Generated Encyclopedia. In: Proceedings of the NAACL-HLT 2007 Doctoral Consortium, URL http://www. aclweb.org/anthology-new/N/N07/N07-3003.pdf., 2007 Quasthoff 1998 QUASTHOFF, Uwe: Projekt Deutscher Wortschatz. In: HEYER, Gerhard (Hrsg.) ; WOLFF, Christian (Hrsg.): Linguistik und neue Medien. Proc. 10. Jahrestagung der Gesellschaft für Linguistische Datenverarbeitung. Wiesbaden : Deutscher Universitätsverlag, 1998 Redmann und Thomas 2007 REDMANN, Tobias ; THOMAS, Hendrik: The Wiki Way of Knowledge Management with Topic Maps. In: Proceedings of the International Conference on Information Society, URL http://www.i-society.org/2007/Contributors/Proceedings.htm, 2007, S. 352–357 RFC:3986 2005 : Uniform Resource Identifier (URI): Generic Syntax. 2005. – URL http://www. ietf.org/rfc/rfc3986.txt Ruiz-Casado u. a. 2005 RUIZ-CASADO, Maria ; ALFONSECA, Enrique ; CASTELLS, Pablo: Automatic Assignment of Wikipedia Encyclopedic Entries to WordNet Synsets. In: Advances in Web Intelligence, URL http://dx.doi.org/10.1007/11495772_59, 2005, S. 380–386 Salton und McGill 1986 SALTON, G. ; MCGILL, M. J.: Introduction to Modern Information Retrieval. New York, NY, USA : McGraw-Hill, Inc., 1986. – ISBN 0-07-054484-0 Salton u. a. 1975 SALTON, G. ; WONG, A. ; YANG, C. S.: A vector space model for automatic indexing. In: Commun. ACM 18 (1975), Nr. 11, S. 613–620. – URL http://doi.acm.org/10.1145/361219. 361220 de Saussure 2001 SAUSSURE, F. de: Grundfragen der allgemeinen Sprachwissenschaft. Walter de Gruyter, 2001. – Fr. original published 1916 Schönhofen 2006 SCH¨ONHOFEN, Péter: Identifying Document Topics Using the Wikipedia Category Network. In: Proceedings of the 2006 IEEE/WIC/ACM International Conference on Web Intelligence, URL http://portal.acm.org/citation.cfm?id=1249180, 2006 SMW : Semantic MediaWiki. – URL http://semantic-mediawiki.org/ Steyvers und Tenenbaum 2005 STEYVERS, Mark ; TENENBAUM, Joshua B.: The Large-Scale Structure of Semantic Networks: Statistical Analyses and a Model of Semantic Growth. In: Cognitive Science 29 (2005), Nr. 1, S. 41–78. – URL http://dblp.uni-trier.de/db/journals/cogsci/cogsci29. html#SteyversT05 Stock 2007 STOCK, Wolfgang G.: Information Retrieval. Oldenbourg, 2007. – ISBN 3-486-58172-4, 978-3-486-58172-0 Strube und Ponzetto 2006 STRUBE, M. ; PONZETTO, S. P.: WikiRelate! Computing Semantic Relatedness Using Wikipedia. In: AAAI, URL http://www.eml-research.de/english/homes/ strube/papers/aaai06.pdf, 2006 Stvilia u. a. 2005 STVILIA, B. ; TWIDALE, M. B. ; SMITH, L. C. ; GASSER, L.: Assessing information quality of a community-based encyclopedia. In: Proceedings of the International Conference on Information Quality, 2005, S. 442–454 Literaturverzeichnis 202 Suchanek u. a. 2007 SUCHANEK, F. M. ; KASNECI, G. ; WEIKUM, G.: Yago: a core of semantic knowledge. In: Proceedings of the 16th international conference on World Wide Web (2007), S. 697–706 SUMO : Suggested Upper Merged Ontology. – URL http://www.ontologyportal.org/ Syed u. a. 2008 SYED, Z. ; FININ, T. ; JOSHI, A.: Wikipedia as an Ontology for Describing Documents. In: Proceedings of the Second International Conference on Weblogs and Social Media, URL http://ebiquity.umbc.edu/paper/html/id/383/ Wikipedia-as-an-Ontology-for-Describing-Documents, 2008 Toral und Munoz 2006 TORAL, A. ; MUNOZ, R.: A proposal to automatically build and maintain gazetteers for Named Entity Recognition by using Wikipedia. In: EACL 2006 (2006) Toral und Munoz 2007 TORAL, Antonio ; MUNOZ, Rafael: Towards a Named Entity Wordnet (NEWN). In: Proceedings of the 6th International Conference on Recent Advances in Natural Language Processing (RANLP), URL http://www.dlsi.ua.es/~atoral/publications/2007_ranlp_newn_poster. pdf, 2007 UDC : UDC Consortium. – URL http://www.udcc.org/ UNICODE 2007 CONSORTIUM, The U. (Hrsg.): The Unicode Standard, Version 5.0.0. 2007. – URL http://www.unicode.org/versions/Unicode5.0.0/ VBNW 2003 VBNW (Hrsg.): Allgemeine Systematik für öffentliche Bibliotheken (ASB), Gliederung und Alphabetisches Schlagwortregister. Bock und Herchen, 2003. – Erarbeitet vom Ausschuss für Systematik beim Verband der Bibliotheken des Landes Nordrhein-Westfalen Voß 2005a VOSS, Jakob: Informetrische Untersuchungen an der Online-Enzyklopädie Wikipedia. Berlin, Humboldt University, Diplomarbeit, 2005. – URL http://jakobvoss.de/magisterarbeit/ MagisterarbeitJakobVoss.pdf Voß 2005b VOSS, Jakob: Measuring Wikipedia. In: Proceedings of the 10th International Conference of the International Society for Scientometrics and Informetrics, Karolinska University Press, 2005. – URL http://eprints.rclis.org/archive/00003610/ Voß 2006 VOSS, Jakob: Collaborative thesaurus tagging the Wikipedia way. April 2006. – URL http: //arxiv.org/abs/cs.IR/0604036 W3C 2005 W3C ;MILES, Alistair (Hrsg.): Quick Guide to Publishing a Thesaurus on the SemanticWeb / W3C. URL http://www.w3.org/TR/2005/WD-swbp-thesaurus-pubguide-20050517, Mai 2005 (TR/2005/WD-swbp-thesaurus-pubguide-20050517). – Working Draft. W3C Working Draft 17 May 2005 W3C:HTML 1999 : HTML 4.01 Specification. 1999. – URL http://www.w3.org/TR/html401/ W3C:N3 2006 BERNERS-LEE, Tim (Hrsg.): Notation 3 – An readable language for data on the Web. 2006. – URL http://www.w3.org/DesignIssues/Notation3.html W3C:NTriples 2004 : RDF Test Cases: N-Triples. 2004. – URL http://www.w3.org/TR/ rdf-testcases/#ntriples W3C:OWL 2004 : OWL Web Ontology Language Overview. 2004. – URL http://www.w3.org/TR/ owl-features/ W3C:RDF 2004 : RDF Primer. 2004. – URL http://www.w3.org/TR/rdf-primer/ Literaturverzeichnis 203 W3C:RDFS 2000 : Resource Description Framework (RDF) Schema Specification 1.0. 2000. – URL http://www.w3.org/TR/2000/CR-rdf-schema-20000327/ W3C:RDF/XML 2004 : RDF/XML Syntax Specification (Revised). 2004. – URL http://www.w3. org/TR/rdf-syntax-grammar/ W3C:SKOS 2004 : Simple Knowledge Organization System (SKOS) - Specifications & Documentation. 2004. – URL http://www.w3.org/2004/02/skos/specs W3C:SPARQL 2008 : SPARQL Query Language for RDF. 2008. – URL http://www.w3.org/TR/ rdf-sparql-query/ W3C:URI 2001 : URIs, URLs, and URNs: Clarifications and Recommendations 1.0. 2001. – URL http://www.w3.org/TR/uri-clarification/ W3C:XML 2006 : Extensible Markup Language (XML) 1.0 (Fourth Edition). 2006. – URL http: //www.w3.org/TR/xml/ W3C:XSD 2004 : XML Schema Part 0: Primer Second Edition. 2004. – URL http://www.w3.org/ TR/xmlschema-0/ Wales 2004 WALES, J.: Wikipedia Sociographics. In: Proceedings of 21C3, the 21st Chaos Communication Conference, 2004 Wilks u. a. 1996 WILKS, Y. ; SLATOR, B. M. ; GUTHRIE, L. M.: Electric Words: Dictionaries, Computers, and Meanings. MIT Press, 1996 Witte und Gitzinger 2007 WITTE, René ; GITZINGER, Thomas: Connecting wikis and natural language processing systems. In: D´ESILETS, Alain (Hrsg.) ; BIDDLE, Robert (Hrsg.): Int. Sym. Wikis, ACM, 2007, S. 165–176. – URL http://dblp.uni-trier.de/db/conf/wikis/wikis2007.html#WitteG07. – ISBN 978-1-59593-861-9 WM:10M 2008 : Wikipedia Hits Milestone of Ten Million Articles Across 250 Languages. press release. März 2008. – URL http://wikimediafoundation.org/wiki/Press_releases/10M_articles WM:2M 2007 : Wikipedia Reaches 2 Million Articles. press release. September 2007. – URL http://wikimediafoundation.org/wiki/Press_releases/Wikipedia_Reaches_2_ Million_Articles WM:ABOUT : About Wikimedia. – URL http://wikimediafoundation.org/wiki/About_ Wikimedia WM:DOWNLOAD : Wikimedia dump service. – URL http://download.wikipedia.org/ backup-index.html WM:PROJECTS : Wikimedia: Our projects. – URL http://wikimediafoundation.org/wiki/ Our_projects WM:SURVEY 2008 : Wikimedia Foundation and UNU-MERIT announce First Survey of Wikipedians. press release. Januar 2008. – URL http://wikimediafoundation.org/wiki/Press_releases/ UNU_survey_agreement WordNet : WordNet: a lexical database for the English language. – URL http://wordnet. princeton.edu/ Literaturverzeichnis 204 Wortschatz : Projekt Deutscher Wortschatz. – URL http://wortschatz.informatik. uni-leipzig.de/ WP:100K : Wikipedia:100,000 feature-quality articles. – URL http://en.wikipedia.org/wiki/ Wikipedia:100%2C000_feature-quality_articles WP:ARTIKEL : Wikipedia:Artikel. – URL http://de.wikipedia.org/wiki/Wikipedia: Artikel WP:BKL : Wikipedia:Begriffsklärung. – URL http://de.wikipedia.org/wiki/Wikipedia: Begriffskl%C3%A4rung WP:EA : Wikipedia:Exzellente Artikel. – URL http://de.wikipedia.org/wiki/Wikipedia: Exzellente_Artikel WP:GS : Wikipedia:Gesichtete Versionen. – URL http://de.wikipedia.org/wiki/Wikipedia: Gesichtete_Versionen WP:IB : Hilfe:Infoboxen. – URL http://de.wikipedia.org/wiki/Hilfe:Infoboxen WP:INTERLANG : Hilfe:Internationalisierung. – URL http://de.wikipedia.org/wiki/Hilfe: Internationalisierung WP:INTERWIKI : Hilfe:Interwiki-Links. – URL http://de.wikipedia.org/wiki/Hilfe: Interwiki-Links WP:KAT : Wikipedia:Kategorien. – URL http://de.wikipedia.org/wiki/Wikipedia: Kategorien WP:LINKS : Hilfe:Links. – URL http://de.wikipedia.org/wiki/Hilfe:Links WP:LR : Wikipedia:Löschregeln. – URL http://de.wikipedia.org/wiki/Wikipedia:L%C3% B6schregeln WP:NAVI : Hilfe:Navigationsleisten. – URL http://de.wikipedia.org/wiki/Hilfe: Navigationsleisten WP:NK : Wikipedia:Namenskonventionen. – URL http://de.wikipedia.org/wiki/Wikipedia: Namenskonventionen WP:NS : Wikipedia:Namensräume. – URL http://de.wikipedia.org/wiki/Wikipedia: Namensr%C3%A4ume WP:QS : Wikipedia:Wikipedia:Qualitätssicherung. – URL http://de.wikipedia.org/wiki/ Wikipedia:Wikipedia:Qualitätssicherung WP:RED : Wikipedia:Redundanz. – URL http://de.wikipedia.org/wiki/Wikipedia: Redundanz WP:RL : Wikipedia:Red link. – URL http://en.wikipedia.org/wiki/Wikipedia:Red_link WP:STATS : Wikipedia:Statistik. – URL http://de.wikipedia.org/wiki/Wikipedia: Statistik WP:TB : Wikipedia:Textbausteine. – URL http://de.wikipedia.org/wiki/Wikipedia: Textbausteine Literaturverzeichnis 205 WP:V : Wikipedia:Verlinken. – URL http://de.wikipedia.org/wiki/Wikipedia:Verlinken WP:VOR : Hilfe:Vorlagen. – URL http://de.wikipedia.org/wiki/Hilfe:Vorlagen WP:WL : Hilfe:Weiterleitung. – URL http://de.wikipedia.org/wiki/Hilfe:Weiterleitung WP:WSIGA : Wikipedia:Wie schreibe ich gute Artikel. – URL http://de.wikipedia.org/wiki/ Wikipedia:Wie_schreibe_ich_gute_Artikel Wu und Weld 2007 WU, Fei ; WELD, Daniel S.: Autonomously semantifying wikipedia. In: CIKM ’07: Proceedings of the sixteenth ACM conference on Conference on information and knowledge management. New York, NY, USA : ACM, 2007, S. 41–50. – URL http://portal.acm.org/citation. cfm?id=1321440.1321449. – ISBN 978-1-59593-803-9 YAGO : Yago. – URL http://www.mpi-inf.mpg.de/~suchanek/downloads/yago/ Zesch und Gurevych 2006 ZESCH, Torsten ; GUREVYCH, Iryna: Automatically creating datasets for measures of semantic relatedness. In: COLING/ACL 2006 Workshop on Linguistic Distances. Sydney, Australia, 2006, S. 16–24. – URL http://www.ukp.tu-darmstadt.de/sites/www.ukp. tu-darmstadt.de/files/datasets.zip Zesch und Gurevych 2007 ZESCH, Torsten ; GUREVYCH, Iryna: Analysis of the Wikipedia Category Graph for NLP Applications. In: Proceedings of the TextGraphs-2Workshop (NAACL-HLT), URL http: //elara.tk.informatik.tu-darmstadt.de/publications/2007/hlt-textgraphs.pdf, 2007 Zesch u. a. 2007a ZESCH, Torsten ; GUREVYCH, Iryna ; M¨UHLH¨AUSER, Max: Analyzing and Accessing Wikipedia as a Lexical Semantic Resource. In: Biannual Conference of the Society for Computational Linguistics and Language Technology, 2007 Zesch u. a. 2007b ZESCH, Torsten ; GUREVYCH, Iryna ; M¨UHLH¨AUSER, Max: Comparing Wikipedia and German Wordnet by Evaluating Semantic Relatedness on Multiple Datasets. In: Proceedings of Human Language Technologies: The Annual Conference of the North American Chapter of the Association for Computational Linguistics (NAACL-HLT), URL http://elara.tk.informatik.tu-darmstadt. de/publications/2007/hlt-short.pdf, 2007 Zipf 1935 ZIPF, George K.: The Psycho-Biology of Language: An Introduction to Dynamic Philology. Boston : Goughton-Mifflin, 1935 ZipfR : ZipfR. – URL http://www.cogsci.uni-osnabrueck.de/~severt/zipfR/ Teil VI. Rechtliches Lizenz Urheber der vorliegenden Diplomarbeit ist Daniel Kinzler. Sie steht, mit der Zustimmung der Universität Leipzig in der Person von Prof. Dr. Gerhard Heyer, unter den GNU Free Documentation License (kurz GFDL, deutsch „GNU-Lizenz für freie Dokumentation“) Version 1.2 [GFDL] und darf, gemäß den Bestimmungen dieser Lizenz in dieser oder einer neueren Version, frei kopiert, verbreitet und/oder verändert werden (Veränderte Versionen sind, laut der Lizenz, als solche kenntlich zu machen). Die Arbeit wurde mit Hilfe des Textsatzsystems LATEXverfasst, der Quelltext ist unter /WikiWord/WikiWordThesis/Diplomarbeit/ auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/WikiWord/WikiWordThesis/ Diplomarbeit/> sowie als Archiv unter /WikiWordThesis-tex.tar.gz auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/WikiWordThesis-tex.tar.gz> verfügbar (siehe auch .G.5). Es gibt keinen vorderen oder hinteren Umschlagtext im Sinne der Lizenz. Eine Kopie des Lizenztextes der GFDL ist unter dem Titel GNU Free Documentation License enthalten. Bei Verbreitung der vorliegenden Arbeit in veränderter oder unveränderter Form sollen Titel und Urheberschaft der Originalversion wie folgt angegeben werden: Daniel Kinzler, Automatischer Aufbau eines multilingualen Thesaurus durch Extraktion semantischer und lexikalischer Relationen aus der Wikipedia, Diplomarbeit an der Abteilung für Automatische Sprachverarbeitung, Institut für Informatik, Universität Leipzig, 2008. Urheber des im Rahmen der vorliegenden Diplomarbeit entstandenen Softwarepaketes WikiWord ist Daniel Kinzler. Es steht, mit der Zustimmung der Universität Leipzig in der Person von Prof. Dr. Gerhard Heyer unter der GNU Public License Version 2 [GPL] und darf, gemäß den Bestimmungen dieser Lizenz in dieser oder einer neueren Version, frei kopiert, verbreitet und/oder verändert werden. Eine Kopie des Lizenztextes der GPL wird mit dem Quellcode von WikiWord mitgeliefert. Der Quellcode von WikiWord ist unter /WikiWord/ auf der beiliegenden CD oder online unter <http://brightbyte.de/DA/WikiWord/> verfügbar, siehe .G.3 für eine Aufstellung von Archivdateien. Sämtliche Texte, die aus der der Wikipedia übernommen wurden, und im Rahmen der vorliegenden Diplomarbeit verfügbar gemacht werden, stehen unter der GNU Free Documentation License (GFDL) Version 1.2. Sie sind als solche speziell gekennzeichnet und mit einem Verweis auf die erforderlichen Daten zur Urheberschaft versehen. Die Gesamtheit der Wikipedia ist möglicherweise als Datenbankwerk zu betrachten. Sie ist dann ein Gemeinschaftswerk (Collective Work) aller mitwirkenden Autoren und steht ebenfalls unter der GFDL. Statistisch ermittelte Daten, die aus der Wikipedia als Gesamtwerk abgeleitet werden, genießen mangels Schöpfungshöhe keinen eigenen urheberrechtlichen Schutz, sind gegebenenfalls aber als Bearbeitung (Derivative Work) der Wikipedia als Datenbankwerk anzusehen. 208 GNU Free Documentation License Version 1.2, November 2002 Copyright © 2000,2001,2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The purpose of this License is to make a manual, textbook, or other functional and useful document “free” in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. 1. APPLICABILITY AND DEFINITIONS This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as “you”. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law. A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. 209 A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called “Opaque”. Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only. The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work’s title, preceding the beginning of the body of the text. A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve the Title” of such a section when you modify the Document means that it remains a section “Entitled XYZ” according to this definition. The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License. 2. VERBATIM COPYING You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies. 3. COPYING IN QUANTITY If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. 210 If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computernetwork location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document. 4. MODIFICATIONS You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement. C. State on the Title page the name of the publisher of the Modified Version, as the publisher. D. Preserve all the copyright notices of the Document. E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s license notice. H. Include an unaltered copy of this License. I. Preserve the section Entitled “History”, Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled “History” in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the “History” section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. K. For any section Entitled “Acknowledgements” or “Dedications”, Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. M. Delete any section Entitled “Endorsements”. Such a section may not be included in the Modified Version. N. Do not retitle any existing section to be Entitled “Endorsements” or to conflict in title with any Invariant Section. O. Preserve any Warranty Disclaimers. 211 If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles. You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various parties–for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version. 5. COMBINING DOCUMENTS You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections Entitled “History” in the various original documents, forming one section Entitled “History”; likewise combine any sections Entitled “Acknowledgements”, and any sections Entitled “Dedications”. You must delete all sections Entitled “Endorsements”. 6. COLLECTIONS OF DOCUMENTS You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document. 7. AGGREGATION WITH INDEPENDENTWORKS A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an “aggregate” if the copyright resulting from the compilation is not used to limit the legal rights of the compilation’s users beyond what the individual works permit. When the 212 Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate. 8. TRANSLATION Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail. If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title. 9. TERMINATION You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 10. FUTURE REVISIONS OF THIS LICENSE The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/. Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. Erklärung Ich versichere, dass ich die vorliegende Arbeit selbständig und nur unter Verwendung der angegebenen Quellen und Hilfsmittel angefertigt habe, insbesondere sind wörtliche oder sinngemäße Zitate als solche gekennzeichnet. Mir ist bekannt, dass Zuwiderhandlung auch nachträglich zur Aberkennung des Abschlusses führen kann. Ort und Datum Unterschrift