Vor der Tokenisierung sind die Dokumente Zeichenfolgen, die nur gelegentlich
von Absatzendemarkierungen unterbrochen werden.
Die Tokenisierung legt fest, welche Zeichenfolgen in der weiteren Verarbeitung
als eine Einheit betrachtet werden.
Die Einheiten werden Token genannt, was selbst soviel wie Zeichen3.4bedeutet.
Damit soll betont werden, dass sie immer nur als ganzes verarbeitet werden.
Token sind gewöhnlich Wörter oder Zahlen.
Häufig können sie am sie umgebenen Leeraum erkannt werden.
Eine gute Tokenisierung einer längeren Zeichenfolge ist aber
nur in Ausnahmefällen identisch mit einer
einfachen Zerlegung der Eingabe an Leerzeichen.
So bilden z.B. Satzzeichen keine Einheit mit dem vorangehenden Wort.
Sie werden entweder als eigenes Token behandelt oder ganz ignoriert.
Der im KoKS-System verwendete Tokenisierer behält Satzzeichen bei.3.5Weitere Sonderfälle stellen Klammern, Bindestriche und Anführungszeichen
dar.
![[*]](crossref.png)
zeigt einige problematische Textfragmente, die
größtenteils einem ABC Online Interview entnommen wurden,
und die Anzahl der Token.
Abkürzungen am Satzende absorbieren beim KoKS-Tokenisierer den Punkt, der
dann nicht mehr als eigenes Token zur Verfügung steht.3.6
Die Tokenisierung ist im KoKS-System kein eigenständiges Modul, sondern wird zusammen mit dem POS-Tagging (siehe unten) vom IMS TreeTagger ausgeführt. Zwar können die einzelnen Komponenten des IMS TreeTaggers nicht angepasst werden. Aber zwischen ihnen kann die Ein- und Ausgabe manipuliert werden. Im KoKS-Projekt wurde davon Gebrauch gemacht, um das Verhalten bei Punkten zu ändern. Nicht jeder Punkt ist automatisch ein Satzzeichen. Punkte treten in Abkürzungen, Zahlen und Nummerierungen auf. Der IMS Tagger setzt eine Liste von Abkürzungen ein, um Punkte unterschiedlich zu behandeln. Wird nach einem Punkt klein geschrieben, dann wird der Punkt anscheinend grundsätzlich zum vorangehenden Token gezählt.
() diskutieren weitere Probleme der
Tokenisierung (Seite 124-131).
U.a. ist die Situation bei Klitika im Englischen
komplizierter, als
in der Tabelle dargestellt.
Ein Problemfall von mehreren ist das Possessivum im Plural, wie
in ,,the boys' toys``.
Die zweite KoKS-Erweiterung des IMS Taggers betrifft die Orthographie. Ein Teil der Dokumente verwendet keine Umlaute und Eszett. Vor den weiteren Vorverarbeitungsschritten müssen diese Wörter korrigiert werden. Dazu werden Regeln und die Vollformenliste der bereits verarbeiteten Dokumente verwendet.
Mit dem Harry-Potter Korpus stellt sich die neue deutsche Rechtschreibung als weiteres Problem heraus. Die beiden häufigsten betroffenen Wörter ,,dass`` und ,,muss`` sollten eigentlich durch die Umlaut- und Eszettkorrektur angepasst werden. Dies geschieht aber nicht, da die Vollformenliste die Wörter auch in der neuen Schreibung enthält. Mit der Absicht eine korrekte Vollformenliste aufzubauen wurden zuerst die Wörterbücher und Teilkorpora verarbeitet, die keine Umlaut- und Eszettkorrektur erfordern. Dann wurde das Korrekturmodul aktiviert und die restliche Teilkorpora verarbeitet. Da das Ziel die Korrektur der Teilkorpora war, die keine Umlaute und Eszett verwenden, wurde nicht beachtet, dass eines der Wörterbücher die neue Rechtschreibung verwendet.3.7Warum nicht bei der Überprüfung der Ausgabe des Korrekturmoduls aufgefallen ist, dass die häufigen Wörter ,,dass`` und ,,muss`` weiterhin auftreten, lässt sich nicht mehr rekonstruieren.3.8
Analog könnte die im vorangehenden Abschnitt erwähnte Silbentrennung an Zeilenumbrüchen von einem Tokenisierer entfernt werden. Eine Überprüfung, ob die verschmolzenen Wörter bereits im System bekannt sind, könnte verhindern, dass Gedanken- oder Bindestriche, die zufällig am Zeilenende stehen, als Trennstrich bewertet werden. Dies wäre ein Beispiel dafür, dass Whitespace nicht immer Token trennt. Der KoKS-Tokenisierer leistet dies jedoch nicht.
Im Allgemeinen ist die Tokenisierung nicht umkehrbar. Zur Ausgabe von Text bietet es sich an, die Token leerzeichengetrennt aneinander zu hängen und Leerzeichen vor Satzzeichen und schliessenden Klammern und nach öffnenden Klammern zu löschen. Bei nicht typographischen Anführungszeichen ist die Situation schwieriger. Hier kann nur mit größerem Aufwand entschieden werden, welches Leerzeichen unerwünscht ist. Es kann aber nicht garantiert werden, dass das Resultat mit dem ursprünglichen Text identisch ist, da der Tokenisierer nicht entsprechend entworfen wurde. Dies wird an der Behandlung von Whitespace deutlich. Ob und welche Art von Whitespace zwischen zwei Token im ursprünglichen Text steht, wird nicht repräsentiert. Wenn dort irgendetwas ungewöhnliches auftritt, wie z.B. abgerückte Satzzeichen oder doppelte Leerzeichen, dann kann der Text nicht von den Token rekonstruiert werden.
Man könnte argumentieren, dass die Dokumentaufbereitung Abweichungen von den ,,normalen Regeln`` der Typografie korrigieren, also z.B. Satzzeichen an die vorangehenden Wörter heranrücken müsse. Dies würde aber bedeuten, dass die Aufbereitung viele Aufgaben der Tokenisierung übernehmen müsste.
,
siehe Abbildung .