Datenbank

Die alignten Dokumente werden in einer Datenbank abgelegt. Dabei wird jedes Tupel aus Token, POS-Tag, Grundform und Sprache nur einmal gespeichert und mit einer eindeutigen Zahl, der Token-ID, versehen, die zur Identifikation des Tupels dient. Der Dokumentinhalt reduziert sich damit auf eine Folge von Token-IDs, die in der Datenbank als funktionale Relation zwischen den natürlichen Zahlen und den Token-IDs realisiert ist. Als Tabelle dargestellt ergibt das die zwei Spalten Token-Nummer und Token-ID.

Das Alignment wird in der Datenbank repräsentiert, indem zu jeder Token-Nummer vermerkt wird, zu welchem Segment das Token gehört. Es werden gleiche Segmentnummern für die beiden Segmente eines Alignment-Beads verwendet. Entsprechend ist auch eine Satznummer vermerkt. (Gemeint ist die sprachliche Einheit Satz, nicht ein Datensatz.) Zu jedem Satz wird die Herkunft (Quelle, Autor und Jahr) und nochmal die Sprache gespeichert. Die Sprache wird aufgelistet, um ohne Rückgriff auf die Tokentupel Segmente einer bestimmten Sprache abfragen zu können. Eventuell war auch vorgesehen, dass Tokensprache und Satzsprache abweichen können. Die KoKS-Vorverarbeitung unterstützt dies jedoch nicht. Warum diese Informationen gerade bei Sätzen und nicht bei größeren Einheiten wie Absäztzen oder Dokumenten vermerkt werden, ist nicht (mehr) bekannt.

Einen weiteren Teil der Datenbank nehmen Indizes ein. Indizes auf Zeilenwerte einzelner Spalten und Kombinationen von Spalten werden von der Datenbanksoftware angeboten und automatisch und transparent bei SQL-Anfragen^3.26eingesetzt. Darüber hinaus wurden spezielle Indizes aufgebaut, die eigene Tabellen erforden, beispielsweise eine Auflistung aller Segmentnummern sortiert nach Satzanfängen. Im nächsten Abschnitt werden diese Indizes vorgestellt.

Behandlung der Grundformen

Das Tokentupel enthält die Grundform so, wie sie der Tagger annotiert. Bei manchen Token ist dies nicht eine einzelne Grundform, sondern eine Liste aus mehreren, durch senkrechte Striche getrennte Grundformen. Tabelle im Abschnitt zeigt ausgewählte Beispiele. Wenn nach Stellen im Korpus gesucht wird, die Token mit einer vorgegebenen Grundform enthalten, werden diese Grundformenlisten vom KoKS-System nicht berücksichtigt. Dies hat sowohl Vor- als auch Nachteile. Zum einen werden viele relevante Stellen mit Token, in deren Grundformenliste die gesuchte Grundform erscheint, nicht gefunden. Zum anderen werden falsche Treffer vermieden, die auftrete würden, wenn in einer Grundformenliste, die die gesuchte Grundform enthält, eine andere Grundform zutrifft. Im KoKS-System wurde also Wert darauf gelegt, dass möglichst viele Fundstellen korrekt sind, die Precision also hoch ist. Das geht auf Kosten des Recalls, also des Anteils der gefundenen (und korrekten) Fundstellen an den im Korpus tatsächlich vorhandenen, relevanten Stellen.

Im Rahmen dieser Magisterarbeit wurde eine zusätzliche Tabelle in der Datenbank angelegt, die die einzelnen Grundformen der Grundformenlisten verzeichnet und auf die jeweiligen Tokentupel verweist.^3.27Es wurde ein Modul implementiert, dass zu einer Grundform alle infrage kommenden Token-Nummern ermittelt und darauf basierend verschiendene Suchmöglichkeiten im Korpus anbietet. Beispielsweise besteht die Möglichkeit, die Vollform in die Suche mit einzubeziehen. Dies kann sinnvoll sein, wenn die Grundform im System unbekannt ist. Der IMS TreeTagger annotiert als Grundform ,,<unknown>``, wenn ein Token nicht in seinem Vollformlexikon enthalten ist. Da es in dieser Arbeit darum geht, das Korpus als Informationsquelle für die Übersetzung zu nutzen und die Nützlichkeit abzuschätzen, ist ein hoher Recall wichtiger ist als gute Precision.

Eine alternative Lösung des Problems wäre die Disambiguierung der Grundformen. Denkbar wäre, einfache Regeln für die häufigsten Token von Hand zu erstellen. Beispielweise könnte man bei ,,führen`` heranziehen, ob ,,nach`` oder ,,zu`` in der Nähe auftritt. Wenn nur die häufigsten Token behandelt werden, ist der Aufwand nicht allzu hoch und trotzdem eine deutlich Verbesserung der Lemmatisierung möglich. Zu beachten ist, dass Regeln nicht jeden Fall, der in von Menschen verfassten Texten auftritt, berücksichtigen können. Eine Disambiguierung wird Fehler einführen, sodass im Vergleich zu der KoKS-Lösung die Precision der Anfrageergebnisse und im Vergleich zur neuen Lösung der Recall sinkt.

Detailprobleme

Im KoKS-Projekt konnte nicht jedes Detail der Implementation perfekt umgesetzt werden. Dafür fehlte die notwendige Zeit. So verwendet die SQL-Anfragesprache der Datenbank Anführungszeichen, um Werte, die selbst Zeichenfolgen sind, zu Kennzeichnen. In der KoKS-Implementation werden alle Anführungszeichen einfach in ein Nummernzeichen (#) verwandelt. Die bessere Lösung wäre gewesen, in der SQL-Dokumentation nachzuschauen, wie Anführungszeichen geschützt werden müssen, und eine entsprechende Funktion zu implementieren. In den im Rahmen dieser Magisterarbeit erstellten, neuen Softwarekomponenten wurde dies umgesetzt, da im Harry-Potter Korpus oft wörtlich Rede vorkommt. Die Umstellung sämtlicher Komponenten wurde aber aus Zeitmangel aufgegeben.

Die unvollständige Umstellung führt leider zu neuen Problemen. Eine Anfrage, die Anführungszeichen enthält, findet im Korpus keine Treffer. Erst eine Umstellung der gesamten Korpusvorverarbeitung würde hier Abhilfe schaffen. In dieser Arbeit tritt das Problem nicht auf, da für die Anfragen nur Sätze aus dem Korpus selbst verwendet werden.

Fußnoten

...SQLSQL-Anfragen^3.26

SQL ist eine Sprache, in der eine Anwendung Fragen und Anweisungen an die Datenbanksoftware richtet.

... verweist.^3.27

Im konkreten Datenbankdesign sind die Tokentupel auf mehrere Tabellen (Token, Grundformen, POS-Tagset) aufgeteilt. Der Verweis auf die Grundformenliste erfolgt über die Grundform-ID.