Donatus und Unicode

Es gibt ein Problem mit den Text-Kodierungen, wenn man einen Echo-Schema-konformen Text von Arboreal aus an Donatus schickt: Arboreal erhält zwar das Ergebnis von Donatus, bricht den Vorgang aber ab mit einer Fehlermeldung "UTF8-Fehler". Man kann das Ergebnis dann in Arboreal weder anschauen noch abspeichern.

Ein kurzfristiger Workaround ist, den minimal veränderten Text​ an den ​Donatus-Webservice zu schicken (siehe Abschnitt 1), dann einen Kommentar in der zurückgeschickten Morphologie-Datei​ zu löschen und in Arboreal den ​unveränderten Text (d.h ohne die Änderung für Donatus) und die ​Morphologie-Datei ohne den Kommentar zu verwenden. Dabei verliert man alle Wortformen im Text, die regularisiert werden müssen, unabhängig davon, ob sie bereits regularisiert wurden oder nicht. In Texten wie dem Alvarus ist das ein beträchtlicher Anteil.

Mittelfristig kann das Problem durch einen Service gelöst werden, der bei einem XML-Text die Wörter im Text durch die normalisierten Formen ersetzt. Diese Textversion kann Arboreal dann zu Donatus schicken. Dann sind auch die (normalisierten) Wortformen der regularisierungsbedürftigen Wortformen in der Morphologie-Datei enthalten. Damit Arboreal solche Wortformen dann auch tatsächlich richtig zuordnen kann, muss ein zweiter Service diese Wortformen in der Morphologie-Datei ergänzen.

Die langfristig beste Lösung wäre, dass Arboreal neben der <expan>-Struktur in Archimedes auch die neue <reg>-Struktur versteht, und Arboreal sollte bei Echo-Schema-konformen Texten die neue Normalisierung verwenden. Für diese Lösung muss allerdings der Sourcecode von Arboreal geändert werden.

Treffen 2011-08-04: Wir wollen den Service, der einen normalisierten Text erstellt und dabei die XML-Struktur beibehält. Beim normalisierten Text wird DISP verwendet, und die <reg> werden in dieser Textversion entfernt. Peter: Dann kann man den originalen Text in Arboreal als slave text laden. (Dadurch wird der zweite Service überflüssig.) Jochen: Derselbe Service kann dann auch für unsere statischen Textversionen verwendet werden.

1. Problembeschreibung bei Alvarus

Das Problem ist offenbar der gleiche Fehler wie damals beim Benedetti. Zur ursprünglichen Problembeschreibung für Benedetti siehe Abschnitt 5. Ich habe diesmal nur den Donatus-Webservice ausprobiert und es nicht in Arboreal nachvollzogen. Und zwar habe ich eine angepasste Version​ vom Alvarus an den ​Donatus-Webservice geschickt. Einzige Änderung am Alvarus war, dass ich für Donatus <text xml:lang="la"> zu <text lang="la"> gemacht habe.

Donatus liefert dann zwei XML-Dateien (Alvarus_1509_YHKVZ7B4.morph.xml​ und Alvarus_1509_YHKVZ7B4.unparsed.xml​) und auf der Ergebnisseite selbst einen kurzen Überblick, was es getan hat:

donatus (2.9) running on archimedes.fas.harvard.edu at Sat Jul 30 07:57:07 2011
...
Used Cruncher backend for 'la'.
...
1000 0 0.00 al?atiõis 0
...

Als Originalwort kommt nur alṫatiõis = alterationis in Frage.

Alvarus_1509_YHKVZ7B4.morph.xml​ enthält denselben Text als Kommentar. Wenn man diese Datei zum Beispiel mit BBEdit öffnet, kommt eine Fehlermeldung "kein korrektes UTF-8", weil dieser Teil mit ISO 8859-1 statt UTF-8 kodiert ist (siehe Abschnitt 5), und die Zeile von oben wird angezeigt als

1000 0 0.00 al?ati�is 0

wobei � das Ersatz-Zeichen U+FFFD ist. (Da der Rest der Datei ASCII und damit auch ISO-8859 und UTF-8 ist, kann man auch sagen, dass Donatus eine ISO-8859-1-Datei zurückliefert, trotz der expliziten Angabe <?xml version="1.0" encoding="UTF-8"?> in der Datei.)

Arboreal wird wohl über die gleiche Stelle stolpern, löst das Problem aber nicht so nonchalant wie BBEdit.

2. Was schickt Arboreal an Donatus?

Soweit ich weiß, fügt Arboreal um jedes Wort ein <w> ein. Das macht aber wohl keinen großen Unterschied für Donatus. Arboreal ersetzt außerdem jedes Wort durch eine normalisierte Form. Beim früheren <expan>, also zum Beispiel

<expan abbr="alṫatiõis">alterationis</expan>,

hätte Arboreal alterationis genommen, wo die Normalisierung keinen Unterschied macht, und es so an Donatus geschickt. Beim jetzigen <reg> (siehe normalization/5), also

<reg norm="alterationis" type="simple context">alṫatiõis</reg>,

nimmt Arboreal alṫatiõis und normalisiert und schickt es. Da es keine Normalisierungsregeln für ṫ und õ gibt (siehe normalization/1), verändert sich das Wort nicht. Zum Ergebnis siehe Abschnitt 1. (Dieses Wort kommt im Alvarus nur ein einziges Mal vor und hat noch kein <reg>. Deshalb stellt sich die Frage, wie Arboreal mit <reg> umgeht, hier noch gar nicht. Es kommt aber in Abschnitt 4 wieder vor.)

Bei ASCII-Zeichen verändert die Arboreal-Normalisierung nur

• j --> i
• v --> u
• q; --> que

Das Wort "ut" kommt im Alvarus zum Beispiel als vt und Ut vor, aber nicht als ut. Der Donatus-Webservice kann es aber auch ohne Normalisierung korrekt analysieren:

<lemma form="ut" lang="la">
  <variant form="Ut"><analysis desc="N"/></variant>
  <variant form="ut"><analysis desc="N"/></variant>
</lemma>

Mit j statt i wird es ähnlich sein, aber j kommt im ganzen Alvarus nicht vor. Man kann also davon ausgehen, dass bei ASCII-Wörtern die Arboreal-Normalisierung überflüssig ist. (Ich gehe davon aus, dass alle "q;" im Text ein <reg> haben.)

3. Was sollte man an Donatus schicken?

Was man wirklich schicken sollte, ist die DICT-normalisierte Form, mit dem DICT-State vom Lex für Latein​. (Oder sogar einen State, der genauer an Texte dieser Zeit angepasst ist, vergleichbar mit RENAISSANCE_DICT für Benedetti. Das kann man aber erst genauer sagen, wenn Alvarus alle nötigen <reg> enthält und das Backend korrekt mit <reg> umgeht.)

DICT verwendet dieselben Regeln für ij und für die moderne Schreibung von u und v wie der State DISP für die Textanzeige. Ich denke nicht, dass der Unterschied zur Normalisierung in Arboreal einen Unterschied für Donatus macht, siehe Abschnitt 2. Ansonsten liefert DICT reines ASCII zurück, das Arboreal nicht weiter normalisieren würde.

Das Lex erwartet als input immer die regularisierte Form. Auf nicht-regularisierte Formen reagieren die States unterschiedlich. DICT liefert einen leeren String zurück, falls in einem Wort merkwürdige Zeichen wie ṫ oder õ enthalten sind, für die es keine Regel gibt. Die Form alṫatiõis würde also, solange sie kein <reg> hat, gar nicht an Donatus weitergeleitet werden.

Man will nämlich gar nicht irgendwelche Kodierungen konvertieren, weil das das eigentliche Problem nicht löst. Das, was man schicken möchte, ist (zumindest für Latein, nicht z.B. für Deutsch!) bereits ASCII. Deshalb ist eine Box zwischen Arboreal und Donatus, die ich am Donnerstag im Meeting vorgeschlagen habe, doch keine gute Lösung.

4. Lösungsvorschlag

Ein kurzfristiger Workaround ist ganz oben beschrieben.

langfristig

Eigentlich müsste man Arboreal unter anderem beibringen, dass <reg> eine andere Struktur als das <expan> von Archimedes hat. Man muss Arboreal zum Beispiel über die docspecs.xml mitteilen können, was es verwenden soll: bei <expan> den Element-Inhalt, bei <reg> das @norm-Attribut (falls vorhanden; sonst auch den Element-Inhalt).

Arboreal sollte außerdem zumindest bei Echo-Schema-konformen Texten die neue Normalisierung verwenden.

Aber zurzeit traut sich niemand, etwas im Arboreal-Quellcode zu ändern. Im folgenden beschreibe ich eine Lösung, bei der das nicht nötig ist.

mittelfristig

Vorschlag, Teil 1: Ein Service, der bei einem XML-Text den Text auf Knopfdruck durch die DICT-normalisierte Form ersetzt. Diesen Text kann Arboreal dann zu Donatus schicken, und danach kann man diese Textversion entsorgen.

Das ist zwar für die Arbeit mit Arboreal immer noch eher eine Symptombekämpfung als eine echte Lösung, aber dafür ist dieser Service auch unabhängig von Arboreal sinnvoll. Man kann diesen Service noch so erweitern, dass man auf Knopfdruck auch den regularisierten Text bekommen kann, sowie das Ergebnis jedes beliebigen Lex-States für diese Sprache. Die XML-Struktur und die IDs werden dabei beibehalten.

Die Versatzstücke für diesen Service existieren bereits im Backend: Worterkennung, Regularisierung, Lex anwenden, zusammenfügen zu einer Textseite.

Vielleicht sollte DICT dann bei problematischen Wörtern nicht einen leeren String, sondern besser ein Sternchen * zurückliefern, oder das Originalwort in eckigen Klammern, also zum Beipsiel [alṫatiõis]. Das müsste dann aber vom Backend abgefangen werden, so dass es nicht an Donatus geschickt wird. Und zurzeit tilgt DICT Zeilenumbrüche, d.h. aus "di- uerſa" wird nicht "di- versa", sondern "diversa". Aber für eine so entstandene Textversion wäre eine Verschiebung des Zeilenumbruchs hinter das Wort wohl gut genug. Alternative wäre ein neuer State DONATUS, der recht einfach zu erstellen wäre.

(Alternativ könnte man (1) Arboreal die Wörter des Textes extrahieren lassen, ohne dass dabei die schon vorhandenen Regularisierungen berücksichtigt werden; (2) das entstandene XML mit dem Regularisierungsskript neu regularisieren, beachte dabei die Schreibweise quã-titate ohne Leerzeichen für Zeilenumbrüche; (3) die <reg>-tags durch den Inhalt des @norm-Attributs ersetzen und (4) es dann mit Hilfe eines simplen Java-Wrappers mit dem Lex normalisieren. Die nicht-automatisierbaren Regularisierungen, zum Beispiel Tippfehlerkorrekturen, werden allerdings auch mit dieser Methode nicht übernommen.)

Die so erhaltene Morphologie-Datei enthält auch die (normalisierten) Wortformen der regularisierungsbedürftigen Wortformen. Hypothetisches Beispiel: Falls es im Text zum Lemma "alteratio" nur die Wortform "alṫatiõis" gäbe, wäre das Lemma trotzdem enthalten. (In Wirklichkeit enthält Alvarus aber auch unverkürzte Formen wie alterationis oder alteratione.) Allerdings würde Arboreal von "alṫatiõis" nicht zum Lemma-Eintrag kommen, siehe diese Wortform in <s xml:id="N2CAEE">.

Damit Arboreal solche Wortformen dann auch tatsächlich richtig zuordnen kann, muss ein zweiter Service diese Wortformen in der Morphologie-Datei ergänzen. Der erste Service hat bereits eine Liste aller originalen Wortformen mit ihren normalisierten Gegenstücken gemacht, also zum Beispiel

alṫatiõis --> alterationis

Vorschlag, Teil 2: Der zweite Service muss dann in der Morphologie-Datei das Lemma von alterationis finden (<lemma form="alteratio" lang="la">) und dort die Wortform alṫatiõis ergänzen (<variant form="alṫatiõis"></variant>), indem es den Eintrag der normalisierten Form alterationis kopiert.

5. Ursprüngliche Problembeschreibung

[meine Email vom 9.6.2010; nur noch für die Diskussion von ISO 8859-1 relevant]

Zur Fehlermeldung (in etwa) "invalid XML character 173a64 was found in the comment (line 74)" in Arboreal beim Benedetti mit der neuen reg-Struktur: Es ist ein wohl ein Zeichenkodierungsproblem mit dem "Cruncher backend", das Donatus für Latein verwendet.

Der Cruncher schreibt am Anfang der Datei einen Text als Kommentar, und dieser Text ist wohl ISO-8859-kodiert. Mein Verdacht ist, dass er über die Wortform "cõtinui" stolpert, also über einen Buchstaben, der zwar in ISO 8859-1 vorhanden ist, aber einen anderen Codepoint hat als in Unicode. Zeichen, die es gar nicht in ISO 8859-1 gibt, werden dagegen vermutlich einfach durch ein ? ersetzt: prę durch pr? und ꝗcquid durch ?cquid.

Donatus erstellt jedenfalls brav die Morphologie-Liste und ignoriert dabei alle Formen, die es nicht versteht. Dazu gehören Formen wie "prę" und "cõtinui" und "ꝗcquid". Das ist zwar nicht das, was wir wollen, aber es ist immerhin auch nicht Unsinn.

Man muss also entweder dem Cruncher UTF-8 beibringen, oder Donatus es in UTF-8 konvertieren lassen, oder Arboreal muss den Fehler im Kommentar ignorieren. Oder noch einfacher: Arboreal sendet nicht die Originalformen, sondern die regularisierten Formen an Donatus. Das wäre sowieso sinnvoller. Allerdings kann man ja nicht immer garantieren, dass alle Formen regularisiert sind.

Etwas Zahlenakrobatik: Den Unicode-Codepoint 173A64 gibt es nicht, Unicode geht nur bs 10FFFF. Aber jedenfalls: 173A64 ist

00010111 00111010 01100100.

In UTF-8 wäre das

11110101 10110011 10101001 10100100

Und da haben wir wohl den Schuldigen: 11110101 ist õ. Wie Arboreal allerdings aus den restlichen Bytes gerade diesen Codepoint macht, ist mir völlig unklar. Das "õtin" aus cõtinui wäre in ISO 8859-1:

11110101 01110100 01101001 01101110

BBedit zum Beispiel stellt fest, dass das keine legale UTF8-Bytefolge ist, weil die Bytes 2 bis 4 nicht mit 10 anfangen, und stellt es als �tin dar. Arboreal dagegen macht wohl noch irgendwelchen wirren Berechnungen. Aber das ist reine Spekulation.