Beim Tagging wird jedes Token mit Informationen angereicht. Die Art der Informationen kann sehr unterschiedlich sein. Ebenso vielfältig sind die Anwendungen, bei denen Tagging nützlich ist. Einen Einblick bieten (). Die Bezeichnung ,,Tag``, die mit ,,Etikett`` oder ,,Anhängsel`` übersetzt werden kann, deutet darauf hin, dass Tags sich immer auf genau ein Token beziehen. Der Aufbau tokenübergreifender Strukturen, wie z.B. beim Parsing, wird nicht unter Tagging zusammengefasst. Prinzipiell ist es aber möglich, Relationen zwischen Token mit Tags zu annotieren.
Im KoKS-System werden die Wortart (Part of Speech, POS) und das Lemma (die Grundform) jedes Tokens annotiert. Dazu wird der IMS TreeTagger3.9eingesetzt, der die Sprachen Deutsch und Englisch, die im KoKS-Projekt auftreten, unterstützt.3.10
Ein Tagset ist die Menge der Tags, die annotiert werden können.
Der IMS TreeTagger verwendet für die unterstützen Sprachen
unterschiedliche POS-Tagsets.
Für Englisch ist es das Penn-Treebank3.11Tagset, für Deutsch das kleine (s.u.) STTS Tagset.
Informationen zu den Tagsets stehen auf der Webseite zum
IMS TreeTagger (siehe Fußnote ![[*]](crossref.png)
) und zur Verfügung,
die auch im KoKS-Abschlussbericht zusammengefasst sind.
Die Tagsets gehen über die Hauptwortarten deutlich hinaus. Sie umfassen 48 (Penn-Treebank) bzw. 54 (IMS TreeTagger) POS-Tags. Das STTS Tagset ist hierarchisch aufgebaut. Jedes Tag gehört zu einer von elf Hauptwortarten (Nomina, Verben, Artikel, Adjektive usw.) oder ist ein spezielles Tag, z.B. für Satzzeichen. Sieben Hauptwortarten sind weiter unterteilt in Unterwortarten. Beispielsweise sind Nomina gegliedert in Eigennamen und ,,normale Nomina`` (Zitat STTS Tagging Guideline3.12). Die Pronomina sind noch in einer dritten Hierarchieebene unterteilt. Das große STTS Tagset3.13gliedert die Tags noch weiter, um detailiertere Informationen, z.B. zu Kasus, Numerus und Genus bei Nomina, annotieren zu können, wird aber vom IMS TreeTagger nicht benutzt.
Die Lemmatisierung wird häufig nicht als Tagging, sondern nur als Nebenprodukt des POS-Tagging wahrgenommen, da sie von den meisten POS-Taggern optional angeboten wird. Da jedem Token eine Grundform zugewiesen wird, kann man auch hier von Tagging sprechen. Das Tagset umfasst alle Grundformen, die potentiell vom Tagger annotiert werden können. Im Falle des IMS TreeTaggers ist das Tagset eine endliche Menge, da die Grundformen mit der Vollform (also dem Token) nachgeschlagen werden.3.14Eine Analysekomponente, die unbekannte Wörter auf eine Grundform reduzieren kann, wird in der Beschreibung des IMS TreeTaggers nicht erwähnt.
Abbildung
zeigt einen Ausschnitt aus dem
getaggten Beispieldokumentpaar.
An den POS-Tags der Artikel beider Sprachen kann man auch ohne
Kenntnis der Tagsets erkennen, dass sie unterschiedlich sind.
Viele POS-Tagger arbeiten laut ()
in drei Schritten (Seite 109-110):
Tokenisierung (bereits im Abschnitt behandelt),
Ermittlung der Tags, die für jedes einzelne Token in Frage kommen,
und
Auswahl eines Tags je Token mit Hilfe eines Modells der Sprache.
Der IMS TreeTagger benutzt eine Vollformliste, um ein Token auf einen Wahrscheinlichkeitsvektor abzubilden. Das heißt, dass nicht nur aufgelistet wird, welche Tags für das betreffende Token möglich sind, sondern darüber hinaus auch eine Wahrscheinlichkeit für jedes POS-Tag angegeben wird. Ist das Token nicht verzeichnet, dann stehen dem IMS TreeTagger noch andere Methoden zur Verfügung, um zu einem Wahrscheinlichkeitsvektor zu gelangen, siehe () und (). Beispielsweise können aus den letzten Zeichen des unbekannten Wortes Informationen gewonnen werden.
Im nächsten Schritt (dem dritten nach der Liste von ) entscheidet der IMS Tagger welches Tag dem Token tatsächlich zugewiesen wird. Der Tagger nutzt wie viele andere POS-Tagger auch ein Markov Modell, innerhalb dessen mit dem Viterbi Algorithmus die wahrscheinlichste Tagsequenz gefunden wird. Die Übergangswahrscheinlichkeiten zwischen den Zuständen des Modells werden vorab aus einem Trainingskorpus, das manuell annotiert wurde, ermittelt. Hier wendet der IMS TreeTagger einen Decision Tree (Entscheidungsbaum) an, um Zustände zusammenzulegen. Auf diese Weise wird das so genannte Sparse Data Problem umgangen, das darin besteht, dass nicht genug Daten vorhanden sind, um alle Übergangswahrscheinlichkeiten zuverlässig abschätzen zu können. Der Entscheidungsbaum spielt also nur in der Trainingsphase eine Rolle. Das eigentliche Tagging bedient sich dann des Markov Modells, dessen Parameter im Training bestimmt wurden. Auf verschiedene Erweiterungen, die für das Training des deutschen Taggers notwendig waren, da dort das Trainingskorpus kleiner war, geht () im zweiten Artikel ein.
Zum Verständnis der Artikel von sollte man mit verschiedenen bedingten Wahrscheinlichkeiten von Wort- und Tagsequenzen umgehen können. Eine gute Einführung bieten () in einem Kapitel über Markov Modelle (Seite 318-340). Das anschliessende Kapitel über POS-Tagging (Seite 341-381) ist zur Vertiefung sicherlich lesenswert, aber zum Erarbeiten der genannten Artikel über den IMS TreeTagger nicht erforderlich. Weitere Bemerkungen zur Feinabstimmung des Markov Modells finden sich in (). () erläutern am Beispiel ,,will to fight`` das Unvermögen von POS-Taggern, die auf einem Markov Modell basieren, Informationen von Vorgängertoken und Nachfolgertoken gleichermaßen zu nutzen. Dies führe dazu, dass im Beispiel entweder ,,will`` als Verb oder ,,fight`` als Nomen getaggt wird.
Zur Lemmatisierung erwähnt () lediglich, dass beim Aufbau des Vollformlexikons, das die Wahrscheinlichkeitsvektoren der einzelnen POS-Tags aufnimmt, auch die Analyseergebnisse der Morphologiekomponente ,,DMOR`` einflossen (Abschnitt 4 ,,Tests``). Wie genau die Lemmatisierung funktioniert, kann den Quellen nicht entnommen werden. Vermutlich wurden auch die bei der DMOR-Analyse bestimmten Grundformen in das Vollformlexikon aufgenommen, sodass der Tagger in der Lage ist, diese zu annotieren. Die Lemmatisierung spielt in der Darstellung des POS-Taggers keine Rolle, ist also kein Nebenprodukt, sondern eine zusätzliche Leistung des IMS TreeTaggers.3.15
Wichtig für diese Arbeit (und auch für das KoKS-System) ist die Tatsache,
dass der IMS TreeTagger keine Disambiguierung der Lemmata vornimmt.
Kommen für ein Token mehrere Grundformen in Frage, dann annotiert der
Tagger alle Alternativen.
zeigt einige Beispiele aus dem Teilkorpus
EU/1998.
Die POS-Tags sind mit angegeben, da der IMS TreeTagger
scheinbar die Liste der Grundformen auf solche Grundformen
beschränkt, die mit dem für das Token bestimmte POS-Tag vereinbar
sind.
Ein geeignetes Token für einen Test des Verhaltens des Taggers
ist ,,Gefallen``.
In einem Kontext, in dem es als Nomen getaggt
wird aber auch isoliert betrachtet ein Verb sein könnte, d.h. am
Satzanfang steht, müssten auch die Verben ,,fallen`` und ,,gefallen``
annotiert werden, wenn das POS-Tag keine Rolle spielt.
Abbildung zeigt, dass je nach POS-Tag
eine andere Grundformenliste annotiert wird.
In den Testsätzen sind zwei POS-Taggingfehler enthalten, die in der
Abbildung mit Sternchen markiert wird.
Im Deutschen sind viele Verben und Nomen betroffen. Im Englischen treten lexikalische Mehrdeutigkeiten innerhalb einer Wortklasse viel seltener, im gesamten KoKS-Korpus gar nicht, auf. Ein Beispiel wäre ,,saw``: Als Verb kann es die Vergangenheitsform von ,,see`` (sehen) und Präsenz von ,,saw`` (sägen) sein. (Des Weiteren kann es das Nomen ,,saw`` (Säge) sein.)
Schließlich muss bei den annotierten Grundformen beachtet werden,
dass der IMS TreeTagger nicht alle Token, die in einer Eingabe
auftreten können, in seiner Vollformenliste verzeichnet haben kann.
Unbekannte Wörter erhalten die Grundform ,,<unknown>``.
|
zeigt die häufigsten betroffenen
Token im KoKS-Korpus.
Wichtig für die Andwendungen in KoKS und in dieser Arbeit
ist auch die Fehlerrate des Taggers.
Der getaggte Text in Abbildung offenbart
bereits, dass der Tagger gelegentlich Fehler macht.
Laut () erreicht der POS-Tagger für das Deutsche
97,5 % und für das Englische 96,8 % Korrektheit.
Da diese Zahlen auf einzelne Token bezogen sind, bedeutet dies
trotz der hohen Korrektheit, dass sehr viele Sätze Fehler enthalten.
Für das KoKS-System ist die Fehlerrate niedrig genug.
Tag-Sequenzen mit einer Länge von bis zu sechs Token sollten häufig
korrekt sein, eine
zufällige Verteilung der Fehler vorausgesetzt.
Bei einer Translation Memory Anwendung, die auch POS-Tags für das
Matching ganzer Sätze nutzt, können die Fehler jedoch Auswirkungen
haben.
Das wird im Kapitel zu berücksichtigen sein.
.
