[[PageOutline(1-4,,pullout)]] = 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 [attachment:Alvarus_1509_YHKVZ7B4-fuer-Donatus.xml minimal veränderten Text] an den [http://archimedes.fas.harvard.edu/cgi-bin/donatus Donatus-Webservice] zu schicken (siehe Abschnitt 1), dann einen Kommentar in der [attachment:Alvarus_1509_YHKVZ7B4.morph.xml zurückgeschickten Morphologie-Datei] zu löschen und in Arboreal den [https://it-dev.mpiwg-berlin.mpg.de/tracs/mpdl-project-content/browser/trunk/texts/Alvarus_1509/xml/Alvarus_1509_YHKVZ7B4.xml unveränderten Text] (d.h ohne die Änderung für Donatus) und die [https://it-dev.mpiwg-berlin.mpg.de/tracs/mpdl-project-content/attachment/wiki/donatus-unicode/Alvarus_1509_YHKVZ7B4_neu.morph.xml 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 -Struktur in Archimedes auch die neue -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 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 [wiki:statische-versionen 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 [attachment:Alvarus_1509_YHKVZ7B4-fuer-Donatus.xml angepasste Version] vom Alvarus an den [http://archimedes.fas.harvard.edu/cgi-bin/donatus Donatus-Webservice] geschickt. Einzige Änderung am Alvarus war, dass ich für Donatus zu gemacht habe. Donatus liefert dann zwei XML-Dateien ([attachment:Alvarus_1509_YHKVZ7B4.morph.xml] und [attachment: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. [attachment: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 `` 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 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 , also zum Beispiel alterationis, hätte Arboreal alterationis genommen, wo die Normalisierung keinen Unterschied macht, und es so an Donatus geschickt. Beim jetzigen (siehe [wiki:normalization/5 normalization/5]), also alṫatiõis, nimmt Arboreal alṫatiõis und normalisiert und schickt es. Da es keine Normalisierungsregeln für ṫ und õ gibt (siehe [wiki:normalization/1 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 . Deshalb stellt sich die Frage, wie Arboreal mit 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: {{{ }}} 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 haben.) == 3. Was sollte man an Donatus schicken? Was man wirklich schicken sollte, ist die DICT-normalisierte Form, mit dem DICT-State vom [source:trunk/schema/scripts/MpdlNormalizerLex/MpdlNormalizerLexLA.lex 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 enthält und das Backend korrekt mit 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 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 eine andere Struktur als das von Archimedes hat. Man muss Arboreal zum Beispiel über die docspecs.xml mitteilen können, was es verwenden soll: bei den Element-Inhalt, bei 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 -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 . 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 () und dort die Wortform alṫatiõis ergänzen (), 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.