Autor: Torsten Hiltmann

Die Erstellung digitaler Editionen ist ein zentraler Arbeitsbereich der Digitalen Geschichtswissenschaften. Die bisher zur Verfügung stehenden Werkzeuge und Arbeitsumgebungen, die ja nicht nur uns Historiker sondern alle textbasierten Wissenschaften betreffen, bleiben dabei aber häufig hinter dem zurück, was man sich hierfür wünscht oder vorstellen kann. Dies gilt auch für das automatische Kollationieren. Doch wie sich auf dem „Code and Collation“ Workshop  gezeigt hat, der vom 2. bis 4. November in Amsterdam stattfand, gibt es hier deutliche Fortschritte zu verzeichnen.

Das Problem – analog

Wenn man an der Edition eines Textes arbeitet, der gleich in mehreren Textzeugnissen überliefert ist, stellt sich immer erst einmal die Frage, welche der Überlieferungen man dem zu erstellenden Editionstext zugrunde legen soll. Mit den Möglichkeiten der digitalen Edition hat sich dieses Problem deutlich vereinfacht. So kann man bei einer digitalen Edition, z.B. unter Verwendung von XML/TEI, mit irgendeinem der Texte beginnen und die anderen Textzeugnisse dann sukzessive einarbeiten. Die Reihenfolge spielt keine Rolle mehr, da bei digitalen Editionen der Prozess der Erstellung des Editionstextes vom Prozess der späteren Darstellung dieses Textes getrennt ist. Erst bei der Veröffentlichung muss man sich tatsächlich entscheiden, welchem der Textzeugnisse man als Basistext den Vorzug gibt, ob man eine synoptische Darstellung präferiert (z.B. mit der Versioning machine), oder ob man dem Leser selbst die Entscheidung überlässt.

Die Probleme – digital

Also alles ganz einfach? Natürlich nicht. Denn wenn man einmal versucht hat – so wie wir in unserem Editionsprojekten zum Obsequientraktat – 36 verschiedene, teils stark voneinander abweichende Textzeugnisse samt Transpositionen, Kontaminationen, Textverlusten usw. in eine Datei zu bringen, der weiß das. Durch die Baumstruktur des XML-Formats geht rasch der Überblick verloren.

Die Alternative wäre daher, die Texte zunächst einmal unabhängig voneinander zu transkribieren und gegebenenfalls bereits zu annotieren. Das heißt, die Textzeugnisse zunächst einmal einzeln vorzubereiten und erst in einem zweiten Schritt im Rahmen einer automatischen (bzw. semi-automatischen) Kollationierung zusammenzuführen.

Was einfach klingt, ist es wie immer nicht. Zwei wesentliche Probleme stellen sich:

1. Die Kollationierbarkeit der Texte: Die bisher zur Verfügung stehenden Hilfsmittel können nur schwer mit stark abweichenden Graphien umgehen und lassen sich kaum dem eigenen Material anpassen.
2. Das XML-Format Problem: Will man darüber hinaus statt einfachem plain text bereits annotierte XML Dateien miteinander kollationieren, stößt man rasch an die Grenzen des Möglichen. Denn die Regel der Wohlgeformtheit und die Notwendigkeit der Segmentierung des Textes im Rahmen der Kollationierung schienen einander auszuschließen.

Bis vor kurzem funktionierte das Ganze für unser Projekt auch entsprechend leidlich, stand uns doch nur die Out of the Box – Lösung von CollateX hier zur Verfügung. Aufgrund des wenig zufriedenstellenden Ergebnisses waren wir gezwungen, die Texte erst einmal mit Hilfe einer größeren Konkordanzliste für abweichende Graphien auf eine einheitliche Graphie zu bringen und erst diese dann mit Hilfe von CollateX zu kollationieren. Das noch immer nicht ganz zufriedenstelle Output haben wir daraufhin in eine Excel-Tabelle übertragen und dort weiterbearbeitet, bis hin zum Abgleich mit den jeweiligen Textvorlagen und der Annotierung.

CollateX in Python individuell den eigenen Projektanforderungen anpassen

Mittlerweile aber wurde die Leistungsfähigkeit von CollateX weiter ausgebaut. Zudem gibt es die Möglichkeit, den in Python geschriebenen Code selbst zu ändern und an die eigenen Anforderungen anzupassen. Wie das geht, wurde auf dem DiXiT-Workshop vom Huygens Institut in Amsterdam vorgestellt. Die Unterlagen für den Workshop mit ausführlichen Anleitungen sind auf GitHub zugänglich.

Die einzelnen Arbeitsschritte

Um den Code seinen eigenen Anforderungen anzupassen, muss man zunächst einmal wissen, wie dieser funktioniert. Also, wie sieht der Kollationierungsprozess konkret aus?

Das Ganze läuft in drei wesentlichen Etappen ab: Tokenisierung, Normalisierung, Kollationierung.

Tokenisierung: nachdem das einzelne Textzeugnis eingelesen wurde, wird der Text in einzelne Abschnitte unterteilt. In der Grundeinstellung geschieht dies nach Wörtern, d.h. Abfolgen von Buchstaben und Zahlen, auf die ein Leerzeichen folgt. Durch die Möglichkeit, direkt mit dem Python Code von CollateX zu arbeiten, kann man diese als Regular expressions (REGEX) formulierte Regel aber umschreiben. So kann man z.B. bei französischen Texten selbst entscheiden, wie man mit Apostrophen umgehen möchte, ob z.B. “d’armes” als ein Token oder als zwei Token behandelt werden soll, also “d’armes” oder “d'” und “armes”. Oder man kann entscheiden, ob Satzzeichen eigene Token darstellen sollen oder nicht, um diese dann entsprechend bei der Kollationierung berücksichtigen zu können.

Normalisierung: hier wird der Text, wie der Name schon sagt, normalisiert. Nur eben nicht, wie bei unserem Workaround, der zu kollationierende Text. Vielmehr werden die einzelnen Token jeweils durch ein Dictionary ersetzt, also eine Verbindung von zwei Werten, die als Key die ursprüngliche Schreibweise des jeweiligen Wortes enthält (im Script der t-Wert) und als Wert die normalisierte Fassung des jeweiligen Wortes (im Script der n-Wert). Für die Kollationierung wird dann nur noch der n-Wert herangezogen, ausgeben läßt sich aber auch der damit verbundene t-Wert. Und auch hier kann man die Regeln für die Normalisierung der Wörter und damit zur Erstellung der n-Werte mit REGEX anpassen. So lassen sich z.B. bestimmte Buchstabenfolgen, deren unterschiedliche Schreibung während der Kollationierung nicht berücksichtigt werden soll, gleichsetzen oder Kürzungen auflösen, wenn diese bei der Kollationierung keine Rolle spielen sollen. Im Rahmen des Workshops haben wir für das Material des Obsequientraktates beispielsweise ein Script erstellt, welches die Wörter im n-Wert aufgrund unserer Konkordanz für abweiche Graphien mit einer vereinheitlichten Schreibung ersetzt, ohne dass dies auf den eigentlichen Textbestand Einfluss hätte (den entsprechenden Code werden wir ebenfalls auf GitHub zur Verfügung stellen).

Kollationierung: aufgrund der n-Werte werden die verschiedenen Textzeugnisse dann verglichen und aneinander ausgerichtet (aligned) bzw. gemappt. Denn zumindest der Dekker-Algorithmus ist auch in der Lage, mit Texttranspositionen umzugehen. Wie das alles genau funktioniert, ist etwas zu komplex, um es hier darzustellen. Grob gesagt aber läuft das so ab, dass die Maschine die Texte linear Token für Token durchgeht und nach Übereinstimmungen sucht. Passen die Token der beiden Textzeugnisse zusammen, werden diese gematcht, dann wird nach dem nächsten Match gesucht (im Idealfall das nächste Wort), usw. Kann keine Entsprechung gefunden werden, bleibt der Platz im anderen Text leer und es wird eine Auslassung angenommen, bis es wieder passt.

Bisher wurden dabei immer nur die gesamten Token abgeglichen, was bei abweichenden Graphien zu stark verschobenen Ergebnissen führte. Schließlich wurden ja immer nur eindeutige Matches akzeptiert. Doch bietet CollateX jetzt ein neues Feature: Near-Matching. Mit diesem Feature (als Argument zur collate Funktion) wird nicht mehr nur die Ähnlichkeit der Texte berechnet, sondern auch der einzelnen Token. Das heißt, die Maschine kann beim Abgleich der Token erkennen, dass “doivent” und “doibvent” das gleiche Wort mit einer leicht veränderten Orthographie wiedergeben und behandelt diese entsprechend anders als zwei völlig voneinander abweichende Token wie z.B. “doivent” und “d’armes”. Das bringt natürlich einen erheblichen Rechenaufwand mit sich. Zudem kann man die ausgebenen Texte bisher noch nicht segmentieren, also die in den verschiedenen Kopien identischen Textteile zu größeren Segmenten zusammenfassen. Dennoch funktioniert das Feature hervorragend. Ein wesentliches Problem unseres Editionsvorhabens, das uns zuvor viel Arbeit gekostet hat, wäre damit gelöst.

Das XML-Problem

Bleibt noch die Frage der Kollationierung von Texten, die bereits annotiert als XML-Dateien vorliegen. CollateX und insbesondere David J. Birnbaum arbeiten daran, haben aber noch keine fertige Lösung für das Problem. Schließlich ist das Problem doch komplexer, geht es doch nicht nur um die einfache Kollationierung der Texte und ihrer Tags sondern auch um eine unterschiedliche Behandlung der einzelnen Tags. So sollte der Prozess unterscheiden können zwischen Elementen, die auch bei der Kollationierung eine Rolle spielen sollen (z.B. Tags zum Layout wie Zeilen- und Seitenwechsel, was besonders für literarische Texte interessant sein kann, aber auch Korrekturen oder Kürzungen) und solchen, die das Programm einfach nur durchschleifen soll.

Eine mögliche Lösung für das XML-Problem könnte hier aber auch von anderer Seite kommen. Nach eigener Aussage verfügt das schwedischen eXistdb-Projekt über eine funktionierende Lösung, die bisher aber noch nicht released wurde. Bei Bedarf kann man aber sicher schon einmal anfragen.

Die ausführlichen Unterlagen des im Rahmen des EU-finanzierten DiXit Projektes von Ellie Bleeker und Elena Spadini organisierten Workshops samt entsprechender Anleitungen und Code-Beispiele sind wie gesagt auf GitHub verfügbar (hier).

Das alles ersetzt natürlich noch lange nicht ein entsprechendes Working Environment für digitale Texteditionen, welches den Workflow bis hin zu einer Visualisierung der Ergebnisse intutitv und adaptiv abbildet, so wie man sich das wünschen würde. Aber es ist doch ein weiteres, wesentliches Puzzleteil hin zu einer leistungsfähigeren und adaptiveren digitalen Editorik.