Datenbankgestützte Speicherung von Korpora
Werbung
ISSN 1436-056X CLUE-Arbeitsberichte Nummer 4 CLUE Technical Reports Number 4 Thomas Künneth Datenbankgestützte Speicherung von Korpora CLUE Friedrich-Alexander-Universität Erlangen-Nürnberg Institut für Germanistik Abteilung für Computerlinguistik Prof. Dr. Roland Hausser, Ph. D. Künneth, Thomas: Datenbankgestützte Speicherung von Korpora / Thomas Künneth – 1. Aufl. – Erlangen: Abt. f. Computerlinguistik (CLUE), Friedrich-AlexanderUniversität Erlangen-Nürnberg, 2001 [CLUE-Arbeitsberichte / CLUE Technical Reports, 4; Hrsg. Leidner] ISSN 1436–056X Thomas Künneth 1999–2001. First published 2001. Friedrich-Alexander-Universität Erlangen-Nürnberg Institut für Germanistik Abteilung für Computerlinguistik (CLUE) Bismarckstraße 12 91054 Erlangen Bundesrepublik Deutschland Gesetzt mit LATEX in 11 pt Times und News Gothic. Printed in Germany. v. Jochen Vorwort des Herausgebers Der vorliegende Band ist die vierte Veröffentlichung in der Reihe CLUEArbeitsberichte/CLUE Technical Reports, die wissenschaftliche Arbeiten aus der Computerlinguistik der Forschergemeinschaft in deutscher oder englischer Sprache zur Verfügung stellen und dadurch Aktivitäten der Abteilung für Computerlinguistik (CLUE) der Friedrich-Alexander-Universität Erlangen-Nürnberg dokumentieren möchte. Die zugrundeliegende Magisterarbeit wurde im September 1999 an der Philosophischen Fakultät II (Sprach- und Literaturwissenschaften) eingereicht und angenommen. Thomas Künneth berichtet hier von S AN R EMO, seinem Ansatz zur Verwendung relationaler Datenbank-Managementsysteme (DBMS) für die Speicherung von Korpora. Der Ansatz resultiert aus den Erfahrungen des Systems von Zierl (1997, Band 1 dieser Reihe), das sehr leistungsfähig ist, aber dessen Serverkomponente schwer zu warten und zu portieren war. Hier sollen nunmehr Wartungsarbeiten den RDMBS-Herstellern überlassen werden. Der Autor stellte seine LATEX-Quellen zur Verfügung. Michael Piotrowski entwickelte das Layout dieser Serie und besorgte den Satz auf seiner HP-9000Workstation unter UNIX. Prof. Dr. Roland Hausser, Ph. D. stellte freundlicherweise die finanziellen Mittel für den Druck bereit. Jochen Leidner, M. A. ⟨[email protected]⟩ Über den Autor. Thomas Künneth wurde am 29. August 1970 in Nürnberg geboren. Nach seinem Abitur studierte er an der Friedrich-AlexanderUniversität Erlangen-Nürnberg Linguistische Informatik, Germanistische Linguistik und Neuere deutsche Literaturgeschichte. Im Anschluß an sein Studium übernahm er die Stelle eines wissenschaftlichen Angestellten an der Abteilung für Computerlinguistik der Universität Erlangen-Nürnberg. Dort bereitet er zur Zeit seine Promotion über Speicherung und Abfrage umfangreicher annotierter Korpora vor (Betreuung: Professor Hausser). iii iv Inhaltsverzeichnis Vorwort des Herausgebers 1 2 iii Einleitung 1 1.1 Korpuslinguistik und Korpusdatenbanken . . . . . . . . . . . 1 1.2 Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Definitionen 5 2.1 Korpora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1 Der Korpusbegriff . . . . . . . . . . . . . . . . . . . 5 2.1.2 Inhalt und Struktur . . . . . . . . . . . . . . . . . . . 6 2.1.3 Type-Token-Unterscheidung . . . . . . . . . . . . . . 7 2.1.4 Formaler Aufbau . . . . . . . . . . . . . . . . . . . . 7 2.1.5 Vorstellung einiger Korpora . . . . . . . . . . . . . . 8 Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1 Datenbasis, DBMS, Datenbank . . . . . . . . . . . . 9 2.2.2 Datenbanksprachen . . . . . . . . . . . . . . . . . . . 10 2.2.3 Datenbank-Operationen . . . . . . . . . . . . . . . . 11 2.2.4 Das relationale Datenmodell . . . . . . . . . . . . . . 13 2.2.5 Die Anfragesprache SQL . . . . . . . . . . . . . . . . 14 2.2 2.3 Korpusdatenbanken . . . . . . . . . . . . . . . . . . . . . . 16 2.3.1 Begriffsbestimmung . . . . . . . . . . . . . . . . . . 16 2.3.2 Operationen auf Korpora . . . . . . . . . . . . . . . . 17 2.3.3 Anforderungen an Korpusdatenbanken . . . . . . . . 18 2.3.4 Komponenten einer Korpusdatenbank . . . . . . . . . 19 2.3.5 Vorstellung verfügbarer Systeme . . . . . . . . . . . . 21 v 3 Die Korpusdatenbank SanRemo 23 3.1 Konzepte zur Speicherung von Korpora . . . . . . . . . . . . 23 3.1.1 Eigenentwicklungen . . . . . . . . . . . . . . . . . . 23 3.1.2 Relationale Datenbanksysteme . . . . . . . . . . . . . 24 3.1.3 Notwendige Ergänzungen . . . . . . . . . . . . . . . 25 SanRemo im Überblick . . . . . . . . . . . . . . . . . . . . . 26 3.2.1 Vorstellung des Systems . . . . . . . . . . . . . . . . 26 3.2.2 Die Komponenten im Überblick . . . . . . . . . . . . 27 3.2.3 Zur Wahl einer geeigneten Programmiersprache . . . . 28 3.2.4 Hardware-Basis und Voraussetzungen für den Betrieb . 28 3.2 4 5 6 Das Tabellenmodell von SanRemo 31 4.1 Allgemeine Überlegungen zur Tabellenstruktur . . . . . . . . 31 4.2 Abbildung von Korpuspositionen auf Attribute . . . . . . . . 31 4.3 Der 2-Tabellen-Ansatz . . . . . . . . . . . . . . . . . . . . . 33 4.3.1 Die Normalisierung von Tabellen . . . . . . . . . . . 33 4.3.2 Bewertung der 2-Tabellen-Struktur . . . . . . . . . . 34 4.4 n-Tabellen-Struktur . . . . . . . . . . . . . . . . . . . . . . . 35 4.5 Speicherung textbezogener Informationen . . . . . . . . . . . 36 4.5.1 Zugehörigkeit eines Textes zu einem Korpus . . . . . 37 4.5.2 Speicherung hierarchischer textbezogener Informationen 37 4.6 Zuordnung der beteiligten Tabellen zu einem Korpus . . . . . 38 4.7 Optimierung von Suchanfragen . . . . . . . . . . . . . . . . 39 4.8 Registrierung der Korpora in der Datenbank . . . . . . . . . . 41 4.9 Zusammenfassung der Tabellenstruktur . . . . . . . . . . . . 41 Filter 45 5.1 Allgemeine Bemerkungen . . . . . . . . . . . . . . . . . . . 45 5.2 SGML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.3 Exportfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.4 Importfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.4.1 Generelle Überlegungen . . . . . . . . . . . . . . . . 47 5.4.2 Importfilter für das BNC . . . . . . . . . . . . . . . . 48 Korpusanfragen 51 6.1 Korpusanfragen in SQL . . . . . . . . . . . . . . . . . . . . 51 6.1.1 SQL als Benutzeranfragesprache . . . . . . . . . . . . 51 6.1.2 SQL als Basis für Korpusanfragen . . . . . . . . . . . 51 6.1.3 KWIC-Listen . . . . . . . . . . . . . . . . . . . . . . 52 Allgemeine Anforderungen . . . . . . . . . . . . . . . . . . 52 6.2 vi 7 6.3 SgmlQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.4 Grafische Benutzeroberflächen . . . . . . . . . . . . . . . . . 53 Zusammenfassung 55 7.1 SanRemo im praktischen Einsatz . . . . . . . . . . . . . . . 55 7.1.1 Import des BNC . . . . . . . . . . . . . . . . . . . . 55 7.1.2 Anfragen . . . . . . . . . . . . . . . . . . . . . . . . 55 7.1.3 Einfügevorgänge . . . . . . . . . . . . . . . . . . . . 56 7.2 Zusammenfassung und Bewertung der Praxistauglichkeit . . . 56 7.3 Mögliche Erweiterungen . . . . . . . . . . . . . . . . . . . . 56 vii viii Abbildungsverzeichnis 2.1 Beziehung zwischen Type und Token . . . . . . . . . . . . . . 7 3.1 Schema einer RDBMS-basierten Korpusdatenbank . . . . . . 25 4.1 Beziehung zwischen den Tabellen types und tokens . . . . . . 34 4.2 Beispiel einer n-Tabellen-Struktur . . . . . . . . . . . . . . . 36 4.3 Darstellung von Kategorien in der Tabelle info . . . . . . . . . 38 4.4 An der n-Tabellen-Struktur beteiligte Tabellen . . . . . . . . . 42 ix x 1 Einleitung 1.1 Korpuslinguistik und Korpusdatenbanken Traditionell beschäftigen sich linguistische Untersuchungen mit der Struktur von Sprache. Hierbei stehen die Elemente sprachlicher Kommunikation sowie ihre Beziehung zueinander, insbesondere das Verknüpfen von kleineren Einheiten zu komplexeren Konstruktionen, im Mittelpunkt. Die Korpuslinguistik untersucht Sprache aus einem anderen Blickwinkel: Sie analysiert die tatsächliche Verwendung von Sprache in bestimmten Situationen, wobei sowohl lexikalische wie syntaktische Einheiten Gegenstand der Untersuchung sein können. Basis aller korpuslinguistischen Arbeiten sind Textsammlungen, die nach bestimmten Kriterien zusammengestellt wurden. Solche Korpora bieten einen Ausschnitt sprachlicher Kommunikation, an dem bestimmte linguistische Phänomene untersucht werden können. Die Verwendung von Korpora ist nicht an den Einsatz von Computern gebunden. Schon vor der allgemeinen Verfügbarkeit von Computern wurde korpuslinguistische Forschung betrieben. Allerdings stellen Rechner bei der Arbeit mit Korpora eine enorme Arbeitserleichterung dar. Zudem wären viele der heute verfügbaren Korpora ohne leistungsfähige Computeranlagen alleine aufgrund ihrer Größe nicht zu warten. Die Steigerung der Leistungsfähigkeit der Maschinen läßt sich an der Größe bekannter Computerkorpora belegen. Bestand ein Korpus, das 1964 an der Brown University entwickelt wurde, aus 500 Texten mit jeweils ungefähr 2000 Wörtern, enthielt die Bank of English am 20.7.1998 329 Millionen Wörter. Hierbei spiegelt die Größe des Brown Corpus die Informationsmenge wieder, die sich zur Zeit dessen Entstehung mit Rechnern zu vertretbaren Kosten verarbeiten ließen. Zwar spielen Faktoren wie Rechengeschwindigkeit sowie die Kapazität der Massenspeicher aufgrund der Entwicklung der elektronischen Datenverarbeitung in den letzten dreißig Jahren nunmehr eine zu vernachlässigende Rolle, allerdings läßt sich eine solche Menge an Informationen nur mit geeigneten, spezialisierten Werkzeugen sinnvoll verarbeiten. 1 Programmsysteme, die eine Korpusanalyse ermöglichen, werden oft als Korpusdatenbanken (engl.: Corpus Query Systems) bezeichnet. Die vorhandenen Systeme basieren zumeist auf eigens entwickelten Datenbankkernen mit proprietärer Anfragesprache und uneinheitlicher Bedienung. Deren Implementierung und Wartung is aufwendig, eine Übertragung auf andere RechnerSysteme häufig problematisch. Aus diesen Gründen erscheint eine Suche nach Alternativen gerechtfertigt. 1.2 Ziel der Arbeit Gegenstand dieser Arbeit ist die Untersuchung der Verwendbarkeit von herkömmlichen relationalen Datenbanksystemen für die Speicherung und Abfrage umfangreicher Korpora. Im Verlauf der Arbeit wurde eine experimentelle Korpusdatenbank entwickelt, die auf der Basis eines geeigneten Tabellenmodells Korpusdaten sowie Annotationen speichern kann. In der Programmiersprache Perl geschriebene Werkzeuge erlauben das Einfügen von Korpora in die Datenbank sowie rudimentäre Anfragen an das System. Die Korpusdatenbank trägt den Namen S AN R EMO. Das Akronym steht für corpus analysis based on the relational model. Um eine grundsätzliche Praxistauglichkeit des verwendeten Tabellenmodells sowie der entwickelten Komponenten zu überprüfen, wurden Teile des British National Corpus in die Korpusdatenbank eingelesen. 1.3 Gliederung Diese Magisterarbeit beschäftigt sich mit den für die maschinelle Speicherung und Verarbeitung von Korpora notwendigen linguistischen und informationstechnischen Konzepten, die die Basis für die Implementierung einer Korpusdatenbank unter Verwendung eines relationalen Datenbanksystems bilden, und stellt Erkenntnisse, die sich im Rahmen der Implementierung von S AN R EMO ergaben, vor. Das zweite Kapitel beschäftigt sich mit den Themenkomplexen Korpora, Datenbanken und Korpusdatenbanken. Hierbei werden Begriffe aus dem Bereich Korpuslinguistik diskutiert. Ferner werden relationale Datenbanksysteme vorgestellt sowie Anforderungen und Komponenten von Korpusdatenbanken erörtert. Kapitel 3 diskutiert Eigenentwicklungen im Vergleich zu relationalen Datenbanksystemen als Basis für Korpusdatenbanken. Anschließend wird S AN R E MO und dessen Aufbau sowie die verfügbaren Komponenten vorgestellt. Das vierte Kapitel stellt Ansätze für die Speicherung von Korpusdaten in SQLTabellen vor und beschreibt die in S AN R EMO verwendeten Tabellen und Attribute. Kapitel 5 führt das in S AN R EMO verwendete Filter-Konzept ein und diskutiert dessen Vorteile. Ferner wird die Implementierung eines Importfilters für das Einlesen von Korpusdaten des British National Corpus vorgestellt. 2 Das sechste Kapitel widmet sich dem Komplex der Anfragesprachen und Interaktion mit dem Anwender und diskutiert allgemeine Anforderungen an Anfragesprachen. Kapitel 7 faßt die Ergebnisse der Magisterarbeit zusammen, beschreibt Erfahrungen im praktischen Einsatz von S AN R EMO und nennt Problemfelder sowie mögliche Ergänzungen der vorgestellten Korpusdatenbank. 3 4 2 Definitionen Dieses Kapitel thematisiert die Bereiche Korpuslinguistik und Datenbanken. Ferner werden spezielle Datenbanksysteme für die Speicherung und Abfrage von Korpora beschrieben. In diesem Zusammenhang werden Anforderungen an solche Systeme diskutiert sowie verfügbare Programme vorgestellt. 2.1 Korpora 2.1.1 Der Korpusbegriff Der Begriff Korpus findet in unterschiedlichen Bedeutungen Verwendung. In seiner allgemeinen Form bezeichnet er Sammlungen von Texten, die aus formalen oder inhaltlichen Gründen als zusammen gehörig angesehen werden. Beispielsweise bildet das Werk eines Schriftstellers oder ein Teil davon ein Korpus. Die Zugehörigkeit eines Textes zu diesem Korpus ergibt sich aus der Urheberschaft des Verfassers.1 In der Korpuslinguistik wird der Begriff enger gefaßt. Korpora werden gezielt zusammengestellt, wobei die Auswahl der Texte aufgrund ihrer Zugehörigkeit zu einer bestimmten Kategorie oder Domäne erfolgt. Aus diesem Grund decken Korpora immer einen (durch die Auswahl der Texte vorgegebenen) Ausschnitt einer Sprache ab. Francis definiert ein Korpus als „a collection of texts assumed to be representative of a given language, dialect, or other subset of a language, to be used for linguistic analysis“2 . Die Auswahl von Texten kann auch aufgrund nichtsprachlicher Kriterien erfolgen oder durch außersprachliche Faktoren beeinflußt werden, allerdings geschieht eine entsprechende Auswahl stets vor dem Hintergrund des intendierten Zwecks eines Korpus. Dies läßt sich am Beispiel des Brown Corpus aufzeigen. Es wurde von W. Nelson Francis und Henry Kucera an der Brown University zusammengestellt 1 2 Siehe hierzu [Aston 1998, S. 4] [Svartvik 1992, S. 17] 5 und 1964 erstmals zugänglich gemacht. Das Korpus enthält englischsprachige Prosa, die in den USA während des Kalenderjahres 1961 gedruckt wurde. 3 Neben der auf dem Inhalt basierenden Einteilung in Kategorien sind für eine Auswahl eines potentiellen Textes auch textexterne Kriterien wie dessen Erscheinungsjahr von Belang. Die Erstellung oder Bearbeitung von Korpora ist im Prinzip nicht an die Verwendung von Computern gebunden, allerdings gestatten Rechner einen äußerst flexiblen und schnellen Zugriff auf den Datenbestand. Aston und Burnard bemerken hierzu: „It is worth noting however that there is very little in the practice of corpus linguistics which could not equally well be done in principle by non-automatic means. However, in general, corpora are understood to be computer-processable corpora.“ 4 Zudem hat sich die durchschnittliche Größe von Korpora, die sich aus der Zahl der Wortformen aller Texte sowie zusätzlich gespeicherten Informationen ergibt, in den letzten 30 Jahren vervielfacht. Das Brown Corpus besteht beispielsweise aus 500 Texten zu jeweils ca. 2000 Wörtern. Das Mitte der Neunziger fertiggestellte British National Corpus (BNC) hingegen besteht aus über 100 Millionen laufender Wortformen. Erscheint die Erschließung des Brown Corpus ohne Rechnerunterstützung zumindest theoretisch noch möglich, ist dies im Falle des BNC auszuschließen. Solch enorme Datenmengen lassen sich nur mit spezialisierten Werkzeugen effizient verarbeiten, die eine zumindest teilweise Automatisierung von Analysen ermöglichen. 2.1.2 Inhalt und Struktur Ziel bei der Erstellung von Korpora ist die Dokumentierung eines bestimmten Ausschnitts oder Aspekts einer Sprache. Dieser ist bei der Auswahl der Texte zu berücksichtigen. Ferner sind Überlegungen, die die Anzahl der einzubeziehenden Texte sowie die Zahl der Wortformen je Text betreffen, anzustellen. Solche Anforderungen werden in der Design-Phase formuliert. Hierbei ist auch zu entscheiden, ob ein Korpus nach der Auswahl der Texte als abgeschlossen gilt, ob Texte zyklisch ausgetauscht werden oder der Textbestand stetig erweitert wird. Sinclair unterscheidet in diesem Zusammenhang zwischen sample corpora und monitor corpora.5 Sample corpora können nach der Auswahl der Texte als abgeschlossene Projekte gelten. Korrekturen am Korpusmaterial sind möglich, etwa um Fehler zu beseitigen, die während der Übertragung eines Textes in elektronische Form entstanden sind und erst nach Fertigstellung des Korpus gefunden wurden. Neue Texte werden allerdings nicht eingebracht. Solche Korpora dokumentieren den Zustand einer Sprache bzw. eines durch das Korpus abgedeckten sprachlichen Phänomens zu einem durch die Auswahl der Texte festgelegten Zeitpunkt bzw. Zeitabschnitt. Das British National Corpus sowie das Brown Corpus sind Beispiele für sample corpora. Monitor corpora hingegen werden laufend erweitert und spiegeln daher den aktuellen Zustand einer Sprache wider. Da durch die regelmäßigen Aktuali3 4 5 6 Siehe hierzu [Francis 1964] [Aston 1998, S. 5] [Sinclair 1991, S. 23f] sierungen umfangreiche Datenmengen anfallen, stellen monitor corpora hohe Anforderungen an das verwendete System in Bezug auf verfügbaren Speicherplatz sowie Rechengeschwindigkeit. Das 1991 durch die University of Birmingham und COBUILD gestartete Projekt Bank of English 6 ist mit 329 Millionen Wortformen ein sehr umfangreiches monitor corpus. Häufig enthalten Korpora Informationen, die zusätzlich zu den eigentlichen Texten abgespeichert werden. Solche Daten können sich auf ganze Texte sowie einzelne Wortformen beziehen. Erstere beinhalten Angaben zu Herkunft, Verfasser oder etwaigen Copyright-Bestimmungen der Texte eines Korpus. Solche Informationen können bei Anfragen sinnvoll sein, um etwa den Suchraum gezielt einzuschränken. Von großer Bedeutung sind auch Korpus-Annotationen, die etwa die Klassen der gespeicherten Wortformen enthalten oder Hinweise auf die Grundform eines Wortes geben. Im Idealfall liegen diese Informationen für jede Wortform vor. Allerdings können sich solche Informationen auch auf Ebenen zwischen Text und Wortform beziehen, etwa, wenn spezielle Markierung Anfang oder Ende von Überschriften, Absätzen oder Kapiteln kennzeichnen. Computer-basierte Korpora sollten in jedem Fall Zugriff auf solche Informationen ermöglichen. Gerade die Suche nach sprachlichen Phänomenen, die sich nicht nur in Wortformen manifestieren, machen Korpora für die linguistische Analyse wertvoll. 2.1.3 Type-Token-Unterscheidung Das linguistische Konzept der Unterscheidung zwischen Types und Tokens wurde durch den amerikanischen Philosophen C. S. Peirce (1839–1914) eingeführt. Tokens sind konkrete Realisierungen einer (abstrakten) Form, dem Type. Im Falle des Wortes linguistics entspricht jedes Auftreten einer solchen Zeichenkette einem Token. Alle Token, die der gleichen Zeichenkette entsprechen, verweisen auf ein Type. Abbildung 2.1 verdeutlicht diesen Sachverhalt. Abbildung 2.1: Beziehung zwischen Type und Token Type Text Token Dieser Text besteht aus Tokens. Ein weiterer Text. 2.1.4 Formaler Aufbau Jedes Korpus besteht aus einer Menge von Texten, deren Länge im Prinzip beliebig variieren kann. Allerdings wird man in der Regel auf eine annähernd identische Textgröße achten, um eine ausgewogene Verteilung der Wortformen zu gewährleisten. Bei den Wortformen eines Korpus handelt es sich um konkrete Realisierungen, also Tokens. Die Gesamtmenge aller Token eines Korpus ergibt eine Abfolge von n Korpuspositionen. Hierbei wird jeder Position eine bestimmte Zahl 6 ⟨http://www.cobuild.collins.co.uk/boe_info.html⟩ 7 positionaler Attribute zugeordnet. Christ und Schulze definieren positionale Attribute als solche, „bei der jeder Corpusposition eine Zeichenkette zugeordnet ist. Insbesondere zählt die Sequenz der Wörter, aus denen das Corpus aufgebaut ist, zu den positionalen Attributen“ 7 . Weitere mögliche positionale Attribute sind grammatische Kategorien (beispielsweise part of speech tags) sowie die Grundformen der Wörter eines Textes. Jedes positionale Attribut erhält einen eindeutigen Bezeichner, der den Zugriff auf die an einer bestimmten Korpusposition gespeicherten Informationen ermöglicht. Für die obligatorische Wortsequenz wird im allgemeinen der Attributname word verwendet, die grammatische Kategorie part of speech wird mit POS gekennzeichnet. Sei m die Zahl der positionalen Attribute eines Korpus, dann enthält jede Korpusposition i mit 1 ≤ i ≤ n genau m Name-WertPaare. Die Größe n entspricht hierbei der Gesamtzahl der im Korpus abgelegten Token und bestimmt sich aus der Zahl der Texte, die ein Korpus enthält, sowie der Zahl der Wortformen je Text. Wurde ein Korpus mit grammatischen Kategorien annotiert, ergibt die Menge aller verwendeten Kategorie-Ettiketten das sog. tag set. Wie im letzten Abschnitt dargelegt wurde, enthält ein Korpus zumeist textbezogene Informationen, die Auskunft über Ursprung, Verfasser, Sparte oder Domäne eines Textes geben. Solche Angaben lassen sich nicht bestimmten Korpuspositionen zuordnen. Ein Korpusdatenbanksystem sollte dem Anwender jedoch die Möglichkeit geben, vorhandene Informationen abzufragen und ggf. fehlende Informationen zu ergänzen. 2.1.5 Vorstellung einiger Korpora Die Bedeutung computerbasierter Korpora für die linguistische Forschung hat in den letzten Jahren stark zugenommen. Ein Grund hierfür ist die Verfügbarkeit von Korpora mit mehr als 50 Millionen Wortformen. Diese ermöglichen eine Forschung in Bereichen, die sich durch kleine Korpora nicht erschließen lassen. Sinclair bemerkt hierzu: „The received wisdom of corpus linguistics is that fairly small corpora, of one million words or even fewer, are adequate for grammatical purposes, since the frequency of occurrence of so-called grammatical or functional words is quite high. [...] However, the availability nowadays of much larger corpora makes it possible to evaluate conventional grammatical statements.“ 8 2.1.5.1 The Brown Corpus Das Brown Corpus wurde ab 1961 von W. Nelson Francis und Henry Kucera an der Brown University speziell für den Einsatz mit Computern entwickelt. Als erstes computerbasiertes Korpus hat es nicht nur im Hinblick auf Umfang, Auswahl der Kategorien und allgemeinen Aufbau Vorbildcharakter. 7 8 8 [Christ 1994, S. 2f] [Sinclair 1991, S. 100] Die Erstellung des LOB (Lancaster-Oslo-Bergen) Korpus, das Aufbau und Struktur des Brown Corpus in Verbindung mit britisch englischen Texten übernimmt, sowie des LIMAS Korpus als Beispiel für ein deutschsprachiges Korpus verdeutlichen die Bedeutung des Brown Corpus. Das Korpus wurde mehrfach redigiert und kann daher als fehlerfrei betrachtet werden. 2.1.5.2 The British National Corpus Das British National Corpus (BNC) wurde zusammengestellt, um das gegenwärtig gebräuchliche britische Englisch möglichst umfassend zu dokumentieren. Es besteht zu 90 Prozent aus geschriebener Sprache. Die Texte wurden anhand der drei Kriterien Domäne, Jahr der Entstehung sowie Form der Veröffentlichung ausgewählt. Jedes Auswahlkriterium wurde ferner in verschiedene Kategorien unterteilt, für die ein prozentualer Anteil am Gesamtkorpus festgelegt wurde. 2.1.5.3 The Bank of English Ein Beispiel für ein sehr umfangreiches englisches Monitorkorpus ist die Bank of English (BoE). Das 1991 an der Universität Birmingham begonnene Projekt umfaßte im Juli 1998 329 Millionen laufende Wortformen. Das Korpus wird laufend um Textauszüge aus den unterschiedlichsten Quellen, etwa Zeitungen, Zeitschriften, Broschüren oder Flugblättern erweitert. Wie das BNC enthält die BoE gesprochene Sprache, die in transkribierter Form aufgenommen wird. Um auch gesprochene Sprache erfassen zu können, werden die Texte vor einer Übernahme in das Korpus transkribiert. 2.2 Datenbanken 2.2.1 Datenbasis, DBMS, Datenbank Der Begriff Datenbank wird häufig verallgemeinernd als Synonym für Datenbasis und Datenbanksystem gebraucht. Gerade die Gleichsetzung der Begriffe Datenbasis und Datenbanksystem ist aus technischer Sicht nicht zu rechtfertigen. Die Beziehung zwischen den genannten Termini soll daher in diesem Abschnitt dargestellt werden. Eine sehr allgemeine Umschreibung des Begriffs Datenbank geben Elmasri und Navathe: „A database is a collection of related data.“ 9 . Da auch die Wörter auf den Seiten eines Buches zueinander in Beziehung stehen, müßte ein solches Schriftstück als Datenbank angesehen werden, wenn man dieser allgemeinen Beschreibung folgt. Da dies zu verneinen ist, schreiben Elmasri und Navathe einer Datenbank mehrere indirekte Eigenschaften zu: „[...]a database has some source from which data are derived, some degree of interaction with events in the real world, and an 9 [Elmasri 1989, S. 3] 9 audience that is actively interested in the contents of the database.“10 . Der Zugriff auf die in einer Datenbank gespeicherten Informationen muß nicht zwingend in der Reihenfolge stattfinden, in der sie abgelegt wurden. Das Konzept einer Datenbank läßt sich keineswegs nur mit Computern realisieren. Adreßbücher und die aus Bibliotheken bekannten Karteikarten zur Verwaltung des Zeitschriften- und Bücherbestands genügen den skizzierten Anforderungen. Allerdings bieten Rechner zahlreiche Vorteile gegenüber einer manuellen Verwaltung. Beispielsweise können geeignete Programme auch umfangreiche Datenbestände in kurzer Zeit durchsuchen. Ferner können die Informationen auf unterschiedlichste Weise sortiert werden. Im Rahmen dieser Arbeit ist unter dem Begriff Datenbank ein computergestütztes System zu verstehen, sofern nicht ausdrücklich auf eine andere Bedeutung hingewiesen wird. Neben den eigentlichen Daten gehören dann eine geeignete Rechenanlage sowie spezielle Software zu einer Datenbank. Werkzeuge, die das Anlegen und Pflegen von Datenbeständen ermöglichen, bilden zusammen das Datenbasis-Management-System, das oft auch als Datenbanksystem, Datenbankverwaltungssystem, Database Management System oder DBMS bezeichnet wird. Dieses operiert auf der Datenbasis. Sie ist definiert als eine „Sammlung strukturierter Daten in einem entsprechend organisierten Speicher, zusammen mit denjenigen Daten, welche die Datenmodelle, die zugehörigen Datenstrukturen und die entsprechende Speicherorganisation beschreiben und zueinander in Bezug setzen“11 . Die Datenbasis enthält die zu speichernden Informationen in strukturierter Form. Sie wird mit dem DBMS aufgebaut und kontrolliert. Mit Hilfe einer Datenbeschreibungssprache (data description language) wird festgelegt, wie sich die Struktur der Daten dem Benutzer darstellt. Die Repräsentation der Daten auf dem Massenspeicher kann sich völlig von dieser logischen Sichtweise unterscheiden. Mit Hilfe der Datenbeschreibungssprache werden Satztypen sowie die ihnen zugeordneten Datenfelder benannt, und die Beziehungen zwischen einzelnen Sätzen festgelegt. 12 2.2.2 Datenbanksprachen Der Begriff Datenbanksprache faßt die Termini Datenbeschreibungssprache, Datendefinitionssprache und Datenmanipulationssprache zusammen. Die durch die Trennung der Begriffe suggerierte Unabhängigkeit der einzelnen Sprachen wird in der Praxis häufig durchbrochen. Beispielsweise enthält die noch ausführlich vorzustellende Sprache SQL sowohl Elemente einer Datenbeschreibungs- als auch einer Datenmanipulationssprache. Mit der Datenbeschreibungssprache wird, wie im vorangehenden Abschnitt erläutert wurde, die logische Struktur einer Datenbank festgelegt. Die Daten10 [Elmasri 1989, S. 4] 1997, →Datenbasis] 12 nach [Schneider 1997, →Datenbeschreibungssprache] 11 [Schneider 10 definitionssprache gestattet in generalisierten Datenbanksystemen die Definition von Schemata, die einen freien Zugriff auf beliebige Informationsbereiche ermöglichen. Schemata sind „Formale und in den meisten Fällen deskriptive (deklarative) Definitionen der in der Datenbank zugelassenen Typen von Datenstrukturen“13 . Die Datenmanipulationssprache (engl.: Data Manipulation Language, DML) dient dem Ausführen grundlegender Datenbank-Operationen. Dabei kann eine DML entweder in eine höhere Programmiersprache eingebettet oder als eigenständige Sprache realisiert werden. In diesem Fall wird sie häufig als Abfragesprache (engl.: Query Language) bezeichnet. 14 2.2.3 Datenbank-Operationen Durch das Generieren einer neuen Datenbasis werden die Voraussetzungen für spätere Zugriffe auf die Daten geschaffen, indem beispielsweise Speicher reserviert und die Zuordnung zwischen der durch eine Datenbeschreibungssprache vorgegebenen logischen Struktur und der physikalischen Repräsentation der Daten auf dem Massenspeicher hergestellt wird. Im allgemeinen gehen der Einrichtung einer Datenbasis umfangreiche Überlegungen zu Umfang, Zusammensetzung und Inhalt der Daten voraus, da die Struktur der Datenbank großen Einfluß auf die Antwortzeiten des Systems bei Anfragen hat und umfassende Änderungen am Aufbau der Datenbank im laufenden Betrieb nur mit großem Aufwand möglich sind. Ein weiterer grundlegender Vorgang ist das Einbringen neuer Daten in die Datenbank. Dies kann sowohl mit Elementen der DML erfolgen als auch durch spezielle Werkzeuge des DBMS. Der Vorteil bei der Verwendung einer Datenmanipulationssprache liegt in der gleichen Handhabung auf jedem Datenbanksystem, das die DML unterstützt. Allerdings stößt ihre Verwendbarkeit an Grenzen, wenn umfangreiche Datenmengen in die Datenbank eingefügt werden müssen. Eigene Versuche, die im Rahmen dieser Arbeit durchgeführt wurden, zeigen, daß die für das Einfügen einer bestimmten Menge an Daten benötigte Zeit bei Verwendung von Elementen der Anfragesprache SQL erheblich größer ist als bei Verwendung DBMS-spezifischer Dienstprogramme. Die Möglichkeit, im Datenbestand zu suchen, wird durch eine DML bereitgestellt und dient neben dem Auffinden abgelegter Informationen auch als Auswahl- oder Verknüpfungskriterium für weitere Operationen auf der Datenbasis. In diesem Zusammenhang sind verschachtelte Suchanfragen zu nennen, aber auch kombinierte Such- und Löschoperationen. Bei einer verschachtelten Suchanfrage wird ein Auswahlkriterium benutzt, um aus der Datenbasis Informationen zu erhalten. Ein weiteres Kriterium wird dann auf die durch den ersten Vorgang ermittelten Daten angewendet. Neben dem Einbringen und Suchen von Daten steht als weitere grundlegende Operation das Löschen von Informationen zur Verfügung. Löschvorgänge können mit Suchanfragen verknüpft werden. In diesem Fall werden diejenigen Daten gelöscht, die dem angegeben Auswahlkriterium genügen. Beispielsweise ließen sich aus einer Datenbank, die Bestellungen verwaltet, alle Aufträge 13 [Schneider 14 nach 1997, →Schema] [Schneider 1997, →Datenmanipulationssprache] 11 löschen, die bereits ausgeführt wurden oder deren Eingang mehr als drei Jahre zurück liegt. Neben den vorgestellten Operationen stellen Datenbanksysteme zumeist zusätzliche administrative Funktionen zur Verfügung, die etwa das Anlegen von Sicherungskopien der Datenbank gestatten, Konsistenzprüfungen des Datenbestands durchführen oder eine Zugriffskontrolle ermöglichen. 12 2.2.4 Das relationale Datenmodell Das relationale Modell bildet die formale Grundlage für viele Datenbanksysteme. Drei Teilbereiche befassen sich dabei mit der Frage nach • der Struktur von Daten • deren Integrität • der Möglichkeit ihrer Manipulation Im relationalen Datenmodell werden Informationen als eine Menge von Relationen gespeichert. Dabei entsprechen solche Relationen im Wesentlichen den Tabellen der Datenbanksprache SQL. Die theoretischen Grundlagen des relationalen Modells formulierte E. F. Codd 1970 in seinem Artikel A Relational Model of Data for Large Shared Data Banks. Date bemerkt in Bezug auf die Bedeutung der Veröffentlichung: „The entire field of relational database technology has its origins in that paper.15 .“ Systeme, die auf den Prinzipien des relationalen Modells basieren, werden im allgemeinen als relationale Datenbanksysteme bezeichnet. Eine Domäne (engl.: domain) faßt atomare Elemente gleichen Typs zusammen. Solche elementaren Objekte lassen sich im Sinne des relationalen Modells nicht weiter zerlegen. Date bezeichnet sie daher auch als Skalare 16 . Dabei wird einer Domäne ein Name, ein Datentyp sowie ein Format zugewiesen. Elmasri und Navathe nennen als Beispiele möglicher Domänen unter anderem die Menge aller gültigen 10-stelligen Telefonnummern in den Vereinigten Staaten, die Menge aller gültigen 9-stelligen Sozialversicherungsnummern, oder die (Teil-)Menge von Personennamen. 17 Ein möglicher Name für die Domäne US-amerikanischer Rufnummern wäre USAPhoneNumbers, als Format ließe sich die Zeichenkette (ddd)ddd-dddd angeben, wobei d eine Ziffer repräsentiert.18 An diesem Beispiel wird auch deutlich, daß Domänen und Datentypen keineswegs immer gleichzusetzen sind. Im Sinne des Datentyps gültige Skalare müssen keineswegs den durch die Domäne vorgegebenen Einschränkungen genügen. Beispielsweise ergibt nicht jede aus drei Ziffern bestehende Zahl einen in den Vereinigten Staaten gültigen area code. Domänen werden in Verbindung mit Attributen verwendet. Jedem Attribut wird neben einem Namen eine Domäne zugeordnet, die festlegt, welche Werte das Attribut annehmen kann. Da die Domäne eines Attributs dessen mögliche Inhalte charakterisiert, bestimmt die Menge der verwendeten Attribute die inhaltliche Struktur einer Relation. Eine solche Attributmenge heißt Relationsschema. Der Begriff Relation bezeichnet die tatsächliche Realisierung eines Relationsschemas (das häufig auch heading genannt wird) in Verbindung mit einer als body bezeichneten Menge von n-Tupeln. Ein n-Tupel enthält Attribut-WertPaare, deren Anzahl von den im Relationsschema angegebenen Attributen abhängig ist. Die Werte eines Attributs sind zwingend Elemente der dem Attribut 15 [Date 1997, S. 4] 1990, S. 251] 17 [Elmasri 1989, S. 136] 18 a. a. O. 16 [Date 13 zugewiesenen Domäne, haben also einen festen Wertebereich. Relationen haben stets folgende Eigenschaften: Tupel können nicht mehrfach auftreten, ihre Reihenfolge ist unbestimmt, ebenso die Abfolge der Attribut-Werte-Paare innerhalb eines Tupels. Ferner sind die Werte aller Attribute stets atomar. Aus der ersten Eigenschaft ergibt sich, daß jede Relation einen primären Schlüssel enthält. Diese sind Attribute, die zu keiner Zeit in mehr als einem Tupel den gleichen Wert enthalten können. Der Grad (degree) einer Relation entspricht der Zahl der Elemente der Relationsschemas. Er ist für eine Relation konstant. Die Kardinalität (cardinality) einer Relation gibt die Zahl der einer Relation zugeordneten n-Tupeln an. Sie ist zeitabhängig. 19 Veränderungen an der Zahl der Tupel einer Relation ergeben sich aus Operationen, die auf die Relation angewendet werden können. Die relationale Algebra definiert acht solche Operatoren, die eine oder zwei Relationen als Operanden haben, und eine neue Relation als Ergebnis liefern: RESTRICT, PROJECT, PRODUCT, UNION, INTERSECT, DIFFERENCE, JOIN, DIVIDE. Das Verknüpfen dieser Basisoperationen zu komplexen Ausdrücken kann aus unterschiedlichsten Gründen erfolgen. Date nennt als Beispiel unter anderem die Vergabe von Zugriffsrechten. 20 . In jedem Fall erlauben Ausdrücke aus der relationalen Algebra den sowohl lesenden (abfragenden) als auch schreibenden (manipulierenden) Zugriff auf Relationen, letztlich also den Datenbestand einer Datenbasis. 2.2.5 2.2.5.1 Die Anfragesprache SQL Entstehung und Entwicklung der Sprache Die Datenbankanfragesprache SQL hat Einzug in zahlreiche kommerziell vermarktete Datenbanksysteme gehalten und ist ferner ein durch die Gremien ANSI (American National Standards Institute) und ISO (International Organization for Standardization) normierter Standard. Ursprünglich wurde der Name SQL als Akronym für Structured Query Language interpretiert, zumindest in der standardisierten Form der Sprache steht er mittlerweile für sich selbst. 21 1974 definierte Donald Chamberlin am IBM Forschungslaboratorium in San Jose, Kalifornien, die Sprache SEQUEL (Structured English Query Language). Sie wurde als Prototyp (SEQUEL-XRM) implementiert. 1976/77 entstand SEQUEL/2, wurde aus rechtlichen Gründen jedoch in SQL umbenannt. 1977 wurde System R fertiggestellt, ein weiterer Prototyp, der einen großen Teil von SQL unterstützte. Der große Erfolg von System R – IBM hatte das System nicht nur intern eingesetzt, sondern auch an ausgewählte Kunden weitergegeben – veranlaßte neben IBM selbst auch andere Firmen, SQL-basierte Produkte zu entwickeln.22 2.2.5.2 Anwendungsmöglichkeiten SQL bietet die Möglichkeit, Daten bzw. deren Struktur zu definieren, auf sie lesend und schreibend zuzugreifen sowie sie anderweitig zu manipulieren. Dabei können Konstrukte zum einen direkt eingegeben werden, zum anderen besteht die Möglichkeit, SQL-Befehle in Programme einer höheren Programmiersprache einzubetten. Im ersten Fall stellt das Datenbanksystem eine Kom19 nach [Date 1990, S. 257ff] 1990, 314] 21 siehe hierzu [Date 1997, S. 3f] 22 ebenda 20 [Date 14 mandozeile zum Eingeben der Befehle zur Verfügung. Unmittelbar nach der Eingabe wird das System die Anfrage ausführen und das Ergebnis auf dem Bildschirm ausgeben. Der unmittelbare Dialog zwischen Benutzer und Maschine hat den Vorteil, daß sehr leicht verschiedene Anfragestrategien getestet werden können. Auf der anderen Seite erfordern gerade komplexe Suchmuster zahlreiche SQL-Schlüsselwörter, was die Eingabe der Suchanfrage langwierig und fehleranfällig macht. Außerdem werden ausgegebene Tabellen häufig elektronisch weiter verarbeitet. Das Einbetten von SQL-Konstrukten in eine höhere Programmiersprache gestattet dem Programmierer eben diese Weiterbearbeitung auf effiziente Weise. Hierzu werden die Ergebnisse von Suchanfragen unmittelbar an Variablen gebunden, die für weitere Berechnungen ausgewertet werden können. Im folgenden werden einige ausgewählte SQL-Befehle vorgestellt. SQL Anweisungen sind formatfrei, die Einrückungen dienen ausschließlich einer besseren Lesbarkeit. 23 Grundlage für die Arbeit in SQL sind Tabellen. Sie sind im wesentlichen Entsprechungen der Relationen des durch Codd eingeführten Modells. Der Befehl CREATE TABLE generiert eine solche Basistabelle (base table). Die Parameter der Anweisung legen die Namen der Tabelle und der Attribute sowie deren Datentyp fest. CREATE TABLE bestimmt demzufolge die Struktur der Daten. Im Gegensatz zu views24 werden Basistabellen in einem Massenspeicher abgelegt. Views hingegen werden zwar wie Basistabellen behandelt, spiegeln aber nur eine bestimmte Sichtweise von Daten wider. Sie werden beispielsweise eingesetzt, um nur einen Teil der abgelegten Informationen verfügbar zu machen. Views haben allerdings keine physikalische Entsprechung, bestehen letztlich aus Daten von Basistabellen. 2.2.5.3 Einfache SQL-Konstrukte Aufgrund der Normierung von SQL durch die ISO sind die folgenden Beispiele auf jedem relationalen Datenbanksystem, das die direkte Eingabe von SQLKonstrukten gestattet, ausführbar, wenn das System vollständig installiert wurde und durch den Datenbank-Administrator eine Datenbank eingerichtet wurde. Hierfür findet häufig die Anweisung CREATE DATABASE Verwendung. CREATE TABLE korpus ( word VARCHAR (64) NOT NULL , PRIMARY KEY(word ) ) Die Eingabe dieses Befehls generiert eine Basistabelle mit dem Namen korpus. Sie beinhaltet das Attribut word, das Zeichenketten bis zu 64 Zeichen Länge aufnehmen kann. Das Schlüsselwort NOT NULL 25 erzwingt eine Wertzuweisung, es kann keine Zeile der Tabelle leer sein. PRIMARY KEY schließlich legt word als primären Schlüssel fest. Dieser erzwingt, daß kein Wort (als Wert von word) mehrfach vorkommen kann. 23 Die vorgestellten Beispiele sind vollständig und funktionsfähig. Es sei aber darauf hingewiesen, daß nicht alle möglichen oder sinnvollen Parameter berücksichtigt werden können. Beispielsweise würde in aller Regel bei CREATE TABLE der Tabellenbereich (engl.: tablespace) angegeben, in dem die Tabelle generiert werden soll; hierauf wird aus Gründen der leichteren Verständlichkeit verzichtet. 24 auch virtuelle Tabellen oder Sichten genannt, Anm. d. Hsrg. 25 Die beiden Wortformen bilden eine semantische Einheit. 15 Der Befehl INSERT fügt einer Tabelle neue Zeilen (die den Tupeln des theoretischen Modells entsprechen) hinzu. Im Rahmen dieses Einfügevorgangs werden Konsistenzprüfungen durchgeführt, die sich beispielsweise aus dem CREATE TABLE ergeben. So wird das Kommando INSERT INTO korpus VALUES ( ’ Ein ’ ),( ’ minimales ’ ),( ’ Korpus ’ ) beim erstmaligen Aufruf ohne Fehlermeldung ausgeführt. Jeden weiteren Einfügeversuch (mit den gleichen Wortformen) wird das Datenbanksystem zurückweisen, da die entsprechenden Wortformen in der Tabelle bereits gespeichert wurden, als primäre Schlüssel jedoch nur einmal vorkommen können. Die UPDATE Anweisung dient dazu, bereits abgelegte Daten zu verändern. Das folgende Beispiel ersetzt das Wort minimales durch kleines. UPDATE korpus SET word = ’ kleines ’ WHERE word = ’ minimales ’ Der lesende Zugriff auf abgelegte Daten erfolgt durch den SELECT Befehl. So listet SELECT ∗ FROM korpus alle Zeilen der Tabelle auf. Einschränkungen des Ergebnisraumes sind durch das WHERE Konstrukt möglich. SELECT ∗ FROM korpus WHERE word = ’ minimales ’ Ergebnisse von Anfragen an das System mittels SELECT sind ebenfalls Tabellen, die Ausgangspunkt für weitere Suchanfragen sein können. Der letzte hier vorzustellende grundlegende SQL-Befehl ist DELETE. Er dient dem Entfernen von Zeilen aus einer Tabelle. Wie SELECT läßt er sich durch ein WHERE Konstrukt einschränken. DELETE FROM korpus WHERE word = ’ Ein ’ Die Sprache SQL gestattet einen umfassenden Zugriff auf relationale Daten. Gerade aufgrund ihrer Flexibilität ist allerdings eine fundierte Kenntnis ihrer Syntax nötig. 2.3 Korpusdatenbanken 2.3.1 Begriffsbestimmung Datenbanksysteme stellen Dienstprogramme zur Verfügung, um auf einer Datenbasis bestimmte Operationen wie Einfügen, Löschen oder Suchen durchführen zu können. Korpora, die in elektronischer Form vorliegen, entsprechen strukturierten Daten, auf die sich diese Funktionen ebenfalls anwenden lassen. Im folgenden soll deshalb unter dem Begriff Korpusdatenbank ein Programmsystem verstanden werden, das neben dem Import von Korpora auch die Bearbeitung der gespeicherten Informationen sowie die Recherche im Datenbestand ermöglicht. Dabei entspricht das Korpus einschließlich aller zusätzlich gespeicherten Informationen der Datenbasis, auf der bestimmte Werkzeuge operieren. Korpusdatenbanken können als klassische Datenbanksysteme angesehen werden, die für die Verarbeitung von linguistischen Daten optimiert sind. 16 2.3.2 2.3.2.1 Operationen auf Korpora Frequenzlisten Frequenzlisten geben Auskunft darüber, wie oft ein bestimmtes Token in einem Text vorkommt. Jeder Wortform wird eine Zahl zugeordnet, die der Häufigkeit ihres Auftretens entspricht. Dabei läßt sich das Datenmaterial auf unterschiedliche Weise sortieren. Ein mögliches Kriterium ist die erste Fundstelle einer Wortform. Eine so erzeugte Liste zeigt die Wortformen eines Textes in der Reihenfolge ihres ersten Vorkommens. Frequenzlisten können auch alphabetisch sortiert werden. In diesem Fall entscheidet der Anfangsbuchstabe über die Position innerhalb der Liste. 26 Eine derart aufbereitete Liste läßt sich mit dem etwa aus Fachbüchern bekannten Index vergleichen. Schließlich lassen sich Frequenzlisten nach der Häufigkeit der Fundstellen sortieren. 27 Die Generierung von Frequenzlisten mit Hilfe des Computers bietet zahlreiche Vorteile. So lassen sich leicht Mehrfachsortierungen durchführen, etwa eine Liste, die primär alphabetisch sortiert wird und auf Buchstabenebene nach der Häufigkeit, in der die einzelnen Wortformen auftreten. Ferner erfolgt eine solche Operation auch in umfangreichen Texten sehr schnell. Zudem sind dem Rechner die bei Menschen beobachteten Flüchtigkeitsfehler unbekannt. Allerdings fehlt der Maschine die Fähigkeit, kleinere Fehler im Datenbestand zu korrigieren. Wurden innerhalb eines Wortes etwa zwei Buchstaben vertauscht, kann der Rechner nur mit erheblichem Aufwand eine korrekte Zuordnung vornehmen. Frequenzlisten liefern wertvolle statistische Informationen. Von besonderer Bedeutung sind diese vor allem in Verbindung mit weiteren Suchanfragen. 2.3.2.2 Konkordanzen Nach Sinclair ist eine Konkordanz die Auflistung aller Fundstellen einer bestimmten Wortform. Im einfachsten Fall generiert ein Programm einen Index, der jede Wortform erfaßt und alle Stellen ausweist, an denen das indizierte Wort in einem Text vorkommt.28 Für die Arbeit am Text weitaus praktischer ist allerdings die Darstellung im sogenannten KWIC-Format. Das Akronym bedeutet hierbei keyword in context. Die Fundstellen werden hierzu zeilenweise ausgegeben, wobei die gesuchte Wortform in der Zeilenmitte erscheint. Links und rechts davon stehen Wortformen, die der gesuchten vorangehen, bzw. ihr folgen. Wie groß das anzuzeigende Umfeld ist, hängt von der konkreten Suchsituation ab und sollte daher vom Anwender einstellbar sein.29 2.3.2.3 Anfragen Die von Korpusdatenbanken generierten Konkordanzen sind das Ergebnis von Suchanfragen, die der Anwender an das System stellt. Im einfachsten Fall 26 Bei gleichen Anfangsbuchstaben wird der jeweils nächste Buchstabe in die Sortierung einbezogen. 27 nach [Sinclair 1991, S. 30f]. 28 nach [Sinclair 1991, S. 32] 29 nach [Sinclair 1991, S. 32f]. 17 handelt es sich hierbei um eine einzelne Wortform. Werden mehrere Wörter eingegeben, liefert das Programm nur diejenigen Textstellen, die alle eingegebenen Wörter in der gleichen Reihenfolge enthalten. Wurde ein Korpus mit zusätzlichen Informationen annotiert, sollte die Korpusdatenbank die Möglichkeit bieten, solche Daten als Kriterien in die Suchanfrage einzubeziehen. In welcher Form Anfragen an das System erfolgen, ist Korpusdatenbank-spezifisch. 2.3.3 Anforderungen an Korpusdatenbanken Heute lassen sich die technischen Voraussetzungen für die Speicherung umfangreicher Korpora mit vertretbarem Aufwand erfüllen. Allerdings muß eine Korpusdatenbank auch Anforderungen genügen, die sich aus der Struktur der gespeicherten Informationen und dem Verwendungszweck ergeben. 2.3.3.1 Technische Aspekte Eine Beschränkung der Korpusgröße aufgrund implementierungsspezifischer Einschränkungen erscheint nicht vertretbar, ebensowenig lange Bearbeitungszeiten von Suchanfragen. Instabilitäten in der Form von unerwarteten Programmabbrüchen bei der Verarbeitung von großen Datenmengen sind in jedem Fall zu vermeiden. Ferner sollte sich eine Korpusdatenbank auf möglichst vielen Hardware-Architekturen einsetzen lassen, oder eine Portierbarkeit soweit wie möglich vereinfachen. Das System muß in der Lage sein, mehrere umfangreiche Korpora zu verwalten. 30 Dabei sollte die Korpusdatenbank keine Annahmen in Bezug auf die logische Struktur eines Korpus, dessen Aufbau oder Annotationen machen. 31 Dies läßt sich erreichen, indem das System eine geeignete Schnittstelle zur Verfügung stellt, die zusätzlichen Komponenten den Zugriff auf die Datenbasis ermöglicht. Idealerweise gestattet das System den Aufbau eines Korpus im laufenden Betrieb. Dies ist von Vorteil, wenn die Zusammenstellung oder Bearbeitung von Texten nicht abgeschlossen ist, an bereits vorhandenem Material aber Untersuchungen durchgeführt werden sollen. 2.3.3.2 Anforderungen an die Anfragesprache Suchanfragen sollten auf bestimmte Teilkorpora beschränkt werden können, wobei es in diesem Zusammenhang wünschenswert ist, daß der Anwender selbständig logische Einheiten definieren kann, die sich bei Anfragen gezielt aktivieren oder ausschließen lassen. Die Auswahl der Texte sollte hierbei auch mit Hilfe bibliographischer Angaben erfolgen können, die der Anwender jederzeit einsehen kann. Ferner erscheint es geboten, die einzelnen Texte eines Korpus beliebigen Kategorien zuordnen zu können. Solche Kategorien sollten Grundlage für die Auswahl eines Textes sein können. Die bereits vorgestellte Sprache SQL verlangt das Voranstellen des Schlüsselwortes SELECT vor jede Suchanfrage. Anfragen an Korpusdatenbanken sollten 30 Eine Grenze kann sich aus der zur Verfügung stehenden Hardware ergeben. impliziert, daß die Korpusdatenbank sowohl annotierte Korpora als auch solche ohne zusätzliche Informationen verwalten kann. 31 Dies 18 weitestgehend ohne sprachspezifische Schlüsselwörter möglich sein. Desweiteren erscheint es geboten, auf komplizierte syntaktische Konstrukte zugunsten einer leichten Erlernbarkeit und effizienten Handhabbarkeit zu verzichten. Ferner sollte die Anfragesprache nicht nur Zugriff auf die Textdaten erlauben, sondern auch Analysen hinsichtlich grammatischer Phänomene oder dem sprachlichen Umfeld einer Suchanfrage zulassen. In Zusammenhang mit Suchanfragen nach Vorkommen bestimmter Wortformen ist die Verwendbarkeit von regulären Ausdrücken sinnvoll, beispielsweise um effizient nach Variationen in der Schreibung von Namen suchen zu können. 2.3.3.3 Weitere Desiderata Eine Programmierschnittstelle sollte den Zugriff auf den Datenbestand durch andere Programme ermöglichen, so daß die Textauszüge auch in anderen Anwendungen zur Verfügung stehen. Ferner sollte der Anwender die Möglichkeit haben, Frequenzlisten und Wortstatistiken zu erstellen, sowie beliebiger Analysen in einem einheitlichen Format speichern zu können. Die Darstellung von Fundstellen sollte zweckmäßigerweise im KWIC-Format erfolgen, das durch die Zentrierung der gesuchten Wortform eine gute Lesbarkeit der Ausgabe gewährleistet. Alternativ sollten sich Konkordanzen nach verschiedenen Kriterien sortieren lassen. 2.3.4 Komponenten einer Korpusdatenbank Wie bereits dargelegt wurde, sind Korpusdatenbanken den klassischen Datenbanksystemen sehr ähnlich. Neben den obligatorischen Komponenten eines DBMS sind allerdings spezifische Werkzeuge nötig. Dieser Abschnitt stellt typische Komponenten einer Korpusdatenbank vor. 2.3.4.1 Der Datenbankkern Die zentrale Komponente einer Korpusdatenbank ist für die Speicherung der Korpusdaten auf einem Rechnersystem zuständig. Der Kern stellt hierzu gängige Datenbank-Operationen wie Einfügen, Ändern, Löschen und Suchen zur Verfügung. Solche Aktionen werden in der Regel nicht durch direkte Kommunikation mit dem Anwender ausgelöst. Spezielle Werkzeuge übernehmen das Einlesen von Texten oder nehmen Suchanfragen des Benutzers entgegen und kommunizieren mit dem Datenbankkern. Dessen Konzeption und Implementierung hat entscheidenden Einfluß auf die Leistungsfähigkeit einer Korpusdatenbank. Bei seiner Implementierung ist eine möglichst effiziente Ausführung der Datenbankoperationen anzustreben. Ferner sind Beschränkungen in Bezug auf die Gesamtkapazität der Daten oder die Komplexität von Suchanfragen soweit möglich zu vermeiden. 2.3.4.2 Importfilter Importfilter fügen einer Korpusdatenbank vollständige Korpora oder einzelne Texte hinzu. Die Filter erwarten die einzufügenden Daten in einem bestimmten Format, für das sie entwickelt wurden. Ein einfach zu realisierender Filter könnte Dateien im ASCII-Format einlesen, wobei die einzelnen Tokens eines Korpus zeilenweise abgelegt werden. Spezielle Markierungen zeigen dann 19 das Ende eines Textes an. Aufwendigere Filter könnten beispielsweise das Einlesen von SGML-kodierten Texten erlauben. Das Filter-Konzept gewährleistet die einfache Erweiterbarkeit einer Korpusdatenbank. Liegt ein Korpus in einem dem System unbekannten Format vor, ist nur ein entsprechender Filter zu entwickeln oder ein bestehender anzupassen. Bislang hat das Filter-Konzept kaum Einzug in Korpusdatenbanken gefunden. 2.3.4.3 Exportfilter Die Aufgabe von Exportfiltern ist es, Korpusdaten in einem Format auf Massenspeichern abzulegen, das die Weiterverarbeitung dieser Dateien mit anderen Programmen gestattet. Für unterschiedliche Aufgaben können spezifische Filter zur Verfügung gestellt werden. In den letzten fünf Jahren hat die Auszeichnungssprache HTML weite Verbreitung gefunden. HTML-Exportfilter können Teile eines Korpus als Dateien mit HTML Tags generieren. Diese eignen sich für eine Verbreitung über das Internet. 2.3.4.4 Werkzeuge für die Textaufbereitung Gelegentlich müssen Texte vor der Bearbeitung durch einen Importfilter aufbereitet werden. Diese Aufgabe übernehmen Werkzeuge, die komzeptionell nicht zwingend der Korpusdatenbank zuzuordnen sind. Allerdings erleichert das System dem Anwender die Arbeit, wenn es entsprechende Komponenten bereitstellt. Gründe für die Notwendigkeit einer Bearbeitung sind: • die unterschiedliche Kodierung von Zeichen auf verschiedenen Computersystemen • das Fehlen eines geeigneten Importfilters Steht kein passender Importfilter zur Verfügung, kann es beispielsweise helfen, Filter-spezifische Markierungen zu entfernen und einen einfachen Filter zu verwenden. Neben Programmen, die Daten vor dem Einsatz von Filtern aufbereiten, gehören zu den Werkzeugen für die Textaufbereitung auch solche, die Texte mit zusätzlichen Informationen versehen. Als Beispiel sind Programme zu nennen, die zu den Wortformen eines Textes beispielsweise deren grammatische Kategorie oder Grundform liefern. 2.3.4.5 Benutzerschnittstelle Die Benutzerschnittstelle faßt alle Komponenten zusammen, die dem Anwender die Kommunikation mit dem System gestatten. Hierzu zählt insbesondere eine Eingabemöglichkeit für Korpusanfragen. Die derzeit verfügbaren Korpusdatenbanken stellen hierzu einen Interpreter für eine spezielle Anfragesprache bereit. Eine weitere Komponente der Benutzerschnittstelle übernimmt die Ausgabe der Ergebnisse von Suchanfragen. Verfügbare Korpusdatenbanken stellen sie im KWIC-Format dar, wobei die Ausgaben zumeist beliebig sortiert werden können. Aspekte des Themenkomplexes Benutzerführung werden in Kapitel 6 behandelt. 20 2.3.5 Vorstellung verfügbarer Systeme Im folgenden werden einige verfügbare Korpusdatenbanken vorgestellt. Neben technischen Besonderheiten ist insbesondere auf die jeweilige Anfragesprache einzugehen. Wenn auch die einzelnen Dialekte immer in Zusammenhang mit dem entsprechenden Gesamtsystem zu sehen sind, so lassen sich doch anhand der ermittelten Gemeinsamkeiten grundsätzliche Anforderungen an Korpusanfragesprachen formulieren, die in Abschnitt 6.2 thematisiert werden. 2.3.5.1 IMS Corpus Workbench Die C ORPUS W ORKBENCH wurde von Oliver Christ und Bruno M. Schulze am Institut für maschinelle Sprachverarbeitung der Universität Stuttgart entwickelt. Dieses System unterstützt beliebig viele Korpusannotationen, sowie die Einbeziehung externer Informationsquellen, die für Suchanfragen herangezogen werden können.32 Zentrales Element der Anfragesprache der C ORPUS W ORKBENCH ist der Attributausdruck. Er legt Bedingungen fest, die Korpusannotationen erfüllen müssen, um im Rahmen einer Suchanfrage als Ergebnis gemeldet zu werden. 33 Die Kombination mehrerer Attributausdrücke ist möglich. Im Zuge der Auswertung einer Anfrage liefert der Interpreter diejenigen Korpusintervalle, die den Attributausdrücken genügen.34 Die allgemeine Form eines Attributausdrucks folgt dem Schema [attribut = pattern]. D IE C ORPUS W ORKBENCH gestattet die Vereinfachung zu der Form pattern, wenn nach einer Wortform gesucht werden soll; diese werden dem Attribut word, das für jedes Korpus vorhanden sein muß, zugeordnet. Möglich ist auch der Zugriff auf sogenannte dynamische Attribute. Sie binden „externe Wissensquellen an das Corpus, ohne daß die durch diese Wissensquellen repräsentierten Informationen direkt annotiert wären“35 . Der Zugriff auf dynamische Attribute durch die Anfragesprache ist möglich. Er erfolgt analog zu Funktionsaufrufen in gängigen Programmiersprachen, indem dem Attribut eine Argumentliste übergeben wird. Strukturelle Attribute enthalten Informationen bezüglich Satz- und Abstandsgrenzen 36 . Ein Zugriff auf diese ist durch die Anfragesprache möglich. Hierzu wurde das Schlüsselwort within eingeführt, das eine Begrenzung auf eine Maximalzahl von Korpuspositionen oder eine deklarierte Strukturannotation ermöglicht 37 . 2.3.5.2 Corsica C ORSICA (CORpus Storage and InteraCtive retrievAl) wurde von Marco Zierl an der Abteilung Computerlinguistik der Universität Erlangen-Nürnberg entwickelt. Ziel der Implementierung war neben einer einheitlichen Speicherung von beliebigen Analysen der Korpusdaten ein Zugriff durch andere Programme 32 [Christ 33 [Christ 1994] 1994, S. 6] 34 ebenda 35 [Christ 1994, S. 4] 1994, S. 3] 37 [Christ 1994, S. 8] 36 [Christ 21 sowie die Möglichkeit, Korpusannotationen beliebig hinzufügen und entfernen zu können38 . Die Anfragesprache von C ORSICA ist an die der C ORPUS W ORKBENCH angelehnt 39 . An logischen Operationen auf Korpuspositionen bietet C ORSICA sowohl Konjunktion als auch Disjunktion, wobei letztere eine höhere Priorität besitzt. Der Distanzoperator $any(x) bietet die Möglichkeit, nach nicht unmittelbar aufeinander folgenden Attributausdrücken zu suchen. C ORSICA wurde als Client-Server-System implementiert, wobei der Client als Java-Applet realisiert wurde, das in einem Webbrowser ablaufen kann. Dies trägt dem Desiderat der Verfügbarkeit auf möglichst vielen Plattformen zumindest auf Client-Seite Rechnung. 2.3.5.3 SARA S ARA ist die Korpusdatenbank zur Arbeit mit dem BNC. Das Akronym SARA bedeutet SGML-Aware Retrieval Application. Obwohl der Name des Programmsystems die Verwenbarkeit für beliebige SGML-Dokumente nahelegt, ist SARA ausschließlich für eine Benutzung mit dem British National Corpus konzipiert. SARA besteht aus vier Hauptkomponenten: • Ein Indizierer wandelt SGML-annotierte Texte in ein proprietäres Format. Dieser Index enthält Verweise auf alle Wortformen sowie auf die SGML- und POS-Tags des Korpus. • Der SARA-Server nutzt den Index für die Bearbeitung von Suchanfragen • Client-Programmen nehmen Benutzeranfragen entgegen und kommunizieren mit dem Server auf der Basis von TCP/IP • Anfragen an den Server werden in einer CQL (corpus query language) genannten Anfragesprache formuliert. Diese orientiert sich wie die Corsicas und der Corpus Workbench an Attributausdrücken. Zusätzlich ist der Zugriff auf SGML-Tags möglich. Die Kommunikation mit dem Anwender übernehmen Client-Programme. Für Rechner unter dem Betriebssystem UNIX steht nur ein rudimentäres Programm zur Verfügung, das Anfragen in CQL erwartet. Ein sehr umfangreicher Client, der Microsoft Windows voraussetzt, erlaubt hingegen eine sehr flexible und komfortable Arbeit mit dem Korpus. 40 38 [Zierl 1997, S. 2] 1997, S. 57] 40 Allgemeine Informationen zu SARA finden sich bei [Burnard 1996] 39 [Zierl 22 3 Die Korpusdatenbank SanRemo Dieses Kapitel beschreibt Problemfelder, die sich aus der Verwendung eigens entwickelter Datenbankkerne für die Speicherung von Korpora ergeben können, und stellt relationale Datenbanksysteme als Basis für Korpusdatenbanken als mögliche Alternative vor. Ferner werden die Korpusdatenbank S AN R EMO und ihre Komponenten vorgestellt. 3.1 Konzepte zur Speicherung von Korpora 3.1.1 Eigenentwicklungen Für eine effiziente Arbeit mit umfangreichen annotierten Korpora sind spezialisierte Werkzeuge nötig, die auch komplexe Suchanfragen schnell und zuverlässig verarbeiten können. Um dies zu erreichen, enthalten die dem Verfasser bekannten verfügbaren Systeme eigens entwickelte Datenbankkerne, auf die alle weiteren Komponenten über eine geeignete Schnittstelle zugreifen. Solche Korpusdatenbanken lassen sich nur um zusätzliche Funktionen erweitern, wenn die Funktionalität der Schnittstelle offengelegt wird und auf dem Rechnersystem eine geeignete Programmiersprache zur Verfügung steht. Proprietäre Datenbankkerne können auf spezifische Eigenschaften des verfügbaren Korpusmaterials Rücksicht nehmen, was zu einem sehr effizienten Zugriff auf den Datenbestand führt. Allerdings lassen sich solche Systeme nicht oder nur mit erheblichen Aufwand um Korpora erweitern, deren Struktur ganz oder teilweise von der beim Entwurf des Kerns zugrundegelegten abweicht. Um mehreren Anwendern den gleichzeitigen Zugriff auf Korpora zu ermöglichen, müssen Korpusdatenbanken als Client-Server-Systeme implementiert werden. Damit Client-Programme Anfragen an den die Datenbank verwaltenden Server stellen können, muß ein geeignetes Kommunikationsprotokoll zur Verfügung stehen. Mechanismen, die Zugriffskontrollen – etwa im Rahmen einer Benutzerverwaltung – ermöglichen, sind in diesem Fall durch die Kor23 pusdatenbank zu realisieren, wobei soweit möglich ein Zugriff auf durch das Rechnersystem bereitgestellte Betriebsmittel erfolgen wird. Von besonderer Bedeutung ist eine möglichst effiziente Speicherung der Korpusdaten auf dem Massenspeicher. Bei Suchanfragen muß der Kern in der Lage sein, schnell auf den Datenbestand zuzugreifen. Allerdings läßt die bei einem aus 100 Millionen Wortformen bestehenden Korpus anfallende Menge an Informationen die Verwendung von Komprimierungsverfahren sinnvoll erscheinen. Dies erfordert wiederum den Zugriff auf systemspezifische Mechanismen, deren Übertragung auf andere Plattformen problematisch sein kann. Wie die aufgeführten Beispiele zeigen, ist die Konzeption und Implementierung einer Korpusdatenbank auf Basis eines proprietären Datenbankkerns aufwendig. Neben Problemen, die die Arbeit mit Korpora betreffen (etwa die Bereitstellung einer geeigneten Anfragesprache) sind zahlreiche programmiertechnischen Aspekte (beispielsweise die Definition und Realisierung eines geeigneten Netzwerkprotokolls) zu berücksichtigen. Für die Programmierung eines möglichst effizienten Systems ist zudem der Zugriff auf systemnahe Funktionen unerläßlich, was zu einer bereits angesprochenen erschwerten Portierbarkeit auf andere Rechnerplattformen führen, wenn diese ein entsprechendes Betriebsmittel nicht oder in nicht kompatibler Weise zur Verfügung stellen. 3.1.2 Relationale Datenbanksysteme Relationale Datenbanksysteme finden in den unterschiedlichsten Bereichen der elektronischen Datenverarbeitung Anwendung. Die Häufigkeit ihres Einsatzes führte zur Entwicklung von zahlreichen Produkten, die ein breites Leistungspektrum abdecken. Neben Einzelplatzversionen, die sich zur Speicherung kleiner bis mittlerer Datenmengen eignen, existieren Client-Server-Produkte, die einen schnellen und zuverlässigen Zugriff auch auf sehr umfangreiche Datenbestände gewährleisten. Gerade solche Systeme scheinen für einen Einsatz in der Korpuslinguistik sehr geeignet zu sein. Sowohl Tabellendefinitionen als auch Suchanfragen und Manipulationen am Datenbestand können durch Elemente der Sprache SQL erfolgen. Da relationale Datenbanksysteme für zahlreiche Betriebssysteme existieren, stehen Korpusdatenbanken auf Basis von SQL auf entsprechend vielen Rechnern zur Verfügung. Da Syntax und Semantik der Sprache durch die Gremien American National Standards institute (ANSI) und International Organisation for Standardization (ISO) standardisiert wurden, 1 sind bei der Implementierung der Datenbank keine Komplikationen zu erwarten. Eine aufwendige Portierung, die bei in herkömmlichen Programmiersprachen entwickelten Korpusdatenbanken zu erwarten ist, entfällt. Aufgrund ihrer komplexen Syntax erscheint SQL als Korpusanfragesprache für Benutzer allerdings wenig geeignet. Kapitel 7.1 zeigt dies anhand ausgewählter Anfragen. Da SELECT-Anweisungen Namen von Tabellen und Attributen beinhalten, erfordern sie die Kenntnis der Tabellenstruktur, die nicht der im Rahmen der formalen Definition vorgestellten Sichtweise auf ein Korpus entsprechen wird. Eine Abbildung von Korpusdaten auf SQL-Tabellen hat vor dem Hintergrund eines möglichst effizienten Zugriffs zu erfolgen. Eine Tabelle, deren Attribute 1 24 [Date 1997, S. 6] den positionalen Attributen eines Korpus entsprechen, wäre nicht nur im Hinblick auf den zu erwartenden Speicherverbrauch in hohem Maße ineffektiv. Auf diesen Sachverhalt ist im folgenden Kapitel ausführlich einzugehen. Zudem erfordert die Formulierung einer Suchanfrage in SQL die Eingabe zahlreicher Füllwörter (etwa FROM, WHERE), was für den ungeübten Anwender zusätzlichen Lernaufwand bedeutet. Aus disem Grund erscheint es sinnvoll, dem Benutzer einer Korpusdatenbank anstelle von SQL eine Anfragesprache zur Verügung zustellen, die • die gewohnte Sichtweise auf ein Korpus in der Form von Korpuspositionen und positionalen Attributen ermöglicht • eine geringe Einarbeitungszeit erfordert • effizienten Zugriff auf Korpusdaten gewährleistet 3.1.3 Notwendige Ergänzungen Die leichte Verfügbarkeit von relationalen Datenbanksystemen und ihre im praktischen Einsatz nachgewiesene Stabilität machen sie zu einer sehr geeigneten Basis für Korpusdatenbanken. Da SQL als Korpusanfragesprache aus den dargelegten Gründen wenig benutzerfreundlich ist, muß eine Korpusdatenbank eine geeignetere Anfragesprache zur Verfügung stellen und in SQL-Konstrukte umsetzen, sowie die vom RDBMS gelieferten Ergebnistabellen für den Anwender aufbereiten, etwa in der Form einer KWIC-Liste. Eine solche Verteilung von Aufgaben führt zu dem in Abbildung 3.1 dargestellten Dreischichtenmodell. Abbildung 3.1: Schema einer RDBMS-basierten Korpusdatenbank Programmiersprachen (Perl, Java) Anfragesprache Import Filter KWIC Export Filter SQL Suchanfragen an die Datenbank Einfügen neuer Texte und Korpora Ausgabe von Suchergebnissen Export von Korpora Datenbank−System Das RDBMS ist als zentrale Komponente für die Speicherung der Korpusdaten sowie für deren Manipulation verantwortlich. Die Korpora werden in verschiedenen Tabellen abgelegt, deren Struktur und Bedeutung in Kapitel 4 ausführlich dargestellt wird. Alle weiteren Komponenten des Systems kommunizieren mit dem RDBMS in der Sprache SQL auf Basis dieser Tabellenstruktur. SQL bildet das Transportmedium für Anfragen an die Datenbank sowie für das Hinzufügen von Texten zu einem Korpus oder das Einbringen vollständiger Korpora. Hierbei werden Daten in Richtung des RDBMS übertragen. Dieses liefert Ergebnisse von Suchanfragen in Form von Tabellen, die von geeigneten Komponenten ausgewertet und aufbereitet werden. 25 Hierzu zählen Programme, die Suchanfragen in Form einer KWIC-Liste darstellen oder Teile eines Korpus als SGML-Datei speichern können. An solche Komponenten sind ähnliche Anforderungen zu stellen wie an den Datenbankkern selbst. Da sie Anfragen an den Kern weiterleiten sowie Ergebnistabellen von ihm erhalten, müssen sie auch umfangreiche Datenmengen schnell und zuverlässig verarbeiten können. Bei der Wahl einer geeigneten Programmiersprache für Komponenten ist auch deren Verfügbarkeit auf unterschiedlichen Rechnersystemen zu berücksichtigen. Hierbei muß die Sprache hardwarespezifische Merkmale weitgehend ausschließen. Eine Abhängigkeit zwischen der Länge eines Maschinenregisters und dem Wertebreich eines elementaren Datentyps, wie sie etwa die Programmiersprache C kennt, führt bei der Übertragung eines Programms auf ein anderes Computersystem sehr leicht zu Fehlern. Ferner sind bei der Implementierung der Werkzeuge systemspezifische Funktionen bzw. unmittelbare Zugriffe auf das Betriebssystem möglichst zu vermeiden. Stattdessen sind Elemente der Programmiersprache oder genormte, der Sprache zugeordnete Funktionsbibliotheken zu verwenden. Da die Programme mit dem RDBMS kommunizieren, ist bei der Wahl der Programmiersprache schließlich zu prüfen, inwieweit sie Zugriff auf SQL-Datenbanken gestattet. 3.2 SanRemo im Überblick 3.2.1 Vorstellung des Systems S AN R EMO ist die experimentelle Implementierung einer Korpusdatenbank auf der Basis eines relationalen Datenbanksystems. Hierbei steht der Name für corpus analysis based on the relational model. Neben Werkzeugen zum Einfügen von Texten in die Datenbank stellt S AN R EMO Funktionen zum Stellen von Anfragen und der Ausgabe von Suchergebnissen zur Verfügung. Das Ziel der experimentellen Implementierung bestand nicht primär in der Entwicklung eines allgemein verfügbaren Systems, sondern dient zunächst der Untersuchung einer grundsätzlichen Eignung von relationalen Datenbanksystemen zur Speicherung umfangreicher, annotierter Korpora. Dies erfordert die Erfüllung folgender Kriterien: • hinreichend schnelle Antwortzeiten des Systems bei Einfügeoperationen, vor allem aber bei Suchanfragen • ausreichende Flexibilität des relationalen Modells für die Speicherung von Korpusdaten • Eignung von SQL als Basis für Korpusanfragen Zentraler Bedeutung kommt hierbei der Tabellenstruktur zu, die alle in einem Korpus abgelegten Informationen erfassen und einen möglichst effizienten Zugriff gewährleisten muß. Die im Rahmen dieser Arbeit vorgelegten Werkzeuge zur Arbeit mit Korpora spiegeln den experimentellen Charakter des Systems wider. Der modulare Aufbau von S AN R EMO und die Nutzung von SQL als Kommunikationsmittel gestatten allerdings die nachträgliche Erweiterung durch den gezielten Austausch bestimmter Komponenten. 26 3.2.2 Die Komponenten im Überblick S AN R EMO implementiert das in Abbildung 3.1 dargestellte Drei-SchichtenModell. 3.2.2.1 Das RDBMS Die Basis bildet ein relationales Datenbanksystem, das die vollständige Speicherung der Korpora übernimmt. Im Rahmen einer Referenzimplementierung wurde IBM DB/2 gewählt. Da die einzelnen Komponenten ausschließlich über Elemente der Datenbanksprache SQL miteinander kommunizieren, sollte stattdessen ein beliebiges RDBMS eingesetzt werden können, das SQL in einer zum ANSI- bzw. ISO-Standard kompatiblen Fassung bereitstellt. 3.2.2.2 Die Transportschicht Die formale Grundlage für die Speicherung der Korpusdaten ergibt sich aus einem geeigneten, in Kapitel 4 ausführlich vorzustellenden, Tabellenmodell. Kernpunkt dessen Struktur ist die Speicherung beliebiger Online-Texte. Ziel bei der Entwicklung war es, etwaige Korpusannotationen sowie zusätzliche textuelle Informationen vollständig in die Datenbank zu integrieren. Die einzigen zwingend notwendigen Informationen sind die Wortformen der OnlineTexte, so daß sich Korpora auch aus reinen ASCII-Texten ohne weitere Informationen aufbauen und bearbeiten lassen. Die Tabellenstruktur stellt nur die für eine flexible Speicherung nötigen Attribute zur Verfügung. Diese werden durch geeignete Importfilter, deren Funktionsweise in Kapitel 5 dargestellt wird, mit Daten gefüllt. Importfilter sowie alle weiteren Komponenten der Anwenderschicht kommunizieren mit dem Datenbanksystem durch SQL-Anweisungen auf der Basis der Tabellenstruktur. Da sich auch die Tabellendefinitionen in CREATE TABLEKonstrukten manifestieren, kommt der Datenbanksprache die Rolle eines zentralen Transportmediums zu. 3.2.2.3 Kommunikation mit dem Anwender Die Anwenderschicht faßt alle Komponenten zusammen, die mit dem Benutzer der Korpusdatenbank interagieren. Hierzu zählen die bereits vorgestellten Importfilter sowie Interpreter von Suchanfragen oder administrative Werkzeuge. Im einzelnen wurde implementiert: • SanRemo.pl: generiert die SanRemo.toc Tabelle • newcorpus.pl: richtet ein neues Korpus ein und generiert die Tabellen info, textinfo und types • delcorpus.pl: löscht ein Korpus vollständig aus der Datenbank • fill.pl und turbo.pl: rudimentäre Importfilter zum Einlesen des BNC • text.pl: zeigt einzelne Texte eines Korpus auf dem Bildschirm an • textinfo.pl: ermittelt statistische textbezogene Informationen • kwic.pl: gestattet die Suche nach Wortformen und zeigt Fundstellen im KWIC-Format 27 Die Programme basieren auf dem im Rahmen dieser Arbeit entwickelten PerlModul dbhelper.pm, das die Kommunikation mit dem RDBMS übernimmt. Durch die Bereitstellung von Funktionen anstelle der direkten Kommunikation mit dem Datenbanksystem bleiben die Komponenten auch nach Änderungen an der Tabellenstruktur funktionsfähig. 3.2.3 Zur Wahl einer geeigneten Programmiersprache Die im Rahmen dieser Arbeit entstandenen Komponenten wurden in der Programmiersprache Perl geschrieben. Perl ist aus mehreren Gründen sehr gut für solche Werkzeuge geeignet. Das Modul DBI 2 gestattet auf sehr elegante Weise den Zugriff auf SQL-Datenbanken. Zudem ist Perl für verschiedene Rechner verfügbar, was eine Portierung von S AN R EMO auf andere Systeme sehr vereinfacht. Ferner bietet diese Programmiersprache komfortable Mechanismen zur Zeichenkettenbearbeitung sowie reguläre Ausdrücke, was die Bereitstellung äußerst leistungsfähiger Anfragesprachen ermöglicht. Schließlich erlaubt Perl die Zusammenfassung von funktional zusammengehörenden Elementen zu sogenannten Modulen. Diese stellen Funktionen bereit, auf die andere Komponenten ohne Kenntnis der konkreten Implementierung zugreifen können. Diese Form der Abstraktion gestattet beispielsweise Änderungen an der Tabellenstruktur, ohne Anpassungen an bestehenden Komponenten vornehmen zu müssen. 3.2.4 Hardware-Basis und Voraussetzungen für den Betrieb Kleinere Korpora, beispielsweise das Brown Corpus, lassen sich problemlos mit Hilfe von Einzelplatzversionen relationaler Datenbanksysteme speichern. Die zu erwartenden Antwortzeiten des Systems sind bei solchen Datenmengen auch bei durchschnittlich ausgestatten Maschinen zu vernachlässigen. Umfangreiche annotierte Korpora, wie etwa das British National Corpus, erfordern hingegen Massenspeicher mit Kapazitäten im Gigabyte-Bereich. Auch ist eine möglichst hohe Rechengeschwindigkeit wünschenswert. Aus diesen Gründen ist S AN R EMO idealerweise in Verbindung mit einem Client-Server basiertem RDBMS einzusetzen. Die Verwendung standardisierter Komponenten hat eine unkomplizierte Installation von S AN R EMO zur Folge, setzt allerdings ein richtig konfiguriertes Netzwerk voraus, falls das System nicht auf einem Einzelplatzrechner betrieben wird. Ferner muß das RDBMS und ein geeigneter Perl-Interpreter installiert und ggf. an die Hardwareumgebung angepaßt werden. Wie aufwendig solche vorbereitenden Maßnahmen sind, ist von den zur Verfügung stehenden Geräten abhängig. Die Generierung einer Datenbasis ist ebenfalls vor einem Einsatz von S AN R E MO durchzuführen. Der hierfür zuständige Nutzer muß auf dem System entsprechende Datenbank-Administrator-Rechte besitzen. Solche Maßnahmen erfolgen auf verschiedenen Rechner-Systemen in unterschiedlicher Weise. Zumindest in einer experimentellen Implementierung sind solche Aufgaben nicht durch die Korpusdatenbank zu bearbeiten. Eine allgemein verfügbare Version 2 28 ⟨http://dbi.symbolstone.org/ ⟩ von S AN R EMO hingegen könnte eine entsprechende Funktionalität bereitstellen. 29 30 4 Das Tabellenmodell von SanRemo In diesem Kapitel wird die in S AN R EMO für die Speicherung der Korpusdaten verwendete SQL-Tabellenstruktur vorgestellt. Hierbei werden mehrere Lösungsansätze gezeigt, die den Verlauf dieser Arbeit dokumentieren. 4.1 Allgemeine Überlegungen zur Tabellenstruktur Das S AN R EMO zugrunde liegende Tabellenmodell hat zentrale Bedeutung für dessen Flexibilität, Geschwindigkeit und Benutzerfreundlichkeit. Struktur und Verknüpfung der beteiligten Tabellen entscheiden über die Bearbeitungsdauer von Anfragen an das System sowie bei Wartungsarbeiten, zu denen das Anfügen neuer oder Entfernen bestehender Texte oder das Bearbeiten textbezogener Informationen gehören. Ferner ist vom Aufbau der einzelnen Tabellen abhängig, welche zusätzlichen Informationen über ein Korpus gespeichert werden können und inwieweit diese als Grundlage für Suchanfragen verwendet werden können. Ziel bei der Entwicklung einer geeigneten Struktur war die Möglichkeit einer flexiblen Speicherung von Korpusdaten unter Entstehung minimaler Redundanz. Die Tabellenstruktur gibt wenige Attribute vor. Stattdessen können Importfilter die geeigneten Informationen aus den Online-Texten in ihnen geeignet erscheinenden Tabellen eintragen. 4.2 Abbildung von Korpuspositionen auf Attribute Wie in Abschnitt 2.1.4 dargelegt wurde, läßt sich ein Korpus formal als eine Abfolge von n Korpuspositionen beschreiben, wobei jeder Position eine beliebige Anzahl positionaler Attribute zugeordnet wird. In einem ersten Versuch kann ein auf diese Weise beschriebenes Korpus unmittelbar auf eine Tabelle abgebildet werden: 31 CREATE TABLE korpus ( counter INTEGER NOT NULL , word VARCHAR (44) NOT NULL , pos VARCHAR (8), PRIMARY KEY( counter ) ) Die generierte Tabelle wird über den Namen korpus angesprochen. Ihre Attribute entsprechen den positionalen Attributen word und pos. Da counter die Korpusposition der zu speichernden Wortform angibt, findet sich keine Entsprechung bei den positionalen Attributen. Ein Zugriff auf Korpusdaten an einer bestimmten Korpusposition ist nach einem Einfügevorgang mit Hilfe einer entsprechenden SELECT Anweisung möglich: INSERT INTO korpus ( counter , word ) VALUES (1, ’ Ein ’ ),(2, ’ minimales ’ ),(3, ’ Korpus ’ ) INSERT INTO korpus ( counter , word ) VALUES (4, ’ Ein ’ ),(5, ’ weiterer ’ ),(6, ’ Text ’ ) SELECT ∗ FROM korpus WHERE word=’ minimales ’ oder SELECT ∗ FROM korpus WHERE counter < 3 Ergebnis: COUNTER ----------1 2 WORD ---------------------Ein minimales POS -------- 2 record(s) selected. Die vorgestellte Tabelle ist für die Speicherung großer Korpora aus mehreren Gründen ungeeignet: • Alle Wortformen werden mit eindeutigen Nummern versehen, allerdings ist keine Zuordnung zu einzelnen Texten möglich, da die Position der Textgrenzen nicht gespeichert wird. Obwohl sich Suchanfragen sehr oft auf das gesamte Korpus beziehen, sollte eine Korpusdatenbank die Einschränkung des Suchraumes auf bestimmte Texte unterstützen. • Attribute, die positionale Attribute abbilden, lassen sich zwar mit der Anweisung ALTER TABLE ADD COLUMN beliebig hinzufügen, allerdings nicht wieder entfernen. Werden Texte aus dem Korpus entfernt, enthält die Tabelle korpus weiterhin die möglicherweise nicht mehr benötigten Attribute, was eine unnötige Verwendung von Speicherplatz zur Folge hat. • Durch die mehrfache Speicherung gleicher Wortformen als Zeichenketten entsteht gerade bei sehr großen Korpora eine erhebliche Menge an redundanter Information. Das BNC enthält beispielsweise die Wortform 32 linguistics an 537 Korpuspositionen. Die entsprechende Zeichenkette würde demnach 537 mal gespeichert. Zwar hat sich die Kapazität verfügbarer Massenspeicher in den letzten Jahren vervielfacht, allerdings müssen bei Suchanfragen alle Zeichenketten verglichen werden. Da mit der ersten Speicherung die Oberfläche der Wortform bekannt ist, erscheint es sinnvoll, nach einer weniger speicherintensiven Ablageform bereits bekannter Wortformen zu suchen. Eine mögliche Vorgehensweise wird im folgenden Abschnitt dargestellt. 4.3 Der 2-Tabellen-Ansatz Der 2-Tabellen-Ansatz erreicht eine Reduzierung des für das Ablegen der Korpusdaten nötigen Speicherplatzes durch Aufteilen der Informationen auf zwei Tabellen. Möglich wird dies durch die Anwendung des in Abschnitt 2.1.3 vorgestellten Type-Token-Konzepts. 4.3.1 Die Normalisierung von Tabellen Der Prozeß der Vereinfachung von Tabellen, und damit der Auflösung von Redundanzen, wird als Normalisierung bezeichnet. Date bemerkt zu der auf das relationale Modell bezogenen Normalisierungstheorie: „Normalization theory is built around the concept of normal forms. A relation is said to be in a particular normal form if it satisfies a certain set of constraints. For example, a relation is said to be in first normal form (abbreviated 1NF) if and only if it satisfies the constraint that its underlying simple domains contain atomic values only“1 . Eine Datenbank auf der Basis des Type-Token-Konzepts speichert demnach nicht die Tokens der Texte eines Korpus selbst, sondern Verweise auf eine Tabelle, die jede im Korpus vorkommende Wortform als Type genau einmal enthält. Diese Überlegungen führen unmittelbar zu der Definition von zwei SQL-Tabellen, die das Type-Token-Konzept implementieren: CREATE TABLE types ( running_type INTEGER NOT NULL, surface VARCHAR (64), PRIMARY KEY ( running_type ) ) CREATE TABLE tokens ( running_token INTEGER NOT NULL , token INTEGER NOT NULL , PRIMARY KEY ( running_token ) ) Abbildung 4.1 dokumentiert die Beziehung zwischen den Tabellen types und tokens. Die Darstellung zeigt den Inhalt der Tabellen nach folgenden SQLKommandos: 1 [Date 1990, S. 526f] 33 INSERT INTO types ( running_type , surface ) VALUES (1, ’ Ein ’ ), (2, ’ kleiner ’ ), (3, ’ Text ’ ), (4, INSERT INTO tokens VALUES (1,1), (2,2), (3,3), (4,4), (5,1), (6,3) ’ Noch ’ ) Diese Anweisungen speichern die Texte Ein kleiner Text und Noch Ein Text in der Datenbank ab. Abbildung 4.1: Beziehung zwischen den Tabellen types und tokens tokens types running_type surface running_token token 1 1 kleiner 2 2 Text 3 3 Noch 4 4 5 1 6 3 1 Ein 2 3 4 Die Tabelle tokens ist für die Speicherung der Wortformen (Tokens) in der Reihenfolge ihres Auftretens in den Texten eines Korpus verantwortlich. Der Bezug zur Tabelle types wird durch das Attribut running_type hergestellt, das jedem Type eine innerhalb eines Korpus eindeutige Nummer zuordnet. Diese wird in der tokens Tabelle im Attribut token anstelle der Zeichenkette selbst abgelegt. 4.3.2 Bewertung der 2-Tabellen-Struktur Die Wortformen eines Korpus werden nicht bei jedem Erscheinen als Folgen von Zeichen gespeichert, sondern als Indizes in eine types Tabelle. Um nach Wortformen an einer Korpusposition zu suchen, sind demzufolge zwei SELECT Anweisungen oder vergleichbare verschachtelte Konstrukte nötig. Zuerst ist anhand der Oberfläche der Wortform ( surface) nach der Nummer des entsprechenden Types zu suchen. Der auf diese Weise ermittelte Index ( running_type) kann anschließend als Suchkriterium in der tokens Tabelle verwendet werden. Die folgende SQL-Anweisung zeigt alle Korpuspositionen, die das Token Ein enthalten. SELECT ∗ FROM tokens , ( SELECT ∗ FROM types WHERE surface = ’ Ein ’ ) AS temp WHERE tokens . token = temp . running_type Ergebnis: RUNNING_TOKEN TOKEN RUNNING_TYPE SURFACE ------------- --------- ------------ -------1 1 1 Ein 5 1 1 Ein 2 record(s) selected. 34 Die Komplexität der Anfrage dokumentiert die in Abschnitt 3.1.3 angesprochene Notwendigkeit einer leicht zu erlernenden Korpusanfragesprache. Eine mit dem Anwender kommunizierende Komponente kann problemlos in dieser Sprache formulierte Anfragen in dem Beispiel ähnliche SQL-Konstrukte umformen. Als Vorteile der 2-Tabellen-Struktur sind zu nennen: • Verminderung von Redundanz bei der Speicherung der Korpusdaten: Für die Speicherung von Zeichenketten benötigen Datenbanksysteme mehr Kapazität auf dem Massenspeicher als für Zahlen. • Steigerung der Suchgeschwindigkeit: Der Vergleich von Zahlen im Rahmen einer Suchoperation ist weniger aufwendig als die Suche nach Übereinstimmung in Zeichenketten. Nachteile der 2-Tabellen-Struktur sind: • Textgrenzen werden nicht gespeichert: Die Einschränkung von Suchanfragen auf Teilkorpora ist ohne eine Markierung von Textgrenzen nicht realisierbar. • Die Speicherung textbezogener Informationen wie Urheber oder Copyrightvermerke ist nicht möglich. • Bei umfangreichen Korpora entstehen lange Wartezeiten. Es hat sich gezeigt, daß die Verwendung einer globalen tokens Tabelle zu nicht hinnehmbaren Wartezeiten bei Suchanfragen führen kann. Abschnitt 7.1 stellt im Verlauf der praktischen Arbeit mit S AN R EMO gewonnene Erkenntnisse vor. Die für Suchanfragen benötigte Zeit ist in starkem Maße von der Leistungsfähigkeit des Rechnersystems, auf dem das Datenbanksystem installiert ist, abhängig. In Client-Server-Umgebungen spielt ferner die Auslastung des Netzwerks eine signifikante Rolle. Korpusdatenbanken mit proprietärem Datenbankkern werden ebenfalls durch diese Faktoren beeinflußt. Aus diesem Grund sind implementierungsspezifische Wartezeiten so gering wie möglich zu halten. Dies läßt sich durch eine weitere Normalisierung der Tabellenstruktur erreichen. Hierzu wird die tokens Tabelle in Teileinheiten zerlegt. 4.4 n-Tabellen-Struktur Die Aufteilung der tokens Tabelle in kleinere Einheiten erfolgt zweckmäßigerweise an Textgrenzen. Zwar ist eine Unterteilung prinzipiell an jeder Korpusposition möglich, allerdings bilden die einzelnen Texte eines Korpus logische Einheiten, deren Grenzen sich für eine Aufteilung gut eignen. Ferner reflektieren auf diese Weise die Tabellen die logische Struktur des Korpus. Die 2-Tabellen-Struktur speichert m Wortformen eines aus n Texten bestehenden Korpus in einer tokens Tabelle. Eine Aufteilung an Textgrenzen führt zur Bildung von n tokens Tabellen. Eine solche Unterteilung soll daher nTabellen-Struktur genannt werden. Die Teiltabellen dieser Struktur werden mit t1 bis tn bezeichnet. 35 CREATE TABLE types ( running_type INTEGER NOT NULL , surface VARCHAR (64), type_count INTEGER , map CLOB (128), PRIMARY KEY ( running_type ) ) CREATE TABLE tn ( running_token INTEGER NOT NULL , token INTEGER NOT NULL, PRIMARY KEY ( running_token ) ) Der Aufbau der an der n-Tabellen-Struktur beteiligten Tabellen entspricht im Wesentlichen den in Abschnitt 4.3 vorgestellten Form. Um zwischen Korpusglobalen und Text-bezogenen Tabellen unterscheiden zu können, werden letztere im Folgenden als tn Tabellen bezeichnet. Die Erweiterungen der types Tabelle durch die Attribute type_count und map werden im Abschnitt 4.7 ausführlich diskutiert. An der Funktionsweise der n-Tabellen-Struktur ändern sie nichts. Jede Korpusposition läßt sich auf diese Weise durch Nennung einer tn Tabelle und dem Attribut running_token eindeutig bestimmen. Um die in Abschnitt 4.3 verwendeten Beispieltexte in einer n-Tabellen-Struktur speichern zu können, sind neben einer types Tabelle zwei tn Tabellen anzulegen (t1 und t2). Die Verteilung der Tokens auf die tn Tabellen geschieht durch folgende SQL-Anweisungen: INSERT INTO t1 VALUES INSERT INTO t2 VALUES (1,1),(2,2),(3,3) (1,4),(2,1),(3,3) Abbildung 4.2: Beispiel einer n-Tabellen-Struktur t2 running_token types token running_type t1 surface running_token token 1 4 1 Ein 1 1 2 1 2 kleiner 2 2 3 3 3 Text 3 3 4 Noch Abbildung 4.2 verdeutlicht die Abhängigkeiten zwischen types, t1 und t2 Tabellen nach Ausführung der vorgestellten INSERT Anweisungen. 4.5 Speicherung textbezogener Informationen Die n-Tabellen-Struktur beinhaltet die Vorteile der 2-Tabellen-Struktur und ermöglicht einen effizienteren Zugriff auf die Teiltexte eines Korpus. Durch die Kennzeichnung von Textgrenzen ist ferner die Speicherung von zusätzlichen textbezogenen Informationen möglich. Hierfür werden, dem Konzept der Normalisierung folgend, weitere Tabellen eingeführt. 36 4.5.1 Zugehörigkeit eines Textes zu einem Korpus Um tn Tabellen eindeutig einem Korpus zuordnen zu können, werden Informationen über die einzelnen Texte in einer Tabelle textinfo zusammengefaßt. Diese Tabelle wird durch Importfilter, die für das Einfügen eines bestimmten Textes verantwortlich sind, bearbeitet. CREATE TABLE textinfo ( textno INTEGER NOT NULL , tablenam VARCHAR (10), filename VARCHAR (64), PRIMARY KEY ( textno ) ) Die Attribute textno und tablenam ordnen jedem Text eine korpusweit eindeutige Nummer zu und beinhalten den Namen der entsprechenden tn Tabelle. Die Speicherung beider Informationen ist nötig, da auf die Textnummer in der im Abschnitt 4.5.2 vorzustellenden Tabelle info Bezug genommen wird. Ferner sind für das Anlegen einer tn Tabelle Importfilter zuständig. Da SQL ausschließlich aus Ziffern bestehende Tabellennamen nicht gestattet, müssen die Filter der Textnummer ein Präfix (beispielsweise t) hinzufügen. Um Inkompatibilitäten durch abweichende Präfixe zu vermeiden, wird der vollständige Name der generierten tn Tabelle im Attribut tablenam abgelegt. Die Tabelle textinfo ist beliebig erweiterbar, beispielsweise könnten Importfilter in einem Attribut filename den Dateinamen des Online-Textes vermerken, den sie in die Datenbank eingefügt haben. Die Tabelle eignet sich für die Speicherung textbezogener Informationen, die sich eindeutig einem Attribut zuordnen lassen. Beispiele hierfür sind etwa der Titel des Textes, der Name des Verfassers oder das Jahr der Veröffentlichung. Importfilter könnten diese Informationen in den Attributen (die bei Bedarf angelegt werden können) title, author und publication_date ablegen. Allerdings stehen solche Attribute für jeden in textinfo abgelegten Text zur Verfügung. Aus diesem Grund ist es ratsam, nur solche Informationen zu speichern, die in möglichst vielen Texten enthalten sind. Für die Speicherung spezifischerer Informationen steht die im folgenden einzuführende Tabelle info zur Verfügung. 4.5.2 Speicherung hierarchischer textbezogener Informationen Informationen, die Hierarchien repräsentieren, eignen sich nicht für die Speicherung in textinfo, da für jede Hierarchiestufe ein eigenständiges Attribut verwendet werden müßte. Da die Zahl der zu erwartenden Ebenen schwer vorherzusagen ist, entstehen möglicherweise leere Einträge, da nicht jede Hierarchiestufe eines Textes belegt werden muß. Als Beispiel für solche Hierarchien wären etwa Gattungsbegriffe für literarische Texte zu nennen: Prosa, Fiktion, Utopie. Da durch das Attribut textno der Tabelle textinfo eine eindeutige Identifizierung von Texten möglich ist, lassen sich hierarchische Informationen in einer eigenen Tabelle ablegen und bei Bedarf einem bestimmten Text zuordnen. CREATE TABLE info ( text INTEGER NOT NULL , infohier INTEGER , 37 infocatg VARCHAR (32), infovalu VARCHAR (32), PRIMARY KEY ( text ) ) Abbildung 4.3 zeigt die Einordnung der als Beispiel genannten Gattungsbegriffe in eine geeignete Tabelle. Abbildung 4.3: Darstellung von Kategorien in der Tabelle info Kategorien Prosa Fiktion Utopie INFOHIER INFOCATG INFOVALU 1 2 3 Textart Textart Textart Prosa Fiktion Utopie Importfilter können den Attributen infocatg und infovalu bei Bedarf Kategoriename-Werte-Paare zuweisen. infohier ermöglicht eine Sortierung der Paare. Die Zuordnung zu einem bestimmten Text erfolgt über text. Die Kategoriename-Werte-Paare infocatg und infovalu gestatten den Importfiltern die Speicherung aller relevanten textuellen Informationen, die sie den Online-Texten entnehmen. Von besonderer Bedeutung ist hierbei, daß Tabellen nicht um Attribute erweitert werden müssen. Bei einer Speicherung in textinfo würde deren Attributzahl mit jeder neuen Kategorie zunehmen, was zu einem unnötig hohem Speicherbedarf führt, da zu vielen Texten bestimmte Kategorien nicht verfügbar sind. Aus diesen Gründen eignet sich info neben der Speicherung von hierarchischem Datenmaterial besonders für Informationen, von denen anzunehmen ist, daß sie nicht in allen Texten eines Korpus enthalten sind, die aber für Suchanfragen von Interesse sein können und daher im Korpus abgelegt werden sollten. 4.6 Zuordnung der beteiligten Tabellen zu einem Korpus Ein Desiderat an Korpusdatenbanken ist die Möglichkeit der Speicherung mehrerer Korpora. Wenn diese gemäß der n-Tabellen-Struktur abgelegt werden, entstehen ohne weitere Vorkehrungen Namenskonflikte. So müssen für jedes Korpus textinfo, info und tn Tabellen generiert werden. Eine mögliche Lösung dieses Problems liegt in der Verwendung globaler, für alle Korpora gültigen textinfo und info Tabellen. Gerade bei textinfo ist allerdings eine große Zahl von durch Importfilter vergebenen Attributen zu erwarten. Wenn nicht alle Korpora die gleiche Menge an textuellen Informationen enthalten, wird auf diese Weise Speicherplatz ungenutzt bleiben. Das Problem der Mehrfachvergabe von Namen bei tn Tabellen bleibt ungelöst. SQL-Schemas fassen logische Einheiten einer Datenbank zusammen: „A schema (more correctly, an SQL-schema) is a named collection of descriptors within a catalog. A descriptor in turn (to quote the standard) is “a coded description of an SQL object [that includes] all of the information about the object that a conforming SQLimplementation requires.” Each schema contains descriptors for the following types of objects (in general): • domains 38 • base tables [...] “2 Die Tabellen textinfo, info sowie tn werden grundsätzlich Schemas zugeordnet. Da in den in dieser Arbeit bisher aufgeführten Beispielen keine expliziten Schema-Zuordnungen getroffen wurden, gehören alle Tabellen zu einem Schema, das sich aus dem Namen des Datenbank-Nutzers ergibt: db2 => list tables for schema tommi Table/View Schema Type Creation time ------------ --------- ------- -------------------------T1 T2 [...] TOMMI TOMMI T T 1999-09-10-17.52.03.073621 1999-09-10-17.52.27.686120 In der Zuordnung zu einem Datenbank-Nutzer liegen auch die Gründe für die bereits angesprochenen Namenskonflikte. Da sich alle Tabellen jeweils auf ein bestimmtes Korpus beziehen, erscheint es sinnvoll, den Namen dieses Korpus als Schema-Name zu vergeben. Ein Schema wird durch die SQL-Anweisung CREATE SCHEMA angelegt. In S AN R EMO wird diese Operation durch die Komponente newcorpus.pl ausgeführt, die auch für die Generierung der benötigten Tabellen verantwortlich ist. Der Zugriff auf Tabellen eines Schemas erfolgt mit Hilfe des Operators . (Punkt): SELECT ∗ FROM tommi. types WHERE surface = ’ Text ’ Schemas ermöglichen die Zuordnung von Tabellen zu einem Korpus. Sie gestatten die Speicherung mehrerer Korpora in einer Datenbank und strukturieren auf diese Weise den Tabellenbestand. 4.7 Optimierung von Suchanfragen Um alle Korpuspositionen zu ermitteln, an denen ein positionales Attribut einen bestimmten Wert hat, sind auf der Basis der n-Tabellen-Struktur zwei Schritte nötig: • Suche nach allen zu einem Korpus gehörenden Texten; diese werden in textinfo gespeichert • Anzeigen aller Positionen in tn, an denen das gesuchte positionale Attribut den gewünschten Wert hat; dieser Schritt ist für jeden Text des Korpus auszuführen Die vorgestellte Strategie führt dazu, daß alle Korpuspositionen auf das Erfüllen des Suchkriteriums geprüft werden. Gerade bei niederfrequenten Wortformen erscheint eine Reduzierung des Suchraumes wünschenswert. 2 [Date 1997, S. 43] 39 Verfügbare Korpusdatenbanken führen umfangreiche Indexlisten, in denen jede Korpusposition vermerkt wird, an der ein Type als Token auftritt. Allerdings sind Aufbau und Pflege solcher Listen aufwendig. Einfüge- oder Löschoperationen erfordern eine Überprüfung und möglicherweise Korrektur der Indexdateien. Eine Implementierung von Indizes in S AN R EMO ist aufwendig, da jedem Type eine Liste von Korpuspositionen zugeordnet werden muß, die entsprechende Tokens beinhalten. Da die Zahl der Korpuspositionen für einzelne Types stark abweichen kann, ist die Speicherung in Attributen nicht zu realisieren. SQL kennt keine Mechanismen zur Speicherung von variablen Integerlisten. Auch Konstrukte analog zu VARCHAR(x) sind nicht optimal, da bei der Tabellendefinition eine Obergrenze (x) festgelegt werden muß. Diese ist schwer vorauszusagen. Dem Konzept der Normalisierung folgend, wäre eine mögliche Alternative die Einführung einer Tabelle positions, die jedem Type Korpuspositionen korrespondierender Tokens zuordnet. CREATE TABLE positions ( counter INTEGER NOT NULL , type INTEGER NOT NULL, position INTEGER NOT NULL , tablenam VARCHAR (10), PRIMARY KEY ( counter ) ) type verweist auf einen Eintrag in einer types Tabelle, die Attribute position und tablenam definieren die Korpusposition entsprechend der Vorgabe der nTabellen-Struktur. positions ordnet Types Korpuspositionen zu. Da dies auch tn Tabellen leisten, entsteht eine nicht zu vernachlässigende Redundanz an gespeicherten Informationen. Die Alternative, das Konzept der Text-spezifischen Token-Tabellen zugunsten der positions Tabelle zu verwerfen, führt zu dem bereits in Abschnitt 4.3.2 dargestellten Nachteil langer Antwortzeiten bei Suchanfragen. Da S AN R EMO durch Exportfilter die Möglichkeit bietet, Korpora in bestimmten Formaten zu speichern, müssen im Datenbestand alle relevanten Informationen vorhanden sein. Die von anderen Systemem angewandte Methode, ausschließlich mit Indexdateien zu arbeiten, ist aus diesem Grund nicht realisierbar. Da eine Generierung und Speicherung von Indexdateien zusätzlich zu den ohnehin vorhandenen Korpusdaten Redundanz erzeugen würde, verzichtet S AN R EMO auf die Erstellung solcher Listen. Indizes, die das Datenbanksystem intern generiert, bleiben hiervon natürlich ausgenommen. Um bei Suchanfragen nicht alle Korpuspositionen prüfen zu müssen, greift S AN R EMO auf folgende Strategien zur Optimierung zurück: • Für jedes Type wird die Zahl der korrespondierenden Tokens gespeichert. • Korpora werden in Bereiche zerlegt; jedes Type enthält Informationen über Bereiche, in denen es als Token auftritt. Die Anzahl der Tokens wird im Attribut type_count der types Tabelle gespeichert. Komponenten, die Suchanfragen ausführen, können ihre Tätigkeit 40 beenden, wenn der Datenbankkern eine entsprechende Anzahl von Ergebnissen gemeldet hat. Das Attribut map speichert, in welchen Bereichen eines Korpus ein Type als Token auftritt. Der entsprechende Teil der in Abschnitt 4.4 vorgestellten types Tabelle map CLOB(128) ermöglicht die Einteilung eines Korpus in maximal 1024 Bereiche, da jedes der 128 Zeichen des map Attributs 8 Bereiche speichern kann, wobei in diesem Fall jedes Bit einen Bereich repräsentiert. Hierbei bedeutet ein gesetztes Bit, daß das zugeordnete Type im korrespondierenden Korpusbereich mindestens einmal als Token auftritt. Die Aufteilung eines Korpus in Bereiche erfolgt anhand korpusweit eindeutiger Nummern, die jedem Text in textinfo zugeordnet werden. Ausgehend von der Gesamtmenge an Bereichen g mit 1 ≤ g ≤ 1024 läßt sich der Bereich, dem Text x zuzuordnen ist, durch die Funktion f (g, x) = x mod g bestimmen. Die Modulo-Funktion mod liefert den Rest der ganzzahligen Division der Werte x und g. Auf diese Weise lassen sich dem Korpus neue Texte hinzufügen. Selbst eine Überschreitung der durch g festgelegten Bereichsgrenze verhindert nicht eine korrekte Zuordnung des Texts zu einem Bereich. Durch die Einführung von Korpusbereichen lassen sich die bei Suchanfragen zu prüfenden Korpuspositionen gerade bei niederfrequenten Wortformen reduzieren. Die Auswertung der in types abgespeicherten Informationen ist hierbei durch die eine Suche veranlassende Komponente vorzunehmen. Die Wahl eines geeigneten Wertes für g ist von der zu erwartenden Zahl an Texten eines Korpus abhängig. Damit Komponenten das Attribut map in geeigneter Form auswerten können, muß die für ein Korpus gewählte Bereichsgröße in der Datenbank gespeichert werden. 4.8 Registrierung der Korpora in der Datenbank Für Anwender einer Korpusdatenbank kann es von Interesse sein, die ihm zur Verfügung stehenden Korpora zu erfragen. Hierfür stellt S AN R EMO die Tabelle toc zur Verfügung, in der alle Korpora durch Importfilter und am Aufbau von Korpora beteiligten Komponenten registriert werden. CREATE TABLE SanRemo. toc ( corpusno INTEGER NOT NULL, parts INTEGER , name VARCHAR (20), PRIMARY KEY( corpusno ) ) In name wird der Name des Korpus abgelegt, der (wie in Abschnitt 4.6 beschrieben wurde) als SQL-Schema interpretiert wird. Von Bedeutung ist das Attribut parts, das die Zahl der Korpusbereiche angibt. toc bildet die oberste Hierarchiestufe der in S AN R EMO verwendeten Tabellenstruktur. Um diesem Aspekt Rechnung zu tragen und um Problemen durch die Vergabe von Schema-Namen auf der Basis des Benutzernamens vorzubeugen, wird für die Tabele toc ein eigenes Schema, SanRemo, eingeführt. 41 4.9 Zusammenfassung der Tabellenstruktur Die n-Tabellen-Struktur bildet die Grundlage für die Speicherung aller korpusbezogenen Informationen. Die in die Tabellen einzufügenden Daten werden von Importfiltern geliefert, die das Korpusmaterial analysieren und aus den Online-Texten alle relevanten Informationen extrahieren. Durch die Unterscheidung zwischen Types und Tokens wird die Speicherung redundanter textueller Informationen vermieden. Die types Tabelle kann für die einfache Suche nach Wortformen und für die Generierung von Wortlisten verwendet werden. Die einzelnen tn Tabellen bewahren die Struktur der Originaltexte. Im Gegensatz zu existierenden Korpusdatenbanken greift S AN R EMO bei Suchanfragen nicht auf spezielle Indizes zu. Durch das Hinzufügen oder Löschen von Texten müssen solche Indexdateien aufwendig reorganisiert und aktualisiert werden. Dies ist bei S AN R EMO nicht nötig. Ferner lassen sich, entsprechende Exportfilter vorausgesetzt, die Korpusdaten in beliebigen Formaten speichern, was die weitgehend identische Reproduktion des Originaltextes beinhaltet. Abbildung 4.4: An der n-Tabellen-Struktur beteiligte Tabellen SanRemo.toc Korpus 3 Korpus 2 Korpus 1 types t1 textinfo t2 info Die Tabelle info gestattet die flexible Speicherung von textbezogenen Informationen, wobei Importfilter nach eigenem Ermessen Kategoriename-WertePaare speichern können. Die Anwendung dieses Konzepts auf positionale Attribute ist aufwendig, da jeder Text in einer eigenständigen Token-Tabele abgelegt wird, weshalb eine entsprechende Tabelle nicht nur die Textnummer sondern auch die Nummer der laufenden Wortform speichern müßte. Ferner würde sich die Komplexität bei Suchanfragen weiter erhöhen, was zu einer Reduzierung der Suchgeschwindigkeit führt. Aus diesem Grund werden positionale Attribute den einzelnen tn Tabellen als Attribute hinzugefügt. Auch die Aufgabe der Erweiterung von tn Tabellen kommt den Importfiltern zu. Importfilter sind die zentralen Komponenten beim Einbringen von Korpusdaten. Die Tabellenstruktur stellt nur die zur Speicherung nötige Infrastruktur 42 zur Verfügung. Das Delegieren der Suche nach relevanten Informationen an den Filter ermöglicht die Speicherung nahezu beliebig strukturierter Korpora. Durch die Attribute map und type_count ermöglicht die n-Tabellen-Struktur die Reduzierung der für die Ausführung von Suchanfragen benötigten Zeit. Für die Auswertung diesbezüglicher Informationen sind ebenfalls Komponenten zuständig. Die Beziehung der an der n-Tabellen-Struktur beteiligten Tabellen ist in Abbilung 4.4 dargestellt. 43 44 5 Filter Das bei Korpusdatenbanken bisher unbekannte Filter-Konzept gestattet eine einfache Erweiterung eines bestehenden Systems. S AN R EMO unterscheidet zwischen Importfiltern, die Online-Texte eines vorgegebenen Formats interpretieren und dem Korpusbestand hinzufügen, und Exportfiltern, die die Speicherung von Korpusdaten in durch den Filter vorgegebenen Formaten ermöglichen. 5.1 Allgemeine Bemerkungen Das Filter-Konzept ist in vielen Bereichen der elektronischen Datenverarbeitung weit verbreitet. Systeme, die das elektronische Publizieren am Rechner (desktop publishing, DTP) ermöglichen, profitieren von Filtern, die mit anderen Programmen gespeicherte Texte einlesen können. Im Multimedia-Bereich nutzen Programme zur elektronischen Bildverarbeitung (EBV) Filter nicht nur, um Bilddokumente unterschiedlicher Herkunft einlesen zu können, sondern ermöglichen ferner optische Veränderungen am Datenmaterial, etwa das Verändern der Helligkeit. Generell erweitern Filter die Funktionalität eines Programmsystems. Hierzu stellt das System eine definierte Schnittstelle zur Verfügung, über die Programm und Filter Daten und Anweisungen austauschen. Da sich Filter dem Anwender nicht als eigenständige Programme darstellen, sondern in ein bestehendes System integriert werden, bezeichnet man sie häufig als plug ins. Korpusdatenbanken können auf unterschiedliche Weise vom Filter-Konzept profitieren: • Durch die Bereitstellung entsprechender Importfilter können Korpora nahezu beliebigen Formats eingelesen werden. • Exportfilter können Korpusdaten in verschiedenen Formaten verfügbar machen. • Anzeigefilter können die Korpusdaten auf unterschiedliche Weise darstellen. 45 Die dem Autor bekannten Korpusdatenbanken machen von Filtern in der dargestellten Form keinen Gebrauch. 5.2 SGML Die Metasprache SGML (Standard Generalized Markup Language) ist ein internationaler Standard zur Definition von Auszeichnungssprachen. 1 SGML-Dokumente entsprechen einer definierten, leicht zu parsenden baumartigen Struktur. Im folgenden werden Merkmale dieser Sprache vorgestellt, die sie zu einem idealen Träger elektronisch gespeicherter textueller Informationen machen. SGML-Dokumente bestehen aus Elementen folgender Form: <t a1=v1 a2=v2 ... an=vn> c </t> Hierbei sind <t ...> und </t> Start- und End-Tags, c beschreibt Inhalte und an=vn enthalten Attribut-Wert-Paare. c kann leer sein, Texte, Elemente oder Kombinationen aus Texten und Elementen enthalten. Die baumartige Struktur von SGML-Dokumenten entsteht durch die Möglichkeit der Schachtelung von Tags. Während Tags die Struktur eines Dokuments festlegen, charakterisieren Attribute die Eigenschaften von Elementen. Die Menge der zur Verfügung stehenden Attribute und Tags wird in der document type definition (DTD) vorgenommen. SGML bietet die Möglichkeit, Online-Texte mit beliebigen Auszeichnungen zu versehen. Diese können die Struktur des Textes kennzeichnen, etwa indem sie Überschriften, Absatz- oder Kapitelgrenzen markieren. Gerade im Hinblick auf Korpora ist die Möglichkeit von Bedeutung, einzelne Wörter durch Attribute mit zusätzlichen Informationen zu versehen. Auf diese Weise lassen sich den Tokens beliebige grammatische Kategorien sowie andere Wortformbezogene Annotierungen zuordnen. Allerdings definiert SGML nur die formale Struktur eines Dokuments. Zwar kann die Richtigkeit eines SGML-ausgezeichneten Textes anhand der DTD überprüft werden, die Wahl der Tags und Attribute bleibt dem Anwender überlassen. Die Text Encoding Initiative (TEI) pflegt eine Sammlung von Richtlinien, die für bestimmte Texttypen die zu verwendenden Tags und Attribute enthält.2 Für die Kodierung des British National Corpus wurde die Auszeichnungsvariante Corpus Data Interchange Format (CDIF) verwendet, die sich an TEIVorgaben orientiert.3 5.3 Exportfilter Exportfilter können den Datenbestand einer Korpusdatenbank auf eine Weise speichern, die die Weiterverarbeitung dieses Materials mit anderen Programmen gestattet. Sie ermöglichen damit • die Verwendung eines Korpus in einer anderen Korpusdatenbank 1 2 3 46 Siehe hierzu [Goldfarb 1990] Siehe hierzu [Ide 1995] [Aston 1998, S. 33] • die Distribution eines Korpus in einem verbreitetem Format • Vorbereitung der Veröffentlichung eines Korpus in elektronischer oder gedruckter Form Die Übernahme eines Korpus in eine andere Korpusdatenbank ließe sich mit einem Exportfilter realisieren, der SGML-Dokumente generieren kann. Eine Veröffentlichung von Korpustexten im Internet ist möglich, wenn ein auf SGML aufbauender Filter HTML-Dokumente erzeugen kann. Im Rahmen der experimentellen Implementierung von S AN R EMO wurden bisher keine Exportfilter programmiert. 5.4 Importfilter Bevor Anwender einer Korpusdatenbank auf die gespeicherten Texte zugreifen können, müssen die Korpus-Rohdaten mit geeigneten Programmen in die Datenbank eingefügt werden. Ziel eines solchen Imports ist es, alle im OnlineText gespeicherten Informationen in die Datenbasis zu übernehmen. Die nTabellen-Struktur bildet die Grundlage für die Speicherung von Korpusdaten. Die Informationen werden durch Importfilter bereitgestellt. Diese extrahieren aus Online-Texten alle relevanten Informationen und fügen sie den entsprechenden Tabellen durch geeignete SQL Kommandos hinzu. Diese Informationen lassen sich in verschiedene Gruppen einteilen, nämlich • Korpusbezogene Informationen, • textbezogene Informationen, • Korpusannotationen und • Wortformen. 5.4.1 Generelle Überlegungen Eine Korpusdatenbank sollte jederzeit durch neue Texte ergänzt werden können. Ferner sind an die am Import beteiligten Komponenten bestimmte Anforderungen zu stellen. 5.4.1.1 Löschen von Texten Eine Korpusdatenbank muß nicht nur das Hinzufügen neuer Texte ermöglichen, sondern auch das gezielte Entfernen nicht mehr benötigter Dokumente unterstützen. Die n-Tabellen-Struktur kommt diesem Desiderat nach, indem sie die Tabelle textinfo vorsieht, die jedem Text eines Korpus eine eindeutige Nummer zuordnet und den Namen der betreffenden Token-Tabelle speichert. 5.4.1.2 Benutzbarkeit während eines Einfügevorgangs Die Korpusdatenbank sollte während einer Einfügeoperation weitgehend benutzbar bleiben. Hierbei ist zwischen der Benutzbarkeit anderer, nicht vom Import betroffener Korpora, sowie des Korpus, dem neue Texte hinzugefügt 47 werden sollen, zu unterscheiden. Im ersten Fall ist eine weitere Verwendbarkeit in jedem Fall zu gewährleisten, da das zugrunde liegende Datenbanksystem für die nötige Abschirmung der einzelnen Korpora sorgen kann. Auch die Benutzbarkeit des Korpus, dem Texte hinzugefügt werden, kann gewährleistet werden, wenn für den Import ausschließlich Elemente von SQL verwendet werden. 5.4.2 Importfilter für das BNC Um das BNC in S AN R EMO importieren zu können, wurde ein Filter entwickelt, der Textdateien einlesen kann, die in jeder Zeile eine Wortform des Textes enthalten. Solche Dateien enthalten keine weiteren textbezogenen Informationen sowie keine grammatische Kategorien oder andere positionale Attribute. Für die Übermittlung der eingelesenen Wortformen an die Datenbank kann der Filter auf Elemente von SQL zurückgreifen oder spezifische Werkzeuge des verwendeten Datenbanksystems ansprechen. Um den Zeitbedarf für Einfügevorgänge beurteilen zu können, wurden beide Varianten als Perl-Programme realisiert. Da die einzufügenden Texte außer den Wortformen keine weiteren Informationen enthalten, beinhaltet die Arbeit des Filters das Einlesen der Wortform sowie das Übertragen in die entsprechenden Tabellen der Datenbank. Für jedes Wort wird zunächst geprüft, ob die Oberfläche dieser Wortform bereits als Type in der Tabelle type enthalten ist. Trifft dies zu, kann die in running_type gespeicherte eindeutige Nummer des Types ermittelt werden. Im anderen Fall ist eine eindeutige, noch nicht vergebene Nummer zu bestimmen und mit dem Type in type einzutragen. Weiter ist der ermittelte oder berechnete running_type mit einer ebenfalls eindeutigen Nummer in der token Tabelle zu speichern. Da die n-Tabellen-Struktur für jeden Text eine eigenständige Token-Tabelle vorsieht, muß der Filter diese vor dem Einlesevorgang generieren und nach erfolgreichem Import in der Tabelle textinfo eintragen, um die Zugehörigkeit des Textes zu einem Korpus zu markieren. Da textinfo alle relevanten Informationen über einen eingelesen Text speichert, beispielsweise den Namen der Tabelle, in denen die Wortformen abgelegt werden, ist ein nachträgliches Hinzufügen von positionellen Attributen problemlos möglich. 5.4.2.1 Implementierung auf der Basis von SQL Die in Abschnitt 5.4.2 beschriebene Vorgehensweise beinhaltet sowohl lesende als auch schreibende Zugriffe auf die Datenbank. Die Suche nach vorhandenen Types geschieht durch SELECT Anweisungen. Besteht der zu importierende Text aus n Wortformen, sind im Idealfall, falls also alle Wortformen bereits als Types erfaßt wurden, n Anfragen an die type Tabelle. Im Falle nicht gefundener Types sind entsprechend viele INSERT Befehle nötig. Da die Token-Tabelle für jeden Text neu angelegt wird, sind in jedem Fall n INSERT Anweisungen nötig. Eine allgemein gültige Aussage über die Häufigkeit des Auftretens unbekannter Types ist nicht möglich. Die Struktur des Korpus, die Auswahl der Texte sowie die Reihenfolge des Imports sind beeinflussende Faktoren. 48 Um Anfragen an die Datenbank und den damit verbundenen zeitlichen Aufwand zu minimieren, können bereits gefundene Types sowie deren eindeutige Nummer durch das Perl-Programm zwischengespeichert werden. Vor einer Anfrage an die Datenbank ist demnach zu prüfen, ob die benötigten Informationen bereits vorliegen; nur wenn dies nicht der Fall ist, erfolgt ein Zugriff auf die Datenbank. Der hierdurch erreichbare Zuwachs an Geschwindigkeit ist von der Größe des einzulesenden Textes sowie dessen Aufbau (also Häufigkeit und Verteilung einzelner Wortformen) abhängig. Allerdings steht der kürzeren Einfügedauer ein deutlich größerer Speicherplatzbedarf des Programms gegenüber. Im Hinblick auf die derzeit verfügbaren Rechner und deren Speicherkapazität dürfte dieser Aspekt allerdings zu vernachlässigen sein. Abhängig von der Größe des einzulesenden Textes sind viele Einzelanfragen an die Datenbank nötig. Da alle Änderungen an vorhandenen Daten durch das Datenbanksystem vorgenommen werden, ist während des Import-Vorgangs ein weiterer Zugriff auf das Korpus möglich. 5.4.2.2 Verwendung RDBMS-spezifischer Mechanismen Eine zweite Realisierung des Filters liegt mit dem Programm turbo.pl vor. Ziel dieser Implementierung war, die Zahl der Anfragen an das RDBMS so gering wie möglich zu halten. Dies wird durch die Verwendung von Dienstprogrammen, die das Datenbanksystem zur Verfügung stellt, erreicht. Die Werkzeuge LOAD und EXPORT können vollständige Tabellen in ASCII-Dateien ablegen, bzw. aus diesen in Tabellen einfügen. Sie wurden speziell für die Verarbeitung großer Datenmengen bereitgestellt, und versprechen einen deutlichen Geschwindigkeitszuwachs beim Einleseprozeß. Voraussetzung für die Anwendung solcher Dienstprogramme ist, daß die Programmiersprache die Ausführung nativer Programme auf einem Rechner unterstützt. Dies ist im Falle von Perl gewährleistet. Das Programm turbo.pl bedient sich des LOAD-Werkzeugs, um die TokenTabelle in die Datenbank zu übernehmen. Hierzu werden die Wortformen zunächst in einer Datei zwischengespeichert, die LOAD dann einliest. Werden auf diese Weise nur Zugriffe auf die Token-Tabelle ersetzt, bleibt das Korpus während des Einlesevorgangs benutzbar. Eine weitere Möglichkeit der Geschwindigkeitssteigerung besteht im vollständigen Export der Type-Tabelle mit dem EXPORT Kommando. Die auf diese Weise generierte Datei kann vom Filter eingelesen werden. Erst nach dem vollständigen Importieren des Textes wird die Type-Tabelle in aktualisierter Form in die Datenbank zurückgeschrieben. Die Verwendung DBMS-spezifischer Dienstprogramme ist einer reinen SQLbasierten Lösung nur dann vorzuziehen, wenn sehr oft große Korpora eingelesen werden müssen, da die Anwendung solcher Komponenten die Verfügbarkeit der Dienstprogramme unter gleichem Namen sowie mit gleicher Zahl von zu übergebenden Parametern voraussetzt. 5.4.2.3 Abwägung der beiden Methoden Beide Filter wurden für den Import von Texten des BNC verwendet. Die hierzu benötigten Zeiten sind von mehreren Faktoren abhängig. Neben technischen 49 Aspekten wie der Leistung des verwendeten Computersystems ist in diesem Zusammenhang die Bandbreite des Netzwerkes zu nennen. Ebenfalls von Belang sind aber korpusspezifische Faktoren wie Anzahl der Texte oder Zahl der bereits bekannten Types. Kapitel 7.1 beschäftigt sich mit Erfahrungen im praktischen Einsatz. 50 6 Korpusanfragen In diesem Kapitel werden Fragen, die die Kommunikation des Anwenders mit S AN R EMO betreffen, diskutiert. In diesem Zusammenhang ist auf die Eignung von SQL als Benutzeranfragesprache einzugehen. Ferner werden grundsätzliche Anforderungen an Korpusanfragesprachen formuliert. 6.1 Korpusanfragen in SQL 6.1.1 SQL als Benutzeranfragesprache Der Zugriff auf ein Korpus erfolgt durch Formulierung geeigneter Suchanfragen. Die dem Anwender zur Verfügung stehenden Funktionen werden durch die verwendete Anfragesprache vorgegeben. Bei einer Korpusdatenbank auf der Basis eines RDBMS steht SQL als Datenbanksprache zur Verfügung. Deren komplexe Syntax sowie die in Kapitel 4 vorgestellte Aufteilung der Korpusdaten auf types und tn Tabellen erschweren die Eingabe geeigneter SQL-Konstrukte. Zudem kann beim intendierten Benutzerkreis von Korpusdatenbanken eine fundierte Kenntnis dieser Sprache nicht vorausgesetzt werden. 6.1.2 SQL als Basis für Korpusanfragen Die in Abschnitt 3.2 vorgestellte Architektur von S AN R EMO sieht SQL als zentrales Kommunikationsmittel zwischen den Komponenten der Benutzerebene und dem Datenbanksystem vor. In diesem Abschnitt werden Anfragen aus Benutzersicht und ihre Darstellung in SQL vorgestellt. 6.1.2.1 Suche nach Wortformen Bei der Suche nach Wortformen sind alle Korpuspositionen aufzulisten, an denen ein bestimmtes Token auftritt. Alle Texte eines Korpus werden in textinfo eingetragen. Wenn der Benutzer die Menge der zu durchsuchenden Texte nicht einschränkt, sind die im folgenden darzustellenden Anweisungen für jeden Text auszuführen. 51 • Suche nach passender Wortform im Attribut surface der Tabelle types • wird eine solche Wortform gefunden, enthält running_type eine korpusweit eindeutige Nummer, nach der im Attribut token der Tabelle tn zu suchen ist. 6.1.2.2 Erstellung sortierter Wortlisten Die Erstellung sortierter Wortlisten ist mit einer SELECT Anweisung realisierbar: SELECT ∗ FROM types ORDER BY surface ASC SELECT ∗ FROM types WHERE surface >= ’ Text ’ ORDER BY surface ASC Eine Sortierung nach der Häufigkeit des Auftretens ist durch die Verwendung des Attributs type_count als Sortierkriterium ebenfalls möglich. 6.1.3 KWIC-Listen Die Darstellung einer KWIC-Liste ist durch folgendes SQL-Konstrukt möglich: SELECT surface , TEMP. running_token FROM types , ( SELECT ∗ FROM t1 WHERE running_token <= 3 and running_token >= 1 ) AS TEMP WHERE types . running_type = TEMP. token ORDER BY TEMP. running_token ASC Diese Anweisung liefert alle Wortformen an den Korpuspositionen 1, 2 und 3. Von besonderer Bedeutung ist hierbei, daß die für eine Bildschirmausgabe benötigten Oberflächen ohne weitere Anfragen ermittelt werden können. Die Grenzen der Anfrage (1 und 3) können durch die eine Anfrage stellende Komponente beliebig gesetzt werden. Um etwa den Kontext einer Wortform darzustellen, ist nach dieser Wortform in der types Tabelle zu suchen. Die Grenzen für die folgende SELECT Anweisung ergeben sich aus ihrer Korpusposition in einer tn Tabelle. 6.2 Allgemeine Anforderungen Die in der Datenbank abgelegten Korpusdaten lassen sich in textbezogene Informationen und positionale Attribute unterteilen. Textbezogene Informationen, etwa die Zuordnung zu einer oder mehreren Kategorien, können verwendet werden, um Teilkorpora zu definieren. Positionale Attribute werden vor allem bei Suchanfragen nach Wortformen oder grammatischen Kategorien verwendet. Häufig wird eine solche Suche in einem durch die Auswertung von textuellen Informationen eingeschränkten Suchraum stattfinden. Bei Anfragen an das System muß demnach die Möglichkeit des Zugriffs sowohl auf textbezogene Informationen als auch auf positionale Attribute gewährleistet werden. Ebenfalls wünschenswert ist, daß die Anfragesprache mögliche Erweiterungen in der Tabellenstruktur berücksichtigt. Aus diesem Grund sollten Zugriffe auf beliebige Attribute einzelner Tabellen möglich sein. Geeignete Importfilter könnten beispielsweise fremdsprachliche Grundformen zu einem Wort liefern 52 und in der token Tabelle ein neues Attribut einführen. Wenn die Anfragesprache den Zugriff auf beliebige Attribute gestattet, können auch solche nachträglich bereitgestellten Informationen in Suchanfragen verwendet werden. Eine geeignete Anfragesprache sollte ferner nicht nur auf die gespeicherten Textdaten zugreifen können, sondern auch Analysen hinsichtlich grammatischer Phänomene oder dem sprachlichen Umfeld einer Wortform ermöglichen. Von großer Bedeutung ist eine schnelle Formulierbarkeit von Anfragen. Unnötige Schlüsselwörter sollten bei der Definition der Syntax einer solchen Sprache vermieden werden. Idealerweise reduziert sich die SQL-Anfrage SELECT ∗ FROM korpus . types WHERE surface = ’ Korpus ’ auf die Eingabe der Wortform Korpus. 6.3 SgmlQL SgmlQL ist eine Anfragesprache für SGML-kodierte Texte. Als eine Erweiterung von SQL gestattet sie den Zugriff auf die in SGML-Texten gespeicherten Informationen sowie die Bearbeitung der Annotationen. Die Sprache ist an die Baumstruktur von SGML-Dokumenten angepaßt. Eine Auszeichnung von Korpora mit SGML-Tags gestattet die Speicherung von bibliographischen Angaben, Informationen über die Struktur der Dokumente (etwa Satz-, Absatz- oder Kapitelgrenzen) sowie grammatischen Kategorien einzelner Wortformen. Maitre, Murisasco und Rolbert sehen mit solchen Informationen angereicherte Korpora als Datenbanken an, wobei SGML die Daten-Definitionssprache darstellt.1 Allerdings übernimmt SgmlQL die komplexe Syntax von SQL. Aus diesem Grund ist die Formulierung von Anfragen aufwendig und fehleranfällig. 6.4 Grafische Benutzeroberflächen Eine Korpusanfragesprache bietet einen umfassenden Zugriff auf textuelle Informationen und positionale Attribute. Für weniger komplexe Anfragen, etwa die Suche nach einer bestimmten Wortform oder die Ermittlung deren Frequenz, ist die Auswahl aus einer Liste für den Anwender eine komfortable Alternative. Eine solche Komponente der Korpusdatenbank kann alle Einträge der types Tabelle in Form einer alphabetisch sortierten Liste darstellen, aus der der Benutzer die gewünschte Wortform nur mit Hilfe der Maus auszuwählen braucht. Eine Voraussetzung hierfür ist die Verfügbarkeit einer grafischen Benutzeroberfläche auf dem verwendeten Rechnersystem. Zwar werden gängige Systeme mit solchen Komponenten ausgestattet, allerdings differiert die Programmierung des grafischen Systems häufig. Um die Portierbarkeit einer Korpusdatenbank nicht einzuschränken, ist bei der Wahl der Programmiersprache für solche grafischen Anfragekomponenten die Unterstützung möglichst vieler Benutzeroberflächen wünschenswert. 1 [Maitre 1997, S. 37] 53 Die Sprache Java erfüllt diese Desiderata, indem sie dem Programmierer unabhängig vom grafischen System der Zielplattform einen Satz grafischer Komponentnen zur Verfügung stellt. 54 7 Zusammenfassung Die Konzeption der n-Tabellen-Struktur erlaubt die flexible Speicherung von Korpusdaten sowie zusätzlicher textueller Informationen. Praktische Tests sollen die theoretische Eignung relationaler Datenbanksysteme zur Speicherung von Korpora verifizieren. Die Arbeit schließt mit der Nennung möglicher Erweiterungen des Systems. 7.1 SanRemo im praktischen Einsatz 7.1.1 Import des BNC Das British National Corpus ist aufgrund seiner Größe gut für die Untersuchung der Eignung relationaler Datenbanksysteme zur Speicherung von Korpora auf der Basis der in Kapitel 4 vorgestellten n-Tabellen-Struktur geeignet. An der Abteilung für Computerlinguistik der Friedrich-Alexander-Universität Erlangen-Nürnberg steht das BNC in der Version 1.0 in SGML-ausgezeichneter Form zur Verfügung. Ferner liegen die Texte des Korpus in Form von 4124 Dateien vor, die jeweils eine Wortform in einer Zeile enthalten. Diese wurden für den Import in S AN R EMO herangezogen. Im Verlauf der Arbeit wurden Teile dieser Dateien in die n-Tabellen-Struktur eingelesen. 7.1.2 Anfragen Die Komponenten textinfo.pl, text.pl und kwic.pl erlauben den Zugriff auf die in der n-Tabellen-Struktur abgelegten Korpusdaten. Die Ermittlung statistischer Informationen durch textinfo.pl hat sich in Testläufen als nicht problematisch erwiesen. Der Aufruf der Komponente kwic.pl führte vor der Änderung der Tabellenstruktur durch Einführung der Attribute map und type_count zu sofortiger Anzeige von Fundstellen, allerdings führt die Durchsuchung des gesamten Korpus zu einer insgesamt langen Wartezeit. Diese Wartezeit läßt sich durch konsequente Nutzung der Korpusbereiche erheblich reduzieren. 55 7.1.3 Einfügevorgänge Praktische Versuche ergaben im Durchschnitt Einfügezeiten von 20 Minuten für das Programm fill.pl sowie 3 Minuten für turbo.pl. Aufgrund bereits dargelegter Abhängigkeiten von der zur Verfügung stehenden Hardware lassen sich die ermittelten Werte nicht ohne weiteres auf andere Umgebungen übertragen. Der deutlich geringere Zeitbedarf läßt die Verwendung der durch die Implementierung von turbo.pl vorgestellten Methode als sinnvoll erscheinen. 7.2 Zusammenfassung und Bewertung der Praxistauglichkeit Anwender von Korpusdatenbanken werden häufig mit systemspezifischen Einschränkungen konfrontiert. So sind manche Systeme für spezifische Korpora ausgelegt, benötigen für die Ausführung komplexer Suchanfragen sehr lange oder werden bei umfangreichen Korpora instabil. Relationale Datenbanksysteme haben ihre Verläßlichkeit und Geschwindigkeit in den unterschiedlichsten Bereichen der elektronischen Datenverarbeitung unter Beweis gestellt. Es erschien daher vielversprechend, ihre Eignung für die Korpuslinguistik zu untersuchen. Die Korpusdatenbank S AN R EMO wurde entwickelt, um die Verwendbarkeit des relationalen Datenbanksystems IBM DB/2 für die Speicherung von umfangreichen Korpora zu untersuchen. Hierzu wurden in der Programmiersprache Perl Komponenten entwickelt, die Korpusinformationen des BNC in SQLTabellen einfügen können. Im Verlauf der Arbeit hat sich gezeigt, daß die Beschaffenheit und Verknüpfung der verwendeten Tabellen in starkem Maße die Geschwindigkeit von Anfragen an das System beeinflußt. Die in der Arbeit vorgestellte n-Tabellen-Struktur ist nach der Einführung des Konzepts der Korpusbereiche für die Speicherung und Abfrage umfangreicher Korpora geeignet. Die Zugriffe erfolgen in einem für den Anwender akzeptablen zeitlichen Rahmen. Auch die für den Import von Texten zu veranschlagende Zeit liegt in akzeptablen Grenzen. Hierbei ist zu berücksichtigen, daß die Menge an zu erwartenden Einfügevorgängen im Vergleich zu Suchanfragen zu vernachlässigen ist. Akzeptable Antwortzeiten auf Suchanfragen sind bei Korpusdatenbanken ein bestimmenderer Faktor. Für den Einsatz relationaler Datenbanksysteme spricht die leichte Verfügbarkeit auf zahlreichen Rechner-Systemen. Allerdings erfordern solche Programme leistungsfähige Hardware, gerade wenn umfangreiche Korpora eingelesen werden sollen. 7.3 Mögliche Erweiterungen S AN R EMO wurde nicht primär vor dem Hintergrund einer allgemeinen Verfügbarkeit entwickelt. Aus diesem Grund genügen die Komponenten nicht den Ansprüchen eines Anwenders. Der Aufbau des Systems gestattet allerdings einen problemlosen Austausch einzelner Komponenten. 56 Im Rahmen einer Erweiterung des Systems ist zunächst eine geeignete Anfragesprache zu implementieren. Die Ergebnisse dieser Arbeit zeigen die grundsätzliche Eignung von SQL als Basis für Korpusanfragen. Eine InterpreterKomponente muß Benutzeranfragen in entsprechende SQL-Konstrukte umsetzen. Ferner erscheint die Entwicklung komplexer Import-Filter wünschenswert. Die weite Verbreitung der Metasprache SGML legt die Implementierung eines Filters nahe, der SGML-kodierte Texte auswerten und die entsprechenden Informationen in die n-Tabellen-Struktur übernehmen kann. Um die Verbreitung von Korpora zu erleichtern, wäre ferner ein Exportfilter von Interesse, der SGML-Dokumente erzeugt. Andere mögliche Erweiterungen des Systems betreffen die grafische Aufbereitung von Suchergebnissen sowie die Unterstützung von SQL-Zugriffsrechten. Von besonderer Bedeutung wäre in diesem Fall die Bereitstellung einer Benutzerkomponente auf der Basis eines Java-Applets, das eine Nutzung von Korpora über das Internet gestatten würde. 57 58 Literaturverzeichnis [Aarts 1990] Aarts, J., Meijs, W. (Hrsg.) (1990): Theory and Practice in Corpus Linguistics. Language and Computers: Studies in Practical Linguistics 4, Amsterdam: Rodopi. [Aston 1998] Aston, Guy, Burnard, Lou (1998): The BNC Handbook: Exploring the British National Corpus with SARA Edinburgh: Edinburgh University Press. [Armstrong 1994] Armstrong, S. (Hrsg.) (1994): Using Large Corpora. Cambridge, MA: MIT Press. [Biber 1998] Biber, D., Conrad, S., Reppen, R. (1998): Corpus linguistics: Investigating Language Structure and Use. Cambridge: Cambridge University Press. [Burnard 1996] Burnard, Lou (1996): Introducing SARA: An SGML-Aware Retrieval Application for the British National Corpus; verfügbar im Internet unter ⟨http://info.ox.ac.uk/bnc/using/papers/burnard96a.htm⟩ [Christ 1994] Christ, Oliver, Schulze, Bruno M. (1994): Ein flexibles und modulares Anfragesystem für Textkorpora. Institut für Maschinelle Sprachverarbeitung (IMS), Universität Stuttgart. [Date 1997] Date, C. J., Darwen, Hugh (1997): A Guide to the SQL Standard. Reading, MA: Addison-Wesley. [Date 1990] Date, C. J. (1990): An Introduction to Database Systems. Reading, MA: Addison-Wesley. [Dunham 1998] Dunham, Jeff (1998): Database Performance Tuning Handbook. New York: McGraw-Hill. [Elmasri 1989] Elmasri, R., Navathe, Sh. (1989): Fundamentals of Database Systems. Reading, MA: Addison-Wesley. [Francis 1964] Francis, W. N., Kucera, H. (1964): Brown Corpus Manual; MANUAL OF INFORMATION to accompany A Standard Corpus of Present-Day Edited American English, for use with Digital Computers; 59 durchgesehene und erweiterte Fassung von 1979, verfügbar im Internet unter ⟨http://khnt.hit.uib.no/icame/manuals/brown/INDEX.HTM⟩ [Goldfarb 1990] Goldfarb, Charles F. (1990): The SGML handbook. Oxford: Oxford University Press. [Hill 1979] Howard-Hill, T. H. (1979): Literary Concordances: a Complete Handbook for the Preparation of Manual and Computer Concordances . Oxford: Pergamon. [Ide 1995] Ide, N., Veronis, J. (Hrsg.) (1995): The Text Encoding Initiative: Background and Context. Dordrecht: Kluwer. [Maitre 1997] Le Maitre, J., Muriasco, E., Rolbert, M. (1997): From Annotated Corpora to Databases: The SgmlQL Language. In: Nerbonne, J.: Linguistic Databases. CSLI Lecture Notes 77, S. 37–58. [Schneider 1997] Schneider, H.-J. (Hrsg.) (1997): Lexikon Informatik und Datenverarbeitung. Oldenburg: Opladen. [Sinclair 1991] Sinclair, John (1991): Corpus – Concordance – Collocation. London: Longman. [Souter 1993] Souter, C., Atwell, E. (Hrsg.) (1993): Corpus-based Computational Linguistics. Amsterdam: Rodopi. [Svartvik 1992] Svartvik, J. (Hrsg.) (1992): Directions in Corpus Linguistics; Proceedings of Nobel Symposium 82 Stockholm, 4-8 August 1991. [Thomas 1996] Thomas, J., Short, M. (Hrsg.) (1996): Using Corpora for Language Research. London: Longman. [Zierl 1997] Zierl, Marco (1997): Entwicklung und Implementierung eines Datenbanksystems zur Speicherung von Textkorpora. Magisterarbeit, Abteilung für Computerlinguistik, Friedrich-Alexander-Universität Erlangen-Nürnberg. (Auch erschienen als erster Band dieser Reihe.) 60
