Donatus und Unicode

Das Problem mit Arboreal, Alvarus und Donatus kann 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.

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 Zeichen U+FFFD ist. 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 <reg>, also zum Beispiel

<reg orig="alṫatiõis">alterationis</reg>,

hätte Arboreal alterationis genommen, wo die Normalisierung keinen Unterschied macht, und es so an Donatus geschickt. Beim jetzigen <reg>, 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 hat Regeln für ij und für die moderne Schreibung von u und v, die er vom State DISP für die Textanzeige übernimmt. 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.

DICT liefert einen leeren String zurück, falls er in einem Wort merkwürdige Zeichen wie ṫ oder õ findet, für die er keine Regel hat. Die Form alṫatiõis würde also, solange sie kein <reg> hat, gar nicht an Donatus weitergeleitet werden. Dieses Verhalten von DICT ist umstritten (Paul ist dafür, Jochen dagegen), aber hier ist es genau das, was man möchte.

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

Eigentlich müsste man Arboreal unter anderem beibringen, dass sich die Struktur von <reg> geändert hat. Aber zurzeit traut sich niemand, etwas im Arboreal-Quellcode zu ändern. Am besten wäre also eine Lösung, bei der das nicht nötig ist.

Vorschlag: 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.

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.