Automatische Segmentierung, Ver

Transcrição

Automatische Segmentierung, Verwaltung und Abfrage von Korpora
gesprochener Sprache
Marcus L. Fach
Dissertationsschrift zur Erlangung der Würde
eines Doktors der Philosophie (Dr. phil),
eingereicht bei der Fakultät für Philosophie
der Universtität Stuttgart
Dezember 2000
Gutachter:
Prof. Dr. phil. habil. Grzegorz Dogil, Universität Stuttgart
Prof. Dr. Werner Kallmeyer, Institut für Deutsche Sprache, Mannheim
Mündliche Prüfung
13.01.2001
Seite 1
Universität Stuttgart
Institut für Maschinelle Sprachverarbeitung
Lehrstuhl für Experimentelle Phonetik
Azenbergstraße 12
D-70619 Stuttgart
http://www.ims.uni-stuttgart.de/phonetik/
[email protected]
Seite 2
Danksagung
Diese Dissertation entstand am Lehrstuhl für Experimentelle Phonetik, Institut für Maschinelle
Sprachverarbeitung der Universität Suttgart, dessen wissenschaftliche und freundlich hilfsbereite Atmosphäre sehr zum Gelingen dieser Arbeit beigetragen hat. Meine Tätigkeit im Kooperationsprojekt "Maschinelle Segmentierung von Korpora gesprochener Sprache des IDS", dass im
Rahmen des Sonderforschungspools des Landes Baden-Württemberg gefördert wurde, motivierte mich zur Wahl des Themas.
Viele Kolleginnen, Kollegen und Freunde haben durch ihre konstruktiven Kommentare, Rückmeldungen und willkommenen Ablenkungen zu dieser Arbeit beigetragen. Besonders hervorheben möchte ich meine Betreuer Prof. Grzegorz Dogil, der mich seit dem Studium fachlich
betreute und förderte und durch seine wegweisende und freundliche Unterstützung einen großen
Anteil an dieser Arbeit hat und Prof. Werner Kallmeyer für viele fachlichen Diskussionen und
seine Bereitschaft, meine Arbeit zu begutachten.
Bedanken möchte ich mich auch bei der Forschungsgruppe im IDS um Prof. Werner Kallmeyer
für die fast dreijährige, fruchtbare gemeinsame Arbeit. Dr. Wilfried Schütte, Dr. Marcel
Schilling, Dr. Ulricke Gut und Ralf Knöbl haben durch Anregungen, Kommentare und die
tägliche Projektarbeit wertvolle Hilfe bei der Entstehung dieser Arbeit geleistet. Erwin Schuster,
Dr. Peter Fach haben die Arbeit durch aufschlussreiche Diskussionen begleitet, Ralf Knöbl und
meine Frau Beate halfen beim Korrekturlesen.
Mein herzlicher Dank gilt Dr. Wolfgang Wokurek, der mich als Betreuter von Studienarbeit und
Diplomarbeit durch mein Studium begleitet hat damit diese Arbeit ermöglichte sowie Dr. Peter
Regel-Brietzmann, der maßgeblich an meiner Ausbildung im Bereich "Automatische Spracherkennung" beteiligt war.
Zuletzt möchte ich mich bei meiner Familie, Beate, Judith, Elena, Lucas und Timm bedanken,
die durch ihr Verständnis und ihre Unterstützung in allen Gefühlslagen, vorallem in der Schlußphase dieser Arbeit, einen unschätzbaren und wichtigen Teil beigesteuert haben.
Seite 3
14.530000
14.690000
14.800000
15.190000
15.280000
15.390000
15.924926
121
121
121
121
121
121
121
isch
bin
die
k"onigin
vun
de
filsbach
129
121
121
121
123
121
121
121
121
121
129
121
121
123
121
121
121
121
123
121
121
121
121
schdegge
wo
sin
ihr
schdegge
LACHEN
ware
se
zu
eitl
do
war
isch
zu
eidl
ja
do
haww
isch
awwa
ga
ned
dro
123
123
123
123
ah
ja
ach
gott
[...]
174.290000
174.710000
174.900000
175.030000
175.564979
176.855364
177.073907
177.276930
177.439974
177.984231
178.301259
178.413700
178.554099
178.671853
179.139140
179.219863
179.287798
179.391965
179.464429
179.647854
179.819956
179.892420
180.140750
[...]
1251.800002
1252.008335
1252.089856
1252.216667
automatisch segmentiertes Fragment aus Stadtsprache Mannheim (IDS).
Seite 4
Inhaltsverzeichnis
1.Einführung
11
2.Linguistische Annotation
17
2.1. Annotationsmodelle
18
2.1.1. Partiturformat des BAS
19
2.1.2. CHILDES (CHIld Language Data Exchange System)
23
2.1.3. LDC Broadcast News Transcripts
25
2.1.4. NIST UTF (Universal Transcript Format)
26
2.1.5. Heterogeneous Relation Graphs (HRG)
30
2.1.6. Das Annotationsmodell des MATE-Annotationssystems
34
2.1.7. Das Annotationsmodell des EMU-Datenbanksystems
36
2.2. Ein formales Grundgerüst für Annotationen
41
2.2.1. Anforderungen an ein formales Annotationsgerüst
41
2.2.2. Annotationsgraphen als formales Grundgerüst
43
2.3. Annotationsmodelle in der Darstellung als AG
49
2.4. Zusammenfassung der Annotationsmodelle und -systeme
51
3.Annotierungs- und Segmentierungssyteme
55
3.1. Manuelle Annotationsverfahren - Das System DIDA
56
3.2. Automatische Segmentiersysteme
60
3.2.1. Das Stuttgarter automatische Segmentiersystem Alphones
61
3.2.2. Das Münchner Automatische Segmentationssystem
64
3.3. Evaluierung der automatischen Segmentierungssysteme
67
Seite 5
4.Grundlagen der Datenbanktechnik
69
4.1. Datenbankdesign
69
4.2. Datenbank-Entitäten
70
4.3. Beziehungen und Schlüsselattribute
71
4.4. Normalisierung
73
4.5. Physikalisches Datenmodell - Tabellenstruktur
74
5.Annotationssystem am IDS
76
5.1. Das Annotationsmodell und der Partitureditor DIDA
78
5.2. Das Recherchesystem COSMAS II
80
5.3. Experimente zur automatischen Segmentierung von Sprachsignalen
81
5.4. Zusammenfassung
101
6.Das Sprachdatenbanksystem IMSPhoBase
102
6.1. Annotationsmodell
102
6.2. Realisierung der Sprachdatenbank IMSPhoBase
103
6.2.1. Anforderungsanalyse der Sprachdatenbank
104
6.2.2. Auswahl und Funktion der Datenbank-Engine
107
6.2.3. Datenbank-Design
109
6.2.4. Funktionen des IMSPhoBase-MS
117
6.2.5. Das Analysemodul
122
6.3. Zusammenfassung
127
7.Zusammenfassung und Ausblick
129
Literaturverzeichnis
134
Anhang
141
A.1. Vollständiges Verzeichnis der Tabellen der Datenbank
141
A.2. Die Menüebenen des Datenbank-Management-Systems IMSPhoBase-MS 148
A.3. Übersicht über die verfügbaren Korpora
150
Seite 6
Abbildungsverzeichnis
Kapitel 2
Abb. 2-1: Schematische Darstellung des BAS-Partiturformats
22
Abb. 2-2: Transkriptdarstellung des CHILDES Annotationsformats
24
Abb. 2-3: Transkriptdarstellung des LDC Broadcast-Annotationsformats
26
Abb. 2-4: Transkriptdarstellung des UTF-Annotationsformats
29
Abb. 2-5: Darstellung von linguistischen Objekten in HRG
31
Abb. 2-6: Erweiterte Darstellung von linguistischen Objekten in HRG
31
Abb. 2-7: Graphische Darstellung von silbischen Strukturen mittels HRG
32
Abb. 2-8: Annotation einer kompletten Äußerung mittels HRG
33
Abb. 2-9: Phonetische Annotation im MATE-Annotationsmodell
35
Abb. 2-10: Darstellung einer EMU-Templatedatei
38
Abb. 2-11: Das EMU-Annotationsmodells am Beispiel des Wortes „jude“
39
Abb. 2-12: Darstellung der Annotationsebenen einer EMU-Annotationsdatei
39
Abb. 2-13: Baumdarstellung der Dominanzbeziehung einer EMU-Annotation
40
Abb. 2-14: Darstellung eines Annotationsgraphen
44
Abb. 2-15: Formale Darstellung eines Annotationsgraph
46
Abb. 2-16: Konstruktion des time-local index in AGs
48
Abb. 2-17: Annotationsgraph für "she had your ..."
50
Abb. 2-18: Darstellung eines Annotationsgraphen in XML-Konvention
50
Seite 7
Kapitel 3
Abb. 3-1: Die Architektur von DIDA
58
Abb. 3-2: Die Oberfläche des DIDA-Partitureditors
59
Abb. 3-3: Architektur des Stuttgarter Segmentierungswerkzeugs Alphones
63
Abb. 3-4: Architektur des Münchner Segmentiersystems MAUS
65
Abb. 3-5: Erzeugung der Aussprachevarianten in MAUS
66
Abb. 3-6: Evaluierung der Segmentiersysteme
68
Kapitel 4
Abb. 4-1: Darstellung einer Entität im logischen Datenmodell
71
Abb. 4-2: Entitäten mit Schlüsselattribut
72
Abb. 4-3: Darstellung einer 1-M-Relation zwischen 2 Entitäten
72
Abb. 4-4: Physikalisches Datenmodell (Relationenschema)
75
Kapitel 5
Abb. 5-1: Die Annotationsinfrastruktur von Sprachdaten am IDS
77
Abb. 5-2: Annotation im IDS Partiturformat
79
Abb. 5-3: SGML- basiertes Annotationsformat von COSMAS II
80
Abb. 5-4: Ergebnis der Evaluierung von Alphones in der Basisvariante
83
Abb. 5-5: Die Topologie eines Hidden Markov Modells (HMM)
87
Abb. 5-6: Auschnitt aus einer Talkshow: Musik und Klatschen
89
Abb. 5-7: Ausschnitt einer Talkshow: Rauschen und Störung
89
Abb. 5-8: Ausschnitt aus einer Talkshow: Musik und Klatschen - Verbesserung
91
Abb. 5-9: Ausschnitt einer Talkshow: Rauschen und Störung - Verbesserung
91
Abb. 5-10: Grammatik für optionale Ganzwortmodelle
92
Seite 8
Abb. 5-11: Ergebnis auf dem gesamten Evaluierungskorpus
94
Abb. 5-12: Ergebnis auf einem Teil des Evaluierungskorpus
94
Abb. 5-13: Ausschnitt aus einer Talkshow: mhm
96
Abb. 5-14: Ausschnitt aus einer Talkshow: äh
96
Abb. 5-15: Ausschnitt aus einer Talkshow: mhm - Lösung
97
Abb. 5-16: Ausschnitt aus einer Talkshow: äh - Lösung
98
100
Kapitel 6
Abb. 6-1: Schematische Darstellung des Annotationsmodells
103
Abb. 6-2: Die Architektur von IMSPhoBase
107
Abb. 6-3: mSQL-Architektur der IMSPhoBase
109
Abb. 6-4: Erster Entwurf des logischen Datenmodells
110
Abb. 6-5: Zweiter Entwurf des Datenmodells
111
Abb. 6-6: Dritter Entwurf des Datenmodells
112
Abb. 6-7: Vollständiger Entwurf des logischen Datenmodells
113
Abb. 6-8: Umsetzung der Entität FILE in eine Tabellenstruktur
114
Abb. 6-9: Screenshot des Startmenüs
119
Abb. 6-10: Auswahlstruktur für "Alle Dateien abfragen"
120
Abb. 6-11: Ergebnis der Anfrage "Alle Datenbestände ausgeben"
120
Abb. 6-12: Auswahlstruktur für "Dateien eintragen"
121
Kapitel 7
Abb. 7.1: Drei-Schichten-Architektur verteilter Datenbanksysteme
131
Abb. 7.2: Prototypische Darstellung eines Eingabeformulars zur Korporarecherche132
Seite 9
Anhang
Abb. A.1: Übersicht über die aktuellen Tabellen des Datenbanksystems
141
Abb. A.2: Die Tabelle FILE
142
Abb. A.3: Die Tabelle FILE_ID
142
Abb. A.4: Die Tabelle FILE_PHONES
142
Abb. A.5: Die Tabelle FILE_WORDS
143
Abb. A.6: Die Tabelle FILE_SPH
143
Abb. A.7: Die Tabelle FORMAT
143
Abb. A.8: Die Tabelle FORMAT_ID
144
Abb. A.9: Die Tabelle FILE_FO_ZUORDNUNG
144
Abb. A.10: Die Tabelle QUELLE
144
Abb. A.11: Die Tabelle QUELLE_ID
144
Abb. A.12: Die Tabelle FILE_QU_ZUORDNUNG
145
Abb. A.13: Die Tabelle HAUPTTYP
145
Abb. A.14: Die Tabelle HAUPTTYP_ID
145
Abb. A.15: Die Tabelle FILE_HT_ZUORDNUNG
145
Abb. A.16: Die Tabelle UNTERTYP
146
Abb. A.17: Die Tabelle UNTERTYP_ID
146
Abb. A.18: Die Tabelle FILE_UT_ZUORDNUNG
146
Abb. A.19: Die Tabelle PROZEDUR
146
Abb. A.20: Die Tabelle PROZEDUR_ID
147
Abb. A.21: Die Tabelle FILEEXT_PROZEDUR_ZU
147
Abb. A.22: Die Tabelle FILE_PRO_ZUORDNUNG
147
Abb. A.23: Baumstrukur der Menüebenen des DBMS
148
Abb. A.24: Fragment einer SGML-basierten Annotationsdatei des IDS
149
Seite 10
KAPITEL 1
Einführung
Das Thema dieser Arbeit ist automatische Segmentierung, Verwaltung und Abfragemöglichkeiten von großen Sprachdatensammlungen. Obwohl diese einzelnen Gebiete auf den ersten Blick
nicht unbedingt einen inneren Zusammenhang aufweisen, wird in der vorliegenden Arbeit eine
Zusammenführung dieser unterschiedlichen Aufgaben vorgenommen. Die Zusammenführung
ergibt schließlich ein aktives System, in dem Funktionalitäten implementiert sind, die in großen
Sprachdatenbanken bisher nicht enthalten sind.
Der Ausgangspunkt dieser Arbeit sind große Mengen von Sprachdaten, also aufgenommer gesprochener Sprache, und deren Analysen. Die Sprachdaten sowie die Analysen können auf verschiedene Weise erhoben bzw. erzeugt werden. Im einfachsten Fall kann Sprache direkt am
Computer aufgenommen und von Hand z.B. in Wörter segmentiert werden. Darüber hinaus gibt
es natürlich viele Möglichkeiten, Aufnahmen gesprochener Sprache zu gewinnen. Eine Möglichkeit, Sprachmaterial automatisch zu gewinnen, wird in der Dissertation von Stefan Rapp
[1.1] aufgezeigt. Darin wurden z.B. Radioaufnahmen eines digitalen Satellitenradios (DSR) direkt vom Computer automatisch gewonnen und in ein entsprechendes Format gebracht. Der
Vorteil dieser Art der Datenerhebung (Radio, Fernsehen usw.) ist neben einem meistens geringen Aufwand die oft gute bis sehr gute technische Aufnahmequalität. Auch die zunehmende
Verbreitung von weiteren Quellen wie etwa Literaturlesungen, die auf CD-ROM erhältlich sind
und sich durch gute technische Qualität (hohe Samplingrate) auszeichnen, sei in diesem Zusammenhang erwähnt. Diese Sprachdaten werden dann annotiert, d.h. aus den verschiedensten
Blickrichtungen und Anforderungen beschrieben. So kann z.B. eine phonetische oder phonemische Beschreibung des Sprachsignals notwendig sein, oder es reicht eine reine wortbasierte Beschreibung aus. Darüber hinaus können artikulatorische, prosodische, syntaktische oder
Seite 11
semantische Beschreibungen erforderlich sein. Die Annotierungen können manuell oder auch
maschinell gewonnen werden.
Sprachdaten und deren linguistische Beschreibungen (Annotierungen), die auf so unterschiedliche Weisen gewonnen werden, sind typischerweise sehr heterogen. Dennoch können Sprachdaten nach verschiedenen Kriterien klassifiziert werden, so dass größere Körper, sogenannte
Korpora, entstehen. Die einem Korpus gemeinsamen Merkmale können z.B. Aufnahmeort oder
-datum, Sprecher, gesprochene Texte, Projekt- oder Domänenzugehörigkeit sein. Durch die Zusammenführung werden die verbleibenden Unterschiede der Sprachsignale und deren Beschreibungen auf die nächst höhere Ebene projeziert und definieren sich dann als Unterschiede
zwischen den Korpora. Die eher theoretisch motivierte Begriffsbestimmung von Korpus in
[1.2]:
„Endliche Menge von konkreten sprachlichen Äußerungen, die als empirische
Grundlage für sprachwissenschaftliche Untersuchungen dienen. Stellenwert und
Beschaffenheit des Korpus hängen weitgehend von den jeweiligen spezifischen Fragestellungen und methodischen Voraussetzungen des theoretischen Rahmens der
Untersuchung ab (...).“
wird in [1.3] erweitert zu:
„Wenn nicht nur einzelne Gesprächsaufnahmen zu Transkripten verarbeitet, sondern viele derartige Aufnahmen nach Varianz- und Ähnlichkeitsgesichtspunkten zusammengestellt werden, sprechen wir von Korpora. Gesprächskorpora können u.a.
nach systematischen Gesichtspunkten entstehen, etwa um Gespräche eines bestimmten Interaktionstyps zu dokumentieren (z.B. „Beratungsgespräche“) oder um
Tendenzen der Sprachentwicklung aufzuzeigen, indem Gespräche nach ihrem Aufzeichnungsdatum chronologisch zusammengestellt werden. Solche Korpora können
zu einem Archiv zusammengefügt werden.“
Sind Korpora auf diese Weise erstellt, so will man darin auch nach bestimmten linguistischen
Phänomenen suchen können. Für eine Suche gibt es prinzipiell zwei unterschiedliche Vorge-
Seite 12
hensweisen: Entweder es wird im Sprachsignal oder in den Annotierungen gesucht. Die Wahl
hängt von den Rahmenbedingungen ab; ist das zu durchsuchende Korpus klein und der vorher
geleistete Annotierungsaufwand gering und sehr speziell, so bietet sich u.U. die Suche direkt im
Sprachsignal an. Allerdings muss dabei auf eine Technik aus der automatischen Spracherkennung zurückgegriffen werden, die Schlüsselworterkennung (engl. Keyword spotting). Diese
Methode ist mittlerweile recht weit ausgereift (siehe [1.4]), hat allerdings auch gravierende
Nachteile, weswegen es für die hier beschriebenen Probleme in der Regel nicht zum Einsatz
kommt. Eine Schlüsselwortsuche (Schlüsselworterkennung) im Sprachsignal ist relativ aufwendig und muss für jedes neue zu suchende Wort wiederholt werden, was zwar im Vergleich mit
der manuellen Schlüsselwortsuche im Sprachsignal schneller, aber trotzdem in keiner Weise effizient ist. Darüber hinaus ist es nicht gesichert, dass immer alle Vorkommen eines Suchwortes
gefunden werden, bzw. häufig mehr gefunden, als tatsächlich vorhanden sind.
Demgegenüber ist eine Suche in der Annotierung wesentlich effizienter. Eine solche Suche ist
rein textbasiert und somit signifikant schneller als eine Suche, die das Sprachsignal Zeitpunkt
für Zeitpunkt analysiert. Die Annotierung wird einmal erstellt und liefert exakt, abhängig von
der Qualität der Annotierung, jedes Vorkommen eines gesuchten Merkmals. Der Zugriff auf ein
sprachliches Objekt erfolgt bei dieser Methode also indirekt, über dessen textbasierte Beschreibung, vorausgesetzt, es existiert eine Verbindung zwischen der Annotierung und dem Sprachsignal. Solche Verbindungen werden in der Regel über eine Zeitachse realisiert. Jedes Element
muss dazu segmentiert, d.h. mit Referenzen auf Zeitpunkte ausgestattet sein. Dies kann in Form
von Startzeitpunkt und Dauer oder durch Startzeitpunkt und Endzeitpunkt notiert sein. Eine solche Segmentierung kann natürlich von Hand vorgenommen werden, idealerweise bereits zum
Zeitpunkt der Annotierung, was allerdings den Zeitaufwand für einen menschlichen Labeller
drastisch erhöht. Für eine automatische Segmentierung wird neben dem Sprachsignal nur die
Verschriftlichung des Sprachsignals benötigt, was einen sehr viel geringeren Aufwand für die
Annotierung insgesamt bedeutet. Für die automatischen Segmentierverfahren werden ebenfalls
Techniken aus der automatischen Spracherkennung eingesetzt, die allerdings auf Grund von
Einschränkungen gegenüber Spracherkennungssystemen wesentlich robuster arbeiten als reine
Spracherkennungssysteme.
Die Integration, Pflege und Abfrage solcher Korpora stellt eine große Herausforderung dar.
Durch die Notwendigkeit einer mächtigen Abfragemöglichkeit einerseits und durch den An-
Seite 13
spruch andererseits, möglichst viele verschiedenartige Korpora einer automatischen Verarbeitung zugänglich zu machen, entstehen viele Anforderungen an ein Korporaverwaltungssystem.
Die wichtigsten Punkte sind im Folgenden diskutiert.
• Annotierungen sollen möglichst konsistent vorgenommen sein. Diese
Forderung vereinfacht den Aufwand beim Systementwurf und bei der Systempflege, ist aber auch zwingend notwendig für die Abfrage auf den Annotierungen.
Die
Forderung
zielt
in
erster
Linie
auf
die
Transkriptionsrichtlinien, aber auch auf die Abbildung zwischen dern Annotierungen ab: Die Segmentgrenzen von verschiedenen Annotierungen,
die das gleiche Sprachsignal beschreiben, müssen identisch sein.
• Das Auffinden von bestimmten sprachlichen Phänomenen, auch in
spezifischen Kontexten, soll möglich sein. Die Annotierungen sollen so
geeignet repräsentiert sein, dass die Suche nach einem Element alle vorhanden Annotierungen einschließt. Auf diese Weise kann jeder linguistische
Kontext berücksichtigt werden, soweit eine Annotierung vorliegt.
• Alle Ergebnisse sollten auch weiteren Auswertungen z.B. statistischen
Analysen zugänglich sein. Große Mengen von strukturierten Korpora
müssen auch von externen Programmen automatisch durchsucht, analysiert
und weiterverarbeitet werden können. Um diese Forderung zu erfüllen,
muss neben einer einfachen Benutzerinteraktion auch eine Exportfunktion
der Ergebnisse und eine Programmierschnittstelle vorhanden sein.
• Die Strukturen sollen erweiterbar sein, z.B. um neue, auch andersartige Daten integrieren zu können. Die gemeinsame Struktur aller in einem System vorhandenen Korpora muss so flexibel sein, dass jederzeit
neue Annotierungsstrukturen oder auch Fremdformate abbildbar sind. In
diesen Zusammenhang ist auch die erste Forderung zu stellen, denn obwohl
Transkriptionsrichtlinien Veränderungen unterliegen, muss eine konsisten-
Seite 14
te Annotierung gewährleistet sein. Dies kann nur über eine offene Architektur realisiert werden.
Die meisten dieser Forderungen können mit konventionellen Datenbanksystemen und einigen
Vorverarbeitungsschritten eingelöst werden. Zu diesen Vorverarbeitungsschritten gehört die
Planung und Erstellung einer gemeinsamen Struktur für alle verfügbaren Korpora. Dabei ist besonderer Wert auf eine möglichst offene Struktur zu legen, damit auch zukünftige Korpora ohne
Aufwand in diese Struktur eingefügt werden können. Um sehr heterogene Korporastrukturen abbilden zu können, werden in der Regel auch komplexe Annotierungsmodelle gewählt, die typischerweise nicht maschinell verarbeitbar sind und somit nicht ohne weiteres in ein StandardDatenbanksystem überführt werden können. Obwohl Cassidy in [1.5] eine Methode für die Umsetzung eines Annotationsmodells in das relationale Datenbankmodell gezeigt hat, kann als Alternative auch ein ganz einfaches Annotationsmodell1 gewählt werden.
Wenn aber über diese Standardanforderungen hinaus weitere Funktionen möglich sein sollen,
wie etwa eine automatische Konvertierung von in der Datenbank vorhandenen Daten oder eine
Erzeugung neuer Daten, so reicht die Funktionalität von Standardsystemen nicht aus. Solche
Funktionserweiterungen erfordern auf der einen Seite eine Einbindung in das grundlegende Datenmodell der Datenbank und auf der anderen Seite ein flexibles Datenbank-Management-System, in dem die Funktionen als aufrufbare Prozeduren integriert werden. Durch automatisches
Eintragen von neuen Daten in die Datenbank werden u.a. Konsistenzprobleme umgangen.
Um alle oben aufgeführten Anforderungen erfüllen zu können, ist mit dieser Arbeit ein neuer,
hybrider Ansatz aus konventioneller Datenbanktechnik, spezifischen Modulen, die den vorhandenen Korpora und Korporawerkzeugen gerecht werden und automatischen Segmentierungswerkzeugen entwickelt worden.
Damit ist ein Abfragesystem entstanden, mit dem gleichermaßen Sprachdatenkorpora verwaltet
und abgefragt und neue Annotierungen und Segmentierungen durch Konvertierungsroutinen generiert und eingetragen werden können.
1 Einfache Annotationsmodelle haben gegenüber komplexen Modellen den Nachteil, dass Abfragen
über ein komplexes Analysemodul realisiert werden müssen (siehe Abschnitt “Das Sprachdatenbanksystem IMSPhoBase” auf Seite 102).
Seite 15
Die vorliegende Arbeit ist in 8 Kapitel eingeteilt. In Kapitel 2, 3 und 4 werden die Grundlagen,
die für den eigenen Entwurf benötigt werden, beschrieben. Dazu gehören linguistische Grundlagen zur Annotierung, die anhand der wichtigsten Annotationsmodelle und -systeme dargestellt
werden sowie die entsprechenden manuellen, semi-automatischen und automatischen Systeme,
mit denen Annotierungen und Segmentierungen produziert werden können (Kapitel 3). In Kapitel 4 werden die benötigten informationstechnischen Grundlagen in Form einer Einführung in
die Datenbanktechnik erarbeitet.
In Kapitel 5 werden Experimente zur maschinellen Segmentierung ausführliche diskutiert, die
ein bestehendes Annotationsystem mit Zeitmarken anreichern soll. Diese Experimente sind Bestandteil des Alignmentprojekts zwischen dem Lehrstuhl für Experimentelle Phonetik, Institut
für Maschinelle Sprachverarbeitung (IMS) der Universität Stuttgart und dem Institut für Deutsche Sprache (IDS) in Mannheim. Der Rahmen, in dem die Ergebnisse dieser Experimente eingearbeitet werden, wird kurz skizziert, in den Kontext dieser Arbeit gestellt und darin bewertet.
Die Erfahrungen daraus gehen in die Arbeit in Kapitel 6 ein. Die Experimente aus diesem Kapitel habe ich u.a. auf der 1. Arbeitstagung zur linguistisch Korpuslinguistik 20002 [1.1] in Freiburg vorgestellt und diskutiert.
In Kapitel 6 wird der eigene Entwurf vorgestellt. Das darin beschriebene Sprachdatenbanksystem IMSPhoBase ist am IMS entstanden. Das System IMSPhoBase, in das die Erfahrungen der Grundlagenkapitel und vor allem aber der Projektarbeit (Kapitel 5) eingeflossen sind,
ist auf die speziellen Anforderungen am IMS hin entwickelt worden. Grundzüge aus Kapitel 6
habe ich auf der Konvens20003 [4.1] in Ilmenau präsentiert und diskutiert. Die vielen konstruktiven Ideen, Bemerkungen und Anmerkungen kamen diesem Kapitel natürlich zugute.
In Kapitel 7 wird die Arbeit zusammengefasst, in Kapitel 8 finden sich die Quellennachweise,
nach Kapiteln sortiert. Im Anhang ist eine Liste der benutzten Korpora.
2 [http://omnibus.uni-freiburg.de/~pusch/korpus_2000/index.htm]
3 [http://www.e-technik.tu-ilmenau.de/dsv/konvens2000/index.html]
Seite 16
KAPITEL 2
Linguistische Annotation
Unter Annotierung versteht man im Allgemeinen Erklärungen oder Kommentare (deskriptive
und analytische Beschreibungen) zu bestimmten Objekten bzw. die Handlung, um solche Kommentare oder Erklärungen zu produzieren. Im Fall von linguistischer Annotierung handelt es
sich also um das Kommentieren oder Erklären von linguistischen Objekten [2.2], wobei diese
sowohl in Form verschrifteter Texte als auch in Aufnahmen von gesprochener Sprache vorliegen
können. Ich werde mich im Weiteren bei der Betrachtung linguistischer Objekte primär auf
Sprachsignale konzentrieren.
Die einfachste Art der Annotierung ist die Verschriftung des Sprachsignals. Dieser Vorgang findet gewöhnlich manuell4 statt und ergibt eine orthographische Repräsentation des Sprachsignals
ohne dabei auf einen zeitlichen Bezug Wert zu legen. Darüber hinaus gibt es weitere Annotationsebenen, wobei die Anzahl letztlich nur durch die Menge der beschriebenen linguistischen
Phänomene abhängig ist. Weit verbreitet sind phonetische, phonemische und prosodische Beschreibungen sowie Wort- und Silbenbeschreibung. In vielen Fällen gehören zu diesen Kernbeschreibungsebenen auch noch syntaktische Informationen in Form von ”Part-of-Speech (POS)
Tags”. Darüber hinaus finden sich auch tiefer gehende syntaktische und semantische Beschreibungen, aber auch Grundfrequenzanalyse, Beschreibung von artikulatorischen Gesten und vieles mehr.
Die Art der Erstellung5 der Annotierungen determiniert in der Regel auch ihre Struktur und Organisation. Während der Dateiname des Sprachsignals meist die äußere Struktur bestimmt (in
4 Für eine automatische Verschriftung würde man auf Methoden aus der automatischen Spracherkennung zurückgreifen müssen.
5 Siehe Kapitel "Annotierungs- und Segmentierungssyteme, S. 55"
Seite 17
Form einer Namenskonvention), wird bei der inneren Struktur unterschieden zwischen einer
Einzeldarstellung aller Ebenen, wie es aus der Tier-Notation ([2.1]) bekannt ist, und einer gesamtheitlichen Darstellung, wie es z.B. bei Partitureditoren der Fall ist. Die Darstellung mittels
einzelner Annotierungsebenen wird z.B. im Sprachdatenbanksystem EMU (siehe Abschnitt
"Das Annotationsmodell des EMU-Datenbanksystems S. 36) gewählt, während die zweite Möglichkeit bei Partitureditoren wie z.B. DIDA (siehe Abschnitt "Der Partitureditor DIDA S. 56) und
beim BAS-Partiturformat (siehe Abschnitt "Partiturforamt des BAS" S. 19) benützt wird.
Die Zusammenfassung von Sprachsignalen und deren Anreicherung durch Annotierungsebenen
ergeben einen Korpus. Die Zusammenführung von Korpora und die Anreicherung mit Methoden zur Speicherung, Manipulation und Abfrage ergeben annotierte Sprachsignalkorpora. Solche Sprachsignalkorpora können als zusammenhängende Dateienstruktur mit einfachen
textbasierten Such- und Verwaltungsstrukturen realisiert sein oder auf einer Datenbank basieren. Für eine datenbankbasierte Verarbeitung von Annotierungen müssen diese in geeignete Repräsentationen (Modelle) überführt werden. Eine Auswahl der wichtigsten Vertreter solcher
Annotationsmodelle sind in Abschnitt 2.1. beschrieben.
2.1.
Annotationsmodelle
Für eine maschinelle Verwendung von Annotierungen, z.B. im Sinne von Datenbanksystemen,
ist es unerlässlich, ein Modell für die Annotation zu Grunde zu legen. Solche Annotationsmodelle bilden den inneren Rahmen, in dem die verschiedenen Beschreibungsebenen zusammengefasst werden. Dabei gibt es große Unterschiede zwischen den Annotationsmodellen: Von
einfachen Modellen, die in sich nur eine lose Sammlung von Annotationsebenen subsummieren,
bis hin zu sehr komplexen Modellen, in denen Abhängigkeiten und Beziehungen zwischen den
einzelnen Ebenen definiert werden. Neben der Organisation innerhalb des Annotationsmodells
ist die Notation, die jeder Ebene der Annotation zu Grunde liegt, von Modell zu Modell verschieden. Dabei kann es sich im einfachsten Fall um eine rein textbasierte Notation handeln, die
durch Zeitmarken und Labelsegmente charakterisiert ist, aber auch um XML- oder SGML-basierte aufwendige Repräsentationen. Zusammenfassend kann ein Annotationsmodell als eine
Schreibkonvention für die Darstellung von Kommentaren und Analysen linguistischer Objekte
bezeichnet werden.
Aus der Literatur sind viele Annotationsmodelle bekannt. In Anbetracht der großen Variations-
Seite 18
breite der verschiedenen Modelle wird das in den Arbeiten von Bird&Liberman [2.2] und [2.3]
(auch [2.4] und [2.5]) entwickelte formale Grundgerüst benützt, um die vorgestellten Annotationsmodelle darin zu integrieren. Damit lässt sich wiederum zeigen, dass die meisten Annotationsmodelle auf einen gemeinsamen Kern reduziert werden können. Die vorgestellten Modelle
Partitur ([2.6], [2.7]), CHILDES ([2.8]), LDC Broadcast News ([2.9]), NIST UTF ([2.10]), HRG
(Festival [2.11], [2.12]), MATE ([2.13], [2.14], [2.15]) und EMU ([2.16], [2.16], [2.18]) entspringen spezifischen Anwendungen und bestimmten linguistischen Domänen.
2.1.1.
Partiturformat des BAS
Das Partiturformat des Bayerischen Archivs für Sprachsignale6 (BAS) ist eine Darstellungsform
für unterschiedliche Annotierungsebenen gesprochener Sprache. Das Format erlaubt eine zeitalignierte, multi-ebenen Beschreibung von Sprachsignalen. Das zu Grunde liegende Modell realisiert eine Mischung aus dem in der Einleitung bereits erwähnten Konzept des Einzelebenensystems und der aus der Musik bekannten Partiturschreibweise. Im Gegensatz zu anderen
Partitureditoren (z.B. der Partitureditor DIDA, Seite 78) werden hier die einzelnen Annotierungsebenen wie die Stimmen einer Partitur nebeneinander gestellt, verbleiben aber in getrennten Dateien.
Die Realisierung der Struktur erfolgt durch eine Partiturdatei, welche die äußere Struktur bildet
und deren Aufbau aus einem SAM-kompatiblen7 Header und aus einem Datenteil besteht.
Durch den gemeinsamen Namensstamm ist die Verbindung zur korrespondieren Sprachsignaldatei gewährleistet. Im Datenteil der Definition sind u.a. die Annotierungsebenen durch Referenz eingebunden.
Struktur des Annotationsmodells
Das Annotationsmodell wird äußerlich durch die Partiturdatei gebildet. Die Sprachsignaldatei
und die Partiturdatei haben den gleichen Namensstamm, aber verschiedene Endungen. Die innere Struktur wird über Indizes realisiert, mit denen annotierungsübergreifend, durch Referenzierung auf entsprechende Indizes anderer Annotierungsebenen, Beziehungen aufgebaut werden
können. Durch die in (1) dargestellte Syntax wird die innere Struktur gebildet, wobei „REF“ für
6 [www.phonetik.uni-muenchen.de/BAS/BASFormatsdeu.hmtl]
7 Esprit „SAM“ Projekt No 2589: Speech Input und Output Assesment Methodologies and Standardization, [http//:www.icp.grenet.fr/Relator/standsam.html]
Seite 19
die Referenzierung auf die Annotierungsebenen steht.
(1)
REF: ([START-ZEIT] [DAUER-ZEIT]) ([LINK],{LINK}) [MARKER] ETIKETT
Aus dieser allgemeinen Syntax8 können alle Ebenen generiert werden, wobei nicht alle Ebenen
die gesamte Syntax ausnützen. Aus (1) sind 3 Klassen von Ebenen ableitbar.
• Klasse1: Ebenen mit symbolischen Verzeigerungen,
• Klasse2: Ebenen mit Zeitreferenz und symbolischer Verzeigerung und zeitlichen Abschnitte,
• Klasse3: Ebenen mit Zeitreferenz und symbolischer Verzeigerung ohne
zeitlichen Abschnitte
Zur Verdeutlichung werden im Folgenden die wichtigsten Instanzen der Klassen vorgestellt:
Kanonische Beschreibungsebene (KAN: [LINK] TRANSKRIPTION)
Diese Ebene enthält die Äußerungen des Sprachsignals in kanonischer
Transkription in SAM-PA Notation.
Beispiel:
KAN:
0
j’a:
KAN:
1
Qalzo:+
KAN:
2
QE:m
KAN:
3
h’OYt@
KAN:
4
Qo:d6+
Diese Ebene bildet durch ihre durchgängige Indizierung die symbolische
Basis für alle weiteren Ebenen. KAN gehört zur Klasse 1. Die orthographische Beschreibungsebene (ORT) enthält die zur kanonischen
Transkription gehörige Orthographie. ORT ist ebenfalls eine Instanz der
Klasse 1.
8 Die "{ }" bedeutet null oder mehrmalige Wiederholungen, "[ ]" bedeuten optional
Seite 20
Phonetische Beschreibungsebene (MAU: [START] [DAUER] [LINKS] SEGMENT)
Diese Annotierungsebene enthält eine automatisch erstellte phonetische
Transkription durch das System MAUS9. Es werden Startzeitpunkt und
Dauer der Segmente sowie die symbolische Verzeigerung auf die
entsprechende Vorschlagstranskription (KAN) berechnet.
Beispiel:
MAU: 0
676
-1
<p:>
MAU: 6677
861
-1
<nib>
MAU: 8539
450
0
g
MAU: 89902
436
0
u:
MAU: 114271 740
0
t
MAU: 13168
1
d
958
Die phonetische Beschreibungsebene gehört zur Klasse 2. Neben dieser
Beschreibungsebene gibt es weitere phonetische Ebenen, die allerdings
projektabhängig anderen Transkriptionsrichtlinien folgen.
Prosodische Beschreibungsebene (PRB: [START-ZEIT] [LINKS] ZEICHENKETTE)
Die prosodische Annotierungsebene beschreibt wie die Ebenen der Klasse 2
Zeitpunkte, aber jedoch keine Dauer, da die zu annotierenden Phänomene
Kurzzeitereignisse sind. Die Segmentierung erfolgt nach GTOBI und
bezieht sich auf die Indizes von (KAN). Die prosodische Beschreibungsebene
gehört zur Klasse 3.
Beispiel:
PRB: 542125
TON: H;
FUN: NA
PRB: 632697
TON: L+H*; FUN: EK
PRB: 763718
BRE: B3;
PRB: 799678
TON: L*+H; FUN: PA
TON: L-L%
9 Siehe Abschnitt "Das Münchner Automatische Segmentationssystem, S. 64"
Seite 21
Nicht alle Annotationsebenen nützen die gesamte Syntax der formalen Struktur aus, nur „grundlegende“ Annotationen wie KAN oder MAU verfügen über alle Elemente der formalen Struktur.
Die übrigen Ebenen referieren mit Indizes (LINKS) auf diese grundlegenden Annotationsspuren.
Über die hier dargestellten Annotationsebenen hinaus gibt es noch weitere Instanzen der drei
oben aufgeführten Klassen, die allerdings korpora- bzw. aufgabenspezifisch sind. Die vollständige Auflistung aller Annotierungsebenen, die Transkriptionsrichtlinien und detaillierte Erklärungen finden sich unter [http://www.phonetik.uni-muenchen.de/Bas/BasFormatsdeu.html].
Die äußere Struktur des Modells wird durch eine Datei realisiert, die den Namensstamm des korrespondierenden Sprachsignals trägt, aber die Endung "*.par" (für "Paritur") aufweist. In Abbil-
Body
Header
dung 2-1 ist eine solche Partiturdatei schematisch dargestellt.
Abb. 2-1: Schematische Darstellung des BAS-Partiturformats
In der Abbildung ist die Partiturdatei schematisch dargestellt. Die Partiturdatei ist in einen Header und einen Datenteil aufgeteilt. Im Header sind dem Sprachsignal zugehörige Metadaten enthalten, im Datenteil werden die einzelnen Annotationstiers mittels Referenz (hier durch stilisierte waagerechte Tiers dargestellt) eingetragen.
Wie in der Abbildung 2-1 dargestellt, besteht die Partiturdatei aus den zwei Teilen Header und
Datenteil. Die Headerdefinition enthält generelle Informationen, die für die Klassifikation und
Zuordnung der Annotierungen notwendig sind, während im Datenteil speziellere Informationen,
vor allem aber die Anker der verschiedenen Annotierungsebenen (in der Abbildung als waagerechte Ebenen stilisiert), enthalten sind. Alle Einträge in dieser Partiturdatei sind einer AttributWert-Struktur entsprechend definiert. Ein Vorteil dieser Definiton ist, dass im Datenteil beliebig
neue Attribute definiert werden können, solange diese nicht mit bereits vorhandenen Attributen
kollidieren. Auf diese Weise können auch neue Annotationsebenen eingetragen werden, ohne
das Annotationsmodell verändern zu müssen.
Seite 22
2.1.2.
CHILDES (CHIld Language Data Exchange System)
Das CHILDES System besteht aus drei Komponenten: Einer Diskursnotationskomponente, die
auf dem Annotierungsmodell CHAT10 basiert, einer Sammlung von Werkzeugen (CLAN), die
aber nicht Gegenstand der Betrachtung sein sollen11, und einer Datenbank mit Transkripten (ca.
160MB), die im CHAT Format annotiert sind. Die CHILDES Datenbank umfasst Diskursdaten
von Kindern und Erwachsenen verschiedenster Sprachzugehörigkeiten. Für eine ausführliche
Spezifikation der Aufnahme und Domänenspezifikation siehe [http://childes.psy.cmu.edu/html].
Struktur des Annotierungsmodells
Das CHAT-Modell basiert auf einer Transkriptnotation und weist jedem Turn eine Annotierungsdatei zu, in der alle Annotierungsebenen enthalten sind. Diese Annotierungsdatei ist geteilt
in einen Header und einen Datenteil. Im Header stehen relevante Daten bezüglich der Personen,
die am Diskurs beteiligt sind, wie etwa Alter, Ausbildung uvm.
Die Transkription erfolgt sequentiell, Äußerung für Äußerung, und wird in Wortform auf je eine
Zeile im Datenteil annotiert. Diese Hauptzeile ist ausgezeichnet durch das Symbol „*“ und die
Kennung der betreffenden Person. Ergänzende Annotierungen werden in separaten Zeilen unmittelbar unter die korrespondierende Hauptzeile eingefügt und sind durch das Symbol „%“ sowie einen Referenten markiert. Es sind Spuren für phonologische, morphologische und
syntaktische Analyse, Sprechakte und Sprechfehler sowie für die Referenz auf das Sprachsignal
vorgesehen. Darüber hinaus sind aber weitere Annotierungsebenen frei definierbar.
Die Zeilenstruktur des Datenteils ist dialog-orientiert und wird nach der in (2) dargestellten Syntax gebildet:
(2)
* SPR 1:
ÄUSSERUNG
{ %REF:
{ %REF:
[SPRACHSIGNAL] [START] [END] }
[ZEICHENKETTE] }
Mit der 1. Zeile werden die Äußerungen der Sprecher, deren Kennung im Header definiert ist,
in der Reihenfolge des Auftretens im Sprachsignals annotiert. Die zweite, optionale Zeile dient
einer möglichen Abbildung auf das korrespondierende Segment im Sprachsignal und die dritte
10 CHAT steht für Codes for the Human Anaylsis of Transcripts
11 Für die Werkzeugsammlung CLAN siehe [http://childes.psy.cmu.edu/html/clan.html].
Seite 23
optionale Zeile dient der weiteren möglichen Annotierungen.
In Abbildung 2-2 ist ein Auszug aus einem Transkript (nach [2.8]) dargestellt.
Abb. 2-2: Transkriptdarstellung des CHILDES Annotationsformats
Das Annotationsformat von CHILDES teilt das Transkript in zwei Teile, den Header und den Datenteil, auf. Im
Header stehen sämtliche relevanten Metadaten zur Annotation. Im Datenteil werden die Sprecher auf der sogenannten Hauptzeile in Wortform annotiert, für jeden Sprecher gibt es eine Hauptzeile, die durch einen Stern markiert ist
und das entsprechende Sprecherkürzel, laut Headerdefinition, enthält. Zu jeder Hauptzeile können weitere Annotationen angehängt werden; in dem abgebildeten Beispiel ist die Referenz zum jeweiligen Segment im Sprachsignal
angegeben.
In der Abbildung ist der Anfang eines Dialogs zwischen Kindern und Eltern dargestellt. In der
Headerdefinition des Annotationsmodells sind die Teilnehmer am Dialog sowie weitere Metadaten wie Aufnahmedatum, nähere Angaben zu den Teilnehmern etc. definiert. Im Datenteil
sind Äußerungen gemäß der Syntax aus (2) annotiert. Jeder der Teilnehmer hat eine eigene
Hauptzeile, die durch sein Namenskürzel eingeleitet wird. Hier ist als einzige Nebenzeile die
Abbildung auf die entsprechenden Segmente in der Signaldatei annotiert.
Obwohl auch in dem CHAT-Annotationsmodell neue Annotationsebenen definiert werden können, stellt es auf Grund der Organisation des Annotationsmodells weit mehr Aufwand dar, neue
Ebenen einzubauen, als in einer Struktur wie es das BAS-Partiturformat aufweist.
Seite 24
2.1.3.
LDC Broadcast News Transcripts
Der LDC Nachrichtenkorpus besteht aus über 200 Stunden Sprachdaten, die Aufzeichnungen
der Sender ABC, CNN, CSPAN Television Networks, NPR und PRI Radio darstellen. Die
Sprachsignale sind auf der phrasalen Ebene segmentiert, die Grenzen zwischen einzelnen Nachrichten sowie Sprecherwechsel sind annotiert. Das zu Grunde liegende Annotationsmodell ist in
SGML strukturiert.
Das Modell basiert ebenso wie das CHAT-Modell auf einer Transkriptnotation, weist allerdings
eine komplexe innere SGML-Struktur auf. Es erfolgt keine separate Headerdefinition, alle Metadaten werden direkt in die Annotation eingetragen. Die in (3) dargestellte pseude-SGML Syntax generiert die Annotation:
(3)
<sektion>
{ [GLOBALE_QUALITAETSMERKMALE] }
<segment START SPRECHER QUALITÄT MODE>
[PHRASE | SATZ] <zeit_sync> [ZEIT_MARKER]
{ [PHRASE | SATZ] <zeit_sync> [ZEIT_MARKER] }
</segment>
{ <segment START SPRECHER QUALITÄT MODE>
[PHRASE | SATZ] <zeit_sync> [ZEIT_MARKER]
{ [PHRASE | SATZ] <zeit_sync> [ZEIT_MARKER] }
</segment> }
</sektion>
Die Syntax erlaubt eine Annotierung, die sich an der Struktur von Nachrichten orientiert. Die
Annotierung wird durch wiederkehrende Abfolgen von Segmenten, eingeschlossen durch die
Tags <segment> und </segment>, strukturiert. In jedem Segment werden Anfangszeitpunkt
(START), Sprecheridentität (SPRECHER), Qualität des Sprachsignals (QUALITÄT), Sprechstil (MODE) und Referenzzeitpunkte (<zeit_sync>) zu den entsprechenden Abschnitten der wortbasierten
Annotierung eingetragen. Der Block {[PHRASE|SATZ] <zeit_sync> [ZEIT_MARKER]} kann sich innerhalb eines <segment> Blocks beliebig oft wiederholen. Der Block <segment> wiederum ist
durch die Tags <sektion> und </sektion> eingeschlossen und kann ebenfalls beliebig oft wiederholt werden. In Abbildung 2-3 ist ein Auszug aus einem Transkript (nach [2.9]) dargestellt.
Seite 25
Abb. 2-3: Transkriptdarstellung des LDC Broadcast-Annotationsformats
Das Annotationsmodell ist definiert durch eine feste Abfolge von Blöcken, die in einer SGML-konformen Notation
durch Tags begrenzt werden. Es gibt keine Headerdefinitionen, alle Metadaten werden in <sektion> und/oder
<segment> annotiert. Der Block segment kann beliebig oft wiederholt werden.
In dem Beispiel aus Abbildung 2-3 ist der Beginn einer Nachrichtensendung annotiert. Gemäß
der Syntax aus (3) werden globale Merkmale des Sprachsignals, wie Art und Stärke des Hintergrundgeräuschs und deren zeitliche Markierung auf einer <sektion> vor den <segment> Blöcken
annotiert, sofern diese die gesamte Zeitspanne einer <sektion> überlappen. Die selben Merkmale
können auch innerhalb der <segment> Blöcke für lokale Ereignisse benützt werden.
Das LDC Broadcast Annotationsmodell ist in seiner Struktur auf Grund der turn-basierten Ausrichtung stark eingeschränkt und wie auch das CHAT-Annotationsmodell wenig flexibel
in Bezug auf Eintragung neuer Annotationsstrukuren und -ebenen.
2.1.4.
NIST UTF (Universal Transcript Format)
Das UTF ist eine Weiterentwicklung des LDC Broadcast Annotationsformat. Die wichtigste Erweiterung der SGML-basierten Transkriptionskonventionen ist die Möglichkeit, überlappende
Segmente zu markieren. Die UTF Annotationsstruktur enthält eine umfangreiche und komplexe
Annotationshierarchie.
Seite 26
Der Kern des Annotationsformats besteht aus einer wortsegmentierten Sprecheräußerung und
wird durch die Tags <turn> und </turn> begrenzt. Diese Struktur ist wie auch beim LDC Broadcast-Format (<segment>) der Kern der Annotation. Die Annotationstruktur des UTF ist allerdings reichhaltiger und weist eine komplexere Hierarchie auf als die des LDC Broadcast. Die
Annotationshierarchie ist durch vier Tag-Klassen charakterisiert: Strukturklasse, Qualitätsklasse, Segmentierungsklasse (engl. pseudo bracketing) und lexikalische Klasse.
Die Tags der Strukturklasse bilden die formale Struktur einer Annotation. Zu dieser Klasse gehören die Tags <utf>, welche den äußeren Rahmen einer Annotation bilden, <bn_episode_trans>
sowie <conversation_trans> folgen als nächst tiefere Hierarchiestufe. <sektion> und <turn> stellen
die unterste Hierarchiestufe dar. Die Klasse Qualität beinhaltet das Tag (<qualitaet>), deren Attribute zur Beschreibung von Sprachsignalqualität und Hintergrundgeräuschen herangezogen
werden. Alle Tags dieser zwei Klassen sind der SGML-Notation folgend als Paardarstellung
(öffnender und schließender Tag) realisiert. Die Tags der Segmentierungs-Klasse folgen nicht
der SGML-konformen Paardarstellung der Tags (<seg>), sondern können projekt- und aufgabenbezogen definiert werden und haben die generische Form von <b_xx> und <e_xx>. Die Attribute, wie z.B. Überlappungen, Fremdsprache, Named Entity ersetzen jeweils die „xx“.
Innerhalb dieser Tags werden Annotationen gesetzt. Die Tags der lexikalischen Klasse
(<lex_tag>) entsprechen auch nicht der Paarschreibweise und verfügen nur über öffnende Tags.
Diese Tags definieren Attribute wie Zeitreferenzen, Auflösung von Kontraktion im Sinne von
Reduktion, Wortfragmente u.v.m.
Auf allen Hierarchiestufen können Kommentare in der SGML-konformen Weise eingefügt werden. Jedem Tag sind eine Menge von Attributen zugewiesen, deren Detaildefinition in [2.10]
nachgelesen werden kann. Das SGML-basierte Annotationsmodell wird durch die in (4) dargestellte BNF Syntax (nach [2.10]) definiert:
(4)
<utf>:== (<bn_episode_trans> | <conversation_trans>)
<bn_episode_trans>:== (<qualitaet> | <sektion>)*
<conversation_trans>:== (<qualitaet> | <turn>)*
<sektion>:== (<qualitaet> | <turn>)*
<turn>:== (<grenze> | <qualitaet> | <seg> | <lex_tags> |
[WORT_ANNOTATION])*
Seite 27
Die Syntax nach (4) formuliert eine mächtige Grammatik, mit der stark strukturierte Annotationen möglich sind. Der Ursprungsdomäne entsprechend ist die Möglichkeit der Unterscheidung
von größeren inhaltlich zusammenhängenden Nachrichtenblöcken (<bn_episode_trans>) und
kurzen Äußerungen (<conversation_trans>) gegeben. Durch die Möglichkeit, auf jeder Ebene der
Grammatik Angaben zur Qualität des Sprachsignalabschnitts zu annotieren (<qualität>), kann
auf schnell abwechselnde Signalqualitäten, wie etwa Hintergrundgeräusche, Sprecherwechsel,
Sprechstil u.v.m, reagiert werden. Der „*“ am Ende jeder Syntaxzeile bedeutet beliebige Wiederholung der Zeile. Diese Konstruktion erlaubt die Annotierung von beliebig langen Sprachsignalaufnahmen. Das folgende Annotationsfragment (5) stellt eine Instanz der Grammatik dar
und zeigt beispielhaft die Verwendung der SGML-Struktur.
(5)
<utf>
<conversation_trans <hintergrund typ=Musik level=niedrig>
<turn sprecher=weibl. START=X END=X4>
word_X1 word_X2
<b_ueberlappung START=X3 END=X4>
word_X3 word_X4
<e_ueberlappung>
</turn>
<turn sprecher=maennl. START=Y1 END=Y2>
<b_ueberlappung START=Y1 END=Y1>
word_Y1
<e_ueberlappung>
word_Y2
</turn>
</conversation_trans>
</utf>
Das Sprachsignalsegment, das mit der Annotation beschrieben werden soll, besteht aus einer
Abfolge von Wörtern (word_X1 bis word_X4, word_Y1 bis word_Y2) zweier Sprecher, wobei
word_X3, word_X4 und word_Y1 simultan gesprochen sind. Das Annotationsfragment ist gemäß der Definition (4)12 in das Klammerpaar <utf> und </utf> eingeschlossen, in das wiederum
die nächste Grammatikebene <conversation_trans> und </conversation_trans> eingebettet ist.
Seite 28
Auf dieser Ebene werden Qualitätsmerkmale des Sprachsignals annotiert, die über den gesamten
Zeitraum des <utf> reichen. Dort sind auch die am tiefsten eingeschachtelten Ebenen <turn> eingebettet, in der die Wortannotierung stattfindet.
Jedem Sprecher des Sprachsignalabschnitts wird ein <turn> zugewiesen, in dem neben der Sprecheridentifikation, Start- und Endzeitpunkt sowie die Simultanpassagen durch die Tags
<b_ueberlappung> und <e_ueberlappung> annotiert sind. Eine konkrete Instanz der Grammatik ist
in Abbildung 2-4 (nach [2.7]) dargestellt.
Abb. 2-4: Transkriptdarstellung des UTF-Annotationsformats
In diesem Annotationsfragment sind nur die Ebenen <turn> dargestellt. Es sind Äußerungen zweier Sprecher annotiert, die teilweise überlappende Abschnitte realisieren. Beide Sprecher werden detailliert zu Beginn eines
<turn> beschrieben, die überlappenden Abschnitte werden ebenfalls markiert. Interessant ist hier die Erweiterung
der Annotierung durch Named Entity-Tags (hier: für das Wort „congress“) und durch Kontraktion (hier: für „you
have“) sowie die Darstellung von Kommentaren in "{" -Schreibweise.
12 Die Darstellung in der Konvention von Pseudoprogrammiercods ist keine notwendige Bedingung von
SGML und dient nur der besseren Lesbarkeit. Eine völlig adäquate Darstellung des Annotationsfragments ist die folgende: <utf> <conversation_trans <hintergrund typ=Musik level=niedrig> <turn
sprecher=weibl. START=X END=X4> word_X1 word_X2 <b_ueberlappung START=X3
END=X4> word_X3 word_X4 <e_ueberlappung> </turn> <turn sprecher=maennl.
START=Y1 END=Y2> <b_ueberlappung START=Y1 END=Y1> word_Y1 <e_ueberlappung>
word_Y </turn> </conversation_trans> </utf>
Seite 29
Das in Abbildung 2-4 dargestellte Annotationsfragment zeigt die Annotierung zweier Sprecher,
die jeweils in einem eigenen <turn> abgebildet sind. Wie in (5) dargestellt, wird jeder Sprecher
zu Beginn seines <turn> detailliert beschrieben, inklusive der zeitlichen Segmentierung. An diesem Beispiel wird die Verwendung der Attribute der Segmentierungs-Klasse (<seg>) deutlich.
Das Wort „congress“ wird mit dem Tag <b_enamex> und <e_enamex> für Named Entity und dem
Wert „ORGANIZATION“ explizit annotiert. Auch die Verwendung des Attributes <kontraktion>
aus der lexikalischen Klasse <lex_tags> wird an den Beispielen „you have“ und „that is“ deutlich.
Obwohl das UTF-Annotationsmodell dem LDC Broadcast in Komplexität und somit in seiner
Annotationsmöglichkeit überlegen ist, existieren auch beim UTF auf Grund der turn-basierten
Ausrichtung Beschränkungen bezüglich einer flexiblen Verwendung und Integration neuer Annotationsebenen.
2.1.5.
Heterogeneous Relation Graphs (HRG)
Die Annotationsstruktur HRG ist ursprünglich für die Repräsentation von linguistischen Informationen für das Sprachsynthesesystem Festival entworfen worden, aber in [2.12] als ein allgemeingültiges Annotationsmodell vorgeschlagen worden. Ein HRG besteht aus einer Menge von
linguistischen Items, welche linguistische Entitäten wie etwa Wörter, Silben oder Phoneme repräsentieren. Diese Items werden durch Attribut-Wert-Matrizen (AVM) dargestellt und in relation structures organisiert. Die Relationenstrukturen können durch Listen oder Bäume kodiert
sein. Jedes Item kann zu mehreren Relationenstrukturen in Beziehung stehen, so kann ein Wort
zu Wortrelationen und zu syntaktischen Relationen gehören. Für jeden benötigten linguistischen
Typ existiert eine Relation.
Ein HRG beinhaltet alle Items und Relationen, die für die Beschreibung einer Äußerung benötigt
werden. Relationen bestehen aus Knoten und beschrifteten Kanten. Die Knoten enthalten keine
Informationen und stellen nur die Verbindung zu den linguistischen Items her. Die Items werden
durch AVMs dargestellt und beinhalten linguistische Objekte in Form von atomaren Werten
oder eingeschachtelten AVMs. In Abbildung 2-5 sind zwei einfache AVMs dargestellt. In (a) ist
die AVM für ein Wort dargestellt. Die Matrix besteht aus den drei Attributen POS für die syntaktische Tagging-Information, NAME für die orthographische Darstellung und FOCUS. Alle
Werte dieser drei Attribute sind atomar. In (b) ist eine AVM für ein Phonem dargestellt; es ent-
Seite 30
hält die Attribute NAME, PLACE OF ARTICULATION, VOICE, CONTINUANT und SONORANT. Die Werte der Attribute sind auch hier mit einer Ausnahme atomar. Der Wert für PLACE
OF ARTICULATION ist im vorliegenden Fall eine eingeschachtelte AVM, welche die zwei Attribute CORONAL und ANTERIOR trägt.
(a)
(b)
Abb. 2-5: Darstellung von linguistischen Objekten in HRG
Auf der linken Seite (a) ist die Darstellung einer AVM für ein Wort und auf der rechten Seite (b) für ein Phonem
dargestellt. Das Beispiel für die Phonemrepräsentation enthält eine eingeschachtelte AVM.
Die vereinfachte Darstellung in Abbildung 2-5 (aus [2.12]) reicht in der Praxis zu einer sinnvollen Annotation nicht aus. In der Grundform verfügen die Items, wie in Abbildung 2-6 (aus
[2.12]) dargestellt, über zwei Attribute, CONTENTS (für die Beschreibung der linguistischen
Objekte) und RELATIONS, in welcher die Relationen annotiert werden.
Abb. 2-6: Erweiterte Darstellung von linguistischen Objekten in HRG
Die erweiterte Darstellung zeigt die Repräsentation eines linguistischen Objektes mittels CONTENTS und RELATIONS. Das Attribut RELATIONS definiert die Zugehörigkeit zu Relation und somit den linguistischen Typ des
Items.
Seite 31
Beide Attribute enthalten wiederum eingeschachtelte AVMs. Bei dem Attribut RELATIONS
wird klar, dass die Definition von Typen nicht explizit vollzogen wird, sondern implizit durch
die Belegung in der entsprechenden AVM. In dem Beispiel in Abbildung 2-6 ist die Zugehörigkeit des in CONTENTS beschriebenen linguistischen Objekts zu WORD und SYNTAX definiert.
Die Verbindung zur temporalen Dimension erfolgt ebenfalls über eine eingeschachtelte AVM,
die dem Attribut TIMING zugewiesen wird. Diese AVM enthält die Attribute START, END und
DURATION, denen atomare Werte zugewiesen werden. Die Zeitinformationen können neben
solchen absoluten Werten auch mittels Funktionen über die Vorgänger definiert werden. In Abbildung 2-7 ist die graphische Repräsentation eines HRG, mittels dem die Silbenstruktur von
„strength“ annotiert ist, dargestellt.
Abb. 2-7: Graphische Darstellung von silbischen Strukturen mittels HRG
Darstellung der Silbenstruktur von „strength“. Die Phonemkette ist als lineare Liste dargestellt, während die Silbenstruktur als Baum repräsentiert ist. Jedem Knoten ist eine AVM zugeordnet, die atomaren Töchter des Baumes
teilen sich die AVMs mit denen der Phoneme.
Das Beispiel in Abbildung 2-7 (aus [2.12]) zeigt zwei sich überschneidende Relationen, Silbenund Phonemrelation. Die Phonemrelation ist als lineare Liste und die Silbenstruktur als Baum
kodiert. Jedem Knoten der Relationen werden Items in Form von AVMs zugewiesen. Die Töch-
Seite 32
ter des Baumes teilen sich die AVMs mit den Phonemen. Die AVMs beider Relationen sind mit
den Attributen START, END und DUR ausgestattet, wobei nur die AVM, die dem ersten Phonem
zugeordnet ist, über einen atomaren Wert für die Startzeit und Dauer verfügt. Die AVMs der folgenden Phoneme berechnen Dauer und Startzeit durch Funktionen aus dem ersten Element. Die
AVMs, die den Silbenknoten zugewiesen sind, errechnen alle Zeitwerte aus denen der Phoneme.
In Abbildung 2-8 ist ein kompletter HRG für die Äußerung "the drunkard is a social outcast"
dargestellt. Da die Visualisierungkomponente von Festival keine AVMs darstellen kann, sind
diese in der Struktur nicht enthalten.
Abb. 2-8: Annotation einer kompletten Äußerung mittels HRG
Kompletter HRG für die Äußerung „the drunkard is a social outcast“. Der HRG besteht aus den Relationen Phonem
und den entsprechenden Oberflächensegmenten, den hierarchischen Strukturen der metrischen und silbischen Bäume sowie der linearen Wortstruktur.
Wie in der schematischen Darstellung des HRG in Abbildung 2-7 formen auch in diesem Beispiel die Linien die Relationen. Die AVMs werden durch die entsprechenden Boxen symbolisiert. Der abgebildete HRG besteht aus fünf Relationen: Zwei Relationen bilden die
Phonemkette, welche aus einer Tiefenstruktur und einer Oberflächenstruktur besteht, darüber ist
die Relation der Silbenstruktur und die hierarchische metrische Struktur der ganzen Äußerung
sowie die lineare Abfolge der Wörter in Form einer Liste, annotiert.
Die Stärke dieses Annotationsmodells liegt in der Möglichkeit, sämtliche linguistischen Strukturen von der phonetischen bis hin zur semantischen Ebene mit einem Formalismus darzustellen.
Seite 33
2.1.6.
Das Annotationsmodell des MATE-Annotationssystems
Die MATE-Workbench ist ein System, dass für die Annotierung von gesprochener und geschriebener Sprache eingesetzt werden kann. Im Fokus steht allerdings die Annotation von gesprochenen Dialogdaten. Das System ist in Java1.2 implementiert und bietet daher prinzipiell
plattformunabhängige Anwendungsmöglichkeiten. Zu den Werkzeugen, die Benutzern zugänglich sind, gehören u.a. verschiedene, auch freidefinierbare, Stylesheets, die benutzerdefinierte
Annotationsmethoden zulassen, eine komplexe Suchmaschine sowie eine graphische Benutzerschnittstelle und Audioeditor. Der Kern des Systems ist ein XML-basiertes Annotationsmodell;
Annotationsguidelines gewährleisten den Austausch von Daten zwischen verschiedenen Anwendungen und Modellen.
Das Annotationsmodell erlaubt entsprechend dem XML-Standard eine streng hierarchische Anordnung der Datenstrukturen. Die verschiedenen Hierarchien werden in einzelnen Dateien gespeichert und durch sogenannte XML-Pointers verbunden, wodurch die Verbindungen
zwischen den Hierarchien aufgedrückt werden. Die Annotationen werden nach der in (6) spezifizierten Syntax gebildet:
(6)
< element attribute=wert />
Über das Schema (6) hinaus verfügt jede Ebene über spezifische Elemente. Würde das Annotationsschema auf die phonetische Ebene angewendet, würde eine Annotation wie in (7) entstehen:
(7)
< phone typ="a:" />
Weitere Informationen zu diesem Element, wie etwa Zeitmarken, werden als weitere Attribute
(start) und (end) innerhalb der eckigen Klammern notiert. Zu den annotierbaren Ebenen gehören
Prosodie, Morphosyntax, Dialogakte, Koreferenz, Kommunikationsphänomene und verschiedene mehr. Die prosodische Beschreibungsebene besteht aus 4 sogenannten Layern, von denen die
phonetische Ebene die unterste ist. Die weiteren Ebenen sind Beschreibung der Grundfrequenz-
Seite 34
kurve, phonologische Beschreibung der Intonation und prosodische Phrasierung. Die phonetische Ebene besteht wiederum aus 2 Layern mit den Elementen <syllable> und <phone>. In
Abbildung 2-9 (aus [2.15]) sind beide Annotationsschichten für das spanische Wort „casa“ dargestellt.
phone.xml
< phone id="phn_001" type="k" start="345" end="390" />
< phone id="phn_002" type="a" start="390" end="450" />
< phone id="phn_003" type="s" start="450" end="490" />
< phone id="phn_004" type="a" start="490" end="540" />
syllable.xml
< syllable id="sllbl_01" stress="&quot" href="phone.xml#id(phn_001) .. id(phn_002)" />
< syllable id="sllbl_02"
href="phone.xml#id(phn_003) .. id(phn_004)" />
Abb. 2-9: Phonetische Annotation im MATE-Annotationsmodell
Die Annotation ist in die zwei Layer phone.xml und syllable.xml aufgeteilt. Die Phoneme werden der Reihe ihres
Vorkommens nach nummeriert und mit Start- und Endzeitpunkt annotiert. Die Silben werden nach dem gleichen
Muster annotiert, darüber hinaus wird durch das zusätzliche Attribut stress die Betonung markiert. Die Zeitmarken
werden durch die Verbindung mittels href von den einzelnen Phonemen ererbt.
Die Annotation erfolgt durch Auflistung der linguistischen Objekte (Phoneme, Silben etc) und
deren Markierung mit Start- und Endzeitpunkten. Wie in der Abbildung ersichtlich ist, verfügt
das Element <phone> über die Attribute id, type, start und end, mit denen alle wichtigen Eigenschaften von Phonemen annotiert werden können. Das Element <syllable> verfügt über die Attribute id, stress, start und end. In der Silbenbeschreibung kommt eine der Stärken von XML zum
Ausdruck: Obwohl auch für die Silbenebene die Attribute start und end zulässig sind, werden sie
nicht benötigt, da diese Informationen der entsprechenden phonetischen Beschreibung mittels
Link direkt benützt werden können. Die Verwendung der zulässigen Elemente, deren Attribute
und Wertebereiche sind in einer separater Form ("Document Type Definition (DTD))"13, definiert. Für eine detaillierte Diskussion der gesamten Annotationsstruktur siehe [2.15].
13 Für jede Annotationsebene existiert eine DTD. Eine Auflistung aller DTDs, die in MATE benützt werden, findet sich in [2.15], S. 308ff.
Seite 35
Das MATE-Annotationsmodell verfügt über eine sehr hohe Flexibilität. Beliebig viele Annotationsebenen sind ohne Schwierigkeiten integrierbar. Durch die XML-basierte Notation wird ein
leichter Datenaustausch mit anderen Systemen und eine Adaption an weiterentwickelte Annotations- und Transkriptionsrichtlinien unterstützt. Das Gesamtsystem verfügt über ein sehr effizientes Such- und Abfragewerkzeug und eine graphische Benutzeroberfläche.
2.1.7.
Das Annotationsmodell des EMU-Datenbanksystems
Das EMU-Sprachdatenbanksystem besteht aus einem C++-Kern, in dem die grundlegenden
Operationen auf den Annotationen durchgeführt werden. Das System verfügt darüber hinaus
über einem graphischen Labeller und die Möglichkeit Tcl/Tk basiert Skripte einzuhängen. Das
EMU-System kann eine Vielzahl von Segmentierungsformaten (TIMIT, ESPS, Partitur, EMU
uva.) und Signalformaten (wav, nist sphere, au, aiff, ssff) importieren und verarbeiten und läuft
unter verschiedenen Unixdialekten und Windows9x/NT. Abfrageergebnisse können durch verschiedene Werkzeuge, wie etwa den Emu-Visualisierer, Statistikprogramme uvm., weiter verarbeitet werden.
Das EMU Annotationsmodell erlaubt eine hierarchische Anordnung von Annotationsebenen
(Tiers), wobei jede Ebene eine lineare temporale Ordnung erhält. Jede Ebene besteht aus einer
Abfolge von Tokens, die wiederum aus einem oder mehreren tatsächlichen Segmentetiketten bestehen können und optional mit Start- und Endzeitpunktmarkierungen relativ zum Sprachsignal
ausgestattet sind. Durch Verbindungen solcher Tokens entstehen Dominanz- und Assoziationsrelationen und damit Hierarchieebenen.
Die äußere Struktur des Annotationsmodells wird durch eine Annotationsdatei, in der die Verbindungen mit den korrespondierenden Labeldateien (xwaves-Format), in denen die Zeitmarken
der jeweiligen Segmente relativ zum Sprachsignal enthalten sind, realisiert. Eine DatenbankTemplatedatei enthält neben organisatorischen Angaben wie z.B. Art und Struktur der Segmentierungsdatei und Suchpfade, vor allem eine Definition der enthaltenen Hierarchieebenen und
Beziehungen, die nach folgender allgemeiner Struktur gebildet werden können:
Seite 36
1. Ebene:
äußerung
2. Ebene:
intonatorische phrase äußerung
3. Ebene:
intermediäre phrase
intonatorische phrase
4. Ebene:
wort
intermediäre phrase
5. Ebene:
silbe
wort
6. Ebene:
phonem
wort
7. Ebene:
phonetisch
phonem
Die abgebildete Hierarchie stellt die maximale Projektion einer Datenbank dar. In der Realität
sind dagegen oft nur Teilmengen dieser Hierarchie annotiert. In Abbildung 2-10 ist ein solches
Template dargestellt. Die Ebenenhierarchie, die im Template dargestellt ist, beginnt erst auf
Wortebene (Mutterknoten) und reicht über Silben-, Phonemebene bis auf die phonetische Ebene. Nach der Definition der Hierarchie schließen sich weitere Definitionen wie die Festlegung
der möglichen Instanzen der Segmenttypen (hier das phonetische Inventar), die Abbildung auf
das Sprachsignal und organisatorische Daten wie Speicherort an. Die Definitionen "! legal labels" ist für die Bildung von Suchanfragen von großer Bedeutung, denn nur die Merkmale, die
hier angegeben werden, können später abgefragt werden.
Die interne Struktur des Annotationsmodells (d.h. die Struktur der einzelnen Tiers) wird durch
die in (8) dargestellte Syntax gebildet:
(8)
Notation: [INDEX] [ETIKETT]
Die Verbindungen der Segmente aller Ebenen zum Sprachsignal werden mittels Zugriff über [INDEX] auf die phonetische Ebene und die korrespondierenden xwaves-Labeldatei realisiert, da die
Zeitmarken im xwaves-Signal verbleiben, während die Segmentlabels reproduziert werden.
Seite 37
! definition of levels
level Word
level Syllable Word
level Phoneme Syllable
level Phonetic Phoneme many-to-many
level VoiceOnset Phonetic
! definition of additional label types
label Word Text
! legal labels
legal Phonetic vowel A E I O U V a: e: i: o: u:
legal Phonetic stop p t k b d g
legal Phonetic fricative f s S T D v
! information about the format of label files
labfile Phonetic :extension lab :time-factor 1000
labfile VoiceOnset :extension vot :time-factor 1000
! location of files
path lab,vot c:\database
path sd,fb e:\signals
! associations between tracks and file extensions
track samples sd
track fm fb
Abb. 2-10: Darstellung einer EMU-Templatedatei
Ein Datenbank-Template ist eine Abfolge von Definitionen für Ebenenhierarchie, Labeltypen, zugelassenen Instanzen der Typen, Verweise auf die Sprachsignale, Suchpfade uvm.
In Abbildung 2-11 ist das Annotationsmodell in zwei unterschiedlichen Notationsarten dargestellt. Auf der linken Seite der Abbildung (a) ist das Wort „jude“ in einer Baumhierarchie (aus
[1.5]) annotiert und auf der rechten Seite (b) die schematische Tier-Repräsentation dargestellt.
Die annotierte Baumstruktur zeigt die Beziehungen zwischen der phonemischen und phonetischen Ebene und die Abbildung auf die Wortebene. Die Darstellung (b) der Abbildung zeigt die
gleichen Beziehungen, aber in der abstrakten Tier-Repräsentation.
Seite 38
e
as
hr
/P
tz
Sa
W
r
te
ör
en
lb
Si
e
em
on
Ph
(a)
(b)
Abb. 2-11: Das EMU-Annotationsmodells am Beispiel des Wortes „jude“
Auf der linken Seite ist eine konkrete Annotation („jude“) als Baum dargestellt. Ausgehend vom Mutterknoten sind
die phonemischen und phonetischen Ebenen dargestellt. Analog sind die Hierarchieebenen auf der rechten Seite
schematisch dargestellt.
Abb. 2-12: Darstellung der Annotationsebenen einer EMU-Annotationsdatei
Die Abbildung zeigt die Hierarchiestufen einer Annotation in EMU. Auf allen Stufen sind die Indizes notiert. Die
Hierarchie reicht von der obersten Stufe „Äußerung“ bis hinunter zur phonetischen Repräsentation.
Seite 39
Abbildung 2-12 (aus [2.2]) zeigt ein Beispiel einer EMU-Annotationsdatei. Die abgebildete
Struktur ist die Annotation für den Satz "the price range is smaller than any of us expected". Die
Hierarchiestufen in der Abbildung sind in einer Templatedatei (analog Abbildung 2-10) definiert und könnten für die hier vorliegende Annotation eine Struktur wie in (9) haben:
(9) utterance > intonational > intermediate > word > syllable > phoneme > phonetic
Daraus lässt sich unmittelbar die Dominanzrelation für die gesamte Annotationstruktur ableiten,
die in der EMU-Struktur separat annotiert wird und eine Form wie in (10) haben könnte:
(10) 8 7 5 2 4 1 0 10 9 13 15 12 11 16 18 17 19 21 20 23 22 26 28 25 24 30 32 31 34 33 36 35
Die in (10) abgebildete Dominanzbeziehung ist nur der Anfang des gesamten Satzes und stellt
die Beziehung zwischen den Wörtern "the price range" dar. Die Indexschreibweise kann zur
Verdeutlichung auch in einer Baumstruktur dargestellt werden und hätte dann die Form wie in
Abbildung 2-13.
8
7 L%
5 L-
42 L-
74 L-
[...]
[...]
2 the
13 price
26 range
4w
15 s
28 s
1D
10 @
0D
9@
12 p
18 r
21 aI 23 s
[...] [...] [...]
11 p 15 H 17 Or 19 r 20 aI 22 s
Abb. 2-13: Baumdarstellung der Dominanzbeziehung einer EMU-Annotation
Die Repräsentation in einer baumartigen Struktur zeigt die Dominanzbeziehung deutlicher als in der Notation aus
(10). Der Index 8 als Mutterknoten dominiert alle anderen Knoten des Baumes. Die Dominanzbeziehung reicht von
Knoten zu Knoten bis zu den terminalen Knoten.
Seite 40
Die Darstellung der Annotation in einer Baumstruktur zeigt die Dominanzbeziehung deutlicher.
Der Index 8, der als Mutterknoten die gesamte Äußerung repräsentiert, dominiert alle im Baum
folgenden Töchter. So dominiert etwa Index 8 alle Indizes (12, 18, 21, 23, 11,17, 19, 20, 22), die
auch von Index 15 dominiert werden. Darüber hinaus können auch Assoziationsbeziehungen
zwischen den Töchtern einer Ebene definiert werden.
Dieses „natürliche“ Annotationsmodell ermöglicht, in Verbindung mit Hierarchiestrukturen und
darauf arbeitenden Beziehungen, einen mächtigen Abfragemechanismus. Darüber hinaus ermöglicht dieses Modell einerseits eine leichte Überführung der Annotationen in andere Datenstrukturen (z.B. eine Überführung in das relationale Datenmodell, siehe [1.5]) und andererseits
eine Überführung fremder Daten- und Annotationsmodelle wie z.B. das BAS-Partiturformat
(siehe [http://www.shlrc.mq.edu.au/emu/partitur/partitur.html], in das EMU-Modell.
2.2.
Ein formales Grundgerüst für Annotationen
Aus den oben vorgestellten Annotationsstrukturen und -modellen ist ersichtlich, dass in den letzten Jahren viele Annotationssysteme und Werkzeuge entwickelt worden sind, die trotz eines
großen disziplinübergreifenden Bedarfs in der Mehrzahl proprietär sind. Daher ist in [2.2] der
Versuch unternommen worden, einen Standard für linguistische Annotationen zu entwickeln.
Mit diesem Ansatz haben Bird&Liberman ein formales Grundgerüst geschaffen, in das alle relevanten Annotationssyteme transformiert werden können. Die Arbeit wird in ihren Grundzügen
in diesem Abschnitt vorgestellt unter besonderer Berücksichtigung der Bewertung der Annotationsmodelle in Hinblick auf die Wahl eines Annotationsmodells für den in Kapitel 6 ("Das
Sprachdatenbanksystem IMSPhoBase, S. 102") vorgestellten Ansatz.
In Abschnitt 2.2.1. werden zunächst Anforderungen an ein formales Grundgerüst für ein Annotationsmodell vorgeschlagen und in Abschnitt 2.2.2. durch Definition des konkreten Annotationsmodells verifiziert. In Abschnitt 2.3. werden schließlich die in Abschnitt 2.1. vorgestellten
Annotationsmodelle in den allgemeinen Ansatz transformiert und bewertet. Damit kann gezeigt
werden, dass die eigentlich proprietären Annotationsmodelle einen gemeinsamen Kern haben
und somit in begrenzter Weise austauschbar sind.
2.2.1.
Anforderungen an ein formales Annotationsgerüst
Um ein formales Annotationssystem definieren zu können, muss zunächst von den konkreten
Seite 41
Daten und Modellen abstrahiert werden, um allgemeine Anforderungen, die als Mindeststandard erfüllt sein sollten, formulieren zu können. Die folgenden Überlegungen spielen nach [2.3]
eine zentrale Rolle und sollten beim Design von Annotationsmodellen und -systemen berücksichtigt werden:
1. Repräsentation von Teilinformation. Eine Annotation muss auch dann
wohlgeformt sein, wenn einzelne Beschreibungsebenen nicht vollständig
sind, insbesondere wenn die temporale Information unvollständig ist oder
nicht alle Signalsegmente annotiert sind (z.B. werden oft nur spezielle
phonetische Phänomene annotiert).
2. Kodierung von hierarchischen Informationen. Es stehen grundsätzlich
drei unterschiedliche Methoden für die Darstellung von hierarchischen
Informationen zur Auswahl. Die token-basierte Darstellung formuliert
explizit eine Mutter-Tochter-Relation zwischen den Segmenten. Die typenbasierte Darstellung drückt eine Hierarchierelation als abstrakte Tatsache
zwischen Typen aus (z.B. eine Relation zwischen Silben und Wörtern),
unabhängig von der tatsächlichen Realisierung durch einzelne Segmente.
Die graph-basierte Darstellung definiert die Relationen über Knoten und
Kanten.
3. Darstellung von Instanzen, Überlappungen und Lücken. Für die
Annotierung linguistischer Objekte gibt es verschiedene Notationsmöglichkeiten. Die Objekte können entlang der Zeitachse als sequentielle
nichtüberlappende Intervalle, als diskrete Instanzen, als Intervalle mit
Lücken
oder
Überlappungen
und
als
Kombination
aller
dieser
Möglichkeiten annotiert werden.
4. Zusammenhang zwischen Annotation und Sprachsignale. Obwohl die
verschiedenen Formate der Sprachsignale gewöhnlich eine komplexe
interne Struktur aufweisen und sich hinsichtlich ihres Standards (offen vs.
Seite 42
proprietär) unterscheiden, ist die zu Grunde liegende gemeinsame Zeitachse
die systematische Verbindung von Annotationen und Sprachsignaldaten.
Diese Zeitachse kann in allen Annotationen explizit enthalten sein, oder
mittels Indizierung propagiert werden.
Während die erste Forderung nach Wohlgeformtheit auch bei nicht vollständiger Annotation vor
allem bei Systemen, die Suche und Abfrage auf Annotationen erlauben, eine wichtige Rolle
spielt, sind die weiteren Forderungen allgemeinerer Natur, die im Folgenden an Hand des formalen Gerüsts nach Bird&Liberman umgesetzt werden sollen.
2.2.2.
Annotationsgraphen als formales Grundgerüst
Das im Folgenden vorgestellte Annotationsmodell basiert auf der Graphentheorie, der ein wohldefiniertes, mathematisches Konzept zu Grunde liegt.
2.2.2.1. Informelle Definition Annotationsgraph
Ein Annotationsgraph (AG) ist ein gerichteter, azyklischer Graph mit Kanten und Knoten. In
den Kanten sind die Annotierungen in Form von Typen und Etiketten markiert. Die Notation
folgt dem Schema in (11):
(11) TYPE/SEGMENT
In den Knoten sind die Indizierung und die optionalen Zeitreferenzen kodiert. Die Kanten als
Träger von Informationen über die Hierarchie (durch die Typisierung) und die Etiketten (Segmente), die auch als Teilinformation enthalten sein können, erfüllen die Kriterien 1, 2 und 3
(nach Abschnitt 2.2.1.). Die Knoten als Träger von Index und Zeitmarken erfüllen das Kriterium
4. In Abbildung 2-14 ist ein einfacher Annotationsgraph dargestellt, der nur über die zwei Annotierungebenen (Typisierung) Phonem (P/) und Wort (W/) verfügt. Der AG repräsentiert die
Annotation für die Wörter "in den" durch sechs Knoten, die alle über eine temporale Abbildung
verfügen.
Seite 43
P/e:
P/I
2
P/d
P/n
5.240
4
5
5.450
5.550
P/n
P/
0
1
3
4.120
5.150
5.420
W/In
6
5.700
W/de:n
Abb. 2-14: Darstellung eines Annotationsgraphen
Der AG stellt die Annotierung für die Worte "in den" dar. Es sind Wortannotierungsebene (W/) und Phonemannotierungsebene (P/) dargestellt. Der AG besteht aus 6 Knoten, die alle Zeitinformation enthalten.
Die Benennung der Kanten erfolgt nach Definition (11): Die oberen Kanten in der Abbildung
(P/I, P/n, P/d, P/e:, P/n) repräsentieren die phonetische Annotierungsebene und die unteren Kanten (W/In, W/de:n) die Wortannotierungsebene.
2.2.2.2. Formale Definition Annotationsgraph
Sei T eine Menge von Typen, wobei jeder Typ in T eine nicht leere Menge von Elementen darstellt und L der Etikettenraum, der aus der Vereinigung dieser Mengen hervorgeht, so dass die
Notation eines Labels l aus L ein Paar der Art typ/etikett ist, dann können Annotationsgraphen
wie folgt definiert werden:
Definition 1: Ein AG G über einer Etikettenmenge L und einer Knotenmenge N ist eine Menge von Tripeln der Form 〈n1, l, n2〉, l ∈L und
n1, n2 ∈N, so dass folgende Bedingungen erfüllt sind:
1. 〈N, {〈n1, n2〉|〈n1, l, n2〉 ∈G }〉 sei ein gerichteter
azyklischer Graph
2. τ: N −> ℜ sei eine ordnungserhaltende Abbildung, die Knoten
aus N Zeitpunkte zuweist.
Die Menge M aller so definierten AGs heißt eine Algebra (Definitionen über Ringe und Algebren, [2.19] S.44 ff.). Eine Algebra kann nichtleere Systeme S von Teilmengen von M darstellen
und ist abgeschlossen für Vereinigung, Schnitt und Komplement. Eine Algebra entspricht den
Anforderungen aus Abschnitt 2.2.1., dass auch eine Teilmenge (Teilinformation) aus der Ge-
Seite 44
samtmenge der AGs ein wohlgeformter AG sein muss. In Definition 1 ist keine Aussage über
eine Verbindung zwischen den AGs oder einem Anker (temporaler Offset) gemacht. Durch diese allgemeine Definition erhält das Konzept der Annotationsgraphen seine Mächtigkeit. In der
Praxis werden allerdings aus Gründen einer einfacherer Verarbeitung Anker eingesetzt.
Definition 2: Ein geankerter AG G über eine Etikettenmenge L und einer
Knotenmenge N ist ein AG (nach Definition 1), der folgende Bedingungen
erfüllt:
1. wenn n ∈N ist, so dass 〈n, l, n’〉 ∉G für alle l ∈L, n’ ∈N,
dann τ: n —› r ∈ℜ
2. wenn n ∈ N ist, so dass 〈n’, l, n〉 ∉G für alle l ∈L, n’ ∈N,
dann τ: n —› r ∈ℜ
Durch diese Definition wird die Mächtigkeit der AGs in der Art eingeschränkt, dass nun allen
Knoten Zeitreferenzen zugewiesen werden können. Damit ist die Menge aller AGs nur noch gegen Vereinigung abgeschlossen, erfüllt aber die Anforderung nach einer gemeinsamen Zeitbasis
(nach Definition, Abschnitt 2.2.1.).
Nach der Definition von Kanten und Etiketten werden auf den Knoten zwei Vorgängerrelationen
definiert, die sich auf die Graphenstruktur (<s) und auf die temporale Struktur (<t) beziehen.
Definition 3: Ein Knoten n1 ist struktureller Vorgänger von n2, (n1 <s n2),
wenn es eine Verbindung von n1 zu n2 gibt.
Ein Knoten n1 ist temporaler Vorgänger von n2, (n1 <t n2),
wenn τ(n1) <t τ(n2).
Beide Relationen in Definition 3 sind transitiv. Die Mischung beider Vorgängerrelationen führt
zu einer allgemeineren Vorgängerrelation ”<”, die in Definition 4 formuliert wird.
Definition 4: Die binäre Vorgängerrelation < auf Knoten ist der transitive
Abschluss gegenüber der Vereinigung von <s und <t.
Aus diesen Definitionen von Knoten werden analog die Definitionen von den Kanten abgeleitet.
Seite 45
Es wird die Inklusion für die Graphenstruktur ( ⊃s) und für die temporale Struktur ( ⊃t) wie folgt
definiert (siehe auch [2.19], Definitionen über Relationen, S.12, ff).
Definition 5: Eine Kante p= 〈n1,n4〉 inkludiert (⊃s) eine Kante
q= 〈n2,n3〉, gdw. n1 <s n2 und n3 <s n4.
Eine Kante p inkludiert (⊃t) q, gdw. n n1 <t n2 und n3 <t n4.
p
q
n1
n1 < n2
n2
n3
n1 < n2
n4
Abb. 2-15: Formale Darstellung eines Annotationsgraph
Der einfache AG besteht aus 4 Knoten und den zwei Kanten p und q. Zwischen den Knoten n2 und n1 sowie zwichen n4 und n3 besteht eine allgemeine Vorgängerrelation nach Def. 4. Die Kante p inkludiert die Kante q nach
Def. 5.
Mit dem AG aus Abbildung 2-15 kann eine Hierarchie zwischen 2 Silben und einem Wort formuliert werden, wobei die Kante p=〈n1,n4〉 der Wortkante (W/wort) entspricht und die Kanten
q1=〈n1,n2〉 und q2=〈n2,n3〉 den Silbenkanten (S/silb1, S/silbe2).
Analog zu Definition 4 wird die Inklusion als allgemeine Teilmengenrelation ”⊃” definiert.
Definition 6: Die Inklusion ⊃ ist eine binäre Relation über Kanten, die den
transitiven Abschluss gegenüber der Vereinigung von ⊃s und ⊃t darstellt.
Die sechs Definitionen bilden das Konzept der Annotationsgraphen. Demnach besteht ein Annotationsgraph aus einer Menge von Knoten, Kanten und Etiketten. Die Annotationsgraphen
werden in der Praxis als geankerte AGs realisiert, dass heißt es gibt keine AGs, die ohne Zeitreferenz und ohne Verbindung zu einem anderen AG sind; ebenso gibt es keine vagabundierenden
Kanten. Über die Abbildungen der Knoten in die zeitliche Domäne wird die Verbindung zum
Sprachsignal (Zeitreferenz) hergestellt. Wenn alle Knoten Zeitreferenzen enthalten, so spricht
Seite 46
man von einem "total-geankerten" AG. Die Definitionen von Beziehungen über Kanten können
unter Berücksichtigung sowohl der temporalen als auch der strukturellen Dimension stattfinden.
Durch strukturelle Beziehungen über Kanten und Knoten können linguistische Hierarchieebenen und Dominanzrelationen ohne Berücksichtigung der temporalen Dimension abgebildet werden.
2.2.2.3. Indizierung
Da das Konzept der AGs nicht auf einem Datenmodell wie etwa dem relationalen Datenmodell
([4.2]) beruht, in dem Annotationen in geeignete Stücke aufgeteilt und indiziert werden können14, muss für eine effiziente Verwaltung (und auch Suche) ein Indizierungsformalismus verwendet werden, der die natürlichen Strukturen der Graphentheorie ausnützt. Ein effizienter
Verwaltungs- und Zugriffsmechanismus ist umso wichtiger, je größer die annotierte Datenmenge wird. Bird&Liberman haben drei Indizierungsverfahren time-local index, type-local index
und hierarchy-local index vorgeschlagen auf den AGs wie folgt definiert:
time-local index: Bei dieser Methode werden die AGs in Bereiche von
Zeitintervallen unterteilt. Es sei ri ∈R eine Sequenz von Zeitreferenzen und
[ri, ri+1) das Zeitintervall, das die Sequenz enthält. Jeder Kante werden
solche aneinander grenzende Intervalle zugeordnet, wobei die Kanten zu
< rq) geankert
{[rp, rp+1), [rp+1,
Knoten gehören, die durch die Zeitpunkte rp und rq (mit rp
sind. So entstehen Mengen von Intervallen der Art
rp+2),...,
[rq-1, rq)}, denen die Kanten zugewiesen werden. Um auf diese
Mengen von Zeitintervallen auch bei nur partieller temporaler Information
verweisen zu können, werden die Zeitmarken ”greatest lower bound” (glb)
und ”least upper bound” (lub)15 zu einer Kante definiert. Beide Zeitmarken
verweisen auf einen geankerten Knoten, von dem aus eine Kante erreicht
werden kann.
14 Wie etwa im relationalen Modell, in dem alle Daten in Tabellen abgelegt werden und somit „automatisch“ indiziert werden.
15 glb und lub definieren also jeweils temporale Unterkanten und Oberkanten über Folgen von Knoten
und Kanten und bilden somit Zeitintervalle. Die formale Definition von glb und lub kann in [2.2] nachgelesen werden.
Seite 47
Der type-local index ist in gleicher Weise wie der ”time-local index”
definiert, nur mit dem Unterschied, dass die Kanten nicht durch Zeitpunkte,
sondern durch die Benennung der Typen der Kanten partitioniert werden.
Bei dem hierarchy-local index wird durch eine Dominanzrelation, die auf
der Inklusion (siehe Definition 6, auf Seite 46) basiert, eine geordnete
Menge aller Typen erzeugt. Durch diese Dominanzrelation wird eine
implizite hierarchische Struktur expliziert.
Die Wahl der Indizierungsmechanismen ist sehr stark abhängig von der Anwendung. So ist ein
hierarachy-local index bei flachen Datenstrukturen nicht erforderlich. Bei der Auswahl eines Indizierungsmechanismus ist grundsätzlich darauf zu achten, dass die elementaren Strukturen der
Indizierung die Konstruktion der Abfragemechanismen und -sprache im Voraus festlegen.
Den time-local index verwendet man typischerweiser, um Überlappungen bzw. ”Inklusions”-Relationen zu berechnen. Um alle Kanten zu finden, die eine bestimmte Kante p überlappen, wird über eine Liste von Zeitintervallen, die p umfassen, iteriert und alle Kanten, die in dem
time-local index zu finden sind, gesammelt. Anschließende Tests bestimmen dann die Art der
Überlappung ( ⊃s oder ⊃t). Der time-local index ist in der ersten prototypischen Realisierung
dieses Konzeptes der Annotationsgraphen implementiert ([2.22]). Die Konstruktion des time-local index ist in Abbildung 2-16 (nach [2.2]) dargestellt.
Abb. 2-16: Konstruktion des time-local index in AGs
Die Abbildung zeigt einen Ausschnitt aus dem UTF Fragment, das auf Seite 26 diskutiert wurde. Die ersten zwei
Spalten zeigen die Zeitintervalle, die erzeugt worden sind, dann folgen die Indizes jeweils vor der Zeitmarke jeder
annotierten Zeile.
Seite 48
Das in der Abbildung dargestellte Fragment ist bereits in die AG-Darstellung überführt worden
(vgl. Seite 26), was durch Hinzufügen von Knotenindizes (Ergänzung der ursprünglichen Zeitreferenzen) und Umwandlung der Annotierungen in die Kantendarstellung sichtbar ist. Die Annotierung von Metadaten erfolgt durch Duplizierung der Knoteninformation und einer
entsprechenden Anreicherung. Der neue time-local index (erste zwei Spalten) besteht aus vier
Zeitintervallen, die jeweils aus den vorhandenen Zeitreferenzen nach Definition durch glb und
lub16 generiert worden sind. In dieser Darstellung ist gut zu erkennen, dass die generierten Indexkanten mehrere ursprüngliche Kanten überspringen. Zum Beispiel überspannt die dritte Indexkante die eingebettete Annotationsstruktur, die sich zwischen den Knoten 13 und 21
aufspannt. Der time-local index kann, wie in diesem Beispiel deutlich wird, benützt werden, um
z.B. Überlappungen sichtbar zu machen (der dritte Index überspannt die Simultanpassage beider
Sprecher).
Das Konzept der Annotationsgraphen ist mit den Definitionen 1 bis 7 und der Formulierung eines Indizierungsschemas vollständig definiert.
2.3.
Annotationsmodelle in der Darstellung als AG
Die in Abschnitt 2.2. vorgestellte Annotationsstruktur beschreibt auf Grund ihrer Allgemeingültigkeit, insbesondere durch die Abstraktion von Signal- und Labeldateiformaten, einen sehr
mächtigen Formalismus. Dieser Formalismus ist darüber hinaus gekennzeichnet durch ein klares mathematisches Konzept, das den Entwurf eines stark strukturierten und effizienten Abfragemechanismus ermöglicht. Auf Grund der Allgemeingültigkeit des Ansatzes ist es z.B.
möglich, einen Annotationsgraphen auf jede beliebige Beschreibungsstruktur abzubilden. Ein
Beispiel für eine solche Umsetzung ist in Abbildung 2-17 und 2-18 gezeigt. In Abbildung 2-17
ist ein Annotationsgraph dargestellt, der für die Annotierung "she had your ..." die Phonem- und
Wortebene angibt.
16 Siehe Fußnote 15
Seite 49
P/ac
P/sh
2
P/iy
P/hv
3270
P/h
4
5
6160
8720
P/y
P/dcl
7
P/axr
10173
0
1
3
6
8
0
2360
5200
9680
11077
W/she
P/your
W/had
Abb. 2-17: Annotationsgraph für "she had your ..."
Der Annotationsgraph ist einem Annotationsfragment des TIMIT Korpus entnommen ([2.2]), die Konstruktion des
Annotationsgraphen folgt [2.3]. In dem Graphen sind die Ebenen für Phoneme und Wörter annotiert.
Der AG repräsentiert ein Annotationsfragment, welches eine Struktur aufweist, die für segmentdateienbasierte wie es für Annotatonsmodelle (siehe BAS, EMU) typisch ist. In [2.2], [2.3] und
[2.4] wird gezeigt, dass alle Annotationsmodelle, die auch in Abschnitt 2.1. diskutiert worden
sind, in solche Annotationsgraphen überführt werden können. Somit kann das Konzept der Annotationsgraphen auch als eine Meta-Repräsentationsebene formuliert werden, denn die Graphenstruktur kann wiederum in jede adäquate Schreibkonvention überführt werden, wie in
Abbildung 2-18 am Beispiel von XML gezeigt wird.
<annotation>
<arc> <source id="0" offset="0"/>
<xlabel att_1="P" att_2="h"/>
<target id="1"
offset="2360"/> <arc/>
<xlabel att_1="P" att_2="sh"/>
<target id="2"
<xlabel att_1="P" att_2="iy"/>
<target id="3"
<xlabel att_1="W" att_2="she"/>
<target id="3"
<xlabel att_1="P" att_2="hv"/>
<target id="4"
<xlabel att_1="P" att_2="ac"/>
<target id="5"
<xlabel att_1="P" att_2="dcl"/>
<target id="6"
<xlabel att_1="W" att_2="had"/>
<target id="6"
<xlabel att_1="P" att_2="y"/>
<target id="7"
offset="10173"/><arc/>
<xlabel att_1="P" att_2="axr"/>
<target id="1"
<xlabel att_1="W" att_2="your"/>
<target id="1"
< annotation />
Abb. 2-18: Darstellung eines Annotationsgraphen in XML-Konvention
Durch die Überführung eines Annotationsgraphen in eine XML-basierte Dateienstruktur wird für jeden Knoten des
AGs eine eindeutige Nummer (id) und für die Kanten jeweils eine Zeile mit Start- und Zielknoten eingeführt. Die
Informationen der Knoten und Kanten werden durch Attribute des Elements source, xlabel und target repräsentiert.
Die Umsetzung des Annotationsgraphen in eine Dateistruktur erfolgt, indem für die Indizes aller
Seite 50
Knoten eindeutige Bezeichner (id) gewählt und deren Kanten auf die Elemente source und target
abgebildet werden. Die Zeitinformationen werden als zusätzliches Attribut (offset) zum jeweiligen Knoten annotiert. Die Eigenschaften der typisierten Kanten werden auf die Attribute att_1
und att_2 des Elements xlabel abgebildet.
Einer der Vorteile dieser Struktur liegt in der leichten Verwaltung solcher Datenstrukturen.
Müssen neue Annotationen, unabhängig von ihrer Art, nachträglich eingetragen werden, so können diese am Ende einer Datei angehängt werden. Da bei einer Annotationsstruktur wie in Abbildung 2-18 keine zeitliche Reihenfolge mit der Abfolge der einzelnen Einträge verbunden ist,
entstehen keine Probleme mit der temporalen Sortierung, wie es etwa bei Annotationsmodellen
der Fall ist, die auf Labeldateien basieren. Darüber hinaus kann durch die volle temporale Orthogonalität der Annotationsebenen ein Grad von Unabhängigkeit zwischen Annotationsebenen
erreicht werden, der ein nahezu beliebiges Einfügen neuer Annotationsebenen ermöglicht.
Obwohl ein Abfragemechanismus bisher nur in Ansätzen besteht17 und noch keine Möglichkeiten aufgezeigt worden sind, Metadaten über Sprecher, Texte, etc, explizit mit einer Annotierung
in Annotationsgraphen zu verwalten, bildet dieses Grundgerüst einen universellen Ansatz für
Annotationen aller Art.
2.4.
Zusammenfassung der Annotationsmodelle und -systeme
Abschließend sollen alle hier vorgestellten Modelle zusammengefasst und nach den in [2.3] aufgestellten Kriterien beurteilt werden. Die Kriterien sind Allgemeingültigkeit und Einfachheit,
Such- , Abfrage- sowie Wartungsmechanismen.
Allgemeingültigkeit, Einfachheit. Ein Annotationssystem sollte mächtig
genug sein, um alle gebräuchlichen Arten linguistischer Annotation sowie
möglicher Erweiterungen umfassen zu können, ohne aber unnötig komplexe
Strukturen zu benutzen. Annotationen sollten publizierbar und somit
wechselseitig
verständlich
und
einsetzbar
sein,
unabhängig
von
17 In [2.20]und [2.21]sind Abfragemechanismen immer nur als Fragmente eines datalogic-Formalismus
(Prädikatenkalkül erster Ordnung) dargestellt worden. Erst mit der Architektur von ATLAS ([2.22])
wird ein durchgängig definierter Abfragemechanismus entworfen. Siehe auch [http://www.nist.gov/
speech/atlas]
Seite 51
Entwicklern, Disziplinen, Computersystemen und Zeiträumen. Darüber
hinaus sollten Annotationssysteme modular und offen genug sein, um
weitere Entwicklungen in diesem Bereich aufnehmen zu können; dazu
gehören auch entsprechende Schnittstellen, um die Entwicklung und
Anbindung von spezifischen Tools zu ermöglichen. Alle Arten von
Information, auch Metadaten, sollten aufgenommen werden können.
Suche- und Abfragemöglichkeit. Ein Annotationssystem soll einen
effizienten algebraischen Abfragemechanismus enthalten, wobei komplexe
Abfragen
aus
wohldefinierten
Kombinationen
einfacherer
Abfragen
zusammensetzbar sein sollten. Die Ergebnisse solcher Abfragen sollten
wohldefiniert sein und somit selbst Annotationen darstellen, d.h. das
Ergebnis einer Korpusanfrage ist wieder ein Korpus. Damit sind auch
partiell vorliegende Annotationen ebenso verarbeitbar wie komplexe und
vollständige Annotationen. Die Grundlage des Abfragemechanismus ist ein
Indizierungsschema, das es erlaubt, verschieden große Teilkorpora des
Annotationssystems mit konstantem Aufwand zu durchsuchen. Ein
Annotationssytem
sollte
Projektionen
von
Beschreibungsebenen
unterstützen, so dass Ebenen ausgeblendet werden können.
Wartungsmöglichkeiten.
Die
Erstellung
von
großen
skalierbaren
Datenbanken ist teuer; um einen dauerhaften Betrieb gewährleisten zu
können, müssen Methoden und Möglichkeiten vorgesehen werden, um
Struktur und Daten dauerhaft konsistent zu halten, auch wenn neue Daten
und Beschreibungsebenen hinzukommen. Im Idealfall sollten Referenzen
auf frühere, abgeänderte oder überschriebene Daten erhalten bleiben, so
dass weiterhin Abfragen darauf möglich sind. Annotationsebenen sollten
orthogonal oder zumindest nur an einem Punkt miteinander verbunden sein,
damit Neueinträge, Änderungen oder Löschen keine Korrekturen in
anderen, assoziierten Annotationsebenen nach sich ziehen. Annotationen
von temporär unterschiedlichem Material sollten so modular sein, dass die
Seite 52
Überarbeitung eines Bereiches nicht eine globale Modifikation nach sich
zieht. Um einen wissenschaftlichen Gebrauch zu gewährleisten, sollte es
möglich sein, dauerhafte Referenzen zu definieren, um Ergebnisse
nachvollziehbar zu halten.
Das in Abschnitt 2.2. dargestellte formale System "Annotationsgraph" erfüllt diese Anforderungen. Bird&Liberman haben die Allgemeingültigkeit ihres Ansatzes gezeigt; der Grundstein für
ein Abfragesystem sowie das Fundament für die Pflege und Haltbarkeit ist in dem Grundgerüst
gelegt worden (siehe Abschnitt 2.3.).
Diejenigen Annotationsmodelle, die eine dem Annotationsgraphen ähnliche Grundstruktur aufweisen, wie etwa HRG und MATE, erfüllen mit wenigen Abstrichen die aufgestellten Anforderungen ebenfalls. Während die Forderung nach Allgemeinheit und Unabhängigkeit bei MATE
durch die Implementierung in Java gegeben ist, fehlt bei HRG allerdings eine Abfragekomponente. Dieser Mangel ist allerdings darauf zurückzuführen, dass die HRG ursprünglich nicht als
Annotationsmodell für ein Sprachdatenbank- bzw. Annotationssystem entworfen worden ist,
sondern als Textrepräsentationsmodell in einem Sprachsynthesesystem.
Annotationsmodelle, wie BAS-Partitur, LDC und UTF, die als reine Annotationsformalismen
entworfen worden sind, ohne als Grundlage für ein Annotationssystem zu dienen, erfüllen ebenfalls nicht den gesamten Anforderungskatalog. Während diese Modelle die Forderung nach Allgemeinheit - Offenheit für alle denkbaren Annotationen, Austauschbarkeit usw. - noch erfüllen,
können Forderung, die an ein Annotationssystem gerichtet sind, naturgemäß nicht erfüllt werden. Allerdings könnten auf den SGML-basierten Modellen LDC und UTF durchaus mächtige
Abfrageformalismen definiert werden.
Das Annotationssystem, dem das CHAT zu Grunde liegt, enthält viele Methoden und Möglichkeiten zur Analyse und Annotierung; ein Abfragemechanismus dagegen ist nicht enthalten. Das
System erfüllt die Forderungen nach Allgemeinheit, d.h. nach multiplen Annotationsmöglichkeiten, ist allerdings auf Grund der wenig starken Strukturierung seines Modells nur sehr eingeschränkt als Recherchewerkzeug zu verwenden.
Das Annotationsmodell, das dem EMU-Sprachdatenbank-System zu Grunde liegt, erfüllt die
formulierten Anforderungen in vielen Punkten. Durch das flexible, multiebenen-basierte Modell
können beliebige Annotationsebenen eingebunden, verwaltet und abgefragt werden.
Seite 53
In diesem Kapitel sind viele Annotationsmodelle und -systeme diskutiert worden, aber nur das
MATE-System und das EMU-System sind im Augenblick weitverbreitete und benutzte Systeme.
Der theoretisch orientierte Vorschlag von Bird&Liberman (AGs) besitzt zwar sehr starke Ausdrucksmöglichkeiten, aber ein korrespondierendes System ([2.22]) ist gerade erst im Aufbau.
Der Formalismus von Taylor&Black (HRG) wird zwar in Festival eingesetzt und erfährt damit
auch eine große Verbreitung, verfügt aber nicht über Werkzeuge zum Kreieren, Abfragen und
Zugreifen auf annotierte Sprachdaten seitens möglicher Benutzer. Das MATE-System verfügt,
bedingt durch die XML-Repräsentation, über eine sehr mächtige Repräsentationsform, die zusammen mit einem Queryprozessor zu einer sehr mächtigen Abfragemethode vereinigt ist.
Das EMU-System ist, obwohl mit weit weniger mächtigen Abfragemethoden als MATE ausgestattet, nach jetzigem Kenntnisstand das einzige im Augenblick eingesetzte System, das Methoden zur Erzeugung, Management, Abfragen und Analyse von Sprachdatenkorpora enthält, in
vollem Umfang frei verfügbar ist und nach Aussage der Autoren in einem großen Bereich von
Sprachdatenbank-Projekten eingesetzt wird.
In diesem Kapitel wurde gezeigt, dass das formale System "Annotationsgraphen" als eine MetaRepräsenationsebene alle diskutierten Annotationsmodelle darstellen, importieren auch exportieren kann. Des Weiteren wurde dargelegt, dass Annotationsgraphen den formulierten Anfordungen genügen. Daraus ist zu schließen, dass auch die unter 2.2. dargestellen
Annotationsysteme in der Darstellung als Annotationssgraphen diesen Anforderungen entsprechen, wenn auch Mängel einzelner Modelle in der Meta-Repräsentationsebene naturgemäß nicht
ausgeglichen werden können.
Seite 54
KAPITEL 3
Annotierungs- und Segmentierungssyteme
Zur Erzeugung von Annotationsebenen, wie sie in Kapitel 2 beschrieben worden sind, gibt es
viele Möglichkeiten und Systeme.18 Prinzipiell lassen sich die Annotierungssysteme unterteilen
in computergestützte Systeme, welche die manuelle Annotierung auf geeignete Weise organisieren, und automatische Annotierungssysteme. Systeme zur manuellen Annotierung wie etwa
ein Partitureditor (Abschitt 2.1.1. und 3.1.) haben in aller Regel mangels eines direkten Zugriffs
auf das Sprachsignal keine Möglichkeit, die beschriebenen linguistischen Objekte und Phänomene bereits zu segmentieren, d.h. die direkte Abbildung zum Sprachsignal mittels Zeitmarken
herzustellen. Ausnahmen davon stellen Programme zur Visualisierung von Sprachsignalen wie
z.B. xwaves19, Praat20 und Transcriber21 dar, die auf Grund einer Synchronisation zwischen
Sprachsignal und editierbaren Segmentspuren Annotierung und Segmentierung auf allen Ebenen, die mit der "wave-Darstellung" des Sprachsignals in Zusammenhang stehen, erlauben. Ein
Nachteil bei der Verwendung solcher Systeme liegt in der sehr geringen Mächtigkeit der Annotierungsmerkmale gegenüber speziellen Editoren wie den verschiedenen Partitureditoren.
Bei den automatischen Annotierungssystemen handelt es sich im Grunde immer um Segmentierungsverfahren, da sie zusätzlich zum Sprachsignal noch eine orthographische Repräsentation,
d.h. die für den menschlichen Sprecher dieser Sprache einfachste Form einer Annotierung, des
Sprachsignals benötigen, um ausreichend gute Ergebnisse zu liefern. Das Ergebnis solcher automatischer Verfahren ist in aller Regel beschränkt auf Phonem- und Wortebene. Es finden sich
18 [http://morph.ldc.upenn.edu/annotation/]
19 Kommerzielle Software zur Visualisierung und Analyse von Sprachsignalen, Entropic Research Inc.
600 Pennsylvania Avenue, SE, Suite 202, Washington, DC 20003. Seit 1999 Microsoft Inc.
20 Freie Software zur Visualisierung und Analyse von Sprachsignalen. [http://www.fon.hum.uva.nl/praat]
21 Freies Softwarepacket zum Segmentieren und Transkribieren. [http://www.etca.fr/CTA/gip/Projets/Transcriber]
Seite 55
aber auch Systeme, die aus der Kombination von Ergebnisse und externen Ressourcen Silbenund Tag-Ebenen produzieren können.
Werden solche Systeme dagegen ohne orthographische Eingabe betrieben, so handelt es sich um
reine Spracherkennungssysteme, die beim augenblicklichen Forschungsstand noch keine ausreichend gute Ergebnissen produzieren ([5.6]). In letzter Zeit sind vermehrt Anstrengungen unternommen worden, "reine Annotierungssysteme" zu implementieren, die nicht ausschließlich auf
Spracherkennungstechnologie aufbauen. Zu dieser Forschungsrichtung gehört z.B. das System
ALPS ([3.1]), das keine orthographische Repräsention benötigt und eine hybride Architektur
aufweist. Der Kern des Systems besteht aus Neuronalen Netzen (zur Klassifizierung von artikulatorisch-akustischen Eigenschaften); die Abbildung der phonetischen Eigenschaften auf tatsächliche Phoneme und die Phonemsegmentgrenzen werden durch Hidden Markov Modelle
(welche als Basistechnologie der meisten herkömmlichen automatischen Systeme dienen) realisiert. Diese Systeme erreichen in Laborexperimenten bereits gute Ergebnisse, bedürfen allerdings für den breiten Einsatz noch einiger Entwicklungsarbeit.
3.1.
Manuelle Annotationsverfahren - Das System DIDA
Als Vertreter der manuellen, computerunterstützten Werkzeuge soll der Partitureditor DIDA22,
der am Institut für Deutsche Sprache (IDS) entwickelt worden ist ([3.2],[3.3]), vorgestellt werden. Der Partitureditor ist das grundlegende Werkzeug für die in Kapitel 5 ("Annotationssystem
am IDS, S. 76") beschriebene Annotationsinfrastuktur.
Das System DIDA23 geht allerdings über die eigentliche Funktion eines Partitureditors hinaus
und stellt ein computerunterstütztes Werkzeug zur Erfassung und Verwaltung von transkribierten Gesprächsdaten dar, wobei die Verwaltung durch eine integrierte Datenbank realisiert ist.
Ein Mechanismus erlaubt es, bereits vorhandene Transkripte zu sperren, falls andere Benutzer
daran arbeiten. Neueste Entwicklungen unterstützen durch die Integration eines Audioeditors
die Arbeit des Transkribenten, in dem ein komfortables Anhören mit Wiederholmöglichkeit eines Sprachsignals ermöglicht wird.
22 [http://www.ids-mannheim.de/prag/dida/]
23 DIDA ist ein Akronym für DIskurs DAtenverarbeitung.
Seite 56
Das System zeichnet sich durch die folgenden Merkmale aus:
• Das Partiturformat ermöglicht es, jedem an einem Gespräch Teilhabenden
eine eigene Sprecherzeile zuzuordnen. Die Verschriftung erfolgt in literarischer Umschrift, die, auf das orthographische System gestützt, durch Ergänzungen mit Sonderzeichen erweitert ist.
• Jeder Sprecherzeile können beliebig viele Kommentarzeilen hinzugefügt
werden, um Metadaten über die Kommunikation zu annotieren.
• Die Kapazität von Sprecherzeile und Kommentarzeile ist letztlich nur durch
den Speicher des Computersystems begrenzt.
• Die Anzahl der Sprecherzeilen sind beliebig und können im Verlauf des
Transkribierens verändert werden.
• Die situative Beschreibung des Diskurses geschieht in einer separaten Zeile, die ‘globaler Kommentar‘ genannt wird.
• Die in den Kommentarzeilen befindliche Annotierungen müssen synchron
zu den Äußerungen in den betreffenden Sprecherzeilen sein (Referenzpunkte).
• Die Referenzpunkte lassen sich synchron verschieben.
• Beim Einfügen oder Löschen von Transkriptteilen ist die Aufrechterhaltung der Synchronität der Referenzpunkte gewährleistet.
• Innerhalb einer Partitur ist horizontales und vertikales Navigieren und freies Positionieren möglich.
• Verschiedene Zeichensätze wie IPA, Kyrillisch und diverse Sonderzeichen
sind verfügbar.
Neben diesen Merkmalen erlaubt der Partitureditor das Speichern und Laden von Transkripten,
was für eine effiziente Arbeit mit Transkripten notwendig ist. Darüber hinaus sind weitere Metadaten wie etwa Bearbeitungsstand des Transkripts, Datum und Status von Korrekturen, Liste
der Gesprächsteilnehmer und eine Liste der verwendeten Sonderzeichen und deren Bedeutung
einfügbar.
Das System DIDA ist als Client-Server-Architektur realisiert und ist wie in Abbildung 3-1 ge-
Seite 57
zeigt aufgebaut. Folgende Komponenten charakterisieren das System: Der Partitureditor, der in
der Abbildung als graphische Benutzerschnittstelle ("Oberfläche") dargestellt ist, Datenbank
und Datenbankserver, welcher die Transkripte verwaltet, und die Druck- bzw. Exportkomponente ("Druck", "exp.nr1", "Hardcopy"). Die Pfeile symbolisieren den Datenfluss zwischen den
einzelnen Komponenten. Durch die Kommunikationsmodule wird die Client-Server-Architektur und mittels eines proprietären Mailboxformates der Transkriptdatenfluss realisiert.
Abb. 3-1: Die Architektur von DIDA
Die Architektur (nach [3.2]) ist im Wesentlichen zweigeteilt: Auf der Client-Seite ist der Partitureditor mit sämtlichen Funktionen realisiert und auf der Server-Seite die Verwaltung der Transkripte. Durch diese Struktur können
mehrere Clients gleichzeitig auf Transkripte zugreifen.
Als Voraussetzung dafür, dass mehrere Benutzer das System gleichzeitig benutzen können, sind
verschiedene Sicherheitsmerkmale implementiert worden. Dazu gehören Benutzerkennung und
Benutzerrechte, die Möglichkeit, Transkripte zu sperren und ein überwachter Import der Daten
in die Datenbank beim Speichern.
Benutzerkennung und Benutzerrechte werden analog zu Login-Fenstern eines Computersystems verwaltet. Ist ein Benutzer berechtigt, mit dem System zu arbeiten, wird der Editor geladen und ist benutzbar. Wird ein bereits vorhandenes Transkript geladen, so wird es für andere
Seite 58
Benutzer gesperrt. Auf diese Weise ist es unmöglich, dass zwei Benutzer an demselben Transkript arbeiten und dabei Inkonsistenzen produzieren. Beim Speichern wird das im Editor befindliche Transkript in eine sogenannte Mailbox geschrieben, die dann zur Aufnahme in den
Diskurs an den Datenbankserver übertragen wird. Dabei werden verschiedene Recover-Strategien verfolgt, um die alten Daten entsprechend reproduzieren zu können. Weitere Details zur
Bedienung des Systems können in ([3.2] und [3.3]) nachgelesen werden.
Abb. 3-2: Die Oberfläche des DIDA-Partitureditors
Der Partitureditor zeigt einen Ausschnitt aus einem Transkript mit vier Sprechern (AA, BB, CC, DD); jedem Sprecher ist eine eigene Partiturzeile zuzüglich Kommentarzeile (K) reserviert.
Abbildung 3-2 zeigt einen Ausschnitt aus einem Transkript in Partiturschreibweise. Erkennbar
sind hier die Sprecherzuordnungen (AA und BB sind Kontrahentinnen, wobei BB in diesem
Ausschnitt nicht redet, CC ist ein Schlichter), drei Simultanpassagen (AA und CC reden gleichzeitig; Anfang und Ende der Simultanpassagen sind mit "|" markiert) und eine rudimentäre prosodische Notation (Darstellung von Grenzintonation mit den Symbolen "↑" für steigende und "↓"
für fallende Intonation, "→" für Veränderung der Sprechgeschwindigkeit und "*" für Pausen).
Die Notation erfolgt in literarischer Umschrift24.
Das System DIDA ist ein mächtiges Werkzeug, das eine weitreichende Annotierung von Gesprächsdiskursen zulässt. Zu diesen Annotierungen zählen Diskursdaten wie Informationen zu
24 Literarische Umschrift stellt einen Kompromiss zwischen Standardorthographie und phonetischer
Umschrift dar. Auf diese Weise ist es möglich, dialektale Variationen oder Verschleifungen signalnah
zu beschreiben.
Seite 59
Sprachsignalen, Gespächsinhalt und –teilnehmern sowie Information über den Bearbeitungsstand eines Diskurses, Transkriptdaten wie Menge aller Äußerungsentitäten mit Anfangs- und
Endzäsur und Kommentare sowie weitere Verwaltungsdaten.
Das System verfügt dagegen nicht über Segmentierfunktionalität, weder manuell noch automatisch. Die erzeugten Annotationen sind reine Beschreibungen von Gesprächsdiskursen und somit primär nicht maschinell recherchierbar. Um die Transkripte, die mit DIDA annotiert werden,
trotzdem recherchierbar zu machen, werden die Daten über den Exportfilter in ein Recherchesystem überführt und mit den Zeitmarken eines automatischen Segmentiersystems angereichert
(siehe auch Kapitel 5).
3.2.
Automatische Segmentiersysteme
Die Vielfalt der existierenden Verfahren zur automatischen Segmentierung resultiert aus der
Notwendigkeit, akustische Daten und phonetische Beschreibungen elementarer sprachlicher Ereignisse für die Anwendung in der Sprachtechnologie in Übereinstimmung zu bringen. Solche
Segmentierungsverfahren sind dem Bereich der digitalen Sprachanalyse zuzuordnen.
Eine Klassifikation der Segmentierungssysteme kann nach dem Verfahrensprinzip und der
Wahl der zu segmentierenden Einheiten vorgenommen werden ([3.4]). Der wohl überwiegende
Teil der Systeme ist auf die Zerlegung in lautbezogene Einheiten konzentriert. Im Allgemeinen
kommen als solche Einheiten Phoneme, Diphone, Silben oder auch Wörter in Frage. Die Segmentierungsalgorithmen werden nach expliziten und impliziten ([3.4], [3.5]) sowie nach sequentiellen und optimalen Verfahren ([3.6]) unterschieden.
Implizite Verfahren benützen keine externen Wissensquellen, wie z.B. Informationen über die
geäußerten Wörter im Sprachsignal, sondern versuchen, Phonetikern gleich, Segmentgrenzen
im Sprachsignal zu finden. Diese Verfahren legen die Annahme zu Grunde, dass sich die spektralen Charakteristiken innerhalb eines Segments weniger stark ändern als an den Grenzen zwischen den Segmenten. Dagegen benützen explizite Ansätze externe Wissensquellen. Eine weit
verbreitete Vorgehensweise bei diesen Verfahren ist die Segmentierung durch Erkennung. Aus
diesem Grunde sind solche Verfahren auch oft mit den Methoden der automatischen Spracherkennung realisiert. Explizite Verfahren sind im Vergleich mit manuell erstellten Referenzdaten
besser als implizite Verfahren.
Sequentielle Verfahren verwenden lokale Änderungen, die jeweils einen relativ kleinen Teil des
Seite 60
zu segmentierenden Sprachsignals bewerten, während optimierende Verfahren große Abschnitte eines Sprachsignals auswerten. Bei den optimierenden Segmentierungsverfahren werden die
Segmentgrenzen nicht mittels Änderungen von Merkmalen in transienten Signalabschnitten gesucht; als Segmentierungskriterium wird vielmehr die Varianz bzw. die Ähnlichkeit von Merkmalen innerhalb möglicher Segmente herangezogen.
In [3.7] werden 32 solcher automatischer Segmentierverfahren ausführlich verglichen und evaluiert, insbesondere im Vergleich mit manueller Segmentierung. Der überwiegende Teil der dort
beschriebenen Systeme (44%) sind HMM- oder HMM/ANN25-basiert und 25% berechnen die
Segmentgrenzen mit DTW26. Der verbleibende Rest der Systeme implementiert verschiedene
Verfahren und Merkmale wie etwa das Abschätzen spektraler Veränderung oder Stimmhaftigkeit, Diphondetektion, multiple Frequenzbandfilter oder beruhen wie das Bonner Segmentiersystem [3.8] auf Vergleichen zwischen Referenzsignalen, die durch Sprachsynthese erzeugt
worden sind, und einem unbekannten Signal.
Im Folgenden werden zwei Segmentiersysteme für Deutsch ausführlich diskutiert und im Kontext von [3.7] bewertet. Beide Segmentiersysteme, das Stuttgarter System Alphones wie auch
das Münchner System MAUS, können zu den expliziten, global optimierenden Verfahren gezählt werden. Für diese Art der Segmentierung werden die benötigten Einheiten durch zuvor explizit trainierte Modelle repräsentiert. Die Optimierung der Segmentierung erfolgt im
Allgemeinen durch die Anwendung eines Mustervergleichsalgorithmus, wobei verschieden
wahrscheinliche Modellfolgen für ein bestimmtes Sprachsignal berechnet werden. Die Modellfolge mit der höchsten Wahrscheinlichkeit liefert die wahrscheinlich optimalen Segmentgrenzen für das Sprachsignal zusammen mit der symbolischen Beschreibung der individuellen
Segmente.
3.2.1.
Das Stuttgarter automatische Segmentiersystem Alphones
Das automatische Segmentierwerkzeug Alphones27 entstand im Rahmen einer Dissertation
([3.5]) am Lehrstuhl für Experimentelle Phonetik des Instituts für Maschinelle Sprachverarbeitung der Universität Stuttgart. Das System erzeugt Segmentierungen auf Phonem-, Silben- und
25 ANN="Artificial Neuronal Network" = künstliches neuronales Netzwerk.
26 DTW="Dynamic Time Warping", Methode um Signale im Zeitbereich zu vergleichen.
27 Alphones ist die Abkürzung für Align Phones.
Seite 61
Wortebene, und durch die Integration eines POS-Taggers ([3.10]) ist es auch möglich, eine syntaktische, kategoriale Wortklassifizierungsebene zu erzeugen.
Das System besteht aus einer Trainingsphase und einer Segmentierungsphase. Die Trainingsphase ist Teil der Entwicklung des Systems und ist mit der Fertigstellung des Systems abgeschlossen. In der Trainingsphase wird für jedes Symbol des Sprachinventars (z.B. Phonem einer
Sprache) ein Modell angelegt und anhand der vorkommenden Muster trainiert. Das Ergebnis
dieser Trainingsphase ist eine Modellmenge, in der die vorkommenden Modelle die spezifischen
Eigenheiten (z.B. spektrale Eigenschaften) der jeweiligen Symbole der Sprache repräsentieren.
Das System ist ursprünglich auf HTK ([5.9]) in der Version 1.5 entwickelt und auf die Version
2.1 portiert worden. Im Training wurden für die Phonemmodelle ergodische Modelle mit drei
emittierenden Zuständen angesetzt. Die Initialisierung wurde auf dem Teilkorpus "Berlin- und
Marburgsätze" des Kiel Corpus of Read Speech Vol.1 ([3.11]) durchgeführt. Das Trainingsmaterial enthält ingesamt 6144 Wörter männlicher und weiblicher Sprecher.
Die Segmentierungsphase ist der normale Betrieb des Systems und durch eine Dreiteilung gekennzeichnet: Die Textvorverarbeitung, die Sprachsignalvorverarbeitung und die Segmentierung. In Abbildung 3-3 ist die Architektur dargestellt.
Die Textvorverarbeitung besteht aus zwei Stufen. Die erste Stufe ist die Umsetzung von graphemischer in phonemische Repräsentation (Graphem-Phonem-Konversion). Die Graphem-Phonem-Konversion ist wiederum unterteilt in drei Strufen. Die erste Stufe besteht aus zwei
Lexikonzugriffen: Zuerst wird in einem Ausnahmelexikon nachgeschaut und Treffer durch deren phonetische Umschrift ersetzt. Als zweite Stufe wird der deutsche Teil des CELEX Lexikons
([3.12]), das aus 359611 Wortformen besteht, benützt, um die verbliebenen orthographischen
Symbole des Eingabestroms zu ersetzen. Weitere im Eingabestrom verbleibende, nicht ersetzte
Grapheme werden in der dritten Stufe regelbasiert umgesetzt. Die regelbasierte Konversion ist
eine Implementierung der Ausspracheregeln des Duden.
Die zweite Stufe der Textvorverarbeitung überführt die phonetische Repräsentation in eine systeminterne Repräsentation ("Grammatik"). Diese systeminterne Repräsentation ist eine Verkettung phonetischer Symbole, die durch ihre trainierten Modellen ersetzt wurden.
Seite 62
Die Buttergeschichte. Es war
in Berlin zu einer Zeit, als
Lebensmittel nicht gen"ugend
vorhanden waren. [...]
Binary Search
CELEX
Rule Based Conv.
Vector Coding
["di:] ["bU[t]@R][g@][SIx][t@]
["Es] ["va:R] ["In] [bER]["li:n]
["tsu:] ["aI][n@R] ["tsaIt] ["als]
["le:][b@ns][mI[t]@l] ["nIxt]
[g@]["ny:][g@nt] ["fo:R][han][d@n]
["va:][R@n] ...
Net Construction
(pause%\<P\>
pc_d%d lv_i:%i: [WordBoundary%\<P\>]
pc_b%b kv_U%U pc_t%t sv_@%@ lc_R%R pc_g%g
sv_@%@ fc_S%S kv_I%I fc_x%x pc_t%t sv_@%@
[WordBoundary%\<P\>]
kv_E%E fc_s%s [WordBoundary%\<P\>]
fc_v%v lv_a:%a: lc_R%R
kv_I%I nc_n%n [WordBoundary%\<P\>]
pc_b%b kv_E%E lc_R%R lc_l%l lv_i:%i:
nc_n%n [WordBoundary%\<P\>]
pc_t%t fc_s%s lv_u:%u: ...
Viterbi Decoder
#
0.380000
0.430000
0.500000
0.580000
0.630000
0.690000
0.740000
0.770000
0.830000
0.870000
121
121
121
121
121
121
121
121
121
121

d
i:
b
U
t
@
R
g
@
Abb. 3-3: Architektur des Stuttgarter Segmentierungswerkzeugs Alphones
Alphones besteht aus drei Teilen: Auf der linken Seite der Graphik ist die Textvorverarbeitung dargestellt und in
der Mitte oben die Signalvorverarbeitung, die für die dritte Stufe, das Segmentieren, zusammengeführt werden. Auf
der rechten Seite ist ein Ergebnis in der Form einer Wortsegmentierung aufgezeigt.
Das Sprachsignal unterliegt ebenfalls einer Vorverarbeitung; hier gelten die gleichen Prinzipien
wie bei der automatischen Spracherkennung: Die typische "waveform"-Darstellung des Sprachsignals (jedem Zeitpunkt auf der horizontalen Achse ist ein Abtastwert auf der vertikalen Achse
zugeordnet) liefert nicht genug Informationen, um akustische Ereignisse distinktiv beschreiben
zu können. Aus diesem Grunde wird das Sprachsignal in eine andere Repräsentationsform konvertiert (vgl. Spektrogramm), in der jedem Zeitpunkt beliebig viele Merkmale zugeordnet werden können (um beim Beispiel des Spektrogramms zu bleiben: Die Anzahl von Frequenzwerten,
die jedem Zeitpunkt zugewiesen werden können, hängen im Grunde nur von der Auflösung der
Darstellung ab). Die Bündelung der Merkmale pro Zeitpunkt ergibt dann einen Vektor pro Zeiteinheit. In dem hier beschriebenen System werden Vektoren mit 13 Dimensionen28 berechnet:
davon entsprechen 12 Dimensionen realen Merkmalen (im Falle eines Spektrogramms wären
Seite 63
dies 12 Frequenzwerte), hier sind es Mel-Frequenz-skalierte Cepstralkoeffizienten und eine Dimension für die Energie in der betrachteten Zeiteinheit. Dazu kommen dann noch die erste und
zweite Ableitung jeder Dimension. Damit entstehen insgesamt 39-dimensionale Vektoren. Diese Vektoren werden im Abstand von 10ms in einem Zeitintervall von 25.6ms berechnet. Auf diese Weise ergibt sich ein Überschneiden der Auswertungsintervalle, was eine bessere Erfassung
und Modellierung des Sprachsignals zulässt.
Das letztendliche Segmentieren erfolgt dann zwischen der Grammatik und dem parametrisierten
Sprachsignal, in Abbildung 3-3 durch die Box "Viterbi Decoder" dargestellt.
Das System Alphones kann Phonem- und Wortsegmentierungen vornehmen. Der Unterschied
zwischen Phonem- und Wortsegmentierung liegt in der erzeugten Grammatik. Während bei der
Phonemsegmentierung die Grammatik nach jedem Phonem ein Etikett ausgibt, wird bei der
Wortsegmentierung nur nach dem letzten erkannten Phonem eines Wortes ein Wortetikett ausgegeben. Die Silbensegmentierung wird nicht durch den eigentlichen Segmentierungsvorgang,
sondern durch eine Ableitung aus der Phonemsegmentierung erzeugt.
3.2.2.
Das Münchner Automatische Segmentationssystem
Das MAUS-System ([3.13] und [3.14]) basiert auf Spracherkennungstechnologie und verwendet
ähnlich dem System Alphones Hidden Markov Modelle zur Segmentierung. Es liefert eine breite
phonematische Transkription einer Äußerung inklusive der dazugehörigen Segmentgrenzen.
3.2.2.1. Architektur des Systems
Das System erzeugt aus der Eingabe von Sprachsignal und zugehörigem orthographischen Text
unter Einsatz von Hidden Markov Modellen (HMM) und Viterbi-Alignment die zeitliche Zuordnung der aus dem orthographischen Text gewonnenen Transkription zum Sprachsignal. Das System besteht aus den folgenden Hauptkomponenten: Parametrisierung des Sprachsignals,
Graphem-Phonem-Konversion durch Lexikonsuche, Viterbi-Decoder und einem HMM-Set, das
das trainierte Lautinventar des Deutschen repräsentiert (hier 42 Modelle). Die HMMs weisen
eine unterschiedliche Topologie auf und können zwischen drei und sechs Zustände haben. Das
Training der Modelle erfolgte an handsegmentiertem Material, das ungefähr 2400 Äußerungen
28 Unter den Dimensionen eines Vektors wird in diesem Zusammenhang die Anzahl der Koeffizienten
verstanden, die aus dem Sprachsignal pro Zeiteinheit berechnet werden.
Seite 64
umfasst ([3.13]). In Abbildung 3-4 ist das Gesamtsystem schematisch dargestellt.
Abb. 3-4: Architektur des Münchner Segmentiersystems MAUS
Die Signalvorverarbeitung erzeugt Vektoren als die erste von drei Eingaben für das Viterbi-Alignment (die Segmentierung): die Textvorverarbeitung, bestehend aus Lexikonsuche und Generierung von Varianten aus der kanonischen Form, stellt die zweite Eingabe dar. Die dritte Eingabe sind die trainierten Modelle. Ein "Refinement" führt
eine Nachkorrektur der Segmentgrenzen durch.
Der Unterschied zwischen Alphones und MAUS liegt im sogenannten Variantengenerator und in
einem Modul zur Nachkorrektur des Segmentierungsergebnisses.
Der Variantengenerator von MAUS verfügt über ein Regelwerk, mit dem die Einträge der kanonischen phonetischen Repräsentation modifiziert werden können. Das Ergebnis dieser eingeschobenen Textvorverarbeitungsstufe ist eine um verschiedene Aussprachevarianten
angereicherte Phonemfolge. Um die Generierung der Aussprachevarianten zu erleichtern, wird
jedes Symbol intern als gerichteter Graph dargestellt. Die Erweiterung durch die Anwendung
der Regeln für die Aussprachvarianten erfolgt nun einfach durch Hinzufügen weiterer Übergän-
Seite 65
ge zum Graphen. In Abbildung 3-5 wird dieses Vorgehen schematisch dargestellt.
(a)
*
h
a:
b
@
n
*
(b)
*
h
a:
b
@
n
*
m
Abb. 3-5: Erzeugung der Aussprachevarianten in MAUS
In (a) ist ein einfacher Graph der kanonischen Repräsentation und in (b) ein Graph mit Variantenerweiterung gezeigt. Die Zustände mit "*" symbolisieren die Wortgrenzen. Die Varianten erlauben eine Segmentierung, die das
Signal adäquater abbilden.
Der Graph (a) in Abbildung 3-5 ist ein einfacher linearer links-rechts Graph, bei dem jeder Knoten nur einen Vorgänger hat. In Teil (b) ist die Anreicherung der Aussprachevarianten durch die
hinzugefügten weiteren Übergänge abgebildet. Durch die Erweiterung ist es möglich, neben
[ha:b@n] auch die Varianten [ha:m], [ha:bm] und [ha:bn] zu produzieren. Die Variantenbildung
ist eine signalnähere Segmentierung, da die Varianten gegenüber der kanonischen Form häufiger in gesprochener Sprache vorkommen. Allerdings bewirkt die Variantenbildung immer einen
höheren Rechenaufwand, der bei schlechten Verarbeitungsprozeduren explodieren kann, ohne
dabei immer den gewünschten Effekt zu erzielen ([5.6]).
Das "Refinement" von MAUS erzeugt ein nachträgliches Verbessern der durch den Viterbi-Decoder ermittelten Segmentgrenzen. Dabei werden z.B. die Segmentgrenzen auf den nächstliegenden Nulldurchgang des Signals verschoben oder Korrekturen der Anfangsgrenzen initialer
Plosive vorgenommen.
Das Segmentiersystem MAUS erlaubt automatisches Transkribieren und Segmentieren von
sprachlichen Äußerungen, wobei keine expliziten Wortsegmentierungen produziert werden; Informationen über Wortgrenzen sind nur implizit durch die Kodierung von Wortanfang und -ende
("*") enthalten.
Seite 66
3.3.
Evaluierung der automatischen Segmentierungssysteme
Die Evaluierung automatisch erstellter Segmentationen bedarf einer genauen Interpretation. Insbesondere muss auf die Auswahl einer entsprechenden Referenzsegmentierung großen Wert gelegt werden, da auch phonetische Experten durchaus unterschiedliche Segmentationen des
selben Signals produzieren können, ohne dass dabei einfach entschieden werden könnte, welche
davon nun die korrekte Segmentation ist (siehe [3.7], [3.13], [3.15]). In den eben genannten Arbeiten wird eine gemittelte Referenzsegmentierung mehrerer Labeller ("inter-labeller distance")
benützt, um die Segmentiergenauigkeit der automatischen Segmentierverfahren zu bewerten.
Im Allgemeinen wird nach zwei unterschiedlichen Methoden evaluiert:
• Übereinstimmung der erzeugten Labelsegmente (das ist nur bei Systemen
wie MAUS von Bedeutung, da in diesen Systemen durch die Variantengenerierung zwischen Eingabesysmbolen und erzeugten Phonemsymbolen
Unterschiede entstehen können)
• Übereinstimmung der segmentalen Grenzen
Durch die unterschiedliche Generierung der zur Segmentierung benötigten Modellfolge der beiden vorgestellten Segmentiersysteme erfolgt nur eine Bewertung für die Übereinstimmung der
Segmentgrenzen. In Abbildung 3-6 sind die Ergebnisse von unterschiedlichen Evaluierungen
zusammengetragen. Da es üblich ist, Evaluierungen über ein bestimmtes Zeitintervall zu machen, ist es möglich die verschiedenen Systeme gegenüberzustellen. Die Ergebnisse aus Spalte
eins, Spalte zwei und Spalte vier sind aus [3.9] übernommen, die Spalten drei und fünf sind aus
[3.13]. Die Bewertung der Segmentierleistung erfolgt über die Genauigkeit der Segmentgrenzen
in Prozent, die über fünf Zeitintervalle ([0..10]ms, [10..15]ms, [15..20]ms, [20..32]ms,
[32..64]ms) ermittelt worden sind. Die Evaluierung der Systeme ist für unterschiedliche Sprachen gemacht, wobei DK für Dänisch, GB für Englisch, I für Italienisch und D für Deutsch steht.
Die Ergebnisse zeigen im interlingualen Bereich auf den ersten Blick erstaunliche Unterschiede,
die bei Handsegmentierung von Phonetikern so nicht beobachtet wurden ([3.7]). Tatsächlich
sind allerdings nur die Ergebnisse von Dalsgaad, Andersen, Barry ([3.7]) unterschiedlich, was
u.U. auf die Architektur (Neuronale Netzwerke) zurückgeführt werden kann.
Seite 67
Zeit
Dalsgaad, Andersen,
Barry (1991)
Kvale (1993)
MAUS
(1995)
Alphones
(1995)
Phonetiker
DK
GB
I
DK
GB
I
D
D
[3.13]
10 ms
48.7%
62.6%
34.2%
70.3%
66.2%
64.2%
61%
59.1%
87%
15 ms
58.9%
72.5%
45.8%
81.0%
76.4%
77.7%
76%
75.9%
93%
20 ms
65.5%
77.5%
52.0%
86.1%
82.3%
84.5%
84%
84.4%
96%
32 ms
-
-
-
-
-
-
90%
91.1%
99%
64 ms
-
-
-
-
-
-
95%
96.0%
100%
Abb. 3-6: Evaluierung der Segmentiersysteme
Darstellung der Segmentierungsergebnisse von MAUS und Alphones im Vergleich mit Systemen für andere Sprachen und Handsegmentierung von Phonetikern. Die Ergebnisse sind über Intervallzeiträume erzielt worden. Die
Zeiträume geben an, welche Abstände zwischen zwei Segmentgrenzen als vernachlässigbar gelten.
Der Vergleich zwischen den beiden vorgestellten automatischen Segmentiersystemen MAUS
und Alphones ergibt keine nennenswerten Unterschiede. Über die ganze Versuchsreihe hinweg
unterschieden sich die Ergebnisse nur im Nachkommabereich (mit Ausnahme des Intervalls
[0..10ms]). Das Gleiche gilt für den Vergleich mit den Systemen von Dalsgaad, Andersen, Barry
(1991) und Kvale (1993). Nicht weniger überraschend ist der signifkant hohe Abstand der Segmentiergenauigkeit zu Ergebnissen, die von Menschen produziert worden sind, und zwar über
alle Intervalle hinweg. Obwohl die in [3.13] berichteten Ergebnisse von geschulten Phonetikern
erzielt worden sind (letzte Spalte der Tabelle in Abbildung 3-6), sind vergleichbare Ergebnisse
nicht wesentlich niedriger. In [3.7] wird z.B. von durchschnittlichen Segmentiergenauigkeiten
von 93.8% bei 20ms über verschiedene Sprachen und Sprachsignalqualitäten hinweg berichtet.
Bemerkenswert ist allerdings, dass sich die zwei Systeme MAUS und Alphones nicht unterscheiden, denn daraus lässt sich folgern, dass die Generierung von Aussprachevarianten für die automatische Segmentierung keine signifikante Verbesserung der Ergebnisse bewirkt.
Das automatische Segmentiersystem Alphones kommt im Weiteren in Kapitel 5 und Kapitel 6
zum Einsatz.
Seite 68
KAPITEL 4
Grundlagen der Datenbanktechnik
Ein Datenbanksystem ist im Grunde eine Ansammlung von beliebigen Daten, die einer gewissen
Ordnung unterliegen - im Allgemeinen einem Index - und auf der, als minimale Anforderung,
eine Suchfunktion definiert werden kann. Die Unterschiede zwischen den vielen existierenden
Datenbanksystemen29 sind Design und Funktionalität sowie deren Kosten. So gibt es objektorientierte und relationale Datenbanksysteme für Standard- und Nischenanwendungen als kommerzielle Lösungen und als freie "Open-Source-Software"-Lösungen. Die Auswahl eines
passenden Datenbanksystems ist also abhängig von der intendierten Anwendung sowie von den
finanziellen Rahmenbedingungen.
4.1.
Datenbankdesign
Unabhängig von der Implementierungsstruktur einer Zieldatenbank ist die erste Aufgabe, die
abzubildende Realität in einem logischen Datenmodell darzustellen30. Dazu gehören Überlegungen zu den zu speichernden Daten sowie über deren Organisation und Struktur. Das logische
Datenmodell besteht aus den drei Komponenten Entitäten, Attribute und Beziehungen31. Daraus
wird ein physikalisches Datenmodell, das bei relationalen Datenbanksystemen aus Tabellen be-
29 Ein Datenbanksystem beinhaltet die Datenbank, in der die Daten physikalisch organisiert sind, und ein
Datenbank-Management-System (DBMS), das es ermöglicht, die Daten komfortabel zu benutzen; das
DBMS ist also mit anderen Worten eine Schnittstelle zwischen Daten und Benutzern.
30 Es gibt verschiedene Techniken der Datenmodellierung. In der Literatur wird oft empfohlen, vor dem
Entwurf des logischen Datenmodells ein konzeptionelles Datenmodell zu erstellen. Dazu verwendete
Techniken sind z.B. das Entity-Relationship-Modell. (ausführliche Diskussion in [4.2], Kap. 4 und
Kap. 5). Wegen der geringen Komplexität des hier benötigten Datenmodells wird auf eine konzeptionelle Entwicklung verzichtet.
31 Weitere Datenmodelle sind Netzwerk- und hierarchisches Modell (siehe [4.2], Kap. 6).
Seite 69
steht, erzeugt. Der Vorgang von der logischen Datenmodellierung bis hin zur Tabellenstruktur
wird als Datenbank-Design bezeichnet.
Der wichtigste Aspekt des Datenbank-Designs ist, neben einer sauberen logischen Modellierung
der Daten, mögliche Redundanzen aus der Datenbank fernzuhalten. Für das Isolieren und Eliminieren von Redundanzen werden die Methoden der Normalisierung eingesetzt. Idealerweise erfolgt das Datenbank-Design in den folgenden Schritten (nach [4.1]):
1. Bestimmung und Modellierung der Entitäten
2. Bestimmung und Modellierung der Beziehungen zwischen den Entitäten
3. Bestimmung und Modellierung der Attribute
4. Bestimmung eindeutiger Schlüsselattribute für jede Entität
5. Normalisierung
Die Phasen dieses Entwurfsprozesses im Kontext von Datenbank-Lebenszyklen wird in ([4.2],
Seite 45 ff.) ausführlich dargestellt.
4.2.
Datenbank-Entitäten
Unter einer Datenbank-Entität versteht man ein Objekt, über das Daten gesammelt werden sollen. Die Daten, die eine Entität beschreiben, werden durch Attribute oder durch Verbindungen
zwischen den Entitäten modelliert. In einem Datenmodell werden Entitäten durch Kästchen mit
einer Überschrift dargestellt, wobei die Überschrift die Entität benennt. Während jede Entität
keine oder mehrere Attribute besitzen kann, beschreibt jedes Attribut genau eine Entität. Jede
Instanz einer Entität besitzt einen Wert für jedes ihrer Attribute. Ein solcher Attributwert kann
durch einen beliebigen Datentypen repräsentiert werden. In der Abbildung 4-1 ist ein Datenmodell dargestellt, das nur aus einer Entität und ihren Attributen besteht.
Seite 70
Entität
Attribut1
Attribut2
...
Attribut n
Abb. 4-1: Darstellung einer Entität im logischen Datenmodell
Eine Entität besteht aus dem Entitätsnamen und den Attributen. Die Attribute sind einwertig und können von beliebigem Datentyp sein.
4.3.
Beziehungen und Schlüsselattribute
Für die Abbildung von Daten einer zu beschreibenden Entität gibt es neben dem Definieren von
Attributen auch die Möglichkeit, Verbindungen zwischen Entitäten zu formulieren. Solche Verbindungen werden benützt, um einen feineren Detailliertheitsgrad von Entitäten zu erreichen. Es
ist prinzipiell möglich, sämtliche Daten, die modelliert werden sollen, auf eine einzige Entität
abzubilden. Das hat allerdings den Nachteil einer sehr komplexen Struktur sowie von mehrwertiger Attribute. Solche mehrwertigen Attribute führen bei der Umsetzung des Schemas auf die
Tabellenstruktur zu hohen Redundanzen und somit letztlich zu einer Datenbank mit sehr
schlechter Performanz. Dieser wichtige Aspekt des Datenbank-Designs, die Redundanzfreiheit,
wird durch die verschiedenen Stufen der Normalisierung (siehe Abschnitt “Normalisierung” auf
Seite 73) erreicht. Der Kern einer jeden Normalisierung, unabhängig von der Stufe, ist das Aufteilen einer Entität in mehrere Entitäten, deren semantische Bedeutung durch Beziehungen wieder hergestellt werden. Um aber mehrere Entitäten verbinden zu können, muss jede Entität über
ein eindeutiges Schlüsselattribut verfügen. Der Wert dieses Attributes muss für die gesamte Gültigkeitsdauer und über alle Instanzen einer Entität hinweg von Null verschieden und eindeutig
sein. Durch die Einführung eines Schlüsselattributes erweitert sich die Darstellung einer Entität,
wie in Abbildung 4-2 dargestellt. Ein Schlüsselattribut einer Entität wird immer mit einem Unterstrich dargestellt. Auf diese Schlüsselattribute können nun Beziehungen definiert werden.
Seite 71
Entität_1
Entität_2
Entität_1-ID
Entität_2-ID
Attribut1
Attribut2
...
...
Attribut n
Attribut n+1
Abb. 4-2: Entitäten mit Schlüsselattribut
Entitäten verfügen über ein ausgezeichnetes Attribut, das einen eindeutigen Namen über alle Attribute hinweg hat.
Dieses ausgezeichnete Attribut, Schlüsselattribut oder Primärschlüssel genannt, wird im Datenmodell unterstrichen
dargestellt.
Es gibt binäre Beziehungen, die zwei Entitäten verknüpfen, und es gibt rekursive, die eine Entität mit sich selbst verknüpft. Da Beziehungen neben den Entitätsattributen die zweiten Träger
von Informationen über Entitäten sind, gibt es auch mehrere Möglichkeiten, Informationen zu
modellieren. Die einfachste binäre Beziehung ist eine 1-1-Verbindung, mit der etwa MutterTochter-Beziehungen modelliert werden können. Dagegen sind 1-M-Beziehungen oder M-MBeziehungen sehr viel mächtiger. Ein Beispiel für eine 1-M-Beziehung wäre beispielsweise eine
Mutter-Töchter-Beziehung. Da jede M-M-Beziehung durch zwei 1-M-Beziehungen ausgedrückt werden kann, sind 1-M-Beziehungen im Sinne eines einfachen und klaren Datenmodells
zu bevorzugen. Eine binäre Verbindung wird im Datenmodell durch einen Strich dargestellt und
die Art der Beziehung, "Wurzeln", am Ende: Abbildung 4-3 verdeutlicht die Notation.
Entität_1
Entität_2
Entität_1-ID
Entität_2-ID
Attribut1
Attribut2
...
...
Attribut n
Attribut n+1
Abb. 4-3: Darstellung einer 1-M-Relation zwischen 2 Entitäten
Auf Schlüsselattribute können Beziehungen definiert werden. Die Beziehungen sind binär und müssen den entsprechenden Primärschlüssel in der verbundenen Entität als sogenannten Fremdschlüssel identifizieren können.
Bei der einfachen Darstellung der Entitäten in Abbildung 4-2 und 4-3 ist immer nur ein Anker
Seite 72
einer Beziehung (das Schlüsselattribut) dargestellt. Der zweite Anker kann natürlich nicht das
Schlüsselattribut der zu verbindenden Entität32 sein, daher muss das Schlüsselattribut als
Fremdschlüssel in die zu verbindende Entität eingesetzt werden. Dabei ist zu beachten, dass jene
Entität den Fremdschlüssel zugewiesen bekommt, die bei der 1-M-Beziehung auf der "1-Seite"
(d.h. "Nicht-Wurzel-Seite") steht.
4.4.
Normalisierung
Das Ziel einer Normalisierung ist die Eliminierung von Redundanzen in einem Datenmodell.
Solche Redundanzen treten sehr häufig in den Attributwerten von Entitäten auf, z.B. wenn mehrere Attributwerte zu einem Attribut gehören. In einem solchen Fall ist es angebracht, die Entität
in zwei oder mehrere Entitäten aufzuteilen, solange bis jedes Attribut nur noch ein Attributwert
hat. Der zu Anfang bestehende Zusammenhang zwischen den Attributwerten wird durch Beziehungen wieder hergestellt.
Eine Normalisierung wird über Entitäten und Attribute durchgeführt und kann mehrere Stufen
(1. Normalform, 2. Normalform etc.) beinhalten; von den existierenden Normalformen33 sollen
die drei häufigsten hier dargestellt werden:
• Die 1. Normalform bezieht sich auf die Einwertigkeit von Entitätsattributen. Wie bereits oben angedeutet, ist die wichtigste Forderung an das Datenmodell, dass alle Attribute einwertig sind. Ist diese Bedingung erfüllt, so
befindet sich das Datenmodell in der 1. Normalform. Ist diese Forderung
nicht erfüllt, so muss aus dem entsprechenden Attribut eine neue Entität mit
eigenen Attributen formuliert werden.
• Die 2. Normalform bezieht sich auf Schlüsselattribute. Wenn die Entitäten
bereits in der 1. Normalform vorliegen und alle Attribute, die nicht Schlüsselattribut sind, nur von dem eindeutigen Schlüsselattribut der Entität abhängen, so ist die 2. Normalform erfüllt. Ist die 2. Normalform nicht
erreicht, z.B. dadurch dass ein Attribut zu zwei oder mehreren Entitäten in
32 Entitäten können immer nur über gleichlautende Attributsnamen verknüpft werden, und Schlüsselattribute sind per Definition eindeutig.
33 In den theoretischen Grundlagen zu Relationenmodellen geht man von insgesamt 5 NF aus.
Seite 73
Beziehung steht, so muss durch Formulierung einer neuen Entität die 2.
Normalform wieder hergestellt werden.
• Die 3. Normalform bezieht sich auf die Attributsabhängigkeit innerhalb einer Entität. Eine Entität liegt in der dritten Normalform vor, wenn es bereits
in der 2. Normalform ist und kein Nicht-Schlüsselattribut von einem anderen Nicht-Schlüsselattribut abhängig ist. Ist dies nicht der Fall, so wird die
3. Normalform hergestellt, indem die voneinander abhängigen Attribute in
eine neue Entität überführt werden.
Bei jeder dieser 3 Normalformen werden durch das Erzeugen von neuen Entitäten auch neue Beziehungen erzeugt, die die semantische Bedeutung der Entität aufrechterhalten. Ist ein Datenmodell in der 3. Normalform, so kann man von einer weitestgehend redundanzfreien Umsetzung in
ein Relationenschema (physikalisches Datenmodell) ausgehen.
4.5.
Physikalisches Datenmodell - Tabellenstruktur
Nachdem in dem vorangegangen Abschnitt der erste Schritt des Datenbank-Designs gezeigt
worden ist, wird in diesem Abschnitt der Übergang zur physikalischen Realisierung dargestellt:
Aus dem logischen Datenmodell werden Tabellen34 und Beziehungen generiert. Nach [4.1] besteht das Umwandeln des logischen in ein physikalisches Datenmodell aus den folgenden Regeln:
• aus Entitäten werden Tabellen
• aus Attributen werden Spalten der Tabellen
• Schlüsselattribute werden zu Spalten, die nicht leer sein dürfen; sie werden
als Primärschlüssel der physikalischen Datenbank bezeichnet
• die Beziehungen werden durch Fremdschlüssel formuliert, indem die entsprechenden Attribute als neue Spalten eingesetzt werden
In Abbildung 4-4 ist das Resultat dieser Regeln in Form einer Tabellendefinition dargestellt. Die
34 Das hier dargestellte Datenbank-Design bezieht sich auf relationale Datenbanksysteme.
Seite 74
tatsächliche Darstellung der Umwandlung durch SQL-Anweisungen würde an dieser Stelle zu
weit führen. Die Tabelle in Abbildung 4-4 ist das umgewandelte logische Datenmodell aus Abbildung 4-3. Die einzige Beziehung, die im logischen Datenmodell vorhanden ist, ist eine 1-MBeziehung. Die Umsetzung dieser Verbindung erfolgt, indem der Primärschlüssel der "1-Seite"
der Beziehung in die Tabelle der "M-Seite" als Fremdschlüssel eingetragen wird (siehe Abbildung 4-4). Wäre eine 1-1-Beziehung enthalten, müsste ebenfalls ein Primärschlüssel als Fremdschlüssel eingetragen werden: allerdings müsste dann nicht auf die Reihenfolge geachtet
werden.
Tabelle
Spalte
Datentyp
Bemerkung
Entität 1
Entität_1-ID
INT
Primärschlüssel
Attribute 1
TEXT
Entität_2-ID
INT
Attribut 2
TXT
Entität_1-ID
INT
Entität 2
Primärschlüssel
Fremdschlüssel
Abb. 4-4: Physikalisches Datenmodell (Relationenschema)
Das logische Datenmodell aus 4-3 ist in die Tabellenform eines relational-basierten pyhsikalischen Datenmodells
überführt worden. Dabei sind die Beziehungen durch das Definieren von Primär- und Fremdschlüsseln abgebildet
worden.
Durch die in Abbildung 4-4 dargestellte Methode werden aus dem logischen Datenmodell, das
bei realen Datenbanksystemen mehrere tausend Entitäten beinhalten kann, die Tabellenstrukturen erzeugt, auf die im Transaktionsmodus Anfragen gestellt werden können.
Dieses Kapitel 4 stellt eine Einführung in die Datenbankentwurfstechnik dar und bildet somit
die Grundlage für das in Kapitel 6 vorgestellte System ("Das Sprachdatenbanksystem IMSPhoBase, S. 102"). Im sechsten Kapitel wird der Entwurfsprozess, der in diesem Kapitel sehr allgemein dargestellt wurde, anhand der benötigten Entitäten bis hin zum Relationenschema
aufgezeigt.
Seite 75
KAPITEL 5
Annotationssystem am IDS
Im folgenden Kapitel werden die Arbeiten und Experimente vorgestellt, die im Rahmen des Kooperationsprojekts ”Segmentierung gesprochener Sprache - Alignmentprojekt” zwischen dem
Institut für Deutsche Sprache (IDS) und dem Institut für Maschinelle Sprachverarbeitung (IMS),
Lehrstuhl für Experimentelle Phonetik, gemacht worden sind.
Das am IDS vorhandene Annotations-Recherchesystem COSMAS II35 hat die Möglichkeit, die
Auswertung der Treffer von Suchanfragen durch Abspielen der Treffer zu ergänzen. Eine wesentliche Voraussetzung zum Abspielen der Treffer ist die Markierung der zu Grunde liegenden
Annotationen mit Zeitmarken. Eine schlechte bzw. falsche Markierung ist allerdings kontraproduktiv, da Stellen im Sprachsignal vorgespielt werden, die nicht oder nur schlecht zu den gefundenen Textpassagen passen. Die Zuordnung vom Sprachsignal zum Text entspricht einer
Segmentierungsaufgabe. Durch die enorme Menge an Daten36 ist nur eine automatische Segmentierung möglich.
Das Ziel der Experimente ist es, systematisch schlechte Segmentierungen zu identifizieren und
durch neue Modellierungsmethoden zu verbessern. Die Segmentierungsexperimente werden auf
Wortebene durchgeführt.
Am IDS ist eine komplette Annotierungsinfrastruktur vorhanden. In dieser Infrastruktur ist der
gesamte Lebenszyklus eines Sprachsignals enthalten: von der Aufnahme bzw. Digitalisierung
auf einem Computersystem über geeignete Werkzeuge zur manuellen Annotierung bis hin zu ei-
35 [http://www.ids-mannheim.de/COSMAS]
36 siehe Seite 81 und Fußnote 41.
Seite 76
nem Recherchesystem, in dessen Datenbank die annotierten Sprachdaten organisiert und verwaltet werden. Die Infrastruktur ist in Abbildung 5-1 dargestellt.
(Analoge) Aufnahme
Digitalisierung
Transkription
Sprachsignal
(DIDA−) Transkript
Dokumentation
Verwaltungsdaten
Extraktion
Wortfolge
Ton−Text−Alignment
Konvertierung
Hinzufuegen
Labeldateien (=Wortfolgen mit Zeitmarken)
(SGML−) Transkript mit Zeitmarken und
Verwaltungsdaten
Einmischen
Datenbankrecherche mit COSMAS II
Abb. 5-1: Die Annotationsinfrastruktur von Sprachdaten am IDS
Die abgebildetet Infrastruktur (aus [5.1]) zeigt den Weg einer Sprachaufnahme von der Aufnahme (analog und digital) bis zur vollständigen Segmentierung und Annotation in einer Datenbank. Die Sprachaufnahmen werden transkribiert, in ein SGML-basiertes Annotationsformat überführt und durch ein automatisches Segmentiersystem mit
Zeitmarken angereichert. Kasten mit eckigen Kanten bedeuten Arbeitsschritte, Kasten mit runden Kanten stellen
Ergebnisse dar.
Die Sprachaufnahmen werden auf drei verschiedene Arten behandelt. Ist das Sprachsignal eine
analoge Aufnahme, etwa auf einem Kassettenrecorder, so muss diese Aufnahme zuerst digitalisiert werden; neuere Aufnahmen liegen in der Regel schon digital vor. Das Sprachsignal wird in
einem zweiten Schritt transkribiert. Das Ergebnis der Transkription kann eine sehr detaillierte
Annotation sein, oder auch nur eine einfache Verschriftlichung des aufgenommenen Sprachsignals. Die Transkription wird mit einem Partitureditor (DIDA), der in Abschnitt 5.1 beschrieben
wird, erstellt. Weitere diskursbezogene Annotationen (Verwaltungsdaten) werden in einem dritten Schritt annotiert. Solche Verwaltungsdaten sind etwa Aufnahmedaten, Datenträger, Sprecher und die korrespondierenden Siglen, Besonderheiten, Kommunikationsverlauf usw. Aus
den Verwaltungsdaten und den Transkripten werden komplexe SGML-basierte Annotationen
Seite 77
erstellt und mit Zeitmarken angereichert, die von dem automatischen Segmentiersystem berechnet wurden. Die Experimente zur automatischen Segmentierung werden in Abschnitt 5.3. ausführlich diskutiert. Die SGML-basierten Annotationen werden in COSMAS II überführt, um
darauf Recherchen zu ermöglichen. COSMAS II wird in Abschnitt 5.2 diskutiert.
5.1.
Das Annotationsmodell und der Partitureditor DIDA
Gesprächs- bzw. Sprachaufnahmen sind die primären Daten für die empirische Gesprächsforschung am IDS. Untersuchungen solcher Gespräche lassen sich aber nur durchführen und intersubjektiv nachprüfbar machen, wenn Daten nach einem standardisierten Transkriptionssystem
konsistent verschriftet werden. Am IDS wurden für diesen Zweck der Partitureditor DIDA37 (für
eine genaue Beschreibung der Architektur, siehe "Manuelle Annotationsverfahren - Das System
DIDA, S. 56") und dazugehörige Annotationsrichtlinien ([5.2]) entwickelt.
Das zu Grunde liegende Annotationsmodell ist ein Partiturmodell (ähnlich dem BAS-Annotationsmodell, S. 19), in dem für jeden am Diskurs beteiligten Sprecher eine eigene Sprecherzeile
angelegt ist, die in Sprecherzeilenblöcke ("turns") gegliedert sind. Auf dieser Sprecherzeile wird
die jeweilige Äußerung verschriftet. Den Sprecherzeilen sind weitere Zeilen, sogenannte Kommentarzeilen, zugeordnet, auf denen ergänzende Annotierungen wie etwa nicht-sprachliche Aktivitäten lokaler als auch globaler Art in Bezug auf das Sprachsignal festgehalten werden
können. Die Partiturschreibweise basiert auf der sogenannten ”literarischen Umschrift”, die einen Kompromiss zwischen orthographischer Verschriftung und phonetischer Umschrift bildet.
Einfache prosodische Merkmale, wie Grenzintonationsmuster, Pausen und Sprechweise können
ebenso annotiert werden wie Simultanpassagen mehrerer Sprecher. Für weitergehende Informationen zur Partiturschreibweise, siehe [5.2]. In Abbildung 5-2 ist der Auszug aus einer Partiturannotation gezeigt.
37 [http://www.ids-mannheim.de/prag/dida]
Seite 78
[...]
AA:
|ich hab die beiden mit
BB: das ist ihre|(arbeit↓)
CC:
|sie haben haben das (...)
AA: ja↓|
BB:
| ja– * ja da sind jetz haare drauf un das is
CC:
|
BB: die der aufbau dieser geschichte– * daß es also
BB: einige millimeter äh=dick sein soll ist– * äh– *
BB: nicht– * richtig ↑* es ist– && es=is=so:–
XM:
(...)
K&
PAPIERGERASCHEL
BB: * daß äh das der aufbau für dieses haarteil ist↑
K
RASCHELT MIT PAPIER, PACKT AUS
BB: * das ka=man insofern noch das besteht also aus
K
>>
[...]
BB: wa"s frau klocke meint is eintlich etwas a:ndres↓
K
ERKLÄRENDER TONFALL >>
BB: * ¨sie meint es is– * relativ dick und voll als
[...]
Abb. 5-2: Annotation im IDS Partiturformat
Die Partiturdarstellung zeigt einen Ausschnitt aus dem Transkript "3005.21, haarteil", das in rtf-Format konvertiert
wurde (in einer älteren Form). Es zeigt drei Sprechern AA, BB, CC die in Sprecherzeilenblöcken annotiert sind.
Die Stellen, an denen mehrere Sprecher gleichzeitig sprechen, sind mit "|", prosodische Merkmale wie steigende
und fallende Intonation sind mit "↑" bzw. "↓", Pausen durch "*" notiert. Auf den Kommentarzeilen "K" werden lokale Aktivitäten annotiert.
Der Ausschnitt aus einem Transkript zeigt ein Gespräch, an dem drei Sprecher (AA, BB, CC)
beteiligt sind, die teilweise gleichzeitig reden (Simultanpassagen werden in senkrechte Striche
eingeschlossen). Prosodische Markierungen wie Grenzintonation38 ("↑ " bzw. "↓") und Pausen
("*") sind annotiert, ebenso nicht-sprachliche Ereignisse (Kommentarzeile). An diesem Ausschnitt ist die Form der literarischen Umschrift wie etwa bei "a:ndres" und "ka=man" zu sehen. Dabei entsteht "ka=man" durch Elision des "schwa"-Lautes und Nasalverschleifung von
"kann" und "man". Die Vokaldehnung ":" bei "a:ndres" ist nicht Bestandteil der literarischen Umschrift, sondern Teil der prosodischen Annotation.
Die durch DIDA erzeugten Annotationen werden in ein SGML-basiertes Annotationsformat
38 Abschlussintonation an Segmentgrenzen, die als Stellen möglicher Redeübergaben interpretiert werden können.
Seite 79
umgewandelt, das beim Import in COSMAS II indiziert wird. In Abbildung 5-3 ist ein Ausschnitt
der Partiturdatei aus Abbildung 5-2 in die von COSMAS II benötigte SGML-basierte Darstellung
konvertiert. Die Umwandlung erfolgt durch ein spezielles Werkzeug, dem sogenannten Diskursstruktur Manager.
[...]
<w lemma='ja' n=4078-19-4773>ja</w> <pause dur='0,5'><w lemma='ja' n=4079-19-4774>ja</w> <w lemma='da' n=4080-19-4775>da</w> <w lemma='sind' n=4081-19-4776>sind</w> <w lemma='jetz' n=4082-19-4777>jetz</w>
<w lemma='haare' n=4083-19-4778>haare</w> <w lemma='drauf' n=4084-194779>drauf</w> <w lemma='un' n=4085-19-4780>un</w> <w lemma='das' n=408619-4781>das</w> <w lemma='is' n=4087-19-4782>is</w> <w lemma='die' n=408819-4783>die</w> <w lemma='der' n=4089-19-4784>der</w> <w lemma='aufbau'
n=4090-19-4785>aufbau</w> <w lemma='dieser' n=4091-19-4786>dieser</w> <w
lemma='geschichte' n=4092-19-4787>geschichte</w> <pause dur='0,5'><w lemma='daß' n=4093-19-4788>daß</w> <w lemma='es' n=4094-19-4789>es</w> <w lemma='also' n=4095-19-4790>also</w> <w lemma='einige' n=4096-19-4791>einige</
w> <w lemma='millimeter' n=4097-19-4792>millimeter</w> <w lemma='äh=dick'
n=4098-19-4793>äh=dick</w> <w lemma='sein' n=4099-19-4794>sein</w> <w lemma='soll' n=4100-19-4795>soll</w> <w lemma='ist' n=4101-19-4796>ist</w>
<pause dur='0,5'><w lemma='äh' n=4102-19-4797>äh</w> <pause dur='0,5'><w
lemma='nicht' n=4103-19-4798>nicht</w> <pause dur='0,5'><w lemma='richtig'
n=4104-19-4799>richtig</w> <pause dur='0,5'><w lemma='es' n=4105-194800>es</w> <w lemma='ist' n=4106-19-4801>ist</w> <w lemma='&&' n=4107-194802>&&</w> 
[...]
Abb. 5-3: SGML- basiertes Annotationsformat von COSMAS II
Der Ausschnitt zeigt die SGML-basierte Annotation für einen Sprecherzeilenblock, der von und begrenzt
wird. Alle Annotationen zu diesem Sprecherzeilenblock erfolgen innerhalb dieser Struktur, wie z.B. die Sprecheridentifikation, die über das Element who erfolgt.
In dem SGML-basierten Annotationsmodell werden die Äußerungen in Sprecherblöcke strukturiert ( und ), in denen wiederum die Worte durch die Tags <w> und </w> aufgelistet werden. Jedes Wort wird durch sein Lemma (lemma), seiner tatsächlich vorkommende Form, einen
eindeutigen Bezeichner (n) und Referenzen für mögliche Simultanpassagen annotiert. Die Pausen werden mit einem eigenen Element (pause) mit dem Attribut dur annotiert.
5.2.
Das Recherchesystem COSMAS II
COSMAS II39 ist eine Text- und Korpusdatenbank, die speziell für große Datenmengen (im Augenblick sind über 700 Millionen geschriebener Wörter enthalten) konzipiert ist ([5.3]). Die Ar-
39 COSMAS ist ein Akronym für "COrpus Storage Maintainance and Accessment System"
Seite 80
chitektur ist Client-Server-basiert und modular; das System besteht aus einem zentralen
Datenverwaltungskern und verschiedenen Modulen, wie etwa einer graphischen Suchanfragekomponente, Worteinheiten- und Satzsegmentierungskomponente uvm. Das dem Abfragemodul zu Grunde liegende Datenmodell besteht aus einer Referenzschicht und einer theoretisch
unbegrenzten Anzahl von Annotationsschichten, deren Annotierungen auf Einheiten in der Referenzschicht verweisen. Die Ebenen werden beim Import40 in die Datenbank aus der SGMLbasierten Annotationstruktur extrahiert.
Neben den annotierten text-basierten Transkripten sind ca. 330 Diskurstranskripte in das Datenbanksystem eingebunden, deren korrespondierende Sprachaufnahmen ungefähr 150 Stunden
aufgenommener Sprache (ca. 1,5 Millionen Wortformen) entsprechen; von diesen 150 Stunden
liegen ca. 21 Stunden segmentiert vor ([5.4]).
Die Verbesserung der existierenden Segmentierungen sowie weitere Erzeugung von segmentierten Sprachsignalen ist das Ziel der im Folgenden diskutierten Experimente.
5.3.
Experimente zur automatischen Segmentierung von Sprachsignalen
Die Sprachdaten, die am IDS vorliegen, sind sehr umfangreich41. Von diesen Sprachdaten soll
ein kleiner Teil, nämlich die 150 Stunden digitalisierte und transkribierte Diskurse (davon entfallen ca. 50 Stunden auf dialektale Aufnahmen aus dem Projekt "Stadtsprache Mannheim"), die
bereits in COSMAS II als reine Texttranskripte integriert sind, prototypisch segmentiert werden.
Es handelt sich dabei im Wesentlichen um die dialog-orientierten Sprachaufnahmen aus den folgenden Domänen ([5.1]):
• Beratungsgespräche unterschiedlicher Art
• Schlichtungsgespräche (z.B. vor einer Vergleichsbehörde)
• Aufnahmen aus dem Projekt "Stadtsprache Mannheim"
• Fernsehaufnahmen (z.B. Talkshows und Diskussionen)
• Ethnographische Interviews mit Fernsehredakteuren und -moderatoren
• Interviews mit Beamten europäischer Institutionen in Brüssel
40 Der Import besteht aus drei Phasen: Parsen und Validieren der SGML-Syntax, interpretieren der Strukturen, z.B. Verweise und Indizierung der grundlegenden Einheiten für einen schnellen Zugriff.
41 Im [http://www.ids-mannheim.de/dsav/] werden zur Zeit 33 gesprochensprachliche Korpora verwaltet.
Seite 81
Die besonderen Schwierigkeiten dieser Daten liegt zum Einen an der Vielzahl unterschiedlicher
Sprecher, die zum Teil simultan sprechen (bei Talkshows); zum Anderen handelt es sich um
technisch schlechte Aufnahmen (Feldaufnahmen) und um starke dialektale Variation.
Zur Vorbereitung der Experimente sind durch aufwendige, manuelle und zeitintensive Ausarbeitung von Vorstudien zu diesem Projekt drei Klassen von Fehlern identifiziert worden:
• Klasse 1: nicht-sprachliche Signalabschnitte
• Klasse 2: Hesitations- und Rezeptionssignale
• Klasse 3: Simultanpassagen
Die Fehler der ersten Klasse werden durch zwei Phänomene verursacht: signalinhärente und domänentypische Besonderheiten. Bei signalinhärenten Besonderheiten handelt sich z.B. um Rauschen, hervorgerufen durch schlechte Aufnahmequalität. Im zweiten Fall verursachen
Signalpassagen wie z.B. Lachen, Klatschen oder Musik (Talkshows) die Fehler. Da solche Passagen oft sehr lang sind, erzeugen sie auch globale Fehler, also Fehler, die sich über viele Segmente hinweg erstrecken. Dagegen sind Fehler, die der zweiten Klasse zuzuordnen sind, in der
Regel auf einen kleinen, lokalen Bereich begrenzt, dafür aber unter linguistischen Gesichtspunkten äußert interessant (für weiterführende Informationen auch [5.5]). Die dritte Fehlerklasse
zeichnet sich durch Fehler aus, die durch Simultanpassagen ausgelöst werden. Diese Fehler
kommen in Gesprächen, zumal in kontrovers geführten Gesprächen mit mehreren Teilnehmern,
sehr häufig vor. Die Fehler dieser Fehlerklasse werden aber in dieser Arbeit nicht weiter thematisiert.
Die Experimente werden mit dem automatischen Segmentierwerkzeug Alphones (siehe Abschnitt “Das Stuttgarter automatische Segmentiersystem Alphones” auf Seite 61) durchgeführt.
5.3.1.
Ausgangspunkt aller Experimente (Baseline)
Zur Vorbereitung der Experimente ist ein Evaluierungskorpus semi-manuell42 erstellt worden.
Das Evaluierungskorpus besteht aus ungefähr 2,5 Stunden aufgenommener Sprache, jeweils zur
Hälfte aus Aufnahmen einer Talkshow und Aufnahmen aus dem Projekt "Mannheimer Stadt-
Seite 82
sprache". Der Domänenmix spiegelt einen Querschnitt aus den oben erwähnten Problemen wider, so dass diese Probleme ausreichend gut modelliert und evaluiert werden können. Die erste
Evaluierung der Ergebnisse von Alphones ohne Verbesserungen erfolgt auf dem Evaluierungskorpus und stellt damit die Grundlage für weitere Entwicklungen dar ([5.7]). Das Ergebnis ist in
Genauigkeit / %
Abbildung 5-4 dargestellt.
100
90
80
70
60
Gesamtkorpus
Refernzkorpus
50
0
500 1000 1500 2000 2500 3000
Zeitintervall / ms
Abb. 5-4: Ergebnis der Evaluierung von Alphones in der Basisvariante
Das Ergebnis der Evaluierung von Alphones ohne adäquate Modellierung der Fehlerproblematik (Kurve mit Kreissymbole) erbringt immerhin eine Segmentiergenauigkeit von knapp 92% in einem Intervall von 3000ms. Der Vergleich zu einer Evaluierung von Alphones auf einem sauberen Referenzkorpus (Kurve ohne Symbole) zeigt deutlich
die Defizite auf.
In Abbildung 5-4 ist das Ergebnis über den gesamten Evaluierungskorpus in Prozent pro Zeitintervall angegeben. Die Experimente verlaufen immer über ein Zeitintervall von [0..3000] ms.
Die Kurve mit den Kreissymbolen stellt die Segmentiergenauigkeit ohne Berücksichtigung einer adäquaten Behandlung der oben erwähnten Fehlerproblematik dar.
Wie dem Ergebnis zu entnehmen ist, liegt Alphones erst ab einem Zeitintervall von ca. 500ms
über 90% Segmentiergenauigkeit, d.h., dass Wörter, die um bis zu 500ms von der Referenzsegmentierung abweichen, noch als richtiges Ergebnis gezählt werden. Legt man zum Beispiel eine
42 Das Evaluierungskorpus ist automatisch segmentiert worden und anschließend von Hand korrigiert
worden.
Seite 83
durchschnittliche Länge von Partizip Perfekt Verben (VVPPs) von ca. 880ms zu Grunde ([5.6]),
so kann eine Abweichung von mehr als der Hälfte (450ms) des zu segmentierenden Wortes bereits ein "Danebenliegen" des Ergebnisses bewirken. Die Quote wird bei abnehmendem Intervall rapide schlechter. Zum Vergleich ist eine Referenzsegmentierung auf sauberen
Labordaten43 durch die Kurve ohne Symbole dargestellt. Wie der Kurve zu entnehmen ist, sind
diese Ergebnisse ohne Einschränkungen gut, im Intervall [0..100] ms wird eine Genauigkeit von
98% erreicht und im Intervall [100..3000] ms von 99%. Das bedeutet, dass das schlechtere Ergebnis tatsächlich eine unmittelbare Folge der vorliegenden Daten ist.
5.3.2.
Allgemeiner Lösungsansatz für Segmentierprobleme
Segmentierfehler, die auf nicht-sprachliche Signalanteile zurückzuführen sind und Segmentierfehler, die durch Hesitations- bzw. Rezeptionssignale verursacht werden, werden letztlich die
gleiche Fehlerquelle verursacht. Die Fehlerquelle liegt in der Behandlung der Signale durch das
Segmentiersystem. Um die Ursache dieser Fehlerquelle deutlich zu machen, sollen an dieser
Stelle die notwendigen Details des Segmentierprozess wiederholt werden (siehe Abschnitt “Das
Stuttgarter automatische Segmentiersystem Alphones” auf Seite 61):
• Für jedes Phonem des Lautinventars existiert ein HMM (bereits trainiert).
• Jedes Graphem der Eingaberepräsentation wird durch einen Graphem-Phonemkonverter in eine phonetische Zwischenrepräsentation überführt.
• Die Phoneme der Zwischenrepräsentation werden durch die korrespondierenden HMMs ersetzt.
• Der Segmentierprozess vollzieht sich zwischen der Kette der HMMs und
dem Sprachsignal.
Der Eingabetext wird also in eine Kette von Einzelphonemen überführt, um damit anschließend
die Segmentierung durchzuführen. Damit können aber nur solche Signalabschnitte segmentiert
werden, die ein akustisches Korrelat im Sprachsignal haben. Es entstehen Fehler, wenn Elemente in der Kette sind, denen kein akustisches Korrelat im Sprachsignal zuzuordnen sind und vice
43 Aufnahme von gelesen Texten durch Standardsprecher des Deutschen in einem schalltoten Raum.
Seite 84
versa. Das ist aber der Fall bei Vertretern der 1. Fehlerklasse: Lange Signalabschnitte, die z.B.
Klatschen oder Musik beinhalten, haben in der einfachen Texteingabe keine Entsprechung. Damit entstehen in der HMM-Kette sozusagen "Lücken"44, die Alphones durch gleichmäßiges
Verteilen des angrenzenden Materials zu schließen versucht. Auf diese Weise können globale
Fehler entstehen, die je nach Länge des problematischen Signalsegments bis zu mehreren Minuten betragen können. Die Lösung dieses Problems liegt auf der Hand: das Annotationsmodell,
aus dem die einfache Textrepräsentation extrahiert worden ist (zur Erinnerung: die Experimente
dienen dazu, die bestehenden Annotierungen von COSMAS II mit Zeitmarken anzureichern),
verfügt über die an dieser Stelle notwendigen Annotationen. Wird also versucht, die orthographische Eingabe des Segmentiersystems mit den notwendigen Informationen anzureichern, so
dass keine "Lücken" in der Kette der HMMs entstehen, so wird man erneut mit Problemen konfrontiert, die exakt den Problemen, die man mit den Hesitations- und Rezeptionssignalen bekommt, gleichen. Die Graphem-Phonem-Konvertierung ist der Grund für die Fehler: Jedes
Element des Eingabestroms wird durch das korrespondierende Phonem ersetzt. Der Vorgang ist
in (1) exemplarisch dargestellt.
(1)
aus
aus
aus
aus
aus
MUSIK
KLATSCHEN
RAUSCHEN
ähm
mhm
wird [mu:]["zi:k]
wird ["kla[tS]@n]
wird ["RaU][S@n]
wird [Em]
wird [mm]
Die Segmente, wie in (1), die eigentlich als eine Einheit behandelt werden sollten, werden in
eine Einzelphonemrepräsentation überführt. Eine solche Abbildung bewirkt natürlich keine adäquate Beschreibung, da in einem 60 Sekunden langen KLATSCHEN-Signal normalerweise die
Phonemfolge [k l a tS @ n] nicht vorkommt. Das gleiche gilt auch für ähm und mhm. Das als
Hesitation geäußerte ähm hat eine völlig andere spektrale und temporale Struktur als die isoliert
geäußerten Phoneme [E] und [m]. Ein mhm, das als zweigipfliges Rezeptionssignal realisiert
wird, hat mit zwei isolierten [m] nichts gemeinsam.
44 Solche Lücken entstehen natürlich auch, wenn die Verschriftlichung des Sprachsignals, die ja unbedingte Voraussetzung für eine maschinelle Segmentierung ist, bereits lückenhaft ist. Diese Art der Probleme sind aber an anderer Stelle zu diskutieren.
Seite 85
Die Lösung zu diesen Problemen liegt darin, für alle die beschriebenen Phänomene neue Modelle zu erstellen. Solche Modelle werden an vielen Instanzen der jeweiligen Muster trainiert
und als sogenannte Ganzwortmodelle in das System eingebunden. Bei der Graphem-PhonemKonversion werden dann diese neuen Modelle analog zu den Einzelphonemmodellen, allerdings
als eine Einheit, umgesetzt. Durch diese erweiterte Prozedur werden die Beispiele aus (1) wie in
(2) umgesetzt.
(2)
aus
aus
aus
aus
aus
MUSIK
KLATSCHEN
RAUSCHEN
ähm
mhm
wird [MUSIK]
wird [KLATSCHEN]
wird [RAUSCHEN]
wird [EM]
wird [MHM]
Für die Modellierung der hier benannten Probleme sind die in (3) aufgezählten Ganzwortmodelle erstellt worden.
(3)
ATMEN, HUSTEN, KLATSCHEN, LACHEN, RAUSCHEN,
STOERUNG, MUSIK, EH, EHM, JA, JAJA, M, MH, MHM
Zu Erstellung und Training der neuen Ganzwortmodelle ist ein Trainingskorpus mit ungefähr 17
Stunden Dauer ebenfalls semi-manuell erstellt worden. In diesem Trainingskorpus sind alle Vorkommen der jeweiligen Ganzwortmodell-Sequenzen von Hand nachsegmentiert worden.
Im Allgemeinen wird in einer Trainingsphase für jeden Laut (Phonem) des Sprachinventars ein
mathematisches Modell (HMM) angelegt und anhand vieler Realisationen des Phonems aus
dem Trainingskorpus trainiert. Das Trainingsprozedere ist unabhängig von der Art des zu Grunde liegenden Modells (Einzelphonem- oder Ganzwortmodell) und wird hier für Ganzwortmodelle gezeigt.
Ein "Hidden Markov Model" (HMM) besteht aus Zuständen und Übergängen. Für die Modellierung von gesprochener Sprache werden ergodische Modelle ([5.8]) angenommen, die von
links nach rechts durchlaufen werden. Es gibt Übergänge, die auf sich selbst zeigen und solche,
die zu einem anderen Knoten zeigen. Jeder Übergang ist gewichtet (Transitionswahrscheinlichkeit) und gibt Auskunft über die Verweildauer in einem Knoten. Die Knoten selbst sind eben-
Seite 86
falls gewichtet (Emissionswahrscheinlichkeit).
Abb. 5-5: Die Topologie eines Hidden Markov Modells (HMM)
Ein HMM besteht aus Knoten und Kanten, beide sind mit Wahrscheinlichkeitswerten gewichtet. Die Transitionswahrscheinlichkeiten der Übergänge determinieren in gewisser Weise die Länge und Dauer des Modells, während
die Emissionswahrscheinlichkeiten der Knoten eine Gewichtung für die "Produktion" eines Symbols angibt. Die
Abbildung auf das Sprachsignal ist durch die Observationsfolge dargestellt.
Abbildung 5-5 zeigt ein prototypisches Modell (nach [5.9], [5.10]), das aus fünf Zuständen besteht. Zustand eins und Zustand fünf haben als Einstiegs- und Ausstiegspunkte besonderen Status und tragen keine Merkmale; sie dienen der Verknüpfung mit den Vorgänger- und
Nachfolgermodelle. Die Zustände dazwischen tragen die Merkmalsinformationen in Form der
Gewichte b2( ) bis b5( ).
Ein diskretes HMM ist formal durch das Tripel in (4) definiert.
(4)
M := { e, A, p(xi | sj) }
Ein Modell M ist definiert durch den Startzustand e, die Matrix A aller Transitionswahrscheinlichkeiten und die Emissionswahrscheinlichkeit p, die für jeden Zustand sj die Wahrscheinlichkeit für ein Symbol xi angibt.
Die Wahrscheinlichkeitswerte stellen die Modellparameter dar, die bei einem Trainingslauf aus
den Daten berechnet werden. Wie in Abbildung 5-5 gezeigt, wird jedem Zustand des Modells
ein Symbol des entsprechenden Musters (Observationsfolge) zugewiesen: Zustand 2 bekommt
in diesem Beispiel die zwei Symbole o1 und o2 zugewiesen, Zustand 3 dagegen nur das Symbol
o3. An den spezifischen Merkmalen der Symbole werden die Parameter der Zustände berechnet.
Seite 87
Am Ende des Trainings existieren für jedes Symbol eines sprachabhängigen Lautinventars ein
solchermaßen trainiertes Modell.
In den im Folgenden beschriebenen Experimenten werden die Modelparameter der jeweiligen
Ganzwortmodelle trainiert und optimiert. Die Optimierung erfolgt durch Variation von Anzahl
der Zustände und Übergänge des Modells.
5.3.3.
Experiment 1: Behandlung nicht-sprachlicher Signalanteile
In diesen Experimenten sollen Ganzwortmodelle erstellt, trainiert und optimiert werden, um Signalsequenzen abzudecken, die typisch sind für Sprachaufnahmen von Diskussionsrunden und
Talkshows. Darüber hinaus sollen auch Ganzwortmodelle für Signalsequenzen erstellt werden,
die unabhängig von der Domäne vorkommen, wie etwa Rauschen, Husten, Räuspern und sonstige Störgeräusche.
Beide Signaltypen, nicht-sprachliche Ereignisse, bewirken globale Fehler, d.h dass die Synchronisationszeit (das ist die Zeit, bis die Segmentierung wieder mit dem Sprachsignalabschnitt
übereinstimmt) sehr lang ist. Bei Aufzeichnungen von Talkshows aus dem Fernseher ist es üblich, dass ein Musikstück zur Einleitung, gefolgt von langen Sequenzen mit Klatschen, und ein
Musikstück zum Ausklingen das eigentliche Sprachsignal umschließt. Das Gespräch wird dabei
als eine Folge von Einzelgesprächen organisiert (wobei jeweils ein einzelner Talkgst oder ein
thematischer Aspekt des Sendungsthema im Fokus stehen), und diese Einzelgespräche werden
durch Musikauftritte unterbrochen. Solche Signalabschnitte bewirken ein "Entgleisen" der Segmentierung, da an diesen Stellen, wie eingangs beschrieben, Lücken entstehen. In Abbildung 56 und 5-7 werden Signalausschnitte gezeigt, die die Problematik verdeutlichen sollen.
In Abbildung 5-6 ist ein Ausschnitt aus einer Talkshow dargestellt. Die ersten 43 Sekunden bestehen aus dem Anfangsmusikstück, dann folgt eine Sequenz mit Klatschen, die knapp 6 Sekunden dauert. Danach beginnt der Moderator seine Einleitung "einen wunderschönen guten Abend
[...]". Ohne ein Modell für Musik versucht das Segmentiersystem den Text von Beginn an auf
das Sprachsignal abzubilden. Wie in der oberen Segmentierspur zu sehen ist, sind die beiden
Wörter "einen wunderschönen" an anderer, falscher Stelle segmentiert worden, und auch
"abend" ist noch falsch, auf das Segment "guten", abgebildet. Da in dieser Darstellung die Segmentierung immer nur durch Markierung des Endes eines Segments erfolgt, bezieht sich die Bewertung nur auf Abweichungen zwischen den Enden von Segmenten. Die Referenzspur (untere
Seite 88
Spur) zeigt die richtige, von Hand erstellte, Segmentierung.
Abb. 5-6: Auschnitt aus einer Talkshow: Musik und Klatschen
Dargestellt ist das Ende des Musikintros einer Talkshow, der Übergang - Klatschen des Publikums - und der Beginn
der Einleitungsrede des Moderators. In der oberen Segmentspur ist die automatische Segmentierung und in der unteren Segmentspur die handsegmentierte Referenzspur angegeben.
Abb. 5-7: Ausschnitt einer Talkshow: Rauschen und Störung
Dargestellt ist ein Ausschnitt mit einer langen Sequenz von Rauschen, das von einer Störung gefolgt ist. In der oberen Segmentspur ist die automatische und in der unteren Spur die handgefertigte Segmentierung zu sehen.
Seite 89
In Abbildung 5-7 sind Fehler gezeigt, die durch signalinhärente Probleme entstehen. Im Signal
ist ein relativ langes Rauschen (ca. 2 Sekunden) zu sehen, das von einem deutlichen Störgeräusch (Nadelimpuls) gefolgt wird. In der Referenzspur sind die Etiketten RAUSCHEN und
STOERUNG für die jeweiligen Signalabschnitte vergeben. Dagegen sieht man in der darüber
liegenden automatisch erzeugten Segmentierspur den Fehler beim Etikett "zwischen", dessen
Beginn richtig segmentiert worden ist, aber den ganzen Zeitraum des Rauschens mit überspannt.
Die Grenzsegmente "komma" (Vorgängersegmente) und "wo" (Nachfolgersegmente) sind richtig; es entsteht also ein Fehler, der auf einen lokalen Bereich begrenzt beleibt.
Das Erstellen neuer Ganzwortmodelle, wie oben dargestellt, sowie deren Training und Optimierung bewirkt beim gleichzeitigen Einsatz mit den restlichen Modellen, dass diese Fehler verschwinden bzw. so minimiert werden, dass die verbleibenden Segmentgrenzfehler auditiv nicht
mehr wahrnehmbar sind.
In Abbildung 5-8 ist das Beispiel aus Abbildung 5-6, aber mit Einsatz der neuen Ganzwortmodelle, nochmals dargestellt. Die untere Spur ist nach wie vor die Referenzsegmentierung, die
mittlere Spur ist die vormalige, automatisch erzeugte und die obere Spur ist die neue, automatisch erzeugte Segmentierspur. In der oberen Spur sind die neuen Ganzwortmodelle für Musik
(MUSIK) und Klatschen (KLATSCHEN) eingesetzt. Im Falle von MUSIK wird eine minimale
Abweichung von 0.3 Sekunden erzeugt, wobei in dem Intervall von [43 .. 43,3] Sekunden noch
Musik ist, aber auch schon Klatschen einsetzt, und im Falle von KLATSCHEN eine exakte
Übereinstimmung erzeugt wird. Das bedeutet für das Modell KLATSCHEN in dem vorliegenden Fall eine perfekte Segmentierung. Durch die richtige Modellierung der Klatschensequenz
sind auch die nachfolgenden Nutzsegmente "einen wunderschönen" ohne Abweichung zur Referenzsegmentierung zugewiesen worden.
Das Beispiel in Abbildung 5-9 zeigt die Verbesserungen gegenüber Abbildung 5-7. Auch in dieser Abbildung haben die Segmentspuren die gleiche Reihenfolge. Der Erfolg der neuen Ganzwortmodelle zeigt sich in der oberen Segmentspur: Das Modell RAUSCHEN ist perfekt
abgebildet, das Modell STOERUNG produziert eine vernachlässigbare Abweichung von 0.02
Sekunden. Durch den Einsatz von RAUSCHEN kommt es zu einer Verschiebung des Nutzsegments "zwischen" von 0.08 Sekunden; diese Verschiebung gegenüber dem Referenzsignal hat
aber seine Berechtigung, da an dieser Stelle die Referenzsegmentierung ungenau ist, die automatisch erstellte Segmentierung mithin genauer.
Seite 90
Abb. 5-8: Ausschnitt aus einer Talkshow: Musik und Klatschen - Verbesserung
Die Abbildung entspricht dem Beispiel aus Abbildung 5-6, mit dem Unterschied, dass die oberste Spur eine automatische Segmentierung unter Einsatz von Ganzwortmodellen für Musik und Klatschen darstellt.
Abb. 5-9: Ausschnitt einer Talkshow: Rauschen und Störung - Verbesserung
Das dargestellte Beispiel entspricht dem aus Abbildung 5-7, aber mit Einsatz der Ganzwortmodelle für signalinhärente Phänomene wie Rauschen und Störung. Die obere Spur zeigt die automatische Segmentierung mit den neuen
Modellen.
Seite 91
Ein weiteres Phänomen ist an diesem Beispiel zu beobachten: das Modell RAUSCHEN produziert Einfügefehler. Das Problem der Einfügefehler, eigentlich aus der Spracherkennung bekannt und im Segmentierprozess nicht von Bedeutung, hat seinen Ursprung in der besonderen
Behandlung von Rauschen. Wie in Abschnitt 5.3.2. dargelegt, wird jedes Symbol in der Eingabekette eines Segmentiersystems für den Segmentierprozess benützt, es werden keine zusätzlichen Symbole produziert und somit können streng genommen keine Einfügefehler entstehen.
Mit diesem Ansatz können jedoch Signalsequenzen, die kein orthographisches Korrelat haben,
wie etwa Rauschen, nicht modelliert werden. Aus diesem Grund ist diese Klasse von Phänomenen, zu denen auch Husten, Räuspern, Atmen, Schmatzen, Brummen usw. zählen, nur adäquat
abbildbar, wenn diese "frei" eingesetzt werden können. Unter "freiem Einsetzen" ist in diesem
Zusammenhang die Möglichkeit zu verstehen, vor und nach jedem Wort das Modell RAUSCHEN optional zuzulassen. In Abbildung 5-10 ist der Sachverhalt verdeutlicht.
WD_BEGIN%anf“angt
kv_a
nc_n
fc_f
kv_E
nc_N
pc_t
WD_END%anf“angt
(a)
WD_BEGIN%anf“angt
kv_a
nc_n
fc_f
kv_E
nc_N
pc_t
WD_END%anf“angt
[WordBoundary%\<P\>|RAUSCHEN]
(b
Abb. 5-10: Grammatik für optionale Ganzwortmodelle
In der Abbildung sind Auschnitte aus zwei Grammatiken zu sehen. In (a) ist die "gewöhnliche" Grammtik gezeigt,
die nur ein Modell für Pause nach jedem Wort zulässt und in (b) die diskutierte Erweiterung für das "freie" Einsetzen des Ganzwortmodell RAUSCHEN. Die Modelle "" und "RAUSCHEN" sind durch die "oder"-Verknüpfung freie Varianten.
Durch diese "freie" Verwendung des Ganzwortmodells werden oft mehr RAUSCHEN Etikette
erzeugt, als tatsächlich vorhanden sind45, aber es ist die einzige Möglichkeit, solche Signalsequenzen zu modellieren. Durch viele Experimente ([5.7]) mit der Topologie des Modells für
45 Allerdings sind nicht alle eingefügten RAUSCHEN auch tatsächliche Einfügefehler, sondern oftmals
verbesserte Segmentierungen gegenüber einer Referenzsegmentierung.
Seite 92
RAUSCHEN ist die Einfügefehlerrate auf ein moderates Maß gesunken. Für die restlichen Vertreter dieser Phänomenklasse hat sich nach vielen Versuchen und Optimierungen ([5.7]) ergeben, dass es besser ist, nur ein Modell als Vertreter dieser Klasse anzunehmen. Die Gründe für
diese Entscheidung liegen zum Einen in einer zu geringen Anzahl von Trainingsmustern für ein
robustes Modell (Husten, Räuspern und Schmatzen) und zum Anderen in einer zu großen Einfügefehlerrate (Atmen). Als Konsequenz ist das Modell für Rauschen (RAUSCHEN) etwas unschärfer trainiert46 worden, was zur Folge hat, dass das RAUSCHEN mehr abdecken kann als
nur Rauschen. Die Folge davon sind aber Abweichungen und Ungenauigkeiten, die allerdings
in der Summe weniger ins Gewicht fallen, als bei einer separaten Verwendung aller Modelle.
Experimente mit allen Ganzwortmodellen, bei denen die Modellgröße (Anzahl der Zustände)
und Anzahl und Art der Übergänge (Kanten von Zustand zu Zustand) variiert wurden sowie eine
unterschiedliche Verwendung ("frei" vs. "textgesteuert"), ergaben am Ende bei folgender Konfiguration die besten Ergebnisse:
• HUSTEN wird durch RAUSCHEN abgedeckt
• ATMEN wird durch RAUSCHEN abgedeckt
• RAUSCHEN: 15 Zustände, frei
• MUSIK: 5 Zustände, textgesteuert
• KLATSCHEN, 7 Zustände, textgesteuert
• LACHEN, 7 Zustände, textgesteuert
• STOERUNG: 7 Zustände, textgesteuert
Die Ergebnisse dieser Konfiguration sind in Abbildung 5-11 und 5-12 gezeigt. Die Ergebnissesind als Diagramme dargestellt, auf deren horizontalen Achsen das Zeitintervall der Auswertung
und auf den vertikalen Achsen die Segmentiergenauigkeit abgetragen sind. Die Segmentiergenauigkeit bezieht auf die Übereinstimmung von Segmentgrenzen zwischen automatisch erzeugter und von Hand erzeugter Segmentierung pro Zeitpunkt im Intervall.
46 unschärfer trainieren bedeutet, dass ein Modell nicht nur auf seinen eigenen Instanzen trainiert wird,
sondern auch auf Instanzen anderer Signaltypen.
Seite 93
Segmentiergenauigkeit / %
100
90
80
70
60
50
0
mit Ganzwortmodelle
ohne Ganzwortmodelle
500 1000 1500 2000 2500 3000
Zeitintervall / ms
Abb. 5-11: Ergebnis auf dem gesamten Evaluierungskorpus
Ergebnis für die optimale Modellkonfiguration auf dem gesamten Evaluierungskorpus. Die Kurve mit den KreisSymbolen ist das Originalergebnis (siehe auch Abbildung 5-4) und die Kurve mit den Quadrat-Symbolen das Ergebnis für die Ganzwortmodelle.
100
90
80
70
60
50
40
0
mit Ganzwortmodelle
500 1000 1500 2000 2500 3000
Zeitintervall / ms
Ergebnis der optimalen Modellkonfiguration auf einem Teil des Evaluierungskorpus. Die Kurve mit den QuadratSymbolen stellt das Ergebnis der neuen Ganzwortmodelle und die Kurve mit den Kreis-Symbolen das Originalergebnis dar. In dem betrachteten Teilkorpus kommen mehr den Ganzworten entsprechende Signalsequenzen vor als
im zweiten Teil des Evaluierungskorpus.
Seite 94
Das Gesamtergebnis aus Abbildung 5-11 zeigt den erfolgreichen Einsatz der neuen Ganzwortmodelle für nicht-sprachliche Signalphänomene. Im unteren Bereich des Zeitintervalls werden
leichte Steigerungen der Segmentgenauigkeit erreicht, die sich ab ungefähr 200 Millisekunden
kontinuierlich steigern, bis hin zu 3 % am Ende des Intervalls. Auf Grund der Struktur des Evaluierungskorpus47 fällt die Steigerung der Segmentgenauigkeit nicht so starkt aus, wie eigentlich
erwartet wurde. Das Ergebnis auf dem Teilkorpus "Talkshow", siehe Abbildung 5-12, dagegen
weist eine große Steigerung der Segmentgenauigkeit auf. Die Kurve mit den Quadrat-Symbolen
steigt sehr viel steiler an als die Originalkurve, was eine wesentlich höhere Segmentgenauigkeit,
vorallem, schon im kleinen Intervallbereich, repräsentiert. Oberhalb von 200 Millisekunden
liegt bereits eine Steigerung um 10 % vor, die bis zum Ende des Zeitintervalls beibehalten wird.
Die maximale Steigerung der Genauigkeit liegt bei 13 %, das bedeutet eine Steigerung von 88%
Segmentiergenauigkeit auf über 98% bei 3000ms.
Auf Grund der Ergebnisse kann von einem erfolgreichen Modellieren der problematischen Signalabschnitte (Klasse 1) gesprochen werden.
5.3.4.
Experiment 2: Behandlung von Hesitations- und Rezeptionssignalen
In diesen Experimenten sollen Ganzwortmodelle erstellt, trainiert und optimiert werden, um Signalsequenzen abzudecken, die unter dem Begriff Hesitations- und Rezeptionsphänomene subsumiert werden. Diese Klasse von Signalsequenzen sind unabhängig von einer gewählten
Domäne und kommen in spontan geäußerter Sprache sehr häufig vor.
Diese Signaltypen bewirken, im Gegensatz zu nicht-sprachlichen Signaltypen, lokal begrenzte
Fehler. Allerdings sind diese lokalen Fehler zum Teil gravierender als globale Fehler nichtsprachlicher Signaltypen, denn in deren langen Abschnitten befinden sich keine Nutzsegmente,
die durch Verschieben der betroffenen Segmente ebenfalls verschoben werden; es werden nur
vereinzelte Nutzsegmente falsch segmentiert, die dann natürlich große Abweichungen aufweisen. Dagegen kommen Hesitationen und Rezeptionen naturgemäß zwischen anderen Nutzsegmenten vor, die von der falschen Segmentierung stark betroffen sind. Insofern handelt es sich
bei lokalen Fehlern um Fehler, die tatsächlich auf einen kleinen Bereich beschränkt sind, darin
47 Der Teilkorpus "Mannheimer Stadtsprache" hat sehr wenige nicht-sprachliche Signalsequenzen,
wogegen der Teil "Talkshow" über sehr viele solche Sequenzen verfügt.
Seite 95
aber viel Schaden anrichten. Die Abbildungen 5-13 und 5-14 verdeutlichen den Sachverhalt.
Abb. 5-13: Ausschnitt aus einer Talkshow: mhm
In dem dargestellten Ausschnitt ist in der oberen Spur die automatische Segmentierung und in der unteren die Referenzsegmentierung gezeigt. Durch die zu frühe Segmentierung des "mhm" verschieben sich alle folgende Segmente nach vorn.
Abb. 5-14: Ausschnitt aus einer Talkshow: äh
Der gezeigte Ausschitt repräsentiert einen Fehler, der durch zu spätes Segmentieren der Hesitation "äh" entsteht.
Alle Vorgängersegmente in der oberen, automatisch segmentierten Spur sind falsch.
Im Beispiel von Abbildung 5-13 ist die falsche Segmentierung des Rezeptionssignal "mhm" gezeigt. Durch falsche Zuordnung des "mhm" werden die nachfolgenden Segmente "und die jagd"
Seite 96
so weit nach vorn geschoben, bis das Segment "jagd" an die Stelle des "mhm" (Referenzsegmentierung) segmentiert wird. Erst mit dem nachfolgenden Segment von "jagd" ist die Segmentierung wieder synchronisiert. Im Falle von "jagd" entsteht ein Fehler von fast 2 Sekunden. Das
Beispiel soll zeigen, dass ein lokal begrenzter Fehler trotzdem große Auswirkungen haben kann.
Im Gegensatz dazu werden in dem Beispiel in Abbildung 5-14 durch das falsche Segmentieren
des Hesitationssignals "äh" alle Vorgängersegmente falsch zugeordnet. Die entstandenen Fehler
werden durch die Kombination mit einem langem Rauschsignalabschnitt und Atmen noch zusätzlich verstärkt. Die gesamte Fehlersequenz dauert ungefähr 6 Sekunden.
Um diese Fehler zu verhindern bzw. soweit zu reduzieren, dass eine ungenaue Segmentgrenzzuweisung auditiv nicht mehr wahrnehmbar ist, werden neue Ganzwortmodelle erstellt, trainiert
und optimiert. Die Verwendung der neuen Ganzwortmodelle gleichberechtigt mit den bisher erzeugten Modellen ergeben die in Abbildung 5-15 und 5-16 dargestellten Beispielsegmentierungen.
Das Beispiel in Abbildung 5-15 stellt die verbesserte automatische Segmentierung des Beispiels
aus Abbildung 5-13 unter Verwendung aller Ganzwortmodelle dar.
Abb. 5-15: Ausschnitt aus einer Talkshow: mhm - Lösung
Das Beispiel aus Abbildung 5-13 ist hier nochmals gezeigt, allerdings mit den neuen Ganzwortmodellen. Die obere
Spur zeigt die automatische Segmentierung mit den neuen Modellen, die mittlere die ohne Ganzwortmodelle. Im
Vergleich mit der Referenzspur zeigt sich die Güte des neuen Modells für "mhm".
Seite 97
Das Beispiel in Abbildung 5-15 zeigt deutlich die Konsequenz aus der "freien" Verwendung des
Modells-RAUSCHEN. Anders als in der Referenzsegmentierung werden in der neuen automatisch erzeugten Segmentierung vier RAUSCHEN generiert, die in Verbindung mit dem neuen
Modell für MHM ein Verschieben der entsprechenden Nutzsegmente "mhm", "die" und "jagd"
bewirken. Im Falle des Rezeptionssignals "mhm" und des Segmentes "jagd" bewirkt das Einfügen von RAUSCHEN allerdings eine Verbesserung der Segmentierung gegenüber der Referenzsegmentierung. Das Segment "und" bleibt unverändert, nur bei "die" entspricht das
RAUSCHEN einem Einfügefehler.
Die Kombination der neuen Ganzwortmodelle erzeugt eine nahezu fehlerfreie Segmentierung.
Im Vergleich zu der ursprünglichen, automatisch erzeugten Segmentierung ist die Verbesserung
deutlich zu sehen.
Das Beispiel in Abbildung 5-16 ist die verbesserte Segmentierung des Beispiels aus Abbildung
5-14. Das Hesitationssignal "äh" ist von einer langen und einer kurzen Rauschensequenz eingeschlossen und somit deutlich von den übrigen Nutzsegmenten getrennt. Trotzdem wird in der
ursprünglichen automatischen Segmentierung das "äh" zu spät segmentiert und beeinflußt alle
Vorgängersegmente. Durch den Einsatz der neuen Ganzwortmodelle wird "äh" richtig segmentiert, begünstigt von beiden RAUSCHEN, die an dieser Stelle quasi als Trigger dienen.
Abb. 5-16: Ausschnitt aus einer Talkshow: äh - Lösung
Das Beispiel aus Abbildung 5-14 ist um die obere Spur erweitert worden, die die Segmentierung mit den neuen
Ganzwortmodellen zeigt. Der Vergleich mit der mittleren Spur zeigt die Verbesserung der Genauigkeit aller Segmente, insbesondere die Zuordnung des Hesitationssignals "äh".
Seite 98
In diesem Beispiel zeigen sich die Auswirkungen des unscharf trainierten Modells RAUSCHEN
(siehe auch Fußnote 46) sehr deutlich. Der Abschnitt, der in der Referenzsegmentierung durch
ATMEN modelliert wird, wird nicht exakt durch das RAUSCHEN Modell in der oberen Spur
übernommen. Der Anfang des "äh" wird in der oberen Spur zu früh gesetzt, das Ende von "äh"
zu spät (Abweichung um ca. 0.03 Sekunden). Das die Verschiebung auslösende RAUSCHEN
ist allerdings kein Einfügefehler, sondern zu Recht eingesetzt, da in dem Sprachsignalabschitt
eine entsprechende Sequenz von Rauschen vorhanden ist. Der Vergleich mit der mittleren, ursprünglichen automatischen Segmentierung zeigt wiederum die Verbesserung der Genauigkeit,
die durch den Einsatz der neuen Ganzwortmodelle erzielt werden.
Experimente mit den Ganzwortmodellen, in denen die Modellgröße (Anzahl der Zustände) und
Anzahl und Art der Übergänge (Kanten von Zustand zu Zustand) variiert wurden, ergaben am
Ende bei folgender Konfiguration die besten Ergebnisse:
• hm (HM), m (M), mh (MH): 5 Zustände
• äh (EH), ähm, ehm äm, em (EHM): 7 Zustände
• mhm (MHM): 9 Zustände
Alle Modelle werden textgesteuert eingesetzt, eine Kombination wie in Experiment 1 ist hier
nicht notwendig, da diese Segmente immer ein orthographisches Korrelat besitzen. Die Ergebnisse der Segmentierung ergab in dem vorliegenden Fall mit Ganzwortmodellen für Hesitationsund Rezeptionssignalen kein einheitlichen Bild wie etwa in Experiment1. Wiesen in Experiment
1 die Ergebnisse auf dem "Mannheimer"-Teil des Evaluierungskorpus wenigsten leichte Tendenzen für eine Steigerung der Segmentiergenauigkeit aus, so ist in diesem Fall, trotz mehrerer
Versuche, eine leichte Verschlechterung eingetreten. Der Grund für eine Verschlechterung liegt
an den niedrigen Vorkommen der Hesitations- und Rezeptionssignalen in diesem Teilkorpus.
Das Vorkommen der Hesitation "äh" liegt z.B. bei 67 und "ä" bei 47. Dabei benützt die Sprecherin das "ä" aber nicht als Hesitation (im Sinne des trainierten "äh"s), sondern als Partikel "ein".
Im Vergleich dazu werden in dem zweiten Teil des Evaluierungskorpus 317 Hesitationen des
Typs "äh" benutzt. Aus diesem Grund werden die Ergebnisse der oben dargestellten Konfiguration nur für den "Talkshow"-Teil des Korpus, siehe Abbildung 5-17, gezeigt. Die Diagramme
(a) und (b) in Abbildung 5-17 zeigen die Ergebnisse der automatischen Segmentierung mit allen
Seite 99
neuen Ganzwortmodellen ("lang-gestrichelte" Kurve) im Kontext mit den Ergebnissen aus Ex-
periment 1 (nur nicht-sprachliche Ganzwortmodelle, "kurz-gestrichelte" Kurve).
100
90
80
70
60
50
0
alle Ganzwortmodelle
nicht-sprachliche
Ganzwortmodelle
500 10001500200025003000
Zeitintervall / ms
(a)
70
65
60
55
alle Ganzwortmodelle
nicht-sprachliche
Ganzwortmodelle
50
0 5 10 15 20 25 30 35 40 45 50
Zeitintervall / ms
(b)
Die Diagramme (a) und (b) zeigen das Ergebnis der automatischen Segmentierung unter Einbeziehung aller Genzwortmodelle auf einem Teil des Evaluierungskorpus. Das Diagramm in (b) ist eine gezoomte Darstellung von (a).
Der Unterschied zwischen den Experimenten 1 und 2 ist sehr gering, wie aus der gezoomten Darstellung ersichtlich
ist.
Das Basisergebnis ohne Ganzwortmodelle ist durch die Kurve mit den Kreis-Symbolen
dargestellt. Das Ergebnis aus Experiment 2 zeigt die gleiche enorme Steigerung der
Segmentiergenauigkeit wie Experiment 1, denn das Ergebnis aus Experiment 1 ist sozusagen in
Experiment 2 schon enthalten. Allerdings ist der Beitrag der Modelle für die Hesitations- und
Rezeptionssignale im Vergleich zu den Modelle für die nicht-sprachliche Signale niedriger.
Diesen Zusammenhang verdeutlicht das Diagramm (b), das einen Ausschnitt von Diagramm (a)
darstellt. Die beiden Kurven haben im Intervall [15..20] ms ihren Treffpunkt, davor ist das
Ergebnis von Experiment 2 besser, dannach das von Experiment 1, allerdings ist der Unterschied
beider Ergebnisse im oberen Intervallbereich kleiner als im unteren Intervallbereich. Im Bereich
[0..5] ms ist der Unterschied mit 2.5 % am höchsten.
In Bezug auf die praktische Anwendung der Experimente sind die Ergebnissse insofern als erfolgreich anzusehen, da der untere Bereich, also die kleinste zulässige Abweichung einer automatisch erzeugte Segmentgrenzen und einer tatsächlichen Segmentgrenze, für die Performanz
verantwortlich ist. Somit können die Ergebnisse aus Experiment 2 als eine erfolgreiche Model-
Seite 100
lierung der problematischen Signalabschnitte bezeichnet werden.
5.4.
Zusammenfassung
In diesem Abschnitt ist der Rahmen vorgestellt worden, in dem am Institut für Deutsche Sprache
große Korpora gesprochener Sprache aufbereitet und annotiert werden. Das Ziel der Arbeiten
auf diesem Gebiet sind eine maschinelle Repräsentation und entsprechende Abfragemöglichkeiten auf den erstellten Annotationen durch das Recherchesystem COSMAS II. Eines der Hauptmerkmale von COSMAS II ist die Möglichkeit, die Ergebnisse von Suchanfragen neben einer
textbasierten Darstellung auch anzuhören. Die Voraussetzung dafür, Textabschnitte anhören zu
können, ist die Aufbereitung der Annotationen mit Zeitmarken. Die Zeitmarken werden durch
Segmentierung erzeugt, die auf Grund der sehr großen Datenmengen maschinell durchgeführt
wird. Solche automatischen Segmentierungsverfahren sind allerdings sehr anfällig in ihrer Genauigkeit, wenn die zu verarbeitenden Sprachdaten Abweichungen von der hochsprachlichen
Sprechernorm aufweisen. In zwei Experimenten wurden Methoden vorgestellt, um die Genauigkeit auch bei schwierigen Sprachdaten wie Dialektdaten, Diskussionsrunden mit mehren Teilnehmern uvm. auf einem relativ hohen Niveau zu halten. Die Methoden beinhalten zum Einen
eine adäquate Modellierung spontansprachlicher Eigenschaften, wie etwa Hesitations- und Rezeptionsphänomenen und zum Anderen nicht-sprachlicher Eigenschaften, wie etwa Störgeräusche, Lachen und Klatschen. Es konnte in den Experimenten gezeigt werden, dass in beiden
Fällen nicht alle Modelle durch ein eigenes Modell repräsentiert werden mussten, vielmehr sind
aus dem Blickwinkel einer automatischen Segmentierung viele Phänomene durch ein einziges
Modell generalisierbar. Zum Beispiel konnte gezeigt werden, dass die Segmentiergenauigkeit
steigt, wenn Signalabschnitte wie Rauschen, Atmen, Räuspern nur durch ein Modelle RAUSCHEN abgedeckt werden; ebenso konnten alle verschiedenen Hesitationen durch die zwei Modell EH (für: äh, ä) und EHM (für: ähm, äm, ehm, em) ausreichend genau modelliert werden.
Für die Rezeptionsegmente reicht es aus, Modelle für M (für: m, mh, hm) und MHM (für:
hmhm, mhm, mm, mmm) anzunehmen. Es zeigt aber auch, dass die Ergebnisse nicht auf alle
Arten von Sprachdaten übertragen werden können. Der Einsatz von Ganzwortmodellen auf dem
"Mannheimer"-Teil des Evaluierungskorpus ergab eine leichte Verschlechterung der Segmentiergenauigkeit. Die Ergebnisse der Experimente weisen insgesamt eine maximale Steigerung
der Segmentiergenauigkeit von 13% auf.
Seite 101
KAPITEL 6
Das Sprachdatenbanksystem IMSPhoBase
Zur Abfrage und Wartung der heterogen annotierten Sprachsignal-Korpora des Lehrstuhls für
Experimentelle Phonetik am IMS sind verschiedene Werkzeuge zu dem IMSPhoBase Sprachdatenbanksystem verschmolzen worden. Das Sprachdatenbanksystem verfügt über ein einfaches Annotationsmodell, das in eine relationale Datenbank überführt worden ist, über einen
Mechanismus, um Daten automatisch konvertieren und segmentieren zu können sowie über ein
Analysemodul, das auf die Ergebnismenge einer SQL-Anfrage angewendet werden kann.
6.1.
Annotationsmodell
In Kapitel 2 sind die wichtigsten Annotationsmodelle und dazugehörenden Systeme vorgestellt
worden. Die Annotationsmodelle sind hinsichtlich ihrer mathematischen Wohlgeformtheit, ihrer Komplexität und Mächtigkeit und auch unter Berücksichtigung ihrer möglichen (algebraisch
wohlgeformten) Abfragemöglichkeiten, aber auch in Hinsicht auf ihrer Nachteile diskutiert worden.
Auf Grund dieser Diskussion ist die Entscheidung bei dem hier beschriebenen System IMSPhoBase auf ein einfaches, flaches und xwaves-orientiertes Annotationsmodell gefallen. Die Gründe
hierfür sind vielschichtig: Auf der einen Seite ist es notwendig, die bereits vorhandene Datenlandschaft so adäquat wie möglich zu erfassen, auf der anderen Seite ist es aber auch notwendig,
so flexibel und offen wie möglich für neue Annotationsstrukturen und linguistische Beschreibungsebenen zu bleiben. In Abbildung 6-1 ist das Annotationsmodell schematisch dargestellt.
Seite 102
en
gs
lb
Ta
Si
r
e
em
te
on
ör
W
Ph
Abb. 6-1: Schematische Darstellung des Annotationsmodells
Das Annotationsmodell ist gekennzeichnet durch die Menge der Annotationsebenen, die keine gegenseitige Interaktion aufweisen. Jede Annotationsbene verfügt über eine eigene Zeitkodierung.
Das Annotationsmodell ist dadurch charakterisiert, dass es sowohl innerhalb als auch zwischen
den linguistischen Beschreibungsebenen keine Verzeigerungen gibt. Gleichfalls gibt es auch
keine Indizierung; jede Beschreibungsebene hat eine explizite Zeitachse kodiert, die allerdings
über alle assozierten Dateien hinweg gleich ist. Unter assozierten Dateien wird die zentrale
Sprachsignaldatei sowie alle daraus ableitbaren (linguistischen) Beschreibungsebenen verstanden. Die Verbindung dieser Dateien ist im Annotationsmodell nur durch den gemeinsamen Namensstamm implizit enthalten. Die Unterscheidung wird somit durch die Extentionen einer
jeden Datei definiert. Die Konsequenz daraus ist, dass in diesem Annotationsmodell keine Segmente, also Einheiten der Phonem-, Silben-, Wort-, Tag- oder Prosodieebene, indiziert werden,
sondern ganze Dateien. Das wiederum hat zur Konsequenz, dass mit dem Datenbanksystem allein noch keine Abfragen auf Segmentebene möglich sind. Die Abfrage auf Segmentebene wird
extern durch ein Analysemodul realisiert. Damit ist das Datenbanksystem letztendlich nur zur
Verwaltung und Abfrage der Dateien konzipiert, wobei unter Abfragen die Bildung von Mengen
von Dateien (natürlich sind diese wiederum linguistische Beschreibungsebenen) gemeint ist,
welche nach Kriterien wie Korpuszugehörigkeit, Aufnahmedatum und-ort, Geschlecht und Alter der Sprecher, Sprechersituation usw., also auf Grund von Metadaten von Sprachsignalen, gebildet werden können.
6.2.
Realisierung der Sprachdatenbank IMSPhoBase
In diesem Abschnitt wird die Realisierung der Sprachdatenbank IMSPhoBase vorgestellt. Der
Abschnitt beginnt mit einer Anforderungsanalyse an die Leistungsfähigkeit des Systems. Aus
der Anforderungsanlyse ergibt sich das Datenbank-Design, das an Hand der vorgestellten
Grundlagen (siehe Abschnitt “Grundlagen der Datenbanktechnik” auf Seite 69) durchgeführt
Seite 103
wird, sowie die Auswahl der Datenbank-Engine. In Abschnitt 6.2.4. wird die Implementierung
und die Funktionalität des IMSPhoBase-Management-Systems (spezielle Implementierung eines Datenbank-Management-Systems) vorgestellt.
6.2.1.
Anforderungsanalyse der Sprachdatenbank
Die Motivation für die Entwicklung einer Sprachdatenbank ist bereits in Kapitel 1 (Kapitel "Einführung, S. 11") ausführlich dargestellt worden. Auf Grund der beschriebenen speziellen Ausgangssituation am IMS ist es notwendig, eine proprietäre Lösung zu wählen. Im Folgenden sind
nochmals die wichtigsten Punkte der zu berücksichtigenden Rahmenbedingung aufgezählt:
• Die Daten sind vor dem Sprachdatenbanksystem vorhanden.
• Es liegt eine absolut heterogene Datenlandschaft vor.
• Bei dem Entwurf muß berücksichtigt werden, dass vorhandene Daten nicht
veränderbar sind. Alle Besonderheiten in Bezug auf die Daten müssen
durch das System modelliert werden können.
• Die Speicherorte der Daten der einzelnen Benutzer müssen unverändert
bleiben, d.h. die Daten müssen in ihrem Ursprung verbleiben und trotzdem
für alle benutzbar sein. (Wenn die Daten für ein Sprachdatenbanksystem
zentralisiert gehalten werden sollen, müssen alle Benutzer sämtliche Datenpfade neu anlegen, was einer Akzeptanz durch die Benutzer und einer
einfachen Benutzung aller Daten für die Benutzer entgegen steht. Ein weiterer Vorteil der bestehenden dezentralen Vorhaltung der Daten ist, dass
der jeweilige Besitzer für die Korrektheit seiner Daten verantwortlich
bleibt und nur er Manipulationen an den physikalischen Daten durchführen
kann).
• Es müssen unterschiedlichste Arten von Signalen eingebunden werden
können. Nicht nur die Sprachsignale unterscheiden sich, auch sämtliche,
den Sprachsignalen assozierte Daten sind unterschiedlich. Oft werden in
unterschiedlichen Projekten verschiedene Arten von Segmentierungen benötigt und deshalb werden Sprachsignale nicht immer gleich annotiert.
Seite 104
• Im Verlauf von Projekten entstehen immer auch verschiedene Tools, mit
denen die Datenbestände gewartet und manipuliert werden. Diese Werkzeuge, die oft auch sehr datenspezifisch sind, sollten weiterhin verfügbar
bleiben. Manche Anwendungen erfordern einen direkten Zugriff von externen Programmen auf Daten.
• Die Daten werden völlig verteilt vorgehalten. Viele Daten sind über die verschiedenen HomeDirectories der einzelnen Mitarbeiter verteilt; Daten liegen z.B. auf verschiedenen Rechnern und Verzeichnissen sowie auf
CDROMs und zukünftig vermehrt im Internet oder weit entfernten Rechnerknoten.
• Die Datenmenge ist enorm, nämlich mehrere 10 GB. Werden pro 1 GB ca.
80.000 Labelsegmente auf Wortebene angesetzt, so ergibt das für die Basisannotation (Phonem, Wort, Silbe, Tags, Orthographie) eine Aufkommen
von ca. 600.000 bis 700.000 Segmente. Jede weitere Annotationsebene erweitert die Anzahl der Segmente. Unabhängig vor einem noch so effektiven Datenmodell ist es sehr schwierig, eine solche Menge von Indizes zu
verwalten.
Aus diesen Rahmenbedingungen heraus ergeben sich folgende Anforderung an das Sprachdatenbanksystem IMSPhoBase:
• das Datenbanksystem soll als eine Schnittstelle zwischen allen Benutzern
und allen Daten fungieren. Wobei unter das Konzept “Benutzer“ auf der einen Seite tatsächliche Benutzer fallen, die eine benutzerfreundliche
Schnittstelle erwarten, und auf der anderen Seite Programme, die direkt mit
dem Datenbanksystem kommunizieren können müssen.
• das Datenbanksystem muß in der Lage sein, die Daten, unabhängig von ihrem Speicherort, zu verwalten.
• Sprachdaten können nicht direkt indiziert werden. Die Indizierung aller den
Sprachdaten assozierten Daten sprengt den Rahmen. Alle Daten werden
nur dateiweise indiziert.
Seite 105
• das Datenbanksystem soll in der Lage sein, neue Daten zu erzeugen, da
nicht immer alle Daten vorhanden sind; die Tools für die Erzeugung neuer
Daten können sehr verschieden sein.
• die Architektur des Datenbanksystems muß so modular und offen sein, dass
jederzeit neue Daten eingetragen werden können.
• das Datenbanksystem muß unter SGI IRIX™ lauffähig aber auch auf andere
Plattformen portierbar sein.
Auf der einen Seite durch die hohen, sehr spezifischen Anforderungen an das Datenbank-Management-System, das bei kommerziellen Standardsystemen nicht in der Weise verändert werden
kann und auf der anderen Seite durch die Forderung an ein nicht-kommerzielles System, können
diese Anforderungen nicht durch ein Standardsystem erfüllt werden.
Aus diesen Gründen ist die Wahl auf eine gemischte Architektur aus freier Software und Eingenentwicklung gefallen. Es wird eine freie Datenbank-Engine in dieses System eingebaut; das
Datenbank-Management-System IMSPhoBase-MS ist in der Programmiersprache C implementiert. Auf Grund der Entscheidung, die Daten nicht auf unterster Ebene - im Falle von z.B. Wortsegmentierung wären das jedes einzelne Wortsegment - zu indizieren, können auf dieser Ebene
keine direkten Analysen gemacht werden. Das Ergebnis einer Datenbankanfrage ist immer nur
eine Ergebnismenge, die ganze Dateien enthält. Deshalb ist ein Analysemodul notwendig, um
auf der Ergebnismenge der Datenbankanfrage die erwünschten Untersuchungen durch zu führen. Dieses Analysemodul ist im Sinne der geforderten Modularität ein von dem IMSPhoBaseMS unabhängiges in der Programmiersprache Perl implementiertes Programm. Damit ist das
Analysemodul ein Programm neben vielen potentiellen anderen externen Programmen, die direkt auf das IMSPhoBase-MS zugreifen kann. Im Sinne dieser Anwendungen ist es wichtig, dass
alle Schnittstellen des Systems textbasiert sind. Dazu zählt die Schnittstelle zwischen IMSPhoBase-MS und Analysemodul, aber auch die Schnittstelle von Analysemodul zu weiterverarbeitenden Programmen oder ein denkbares GUI-basiertes Benutzer Interface. Die prototypische
Realisierung ist im Rahmen einer Diplomarbeit [6.4] entwickelt worden. In Abb. 6-2 ist die Architektur des Gesamtsystems dargestellt.
Seite 106
Benutzer
z.B. interaktiverDBMS-Modus
Programm
z.B. Analysemodul
Datenbankmanagementsystem (IMSPhoBase-MS)
Administrationstools
Datenbank
Abb. 6-2: Die Architektur von IMSPhoBase
Das System besteht aus drei Teilen. Die unterste Ebene bildet die Datenbank, in der die Daten abgelegt sind. Die
mittlere Ebene ist ein Datenbank-Management-System, das als Schnittstelle zwischen den Benutzern und den Daten
fungiert. Die oberste Ebene sind die Benutzer, in dem vorliegenden Fall sowohl tatsächliche Benutzer als auch externe Programme, die direkt auf die Daten zugreifen können.
Das Datenbanksystem besteht im Wesentlichen aus drei Modulen. Auf der untersten Ebene ist
die Datenbank-Engine, die die Daten verwaltet. Das IMSPhoBase-MS dient als Schnittstelle
zwischen den Benutzern und den Daten, kommuniziert mit der Datenbank-Engine über eine CSchnittstelle und über eine kommandozeilen-orientierte Menüstruktur im Falle tatsächlicher Benutzer. Für die Kommunikation zwischen IMSPhoBase-MS und anderen Programmen (wie eben
z.B. das Analysemodul) sind entsprechende Optionen im Programmaufruf enthalten. In den weiteren Abschnitten werden die drei Module beschrieben.
6.2.2.
Auswahl und Funktion der Datenbank-Engine
Die Aufgabe der Datenbank-Engine ist es, Daten logisch zusammen zu fassen, bzw. zu organisieren und Tools zu deren Manipulation bereit zu stellen. Unter Manipulation versteht man das
Eintragen, Ändern und Löschen von Daten. Die Verwaltung der Daten geschieht im vorliegenden Fall durch Indizierung, im Sinne des in Abschnitt 6.1. vorgestellten Annotationsmodells.
Die Auswahl der Datenbank-Engine orientiert sich an den folgenden Anforderungen:
Seite 107
• Die Datenbank-Software muß frei sein, d.h., mit dem Erwerb sind keine
Kosten verbunden und es fallen im Weiteren keine Kosten an und die Software kann zumindest zu Forschungszwecken weitergegeben werden.
• Client-Server-basierte Architektur.
• Auf Grund der intendierten Anwendung sind nicht alle ANSI-SQL Features
notwendig. Eine Datenbank-Engine, die nicht alle Features implementiert
hat, ist schneller.
• Auf Grund des modularen Aufbaus wird eine möglichst reichhaltige Anzahl
von Schnittstellen benötigt.
• Die Engine sollte auf vielen Betriebssystemen ablauffähig sein, zumindest
aber unter SGI IRIX™ und Linux.
Aus diesen Überlegungen heraus wurde für die hier beschriebene Anwendung mSQL [6.2] in
der Version 1.0.16 gewählt. mSQL ist eine freie, SQL-basierte48, relationale Datenbank-Engine,
die als Client-Server-Architektur ausgelegt ist. In Abbildung 6-3 ist die Architektur dargestellt.
Das mSQL-System ist mit Schnittstellen für CGI-Programmierung, Perl, Python, C und C++,
Java und JDBC ausgestattet. Der mSQL-Server steht als Vermittler zwischen den Clients und
der Datenbank. Das Verarbeitungsprinzip ist im Gegensatz zu z.B. MySQL ([4.1], [4.3])
"queue"-orientiert, d.h. alle Clients reihen sich mit ihren Anfragen in eine "queue" ein, der Server arbeitet die Anfragen der Reihenfolge nach ab. Dabei wird nicht zwischen lokalen Clients
(z.B. Unix-Sockets) oder externen Clients (z.B. TCP/IP-Sockets) unterschieden. Diese Architektur muß nicht unbedingt ein Nachteil sein, wenn der Datenbank-Server auf einem schnellen
Serverrechner läuft. Der mSQL-Server wird auf einem Serverrechner installiert und läuft dort als
"Dämon"49. Die Administrationstools von mSQL erlauben, auf dem Serverrechner vorhandene
Datenbanken einzubinden oder neue Datenbanken hochzufahren.
48 SQL (=Structured Query Language), ist eine Datenbankabfragesprache, deren Erklärung aber den
Rahmen hier sprengen würde. Für weiterführende Literatur siehe z.B. [4.1] oder [http://users.neca.com/
ltruett/sql.html], [http://homepages.go.com/~chlee1h/sql.html], [http://w3.one.net/~jhoffman/sqltut.htm], [http://
www.astentech.com/tutorials/SQL.html].
49 Ein Dämon ist ein Programm, dass ständig auf einem Server läuft.
Seite 108
Lokale Clients
mSQLServer
Abarbeitung der Anfragen
?
?
?
?
?
Abfragen
Externe Clients
Abb. 6-3: mSQL-Architektur der IMSPhoBase
Die zentrale Einheit ist der mSQL-Server. Um den Server herum sind die Clients gruppiert, die Anfragen an den
Server stellen. Sowohl schnelle lokale Clients als auch langsamere externe Clients müssen über die gleiche synchrone Warteschlange ihre Anfrage stellen. Die Verbindung der externen Clients werden über das TCP/IP-Protokoll realisiert, womit prinzipiell Abfragen von beliebigen Computern möglich ist.
Über den mSQL-Monitor (in mSQL enthaltenes Programm msql) können SQL-basiert die Datenbestände bearbeitet werden. Der mSQL-Monitor kann als lokaler Client auf dem Serverrechner
benutzt werden oder aber auch als externer Client auf einem beliebigen Rechner. Beim Aufruf
des Monitors muß immer eine Datenbank bzw. die Datenbanken, die abgefragt werden sollen,
angegeben werden; beim Aufruf als Client muß zusätzlich auch der Name des Servers, auf dem
der SQL-Dämon läuft, angegeben werden. Durch eine Inititialisierungsdatei können Sicherheitsaspekte wie z.B. Rechnerdomänen, von denen aus auf die Datenbank zugreifen dürfen, realisiert werden.
Der Nachteil einer reinen mSQL-Monitor basierten Arbeitsweise liegt darin, dass umfangreiche
Vorkenntnisse der Abfragesprache SQL notwendig ist. Die genaue Beschreibung der Mächtigkeit der mSQL-Tools findet sich in [6.2].
6.2.3.
Datenbank-Design
Ausgehend von den vorgestellten grundlegenden Konzepten des allgemeinen Datenbank-Designs (siehe Abschnitt “Datenbankdesign” auf Seite 69) soll im folgenden Abschnitt der Entwurf
des Datenmodells von IMSPhoBase erarbeitet werden.
Seite 109
6.2.3.1. Logisches Datenmodell
Als elementares Objekt des Systems wird das Sprachsignal angenommen, über das Daten und
Informationen gesammelt werden sollen. Das Objekt Sprachsignal soll durch die Entität FILE
modelliert werden. Die Entität bekommt die Attribute "ID", "name", "pre", "datum", "uhrzeit",
"endung", "pfad" und "quelle" zugewiesen. Alle Attribute beschreiben Eigenschaften von
Sprachsignalen: "name" beinhaltet den Dateinamen, in "pre" ist der Dateistamm und in "endung" die Endung der Datei gespeichert, "datum" beinhaltet das Produktionsdatum des Sprachsignals (ebenso "uhrzeit"), "pfad" beinhaltet den vollen Pfadnamen des Sprachsignals und in
"quelle" ist die Herkunft des Sprachsignals gespeichert. Eine solch detallierte Definition von Attributen erlaubt eine vielfältige Form der Abfrage, so kann z.B. gezielt nach Sprachsignalen gesucht werden, die einer bestimmten Quelle zugeordnet sind; das gleiche gilt für das
Aufnahmejahr ("datum", "uhrzeit"). Darüber hinaus wird das Attribut "endung" benutzt, um im
Hintergrund Verabeitungsroutinen anzustoßen (siehe Abschnitt “Funktionen des IMSPhoBaseMS” auf Seite 117). Das Attribut "ID" ist das Schlüsselattribut (Primärschlüssel) der Entität FILE. In Abbildung 6-4 ist das Datenmodell mit der Entität FILE dargestellt.
FILE
ID
name
pre
datum
uhrzeit
endung
pfad
quelle
Abb. 6-4: Erster Entwurf des logischen Datenmodells
Das Datenmodell besteht aus einer Entität FILE, das die zentrale Entität des gesamten Datenmodells ist. Die Entität
enthält sämtliche Attribute, die benötigt werden, um ein Sprachsignal distinktiv zu beschreiben. Das Schlüsselattribute ist ID.
Das Datenmodell erfüllt die Anforderungen der 1. Normalform, da alle Attribute einwertig sind.
Da aber in der praktischen Anwendung mehr als ein Quellenname notwendig sein kann, ist eine
zweite Entität, QUELLE, eingeführt worden. Die Verbindung zwischen FILE und QUELLE
wird über eine Zuordnungstabelle realisiert. Durch die Einführung solcher Zuordnungstabellen
Seite 110
wird das Modell sehr flexibel, da die zentrale Entität FILE nicht ständig im Sinne von Aufnahmen neuer Fremdschlüssel verändert werden muss . In Abbildung 6-5 ist das erweiterte Datenmodell gezeigt.
FILE
FILE_QU_ZUORDNUNG
QUELLE
ID
name
ID
FI_QU_ZU_ID
ID
name
pre
name2
datum
uhrzeit
endung
pfad
quelle
FILE_ID
QUELLE_ID
ID
ID
Abb. 6-5: Zweiter Entwurf des Datenmodells
Das Datenmodell besteht aus den Entitäten FILE, FILE_ID, QUELLE, QUELLE_ID und einer Zuordnungstabelle
FILE_QU_ZUORDNUNG. In der Entität QUELLE sind weitere Informationen zum Sprachsignal möglich, die Tabellen *_ID berechnen für jeden Neueintrag einer Instanz der entsprechenden Entität eine neue, eindeutige Nummer
(Primärattribute). Zuordnungstabellen haben organisatorische Funktion und verfügen daher nicht über Primärattribute.
Das Datenmodell ist um die Entität QUELLE, das die zwei Attribute "name" und "name2" besitzt, erweitert worden. Die Entität QUELLE kann unabhängig von FILE durch Hinzunahme
weiterer Attribute vergrößert werden. Die Verbindung zwischen einem Sprachsignal (Entität FILE)
und
einer
Quelle
(Entität
QUELLE)
erfolgt
über
die
Zuordnungstabelle
FIILE_QU_ZUORDNUNG. In der Zuordnungstabelle sind die Attribute "ID" und
"FI_QU_ZU_ID" enthalten, beide Attribute sind Fremdschlüssel der Entitäten FILE und QUELLE. Zusätzlich sind noch zwei weitere Entitäten, FILE_ID und QUELLE_ID, eingefügt worden.
Beide Entitäten haben die Aufgabe, einen aktuellen, eindeutigen Primärschlüssel für FILE und
QUELLE bereit zu stellen.
Einer Quelle können viele Sprachsignale zugeordnet sein dieser Sachverhalt wird durch die "1M_Beziehung" zwischen FILE_QU_ZUORDNUNG und QUELLE ausgedrückt. Das Datenmodell aus Abbildung 6-5 entspricht der 3. Normalform, da die Nicht-Schlüsselattribute nicht von
einander abhängig sind.
Seite 111
Die nächste Ergänzung des Datenmodells ergibt sich aus den weiteren Eigenschaften von
Sprachsignalen. Jedes Sprachsignal hat ein Format und einen Typ. Durch die Aufteilung des
Typs in Haupttyp und Untertyp und die Realisierung der Verbindungen über Zuordnungstabellen wird die offene und jederzeit erweiterbare Struktur beibehalten. Das Ergebnis der dritten
Entwurfsphase ist in Abbildung 6-6 dargestellt.
FORMAT_ID
FORMAT
FILE_FO_ZUORDNUNG
ID
ID
kennzeichnung
ID
FI_FO_ZU_ID
FILE
FILE_QU_ZUORDNUNG
ID
name
ID
FI_QU_ZU_ID
pre
HAUPTYP_ID
HAUPTTYP
FILE_HT_ZUORDNUNG
ID
ID
kennzeichnung
ID
FI_HT_ZU_ID
UNTERTYP_ID
UNTERTYP
FILE_UT_ZUORDNUNG
ID
ID
kennzeichnung
ID
FI_UT_ZU_ID
datum
uhrzeit
endung
pfad
quelle
QUELLE
ID
name
name2
FILE_ID
QUELLE_ID
ID
ID
Abb. 6-6: Dritter Entwurf des Datenmodells
Das Modell ist um die Entitäten FORMAT, HAUPTTYP und UNTERTYP ergänzt worden. Die Verbindung zur
Hauptentität FILE ist wiederum durch Zuordnungsentitäten realisiert. Jeder der neuen Entitäten ist eine Entität zugeordnet, die jeweils eindeutige Primärschlüssel bereitstellt.
Die Erweiterung des Datenmodells bringt keine neue Strukturen gegenüber dem 2. Entwurf mit
sich. Das Datenmodell befindet sich somit nach Definition noch immer in der 3. Normalform.
Die letzte Erweiterung des Datenmodells betrifft die Funktionalität der Hintergrundverarbeitung. Die Möglichkeit der Datenverarbeitung im Hintergrund soll in der Konzeption bereits
so verankert sein, dass jederzeit, ohne Re-Designmaßnahmen, neue Verarbeitungsroutinen integriert werden können. Dazu wird die neue Entität PROZEDUR eingeführt, die mittels zweier
Zuordnungstabellen FILEEXT_PROZEDUR_ZU und FILE_PRO_ZUORDNUNG mit FILE in
Verbindung gebracht wird. Durch die Zuordnungstabelle FILEEXT_PROZEDUR_ZU ist es
möglich, alle in der Datenbank vorhandenen Datensätze entsprechend den Angaben über Ursprungsformat (Endung) und Zielformat (Endung) konvertieren zu lassen. Durch die Zuordnungstabelle FILE_PRO_ZUORDNUNG können solche Konvertierungen durch die explizite
Datei-Programm-Zuordnung ausgelöst werden. Die Pfade (also das Ergebnis der Umwandlun-
Seite 112
gen) werden sowohl in die Haupttabelle FILE als auch in entsprechenden Protokolltabellen
(FILE_SPH, FILE_WORDS, FILE_PHONES, FILE_TXT) eingetragen. Der Platz des physikalischen Ergebnisses der Umwandlung wird durch einen Pfad (hier: Umgebungsvariablen "ExPho") bestimmt. Somit ist es möglich, auf die Ergebnisse von Umwandlungen direkt wieder
zuzugreifen.
In Abbildung 6-7 sind die letzten Erweiterungen des logischen Datenmodells zusammen mit der
Entität ZUGRIFFSRECHT abgebildet. Die Entität ZUGRIFFSRECHT ist im Augenblick nur
konzeptionell abgebildet, nicht aber implementiert.
PROZEDUR_ID
ID
FILEEXT_PROZEDUR_ZU
PROZEDUR
FILE_PRO_ZUORDNUNG
ext
pro_name
ID
name
ID
FI_P_ZU_ID
outext
typ
FORMAT_ID
FORMAT
FILE_FO_ZUORDNUNG
ID
ID
kennzeichnung
ID
FI_FO_ZU_ID
FILE
FILE_QU_ZUORDNUNG
ID
name
ID
FI_QU_ZU_ID
pre
HAUPTYP_ID
HAUPTTYP
FILE_HT_ZUORDNUNG
ID
ID
kennzeichnung
ID
FI_HT_ZU_ID
UNTERTYP_ID
UNTERTYP
FILE_UT_ZUORDNUNG
ID
ID
kennzeichnung
ID
FI_UT_ZU_ID
datum
uhrzeit
endung
pfad
quelle
QUELLE
ID
name
name2
FILE_ID
QUELLE_ID
ID
ID
Abb. 6-7: Vollständiger Entwurf des logischen Datenmodells
Die Erweiterung um die Entitäten PROZEDUR und deren Satellitenentitäten ist für die Funktion der Hintergrundverarbeitung notwendig. Die benötigten Prozeduren für die Hintergrundverarbeitung werden in die Tabelle PROZEDUR eingetragen; die Ausführung, Auswahl der entsprechenden Dateien, usw. werden durch die
Satellitenentitäten geregelt.
Es läßt sich leicht prüfen, dass das logische Datenmodell nach Abbildung 6-7 in der 3. Normal-
Seite 113
form ist. Durch das logische Datenmodell wird das Annotationsmodell (siehe Abschnitt “Annotationsmodell” auf Seite 102) folgendermaßen abgebildet: Alle Daten sind Instanzen der Entität
FILE. Die Verbindung der zusammenhängenden Dateien erfolgt über die als Attribute eingetragende Werte für "pre" (also gemeinsamer Stamm der assozierten Dateien) und "pfad" (abgebildetet Verzeichnisstruktur). Die Indizierung erfolgt über vollständige Dateien (alle
Datenentitäten).
6.2.3.2. Physikalisches Datenmodell - der Tabellenentwurf
Beim physikalischen Datenmodell werden die tatsächlichen Tabellen erzeugt. Die Vorgehensweise ist bereits in Abschnitt 4.1. dargestellt. Dieser Darstellung folgend, werden alle Entitäten
aus dem logischen Datenmodell in Tabellen abgebildet.
Im Augenblick besteht das physikalische Datenmodell aus 20 Tabellen, davon sind 7 Datentabellen, 7 Zuordnungstabellen (beziehungsdarstellende Tabellen) und 6 organisatorische Tabellen.
Die Datentabellen enthalten relevante, applikationsbezogene Informationen, welche die abzubildende Realität modellieren. Zu den Datentabellen gehören FILE, PROZEDUR, FORMAT,
HAUPTTYP, UNTERTYP, QUELLE und ZUGRIFFSRECHT. In Abbildung 6-8 ist stellvertretend die Tabelle FILE dargestellt.
Abb. 6-8: Umsetzung der Entität FILE in eine Tabellenstruktur
Die Umsetzung von logischem Datenmodell in physikalisches Datenmodell erfolgt durch Konvertieren von Zeilen
in Spalten. In der Abbildung ist ein Bildschirmabzug der zentralen Entität FILE in Tabellenform zu sehen.
Seite 114
Beim Vergleich zwischen der Entität FILE und der Tabelle FILE fällt auf, dass aus den ehemaligen Attributen die Zeilen der Tabelle geworden sind, die durch die Spalten “Type“, “Length“,
“NotNull“ und “Key“ spezifiziert werden. In der Spalte “Type“ werden die Datentypen der Attribute festgelegt. Das Schlüsselattribut “ID“ hat als einziger Eintrag den Datentyp “int“, damit
ein schneller Zugriff auf den Index möglich ist. Die anderen Attribute sind vom Datentyp “char“,
da dort typischerweise Zeichenfolgen gespeichert werden. “Length“ beschreibt die erlaubte
Länge der Zeichenketten. In der Spalte “NotNull“ ist vermerkt, welche Informationen zur Indentifizierung der Instanzen notwendig sind ("Y") und welche nur optional (“N“). Neben der "ID"
ist natürlich auch der Name und der Pfad unbedingt notwendig zur Indentifzierung einer Instanz,
also eines Objektes der realen Welt. Die Spalte “Key“ bestimmt den Primärschlüssel (“Y“) einer
Tabelle und den Fremdschlüssel (“N“). Die Zuordnungstabellen modellieren die wechselseitigen Beziehungen zwischen Datentabellen und erhalten somit die Übersichtlichkeit, Modularität
und
Erweiterbarkeit
des
FILEEXT_PROZEDUR_ZU,
FILE_HT_ZUORDNUNG,
Datenmodells.
Zu
diesen
FILE_PRO_ZUORDNUNG,
FILE_QU_ZUORDNUNG,
Tabellen
gehören:
FILE_FO_ZUORDNUNG,
FILE_UT-_ZUORDNUNG
und
FILE_ZUG_ZUORDNUNG.
Organisatorische Tabellen haben in erster Linie nichts mit der Applikation zu tun. Sie sind in
organisatorischer Hinsicht Hilfstabellen und stellen deshalb Daten zur Verfügung, die ein reibungsloses Zusammenspiel im Aufbau der Datenbank, in der Aufrechterhaltung der referentiellen Integrität zwischen den Tabellen ermöglicht. Die Tabellen sorgen dafür, dass der
Identifikator (also der Primärschlüssel) jedes Datensatzes in der entsprechenden Tabelle eindeutig ist, da das verwendete Datenbanksystem keinen direkten Mechanismus zur Ermittlung eines
neuen, eindeutigen Werts zur Verfügung stellt (im Sinne eines selbst inkrementierenden Zählers).
Zu
diesen
Tabellen
gehören:
FILE_ID,
PROZEDUR_ID,
FORMAT_ID,
HAUPTTYP_ID, UNTERTYP_ID, QUELLE_ID
Darüber hinaus gibt es Protokolltabellen, in denen Informationen über bereits vollzogene Konvertierungen enthalten sind; z.B. kann aus solchen Tabellen die Information gewonnen werden,
welche Dateien durch Konvertierung eingetragen sind. Zu den Protokolltabellen gehören im Augenblick: FILE_SPH, FILE_PHONES, FILE_WORDS, FILE_TXT.
Der Aufbau aller Tabellen ist prinzipiell gleich; eine vollständige Auflistung aller Tabellen befindet sich im Anhang (A.1).
Seite 115
6.2.4.
Das Datenbank-Management-System IMSPhoBase-MS
Wie schon in den vorangegangenen Abschnitten erwähnt, kommt dem IMSPhoBase-MS eine
besondere Bedeutung zu. Das IMSPhoBase-MS dient als Schnittstelle zwischen der DatenbankEngine und den Benutzern. Dabei hat es weit mehr Aufgaben zu erfüllen, als nur Daten weiterzureichen.
6.2.4.1. Anforderungen an das IMSPhoBase-MS
Da die Datenbank-Engine nur über eine SQL-Schnittstelle (mSQL-Monitor, siehe Abschnitt
“Auswahl und Funktion der Datenbank-Engine” auf Seite 107) verfügt, diese Abfragesprache
aber nicht intuitiv und einfach zu erlernen ist, besteht eine Aufgabe des IMSPhoBase-MS in der
Bereitstellung einer bedienerfreundlicheren Anwendungsschnittstelle. Ein weiterer Wunsch ist
die Möglichkeit, externen Programmen, wie z.B. Statistikprogrammen oder auch Trainingsmodulen von Spracherkennungssystemen direkten Zugriff auf die Daten zu gewähren. Darüber hinaus muss das IMSPhoBase-MS die speziellen Bedürfnisse der vorliegenden Datenlandschaft
adäquat modellieren können. Dazu zählt vor allem der Wunsch, dass das IMSPhoBase-MS in
der Lage sein soll, aktiv neue Daten zu erzeugen. Um dies möglich zu machen, müssen die externen Programme, die ja bereits im Datenmodell verankert sind (siehe Abschnitt “DatenbankDesign” auf Seite 109) bedienbar gemacht werden. Aus diesen Anforderungen heraus lassen
sich die Aufgaben des IMSPhoBase-MS als eine Verfeinerung der Anforderungen an das Gesamtsystem (siehe Abschnitt “Anforderungsanalyse der Sprachdatenbank” auf Seite 104) wie
folgt charakterisieren:
• Übernahme der Werkzeuge, die auf den Datenbeständen operieren.
• Implementierung von referentieller Integrität.
• Bereitstellung von Benutzerschnittstellen, die interaktiv (für Benutzer) und
nicht-interaktiv (für Programmzugriffe) benutzbar sein sollen.
• Das IMSPhoBase-MS soll im interaktiven wie im nicht-interaktiven Modus
über Batch-Funktion verfügen.
• Das IMSPhoBase-MS hat eine aktive Datenerzeugungskomponente.
Das IMSPhoBase-MS wurde unter Berücksichtung der oben aufgeführten Punkte in C entwik-
Seite 116
kelt. Alle Schnittstellen wurden textbasiert implementiert. Die Kommunikation mit der Datenbank-Engine verläuft über die C-Schnittstelle von mSQL, d.h. das IMSPhoBase-MS übersetzt
Anfragen an die Datenbank in SQL-Anweisungen. Die Benutzerschnittstellen sind kommandozeilen-orientiert, damit können sowohl externe Programme wie tatsächliche Benutzer das IMSPhoBase-MS-Programm benützen. Die Auswahl zwischen interaktivem und nicht-interaktivem
Verhalten des Programms wird durch eine Anzahl bestimmter Optionen beim Starten des Programms bestimmt. In beiden Modi sind die gleichen Funktionalitäten auswählbar und in beiden
Fällen wird als Ergebnis eine Datei mit der Antwortmenge der Datenbank generiert. Die Antwortmenge hat die Form einer Liste, in der alle ausgewählten Dateien samt Pfadangabe aufgelistet sind.
6.2.4.2. Funktionen des IMSPhoBase-MS
Über die für Datenbank-Management-Systeme typischen Funktionen hinaus verfügt das hier beschriebene IMSPhoBase-MS über folgende weitere Eigenschaften. Das IMSPhoBase-MS kann
in zwei Modi gestartet werden: Partielle Automatisierung und vollständige Automatisierung.
Der Begriff ''Automatisierung'' stellt in diesem Sinne einen eigenständigen Programmablauf
ohne Einwirkung des Benutzers dar. Der Benutzer muß bei der partiellen Automatisierung gegebenenfalls Eingabewerte eingeben, während bei der vollständigen Automatisierung dem IMSPhoBase-MS entsprechende Eingabewerte in Form von Argumenten übergeben werden. Der
erstgenannte Modus hat den Vorteil, dass der Benutzer die vollständige Kontrolle bei der Datenbankadministration hat und das Ergebnis der zuvor ausgeführten Datenbankoperation überprüfen und ansehen kann. Im Gegensatz dazu ist der zweite Modus von der Ablauflogik für den Fall
geeignet, wenn von anderen Anwendungen heraus eine Routine im IMSPhoBase-MS gestartet
werden soll.
Datensätze können sowohl im partiellen als auch im vollautomatischen Modus im Batch-Betrieb
importiert und gelöscht werden. Die Steuerung erfolgt über eine Folge von Kommandozeilenoptionen beim Start. Dabei können Daten aus einer zuvor präparierten Eingabedatei, die entweder relativ oder absolut adressiert sein können, in die Tabelle FILE übertragen werden, ohne dass
der Benutzer interaktiv in das Geschehen eingreift.
Der Aufbau der Eingabedatei entspricht dem Aufbau der Ausgabedatei: Eine Menge von Dateien mit Pfadangabe in Listenform. Jeder Dateneintrag in der Tabelle FILE wird durch eine ID-
Seite 117
Nummer eindeutig identifiziert. Die Übertragungsroutine prüft anhand des Namens der zu importierenden Sprachsignaldatei zuerst, ob diese Datei bereits in der Datenbank vorhanden ist.
Falls es nicht der Fall ist, wird eine neue ID-Nummer ermittelt und dieser Datei zugewiesen.
Im Gegensatz zum Löschen von Daten aus der Tabelle FILE ist es nicht möglich, eine Tabelle
vom IMSPhoBase-MS aus mittels des üblichen Platzhalters ''*'' komplett zu löschen. Nur Dateneinträge, die durch eine entsprechende, obligatorische Angabe spezifiziert sind, werden gelöscht. Auf diese Weise kann das IMSPhoBase-MS die Propagierung des Löschvorgangs an
andere Tabellen weiterleiten und kontrollieren, die eine Beziehung mit der urspünglichen Tabelle haben. Soll eine Tabelle dennoch komplett gelöscht werden, muß auf ''msql'' zurückgegriffen
und ein entsprechendes SQL-Statement ausgeführen werden.
Bei der aktiven Datenerzeugung (im Allgemeinen Konvertierung genannt) werden vordefinierte
Transformationsprozeduren direkt vom IMSPhoBase-MS aus aufgerufen. Im Prinzip werden
die Ergebnisse solcher Konvertierungen dort gespeichert, wo auch die Ausgangsdaten liegen.
Das geht auf Grund der Verteiltheitsprinzipien der Daten und deren Zugriffsrechte nicht immer.
Ein einfacher Weg, solche Probleme zu umgehen, ist die Benutzung einer Umgebungsvariablen.
Diese Umgebungsvariable gibt den Zielpfad an, also den Ort, an dem die konvertierte Datei abgelegt werden soll.
Im Moment sind als Konvertierungsroutinen die Programme e2sphere und Alphones (siehe
3.2.1.) im Einsatz.
6.2.4.3. Benutzung von IMSPhoBase-MS
Dieser Abschnitt beschreibt die wichtigsten Aspekte im praktischen Umgang mit den IMSPhoBase-MS. Das IMSPhoBase-MS kann interaktiv über ein Menüsystem benutzt werden. Über
dieses Menüsystem können alle Datenmanipulationsoperationen (siehe Abschnitt “Auswahl und
Funktion der Datenbank-Engine” auf Seite 107 ) ausgeführt werden50. Das Menüsystem ist
baumartig realisiert, wobei jeder Menüknoten im Baum mit einem Buchstaben verbunden ist.
Die Kombination der den Menüs zugewiesenen Buchstaben und den Auswahlziffern jedes Menüs realisieren den nicht-interaktiven Modus.
Bevor das Programm benützt werden kann, muss eine Datenbank aktiviert werden. Dazu gehört
50 Ausnahme: Backup- und Recoverstrategien
Seite 118
neben dem Starten des Datenbankdämons auch das Erzeugen bzw. Einlesen einer Datenbank.
Zur Verdeutlichung ist in Abbildung 6-9 das Startmenü des interaktiven Modus abgebildet.
Abb. 6-9: Screenshot des Startmenüs
Bildschirmabzug der obersten Menüebene des interaktiven Betriebsmodus des IMSPhoBase-MS. Auf dieser Ebene
sind die grundlegenden Funktion wie Abfragen, Umwandeln und Ändern verfügbar.
Auf dieser Ebene sind alle wichtigen Funktionen des Datenbanksystems auswählbar, dazu gehört das Abfragen, Ändern und Löschen von Daten. Auf dieser Ebene entspricht das den gleichen Funktionen, die durch den direkten SQL-Zugriff durch mSQL verfügbar sind. Durch
Eingeben der Auswahlziffern kann man auf die darunterliegenden Menüs zugreifen. Die Verzweigungen gehen immer so weit, bis eine Auswahl auf eine Prozedur, die eine Aktion auslöst,
zugreift und damit die Auswahl beendet. In Abbildung 6-10 ist schematisch die Auswahl zum
Abfragen aller Datenbestände aufgezeigt. Durch zweimalige Eingabe der Auswahlziffern "1"
gelangt man in die Ebene, in der alle Einträge Funktionen auslösen; in der Baumstruktur sind
also terminale Knoten erreicht. Durch die Auswahlziffer "1" werden z.B. alle in der Datenbank
enthaltenen Daten ausgegeben. Die Ausgabe erfolgt, der bisherigen Philosophie folgend, auf
zwei Arten: In eine Ergebnisdatei und auf Kommandozeilenebene. In Abbildung 6-11 ist die
Antwort von IMSPhoBase-MS dargestellt.
Seite 119
(1«RETURN»)
(1«RETURN»)
Abb. 6-10: Auswahlstruktur für "Alle Dateien abfragen"
Beispiel für die Menüfolge, um alle Daten, die in der Datenbank eingetragen sind, abzufragen. Von der obersten
Menüebene (siehe Abbildung 6-9) gelangt man in die Ebene "Datei Abfragen" und von dort zur Auswahl "Alle Dateien".
Abb. 6-11: Ergebnis der Anfrage "Alle Datenbestände ausgeben"
Darstellung der Ergebnismenge einer Datenbankanfrage im Menü. Nach der Auflistung der Ergebnisse, alle vorhandenen Dateien inklusive ihrer Quelle werden ausgegeben, geht das Progamm sofort wieder auf das Anfangsmenü zurück. Es wird parallel zur Ausgabe eine Ausgabedatei produziert, in der das gleiche Ergebnis gespeichert ist.
Ein zweites Beispiel zeigt das Eintragen von Daten. Mit der in Abbildung 6-12 dargestellten Menüfolge gelangt man zu der Auswahlebene, auf der Daten eingetragen werden können.
Seite 120
(3«RETURN»)
(1«RETURN»)
Abb. 6-12: Auswahlstruktur für "Dateien eintragen"
Zum Eintragen von Dateien müssen ebenfalls die zwei ersten Menüebenen durchlaufen werden. Die dritte Ebene
bietet die Möglichkeit des interaktiven Eintragens einzelner Dateien und eine Listen-gesteuerte Möglichkeit des
Eintragens, das allerdings eine bereits existierende Dateiliste voraussetzt.
Wie in Abbildung 6-12 zu erkennen ist, gibt es zwei Möglichkeiten, neue Daten einzufügen. Mit
"Interaktiv" kann jeweils nur ein einzelner Datensatz eingetragen werden. Durch die Auswahl
"Einlesen von Dateien" können im Batch-Betrieb Listen von Dateien eingetragen werden. Die
Textdatei hat ein besonderes Format besteht aber im Wesentlichen aus einer Auflistung von Dateinamen mit Pfadangabe, die automatisch in die Datenbank eingetragen wird und zwar ohne Interaktion mit dem Benutzer.
Die gleiche Funktionalität ist auch im nicht-interaktiven Betriebsmodus enthalten. Der nicht-interaktive Modus ist bereits mehrfach motiviert worden und soll an dieser Stelle an Beispielen
verdeutlicht werden. Der in (1) dargestellte Kommandoaufruf ist vollständig äquivalent mit der
Menüauswahl aus Abbildung 6-10.
(1) dbms_programm -r host -s datenbank
A=1B=1C=1 <Listen-Dateiname> -e
Das IMSPhoBase-MS greift durch die übergebene Folge von Optionen auf die gleiche Funktion
zu, die hinter der Auswahlziffer "1" der dritten Menüebene zu finden ist (siehe Abbildung 6-10).
Seite 121
Die Datei <Listen-Dateiname> ist die Ergebnisdatei, durch "-e" wird die Nicht-Interaktivität
ausgelöst. Der Vorteil dieser Zugriffsweise liegt auf der Hand: Externe Programme können ohne
Interaktion durch einen Benutzer auf die Daten in der Datenbank zugreifen.
In diesem Abschnitt ist das Ausgabeformat des IMSPhoBase-MS schon an mehreren Stellen angesprochen worden. Nicht zuletzt auch auf Grund des zu Grunde liegende Annotationsmodells
besteht die Ergebnismenge einer Datenbankanfrage immer aus einer Menge von Dateien. Das
können z.B. Dateien sein, Phonem- oder Wortsegmentierungen oder ganz allgemein linguistische Beschreibungsebenen. Da die einzelnen Segmente der Dateien nicht in der Datenbank indiziert sind, können auf ihnen keine Analysen gemacht werden. Aber genau das ist das
eigentliche Interesse an an einer Sprachdatenbank. Das im Abschnitt 6.2.5. beschriebene Analysemodul ermöglicht solche Analysen. Das Analysemodul ist im Sinne der allgemeinen Modularität extern realisiert und arbeitet auf der Ergebnismenge einer Datenbankanfrage.
6.2.5.
Das Analysemodul
Das Analysemodul, das in Perl realisiert ist, ist unabhängig von dem Datenbanksystem und somit einfach und ohne Nebenwirkungen modifizierbar. Dargestellt ist das Analysemodul in der
Gesamtarchitektur (siehe Abb. 6-2 oben) als “Programm“, das als externes Programm das IMSPhoBase-MS nutzt.
Durch textbasierte Konfigurationsdateien können beliebige Features (phonetische als auch andere) sowie deren Zuweisung zu den Elementen frei definiert werden. Die Konfigurationsdatei
weist eine gemischte Attribut-Wert-Paar Struktur auf. Im Grunde ist jede komplexe Definition
denkbar, z.B. könnte das gesamte Lautinventar einer Sprache abgebildet werden und durch entsprechende distinktive Merkmale spezifiziert werden. Dies würde dann eine ganz allgemeine
Suche auf distinkiven Merkmalen ermöglichen.
Die Konfigurationdatei kann jederzeit verändert werden, dh. es bedarf dafür keines Eingriffs in
den Programmcode des Analyseprogramms. Das Analysemodul erhält seine Mächtigkeit durch
die Möglichkeit, Einheiten und Features durch logische Operatoren zu verknüpfen, und durch
eine Auswertung in beliebig langen Kontexten, d.h. es ist möglich, jedes Segment mit beliebig
langem Kontext links und/oder rechts auszugeben.
Es findet ein einfaches Parsen der Eingabeparameter beim Aufruf des Analyseprogramms statt.
Seite 122
Beispielsweise erfolgt eine Fehlermeldung, sofern ein Operator in der Parameterliste doppelt
vorkommt. Hinsichtlich der Angabe von Features und Elementen mit der Option [-F] bzw. [-E]
muss der Benutzer dafür sorgen, dass das Setzen von Klammerpaaren richtig erfolgt, falls die
Priorität der Abarbeitung abweichend vom Defaultwert interpretiert werden soll.
Ein Unterschied besteht in der Spezifikation mit der Option [-pro]. Der String, der nach [-pro]
in doppelten Hochkommata eingeschlossen ist, wird nicht geparst, da diese Ausgabe Teil der erwarteten Befehlssyntax des weiterverarbeitenden Programms ist. Alle spezifizierten Platzhalter
in der Kommandozeilenoption [-pro] werden durch entsprechende Werte ersetzt. Durch die alleinige Angabe der Option [-i] wird eine Hilfemeldung angezeigt, in der alle Möglichkeiten gelistet sind.
Die Eingabe des Analysemoduls ist die Ergebnismenge einer Datenbankanfrage. Die Ergebnisdatei beinhaltet das Analysergebnis und orientiert sich in ihrer Gestaltung nach der Kommandozeilenoption [-pro]. Fehlt diese Kommandozeileoption, wird automatisch der festgelegte
Kommandostring ''sgplay -s STARTZEIT -e ENDZEIT FILENAME ELEMENT'' eingesetzt.
6.2.5.1. Die Funktionen des Analysemoduls
Der Aufruf des Analysemoduls erfolgt nach der in (2) dargestellten Syntax:
(2) analyse_programm [-v][-i] [-E Elemente-String]
[-F Feature-String] [-pro Format-String]
[-k Definitionsdatei] [-r Ergebnisdatei]
Inputdatei
Wird das Programm nur mit [-i] aufgerufen, so erscheint eine Hilfe zu den einzelnen Optionen.
Die Angabe von [-v] bewirkt eine um Verarbeitungsinformationen angereicherte Ausgabe. Die
Verwendung der Option [-E ] ermöglicht die Segment-basierte Analyse, die Verwendung von
[-F] die Eigenschaft-basierte Analyse. Bei Eigenschaft-basierter Analyse ist die Verwendung
der Konfigurationsdatei notwendig.
Seite 123
Wird das Ausgabeformat spezifiziert, so sind folgende Werte einsetzbar:
• %S ist Platzhalter für die Startzeit eines Elements
• %E ist Platzhalter für die Endzeit eines Elements
• %N: Startzeit des nachfolgenden Elements
• %-d: Startzeit des vorgehenden Abtastwert im Abstand d (d ist vom typ(int))
• %d oder %+d: Startzeit vom nachfolgenden Abtastwert im Abstand d
• %I: das Sprachelement, nach dem gesucht wird
• -F: Dateiname, in dem das Sprachelement vorkommt
Die Option [-k] bezeichnet die Konfigurationsdatei, mit [-r] kann die Ergebnisdatei explizit benannt werden. Der Defaultwert ist "erg.dat".
6.2.5.2. Konfigurationsdatei
Die Konfigurationsdatei ist erforderlich für die Suche nach Eigenschaften und/oder Elementen
und wird eingeleitet durch Angabe der Kommandozeilenoption [-k]. Diese Datei wird zum Beispiel wie folgt definiert:
\# vo,fr,sth,stl,na
a vo
e vo
i: vo
z fr
f fr,stl
p stl
t stl
n na
es POS-Tag
Ein Kommentar wird gekennzeichnet durch ein vorangestelltes Nummerzeichen "\#". Jede Zeile
beginnt mit einem Phonem wie z.B ''a'', ''c'', ''i:'' usw., gefolgt von den damit verbundenen Eigenschaften. Als Trennzeichen zwischen den Eigenschaften können Tabulator-, Leerzeichen oder
Kommata verwendet werden. Zwischen einem Sprachelement und dessen Eigenschaften ist allerdings nur Leer- oder Tabulator-Zeichen als Trennzeichen zugelassen.
Seite 124
Die Definition jedes Phonems beginnt immer mit einer neuen Zeile in der Definitionsdatei, die
Anzahl der Zeilen ist nach oben nicht begrenzt.
Die Definitionsdatei kann auch benutzt werden, um nach Wörtern zu suchen. In diesem Fall wird
ein Wort als Sprachelement spezifiziert, dessen Eigenschaften ebenfalls entsprechend gekennzeichnet werden. Beispielsweise enthält die obige Konfiguration das Wort ''es'' und dessen Eigenschaft ''POS-Tag'' (POS-Tag steht hier stellvertretend für beliebige Worteigenschaften).
Über die hier dargestellten Möglichkeiten hinaus können beliebige Attribute und Werte definiert
werden.
Im folgenden Abschnitt werden mit Eigenschaft- und Segment-basiert zwei grundlegende Analysemöglichkeiten vorgestellt.
6.2.5.3. Beispiel für Eigenschaft-basierter Analyse
Aufgabenstellung: Auf der Ergbnismenge "temp.txt" einer Datenbankanfrage sollen alle Elemente gefunden werden, die vokalisch oder stimmhaft sind. Die Konfigurationsdatei heisst "defi.dat" und wird durch ’-k’ eingeleitet. Das Ergebnis wird in "erg.dat" geschrieben. Das
Kommando ist in (3) dargestellt.
(3) analyse.pl -v -F "vo|sth" -k defi.dat
-r erg.dat temp.txt
Ein Auszug aus dem Ergebnis ist in (4) dargestellt. Es ist keine spezielle Formatierung des Ausgabeformats erfolgt, die Ausgabe erscheint im Standardausgabeformat, mit dem die Treffer angehört werden können.
(4) sgplay -s 0.310000 -e 0.360000 /usr/local/tmp/ExPhoDB umtausch_Michaela.sd #e
sgplay -s 1.400000 -e 1.430000 /usr/local/tmp/ExPhoDB/umtausch_Michaela.sd #g
sgplay -s 2.120000 -e 2.180000 /usr/local/tmp/ExPhoDB/umtausch_Michaela.sd #a
sgplay -s 3.800000 -e 3.880000 /usr/local/tmp/ExPhoDB/umtausch_Michaela.sd #a
sgplay -s 5.130000 -e 5.180000 /usr/local/tmp/ExPhoDB/umtausch_Michaela.sd #e
sgplay -s 6.450000 -e 6.520000 /usr/local/tmp/ExPhoDB/umtausch_Michaela.sd #e
Seite 125
Das gleiche Ergebnis erhält man, wenn mittels der Option [-pro] das Ausgabeformat wie in (5)
formuliert angegeben wird. Dabei ist zu beachten, dass in diesem Fall auch [%F] für die gefundene Datei angegeben werden muss. Das Ergebnis ist identisch zu (4).
(5) analyse.pl -F "vo|sth" -pro "sgplay -s %S -e %E %F %#I"
-k defi.dat -r erg.dat temp.txt
Die Formulierung eines Kommandos wie in (6) ermöglich es, das gleiche Ergebnis direkt einem
Statistikprogramm oder einem Trainingsprogramm zu zu führen.
(6) analyse.pl -F "vo|sth" -pro "%F
%S %E" -k defi.dat
-r erg.dat temp.txt
Das Ergebnis dieses Kommandos ist in (7) dargestellt. Nunmehr besteht das Ergebnisformat nur
aus Ergebnisdatei, Start- und Endzeitpunkt des gefundenen Segments.
(7) /usr/local/tmp/ExPhoDB/umtausch_Michaela.sd 0.310000 0.360000
/usr/local/tmp/ExPhoDB/umtausch_Michaela.sd 1.400000 1.430000
6.2.5.4. Beispiel für Segment-basierte Analyse
Aufgabenstellung: Auf der Ergebnismenge "temp.txt" einer Datenbankanfrage sollen alle "und"
Elemente gefunden werden. Da direkt auf der Wortsegmentebene analysiert wird, ist keine Kon-
Seite 126
figurationsdatei von Nöten. Das Ergebnis wird in "erg.dat" geschrieben. Das Kommando ist in
(8) dargestellt.
(8) analyse.pl -E "und" -r temp.txt erg.dat
Das Ergebnis ist in (9) dargestellt, das Ausgabeformat ist wiederum das Standardformat.
(9) sgplay -s 0.170000 -e 0.280000 /usr/local/tmp/ExPhoDB/umtausch_Michaela.sd #und
sgplay -s 7.150000 -e 7.260000 /usr/local/tmp/ExPhoDB/umtausch_Michaela.sd #und
sgplay -s 1.500000 -e 1.680000 /usr/local/tmp/ExPhoDB/wut_Judith.sd #und
sgplay -s 1.330000 -e 1.470000 /usr/local/tmp/ExPhoDB/wut_Michaela.sd #und
Die Beispiele aus 6.2.5.3. und 6.2.5.4. können auch so zusammengefasst werden, dass eine kombinierte Analyseanfrage formuliert werden kann.
6.3.
Zusammenfassung
In diesem Kapitel wurde ein neuartiger Ansatz zur Verwaltung und Abfrage von Sprachsignalkorpora vorgeschlagen. Die Architektur und das zu Grunde liegende Annotationsmodell orientieren sich zum Einen an den gängigen Annotationsmodellen aus der Literatur und zum Anderen
an den spezifischen Eigenschaften der zu modellierenden Datenstrukturen und -topologien. Die
Neuheit an dem Sprachdatenbanksystem liegt in der Verbindung zwischen konventioneller Datenbank und automatischem Segmentiersystem. Durch diese Verbindung ist es möglich, jederzeit fehlende Segmentierungen zu Sprachsignalen, die in der Datenbank vorhanden sind, zu
erzeugen. Nach erfolgreichem Abschluss von Segmentierungen werden erzeugte Daten wieder
in das Datenbanksystem eingetragen, so dass auch auf diesen Daten anschließend recherchiert
werden kann. Ein zum System gehörendes Analysemodul ermöglicht detaillierte Analysen auf
den Ergebnismengen der Datenbankabfragen. So kann man beispielsweise Segmente bezüglich
ihrer Länge oder vorher definierter Eigenschaften analysieren. Weitergehende Analysemöglichkeiten wie etwa die folgende, in (10) in Pseudocode dargestellte, kombinierte Abfrage über mehrere Segmentierungsebenen sind in der prototypischen Realisierung des Systems nur
konzeptionell möglich, bzw. nur mit einigem manuellem Aufwand realisierbar.
Seite 127
(10)
Ermittle die Anzahl und Dauer aller betonter
Vokale "a", die in Nomen vorkommen
Lösung: Bildung einer Schnittmenge aus den Segmentierebenen sprachsignal.tags,
sprachsignal.silben, Sprachsignal.töne und sprachsignal.phoneme. Das Ergebnis
der Schnittmenge ist eine Menge von Silben, die Untereinheiten von Nomen sind,
die wiederum betont sind und den Vokal "a" beinhalten. Ausgabe alle Vokale "a"
und deren Dauer sowie die Häufigkeit.
Solche komplexen Analysemöglichkeiten sind mit dem Analysemodul derzeit nur verankert,
nicht jedoch realisiert.
Das Ausgabeformat des Analysemodels ist frei wählbar und somit an die Eingabesyntax eines
jeden externen Programms adaptierbar. Die beiden getrennten Module, die Datenbank wie das
Analysmodul, können sowohl über eine Kommandozeile eingesetzt werden als auch menügesteuert. Die Funktionalität der Kommandozeilen-orientierten Benutzung ist vorallem in Hinblick auf die Weitergabe von Daten und Ergebnissen an weiterverarbeitende Programme
wichtig.
In Kapitel 2, Abschnitt 2.2.1., wurden die Anforderungen an ein allgemeines Annotationsschema beschrieben. Das hier vorgestellte Sprachdatenbanksystem erfüllt diese Forderungen hinreichend gut: Die Repräsentation von Teilinformation ist durch die gewählte Struktur des
Annotationsmodells bedingt möglich, eine Verbindung von Sprachsignal und entsprechender
Annotation bzw. Segmentierung durch eine explizite Zeitachse ist gewährleistet. Eine Kodierung von hierarchischen Strukturen ist dagegen auf Grund des einfachen Annotationsmodells
nicht möglich. Die Segmente werden als Instanzen annotiert, es können dabei bedingt Lücken
entstehen; Überlappungen sind nicht möglich.
Während die Anforderungen nach Darstellung von Lücken und Überlappung, also allgemein
ausgedrückt, von Teilinformationen durch eine Konvertierung der Annotationsstruktur in eine
XML-Repräsentation erfüllbar wäre, ist die Kodierung von hierarchischen Strukturen nicht so
einfach möglich.
Seite 128
KAPITEL 7
Zusammenfassung und Ausblick
Die Bereitstellung von Sprachsignalaufnahmen sowie der entsprechenden Segmentierungen und
Annotierungen erlaubt einen maschinellen Zugriff auf diese Daten. Durch die damit einsetzbaren maschinellen Verarbeitungsmethoden wird es für Sprachwissenschaftler und Sprachtechnologen erst möglich, große Mengen von Sprachdaten zu bearbeiten.
Mussten Phonetiker und Phonologen noch vor einigen Jahren Belege aus einer textbasierten Recherche mühsam durch sequentielles Suchen in Tonbändern oder auf digitalen Beständen suchen, so ist es heute möglich, große Korpora gesprochener Sprache nach bestimmten Segmenten
und Sprachsignalstellen systematisch zu durchsuchen.
Für die modernen Disziplinen der Sprachtechnologie ist es zwingend notwendig, Zugriff auf
große Sprachdatensammlungen zu haben, die aus verschieden feinen Segmentiereinheiten aufgebaut sind. So benötigen etwa Spracherkennungssysteme Segmentierungen auf Phonemebene,
um entprechende Modelle trainieren zu können, und Sprachsynthesesysteme benötigen z.B.
Segmentierungen in Zweiereinheiten (Diphone) zur Konkatenation im Generierungsprozess.
Der Aufbau solcher großen, oft mehrere Gigabyte umfassenden Sprachdatensammlungen sind
nur maschinell möglich. Für die Segmentierung in Einheiten, wie Phoneme, Silben, Wörter und
syntaktische Einheiten, die die Grundlage solcher Datensammlungen sind, benötigt man manuell fast die hundertfache Zeit der Dauer des Sprachsignals.
In dieser Arbeit sind beide Problemfelder diskutiert und Lösungen vorgeschlagen worden. In
Kapitel 3 sind Systeme vorgestellt worden, mit denen Sprachsignale automatisch segmentiert
werden können. In Kapitel 5 ist ein solches Segmentiersystem, das Stuttgarter Segmentier-
Seite 129
system Alphones durch Experimente so verbessert worden, dass auch für Spontansprache
typische Signalabschnitte sowie spezifische signalinhärente Phänomene adäquat verarbeitet
werden können.
In Kapitel 6 wurde eine Sprachdatenbank entworfen und diskutiert. Diese Sprachdatenbank,
IMSPhoBase, erlaubt zum Einen die Verwaltung und Abfrage von Sprachsignalen auf Basis der
entsprechenden Segmentierungen sowie weitreichende Anaylsen, zum Anderen ist das System
mit der Funktionalität, im Hintergrund neue Segmentierungen zu erzeugen, ausgestattet. Die
Funktionalität wird ermöglicht durch das Einbinden des in Kapitel 5 optimierten Systems
Alphones. Das System IMSPhoBase verfügt über Schnittstellen, um Abfragen und Analysen für
menschliche Benutzer zu ermöglichen, und über Schnittstellen, über die externe Programme wie
z.B. Spracherkenner oder Statistikprogramme direkt auf die Daten zugreifen können.
Mit solchen spezifischen Sprachdatenbanksystemen werden Forschungsarbeiten zu gesprochener Sprache in großem Umfang möglich.
Da das Sprachdatenbanksystem im Rahmen dieser Arbeit nur prototypsich realisiert werden
konnte, bleiben noch einige Möglichkeiten für weitere Entwicklungen offen. Dazu gehören aus
informations-technischer Sicht die Implementierung einer verbesserter Benutzerschnittstelle,
mit der es möglich ist, das System sowohl im Intranet als auch im Internet Browser-basiert zu
benutzen. In Abbildung 7.1 ist eine solche Struktur schematisch dargestellt.
Unter der Zwischenebene, "Verteilten Anwendungsdiensten", werden verschiedenste Methoden
und Protokolle subsumiert. Durch eine geeignete Implementierung dieser Zwischenebene kann
die Benutzerseite unabhängig von deren spezifischen Unterschieden und ohne Kenntnis der
Strukturen der physikalischen Datenbank realisiert werden. Die unterschiedlichen Computertypen in Abbildung 7.1 repräsentieren die plattformunabhängige Anwendung. Durch die Wahl einer HTTP-basierten Zwischenebene lassen sich die zwei Zugriffvarianten Intra- und Internet
realisieren. Das Intranet-Zugriffsszenario wäre ein Zugriff innerhalb der gleichen Domäne, während das Internet-Zugriffsszenario Zugriffe von außerhalb der Domäne zuläßt. Auf Grund von
Sicherheitsaspekten und lizenzrechtlicher Bestimmungen gekaufter Sprachkorpora ist beim
zweiten Szenario eine Zugriffsbeschränkung unerläßlich.
Seite 130
Abb. 7.1: Drei-Schichten-Architektur verteilter Datenbanksysteme
Die Architektur (aus [4.1]) zeigt die verteilte Anwendung von Datenbanksystemen. Durch eine geeignete Wahl der
"Verteilten Anwendungsdienste" ist die Verwendung im Intranet (hier: als verschiedene Computerplattformen dargestellt) und Internet möglich.
Die Wahl von HTTP-basierten "Verteilten Anwendungsdiensten" bietet sich im Fall der Sprachdatenbank IMSPhoBase nicht nur wegen der dadurch möglichen www-basierten Zugriffsmöglichkeit an, sondern auch auf Grund der gewählten Architektur des Systems. Die Wahl der
Datenbank-Engine, die sowohl über Java-, Perl- und PHP-Schnittstellen verfügt, sowie die Implementierung des Analysemoduls in Perl ermöglicht die Realisierung einer einfachen, aber effizienten Kommunikation zwischen einer www-basierte Schnittstelle und den Modulen des
Datenbanksystems. Eine solche www-basierte Schnittstelle könnte beispielsweise ein HTMLbasiertes Formular sein, dass folgende Anforderungen erfüllen muss:
• Eingabefelder zur Korpusauswahl. Es sollte möglich sein, sogenannte
"logische" Korpora für bestimmte Anwendungen zusammenzustellen. Die
Zusammenstellung sollte nach unterschiedlichsten Merkmalen möglich
sein.
• Eingabefelder für die Abfrage. Entsprechend der Möglichkeiten, die das
Analysemodul bietet, sollten Textfelder in denen Abfragen formuliert werden können vorhanden sein.
Seite 131
• Format und Medium der Ausgabe. Die möglichen Ausgabeformate müssen unterstützt werden. Es muss eine Möglichkeit der beliebigen Formatierung einer Ergebnisdatei durch einen String vorhanden sein. Die
Darstellung des Ergebnisses sollte frei wählbar sein.
• Auswahl Soundformat. Zur Unterstützung der Plattformunabhängigkeit
sollte das Soundformat für eine audio-basierte Kontrolle frei wählbar sein.
In Abbildung 7.2 ist eine prototypische Realisierung eines Eingabeformulars unter Berücksichtigung der oben genannten Punkte gezeigt.
Abb. 7.2: Prototypische Darstellung eines Eingabeformulars zur Korporarecherche
Das HTML-basierte Formular erlaubt eine Zusammenstellung von Korpora, die Formulierung von Segment- und
Eigenschaft-basierten Anfragen sowie die Darstellung und Formatierung des Ergebnisses der Anfrage.
Seite 132
Das in Abbildung 7.2 dargestellte Formular ist im Wesentlichen in drei Teile gegliedert: Korpuszusammenstellung, Suchanfragenformulierung und Formatierung der Ergebnisdarstellung.
Für die Korporazusammenstellung sind zwei Eingabemenüs vorgesehen. Das Menü "Auswahl
nach Korpora" unterstützt die Auswahl eines Korpus (siehe "Liste der verfügbaren Korpora" im
oberen Teil des Formulars) oder aller Korpora. Das Menü "Auswahl nach Korpora-Merkmalen"
unterstützt die Zusammenfassung von Korpora nach bestimmten Merkmalen. Die Formulierung
der Suchanfragen ist über zwei Textfelder (Segment- und Eigenschaft-basiert) realisiert. Zur
Unterstützung bei der Formulierung der Anfragen gibt es zwei Menüs, die Auskunft über die benutzbaren Elemente geben. Für die Ergebnisdarstellung gibt es drei Möglichkeiten, eine
Anzeige innerhalb des Browsers oder eine Ausgabe in eine Datei, oder beides. Für die Anzeige
im Browser ist die Möglichkeit vorgesehen, die Ergebnisse der Anfrage direkt anhören zu können. Um die Plattfromunabhängigkeit zu erhalten, ist im Eingabeformular die Auswahl von verschiedenen Soundformaten möglich. Durch das Textfeld "Ausgabeformat der Ergebnisdatei"
kann das Format, in dem sich die Ergebnisdatei befindet, völlig frei bestimmt werden.
Einer der Vorteile einer solchen Benutzerschnittstelle gegenüber der bereits implementierten
Kommandozeilen-orientierten Menüsteuerung liegt zum Einen in einer breiten, plattformunabhängigen Anwendungsmöglichkeit und zum Anderen in mehr Benutzerfreundlichkeit und Komfort und damit letztlich in einer größeren Akzeptanz durch die Benutzer.
Weitere Entwicklungen im Bereich der eingesetzten Konvertierungsprozeduren, wie etwa die
Einbindung von Programmen zur Erzeugung von Grundfrequenz und Spektrogramm sowie Systeme zur Erkennung von Akzent- und Merkmalsstrukturen (die sich freilich noch im Laborstatus befinden), würden die Sprachdatenbank IMSPhoBase noch mächtiger machen.
Seite 133
Literaturverzeichnis
7.1.
[1.1]
Quellenangaben Kapitel 1
Rapp S. Automatisierte Erstellung von Korpora für die Prosodieforschnung. Dissertation, Universität Stuttgart 1998. In: Phonetik AIMS, Arbeitspapiere des Instituts für Maschinelle Sprachverarbeitung, Lehrstuhl für Experimentelle Phonetik, Vol. 4, No. 2.
[1.2]
Bußmann H. Lexikon der Sprachwissenschaft. 2. Stuttgart, Körner, 1990.
[1.3]
Bodmer F., Fach M., Schmidt R., Schütte W. Von der Tonbandaufnahme zur integrierten
Ton-Text-Datenbank. Instrumente für die Arbeit mit Gesprächskorpora. In: Tagungsband
der 1. Freiburger Arbeitstagung zur romanistischen Korpuslinguistik, Reihe ScriptOralia, Gunter Narr Verlag, Erscheinungsdatum Frühjahr 2001.
[1.4]
Haag A. Keywordspotting. Studienarbeit, Instituts für Maschinelle Sprachverarbeitung,
Lehrstuhl für Experimentelle Phonetik, Universtität Stuttgart 2000. WEBADRESSE
fehlt noch.
[1.5]
Cassidy S. Compiling Multi-Tiered Speech Databases Into the Relational Model: Experiments with the Emu System. In: Tagungsband der 6th European Conference on Speech
Communication and Technology (Eurospeech), Budapest 1999, Vol. 5, pp. 2239-2242.
7.2.
[2.1]
Grewendorf G., Hamm F., Sternefeld W. Sprachliches Wisssen. Suhrkamp Taschenbuch,
Wissenschaft 659, 4. Auflage. Frankfurt am Main, 1990. Seite 111-113.
[2.2]
Bird S, Liberman M. A Formal Framework for Linguistic Annotation. Technical Report
MS-CIS-99-01, [http://xxx.lanl.gov/abs/cs.CL/9903003], Department of Computer and Information Science, University of Pennsylvania, Linguistic Data Consortium.
Seite 134
[2.3]
Bird S, Liberman M. A Formal Framework for Linguistic Annotation. In: Speech Communication, Special Issue on Speech Annotation and Corpus Tools, Vol. 33, Erscheinungsdatum Januar 2001.
[2.4]
Bird S., Liberman M. Annotation Graphs as a Framework for Multidimensional Linguistic Data Analysis. Proceedings of the Workshop "Towards Standards and Tools for Discourse Tagging", ACL 1999 , S. 1-10. Association for Computational Linguistics.
[2.5]
Bird S., Liberman M. Towards a Formal Framework for Linguistic Annotations. Proceedings of International Conference on Spoken Language Processing ICSLP, Sydney 1998,
Volume 7, S. 3179.
[2.6]
Schiel F. The Bavarian Archive for Speech Signals 1995-1997. In: Forschungsberichte
des Instituts für Phonetik und Sprachliche Kommunikation der Universität München,
Band 35, S. 121-125, 1997.
[2.7]
Schiel F., Burger S., Geumann A., Weilhammer K. The Partitur format at BAS. In Proceedings of the First International Conference on Language Resources and Evaluation,
Granada 1998. [www.phonetik.uni-muenchen.de/BAS/BASFormatseng.hmtl].
[2.8]
MacWhinney B. The CHILDES Project: Tools for Analyzing Talk. Mahwah, NJ: Lawrence Erlbaum 1995. [poppy.psy.cmuedu/childes/].
[2.9]
LDC broadcast News, [www.ldc.upenn.edu/Catalog/LDC98T287.html].
[2.10] NIST. A universal transcription format (UTF) annotation specification for evaluation of
spoken language technology corpora. National Insitute of Standards and Technology,
NIST, 1998. [http://www.nist.gov/speech/tests/bnr/hub4_98/hub4_98.htm].
[2.11] Taylor P., Black A., Caley R. The architecture of the Festival speech synthesis system. In:
Third International Workshop on Speech Synthesis, Sydney, Australia November 1998.
[2.12] Taylor P., Black A., Caley R. Heterogeneous relation graphs as a mechanism for representing linguistic information. In: Speech Communication, Special Issue on Speech Annotation and Corpus Tools, Vol. 33, Erscheinungsdatum Januar 2001.
[2.13] McKelvie D., Isard A., Mengel A., Møller M., Grosse M., Klein M. The MATE Workbench - an annotation tool for XML coded speech corpora. In: Speech Communication,
Special Issue on Speech Annotation and Corpus Tools, Vol. 33, Erscheinungsdatum Januar 2001.
Seite 135
[2.14] Isard A., McKelvie D., Mengel A., Møller M., Grosse M., Olsen M. Data Structures and
APIs for the MATE Workbench. Deliverable D3.2. LE Telematics Project LE4-8370. [http://mate.mip.ou.dk].
[2.15] Mengel A., Dybkjær L., Garrido J. Heid U., Klein M., et. al. MATE Dialogue Annotation
Guidelines. Deliverable D2.1. LE Telematics Project LE4-8370.
[2.16] Cassidy S., Harrington J. An enhanced hierarchical speech data management system. In
Proceedings of the Sixth Australian International Conference on Speech Science and
Technology Adelaide 1996.
[2.17] Cassidy S., Harrington J. Multi-level annotation of Speech: An Overview of the Emu
Speech Databse Management System. In: Speech Communication, Special Issue on
Speech Annotation and Corpus Tools, Vol. 33, Erscheinungsdatum Januar 2001.
[2.18] Harrington J., Cassidy S., Fletcher J., McVeigh A. The Mu+ speech database system.
Computer Speech and Language, International Journal, 7:305-31, 1993.
[2.19] v. Mangoldt, Knopp. Einführung in die höhere Mathematik, vierter Band. von Dr. Friedrich Lösch, 3., durchgesehene Auflage. S. Hirzel Verlag Leipzig 1979.
[2.20] Cassidy S., Bird S. Querying Databases of Annotated Speech. Proceedings of the Eleventh Australasian Database Conference, S. 12-20. ADC 2000, IEEE Computer Society,
Canberra 2000.
[2.21] Bird S., Buneman P., Tan W-C. Towards A Query Language for Annotation Graphs. Proceedings of the International Resources and Evaluation Conference, LREC 2000,
Athens, S. 807-814.
[2.22] Bird S., Day D., Garofolo J., Henderson J., Laprun C., Liberman M. ATLAS: A Flexible
and Extensible Architecture for Linguistic Annotation. In: Second International Resources and Evaluation Conference, LREC 2000, Athens, S. 1699-1706.
Seite 136
7.3.
[3.1]
Greenberg S. et al. Automatic Phonetic Transcription of Spontaneous Speech (American
English). Proceedings of the International Conference on Spoken Language Processing,
Beijing 2000.
[3.2]
Schmidt R. Architektur und Funktionalität der Diskursdatenverarbeitung DIDA. In:
LDV-INFO 8. Informationsschrift der Arbeitstelle Linguistische Datenverarbeitung.
Hrsg. vom Institut für Deutsche Sprache, S. 142-155, Mannheim 1996
[3.3]
Schmidt R., Neumann R. The Digital Discourse Processing System DIDA. In: Proceedings of the 2nd SQL Workshop on Multi-Lingua Information Retrieval Dialogues, S.
145-148. Pilzen 1997.
[3.4]
Englert F. Automatische Segmentation von Sprachsignalen. In: Forum Phoneticum Nr.
61, Hector, Frankfurt am Main 1995.
[3.5]
Rapp S. Automatisierte Erstellung von Korpora für die Prosodieforschnung. Dissertation
1998,Universität Stuttgart. Erschienen in: phonetikAIMS, Arbeitspapiere des Instituts
für Maschinelle Sprachverarbeitung, Lehrstuhl für Experiementelle Phonetik, Universität Stuttgart Vol. 4, No.1, 1998.
[3.6]
Maenobu K., Arikiri Y., Sakai T. Speaker-independent word recognition in connected
speech on the basis of phoneme recognition. In: Information Sciences No. 33, S. 31-61,
1984.
[3.7]
Hosom J.P. Automatic time Alignment of Phonemes Using Acoustic-Phonetic Information. PhD. Thesis, Oregon Graduate Institute of Science and Technology, 2000. [http://
www.cse.ogi.edu/~hosom]
[3.8]
Stöber K., Sprecherunabhängige automatische Lautsegmentierung unter Verwendung
synthetischer Sprache: Einfluss psychoakustisch motivierter Vorverarbeitung und des
Skalierungsfaktors von DTW, erscheint in: Fellbaum, K. (Hrsg.). Tagungsband Elektronische Sprachsignalverarbeitung ESSV 2000, Studientexte zur Sprachkommunikation,
Cottbus 2000.
Seite 137
[3.9]
Rapp S. Automatic phonetic transcription and linguistic annotation from know test with
Hidden Markov Models / An aligner for German. In: Integration of Language and Speech
in Academia and Industry. ELSNET goes east and IMACS. Moscow 1995. [http://
www.ims.uni-stuttgart.de/˚rapp/aligner.ps.gz]
[3.10] Schmidt H. Improvements in part-of-speech tagging with an application toGerman. In:
Proceedings of EACL SIGDAT Workshop. Dublin 1995, S. 47-50. [http://www.ims.unistuttgart./pub/corpora/treetagger2.ps.gz]
[3.11] Kohler K.J. The Kiel Corpus of Read Speech (CD-ROM). Institut für Phonetik und digitale Sprachverarbeitung. Christian-Albrechts-Universität zu Kiel 1995
[3.12] Baayen R.H., Piepenbrock R., van Rijn H. The CELEX Lexical Databse (CD-ROM). Linguistic Data Consortium, University of Pennsylvania, Philadelphia, PA, 1995.
[3.13] Kipp A., Wesenick M. Das Münchner Automatische Segmentationssystem (MAUS).
Verbmobil Memo Nr. 95. Institut für Phonetik und Sprachliche Kommunikation, Ludwig-Maximilians-Universität München, 1995.
[3.14] Schiel F., Kipp A. Probabilistic Analysis of Pronounciation with MAUS. In: The Word as
a Phonetic Unit, Berlin 1997.
[3.15] Eisen B., Tillmann H.G., Draxler C. Consistency of Judgement in Manual Labelling of
Phonetic Segments: the Distinction between Clear and Unclear Cases. In: Proceedings
of ICSLP 1993, Banff, Canada, S. 871-874.
7.4.
[4.1]
Yarger R., Reese G., King T. MySql&mSQL. O’Reilly Koeln, 2000.
[4.2]
Vossen G. Datenmodell, Datenbanksprachen und Datenbank-Management-Systeme.
Addison-Wesley Bonn 1994. 2. Auflage.
[4.3]
Kirsch K. RDMMS. MySQL.: Freie Datenbank. In: iX, Magazin fuer professionelle Informationstechnik, Juni 2000, Seite 52.
Seite 138
7.5.
[5.1]
Fiehler R., Schütte W. Instrumente für die Arbeit mit Korpora besprochener Sprache:
Ton-Text-Alignment und COSMAS II. 2. Symposion AUTORENERKENNUNG des
BKA vom 03.-05.04.2000. Tagungsband Hrsg. von Christa J. Baldauf, Wiesbaden 2000,
S. 1-18. ISSN 1615-4878.
[5.2]
Klein W., Schütte W. Transkriptionsrichtlinien für die Eingabe in DIDA. Stand Februar
1999. Institut für Deutsche Sprache, Mannheim. [http://www.ids-mannheim.de/prag/dida/
dida-trl.pdf]
[5.3]
Bodmer F. Aspekte der Abfragekomponente von COSMAS II. In: LDV-INFO 8. Informationsschrift der Arbeitstelle Linguistische Datenverarbeitung. Hrsg. vom Institut für
Deutsche Sprache, S. 142-155. Mannheim 1996
[5.4]
Bodmer F., Fach M., Schmidt R., Schütte W. Von der Tonbandaufnahme zur integrierten
Ton-Text-Datenbank - Instrumente für die Arbeit mit Gesprächskorpora. In: Tagungsband der 1. Freiburger Arbeitstagung zur Romanistischen Korpuslinguistik, Freiburg
2000. Erscheint im Frühjahr 2001 in der Reihe ScriptOralia im Verlag Gunter Narr, Tübingen.
[5.5]
Ehrlich K. Interjektionen. Linguistische Arbeiten 111, Max Niemeyer Verlag, Tübingen
1986.
[5.6]
Fach M. Trigger für die Automatische Spracherkennung. In: International Journal for
Language Data Processing (Sprache und Datenverarbeitung), SDv Vol. 24.1/2000, S. 3551.
[5.7]
Fach M. Alignmentprojekt IMS/IDS. Projektberichte. [http://www.ims.uni-stuttgart.de/phonetik/projekte/IDS/index.html] und [http://www.ims.uni-stuttgart.de/phonetik/projekte/IDS/activities.html]
[5.8]
Rabiner L. A Tutorial on Hidden Markov Models ans Selected Applications in Speech
Recognition. Proceedings of the IEEE, Vol. 77, No. 2, S. 257285, 1989.
Seite 139
[5.9]
Young S., Jansen J., Odell J., Ollason D., Woodland P. The HTK Book Version2. Entropic
Research Laboratory, Inc. 600 Pennsylvania Avenue, SE, Suite 202, Washington, DC
20003.
[5.10] Fach M. Pitch Accent Classification of Fundamental Frequency Contours by Hidden
Markov Models. Proceedings of the Eurospeech '95, Vol.3, S.2047-2050, Madrid 1995.
7.6.
[6.1]
Fach M., Wokurek W. Abfrage- und Wartungswerkzeuge heterogen annotierter Sprachsignal Korpora. In Tagungsband: KONVENS2000-Sprachkommunikation, ITG-Fachbericht 161: Seite 203-208, VDE Verlag Berlin, Offenbach.
[6.2]
SQL. [http://www.hughes.com.au]
[6.3]
Kirsch K. RDMMS. MySQL.: Freie Datenbank. In: iX, Magazin fuer professionelle Informationstechnik, Juni 2000, Seite 52.
[6.4]
Quang Phan. Konzeption und Implementierung einer Datenbank für Sprachsignalkorpo
ra. Diplomarbeit, IMS, Universität Stuttgart, 1998.
[6.5]
Kline K., Kline D. SQL in a Nutshell. O’Reilly Verlag GmbH&Co, 2000.
Seite 140
Anhang
A.1
Vollständiges Verzeichnis der Tabellen der Datenbank
Abb. A.1: Übersicht über die aktuellen Tabellen des Datenbanksystems
Die Abbildung zeigt einen Bildschirmabzug aller im Datenbanksystem verfügbaren Tabellen.
Die in Abbildung A.1 enthaltenen Tabellen werden im Folgenden einzeln aufgelistet. Alle Darstellungen der Tabellen sind Bildschirmabzüge, von Ausgaben, die mit einem Kommando des
mSQL-admintools generiert wurden.
Seite 141
Abb. A.2: Die Tabelle FILE
Die Tabelle FILE ist die zentrale Tabelle im Sprachdatenbanksystem. In ihr werden alle Information über Sprachsignale gespeichert.
Abb. A.3: Die Tabelle FILE_ID
Organisatorische Tabelle, die für jede Neuanlage einer "FILE"-Tabelle eine eindeutige ID berechnet
Abb. A.4: Die Tabelle FILE_PHONES
Temporäre Kontrolltabelle, die beim Erzeugen von Phonemsegmentierungen generiert wird.
Seite 142
Abb. A.5: Die Tabelle FILE_WORDS
Temporäre Kontrolltabelle, die beim Erzeugen von Wortsegmentierungen generiert wird.
Abb. A.6: Die Tabelle FILE_SPH
Temporäre Kontrolltabelle, die beim Erzeugen von Wort- und Phoemensegmentierungen generiert wird.
Abb. A.7: Die Tabelle FORMAT
Tabelle für zusätzliche Informationen Entitäten des Datenbanksystems. Im Falle von Sprachsignalen ist der Wert
des Attributes z.B. "sd", im Falle von Wortsegmentierung dagegen "words".
Seite 143
Abb. A.8: Die Tabelle FORMAT_ID
Organisatorische Tabelle, die für jede Neuanlage einer "Format"-Tabelle eine eindeutige ID berechnet.
Abb. A.9: Die Tabelle FILE_FO_ZUORDNUNG
Abbildungstabelle, die die Verbindung zwischen der Tabelle FILE und FORMAT darstellt.
Abb. A.10: Die Tabelle QUELLE
Tabelle für erweiterte Informationen zu Quelleneinträgen zu Sprachsignalen.
Abb. A.11: Die Tabelle QUELLE_ID
Organisatorische Tabelle, die für jede Neuanlage einer "Quelle"-Tabelle eine eindeutige ID berechnet.
Seite 144
Abb. A.12: Die Tabelle FILE_QU_ZUORDNUNG
Abbildungstabelle, die die Verbindung zwischen der Tabelle FILE und QUELLE darstellt.
Abb. A.13: Die Tabelle HAUPTTYP
Tabelle für erweiterte Informationen zu Sprachsignalen. Ein Haupttyp wäre etwa Sprachsignal oder Labeldatei.
Abb. A.14: Die Tabelle HAUPTTYP_ID
Organisatorische Tabelle, die für jede Neuanlage einer "HAUPTTYP"-Tabelle eine eindeutige ID berechnet.
Abb. A.15: Die Tabelle FILE_HT_ZUORDNUNG
Abbildungstabelle, die die Verbindung zwischen der Tabelle FILE und HAUPTTYP darstellt.
Seite 145
Abb. A.16: Die Tabelle UNTERTYP
Tabelle für erweiterte Informationen zu Sprachsignalen. Ein Untertyp wäre etwa "esps-sd" für den Haupttyp
"Sprachsignal" oder "xlabel" für den Haupttyp "Labeldatei".
Abb. A.17: Die Tabelle UNTERTYP_ID
Organisatorische Tabelle, die für jede Neuanlage einer "UNTERTYP"-Tabelle eine eindeutige ID berechnet.
Abb. A.18: Die Tabelle FILE_UT_ZUORDNUNG
Abbildungstabelle, die die Verbindung zwischen der Tabelle FILE und UNTERTYP darstellt.
Abb. A.19: Die Tabelle PROZEDUR
Tabelle für die verfügbaren Konvertierungsroutinen im Sprachdatenbanksystem.
Seite 146
Abb. A.20: Die Tabelle PROZEDUR_ID
Organisatorische Tabelle, die für jede Neuanlage einer "PROZEDUR"-Tabelle eine eindeutige ID berechnet.
Abb. A.21: Die Tabelle FILEEXT_PROZEDUR_ZU
Abbildungstabelle, die die Verbindung zwischen der Tabelle FILE und PROZEDUR darstellt. Die Konvertierung
erfolgt über die Extentionen aller Daten ohne Interaktion des Benutzers.
Abb. A.22: Die Tabelle FILE_PRO_ZUORDNUNG
Abbildungstabelle, die die Verbindung zwischen der Tabelle FILE und UNTERTYP darstellt. Die Konvertierung
erfolgt durch explizitesAufrufen einer Konvertierungsroutine.
Seite 147
A.2
Die Menüebenen des Datenbank-Management-Systems IMSPhoBase-MS
Abb. A.23: Baumstrukur der Menüebenen des DBMS
Darstellung aller Menüebenen der baumartig organisierten Benutzerschnittstelle des Sprachdatenbanksystems
IMSPhoBase. Alle Menüebenen verzeigen bis zu einer bestimmten Tiefe. Ein Menü, dass keine Nachfolger mehr
hat, hat als Einträge nur ausführende Programme und Aktionen.
Seite 148
A.3
Auschnitt einer SGML-Annotationsdatei
<!DOCTYPE tei.2 system 'tei2.dtd' [
<!ENTITY % TEI.spoken 'INCLUDE'>
<!ENTITY % TEI.fs 'INCLUDE'>
<!ENTITY % TEI.analysis 'INCLUDE'>
<!ENTITY % TEI.linking 'INCLUDE'>
<!ENTITY % TEI.corpus 'INCLUDE'>
<!ENTITY % ISOlat1 system 'ISOlat1c.ent'>
<!ENTITY % ISOlat2 system 'ISOlat2c.ent'>
<!ENTITY % ISOnum system 'ISOnumc.ent'>
<!ENTITY % TEI.extensions.ent system 'trans-x.ent' >
<!ENTITY % TEI.extensions.dtd system 'trans-x.dtd' >
%ISOlat1
%ISOlat2
%ISOnum





]>
<tei.2>
<teiHeader>
<fileDesc>
<titleStmt>
<title>
Transcript 3005.21,haarteil
</title>
<publicationStmt>

CopyRight by:
Institut für deutsche Sprache
Anschrift:
R5,6 - 13
D-68161 Mannheim (Germany)</>
</publicationStmt>
<sourceDesc>
 DIDA Transcript 
This transcript was automaticaly converted by the Converter DID2SGML Version 0.3.3 (incomplete) 19.09.97.
Transcript Global Information (when exported from DIDA):
- Modus = Sicherung mit Beendigung des Arbeitsschrittes
- Status = wird korrigiert
- Nb KZ = 2 (Kopfzeilen)

</sourceDesc>
</fileDesc>
<profileDesc>
<langUsage><language id=eng usage='100'></langUsage>
<particDesc>
<person id='AA'></person>
<person id='BB'></person>
<person id='CC'></person>
<person id='XM'></person>
<person id='XW'></person>
</particDesc>
</profileDesc>
</teiHeader>
<text>
<body>
<w lemma='firma' n=6803-1-8207>firma</w> <w lemma='meister' n=6804-1-8208>meister</w> <w lemma='plack' n=6805-1-8209>plack</w> <w lemma='inhaber' n=6806-1-8210>inhaber</w> <w lemma='günther' n=6807-18211>günther</w> <w lemma='plack' n=6808-1-8212>plack</w> <pause dur='0,5'><w lemma='und' n=6809-1-8213>und</
w> <w lemma='da' n=6810-1-8214>da</w> <w lemma='erscheint' n=6811-1-8215>erscheint</w> <w lemma='herr' n=68121-8216>herr</w> <w lemma='friseurmeister' n=6813-1-8217>friseurmeister</w> <w lemma='günther' n=6814-1-8218>günther</w> <w lemma='plack' n=6815-1-8219>plack</w> <unclear><w lemma='...' n=6816-1-8220>...</w> </unclear>
h BB
l
' h' 3945 1 4642 h /
l
'j
ll' 3946 1 4643 j
ll /
d '9' /
Abb. A.24: Fragment einer SGML-basierten Annotationsdatei des IDS
Das Fragment zeigt die Struktur der Annotationen, die in COSMAS II eingesetzt werden. Im oberen Teil befinden
sich sämtliche Annotationen der relevanten Metadaten, ab <body> beginnt das SGML-basierte Transkript.
Seite 149
A.4
Übersicht über die verfügbaren Korpora
• IDS-Korpus: Schlichtungsgespäche, Diskussionsrunden, "Manheimer
Dialekt", Aufnahmen mit "Pommerschen" Dialekt, "Badischen"-Dialekt
und "Oberschwäbischer"-Dialekt. Alle Sprachdaten sind zum größten Teil
automatisch wortsegmentiert, kleine Teile sind manuell korregiert. Größe:
etwa 1,1 GB.
• Studentenkorpus: Aufnahmen von 18 Seminarteilnehmern im schalltoten
Raum, männlich, weiblich, pro Sprecher 19 Texte. Sprachsignal und LxSignal, automatisch phonem-, wort, silbenund tagsegmentiert. Größe:
etwa 3,3 GB.
• Sternzeitkorpus I: 7 CD-ROMs, Sprachaufnahmen vom digitalen Satellitenradio, automatisch wortsegmentiert, mit Hintergrundgeräuschen (Musik). Größe etwa 4 GB.
• Strenzeitkorpus II: Ausgewählte Texte von Sternzeitkorpus I, die im schalltoten Raum gelesen worden sind, automatisch phonem-, silben, wort- und
tagsegmentiert. Größe etwa 600 MB.
• Stuttgarter Radio News Korpus: Nachrichtenaufnahmen vom digitalen Satellitenradio, manuell phonem-, word-, silben-, und tags-, tones- und breaksegmentiert Grundfrequenzverlauf, Sprachsignal in wav-Format. Größe:
etwa 1 GB.
• Boston Radio News Corpus, Größe etwa 1,2 GB.
Seite 150

Automatische Segmentierung, Ver

Transcrição

Documentos relacionados

Flyer Eventverleih

49 % ! – 49

Operator (m/w) SMD-Bestückung - Hornberg

„Sie müssen nur den Nippel durch die Lasche zieh`n“

Nachkauf-Set für Hallux Valgus Schiene Nachkauf-Set für

Die in Zusammenarbeit mit der Fa. KLUG

39 % ! – 39

400 10 50 c kompressor50015-02

Die Tracht in der Medizin

Elch-Lollis

Digitale Annotationen: `Best Practices` und Potentiale (R 6.2.1) Teil II