close

Anmelden

Neues Passwort anfordern?

Anmeldung mit OpenID

(' )1023234 5 % 687¢90234@ %a' )b023c¢4 5 % dfebg8h5iq p5rtsu

EinbettenHerunterladen
 ✁✂✁☎✄✝✆✟✞✡✠✡☛✡☞ ✌✡✍✂☛✡✎
✏☎✑✡✒✔✓✖✕✗✑✡✘✔✕✚✙✜✛✔✢✤✣✔✥✦✥✦✧✡✓★✙
✩✫✪✂✬ ✣✔✥✦✧✭✙✮✛✔✢✯✣✔✥✦✰✂✧✡✓★✙
✱✳✲✯✴✫✵★✶✸✷★✹✻✺✼✴✗✽
✾✔✓✖✿ ✧✡❀✂✓✖✿ ❁✔✒✔❂ ❃✤✬ ✧❅❄❆✑✡✘✔❀☎✧✡✓✖❂❈❇❆✘✔✿ ❉☎✧✡✓✖❊✟✿ ❋✖●✟❋✫❍✗✓✖✬ ✑✂✘✔✕☎✧✡✘✔❂❈✢✯■✔✓✖✘✔✰✂✧✡✓✖✕
❏ ✘✔❊❑❋▲✿ ❋▲✣✻❋❆▼✖■✔✓❖◆€✧✂✓✖✥◗✑✂✘✔✿ ❊❑❋▲✿ ❘
❃✤✰✟❋▲✧✡✿ ✬ ✣✔✘✔✕❙▼✖■✔✓❯❚€✪✂✥◗❱☎✣✻❋▲✧✡✓✖✬ ✿ ✘✔✕✗✣✔✿ ❊❑❋▲✿ ❘
Zierl, Marco:
Entwicklung und Implementierung eines Datenbanksystems zur Speicherung und Verarbeitung von Textkorpora / Marco Zierl – 1. Aufl. –
Erlangen: Abt. f. Computerlinguistik (CLUE), Friedrich-AlexanderUniversität Erlangen-Nürnberg, 1998
[ CLUE-Arbeitsberichte / CLUE Technical Reports, Jg. 1, Heft 1; Hrsg. v.
Jochen Leidner ]
ISSN 1436–056X
❲
Copyright c Marco Zierl 1997, 1998.
First published 1998.
Abteilung für Computerlinguistik (CLUE)
Bismarckstraße 12
91054 Erlangen
Bundesrepublik Deutschland
Gesetzt mit LATEX in 11 pt Times.
Printed in Germany.
Department for Computational Linguistics
Bismarckstraße 12
91054 Erlangen
Federal Republic of Germany
Der vorliegende Band ist der erste der neuen Reihe CLUE-Arbeitsberichte/CLUE
Technical Reports, die interessante wissenschaftliche Arbeiten aus der Computerlinguistik der Forschergemeinschaft in deutscher oder englischer Sprache zur Verfügung
stellen und Aktivitäten der Abteilung für Computerlinguistik (CLUE) der FriedrichAlexander-Universität Erlangen-Nürnberg dokumentieren möchte. Er resultiert aus
einer Arbeit, die dort 1997 an der Philosophischen Fakultät II (Sprach- und Literaturwissenschaften) als Magisterarbeit eingereicht und angenommen wurde.
Korpora sind authentische Belege von Sprachereignissen, die der Linguistik zur Prüfung von Hypothesen und der maschinellen Sprachverarbeitung als Datengrundlage
zur Ermittlung statistischer Eigenschaften von Sprache dienen.
Der Autor faßt zunächst die gegenwärtigen Stand der Methoden und Werkzeuge aus
dem Bereich computerisierter Korpora zusammen. Dann beschreibt er die Konzeption und Implementierung von CORSICA, einem System, das die Speicherung von und
das Arbeiten mit großen, elektronisch gespeicherten Korpora in einer Client/ServerUmgebung ermöglicht.
Marco Zierl stellte die Quellen seiner Arbeit zur Verfügung. Michael Piotrowski
entwickelte das Layout dieser neuen Serie. Prof. Dr. Roland Hausser, Ph. D. stellte
freundlicherweise die finanziellen Mittel für den Druck und die Infrastruktur bereit.
Allen sei hiermit gedankt.
Jochen Leidner M. A.
Serienherausgeber
Über den Autor. Marco Zierl wurde 1969 in Esslingen am Neckar geboren. Nach
dem Abitur an der John-F.-Kennedy-Schule (Wirtschaftsgymnasium) in Esslingen studierte er Linguistische Informatik, Englische Philologie und Germanistische Linguistik an der Friedrich-Alexander-Universität Erlangen-Nürnberg und am Department
of Artificial Intelligence, University of Edinburgh, UK. 1997 legte er in Erlangen das
Magisterexamen ab. Zur Zeit ist er als Redakteur bei der Zeitschrift Internet Professionell tätig.
❳❳
Vorwort des Herausgebers
ii
Inhaltsverzeichnis
iii
Abbildungsverzeichnis
v
Tabellenverzeichnis
vi
1
Einleitung
1
1.1
Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
Korpora und Korpuslinguistik
4
2.1
Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.1
Repräsentativität und Balanciertheit . . . . . . . . . . . . . .
5
Korpora – gestern, heute und morgen . . . . . . . . . . . . . . . . .
5
2.2.1
Erste Computerkorpora . . . . . . . . . . . . . . . . . . . . .
6
2.2.2
Heutige Computerkorpora . . . . . . . . . . . . . . . . . . .
7
2.2.2.1
BNC . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.2.2
Bank of English . . . . . . . . . . . . . . . . . . .
8
2.2.2.3
IDS-Korpora . . . . . . . . . . . . . . . . . . . . .
9
2.2.2.4
Zukunft . . . . . . . . . . . . . . . . . . . . . . .
10
Korpusannotationen . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3.1
Formale Betrachtung . . . . . . . . . . . . . . . . . . . . . .
10
2.3.2
Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.2.1
12
2.2
2.3
Zuordnung von Tags . . . . . . . . . . . . . . . . .
❳❳❳
2.3.3
3
4
Disambiguierung . . . . . . . . . . . . . . . . . .
12
2.3.2.3
Tagset . . . . . . . . . . . . . . . . . . . . . . . .
13
Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3.3.1
14
Zugriff und Speicherung . . . . . . . . . . . . . . .
Verwandte Arbeiten
16
3.1
Konkordanzen und Korpus-Tools . . . . . . . . . . . . . . . . . . .
16
3.1.1
Konkordanzen . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.1.2
Konkordanzprogramme . . . . . . . . . . . . . . . . . . . .
17
3.1.3
Korpusdatenbanken . . . . . . . . . . . . . . . . . . . . . . .
18
3.1.3.1
SARA . . . . . . . . . . . . . . . . . . . . . . . .
18
3.1.3.2
COSMAS . . . . . . . . . . . . . . . . . . . . . .
19
3.1.3.3
Corpus Workbench . . . . . . . . . . . . . . . . .
19
3.1.3.4
Vergleich . . . . . . . . . . . . . . . . . . . . . . .
19
Kodierung und Tokenisierung
21
4.1
SGML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.2
TEI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.2.1
Kodierungsarten . . . . . . . . . . . . . . . . . . . . . . . .
23
4.2.2
Bedeutung für die Verarbeitung von Textdaten . . . . . . . .
23
Tokenisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.3.1
Modularer Ansatz . . . . . . . . . . . . . . . . . . . . . . . .
25
4.3.1.1
Entfernen von Whitespace . . . . . . . . . . . . . .
25
4.3.1.2
Trennen von Wörtern . . . . . . . . . . . . . . . .
25
4.3.1.3
Abtrennen von Satzzeichen . . . . . . . . . . . . .
26
4.3.1.4
Rückgängigmachen von Trennungen am Zeilenende
26
4.3.1.5
Zusammenführen von Zahlen . . . . . . . . . . . .
27
4.3.1.6
Disambiguierung von Punkten . . . . . . . . . . .
27
4.3.1.7
Ergebnisse der Punktdisambiguierung . . . . . . .
29
4.3
5
2.3.2.2
Texte und Textmetainformation
31
5.1
TEI-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.2
Korpus-Header und Text-Header . . . . . . . . . . . . . . . . . . . .
32
5.2.1
Title Statement . . . . . . . . . . . . . . . . . . . . . . . . .
33
5.2.2
Publication Statement . . . . . . . . . . . . . . . . . . . . .
33
5.2.3
Source Description . . . . . . . . . . . . . . . . . . . . . . .
33
Definition des Klassifikationsschemas . . . . . . . . . . . . . . . . .
34
5.3
❳❨
5.3.1
Referenzierung des Klassifikationsschemas . . . . . . . . . .
35
Speicherung der Textmetainformation . . . . . . . . . . . . . . . . .
35
5.4.1
36
5.4
6
Datenstrukturen
38
6.1
Grundgedanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
6.2
Integerzuordnung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
6.2.1
Wortliste . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
Suche nach Zeichenketten . . . . . . . . . . . . . . . . . . . . . . .
40
6.3.1
B-Bäume . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
6.3.2
Tries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
6.3.3
Patricia Trees . . . . . . . . . . . . . . . . . . . . . . . . . .
41
6.3.4
Binäre Suche im Hauptspeicher . . . . . . . . . . . . . . . .
42
Indexgenerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
6.4.1
Invertierte Datei . . . . . . . . . . . . . . . . . . . . . . . .
44
6.4.2
Sortierung der Indexdatei . . . . . . . . . . . . . . . . . . . .
44
6.4.3
Zusätzliche Dateien . . . . . . . . . . . . . . . . . . . . . . .
45
6.4.4
Beispielanfrage . . . . . . . . . . . . . . . . . . . . . . . . .
45
Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
6.3
6.4
6.5
7
8
9
Textmetainformation . . . . . . . . . . . . . . . . . . . . . .
Die Anfragesprache
48
7.1
Reguläre Ausdrücke . . . . . . . . . . . . . . . . . . . . . . . . . .
48
7.2
Logische Operatoren . . . . . . . . . . . . . . . . . . . . . . . . . .
49
7.3
Der Distanzoperator . . . . . . . . . . . . . . . . . . . . . . . . . .
50
7.3.1
50
Auswertung der Anfragesprache . . . . . . . . . . . . . . . .
Programmschnittstelle und Implementierung
52
8.1
Registrierung von Korpora . . . . . . . . . . . . . . . . . . . . . . .
52
8.2
Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
8.2.1
Logische Ebene . . . . . . . . . . . . . . . . . . . . . . . . .
53
8.2.2
Physikalische Ebene . . . . . . . . . . . . . . . . . . . . . .
54
8.2.3
Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
Zusammenfassung
56
9.1
56
Literatur
Erweiterungsmöglichkeiten . . . . . . . . . . . . . . . . . . . . . .
56
❨
2.1
Positionelle Attribute . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2
Auszug aus SUSANNE . . . . . . . . . . . . . . . . . . . . . . . . .
11
5.1
File Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.2
Taxonomiebeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.3
Beispiel einer profile description . . . . . . . . . . . . . . . . . . . .
36
6.1
Wortliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
6.2
Indexerstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
6.3
Sortierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
6.4
Beispielanfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
6.5
Attribute eines Korpus . . . . . . . . . . . . . . . . . . . . . . . . .
47
8.1
Überblick über das Gesamtsystem . . . . . . . . . . . . . . . . . . .
55
❨❩❳
2.1
Zusammenstellung des Brown- und LOB-Korpus . . . . . . . . . . .
7
2.2
BNC-Kategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3
IDS-Korpora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
4.1
Ergänzungswörter . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2
Abkürzungen in den IDS-Korpora . . . . . . . . . . . . . . . . . . .
28
7.1
EBNF-Spezifikation der Anfragesprache . . . . . . . . . . . . . . . .
50
❨❬❳ ❳
In der computerlinguistischen Forschung konnte man in den letzten Jahren einen
Trend zu empirischen Methoden der automatischen Spracherkennung und - verarbeitung feststellen. Diese Methoden wurden erst durch die Verfügbarkeit sehr großer
Korpora natürlicher Sprache möglich. Seit den ersten Versuchen, Sprache automatisch
mit Hilfe eines Computers zu analysieren, konzentrierte sich die Forschung hauptsächlich auf regelbasierte beziehungsweise wissensbasierte Ansätze, die meistens auf die
Ideen von Chomsky (1957) zurückgingen. Die entstandenen Systeme basierten somit auf der Idee einer generativen Grammatik, welche ganz im Sinne Chomskys auf
Grundlage von Introspektion, d. h. des eigenen Sprachwissens, erstellt wurde.
Durch die Fortschritte in der Computertechnik wurde es im Laufe der Jahre möglich,
immer größere Textmengen zu speichern. Während Chomsky die Verwendung von
Korpora zur linguistischen Theoriebildung aufgrund der zu geringen verfügbaren Datenmenge und der dadurch bedingten automatischen Einschränkung auf einen kleinen
Ausschnitt einer Sprache scharf kritisierte, existieren heutzutage Korpora mit einer
Größe von mehreren hundert Millionen Wörtern (siehe Kapitel 2.2.1). Solche Korpora mögen für die Untersuchung niederfrequenter linguistischer Phänomene immer
noch zu gering sein; für die Analyse des normalen Sprachgebrauchs sind sie jedoch
inzwischen ein wertvolles Hilfsmittel geworden.
Korpusdaten können auf verschiedene Arten von Nutzen sein: Bestehende Systeme
zur Analyse natürlicher Sprache können z. B. bezüglich ihrer Abdeckung sprachlicher
Phänomene geprüft werden. Wenn Korpora mit linguistischen Informationen annotiert werden, so können auf Basis dieser Information statistische Modelle zur automatischen Spracherkennung trainiert werden. Zudem öffnen sich weitere Möglichkeiten
wie die automatische Erstellung von Lexika, das Berechnen häufiger Kollokationen
und die Untersuchung von Frequenzverteilungen.
Für Linguisten bieten Korpora die Möglichkeit, gezielt nach bestimmten linguistischen Phänomenen zu suchen. Lexikographen können mögliche Verwendungen und
Bedeutungen von Wörtern direkt überblicken. Es entfällt somit die Notwendigkeit der
erfundenen linguistischen Beispielsätze. Durch die Verwendung von großen Textkorpora in der linguistischen Forschung ist es möglich, nicht mehr auf Grund des eigenen
Sprachgefühls und -verständnisses, sondern allein auf Basis der im Korpus befindli✆
chen Daten zu linguistischen Schlußfolgerungen zu kommen. Es ergibt sich somit ein
Paradigmenwechsel hin zu einer empirisch orientierten Wissenschaft.
Grundlage der Verwendung großer Textkorpora ist die Verfügbarkeit der Korpustexte
auf einen Computersystem. Da heutzutage Korpora in einer Größenordnung von hundert Millionen laufenden Wortformen keine Seltenheit mehr sind, ist es nicht mehr
möglich, auf diese Datenmengen mit den Standard-Werkzeugen zur Textverarbeitung
(z. B. grep(1), awk(1)) effizient zuzugreifen. Bei der Speicherung von Analysen von
Korpustexten ergibt sich zusätzlich das Problem, daß dabei die Originaldaten kopiert
werden müssen und ein Vergleich mehrerer linguistischer Analysen nur schwer möglich ist.
Um komfortabel mit größeren Korpora arbeiten zu können, ist daher die Speicherung
in einer Datenbank notwendig. Da normale Datenbanken nicht allen Anforderungen
gerecht werden, die beim Verarbeiten und Speichern von Korpustexten und - analysen
auftreten, ist hierzu die Erstellung eines speziellen Programmes sinnvoll. Dadurch
kann ein System erstellt werden, daß genau auf die Anforderungen der Benutzer von
Korpusdaten zugeschnitten ist.
❭❫❪❴❭❛❵✫❜❞❝✫❡❣❢❤❝✫✐❦❥❧✐♥♠❤❝✫❜❞♦
Ziel dieser Arbeit ist die Entwicklung und Implementierung eines Datenbanksystems
zur Speicherung und Verarbeitung von Textkorpora. Das zu erstellende System soll
dabei unter mehreren Gesichtspunkten benutzt werden können. Aus computerlinguistischer Sicht ist eine einheitliche Speicherung von beliebigen Analysen der Korpusdaten notwendig. Zudem soll von anderen Programmen auf die in der Korpusdatenbank gespeicherten Daten zugegriffen werden können. Die Korpusannotationen sollen
dabei beliebig zu einem Korpus hinzugefügt und entfernt werden können. Dadurch
wird eine Grundlage für computerunterstützte Analysen und Evaluierungen der Daten
geschaffen.
Eine andere Anforderung stellt das Durchsuchen der gespeicherten Korpora dar. Hierzu ist eine effiziente Anfragesprache notwendig, in der beliebige Anfragen zu Textdaten und -analysen formuliert werden können. Weiterhin ist eine Aufteilung der
Korpora in logische Einheiten, die mit Informationen versehen und einzeln angewählt
werden können, sinnvoll, um Suchanfragen auf bestimmte Teile eines Korpus einzuschränken. Eine weiterer Schwerpunkt ist die Aufbereitung und Kodierung der ursprünglichen Texte, um diese einheitlich in der Datenbank speichern zu können.
❭❫❪ ♣rq❙❡❞❜❞❝✫❢❤❝✫✐♥s€t❣✉
Die Arbeit ist wie folgt gegliedert: Kapitel 2 gibt einen allgemeinen Überblick über
bestehende Korpora und Möglichkeiten der Korpusannotation. Dabei werden Techniken der Korpusanalyse vorgestellt und die Konzeption und Erstellung von großen
Textkorpora erläutert. Kapitel 3 behandelt die Anforderungen an ein Programm zur
Speicherung von Korpusdaten und beschreibt verwandte Arbeiten. Das 4. Kapitel
ist der Aufbereitung der Korpusdaten gewidmet. Hierbei werden Möglichkeiten der
✈
Kodierung besprochen und die verwendete Tokenisierung der Korpusdaten erläutert.
Im 5. Kapitel wird die Speicherung und Auszeichnung von Text-externen Daten diskutiert. Hierzu gehört auch die Einordnung der Texte in selbstdefinierte Kategorien.
Kapitel 6 beschreibt die verwendeten Datenstrukturen der Korpusdatenbank und die
Methode der Indexerstellung. Das 7. Kapitel erläutert die Anfragesprache der Datenbank. Im 8. Kapitel wird auf die Konzeption des Systems und auf die Implementierung eingegangen. Kapitel 9 faßt die Ergebnisse der Arbeit zusammen und zeigt
Erweiterungsmöglichkeiten auf.
Das erstellte System wird im folgenden mit dem Namen CORSICA bezeichnet. Dieses
Akronym steht für »CORpus Storage and InteraCtive retrievAl«.
✠
In diesem Kapitel soll eine kurze Einführung in wichtige Begriffe der Korpuslinguistik
gegeben werden. Dabei wird die Entwicklung der Computerkorpora aufgezeigt und es
werden häufig verwendete Korpora der englischen und deutschen Sprache vorgestellt.
Anschließend werden Möglichkeiten zur Annotierung der Korpora mit linguistischer
Information diskutiert.
♣❯❪❴❭❛✇★❝✫①❤t€❜❞♦❑❜❞②✫t
John Sinclair definiert ein Korpus folgendermaßen:
A corpus is a collection of naturally-occuring language text, chosen to
characterize a state or variety of language.
(Sinclair 1991, S. 171)
Demzufolge kann jede Sammlung von Texten, wobei hier gesprochene Texte mit eingeschlossen sind, als Korpus aufgefaßt werden, sofern die Texte gezielt ausgewählt
wurden. Wichtig ist hierbei der Gedanke, daß ein Korpus zu einem bestimmten Zweck
erstellt wird und einen bestimmten Ausschnitt einer Sprache darstellt. Wie Chomksy
schon 1962 bemerkte, basieren alle Korpora auf bestimmten Auswahlkriterien:
Any natural corpus will be skewed. Some sentences won’t occur because
they are obvious, others because they are false, still others because they
are impolite.
(N. Chomsky, zitiert nach McEnery und Wilson 1996, S. 8)
Chomskys Kritik trifft auch heute noch zu, da mit einem Korpus niemals alle Variationen einer Sprache erfaßt werden können. Um also mit einem Korpus einen möglichst
großen Teil der in der jeweiligen Sprache vorkommenden Phänomene abzudecken, ist
es notwendig, bei der Auswahl der Korpustexte ein breites Spektrum an Textformen
und -Kategorien, welche im Idealfall auch quantitativ die Anzahl der in der Realität
produzierten und rezipierten Texte wiederspiegeln, zugrunde zu legen.
✞
③⑤④ ✙ ④ ✙⑦⑥❫✧✡❱☎✓✖●✡❊✟✧✡✘✻❋▲✑❅❋▲✿ ❉☎✿ ❋▲●❅❋❤✣✔✘✔❀⑨⑧❆✑✂✬ ✑✡✘✔❁✔✿ ✧✡✓⑩❋▲✒✔✧✡✿ ❋
In diesem Zusammenhang sind die Begriffe Repräsentativität und Balanciertheit eines Korpus von Wichtigkeit. Repräsentativität bezeichnet dabei die Auswahl der Texte. Wird die Gesamtmenge der möglichen Texte eines Korpus im voraus bestimmt, so
ist eine Zufallsauswahl die beste Methode, um eine repräsentative Auswahl zu erhalten. Biber (1993) liefert eine ausführliche Diskussion zum Thema Repräsentativität;
er plädiert dafür, vor einer Auswahl von Stichproben eine genaue Definition der Grenzen der zu untersuchenden Gesamtmenge vorzunehmen (sampling frame). Für eine
Auswahl von geschriebenen Texten eines bestimmten Jahres könnte also z. B. ein Index aller in diesem Jahr publizierten Werke diese Gesamtmenge darstellen, aus der die
Stichproben genommen werden.
Balanciertheit bezeichnet die Art der Gesamtzusammenstellung des Korpus. Ein balanciertes Korpus sollte demnach möglichst viele Textformen und -sorten sowie unterschiedliche Sprachvarianten in einer vorher bestimmten Anzahl enthalten. Zu diesem
Zweck werden oft Klassifikationsschemata aufgestellt oder es wird eine bestehende
Einordnung für Texte verwendet, um für eine Balance zwischen den verschiedenen
Kategorien zu sorgen. Sinclair spricht in Zusammenhang mit balancierten, repräsentativen Korpora hierbei auch von einem general corpus; er legt folgendes Prinzip zugrunde:
One of the principle uses of a corpus is to identify what is central and
typical in the language.
(Sinclair 1991, S. 17)
Repräsentative, balancierte Korpora sollten daher die allgemeine Verwendung von
Sprache abbilden und Spezial- und Fachsprache nur in dem Maße berücksichtigen,
wie diese Variante auch im Alltag wiederzufinden ist. Beispiele für balancierte Korpora werden in Kapitel 2.2.1 gegeben.
Im Gegensatz dazu stehen Korpora, die bewußt nur einen bestimmten Teil oder eine
bestimmte Kategorie einer Sprache abbilden und somit auch nur für diesen bestimmten Sprach- oder Texttyp repräsentativ sind. Hierzu zählen große Textsammlungen
bestimmter Autoren oder Zeitungskorpora, die hinsichtlich der Auswahl der Texte
auf ein Print- oder Publikationsmedium beschränkt sind, aber auch Spezialkorpora,
die sich in der Auswahl der Texte auf eine bestimmte Domäne oder Sprachvariante
beschränken. Als Beispiele seien hier das am Institut für Deutsche Sprache in Mannheim verfügbare Goethe-Korpus oder die von Brian MacWhinney erstellte Childes
Database McWhinney 1991, welche Gespräche zwischen Kindern einer bestimmten
Altersgruppe mit ihren Eltern enthält, genannt.
Für die computerlinguistische Forschung von größerem Interesse sind balancierte Korpora, die durch ihre Ausrichtung auf ein breites Spektrum von Sprach- und Textvarianten und ihren repräsentativen Charakter als Basis für das Training von statistischen
Modellen zur automatischen Sprachverarbeitung oder als Grundlage zur Verifikation und Erstellung von Programmen zur automatischen Sprachanalyse besser geeignet
sind. Unglücklicherweise ist die Erstellung von balancierten Korpora extrem arbeitsintensiv (abgesehen von rechtlichen Problemen, die das Copyright der Texte betreffen
und die Textauswahl erschweren können), so daß viele der umfangreichsten verfügbaren Textkorpora weder balanciert sind, noch nach genauen Auswahlkriterien zusammengestellt wurden (Ausnahmen siehe Kapitel 2.2.1).
✍
♣❯❪ ♣r❶❦②✫✐♥❷❤②✫✐♥❸r❹❛✉✼❝✫❺☎♦❻❝✫✐♥t€❼❆❽€❝€s€♦❑❝❾s€t❣❢➀❿➁②✫✐♥✉✼❝✫t
Traditionell wurden Korpora erstellt, um Linguisten beim Erstellen von Grammatiken
und Lexika eine Datenbasis und Referenz zur Verfügung zu stellen. Prominentestes
Beispiel ist die Erstellung des Oxford English Dictionary. Unter Mithilfe von zahlreichen Freiwilligen wurden zwischen 1858 bis zur Fertigstellung des Lexikons im Jahre
1928 über vier Millionen Zitatstellen gesammelt. In Kontrast zu dieser auf Hilfe von
Freiwilligen basierenden Korpuserstellung wurde bei der Arbeit zur dritten Ausgabe
von Webster’s New International Dictionary eine Anzahl von professionellen Lexikographen eingestellt, welche im Jahr 1936 ein systematisches Lesen von Zeitungen,
Zeitschriften und Büchern begannen. Bis zum Erscheinen des dritten Ausgabe (1961)
wurde dadurch die schon vorhandene Sammlung von Belegbeispielen von 1,6 Millionen auf 4,5 Millionen erhöht.
Ein weiteres Beispiel für eine erstaunliche Sammlung von Korpusmaterial ist die Arbeit von Kaeding, der schon 1897 für die Erstellung seines Buches über Wortfrequenzen ein Korpus von 11 Millionen laufenden Wortformen verwendete. Kaeding beschäftigte 5 000 Zähler, die die gesammelten Texte nach bestimmten Wörtern durchsuchten, um deren Frequenz zu ermitteln.
Diese Beispiele belegen die Wichtigkeit der Verwendung von Korpusmaterial und bestechen durch den unglaublichen Aufwand, der notwendig war, um die Daten von
Hand zu durchsuchen und auszuwerten. Einen guten Überblick über die Verwendung
von Korpora vor der Computer-Ära gibt der Artikel »Language Corpora B. C.« Francis
1992. Wenn heute von Korpora die Rede ist, so sind damit fast ausschließlich elektronisch verfügbare Korpora gemeint – der Begriff Korpus schließt somit das Vorhandensein der Daten in einer maschinenlesbaren Form mit ein. Durch die Möglichkeit,
Korpusdaten mit dem Computer auszuwerten und zu durchsuchen, ergeben sich eine
Vielzahl neuer Möglichkeiten der Datenauswertung, die die Verwendung von Korpora
insbesondere im Bereich der Lexikographie inzwischen unverzichtbar macht.
③⑤④ ③⑤④ ✙⑦❍☎✓✖❊❑❋▲✧➂❚€✪✂✥◗❱☎✣✻❋▲✧✡✓✖❘✔✪✡✓✖❱✂✪✂✓✖✑
Das erste Korpus, welches für die Benutzung mit einem Rechnersystem konzipiert
wurde, ist das inzwischen legendäre Brown Corpus, welches 1964 an der Brown University erstellt wurde. Das Korpus besteht aus 500 Texten aus 15 Genres, wobei jeder Text ungefähr 2 000 Wörter enthält. Die Größe von ungefähr 1 Million Wörtern
stellte das Maximum dessen dar, was mit der damaligen Computertechnologie und
den zur Verfügung stehenden Geldmitteln erstellt werden konnte. Das Korpus enthält
ausschließlich gedruckte amerikanische Texte des Jahres 1961 (und somit keine gesprochene Sprache), wobei die Textauszüge nach der Bestimmung der Genres zufällig
ausgewählt wurden und nach ca. 2 000 Wörtern enden. Die Anzahl der Textauszüge pro Genre sollte den Grad ihrer Verbreitung wiederspiegeln. Durch die zufällige
Auswahl der Texte sollte eine bewußte Bevorzugung einiger Texte vermieden werden.
Basierend auf der Komposition des Brown-Korpus wurde 1978 das LOB Corpus
(Lancaster-Oslo-Bergen-Korpus) fertiggestellt1, welches als britisches Gegenstück
1
Die Erstellung des LOB-Korpus begann im Jahre 1970. Aufgrund von technischen Schwierigkeiten, die
erst durch eine Zusammenarbeit mit dem norwegischen Computerzentrum der Geisteswissenschaften in
Bergen gelöst werden konnten, konnte es erst 1978 vollendet werden.
☛
konzipiert wurde und aus Texten der gleichen Genres aus dem gleichen Zeitraum
besteht. Somit war ein direkter Vergleich zwischen britischen und amerikanischem
Englisch möglich geworden. Tabelle 2.1 vergleicht die Genres und die Anzahl der
Texte pro Genre der beiden Korpora.
➃❻➄❩➅✡➆➈➇ ➇➉➆❣➊✮➋ ➌▲➍❆➃✻➆➈➎♥➏ ➐✖➄➑➏ ➆❴➒✂➓❻➔➣→ ➆➈↔➙↕❅➆❴➛✼➜➑➔❑➓❅➝✮↔▲➞
➟ ↔✜↕€➠✔➡✟➜➑➞ ➢⑤➓➈➔➣➤ ➟ ➛➦➥ ➠➧➆✻➆❬➨❴➩➦➥ ➌✮➫✖➭⑤➯✖➲ ➳➑➵❩➋➑➯✖➲
Textkategorie (Genre)
A
B
C
D
E
F
G
H
J
K
L
M
N
P
R
Press: reportage
Press: editorial
Press: reviews
Religion
Skills & hobbies
Popular Lore
Belles lettres, biography, essays
Miscellaneous
Learned
General fiction
Mystery & detective fiction
Science fiction
Adventure & western fiction
Romance & love story
Humor
Textanzahl
Brown
44
27
17
17
36
48
75
30
80
29
24
6
29
29
9
LOB
44
27
17
17
38
44
77
30
80
29
24
6
29
29
9
In Deutschland wurde 1970 an der Universität Bonn das LIMAS-Korpus erstellt, welches in Textanzahl und -umfang dem Brown-Korpus entspricht, aber Texte aus 33
Themengebieten enthält. Die Themengebiete entsprechen der Einteilung der Deutschen Nationalbibliographie für deutsche Texte aus dem Jahr 1970. Das Korpus ist
bislang das einzige allgemeine, balancierte Korpus in deutscher Sprache.
Diese drei unter heutigen Gesichtspunkten relativ kleinen Korpora werden auch heute noch häufig in der Forschung verwendet, stellen sie doch eine zuverlässige Datenbasis dar, die durch zahlreiche Forschungsarbeiten analysiert und annotiert wurde
(siehe hierzu auch Kapitel 2.3). So veröffentlichten Francis und Kuˇcera (1982) eine
ausführliche Frequenzanalyse des Brown-Korpus, die auch heute noch als Standard
für Frequenzuntersuchungen von Korpora gilt. Die Konzeption und Textauswahl des
Brown-Korpus gilt dabei heute immer noch als vorbildlich. Durch einen hohen manuellen Aufwand ist das Brown-Korpus heute praktisch fehlerfrei.
③⑤④ ③⑤④ ③
➸ ✧✂✣✻❋✖✿ ✕✗✧➂❚✫✪✡✥✦❱✂✣✻❋▲✧✡✓✖❘✔✪✂✓✖❱✂✪✡✓✖✑
Da in der heutigen Zeit beinahe jeder Text vor seinem Druck in elektronischer Form
vorliegt (und sei es nur als Satzband), liegt das Problem der Korpuserstellung heutzutage nicht mehr in der Beschaffung der Texte, sondern, wie Sinclair bemerkt, in
der richtigen Auswahl der zur Verfügung stehenden Daten für den jeweiligen Verwendungszweck. Mit der Einführung der CD-ROM und der Ausbreitung des World
Wide Web ist eine große Anzahl von Publikationen elektronisch verfügbar geworden2.
Church (1993) gibt z. B. an, daß er Texte in einem Umfang von einer halben Milliarde
laufender Wortformen online zur Verfügung hat. Trotzdem kann es je nach Anwendungszweck sinnvoller sein, ein kleineres, zumindest teilweise balanciertes Korpus
zur Verfügung zu haben, welches sauber kodiert und annotiert wurde und weitgehend
2
Als Beispiel sei hier die CD-ROM der taz genannt, auf der alle Ausgaben der letzten zehn Jahre gespeichert sind.
➺
fehlerfrei ist. Zur linguistischen Theoriebildung und der Suche nach weniger frequenten sprachlichen Phänomenen kann aber weiterhin Churchs Ausspruch »More data is
better data« als richtungsweisend angesehen werden.
③⑤④ ③⑤④ ③⑤④ ✙⑦⑧❆✢✤❚
Ein vorbildliches Projekt, welches 1995 abgeschlossen wurde, ist das British National
Corpus (BNC). Hierbei handelt es sich um ein balanciertes Korpus bestehend aus 100
Millionen laufenden Wörtern, wobei 10 % der Daten aus gesprochener Sprache bestehen Burnard 1995. Für die Kategorisierung der Texte wurden dabei verschiedene
Taxonomien definiert; jede Taxonomie beinhaltet eine definierte Anzahl von möglichen Kategorien. Tabelle 2.2 zeigt einen Ausschnitt der verwendeten Taxonomien des
BNC. Durch diese Einteilung ist es z. B. möglich, nur gesprochene Texte von Autoren einer bestimmten Altersgruppe auszuwählen. In Kapitel 5.3 wird genauer auf die
Definition der Taxonomien eingegangen. Das BNC enthält englische Texte der Jahre 1960 bis 1993 und ist bezüglich der Komposition und der Kodierung.3 das bisher
aufwendigste Projekt in der Geschichte der Computerkorpora. Wie auch Brown, LOB
und LIMAS gehört es zur Gruppe der sample corpora, d. h. es wurde bei Texten, die
eine bestimmte Wortanzahl übersteigen, nur eine vorher festgelegte Anzahl von Wörtern des Textes (= sample size) in das Korpus aufgenommen (im Falle des BNC lag
die Grenze bei 45 000 Wörtern), um sicherzustellen, daß einzelne Texte die Balance
des Gesamtkorpus nicht beeinträchtigen können.
➃❻➄❩➅✡➆➈➇ ➇➉➆❣➊✮➋ ➊✜➍➻➃❻➄❬➎✟➓❻↔✜➓❻➼✼→➉➆➈↔❙↕❅➆➈➛✼➜✜➽€➾
➥ ➚ ➟ ➛▲➛✜➨➪➩❩↔▲→ ➏ ➏ ➲
Taxonomie
Kategorien
Domain
Imaginative, Arts, Belief and Thought, Commerce,
Leisure, Natural Science, Applied Science, World Affairs, Unclassified
Publication date
1960–1974, 1975–1993, Unclassified
Medium
Book, Periodical, Misc. published, Misc. unpublished, To-be-spoken, Unclassified
Author sex
Male, Female, Mixed, Unknown, Unclassified
③⑤④ ③⑤④ ③⑤④ ③
⑧❆✑✡✘✔❘◗✪❅▼✯❍✗✘✔✕☎✬ ✿ ❊✟✒
Das bislang umfangreichste Korpus englischer Sprache ist die Bank of English (BOE),
erstellt von COBUILD unter der Leitung von John Sinclair. Eine Besonderheit der
BOE ist die ständige Erweiterung des Datenbestandes durch eine Anzahl von täglich
oder wöchentlich erscheinenden Publikationen. Gemäß der Homepage der BOE4 enthielt das Korpus Mitte Juni 1996 bereits 320 Millionen laufende Wortformen bei einem monatlichen Wachstum von etwa 5 Millionen Wörtern. Sinclair spricht in diesem
Zusammenhang von einem Monitorkorpus, d. i. ein Korpus, welches den jeweiligen
Zustand einer Sprache darstellen soll. Ausgehend von einem Main Corpus können
bestimmte Teile der BOE entfernt oder hinzugefügt werden. Durch An- oder Abwählen zeitlich bestimmter Teile des Korpus sollen so verschiedene Entwicklungsebenen
einer Sprache ausgewählt werden können.
3
4
Zur Kodierung des BNC siehe Kapitel 4.2
➶ http://titania.cobuild.collins.co.uk/boe_info.html➹
➘
Die Arbeit an der BOE begann im Jahr 1980 mit der Erstellung des Main Corpus,
welches 1982 fertiggestellt wurde und 7,3 Millionen Wortformen umfaßt. Folgende
Designkriterien wurden dabei aufgestellt:
➴ Geschlecht der Autoren: 75 % männlich, 25 % weiblich
➴ Sprachvariante: 70 % britisches Englisch, 20 % amerikanisches Englisch, 5 %
weder amerikanisch noch britisch
➴ Sprachmodus: 75 % gesprochene Sprache, 25 % geschriebene Sprache
Der Teil des Korpus, der geschriebene Sprache enthält besteht dabei aus 94 Texten mit
durchschnittlich 70 000 Wortformen und wurde hauptsächlich durch OCR (Optical
Character Recognition) in computerlesbare Form übertragen. Die Texte wurden aus
16 verschiedenen Bereichen ausgewählt, aufgrund der bescheidenen Gesamtanzahl
der Texte sind aber durchschnittlich nur 5 Texte pro Kategorie enthalten. Zudem ist
der Anteil an Texten, die aus Büchern entnommen wurden, mit 66 von insgesamt 96
Texten verhältnismäßig hoch (siehe Renouf 1987, Appendix 1).
Aufbauend auf diesem Main Corpus wurde in darauffolgenden Jahren ein Reserve
Corpus erstellt, indem alle Bücher, deren 70 000 erste Wortformen im Main Corpus
erfaßt wurden, vervollständigt wurden, um komplette Texte im Computer zur Verfügung zu haben. Darüber hinaus wurden 190 neue Texte integriert (148 davon aus
Büchern); das Reserve Corpus umfaßt dadurch 13 Millionen Wortformen. Die ursprüngliche Intention der Korpuserstellung wurde dabei aufgegeben:
The Reserve Corpus was not built with attention to the parameters of
register and discourse. What was aimed for was variety, not balance,
since it was conceived to be an on-going accumulation of data.
(Renouf 1987, S. 11)
Eine Einteilung in Genres oder Kategorien wurde also bewußt vernachlässigt und Texte wurden nun vollständig erfaßt, weshalb die Bank of English von Leech auch als die
»Birmingham Collection of English Text« bezeichnet wird (Leech 1987, S. 6). Sinclair rechtfertigt die Integration auch sehr großer kompletter Texte mit der wachsenden
Größe des Korpus; der Beitrag eines einzelnen Textes zum Gesamtkorpus wird mit zunehmender Größe des Korpus immer geringer. Zudem ließe sich jederzeit ein sample
corpus aus den zur Verfügung stehenden Texten erstellen. Zu kritisieren bleibt trotz
des beeindruckenden Umfangs die geringe Balance der Textsorten und eine weitgehende Konzentration auf Zeitungstexte beim Erweitern des Monitorkorpus.
③⑤④ ③⑤④ ③⑤④ ➷
❏ ➬€➮⑤❂❈➱❫✪✂✓✖❱✂✪✡✓✖✑
Die umfangreichste Sammlung deutscher Korpora befindet sich am Institut für Deutsche Sprache (IDS) in Mannheim. Dort sind verschiedenste Korpora mit einem Gesamtumfang von ca. 73,5 Millionen laufenden Wortformen gespeichert, auf die über
das System COSMAS zugegriffen werden kann. Das größte Korpus stellt dabei das
Monitorkorpus des Mannheimer Morgen dar; jeden Morgen wird die aktuelle Ausgabe
dieser Tageszeitung per Modem ins IDS übertragen und dort automatisch gespeichert.
Auf diese Weise sind ca. 42 Millionen laufende Wortformen dieser Tageszeitung verfügbar.
✃
Die übrigen verfügbaren Korpora sind bis auf das LIMAS-Korpus entweder vom Umfang her gering (die drei verfügbaren Korpora gesprochener Sprache z. B. umfassen
zusammen ca. 1,5 Millionen laufende Wortformen), oder – wie das Grimm- oder das
Marx-Engels-Korpus – sehr speziell. Als Korpora allgemeiner Sprache interessant
sind folgende Sammlungen:
➃❻➄❩➅✡➆➈➇ ➇➉➆❣➊✮➋ ❐▲➍➧❒ ❮❫➵❩➞ ➢⑤➓❻➔❞➤✡➓❻➔❞➄❧➥ ➚ ➟ ➛▲➛✜➨➪➩❩↔▲→ ➏ ➏ ➲
Titel
Textanzahl
Größe
Quelle
Handbuchkorpora
17 330
11 Mill.
Zeit,
Mannheimer
Morgen, Stern
Bonner Zeitungskorpus
10 840
3 Mill.
Neues Deutschland /
Die Welt
Wendekorpus Ost/West
3 387
3,3 Mill.
Artikel, Reden, Flugblätter etc.
Wie auch in Kapitel 3.1.3.2 beschrieben wird, können die Korpora bei einer Anfrage
beliebig kombiniert werden. Auf diese Weise ist es möglich, domänenspezifische
Korpora gezielt anzuwählen. Auch bei den IDS-Korpora ist aber eine weitgehende
Dominanz von Zeitungstexten festzustellen.
③⑤④ ③⑤④ ③⑤④ ❰
Ï ✣✔❘✔✣✔✘✻▼⑩❋
Die BOE und die Sammlung der Textkorpora des IDS zeigen auf, wohin die Entwicklung der Korpora in Zukunft gehen könnte: hin zu großen Textdatenbanken, aus
denen sich die Benutzer ein für ihre Zwecke sinnvolles Korpus selbst definieren können. Entscheidend für die Qualität eines solchen Korpus werden die Auswahl der
Texte und der Kategorien sein, in welche diese eingeteilt werden. Die Anzahl der
laufenden Wortformen wird dabei in Zukunft immer größer werden. Schon jetzt existieren riesige elektronische Textsammlungen wie z. B. das Oxford Text Archive, in
welchem urheberrechtsfreie englische und amerikanische Texte gesammelt werden.
Diese Sammlungen stellen, wie Leech (1991) bemerkt, zwar keine Korpora dar,5 können aber leicht als Basis zur Erstellung eines Korpus herangezogen werden. Die Herausforderung an die Software, mit welcher dann auf dieses Korpus zugegriffen wird,
liegt demzufolge unter anderen auch im Bereich der gezielten Auswahl- und Filtermöglichkeit von bestimmten Teilmengen des Korpus.
♣❯❪ Ðr❶❦②✫✐♥❷❤s€❺✂❸✫t€t❣②✫♦❑❸€♦❑❜❞②✫t€❝✫t
Unter der Annotation eines Korpus versteht man die Hinzufügung von Information
zu einem Korpus. Typischerweise handelt es sich hierbei um linguistische Analysen
der Korpusdaten. Die Bandbreite reicht dabei von der Analyse der Wortklasse über
Morphologie und Syntax bis hin zur semantischen Analyse, wie z. B. der Einordnung
in Bedeutungsklassen.
③⑤④ ➷⑤④ ✙⑦✾✔✪✡✓✖✥✦✑✡✬ ✧➂⑧❆✧✟❋✖✓✖✑✂❁✔✒✻❋✖✣✔✘✔✕
Wenn ein Korpus als eine Abfolge von n Positionen gesehen wird, wobei jeder Position ein Wort zugeordnet ist, so kann eine Annotation auf der Wortebene als ein zusätz5
»A collection of machine-readable text does not make a corpus« (Leech 1991, S. 10).
✆❅✌
liches positionelles Attribut definiert werden. Die Anzahl der positionellen Attribute
ist dabei nicht begrenzt; ein obligatorisches positionelles Attribut für jedes Korpus
wäre demnach die Zuordnung einer Wortform zu jeder Position (siehe Schaubild 2.1).
➚♥➅❅➅❅→ ➇➉↕ ➟ ↔▲➒Ñ➊✜➋ ➌✖➍✔Ò✜➓❻➔➣➼✼➄❩➇➉➆❖➵▲→➉➨➪➩✜➏ ➝✗➆❴→ ➛✜➆❯↕❅➆❴➔
➤✡➓❻➛▲→➉➏ → ➓❻↔✜➆➈➇ ➇➉➆➈↔✯➚☎➏ ➏ ➔❞→ ➅ ➟ ➏ ➆
Position
Wort
pos. Attr. 1
pos. Attr. 2
...
pos. Attr. i
0
wort(0)
pos_attr_1(0)
pos_attr_2(0)
...
pos_attr_i(0)
1
wort(1)
pos_attr_1(1)
pos_attr_2(1)
...
pos_attr_i(1)
...
...
...
...
...
...
n
wort(n)
pos_attr_1(n)
pos_attr_2(n)
...
pos_attr_i(n)
Typische positionelle Attribute sind zum Beispiel die Speicherung der Grundform einer jeden Wortform (Lemma), oder die im nächsten Abschnitt beschriebenen Zuordnung einer grammatischen Kategorie (Tag). Als Beispiel soll der folgende Ausschnitt
aus dem SUSANNE-Korpus Sampson 1995 dienen: Das Korpus enthält die Attribute
Wordtag (siehe Abschnitt 2.3.2), Lemma und Parse Field (siehe Abschnitt 2.3.3).
➚♥➅❅➅❅→ ➇➉↕ ➟ ↔▲➒❦➊✜➋ ➊✮➍➧➚ ➟ ➛▲Ó ➟ ➒Ñ➄ ➟ ➛➦↕❅➆➈➼
➵➑Ô➧➵▲➚✮➽✡➽✡Õ♥➞ ➢✗➓❻➔❞➤ ➟ ➛Ö➵❩➄❩➼✼➤❅➛✜➓❻↔★➌✜➫✮➫✮×
Word
Wordtag
Lemma
Parse Field
I
PPIS1
I
[S[Nea:s.Nea:s]
suspected
VVDt
suspect
[Vd.Vd]
why
RRQq
why
[Fn?:o[Rq:c.Rq:c]
he
PPHS1m
he
[Nas:s.Nas:s]
brought
VVDt
bring
[Vd.Vd]
it
PPH1
it
[Ni:o.Ni:o]
along
RL
along
[R:p.R:p]Fn?:o]S]
③⑤④ ➷⑤④ ③⑦Ø ✑✡✕✗✕☎✿ ✘✔✕
Die verbreitetste Annotation von Korpora ist das morphosyntaktische Tagging. Hierbei wird jeder Wortform eine eindeutige grammatische Kategorie zugeordnet. In der
Literatur werden hierfür auch die Termini part-of-speech (POS) tagging oder kurz
POS-Annotation verwendet (vgl. McEnery und Wilson 1996, S. 36). Ein Grund für
die häufige Annotierung von Korpora mit POS-Klassen ist dabei die Tatsache, daß dieser Vorgang von sogenannten Taggern mit einer geringen Fehlerquote vollautomatisch
durchgeführt werden kann.
Durch Tagging können die Möglichkeiten der effektiven Suche in einen Korpus besonders für Sprachen mit einer hohen Anzahl von Homographen extrem gesteigert
werden. Ohne morphosyntaktische Information ist es z. B. in deutschen Texten nicht
möglich, bei der Suche in einem Korpus zwischen dem Verb und dem Adjektiv »liebe«
zu unterscheiden. In englischen Texten würde die Suche nach dem Personalpronomen
der ersten Person Singular auch alle Stellen liefern, an der »I« als römische Zahl oder
als Buchstabe verwendet wurde.
Das Tagging selbst läuft meist in zwei Phasen ab:
1. Tag-Zuordnung: Jeder Wortform wird eine Anzahl von möglichen Tags zugeordnet. (Kandidatenzuweisung)
✆✡✆
2. Tag-Disambiguierung: Die in Phase 1 zugeordneten Tags werden disambiguiert,
so daß ein eindeutig getaggtes Korpus entsteht. (Auswahl)
Als Beispiel soll ein Satz aus Briscoe (1994) betrachtet werden:
he can can a
can
ProN Mod Mod Det Mod
Nn Nn
Nn
Vb Vb
Vb
Mehrdeutige Tag-Sequenz
Da das Wort »can« im Englischen sowohl als Modalverb, Vollverb oder Nomen
verwendet werden kann, ergeben sich in obigem Satz 27 Möglichkeiten der TagZuordnung. Die Aufgabe der Disambiguierung ist es, den richtigen Pfad durch die
Reihe der möglichen Tags zu finden und zu folgendem Resultat zu kommen:
he can can a
can
ProN Mod Vb Det Nn
Disambiguierte Tag-Sequenz
③⑤④ ➷⑤④ ③⑤④ ✙
Ï ✣✔✪✡✓✖❀☎✘✔✣✔✘✔✕❙❉☎✪✡✘ Ø ✑✡✕✗❊
Beim Tagging des Brown- und des LOB-Korpus wurde die Tagzuordnung mit Hilfe von Programmen durchgeführt, die ein kleines Basislexikon benutzen. Im Falle
des LOB-Korpus umfaßte dieses Lexikon ca. 7 200 Wörter (siehe Garside 1987, S.
35). Nicht erkannte Wörter wurden mit Hilfe einfacher Stemming-Algorithmen und
Heuristiken analysiert.
Heutzutage wird zumeist ein Programm zur morphologischen Analyse verwendet.
Der ENCGG-Tagger (vgl. Voutilainen 1994), der zum Tagging der Bank of English benutzt wurde, verwendet ein morphologisches Analyseprogramm, welches auf
der Two-Level Morphology von Koskenniemi (1983) basiert. An der Abteilung für
Computerlinguistik der Universität Erlangen-Nürnberg wird das Programm MALAGA (vgl. Beutel 1995) mit der von Lorenz (1996) geschriebenen deutschen Morphologie verwendet. Die theoretische Grundlage von MALAGA bildet die linksassoziative
Grammatik wie in Hausser (1989) beschrieben.
③⑤④ ➷⑤④ ③⑤④ ③
➬✫✿ ❊✟✑✡✥✦✰☎✿ ✕✗✣✔✿ ✧✂✓✖✣✔✘✔✕
Bei der Disambiguierung der zugeordneten Tags kann man zwischen regelbasierten
und statistischen Disambiguierungsmethoden unterscheiden. Eines der ersten Programme war TAGGIT (siehe Greene und Rubin 1971), welches zum Taggen des
Brown-Korpus verwendet wurde. TAGGIT umfaßte 3 300 regelbasierte Schablonen
(templates) und konnte damit 77 % der Tags disambiguieren. Der Rest des Korpus
wurde in zeitaufwendiger Arbeit von Hand disambiguiert. Durch diese Pioniertat entstand das erste vollständig getaggte Korpus englischer Sprache. Da die Annotierung
in Handarbeit überprüft wurde, stellt es immer noch eines der am zuverlässigsten und
fehlerfreiesten annotierten Korpora dar.
Ausgehend vom getaggten Brown-Korpus wurde an der Universität Lancaster Mitte der 80er Jahre ein Projekt gestartet, um das komplette LOB-Korpus zu Taggen.
✆ ✈
Dabei wurden statistische Modelle verwendet, die auf der Grundlage der Daten des
getaggten Brown-Korpus errechnet wurden. Die angewandte Methode basiert auf
Übergangswahrscheinlichkeiten zwischen je zwei Tags (Bigrammen) und der relativen Wahrscheinlichkeit der Zuweisung einer Kategorie zu einem Wort (relative tag
probability). Das entstandene Programm CLAWS Marshall 1987 hatte eine Fehlerrate
von etwa 4 % und setzte damit den Standard für alle folgenden Projekte.
Die Vorgehensweise des statistischen Taggens hat sich seitdem wenig geändert. Die
Nachteile von CLAWS – das System benötigte sehr viel Speicher und Rechenzeit
– wurden durch Arbeiten von DeRose (1988) und Church (1988) beseitigt. Zudem
wurden erweitere statistische Modelle basierend auf Trigrammen oder n-Grammen
verwendet. Die Grundvoraussetzung bildet aber immer noch ein eindeutig getaggtes
Korpus. Die Fehlerrate der statistisch-basierten Tagger konnte dabei nicht wesentlich
verbessert werden (einen Vergleich über verschiedene Tagger bietet DeRose (1988)).
Wird ein Korpus wie im Falle des BNC mit Hilfe eines statistischen Taggers vollautomatisch getaggt, so ist damit automatisch ein bestimmter Prozentsatz an Fehlern
verbunden.6
Eine Alternative stellt die in Voutilainen (1994) vorgestellte regelbasierte Disambiguierung auf Grundlage der von Karlsson entwickelten Constraint Grammar dar (vgl.
Karlsson et al. 1995, ) dar. Die Disambiguierungsgrammatik besteht dabei aus 1 100
Constraints, die auf Basis von 23 linguistischen Verallgemeinerungen aufgestellt wurden. Das besondere dieses regelbasierten Taggers liegt dabei in der Tatsache, daß die
Möglichkeit besteht, ca. 2–4 % der Wortformen mehrdeutig getaggt zu lassen. Die
Fehlerrate des Taggers verringert sich dadurch auf nur 0,3 %. Auf diese Weise ist
eine manuelle Disambiguierung der nicht disambiguierten Tags möglich, um so ein
beinahe fehlerfrei annotiertes Korpus zu erhalten.
③⑤④ ➷⑤④ ③⑤④ ➷⑦Ø ✑✡✕✗❊✟✧❅❋
Entscheidend für den Wert der Annotation ist das verwendete Tagset, welches die Anzahl und Art der möglichen Tags definiert. Fehlerrate und Nützlichkeit der vom Tagger
erzeugten Annotation hängt dabei nicht unwesentlich von der Größe des Tagsets ab.
Ist dieses relativ klein gewählt, sinkt zwar die Fehlerrate des Taggers, die Annotation
läßt dann aber keine feinen linguistischen Unterscheidungen mehr zu. Ist das Tagset
zu groß gewählt, so steigt die Ambiguität bei der Zuweisung der Tags und der Tagger
produziert dadurch eine größere Anzahl von Fehlern. Bei statistischen Taggern tritt
dabei noch ein anderes Problem auf: Da zum Training der statistischen Modelle ein
eindeutig getaggtes Korpus notwendig ist, muß schon dieses Trainingskorpus mit dem
verwendeten Tagset annotiert worden sein. Eine Veränderung des Tagset ist demnach
auch mit einer zeitaufwendigen manuellen Annotierung eines Korpus verbunden. Dies
ist mit ein Grund dafür, daß die meisten Tagger für englische Texte auf dem Tagset des
Brown-Korpus basieren (127 unterschiedliche Tags), oder dieses – wie im Falle von
CLAWS (130 Tags) – nur geringfügig verändern. Ein »downsizing« auf ein kleineres
Tagset ist hingegen unproblematisch.
6
Burnard (1995) gibt die Fehlerrate des BNC mit 2–3 % an. Eine Betrachtung der BNC-Daten läßt aber
auf eine höhere Fehlerquote schließen. Inzwischen wurde ein neues Projekt gestartet wurde, um das Korpus
komplett neu zu Taggen.
✆❅✠
③⑤④ ➷⑤④ ➷
Ù ✑✡✓✖❊✟✿ ✘✔✕
Nachdem die morphosyntaktischen Einheiten eines Korpus ausgezeichnet wurden, ist
es möglich, diese zu syntaktischen Einheiten zusammenzufassen und die Abhängigkeiten dieser Einheiten voneinander zu bestimmten (Parsing). Syntaktisch analysierte
Korpora werden auch als treebanks bezeichnet. Dieser Ausdruck beruht auf der Tatsache, daß die verwendete Analyse der Sätze meist auf einem Syntaxbaum basiert,
der die hierarchische Ordnung der Konstituenten darstellt. Da die syntaktische Analyse von Korpustexten um vieles schwieriger und komplexer als die morphologische
Analyse bzw. Wortklassenbestimmung ist, existieren bisher wenig Programme, die
beliebige Korpustexte vollautomatisch analysieren können. Die meisten syntaktisch
annotierten Korpora wurden zumindest teilweise manuell erstellt und nachbearbeitet.
Das oben genannte SUSANNE-Korpus (ein Teil des Brown-Korpus bestehend aus
130 000 laufenden Wortformen) wurde in jahrelanger Arbeit von Hand syntaktisch
analysiert. Das dabei verwendete parsing scheme ist in Sampson (1995) beschrieben
und stellt die bisher ausführlichste syntaktische Beschreibung eines Teilkorpus dar.
Es wurden nicht nur formale sondern auch funktionale Kategorien wie Subjekt und
Objekt eines Satzes und semantische Information wie die Art eines Adjunkts (place,
direction, time etc.) ausgezeichnet.
Korpora, die zum größten Teil automatisch syntaktisch analysiert wurden, weisen hingegen eine sehr einfache und »flache« Analyse der Konstituenten auf. Man spricht
dabei auch von skeleton parsing. Die Parser verwenden dabei meist eine Variante einer kontextfreien Phrasenstrukturgrammatik, deren Regeln durch Training auf einem
getaggten Testkorpus errechnet werden können (vgl. Leech und Garside 1991).
Einen anderen Ansatz stellt Karlssons System dar, das zur syntaktischen Analyse der
BOE verwendet wurde. Der Parser markiert dabei nicht Phrasengrenzen, sondern
die grammatischen Funktionen der Wörter eines Satzes und die bestehenden Abhängigkeiten zwischen diesen (Dependenzgrammatik). Das Ergebnis ist allerdings noch
mehr als beim skeleton parsing eine sehr flache Analyse der Satzstruktur, da der Parser
aus Effizienzgründen keine Fernabhängigkeiten markiert.
③⑤④ ➷⑤④ ➷⑤④ ✙
Ï ✣✔✕✗✓✖✿ ▼⑩▼❯✣✔✘✔❀Ú➮⑤❱✂✧✂✿ ❁✔✒✔✧✡✓✖✣✔✘✔✕
Probleme bei der syntaktischen Analyse ganzer Korpora stellen Zugriff und Speicherung der Satzanalysen dar. Die einfachste Möglichkeit besteht in der Speicherung der
Parsinginformation als positionelle Attribute. Dies bietet sich vor allem bei Karlssons System an, da hier die syntaktische Information nicht hierarchisch organisiert
ist. Grundsätzlich ist natürlich die Speicherung des Syntaxbaumes als eigenständige
Datenstruktur wünschenswert. Der mögliche Zugriff auf diese abgespeicherten Syntaxanalysen ist aber im Bereich der Korpuslinguistik noch wenig erforscht. Wenn die
Daten dem Benutzer als zusätzliche Möglichkeit, Suchanfragen zu formulieren, zur
Verfügung gestellt werden sollen, so stellt dies komplexe Anforderungen an die verwendete Anfragesprache. Bisher unterstützt noch kein dem Autor bekanntes System
die Anfrage der kompletten Struktur syntaktisch analysierter Korpora. Zudem ergibt
sich das Problem, daß die syntaktischen Analysen stark vom jeweiligen Parser abhängig sind und bisher noch kein einheitliches Format existiert. Soll die syntaktische
Information als Grundlage zum Training von statistischen Analyseprogrammen oder
zur Abfrage von Parsinginformation verwendet werden, so ist der Aufbau einer spezi✆❅✞
ellen Datenstruktur innerhalb des jeweiligen Programmes notwendig. In diesem Fall
würde eine Speicherung der Parsinginformation als positionelles Attribut ausreichen,
da die Satzanalysen daraus zusammengesetzt werden können.
Eine andere Möglichkeit, welche an der Abteilung für Computerlinguistik in Erlangen untersucht wird, ist die Speicherung der Satzanalysen in einer separaten Datenbank. Wird diese Methode verwendet, so ist es ausreichend, eine Schnittstelle zwischen CORSICA und der Datenbank herzustellen. Eine zusätzliche Speicherung der
Analysen ist dadurch nicht notwendig. In CORSICA wird daher nur die Möglichkeit der Speicherung positioneller Attribute unterstützt. Komplexere Analysen können aber verteilt über mehrere Positionen abgespeichert werden, wenn Start und Ende
der Analysen genau definiert werden.
✆❅✍
Ð❯❪❴❭❛❶❦②✫t€Û❣②✫✐♥❢❤❸✫t€Ü➻❝€t❛s€t❣❢Ý❶❦②✫✐♥❷❤s€❺✂Þàß✫②✫②✫❡❞❺
In diesem Kapitel sollen verwandte Arbeiten und Systeme vorgestellt werden. Ausgehend von den ersten Computerprogrammen zur Konkordanzerstellung werden die
Entwicklungen zu den heute verwendeten Programmen aufgezeigt.
➷⑤④ ✙ ④ ✙⑦➱❫✪✡✘✔❘✔✪✂✓✖❀✂✑✡✘✔á✜✧✡✘
In den Anfängen der Corpuslinguistik lag die hauptsächliche Anwendung von Korpusdaten in der Erstellung von Konkordanzen und Frequenzlisten. McEnery und Wilson
(1996) definieren eine Konkordanz folgendermaßen:
[...] a comprehensive listing of a given item in a corpus (most often a
word or phrase), also showing its immediate context.
(McEnery und Wilson 1996, S. 177)
Konkordanzen waren schon seit langer Zeit bekannt und wurden traditionell für besonders wichtige Werke der Literatur (Bibel, Shakespeare etc.) manuell erstellt, um
Textstellen besser finden zu können. Sinclair (1991, S. 170) definiert eine Konkordanz deshalb auch allgemein als einen Index zu den Wörtern eines Textes. Durch
die Verwendung von Computern hat sich eine Konvention der Konkordanzdarstellung
durchgesetzt, die KWIC (Key Word In Context) genannt wird. Diese Art der Darstellung entspricht in etwa der Definition von McEnery und Wilson. Hierbei ist das
Schlüsselwort zentriert gedruckt; zudem wird der folgende und vorangehende Kontext
des Wortes angezeigt und auf die betreffende Textstelle verwiesen.
Die ersten Programme erstellten diese Konkordanzen noch durch Ausdruck aller
Fundstellen eines Schlüsselwortes in einem Korpus. Diese Praxis wurde auch 1980 bei
der Erstellung der Konkordanzen des Main Corpus des später BOE genannten Korpus
angewandt. Aufgrund der ungeheuren Datenmenge der auf 7,3 Millionen laufenden
Wortformen basierenden erstellten Konkordanzen wurden die Ausdruck dann auf Mikrofiche archiviert. Diese Konkordanzen dienten als Arbeitsgrundlage zur Erstellung
✆❅☛
des COBUILD Dictionary, des ersten Wörterbuchs, dessen Beispielsätze komplett aus
»real existierenden« Texten stammten.
➷⑤④ ✙ ④ ③
➱❫✪✡✘✔❘✔✪✂✓✖❀✂✑✡✘✔á✜❱✂✓✖✪✡✕✗✓✖✑✡✥✦✥✦✧
Eine Weiterentwicklung sind die mit der Verbreitung des PC erhältlich gewordenen
interaktiven Konkordanzprogramme. Diese Programme erstellen die Konkordanzen
durch Durchsuchen der Korpustexte für jede Suchanfrage neu und geben das Ergebnis
auf dem Bildschirm aus. Der Ausdruck der Konkordanzen auf Papier ist dadurch nicht
mehr notwendig. Hofland (1991) gibt einen guten Überblick über frühe Konkordanzprogramme für PC, in Müller (1993) findet sich ein sehr detaillierter Vergleich der vier
Programme TEXTPACK PC, Micro-OCP (dieses Programm basiert auf der Software,
die zur Erstellung der COBUILD-Konkordanzen verwendet wurde), Konkordtext und
WordCruncher.
Alle Programme bieten ungefähr die gleichen Grundfunktionen:
➴ Erstellen von Konkordanzen anhand einer Suchanfrage
➴ Sortieren der Konkordanzzeilen nach bestimmten Sortierkriterien (z. B. nach
erstem oder zweiten Wort vor oder nach dem Schlüssselwort)
➴ Durchsuchen von mehreren Korpustexten
➴ Erstellen von Frequenzlisten
➴ Erstellen von Wortstatistiken
Das am weitesten verbreitete Programm ist WordCruncher. WordCruncher besteht aus
einem Indizierungs- und einem Retrieval-Programm. Alle Korpustexte, die untersucht
werden sollen, müssen hierbei vor der Analyse indiziert werden. Die weite Verbreitung des Programmes zeigt sich daran, daß das ICAME1 in Bergen eine CD-ROM mit
Korpora vertreibt, die bereits für WordCruncher vorindiziert sind (zu den enthaltenen
Korpora gehören auch LOB und Brown).
Weitere Beispiele für frühe Konkordanzprogramme sind Micro Concord und MonoConc for Windows (wie bei WordCruncher auch handelt es sich hierbei um kommerzielle Produkte). MonoConc enthält zusätzlich die Möglichkeit, eine Kollokationsanalyse auf Basis der erstellten Konkordanzzeilen durchführen zu lassen, führt aber (wie
auch Micro Concord) keine Vorindizierung der Texte durch, so daß diese bei jeder
Suchanfrage komplett durchlaufen werden müssen.
Die Zielgruppe dieser Konkordanzprogramme stellen hauptsächlich Sprach- und Literaturwissenschaftler dar, die den Computer als Hilfsmittel verwenden, um Texte effizient nach bestimmten Kriterien durchsuchen zu können. Die Hauptanwendung ist
demnach das Ausgeben von Belegstellen für wissenschaftliche Arbeiten. Für größere
Korpora sind diese Systeme nur bedingt geeignet (die Programme werden typischerweise für Korpora bis zu einer Million laufender Wortformen eingesetzt, obwohl moderne Programme wie WordCruncher größere Datenmengen verarbeiten können). Zudem fehlen Möglichkeiten, Korpusannotationen unabhängig vom Text abzuspeichern.
Die einzige Möglichkeit der Speicherung von Annotationen besteht darin, diese an
die Wortformen anzuhängen (z. B. »schöne_ADJ« zur Markierung der Wortform als
1
International Computer Archive of Modern English
✆❅➺
Adjektiv). Da es sich zudem meist um geschlossene Systeme handelt, ist ein Zugriff
auf die Korpusdaten von anderen Programmen aus nicht möglich. Zusammenfassend
läßt sich also sagen, daß Konkordanzprogramme für den Einsatz in der computerlinguistischen Forschung nur sehr bedingt geeignet sind.
➷⑤④ ✙ ④ ➷
➱❫✪✡✓✖❱☎✣✔❊✟❀✂✑❅❋▲✧✡✘✔✰☎✑✡✘✔❘✔✧✡✘
Durch die Verfügbarkeit immer größerer Korpora und das Aufkommen der auf den
Korpusdaten basierenden computerlinguistischen Forschung werden also neue Anforderungen an die Software gestellt. Die Grundanforderungen ergeben sich dabei aus
den Schwachstellen der oben dargestellten Konkordanzprogramme:
➴ Speicherung von und Zugriff auf mehrere Korpora
➴ keine Beschränkung der Größe eines Korpus
➴ Speicherung beliebiger Annotationen zu den Korpustexten
➴ Suche nach beliebigen Wörtern und Annotationen
➴ Zugriff auf die Korpustexte über eine Programmierschnittstelle (API)
Damit mehrere Benutzer gleichzeitig mit dem Daten arbeiten können, ist eine Implementierung sinnvoll, die es ermöglicht, über ein Netzwerk auf die Korpora zugreifen
zu können. Um eine effiziente Bearbeitung von Suchanfragen gewährleisten zu können, ist außerdem eine Indizierung aller Wörter der Texte notwendig. Systeme, die
diese Anforderungen erfüllen, sollen als Korpusdatenbanken bezeichnet werden. Im
folgenden sollen drei State-of-the-art-Systeme zum Zugriff auf Korpora verglichen
werden.
➴ SARA (SGML-Aware Retrieval Application): wurde zum Zugriff auf das BNC
erstellt.
➴ COSMAS: dient am IDS zum Zugriff auf die dort gespeicherten Korpora.
➴ IMS Corpus Workbench: wurde am IMS in Stuttgart von Oliver Christ entwickelt.
Alle drei Systeme basieren auf einer Client/Server-Architektur. Die Korpusdaten werden zuerst indiziert und in Datenstrukturen abgelegt. Suchanfragen werden über eine
eigene Anfragesprache formuliert.
➷⑤④ ✙ ④ ➷⑤④ ✙⑦➮✜❃✤⑥✔❃
Das Programm SARA nimmt unter den drei zu vergleichenden Programmen eine Sonderstellung ein, da hier die Ausrichtung auf ein einziges Korpus (BNC) vorgegeben
ist. Obwohl das Akronym SARA ein allgemeines Programm zur Verarbeitung von
SGML-kodierten Korpora erwarten läßt (siehe hierzu Kapitel 4.1), ist das System genau auf die spezielle Art der Kodierung des BNC ausgelegt. Eine Verarbeitung von
»Fremddaten« ist damit leider ausgeschlossen. Die einzige Annotation, die von SARA unterstützt wird, ist der Zugriff auf die Tagging-Information des BNC.
✆ ➘
SARA unterstützt Verwaltung und Zugriff auf die bibliographischen Daten über eine
eigens definierte Datenbankschnittstelle. Außerdem ist eine Definition von benutzerspezifischen Subkorpora, z. B. auf Basis einer Auswahl aus dem Klassifikationsschema, möglich. Alle Aktionen sind über ein Netzwerkprotokoll definiert.
➷⑤④ ✙ ④ ➷⑤④ ③
❚✫â✼➮⑤ã❖❃✤➮
COSMAS wird am IDS in Mannheim zum Zugriff auf die dort verfügbaren Korpora
eingesetzt. Das System erlaubt eine beliebige Auswahl der zur Verfügung stehenden
Korpora. Die Ergebnisse einer Suchanfrage können in verschiedenen Stufen angezeigt
werden. Auf der untersten Stufe wird dabei nur eine statistische Übersicht über die
Fundstellen geliefert. Die zweite Stufe bietet eine Darstellung der Konkordanzen im
KWIC-Format. In der dritten Stufe können einzelne Fundstellen in größerem Kontext
angezeigt werden und es ist eine genaue Quellenangabe abrufbar.
Das zur Zeit [1997, Anm. d. Hrsg.] verfügbare System bietet keine Möglichkeit, linguistische Informationen wie z. B. die Wortklasse einer Wortform mit abzufragen. Integriert ist allerdings ein Lemmatisierungsprogramm, das Wortformen auf ihre Grundform zurückführen und Komposita zerlegen kann. Zusätzlich zu den üblichen Konkordanzen können auch Kollokationsanalysen einzelner Wörter sowie Frequenzlisten
erstellt werden.
➷⑤④ ✙ ④ ➷⑤④ ➷
❚✫✪✡✓✖❱✂✣✔❊✤äå✪✡✓✖❘✔✰☎✧✡✘✔❁✔✒
Die Corpus Workbench wurde am IMS (Institut für Maschinelle Sprachverarbeitung)
von Oliver Christ erstellt und wurde auch im Hinblick auf die computerlinguistische
Anwendung programmiert. So ist z. B. eine Schnittstelle zu dem in Stuttgart verwendeten Grammatikformalismus STUF integriert. Außerdem wurde eine Einbindung der semantischen Datenbank WORDNET vorgenommen, wodurch Suchanfragen auch mit semantischen Bestimmungen möglich sind. Enthalten sind zudem eine
Anzahl von Tools, die den direkten Zugriff auf die Korpusdaten ermöglichen. Die
IMS Corpus Workbench wird an einigen Universitäten erfolgreich zur Speicherung
und zum Zugriff von sehr großen Korpora eingesetzt.2 Ein Schwachpunkt liegt in der
fehlenden Möglichkeit, einzelne Texte eines Korpus auswählen zu können. Auch die
Angabe von bibliographischen Informationen zu den Texten ist nicht möglich.
➷⑤④ ✙ ④ ➷⑤④ ❰
✩✫✧✂✓✖✕☎✬ ✧✡✿ ❁✔✒
Die üblichen Funktionen der Konkordanzprogramme werden von allen drei Systemen
abgedeckt. Hierzu zählen die Sortierung der Konkordanzen nach verschieden Kriterien, die Anzeige eines größeren Kontextes der Konkordanzzeile und das Erstellen von
Frequenzlisten. Die Stuttgarter Corpus Workbench ist dabei am ehesten als offenes,
für Programmierer zugängliches System konzipiert, was sich auch in dem möglichen
direkten Zugriff auf die Korpusdaten und in der Speicherung von beliebigen Annotationen zeigt. SARA bietet gute Möglichkeiten des Zugriffs auf zusätzliche Textinformationen und einen großen Funktionsumfang, ist aber auf die Daten und Kodierung
des BNC beschränkt. Das COSMAS-System erlaubt eine flexible Auwahl mehrerer
Korpora zur gleichzeitigen Bearbeitung und unterstützt die Erstellung von Statistiken
2 Das System wird z. B. an der Universität Lancaster zusätzlich zu SARA eingesetzt, um auf das BNC
zuzugreifen.
✆ ✃
zur Kollokationsanalyse. Zudem steht ein großer Umfang an zusätzlichen Funktionen
zur Verfügung, leider aber keine linguistische Annotation der Daten.
Ein optimales System müßte die Vorteile der drei vorgestellten Programme miteinander verbinden. So sollten Möglichkeiten gegeben sein, bibliographische Angaben zu
Texten zu speichern und einzelne Texte und Korpora beliebig auswählen zu können.
Eine Kategorisierung der Texte wie in das Kategorieschema des BNC sollte möglich sein und das System sollte offen konzipiert sein, beliebige Annotationen sowie
einen Zugriff über eine Programmierschnittstelle unterstützen. Optimalerweise sollte
zusätzlich noch die Integration von SGML-kodierten Texten unterstützt werden.
Bei der Erstellung von CORSICA wurde versucht, diese Anforderungen so weit wie
möglich zu erfüllen. Die allgemeine Zielsetzung war dabei nicht, ein benutzerfreundliches Konkordanzprogramm zu erstellen, sondern ein Werkzeug zu entwickeln, das
erweiterbar ist und insbesondere bei der automatischen Analyse von Korpusdaten von
Nutzen sein kann.
✈ ✌
Bevor die Texte eines Korpus in einer Korpusdatenbank gespeichert werden können
sind einige Schritte notwendig, um die Daten in ein einheitliches Format zu bringen.
Entscheidend dafür ist die Kodierung der Korpustexte. Prinzipiell kann man zwischen
zwei Arten von Daten unterscheiden:
1. Die Texte sind Teil eines offiziell erstellten Korpus. In diesem Fall kann davon
ausgegangen werden, daß die Daten bereinigt sind und in einer Form vorliegen,
die eine einfache Speicherung ermöglicht.
2. Die Texte sind kein Teil eines erstellten Korpus, sondern stammen aus verschieden Quellen (CD-ROM, Internet, OCR etc.).
In letzterem Fall ist es zuerst notwendig, softwarespezifische Markierungen in den
Texten zu entfernen. Außerdem ist es sinnvoll, soweit dies noch nicht geschehen
ist, bestimmte Texteinheiten wie z. B. Abschnitte oder Überschriften einheitlich zu
kennzeichnen. Wird dieser Arbeitsschritt unterlassen, so besteht die Gefahr, daß die
vorherige Form eines Textes nicht mehr zu erschließen ist und die Daten für eine spätere Analyse unbrauchbar werden. Außerdem sollten die bibliographischen Angaben
zu jedem Text erfaßt werden. Ohne Angabe der bibliographischen Daten sind die
gefundenen Belegstellen bei der Suche in einem Korpus nicht auf eine Quelle zurückzuführen und werden deshalb für wissenschaftliche Publikationen unbrauchbar, da
sie nicht überprüft werden können. Für die Form der Kodierung dieser zusätzlichen
Informationen bietet sich der internationale Standard SGML (Standard Generalized
Markup Language, siehe Goldfarb und Rubinsky 1990) an, der auch in der Praxis
häufig verwendet wird, um Korpustexte zu kodieren.
æ❯❪❴❭❛ç✯q❙èêé
Bei SGML handelt es sich um eine Sprache zur Definition von Auszeichnungssprachen. Der Standard (ISO 8879:1986) wurde entwickelt, um eine systemunabhängige,
maschinenlesbare und genau festgelegte Auszeichnung von Daten vornehmen zu können. SGML-Dokumente bestehen dabei aus zwei Teilen: einer DTD (Document Type
✈ ✆
Description), in welcher die Art und Weise der Markierung und die möglichen Markierungen definiert sind und einem Text, der in dieser DTD kodiert ist. Mit Hilfe
eines SGML-Parsers läßt sich dann bestimmen, ob die Kodierung eines Textes einer
bestimmten DTD entspricht.
Ein SGML-Text besteht aus Elementen, die in der DTD definiert werden. Jedes Element kann wiederum eine genau definierte Anzahl von Elementen und Attributen enthalten. Auf diese Weise entsteht ein hierarchischer Baum von möglichen Elementen,
die im Text jeweils durch ein Start-Tag und ein Ende-Tag dargestellt werden.1 Innerhalb dieser Markierungen stehen die eigentlichen Daten des Textes. Deshalb ist es
jederzeit wieder möglich, die Markierungen eindeutig zu entfernen.
SGML bietet sich für die Kodierung von Korpora an, da hierbei eine Systemunabhängigkeit und eine Austauschbarkeit der Daten von großer Wichtigkeit ist. Sollen
Korpustexte an Dritte weitergegeben werden, so ist durch die Verwendung von SGML
als Austauschformat eine problemlose Weiterverwendbarkeit der Textdaten sichergestellt. Inzwischen existieren einige komplett in SGML kodierte Korpora wie das BNCKorpus oder einige von der ECI (European Corpus Initiative) vertriebene CD-ROM
mit Texten aus verschiedenen europäischen Sprachen.
æ❯❪ ♣rß✫ë✼ì
Da SGML nur eine Beschreibungssprache für Auszeichnungssprachen darstellt, ist es
jedem Benutzer von SGML freigestellt, sich seine eigene Kodierung zu definieren.
Demzufolge ist auch nicht festgelegt, welche Elemente verwendet werden und welche
Einheiten eines Textes überhaupt kodiert werden. Die Text Encoding Initiative (TEI)
hat es sich zur Aufgabe gemacht, eine Sammlung von Richtlinien zur Kodierung beliebiger Texte in SGML Sperberg-McQueen und Burnard 1994 vorzudefinieren. Im Kern
bestehen diese Richtlinien aus einer Anzahl von DTD für die verschiedensten Texttypen, sowie einer DTD mit einer Menge an Grundelementen (base tagset), die für alle
Texte gleich sind. Obwohl in den TEI-Richtlinien sehr genaue Angaben zur Kodierung von Texten gemacht werden und die DTD der TEI für diese Kodierung verwendet
werden können, ist es trotzdem möglich, die DTD durch Erweiterung oder Modifizierung auf die eigenen Bedürfnisse anzupassen. Es handelt sich demnach nicht um ein
festgeschriebenes Regelwerk zur Textauszeichnung, sondern um flexible Richtlinien,
die von jedem Benutzer anders angewendet werden können. Diesem Zustand wird
schon allein durch den enormen Umfang Rechnung getragen: Die gedruckte Fassung
der TEI-Richtlinien umfaßt über 1 300 Seiten und die Anzahl der in den DTD definierten Elemente übersteigt 400.
Ein Text besteht gemäß der TEI-Richlinien aus zwei Teilen: einem TEI-Header und
dem eigentlichen Text. Im Header wird dabei Information über den erfaßten Text
kodiert. Dazu zählen die kompletten bibliographischen Daten des Textes, der elektronische Titel und optionale Angaben wie die Art der Kodierung, Information über
die verwendeten Tags oder Angaben zur Einordnung des Textes in ein vorher definiertes Klassifikationsschema (siehe Kapitel 5.3). Erst nach diesem ausführlichen
1 Je nach Definition des Elements in der DTD können Start-Tag und/oder Ende-Tag auch weggelassen
werden (tag minimization).
✈✡✈
TEI-Header-Element (welches zu den komplexesten Elementen der TEI-DTD gehört)
folgt der eigentliche Text.
❰⑤④ ③⑤④ ✙⑦➱❫✪✡❀☎✿ ✧✂✓✖✣✔✘✔✕☎❊✟✑✡✓⑩❋▲✧✡✘
Aus oben genannten Gründen gibt es verschiedene Möglichkeiten der Kodierung von
Texten bei der Verwendung der TEI-Richtlinien. Die EAGLES-Forschungsgruppe
(vgl. Ide und Veronis 1994) hat allgemeine Richtlinien für die Kodierung von Korpora aufgestellt und richtet sich dabei nach den Vorgaben der TEI. Obwohl die TEIRichtlinien ein eigenes Kapitel über die Kodierung von Korpora enthalten, gibt es
wie auch bei normalen Texten mehrere Möglichkeiten der Anwendungsweise. Die
EAGLES-Gruppe definiert deswegen vier verschiedene Ansätze, die sich im Grad der
Genauigkeit der Auszeichnung unterscheiden.
➴ Typ 3: Die Textdaten werden mit einer linguistischen Analyse versehen. Hierbei kann es sich z. B. um morphosyntaktische, syntaktische oder prosodische
Information handeln.
➴ Typ 2: Es werden innerhalb von Abschnitten Auszeichnungen vorgenommen.
Dabei kann es sich um die Auszeichnung von Sätzen, Namen, Zitaten, Wörtern
etc. handeln.
➴ Typ 1: Es werden verschiedene Textelemente bis hinunter zur Ebene eines Abschnittes ausgezeichnet.
➴ Typ 0: Es werden bibliographische Informationen über den Text und seinen
Inhalt ausgezeichnet.
Jeder Typ enthält dabei auch alle Auszeichnungen aller darunterliegender Typen. Bei
kodierten Texten muß also zwischen den verschiedenen Auszeichnungsvarianten unterschieden werden, um die Daten einheitlich in der Korpusdatenbank speichern zu
können. So ist bei der maximalen Auszeichnung bereits jedes Wort mit einem eigenen Tag ausgezeichnet, so daß die Bestimmung der Wortgrenzen (siehe Kapitel 4.3)
entfällt. Das BNC wurde nach den Richtlinien der TEI kodiert und ist ein Beispiel für
diese maximale Auszeichnung.
Ein Beispiel für eine Kodierung erster Stufe stellt die von der European Corpus Initiative (ECI) herausgegebenen Korpus-CD-ROM dar. Hier wurden bei den Texten
nur Absätze und Unterteilungen (Kapitel, Unterkapitel etc.) ausgezeichnet. Diese
Variante enthält demnach noch keine Bearbeitung der Textdaten auf Wort- und Satzebene. Eine minimalste Auszeichnung von Texten (Typ 0) ist auch bei »rohen« Textdaten relativ unproblematisch einzufügen – gemäß der TEI-Richtlinien genügt eine
Markierung des Anfangs und Endes des Textes sowie die Erfassung der allgemeinen
Textinformationen.
❰⑤④ ③⑤④ ③
⑧❆✧✡❀☎✧✡✣✻❋▲✣✔✘✔✕➦▼à■✔✓❖❀✂✿ ✧❦✩✫✧✡✓✖✑✂✓✖✰✂✧✡✿ ❋▲✣✔✘✔✕❦❉✗✪✡✘ Ø ✧✟❄➑❋▲❀☎✑❅❋▲✧✡✘
SGML stellt in Verbindung mit den TEI-Richtlinien den einzigen Quasistandard zur
Auszeichnung von beliebigen Texten dar. Aus diesem Grund sind z. B. alle Texte des
Oxford Text Archive (OTA) nach den TEI-Richtlinien kodiert. Sollen Texte beliebigen
Benutzern zur Verfügung gestellt werden, so kann durch die Verwendung von SGML
✈ ✠
und den TEI-Richtlinien sichergestellt werden, daß die Daten auf jedem Computersystem verwendet und die Kodierungen von jedem Benutzer verstanden werden können.
Bei der Speicherung von Texten in der Korpusdatenbank scheint es deswegen sinnvoll,
diese Art von Textauszeichnung zu unterstützen. Die Markierungen sollten dabei automatisch erkannt und gesondert behandelt werden. Der hier verfolgte Ansatz geht
davon aus, daß die SGML-Markierungen Teil des Textes sind und zusammen mit dem
Text abgespeichert werden. Auf diese Weise kann bei einer Suchanfrage auch nach
SGML-Tags gesucht werden (z. B. um den Inhalt eines bestimmten Elements zu finden) oder die Markierungen können wahlweise ignoriert werden. Der TEI-Header
wird dabei gesondert behandelt und zählt nicht als Teil der Textdaten (siehe 5.1).
Texte, die nicht in SGML kodiert wurden, oder Texte, die nur auf den unteren Stufen
kodiert wurden (Absatz- und Überschriftenmarkierung), müssen vor der Speicherung
in der Datenbank noch tokenisiert werden, da hier noch keine Bestimmung der Tokens
auf der Wortebene stattgefunden hat.
æ❯❪ Ðrß✫②€Û€❝✫t❣❜➣❺✂❜➣❝€✐✮s❣t€✉
Unter Tokenisierung von Texten versteht man die Unterteilung des Textes in Tokens,
d. h. die Ermittlung der Einheiten eines Textes. Auf der untersten Ebene besteht ein
Text aus einer Abfolge von Zeichen. Der erste Schritt der Textanalyse besteht demnach in der Bestimmung der Wortgrenzen. Dieser Schritt ist notwendig, da in der
Korpusdatenbank einzelne Wörter gespeichert und gesucht werden sollen, und jede
linguistische Analyse der Textdaten auf der Wortebene startet. Praktisch gesehen handelt sich es also um die Entscheidung, was unter orthographischen Gesichtspunkten
als Wort bezeichnet werden kann. Hierzu zählt z. B. das Abtrennen von Satzzeichen,
das Erkennen von Zahlenangaben und das Rückgängigmachen von Trennungen am
Zeilenende.
Obwohl die Aufbereitung der Textdaten im strengen Sinne keine Aufgabe der Korpusdatenbank ist, wurde trotzdem ein Programm zur Tokenisierung für CORSICA
entwickelt. Dies geschah zum Teil aus praktischen Gründen, da die Tokenisierung die
Grundlage für eine Speicherung von Texten bildet und es keinen Sinn macht, große
Mengen von Korpusdaten zu speichern, die sehr fehlerhaft oder nur teilweise tokenisiert sind. Ein anderer Grund liegt in der damit erreichten Unabhängigkeit von anderen
Tokenisierern und möglichen Fremdformaten.
Die einfachste Methode der Tokenisierung, die von vielen Systemen angewendet
wird, besteht im Schreiben eines Skripts, das aufgrund von definierten regulären Ausdrücken den Eingabe-Strom in Tokens unterteilt. Diese Art der Tokenisierung hat
den Nachteil, daß das daraus resultierende Skript meist unübersichtlich wird und nur
schlecht verändert werden kann, da die möglicherweise auftretenden Nebeneffekte
nicht immer abzuschätzen sind. Außerdem ist dadurch eine Anpassung an verschiedene nationale Schreibvarianten (so existieren z. B. in deutschen und englischen Texten
unterschiedliche Konventionen bei Zahlenangaben) nur sehr schwer möglich.
✈ ✞
❰⑤④ ➷⑤④ ✙⑦ã❧✪✡❀☎✣✔✬ ✑✡✓✖✧✂✓⑤❃✤✘✔❊✟✑❅❋▲á
Der hier verwendete Ansatz besteht deshalb aus einem modularen System, bei dem jedes Modul nur einen Arbeitsschritt ausführt. Auf diese Weise werden einige Nachteile
des Ein-Skript-Modells eliminiert. Der Benutzer kann nun durch gezielte Auswahl
der Module selbst bestimmen, welche Arten der Tokenisierung durchgeführt werden
sollen. Dadurch ist eine Anpassung an teilweise tokenisierte Texte möglich. Zudem
ist jedes Modul einfacher auf verschiedene Textformate und Schreibvarianten abzustimmen. So ist z. B. bei der Anpassung auf ein anderes System zur Darstellung von
Zahlen nur das Modul zu verändern, welches die Erkennung von Zahlenangaben zur
Aufgabe hat.
Nachfolgend sollen die einzelnen Schritte der Tokenisierung besprochen werden. Die
erstellten Module sind dabei nicht vollständig voneinander unabhängig, sondern basieren in einigen Fällen auf vorhergehenden Schritten. Außerdem muß die Reihenfolge, in der die Module aufgerufen werden, eingehalten werden. Der Grundgedanke
der Tokenisierung ist dabei, die Daten des Textes nicht zu verändern. Der Text sollte
nach der Tokenisierung in Tokens unterteilt sein, aber keine zusätzliche Information enthalten, da die Analyse der Daten eine Aufgabe des Taggers und der auf der
Tagging-Analyse aufbauenden Programme ist und mehrere konkurrierende Analysen
eines Textes möglich sein sollen.
Es wird davon ausgegangen, daß die zu verarbeitenden Texte keine Kodierungen außer
SGML-Tags enthalten. Softwarespezifische Kodierungen müssen vor der Tokenisierung mit speziellen Filterprogrammen entfernt werden.
❰⑤④ ➷⑤④ ✙ ④ ✙⑦❍☎✘✻❋❈▼✖✧✡✓✖✘✔✧✡✘❦❉☎✪✡✘Ñäå✒✔✿ ❋▲✧✡❊✟❱☎✑✡❁✔✧
Im ersten Arbeitsschritt werden die sogenannten whitespace characters entfernt. Dazu
zählen Tabulatoren, Leerzeichen und Zeilenumbrüche. Außerdem werden Zeichenketten, die am Ende einer Zeile mit dem Zeichen »–« enden, markiert, um zu einem
späteren Zeitpunkt mögliche Trennungen am Zeilenende rückgängig machen zu können. Zudem werden SGML-Tags erkannt und wie eine einzige Wortform behandelt,
um zu verhindern, daß eine Tokenisierung dieser Auszeichnungen stattfindet. In der
Ausgabe ist jedes zu diesem Zeitpunkt erkannte Token durch einen Zeilenumbruch
getrennt. Diese Trennung der Tokens wird von allen anderen Modulen erwartet und
auch so weitergegeben.
❰⑤④ ➷⑤④ ✙ ④ ③⑦Ø ✓✖✧✡✘✔✘✔✧✡✘❦❉☎✪✡✘Ñäåí✡✓⑩❋▲✧✡✓✖✘
Im Trennmodul werden zusammengeschriebene Alternativen mehrerer Wörter getrennt. In deutschen Texten ist dies bei Angabe zweier durch einen Schrägstrich
getrennter Möglichkeiten der Fall (z. B. und/oder, Artikel/Nomen/Verb, CDU/CSU,
Feldberg/Schwarzwald). Dabei werden folgende Ausnahmen gemacht:
➴ Besteht eines der beiden Wörter oder beide Wörter aus nur einem Buchstaben,
so wird keine Trennung vorgenommen, da dies fast ausnahmslos nur bei Maßeinheiten der Fall ist (z. B. km/h, m/s). Eine Trennung dieser Angaben würde
für die Analyse in der Morphologie bedeuten, daß die einzelnen Buchstaben
als Wörter aufgenommen werden müßten, was die Ambiguität der morphologischen (Teil-)Analysen stark erhöhen würde.
✈ ✍
➴ Mit Schrägstrich geschriebene Zahlen werden nicht getrennt. Dies betrifft z.B
Jahreszahlen, Brüche oder Quellenangaben (WS 1970/71, Nr. 36/1970, 1/4
Hilfskraftstelle).
Die Ausgabe erfolgt wieder getrennt durch Zeilenumbrüche.
❰⑤④ ➷⑤④ ✙ ④ ➷
❃✤✰✟❋▲✓✖✧✡✘✔✘✔✧✡✘Ñ❉☎✪✡✘◗➮⑤✑❅❋▲á✮á✮✧✂✿ ❁✔✒✔✧✡✘
Als nächstes werden Satzzeichen abgetrennt. Das Skript unterscheidet dabei Satzzeichen, die jeweils nur am Anfang bzw. Ende eines Wortes vorkommen können. Jedes
Satzzeichen (Komma, Semikolon, Fragezeichen, Anführungszeichen etc.) wird dabei
als eigenständiges Token ausgegeben. Punkte am Ende eines Wortes werden zu diesem Zeitpunkt nicht abgetrennt, da zur Entscheidung über die Abtrennung von Punkten erst eine vollständige Tokenisierung notwendig ist. Die Punktdisambiguierung ist
deshalb ein eigener, komplexer Arbeitsschritt, der in Sektion 4.3.1.6 beschrieben wird.
❰⑤④ ➷⑤④ ✙ ④ ❰
⑥❫■✔❁✔❘✔✕✗●✡✘✔✕✗✿ ✕✗✥✦✑✡❁✔✒✔✧✡✘❖❉☎✪✂✘ Ø ✓✖✧✂✘✔✘✔✣✔✘✔✕☎✧✡✘◗✑✡✥
Ï ✧✡✿ ✬ ✧✡✘✔✧✡✘✔❀☎✧
In diesem Arbeitsschritt werden die im ersten Schritt eingefügten Trennungsmarkierungen analysiert. Bei einem Trennungszeichen am Zeilenende können folgende Phänomene vorliegen:
➴ Silbentrennung (ver-|suchte, Ein-|bruch).
➴ Trennung eines mit Bindestrich geschriebenen Wortes (römisch-| katholisch,
Kripo-|Inspektionsleiter).
➴ Der Bindestrich ist ein Ergänzungszeichen. Dies tritt bei zusammengesetzten Wörtern, bei denen ein gemeinsamer Teil nur einmal genannt wird,
auf (z. B. Advents-|und Weihnachtskonzert, Mund-|oder Kieferbereich, Aktien|beziehungsweise Immobilienmarkt).
Durch die Verbesserungen der Textverarbeitungssoftware existieren heute nur noch
selten Texte, in denen die Silbentrennung nach der Ausgabe in einem Übertragungsformat noch vorhanden ist. Ist dies dennoch der Fall, so ist eine morphologische Analyse des getrennten Wortes sinnvoll, da ansonsten nicht zwischen getrennten Wörtern
und solchen Wörtern, die mit einem Bindestrich geschrieben werden, unterschieden
werden kann. Da dem Autor keine Texte mit Silbentrennung vorlagen, wurde auf eine
Behandlung der Silbentrennung verzichtet. Die Integration von MALAGA und der
deutschen Morphologie wäre jedoch durch die von MALAGA zur Verfügung gestellten Bibliotheksfunktionen unproblematisch.
Notwendig ist allerdings die Unterscheidung zwischen einem Bindestrich als Ergänzungszeichen und einem Bindestrich innerhalb eines Wortes. Zuerst wird deswegen
getestet, ob das nachfolgende Wort mit einen Buchstaben oder einer Zahl beginnt. Ist
dies nicht der Fall, so liegt mit hoher Wahrscheinlichkeit keine Trennung eines Wortes vor und beide Wörter werden als eigenständige Tokens ausgegeben (z. B. Haupt/ Ecke Zeilsheimer Straße). Andernfalls wird geprüft, ob das folgende Wort ein Wort
ist, welches häufig zwischen dem Ergänzungszeichen und dem ergänzten Wort steht.
Zu diesem Zweck wurde halbautomatisch aus einem Teil der deutschen Daten der
ECI-CD-ROM2 eine Liste von Wörtern erstellt, die diese Eigenschaft erfüllen (sie2
Es handelt sich dabei hauptsächlich um Texte des Donau-Kuriers und der Frankfurter Rundschau mit ca.
13 Millionen laufenden Wortformen.
✈ ☛
he Tabelle 4.1). Wird das folgende Wort in dieser Liste gefunden, so werden beide
Wörter als eigenständige Tokens ausgegeben. Ist das Wort nicht enthalten, so werden
beide Wörter verbunden und als ein Token ausgegeben.
➃❻➄❩➅✡➆❴➇ ➇➉➆❫î✜➋ ➌✖➍➧➚♥➅❅➛✜➓❻➇ ➟ ➏ ➆❣ï✔ð ➟▲ñ ➒✟➐✮➆➈→➉➏✡↕❅➆❴➔
ò❤ó❻➔à➏ ➆➈➔⑤Ó✮➝♥→ ➛✜➨❴➩✜➆❴↔✯Õ♥➔❞➒✟ð❬↔▲Ó ➟ ↔▲➒✟➛❩Ó✮➆❴→➉➨➪➩✜➆➈↔
➟ ↔✜↕ô➆➈➔❞➒✟ð❩↔❩Ó✮➏ ➆➈➼õò❤➓➈➔à➏
15 729
626
324
304
69
62
53
47
33
25
22
16
14
12
❰⑤④ ➷⑤④ ✙ ④ ö
und
oder
bis
u.
bzw.
als
in
sowie
wie
noch
beziehungsweise
zum
auf
statt
Ï ✣✔❊✟✑✡✥✦✥✦✧✡✘✻▼✖■✔✒✔✓✖✧✡✘ô❉☎✪✂✘ Ï ✑✂✒✔✬ ✧✡✘
In diesem Modul werden Zahlen, die aus mehr als drei Ziffern bestehen und im Originaltext mit Leerzeichen geschrieben wurden wieder zu einer Zahl zusammengeführt
(z. B. 20 000, 4,334 035, 1 244,333 12). Wichtig ist dabei eine genaue Definition
der erlaubten Zahlenmuster, damit in Zahlenabfolgen wie z. B. »... beschäftigte 1968
757 230 Personen ...« die Jahreszahl nicht mit verschmolzen wird. Eine fehlerhafte
Tokenisierung kann sich hierbei bei einem Aufeinandertreffen zweier unterschiedlicher Zahlenangaben ergeben. Im LIMAS-Korpus, das zu Testzwecken diente, wurde
allerdings kein solcher Fall gefunden. Wäre allerdings in oben genanntem Beispiel
eine dreistellige Jahreszahl aufgeführt worden (z. B. »... beschäftigte 878 757 230
Personen ...«), würde diese mit den anderen Zahlen zusammengeführt. Die dadurch
entstehende Fehlerquote dürfte allerdings zu vernachlässigen sein.
❰⑤④ ➷⑤④ ✙ ④ ÷
➬✫✿ ❊✟✑✡✥✦✰☎✿ ✕✗✣✔✿ ✧✂✓✖✣✔✘✔✕➦❉☎✪✡✘ Ù ✣✔✘✔❘✻❋▲✧✡✘
Der letzte und komplexeste Schritt der Tokenisierung besteht im Disambiguieren von
Punkten am Wortende. Es kann sich dabei um einen Satzpunkt, einen Abkürzungspunkt, den Punkt einer Ordinalzahl oder um Satzpunkt und einen der beiden anderen
Fälle gleichzeitig handeln. Zum Treffen einer Entscheidung ist daher das Erkennen
von Abkürzungen notwendig. Zu diesem Zweck wurde aus den Korpora des IDS (die
schon vollständig tokenisiert sind) eine Liste der 200 häufigsten deutschen Abkürzungen erstellt (siehe Tabelle 4.2).
Da die Bildung von Abkürzungen produktiv ist, können nie alle Abkürzungen im Lexikon enthalten sein. Aus diesem Grund wurde eine zusätzliche Liste von Suffixen erstellt, die niemals am Ende eines nicht abgekürzten Wortes auftreten können: Mit dem
Suffix -tr werden alle Straßenangaben (z. B. Glückstr., Oskar-von-Miller-Str.) und Abkürzungen von »Zentrum« (Notdienstzentr., Seniorenzentr. etc.) als Abkürzungen erkannt. Durch das Suffix -pl werden abgekürzte Namen von Plätzen erkannt. Auf -lich
endende abgekürzte Wörter werden durch -tl als Abkürzungen identifiziert und -br erkennt Abkürzungen von Kombinationen mit den Worten »Fabrik« und »Brauerei«/» bräu«. In den zur Verfügung stehenden Korpora wurden dabei keine Fälle gefunden,
✈ ➺
➃❻➄❩➅✡➆❴➇ ➇➉➆❫î✜➋ ➊✮➍➧❮✔→➉➆❖➌✮×❤➩❩ð ➟▲ñ ➒✟➛➑➏ ➆➈↔
➚♥➅❅➐✮ø❈➔➣Ó ➟ ↔▲➒✂➆➈↔❯→ ↔➦↕❅➆➈↔✤❒ ❮❫➵▲➞ ➢✗➓❻➔➣➤✔➓❻➔➣➄❩➳✟➼✼→➉➏
➄❬➅❅➛✜➓❻➇ ➟ ➏ ➆➈➔⑤ï✔ð ➟▲ñ ➒✟➐✮➆➈→➉➏
9998
3538
2413
1986
1495
1457
1379
1150
1077
1016
939
937
895
570
Dr.
Nr.
Mill.
bzw.
Prof.
dgl.
Mrd.
Tel.
Abb.
St.
usw.
ca.
Mio.
Co.
bei denen durch diese auf den Suffixen basierende Erkennung als Abkürzung ein Fehler eingefügt wurde. Theoretisch sind jedoch Fälle denkbar, in denen Eigennamen, die
mit diesen Suffixen enden, am Ende eines Satzes auftreten. In einem solchen Fall würde der Eigenname als Abkürzung erkannt und der Satzpunkt nicht abgetrennt. Wurde
eine Abkürzung durch diese Methoden nicht erkannt, so wird zusätzlich getestet, ob
das Wort ausschließlich aus Konsonanten besteht.
Die Entscheidung über die Abtrennung von Punkten am Wortende arbeitet dabei mit
folgender (hier vereinfacht dargestellter) Heuristik. Eine Abkürzung in folgenden Fällen vor:
➴ Das folgende Wort ist klein geschrieben.
➴ Das Wort besteht aus nur einem Buchstaben.
➴ Das Wort besteht aus Initialen (z. B. »O.J.«).
➴ Das Wort besteht nur aus Konsonantengraphemen.
➴ Das folgende Wort ist ein Satzzeichen, welches nur innerhalb eines Satzes auftreten kann.
➴ Das Wort wurde im Abkürzungslexikon gefunden.
➴ Das Ende des Wortes wurde im Suffixlexikon gefunden.
➴ Das folgende Wort ist ebenfalls eine Abkürzung (in diesem Fall wird im Abkürzungslexikon nach einer mehrteiligen Abkürzung wie »z.B.« gesucht; mehrteilige Abkürzungen werden als ein Token ausgegeben).
Treffen diese Kriterien nicht zu, so liegt höchstwahrscheinlich das Ende eines Satzes
vor. Um weitere Entscheidungskriterien für die Wahrscheinlichkeit eines Satzendes
zu haben, wurde ein zusätzliches Lexikon von 60 Wörtern erstellt, die nur am Anfang
eines Satzes groß geschrieben werden können. Es handelt sich hierbei hauptsächlich
um Artikel, Konjunktionen und Partikeln. In diesen Fällen wird der Punkt abgetrennt,
oder, im Falle einer Abkürzung als letztem Element eines Satzes, ein zusätzlicher
Punkt ausgegeben, um damit das Satzende zu markieren.
✈✡➘
Ein Satzende liegt in folgenden Fällen vor:
➴ Das folgende Wort ist eine Absatzmarkierung.
➴ Das Wort ist eine Jahreszahl.
➴ Das folgende Wort wird normalerweise groß geschrieben.
➴ Das Wort ist keine Abkürzung.
Die Überprüfungen auf Satzende und Abkürzung werden dabei jeweils auf das jeweilige Wort und die zwei folgenden Wörter angewandt. Auf diese Weise können
auch mehrteilige Abkürzungen erkannt werden. Zudem werden die beiden Heuristiken nicht nacheinander, sondern voneinander abhängig ausgewertet.
❰⑤④ ➷⑤④ ✙ ④ ù
❍☎✓✖✕✗✧✡✰☎✘✔✿ ❊✟❊✟✧➂❀✂✧✡✓ Ù ✣✔✘✔❘✻❋✖❀☎✿ ❊✟✑✂✥◗✰☎✿ ✕✗✣✔✿ ✧✡✓✖✣✔✘✔✕
Um die Korrektheit der Punktdisambiguierung zu testen, wurde ein Versuch mit einem Teil des IDS-Korpus unternommen. Es handelte sich dabei um die ersten 300 000
laufenden Wortformen des Handbuchkorpus. Dieses Teilkorpus diente nicht zur Erstellung der von der Disambiguierung verwendeten Lexika. Da die Korpora des IDS
schon tokenisiert vorlagen, wurde im ersten Bearbeitungsschritt die Punktdisambiguierung rückgängig gemacht, indem alle abgetrennten Punkte wieder an das vorhergehende Wort angefügt wurden. Anschließend wurde die Punktdisambiguierung auf
das so erstellte Teilkorpus angewandt. Im gesamten Teilkorpus wurden 58 549 mit
einem Punkt endende Wörter gezählt. Von diesen wurden 211 nicht richtig disambiguiert, was einer Fehlerrate von 0,3 % entspricht. Bei einer genauen Analyse der
fehlerhaften Disambiguierungen stellte sich allerdings heraus, daß ein Großteil der
Fehler auf eine falsche Tokenisierung des IDS-Korpus zurückgeht. So waren z. B.
die Punkte von einigen Abkürzungen in den IDS-Texten abgetrennt, oder einige Satzpunkte nicht von den Wörtern getrennt. Durch eine manuelle Auszählung der Fehler
ergab sich eine Fehleranzahl von 65 (0,1 %). Dabei handelte es sich hauptsächlich
um nicht erkannte Abkürzungen oder um Zahlen, die als Ordinalzahl erkannt wurden,
obwohl es sich um das Ende eines Satzes handelte. Die folgenden Beispiele sollen
dieses Problem veranschaulichen:
(1) [...] jetzt in der Lohngruppe 4. Jürgen dagegen [...]
(2) [...] im Bundesgebiet 90000. Hochgerechnet ergibt [...]
(3) [...] niedrigen Stand von 76. Tokio notierte nach [...]
(4) [...] auf rund 16000. Deutsche Männer und Frauen [...]
Wie die Beispiele zeigen, würde auch die Zuhilfenahme einer morphologischen Analyse bei den Beispielen (1), (3) und (4) keine eindeutige Entscheidung bei der Disambiguierung der Zahlen bieten. In Beispiel (2) könnte durch die morphologische
Analyse des folgenden Wortes als normalerweise klein geschriebenes Verb ein Satzende erkannt werden. Die Analyse der 65 Fehler ergab 20 Fälle, in denen durch
Analyse der Wortart eine eindeutige Disambiguierung erfolgen könnte.
Eine verwandte Arbeit wurde von Palmer und Hearst (1994) ausgeführt, die ein neuronales Netz verwenden, um bei getaggtem Texten Punkte am Wortende automatisch
✈✡✃
zu disambiguieren. Die dabei erzielte Erfolgsrate lag bei 98,5 %. Das Besondere des
Systems liegt dabei in der Tatsache, daß die verwendete Technik durch einfaches Training auf verschiedene Sprachen angewandt werden kann. Das erstellte System SATZ3
verwendet allerdings zusätzlich ein Abkürzungslexikon und ein Vollformenlexikon,
um bessere Resultate zu liefern.
Eine weitere Arbeit zur Punktdisambiguierung wurde von Grefenstette und Tapanainen (1994) durchgeführt. Die beiden Autoren führten dabei eine Anzahl von Experimenten zur Erkennung von Abkürzungen im Brown-Korpus durch. Die verwendete
Technik basiert dabei auf der Eintragung erkannter Abkürzungen in ein Abkürzungslexikon. Auf diese Weise erreichen sie eine Erfolgsrate von 97,9 %. In einem zusätzlichen Experiment integrierten sie eine morphologische Analyse und konnten die
Erfolgsrate dadurch auf 99,7 % steigern. Dies entspricht den Ergebnissen des hier
vorgestellten Ansatzes, der keine morphologische Information verwendet. Allerdings
ist das hier verwendete 300 000 laufende Wortformen umfassende Testkorpus wesentlich kleiner als das Brown-Korpus, so daß davon ausgegangen werden kann, daß sich
die Ergebnisse bei einer Anwendung auf größere Datenmengen etwas verschlechtern
würden. Die Beschränkung auf ein kleines Korpus wurde bedingt durch die fehlerhafte Tokenisierung der zur Verfügung stehenden Korpusdaten, wodurch die Ergebnisse
manuell ausgezählt werden mußten. Wie gezeigt wurde, können die Ergebnisse durch
die Integration einer morphologischen Analyse nochmals verbessert werden.
3
➶ http://elib.cs.berkeley.edu/src/satz/ ➹
✠✡✌
Jedes Korpus besteht aus einer Anzahl von Texten. Zu jedem Text sollen Informationen wie bibliographische Angaben oder Textlänge abrufbar sein. Die Definition eines
Korpustextes deckt sich dabei nicht hundertprozentig mit der traditionellen Sichtweise, da ein Korpustext aus mehreren Originaltexten bestehen kann. So wäre es z. B.
sehr aufwendig und unnötig, jeden Artikel einer Tageszeitung als einzelnen Text im
Korpus zu speichern. Statt dessen wird man alle Artikel einer Rubrik oder alle Artikel einer Zeitung zu einem logischen Text zusammenfassen und diesen als Einheit im
Korpus erfassen. Dieses Kapitel beschäftigt sich mit der Erfassung und Speicherung
der zusätzlich zu den eigentlichen Textdaten notwendigen Daten eines Korpustextes.
Der beschriebene Ansatz versucht, dabei einen Mittelweg zwischen der sehr aufwendigen und für viele Benutzer undurchschaubaren Kodierung nach den TEI-Richtlinien
und der Entwicklung eines eigenen Formates zu gehen.
ú❯❪❴❭❛ß✫ë✼ì➣Þàû➦❝✫❸€❢❤❝✫✐
Ein Text besteht gemäß der TEI-Richlinien aus zwei Teilen: einem TEI-Header und
dem eigentlichen Text. Im TEI-Header wird dabei Information über den Text kodiert.
Dies sind bibliographische Angaben wie Autor, Titel bis hin zu Informationen über die
verwendeten Tags oder Angaben zur Einordnung des Textes in ein vorher definiertes
Klassifikationsschema (siehe Abschnitt 5.3). Ein minimaler TEI-Header muß dabei,
um der TEI-DTD zu entsprechen, mindestens folgende Elemente enthalten:
➴ <titlestmt> Angaben zum Titel des elektronischen Textes, der nicht mit
dem Titel des Ursprungstextes identisch sein muß.
➴ <pubstmt> Angaben zur Publikationsform des elektronischen Textes.
➴ <sourcedesc> Angaben zur Quelle des Textes.
✠❣✆
Diese Elemente sind alle innerhalb des Elementes <filedesc> definiert. Es ergibt
sich somit folgender minimaler TEI-Header:
<teiheader>
<filedesc>
<titlestmt> ... </titlestmt>
<publicationstmt> ... </publicationstmt>
<sourcedesc> ... </sourcedesc>
</filedesc>
</teiheader>
Sollen Texte, die nach den Richtlinien der TEI kodiert sind, in einer Korpusdatenbank
gespeichert werden, so ist dieser TEI-Header gesondert abzuspeichern. Unglücklicherweise ist der TEI-Header das komplexeste Element der gesamten TEI-Richtlinien.
Aus diesem Grund ist es sehr aufwendig bis unmöglich (jedenfalls im Rahmen dieser
Arbeit), ein System zu erstellen, das alle Möglichkeiten der im TEI-Header erfaßten
Daten in Feldern einer Datenbank speichert. Im Falle von bibliographischen Angaben
existieren z. B. drei verschiedene Grundelemente, von denen zwei beliebig komplex
verschachtelt werden können. Zudem kann jedes der beiden Elemente einen Großteil
der gesamten TEI-Elemente enthalten. Ein Parsen einer solchen Angabe ist durch die
Definition der DTD zwar ohne weiteres möglich, eine sinnvolle Eintragung in eine
Datenbank scheitert aber an der großen Menge der möglichen Felder und an der beliebigen Schachtelungstiefe (so ist alleine innerhalb des einfacheren <bibl>-Elements
die Verwendung von 46 Elemente möglich, die zu einem großen Teil wieder mehrere
Elemente enthalten können).
Der vorliegende Ansatz geht deshalb von einem minimalen TEI-Header aus, der zusätzlich einige obligatorische Elemente enthalten muß, die zur Speicherung der Texte
in der Korpusdatenbank notwendig sind. Dieser Ansatz deckt sich mit der Vorgehensweise bei der Kodierung der BNC-Daten, der in Dunlop (1995) beschrieben ist. Die
Möglichkeiten der TEI wurden dabei auf die zur Kodierung notwendigen Elemente
beschränkt und das Format und die Schachtelungstiefe einiger Elemente wurde vorgegeben, um eine eindeutige Eintragung in der Datenbank zu ermöglichen.
In CORSICA werden bei der Analyse der TEI-Header nur die obersten Elemente jedes minimalen TEI-Headers analysiert. Alle darin enthaltenen Elemente werden in
der Datenbank gespeichert. Auf diese Weise können komplexe Quellenangaben oder
auch Fremdformate (deren Angabe innerhalb der TEI-Richtlinien ebenfalls möglich
ist) erfaßt werden. Durch eine Integration einer Datenbankkomponente für TEI-Daten
oder für das verwendete Fremdformat könnten diese Daten dann explizit ausgewertet
werden. Dies liegt jedoch nicht mehr in der Zuständigkeit der Korpusdatenbank und
könnte als eigenständige Arbeit von Interesse sein.
ú❯❪ ♣r❶❦②✫✐♥❷❤s€❺✂Þàû➦❝€❸✫❢❤❝✫✐❧s€t❣❢Ýß✫❝✫ü❆♦❻Þàû➦❝✫❸€❢❤❝✫✐
Eine grundsätzliche Unterscheidung muß zwischen dem Korpus-Header und den einzelnen Text-Headern gemacht werden. Der Korpus-Header enthält Informationen, die
das gesamte Korpus betreffen, und ist wie ein normaler TEI-Header aufgebaut. Der
Unterschied besteht darin, daß im Korpus-Header ein Klassifikationsschema definiert
werden kann, auf das die einzelnen Texte referieren können. Im folgenden sollen
✠ ✈
zunächst die gemeinsamen Elemente beider Header beschrieben werden.
ö⑤④ ③⑤④ ✙þý❅ÿ ✂✁☎✄✝✆✞ ✂✟✠ ✡✄☞☛✌✄☞✍✎ Zur Speicherung des Titels eines elektronischen Textes existiert aus mehreren Gründen ein eigenes Element. Werden mehrere Originaltexte zu einem elektronischen Text
zusammengefaßt, so sollte ein neuer Titel, der alle Texte zusammenfassend beschreibt,
gefunden werden. Außerdem ist die Speicherung des Originaltitels nicht immer sinnvoll. So ist ein Titel, der den elektronischen Text im Vergleich mit den anderen im
Korpus existierenden Texten beschreibt, oft aussagekräftiger. Im Falle von Zeitungstexten, die als einzelne Texte abgespeichert werden, könnte z. B. der Name der Zeitung
sowie das Datum der Ausgabe und die Rubrik, unter der der Text erschien, als Titel angegeben werden. Auf diese Weise kann bei einer Textauswahl allein durch Vergleich
der Titel eine sinnvolle Auswahl getroffen werden.
ö⑤④ ③⑤④ ③✑✏✓✒✕✔ ✁ ✗ÿ ✖✕✟✠ ⑩ÿ☎✘✙✍✚✆✞ ✂✟✠ ✡✄☞☛✌✄☞✍✎ Dieses Element enthält Informationen über die Veröffentlichung oder Verfügbarkeit
des elektronischen Textes. Typischerweise werden hier Daten über die Organisation,
die den elektronischen Text erzeugt hat (oder vertreibt) gespeichert. Im Falle eines
Korpus-Headers ist eine Angabe der Verfügbarkeit des Korpus von Wichtigkeit. So ist
z. B. das BNC nur für Forschungszwecke innerhalb der EU zugelassen. Aus diesem
Grund sollten hier auch Adressen der Kontaktpersonen aufgenommen werden, die für
Erstellung und Verbreitung des Korpus zuständig sind.
Um eine eindeutige Identifizierung der einzelnen Korpustexte zu ermöglichen, erwartet CORSICA eine Angabe einer eindeutigen Identifikationsnummer in Form eines
<idno>-Elements als erstes Element innerhalb von <pubstmt>. Diese Vorgehensweise deckt sich mit der im BNC verwendeten Methode und erlaubt eine Speicherung
der Header-Daten jedes Textes unter des jeweiligen ID. Auch das gesamte Korpus erhält eine eindeutige ID, die als Basis für die Dateinamen der Korpusdaten dient. Die
Korpus-ID der von CORSICA gleichzeitig verwalteten Korpora müssen dabei unterschiedlich sein.
ö⑤④ ③⑤④ ➷
✆✛✘ ✒✕✜ ✖✎✄✣✢✣✄✙✤✠✖ ✜
ÿ ✥✠ ❈ÿ☎✘✙✍
Das Element <sourcedesc> enthält eine vollständige Quellenabgabe der Originaltexte, auf denen die elektronische Version basiert. Der einfachste Eintrag besteht hierbei in der Angabe von Absätzen (<p>), die eine formatfreie Quellenangabe enthalten.
Im Falle von elektronisch erstellten Texten, die keine Quelle besitzen (ein elektronisch
erstelltes Korpus wäre ein solcher Text), sollte auf die Nichtexistenz eines Originals
hingewiesen werden. Die TEI-Richtlininien sehen weiterhin drei verschiedene Elemente zur Speicherung von bibliographischen Informationen vor. <bibifull> definiert eine vollständige bibliographische Angabe und kann die gleichen Elemente wie
das <filedesc>-Element des TEI-Headers enthalten. <bibl> ist eine freie Variante zum Erfassen bibliographischer Information und kann alle Elemente erhalten, die
auch in laufendem Text vorkommen können (der einfachste Eintrag besteht demnach
wiederum in der Angabe eines Paragraphen, der freien Text enthält). Das Element
<listbibl> ermöglicht die Auflistung mehrerer bibliographischer Angaben, falls
der Text aus mehreren Originaltexten besteht.
✠✡✠
In Abbildung 5.2.3 ist das gesamte <filedesc>-Element des Testkorpus dargestellt.
➚♥➅❅➅❅→ ➇➉↕ ➟ ↔▲➒➂×▲➋ ➌✖➍✠✦★✧ ✩✫✪✕✩✕✬★✭✯✮✱✰ ✲✕✳ ✰ ✴✙✵❦↕❅➆➈➛
➃✻➆➈➛✜➏ ➐✮➓❻➔❞➤ ➟ ➛
<filedesc>
<titlestmt>
<title>CLUE-Testkorpus</title>
</titlestmt>
<publicationstmt>
<idno>clue1.1</idno>
<distributor>
<name>
Abteilung für Computerlinguistik (CLUE),
Institut für Germanistik,
Friedrich-Alexander-Universität Erlangen-Nürnberg
</name>
<address>
Bismarckstraße 12
D-91054 Erlangen
e-mail: maz@linguistik.uni-erlangen.de
Phone: +49 9131 85 92 50
</address>
</distributor>
<date> 1997-02 </date>
</publicationstmt>
<sourcedesc>
<p> Wird das Korpus als eigenständiger Text betrachtet,
so existiert keine Quelle, da es als elektronischer
Text konzipiert wurde.</p>
<p> Die Quellen der einzelnen Texte sind in den
jeweiligen source descriptions angegeben. </p>
</sourcedesc>
</filedesc>
ú❯❪ Ðr✇★❝✫①❤t€❜❞♦❑❜❞②✫t➁❢❤❝✫❺ ❶❦❡➣❸€❺☎❺✂❜➣①❤Û❣❸✫♦❑❜❞②✫t❣❺☎❺✠✶€❽❣❝✫❿➁❸✫❺
Im Korpus-Header kann optional ein Klassifikationsschema zur Einordnung der Texte
in genau bestimmte Kategorien definiert werden. Dies geschieht innerhalb des Elementes <classdesc>. Ein Klassifikationsschema besteht dabei aus einer Anzahl
von Taxonomien (<taxonomy>), die jeweils eine Anzahl von Kategorien enthalten
können. Die bei der Kodierung des BNC verwendete Konvention (vgl. Dunlop 1995,
S. 91), die auch bei CORSICA angewandt wird, geht dabei davon aus, daß jede Taxonomie eine übergeordnete Kategorie enthält. Diese Kategorie enthält eine Beschreibung der Taxonomie in ihrem <catdesc>-Element und definiert alle möglichen Kategorien, die in dieser Taxonomie referenziert werden können, als Unterkategorien.
In Abbildung 5.3 ist ein Ausschnitt aus dem Klassifikationsschema eines Testkorpus
der Abteilung für Computerlinguistik der FAU Erlangen-Nürnberg dargestellt. Jede
Taxonomie und jede Kategorie erhalten dabei eine eindeutige ID, die über ein SGMLAttribut angegeben ist. Die ID müssen im ganzen Korpus eindeutig sein, da sie die
Basis für die Referenzierung und Speicherung von Texten bilden.
Durch die Möglichkeit, beliebige Taxonomien definieren zu können, können Texte
entlang der unterschiedlichsten Klassifikationskriterien unterschieden werden. Interessant ist dies insbesondere in Verbindung mit balanciert erstellten Korpora, deren
Texte unter bestimmten Gesichtspunkten ausgewählt wurden, wobei genaue Quoten
✠✡✞
➚♥➅❅➅❅→ ➇➉↕ ➟ ↔▲➒➂×▲➋ ➊✮➍➧➚ ➟ ➛➑➨➪➩▲↔▲→➉➏ ➏✟➄ ➟ ➛➦↕❅➆➈➼
➢✮➇ ➄❩➛▲➛❩→ ñ ➐✖➄➧➏ → ➓❻↔▲➛✜➨❴➩✜➆➈➼✼➄➙↕❅➆❴➛★➃❅➆➈➛✜➏ ➐✮➓❻➔❞➤ ➟ ➛▲➋
<taxonomy id=TA02>
<category>
<catdesc> Quellenmedium </catdesc>
<category id=C05>
<catdesc> Buch </catdesc>
</category>
<category id=C06>
<catdesc> Zeitschrift </catdesc>
</category>
<category id=C07>
<catdesc> Zeitung </catdesc>
</category>
<category id=C08>
<catdesc> Manuskript </catdesc>
</category>
</category>
</taxonomy>
für die Anzahl bestimmter Textsorten festgelegt wurden. So können die geschriebenen Texte des BNC z. B. anhand 13 Kriterien, die von der Domäne des Textes über das
Medium bis zur Zielgruppe des Textes reichen, unterschieden werden (vgl. Burnard
1995, S. 5–9).
ö⑤④ ➷⑤④ ✙⑦⑥❫✧❅▼✖✧✡✓✖✧✡✘✔á✜✿ ✧✂✓✖✣✔✘✔✕Ú❀✂✧✡❊★➱❫✬ ✑✡❊✟❊✟✿ ✷✫❘✔✑❅❋▲✿ ✪✂✘✔❊✟❊✟❁✔✒✔✧✡✥✦✑✡❊
Um zu kennzeichnen, welcher Kategorie ein Text angehört, kann jeder Text des
Korpus Referenzen auf die Kategorien der definierten Taxonomien enthalten. Jeder Korpustext kann dabei auf beliebige Kategorien jeder Taxonomie verweisen.
Die Referenz erfolgt innerhalb des Elementes <textclass>, das innerhalb von
<profiledesc> definiert ist. Die dabei verwendeten <catref>-Elemente enthalten die Referenz auf Taxonomie (<scheme>) und Kategorie (<target>) als Attribute, die auf die jeweiligen ID verweisen, und sind ansonsten inhaltsleer.
Zusätzlich zu der Referenzierung erwartet CORSICA innerhalb des
<profiledesc>-Elements eine Angabe des Dateinamen des mit dem Header beschriebenen Textes. Hierzu wurde das Element <creation> ausgewählt, in
dessen Unterelement <code> der Dateiname angegeben wird. Dies ist notwendig,
da die Header unabhängig von den Texten abgespeichert und analysiert werden.
Nachdem die Header eingelesen sind, werden die eigentlichen Textdaten, die sich in
den angegebenen Dateinamen befinden, gelesen und in der Datenbank gespeichert. Es
können dabei beliebig viele Dateinamen innerhalb des <creation>-Elements angegeben werden. Dadurch können mehrere Texte unter einem Header zusammengefaßt
werden.
Ein Beispiel einer kompletten profile description aus dem Testkorpus befindet sich in
Abbildung 5.3.
ú❯❪ ærç✯❷❤❝✫❜✸✶❣❽€❝✫✐♥s❣t€✉❾❢❤❝✫✐◗ß✫❝€ü❫♦❻❿➁❝✫♦❑❸✫❜❞t✺✹❻②✫✐♥❿➁❸✫♦❑❜❞②✫t
Die Speicherung der Textinformationen geschieht unabhängig von den eigentlichen
Textdaten in einem von den Textdaten unabhängigen Teil der Datenbank. Es wer✠✡✍
➚♥➅❅➅✻→ ➇➉↕ ➟ ↔▲➒◗×▲➋ ❐✖➍➧➜➻➆❴→ ➛▲➤❅→ ➆➈➇✔➆❴→ ↔✜➆➈➔✻✲✙✮✱✴✙✦★✧ ✩
✪✙✩✕✬★✭✼✮✸✰ ✲✙✳ ✰ ✴✕✵❦➆❴→ ↔✜➆➈➛➦➃❅➆➈➎✟➏ ➆➈➛✤➄ ➟ ➛➦↕❅➆➈➼
➃❅➆➈➛✜➏ ➐✮➓❻➔❞➤ ➟ ➛▲➋
<profiledesc>
<creation>
<code>/projects/korpora/sz/sport.sgml</code>
</creation>
<textclass>
<!-- Sport -->
<catref scheme=TA01 target=C03>
<!-- Zeitung -->
<catref scheme=TA02 target=C07>
<!-- Geschrieben, veroeffenlicht -->
<catref scheme=TA03 target=C09>
</textclass>
</profiledesc>
den dabei alle Daten der TEI-Header abgespeichert, so daß aus der Datenbank heraus
jederzeit ein vollständiger TEI-Header für jeden Text und für das gesamte Korpus erstellt werden kann. Auf diese Weise kann das ganze Korpus TEI-konform aus der
Datenbank ausgegeben werden. Der Zugriff auf die Daten erfolgt dabei über die eindeutigen ID, die als Schlüssel für die Anfrage in der Datenbank dienen. So kann z. B.
der komplette Header jedes Textes über seine unter <idno> definierte ID angefordert
werden. Die Taxonomien werden hierarchisch abgespeichert, so daß durch Zugriff auf
eine Taxonomie alle darunter definierten Kategorien zur Verfügung stehen.
Zusätzlich müssen die Referenzen auf die Kategorien der Taxonomien in einer geeigneten Form gespeichert werden. Dabei wird zu jeder Kategorie jeder Taxonomie
einer Liste aller Texte abgespeichert, die auf diese ID referieren. Dies ermöglicht bei
einer Korpusanfrage die Definition von Filtern, die über eine Auswahl der Kategorien
den Suchraum auf eine bestimmte Anzahl von Texten einschränken. Intern wird dabei
für jede Kategorie die Start- und Endposition jedes Textes abgespeichert. Die Dateipositionen nebeneinanderliegender Texte werden dabei zu einem Korpusintervall
verschmolzen.
Die Texte selbst sind innerhalb der Korpusdaten durch ihre Position innerhalb der
Daten definiert. Um von jeder Korpusposition auf den jeweiligen Text schließen zu
können, wurde daher zusätzlich eine Abbildung der Textstartpositionen auf die ID der
Texte geschaffen.
ö⑤④ ❰⑤④ ✙
Ø ✧❅❄➧❋▲✥✦✧❅❋▲✑✡✿ ✘✻▼✖✪✡✓✖✥✦✑❅❋▲✿ ✪✡✘
Zu jedem Text werden folgende Felder in der Datenbank gespeichert:
➴ Die komplette Header-Information, bestehend aus:
– Titel
– Publication Statement
– Text-ID
– Source Description
– Einer Liste von referenzierten ID des Klassifikationsschemas
➴ Start- und Endposition des Textes im Korpus
➴ Anzahl der Wortformen des Textes
✠✡☛
Theoretisch wäre es möglich, zusätzlich eine Indizierung der Header-Daten vorzunehmen. Dadurch könnte eine Textauswahl auch durch Suche in den bibliographischen
Angaben getroffen werden. Da das Format der bibliographischen Daten jedoch noch
nicht definiert ist, erscheint es sinnvoller, eine Schnittstelle zu einer Datenbank zu definieren, in welcher die Textdaten gespeichert werden. Wie schon besprochen weist
dies über den Rahmen dieser Arbeit hinaus. Zudem würde dadurch eine genaue Erfassung der bibliographischen Angaben in einem bestimmten Format erzwungen.
✠✡➺
✽
Nach der Definition der Textmetainformation und der Beschreibung der Taxonomien
erfolgt als nächster Schritt die Speicherung der eigentlichen Textdaten in der Korpusdatenbank CORSICA. In diesem Kapitel werden die dazu verwendeten Datenstrukturen beschrieben. Da es sich bei einer Korpusdatenbank um eine spezielle Art von
Datenbank handelt, werden die verschiedenen Entscheidungen für die verwendeten
Datenstrukturen und Algorithmen erläutert. Die Darstellung ist dabei zunächst auf die
physikalische Ebene der Datenbank beschränkt.
❪❴❭❛q❙✐♥s❣t€❢❤✉✼❝✫❢❤❸✫t❣ۀ❝✫t
Wie schon in Kapitel 2.3.1 dargestellt, wird von einer besonderen Betrachtungsweise
der Korpusdaten ausgegangen. Ein Korpus besteht demnach in einer Abfolge von n
Positionen. Jeder Position ist dabei ein Token (d. h. eine Wortform) zugeordnet. Ein
positionelles Attribut ist definiert als eine zusätzliche Zuordnung eines Tokens zu jeder
Position. Laut den in Abschnitt 3.1.3 dargestellten Anforderungen an eine Korpusdatenbank sollen beliebige positionelle Attribute möglich sein. Zusätzlich sollen die
Attribute unabhängig von den Korpusdaten entfernt und hinzugefügt werden können.
Dadurch ist z. B. die Speicherung mehrerer Tagging-Analysen möglich, die so miteinander verglichen werden können. Die Zuordnung eines Attributs zu den eigentlichen
Korpusdaten erfolgt also nur über die Position. Ein Text eines Korpus ist ebenfalls
über seine Start- und Endposition um Korpus definiert. Ein Subkorpus ist demnach
durch eine Menge von Start-/Ende-Positionen definiert. Eine erfolgreiche Suche in
einem Korpus liefert daher als Resultat daher ein Subkorpus zurück. Ausgehend von
den Positionen dieses Subkorpus kann dann eine Konkordanz erstellt werden, indem
die Umgebung der gefundenen Positionen ebenfalls dargestellt wird (KWIC).
Bei der Speicherung der Korpustexte wird also zu jeder Position eine Wortform (ein
Token) abgespeichert. Um später nach diesen Wörtern effizient suchen zu können, ist
die Erstellung eines Index notwendig, der zu jedem type eines Korpus alle Positionen
abspeichert, an denen dieses Auftritt.
✠ ➘
✽
❪ ♣rì➣t€♦❑❝€✉✤❝€✐✮Ü➻s❣②✫✐♥❢❤t€s❣t€✉
Der grundlegende Gedanke bei der Speicherung der Wortformen ist die Zuordnung
eines Integerwertes zu jeder Wortform eines Korpus, wobei gleiche Wortformen den
gleichen Wert erhalten.1 Anders ausgedrückt entspricht so jedem type ein eindeutiger
Zahlwert, wobei kein Wert doppelt vorkommt. Die Zuordnung ist dabei beliebig und
erfolgt in Reihenfolge der auftretenden types. Dadurch sind keine Kollisionen möglich, der Wert einer Wortform kann aber auch nicht, wie bei z. B. bei einem Streuspeicherverfahren (hashing) errechnet werden, sondern muß in einer Zuordnungstabelle
abgefragt werden.
Durch diese eindeutige Zuordnung ist es möglich, die Tokens eines Korpus als Sequenz von Zahlenwerten abzuspeichern. Zusätzlich ist die Erstellung einer Zuordnung
der Zahlenwerte zu den Wortformen notwendig – diese Struktur soll im folgenden als
Wortliste bezeichnet werden.
Die Speicherung von Zahlenwerten hat dabei entscheidende Vorteile gegenüber der
Speicherung einer Zeichenkette zu jeder Korpusposition: Da die Zahlenwerte binär
gespeichert werden, ist jeder Eintrag gleich groß. Dadurch läßt sich jede Position des
Korpus genau bestimmen, indem die Korpusposition mit der Anzahl der zur Speicherung des Zahlenwertes verwendeten Bytes multipliziert wird:
poscorpus
✾
poscorpus ✿ sizeo f ❀ typeinteger ❁
Auf diese Weise ist ein wahlfreier Zugriff auf die Positionen des Korpus möglich. Die
Positionen eines Korpus sind somit implizit durch die Größe des verwendeten Datentypes bestimmt und brauchen nicht zusätzlich gespeichert werden. In der vorliegenden
Implementierung wurde ein Integerwert von 4 Bytes verwendet; somit ergeben sich
maximal 232 verschiedene types. Theoretisch würden 3 Bytes eine genügende Anzahl
von verschiedenen Möglichkeiten bieten. Da die meisten Computer architekturbedingt intern mit geraden Byte-Anzahlen rechnen, würde dies nur einen Gewinn bei
der Speicherung der Daten, nicht aber bei der Anwendung darstellen. Zudem sind unter C/C++ keine Integer-Datentypen mit 3 Bytes definiert, so daß durch die Definition
eines eigenen Datentyps ein Laufzeitnachteil entstehen würde.
Die Zuordnung eines positionellen Attributs zu einem Korpus wird ebenfalls vereinfacht. Werden die positionellen Attribute in der gleichen Weise wie das Korpus als
Zahlenwerte gespeichert, so ist die Zuordnung eines Attributs zu einem Korpus implizit durch die Position vorgeben. Da die gleichen Datenstrukturen verwendet werden
können, ergibt sich eine identische Speicherung der Attributdaten bis hin zur Indexgenerierung. Ein weiterer Vorteil dieser Speicherung besteht in der Platzersparnis. Geht
man von einer durchschnittlichen Wortlänge von 6 Zeichen aus, so müßten bei einer Speicherung der Wörter als Zeichenketten pro Wortform 7 Zeichen abgespeichert
werden, um die Wortgrenzen noch erkennen zu können. Bei einem Korpus von 100
Millionen Wortformen ergibt sich so eine Platzersparnis von 300 MB; zusätzlich ist
allerdings natürlich die Speicherung der Wortliste notwendig.
1
Dieses Verfahren wird auch in der IMS Corpus Workbench und in dem System zum Zugriff auf die BOE
angewandt, von dem außer einer knappen Bedienungsanleitung keine Literatur zur Verfügung stand.
✠ ✃
÷⑤④ ③⑤④ ✙
äå✪✡✓⑩❋▲✬ ✿ ❊❑❋▲✧
In der Wortliste eines Korpus wird die Zuordnung jeder Wortform zu einem Zahlenwert definiert. Die Datenstruktur muß dabei eine Abbildung von einem Integerwert
zu einer Zeichenkette und umgekehrt zur Verfügung stellen. Die Wortliste selbst besteht aus dabei einer Liste der types des Korpus in der Reihenfolge ihres Auftretens.
Für diese Struktur müssen zwei Indizierungen vorgenommen werden, um nach Zahlenwert und Zeichenkette suchen zu können. Eine Suche nach einer Zeichenkette ist
dabei Voraussetzung für die Suche nach Wortformen im Korpus. Zur Ausgabe von
Textdaten aus der Korpusdatenbank ist eine Suche nach den zu den Zahlenwerten gehörenden Wörtern notwendig.
✽
Um die einem Zahlenwert entsprechende Wortform finden zu können, wird dabei für
jeden Zahlenwert die Dateipositions der Wortform in der Wortliste gespeichert. Geht
man von w Wörtern aus, so wird eine Liste von w Dateipositionen erstellt. Wenn
diese Liste wie die Korpusdaten binär gespeichert wird, so kann wiederum wahlfrei
zugegriffen werden. Dadurch entfällt die Zuordnung der Zahlenwerte zu den Dateipositionen, da diese wieder implizit durch die Größe des Datentyps gegeben ist.
❪ Ðrç✯s✺✶€❽❣❝➁t€❸❂✶❣❽❾❵€❝✫❜✸✶❣❽€❝✫t❣ۀ❝✫♦❻♦❑❝✫t
Der umgekehrte Fall, die Suche nach einer Zeichenkette, gestaltet sich dabei weitaus
schwieriger. Um Benutzer bei einer Suche in einem Korpus möglichst mächtige Möglichkeiten der Bestimmung der Suchanfrage zu geben, soll dabei die Verwendung beliebiger reguläre Ausdrücke möglich sein. Im Gegensatz zu Text-Retrieval-Systemen,
die eine Suchanfrage meist auf die Möglichkeit der Trunkierung von Wörtern beschränken, sind damit sehr komplexe Muster, die einen Vergleich mit der gesamten
Wortliste notwendig machen, möglich.
Die Suche von Wortformen erfordert es daher, die Einträge der Wortliste in einer Datenstruktur zu speichern, die eine Ordnung der Einträge vornimmt und die Suche nach
regulären Ausdrücken unterstützt.
÷⑤④ ➷⑤④ ✙⑦⑧❆❂❈⑧❆●✡✣✔✥✦✧
Eine der beliebtesten externen Datenstrukturen zur Suche ist der B-Baum, zuerst beschrieben in Bayer und McCreight (1972) (siehe auch Gonnet und Baeza-Yates 1991).
Es handelt sich dabei um einen balancierten Suchbaum, wobei die Ordnung m des
Baums die Höchstanzahl der Tochterknoten jedes Knoten bestimmt (2 ✿ m). Jeder interne Knoten hat dabei mindestens m ❃ 1 Tochterknoten. Die Schlüssel werden in den
Knoten des Baumes gespeichert, wobei in den internen Knoten ein Schlüssel weniger
als die Anzahl der Tochterknoten enthalten ist. Wenn ein Knoten n Schlüssel enthält,
so sind alle Schlüssel k innerhalb des n-ten Tochterknoten größer als k, alle Schlüssel
innerhalb des Tochterknotens n ❄ 1 kleiner als k; der Baum wird automatisch balanciert. Wenn ein Knoten die maximale Anzahl von Schlüsseln enthält, wird der Knoten
aufgespalten und ein Schlüssel nach oben weitergegeben. Ein B-Baum wächst demnach immer von unten nach oben. Die Speicherausnutzung ist dadurch mindestens
50 %, da jeder interne Knoten mindestens m Schlüssel enthält.
✞✡✌
Ein B-Baum ist die am weitesten verbreitete Methode zur Suche nach Schlüsseln im
Hintergrundspeicher. Aus einigen Gründen ist die Datenstruktur für die vorliegende
Problemstellung trotzdem nicht geeignet. Für die Speicherung von beliebig langen
Schlüssel wird meistens eine abgeänderte Variante des B-Baumes verwendet, bei der
in den Knoten nur die ersten Zeichen jedes Schlüssels gespeichert werden, die zur
Einordnung des Schlüssels in die lexikalische Ordnung notwendig sind. Die Anzahl
der Schlüssel pro Knoten ist dabei variabel, da diese in der Größe variieren können.
Diese Methode hat aber, wie Harman et al. (1992) bemerken, einen entscheidenden
Nachteil:
The prefix method breaks down if there are many words with the same
(long) prefix. (Harman et al. 1992, S. 31)
Da insbesondere bei der Speicherung aller Wortformen eines sehr großen Korpus allein schon durch die deutsche Flexion bedingt sehr viele ähnliche Schlüssel auftreten,
würde die Präfix-Methode dazu führen, daß sehr viele Zeichen der Schlüssel in den
Knoten gespeichert werden müssen. Durch die dadurch entstehende schlechtere Ausnutzung des zu Verfügung stehenden Speichers ergibt sich eine erheblich höhere Anzahl von Knoten. Als Resultat werden bei einer Suche mehr Plattenzugriffe benötigt,
was die allgemeine Geschwindigkeit bei der Suche beeinträchtigt.
÷⑤④ ➷⑤④ ③
ý ✜ ☎ÿ ✄✙✤
Eine besser geeignete Datenstruktur zur Suche nach beliebig langen Schlüsseln ist ein
Buchstabenbaum (trie structure, bei der die Zeichen der Schlüssel die Verzweigung
der Knoten des Baumes vorgeben. Der Wurzelknoten entspricht dabei dem ersten Zeichen eines Schlüssels, die Tochterknoten dem zweiten Zeichen etc. Probleme treten
bei dieser Datenstruktur auf, wenn ein großes Alphabet verwendet wird:
When the cardinality of the alphabet is large and consequently internal
nodes are of significant size compared to a record, the trie becomes inefficient in its use of storage.
(Gonnet und Baeza-Yates 1991, S. 136)
Da bei der vorliegenden Problemstellung die Wortformen eines Textes unverändert abgespeichert werden sollen, müssen alle Sonderzeichen sowie eine Unterscheidung von
Groß- und Kleinschreibung der Schlüssel beachtet werden – das verwendete Alphabet
ist also sehr umfangreich. Der dadurch entstehende Speicherbedarf bei der Erstellung
des Tries kann zu nicht unerheblichen Problemen führen – wie auch bei den PräfixB-Bäumen wird die Effizienz der Suche durch eine erhöhte Anzahl von notwendigen
Plattenzugriffen verschlechtert. Ein weiteres Problem eines solchen Buchstabenbaumes ist die Existenz interner leerer Knoten, die nur Verweise auf andere Knoten, aber
keinen Verweis auf einen Schlüssel enthalten.
÷⑤④ ➷⑤④ ➷✑✏
ÿ ✻ÿ ✟✭ý
✟❅ ✜ ✗✖
✜ ✄❅✄✙✤
Eine bessere Lösung ist die Verwendung eines Patricia Tree Gonnet, Baeza-Yates und
Snider 1992. Hierbei handelt es sich um einen speziellen binären Baum, bei dem die
Bitmuster der Schlüssel die Verzweigung der Knoten vorgeben. Zusätzlich wird in
✞❣✆
jedem Knoten eine Zahl gespeichert, die die zu überspringenden Bits für die Tochterknoten angibt. Auf diese Weise können leere interne Knoten vermieden werden. Das
Resultat ist ein gepackter binärer Baum, der für n Schlüssel genau n ❄ 1 interne und
n externe Knoten enthält. Das Wachstum des Baumes ist somit konstant – die Gesamtgröße des Baumes kann daher anhand der Schlüsselanzahl vorberechnet werden.
Beim Erreichen eines externen Knotens muß dabei der gefundene Schlüssel überprüft
werden, da durch das Überspringen von Bits in den internen Knoten keine eindeutige
Identifizierung des Schlüssels erfolgen kann. Die bei den anderen Datenstrukturen
festgestellten Speicherprobleme treten bei Patricia Trees aus diesen Gründen nicht
auf. Gonnet schreibt dazu:
Patricia trees are a practical and efficient solution for handling variable length or very long keys; they are particulary well suited for textsearching. Note that the problem generated by very long common prefixes virtually disappears for Patricia trees.
(Gonnet und Baeza-Yates 1991, S. 142)
Wie weiterhin in Gonnet, Baeza-Yates und Snider (1992) gezeigt wird, ist es möglich, sehr effizient in einem Patricia Tree nach regulären Ausdrücken zu suchen. Zu
diesem Zweck wird der reguläre Ausdruck zuerst in einen minimalen deterministischen endlichen Automaten umgewandelt (DEA). Dieser Automat wird dann in einen
binären Automat konvertiert, der der Binärkodierung des verwendeten Zeichensatzes
entspricht. Nun kann dieser endliche Automat auf dem binären Baum simuliert werden. Der Wurzelknoten entspricht dabei dem Startzustand des Automaten. Bei jedem
Knoten, der einem Endzustand des Automaten entspricht wird dabei der gesamte darunterliegende Teilbaum als Resultat ausgegeben.
Patricia Trees stellen somit eine optimale Lösung für die vorhandenen Probleme dar.
Programmiertechnisch sind sie allerdings sehr aufwendig zu implementieren. Gonnet
entwickelte eine effiziente Implementierung der Patricia Trees für das Textsuchsystem des Oxford English Dictionary (OED). Die verwendete Software wird unter dem
Namen PAT inzwischen kommerziell vertrieben. Für CORSICA wurde eine Implementierung der Patricia Trees deswegen als zu aufwendig angesehen. Insbesondere
die notwendige Aufspaltung des Baumes zur Speicherung auf dem Hintergrundspeicher und die Programmierung und Konvertierung der endlichen Automaten stellen
Probleme dar, die eine eigenständige Arbeit rechtfertigen würden. Als bestmögliche
Problemlösung sollten Patricia Trees aber als mögliche Erweiterung von CORSICA
in Betracht gezogen werden.
÷⑤④ ➷⑤④ ❰
⑧❆✿ ✘✔●✡✓✖✧✦➮✗✣✔❁✔✒✔✧✦✿ ✥
➸ ✑✡✣✔❱✟❋▲❊✟❱☎✧✡✿ ❁✔✒✔✧✂✓
Die in CORSICA verwendete Methode zur Suche nach Zeichenketten wurde aus praktischen Überlegungen und Erfahrungen gewählt und basiert auf einer binären Suche der Wörter im Hauptspeicher. Dazu wird die gesamte Wortliste mit Hilfe der
mmap(2)-Funktion von UNIX2 im Hauptspeicher abgebildet.3 Diese Lösung mag im
Vergleich mit den vorher dargestellten Möglichkeiten primitiv erscheinen, bietet aber
neben der direkten und einfachen Implementierung einige Vorteile. Zudem konnten
2
nach AES und SVID3 standardisiert, Anm. d. Hrsg.
In Stevens (1992, S. 407) werden das genaue Verfahren und die Zeitvorteile beschrieben, die durch diese
Möglichkeit entstehen.
3
✞ ✈
➚♥➅❅➅❅→ ➇➉↕ ➟ ↔▲➒❇❆▲➋ ➌✖➍❉❈ ➟ ➒✟➔❞→❋❊ ❊ ➛▲➛➑➏ ➔ ➟ ➐✮➏ ➟ ➔❑➆➈↔❦➄ ➟ ❊
↕❻→ ➆❯ò❤➓❻➔❑➏ ➇ → ➛✜➏ ➆
Korpus
pos
0
1
2
3
4
5
6
7
.
Integer i
29
i -> w
0
1
.
.
.
.
29
.
.
w
Wortliste (unsortiert)
w -> i
sortierter Index
i -> w
...
0
...
.
.
.
Zygote
Aachen
Baum
29
s
n
im Praxistest sehr gute Resultate erzielt werden. Im Gegensatz zu den anderen vorgestellten Methoden wird nur eine einzige zusätzliche Datei erstellt, die eine sortierte
Ordnung der Schlüssel enthält. Die dabei verwendete Datenstruktur ist identisch mit
der Zuordnung der Integerwerte zu einem Schlüssel, mit dem Unterschied, daß die gespeicherten Positionen eine aufsteigende Ordnung der Wortliste definieren. Durch die
Abbildung der Wortliste im Hauptspeicher ergibt sich der Vorteil, daß sowohl bei der
Suche als auch bei der Ausgabe von Zeichenketten die Plattenzugriffe entfallen. Insbesondere die Ausgabe von Textdaten würde ansonsten für jedes auszugebende Wort
einen Festplattenzugriff bedeuten. Die binäre Suche zum Auffinden der Wörter ist
dabei ein sehr stabiler Algorithmus, der das Durchsuchen von Abschnitten zuläßt und
dessen Suchzeiten von Anfrage zu Anfrage nur unwesentlich variieren.
✽
Abbildung 6.1 zeigt eine Wortliste mit den beiden Zugriffsstrukturen. Der sortierte
Index enthält dabei an der ersten Position einen Zeiger zu der Wortform, die bei der
Sortierung den niedrigsten Wert erhalten hat. Da während des Erstellens der Korpusdaten bei jedem type geprüft werden muß, ob schon eine Zuordnung zu einem Zahlenwert vorhanden ist, befinden sich bereits alle Wortformen bereits im Hauptspeicher,
nachdem alle Texte als Zahlenwerte abgespeichert wurden. Zu jedem Eintrag wird
dann in der Sortierreihenfolge die Position jedes type abgespeichert.
❪ ærì➣t€❢❤❝✫ü❆✉✼❝✫t€❝€✐✮❜❞❝✫✐♥s€t❣✉
Um effizient nach den Wörtern eines Korpus suchen zu können, ist die Erstellung
eines Index für die zu suchenden Wortformen notwendig. Im Index werden dabei zu
jedem Eintrag alle Positionen aufgelistet, an denen dieser Eintrag im Korpus zu finden
ist.
Im Bereich des Information Retrival werden dabei vor der Indexgenerierung einige Filteroperationen auf die Daten angewandt, um die Anzahl der zu indizierenden
Wörter zu reduzieren. Dazu zählt z. B. das Entfernen von sogenannten Stoppwörtern
(stopwords), Wörtern, die häufig vorkommen und wenig Information enthalten. Des
Außerdem werden Zahlen und Daten in ein einheitliches Format gebracht, Sonderzeichen entfernt und alle Großbuchstaben in Kleinbuchstaben gewandelt. Ziel ist es, den
zu erstellenden Index möglichst klein zu halten.
Für die Aufgabe der Korpusdatenbank sind diese Methoden aus verschiedenen Gründen nicht geeignet. So ist ein Zugriff auf alle Wörter eines Textes notwendig, um
✞✡✠
➚✮➅✻➅❅→ ➇ ↕ ➟ ↔❩➒❇❆✖➋ ➊✜➍✔Õ♥➔❞➛➑➏ ➆➈➇ ➇ ➟ ↔❩➒◗↕❅➆❴➛✤❒ ↔✜↕❅➆➈➎
pos
i
0
1
2
3
5
.
.
.
33
122
242
55
1
.
.
.
n
n
pos
Sortierung
i
5
213
22
774
7
31
664
.
1
1
2
2
2
2
3
.
n
n
beliebige linguistische Suchanfragen formulieren zu können. Hierzu gehört auch die
Unterscheidung von Groß- und Kleinschreibung und die Suche nach Sonderzeichen
und Zahlenangaben. Bei der Erstellung des Index für die Textdaten muß daher jeder
Eintrag der Wortliste indiziert werden und eine Liste aller Vorkommnisse abspeichert
werden.
÷⑤④ ❰⑤④ ✙⑦❏ ✘✻❉☎✧✡✓⑩❋▲✿ ✧✂✓⑩❋✖✧➙➬€✑✟❋✖✧✂✿
Die verwendete Datenstruktur des Indexes ist eine invertierte Datei (inverted file),
wie in Harman, Fox, Baeza-Yates und Lee (1992) sowie Rooth und Christ (1994)
beschrieben. Eine invertierte Datei enthält für jedes indizierte Wort die Anzahl n der
Vorkommnisse im Korpus und n Zeiger auf Korpuspositionen. Da eine vollständige
Indizierung der Textdaten notwendig ist, ergibt sich eine Indexgröße, die identisch mit
der Größe der Korpusdaten ist. Der Index entsteht dabei aus einer Umsortierung der
Korpusdaten und einer zusätzlichen Abspeicherung der Frequenz zu jedem Eintrag
der Wortliste. Wie nachfolgend dargestellt wird, ist der Zugriff auf die verwendeten
Daten direkt und erfordert nur eine Suche nach dem Schlüsselwort.
Wenn ein Korpus aus einer Anzahl Zuordnungen von Korpusposition zu einem Zahlenwert besteht, so ist dadurch eine Sortierung der Korpusdaten nach der Korpusposition gegeben. Die Erstellung des Index vertauscht diese Zuordnung. Die Korpusdaten
werden nach dem Zahlenwert sortiert; dabei wird allerdings die ursprüngliche Korpusposition mit abgespeichert. Auf diese Weise entsteht eine Zuordnung, die nach
den Zahlenwerten im Korpus sortiert ist und zu jedem Wert die Position im Korpus
enthält (siehe Abbildung 6.2).
÷⑤④ ❰⑤④ ③
➮⑤✪✡✓⑩❋▲✿ ✧✡✓✖✣✔✘✔✕Ú❀☎✧✡✓✤❏ ✘✔❀☎✧❅❄❆❀✂✑❅❋▲✧✡✿
Da bei der Erstellung der Indexdatei das gesamte Korpus sortiert werden muß, ist
eine Sortierung der Daten im Hauptspeicher nicht mehr möglich. Es muß daher ein
Verfahren verwendet werden, welches es ermöglicht, die Daten extern zu Sortieren.
Dies geschieht, indem temporäre Dateien auf die Festplatte ausgelagert werden. Der
dabei verwendete Algorithmus basiert auf Mischsortierung (Mergesort, siehe Gonnet
und Baeza-Yates 1991, S. 187) und besteht aus zwei Phasen. In der ersten Phase wird
die zu sortierende Datei in mehrere kleine Dateien unterteilt, die so groß sind, daß
sie im Hauptspeicher sortiert werden können (distribution phase). Das Ergebnis ist
eine Anzahl von sortierten Dateien. Im darauffolgenden Schritt werden diese Dateien
Datei für Datei »zusammengemischt«, bis wieder eine einzige Datei entstanden ist
✞✡✞
➚✮➅✻➅❅→ ➇ ↕ ➟ ↔❩➒❇❆✖➋ ❐▲➍❆➵✜➓❻➔❑➏ →➉➆❴➔ ➟ ↔▲➒Ú↕❅➆❴➔
❒ ↔✜↕❅➆➈➎✟↕❻➄➧➏ ➆➈→
Korpusdaten
5 3 77 34 33 654 774 7747 47454 45 666 ....
Verteilung
5 3 77
34 33...
...
...
...
Sortierung
3 5 77
33 34...
...
...
...
Zusammensetzung
3 5 33 34 77 ...
(merge phase). In Abbildung 6.3 ist das Verfahren graphisch dargestellt. Durch diese
Vorgehensweise ist eine Sortierung von beliebig großen Dateien möglich. Die einzige
Beschränkung ist der zur Verfügung stehende Plattenplatz.
÷⑤④ ❰⑤④ ➷
Ï ✣✔❊✟●❅❋▲á✮✬ ✿ ❁✔✒✔✧➂➬✫✑❅❋▲✧✡✿ ✧✡✘
Als nächster Schritt ist die Frequenz jedes type abzuspeichern. Da die neue Sortierung
alle Vorkommnisse eines type hintereinander auflistet, geschieht dies durch einfaches
Abzählen bis zum Wechsel des type. Zusätzlich werden alle Positionen, die einem
type zugeordnet sind, in der Indexdatei aufsteigend sortiert, und es wird eine Datei
erstellt, die für jeden Eintrag der Wortliste die Startposition im Index enthält. Nach
diesem Schritt ist der Index erstellt und die nach types sortierte Datei kann gelöscht
werden.
Das besondere der Indexerstellung liegt in der Tatsache, daß alle Operationen auf der
Ebene von binären Dateien ablaufen und keine Vergleiche von Textdaten notwendig
sind. Da binäre Daten um einiges schneller verarbeitet werden können, ergibt sich
ein gutes Laufzeitverhalten. Die Effizienz der Indexerstellung ist demnach nur von
dem verwendeten Sortierverfahren abhängig. Intern wird dabei mit einer Variante von
Quicksort sortiert.
÷⑤④ ❰⑤④ ❰
⑧❆✧✡✿ ❊✟❱✂✿ ✧✡✬ ✑✡✘✻▼à✓✖✑✂✕☎✧
Abbildung 6.4 zeigt eine komplette Anfrage mit Zugriff auf die Indexstruktur. Zuerst
wird dabei das Wort in dem sortierten Index in der Wortliste gesucht und der zugehörige Zahlenwert zwischen 0 und w zurückgeliefert. Als nächstes wird die Startposition
dieses Wertes (29) in der Indexstart-Datei gelesen. Der Zugriff erfolgt wieder direkt,
da die Position durch die Größe des Datentyps vorgegeben ist. Daraufhin wird zu
dieser Position in der Indexdatei gesprungen. Zur Ermittlung der Anzahl zu lesender
Positionen wird nun in der Frequenzdatei der zugehörige Wert gelesen. Daraufhin
können alle Korpuspositionen, an denen das Suchwort im Korpus auftritt, gelesen
werden. Um das Ergebnis der Suche auszugeben, ist es jetzt noch notwendig, die
an den Ergebnispositionen stehenden Zahlenwerte durch Zugriff auf die Wortliste als
Zeichenketten auszugeben.
Bei der vorliegenden Art der Indexstruktur ist ein direkter Zugriff auf die Indexdaten
möglich, sobald der Integerwert des zu suchenden Wortes ermittelt wurde.
✞✡✍
➚♥➅❅➅❅→ ➇➉↕ ➟ ↔▲➒●❆✖➋ î✜➍➑➜➻➆➈→ ➛▲➤❅→➉➆❴➇ ➄❩↔❍❊ ➔➣➄❩➒✂➆
sortierter Index
w -> Wortliste
Index
i -> inv. Korpus
0
0
invertiertes
Korpus
0
Korpus
0
Baum
Ausgabe
29
w
219
43
29
219 43
218
663
...
w
219 + 7
Wortliste
w -> i
i -> Frequenz
0
29
Baum
✽
w
7
n
n
29
w
❪ ú❏■ô♠❤❝✫✐♥❺✂❜✸✶❣❽€♦
Mit Hilfe der dargestellten Datenstrukturen können alle Daten und Attribute eines
Korpus in einem einheitlichen Format abgespeichert werden. Jedes Attribut verwendet dabei die gleiche Anzahl und Art von Dateien wie die eigentlichen Textdaten.
Dadurch ist eine automatische Zuordnung der Attribute zu einem Korpus durch die
Dateipositionen gegeben, die implizit vorhanden sind. Alle logischen Einteilungen
des Korpus, die ebenfalls über Korpuspositionen definiert sind, sind so in jedem Attribut ebenfalls enthalten. Durch diese implizite Zuordnung der Attribute zu den Korpusdaten ist eine beliebige Erstellung von Korpusattributen möglich, die durch einfaches registrieren des Attributnamens (siehe Kapitel 8.1) allgemein verfügbar gemacht
werden können. Genauso können Attribute beliebig entfernt werden, da dadurch die
eigentlichen Korpusdaten nicht betroffen sind.
Die notwendigen Dateien für jedes Korpusattribut (wozu auch die Daten der laufenden
Wortformen zählen, die ein obligatorisches Attribut eines Korpus darstellen) sollen
nachfolgend kurz aufgelistet werden.
✞✡☛
Jedes Attribut eines Korpus besteht physikalisch aus folgenden Datenstrukturen:
➴ Den eigentlichen Daten, die einer Sequenz von n Integerwerten entspricht
➴ Der Wortliste, die die Zuordnung der Zeichenketten zu den Intergwerten definiert und aus folgenden Dateien besteht:
– Eine Sequenz der Zeichenketten mit zugehörigem Integerwert (die Länge
dieser Datei ist variabel)
– Ein Index der Länge i, der jedem Integerwert i eine Position in der Wortliste zuordnet.
– Ein sortierter Index der Länge i, der in einer sortierten Reihenfolge auf die
Zeichenketten verweist
➴ Dem Index, der folgende Strukturen enthält:
– Die Indexdaten der Länge n, die durch eine Umsortierung der Korpusdaten
entstanden sind.
– Eine Frequenzliste der Länge i, in der zu jedem Zahlenwert die Anzahl
der Vorkommnisse im Korpus angegeben ist.
– Ein Index der Länge i, der jedem Integerwert eine Position im Index zuordnet.
In Abbildung 6.5 ist ein Korpus der Länge n mit i Attributen schematisch dargestellt.
Wie zu sehen ist, besitzt jedes Attribut eine eigene Wortliste und einen eigenen Index.
Die Zuordnung der Attribute bleibt durch die identische Größe der Dateien, welche
die Datensequenz abbilden, auch auf der Ebene der Textbetrachtung erhalten.
➚♥➅❅➅✻→ ➇➉↕ ➟ ↔▲➒❇❆✖➋ ×✖➍❆➵▲→➉➨➪➩➑➏ ➝✗➆➈→ ➛✜➆❖↕❅➆➈➔☎➚☎➏ ➏ ➔❞→ ➅ ➟ ➏ ➆
➆➈→ ↔✜➆❴➛✯➢✗➓❻➔❞➤ ➟ ➛
Textdaten
Attr. 1
Attr. 2
Attr. i
0
Text 1
...
Text 2
...
...
Text n
...
n
Index
+
Wortliste
Index
+
Wortliste
Index
+
Wortliste
Index
+
Wortliste
✞✡➺
Die im vorigen Kapitel vorgestellten Datenstrukturen werden von der im folgenden
dargestellten logischen Zugriffsebene der Korpusdatenbank genutzt, um auf die gespeicherten Daten zuzugreifen. Um gezielt nach Informationen in einem Korpus suchen zu können, ist eine Formulierung von Anfragen notwendig, die über das Suchen
nach festen Wortformen hinausgeht. Zu diesem Zweck wurde eine Anfragesprache
entwickelt, mit der Einschränkungen auf Korpuspositionen ausgedrückt werden können. Jede Anfrage besteht dabei aus einer Menge von Ausdrücken, die jeweils eine
Einschränkung auf eine Korpusposition beschreiben. Die Reihenfolge der Ausdrücke
beschreibt dabei die Reihenfolge des Vorkommens im Korpus.
Mit jeder Anfrage einer Korpusposition kann eine Einschränkung für jedes definierte Attribut eines Korpus gegeben werden. Die Syntax der Anfragesprache orientiert
sich an der Syntax der in Christ und Schulze (1995) dargestellten Anfragesprache
der IMS Corpus Workbench. Jede Anfrage auf eine Korpusposition wird dabei in
eckigen Klammern angeben. Attributwerte werden in Anführungszeichen gesetzt und
Attribute werden immer einem Attributwert zugeordnet. Diese Notation ist klar und
ersichtlich und es erschien deshalb angebracht, auf die Erfindung einer weiteren Anfragesyntax zu verzichten.1 Der Ausdruck
[word="can"]
würde demnach alle Positionen liefern, an denen das Attribut word den Wert »can«
hat. Das Attribut word ist dabei obligatorisch für jedes Korpus und bezeichnet die
Ebene der Wortformen. Werden mehrere Anfragen auf Korpuspositionen hintereinander angegeben, so müssen diese als Sequenz im Korpus vorkommen. Die Anfrage
[word="Vortrag"] [word="gehalten"]
findet alle Stellen im Korpus, in denen »Vortrag« gefolgt von »gehalten« auftritt.
1
Die Entwicklung der Anfragesprache der IMS Corpus Workbench wird in Schulze (1994) dargestellt.
✞ ➘
❫❪❴❭▼▲Ñ❝✫✉✼s€❡✱◆✫✐♥❝ ❥❧s€❺✂❢❤✐€❖✺✶❣ۀ❝
❑
Als Attributwerte können in der Anfragesprache beliebige reguläre Ausdrücke verwendet werden. Die Syntax der regulären Ausdrücke entspricht dabei dem Standard.2
Dadurch wird z. B. Hüllenbildung (+, *), Disjunktion (|) und die Angabe von Zeichenklassen ([]) unterstützt. Das Programm erkennt dabei selbständig, ob es sich bei
einem Attributwert um einen regulären Ausdruck handelt, oder ob eine Suche nach
einem einzigen Eintrag in der Wortliste genügt. Die Mächtigkeit der regulären Ausdrücke wird von CORSICA nicht eingeschränkt. Damit ist es theoretisch möglich,
Anfragen zu stellen, die das gesamte Korpus als Resultat zurückliefern. Da die Höchstanzahl der Fundstellen vom Benutzer angegeben werden kann, ist dies aber nicht
problematisch. Folgendes Beispiel beschreibt eine Anfrage, die als Resultat alle Positionen zurückliefert, an denen Wörter, die in -heit enden, stehen:
[word=".*heit"]
Werden in einer Anfrage nur Attribute des Typs word verwendet, so genügt es, nur
die Anführungszeichen anzugeben:
"Unabhängigkeits.*"
Dadurch kann bei längeren Sequenzen Redundanz vermieden werden.
❫❪ ♣ré❣②✫✉✼❜➣❺✠✶€❽❣❝❘◗➙❷❤❝€✐✮❸€♦❑②✫✐♥❝✫t
❑
Mehrere Anfragen auf eine Korpusposition können durch Disjunktion (|) oder Konjunktion (&) verknüpft werden. Wie üblich hat dabei die Disjunktion eine höhere
Priorität als die Konjunktion. Die Anfrage
[word="hexen" & pos="VFIN"]
liefert demnach alle Positionen, an denen das Wort »hexen« mit dem Attributwert
»VFIN« für das positionelle Attribut pos (part of speech) vorkommt. Bei dem Ausdruck
[word="hexen" & pos="VFIN" |
word="klecksen" & pos="VFIN"]
sind zwei unabhängige disjunktiv verknüpfte Ausdrücke vorhanden, die beide ausgewertet werden und gemeinsam ein Resultat bilden. Wie auch in Christ und Schulze
(1995) diskutiert wird, ist damit die Möglichkeit gegeben, Disjunktionen auf Ebene
der regulären Ausdrücke oder auf Ebene der booleschen Operatoren anzugeben. Die
beiden Beispiele sollen dies veranschaulichen:
(1) [word="gut|besser|besten"]
(2) [word="gut" | word="besser" | word="besten"]
2
genauer: regcomp(2) genügt den Standards POSIX.2 und XPG4, Anm. d. Hrsg.
✞ ✃
Im ersten Beispiel wird die Disjunktion dabei auf Ebene der regulären Ausdrücke behandelt, was im Vergleich zur zweiten Anfrage eine sehr viel längere Antwortzeit nach
sich zieht. In der zweiten Anfrage ist eine Disjunktion von eindeutigen Attributwerten vorhanden. Zum Finden der Werte ist demnach keine Auswertung von regulären
Ausdrücken notwendig.
❫❪ Ðr✇★❝✫✐◗✇★❜➣❺✂♦❑❸✫t❣Ü➻②✫❷❤❝✫✐♥❸✫♦❻②✫✐
❑
Mit einem speziellen Distanzoperator $any kann eine mögliche Distanz zwischen
zwei positionellen Angaben definiert werden. Die Anfrage
[word="habe"] $any(5) [word="müssen"]
liefert demnach alle Positionen, an denen eine Sequenz der Wörter »habe« und »müssen« auftritt, wobei diese Sequenz durch bis zu fünf beliebige Wortformen unterbrochen sein kann. Dadurch kann auf größere Abhängigkeiten zwischen zwei Attributwerten abgeprüft werden.
ù⑤④ ➷⑤④ ✙
❃✤✣✔❊❚❙Ñ✧✡✓⑩❋▲✣✔✘✔✕⑨❀✂✧✡✓➻❃✤✘✻▼à✓✖✑✡✕✗✧✡❊✟❱☎✓✖✑✡❁✔✒✔✧
Da es sich bei der Anfragesprache um eine unter programmiersprachlichen Gesichtspunkten recht einfache Syntax handelt, wird der Syntaxbaum einer Anfrage in Form
von Listen dargestellt. Jede Anfrage besteht dabei aus einer Liste von Anfragen auf
Positionen eines Korpus. Jede Anfrage auf eine Position besteht aus einer Liste von
Disjunktionen, jede Disjunktion wiederum aus einer Liste von Konjunktionen. Eine Konjunktion ist definiert durch eine Liste von Attribut/Wert-Paaren. Die gesamte
Syntax der Anfragesprache ist in Tabelle 7.3.1 dargestellt.
➃❻➄❩➅✡➆❴➇ ➇➉➆✯➯▲➋ ➌✖➍➧Õ♥➜➑➽✡Ò▲➞➉➵▲➤✡➆➈Ó✖→ ñ ➐✖➄➑➏ → ➓❻↔Ö↕❅➆❴➔
➚♥❯↔ ❊ ➔❞➄❬➒✂➆❴➛❩➤✻➔➣➄➑➨❴➩✜➆
query ❲ ::=
❱
❱
pos_match ❲ ::=
❱
❱
pos_query ❲ ::=
’[’
❱ disjunct ❲ ’]’
❳
regex_match
❲
❱
❳
anyword
❲
.
❱
❱
anyword ❲ ::=
’$any(’ DIGIT ’)’ .
❱
regex_match ❲ ::=
’"’
REGEX ’"’
❳
❱ regex_match ❲ ’"’ REGEX ’"’ .
❱
disjunct ❲ ::=
❱
❱
conjunct ❲ ::=
❱
❱
att_val ❲ ::=
STRING ’=’ ’"’ REGEX ’"’ .
❱
pos_match ❲ .
pos_query ❲
❱ pos_match ❲ ❱ pos_query ❲ .
❳
❳
conjunct ❲
❱ disjunct ❲ ’|’ ❱ conjunct ❲ .
❳
att_val ❲
❱ conjunct ❲ ’&’ ❱ att_val ❲ .
Bei der Auswertung einer Anfrage wird von links nach rechts vorgegangen und jeweils
versucht, möglichst früh ein eindeutiges Ergebnis auf einer Position zu erreichen.
✍✡✌
Ist dies erreicht, können die anderen positionellen Einschränkungen mit diesem Resultat abgeglichen werden, um so die Menge der möglichen Resultatspositionen zu
vermindern. Intern werden dabei Verfahren des Ein- und Auslesens von Indexinformationen vorgenommen, um sicherzustellen, daß jede Anfrage nur eine bestimmte
Menge von vorher angegebenem Speicher verbrauchen darf. Dies ist notwendig, da
durch die uneingeschränkte Möglichkeit der regulären Ausdrücke solche Anfragen
gestellt werden können, die das gesamte Korpus zum Ergebnis haben. Damit hier
nicht das gesamte Korpus als Resultat zurückgeliefert wird, existiert eine Höchstgrenze der Fundstellen, die aber variabel eingestellt werden kann. Beim direkten Zugriff
auf die Korpusdaten über die Programmierschnittstelle kann es durchaus sinnvoll sein,
eine Anfrage auszuwerten, die eine sehr hohe Zahl an Resultaten liefert, da mit dem
Resultat beliebig weitergerechnet werden kann.
Bei der Formulierung von Anfragen sollte dabei die Auswertungsreihenfolge in Betracht gezogen werden. So werden Anfragen, die als ersten Attributausdruck einen
eindeutigen Attributwert enthalten, deutlich schneller ausgewertet als Anfragen, in
denen die ersten Attributausdrücke sehr allgemeine Einschränkungen darstellen. Vor
der Auswertung der einzelnen Teilausdrücke ist es dabei nicht möglich, festzustellen,
welcher Teilausdruck ein weniger umfangreiches Resultat liefern wird. So reicht ein
Abprüfen auf die Existenz von regulären Ausdrücken nicht aus, da auch die Frequenz
der einzelnen Wortformen für die Auswertung von Bedeutung ist. Diese wiederum
kann von Attribut zu Attribut stark variieren. Im Falle eines sehr kleinen Tagsets kann
bei einer Anfrage auf eine eindeutige, hochfrequente Wortklassenkategorie ein Großteil des Korpus zurückgeliefert werden. Aus diesem Grund wurde eine Entscheidung
für eine Auswertung in Reihenfolge des Auftretens getroffen. Auf diese Weise kann
und muß der Benutzer selbst dafür sorgen, daß eine Anfrage schneller beantwortet
werden kann.
✍❣✆
❨
In diesem Kapitel sollen einige praktische Aspekte von CORSICA vorgestellt werden.
Es wird auf die Implementierung eingegangen und die Programmierschnittstelle wird
vorgestellt.
❪❴❭▼▲Ñ❝✫✉✼❜❞❺☎♦❻✐✮❜❞❝✫✐♥s€t❣✉❬❩☎②✫t✝❶★②€✐✮❷❤②€✐✮❸
Bevor auf die Daten eines Korpus zugegriffen werden kann, muß dieses registriert
werden. Bei der Registrierung werden Informationen über das Korpus in einer globalen Registrierungsdatei, die über eine Umgebungsvariable gefunden werden kann,
eingetragen. Alle in dieser Datei eingetragenen Korpora sind dann über CORSICA
verwendbar. Zu jedem Korpus werden dabei folgende Informationen gespeichert:
➴ Korpus-ID
➴ Korpustitel
➴ Verzeichnis der Korpusdaten
➴ Gesamtanzahl der laufenden Wortformen
➴ vorhandene Attribute
Eine Registrierung eines Korpus trägt dabei nur diese Daten in eine Registrierungsdatei ein. Das eigentliche Korpus bleibt davon unberührt und kann weiterhin mit
zusätzliche Attributen annotiert werden. Diese Attribute werden allerdings erst nach
einer erneuten Registrierung zugänglich.
✍ ✈
❨
❪ ♣rì➣❿❾❷❤❡❞❝✫❿➁❝✫t❣♦❑❜❞❝✫✐♥s€t€✉
CORSICA wurde in C++ programmiert. Dabei wurde die Bibliothek LEDA (Library
of Efficient Data Structures and Algorithms) vom Max-Planck-Institut für Informatik
in Saarbrücken Mehlhorn, Näher und Uhrig 1996 verwendet. Diese Bibliothek enthält
grundlegende Datenstrukturen wie Listen, assoziative Felder, Stapel oder Prioritätslisten. Zusätzlich sind Graphalgorithmen und geometrische Datenstrukturen enthalten,
die hier jedoch nicht verwendet wurden. Außerdem wurde folgende Software bei der
Implementierung eingesetzt:
➴ Der GNU g++-Compiler.
➴ Der lexikalische Analysatoren-Generator flex wurde zur Erstellung des Tokenisierers, zur Programmierung der lexikalischen Analyse der Anfragesprache und
zur lexikalischen Analyse der Header-Dateien verwendet.
➴ Der Parser-Generator bison wurde zur syntaktischen Analyse der Anfragesprache und der Header-Dateien benutzt.
➴ Zur Speicherung der Header-Information wurde die Berkeley-db-Library verwendet.
In der vorliegenden Implementierung kann auf die Korpusdaten über eigene C++Klassen zugegriffen werden. Dadurch ist es möglich, die Korpusdaten beliebig von
anderen Programmen aus zu verwenden. Zudem ist eine Berechnung von statistischen
Modellen auf Basis der zugrundeliegenden Datenstrukturen möglich. Außerdem kann
auf alle Daten eines Korpus auf allen Ebenen zugegriffen werden, so daß eine Analyse
und ein Vergleich verschiedener Analysen der Korpusdaten möglich wird.
⑤④ ③⑤④ ✙❫❪✔✪✡✕✗✿ ❊✟❁✔✒✔✧◗❍☎✰☎✧✡✘✔✧
❭
Es werden dabei zwei Ebenen der Korpusbetrachtung unterschieden. Auf der logischen Ebene besteht ein Korpus aus einer Menge von Texten. Jeder Text ist bestimmt
durch seine Position im Korpus und durch eine mögliche Einordnung in ein Klassifikationsschema. Jedem Text ist zusätzlich die Information seines TEI-Headers zugeordnet. Die Anfragesprache ist Teil der logischen Ebene des Korpus. Mit ihr können
Einschränkungen definiert werden, die ein Korpusintervall als Ergebnis zurückliefern.
Eine Einschränkung des Suchraumes der Anfrage ist dabei durch die Definition eines
Filters möglich. Ein Filter kann auf zweierlei Weisen definiert werden:
➴ Durch Angabe einer Liste von Kategorien des Klassifikationsschemas. Hierbei wird, falls vorhanden, das im Korpus-Header definierte Klassifikationsschema verwendet. Als Ergebnismenge werden nur Texte zugelassen, die in ihrer
<profiledesc> auf eine der angegebenen ID der Kategorien referieren.
➴ Durch direkte Angabe einer Liste der Text-ID. Auf diese Weise werden die aufgeführten Texte als Ergebnismenge ausgewählt.
Zusätzlich kann auf der logischen Ebene die Header-Information jedes Textes angezeigt werden. Die logische Ebene bildet somit die Grundlage für eine benutzerfreundliche Schnittstelle zu den Korpusdaten.
✍✡✠
⑤④ ③⑤④ ③
Ù ✒✕❴⑤❊✟✿ ❘✔✑✡✬ ✿ ❊✟❁✔✒✔✧◗❍✗✰✂✧✡✘✔✧
❭
Die physikalische Ebene von CORSICA stellt einen direkten Zugriff auf die Datenstrukturen der registrierten Korpora her. Dadurch sind alle Informationen, die zu einem Korpus gespeichert wurden, direkt zugänglich. Dieser Zugang wird über C++Klassen zur Verfügung gestellt und ermöglicht die Analyse und Auswertung der Korpusdaten von beliebigen Programmen aus. Im einzelnen werden folgende Funktionen
zur Vefügung gestellt:
➴ Zugriff auf jede Position jedes Korpusattributs
➴ Zugriff auf die Frequenzinformation der Wortliste
➴ Zugriff auf die Zeicheninformation der Wortliste
➴ Zugriff auf die Indexdaten einer Wortform
Eine besondere Möglichkeit bietet sich zur Speicherung und Disambiguierung von
morphologischen Analysen an. Das Programm MALAGA kann zusammen mit der
deutschen Morphologie eine vollständige morphologische Analyse jedes Tokens liefern. Anstatt in der üblichen Weise die Texte eines Korpus zu analysieren und die so
erhaltene mehrdeutige Analyse zu disambiguieren, ist es möglich, statt dessen nur die
Wortliste eines Korpus analysieren. Auf diese Weise wird jedes Token des Korpus
nur ein einziges Mal (mehrdeutig) analysiert. Die Datenstruktur zur Speicherung der
Analyse ist dabei identisch mit der Datenstruktur zur Speicherung der Wortliste eines
Korpus. Eine mehrdeutige morphologische Analyse eines Korpus oder eines Subkorpus kann danach jederzeit bei Bedarf erstellt werden, ohne daß die Morphologie dazu
benötigt wird. Zusätzlich besteht die Möglichkeit, Information zur Disambiguierung
eines Korpus abzuspeichern. Dazu wird zu jeder Korpusposition ein Wert gespeichert,
der die für diese Position eindeutige morphologische Analyse kennzeichnet. Da nicht
davon auszugehen ist, daß es mehr als 255 unterschiedliche Analysen einer Wortform
geben kann, genügt dazu ein Byte pro Korpusposition. Der Zugriff auf die Disambiguierungsinformation ist wieder wahlfrei.
⑤④ ③⑤④ ➷
❭
❵
✰✂✧✂✓✖✰✂✬ ✿ ❁✔❘
In Abbildung 8.1 wird ein Überblick über das Gesamtsystem gegeben. In der vorliegenden Implementierung ist von den C++-Klassen ein Zugriff sowohl auf die logische
als auch auf die physikalische Ebene der Korpusdatenbank möglich.
✍✡✞
➚✮➅✻➅❅→ ➇ ↕ ➟ ↔❩➒❦➭✮➋ ➌✖➍❜❛❬➅✔➆➈➔❞➅❅➇ → ➨❴➐➦ø❈➅✡➆➈➔✫↕❻➄❬➛
❝ ➆❴➛❩➄❩➼★➏ ★
➛ ❞à➛✜➏ ➆➈➼
Anwender-Ebene
- Korpuswerkzeuge
- Anfragewerkzeug
- Schnittstellen
- Konkordanzen
- Bibliotheken
direkt
logische
Ebene
- Anfragesprache
- Filteroperationen
- Textdefinitionen
Datenbank
physikalische
Ebene
Korpora
Indizes
✍✡✍
56
Mit dem vorliegenden System CORSICA wurde die Grundlage für eine Speicherung
von Korpora natürlicher Sprache geschaffen. In der vorliegenden Implementierung
können beliebige Attribute zu den Korpusdaten hinzugefügt und wieder entfernt werden. Durch die verwendeten Datenstrukturen ist ein effizienter Zugriff auch auf sehr
große Datenmengen möglich. Die entwickelte Anfragesprache ermöglicht die Formulierung von komplexen Einschränkungen auf beliebige Attributwerte und die Verwendung von beliebigen regulären Ausdrücken.
Ein besonderer Schwerpunkt lag in der vorliegenden Implementierung auf der Speicherung von globalen Textinformationen, die in einer TEI-konformen Notation erfaßt
werden können. Die zusätzlich mögliche Einordnung der Korpustexte in ein selbstdefiniertes Klassifikationsschema erlaubt eine gezielte Auswahl von Korpustexten. Auf
die notwendige Tokenisierung von Textdaten wurde ausführlich eingegangen und ein
vielversprechendes Resultat erzielt.
❡
Die Implementierung des Systems ermöglicht einen Zugriff auf die Korpusdaten in
Form einer Programmierschnittstelle. Auf diese Weise können die Daten beliebig analysiert und ausgewertet werden. Durch die offene Konzeption ist zudem die einfache
Integration in andere Programme möglich.
❪❴❭❛ë✼✐€❢❙❝✫❜❞♦❑❝✫✐♥s❣t€✉✼❺☎❿❤❣✫✉✼❡❞❜✸✶❣❽€Û❣❝✫❜➣♦❻❝✫t
Das vorliegende System bietet alle Funktionen auf Ebene einer Programmierschnittstelle an. Zusätzlich wurde versuchsweise eine Interpretervariante zum Testen der
Anfragesprache programmiert. Eine sinnvolle Anschlußarbeit ist daher die Erstellung einer graphischen Benutzeroberfläche, um die Korpusanfragen in einer geeigneten Form darstellen zu können. Auf diese Weise könnte eine komfortable Benutzung
der implementierten Möglichkeiten des Zugriffs auf Korpusdaten erreicht werden.
Bayer, R. und E. McCreight (1972). »Organization and maintenance of large ordered indexes.« Acta Informatica 1(3), 173–189.
Beutel, B. (1995). MALAGA 3.0. Programmdokumentation. Abteilung für Computerlinguistik (CLUE), Friedrich-Alexander-Universität Erlangen-Nürnberg.
Biber, D. (1993). »Representativeness in corpus design.« Literary and Linguistic
Computing 8(4).
Briscoe, T. (1994). »Prospects for practical parsing of unrestricted text: robust statistical parsing techniques.« In: N. Oostdijk und P. de Haan (Hrsg.), CorpusBased Research into Language. Amsterdam: Rodopi.
Burnard, L. (Hrsg.) (1995). Users Reference Guide British National Corpus. Version 1.0. Oxford: Oxford University Computing Services.
Chomsky, N. (1957). Syntactic Structures. Den Haag: Mouton.
Christ, O. und B. M. Schulze (1995). »Ein flexibles und modulares Anfragesystem
für Textkorpora.« In: Tagungsberichte des Arbeitstreffens Lexikon + Text, Tübingen. Niemeyer.
Church, K. (1988). »A stochstic parts program and noun phrase parser for unrestricted text.« In: Proceedings of the 2nd Conference on Applied Natural Language
Processing., Austin, TX, 136–143.
Church, K. W. (1993). »I’ve got data coming out of my ears.« Ta! The Dutch
Student’s Magazine for Computational Linguistics 2(2).
DeRose, S. (1988). »Grammatical category disambiguation by statistical optimization.« Computational Linguistics 14, 31–39.
Dunlop, D. (1995). »Practical considerations in the use of TEI headers in a large
corpus.« In: N. Ide und J. Vèronis (Hrsg.), Text Encoding Initiative: Background and context, 85–98. Dordrecht: Kluwer.
Francis, W. und H. Kuˇcera (1982). Frequency Analysis of the English Language.
Boston, MA: Houghton Mifflin.
Francis, W. N. (1992). »Language Corpora B. C.« In: J. Svartvik (Hrsg.), Directions in Corpus Linguistics: Proceedings of Nobel Symposium 82, Stockholm,
4–8 August 1991. (Trends in Linguistics 65) Berlin: Mouton de Gruyter.
✍✡➺
Garside, R. (1987). »The CLAWS word-tagging system.« In: R. Garside, G. Leech
und G. Sampson (Hrsg.), The Computational Analysis of English. London:
Longman.
Garside, R., G. Leech und G. Sampson (Hrsg.) (1987). The Computational Analysis
of English. London: Longman.
Gefenstette, G. und P. Tapanainen (1994). »What is a word, What is a sentence?
Problems of Tokenization.« (Technischer Bericht) Rank Xerox Research Centre
Europe, Grenoble.
Goldfarb, C. F. und Y. Rubinsky (1990). The SGML Handbook. Oxford: Clarendon.
Gonnet, G. H. und R. Baeza-Yates (1991). Handbook of Algorithms and Data
Structures (2. Auflage). Reading, MA: Addison-Wesley.
Gonnet, G. H., R. A. Baeza-Yates und T. Snider (1992). »New indices for text:
PAT trees and PAT arrays.« In: W. B. Frakes und R. A. Baeza-Yates (Hrsg.),
Information Retrieval. Murray Hill, NJ: Prentice-Hall.
Greene, B. B. und G. M. Rubin (1971). Automatical Grammatical Tagging of English. (Technischer Bericht) Department of Linguistics, Brown University, Providence, RI.
Harman, D., E. Fox, R. Baeza-Yates und W. Lee (1992). »Inverted Files.« In: W. B.
Frakes und R. A. Baeza-Yates (Hrsg.), Information Retrieval. Murray Hill, NJ:
Prentice-Hall.
Hausser, R. (1989). Computation of Language. Berlin: Springer.
Hofland, K. (1991). »Concordance programs for personal computers.« In: S. Johansson und A.-B. Stenström (Hrsg.), English Computer Corpora. Selected
Papers and Research Guide. Berlin: Mouton de Gruyter.
Ide, N. und J. Veronis (1994). EAGLES - Corpus Encoding. Technischer Bericht,
Laboratoire Parole et Langue, Aix-en-Provence.
Kaeding (1897). Häufigkeitswörterbuch der deutschen Sprache. Steglitz: Eigenverlag.
Karlsson, F., A. Voutilainen, J. Heikkilä und A. Antilla (Hrsg.) (1995). Constraint
Grammar: A Language-Independent System for Parsing Unrestricted Text. Berlin: Mouton de Gruyter.
Koskenniemi, K. (1983). Two-Level Morphology. A General Computational Model for Word-form Production and Generation. (Publication 11) Department of
General Linguistics, University of Helsinki.
Leech, G. (1987). »General Introduction.« In: R. Garside, G. Leech und G. Sampson (Hrsg.), The Computational Analysis of English. London: Longman.
Leech, G. (1991). »The state of the art in corpus linguistics.« In: K. Aijmer und
B. Altenberg (Hrsg.), English Corpus Linguistics. Studies in Honour of Jan
Svartvik. London: Longman.
Leech, G. und R. Garside (1991). »Running a grammar factory: The production
of syntactically analysed corpora or ‘treebanks’.« In: S. Johansson und A.-B.
Stenström (Hrsg.), English Computer Corpora. Selected Papers and Research
Guide. Berlin: Mouton de Gruyter.
✍ ➘
Lorenz, O. (1996). DMM – Deutsche MALAGA-Morpholgie. Abteilung für Computerlinguistik (CLUE), Friedrich-Alexander-Universität Erlangen-Nürnberg.
Marshall, I. (1987). »Tag selection using probabilistic methods.« In: R. Garside,
G. Leech und G. Sampson (Hrsg.), The Computational Analysis of English.
London: Longman.
McEnery, T. und A. Wilson (1996). Corpus Linguistics. Edinburgh: Edinburgh
University Press.
McWhinney, B. (1991). The CHILDES Project. Tools for Analyzing Talk. Hillsdale,
NJ: Lawrence Erlbaum Associates.
Mehlhorn, K., S. Näher und C. Uhrig (1996). The LEDA User Manual Version R
3.4.1. Max-Planck-Institut für Informatik, Saarbrücken.
Müller, H. H. (1993). »Stärken und Schwächen vier microcomputerfähiger Programme zur Textanalyse.« In: W. Lenders (Hrsg.), Computereinsatz in der
angewandten Linguistik (Forum Angewandte Linguistik 25) Frankfurt a. M.:
Lang.
Palmer, D. D. und M. A. Hearst (1994). »Adaptive sentence boundary disambiguation.« (Technischer Bericht UCB/CSD 94/797) Computer Science Division,
University of California at Berkely.
Renouf, A. (1987). »Corpus Development.« In: J. Sinclair (Hrsg.), Looking Up.
London: Harper-Collins.
Rooth, M. und O. Christ (1994). A Tutorial on Corpus Hacking. Institut für Maschinelle Sprachverarbeitung (IMS), Universität Stuttgart.
Sampson, G. (1995). English for the Computer. Oxford: Clarendon.
Schulze, B. M. (1994). Entwurf und Implementierung eines Anfragesystems für
Textkorpora. (Diplomarbeit 1059) Institut für Maschinelle Sprachverarbeitung
und Institut für Informatik, Universität Stuttgart.
Sinclair, J. (Hrsg.) (1987a). Collins COBUILD English Language Dictionary. London: Harper-Collins.
Sinclair, J. (Hrsg.) (1987b). Looking Up. London: Harper-Collins.
Sinclair, J. (1991). Corpus Concordance Collocation. Oxford: Oxford University
Press.
Sperberg-McQueen, C. M. und L. Burnard (1994). Guidelines for the Electronic
Text Encoding and Interchange (P3). Chicago, Oxford: Text Encoding Initiative
(TEI).
Stevens, W. R. (1992). Advanced Programming in the UNIX Environment. Reading,
MA: Addison-Wesley.
Svartvik, J. (Hrsg.) (1992). Directions in Corpus Linguistics: Proceedings of Nobel
Symposium 82, Stockholm, 4–8 August 1991. (Trends in Linguistics 65) Berlin:
Mouton de Gruyter.
Voutilainen, A. (1994). »Morphological disambiguation.« In: F. Karlsson, A. Voutilainen, J. Heikkilä und A. Antilla (Hrsg.), Constraint Grammar: A LanguageIndependent System for Parsing Unrestricted Text. Berlin: Mouton de Gruyter.
✍ ✃
Document
Kategorie
Internet
Seitenansichten
12
Dateigröße
388 KB
Tags
1/--Seiten
melden