Projektgruppe
Intelligence Service
PG Bericht
24. September 2008
Veranstalter:
Lehrstuhl 8, Universita¨t Dortmund
Betreuer:
Prof. Dr. Katharina Morik
Dipl.-Inform. Felix Jungermann
Teilnehmer:
Baumann, Bjo¨rn
Bo¨hmer, Martin
Firstein, Roman
Fritsch, Regina
Gu¨nal, Emel
Gu¨ner, Mustafa
Kaz, Erkan
Koloch, Rafael
Kubatz, Marius
Viefhues, Alexander
Zhu, Qingchui

Inhaltsverzeichnis
1 Einfu¨hrung 17
1.1 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 Methoden der Named Entity Recognition . . . . . . . . . . . . . . . . . . . . 18
1.2.1 U¨bersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.2 Hidden Markov Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.2.3 Maximum Entropy Markov Models . . . . . . . . . . . . . . . . . . . . 37
1.2.4 Conditional Random Fields . . . . . . . . . . . . . . . . . . . . . . . . 38
1.3 Methoden der Indexierung und Information Retrieval . . . . . . . . . . . . . . 42
1.3.1 Indexierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
1.3.2 Suchmaschinen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
1.3.3 Lernende Suchmaschinen . . . . . . . . . . . . . . . . . . . . . . . . . 55
1.4 Maschinelle Lernverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
1.4.1 SVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
1.4.2 SVM struct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
1.4.3 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
1.5 Relation Extraction auf unstrukturierten Texten . . . . . . . . . . . . . . . . 86
1.5.1 Einfu¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
1.5.2 Anwendungsbeispiel: TEXTRUNNER . . . . . . . . . . . . . . . . . . 89
1.5.3 Dependency Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
1.5.4 SVM Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
1.5.5 Kernel Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
1.6 Semantic Role Labeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
1.6.1 Semantische Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
1.6.2 Automatisches Zuweisen von semantischen Rollen . . . . . . . . . . . . 101
1.6.3 CoNLL2005 - Shared Task . . . . . . . . . . . . . . . . . . . . . . . . . 112
1.6.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
1.7 Treebank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
1.7.1 Einfu¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
1.7.2 Verallgemeinerte Treebank . . . . . . . . . . . . . . . . . . . . . . . . 117
1.7.3 PropBank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
1.7.4 NomBank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
1.7.5 TIGER Baumbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
1.7.6 TIGERSearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
1.7.7 Event Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
1.8 Theorie der Fragebeantwortung . . . . . . . . . . . . . . . . . . . . . . . . . . 145
1.8.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
1.8.2 Fragekomplexita¨t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
1.8.3 Antworttypen-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
1.8.4 Ablauf der Fragebeantwortung . . . . . . . . . . . . . . . . . . . . . . 147
iii
1.9 TREC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
1.9.1 Was ist TREC? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
1.9.2 Durchfu¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
1.9.3 Welche Fragetypen gibt es? . . . . . . . . . . . . . . . . . . . . . . . . 148
1.9.4 Nugget-Pyramide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
1.9.5 ciQA-Durchfu¨hrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
1.9.6 Interaktion mit Nutzer . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
1.9.7 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
1.10 Dictionaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
1.10.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
1.11 Frageformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
1.11.1 Erga¨nzungsfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
1.11.2 Entscheidungsfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
1.11.3 Direkte Fragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
1.11.4 Indirekte Frage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
1.11.5 Offene Fragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
1.11.6 geschlossenen Fragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
1.11.7 weitere Fragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
1.11.8 statistischen-Fragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
1.12 Anwendungsbereich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
1.12.1 Aufbau und Themen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
1.12.2 IR relevante Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
1.12.3 Vorga¨nge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
1.12.4 Dokumente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
2 Systementwurf 177
2.1 Das System in prozessorientierter Sicht . . . . . . . . . . . . . . . . . . . . . . 177
2.1.1 Akquisition- und Extraktionssystem (AES) . . . . . . . . . . . . . . . 177
2.1.2 Fragebeantwortungssystem (FBS) . . . . . . . . . . . . . . . . . . . . 179
2.1.3 Prozessorientierung und UML . . . . . . . . . . . . . . . . . . . . . . . 179
2.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
2.2.1 Design Entscheidungen . . . . . . . . . . . . . . . . . . . . . . . . . . 179
2.2.2 Dekomposition der Architektur . . . . . . . . . . . . . . . . . . . . . . 180
2.3 Statisches Package Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
2.4 Das Repository und seine Datenstrukturen . . . . . . . . . . . . . . . . . . . 187
2.4.1 Das Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
2.4.2 Datenbanken und Verzeichnisse . . . . . . . . . . . . . . . . . . . . . . 188
2.4.3 Datenstrukturen und Dateiformate . . . . . . . . . . . . . . . . . . . . 191
2.4.4 Physikalische Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
2.5 Prozess Modell und Beziehungen zwischen den Subsystemen . . . . . . . . . . 195
2.5.1 Grundsa¨tzliches zu atomaren Prozessen . . . . . . . . . . . . . . . . . 195
2.5.2 Datenakquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
2.5.3 Prozesse der Informationsextraktion . . . . . . . . . . . . . . . . . . . 196
2.5.4 Fragebeantwortung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
3 Datenakquisition 205
3.1 Corpus-Erstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
iv
3.1.1 Umwandlung von PDF zu regular ASCII . . . . . . . . . . . . . . . . 205
3.1.2 Umwandlung von regular ASCII zu WTF . . . . . . . . . . . . . . . . 207
3.1.3 Der FileWorker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
3.2 Erstellen der Trainingsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
3.3 Sentence Splitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
3.3.1 Grundlegendes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
3.3.2 Problematik der Satzendeerkennung . . . . . . . . . . . . . . . . . . . 213
3.3.3 Satzenden in den Dokumenten des Dt. Bundestags . . . . . . . . . . . 214
3.3.4 Markierung von Satzenden . . . . . . . . . . . . . . . . . . . . . . . . 214
3.3.5 Betrachtung der Wo¨rter im Sliding Window Verfahren . . . . . . . . . 214
3.3.6 Satzendeerkennung mit Regular Expressions und Wo¨rterbu¨chern . . . 214
3.3.7 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
4 Informationsextraktion 217
4.1 Information automatische Extraction aus HTML . . . . . . . . . . . . . . . . 217
4.1.1 HTML Datei lesen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
4.1.2 Umwandlung von HTML mit einigen Regeln zu XML . . . . . . . . . 217
4.1.3 Benutze zum Umwandeln fu¨r MOPs mit HtmltoXml . . . . . . . . . . 217
4.1.4 IdErzeugen (PersonIdErzeugen.java) . . . . . . . . . . . . . . . . . . . 226
4.1.5 MOPsZugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
4.1.6 Seitenbeschaffung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
4.1.7 Automatischem Update . . . . . . . . . . . . . . . . . . . . . . . . . . 228
4.2 NER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
4.2.1 Entita¨ten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
4.2.2 Rapid Miner, IE-Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . 232
4.3 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
4.3.1 Allgemeine Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
4.3.2 Event-Schemata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
4.3.3 Relationen zwischen Events . . . . . . . . . . . . . . . . . . . . . . . . 242
4.3.4 Relation Extraction am Beispiel von Abstimmungen . . . . . . . . . . 244
4.4 Datenextraktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
4.4.1 Extraktion von Relationen zwischen Protokollen und Drucksachen . . 247
4.4.2 Vorgehensweise der Referenz-Extraktion . . . . . . . . . . . . . . . . . 249
4.4.3 Der umgedrehte Fall: BTD2BTP . . . . . . . . . . . . . . . . . . . . . 249
4.4.4 Extraktion von Reden . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
4.4.5 Der Prozess der Reden-Extraktion . . . . . . . . . . . . . . . . . . . . 251
4.4.6 Extraktion von Abstimmungen . . . . . . . . . . . . . . . . . . . . . . 254
4.4.7 Extraktion der Attribute aus Drucksachen . . . . . . . . . . . . . . . . 257
4.4.8 BundestagLookUp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
5 Systemkomponenten 262
5.1 Lexical Tree (L-Tree) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
5.2 Lucene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
5.3 WT2XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
5.4 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
5.5 Queryfacade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
5.5.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
v
5.5.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
5.5.3 Fragevorschau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
5.5.4 Fragebeantwortungssystem . . . . . . . . . . . . . . . . . . . . . . . . 280
5.6 Dossier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
5.6.1 Aufgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
5.6.2 Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
5.6.3 Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
5.6.4 GUI Design und Anwendungsfa¨lle . . . . . . . . . . . . . . . . . . . . 289
5.6.5 Anmerkungen zur Performanz und Anekdoten . . . . . . . . . . . . . 291
5.7 PartyNator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
5.8 Datensa¨tze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
5.8.1 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
5.8.2 Grafische Oberfla¨che . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
5.8.3 Anfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
5.8.4 .dat und .aml Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
5.9 Eigenentwicklungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
5.9.1 Event Cutter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
6 Fragebeantwortung 300
6.1 Manuelle Fragebeantwortung . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
6.1.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
6.1.2 Konkretes Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
6.2 Frage Eingabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
6.2.1 Freie Frageeingabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
6.2.2 Strukturierte Frageeingabe . . . . . . . . . . . . . . . . . . . . . . . . 305
6.3 Warum Fragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
6.3.1 Die Basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
6.3.2 Die Bedingung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
6.3.3 Der Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
6.3.4 Operatodetails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
7 Evaluation 309
7.1 Bewertung auf Grundlage der Aufgabenstellung . . . . . . . . . . . . . . . . . 309
7.2 Bewertung auf Grundlage der Website bundestag.de . . . . . . . . . . . . . . 310
7.2.1 Suche nach Textausschnitten . . . . . . . . . . . . . . . . . . . . . . . 310
7.2.2 Informationen u¨ber Abgeordnete . . . . . . . . . . . . . . . . . . . . . 310
7.2.3 Abgeordneten-Dossier . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
7.2.4 Fragebeantwortung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
7.2.5 PartyNator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
7.3 Optimierungsvarianten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Literaturverzeichnis 315
vi
Abbildungsverzeichnis
1.1 Wettervorhersage mit dem Markov Modell . . . . . . . . . . . . . . . . . . . . 25
1.2 Wettervorhersage mit dem Hidden Markov-Modell . . . . . . . . . . . . . . . 27
1.3 Forward-Rekursion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.4 Backward-Rekursion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.5 Viterbi-Decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.6 Baum-Welch-Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.7 NER mit Hilfe des HMMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.8 Graph mit Clique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.9 Suffix Baum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
1.10 Google Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.11 A und B sind Backlinks - C erreichbar durch Forwardlinks . . . . . . . . . . . 48
1.12 Eine Iteration der vereinfachten Rankingfunktion . . . . . . . . . . . . . . . . 49
1.13 Ein Kreis im Webgraph: Rank Sink . . . . . . . . . . . . . . . . . . . . . . . . 49
1.14 Architektur einer ALVIS Node . . . . . . . . . . . . . . . . . . . . . . . . . . 50
1.15 Document processing pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
1.16 Eine spezialisierte NLP Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
1.17 Linguistische Analyse eines Satzes . . . . . . . . . . . . . . . . . . . . . . . . 53
1.18 Zusammenspiel zwischen Document und dem Maintenance System. . . . . . . 54
1.19 die Suchergebnisse mit der Anfrage ’support vector machine’ . . . . . . . . . 56
1.20 Anfrage - Dokument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
1.21 Ranking-merge Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
1.22 trennende Hyperebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
1.23 Hyperebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
1.24 Breite der Hyperebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
1.25 Nicht linear trennbare Trainingsdaten . . . . . . . . . . . . . . . . . . . . . . 65
1.26 Beispiele fu¨r α-ξ Kombinationen . . . . . . . . . . . . . . . . . . . . . . . . . 66
1.27 Der Kern-Trick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
1.28 Relation zwischen zwei Objekten. . . . . . . . . . . . . . . . . . . . . . . . . . 87
1.29 Semantisches Netz (www.conroeisd.net) . . . . . . . . . . . . . . . . . . . . . 88
1.30 Chen und Bachmann Diagramme (de.wikipedia.org) . . . . . . . . . . . . . . 88
1.31 Darstellung des Extraction Graphen . . . . . . . . . . . . . . . . . . . . . . . 90
1.32 Inverted Index u¨ber dem Graphen . . . . . . . . . . . . . . . . . . . . . . . . 92
1.33 KNOWITNOW vs. TEXTRUNNER . . . . . . . . . . . . . . . . . . . . . . . 93
1.34 Dependecytree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
1.35 Erweiterter Dependecytree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
1.36 SVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
1.37 Die Darstellung der gewichte Funktion . . . . . . . . . . . . . . . . . . . . . . 98
1.38 Syntaxbaum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
1.39 Die Domain Communication aus der FrameNet-Datenbank . . . . . . . . . . 101
vii
1.40 Das Parse Tree Path Merkmal . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
1.41 Wahrscheinlichkeitsverteilungen in der finalen Version . . . . . . . . . . . . . 104
1.42 Verteilungsnetz / BackOff-Kombination . . . . . . . . . . . . . . . . . . . . . 104
1.43 Deep-Parse-System aus [PHK+05] . . . . . . . . . . . . . . . . . . . . . . . . 107
1.44 Shallow-Parse-System aus [PHK+05] . . . . . . . . . . . . . . . . . . . . . . . 108
1.45 Der Eintrag whisper aus dem Verblexikon . . . . . . . . . . . . . . . . . . . . 110
1.46 Das Eingabeformat fu¨r die CoNLL-2005 an einem Beispielsatz . . . . . . . . . 113
1.47 Vergleich der Systeme der CoNLL2005 . . . . . . . . . . . . . . . . . . . . . . 115
1.48 Chinesiche Wo¨rter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
1.49 Syntaxmehrdeutigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
1.50 Liste des POS-Taggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
1.51 Prozess des POS-Taggings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
1.52 Syntaxbaum und Pra¨dikate-Argument-Struktur . . . . . . . . . . . . . . . . . 122
1.53 Pyramide des NLPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
1.54 Das Mapping fu¨r eine Verbinstanz zu einem Frameset . . . . . . . . . . . . . 124
1.55 Dependency Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
1.56 U¨bereinstimmung des Interannotators . . . . . . . . . . . . . . . . . . . . . . 126
1.57 englisch-chinesische PropBank . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
1.58 Die Relation zwischen Lexika . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
1.59 Maximale Log-Wahrscheinlichkeit Algorithmus . . . . . . . . . . . . . . . . . 131
1.60 PropBank und Nombank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
1.61 NEGRA Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
1.62 TIGER-Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
1.63 Lexikalisch-funktionale Grammatik . . . . . . . . . . . . . . . . . . . . . . . . 135
1.64 Trigram-HMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
1.65 Cascaded Markov Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
1.66 TigerXML im Vergleich zum Syntaxbaum . . . . . . . . . . . . . . . . . . . . 139
1.67 TIGERSearch GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
1.68 Architektur des TIGERSearchs . . . . . . . . . . . . . . . . . . . . . . . . . . 140
1.69 Schritte des Partial Parsings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
1.70 Beispiel fu¨r die Zuordnung der Antworttypen . . . . . . . . . . . . . . . . . . 146
1.71 Ablauf der Fragebeantwortung mit verschiedenen Feedback-Loops . . . . . . . 147
1.72 Beispiel fu¨r Frageserie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
1.73 Vergleich Einzelperformance vs. Nugget Pyramid-Performance . . . . . . . . . 150
1.74 TREC2006 liefert uns 5 Vorlagen mit der gearbeitet werden kann . . . . . . . 151
1.75 Ergebnisse TREC 2007 QA-Track . . . . . . . . . . . . . . . . . . . . . . . . . 152
1.76 Automat mit Transition Jamming . . . . . . . . . . . . . . . . . . . . . . . . 154
1.77 Gesamte Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
1.78 Auflo¨sung von Mehrdeutigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . 156
1.79 Personendaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
1.80 Typen von Dictionaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
1.81 Reverse Stemming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
1.82 Startseite des Deutschen Bundestages. . . . . . . . . . . . . . . . . . . . . . . 162
1.83 Markierung von relevanten Daten im Profil eines Abgeordneten. . . . . . . . . 165
1.84 Der Bereich: Abgeordnete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
1.85 Mo¨gliche Abfragen des DIP (8-15 Wahlperiode) . . . . . . . . . . . . . . . . . 166
1.86 Formular zur Suche innerhalb der Vorga¨nge . . . . . . . . . . . . . . . . . . . 167
viii
1.87 Erweiterte Suche in den Aktivita¨ten im DIP21 . . . . . . . . . . . . . . . . . 168
1.88 Der Bereich: Abgeordnete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
1.89 Beispiel einer Drucksache mit relevanten Bereichen. . . . . . . . . . . . . . . . 174
2.1 Zwei Anwendungen in der prozessorientierten Sicht. . . . . . . . . . . . . . . 178
2.2 Komponentenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
2.3 JAVA Packages der Datenakquisition . . . . . . . . . . . . . . . . . . . . . . . 185
2.4 Packages der Informationsextraktion. . . . . . . . . . . . . . . . . . . . . . . . 186
2.5 Java Packages im Prozess der Fragebeantwortung. . . . . . . . . . . . . . . . 187
2.6 Datenstrukturen und Datenbanken im Repository . . . . . . . . . . . . . . . . 188
2.7 P00 - Datenakquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
2.8 [P01] - Erstellung der Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . 197
2.9 [P01] - Verarbeitung der Dokumente . . . . . . . . . . . . . . . . . . . . . . . 198
2.10 [P01] - Named Entity Recognition . . . . . . . . . . . . . . . . . . . . . . . . 198
2.11 [P01] - Aufbau der Indizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
2.12 [P01] - QueryFacade Datensa¨tze . . . . . . . . . . . . . . . . . . . . . . . . . 200
2.13 [P02] - Prozesse der Stichwortsuche . . . . . . . . . . . . . . . . . . . . . . . . 201
2.14 [P02] - Fragebeantwortung mit MOPS Query . . . . . . . . . . . . . . . . . . 201
2.15 [P02] - Partynator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
2.16 [P02] - Aufbau des Dossiers als Prozesse . . . . . . . . . . . . . . . . . . . . . 202
2.17 [P01] - QueryFacade und die
”
Warum“-Fragen . . . . . . . . . . . . . . . . . 203
3.1 PDF nach regular Ascii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
3.2 Ausschnitt einer Drucksache im PDF-Format . . . . . . . . . . . . . . . . . . 206
3.3 Die Drucksache nach der Umwandlung in das regular ASCII Format . . . . . 207
3.4 regular Ascii ins WTF-Format fu¨r das RapidMiner ie-Plugin . . . . . . . . . . 207
3.5 Die Drucksache im WTF-Format . . . . . . . . . . . . . . . . . . . . . . . . . 208
3.6 Das Menu¨ des FileWorkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
3.7 Das erweitere Menu¨ des FileWorkers, beim Filter PDF → WTF . . . . . . . . 210
3.8 Aufbau der Komponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
4.1 HTML Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
4.2 Automater um HTML Datei zu lesen . . . . . . . . . . . . . . . . . . . . . . . 218
4.3 Umwandlung von HTML zu XML . . . . . . . . . . . . . . . . . . . . . . . . 218
4.4 Umwandlung von HTML zu XML Level-1 . . . . . . . . . . . . . . . . . . . . 219
4.5 Umwandlung von HTML zu XML Level-2 . . . . . . . . . . . . . . . . . . . . 220
4.6 Umwandlung von HTML zu XML Level-3 . . . . . . . . . . . . . . . . . . . . 221
4.7 Umwandlung von HTML zu XML Level-4 . . . . . . . . . . . . . . . . . . . . 222
4.8 XMLSchema fu¨r MOPs.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
4.9 MOPsZugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
4.10 Format von Link in HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
4.11 Automater, um die Linke auszuziehen . . . . . . . . . . . . . . . . . . . . . . 229
4.12 Sequenz Diagramm fu¨r Automatischem Update . . . . . . . . . . . . . . . . . 230
4.13 Die NER Prozesskette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
4.14 Schematische Darstellung des Events Beschlussempfehlung . . . . . . . . . . . 241
4.15 Schematische Darstellung des Events
”
Abstimmung“ . . . . . . . . . . . . . . 242
4.16 Schematische Darstellung des Events
”
Zwischenruf“ . . . . . . . . . . . . . . 243
ix
4.17 Zu fu¨llendes Template fu¨r Event
”
Abstimmung“ . . . . . . . . . . . . . . . . 244
4.18 Schematische der Relationen im Event
”
Abstimmung“ . . . . . . . . . . . . . 245
4.19 Der Inhalt der XML-Index-Datei . . . . . . . . . . . . . . . . . . . . . . . . . 250
4.20 Beispiel fu¨r den Beginn einer Rede . . . . . . . . . . . . . . . . . . . . . . . . 252
4.21 Repra¨sentation der Rede in der XML . . . . . . . . . . . . . . . . . . . . . . . 252
4.22 Repra¨sentation der Rede mit Preludium und Aktuer . . . . . . . . . . . . . . 253
4.23 Zwischenrufe im PDF-Dokument . . . . . . . . . . . . . . . . . . . . . . . . . 253
4.24 Repra¨sentation der Zwischenrufe in Reden . . . . . . . . . . . . . . . . . . . . 253
4.25 Beispiel fu¨r eine typische Abstimmung innerhalb des Plenarprotokolls . . . . 254
4.26 Beispiel fu¨r die Relation zwischen Drucksache und Abstimmung . . . . . . . . 255
4.27 XML-Repra¨sentation der Abstimmungen . . . . . . . . . . . . . . . . . . . . . 256
4.28 Eine Beispieldrucksache mit Makierungen der Attribute . . . . . . . . . . . . 257
4.29 Die Beispieldrucksache im XML-Format des Btd-Indexes . . . . . . . . . . . . 258
4.30 Die XML fu¨r den BundestagLookUp . . . . . . . . . . . . . . . . . . . . . . . 259
4.31 Die XML fu¨r den Auto-BundestagLookUp . . . . . . . . . . . . . . . . . . . . 261
5.1 L-Tree Datenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
5.2 Ha¨ufigkeiten (y-Achse) der Wortla¨ngen (x-Achse) in den Dokumenten des Sys-
tems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
5.3 Aufbau des Lucene Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
5.4 Startseite der Grafischen Benutzer-Schnittstelle . . . . . . . . . . . . . . . . . 272
5.5 Serviceseite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
5.6 Abgeordneten Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
5.7 Serviceseite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
5.8 Dokumentensuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
5.9 Stichwortsuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
5.10 Dossier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
5.11 PartyNator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
5.12 Beispiel einer Entita¨tendefinition . . . . . . . . . . . . . . . . . . . . . . . . . 279
5.13 Beispiel einer QueryFacade Anfrage . . . . . . . . . . . . . . . . . . . . . . . 280
5.14 Eine beispielhafte Frage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
5.15 Vorschau des Schemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
5.16 Dossier im U¨berblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
5.17 Java Packages der Komponente Dossier . . . . . . . . . . . . . . . . . . . . . 287
5.18 Control und Entity Klassen des Dossiers . . . . . . . . . . . . . . . . . . . . . 288
5.19 Bildschirmfoto der Abgeordnetenauswahl und eines Dossiers . . . . . . . . . 289
5.20 Anwendungsfall Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
5.21 RMDatensatzBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
5.22 Ausschnitt des Event Cutters . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
6.1 Startseite des DIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
6.2 Sucheingabe im DIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
6.3 Titelu¨bersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
6.4 U¨bersicht eines Dokuments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
6.5 Stichwortsuche im Pdf Dokument . . . . . . . . . . . . . . . . . . . . . . . . . 303
6.6 Ergebnis der Stichwortsuche im Pdf Dokument . . . . . . . . . . . . . . . . . 303
6.7 Triggerwo¨rter in Plenarprotokollen . . . . . . . . . . . . . . . . . . . . . . . . 304
x
7.1 Mo¨glichkeiten der Anzeige von Abgeordneten auf bundestag.de . . . . . . . . 310
7.2 Filterung von Abgeordneten mit isie . . . . . . . . . . . . . . . . . . . . . . . 311
7.3 SQL Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
xi

Tabellenverzeichnis
1.1 Beispiele von Mehrdeutigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2 Beispiele fu¨r Merging-Operationen . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3 Vergleich mit Suchmaschinen . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
1.4 Methodenvergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
1.5 Vergleich der SVM Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
1.6 Oberfla¨chenkasus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
1.7 Ergebnisse des probabilistischen Semantic Role Labeling . . . . . . . . . . . . 105
1.8 Vergleichsergebnisse aus [PHK+05] . . . . . . . . . . . . . . . . . . . . . . . . 107
1.9 Ausgangsdaten fu¨r SRL-MEM Beispiel . . . . . . . . . . . . . . . . . . . . . . 109
1.10 Ausgangsdaten fu¨r SRL-MEM Beispiel . . . . . . . . . . . . . . . . . . . . . . 110
1.11 Der Frame-Matching Schritt am Beispiel . . . . . . . . . . . . . . . . . . . . . 111
1.12 Ergebnisse des Unsupervised Semantic Role Labelings . . . . . . . . . . . . . 112
1.13 Auszug der Merkmalstypen ausgewa¨hlter Systeme in der CoNLL-2005 . . . . 113
1.14 Ein Beispiel vom Frameset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
4.1 Verteilung der NER Entita¨ten am Beispiel eines manuell getaggten Bundes-
tagsprotokolls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
4.2 Ergebnisse von NER-Testla¨ufen auf einem WTF-Dokument . . . . . . . . . . 237
4.3 Ergebnisse der erweiterten NER-Testla¨ufe auf zwei markierten Protokollen . . 248
4.4 Performance der automatischen Triggersuche (mit Preprocessing und NER) . 248
4.5 Performance der automatischen Triggersuche (nur NER) . . . . . . . . . . . . 248
4.6 Performance der automatischen Triggersuche (nur Preprocessing) . . . . . . . 248
4.7 Performance der automatischen Triggersuche mit scharfer Abrenzung (nur Pre-
processing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
5.1 Allgemeine Form der .dat Datei . . . . . . . . . . . . . . . . . . . . . . . . . . 296
5.2 Ausschnitt aus Ausschuss.dat . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
xiii

Listings
1.1 SVMstruct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
1.2 COP-K-Means . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
1.3 SVMStruct Version2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.1 HTML-Page.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
4.2 XML-Event am Beispiel
”
Antrag“ . . . . . . . . . . . . . . . . . . . . . . . . 239
5.1 WT2XML Klassen 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
5.2 WT2XML Klassen 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
5.3 WT2XML 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
5.4 WT2XML 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
5.5 WT2XML 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
5.6 WT2XML 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
5.7 WT2XML 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
xv

1 Einfu¨hrung
1.1 Aufgabenstellung
Ziel der PG ist das automatische Erstellen eines Pressespiegels fu¨r eine bestimmte Person
(z.B. einen Politiker) oder eine bestimmte Firma aus dem Internet bzw. aus Datenbanken.
Daraus sollen dann gezielt Antworten auf bestimmte Fragen extrahiert werden. Methoden zu
einem solchen Intelligence Service werden untersucht und implementiert. Allerdings ist das
Spektrum der Informationen fu¨r eine einzige Anfrage hierbei zu gross. Das Problem ist, die
interessanten Daten zwischen den uninteressanten Daten herauszufinden. Dies ist das Pro-
blem des Information Retrieval. Der zu entwickelnde Intelligence Service soll natu¨rlich u¨ber
das Information Retrieval von Suchmaschinen hinausgehen. Das grundsa¨tzliches Problem ist,
dass Suchmaschinen nicht konkrete Antworten liefern. Vielmehr wird eine Auswahl an Do-
kumenten geliefert, die die Antwort zu gestellten Anfrage ho¨chstwahrscheinlich entha¨lt. Was
man aber oft mo¨chte, ist auf eine Frage wie:
Welcher Bundeskanzler stellte als letztes das Misstrauensvotum?
Antwort: Gerhard Schro¨der (zusammen mit der URL, auf der die Information gefunden wur-
de, zu erhalten.)
Fu¨r solche Fragebeantwortung muss man nicht nur die relevanten Dokumente finden, sondern
auch die relevanten Passagen,dies ist ein weiterer Punkt, der von Suchmaschinen nicht er-
bracht wird. Wenn die Dokumente durch eine Auszeichnungssprache (XML) annotiert sind,
ist die Suche in den relevanten Dokumenten erleichtert, so dass gezielt etwa nach Investitio-
nen, Erfolgen, neuen Produkten, Bo¨rsenzahlen gesucht werden kann. Die meisten Dokumente
sind aber nicht annotiert. Man muss also algorithmisch nach Entita¨ten eines bestimmten Typs
(z.B. Person, Ort, Firma) suchen. Das Gebiet, das sich mit der Erkennung der Entita¨ten eines
inhaltlichen Typs in Texten befasst, ist die Named Entity Recognition (NER) und verwendet
statistische Verfahren und solche des maschinellen Lernens bzw. Data Mining. Somit ist die
NER ein weiterer Bereich, mit dem sich die PG befassen muss. Die Abfolge von Anfragen soll-
te jedoch automatisiert erfolgen, um ein allgemein nutzbares System zu schaffen. Fu¨r Politiker
bietet sich hierfu¨r beispielsweise die Internetseite Bundestag.de an. Hier sind zu jedem Ab-
geordneten die jeweiligen Biographien hinterlegt. Zusa¨tzlich zu diesen offensichtlichen Daten
kann man jedoch auch noch die digital vorliegenden Drucksachen (z.B. Antra¨ge) und Proto-
kolle verarbeiten. Nach durchgefu¨hrter NER u¨ber diesen Dokumenten sollen dann konkrete
Fragen beantwortet werden.
17
1.2 Methoden der Named Entity Recognition
1.2.1 U¨bersicht
Definition und Zielsetzung
Zielsetzung der Named Entity Recognition ist es, bestimmte Bestandteile eines natu¨rlich-
sprachlich verfassten Text, also Zeitungsartikel, Dossiers oder auch E-Mail, zu erkennen und
einer vorgegebenen Kategorie zuzuordnen. Diese Bestandteile nennt man auch Named En-
tities. Die Named Entities dienen in der Regel dazu wichtige Fragen, die an einen natu¨rlich-
sprachlichen Text gestellt werden, zu beantworten. Was? Wann? Wo? und Wer? sind dabei
typische Fragen, die mit der Named Entity Recognition gekla¨rt werden ko¨nnen.
Die Besonderheit dieser Named Entities ist ihre Einmaligkeit, denn u¨blicherweise handelt es
sich dabei um eine Person, Organisation oder einen Ort. Angaben also, die in der Regel definit
sind und nur einmal vorkommen. Beispielsweise ko¨nnte dem Begriff Angela Merkel eindeutig
die Klasse Person zugewiesen werden - es handelt sich also um ein Named Entity oder auch
Eigenname, wa¨hrend der Begriff Bundeskanzler/in nicht auf eine bestimmte Person hinweist,
somit also nicht klassifiziert wird. Wichtig ist also, dass nur relevante Informationen klassi-
fiziert werden, wobei sich die semantische Relevanz auf die Doma¨ne des Texts bezieht. Die
Relevanz kann durch die Auswahl passender Trainingsdaten sowie den Tags bestimmt wer-
den. Neben den oben aufgefu¨hrten Kategorien Person, Organisation und Ort geho¨ren auch
Zeitangaben sowie quantitative Aussagen zu den mo¨glichen Named Entities.
Hier nun ein kurzes Beispiel fu¨r eine mo¨gliche Ein- und Ausgabe eines NER-Systems:
Eingabe: Auch die widerspru¨chlichen Angaben daru¨ber, wie viel Geld Bohlen tatsa¨chlich am
11. Dezember 2006 gestohlen wurde, wollte das Landgericht Bochum kla¨ren.
Ausgabe: Auch die widerspru¨chlichen Angaben daru¨ber,
wie viel Geld <Person>Bohlen</Person> tatsa¨chlich am <Datum> 11. Dezem-
ber 2006 </Datum> gestohlen wurde, wollte das <Organisation> Landgericht
Bochum </Organisation> kla¨ren.
Geschichte der NER
Named Entity Recognition wurde durch die von der DARPA instituierten Message Under-
standing Conferences (kurz: MUC) bekannt. Die Message Understanding Conferences fanden
erstmals 1987 statt und hatten die Entwicklung besserer Information Extraction-Methoden
zum Ziel. Dabei gibt es eine Reihe von Teams, die alle an einem genau definierten Ziel, unter
Vorgabe der zu untersuchunden Texte, arbeiten. Die einzelnen Ergebnisse der Gruppen wer-
den an den Konferenztagen vorgestellt und ermo¨glichen so einen umfassenden Blick u¨ber den
aktuellen Stand der Technik.
In diesem Zusammenhang wurde Named Entity Recognition / Koreferenz erstmals 1995 in
der sechsten MUC als Ziel definiert. Das Forschungsgebiet ist in der Informatik also relativ
neu.
Evaluation
Um gute Programme zu entwickeln, beno¨tigt man ein Scoring-verfahren um die Qualita¨t des
Programms bemessen zu ko¨nnen. In der Named Entity Recognition haben sich dabei drei
18
immer wieder verwendete Evaluationsmaße etabliert. Alle Werte gehen davon aus, dass wir
den gesamten Korpus einer Datei oder eines Texts nach Named Entities durchsuchen.
Precision Unter Precision, oder zu deutsch Pra¨zision, versteht man die Anzahl der korrekt
klassifizierten Named Entities im Verha¨ltnis zu der Anzahl der vom Recognizer gefun-
denen Named Entities.
Precision =
AnzahlkorrektklassifizierterNEs
AnzahlNEsgefunden
(1.1)
Recall Recall ist die Ausbeute an Named Entities aus dem gesamten Dokument. Hier wird also
das Verha¨ltnis der Anzahl an korrekt klassifizierten Named Entities zu den insgesamt
im Text vorhandenen Named Entities betrachtet.
Recall =
AnzahlkorrektklassifizierterNEs
AnzahlvorhandenerNEsimKorpus
(1.2)
F-Measure Um beide Gro¨ßen, also Precision und Recall, zusammen betrachten zu ko¨nnen,
bildet man den ungewichteten harmonischen Mittelwert beider Werte und erha¨lt den so
genannten F-Measure [Rij79].
F −Measure =
2 ∗ Precision ∗Recall
Precision+Recall
(1.3)
Interne / Externe Evidenz
Jedes Merkmal zur Klassifikation eines Named Entity kann ganz grob in Interne und Externe
Evidenz aufgeteilt werden. So kann jedes Analyseverfahren in [1.2.1] eine der beiden Gruppen
aufgeteilt werden.
Interne Evidenz Verfahren der Internen Evidenz ziehen ihr Wissen nur aus dem betrachteten
Wort. Dies kann ein Eintrag in einem Lexikon (zum gesuchten Wort) sein [1.2.1], be-
stimmte Bestandteile eines Wortes oder auch die Großschreibung einzelner Buchstaben.
Wenn wir beispielsweise das Wort DARPA betrachten, ist es wahrscheinlich, dass es
sich hierbei um eine Organisation handelt, da alle Buchstaben groß geschrieben sind,
folglich es sich um eine Abku¨rzung handeln ko¨nnte.
Externe Evidenz Viele Verfahren der Internen Evidenz gelangen rasch an ihre Grenzen. So
unterscheidet sich rein syntaktisch eine Bank mit der Bedeutung einer Finanzeinrichtung
nicht mit der einer (Sitz-) Bank. Auch ein Lexikon wu¨rde an dieser Stelle nur viele
Mo¨glichkeiten anzeigen, aber kein Aufschluss daru¨ber geben, worum es sich nun wirklich
handelt.
Hier muss man weitergehen und den Kontext des Wortes betrachten. Der Kontext kann
einerseits der umschlossene Satz, aber auch ein ganzer Textabsatz darstellen. So ist der
Kontext Die franzo¨sische Stadt... ein eindeutiger Hinweis auf ein Named Entity der
Kategorie Ort.Zum Kontext geho¨ren aber auch die vorher bestimmten Named Entities,
die oftmals ebenfalls ein hilfreiches Indiz fu¨r eine mo¨gliche Einordnung liefern.
19
Mo¨gliche Analyseverfahren
Tokenisierung Bevor man einen Text bearbeiten und maschinell auswerten kann, muss man
ihn in seine einzelnen Bestandteile, den Token, zerlegen. Diese Aufsplittung gestaltet sich
bei den meisten Sprachen, beispielsweise englisch, deutsch oder spanisch, relativ einfach.
Man sucht nach Leerzeichen, die u¨blicherweise jedes Wort abgrenzen und erha¨lt damit
einen einzelnen Token. Wichtig bei der Tokenisierung ist allerdings auch, dass dies nicht
in allen Sprachen so einfach sein muss.
Im na¨chsten Schritt kann man anhand von Satzzeichen ( ‘.‘, ‘,‘, ‘?‘) die Struktur des
Texts erfassen und bekommt damit wichtige Informationen wenn es darum geht den
Kontext eines Worts zu untersuchen. Ausruf- oder Fragezeichen kann man hierbei als
deutlichen Hinweis fu¨r ein Satzende ansehen. Bei einem ‘.‘kann man sich dagegen nicht
immer sicher sein, dass es sich um das Ende eines Satzes handelt. Hier ist beispielsweise
auch eine Abku¨rzung mo¨glich (bzw. , e.V.,usw.) und man muss anhand des Kontexts
bzw. des syntaktischen Aufbaus das Satzende bestimmen.
Morphologische Analyse Die morphologische Analyse bedient sich sprachlicher Mittel um die
im ersten Schritt erfassten Token fu¨r die weitere Bearbeitung zu vereinfachen. Ein wich-
tiger Bestandteil der morphologischen Analyse ist das Stemming-Verfahren. Hierbei
werden Verben in ihre Stammform u¨berfu¨hrt um die Anzahl der Regeln, die in den
nachfolgenden Schritten zur Erkennung der Kategorie dienen, klein zu halten. So wird
aus ’schla¨ft’ ’schlafen’ und aus ’sprach’ ’sprechen’. Auch die Anzahl der Lexikoneintra¨ge
kann mit diesem Verfahren reduziert werden.
Ganz a¨hnlich kann man sich die Motivation fu¨r die Pra¨fix- und Suffix-Erkennung vor-
stellen. Auch hier geht es darum komplex zusammengesetzte Wo¨rter zu vereinfachen
und auf ihr Lemma zuru¨ckzufu¨hren.
Wichtig zu erwa¨hnen ist, dass dieser Schritt bei manchen Sprachen sehr wichtig sein
kann. Im Deutschen gibt es eine Vielzahl von morphologischen Vera¨nderungen eines
Wortes. Viele verschiedene Zusammensetzungen eines Wortes sind denkbar und mu¨ssen
hier beru¨cksichtigt werden. Gleiches gilt beispielsweise auch in der franzo¨sischen Spra-
che. Im Gegensatz dazu kann man bei der Betrachtung eines englischen Textes einen
Großteil dieser Verfahren wegfallen lassen und allenfalls noch ein Stemming von Ver-
ben durchfu¨hren. Die maschinelle Erfassung der Semantik eines Textes kann also in den
verschiedenen Sprachen deutlich variieren.
Lexikalische Analyse Die Lexikalische Analyse in der Named Entity Recognition ist ein einfa-
cher LookUp in einem vorbereiteten Lexikon. In den meisten Fa¨llen kann an dieser Stelle
schon eine eindeutige Kategorie fu¨r das Named Entity gefunden werden. So wird man
unter dem Stichwort Angela Merkel sicherlich nur eine mo¨gliche Kategorie-Zuordnung
zulassen, na¨mlich Person.
Da es sich hierbei allerdings um ein Verfahren der Internen Evidenz (1.2.1) handelt,
sprich es wird nur die Struktur des Wortes / Token betrachtet und nicht der Kontext,
ko¨nnen Mehrdeutigkeiten auftreten. Diese Mehrdeutigkeiten ko¨nnen nur aufgehoben
werden, wenn man sich den kompletten Satz, bzw. den ganzen Abschnitt ansieht und
nach mo¨glichen Relationen zur gesuchten Entita¨t Ausschau ha¨lt. Dies wird in der Syn-
taktischen Analyse gemacht.
Hier einige Beispiele fu¨r Mehrdeutigkeiten:
20
Wort Mo¨gliche Deutung
Essen Stadt in NRW oder Mahlzeit?
Bank Finanzeinrichtung oder Sitzmo¨bel?
Buchen Baum oder Imperativ von buchen. Bsp.: Buchen Sie mir einen Flug!
Hamburger Burger oder Einwohner von Hamburg?
Tabelle 1.1: Beispiele von Mehrdeutigkeiten
Syntaktische Analyse Um Mehrdeutigkeiten in der Struktur der Wo¨rter aufzuheben, kommt
man nicht umher den Kontext eines Wortes zu betrachten. Kleinra¨umig ist dies ein
Satz, im gro¨ßeren Maßstab kann man hier aber auch einen Textabschnitt betrachten.
Bei der Betrachtung des Kontexts geht es darum den Satz in syntaktische Bestandteile
zu zerlegen. Es geht dabei also um die Erkennung von Nomen, Verben, Pra¨positionen,
usw. Auch bereits erkannte und klassifizierte Named Entities geho¨ren zum Kontext und
ko¨nnen hilfreich sein, beispielsweise wenn es darum geht zwei gleiche Referenzen auf
ein Objekt aufzulo¨sen. So steht die Abku¨rzung IBM fu¨r International Business Machi-
ne. Beides sind Named Entities, die aber die gleiche Firma beschreiben. Anhand der
Abku¨rzung ko¨nnte man dies erkennnen.
Fu¨r die syntaktische Analyse eines Satzes werden in der Named Entity Recognition
Part-of-Speech Tagger eingesetzt. Diese weisen jedem Wort eines Satzes eine Wort-
klasse zu. Anhand von Kontextinformationen ko¨nnen hier Mehrdeutigkeiten aufgehoben
werden, wobei auch unbekannten Wortphrasen eine Wortklasse zugeteilt wird. TnT ist
ein relativ bekannter POS-Tagger und klassifiziert englische Wo¨rter mit bis zu 86% und
deutsche mit 89% Wahrscheinlichkeit zur richtigen Wortgattung.
Eine Alternative zum POS-Tagger wa¨re ein Full-Parsing, wo die Analyse einer Satz-
konstruktion u¨ber einen Parsebaum geschieht, der an kontextfreie Grammatiken ange-
lehnt ist und Wortgattungen aufgrund von Position und Vorkommen im Satz ableitet.
Allerdings ist dieses Verfahren sehr fehlerbehaftet und beno¨tigt viel Rechenzeit, weswe-
gen man es in der Regel nicht anwendet [AI99].
Doma¨nenspezifische Analyse In der Doma¨nenspezifischen Analyse geht es darum die Klas-
sifizierung durch Einbezug des Text-Themas - daher Doma¨nenspezifisch - zu verbessern.
Hierbei kommt insbesondere die Koreferenz-Auflo¨sung zum Einsatz. Die Aufgabe der
Koreferenz-Auflo¨sung ist die Erkennung von gleichen Referenzen innerhalb eines
Texts. Falls also am Anfang eines Texts von G.W. Bush die Rede ist und in spa¨teren
Abschnitten nur noch ‘Er‘vorkommt, muss erkannt werden, dass es sich hierbei um die
anfangs genannte Person handelt. Auch bei Organisationen/Firmen ist die Erkennung
dieser Personalpronomen wichtig um den Inhalt des Texts verfolgen zu ko¨nnen. Auch
temporale Referenzen mu¨ssen aufgelo¨st werden. So bedeutet die Phrase ‘um Viertel vor
Vier ‘genausoviel wie 15:45 Uhr.
Beim Merging geht es hingegen darum gegebene Named Entities zu verschmelzen, falls
es sich dabei um ein und dasselbe Objekt handelt. Hier einige Merging-Beispiele:
Systemarchitekturen
Listenbasierte Systeme Beim Entwurf einer Systemarchitektur fu¨r ein NER-System kann
man sich ganz einfach eine riesige Liste mit allen Named Entities vorstellen, die es gibt.
21
Abku¨rzung Referenz
IBM International Business Machine
Deutsche Bahn AG Die Bahn entla¨sst Mitarbeiter
USA United States of America
Hamburger Burger oder Einwohner von Hamburg?
Tabelle 1.2: Beispiele fu¨r Merging-Operationen
In dieser Liste mu¨ssten dann aber auch immer alle neuen Wortscho¨pfungen erga¨nzt,
sowie morphologische Varianten eines Wortes abgespeichert werden. (aus [CB03])
Wa¨hrend diese beiden Punkte noch relativ gut realisierbar sind, fu¨hren die mo¨glichen
Mehrdeutigkeiten dazu, dass ein Listenbasiertes Verfahren keine gute Option fu¨r die
Named Entity Recognition darstellt. Mann kann zwar nachschlagen, was ‘Essen‘alles
bedeuten kann, aber ohne Betrachtung des Kontexts wird es nicht mo¨glich sein, die
passende Kategorie der Entita¨t zu finden. Rein Listenbasierte Verfahren scheiden also
aufgrund der zu hohen Fehlerrate aus.
Regelbasierte Systeme Bei Regelbasierten Systemen definiert man anhand der Merkmale
der einzelnen Token Regeln, um das Einsortieren in Kategorien zu ermo¨glichen. Dabei
nutzt man morphologisches, lexikalisches, syntaktisches und doma¨nenspezifisches Wis-
sen aus, also alle Verfahren, die zur Bestimmung von Named Entities in Frage kommen.
Hat man eine Reihe von Regeln entwickelt kann man daraus eine Grammatik (kontext-
frei) entwickeln, die in Texten nach Named Entities sucht.
Im Gegensatz zu lernbasierten Verfahren beno¨tigt man hier allerdings spezielle Lin-
guisten fu¨r die Entwicklung der einzelnen Regeln. Diese Regeln werden dann an relativ
kleinen Trainings-Datensa¨tzen getestet und falls erforderlich korrigiert und wieder getes-
tet. Nach einigen Iterationen hat man so eine qualitativ gute Regelmenge zur Erkennung
von Named Entities zusammen. Insgesamt ist die Entwicklung von Regelbasierten Ver-
fahren zeitaufwa¨ndiger, da man hier sehr umfassende Grammatiken entwickeln muss.
Und auch hinsichtlich der Flexibilita¨t zeigen sich Regelbasierte Systeme eher nachteilig
im Vergleich zu Lernbasierten Verfahren. Hier kann man die Grammatik in der Regel
nicht schnell erweitern oder gar einige Teile vera¨ndern, da viele Regeln aufeinander auf-
bauen und transitiv abha¨ngig sind. Auch die Anpassung an eine neue Doma¨ne ist damit
wesentlich schwieriger. (siehe [Fel03])
Nachfolgend einige Beispiele wie solche Regeln aussehen ko¨nnen:
ˆ Aufeinanderfolgende Phrasen der Form ¡Wort¿¡Wort¿ GmbH deuten mit hoher
Wahrscheinlichkeit auf eine Firma / Organisation hin
ˆ Großgeschriebene Worte ko¨nnen Hinweise auf eine Firma oder Organisation sein:
NASA, ADAC, UNICEF
ˆ ‘denken‘ist, unabha¨ngig vom Tempus der Verbform, in der dritten Person immer
ein starker Hinweis fu¨r ein menschliches Subjekt
ˆ Vorkommen von ‘-burg‘, ‘-dorf‘, ‘-stadt‘deuten auf eine Ortsangabe aus dem deutsch-
sprachigen Raum hin
22
Lernende / Automatische Systeme Lernende oder Automatische Systeme nutzen statisti-
sche Verfahren oder Methoden des Maschinellen Lernens um in einem Textkorpus nach
Named Entities zu suchen. Im Gegensatz zu Regelbasierten Verfahren werden dabei
qualitativ und quantitativ hohe Anforderungen an Trainingstexte gestellt. Douglas E.
Appelt und David J. Israel beschreiben in ihrem Paper [AI99], dass man fu¨r jede Ver-
dopplung der Trainingsdatensa¨tze den F-Measure um 1,5 Punkte steigern kann. Dabei
ist die Auswahl der Trainingsdatensa¨tze entscheiden fu¨r das spa¨tere Verhalten des Re-
cognizers und kann mitunter schwieriger sein als das Entwerfen von Regeln fu¨r ein
Regelbasiertes System.
Zu den wichtigsten Verfahren des Maschinellen Lernens geho¨ren Hidden Markov Models
1.2.2, Maximum Entropy Markov Models 1.2.3, Conditional Random Fields 1.2.4 und
Support Vextor Machines 1.4.1. Jedes Verfahren wird mit den mo¨glichen Erweiterungen
weiter unten beschrieben.
Eine Gefahr bei Maschinellen Lernverfahren ist das so genannte Overfitting. Dabei
wird dergleiche Trainingstext immer und immer wieder gelernt, so dass eine U¨beran-
passung des Systems an den Datensatz vorkommen kann. Wird nun bei der Erkennung
ein thematisch anderer Datensatz verwendet, ist eine hohe Fehlerrate bei der Klassifi-
kation von Named Entities wahrscheinlich.
Vor- und Nachteile der Systemarchitekturen
Regelbasierte Systeme beno¨tigen aufgrund der einfachen Erstellung eines Parsebaums relativ
wenig Zeit zur Auswertung, wobei die Auswertungsergebnisse auf gleicher Ho¨he oder etwas
besser im Vergleich zu Lernbasierten Systemen sind. So ergab die Auswertung eines Wall
Street Journals in der siebten Message Understanding Conference einen Vorteil der Regelba-
sierten Systeme von 3,3 Prozentpunkten (93,7% vs. 90,4% gemessen an der Zahl der korrekt
klassifizierten NE [Fel03]).
Lernende Systeme sind hingegen wesentlich flexibler, wenn es darum geht, ein System zur
Laufzeit zu vera¨ndern. Wa¨hrend wir bei Regelbasierten Systemen viele Regeln einzeln anpas-
sen mu¨ssen, genu¨gt es die Parameter zu vera¨ndern und das System mit neuen Trainingstexten
zu fu¨ttern. Diese Flexibilita¨t zeigt sich auch hinsichtlich der Anpassung an verschiedene Spra-
chen.
1.2.2 Hidden Markov Model
Einleitung
Namensgeber dieses Modells ist sein Entwickler Andrei Andrejewitsch Markov (1856 - 1922),
der wesentliche Beitra¨ge zur Wahrscheinlichkeitstheorie und Analysis beisteuerte. Er berech-
nete 1913 die Buchstabensequenzen in russischer Literatur um die Notwendigkeit der Un-
abha¨ngigkeit fu¨r das Gesetz der grossen Zahlen nachzuweisen. Die Berechnungen konnten
zudem als Aussage u¨ber die Wohlgeformtheit der Orthographie von Buchstabenketten inter-
pretiert werden. Aus diesem Ansatz entwickelte sich ein allgemeines statistisches Werkzeug,
der sogenannte stochastische Markov-Prozess. Basierend auf dieser Methode findet eine An-
wendung in der NER1 statt.
1Named Entity Recognition
23
Markov-Prozess
Der Markov-Prozess wird allgemein synonym zur Markov-Kette verwendet, da sich die Ver-
teilungsfunktion zu einem beliebigen, auch nicht diskretem Zeitpunkt bestimmen la¨sst. In der
Computertechnik kommen die spezielleren Markov-Ketten zum Einsatz.
Markov-Kette
Eine Markov-Kette ist eine spezielle Klasse von stochastischen Prozessen. Man unterschei-
det bei Markov-Ketten zwischen diskreter und stetiger Zeit. Markov-Ketten in stetiger Zeit
werden meistens als Markov-Prozesse bezeichnet. Das System springt bei jedem Zeitschritt
von einem Zustand in den Na¨chsten, dem zeitlichen Fortschreiten liegt eine U¨bergangswahr-
scheinlichkeit zugrunde. Das Besondere an einer Markov-Kette ist die Eigenschaft, dass durch
Kenntnis einer begrenzten Vorgeschichte genauso gute Prognosen u¨ber die zuku¨nftige Ent-
wicklung mo¨glich sind, wie bei einer Kenntnis der gesamten Vorgeschichte des Prozesses. Im
Falle einer Markov-Kette erster Ordnung heißt das:
Die Zukunft des Systems ha¨ngt nur von der Gegenwart (dem aktuellen Zustand) und nicht von
der Vergangenheit ab. Um diese Eigenschaft anschaulich zu beschreiben sagt man auch, dass
eine Markov-Kette
”
geda¨chtnislos“ ist. Ausserdem besagt die Ordnungszahl einer Markov-
Kette, von wie vielen vorherigen Zusta¨nden der aktuelle Zustand abha¨ngt. Bei den Markov-
Ketten 1. Ordnung ha¨ngt der aktuelle Zustand und seine Ausgabe nur vom seinem vorherigen
Zustand ab, mathematisch ausgedru¨ckt:
P (qt = Sj |qt−1 = Si, qt−2 = Sk, . . .)
= P (qt = Sj |qt−1 = Si)
Um Markov-Ketten zu modellieren, mu¨ssen sie aus den folgenden Elementen bestehen:
ˆ die Menge der Zusta¨nde S = {s1, s2, . . . , sN}
ˆ aij ist die Wahrscheinlichkeit, dass das System in den Zustand sj u¨bergeht unter der
Vorraussetzung, dass das System sich im Zustand si befindet, wobei die Summe aller
U¨bergangswahrscheinlichkeiten in einem Zustand bzw. einer Zeile der Matrix zusammen
1 ergeben mu¨ssen.
aij = P (qt+1 = sj |qt = si), 1≤i, j≤N (1.4)
aij≥0,
N∑
i=1
aij = 1 (1.5)
ˆ Anfangswahrscheinlichkeitenvektor pi = {pii}, der den Anfangszustand des Systems
beschreibt.
24
Abbildung 1.1: Wettervorhersage mit dem Markov Modell
pii = P (q1 = si), 1≤i≤N (1.6)
Ein Markov-Modell ist eine Datenstruktur, die die no¨tigen Werte fu¨r die Steuerung einer
Markov-Kette bereitstellt. Hier beschreibt das urspru¨nglich einfache Modell Vorhersagen auf
Grundlage indirekter Evidenz (Hidden Markov-Modell).
Hier benutze ich das popula¨re Beispiel vom Markov-Modell, na¨mlich das System der Wetter-
vorhersage in Fig1.1, welches einfach mit zwei Zusta¨nden aufgebaut ist: Regen und Sonne.
U¨bergangswahrscheinlichkeiten:
P (Regen|Regen) = 0.3, P (Sonne|Regen) = 0.7
P (Regen|Sonne) = 0.2, P (Sonne|Sonne) = 0.8
A = {aij} =
(
0.3 0.2
0.7 0.8
)
Anfangswahrscheinlichkeiten:
P (Regen) = 0.4, P (Sonne) = 0.6
Nehmen wir an, dass wir eine Beobachtungsfolge der Zusta¨nde in unserem Beispiel errechnen
mo¨chten: {Sonne, Sonne, Regen, Regen}.
P (Sonne,Regen) = P (Sonne)P (Sonne|Sonne)P (Regen|Sonne)P (Regen|Regen)
= 0.6 ∗ 0.8 ∗ 0.2 ∗ 0.3
= 0.0288
25
Hidden Markov-Model
Heute finden wir die HMM-Technik u¨berall vor, wo (Zeit)seriendaten zu modellieren, zu inter-
pretieren und zu segmentieren sind und wo ein Erwerb umfangreicher Trainingsdatensamm-
lungen mit passendem Aufwand zu vollziehen ist. Sie bieten eine Vielfalt von technischen
Anwendungen. Einige bekannte Anwendungsgebiete sind:
ˆ Gen-Vorhersage
ˆ Spracherkennung und Mustererkennung
ˆ Signal-Verarbeitung
ˆ Neurobiologie
ˆ . . .
mit Hilfe von Hidden Markov-Modellen kann man nach bestimmten Sequenzen oder Mustern
in Daten suchen. Bei allen diesen Anwendungsmo¨glichkeiten werden bestimmte Muster in
grossen Datenmengen gesucht. Die Mustersuche in Datenbanken wird als Data-Mining be-
zeichnet.
Aus dem allgemeinem Markov-Modell ist mit dem Das Hidden Markov-Modell ein erweiter-
tes stochastisches Modell entwickelt worden, das sich durch zwei Zufallsprozesse beschreiben
la¨sst. Der erste Zufallsprozess entspricht dabei einer Markov-Kette, die durch Zusta¨nde und
U¨bergangswahrscheinlichkeiten gekennzeichnet ist. Die Zusta¨nde der Kette sind von außen
jedoch nicht direkt sichtbar (sie sind verborgen). Stattdessen erzeugt ein zweiter Zufallspro-
zess zu jedem Zeitpunkt beobachtbare Ausgangssymbole gema¨ß einer zustandsabha¨ngigen
Wahrscheinlichkeitsverteilung. Die Aufgabe besteht ha¨ufig darin, aus der Sequenz der Aus-
gabesymbole auf die Sequenz der verborgenen Zusta¨nde zu schließen.
Definition [LR89] ein Hidden Markov-Modell wird formal als Fu¨nftupel λ = (N,M,A,B, pi)
definiert:
ˆ N ist die Menge aller Zusta¨nde S = {s1, s2, . . . , sN} im HMM, die Zustandsvariable
Q = q1q2. . .qT annehmen kann.
ˆ M ist Merkmalsraum (oft als Ausgabealphabet bezeichnet), also der Definitionsbereich
von bi. Dieser kann diskret, oder kontinuierlich sein. Je nach dem ist bi eine Wahrschein-
lichkeit oder eine Dichte.
ˆ A = {aij} Zustandsu¨bergangsmatrix, wobei aij die Wahrscheinlichkeit angibt, dass nach
Zustand qi in Zustand qj gewechselt wird.
ˆ B = {b1, . . . , bn} Menge der Emissionswahrscheinlichkeitsverteilungen bzw. Dichten
ˆ bi(k) Wahrscheinlichkeit im Zustand qi die Beobachtung k zu machen
ˆ pi = {pii} Anfangswahrscheinlichkeitsverteilung mit
26
Abbildung 1.2: Wettervorhersage mit dem Hidden Markov-Modell
pii = P (q1 = si), 1≤i≤N (1.7)
Gegeben seien die passenden Werte von N , von M , von A, von B und von pi. Das HMM kann
als Generator verwendet werden, um eine Beobachtungs-Reihenfolge anzugeben, in der jede
Beobachtung Ot eins der Symbole von M ist und T die Zahl der Beobachtungen in der Folge
ist. Das unten genannte Verfahren kann verwendet werden als Generator von Beobachtungen
und als Modell dafu¨r, wie eine gegebene Beobachtungs-Reihenfolge durch ein passendes HMM
erzeugt wurde. Diese Schrittfolge[LR89] kann man genauer direkt unten einsehen.
1. wa¨hle Anfangszustand qi = si entsprechend Anfangszustandverteilung pi
2. Setze t = 1
3. Wa¨hle Ot = vk entsprechend Wahrscheinlichkeitsverteilung der Beobachtungssymbole
im Zustand si, d.h. bi(k)
4. Wechsle in den na¨chsten Zustand qt+1 = si entsprechend U¨bergangswahrscheinlichkeits-
verteilung aij fu¨r Zustand si
5. setze t = t+ 1, wiederhole Schritt 3, falls t < T , sonst endet dies Verfahren
In der vorherigen Vorstellung haben wir schon gesehen, wie das System der Wettervorhersage
mit Hilfe des allgemeinen Markov-Modells dargestellt wird und jetzt schauen wir uns das
erweiterte System in Fig.1.2, welches aus dem Markov-Modell evolviert ist, an.
Zwei Zusta¨nde vom Luftdruck:
niedrig oder hoch
Zwei Beobachtungen:
27
Regen und Sonne
U¨bergangswahrscheinlichkeiten:
P (niedrig|niedrig) = 0.3, P (hoch|niedrig) = 0.7
P (niedrig|hoch) = 0.2, P (hoch|hoch) = 0.8
A = aij =
(
0.3 0.2
0.7 0.8
)
Ausgabewahrscheinlichkeiten:
P (Regen|niedrig) = 0.6, P (Sonne|niedrig) = 0.4
P (Regen|hoch) = 0.4, P (Sonne|hoch) = 0.3
Anfangswahrscheinlichkeiten:
P (niedrig) = 0.4, P (hoch) = 0.6
Hier als Beispiel ko¨nnen wir versuchen, alle mo¨glichen Reihenfolgen der versteckten Zusta¨nde
anzunehmen:
P (Sonne,Regen) = P (Sonne,Regen, niedrig, niedrig)
+ P (Sonne,Regen, niedrig, hoch)
+ P (Sonne,Regen, hoch, niedrig)
+ P (Sonne,Regen, hoch, hoch)
Anschaulicher sollte ein Gedanke nach unserer Probe daher erzeugt werden. Die Berechnung
von P (O|λ) gema¨ß originaler Definition kann ziemlich groß sein, man betrachtet in diesem
Fall den Rechenaufwand auf O(NT ). Gibt es eine Methode, um diesen schlechten Fall zu
verbessern? In den folgenden Abschnitten werden wir konkreter darauf eingehen.
Drei klassische Problemstellungen bei den Anwendungen
Es gibt drei grundlegende Probleme, die gelo¨st werden mu¨ssen, damit das Hidden Markov-
Modell in der Real-Welt bei verschiedenen Anwendungen nu¨tzlich ist. Hier befindet sich noch
ein sinnvolles Online-Tutorium [Boy] fu¨r alle Interessenten.
28
1. Gegeben sei die Beobachtungsfolge O = O1O2. . .OT und ein Modell λ = (A,B, pi), wie
berechnet man die Wahrscheinlichkeit P (O|λ)?
2. Wie bestimmt man eine Zustandsfolge Q = q1q2. . .qT , die eine gegebene Beobachtungs-
folge O = O1O2. . .OT zu einem gegebenem Modell λ = (A,B, pi) besitzt?
3. Wie passt man die Modellparameter λ = (A,B, pi) an, wenn nur die Beobachtungsfolge
bekanntgegeben ist, um die Wahrscheinlichkeit P (O|λ) zu maximieren?
Die Wahrscheinlichkeit einer Reihenfolge von U¨berga¨ngen herauszufinden ist nu¨tzlich. Um die
Wahrscheinlichkeit einer Reihenfolge von Beobachtungen zu finden, welche als Evaluation
gekennzeichnet wird, kann in der Vorwa¨rts- und Ru¨ckwa¨rts- Richtung gerechnet werden (d.h.
vorwa¨rts von der ersten Beobachtung arbeiten oder von der letzten Beobachtung zuru¨ck zu
arbeiten).
Nachdem das oben genannte Problem gelo¨st worden ist, ko¨nnen wir nicht absichern, welche
Reihenfolge der Zusta¨nde fu¨r eine gegebene Reihenfolge von Beobachtungen vorgenommen
wird. Im allgemeinen ist es am effizientesten, die wahrscheinlichste Zustandflugbahn fu¨r eine
gegebene Reihenfolge von Beobachtungen zu scha¨tzen. Dieses Problem wird ha¨ufig als Deco-
dieren gekennzeichnet.
Eine andere allgemeine Anforderung ist, die Wahrscheinlichkeiten zu erlernen, die mit U¨ber-
ga¨ngen im System verbunden sind. Durch ein Repra¨sentativ-training wird seine passende
Reihenfolge gegeben anstatt seine U¨bergangswahrscheinlichkeiten direkt anzugeben. Die Idee
ist, den Raum von U¨bergangswahrscheinlichkeiten zu finden, der die Wahrscheinlichkeit der
Trainings-Reihenfolge maximiert. Dies ist das sogenannte Lernproblem.
Forward- und Backward-Algorithmus
Die Wahrscheinlichkeit der Beobachtungen O fu¨r eine spezifische Zustandsreihenfolge Q ist:
P (O|Q,λ) =
T∏
t=1
P (Ot|Qt, λ)
= bq1(O1)(×)bq2(O2). . .bqT (OT ) (1.8)
und die Wahrscheinlichkeit der Zustandsreihenfolge ist:
P (O|λ) = piq1aq1q2aq2q3 . . .aqT−1qT (1.9)
Die Wahrscheinlichkeit einer Beobachtungssequenz bei vorgegebenem Modell ist die Wahr-
scheinlichkeit fu¨r das Auftreten einer Beobachtungssequenz bei allen mo¨glichen Hintergrund-
sequenzen, die sich zur Gleichung 1.8 expandieren la¨sst.
P (O|λ) =
∑
alleQ
P (O|Q,λ)P (Q|λ) (1.10)
=
∑
q1,q2,...,qT
piq1bq1(O1)aq1q2bq2(O2)
. . . aqT−1qT bqT (OT ) (1.11)
29
Abbildung 1.3: Forward-Rekursion
Die Forward-Variable wird definiert als:
αt(i) = P (O1, O2, . . . , Ot, qt = si|λ) (1.12)
Forward Rekursion
1) Initialisierung:
α1(i) = P (O1, q1 = si|λ) = piibi(O1), 1≤i≤N (1.13)
Die Gesamtwahrscheinlichkeit, Zustand si im Zeitpunkt 1 zu erreichen, ist die Anfangswahr-
scheinlichkeit fu¨r si, multipliziert mit der Wahrscheinlichkeit, dass O1 ausgegeben wird.
2) Induktion:
αt+1(j) =
N∑
i=1
αt(i)aijbj(Ot+1), 1≤t≤T − 1, 1≤j≤N (1.14)
Die Gesamtwahrscheinlichkeit, Zustand sj im Zeitpunkt t+1 zu erreichen, ist die Summe
der Wahrscheinlichkeiten von einem beliebigen Zustand si in Zustand sj unter Ausgabe des
na¨chsten Symbols Ot+1.
3) Terminierung:
P (O|λ) =
N∑
i=1
αT (i) (1.15)
Die Gesamtwahrscheinlichkeit der Realisierung in Fig.1.3 ist die Summe der Wahscheinlichkei-
ten, zum Zeitpunkt T in einen beliebigen Zustand zu kommen. Daher ist der Rechenaufwand
30
Abbildung 1.4: Backward-Rekursion
auf N2T reduzierbar. Wir ko¨nnen also die Backward-Rekursion in Fig.1.4 analog machen. Die
Backward Rekursion wird in der Lo¨sung zum Problem 3 verwendet ist aber fu¨r das Problem
1 nicht notwendig.
Backward Rekursion
Wir definieren zuerst die Backward-Variable:
βt(i) = P (Ot+1, Ot+2, . . . , OT |qt = si, λ) (1.16)
1) Initialisierung:
βT (i) = 1, 1≤i≤N (1.17)
2) Induktion:
βt(j) =
N∑
j=1
βt+1(j)aijbi(Ot+1), 1≤i≤N, t = T − 1, T − 2, . . . , 1 (1.18)
3) Terminierung:
P (O1, O2, . . . , OT ) =
N∑
i=1
β1(i)piibi(O1) (1.19)
Viterbi-Algorithmus
Die Frage welche Hintergrundsequenz bei gegebener Beobachtungssequenz und Modell opti-
mal ist, bescha¨ftigt sich damit, die korrekte Zustandsabfolge zu finden. Das zweite Problem
ist mit Hilfe des Viterbi-Algorithmus lo¨sbar, wobei der P (Q,O|λ) maximal ist.
31
Der Viterbi-Algorithmus in Fig.1.5 ist eine Methode aus dem Gebiet der Dynamischen Pro-
grammierung. Die Idee war, dass δt(i) die ho¨chste Wahrscheinlichkeit, einen Suchpfad zum
Zeitpunkt n beschreibt. Dabei werden die ersten n Beobachtungen geza¨hlt und δt(i) landet
schliesslich im Zustand si.
δt(i) = max
q1,q2,...,qt−1
P (q1, q2, . . . , qt = i, O1, O2, . . . , Ot|λ (1.20)
Durch Induktion hat man die Beziehung
δt+1(j) = [max
i
δt(i)aij ]bi(Ot+1)
, Um die Zustandsfolge wieder zu gewinnen, speichert man auch gleichzeitig das Argument,
das die δt+1(j) fu¨r jedes t und j jeweils maximiert, in ein Feld Ψt(j)
Der gesamte Optimierungsvorgang
1) Initialisierung:
δ1(i) = piibi(Oi), 1≤i≤N (1.21)
Ψt(i) = 0 (1.22)
2) Induktion:
δt(j) = max
1≤i≤N
[δt−1(i)aij ]bj(Ot), 2≤t≤T, 1≤j≤N (1.23)
Ψt(i) = arg max
1≤i≤N
[δt−1(i)aij ], 2≤t≤T, 1≤j≤N (1.24)
3) Terminierung:
P ? = max
1≤i≤N
[δT (i)] (1.25)
q?t = arg max
1≤i≤N
[δT (i)] (1.26)
4) Optimale Zuru¨ckverfolgerung der Zustandsfolge:
q?t = Ψt+1(q
?
t+1), t = T − 1, T − 2, . . . , 1 (1.27)
EM-Algorithmus
Der EM-Algorithmus 2 ist ein allgemeines Verfahren zur Bestimmung von Maximum-Likelihood
Scha¨tzwerten von probabilistischen Modellen. Die Bezeichnung Algorithmus ist eigentlich ir-
refu¨hrend, da in der allgemeinen Definition des Verfahrens keine genauen Anweisungen fu¨r
Rechenschritte gegeben werden, wie es der Begriff des Algorithmus fordert, sondern nur eine
allgemeine Beschreibung des Verfahrens und seiner mathematischen Eigenschaften. Fu¨r jedes
32
Abbildung 1.5: Viterbi-Decoder
Abbildung 1.6: Baum-Welch-Algorithmus
33
Anwendungsgebiet muss daher ein EM-Algorithmus erfunden werden. Fu¨r Hidden Markov-
Models heißt dieser Algorithmus
”
Baum-Welch Algorithmus“ in Fig.1.6.
ξt(i, j), 1≤t≤T ; 1≤i, j≤N sei die Wahrscheinlichkeit, dass der U¨bergang zwischen Zustand si
und Zustand sj zur Zeit t (mit Forward-und Backward-Variable geschrieben) bei einer gege-
benen Realisation O genommen wird:
ξt(i, j) = P (qt = si, qt+1 = sj |O, λ) (1.28)
=
αt(i)aijbj(Ot+1)βt+1(j)
∑N
i=1
∑N
j=1 αt(i)aijbj(Ot+1)βt+1(j)
(1.29)
Weiterhin ist γi(t) =
∑N
j=1 ξt(i, j) die Wahrscheinlichkeit, dass Zustand i zum Zeitpunkt t
bezu¨glich O erreicht wird.
Im Estimation-Schritt werden nun die Erwartungswerte fu¨r die Anzahl der U¨berga¨nge pro
Kante berechnet:
ˆ
∑T−1
t=1 γi(t) ist die erwartete Anzahl von U¨berga¨ngen aus Zustand si bei Realisierung
O.
ˆ
∑T−1
t=1 ξt(i, j) ist die erwartete Anzahl von U¨berga¨ngen von Zustand si nach sj bei
Realisierung O.
Im Maximization-Schritt werden nun die Modellparameter neu berechnet anhand der Erwar-
tungswerte:
ˆ
pii = γi(1) (1.30)
Die neuen Anfangswahrscheinlichkeiten sind die Wahrscheinlichkeiten, dass Zustand si
zum Anfang der Zustandssequenz bezu¨glich O auftritt.
ˆ
aij =
∑T−1
t=1 ξt(i, j)
∑T−1
t=1 γi(t)
(1.31)
Die neue Wahrscheinlichkeit fu¨r einen U¨bergang von Zustand si nach Zustand sj ist die
erwartete Anzahl der U¨berga¨nge von si nach sj dividiert durch die erwartete Gesamtzahl
der U¨berga¨nge aus si durch die Normierung entsteht hier wieder eine Wahrscheinlichkeit
0≤aij≤1.
ˆ
bik =
∑T
t=1 γi(t)δk,Ot
∑T
t=1 γi(t)
(1.32)
2Expectation-Maximization Algorithmus
34
δk,Ot ist wie folgt definiert:
δk,Ot =
{
1; k = Ot
0; sonst
(1.33)
Die neue Wahrscheinlichkeit fu¨r die Ausgabe eines Symbols k im Zustand si ist die
erwartete Anzahl im Zustand si zu sein und dabei das Symbol k = Ot auszugeben,
dividiert durch die erwartete Anzahl, u¨berhaupt im Zustand si zu sein.
Damit wurde ein neues Modell λ = (A,B, pi) berechnet. Wie fu¨r den EM-Algorithmus allge-
mein gezeigt, gilt P (O|λ) ≥ P (O|λ).
Zeichenbasiertes NER mit Hidden Markov-Modellen
In einem Zeichenstrom kann mittels eines HMMs eine Named Entity erkannt und klassifiziert
werden. Interessant ist der Ansatz vorallem deswegen, weil er aufzeigt, wie wertvoll bereits
Teilsequenzen von Zeichen sein ko¨nnen fu¨r NER.
Das Ziel ist, zu einem gegebenen Text automatisch alle Wo¨rter mit den zugeho¨rigen Wortarten
zu annotieren. Wie beschrieben kann ein HMM diese Aufgabe lo¨sen, wenn seine Parameter
(A,B, pi) richtig gesetzt sind. Ein HMM muss also trainiert werden, indem man mithilfe eines
vorgetaggten Textes die Parameter so anpaßt, dass das HMM fu¨r die Wortfolgen in diesem
Text die richtigen Wortartfolgen mit mo¨glichst geringer Fehlerrate ausgibt.
Als Beispiel nehmen wir an, dass man den Wo¨rtern eines Textes ihre Wortarten zuweisen
mo¨chte. Alles was vorliegt, ist ein Text als eine Folge von Wo¨rtern. Einen solchen Text kann
man in Anna¨herung als eine Folge von zufa¨lligen Ereignissen interpretieren, zwar dass auf
eine Wortart mit einer bestimmten Wahrscheinlichkeit eine andere Wortart folgt, und fu¨r je-
de Wortart dann mit einer bestimmtenWahrscheinlichkeit ein konkretes Wort generiert wird.
Betrachtet man den Text als Ergebnis des gesamten Zufallsexperiments, so ist die Abfolge
der Wo¨rter erkennbar, nicht mehr die Folge der Wortarten, die die Wo¨rter generierte.
Ein Text kann also als ein Zufallsexperiment mit einer Menge von Zufallsvariablen
O1, . . . , OT , q1, . . . , qT gesehen werden. Die Werte der Oi ist die Folge der beobachtbaren Da-
ten (die Realisierung), hier sind die einzelnen Wo¨rter. Die Werte der qi sind die versteckten
Daten, na¨mlich die zu den Wo¨rtern geho¨rigen Wortarten.
Die zugrundeliegende Verteilung ist also eine gemeinsame Verteilung der Menge von Zu-
fallsvariablen {O1, . . . , OT , q1, . . . , qT }. Mit Hilfe des Hidden Markov-Modells ko¨nnen solche
Verteilungen modelliert werden.
Der Aufbau des HMM’s wurde schon erla¨utert. Pro Zustand, welcher vom HMM durchlau-
fen wird, wird ein Zeichen generiert bzw. ausgegeben. Jeder Zustand wird durch ein Tupel
bestehend aus Klasse (Person, Ort, Organisation)in Fig.1.7, welche den Offset im aktuellen
Wort angibt, identifiziert. Es gibt z.B. einen Zustand (Ort, 2) in welchem die Emission des
dritten Zeichens aller NE vom Typ ’Ort’ vorgenommen wird. Ein spezieller Endzustand (Ort,
L) wird fu¨r das Leerzeichen (Wortgrenze) zwischen zwei Wo¨rtern verwendet. Ferner wird ei-
ne Outputmodell der Form P (vk|vk−1. . .vk−N+1, sk) benutzt, wobei vk das aktuelle Zeichen
und sk der aktuelle Zustand ist - es handelt sich also um ein (zustandsabha¨ngiges) N-Gram.
35
Abbildung 1.7: NER mit Hilfe des HMMs
Die Anzahl der Zusta¨nde pro Klasse ist beschra¨nkt sich auf N ’regula¨re’ Zusta¨nde und dem
Endzustand.
Statistische Modelle jenseits des HMMs
Local-Berechnungs-Methoden (Forward- und Backward- , Viterbi-Algorithmus) erleichtern die
Analyse von großen Datenmengen, wenn eine Scha¨tzung von Emissionswahrscheinlichkeiten
vorhanden ist. Der EM-Algorithmus ist eine gute Wahl, wenn schnelle und nicht so pra¨zise
Ergebnisse gefordert sind.
ˆ HMM sind fu¨r die Klassifikation und Modellbildung insbesondere von Zeitreihen gut
geeignet.
ˆ Durch das Modell erha¨lt man viele Informationen u¨ber die modellierte Signalquelle.
Trotz erfolgreicher Einsa¨tze der einschla¨gigen HMM-Modellierungswerkzeuge in etlichen sym-
bolverarbeitenden KI-Anwendungen unterliegt das traditionelle Hidden Markov-Model einer
Reihe offenkundiger Schwachstellen und Einschra¨nkungen:
ˆ das endliche Zustandsinventar fu¨hrt zu dem endlichen Geda¨chtnis
ˆ die fixe Abha¨ngigkeitsstruktur der Zustandsvariablen
ˆ die eindimensionale Organisation der Ausgabedaten
ˆ insbesondere seine implizit exponentielle Zustandsverweildauer
welche in den nachkommden Abschnitte zur Vorstellung einiger Variationen des Themas HMM
gab: Maximum Entropy Markov Models, Conditional Random Fields.
36
1.2.3 Maximum Entropy Markov Models
Einleitung und Motivation
Das Internet u¨berha¨uft uns mit so vielen Informationen, dass es unmo¨glich ist in ku¨rzester
Zeit die gebu¨ndelten und erwu¨nschten Informationskerne zu filtern. Die Idee ein automati-
sches System zu entwickeln, hinter welchem eine bestimmte Struktur und verborgene Logik
steckt, la¨sst einen Lo¨sungsweg fu¨r das Problem aufblitzen. Ein Problem bleibt jedoch weiter-
hin bestehen: Der Computer kann niemals die freie Entscheidung des Menschen u¨bernehmen.
Aber ein automatisiertes System kann beliebig nah zur Menschenentscheidung approximiert
werden. Einer der Versuche Informationen aus dem Internet zu bekommen, ist das so ge-
nannte Hidden Markov Model (HMM), das Informationen syntaktisch liest und semantisch
bewertet. Dieses Modell ist im vorherigen Kapitel ?? erkla¨rt worden. Wir bescha¨ftigen uns
hier mit einer Verbesserung des HMM, dem so genannten Maximum Entropy Markov Models
(MEMM).
Von HMM zu MEMM
Wie kann man ein System entwickeln, so dass es Informationen aus dem Netz ausliest und auch
richtig bewertet? Wie man sieht, unterteilt sich dieses Problem in zwei Bereiche: syntaktisch
auslesen und semantisch bewerten. Das erste ist kein Problem, denn das Auslesen wird schon
mit einer 100-prozentigen Wahrscheinlichkeit richtig ausgefu¨hrt. Das gro¨ßte Problem ist, wie
man ausgelesene Informationen bewertet, weil in vielen Situationen gelesene Informationen
unterschiedlich bewertet werden ko¨nnen. Dies ha¨ngt von verschiedenen Faktoren ab. Dazu
geho¨rt auch der gesunde Menschenverstand, was eine Maschine nie lernen kann. Ein solches
System ist folgendermaßsen aufgebaut:
ˆ Man macht eine Stichprobe. Das heißt man nimmt per Hand eine gewisse Information
aus dem Web und bewertet sie selber. Es wird hier aber angenommen, dass der Mensch
per Hand die Information richtig bewertet.
ˆ Danach wa¨hlt man ein Scha¨tzungsverfahren und bestimmt eine Wahrscheinlichkeitsver-
teilung, wie eine bestimmte Information (z.B. Zeichen, Wort, Satz) bewertet wird. Je
besser dieses Scha¨tzungsverfahren ist, desto na¨her kann ein automatisches System zur
Menschenentscheidung approximiert werden.
Jetzt wiederholen wir kurz HMM und gehen dann zu MEMM u¨ber. Als Beobachtungen be-
zeichnet man die gelesene Information und als Zusta¨nde deren Bewertung. Folge von Beob-
achtungen und Zusta¨nden ist dann die ganze Information, bzw. die Bewertung. HMM hat
den Zusammenhang zwischen einer Beobachtung und deren Zustand, beispielsweise die U¨ber-
setzung aus dem Englischen. Eine Beobachtung wa¨re hier ein Wort und ein Zustand dessen
U¨bersetzung. Es ist aber klar, dass manche Wo¨rter verschieden u¨bersetzt werden ko¨nnen. Um
richtig zu u¨bersetzen ist es eventuell notwendig den kompletten Satz und die Satzstruktur zu
kennen, was dieses Modell nicht beru¨cksichtigt. Deswegen ist es schwach. Ein Modell, welches
dieses Verfahren nutzt, sind die so genannten Conditional Random Fields (siehe Kapitel ??).
Hier bescha¨ftigen wir uns mit einer etwas schwa¨cheren Variante, dem MEMM.
37
MEMM
Die Verbesserung ist die, dass die Bewertung der Beobachtung auch von der vorherigen Be-
wertung abha¨ngt. Man teilt P in |S| Funktionen auf: P
(
s|s‘, o
)
= Ps‘(s|o) , was so viel heißt
wie:
”
die Wahrscheinlichkeit, dass die Beobachtung o als Bewertung s ausgewertet wird, wenn
s
′
der vorherige Zustand ist“.
Maximale Entropie
Wie oben beschrieben macht man eine Stichprobe und berechnet die Wahrscheinlichkeit P fu¨r
die Testdaten. Als na¨chstes muss die Verteilung abgescha¨tzt werden. Hier bescha¨ftigen wir uns
mit einer Verteilung, die maximale Entropie hat. Maximale Entropie wird bei der gleichma¨ßi-
gen Verteilung erreicht. Anhand von errechneten Wahrscheinlichkeiten P fu¨r die Testdaten
wird die gesamte Verteilung abgescha¨tzt, die mit den Testdaten nicht im Widerspruch steht,
so dass eine minimale Anzahl von Annahmen getroffen wird. Dies ist die gesuchte Verteilung
mit der maximalen Entropie und P wird wie folgt berechnet:
Ps‘(s|o) =
1
Z(o,s‘) exp (
∑
a λafa(o, s))
mit Z(o, s‘) =
∑
s exp (
∑
a λafa(o, s)) . Die beiden Formeln sollten ohne Beweis angenommen
werden. Das bina¨re Feature b ist eine bina¨re Funktion, die einer Beobachtung den Wert
”
true“
oder
”
false“ zuordnet. Bsp.: Die Beobachtung ist ein Großbuchstabe. Die Beobachtung be-
steht aus sechs Worten. Man definiere folgende charakteristische Funktion:
f〈b,s〉(ot, st) =
{
1, wenn b(ot) ist true und s = st
0, sonst
Die Funktion hilft uns die Beobachtungen anhand ihrer Eigenschaften zu analysieren und P zu
berechnen. Wenn P schon berechnet wurde, was nun? Wie kommt man an die Zustandsfolge?
Viterbi Algorithmus
Man definiert die rekursive Variable:
δt+1(s) =
(max
s‘∈S
) {
δt(s‘) · Ps‘(s|ot+1)
}
wobei δt(s‘) die Wahrscheinlichkeit ist, dass die wahrscheinlichste Zustandsfolge bis zum ot
im s‘ endet. Es werden dynamisch alle δ-Werte berechnet. Somit errechnet sich die gesuchte
Zustandsfolge.
1.2.4 Conditional Random Fields
Einfu¨hrung
Im großen Bereich des Maschinellen Lernens ist das sogenannte Taggen von Sequenzen von
wichtiger Bedeutung. Hier geht es nicht um die Kennzeichnung von Wo¨rtern (Parsing) sondern
um die Zuordnung von Wo¨rtern zu Entity-Klassen. Dabei handelt es sich bei der Eingabe stets
38
um sequentielle Daten. Hierbei werden die Wo¨rter identifiziert und verschiedenen Entity-
Klassen wie LOCATION, PERSON und anderen zugeordnet. Das sogenannte Named Entity
Recognition (NER) ordnet genau diese Named Entities (NE) den Entity-Klassen zu. Die
Grundlage zur Identifizierung der Entities sind meistens Lexika. Allerdings reichen diese nicht
aus, da ein Wort zweideutig und somit zu mehr als eine Entity-Klasse zugeordnet werden
kann. Speziell durch die Verwendung von Conditional Random Fields (CRF) zur Named
Entity Recognition umgeht man bestimmte Probleme die mit vorher verwendeten Modellen
existieren.
Grundlagen
Bei CRF handelt es sich um eine Weiterentwicklung der Hidden Markov models (HMM)
und Maximum entropy markov models (MEMM). Dabei werden gezielt Nachteile (label bias
problem) der vorherigen Modelle vermieden. Als Grundlage fu¨r CRF dient hier ebenfalls die
Markov Random Fields (MRF). Dabei erfu¨llt ein MRF u.A. folgende Eigenschaften:
ˆ Graphisches Modell
ˆ Darstellbar als ungerichteter, azyklischer Graph gema¨ß G=(V,E)
ˆ Knoten aus V entsprechen den Labels
Desweiteren gilt stets die Markov-Eigenschaft. Das heißt, dass ein aktueller Zustand nur von
einer bestimmten Menge von Zusta¨nden abha¨ngt. Der in der Graphentheorie etablierte Begriff
der Clique ist hier das Stichwort. Konkret kann man sagen, dass ein Knoten bzw. ein Zustand
v nur von den Knoten abha¨ngt, die in der gleichen Clique sind wie v. Formal notiert kann
man schreiben:
P (yv|yw : v 6= w) = P (yv|yw : v ∼ w)
Wie oben beschrieben handelt es sich bei MRF um ein ungerichtetes graphisches Modell. Somit
ko¨nnen Vorga¨nger nicht eindeutig bestimmt werden. Durch eine geeignete Funktion muss
deshalb die bedingten Wahrscheinlichkeiten eines Zustandes, die u¨ber die Cliquen definiert
werden, errechnet werden. Dabei definiert man die Potentialfunktion u¨ber jede Clique ci im
Graphen und erha¨lt somit eine Menge von Potentialfunktionen gema¨ß:
Φ = Φci : Aci → R
+
Die Funktion liefert also eine Zahl ∈ R, die also auch Zahlen gro¨ßer als 1 liefern kann. Die
Gro¨ße der Zahl skaliert mit der Wahrscheinlichkeit einer Belegung der Clique. Somit ist die
Wahrscheinlichkeit einer Label-Sequenz wie folgt definiert:
P (y1, . . . , yn) =
1
Z
∗
∏
Φ
Φci
(
yi1 , . . . , yi|ci|
)
Durch einen weiteren Schritt wird durch einen Normalisierungsfaktor eine Zahl generiert die
Wahrscheinlichkeitskonform ist. Die Normalisierung wird durch folgende Funktion realisiert:
Z =
∑
Y n
[
∏
Φ
Φci
(
yi1 , . . . , yi|ci|
)]
39
Abbildung 1.8: Graph mit Clique
Conditional Random Fields
Bei CRF handelt es sich eigentlich um MRF. Der wichtige Unterschied allerdings ist, dass
hier eine gewisse Abha¨ngigkeit existiert. Formalisiert kann man folgendes festhalten:
P (y1, . . . , yn|x)
Hier kann man sehen, dass die Wahrscheinlichkeit der Label-Sequenz von x abha¨ngt. Deswei-
teren wird stets angenommen, dass der als Graph visualisierte CRF einer first-order Markov-
Kette entspricht. Dies bedeutet, dass eine Clique als ein Knoten interpretiert wird und einen
Vor- bzw. Nachfolger hat. Bei den Cliquen selbst handelt es sich um verbundene Labels.
Die enge Beziehung zu MRF spiegelt sich auch in der Potentialfunktion wider:
Φk(yi−1, yi, x, i)
Um die Versta¨ndlichkeit zu erho¨hen, kann man sich auf bina¨re Potentialfunktionen beschra¨nken.
Die Funktion sei erfu¨llt wenn sie 1 liefert bzw. nicht erfu¨llt wenn sie 0 liefert. Ein einfaches
Beispiel soll die formale Notation vereinfacht darstellen:
Sei Φ(yi−1, yi, x, i) = b(x, i) wenn yi−1 = [ORG] und yi = [LOC] dann ist b(x, i) = 1, genau
dann wenn Beobachtung an Position i das Wort
”
Deutschland“ ist, ansonsten 0.
Die bedingte Wahrscheinlichkeit gleicht der Notation wie bei den MRF. Deswegen kann man
die Formel folgender Form festhalten:
P (~y|~x) =
1
Z(~x)
∏
k
t∑
i=1
Φk (yi−1, yi, ~x, i)
wobei stets gilt: ~(x) = (x1, . . . , xn)
Beim CRF Graphen handelt es sich stets um einen Baum. Dementsprechend kann man das
Hammersley-Clifford-Theorem anwenden und die Formel fu¨r das Training mit den Sequenzen
vorbereiten:
P (~y|~x) =
1
Z(~x)
exp
[
∑
k
t∑
i=1
Φk (yi−1, yi, ~x, i)
]
40
Wie vorher erwa¨hnt wurde, erzeugt die unbehandelte Verwendung der Potentialfunktion Zah-
len, die nicht ins Wahrscheinlichkeitsuniversum passen. Erst durch den Normalisierungsfaktor
Z werden Ergebnisse e [0,1] geliefert und entsprechen damit einem Wahrscheinlichkeitswert.
Eine gute Label-Sequenz soll stets einer Zahl entsprechen die nahe 1 ist, eine schlechte Label-
Sequenz einer Zahl die nahe 0 ist.
Training
Der eingefu¨hrte Vektor ~λ, der die Potentialfunktionen unterschiedlich gewichtet, muss schließ-
lich Trainiert werden. Nur dann kann man gewa¨hrleisten, dass die Wahrscheinlichkeiten fu¨r ge-
gebene Trainingsbeispiele maximiert werden. Formal bildet man den maximum-log-likelihood
und maximiert diese Funktion. Um die Funktion weiter zu vereinfachen, summiert man die
Potentialfunktion u¨ber die Sequenzla¨nge:
Fk(~y, ~x) =
T∑
i=1
(Φk (yi−1, yi, ~x, i))
Letztendlich erha¨lt man eine Gleichung fu¨r die log-likelihood-Funktion. Wenn es zwischen den
Zusta¨nden im modellierten Graph und den Labels eine eins-zu-eins-Beziehung existiert, ist
die Konvexita¨t der Funktion gegeben und somit auch das Finden eines globalen Maximums.
Die Berechnungen erfolgen dann stets iterativ, indem bei jedem Schritt die Parameter der
maximum likelihood-Lo¨sung na¨her kommen, oder alternativ durch andere gradientenbasierte
Methoden.
Um die Berechnungen der bedingten Wahrscheinlichkeiten effizient durchzufu¨hren, werden
Matrizen verwendet. Bei Sequenzen mit n Labels werden genau n+1 Matrizen erzeugt und
betrachtet, also jeweils eine fu¨r jede Stelle und eine fu¨r die gesamte Beobachtungssequenz.
Jede Matrix hat die Form |Y | × |Y |, wobei Y das Zustandsalphabet darstellt. Formal kann
folgendes festhalten:
Mi(~x) =
[
Mi(y
′, y|~x)
]
, wobei gilt
Mi(y
′, y|~x) = exp
(
∑
k
λkΦk(y
′, y, ~x, i)
)
Die Formel fu¨r die Berechnung der Bedingten Wahrscheinlichkeiten kann nun folgendermaßen
festgehalten werden:
P (~y|~x,~λ) =
∏T+1
i=1 Mi(yi−1, yi|~x)
Z(~x,~λ)
Natu¨rlich sieht man hier wieder den Normalisierungsfaktor Z. Durch die Multiplikation aller
Matrizen werden alle aktiven Potentialfunktionen fu¨r alle mo¨glichen Label-Sequenzen berech-
net.
41
1.3 Methoden der Indexierung und Information Retrieval
1.3.1 Indexierung
Einfu¨hrung
Mit der Popularita¨t des Internets sind auch die Quellen der Dokumentensammlungen (Zei-
tungsartikel, Webseiten, Bibliographien, usw) gestiegen, die den Nutzern fu¨r die Informati-
onsgewinnung zur Verfu¨gung stehen. Somit ist auch die Frage entstanden, wie man in die-
ser großen Informationsmenge, auf effiziente Art und Weise, Dokumente finden kann, die
einem relevant erscheinen. Bewa¨hrt haben sich dafu¨r WebSuchmaschinen, welche den Nut-
zern als Hilfsmittel dienen, um bestimmte Dokumente in Sammlungen zu finden. Die Web-
Suchmaschinen liefern einen leichten und effizienten Zugang zu Informationen. Neben der
effizienten Suchfunktion sind Suchmaschinen auch fa¨hig Indexierungen vorzunehmen. Viele
ga¨ngige Suchmaschinen sind indexbasiert. Man stelle sich den Index wie das Schlagwortver-
zeichnis eines Buches vor. Durch sto¨bern im Index nach dem gesuchten Wort findet man
schliesslich den passenden Verweis auf eine Seite und schla¨gt diese dann auf. Vorteil hier-
bei ist mit Sicherheit die verku¨rzte Suchzeit. Im Folgenden soll vorgestellt werden, wie man
den Index als Datenstruktur konstruieren und verwalten kann. Zusa¨tzlich wird auf die In-
dexstruktur Inverted File na¨her eingegangen. Da im Internet eine erheblich große Menge an
Dokumenten zur Verfu¨gung steht, ko¨nnen auch die Indizes dementsprechend groß ausfallen.
Weiterhin soll gezeigt werden, wie man mit geeigneten Kompressionsverfahren die Indexgro¨ße
reduzieren kann. Den Abschluss bilden weitere Indexierungsverfahren: Das Signature File, das
Suffix Array, sowie das Suffix Tree Verfahren.
Index
Inverted Files Ein Index ist eine Datenstruktur, welche Ausdru¨cke auf Dokumente abbildet,
die sie enthalten. Die effizienteste Struktur, die zum Indizieren verwendet wird, ist das Inver-
ted File Verfahren. Es ist eine Sammlung von Listen, in denen alle Ausdru¨cke abgespeichert
werden, die in den Dokumenten vorkommen. Dabei unterscheidet man zwei Varianten des
Index. Zum einen den word-level Index, der anzeigt, an welcher Position ein Ausdruck im
Dokument vorkommt. Die zweite Variante ist der document-level Index, der nur die Informa-
tion speichert, ob ein Ausdruck in einem Dokument vorkommt. Hierbei wird also kein Hinweis
dafu¨r geliefert, an welcher Stelle der jeweilige Ausdruck erscheint. U¨blicherweise werden jedem
Dokument eine Menge von Ausdru¨cken (Termen) zugeordnet. Doch wie der Name Inverted
File verra¨t, findet hier eine Zuordnung der Dokumente zu einzelnen Termen statt. Gleichzeitig
werden Informationen u¨ber das Vorkommen eines Terms in den Dokumenten bereitgehalten.
Ein Inverted File besteht daher im wesentlichen aus einem Wo¨rterbuch, in dem alle vor-
kommenden Terme eines Dokuments abgelegt werden. Das Wo¨rterbuch bildet dann auf ein
sogenanntes Posting File ab, in dem die Dokumenten-ID (doc-id), also die Termvorkommen,
eventuell auch Wortpositionen, abgespeichert sind.
Der Vorteil einer solchen Datenstruktur ist der schnelle Zugriff auf Terme und Dokumen-
te. Daraus resultiert natu¨rlich eine kurze Suchzeit. Der Nachteil bei einer großen Anzahl an
Wo¨rtern, die in Listen abgespeichert werden mu¨ssen, ist der hohe Speicheraufwand. Durch
Erweiterungen des Index wird beabsichtigt eine Suche mo¨glichst effizient zu machen. Metho-
den wie Stemming oder Stopping beispielsweise sorgen dafu¨r, den Index klein zu halten. Mit
Stemming werden Wo¨rter auf ihre Stammform reduziert. Man betrachtet dabei also nicht
42
die Wo¨rter, sondern nur die Wortsta¨mme und trennt die Endungen eines Wortes ab, so dass
dann die Wo¨rter in ihrer Grundform im Index gespeichert werden. Mit Stopping werden
Pra¨positionen (die, von, bzw.,...) weggelassen, die wenig Aussagekraft haben. Dies ermo¨glicht
die Einsparung von Platz bei der Speicherung des Indexes. Daraus resultiert eine effizientere
Suche, da der Index kleiner ist. Eine andere Technik, die verwendet wird um die Gro¨ße des
Index klein zu halten, ist der Thesaurus. Ein Lexikon, in dem unterschiedliche Wo¨rter gleicher
Bedeutung zusammengefasst werden.
Indexkonstruktion Die Konstruktion eines Indexes, auch Invertierung genannt, beinhaltet
die folgenden 3 Schritte: Im ersten Schritt, dem Parsen der Dokumente, werden die Doku-
mente, die zu indizieren sind, von vorne bis hinten durchlaufen und eine Liste der Wo¨rter mit
der Dokumenten-id erstellt. Dabei ko¨nnen schon die Stopwo¨rter, die den Index unno¨tig ver-
gro¨ßern, ausgelassen werden. Nachdem man diese Liste alphabetisch mit Hilfe von Sortieralgo-
rithmen geordnet hat, werden Wo¨rter, die in der Liste doppelt vorkommen, zusammengefasst.
Durch die in der Liste angegebenen Dokumenten-ids ist das Vorkommen der Wo¨rter eindeutig
bestimmt. Beim Erstellen des Index ko¨nnen auch Probleme auftreten: Durch das Sortieren
des Index mu¨ssten alte unsortierte oder neue sortierte Daten auf die Platte abgelegt werden.
Dies wu¨rde kurzzeitig zu einem erho¨hten Speicherverbrauch fu¨hren.
Indexverwaltung Da die Aktualisierung eines Index meistens mit Neueinfu¨gungen von Wo¨r-
tern verbunden ist und selten Wo¨rter gelo¨scht werden, wa¨chst natu¨rlich auch die Gro¨ße des
Index enorm. Der Index wird meist in Speicher verwaltet. Dabei werden kurze, invertier-
te Listen in Speichern fester Gro¨ße verwaltet, lange Listen werden in zusammenha¨ngenden
Speicherbereiche variabler Gro¨ße abgespeichert. Jede invertierte Liste wird in einem Bucket
hinterlegt, da sie zu Beginn noch, als kurze Liste, hineinpasst. Doch mit dem Hinzufu¨gen
neuer Terme und dem Wachstum der Liste droht ein U¨berlauf des Buckets. Ist der U¨berlauf
geschehen, wird die a¨lteste darin enthaltene Liste zu einer langen Liste. Als Datenstruktur
fu¨r einen Index werden meist verkettete Listen genutzt. Diese ermo¨glichen eine dynamische
Speicherbelegung und ein einfaches Hinzufu¨gen von Ausdru¨cken in Dokumenten.
Indexoptimierung Wie schon erwa¨hnt kann der Index durch viele Eintra¨ge stetig wachsen.
In Kapitel 2 wurden Verfahren erla¨utert, die die Gro¨ße des Index reduzieren. Das Stem-
ming ku¨rzt Wo¨rter auf ihre Stammform ab und fasst diese in einem Wort zusammen (z.B.
wird ”neues”, ”neuem”, ”neuesten” abgeku¨rzt zu ”neu”). Wenn man in der Suchanfrage den
Begriff ”neu” eingibt, werden auch all die Dokumente ausgegeben, in denen das Wort neu
mit verschiedenen Endungen auftritt. Durch das Auslassen von Pra¨positionen, Artikeln, also
sogenannten Stopwo¨rtern, verringert sich der Speicherbedarf des Index.
Kompressionsverfahren
Es gibt aber auch andere Ansa¨tze mit denen man einen Index klein halten kann. Und zwar
sind dies Komprimierungsverfahren, die mittels geeigneter Kodierung zu einem erwu¨nschten
Ergebnis fu¨hren. Diese Kodierungsmethoden ermo¨glichen eine Reduzierung der Textgro¨ße auf
fast 50 Prozent. Daraus resultiert eine geringere Auswertungszeit von Anfragen. Zusa¨tzlich
kann in kurzer Rechenzeit ein Index erstellt werden.
43
Golomb-Code Der Golomb-Code wurde 1966 von Solomon W. Golomb vorgestellt. Dabei
handelt es sich um eine Darstellungsform fu¨r alle positiven Zahlen, einschliesslich der Null. Ein
großer Vorteil an diesem Kodierungsverfahren ist die Abspeicherung von Daten unbekannter
Gro¨ße. Es ermo¨glicht eine schnelle Kodierung und eine sparsame Nutzung des Speichers. Die
Idee des Golomb Ansatzes besteht darin, die darzustellende Zahl n durch den Quotienten
q, einen frei wa¨hlbaren Parameter b, und dem Rest r zu beschreiben. Dazu wird im ersten
Schritt der Quotient der Zahl n berechnet mit der simplen Formel
q =
⌊
n− 1
b
⌋
.
Das Ergebnis des Quotienten wird una¨r kodiert ausgegeben, an das Ende der Bitfolge wird
eine logische 0 angeha¨ngt. Im zweiten Schritt bestimmt man den Rest r der Zahl n mit Hilfe
der Formel:
r = n ∗ (q ∗ b)− 1.
Das Ergebnis wird nun bina¨r ausgegeben. Zum Abschluss ha¨ngt man den zweiten Teil des
Code-Wortes an das Ergebnis aus dem ersten Schritt und man erha¨lt das fertige Code Wort.
Zusa¨tzlich zum Golomb-Code gibt es noch den Rice-Code. Der Rice-Code ist ein Spezialfall
des Golomb-Code. Hierbei ist der Paramater b nicht frei wa¨hlbar, sondern eine Potenz von
zwei.
Weitere Indexierungsverfahren
Selbstversta¨ndlich gibt es auch weitere Ansa¨tze um Indexierung vorzunehmen. So sind das
Suffix Array, der Suffix Tree und die Signature Files Verfahren mit denen man einen Index
erzeugen kann.
Signature Files In einem Signature File ko¨nnen Eintra¨ge einer Datenbasis, welche eine be-
stimmte Bedingung erfu¨llen, effizient herausgefiltert werden. Vor allem große Textbesta¨nde
sind innerhalb kurzer Zeit nach Schlu¨sselwo¨rtern durchsuchbar. Die Signaturen selbst wer-
den durch die Abbildung von Wo¨rtern auf Bitstrings mittels Hash-Funktion erzeugt. Dabei
werden die Dokumente in einer Textdatei, die Signaturen in einer separaten Datei abgespei-
chert. Ein Vorteil gegenu¨ber dem Inverted File ist der geringe Speicherplatzbedarf. Jedoch ist
dieses Verfahren ineffizient fu¨r große Datenbanken. Ein Nachteil sind die falschen Eintra¨ge,
sogenannte False Drops, die herausgefiltert werden. Die Konstruktion eines Signature Files
erfolgt dadurch, das Dokument in logische Blo¨cke zu unterteilen. Fu¨r jeden Block werden die
einzelnen Signaturen gebildet, wobei jeder Block eine konstante Anzahl an Wo¨rtern hat.
Suffix Array Ein Suffixarray ist ein Array, welches die Suffixe, in lexikographischer Reihen-
folge angeben kann. Der Text ist als eine lange Zeichenkette abgespeichert. Jedes Teilstu¨ck
des Textes ist eindeutig durch seine Position bestimmt, wobei die Positionen im Text frei
wa¨hlbar sind. Der Vorteil des Suffixarrays als Index zu nutzen liegt darin, mo¨glichst schnell
jedes Teilwort innerhalb des Wortes zu lokalisieren. Durch die lexikographische Sortierung
ko¨nnen die Suffixe effizient mit Hilfe der bina¨ren Suche gefunden werden.
44
Abbildung 1.9: Suffix Baum
Suffix Tree Ein Suffix-Tree dient dazu, die Suffixe in einer baumartigen Struktur darzustel-
len. Die Suffixe enden als Blatt im Baum. Also hat ein Suffix-Tree soviele Bla¨tter wie eine
Zeichenkette Suffixe besitzt. Aus den inneren Knoten gehen mindestens zwei Kinder aus. Jede
Kante des Suffix-Trees definiert ein Teilwort der Zeichenkette.
Beispiel : acacb
1. Suffix= cacb
2. Suffix= acb
3. Suffix= cb
4. Suffix= b
1.3.2 Suchmaschinen
Einfu¨hrung
Neben den im vorherigen Abschnitt beschriebenen Indexierungstechniken zum Zugriff auf die
gespeicherten Dokumente, benutzen moderne Suchmaschinen Ranking-Verfahren um die Er-
gebnisse einer Suchanfrage zu sortieren. Diese Verfahren werden als Page-Ranking-Verfahren
bezeichnet, da sie die Linkliste der Ergebnisse einer Suchmaschine absteigend sortieren. Die
Relevanz einer Page dient hierbei als Sortierkriterium. Dieses Kriterium soll mo¨glichst objek-
tiv und maschinell berechenbar sein und das menschliche Interesse sowie die Aufmerksamkeit
widerspiegeln.
Page-Ranking-Algorithmen ko¨nnen in zwei Kategorien aufgeteilt werden. Semantisch un-
abha¨ngige, vor dem Indizierungsschritt ausfu¨hrbare Algorithmen, welche die Dokumente a
priori mit einem statischen Rank versehen und semantisch abha¨ngige Verfahren, welche nach
der Indizierung die Dokumente aufwa¨ndig verarbeiten, die teilweise sogar zur Query Zeit
ausgefu¨hrt werden.
45
Abbildung 1.10: Google Systemarchitektur
Die statischen Ranking-Verfahren erzeugen ein globales Ranking von Webseiten durch Analyse
der Verbindungsstruktur des Netzes. Sie betrachten nur die Topologie des Webgraphen und
ignorieren die Inhalte und den semantischen Kontext einer Webseite. Die Verweise auf andere
Webseiten sind die einzigen Informationstra¨ger.
Die zweite Kategorie, der semantischen Page-Ranking Verfahren, nutzt Informationen der mit
Meta-Daten angereicherten Dokumente. Durch aufwa¨ndiges Preprozessing extrahierte Meta-
Daten der Inhalte sind hier die Informationstra¨ger.
In diesem Abschnitt werden beide Ranking-Verfahren anhand zwei Suchmaschinen erla¨utert.
Google Architektur
Google ist zur Zeit die mit Abstand bekannteste und am ha¨ufigsten benutzte Suchmaschine.
Diese positive Entwicklung resultiert aus dem ausgewogenem Mix aus Performance, Benutzer-
freundlichkeit und Qualita¨t der Suchergebnisse. Lawrence Page und Sergey Brin, die beiden
Gru¨nder von Google beschreiben in ”Anatomy of a Large-Scale Hypertextual Web Search
Engine” [BP98] den Aufbau und die Einsatzmo¨glichkeiten Ihrer Suchmaschine, sowie in ”The
PageRank citation ranking: Bringing order to the Web” [BP98] das PageRank Verfahren zur
Analyse der Webtopologie.
Die System-Architektur von Google besteht aus mehreren miteinander kooperierenden Kom-
ponenten:
Die Crawler, ausgelegt auf gro¨ßtmo¨gliche Parallelita¨t, wandeln URLs u¨ber den Domain Name
Service (DNS) Requests in IP-Adressen um. Sie stellen mittels HTTP simultan, mehrere
Verbindungen mit den Server her, um die erreichten Pages herunterzuladen.
Im Repository wird der komplette HTML-Code jeder heruntergeladenen Page mit zlib kom-
primiert gespeichert.
46
Die Aufgabe des Indexers besteht im dekomprimieren und analysieren der gespeicherten Pa-
ges. Jede heruntergeladene Page bekommt eine DocID. Zusa¨tzlich werden Hits als Wortvor-
kommen in so genannten Hit Listen registriert. Die Hit Listen beinhalten Informationen u¨ber
das Auftreten eines bestimmten Wortes in einem bestimmten Dokument, einschließlich Posi-
tion, Schriftkegel und Hervorhebungen. Eine weitere wichtige Funktion des Indexers ist das
Abspeichern aller Links Page in einer Anchor Datei. Die Sonderbehandlung von Link in Doku-
menten ermo¨glicht Indexierung von Seiten, die aus Bildern, Programmen oder Datenbanken
bestehen.
Fu¨r jedes Dokument werden zwei Indizes erstellt, der Forward-Index ist bereits teilweise
sortiert und in einer Reihe von Barrels gespeichert. Die Barrels ermo¨glichen einen hohen
Grad an Parallelita¨t, der Index wird auf viele relativ kleine Barrels aufgeteilt. Jedes Barrel
beinhaltet also nur eine kleine Anzahl an WordIDs. Entha¨lt ein Dokument eine WordID, so
wird seine DocID in dem entsprechenden Barrel gespeichert. Der Datensatz entha¨lt zusa¨tzlich
eine Liste von WordIDs mit Hitlisten. Der Invertierte Index wird in den gleichen Barrels wie
der Forward-Index gespeichert, allerdings ist er bereits durch den Sorter verarbeitet worden.
Fu¨r jede gu¨ltige WordID entha¨lt das Lexicon einen Zeiger auf das entsprechende Barrel. Dort
befindet sich ein Zeiger auf eine DocList, die alle Vorkommen des Wortes in allen Dokumenten
zusammenfasst.
Im Document-Index werden alle zusa¨tzlichen Informationen u¨ber ein Dokument gespeichert.
Dabei entha¨lt jeder Eintrag den Dokumentstatus, einen Zeiger ins Repository, eine Doku-
mentpru¨fsumme und verschiedene Statistiken.
Die Sorter arbeiten kontinuierlich daran, den nach der DocID sortierten Forward Index in
einen nach WordID sortierten Inverted Index umzuwandeln.
Wa¨hrend das gesamte u¨brige System kontinuierlich daran arbeitet, die Datenbasis zu aktua-
lisieren und zu erweitern, ist der Searcher die einzige anfrageverarbeitende Komponente. Der
Searcher verarbeitet Suchanfragen, erzeugt Ergebnislisten und sortiert sie nach Relevanz.
PageRank
Lawrence Page und Sergey Brin beschreiben in ”The PageRank citation ranking: Bringing
order to the Web” [BP98] das von Google verwendete PageRank Verfahren zur Analyse der
Webtopologie. Dieses Verfahren basiert auf der Idee eines globalen Rankings von Webseiten,
dass durch Analyse der Verbindungsstruktur des Netzes erzeugt wird. Die Autoren nehmen
an, dass wichtige Seiten besonders oft von anderen Seiten verlinkt werden. Ein Webautor
signalisiert durch einen Link auf eine andere Seite die Bereitschaft eine andere Quelle in den
eigenen Inhalten zu zitieren.
Das Web ist ein mittels HTTP Protokoll realisiertes, virtuelles Netz aus HTML-Dokumenten,
die durch Hyperlinks miteinander verbunden sind. Das Verfahren nutzt diese Struktur in dem
es das Web als Graph betrachtet.
Webgraph - Es sei G = (V,E) ein gerichteter Graph mit:
ˆ V der Knotenmenge statischer Webseiten
ˆ E der Kantenmenge aus Hyperlinks
47
Abbildung 1.11: A und B sind Backlinks - C erreichbar durch Forwardlinks
Jeder Knoten des Webgraphen ist also ein HTML-Dokument, verbunden mit anderen Do-
kumenten durch Anchor Tags. Eingehende Kanten eines Dokuments bezeichnen wir als B
Backlinks oder ”inedges”, ausgehende Kanten als F Forwardlinks oder ”outedges”.
Der PageRank Algorithmus betrachtet die Backlinks einer Webseite, allerdings werden nicht
alle eingehenden Links gleich bewertet. Der Rank einer Seite ist die Summe der Ranks ihrer
Backlinks.
PageRank Sei u eine Webseite und ein Knoten in G
ˆ Fu die Menge aller Forwardlinks von u,
ˆ Bu die Menge aller Backlinks von u,
ˆ Nu = |Fu| die Anzahl aller Nachfolger von u
ˆ d soll Damping-Faktor zur Normierung des Ranks sein
ˆ E sei eine Initialbelegung des statischen PageRanks u¨ber alle Seiten.
R ist eine Rankingfunktion von u und ihrer Vorga¨ngerin v, der Form:
R(u) = d
∑
v∈Bu
R(v)
Nv
+ dE(u)
Der PageRank einer Seite u wird also rekursiv aus der Summe der PageRanks derjenigen
Seiten die auf u verweisen bestimmt. Allerdings wird nur eine einzige Verbindung zu u, an-
teilig zur der Menge aller Links betrachtet. Fu¨r die Analyse des Algorithmus betrachten wir
Adjazenzmatrix A des Webgraphen G mit:
ˆ av,u = 1Nv falls eine Kante von v nach u existiert.
ˆ av,u = 0 sonst.
PageRank Starte in R0 = E der Initialbelegung und laufe durch die folgende Schleife bis Rj
konvergiert.
ˆ Ri+1 ← ARi
48
Abbildung 1.12: Eine Iteration der vereinfachten Rankingfunktion
Abbildung 1.13: Ein Kreis im Webgraph: Rank Sink
ˆ d← ||Ri||1 − ||Ri+1||1
ˆ Ri+1 ← Ri+1 + dE
Ohne die Initialbelegung und den Damping-Faktor wu¨rde der PageRank bei jeder Iteration
zu den Senken fliessen. Also zu Seiten die auf keine anderen Seiten verlinken (Dangling-
Links) oder auf dem Webgraph Kreise bilden (Rank Sinks). Um den negativen Effekt der
Dangling-Links entgegenzuwirken, werden die PageRanks dieser Seiten erst berechnet, wenn
die eigentliche Berechnung bereits abgeschlossen ist. Seiten die durch gemeinsames Verlinken
auf dem Webgraph Kreise bilden und nur auf sich selbst verweisen, erzeugen eine Schleife in
der der Rank steigt aber nicht weiter verteilt wird, da dieser Kreis keine ausgehenden Kanten
besitzt.
Der Damping-Faktor, der stets zwischen 0 und 1 liegt, wirkt diesem Problem entgegen und
verringert den Ausmaß der PageRank-Weitergabe.
Das statische PageRank-Verfahren von Google ist Unabha¨ngig von den Inhalten einer Web-
seite. Der Algorithmus konvergiert schnell und liefert selbst nach wenigen Iterationen gute
Ergebnisse. Nach 45 Iterationen ist die PageRank-Berechnung von 161 Mio. Links abgeschlos-
sen. Bei Verdoppelung der Anzahl von Links konvergiert der Algorithmus bereits nach 52,5
Iterationen. Der Algorithmus wird zur Datenaufbereitung ausgefu¨hrt und schont Ressourcen
die zur Query-Zeit beno¨tigt werden.
Zusa¨tzlich la¨sst sich das Verfahren, wie in ”A Unified Probabilistic Framework for Web Page
Scoring Systems” von Diligenti, Gori etal. [al.04] beschrieben, auch probabilistisch als Random
Surfer Modell interpretieren.
49
Abbildung 1.14: Architektur einer ALVIS Node
ALVIS Superpeer Semantic Searchengine
Der vorangegangene Abschnitt bescha¨ftigte sich mit Suchmaschinen, die auf mo¨glichst genaue
Indexierung und Ranking angewiesen sind. Dieser Abschnitt bescha¨ftigt sich mit einer der
wenigen Suchmaschinen, die Methoden der Verarbeitung von natu¨rlichen Texten nutzen um
Inhalte zu analysieren und eine Wissensdatenbank aufzubauen. Das Open Source Projekt
ALVIS geho¨rt zu dieser neuen Kategorie der Suchmaschinen, die als Suchmaschinen der dritten
Generation, oder semantische Suchmaschinen bezeichnet werden.
Das nach einem allwissendem Zwerg aus der nordischen Mythologie benannte Projekt wurde
am 1. Januar 2004 ins Leben gerufen. Mehrere internationale Institute und Firmen beteiligten
sich wa¨hrend der Laufzeit an der Forschung und Entwicklung. ALVIS, Superpeer Semantic
Searchengine entstand unter der wissenschaftlichen Fu¨hrung von Wray Buntine und wur-
de von der Technischen Universita¨t Helsinki koordiniert. Das Projekt nutzt Open Source
Software und wurde zum gro¨ßten Teil auch als Open Source vero¨ffentlicht. Der durchge-
hende Open Architecture Ansatz, der XML als Datenformat benutzt, garantiert hohe Inte-
roperabilita¨t mit anderen Systemen. Das Projekt wurde nach drei Jahren erfolgreich ab-
geschlossen und kostete u¨ber 3,5 Millionen Euro. Der gesamte Projektverlauf wurde auf
www.opensourcesearchengine.org Dokumentiert und kann dort nachgeschlagen werden. [al.07]
ALVIS ist eine themen-orientierte, dezentrale, verteile Suchmaschine. Einzelne Instanzen die-
ser Suchmaschine, genannt Nodes, sammeln fokussiert Informationen u¨ber Dokumente und
Webseiten aus ihrer Wissensdoma¨ne. Wie in jeder anderen Suchmaschine, ko¨nnen diese In-
formationen vom Benutzer u¨ber ein u¨bliches Web Formular abgefragt werden. Das Ergebnis
besteht aus einer nach Relevanz sortierten Linkliste. Zusa¨tzlich stellt eine Node, mittels peer-
to-peer Technologie, ihr Wissen anderen Nodes zur Verfu¨gung. Diese Form von der Zusam-
menarbeit u¨ber peer-to-peer ermo¨glicht doma¨nenu¨bergreifendes, verteiltes Suchen.
Abbildung 1.14 zeigt eine typische Node, die grob aus vier Subsystemen besteht. [WLB05]
ˆ Das
”
Document system“ ist fu¨r die Sammlung und Indexierung von Dokumenten ver-
antwortlich.
50
Abbildung 1.15: Document processing pipeline
ˆ Das
”
Maintenance system“ erweitert und pflegt die Knowledge Base (KB).
ˆ Das
”
Runtime system“ stellt Dienste die mit dem Benutzer interagieren und Fragen
beantworten.
ˆ Das
”
P2P system“ ist eine Schnittstelle des
”
Runtime system“ und stellt die Kommu-
nikation mit anderen Nodes sicher.
Wie bereits erwa¨hnt, findet die Kommunikation mit dem Benutzer, sowie anderen Nodes im
”
Runtime system “ statt. Das
”
Runtime system “ ist damit ein Server Dienst, der sta¨ndig
zur Verfu¨gung gestellt wird. Dieser Dienst greift, um Anfragen beantworten zu ko¨nnen auf
das
”
Document system “ zu. Das
”
Document system “ ist fu¨r die Sammlung und Speicherung
von Dokumenten verantwortlich. Die Akquise neuer Dokumente geschieht u¨ber einen fokus-
sierten Crawler. Als Quellen dienen Webseiten, Datenbanken und MS Word Dokumente. Bei
der Akquise verha¨lt sich eine Node wie jede andere Suchmaschine, sie durchforstet die Quel-
len und indexiert die heruntergeladenen Daten. Diese werden in ein standarisiertes Format
transformiert und im Document repository abgespeichert.
Anders, als eine gewo¨hnliche Suchmaschine, nutzt sie bei der Datenaufbereitung bereits er-
worbenes Wissen um semantische Informationen hervorzuheben. (Cite: Wray Buntine etal.,
Final Activity Report, 2007. ) Dies geschieht durch mo¨glichst pra¨zises Tagging der gelese-
nen Webseiten. Gefundene Dokumente werden mit Hilfe der
”
Document processing pipeline“
verarbeitet und im
”
Documents repository“ abgelegt. Das
”
Document system“ nu¨tzt also
die Knowledge Base als Ressource. Das
”
Maintenance system“ wird periodisch bei Bedarf
eingeschaltet um aus den neu ankommenden Dokumenten Informationen zu extrahieren und
sie in der Knowledge Base zu speichern. Die so erzeugten linguistischen Ressourcen werden
wiederum vom
”
Document system“ zur Analyse der eingehenden Dokumente genutzt.
ALVIS Document processing pipeline
Das Herzstu¨ck von ALVIS ist die
”
Document processing pipeline“, sie spielt eine zentrale
Rolle in der Verarbeitung von Dokumenten innerhalb des
”
Document system“. (Abbildung
1.15) Sie besteht aus vier Stufen, die jeweils, wie in einer Pipeline u¨blich, die Ergebnisse des
51
Abbildung 1.16: Eine spezialisierte NLP Line
Vorga¨ngers nutzen. Gema¨ß dem dem Open Architecture Ansatz ist XML das gegebene Doku-
mentenformat. Jede Stufe erzeugt ein XML Dokument, welches mittels XLS Transformation
in ein vom Nachfolger lesbares Format transformiert wird. Die Pipeline soll in der gesamten
Verarbeitung die Dokumente anreichern und keine im Dokument enthaltenen Informationen
entfernen.
Die Document processing pipeline besteht aus vier hintereinander geschalteten Stufen. hin-
terfolgenden Komponenten:
WP7 Einem fokussierten Crawler, der auf ein bestimmtes Themengebiet konfiguriert werden
kann, spu¨rt auf und la¨dt die gefundenen Dokumente herunter. Die Inhalte werden in
ein XML Dokument umgewandelt und mit ein paar Meta Daten versehen.
WP5 Der linguistischen Analyse (NLP) - Einer Komponente, welche fu¨r die linguistische An-
notation eines Dokuments zusta¨ndig ist. Sie basiert auf der Natural Language Processing
Platform. [AN06] Wie in der Abbildung 1.16 gezeigt, handelt es sich hierbei um einen li-
nearen Prozess zu schrittweise Annotation von Webdokumenten unter Beru¨cksichtigung
von bereits vorhanden Ressourcen aus der Knowledge Base. Das Spektrum dieser Res-
sourcen sowie deren Aufbau ist sehr bereit gefa¨chert und variiert je nach Spezialisierung
der Suchmaschine. Man kann sie jedoch grob in Regelsammlungen, Ontologien und
Wo¨rterbu¨cher aufteilen. Durch die Annotation werden Dokumente mit semantischen
Informationen einer bestimmten Doma¨ne angereichert. Die Abbildung 1.16 zeigt eine
spezialisierten NLP Linie fu¨r Annotation im Bereich Biologie. Fu¨r das ALVIS Projekt
wurden mehrere NLP Linien erstellt, unteranderem fu¨r die Annotation von englischen,
chinesischen und slovakischen Texten. Durch die NLP Linie werden, je nach la¨nge mor-
phologische, syntaktische und semantische Informationen hinzugefu¨gt.
WP6 Der Resource Acquisition, die mit WP5 kooperiert um, als semi-automatischer Sammler
linguistischer und semantischer Daten, diese im Dokument repository abzulegen.
WP2 Einem Relevance System, der die Relevanz der vorhandenen Dokumente an Hand von
Rankingverfahren analysiert. Zusa¨tzlich beru¨cksichtigt das Relevance System die lin-
guistischen und semantischen Tags bei der Berechnung des Ranks.
52
Abbildung 1.17: Linguistische Analyse eines Satzes
WP3 Schließlich ist die Indexing Engine fu¨r die Indexierung der Dokumente zusta¨ndig. In-
teressanter weise unterstu¨tzt sie die von den vorhergegangenen Stufen erzeugten und
XML getaggten Dokumente.
WP9 Das User interface greift auf die von der Pipeline erzeugten Daten um Fragen zu beant-
worten. Wie bereits erwa¨hnt handelt es sich hierbei um Formulare in einer Webseite.
Linguistische Analyse
Die linguistische Analyse von Dokumenten ist abha¨ngig von der Spezialisierung der NLP, die
morphologische Analyse ist zum Beispiel nur fu¨r die Slovenische NLP verfu¨gbar. Die Named
Entity Recognition ist fu¨r englische, chinesische, franzo¨sische und auch fu¨r die spezialisierte,
biologische NLP vorhanden. Abbildung 1.17 zeigt die einzelnen NLP Schritte in umgekehr-
ter Rheinfolge, an Hand eines Satzes der durch die spezialisierte, biologische NLP annotiert
wurde. Eine generalisierte NLP die alle verfu¨gbaren Komponenten beinhaltet ko¨nnte folgen-
dermaßen aussehen:
ˆ Im ersten Schritt wird der Text u¨blicherweise segmentiert, also wortweise zerlegt,
ˆ im zweiten Schritt erfolgt die NER,
ˆ POS Tagging,
ˆ Term Tagging,
ˆ lexikalische Analyse und Chunking,
ˆ dann werden die die semantischen Abha¨ngigkeiten markiert.
ˆ Schließlich folgt die Markierung von semantischen Typen und Relationen sowie die
Auflo¨sung von Anaphern.
53
Abbildung 1.18: Zusammenspiel zwischen Document und dem Maintenance System.
Maintenance System
Wie im vorherigen Abschnitt beschrieben erzeugt das Document System am laufendem Band
XML Dokummente die mit semantischen Meta-Daten annotiert sind. Auf der anderen Seite
der Datenhaltung wird mit Methoden des maschinellen Lernens die vorhandene Knowledge-
base sta¨ndig erweitert. Das hierfu¨r zusta¨ndige Maintenance System erzeugt teilautomatisch
die entsprechenden Datenbanken.
Das [WP6] Maintenance System besteht aus fu¨nf Subsystemen die, wie in Abbildung 1.18
dargestellt, folgende Datenbanken mit Daten befu¨llen.
ˆ Die NER Pattern Datenbank speichert alle Suchmuster die zur Name Entity Recogni-
tion beno¨tigt werden. Das zusta¨ndige Subsystem, Supervised Learning of Name Entity
patterns, arbeitet u¨berwacht und entha¨lt ein Wo¨rterbuch mit mo¨glichen Named Enti-
ties.
ˆ Ein Classifier entha¨lt alle Muster die zur Segmentierung von Sa¨tzen verwendet werden
ko¨nnen.
ˆ Das Term extraction Subsystem erzeugt eine Terminologie.
ˆ Um Sa¨tze nach ihrer Syntax parsen zu ko¨nnen wird eine Sammlung von Grammatiken
beno¨tigt, diese wird von einem Subsystem vervollsta¨ndigt, welches gleichzeitig fu¨r die
Bildung der Ontologie zusta¨ndig ist. Mit der gebildeten Ontologie werden neue Aus-
dru¨cke gelernt und auf der anderen Seite die einzelnen Wo¨rter ihrem semantischen Typ
zugeordnet.
ˆ Zusa¨tzlich existiert eine Sammlung von Regeln zur Informationsextraktion und der Er-
kennung von Anaphern, diese wird von dem Semantic relation learning Subsystem er-
weitert.
54
Fazit
Eine verteilte, spezialisierte Suchmaschine die auf Peer-to-Peer Technologien aufbaut und
einen gemeinsamen Index verwaltet ist eine robuste und elegante Alternative zu den monoli-
thischen Strukturen auf dem Markt. Die Nutzung von maschinellen Lernverfahren in Bereich
der Verarbeitung von Dokumenten ist neu und wird sicherlich in der Zukunft o¨fters in dem
kommerziellen Sektor anzutreffen sein. Die ALVIS NLP Linie wurde in vielen Experimenten
besta¨tigt. Sie verha¨lt sich robust bei einer großen Anzahl von Dokumenten (55.000 Dokumen-
te, mit u¨ber 100 Millionen Wo¨rtern) selbst wenn die Dokumente in unterschiedlichen Sprachen
geschrieben wurden. Die extensive Nutzung von spezialisierten Ressourcen wurde auf einem
Corpus aus 300.000 wissenschaftlichen Zusammenfassungen im Bereich der Mikrobiologie ge-
testet. Allerdings so groß wie diese Zahlen auch klingen mo¨gen, die Zahlen sind sehr Klein im
vergleich zu den Millionen an Dokumenten die im Web gefunden werden ko¨nnen.
Fu¨r die Verwendung innerhalb der Doma¨ne des Bundestages mu¨sste zuna¨chst einmal eine
spezialisierte NLP Linie fu¨r die Verarbeitung von politischen Texten erstellt werden. Dies
wa¨re gleichbeutend mit Pionierarbeit auf zwei Gebieten, da keine deutsche NLP Linie exisitert.
Zusa¨tzlich mu¨sste das gesamte Maintenance System auf die Erstellung von deutschsprachigen
Ressourcen angepasst werden.
1.3.3 Lernende Suchmaschinen
Vorwort
Der vorliegende Abschnitt dient zu Lernenden Suchmaschinen. Er basiert auf einem Paper von
Thorsten Joachims [Joa02]. Das klassische Anwendungsgebiet der Lernenden Suchmaschinen
sind Literaturdatenbanken, die heute in Form Digitaler Bibliotheken zunehmend an Bedeu-
tung gewinnen. Lernende Suchmaschinen sind besonders popula¨r geworden durch die Anwen-
dung in Internet-Suchmaschinen; dadurch kommt jeder Internet-Nutzer mit IR-Methoden in
Beru¨hrung. Jeder, der eine dieser Anwendungen mehrmals genutzt hat, wird die wesentlichen
Unterschiede zwischen Suchmaschinen-Anwendungen und deren klassischer Datenbanksyste-
me leicht erkennen:
ˆ Meistens durchla¨uft der Prozess der Anfrageformulierung mehrere Iterationen, bis pas-
sende Antworten gefunden werden.
ˆ Anfragen liefern potentiell sehr viele Antworten, aber nur wenige davon sind fu¨r den
Nutzer interessant.
ˆ Das vorgenannte Problem entscha¨rft sich durch die vom System bereitgestellte Rang-
ordnung der Antworten, wodurch potentiell relevante Antworten geha¨uft am Anfang der
Rangliste auftauchen (z.B. betrachten bei Internet-Suchmaschinen mehr als 90% aller
Nutzer nur die ersten 10 Antworten)
Was ist eine lernende Suchmaschine?
Zur Definition des Gebietes legen wir hier die Beschreibung der Aufgaben und Ziele dar. Eine
lernende Suchmaschine ist eine Suchmaschine mit ku¨nstlicher Intelligenz, die selbststa¨ndig
lernt, fu¨r wen etwas interessant sein ko¨nnte, indem sie die Benutzer befragt.
55
Abbildung 1.19: die Suchergebnisse mit der Anfrage ’support vector machine’
Trainingsdaten
Eine Lernende Suchmaschine braucht Trainingsdaten, damit sie lernen kann. Die Trainings-
daten ko¨nnen durch die Anfragen der Besucher automatisch erzeugt werden. Sie werden durch
eine Datengruppe Trio(q, r, c) dargestellt.
ˆ q: Anfrage
ˆ r: Die Rangliste der Suchergebnisse
ˆ c: URL-Liste, die der Benutzer gewa¨hlt hat.
Um die Definition von Trio(q, r, c) besser zu verstehen, sehen wir ein Beispiel mit Anfrage
’support vector machine’. Die Anfrage ’support vector machine’ liefert 10 Antworten, aber
nur 1, 3, 7 sind fu¨r den Nutzer interessant (siehe Abb.1.19).
Bei dem Beispiel sind:
ˆ q: ’support vector machine’
ˆ r: Liste (1,2,3,4,5,6,7,8,9,10)
ˆ c: (1,3,7)
56
Welche Informationen sind relevant?
Was ko¨nnen die lernenden Suchmaschinen durch die Trainingsdaten lernen? Bei dem Beispiel
(Abb.1.19) hat der Benutzer 1, 3, 7 gewa¨hlt. Es ist aber nicht sicher, dass 1, 3, 7 absolut re-
levant sind. Aber man kann die relativ relevanten Dokumente bestimmen. Der Benutzer hat
nach dem Rang2 den Rang3 gelesen. Ja, Rang3 ist wahrscheinlich relevanter als Rang2, da
man ihn mit einer Relation r∗ darstellen kann link3 < r∗ link2. Analog kann man die ganze
Relation r∗ aus dem Beispiel (Abb.1.19) bestimmen:
link3 < r∗ link2 link7 < r∗ link2
link7 < r∗ link4
link7 < r∗ link5
link7 < r∗ link6.
Die Relation r∗ hat also partielle Information der gesuchten Sortierung der Suchergebnisse.
Darstellung der Relation < r∗
Fu¨r eine Suchergebnisliste gibt es m Dokumente D = {d1, . . . , dm}. Die Relation r∗ kann man
mit einer Matrix M darstellen.
((M ⊂ D ×D))
(di < r∗ dj) =⇒ (Mij = 1 und Mji = 0)
Bei dem Beispiel (Abb.1.19)
M=







− ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗
∗ − 1 ∗ ∗ ∗ 1 ∗ ∗ ∗
∗ 0 − ∗ ∗ ∗ ∗ ∗ ∗ ∗
∗ ∗ ∗ − ∗ ∗ 1 ∗ ∗ ∗
∗ ∗ ∗ ∗ − ∗ 1 ∗ ∗ ∗
∗ ∗ ∗ ∗ ∗ − 1 ∗ ∗ ∗
∗ 0 ∗ 0 0 0 − ∗ ∗ ∗
∗ ∗ ∗ ∗ ∗ ∗ ∗ − ∗ ∗
∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ − ∗
∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ −







.
(* unbekannt)
Die Funktion fu¨r lernende Suchmaschinen
Mit den Trainingsdaten mu¨ssen die lernenden Suchmaschinen eine Funktion finden, damit
die Dokumente gut sortiert werden ko¨nnen. Um die Suchergebnisse zu verbessern, muss die
Qualita¨t der Funktion zu beurteilen sein. In der Statistik ist Kendall’s τ sehr oft benutzt
worden, um 2 Range zu vergleichen.
Fu¨r 2 Range (ra ⊂ D ×D) und (rb ⊂ D ×D),
P ist die Anzahl der u¨bereinstimmenden Paare,
Q ist die Anzahl der nicht u¨bereinstimmenden Paare, ist dann Kendall’s τ definiert durch:
τ =
P −Q
P +Q
= 1−
2Q
(m2 )
(1.34)
Um die Kendall’s τ besser zu verstehen, sehen wir folgendes Beispiel fu¨r 2 Ra¨nge ra und rb:
ra : d1 <ra d2 <ra d3 <ra d4 <ra d5
rb : d3 <rb d2 <rb d1 <rb d4 <rb d5.
Die Anzahl der nicht u¨bereinstimmenden Paare Q ist 3 ({d2, d3}, {d1, d2}, {d1, d3}). Und die
57
Anzahl der u¨bereinstimmenden Paare P ist 7. Damit kann man τ durch die Definition errech-
nen:
τ =
P −Q
P +Q
=
7− 3
7 + 3
= 0, 4. (1.35)
Wenn Q=0, hat τ Maximum 1. Und umgekehrt hat τ Minimum -1. rf(q) ist das System
mit der die Frage q aus der Rangliste ausgelesen wird. τ(rf(q), r∗) ist dann die Qualita¨t der
Suchergebnisse einer Funktion f nach der Anfrage q. Man kann die τ(rf(q), r∗) als die Pra¨zision
der Suchergebnisse betrachten. Ist τ(rf(q), r∗) groß, ist somit die Pra¨zision der Suchergebnisse
dann ebenfalls groß.
Wir sind jetzt in einer Position um das Problem na¨her zu definieren. Das Ziel ist die Funktion
fu¨r die zu erwartenden Kendall’s τ
τp(f) =
∫
τ(rf(q), r
∗)dPr(q,r∗) (1.36)
fu¨r eine feste, aber unbekannte Verteilung Pr(q, r∗) von Abfragen und Zielgruppen eine
Rangliste auf einer Dokumentensammlung D mit maimal m Dokumenten. Wa¨hrend das Ziel
des Lerners nun definiert ist, bleibt die Frage offen, ob es mo¨glich ist, die Funktion zu opti-
mieren.
Der Algorithmus fu¨r lernende Suchmaschinen
Die meiste Arbeit der lernenden Suchmaschinen im Information Retrieval ist nicht die For-
mulierung von Dokumenten, sondern die vereinfachte Aufgabe, eine bina¨re Klassifikation von
Problem mit den beiden Klassen ”relevantu¨nd ”nicht relevant”. Eine solche Vereinfachung
hat mehrere Nachteile.
Die ”nicht relevanten”Dokumente haben eine starke Mehrheit. Ein Lernender muss eine Regel
haben, um die Dokumente maximal automatisch genau zu klassifizieren. Aber es ist noch wich-
tig, und gezeigt, dass solche absolute relevante Urteile nicht existieren, und nicht verfu¨gbar
sind. Deshalb sollen wir einen Algorithmus finden.
Fu¨r identische q und ihre r∗:
(q1, r
∗
1), · · · , (qn, r
∗
n) (1.37)
wa¨hlt Lerner L eine Funktion f , so dass
τs(f) =
1
n
n∑
i=1
τ(rf(qi), r
∗
i ) (1.38)
maximiert wird. Ist es ma¨glich, einen Algorithmus und eine Familie von Rang Funktionen
F zu entwerfen, so dass eine Funktion f ∈ F Maximierung effiziente gefunden wird, und
diese Funktion weit u¨ber den Trainingsdaten verallgemeinert werden kann. Betrachten Sie die
linearen Funktionen
(di, dj) ∈ fω¯(q)⇔ ω¯ϕ(q, di) > ω¯ϕ(q, dj). (1.39)
ω ist ein Gewichtsvektor, und ϕ(q, d) ist ein Diagramm mit der Dimension, die die Eigenschaft
zwischen Anfrage q und Dokument d beschreibt.
58
Abbildung 1.20: Anfrage - Dokument
Mit unterschiedlichen Gewichtsvektoren ω werden die Dokumente unterschiedlich sortiert
(siehe Abb.1.20). Jetzt haben wir sofort eine Frage, wie kann man die Dokumente als Punkte
auf einem Diagramm zeichnen? Das folgende Beispiel illustriert die Anwendung der Gewichts-
vektoren bei Suchergebnissen.
Beispiel-Frage: ’side effect of drugs on memory and cognitive abilities, not aging’
ti ωi d1i d2i d3i d4i
side effect 2 1 0,5 1 1
drugs 2 1 1 1 1
memory 1 1 1
cognitive ability 1 1 1 0,5
not aging -2 1
Retrivalgewicht 5 2 6 4,5
Entsprechend den Retrivalgewichten werden die Dokumente in der Reihenfolge d3; d1; d4; d2
ausgegeben.
Die Maximierung (Formel 1.38) ist direkt a¨quivalent zur Minimierung der Zahl Q, der nicht
u¨bereinstimmenden Paare in der Formel (1.34). Fu¨r die Klasse der linearen Rangfunktionen
(1.39)ist dies a¨quivalent dazu, um das Gewicht des Vektors zu finden, so dass die maximale
Anzahl der folgenden Ungleichungen erfu¨llt ist.
∀(di, dj) ∈ r∗i : ω¯ϕ(q1, di) > ω¯ϕ(q1, dj)
· · ·
∀(di, dj) ∈ r∗n : ω¯ϕ(qn, di) > ω¯ϕ(qn, dj)
Das Problem ist NP-Schwer. Aber genau wie bei der Klassifizierung des SVMs ist es mo¨glich
durch die Einfu¨hrung von (nicht negativ) Schlupfvariablen ξi,j,k und Minimierung
∑
ξi,j,k
dieses Problem zu lo¨sen.
(RANKING SVM)
Min.V (ω¯, ξ¯) =
1
2
ω¯ · ω¯ + C
∑
ξi,j,k (1.40)
59
mit Nebenbedingung:
∀(di, dj) ∈ r
∗
i : ω¯ϕ(q1, di) ≥ ω¯ϕ(q1, dj) + 1− ξi,j,1 (1.41)
· · · (1.42)
∀(di, dj) ∈ r
∗
n : ω¯ϕ(qn, di) ≥ ω¯ϕ(qn, dj) + 1− ξi,j,n (1.43)
∀i, j, k : ξi,j,k ≥ 0 (1.44)
C ist positive Konstante, die den Ausgleich zwischen der Minimierung von 12 ω¯ · ω¯ und der kor-
rekten Klassifizierung der Trainingsbeispiele regelt. Durch die Neuordnung der Ungleichung
(1.41) als
ω¯ϕ(q1, di)− ω¯ϕ(q1, dj) ≥ 1− ξi,j,1 (1.45)
wird verdeutlicht, dass die Optimierung des Problems a¨quivalent ist zu einer Klassifikation
von SVM auf paarweise unterschiedliche Vektoren ω¯ϕ(q1, di) − ω¯ϕ(q1, dj). Es kann gezeigt
werden, dass die erlernten Retrieval Funktionen fω¯∗ immer als eine lineare Kombination der
Vektoren vorkommen.
(di, dj) ∈ fω¯∗(q) (1.46)
⇐⇒ ω¯∗ϕ(q, di) > ω¯
∗ϕ(q, dj) (1.47)
⇐⇒
∑
α∗k,lϕ(qk, dl)ϕ(q, di) >
∑
α∗k,lϕ(qk, dl)ϕ(q, dj) (1.48)
Der Vektorraum und die zugeho¨rigen Trainingsdaten sind durch eine Kernelfunktion
∑
α∗k,lϕ(qk, dl)ϕ(q, di) in einen Raum mit so hoher Dimension zu u¨berfu¨hren, dass sich die
Trainingsdaten dort linear trennen lassen.
Experiment
Um die Qualita¨t der verschiedenen Retrieval Funktionen vergleichen zu ko¨nnen, wird die Me-
thode in [T. Joachims 2002] beschrieben. Die zentrale Idee ist es, zwei Rankings in der gleichen
Zeit zu vergleichen. Man kombiniert zwei Ranglisten A und B zu C. Es muss die folgende
Bedingung gelten: Die oben erwa¨hnten L Links der kombinierten Ra¨nge C enthalten die oben
genannten Ka Links von A und der oben erwa¨hnten Kb Links von B mit |Ka −Kb| ≤ 1. Mit
anderen Worten, wenn der Benutzer die Links von C von oben nach unten scannt, hat er an
einem beliebigen Punkt fast ebenso viele Links von der Spitze von A wie von der Spitze des
B gesehen.
Ein Beispiel ist in Abb.1.21 gegeben. Die von zwei Retrieval Funktionen kombinierten Er-
gebnisse C werden an den Benutzer weitergeleitet. In diesem Beispiel hat der Benutzer auf
den Links 1, 3 und 7 angeklickt. In diesem Beispiel muss der Benutzer die oben erwa¨hnten
4 Links aus einzelnen Rankings gesehen haben, da er auf den Link 7 in der kombinierten
Rangliste C angeklickt hat. Er hat auf 3 Links in der oberen 4 Links im Ranking A (1, 2 und
4) angeklickt, sondern nur auf 1 Link in Rang B (1). Es wird daraus geschlossen, dass die
oben genannten 4 Links von A besser sind als jene von B fu¨r diese Anfrage.
Am Paper von Thorsten Joachims [Joa02] wird die lernende Funktion von SVM mit Google,
MSNSearch und Toprank vergleicht. Die Ergebnisse siehe man im Tab.1.3.
60
Abbildung 1.21: Ranking-merge Beispiel
61
Comparison more clicks on learned less clicks on learned
Learned vs. Google 29 13
Learned vs. MSNSearch 18 4
Learned vs. Toprank 21 9
Comparison tie(with clicks) no clicks total
Learned vs. Google 27 19 88
Learned vs. MSNSearch 7 11 40
Learned vs. Toprank 11 11 52
Tabelle 1.3: Vergleich mit Suchmaschinen
Abbildung 1.22: trennende Hyperebene
1.4 Maschinelle Lernverfahren
1.4.1 SVM
Eine Support Vector Machine (SVM) lo¨st ein bina¨res Klassifizierungsproblem. Sie lernt auf
einer bereits klassifizierten Menge von Trainigsbeispielen und entscheidet dann fu¨r Test-
Elemente, zu welcher der zwei Klassen sie geho¨ren. Das eigentliche Lernen besteht darin,
eine Hyperebene H zu berechnen, die die Beispiele beider Klassen trennt. Danach kann an-
hand der Lage der Test-Elemente zur Hyperebene eine Klassifizierung erfolgen. Zuna¨chst gilt
es aber unter den vielen mo¨glichen trennenden Ebenen die Optimale zu finden. Optimal wird
dabei so verstanden, dass der Abstand von der Ebene zum nahesten Beispiel beider Klassen
maximiert wird. Es liegt also ein Optimierungsproblem [Bur98] vor, welches nachfolgend for-
malisiert werden soll.
Es sei o.B.d.A. angenommen, dass die Beispiele in positive und negative unterteilt seien. Vor-
erst wird vorrausgestzt, dass die Trainingsdaten linear trennbar sind, es also eine trennende
Hyperebene gibt. Der Fall linear nicht trennbarer Daten wird danach aufbauend auf diesen
Erkenntnissen betrachtet.
(xi, yi) (i = 1, ...,m) seien m Trainingsbeispiele, bestehend aus einem Punkt xi ∈ RRd
und der Klassifizierung3 yi ∈ {−1, 1}. w ∈ RRd sei der zu bestimmende Normalenvektor
3Als Klassifizierung wird die -1 und 1 statt z.B. 0 und 1 verwendet, weil sich damit, wie wir sehen werden,
62
Abbildung 1.23: Hyperebene
Abbildung 1.24: Breite der Hyperebene
der Hyperebene (siehe Abbildung 1.23), b ∈ RR ihr Bias. Als Ebenengleichung wird die
Variante mit dem Skalarprodukt gewa¨hlt, so dass alle Punkte x der Ebene die Gleichung
w · x + b = 0 erfu¨llen. Per Definition sollen die nahesten positiven Beispiele auf der Ebene
H1: w · xi + b = 1 und die nahesten negativen Beispiele auf der Ebene H2: w · xi + b = −1
liegen (siehe Abbildung 1.24). Dies kann durch eine entsprechende Skalierung von w und b
sichergestellt werden. Aus diesen Definitionen lassen sich direkt zwei Nebenbedingungen des
Optimierungsproblems formulieren:
w · xi + b ≥ 1, ∀i : yi = 1 (1.49)
w · xi + b ≤ −1, ∀i : yi = −1 (1.50)
Die la¨sst sich zusammenfassen zu:
yi(w · xi + b)− 1 ≥ 0, ∀i (1.51)
Ziel des Optimierungproblems ist die erwa¨hnte Maximierung des Abstandes zu den na¨hesten
Beispielen. Man spricht hier auch von der Breite (margin) der Ebene H, die bildlich den
Abstand der Ebenen H1 und H2 aus Abbildung 1.24 repra¨sentiert. Dieser Abstand betra¨gt
2
‖w‖ , wobei ‖w‖ die euklidische La¨nge von w darstellt. Zur Maximierung der Breite muss
also ‖w‖ minimiert werden. Eine SVM la¨sst sich dann durch folgendes Optimierungsproblem
beschreiben:
‖w‖2 −→Min!
yi(w · xi + b)− 1 ≥ 0, ∀i
besser rechnen la¨sst.
63
Nun wird ersichtlich, warum die SVM Stu¨tzvektor -Maschine heißt: Die Hyperebene H wird
durch Maximierung der Breite bestimmt. Die Breite ha¨ngt nur von den zur Ebene am na¨chsten
gelegenen Beispielen ab, die ja die Ebenen H1 und H2 bestimmen. Die Beispiele, die auf einer
dieser Ebenen liegen, stu¨tzen die Ebene H, da sich ohne sie die Lage (die Breite) von H
vera¨ndern wu¨rde, und werden daher Stu¨tzvektoren genannt.
Um den Fall nicht linear separierbarer Daten besser handhaben zu ko¨nnen, ist eine Transfor-
mation des Problems in die duale Lagrange-Form no¨tig. Dazu werden die u¨blichen Lagrange-
Multiplikatoren αi ≥ 0 eingefu¨hrt und die Nebenbedingung in die Zielfunktion aufgenommen.
Man erha¨lt zuna¨chst die Zielfunktion:
L(w, b, α) =
1
2
‖w‖2 −
m∑
i=1
αiyi(w · xi + b) +
m∑
i=1
αi (1.52)
Jedes Optimum der Zielfunktion muss auch ein Minimum der Funktion sein. Dies ist die eine
notwendige Bedinung fu¨r die Eigenschaft als Optimum. Die Karush-Kuhn-Tucker (KKT) Be-
dingungen setzten diese Tatsachen in Gleichungen um. Damit ein Minimum vorliegt, mu¨ssen
die ersten partiellen Ableitungen in Richtung der Entscheidungsvariablen w und b null sein.
Die KKT Bedingungen fu¨r das Optimierungsproblem der SVM mit der Lagrange-Zielfunktion
(1.52) lauten:
∂
∂w
L(w, b, α) = w −
m∑
i=1
αiyixi = 0
∂
∂b
L(w, b, α) = −
m∑
i=1
αiyi = 0
yi(w · xi + b)− 1 = 0, ∀i
αi ≥ 0, ∀i
αi(yi(w · xi + b)− 1) = 0, ∀i
Durch Umstellen der ersten beiden Bedingungen erha¨lt man:
w =
m∑
i=1
αiyixi (1.53)
m∑
i=1
αiyi = 0 (1.54)
Einsetzen von (1.53) und (1.54) in (1.52) liefert die Zielfunktion LD des dualen Optimierungs-
problems:
LD(α) =
m∑
i=1
αi −
1
2
m∑
i=1
m∑
j=1
αiαjyiyj(xi · xj) (1.55)
Die Zielfunktion ha¨ngt damit nur noch von α ab und verwendet als einzige nicht elementare
Rechenoperation das Skalarprodukt. Nun erhalten wir das (einfachere) duale Optimierungs-
64
Abbildung 1.25: Nicht linear trennbare Trainingsdaten
problem fu¨r eine SVM auf Basis linear trennbarer Trainingsdaten:
m∑
i=1
αi −
1
2
m∑
i=1
m∑
j=1
αiαjyiyj(xi · xj) −→Max!
m∑
i=1
αiyi = 0, ∀i
αi ≥ 0, ∀i
Nach Lo¨sung des Problems sind alle αi bestimmt und der Normalenvektor w kann mit (1.53)
berechnet werden. Den Bias erha¨lt man, in dem man einen beliebigen Stu¨tzvektor in die
Ebenengleichung von H einsetzt und nach b umformt. Normalenvektor, Bias und damit die
Hyperebene sind also durch Linearkombinationen aus gerade den Beispielen xi, fu¨r die αi > 0
ist, bestimmt. Diese Beispiele sind, wie wir schon gesehen haben, die Stu¨tzvektoren. Also gilt:
ˆ αi > 0: xi ist Stu¨tzvektor
ˆ αi = 0: xi ist kein Stu¨tzvektor
Nun ko¨nnen die Elemente der Test-Menge klassifiziert werden. Dazu genu¨gt die Auswertung
der Funktion
f(x) = w · x+ b (1.56)
fu¨r ein Testelement x. Das Vorzeichen von f(x) gibt dabei die Klassifizierung an, da nur
folgende Fa¨lle zu unterscheiden sind:
ˆ f(x) > 0: x liegt im positiven Halbraum
ˆ f(x) < 0: x liegt im negativen Halbraum
ˆ f(x) = 0: x liegt auf H
Betrachten wir jetzt den Fall nicht linear trennbarer Daten, den Abbildung 1.25 schematisch
zeigt. Was kann man tun, um dieses Problem zu lo¨sen?
ˆ Fehler zulassen
Dies kann mit der Einfu¨hrung einer weich trennenden Ebene gelo¨st werden, die fehler-
hafte Klassifizierungen von Trainingsbeispielen bis zu einem gewissen Grad zula¨sst.
ˆ Das Problem und die Daten so transformieren, dass sie linear trennbar werden.
65
Abbildung 1.26: Beispiele fu¨r α-ξ Kombinationen
Die eine SVM mit weich trennender Hyperebene erweitert die bekannte SVM um die
”
Feh-
lerkosten“ ξi ≥ 0 fu¨r jedes Beispiel. Die Nebenbedingungen 1.49 und 1.50 a¨ndern sich dann
zu:
w · xi + b ≥ 1− ξi, ∀i : yi = 1 (1.57)
w · xi + b ≤ −1 + ξi, ∀i : yi = −1 (1.58)
Diese lassen sich wieder zusammenfassen zu:
yi(w · xi + b)− 1 + ξi = 0, ∀i (1.59)
Zu der urspru¨nglichen Zielfunktion werden die
”
Fehlerkosten“ einfach hinzu addiert. Weiter-
hin wird noch eine vom Benutzer zu wa¨hlende Konstante C eingefu¨hrt, die die Auswirkung
der Fehlklassifikationen beeinflusst. Eine weich trenndende SVM wird dann durch folgendes
Problem repra¨sentiert:
‖w‖2 + C
m∑
i=1
ξi −→Min!
yi(w · xi + b)− 1 = 0, ∀i
0 ≤ αi ≤ C, ∀i
Die Zielfunktion des dualen Problem ist wieder (1.52), da die ξi beim Bilden des dualen
Problems verschwinden. Das bekannte duale Problem fu¨r linear trennbare Daten wird fu¨r die
weich trennende SVM also nur um die Nebenbedingungen 0 ≤ αi ≤ C erweitert. Abbildung
1.26 verdeutlicht noch einmal die Bedeutung der αi und ξi.
Die Transformation der linear nicht trennbaren Daten in linear trennbare gelingt ohne große
Mu¨hen, da in den entwickelten Formeln das Skalarprodukt die einzige nicht elementare Re-
chenoperation ist. Die Idee ist, die Beispiele durch eine Abbildung Φ : RRm −→ RRh mit
66
Abbildung 1.27: Der Kern-Trick
h > m in einen ho¨herdimensionalen Raum zu transformieren, wo sie dann linear trennbar
sind. Die Zielfunktion (1.55) wird dann einfach angepasst:
LD(α) =
m∑
i=1
αi −
1
2
m∑
i=1
m∑
j=1
αiαjyiyj(Φ(xi) · Φ(xj)) (1.60)
Sei K(x, y) = Φ(x) · Φ(y) eine Kernfunktion, die das Skalarprodukt zweier transformierter
Trainingsdaten direkt berechne. Eine solche Funktion muss die Abbildung Φ gar nicht kennen.
Die Abbildung 1.27 verdeutlicht diesen Gedanken, den man auch den Kern-Trick nennt.
Ein Beispiel:
Seien x, y ∈ RR2 und K(x, y) = (x · y)2 eine Kernfunktion. Um zu zeigen, dass K das
Skalarprodukt direkt berechnet, muss eine Abbildung Φ mit Φ(x) ·Φ(y) = (x+ y)2 gefunden
werden. Wir nehmen an, dass die Funktion
Φ(x) =


[x]21√
2[x]1[x]2
[x]22

 (1.61)
dieses tut. [x]i bezeichnet dabei die i-te Komponente von x. Beweis:
Φ(x) · Φ(y) =


[x]21√
2[x]1[x]2
[x]22

 ·


[y]21√
2[y]1[y]2
[y]22


= [x]21[y]
2
1 + 2[x]1[x]2[y]1[y]2 + [x]
2
2[y]
2
2
= ([x]1[y]1)
2 + 2[x]1[y]1[x]2[y]2 + ([x]2[y]2)
2
= ([x]1[y]1 + [x]2[y]2)
2
= (x · y)2
Wir sehen also, dass K das Skalarprodukt von x und y direkt berechnet, ohne dabei erst in
den ho¨herdimensionalen Raum abzubilden.
67
Setzt man die Kernfunktion in in die Zielfunktion (1.60) ein, erha¨lt man zusammen mit
den bekannten Nebenbedingungen das Optimierungsproblem fu¨r eine SVM mit nicht linear
trennbaren Daten:
m∑
i=1
αi −
1
2
m∑
i=1
m∑
j=1
αiαjyiyjK(xi, xj) −→Max!
m∑
i=1
αiyi = 0, ∀i
0 ≤ αi ≤ C, ∀i
Mit der Mercer’s Condition la¨sst sich u¨berpru¨fen, ob eine Funktion K(x, y) eine Kernfunktion
ist:
Es gibt Abbildungen K und Φ mit K(x, y) = Φ(x) · Φ(y) =
∑
i[Φ(x)]i[Φ(y)]i ⇔
fu¨r jedes g(x) mit finitem
∫
g(x)2dx gilt
∫
K(x, y)g(x)g(y)dxdy ≥ 0
Die Lo¨sung des Optimierungsproblems gestaltet sich als schwierig. Zwar liegt ein quadrati-
sches, konvexes Optimierungsproblem vor, welches in O(m3) gelo¨st werden kann, jedoch ist
dies in praktischen Anwendungen fu¨r eine sehr große Menge an Trainingsdaten langwierig.
Erschwerend kommt hinzu, dass die Ungleichungen fu¨r große m nur mit numerischen Me-
thoden gelo¨st werden ko¨nnen. Ein numerischer Solver muss als Unterprogramm aufgerufen
werden. Im Folgenden werden zwei Lo¨sungsalgorithmen vorgestellt, die das Optimierungspro-
blem heuristisch lo¨sen.
Ein Verfahren ist das Chunking, bei dem der zentrale Gedanke darin liegt, Trainingsbeispie-
le, die keine Stu¨tzvektoren sind, aus der Berechnung auszuschließen, da sie, wir wir gesehen
haben, die Lage der Hyperebene nicht beeinflussen. Eine Iteration la¨uft wie folgt ab:
1. Lo¨se das Problem auf Basis einer Teilmenge der Trainingsdaten.
2. Betrachte die berechnten αi-Werte:
Ist αi = 0 ist xi kein Stu¨tzvektor und wird von der weiteren Berechnung ausgeschlossen.
3. Nimm M Trainiungsbeispiele in die Berechnungsmenge auf, die die KTT-Bedingungen
am schlechtesten erfu¨llen.
U¨ber die Iterationen wird also versucht, die Stu¨tzvektoren zu identifizieren. In der letzten
Iteration sind dann nur noch Stu¨tzvektoren in der Berechnungsmenge, so dass dann das ge-
samte Problem gelo¨st wird. Damit reduziert Chunking den Aufwand auf die quadrierte Anzahl
der Stu¨tzvektoren. Dies kann erhebliche Vorteile bringen, aber auch genauso schlecht wie die
Lo¨sung ohne die Heuristik sein, wenn nahezu alle Trainingsdaten Stu¨tzvektoren sind. Defi-
nitv nachteilig ist aber, dass Chunking weiterhin nicht ohne Numerik-Solver auskommt. Genau
diesem Nachteil nimmt sich das zweite Verfahren an: Die Sequential Minimal Optimization
[Pla99], kurz SMO.
Wa¨hrend das Chunking immer mehrere αi optimiert, beschra¨nkt sich die SMO auf die Opti-
mierung von genau zwei αi in jeder Iteration. Der Vorteil ist, dass sich dies analytisch lo¨sen
la¨sst. Somit kann auf das Unterprogramm zur numerischen Lo¨sung einer Gleichung verzichtet
68
werden. Insgesamt sind natu¨rlich weit mehr Optimierungen no¨tig als beim Chunking, da alle
αi paarweise optimiert werden mu¨ssen. Trotzdem ist die Laufzeit besser als die des Chunkings,
da die Numerik-Solver Aufrufe schwerer wiegen als das Mehr an Optimierungsiterationen (die
alle in O(1) gelo¨st werden ko¨nnen).
Der SMO-Algorithmus verwendet eine a¨ußere und eine innere Schleife zur Auswahl der αi-
Paare. In der a¨ußeren Schleife werden zuna¨chst alle Beispiele durchlaufen und alle nicht gebun-
denen (non bound, d.h. αi ist weder 0 noch C) Beispiele gesucht, die die KKT-Bedingungen
verletzten. Das dazugeho¨rige Alpha sei jeweils αI , welches fu¨r die innere Schleife fest ist. Die
innere Schleife findet nun unter den u¨brigen Beispielen ein αII als Optimierungspartner. Als
Auswahlkriterium wird der momentane Fehler
Ei = f(xi)− yi (1.62)
genutzt. EI sei der Fehler des Beispiels aus der a¨ußeren Schleife. Die Fehler der u¨brigen
Beispiele werden berechnet und das Beispiel, welches αII liefert, wie folgt gewa¨hlt:
ˆ EI > 0: Wa¨hle Beispiel mit kleinstem Ei
ˆ EI < 0: Wa¨hle Beispiel mit gro¨ßtem Ei
Fu¨r die genaue Vorgehensweise zur Optimierung des Paares (αI , αII) sei auf [Pla99] verwiesen.
Nach der Optimierung wird die Ebene neu berechnet. Damit a¨ndern sich auch die Ergebnisse
von f(xi) bei der Fehlerberechnung aus (1.62). Die a¨ußere Schleife la¨uft bis kein Beispiel mehr
die KKT-Bedingungen verletzt. Danach werden noch einmal alle Beispiele durchlaufen und
paarweise optimiert. Die Suche in der a¨ußeren Schleife beginnt immer an einer Zufallsposition,
damit sich die SVM nicht den ersten Trainingsdaten anna¨hert.
1.4.2 SVM struct
Dieser Abschnitt basiert auf dem Artikel, welcher unter [THJA04] zu finden ist.
Einleitung SVMstruct soll auch komplexe Ausgaben miteinbeziehen ko¨nnen. Es soll eine Zu-
ordnung von einer Eingabe x ∈ X zu einer diskreten Ausgabe y ∈ Y gefunden werden, welche
auf einer Trainingsmenge von Eingabe-Ausgabe Paaren (x1, y1),...,(xn, yn) ∈ X × Y basiert.
Y ist dabei ein strukturierter Ausgaberaum. y ∈ Y ko¨nnen z.B. Sequenzen, Strings, Ba¨ume,
Gitter und Graphen sein. Derartige Probleme gibt es bei einer Vielzahl von Anwendungen.
Durch eine Verallgemeinerung der Large Margin Methode (Standard Multiclass-SVM) sollen
nun strukturierte Antworten gefunden werden.
Diskriminanten und Verlustfunktionen Das Funktionenlernen f : X → Y, basiert auf einer
Trainingsmenge von Eingabe-Ausgabe Paaren. Es soll eine Diskriminanzfunktion F : X×Y →
<, u¨ber die Eingabe/Ausgabe Paare gelernt werden, von der Vorhersagen abgeleitet werden
ko¨nnen, indem F u¨ber die Ru¨ckgabevariable fu¨r die Eingabe x maximiert wird. Formal ist
dies wie folgt zu notieren:
f(x;w)= arg maxy∈Y F(x,y;w)
(1.63)
69
mit w als ein Parameter-Vektor. F soll linear in seiner kombinierten Merkmalsrepra¨sentation
von Ein- und Ausgaben Ψ(x, y) sein, also soll gelten:
F(x,y;w) = 〈w,Ψ(x, y)〉.
(1.64)
Die spezifische Form von Ψ ha¨ngt allerdings von der Art des Problems ab.
Beispiel 1 (natu¨rlichsprachliche Syntaxanalyse) F soll so gewa¨hlt werden, dass ein Mo-
dell entsteht, dass einer kontextfreien Grammatik entspricht. Jeder Knoten, im Syntaxbaum
y fu¨r einen Satz x, entspricht einer Grammatikregel gj mit den Kosten wj. Alle gu¨ltigen Syn-
taxba¨ume y fu¨r den Satz x bekommen eine Punktzahl zugewiesen, die sich aus der Summe der
wj seiner Knoten berechnen la¨sst, also F(x,y;w) = 〈w,Ψ(x, y)〉. Ψ(x, y) ist ein Histogramm-
vektor, der die Vorkommen jeder Grammatikregel gj im Baum y za¨hlt. f(x;w) kann effizient
berechnet werden, indem die Struktur y ∈ Y gefunden wird, die F(x,y;w) maximiert.
Das Lernen u¨ber strukturierten Ausgabera¨umen Y bezieht andere Verlustfunktionen mit ein
als die Standard 0/1 - Klassifikationsverluste.
Beispiel 2 (natu¨rlichsprachliche Syntaxanalyse) So ist es sinnvoll einen Syntaxbaum,
der sich vom korrekten Syntaxbaum in nur wenigen Knoten unterscheidet, anders zu behan-
deln, als einen Syntaxbaum der sich von diesem vollkommen unterscheidet.
Deshalb wird auch davon ausgegangen, dass eine beschra¨nkte Verlustfunktion ∆ : Y×Y → <
vorhanden ist. Dies bedeutet, wenn y der wahre Ausgabewert ist, misst ∆(y, yˆ) den Verlust
der mit der Vorhersage yˆ verbunden ist.
Von der SVM zur SVMstruct Zuna¨chst wird der separierbare Fall betrachtet, dass der
Trainingsfehler gleich null ist. Angenommen, dass ∆(y, y′) > 0 ist, wenn y 6= y′, und dass
∆(y, y) = 0 ist. Die Bedingung, dass der Trainingsfehler null ist, soll nun kompakt dargestellt
werden, als die Menge der nicht linearen Bedingungen
∀i : max
y∈Y\yi
{〈w,Ψ(xi, y)〉} < 〈w,Ψ(xi, yi)〉. (1.65)
Jede dieser nicht linearen Ungleichheiten, kann durch |Y| − 1 lineare Ungleichheiten ersetzt
werden. Insgesamt gibt es also n |Y| − n lineare Bedingungen der Form
∀i,∀y ∈ Y \ yi
:
〈w, δΨi(y)〉 > 0
, mit
δΨi(y) ≡ Ψ(xi, yi)−Ψ(xi, y)
.
70
Wenn die Menge dieser Ungleichheiten zula¨ssig ist, dann gibt es typischerweise mehr als eine
Lo¨sung w∗. Um eine einzige Lo¨sung zu erhalten, muss das w gewa¨hlt werden, fu¨r das sich die
Punktzahl des korrekten Labels yi konstant am meisten von dem nahesten zweitplatzierten
unterscheidet, also
yˆi(w) = arg max
y 6=yi
〈w,Ψ(xi, y)〉
. Dies ist die Generalisierung des Maximum-Margin-Prinzips welches in der SVM angewandt
wird. Das resultierende Hard-Margin-Optimierungsproblem, ist die SVM fu¨r linear trennbare
Daten.
SVM linear : min
w
1
2
‖w‖2,
mit den Nebenbedingungen
∀i,∀y ∈ Y \ yi : 〈w, δΨi(y)〉 ≥ 1.
Um nun aber einen Fehler in der Trainingsmenge zu erlauben, wird eine Schlupfvariable
eingefu¨hrt und zwar fu¨r jede nicht lineare Bedingung eine Schlupfvariable. Diese ist die obere
Grenze des Trainingsfehlers. Das Einfu¨gen einer Strafbedingung zu den Zielergebnissen die
linear in den Schlupfvariablen ist, fu¨hrt nun zur SVM fu¨r nicht lineare Daten.
SVMnonlinear : min
w,ξ
1
2
‖w‖2 +
C
n
n∑
i=1
ξi,
so dass ∀i, ξi ≥ 0, mit den Nebenbedingungen
∀i,∀y ∈ Y \ yi : 〈w, δΨi(y)〉 ≥ 1− ξi.
Bisher gibt es aber noch keine neuen Erkenntnisse, welche es nicht schon im Kapitel 1.4.1
u¨ber SVM gab. Diese Formulierung soll jetzt aber fu¨r beliebige Verlustfunktionen ∆ genera-
lisiert werden. Dafu¨r muss zuna¨chst der Maßstab der Schlupfvariablen gea¨ndert werden und
zwar gema¨ß des Verlustes der in jeder linearen Bedingung angefallen ist. Das Verletzen ei-
ner Margin-Bedingung die einen Ausgabewert mit hohem Verlust ∆(yi, y) zur Folge hat, soll
strenger bestraft werden, als ein Verstoß aus dem ein kleiner Verlust folgt. Dies wird erreicht,
indem die Schlupfvariablen mit dem inversen Verlust skaliert werden. Dies fu¨hrt nun endlich
zur SVMstruct,
SVM struct : min
w,ξ
1
2
‖w‖2 +
C
n
n∑
i=1
ξi,
so dass ∀i, ξi ≥ 0, mit den Nebenbedingungen
∀i,∀y ∈ Y \ yi : 〈w, δΨi(y)〉 ≥ 1−
ξi
∆(yi, y)
.
SVMstruct Algorithmus Die Hauptaufgabe beim Lo¨sen dieser verallgemeinerten SVM - For-
mulierung, liegt in der großen Anzahl der Margin-Bedingungen, denn die Gesamtanzahl der
Bedingungen betra¨gt n |Y|. Wobei |Y| in vielen Fa¨llen extrem groß ist (z.B. beim Grammatik-
Lernen). Daher sind Standardlo¨sungen eher ungeeignet. Der SVMstruct-Algorithmus soll nun
die Struktur des Maximum-Margin-Problems ausnutzen, also nur noch eine kleine Teilmenge
71
1 Input: (x1, y1), ..., (xn, yn), C, 
2 Si ← ∅ for all i = 1, ..., n
3 repeat
4 for i = 1, ..., n do
5 set up cost function [{z.B: SVM s: H(y) ≡ (1− 〈δΨi(y), w〉)∆(yi, y)}]
6 compute yˆ = arg maxy∈Y H(y)
7 compute ξi = max{0,maxy∈Si H(y)}
8 if H(yˆ) > ξi +  then
9 Si ← Si ∪ {yˆ}
10 αS ← optimize dual over S, S = ∪iSi
11 end if
12 end for
13 until no Si has changed during iteration
Listing 1.1: SVMstruct
von Bedingungen detailiert betrachten. Er soll eine kleine Menge von aktivierten Bedingun-
gen finden, die eine ausreichend fehlerfreie Lo¨sung garantieren. Dies ergibt eine gute und
gu¨ltige Lo¨sung, da es immer eine polynomiell große Teilmenge von Bedingungen gibt, so
dass die zugeho¨rige Lo¨sung alle Bedingungen mit einer Genauigkeit von mindestens  erfu¨llt.
Alle anderen Bedingungen werden garantiert durch nicht mehr als  verletzt, ohne dass sie
dafu¨r genauer betrachtet werden mu¨ssen. Der folgende Algorithmus kann auf alle SVM struct-
Formulierungen angewandt werden, die in [THJA04] vorgestellt werden. Es muss nur die
Kostenfunktion in Schritt 5 angepasst werden.
Es gibt eine Arbeitsmenge Si fu¨r jedes Trainingsbeispiel (xi, yi), welche in Zeile 2 definiert
wird. Sie ha¨lt die aktuell ausgewa¨hlten Bedingungen fest. Beim Abarbeiten der Trainings-
beispiele wird die Bedingung gesucht, die den gro¨ßten Verlust zur Folge hat (siehe Zeile 6).
Wenn dessen Margin-U¨berschreitung den in Zeile 7 errechneten Wert von ξi, mit mehr als
 u¨berschreitet (diese Abfrage ist in Zeile 8 zu finden), dann soll die Bedingung yˆ zur Ar-
beitsmenge hinzufu¨gt werden (vgl. Zeile 9). Dies entspricht einer sukzessiven Versta¨rkung des
grundlegenden Problems, durch eine Schnittebene, die die aktuelle Lo¨sung von der zula¨ssigen
Menge entfernt. Die gewa¨hlte Schnittebene entspricht der Bedingung, die den kleinsten zula¨s-
sigen Wert fu¨r ξi bestimmt. Nachdem eine Bedingung zur Arbeitsmenge hinzugefu¨gt wurde,
muss die Lo¨sung, in Zeile 10 (in Bezug auf S), neu errechnet werden. Der Algorithmus stoppt,
wenn, wie in Zeile 13 gefordert, keine Bedingung durch mehr als  verletzt wird und sich
somit kein Si gea¨ndert hat. Es ist leicht zu zeigen, dass der Algorithmus eine Lo¨sung hat die
nahe am Optimum liegt. Fu¨r eine große Klasse von Problemen konvergiert der Algorithmus in
polynomieller Zeit trotz eventuell exponentiellen oder unendlichen |Y|. Das liegt daran, dass
die Anzahl der Bedingungen in S nicht von |Y| abha¨ngig ist. Wenn die Zeile 6 des Codes also
polynomiell ist, dann ist der ganze Algorithmus polynomiell.
72
Anwendungen und Experimente Dieser Ansatz ist effektiv und vielseitig. Er kann auf eine
breite Klasse von Aufgaben angewandt werden, z.B. auf Multiclass Klassifikation, Klassifika-
tion mit Taxonomien, Label Sequence Learning, Sequence Alignment und Natural Language
Parsing. Um den Algorithmus an das neue Problem anzupassen muss lediglich eine Implemen-
tierung der Merkmalsabbildung Ψ(x, y), der Verlustfunktion ∆(yi, y) und der Maximierung
des Verlusts (Zeile 6 des Codes) erfolgen.
Beispiel 3 (Label Sequence Learning) Es soll eine Sequenz von
Labeln y = (y1, ..., yn), yk ∈ Σ, gegeben einer Sequenz von Eingaben x = (x1, ..., xm), vorher-
gesagt werden. Diese Art der Klassifizierung wird z.B. bei der optischen Zeichenerkennung,
der natu¨rlichsprachlichen Syntaxanalyse, der Informationsgewinnung und der Bioinforma-
tik angewandt. Hier wird das Label Sequence Learning am Beispiel NER betrachtet, welches
bereits aus Kapitel 1.2.1 bekannt sein sollte. Es wird eine Sammlung von 300 Sa¨tzen be-
trachtet. Die Zeichenmenge besteht aus Bezeichnungslosen und zusa¨tzlich aus dem Anfang
und der Weiterfu¨hrung von Personennamen, Organisationen, Orten und diversen Namen.
Insgesamt gibt es also 9 verschiedene Labels. Ψ(x, y) ist in diesem Fall ein Histogramm der
Zustandsu¨berga¨nge und eine Menge von Merkmalen die die Ausgaben beschreiben. Tabelle 3
zeigt wie die unterschiedlichen Methoden bei diesem Datensatz abschneiden. Die Standard
Methode HMM CRF Perceptron SVM
Fehler 9.36 5.17 5.94 5.08
Tabelle 1.4: Methodenvergleich
Hidden Markov Model Methode, welche bereits aus Kapitel 1.2.2 bekannt ist, wird von allen
Lernmethoden deutlich u¨bertroffen. Die Methoden Conditional Random Fields (welche bereits
aus Kapitel 1.2.4 bekannt ist), Perceptron und SVM, schneiden fast gleich ab, wobei schon
hier die SVM etwas besser ist als die anderen zwei Methoden. Die folgende Tabelle zeigt wie
die SVM fu¨r nicht lineare Daten gegen die SVMstruct abschneidet. Die Ergebnisse der un-
Methode Train Fehler Test Fehler Const Verlust
SVMnonlinear 0.2 ± 0.1 5.1 ± 0.6 2824 ± 106 1.02 ± 0.01
SVM struct 0.4 ± 0.4 5.1 ± 0.8 2626 ± 225 1.10 ± 0.08
Tabelle 1.5: Vergleich der SVM Methoden
terschiedlichen SVM Methoden sind im großen und ganzen vergleichbar. Der Trainingsfehler
ist fu¨r die SVMnonlinear etwas besser, der Testfehler hingegen ist nahezu identisch. Weniger
Bedingungen werden bei der SVM struct hinzugefu¨gt und der durchschnittliche Verlust ist bei
der SVMnonlinear etwas besser. Aber diese Unterschiede sind alle kaum nennenswert.
Ergebnis Als Resultat ist eine SVM fu¨r u¨berwachtes Lernen mit strukturierten und von-
einander abha¨ngigen Ausgaben entstanden. Diese basiert auf einer Merkmalsabbildung u¨ber
Eingabe/Ausgabe - Paare und deckt damit eine breite Klasse von Modellen ab. Das wa¨ren
z.B. gewichtete kontextfreie Grammatiken, Hidden Markov Models und Sequence Alignment,
um nur einige wichtige zu nennen. Dieser Ansatz ist flexibel im Umgang mit methodenspezifi-
schen Verlustfunktionen und eine sehr positive Eigenschaft ist, dass nur ein allgemeingu¨ltiger
Algorithmus an sa¨mtliche Aufgaben herangehen kann. Was die Pra¨zision des Ansatzes an-
geht, so ist diese fu¨r einen weiten Bereich mindestens vergleichbar mit den u¨blichen Ansa¨tzen
73
und oft sogar besser. Was durch den Algorithmus aber garantiert wird ist, dass dieser nutz-
bar ist um komplexe Modelle zu trainieren, die ansonsten nur schwer im u¨blichen Rahmen
behandelbar wa¨ren.
1.4.3 Clustering
Ensemble Clustering
Das Forschungsgebiet der Cluster Ensembles erarbeitet Verfahren zur Vereinigung mehrerer
Objekt-Zuordnungen. Ein Clusterer ordnet jedem Objekt einer Menge maximal eine Grup-
pe zu. Die Aufgabe dieses Bereichs der Forschung liegt in der Vereinigung der Ergebnisse
verschiedener Clusterer zu einer einzelnen Zuordnung, die mit den Originalzuordnungen ei-
ne mo¨glichst hohe A¨hnlichkeit besitzt. Besondere Bedeutung besitzen Algorithmen, die jene
Aufgabe ohne Kenntnis u¨ber die Zuordnungskriterien durchfu¨hren, da derartige Verfahren
wiederverwendbar und universell einsetzbar sind. Die Qualita¨t der Verfahren kann unter ver-
schiedenen Gesichtspunkten analysiert werden. Ein wesentliches Kriterium liegt trivialerweise
in der A¨hnlichkeit der neuen Zuordnung zu jenen aus der Eingabe. Wegen eventuell großen
Datenmengen muss der Laufzeit in Abha¨ngigkeit von der Eingabemenge ebenfalls eine große
Bedeutung zugeordnet werden. Ein weiteres interessantes Kriterium, das nur eine untergeord-
nete Bedeutung besitzt, liegt in der potentiellen Verwendung dieses Algorithmus auf einem
verteilten System. Diese zusa¨tzliche Mo¨glichkeit kann die Laufzeit des Verfahrens allerdings
nur um einen konstanten Faktor senken, sollte aber dennoch nicht vo¨llig vernachla¨ssigt werden.
Als Basis fu¨r eine effiziente Bearbeitung dient eine Transformation der Eingabedaten in ei-
ne geeignete Form fu¨r die Verarbeitung. Hierzu werden die Eingabedaten in eine Matrix
transformiert, wobei die Zeilen den einzelnen Objekten entsprechen, die zugeordnet werden
sollen und die Spalten den Clusterern, die eine Zuordnung erzeugen. Die Eintra¨ge der Ma-
trix entsprechen folglich der Gruppe, die der Clusterer dem Objekt zugeordnet hat. Wegen
der Wiederverwendbarkeit des Verfahrens ko¨nnen beliebige Identifikatoren verwendet werden.
Die Matrix kann nun durch Erweiterung einer Spalte in einen Hypergraphen umgewandelt
werden. Hierzu findet eine Ersetzung eines Clusterers durch die Gruppen, die jener erzeugt,
statt. Die Eintra¨ge der Matrix werden nun durch eine 1 ersetzt, falls das Objekt jener Gruppe
zugeordnet ist, ansonsten durch eine 0. Eine Spalte repra¨sentiert folglich nun eine Hyperkante
in einem Hypergraphen. Jegliche Objekte, die der gleichen Gruppe zugeordnet sind, werden
durch Hyperkanten verbunden.
Der Cluster-based Similarity Partitioning Algorithm (CSPA)[SG02] basiert auf einer ziem-
lich einfachen Idee. Die einzelnen Objekte werden miteinander verglichen und die A¨hnlichkeit
dieser Objekte ermittelt. Diese paarweise Betrachtung der einzelnen Objekte kann je nach An-
wendungsgebiet auch als Schwachpunkt dieses Verfahrens angesehen werden. Die A¨hnlichkeit
wird durch eine Matrixmultiplikation bestimmt. Hierzu wird die Matrix des Hypergraphen
mit seiner transponierten Matrix multipliziert. Anschließend wird die Ergebnismatrix mit dem
Inversen der Anzahl der Clusterer multipliziert. Jeder Eintrag wird somit auf einen Wert zwi-
schen null und eins normiert, da jedes Objekt nach Definition pro Clusterer nur einer Gruppe
zugeordnet werden kann und sich folglich maximal Anzahl der Clusterer Einsen pro Zeile
der Originalmatrix bzw. pro Spalte der transponierten Matrix befinden. Nach Ausfu¨hrung
dieser Schritte wurde das Ursprungsproblem auf das Problem eines a¨hnlichkeitsbasierten Zu-
74
ordnungsalgorithmus reduziert. Die Matrix bestehend aus den paarweisen A¨hnlichkeiten der
Objekte kann nun mit Hilfe eines solchen Algorithmus zum Beispiel METIS in die gewu¨nschte
Anzahl von Cluster umgruppiert werden.
Der HyperGraph-Partitioning Algorithm (HGPA)[SG02] versucht die Schwachstelle des Cluster-
based Similarity Partitioning Algorithm mit der paarweisen Betrachtung zu beheben. Dieser
Algorithmus arbeitet, wie schon der Name verra¨t, auf einem Hypergraphen. Eine Spalte in der
Matrix repra¨esentiert eine Hyperkante innerhalb dieses Hypergraphen. Aus diesem Graphen
sollen mo¨glichst wenige Kanten entfernt werden um die anvisierte Anzahl von unverbunde-
nen Komponenten zu erreichen, wobei jede Kante die gleiche Gewichtung besitzt. Analog
zum CSPA wird das Problem auf einen anderen Problemtyp reduziert, fu¨r den beispielsweise
mit Hilfe des hMETIS-Algorithmus gute Ergebnisse erzielt werden ko¨nnen. Eine weitere An-
forderung liegt in der anna¨hernd gleichen Gro¨ße der unverbundenen Komponenten, die eine
ho¨herer Qualita¨t des Ergebnisses garantieren soll. Eine kleine Schwa¨che dieses Verfahrens mit
der anschließenden Verwendung des hMETIS-Algorithmus ist eine fehlende Beru¨cksichtigung
der Schnittha¨ufigkeit einer zertrennten Kante.
Der Meta-Clustering Algorithm (MCLA)[TJP04] basiert ebenfalls auf der Reduktion des ei-
gentlichen Problems auf einen a¨hnlichkeitsbasierten Zuordnungsalgorithmus. Hierzu werden
fu¨r alle Gruppen der Clusterer Knoten erzeugt. Die Kanten zwischen den einzelnen Gruppen
werden hierbei mit ein Kantengewicht belegt, das die A¨hnlichkeiten dieser Gruppen wieder-
gibt. Ein etabliertes Verfahren zur Ermittlung der A¨hnlichkeit zwischen zwei Gruppen ist das
Jaccard Measure. Dieser Maßstab wird durch den Quotienten aus den gemeinsamen Objekten
und den Objekten, die mindestens in einer Menge vorkommen, ermittelt. Im Gegensatz zum
CSPA, bei dem auf Basis der A¨hnlichkeiten der Objekte neue Gruppen erzeugt werden, dient
hier die Gruppena¨hnlichkeit als Eingabe fu¨r den Algorithmus. Nachdem die neuen Gruppen,
die eine Vereinigung mehrerer urspru¨nglicher Gruppen sind, erzeugt wurden, wird jedes Ob-
jekt einer dieser Gruppe zugeordnet. Das Kriterium fu¨r die Zuordnung stellt der Quotient
aus Anzahl der Unsprungsgruppen, in denen es vorkommt, und der Anzahl der Gruppen, die
vereinigt wurden.
Beim Estimation-Maximization-Algorithm (EM-Algorithm) handelt es sich um einen k-means
Algorithmus. Zu Beginn des Algorithmus werden Clusterzentren an beliebigen Position des
Arbeitsraumes festgelegt. Die Anzahl der Clusterzentren entspricht der Gruppenanzahl, die
erzeugt werden sollen. Jedes Objekt wird mit einer Wahrscheinlichkeit dem Zentrum mit der
geringsten Distanz zugeordnet. Als Verfahren fu¨r die Ermittlung des Wahrscheinlichkeitwer-
tes wird die Standardnormalverteilung empfohlen. Nachdem diese Zuordnung fu¨r alle Ob-
jekte vollzogen wurde, ko¨nnen anhand der enthaltenen Objekte und der Wahrscheinlichkeit
ihrer Zugeh¨o¨rigkeit neue Clusterzentren ermittelt werden. Mit diesen neuen Clusterzentren
werden alle Objekte erneut zugeordnet. Dieser Vorgang wird wiederholt bis ein definierter
Schwellenwert unterschritten wurde oder eine definierte maximale Anzahl an Wiederholun-
gen erreicht ist. Diese zusa¨tzliche Bedingung ist notwendig, da dieser Algorithmus ansonsten
nicht zwangsla¨ufig terminiert.
Der Cluster-based Similarity Partitioning Algorithm wird besonders bei großen Objektmen-
gen sehr ineffizient, wenn nicht sogar unpraktikabel. Die Matrixmultiplikation ist zwar ein
einfaches Verfahren besitzt jedoch eine Laufzeit von O(n2kr), wobei n der Anzahl der Objek-
75
te, k der Anzahl der Clusterer und r der Gruppen pro Clusterer entspricht. Zudem ist wegen
der erzeugten n × n Matrix eine hohe Speicherbelastung gegeben. Im Gegensatz dazu ist der
HyperGraph-Partitioning Algorithm sehr sparsam im Ressourcenverbrauch mit seiner Lauf-
zeit von O(nkr) und du¨rfte im Rahmen dieser Projektarbeit mit vielen Objekten eine gro¨ßere
Bedeutung besitzen. Der Meta-Clustering Algorithm ist mit seiner Laufzeit von O(nk2r2) zwar
langsamer als der HGPA, jedoch insbesondere bei wenigen Clusterern und wenig zugeordne-
ten Gruppen interessant. Die Laufzeit des Estimation-Maximization-Algorithm O(kNH) ist
abha¨ngig von der Anzahl der erzeugten Gruppen, Objekte und Anzahl der Wiederholungen
bis zum Erreichen des Schwellenwertes bzw. der maximalen Wiederholungsha¨ufigkeit.
Die Qualita¨t der Ergebnisse differiert in den vorgenommenen Studien stark von den Ein-
gabedaten. Zumal keinerlei Eingabedaten fu¨r ein vergleichbares Forschungsgebiet vorliegen,
ko¨nnen hier nur schwer Ergebnisse prognostiziert werden.
Semi-supervised Clustering
Einleitung und Motivation In dieser Ausarbeitung zu dem Vortrag soll ein neues Verfahren
fu¨r eine Clusteranalyse vorgestellt werden. Es handelt sich hierbei um ein Semi-supervised
(halbu¨berwachtes) Clustering Verfahren, welches dem Nutzer erlaubt dem System Feedbacks
zu geben und es ihm ermo¨glicht den Clusterprozess mitzusteuern. Die Feedbacks sind in Form
von Constraints (Bedingungen) dargestellt. Es existieren natu¨rlich schon andere Verfahren wie
Supervised (u¨berwachte) und Unsupervised (unu¨berwachte) Clustering.
Im ersten Abschnitt wird ein kurzer U¨berblick u¨ber die Clusteranalyse gegeben. In den darauf
folgenden Kapiteln wird nun aufgezeigt, welche Eigenschaften Supervised, Unsupervised und
Semi-supervised Clustering haben. Im sechsten Abschnitt werden die Verfahren bezu¨glich
ihrer Performance verglichen und anschließend folgt die Zusammenfassung.
Clusteranalyse Die Clusteranalyse ist ein Verfahren um eine Menge von Objekten in pas-
sende Cluster einzuteilen. Hierbei sollen verborgene Muster und Strukturen in Daten erkannt
und zusammengefasst werden. Die Standard Clusteranalyse ist das Unsupervised Clustering,
bei dem Cluster automatisch gebildet werden. Dies geschieht mit Hilfe eines A¨hnlichkeitskri-
teriums, wie z.B. dem Euklidschen oder Hammingschen Distanzmaß. Das Clusteringproblem
existiert nicht nur im Web sondern auch in anderen Gebieten wie Biologie, Marketing usw..
Algorithmen Es existieren zwei große Algorithmengruppen, zum einen die hierarchischen
Clustering Algorithmen wie z.B. Complete-Link-Algorithmus, Single-Link-Algorithmus und
Agglomerierende, zum anderen die partitionierenden Clustering Algorithmen wie k-means
oder EM.
Hierarchische Verfahren lassen sich in anha¨ufende Verfahren (agglomerative Clustering) und
teilende Verfahren (divisive Clustering) unterscheiden. Bei den anha¨ufenden Verfahren werden
schrittweise einzelne Objekte zu Clustern und diese zu gro¨ßeren Gruppen zusammengefasst,
wa¨hrend bei den teilenden Verfahren gro¨ßere Gruppen schrittweise immer feiner unterteilt
werden. Partitionierende Verfahren erzeugen nur eine einzige Partitionierung der Objektmen-
ge und mu¨ssen meistens die Anzahl der gewu¨nschten Cluster vorgeben.
Die k-means Methode allgemein(vgl. [Jos06]):
ˆ Datenmenge in k Cluster partitionieren.
76
ˆ Zentren von Clustern berechnen.
ˆ Mit der euklidschen Distanz Absta¨nde berechnen.
ˆ Minimierung des Abstandes zum Zentrum.
Die agglomerative Methode allgemein(vgl. [Jos06]):
ˆ Jedes Objekt bildet zu Beginn ein eigenes Cluster.
ˆ In einer Abstandsmatrix werden paarweise Absta¨nde gespeichert.
ˆ In jedem Schritt werden Cluster, mit kleinsten Abstand zu einander, zu einem neuen
zusammengefu¨gt.
ˆ (Abstandsmatrix anpassen)
ˆ Algorithmus stoppt , falls sich alle Objekte in einem Cluster befinden.
Es sind natu¨rlich noch andere Kriterien vorhanden wie(vgl. [Jos06]):
ˆ Stochastische, die zufa¨llige Prozesse verwenden. Z.B. zufa¨llige Anfangssituation
ˆ Deterministische, die keine zufa¨lligen Prozesse verwenden.
ˆ Exakte, die jedes Objekt genau einem Cluster zugeordnen.
ˆ Fuzzy Algorithmen, die Zugeho¨rigkeit von Objekten zu Clustern u¨ber prozentuale Werte
ausdru¨cken.
Beispiel:
Aufgabe: Bestimme Cluster nach k-means (hier k = 2) Verfahren, nutze den euklidschen Ab-
stand und wa¨hle als Zentroiden (6, 5) und (11, 10).
Schritt Eins: B ={(2, 4), (2, 8), (4, 9), (7, 7), (11, 10), (11, 7), (6, 5), (9, 2), (12, 5), (14, 4)}
C1 ={(6, 5), (2, 4), (2, 8), (4, 9), (7, 7), (9, 2)}
C2 ={(11, 10), (11, 7), (14, 4), (12, 5)}
Berechne neue Zenroiden und fahre fort bis sich die Cluster nicht mehr a¨ndern. Wa¨hle neue
Zentroiden
C1 ={(6, 5), (2, 4), (2, 8), (4, 9), (7, 7)}
C2 ={(11, 10), (11, 7), (14, 4), (12, 5), (9, 2)}
Supervised Clustering Bei diesem Verfahren wird angenommen, dass die Klassenstruktur
schon bekannt ist. Dies wird in einer so genannten Trainingsphase ermittelt. Danach werden
einige Instanzen mit Bezeichnungen (Markierungen) genommen und den jeweiligen Klassen
zugeordnet. Diese Bezeichnungen werden Labels genannt und ermo¨glichen eine pra¨zise und
gezielte Zuordnung fu¨r neue Objekte. Somit kann der Nutzer die Beziehungen zwischen den
Objekten erkennen und sieht warum diese zusammen gruppiert werden(vgl. [DC03]).
77
Unsupervised Clustering In diesem Verfahren kennt der Nutzer die Klassenstruktur nicht
und hierbei sind keine Informationen und kein Hintergrundwissen vorhanden. Die Daten sind
unbezeichnet und sollen nach einem A¨hnlichkeitsgrad gruppiert werden, wobei das Auffinden
eines geeigneten Kriteriums den gr”o¨ßten Aufwand darstellt. Eine mo¨gliche Hilfe fu¨r das
Finden einer guten Gruppierung sind Beobachtungen und Experimente(vgl. [DC03]).
Semi-supervised Clustering Dieses neue Verfahren liegt zwischen den beiden oben genann-
ten Verfahren. In die Clusteranalyse wird Hintergrundwissen integriert, um die resultierenden
Cluster zu verbessern und um die Laufzeit fu¨r die Berechnung von Clustern zu reduzieren.
Das Hintergrundwissen wird in Form von Constraints (Bedingungen) in die Clusteranalyse
mit eingefu¨gt. Der Nutzer gibt Constraints in das System ein und kann Angaben machen,
ob Objekte in das selbe Cluster geho¨ren oder nicht. Durch diese Einschra¨nkungen wird der
Lo¨sungsraum begrenzt und der Suchraum reduziert. Außerdem hat der Nutzer die Mo¨glich-
keit die Clusteranalyse zu steuern, um eine mo¨glichst gute Partitionierung der Objekte zu
erzielen. Semi-supervised Clustering steht in Beziehung zum aktiven Lernen, aber es unter-
scheidet sich von Diesem durch die Wahl der Datenpunkte, welche die meisten Informationen
liefern und somit eine gute Partitionierung ermo¨glichen. Der Nutzer wa¨hlt die Datenpunkte
selbst und bestimmt auf diese Weise eine Anzahl von Bedingungen, wobei das System nun
die Menge von Objekten nach diesen Bedingungen clustert(vgl. [DC03]).
Ein Vorteil dieses Verfahrens ist es, dass dem Nutzer die Mo¨glichkeit gegeben wird mit dem
System zu interagieren und mit den Daten zu arbeiten, um diese besser verstehen zu ko¨nnen.
Dadurch lernt das System Kriterien, um den Nutzer zufriedenzustellen. Ein weiterer Vorteil
ist es, dass das System keine Funktionseingaben des Nutzers erwartet, um die Kriterien, die
der Nutzer im Kopf hat, zu erfu¨llen. Der Nachteil dieses Verfahrens ist, dass es viele mo¨gliche
Bedingungen gibt, die in das System eingegeben werden ko¨nnen (vgl. [DC03]).
Wann sollte Semi-supervised Clustering bevorzugt werden?
Existieren verschiedene und gleichwertige Clusterings, so wu¨rde ein aktiv lernendes System
viele unno¨tige Anfragen stellen und nicht-zufriedenstellende Cluster erzeugen. Ein weiterer
nennenswerter Punkt wa¨re, die Bevorzugung des Verfahrens, bei unbekannter Anordnung der
End-Cluster, denn Constraints sind einfacher zu verstehen als Labels. Falls die Labels nicht
leicht fu¨r die Clusteranalyse benutzbar sind, wa¨re dies ein weiterer Aspekt fu¨r die Wahl des
Verfahrens(vgl. [DC03]).
Constraints Sind Bedingungen, die der Nutzer dem System vorgibt, und die auf jeden Fall
eingehalten werden mu¨ssen. Es sind verschiedene Arten von Constraints vorhanden, als Bei-
spiel sind die Instance-Level Constraints zu nennen. Diese machen Aussagen u¨ber die Be-
ziehung der einzelnen Objekte(vgl. [Ebe06]). Noch erwa¨hnenswert wa¨ren σ- Constraints (ein
beliebiges Paar von Datenpunkten aus zwei verschiedenen Clustern, die eine Mindestdistanz
σ haben) und γ- Constraints fu¨r hierarchisches Clustering (zwei Cluster, deren Zentroiden
eine Distanz gro¨ßer γ zueinander haben, ko¨nnen nicht fusioniert werden)(vgl. [Zho06]).
Haupttypen In diesem Abschnitt werden zwei Haupttypen von Instance-Level Constraints
unterschieden. Zum Einen: Must-Link Constraints die festlegen, dass zwei Objekte in das sel-
be Cluster geho¨ren und zum Anderen: Cannot-Link Constraints, welche festlegen, dass zwei
78
Objekte nicht in das selbe Cluster geho¨ren. Aus diesen Aussagen kann man schlussfolgern,
dass diese Constraints Aussagen u¨ber die paarweise Beziehung zwischen zwei Objekten der
selben Menge machen (vgl. [Ebe06]).
Beispiele:
ˆ Ein Beispiel fu¨r die Beziehungen der Objekte(vgl. [Ebe06]):
Falls ML(a, b) und ML(b, c) => ML(a, c) aber auch Aussagen u¨ber CL mo¨glich.
ˆ Clusterprozess mit Einbindung von Constraints (vgl. [Ebe06]):
Dazu nehme ich einen k-means partitionierten Cluster . Die Bedingungen werden in die
Clusteranalyse integriert, um Verbesserungen bzgl. der Laufzeit, der Genauigkeit und
Leistung zu erreichen.
Allgemeine Werte und Ablauf der Methode:
– Datensatz D
– Satz Must-Link Constraints (CON=) und Satz von Cannot-Link Constraints (CON 6=)
– Methode VIOLATE-CON angelegt worden, die einen Wahrheitswert zuru¨ck gibt.
Wenn die Ausgabe dieser Methode true ist bedeutet das, dass durch die Zuteilung
ein Constraint verletzt wurde. Sollte jedoch false zuru¨ckgegeben werden, ist die
Einordnung von di in Cj gu¨ltig.
Methoden Schritte:
1. ob ein Must-Link Constraint existiert der die zu clusternde Instanz d entha¨lt,
dessen Contraint-Partner d= bereits klassifiziert wurde. Diese ist jedoch nicht in
dem Cluster C, in das d eigentlich gruppiert werden soll. Eine solche Situation
wu¨rde zu der Ausgabe true fu¨hren.
2. Sollte jedoch ein Cannot-Link Constraint verletzt sein, dann wurde eine Instanz
d6= gefunden, die bereits im Cluster C platziert wurde. Das macht es unmo¨glich,
dass d ebenfalls nach C geordnet wird.
3. Nur fu¨r den Fall, dass kein spezifizierter Constraint verletzt wird, liefert V IOLATE−
CON false und damit kann COP -K-Means den Datenpunkt di dem Cluster Cj
zuteilen. Offensichtlich kann mit dieser Methode auch der Fall eintreten, dass kei-
nes der vorhandenen Cluster so gefunden werden kann, dass kein Instance-Level
Constraints aus (CON=) oder (CON 6=) verletzt wird. Bei solch einem Fall wird
der Algorithmus abgebrochen.
79
1 Seien c1, c2, · · · , ck die initialen Clusterzentren.
2 repeat (fu¨r alle Instanzen di ∈ D):
3 ordne di dem Cluster Cj zu, dessen Clusterzentrum di am
na¨chsten ist , so dass
V IOLATE − CON(di, Cj , (Con=), (CON 6=)) = false ist. WENN kein
solches Cluster gefunden werden kann , DANN FAIL (RETURN {}).
5 Fu¨r alle Cluster Ci: Update Clusterzentrum: ci 1|ci|
∑
dj∈Ci
dj
6 Schritt (2) und (3) solange wiederholen , bis Clustermengen
sich nicht a¨ndern.
7 Return \{c1, c2, · · · , ck\}:
Listing 1.2: COP-K-Means
V IOLATE−CON : (Datenpunkt d,Cluster C,Must-Link Constraints (CON=) ⊆ D×
D,Cannot-Link Constraints (CON 6=) ⊆ D ×D)
1. Fu¨r alle (d, d=) ∈ CON= : FALLS d= /∈ C : RETURN true.
2. Fu¨r alle (d, d6=) ∈ CON 6= : FALLS d6= ∈ C : RETURN true.
3. Sonst RETURN false.
ˆ Das Yahoo-Problem(vgl. [DC03]):
Bei diesem Problem geht es darum 100.00 Dokumente ( Texte, Artikel, usw.) in passende
Gruppen zu partitionieren. Es wird auch nicht angegeben welche Klassenbezeichnungen
verwendet werden sollen (z.B. Sport, Technik, Politik).
Der Lo¨sungsansatz lautet wie folgt:
1. Die Dokumente in unsupervised clustering Algorithmus geben und clustern lassen
2. User geht Cluster durch und sagt dem System welches Cluster er mag oder nicht
mag.
=¿ Nicht fu¨r alle Cluster tun sondern nur einige. Gebe Feedback hinzu:
– das Dokument geho¨rt nicht hier hin
– bewege das Dokument zu diesem Cluster
– Die Dokumente in selbe oder unterschiedliche Cluster zuordnen.
=¿ nicht fu¨r alle sondern nur fu¨r diejenigen die am unpassensten sind
3. Nach der Kritik, neu Clustern lassen mit Feedback.
4. Wiederholen bis zufrieden!
Feedback Dieser Abschnitt behandelt die Verwendung von Constraints als Feedback. (vgl.
[DC03]). Diese Constraints ko¨nnen verschiedene Auspra¨gungen haben:
ˆ Zwei Dokumente geho¨ren oder geho¨ren nicht ins selbe Cluster.
80
ˆ Ein Dokument geho¨rt oder geho¨rt nicht in dieses Cluster.
ˆ Bewege das Dokument in dieses Cluster.
ˆ Cluster zu grob oder zu fein.
ˆ Cluster ist gut oder nicht gut.
ˆ Diese Bedingungen werden an individuell gewa¨hlten Punkten eingesetzt und es sollte
vermieden werden clusterspezifische Feedbacks zu geben.
Vergleich der Performance Es ist grundsa¨tzlich schwierig Supervised und Semi-supervised
Clustering zu vergleichen. Denn zum Einen, wird zwischen Constraints und Labels unterschie-
den und zum Anderen wird bei Supervised Clustering nicht die gesamte Menge der Objekte
betrachtet. Die in der Trainingsphase benutzten Objekte sind schon markiert und mu¨ssen
nicht mehr bearbeitet werden, mit anderen Worten, es existiert eine preprocessing Phase im
Supervised Clustering. Diese berechnet die Klassenbezeichnungen, an Hand deren partitio-
niert wird. Dennoch versuchen wir die Verfahren miteinander zu vergleichen, indem wir die
Prozentzahl der korrekt eingeordneten Objekte messen. Wobei hier noch wichtig ist, dass nach
und nach Labels oder Constraints mit in die Analyse eingebracht werden. Nachdem 10 Cons-
traints eingefu¨gt wurden, wird die asymptotische Performance erreicht. Es werden 70-80%
der Objekte korrekt partitioniert. Aber mit Zunahme von Constraints wird keine Verbesse-
rung mehr erreicht. Um die gleiche Performance zu erreichen, beno¨tigt Supervised Clustering
3 bis 6 fach mehr Labels. Aber desto mehr Labels verwendet werden desto besser wird die
Performance dieses Verfahrens. Das Unsupervised Clustering hat eine Korrektheit von 50%,
also hat es eine geringere Genauigkeit(vgl. [DC03]).
Zusammenfassung und Fazit In dieser Ausarbeitung wurde ein neues Vefahren dargestellt
und die jeweiligen Vorteile, die es bei der Benutzung, mit sich bringt. Es wurden Fa¨lle be-
schrieben in denen es sinnvoll ist ein bestimmtes Verfahren den jeweils anderen vorzuziehen.
Grudsa¨tzlich hat der Nutzer mit Hilfe von Hintergrundwissen in Form von Constraints die
Mo¨glichkeit sich in den Clusterprozess miteinzubinden und mit dem System zu interagieren.
Dadurch wird eine mo¨glichst gute Partitionierung der Objekte erreicht. Das System hat die
Mo¨glichkeit vom Nutzer zu lernen, um diesen zufriedenzustellen. Also kann das menschliche
Vorgehen ein wegweisendes Verfahren werden, um Zusammenha¨nge innerhalb von Gruppen
zu entdecken. Das eigentliche Ziel des Semi-Supervised Verfahrens ist es jedoch Wege zu fin-
den, wie Feedback wa¨hrend des Clusteringprozesses in die Verarbeitung eingebunden werden
kann.
SVM Clustering
Die Idee Die Idee bei Supervised Clustering ist, dass man fertig geclusterte Itemsets gege-
ben hat und jetzt die Fa¨higkeit erlernen mo¨chte, weitere Itemsets richtig zu Clustern.
Der Lo¨sungsansatz ist hierbei, dass man die SVM zum Trainieren des Cluster-Algorithmus
benutzt.
Das Problem beim Clustering liegt darin zu erkennen: welche Items sind sich
”
a¨hnlich“, was
bedeutete
”
a¨hnlich“ eigentlich genau, und wie definiert man es. Außerdem muss der Benutzer
mit seinen Beispielsets mo¨glichst viele Mo¨glichkeiten abdecken, um gute Lernergebnisse zu
81
erzielen.
Formal:
gegeben: n Trainingssets : (xi, yi)...(xn, yn) ∈ X × Y
X sind alle Items.
Y alle mo¨glichen Partitionen von X.
gesucht: Clusterfunktion: h:X → Y
Hilfsmittel:
Verlustfunktion: ∆ : Y × Y → R
vergleicht zwei Clusterings
Trainingserror: ∆(h(x), y)
fu¨r ein Beispiel (x,y) und Clusterfunktion h
Paarweise Klassifikation Alle Items werden paarweise verglichen und jedes Paar wird durch
einen Eigenschaftsvektor beschrieben. Der Ausgabewert gibt an, ob die Items im selben Clus-
ter sind oder nicht. Positive Beispiele sind die in einem Cluster. Negative die, die nicht in
einem Cluster sind.
Wenn nicht eindeutig klar ist, ob ein Paar im gleichen Cluster ist oder nicht, kann der paarwei-
se Klassifizierer nicht nach dem geforderten Leistungsmaß optimieren. Die Anzahl von Paaren
in einem Cluster ist oft sehr gering. Deshalb ko¨nnen sie unterbewertet werden. Der Vorteil
von Abha¨ngigkeiten der einzelnen Paare kann nicht genutzt werden. Es gibt Methoden um
diese Probleme zu beseitigen, allerdings sind bisher alle nur Heuristiken.
Cohen & Cardie: lernen nur auf Paaren, die sich a¨hnlich sind.
Ng & Cardie: basiert auf Zusammenha¨ngen von Ausdru¨cken:
xb + xa werden pos. Paar,
xa ist der Ausdruck,
der am na¨chsten vor xb auftaucht
und mit xb in Verbindung steht.
Alle Ausdru¨cke zwischen xa und xb
werden mit xb zu negativen Paaren
Modell Grundsa¨tzlich wird an der Methode fu¨r das Supervised Clustering nichts gea¨ndert.
Es wird nur das A¨hnlichkeitsmaß modifiziert, so dass der Algorithmus die erwu¨nschten Er-
gebnisse liefert.
Das A¨hnlichkeitsmaß Simw bildet Itempaare auf Werte ab. Positiv = a¨hnlich; negativ =
una¨hnlich.
∀ : (xa, xb); xa, xb ∈ x; xa 6= xb ∃ : ∅(xa, xb) ≡ ∅a,b
A¨hnlichkeitsmaß: Simw(xa, xb) = wT∅a,b
∅: Eigenschaftsvektor der Paare.
w: Parameter fu¨r das A¨hnlichkeitsmaß.
82
1 Imput: (x1, y1), ..., (xn, yn), C, 
2 Si ← ∅ fu¨r alle i = 1, ..., n
3 repeat
4 for i = 1, ..., n \textbf{do}
5 H(y) ≡ ∆(yi, y) + wTΨ(xi, y)− wTΨ(xi, yi)
6 berechne: yˆ = argmaxy∈YH(y)
7 berechne: ξi = max{0, maxy∈SiH(y)}
8 if H(yˆ) > ξi +  \textbf{then}
9 Si ← Si ∪ {yˆ}
10 w ← Optimiere u¨ber S =
⋃
i SI
11 end if
12 end for
13 until kein Si hat sich wa¨hrend des Durchlaufs gea¨ndert
Listing 1.3: SVMStruct Version2
Fu¨r die Cluster Methode benutzt man: Corellation Clustering(Bansal 2002) Fu¨r ein Itemset
x wird das Clustering y gesucht, so dass die Summe der A¨hnlichkeitswerte maximal ist.
argmaxy
∑
y∈y
∑
xa,xb∈y
Simw(xa, xb)
Durch dieses Vorgehen kann es allerdings vorkommen, dass Paare, die eigentlich nicht in ein
Cluster geho¨ren, zusammengefasst werden, da der Netzeffekt einen Gesamtvorteil liefert.
∑
y∈y
∑
xa,xb∈y
Simw(xa, xb) =
∑
y∈y
∑
xa,xb∈y
wT∅a,b = wT (
∑
y∈y
∑
xa,xb∈y
∅a,b)
Die Zielfunktion ist also ein Linearprodukt von w und einer Summe von ∅ Vektroren. Auch
wenn man Corellation Clustering benutzt, ist jede Zielfunktion, die ein Linearprodukt von w
ist, erlaubt.
argmaxy∈YH(y) liefert die am meisten verletze Nebenbedingung, wobei ∆(y, yˆ) der Wert-
verlust zwischen dem wirklichen Cluster y und dem vorhergesagten yˆ ist, und Ψ(xi, y) =
1
|xi|
2
∑
y∈y
∑
xa,xb∈y
∅(xa, xb).
Wenn die Nebenbedingung mehr als  verletzt wird, wird sie u¨bernommen und es wird neu
optimiert.
Dies wird solange wiederholt, bis keine Nebenbedingung mehr hinzukommt.
Theorem 1:
Wenn ∆ = max(xi,yi)∈S(maxy∆(yi, y)) und R = max(xi,yi)∈S(maxy ||Ψ(xi, yi)−Ψ(xi, y)||)
dann konvergiert die SVMstruct nach max{2n∆ ,
8Cn∆R
2
2 }
Theorem 2:
Der Algorithmus liefert ein approximiertes Ergebnis, das kleiner oder gleich dem quadrati-
schen Programm der SVMstruct ist. Alle Nebenbedingungen sind im Rahmen von  erfu¨llt.
83
Approximation Es stellt sich jetzt die Frage, wie schwer es ist, die meist verletzte Nebenbe-
dingung zu finden?
H(y) ≡ ∆(yi, y) + wTΨ(xi, y)−wTΨ(xi, yi)
Der letzte Teil bleibt immer gleich, und kann vernachla¨ssigt werden, so dass sich das Ma-
ximum nicht a¨ndert. Es bleibt also die Kostenfunktion, die sich aus dem Verlust zwischen
korrekten Clustering yi und dem vorhergesagten y sowie der Zielfunktion des Correlation
Clusterings zusammensetzt. Das Finden des y fu¨r die Zielfunktion ist NP-vollsta¨ndig (Ban-
sal,2002) und den Verlust zu Addieren bringt keinen Vorteil. Also ist das Problem die meist
verletzte Nebenbedingung zu finden auch NP-vollsta¨ndig. Wir betrachten deswegen zwei Ap-
proximationsmo¨glichkeiten fu¨r die Clusterfunktion und damit fu¨r argmaxyH(y).
Greedy Approximation CG Zu Beginn ist jedes Item in einem eigenen Cluster, jetzt werden
zwei Cluster vereinigt, so dass H(y) maximal erho¨ht wird. Der Algorithmus terminiert, wenn
keine Vereinigung eine Erho¨hung von H(y) bewirkt.
Korollar: Das Ergbenis der Greedy-Approximation CG ist nicht gro¨ßer als das der SVMstruct.
Relaxation Approximation, CR Jedes Paar xa, xb hat eine Variable ea,b die anzeigt, zu wel-
chem Maß die Items in das gleiche Cluster geho¨ren.ea,b ∈ [0, 1] ea,b = eb,a ea,b + eb,c ≥ ea,c.
Man erha¨lt also ein lineares Programm: maxe
∑
ea,b∈e
(ea,b) ·(wT∅a,b) und damit ein Ψ(x, e) =
1
x
∑
ea,b∈e
(ea,b)·∅a,b. Dies ist die gleiche Funktion wie Ψ(xi, y) = 1|xi|2
∑
y∈y
∑
xa,xb∈y
∅(xa, xb),
wenn ea,b ganzzahlig ist.
Korollar: Das Ergebnis der Relaxation Approximation CR ist nicht kleiner als das der SVMstruct.
Fu¨r die Experimente wurde C∗R benutzt. Hierbei hat zu Beginn jedes Item ein eigenes Cluster,
dann wird u¨ber alle xa ∈ x iteriert, wenn xa alleine im Cluster ist wa¨hle es aus. Als na¨chstes
sucht man alle xb ∈ x die auch alleine in einem Cluster sind und Vereinigt sie mit xa, wenn
ea,b > 0, 7
Verlustfunktionen Fu¨r die Experiemente stehen zwei Verlustfunktionen zur Verfu¨gung zum
Einen paarweise ∆P und zum Anderen MITRE Verlust ∆M .
∆P (y, y) = 100WT wobei, T die Anzahl von Paaren im Itemset ist und W die Anzahl von
Paaren ist, bei denen y und y nicht u¨bereinstimmen. Bei Relaxation Approximation wird
ea,b · (wT∅a,b + 100T ) verwendet.
∆M (y, y) = 100
2(1−R)(1−P )
(1−R)+(1−P ) wobei R der MITRE recall ist und P die MITRE precision. ∆M
kann als Anzahl von no¨tigen Transformationsschritten angesehen werden, um von y nach y
zu gelangen. Eine Schritt ist entweder das Teilen oder das Vereinigen von Clustern.
Experimente Als Testmaterial wurden zum Einen die MUC-6 noun-phrase Daten benutzt
zum Anderen eine Auswahl aus den Google-News. Die MUC-6 Daten bestehen aus 60 Do-
kumente, wovon 30 als Traingsdaten und 30 als Testdaten benutzt wurden. Jedes Dokument
84
hat im Schnitt 101 Cluster mit durchschnittlich je 1,48 Wo¨rtern. Es gibt aber auch viele
Einzelwort-Cluster. Der Eigenschaftsvektor der Paare hat 53 Dimensionen, wie zum Beispiel:
Ob die Worte mit dem gleichen Artikel auftauchen, wieviele Sa¨tze sie voneinander entfert
sind, ob eins der Worte ein Subjekt im Satz ist, etc.
Fu¨r die Google-News Daten wurden 30 Tage lang die Top 10 Themen der
”
World“ Kategorie
ausgewa¨hlt und von jeder Kategorie soweit mo¨glich 15 Artikel ausgewa¨hlt. Die ersten 15 Tage
waren Trainingsdaten und die lezten die Testbeispiele. Jeder Artikel hat 30 TFIDF gewichtete
Vektoren fu¨r Unigramme, Bigramme, Trigramme, etc. Der Eigenschaftsvektor ist der Cosinus
zwischen den Vektoren der Artikel plus einer Eigenschaft, die immer 1 ist.
Testergebnisse bei MUC-6
CG PCC Default
Test mit CG,∆M 41,3 51,6 51,0
Test mit CG,∆P 2,89 3,15 3,59
Spalte CG : - mit SVM-Cluster und Greedy Algorithmus gelernt
Spalte PCC: - mit PCC gelernt
Spalte Default: - in der ersten Zeile alle Items in einem Cluster
- in der zweiten jedes Item in eigenem Cluster
Zeile 1: getestet und optimiert mit MITRE Verlustfunktion
Zeile 2: getestet und optimiert mit paarweiser Verlustfunktion
Beide Tests benutzen den Greedy Algorithmus auf der Testmenge.
Es ist ganz klar zu erkennen, dass die SVM deutlich besser ist, als der Rest. Bei ∆M kann man
das dadurch erkla¨ren, dass die SVM fu¨r eine Verlustfunktion optimieren kann, PCC nicht.
Bei ∆P la¨sst sich allerdings so nicht argumentieren, da PCC quasi gleich optimiert, trotzdem
ist die SVM besser.
Testergebnisse bei Google News
CG CR PCC Default
Test mit CG,∆P 2,36 2,43 2,45 9,45
Test mit CR,∆P 2,04 2,08 1,96 9,45
Bei diesen Daten sieht man, dass keine Mehtode deutlich besser ist als die andere. Man
kann also schlussfolgern, dass die SVM besser zu sein scheint, wenn die Daten transitive
Abha¨ngigkeiten haben. Wenn nicht, sind beide Methoden anna¨hernd gleich gut.
Optimierung fu¨r Verlustfunktionen
Opt. to ∆M Opt. to ∆P
Performance bei ∆M 41,3 42,8
Performance bei ∆P 4,06 2,89
Es gibt kaum Unterschiede bei der ∆M Performance, aber bei ∆P sind die Performanceun-
terschiede recht deutlich. Außerdem sind die Werte des fu¨r ∆M optimierten Modells nicht
besser, als die der Defaultwerte. Als Schlussfolgerung kann man also festhalten, dass die Wahl
der Verlustfunktion nachhaltig die Accurracy des Modells beeinflussen kann.
85
Verlust bei argmaxyH(y) Muss die Verlustfunktion in argmaxyH(y) integriert sein oder
darf man sie hier vernachla¨ssigen?
mit Verlusfunkt. ohne Verlustfunkt.
MUC-6, ∆M 41,3 41,1
MUC-6, ∆P 2,89 2,81
Google, train CG, test CG 2,36 2,42
Google, train CR, test C∗R 2,08 2,16
Es gibt keine signifikante A¨nderung in den Zeilen, bei keinem Modell. Dies la¨sst den Schluss
zu, dass die Verlustfunktion in argmaxyH(y) nicht zwingend erforderlich ist.
Greedy vs. Relaxation Als letztest stellt sich die Frage, welche Approximation besser ist.
Train CG Train CR
Test CG 2,36 2,43
Test CR 2,04 2,08
Auch hier sind kaum Unterschiede zu erkennen. Es ist keine der Approximationen ist zu be-
vorzugen.
Effizienz der SVMcluster Auf dem MUC-6 Material werden u¨ber 1000 Nebenbedingungen
integriert und es wird 50 mal neu optimiert. Mit CG wurde nur 1% der Zeit beno¨tigt.Bei allen
Experiementen hat keine SVMcluster la¨nger als 3-4 Stunden gebaucht, wobei der Durchschnitt
eher unter einer Stunde lag. Als Vergleich dient der paarweise Klassifizierer. Dieser bearbei-
tete eine knappe halbe Million Paare im Trainingsset. Hierfu¨r beno¨tigte er eine halbe Woche
und es wurden eine halbe Million Nebenbedingungen eingefu¨gt.
Zusammenfassung Die SVM ist je nach Material gleich oder besser als PCC. Die Wahl der
Verlustfunktion ist entscheidend fu¨r die Accurracy, in Abha¨ngigkeit vom Modell. Der Verlust
in argmaxyH(y) kann vernachla¨sigt werden. Keine der Approximationen ist eindeutig besser.
Fasst man alle Erkenntnisse zusammen ist die SVMcluster mit einem Approximationsalgorith-
mus fu¨r die Geschwindigkeit die beste Wahl.
1.5 Relation Extraction auf unstrukturierten Texten
1.5.1 Einfu¨hrung
Relationen sind Beziehungen, also Verknu¨pfungen zwischen Entita¨ten oder Daten. Sie sind
uns aus Graphen, Datenbanken und Diagrammen bestens bekannt und vertraut. Das
”
in
Beziehung“ setzen von Entita¨ten wird u¨blicherweise entweder durch ein Modell induziert,
siehe Datenbanken, oder geschieht manuell wie im Fall von Diagrammen. Die automatische
Erstellung von Relationen aus unstrukturierten Daten nennt man
”
Relation Extraction“.
86
Abbildung 1.28: Relation zwischen zwei Objekten.
In der Literatur ordnet man Relation Extraction meistens als Teilgebiet der folgenden For-
schungsbereiche ein:
ˆ SRL
”
Statistical Relational Learning“ einer Disziplin des maschinellen Lernens
ˆ ILP
”
Inductive Logic Programming“ also der konventionellen Logik Programmierung.
Wir wollen uns in diesem Teil der Ausarbeitung mit den graphischen Modellen und statis-
tischen Kernel Methoden bescha¨ftigen. Doch zuna¨chst einmal eine kurze Einfu¨hrung in die
graphischen Darstellungen von Relationen.
Relationen sind bekanntermaßen Beziehungen zwischen Objekten und ko¨nnen als Graph dar-
gestellt werden. In unserem Anwendungsfall sind die Wo¨rter eines Satzes Objekte und die
semantischen Beziehungen zwischen den Wo¨rtern sind die zu extrahierenden Relationen, in
diesem Sinne die Kanten des Graphen.
Natu¨rlich sind nicht alle Wo¨rter eines Satzes relevante Objekte. Im Normalfall werden nur die
Nomen, in unserem Fall, die zuvor extrahierten “Named Entities
”
als Objekte betrachtet. Es
liegt Nahe die Relation aus den Wo¨rtern zwischen den Objekten zu extrahieren. Die Aufgabe
der Extraktion kann somit genauer als Analyse der Wo¨rter und die gleichzeitige Bildung einer
Beziehung zwischen zwei benachbarten Entita¨ten beschrieben werden.
Die extrahierten Relationen, besonders auf eindeutigen Entita¨ten, bilden einen Extraktions-
graphen der die Beziehungen zwischen den Entita¨ten auf dem gesamten Text aufspannt. Es
existieren verschiedene Darstellungen des Graphen, Cafarella za¨hlt eine Hierarchie der Kom-
plexita¨t und Ma¨chtigkeit dieser Graphen auf:
ˆ Die komplexeste und erscho¨pfende Darstellung des Grafen bilden Semantische Netze,
wie sie auf den Webseiten von John F. Sowa beschrieben sind. Semantische Netze sind
die klassische, aus der Psychologie stammende Abbildung kategorisierter semantischer
Relationen. Die Betonung liegt hier auf den semantischen Beziehungen zwischen den
Entita¨ten.
ˆ Entity Relationship Diagramme, kurz ER-Diagramme sind die relaxierte Betrachtung
der semantischen Netze. Die von Chen und Bachmann eingefu¨hrten Modelle sind die
wohl bekannteste Darstellung von relationalen Datenbanken. Die Darstellung kennt nur
wenige Kategorien der Beziehungen und konzentriert sich auf den Quantita¨ten der Ver-
bindungen und deren Hierarchie.
ˆ Die schwa¨chste Form der Darstellung ist aus dem Internet bekannte Link Graph, auch
Citation Graph genannt. Dieser Graph besteht aus Dokumenten kennt nur eine Form
der Relationen, na¨mlich den weiterfu¨hrenden Link auf ein anderes Dokument und wurde
Ausfu¨hrlich in den Arbeiten von Page, Brin und Kleinberg beschrieben.
87
Abbildung 1.29: Semantisches Netz (www.conroeisd.net)
Abbildung 1.30: Chen und Bachmann Diagramme (de.wikipedia.org)
88
Die Defintion eines Graphen der aus Knoten, in unserem Fall NE’s, besteht, sowie die Defi-
nition der Kanten als Relationen wird hier nicht aufgefu¨hrt, da sie bereits aus den vorange-
gangenen Ausarbeitungen bekannt sein sollte.
1.5.2 Anwendungsbeispiel: TEXTRUNNER
Ein praktisches Beispiel der Anwendung von ’Relation Extraction’ Techniken ist TEXTRUN-
NER. Dieses Server basierte System von Cafarella, Banko und Etzioni zur relationalen Websu-
che, nutzt das domainunabha¨ngige Internet als Corpus und extrahiert ohne menschliches Ein-
greifen Relationen aus Texten. Im Vergleich zu anderen Systemen, wie KNOWITALL [DA04]
oder AskMSR [JA02] ist TEXTRUNNER auf die schnelle Verarbeitung von großen, domainu-
nabha¨ngigen Corpora ausgelegt. Skallierbarkeit und vergleichbar schnelle
”
single-pass“ Verar-
beitung sind zwei wichtige Argumente die dessen breite Nutzung als Suchmaschine in Aussicht
stellen.
Wie bereits erwa¨hnt extrahiert TEXTRUNNER mit einfachen, recht wenigen Methoden, Re-
lationen aus Texten und baut aus ihnen einen
”
Extraction Graphen“ auf. Dieser Graph ist
eine textuelle Approximation des Entity Relationship Diagramms, kann also in der Hierar-
chie der semantischen Netze zwischen den ER-Diagrammen und Link Graphen eingeordnet
werden. Der Extraction Graph bildet eine Zwischenstufe in der Repra¨sentation von Informa-
tionen und zeigt gerade die Informationen, die explizit nicht im Inverted Index stehen. Diese
neue Suchmethode geht weit u¨ber die Stichwortsuche hinaus, was mit dieser erweiterten Da-
tenstruktur auch nicht weiter verwundert. Beim Aufbau des Extraction Graphen wird in der
na¨chsten Na¨he der Entita¨ten nach den Verbindungen, ergo Relationen gesucht. Hierbei wird
das Theorem aufgestellt das miteinander verbundene Entita¨ten auch lexikalisch nahe bei ein-
ander liegen werden. Es muss also nur der Text zwischen den Entita¨ten untersucht werden.
Das Auffinden und Markieren von Entita¨ten in einem Text ein hierbei kein separater Schritt
vor der eigentlichen Relation Extraction, sondern geschieht simultan.
Datenstruktur: Extraction Graph
Der Extraction Graph wird exklusiv aus dem vorliegendem Text generiert. Seine Knoten
und Kanten bestehen aus Wo¨rtern (Strings). Im Gegensatz zu einem semantischen Netz sind
die vorhandenen Relationen oder Entita¨ten nicht Eindeutig, das bedeutet, dass die selben
realen Objekte verschieden repra¨sentiert werden ko¨nnen. Es existieren keine Mechanismen
um logische Inkonsistenzen zwischen Begriffen zu beheben.
Es sei ein gerichteter Graph, der, wie bereits bekannt, aus Knoten und Kanten besteht. Die
Knoten bilden die Entita¨ten ab und die Kanten stellen logischerweise die Relationen zwischen
den Entita¨ten dar. Die Relationen sollen als ein Tripel aus zwei Knoten und einer Kante
definiert werden:
ˆ Eine Relation im Extraction Graph ist ein Tripel tx = (ni, ei,j , nj).
ˆ mit n ∈ V , V 6= ∅ und Knotenmenge.
ˆ mit e ∈ E , E als Menge der Kanten.
ˆ Der Graph kennt nur zwei Kategorien / Typen von Kanten:
89
Abbildung 1.31: Darstellung des Extraction Graphen
– Eine isA Relation zwischen zwei Knoten, die u¨blicherweise als ist-Bezeichner eines
Knoten dient.
”
Oppenheimer - isA - American Sciencist“ sei ein Beispiel fu¨r eine
ist Relation dieser Form.
– Alle anderen denkbaren Relationen werden als predicate Relation abgebildet. Da es
sich bei diesen Relationen um Text Labels handelt sind sie flexibel genug um vie-
le Beziehungen darzustellen, allerdings kann man in diesem Zusammenhang nicht
wirklich von einer semantischen Relation sprechen.
”
Berkeley - hired - Oppenhei-
mer“ ist ein typisches Beispiel fu¨r eine derartige Kategorie.
ˆ Zusa¨tzlich wird zu dem Tripel die Anzahl seiner Vorkommen im Text gespeichert.
ˆ Jedem Tripel wird sein Inhalt als String zugeordnet.
Wie die formelle Definition des Graphen zeigt, beschra¨nkt sich die Semantik nur auf die isA
Beziehung. Alle anderen Beziehungen werden nur sehr abgeschwa¨cht dargestellt.
Extraktion der Kanten aus dem Text
Optimal wa¨re es die Extraktion in einem einzigen Lauf u¨ber das Dokument zu realisieren.
Diese Vorgabe ist vermutlich der Grund fu¨r diese einfache und relaxierte Betrachtung der
Kanten. Eine Kante kann trivialer-weise aus allen Wo¨rtern zwischen zwei Entita¨ten bestehen.
Dies wu¨rde jedoch die Suche einer Relation auf die einfache Stichwortsuche reduzieren. Die
Genauigkeit der Antworten auf gestellte Queries wu¨rde erheblich leiden. Alternativ ko¨nnte
man mit morphologischen Mitteln nur Verben extrahieren, was wiederum zu einschra¨nkend
90
wa¨re. Die TEXTRUNNER Vorgehenswiese ist eine Lo¨sung die zwischen beiden Ansa¨tzen
liegt, hierbei werden u¨berschaubar wenige linguistische Mittel genutzt um die Kanten zu
extrahieren.
ˆ Um eine
”
isA “ Relation zu identifizieren werden die Wo¨rter zwischen zwei Entita¨ten mit
einer adaptierten Version der Hearst Methode [Hea99] zur Entdeckung von Hypernymen
mit Hilfe von lexikalischen Mustern. Diese Art der Kante impliziert die Exsistenz einer
”
ist Oberbegriff von“ impliziert. Dabei werden diese Kanten automatisch kunstruiert.
ˆ Der Algorithmus der eine
”
predicate“ Relation aus den Inhalten extrahiert findet im
ersten schritt den wahrscheinlichsten Part-of-Speech Tag fu¨r die Wo¨rter. Danach wer-
den mit einem Ausdrucksegmentierer die Nomen in diesem Satz gesucht, die Nomen
werden direkt zu Knoten umgewandelt. Die lexikalische POS Distanz zwischen den ge-
fundenen Nomen gibt Aufschluss daru¨ber, wie nahe die Entita¨ten nebeneinander liegen.
Jeder betrachtete Satz wird schließlich kategorisiert, hierbei wird in zwei Kategorien
eingeordnet:
– Ein Satz besitzt das so genannte
”
low-content-load“ wenn er viele Satzzeichen und
Stoppwo¨rter entha¨lt. Diese Sa¨tze sind fu¨r die Extraktion uninteressant, sie werden
als sprachlicher Ballast behandelt.
– Sa¨tze mit vielen Verben und Pra¨positionen, die aus wenigen Nebensa¨tzen beste-
hen werden mit dem Label
”
high-content-load“ versehen. Sie sind die eigentlich
interessanten Informationstra¨ger des Textes.
Diese Einordnung der Sa¨tze ist eine simple Maßnahme, welche die zu betrachtende
Satzmenge reduziert. Die Verbindung zwischen zwei Nomen bildet ein Muster, das auf
die Form Nomen - Pra¨dikat - Nomen reduziert wird und mo¨glicherweise als Relation in
den Graphen aufgenommen wird.
Beispielsweise ist das Tripel
”
Oppenheimer, professor of, theoretical physics“ eines dieser
gewollten Muster.
Um einen Gesamtu¨berblick u¨ber den Extraktionsprozess zu erhalten muss man sich folgende
Reihenfolge im Ablauf der Applikation vorstellen:
ˆ Der Self-Supervised Learner markiert a priori potentielle Sa¨tze entsprechend ihrem
content-load als vertrauenswu¨rdige oder nicht-vertrauenswu¨rdige Quellen fu¨r die Re-
lationsextraktion. Vertrauenswu¨rdig sind alle Sa¨tze die entsprechend als
”
high-content-
load“ klassifiziert wurden und mit wenigen eingebetteten Nebensa¨tzen auskommen.
ˆ Darauf folgt die gerade beschriebene
”
Single Pass Extraction“.
ˆ Schließlich vereint ein Redundancy-based Assessor identische Entita¨ten im Graphen.
Beantwortung von Fragen
TEXTRUNNER akzeptiert Anfragen die aus Stichwo¨rtern bestehen. Das System beantwortet
die Fragen mit einer Liste aus Objekten oder mit Pra¨dikaten die auf ein Objekt verweisen.
Es ko¨nnen folgende Fragen beantwortet werden:
ˆ Die Frage nach einer Liste von Objekten die ein gemeinsames Attribut besitzen.
91
Abbildung 1.32: Inverted Index u¨ber dem Graphen
ˆ Die Frage nach einem unbekannten Objekt. Also einem Wort welches der Benutzer
finden mo¨chte aber nicht kennt. Eine Art Kontext Suche.
ˆ Schließlich die Frage nach einer Relation, also der Beziehung zwischen zwei Objekten.
ˆ (Theoretisch ko¨nnen auch statistische Fragen mit einer Tabelle beantwortet werden,
diese waren jedoch im Paper nicht zu finden.)
Eine vom Benutzer eingegebene Query wird in einzelne Wo¨rter (Tokens) zerlegt und an das
Response System u¨bergeben. Die Frage wird also trotz dem Anspruch eine Semantische Such-
maschine zu sein, an Hand von vorhandenen Stichwo¨rtern beantwortet. Im Gegensatz zu einer
Stichwortsuche, die zu den Query Tokens die zugeho¨rigen Dokumente ausgeben wu¨rde, lie-
fert TEXTRUNNER Objekte zuru¨ck - also Tripel des Graphen. Um diese Tripel ausgeben
zu ko¨nnen muss eine Zuordnung zwischen den Wo¨rtern eines Dokuments und den Tripeln
existieren. Das System baut hierzu einen Inverted Index der jedes Stichwort auf eine Men-
ge von Tripeln abbildet. Nachdem die Eingabe in Tokens zerlegt wurde, wird eine Liste der
im Inverted Index referenzierten Tripel aufgebaut. Mit dem
”
spread activation“ Algorithmus
werden die Knoten, also Entita¨ten im Graph markiert und ihre Kanten mit einem Wert
”
akti-
viert“. Dieser Wert wu¨rde, ungebremst, die benachbarten Knoten markieren und ihre Kanten
aktivieren. Die Aktivierung wu¨rde sich also wie Welle u¨ber dem Graphen ausbreiten. Diese
Ausbreitung ko¨nnte man auf Kosten der Rechenzeit relativ lange gewa¨hren lassen, TEX-
TRUNNER jedoch erlaubt nur eine Pfadla¨nge von 1. Der Wert der Aktivierung ist additiv,
so dass zwei benachbarte, markierte Knoten eine gemeinsame Kante mit einem hohen Wert
besitzen.
Die Tripel mit dem ho¨chsten Wert bilden das Set aus dem die Antwort berechnet wird.
Natu¨rlich wirkt sich die Art der Frage auf die endgu¨ltige Form der Antwort aus. Dieses
92
Abbildung 1.33: KNOWITNOW vs. TEXTRUNNER
Verfahren kann man gleichzeitig als eine Art von Rankingverfahren ansehen bei dem Tripel
bezu¨glich ihrer Relevanz zur Query geordnet werden. Gleichzeitig wird ein eigenes Ranking-
verfahren angewendet welches die Objekte in Clustern entlang a¨hnlicher Pra¨dikate anordnet.
Performanz und Ergebnisse
TEXTRUNNER nutzt acht einfache Extraktionsmuster um innerhalb 35 Stunden beinahe
1 Million Dokumente zu durchlaufen. Nichts desto trotz sind die Hardware Anforderungen
relativ umfangreich. Das vorgestellte und getestete System la¨uft auf einem Cluster bestehend
aus zwanzig Dual-Xeon Intel Servern mit einer Gesamtkapazita¨t an Festplattenspeicher von
5 TerraByte.
Im Durchschnitt wird
ˆ eine isA Relation pro 40 Sa¨tze extrahiert,
ˆ zusa¨tzlich werden in 10 Sa¨tzen 7,7 predicate Relationen erkannt.
Die Qualita¨t der extrahierten Daten ist erstaunlicherweise besser als bei dem Vorga¨nger Sys-
tem KnowITNow. Offensichtlich ist ein gewisser Grad an Ungenauigkeit bei der Verarbeitung
gerade gut genug.
Relevanz fu¨r die Projekt Gruppe
TEXTRUNNER hat keine wirkliche Relevanz bezu¨glich der Extraktion von Named Entities.
Der Ansatz mo¨glichst schnell viele Dokumente zu erfassen ist fu¨r die PG uninteressant, die
Geschwindigkeit mit der im Bundestag neue Dokumente vero¨ffentlicht werden, la¨sst ein großes
Zeitfenster fu¨r die Verarbeitung. Die relaxierte Betrachtung des Problems mit einem weniger
komplexen
”
Extraction Graph“ ist wesentlich interessanter und wu¨rde ganz gut zu den von uns
aufgestellten Event Schemas passen. Der Ablauf der Extraktion kann auch mit wenig Aufwand
93
an unser Vorgehen angepasst werden. Das POS Tagging von Wo¨rtern zwischen den Named
Entities und deren Mapping auf die Trigger aus unseren Event Schemas wu¨rden zwar einen
Graphen mit mehreren Typen von Relationen erstellen, allerdings bliebe die Funktionalita¨t
erhalten: Gesucht seien Kanten die an gegebene Query Tokens angrenzen. Die durch die
Query implizierte Typ der Relation wa¨re damit nur ein Kriterium des Rankings und nicht der
Suche selbst. Die Schwierigkeit liegt hier allerdings wieder beim Erkennen des vom Benutzer
gemeinten Typs.
Ein weiterer Ansatz der Interessant erscheint ist der
”
spread activation“ Algorithmus. Bei
Festgelegten
”
decay factor“ und einer > 1 begrenzten Pfadla¨nge der Ausbreitung mu¨sste
auch der Kontext einer Anfrage sichtbar werden, was zu interessanten Schlussfolgerungen
fu¨hren ko¨nnte.
1.5.3 Dependency Tree
Aufbau
Ein dependency tree repra¨sentiert die grammatikalische Beziehung der Entita¨ten eines Satzes.
Er wird durch ein Set von Regeln aus dem Syntaxbaum des Satzes erstellt. Solche Regeln
ko¨nnen zum Beispiel sein:
ˆ Subjekte zeigen auf ihre Verben
ˆ Adjektive zeigen auf die Nomen die sie modifizieren
Anschließend wird jeder Knoten des dependenca tree mit einem Eigenschaftsvektor erweitert,
dieser Vektor hat unter Anderen folgende Dimensionen:
Feature Example
word troops, Tikrit
part-of-speech(24 values) NN,NNP
general-pos(5 values) noun, verb, adj
chunk-tag NP,VP,ADJP
entity-type person, geo-political-entity
entity-level name, nominal, pronoun
Wordnet hypernyms social group, city
relation-argument ARG A, ARG B
Vorverarbeitung
Zuerst mu¨ssen die Entita¨ten erkannt werden, hierfu¨r gibt es eine Fu¨lle an Verfahren die
auch sehr gute Ergebnisse erzielen. Der na¨chste Schritt ist die Coreference resolution, hierbei
werden gleiche Entita¨ten erkannt, also wenn eine Entita¨t in verschiedenen Formen im Text
auftaucht, muss erkannt werden, das es sich um die gleiche Entita¨t handelt. Dies ist Thema
der aktuellen Forschung, genaueres hierzu kann man bei Pasula et al.,2002; McCallum and
Wellner, 2003 nachlesen.
Relation Extraction
Fu¨r die Relation Extraction wird u¨ber alle Paare von Entita¨ten in einem Satz iteriert. Fu¨r
jedes Paar einen Erweiterten dependency tree erstellen, der die beiden Entita¨ten entha¨lt und
94
alle Knoten, die zwischen den Entita¨ten liegen. Anschließend wir mit der Kernelfunktion die
A¨hnlichkeit der Ba¨umen berechnen. Je A¨hnlicher ein Baum einem Aus dem Trainingsdaten-
satz ist, desto wahrscheinlicher ist es, dass die Entita¨ten in der gleichen Beziehung zueinander
stehen.
Kernelfunktion
Die Kernfunktion besteht aus meheren Teilfunktionen:
m(ti, tj) =
{
1 if ∅m(ti) = ∅m(tj)
0 sonst
ist 1 wenn die Eigenschaftsvektoren der Knoten ti und
tj mindestens in einer Eigenschaft den gleichen Wert haben
s(ti, tj) =
∑
υq∈∅s(ti)
∑
υr∈∅s(tj)C(υq, υr) A¨hnlichkeitsfunktion zwischen zwei Knoten.
C(υq, υr) =
{
1 if υq = υr
0 sonst
Vergleichsoperationen der Eigenschaften.
Zusammen ergibt sich dann folgende Kernfunktion:
K(T1,T2) =
{
0 if m(r1, r2) = 0
s(r1, r2) +Kc(r1[c], r2[c]) sonst
mit T1 und T2 erweiterte dependency trees.
Diese Kernfunktion gibt ein normalisiertes, symetrisches A¨hnlichkeitsmaß zuru¨ck.
Experimente
Fu¨r die Experimente wurden verschiedene Kernel Varianten eingesetzt. Als Datensatz wurde
Automatic Content Extraction(ACE) vom Intitut for Standards an Technology(NIST) be-
nutzt. die ist ein Datensatz mit u¨ber 800 annotierte Texte.
normal Kernel Option. 1 Kernel Option. 2
Recall 26,3 51,8 35,0
Recision 70,3 81,2 67,5
F1 38,0 63,2 45,8
Beispiel
Fu¨r den Satz: ”Troops advanced near Tikrit.”
Optimierungsvarianten
Um die Performance zu verbessern berechnet man nicht die vollsta¨ndigen dependeny trees,
sondern nur die ku¨rzesten Pfade zwischen den beiden Entita¨ten, die betrachtet werden →
bessere Laufzeit, da deutlich weniger Knoten betrachtet werden.Nach Razan C. Buescu and
Raymond J. Mooney
1.5.4 SVM Methoden
Eine Support Vector Machine (SVM) ist ein Klassifikator. Eine Support Vector Machine unter-
teilt eine Menge von Objekten so in Klassen, dass um die Klassengrenzen herum ein mo¨glichst
breiter Bereich frei von Objekten bleibt; sie ist ein sogenannter Large Margin Classifier.
Trainingsdaten
95
Abbildung 1.34: Dependecytree
Abbildung 1.35: Erweiterter Dependecytree
96
SVM Methode braucht Trainingsdaten, damit es lernen kann. Die Trainingsdaten ko¨nnen
menschenlich erstellen. Es kostet aber viele Arbeitskra¨fte. Sie ko¨nnen auch semi-automatisch
erzeugt werden. Diese Methode erfordert keine Experten aus verschiedenen Bereichen. Es
braucht nur die Leute mit fachlichen Kenntnissen, um die Beziehung zwischen Entita¨ten zu
beurteilen. Dann werden die Daten als Trainingsdaten gespeichert. Die Daten ko¨nnen auch
fu¨r andere Learning Algorithmen verwenden.
1. Die Relationen zwischen zwei Entita¨ten werden gegeben.
2. Menschen entscheiden ja und nein.
3. Die Daten werden als Trainingsdaten gespeichert.
Vektor Bildung
Fu¨r die Verarbeitung natu¨rlicher Sprache Probleme mit SVM ist es ein wichtiges Ketten-
glied, wie man die Relationen zwischen zwei Entita¨ten als Vektor bilden. Ein Vektor ist ein
Daten mit der Dimension, die die Eigenschaft zwischen zwei Entita¨ten in dem Dokument
beschreibt. Die Vektorelemente ko¨nnen bina¨ren sein. 1 oder 0 bedeutet, ob die Eigenschaft
existiert ist. Die Wert der i-te Dimension des Vektors wird durch Funktion
fi : H × T− > {0, 1} (1.66)
errechnet. Wobei sind H die alle Eigenschaft in dem Dokument fu¨r die zwei Entita¨ten. T sind
alle Eigenschaft (Dimension), die man definiert. Dann ist die i-te Vektorelement
xi = fi(h, t). (1.67)
Beispeil : Man definiert eine Vektorraum (Es gibt Persons, Es Organizations, Es gibt Physical,
· · · ). Fu¨r ”Herr Ackermannu¨nd A¨cor GmbHı¨n ”Herr Ackermann ist ein Manager von Acor
GmbH”kann man dann ein Vektor (1,1,0,· · · ) bilden.
Gewichte Vektor
Mit der Trainingsdaten wird eine gewichte Vektor errechnet. Die gewichte Funktion:
Abbildung 1.36: SVM
y = −→ω−→x + b, (1.68)
wobei −→ω die gewichte Vektor ist.
97
Klassifikation
Mit der gewichte Vektor werden neue Daten entscheidet. Mit einem Fenster werden die neue
Daten extrahieren. Allgemeine stehen die Entita¨ten einer Relation nahe. Aber wenn das Fens-
ter zu groß ist, ist die Laufzeit lange. Wenn Fenstergroß 7 ist, gilbt es maximal 7 Entita¨ten
21 Paar der Entita¨t. Zwischen ein Paar (Ei, Ej) steht Relation? Egal, Es ist nicht wichtig.
Wichtig ist, ob das Paar (Ei, Ej) geho¨rt zu Klasse der Relation A ist. Um es zu entscheiden,
muss zuerst das Paar als ein Vektor (−→x ) gebildet werden. Durch die gewichte Funktion (1.68)
wird die Wert y ermittelt. Wenn y positive ist, ist das Paar (Ei, Ej) zu Klasse A geho¨rt.
Abbildung 1.37: Die Darstellung der gewichte Funktion
1.5.5 Kernel Methoden
Kernelfunktion wird ersten in SVM fu¨r nichtlineare Erweiterung verwendet. Vergleich mit
SVM-Methode braucht man fu¨r Kernel-Methode ohne Vektor zu bilden. Man braucht nur
zwei Objekte zu vergleichen. Wenn sie a¨hnlich sind, sind sie geho¨rt zu gleich Klasse. Das
Klassifikationsproblem ist jetzt das A¨hnlichkeitsproblem. Fu¨r das A¨hnlichkeitsproblem sind
nur typische Exemplare notwendig anstatt riesigen Trainingsdaten.
Subsequenz Kernel
Sind die zwei Sequenzen der Wo¨rter a¨hnlich? Es wird eine Kern-Funktion definiert. Fu¨r eine
Sequenz X = x1x2x3 · · ·xs bedeutet i = [i1i2 · · · in] eine Index von X, wobei 1 ≤ i1 < i2 <
· · · < in ≤ n. xi ist ein Wort. s ist hier die La¨nge der Sequenz. Dann ist X[i] eine Teilsequenz
von X.
Z.B. X =’ACDBABC’ ist eine Sequenz, wobei A ein Wort ist. Fu¨r eine Teilsequenz ’ADB’
gebt es zwei Index ACDBABC ([134]), ACDBABC ([136]).
Wir definieren die La¨nge L(i) der Index-Sequenz i in X als in − i1 + 1. Z.B. fu¨r i = [134] ist
L(i) = 3; fu¨r j = [136] ist L(j) = 5.
Fu¨r zwei Sequenzen X und Y ist
∑n die Menge der gemeinsame Teilsequenzen. Die Kern-
Funktion ist dann:
Kn(X,Y ) =
∑
u∈
∑n
∑
i:u≺X[i]
∑
j:u≺Y [j]
λL[i]+L[j], (1.69)
wobei u die gemeinsame Teilsequenz ist, und λ ein verfallenden Faktor ist (λ < 1). λ macht
Kern-Funktion umgekehrt proportional zu die La¨nge L(i).
Fu¨r die Verarbeitung natu¨rlicher Sprache ist nur Subsequenz Kernel nicht genug. In der Kern-
Entscheidfunktion muss auch die Semantik-A¨hnlichkeit errechnet werden.
98
1.6 Semantic Role Labeling
1.6.1 Semantische Rollen
Eine semantische Rolle ist
”
die Bedeutungsfunktion eines Satzteils auf den ganzen Satz“[Sem08]
oder genauer
”
die semantische Relation der Satzbestandteile zum Pra¨dikat“[EV06]. Das Kon-
zept der semantischen Rollen gibt es bereits seit Ende der 60er Jahre und stammt aus der
Linguistik. Semantische Rollen werden von vielen neuartigen Grammatikmodellen genutzt,
um Syntax und Semantik in einem Modell zu erfassen und so etwas wie eine Universalgram-
matik fu¨r alle Sprachen darzustellen.[Sem08]
Es gibt viele unterschiedlich spezielle Rollenaufteilungen fu¨r semantische Rollen. Im Folgenden
sollen die semantischen Rollen nach Fillmore (1971) beschrieben werden, welche eine eher
generellere Rollenaufteilung beschreiben.
ˆ Agent - Dieser fu¨hrt die Handlung aus.
Bsp.: Die na¨chste Frage stellt der Kollege Burgbacher.
ˆ Experiencer - Dieser nimmt etwas wahr oder fu¨hlt etwas.
Bsp.: Sie haben den Vorschlag geho¨rt.
ˆ Instrument - Dieses ist ein Mittel, mit dem eine Handlung ausgefu¨hrt wird.
Bsp.: Die Wahl findet mit verdeckten Stimmkarten, also geheim, statt.
ˆ Object (oft auch Theme) - Dieses vera¨ndert sich durch die Handlung.
Bsp.: Die Regierung hat ein Denkmal errichtet.
ˆ Time - Dies ist die Zeit des Geschehens.
Bsp.: Daru¨ber werden wir morgen beraten.
ˆ Location - Dieses ist der Ort des Geschehens.
Bsp.: Sie du¨rfen Ihre Stimmkarte nur in der Wahlkabine ankreuzen.
ˆ Goal - Dieses ist der Ort zu dem sich etwas bewegt.
Bsp.: Wir sind wieder in die Mitte Europas geru¨ckt, was das Wachstum anbelangt.
ˆ Path - Dies ist der Weg des Geschehens.
Bsp.: Im U¨brigen haben die USA hervorragend mit den menschenverachtenden Taliban
verhandelt, und zwar u¨ber eine Gaspipeline durch Afghanistan.
ˆ Source - Dies ist der Ort von dem aus sich etwas bewegt.
Bsp.: Herr Kollege Bru¨derle, setzen Sie sich doch einmal aufs Fahrrad und fahren
von Ihrem Heimatort aus in Richtung Westen nach Frankreich.
[Kas08, Kri04]
Oberfla¨chenkasus
Die semantischen Rollen werden ha¨ufig auch als Tiefenkasus bezeichnet, das auf der Syntax
beruhende Gegenstu¨ck ist der Oberfla¨chenkasus.
Der Oberfla¨chenkasus hilft die semantischen Rollen zu bestimmen. Wie in Tabelle 1.6 an den
kursiven Stellen zu sehen ist, ist der Oberfla¨chenkasus aber leider nicht eindeutig. Weitere
99
Maskulinum Femininum Neutrum Plural
Nominativ (wer oder was) der - er die - sie das - es die - sie
Akkusativ (wen oder was) den - ihn die - sie das - es die - sie
Dativ (wem) dem - ihm der - ihr dem - ihm den - ihnen
Genitiv (wessen) des - seiner der - ihrer des - seiner der - ihrer
Tabelle 1.6: Oberfla¨chenkasus
U¨bereinstimmungen zwischen verschiedenen Kasus sind ebenfalls in Tabelle 1.6 abzulesen.
Wenn nicht alle Formen unterschiedlich ausgepra¨gt sind, so nennt sich dies auch Synkretismus.
Wu¨rde kein Synkretismus im Oberfla¨chenkasus vorliegen, so wa¨re es eine einfache Aufgabe die
semantischen Rollen zu bestimmen, die allerdings auch wieder sprachspezifisch wa¨re. [EV06]
Part of speech tagging
Beim part of speech (POS) tagging wird jedem Wort in einem Satz eine Wortart zugeordnet.
Außerdem wir auch jedem Satzteil eine Satzphrasenart zugeordnet. Die Ergebnisse des POS
taggings lassen sich gut durch einen Syntaxbaum visualisieren. Abbildung 1.38 zeigt das Bei-
spiel eines Syntaxbaumes.
S
PP
NP
NDet
V’
V
VP
NP P NP
NDet
FernrohrdemmitJungendensahEr
Abbildung 1.38: Syntaxbaum
S: Satz
NP: Nomenphrase
VP: Verbphrase
PP: Pra¨positionale Phrase (Ad-
verbiale Phrase)
N: Nomen
V: Verb
Det: Determinantien (z.B. Arti-
kel)
P: Pra¨position
V’: Verbphrase die einer Verb-
phrase (VP) untergeordnet ist
(auch V” usw. mo¨glich)
Im Beispiel aus Abbildung 1.38 wird auch direkt ein Problem der Wortartenzuweisung deut-
lich. Denn dieser Satz ist auf zwei Weisen interpretierbar.
1. Er sah den Jungen durch sein Fernrohr.
2. Er sah den Jungen, der das Fernrohr hat.
Der Syntaxbaum aus Abbildung 1.38 stellt die 1. Variante dar. In der 2. Variante wa¨re der
Satzteil
”
mit dem Fernrohr“ keine eigensta¨ndige Pra¨positionale Phrase der Verbphrase mehr,
sondern wa¨re als pra¨positionale Phrase an die Nomenphrase
”
den Jungen“ angeschlossen.
Allerdings sind Syntaxba¨ume trotzdem sehr hilfreich, um auf semantische Rollen schließen zu
ko¨nnen. So beschreibt eine NP vor einer VP meist ein Subject und dieses ist meist der Agent.
100
Eine NP in einer VP hingegen beschreibt meistens ein Object. Und eine PP beschreibt ha¨ufig
Informationen u¨ber Ort und Zeit. [Mey02]
1.6.2 Automatisches Zuweisen von semantischen Rollen
Das automatische Zuweisen von semantischen Rollen, auch Semantic Role Labeling genannt,
bezeichnet die Gruppierung von Wo¨rtern eines Satzes in einer Weise, die es anschließend
ermo¨glicht den Wortgruppen eine semantische Rolle zuzuweisen. Das verbreiteteste Vorge-
hen dabei ist, das Verb eines Satz als zentrales Element zu untersuchen. Zu jedem Verb
geho¨ren eine Reihe von verallgemeinerten Argumenten, die in ihrer konkreten Auspra¨gung
dann einen Satz bilden. Die Argumente entsehen hauptsa¨chlich durch den Oberfla¨chenkasus.
So ko¨nnte man z.B. Sa¨tze mit dem Verb befu¨rworten durch die Argumente Befu¨rworter und
Befu¨rwortetes gliedern, so dass sie die Struktur <Befu¨rworter> befu¨rwortet <Befu¨rwortetes>
erhalten. Eine Auspra¨gung dieser Satzform wa¨re dann zum Beispiel:
”
Die Fraktion der SPD
befu¨rwortet den Antrag XYZ.“.
Wie man erkennen kann, sind solche Argumente Tra¨ger semantischer Rollen. Ziel ist es alo
einen Satz so erfassen, dass alle Wo¨rter eines Satzes auf die Argumente des Verbs abgebil-
det werden und so ihre semantischen Rollen erhalten. Diese Abbildung wird auf der Basis
von Informationen u¨ber die Charakteristik des Satz vorgenommen. Als Charakteristika (auch
features genannt) dienen z.B. syntaktische Informationen, wie der Oberfla¨chenkasus, oder
Part-of.Speech-Tags, wie sie oben vorgstellt wurden.
Probabilistisches Semantic Role Labeling
Probabilistisches Semantic Role Labeling soll wie a¨hnliche Probleme behandelt werden, z.B.
POS, Syntaxanalyse...). Hierfu¨r sollen statistische Techniken ausgenutzt werden.
Abbildung 1.39: Die Domain Communication aus der
FrameNet-Datenbank
Die Zuweisung semantischer Rol-
len wird in zwei Teilaufgaben auf-
geteilt. Zum einen die Identifi-
zierung der Frameelementgrenzen
und zum anderen die Zuweisung
einer semantischen Rolle zu je-
dem Frameelement. Frameelemen-
te sind Bereiche im Satz. Fu¨r ver-
schiedene Frames sind unterschied-
liche Frameelemente mo¨glich. In
Abbildung 1.39 sind Frames und
Frameelemente aus der FrameNet-
Datenbank zu sehen. Außerdem
sind an die Frames noch die je-
weiligen Triggerverben und -nomen
angeheftet. Findet man ein solches
Triggerwort im Text, so weiß man,
dass das Frame zu diesem Triggerwort in diesem Bereich vorliegen muss. Nun kann nach den
definierten Frameelementen gesucht werden.
In der folgenden Beschreibung wird davon ausgegangen, dass die Grenzen bereits per Hand
annotiert worden sind. Die Ergebnisse von automatisch erkannten Grenzen sind in etwa gleich.
101
Abbildung 1.40: Das Parse Tree Path Merkmal
Um nun die semantischen Rollen zuweisen zu ko¨nnen, sind die folgenden Merkmale gegeben:
1. Phrase Type (pt): Dieser beschreibt den syntaktischen Typ des Satzteils, also z.B.
NP, VP oder S.
2. Governing Category (gov): Von einer NP ausgehend wird der na¨chste Vorfahr S oder
VP gesucht. Wenn der na¨chste Vorfahr das S ist, so bekommt die NP die Governing
Category Subjekt, ist der na¨chste Vorfahr eine VP, so wird der NP die Governing Cate-
gory Objekt zugeordnet. Fu¨r andere Typen als NP als Ausgangsbasis hat die Governing
Category nur wenig Effekt, weshalb dieses Merkmal auch nur fu¨r NP’s genutzt wird.
3. Position: Diese gibt an, ob die Komponente vor oder hinter dem Pra¨dikat angesiedelt
ist .
4. Parse Tree Path: Dieses Merkmal beschreibt den Pfad vom Zielwort zur Komponente
der Frage. Im Beispiel aus Abbildung 1.40 ist das Zielwort
”
He“ und beantwortet die
Frage nach dem
”
wer“. VB↑VP↑S↓NP bedeutet also, dass vom Verb (VB) nach oben (↑)
zur Verbphrase (VP), von dort nach oben (↑) zum Satz (S) und nun nach unten (↓) zur
Nomenphrase (NP) durch den Baum gelaufen wird. Wenn wir diesen Pfad durchlaufen
haben, so handelt es sich um ein Subjekt. Dies ist in der Tabelle aus Abbildung 1.40
abzulesen. Dort werden auch die Ha¨ufigkeiten der unterschiedlichen Pfade im Bezug auf
den Datensatz (FrameNet Datenbank, mit ca. 8148 Beobachtungen) aufgezeigt.
5. Voice: Dieses Merkmal unterscheidet zwischen aktiven und passiven Verben. Im vor-
liegenden Datensatz sind ca. 5 % der Verben passiv.
6. Head Word (h): Hier wird das Hauptwort des Satzteils makiert. Mit diesem kann die
grammatische Funktion bestimmt werden.
ˆ Bsp. NP: the old fashioned door
ˆ Bsp. VP: might be hit
ˆ Bsp. PP: on the table
Um die Wahrscheinlichkeiten direkt u¨ber der vollen Menge der Merkmale zu berechnen, also
mit
P (r | h, pt, gov, position, voice, t) =
#r, h, pt, gov, position, voice, t
#h, pt, gov, position, voice, t
, (1.70)
102
mit r = semantische Rolle und t = target word / Verb,
sind leider zu wenig Daten vorhanden. Deshalb wird hier die lineare Interpolation benutzt
und die Wahrscheinlichkeiten werden somit unterschiedlich kombiniert.
P (r | Komponente) = λ1P (r | t) + λ2P (r | pt, t) + λ3P (r | pt, gov, t)+
λ4P (r | pt, position, voice) + λ5P (r | pt, position, voice, t)+
λ6P (r | h) + λ7P (r | h, t) + λ8P (r | h, pt, t)
mit
∑
i
λi = 1
(1.71)
103
Abbildung 1.41: Wahrscheinlichkeitsverteilungen in der finalen Version
In Abbildung 1.41 sind die acht Wahrscheinlichkeitsverteilungen aus Formel 1.71 abgebildet.
Accuracy steht hier fu¨r den Anteil an Testdaten, fu¨r die die korrekte Rolle vorhergesagt wurde.
Coverage ist der Anteil der Testdaten, fu¨r die das bedingte Ereignis in den Trainigsdaten
gesichtet wurde. Performance beschreibt das Produkt von Accuracy und Coverage.
An Abbildung 1.41 ist zu erkennen, dass es einen Tradeoff zwischen spezifischen Verteilungen,
also Verteilungen mit einer hohen Accuracy und einer niedrigen Coverage, und unspezifischen
gibt. So ist die Gu¨te (Accuracy) fu¨r die unspezifischen Verteilungen deutlich ho¨her, jedoch
ist die Abbdeckung im Datensatz nicht mehr so hoch. Bei den spezifischen Verteilungen hat
man eine sehr gute Abdeckung im Datensatz jedoch la¨sst die Gu¨te hier zu wu¨nschen u¨brig.
So entstand die Idee eines Rankings, um die λ-Werte aus Formel 1.71 festzulegen. Es wurde
ein Netz gebildet von spezifischen zu unspezifischen Verteilungen, welches in Abbildung 1.42
zu sehen ist.
Abbildung 1.42: Verteilungsnetz / BackOff-Kombination
In diesem Netz wird zu-
na¨chst immer versucht ei-
ne der obersten und somit
unspezifischten Verteilun-
gen zu benutzten. Erst
wenn dies nicht mo¨glich
ist, da keine Beispiele
hierzu vorhanden sind, so
wird eine Ebene tiefer im
Netz gegangen. Ein sol-
ches Netzwerk wird auch
BackOff-Kombination ge-
nannt.
Andere Schemata als die
BackOff-Kombination zur Wahl der λ-Werte, haben relativ wenig Effekt gezeigt, denn die
Bewertung ha¨ngt nur vom Ranking der Wahrscheinlichkeiten ab und nicht von deren exakten
Werten.
In Tabelle 1.7 sind die Ergebnisse des automatischen Zuweisens semantischer Rollen mit der
probabilistischen Methode festgehalten. Die Basis ist hier entstanden, indem immer die spe-
zifischste Verteilung, also P (r | t) = #(r,t)#(t) mit Accuracy = 40,9, wie in Abbildung 1.41 zu
104
Kombinationsmethode korrekt
Lineare Interpolation 79,5%
Backoff, Lineare Interpolation 80,4%
Basis: ha¨ufigste Rolle 40,9%
Tabelle 1.7: Ergebnisse des probabilistischen Semantic Role Labeling
sehen ist, gewa¨hlt und damit die semantische Rolle zugewiesen wurde. Wie bereits erwa¨hnt
wurde, wurde als Korpus die FrameNet Datenbank mit 8148 Beobachtungen verwendet.
[GJ00, GJ02a]
Semantic Role Labeling mit SVM
In Kaptiel 1.4.1 wurde die SVM bereits detailliert vorgestellt. Hier soll nun ihre Anwendung
fu¨r die Methoden des Semantic Role Labeling demonstriert werden. Das Ziel ist, die SVM so
zu trainieren, dass sie ein Wort nach seiner semantischen Rolle klassifiert. Da die SVM aber
ein bina¨rer Klassifizierer ist und die Anzahl der semantischen Rollen u¨berlicherweise gro¨ßer
als zwei ist, muss das Konzept der SVM zuna¨chst in das eines Multiklassen-Klassifizierers
gea¨ndert werden. Dazu bieten sich zwei Ansatze [PHK+05].
Der One-versus-All-Ansatz (OVA) sieht fu¨r jede Klasse (die hier einer semantischen Rolle
entspricht) eine SVM vor, die entscheidet, ob das einzuordnende Wort zu genau dieser eine
Klasse geho¨rt oder zu der Menge der u¨brigen. Fu¨r n Klassen sind damit ho¨chstens n SVMs
auszuwerten. Ein Nachteil dieser Lo¨sung ist der hohe Daten- und Lernaufwand. Jede SVM
muss durch das OVA-Prinzip immer auf allen vorhandenen Daten lernen.
Eine Alternative ist der paarweise Vergleich. Fu¨r n Klassen (semantische Rollen) werden
n∗(n−1)
2 SVMs beno¨tigt, so dass fu¨r jedes Klassenpaar eine Entscheidung zugunsten einer
der Klassen des Paars entsteht. Die entgu¨ltig zugeordnete Klasse ist die, die die meisten
Einzelentscheidungen fu¨r sich gewinnen konnte. Vorteil dieses Ansatz ist die im Vergleich
zum OVA-Prinzip kleine Trainingsdatenmenge, da mit jeder SVM immer nur zwei Klassen
verglichen werden. Dieser Vorteil kann sich aber auch durch die viel gro¨ßere Anzahl an SVMs
ins Gegenteil kehren. Die genauen Auswirkungen ha¨ngen von jeweiligen Anwendungsfall ab,
so dass die Methode zur Erweiterung der SVM zum Multiklassen-Klassifizierer gut u¨berlegt
sein sollte.
Das SRL geschieht durch die Bewertung von Auspra¨gungen verschiedener Merkmale (featu-
res). Im vorherigen Abschnitt wurden bereits einige Merkmale, wie Pharse Type, Governing
Category oder Position vorgestellt. Letzteres ist ein numerisches Feature, die beiden zuerst
genannten nicht. Da die SVM aber ein numerischer Klassifizierer ist, besteht das Problem,
nicht numerische Features passend zu codieren [KM00]. Dies kann durch die Verwendung von
bina¨ren Feature-Vektoren geschehen. Solch ein Vektor besitzt fu¨r jede mo¨gliche Auspra¨gung
jedes Features eine Komponente. Ist eine Auspra¨gung vorhanden, so wird die Komponenete
auf 1 gesetzt, sonst auf 0. Bei dieser Art der Darstellung erha¨lt ein Vektor schnell mehr als
100.000 Dimensionen. Ein Trick macht ihn aber trotzdem effizient einsetzbar und wenig spei-
cherintensiv. Der Vektor kann na¨mlich sehr gut kompaktiert werden, indem nur die Indizies
der Komponenten gespeichert werden, die mit einer 1 besetzt sind. Die Anzahl dieser Kompo-
nenten ist in den allermeisten Fa¨llen sehr klein [Joa98]. Man spricht bei derartigen Vektoren
aus von spa¨rlich oder du¨nn besetzten (sparse) Feature-Vektoren.
105
Eine Alternative zu den bina¨ren stellen TF-IDF basierte Vektoren dar, auf die aber hier nicht
weiter eingegangen werden soll.
Unter Umsta¨nden liegen fu¨r das SRL keine oder nur begrenzte syntaktische Informationen
vor. Dies kann zum Beispiel bei sehr komplizierten Sprachen oder bei solchen, fu¨r dies es
noch keine umfassenden Daten gibt, der Fall sein. Mit der Methode des Chunking lassen sich
dann aber trotzdem sogenannte oberfla¨chliche/flache syntaktische Informationen gewinnen
(shallow parse). Ein vollsta¨ndiges syntaktsisches Parsen wird dagegen als Tiefenparsen (deep
parse) bezeichnet. Das Chunking bezeichnet das Erkennen von zusammenha¨ngenden Wo¨rtern
in einem Satz, die dann durch die Zuweisung Chunk Labels, z.B. in der IOB-Notation (Inside,
Outside, Begining), die flachen Syntaxinformationen darstellen.
Ein Beispiel:
Eingabe:
[PPER Ich] [V AFI habe] [V V PP ausgesagt] , [ART die] [ADJA schwarzen] [NN Koffer]
[PTKNEG nicht] [V V PP genommen] [PTKZU zu] [V AINF haben].
Ausgabe:
[B−NP Ich] [B−V P habe] [I−V P ausgesagt] , [B−NP die] [I−NP schwarzen] [I−NP Koffer]
[O nicht] [B−V P genommen] [I−V P zu] [I−V P haben].
Auch fu¨r dieses Verfahren la¨sst sich die SVM, analog zur Verwendung beim SRL, nutzen. Eine
fertige Implentierung bietet YamCha (Yet another multipurpose Chunk Annotator) [Yam]
[KM00], bester Chunk Annotator im CoNLL2000 Shared Task im Bereich Chunking. Als
Basis nutzt YamCha eine SVM mit paarweiser Klassifizierung, die u¨ber das Chunk Label
eines Wortes entscheidet. Die Eingabe ist ein Text mit POS-Tags. Als Features werden die
umgebenden Wo¨rter und POS-Tags, je mit einer Fenstergro¨ße von zwei, sowie die beiden
letzten vergebenen Chunk Labels verwendet.
Anhand der unterschiedlichen Tiefen der syntaktischen Analyse unterscheidet man drei un-
terschiedliche Verfahren des SRL:
ˆ constituent-by-constituent (c-by-c)
Fu¨r dieses Verfahren dient ein vollsta¨ndiges syntaktisches Parsen als Grundlage. Der
Syntaxbaum eines Satzes wird zu einer Kette seiner Komponeneten linearisiert und
dann werden komponentenweise (constituent-by-constituent) die semantischen Rollen
bestimmt.
ˆ pharse-by-pharse (p-by-p)
Der Betrachtungsraum ist wie beim c-by-c Verfahren der ganze Satz. Da jedoch keine
vollsta¨ndigen syntaktsichen Informationen vorliegen, kann nicht wie beim c-by-c vorge-
gangen werden. Aus dem Kontext des Satzes mu¨ssen andere Informationen zur Klas-
sifizierung herangezogen werden. Um doch syntaktische Informationen zu verwenden,
findet das Chunking hier Anwendnung.
ˆ word-by-word (w-by-w)
Klassifierungen werden beim w-by-w Labeling nur auf Basis des zu klassifierenden
Wortes und der umgebenden Worte durchgefu¨hrt. Es werden also keine Satzgrenzen
beru¨cksichtigt. Auch hier la¨sst sich das Chunking sinnvoll einsetzten, wenn keine syn-
taktischen Informationen vorhanden sind.
106
Abbildung 1.43: Deep-Parse-System aus [PHK+05]
[PHK+05] vergleicht das Deep-Parsing und das Shallow-Parsing in drei Auspra¨gungen: Ein
c-by-c Verfahren mit vollsta¨ndigem Syntax-Parsing (Deep-Parsing) und zwei w-by-w Verfah-
ren, einmal mit syntaktischem Deep-Parsing und einmal ohne. Ingesamt ist [PHK+05] eine
Weiterentwicklung des Ansatzes von [GJ02a], der die dort verwendeten Wahrscheinlichkeiten
(siehe Kapitel 1.6.2) durch SVMs ersetzt und neue Features erga¨nzt. Zu den neuen Featu-
res za¨hlen z.B. die NER (Person, Organization, Location, ...), das POS-Tag des Headwords
und die Verb Sense Information. Letzere erkennt und merkt sich, welche Bedeutung eines
mehrdeutigen Verbes (mit gleichen Argumentanzahlen) gerade gemeint ist. Ein Beispiel ist
das Verb wiegen. Einerseits bezeichnet es das Wiegen eines Gewichtes mit den Argumenten
Wiegende(r) und Gewogenes, andererseits das Wiegen eines Kindes in der Wiege mit den
Argumenten Wiegende(r) und Kind.
Die Abbildungen 1.43 und 1.44 zeigen die beiden zu vergleichenden grundlegenden Syste-
marchtiekturen. Das Deep-Parse-System verwendet den syntaktischen Parser von Charniak
[Cha00]. Im Shallow-Parse-System wird dieser durch einen POS-Tagger und YamCha als
Chunker ersetzt.
Als Korpus fu¨r den Vergleich dient der PropBank-Korpus von Juli 2002. Wie allgemein u¨blich,
wurden die Sektionen 02-21 zum Lernen, die Sektion 00 zur Entwicklung und Debugging und
alle u¨brigen zum Testen verwendet.
System Precision Recall F1
Deep-Parse, c-by-c 80, 6 67, 1 73, 2
Deep-Parse, w-by-w 70, 7 60, 5 65, 2
Shallow-Parse, w-by-w 66, 2 54, 9 60, 0
Tabelle 1.8: Vergleichsergebnisse aus [PHK+05]
Tabelle 1.8 zeigt die konkreten Ergebnisse des Vergleichs von [PHK+05]. Es fa¨llt auf, dass die
Verfahren mit Tiefen-Parsing u¨berlegen sind und ein weiter gefasster Kontext (c-by-c) sich
postiv auf die Ergebnisse auswirkt. Der Hauptgrund fu¨r die großen Leistungsunterschiede ist
107
Abbildung 1.44: Shallow-Parse-System aus [PHK+05]
in der unterschiedlichen Bildung eines der wichtigsten Features, des Pfades (Path), zu finden.
Bei einer syntaktischen Tiefenanalyse entha¨lt der Pfad mehr und genauere Information als
bei einer flachen Analyse.
Im Rahmen dieses Vergleichs wurde auch eine Bewertung des Beitrags einzelner Features
zu Gesamtergebnis ermittelt. Dabei kommt dem Path-Feature, wie schon erwa¨hnt, eine der
wichtigsten Rollen zu. Noch wichtiger ist nach [PHK+05] das Headword. Positiv wirken sich
auch das POS-Tag des Headwords und die Verb Sense Information aus. U¨berraschender Weise
verschlechtert die NER allerdings die Ergebnisse. Dies liege, so die Autoren, daran, dass viele
Komponenten Named Enities enthielten, aber dabei keine Charakteristika des Pra¨dikats seien.
Somit wirkt die NER eher als Sto¨rquelle.
Semantic Role Labeling mit Maximum Entropy
Einen guten Einstieg in diese Thematik liefert [Rat97]. Die grundlegende Idee beim SRL mit
Maximum Entropy Models (MEM) ist, das Auftreten einer einer Klasse a in einem Kontext
b statistisch abzuscha¨tzen. Eine Klasse kann dabei ein POS-Tag oder eine semantische Rolle
sein. Der Kontext in dem diese auftreten sind Wo¨rter oder Sa¨tze. Diese allgeimeine Formu-
lierung la¨sst erahnen, dass MEM ein weites Anwendungsgebiet haben, das aber hier auf SRL
begrenzt werden soll.
Sei A die Menge aller Klassen, B die Menge aller Kontexte und x = (a, b) eine Klasse-
Kontext-Kombination mit a ∈ A und b ∈ B. Weiter sei E = A × B die Menge aller solcher
Kombinationen x. Die Wahrscheinlichkeit fu¨r ein Auftreten von x wird mit der Wahrschein-
lichkeitsverteilung p(a, b) = p(x) bezeichnet. Fu¨r das Modell gibt es zwei Wahrscheinlichkeits-
verteilungen: p˜(x) ist die Verteilung, die als Parameter fu¨r das Modell fungiert und sich aus
konkreten Beobachtungen speist. S ⊆ E sei dabei die Menge der Beobachtungen. p˜(x) gilt
also nur u¨ber S. Die zweite Verteilung, p(x), ist eine vom Modell errechnete, verallgemeinerte
Verteilung u¨ber E , also u¨ber allen mo¨glichen Kombinationen (a, b).
Die Beobachtungen, die p˜(x) definieren, werden die mittels einer Feature-Funktion f : E →
{0, 1}, die fu¨r alle Klasse-Kontext-Kombinationen x angibt, ob sie fu¨r das Feature relevant
108
sind. Es sei hier von k Features mit je einem dazugeho¨rigen fi (i = 1, ..., k) ausgegangen. Die
Features werden durch die folgende Bedingung in das MEM integriert:
Epfi = Ep˜fi ∀i = 1, ..., k (1.72)
E bezeichnet dabei den Erwartungswert der jeweiligen Verteilungsfunktion. So ist Ep˜ =∑m
x∈S x · p˜(x) und Ep(x) analog. Mit dieser Bedingung erreicht man, dass die vom Modell
errechnete Wahrscheinlichkeitsverteilung konsistent mit den Beobachtungen ist.
Das MEM fu¨r SRL ist nun ein Optimierungsmodell
p∗ = argmax
p∈P
, H(p)
H(p) = −
∑
x∈E
p(x) log p(x)
P = {p|Epfi = Ep˜fi, i = 1, ..., k}
welches aus allen gu¨ltigen Verteilungen die Verteilung p∗ findet, die die Entropie H maximiert.
Eine Verteilung p ist gu¨ltig, wenn sie die Gleichung (1.72) erfu¨llt.
Die optimale Verteilung ist aber anders darstellbar [Rat97]:
p∗ = pi
k∏
j=1
α
fj(x)
j (1.73)
Dabei sind die αj die einzigen Variablen, die sich durch den Generalized Scaling Algorithmus
[Rat97] relativ leicht brechnen lassen.
Abschließend soll noch ein Beispiel die Formulierung der Features und der Gleichung 1.72
verdeutlichen: Sei A = {x, y} und B = {0, 1}. Als Feature soll das Vorkommen des Kontextes
b = 0 modelliert werden, dessen Ha¨ufigkeit man insgesamt mit 60% beobachtet habe. Dies
stellt Tabelle 1.6.2 dar.
Tabelle 1.9: Ausgangsdaten fu¨r SRL-MEM Beispiel
p(a, b) 0 1
x ? ?
y ? ?
∑
0,6 ?
Das Feature la¨sst sich durch die Funktion
fi =
{
1, wenn b = 0
0, sonst
109
darstellen, so dass sich fu¨r die Bedingung 1.72 ergibt:
Ep˜ · f1 = Ep · f1
⇔
p(x, 0) · 1 + p(y, 0) · 1 = Ep · f1
⇔
0, 6 = Ep · f1
Das Ergebnis, das die Entropie maximiert, ist in Tabelle 1.6.2 dargestellt. Gu¨ltig wa¨ren auch
alle Ergebnisse deren erste Spalte in Summe 0,6 und deren zweite Spalte summiert 0,4 ergeben.
Diese maximieren aber die Entropie nicht.
Tabelle 1.10: Ausgangsdaten fu¨r SRL-MEM Beispiel
p(a, b) 0 1
x 0,3 0,2
y 0,3 0,2
∑
0,6 0,4
Unsupervised Semantic Role Labeling
Beim Unsupervised Semantic Role Labeling soll eine Zuordnung der semantischen Rollen erfol-
gen, ohne dass manuell getaggte Daten vorliegen. Dies wird erzielt, indem initial Zuordnungen
anhand eines Verblexikons gemacht werden, wenn eine Zuordnung eindeutig mo¨glich ist. An-
hand dieser Zuordnungen soll dann ein Wahrscheinlichkeitsmodell aufgestellt werden, mit dem
die restlichen Daten zugeordnet werden sollen.
Beim Iterieren u¨ber den Daten wachsen die annotierten Daten immer weiter an und um am
Ende alle semantischen Rollen getaggt zu haben, wird die Schwelle des Wahrscheinlichkeits-
modells immer weiter herabgesetzt.
Das Verblexikon nimmt in dieser Methode eine sehr zentrale Rolle ein. Es listet mo¨gliche
Rollen fu¨r alle Argumente eines Verbs auf. In Abbildung 1.45 ist ein beispielhafter Eintrag
des Verlexikons fu¨r das Verb
”
whisper“ dargestellt.
whisper
Frames:
Agent V
Agent V Prep(+dest) Recipient
Agent V Topic
Verben in der selben (Sub-)Klasse:
[bark, croon, drone, grunt, holler, ...]
Abbildung 1.45: Der Eintrag whisper aus
dem Verblexikon
Dieser Eintrag ist wie folgt zu verstehen: Das
Verb whisper hat drei mo¨gliche Frames, die erste
mo¨gliche wa¨re Agent V. Frames bestehen wieder-
um aus Slots, die durch semantische Rollen gefu¨llt
werden sollen. Slots sind alle nicht Verben eines
Frames, z.B. Subjekt und Objekt. Bei dem Frame
Agent V Topic wu¨rden die z.B. die Slots Subjekt
und Objekt durch die Argumente Agent und To-
pic gefu¨llt. Desweiteren sind die Verben aus der
selben Subklasse, die hier
”
Gera¨usche erzeugen“
heißen ko¨nnte, angegeben. Diese werden beno¨tigt,
falls im spa¨teren Verlauf dieser Methode die Ver-
ben generalisiert werden sollen.
110
Im Frame-Matching Schritt sollen fu¨r jedes Verb die mo¨glichen Rollen seiner Argumente be-
rechnet werden und die vorhandenen Argumentslots, wie Subjekt, Objekt, indirektes Objekt
und Adverbial, vorhergesagt werden. Die Argumente haben nun eine Menge an mo¨glichen Rol-
len, welche die Argumentslots fu¨llen ko¨nnten. Wenn diese Menge einelementig ist, so kann die
Rolle zugeordnet werden. Diese Daten, die eindeutig zuzuordnen waren, bilden die gelabelten
Anfangsdaten, mit welchen dann das Wahrscheinlichkeitsmodell trainiert werden kann.
Mo¨gliche Frames fu¨r V
vorhergesagte Slots
%Frame %Sent Score
Subj. Obj. Prbj.
Agent V Agent 100 33 133
Agent V Theme Agent Theme 100 67 167
Instrument V Theme Instr. Theme 100 67 167
Agent V Theme P Instr. Agent Theme Instr. 100 100 200
Agent V Recipient Theme Agent Recip. 67 67 133
Tabelle 1.11: Der Frame-Matching Schritt am Beispiel
In Tabelle 1.11 wird der Frame-Matching Schritt am Beispiel genauer dargestellt.
%Frame stellt hier den Anteil der zuzuordneden Argumente dar, die im Frame belegt werden
konnten. Fu¨r 4 der 5 mo¨glichen Frames konnten alle Argumente in einen Slot einsortiert wer-
den. Diese bekommen also alle den %Frame-Wert 100. Nur fu¨r das letzte Frame konnte das
Argument Theme nicht zugeordnet werden, da hierzu ein weiterer Objekt-Slot no¨tig gewesen
wa¨re. Es konnten also nur zwei von drei Argumenten einem vorhergesagten Slot zugeordnet
werden. Deshalb bekommt dieses Frame nur den %Frame-Wert 67.
%Sent ist der Anteil von den vorhergesagten Slots, die gefu¨llt werden konnten. Nur das vierte
Frame fu¨llt hier alle vorhergesagten Slots und bekommt somit einen %Sent-Wert von 100.
Die Score eines Frames ist nun einfach die Addition von %Frame und %Sent.
Nun mu¨ssen die maximalen Score-Werte betrachtet werden. Hat, wie in unserem Beispiel, nur
ein Frame einen maximalen Score-Wert, so kann dieser Frame mit den semantischen Rollen
gelabelt werden und schafft somit Anfangsdaten, mit denen dann in einem spa¨teren Schritt
die restlichen Daten annotiert werden ko¨nnen.
Um Slots zu fu¨llen, bei denen mehrere Mo¨glichkeiten zur Fu¨llung bestehen, muss nun ein
Wahrscheinlichkeitsmodell aufgestellt werden. Dieses sogenannte BackOff-Modell ist wie folgt
definiert,
λ1P1(r | v, sc) +
P (r | v, s, n) −→ λ2P2(r | v, nc) + −→ P (r | sc)
λ3P3(r | vc, s) +
(1.74)
mit r = Rolle, v = Verb, s = Slot, n = Nomen im Slot,
sc = Slotklasse, nc = Nomenklasse, vc = Verbklasse.
Wenn die Wahrscheinlichkeit einer Kandidatenrolle einen Schwellenwert minEvidence nicht
erreicht, so soll dieser noch zu fu¨llende Slot im na¨chsten BackOff-Level erneut untersucht
werden.
Wie in Formel 1.74 zu sehen ist, gibt es drei BackOff-Level. Das erste ist das spezifischste, bei
welchem das Verb, der Slot und das Nomen im Slot genutzt werden. P (r | v, s, n) ist also die
111
Wahrscheinlichkeit, wenn die Kombination Verb, Slot und Nomen auftritt, dass dann die Rol-
le r vorhergesagt wird. Im zweiten BackOff-Level wird schon eine starke Verallgemeinerung
vorgenommen. Hier werden drei Wahrscheinlichkeiten additiv kombiniert. In jeder der drei
kombinierten Wahrscheinlichkeiten wird eine Sache verallgemeinert. So wird in der dritten
Wahrscheinlichkeit, wie bei Abbildung 1.45 bereits erla¨utert wurde, das Verb auf die Verb-
klasse verallgemeinert. Die λ-Werte sind in dieser Methode bisher gleichverteilt. Im dritten
BackOff-Level ist dann nur noch eine ganz starke Verallgemeinerung vorhanden. Hier wird
eine Rolle nur noch unter Beru¨cksichtigung der Slotklasse zugeordnet. So sind nur noch sehr
allgemeingu¨ltige Zuordnungen, wie Subjekt impliziert Agent, mo¨glich.
Um nun eine Rolle auszuwa¨hlen, wenn mehr als zwei Rollen die Schranke minEvidence errei-
chen, so werden die besten zwei von diesen ausgewa¨hlt. Um die Gu¨te dieser beiden mo¨glichen
Rollenzuweisungen zu berechnen, wird der Logarithmus des Verha¨ltnisses gebildet. Nun muss
ein Schwellenwert log ratio erreicht werden. Wird auch dieser von beiden mo¨glichen Zuwei-
sungen erreicht so wird die Rolle mit der ho¨heren Wahrscheinlichkeit zugewiesen. Dieser
Schwellenwert wird hoch initialisiert und wird mit der Zeit immer weiter herabgesetzt.
Diese Methode wurde nun auf zufa¨llig ausgewa¨hlte 20% des British National Corpus ange-
wandt. Die Ergebnisse hiervon sind in Tabelle 1.12 zu sehen.
Rollenzuordnung
identifizierte Argumente alle Zielslots
Baseline
Algorithmus
Baseline
Algorithmus
eindeutig final eindeutig final
zugeordnet
korrekt 77.3 76.4 90.1 63.7 75.9 87.2
falsch 22.7 2.7 7.0 36.3 6.8 10.4
nicht zugeordnet
mo¨glich 0 17.1 0 0 14.1 0
unmo¨glich 0 3.8 2.9 0 3.1 2.4
Tabelle 1.12: Ergebnisse des Unsupervised Semantic Role Labelings
Unter Rollenzuordnung, nicht zugeordnet bedeutet unmo¨glich, dass keine Kandidatenlisten
vorhanden ist. In diesem Fall ist es natu¨rlich unmo¨glich eine Rolle zuzuweisen. Der Unter-
schied zwischen identifizierte Argumente und alle Zielslots ist, dass bei identifizierte Argu-
mente Fehler die in Vorverabeitungsschritten gemacht wurden nicht miteinbezogen werden,
bei alle Zielslots hingegen werden diese miteinbezogen. Dies ist sinnvoll, da so zuna¨chst die
Gu¨te des Verfahrens alleine unter identifizierte Argumente betrachtet werden kann. Allerdings
sind die Werte unter alle Zielslots die letztlich relevanten, da das Benutzen der Vorverarbei-
tungsschritte nun einmal unumga¨nglich ist. Die Baseline wird durch das dritte BackOff-Level,
welches in der Formel 1.74 zu sehen ist, beschrieben.
Was sehr auffa¨llig ist, ist dass viele Zuordnungen bereits wa¨hrend des Frame-Matching Schritts
gemacht werden. Dies ist in der Spalte eindeutig festgehalten. So wird die Baseline letztlich
sogar bereits durch den Frame-Matching Schritt u¨berschritten. Deshalb kann davon ausgegan-
gen werden, dass der Frame-Matching Schritt auch vielen supervised Methoden einen großen
Gewinn bringen ko¨nnte. [SS04, SS05]
1.6.3 CoNLL2005 - Shared Task
An der CoNLL2005 - Shared Task (Computational Natural Language Learning 2005 - Shared
Task) haben 19 Teams teilgenommen. Diese hatten 3 Monate Bearbeitungszeit zur Verfu¨gung.
112
Wörter POS-Tags Chunks Abschnitte komletter Syntaxbaum NEs Zielverben
Vorhersage der SR für 
das jeweilige Verb
Abbildung 1.46: Das Eingabeformat fu¨r die CoNLL-2005 an einem Beispielsatz
Auch im Jahr 2004 war das Thema der CoNLL Semantic Role Labeling, wodurch ein direk-
ter Vergleich mo¨glich war. Als Merkmale fu¨r den Lernschritt waren die Wo¨rter, POS-Tags,
Chunks (Basiszerlegungen), Abschnitte im Start-End-Format, Named Entities und die Zielver-
ben gegeben. Und in der 2005er Ausgabe der Shared Task war zusa¨tzlich noch der komplette
Syntaxbaum gegeben. Des Weiteren ist noch die Argumentzuordnung zu den semantischen
Rollen gegeben, diese ist aber natu¨rlich fu¨r die Lernmenge nicht verfu¨gbar gewesen. Ein Bei-
spielsatz in diesem Eingabeformat ist in Abbildung 1.46 zu sehen.
Was außerdem neu in der 2005er Shared Task war, ist dass die Trainingsdaten vergro¨ßert
wurden und eine neue Testmenge in Form des Brown-Korpus hinzugefu¨gt wurde. Die Trai-
ningsdaten stammten aber weiterhin aus dem PropBank Korpus, sowie dem WSJ, welcher
ein Teil des PennTreeBank Korpus ist.
In Tabelle 1.13 sind einige ausgewa¨hlte Systeme mit ausgewa¨hlten Merkmalen zu sehen. Die
Tabelle gibt an wie die einzelnen Systeme vorgegangen sind.
Unter der Zeile F1-Rang ist die Gu¨te der jeweiligen Systeme im Bezug auf die anderen Systeme
zu sehen. Wir haben hier die Positionen 1, 2, 4 und 17 ausgewa¨hlt, um anhand dieser, einige
Merkmale, die genutzt wurden, zu erkla¨ren. In der zweiten Zeile (Team) steht der Ku¨rzel des
Teams, welches das System entwickelt hat. So kann spa¨ter in den Ergebnissen einfach nach
dem Ku¨rzel gesucht werden.
F1-Rang Team ML-Method Kombination NE
Argument Verb
Typ PP Dic Ver Sub
1 pun SNoW ja + + + - + +
2 hag ME ja - + + + + +
4 pra SVM ja + + + - + +
17 pon DT nein + + - - + -
Tabelle 1.13: Auszug der Merkmalstypen ausgewa¨hlter Systeme in der CoNLL-2005
113
In der Spalte ML-Method ist vermerkt, welche Lernmethode zum Einsatz gekommen ist. An
dieser Stelle ko¨nnten auch mehrere Methoden stehen, bei unseren ausgewa¨hlten Systeme ist
es aber immer nur eine. Mit Absicht wurden hier vier Systeme gewa¨hlt, die mit unterschied-
lichen Lernmethoden arbeiten. So sind in unserem Ausschnitt Dependency Tree (DT), SVM
(Support Vector Maschine), Maximum Entropy (ME), sowie Sparse Network of Winnows
(SNoW) als Lernmethoden genutzt worden.
Unter Kombination ist vermerkt, ob eine Kombination von verschiedenen Ausgaben genutzt
wurde. Verschiedene Ausgaben konnten unter anderem durch verschiedene Lernalogrithmen,
verschiedene syntaktische Eingabestrukturen (es gab verschiedene Parser) oder durch nutzen
der n-besten Parsing-Kandidaten entstehen. Unter NE ist vermerkt, ob Named Entities ge-
nutzt wurden.
Dann folgen die Merkmale des Arguments. Dort ist unter Typ vermerkt, ob der syntaktische
Typ des Arguments genutzt wurde. PP (pra¨psitionale Phrase) gibt an, ob sezifische Merkmale
der PP genutzt wurden. Unter Dic wird angezeigt, ob semantische Wo¨rterbu¨cher verwendet
wurden. Ein solches Wo¨rterbuch sammelt Wo¨rter, die in der Trainingsmenge beispielsweise
ha¨ufig im Temporal oder Lokativ standen.
Dann gibt es noch die Merkmale, die das Verb betreffen. Ver zeigt hier an, ob die standard
Verbmerkmale, wie Voice (aktiv/passiv Unterscheidung), POS-Tag oder Form, benutzt wur-
den. Unter Sub, also Subkategorisierung, ist vermerkt, ob die syntaktische Regel, die den Elter
des Pra¨dikats erweitert, als Merkmal genutzt wurde. Ein Beispiel hierfu¨r wa¨re die Regel VP
→ V NP.
Grundsa¨tzlich kann zu den Systemen gesagt werden, dass die Systeme einen besseren F1-Rang
hatten, die mehr Merkmale verwendet haben. Außerdem hat sich herausgestellt, dass Kombi-
nation sehr wichtig ist. So haben 8 von 19 Teams eine Kombination verwendet und von diesen
sind bis auf einen alle unter den besten zehn Teams.
In Abbildung 1.47 ist eine vollsta¨ndige Abbildung aller Systeme und ihrer F1-Werte auf
den unterschiedlichen Korpus zu sehen. Die Baseline ist durch ein einfaches System aus der
CoNLL2004 gegeben.
Es wurde eine maximale F1-Score von circa 80 erreicht. Dies ist ein Anstieg um 10 Punkte im
Vergleich zu den Ergebnissen des Vorjahres. Diese Verbesserung entstand durch die 5-fache
Vergro¨ßerung der Trainingsmenge, die zusa¨tzliche Eingabe der kompletten Syntaxba¨ume und
die verfeinerten Kombinationsverfahren. Allerdings sind diese Ergebnisse immer noch zu weit
weg von Wunschergebnissen. Am Brown-Korpus ist zu sehen, wie gut ein SRL-Modul in
einer realen Anwendung abschneiden wu¨rde und dies ist etwa 10 F1-Punkte schlechter und
entspricht so nur einer F1-Score von 70. [CM04, CM05a, CM05b]
1.6.4 Fazit
In diesem Kaptiel wurden verschiedenste Verfahren zum Semantic Role Labeling vorgstellt.
Damit ging auch eine Vielzahl von Features einher. Deutlich wurde aber, dass das Path-
Feature und das Headword-Feature die dominantesten davon sind. In den Vergleichswettber-
weben sind diese Verfahren gegeneinander angetreten und es hat sich gezeigt, dass komb-
nierte Verfahren, also solche, die mehr als ein
”
Grundverfahren“ nutzen, die erfolgreichsten
sind. Die Wettbewerbe haben aber auch hervorgehoben, dass mit einem F1 von ca. 70%
noch viel Forschungs- und Optimierungspotenzial bestehen. Keines der Verfahren verwendet
doma¨nenspezifische Features. Fu¨r diese Projektgruppe ergibt sich daraus die Perspektive, den
F1-Wert durch die Anpassung der Verfahren auf die Bundestags-Doma¨ne zu verbessern.
114
Abbildung 1.47: Vergleich der Systeme der CoNLL2005
115
Abbildung 1.48: Chinesiche Wo¨rter
Die Techniken des SRL kann die Projektgruppe vor allem in den Bereichen der Fragebeant-
wortung und des Information Extraction nutzen. Eine grob eingegrenzte Antwort kann so
weiter zergliedert werden. Das ero¨ffnet unter Umsta¨nden die Mo¨glichkeit, dem Fragenden ei-
ne pra¨zise Antwort zu pra¨sentieren, die nur noch relevante Informationen entha¨lt und kein
nachtra¨gliche Suche des Fragenden im Antwort-Textschnipsel erfordert.
1.7 Treebank
1.7.1 Einfu¨hrung
Sprachverstehen wird oft als ein KI-vollsta¨ndiges Problem gekennzeichnet, weil fu¨r natu¨rliche
Spracherkennung umfangreiches Wissen u¨ber der Außenwelt zu verlangen ist, ausserdem soll
es auch in der Lage sein, Wissen zu manipulieren und verwenden. Die Definition von ”Verste-
hen¨ıst inzwischen ein Hauptproblem in NLP. Aber A paar Probleme ko¨nnen in dem Sprach-
verstehen(NLP4) immer betroffen werden:
ˆ Wo¨rtersegmentierung: Einige geschriebene Sprachen wie z.B. Chinesisch, Japanisch
und Thaila¨ndisch haben keine Einzelnen Wortgrenzen, deshalb verlangte jeder bedeu-
tungsvoller Text die Identifikation der Wortgrenzen, bevor der analysiert wird. diese ist
oft eine nicht-triviale Aufgabe.
Beispiel siehe Abbildung 1.48
ˆ Disambiguierung: Viele Wo¨rter haben mehr als eine Bedeutung, so dass wir die Be-
deutung, die den meisten Sinn in Kontext macht, auswa¨hlen mu¨ssen.
Bsp.: The old can can hold the water.
erste
”
can“: Beha¨lter
zweite
”
can“ modales Verb
ˆ Syntaktische Zweideutigkeit: Die Grammatik fu¨r natu¨rliche Sprachen ist zweideutig,
es ko¨nnen sich oft viele verschiedenen Sytnaxbaeume aus einem Satz ergeben, analysie-
ren Sie Ba¨ume fu¨r einen gegebenen Satz. Um dem Geeignetesten auszuwa¨hlen, verlangt
man normalerweise semantische und kontextuelle Informationen. Zur Bestimmung der
Problembestandteilen von Syntax auf einem Satz mu¨ssen wir uns mit ganzen Kontext
herumgucken, danach ko¨nnte man sich den Informationen entsprechendenden Analy-
senbaum herausfinden.
Beispiel siehe Abbildung 1.49
4Natural language processing
116
Abbildung 1.49: Syntaxmehrdeutigkeit
Das NLP befassen sich natu¨rlich nicht nur mit den oben sogenannten Problemen, aber in
diesem Abschnitt wollten wir soeben davon ausgehen. Um solche problematik zu verbessern,
kann man hier eine Mehtode
”
Baumbank“ verwenden.
1.7.2 Verallgemeinerte Treebank
Baumbanks ko¨nnen in Korpus-Linguistiken fu¨r das Lernen syntaktischer Pha¨nomene oder
in computational linguistic fu¨r die Training- oder Test-Parser benutzt werden.Genauso kann
ein Textkorpus von Linguisten ausgewertet werden, um Regelma¨ßigkeiten in dieser Sprache
beschreiben zu ko¨nnen. Mehrsprachige Korpora ko¨nnen zur (teil-)automatischen U¨bersetzung
oder fu¨r vergleichende Betrachtungen der Sprachen genutzt werden.
Definition Eine Baumbank ist ein Korpus, in dem jeder Satz mit
syntaktischen Strukturen kommentiert worden ist. Die-
se syntaktische Struktur wird im Allgemeinen als Baum-
struktur dargestellt.[AT00]
Vom Anfangen an ist die Wortarten-Annotation zu erledigen. Sie sollte mo¨glichst mit einem
geringen manuellen Korrekturaufwand verbunden und stellt heute eine Mindestanforderung
an ein Textkorpus dar.
Wortarten
Unter Wortart(englisch. POS5) versteht man die Klasse von Wo¨rtern einer Sprache auf Grund
der Zuordnung nach gemeinsamen grammatischen Merkmalen. Die Wortartlehre versucht ei-
ne Klassifizierung der lexikalisch-grammatischen Einheiten einer Sprache. Auf der Liste in
der Abbildung 1.50 stellen teilweise Wortarten aus der Penn Baumbank dar. Die Erfassung
und Kennzeichnung der Wortarten wurde urspru¨nglich manuell durchgefu¨hrt, im Laufe der
Zeit wurde das Verfahren zunehmend durch die Computerlinguistik automatisiert. Durch die
5part of speech
117
Abbildung 1.50: Liste des POS-Taggers
state-of-art Techniken kann u¨ber 96% Genauigkeit fu¨r die meisten erfolgreichen Ansa¨tze rea-
lisiert werden.
Bsp.: The representative put chairs on the table
DT NN VBD NNS IN DT NN
Automatische Wortartenannotation
Das automatische Annotation des Wortarts ist ein Bereich von der natu¨rlichen Sprache Ver-
arbeitung. Im Wesentlichen sind zwei unterschiedliche Methoden(Abb. 1.51), die sowohl sta-
tistisch als auch regelbasiert sind, ko¨nnen entwickelt werden. Aber statistische Techniken
scheinen sich erfolgreicher als regelbasierte Methoden zu sein. Die Tatsache, dass sehr wenig
handgefertigte Wissen im System aufgebaut werden muss. Demgegenu¨ber sind die Richtlinien
in den regelbasierten Systemen normalerweise schwierig zu konstruieren und sind nomaler-
weise nicht sehr robust. Von der ausfu¨hrlichen Sto¨rung Analyse kann es geschehen, dass das
regelbasierte Tagging mehr Probleme mit unbekannten Wo¨rtern als das statistische Tagging
hat. Durch die Forschung von der Universita¨t Zurich [Mit98] sind uns bekanntgegeben, wie
durch die Beiden automatische Taggingerstellung deutscher Sprache auszuwirken ist. Wenn
die unbekannten Wo¨rter in die Taggers mithilfe eines externen Lexikons eingezogen werden,
fa¨llt die Fehlerrate des regelbasierten Tagging auf 4.7% ab und wobei die Fehlerrate der sta-
tistischen Taggingsauf 3.7% senkt.
118
Abbildung 1.51: Prozess des POS-Taggings
Regelbasierte Annotation
Bei regelbasierte Annotation[Bri92] benutzt man eine große Datenbank von handgefertigten
Disambiguierungsregeln oder Regeln aus Baumbank, Um diese Methode einfach zu verstehen,
kann sich der ganze Annotationsprozess auf zwei Schritte gliedern:
Erster Schritt: Zuerst benutzt man ein Wo¨rterbuch, um jedem Wort des Textes eine Liste
potenzieller POSs zuzuweisen.
Zweiter Schritt: Diese Listen lassen sich durch die handgefertigte Disambiguierungsregeln
weiter verfeinern, danach kann man mit Hilfe der allen einzelnen POS-Taggings jedes
Wort trennen.
hierunter stellt ein ”that”Beispiel mit einem einfachen Verfahren dar. Aber hier das einfache
Wort scheint sich nicht mehr einfach zu sein, da das Wort that unterschiedliche Syntaxfunk-
tionen gib’s.
Adverbial-That Regel
Input: that
if (+1→ A/ADV/Pron/Noun)//falls adj, adv ,. . . direkt folgen
then eliminate ADV;
else if (+n→ Clause)//falls als Anfang von Klausel
then eliminate non-ADV
Ergebnis:
ADV: he isn’t that man!
Non-ADV: I am glad that you are satisfied with your job.
119
Statistische Annotation
Viele Statistische Modelle ko¨nnen im Trainingskorpus beitragen. Die Idee ist einfach und klar,
man kann z.B. mit HMMs, MEMMs, CRFs die Wahrscheinlichkeit bei der Annotation von
einem gegebenen Wort berechnen. Danach ko¨nnen die beste Zustandsequenz generiert werden,
um spa¨ter als Muster alle ungetaggte Wo¨rter zu u¨berpru¨fen und klassifizieren. Außerdem kann
man auch mit Hilfe von SVMs den Korpus automatisch annotieren. Aber schwer ist, wie man
die effiziente Kernfunktion auskriegen kann. In diesem Bericht erwa¨hnen wir das Verfahren
mit Bigram-HMM.
ti = arg max
j
P (tj |ti−1, wi) (1.75)
ti ist die beste Wahrscheinlichkeit fu¨r den Tag eines Wort wi, wobei i die aktuelle Stelle im
Satz und j das Index u¨ber alle mo¨gliche Tags sind. Durch die Markov-Annahme ko¨nnen die
oben genannte Formel umgeformt werden.
ti = arg max
j
P (tj |ti−1)P (wi|tj) (1.76)
Annotationsvorgang
wie im Abschnitt 1.2 beschrieben sind, dass Viterbi-Algorithmuss hier zu verwenden ist.
1) Initialisierung:
δ1(k) = pikP (w1|tk), 1≤k≤J (1.77)
Ψi(j) = 0 (1.78)
2) Induktion:
δi(j) = [max
i
δi−1(k)P (tj |tk)]P (wi|tk), 2≤i≤n, 1≤k≤J (1.79)
Ψi(j) = arg max
1≤j≤J
[δi−1(k)P (tj |tk)] (1.80)
maxi δi−1(k)P (tj |tk)]P (wi|tk) stellt den Forward-Algorithmus dar. In der Arrayliste Ψi(j)
werden dann die beste Wahrscheinlichkeit vom Tag k zum Tag j ausgesucht.
3) Terminierung:
Xn = arg max
1≤i≤N
[δn(j)] (1.81)
δn(j) sind die Wahrscheinlichkeiten aller mo¨glichen Tagssequenzen vom ersten bis zum letzten
Wort.
4) Optimale Zuru¨ckverfolgerung der Zustandsfolge:
120
for i := n-1 to 1 Step -1 do
Xi = Ψt+1(Xt+1) (1.82)
t = T-1, T-2, . . . , 1
Bsp.: The sportler is expected to win tomorrow
DT NNP VBZ VBN TO VB NN
Gegeben sind:
P (V B|TO) = 0.34 P (win|V B) = 0.00003
P (NN |TO) = 0.021 P (win|NN) = 0.00041
√
P (V B|TO)P (win|V B) = 0.34 ∗ 0.00003 = 0.0000102
× P (NN |TO)P (win|NN) = 0.021 ∗ 0.00041 = 0.00000861
Die verschiedenen statistischen Methoden ko¨nnen nicht nur zur Annotation der Wortarten
dienen, ferner ko¨nnen sie bei der Analyse von PCG6 weiterhelfen, da am Anfangen wir schon
erwa¨hnt haben, dass nicht nur das problem mit Disambiguierung von Wort, sondern auch mit
Syntaxmehrdeutigkeit vorkommt. Das ganze Verfahren bei automatischem Syntaxaufbau ist
a¨hnlich wie POS-Tagging.
Syntaktische Struktur
Bisher haben wir schon etwas u¨ber das POS-Tagging kennengelernt. Aber wie sieht aus Baum-
banks deren
”
Ba¨ume“ aus? schauen wir die Struktur von einem Beispielsatz an. Fu¨r Syntak-
tische Analyse ist durch kontextfreie Grammatiken leicht zu formalisieren.
S → NP VP
NP → Pronoun — Noun — Det Adj Noun —NP PP
PP → Prep NP
V → Verb — Aux Verb
VP → V — V NP — V NP NP — V NP PP — VP PP— VP S —V S
Mit Hilfe von der oben genannte Grammatik kann ein Syntaxbaum eines Beispielsatzs(Abb.
1.52) erstellt werden. Durch viele solche indizierte Satzba¨ume in einem Korpus entsteht die
endliche Produkt ”Baumbank”.
6Probabilistic Context-Free grammar
121
Abbildung 1.52: Syntaxbaum und Pra¨dikate-Argument-Struktur
1.7.3 PropBank
Geschichte der Penn Baumbank
Die bekannteste Baumbank ist die Penn Baumbank [AT00]. Die Entwicklung dieser Baum-
bank gliedert sich in drei Phasen. In der ersten Phase (1989-1992) annotierte ein symbolischer
Parser die Sa¨tze vor, die anschließend manuell korrigiert wurden. Bedingt durch den hohen
manuellen Aufwand musste in dieser Phase ein vereinfachtes Phrasenstruktur-Modell ver-
wendet werden, das auch als Parsing-Skelett bezeichnet worden ist. Da eine so detaillierte
Annotation nur teilweise durch statistische Methoden unterstu¨tzt werden kann, ist der Anteil
manueller Korrekturen sehr hoch. Zum Ende der zweiten Phase der Penn Treebank (1993-
1995) sind eine Million Wortformen der ersten Phase auf diese Weise aufbereitet worden. In
der dritten Phase (1996-1999) ist der Umfang der detaillierten Annotation nochmals um eine
Million Token erweitert worden.Diese Baumbank umfasste jedoch beachtenswerte 3 Millio-
nen Token und stellte damit eine hervorragende Ausgangsposition fu¨r computerlinguistische
Anwendungen dar.
Pra¨dikate-Argument-Struktur
Obwohl man mit einer Grammatik von dem Quellsatz die komplette Worte analysieren kann,
die Informationextraktion war ha¨ufig noch ungenaurig. Es fehlt noch im NLP etwas, das ist
genau die predicate-argument Struktur. Diese Notwendigkeit zeigt offenbar durch eine neue
Auswertung der Penn Baumbank [Kin02]. Die Qualita¨t des semantischen Tagging konnte
durch die wichtigste Faktor genauso die Pra¨dikate-Argument-Struktur beeinflußt worden.
Man kann die auch als Klammerstruktur bezeichnen, deren Schreibweise sieht a¨hnlich wie
Beschreibungslogik aus. Die Eingabe ist Syntaxbaum und Die Ausgabe ist, wie in Abbildung
1.52 ein einfaches Beispiel darstellt. Das Verb consider spielt im Beispiel die wichtigste Rolle,
da Ohne dies Wort der ganze Satz nicht mehr gekoppelt wird, d.h. macht der ganze Satz keinen
Sinn. Außerdem Obwohl das Wort fool hier Substantiv ist, kann man mit Hilfe von NomBank,
die im na¨chsten Abschnitt vorgestellt wird, leicht verstehen, warum es die Pra¨dikate vom
Subsatz ist.
Penn Baumbank++
Die Erfassung von linguistischen Regelma¨ßigkeiten ist immer schwer, da der semantischen
Annotation, die in einer normalen Treebank nicht zur Verfu¨gung stehen. aber jetzt sieht die
122
Abbildung 1.53: Pyramide des NLPs
Situation andere aus, weil mit Hilfe von der Pra¨dikate-Argument-Struktur die Penn Baum-
bank endlich vor dem Semantic-Role-Labeling stehen la¨sst, d.h. sie steigert sich von der syn-
taktischen Annotation auf der semantischen Annotation (Abb.1.53). Man kann auch die Prop-
Bank Penn Baumbank++ nennen. Hier gib’s die Linke zu diesem großartigen Projekt. Die
Anwendungen von PropBank im NLP ko¨nnen zur Maschinelle U¨bersetzung und Information
Extraktion dienen.
Frames Files
Argumentmerkmale Argumentmerkmale waren sinnvoll in PropBank zum Einsatz. Die
konnten auf die Eigenschaften eines Satzes leicht abgebildet werden. Sie wurden in den meisten
modernen Theorien der Argumentstruktur benutzt. Außerdem ko¨nnen Sie eigene Argument-
merkmale, die nicht besonders verpflichtet auf einer bestimmten Theorie basiert, erzeugen.
Prima¨re Labels: Argumentenelemente sind ARG[0→ 5], diese bieten ho¨here Korrelation zwi-
schen Argumenten und Pra¨dikaten als Adjuncts an.
Sekunda¨re Labels: (Annotation von Modifiern) fu¨r Adjuncts: TMP, LOC, PRP, MNR, . . .
Frames File
Jeder Eintrag im Annotationslexikon ist ein Frames File, dieses hat:
ˆ Eine Beschreibung des Verbsinnes ist im Frameset gekennzeichnet. Ein Frameset ist
eine Menge von syntaktischen Subkategorie Frames, die einige erwartete Argumente
oder semantische Rollen enthalten.
ˆ Eine Beschreibung der Menge von semantischen Rollen, mit der ein Frameset assoziiert
wird(Abb. 1.55).
ˆ Eine Beschreibung der Subkategorie Frames (Predikate + Realisierte Argumente) fu¨r
jedes Frameset. Bsp.: In Tabelle 1.14
ˆ Ein Mapping(Abb. 1.54) zwischen den syntaktischen Funktionen und den Argumentla-
beln fu¨r jedes Subkategorie Frame.
123
Abbildung 1.54: Das Mapping fu¨r eine Verbinstanz zu einem Frameset
Abbildung 1.55: Dependency Tree
124
Verb: pass Verb: pass
Frameset. 01= ”move/go” Frameset.02 = ”bill becomes law”
Semantic roles: Semantic roles:
Arg0: passer Arg0: lawmaker
Arg1: passing through Arg1: bill, regulation, law, etc.
Frame 1: Frame 1:
”The train is passing through ”The Congress passed the
the tunnel.” banking law recently.”
PropBank Annotation: PropBank Annotation:
Rel: passing Rel: passed
Arg0: train Arg0: passer
Arg1: tunnel Arg1: passing through
ArgM-TMP: recently
Frame 2 . . . Frame 2 . . .
Tabelle 1.14: Ein Beispiel vom Frameset
U¨berpru¨fung bei Interannotationen
Die Annotatoren selbe sind aus einer Vielzahl der Hintergru¨nde,die von den Student bis zu
PhDs7, Linguisten, Informatiker und andere sind, gekommen worden. Deswegen bevor die
Annotation startet, sollt bei allen Annotatoren u¨ber die Annotationregeln der PropBank ein
gutes Training erforderlich gewesen sein. Die Dauer des Trainings sind jedoch unterschiedlich,
bei einigen ist sehr schnell und erfolgreich, aber auch einige andere Leute haben immer Pro-
blem. Nach der Annotation der PropBank wird ein Vergleichtest zusa¨tzlich stattfinden, um
die U¨bereinstimmung des Interannotators zu u¨berpru¨fen. Hierzu ist Kappastatistik verwend-
bar. Beim Test werden Alle PropBank-Korpa von zwei Tagger annotiert.
κ =
P (A)− P (E)
1− P (E)
(1.83)
”
role identification(role vs. non-role)“ bedeutet, dass bei der Annotation nur fu¨r jedes Wort
oder jede Wortgruppe aus dem Korpus entscheidbar ist, ob die Rolle sind, oder keine.
”
role
classification (Arg0 vs. Arg1 vs. . . . )“ sind verfeinertere Entscheidungen als die oben sogenann-
te Rolle-Identifikation. Die P(A) ist die erwartete U¨bereinstimmungswahrscheinlichkeit der
Interannotation und P(E) ist die zufa¨llig erwartete U¨bereinstimmung. Kappastatistik fu¨r diese
verschiedenen Argumententscheidungen wird gezeigt in Abbildung 1.56. Die U¨bereinstimmung
u¨ber Rollenannotation ist unter beiden Behandlungen von ArgMs sehr hoch auf (0.99. Be-
ruhigend ist das Kappaergebnis fu¨r die schwierigere Rollenklassifikationaufgabe auch hoch
auf 0.93, schließlich sind alle Arten ArgM und nummerierte Argumente zu betrachten. Kap-
pa berechnet auf der kombinierten Annotation und der Klassifikationentscheidung u¨ber allen
Knoten in Baumbank war 0.91, einschließlich von ArgM und 0.93 u¨ber nummerierte Argu-
menten.
7Doctor of Philosophy
125
Abbildung 1.56: U¨bereinstimmung des Interannotators
Vergleich zum FrameNet
Das PropBank Projekt und das FrameNet, welches vom International Computer Science In-
stitute entwirkelt wurde, teilen die Dokumentation der syntaktischen Realisierung der Ar-
gumente von den Pra¨dikaten des allgemeinen englischen Lexikons mit einander. Die beiden
annotieren einen Korpus mit semantischen Rollen. Trotz der zwei A¨hnlichkeiten von beiden
sind ihre angewendete Methoden unterschiedlich. FrameNet wird auf semantische frames ge-
richtet, die als vereinfachte Darstellung der Situationen, der verschiedene Teilnehmern und
anderer Begriffsrollen definiert werden. Obwohl die beiden Performancen beim SRL8 fast
gleich sind, bietet PropBank die Einfachkeit der Annotation und mehr Lernfa¨higkeit an.
In Propbank sind Argumentlabel verbspezifisch. Das Arg0 ist aus einem Frameset vom
buy, hingegen in FrameNet werden die die Verben instanziert. Die Frame Elemente sind
verbklassen-spezifisch. Z.B. Buyer aus dem Frame Commerce u¨ber eine Klasse der Verben:
buy, lease, purchase, rent, . . .
PropBank FrameNet
Buy Sell Commerce
ARG0: buyer Arg0: seller Buyer:
Arg1: thing bought Arg1: thing sold Seller:
Arg2: seller Arg2: buyer Payment:
Arg3: price paid Arg3: price paid Goods:
Arg4: benefactive Arg4: benefactive Rate/Unit:
Bsp.: FrameNet Annotation(1) und PropBank Annotation(2)
(1) [Buyer: Tim] bought [Goods: a car] [Seller: from Tom] [Payment:for $1000].
(2) [Arg0: Tim] bought [Arg1: a car] [Arg2: from Tom] [Arg3: for $1000]
Automatisierung des Semantic-Role-Labeling
Das Ziel des PropBank ist, die Trainingsdaten fu¨r automatische Rollentags zur Verfu¨gung zu
stehen. Eine von PropBank wichtigen Eigenschaften als praktisches Hilfsmittel ist, dass die
Sa¨tze, die fu¨r Annotation aus dem Wall Street Journal-Korpus gewa¨hlt sind, werden fu¨r das
urspru¨ngliche Penn Baumbank Projekt benutzt. Und folglich sind manuell-gepru¨fte syntakti-
sche Analyse-Ba¨ume fu¨r den gesamten Datensatz vorhanden .
8semantic role labeling
126
[GJ02b] beschreibt ein statistisches System, das auf den Daten vom FrameNet Projekt ver-
wendet wurde, um semantische Rollen automatisch zuzuweisen. Das System hat zuerst Sa¨tze
durch einen automatischen Grammatikparser [Col99] bestanden. Es extrahierte syntaktische
Eigenschaften und scha¨tzte die Wahrscheinlichkeiten fu¨r semantische Rollen von den syn-
taktischen und lexikalischen Eigenschaften. analysiert Training und Testsa¨tze automatisch,
wie keine per Hand-Annotation Ba¨ume waren fu¨r das Korpus analysieren vorhanden. Im
Abschnitt 1.5 sind schon beschrieben, wie durch die Merkmale von den semantischen Rollen
mit dem Back-Off Modell die Wahrscheinlichkeiten eines Satzbestandteils als die erste Tei-
laufgabe abzugrenzen sind (englisch. chunk). Zum zweiten werden die Relation zwischen allen
abgrenzten Wo¨rterstu¨cken durch die CCG9 analysiert [GH03].
Ereignissevariablen
Man sucht im Bereich des NLPs ein reiches Werkzeug fu¨r das Analysieren von Verbenbedeu-
tung. Jetzt per eine Ereignisvariable la¨sst eine direkte Darstellung der logischen Form von
den adverbialen Modifikatoren und der Darstellung der Substantivwo¨rtern, die auf Ereignisse
beziehen, zu.
Satz.: Mr. Bush met him privately, in the White House, on Thursday.
a. PropBank Annotation
Rel: met Arg0: Mr. Bush
ArgM-MNR: privately ArgM-LOC: in the White House
ArgM-TMP: on Thursday
b. Logische Darstellung mit einer Event Variable
∃ e meeting(e) & Arg0(e, Mr. Bush) & Arg1(e, he) & MNR(e,privately) & LOC(e, in the
White House) & TMP(e, on Thursday)
PropBank II
PropBank II sind an der Parallel chinesisch-englische U¨bersetzung angewendet und außerdem
fasst Ereignissevariablen, nominale Hinweise um. Es liegt hier eine einfache Darstellung zur
Parallel chinesisch-englische U¨bersetzung (Abb. 1.57) vor.
1.7.4 NomBank
NomBank ist ein Teilprojekt der Penn Baumbank II, um die zusa¨tzlich logischen und se-
mantischen Rollen der Penn Baumbank hinzufu¨gen. Sie dient zur Annotation der Nominelle
Pra¨dikat-Argument-Struktur. Deren Framen sind im Allgemeinen gleich wie PropBank(ARG0,
ARG1, . . . ) und arbeitet mit der PropBank zusammen und fu¨hrt zur Verbesserung der Ana-
lyse des Korpus. Zur Zeit stellt NomBank Argumentstruktur fu¨r Fa¨lle von ungefa¨hr 5000
allgemeinen Substantivwo¨rtern zur Verfu¨gung. Hier ist die Linke zur Webseite der NomBank.
mit dem folgenden Beispiel kann man leicht verstehen, was die NomBank grundsa¨tzlich tut.
Analyse der Substantivphrasen
9combinatory categorial grammar
127
Abbildung 1.57: englisch-chinesische PropBank
Beispiel.: the museum’s director
REL = director, ARG0 = director, ARG2 = the museum’s
Verschiedene Lexika
Die verschieden Lexika sind die grundlegenden Bausteine, sie unterstu¨tzen sich mit einanderen
und stellen die Modularita¨t von der Nombank dar. Die folgende Liste sind die wichtigste
Resources von Hand-kodierten elektronischen Lexika[MRM+04]:
ˆ NOMLEX ist eine Wo¨rterbuchauflistung, darin gib’s 1000 Nominalisierungen als Sub-
stantivphrase.
ˆ NOMLEX-PLUS ist eine Erweiterung von NOMLEX, um Substantivargumentenstruk-
tur zu identifizieren.
ˆ COMLEX ist ein syntaktisches Wo¨rterbuch von Substantiven, Verben, Adjektiven und
Adverbien
ˆ COMLEX-PLUS ist eine Anreicherung der Substantivkomplementstruktur vom COM-
LEX
ˆ CATVAR ist ein Wo¨rterbuch u¨ber die Erkla¨rung lexikaler Felder durch derivational-
Morphologie
ˆ ADJADV ist ein Wo¨rterbuch, das adverbiale Verwendungen der Adjektive definiert.
128
Abbildung 1.58: Die Relation zwischen Lexika
ME-Modell fu¨r SRL
Die SRL10-Aufgabe der NomBank wird als Klassifikationproblem behandelt und gliedert sie
sich in zwei Teilen: Argumentidentifizierung und Argumentklassifikation [JN06]. Opennlp ma-
xent11ist eine Implementierung von dem maximalen Entropie Modell , es wird als das Klas-
sifikationwerkzeug verwendet.
p(l|x) =
exp(
∑n
i=1 λifi(l, x))
Zx
(1.84)
λi ist der Gewichtsparamter fu¨r jede EigenschaftFunktionfi(l, x). fi(l, x)ist eine Eigenschafts-
funktion, um die Abbildung des Merkmals l und der Eingabe x entweder 0 oder 1 zu beschrif-
ten. Zx ist ein Normalisierungfaktor, damit die Summe gleich 1 wird. Im Identifizierungsmodell
wird Merkmal l entweder
”
Argument“ oder
”
Nicht-Argument“ gekennzeichnet. Die Klassifi-
kationsausgabe ist das Merkmal l mit der ho¨chsten Wahrscheinlichkeit p(l|x).
Max(T ) = max{
NONE(T ) +
∑
(Max(child))
ARG(T ) +
∑
(NONETree(child))
(1.85)
Der Algorithmus, durch den die Argumente nicht zu u¨berlappen sind, ist beno¨tigt beim Test.
So kommt der maximale Logwahrscheinlichkeit -Algorithmus vor, um ME-Modell zu verfei-
10semantic role labeling
11Die Linke zur Resource
129
nern. Max(T ) ist die maximale Log-Wahrscheinlichkeit von einem Baum.
”
NONE(T )“ und
”
ARG(T )“ sind die Log-Wahrscheinlichkeit der
”
None“ und
”
ARG“ vom Argumentidentifika-
tionsmodell zu Baumknoten T . Und
”
NONETree(child)“ is the Log-Wahrscheinlichkeit von
jeder Knote, die unter Kinderknote ist, werden auch dann alle als
”
NONE“ gekennzeichnet.
In Abbildung 1.59 stellt dieser Algorithmus per Pesudo-Code ausfu¨hrlich dar.
130
Abbildung 1.59: Maximale Log-Wahrscheinlichkeit Algorithmus
131
Eine gemischte Darstellung
In kombinierten PropBank und NomBank ist eine grafische Darstellung wie in der Abbildung
1.60 vorgekommen. In der jede Rolle einer Bogenline entspricht. Z.B. wir ko¨nnen zuerst die
Argumentstruktur des Substantivwort ovation genau wie des Verb applaud annehmen. Da-
nach entsprechend unserer Analyse sind (they) die Geber von (the ovation) und the chefs sind
dagegen die Empfa¨nger. Außerdem hat (gave) und (ovation) zwei eindeutige Richtungsrela-
tionen.
Abbildung 1.60: PropBank und Nombank
PropBank:
REL = gave
ARG0 = they
ARG1 = a standing ovation
ARG2 = the chefs
NomBank:
REL = ovation
ARG0 = they
ARG1: Pra¨position
SUPPORT = gave
SUPPORT-Verben sind Verben, die Sub-
stantivwo¨rter bis eins (oder mehr) ih-
rer Argumente per das Argumentteilen
anschließen. Z.B. John took a walk, das
Verb took teilt sein Subjekt mit dem
Substantivwort walk. Aber SUPPORT-
Verben ko¨nnen aus einigen Gru¨nden pro-
blematisch sein.[BR04]
Fehler und Problem
Mit Hilfe der NomBank hat die Genaurigkeit der Interannotation schon auf etwa 85% ge-
steigert. Aber es gibt noch einige Ursachen, Durch die das Ergebnis der Annotation negativ
auszuwirken ist: a)Widerspru¨che hinsichtlich der SUPPORT-Verben und die geteilten Ar-
gumente, die zu ihnen geho¨ren; b) Unterschiede zwischen den Annotatoren ko¨nnten durch
Sto¨rungen(Tippfehler, schlecht geformte Ausgabe, u.s.w) verursachen.
Zum Punkt a) sollte man mo¨gliche Eigenschaften von SUPPORT-Verben formalieren und
betrachten[BR04]:
ˆ Paare der SUPPORT Verb/Substantivwort ko¨nnen idiosynkratisch angeschlossen wer-
den. Einige Forscher nennen sie Idiome oder Redensart
Z.B. take a walk
132
Abbildung 1.61: NEGRA Format
ˆ Das Verb kann wesentlich leeren Sinn sein.
Z.B. make an attack
ˆ Die (Verb/Substantiv) Kombination kann eine bestimmte Argumentenmenge nehmen,
aber die Bedeutung ist ganz anderes von jedem einzelnen Wort.
Z.B. take advantage of
ˆ Einige SUPPORT-Verben teilen das Subjekt von jeder mo¨gliche Nominalization in ei-
nem bestimmten Argument.
Z.B. He attempted an attack
ˆ In einigen Fa¨llen sind SUPPORT-Verb und das Substantiv aus den a¨hnlichen semanti-
schen Kategorien.
Z.B. fight a battle
1.7.5 TIGER Baumbank
Die TIGER Baumbank ist ein gemeinsames Projekt von dem Department of Computatio-
nal Linguistics and Phonetics in Saarbru¨cken, dem Institut von Natural Language Proces-
sing(IMS) in Stuttgart und dem Institute fu¨r Germanistik in Potsdam. Sie setzt auf den
Ergebnissen des Projekts NEGRA auf. Wobei NEGRA Projekt eine erste deutsche Baum-
bank ist. Die Ziele des TIGER-Projekts sind die Verfeinerung und Erweiterung der Negra-
Annotationsrichtlinien und die Erstellung einer Baumbank mit 40.000 Sa¨tzen. Die Annota-
tion erfolgt dabei halbautomatisch. Ein Wortarten-Tagger und ein partieller Parser schlagen
fu¨r jeden Satz die Wortarten- bzw. Phrasenannotierung vor, die dann vom Annotierer korri-
giert werden muss. Wa¨hrend im Englischen aufgrund der festen Wortstellung Basispositionen
und damit die Position von Spuren leicht zu bestimmen sind, ist dieses im Deutschen we-
sentlich schwieriger. Die Basisposition extraponierter Komplementsa¨tze beispielsweise ist bis
heute umstritten. Daher sind im TIGER-Korpus Pra¨dikat-Argument-Strukturen als Teile ei-
nes ungeordneten Baums, d.h. eines Graphen mit kreuzenden Kanten, vgl. Abb.1.61 annotiert
worden.
Die Basis des TIGERS Baumbank sind Texte aus dem deutschen Zeitung Frankfurter Rund-
schau, um eine ausgedehntere Strecke der Sprachvera¨nderungen zu umfassen. Nur komplette
Artikel werden benutzt, die wurden von aller Arte des domains(regionale, sportliche. . . ) an-
genommen wurden.
133
Abbildung 1.62: TIGER-Format
Zuna¨chst schauen wir um, wie die Annotation im NEGRA-Format aussieht. Sie unterscheidet
drei Ebenen (vgl. Abb. 1.61):
1. Tags auf Wortebene, die die Wortart und morphosyntaktische Information angeben (z.B.
ART Masc.Nom.Sg fu¨r Artikel, Maskulinum, Nominativ, Singular).
2. Knotenbeschriftungen fu¨r phrasale syntaktische Kategorien (z.B. NP fu¨r Nominalphra-
se)
3. Kantenbeschriftungen fu¨r syntaktische Funktionen (z.B. HD fu¨r Kopf, SB fu¨r Subjekt).
Alle Kreuzende Kanten werden u¨ber die Beschreibung von Argumenten hinaus auch zur Ko-
dierung von weiteren linguistischen Abha¨ngigkeiten verwendet. In der Abbildung 1.61 liegt
beispielsweise ein extraponierter Relativsatz vor, der u¨ber eine kreuzende Kante mit der No-
minalphrase des Bezugsnomens verknu¨pft wird.
Im Vergleich zm NEGRA-Format stellt eine weitere Besonderheit des Datenmodells, die so
genannten sekunda¨ren Kanten sind, dar. Sie werden bei der Behandlung der Koordination
eingesetzt (vgl. Abb. 1.62. Die koordinierten Elemente werden zusammengefasst, um eine neue
Konstituente zu bilden (hier: CNP fu¨r koordinierte Nominalphrasen und CS fu¨r koordinierte
Teilsa¨tze). Dabei kann es vorkommen, dass Konstituenten in einem der Konjunkte fehlen. In
diesem Fall werden sekunda¨re Kanten gezogen. Im vorliegenden Beispiel ist das Personalpro-
nomen Er sowohl Subjekt des ersten als auch des zweiten Konjunkts; A¨pfel und Birnen ist
entsprechend das Akkusativobjekt beider Konjunkte.
Es gibt zwei Annotationsmethoden in TIGER:
ˆ Die verallgemeinerte Annotation la¨uft im gleichen Format wie die PropBank, das NE-
GRA Projekt von der Uni- Saarbru¨cken wird verwendet. Das entha¨lt:
134
Abbildung 1.63: Lexikalisch-funktionale Grammatik
1. POS Tags sind Stuttgart-Tu¨bingen-Tagset (STTS)
2. Morphologische Analyse sind die erweiterten STTS
3. Die grammatische Funktion in der direkt dominierenden Phrase
4. ie Kategorie von nichtterminalen Knoten (Phrasen)
ˆ zweistufige LFG12-Annotation:
1. Der TIGER-Korpus wird durch die LFG-Grammatik analysiert und die Ausgabe
der LFG-Grammatik wird halbautomatisch disambiguiert.
2. Die ausgewa¨hlte Ausgabe wird dann automatisch zum TIGER-Exportformat(TigerXML)
konvertiert.
Lexikalisch-funktionale Grammatik
LFG ist Eine Transformationsgrammatik fu¨r die Syntax, Morphologie und Semantik. Im Ge-
gensatz zur Chomskys Grammatik, die durch Transformationen verbundene separate Ebenen
der linguistischen Darstellung beinhaltet, basiert auf zwei sich gegenseitig einschra¨nkenden
Strukturen:
ˆ Ein Konstituentenbaum (C-Struktur):
– Konstituenten sind Wortfolgen, die in einem inneren Zusammenhang stehen. Sie
werden auch als Phrasen bezeichnet. Ein Satz entha¨lt Informationen u¨ber Mor-
phologie, Wahlbereich und linearer Ordnung. Um die C-Struktur zu verstehen,
betrachten wir zuna¨chst folgende einfache formale Grammatik(abb.). die Wo¨rter,
werden nicht in der Grammatik angegeben, sondern stehen in einem Lexikon von
Terminalsymbolen.
Da C-Struktur alleine nicht ausreichend, wird F-Struktur als zusa¨tzliche Eigenschaft genutzt.
Hier gibt’s ein sinnvolles Beispiel 1.63 aus Wikipedia.
12Lexikalisch-funktionale Grammatik
135
Abbildung 1.64: Trigram-HMM
ˆ eine Merkmalstruktur (F-Struktur):
– Sie stellt Informationen der Pra¨dikatargumentenstruktur, u¨ber Modifikation, Zeit,
Stimmung u.s.w. dar.
– Bei einer ↑=↓ Zuordnung wird die F-Struktur des u¨bergeordneten Knotens der
C-Struktur mit der F-Struktur des untergeordneten Knotens unifiziert.
– Gleichung (↑ Subject) =↓ unifiziert den Knoten Subjekt der F-Struktur des u¨bergeordneten
Knotens der C-Struktur mit der F-Struktur des untergeordneten Knotens.
– Die Notation der Unifikationsstruktur erfolgt in Attribut-Wert-Matrizen.
automatisierte Annotation vom TIGER
Wortartenannotation-TnT In TIGER Baumbank wird ein Tagger, der TnT heißt, fu¨r auto-
matisierte Annotation benutzt. TnT ist die Abkurzung von Trigrams’n’Tags, Dieser Tagger in
Abbildung 1.64 ist eine Implementierung des Viterbi-Algorithmus fu¨r Zweiordnungen Markov
Modell. Unbekannte Wo¨rter werden durch ein Suffix und eine aufeinander folgende Abstrak-
tion behandelt [Bra00].
Cascaded Markov Modell Die grundlegende Idee der Cascaded Markov Models ist der Syn-
taxbaum Schicht fu¨r Schicht zu erstellen, erste Strukturen(POS-Tagging) von Tiefe eins, dann
eine Ebene hoch ist von Tiefe zwei gekennzeichnet und so geht’s weiter(Phrasenvereinbarung).
Fu¨r jede Schicht stellt ein markov Modell den besten Satz von Phrasen fest. Diese neuen fest-
gestellten Phrasen sind wiederverwendbar und fu¨r die folgende Schicht als Eingabe. Eine T
die eine weitere Schicht addiert. die Phrase, die in jeder Schicht angenommen wird, wird
136
Abbildung 1.65: Cascaded Markov Modell
nach dementsprechenden stochastischen kontextfreien Grammatikrichtlinien erzeugt(die Aus-
gaben des Markov Modells) und nachher von links nach rechts durch Markov Modelle gefiltert
[Bra99].
1) Initialisierung:
∆0,t(q) = P (q|qs)δ0,t(q) (1.86)
2) Induktion:
∆t,t′ (q) = max
(t′′ ,t,q′ )∈Lattice
∆t′′ ,t(q
′)P (q|q′)]δt,t′ (q), 1≤t < T. (1.87)
3) Terminierung:
max
Q∈Q?
P (Q,Lattice) = max
(t,T,q)∈Lattice
∆t,T (q)P (qe|q). (1.88)
137
Korpusanfragesprache
Eine vollsta¨ndige Beschreibung der Konzeption der Sprache befindet sich in [Lez02]. Diese
Anfragesprache besteht aus drei Niveaus. Auf dem ersten Niveau ko¨nnen Knoten durch Boole-
sche Ausdru¨cke u¨ber Attributwerte beschrieben werden. z.B. bei der Abfrage [word=”lacht”&
pos=”VVFIN”] wird genau dann die Terminalknote lacht ausgewa¨hlt. Auf dem zweiten Ni-
veau werden Knoten u¨ber Relationen miteinander verknu¨pft. hier listen wir beispielweise a
paar Zeichens von Relationen auf:
> direkte Dominanz
> ∗ allgemeine Dominanz
. lineare Pra¨zedenz
.∗ allgemeine Pra¨zedenz
$ Geschwister
$.* Geschwister mit Pra¨zedenz
Auf der Graphbeschreibungsebene werden schließlich Knotenrelationen durch boolesche Aus-
dru¨cke verknu¨pft. Um die Identita¨t zweier Knoten auszudru¨cken, werden Variablen eingesetzt.
Zur Zeit wird diese Anfragesprache in TIGERSearch(Query) genutzt und implementiert.
TigerXML
Baumbanken mu¨ssen zuna¨chst in das Korpusdefinitionsformat konvertiert werden. Aber wenn
dies Format nicht standardisiert ist, fu¨hrt zu Schwierigkeiten bei der Entwicklung, oder Er-
weiterung von Konvertierungsprogrammen. Außerdem werden bei der Korpusanfragung die
gezielten Anfrageergebnisse beeinflusst. Deswegen lassen sich diese Probleme durch XML-
Datenformat lo¨sen. In Abbildung 1.66 stellt dies TigerXML-Format bzw. dessen gezielte
Information aus TIGER-Korpus dar. Es dient dazu, dass zum einem eine Validierung der
gespeicherten Daten und zum anderen eine grafische Darstellung des TIGER-Korpus zu
ermo¨glichen, ferner ist die Korpusanfrage in TIGER auch mo¨glich. Im folgenden Abschnitt
TIGERSearch wird direkt vorteilhaft beschrieben, warum mit XML und wie gut ist sie.
1.7.6 TIGERSearch
Das TIGERSearch-Werkzeug(abb.1.67) besteht aus drei Einzelprogrammen: mittels TIGER-
Registry ,TIGERSearch und TIGERGraphViewer. Einen U¨berblick u¨ber die Funktionsweise
und Systemarchitektur stellen das [EK03] und in Abbildung 1.68 dar. Außerdem um schnel-
ler das Tool zu erlernen, ko¨nnen Sie unter diese Linke aus Projektgruppe des TIGERs eine
detailierte Vorstellung vom TIGERSearch einsehen.
TIGERRegistry
Fu¨r den Import diverser Korpus-Formate u¨berfu¨hrt TIGERRegistry das zu importierende
Korpus zuerst in das eigene TIGER-XML-Format. Aus der XML-Zwischendarstellung wird
dann der Korpusindex erzeugt. Durch die Generierung einer XML-Zwischendarstellung ist der
138
Abbildung 1.66: TigerXML im Vergleich zum Syntaxbaum
Abbildung 1.67: TIGERSearch GUI
139
Abbildung 1.68: Architektur des TIGERSearchs
Indexierungschritt unabha¨ngig vom Importfilter und erleichtert so dessen Erstellung. Dass bei
der Zwischendarstellung das XML-Format gewa¨hlt wurde, hat zudem noch die Vorteile, dass
zur Bearbeitung und Validierung eines Korpus XML-Werkzeuge eingesetzt werden ko¨nnen
und dass - falls ein zu importierender Korpus in einem XML-Format vorliegt - die Erstellung
eines XSLT-Stylesheets zur U¨berfu¨hrung in das TIGER-XMLFormat ausreicht.
TIGERSearch
Eine textuelle Suchanfrage ist nach dem Laden eines Korpus mit TIGERSearch mo¨glich. Im
Frame linksunter werden alle Attribute des geladenen Korpus angezeigt. Die mo¨glichen Wer-
te mit Erkla¨rungen, falls Erkla¨rungen in der Korpusdefinition enthalten sind, lassen sich in
einem Pulldown- Menu¨ einsehen. Die Anfrage muss dabei in der speziellen TIGERSearch-
Anfragesprache erfolgen. Nach Absenden der Anfrage mit dem SSearchKnopf wird, fu¨r den
Benutzer nicht sichtbar, die Anfrage normalisiert, d.h. in eine disjunktive Normalform ge-
bracht. Um die Anfragebearbeitung zu beschleunigen, wird danach eine Anfrageoptimierung
durchgefu¨hrt. Nachdem alle relevanten Sa¨tze durchsucht worden sind, wird der TIGERGra-
phViewer zur Ergebnisvisualisierung gestartet. Wa¨hrend der Suche wird der Benutzer u¨ber
den aktuellen Fortschritt durch einen Statusbalken informiert. Die Suche la¨sst sich jederzeit
abbrechen.
TIGERGraphViewer
Der TIGERGraphViewer kann zum einen die Phrasenstruktur-Ba¨ume der einzelnen Sa¨tze
eines Korpus anzeigen, zum anderen dient er zur Visualisierung der Anfrageergebnisse. Dabei
werden die gefundenen Strukturen farblich hervorgehoben. Unterhalb der grafischen Baum-
darstellung des Satzes befinden sich eine Anzeige, die u¨ber Anzahl der Sa¨tze und Treffer
Auskunft gibt, und Bedienelemente zur Navigation. Mit den beiden Kno¨pfen im Feld SSub-
graph”navigiert man innerhalb eines Satzes, d.h. es wird nicht zu einem anderen Satz ge-
sprungen, sondern lediglich zur na¨chsten Fundstelle innerhalb des Satzes, wobei nun andere
Strukturen eingefa¨rbt werden, die ebenfalls zu einem Treffer gefu¨hrt haben. Die Baumdar-
140
stellung einzelner Sa¨tze la¨sst sich in den Formaten JPG13, PNG14, PDF15 und TIF16 als
Bitmap-Grafik oder im SVG-Format17 als Vektor-Grafik speichern. Außerdem lassen sich alle
oder eine Sequenz der Ba¨ume in dem XML-basierenden SVG-Format mitsamt Navigation
speichern, die es erlaubt, interaktiv zu den einzelnen Ba¨umen zu springen.
1.7.7 Event Extraction
Einleitung
Der Begriff Information Extraction wird definiert als die automatische Identifikation und
strukturierte Repra¨sentation von Entities, Relationen oder Events in natu¨rlich- sprachlichen
und meist unstrukturierten Texten. Ziel ist dabei, aus einer vordefinierten Doma¨ne Wissen
zu erzeugen.
Anwendungsbereiche fu¨r die Information-Extraction sind z.B. ·Analyse von Zeitungsartikeln
nach relevanten Wirtschaftsdaten · Zusammenfassen von gro¨ßeren Texten · Erstellung eines
Index
Es gibt zwei Typen von Information Extraction. Zum einen die name- extraction, auch be-
kannt unter dem Namen ”Named Entity Recognition”[na¨heres dazu in: Kapitel 1.2] und zum
anderen die event-extraction, welches hier na¨her erla¨utert wird.
Einleitung
Die Event Extraction wird bezeichnet als die Extraktion von Entita¨ten und anderen seman-
tischen Einheiten aus natu¨rlich sprachlichen Texten. Konkretes Ziel hierbei ist es, die Text-
elemente in eine wesentlich bessere maschinenlesbare Form zu bringen. Abspeicherung dieser
Elemente ko¨nnen in Datenbanken oder XML- Strukturen geschehen wie von Grishman vorge-
schlagen wird [Mit03]. Die einheitliche Extrahierung der Informationen sorgt fu¨r eine leichte
Durchsuchung und dient einer effizienteren Weiterverarbeitung.
Ein weiterer Begriff in der Information Extraction ist der des Relation Extraction. Relation
Extraction kann dazu verwendet werden Beziehungen zwischen Named Entities und andere
semantischen Einheiten zu extrahieren. Man kann also die Relation Extraction dazu verwen-
den, Events zu erkennen. Ziel der Relation Extraction ist die Named Entities und andere
Informationen, welche extrahiert worden sind, in Beziehung zu bringen um die Events zu
stu¨tzen. [na¨heres dazu im Abschnitt Relation Extraction]
Grundlagen
Da die Eingabe fu¨r die Event Extraction natu¨rlich sprachliche Texte sind, die nicht alle
eine einheitliche Struktur aufweisen ko¨nnten, kann sich die Herangehensweise fu¨r die Event
Extraction auch in einigen Schritten unterscheiden. Textstrukturen werden klassifiziert in:
ˆ Strukturierte
13Joint Photographic Experts Group (JPEG) File Interchange Format
14Portable Network Graphics
15Portable Document Format
16Tagged-Image File Format
17Scalable Vector Graphics
141
ˆ Halb-Strukturierte
ˆ Unstrukturierte
Wenn der Text im gu¨nstigsten Fall strukturiert vorliegt, ist die Event Erkennung mithilfe von
Mustern mo¨glich, ohne viel linguistische Kenntnisse zu beno¨tigen. Fu¨r die Event Extraction
in halb-strukturierten Texten ist eine Kombination aus Mustern und der erho¨hten Kenntnis
der Linguistik no¨tig. Im ungu¨nstigsten Fall in welchem der Text vo¨llig unstrukturiert ist,
reichen einfache linguistische Kenntnisse nicht aus. In diesem Fall ist eine Layout-Analyse
durchzufu¨hren. Um einen strukturierten Text zu erhalten, kann man die Methode der Named
Entity Recognition durchfu¨hren. Diese dient der Bestimmung und Klassifizierung von Eigen-
namen. Mithilfe von regula¨ren Ausdru¨cken ist die Bestimmung von Named Entities mo¨glich.
Beispiel
Der Satz:
”
Max Mustermann ist Mitglied der SPD
”
wird maschinenleserlich abgespeichert in Form von:
<NAME type=person> Max Mustermann <NAME> ist Mitglied der
<NAME type=partei> SPD <NAME>
Methoden
Man kann Triggerwo¨rter erstellen, um spa¨ter die Events leichter zu identifizieren. Ermo¨glicht
wird dies mit einfachen regula¨ren Ausdru¨cken. Jedoch besteht hier der Nachteil das die Events
nicht immer erkannt werden ko¨nnen. Mehrere Sa¨tze ko¨nnen semantisch dasselbe aussagt, aber
syntaktisch ganz anders aufgebaut sein. Daher ist ein etwas aufwa¨ndigeres Konzept und die
Kombination von regula¨ren Ausdru¨cken no¨tig. Wenn man die regula¨ren Ausdru¨cken kombi-
niert, bilden diese sogenannte Muster (pattern). Wenn ein Text abgearbeitet wird, werden
die Wo¨rter klassifiziert um spa¨ter die Event-Felder zu fu¨llen. Je nachdem zu welchem Mus-
ter die Wortgruppe korrespondiert, wird es der jeweiligen Klasse zugeordnet. Die Methode,
welches das Klassifizieren der Satzbestandteile nach einem bestimmten Muster ermo¨glicht,
ist das Pattern Matching. Auch hier entstehen die Nachteile, das z.B. ein Satz bei gleichbe-
deutender Semantik, verschieden aufgebaut sein kann. Zudem kann sich auch die Information
auf mehrere Sa¨tze aufteilen. Somit sind diese einfachen Muster nicht mehr effizient und man
beno¨tigt kompliziertere Muster. Vorgegebene Sa¨tze in ihre Bestandteile (noun phrases oder
Verbgruppen) zu unterteilen und sie somit zu untersuchen ist hier von Vorteil. Nach jedem
Schritt werden fu¨r die Klassifizierung Pattern Matcher eingesetzt um die Satzbestandteile zu
identifizieren. Siehe dazu Partial Parsing.
Partial Parsing
Partial Parsing ist eine Methode zur Event Extraction, wo ein Satz Schritt fu¨r Schritt in seine
Bestandteile aufgeteilt wird. Nach jedem Schritt werden Patternmatcher fu¨r die Klassifizie-
rung eingesetzt. Dieses Verfahren erkennt Events arbeitet Satzweise. Partial Parsing kann in
folgende Schritte aufgeteilt werden:
ˆ NER
ˆ Nounphrase Recognition
142
Abbildung 1.69: Schritte des Partial Parsings
ˆ Verb group Recognition
ˆ Event Recognition
Jeder Schritt benutzt die Ausgabe aus dem vorherigem Schritt und stellt die eigene Ausgabe
dem nachfolgendem Schritt zur Verfu¨gung. Beim NER handelt es sich um das u¨bliche Ver-
fahren um Eigennamen zu erkennen und zu markieren. Nounphrase Recognition wird dazu
verwendet die Nomengruppen zu erkennen. Es werden zum Teil die Informationen aus dem
NER-Schritt benutzt. Nounphrase Recognition ist gut geeignet Schlu¨sselwo¨rter zu erkennen.
Mit Verb group Recognition wird versucht die Verb-Gruppen zu erkennen und zu normali-
sieren. Die Verben sind wichtig, da so NE’s und andere semantische Einheiten in Beziehung
gebracht werden ko¨nnen. Nach der Event Recognition hat man ein Event-Format gefu¨llt.
Das Event-Format ist ein Modell mit verschieden Typen. Ziel der Event-Extraction ist es
die Typen mit Werten zu fu¨llen und es geeignet abzulegen. Das besodere an dieser Art der
Event-Extraction ist, das z.B. nicht nur die NE’s extrahiert werden. Durch vorher definier-
te Patternmatcher ko¨nnen auch Informationen extrahiert werden, die eigentlich so nicht im
Eingabe-Text vorhanden sind. Durch die geeignete Extaktion der Informationen sind weitere
Schritte vorstellbar, wodurch man Informationen erzeugen kann die eigentlich dem Menschen
vorenthalten sind. So ko¨nnen auch hier Patternmatcher erstellt werden wodurch die neuen
Informationen erzeugt werden ko¨nnen.
Probleme
Auch wenn die Event Extraction mit dieser Heransgehensweise Events erkennt, bestehen auch
hier Probleme. Das Problem der Wiederholung von Referenzwo¨rtern ist nicht nur hier ein Pro-
blem, sondern ein allgemeines Problem in der Information Extraction. Der Grund liegt in der
Arbeitsweise der Methoden. Der Text wird einfach Satzweise bearbeitet was zum erwa¨hnten
143
Problem fu¨hrt. Es existieren aber Lo¨sungsansa¨tze in Form von Coreference Analysis. Core-
ference Analysis dient dazu, die referenzierten Wo¨rter aufzulo¨sen. In der Event-Extraction
ist dies als Vorverarbeitungsschritt denkbar. Ein weiteres Problem ist die große anzahl von
Satzstrukturen die in einem Freitext vorkommen. Um viele Events zu erkennen mu¨sste fu¨r
jeden Satztyp ein Muster geschrieben werden. Diesem Problem kann man entgegenwirken,
indem man versucht Muster zu generieren [Gri97].
Pattern-Generierung
Mit Pattern-Generierung versucht man Pattern, also Muster, zu Generieren und auf Sa¨tze
anzuwenden. Ziel ist es die beno¨tigten Muster automatisch zu generieren und auf den Einga-
betext anzuwenden. Dazu versucht man u.A. die bei einfachen Sa¨tzen gebildeten Muster auf
kompliziertere anzuwenden. A¨hnlich wie beim Partial Parsing sind auch hier folgende Schritte
no¨tig:
ˆ NER
ˆ Nounphrase Recognition
ˆ Verb group Recognition
Anschließend wird ein bestimmten Musters auf Grundlage der Bestandteile entworfen. Das er-
stellte Muster muss nochmal von Hand u¨berpru¨ft werden weil die Korrektheit nicht garantiert
ist. Dabei werden die Muster klassifiziert. Ein Muster kann demnach in folgende Kategorien
klassifiziert werden:
ˆ Akzeptieren
ˆ Verwerfen
ˆ Vereinfachen
Bei schon annotierten Texten ist auch Vereinheitlichung von Patterns mo¨glich. Dabei wird
ein durchschnitt von mehreren Patterns zu einem gebildet. Das neue Muster bildet eine Ver-
allgemeinerung zu den Quell-Mustern und kann nach U¨berprufung akzeptiert werden. Dieses
vorgehen macht dann Sinn, wenn verschieden Muster z.B. nur ein einer stelle verschieden
sind.
Fazit
Im allgemeinen kann Event Extraction dort angewandt werden, wo Informationen noch manu-
ell gefunden werden mu¨ssen. Dabei ko¨nnen es sich um Medizinische Texte handeln oder auch
Texte u¨ber Firmen und deren Ta¨tigkeiten. Die Erfolgsquote in der Event-Extraction ist leider
noch nicht so hoch wie z.B. im Bereich der reinen NER. Trotzdem ist eine Einschra¨nkung auf
eine bestimmte Doma¨ne von Informationen unerla¨sslich.
144
1.8 Theorie der Fragebeantwortung
1.8.1 Einleitung
Fragebeantwortung ist die Aufgabe des Findens einer Antwort auf eine natu¨rlichsprachlich-
gestellte Frage. Der Korpus dieser Antwort ist zumiest sehr groß, etwa das Suchen im World
Wide Web oder in riesigen Dokumentenarchiven. Besonders aufgrund der großen Pupularita¨t
des Internets, werden genau diese Systeme immer wichtiger und bekommen eine steigende
Bedeutung. Auch bei einer Suchmaschine wa¨re es wu¨nschenswert auf eine konkret gestellte
Frage, genau eine Antwort zu bekommen.
Fragebeantwortung teilt sich grob in drei Schritt auf:
1. Analyse der Frage
2. Suchen relevanter Dokumente/Text-Passagen
3. Antwort-Extraktion
Der schwierigste Teil ist in diesem Zusammenang die konkrete Analyse der gestellten Frage.
Hier mu¨ssen Antworttypen bestimmt werden und auch die Schlu¨sselwo¨rter fu¨r die Anfrage
an einen Index.
1.8.2 Fragekomplexita¨t
Jede Frage kann einer so genannten Frageklasse (nach [PH01])zugeordnet werden. Je nach
Komplexita¨t der Frage ist der Aufwand zur Beschaffung einer Antwort mehr oder weniger
hoch. Klasse 1 stellt Fragen nach bestimmten Attributen, einfache Nennung von Events oder
auch Bedingungen von Events. In diesem Fall ist die Antwort ein einfacher String. Zur Klasse
2 geho¨ren Fragen, die anhand einer Vorlage generiert werden. Die Antworten auf die gestellte
Frage befinden sich dabei in mehreren Quellen, wobei sich diese Antworten um ein gemeinsa-
mes Stichwort drehen. Stellt man die Frage
”
Wer ist Bill Gates?“ ko¨nnten Antworten lauten:
”
Ein Mann, der am 28. Oktober 1955 in Seattle geboren wurde.“,
”
Gru¨nder von Microsoft“
oder auch
”
Drittreichster Mann der Welt“. Alle drei Antworten sind richtig und werden Fra-
geklasse 2 zu einer Vorlage zusammengefasst. In Frageklasse 3 sind die Antworten noch mehr
gestreut und orientieren sich nicht mehr an einem Charakteristikum. Stattdessen kann diese
Klasse als eine Menge von Vorlagen gesehen werden, die sich um verschiedene Themen kreisen.
Diese Frageklasse ist daher am ehesten vergleichbar mit einem Dossier und Fragen ko¨nnen
hier sehr offen gestellt sein. Bei einer Frage
”
Welche Konsequenzen hat die Veruntreuung der
UNICEF-Spenden gehabt?“ wa¨ren daher viele Antworten mo¨glich, darunter z.B.
”
Ru¨cktritt
UNICEF-Chef“ oder
”
Spendenru¨ckga¨nge“.
Frageklassen dienen also der groben Einteilung der Schwierigkeit einer Frage.
1.8.3 Antworttypen-Modell
Einer der wichtigsten Aufgaben bei der Fragebeantwortung ist die Bestimmung des richti-
gen Antworttyps. In der Regel basiert der Antworttyp auf einer syntaktischen Analyse der
Frage. Zuna¨chst wird dabei der Satzbau analysiert und eventuell vorhandene Stoppwo¨rter
entfernt. Anschließen bestimmt man den Antworttyp anhand des Questions Stems und den
Konzepten der Frage. Alle Kombinationen mit den jeweiligen Antworttypen sind dabei vorde-
finiert in einer Tabelle gegeben. Die nachfolgende Abbildung zeigt ein Beispiel. Nachfolgend
145
Abbildung 1.70: Beispiel fu¨r die Zuordnung der Antworttypen
wollen wir ein Antworttypenmodell vorstellen, das Frageklassen, Antworttypen und Formate
beru¨cksichtigt. Das Antworttypenmodell ist ein 4-Tupel mit folgenden Attributen:
AT = [Kategorie, Abha¨ngigkeit, Nummer, Format]
An erster Stelle unseres Tupel-Modells beschreibt Kategorie die Art der Antwort, die sich
wiederum nach den, im vorherigen Abschnitt beschriebenen, Frageklassen richtet. Hier ist
entweder ein vordefinierter Antworttyp, eine Definition, eine Vorlage oder eine Zusammenfas-
sung mo¨glich. An zweiter Stelle beschreibt Abha¨ngigkeit das Verha¨ltnis zwischen der Katego-
rie und den Antworttypen. Fragen wir also
”
Wann wurde Kennedy erschossen?“, beschreibt
die Abha¨ngigkeit, dass wir als Antworttyp ein Datum erwarten. Nummer steht an dritter
Stelle unseres Tupels und ist ein einfacher Boolean-Wert (Flag), der angibt, ob ein einzelner
Wert oder eine Liste von Elementen gesucht ist. Schließlich definiert Format ein spezielles
Ausgabeformat, bspw. wa¨re dies fu¨r ein Datum
”
dd.mm.yy“.
Kommen wir nun zu den einzelnen Kategorie-Typen:
Antworttyp Antworttypen werden, wie bereits beschrieben, aus Question Stem und Konzep-
ten der Frage gewonnen. Beide bestimmen zusammen den Antworttyp, der zumeist in
einer Tabelle vordefiniert ist. Oft handelt es sich bei den Antworttypen um Named En-
tities, die so auch direkt in den Texten vorkommen. Hier ist allerdings zu beachten, dass
bei der Abbildung Antworttyp zu Named Entity eine 1 zu n bzw. n zu 1-Beziehung be-
stehen kann. So ist es mo¨glich, dass man dem Antworttyp
”
Person“ die Named Entities
”
Person“ und
”
Name“ zuweist, andererseits kann man aus den Typen
”
Geschwindig-
keit“,
”
Dauer“ und
”
Menge“ den Named Entity
”
Quantita¨t“ abbilden.
Definitionen Antworten zu Definitionen ergeben sich direkt aus der Fragestellung. Auf eine
Frage
”
Was ist/war [ObjektName]?“ kann man eine Antwort
”
[ObjektName] ist/war
[Antwort]“ automatisch generieren.
Vorlage Besteht eine Antwort aus verschiedenen Antworttypen, so ergibt sich daraus auto-
matisch der Typ Vorlage. In diesem Fall muss eine Vorlage generiert werden, die aus
einer Menge von Antworttypen (Slots) besteht. Dies passiert in drei Schritten:
1. Fu¨r eine Frage wird zuna¨chst nach mo¨glichen Antworten gesucht. Fu¨r jede Antwort
wird ein Frageabha¨ngigkeitsgraph erstellt und darin nach gemeinsamen Merkmalen
gesucht.
146
Abbildung 1.71: Ablauf der Fragebeantwortung mit verschiedenen Feedback-Loops
2. Die ha¨ufigsten Merkmale, die in den Antworttypen genannt werden, werden iden-
tifiziert.
3. Gemeinsame Merkmale werden in der Vorlage gesammelt und diese als Namen fu¨r
Slots genutzt.
Zusammenfassung Zusammenfassungen enthalten verschiedene Vorlagen, die nicht aus ge-
meinsamen Merkmalen bestehen. Daher ko¨nnen diese nicht weiter zusammengefasst
werden und eine Sammlung von verschiedenen Vorlagen wird als Antwort ausgegeben.
1.8.4 Ablauf der Fragebeantwortung
Abschließend wollen wir ein Beispiel fu¨r ein komplexes Q/A-System geben. Die Besonder-
heit dieses Systems sind die so genannten Feedback-Loops, die die Ergebnisse verfeinern und
spezialisieren ko¨nnen.
Eine Anfrage besteht zuna¨chst aus einem Antworttyp und einer Menge von Schlu¨sselwo¨rtern.
Diese werden durch Frageabha¨ngigkeiten zusammengefu¨hrt und als Query an einen Index
geschickt. Dieser liefert eine Menge von Dokumenten, die auf die Schlu¨sselwo¨rter und den
Antworttypen passen. Aus diesen Dokumenten werden relevante Text-Passagen extrahiert.
Hier kommt nun der erste Feedback-Loop ins Spiel. Werden zuviele Ergebnisse zuru¨ckgeliefert,
muss die Menge der Schlu¨sselwo¨rter spezialisiert werden, so dass es bei einer erneuten Anfrage
weniger Treffer gibt. Andersherum werden bei zu wenigen Treffern neue Schlu¨sselwo¨rter hin-
zugenommen. Dieses Verfahren endet, wenn keine Schlu¨sselwo¨rter hinzugefu¨gt oder gelo¨scht
werden ko¨nnen.
Bei der Pru¨fung der Antwortabha¨ngigkeiten ko¨nnen sich im na¨chsten Schritt neue lexikalische
Alternativen ergeben. Synonyme oder morphologische Varianten ko¨nnten daraufhin zu den
147
Schlu¨sselwo¨rtern hinzugefu¨gt werden. Sobald die Antwort- und Frageabha¨ngigkeit semantisch
gleich ist, kann das Ergebnis in einem letzten Schritt gepru¨ft werden (
”
Abductive Judtificati-
on“). Dies geschieht durch eventuell vorhandene Wissensbasen. Falls in diesem Schritt Ober-
begriffe oder Paraphrasen gefunden werden, ko¨nnte auch hier wiederum ein Feedback-Loop
erfolgen. Dies wird durch die dritte Ru¨ckwa¨rtskante
”
Semantic Alternations“ ausgedru¨ckt.
Fu¨r die Ausgabe der Antwort kann nun eine Antwortfusion erfolgen. Die daraus resultierende
Antwort wird letztlich ausgegeben.
1.9 TREC
1.9.1 Was ist TREC?
TREC ausformuliert ist die Text Retrieval Conference, dies ist ein Workshop des National
Institute of Standards and Technology (NIST genannt). Die Konferenz wird seit 1999 ab-
gehalten, mit dem Ziel Techniken zur Fragebeantwortung zu entwickeln. Seitdem wurde die
Komplexita¨t der Fragen und die Anzahl der Fragetypen sta¨ndig erho¨ht.
Zu Beginn dieses Workshops wurden nur Fakten-Fragen (Factoid questions), seit 2003 aber
auch Listen- und Weitere-Fragen beantwortet. Zu diesen Fragetypen kamen 2006 die komple-
xen, interaktiven Fragen hinzu (complex, interactive QA auch ciQA genannt). Der Hauptun-
terschied zu den anderen Fragetypen ist hier, dass eine Interaktion mit dem Nutzer existiert.
Die Quelldokumente die verwendet wurden waren bis 2006 ausschließlich Zeitungsartikel. Ab
2007 kamen zu diesen auch Blogs wie z.B. Tagebu¨cher, Journale im Web hinzu.
1.9.2 Durchfu¨hrung
Das Ziel der TREC-Durchfu¨hrung ist es fu¨r eine bestimmte Interessentengruppe eine Liste von
Fragen zu beantworten. Es werden dabei die Fragen in Serien, die zu einem bestimmten Thema
mit unterschiedlichen Fragetypen zusammengefasst. Mo¨gliche Themen fu¨r Frageserien sind
z.B. Person, Organisation, Objekt oder ein Event. Fu¨r die Auswertung der Systemantworten
sind die Mitglieder der NIST verantwortlich. Danach haben die Teilnehmer 2 Wochen Zeit
um automatisch generierte Antworten zu erstellen. Aber es muss die Reihenfolge der Fragen
so abgearbeitet werden wie sie vorher vorgegeben war. Als Hilfe du¨rfen innerhalb einer Serie
vorherige Fragen/Antworten genutzt werden aber nachfolgende nicht.
Beispiel: Frageserie Es muss innerhalb einer Serie beachtet werden, dass es mehrere Fakten-
Fragen, eine oder zwei Listen-Fragen und genau eine Weitere-Frage erlaubt ist.
1.9.3 Welche Fragetypen gibt es?
Die Fragen werden in 3 Fragetypen unterteilt.
Fakten-Fragen Fakten-Fragen, bei denen die Antwort ein 2-Tupel [dok-id, Antwort-String]
oder Nil (es konnte keine passende Antwort gefunden werden). Die Pru¨fung der Ant-
worten erfolgt durch eine Jury mit den Bewertungen:
- incorrect: Die gelieferte Antwort ist Falsch.
- not suported: Die Antwort ist korrekt, wird aber vom Dokument nicht unterstu¨tzt.
- not exact: Die Antwort ist korrekt, wird auch vom Dokument unterstu¨tzt aber es exis-
tieren unterschiedliche Antworten auf die Anfrage.
148
Abbildung 1.72: Beispiel fu¨r Frageserie
- locally correct: Die Antwort ist korrekt, wird auch vom Dokument unterstu¨tzt aber
der Pru¨fer findet eine bessere Antwort innerhalb des Dokumentes.
- globally correct: : Die Antwort ist korrekt, wird auch vom Dokument unterstu¨tzt und
es gibt keine bessere Antwort.
Listen-Fragen Bei Listen-Fragen ist die korrekte Antwort eine unsortierte Liste mit unter-
schiedlichen Antworten. Die Bewertung der einzelnen Antworten ist identisch zu den
Fakten-Fragen. Wobei die global korrekten Antworten in A¨quivalenzklassen zusammen-
gefasst werden. Mit Hilfe von F-Score werden die Listen-Antworten bewertet. Wie be-
kannt setzt sich F-Score aus Recall und Precision zusammen.
Weitere-Fragen Weitere-Fragen, sind ein ungeordnetes Set aus [dok-id, Antwort-String]. Der
Antwort-String muss hier relevante Stichworte (Nuggets) enthalten. Diese werden vor
der Anfrage durch den Pru¨fer ausgewa¨hlt und festgelegt. Die Bewertung des Fragetyps
wird dadurch relativ erschwert. Die Bewertung la¨uft folgendermaßen ab:
a) Die Pru¨fer wa¨hlen eine Liste von
”
Vital“ und
”
Non-Vital“-Nuggets aus. ( Vital
bedeutet, dass das Stichwort gut ist. Non-Vital , dass diese akzeptabel ist.)
b) Pru¨fer gehen die Ausgabe durch und markieren Nuggets(doppelte za¨hlen nur ein-
mal). Das Bewertungsmaß ist also: 0,1, nuggets
c) F-Score bestehend aus Recall(wie bisher) und einem vera¨nderten Precison-Wert -
la¨ngenbasierter Precision-Wert
149
Abbildung 1.73: Vergleich Einzelperformance vs. Nugget Pyramid-Performance
- 100 Zeichen sind pro Vital/Non Vital Nugget erlaubt
- Falls kompletter Antwortstring unter 100 Zeichen ausgibt: - Precision = 1.0, sonst
wird die Gleichung 1− Laenge−BegrenzungLaenge < 1 angewendet.
1.9.4 Nugget-Pyramide
Das bisherige Scoring wird hier erweitert, aber es gibt ein Problem und zwar haben nur Vital
Nuggets Einfluss auf den Recall-Wert. Bei den Antworten gibt es aber nur sehr wenige Vital
Nuggets. Um dieses Problem zu lo¨sen, entscheiden jetzt mehrere Pru¨fer ob ein Stichwort Vital
oder
”
nur“ okay (non-Vital) ist.
Wir sehen in Abbildung 1.73, dass dort wo vorher bei einem Pru¨fer keine Antwort in der Liste
gefunden wurde, nun aber mit Hilfe der Nugget-Pyramide mit einer 60%igen Wahrscheinlich-
keit eine Antwort gefunden wird.
1.9.5 ciQA-Durchfu¨hrung
Die Ziele dieser Durchfu¨hrung sind zum einen, eine Ausgabe von komplexeren Antworten bzgl.
einer Nutzer-Anfrage zu bekommen, wobei es sich nicht um eine Fakten Frage handeln soll
und zum anderen sollen keine einfachen in einem Schritt erhaltenen Antworten ausgegeben
werden, sondern Antworten die nach einem interaktiven Dialog mit dem Nutzer liefern. Das
Konzept der mo¨glichen Fragen innerhalb dieser Durchfu¨hrung beschreibt, dass eine Entita¨t
in Beziehung zu einer anderen gesetzt werden soll. Die dabei entstehende Beziehungs-Frage
setzt sich aus 2 Teilen zusammen:
1. Der Vorlage (Template) mit fixer Struktur und freien Slots
2. Einem Bericht mit der Intention der Frage
Die Bewertung dieser Fragen ist dieselbe wie bei den
”
Weiteren-Fragen“, aber mit einem
ho¨heren (Zeichen-) Grenzwert.
150
Abbildung 1.74: TREC2006 liefert uns 5 Vorlagen mit der gearbeitet werden kann
1.9.6 Interaktion mit Nutzer
Damit die Interaktion mit dem Nutzer ablaufen kann, muss ein Framework entwickelt, dass
die Interaktion mit dem QA-System erlaubt. Bis 2007 konnten auch lokale Applikation wie
Java verwendet werden, jetzt aber ist die Interaktion webbasiert. Die Nutzung des Systems
soll fu¨r jedes Thema nicht mehr als 5 Minuten in Anspruch nehmen.
Beispielhafter Ablauf des Experimentes - Jeder Teilnehmer u¨bermittelt 2 Initialla¨ufe und
die URL’s an das NIST.
- Die Pru¨fer haben nun 3 Tage Zeit um mit jedem System zu interagieren. Die Daten
stehen den Teilnehmern sofort zur Verfu¨gung.
- Die Teilnehmer haben danach 2 Wochen Zeit um die Endresultate zu bestimmen
1.9.7 Ergebnisse
Um die Ergebnisse der ciQA2007 mit 7 Teilnehmern und 12 La¨ufen auszuwerten werden die
Baseline und die Endresultate der Teilnehmer betrachtet. Baseline ist dabei die Anfrage an
Lucene, welche mir die Top20 Antworten liefert. Diese Antworten werden erst dann Ausge-
wertet wenn keine Stoppwo¨rter mehr enthalten sind, es wird also wird eine Tokenisierung
und eine Entfernung der Stoppwo¨rter durchgefu¨hrt. Wir sehen, dass die Baseline in manchen
fa¨llen sogar besser ist, als die Endresultate der Teilnehmer. Daraus la¨sst sich schließen das
manuelle Abla¨ufe besser sind als komplett automatisch generierte.
151
Abbildung 1.75: Ergebnisse TREC 2007 QA-Track
1.10 Dictionaries
1.10.1 Einleitung
Was sind Dictionaries
In dem Umgang mit Information kann es vorkommen, dass einige Information sich im Laufe
der Zeit nicht a¨ndert, also konstant bleibt. Solche Informationen nennen wir sichere Informa-
tionen. Als Beispiel ko¨nnen wir das Datum des Eintretens Angela Merkels in die Rolle der
Bundeskanzlerin anfu¨hren. 22.11.2005 ist dann die sichere Information. Unseres Ziel ist, diese
geeignet zu speichern und auch den bestmo¨glichen Zugriff zu gewa¨hrleisten. Dazu benutzen
wir Dictionaries. Dictionaries sind Listen fu¨r die Speicherung von solchen sicheren Informati-
on. Beispielsweise wa¨re eine Liste von Namen von Abgeordneten ein Dictionary. Ein bisschen
komplizierter wird es, wenn man ganze Sa¨tze in Dictionaries speichern will. Wenn man auf
die Idee kommt, die wie eben zu speichern, also sprich eine große Liste von Sa¨tzen, dann
muss man damit rechnen, dass eine Anfrage an die Dictionaries nicht so schnell la¨uft, sogar
sehr langsam. Eine bessere Idee wa¨re, einen Satz zu zerteilen und Verben und Adjektive als
Relationen bzw. Events gelten zu lassen. Schauen wir uns am besten das folgende Beispiel
genau an: Sichere Informationen: Merkel ist Bundeskanzlerin. Teilen wird in zwei Teile
ˆ Merkel
ˆ Bundeskanzlerin
Die Relation zwischen Merkel und Bundeskanzlerin : ist Also, man hat hier zwei Listen. Eine
Liste mit Namen und eine mit A¨mter. Was natu¨rlich fehlt ist die Verbindung dazwischen.
Wie oben beschrieben, definieren wir eine Funktion zwischen den Listen.
Dictionaries fu¨r unsere PG
Fu¨r unsere Zwecke in der PG brauchen wir folgende Dictionaries:
152
ˆ Datum
ˆ Drucksache
ˆ Name
ˆ Person
ˆ Partei
ˆ Reaktion
ˆ Ort
ˆ Ergebnis (Abstimmung)
ˆ Amt/Rolle
Diese 10 Listen sind NERs, auf die wir uns geeignet haben. Dazu kommen noch:
ˆ Wahlperiode
ˆ Gehalt
ˆ Religion
ˆ Anzahl Kinder
ˆ Sternzeichen
ˆ usw.
Bei den komplizierten Sa¨tzen funktioniert das Speicher genau so. Z.B.:
”
Gerhard Schro¨der
kommt aus Berlin und hat gegen Angela Merkel bei der Bundeskanzlerwahl gestimmt, obwohl
er mit ihr befreundet ist“. Wir haben hier zwei Listen und drei Relation.
Listen:
ˆ Name
ˆ Ort
Relationen:
ˆ befreundet
ˆ stimmt gegen
ˆ kommt aus
153
Abbildung 1.76: Automat mit Transition Jamming
Methoden zum Halten von Dictionaries
Jetzt werden wir uns damit bescha¨ftigen, das Dictionary zu speichern und einen Eintrag
hinzuzufu¨gen. Stellen wir uns das an dem Beispiel
”
Schro¨der kommt aus Berlin“ da. Also man
mo¨chte den oben genannten Satz in das Dictionary einfu¨gen. Dafu¨r nehmen wir zwei Listen,
die erste mit Namen und die zweite mit Orten. In der Liste Name und Ort wird entsprechend
Schro¨der bzw. Berlin hinzugefu¨gt und der entsprechender Index i und j markiert. Dann wird
der Hashwert h von dem Namen unter Beru¨cksichtigung der Relationen berechnet. Dann wird
an der h-ten Stelle in der Zwischentabelle der Index von Berlin, also j gespeichert. Es ist leicht
nachzuvollziehen, dass die Suche im Dictionary analog la¨uft. Also das Aussuchen von
”
Woher
kommt Herr Schro¨der?“ wird wie folgt berechnet. Der Hashwert h von Schro¨der wird unter
Beru¨cksichtigung der Relation berechnet. In der h-ten Stelle in der Zwischentabelle wird der
j-Wert ausgelesen, welcher an den Index von Berlin werweist. Dies ist die erste Mo¨glichkeit,
also mit Hashtabellen zu arbeiten. Eine andere Mo¨glichkeit ist, die Wo¨rter in der Hashtabelle
nicht als eine Liste von Wo¨rtern zu speichern, sondern durch einen Automaten zu realisieren.
Diese Darstellung hilft uns die gleichen Buchstaben nicht doppelt zu speichern.
Rot gekennzeichnet sind die Buchstaben, die in Wo¨rtern start und art vorkommen, deswegen
brauchen wir die nicht doppelt speichern. Die Automaten helfen uns den Speicherplatz zu
verringern und der Automat kann gleichzeitig eine Hashfunktion realisieren. Wir ko¨nnen den
Automaten noch optimieren, so dass wir mit weniger Zusta¨nden auskommen, in dem wir im
Bild noch alle die Zusta¨nde lo¨schen, die genau eine ein- und ausgehende Kante haben, weil
die Zusta¨nde keine Information beinhalten. Dieses Verfahren nennt sich Transition Jamming.
Das Bild zeigt die gesamte Struktur noch mal an.
Beispiele
Fu¨r umfangreiche Dictionaries gibt es in der Praxis bereits diversa Beispiele. Eine sehr be-
kannte Klasse der Dictionaries bilden die sogenannten
”
Gazetteers“. Dabei handelt es sich
um Datenbanken, in denen Informationen zu geografischen Koordinaten gespeichert werden.
Diese Daten reichen von Ausdehnung, u¨ber Name des Ortes auf der Erde, bis zu spezifischen
154
Abbildung 1.77: Gesamte Struktur
Attributen wie Bevo¨lkerungszahl. Der bekannteste Gazetteer ist der ADL (Alexandria Digi-
tal Library), der auch u¨ber ein o¨ffentlich zuga¨ngliches WebService Interface verfu¨gt. Weitere
nennenswerte Vertreter sind z.B. die
”
Metacarta GazDB“, in der Daten mehrerer Gazetteers
kumuliert und in einem relationalen Datenbankschema abgelegt werden, mit spezieller Opti-
mierung auf schnelle Aktualisierbarkeit und Durchsuchbarkeit.
Eine weitere Klasse von Dictionary a¨hnlichen Strukturen bilden die Nom- bzw. Propbanks,
die an einer anderen Stelle dieses Dokuments behandelt werden.
Quellen fu¨r Dictionaries
Zum initialen Befu¨llen von Dictionaries mu¨ssen geeignete Datenquellen gefunden werden.
Diese Datenquellen sollten einen mo¨glichst breiten und verla¨sslichen Datenbestand bieten.
In vielen Arbeiten hat sich die freie Enzyklopa¨die
”
Wikipedia“ als geeignet erwiesen, da
dort bereits viele Dictionary spezifische Strukturen realisiert sind. Zum einen ist Wikipedia
geeignet, um Mehrdeutigkeiten aufzulo¨sen, also erlaubt bei Suchanfragen die Entscheidung
welches, der potentiell vielen Suchergebnisse gemeint war. Zum anderen bietet Wikipedia eine
Reihe von Daten bereits vorstukturiert an. Wie zum Beispiel alle Eckdaten einer Person oder
eines Ortes.
Denkbar sind natu¨rlich auch andere Quellen, jedoch ist eine gewisse Vorstukturierung sehr
vorteilhaft.
Einsatzgebiete
In der NER ko¨nnen Dictionaries in verschiedenen Kontexten eingesetzt werden. Die bekann-
testen Beispiele sind Wortfilter, wie Stop-Word Listen, oder Listen von Abku¨rzungen. Auch
vorgefertigte Listen von Nomen sind denkbar, zum Beispiel um Mehrdeutigkeiten von groß
155
Abbildung 1.78: Auflo¨sung von Mehrdeutigkeiten
geschriebenen Worten am Satzanfang aufzulo¨sen. Generell lassen sich drei Klassen von Dic-
tionaries bilden:
ˆ Allgemeine Wortlisten (z.B. Stop-Words)
ˆ Spezifische Wortlisten (z.B. bereits bekannte Entities)
ˆ Trigger Wortlisten (z.B. GmbH, AG als Trigger fu¨r Firmen)
Dictionaries dieser Typen lassen sich auch innerhalb eines NER Vorgangs kombinieren und
sogar kaskadieren, um die Qualita¨t der gewonnenen Daten zu verbessern. Meist werden dabei
die Allgemeinen Wortlisten in fru¨hen Schritten, oder sogar im Preprocessing der Daten ange-
wandt. In folgenden Schritten werden dann sichere Treffer erkannt. Zuletzt werden mit Hilfe
von Triggern neue Entities entdeckt. Auch eine logische Verknu¨pfung mehrerer Dictionaries
ist denkbar. So ko¨nnte man Beispielsweise ein Wort, das in der Liste von Personennamen ent-
halten ist, aber nicht in der Liste ha¨ufiger Nomen und weiterhin von einem
”
Herr“ eingeleitet
wird, sehr sicher als einen Eigennamen identifizieren. Bei logischer Negation in einer solchen
Verknu¨pfung spricht man auch von einem
”
Anti-Dictionary“.
Hier eine beispielhafte Aufstellung der verschiedenen Typen:
Optimierung
Es gibt diverse Techniken, um den Einsatz von Dictionaries zu optimieren. Da es sich bei
Dictionaries um Wortlisten mit fester Schreibweise handelt, ist ein Lookup meist nur bei
Einhaltung der exakt gleichen Schreibweise erfolgreich. Um diesen Effekt zu minimieren gibt
156
Abbildung 1.79: Personendaten
157
Abbildung 1.80: Typen von Dictionaries
Abbildung 1.81: Reverse Stemming
es Techniken wie
”
stemming“, wobei die Eingabedaten in eine normalisierte Schreibweise
u¨berfu¨hrt werden, aber auch Techniken, die man als
”
reverse-stemming“ bezeichnen ko¨nnte.
Dabei werden z.B. alle Schreibweisen eines Namens gebildet, um weitere Vorkommen desselben
Namens im Text finden zu ko¨nnen. Ein Beispiel hierfu¨r sieht folgendermaßen aus:
Eine weitere Mo¨glichkeit ist ein Lookup u¨ber ein A¨hnlichkeitsmaß, satt u¨ber einen direk-
ten String-Vergleich. Dabei wird fu¨r ein Eingabewort die A¨hnlichkeit mit jedem Wort im
Dictionary gebildet. Wird dabei ein bistimmter Schwellenwert der A¨hnlichkeit erreicht, wird
angenommen, dass dieses Wort in die Wortklasse des Dictionaries einzuordnen ist. Diese Me-
thode hat leider einen sehr hoher Rechenaufwand zur Folge und erho¨ht das
”
noise“ in den
Daten, also die Anzahl der Falschtreffer.
158
Fazit
Dictionaries ko¨nnen an vielen Stellen der NER eingesetzt werden und ko¨nnen dazu beitragen
das Ergebnis der NER deutlich zu verbessern. So sind Vorteile in der Geschwindigkeit, so wie in
der Verla¨sslichkeit der Treffer mo¨glich. Allerdings stehen dieser Verbesserung auch Nachteile
wie hoher Speicherbedarf und die Abha¨ngigkeit von externen Datenquellen gegenu¨ber. So
muss dafu¨r gesorgt werden, dass die Daten verla¨sslich sind und stets aktuell bleiben. Es
bleibt also abzuwa¨gen ob und in welchem Umfang der Einsatz von Dictionaries Sinn macht.
1.11 Frageformen
1.11.1 Erga¨nzungsfrage
Wird gestellt, um Auskunft u¨ber Personen, Sachen oder die Umsta¨nde eines Geschehens oder
Zustandes zu erhalten um dadurch eine Wissenslu¨cke zu schließen. Dabei kann es sich um
Umsta¨nde wie Ort, Zeit, Ursache, Art und Weise oder Zweck handeln.
Merkmale sind Fragewo¨rter am Satzanfang:
Beispiele:
ˆ Wer, welcher, welche, welches? (Fragen nach dem Subjekt)
ˆ Wen? (Fragen nach dem direkten Objekt)
ˆ Wem? (Fragen nach dem indirekten Objekt)
ˆ Wessen? (Fragen nach dem Attribut oder einem indirekten Objekt)
ˆ Wo, wohin, woher? (Fragen nach dem Ort oder der Richtung)
ˆ Wann, wie lange, wie oft? (Fragen nach der Zeit)
ˆ Wie? (Fragen nach der Art und Weise)
ˆ Weshalb, warum, weswegen, wieso? (Fragen nach der Ursache)
Beispiele fu¨r Frageaufbau:
159
Fragewort erwartete Antwort Beispiel Frage
wann am[Datum] Wann war das letzte Misstrauensvotum?
wie [String] Wie ist die Reaktion von..?
Wie oft sind Zwischenrufe bei Reden von ..?
wer am[Datum],[String] Wer ist der Parteivorsitzender der ..?
welche [String] Welche Parteien sind im Bundestag?
welcher [String] Welcher Partei geho¨rt .. an?
wird [String] ...
wo [String] Wo wird die Bundeswehr zurzeit eingesetzt?
wieso [String] [Event Extraction]
Wieso ist Deutschland gegen den EU-Beitritt der Tu¨rkei?
warum [String] [Event Extraction]
Warum ist die BRD gegen Tu¨rkei Beitritt?
weshalb [String] [Event Extraction]
Weshalb...?
Diesen Typ von Fragen behandeln wir in unserer PG. Die Fragetypen die hier aufgezeigt wer-
den, sind zum einen
”
Stichwort-Fragen“ und zum anderen
”
Ereigniss-Fragen“, wobei letzteres
noch nicht behandelt wurde.
1.11.2 Entscheidungsfragen
Sind Fragen, die nur mit ja oder nein beantwortet werden ko¨nnen.
Merkmal: Beno¨tigt keine Fragewo¨rter aber beginnen mit der finiten (gebeugten) Verbform.
Beispiele:
ˆ hat, hast, haben
ˆ kommt, kann, ko¨nnen
ˆ sind, ist
ˆ gibt, besitz
ˆ werden, wurden, wurde
→ erweiterbar
Beispiele fu¨r Frageaufbau:
Fragewort erwartete Antwort Beispiel Frage
hat [String] Hat der Abgeordnete .. Kinder?
ist [String] Ist der Abgeordnete .. verheiratet?
sind [String] Sind...
gibt [String] Gibt es Abgeordnete mit mehr als 3 Kindern?
wurden [String] Wurden die Dia¨ten in der 16 Wperiode erho¨ht?
werden [String] Werden Antra¨ge von ..abgelehnt?
wurde [String] Wurde ein Misstrauensvotum in der 14.Wahlperiode gestellt?
besitzt [String] Besitzt der Abgeordnete .. einen Nebenjob?
Hier liefern wir die Antwort und dazu kommt eventuell eine Liste mit Namen oder nur ein
Integerwert.
160
1.11.3 Direkte Fragen
Enden im Deutschen immer mit dem Fragezeichen ?
”
Im Grunde ist dies eine Frage, welche
sich mit der Hilfe der ersten beiden Frageformen beantworten la¨sst“.
Beispiele: siehe den ersten beiden Frageformen
1.11.4 Indirekte Frage
Sind Fragen die auch indirekt gestellt werden ko¨nnen, ohne die grammatische Form einer
Frage zu haben.
Beispiele: siehe den ersten beiden Frageformen aber hier kann vor der Frage etwas anderes
stehen wie z.B. Ich will wissen, wann....
1.11.5 Offene Fragen
Der Fragesteller verknu¨pft seine Frage mit weitergehenden
”
Erkundungsabsichten“ und will
damit bewirken, dass der Befragte ausfu¨hrlich antwortet.
Merkmal: Beginnen gewo¨hnlich mit einem Fragewort. Also alle W-Fragen ( was, wer, wie,
usw.)
Beispiele fu¨r Frageaufbau:
Fragewort erwartete Antwort Beispiel Frage
was am[Datum],[String] Was hat Schro¨der im Bundestag am...gesagt?
→ weitere Beispiele siehe Erga¨nzungsfrage
1.11.6 geschlossenen Fragen
Merkmal: Diese Fragen haben ihre Bedeutung in Situationen, wo es auf pra¨zise und eindeutige
Antworten ankommt, beginnen gewo¨hnlich mit einem Verb.
Sehen wir wie offene Fragen und es wird eine Liste mit Antworten zuru¨ckgegeben.
1.11.7 weitere Fragen
Dann gibt es noch Fragen die als Antwort eine Liste von z.B. Namen zuru¨ckgeben.
Beispiele fu¨r Frageaufbau:
Fragewort erwartete Antwort Beispiel Frage
gib [String] gib alle Abeordneten mit Kindern aus!
liefere [String] suche alle weiblichen Abgeordneten der ...
in welchen [String] in welchen La¨ndern sind deutsche Soldaten Stationiert?
→ beliebig erweiterbar!
Fu¨r unsere PG haben wir uns entschlossen die Fragemo¨glichkeiten des Nutzer soweit es geht
einzuschra¨nken, da der Nutzer zu viele Fragestellungsmo¨glichkeiten hat. Zudem wird die Ana-
lyse und Auswertung unno¨tig erschwert, deshalb wir uns fu¨r einen anderen
161
Abbildung 1.82: Startseite des Deutschen Bundestages.
1.11.8 statistischen-Fragen
Merkmal:
Wir erwarten hier als Ru¨ckgabe z.B. eine Prozentzahl, Anzahl, ein Wert usw.
Fragewort erwartete Antwort Beispiel Frage
wieviele [Integer] Wieviele Antra¨ge werden durchschnittlich abgelehnt?
wieviel [Integer] Wieviel Antra¨ge werden durchschnittlich abgelehnt?
→ erweiterbar!
1.12 Anwendungsbereich
1.12.1 Aufbau und Themen
Der Deutsche Bundestag
Der Deutsche Bundestag ist das oberste demokratische Staatsorgan in Deutschland. Es ist
das Zentrum des politischen Lebens. Der Arbeitsalltag des Deutschen Bundestages umfasst
die o¨ffentlich gefu¨hrten, politischen Debatten, die Arbeit an Gesetzentwu¨rfen, Antra¨gen und
Anfragen. Sowie die Beratungen der Fachpolitiker in den Ausschu¨ssen und politische Arbeit
in den Fraktionen.
Der Deutsche Bundestag als Organ der Legislative ha¨lt folgende Aufgaben und Funktionen
inne:
ˆ Gesetzgebung
ˆ Bundeshaushalt
162
ˆ Kontrolle der Regierung
ˆ Wahl des Bundeskanzlers
ˆ Rechtliche Grundlagen
Die Webseiten des Deutschen Bundestages ko¨nnen u¨ber das Portal unter der URL:
www.bundestag.de erreicht werden. Die Verantwortung fu¨r das Internet Angebot tra¨gt das
Referat Online-Dienste und Parlamentsfernsehen (Referat PuK4). Die HTML Webseiten wer-
den mit dem Content-Management-System: Infopark CMS Fiona generiert. Das Portal wird
im Serverpark der Babiel GmbH betrieben.
Das Portal stellt neben Texten und Bildern aus dem Betrieb des Dt. Bundestages auch Do-
kumente und Audio/Video Streams zur Verfu¨gung.
Sitemap
Das Portal des Deutschen Bundestages weist folgende Struktur auf.
ˆ Startseite: Willkommensseite des Portals, die sowohl die Navigation, einen Veranstal-
tungskalender und die aktuellen Newsbeitra¨ge darstellt.
ˆ Sitemap: Gesamtstruktur des Webangebots.
ˆ Architektur und Kunst: Einen Abschnitt, der sich mit Bauwerken, Ku¨nstlern und Kunst-
werken rund um den Dt. Bundestag und das Parlamentsviertel bescha¨ftigt.
ˆ Aktuell: Pressemitteilungen, Meldungen, Newsletter, RSS
ˆ Parlament: U¨berblick u¨ber Funktion und Aufgaben, sowie Informationen u¨ber das Pra¨-
sidium, Gremien, Fraktionen und Wahlen.
ˆ Abgeordnete: Eine Fu¨lle aus Informationen, Zahlen und Listen u¨ber die Abgeordneten
des Bundestages seit der 13. Wahlperiode.
ˆ Ausschu¨sse: Liste und Funktion der jeweiligen Ausschu¨sse.
ˆ Wehrbeauftragter: Aufgaben, Funktion und Befugnisse des Wehrbeauftragten.
ˆ Dokumente: Die unvollsta¨ndige Informationsdatenbank zu Drucksachen, Protokollen,
Analysen und Gutachten des Bundestages. In diesem Abschnitt ko¨nnen zusa¨tzlich Do-
kumente zum Stand der Gesetzgebung, Informationen u¨ber die Parteienfinanzierung,
sowie das Datenhandbuch des Dt. Bundestages eingeholt werden. Das Datenhandbuch
ist ein Sammelsurium statistischer Daten u¨ber den Bundestag, allerdings nur bis zur
letzten Wahlperiode.
ˆ Wissen: Dieser Abschnitt bietet eine große Anzahl an begleitenden Informationen die
zum besseren Verstehen der Vorga¨nge unabdingbar sind. Neben weiterfu¨hrenden Links,
Symbolen des Staates und der Bibliothek, befinden sich hier Wissenschaftliche Dienste,
ein Abku¨rzungsverzeichnis und ein alphabetisch sortiertes Glossar.
163
ˆ Live: Multimediales Archiv der Fernsehaufzeichnungen und gleichzeitig das Parlaments-
fernsehen Web-TV
ˆ Europa und Internationales: Informationen rund um die Rolle Deutschlands in Europa
und das Europa¨ische Parlament.
ˆ Service: Kontaktmo¨glichkeiten, Formulare, Antra¨ge und Stellenangebote des Dt. Bun-
destages. Hier befinden sich auch einige Dienste, z.B. die Volltextsuche, die nur auf das
Internetangebot des Bundestages beschra¨nkt sind.
ˆ Publikationen, Jugend, Ausstellungen, Parlamentspreise
ˆ Geschichte: Chronik des Parlaments und ein Abriss u¨ber Dt. Parlamentarismus.
ˆ Blickpunkt Bundestag: U¨berblick u¨ber die aktuellen Themen des Bundestages sowie ein
Ru¨ckblick auf die Jahre 1998 - 2004.
1.12.2 IR relevante Dienste
Das Portal des Dt. Bundestages stellt einige Dienste zur Verfu¨gung, welche fu¨r die Lo¨sung
unserer Aufgabe im Bereich Information Retrieval interessant sind. Aus den bereitgestellten
Diensten sollen Daten gewonnen werden und in Datenbanken gespeichert werden. Die Daten
sollen von dem System zur Erstellung des Dossiers verarbeitet werden. Da es sich bei dem Por-
tal des Deutschen Bundestages um ein HTTP Internet Server handelt, werden grundsa¨tzlich
nur zwei Methoden beno¨tigt um Dienste anzusprechen.
ˆ HTTP GET - Einer gewo¨hnlichen Anfrage an den Webserver, um an Hand der URL,
oder der in der URL angegebenen Parameter ein HTML Dokument oder eine Datei zu
erhalten. Die u¨berwiegende Mehrheit der Dienste kann so angesprochen werden.
ˆ HTTP POST - Einer in einem HTML Formular eingebetteten Anfrage. Hierbei mu¨ssen
die Parameter der Anfrage in den Formularfeldern u¨bergeben werden. Zu diesem Zweck
mu¨sste im Vorfeld ein Robot geschrieben werden, der die HTML Dokumente, die For-
mulare enthalten, mit den entsprechenden Parametern versieht und an den Server, wie
ein gewo¨hnlicher Browser zuru¨cksendet. Glu¨cklicherweise ist diese Vorgehensweise fu¨r
unsere Zwecke nicht relevant, diese Formulare liefern als Ausgabe die selben Dokumente,
die genauso u¨ber die HTTP GET Anfragen erreichbar sind.
WWW
Der WWW Dienst des Webservers liefert aus dem CMS erzeugte HTML Dokumente. Diese
beinhalten Informationen in Textform, welche, u¨blich fu¨r HTML, innerhalb der Tags der Do-
kumentstruktur eingeschlossen sind. Um Daten aus den HTML Dokumenten zu extrahieren,
mu¨ssen die relevanten Passagen mit Hilfe von regula¨ren Ausdru¨cken in der Dokumentstruk-
tur und innerhalb des Textes gefunden und ausgelesen werden. Das relevante Datum wird an
Hand der es umgebenden Wo¨rter erkannt. Abbildung 1.2 zeigt eine beispielhafte Markierung
im Abgeordnetenprofil.
Im Rahmen des Information Retrieval ko¨nnen zum Aufbau der Datenbanken folgende Bereiche
des Portals als Quellen betrachtet werden:
164
Abbildung 1.83: Markierung von relevanten Daten im Profil eines Abgeordneten.
ˆ Abgeordnete Liefert eine Fu¨lle von Informationen und statistischen Daten u¨ber die Ab-
geordneten des Bundestages. Neben Biographien sind diverse statistische Auflistungen
nach verschiedenen Kriterien und die Offenlegung der Nebenta¨tigkeiten, interessante
Ansatzpunkte zum Aufbau eines Dossiers.
ˆ Ausschu¨sse Beinhaltet die vollsta¨ndige Auflistung der aktuellen Ausschu¨sse des Deut-
schen Bundestages. Informationen u¨ber Aufgaben und Funktionen einzelner Ausschu¨sse
ko¨nnen hier extrahiert werden. Allerdings dienen diese nur der Beantwortung von Fra-
gen, die direkt Funktion oder Aufgabe eines Ausschusses betreffen. Die Auflistung der
Mitglieder eines Ausschusses kann auch aus den Profilen der Abgeordneten aufgebaut
werden. Dieser Bereich ist daher rein als optional zu betrachten.
Abbildung 1.84: Der Bereich: Abgeordnete
165
Abbildung 1.85: Mo¨gliche Abfragen des DIP (8-15 Wahlperiode)
ˆ Parlament Hier liegt das Hauptaugenmerk auf den Rubriken Gremien, Wahlen und
Verwaltung. Die Relevanz dieses Bereiches gestaltet sich a¨hnlich wie im Vorherigen. Es
bedarf spezifisch formulierter Fragen zu den Themen, damit man sich u¨berhaupt mit
diesem Bereich bescha¨ftigen muss.
ˆ Glossar und Abku¨rzungsverzeichnis Im Bereich Service befindet sich das elektroni-
sche Nachschlagewerk des Parlaments. Schlagwortregister, Abku¨rzungsverzeichnis und
Glossar beinhalten Fachbegriffe und deren Erkla¨rung. Diese Quellen ko¨nnen zur Erstel-
lung einer Terminologie der parlamentarischen und politischen Begriffe genutzt werden.
Sach- und Sprechregister : DIP
Die Sach- und Sprechregister des Deutschen Bundestages bestehen aus zwei Datenbanken.
Hinter der Abku¨rzung DIP verbirgt sich das
”
Dokumentations- und Informationssystem fu¨r
parlamentarische Vorga¨nge“ des Deutschen Bundestages. Das System ist in zwei Versionen
verfu¨gbar. Der Ersten, u¨ber dip.bundestag.de erreichbaren, a¨lteren Version, die teilweise un-
vollsta¨ndig Dokumente der Wahlperioden 8-15 beinhaltet. Der zweiten, neuen Version, die
u¨ber dip21.bundestag.de erreichbar ist und Dokumente der 16-ten Wahlperiode beinhaltet.
Beide Datenbanken fu¨hren die Drucksachen und Plenarprotokolle im pdf-Format auf. Do-
kumente, a¨lter als die 14-te Wahlperiode, sind entweder nur als Text Dateien oder in pdf
eingebettete Fotokopien vorhanden. Die aktuellen Plenarprotokolle sind u¨ber die Webseite im
gleichnamigen Bereich abrufbar und werden schon wa¨hrend der laufenden Plenarsitzung als
vorla¨ufige Protokolle eingestellt und spa¨ter in die Datenbank eingepflegt. In der a¨lteren Ver-
sion des DIP existiert ein zusa¨tzlicher separater Bereich zum Stand der Gesetzgebung. Dieser
zeigt an, in welcher Stufe des Prozesses der Gesetzgebung sich ein Prozess aktuell befindet.
Letztgenannte Funktion ist in der neuen DIP21 Version nicht mehr vorhanden und wurde in
die normale Suche integriert.
Die Dokumente beider Datenbanken ko¨nnen direkt u¨ber die URL erreicht werden. Die Da-
tenbanken weisen eine sehr einfache, nach Dokumenttyp und Wahlperiode aufgebaute Ver-
zeichnisstruktur auf. Dies erleichtert das Crawling und den Download der Dokumente, so dass
sich die aufwa¨ndige Herstellung eines Robots, der die Formulare beider Informationssysteme
bedient, eru¨brigt.
166
Abbildung 1.86: Formular zur Suche innerhalb der Vorga¨nge
Die mo¨glichen Abfragen auf der Datenbank im a¨lteren DIP u¨berschneiden sich auf den Do-
kumenten. Wie wir spa¨ter in der Analyse der Dokumente sehen werden, existieren zwei grobe
Gruppen von Dokumenten, die eigentlichen Dokumente und die Plenarprotokolle. Die vier
in Abbildung 1.4 dargestellten Abfrage-Mo¨glichkeiten fu¨hren zu separaten Formularen, die
wiederum eine Linkliste der relevanten Dokumente zuru¨ckliefern.
ˆ Stand der Gesetzgebung verweist auf alle Drucksachen die von einem Antrag ausgehen
und sich im Prozess der Gesetzgebung befinden. Plenarprotokolle mit Redebeitra¨gen
und Abstimmungen zu einem Antrag sind hierbei nicht eingeschlossen.
ˆ Parlamentarische Vorga¨nge im Bundestag/Bundesrat verweist auf alle Vorga¨nge, durch-
sucht also sowohl Protokolle, wie auch Drucksachen, allerdings sind die Inhalte von
Fragestunden nicht indexiert. U¨ber Parlamentarische Vorga¨nge kann man also Antra¨ge,
Redebeitra¨ge in Beratungen und Anfragen finden.
ˆ Parlamentarische Aktivita¨ten von Personen, hierbei werden Antra¨ge, Anfragen aus
Drucksachen und Redebeitra¨ge aus den Protokollen beru¨cksichtigt.
ˆ Fragen fu¨r die Fragestunde, durchsucht die eingegangenen Drucksachen nach Fragen fu¨r
eine Fragestunde und ordnet diese dem entsprechendem Protokoll zu.
Das a¨ltere System arbeitet auf mehreren Sets aus Meta-Daten, die fu¨r jede Anfrage-Mo¨glichkeit
eine andere Belegung brauchen. Es dra¨ngt sich die Vermutung auf, dass es sich hierbei um
vordefinierte Views auf eine SQL Datenbank handelt. Die Abfrage-Mo¨glichkeiten greifen also
auf den gesamten Pool der pdf-Dokumente zu, die Views schra¨nken die Auswahl auf be-
stimmte Dokumenten Typen ein, die u¨ber ganz bestimmte Meta-Daten verfu¨gen. Dies ist
besonders deutlich durch die Unterteilung der Plenarprotokolle auf diejenigen, die Fragestun-
den enthalten und alle u¨brigen, in denen teils Abstimmungen und Redebeitra¨ge vorhanden
167
Abbildung 1.87: Erweiterte Suche in den Aktivita¨ten im DIP21
sind. Sowohl die Suche auf den Parlamentarischen Vorga¨ngen wie auch die Suche auf den
Aktivita¨ten ko¨nnen auf das selbe Protokoll verweisen, wenn der Redner (Suchkriterium fu¨r
einen Vorgang) gleichzeitig eine Frage in der Fragestunde stellte.
Das neuere DIP21 stellt grundsa¨tzlich drei Abfrage-Mo¨glichkeiten zur Verfu¨gung.
ˆ Nach Themengebieten sortierte Beratungsabla¨ufe in der Gesetzgebung ersetzen die
Vorga¨nge und die GESTA der Vorga¨ngerin.
ˆ Die Aktivita¨ten, also eine U¨bersicht aller Aktivita¨ten im Bundestag.
ˆ Eine umfangreiche Suche u¨ber allen Dokumenten des Bundestages.
Es wird wie in der vorherigen Version der gesamte Dokumenten Pool durchsucht, jede Abfrage-
Mo¨glichkeit steht mit zwei Formularen zur Verfu¨gung, der Einfachen und Erweiterten Suche.
Bis auf die Zusammenfassung der Abfrage-Mo¨glichkeiten unterscheidet sich die DIP21 Suche
in der Anzahl und Art der abgefragten Meta-Daten. Die neuere Version des DIP bietet zwar
eine kleinere Anzahl an Mo¨glichkeiten, auf der anderen Seite erho¨ht sie jedoch die Anzahl der
Parameter, die der Suche u¨ber Formularfelder mitgegeben werden.
168
Abbildung 1.88: Der Bereich: Abgeordnete
Datenhandbuch
Das
”
Datenhandbuch zur Geschichte des Bundestages 1994-2003“ ist ein Dokument im pdf-
Format, das Umfangreiche Registerrecherche und Volltextsuche in den Dokumenten des Dt.
Bundestages aus der Zeitperiode erlaubt. Das Dokument beinhaltet die fu¨r pdf-Dokumente
u¨bliche Suchfunktion mit der nach Stichwo¨rtern gesucht werden kann. Zusa¨tzlich sind in den
Sach- und Personenregistern die Informationen u¨ber Ausschu¨sse, Gremien und Abgeordnete,
mit dem Stand bis 2003, gesammelt. Um diese Daten erfolgreich extrahieren zu ko¨nnen, muss
das Dokument mit einem pdf-Parser ausgelesen und die relevanten Stellen mit Hilfe von
regula¨ren Ausdru¨cken ausgelesen werden.
Suche
Die Volltextsuche des Portals ist in zwei Formulare unterteilt. Zum einen gibt es einen Such-
agenten, den Bundesadler, der hier nicht als Staatssymbol, sondern eher als Maskottchen
des Portals dargestellt wird. Dieser Agent verarbeitet einen im Formular u¨bermittelten Text
und lenkt den Benutzer u¨ber eine Link-Sammlung auf Inhalte, die der Benutzer in seinem
Text gemeint haben ko¨nnte. Zusa¨tzlich gibt der Adler einen, manchmal nicht ganz schlauen
Kommentar von sich. Fu¨r die Zwecke der PG ist der Adler-Agent nur im Sinne seiner techni-
schen Realisierung spannend. Die durch Ihn bereitgestellte Suchfunktion ist zur Navigation
innerhalb der Webseiten des Bundestages fu¨r die von der PG erstellte Software ohne belang.
Die eigentliche Suchfunktion des Portals ist eine gewo¨hnliche Stichwortsuche, die eine nach
Relevanz sortierte Link-Liste liefert. Das auf der HTTP POST Methode basierende Formular
bedarf eines im Vorfeld dargestellten Robots, der das Formular mit Stichwo¨rtern versorgt
und die Ergebnisse mit einem Crawler und einem auf regula¨ren Ausdru¨cken basierten Parser
abtastet. Wie schon bei dem vorherigen Suchformular ist die Relevanz fu¨r das Projekt zu
gering, im Vergleich zu dem Aufwand den man betreiben mu¨sste, um diesen Dienst zu nutzen.
Zum einen gehen wir davon aus, dass die Webseiten des Deutschen Bundestages aus Gru¨nden
der Wiedererkennung und Konsistenz eine feste organisatorische Struktur behalten werden.
169
Daher bleiben die relevanten Bereiche unvera¨ndert. Der Einsatz eines CMS impliziert indirekt
die Konsistenz der Daten. Zum Anderen wa¨re der Einsatz von generischen aber sehr ma¨chtigen
Parsern notwendig um die Ergebnisse der Suche zu verarbeiten. Der Einsatz von spezialisierten
Parsern, die in einem eingeschra¨nktem Bereich der Webseite eingesetzt werden, erscheint uns
als sinnvoller.
Digitaler Bilderdienst
Der digitale Bilderdienst des Deutschen Bundestages stellt Aufnahmen der Sitzungen, Ver-
sammlungen, Abgeordneten und Geba¨ude der O¨ffentlichkeit zur Verfu¨gung. Die Aufnahmen
stehen als Dateien zum Download im jpg-Format bereit. Da sich diese PG nicht mit der
Informationsextraktion von Daten aus digitalen Bildern bescha¨ftigt, kann dieser Dienst, der
strenggenommen nur ein weiterer Bereich innerhalb des WWW Dienstes ist, vernachla¨ssigt
werden.
Newsletter
Der Newsletter Dienst ist ein auf dem SMTP Protokoll basierter Dienst der an Abonnenten
Emails in text-Form verschickt. Aktuelle Meldungen des Bundestages ko¨nnen hier abonniert
werden. Dieser Dienst kann dazu genutzt werden, um brandaktuelle Themen des Bundestages
zu speichern. Allerdings ist die Halbwertszeit dieser Informationen relativ eingeschra¨nkt. Zum
einem ko¨nnen die selben Informationen direkt aus dem WWW Dienst extrahiert werden,
zum Anderen werden diese Daten mit einer leichten Verzo¨gerung in den Protokollen und
Dokumenten des Bundestages zu finden sein.
RSS
Das Abonnement des RSS Dienstes des Bundestages hat a¨hnliche Merkmale wie das Abonne-
ment des Newsletters und birgt die selben Redundanzen. Strenggenommen ist der RSS Dienst
auch nur ein WWW a¨hnlicher Dienst der XML Dokumente anstatt von HTML ausliefert. Der
einzige Vorteil des RSS Feeds ist seine kompakte Form, die einheitliche Nutzung von HTTP
GET Anfragen und wesentlich einfachere Dokumentenstruktur.
1.12.3 Vorga¨nge
Gesetzgebung
Der Vorgang der Gesetzgebung ist ein mehrstufiger Prozess, der mit entsprechenden Doku-
menten des Bundestages begleitet wird und der folgende Schritte beinhaltet:
ˆ Die Gesetzesinitiative geht in der Mehrheit der Fa¨lle von der Bundesregierung aus.
Manchmal wird sie auch vom Bundesrat oder aus der die Mitte des Bundestages, also
von Abgeordneten, Parteien und Fraktionen eingebracht.
– Der Prozess wird im Normalfall schriftlich initiiert und dem Bundestag in einer
Rede vorgestellt.
– Referenzen auf diesen Prozess sind in der GESTA und den Plenarprotokollen zu
finden.
170
ˆ Die Beratung und Beschlussempfehlung erfolgt auf die eingebrachte Gesetzesinitiative.
Der Schritt wird meistens in mehreren Lesungen, maximal jedoch drei, abgehandelt.
Als Ergebnis liegt dem Bundestag eine Beschlussempfehlung zur zur Verabschiedung
vor oder sie wird den Ausschu¨ssen zu weiteren Beratung vorgelegt, falls besondere, in
den Ausschu¨ssen vorhandene Expertise, beno¨tigt wird.
– Daten sowie die Ergebnisse dieses Schrittes sind in Protokollen und Dokumenten
zu finden.
ˆ Ein Gesetz wird in einer Sitzung durch den Bundestag in einer Abstimmung verabschie-
det. Die Referenzen auf diesen Schritt befinden sich in den Protokollen und als Beschluss
in den Dokumenten.
ˆ Der Beschluss des Bundestages wird an den Bundesrat zur Verabschiedung weitergelei-
tet.
ˆ Bundesrat behandelt den Gesetzesbeschluss in einer Sitzung. Sollte das Gesetz durch den
Bundesrat in einer Abstimmung verabschiedet werden, wird es an den Bundespra¨sidenten
weitergeleitet. Sonst wird es an den Vermittlungsausschuss zur Kompromissfindung wei-
tergegeben.
ˆ Gegenzeichnung durch die Bundesregierung ohne weitere Beratung oder Anku¨ndigung
im Bundestag no¨tig.
ˆ Ausfertigung durch den Bundespra¨sidenten.
ˆ Schließlich verku¨ndet der Bundespra¨sident das verabschiedete Gesetz. Der Prozess ist
damit abgeschlossen und das Gesetz tritt entweder unverzu¨glich oder zu einen festge-
legten Zeitpunkt in Kraft.
Eine Abstimmung
Der mit einer Abstimmung verbundene Prozess ist recht einfach und kann als Unterprozess
im Prozess der Gesetzgebung gesehen werden. Die zu einem Sachverhalt geforderte Abstim-
mung hat einen Initiator, einen die Abstimmung u¨berwachenden Akteur und die Menge der
Abstimmenden. Eine Abstimmung wird angeku¨ndigt, initiiert und ausgeza¨hlt. Das Ergebnis
der Abstimmung wird bekanntgegeben.
Antra¨ge
Antra¨ge sind fu¨r gewo¨hnlich Gesetzesinitiativen aus der Mitte des Bundestages. Die Vorga¨nge
dieser Form werden im Bundestag mit den folgenden Bezeichnungen in der im Verzeichnis
der Drucksachen gefu¨hrt:
ˆ Antrag
ˆ A¨nderungsantrag
ˆ Entschließungsantrag
171
Beschlussempfehlung und Bericht
In einer Beschlussempfehlung begru¨nden die Initiatoren eines Gesetzes ihr Vorhaben. Eine
Beschlussempfehlung ist in vier Artikel gegliedert.
ˆ A. Problem, in dem ein Missstand, welchen dieses Gesetz beheben soll, ausfu¨hrlich
skizziert und damit die Einleitung des Prozesses justifiziert wird.
ˆ B. Lo¨sung. Eine ausfu¨hrliche Schilderung, wie das zuvor beschriebene Problem durch
das zu beschließene Gesetz gelo¨st werden soll.
ˆ C. Alternativen. Hier werden, meist kurz, die mo¨glichen Alternativen zur Lo¨sung ange-
boten.
ˆ D. Kosten. Dieser Teil fu¨hrt die vermuteten Kosten auf, die nach dem in Kraft treten des
Gesetzes entstehen werden. Es werden meistens Kosten fu¨r die von dem Gesetz direkt
betroffenen Personengruppen und Institutionen aufgefu¨hrt.
Mit dem Passus:
”
Der Bundestag wolle beschliessen:“ werden der eigentliche Gesetzestext
oder die A¨nderungen an einem vorhandenen Gesetz eingeleitet.
Im Anhang des Dokuments befindet sich ein Bericht zu dem Beratungsprozess, der im Vorfeld
stattgefunden hat. Ein an dem Prozess beteiligter Abgeordneter wird mit dem Bericht immer
dann beauftragt, wenn die Beschlussempfehlung zur Beratung einem Ausschuss vorgelegt
wurde. In dem Bericht werden vom Berichterstatter die Stellungnahmen aller mitarbeitenden
Gremien und explizit der beteiligten Ausschu¨sse aufgefu¨hrt.
U¨bersicht
In einer U¨bersicht werden Beschlussempfehlungen u¨ber einen Zeitraum tabellarisch zusam-
mengefasst. Eine U¨bersicht ist eine Roadmap u¨ber die Abstimmungen des Bundestages und
beginnt mit dem Passus:
”
Der Bundestag wolle beschliessen:“
Gesetzesentwurf
Ein Gesetzesentwurf ist ein Dokument, mit dessen Vero¨ffentlichung der Gesetzgebungsprozess
des Bundestages abgeschlossen wird. Das Gesetz wird im na¨chsten Schritt dem Bundesrat zur
Abstimmung vorgelegt. Neben den Initiatoren des Gesetzes und dem Auszug aus dem Ent-
wurf in dem das Problem, die Lo¨sung, die Alternativen und die Kosten kurz skizziert werden,
entha¨lt das Dokument den folgenden Passus
”
Der Bundestag hat das folgende Gesetz beschlos-
sen:“. Darauf folgt der eigentliche Gesetzestext. Auf den letzten Seiten des Gesetzesentwurfs
befindet sich eine ausfu¨hrliche Begru¨ndung zu jedem Artikel des Gesetzes.
Anfragen
Eine Anfrage ist eine Sammlung schriftlich gestellter Fragen zu einem Themenbereich an die
Bundesregierung. Eine Anfrage hat einen Initiator, also die Person, Partei oder Fraktion,
welche diese Frage vorbringt und einen Antwortenden. Jede Anfrage bedarf einer schriftlichen
Antwort.
172
ˆ Große Anfrage ist ein an die Bundesregierung gestellter Fragenkatalog zu einem Pro-
blemthema. Die Fragen werden in Kategorien zu den Aspekten des Problemthemas
gruppiert, was zu einer großen Anzahl an Fragen fu¨hrt.
ˆ Kleine Anfrage ist ebenfalls eine schriftlich formulierte Anfrage, die einer schriftlichen
Antwort bedarf. Die kleine Anfrage betrifft einen kleineren Themenbereich zu dem nur
wenige Fragen gestellt werden.
ˆ Die Antwort der Bundesregierung ist eine Drucksache die auf eine kleine oder große
Anfrage die entsprechenden Antworten liefert.
Unterrichtung
Eine Unterrichtung ist eine Sammlung bedeutsamer Erkenntnisse, die dem Bundestag zur
Entscheidungsfindung mitgeteilt werden. Eine Institution, die den Bundestag u¨ber einen Sach-
verhalt oder den Verlauf einer Pru¨fung unterrichtet, gliedert ihre Ausfu¨hrung in drei Teile: in
den Vorbemerkungen werden der Zweck und Schwerpunkte der Unterrichtung dargestellt. In
der Zusammenfassung werden die kurz gefassten Ergebnisse aufgelistet. Schließlich folgt die
detailierte, in mehrere Kapitel aufgeteilte, Ausfu¨hrung.
Fragen zu einer Fragestunde
In einer Sitzung des Deutschen Bundestages werden als Punkt der Tagesordnung Fragen von
Abgeordneten beantwortet. Die Fragen werden als Dokument zusammengefasst und dem Bun-
destag vorgelegt. Der Adressat einer Frage beantwortet diese im Rahmen einer Fragestunde.
Die im Vorfeld eingereichten Fragen sind also als Drucksache des Bundestages zu finden, die
Antworten sind im Plenarprotokoll der Sitzung zu finden, in der diese Fragestunde stattfindet.
Wahlen und Wahlvorschla¨ge
Die Abgeordneten einer Fraktion ko¨nnen schriftlich Wahlvorschla¨ge fu¨r die zu besetzenden
Posten und A¨mter im Bundestag einreichen. Diese werden als Drucksachen mit der Vorgangs-
bezeichnung Wahlvorschlag gefu¨hrt. Die darauf folgende Abstimmung findet in einer Sitzung
des Bundestages statt und die Ergebnisse sind in dem entsprechenden Plenarprotokoll zu
finden.
1.12.4 Dokumente
In diesem Abschnitt bescha¨ftigen wir uns mit der Struktur und Form der Dokumente, die auf
der Webseite des Bundestages zu finden sind. Aus diesen Daten sind im Verlauf der PG die
fu¨r die Erfu¨llung der Aufgabenstellung notwendigen Datenbanken erstellt worden.
Die fu¨r die PG relevanten Dokumente stammen aus den Wahlperioden 14-16 und sind aus-
schliesslich im pdf-Format vorhanden.
Die Abbildung 1.89 zeigt das Beispiel einer Drucksache (die Antwort der Bundesregierung auf
eine kleine Anfrage) mit entsprechenden Markierungen, welche den Zweck des Dokumentes
verdeutlichen sollen. Diese Markierungen wurden von einem Menschen angebracht, sollen aber
173
Abbildung 1.89: Beispiel einer Drucksache mit relevanten Bereichen.
im Zuge der PG von der Maschine automatisch angebracht werden. Die zwei groben Bereiche,
die mit violett und hell-blau markiert wurden, identifizieren das Dokument selbst (violett)
und das Dokument, auf das sich dieses bezieht (hell-blau). Die Typen der Dokumente wurden
gru¨n markiert, die beteiligten Personen und Institutionen gelb. Der Titel wurde mit orange
abgesetzt, die Nummern der Drucksachen sind rosa. An diesen markierten Bereichen und
Wo¨rtern werden die Dokumente identifiziert und mit Hilfe der markierten Daten verarbeitet.
Eine detailierte Auflistung der Markierungen und Verarbeitungstechniken folgt im weiteren
Verlauf dieses Abschlussberichts. Fu¨r den Anwendungsbereich fu¨hren wir noch die U¨bersicht
u¨ber die vorhandenen Arten der Dokumente sowie deren herausstechenden Merkmale:
ˆ BTD
Drucksachen des Deutschen Bundestages
– Pfad:
Die im pdf-Format gespeicherten Dateien befinden sich unter
http://dip.bundestag.de/btd/[Wahlperiode]/[fortlaufend nummeriertes Unterver-
zeichniss]/[XXYYYYY].pdf
– Dateiname und Nummerierung:
Dateiname ist siebenstellig, Die ersten beiden Stellen sind identisch mit der Wahl-
periode (XX), die na¨chsten fu¨nf Stellen (YYYYY) sind fu¨r die laufende Nummer
reserviert. Diese entspricht der Drucksachennummer. Die Nummerierung innerhalb
des Dokuments hat immer die Form Wahlperiode/Drucksachennummer.
– Layout:
Das Layout der Drucksachen ist abha¨ngig vom Vorgang. Antra¨ge, Beschlu¨sse, An-
fragen und Anfragen sind meistens ein oder zweispaltig. Fragen zur Fragestunde
sind immer tabellarisch angeordnet.
174
– Vorga¨nge:
* Antra¨ge
* Kleine und große Anfragen
* Antworten
* Beschlussempfehlungen, Berichte, Empfehlungen und Erga¨nzungen
* Gesetzentwu¨rfe
* U¨bersichten
* Unterrichtungen
* Fragen fu¨r eine Fragestunde
* Wahlvorschla¨ge
ˆ BTP
Plenarprotokolle des Deutschen Bundestages
– Pfad:
Die im pdf-Format gespeicherten Protokolle befinden sich unter
http://dip.bundestag.de/btp/[Wahlperiode]/[fortlaufend nummeriertes Unterver-
zeichniss]/[XXYYY].pdf
– Dateiname und Nummerierung:
Dateiname ist fu¨nfstellig, Die ersten beiden Stellen (XX) sind identisch mit der
Wahlperiode, die folgenden drei Stellen (YYY) sind fu¨r die laufende Sitzungsnum-
mer reserviert. Wird in einem Schriftstu¨ck auf ein Plenarprotokoll verwiesen, so
hat die Plenarprotokoll Nummer immer die Form Wahlperiode/Sitzungsnummer.
– Layout:
Das Layout der Plenarprotokolle ist immer zweispaltig mit vielen Einru¨ckungen.
– Vorga¨nge:
* Abstimmungen
* Fragestunden
* Reden (Beratungen, Aussprachen)
ˆ IDX
Verhandlungen des Deutschen Bundestages: Drucksachen Ba¨nder
– Pfad:
Die im pdf-Format gespeicherten Ba¨nder der Drucksachen befinden sich unter
http://dip.bundestag.de/btd/[Wahlperiode]/idx/[XX]IN[YYY].pdf
– Dateiname und Nummerierung:
Dateiname ist fu¨nfstellig, Die ersten beiden Stellen sind identisch mit der Wahlpe-
riode (XX), darauf folgt die Abku¨rzung IN fu¨r Index. Die laufende Nummer des
aktuellen Bandes fu¨llt die folgenden drei Stellen (YYY)aus.
175
– Layout:
Das Layout der Drucksachen Ba¨nder beginnt immer mit einem tabellarischen
Abku¨rzungsverzeichnis und dann einer fu¨nfspaltigen, tabellarischen Auflistung al-
ler Drucksachen diesen Bandes.
– Vorga¨nge:
Die Ba¨nder beinhalten keine Vorga¨nge, sie listen alle Drucksachen mit Titel, Datum
Urheber und Dokumenttyp auf.
176
2 Systementwurf
2.1 Das System in prozessorientierter Sicht
Die Ziele der Projektgruppe spezifizieren die Erstellung eines intelligenten Software-Systems
zur Beantwortung von Benutzerfragen. Das Software-System soll auf Basis von bestehenden
Standards in der Software-Technologie als eine Java Anwendung realisiert werden. Durch den
Einsatz dieser Anwendung, soll in erster Linie zeitaufwa¨ndige Recherche verku¨rzt und verein-
facht werden. Neben der in der Projektaufgabenstellung beschriebenen Fragebeantwortung,
sollen auf Wunsch Teile der gesammelten Informationen dargestellt werden. Die Anwendung
kann also in die Kategorie der Wissens- und Informationssysteme eingeordnet werden und
weist einige Merkmale einer Suchmaschine auf.
Eine derartige Anwendung setzt sowohl die Existenz einer graphischen Benutzeroberfla¨che
(GUI) die dem fragestellendem Benutzer zuga¨nglich ist, wie auch die Existenz eines umfang-
reichen Datenverarbeitungssystems im Hintergrund. Wir unterscheiden also in der architek-
tonischen Sicht auf das System, zwischen dem Benutzer zugewandtem Frontend und dem
datenverarbeitendem Backend.
Die komplexen Vorga¨nge im Backend sollen in erster Linie von einem Administrator/Entwick-
ler u¨berwacht und gesteuert werden, eine vollsta¨ndige Automatisierung ist denkbar einfach,
aber nicht im Sinne der Projektgruppe. Eine eigene GUI ermo¨glicht bessere Pra¨sentation und
Kontrolle der Datenverarbeitung, schließlich stecken die gro¨ßten Aufwa¨nde gerade in dem fu¨r
den Frontend-Benutzer unspektakula¨ren Backend.
Die Funktionalita¨t des Gesamtsystems kann grob in drei Prozessen: Wissensentdeckung, Ex-
traktion und Fragebeantwortung zusammengefasst werden. Daraus ergibt sich die Modellie-
rung der drei Prozesse, die eine logische Aufteilung des Systems erlauben. Wenn wir die Wege
der Daten in dem System betrachten, wird auf der einen Seite der Datenweg aus dem Inter-
net zur Datenbank und auf der anderen Seite, der Weg der Daten aus der Datenbank zum
Benutzer deutlich sichtbar.
Diese sinnvolle Aufteilung des Software-Systems fu¨hrte zu der Entscheidung zwei Anwendun-
gen zu erstellen. Beide haben jeweils den Charakter eines
”
standalone“ Subsystems.
Abbildung 2.1 zeigt das System in eben dieser prozessorientierten Sicht. Sie stellt gleichzei-
tig den Weg der Daten durch das Gesamtsystem und die Interaktion der Benutzer mit den
beiden Anwendungen dar. Diese etwas ungewo¨hnliche Sicht als SDL Diagramm auf die An-
wendungen dient der Orientierung innerhalb des Systems und stellt gleichzeitig den gro¨bsten
Funktionsumfang dar.
2.1.1 Akquisition- und Extraktionssystem (AES)
Das Akquisition- und Extraktionssystem ist eine modulare, aus Komponenten bestehende
Anwendung, die Wissen aus Dokumenten und Webseiten extrahieren soll. Das Internet, spe-
177
Abbildung 2.1: Zwei Anwendungen in der prozessorientierten Sicht.
ziell die Seiten des Deutschen Bundestages werden als eine umfangreiche und heterogene
Quelle genutzt. Die dort vorhandenen Dateiformate der Quellen wurden bereits im Kapitel
Anwendungsgebiet beschrieben.
AES speichert die akquirierten Dateien im lokalen Dateisystem und extrahiert Informationen
aus deren Inhalten. Neben einer Benutzeroberfla¨che mit der ein Administrator/Entwickler
die Anwendung steuern kann, existiert eine Anbindung an die Datenbanken in denen das
extrahierte Wissen gespeichert wird. Der Weg der aus den Inhalten gewonnen Daten kann
wie folgt als Prozesse beschrieben werden:
P00 Datenakquisition.
Die Datenaquisition ist ein Synonym fu¨r die Erstellung einer gemeinsam genutzten Basis
von Dokumenten, die zur spa¨teren Verarbeitung im Dateisystem des Rechners abgelegt
wird. Alle zur Informationsextraktion notwendigen Vorverarbeitungsschritte sollen im
Verlauf dieses Prozesses abgeschlossen werden.
Dieser Prozess veranlasst also das Herunterladen von Dateien aus dem Dokumenten-
Archiv und der Webseite des Bundestages. Da die Dokumente im pdf-Format vorliegen,
sollen sie zuna¨chst einmal abgespeichert werden. Um diese Dokumente verarbeiten zu
ko¨nnen, mu¨ssen sie von pdf zu plain text konvertiert werden. Der Prozess ha¨lt gleich-
zeitig nach, welche Dateien, von welcher Lokation bereits heruntergeladen worden sind
und an welcher Stelle sie im Dateisystem abgespeichert wurden. Abschliessend werden
alle heruntergeladenen Dokumente indexiert.
178
P01 Informationsextraktion.
Im Zuge dieses Prozesses werden interessante Daten aus den gesammelten Daten ex-
trahiert. Diese Informationen, also alle fu¨r die Fragebeantwortung beno¨tigten Daten
werden strukturiert gespeichert. Die vorhandenen Dokumente werden im Verlauf dieses
Prozesses mit zusa¨tzlichen Meta-Informationen versehen. Die Informationsextraktion
beinhaltet nicht nur die Markierung von
”
Named Entities“ sondern auch der semanti-
schen Relationen zwischen den Entites. Zusa¨tzlich sollen Informationen, die mit Hilfe
von regula¨ren Ausdru¨cken herauslesen wurden, Strukturiert in XML Dateien abgelegt
werden.
2.1.2 Fragebeantwortungssystem (FBS)
Das Fragebeantwortungssystem, kurz FBS, ist ebenso eine modulare Anwendung welche Be-
nutzerfragen entgegen nehmen soll. Sie soll die in den Datenbanken vorhandenen Informa-
tionen nutzen um diese Fragen zu beantworten. Dies wird in der Abbildung 2.1 durch den
folgenden Prozess dargestellt:
P02 Fragebeantwortung.
Der Benutzer kann u¨ber eine grafische Oberfla¨che Fragen an das System stellen. Abha¨ngig
von der gestellten Frage werden unterschiedliche Methoden der Beantwortung aus-
gefu¨hrt, welche unterschiedliche Komponenten des Systems ansprechen. Die Kompo-
nenten berechnen auf Grund der vorhandenen und a priori extrahierten Informationen
eine Antwort, die wiederum an den Benutzer ausgeliefert wird.
2.1.3 Prozessorientierung und UML
Bei der Beschreibung der Software wird eine Kombination aus Prozessdiagrammen und UML
benutzt. UML Diagramme alleine ha¨tten den Umfang dieser Beschreibung vervielfacht und
bilden die prozessorientierte Interaktion der Komponenten nur unzureichend ab. Getreu dem
Motto, dass eine Beschreibung selbst von einem Laien schnell lesbar sein sollte verzichten wir
auf aufwa¨ndige Sequenz-, Zustand- und Komponentendiagramme und beschreiben die eben
erwa¨hnte Interaktion als Prozesse.
Unsere Aufteilung in die oben beschriebenen drei Prozesse ist natu¨rlich nur die oberste Ebe-
ne und eine Abstraktion. Jeder dieser groben Prozesse zerfa¨llt in eine Menge aus feineren,
teilweise von einander unabha¨ngigen Prozessen. Die im weiteren Verlauf des Kapitels genauer
beschrieben werden.
2.2 Architektur
2.2.1 Design Entscheidungen
Entsprechend dem Anwendungsgebiet klassifizieren wir beide Subsysteme als prozessorien-
tierte, datenverarbeitende Anwendungen, ohne explizite Benutzerintervention [Som04]. Der
Benutzer lo¨st nur die datenverarbeitenden Prozesse aus, hat jedoch keinen Einfluss auf deren
Verlauf. Das Gesamtsystem nimmt, entsprechend der Request-Response Verfahrensweise, eine
Benutzeranfrage entgegen und liefert eine Antwort aus. Ist der Request eine Benutzerfrage,
179
wird die Antwort berechnet. Ist der Request ein Anweisung zum Starten eines datenverarbei-
tenden Prozesses wird dieser Ausgefu¨hrt.
Die Aufteilung des Systems auf zwei Subsysteme begu¨nstigt die Implementierung als eine
Client/Server Anwendung. Das Frontend ko¨nnte auf der Client-Seite ausgefu¨hrt werden, das
Backend auf dem Server. Dies ist jedoch im Rahmen dieser PG, aus Zeitgru¨nden nicht beab-
sichtigt.
Als generisches Architekturmodell verwenden wir das von Buxton eingefu¨hrte Repository
Modell [J.80]. Ein Repository ist dem entsprechend eine passive Sammlung aus gemeinsam
genutzten Datenstrukturen und Datenbanken, welche von Subsystemen umgeben sind. Wie
bereits erwa¨hnt Betrachten wir die Prozesse P00-P01 und P02 als eben diese Subsysteme.
Jedes Subsystem, besteht aus mehreren Komponenten, die in ihrem gemeinsamen Wirken
diesen Prozess implementieren. Die einzelnen Komponenten sind in dem Modell fu¨r die Kon-
trolle und Verarbeitung der Daten verantwortlich, es gibt keine zentrale verwaltende Instanz
die sich um Konsistenz bemu¨ht. Jede Komponente sorgt selber dafu¨r das sie die Daten lesen
und wieder speichern kann. Um diese Aufgabe zu erleichtern verwenden wir XML als Datei-
format fu¨r unsere Datenbanken. Einige Komponenten werden teilweise prozessu¨bergreifend
verwendet und gewa¨hrleisten damit gro¨ßtmo¨gliche Wiederverwertbarkeit des Quellcodes.
Die Projektgruppe hat sich bei der Implementierung des Prozesses P00 ganz bewusst fu¨r die
Erstellung einer beinahe Abbildung der Inhalte des Dokumenten-Archivs entschieden. Die
Entwicklung und Test der Software ist damit unabha¨ngig von einer Internet Verbindung und
wir erkaufen uns, auf Kosten des zusa¨tzlichen Speicherplatzes wesentlich schnelleren Zugriff
auf die Dokumente. Außerdem betrachten wir die im pdf-Format vorliegenden Dokumente
des Bundestages als statische Dateien, die im laufe der Zeit vom Bundestag nicht gea¨ndert
werden du¨rfen. Anders verha¨lt es sich mit den dynamischen Inhalten der Webseite, diese
mu¨ssen regelma¨ßig auf A¨nderungen u¨berpru¨ft werden. Diese Mechanismen werden jedoch
nicht implementiert, obwohl eine Grundlage durch das Nachhalten der heruntergeladenen
Dateien im Ansatz gegeben ist.
2.2.2 Dekomposition der Architektur
Die Subsysteme werden entsprechend der Abbildung 2.2 in einzelne Komponenten zerlegt.
Jedes Subsystem interagiert, gema¨ß der Vorgabe des Architekturmodells mit dem Repository
in dem es Daten liest und/oder speichert. Die durchgezogenen Pfeile markieren eben diese
Interaktion. Die gestrichelten Pfeile dru¨cken die
”
Komponente benutzt eine andere Kompo-
nente“ Beziehung aus. Im vorangegangenem Abschnitt haben wir die Aufgaben der Prozesse
beschrieben, in diesem Abschnitt werden die beteiligten Komponenten kurz skizziert. Eine
genaue Beschreibung einzelner Komponenten befindet sich im im Kapitel 2.2 dieser Ausar-
beitung.
AES: [P00] - Datenakquisition
Die Komponenten der Datenakquisition interagieren miteinander um den Weg der Dokumente
aus dem Internet in das Repository zu realisieren und ko¨nnen folgender weise aufgelistet
werden:
180
Abbildung 2.2: Komponentenmodell
181
ˆ [K00]Crawler
La¨dt Dateien an Hand einer eingegebenen URL herunter und speichert sie im Dateisys-
tem ab. Die Dateien sollen im pdf-Format abgespeichert werden und deren URL an das
Subsystem u¨bergeben werden.
ˆ [K01]AES FileWorker
Diese Komponente ist entsprechend der MVC Architektur der Controller in dieses Sub-
systems und steuert den weiteren Ablauf der Datenverarbeitung.
ˆ [K01a]AES Graphic User Interface
Die GUI des Backends mit der die Datenakquisition und Extraktionsprozesse gestartet
werden.
ˆ [K03]PDFbox
Eine externe Open Source Komponente um PDF Dateien laden und verarbeiten zu
ko¨nnen. Wird von uns hauptsa¨chlich dazu benutzt Dokumente aus dem pdf-Format ins
plain text zu konvertieren.
ˆ [K04]AnnotationTool
Das AnnotationTool ist eine standalone Anwendung mit einer eigenen GUI um Texte mit
einem vordefinierten Set aus Named Entities zu taggen. An dieser Stelle benutzen wir
sie um Dokumente aus dem plain text in das wortweise-tokenisierte Format (wt-Format)
zu konvertieren. Das wt-Format wird fu¨r die Named-Entity-Recognition beno¨tigt.
AES: [P01] - Informationsextraktion
Die Komponenten der Informationsextraktion bilden in ihrer Interaktion die Prozesse ab, mit
denen Informationen aus Dokumenten, dem Internet und anderen Datenbanken in das Reposi-
tory transferiert werden. Das Ziel der Informationsextraktion ist es fu¨r die Fragebeantwortung
lesbare Datenstrukturen zu erzeugen.
ˆ [K01]AES FileWorker
Diese Komponente ist entsprechend der MVC Architektur der Controller in dieses Sub-
systems und steuert den weiteren Ablauf der Datenverarbeitung.
ˆ [K01a]AES Graphic User Interface
Die GUI des Backends mit der die Datenakquisition und Extraktionsprozesse gestartet
werden.
ˆ [K02a]LuceneUpdate
Eine Interface Komponente zur Ansteuerung des Lucene Indexers.
ˆ [K05] RM DatensatzBuilder
Diese Komponente erstellt einen Eingabe-Datensatz fu¨r die RapidMiner Anwendung.
Dieser Datensatz wurde aus den Meta-Daten der Dokumente und Abgeordneten erstellt
und wird beno¨tigt um mit Hilfe von Lernverfahren im RapidMiner die so genannten
Warum-Fragen zu beantworten.
182
ˆ [K06]BTD2BTP RelationExtraction
Diese Komponente erstellt eine simple XML Datenbank aller Verweise zwischen den
Protokollen und Drucksachen. Sie bildet also die Relationsrichtung: welche Drucksachen
wird in einem Protokoll besprochen, bzw. zittiert. Die umgekehrte Relation: in welchen
Protokollen wird eine Drucksache behandelt ist auf kosten von ein wenig Rechenzeit aus
der Liste zu entnehmen.
ˆ [K07]BTD Builder
Diese Komponente ist eine Vorstufe vor dem Aufbau des BTD Index in Lucene. Sie
extrahiert aus den Drucksachen des Bundestages mit Hilfe von Regular Expressions re-
levante Meta-Daten. Sie erzeugt also eine XML Datenbank mit diesen Daten, die spa¨ter
bei der Erzeugung des BTD Index in die Lucene frei-definierbaren Felder zu einem Do-
kument importiert wird.
Diese, urspru¨nglich nur auf dem Inhaltsverzeichnis des Bundestages, also den IDX Doku-
menten arbeitende Komponente wurde durch eine verbesserte Version ausgetauscht, die
mit Hilfe der PDFbox Komponente die BTD pdf-Dokumente erneut o¨ffnet und daraus
Informationen extrahiert.
ˆ [K08]BTP Event Extraction
Die Event Extraction Komponente markiert Ereignisse in den Protokollen des Bundes-
tages. Die komponente erkennt an Hand der im Event Schema definierten Triggerwo¨rter
im Text stattfindende Ereignisse und markiert sie mit xml Tags. Diese ko¨nnen spa¨ter
von der Maschine gelesen und interpretiert werden.
ˆ [K09]SpeechExtraction
Diese Komponente durchsucht Sitzungsprotokolle nach bestimmten Mustern zerlegt ihre
Inhalte in Tagesordnungspunkte und damit auch in einzelne Redebeitra¨ge. Zu jedem
Tagesordnungspunkt / Rede wird ein Satz aus Meta-Daten erstellt und im Repository
als XML Datei gespeichert. Die einzelnen Redebeitra¨ge erhalten eine eindeutige ID und
werden im Repository gespeichert. Die Redebeitra¨ge und die gesammelten Meta-Daten
werden in dem BTP Index von Lucene integriert.
ˆ [K10]MOPSBuilder
”
Members Of Parlament Search“ Builder la¨dt die vorhandenen Biographien der Abge-
ordneten von der Webseite des Bundestages. Sie extrahiert aus den HTML-Webseite
zu jedem Abgeordneten einen von der Wahlperiode abha¨ngigen Satz an Abgeordneten-
Daten. Aus diesen Informationen wird eine eine XML Datenbank mit der man Fragen
zu den Abgeordneten beantworten kann.
ˆ [K11]AUSSCHBuilder
Diese Schwester-Komponente zu MOPSBuilder arbeitet auf den Informationswebseiten
zu den verschiedenen Ausschu¨ssen des Detuschen Bundestages. Diese Komponente er-
stellt eine vollsta¨ndige Liste der Mitglieder eines Ausschusses. Diese ebenso aus HTML-
Webseiten extrahierten Informationen werden in einer XML Datenbank gespeichert.
ˆ [K12]BTLBuilder
Auf den Webseiten des Bundestages befinden sich erstaunlich wenige Informationen
zur der Zusammensetzung und Verteilung der Posten in der Bundesregierung. Zu dem
183
fehlen die als Allgemeinwissen vorausgesetzten Informationen. Also einfache statistische
Daten u¨ber die Parteien, Sitzverteilung, die Parteivorsitzenden und Gru¨ndungsdaten.
Diese Daten wurden in einer separaten Datenbank der BTLookup XML Datenbank
abgelegt, die anfa¨nglich manuell erzeugt worden ist. Der BTL Builder erzeugt diese
Datenbank automatisch aus den Webseiten der Wikipedia.org.
FBS: [P02] - Fragebeantwortung
Dieser Abschnitt muss im Laufe des zweiten Projektsemesters detailliert beschrieben werden.
Die Zusammenstellung des Subsystems steht zum heutigen Zeitpunkt nicht fest, daher wird
hier erst mal auf die Beschreibung aller beteiligten Komponenten verzichtet.
ˆ [K10a] MopsQuery
Diese fragebeantwortende und aus dem Ku¨rzel MOPS also:
”
Members Of Parlament
Search“ stammende Komponente, benutzt die gleichnamige XML Datenbank um sta-
tistische und direkte Fragen zu Abgeordneten zu beantworten.
ˆ [K13] Dossier
Das Dossier ist eine informationsdarstellende Komponente die sowohl MOPS XML, wie
auch beide Lucene Indices benutzt. Sie stellt in der GUI ein Dossier eines Abgeord-
neten. Dieses Dossier ist abha¨ngig zu der Wahlperiode und beinhaltet nicht nur alle
biographischen Daten eines Abgeordneten, sondern auch alle Drucksachen an den der
Abgeordnete beteiligt war. Zusa¨tzlich wird eine Liste der Reden des Abgeordneten aus
den Protokollen gefu¨hrt.
ˆ [K14 EventCutter
Der EventCutter geho¨rt zu den fragebeantwortenden Komponenten, es benutzt Lucene
um zu einer Stichwortmenge, eine Auswahl an Dokumenten zu laden und die Textaus-
schnitte um diese Stichwo¨rter herauszuschneiden und zuru¨ckzugeben.
ˆ [K15]Partynator
Diese urspru¨nglich zum Campus Fest erstellte Komponente vergleicht Benutzerangaben
mit der MOPS Datenbank nach U¨bereinstimmungen. Als Ergebnis dieser Suche wird
eine Liste der Abgeordneten zuru¨ckgegeben die dem Benutzer am a¨hnlichsten sind.
ˆ [K16]QueryFacade
Ist eine fragebeantwortende Komponente die ein Framework aus Fragebausteinen anbie-
tet damit der Benutzer komplexe, Datenbanku¨bergreifende Fragen an das System stellen
kann. QueryFacade nutzt beinahe alle vorhandenen Datenbanken und kann die Beant-
wortung von den so genannten
”
warum-Fragen“ mit Hilfe der RapidMiner Anwendung
anstossen.
ˆ [K17]FBS Graphic User Interface
Die GUI des Frontends integriert die P02 Komponenten in einer großen Anwendung.
Lucene (lucene.apache.org)
ˆ [K02]Lucene
Lucene ist eine Open Source Anwendung die in der Lage ist einen Index der Doku-
mente aufzubauen, also verantwortlich fu¨r die Zuordnung: wie oft kommt ein Wort in
184
Abbildung 2.3: JAVA Packages der Datenakquisition
welchen und wie vielen Dokumenten vor. Lucene kann zusa¨tzlich zu jedem Dokument
frei definierbare Attribute speichern.
– BTD Index
Der von Lucene Index u¨ber den Drucksachen des Bundestages, der zusa¨tzlich alle
extrahierten Meta-Daten eines Dokuments beinhaltet.
– BTP Index
Im Zuge der Informationsextraktion wurden aus den Protokollen des Bundestages
Redebeitra¨ge der Abgeordneten extrahiert, diese wurden separat als einzelne Reden
im plain-text Format gespeichert. Der BTP Index ist ein weiterer Lucene Index
der genau auf diesen Reden und ihren Meta-Daten erstellt wurde.
RapidMiner (yale.sourceforge.net)
ˆ [K06]RapidMiner
Diese am LS8 entwickelte Anwendung stellt ebenso eine eigene, ausgefeilte GUI zur
Verfu¨gung mit der Data Mining und Information Extraction Prozesse erstellt werden
ko¨nnen. Die Modell-Dateien eines Lernlaufes sollen im Repository gespeichert werden.
Eine genaue Beschreibung dieser Anwendung befindet sich im Kapitel 2.2.
2.3 Statisches Package Modell
Wir haben nun alle Komponenten kurz vorgestellt, die hier aufgefu¨hrten UML Package Dia-
gramme beinhalten die oberste Hierarchieebene der Java Packages beider Systeme. Die Dia-
gramme orientieren sich, entsprechend unserer Konvention, an den Prozessen P00 bis P02. Wie
bereits erwa¨hnt benutzen wir einige Open Source Anwendungen als Komponenten die u¨ber
public Methoden aufgerufen werden. Diese, von uns verwendeten 3rd-party Anwendungen,
stehen alle unter der GPL Lizenz auf www.sourceforge.net frei zur Verfu¨gung. Alle u¨brigen
Komponenten wurden von den Mitgliedern der Projektgruppe selbsta¨ndig entwickelt und
ko¨nnen aus dem CVS ( Concurrent Versioning System) der Projektwebseite bezogen werden.
(pg520.sourceforge.net)
185
Abbildung 2.4: Packages der Informationsextraktion.
Die von den PG-Mitgliedern in Java (Version 6) programmierten Komponenten wurden mit
der Open Source IDE Eclipse entwickelt und sind in Packages unterteilt. Gema¨ß der Java Na-
ming Convention fu¨r Packages sollen diese eindeutig, in Kleinbuchstaben, ASCII benannt sein
und mit den top-level Domains oder den La¨ndercodes des ISO Standard 3166 beginnen, ge-
folgt von Organisation, Abteilung, Projektname oder einem Eigennamen. Die Projektgruppe
hat sich fu¨r den eindeutigen Namen:
ˆ de.uni-dortmund.pg520
entschieden.
Wa¨hrend der Entwicklung wurden die einzelnen Komponenten als separate Projekte behan-
delt. Alle Komponenten besitzen eine gemeinsame Referenz auf das Repository und ein
”
Mas-
ter Projekt“ in dem sich alle importierten Libraries der Komponenten befinden. Das Repo-
sitory ist in der Entwicklungsphase ebenso ein leeres Projekt, die Daten und Datenbanken
wurden, wa¨hrend der Entwicklung, ha¨ndisch vom LS8 Fileserver in das Projekt umkopiert.
Die Struktur des Reposiory wurde also im CVS gespeichert, die Daten auf dem LS8 Server. Die
Gro¨ße des Repository und die Geschwindigkeit mit der das Repository ein- und ausgecheckt
wird, waren die wichtigsten Argumente fu¨r dieses Vorgehen.
Die Abbildung 2.3 stellt die Packages der Datenakquisition dar. Die von dem Prozess verwen-
deten Komponenten werden von [K01] AES FileWorker angesteuert. Die Abbildung 2.4 ist
a¨hnlich aufgebaut und zeigt alle beteiligten Komponenten. Zusa¨tzlich wurden einige, meis-
tens nur aus einer bis zwei Klassen bestehenden Komponenten direkt in das AES FileWorker
Projekt implementiert. Sie sind dort als Sub-Packages enthalten.
Die verwendeten 3rd-party Anwendungen sind die beiden Open-Source-Java-Bibliotheken:
ˆ Lucene - eine Bibliothek zum Erzeugen und Durchsuchen von Text-Indizes, mit der sich
Voltextsuche auf beliebigen Texten implementieren la¨sst.
186
Abbildung 2.5: Java Packages im Prozess der Fragebeantwortung.
ˆ PDFbox - eine Java PDF Bibliothek zum Erzeugen und Verarbeiten von pdf Dokumen-
ten, welche gleichzeitig Extraktion von Inhalten erlaubt.
Zusa¨tzlich wird die unter GPL lizensierte Version der Data-Minig Software: Rapid Miner (ehe-
mals Yale) von Rapid-I (www.rapid-i.com) in Kombination mit dem Information Extraction
Plug-In von Dipl.-Inf. Felix Jungermann verwendet.
Die Abbildung 2.5 zeigt die in UML modellierte Ansicht der Fragebeantwortung. Die gestri-
chelten Linien in allen Abbildungen dru¨cken die
”
benutzt“ Beziehung zwischen den Packages
aus.
2.4 Das Repository und seine Datenstrukturen
2.4.1 Das Repository
Unser System ver- und bearbeitet Dokumente und Datenbanken, es beno¨tigt also eine phy-
sikalische Lokation, ein Depot, um diese Dateien zu holen und nach der Verarbeitung wieder
abzulegen. Bei der Planung des Systems stand die Frage einer verteilten Datenhaltung im
Raum, da eine gro¨ßere Menge unabha¨ngiger Komponenten vermutet wurde. Eine verteilte
Datenhaltung ha¨tte als Konsequenz die Implementierung von Synchronisierungs- und Kom-
munikationsmechanismen. Dies ha¨tte unsere Aufwa¨nde vervielfacht und unsere Aufmerksam-
keit viel zu sehr auf diese Mechanismen gelenkt, anstatt sie in auf die anwendungskritischen
Problemen zu bu¨ndeln. Die Projektgruppe hat sich deshalb fu¨r ein simples, zentrales Daten-
depot entschieden, welches allen Komponenten bekannt ist.
Wir haben unser Datendepot frei als Repository benannt, wobei das Repository nicht viele
Gemeinsamkeiten mit einer CVS oder SVN a¨hnlichen Struktur besitzt. Wir benutzen den
Begriff in Anlehnung an das Repository Architekturmodell von Buxton, der eine zentrale,
datenhaltende Instanz beschreibt, welche aus mehreren Datenbanken besteht und gemeinsa-
me, von allen Komponenten nutzbare Datenstrukturen besitzt. Diese Form der Datenhaltung
187
Abbildung 2.6: Datenstrukturen und Datenbanken im Repository
induziert gleichzeitig die Standardisierung der Verarbeitungsprozesse. Die Grundform eines
jeden atomaren Prozesses entspricht etwa diesen drei Schritten:
ˆ Daten aus dem Repository holen,
ˆ Daten verarbeiten,
ˆ Daten ins Repository ablegen.
Diese einfache Vorgehensweise reduziert den Verwaltungsaufwand und erlaubt die Modellie-
rung la¨ngerer Prozessketten durch Hintereinander-Ausfu¨hrung der Komponenten.
2.4.2 Datenbanken und Verzeichnisse
Das Repository besteht aus Verzeichnissen und Datenbanken. Die Verzeichnisse sind nichts
anderes als Dateiordner, welche vom System erzeugte Dateien und aus dem Internet geladenen
Dokumente beinhalten. Ein Verzeichnis ha¨lt in der Regel einen bestimmten Typ von Dateien
vor. Die Entscheidung, welche Verzeichnisse angelegt wurden, ha¨ngt von der Struktur des
Anwendungsgebietes und den zur Informationsextraktion notwendigen Verarbeitungsschritte.
Wie bereits erwa¨hnt sammeln wir extrahierte Informationen in Datenbanken, es ist nicht
weiter u¨berraschend, dass sich dieses ebenfalls im Repository befinden. Die Abbildung 2.6
zeigt die U¨bersicht der vorhandenen Verzeichnisse und Datenbanken.
Die prozessorientierte Ausrichtung des Systems kann auch in der Struktur des Repository
nachvollzogen werden. Die Richtungspfeile der Abbildung zeigen die Konvertierung der Do-
kumente aus einem Dateiformat ins Na¨chste. Die verbundenen Verzeichnisse zeigen eben die-
sen Weg der Konvertierung. Zusa¨tzlich wird der Informationsfluss aus den Textdokumenten
188
zu den Datenbanken dargestellt. Wie man sieht, spielen die aus den PDF Quellen erzeugten
Textdokumente eine zentrale Rolle im System. Sie sind der Ursprung des verzweigten Ex-
traktionsprozesses, dementsprechend wirkt sich ihre Qualita¨t auf die Gu¨te der nachfolgenden
Ergebnisse.
Wir wollen an dieser Stelle die an dem Konvertierungsweg beteiligten Verzeichnisse beschrei-
ben:
ˆ [V01] PDF Dokumente
Dieses Verzeichnis entha¨lt alle aus dem Internet geladenen PDF Dateien des Deutschen
Bundestages. In seinen Unterverzeichnissen werden die drei Dokumenttypen gespeichert,
die von dem IT-Dienstleister des dt. Bundestages im Internet bereitgestellt worden sind.
Die drei Typen sind Drucksachen (BTD), Protokolle (BTP) und Drucksachenba¨nder
(IDX).
ˆ [V02] TXT Dokumente
Die PDF Quellen ko¨nnen nicht ohne weiteres von einem Informationssystem verar-
beitet werden. Sie wurden in einem Stapelverarbeitungslauf aus dem pdf-Format in
ein gewo¨hnliches ASCII Text Format konvertiert. Diese konvertierten Dateien wurden
in diesem Verzeichnis gespeichert, wobei die Struktur der Unterverzeichnisse erhalten
blieb.
ˆ [V03] WTF Dokumente
Das
”
Wordwise Tagged“ Format (WTF) entha¨lt pro Wort zusa¨tzliche Informationen,
na¨mlich die annotierte Named Entity des Wortes. Dieses Verzeichnis entha¨lt alle WTF
Dokumente die aus den Text Dokumenten erzeugt wurden.
ˆ [V04]XML Dokumente
Die Protokolle des Bundestages beinhalten Redebeitra¨ge der Abgeordneten. Das XML
Dokumente Verzeichnis entha¨lt die aus den Text Dokumenten extrahierten Reden, die
gleichzeitig in eine XML Dokument u¨berfu¨hrt worden sind. In diesen XML Dokumen-
ten befinden sich alle Meta-Daten einer Rede, also Informationen u¨ber den Redner,
Wortanzahl, Unterbrechungen usw.
Aus den PDF Dokumenten des Bundestages wurden zusa¨tzlich einige Datenbanken erzeugt,
die mit Meta-Informationen zu den Dokumenten gefu¨llt worden sind.
ˆ [D00] DOC Liste
Dies ist eine vom Crawler [K00] verwaltete Datenbank der bereits erfassten Dokumente.
ˆ [D02] BTD2BTP
Diese XML Datenbank entha¨lt alle Relationen zwischen den Drucksachen und Proto-
kollen. Sie listet alle Vorkommen einer Drucksache in den vorhandenen Protokollen.
ˆ [D03] BTP XML
Entha¨lt alle Redner und Daten der Protokolle. Wird als Datenquelle fu¨r die Erzeugung
der XML Dokumente [V04] sowie des Lucene Index u¨ber den Reden beno¨tigt.
189
ˆ [D04] BTD XML
Wie die bereits beschriebene BTP XML ist diese Datenbank auch eine notwendige
Voraussetzung zur Erzeugung einer nachfolgenden Datenbank. BTD XML wird vom
BTD Builder [K07] erzeugt und entha¨lt alle Meta-Daten zu einer Drucksache.
Unser System nutzt Lucene als zentralen Indexer. Die Zuordnung zwischen den Wo¨rtern
und Dokumenten wird also in zwei Lucene Instanzen gespeichert. Damit die Anfragen zu
Dokumenten nicht u¨ber mehrere Datenbanken ausgefu¨hrt werden mu¨ssen, werden alle Meta-
Daten ebenfalls als Attribute eines Dokuments in Lucene gespeichert. Die beiden folgenden
Lucene Indizes werden also jeweils aus den Text und XML Dokumenten sowie den beiden
Vorga¨nger Datenbanken erzeugt.
ˆ [D01a] BTP Index
Dieser Lucene Index wurde auf den Reden [V04] des Deutschen Bundestages aufgebaut,
zusa¨tzlich wurden die Meta-Daten aus der BTP XML [D03] genutzt.
ˆ [D01b] BTD Index
Der BTD Index wurde auf den Drucksachen des Bundestages erstellt. Zusa¨tzlich wurde
BTD Index [D04] benutzt um in Lucene zu jedem indexierten Dokument die entspre-
chenden Meta-Daten zu speichern.
Wir beno¨tigen drei weitere Datenbanken, deren Inhalte aus HTML Webseiten erzeugt wor-
den sind. Die erzeugenden Komponenten haben hierfu¨r die entsprechenden Seiten abgeru-
fen und mit Hilfe von regula¨ren Ausdru¨cken und selbst geschriebenen Parsern verarbeitet.
Unglu¨cklicherweise ist die Lebensdauer der Inhalte einer Webseite in Zeiten von Content Ma-
nagement Systemen sehr kurz. Sobald sich also das Layout einer Webseite, oder ihre Inhalte
a¨ndern, werden auch die von uns geschriebenen Komponenten schlechter Arbeiten.
ˆ [D05] BTL XML
Die Bundestag-Lookup Datenbank entha¨lt generelle Informationen zum Deutschen Bun-
destag, also Informationen zur Sitzverteilung, Parteinamen, Ministerposten und Regie-
rungen. Diese Informationen sind nach Wahlperioden geordnet und in einer umfangrei-
chen XML vorgehalten. Diese generellen Infos werden von vielen Komponenten genutzt,
sie sind vor allem bei der Beantwortung statistischer Fragen sehr nu¨tzlich.
ˆ [D06] MOPS XML
Die Members of Parlament Datenbank ist eine aus den Biographien extrahierte Da-
tenbank mit allen Informationen zu den Abgeordneten des Deutschen Bundestages.
Zusa¨tzlich wurden Informationen zu den Ministern und Regierungsmitgliedern aus der
Wikipedia.org extrahiert und eingefu¨gt.
ˆ [D07] AUSS XML
AUSS XML ist eine weitere Datenbank die aus den Seiten des Bundestages erzeugt
worden ist. In ihr sind alle Daten zu den Ausschu¨ssen des Deutschen Bundestages ge-
speichert. Diese Datenbank ist also eine nach Wahlperioden geordnetes XML Dokument
der Ausschu¨sse und ihrer Mitglieder.
Einige Komponenten sind auf die Existenz weitere Verzeichnisse angewiesen:
190
ˆ [V05] NER Experimente
RapidMiner [K18 ]beno¨tigt neben den Daten die verarbeitet werden sollen auch so
genannte Experiment Dateien um die Verarbeitung zu Steuern. Dieses wird benutzt
Verzeichnis um diese Prozessketten im XML Format abzulegen.
ˆ [V06] Event Schemas
Im Zuge der Projektgruppe wurde ein XML Schema erstellt um die verschiedenen Ereig-
nisse zu identifizieren. Genauer gesagt wurden in diesen XML Schemas die Stichwo¨rter
und Relationen definiert an denen ein System die Ereignisse erkennen ko¨nnte. Leider ist
die entsprechende Komponente, die diese Verarbeitung bewa¨ltigen sollte, nicht erstellt
worden.
ˆ [V07] Event Extraktion
In diesem Verzeichnis sollen die extrahierten Ereignisse gespeichert werden, die Ergeb-
nisse der Extraktion von Abstimmungen wurden hier bereits abgelegt.
ˆ [V08] QueryFacade Datensa¨tze
Das System zur Fragebeantwortung ist in der Lage Fragen zu den Ursachen von be-
stimmten Abfragen zu beantworten. In der QueryFacade [K16] Komponente werden die-
se Fragen an RapidMiner [K18] weitergereicht. RapidMiner beno¨tigt als Eingabe einen
speziell formatierten Datensatz, der aus den Daten verschiedener Datenbanken kon-
struiert wird. In diesem Verzeichnis werden diese Datensa¨tze von RMDatensatz Builder
[K05] abgelegt.
ˆ [V09] Wo¨rterbu¨cher
Komponenten die natu¨rlich sprachliche Texte verarbeiten sollen, beno¨tigen Wo¨rterbu¨cher
zur Auflo¨sung von Ambiguita¨ten. In diesem Verzeichnis liegen alle von den Komponen-
ten genutzten Wo¨rterbu¨cher.
2.4.3 Datenstrukturen und Dateiformate
Ein Repository setzt voraus, dass die Anzahl der verwendeten Dateiformate und Datentypen
u¨berschaubar bleibt. Deshalb haben wir uns, entsprechend der Vorgabe, an XML als zentrales
Dateiformat gehalten.
ˆ XML eXtended Markup Language
Wir verwenden das XML Format, mit den ihm inhera¨nten Ba¨umen als einen einfachen
Weg um strukturiert Informationen zu speichern. Wir bezeichnen deshalb alle solche
XML Dateien die innerhalb des Repository hauptsa¨chlich diesem Zweck dienen als Da-
tenbanken.
Es folgt eine kurze Liste der verwendeten XML Datenbanken:
– [D02] BTD2BTP
– [D03] BTP XML
– [D04] BTD XML
– [D05] BTL XML
– [D06] MOPS XML
191
– [D07] AUSS XML
Auf der anderen Seite reichern wir gewo¨hnliche unstrukturierte Textdokumente mit
Hilfe von XML Tags an. Diese angereicherten Dokumente (a.k.a. enriched documents)
ko¨nnen von den Komponenten einfacher verarbeitet werden, und bleiben selbst fu¨r das
menschliche Auge lesbar.
– [V04] Aus den Protokollen extrahierte Redebeitra¨ge.
– [V04] Vom RapidMiner NE annotierten Drucksachen.
Neben XML werden folgende Dateiformate als Dokumentformate gespeichert.
ˆ PDF Portable Document Format
Alle Dokumente des Bundestages sind in dem dem von Adobe entwickelten Dateiformat
vorhanden. Die verschiedenen Typen der Bundestagsdokumente wurden bereits in der
Beschreibung des Anwendungsgebiets in aller Ausfu¨hrlichkeit behandelt, wir wollen hier
die vorhanden Typen anreissen:
– [V01] PDF Version der Drucksachen des Deutschen Bundestages
– [V01] PDF Version der Protokolle des Deutschen Bundestages
– [V01] PDF Version der Drucksachenba¨nder des Bundestages
ˆ TXT Plain Text Format
Diese im reinem Textformat vorliegenden Dokumente sind das Ergebnis der Dokumen-
takquisition [P00]. Wir konvertieren alle im PDF Dokumente Verzeichniss [V01] lie-
genden Dateien in dieses Format. Zusa¨tzlich sind die Wo¨rterbu¨cher in diesem Format
abgespeichert.
– [V02] Drucksachen des Deutschen Bundestages
– [V02] Protokolle des Deutschen Bundestages
– [V09] Wo¨rterbu¨cher
ˆ WTF Word Tagged Format
Dieses Format wird beno¨tigt als Eingabe fu¨r die Information Exraction Komponente
des RapidMiner [K18]. Die charakteristische Eigenschaft dieses Formats ist die Tokeni-
sierung der Texte. Jedes Zeile der Datei wird aus einem Tupel gebildet der aus einem
einzelnen Wort, gefolgt von einem Tag der Named Entity Notation, besteht. Satzenden
werden als Leerzeilen markiert.
Wir nutzen folgende automatisch im AnnotationTool [K04] erzeugte Typen der WTF
Dokumente:
– [V03] Drucksachen des Deutschen Bundestages
– [V03] Protokolle des Deutschen Bundestages
– [V07] Abstimmungen aus den Protokollen des Dt. Bundestages.
192
Zusa¨tzlich gibt es zwei Typen von Dokumenten die von einem Benutzer im Annotati-
onTool [K04] per Hand markiert worden sind. Diese sind ebenso als Eingabe fu¨r den
RapidMiner [K18] gedacht, allerdings wird auf dieser Eingabe gelernt um im na¨chsten
Durchlauf nicht-markierte Dokumente zu markieren.
– [V03] Drucksachen und Protokolle fu¨r den NER Learner
– [V07] Protokolle fu¨r den Learner zur Extraktion von Abstimmungen
ˆ CSV Character Separated Values
Der Crawler [K00] verwaltet diese Semikolon separierten Listen um A¨nderungen im
Dokumentarchiv auf der Webseite des Bundestages nachzuhalten. Dem entsprechend
werden nur dem System unbekannte, oder gea¨nderte Dateien heruntergeladen.
– [D00] Drucksachen des Deutschen Bundestages
– [D00] Protokolle des Deutschen Bundestages
– [D00] Drucksachenba¨nder des Bundestages
ˆ AML RapidMiner Experimente
RapidMiner [K18] ist in der Lage innerhalb seiner GUI Prozesse abzubilden. Durch Hin-
tereinanderschaltung von Komponenten sind komplexe Abla¨ufe mo¨glich. Diese Abla¨ufe
ko¨nnen dauerhaft als AML Dateien gespeichert werden um zu einem spa¨teren Zeitpunkt
das selbe Experiment noch einmal, ohne Benutzerintervention auszufu¨hren.
– [V05] NER Experimente
– [V07] Event Extraction Experimente
– [V08] Experimente fu¨r die QueryFacade Datensa¨tze
ˆ DAT Semikolon separierte RapidMiner Datensa¨tze
RapidMiner [K18] beno¨tigt als Eingabe eine Semikolon separierte Tabelle in der die
Daten zeilenweise aufgefu¨hrt sind.
– [V08] QueryFacade Datensa¨tze zur Beantwortung der Warum-Fragen.
2.4.4 Physikalische Struktur
Das Repository besteht physikalisch aus einem Verzeichnis im Dateisystem des Rechners
auf dem das System installiert wurde. Datenbanken und Dateisammlungen befinden sich in
den Unterverzeichnissen. Wie u¨blich fu¨r Verzeichnisse im Dateisystem eines Rechners ist die
Struktur unseres Repository ein Baum mit /data als das Wurzelverzeichnis unseres Repository.
Alle weiteren Bestandteile befinden sich in den Unterverzeichnissen von /data.
Im /data Verzeichnis befinden sich folgende Unterverzeichnisse
/ ascii - [V02] TXT Dokumente
/ btd - Drucksachen des Bundestages
In den Unterverzeichnissen befinden sich die nach Wahlperioden geordneten Do-
kumente.
193
/ btp - Sitzungsprotokolle des Bundestages
Genau so wie die Drucksachen sind die Protokolle auch nach Wahlperioden geord-
net.
/ aus-lookup - [D07] AUSS XML
In diesem Verzeichnis liegt die Datenbank mit Informationen u¨ber Ausschu¨sse des Bun-
destages.
/ btd-index - [D04] BTD XML
/ btp-index - [D03] BTD XML
/ btpcontent-abstimmung - [V07] EventExtraktion
/ config - Konfigurationsdateien des Systems
/ dictionaries - [V09] Wo¨rterbu¨cher
/ events - [V06] Event Schemas
/ experiments - [V05] NER Experiments
/ import - [V01] PDF Dokumente
/ btd - Drucksachen des Bundestages
In den Unterverzeichnissen befinden sich die nach Wahlperioden geordneten Do-
kumente.
/ btp - Sitzungsprotokolle des Bundestages
Genau so wie die Drucksachen sind die Protokolle auch nach Wahlperioden geord-
net.
/ idx - Drucksachenba¨nder des Bundestages
/ lucene-index - [D01b] BTD Index
In diesem Verzeichnis liegt der Lucene Index der Drucksachen und Protokolle.
/ lucene-speeches - [D01a] BTD Index
Hier befindet sich der Lucene Index fu¨r die Redebeitra¨ge der Abgeordneten.
/ mops - [D06] MOPS XML
/ nerd - [V03] WTF Dokumente
194
/ btd - Drucksachen des Bundestages
/ btp - Sitzungsprotokolle des Bundestages
/ relationen - [D02] BTP2BTD
/ speech-extraction - [V04] XML Dokumente
Hier befinden sich nach Wahlperioden geordnete Redebeitra¨ge als XML Dokumente, die
von der SpeechExtraction [K09] Komponente erstellt wurden.
/ xml - [V04] XML Dokumente
Hier befinden sich die von WTF nach XML konvertierten, annotierten Drucksachen und
Protokolle.
Diese Verzeichnisstruktur ist sie wa¨hrend der Entwicklung gewachsen und wir haben uns, da
es sich um einen Prototypen handelt, nicht um durchgehende Konsistenz zwischen Verzeichnis
und Komponentennamen bemu¨ht. Es wurde jedoch stets dafu¨r gesorgt, dass jede vorhandene
Komponente die Pfade zu den von ihr beno¨tigten Datenbanken und Verzeichnissen kennt.
2.5 Prozess Modell und Beziehungen zwischen den Subsystemen
Dieser Abschnitt beschreibt die Zusammenha¨nge zwischen den Komponenten und den Daten-
banken und dient der allgemeinen U¨bersicht im System. Die dargestellten Zusammenha¨nge
werden nur grob an Hand einfacher Prozessdiagramme erla¨utert. Detaillierte Beschreibungen
der Funktionsweise vorhandener Komponenten befinden sich in den darauf folgenden Kapi-
teln. Als Konvention zur Prozessbeschreibung wird auf SDL zuru¨ckgegriffen.
2.5.1 Grundsa¨tzliches zu atomaren Prozessen
Prozesse sind in Bezug auf die Verarbeitung der Datenstrukturen mo¨glichst atomar und in
einzelnen Komponenten gekapselt. Die Komponenten der Repository Architektur sind darauf
ausgelegt Dateien aus dem Repository zu holen, zu verarbeiten und ggf. wieder im Reposi-
tory abzulegen. Das vereinfacht die vorhanden Schnittstellen und macht das System robus-
ter gegenu¨ber A¨nderungen in der Programmstruktur. A¨nderungen der Datenstrukturen sind
natu¨rlich fu¨r alle Systeme mit vergleichbaren Aufwa¨nden verbunden, unabha¨ngig von der
Architektur.
Da die Dateien nicht erst bei der Benutzeranfrage verarbeitet werden, sondern a priori, ist
diese IO-lastige Art Daten zu verarbeiten nicht weiter schlimm. Zusa¨tzlich ist sie gegenu¨ber
Programmabbru¨chen robust, da man in dem Prozessschritt und in der Datei weitermachen
kann, an der die Verarbeitung abgebrochen wurde.
195
Abbildung 2.7: P00 - Datenakquisition
2.5.2 Datenakquisition
Die Abbildung 2.7 billdet den Prozess der Datenakquisition als Teil des AES Subsystems
ab. Der Prozess wird hier nur kurz angerissen und selbstversta¨ndlich im spa¨teren Kapitel
detailiert beschrieben. Deshalb zeigen wir hier nur das Zusammenspiel des AES Fileworker
[K01] mit dem Repository. Der Fileworker ist fu¨r die Ausfu¨hrung der Prozessschritte und
die Koordination der beteiligen Komponenten zusta¨ndig. A¨hnlich einem Batch Lauf la¨dt
der Crawler [K00] die noch nicht erfassten Dokumente, erzeugt die entsprechenden Eintra¨ge
in seine Liste und u¨bergibt sie an den Fileworker. Die Dokumente werden im Repository
gespeichert. Im na¨chsten Schritt werden die Dokumente zuerst aus dem pdf-Format in Plain
Text und schliesslich in das wtf-Format konvertiert. Nach jeder Konvertierung werden die
Ergebnisse in Verzeichnissen gespeichert.
2.5.3 Prozesse der Informationsextraktion
Die Informationsextraktion ist eine ins gesamt komplexe Aufgabe, die wir auf einfachere,
teilweise unabha¨ngige Prozesse aufgeteilt haben. Sie besteht aus fu¨nf Unterprozessen und kann
zum teil parallel verarbeitet werden. Sollte das System auf verschiede Server aufgeteilt werden,
so besteht dadurch die Mo¨glichkeit zumindest paarweise die Prozesse zu verarbeiten. Parallele
Verarbeitung ist logischerweise immer dann Mo¨glich wenn die Quell und Ziel Verzeichnisse
oder Datenbanken unterschiedlich sind.
Informationen u¨ber den Bundestag, Ausschu¨sse und die Abgeordneten werden in drei XML
Datenbanken vorgehalten. Der Aufbau dieser Datenbanken ist in der Abbildung 2.12 dar-
gestellt. Diese drei Prozessschritte sind zwar im Prinzip von einander Unabha¨ngig, sollten
aber in der dargestellten Reihenfolge ablaufen. Zumindest bei der Initialbefu¨llung der Da-
tenbanken. MOPS XML [D06] ist hierbei die zentrale Datenbank, welche die Personen ID’s
verwaltet.
196
Abbildung 2.8: [P01] - Erstellung der Datenbanken
Abbildung 2.9 zeigt die Verarbeitung der Dokumente in der Informationsextraktion. Ausge-
hend von den in Plain Text konvertierten Dateien werden drei unterstu¨tzende Datenbanken
aufgebaut aus denen im spa¨teren Verlauf, und zwar beim Aufbau der Indizes Informationen
eingeholt werden. BTD2BTP [D02] wird beno¨tigt um in Lucene [K02] die Beziehungen zwi-
schen den Drucksachen und Protokollen herzustellen. BTD XML [D04] und BTP XML [D03]
werden mit Meta-Daten befu¨llt. Lucene [K02] erzeugt nicht nur den Index u¨ber den Dokumen-
ten, es speichert auch diese Meta-Daten als Attribute zu jedem Dokument. Abbildung 2.11
verdeutlicht diese Beziehung. Schließlich extrahiert die SpeechExtraction [K09] Komponente
die Reden aus den Protokollen und legt sie als XML annotierten Texte ab.
Der u¨ber eine eigene GUI verfu¨gende AES Fileworker [K01] spielt bei der Verarbeitung der
Dokumente wieder eine zentrale Rolle. Diese Komponente startet die datenbankerzeugenden
Komponenten und u¨berwacht die Ausfu¨hrung.
Die Named Entity Recogition (NER) spielt bei der Informationsextraktion unseres Systems
eine sehr wichtige Rolle. Auf diesem Prozess baut die gesamte, weitere Verarbeitung, welche
spa¨ter fu¨r die Extraktion der Relationen notwendig ist. In der NER werden die ins WTF
Dateiformat konvertierten Dokumente in einem Lauf vom RapidMiner [K18] annotiert. Der
in der Abbildung 2.10 dargestellte Prozess induziert die Verantwortung des AES Fileworker
[K01] fu¨r die Schnittstelle zum RapidMiner [K18]. Diese Stapelverarbeitung u¨berschreibt die
WTF Dokumente und u¨bergibt bei Erfolg die Kontrolle wieder an den Fileworker. Im letzen
Schritt des Prozesses werden die Dokumente nochmals ins XML Format konvertiert. Dies
erzeugt den Corpus fu¨r die Relation Extraction zwischen den Named Entities.
Die Grundlage jeder Stichwortsuche in den Dokumenten ist ein invertierter Index, also die
Zuordnung zwischen den Wo¨rtern und Dokumenten. Dessen Aufbau wird aus dem AES Fi-
leworker [K01] angestossen und von Lucene [K02] durchgefu¨hrt. Abbildung 2.11 zeigt den
Aufruf von Lucene und die Datenquellen die fu¨r den Aufbau beno¨tigt werden.
Der dargestellte Prozess zeigt beide Lucene Instanzen die den jeweils eigenen Index aufbauen.
Wir benutzen einen großen Index u¨ber alle Drucksachen und Protokolle, sowie in der zweiten
Instanz einen kleineren Index u¨ber den Redebeitra¨gen der Abgeordneten. Gleichzeitig wer-
197
Abbildung 2.9: [P01] - Verarbeitung der Dokumente
Abbildung 2.10: [P01] - Named Entity Recognition
198
Abbildung 2.11: [P01] - Aufbau der Indizes
den zu jedem Dokument, welches gerade verarbeitet wird, die zuvor extrahierten Meta-Daten
aus den Datenbanken abgerufen und gespeichert. Lucene bildet ein eigenes Objekt als Re-
pra¨sentation eines indexierten Dokuments, diesem Objekt werden die Attribute hinzugefu¨gt.
199
Abbildung 2.12: [P01] - QueryFacade Datensa¨tze
Im letzten, finalen Prozess werden aus allen Datenbanken, Semikolon separierte Datensa¨tze fu¨r
die RapidMiner [K18] Eingabe generiert. Die zusta¨ndige Komponente: RMDatensatz Builder
[K05] erstellt fu¨r jede Wahlperiode eine dat-Datei mit der die Beantwortung der so genannten
”
Warum-Fragen“ mo¨glich ist.
2.5.4 Fragebeantwortung
Das Subsystem der Fragebeantwortung ist aus Ideen der Projektgruppe und der PG-Leitung
gewachsen. Einige Komponenten wurden zum Campusfest der TU Dortmund entwickelt um
die Attraktivita¨t der Anwendung fu¨r das Publikum beurteilen zu ko¨nnen. Die Entwicklung
des FBS und seiner Komponenten war stark an die Erstellung der Datenbanken gekoppelt.
Da MOPS XML [D06] und der Index BTDIndex [D01b] unsere ersten Datenbanken waren,
ist es nicht weiter verwunderlich, dass MopsQuery [K10a] und der EventCutter [K14] unsere
zuerst entwickelten Komponenten waren.
Urspru¨nglich wurde der Index von einer Lexical-Tree Komponente verwaltet, diese fiel jedoch
dem Java Performance- und Speicherhunger zum Opfer. Der alte Index wurde deshalb gegen
den ma¨chtigeren Lucene Index ausgetauscht, der neben RapidMiner, zentrale Rolle in der
Fragebeantwortung spielt.
Auf den folgenden Seiten wollen wir die einzelnen, von einander unabha¨ngigen Prozesse kurz
skizzieren. In allen Abbildungen verbinden Pfeile die aufeinander folgenden Prozessschritte.
Durchgezogene Linien symbolisieren die Verwendung einer Datenbank durch einen Prozess.
Das FBS kann auf Grund seiner Prozesse als Frontend auf einem oder mehreren Servern
installiert werden. Parallelita¨t kann erreicht werden durch Auslagerung der Komponenten
und der dazugeho¨renden Datenbanken auf separate Maschinen.
200
Abbildung 2.13: [P02] - Prozesse der Stichwortsuche
Abbildung 2.14: [P02] - Fragebeantwortung mit MOPS Query
Die Stichwortsuche wird u¨ber ein einfaches Formular in der GUI gestartet. Die Tokens der
Benutzereingabe werden an den EventCutter [K14] weitergeleitet, der wiederum Lucene [K02]
mit dieser Eingabe versorgt. Lucene liefert eine Liste aus Pfaden zu den relevanten PDF
Dokumenten. Der EventCutter o¨ffnet die Dokumente und schneidet die Passagen aus, in
denen die Stichwo¨rter vorkommen. Dieses Passagen und ein Verweis auf das PDF werden
als Ausgabe fu¨r den Benutzer dargestellt. Abbildung 2.13 zeigt den groben Aufbau aus GUI
[K17], EventCutter [K14], Lucene [K02] und die beteiligten Indizes.
Die Abbildung 2.14 zeigt die Funktionalita¨t der MOPS Query [K10a]. Diese Komponente stellt
die Algorithmen bereit um die MOPS XML [D06] Datenbank zu durchsuchen und einfache
Fragen zu den Abgeordneten des Bundestages zu stellen.
201
Abbildung 2.15: [P02] - Partynator
Abbildung 2.16: [P02] - Aufbau des Dossiers als Prozesse
Zum Campusfest der Technischen Universita¨t Dortmund wurde eine Komponente geplant
und implementiert, mit der das Publikum eigene Daten mit den Daten der Abgeordneten
vergleichen konnte. Abbildung 2.15 zeigt diese Partynator [K15] genannte Komponente. Par-
tynator stellt Formularfelder bereit, die den Feldern in der MOPS XML [D06] entsprechen.
Der Benutzer ist angehalten diese mit eigenen Daten auszufu¨llen. Beim Absenden dieser Par-
tynator Abfrage wird die gro¨ßte A¨hnlichkeit zu einem oder mehreren Abgeordneten errechnet
und daraus die mo¨gliche Bereitschaft der Wahl einer Bundestagspartei als Kreisdiagramm
dargestellt. Natu¨rlich werden die vom Benutzer eingegebenen Daten nicht gespeichert oder
weiterverarbeitet.
Das Dossier ist eine Komponente die aus verschiedenen Datenquellen alle verfu¨gbaren Infor-
mationen zu einem Abgeordneten sammelt und darstellt. In der Abbildung 2.16 wird dieser
Prozess an Hand von wenigen Schritten kurz skizziert. Die GUI stellt eine alphabetisch geord-
nete Liste der Abgeordneten dar und bietet zusa¨tzlich ein Suchformular mit dem der Benutzer
direkt nach dem Abgeordneten suchen kann. Im ersten Schritt werden die allgemeinen Infor-
mationen u¨ber den Abgeordneten in der MOPS XML [D06] Datenbank nachgeschlagen. Wor-
auf die Listen der Drucksachen und Reden des Abgeordneten bei Lucene angefragt werden.
Im letzten Schritt, also direkt vor der Darstellung der Daten wird die Google Bilddatenbank
nach einem Bild des Abgeordneten befragt. Die gesammelten Informationen werden abha¨ngig
von der Wahlperiode dargestellt.
202
Abbildung 2.17: [P01] - QueryFacade und die
”
Warum“-Fragen
Abbildung 2.17 zeigt den Ablauf der komplexen, datenbanku¨bergreifenden Anfragen die mit
QueryFacade [K16] beantwortet werden. QueryFacade bildet eine Schicht zwischen Datenban-
ken und der eigentlichen Fragebeantwortung, welche die XML Datenbanken und die Lucene
Ausgaben abstrahiert. Damit ist der Benutzer in der Lage strukturierte, SQL-a¨hnliche Ab-
fragen auf allen vorhandenen Datenbanken. Der erste Teil des Prozesses beantwortet eben
diese strukturierten Fragen. Zusa¨tzlich besteht die Mo¨glichkeit nach den Ursachen fu¨r ein
Ergebnis zu fragen. Hierfu¨r werden an Hand der vorhin zur Beantwortung genutzten Daten,
entsprechende Datensa¨tze aus dem QF Datensa¨tze [V08] Verzeichnis geladen und mit einer
Anfrage an RapidMiner [K18] u¨bergeben. RapidMiner erstellt eine Antwort und diese wird
von QueryFacade in der GUI dargestellt.
Wie bereits erwa¨hnt ist dies nur eine grobe Einfu¨hrung in die Komponenten und Abla¨ufe
innerhalb des Systems. Die Komponenten werden noch mal ausfu¨hrlich in den folgenden
Kapiteln beschrieben. Den eigen entwickelten Komponenten ist ein Kapitel am Ende des
Projektberichts gewidmet.
203

3 Datenakquisition
In Kapitel 1.12.4 wurde bereits das Format der Dokumente vorgestellt, welche wir zur Wei-
terverarbeitung zur Verfu¨gung stehen haben. Mit diesen PDF-Dateien ko¨nnen wir in den
weiteren Schritten aber nicht weiterarbeiten, deshalb mu¨ssen diese in ein fu¨r unsere Weiter-
verarbeitung sinnvolles Format konvertiert werden.
3.1 Corpus-Erstellung
Zuna¨chst mu¨ssen alle Daten, aus denen der Corpus erstellt werden soll, lokal vorliegen. In
unserem Fall werden also alle Drucksachen des Deutschen Bundestages, sowie alle Plenarpro-
tokolle des Deutschen Bundestages im PDF-Format beno¨tigt. Aus diesen soll nun ein Corpus
erstellt werden, mit dem das System weiterarbeiten kann.
Das Herunterladen der Dokumente soll automatisch geschehen, wie in Kapitel 3.1.3 darge-
stellt, dies soll u¨ber einen Crawler erzielt werden. Dies ist alleine schon sinnvoll, da auf diese
Weise das automatische mitaufnehmen neuer Dokumente leichter zu realisieren ist.
3.1.1 Umwandlung von PDF zu regular ASCII
In Abbildung 3.1 ist zu sehen, wie die Umwandlung von PDF zu regular ASCII vorgenommen
wird.
Zuna¨chst wird der eigentliche Umwandlungsschritt von PDF zu Ascii mit Hilfe der PDF-
Box vorgenommen. PDFBox ist eine Open-Source Java PDF-Bibliothek und hilft dabei, mit
PDF-Dokumenten arbeiten zu ko¨nnen. Mit Hilfe der PDFBox ist es mo¨glich den Inhalt der
PDF-Dokumente zu extrahieren. Diese musste jedoch fu¨r uns angepasst werden, da ihre ei-
gentliche Version zum Teil sehr schlechte Ergebnisse fu¨r die PDF-Dateien des Bundestages
erzielt hat.
Nach diesem Hauptumwandlungsschritt werden im Anschluss diverse Textbereinigungen durch-
PDF
PDF – 
Box
Regular Ascii
(UTF-8)
Ascii
Steuerzeichen 
entfernen
(z.B. Tab)
Worttrennung 
entfernen
Zeilenende – 
Normalisierung 
„\r\n“
Abbildung 3.1: PDF nach regular Ascii
205
Abbildung 3.2: Ausschnitt einer Drucksache im PDF-Format
gefu¨hrt. Es wird zum einen eine Zeilenenden-Normalisierung vorgenommen. Das bedeutet,
dass alle Zeilenenden auf \r\n umgea¨ndert werden, um eine einheitliche Formatierung zu be-
kommen.
Desweiteren werden sa¨mtliche Steuerzeichen entfernt. Das ko¨nnen z.B. Tabulatoren oder meh-
rere Leerzeichen hintereinander sein. Diese sind fu¨r unsere weitere Verarbeitung unnu¨tze Infor-
mationen, da sie nur die Formatierung im PDF-Dokument betrafen und sie fu¨r unsere weitere
Verarbeitung eher hinderlich sind. Fu¨r diese wird lediglich eine reine Textversion beno¨tigt.
Schließlich mu¨ssen alle Worttrennungen entfernt werden. Dies ist ein sehr wichtiger Schritt
um spa¨ter mit den Dokumenten arbeiten zu ko¨nnen. Zum einen wu¨rde ohne diesen Schritt
ein Wort wie Bundestag nicht gefunden, wenn es mit Bundes- tag im Dokument enthalten
wa¨re und zum anderen wu¨rden alle vorhandenen Trennungen als zwei eigene Wo¨rter indexiert
werden.
Nachdem alle diese Umwandlungsschritte vorgenommen wurden, soll die nun regula¨re Ascii-
Datei gespeichert und mit Lucene indexiert werden.
Beispielhafte Umwandlung einer PDF-Datei nach regular ASCII: In Abbildung 3.2 ist ein
Auszug der, die PDF-Datei darstellt, die diesem Beispiel zu Grunde liegt.
Nachdem alle
”
PDF zu Ascii“-Transformationen vorgenommen wurden, ist der in Abbildung
3.3 zu sehende Text entstanden.
In diesem Dokument wurden einige Zeilenendennormalisierungen vorgenommen. Eine z.B.
zwischen der zweiten und der dritten Zeile. Bereits in der ersten Zeile ist zu sehen, dass
dort einige Steuerzeichen zwischen
”
Deutscher Bundestag“ und
”
Drucksache 16/1“ entfernt
wurden.
Bei der Textpassage
”
zuletzt gea¨ndert laut Bekanntmachung vom 12. Juli 2005“ ist eine
Entfernung einer Worttrennung vorgenommen worden. So wurde das Wort
”
Bekanntmachung“
im PDF-Dokument noch
”
Be- kanntmachung“ geschrieben.
206
Deutscher Bundestag Drucksache 16/1
16. Wahlperiode 18. 10. 2005
Antrag
der Fraktionen CDU/CSU, SPD, FDP, DIE LINKE. und BU¨NDNIS 90/DIE GRU¨NEN
Weitergeltung von Gescha¨ftsordnungsrecht
Der Bundestag wolle beschließen:
Fu¨r die 16. Wahlperiode werden u¨bernommen:
die Gescha¨ftsordnung des Deutschen Bundestages einschließlich ihrer Anlagen,
soweit sie vom Deutschen Bundestag zu beschließen sind, in der Fassung der
Bekanntmachung vom 2. Juli 1980 (BGBl. I S. 1237), zuletzt gea¨ndert laut
Bekanntmachung vom 12. Juli 2005 (BGBl. I S. 2512), mit folgender Maßgabe:
’
In § 18 wird die Angabe
”
§44a“ durch die Angabe
”
§ 44b“ ersetzt.‘;
Abbildung 3.3: Die Drucksache nach der Umwandlung in das regular ASCII Format
Rafaels RM  -  O p erator
Regular Ascii
(UTF-8) I e_ p lugin
Satzw eise 
formatieren
Ascii to 
WTF
U mw andlung zu WTF
Abbildung 3.4: regular Ascii ins WTF-Format fu¨r das RapidMiner ie-Plugin
3.1.2 Umwandlung von regular ASCII zu WTF
In Abbildung 3.4 ist zu sehen wie die Umwandlung von regular ASCII zu WTF vorgenommen
wird. Dieses Format wird als Eingabe fu¨r das RapidMiner ie-Plugin beno¨tigt.
Als Eingabe dient in diesem Schritt das im vorangegangenem Abschnitt erla¨uterte regular
Ascii Format. Dieses soll nun in das
”
Wort-Tag“-Format (WTF) konvertiert werden, um z.B.
mit dem ie-Plugin NE’s labeln zu ko¨nnen.
Dabei wird wie folgt verfahren: Zuna¨chst wird das Dokument Satzweise formatiert, da spa¨ter
im WTF-Format zwei Sa¨tze durch eine Leerzeile von einander getrennt werden. Fu¨r diese
Aufgabe wird der SentenceSplitter benutzt. Dieser sucht die Satzenden in einem Dokument
und markiert diese mit einem Tag (<end/>). Abku¨rzungen oder Organisationen die Punkte
enthalten sollen nicht als Satzende identifiziert werden. Deshalb benutzt der SentenceSplitter
unter anderem Abku¨rzungswo¨rterbu¨cher, fu¨r Abku¨rzungen wie Bsp. oder F.D.P., und regula¨re
Ausdru¨cke, um z.B. Datumsangaben zu erkennen. Satzzeichen die das Ende eines Satzes
kennzeichnen, wie z.B. !,. oder ?, werden entfernt und durch ein Tag ersetzt, welches fu¨r
die Weiterverarbeitung in das WTF-Format eindeutig kennzeichnet, dass hier ein Satzende
vorliegt.
Nun wird dieses Zwischenformat mit den <end/>-Tags in das WTF-Format konvertiert.
Jedes Wort bekommt hier eine eigene Zeile. In jeder Zeile gibt es zwei Spalten, welche einfach
durch ein Leerzeichen separiert werden. In der ersten Spalte steht das jeweilige Wort und
207
Deutscher O
Bundestag O
Drucksache O
16 O
/ O
1 O
16 O
. O
Wahlperiode O
18 O
. O
10 O
. O
2005 O
Antrag O
der O
Fraktionen O
CDU/CSU O
Abbildung 3.5: Die Drucksache im WTF-Format
in der zweiten Spalte das Tag, das diesem Wort zugeordnet wurde. In diesem Fall wird ein
unannotiertes Dokument im WTF-Format erstellt. Das bedeutet das jedes Wort nur das
”
leere Tag“ (O) zugewiesen bekommt. U¨ber das Annotation-Tool kann ein solches Dokument
auch manuell getaggt werden (siehe Kapitel 3.2). Außerdem kann u¨ber das ie-Plugin anhand
eines mit Trainingsdaten gelernten Modells eine automatisierte Zuordnung von Tags gestartet
werden (siehe Kapitel 4.2). Fu¨r jedes Wort wird also ein Zeilenumbruch eingefu¨gt. Analog wird
fu¨r jedes Satzende eine Leerzeile eingefu¨gt. Nach diesen Schritten ist ein Dokument nun im
WTF-Format vorliegend.
Beispielhafte Umwandlung einer regular ASCII Datei in das WTF-Format: In Abbildung
3.5 ist ein Auszug aus dem obigen Beispiel im WTF-Format zu sehen.
Hier ist z.B. zu erkennen, dass die Punkte im Datum, wie gewu¨nscht, nicht als Satzendezeichen
erkannt wurden.
3.1.3 Der FileWorker
Der FileWorker ist das Tool, welches die Transformation aus den Abschnitten 3.1.1 und 3.1.2
vornimmt.
In Abbildung 3.6 ist das Hauptmenu¨ des FileWorkers dargestellt. Mit der Option
”
Quell-
Verzeichnis “ muss ein Ordner ausgewa¨hlt werden. Auf diesen und alle seine Unterordner
wird der ausgewa¨hlte Filter angewandt, sofern die Datei das passende Eingabeformat hat.
Unter
”
Filter wa¨hlen “ wird der gewu¨nschte Verarbeitungsschritt eingestellt. Dabei stehen
208
Abbildung 3.6: Das Menu¨ des FileWorkers
die folgenden mo¨glichen Umwandlungsschritte zur Wahl:
ˆ Text-File (mit <end/>) → WTF
Dieses war ein Umwandlungsschritt der beno¨tigt wurde, bevor der SentenceSplitter fer-
tig gestellt wurde. So konnten regular Ascii Dokumente per Hand mit <end/>-Tags
versehen werden und dann automatisch in das WTF-Format konvertiert werden. Dieser
Schritt ist mit Fertigstellung des SentenceSplitters u¨berflu¨ssig geworden.
ˆ PDF in Plain-Text konvertieren (1-spaltig)
Dieser Umwandlungsschritt beschreibt die in Abschnitt 3.1.1 vorgestellten Schritt, al-
lerdings ohne dass Worttrennungen entfernt werden. Dieser Schritt ist auf 1-spaltiges
Layout optimiert worden.
ˆ PDF in Plain-Text konvertieren (2-spaltig)
Dieser Konvertierungsschritt ist identisch zum vorangegangenen Schritt, mit der Aus-
nahme, dass dieser Schritt auf 2-spaltiges Layout optimiert worden ist.
ˆ PDF → WTF (full preprocessing)
Hierbei werden alle beno¨tigten Umwandlungen in einer Ausfu¨hrung durchgefu¨hrt. Das
heißt, dass sowohl die Schritte aus Abschnitt 3.1.1, als auch die Schritte aus Abschnitt
3.1.2 hintereinander ausgefu¨hrt werden. Dieses ist die fu¨r uns wichtigste Umwandlung,
da bei ihr sowohl die regular Ascii Dateien, als auch die WTF-Dateien in einem Schritt
ausgegeben werden. Deshalb hat diese Transformation auch noch zusa¨tzliche Einstel-
lungsmo¨glichkeiten (siehe Abbildung 3.7), welche das Abspeichern der erstellten Dateien
betreffen.
ˆ Worttrennung am Zeilenende entfernen
In diesem Konvertierungsschritt wird lediglich der Worttrennungsschritt aus 3.1.1 durch-
gefu¨hrt. Das heißt, dass die Eingabe eine Ascii-Datei sein muss und als Ausgabe, eine
regular Ascii Datei entsteht.
Nachdem der FileWorker sa¨mtliche Daten des Deutschen Bundestag bearbeitet hat, liegen
uns nun fu¨r alle weiteren Schritte sowohl die regular Ascii Dateien vor, als auch die gleich
ungetaggten Dokumente im WTF-Format.
BTD/BTP-Crawler
Am Anfang der Datenakquise steht die Beschaffung der PDF-Dokumente, um sie dann weiter
verarbeiten zu ko¨nnen. Beschaffung heißt in diesem Fall, dass sie von der Webseite des Bun-
209
Abbildung 3.7: Das erweitere Menu¨ des FileWorkers, beim Filter PDF → WTF
destages heruntergeladen werden mu¨ssen. Nur wenn dieser Schritt automatisiert ist, ko¨nnen
unsere Datenbanken auf einfache Weise aktuell gehalten werden und neue Informationen in-
tegrieren. Diesen automatisierten Download erledigt der BTD/BTP-Crawler.
Der Crawler gliedert sich in zwei logische Bereiche, die durch die unterschiedlichen Speicher-
orte der PDFs bestimmt sind. Die Dokumente der Wahlperioden 14, 15 und die Anfa¨nge der
16. Wahlperiode sind in das DIP (dip.bundestag.de) eingebunden. Alle aktuelleren Dokmente
sind außschließlich in das neue Informationssystem DIP21 (dip21.bundestag.de) aufgenom-
men worden. Das sich DIP und DIP21 grundlegend unterscheiden, behandelt sie der Crawler
auch unterschiedlich.
Der DIP-Webserver bietet die Mo¨glichkeit, sich, a¨hnlich eines Dateimanagers, durch das Datei-
system der Dokumente zu hangeln. Es sind u¨ber- und untergeordnete Dateiordner und die
darin enthaltenen Dateien anwa¨hlbar. Der Crawler la¨dt die Webseite mit der obersten Ver-
zeichnisebene herunter und arbeitet sich anhand der Links der Webseite durch den Verzeich-
nisbaum. Die Links werden mit regula¨ren Ausdru¨cken gefunden. Da auch die PDFs verlinkt
sind, ko¨nnen sie direkt heruntergeladen werden.
Die Beschaffung der PDFs vom DIP21-Server gestaltet sich hingegen ungemein schwieriger,
da die Struktur des Dateisystems nicht mehr in Form von verlinkten Webseiten verfu¨gbar
ist. Ein Link auf ein PDF-Dokument la¨sst sich nur noch u¨ber die Verwendung des DIP21-
Suchformulars erreichen. Auch wenn sie nicht vollsta¨ndig einsehbar ist, so ist im DIP21
aber glu¨cklicherweise die Ordner-Struktur des DIP beibehalten worden. Kennt man also die
Drucksachen- oder Plenarprotokollnummer, so la¨sst sich daraus der Pfad zur PDF-Datei re-
konstruieren. Der DIP21 Crawler verfolgt demnach die Strategie, die Nummer des zuletzt
vero¨ffentlichten BTP bzw. BTD auszumachen und dann einfach die Dokumentennummer
herunterzuza¨hlen. Da die Dokumente alle fortlaufend nummeriert sind, schein dies die effizi-
enteste Methode zu sein, auch wenn Lu¨cken in der Nummerierung erst bei erfolgloser Anfrage
an den Webserver erkannt werden ko¨nnen. Die Lu¨cken kommen am ha¨ufigsten bei den aktu-
ellsten Dokumenten vor, da es immer wieder solche gibt, die zwar ins DIP21 aufgenommen
wurden, aber noch nicht im Volltext (als PDF) vorliegen.
210
Die komplexeste Aufgabe bei der Dokumentenbeschaffung aus dem DIP21 ist also die Be-
stimmung der Nummer der aktuellsten Drucksache bzw. des Plenarprotokolls. Ein einfaches
Heraufza¨hlen der bei eins beginnenden fortlaufenden Nummerieung von Dokumenten einer
Wahlperiode kommt nicht in Frage, da so viel zu viele unno¨tige Anfragen an den Webser-
ver gehen wu¨rden und ein Abbruchkriterium festgelegt werden mu¨sste. Wenn die Anzahl
der erfolglosen Anfragen gering gehalten wird, la¨uft man Gefahr zu fru¨h abzubrechen. Daher
za¨hlt der Crawler die Dokumentennummer herunter. Die aktuell ho¨chste Nummer wird vorher
durch eine automatische Anfrage an das Suchformular des DIP21 gestellt. Angefragt werden
alle Dokuemnte, die bis zum dem Tag, an dem die Anfrage ausgefu¨hrt wird, vero¨ffentlicht
wurden. Dies ist das Ergebnis der Tatsache, dass eine Suche ohne Einschra¨nkungen nicht
mo¨glich ist. Durch weitere Parameter werden werden so die aktuellsten 100 Dokumente ab-
steigend sortiert als HTML-Seite zuru¨ckgeliefert. Ist zu einem Dokument ein PDF vorhanden,
so ist die Dokumentennummer in der Ergebnisliste direkt damit verlinkt. Der Crawler parst
das HTML-Dokument nach der ersten verlinkten Dokumentennummer und bestimmt so die
aktuelle Wahlperiode und die ho¨chste Dokumentennummer. Danach folgt das Herunterza¨hlen.
Ist die aktuelle Wahlperiode abgearbeitet (Dokumentennummer = 1), so wird in die vorheri-
ge Wahlperiode gewechselt. Hier stellt sich, zur Vermeidung unno¨tiger Anfragen, wieder das
gleiche Problem, wie zu Anfang: Was ist das letzte Dokument dieser Wahlperiode? Um dies
zu bestimmt, wird die bekannte Anfrage an das Suchformular um eine Einschra¨nkung auf
die zur Zeit betrachtete Wahlperiode erweitert. Nun funkioniert die Bestimmung analog zur
ersten.
Der die a¨lteste Wahlperiode, die der DIP21-Crawler verarbeitet, ist die Periode 16, die zur
Zeit der Verfassung dieses Dokuments die aktuelle ist. Durch die zuvor beschriebene Funkti-
onsweise ist der Crawler auch fu¨r die Verarbeitung folgender Legislaturperioden geeignet.
Um den Datentransfer gering zu halten, fu¨hrt der Crawler einen eigenen Index, in der zu jeder
herunterladenen Datei das Datum der letzten Modifikation gespeichert wird. Der Index wird
als einfache CSV-Datei in jedem Verzeichnis abgelegt. Bei der großen Anzahl an PDFs, wa¨re
ein zentraler Index unhandlich und langsam. Das A¨nderungsdatum sendet der Webserver bei
der Anfrage nach der Datei automatisch mit zuru¨ck. Es wird bei einem erneuten Crawling
in die Anfrage an den Webserver eingebaut. Das HTTP/1.0 Protokoll [HTT] ha¨lt dafu¨r den
Header IfModifiedSince bereit. Erha¨lt der Webserver eine Anfrage mit diesem Header, kann
er neben den sonst u¨blichen Antworten (200 - OK, 404 - File not found, ...) auch mit 304 -
Not Modified antworten, wenn die angefragte Datei nicht aktueller ist, als das u¨bermittelte
Datum. Bei der Antwort 200 - OK sendet der Webserver die PDF-Datei im Datenbereich der
Antwort mit. Die Not-Modified Nachricht reduziert diese Antwort auf die Antwort-Header.
Der Datenteil, in dem sich das PDF befa¨nde, bleibt leer. So wird der Traffic erheblich reduziert.
Lucene Update
Im Fileworker ist auch eine Komponente enthalten, die die beiden Lucene-Indizes aktuell
halten kann. Dazu wird im Lucene-Index zu jedem Lucene-Dokument in einem Feld das Da-
tum der letzten A¨nderung der Quelldatei gespeichert (zum Aufbau der Lucene-Indizes siehe
Kaptiel 5.2). Bei Dokumenten-Index ist dies zum Beispiel das A¨nderungsdatum einer BTD-
ASCII-Datei. Der Updater durchla¨uft zuna¨chst den gesamnten Lucene-Index und schaut, ob
dort Dateien referenziert werden, die es mittlwerweile nicht mehr gibt. Die entsprechenden
Eintra¨ge werden dann aus dem Index entfernt. Danach werden alle zu indexierenden Dateien
durchlaufen. Ist die Datei im Dateisystem aktueller als ihr Zeitstempel im Index oder garnicht
211
im Index, wird die Datei (neu) indexiert, andernfalls u¨bersprungen. Durch diese Vorgehens-
weise ko¨nnen die Lucene-Indizies effizient aktuell gehalten werden, ohne jedes Mal den ganzen
Index neu zu erzeugen.
Da die Felder der Lucene-Dokumente aber auch aus externe Quellen (XML-Dateien) ihre
Daten beziehen, wird auch fu¨r diese Quellen ein Zeitstempel gespeichert. A¨ndert sich eine ex-
terne Quelle, werden alle Lucene-Dokumente, die diese referenzieren, ungeachtet ihres eigenen
A¨nderungsdatums neu erstellt.
BTD Index erneuern
Im Werkzeuge-Menu¨ des Fileworkers kann auch eine neue BTD Index-Xml fu¨r die Dokumente
erstellt werden. Hierfu¨r werden alle Dokumente verwendet, welche im data-Verzeichnis unter
ascii/btd/ zu finden sind.
Desweiteren wird fu¨r die Erstellung der neuen BTD Index-Xml die Mops-Xml, welche die
Daten u¨ber die Abgeordneten beeinhaltet, beno¨tigt. Diese wird ebenfalls aus dem data-
Verzeichnis, unter mops/results.xml, gelesen. Die Informationen u¨ber die Abgeordneten wer-
den beno¨tigt, um den Autoren eines Dokuments die eindeutigen Id’s zuzuweisen.
Der u¨ber diese Aktion neu erstellte Index wird dann wie gewohnt im data-Verzeichnis unter
btd index/btd index update.xml gespeichert.
3.2 Erstellen der Trainingsdaten
Fu¨r die Erstellung der Trainingsdaten, wurden zuerst die Dokumente mit Hilfe der PDF-BOX
in ASCII-Format konvertiert. Diese sind dann in das Annotion-Tool, welches von Daniel. S.
nach unseren Vorstellungen entwickelt wurde, geladen worden. Der Vorteil des Tools fu¨r unsere
Zwecke war, dass das taggen per Hand erleichtert wurde und es als Ausgabedatei automatisch
das WT-Format nutzt. Bevor das taggen per Hand begonnen werden konnte, mussten nun
passende NEs (Tags) ermittelt werden, welche in den Dokumenten am ha¨ufigsten vorkommen
und fu¨r uns am nu¨tzlichsten erschienen. Es wurde beschlossen nach folgenden Merkmalen zu
taggen:
ˆ Name
ˆ Person (zu einer Person geho¨ren auch Namenstitel wie Dr., Prof., Herr, Frau sowie auch
Kollege.)
ˆ Ort
ˆ Organisation/Institut/Beho¨rde ( wie z.B. Ministerien)
ˆ Reaktionen ( Positive oder Negative Reaktionen auf Reden)
ˆ Abstimmungen ( Pro, Contra, Unentschlossen und das Ergebnis)
ˆ Amt/Rolle ( wie z.B. Bundestagssprecher/in, Sekreta¨r/in, Bundestagspra¨sident/in, Op-
position)
ˆ Partei ( wobei fu¨r einige Parteien synonyme Bedeutungen auch mit getaggt wurden wie
z.B. Die Union, die Gru¨ne.)
212
Das Datum und die Drucksachennummern werden mit Hilfe von regula¨ren Ausdru¨cken extra-
hiert. Es wurde beschlossen Fraktion und Koalition zuna¨chst außer Betracht zu lassen.
Fu¨r das manuelle Taggen haben wir zwei Methoden angewendet, wobei die zweite Methode,
die erfolgreichere und konsistentere war:
1. Es wurden zufa¨llig zwei Dokumente ausgesucht und unter uns abschnittsweise aufgeteilt,
wobei zwei Personen den gleichen Abschnitt getaggt haben. Die ganzen Abschnitte
wurden dann zusammengefu¨gt. Das Lernresultat ist inkonsistent gewesen, es wurden
z.B. viele Orte und Parteien nicht richtig getaggt.
2. Es wurden dieselben Dokumente getaggt aber diesmal nur von zwei Personen und nach
genauer Absprache u¨ber Tag-Kriterien. Dadurch konnte das Lernresultat beim anschlie-
ßenden Lernlauf auf 80% richtig getaggter NEs verbessert werden.
Als Ausgabe liefert das Annotion-Tool, die getaggten Dokumente in WT-Format welche fu¨r
die Weiterverarbeitung innerhalb des RapidMiner-Tools wichtig ist. Mit Hilfe von RapidMi-
ner sehen wir wie gut gelernt wurde.
3.3 Sentence Splitter
3.3.1 Grundlegendes
Jede nicht-triviale computerlinguistische Verarbeitung von natu¨rlichen Texten erfordert Vor-
verarbeitung, die im Allgemeinen folgende Teilaufgaben lo¨sen soll:
ˆ (1) Bereinigung der Eingabekette von Sonderzeichen,
ˆ (2) Zerlegung der Eingabekette in einzelne Einheiten, genannt: Tokens,
ˆ (3) Erkennung der Satzenden.
Der SentenceSplitter ist eine Java Komponente, die an Hand von Regeln Satzenden in einem
Text markieren soll.
3.3.2 Problematik der Satzendeerkennung
Die Erkennung von Satzenden ist wegen der Ambiguita¨t des Punktes eine schwierige Aufgabe.
Der Punkt markiert oft nicht nur das tatsa¨chliche Satzende, sondern auch eine Zahl oder eine
Abku¨rzung. Die Verwendung von Punkten zu Markierung einer bestimmten Zahl innerhalb
einer Aufza¨hlung ist ebenso doppeldeutig wie die Markierung von Abku¨rzungen. Die folgende
u¨berspitzte Passage verdeutlicht die Problematik und zeigt wie kleine Formulierungsfehler
oder Umgangssprache regelbasierte Erkennung erschweren:
”
Der 14. Tag war genau so sonnig wie der 13. Oktober ist im Allg. sehr verregnet.“
Selbst wenn die Maschine eine Abku¨rzung oder Aufza¨hlung als solche erkennt, kann man nur
mit Hilfe des semantischen Kontexts und der umliegenden Wo¨rter entscheiden, ob es sich bei
diesem Punkt um ein tatsa¨chliches Satzende handelt.
213
3.3.3 Satzenden in den Dokumenten des Dt. Bundestags
Die Texte des Dt. Bundestags liegen im Allg. als PDF Dokumente vor. Fu¨r die sinvolle Verar-
beitung werden sie von PDF zu Text umgewandelt und von Sonderzeichen bereinigt. Im Zuge
dieser Konvertierung fließen einige, vom Typ der Dokumente abha¨ngige Layoutinformationen
mit in das Resultat. Die Ausgabe beinhaltet aus dem PDF konvertierte Zeilen, die nicht mit
einem Punkt enden, aber dennoch logisch als abgeschlossene Sa¨tze behandelt werden mu¨ssen.
Dies ist besonders fu¨r U¨berschriften, Kapitel und Listen der Fall. Die ohne hin schwierige
Teilaufgabe der Satzendeerkennung, speziell in den Dokumenten des Bundestags wird also
durch die Ambiguita¨t von Zeilenenden zusa¨tzlich erschwert.
3.3.4 Markierung von Satzenden
Fu¨r die Lo¨sung der oben genannten, dritten Teilaufgabe, ist eine bereinigte Zeichenkette not-
wendig. Der SentenceSplitter liest eine Eingabekette ein und gibt eine verarbeitete Zeichen-
kette aus. Die Markierung von Satzenden erfolgt durch das Einfu¨gen eines abgeschlossenen
XML Tags: <end/> an jedem erkannten Satzende.
Durch die besondere Form der Eingabekette muss die Verarbeitung Zeilenweise erfolgen, wobei
jede Zeile, gema¨ß Teilaufgabe 2 in Wo¨rter (Tokens) zerlegt wird. Die Trennung erfolgt an je-
dem Zeichen, dass kein Buchstabe oder Satzzeichen ist (whitespace characters). Die einzelnen
Tokens werden in einem indizierten Array gespeichert. Fu¨r jede Zeile wird direkt entschieden,
ob das letzte Wort der Zeile als abgeschlossener Satz markiert werden soll. Diese Heuristik
basiert auf zwei einfachen Regeln, welche die Zeichenla¨nge und Wortanzahl der Zeile mit zwei
gewa¨hlten Werten vergleichen. Beide Werte sollen nur die
”
offensichtlichen“ kurzen Zeilen
markieren. Es wa¨re sinnvoll diese Regel so zu modifizieren, so dass sie abha¨ngig vom Typ und
der durchschnittlichen Zeilenla¨nge des Dokumentes optimale Werte berechnet/nutzt.
3.3.5 Betrachtung der Wo¨rter im Sliding Window Verfahren
Im na¨chsten Verarbeitungsschritt wird das Array traversiert. Jedes im Array gespeicherte
Wort wird auf ein mo¨gliches Satzende von der im Diagramm 3.8 dargestellten Entscheidungs-
pipeline u¨berpru¨ft. In vielen Fa¨llen wird sowohl der Vorga¨nger, sowie der Nachfolger des
Wortes betrachtet. Ein Wort wird um die <end/> Markierung erweitert und an die Zeichen-
kette der Ausgabe angeha¨ngt, falls es als Satzende erkannt worden ist. Die Verarbeitung ist
beendet sobald das letzte Wort des Arrays betrachtet worden ist.
3.3.6 Satzendeerkennung mit Regular Expressions und Wo¨rterbu¨chern
Die einzelnen Bausteine der Entscheidungspipeline sind linear angeordnet. Ein Wort wird
von einer “wenn-dann“ Regel zur Na¨chsten weitergereicht, bis eine Regel zutrifft. Die tri-
vialen Fa¨lle werden direkt am Anfang der Pipeline identifiziert, ggf. Markiert und aus der
Pipeline herausgeworfen. Die Erkennung von Satzenden erfolgt mit Hilfe von einfachen, ein
Wort u¨berpru¨fenden Regular Expressions. Zusa¨tzlich werden Aufza¨hlungen und Abku¨rzungen
gegen Wo¨rterbu¨cher gepru¨ft. Es wurden im Vorfeld folgende Wo¨rterbu¨cher angelegt:
ˆ Vorga¨nger einer Aufza¨hlung ( vom, am, dem, der)
214
Abbildung 3.8: Aufbau der Komponente
ˆ Nachfolger einer Aufza¨hlung mit Monatsnamen und Wo¨rtern die besonders ha¨ufig Vor-
kommen. ( Oktober, Antrag, Sitzung )
ˆ Liste deutscher Abku¨rzungen, extrahiert mit Hilfe einfacher Skripte aus den Webseiten:
– www.abkuerzungen.org
– abkuerzungen.woxikon.de
3.3.7 Ergebnisse
Der SentenceSplitter markiert alle eindeutigen Satzenden. Fu¨r die meisten Fa¨lle, der nicht
eindeutigen Satzenden existiert eine Regel in der Entscheidungspipeline. Fa¨lle die nicht ent-
schieden werden ko¨nnen, werden nicht als Satzende markiert. Das gilt besonders fu¨r Satzenden
die nur durch semantischen Kontext erkennbar sind.
215

4 Informationsextraktion
4.1 Information automatische Extraction aus HTML
4.1.1 HTML Datei lesen
Um die Information zu extrahieren, mu¨ssen alle Daten zuna¨chst aus denen HTML Datei
gelesen werden. Eine Beispiel fu¨r HTML Format: Um die Information aus denen HTML Datei
zu lesen, soll Str1 und Str2 gelesen werden. Wie kann man Str1 und Str2 lesen, ist es in folgend
Automater verdeutlichet (sieh Abb.4.3). Das Programm sieht man in ”Html2Xml.HTML-
lesen.java”. Die Daten Struktur ist in ”HTML-Page.java”definiert.
pp-type ist hier Str1 und pp-daten ist hier Str2.
4.1.2 Umwandlung von HTML mit einigen Regeln zu XML
HtmltoXml
Architektur Grobentwurf sieht man in folgend Diagramm (Abb. 4.4 4.5 4.6 4.7).
4.1.3 Benutze zum Umwandeln fu¨r MOPs mit HtmltoXml
Mann kann MOPs durch das Allgemeine Programm ”HtmltoXml” erstellen. Zuna¨chst soll
man Regeln-Datei schreiben. (siehe Regeln-MOPs.xml)
(i) XMLSchema fu¨r MOPs.xml
(ii) Regeln fu¨r MOPs.xml
In folgende werden einige Regeln fu¨r MOPs.xml vorgestellt.
1 <Element name ="wahlperiode" anzahl="1" eigenschaft="Element"
2 type="ordner" path="../ p14">
Abbildung 4.1: HTML Format
217
Abbildung 4.2: Automater um HTML Datei zu lesen
1 public class HTML -Page{
2 public String pp -type;
3 public String pp -daten;
4 }
Listing 4.1: HTML-Page.java
Abbildung 4.3: Umwandlung von HTML zu XML
218
Abbildung 4.4: Umwandlung von HTML zu XML Level-1
219
Abbildung 4.5: Umwandlung von HTML zu XML Level-2
220
Abbildung 4.6: Umwandlung von HTML zu XML Level-3
221
Abbildung 4.7: Umwandlung von HTML zu XML Level-4
222
Abbildung 4.8: XMLSchema fu¨r MOPs.xml
223
eigschaft =”Element”:
Es gebt 3 Eigenschaften von Element.
(1.) Element : Es ist ein Element
(2.) Attribute: Es ist eine Attribute
(3.) Automater: Es ist ein Element, und der Wert wird durch Automater erhalten.
type =”ordner”:
Wenn das Element eine Type ”ordner” hat, muss es ein Wert fu¨r path haben.
path =”../p14”:
Die alle Datei soll in de Ordner ”../p14” gefunden werden, wenn die Kinder-Element eine
Type ”datei” haben.
1 <Element name="nummer" anzahl="1" eigenschaft="Attribute" value=
"14"
2 type="fest"> </Element >
Es ist ein Attribut mit Name ”nummer”. Und es hat fest Werte ”14”.
1 <Element name="person" anzahl="n" eigenschaft="Element"
2 type="datei">
Es ist ein Element. Und der Wert soll aus eine Datei gelesen werden.
1 <Element name="H1" anzahl="1" eigenschaft="Automater" type="main
"
2 pruefung="pp_type" geAutomatervalue="getzustandvalue ()"
3 zustandNr="0" ausgabe="F">
4 <Zustand eigenschaft="Automater">
5 <value eigenschaft="Automater"> H1 </value >
6 <value eigenschaft="Automater"> h1 </value >
7 </Zustand >
8 </Element >
Es ist eine Automater. Die Automater hat nur ein Zustand definiert. Die Automater soll den
Zustand in pp-type pru¨fen. Wenn das Zustand erfu¨llt, wird der Wert aus erste Zustand erhal-
ten (geAutomatervalue = ”getzustandvalue()” zustandNr = ”0”). Das Element soll nicht
in XML Datei ausgeben, weil ausgabe = ”F” (F=false).
224
1 <Element name="Titel" anzahl="1" valuetype="parent.Element"
2 value="H1" eigenschaft="Element" gevalue="Name.getTitel ()">
3 </Element >
Der Wert ist durch spezielle Funktion ”Name.getT itel()” erhalten. Der Wert von vordefinier-
te H1 ist die Parameter.
1 <Element name="Geburt" anzahl="1" eigenschaft="Automater"
2 type="main" pruefung="pp_daten" geAutomatervalue="getpagedaten ()
"
3 pageindex="0" ausgabe="F">
4 <Zustand eigenschaft="Automater">
5 <value eigenschaft="Automater"> geboren </value >
6 <value eigenschaft="Automater"> Geboren </value >
7 <value eigenschaft="Automater"> gebort </value >
8 <value eigenschaft="Automater"> Gebort </value >
9 </Zustand >
10 <Zustand eigenschaft="Automater">
11 <value eigenschaft="Automater"> am </value >
12 <value eigenschaft="Automater"> Am </value >
13 </Zustand >
14 </Element >
Die Automater hat 2 Zusta¨nde definiert. Und sie soll die Zusta¨nde in pp-daten pru¨fen. Wenn
alle Zusta¨nde erfu¨llt, der Wert ist genau den Wert von aktuelle pp-daten, weil pageindex =”0”.
Wenn pageindex = 1 ist, soll die Automater na¨chste pp-daten lesen.
225
1 <Element name="Geburtsdatum_0" anzahl="1" valuetype="parent.
Element"
2 value="Geburt" eigenschaft="Automater" type="main" pruefung="
value"
3 geAutomatervalue="getnextwort ()" getwoerteanzahl="5" ausgabe="F"
>
4 <Zustand eigenschaft="Automater">
5 <value eigenschaft="Automater"> geboren </value >
6 <value eigenschaft="Automater"> Geboren </value >
7 <value eigenschaft="Automater"> gebort </value >
8 <value eigenschaft="Automater"> Gebort </value >
9 </Zustand >
10 <Zustand eigenschaft="Automater">
11 <value eigenschaft="Automater"> am </value >
12 <value eigenschaft="Automater"> Am </value >
13 </Zustand >
14 </Element >
Die Automater lesen die Information aus vordefiniert Geburt. Wenn alle Zusta¨nde erfu¨llt, ist
der Wer genau na¨chste Wort in den Wert von Element Geburt.
Analog fu¨r andere Regeln.
4.1.4 IdErzeugen (PersonIdErzeugen.java)
Die Funktion ”getPersonId(StringName)” dientet dazu, fu¨r eine Person eine Id zu verteilen.
Wenn man die Funktion benutzt hat, soll man nicht vergessen, die Funktion ”PersonIdSpeichern()”
aufzurufen, um die neue Name zu speichern.
4.1.5 MOPsZugriff
Der Klass diente dazu, die MOPs zu zugreifen.
”Suchen()”: beliebigen Information in MOPs zu suchen
”add(personp)”: Eine neue Person in MOPs einfu¨gen.
”toXml(Stringtoxml)”: MOPs als XML ausgeben.
In Folgend sieht man eine Sequenz Diagramm als Beispiel AusschuesseZugriff analog.
226
Abbildung 4.9: MOPsZugriff
227
Abbildung 4.10: Format von Link in HTML
4.1.6 Seitenbeschaffung
Seitenbeschaffung ist ein Programm (Crawler), der sich die HTML automatisch aus dem
Internet zieht, um aus diesen HTML-Seiten dann XML-Instanzen entsprechend Schemas und
Regeln zu erstellen. Zuna¨chst muss die Link aus einer Webseite ausgelesen werden.
Eine Beispiel fu¨r Link in HTML Format: Analog zu HTML lesen, muss man eine Datentype
fu¨r Link definieren.
1 public class web_link {
2 public String Name;
3 public String link;
4 }
Name ist hier die Information (z.B. Person).
Um die Linke auszuziehen, wird hier noch eine Automater geschrieben (sieh Abb. 4.11).
4.1.7 Automatischem Update
Um die Update-Funktion zu benutzen, brauchte man nur eine Instanz von updateClass() zu
erstellen.
Siehe eine Sequenz Diagramm als Beispiel
4.2 NER
4.2.1 Entita¨ten
Zur Beantwortung der Fragen ist es hilfreich, bestimmte Textstellen zu klassifizieren. Dazu
benutzen wir die Named Entity Recognition (NER). In den Rohdaten mu¨ssen dazu im ersten
Schritt einige Dokumente von Hand mit den NER-Entia¨tem markiert werden. Nachfolgend
sind die Entita¨ten aufgefu¨hrt, die wir gewa¨lt haben.
ˆ ORG - Organisation / Institution / Beho¨rde
Beispiel: Bundesregierung
228
Abbildung 4.11: Automater, um die Linke auszuziehen
229
Abbildung 4.12: Sequenz Diagramm fu¨r Automatischem Update
230
ˆ PERS - Person
Beispiel: Abgeordnete
Diese Entita¨t kennzeichnet eine Person ohne Namen.
ˆ REAC - Reaktion
Beispiel: Applaus
Zeigt die Einstellung einer oder mehrerer Personen und gibt somit Hinweise auf das
Verha¨ltnis gegenu¨ber einer anderen Person oder die Haltung zu einem Ereignis oder
Thema.
ˆ LOC - Ort
Beispiel: Berlin
Hilfreich fu¨r Fragen, in denen geographische Informationen enthalten sind oder erfragt
werden.
ˆ PROJ - Projekt
Beispiel: Aufkla¨rungskampagne
ˆ NAME - Name
Beispiel: Angela Merkel
Wird in einer Frage ein Name erwa¨hnt, liefert diese Entita¨t sofort die Sa¨tze, in denen
es um die benannte Person geht. Durch Extraktion eines Namens kann zusa¨tzlich das
Geschlecht bestimmt werden.
ˆ PAR - Partei
Beispiel: CDU/CSU
Dies ist eine der wichtigsten Entita¨ten unserer Doma¨ne.
ˆ BUR - Amt (politisch) / Rolle
Beispiel: Finanzminister
An vielen Stellen werden Personen mit ihren A¨mtern erwa¨hnt. Sind diese getagt, la¨sst
sich im zeitlichen Kontext die dazugeho¨rige Person ermitteln. Diese Zuordnung erho¨ht
die Qualita¨t der Fragebeantwortung, da auch weitere Informationen zu der ermittelten
Person mit einbezogen werden ko¨nnen.
ˆ ADJ+ - Abstimmung positiv
Beispiel: 15 Stimmen dafu¨r
Dies ist eine wichtige Entia¨t zu Extraktion von Ereignissen.
ˆ ADJ+ - Abstimmung positiv
Beispiel: 145 Stimmen dagegen.
ˆ ADJ? - Abstimmung unentschlossen
Beispiel: Enthaltungen
ˆ ADJ! - Abstimmungsergebnis
Beispiel: Antrag einstimmig angenommen
ˆ Drucksache - Referenz auf Drucksache
Beispiel: Drs 14/45
231
Tag Vorkommen absolut Vorkommen relativ
ORG 532 6,36%
PERS 430 5,14%
REAC 136 1,62%
LOC 475 5,68%
PROJ 0 0%
NAME 2540 30,35%
PAR 2078 24,83%
BUR 1632 19,50%
ADJ+ 0 0%
ADJ- 0 0%
ADJ? 0 0%
ADJ! 0 0%
Drucksache 135 1,61%
Plenarprotokoll 54 0,65%
Datum 358 4,28%
Tabelle 4.1: Verteilung der NER Entita¨ten am Beispiel eines manuell getaggten
Bundestagsprotokolls
Mit dieser Entita¨t lassen sich wichtige Verweise finden. So wird zum Beispiel die Ent-
wicklung eines Antrags zeitlich nachverfolgbar und es lassen sich Zusatzinformationen
(Empfehlungen, Plenarprotokolle ...) finden.
ˆ Plenarprotokoll - Referenz auf Plenarprotokoll
Beispiel: 15/47
ˆ Datum
Beispiel: Dezember 2007
Mit einem Datum kann ein zeitlicher Verlauf verfolgt oder der Zeitpunkt eines Ereig-
nisses ermittelt werden.
Beim manuellen Tagging der Trainingsdaten bestand vor allem die Schwierigkeit, fu¨r jede
Entita¨t Daten zu finden. Man kann sich leicht vorstellen, dass die Vorkommen der einzelnen
Tags sehr ungleich verteilt sind. Am seltensten sind Abstimmungen, die aber aus der Sicht der
Informationsextraktion zu den wichtigsten Entita¨ten geho¨ren. Wie zu erwarten, dominieren
die Entita¨ten Person (PERS), Name (NAME) und Amt (BUR). Tabelle 4.1 zeigt diese
Verteilung exemplarisch.
4.2.2 Rapid Miner, IE-Plugin
Zur Durchfu¨hrung der NER wurde das Open-Source Tool RapidMiner
(http://www.rapidminer.com) verwendet. Es ist vor allem unter seinem ehemaligen Namen
Yale (Yet Another Learning Environment) bekannt und wird vom Lehrstuhl fu¨r ku¨nstilche
Intelligenz an der Universita¨t Dortmund entwickelt. Wie der Name schon sagt, handelt es
sich dabei um ein Programm zur Analyse und Manipulation von Datensa¨tzen. RapidMi-
ner wird zusammen mit einem Plugin fu¨r Information Extraction (IE-Plugin) verwendet.
232
Das Plugin bereichert RapidMiner um spezielle Funktionen, die die NER unterstu¨tzen und
vereinfachen. Die Datenverarbeitung geschieht in Form von Prozessketten, die sich aus ver-
schiedensten Operatoren zusammensetzen. Jeder Operator nimmt Daten entgegen und gibt
welche aus, so dass die zu Beginn eingelesenen Ausgangsdaten durch die Prozesskette trans-
formiert werden. Eine weitere Arbeit, die sich mit NER in RapidMinder bescha¨ftigt ist
[Jun06]. Hier soll nun die Prozesskette erla¨utert werden, die fu¨r die NER benutzt wurde.
Abbildung 4.13 zeigt den Prozess schematisch, der im Groben aus den ga¨ngigen drei Phasen
Preprocessing, Trainingsphase, Testphase besteht.
Der NER-Prozess beginnt, wie jeder andere, mit dem Einlesen der Daten, die in diesem Fall
im WTF-Format, beschrieben in Kapitel 3.1.2), vorliegen. Dies bewerkstelligt der Sentence-
ExampleSource-Operator, der die Daten satzweise einliest. Ein Beispiel fu¨r die Rohdaten
ist:
[...] 08.03.2006
Antwort der Bundesregierung auf die Kleine Anfrage der Abgeordneten
Patrick Meinhardt ,
Cornelia Pieper ,
Uwe Barth ,
weiterer Abgeordneter und der Fraktion der FDP [...]
Die Daten im WTF-Format, wie sie der SentenceExampleSource-Operator einliest, haben
die Form:
08.03.2006 B-DATE
Antwort O
der O
Bundesregierung B-BUR
auf O
die O
Kleine O
Anfrage O
der O
Abgeordneten B-BUR
Patrick B-NAME
Meinhardt I-NAME
, O
Cornelia B-NAME
Pieper I-NAME
, O
Uwe B-NAME
Barth I-NAME
, O
weiterer O
Abgeordneter B-BUR
und O
der O
Fraktion O
der O
233
Prep rocessing
E i n l e s e n  d e r  D a t e n
(S e n t e n c e E x a m p l e S o u r c e )
W TF-D o k u m e n t
P r e f i x -B e r e c h n u n g
(P r e f i x )
S u f f i x -B e r e c h n u n g
(S u f f i x )
W o r t l ä n g e n  b e r e c h n e n
(L e t t e r C o u n t P r e p r o c e s s i n g )
N -G r a m  B e r e c h n u n g
(N G r a m )
G e n e r a l i s i e r u n g
(G e n e r a l i z e P r e p r o c e s s i n g )
D a t e n  z u r  K r e u z v a l i d i e r u n g  a u f t e i l e n
(S p l i t t e d X B a t c h V a l i d a t i o n )
Tr a i n i n g s d a t e n
R e g u l ä r e  A u s d r ü c k e
(R e g e x )
N a c h b a r w ö r t e r  b e r e c h n e n
(W o r d P r e p r o c e s s i n g )
W o r t a n z a h l  i m  S a t z  b e r e c h n e n
(G e n e r a l i z e P r e p r o c e s s i n g )
Tr a i n i n g s p h a s e
(M a l l e t C R Fo p e r a t o r )
M o d e l l
Te s t p h a s e
(M a l l e t C R Fo p e r a t o r )
A u s w e r t u n g
(P e r f o r m a n c e E v a l u a t o r )
Te s t d a t e n
Abbildung 4.13: Die NER Prozesskette
234
FDP B-PAR
In jeder Zeile kommt nur ein Wort vor, rechts daneben das
”
Named Entity Tag“. O heißt,
dass das Wort keine Named Entity ist.
”
B-“ weist darauf hin, dass die Named Entity gerade
beginnt, wo hingegen
”
I-“ anzeigt, dass die Named Entity fortgesetzt wird, wie es zum Beispiel
bei Namen (Vorname und Nachname) der Fall ist.
Anschließend werden die Daten durch das Preprocessing angereichert. Dabei werden die Merk-
male berechnet, die spa¨ter die Basis fu¨r den Lernlauf bilden. Die einzelnen Preprocessingschrit-
te werden im Folgenden beschrieben.
ˆ Prefix-Berechnung
Der Prefix gibt den Anfang eines Wortes wieder. In der Prozesskette werden Prefixe
der La¨nge zwei, drei und vier verwendet. Zu jeder La¨nge wird der Prefix des aktuell
betrachteten Wortes, sowie der des Vorvorga¨ngers, Vorga¨ngers, Nachfolgers und Nach-
nachfolgers berechnet. Jedes Wort wird also in einem Fenster der Gro¨ße fu¨nf betrachtet.
ˆ Generalisierung
Der Generalisierungsoperator vereinheitlicht den Text, indem er alle Großbuchstaben
durch
”
A“, alle Kleinbuchstaben durch
”
a“ und alle sonstigen Zeichen durch
”
x“ er-
setzt. Auch hier werden zu jedem Wort die Generalisierungen der zwei vorherigen und
nachfolgenden Wo¨rter, sowie des aktuellen Wortes, erzeugt.
ˆ Regula¨re Ausdru¨cke
Mit regula¨ren Ausdru¨cken ko¨nnen komplexere Merkmale extrahiert werden.
ˆ Nachbarwo¨rter berechnen
Zu jedem Wort werden die umgebenden Wo¨rter mit einer Fenstergro¨ße von fu¨nf berech-
net.
ˆ Suffix-Berechnung
Der Suffix-Operator funktioniert analog zum Prefix-Operator und wird ebenfalls mit
den gleichen La¨ngen und derselben Fenstergro¨ße verwendet.
ˆ N-Gram
Ein N-Gram bezeichnet alle Subsequenzen der La¨nge N einer Sequenz. Wir verwenden
ein zeichenbasiertes N-Gram von einzelnen Wo¨rtern. Fu¨r das Wort
”
Gesetzentwurf“
wa¨ren die N-Gramme der La¨nge 6:
”
Gesetz“,
”
esetze“,
”
setzen“,
”
etzent “,
”
tzentw“,
”
zentwu“,
”
entwur“,
”
ntwurf“.
Es werden N-Gramme der La¨ngen zwei, drei und vier mit je einer Fenstergro¨ße von fu¨nf
berechnet.
ˆ Wortanzahl im Satz
Zu jedem Wort wird die Anzahl der Wo¨rter im Satz, in dem sich das Wort befindet,
zugeordnet.
ˆ Wortla¨ngen
Mit einem Fenster der Gro¨ße fu¨nf werden die Wortla¨ngen zu jeden Wort extrahiert.
235
Nach dem Preprocessing werden die angereicherten Daten in x Teile aufgeteilt, um eine Kreuz-
validierung vorzunehmen. Einer der x Teile wird fu¨r die Testphase benutzt, wa¨hrend anhand
der u¨brigen trainiert wird. Dieser Vorgang wird x-mal wiederholt, so dass auf jeden Teil
der Daten einmal das auf den anderen Teilen berechnete Modell angewendet wird. Als Be-
wertungsmaßstab der Prozesskette werden die Durschnittswerte von Precision, Recall und
F-Measure u¨ber alle x Iterationen ermittelt. Die Kreuzvalidierung ist ein wichtiges Element
zur Bewertung der Qualita¨t der Prozesskette. Die Ergebnisse ko¨nnen durch die Eigenheiten
der fu¨r den Prozess verwendeten Daten beeinflusst werden. So ist gut vorstellbar, dass die
vorgestellten Features mit bestimmten Dokumenten besser funktionieren. Die zufa¨llige Auftei-
lung der Kreuzvalidierung versucht eine Art Unabha¨ngigkeit von der verwendeten Datenbasis
zu erzeugen. Je gro¨ßer die Anzahl der Teile (x) gewa¨hlt wird, desto realistischer sollten die
Ergebnisse fu¨r die Verwendung mit unbekannten Daten sein. Tabelle 4.2 zeigt einige exem-
plarische Ergebnisse fu¨r verschiedene Werte von x bei gleicher Konfiguration der u¨brigen
Komponenten unter Verwendung des selben WTF-Dokuments. Die Laufzeiten wurden auf
einem 2,8Ghz PC mit 2048 MB Arbeitspeicher unter Windows XP gemessen.
236
x 2 4 6
Laufzeit 75 min 300 min 530 min
Tag P R F P R F P R F
ORG 0.493± 0.046 0.210± 0.018 0.292± 0.010 0.644± 0.103 0.470± 0.258 0.511± 0.189 0.656± 0.142 0.452± 0.286 0.501± 0.221
PERS 0.558± 0.297 0.497± 0.030 0.476± 0.128 0.764± 0.164 0.531± 0.086 0.615± 0.090 0.724± 0.315 0.567± 0.104 0.595± 0.234
REAC 0.744± 0.244 0.618± 0.118 0.672± 0.172 0.688± 0.410 0.584± 0.366 0.628± 0.382 0.720± 0.403 0.738± 0.342 0.696± 0.350
LOC 0.766± 0.093 0.338± 0.102 0.452± 0.081 0.872± 0.056 0.511± 0.104 0.638± 0.083 0.878± 0.059 0.515± 0.080 0.645± 0.071
PROJ - - - - - - - - -
NAME 0.760± 0.027 0.640± 0.022 0.695± 0.024 0.877± 0.052 0.825± 0.072 0.849± 0.059 0.880± 0.117 0.787± 0.167 0.829± 0.144
PAR 0.692± 0.111 0.515± 0.057 0.580± 0.003 0.945± 0.049 0.880± 0.087 0.910± 0.068 0.881± 0.162 0.813± 0.227 0.841± 0.202
BUR 0.783± 0.042 0.585± 0.147 0.655± 0.082 0.860± 0.102 0.787± 0.125 0.820± 0.109 0.845± 0.083 0.736± 0.218 0.768± 0.172
ADJ+ - - - - - - - - -
ADJ- - - - - - - - - -
ADJ? - - - - - - - - -
ADJ! - - - - - - - - -
Drucksache 0.500± 0.500 0.500± 0.500 0.500± 0.500 0.750± 0.433 0.571± 0.404 0.626± 0.400 0.395± 0.447 0.484± 0.485 0.421± 0.450
Plenarprotokoll 0 0 0 0.500± 0.500 0.417± 0.433 0.450± 0.456 0.333± 0.471 0.312± 0.443 0.322± 0.456
Datum 1.000± 0.000 0.422± 0.347 0.505± 0.364 0.705± 0.410 0.495± 0.381 0.557± 0.377 0.665± 0.388 0.494± 0.391 0.505± 0.367
Gesamt 0.703± 0.010 0.518± 0.063 0.595± 0.046 0.852± 0.067 0.733± 0.023 0.787± 0.034 0.823± 0.132 0.705± 0.115 0.755± 0.107
Tabelle 4.2: Ergebnisse von NER-Testla¨ufen auf einem WTF-Dokument
237
4.3 Events
4.3.1 Allgemeine Definition
Die Bestimmung von Events erleichert die Beantwortung bestimmter Fragestellungen und
hilft eine Struktur in die gesammelten Informationen zu bekommen. Ziel ist es, die Events
mo¨glichst atomar zu gestalten, so dass die Informationsextraktion der Dokumente mo¨glichst
vollsta¨ndig geschehen kann. Bestimmte Fragestellungen, wie z.B.
”
Wieviele Antra¨ge von weib-
lichen Abgeordneten wurden abgelehnt?“ kann man nachfolgend ausschließlich anhand der
Event-Informationen beantworten. Jedes Event wird als XML gespeichert, so dass Anfragen
an eine Menge von XML-Dateien via XPATH gestellt werden ko¨nnen. Hier ein kleines Beispiel
fu¨r eine solche XML-Datei:
Am Beispiel
”
Antrag“ erkennt man die Struktur der Events. Grundsa¨tzlich kann jedem Event
eine eventId, ein datum sowie eine drucksache zugewiesen werden. Daru¨berhinaus gibt es eine
Menge von speziellen Slots, die u¨blicherweise ein Named Entity darstellen. Im obigen Beispiel
wa¨ren dies der Named Entity Name, Partei und Topic.
4.3.2 Event-Schemata
In diesem Abschnitt folgt eine Auflistung der vorhandenen Events mit Triggern und Slots.
Jedes Event verfu¨gt u¨ber die folgenden Standard-Slots, die nachfolgend nicht mehr explizit
erwa¨hnt werden: eventId (Identifikator des Events), Datum und DokId (Identifikator des
zugeho¨rigen Dokuments).
Antrag
ˆ Triggerworte
– Antrag
In jeder Drucksache wird Antrag trivialerweise als U¨berschrift genutzt.
– fordert auf
”
fordert auf“ ist ein Schlu¨sselsatz, der in vielen Antra¨gen an die Regierung gerichtet
ist.
– stellt fest
”
stellt fest“ ist ein Schlu¨sselsatz, der in vielen Antra¨gen die Beobachtung der An-
tragsteller einleitet.
– Bundestag wolle beschließen
Konkrete Aufforderung der Antragsteller u¨ber den zu fassenden Beschluss im Bun-
destag.
Daraus ergibt sich nachfolgendes Event-Schema:
Zum Event geho¨ren
”
Antrag“ die wichtigen Slots Name, Partei und Topic. Bei den letztge-
nannten handelt es sich um Named Entities, denen wir in einem zweiten Schritt eine Seman-
tische Relation geben. So kann, im Regelfall, allen Personen in einem Dokument
”
Antrag“ die
Semantische Rolle
”
Antragsteller“ zugewiesen werden. Korrespondierend ko¨nnen Parteien als
”
AntragstellendePartei“ und das Topic als
”
Inhalt“ des Antrags bezeichnet werden. Durch
die Rollen werden Relationen zwischen den Events mo¨glich.
238
1 <event typ="Antrag">
2 <named_entity typ="Name" semantische_rolle="Beantragt">
Rainer Bru¨derle </ named_entity >
3 <named_entity typ="Name" semantische_rolle="Beantragt">
Birgit Homburger </ named_entity >
4 <named_entity typ="Name" semantische_rolle="Beantragt">
Dr. Karl Addicks </ named_entity >
5 <named_entity typ="Name" semantische_rolle="Beantragt">
Christian Ahrendt </ named_entity >
6 <named_entity typ="Partei" semantische_rolle="Beantragt"
>FDP </ named_entity >
7 <named_entity typ="Topic" semantische_rolle="Forderung">
Mehr Wettbewerb im Schornsteinfegerwesen </ named_entity >
8 <drucksache >1603344 </ drucksache >
9 <datum >08.11.2006 </ datum >
10 <event_id >324234 </ event_id >
11 </event >
Listing 4.2: XML-Event am Beispiel
”
Antrag“
239
Beschlussempfehlung
ˆ Triggerworte
– Beschlussempfehlung
In jeder Drucksache wird
”
Beschlussempfehlung“ als U¨berschrift genutzt.
– Annahme, Ablehnung, Ablehnen, Annehmen
”
Annahme“,
”
Ablehnung“,
”
Ablehnen“,
”
Annehmen“ sind Schlu¨sselwo¨rter, die al-
le im Zusammenhang mit der Empfehlung fu¨r oder gegen einen Antrag genannt
werden ko¨nnen.
– Zustimmung
Bei jeder Empfehlung wird die Zustimmung verschiedener Fraktionen explizit aus-
gedru¨ckt.
– Stimmenthaltung
Auch Stimmenthaltungen werden nach Fraktionen geordnet in der Drucksache an-
gegeben.
– Lo¨sung
Lo¨sung ist ein spezieller Teilbereich jeder Beschlussempfehlung.
– Alternativen
Alternativen kann ein spezieller Teilbereich einer Beschlussempfehlung sein.
– Bundestag wolle beschließen
Konkrete Aufforderung zur Empfehlung fu¨r oder gegen einen Antrag im Bundestag.
Jede Beschlussempfehlung referenziert den vorlaufenden Antrag, also haben wir einen Slot
vom Typ
”
DrucksachenNr“ mit einer Antragsrelation. Ein weiterer Slot speichert das Ergeb-
nis, ist daher vom Typ
”
Ergebnis“. Daneben werden auch die beteiligten Institutionen in
einem Slot gespeichert. Institutionen werden bereits im NER-Lauf erkannt und sind daher
einfach zu erkennen.
Abstimmung
ˆ Triggerworte
– Enthaltungen?,Wer stimmt dagegen,Wer stimmt dafu¨r
”
Enthaltungen?“,
”
Wer stimmt dagegen“,
”
Wer stimmt dafu¨r“ sind Schlu¨sselsa¨tze
mit der der Bundestagspra¨sident jede Abstimmung einleitet.
– Stimmen
Bei abgeza¨hlten Abstimmung werden auch oft die Anzahl der abgegeben Stimmen
bestimmt.
– Abstimmung
Das Wort
”
Abstimmung“ kommt sinnigerweise auch als Triggerwort in Frage.
Das Event
”
Abstimmung“ beinhaltet zwei Slots des Typs
”
DrucksachenNr“ mit einer Semanti-
schen Relation
”
Beschlussempfehlung“ sowie einer Relation zum Antrag. Die Antragsrelation
240
Abbildung 4.14: Schematische Darstellung des Events Beschlussempfehlung
ist eine 1 zu 1 Beziehung. Es gibt also zu jeder Abstimmung auch einen Antrag, allerdings gibt
es nicht zu jedem Antrag eine Beschlussempfehlung, folglich auch nicht zu jeder Abstimmung
eine Relation zu einer Beschlussempfehlung.
Ein weiterer Slot speichert das Ergebnis der Abstimmung, das bereits bei der NER bestimmt
wurde. Anhand dieses Ergebnisses werden die Semantischen Relationen der Parteien be-
stimmt. Einer Partei ist es mo¨glich einer Abstimmung zuzustimmen, abzulehnen oder sich
zu enthalten. Dies wird mit den Semantischen Relationen
”
Zustimmend“,
”
Ablehnend“ oder
”
Enthaltend“ abgebildet. Zur Bestimmung dieser Relationen wird eine Analyse des Satzes
beno¨tigt, in dem die Partei erwa¨hnt wird.
Zwischenruf
ˆ Triggerworte
– ( )
Jeder Zwischenruf in einem Bundestagsprotokoll ist in Klammern gesetzt.
– Heiterkeit, Lachen, Beifall, Zuruf
Werden als Reaktion der Zwischenrufer genannt und kommen dabei sehr ha¨ufig
vor.
Jedes Zwischenruf-Ereignis entha¨lt zwei Slots vom Typ
”
Name“. Einerseits um den Zwischen-
rufer, der dem aktuellen Redner entweder Zustimmend, Ablehnend oder Neutral gesinnt ist,
zu bestimmen. Andererseits gibt es auch einen Slot fu¨r den Redner. Um diesen auszufu¨llen
muss man den Redner des Absatzes vor dem Zwischenruf bestimmen.
241
Abbildung 4.15: Schematische Darstellung des Events
”
Abstimmung“
Jeder Zwischenrufer wird mit einer Semantischen Relation
”
Zustimmend“,
”
Ablehnend“ und
”
Neutral“ abgebildet. Diese Relationen ko¨nnen wieder u¨ber zuvor bestimmte Trigger aus-
gelo¨st werden. Hierzu vergleicht man die Reaktion des Zwischenrufers, die ebenfalls ein Slot
des Events ist, mit den Triggern und findet die passende Relation. Eine Liste dieser speziellen
Trigger befindet sich im Anhang.
Fu¨r ganz einfach Zwischenrufe wie
”
Beifall bei der SPD“ gibt es zusa¨tzlich einen Slot vom Typ
”
Partei“, der ebenfalls ein semantisches Attribut
”
Zustimmend“,
”
Ablehnend“ oder
”
Enthal-
tend“ bekommt.
In der Praxis wurden im Programm die Semantischen Relationen nicht eingesetzt, da dies
zu einer erheblich komplexeren Extraktion gefu¨hrt ha¨tte. Eine Erweiterung diesbezu¨glich,
wu¨rde allerdings einige neue Funktionen in das Programm einbringen. So wa¨re beispielsweise
auch die Darstellung der Meinung eines bestimmten Politikers zu einem bestimmten Thema
mo¨glich.
4.3.3 Relationen zwischen Events
Zwischen den Events ko¨nnen Relationen vorhanden sein. So befindet sich in einem Event
”
Ab-
stimmung“ immer eine Referenz zur Drucksache des Antrags, sowie in den meisten Fa¨llen auch
eine Referenz zu relevanten Beschlussempfehlungen. Hier kann also anhand der Drucksachen-
Nr nach Events vom Typ Antrag gesucht werden und man erha¨lt das passende Event
”
An-
trag“. Eine derartige Verknu¨pfung besteht zwischen fast jedem Event. Ein Zwischenruf-Event
entha¨lt immer das Quellprotokoll in dem man nach Abstimmungen oder Reden suchen ko¨nnte.
Andersherum kann man u¨ber ein Rede-Event und der passenden Text-Stelle die zugeho¨rigen
242
Abbildung 4.16: Schematische Darstellung des Events
”
Zwischenruf“
243
Abbildung 4.17: Zu fu¨llendes Template fu¨r Event
”
Abstimmung“
Zwischenrufe definieren.
4.3.4 Relation Extraction am Beispiel von Abstimmungen
Events ko¨nnen einerseits mit den in Abschnitt [4.3.2] beschriebenen Event-Triggern gefunden
werden, andererseits aber auch u¨ber Relation Extraction [1.5] aus den NE-getaggten Doku-
menten extrahiert werden. Nachfolgend wird in diesem Abschnitt gezeigt, wie die Relation
Extraction aufgebaut ist, wie wir Rapid Miner als automatischen Triggerfinder einsetzen und
welche Ergebnisse wir damit letztlich erzielen konnten.
Formale Notation der Relation Extraction
Da wir die Relation Extraction am Beispiel von Abstimmungen beschreiben wollen, hier
noch einmal ein kurzer U¨berblick u¨ber das zu fu¨llende Template (siehe Abbildung 4.17). Die
einzelnen Slots des Events Abstimmungen sind: Abstimmungstyp (entspricht einem Druck-
sachentyp), Drucksachen-Nr und Abstimmungsergebnis. Die Slots Beschlussempfehlungs-Nr
bzw. Beschlussempfehlungsergebnis sind optional und werden nur dann gefu¨llt, wenn eine
solche Referenz existiert.
Bei der Relation Extraction [1.5] geht es darum eine Beziehung zwischen einer Menge von
Named Entities oder anderen Datenobjekten herzustellen. In diesem Fall interessiert uns nur
die Relation zwischen Named Entities. Diese Relationen sollen nur innerhalb eines Satzes
hergestellt werden, d.h. sowohl die Named Entities, als auch die Relationen befinden sich in
einem Satz. Nehmen wir als Beispiel folgenden Text aus einem Plenarprotokoll:
S1: Die Beschlussempfehlung ist mit den Stimmen der Koalitionsfraktionen und der
FDP-Fraktion bei Enthaltung von Bu¨ndnis 90/Die Gru¨nen angenommen.
Die fettgedruckten Wo¨rter markieren die vorhandenen Named Entities mit folgender Bedeu-
tung:
”
Beschlussempfehlung“ entspricht einem Drucksachentyp (DrsTyp),
”
FDP“ /
”
Bu¨ndnis
90/Die Gru¨nen“ sind Parteien (Par) und
”
angenommen“ ist vom Typ Ergebnis (Erg).
Zwischen diesen Named Entities bestehen zwei verschiedene Relationen R1 und R2, wobei
eine Relation immer aus zwei Entita¨ten e1, e2 besteht.
ˆ R1 entspricht einer ”
ist“ Relationen zwischen DrsTyp als Entita¨t e1 und Erg als Entita¨t
e2. Umgangssprachlich beschreibt R1(DrsTyp,Erg) also, dass ein bestimmter Druck-
sachentyp entweder angenommen oder abgelehnt worden ist.
244
Abbildung 4.18: Schematische der Relationen im Event
”
Abstimmung“
ˆ Relation R2 besteht zwischen Par und DrsTyp und ist eine ”
stimmt zu“-Relation. Um-
gangssprachlich beschreibt die Relation R2(Par,DrsTyp) alle Parteien, die einer Druck-
sache in einer Abstimmung zustimmen.
Die Notation erfolgte nach [BM05]. Beide Relationen kann man auch in einem Graphen ver-
deutlichen.
Aufbau des Rapid Miner Experiments
U¨blicherweise wird Relation Extraction u¨ber Dependency Tree Kernels [CS03] oder verschie-
denen Optimierungen wie Shortest Path Dependency Kernels [BM05] realisiert. Die Grundi-
dee dabei ist es, zu jeder Entita¨t einen Feature Vector aufzubauen, u¨ber den die Bedeutung
innerhalb eines Satzes gewonnen wird. Dies kann eine POS-Bestimmung, aber auch die Suche
nach Synonymen oder Oberbegriffen sein.
Da Abstimmungen in den Plenarprotokollen relativ homogen aufgebaut sind und von der
Struktur immer gleich ablaufen, werden wir nachfolgend die Relation Extraction mit Hilfe
des Rapid Miners beschreiben, wo wir ein a¨hnliches Verfahren wie bei der Named Entity
Recognition anwenden und dabei als Feature das Preprocessing sowie die erkannten Named
Entities nutzen. Da die weiter oben im Abschnitt 4.2 beschriebenen Named Entities fu¨r dieses
Verfahren nicht ausreichen wu¨rden, wurde die Menge der Named Entities um das Ergebnis
(Erg) von Abstimmungen sowie den Drucksachentypen (DrsTyp) erweitert. Dies ermo¨glicht
in einem nachfolgenden Schritt die Erkennung von Abstimmungen.
Fu¨r die Erweiterung der NER wurden zwei Protokolle per Hand annotiert und dieses Mo-
dell mit dem ebenfalls in 4.2 beschriebenen Verfahren trainiert. Auf Basis dieser Protokolle
konnten bei 10-facher Kreuzvalidierung die in der Tabelle beschriebenen Ergebnisse fu¨r die
einzelnen Named Entities erzielt werden. Die Laufzeit wurde auf einem 3,0Ghz PC mit 4096
MB Arbeitspeicher unter Windows Vista gemessen.
245
Wa¨hrend die Ergebnisse in fast allen Bereichen sehr gut ausfallen und auch die Gesamtper-
formance mit einem F-Measure von 89, 1% gut ist, fa¨llt gerade das Ergebnis der Entita¨t
”
Erg“
ins Auge. Hier konnte nur ein F-Measure von 13, 5% erzielt werden. Grund dafu¨r ko¨nnte eine
unzureichende Tokenmenge in den handmarkierten Protokollen sein. Wa¨hrend Entita¨ten wie
”
DrsTyp“,
”
Par“ oder
”
Name“ in allen Protokollen sehr ha¨ufig vorhanden sind, kommt
”
Erg“
jeweils nur bei den Abstimmungen vor.
In einem zweiten Schritt soll dann mit Rapid Miner ein Trainingsmodell fu¨r die oben ge-
nannten Trigger-Sa¨tze erstellt werden. Bevor Rapid Miner aus den per Hand markierten
Sa¨tzen lernen kann, werden, wie bei der NER [4.2], die Attribute der Preprocessing-Schritte
als Feature genutzt. Auch wird das NER-Modell auf den Datensatz angewendet, so dass wir
im Trainingsschritt fu¨r die Abstimmungssa¨tze Named Entities zur Erkennung der Relationen
in einem Satz nutzen ko¨nnen. Als Lernverfahren werden dabei Conditional Random Fields
benutzt 1.2.4.
Insgesamt wurden in 10 Plenarprotokollen die relevanten Sa¨tze (vgl. S1) am Ende einer Ab-
stimmung markiert. Leider konnten jedoch nicht alle Plenarprotokolle fu¨r den Trainings-
lauf genutzt werden. Sowohl am Lehrstuhl als auch auf dem heimischen Rechner war der
Arbeitsspeicher dafu¨r zu knapp bemessen. Insofern kann man schon an dieser Stelle einen
Schwachpunkt der Ergebnisse festmachen, denn dieses beruht nicht auf den kompletten zur
Verfu¨gung stehenden Trainingsdaten, sondern lediglich auf zwei jeweils einzelnen Protokollen.
Hier wa¨re ein inkrementelles Lernverfahren wu¨nschenswert.
Nachdem wir ein Modell fu¨r die NER und ein Modell fu¨r die Erkennung der Abstimmun-
gen vorliegen haben, ko¨nnen wir in einem dritten Schritt komplett unmarkierte Dokumente
mit Marken fu¨r Named Entities und Marken fu¨r Abstimmungen versehen. Zur Messung der
Performance wurden dabei verschiedene Protokolle unter unterschiedlichen Bedingungen au-
tomatisch markiert. Eine genauere Auswertung der Ergebnisse erfolgt im na¨chsten Abschnitt
dieses Kapitels.
Ergebnisse der automatischen Trigger-Suche
Zur Messung der Performance wurden zwei Trainingsmodelle fu¨r die Suche nach Abstimmun-
gen gelernt. Diese Trainingsmodelle basieren auf markierten Abstimmungen mit den weiter
oben genannten Relationen R1(DrsTyp,Erg) sowie R2(Par,DrsTyp). Als Protokolle dienten
hierfu¨r Plenarprotokoll 16/85 sowie 16/102. Protokoll 16/85 bietet 12 markierte Abstimmun-
gen, Protokoll 16/102 sogar 41, also mehr als dreimal so viele Abstimmungen, was sich auch
auf die Ergebnisse auswirken kann.
Anhand dieser Lernmodelle wurden jeweils fu¨nf unterschiedliche Protokolle automatisch mar-
kiert und das Ergebnis mit den per Hand markierten Dokumenten verglichen. Zur U¨berpru¨fung
der Ergebnisse wurde dasselbe Verfahren nocheinmal ohne ein Preprocessing, also nur mit
Named Entities, getestet und die Performance gepru¨ft. Ein Vergleichswert liefert ebenso ein
Durchlauf, der die Abstimmungen nur anhand des Preprocessing erkennt.
Insgesamt erkennt man in Tabelle 4.4 eine relativ hohe Schwankungsbreite der Ergebnisse.
Wa¨hrend gerade bei kleinen Protokollen (P16/50) der F-Measure relativ gut ist, geht dieser
Wert bei sehr langen Protokollen (P16/102) doch merklich zuru¨ck. Interessant ist auch die
Tatsache, dass bei Protokoll 102, welches sowohl als Lernmodell als auch als Testprotokoll
benutzt wurde, trotzdem keine perfekten Ergebnisse zustande kamen. Natu¨rlich ist diese eine
Zeile trotzdem nicht ganz repra¨sentativ. Insgesamt liegt der F-Measure gemittelt u¨ber alle
246
Testprotokolle bei 73 bzw. 72 Prozent.
In Tabelle 4.5 sind die Lernergebnisse fu¨r den Fall, dass kein Preprocessing stattfindet, ein-
getragen. Hier erkennt man einen deutlichen Unterschied zwischen den beiden Lernmodellen.
Wa¨hrend Modell P16/85, das deutlich weniger Abstimmungen besitzt, mit einem F-Measure
von 42% schlecht abschneidet, kann das Lernmodell P16/102 mit 64% deutlich besser perfor-
men.
Dabei ist zu erwa¨hnen, dass die hohe Fehlerrate besonders durch den Header in den Protokol-
len verursacht wird. Fast alle Fehler sind so zustande gekommen. Die Relationen zwischen den
Entita¨ten werden zumeist sehr gut erkannt und pra¨zise abgegrenzt, ein deutlicher Unterschied
zu der folgenden Methode, wo nur das Preprocessing zur Erkennung genutzt wurde.
In Tabelle 4.6 sind die Ergebnisse der Relation Detection auf einem Lernmodell, das nur auf
Preprocessing beruht, eingetragen. Auch hier schneidet das Modell mit der ho¨heren Anzahl
an markierten Abstimmungen besser ab (P16/102) und liefert gleichzeitig den besten Wert
mit 88% F-Measure. Die Ergebnisse waren in diesem Fall allerdings deutlich unscha¨rfer. Mar-
kierungen fu¨r Abstimmungen wurden teilweise schon im Satz davor begonnen oder endeten
erst einen Satz spa¨ter. Solang die Relationen exakt enthalten waren, wurde dies als korrekt
gewertet. Aus diesem Grund wurde die Performance der Relation Detection (mit ausschließ-
lichem Preprocessing) nochmals mit exakter Abgrenzung der Abstimmungen gemessen. Wie
bereits erwa¨hnt, wurde in Tabelle 4.6 auch eine unscharfe Abgrenzung zugelassen, solang
das Extraktionsergebnis davon nicht beeinflusst wa¨re, es also trotzdem die in Abschnitt 4.3.4
beschriebenen Relationen, und nur diese, liefert.
In Tabelle 4.7 erkennt man einen deutlichen Einbruch der Werte, wenn man nur noch exakte
Markierungen fu¨r die Abstimmungen zula¨sst. So sinkt der F-Measure des Lernmodells auf
Basis von P16/85 von 74% auf 22%. Hier zeigt sich im Vergleich mit Tabelle 4.4, dass die
Extraktion mit ausschließlichem Preprocessing Probleme hat, den Bereich abzugrenzen. Mit
Named Entities als Feature ist dieses Problem hingegen nicht vorhanden.
Die abschließende Bewertung der Ergebnisse fa¨llt relativ schwierig aus. Es zeigt sich, dass ein
Preprocessing wichtig ist um Streufehler zu vermeiden. Allerdings ist auch die reine Erken-
nung mittels Named Entities erfolgreich und vor allem hinsichtlich der Extraktionsgenauigkeit
wichtig. Wie in Tabelle 4.7 gezeigt, ist dies ein großes Problem, wenn man keine Named En-
tities benutzt.
Wenn man das Lernmodell erweitern ko¨nnte, so dass mehr Abstimmungen in den Operator
einfließen, ko¨nnte das Ergebnis deutlich besser ausfallen. Die besten Ergebnisse bezu¨glich der
Erkennung sind daru¨berhinaus bei einem etwas verringerten Preprocessing und in Verbindung
mit der NER zu erwarten.
4.4 Datenextraktion
4.4.1 Extraktion von Relationen zwischen Protokollen und Drucksachen
Der Relation-Builder erstellt einen einfachen Index, der alle referenzierten Drucksachen eines
Plenarprotokolls auflistet. Wichtig ist dies, da wir in den verschiedenen Komponenten unseres
Systems wissen mu¨ssen, wo wir nach Inhalten suchen ko¨nnen. Beispielsweise ist es wichtig zu
wissen, wann ein bestimmter Antrag in einem Plenarprotokoll besprochen bzw. u¨ber diesen
abgestimmt wurde, da wir diese Informationen nicht aus der Drucksache geliefert bekommen.
Ebenso wir der Index bei der Erstellung des Lucene-Index beno¨tigt.
247
x 10
Laufzeit 1590 min
Tag P R F
ORG 0.821± 0.100 0.700± 0.070 0.751± 0.062
PERS 0.954± 0.056 0.930± 0.102 0.941± 0.081
REAC 0.994± 0.018 0.994± 0.009 0.994± 0.012
LOC 0.838± 0.261 0.505± 0.226 0.597± 0.221
NAME 0.879± 0.209 0.812± 0.099 0.824± 0.159
PAR 0.978± 0.021 0.978± 0.015 0.978± 0.013
BUR 0.944± 0.038 0.904± 0.063 0.922± 0.041
DrsTyp 0.844± 0.161 0.835± 0.162 0.828± 0.146
Erg 0.233± 0.396 0.100± 0.166 0.135± 0.224
Drucksache 0.463± 0.466 0.467± 0.476 0.464± 0.469
Gesamt 0.916± 0.139 0.879± 0.044 0.891± 0.091
Tabelle 4.3: Ergebnisse der erweiterten NER-Testla¨ufe auf zwei markierten Protokollen
Lernmodell P16/85 P16/102
Testprotokoll P R F P R F
P16/41 100% 66, 00% 72, 00% 72, 73% 66, 67% 69, 57%
P16/50 100% 100% 100% 100% 100% 100%
P16/102 100% 46, 67% 63, 64% 100% 80, 00% 88, 89%
P16/103 87, 50% 51, 22% 64, 62% 59, 09% 31, 71% 41, 27%
P16/109 83, 33% 55, 56% 66, 67% 71, 43% 55, 56% 62, 50%
Gesamt 94, 17% 63, 89% 73, 38% 80, 65% 66, 79% 72, 44%
Tabelle 4.4: Performance der automatischen Triggersuche (mit Preprocessing und NER)
Lernmodell P16/85 P16/102
Testprotokoll P R F P R F
P16/41 66, 00% 33, 00% 44, 00% 87, 50% 58, 33% 70, 00%
P16/50 14, 29% 40, 00% 21, 05% 100% 100% 100%
P16/102 93, 75% 100% 96, 77% 26, 67% 80, 00% 40, 00%
P16/103 30, 77% 29, 27% 30, 00% 50, 00% 43, 90% 46, 75%
P16/109 15, 38% 22, 22% 18, 18% 48, 65% 100% 65, 45%
Gesamt 44, 04% 44, 90% 42, 00% 62, 56% 76, 45% 64, 44%
Tabelle 4.5: Performance der automatischen Triggersuche (nur NER)
Lernmodell P16/85 P16/102
Testprotokoll P R F P R F
P16/41 100% 66, 00% 72, 00% 83, 33% 83, 33% 83, 33%
P16/50 100% 80, 00% 100% 100% 100% 100%
P16/102 80, 00% 53, 33% 64, 00% 91, 67% 73, 33% 81, 48%
P16/103 80, 00% 58, 54% 67, 61% 89, 19% 80, 49% 84, 62%
P16/109 87, 50% 77, 78% 82, 35% 89, 47% 94, 44% 91, 89%
Gesamt 89, 50% 67, 13% 74, 97% 90, 73% 86, 32% 88, 26%
Tabelle 4.6: Performance der automatischen Triggersuche (nur Preprocessing)
248
Der Relation-Builder ist eine Java Komponente (im Java-Projekt BTPBTDRelationXML
genannt), die mit Hilfe von Regular Expressions nach Drucksachen-Referenzierungen in Plen-
arprotokollen sucht und diese geordnet in XML-Dateien ablegt.
4.4.2 Vorgehensweise der Referenz-Extraktion
Die Erstellung der XML Datei erfolgt in drei Schritten:
1. Finden von Drucksachennummern,
2. Vermeidung doppelter Vorkommen,
3. Ablage in XML-Datei.
Das Finden der Drucksachennummern ist mit Hilfe von Regular Expression realisierbar.
Zuna¨chst wird nach dem Ausdruck
”
(Drucksache|Drucksachen|Drs)1[4, 5, 6]
/[0− 9]1, 5“ gesucht, was sicherstellt, dass alle extrahierten Nummern wirklich den Drucksa-
chen zugeho¨rig sind. Mo¨glich wa¨ren auch Plenarprotokoll-Nummern, da diese ebenfalls in den
Reden genannt werden. Haben wir einen solchen String gefunden, trennen wir die einleiten-
den
”
Drucksachen“ ab und leiten den restlichen String zur Speicherung weiter. Zur Speiche-
rung der XML nutzen wir den XMLOutputter der jdom-Klasse. Als root-Knoten haben wir
”
BTP2BTD“ gewa¨hlt, danach folgt direkt die Aufteilung nach Wahlperiode und Plenarpro-
tokoll. Beide tragen als Parameter die jeweilige Nummer. Alle Drucksachen sind unterhalb
des BTP-Knotens in einem BTD-Knoten eingetragen. Ein doppelter Eintrag wird durch die
vorherige Pru¨fung auf ein vorhandenes Vorkommen vermieden. Die daraus entstehende XML
sieht dann wie in Abbildung 4.19 aus.
4.4.3 Der umgedrehte Fall: BTD2BTP
Wie man in Abbildung 4.19 sieht, ist durch eine einfache XML-Anfrage nur der Weg von den
Plenarprotokollen nach den Drucksachen zu beantworten. Fu¨r den umgedrehten Fall, dass
wir zu einer Drucksache alle Vorkommen in den Plenarprotokollen haben mo¨chten, wurde
eine Methode getProtokolleByDrs(String Drs) in der Klasse BTPBTDQuery implementiert.
Diese fragt die Elternknoten der BTD-Knoten ab und gibt als Ausgabe ein String-Array der
betreffenden Protokolle aus.
4.4.4 Extraktion von Reden
Fu¨r die Dossiererstellung ist es notwendig, dass wir Zugriff auf jede im Bundestag gehaltene
Rede bekommen. Alle Reden werden in den Bundestagsprotokollen, die im PDF-Format auf
http://dip.bundestag.de/ vorliegen, festgehalten. Da in einem Protokoll eine Vielzahl von ge-
haltenen Reden dokumentiert sind, und diese Dokumente einige 1000 Zeilen lang sein ko¨nnen,
ist ein schneller Zugriff auf eine einzelne Rede innerhalb des Dokuments nicht mo¨glich. Daher
ist die organisierte Ablage der Reden extrem wichtig. Nachdem wir die Reden einzeln extra-
hiert und einem Politiker zugeordnet haben, kommen diese in einen eigenen Lucene-Index,
der alle Reden entha¨lt. Folgende Aufgaben mu¨ssen dabei bewa¨ltigt werden:
ˆ (1) Zerlegung des gesamten Bundestagprotokolls in einzelne Sa¨tze,
249
Lernmodell P16/85 P16/102
Testprotokoll P R F P R F
P16/41 87, 50% 58, 33% 72, 00% 75, 00% 75, 00% 75, 00%
P16/50 0, 00% 0, 00% 0, 00% 60, 00% 60, 00% 60, 00%
P16/102 25, 00% 13, 33% 17, 39% 91, 67% 73, 33% 81, 48%
P16/103 22, 22% 14, 63% 17, 65% 59, 46% 53, 66% 56, 41%
P16/109 6, 67% 5, 56% 6, 06% 66, 67% 66, 67% 66, 67%
Gesamt 28, 28% 18, 37% 22, 62% 70, 65% 65, 73% 67, 91%
Tabelle 4.7: Performance der automatischen Triggersuche mit scharfer Abrenzung (nur
Preprocessing)
Abbildung 4.19: Der Inhalt der XML-Index-Datei
250
ˆ (2) Suchen nach dem Beginn der Reden,
ˆ (3) Erkennung von einzelnen Redeabschnitten,
ˆ (4) Zuordnung der Politiker,
ˆ (5) Erkennung von Zwischenrufen innerhalb dieser Reden,
ˆ (6) Split der Zwischenrufe nach Politiker.
Der so genannte SpeechExtractor ist eine Java Komponente, die mit Hilfe von regular expres-
sions einzelne Reden in XML-Dateien ablegt. Die Klasse SpeechExtractor ist dabei Teil des
speechex Pakets im repository-Builder.
Problematik der Reden-Extraktion
Bei der Erfu¨llung der oben gestellten Aufgabe wurde schnell klar, dass durch die Konvertie-
rung der PDFs in das ASCII-Format einige Schwierigkeiten auftauchten. So kann es vorkom-
men, dass in den Protokollen ganze Ketten von Zeichen an der falschen Stelle stehen oder
auseinandergezogen werden und an anderer Stelle wieder auftauchen. Eine weitere Schwierig-
keit, die bei der Extraktion umgangen werden musste, war die Einleitung der Politiker-Reden.
Normalerweise geschieht diese in der Form Vorname, Name [Parteizugeho¨rigkeit]. In
vielen Dokumenten wurde bei der Konvertierung die Reihenfolge vertauscht zu [Parteizu-
geho¨rigkeit] Vorname, Name was ebenfalls einiges an Mehraufwand beim Finden der
Reden erfordert. Grund fu¨r diese Fehler ist das PDF-Format der Bundestagsprotokolle. Hier
kann es passieren, dass der Text einspaltig, zweispaltig oder dreispaltig geschrieben ist, was
bei der Konvertierung in das ascii-Format zu Problemen fu¨hrt. Auch werden die im vorigen
Abschnitt beschriebenen Einleitungen teilweise vertauscht.
4.4.5 Der Prozess der Reden-Extraktion
Jedes Protokoll wird vom SpeechExtractor zuna¨chst eingelesen und mit Hilfe des Sentence
Splitters in einzelne Sa¨tze unterteilt. Da jedem Protokoll eine Inhaltsangabe und eine Auflis-
tung der teilnehmenden Abgeordneten vorausgeht, wird zuna¨chst nach dem Beginn der Re-
deabschnitte gesucht. Sobald dieser gefunden ist, markieren wir die Stelle mit einem<content/>-
Tag. Alle Reden mu¨ssen sich nachfolgend innerhalb dieses Elements befinden.
Die Suche nach dem Beginn der einzelnen Reden ist schwieriger. Hier ko¨nnen wir uns zur
Hilfe machen, dass u¨blicherweise der Bundestagspra¨sident jeden einzelnen Redner aufruft.
Wir suchen also in einem Satz nach dem Vorhandensein von
”
pra¨sident“ und der Beendigung
des Satzes mit einem Doppelpunkt, da hiermit der Redner eingeleitet wird. Abbildung 4.20
zeigt ein Beispiel anhand eines PDF-Dokuments.
Alles was zwischen dem na¨chsten Vorkommen des oben genannten Triggers steht, wird in
der XML-Datei als Rede erfasst und mit einer eindeutigen ID sowie der Anzahl von Wo¨rtern
und Sa¨tzen , als Parameter, abgelegt. Da wir allerdings als Rede nicht das Preludium des
Pra¨sidenten haben mo¨chten, unterteilt sich jede Rede in ein Preludium, das wiederum einem
bestimmten Akteur, na¨mlich den Pra¨sidenten, entha¨lt. Um das Preludium vom restlichen
251
Abbildung 4.20: Beispiel fu¨r den Beginn einer Rede
Abbildung 4.21: Repra¨sentation der Rede in der XML
Redetext abzutrennen, suchen wir in der erfassten Rede, innerhalb der na¨chsten Sa¨tze nach
einem neuen Redner. Wird ein Redner gefunden, ko¨nnen wir sicher sein, dass es sich um einen
neuen Redner handelt und markieren alle vorangeganen Sa¨tze als Preludium, alle Nachfolger
erhalten hingegen die Kennzeichnung des Akteuers mit einem <actor> Element und den
Parametern Rolle, Name, Partei und mopsid. Die Rolle beschreibt, dass es sich bei diesem
Akteur um eine Person handelt und nicht etwa um eine Partei, wie es beispielsweise bei
Zwischenrufen der Fall sein kann. Der Name, Partei und mopsid werden aus der Members
of Parliament-Datenbank gewonnen, die eine Liste aller Bundestagsabgeordneter mit einer
zugeho¨rigen ID entha¨lt.
Damit wir dieses Programm allerdings auch ansprechen ko¨nnen, mu¨ssen wir den Namen des
Abgeordneten ohne Titel in unserem Redetext finden. Auch hier werden eine Reihe von Re-
gular Expressions benutzt um den Namen in der Redeeinleitung zu finden. Unterscheiden
muss man den weiter oben geschilderten Fall, dass die Reihenfolge der Namensaufrufe va-
riieren kann, den Aufruf von Bundesministern, den Aufruf von Pra¨sidenten sowie der/des
Bundeskanzler/in. Damit hat die bis jetzt entstanden XML-Datei folgendes Aussehen:
Extraktion von Zwischenrufen innerhalb von Reden
In jeder Rede gibt es eine Menge an Zwischenrufen. Diese ko¨nnen entweder von einer ganzen
Fraktion oder auch von einzelnen Abgeordneten ausgehen. Beifall oder Heiterkeit wa¨ren Re-
aktionen einer ganzen Partei, wa¨hrend es bei einzelnen Abgeordneten auch mo¨glich ist Fragen
zu stellen oder zu widersprechen. Da die erkannten Reden auch nur Reden des Abgeordneten
enthalten sollten und keine Zwischenrufe, werden diese markiert und fu¨r eine Analyse ebenfalls
einer Partei oder einem Abgeordneten zugeordnet. Das Erkennen dieser Zwischenrufe kann
mittels Regular Expressions realisiert werden, da jeder Zwischenruf in Klammern steht. Es
252
Abbildung 4.22: Repra¨sentation der Rede mit Preludium und Aktuer
Abbildung 4.23: Zwischenrufe im PDF-Dokument
muss als nur gepru¨ft werden, ob der Inhalt innerhalb der Klammern auch einem Zwischenruf
entspricht, was durch den Aufruf eines Abgeordneten oder auch einer Reaktion einer Partei
passieren kann. Diese Reaktionen sind relativ eng begrenzt und im Programm als Trigger-Liste
gegeben. Sobald ein Zwischenruf erkannt wurde, markieren wir dieses mit dem <interjection>
Element und splitten innerhalb des Zwischenrufs nach verschiedenen Reaktionen. In einem
Zwischenruf ko¨nnen mehrere Reaktionen festgehalten sein, so dass diese Prozedur no¨tig ist.
Im <interjection> Tag ist daher auch noch einmal der komplette Zwischenruf vorhanden,
wa¨hrend innerhalb des <actor> Elements nur der Beitrag des Akteurs enthalten ist. Genau
wie bei der Annotation der Reden gibt es zu jedem Zwischenruf eine eindeutig ID bestehen
aus Protokollnummer, Redennummer und einer Laufnummer des Zwischenrufs. In Abbildung
4.24 sehen wir ein Beispiel fu¨r die Repra¨sentationd er Zwischenrufe.
Ergebnisse
Der SpeechExtractor extrahiert Reden aus den Bundestagsprotokollen und annotiert dazu
ein mo¨gliches Preludium sowie alle Zwischenrufe innerhalb der Reden. Die Extraktion der
Zwischenrufe ist durch die gute Markierung im Text kein Problem. Probleme entstehen bei der
Extraktion der Reden sowie der Erfassung des Akteurs. Hintergrund ist hier die Problematik
der Umwandlung von PDF nach ASCII.
Abbildung 4.24: Repra¨sentation der Zwischenrufe in Reden
253
Abbildung 4.25: Beispiel fu¨r eine typische Abstimmung innerhalb des Plenarprotokolls
4.4.6 Extraktion von Abstimmungen
Damit wir Aussagen u¨ber das Abstimmungsverhalten der verschiedenen Parteien oder Per-
sonen mit Hilfe von Rapid Miner machen ko¨nnen, mu¨ssen wir die Abstimmungen zuna¨chst
aus den Bundestagsprotokollen extrahieren und in einer XML abspeichern. Bevor wir die
Komponente na¨her beschreiben, sehen wir in Abbildung 4.25 ein Beispiel fu¨r eine typische
Abstimmung innerhalb eines Plenarprotokolls.
Das Programm BTPExtract ist eine Java Komponente (im Java-Projekt BTPContent), die
mit Hilfe von Regular Expressions nach Abstimmungen innerhalb der Plenarprotokolle sucht
und mit Hilfe eines Sliding Window u¨ber den Stringdaten, relevante Informationen zu den
Abstimmungen extrahiert.
Vorgehensweise der Abstimmungs-Extraktion
Die Erstellung der XML Datei erfolgt in fu¨nf Schritten:
1. Finden von Abstimmungstextstellen in den Protokollen anhand von Triggern,
2. Extraktion des Abstimmungsergebnis,
3. Extraktion der Drucksachen,
4. Extraktion der Empfehlung.
Finden von Abstimmungstextstellen Sobald wir den Text des Plenarprotokolls eingelesen
haben, gehen wir Satz fu¨r Satz durch diesen Text und suchen nach Triggern fu¨r Abstim-
mungen im Bundestag. Das satzweise Durchlaufen des Textes wird durch den Sentence
254
Abbildung 4.26: Beispiel fu¨r die Relation zwischen Drucksache und Abstimmung
Splitter 3.3 ermo¨glicht, der Markierungen fu¨r jedes Satzenden innerhalb des Textes an-
legt. In nahezu allen Fa¨llen wird einer der Trigger
”
Enthaltungen?“,
”
entha¨lt sich?“
oder
”
enthalten?“ genannt, so dass wir unseren Text nach Fundstellen dieser Trigger
durchsuchen. Wichtig ist fu¨r die weitere Extraktion der Abstimmung, dass wir ein festes
Extraktionsfenster wa¨hlen, da wir sicherstellen mu¨ssen, das nur Daten zur gefundenen
Triggerstelle bzw. zur Abstimmungstelle gefunden werden.
In diesem Fall betra¨gt das Fenster 7 Zeilen nach hinten bzw. 1 Zeile nach vorn, ausge-
hend von der Triggerstelle.
Extraktion des Abstimmungsergebnis Das Abstimmungsergebnis wird in jedem Plenarpro-
tokoll direkt nach der Frage zur Abstimmung genannt. Wir suchen also direkt in der
na¨chsten Zeile nach Vorkommen von
”
angenommen“ oder
”
abgelehnt“. Falls wir ein sol-
ches Vorkommen finden, endet an dieser Stelle die Extraktion des Abstimunngsergebnis,
andernfalls suchen wir auch noch in den na¨chsten 4 Zeilen nach einem Ergebnis und
stoppen, sobald ein solches gefunden wurde.
Extraktion der Drucksachen In jeder Abstimmung kommen eine Vielzahl von Drucksachen
vor. So gibt es zu einem Antrag auch eine oder mehrere Beschlussempfehlungen und
Berichte oder es ko¨nnen A¨nderungsantra¨ge referenziert werden. Daher ist es wichtig,
zu jeder extrahierten Drucksache zu pru¨fen, um welchen Typ es sich handelt. Hierzu
benutzen wir den BTD-Index, der zu jeder Drucksachennummer den zugeho¨rigen Typ
abspeichert. Falls nun dieser zuru¨ckgegebene Typ, mit dem Typ des zuvor extrahierten
Abstimmungstyps in der Ergebniszeile, u¨bereinstimmt, u¨bernehmen wir die Drucksa-
chennummer als Drucksache der Abstimmung.
Alle anderen vorkommenden Drucksachen werden als Related Documents zu dieser Ab-
stimmung abgespeichert. So ko¨nnen Hinweise auf vorhandene Beschlussempfehlungen
ebenfalls nu¨tzlich sein und werden in der XML-Datei abgelegt.
Extraktion der Empfehlung Im Zusammenhang mit einer Abstimmung wird oft auch das
Ergebnis der Beschlussempfehlung genannt. Damit wir direkt anhand der Daten un-
serer XML-Datei entscheiden ko¨nnen, ob bei einer Zustimmung, die Zustimmung zur
Beschlussempfehlung oder aber die Zustimmung zum Antrag gemeint ist, speichern wir
das Ergebnis dieser Beschlussempfehlung mit ab. Daher ist es auch wichtig zu wissen,
auf welche Drucksache sich die Annahme oder Ablehnung bezieht. Nur so ko¨nnen wir
die Abstimmung sinnvoll nachvollziehen.
255
Abbildung 4.27: XML-Repra¨sentation der Abstimmungen
Ablage in XML-Datei
Die extrahierten Daten werden in einer XML, nach Legislaturperiode und Protokollnummer
sortiert, abgespeichert. In jedem Protokollknoten gibt es eine Datumsknoten sowie eine Reihe
von
”
VOTE“-Knoten, die das Ergebnis der Abstimmungen speichern. Jeder
”
VOTE“-Knoten
hat als Kinder Knoten vom Typ
”
TYPE“,
”
RESULT“,
”
TO“,
”
TONR“ und kann
”
RELA-
TED“-Knoten enthalten. Im Knoten
”
TYPE“ wird als Attribut die Drucksachennummer
(
”
drs“), auf die sich die Abstimmung bezieht sowie, falls vorhanden, die Empfehlung (
”
emp-
fehlung“) aus einer vorhandenen Beschlussempfehlung gespeichert. Im Element selbst steht
der Abstimmungstyp, also eine Information, die angibt, u¨ber welchen Drucksachentyp hier
abgestimmt wurde.
Der
”
RESULT“-Knoten speichert lediglich das Ergebnis der Abstimmung, so wie es dort vor-
kommt. In der Regel also
”
abgelehnt“ oder
”
angenommen“. Im
”
RELATED“-Knoten befinden
sich weitere zu dieser Abstimmung zugeho¨rige Drucksachen mit Typ und Nummer.
Die letzten beiden Knoten
”
TO“ und
”
TONR“ speichern einserseits den echten Tagesord-
nungspunkt innerhalb der Protokollsitzung, andererseits die laufende Tagesordnungspunkt-
nummer der Sitzung. Hintergrund ist hier, dass nicht alle Tagesordnungspunkte mit der Num-
merierung u¨bereinstimmen. Es kann also vorkommen, dass eine Sitzung bereits bei Punkt 2
oder 3 anfa¨ngt. Nu¨tzlich ko¨nnen diese Informationen sein, wenn wir Gru¨nde fu¨r ein bestimm-
tes Abstimmungsverhalten suchen.
256
Deutscher Bundestag Drucksache 16/128
16. Wahlperiode 01. 12. 2005
Antrag
der Abgeordneten Gisela Piltz , Sibylle Laurischk , Sabine Leutheusser-
Schnarrenberger , Jens Ackermann , Dr. Karl Addicks , Christian Ahrendt , Rainer
Bru¨derle , Angelika Brunkhorst , Ernst Burgbacher , Patrick Do¨ring , Mechthild
Dyckmans , Jo¨rg van Essen , Otto Fricke , Paul K. Friedhoff , Horst Friedrich
(Bayreuth), Dr. Edmund Peter Geisen , Hans-Michael Goldmann , Miriam Gruß ,
Joachim Gu¨nther (Plauen), Dr. Christel Happach-Kasan , Heinz-Peter Haustein ,
Birgit Homburger , Dr. Werner Hoyer , Michael Kauch , Dr. Heinrich L. Kolb , Hellmut
Ko¨nigshaus , Gudrun Kopp , Ju¨rgen Koppelin , Heinz Lanfermann , Ina Lenke ,
Horst Meierhofer , Patrick Meinhardt , Jan Mu¨cke , Burkhardt Mu¨ller-So¨nksen ,
Dirk Niebel , Hans-Joachim Otto (Frankfurt), Detlef Parr , Jo¨rg Rohde ,
Dr. Konrad Schily , Marina Schuster , Dr. Hermann Otto Solms , Dr. Max Stadler ,
Dr. Rainer Stinner , Carl-Ludwig Thiele , Florian Toncar , Christoph Waitz ,
Dr. Claudia Winterstein , Dr. Volker Wissing , Hartfrid Wolff (Rems-Murr),
Martin Zeil , Dr. Wolfgang Gerhardt und der Fraktion der FDP
Gegen eine europaweit verpflichtende Vorratsdatenspeicherung
Der Bundestag wolle beschließen:
I. Der Deutsche Bundestag stellt fest:
1. Der Deutsche Bundestag bekra¨ftigt angesichts des nunmehr vorliegenden
. . .
Abbildung 4.28: Eine Beispieldrucksache mit Makierungen der Attribute
4.4.7 Extraktion der Attribute aus Drucksachen
Um Referenzen zwischen verschiedenen Dokumenten, Personen und sonstigen Entita¨ten her-
stellen zu ko¨nnen, mu¨ssen auch fu¨r Drucksachen festgelegte Attribute aus diesen extrahiert
werden. Dies wurde bereits fu¨r andere Entita¨ten erkla¨rt, z.B. fu¨r Personen in Kapitel 4.1, fu¨r
Protokolle in 4.4.6 und fu¨r Reden in 4.4.4.
Drucksachenattribute
Fu¨r eine Drucksache haben wir uns darauf geeinigt, dass folgende Attribute extrahiert werden
mu¨ssen (in kursiv ist immer ein explizites Beispiel angegeben, welches aus dem Beispiel aus
Abbilung 4.4.7 entnommen wurde):
ˆ Nummer - 16/128
ˆ Legislaturperiode - 16
ˆ Datum - 01.12.2005
ˆ Typ - Antrag
257
〈BTD INDEX〉
〈LEGISLATIVE PERIOD number=”14”〉
〈DOC id=”14348”〉
〈NR〉16/128〈/NR〉
〈DATE〉01.12.2005〈/DATE〉
〈TYPE〉Antrag〈/TYPE〉
〈TITLE〉Gegen eine europaweit verpflichtende Vorratsdatenspeicherung〈/TITLE〉
〈AUTHORS〉
〈AUTHOR id=”000849”〉Gisela Piltz〈/AUTHOR〉
〈AUTHOR id=”000813”〉Sibylle Laurischk〈/AUTHOR〉
〈AUTHOR id=”000220”〉Sabine Leutheusser-Schnarrenberger〈/AUTHOR〉
〈AUTHOR id=”001070”〉Jens Ackermann〈/AUTHOR〉
〈AUTHOR id=”000702”〉Karl Addicks〈/AUTHOR〉
. . .
〈AUTHOR id=”001064”〉Hartfrid Wolff〈/AUTHOR〉
〈AUTHOR id=”001067”〉Martin Zeil〈/AUTHOR〉
〈AUTHOR id=”000103”〉Wolfgang Gerhardt〈/AUTHOR〉
〈AUTHOR id=”−1”〉FDP〈/AUTHOR〉
〈/AUTHORS〉
〈/DOC〉
〈/LEGISLATIVE PERIOD〉
〈/BTD INDEX〉
Abbildung 4.29: Die Beispieldrucksache im XML-Format des Btd-Indexes
ˆ Titel - Gegen eine europaweit verpflichtende Vorratsdatenspeicherung
ˆ Authoren - Gisela Piltz, Sibylle Laurischk, Sabine Leutheusser-Schnarrenberger, Jens
Ackermann, Karl Addicks, . . . , Hartfrid Wolff, Martin Zeil, Wolfgang Gerhardt, FDP
Desweiteren wird zu jedem Author, sofern dieser eine Person ist und nicht z.B. eine Partei, die
jeweilige eindeutige Mops-Id (siehe Kapitel 4.1.4) beno¨tigt. Außerdem wird eine eindeutige
Drucksachen-Id angelegt.
Erstellung einer Drucksachen-Xml
Das Programm btd index builder, welches die Drucksachenattribute automatisch extra-
hiert, beno¨tigt als Eingabe einen Pfad zu den Plain-Ascii-Dokumenten (siehe Kapitel 3.1.1).
Von diesem Pfad aus crawlt sich das Programm durch alle Unterverzeichnisse und arbeitet
alle Dokumente in diesen ab. Dokumente die nicht sauber genug umgewandelt wurden, wer-
den nicht mit in den Index aufgenommen.
Es werden nun u¨ber regula¨re Ausdru¨cke und Reihenfolgeberu¨cksichtigung die in Kapitel 4.4.7
aufgelisteten Attribute extrahiert. U¨ber einen kleinen selbst angelegten Thesaurus, werden
die Parteinamen normalisiert. Fu¨r die Authoren Ausschuss und Partei wird die eindeutige
Personen-Id auf
”
-1“ gesetzt. Fu¨r alle anderen Authoren wird eine Anfrage an eine einmalig
erzeugte Name-zu-Id-Hashmap gestellt. Wird ein Author nicht in dieser gefunden, so erha¨lt
auch er die Id -1. Jede Drucksache wird mit seinen Attributen in einer Xml-Datei abgelegt.
258
〈 bundestag〉
〈 wahlperiode nummer =
”
“ anfangsdatum =
”
“ enddatum =
”
“ 〉
〈 fraktion 〉
〈 partei name =
”
“ regiert =
”
“ size =
”
“ 〉
〈 person name =
”
“ von =
”
“ bis =
”
“ 〉
〈 amt von =
”
“ bis =
”
“ 〉 Name des Amtes〈/amt〉
〈/ person〉
〈/ partei〉
〈/ fraktion〉
〈/ wahlperiode〉
〈/ bundestag〉
Abbildung 4.30: Die XML fu¨r den BundestagLookUp
Unsere Beispieldrucksache aus Abbildung 4.4.7 hat in der Xml-Datei nun die Form, welche
in Abbildung 4.4.7 zu sehen ist.
Anfragen an den Drucksachen-Index
Es ist ein leichtes Anfragen an den Drucksachen-Index zu stellen. Beispielsweise kann u¨ber eine
Drucksachennummer ein Objekt vom Typ Dokument mit allen Attributen erhalten werden.
Da dies allerdings nur fu¨r die Erstellung des Lucene-Index (siehe Kapitel 5.2) beno¨tigt wird
und von da an alle Informationen im Lucene-Index enthalten sind und auch von dort abgefragt
werden ko¨nnen, werde ich hier nicht weiter auf die Anfragen eingehen.
4.4.8 BundestagLookUp
Die XML des Bundestags (Parteien, Minister, Regierung) ist per Hand erstellt worden. Dies
ist nicht automatisiert worden, weil die Informationen zu Beginn schnell verfu¨gbar sein sollten.
BundestagsLookUp liefert Information u¨ber die Abgeordneten, die innerhalb der jeweiligen
Wahlperioden ein Ministerposten besitzen oder besaßen.
Aufbau des Strukturbaumes:
Die Baumstruktur zeigt auf wie die XML aufgebaut ist.
1) gibt an in welcher WP wir uns befinden und wie lange diese dauerte 2) gibt die Fraktionen
an, dieser folgt 3)Partei, welche an Fraktion gebunden ist. Hier erfahren wir um welche Partei
es sich handelt und ob diese die Regierung bilden. Mit Hilfe von 4) und 5)bekommen wir
die Namen der Abgeordneten heraus, die A¨mter besitzen oder im Falle der nicht regierenden
Parteien nur die Parteivorsitzenden. Zu diesen Informationen kommt immer die Dauer von
wann bis wann die A¨mter/Parteivorsitz von den Abgeordneten bezogen worden sind und ein
Vermerk fu¨r den Eintritt in die Partei. Partei, Person und Amt sind unter Fraktion verschach-
telt.
Falls die Partei nicht regiert, wurde nur der Parteivorsitzender eingetragen.
Um die ganzen Minister der Legislaturperioden (14-16) und die Dauer dieser A¨mter zu finden
wurden folgende Seiten verwendet.
259
1) fu¨r die Minister der Regierung Schro¨der:
http://www.muenster.de/ urcom/Bundestagswahl/Minister Schroeder.htm
2) fu¨r die Minister der Regierung Merkel:
http://www.muenster.de/ urcom/Bundestagswahl/Minister Merkel.htm
Um die Daten, fu¨r die Parteizugeho¨rigkeit zu finden, wurde dafu¨r zum einen Wikipedia und
zum anderen die Bundestagsseite genutzt. Die Anzahl der Sitze im Bundestag, erha¨lt man
mit der Hilfe der Seiten:
http://www.bundeswahlleiter.de/wahlen/btw98/btwahl btw98.htm (Fu¨r WP 14,15) und
http://www.bundeswahlleiter.de/bundestagswahl2005/ergebnisse (Fu¨r WP 16).
BTLQueryAnfragen:
Mit der Hilfe dieser Query, welche auf BTL zugreift, ko¨nnen nun einfache Fragen u¨ber die
Minister und Parteien im Bundestag beantwortet werden. Diese wird innerhalb der Query
Facade verwendet.
Automatisierter BundestagLookUp:
Dieses automatisierte Verfahren wurde erstellt, um aufwa¨ndiges und erneutes per Hand su-
chen von Informationen u¨ber die Abgeordneten, die ein Amt in der jeweiligen Wahlperiode
besaßen oder besitzen zu vermeiden. Die fehlende Update-Funktion u¨ber A¨nderungen inner-
halb der Informationsquelle, wie z.B. Minister von einem Amt a¨ndert sich usw., wurde nun
auch erga¨nzt. In dem Fileworker startet die Updatefunktion und zwar wird einfach auf das
Programm zugegriffen und die automatisch erstellte XML durch eine neue XML ersetzt.
Dies ist ohne weiteres mo¨glich, denn die Menge der vorhandenen Eintra¨ge ist ziemlich gering.
Ein anderer Ansatz wa¨re gewesen die vorhandene XML und die Eintra¨ge auf der Seite zu
Vergleichen. Da dies im Endeffekt die gleiche Zeit braucht, lassen wir einfach die vorhandene
XML ersetzen. Die Query-Anfragen laufen wie schon beim normalen BTL u¨ber die Query
Facade. Die ganzen Informationen sollen von der Wikipedia-Seite extrahiert werden.
Mit Hilfe dieses Programms kann man nun automatisch Informationen u¨ber die Minister und
Kanzler der jeweiligen Legislaturperioden bekommen.
Es wird zwischen den Wahlperioden (auf der
”
Wikipedia“ Seite Kabinett genannt) unterschie-
den und angegeben welche Partei welche Minister stellt/e. A¨nderungen innerhalb der Seite
wie z.B. Amtsinhabers a¨ndert sich oder neue Wahlperiode, werden mit Hilfe der Updatefunk-
tion angezeigt.
Aufbau des Strukturbaumes:
Die Struktur hat sich ein wenig gea¨ndert und manche Attribute und Werte sind auch nicht
mehr vorhanden(siehe vorherige XML).
260
〈 bundestag〉
〈 wahlperiode nummer =
”
“ anfangsdatum =
”
“ enddatum =
”
“ 〉
〈 amt 〉 Name des Amtes
〈 partei 〉 Name der Partei
〈 person name =
”
“/〉
〈/ partei〉
〈/ amt〉
〈/ wahlperiode〉
〈/ bundestag〉
Abbildung 4.31: Die XML fu¨r den Auto-BundestagLookUp
261
5 Systemkomponenten
5.1 Lexical Tree (L-Tree)
Im Rahmen der Aufgaben der PG ist an vielen Stellen eine wortbasierte Suche nach Doku-
menten erforderlich. Aufgrund der Gro¨ße des Dokumentenarchivs (ca. 40.000) ist dazu ein
besonders effizienter Wort-Index no¨tig.
Die Datenstruktur Der L-Tree ist eine Datenstruktur, die diesen Anforderungen gerecht
wird. Im Kern ist sie ein B-Baum, wobei jeder Knoten einen Buchstaben repra¨sentiert. Ein
Wort w = (b1, ..., bn), bestehend aus n Buchstaben, entsteht dann durch einen von der Wurzel
ausgehenden Pfad. Der Knoten des letzten Buchstaben speichert eine Liste mit Verweisen auf
die Dokumente, in denen das Wort vorkommt. Das Vorhandensein der Dokumentenliste in
einem Knoten kennzeichnet damit ein gu¨ltiges Wort(-ende). Abbildung 5.1 verdeutlicht die
Datenstruktur. D stellt dabei die Menge aller Dokumente dar. Die Dokumentenliste entha¨lt
aber nicht nur einen Verweis auf die entsprechenden Dokumente, sondern speichert auch
die Anzahl der Vorkommen des Wortes im jeweiligen Dokument selbst. Dadurch ist es ein
Leichtes, ein Ranking der Dokumente zu einem Wort vorzunehmen. Hierzu wurde die TF-IDF
Gewichtung anhand der nachfolgenden Formel verwendet. Sei dafu¨r L(w) = {d ∈ D|w ∈ d} ⊆
D die Dokumentenliste fu¨r ein Wort w und freq(w, dj) die Ha¨ufigkeit, mit der w in dj
vorkommt.
tfidf(w, dj) =
freq(w, dj)
max
j
freq(w, dj)
∗ log
(
‖D‖
‖L(w)‖
)
(5.1)
Wie man sich leicht klarmacht, sind alle zur Berechnung erforderlichen Angaben in der
beschriebenen L-Tree Datenstruktur verfu¨gbar. Die Dokumentenliste wurde mit dem Java-
Datentyp Hashmap implementiert. Die Schlu¨ssel der Hashmap bilden die Dateinamen, denen
Abbildung 5.1: L-Tree Datenstruktur
262
dann die Ha¨ufigkeiten der Wo¨rter im jeweiligen Dokument zugeordnet werden. Dies bildet die
Funktion freq(w, dj) ab. Die Anzahl der verschiedenen Dokumente ‖L(w)‖, in denen das be-
trachtete Wort vorkommt, kann durch die Eigenschaft size() abgerufen werden. Die maximale
Ha¨ufigkeit max
j
freq(w, dj) la¨sst sich leicht in der Liste finden, die Anzahl aller Dokument
|D| wird beim Erstellen des Index mitgeza¨hlt und dann gespeichert.
Effizienz Was diese Datenstruktur als Index so effizient macht ist die Tatsache, dass die
Wo¨rter in sich erga¨nzender Weise gespeichert werden. Teilt sich ein Wort mit einem anderen
die ersten k Buchstaben, so werden fu¨r beide Worte die selben k Anfangsknoten benutzt. Erst
wenn sich die Buchstaben unterscheiden, also fu¨r den jeweils (k+1)-ten Buchstaben, teilt sich
der Pfad. Im besten Fall ist das ku¨rzere Wort vollsta¨ndig in dem la¨ngeren enthalten, so dass
fu¨r das ku¨rzere Wort keinerlei eigene Knoten angelegt werden mu¨ssen. Lediglich der letzte
Knoten beider Worte entha¨lt dann die Liste mit den Dokumentenverweisen. Dieser Aspekt
sorgt fu¨r eine sehr gute Kompaktierung und spart viel Speicherplatz.
Ein weitere wichtige Anforderung ist das effiziente Auffinden der Dokumentenliste zu einem
gegebenen Wort. Durch die Baumstruktur kann die Dokumentenliste zu einem Wort mit n
Buchstaben auch in O(n) gefunden werden, da nur der Pfad, der das gegebene Wort bildet,
verfolgt werden muss.
Gro¨ßenabscha¨tzung Der Index bildet eine zentrale Komponente des Systems und muss da-
her an vielen Stellen schnell verfu¨gbar sein. Am Besten ist dies durch eine vollsta¨ndige und
dauerhafte Residenz im Hauptspeicher zu erreichen. Eine grobe Abscha¨tzung soll zeigen, ob
so der Index bei der vorliegenden Datenmenge in einen handelsu¨blichen Hauptspeicher passt.
Dabei darf der L-Tree natu¨rlich auch den Speicher nicht zu großen Teilen fu¨r sich beanspru-
chen, da das System noch viele weitere Komponenten hat. Die grobe Abscha¨tzung soll dann
empirisch belegt werden.
Sei lmax die La¨nge des la¨ngsten Worts, lavg der La¨ngendurchschnitt. lmax ist auch die La¨nge
des la¨ngsten Pfades und kennzeichnet die Tiefe des L-Trees. Da die Knoten Buchstaben re-
pra¨sentieren ist auch die Menge der mo¨glichen Knotentypen auf die zugelassenen Buchstaben
begrenzt. Dies sei bmax. Ein Knoten kann also maximal bmax Kinder haben. Sei bavg die
durchschnittliche Anzahl der Kinder. Jedes Kind wird am Elter als 32-Bit-Adresse referen-
ziert. Die Speicherung des Buchstaben als Java Datentyp char beno¨tigt 16 Bit. Ein L-Tree
mit k Wo¨rtern hat maximal k ∗ lmax Knoten mit je (bmax ∗ 4 + 2) Byte. Die Gro¨ße der
Dokumentenliste wird zuna¨chst nicht betrachtet. Aus den vorhandenen Dokumenten lassen
sich fu¨r die Doma¨ne Politik lmax = 67 und k = 470.000 ermitteln. Als Buchstaben werden
a-z, A-Z, A¨, O¨, U¨ , a¨, o¨, u¨ und ß zugelassen, was bmax = 59 festlegt. Demnach wa¨re die
Gro¨ße des L-Tree auf ca. 6,8 GB begrenzt. Offensichtlich eine zu grobe Abscha¨tzung, da die
reine Speicherung aller 470.000 Wo¨rter als Textdatei nur 10 MB beno¨tigt und unsere Daten-
struktur keinen derart großen Overhead produziert. Um die Gro¨ßenabscha¨tzung realistischer
zu gestalten werden nachfolgend Durchschnittswerte fu¨r die Parameter verwendet. Aus der
Verteilung der Wortla¨ngen, die in Abbildung 5.2 dargestellt ist, la¨sst sich lavg = 15 bestim-
men. Da fast nie ein Großbuchstabe auf einen Kleinbuchstaben folgt, fallen 30 Buchstaben
als Kinder heraus. Zudem wird der Baum mit jeder Ebene immer spa¨rlicher besetzt, so dass
fu¨r bavg = 15 angenommen wird. Als durchschnittliche Gro¨ße ergibt sich so ca. 450 MB. Ein
Testlauf (ohne Dokumentenlisten) ließ den L-Tree 150 MB groß werden.
Mit Hinzunahme der Dokumentenlisten wurde die Indexierung problematisch. Nach gut ei-
263
Abbildung 5.2: Ha¨ufigkeiten (y-Achse) der Wortla¨ngen (x-Achse) in den Dokumenten des
Systems
nem Drittel der Dokumente brach das Programm, ausgefu¨hrt auf einem Windows-Computer
mit 2 GB Arbeitsspeicher, aus Mangel an Hauptspeicher ab. Die Heap-Gro¨ße der JVM wurde
zuvor auf den maximal mo¨glichen Wert von ca. 1,6 GB vergro¨ßert. Das Problem konnte auch
nach optimierender Umprogrammierung nicht behoben werden. Erst durch die Einfu¨hrung
von 250 Stopwo¨rtern, die bei der Indexierung ignoriert werden, ließ sich der Index erstellen.
Die Stopwo¨rter wurden hautsa¨chlich durch eine Ha¨ufigkeitsanalyse ermittelt. Paradoxerweise
ist der L-Tree mit Verwendung der Stopwort-Liste nur ca. 400 MB groß. Die Gru¨nde dafu¨r
sehen wir einerseits in eventuellen Unzula¨nglichkeiten in der Programmierung, andererseits
aber auch in der Speicherverwaltung der JVM, vor allem in Bezug auf die Verwendung des
Datentyps Hashmap mit sehr vielen Eintra¨gen. Unsere Recherchen haben allerdings ergeben,
dass dieser Datentyp der effizienteste Standard-Datentyp in Java ist. Diese Umsta¨nde sorgen
bei der Verwendung des L-Trees im System fu¨r Probleme.
Anwendungsprobleme Wie bereits erwa¨hnt soll der L-Tree vollsta¨ndig im Hauptspeicher re-
sidieren. Einmal geladen zeigt der L-Tree die erwartete Schnelligkeit im Abruf der Dokumen-
tenlisten zu einem Suchwort. Das Laden des 400 MB Indexes dauert allerdings 10 Minuten -
eine Zeitspanne, die einen zu großen Mangel des fertigen Systems darstellen wu¨rde. Daher wur-
de, parallel zu den Verbesserungsversuchen am L-Tree, nach fertigen Open-Source Lo¨sungen
gesucht, die a¨hnliches leisten ko¨nnen. Das Lucene-Projekt (http://lucene.apache.org/) stellte
sich dabei als Alternative heraus. Die Architektur unterscheidet sich dahingehend, dass Lu-
cene einen dokumentbasierten Index anlegt, nicht einen wortbasierten, wie der L-Tree. Nach
Testla¨ufen sprachen aber folgende Aspekte fu¨r die Verwendung von Lucene an Stelle unserer
264
L-Tree Implementierung:
ˆ Problemlose Indexerstellung mit allen Dokumenten (auch ohne Stopwo¨rter)
ˆ Sehr geringe Ladezeit im Bereich von Sekunden
ˆ Gute Kontrolle u¨ber die indexierten Daten, mit der Mo¨glichkeit beliebige Zusatzdaten
zu einem indexierten Dokument zu speichern
ˆ Parser fu¨r Suchanfragen, der Abfragen nach dem Prinzip ga¨ngiger Suchmaschinen er-
laubt
ˆ Gesucht wird optional auch unter Einbeziehung der Zusatzdaten
ˆ Integriertes Ranking
ˆ Gro¨ße der Indexdatei betra¨gt insgesamt nur ca. 150 MB. Das ist die Gro¨ße, die der
L-Tree Index ohne Dokumentenlisten hat.
Aufgrund der genannten Vorteile haben wir uns zur Benutzung von Lucene entschlossen und
die Arbeiten am L-Tree eingestellt. Die Implementierung von Lucene wird im Folgenden noch
genauer beschrieben.
5.2 Lucene
Lucene (http://lucene.apache.org/) ist eine in Java realisierte Open-Source Suchmaschine.
Da sie schon seit vielen Jahren besteht, gilt sie als sehr ausgereift und effizient. Im vorheri-
gen Kapitel wurde bereits erla¨utert, in wie weit Lucene unserem L-Tree u¨berlegen ist. Ein
weiteres westenliches Feature ist die nahezu unbegrenzte Anpassbarkeit des Systems. Die
zentrale Komponente ist der dokumentenbasierte Index. Ein Dokument (Lucene-Dokument)
besteht dabei aus Name-Value-Paaren, die wahlweise indexiert werden ko¨nnen. Abbildung 5.3
verdeutlicht dies. Wir pflegen mit Lucene zwei Indizes. Der erste Index ist der Dokumenten-
Index, der alle BTD und BTP entha¨lt. Dieser wird mitunter auch als der
”
Lucene-Index“
bezeichnet, da er lange Zeit der einzige Lucene-Index war. Ein Lucene-Dokument entspricht
in disem Fall den einzelnen BTP-/BTD-Dokumenten in Form der ASCII-Dateien und hat die
folgenden Felder:
ˆ Dokumenttext
Der Dokumenttext wird indexiert. Dadurch ist das Dokument komplett durchsuchbar.
ˆ Autorenliste
Diese Liste wird einmal als Liste mit den Namen der Autoren im Klartext und ein-
mal als Liste mit den Identifikationsnummern der MOPS-Datenbank (eine Personen-
Datenbank) gefu¨hrt. Die erste Liste vereinfacht die Suche nach Teilen des Namenes. So
lassen sich schnell alle Dokumente finden, die z.B. von einem
”
Helmut“ verfasst wur-
den. Wu¨rden die Namen nicht im Klartext indexiert, so mu¨sste fu¨r das Beispiel erst
eine Anfrage an die MOPS-Datenbank ausgefu¨hrt werden, um die Identifikationsnum-
mern aller
”
Helmuts“ zu erhalten. Die zweite Liste schafft die direkte Verbindung zur
MOPS-Datenbank.
265
Abbildung 5.3: Aufbau des Lucene Index
ˆ Dokumenttyp
Der Typ des Dokument nach den Kategorien des Bundestages (Kleine Anfrage, große
Anfrage, Beschlussempfehlung, ...)
ˆ Titel
Der Titel des Dokuments soll den Inhalt zusammenfassen und wird ebenfalls indexiert.
ˆ Pfad
Der Pfad des ASCII-Dokuments im Dateisystem.
ˆ URL
Der Pfad des PDF-Dokuments auf der Bundestags-Webseite. Dieses Feld wird genutzt,
damit die GUI bei Bedarf eine aktuelle Version des Dokuments fu¨r den Benutzer aus
dem Internet laden kann. So ist es nicht no¨tig, alle PDFs lokal vorzuhalten.
ˆ Datum
Datum der Vero¨ffentlichung (BTD) bzw. der Plenarsitzung (BTP).
ˆ Nummer
Drucksachen- oder Plenarprotokollnummer.
ˆ Drucksache oder Protokoll
Dieses Feld gibt an, um welchen der beiden Typen es sich handelt.
ˆ Wahlperiode
Die Informationen in den Feldern werden bei der Erstellung des Dokumenten-Index aus drei
Quellen bezogen:
1. aus den ASCII-Dokuemten selbst (Inhalt, Pfad).
266
2. aus dem BTD-Index
Dieser Index extrahiert zuvor mittels regula¨rer Ausdru¨cke alle relevanten Informatio-
nen zu den BTD in ein XML. Bei der Erstellung des Lucene-Index wird anhand der
Drucksachennummer der entsprechende XML-Knoten gefunden.
3. BTP-Index
Dieser Index funktioniert analog zum BTD-Index.
Der zweite Index, der neben dem Dokumenten-Index mit Lucene gepflegt wird, ist der Reden-
Index. In Kapitel 4.4.4 wird die Extraktion der Reden in das XML-Format beschrieben. Der
Lucene-Reden-Index setzt auf die XML-Daten auf. Ein Lucene-Dokument entspricht hier einer
Rede, die folgende Felder entha¨lt:
ˆ Inhalt
Der reine Redetext wird hier indexiert.
ˆ Redner
Der Redner wird im Klartext und als ID aus der MOPS-Datenbank gespeichert.
ˆ Datum
Das Datum der Rede.
ˆ Wahlperiode
ˆ Anzahl der Zwischenrufe
ˆ Zwischenrufer
Auch diese Personen werden auf die bekannte, duale Weise in den Index aufgenommen.
ˆ Protokollnummer Nummer des Plenarprotokolls, in dem die Rede festgehalten ist. Damit
ist auch die Plenarsitzung bestimmt, in der diese Rede gehalten wurde.
Lucene unterstu¨tzt auch Funktionen wie Stemming und Stopworte. Dazu wird eine sogen-
nannte Analyser-Klasse verwendet, von der jeder Text, der indiziert werden soll, vorverarbei-
tet wird. Lucene hat bereits solcherlei Klassen fu¨r die deutsche Sprache integriert, so dass wir
in einfacher Weise auf diese Funktionalia¨ten zuru¨ckgreifen ko¨nnen.
Die Suchfunktion von Lucene ermo¨glicht die Suche in einem oder allen Feldern. Sie ist in einer
einfachen Abfragesprache realisiert [Luc]. Damit ko¨nnen ganz gezielt Informationen abgefragt
werden. Ebenfalls mo¨glich ist die Pharsen- und Platzhaltersuche, wie z.B. nach
”
Helmut Kohl“
oder
”
Abgeordnete?“. Die Suchergebnisse werden von Lucence nach einem TF/IDF basierten
Score geordnet.
5.3 WT2XML
Nach dem die Dateien den RapidMiner passieren haben, mu¨ssen die als XML-Dokumente
gespeichert werden. Eine Funktion, die eine Menge von WT-Dokumenten in die Menge von
XML-Dokumente abbildet, ist eine Grundlage fu¨r das RapidMiner-Plugin. Die Implementie-
rung in Java und dazugeho¨rige Erla¨uterungen sind im Folgenden dargestellt:
267
1 import java.io.File;
2 import java.io.FileReader;
3 import java.io.BufferedReader;
4 import java.io.BufferedWriter;
5 import java.io.FileOutputStream;
6 import java.io.OutputStreamWriter;
7 import java.nio.charset.Charset;
8 import java.nio.charset.CharsetEncoder;
9 import java.util.LinkedList;
10 import java.util.List;
Listing 5.1: WT2XML Klassen 1
1 import de.unidortmund.pg520.annotation.module.document.
SimpleAnnotationDocument;
2 import de.unidortmund.pg520.annotation.module.document.tag.
SimpleEntityTag;
3 import de.unidortmund.pg520.annotation.module.document.
SimpleEntity;
4 import de.unidortmund.pg520.annotation.module.util.XmlUtil;
Listing 5.2: WT2XML Klassen 2
Die Klassen in Listing 5.1 sind notwendig um alle Funktion zu realisieren. Ersten drei Zeilen
sorgen dafu¨r, dass die Datei richtig ausgelesen wird. Die na¨chsten drei Zeilen sind notwendig
um eine Datei zu speichern. Die siebte und achte Zeile sorgen, dass auch die Umlauten richtig
gespeichert werden. Und endlich die letzten beiden Zielen laden die genannten Datenstruktu-
ren runter.
Die Kassen in Listing ?? sind dafu¨r da, dass die erzeugten XML-Dokumenten mit dem selben
Schema erzeugt werden, das auch bei der Erzeugung der Annotations-Dokumente genutzt
wird.
Die Methode in Listing 5.3 gibt die NE, die in der Zeile eines WT-Dokumenets ausgelesen
wird, zuru¨ck. Falls die Zeile nicht markiert ist, das heißt mit einem
”
O“ versehen ist, dann
wird
”
null“ zuru¨ckgegeben.
Die Methode in Listing 5.4 sagt uns, ob die jeweilige Zeile ein neuer oder fortgesetzter Tag
ist.
Im Codeteil in Listing 5.5 wird das Verzeichnis und alle dort befindende WT-Dokumente
ausgelesene und ein nach dem anderen bearbeitet. Nach der Entfernung aus der Datei und
separaten Speicherung von Tags, wird die Datei zwischengespeichert.
In dem Codabschnitt in Listing ?? wird eine Zeile nach der anderen gescannt. Wenn die
268
1 public class WT2XML {
2 private static String getEntityName(String w2){
3 if(w2.length () <2)
4 return null;
5 else{
6 return w2.substring(2, w2.length ());
7 }
8 }
Listing 5.3: WT2XML 3
1 private static boolean isStartEntity(String w2){
2 return(w2.length () <2) || w2.charAt (0) == ’B’;}
Listing 5.4: WT2XML 4
1 public static void main(String [] args) throws Exception{
2 File file = new File (args [0]);
3 File[] fileArray = file.listFiles ();
4 for (int k=0;k<fileArray.length;k++){
5 file = fileArray[k];
6 String fileName = file.getName ().substring(0, file.getName ().
length () -4);
7 BufferedReader in = new BufferedReader(new FileReader(file));
8 FileOutputStream fos = new FileOutputStream(new File ("C:/temp.
wtf"));
9 CharsetEncoder encoder = Charset.forName("UTF -8").newEncoder ();
10 OutputStreamWriter osw = new OutputStreamWriter(fos , encoder);
11 BufferedWriter bw = new BufferedWriter(osw);
Listing 5.5: WT2XML 5
269
1 String zeile;
2 StringBuffer buf = new StringBuffer ();
3 List <SimpleEntityTag <SimpleEntity >> list = new LinkedList <
SimpleEntityTag <SimpleEntity >>();
4 int i = 0;
5 int begin = 0;
6 String prevEntity = null;
7 while(( zeile = in.readLine ()) != null ){
8 String [] s = zeile.split(" ");
9 if(s.length <2)
10 continue;
11 String entity = getEntityName(s[1]);
12 if(( entity == null || isStartEntity(s[1])) && prevEntity !=null)
13 list.add(new SimpleEntityTag <SimpleEntity >(begin , i-1, new
SimpleEntity(prevEntity)));
14 buf.append(s[0]+" ");
15 if(isStartEntity(s[1]))
16 begin = i;
17 prevEntity = entity;
18 i =i + s[0]. length ()+1;
19 }
Listing 5.6: WT2XML 6
Zeile mit einem Tag markiert ist, wir der entsprechender SimpleEntity-Objekt erzeugt. Aus
dem WT-Dokument werden nun alle Tags entfernt, so dass weiter das Dokument ohne Tags
zwischengespeichert wird.
Im Codesegment in Listing 5.7 wird die Datei zwischengespeichert und dann in das SimpleAn-
notationDocument eingelesen. Auf den Objekten der SimpleAnnotationDocument-Klasse wird
ein XML-Schema definiert, womit dann die XML-Dateien aus WT - Dokumenten erzeugt wer-
den.
5.4 Graphical User Interface
Einleitung
Die Grafische Benutzer-Schnittstelle (kurz: GUI) des Intelligence Service (kurz: IS) orientiert
sich stark an den Eigenschaften der benutzten Doma¨ne. Bei der Doma¨ne handelt es sich um
den Deutschen Bundestag bzw. die Bundestags-Seite. Also erwartet der IS erfahrungsgema¨ß
einen relativ hohen Altersdurchschnitt. Infolgedessen war von vorneherein klar, dass das GUI
leicht zu bedienen sein sollte. Obwohl die GBS grafisch nicht u¨berladen wirkt, navigiert sich
270
1 bw.write(buf.toString () ,0,buf.toString ().length ());
2 bw.close ();
3 file = new File ("C:/temp.wtf");
4 SimpleAnnotationDocument annotationDocument = new
SimpleAnnotationDocument(file ,Charset.forName("UTF -8").
newDecoder ());
5 for (int j=0; j<list.size();j++)
6 annotationDocument.insertTag(list.get(j));
7 XmlUtil.initXmlParser ();
8 annotationDocument.saveXmlFile(new File(args[1], fileName+".xml")
);
9 }
10 }
11 }
Listing 5.7: WT2XML 7
der Benutzer durch grafische Schaltfla¨chen bis er zum gewu¨nschten Service gelangt. Sofort
am Anfang hat der Benutzer die Mo¨glichkeit, den gewu¨nschten Service, in Form von relativ
großen Schaltfla¨chen, zu wa¨hlen oder genauer zu spezifizieren. Dies sind folgende:
ˆ Volltextsuche und andere Services
ˆ PartyNator
ˆ Fragebeantwortungssystem
Je nachdem welche Schaltfla¨che der Benutzer dru¨ckt, gelangt er direkt zum Service und kann
Ihn benutzen oder bekommt weitere, kleinere Schaltfla¨chen womit er zu den Services gelangt.
Durch Klick auf “PartyNator” oder “Fragebeantwortungssystem” wird der Service direkt
geo¨ffnet. Der Service “Volltextsuche und andere Services” beinhaltet folgende Services:
ˆ Abgeordneten Informationen
ˆ Dokumentensuche
ˆ Stichwortsuche
ˆ Dossier
Zu jedem Service, ob nun direkt aufgerufen oder durch eine zweite Schaltfla¨che, gibt es eine Be-
schreibung. Die Beschreibung ist entweder in unmittelbarer Na¨he der Schaltfla¨che angebracht
oder erscheint, wenn man mit dem Mauszeiger dru¨berfa¨hrt. Sollte der Benutzer trotzdem
mal nicht wissen wo er sich gerade befindet, oder z.B. seine Sitzung unterbrochen hat und
sie spa¨ter wieder fortsetzt, steht das sogenannte “InfoPanel” zur Verfu¨gung. Das “InfoPanel”
271
Abbildung 5.4: Startseite der Grafischen Benutzer-Schnittstelle
Abbildung 5.5: Serviceseite
272
Abbildung 5.6: Abgeordneten Information
zeigt zu jedem Zeitpunkt an, was der Benutzer tun kann oder muss, um sein Ziel zu erreichen.
Zusa¨tzlich fa¨ngt das “InfoPanel” unvermeidbare Benutzerfehler ab, und gibt Anweisungen
wie weiter fortgefahren werden kann. Der Benutzer hat zu jedem Zeitpunkt die Mo¨glichkeit
wieder zum Startbildschirm zu gelangen. Die Anfragen und Ergebnisse bleiben dennoch er-
halten wenn er zum Service spa¨ter zuru¨ckkehrt. Auch ein Wechsel zwischen den Services vor
dem Ausfu¨hren der Anfrage fu¨hrt nicht zum Ergebnisverlust.
Services im GUI
Abgeordneten Informationen Das Anfrage-Schema bei den Abgeordneten Informationen
basiert auf einzelnen Elementen. Durch “Element Hinzufu¨gen” kann der Nutzer Anfrage-
Elemente beifu¨gen. Die einzelnen Anfragen-Elemente ko¨nnen dann disjunkt oder konjugiert
abgeschickt werden. Falls Abgeordnete existieren, die der Anfrage entsprechen, werden Sie
unter “Liste der Namen” angezeigt. Der Nutzer hat nun die Mo¨glichkeit eine Person an-
zuwa¨hlen und sich alle vorhandenen Informationen u¨ber die Person anzeigen zu lassen. Die
letzte Information zeigt immer die Webadresse der Person und ist durch einen Klick abrufbar.
Dokumentensuche Die Anfrage-Maske der Dokumentensuche ist relativ einfach aufgebaut.
Der Nutzer hat die Mo¨glichkeit ein oder mehrere Stichworte anzugeben, und somit die Do-
kumente der Bundestagsseite nach Schlagwo¨rtern zu durchsuchen. Weiterhin besteht die
Mo¨glichkeit nicht nur alle Wahlperioden zu durchsuchen sondern eine bestimmte Wahlpe-
riode zu spezifizieren. Die Reihenfolge der gefundenen Dokumente ist durch den Lucene-Wert
(Score) festgelegt und wird unter der Liste fu¨r das aktuelle Dokument angezeigt. Dementspre-
chend erscheinen Dokumente, die relevanter sind, auch weiter oben in der Liste. Wenn ein
Dokument angewa¨hlt ist, werden zudem weitere Informationen angezeigt wie z.B. Titel, Typ,
273
Abbildung 5.7: Serviceseite
Autor oder die Webadresse des Dokuments womit das Quelldokument auch geo¨ffnet werden
kann.
Stichwortsuche Die Anfrage-Maske der Stichwortsuche ist identisch mit der Anfrage-Maske
der Dokumentensuche. Allerdings ist die Ausgabe sehr unterschiedlich. Man erha¨lt hier nach
einer Anfrage nicht nur die Namen der relevanten Dokumente, sondern Events in Form von
kleinen Textschnipseln. Um ein Stichwort herum ist immer ein gewisser Kontext vorhan-
den, der hier dem Benutzer pra¨sentiert wird. Obwohl die Textschnipsel auch hier bzgl. der
Lucene-Werte sortiert sind, ist durch den gegebenen Kontext um ein Stichwort herum eine
gezieltere Suche mo¨glich. Wenn dem Nutzer ein Textschnipsel wichtig erscheint, kann er sich
das Original-Dokument durch einen Klick anzeigen lassen.
Dossier im GUI Beim Dossier handelt es sich um eine Sammlung von Abgeordneten u¨ber
Wahlperioden hinweg. Zu einer bestimmten Person kann auf schnellste Weise angezeigt wer-
den, in welchen Dokumenten die Person vorkommt und in welchen Plenarprotokollen die
Person eine Rede ha¨lt. Na¨heres dazu in Abschnitt 3.7.
PartyNator im GUI Der PartyNator in der Grafischen Benutzer-Schnittstelle stellt Text-
felder zur Verfu¨gung, die der Benutzer aktivieren und ausfu¨llen kann. Den verschiedenen
Attributen ko¨nnen Attribute zugewiesen werden. Nachdem die Anfrage abgeschickt wurde
und ein Ergebnis berechnet worden ist, wird dieses u¨bersichtlich in einem animierten Tor-
tendiagramm angezeigt. Die Ho¨he der Parteiaffinita¨t ha¨ngt nicht nur von der Anzahl der
Personen ab, die auch den Werten der angegebenen Attributen entsprechen. Na¨heres dazu in
Abschnitt 3.8.
274
Abbildung 5.8: Dokumentensuche
Abbildung 5.9: Stichwortsuche
275
Abbildung 5.10: Dossier
Abbildung 5.11: PartyNator
276
GUI-Vergleich mit der EN ISO 9241 - 110
Das GUI der IS ist natu¨rlich sehr an die benutzte Doma¨ne angelehnt. Um dennoch die Vor-
und Nachteile zu untersuchen, eignet sich ein Vergleich mit einigen Grundsa¨tzen der Dialog-
gestaltung, welches im Teil 110 der EN ISO 9241 - 110 normiert ist. Teil 110 ersetzt dabei
den schon veralteten 10. Teil der Norm. Auch wenn die Norm eigentlich fu¨r Webanwendungen
zugeschnitten ist, sind die Grundsa¨tze teilweise auf die IS als Offline-Anwendung u¨bertragbar.
Aufgabenangemessenheit Unter dem Aspekt der Aufgabenangemessenheit ist die Einfach-
heit und Zielorientierung des Interfaces gemeint. Wie in der Einfu¨hrung schon erla¨utert, ist
die Navigation bis zu einem bestimmten Service Schaltfla¨chenorientiert. Die Schaltfla¨chen im
Startbildschirm sind relativ groß bemessen und helfen dem Nutzer zu verstehen, was sich
hinter der Schaltfla¨che verbirgt. Die Schaltfla¨chen haben zwar einen großen Farbraum, sind
aber im Durschnitt nicht gro¨ßer als 30 KB. Da IS in Java geschrieben, und es sich um ei-
ne Offline-Anwendung handelt, ist die Gro¨ße der Grafiken im Allgemeinen eher unkritisch.
Die Anfragen, die die Benutzer stellen ko¨nnen sind so individuell, dass auf Speicherung von
Zwischenergebnissen u¨ber Programmaufrufe hinweg, verzichtet wurde.
Selbstbeschreibungsfa¨higkeit Die Selbstbeschreibungsfa¨higkeit deutet auf gelungene Ru¨ck-
meldungen und die allgemeine Versta¨ndlichkeit des Programms. Wenn im GUI eine Liste oder
der gleichen zu sehen ist, wird am Kopf immer der Umfang angezeigt, was der Versta¨ndlichkeit
enorm entgegen kommt.
Steuerbarkeit Die Steuerbarkeit hebt die A¨nderbarkeit der Parameter hervor, die bei einer
Anfrage an das System wichtig sind. Beim IS sind die Parameter sehr spezifisch bzgl. der
Doma¨ne. U¨berall dort wo es Sinn macht, kann z.B. die Wahlperiode spezifiziert oder die
Anzahl der Ergebnisse angegeben werden.
Erwartungskonformita¨t Unter der Erwartungskonformita¨t versteht sich die intuitive Bedie-
nung des Programms. Wird z.B. der (gro¨ßte Teil) der Nutzer bei der Nutzung intuitiv un-
terstu¨tzt oder sorgt das System fu¨r eine, nicht erwu¨nschte und vermeidbare, Verwirrung. Hier
empfiehlt die Norm die Platzierung des Logos auf der linken Seite. Im IS-System ist das Logo
auf der rechten Seite. Die bedeutsamere linke Seite wird fu¨r wichtigere Navigation zwischen
den Services benutzt. Links, die zu einer Seite ins Internet fu¨hrt, sind immer blau und somit
leicht unterscheidbar von herko¨mmlichem Text. Weiterhin gelangt man mit der Tabulator-
Taste zum na¨chsten GUI-Objekt, welches einstellbar ist. Der Focus ist automatisch auf dem
Objekt.
Fehlertoleranz Fehlermeldungen sollen laut der Norm nicht technisch oder durch krypti-
sche Nummer angezeigt werden. Beim IS wird im Ansatz auf solche Fehlermeldungen verzich-
tet. Trotzdem werden unvermeidbare Fehler abgefangen und werden dem Benutzer entweder
deutlich angezeigt (z.B. wenn keine Daten angezeigt werden ko¨nnen weil die Anfrage keine
Ergebnisse liefert) oder werden natu¨rlich-sprachlich umschrieben und im InfoPanel angezeigt.
277
Individualisierbarkeit Die Individualisierbarkeit soll ein System bzgl. der individuellen Vor-
lieben eines Nutzers parametrisieren. Dabei geht es nicht um Anfragespezifische Parameter
sondern um reine GUI-Objekte. Diese Mo¨glichkeit ist im System des IS nicht integriert, da
die Gefahr einer Verwirrung gro¨ßer erscheint als der Nutzen fu¨r ein Individuelles System.
Wie man erkennen kann ist die Norm nicht Eins zu Eins auf das GUI u¨bertragbar. Dennoch
decken sich die Grundzu¨ge der Norm mit dem GUI des IS-Systems.
5.5 Queryfacade
5.5.1 Konzept
Als Queryfacade wird die Abstraktionsschicht bezeichnet, die es erlaubt SQL-a¨hnliche An-
fragen an die stark heterogenen Daten zu stellen, die als Teilergebnisse der Projektgruppe
erarbeitet wurden. Der Name leitet sich aus
”
Query“ fu¨r Anfrage und
”
Facade“ fu¨r die Um-
setzung anhand des gleichnamigen Programmierpatterns ab. Um heterogene Daten als rela-
tionale Daten verarbeiten zu ko¨nnen, muss zuerst die Information festgehalten werden, wie
die einzelnen Daten strukturiert sind und wie sie miteinander in Relation stehen. Jede Daten-
quelle wird also darauf untersucht welche
”
Entita¨ten“ sie liefern kann, also z.B. Person incl.
aller perso¨nlichen Daten, oder Partei incl. des Namens und der Mitglieder. Diese Eigenschaf-
ten von Entita¨ten werden im Folgenden Attribute genannt. Sind die verfu¨gbaren Entita¨ten
erfasst, muss festgelegt werden wie die Entita¨ten miteinander in Beziehung stehen. Analog
zu einem relationalen Datenbank-Schema muss dabei auch angegeben werden, welches Attri-
but der verknu¨pften Entita¨ten als Fremdschlu¨ssel fungiert. Bei einer Abfrage, die Kriterien
an mehrere Entita¨ten stellt, werden dann anhand dieser Fremdschlu¨sselattribute Joins aus-
gefu¨hrt, also Wertevergleiche, um festzustellen welche konkreten Instanzen zweier Entita¨ten
miteinander in Beziehung stehen. Daraus ergibt sich dann ein relationales Schema, das in
XML gespeichert wird. Die Abstraktionsschicht besteht aus drei Hauptbestandteilen, zum
einen ist dies der Parser, der das relationale Schema liest und in ein Objektmodell u¨berfu¨hrt,
zum zweiten ist dies die Oberfla¨che, die das zusammenklicken von Fragen erlaubt, die dem
eingelesenen Schema entsprechen und zuletzt aus einer Frageverarbeitungskomponente, die
die zusammengeklickten Fragen annimmt und auswertet, sowie das Ergebnis zur Anzeige an
die Oberfla¨che zuru¨ckgibt. Die letzte Schicht gliedert sich wiederrum in sogenannte Adapter.
Dabei handelt es sich um Klassen, die einem bestimmten Interface genu¨gen mu¨ssen und den
strukturierten Zugriff auf jeweils eine Datenquelle erlauben. Im Grunde handelt es sich dabei
um Rohdaten-zu-Objekt Konverter.
5.5.2 Architektur
Im Folgenden werden die oben genannten einzelnen Schichten na¨her erla¨utert.
Relationales Schema und Objektmodell
Im relationalen Schema mu¨ssen zu jeder Entita¨t bestimmte Informationen hinterlegt werden.
Fu¨r die Entita¨t selbst muss angegeben werden, welche Java-Klasse als Container fu¨r Instanzen
der Entita¨t verwendet wird, welche Java-Klasse als Adapter fu¨r diese Entita¨t fungiert und
welchen eindeutigen Namen diese Entita¨t tragen soll. Als Kinder-Knoten der Entita¨t werden
278
Abbildung 5.12: Beispiel einer Entita¨tendefinition
ihre Attribute festgehalten, zu denen die Informationen: eindeutiger Name, Name des Attri-
buts in der Containerklasse, der Datentyp, sowie ein Textfragment zur Einbettung in einen
natu¨rlichsprachlichen Satz geho¨ren. Erlaubte Typen fu¨r Attribute sind
”
String“,
”
Integer“,
”
Date“,
”
Select“ und
”
List“. Bei Angabe von Select muss zusa¨tzlich eine Liste von Aus-
wahlmo¨glichkeiten fu¨r die Selectbox angegeben werden. Bei der Angabe von
”
List“ muss der
Ru¨ckgabetyp in der Containerklasse ein String-Array oder eine java.util.List mit Elementen
vom Typ String sein. Mit diesen Mechanismen ist es mo¨glich Beziehungen der Typen 1-zu-
1, 1-zu-n, sowie m-zu-n zu realisieren. Attribute ko¨nnen als Kinder-Knoten nun Relationen
enthalten, da eine Relation ja stets von einem Fremdschlu¨ssel abha¨ngig ist. Zu einer Relation
mu¨ssen die Zielentita¨t, ein Name fu¨r die Relation, der Attributname des Fremdschlu¨ssels in
der Zielentita¨t, sowie ein Textfragment zur natu¨rlichsprachlichen Einbettung. Da an jedes
Attribut auch Bedingungen geknu¨pft werden ko¨nne, wird in diesem Textfragment durch die
Zeichenfolge %value% markiert an welcher Stelle im Text das Eingabefeld fu¨r den Benutzer
angezeigt werden soll.
Der oben genannte Parser liest dieses Schema nun ein und u¨bersetzt es in ein Gefu¨ge von
Objekten, das durch direkte Referenzen miteinander in Beziehung steht. Dies erlaubt ein
”
Durchhangeln“ anhand dieses Graphen-a¨hnlichen Gebildes zur Halb-dynamischen Fragestel-
lung. Dieses sogenannte QOM oder QueryObjectModel wird als zum einen von der Ober-
fla¨che als Schema benutzt, das der Fragestellung zu Grunde liegt, zum anderen wird es in
der Frageverarbeitung dazu verwendet die Joins auszufu¨hren, da dort alle dafu¨r notwendigen
Informationen vorliegen.
Verarbeitung von Anfragen
Die grafische Oberfla¨che der QueryFacade ist in der Lage die vom Benutzer erstellte Frage
in XML Form auszudru¨cken. Dabei wird eine verschachtelte Struktur verwendet, die eine
beliebige Tiefe von Joins zwischen Entita¨ten zula¨sst.
Im Wurzelelement
”
QUERY“ wird mit dem Attribut
”
targetEntity“ festgelegt nach welcher
Entita¨t gesucht wird. Darauf folgt ein
”
AND“, das theoretisch erlaubt aus mehreren per Join
entstandene Ergebnismengen den Durchschnitt zu bilden (dies wird bislang nicht unterstu¨tzt).
Danach kann u¨ber
”
CONSTRAINT“ eine Bedingung an die Zielentita¨t gestellt werden und
eine beliebig tiefe Folge von
”
JOIN“ Elementen folgen, wobei jedes
”
JOIN“ seinerseits
”
CONS-
TRAINT“ Elemente enthalten kann, die dann Bedingungen auf die u¨ber
”
toEntity“ angege-
bene Entita¨t realisieren. Jedes
”
CONSTRAINT“ entha¨lt dabei die Informationen auf welches
Attribut es sich bezieht, von welchem Typ dieses Attribut ist und auf welchen Wert gepru¨ft
werden soll.
279
Abbildung 5.13: Beispiel einer QueryFacade Anfrage
Die Verarbeitung der Anfrage verla¨uft dann rekursiv von innen nach aussen. Es wird also zu-
erst auf die Entita¨t im innersten
”
JOIN“ Element zugegriffen, dann auf die Entita¨t eine Ebene
ho¨her. Dann wird ein Join ausgefu¨hrt, der aus der a¨ußeren Ergebnismenge alle herausfiltert,
bei denen keine Fremdschlu¨sselbeziehung zu einem Elemenent der inneren Ergebnismenge
besteht. Dieser Vorgang wird so lange wiederholt, bis das Wurzelelement der XML-Struktur
und somit die gesuchte Entita¨t erreicht ist.
Das JAVA Interface, das von den Adaptern implementiert werden muss, erzwingt fu¨r die Da-
tenru¨ckgabe den Datentyp
”
QueryResult“. Daher mu¨ssen alle Entita¨ten auf Containerklassen
abgebildet werden, die von diesem Typ erben. In der Oberfla¨che wird dann per Fallunter-
scheidung der tatsa¨chliche Datentyp gepru¨ft und ein zur Entita¨t passendes Ausgabepanel
gewa¨hlt.
5.5.3 Fragevorschau
Die Fragevorschau wird innerhalb der GUI beim Fragebeantwortungssystem verwendet, um
die vom User zusammen geklickten Fragen natu¨rlich sprachlich anzeigen zu ko¨nnen. Hierbei
gibt es unterschiedliche Verknu¨pfungsmo¨glichkeiten, die bei der Fragestellung durch
”
und“
verbunden werden. Entweder wa¨hlt man ein Attribut und macht eine Eintragung per Hand
und schickt die Frage ab oder man wa¨hlt eine weiterfu¨hrende Verknu¨pfung, diese sind mit
einem ”→ ” gekennzeichnet. Die Fragestellungsmo¨glichkeiten wurden von uns eingeschra¨nkt
damit unsinnige oder nicht auswertbare Fragen nicht gestellt werden ko¨nnen. Der User folgt
einem vordefinierten Schema und hat nur die Mo¨glichkeit, die von uns voreingestellten En-
tita¨ten und Attribute auszuwa¨hlen. Er kann nur in den Textfeldern frei Eingaben ta¨tigen, um
seine Frage weiter zu spezialisieren.
5.5.4 Fragebeantwortungssystem
Zu Begin hat der Nutzer die Mo¨glichkeit eine Zielentita¨t auszuwa¨hlen. Mit Hilfe dieser Entita¨t
wird die Frage spezialisiert und es ko¨nnen z.B. Fragen u¨ber eine Person(Abgeordneten), ein
Amt, Protokolle, Ausschu¨sse, Drucksachen, Wahlperioden und Dokumente gestellt werden.
Nachdem nun die Zielentita¨t ausgewa¨hlt wurde gibt es fu¨r jede Entita¨t eigene Bedingungen
die angeklickt und bestimmt werden ko¨nnen. Als erstes folgt hier ein Attribut welches gewa¨hlt
werden kann, danach ko¨nnen weitere weiterfu¨hrende Verknu¨pfungen gewa¨hlt werden, welche
innerhalb der Fragevorschau mit
”
und“ verbunden werden. Bei jeder Frage hat man zudem
280
Abbildung 5.14: Eine beispielhafte Frage
die Mo¨glichkeit selbst per Hand Daten/Informationen anzugeben und somit die Mo¨glichkeit
die Frage weiter einzuschra¨nken, um die gewu¨nschte Antwort zu erhalten.
Beispielhafter Ablauf
Nachfolgend betrachten wir beispielhaft ene Zielentita¨t Person mit den folgenden Bedingun-
gen:
1. Kinder ( Angabe Anzahl der Kinder)
2. A¨mter ”→ ” ( weiterfu¨hrende Verknu¨pfung der Frage gekennzeichnet mit ”→ ”)
3. Bezeichnung ( Angabe eines Amtes)
4. Besetzt durch ”→ ”( weiterfu¨hrende Verknu¨pfung der Frage gekennzeichnet mit ”→ ”)
5. Partei ( Angabe einer Partei)
Danach klickt man auf den Button
”
Suche starten“ und es wird die Antwort fu¨r die gestellte
Frage geliefert.
Vorschau
1. Wie es gut la¨uft: Welche Person hat/mit ’2’ Kind(er/n) und hat das Amt mit der
Bezeichnung ’Finanzminister’ inne und ist besetzt durch eine Person der/die Mitglied
der Partei ’SPD’ ist ?
281
2. Wie es nicht so gut la¨uft: In welchem Ausschuss und der/die Mitglied der Partei ’SPD’
ist und ta¨tig in Wahlperiode ’14’ ?
Wir sehen hier, dass dieses nicht immer optimal abla¨uft, denn es ist eine sehr komplexe
Aufgabe eine Struktur in eine natu¨rlich sprachliche umzuformen.
Dies ist uns auch anhand unserer Seminare und den dort besprochenen Themen klar geworden.
Es wa¨re gut gewesen, wenn die Vorschau, wie unten gezeigt, aufgebaut worden wa¨re. Dies ist
uns leider nicht so gut gelungen. Wieso dies nicht geklappt hat, wurde weiter oben kurz
erla¨utert.
Beispiele fu¨r eine gute Fragevorschau
Amt: Welches Amt hatte die (Person) inne?
Welches Amt wurde von (Person) ausgefu¨hrt?// Welches Amt hatte die (Person) in der
WP(Nr.) inne?
welche A¨mter gab/gibt es in der Wahlperiode(Nr.)?
welches Amt begann am (Datum)?
welches Amt endete am (Datum)?
welches Amt wurde durch einen (MOPS Fragen einbringen) besetzt?
Welche A¨mter wurden durch Abgeordnete der (Partei) besetzt?
Welche Ministerposten wurden durch Abgeordnete der (Partei) ausgefu¨llt?
Welche A¨mter in der (Nr.)Wahlperiode wurden von welchem Abgeordneten ausgefu¨hrt?
Welches Amt wurde in Wahlperiode(Nr.) durch einen (MOPS Fragen)?
Person: Welche/r Abgeordneter hat welches Amt in der Wahlperiode (Nr.) ?
Welche/er Abgeordnete/er besetzt das Amt (Name Amt)?
Welcher Abgeordnete/er besitzt in der Wahlperiode (Nr.) ein Amt/Ausschuss mit der
Bezeichnung(Bez.)?
Welcher Abgeordnete/er ist (MOPS fragen, verheiratet usw.) + A¨mter/Ausschuss/Protokoll..?
Welcher abgeordneter besitzt ein Amt und ist ledig?
Welche Abgeordneten sind in der Wahlperiode(Nr.) Mitglied der Partei(Name)?
Welcher Abgeordneter war/ist vorsitzender eines Ausschusses?
Welcher Abgeordnete/er ist Mitglied der (Parteiname)?
Welcher Abgeordnete/er verfasste die Drucksache(Protokoll/Rede) mit der (Nr., ID, am
Datum, in WP, mit Titel)?
Liefere/Suche alle Mitglieder des Ausschusse (Name) aus WP(Nr.)!
Liefere/Suche alle Mitglieder des (Name)Ausschusses!
Liefere/Suche alle Abgeordneten der Partei (Name) die in einem Ausschuss vertreten
sind!
Liefere/Suche alle Abgeordneten der Partei (Name) die in der Wahlperiode(Nr.) in ei-
nem Ausschuss vertreten sind!
Protokoll: Liefere/Suche das Protokoll/Antra¨ge/Reden mit der Nummer (Nr.)!
Welches/e Protokoll/Antra¨ge/Reden wurde am (Datum)verfasst vom Autor(Name)?
Liefere/Suche alle Protokolle/Antra¨ge/Reden von WP(NR) aus vom Autor(Name)!
Liefere/Suche alle Protokolle/Antra¨ge/Reden von (Personname)!
282
Liefere/Suche alle Protokolle/Antra¨ge/Reden aus die von Minister (Personname) ver-
fasst wurden?
Liefere/Suche alle Protokolle/Antra¨ge/Reden die in Wahlperiode(Nr.) durch Abgeord-
nete der (Parteiname) verfasst wurden!
Liefere/Suche alle Protokolle/Antra¨ge/Reden die von Ausschlussmitgliedern/Vorsitzen-
den verfasst wurden!
Liefere/Suche alle Protokolle/Antra¨ge/Reden die von Ausschlussmitgliedern/Vorsitzen-
den in der Wahlperiode (Nr.) verfasst wurden!
Liefere/Suche alle Protokolle/Antra¨ge/Reden von Ministern!
Liefere/Suche alle Protokolle/Antra¨ge/Reden von (MOPS anfrage)
Liefere/Suche alle Protokolle/Antra¨ge/Reden von Ministern von der Partei(Name) die
(in Wahlperiode(Nr.))ein Amt bezogen haben/hatten!
Liefere/Suche alle Protokolle/Antra¨ge/Reden von Ministern die ein Amt bezogen ha-
ben/hatten!
Drucksache: Liefere/Suche alle Drucksachen vom Typ (Name)!
Liefere/Suche die Drucksache mit der Nummer (Nr.) aus!
Liefere/Suche die Drucksache die am (Datum) verfasst wurde!
Liefere/Suche alle Drucksachen aus Wahlperiode(Nr.)!
Liefere/Suche alle Drucksachen mit dem Schlagwort (Thema) aus!
Liefere/Suche alle Drucksachen in der (Personname) vorkommt!
Liefere/Suche alle Drucksachen die von (Personname)verfasst wurde!
Liefere/Suche alle Drucksachen die von (Personname)in Wahlperiode(Nr.)verfasst wur-
den und die in einem Ausschuss/Amt (Name) ta¨tig sind/waren!
Liefere/Suche alle Drucksachen die von Abgeordneten (Name), welche in der WP(Name)
ta¨tig waren/sind!
Liefere/Suche alle Drucksachen die vom Abgeordneten mit der ID (Nr.) verfasst wur-
den!
Liefere/Suche alle Drucksachen die von (Personname)+(Mops Anfragen) verfasst wur-
den!
Partei: Welcher Partei geho¨rt (Name) an?
In welcher Partei sind die meisten Abgeordneten verheiratet/ledig?
In welcher Partei sind die meisten Doktoren?
Zu welcher Partei geho¨rt der Abgeordnete mit den meisten Kindern?
Welche Parteiabgeordneten kandidierten in Wahlkreis(Nr.)?
Welcher Partei geho¨rt der Ausschussvorsitzende (Personname)von (Amtname) an?
Welche Mitglieder der (Parteiname) haben ein Ministerposten in der Wahlperiode (Nr.)?
Welche Mitglieder der (Parteiname) haben ein Ministerposten?
Welche Mitglieder der (Parteiname) haben ein Ministerposten der am (Datum) begann
oder endete?
Wahlperiode(Wp): In welcher Wp wurde das Amt des Bundeskanzlers durch Schro¨der be-
setzt?
Welche Wp begann/ endete am (Datum)?
283
Welche Abgeordneten waren in der Wp(Nr.) im Bundestag vertreten?
In welcher Wp war (Person) Mitglied/Vorsitzender/stellv. eines Ausschusses?
Liefere/Suche aus der Wp (Nr.) alle Mitglieder des Ausschusses(Name)!
In welcher Wp(NR) wurde der Ministerposten(Name) von Person(Name) besetzt?
Liefere/Suche alle in der Wp(Nr.) verfassten Protokolle/Antra¨ge/Reden!
Liefere/Suche alle in der Wp(Nr.) verfassten Protokolle/Antra¨ge/Reden vom Autor!
Liefere/Suche alle in der Wp(Nr.) vorkommenden Ausschu¨sse/A¨mter
Liefere/Suche aus Wp(Nr.) den Ausschuss Vorsitzenden/ stellv.Vorsitzenden!
Liefere/Suche aus Wp(Nr.) alle Drucksachen/Protokolle (vom Autor(Name))!
Suche aus WP(Nr.) das Amt von Person (Name)!
Ausschluss: In welchem Ausschuss sind Abgeordnete der (Parteiname)?
In welchem Ausschuss aus der Wp(Nr.) sind Abgeordnete der (Parteiname)?
Wer ist Ausschluss Vorsitzender/stellv.Vorsitzender fu¨r den Ausschuss (Name)?
Wer ist Ausschluss Vorsitzender/stellv. Vorsitzender fu¨r den Ausschuss (Name) in der
Wp(Nr.)?
Liefere/Suche alle Ausschlu¨sse der Wp(Nr.)!
In welchem Ausschuss heißt der stellv. Vorsitzende (Personname)?
Liefere/suche Ausschussmitglieder der Wp(Nr.) die zur (Partei)!
Liefere/Suche Ausschussmitglieder der Wp(Nr.) die Mops!
Dokument (Dok): Gib/Liefere das Dok mit der Nummer(Nr.)!
Gib/Liefere das Dok was/welche am (Datum) verfasst wurde!
Gib/liefere das Dokument mit dem Thema (Themaname)!
Suche alle Dokumente der/des Abgeordneten (Name)!
Das Enity-Relation Schema:
5.6 Dossier
5.6.1 Aufgabe
Ein Dossier, franzo¨sisch fu¨r Aktendeckel, ist eine Sammlung von Dokumenten zu einem be-
stimmten Thema und bildet einen substantiellen Teil der Projektaufgabe. Da in den Da-
tenbanken des Bundestages die gemeinsame Darstellung von Daten zu einem Abgeordneten,
inklusive einer Auflistung aller seiner Reden und Dokumente nicht vorhanden ist, hat die
Projektgruppe beschlossen diese aus den extrahierten Daten zu erstellen.
Zu diesem Zweck wurde eine Anwendung erstellt die entweder
”
standalone“, oder als Kompo-
nente der Fragebeantwortung eingesetzt werden kann. Die Anwendung stellt in einer Listenan-
sicht alle Abgeordneten des Bundestages dar. Die Abgeordneten Elemente werden im relevan-
ten Zeitraum, hier Wahlperioden 14 bis 16, angezeigt. In der Listenansicht kann der Benutzer
einen Abgeordneten auswa¨hlen um sein Dossier einzusehen. Das Dossier wird on-demand
erstellt, es entha¨lt alle extrahierten Informationen zu dem Abgeordneten in der jeweiligen
Wahlperiode. Zusa¨tzlich wird eine Liste aller Dokumente und aller Reden dargestellt, die in
284
Abbildung 5.15: Vorschau des Schemas
285
Abbildung 5.16: Dossier im U¨berblick
der Wahlperiode von dem Abgeordneten verfasst oder gehalten wurden. Fu¨r die Pra¨sentation
auf dem Campusfest der TU Dortmund wurde ein weiteres Feature eingebaut, na¨mlich die
Query an die Google Bildersuche, die ein zufa¨lliges Bild des/der Abgeordneten herunterla¨dt
und zeigt.
5.6.2 Realisierung
Die Software wurde in der Programmiersprache Java geschrieben. Die aus der Software-
technik bekannte MVC-Architektur wurde durchgehend realisiert und gliedert dementspre-
chend die Software in drei Schichten. Die Model Schicht bildet alle vorhandenen Entities
ab und ist nur fu¨r die Datenhaltung zusta¨ndig. In der Control Schicht befindet sich die
gesamte Ausfu¨hrungslogik. Diese Schicht ist fu¨r die Erzeugung und Verwaltung von En-
tita¨ten zusta¨ndig. Die GUI ist nur fu¨r die Darstellung verantwortlich und beinhaltet keine
Ausfu¨hrungslogik. Die GUI wurde im Hinblick auf die Integration in dem Gesamtsystem als
Container implementiert, damit sie ohne weiteres in eine bereits vorhandene GUI des Frage-
beantwortung Systems [P02] integriert werden kann.
Die Abbildung 5.16 zeigt die mehrschichtige MVC Architektur der Komponente und die
Interaktion der Control Schicht mit Lucene [K02] und der MOPS XML [D06] Datenbank.
Die Komponente benutzt Lucene um auf die Indexdatenbanken der Dokumente und Reden
zuzugreifen. Wird vom Benutzer ein Dossier eines Abgeordneten angefordert, so wird zuerst
der Abgeordnete mit allen seinen Daten aus MOPS XML instanziert. Danach wird jeweils die
passende Instanz von Lucene angesprochen und ihre Ru¨ckgabe, also eine Liste der Dokumente
oder Reden als Links dargestellt. Zuletzt wird die Google Bilddatenbank nach einem Bild des
Abgeordneten durchsucht.
5.6.3 Packages
Das Dossier besteht aus einem zentralen Package : de.unidortmund.pg520.dossier in dem die
Klassen der Control Schicht und drei weitere Packages untergebracht sind:
ˆ dossier.gui - in dem sich alle Klassen der GUI Schicht befinden,
286
Abbildung 5.17: Java Packages der Komponente Dossier
ˆ dossier.dokument - mit allen Entity Klassen, also der Model Schicht,
ˆ und schließlich dossier.tools mit sogenannten Helfer Klassen.
Die GUI Schicht ist entsprechend dem Java GUI Container-Component Prinzip aufgebaut.
Sie bildet mit Containern die Control Klassen ab und ist fu¨r die Darstellung ihrer Ausgabe
verantwortlich. Zusa¨tzlich werden alle Entities als GUI Components ausgegeben und referen-
ziert. Die Zuordnung zwischen den GUI und den Control und Entity Klassen ist folgender
weise zu verstehen: eine Control Klasse wird durch einen GUI Container dargestellt also in
der Regel durch ein JPanel. Eine Entity wird meistens durch ein JLabel dargestellt. Ein Ab-
geordneten Objekt ist eine Entity, entha¨lt aber Referenzen auf die Entities der Reden und
Dokumente, sowie das geladene und skalierte Google Bild. Mit dieser einfachen Hierarchie
kann die GUI in einem Aufruf top-down dargestellt werden.
Das in der Abbildung 5.17 abgebildete dossier.dokument Package entha¨lt alle Entity Klassen
der Komponente. Wir unterscheiden zwischen zwei Arten von Entities: einerseits Elemente
der Abgeordnetenliste, hier Instanzen der Klasse DossierAbgeordneter. Andererseits ist das
Dossier mit den Daten des einzelnen Abgeordneten und seine referenzierten Dokumente und
Reden.
ˆ dossier.dokument.DossierAbgeordneter
Element der Abgeordneten Auswahlliste, besteht aus der MOPS ID, dem Namen und
Vornamen des Abgeordneten.
ˆ dossier.dokument.Dossier
Das wahlperioden-abha¨ngige Dossier eines Abgeordneten mit allen seinen Daten aus
MOPS XML. Ha¨lt Referenzen auf alle seine Dokumente und Reden.
ˆ dossier.dokument.DossierDokument
Ein Objekt das ein Dokument abbildet, mit ID, Link und Titel.
ˆ dossier.dokument.DossierRede
Ein Objekt das eine Rede abbildet, mit ID, Link und Protokoll Nummer.
Das dossier.tools Package entha¨lt Helfer Klassen die kleinere Funktionen erfu¨llen.
287
Abbildung 5.18: Control und Entity Klassen des Dossiers
ˆ dossier.tools.GooglePicDownloader
Diese Klasse ist fu¨r die Query der Google Bilddatenbank zusta¨ndig und la¨dt das erste
verfu¨gbare Bild des Abgeordneten runter. Zusa¨tzlich wird das Bild passend skaliert, so
dass es die Breite des Fensters nicht u¨berschreitet.
ˆ dossier.tools.JdomXMLReader
Diese Klasse vereinfacht den Zugriff auf XML Dokumente in dem sie die Dokumente
passend als Objekt zuru¨ckgibt. Diese ist fu¨r den Zugriff auf die MOPS XML Datenbank
notwendig.
ˆ dossier.tools.JdomXMLWriter
Diese Klasse ist fu¨r das schreiben von XML Dateien zusta¨ndig.
Das pg520.dossier Package entha¨lt die Control Klassen der Anwendung.
ˆ dossier.DossierCacheControl
Diese Klasse bildet transparent die Methoden der DossierControl Klasse ab und ist fu¨r
die Verwaltung des Cache zusta¨ndig. Ein Aufruf aus der GUI wird zuna¨chst in dieser
Klasse verarbeitet bevor es eine Ebene tiefer, zu der eigentlichen Dossier Erstellung
weitergeleitet wird. Diese Klasse pru¨ft also ob im Dateisystem ein generiertes Dossier
bereits vorhanden ist, sollte dies nicht der Fall sein, wird ein neues Dossier in der
DossierControl Klasse erstellt. Diese Klasse ist noch nicht vollsta¨ndig implementiert.
ˆ dossier.DossierControl
Die wichtigste Control Klasse der Komponente. Sie ist fu¨r die Erzeugung eines Dossiers
zusta¨ndig und fu¨hrt alle hierfu¨r notwendigen Schritte aus. U¨ber eine MOPS ID wird
ein Abgeordneter in MOPS XML nachgeschlagen und die Listen seiner Dokumente und
Reden aus der Ausgabe von Lucene erzeugt.
ˆ dossier.SearchControl
SearchControl implementiert die Funktionalita¨t der Abgeordneten Suche. Sie stellt an
288
Abbildung 5.19: Bildschirmfoto der Abgeordnetenauswahl und eines Dossiers
Hand ein paar Stichwo¨rter eine Liste der Abgeordneten dar, deren Vor- oder Nachname
den Suchkriterien entsprechen.
ˆ dossier.DossierSelector
Eine Klasse mit der die Anwendung gestartet wird, sie erstellt eine, nach Anfangsbuch-
staben geordnete Gesamtliste aller Abgeordneten. Aus dieser Liste kann der Anwender
ein Dossier auswa¨hlen, welches dann von DossierCacheControl erstellt wird.
5.6.4 GUI Design und Anwendungsfa¨lle
In dieser einfachen Anwendung werden alle Funktionen aus der GUI aufgerufen. Deshalb ist
die GUI an dieser Stelle ganz eng mit den Anwendungsfa¨llen verknu¨pft. Eine aktuelle Ansicht
der GUI befindet sich in der Abbildung 5.19. Der Benutzer navigiert und ruft Funktionen mit
der Maus auf. Das Suchformular erfordert selbstversta¨ndlich eine Tastatureingabe.
Die GUI Ansicht besteht aus zwei Teilen, in dem Oberen befindet sich die Suchfunktion und
die Navigationsschaltfla¨chen. Dieser Teil wird immer Dargestellt, es wird allerdings der Titel
entsprechend dem Modus der Anwendung gea¨ndert und die Auswahl Schaltfla¨che ein- oder
ausgeschaltet. Der untere Teil der Ansicht ist variabel und vera¨ndert seinen Inhalt abha¨ngig
zum Darstellungsmodus. Dem Benutzer stehen zwei Modi innerhalb der GUI zur Verfu¨gung:
ˆ Abgeordneten Suche
wird von der dossier.gui.SelectionListPanel dargestellt.
Zeigt eine nach Anfangsbuchstaben des Nachnamens gruppierte und sortierte Liste al-
ler Abgeordneten. Jeder Eintrag besteht aus der aktuellen MOPS ID, dem Vornamen,
Nachnamen und der Partei des Abgeordneten. Die Liste ist unabha¨ngig von der Wahl-
periode und wird aus dem gesamten Datensatz erstellt.
289
Abbildung 5.20: Anwendungsfall Diagramm
ˆ Dossier des Abgeordneten
wird von der dossier.gui.DossierWindowPanel dargestellt.
Stellt einen Abgeordneten mit allen in MOPS verfu¨gbaren Informationen dar. Zusa¨tzlich
wird ein Bild des Abgeordneten angezeigt. Darauf folgen die Listen der von ihm Verfas-
sen Dokumente und der von ihm gehaltenen Reden. Das Bildschirmfoto 5.19 zeigt ein
exemplarisches Dossier des Abgeordneten Ulrich Adam aus der 14-ten Wahlperiode.
Die Anwendung schaltet abha¨ngig vom Zustand in einen der Modi, welche in dem Anwen-
dungsfall Diagramm, Abbildung 5.20, gezeigt werden. Das Diagramm zeigt die Interaktion
des Benutzers mit der GUI und die Funktionen, die in dem jeweiligen Modus auswa¨hlt werden
ko¨nnen. Folgende Optionen stehen dem Benutzer in der Abgeordneten Suche zur Verfu¨gung:
ˆ Auswahl: Abgeordneter
Diese Funktion schaltet in den Dossier des Abgeordneten Modus und stellt die Infor-
mationen des Abgeordneten dar.
ˆ Suche: Abgeordneter
Hiermit werden die Abgeordneten Elemente der hier dargestellten Liste auf die vom Be-
nutzer in das Formularfeld eingegebenen Namen eingeschra¨nkt. Die Suche funktioniert
auch auf einzelnen Buchstaben oder Teilen der Vor oder Nachnamen. Diese Funktion
wird durch das Klicken auf den Suchen Button gestartet.
Der zweite Modus der Darstellung ist das Dossier des Abgeordneten. Es wird in diesen Modus
umgeschaltet, wenn ein Abgeordneter aus der Liste ausgewa¨hlt wird. In diesem Panel hat der
Benutzer folgende Funktionen zur Auswahl:
290
ˆ Auswahl: Dokument
Diese Funktion o¨ffnet das PDF Dokument der ausgewa¨hlten Drucksache in einem vom
Betriebsystem ausgewa¨hlten Darstellungstool. Diese Funktion ist abha¨ngig vom Be-
triebsystem des Host-Systems. Zur zeit funktioniert sie nur in Windows Umgebungen.
ˆ Auswahl: Rede
Diese Funktion o¨ffnet das XML Dokument der ausgewa¨hlten Rede in einem vom Be-
triebsystem ausgewa¨hlten Darstellungstool. Diese Funktion ist abha¨ngig vom Betrieb-
system des Host-Systems. Zur zeit funktioniert sie nur in Windows Umgebungen. Diese
Funktionalita¨t ist nur testweise Eingebaut worden, da ein in Java geschriebenes Dar-
stellungstool fu¨r diese annotierten Reden, geplant aber noch nicht entwickelt worden
ist.
ˆ Suche: Abgeordneter
Diese Funktion schaltet die Anwendung in den Modus der Abgeordneten Suche. Es wird
eine neue, an Hand der Formularfeld Benutzereingabe generierte, Liste der Abgeordne-
ten Elemente erstellt. Diese Funktion wird durch das Klicken auf den Suchen Button
gestartet.
ˆ Zuru¨ck zur Liste
Die Anwendung wird in den Modus der Abgeordneten Suche geschaltet, allerdings wird
wieder die gesamte Liste der Abgeordneten dargestellt. Diese Funktion wird durch das
Klicken auf den Auswahl Button gestartet.
5.6.5 Anmerkungen zur Performanz und Anekdoten
Die Geschwindigkeit mit der die Anwendung Benutzer Anfragen beantwortet, ha¨ngt in erster
Linie von drei Faktoren ab. Lucene ist in den Antworten sehr stabil, es gab keinen merkbaren
Unterschied zwischen der Rechenzeit einer 30-stelligen oder einer 5-stelligen Dokumentenliste.
Das Antwortverhalten von Lucene beeinflusst zwar die Performance der Anwendung, spielt
jedoch eine untergeordnete Rolle. Die Gro¨ße der MOPS XML Datenbank ist hingegen fu¨r den
Zugriff auf die Abgeordneten entscheidend. Da es sich um eine XML Datei handelt, muss sie
vollsta¨ndig in den Speicher geladen und durchsucht werden. Der zweite Faktor ist auf den ers-
ten Blick recht unscheinbar, spielt aber eine sehr wichtige Rolle. Die Google Bildersuche war
nicht nur schwierig zu implementieren, sie liefert a¨ußerst unterschiedliche Antwortzeiten. Eine
Anfrage bei Google liefert bekannter maßen einen Link zuru¨ck. Das dahinter liegende Bild
muss zuerst heruntergeladen und dann skaliert werden. Da dieses Bild eine zufa¨llige Gro¨ße
haben kann, ist die Zeit, welche die Anwendung dafu¨r beno¨tigt sehr schwer einzuscha¨tzen. In
den Testla¨ufen dauerte eine Anfrage im durchschnitt 5 Sekunden. Die la¨ngste Zeit, 75 Sekun-
den, brauchte die Anwendung fu¨r ein Bild der Abgeordneten Petra Pau: es gibt tatsa¨chlich
Menschen die 5 Megapixel Bilder im Internet publizieren.
Wie man aus dem Klassendiagramm der Control Schicht in der Abbildung 5.18 entnehmen
Kann wurde ein Cache-Mechanismus geplant der die bereits erstellten Dossiers und Bilder
als XML Dateien ablegt. Bei Bedarf wird in der DossierCacheControl die Ausfu¨hrung un-
terbrochen und dieses XML geladen und dargestellt. Dieser Mechanismus wurde leider nicht
vollsta¨ndig implementiert - es fehlte die Zeit diese Funktionalita¨t zu programmieren.
291
Die Helfer Klasse, welche Google parst war eine Herausforderung in sich. Erstens musste Goo-
gle vorgegaukelt werden, dass nicht eine Java Anwendung, sondern ein echter Internetbrowser
die Anfrage stellt. Zweitens bestehen Webseiten von Google nur aus JavaSkript Funktionen
die erst auf dem Browser gerendert werden. Damit mussten die Verweise auf die Bilder aus
den Parametern der Funktionen mu¨hsam herausgeschnitten werden. Die Google Bildersuche
ist im Großen und Ganzen nur mit viel Aufwand und sehr vielen regula¨ren Ausdru¨cken pars-
bar. Ironischer weise verlangt Google von allen anderen Internet Seiten, gerade den Einsatz
solcher Verschleierungspraktiken zu unterlassen.
5.7 PartyNator
Der PartyNator ist eine Java Komponente, die speziell fu¨r das Campusfest entwickelt wurde,
und dient zur Unterhaltung der Besucher. Sie bestimmt die Parteizugeho¨rigkeit des Benut-
zers anhand von Attributen, die ausgewa¨hlt und ausgefu¨llt werden ko¨nnen. Zur Auswahl der
Attribute stehen folgende zur Verfu¨gung:
ˆ Ausbildung
ˆ Geburtsort
ˆ Geburtsjahr
ˆ Familie
ˆ Kinder
Der PartyNator arbeitet eng mit den Datensa¨tzen der Abgeordneten Information, dem MOPS,
zusammen. Es werden Personen Objekte erstellt, die bestimmte Attribute haben. Zum einen
ist es die User Person mit den Attributen, die der Benutzer eingibt und zum anderen die
Personen aus dem MOPS, deren Attribute aus der MOPS-XML geholt wird.
Je nachdem, welche Attribute ausgewa¨hlt werden, werden diese mit den Feldern der Eintra¨ge
im MOPS verglichen. Je nach Anzahl der Attribute wird eine spezielle Anfrage an MOPS
gestellt, die eine Liste von Namen der Abgeordneten liefert. Diese Namen erfu¨llen stets die
ausgewa¨hlten und konjugierten Attribute. Fu¨r alle Attribute wurden similarity-Werte festge-
legt und fu¨r die Attribute ”Geburtsjahr”, ”Kinder”, ”Beruf”wurde eine A¨hnlichkeitsfunktion
definiert. Nachdem die Attribute zwischen der User Person und der Attribute der MOPS-
Person verglichen wurden, werden den MOPS-Personen globale similarity Werte zugeordnet.
Die Personen liegen mit den similarity Werten in einem 1-dimensionalen Raum.
Durch das parametrisierbare A¨hnlichkeitsmaß a, bestimmt man die Clustergro¨ße zwischen
der User Person und der MOPS-Person. Die Clustergro¨ße korrespondiert zu der euklidi-
schen Distanz zwischen zwei Personen. Wenn man das A¨hnlichkeitsmaß a beispielsweise auf 1
setzt(enstpricht 100 % A¨hnlichkeit) setzt, ist die Clustergro¨ße auf Minimum. Es werden nur
die Personen betrachtet, die eine euklidische Distanz von 0 besitzen zur User Person. Setzt
man das A¨hnlichkeitsmaß niedriger, also beispielsweise auf 70%-80% A¨hnlichkeit, werden viel
mehr Personen in das Cluster aufgenommen. Das Cluster wa¨chst somit in seiner Gro¨ße, und
die euklidische Distanz ist gro¨ßer als 0.
Fu¨r das Attribut ”Beruf”wurde zusa¨tzlich eine XML-Datei erstellt, welches die Berufe in einer
Hierarchie abbildet. Diese Baumstruktur ist die Grundlage fu¨r die A¨hnlichkeit von Berufen.
292
Fu¨r zwei Berufe werden alle Knoten des jeweiligen Berufspfades in eine Liste u¨berfu¨hrt. Zum
Schluß werden die similarity Werte bestimmt, indem die Listenelemente miteinander vergli-
chen werden.
Weiterhin wird ein Parteiza¨hler hochgeza¨hlt um zu bestimmen, wieviele Personen jeweils zu
welcher Partei angeho¨ren. Wichtig ist dabei auch, alle Abgeordneten des Bundestages zu be-
stimmen. Dies ist notwendig, um die Personenanzahl zu normalisieren. Durch die recht simple
Formel wird dann ein Parteiaffinita¨tswert bestimmt:
Beispiel
pi =
zi
ai
pi ist dabei der Wert fu¨r die Partei i
zi ist die Anzahl der Personen der jeweiligen Partei i auf die die Attribute zutreffen
ai sind alle Personen die der Partei i angeho¨ren
Die Normalisierung fu¨hrt dazu, dass Parteien, die im Bundestag mit einer relativ niedrigen
Personenanzahl vertreten sind, auch grundsa¨tzlich sta¨rker bevorzugt werden. Die Gewich-
tung ist pro Person hier ausschlaggebend. Als Ausgabe liefert der Partynator schließlich die
Affinita¨ten in Prozent. Diese werden weiter oben im System visualisiert.
5.8 Datensa¨tze
5.8.1 Aufbau
Mit dem RMDatensatzBuilder wird ein in der Hauptgui eingebettetes Programm bezeichnet,
das zwei Dateien fu¨r die Weiterverarbeitung mit dem RM erstellt. Diese zwei Dateien werden
im folgenden Datensatz genannt. Ein Administrator ist in der Lage die beno¨tigen Datensa¨tze
mit einem Mausklick zu erstellen. Der Vorgang besteht aus drei Komponenten, die weiter
na¨he erla¨utert werden. Zu beachten an dieser Stelle ist, dass die Laufzeit des Algorithmus
je nach dem bis zu 20 Minuten dauern kann. Bei den Datensa¨tzen ist es zwischen Standard-
und Personenattribute zu unterscheiden. Standardattribute sind Attributen, die zwingend in
den Datensatz kommen. Personenattribute sind Attributen aus MOPS z.B. Wahlkreis, die
der Administrator durch die Auswahl dazufu¨gen kann.
5.8.2 Grafische Oberfla¨che
Die erste Komponente ist die grafische Oberfla¨che, die die Mensch-Maschinen Interaktion
erlaubt. Sie wird in die Hauptgui integriert, so dass der Administrator den gewu¨nschten
Datensatz auswa¨hlt, der er erstellen mo¨chte. Folgende Datensa¨tze ist der Administrator in
der Lage zu erstellen:
ˆ Abgeordnete
ˆ Minister
ˆ Ausschus mit den Standardattributen:
– Mitglieder,
– Name,
293
Abbildung 5.21: RMDatensatzBuilder
– Wahlperiode,
– Vorsitzender
ˆ Abstimmung mit den Standardattributen:
– Mitglieder,
– Drucksache,
– Wahlperiode,
– Datum,
– Name,
– Ergebnis
ˆ Drucksache mit den Standardattributen:
– Autoren,
– Wahlperiode,
– Datum,
– Titel,
– Nummer,
– Typ
ˆ Amt mit den Standardattributen:
– Begin,
– Ende,
– Wahlperiode,
– Bezeichnung,
294
– Typ
ˆ Protokoll mit Standardattributen:
– Autoren,
– Datum,
– Wahlperiode,
– Nummer
ˆ Dokument mit Standardattributen:
– Autoren,
– Datum,
– Wahlperiode,
– Nummer
Zu jedem Datensatz kann man auch wahlweise durch den entsprechenden Checkbox weitere
Personenattribute (z.B. Geburtsort) bestimmen. Den Namen fu¨r die Datei gibt man auch
ein. Mit dem Dru¨cken auf den Button wird die Anfrage an die unteren beiden Komponenten
weitergeleitet.
5.8.3 Anfrage
Die zweite Komponente stellt einen Parser da, der entsprechende XMLs ausließt und dar-
aus Objekte der entsprechenden Klasse erzeugt. Weiterhin werden weitere Objekte je nach
dem ausgewa¨hlten Datensatz erzeugt oder die Attributen zu den existierenden Objekten ge-
setzt. Z.B. wa¨hlt man der Administrator das Ausschuss als der Datensatz aus, so wird das
Ausschuss.xml und das MOPs.xml gelesen und daraus Ausschuss- und Person-Objekte mit
den entsprechenden Standardattributen erzeugt. Danach werden die Objekte verknu¨pft (hier
an der Stelle PersonenId) und zu den Ausschuss-Objekten die Personenattribute aus Person-
Objekten gesetzt. Die resultierende Objekte haben die gewu¨nschte Eigenschaften, na¨mlich, sie
sind die Instanzen der Klasse Ausschuss und haben alle Personenattributen, die der Adminis-
trator ausgewa¨hlt hat. Fu¨r die Datensa¨tze Abgeordnete und Person sind keine Verknu¨pfungen
mit den Person-Objekten no¨tig.
5.8.4 .dat und .aml Dateien
Nach dem von oberen zwei Komponenten alle Objekte vorbereitet sind, kommt die dritte
Komponente ins Spiel, die aus den resultierenden Objekten zwei Dateien erstellt. Genauer,
eine Liste von Objekten, z.B. Ausschuss-Objekten in eine .dat Datei schreibt und dazu eine
beschreibende .aml Datei erstellt. Jedes Objekt mit seinen Attributen wird in eine neue Zeile
der .dat Datei geschrieben. In den ersten n(Anzahl der Standardattributen) Spalten stehen die
Werte von den Standardattributen. In den letzten Spalten wird, wenn der Administrator die
Personenattribute ausgewa¨hlt hat, fu¨r jede Person und jede ihre Attribute, die beispielsweise
in einem Ausschuss sind, eine Spalte investiert. Die Spalten werden wie folgt Personenname,
Personenname-Wahlort, ... genannt. Die .aml Datei ist in der XML-Form geschrieben und
beschreibt, wie die einzelnen Spalten in der .dat Datei auszusehen sind und welche Werte(nicht
bei integer) sie annehmen ko¨nnen. In der Spalte Personenname kann nur true, wenn die
295
Person dabei ist oder false, wenn nicht, stehen. In der Spalte Personenname-Wahlort steht der
tatsa¨chliche Wert, wenn die Person dabei ist, oder null, wenn nicht. Weiter sind beispielhafte
.dat und .aml Dateien dargestellt.
<?xml version="1.0" encoding="UTF-8" ?>
<attributeset default_source="Aussschuss.dat">
<attribute name="Wp" sourcecol="1" valuetype="integer">
</attribute>
<attribute name="Name" sourcecol="2" valuetype="nominal">
<value>Arbeit</value>
<value>Angelegenheiten</value>
...
<value>null</value>
</attribute>
<attribute name="Vorsitz." sourcecol="3" valuetype="nominal">
<value>Doriss Barnet</value>
<value>Werner Kuhn</value>
...
Tabelle 5.1: Allgemeine Form der .dat Datei
Standartattribute Personenattributen (fu¨r jeden Mitglied, der je
einen Antrag gestellt hat, eine Spalte)
... ...
... ...
Tabelle 5.2: Ausschnitt aus Ausschuss.dat
Wp Name Vorsitz. Klaus
Brand-
ner
Klaus
Brandner-
Wahlort
... Rainer
Fornahl
Reiner
Fornal-
Wahlort
...
14 Arbeit Doriss
Barnet
true Gu¨tersloh ... false null ...
14 AngelegenheitWerner
Kuhn
false null ... true Leipzig I ...
... ... ... ... .. ... ... ... ...
5.9 Eigenentwicklungen
5.9.1 Event Cutter
Einleitung
Der Event Cutter ist eine Java Komponente, die als Eingabe ein Text Dokument x und ein
Stichwort y erha¨lt. Als Ausgabe bekommt man die Zeile i, in der das Stichwort y vorkommt
und die Zeilen i-1, i-2, i+1, i+2.
296
Abbildung 5.22: Ausschnitt des Event Cutters
Motivation
Da fast alle Text Dokumente des Deutschen Bundestags mehrere Seiten einnehmen, ist eine
Suche nach einem bestimmten Suchbegriff meist zeitaufwa¨ndig, da der Nutzer wirklich Seite
fu¨r Seite nach dem Suchbegriff suchen muss. Wie oben erwa¨hnt erha¨lt der Event Cutter
ein Dokument bzw. Schritt fu¨r Schritt die zeilen eines Dokuments als Eingabe. Natu¨rlich
ist es sinnvoll dem Event Cutter nur die Dokumente zu u¨bergeben, die auch das Stichwort
enthalten. Dazu wird der LUCENE-Index verwendet, der dem Event Cutter n Dokumente
liefert, die auch das Stichwort enthalten. Danach wird der Event Cutter n-mal aufgerufen und
liefert genau n*i Schnipsel, wobei i die Anzahl der Schnipsel pro Dokument bezeichnet. Die
Weiterverarbeitung der Schnipsel la¨uft u¨ber die grafische Benutzeroberfla¨che.
Aufbau der Komponente
Der Event Cutter arbeitet wahlweise mit den pdf Dateien und den ascii Dateien der Dokumen-
te des Deutschen Bundestags. Zu Beginn werden die Dateien, welches das gesuchte Stichwort
enthalten, mithilfe des Lucene-Index gesucht. Die Lucene-Anfrage gibt sowohl die Anzahl, als
auch die Namen der relevanten ascii Dateien an, welche das gesuchte Stichwort enthalten. Mit
dem Finden der Dateien, werden diese nun iterativ nach dem gesuchten Stichwort zeilenweise
durchlaufen. Mit dem Vorkommen des Stichworts werden die ersten beiden und die letzten
beiden Zeilen abgetrennt, so dass das Stichwort genau zwischen vier Zeilen liegt und einen
Abschnitt bildet. Dieser Vorgang wird fu¨r jedes Wort, welches dem gefundenen Stichwort
entspricht, durchlaufen. Die gefundenen Abschnitte ko¨nnen in einzelne ascii Dateien in einem
separaten Ordner abgespeichert werden oder anderen Objekten als Strings u¨bergeben werden.
Resultat
Der Event Cutter gibt als Endprodukt nur die Zeilen der Text Dokumente aus, die das gesuch-
te Stichwort enthalten. Somit ermo¨glicht der Event Cutter eine Ku¨rzung von Text Dokumen-
297
ten in Abschnitte, die eine effiziente Suche nach dem Stichwort anbieten, ohne vollsta¨ndige
Dokumente durchzulesen.
298

6 Fragebeantwortung
6.1 Manuelle Fragebeantwortung
6.1.1 Einleitung
Die Webseite des Deutschen Bundestags bietet eine interne Suchmaschine an. Das Dokumen-
tations- und Informationssystem fu¨r parlamentarische Vorga¨nge, kurz DIP. Das DIP ist das
gemeinsame Informationssystem von Bundestag und Bundesrat. Wenn Nutzer der Bundes-
tagswebseite an speziellen Ereignissen oder geschichtlichen Daten Interesse haben, ko¨nnen sie
nach diversen Themen recherchieren.
Im DIP wird das parlamentarische Geschehen im Bundestag und Bundesrat dokumentiert
und in Drucksachen und stenografischen Berichten festgehalten. Es verfu¨gt u¨ber eine große
Auswahl an Dokumenten und bietet den Nutzern eine umfangreiche Volltextsuche. Die In-
formationen zu einem Thema stehen meist verstreut in verschiedenen Dokumenten. Jedoch
muss der Nutzer heutzutage nicht mehrere tausende Dokumente Seite fu¨r Seite durchlesen.
Man bekommt mithilfe des DIP’s alle relevanten Dokumente geliefert, die auf eine vom Nut-
zer eingegebene Suchanfrage zutreffen. Spezielle Fragen in Satzform kann der Nutzer dem
DIP nicht stellen. Es kann dafu¨r natu¨rlich keine Ergebnisse liefern, da die Suchanfrage in
Satzform fu¨r das System viel zu komplex ist. Eine Frage in Satzform besteht aus mehreren
Stichwo¨rtern, so dass sich die Suchkategorien u¨ber mehrere Suchbegriffe erstrecken. Das DIP
ist somit nicht in der Lage eine erfolgreiche Suche mit Treffern auszufu¨hren. Deswegen bietet
das DIP Hilfsoperationen, mit denen sich die Suchanfrage beschra¨nken la¨sst. Ermo¨glicht wird
dies durch ’u’ fu¨r die UND-Verknu¨pfung und ’o’ fu¨r eine ODER-Verku¨pfung von Stichworten.
Verla¨uft die Suchanfrage erfolgreich, wird eine Trefferliste mit allen relevanten Dokumenten
ausgegeben. Nun liegt es in der Hand des Benutzers alle Dokumente durchzugehen, das sei-
ner Meinung nach am relevantesten erscheinende Dokument anzuwa¨hlen und im Dokument
nachzulesen, ob er auf seine gestellte Suchanfrage eine Antwort erha¨lt.
6.1.2 Konkretes Beispiel
Als Beispiel fu¨r einen solchen Vorgang, versuchen wir auf die folgende Frage eine Antwort zu
finden:
”
Wie ist die Haltung des deutschen Parlaments gegenu¨ber dem EU-Beitritt der Tu¨rkei?“
Da diese Frage aus einem Satz mit mehreren Wo¨rtern besteht, ist es hier nicht mo¨glich, eine
konkrete Auswahl an Dokumenten, als Ausgabe geliefert zu bekommen. Um diese Frage er-
folgreich beantworten zu ko¨nnen, ist es somit sinnvoll, die Suchanfrage auf 2 Stichwo¨rter zu
beschra¨nken.
Im oben genannten Beispiel sind die Schlagwo¨rter der Frage
”
Tu¨rkei“ und
”
EU“. Der Nutzer
erha¨lt auf diese Suchanfrage eine Trefferliste mit relevanten Dokumenten. Auch hier muss der
300
Abbildung 6.1: Startseite des DIP
Abbildung 6.2: Sucheingabe im DIP
301
Abbildung 6.3: Titelu¨bersicht
Abbildung 6.4: U¨bersicht eines Dokuments
Nutzer nicht jedes angezeigte Dokument durchgehen. Positiv ist auch die Anzeige der rele-
vanten Dokumente. Man erha¨lt als Ru¨ckmeldung eine kurze Inhaltszusammenfassung. Dies
ermo¨glicht dem Leser gezielt unter den angezeigten relevanten Dokumenten zu suchen. Im
Beispiel mit der Tu¨rkei und der EU gibt es eine breite Palette an parlamentarischen Sitzun-
gen, die sich neben dem EU-Beitritt der Tu¨rkei auch mit der Jugendpolitik, Außenpolitik,
Agrarpolitik und Wirtschaft bescha¨ftigt haben. Ein Hinweis auf die Antwort der oben gestell-
ten Frage ko¨nnte das hervorgehobene Dokument in Abbildung 6.3 liefern.
Der Titel des Dokuments entha¨lt genau die Schlagwo¨rter, die auch in der Frage auftauchen.
Somit liegt es dem Nutzer nahe, dieses Dokument anzuwa¨hlen. Unter dem Menu¨ Langform
kann man sich das Dokument als Volltext im Pdf oder Ascii Format anzeigen lassen. Dies
geschieht durch einen Mausklick auf den makierten Bereich in Abbildung 6.4.
Nach dem O¨ffnen des Dokuments kann man nun, mit Hilfe der Pdf-Suche (siehe Abbildung
302
Abbildung 6.5: Stichwortsuche im Pdf Dokument
Abbildung 6.6: Ergebnis der Stichwortsuche im Pdf Dokument
6.5), nach dem Stichwort suchen. Mit der Eingabe des Stichwortes
”
Tu¨rkei“ liefert die Suche
dem Nutzer, die Passagen in dem das Stichwort auftaucht (siehe Abblidung 6.6). Nun liest
der Nutzer den gefundenen Abschnitt im Dokument, um seine Antwort auf die gestellte Frage
zu erhalten.
Dieses Dokument hat allerdings keine wirkliche Antwort auf die Frage, trotz des zutreffenden
Titels in der Trefferliste. Im Abschnitt treten zwar die Stichwo¨rter auf, jedoch muss der Leser
sich die Antwort selbst erarbeiten. Dabei muss man beim Lesen auch auf sprechende Personen
und Parteien achten.
Wichtig bei der Suche nach der Antwort auf die Frage ist auch die Art des Dokumentes, in
dem man sucht. In vielen Dokumenten wie Beschlussempfehlungen oder schriftlichen Fragen
mit Antwort, die als Drucksache vorliegen, ist die Haltung der einzelnen Parteien nicht so
deutlich wie in den Plenarprotokollen von stenografischen Berichten.
In diesen Berichten kommt jede Partei zu Wort und in vielen Dokumenten wurde u¨ber den
303
Abbildung 6.7: Triggerwo¨rter in Plenarprotokollen
EU-Beitritt der Tu¨rkei ausfu¨hrlich diskutiert. In den Plenarprotokollen treten die meisten
Triggerwo¨rter auf. Aufgrund von diversen Zurufen, wie Widerspru¨che, Beifall und Beschimp-
fungen, die mitten im Vortrag auftreten ko¨nnen, ist die Haltung der Parteien ersichtlich. Wie
dies ein Beispiel in Abbildung 6.7 verdeutlicht.
Selbstversta¨ndlich ist dieses genannte Beispiel nur fu¨r ein relevantes Dokument beschrieben
worden. Tatsa¨chlich erstreckt sich die Suche nach der Antwort auf die Frage, wie die Haltung
der deutschen Parteien gegenu¨ber dem EU-Beitritt der Tu¨rkei ist, u¨ber mehrere hundert Do-
kumente. Dafu¨r wurden 291 Dokumente gelesen und nach Triggerwo¨rtern untersucht, darunter
als Dokumententypen: Antra¨ge, Beschlussempfehlungen und Berichte, schriftliche Fragen mit
Antworten, Plenarprotokolle, kleine Anfragen mit Antwort.
6.2 Frage Eingabe
6.2.1 Freie Frageeingabe
Bei einer freien Frageeingabe des Benutzters, z.B. u¨ber ein Textfeld, mu¨ssen die Fragen analy-
siert werden. Unser erster Ansatz zielt darauf ab, die Fragewo¨rter als Trigger fu¨r den Fragetyp,
304
und damit fu¨r das Beantwortungsverfahren zu benutzen:
Frage Antwort Beispiel
wann am[Datum] wann war letzte Misstrauensvotum?
wieviele [Anzahl] wieviele Kinder hat...?
wieviel [Anzahl] wieviel Kinder hat der Abgeordnete?
wie [String] Wie ist die Reaktion...?/ Wie oft Zwischenrufe bei Rede von ...
was am[Datum],[String] Was hat Schro¨der im Bundestag am...gesagt?
wer am[Datum],[String] wer ist der Parteivorsitzender der ..?
welche [String] Welche Parteien sind im Bundestag?
welcher [String] Welcher Partei geho¨rt .. an?
werden [String] werden Antra¨ge von ..abgelehnt?
hat [Anzahl] hat der Abgeordnete .. Kinder?
wo [String] wo wird die BW zurzeit eingesetzt?
wieso [String] [Event Extraction] wieso ist Deutschland gegen Tu¨rkei Beitritt
warum [String] [Event Extraction] warum BDR gegen TR Beitritt
weshalb [String] [Event Extraction] weshalb...
Dieser Ansatz wurde allerdings verworfen, da es dem Nutzer zu viele Mo¨glichkeiten bei
der Fragestellung gab, wodurch die Analyse und Auswertung sehr komplex wird. Auch die
Mo¨glichkeit dem Benutzer vorgefertige Fragen zur Auswahl zu geben ist wenig sinnvoll, da
entweder nur sehr wenige Fragen zur Verfu¨gung stehen, fu¨r die man dann auch kein aufwendi-
ges System beno¨tigt, sondern die no¨tigen Antworten einmal bestimmt und dann abspeichert.
Oder man hat so viele verschiedene Fragen, dass der Benutzer so viel Zeit in das Suchen der
Richtigen Frage investieren muss, dass es fu¨r ihn a¨hnlich effizient wa¨re die Frage selbst manu-
ell zu beantworten. Es muss also ein Weg gefunden werden um dem benutzer sowohl genu¨gend
Freiraum zu lassen, als ihm auch eine strukturierte Form der Fragestellung vorzugeben.
BNF von Alex(ist noch auf seinem defekten Laptop)
6.2.2 Strukturierte Frageeingabe
Sinnvoll erscheint hier also der Mittelweg, dem Benutzer die Fragestellung in bestimmten
Grenzen frei zu u¨berlassen. Dazu ist es sinnvoll zuna¨chst zu erfassen welche Datentypen als
Datenbasis dienen und wie die einzelnen Teile dieser Daten zusammenha¨ngen. Solche Daten-
typen ko¨nnen zum Beispiel sein: Person, Protokoll, Drucksache, Partei. Im folgenden werden
diese als Entities bezeichnet. Um stukturierte Fragestellung zu erlauben mu¨ssen nun diese
Entities in Ihren Attributen vollsta¨ndig beschrieben werden, sowie die Relationen zwischen
den einzelnen Entities erfasst werden. Analog zu relationalen Datenbanken wird fu¨r eine Re-
lation zwischen zwei Entities immer ein Fremdschlu¨ssel beno¨tigt, also ein Attribut, bei dessen
Gleichheit in zwei Entity Instanzen angenommen werden kann, dass diese Instanzen miteinan-
der in Relation stehen. Ist dieses Schema einmal erfasst kann eine Oberfla¨che eine Semi-Freie
Frageerstellung unterstu¨tzen, indem sie nach Auswahl einer Zielentita¨t fu¨r die Frage, die aktu-
ell abfragbaren Attribute und die Relationen zu anderen Entita¨ten anzeigt. Wird ein Attribut
gewa¨hlt, kann man eine Bedingung an dieses Attribut stellen, die im folgenden Constraint
genannt wird. Wa¨hlt man wiederrum eine Relation aus, springt man zur Zielentita¨t dieser
305
Relation und kann von dort aus wieder wa¨hlen, ob man eine Bedingung an ein Attribut dieser
Entita¨t stellen mo¨chte, oder eine Relation dieser Entita¨t wa¨hlen. So ergibt sich eine Frage,
die aus relationalen Verknu¨pfungen mehrerer Entita¨ten besteht und gleichzeitig Bedingungen
an die Entita¨ten stellt.
Dieses Vorgehen erschien als praktikabel und passte gut zu der sehr heterogenen Daten-
landschaft, da es Funktionen a¨hnlich zur Anfragesprache SQL erlaubt, aber nicht an ein
Datenbank-System gebunden ist.
6.3 Warum Fragen
Vergleichsdatensatz muss vorhanden sein RapidMiner wird mit passendem Experiment gest-
artet Items des Ergebnissets werden positive Labels im Datensatz Entscheidungsbaum und
Regellerner Anzeige der Ergebnisse
6.3.1 Die Basis
Die Basis der Warum-Fragen besteht aus zwei Teilen. Zum einen aus einer vom Benutzer
u¨ber die QueryFacade eingegebene Frage, bzw deren Ergebnisset, und zum Anderen aus ei-
nem Vergelichsdatensatz, der wie im Kapitel Datensa¨tze beschrieben erstellt wurde.
6.3.2 Die Bedingung
Damit eine Warum-Frage bearbeitet werden kann, muss das Ergebisset der Frage aus einem
bestimmten Typ von Eintra¨gen bestehen, der einem der Vegleichsdatensa¨tze entspricht, da
sonst keine Berechnung mo¨glich ist. Diese Typen sind z.B. nur Personen der 16 WP oder nur
Antra¨ge, oder nur Drucksachen....
6.3.3 Der Ablauf
Der Benutzer giebt eine Frage ein und la¨sst sich das Ergebnisset anzeigen, wenn die Typen
der Ergebnissets mit einem der Datensa¨tze u¨bereinstimmt, wird der
”
Warum“-Button einge-
blendet, so das der Benutzer die Mo¨glichkeit bekommt die Berechnung zu starten.
Durch das dru¨cken des Buttons wird zuerst eine Daten geschrieben, in der die IDs der Ein-
tra¨ge des Ergebnissets gespeichert werden.
Als na¨chstes wird RapidMiner gestartet.
Die Experimente sehen wie folgt aus:
ˆ Der entsprechende Vergleichsdatensatz wird geladen
ˆ Es wird ein Bina¨res Label geneiert indem die IDs der Daten im Vergleichsdatensatz mit
denen in der zuvor gespeicherten Datei verglichen werden
ˆ Es wird der
”
DecisionTree“ Operator gestartet
306
ˆ Jetzt wird der
”
RuleLearner“ gestartet
Nach abschluss der Berechnung wird das Ergebnis in der aus RapidMiner bekannten Ober-
fla¨che, in einem neuen Fenster angezeigt.
6.3.4 Operatodetails
DecisionTree
Parameter Wert
criterion information gain
minimal leaf size 2
minimal gain 0.0
maximal depth 10
confidence 0.25
RuleLearner
Parameter Wert
criterion information gain
sample ration 0.9
pureness 0.9
minimal prune benefit 0.25
307

7 Evaluation
7.1 Bewertung auf Grundlage der Aufgabenstellung
In der Aufgabenstellung (Kapitel 1.1) sind einige Eckpunkte von ISIE aufgelistet. Anhand
dieser Punkte wollen wir nachfolgend den Erfolg der Projektarbeit betrachten. Zur Aufgabe
geho¨rte die Verwendung der Methoden des Information Retrieval sowie des Data Mining.
Informationen mussten gesammelt und extrahiert werden. Dabei wurden unterschiedlichste
Quellen verwendet wie Drucksachen-PDFs, die Bundestags-Website, Google und Wikipedia.
Da diese Daten so nicht genutzt werden konnten, entstanden als Ergebnis verschiedenste Da-
tenbanken, z.B. MOPS (Abgeordneten-Datenbank) oder ein Drucksachen-Index. Relevante
Daten wurden durch regula¨re Ausdru¨cke, XPath Anfragen auf XML-Dateien oder durch un-
sere QueryFacade-Komponente extrahiert.
Eine zentrale Aufgabe war die Strukturierung der Basisdaten zu einem personen-individuellen
Pressespiegel. Die Dossier-Komponente geht u¨ber diese Anforderungen hinaus und stellt ne-
ben den Redebeitra¨gen und Drucksachen zusa¨tzlich auch ein Foto und personen-bezogene
Informationen des Abgeordneten zur Verfu¨gung.
Ein weiteres Ziel war die Verbesserung der u¨blichen Stichwortsuche von Suchmaschinen, die
ganze Dokumente zuru¨ckliefern. ISIE bietet mit der EventCutter-Komponente die Mo¨glichkeit
die Dokumente auf die Umgebung der relevanten Stellen zu reduzieren. Eine noch genauere
Mo¨glichkeit Antworten zu erhalten, ist durch das Fragebeantwortungssytem in ISIE realisiert.
Eine strukturierte Fragestellung liefert nur Ergebnisse des gewu¨nschten Typs (QueryFacade-
Komponente). Eigentlich war hier eine freie Formulierung der Frage angedacht. Dies wurde
aber aus Komplexita¨tsgru¨nden auf die strukturierten Fragen mit natu¨rlich-sprachlicher Frage-
vorschau reduziert. Die in der Aufgabenstellung gestellte Frage liefert beispielsweise folgende
Ergebnisse:
Erika Steinbach (CDU/CSU)
Monika Bru¨ning (CDU/CSU)
Ba¨rbel Kofler (SPD)
Neben den Namen werden dabei auch die im Dossier vorhandenen personen-bezogenen In-
formationen angezeigt. Außerdem wird dem Benutzer die Mo¨glichkeit geboten, grundlegende
Aussagen u¨ber die Ergebnisse seiner Anfrage zu erhalten. Dies geschieht unter Zuhilfenahme
von RapidMiner, der einen passenden Entscheidungsbaum generiert.
In den Vorverarbeitungsschritten wurde die NER benutzt und verschiedene Tags wie
”
Per-
son“,
”
Partei“,
”
Amt“, etc. zuna¨chst manuell getaggt und spa¨ter automatisch per RapidMiner
annotiert. Dies war im spa¨teren Verlauf der PG hilfreich um Abstimmungen anhand der Tags
zu erkennen und somit unabha¨ngig von regula¨ren Ausdru¨cken zu sein.
309
Abbildung 7.1: Mo¨glichkeiten der Anzeige von Abgeordneten auf bundestag.de
7.2 Bewertung auf Grundlage der Website bundestag.de
Nachfolgend wird das System mit den bestehenden Funktionen auf der Bundestags-Website
www.bundestag.de verglichen. Hauptaugenmerk liegt dabei auf den zusa¨tzlichen Funktionen,
die das System bietet sowie Verbesserungen im Funktionsumfang.
7.2.1 Suche nach Textausschnitten
Die Bundestags-Website bietet u¨ber den Suchdienst DIP21 zwar eine Funktion nach Stichwo¨rtern
innerhalb von Drucksachen und Plenarprotokollen zu suchen, allerdings werden hier nur ganze
Dokumente zuru¨ckgeliefert. Die Anzeige der Fundstelle des Stichworts wird hier dem Benut-
zer verwehrt und muss wieder im Dokument gesucht werden. Man weiss also nur, dass es dort
vorkommt.
Unser System bietet im Unterpunkt
”
Stichwortsuche“ die Mo¨glichkeit ein Stichwort einzuge-
ben. Hier wird als Antwort eine Menge von Abschnitten eines Dokuments geliefert, in dem
das gesuchte Stichwort vorkommt. Damit bekommt der Benutzer direkt einen Eindruck u¨ber
das Thema und muss nicht mu¨hsam nach den Fundstellen suchen.
7.2.2 Informationen u¨ber Abgeordnete
Auf der Bundestags-Website ist es mo¨glich Abgeordnete nach Fraktionen, Wahlkreis oder
Bundesland anzeigen zu lassen. Diese Informationen werden statisch u¨ber eine Auswahl in
der linken Navigationsleiste angezeigt (siehe Abbildung 7.1). Hier gibt es die eben erwa¨hnten
Mo¨glichkeiten der Filterung von Abgeordneten nach Fraktion, Wahlkreis oder Bundesland.
Daneben ist auch eine Gesamtliste anwa¨hlbar.
In isie geht diese Suche nach Abgeordneten sehr viel weiter. Verschiedenste Filtermo¨glichkeiten
sind hier denkbar, beispielsweise nach Anzahl der Kinder, Religionszugeho¨rigkeit, Geschlecht
oder Geburtsort. Diese Funktion ist unter dem Punkt
”
Abgeordneten-Info“ realisiert. Ins-
gesamt 16 Filterkriterien stehen zur Auswahl, wobei jeweils u¨ber Vergleichsoperatoren <
310
Abbildung 7.2: Filterung von Abgeordneten mit isie
,==, ! =, ... und einer freien Auswahl der Schranke, die Abgeordneten ausgewa¨hlt werden.
Daru¨berhinaus sind beliebig viele Filterkombinationen denkbar. So gibt es nur einen Abge-
ordneten der genau 5 Kinder (Filterkriterium 1) hat und in Ko¨ln (Filterkriterium 2) wohnt
(Stand vom 06.08.08). Ein Bildschirmfoto dieser Funktion ist in Abbildung 7.2 zu sehen.
7.2.3 Abgeordneten-Dossier
Das Abgeordneten-Dossier 5.6 eine Funktion, die man so nicht auf der Bundestags-Website
findet. Hier gibt es zwar die Mo¨glichkeit weitergehende Informationen zu den Abgeordneten
anzuzeigen, allerdings sind diese Informationen statisch und bieten keine Angaben u¨ber Be-
teiligungen an Drucksachen oder Reden im Bundestag.
Genau das leistet das Abgeordneten-Dossier, dass im Menu¨punkt
”
Dossier“ zu finden ist.
Beim Aufruf dieser Funktion wird direkt eine alphabetisch sortierte Liste der Abgeordneten
angezeigt. Alternativ kann auch nach Abgeordneten gesucht werden. Klickt man auf einen
Namen, so o¨ffnet sich ein Fenster mit den allgmeinen Daten zur Person, sowie ein Foto des
Abgeordneten. Das Highlight in diesem Bereich sind die Angaben der Drucksachenbeteiligun-
gen sowie die einzelnen Reden, die im Bundestag gehalten wurden. Beide Funktionen sind
neu und so nicht auf der Website implementiert.
311
7.2.4 Fragebeantwortung
Isie bietet einen weiteren Mehrwert gegenu¨ber der Website des Bundestags. Der Bereich Fra-
gebeantwortung bietet die Mo¨glichkeit, unter Angabe einer Zielentita¨t, eine Frage zu kon-
struieren, deren natu¨rlichsprachliche Form in einem Vorschaufenster angezeigt wird. Hier ist
es also mo¨glich genau eine Antwort auf eine gestellte Frage zu bekommen. Voraussetzung
ist, dass man eine ungefa¨hre Vorstellung von der Antwort hat, denn dies ist no¨tig um die
Zielentita¨t, also ein Amt, eine Person, usw., zu bestimmen. Danach erscheinen eine Reihe von
Filtermo¨glichkeiten, die die gesuchte Antwort einschra¨nken. Der Clou ist dabei die Darstellung
der natu¨rlichsprachlichen Frage am unteren Rand des Fensters.
Zwar existiert auf der Bundestags-Website der
”
virtuelle Berater“ in Form eines Bundes-
tagsadlers, allerdings liefert dieser auf eine Frage nur vorgefertigte Sa¨tze und Satzbausteine.
Die Frage
”
Welche Abgeordneten sind in Wahlperiode 16 Mitglied der SPD?“ ergab hier fol-
gende Antwort durch den virtuellen Berater:
”
Alle Informationen zu den Abgeordneten des
deutschen Bundestages finden Sie hier: http://www.bundestag.de/mdb/index.html“. Somit
ist dieser Service kein echtes Fragebeantwortungssystem, sondern lediglich eine erweiterte
Stichwortsuche, da einzelne Stichwo¨rter offensichtlich zur Beantwortung genutzt werden.
7.2.5 PartyNator
Ein kleines Gimmick von isie ist der so genannte PartyNator 5.7. Diese Komponente bestimmt
die Parteizugeho¨rigkeit bzw. die Parteiaffinita¨t des Benutzers anhand von vorbestimmten At-
tributen, die ausgewa¨hlt werden ko¨nnen. Als Ergebnis wird eine dreidimensionale Tortengrafik
generiert, die unter bestimmten Parteiattributen die Parteizugeho¨rigkeit anzeigt. Ebenfalls ei-
ne Anwendung, die auf der Bundestags-Website nicht vorhanden ist.
7.3 Optimierungsvarianten
Um die Bearbeitungszeit der Fragebeantwortung zu verku¨rzen und die Datenhaltung zu zen-
tralisieren, wa¨re ein Vorschlag, eine relationale Datenbank anzulegen, in der alle Daten ent-
halten sind. In Abbildung 7.3 ist ein erster grober Entwurf der Datenbank. Um die Datenbank
nutzen zu ko¨nnen, mu¨ssten allerdings die kompletten Daten aus der bisherigen Datenhaltung
u¨bertragen werden. Dies ist mit etlichen Konvertierungsschritten verbunden. Allerdings ha¨tte
man danach eine einheitliche Datenhaltung, außerdem liefert eine SQL Datenbank auch die
Antworten die bisher von der QueryFacade erstellt werden. Es wa¨re auch mo¨glich die Da-
tenbank zentral auf einem Server laufen zu lassen und via Webdienst auf diese zuzugreifen,
dadurch wu¨rde der beno¨tigte Speicherplatz bei jedem User deutlich sinken. Updates der Da-
ten ko¨nnten dann auch einfacher von einem Servicetechniker zentral durchgefu¨hrt werden und
mu¨ssten nicht mehr von jedem User selbst dezentral gemacht werden.
Eine weitere Verbesserung wa¨re die Einbeziehung der a¨lteren Wahlperioden, dadurch ko¨nnte
man noch umfassendere Aussagen u¨ber Regelma¨ßigkeiten oder Vera¨nderungen u¨ber die Zeit
machen. Hierzu ist es allerdings notwendig, dass man die BILD-PDFs analysiert und zum
Beispiel mittels einer OCR-Software diese in ASCII Dokumente konvertiert, ohne wichtige
Strukturmerkmale zu verlieren.
312
Abbildung 7.3: SQL Datenbank
Außerdem wa¨re ein Ansatzpunkt fu¨r Verbesserungen, die Fragevorschau bzw. die Frageeinga-
be, bisher haben wir die Fragevorschau aus fertigen Bausteinen generiert. Zur Kontrolle ko¨nnte
man noch eine Grammatikpru¨fung einbauen, um die Korrektheit der Sa¨tze zu gewa¨hrleisten.
Noch besser wa¨re natu¨rlich eine freie Frageeingabe des Benutzers, hierzu mu¨sste allerdings
die Eingabe aufwendig analysiert werden, und in eine, vom Computer versta¨ndliche Sprache
gebracht werden, zum Beispiel SQL.
Da das gesamte System u¨ber 30GB Festplattenspeicher in Anspruch nimmt, wa¨re zu u¨berlegen,
ob man nicht einen Server fu¨r das System nutzt und dem User zum Beispiel u¨ber eine Brow-
seroberfla¨che Zugriff auf das System verschafft. Neben dem Vorteil, dass man das System auch
von jedem Internetzugangspunkt benutzen kann, hat man auch als Administrator nur ein Sys-
tem zu pflegen und kann hier fu¨r Updates und Aktualita¨t sorgen. Anstelle eines Webservices
ko¨nnte man das System auch als Server-Client System aufbauen, wodurch auch fast alle Vor-
teile gegeben wa¨ren.
313

Literaturverzeichnis
[AI99] Appelt, Douglas E. ; Israel, David J.: Introduction to Information Extraction
Technology, 1999
[al.04] al., M.Diligenti M.: A Unified Probabilistic Framework for Web Page Scoring
Systems. In: IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGI-
NEERING 16 (2004)
[al.07] al., Buntine et: ALVIS - Superpeer Semantic Search Engine - Project Overview.
(2007)
[AN06] A. Nazarenko, et.al.: Deliverable D5.4 Complete document processing proto-
type. (2006)
[AT00] Ann TAYLOR, Beatrice S. Mitchell MARCUS M. Mitchell MARCUS: The Penn
Treebank: An Overview. (2000)
[BM05] Bunescu, Razvan C. ; Mooney, Raymond J.: A Shortes Path Dependency
Kernel for Relation Extraction / Dept. of Computer Sciences University Texas at
Austin. 2005. – Forschungsbericht
[Boy] Boyle, Roger: Hidden-Markov-Model online Tutorium. HMM,
[BP98] Brin, Sergey ; Page, Lawrence: The Anatomy of a Large-Scale Hypertextual Web
Search Engine. In: Proceedings of the Seventh World Wide Web Conf. WWW7,
1998, S. 107–117
[BR04] B.Young, A. Meyers R.Reeves C.Macleod R.Szekely V. ; R.Grishman: The
NomBank Project: An Interim Report. In: Meyers, A. (Hrsg.): HLT-NAACL
2004 Workshop: Frontiers in Corpus Annotation. Boston, Massachusetts, USA :
Association for Computational Linguistics, May 2 - May 7 2004, S. 24–31
[Bra99] Brants, Thorsten: Cascaded Markov Models. Bergen, 1999, S. 118 – 125
[Bra00] Brants, Thorsten: TnT – A Statistical Part-of-Speech Tagger. Seattle, 2000, S.
224 –331
[Bri92] Brill, Eric: A simple rule-based part-ofspeech tagger. In: ANLP, 1992, S. 152–
155
[Bur98] Burges, Christopher J. C.: A Tutorial on Support Vector Machines for Pat-
tern Recognition. In: Data Min. Knowl. Discov. 2 (1998), Nr. 2, S. 121–167.
http://dx.doi.org/http://dx.doi.org/10.1023/A:1009715923555. – DOI
http://dx.doi.org/10.1023/A:1009715923555. – ISSN 1384–5810
315
[CB03] Cunningham, Hamish ; Bontcheva, Kalina: Named Entity Recognition Tuto-
rial, 2003
[Cha00] Charniak, Eugene: A maximum-entropy-inspired parser. In: Proceedings of the
first conference on North American chapter of the Association for Computational
Linguistics. San Francisco, CA, USA : Morgan Kaufmann Publishers Inc., 2000,
S. 132–139
[CM04] Carreras, Xavier ; Ma`rquez, Llu´ıs: Introduction to the CoNLL-2004 Shared
Task: Semantic Role Labeling. In: Proceedings of CoNLL: Conference on Natural
Language Learning, 2004
[CM05a] Carreras, Xavier ; Ma`rquez, Llu´ıs: Introduction to the CoNLL-2005 Shared
Task: Semantic Role Labeling. In: Proceedings of CoNLL: Conference on Natural
Language Learning, 2005
[CM05b] Carreras, Xavier ; Ma`rquez, Llu´ıs: Introduction to the CoNLL-2005 Shared
Task: Semantic Role Labeling. 2005
[Col99] Collins, Michael J.: Head-driven Statistical Models for Natural Language Par-
sing. Philadelphia, University of Pennsylvania, Diss., 1999
[CS03] Culotta, Aron ; Sorensen, Jeffrey: Dependency Tree Kernels for Relation
Extraction / University of Massachusetts and IBM T.J. Watson Research Center.
2003. – Forschungsbericht
[DA04] D.Weld, O.Etzioni M.Cafarella D.Downey S.Kok A.Popescu T.Shaked S. ;
A.Yates: Web-Scale Information Extraction in KnowItAll. (2004), S. 100–110
[DC03] David Cohn, Andrew M. Rich Caruana C. Rich Caruana: Semi-supervised Clus-
tering with User Feedback / Cornell University. 2003. – Forschungsbericht
[Ebe06] Eberhardt, Stefan: Semisupervised K-Means Clustering.
http://www.informatik.uni-ulm.de/ni/Lehre/SS06/SeminarNI/ausarbeitungen/Eberhardt.pdf,
2006
[EK03] Esther Ko¨nig, Holger V. Wolfgang Lezius L. Wolfgang Lezius: TIGERSearch
2.1 User’s Manual. IMS, University of Stuttgart, 2003
[EV06] Engels, Eva ; Vikner, Sten: Satzglieder, Kasus und semantische Rollen: eine
Einfu¨hrung. In: Tidsskrift for Sprogforskning 4 (2006), Nr. 1, S. 17 – 37
[Fel03] Feldman, Ronen: Information Extraction - Theory and Practice, 2003
[GH03] Gildea, Daniel ; Hockenmaier, Julia: Identifying semantic roles using combi-
natory categorial grammar. Sapporo, Japan, 2003
[GJ00] Gildea, Daniel ; Jurafsky, Daniel: Automatic labeling of semantic roles. In:
ACL ’00: Proceedings of the 38th Annual Meeting on Association for Computa-
tional Linguistics. Morristown, NJ, USA : Association for Computational Lin-
guistics, 2000, S. 512–520
316
[GJ02a] Gildea, Daniel ; Jurafsky, Daniel: Automatic labeling of semantic roles. In:
Comput. Linguist. 28 (2002), Nr. 3, S. 245–288
[GJ02b] Gildea, Daniel ; Jurafsky, Daniel: Automatic labeling of semantic roles.
(2002), S. 245?88
[Gri97] Grishman, Ralph: Information Extraction: Techniques and Challenges. In: SCIE,
1997, S. 10–27
[Hea99] Hearst, M.: Automatic acquisition of hyponyms from large text corpora. In: In
Proceedings of the 14th International Conference on Computational Lingustics,
1999, S. 539–545
[HTT] HTTP/1.0 specification. http://www.w3.org/Protocols/HTTP/1.0/spec.html,
[J.80] J., Buxton: STONEMAN-Requirements for Ada Programming Support Environ-
ments. 1980
[JA02] J.Lin, S.Dumas M.Banko E. ; A.Ng: Web question answering, Is more always
better? In: In Proceeedings of SIGIR 2002, 2002, S. 291–298
[JN06] Jiang, Zheng P. ; Ng, Hwee T.: Semantic Role Labeling of NomBank: A Maxi-
mum Entropy Approach, 2006
[Joa98] Joachims, T.: Making large-scale support vector machine learning prac-
tical. Version: 1998. citeseer.nj.nec.com/joachims98making.html. In:
B. Scho¨lkopf, A. S. C. Burges B. C. Burges (Hrsg.): Advances in Kernel Me-
thods: Support Vector Machines. MIT Press, Cambridge, MA, 1998
[Joa02] Joachims, T.: Optimizing Search Engines using Clickthrough Data. In: Procee-
dings of Knowledge Discovery in Databases, 2002
[Jos06] Jost, Michael: Document Clustering for Information Or-
ganization and Retrieval. http://wwwi2.informatik.uni-
wuerzburg.de/lehre/se0506/ausarbeitungen/jost.pdf., 2006
[Jun06] Jungermann, Felix: Named Entity Recognition mit Conditional Random Fields,
Computer Science, University of Dortmund, Diplomarbeit, 2006
[Kas08] Kasusgrammatik. http://de.wikipedia.org/wiki/Kasusgrammatik, 2008
[Kin02] Kingsbury, Marcus M. und Palmer M. P.: Adding Predicate Argument Structure
to the Penn TreeBank. San Diego, 2002
[KM00] Kudoh, Taku ; Matsumoto, Yuji: Use of support vector learning for chunk
identification. In: Proceedings of the 2nd workshop on Learning language in logic
and the 4th conference on Computational natural language learning. Morristown,
NJ, USA : Association for Computational Linguistics, 2000, S. 142–144
[Kri04] Krifka, Manfred: Argumentenstruktur und Verbsemantik. 2004
[Lez02] Lezius, Wolfgang: Ein Werkzeug zur Suche auf syntaktisch annotierten Textkor-
pora. (2002)
317
[LR89] Lawrence R., Rabiner: A Tutorial on Hidden Markov Models and Selected App-
lications in Speech Recognition, Institute of Electrical and Electronics Engineers,
1989, S. 257–286
[Luc] Lucene Query Parser Syntax. http://lucene.apache.org/java/docs/queryparsersyntax.html,
[Mey02] Meyer, Paul: Synchronic English Linguistics. An Introduction. Tu¨bingen : Narr,
2002
[Mit98] Mitkov, Ruslan: Comparing a statistical and a rule-based tagger for German.
(1998), S. 125–137
[Mit03] Mitkov, Ruslan: The Oxford Handbook of Computational Linguistics. (2003),
S. 545–560
[MRM+04] Meyers, A. ; Reeves, R. ; Macleod, Catherine ; Szekeley, Rachel ; Zielins-
ka, Veronkia ; Young, Brian: The Cross-Breeding of Dictionaries. In: Proceedings
of LREC-2004. Lisbon, Portugal, 2004
[PH01] Pasca, Marius ; Harabagiu, Sanda M.: Answer Mining from On-Line Docu-
ments / Department of Computer Science and Engineering Southern Methodist
University. 2001. – Forschungsbericht
[PHK+05] Pradhan, Sameer ; Hacioglu, Kadri ; Krugler, Valerie ; Ward, Wayne
; Martin, James H. ; Jurafsky, Daniel: Support Vector Learning for Se-
mantic Argument Classification. In: Mach. Learn. 60 (2005), Nr. 1-3, S. 11–
39. http://dx.doi.org/http://dx.doi.org/10.1007/s10994-005-0912-2. –
DOI http://dx.doi.org/10.1007/s10994–005–0912–2. – ISSN 0885–6125
[Pla99] Platt, John C.: Fast training of support vector machines using sequential mini-
mal optimization. (1999), S. 185–208. ISBN 0–262–19416–3
[Rat97] Ratnaparkhi, Adwait: A simple introduction to maximum entropy models for
natural language processing / Institute for Research in Cognitive Science, Uni-
versity of Pennsylvania. 1997. – Forschungsbericht
[Rij79] Rijsbergen, C. J. V.: Information Retrieval. 1979
[Sem08] Semantische Rolle. http://de.wikipedia.org/wiki/Semantische Rolle, 2008
[SG02] Strehl, Alexander ; Ghosh, Joydeep: Cluster Ensembles – A Knowledge Reuse
Framework for Combining Partitionings. In: Proceedings of AAAI 2002, Edmon-
ton, Canada, 2002
[Som04] Sommerville, Ian: Software Engineering 7th. Ed. Pearson Studium, 2004
[SS04] Swier, Robert S. ; Stevenson, Suzanne: Unsupervised semantic role labelling.
In: Proceedings of the 2004 conference on EMNLP, 2004, S. 95–102
[SS05] Swier, Robert S. ; Stevenson, Suzanne: Exploiting a verb lexicon in automatic
semantic role labelling. In: HLT ’05: Proceedings of the conference on Human
Language Technology and Empirical Methods in Natural Language Processing.
318
Morristown, NJ, USA : Association for Computational Linguistics, 2005, S. 883–
890
[THJA04] Tsochantaridis, Ioannis ; Hofmann, Thomas ; Joachims, Thorsten ; Altun,
Yasemin: Support vector machine learning for interdependent and structured out-
put spaces. In: ICML ’04: Proceedings of the twenty-first international conference
on Machine learning, 2004
[TJP04] Topchy, A. ; Jain, A ; Punch, W: A mixture model for clustering ensembles.
In: Proc. of SIAM Conference on Data Mining, 2004
[WLB05] Wray L. Buntine, Michael P. T. Kimmo Valtonen V. Kimmo Valtonen: The
ALVIS Document Model for a Semantic Search Engine. In: Demos and Posters
of the 2nd European Semantic Web Conference ESWC2005, 2005
[Yam] YamCha, Yet another multipurpose Chunk Annotator.
http://www.chasen.org/ taku/software/yamcha/,
[Zho06] Zhou, Zhixiong: Semi-supervised Hierarchical Clustering.
http://www.informatik.uni-ulm.de/ni/Lehre/SS06/SeminarNI/ausarbeitungen/Zhou.pdf,
2006
319