Automatisches Part-of-Speech Tagging - Institut für Maschinelle ...

Universität Stuttgart
Institut für Maschinelle Sprachverarbeitung
Azenbergstraße 12
D-70174 Stuttgart
Studienarbeit
Automatisches
Part-of-Speech Tagging
mit besonderer Berücksichtigung der Einsatzmöglichkeiten
in einem TTS-System fürs Polnische
Mateusz Wiącek
Matrikelnummer: 1993394
Betreuer: PD Dr. phil. Bernd Möbius
Betreuer: Prof. Krzysztof Marasek, Polish-Japanese Institute
of Information Technology
Prüfer: PD Dr. phil. Bernd Möbius
Studienarbeit Nummer: 40
Beginn der Arbeit: 01.06.2005
Ende der Arbeit: 31.10.2005

Hiermit erkläre ich, daß ich die vorliegende Arbeit selbständig verfasst habe und dabei
keine andere als die angegebene Literatur verwendet habe.
Alle Zitate und sinngemäßen Entlehnungen sind als solche unter genauer Angabe der
Quelle gekennzeichnet.
Mateusz Wiącek
Stuttgart, den 22. Oktober 2005

Inhaltsverzeichnis
1 Einführung 7
1.1 Computerlinguistik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Motivation, Ziele und Struktur der Arbeit . . . . . . . . . . . . . . . . . . . . 8
2 Sprachsynthesesysteme 9
2.1 Kann eine Sprache synthetisiert werden? . . . . . . . . . . . . . . . . . . . . . 9
2.2 Komponente eines TTS-Systemes . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Linguistische Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Akustisches Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Anwendungsgebiete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Übersicht der kommerziellen Systeme fürs Polnische . . . . . . . . . . . . . . 18
2.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Korpuserschließung und maschinelle Vorverarbeitung 21
3.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Was ist ein Korpus? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Aufbau der Korpora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.1 British National Corpus . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.2 IPI PAN Korpus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Automatische Verarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.1 C++ und Textverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.2 Korpora fürs Deutsche . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.3 Korpora fürs Polnische . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5 Tagsets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5.1 Was ist ein Tagset? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5.2 Bestimmung der Tagsets . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4 Part-of-Speech Tagging 42
4.1 Was bedeutet Tagging? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Taggingansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.1 Supervised vs. Unsupervised . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.2 Regelbasiertes Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.3 Stochastisches Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Der Tree Tagger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.1 Arbeitsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.2 Training und Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.3 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3

4.4 Transformation-Based Error-Driven Tagger von Eric Brill . . . . . . . . . . . 50
4.4.1 Initial Tagger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4.2 Final State Tagger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4.3 Verbesserungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.4 Training und Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.5 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.5 Vergleich der beiden Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5 Anbindung des Regelbasierten-Taggers an TTS-System 58
5.1 Festival . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.1.1 Modularisierung von Festival . . . . . . . . . . . . . . . . . . . . . . . 59
5.1.2 Part-of-Speech-Tagging in Festival . . . . . . . . . . . . . . . . . . . . 60
5.2 Anpassung des Algorithmus von Eric Brill an Festival . . . . . . . . . . . . . 61
5.2.1 Originalquellcode und Struktur des Algorithmus . . . . . . . . . . . . 61
5.2.2 Änderungen des Algorithmus . . . . . . . . . . . . . . . . . . . . . . . 62
5.3 Anbindung an Festival . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3.1 Neues POS-Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3.2 Anbindungsstelle, Ablauf und Funktionsweise . . . . . . . . . . . . . . 65
6 Zusammenfassung und Kommentar 67
6.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.2 Zukunft der Sprachsynthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
A Tagsets 71
A.1 Modifiezierte S-Tagset mit IPI PAN Zuordnung . . . . . . . . . . . . . . . . . 71
B Relationstrukturen und Festival 73
B.1 Interne Festivalsatzstruktur im Fringe-Format . . . . . . . . . . . . . . . . . . 73
B.2 Interne hierarchnisch aufgebaute Festivalsatzstruktur, die entsprechend der
Module des Äusserungstypen TEXT erzeugt wurde . . . . . . . . . . . . . . . 74
B.3 Beispielsitzung und Tagging im Festival . . . . . . . . . . . . . . . . . . . . . 75
4

Abbildungsverzeichnis
2.1 Module eines TTS-Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Beispiel einer internen Festivalstruktur, erstellt mit dem Visualisierungstool
Fringe für den englischen Satz: „Most precincts had a third of the votes counted";
Quelle: http://www.cogsci.ed.ac.uk/~amyi/mate/fringe.html . . . 16
3.1 Anzahl der verschiedenen Wortformen im deutschen Texten . . . . . . . . . . 28
3.2 Grösse des deutschen Lexikons . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Die häufigsten Wortarten in deutschen Texten . . . . . . . . . . . . . . . . . . 29
3.4 Die Grösse des polnischen Lexikons . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Neue Wortformen im polnischen Lexikon . . . . . . . . . . . . . . . . . . . . . 31
3.6 Die häufigsten Wortarten im IPI PAN Korpus . . . . . . . . . . . . . . . . . . 32
3.7 Verschiedene Wortarten in polnischen Texten . . . . . . . . . . . . . . . . . . 34
3.8 Neue Wortformen in polnischen Texten I . . . . . . . . . . . . . . . . . . . . . 35
3.9 Neue Wortformen in polnischen Texten II . . . . . . . . . . . . . . . . . . . . 35
4.1 Taggingansätze nach [Linda Van Guilder 1995] . . . . . . . . . . . . . . . . . 43
4.2 Möglicher Ablauf eines regelbasierten Taggers . . . . . . . . . . . . . . . . . . 45
4.3 Möglicher Ablauf eines stochastischen Taggers . . . . . . . . . . . . . . . . . . 46
4.4 Entscheidungsbaum des Tree Taggers [Schmid, 94] . . . . . . . . . . . . . . . 48
4.5 Präfixbaum des Tree Taggers [Schmid, 94] . . . . . . . . . . . . . . . . . . . . 49
4.6 Ablauf des Brill Taggers [Brill, 92] . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1 Prozess der Anbindung von dem Brill Tagger an Festival . . . . . . . . . . . . 66
5

Tabellenverzeichnis
2.1 Kommerzielle Sprachsynthesesysteme des Polnischen, Quelle: Internetseiten
der Produzenten bzw. Anbieter . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1 Größe des British National Korpus . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 PJWSTK-Tagset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4 Änderungen bei der Unifikation von zwei Varianten des STTS-Tagsets . . . . 41
4.1 Präzision des Tree Taggers für das Deutsche . . . . . . . . . . . . . . . . . . . 50
4.2 Präzision des Tree Taggers für das Polnische . . . . . . . . . . . . . . . . . . . 50
4.3 Die häufigsten Verwechslungen des Tree Taggers fürs Deutsche . . . . . . . . 50
4.4 Die häufigsten Verwechslungen des Tree Taggers fürs Polnische . . . . . . . . 51
4.5 Die häufigsten Verwechslungen des Brill Taggers fürs Polnische . . . . . . . . 55
4.6 Die häufigsten Verwechslungen des Brill Taggers fürs Deutsche . . . . . . . . 56
4.7 Vergleich des Brill Taggers und des Tree Taggers . . . . . . . . . . . . . . . . 57
5.1 Änderungen im Brill-Tagger Algorithmus . . . . . . . . . . . . . . . . . . . . 63
A.1 Unifikation von PJWST-Tagset und IPI PAN Tagset . . . . . . . . . . . . . . 72
6

Kapitel 1
Einführung
1.1 Computerlinguistik
Computerlinguistik, ist ein Kompositum, also ein Wort, das aus mehreren eigenständig
gültigen Teilwörtern besteht. In diesem Fall sind es die zwei Teilwörter Computer und Linguistik.
Nach der allgemeinen Regel für das Deutsche, sollte die Bedeutung von Komposita in
der umgekehrten Reihenfolge abgelesen werden. Computerlinguistik ist also eine Linguistik,
die zur Analyse der natürlichen Sprache einen Computer verwendet.
Die Schwierigkeit bei der Definition des Begriffes besteht darin, dass die zwei Teilwörter
zu zwei verschiedenen Bereichen der Wissenschaft gehören, Bereichen, die sich auf den
ersten Blick sogar gegenseitig ausschließen. Computer kommt von der Informatik, einer
exakten Wissenschaft; Linguistik wiederum gehört zu der Gruppe der humanistischen
Wissenschaften. Und tatsächlich liegt Computerlinguistik an der Grenze dieser beiden Wissenschaften
- sie versucht nämlich die natürliche Sprache mit Hilfe von mathematischen
Werkzeugen zu formalisieren.
Die praktische Aufgabe der Computerlinguistik besteht darin, Computerprogramme zu
entwickeln, die bestimmte, an Sprache geknüpfte Leistungen erbringen. Dazu gehören zum
Beispiel:
• Die Unterstützung von Autoren beim Verfassen von Texten, z.B. beim Finden des
treffenden Ausdrucks oder der richtigen Terminologie.
• Die Unterstützung beim Übersetzen von Texten in eine andere Sprache oder die vollständig
automatische Übersetzung.
• Die Umsetzung von gesprochener Sprache in geschriebene und von geschriebener Sprache
in gesprochene, z.B. bei telefonischen Auskunftsdiensten oder Lesegeräten für Blinde
(Spracherkennung und Sprachsynthese).
Eine Wissenschaft lässt sich aber auch durch ihr theoretisches Interesse definieren. Bei
Computerlinguistik werden bei den Untersuchungen Computer verwendet, Automaten, die
Symbole (Kombinationen von Nullen und Einsen) nach bestimmten Regeln manipulieren
können. Natürliche Sprachen, genauso wie Zahlen, sind Symbolsysteme - sehr komplexe
und vielschichtige Symbolsysteme. Computerlinguistik versucht Computerprogramme
zu entwerfen, welche die Operationen, die der Mensch mit den Wörtern einer Sprache
durchführt, zumindest teilweise, simulieren. Die Computerlinguistik ist in diesem Sinne eine
Linguistik, welche die Computersimulation als methodisches Mittel einsetzt, um unser
7

Wissen über menschliche Sprachen zu vertiefen.(Quelle: http://de.wikipedia.org/wiki/
Computerlinguistik)
1.2 Motivation, Ziele und Struktur der Arbeit
Um die Vielseitigkeit der Computerlinguistik zu demonstrieren, habe ich mich entschieden
eine Arbeit zu verfassen, die über möglichst viele Gebiete der Computerlinguistik geht.
Sie sollte sich sowohl mit rechnerisch-praktischen, als auch mit theoretischen Problemen
befassen - es ist nämlich der fundamentale Gegenstand der Computerlinguistik diese zwei
Fertigkeiten zu verbinden. Einerseits sind Gebiete wie Syntax, Morphologie oder Phonetik
für die Computerlinguistik wichtig, andererseits werden jedoch deren Ziele mit Hilfe von
Computern erreicht, die die „mathematische“ Analyse und Beschreibung erlauben.
Diese Arbeit wird sowohl theoretische als auch praktische Techniken behandeln. Sie wird
einerseits Elemente der Fachgebiete der Computerlinguistik diskutieren wie Morphologie,
Syntax und Statistik; andererseits aber die Anwendungsgebiete und verwendeten Techniken
wie Sprachsynthese, Generierung und Verarbeitung von Korpora und Extraktion von Daten,
Generierung von Regeln sowie zahlreiche Programmiertechniken, die den Techniken zu Hilfe
kommen.
Um den Begriff Computerlinguistik besser verstehen zu können, werde ich zusätzlich in
Kapitel 2 die möglichen kommerziellen Anwendungen dieses Fachgebietes, sowie einige, auf
dem Markt vorhandene Produkte (die endgültigen Ergebnisse der Arbeit von professionellen
Computerlinguisten) präsentieren. Um das Bild vollständig zu machen wird auch in Kapitel
2 und in Kapitel 5 auch kurz die Funktionsweise und der Aufbau des Programms Festival
beschrieben. Festival 1 wurde an der Universität Edinburgh entwickelt und ist ein allgemeines
Grundgerüst zum Programmieren von Spracherzeugungssystemen (automatische
Umsetzung von geschriebener Sprache in gesprochene Sprache). Das Programm ist in seiner
Funktionalität und Funktionsweise den meisten kommerziellen Sprachsyntheseprogrammen
sehr ähnlich - liefert auch bei entsprechendem Aufwand (Programmierung und Vorbereitung)
vergleichbare oder sogar bessere Resultate. Festival steht für wissenschaftliche Zwecke
und Forschungszwecke frei zur Verfügung.
Im Laufe der Arbeit werden Gebiete besprochen und Techniken vorgestellt, die zu einem
gemeinsamen Ziel führen. In Kapitel 2 wird sehr allgemein Sprachsynthese besprochen, wobei
ich mich grundsätzlich auf die Modularisierung, die Funktionsweise und die kommerziellen
Anwendungen konzentriere. Hier wird zum ersten Mal ein Mechanismus der automatischen
Zuweisung von Wortklassen (allgemein ein POS-Tagger genannt) vorgestellt. Ab hier beginnt
der Prozess der Einbindung eines regelbasierten Taggers an Festival. Der Tagger sollte
das Polnische verarbeiten können. Für diesen Zweck werden in Kapitel 3 benötigte Textmaterialien
vorbereitet, die dann in Kapitel 4 zum Training des Taggers verwendet werden. Es
werden dann zwei verschiedene Ansätze des Taggens detaiiliert besprochen und vergliechen.
Die eigentliche Anbindung an Festival erfolgt dann in Kapitel 5, wo auch das Modul des
Taggens, das Festival intern verwendet, ausführlicher besprochen wird. Als Ergebnis dieser
Arbeit liegt ein, auf polnischen Texten trainiertes Taggingmodul vor, das direkt in Festival
für jede polnische Stimme (aber auch für andere Sprachen) verwendet werden kann.
1 siehe auch http://www.cstr.ed.ac.uk/projects/festival
8

Kapitel 2
Sprachsynthesesysteme
Das Ziel dieses Kapitels ist es zu demonstrieren wie komplex ein Sprachsynthesesystem sein
kann. Es werden hier die modulare Arbeitsweise, sowie Anwendungen, Probleme bei der
Konstruktion und Einsatzgebite eines TTS-Systems vorgestellt. All das sollte dem Leser
verdeutlichen, dass jedes verwendete Modul eines TTS-Systems eine sehr spezifische Arbeit
leistet und im ganzen System nicht vernachlässigt werden kann. Jedes Modul trägt zur
endgültigen Qualität der generierten Stimme bei. In Kapitel 4 wird tiefer in eins der Module,
POS-Tagger, eingegangen. Wir werden sehen, dass der POS-Tagger, der schon für sich ein
sehr komplexes und aufwendiges Problem ist, im gesamten System nur eine sehr kleinere
Rolle spielt. Dieses Kapitel zeigt welche Rolle das ist, und inwieweit ein POS-Tagger für die
restlichen Module von Bedeutung ist.
2.1 Kann eine Sprache synthetisiert werden?
Eine Sprache ist ein System von Zeichen und gegebenen phonologischen, syntaktischen und
semantischen Regeln, die über die Kombination dieser Zeichen entscheiden. Die Sprache
definiert sich nicht nur durch Sprechen, sondern auch durch die Schrift. Die Sprache kann die
Informationen auf eine besondere Weise übermitteln- durch seine akustische Repräsentation,
die als Folge der Laute mit spezifischer Charakteristik kodiert ist. Dieser Code ist für jede
Sprache spezifisch.
Sprachsynthese selbst ist ein abstrakter Begriff für ein System (ein Programm, eine Anwendung),
das imstande ist, eingegebene Sätze, in Form einer Folge von Zeichen, völlig
automatisch in ein Sprachsignal so umzuwandeln, das es einer menschlichen Sprache entspricht
und als menschliche Sprache identifiziert wird. Deswegen heißen solche Systeme auch
TTS-Systeme (eng. Text-to-Speech; de. Text-zu-Sprache). Ein TTS-System kann ganz einfach
(aber trotzdem ganz korrekt) als „Vorlesesystem“ oder „Vorlesemaschine“ bezeichnet
werden. Ein TTS-System versucht eine der komplexesten kognitiven Fähigkeiten der Menschen,
die Fähigkeit zu sprechen, zu modellieren. Die undirekte Aufgabe der Sprachsynthese
ist es also, mit Hilfe von Computerprogrammen das menschliche Verhalten, das durch das
menschliche Gehirn kontrolliert wird, zu simulieren. Systeme, die das menschliche Verhalten
simulieren und wie Menschen handeln werden Künstliche Intelligenz (KI) Systeme genannt.
Ein TTS-System ist also nichts anderes als ein KI System, das einen menschlichen Leser
nachbilden kann und zwar ohne sein Weltwissen, ohne sein Sprachverständnis und ohne
sein Sprechorgane; dabei sollte es aber optimale Verständlichkeit und Natürlichkeit erzielen
(Möbius, Folien zum Hauptseminar „Sprachsynthese I“, Universität Stuttgart).
9

Um Vorgänge im Gehirn zu erklären, wird häufig und gerne auf die Funktion des Computers
zurückgegriffen. Obwohl alle Vergleiche zwischen Gehirn und Computer irgendwann
fehlschlagen, versuchen viele Autoren solch einen Vergleich zu wagen.
[Brodbeck, 1997] vergleicht den Rechner und das menschliche Gehirn. Er behauptet, das
Gehirn ist - verglichen mit einem Digitalcomputer - sehr langsam. Die CPU eines Prozessors
mit 100 MHz leistet 100 Millionen Rechenoperationen in der Sekunde; Nervenzellen sind um
den Faktor 10.000 langsamer [Spitzer, 1996]. [Brodbeck, 1997] definiert auch die wichtigsten
Unterschiede zwischen dem Rechner und dem Gehirn.
„Das Gehirn arbeitet parallel, ein Digitalcomputer seriell. Selbst sehr schnelle
Computer haben große Probleme bei der Mustererkennung oder der Bildverarbeitung.
Ein Gehirn kann ein Gesicht aus einer großen Menschenmenge dagegen
sehr rasch erkennen. Der Grund liegt in der gleichzeitigen Verarbeitung der visuellen
Information. Ein auf der Retina des Auges aufgebautes Bild wird auf
viele Neuronen gleichzeitig abgebildet. Es aktiviert ein ganzes Netz von Neuronen.
Und das verfügbare Potential zur Bildung solcher Vernetzungen ist unüberschaubar
groß.“
„Ein weiterer Unterschied zwischen Gehirn und Computer sollte erwähnt werden.
Bei einem Prozeß im Gehirn werden nicht einfach Informationen abgespeichert.
Es gibt keine Trennung von CPU und Speicher. Vielmehr verändert jede
Wahrnehmung, jeder Gedanke die Gewichte in den Verbindungen zwischen den
Neuronen (Synapsen). Ganz anders als bei einer Turing-Maschine ist also die
Software nicht von der Hardware zu trennen. Es gibt inzwischen Bauelemente,
die diese Eigenschaft des Gehirns teilweise simulieren können.“
Auf die Frage, worin der Unterschied zwischen einem menschlichen Gehirn und einem
Computer liegt, hat Prof. Dr. Wolf Singer von Max-Planck-Institut für Hirnforschung in
einem Interview 1 folgende Antwort gegeben:
Das grundlegend andere Prinzip von Gehirnen ist, daß diese als selbstaktive,
hochdynamische Systeme angelegt sind. In ihrer Organisation, die wiederum genetisch
vorgegeben ist, liegt ungeheuer viel Wissen über die Welt gespeichert. Das
Program, nach welchem Gehirne arbeiten, ist durch die Verschaltung der Nervenzellen
vorgegeben. Diese Verschaltungen haben sich in einem Jahr-Millionen
währenden, evolutionären Prozeß entwickelt, sind optimiert bzw. durch Versuch
und Irrtum umgestaltet worden. Dabei ist ein System entstanden, das nicht nur
vom Aufbau, sondern auch von den Verarbeitungsprinzipien her grundsätzlich
anders organisiert ist als ein Computer. Neuronale Systeme speichern zum Beispiel
nicht wie Computer Inhalte in adressierbaren Registern ab. Sie bedienen
sich sogenannter Assoziativspeicher, von denen Inhalte nach Ähnlichkeitskriterien
abrufbar sind, auch wenn sie mit sehr unvollständigen Informationen gefüttert
werden. Aber selbst wenn man den vollständigen Schaltplan dieser assoziativen
Speicher besäße, könnte man vermutlich noch nicht einmal einfache Gehirne
nachbauen, da deren Leistungen auf dynamischen Verarbeitungsprozessen beruhen,
die extrem nicht-linear und deshalb schwer zu stabilisieren sind. Solche
Systeme haben die unangenehme Neigung, entweder in überkritische Bereiche
zu gelangen, dann werden sie epileptisch, oder abzustürzen und zu schweigen.
Sie im richtigen Arbeitsbereich zu halten, ist unendlich schwierig, da sich ihre
1 „Zu wissen, wie eine streunende Katze in Frankfurt überlebt. Ein Gespräch mit Wolf Singer“, Quelle:
www.palais-jalta.de/texte/Interview_Singer.rtf
10

Dynamik analytisch nicht beherrschen läßt. Allenfalls könnten die Technologien
den Weg beschreiten, den die Natur beschreitet, d.h. sie könnten ein System sich
selbst entwickeln lassen.
Wenn also Sprechen eine der komplexesten kognitiven Fähigkeiten des Menschen ist, und
Computer und Gehirn so unterschiedlich arbeiten, dann scheint doch die Sprachsynthese
eine unmögliche Aufgabe zu sein? In diesem Kapitel wird gezeigt, dass man ein Sprachsynthesesystem
ohne direkte Simulation des menschlichen Gehirns konstruieren kann. Man
bedient sich hier verschiedener Werkzeuge, die Schritt für Schritt die (geschriebene) Sprache
analysieren. Im Laufe der Analyse „lernt“der Computer die wichtigsten Gegebenheiten des
Textes und generiert auf deren Basis ein akkustisches Signal, das im optimalen Fall einer
menschlichen Stimme und natürlichen Sprache entsprechen sollte.
2.2 Komponente eines TTS-Systemes
Die Funktionsweise der Sprachsynthese kann allgemein in zwei Phasen geteilt werden. In
der ersten Phase wird der eingegebene Text in eine Struktur umgewandelt. Diese Struktur
besteht aus Informationen über die Charakteristik der Textstruktur (Syntax, Semantik,
usw.), wie z.B. die phonetische Transkription. In der zweiten Phase erfolgt die akustische
Synthese des Sprachsignals - die Lautsequenzen werden generiert. Es werden dabei auch
die Lautdauer, Intonation und Intensität bestimmt. Die Qualität der Synthese hängt von
beiden Phasen ab. In der Wirklichkeit besteht aber ein TTS-System aus mehreren Teilen -
beide Phasen bestehen aus vielen kleinen Modulen (Abbildung 2.1, Seite 12), die immer eine
ganz spezifische Aufgabe zu erfüllen haben. Der Ablauf erfolgt seriell, das heißt die Ausgabe
eines Moduls funktioniert als die Eingabe für das nächste Modul. In einer größeren Skala ist
auch die Ausgabe des linguistischen Moduls gleichzeitig auch die Eingabe für das akustische
Modul. Wichtig zu erwähnen ist es, dass es keine autoritative Aufteilung ist, da nicht in
jedem Sprachsynthesesystem alle Module verwendet werden. Auch die Reihenfolge ist nicht
für jedes System gleich - die post-lexikalischen Regeln werden zum Beispiel bei manchen
Systemen erst nach der Berechnung der Intonation angewendet; die morphologische Analyse
erfolgt sehr oft parallel zum Part-of-Speech Tagging. Fraglich ist auch ob die Modellierung
der prosodischen Merkmalen zum linguistischen oder akkustischen Modul gehören sollte? Die
Abbildung 2.1 kann als eine ziemlich generelle Übersicht der verwendeten Module verstanden
werden.
2.2.1 Linguistische Analyse
Die Aufgabe dieses Moduls besteht darin, den vom Benutzer eingegebenen Text in eine
phonetische Transkription von einzelnen Lauten umzuwandeln. Der Text wird auch mit linguistischen
(und zum Teil auch para-linguistischen) Merkmalen annotiert wie: Wortklassen,
Satzgrenzen oder Pausen.
Tokenizierung
Hier wird der Text zum ersten Mal geparst. Der eingegebene String wirdinWörterund
Sätze geteilt. Interpunktionszeichen werden so entfernt, dass die Abkürzungen unverändert
bleiben. Sätze werden in Tokens zerlegt - Elemente die Wörtern entsprechen.
11

Abbildung 2.1: Module eines TTS-Systems
12

Token Klassifizierung
Jedem Token wird ein Tag zugewiesen, der seine Charakteristik beschreibt und später
über dessen Aussprache entscheidet. Es ist insbesondere bei Ziffern sehr hilfreich, da z.B.
Kardinal- und Ordinalzahlen sehr unterschiedlich ausgesprochen werden. In diesem Modul
wird unter anderem versucht zwischen folgenden Tokentypen für Ziffern zu unterscheiden:
Uhrzeit, Jahr, Datum, Geldbetrag, Ordinalzahl, Kardinalzahl, Teilungszahl, Dezimalbruch,
Masseinheit, Verhältnisse, Telefonnummer, Brüche, arithmetische Ausdrücke, römische Ziffern,
e-Mail- und Internetadressen.
Jeder Token wird dann seinem Typ entsprechend richtig ausbuchstabiert, z.B.:
„Am 12.03.1978“ wird in „am zwölften März neunzehnhundertachtundsiebzig“ umgewandelt
oder „anna@stuttgart.de“ in „Anna at Stuttgart Punkt DE“.
POS Tagging
Jedem Token wird eine grammatische Kategorie zugewiesen. Diese grammatische Analyse
kann sich auf die Wortklassen konzentrieren (Substantiv, Adjektiv usw.) oder auch die
syntaktischen Funktionen im Satz bestimmen (Subjekt, Objekt). Dieses erfolgt entweder
automatisch (mit Hilfe von Taggern) oder durch Verschlagwortung im Lexikon.
Diesem Modul widmet sich die vorliegende Arbeit und POS-Tagging wird soeben ausführlich
im Laufe dieser Arbeit behandelt. Im Kapitel 3 wird das Textmaterial für die
automatischen Tagger vorbereitet; im Kapitel 4 werden verschiedene Ansätze des automatischen
Taggens diskutiert, sowie zwei verschiedene Tagger werden mit dem Textmaterial
aus dem Kapitel 3 trainiert. Im Kapitel 5 wird dann ein regel-basierter Tagger an Festival
angebunden.
Morphologische Analyse
Hier werden Merkmale wie Person, Numerus, Tempus oder Modus bestimmt. Die Informationen
liefert entweder ein morphologischer Analysator/ Generator 2 oder es wird im
Lexikon nachgeschlagen. Um Fremdwörter zu analysieren, die nach anderen Regeln analysiert
werden, benötigt man in beiden Fällen trotzdem ein separates Lexikon.
Phonetische Transkription
Der Text wird hier in eine Reihenfolge von Phonemen zerlegt (phonetische bzw. phonologische
Transkription). Die Information wird in manchen Systemen direkt aus einem Vollformlexikon
ausgelesen. Die folgenden Beispiele demonstrieren die Einträge aus dem Celex-Lexikon
(Festival Format):
("Prozeß" NOM (((p R o) 0) ((ts E s) 1)))
("Lehr" NOM (((l e: R) 1)))
("Keks" NOM (((k e: k s) 1)))
Das erste Element ist die Wortform, das zweite das POS-Tag, dann erfolgt die phonetische
Transkription nach SAMPA 3 wobei noch zusätzlich die Silben eingeklammert sind, und
deren Betonung markiert ist (1 - akzentuiert).
2 wie etwa DEKO f“urs Deutsche, siehe http://www.ims.uni-stuttgart.de/projekte/DeKo/
3 SAMPA (Abk. für Speech Assessment Methods Phonetic Alphabet) ist die Kurzbezeichnung für ein
computerlesbares phonetisches Alphabet.
13

Die Transkription kann für manche Sprachen (z.B. das Polnische 4 ) automatisch erfolgen.
Es werden Konversionsregeln verwendet, die automatisch oder manuell erstellt werden
(letter-to-sound rules).
Pausensetzung
Hier werden die Pausen markiert und gesetzt. Die Sätze sollten nicht monoton und gleichmäßig
ausgesprochen werden. Die Pausen werden in der natürlichen Sprache nach dem Atemrhythmus
und der Interpunktion gesetzt. Sie haben auch verschiedene Längen - eine längere
Pause signalisiert z.B. das Ende des Satzes; die Pausen zwischen untergeordneten Sätzen
sind ein bisschen kürzer. In TTS-Systemen erfolgt die Pausensetzung meistens automatisch,
auf Basis der Beobachtung eines großen Korpus, das prosodisch annotiert ist.
Postlexikalische Regeln
Dieses Modul sollte die endgültigen Korrekturen des zur Synthese vorbereiteten Materials
durchführen. Die Notwendigkeit des Einsatzes entspringt jedoch nicht der Unsorgfältigkeit
oder Nachlässigkeit in der linguistischen Analyse, sondern der Kontextualität vieler Regeln.
So kann die phonetische Transkription einzelner Wörter korrekt sein (siehe Punkt phonetische
Transkription), aber ein stimmhafter Konsonant am Ende des Wortes wird nur dann
stimmhaft ausgesprochen, wenn das direkt folgende Wort mit einem stimmhaften Laut anfängt:
Erwerb [E R v E R b] des Scheines vs. Erwerb [E R v E R p] von Scheinen.
Für das deutsche können hier z.B. folgende Regeln angewendet werden:
1. Bestimmung von Glottal stops und deren Länge. Z.B. Einfügung von Glottal Stop vor
einem Wort, das mit einem Vokal anfängt.
2. Verbindung von Affrikaten : [p] + [f] => [pf]
3. Abbildung von [R] auf „schwa“ am Ende der Silbe.
2.2.2 Akustisches Modul
Akzent
Hier wird es entschieden, ob ein gegebenes Wort einen Akzent tragen sollte oder nicht.
Akzent wird definiert, als wahrgenommene akustische Prominenz, also das Hervorragen einer
Einheit gegenüber benachbarten. Wir unterscheiden mehrere Typen von Akzenten z.B.:
• Der Satzakzent ist die akustische Hervorhebung eines Teils eines Satzes.
• Der Wortakzent ist die Akzentuierung einer Silbe eines Wortes. Die Silbe ist die kleinste
akzentuierbare Einheit.
• Hauptakzent bzw. Nebenakzent.
Die Entscheidung wo und welcher Akzent bestimmt werden sollte, hängt von mehreren
Faktoren ab: Typ des Wortes, seiner Stelle im Satz oder den grammatischen Merkmale der
benachbarten Wörtern. Zusätzlich wird angegeben zum welchen Typ der Akzent gehört. Der
Akzent wird durch drei möglichen Korrelate markiert: Intonation (Grundfrequenz), Dauer
oder Intensität. Für jedes Korrelat kann es in der Sprachsynthese ein separates Modul mit
dem gleichen Namen geben.
4 An der PJWSTK (Polish Japanese Institute of Information Technology) in Warschau wurde ein System
entwickelt, dass polnische Texte automatisch mit Hilfe von Konversionsregeln phonetisch transkribiert
14

Intonation
Es gibt viele Methoden zur automatischen Bestimmung der Intonation. Der Verlauf der Intonation
setzt sich aus den Effekten des Satzakzentes, des Phrasenakzentes, des Wortakzentes,
sowie des phonetischen Akzentes zusammen, und ist soeben ein sehr komplexes Problem.
In diesem Modul wird versucht die melodischen Standardkonturen (Tonverlauf) für die
gegebene Sprache automatisch zu ermitteln. Dies geschieht meistens mit Hilfe von ToBI-
Beschreibungen (Tone and Breaks Indices, (Beckmann und Hirschberg, „The ToBI annotation
conventions.“, Ohio State University, 1994)), sobald ToBI für diese Sprache definiert
ist. In TTS-Systemen erfolgt das durch PredictTargetF0durch lineare Regression von
allen Faktoren (Position in Phrase, Akzenttyp, Ton, Betonung usw.). Auch hier werden die
Module auf großen, prosodisch annotierten Korpora trainiert.
Gibt es keine ToBI-Beschreibung für die gegebene Sprache (wie etwa Polnisch), werden
einfache Regeln für Intonationskonturen verwendet, die die meisten Fälle abdecken. Es kann
auch ganz einfach passieren, in dem man jedem markierten Akzent naiv einen Brücken- oder
Hutakzent 5 zuordnet.
Dauer
Eine weitere Dimension der Prosodie, die Lautdauer, wird hier modelliert. Die Änderung
der Lautdauer entspricht in manchen Fällen vollkommen dem wahrgenommenen Akzent
(postnuklearer Akzent im Polnischen (Jassem-Demenko)).
Die Vokale in akzentuierten Silben, vor dem Ende der Phrase oder Pause, werden in
manchen Sprachen länger realisiert. Andererseits werden Vokale in unakzentuierten Silben
sowie die, die nacheinander ausgesprochen werden kürzer realisiert.
Intensität
Die Lautstärke, mit der einzelne Silben oder Laute in der Sprache realisiert werden, ist auch
ein Korrelat des Akzentes, das aber in den meisten TTS-Systemen vernachlässigt wird. Möglich
scheint die Modellierung der Intensität mit Hilfe von prosodisch annotierten Korpora,
auf denen das Modul trainiert werden könnte. Weitere Informationen liegen mir nicht vor.
Auswahl der Segmente
Je nach Syntheseverfahren werden andere Segmente gewählt. Die Syntheseengines lassen
sich in der Regel einem von drei Hauptverfahren zuordnen:
Non-uniform unit selection: Aus einer sehr großen Datenbasis werden die am besten
passenden Sprachteile (units) miteinander verkettet, mit variabler Länge (nonuniform).
Dabei wird eine doppelte Kostenfunktion minimiert: die Stücke sollen gut
aneinander passen (Verkettungs-Kosten) und die Vorgaben der Ziel-Prosodie erfüllen
(Target-Kosten).
Diphon Synthese: Das Sprachsignal wird durch Verkettung von Diphonen 6 erzeugt,
die Prosodie-Anpassung (Rhytmus und Melodie) geschieht durch Signal-Manipulation
(Abhängig von der Kodierung der Diphone). Braucht weniger Ressourcen und eignet
sich damit auch für embedded Anwendungen, klingt aber nicht sehr natürlich.
5 Die Gesamtkontur eines Intotationverlaufes, in dem die Stimme zuerst steigt, bleibt dann relativ hoch
für einige Zeit, und senkt sich anschließend wieder
6 Diphone sind Einheiten, die aus Übergängen zwischen zwei Lauten bestehen, und die in der Mitte des
ersten Lautes anfangen und in der Mitte des zweiten Lautes enden
15

Formant Synthese: Das Sprachsignal wird anhand physikalischer Modelle berechnet (Formanten
nennt man die Resonanz-Frequenzen im Sprechtrakt). Ist sehr flexibel und hat
geringste Ressourcen-Anforderung, klingt aber bislang noch sehr unnatürlich.
In der Diphonsynthese werden zum Beispiel in diesem Modul Diphone ausselektiert. Sie
werden dann in der korrekten Reihenfolge miteinander verkettet. Jetzt erfolgt auch die prosodische
Modifikation des Signals (Signalverarbeitung), entsprechend der in der linguistischen
Phase generierten Parameter.
In der Unit Selection wird das ganze Sprachkorpus als akustisches Einheiteninventar
aufbewahrt. Bei der Auswahl der Segmente wird nach den längsten Einheiten gesucht, die
in richtigen prosodischen Kontexten liegen, d.h. die, die den in der linguistischen Phase
berechneten prosodischen Merkmalen entsprechen, und die mit der Sequenz der Ziellaute
übereinstimmen. Man versucht die Anzahl der Verkettungsstellen zu minimieren und die
Notwendigkeit der Signalverarbeitung zu reduzieren. Der Unit Selection-Algorithmus wählt
aus dem Inventar eine optimale Sequenz von Einheiten, indem derjenige Pfad durch das
Zustand-Übergans-Netzwerk gefunden wird, der die Ziel- und Verkettungskosten gemeinsam
minimiert.
Die generierte Textstruktur stellt graphisch die Abbildung 2.2.2 dar.
Abbildung 2.2: Beispiel einer internen Festivalstruktur, erstellt mit dem Visualisierungstool
Fringe für den englischen Satz: „Most precincts had a third of the votes counted"; Quelle:
http://www.cogsci.ed.ac.uk/~amyi/mate/fringe.html
Synthese
An dieser Stelle kann ein akkustisches Signal erzeugt werden. Die eigentliche Synthese besteht
jetzt darin, die ausgewählten Einheiten richtig zu verketten. Zur Verfügung stehen
mehrere Werkzeuge (Synthetiser) zur Verbindung von Einheiten:
• PSOLA (Pitch Synchronous Overlap und Add): Die Grundidee von PSOLA ist es, ein
Originalsignal durch Multiplikation mit entsprechend verschobenen Fensterfunktionen
in kleine Teile zu zerlegen, aus denen sich nach richtiger Addition das Originalsignal
16

ekonstruieren lässt. Durch eine Aneinanderreihung der so entstandenen Signalteile
ist eine beliebige Streckung des Originalsignals bzw. bei Auslassung unwichtiger Teile
eine Stauchung des Originalsignals möglich.
• MBROLA (Multi Band Resynthesis Overlap und Add): ist ein PSOLA-ähnliches Verfahren,
die Datenbasis wird aber im Vorfeld bezüglich der Amplitude, Pitch und spektralen
Eigenschaften angepasst.
• LPC (linear predictive coding) ist ursprünglich ein Komprimierungsverfahren, das auf
dem beliebten Quelle-Filter Sprachmodell 7 basiert.
• TD-PSOLA (Time Domain PSOLA)
• LP-PSOLA (Linear Predictive PSOLA)
• FD-PSOLA (Frequency Domain PSOLA)
• RELP-PSOLA (Residual-Excited PSOLA) - Hybride zwischen LPC und PSOLA
2.3 Anwendungsgebiete
Die Sprachausgabe muß in die Funktionsweise des Systems integriert sein, d.h. sie muß z.B.
mit einer visuellen Ausgabe des Systems angemessen interagieren. Die Sprachausgabe muß
dem Systembenutzer den Umgang mit dem System erleichtern. Sie soll die Effizienz des
Informationsaustausches erhöhen. Dies trifft vor allem auf Anwendungen zu, in denen es
dem Benutzer nicht möglich ist, Informationen auf visuellem Wege zu erhalten wie z.B. im
Bereich der Telekommunikation. In Verbindung mit anderen Systemausgaben erlaubt die
Sprachausgabe eine wünschenswerte Redundanz z.B. in Fahrzeugleitsystemen. Nachfolgend
seien einige bereits marktreife Anwendungen angesprochen.
• Kommunikation
– Vorlesen von SMS und E-mails (email-reading)
– Auskünfte
– Reservierungen
– Angeben von Personalien
– Informationen über das Telefon oder Smartphone
– Fernabfragbare Anrufbeantworter
• Multimedia
– Internet: VoiceXML
– Internet: Informationsportale
– Auto und Navigationssysteme
– Wohnung/ Haus
– MPEG 4 (Synchronisation von Bild und Ton)
7 Akustische Theorie der Sprachlauterzeugung (Fant, 1960): Die Unterscheidung zwischen Stimmquelle
(periodische, stochastische,transiente, gemischte Anregung) und Schallformung im Vokaltrakt führt zum
Quelle-Filter-Modell der Sprachproduktion (source and filter model).
17

– Kodierung, militärische Anwednungen
– Spielzeuge und Roboter
– PDA (Personal Digital Assistant)
– Computerspiele (Kommentare: EA-Sports, Kommunikation in Online Communities)
– Dialogsysteme
– Mensch-Maschine Kommunikation
• Bildung
– Lern- und Lehrprogrammen
– Fremdspracherwerb
– Hilfe beim Lesetraining
– Instrument für linguistische und psycholinguistische Experimente
– Sprechende Bücher
• Kontrolle medizinischer Geräte
Mediziner werden durch eine Sprachausgabe über das nicht ordnungsgemäße Funktionieren
medizinischer Geräte informiert. Diese Anwendung ist vor allem für den
intensivmedizinischen Bereich relevant.
• Hilfe für Behinderte
– Das Ausfüllen von Fragebögen, für Körperbehinderte
– Screen Reader, für Blinde (auch Internetseiten, SMS, Emails)
– Sprechende OCR oder OSC Systeme, für Blinde
– Sprechende Geräte für Leute die Probleme mit der Artikulation haben (S.
Hawking)
Es ist abzusehen, daß sich das Investitionsvolumen im Bereich der Sprachsynthese weiter
erhöhen wird. Die Sprachsynthese wird von der Entwicklung der Hardware stark profitieren.
Die Verbindung von Sprachsynthese und Spracherkennung mit Expertensystemen wird
weitere Anwendungsgebiete erschließen.
2.4 Übersicht der kommerziellen Systeme fürs Polnische
Die Tabelle 2.1 zeigt die Übersicht der kommerziellen Sprachsynthesesystemen für das Polnische.
18

Produkt Produzent Preis
(brutto)
Neurosoft Emtron 49 PLN
Syntalk
(ca. 12
EUR)
Speak II Altix 500 PLN
(ca. 125
EUR)
IVONA IVO Software
RealSpeak Scansoft 532 PLN
(ca. 130
EUR)
Beschreibung
Syntalk ist kein komplettes TTS-System und
braucht, um den Inhalt des Bildschirmes lesen zu
können, zusätzlich ein Steuerungsprogramm (screen
reader, z.B. Hal Screen Reader oder Supernova). Der
einzige Vorteil von Syntalk ist der Preis. Das System
bietet leider nur Grundfunktionen, die gene-
rierte Stimme ist von sehr schlechter Qualität.
SAPI 8 IV TTS-System für Microsoft Windows. Die
generierte Stimme ist verständlich, aber sehr unnatürlich.
Speak II ist mit allen Steuerungsmodulen
kompatibel. Parameter wie die Geschwindigkeit oder
gesetzte Pausen zwischen den Textfragmenten kön-
nen eingestellt werden.
unbekannt IVONA wird vor allem Firmen angeboten, die
Sprachsynthese in Ihre Produkte einbauen wollen -
meistens Rehabilitation bei Sehschwächen. Zwei Versionen
sind erhältlich: IVONA SDK und IVONA Server.
Die wichtigsten Merkmale:
• Auswahl der Textinterpretation (Parsmethode)
• Auswahl der Zeichen die ignoriert werden sollten
• Einstellung der Interpretation von Interpunktionszeichen
• Die Möglichkeit der Einstellung der Geschwindigkeit
(max. x4) ohne Qualitäts- und Intonationsverlust
Die Stimme ist verständlich und hört sich natürlich
an.
RealSpeak wurde nach dem Unit Selection Verfahren
gebaut und bietet momentan die höchste Qualität
der synthetisierten Stimme auf dem polnischen
Markt. Der Synthesizer findet seine Anwendung
hauptsächlich in der Nachrichtentechnik (Telekommunikation),
wird auch einem „normalen“ Benutzer
in Form eines kompletten Softwares angeboten
(„Naturalny Głos“; de. natürliche Stimme).
Fortsetzung auf der nächsten Seite
8 SAPI steht für ßpeech API SDK", siehe http://www.microsoft.com/speech/techinfo/apioverview/
19

Tabelle 2.1 – Fortsetzung aus der letzen Seite
Produkt Produzent Preis
(brutto)
Beschreibung
Elan Elan unbekannt Elan Speech Cube ist ein TTS-Software Kompo-
Speech Informatinente
für Client-Server Architektur. Zwei TTS-
Cube que
Technologien sind erhältlich:
• Elan Tempo - Diphonsynthese
• Elan Sayso - Unit Selection
Elan Speech Cube ist vor allem für eine breite
Auswahl von Betriebssystemen gedacht: Windows
NT/2000/XP, Linux oder Solaris 2.7/2.8. Die Lizenz
kann in verschiedener Form erworben werden: Server,
Client oder „Customized Developer“.
Tabelle 2.1: Kommerzielle Sprachsynthesesysteme des Polnischen,
Quelle: Internetseiten der Produzenten bzw. Anbieter
2.5 Zusammenfassung
In diesem Kapitel wurden die Grundlagen der Sprachsynthese besprochen, die als die Modellierung
der natürlichen Sprache definiert werden kann. Die Aufgabe der Sprachsynthese
besteht darin einen eingegebenen Text (String) in ein akustisches Signal umzuwandeln. Die
Umwandlung erfolgt modular und submodular. Der Syntheseverlauf kann grundsätzlich in
zwei Phasen geteilt werden: die linguistische Phase und die akustische Phase; jede Phase
besteht meistens aus weiteren kleinen Modulen die für verschiedene Analysen verantwortlich
sind. In diesem Kapitel wurden die Aufgaben und die Funktionsweisen von den meisten Modulen
vorgestellt. Weiterhin wurden die Anwendungsgebiete und Einsatzmöglichkeiten der
Sprachsynthese präsentiert: Nachrichtentechnik, Multimedia, Bildung, Medizin u.a. Am Ende
des Kapitels befindet sich auch die Auflistung und kurze Beschreibung der kommerziellen
TTS-Systeme fürs Polnische.
20

Kapitel 3
Korpuserschließung und
maschinelle Vorverarbeitung
3.1 Einführung
Würde man weiter den Gedanken aus dem Kapitel 2.1 folgen, ergibt sich folgendes Problem.
TTS-Systeme versuchen die menschliche Fähigkeit zu sprechen zu simulieren. Sollte also ein
Rechner, genauso wie die Menschen, eine Sprache „erlernen“? Das Erwerben bzw. Erlernen
der Sprache bei den Menschen ist ein sehr komplizierter Prozess. Das Kind muss hören und
sehen können, es muss empfangene Informationen im Gehirn verarbeiten und seine Mundmuskulatur
kontrollieren können. Jedes Kind braucht Menschen in der Umgebung, die mit
ihm sprechen und ihm beibringen, welche Namen die Dinge haben, wie ihre Eigenschaften
sind und wie Sätze richtig formuliert werden sollten. Der Rechner kann aber das alles nicht
- wie sollte er also eine Sprache lernen?
Dies passiert in der Computerlinguistik sehr oft mit Hilfe von Korpora, großen Mengen
maschinenlesbaren Textmaterials. Der Rechner lernt die Sprache nicht, sondern wird auf
diesen Korpora trainiert (man spricht auch sehr oft vom Training). Der Rechner (eigentlich
ein Programm) analysiert die in solchen Korpora enthaltenen Informationen und speichert
sie in Form von Regeln, Wahrscheinlichkeiten, Listen von Werten usw. Bei der Anlayse
wird dann auf diese Daten zugegriffen und auf deren Basis Entscheidungen über natürliche
Sprache getroffen. Diese Zugriffsmöglichkeit könnte man bei den Rechnern als die Fähigkeit
zu Sprechen bezeichnen.
In der Computerlinguistik werden große Mengen maschinenlesbaren Textmaterials „Korpora“
genannt. Zu der popularität von Korpora haben vor allem die Verfügbarkeit großer
Textmengen, die immer schnelleren Rechner und die zur Verfügung stehenden großen Speichermedien,
beigetragen. Die Daten, die man vor 10 Jahren noch auf einem Großrechner
erfassen konnte, können heutzutage auf einem Personal Computer problemlos erfasst werden.
Das Ziel dieses Kapitels besteht darin, zu verdeutlichen, wie große Textmengen so vorbereitet
werden müssen, damit ein Rechner auf diesen Daten trainiert werden könnte. Insbesondere
gilt das für das Training der im Kapitel 4 vorgestellten POS-Tagger. Zu den wichtigsten
Aufgaben gehört in diesem Kapitel die Sammlung von entsprechenden Textmaterialien und
deren maschinelle und automatische Verarbeitung. Bei dem Verarbeitungprozess werden
auch zusätzliche Statistiken generiert. Dieses Kapitel beschreibt die Grundlagen des Aufbaus,
der internen Repräsentation, die Generierungsmethoden, Annotierungsmöglichkeiten,
21

sowie die Schwierikeiten bei der Fertigstellung von Korpora. Die Korpora finden den Einsatz
der oft bei TTS-Systemen, wo verschiedene Module wie z.B. POS-Tagger oder Lautdauermodellierungsmodull
auf solchen Textsammlungen trainiert. Als Resultat enstehen hier verschiedene
Korpora (zum Teil auch annotiert), die ihren Einsatz direkt im Kapitel 4 finden.
3.2 Was ist ein Korpus?
Ein Korpus wird im [Wahrig, 1996] als „Sammlung, Auswahl von Texten, Äußerungen (als
Grundlage für sprachliche Untersuchungen)“ definiert. In der Computerlinguistik ist es also
nichts anderes als eine Menge von Text, die von einer Maschine (Rechner) eingelesen und
analysiert werden kann.
In der Computerlinguistik wird das Wort Korpus meistens in einem Kontext verwendet,
bei dem es sich um eine morphosyntaktisch annotierte Textsammlung handelt. Eine
Textsammlung kann nach folgenden Kriterien annotiert werden:
1. Nach kategorialen Merkmalen (Wortebene)
• Lexikalische Kategorien, wie Substantiv/Nomen, Verb, Adjektiv usw. (POS-
Tagging)
• Phrasale Kategorien wie Nominalphrase, Verbalphrase, Adjektivphrase usw.
(auch chunken genannt)
• Morphologische Eigenschaften - weitere Trennung der lexikalischen Kategorien
in Deklinations- und Konjugationsmerkmale wie z.B Genus, Kasus und Numerus
bei Nomen, Lemmaangabe usw.
2. Nach funktionalen Merkmalen (Satzebene).
Die grammatischen oder syntaktischen Funktionen im Satz, wie z.B. Subjekt,
Objekt, Adverbial, Prädikativ, Attribut.
3. Nach funktionalen Merkmalen(Textebene).
• Satztypen und Satzarten wie Deklarativsätze, Interrogativsätze, Imperativsätze,
aber auch Hauptsätze und Nebensätze (Subjektsätze, Objektsätze, Attributsätze,
Adverbialsätze). Darunter auch Satzgrenzen.
• Nach der topologischen Felderanalyse (Vorfeld, Linke Satzklammer, Mittelfeld,
Rechte Satzklammer, Nachfeld)
4. Nach phonetischen, phonologischen und akustischen Merkmalen (Wortebene und Lautebene)
• Wortdauer
• Akzent
• Phonetische Transkription
• Dauer einzelner Laute innerhalb des Wortes
• Phonologische Kategorisierung der Laute (Lautart, Stimmhaftigkeitsangabe, Artikulationsart,
Artikulationsstelle usw.)
• Grundfrequenzangabe
5. Nach statistischen Merkmalen (alle Ebenen)
22

Angabe der Anzahl des Vorkommens eines spezifischen Segmentes in einer
gegebenen Textmenge; und weitere Statistiken.
Ich werde mich in dieser Arbeit vor allem mit Korpora befassen, die mit lexikalischen
und morphologischen Merkmalen und Kategorien annotiert sind - für die Zwecke dieser Arbeit
sind vor allem lexikalische Kategorien, Wortarten und Wortklassen von Bedeutung. Es
werden auch nicht-annotierte Korpora (Rohkorpora) analysiert, die lediglich einer (grossen)
Sammlung von Textmaterial entsprechen.
3.3 Aufbau der Korpora
Dieses Kapitel wird die Aufbau von Korpora behandeln. Es wird gezeigt wieviele Informationen
ein Korpus kodieren kann, wie komplex diese Informationen sind und wieviel Aufwand
bei der Erstellung investiert werden muss. Professionell vorbereitete Korpora werden meistens
zu wissenschaftlichen Zwecken frei zur Verfügung gestellt, finden aber ihren Einsatz
bei kommerziellen Anwendungen.
3.3.1 British National Corpus
Der British National Corpus (BNC) besteht aus 117.599.144 Tokens, sowohl aus geschriebener
als auch gesprochenen Sprache.
Typ #Kbytes #Sätze #Wortformen
Geschriebene Sprache 1362074 5188373 89740544
Gesprochene Sprache 100172 430348 6154248
Spontane gesprochene Sprache 84952 612049 4211216
Tabelle 3.1: Größe des British National Korpus
Das BNC wurde nach folgenden Merkmalen annotiert:
• POS-Tag (insgesamt 160 verschiedene Kategorien)
• Die Grenzen und Wortklasse für jedes Wort
• Paragraphen, Kapitel und Header in geschriebenen Texten
• Pausen und para-linguistische Merkmale, wie Lachen, in gesprochenen Texten
• Meta-textuale Informationen über die Quelle der Texte
Der British National Corpus liegt in einem Corpus Document Interchange Format(CDIF)
vor, das mit jeder Standard Generalized Markup Language (SGML) kompatiblen Software
dekodiert werden kann. Der folgende Ausschnit zeigt das Format des BNC:
Two men retained their
marbles, and as luck
would have it they’re
both roughie-toughie types
as well as military scientists
&mdash a cross between Albert
23

Einstein and Action Man!
their way to freedom &mdash
so get blasting!
continued on page 7
3.3.2 IPI PAN Korpus
Das IPI PAN ist ein morphosyntaktisch annotiertes Korpus des Polnischen, das im dem
Institut für Informatikgrundlagen in der Polnischen Akademie der Wissenschaften (Instytut
Podstaw Informatyki Polskiej Akademii Nauk, Polen; kurz IPI PAN). Das Korpus besteht
aus 70368788 Tokens, 762169 Typen (verschiedener Wortformen) und 364.366 Lemmata.
Der annotierte Text kommt aus verschiedenen Quellen wie: Gegenwärtige Prosa (10%), Alte
Prosa (10%), Wissen (10%), Presse (50%), Gesetze (5%), Stenogramme vom polnischen
Parlament und Senat (15%). Das Korpus wurde auch mit verschiedenen Typen von Informationen
kodiert, wie:
• Part-of-Speech Tag (32 Hauptkategorien, kombiniert mit grammatischen Kategorien 1 )
• Morpohologie
• Lemmata
• Meta-textuale Informationen über die Quelle der Texte
Beim IPI PAN Korpus wurde ein XML Korpus Encoding Standard (XCES; Ide i in.
2000) Format verwendet. Folgender Auschnitt kommt aus dem IPI PAN Korpus:
Porzadek
porzadeksubst:sg:acc:m3
porzadeksubst:sg:nom:m3
dzienny
dziennyadj:sg:acc:m3:pos
dziennyadj:sg:nom:m1:pos
dziennyadj:sg:nom:m2:pos
dziennyadj:sg:nom:m3:pos
1 siehe Kapitel 3.5 für genaue Informationen
24

Das Korpus, in seiner binären Form kann mit Hilfe von einem, zu diesem Zweck entwickelten
Programm namens Poliqarp einfach durchsucht werden. Die Anfragesprache basiert auf
der Anfragensprache von Corpus Query Processor (CQP), die in Stuttgart entwickelt worden
ist (Christ, 1994), enthält aber zahlreiche Erweiterungen und Verbesserungen gegenüber
von CQP [Przepiórkowski, 2004].
3.4 Automatische Verarbeitung
Damit ein Tagger richtig arbeiten kann, muss er vorher die wichtigsten Daten über die Sprache
lernen. Solch ein Lernprozess erfolgt mit Hilfe von großen Textmaterialien (Korpora),
die verschiedene Informationen enthalten und die in speziellen Formaten vorliegen müssen.
Ohne auf die Einzelheiten auf dieser Etappe einzugehen, nehmen wir einfach an, dass für
die Zwecke dieser Arbeit folgende Textsammlungen gebraucht werden:
1. Eine Liste von allen möglichen Wortformen, wobei bei jeder Wortform eine Liste von
allen Tags vorliegt, die dieser Wortform (in verschiedenen Kontexten) zugewiesen werden
können. (nennen wir die Liste eine N-tag Liste).
2. Eine einfache Liste von allen möglichen Wortarten in der gegebenen Sprache. (nennen
wir die Liste einfache Liste).
3. Ein manuell getaggtes Korpus, bei dem ein Token pro Zeile vorkommt. Bei jedem
Token muss, mit einem Leerzeichen getrennt, der in diesem Kontext zugewiesene Tag
stehen (nennen wir diesen Korpus Token-pro-Zeile Korpus).
4. Ein manuell getaggter Korpus, bei dem ein Satz pro Zeile steht. Das Wort muss von
dem in diesem Kontext zugewiesenen Tag mit einem Slash getrennt werden. (nennen
wir diesen Korpus Satz-pro-Zeile Korpus).
Die Korpora (c) und (d) werden in zwei Teile zerlegt. 90% wird zum Training verwendet,
10% zur Evaluation und zum Testen. Sechs verschiedene Textsammlungen fürs Deutsche,
und sechs fürs Polnische – insgesamt also 12 Dateien – werden gebraucht. Die Vorbereitung
dieser Menge von Textmaterial hat insgesamt mehr als 6 Wochen gedauert. Bei der Vorbereitung
wurden zahlreiche Statistiken generiert, die unten in dieser Arbeit interessante
Ergebnisse liefern.
3.4.1 C++ und Textverarbeitung
Da die Vorbereitung des Textmaterials hauptsächlich an einem Windows-Rechner durchgeführt
wurde, habe ich mich entschieden als Programmiersprache für die benötigten Werkzeuge
C++ zu verwenden. Dennoch wurde für manche Umkonvertierungen Linux Werkezeuge
(wie z.B. awk, perl) verwendet. C++ bietet für Textverarbeitung die C++ Standard
Template Library (STL Bibliotheken) die zahlreiche Funktionen enthält, die die Textverarbeitung
wesentlich erleichtern. Die vollständige Dokumentation von STL befindet sich unter
http://www.cppreference.com/.
Ein echtes Problem stellte dabei die Bearbeitung von polnischen Buchstaben, die nicht im
ASCII Kodierungsystem kodiert werden (da hier nur das englische Alphabet mit den Buchstaben
a-z und A-Z ohne Diakritika kodiert ist). Um diese Zeichen also richtig zu bearbeiten,
muss ein Kodierungssystem verwendet werden, das über das reine ASCII hinausgeht. Generell
können die polnischen Sonderzeichen in folgenden Systemen kodiert werden: ISO-8859-2
(LATIN2), Windows-EE (CP1250), IBM (CP852) oder UTF-8. Ich habe mich entschieden
25

den UTF-8 Standart für Unicode (ISO 10646-1) zu verwenden, wofür es zahlreiche Gründe
gibt:
• UTF-8 ist völlig kompatibel mit ASCII, da nur Codes größer als 127 modifiziert werden.
UTF-8 kodierte Texte können deswegen problemlos in andere Kodierungssysteme
umgewandelt werden und umgekehrt.
• UTF-8 ist ein 8-Bit-Zeichencode, und kann alle im Universal Character Set (UCS)
kodierten Zeichen darstellen.
• Die Länge eines UTF-8 Zeichen ist variabel und kann maximal 4 byte-lang sein. Die
Texte, die hauptsächlich aus ASCII Zeichen bestehen, werden deswegen bei Kodierung
in UTF-8 nicht wesentlich länger.
• Die in UTF-8 kodierten Texte sind (in der Regel) einfach zu erkennen, da die ersten
drei Bytes jeder Datei gekennzeichnet werden (BOM - byte order marker).
3.4.2 Korpora fürs Deutsche
N-Tag Liste Aus dem TAZ-Korpus habe ich für die ersten 10 Millionen Einträge des
Korpuses jeweils kleinere Korpora je 1 Million Einträge extrahiert. Für die restlichen Einträge
(ab 10 Millionen) habe ich dann jeweils kleinere Korpora extrahiert, die 3 Millionen
Einträge enthielten (es sind insgesamt 39 kleinere Korpora entstanden). Es wurden dann
jeweils 2 Dateien als Input genommen und den Inhalt der beiden Dateien verglichen und
verkettet. Jedes Wort wurde dann als ein Objekt einer Klasse gespeichert:
class word_class {
public:
string wort; --> die Wortart
list tags; --> eine Liste von m"oglichen zugewiesenen Tags
string tag; --> der letzte Tag aus der Liste (verwendet bei
Wortarten die immer eindeutig klassifiziert
worden sind)
};
Zu diesem Zweck habe ich in C++ ein Programm geschrieben, dass den eingegebenen Text
schrittweise bearbeitet.
• Jede Zeile aus den beiden Inputdateien wird eingelesen und so zerlegt, das das Wort
als wort gespeichert und der gefundene Tag als einziges Element der liste tags, sowie
als tag gespeichert wird (ab dem zweiten Schritt stehen bei manchen Wortarten schon
mehrere Tags, die Variable tag ist dann das letzte Element der Liste). Alle gefundenen
Wortarten werden eine Liste der Klasse list gespeichert.
• Es entstehen aus zwei Inputdateien zwei Listen dieser Art; die werden dann zuerst
sortiert und Duplikate werden entfernt. Die zwei Listen werden dann zusammengefasst,
wobei die alphabetische Sortierung erhalten bleibt.
• Der Algorithmus läuft dann die ganze Liste durch, und fasst, bei mehrfachen Vorkommen
der gleichen Wortformen, alle Tags zu einer Liste, die dieser Wortform zugewiesen
wird, zusammen.
26

• Ab dem zweiten Schritt, wird die erste Inputdatei, die schon eine alphabetisch sortierte
Liste mit n-tags ist, einfach eingelesen (oder wenn der Algorithmus ohne Unterbrechung
läuft, wird einfach die Outputlist des vorherigen Schrittes als das erste
Parameter genommen ohne die Datei einzulesen). Den Output jedes Schrittes werden
wir in diesem Abschnitt Lexikon nennen.
Zahlen, die als Kardinalzahlen klassifiziert worden sind, werden ignoriert und kommen
im Lexikon überhaupt nicht vor. Das ist auch die Anforderung für das richtige Lernen der
Wortarten der Zahlen beim Tree-Tagger (siehe Kapitel 4.3). Die generierte Datei wurde in ein
Format gebracht, das den Richtlinien des Tree-Taggers für ein Vollformenlexikon entspricht.
Es sollte eine Datei sein, bei der jede Zeile einer Wortform entspricht und eine Sequenz von
Tag Lemma enthält. Jeder Tag sollte direkt nach einem Leerzeichen und jedes Lemma vor
einem Tabulatorzeichen oder einem Leerzeichen stehen.
Als Folge dieses Algorithmus entstand eine Datei, die im gewünschten Format vorliegt.
Die Datei ist 34 MB groß und enthält 1.731.793 verschiedene Einträge. Da das TAZ Korpus
automatisch annotiert worden ist, kommen in der Liste aber eventuell Fehler vor. Eine andere
Möglichkeit zur Erstellung einer N-tag Liste war die Verwendung eines morphologischen
Generators, der zu jeder Wortform alle möglichen morphologischen Varianten liefert (hier
nicht verwendet).
Eine Erstellung der n-tag Liste aus dem TAZ Korpus ermöglichte, als Nebeneffekt, die
Extraktion zahlreicher Statistiken, die folgende Fragen beantworten:
Wie viele verschiedene Wörter kommen in einer bestimmten Menge von
Text vor? Der obige Algorithmus hat insgesamt 39 Dateien analysiert. 9 davon enthielten
1.000.002 Tokens (die ersten neun), eine enthielt 3.595.781 Tokens (die letzte), die restlichen
enthielten 3.000.002 Tokens. Der Durchschnittwert von verschiedenen Wortformen bei
den ersten neun Dateien beträgt 100.867, 6667 (10, 086%), bei den restlichen 29 Dateien
lag er bei 202.433, 7241 (6, 74%). Die Anzahl der verschiedenen Wortformen ist konstant
für eine gegebene Größe des Textmaterials, d.h. in einer bestimmten Menge vom normalen
Text, kommt immer eine ähnliche Anzahl von verschiedenen Wortformen, und beträgt
durchschnittlich ca. 8%. Davon zeugt die fast gerade untere Linie, wie in der Abbildung 3.1
demonstriert.
Welche Wörter treten im Deutschen am häufigsten auf? Welche Wortklassen
haben diese Wörter? Die häufigste Wortform im TAZ Korpus ist das Interpunktionszeichen
Komma (im TAZ Korpus 5238445 aufgetreten), gefolgt von Artikeln, Konjunktionen
und Präpositionen. Das häufigste Nomen (NN) im TAZ Korpus ist Jahren (79831), das
häufigste Eigenname (NE) ist Berlin (90603), das häufigste Verb ist werden (326185).
Wie viele neue Wörter werden bei Analyse einer bestimmten Menge von
Text zum Lexikon hinzugefügt, und welche Wortklassen haben diese Wörter?
Die Annahme bei der Frage war, dass die Anzahl von neuen Wortformen konstant verläuft
und nie eine sichtbare Grenze erreicht (alle Wörter in einer Sprache). Die allgemein akzeptierte
Annahme, mindesten für das Deutsche, wurde von der erzeugten Statistik bestätigt.
Die Grösse des erzeugten Lexikons, das eine Menge von verschiedenen Wortformen bildet,
steigt konstant mit den neu analysierten Texten, was die Abbildung 3.2 demonstriert. Die
Statistiken bestätigen auch die allgemeine Annahme, dass Substantive (NN+NE) und Adjektive
(ADJA+ADJD) zu den produktivsten Wortarten gehören, was die Abbildung 3.3
demonstriert.
27

Abbildung 3.1: Anzahl der verschiedenen Wortformen im deutschen Texten
Abbildung 3.2: Grösse des deutschen Lexikons
28

Die Statistiken bestätigen auch die allgemeine Annahme, dass Substantive (NN+NE)
und Adjektive (ADJA+ADJD) zu den produktivsten Wortarten gehören, was die Abbildung
3.3 demonstriert.
Abbildung 3.3: Die häufigsten Wortarten in deutschen Texten
Einfache Liste Die einfache Liste wurde direkt aus dem TAZ Korpus extrahiert.
Token-pro-Zeile Korpus Die Vorbereitung des Token-pro-Zeile Korpuses, musste von
einem manuell getaggten Korpus erfolgen. Dazu habe ich das deutsche Referenzkorpus des
IMS (empfohlen und zur Verfügung gestellt vom Helmut Schmid) verwendet. Das Korpus
lag schon in dem gewünschten Format vor.
Satz-pro-Zeile Korpus Die Erstellung des Satz-pro-Zeile Korpuses erfolgte direkt aus
dem Token-pro-Zeile Korpus.
Alle entstandenen Dateien wurden in ein gemeinsames Zeichenkodierungsystem, LATIN-
1 (ISO 8859-1), gebracht um den korrekten und konstanten Ablauf des Trainings zu gewährleisten.
3.4.3 Korpora fürs Polnische
N-Tag Liste Die Erstellung einer n-tag Liste fürs Polnische musste auf Grund der fehlenden
Verfügbarkeit eines großen polnischen getaggten Korpuses (auf dessen Informationen
frei zugegriffen werden kann) mit Umwegen und Kompromissen erfolgen.
Zuerst habe ich mit Hilfe von Poliqarp (das maximal 6.000.000 Ergebnisse anzeigt) im IPI
PAN Korpus nach dem Interpunktionszeichen Punkt gesucht (die Suche nach Satzgrenzen ist
nicht möglich), und die gefundenen Tokens, zusammen mit maximalem linkem und rechtem
Kontext (in Poliqarp 20), in eine Datei exportiert (die Wortarten im Kontext waren ebenfalls
annotiert). Die exportierte Datei lag in einem HTML-Format und wurde anschließend in
ein TXT-Format umgewandelt (UTF-8). Die entstandene Datei war 4.173.823 Kbytes groß,
29

und wurde in kleinere, jeweils 10 MB große Dateien geteilt (es entstanden somit 204 kleinere
Teile), die im folgenden Format vorlagen:
Artur [ign] Baniewicz [subst:sg:nom:m1] Drzymalski
[adj:sg:nom:m1:pos] przeciw [qub] Rzeczpospolitej [subst:sg:gen:f]
Z [prep:gen:nwok] daleka [adj:sg:nom:f:pos] wyglądała
[praet:sg:f:imperf] jak [conj] trochę [qub] większy
[adj:sg:nom:m3:comp] pakunek [subst:sg:nom:m3] ,
[interp] pozostawiony [ppas:sg:nom:m3:perf:aff] na [prep:loc]
przystanku [subst:sg:loc:m3] przez [prep:acc:nwok] roztargnionego
[adj:sg:acc:m1:pos] pasażera [subst:sg:acc:m1]. [interp]
Diese Formate wurden, mit Hilfe von einem speziell für diesen Zweck geschriebenen C++
Programms in eine Liste umgewandelt und alphabetisch sortiert, wobei nur nach der Wortart
und dem POS-Tag (das erste Element der geklammerten Wortartinformationen) gesucht
wurde:
odkrytą adj ppas
odkrywa fin
odkrywają fin
odkrywając pcon
odkrywający pact
odkrywających pact
odkrywali praet
odkrywam fin
odkrywamy fin
odkrywana ppas
odkrywane ppas
odkrywani ppas
Ab diesem Schritt sah der Ablauf der Erstellung der polnischen N-tag Liste genauso wie
bei der deutschen (siehe Kapitel 3.4.2) aus. Es wurde jeweils eine Datei analysiert, und die
gefundenen neuen Wortarten oder schon enthaltene Wortarten mit neuen Tags wurden zu
der Liste hinzugefügt. Es wurden dabei auch Statistiken generiert, wobei auf Grund der
Methode der Extraktion aus dem IPI PAN Korpus (es wurde nach Punkt gesucht) viele
nicht aussagefähig sind.
Man kann beobachten, dass bei einer ziemlich konstanten Anzahl von verschiedenen
Wörtern in neuen Dateien, der Zuwachs von der generierten Liste im letzten Abschnitt fast
linear verläuft. Die Annahme hier war, genauso wie fürs Deutsche, dass die Anzahl der
Wortformen im Polnischen nie eine Grenze erreicht, und die Anzahl der neu hinzugefügten
Wortarten konstant wächst. Folgende generierte Statistik lässt aber hoffen, dass fürs Polnische
solch eine Grenze existiert (zumindest annäherungsweise), was im letzten Abschnitt
der Abbildung 3.4 erkennbar ist.
Das generierte Korpus enthält 638.770 verschiedene Wortarten. Die Methode der Extraktion
hat sich also als ziemlich effizient erwiesen (IPI PAN hat nach der Dokumentation
762.169 verschiedene Tokens).
Interessant ist auch eine Statistik, die explizit die Anzahl der neuen hinzugefügten Wörter
anzeigen würde. Die Verhältnisse demonstriert die Abbildung 3.5. Die Graphik zeigt eine
stark sinkende Tendenz der neuen Wortformen in der generierten Liste (bei letzter Datei,
die 17.236 Tokens enthielt, wurden nur 484 neue Wörter gefunden, 2, 8%).
30

Abbildung 3.4: Die Grösse des polnischen Lexikons
Abbildung 3.5: Neue Wortformen im polnischen Lexikon
31

Wieder mal, diesmal fürs Polnische haben sich Nomen und Adjektive als die produktivsten
Wortarten erwiesen, was die Abbildung 3.6 zeigt. Die Substantive machen durchschnittlich
41, 76%, und Adjektive (adj+adja) 19, 4% aller Wörter aus. Eine sehr interessante
Beobachtung war, dass unter den 564.120 (468.938) Tokensnur24.333 (13.219) Tokens
mehr als einen Tag hatten(4, 31 %bzw.2, 818%). Wichtig dabei ist, dass diese Beobachtung
auf den, in der geschriebenen Sprache vorkommenden Wortarten basiert. (die Zahlen
ein Klammer beschreiben die Ergebnisse, nachdem alle Großbuchstaben in Kleinbuchstaben
umgewandelt worden sind, was im Polnischen aussagekräftiger ist)
Abbildung 3.6: Die häufigsten Wortarten im IPI PAN Korpus
Einfache Liste Die Vorbereitung der einfachen Liste fürs Polnische hat sich als eine
sehr zeitaufwendige Aufgabe erwiesen. Zu diesem Zweck habe ich rohes Textmaterial verschiedener
Sorten gesammelt, und in mehreren Schritten eine Liste von einfachen Wörtern
extrahiert. Das Textmaterial bestand aus:
• 1940 Rich Text Format (RTF) Dateien
• 5 Compiled HTML (CHM) Dateien
• 2671 Microsoft Word Format (DOC) Dateien
• 18979 Hypertext Markup Language (HTML) Dateien
• 108 Portable Document Format (PDF) Dateien
• 507 Only Text (TXT u.a.) Dateien
und umfasste folgende Sorten:
• ältere Romane und Prosa (polnische Originale und Übersetzungen)
• neuere Romane und Prosa (polnische Originale und Übersetzungen)
32

• technische Hand- und Fachbücher
• Schul- und Universitätsaufsätze
• Diplom-, Magister- und Doktorarbeiten
• Zeitungstexte
• Gesetze
• Geschäftstexte
• Telefonbuch
Die Extraktion erfolgte in folgenden Schritten (in chronologischer Reihenfolge):
1. Alle Formate wurden zuerst in ein gemeinsames only Text Format umgewandelt.
2. Alle entstandenen Dateien wurden zu einer Datei verbunden, die 1, 9GB groß war.
3. Die Datei wurde dann wieder geteilt, in kleinere Dateien jeweils gleicher Größe (10
MB).
4. Alle only text Dateien wurden in ein gemeinsames Zeichenkodierunksystem UTF-8
umgewandelt.
5. Aus der ersten Datei wurde eine Liste von einzelnen Wörtern (ein Lexikon) erstellt,
die sortiert wurde, und aus der Duplikate entfernt wurden.
6. Die zweite Datei unterging dann dem gleichen Prozess. Die Wörter, die noch nicht
im Lexikon nicht vorgekommen sind, wurden hinzugefügt; auf dem Wege entstand ein
neues Lexikon.
7. Dieser Prozess wurde für alle Dateien ausgeführt. So entstand eine Liste von allen, in
den gesammelten Texten vorgekommenen Wortformen (insgesamt 2.125.618).
8. Aus dem Lexikon wurden mehrstufig die häufigsten fehlerhaften beobachteten Wörter
(Schreibfehler und unkorrekte Schreibweisen) gefiltert (288.236 Einträge).
9. Bei Umwandlung aller Großbuchstaben in Kleinbuchstaben, reduzierte sich die Größe
desLexikonsumweitere320.000.
10. Die endgültige Output-Datei ist 21.948.284 kByte groß und enthält 1.541.826 Tokens,
was 24.474 Seiten Text entspricht.
Der obige Prozess hat auch zahlreiche statistische Daten generiert, die wiederum Antworten
auf folgende Fragen liefern können:
Welches ist das häufigste Wort im Polnischen? Das häufigste Wort im Polnischen
ist die Präposition w (de.in), die 5.170.148 vorgekommen ist. Das häufigste Substantiv im
Polnischen ist Warszawa (de. Warschau), das 443.987 mal vorgekommen ist. Zur Erinnerung
- das häufigste Eigenname im Deutschen war Berlin.
Wie viele verschiedene Wortformen (Tokens) enthält ein durchschnittlicher
polnischer Text? Im Durchschnitt kommen in einem polnischen Text 7.91% verschiedener
Wörter. Die Abbildung 3.7 stellt dieses Verhältniss graphisch dar.
33

Abbildung 3.7: Verschiedene Wortarten in polnischen Texten
Wieviel Text müsste man sammeln, um „alle“ Wörter im Polnischen extrahieren
zu können? Man geht in der Sprachwissenschaft davon aus, dass solch eine Grenze
nicht existiert. Die Abbildung 3.9 zeigt aber (die polynomische Trendlinie), dass die Anzahl
der neuen Wörter konstant sinkt. (in der Abbildung 3.8, wo auch die Größe des Textmaterials
zum Vergleich gezeigt wird, kann man den Verlauf der neuen Wörtern sehr schlecht
erkennen; aus diesem Grund wird auch die Abbildung 3.9 in kleinerer Skala gezeigt).
Im letzten Schritt wurden in einem Text, der 28.768 Wörter enthält, 57 neue Wörter
gefunden (0, 19%). Vier Schritte früher wurden in einem Text mit 1.329.086 Wörtern, 1.766
neue Wörter gefunden (0, 13%). Wichtig zu erwähnen ist, dass das Textmaterial auf dieser
Etappe der Analyse noch sehr viele fehlerhafte Wörter enthalten hat, und dass groß- und
kleingeschriebene gleiche Tokens, als zwei verschiedene erkannt wurden.
Satz-pro-Zeile Korpus Einen manuell getaggtes Korpus habe ich für die Zwecke dieser
Arbeit von Krzysztof Marasek (PJWSTK ) bekommen. Das Korpus lag in einem Satzpro-Zeile
Format vor, aus dem ich direkt einen Token-pro-Zeile Korpus extrahiert habe.
Token-pro-Zeile Wie im vorherigen Punkt erwähnt, lag der erhaltene Korpus schon im
richtigen Format vor.
Alle entstandenen Dateien wurden anschließend in ein gemeinsames Zeichenkodierungsystem,
ISO-8859-2 (LATIN2) gebracht, um den richtigen und konstanten Ablauf des Trainings
zu gewährleisten.
34

Abbildung 3.8: Neue Wortformen in polnischen Texten I
Abbildung 3.9: Neue Wortformen in polnischen Texten II
35

3.5 Tagsets
3.5.1 Was ist ein Tagset?
Ein Tagset ist einfach eine Liste von „lexikalischen Kategorien“, zu denen eine Wortform gehören
kann. Der Begriff Wortform umfasst neben echten Wortformen auch Zahlen in Ziffern,
Satzzeichen, Sonderzeichen (wie z.B. $, §), abgetrennte Wortteile oder Kompositionserstglieder
(wie z.B. „Ein- und Ausgang“).
Jede mögliche lexikalische Kategorie trägt den Namen eines Tags. Jede Hauptwortart
(nach lexikalischen Kategorien klassifiziert; wie z.B. Nomen, Verb usw.) wird normalerweise
noch weiter subklassifiziert, nach distributionellen aber auch morphologischen und syntaktischen
Kriterien. So kann z.B. die lexikalische Kategorie Nomen in zwei weitere wortartenspezifische
Kategorien subklassifiziert - normales Nomen (Tisch) und Eigennomen (Hans).
Das STTS-Tagset (Stuttgart-Tübingen Tagset [Schiller, A., Teufel, S. Thielen, C., 1995])
enthält nach diesen Richtlinien 11 Hauptwortarten (Nomina, Verben, Artikel, Adjektive,
Pronomina, Kardinalzahlen, Adverbien, Konjuktionen, Adpositionen, Interjektionen und
Partikel).
Diese Hauptwortarten sind unterschiedlich stark subklassifiziert. So werden z.B. die Pronomina
in weitere Untergruppen unterschieden, wobei die Untergruppen wieder unterteilt
sein können, je nachdem ob sie NP-ersetzende (substituierend, tag S), nomenbegleitende
(attribuierend, tag AT) oder adverbiale (tag AV) Funktion besitzen. Das STTS-Tagset hat
insgesamt 54 tags.
Welche Merkmale für ein Tagset relevant sind, hängt von dem Ziel der Konstruktion sowie
von der zugrunde liegenden Sprache ab. Ein perfektes Tagset sollte also für jede denkbare
Anwendung alle relevanten Merkmale besitzen - so detailliert wie möglich sein. So könnte
z.B. für jede mögliche Zusammensetzung von morphologischen Merkmalen ein separater Tag
existieren. Eine sehr detaiilierte Informationen kodiert z.B. das IPI PAN Korpus:
• Boisz [bać:fin:sg:sec:imperf] -Wortboisz ist (eigentlich ein Teil der Konstruktion
poln. bać się, de. Angst haben), ein finites Verb „nicht in der Vergangenheitsform“,
Singular, 2.Person, unvollendet.
• Podjechał [podjechać:praet:sg:m3:perf] -Wortpodjechał (von poln. podjeżdżać,
de. ankommen) ist ein Pseudopartizip (Partizipium), im Singular, sächlich maskulin,
vollendet.
IPI PAN Korpus kodiert insgesamt eine breite Anzahl von verschiedenen Merkmalen,
die in zwei Gruppen geteilt wurden:
• Grammatische Kategorien: Person, Numerus, Tempus, Modus, Diathese/Genus Verbi,
Komparation, Aspekt, Negierung, Akzent, Vokalität, Akkomodierung, Agglutination,
Postpräpositionierung.
• Flexeme, subklassifiezierte lexikalische Merkmale: Nomen, depretiative Nomen, Verben
usw., insgesamt 32 Tags.
Die Merkmale werden dann bei der Kategorisierung zu einer komplexen Kategorie kombiniert,
z.B. [podjechać:praet:sg:m3:perf] besteht aus folgenden Teilen:
• podjechać (Wortform)
• praet (Lexkikalisches Merkmal)
• sg:m3:perf (Grammatische Merkmale)
36

Die vollständige Beschreibung der Kodierung in IPI PAN befindet sich
in [Przepiórkowski, 2004].
Da die Konstruktion eines Tagsets auch sehr sprachspezifisch ist zeigt das British-
National-Tagset, in dem nur für die Verben insgesamt 25 verschiedene Tags verwendet werden
(im STTS gibt es hingegen nur 5 Tags für Verben). Darunter werden nur für das Verb
BE 7 Tags und für das Verb HAVE 6 Tags verwendet, wohingegen die deutschen Entsprechungen
SEIN und HABEN überhaupt nicht unterschieden werden.
3.5.2 Bestimmung der Tagsets
In diesem Kapitel werden Tagsets definiert und bestimmt, die weiter in dieser Arbeit zum
Taggen von polnischen und deutschen Texten verwendet werden. Im Kapitel 4 wird beschrieben,
wie zwei Tagger für zwei Sprachen trainiert werden. Jeder Tagger (siehe Kapitel 4.4.4
und Kapitel 4.3.2) benötigt zum Training Textsammlungen, die in besonderen Formaten
vorliegen müssen (siehe Kapitel 3.4). Alle Dateien, die zum Training auf einer Sprache verwendet
werden, müssen, um einen korrekten Ablauf zu gewährleisten nach gleichen Tagset
getaggt werden. In dieser Arbeit wurden Textsammlungen verwendet, die nach verschiedenen
Tagsets getaggt wurden. In diesem Kapitel werden jeweils zwei Tagsets miteinander
unifiziert.
Tagset fürs Polnische
Fürs Training vom Tree-Tagger (siehe Kapitel 4.3) werden zwei verschiedene Textsammlungen
benötigt. Die Erstellung von diesen Textsammlungen (N-tag-Liste und Token-pro-Zeile
Korpus) wurde im Kapitel 3.4.3 besprochen. Das Token-pro-Zeile Korpus wurde nach einem
Tagset (siehe Tabelle 3.3) getaggt (nennen wir dieses Tagset PJWSTK-Tagset), in dem nur
das Verb (7 Tags) und das Zahlwort (2 Tags) subklassifiziert werden.
Das PJWSTK-Tagset in solch einer Form wird auch beim Trainieren vom Brill Tagger
(siehe Kapitel 4.4) verwendet. Die N-tag-Liste wurde aus dem IPI PAN Korpus
extrahiert, der nach einem internen Tagset (die genaue Beschreibung befindet sich im
[Przepiórkowski, 2004]) getaggt. Um dem Tree-Tagger (siehe Kapitel 4.3) einen korrekten
Ablauf zu gewährelisten mussten die Tagsets unifiziert werden und die Tagsersetzungen in
beiden Textsammlungen vorgenommen werden.
Die Tagsets wurden nach folgenden Prinzipen unifiziert:
1. Das PJWSTK-Tagset hat drei Tags für Zahlwörter (normales Numeral, Kardinalzahl
und Ordinalzahl); das IPI PAN Tagset hat jedoch zwei (Kardinalzahl und Sammelzahl).
Die zwei Mengen haben leider nur einen Tag gemeinsam (Kardinalzahl). Alle
Arten der Numerale wurden zu einer Kategorie Numerale (NUM) zusammengefasst.
2. Die Kategorie des IPI PAN Tagsets winien, die die Lexeme winien, powinien, rad
enthalten (alle entsprechen mehr oder weniger den deutschen Lexem „sollen“, die nur
analytische Zeitformen bilden). Alle Lexeme dieser Art wurden zu der Kategorie V
(Verb) hinzugefügt.
3. Die Kategorie predykatyw, die die synthetisch unflektierbare Flexeme kodiert, welche
ausschließlich analytisch modifiziert werden können; z.B. warto (de. es lohnt sich)
- będzie warto (de. es wird sich lohnen). Sie bestimmt auch eine eigene Klasse, zu
der Wortformen gehören, die nach dem PJWSTK-Tagset zu mehrfachen Kategorien
gehören können. So wird z.B. das Wort to („das“ demonstrativ verwendet) im IPI
37

Tag Bedeutung Beispiele
V Czasownik/Verb mówiłem
ADJPAP adjektivisches Passivpartizip chowany
ADJPRP adjektivisches Aktivpartizip celujący
INF Infinitivform biegać
ADVANP adverbiales Perfektpartizip ujżawszy
ADVPRP adverbiales Präsenspartizip celując
VNONP unpersönliche Verbform mówiono
N Nomen pies
ADJ Adjektiv biały
ADV Adverb blisko
PRON Pronomen ja, ty
INTER Interjektion ach, och, ech
NUM Numeral dwudziestu
NUMCRD Kardinalzahl jeden, dwa, trzy (Zahlen im Nominativ)
NUMORD Ordinalzahl pierwszy
P Präposition przy, od, na
PART Partikel że, iż, li, nie, tu, to, nieco, jeszcze
CONJ Konjunktion i,a, oraz
$. Interpunktion am Ende des Satzes ., !, ?
$, Interpunktion innerhalb des Satzes komma,-,
Tabelle 3.3: PJWSTK-Tagset
PAN Korpus als pred getaggt, was nach dem PJWSTK-Tagset als PART (Partikel)
zu klassifizieren ist. Das Wort trzeba (de. man sollte) imIPIPANalspred klassifiziert,
gehört nach dem PJWSTK-Tagset zur Kategorie ADV (Adverb); noch anders ist es
bei z.B. słychać, das beim IPI als pred klassifiziert wird, was nach dem PJWSTK-
Tagset zu der Kategorie INF (Infinites Verb) gehört. Insgesamt gibt es bei IPI PAN
Korpus nur 25 Wortformen dieser Kategorie. Die Kategorie pred wurde also komplett
weggelassen. Die Wörter, die nur einen möglichen Tag pred haben (mit einem Pfeil
markiert), habe ich manuell getaggt; bei den restlichen habe ich einfach die Kategorie
pred gestrichen.
brak pred subst
czas pred subst
czuć inf pred subst
dosyć pred qub
doć pred qub
niepodobna pred --> ADJPAP
podobna adj pred
pora pred subst
potrzeba pred subst
stać inf pred
strach pred subst
szkoda pred subst
słychać pred --> INF
to adj conj pred qub subst
38

trza pred --> ADV
trzeba pred qub
warto pred --> ADV
wiadomo pred --> VNONP
widać pred qub
wolno pred --> ADV
wstyd pred subst
znać inf pred
miech pred subst
żal pred subst
4. Ein ähnliches Problem stellte die Kategorie ’qub’ (unflektierbare Form, die zu anderen
Kategorien nicht passt). Den Wortformen, im IPI PAN als qub klassifiziert werden,
sollten nach dem PJWSTK-Tagset entweder die Kategorie PART (Partikel) oder IN-
TER (Interjektion) zugeordnet werden. Um diese Unkompatibilität zu lösen, habe ich
einfach die Kategorien PART und INTER zusammengefasst.
5. Die Kategorien xxx (Fremdwörter), sowie ign (nicht erkannte Form) wurden komplett
ignoriert.
6. Die Interpunktion stellte auch ein Problem dar, weil es im PJWSTK-Tagset zwei
verschiedene Kategorien dafür gibt; eine für satzendende Interpunktionszeichen und
eine für satzinterne Interpunktionszeichen. Im IPI PAN gibt es nur eine Kategorie
interp, die alle Interpunktionszeichen kodiert. Die Interpunktionszeichen habe ich von
Hand richtig annotiert.
Das endgültige Tagset nach den Modifikationen steht im Anhang A.1. Dieses Tagset
wurde bei Training vom Tree-Tagger verwendet.
Tagset fürs Deutsche
Für das Training vom Tree-Tagger für das Deutsche (siehe Kapitel 4.3) werden zwei verschiedene
Textsammlungen benötigt. Die Erstellung von diesen Textsammlungen (N-tag-Liste
und Token-pro-Zeile Korpus) wurde im Kapitel 3.4.3 besprochen.
Das Token-pro-Zeile-Korpus wurde nach der Standartversion von STTS-Tagset getaggt;
das N-tag-Korpus wurde aus dem TAZ-Korpus extrahiert, das nach einer IMS-Variante
des STTS Tagsets getaggt worden ist. Der Hauptunterschied liegt in der Annotierung von
indefiniten und demonstrativen Pronomina und Determinatoren. Beim Training des Brill-
Taggers wurde Standart STTS Tagset verwendet.
Standart STTS: Demonstrative und indefinite Pronomina formen separate Tags. Spezielle,
lemma-basierte Klassen wurden zu indefiniten Pronomina oder Adverbien (in
adverbialer Lesart von viel).
• das/PDS weiß ich nicht
• diejenige/PDAT Person, die dasselbe/PDAT Kleid trägt
• manches/PIAT andere/ADJA Thema;
• manch/PIAT anderes/ADJA Thema
• keiner/PIS war da; in keiner/PI.AT Form
39

• er hat viele/PIAT Bücher; er trinkt viel/PIAT Wein
• er sieht vieles/PIS ein
• er ißt viel/PIS; er lacht wenig/ADV
• alles/PIS , was recht ist
• all/PIAT diese/PDAT vielen/PIAT Leute
• die beiden/PIS kamen gleichzeitig
• beide/PIS waren da
• beide/PI.AT Läufer waren gleich schnell
IMS-Variante STTS: Klassen für indefinite Pronomina und Determinatoren und demonstrative
Pronomina und Determinatoren formen eine gemeinsame Klasse. Abweichende
Einheiten haben ihre spezifische lemma-basierte Klasse PBEID, PALL, PVIEL und
PNFL (für nicht flektierendes Pronomen)
• das/PROS weiß ich nicht
• diejenige/PROAT Person, die dasselbe/PROAT Kleid trägt
• manches/PROAT andere/ADJA Thema
• manch/PNFL anderes/ADJA Thema
• keiner/PROS war da; in keiner/PROAT Form
• er hat viele/PROAT Bücher; er trinkt viel/PROAT Wein
• er sieht vieles/PROS ein
• er ißt viel/PVIEL; er lacht wenig/PVIEL
• alles/PALL, was recht ist
• all/PALL diese/PROA vielen/PROA Leute
• die beiden/PBEID kamen gleichzeitig
• beide/PBEID waren da
• beide/PBEID Läufer waren gleich schnell
Die zwei Versionen des STTS-Tagset wurden unifiziert. Manche Kategorien des Standartversion
des STTS wurden zu einer Kategorie zusammengefasst. Die Kategorien der
IMS-Variante wurden auf einzelne Kategorien der Standartvariante abgebildet. Alle Ersetzungen
und Abbildungen zeigt die Tabelle 3.4. Diese Tabelle ist wie folgend zu lesen: wenn
in der Spalte Standart STTS mehrere Tags vorkommen, bedeutet das, dass all die Tags
zu einer Kategorie zusammengefasst wurden (fett markiert); die Spalte Bedeutung bezieht
sich auf die Standart STTS Tags; die Spalte Beispiele gibt Beispiele für die Standart STTS
Kategorien; die Spalte IMS STTS listet Tags aus IMS Version des STTS auf, die mit entsprechenden
Tags aus der Spalte Standart STTS ersetzt wurden.
Standart
STTS
Bedeutung Beispiele IMS STTS
PDAT attribuierendes Indefinit- [in] dieser [Halle] PALL: allem, allen,
pronomen ohne Determiner
aller
Forsetzung auf der nächsten Seite
40

Tabelle 3.4 – Forsetzung aus der letzen Seite
Standart STTS Bedeutung Beispiele IMS STTS
PIS substituierendes Indefinit- keiner, viele, man, PBEID:beide, beipronomen
niemand
dem
PIDAT attribuierendes Indefinit- [ein] wenig [Was- PNFL: manch,
pronomen mit Determiner ser], [die] beiden solch
[Brüder]
PIAT attribuierendes Indefinit- kein [Mensch], ir- PROAT: solchem,
pronomen ohne Determinergendein
[Glas] selben
PDS substituierendes
strativpronomenDemon-
dieser, jener PROS: niemand
PVIEL: viel, ebensoviel
PAV Pronominaladverb dafür, dabei, deswegen,
trotzdem
PROAV
PPER irreflexives Personalpro- ich, er, ihm, mich, PPERRF: mir, dich
nomen
dir
VVIZU Infinitiv mit zu, voll anzukommen,
zulassenlos-
VAIZU: anzuhaben
PPOSAT attribuierendes Possessiv- mein [Buch], deine PPOSS: deins, meipronomen
[Mutter]
ne
PTKVZ abgetrennter Verbzusatz [er kommt] an, [er
fährt] rad
PTKVE: an, auf
zugute, zurecht PTKVL: zugute
VAPP Partizip Perfekt, aux gewesen VAPPF: gewesen
VMPP Partizip Perfekt, modal gekonnt, [er hat gehen]
können
VMPPF: gekonnt
VVPP Partizip Perfekt, voll gegangen,
kommenange-
VVPPF: gekoppelt
NN normales Nomen Haus, Tisch NN: Haus, Tisch
FM Fremdwörter development, puncto
keine Kategorie
Tabelle 3.4: Änderungen bei der Unifikation von zwei Varianten des
STTS-Tagsets
Dieses modifizierte Tagset wurde beim Training des Tree-Taggers verwendet.
3.6 Zusammenfassung
In diesem Kapitel habe ich die wichtigsten Probleme und Ansatzpunkte besprochen, die
bei der Erstellung von Korpora auftreten können: annotierte Korpora und deren Formate,
morphologische Merkmale, Tagsets und Zeichenkodierungssysteme. Das Ziel wurde auch
erreicht und zahlreiche Dateien sind erstellt worden, die direkt für das Training von zwei
Anwendungen zur automatischen Wortklassenannotierung verwendet werden können.
41

Kapitel 4
Part-of-Speech Tagging
4.1 Was bedeutet Tagging?
Der Begriff Tagging kommt aus dem Englischen und bedeutet die Zuweisung von Tags (de:
Etikett, Label) verschiedener Form. Tagging kann in vielen verschiedenen Kontexten und
für verschiedene Zwecke verwendet werden. In vielen Kontexten der maschinellen Sprachund
Informationsverarbeitung, stellt Tagging den Prozess der Zuweisung von Matadaten an
Teile von Daten dar.
• Der Inhalt von Webpages ist im HTML-Format kodiert, das die eine Reihe von HTML-
Tags verwendet.
• Tagging wird sehr häufig bei Audiodatenkompression verwendet - hier wird es als
"Hinzufügen"verstanden.
• In der Linguistik wird es meistens als Part-of-speech Tagging verstanden.
In dieser Arbeit wird Tagging aus der linguistischen Sicht betrachtet, als automatisches
Part-of-speech Tagging. POS Tagging ist ein Prozess, bei dem die Wortklasse der Wörter
bestimmt wird. Die Liste der möglichen Wortklassen, die zugewiesen werden können, wird
Tagset genannt (siehe Kapitel 3.5.1). Part-of-Speech Tagging ist viel komplizierter als einfach
eine Liste von Wörtern und ihren Wortklassen. Der Grund dafür ist, dass viele Wörter, je
nach Kontext, verschiedene Wortklassen repräsentieren können. In vielen (vielleicht sogar
allen?) Sprachen ist ein großer Prozentsatz von Wortformen mehrdeutig. Sogar das englische
Wort "dogs", das normalerweise nur als Pluralnomen (de: Hunde) interpretiert wird, kann
ein Verb sein:
1. A policeman dogs us the whole .(de: Ein Polizist läuft uns den ganzen Tag hinterher)
2. Ronaldo had been dogged by injury all the season.(de: Ronaldo wurde die
ganze Saison von einer Verletzung verfolgt)
Die Geschichte des POS-Taggings geht auf die Mitte der sechziger Jahre zurück, als
das erste maschinenlesbare Korpus (Brown Corpus 1 ) erstellt wurde. Dieses Korpus wurde
für das erste automatische Tagging-System (Tagger) verwendet, das eine Fehlerrate von
1Das Brown Corpus wurde an der Universität Brown von Henry Kucera und Nelson Francis entwickelt,
und enthielt ca. 1 Million Tokens
42

knapp 30% hatte (Klein Simmons 1963; Harris 1962). Ein Tagger ist ein Programm, das
einen Text, eine Folge von Wörtern natürlicher Sprache (Strings) als Eingabe bekommt,
und jedem Wort den richtigen (oder wahrscheinlichsten) POS-Tag zuordnet. Die Ausgabe
ist meistens ein mit Tags (und anderen Informationen wie z.B. Lemmata) annotierter Text.
Auf der Suche nach besserer Präzision haben die Wissenschaftler im Laufe der Zeit viele
verschiedene Tagging-Techniken entwickelt, die immer wieder bessere Resultate geliefert
haben. Eine grobe Übersicht der Tagging-Ansätze wird im Kapitel 4.2 gegeben.
4.2 Taggingansätze
Die Abbildung 4.1 schildert die Gliederung der verschiedenen Ansätze des automatischen
POS-Tagging. Dieses Bild sieht in der Wirklichkeit viel komplizierter aus, weil viele Systeme
sehr oft verschiedene, oder sogar alle Ansätze gleichzeitig verwenden. Die Abbildung 4.1
demonstriert die Tagging-Ansätze grafisch. Dieses Kapitel basiert zum grossen Teil auf dem
Artikel von Linda Van Guilder, Georgetown University „Automated Part of Speech Tagging:
A Brief Overview“ und dessen Literatur.
Abbildung 4.1: Taggingansätze nach [Linda Van Guilder 1995]
4.2.1 Supervised vs. Unsupervised
Der erste Unterschied zwischen den verschiedenen Tagging-Ansätzen, bezieht sich auf den
Automatisierungsgrad des Trainings und des Taggingprozesses.
43

Supervised taggers verwenden vorgetaggte Korpora. Die Korpora kommen im Laufe des
ganzen Taggingprozesses zum Einsatz und werden zur Erstellung verschiedener Werkzeuge
benutzt, z.B. Worthäufigkeiten, Regelmengen (bei regelbasierten Ansätzen),
oder auch Wahrscheinlichkeiten der Tagssequenzen (bei probabilistischen Ansätzen).
Unsupervised Modelle brauchen keine vorgetaggte Korpora. Sie verwenden komplexe
Berechnungsmethoden um zueinander gehörende Elementmengen Tag- bzw. Wortmengen
automatisch aus rohen Texten zu induzieren (z.B. Tagsets). Basierend auf
den erstellten Mengen, werden entsprechend entweder probabilistische Informationen
für stochastische Tagger berechnet, oder Kontextregeln für regelbasierte Tagger bestimmt.
Jeder der beiden Ansätze hat Vorteile und Nachteile.
Das erste Argument für die Verwendung des vollautomatischen Ansatzes ist ihre Flexibilität.
Für viele Sprachen (wie etwas für das Polnische) existieren einfach keine vorgetaggten
Korpora die man zum Training verwendet könnte. Die Erstellung von Trainingsdaten ist
sehr teuer (vergleiche Kapitel 3). Der vollautomatische Ansatz hat aber auch seine Nachteile.
Die Wortgruppen, die als Folge diesen Methoden resultieren sind nämlich zu ungenau,
d.h. man verliert die feine Unterscheidung, die man in den sorgfältig entwickelten Tagsets
finden kann (in dem halb-automatischen Ansatz).
4.2.2 Regelbasiertes Tagging
Typische regelbasierte Ansätze verwenden kontextuelle Informationen um unbekannte oder
mehrdeutige Wörter zu taggen. Diese Regeln werden sehr häufig als Kontextrahmenregeln
„context frame rule“ bezeichnet. Zum Beispiel kann solch eine Regel wie folgend aussehen:
wenn einem ambigen/ unbekannten Wort X ein Determiner vorausgeht, und ein Nomen
folgt, dann ist der Tag für X ist Adjektiv. Diese Regel kann auch wie folgend formalisiert
werden.
Det - X - n = X/adj
Viele Tagger verwenden, zusätzlich zu kontextuellen Informationen, auch morphologische
Informationen um den Disambiguierungsprozess zu verbessern. Solch eine Regel für das Englische
kann wie folgend aussehen: wenn ein ambiges/ unbekanntes Wort auf -ing endet und
ihm ein Verb folgt dann ist es ein Verb (playing, de. Continuous Form von spielen). Manche
Systeme verwendet auch Faktoren wie Großschreibung und Interpunktion. Die Information
über Großschreibung kann z.B. im Deutschen beim Taggen von unbekannten Nomen helfen.
Regelbasierte Tagger benötigen normalerweise ein halb-automatisches Training. IEin
möglicher Ansatz der automatischen Regelinduktion bildet die Möglichkeit einen nichtgetaggten
Text durch einen Tagger laufen zu lassen und seine Performanz zu analysieren.
Der Output des Taggers sollte dann in der ersten Phase manuell korrigiert werden, d.h. alle
fehlerhaften Tags sollten durch richtige Tags ersetzt werden. Dieser richtig getaggte Text
wird dem Tagger wieder vorgelegt, der die zwei Mengen von Daten vergleichen sollte. Dabei
werden die so genannten Korrekturegeln erzeugt. Die Einzelheiten solch eines Ansatzes werden
detailliert im Kapitel 4.4 besprochen. Die Abbildung 4.2 stellt diesen Prozess graphisch
dar.
4.2.3 Stochastisches Tagging
Der Begriff stochastisches Tagging bezieht sich auf eine Menge von verschiedenen Ansätzen
im POS-Tagging. Jedes Model, das mit Häufigkeiten oder Wahrscheinlichkeiten arbeitet
44

Abbildung 4.2: Möglicher Ablauf eines regelbasierten Taggers
kann als stochastisch bezeichnet werden. Die einfachsten stochastischen Tagger disambiguieren
Wörter ausschließlich auf der Basis der Wahrscheinlichkeit, dass ein Wort mit einem
spezifischen Tag vorkommt. Dieser Ansatz kann zwar einem Wort den richtigen Tag
zuordnen, aber auch für einen Satz eine unzulässige Sequenz von Tags generieren. Eine
Alternative zum Worthäufigkeitsansatz bildet die Möglichkeit eine Wahrscheinlichkeit für
eine bestimmte Sequenz von Tags zu berechnen. Solch eine Methode wird sehr häufig als
N-Gram-Ansatz bezeichnet - der beste Tag für ein gegebenes Wort wird durch die Wahrscheinlichkeit
bestimmt, dass es mit n vorgehenden Tags auftritt. Dieser Ansatz wird sehr
häufig mit dem Viterbi Algorithmus 2 implementiert. Die nächste Komplexitätsstufe kann
eingeführt werden, indem die zwei oben genannten Ansätze, Worthäufigkeitenmessungen und
Tagsequenzenwahrscheinlichkeiten, miteinander kombiniert werden, was unter dem Namen
Hidden Markov Modelle bekannt ist. Folgende Annahmen liegen diesem Model zugrunde:
1. Jeder verborgene Tagzustand erzeugt ein Wort in einem Satz.
2. Jedes Wort steht in keiner Wechselbeziehung mit allen anderen Wörtern und deren
Tags.
3. Die Wahrscheinlichkeit jedes Wortes hängt ausschließlich von N vorherigen Tags ab.
[Dermatas Kokkinakis, 1995]
Um beim Taggen einen stochastischen Ansatz zu verwenden, müssen zuerst alle notwendigen
Messungen und Berechnungen durchgeführt werden, um die Werte für die n-gram
basierten transitionalen Häufigkeiten zu bestimmen. Man fängt mit einem getaggten Korpus
an und bestimmt mit deren Hilfe die transitionalen Wahrscheinlichkeiten. Um diesen Prozess
zu demonstrieren, zeige ich Schritt für Schritt das Schema der Berechnung von diesen
Werten für Bigramm-Modelle (d.h. nur der unmittelbare Kontext wird berücksichtigt).
1. Der erste Schritt ist die Berechung der Wahrscheinlichkeiten für das Auftreten jeder
Kategorie. Um z.B. die Wahrscheinlichkeit des Auftretens eines Nomen zu berechnen,
2 Der Zweck des Viterbi Algorithmus besteht darin, auf effiziente Weise die beste verborgene Pfadsequenz
durch ein Hidden Markov Modell (HMM) zu finden. Er sucht die wahrscheinlichste Sequenz der verborgenen
Zustände des HMMs zu einer gegebenen Beobachtung.
45

dividiert man die gesamte Anzahl von Nomen, durch die gesamte Anzahl von Wörtern.
Haben wir einen Korpus mit z.B. 100 Wörtern und 20 davon sind Nomen, so beträgt die
Wahrscheinlichkeit des Auftretens eines Nomen 20%. Übergangswahrscheinlichkeiten
werden anhand eines ungetaggten Referenzkorpus gelernt.
2. Der zweite Schritt ist die Berechnung der transitionalen Wahrscheinlichkeiten für
Wortsequenzen, der so genannten bedingten Wahrscheinlichkeit - der Wahrscheinlichkeit
eines Ereignisses A, wenn das Ereignis B gegeben ist (bedingte Wahrscheinlichkeit).
P (A|B) =
P (A ∩ B)
P (B)
Wollen wir also die Wahrscheinlichkeit eines Nomen berechnen, das vor einem Artikel
steht, wobei wir Kategoriefrequenz und nicht die Kategoriewahrscheinlichkeiten in
Betracht ziehen, so sieht die die Formel folgendermaßen aus. Zu der oben gezeigten
Formel fügt man normalerweise noch die Frequenz des Kontextwortes hinzu, damit die
häufigsten Wörter nicht bevorzugt werden. So hängt das Ergebnis von den Frequenzen
der Bigramm-Wörter und nicht von dem Kontextwort ab.
P (i = NN|i − 1=ART )=
count(ART at position i − 1 ∩ NN at i)
count(ART at position i − 1) ∗ count(NN at position i)
3. Der letzte Schritt ist die Verwendung der berechneten transitionalen Wahrscheinlichkeiten
um den optimalen Pfad im Suchraum von einem Tag zu dem anderen zu bestimmen.
Solch ein Algorithmus geht alle Möglichkeiten, und die Wahrscheinlichkeit
jeder Sequenz, durch und liefert die höchstwahrscheinliche Tagsequenz als Output.
Ein allgemeiner Ablauf des stochastischen Taggens wird in der Abbildung 4.3 dargestellt.
Die Einzelheiten einer Variante des stochastischen Taggens wird im Kapitel 4.3 detailliert
besprochen.
Abbildung 4.3: Möglicher Ablauf eines stochastischen Taggers
46

4.3 Der Tree Tagger
Der Tree Tagger [Schmid, 94] ist ein stochastischer Tagger, der im Rahmen des TC-
Projektes 3 am Institut für maschinelle Sprachverarbeitung der Universität Stuttgart von
Helmut Schmid entwickelt wurde. Der Tree Tagger wurde erfolgreich eingesetzt, um deutsche,
englische, französische, italienische und griechische Texte zu annotieren. In diesem
Paragraph wird beschrieben, wie dieser Tagger arbeitet und wie man ihn auf einer neuen
Sprache (etwa Polnisch) trainieren kann. Dieses Kapitel basiert zum grossen Teil auf
den Artikeln von Helmut Schmidt, vor allem [Schmid, 94] und [Schmid, 95], und auf der
Dokumentation der Implementierung des Tree-Tagger, die mit dem Quellcode mitgeliefert
ist.
4.3.1 Arbeitsweise
Der Tree Tagger arbeitet, wie die meisten stochastischen Tagger, mit Wahrscheinlichkeiten.
Die meisten probabilistischen Methoden [DeRose, 1988][Kempe, 1993] basieren auf Markov
Modellen. Diese Methoden generieren eine sehr große Anzahl von Parametern 4 und haben
deswegen Probleme in der richtigen Schätzung von kleinen Wahrscheinlichkeiten aus
einer kleinen Menge des Trainingsmaterials kommt. Um dieses Problem zu beheben und
die Übergangswahrscheinlichkeiten richtig zu bestimmen, wurden bei dem Tree Tagger Entscheidungsbäume
(decision trees) verwendet. Ein Entscheidungsbaum bestimmt die korrekte
Größe des Kontextes (Trigramme, Bigramme, Unigrame) der für die Berechnung von Übergangsfunktionen
verwendet wird.
Bei der Erstellung der Bäume wird in jedem Rekursionsschritt ein Test gebildet. Die
Wahrscheinlichkeit eines bestimmten Trigrammes wird berechnet, indem der entsprechende
Pfad im Baum so lange verfolgt wird, bis ein Blatt gefunden wird. Wollen wir z.B. die Wahrscheinlichkeit
eines Nomens, dem ein Adjektiv und ein Determiner vorausgeht p(NN| DET,
ADJ) müssen wir zuerst einen Test am Wurzelknoten beantworten. Da ein Adjektiv vorausgeht
wird der yes-Pfad gewählt. Da diesem Adjektiv wiederum ein Determiner vorausgeht,
wird dann wieder der yes-Pfad gewählt und das Blatt wird erreicht. Jetzt muss in der Tabelle,
die an dieses Blatt angehängt ist, die Wahrscheinlichkeit des Tags NN nachgeschlagen
werden.
Jedes Wort wird zuerst im Vollformlexikon gesucht, das aus dem getaggten Trainingskorpus
erzeugt werden kann. Sehr oft wird auch ein morphologischer Generator (wie etwa
DMOR [Schiller, 1995]) verwendet um das Vollformlexikon aus einer Wortliste zu generieren.
Das Lexikon, das in dieser Arbeit für das Training verwendet wird, wurde aus annotierten
Korpora generiert - aus dem TAZ Korpus fürs Deutsche, und dem IPI PAN Korpus fürs
Polnische (siehe Kapitel 3.4.2). Wird das gesuchte Wort im Lexikon gefunden, so wird der
Wahrscheinlichkeitsvektor geliefert. Scheitert die Suche, werden alle Großbuchstaben in dem
gesuchten Wort mit Kleinbuchstaben ersetzt und die Suche wir wiederholt. Scheitert die Suche
wieder, wird das Suffixlexikon durchsucht.
Das Suffixlexikon ist der zweite Teil des Lexikons und wird als ein Baum dargestellt.
Jeder Knoten des Baumes (bis auf den Wurzelknoten) ist mit einem Zeichen (character)
beschriftet. Wahrscheinlichkeitsvektoren der Tags wurden den Knoten angehängt. Die Suche
im Suffixlexikon beginnt bei dem Wurzelknoten. In jedem Schritt wird der Ast gewählt, der
mit dem Zeichen beschriftet wurde, der dem nächsten Zeichen im Wort entspricht. Man
beginnt die Analyse des Wortes reading am Wurzelknoten (beschriftet mit #) und folgt
3 Textkorpora und Erschließungswerkzeuge, Land Baden-Würtemberg
4 Bei einem Tagset von 50 Tags, könnten aus einem Trainingsmaterial von 10.000 bis 100.000 Tokens,
125.000 kontextuelle Regeln generiert werden [Schmid, 95]
47

Abbildung 4.4: Entscheidungsbaum des Tree Taggers [Schmid, 94]
dem Pfad mit dem Label g, dann mit dem Label n und erreicht somit den Knoten mit dem
Label i, der ein Blatt ist. Der Wahrscheinlichkeitsvektor, der an diesem Knoten hängt wird
geliefert.
In [Schmid, 95] werden dann weitere Verbesserungen vorgeschlagen, um die Präzision für
Sprachen zu verbessern, für die große annotierte Korpora nicht verfügbar sind. Es wurden
unter anderem folgende Verbesserungen beschrieben:
1. Einsatz eines Präfixlexikons - analog zu Suffixlexikon. In machen Sprachen (etwa
Deutsch) gibt es Flektionspräfixe. Der Einfluss des Wortanfangs auf sein entsprechendes
POS Tag ist in diesen Sprachen größer.
2. Aus nicht getaggten Korpora werden seltene Wörter extrahiert, die weder im Trainingsmaterial
noch im Lexikon auftreten. Dem Tagger stehen in der Originalversion
überhaupt keine Informationen über solche Wörter zur Verfügung (abgesehen vom
Suffix- und Präfixlexikon). Man bestimmt die Tagwahrscheinlichkeiten der unbekannten
Wörter und fügt die Informationen zu dem Vollformlexikon hinzu, um mehr spezifische
Daten über solche Wörter zu haben
3. Die Originalschreibung (Großschreibung) wird im Lexikon eingehalten. Wird eine
Wortform zwei Mal im Lexikon gefunden (einmal klein und einmal großgeschrieben,
wie etwa am Anfang des Satzes) so werden die Wahrscheinlichkeitsvektoren nach relativen
Häufigkeit von zwei Formen geglättet und aufsummiert.
Der Tree Tagger hat einen großen Vorteil gegenüber von klassischen probabilistischen
Ansätzen, die ohne Entscheidungsbäume arbeiten. Er braucht kein großes Trainingsmaterial
um hohe Präzision zu erreichen. Trainiert auf einem Korpus von 20.000 Tokens, hat der
Tree Tagger in der besten Konfiguration eine Präzision von 97.53% [Schmid, 95] erreicht.
48

Abbildung 4.5: Präfixbaum des Tree Taggers [Schmid, 94]
Der Tagger hat aber einen Nachteil. Er setzt die Verfügbarkeit eines morphologischen Analysators
voraus um das Vollformlexikon zu erstellen. In diesem Kapitel werden wir erfahren,
welche Präzision der Tagger für eine Sprache (Polnisch) erzielt, wenn das Vollformlexikon
aus einem Korpus extrahiert worden ist. Der Tagger wird auch unter Verwendung von solch
einem Lexikon für das Deutsche trainiert, um die Ergebnisse für die beiden Sprachen zu
vergleichen.
4.3.2 Training und Tagging
Zum Training und Tagging wird hier die Version des Tree Taggers verwendet, die intern am
Institut für maschinelle Sprachverarbeitung installiert ist. Vier Dateien sind für das Training
erforderlich:
lexicon: ein Vollformlexikon, bei dem jede Zeile einer Wortform entspricht. Jede Zeile sollte
die Wortform und eine Sequenz von Tag-Lemma Paaren enthalten.
open class file: eine Liste von offenen Wortklassen 5
1. STTS fürs Deutsche (siehe Kapitel 3.5.2): ADJA ADJD ADV NE NN TRUNC
VVFIN VVINF VVIZU VVPP VVIMP
2. PJWSTK-Tagset fürs Polnische (siehe Kapitel 3.5.2): V ADJPAP ADJPRP INF
ADVANP ADVPRP VNONP N ADJ ADV
input file: das getaggte Trainingsmaterial.
5 Wortklassen wie Artikel und Präpositionen sind vollständig im Lexikon enthalten und bilden eine Gruppe
von geschlossenen Wortklassen. Wortklassen wie Adjektive oder Substantive sind produktive Wortklassen,
die nicht vollständig im Lexikon enthalten sind, und bilden somit die Gruppe von offenen Wortklassen
49

output file: die Datei, in der die berechneten Parameter gespeichert werden. Diese Datei
wird später zum Taggen verwendet.
4.3.3 Ergebnisse
1. Präzision
Präzision des Tree Taggers für das Deutsche
#Tokens
Trainingskorpus
#Tokens
Lexikon
#Tokens
Testkorpus
Präzision
Bigramme 82174 1810889 8062 93.9345 %
Trigramme 82174 1810889 8062 93.9097 %
4-Gramme 82174 1810889 8062 93.1531 %
Tabelle 4.1: Präzision des Tree Taggers für das Deutsche
Präzision des Tree Taggers für das Polnische
#Tokens
Trainingskorpus
#Tokens
Lexikon
#Tokens
Testkorpus
Präzision
Bigramme 40115 571598 4857 90.1174 %
Trigramme 40115 571598 4857 90.1585 %
4-Gramme 40115 571598 4857 89.9938 %
Tabelle 4.2: Präzision des Tree Taggers für das Polnische
2. Die häufigsten Verwechslungen
Die häufigsten Verwechslungen des Tree Taggers fürs Deutsche
# Verwechslungen Wort Richtiger Tag Falsch getaggt als
19 zu APPR PTKVZ
18 einen ART ADJA
14 rund ADV ADJD
14 das PDAT ART
13 Wie KOUS KOKOM
Tabelle 4.3: Die häufigsten Verwechslungen des Tree Taggers fürs Deutsche
4.4 Transformation-Based Error-Driven Tagger von Eric
Brill
Regelbasierte Ansätze sind seit 1963 bekannt [Klein & Simmons 63]. Sie hatten aber lange
Zeit wesentlich schlechtere Präzision beim Taggen als stochastische Tagger. Das Problem
lag in den Regeln, die manuell von Linguisten erstellt werden mussten. Dieses Kapitel basiert
zum grossen Teil auf den Artikeln von Eric Brill, vor allem [Brill, 92] und [Brill, 93],
und auf der Dokumentation der Implementierung des Brill Taggers, die mit dem Quellcode
mitgeliefert sind.
50

Die häufigsten Verwechslungen des Tree Taggers fürs Polnische
# Verwechslungen Wort Richtiger Tag Falsch getaggt als
74 się PRON ADV
12 można V ADJ
9 ten PRON ADJ
8 tam P N
8 około P ADV
Tabelle 4.4: Die häufigsten Verwechslungen des Tree Taggers fürs Polnische
In [Brill 1992] wurde ein regelbasierter Tagger (der Brill Tagger) vorgestellt, der die Regeln
automatisch aus dem Trainingskorpus ermittelt hat und deren Präzision mit den stochastischen
Taggern verglichen werden konnte. Der vorgestellte Ansatz wurde Transformation-
Based Error-Driven Learning (TBEDL) genannt. Ein unannotierter Text wird beim TBEDL
durch zuerst von einem initial-state Annotierungsmodul analysiert und annotiert. Der
Output wird dann mit der Wahrheit 6 verglichen und Transformationsregeln werden gelernt,
die an dem Output angewandt werden können damit er besser der Wahrheit entspricht. Eine
Anwendung, die aus diesem Ansatz Gebrauch macht muss also folgende Schritte enthalten:
1. Das initial state Annotierungsmodul.
2. Eine Menge von Transformationen, die untersucht werden sollten.
3. Eine Funktion, die das Korpus mit der Wahrheit vergleicht und beste Transformationen
liefert.
Die erste Version des Brill Taggers hat genau nach diesem Schema gearbeitet. Abbildung
4.6 demonstriert diesen Ansatz graphisch.
4.4.1 Initial Tagger
Im ersten Schritt wird jedem Wort sein, in diesem Kontext bestpassender Tag zuordnet,
bestimmt nach den Beobachtungen in einem großen getaggten Korpus. Zwei zusätzliche
Funktionen wurden hier noch eingebaut:
1. Wörter die im Trainingkorpus nicht aufgetreten sind und großgeschrieben werden,
sollten als Eigennamen getaggt werden.
2. Die Wörter die nicht im Trainingskorpus aufgetreten sind, werden mit dem wahrscheinlichsten
Tag für Wörter markiert, die mit 3 gleichen Buchstaben enden. So würde der
Tagger das Wort blahblahung im Deutschen als Nomen taggen. Diese Informationen
werden aus dem Trainingskorpus automatisch ermittelt.
4.4.2 Final State Tagger
Der trainierte Initial State Tagger wird dann verwendet um ein Patch Korpus 7 zu taggen.
Der Output des Initial Taggers wird dann mit dem korrekt getaggten Patch Korpus
verglichen und eine Liste von Tagfehlern wird ermittelt. Solch eine Liste besteht aus
6 eng. the truth [Brill 1992]
7 Das ganze annotierte Trainingskorpus wird in 3 Teile zerlegt, 90% wird zum Training verwendet, 5% ist
zum Testen und 5% ist das Patch Korpus
51

Abbildung 4.6: Ablauf des Brill Taggers [Brill, 92]
Tripels . Jedes Tripel repräsentiert wie oft (number) ein Wort
mit Tag a getaggt wurde, an der Stelle wo es mit Tag b getaggt werden sollte. Es wird
dann berechnet welche Instanziierung der Templates von einer gegebenen Menge zu der
größten Fehlerreduktion beiträgt. Folgende Templates wurden bei der ersten Version des
Brill Taggers verwendet:
Ersetze den Tag a mit Tag b in folgenden Fällen (z und w sind Tags):
1. Das vorhergehende (folgende) Wort ist als z getaggt.
2. Das Wort zwei Stellen davor (danach) ist als z getaggt.
3. Eins der zwei vorhergehenden (folgenden) Wörter ist als z getaggt.
4. Eins der drei vorhergehenden (folgenden) Wörter ist als z getaggt.
5. Das vorhergehende Wort ist als z und das folgende Wort als w getaggt.
6. Das vorhergehende (folgende) Wort ist als z und das Wort zwei Stellen davor (danach)
als w getaggt.
7. Das aktuelle Wort ist (nicht) großgeschrieben.
8. Das vorhergehende Wort ist (nicht) großgeschrieben.
Für jedes Tripel und jede mögliche Instanziierung der Templates wird eine Fehlerreduktion
berechnet, die dem Einsatz des Templates zugrunde liegt. Die Templates, die zur
größten Fehlerreduktion führen werden zu der Liste der Templates hinzugefügt. Die Menge
der Templates entählt im Endeffekt meherer Einträge folgender Art:
52

NN VB PREVTAG TO = Ersetze den Tag NN mit VB wenn das vorhergehende Wort
TO ist.
VBP VB PREV1OR2OR3TAG MD = Ersetze den Tag von VBP mit VB wenn eins
der drei vorhergehenden Wörtern MD ist.
Die gefundenen Templates werden dann auf den Output des Initial Taggers angewendet
um die Fehlerrate zu reduzieren. Wichtig zu bemerken ist auch, dass ein Template, das den
Tag eines Wortes von a in b umwandelt, nur dann angewandt wird wenn das Wort irgendwo
im Trainingskorpus als b getaggt worden ist.
4.4.3 Verbesserungen
In [Brill 1995] wurden unter anderem folgende Verbesserungen des Brill Taggers vorgeschlagen:
Lexikalisierung Kontextuelle Transformationen wurden erweitert, und zwar so, dass der
Tagger Zugriff sowohl auf Wörter als auch auf Tags haben könnte. Folgende Patches wurden
hinzugefügt: Ersetze den Tag a mit Tag b wenn (w, x und z sind Wörter):
1. Das vorhergehende (nachstehende) Wort is w.
2. Das Wort zwei Stellen davor (danach) is w.
3. Eins der zwei vorhergehenden (nachstehenden) Wörter is w.
4. Das aktuelle Wort ist w und das vorhergehende (nachstehende) Wort ist x.
5. Das aktuelle Wort ist w und das vorhergehende (nachstehende) Wort ist als z getaggt.
Folgende neue Templates können fürs Englische extrahiert werden:
1. Ersetze Präposition mit Adverb wenn das Wort zwei Stellen nach rechts ein as ist.
2. Ersetze nicht-3-person Singular im Präsensverb mit seiner Grundform wenn eins der
zwei vorhergehenden Wörtern ein n’t ist
Unbekannte Wörter Folgende weitere Transformationspatches wurden hinzugefügt, damit
der Tagger auch den wahrscheinlichsten Tag Wörtern zuordnen können sollte, die nicht
im Trainingskorpus aufgetreten sind: Ersetze den Tag eines unbekannten Wortes von X mit
Y, wenn (x ist eine Zeichenketten; w ist ein Wort):
1. das Löschen des Präfixes x, |x |

8. das Zeichen z taucht in dem Wort auf.
Die Menge der generierten Templates fürs Englische kann folgende Einträge enthalten:
1. Ersetze den Tag vom normalen Nomen mit normalem Nomen im Plural wenn das Wort
mit einem s’ endet.
2. Ersetze den Tag vom normalen Nomen mit Zahl wenn das Wort das Zeichen . (Punkt)
enthält.
In [Brill 1995] wurde der Brill Tagger mit den vorgestellten Verbesserungen auf 1, 1
Millionen Tokens aus dem Penn Treebank Tagged Wall Street Journal Corpus 8 trainiert. 950
Wörter wurden zum Training verwendet, davon 350.000 um Regel für unbekannte Wörter
zu lernen und 600.000 um kontextuelle Regeln zu ermitteln. Weitere 150.000 wurden zum
Testen verwendet. Es wurden 148 Regeln für unbekannte Wörter und 267 für kontextuelle
Informationen gelernt. Der Tagger hat dabei eine Präzision von 96.5% erreicht. Die höchste
erreichte Präzision des Brill Taggers betrug 99, 1% [Brill 1995]. Es wurde dabei die Methode
der k-besten Tagges verwendet werden (bei 250 Regeln und einem Durchschnitt von 2, 28
pro Wort). Die Präzision beim Taggen von unbekannten Wörtern betrug 85, 0% .
Die linguistischen Informationen werden direkt in einer Menge von nicht stochastischen
Regeln kodiert, die in einer kompakten und verständlichen Form vorliegen. Die Anzahl der
Regeln ist, im Vergleich zu vielen lexikalischen und kontextuellen Wahrscheinlichkeiten bei
stochastischen Ansätzen sehr klein. Es kann auch relativ einfach mit dem Tagger experimentiert
werden - neue Patches können auch von Hand hinzugefügt werden. Es ist wichtig
zu betonen, dass falsche oder fehlerhafte Templates zu keiner Senkung der Präzision führen.
Aus einem fehlerhaften Patch werden dessen Instanziierungen nicht in der Liste des endgültigen
Templates auftreten. Im nächsten Absatz werden wir erfahren welche Fehlerrate der
Brill Tagger für andere Sprachen erreicht (Deutsch, Polnisch), wenn das Trainingsmaterial
relativ klein ist (44.973 Tokens fürs Polnische und 90.234 Tokens fürs Deutsche)
4.4.4 Training und Tagging
Den Quellcode für den regelbasierten Ansatz kann man von der Homepage von Eric Brill
herunterladen 9 . Das Training besteht aus zwei Schritten. Im ersten Schritt werden mit Hilfe
von Perl-Scripten, die zusammen mit dem Tagger geliefert werden, die lexikalischen Regeln
erstellt. Die lexikalischen Regeln werden verwendet um den wahrscheinlichsten Tag für unbekannte
(nicht im Lexikon enthaltene) Wortformen zu ermitteln. Die Ermittlung erfolgt
mit Hilfe von früher erstellten Daten: der Wortliste sowie einer Liste von Bigrammen. Der
Tagger erlernt Regeln in folgender Form (in diesem Fall fürs Polnische):
by addsuf 2 V 634 Wenn die Buchstabenkombination by an Ende des Wortes rangehängt
werden kann, so das ein neues Wort gebildet wird, tagge das Wort als V (Verb). Nach
möglichen Wörtern wird im Lexikon nachgeschlagen, das auch im Laufe des Trainings
erstellt wird.
ć deletesuf 1 INF 372 Wenn das Abschneiden des Suffixes ć eine neue Wortform bildet,
tagge das Wort als INF (Infinitiv)
aby hassuf 3 V 9 Tagge das Wort als V (Verb) wenn es einen Suffix aby hat.
8 urlhttp://www.cis.upenn.edu/ treebank/
9 http://research.microsoft.com/users/brill/
54

Die entstandenen lexikalischen Regeln werden dann verwendet, um einen Teil des Trainingsmaterials
zu taggen (dummy-tagging). Im zweiten Schritt des Trainings werden kontextuelle
Regeln gelernt, indem der dummy-getaggte Text mit dem originalen Trainingstext verglichen
wird. Die kontextuellen Regeln werden aus den eigenen Fehlern erlernt und können
unter anderem folgende Form haben (z.B. fürs Polnische):
ADJPAP ADJ PREVWD w Ersetze den Tag von ADJPAP mit ADJ wenn das vorherige
Wort ein w ist.
ADJPRP ADJ NEXTTAG $. Ersetze den Tag von ADJPRP mit ADJ wenn das nächste
Wort als $. getaggt ist.
PPER N PREV1OR2OR3TAG N Ersetze den Tag von PPER mit N wenn eins von
den 3 vorhergehenden Wörtern als als N getaggte ist.
4.4.5 Ergebnisse
1. Präzision
A a B b C c D d E e F f G g
Polnisch 41465 9403146 7213 3268694 96.7697 % 147 637
Deutsch 82726 9999184 7508 3299590 94.5258 % 281 217
Präzision des Brills Tagger für das Polnische und für das Deutsche
aTokens im getaggten Trainigskorpus
bTokens im ungetaggten Trainigskorpus
cTokens im getaggten Testkorpus
dBigramme ePräzision f Lexikalische Regeln
gKontextuelle Regeln
Die Analyse der Ergebnisse führte zu einer sehr interessanten Beobachtung. Die Präzision/
Fehlerquote hängt nur von dem Start-Tagger mit lexikalischen Regeln ab. Der
zweite Schritt des Taggens, der Final-Tagger der kontextuelle Regeln verwendet, hat
in beiden Sprachen zu überhaupt keinen Verbesserungen beigetragen.
2. Die häufigsten Verwechslungen
Die häufigsten Verwechslungen des Brill Taggers fürs Polnische
# Verwechslungen Wort Richtiger Tag Falsch getaggt als
4 górnicze ADJ N
3 żarty ADJPAP N
3 trzebinia N NUMORD
2 złotem N V
2 wzajemnie ADV N
Tabelle 4.5: Die häufigsten Verwechslungen des Brill Taggers fürs Polnische
4.5 Vergleich der beiden Ansätze
Die Tabelle 4.7 zeigt die wichtigsten Unterschiede, sowie Nachteile und Vorteile des Tree
Taggers und des Brill Taggers.
55

Die häufigsten Verwechslungen des Brill Taggers fürs Deutsche
# Verwechslungen Wort Richtiger Tag Falsch getaggt als
8 Leipzig NE NN
6 Hoechst NE NN
5 werden VAFIN VAINF
4 das PDS ART
4 Vetter NE NN
Tabelle 4.6: Die häufigsten Verwechslungen des Brill Taggers fürs Deutsche
Regelbasierter Tagger Stochastischer Tagger
von Eric Brill
von Helmut Schmid
Erstellung von Korpora Zwei Korpora werden be- Die Erstellung des Lexikons
und Vorbereitung der Danötigt: ein manuell getagg- benötigt einen lexikalischen
tenter
Text und ein ungettag- Generator - Nachteil für Sprater
Text. Die Schwierigkeit chen, für die solch ein Gene-
liegt in der Erstellung des ein- rator nicht existiert. Bei Ex-
Satz-pro-Zeile Formats (sotraktion von Korpora (was
bald die Satzgrenzen nicht sehr lange dauert) erreicht
markiert werden oder bei man eventuell schlechtere Re-
Rohdateien).
sultate.
Aufwand bei Trainings- Das Training benötigt viele Das Training erfolgt sehr
dauer
vorverarbeitete Daten (Bi- schnell und benötigt weniger
gramme, Wort-Tag Listen Dateien (Lexikon, Liste der
etc.). Die Tools werden im
Paket geliefert. Die Erzeu-
offenen Klassen).
gung von Regeln dauert
sehr lange (in Tagen gerechnet)(insbesondere
der
Erstellte Dateien
lexikalischen Regeln; in Perl
implementiert)
Die erstellten Regeln sind les- Die Parameterdatei wird in
bar und können deswegen von binärer Form erzeugt und ist
Hand modifiziert werden. Sie somit unlesbar. Sie ist auch
sind auch sehr klein (lexika- sehr groß (fürs deutsche Trilische
Regeln fürs Polnische grammmodell über 63 MB),
7168 Bytes).
enthält aber das ganze Lexikon.
Fortsetzung auf der nächsten Seite
56

Tabelle 4.7 – Fortsetzung aus der letzen Seite
Regelbasierter Tagger Stochastischer Tagger
von Eric Brill
von Helmut Schmid
Fehlererkennung und Un- Die Formate der Dateien wer- Die Formate, das verwendekompatibilitätden
nicht überprüft. Problete Tagset und das Satzenme
(behebbar im Quellcodezeichen werden überprüft.
de) mit Zeichenkodierungssy- Das Lexikon wird nach dopstemen
(UTF-8, Latin-2). Der pelten Einträgen geprüft. Der
zweite Schritt des Taggens Tree Tagger hat keine Proble-
(Final-Tagger) trägt zu keime mit Zeichenkodierungssynen
Verbesserungen bei. stemen und arbeitet einwanderfrei
sowohl mit UTF-8,
Taggingdauer Es werden alle Dateien (Le-
Latin-2 als auch mit Latin-1.
Nur die Parameterdatei wird
xikon, Bigrammliste, Korpus analysiert. Das Tagging er-
und Regeln) durchsucht. Das
Tagging erfolgt auch in zwei
folgt deutlich schneller.
Phasen (Start-Tagger und
Final-Tagger). Der Taggingprozess
langsam.
ist deswegen sehr
Präzision 96.7697 % fürs Polnische; 93.9345 % fürs Deutsche;
94.5258 % fürs Deutsche 90.1585 % fürs Polnische. Es
muss aber betont werden,
dass die verwendeten Lexika
aus Korpora generiert wurden,
und somit fehlerhafte
Einträge enthalten, die zu
klaren Fehlern führen.
Tabelle 4.7: Vergleich des Brill Taggers und des Tree Taggers
4.6 Zusammenfassung
In diesem Kapitel wurden zwei der wichtigsten Ansätze beim automatischen Part-of-Speech
Tagging beschrieben: ein stochastischer sowie ein regel-basierter Ansatz. Stochastische Tagger
arbeiten mit Wahrscheinlichkeit und Statistik und liefern für jedes Wort das wahrscheinlichste
Tag. Bei regelbasierten Taggern werden die Tags aufgrund von benachbarten
Wortformen, Wortarten sowie Präfixen und Kombinatorik ermittelt. Weiterhin wurden zwei
Tagger detailliert besprochen: der stochastische Tagger von Helmut Schmid, sowie der Tagger
von Eric Brill (Transformation-Based Error-Driven Learning). Beide Tagger habe ich
sowohl fürs Deutsche als auch fürs Polnische trainiert und getestet. Der Brill-Tagger hat
im Allgemeinen bessere Resultate erreicht (96.7697 % fürs Polnische), obwohl die zweite
Etappe des Taggens, der Final-Tagger, zu keinen Verbesserungen beigetragen hat. Der Tree
Tagger liefert ebenfalls ziemlich gute Resultate (93.9345 % fürs Deutsche), wobei für das
Training Lexika verwendet wurden, die klare Fehler enthalten. Der Tree Tagger arbeitet im
Allgemeinen schneller (Training und Tagging) und zuverlässiger. Es sind somit vier Tagging-
Module mit klaren Ergebnissen (zwei fürs Deutsche und zwei fürs Polnische) entstanden,
die in beliebigen TTS-Systemen problemlos eingesetzt werden können.
57

Kapitel 5
Anbindung des
Regelbasierten-Taggers an
TTS-System
5.1 Festival
Festival ist ein allgemeines mehrsprachiges Sprachsynthesesystem, das in der Abteilung für
Rede-Technologie-Forschung (CSTR) an der Universität von Edinburgh entwickelt wurde
und ist ein allgemeines Grundgerüst zum Programmieren von Spracherzeugungssystemen
(Sprachsynthese, wie in Kapitel 2.1 definiert)
Festival ist die bekannteste Open-Source-Sprachsynthese. Festival ist in C++ geschrieben,
mit Scheme-a"hnlicher Sprache gesteuert und als freie Software verfügbar. Sie unterstützt
Englisch, Spanisch und Walisisch. Weitere 9 Sprachen sind von Drittanbietern
erhältlich. Deutsch ist leider nicht darunter.
Die traditionellen Features von Festival beinhalten:
1. External einstellbare sprachenunabhängige Module:
• Phoninventare
• Lexikon
• „letter-to-sound“ (Phon-Graphem) Regeln
• Tokenisierung
• POS-Tagging
• Intonation und Dauer
2. Audiosignalsynthetisatoren
• Diphonbasiert: LPC und PSOLA (Kapitel 2.2.2(
• Unterstützung von MBROLA Datenbanken
• Generalisierung von Statistikmodulen mit Viterbi zur besseren Übersicht
• XML-Unterstützung für Relationen
58

Die aktuelle stabile Version stammt von Juni 1999 (Version 1.4.3). Daneben gibt es seit
Juli letzten Jahres eine Betaversion für Festival 2.0, die bereits sehr stabil ist und die die
Sprachqualität deutlich verbessert. Hierzu wurde ein neues System von sogenannten Multi-
Sync Stimmen entwickelt, die aufgrund detaillierten Daten sehr groß sind und beim ersten
Systemstart einige Zeit zum Laden benötigen. Sprachen mit nicht-lateinischen Alphabeten
werden von Festival zur Zeit nicht oder nur mit größeren Schwierigkeiten unterstützt, da
Unicode-Unterstützung in Festival fehlt. Die neue Version von Festival verwendet auch eine
Syntheseengine, das auf HTS 1 Hidden Markon Modelllen basiert (allgemein HMM-basierte
Synthese genannt). In HMM-basierten Systemen werden spektrale Energie (Vokaltrakt),
Grundfrequenz F0 (Quelle) und Dauer (Prosodie) gleichzeitug von HMMs modeliert. Das
Audiosignal wird dann durch HMMs auf der Basis von „Maximum likelihood criterion“ generiert.
Festival lässt sich als Phonem-Generator mit richtigen Stimmen aus anderen Sprachsynthesen
wie Cepstral 2 oder Mbrola 3 kombinieren. Hierdurch wird oft eine bessere Qualität
erzielt als wenn man diese Stimmen ohne Festival verwendet. Festival hat eine sehr gute
Qualität und einen großen Funktionsumfang, ist aber wegen seiner Größe im Server- oder
Embedded-Bereich z.B. nicht immer die Ideallösung. Weitere Informationen gibt es auf der
Internetseite: http://www.cstr.ed.ac.uk/projects/festival/.
5.1.1 Modularisierung von Festival
Bei der Synthese in Festival wird eine Reihe von Modulen benutzt. Die einzelnen Module
entsprechen im Grossen und Ganzen, der in den Kapiteln 2.2.1 und 2.2.2 vorgestellten Modulariesierung.
In den meisten Fällen wird durch jedes Modul eine neue Relation eingeführt
bzw. eine exisitierende Relation modifiziert. Es werden verschiedene Relationen gebaut,
die Listen von einzelnen Aufbauelementen miteinander verketten. Alle Elemente die zu einer
bestimmten Strukturrelation gehören sind in einer Liste angeordnet. Viele Relationen
bestehen aus verschachtelten Listen, die wiedrum mit Elementen aus anderen Relationen
vernüpft sind - da sie gleiche Elemente enthalten. Beispiele von Festivalrelationen, die für
den Satz „Ich bin ein deutscher Satz“ erzeugt wurden, werden im Anhang B.2 vorgestellt.
Welche Module zur Synthese benutzt werden, hängt von dem aktuellen Äusserungstyp
ab. Festival stellt eine Reihe von Äusserungstypen zur Verfügung: Phrase, Concept, Tokens,
Text, Words usw. Jeder Typ definiert die Module, die durchlafen werden müssen, die
wiederum als Folge eine erwünschte, hierarchisch aufgebaute Relationstruktur liefern. Diese
1 HTS ist eine Sprachsynthese für Japanisch und Englisch. Für Englisch wird intern Festival verwendet.
HTS ist freie Software unter einer BSD-artigen Lizenz und ist in C++ geschrieben. Weitere Informationen
gibt es auf der Internetseite: http://hts.ics.nitech.ac.jp/
2 Cepstral ist eine von mehreren proprietären Sprachsynthesen für Linux. Sie basiert auf Flite und stammt
ebenso wie diese aus Pittsburgh, USA. Cepstral ist neben Englisch, Französisch und Spanisch auch für
Deutsch erhältlich und kostet 29,99 USD. Weitere Informationen gibt es auf der Internetseite: http://epos.
ure.cas.cz/
3 MBROLA ist eine Sprachsynthese von der Fachhochschule Mons in Belgien und unterstützt die größte
Zahl an Sprachen (30 Sprachen einschließlich Deutsch und Polnisch). MBROLA hat zwei Schwierigkeiten, die
der Entwicklung einer benutzerfreundlichen Gesamtlösung entgegenstehen. Erstens ist MBROLA keine vollständige
TTS-Synthese: Zusätzlich wird noch ein Phonemgenerator benötigt, der für die meisten Sprachen
als C-Programm oder als Skript erhältlich ist. Zweitens ist MBROLA Closed Source und darf nur für nichtkommerzielle
und nicht-militärische Zwecke verwendet werden. Der bekannteste deutsche Phonemgenerator
für MBROLA ist Hadifix. Das Hadifix-Programm ist mit Quelltext verfügbar, verwendet aber dieselbe Lizenz
wie MBROLA. Eine bessere Qualität lässt sich erzielen, wenn man die deutschen MBROLA-Stimmen mit
Festival oder Epos zusammen verwendet. Die Festival-Patches zur Unterstützung der deutschen MBROLA-
Stimmen sind mit ebenfalls Quelltext erhältlich, dürfen aber nicht weitergegeben werden und erfordern die
Registrierung mit E-Mail-Adresse. Die Patches beziehen sich außerdem auf eine veraltete Festival-Version
und benötigen mehrerer Änderungen, um sie z.B. auf einem aktuellen SuSE-System kompilieren zu können.
59

Struktur ist die Basis der Synthese. Eine detaillierte Beschreibung aller Typen ist nicht der
Gegenstand dieser Arbeit. Bei dem für typische Synthese in Festival meist verwendetem
Äusserungstyp „Text“ werden folgende Module der Reihe nach durchlaufen (vergleiche mit
den in Kapitel 2.2 vorgestellten Modulen):
1. (Initialize utt)
2. (Text utt)
3. (Token_POS utt)
4. (Token utt)
5. (POS utt)
6. (Phrasify utt)
7. (Word utt)
8. (Pauses utt)
9. (Intonation utt)
10. (PostLex utt)
11. (Duration utt)
12. (Int_Targets utt)
13. (Wave_Synth utt)
5.1.2 Part-of-Speech-Tagging in Festival
Das Part-of-Speech-Tagging findet in Festival im Modul (POS utt) statt. Das Modul (POS
utt) fügt das Merkmal pos hinzu, wie z.B. in der Relation WORD zu sehen ist (vergleiche
Anhang B.2):
((("Ich" ((id "_6") (name "Ich") (pbreak "NB") (pos "N"))))
(("bin" ((id "_7") (name "bin") (pbreak "NB") (pos "V"))))
(("ein" ((id "_8") (name "ein") (pbreak "NB") (pos "ADV"))))
(("deutscher"
((id "_9") (name "deutscher") (pbreak "NB") (pos "ADJ"))))
(("Satz" ((id "_10") (name "Satz") (pbreak "NB") (pos "N")))))
Festival verwendtet zum Taggen verschiedene Methoden, die intern durch den Parameter
„POS_Method“ definiert wird. Die „POS_Method“ kann innerhalb der Sprachdefinition
entsprechend gesetzt werden, kann aber auch im interaktiven Festivalmodus frei geändert
werden. Der Parameter „POS_Method“ ruft im Modul (POS utt) die entsprechende Tagging
Methode, die beliebig definierbar und programmierbar ist. Manche Festivalstimmen verwenden
überhaupt keinen Tagger (No_POS), andere basieren auf einfachen CART Bäumen, die
eine minimale Basiswortartzuweisung durchführen.
Die „POS_Method“ in Festival kann von allen, in Kapitel 4.2 vorgestellten Tagging Ansätzen
Gebrauch machen. Die Festivalversion, die für die Zwecke dieser Arbeit benutzt wurde
60

(und die auf den Rechnern des Instituts für Maschinelle Sprachverarbeitung an Universität
Stuttgart installiert ist), verwendet bei manchen deutschen Stimmen den Tree Tagger
(siehe Kapitel 4.3), implementiert und an Festival von Helmut Schmid und Mark Breitenbuecherangebunden
(Parameter „POS_German“). Der Einsatz von weieteren Tagging
Ansätzen ist möglich, benötigt allerdings eine Verkettungsstelle, soweit sie nicht in Scheme
oder anderen LIPS Dialekten implementiert worden ist. Der Prozess und Ablauf einer
möglichen Anbindung vom Brill Tagger an Festival wurde im Kapitel 5.3 beschrieben.
5.2 Anpassung des Algorithmus von Eric Brill an Festival
Die Implementierung des im Kapitel 4.4 vorgestelltes regelbasierten Tagging Ansatz
(Transformation-Based Error-Driven Tagger) wurde von seinem Entwickler, Eric Brill, im
Jahre 1993 am MIT und an der University of Pennsylvania fertig geschrieben. Der Code
kann heute noch von seiner Homepage des „Department of Computer Science“ unter
http://www.cs.jhu.edu/~brill/ heruntergeladen werden. Das Paket enthält neben dem
Tagger-Code (in C programmiert) auch zahlreiche Werkzeuge (in Perl programmiert), die
während des Trainings zum Einsatz kommen, sowie umfangreiche Dokumentation und fertige
Trainingsdaten fürs Englische. In dieser Arbeit wird lediglich auf die in C programmierten
Taggerdateien eingegangen.
5.2.1 Originalquellcode und Struktur des Algorithmus
Der eigentliche Tagger Code, vollständig in C programmiert, besteht aus drei Teilen:
• tagger.c
• start-state-tagger.c
• final-state-tagger.c
Aufgerufen wird die Hauptfunktion in „tagger.c“, die je nach Parametriesierung für den
weiteren Ablauf sorgt, und entsprechend die Hauptfunktionen in „start-state-tagger.c“ und
„final-state-tagger.c“ (vergleiche Kapitel 4.4.1 und Kapitel 4.4.2), was die Funktionsweise
dieses Tagger-Ansaztes abbildet.
Der vollständige und richtige Aufruf des Taggers sollte (nach der Anleitung) die
Namen der Dateien als Argumente verwenden, die im Laufe des Trainings entstanden sind
(vergleiche Kapitel 4.4.4) und die zum richtigen Taggen benötigt werden (YOUR-CORPUS
ist der Dateiname des Korpuses, der getaggt werden sollte):
tagger LEXICON YOUR-CORPUS BIGRAMS LEXICALRULEFILE CONTEXTUALRULEFILE
Nach dem Aufrufbefehl, können optional, je nach Bedarf verschiedene Parameter (im
Code FLAGS genannt) gesetzt werden, die den Ablauf verändern. Es sind, unter anderem
folgende Parameter möglich:
-w wordlist: ermöglicht die Übergabe einer zusätzlichen Menge von Wortformen (Wort-
Tag Paare), die nicht im LEXICON (Lexikondatei) enthalten sind.
-S: verwendet zum Taggen nur den Start-Tagger (das Argument CONTEXTUALRULE-
FILE entfällt, da es nur Informationen enthält, die für den Final-Tagger brauchbar
sind)
61

-F: verwendet nur den Final-Tagger. In diesem Fall muss der Korpus (YOUR-CORPUS)
vorgetaggt werden; die Tags werden entsprechend der kontextuellen Regeln geändert.
Je nach Parametriesierung werden die Start- und Final-Tagger-Funktionen mit richtigen
Argumenten aufgerufen. Der Tagger, für die Zwecke der Anbindung an Festival im
Kapitel 5.3, sollte mit dem -F Parameter aufgerufen werden. Der Tagger ruft dann intern
den Start-Tagger Algorithmus aus der Datei start-state-tagger.c auf. Folgender Befehl
wird in der Anbindung verwendet:
start-state-tagger LEXICON YOUR-CORPUS BIGRAMS LEXICALRULEFILE
5.2.2 Änderungen des Algorithmus
Damit der Brill Tagger an Festival angebunden werden konnte, musste dessen Algorithmus
modifiziert und an die Gegebenheiten von Festival angepasst werden. Da der „Final State
Tagger“ zu keinen Verbesserungen beim Taggen beigetragen hat (siehe Kapitel 4.4.5), kam
bei der Anbindung ausschliesslich der „Start-State-Tagger“ zum Einsatz. Im Gegensatz zum
ursprünglichen Programmcode, bei dem die Hauptprozedur „tagger.c“ die weiteren Teile, je
nach Paramatern, aufgerufen hat, besteht der modifizierte Code lediglich aus einer Funktion,
die ohne Parametern aufzurufen ist (die Parametern und Dateien sind hard-coded). Die
wichtigsten Änderungen stellt Tabelle 5.1 dar.
Index Originalquellcode Modifizierter Quellcode
1 Die Hauptprozedur nimmt Dateinnamen
als Argumente
2 Die Hauptprozedur kann parametriesiert
werden, so kann z.B. der Parameter
„-S“ ausschliesslich den Start-State-
Tagger aufrufen
3 Die Hauptprozedur (TAGGER) ruft
weitere externe Prozeduren auf. Je nach
Parametern entweder nur den Start-
State-Tagger, oder nur den Final-State-
Tagger, oder beide nacheinander
62
Die Hauptprozedur benötigt keine Dateinamen
als Argumente - die Dateiennamen
sind hard-coded im Quellcode,
als: LEXIKON.BRL, BIGRAMS.BRL
und LEXIKALRULEFILE.BRL. Die
Dateien müssen in dem gleichen Verzeishnis
vorliegen und können ausgetauscht
werden. Die Anbindung an
Festival bleibt somit sprachunabhängig.
Die ausgetauschten Dateien können
auch Informationen enthalten , die aus
dem Trainigsprozess auf einer anderen
Sprache herkommen können
Die Hauptprozedur kann nicht paramatriesiert
werden
Die Hauptprozedur ist ausschliesslich
der Start-State-Tagger und ruft keine
weiteren externen Prozeduren auf.
Fortsetzung auf der nächsten Seite

Tabelle 5.1 – Fortsetzung aus der letzen Seite
Index Origineller Code Modifizierter Code
4 Die Hauptprozedur nimmt Dateinna- Die Hauptprozedur nimmt eine Satzmen
als Argumente
struktur (Struct) von Festival als Argument,
in der die Wörter und die Tags
gespeichert werden können
5 Das Programm kann Texte beliebiger
Länge bearbeiten. Der Textkorpus wird
in Form einer Datei übergeben, die in
einem Satz-pro-Zeile Format vorliegen
muss. Der Korpus muss vortokenisiert
sein und jede Zeile muss mit einem
Leerzeichen enden
6 Das Programm taggt einen Korpus aus
einer Datei
7 Das Programm zeigt die gefundenen
Tags auf dem Standartoutput
8 Das Programm macht eine Reihe von
Ausgaben auf der Standartausgabe, die
dem Ablauf des Programmes entsprechen
typedef struct {
int number_of_words;
/*number of words to be tagged*/
char **word;
/*array of pointers to the words*/
char **tag;
/*array of pointers to the tags*/
} TAGGER_STRUCT;
Das Programm bearbeitet Texte aus einer
extern gelieferten Struktur. Die maximale
Länge des Textes beträgt 50.000
ASCII-Zeichen bzw. maximal 5120
Wörter. Diese Länge entspricht grob 33
bedruckten DIN-A4 Seiten, und sollte
für die meisten TTS-Anwendungen aus-
reichend sein
Das Programm taggt den Text, der in
der Struktur TAGGER_STRUCT, als
ein Array von Zeigern auf die einzelnen
Wörter gespeichert ist
Das Programm speichert die gefundenen
Tags in die TAGGER_STRUCT,
als ein Array von Zeigern
Das Programm macht keine Ausgaben
auf der Standartausgabe
Tabelle 5.1: Änderungen im Brill-Tagger Algorithmus
5.3 Anbindung an Festival
Die Anbindung des Brill Tagger Algorithmus an Festival, in der Form die im Kapitel 5.2.2
vorgestellt wurde, basiert auf der Anbindungsmethode, die (siehe Kapitel 4.3) Helmut
Schmid und Mark Breitenbuecher (Institut für maschinelle Sprachverarbeitung, Universität
Stuttgart, 1998) für den Tree Tagger programmiert haben. Die Funktionen, die ursprünglich
intern mit dem Tree Tagger gearbeitet haben, und damit auch den Text getaggt haben, wurden
so modifiziert und geändert, dass die den Anforderungen des Brill Taggers entsprechen
und mit ihm richtig arbeiten können. Bei der modifizierten Version, ruft die Anbindungsfunktion
intern, anstatt des Tree Taggers, den Brill Tagger vom Kapitel 5.2.2 auf. In diesem
Kapitel werden die wichtigsten Stellen in dem Anbindungmodul besprochen, wobei zu beto-
63

nen ist, dass viele davon lediglich Modifikationen des Quellcodes von Helmut Schmid bzw.
Mark Breitenbuecher sind (die Lizenz gestattet dessen Modifikationen und Verwendung für
wissenschaftliche Zwecke).
5.3.1 Neues POS-Modul
Wie in Kapitel 5.1.2 bereits erwähnt, kann Festival beliebige Methoden zum Taggen verwendet.
Die aktuelle Methode wird durch den Parameter POS_Method intern definiert.
Dieser Parameter kann im interaktiven Modus von Festival mit dem Befehl (Param.get
‘POS_Method) angezeigt werden.
Um eine neue Part-of-Speech Tagging Methode zu benutzen (in diesem Fall ist es der Brill
Tagger) sollte zuerst der richtige Parameter gesetzt werden. Für unseren Zweck nennen wir
ihn POS_Brilltagger. Mit dem Befehl (Param.set’POS_Method’POS_Brilltagger) wird
die Methode als neuer Parameter definiert. Solch eine Definition kann entweder online im interaktiven
Modus stattfinden, oder auch innerhalb der aktuell verwendeten Sprachedefinition,
wie z.B. innerhalb einer theoretischen Funktion (define (polnisch_voice_rulebased)
), z.B.inderDatei voices_polish.scm 4 :
(define (polish_voice_rulebased)
"POLISH_VOICE_RULEBASED uses for tagging a rulebased extern tagging module
from Eric Brill"
...
(Param.set ’Token_Method ...)
(Param.set ’POS_Method ’POS_Brilltagger)
(Param.set ’Phrasify_Method ...)
(Param.set ’Word_Method ...
(Param.set ’Pause_Method ...)
(Param.set ’PostLex_Method ...)
...
)
Anschließend muss die Funktion POS_Brilltagger definiert werden. Die Funktion muss
in der Skriptsprache von Festival, einer LISP-verwandten Sprache die Scheme ähnlich ist,
definiert werden. Festival arbeitet aber in zwei Sprachen, einerseits ist es LISP, andererseits
C/C++, die Sprache, in der auch der Bril Tagger programmiert wurde. Die Definition
von POS_Brilltagger sollte also den zu taggenden Text, von Festival als Satzstruktur
repräsentiert (siehe Kapitel 5.1.1, Seite 59), weiter an eine externe C bzw. C++ Umgebung
leiten, z.B. an die Funktion (Brilltagger_Polish utt). Solch eine Definition sollte bei
den anderen POS-Modulen stehen, z.B. in der Datei polnisch_pos.scm:
(define (POS_Brilltagger utt)
"(POS_Brilltagger utt)
uses the brill tagger. The language of the tagger depends
on the language of the trained BRL files "
(Brilltagger_Polish utt))
4 Alle Festivaldateien, die in SCHEME bzw. LISP programmiert sind, befinden sich im Verzeihnis \lib,
bzw. in seinen sprachspezifischen Unterverzeihnissen z.B. \lib\polish bzw. \lib\german
64

5.3.2 Anbindungsstelle, Ablauf und Funktionsweise
Die Funktion (Brilltagger_Polish utt) befindet sich in einer C bzw. C++ Umgebung,
in einem externen Modul (meistens in dem Verzeichnis \src\modules). Das Modul frrdas
Brill-Tagging kann z.B. im Verzeihnis \src\modules\brilltagger) vorliegen und die
Funktion (Brilltagger_Polish utt) selber kann in der Datei ims_bril_POS.cc definiert
werden. Die Funktion (Brilltagger_Polish utt) ist die eigentliche Verkettungstelle,
zwischen Festival (SCHEME orientiert) und externen Modulen (C/C++ orientiert. Sie
wandelt die SCHEME-Funktion ((Brilltagger_Polish) utt) in die C/C++ Funktion
FT_Brilltagger_Polish um. Das geschieht mit Hilfe folgender C++ Prozedur:
void festival_polish_POS_init (void)
{
festival_def_utt_module ("Brilltagger_Polish", FT_Brilltagger_Polish,
"(POS_Brilltagger UTT)/n calls the Start Brill Tagger for tagging");
}
Die Prozedur FT_Brilltagger_Polish wird ebenfalls in der Datei ims_bril_POS
definiert. Sie bekommt als Argument die interne Festivalstruktur (siehe Kapitel 5.1.1) und
kann auf deren NAME- sowie POS-Features zugreifen. Aus dem Argument werden iterativ
Wörter (Feature NAME) sowie die Interpunktionzeichen ausgelesen:
for (word = (u->relation("Word"))->head(); word && iname();
token= daughter1(word, "Token");
punc = ffeature(word, "R:Token.parent.punc").String();
ts.word[i] = strdup((char *) wort);
if (punc.matches(make_regex("[\\,\\.!\\?\\;\\:]"))) {
i++;
ts.word[i] = strdup((char *) punc);
}
}
Die Wörter werden dann in einer internen Struktur (TAGGER_STRUCT, siehe Tabelle 5.1,
Seite 63) gespeichert, und der externen Brill-Tagger-Funktion zur weiteren Verarbeitung
(zum Taggen) weitergegeben, mit brill_for_festival(ts),wobeibrill_for_festival als void brill_for_festival (TAGGER_STRUCT my_sentence) definiert ist, und in die
entsprechenden Stellen in TAGGER_STRUCT die gefundenen Tags reinschreibt:
for (i=0, word = u->relation("Word")->head();
word && iset("pos",(EST_String) ts.tag[i]);
word=next(word);
}
}
Den ganzen Ablauf der Anbindung stellt die Abbildung 5.1, auf Seite 66, grafisch dar.
65

Abbildung 5.1: Prozess der Anbindung von dem Brill Tagger an Festival
66

Kapitel 6
Zusammenfassung und
Kommentar
6.1 Zusammenfassung
In Kapitel 1.2 wurden für diese Arbeit verschiedene Ziele gesetzt. Die Struktur der Arbeit
wurde an das Hauptziel angepasst - Fertigstellung eines neuen Moduls für die automatische
Zuweisung von Wortarten (innerhalb der Arbeit als „Tagging“ definiert und verwendet). Dieses
Modul sollte ziemlich kompakt und direkt in einem TTS-System verwendbar sein. Dieses
Ziel wurde erreicht. Es ist ein Modul enstanden, das einen regelbasierten Ansatz (den Brill-
Tagger) verwendet um die polnischen Texte mit einer Präzision von 96,7697 % zu taggen.
Jegliche Änderungen wurden besprochen, so dass dieses Modul direkt in Festival, einem
mehrsprachigen Open-Source-Synthesesystem, direkt angebunden werden konnte. Zusätzlich
dazu wurden andere Tagging Systeme vorgestellt welche auf polnischen und deutschen
Textmaterialien trainiert worden sind. Nach dieser Arbeit, können also zwei verschiedene
Taggermodule, je für zwei Sprachen, direkt in Festival angebunden und in einem größerem
Syntheseprojekt als POS-Modul verwendet werden. Weiterhin wurde im Kapitel 5 eine Anbindungsmethode
vorgestellt, nach deren Prinzipen auch andere Module, die in C/C++
programmiert sind, ohne Probleme an Festival angebunden werden können. Das entstandene
Modul ist sprachenunabhängig und kann sofort für andere Sprachen einegsetzt werden,
sobald die Trainingsdaten für diese Sprache vorliegen. Es reicht lediglich die drei Dateien
mit der Erweiterungen BRL mit neuen Dateien zu ersetzen.
Im Kapitel 2 wurde sehr allgemein der Aufbau und die Probleme eines Sprachsynthesesystems
vorgestellt. Das Modul, das für das POS-Taggen zuständig ist, ist nur ein Teil eines
grossen Systemes und dient meistens nur einer spezifischen Aufgabe — der Zuweisung von
Wortklassen. Im Kapitel 3 und 4 wurde dann gezeigt wie komplex die Vorbereitung dieses
kleines Modules sein kann und somit die Mächtigkeit von Sprachsyntese demonstriert. Kapitel
3 beschreibt den Prozess der Erstellung und die Komplexität von Korpora, die lediglich
für einen Teil des Taggertrainings verwendet werden. Es wurden der Aufbau, Konstruktion
und Datenerschliessung von kleinen und großen Korpora besprochen. Weiterhin wurden hier
kurz Tagsets bestimmt, Mengen von möglichen Wortartentypen und deren Formalisierung
für die Zwecke der Sprachsynthese. Im Kapitel 4 wurden allgemein verschiedene Taggingansätze
besprochen. Der Aufbau und die Funktionsweise von zwei bekannten Taggingsystemen,
dem Treetagger von Helmut Schmid und dem Brill-Tagger von Eric Brill, wurden sehr
ausführlich präsentiert. Die Präzision und der Ablauf der beiden Taggersysteme, die ent-
67

sprechend einem regelbasierten und einem stochastischen Ansatz folgen, wurden dann direkt
verglichen. Mit Hilfe von, mit beiden Implementierungen mitgelieferten Trainingstools wurden
dann Daten für das Polnische und das Deutsche erzeugt. Im Kapitel 5 wurde technisch
sehr detailliert auf den Brill Tagger und Festival eingegangen; die für die Anbindung an
Festival benötigten Änderungen im Quellcode besprochen, sowie eine Anbindungsmethode
an Festival vorgeschlagen.
Im Laufe der Arbeit wird auf verschiedene Bereiche der Linguistik, Computerlinguistik,
Statistik, Programmiersprachen, Zeichenkodierungsystemen u.a. eingegangen. Es wurden
auch verschiedene computerlinguistische Methoden und Werzkzeuge besprochen. Somit
wurde das zweite Ziel, das Nebenziel dieser Arbeit erreicht — die Vielseitigkeit der Wissenschaft
der Computerlinguistik zu präsentieren, und einen groben Übersicht über dieses Feld
zu leisten.
Diese Arbeit hat sowohl theoretische als auch praktische Techniken behandelt. Sie hat
einerseits Elemente der Fachgebiete der Computerlinguistik diskutiert wie Phonetik und
Phonologie (Kapitel 2), Morphologie (Kapitel 3), Syntax (Kapitel 4) und Statistik (Kapitel
4); andererseits aber die Anwendungsgebiete und verwendeten Techniken wie Sprachsynthese
(Kapitel 2 und 5), Generierung und Verarbeitung von Korpora und Extraktion von Daten
(Kapitel 3), Generierung von Regeln (Kapitel 4) sowie zahlreiche Programmiertechniken,
die den Techniken zu Hilfe kommen.
6.2 Zukunft der Sprachsynthese
Wir haben in dieser Arbeit ein grosses Gebiet der Computerlinguistik kennengelernt — die
Sprachsynthese. Sprachsynthese die von Thierry Dutoit, 1997 als „the production of speech
by machines, by way of the automatic phonetization of the sentences to utter“ und in dieser
Arbeit als der Versuch eine der komplexesten kognitiven Fähigkeiten der Menschen, die
Fähigkeit zu sprechen, zu modellieren. Ohne Zweifel lässt sich (wie in der voliegenden Arbeit
gezeigt) feststellen, das Sprachsynthese im allgemeinen ein sehr komplexes Problem ist. Ist
es aber möglich „das menschliche Sprechen“ mit formalen, computerlinguistischen Methoden
so zu modellieren, dass es sich von einer „natürlichen“, und von einem gesunden Menschen
produzierten Sprache nicht unterscheidet? Wenn die Antwort auf die Frage „nein“ lautet,
könnte man wiederum fragen: „Warum?“ bzw. „Welche Merkmale der Sprache, die deren
Natürlichkeit bestimmen, lassen sich nicht formalisieren?“. Würde andersrum die Antwort
„ja“ lauten, fällt sofort die Frage ein: „Warum gibt es bis heute kein System, dass jegliche
sprachliche Äusserungen natürlich synthetisieren kann?“ bzw. „Was muss noch erforscht
werden, damit man alle Merkmale der natürlichen Sprache modellieren könnte?“. Es wird in
diesem Kapitel versucht, eine Stellung zu den oben formulierten Fragen zu nehmen.
Frage: „Wie sieht die Zukunft der Sprachsynthese aus und ist es überhaupt möglich
die Sprache so zu modellieren, dass es sich völlig natürlich in allen, in der natürlichen
Sprache vorkommenden Kombinationen, wie eine natürliche Sprache anhört?“. Wäre ich
dazu gebracht, diese Frage beantworten zu müssen, würde ich zuerstmal den zweiten Teil
der Frage bestätigend beantworten. Ja, es ist meiner Meinung nach möglich, nur nicht ohne
riesigen Aufwand in der Forschung verschiedener Gebiete.
Einerseits ist wichtig zu betonen, dass Sprache ein untrennbarer Teil der Menschen ist
und ohne Menschen nicht existieren kann.. Man könnte eventuell bemerken, dass es sich
bei der Sprachsynthese nicht um die Sprache selbst, sondern um die Fähigkeit sprechen zu
können (in dem Sinne „Laute zu produzieren“) handelt. Somit kann es auch ohne Menschen
existieren (z.B. in der Form einer Audioaufnahme). Die Fähigkeit „Laute produzieren zu
können“ ist definitiv keine instruktionell erlernte Fertigkeit. Sie basiert auf Erlebnissen aus
68

der Kindheit, langjährigem unbewussten (Sprache eingeboren?) Training der Sprechorgane
und Erfahrungen, und ist daher ein Teil der Sprache (in der abstrakten, psychischen Bedeutung),
ein Teil der Psyche eines Menschen. Soeben kann diese Fähigkeit nicht ohne Menschen
existieren, da nur die Menschen solch einen komplexen phonetischen Apparat haben und auf
so einer komplexen Weise miteinander kommunizieren.
Die Sprachsynthese versucht diese Tatsache zu umgehen, und modelliert die Merkmale in
der produzierten Äusserungen und nicht die Sprache selbst. Vielleicht heisst die Wissenschaft
deswegen „Computerlinguistik“ und nicht „Computerpsychologie“? Wie kann man aber die
Sprache selbst modellieren, wenn es dafür keine entsprechenden und allgemein akzeptierten
Modelle gibt? Die Wissenschaft der „Psycholinguistik“ befindet sich noch momentan eigentlich
in dem Entwicklungsstadium, in dem es nur ein logisch gesehen akzeptables Modell der
Sprache gibt, das erste und einzige „Parameter setting model“. Es wurde 1979 zusammen mit
der bekannten Vorlesungen zu „Government and Binding“ von Noam Chomsky vorgestellt,
und gilt als der Anfang der eigentlichen Psycholinguistik.
Mit einem begrenzten Instrumentarium von grammatikalischen Regeln und einer
endlichen Anzahl von Wörtern kann eine unbegrenzte Menge von Sätzen gebildet
werden, darunter solche, die noch nie zuvor gesagt wurden. Die Fähigkeit,
unsere Äußerungen auf diese Weise zu strukturieren, ist angeboren und somit ein
Teil des genetischen Programms des Menschen. Dieses wird Universalgrammatik
genannt. Wir sind uns dieser Strukturprinzipien im Allgemeinen genausowenig
bewusst wie wir es uns der meisten unserer biologischen und kognitiven Eigenschaften
sind.(Quelle: http://de.wikipedia.org/wiki/Noam_Chomsky)
Ob die Theorie gilt oder nicht, lässt sich schlecht verifizieren, nichtdestotrozt berufen sich bis
heute viele Wissenschaftler bei ihren Überlegungen darauf. Die psychischen und mentalen
Aspekte der Sprache sollte aber auch bei der Entwicklung von Sprachsynthesesystemen nicht
vergessen werden. Um die Natürlichkeit der Synthese zu erreichen müssen diese Aspekte
berücksichtigt werden. Es ist noch aber zu früh um Annahmen zu nehmen, was in der
Zukunft passieren könnte.
Andererseits könnten, oder sollten die Erforschungen aus dem Gebiet der Neurolinguistik
auch in der Sprachsynthese ihre Anwendungen finden. Bei der Neurolinguistik handelt es
sich um den interdisziplinären Zusammenschluss von Teilen der Linguistik, Psycholinguistik,
Sprachphilosophie, Neurobiologie, Neurologie, Neuropsychologie und Neuroinformatik. Sie
versucht also die Sprache in dem menschlichen, gesunden Gehirn zu lokalisieren und die
zu beschreiben, und könnte wichtige Hinweise bezüglich der menschlichen Verarbeitung von
Sprache liefern, was wiederum zur Natürlichkeit der Synthese beitragen wird.
Die Sprachsynthese heutzutage versucht lediglich menschliche Äusserungen nachzubilden
und nicht die menschliche Sprache selbst. Das scheint ein sinvoller Ansatz zu sein, da die
diese Äusserungen die einzigen Elemente der Sprache sind, die man tatsächlich untersuchen
und klare Ergebnisse bekommen kann. Ich wiederhole hier nochmal den Anfang des Zitates
von oben:
Mit einem begrenzten Instrumentarium von grammatikalischen Regeln
und einer endlichen Anzahl von Wörtern kann eine unbegrenzte Menge von
Sätzen gebildet werden, darunter solche, die noch nie zuvor gesagt wurden.
Im Kapitel 3 wird ein Experiment beschrieben, bei dem Texte analysiert werden, wobei
geprüft und abgespeichert wird, wieviele neue Wortformen bei einer bestimmten Menge
vom neuen Text vorkommen, im Vergleich zu einer abgespeicherten Menge von Wortformen,
die von anderen Texten kommen. Das Experiment hat sich verschiedene, und nicht
69

alle Wortformen angeschaut. Es wurde da gezeigt, dass sogar nach 90GB analysiertem Text
(was 9.000.000 Zeichen Text entspricht), sogar in einem kurzen Text viele neue Wörter verkommen
können. Für die die Sprachsynthese sind aber die Kombinationen von Wortformen,
und nicht die Wortformen selbst, relevant. Das Problem sieht also umso schwieriger. Rein
kombinatorisch gesehen gibt es eine unendliche Anzahl von möglichen Kombinationen. Die
Sprachsynthese müsste, um immer völlig natürliche Sprache zu erzeugen, alle diese Kombinationen
kennen. Zusammen mit den immer schnelleren Rechnern, die immer mehr Daten
speichern und bearbeiten können, wird auch die synthetisierte Sprache immer besser. Werden
die Computer eines Tages dazu fähig, online auf riesige (zu lesen: „unendlich“ große)
Korpora und Informationsammlungen problemlos zuzugreifen, kann man sich, mindestens
rein theoretisch den Idealfall der Unit Selection Synthese vorstellen, nämlich dass der zu
synthetisierte Satz schon in solch einer Form in der Datenbank vorkommt, und es somit
während der Synthese zu keiner Verkettung der Sprachteile kommen muss. Die Geschwindigkeit
der Rechner und die Kapazität wird die Zukunft der Sprachsynthese definieren.
Wann wird es also möglich sein, dass die Menschen eine natürliche Sprache von einer
computergenerierten Sprache nicht unterschieden werden? Meiner Meinung nach, ist es nicht
anderes als die Frage, wann die Rechner den Turing-Test bestehen, da eine natürliche Sprache
in der Originalformulierung des Testes, die 1950 von Alan Turing in seiner Publikation
„Computing machinery and intelligence“ für das Bestehen notwendig ist. Der Rechner sollte,
laut Raymond Kurzweil 1 diesen Test im Jahre 2029 bestehen (Ray Kurzweil, Kurzweil
Foundation).
„Scientists have already reverse-engineered two dozen of the several hundred
regions of the human brain; we’ll understand its principles of operation and be
in a position to re-create its powers in synthetic substrates well within 30 years.
But we won’t program human intelligence link by link in some massive expert
system. Nor will we simply set up a single genetic algorithm and have intelligence
at human levels automatically evolve itself. Rather, we will set up an intricate
hierarchy of self-organizing systems, based largely on the reverse-engineering
of the human brain, and then provide the computer entity with an education,
which, given the increasing power of machines, can proceed hundreds if not
thousands of times faster than the comparable process for humans.“ (Quelle:
http://www.wired.com/wired/archive/10.05/longbets.html?pg=5).
1 Raymond Kurzweil ist ein Pionier der optischen Texterkennung (OCR), Text-To-Speech Synthese , Spracherkennung,
Flachbett-Scannertechnologie und im Bereich elektronischer Musikinstrumente, insbesondere
den Keyboards. Außerdem ist er der Autor der Bücher „The Age of Intelligent Machines“ und „The Age of
Spiritual Machines“ (deutscher Titel: "Homo S@piens"). Kurzweil gilt als einer der bedeutendsten Visionäre
der KI (Künstlichen Intelligenz).
70

Anhang A
Tagsets
A.1 Modifiezierte S-Tagset mit IPI PAN Zuordnung
Tag Bedeutung Beispiele IPI PAN
V Verb siedze fin: finites Verb nicht in
der Vergangenheitsform
będzie bedzie: Zukunftsform
-my
von być (sein)
aglt: Suffixe des Verbes
być[PL], sein[DE]
próbowała praet: Pseudopartizip
zapiewaj impt: Befehlsform, Imperativ
winien winien: die Lexeme winien,
powinien, rad enthalten,
die nur analytische
Zeitformen bilden
ADJPAP adjektivisches Passivpar- chowany ppas: adjektivisches Pastizipsivpartizip
ADJPRP adjektivisches Aktivparti- celujący pact: adjektivisches Akziptivpartizip
INF Infinitivform biegać inf: Infinitivform
ADVANP adverbiales Perfektparti- ujżawszy pant:adverbiales Perfektzippartizip
ADVPRP adverbiales Präsensparti- celując pcon:adverbiales Präzipsenspartizip
VNONP unpersönliche Verbform mówiono imps:unpersönliche Verbform
N Nomen pies subst: Nomen
ludzie depr:
men
depratiatives No-
Manhattan xxs:fremdes Wort an der
Position
phrase
einer Nominal-
Forsetzung auf der nächsten Seite
71

Tabelle A.1 – Forsetzung aus der letzen Seite
Tag Bedeutung Beispiele IPI PAN
chowanie ger: Ein vom Adjektiv gebildetes
Substantiv
ADJ Adjektiv biały adj:Adjektiv
historyczno adja: unflektierbares Adjektiv
prostu adjp: postpräpositionales
Adjektiv
ADV Adverb blisko adv: Adverb
PRON Pronomen ty ppron12: Pronomen 1.
und 2. Person
on ppron3:
Person
Pronomen 3.
siebie siebie: Pronomen siebie
INTER Interjektion ach, och, ech qub: unflektierbare Form,
die zu anderen Kategorien
nicht passt
(INTER+PART) Partikel nie, tu, nieco
NUM
(NUM+
Numeral tyle
NUMCRD+ Kardinalzahl dziesięć num: Kardinalzahl
NUMORD) Ordinalzahl dwunastego
Sammelzahl pięćdziesięciu numcol:Sammelzahl
P Präposition przy, od prep: Präposition
CONJ Konjuktion i,a, oraz conj Konjunktion
SENT ($.) Interpunktion
des Satzes
am Ende ., !, ? interp Interpunktion
$, Interpunktion
des Satzes
innerhalb komma, -, interp Interpunktion
Tabelle A.1: Unifikation von PJWST-Tagset und IPI PAN Tagset
72

Anhang B
Relationstrukturen und Festival
B.1 Interne Festivalsatzstruktur im Fringe-Format
Interne Festivalsatzstruktur des deutschen Satzes „Ich bin ein deutscher Satz“ nach der
linguistischen und akkustischen Analyse; Fringe-Format, Ausschnitt:
EST_File utterance
DataType ascii
version 2
EST_Header_End
Features max_id 45 ; type Text ; iform "\"Ich bin ein deutscher Satz\"" ;
Stream_Items
1 id _1 ; name Ich ; whitespace "" ; prepunctuation "" ;
2 id _2 ; name bin ; whitespace " " ; prepunctuation "" ;
3 id _3 ; name ein ; whitespace " " ; prepunctuation "" ;
4 id _4 ; name deutscher ; whitespace " " ; prepunctuation "" ;
5 id _5 ; name Satz ; whitespace " " ; prepunctuation "" ;
6 id _10 ; name Satz ; pbreak NB ; pos N ;
7 id _9 ; name deutscher ; pbreak NB ; pos ADJ ;
8 id _8 ; name ein ; pbreak NB ; pos ADV ;
9 id _7 ; name bin ; pbreak NB ; pos V ;
10 id _6 ; name Ich ; pbreak NB ; pos N ;
11 id _11 ; name phrase ;
12 id _12 ; name IC ; stress 1 ;
13 id _15 ; name bIn ; stress 1 ;
14 id _19 ; name aIn ; stress 1 ;
15 id _22 ; name dOY ; stress 1 ;
16 id _25 ; name tS6 ; stress 0 ;
17 id _30 ; name zats ; stress 1 ;
18 id _35 ; name _ ; dur_factor -0.11171 ; end 0.576103 ;
19 id _39 ; end 0.598103 ; name ? ; dur_factor -0.233915 ;
20 id _13 ; name I ; dur_factor 1.11578 ; end 0.68762 ;
21 id _14 ; name C ; dur_factor -0.254969 ; end 0.772306 ;
22 id _16 ; name b ; dur_factor -0.162112 ; end 0.834752 ;
23 id _17 ; name I ; dur_factor 0.11924 ; end 0.901212 ;
24 id _18 ; name n ; dur_factor 0.0406929 ; end 0.969725 ;
73

25 id _40 ; end 0.991725 ; name ? ; dur_factor 0.0249055 ;
26 id _20 ; name aI ; dur_factor -0.441345 ; end 1.10944 ;
27 id _21 ; name n ; dur_factor -0.589756 ; end 1.15599 ;
28 id _23 ; name d ; dur_factor -0.49279 ; end 1.19451 ;
29 id _24 ; name OY ; dur_factor -0.371358 ; end 1.32732 ;
30 id _26 ; name t ; dur_factor 0.192649 ; end 1.39517 ;
31 id _27 ; name S ; dur_factor -0.0506968 ; end 1.49355 ;
32 id _28 ; name "6" ; dur_factor -0.235125 ; end 1.5518 ;
33 id _31 ; name z ; dur_factor 0.321983 ; end 1.6493 ;
34 id _32 ; name a ; dur_factor -0.0253699 ; end 1.74031 ;
35 id _33 ; name t ; dur_factor -0.351615 ; end 1.79246 ;
36 id _34 ; name s ; dur_factor 0.485125 ; end 1.91015 ;
37 id _36 ; name _ ; dur_factor -0.079054 ; end 2.49155 ;
38 id _37 ; name L*H ; end 0.772306 ; start 0.576103 ;
39 id _38 ; name H*L ; end 1.91015 ; start 1.5518 ;
40 id _44 ; f0 85.7779 ; pos 1.70261 ;
41 id _43 ; f0 96.8459 ; pos 1.60835 ;
42 id _42 ; f0 106.242 ; pos 0.871015 ;
43 id _41 ; f0 89.7162 ; pos 0.651813 ;
44 id _45 ; wave "[Val wave]" ;
End_of_Stream_Items
B.2 Interne hierarchnisch aufgebaute Festivalsatzstruktur,
die entsprechend der Module des Äusserungstypen
TEXT erzeugt wurde
Bei der Verwendung des Types TEXT werden folgende Relationen erzeugt:
(Token
Word
Phrase
Syllable
Segment
SylStructure
IntEvent
Intonation
Target
Wave)
1. Relation (Token)
(utt.relation_tree utt ’Token)
((("Ich" ((id "_1") (name "Ich") (whitespace "") (prepunctuation "")))
(("Ich" ((id "_6") (name "Ich") (pbreak "NB") (pos "N")))))
(("bin" ((id "_2") (name "bin") (whitespace " ") (prepunctuation "")))
(("bin" ((id "_7") (name "bin") (pbreak "NB") (pos "V")))))
74

(("ein" ((id "_3") (name "ein") (whitespace " ") (prepunctuation "")))
(("ein" ((id "_8") (name "ein") (pbreak "NB") (pos "ADV")))))
(("deutscher"
((id "_4") (name "deutscher") (whitespace " ") (prepunctuation "")))
(("deutscher"
((id "_9") (name "deutscher") (pbreak "NB") (pos "ADJ")))))
(("Satz"
((id "_5") (name "Satz") (whitespace " ") (prepunctuation "")))
(("Satz" ((id "_10") (name "Satz") (pbreak "NB") (pos "N")))))
2. Relation (Word)
(utt.relation_tree utt ’Word)
((("Ich" ((id "_6") (name "Ich") (pbreak "NB") (pos "N"))))
(("bin" ((id "_7") (name "bin") (pbreak "NB") (pos "V"))))
(("ein" ((id "_8") (name "ein") (pbreak "NB") (pos "ADV"))))
(("deutscher" ((id "_9") (name "deutscher") (pbreak "NB") (pos "ADJ"))))
(("Satz" ((id "_10") (name "Satz") (pbreak "NB") (pos "N")))))
3. Relation (Phrase)
(utt.relation_tree utt ’Phrase)
((("phrase" ((id "_11") (name "phrase")))
(("Ich" ((id "_6") (name "Ich") (pbreak "NB") (pos "N"))))
(("bin" ((id "_7") (name "bin") (pbreak "NB") (pos "V"))))
(("ein" ((id "_8") (name "ein") (pbreak "NB") (pos "ADV"))))
(("deutscher"
((id "_9") (name "deutscher") (pbreak "NB") (pos "ADJ"))))
(("Satz" ((id "_10") (name "Satz") (pbreak "NB") (pos "N"))))))
4. Relation (Syllable)
(utt.relation_tree utt ’Syllable)
((("IC" ((id "_12") (name "IC") (stress 1))))
(("bIn" ((id "_15") (name "bIn") (stress 1))))
(("aIn" ((id "_19") (name "aIn") (stress 1))))
(("dOY" ((id "_22") (name "dOY") (stress 1))))
(("tS6" ((id "_25") (name "tS6") (stress 0))))
(("zats" ((id "_30") (name "zats") (stress 1)))))
usw.
B.3 Beispielsitzung und Tagging im Festival
wiacekmz@pinguin /home/users7/wiacekmz/fest/festival/bin 205: clear
1. Festival wird gestartet.
75

wiacekmz@pinguin /home/users7/wiacekmz/fest/festival/bin 206: ./festival
German Festival 1.2 (1.9.5):release Oct 2004
Festival Speech Synthesis System 1.96:beta July 2004
Copyright (C) University of Edinburgh, 1996-2004. All rights reserved.
For details type ‘(festival_warranty)’
2. POS Methode wird definiert.
festival> (define (POS_Brilltagger utt)
> "(POS_Brilltagger utt)
> uses the brill tagger. The language of the tagger depends
on the trained BRL files "
> (Brilltagger_Polish utt))
#
3. POS Methode wird gesetzt.
festival> (Param.set ’POS_Method ’POS_Brilltagger)
#
4. Variable utt wird gesetzt.
festival> (set! utt (Utterance Text "Festival jest bardzo
dobrym programem, a Brill najlepszym taggerem."))
#
5. Vorhandene Relationen werden angezeigt .
festival> (utt.relationnames utt)
nil
6. TTS Module werden von Hand ausgeführt. Neue Relationen
werden hinzugefügt
festival> (Initialize utt)
#
festival> (utt.relationnames utt)
nil
festival> (Text utt)
#
festival> (utt.relationnames utt)
(Token)
festival> (Token_POS utt)
#
festival> (utt.relationnames utt)
(Token)
festival> (Token utt)
76

#
festival> (utt.relationnames utt)
(Token Word)
6. Relation Word wird ausgegeben.
festival> (utt.relation_tree utt ’Word)
((("Festival" ((id "_10") (name "Festival"))))
(("jest" ((id "_11") (name "jest"))))
(("bardzo" ((id "_12") (name "bardzo"))))
(("dobrym" ((id "_13") (name "dobrym"))))
(("programem" ((id "_14") (name "programem"))))
(("a" ((id "_15") (name "a"))))
(("Brill" ((id "_16") (name "Brill"))))
(("najlepszym" ((id "_17") (name "najlepszym"))))
(("taggerem" ((id "_18") (name "taggerem")))))
7. Relation Token wird ausgegeben.
festival> (utt.relation_tree utt ’Token)
((("Festival"
((id "_1") (name "Festival") (whitespace "") (prepunctuation "")))
(("Festival" ((id "_10") (name "Festival")))))
(("jest"
((id "_2") (name "jest") (whitespace " ") (prepunctuation "")))
(("jest" ((id "_11") (name "jest")))))
(("bardzo"
((id "_3") (name "bardzo") (whitespace " ") (prepunctuation "")))
(("bardzo" ((id "_12") (name "bardzo")))))
(("dobrym"
((id "_4") (name "dobrym") (whitespace " ") (prepunctuation "")))
(("dobrym" ((id "_13") (name "dobrym")))))
(("programem"
((id "_5")
(name "programem")
(punc ",")
(whitespace " ")
(prepunctuation "")))
(("programem" ((id "_14") (name "programem")))))
(("a" ((id "_6") (name "a") (whitespace " ") (prepunctuation "")))
(("a" ((id "_15") (name "a")))))
(("Brill"
((id "_7") (name "Brill") (whitespace " ") (prepunctuation "")))
(("Brill" ((id "_16") (name "Brill")))))
(("najlepszym"
((id "_8") (name "najlepszym") (whitespace " ") (prepunctuation "")))
(("najlepszym" ((id "_17") (name "najlepszym")))))
(("taggerem"
77

((id "_9")
(name "taggerem")
(punc ".")
(whitespace " ")
(prepunctuation "")))
(("taggerem" ((id "_18") (name "taggerem"))))))
8. POS Methode wird abgefragt.
festival> (Param.get ’POS_Method)
"POS_Brilltagger"
9. Tagging Modull, der Brill Tagger wird ausgeführt.
Relation POS wird hinzugefügt.
festival> (POS utt)
#
10. Relation Word wird nochmal ausgegeben .
festival> (utt.relation_tree utt ’Word)
((("Festival" ((id "_10") (name "Festival") (pos "N"))))
(("jest" ((id "_11") (name "jest") (pos "V"))))
(("bardzo" ((id "_12") (name "bardzo") (pos "ADV"))))
(("dobrym" ((id "_13") (name "dobrym") (pos "ADJ"))))
(("programem" ((id "_14") (name "programem") (pos "N"))))
(("a" ((id "_15") (name "a") (pos "CONJ"))))
(("Brill" ((id "_16") (name "Brill") (pos "N"))))
(("najlepszym" ((id "_17") (name "najlepszym") (pos "ADJ"))))
(("taggerem" ((id "_18") (name "taggerem") (pos "N")))))
festival> (utt.relationnames utt)
(Token Word)
11. Relation Token wird nochmal ausgegeben .
festival> (utt.relation_tree utt ’Token)
((("Festival"
((id "_1") (name "Festival") (whitespace "") (prepunctuation "")))
(("Festival" ((id "_10") (name "Festival") (pos "N")))))
(("jest"
((id "_2") (name "jest") (whitespace " ") (prepunctuation "")))
(("jest" ((id "_11") (name "jest") (pos "V")))))
(("bardzo"
((id "_3") (name "bardzo") (whitespace " ") (prepunctuation "")))
(("bardzo" ((id "_12") (name "bardzo") (pos "ADV")))))
(("dobrym"
78

((id "_4") (name "dobrym") (whitespace " ") (prepunctuation "")))
(("dobrym" ((id "_13") (name "dobrym") (pos "ADJ")))))
(("programem"
((id "_5")
(name "programem")
(punc ",")
(whitespace " ")
(prepunctuation "")))
(("programem" ((id "_14") (name "programem") (pos "N")))))
(("a" ((id "_6") (name "a") (whitespace " ") (prepunctuation "")))
(("a" ((id "_15") (name "a") (pos "CONJ")))))
(("Brill"
((id "_7") (name "Brill") (whitespace " ") (prepunctuation "")))
(("Brill" ((id "_16") (name "Brill") (pos "N")))))
(("najlepszym"
((id "_8") (name "najlepszym") (whitespace " ") (prepunctuation "")))
(("najlepszym" ((id "_17") (name "najlepszym") (pos "ADJ")))))
(("taggerem"
((id "_9")
(name "taggerem")
(punc ".")
(whitespace " ")
(prepunctuation "")))
(("taggerem" ((id "_18") (name "taggerem") (pos "N"))))))
festival>
79

Literaturverzeichnis
[Wahrig, 1996] Wahrig. „Deutsches Wörterbuch“. Bertelsmann Lexikon Verlag GmbH, 1996.
[Christ u.a., 2001] Oliver Christ, Ulrich Heid, Bruno Maximilian Schulze, Helmut Schmid,
Christine Stöckert. „Laborübungen Corpora I/II; Institut für maschinelle Sprachverarbeitung“.
Universität Stuttgart, Stuttgart 2001
[Przepiórkowski, 2004] Adam Przepiórkowski. „Korpus IPI PAN, Wersja Wstępna“. Instytut
Podstaw Informatyki. Warszawa 2004.
[Wöllstein-Leisten u.a, 1997] Angelika Wöllstein-Leisten, Axel Heilmann/ Peter Stepan,
Sten Vikner. „Deutsche Satzstruktur, Grundlagen der syntaktischen Analyse“. Stauffenburg
Verlag Brigitte Narr GmbH. Tübingen 1997.
[Marasek, 2003] Krzysztof Marasek. „Synteza Mowy: przegląd technologii i zastosowań ze
szczególnym uwzględnieniem języka polskiego“. Polsko-Japońska Wyższa Szkoła Technik
Komputerowych, Warszawa 2003.
[Dogil, 1995] Grzegorz Dogil. „Articulatory correlates of secondary stress in Polish and Spanish.
Phonetik Word Stress“. Arbeitspapiere des Instituts für Maschinelle Sprachverarbeitung.
Stuttgart 1995.
[Durand u.a., 2001] .Durand, A.Durand-Deska, R.Gubrynowicz, B.Marek. „Polish: Prosodic
Aspects of „Czy Questions“. Department of Phonetics, University of Provence, Frankreich;
Polska Akademia Nauk, Polen; Katolicki Uniwersytet Lubelski, Polen.
[Olivier, 1998] livier Dominika. „Polish Text To Speech Synthesis“. Master Thesis, University
of Edinburgh, 1998.
[Schiller, A., Teufel, S. Thielen, C., 1995] Schiller, A., Teufel, S. Thielen, C.. „Guidelines
für das Tagging deutscher Textkorpora mit STTS.“ Technical Report, IMS-CL, University
Stuttgart, 1995. http://www.sfs.nphil.uni-tuebingen.de/Elwis/stts/stts.
html
[Draguhn, 2004] Draguhn, Andreas. „Swinging in the Brain“.Institut für Physiologie und
Pathophysiologie, Universität Heidelberg, 2004. http://www.uni-heidelberg.de/
presse/ruca/ruca04-03/s18swing.html
[Hawkins u.a, 2004] Hawkins, Jeff, Blakeslee, Sandra. „On Intelligence“. Times Books, 2004.
[Brodbeck, 1997] Karl-Heinz Brodbeck. „Das Gehirn ist kein Computer“. http://www.
fh-wuerzburg.de/fh/fb/bwl/Offiziel/BWT/pages/pp/2/brodbeck.htm
[Spitzer, 1996] Spitzer, M. „Geist im Netz“. Heidelberg-Berlin-Oxford, 1996.
80

[Kurzweil, 1993] Kurzweil, R. „The Age of Intelligent Machines“. Massachusetts Institute of
Technology, 1990.
[Vasilakopoulos, 2003] Vasilakopoulos, A. „Improved unknown word guessing by decision
tree induction for POS tagging with TBL“. In: Proceedings of CLUK 2003, Edinburgh
2003.
[Hall, 2003] Hall, J. „ A Probabilistic Part-of-Speech Tagger with Suffix Probabilities“. Master’s
Thesis. Växjö University, Växjö, Schweden 2003.
[Brill, 92] E. Brill. „A simple rule-based part of speech tagger“. In Proceedings of the Third
Conference on Applied Natural Language Processing, ACL, Trento, Italy, 1992.
[Brill, 93] E. Brill. „A Corpus-Based Approach to Language Learning“. PhD thesis, Department
of Computer and Information Science, University of Pennsylvania, 1993.
[Brill, 94] E. Brill. „Some advances in rule-based part of speech tagging“. Proceedings of the
Twelfth National Conference on Artificial Intelligence (AAAI-94), Seattle, Wa., 1994.
[Schmid, 95] H. Schmid. „Improvements In Part-of-Speech Tagging With an Application To
German“. Institut für maschinelle Sprachverarbeitung, Universität Stuttgart, 1995.
[Schmid, 94] H. Schmid. „Probabilistic Part-of-Speech Tagging using Decision Trees“. Institut
für maschinelle Sprachverarbeitung, Universität Stuttgart, 1994.
[Brill u.a, 1993] E. Brill, M.Marcus. „Tagging an unfamiliar text with minimal human supervision“.
ARPA Technical Report. 1993
[Schüzte, 1993] Schütze, Hinrich. „Part-of-speech induction from scratch“. Proceedings of
the 31st Annual Meeting of the Association for Computational Linguistics, 251-258.
1993
[Brill, 1995] E. Brill. „Unsupervised learning of disambiguation rules for part of speech
tagging“.1995.
81