Regularisierung

Die Regularisierung eines Textes mit Hilfe von <reg> ist wohlbekannt. Seit Archimedes wurde insbesondere die Struktur von <reg> umgestellt von <reg orig="Original">Korrektur</reg> zu <reg norm="Korrektur">Original</reg>, also zu <reg> als einer Annotation des Originaltextes.

Neu ist eine weitere Funktion von <reg>: Wenn wir im Rohtext Informationen haben, die wir nicht darstellen können, kommen diese in ein neues Attribut namens "faithful". Beispiele sind griechische Ligaturen und chinesische Zeichenvarianten, die nicht in Unicode sind. Die Idee, solche Zeichenvarianten in ein Attribut von <reg> zu schieben, stammt von Robert.

Viele Beispiele für Regularisierungen sind in dieser Tabelle zu sehen.

Grundgedanken

Ziele:

• Wissen über den einzelnen Text und einzelne Textstellen muss in <reg>
• Halte die Anzahl der benötigten <reg> möglichst klein.
• Idealerweise wird gerade so viel regularisiert, dass die Normalisierung aus dem regularisierten Text die in der jeweiligen Sprache oder Sprachschicht gewünschte Standardschreibweise ergibt.
• Informationen aus dem Rohtext, die wir zurzeit nicht nutzen können, sollen erhalten bleiben. Insbesondere wollen wir endlich Griechisch von Rohtext in XML umwandeln können, ohne Informationen wegwerfen zu müssen.
• Sobald wir solche Informationen anzeigen können, soll dies mit dem unveränderten XML möglich sein.
• Die Suche soll funktionieren.
• Der regularisierte Text soll problemlos anzeigbar sein.
• Die Regularisierung soll robust genug für alle von uns verwendeten Sprachen sein.
• Die Hemmschwelle für Texte aus anderen Quellen soll niedrig sein: Auch Texte ohne <reg> sollen anzeigbar sein.
• korrekt geschriebene Texte in modernen Sprachen sollten im Idealfall gar keine Regularisierungen benötigen

Das faithful-Attribut

Das faithful-Attribut nimmt, wie gesagt, Informationen aus dem Rohtext auf, die wir zurzeit noch nicht richtig darstellen können. Es gibt keine Verpflichtung, in <reg> ein faithful-Attribut anzugeben. (Wenn es kein faithful-Attribut gibt, muss es aber, wie bisher auch, das norm-Attribut geben.) In vielen Texten wird es auch keine Notwendigkeit geben, es zu verwenden. Aber häufig enthalten unsere Rohtexte Informationen, die wir nicht sinnvoll in Unicode kodieren können. Zum Beispiel enthält Pappus 1660 aus Work Order 1 diverse griechische Ligaturen und Abbreviaturen, also Formen wie {πρ}ός (im Text steht meistens die Form {πρ}ὸς). Wir können es zurzeit nicht leisten, die Transkription des griechischen Textes auf Korrektheit zu überprüfen, deshalb verschieben wir die hier erkannte πρ-Ligatur in das faithful-Attribut:

<reg faithful="{πρ}ός">πρός</reg>

Wahrscheinlich werden wir in absehbarer Zukunft keinen Mechanismus für {πρ} anbieten, so dass im faithful-Modus einfach {πρ}ός angezeigt wird. Die Textdarstellung funktioniert auch ohne einen geeigneten Mechanismus, und der Mechanismus kann jederzeit nachgeliefert werden.

Die Informationen über Ligaturen sind insbesondere deshalb enthalten, weil wir eventuelle Transkriptionsfehler der Chinesen korrigieren können wollen. Ein mögliches Szenario: Ein Forscher findet, {πρ} ist falsch transkribiert worden. Festgestellt hat er das, indem er auf das Image der Buchseite geschaut hat. Jetzt kann er mit einer einzigen XQuery alle Stellen von {πρ} im Text finden und alles auf einmal korrigieren. (Für die XQuery sollte es wohl eine Checkbox in den Suchoptionen geben: "Suche in faithful".)

Umgekehrt kann ein Forscher auch beschließen, dass die {πρ}-Ligatur in diesem Text nicht markierenswert ist. Diese Entscheidung muss nicht für weitere Texte gelten, denn sie hängt vom im Buch verwendeten Font ab. (Vermutlich gibt es aber eine Liste von Ligaturen, die in allen Fonts trivial sind.) Dann kann er alle {πρ} durch das simplere πρ ersetzen, also zum Beispiel {πρ}ός durch πρός.

Es wird ein Workflow-Skript geben, das dabei hilft, <reg faithful="{πρ}ός">πρός</reg> durch πρός zu ersetzen. Beachte dabei insbesondere den Fall, dass in einem Wort wie {πα}ρε{σκ}{ευ}ασ{μέν}η die ersten beiden Ligaturen einfach sind, die anderen Ligaturen jedoch nicht. Dieses Skript wird auch helfen, beispielsweise <reg norm="exem" type="context">exẽ</reg> <lb/>plo durch <reg norm="exem- plo" type="context">exẽ-<lb/>plo</reg> zu ersetzen (eigentlich mit soft hyphen).

Sobald der Inhalt von faithful sogar mit Unicode-Mitteln dargestellt werden kann, kommt er zurück in den Original-Text.

Das type-Attribut in <reg> wird sich wohl weiterhin nur auf den Inhalt des norm-Attributs beziehen. Es wird sowieso nicht vom Anzeigesystem ausgewertet und soll nur erklären, wie es zu einer bestimmten Regularisierung gekommen ist.

Zusammenhang mit den Anzeigemodi

Bei den Anzeigemodi ist "faithful" als eine Checkbox von Original realisiert.

	Original	faithful	Regularized	Normalized
orig	orig	orig	orig	normalisiertes orig
<reg norm="reg">orig</reg>	orig	orig	reg	normalisiertes reg
<reg faithful="faithful">orig</reg>	orig	faithful	orig	normalisiertes orig
<reg faithful="faithful" norm="reg">orig</reg>	orig	faithful	reg	normalisiertes reg

Das norm-Attribut hat immer noch einen unglücklichen Namen, denn der Name klingt, als ob es etwas mit der Normalisierung zu tun hätte. Ich möchte aber auch nicht <reg reg="korrigiert">Fehler</reg> verwenden. Wie wäre es mit "std"?

Die Grenze zwischen orig und faithful

In diesem Abschnitt geht es um die Frage, wo die Grenze zwischen orig und faithful gezogen wird.

Fälle, die entweder in orig oder in faithful gehören:

1. Unicode-Zeichen: Kernbereich (zum Beispiel "a")
2. Unicode-Zeichen: alle offiziellen Codepoints, die direkt einem Zeichen oder einem Diakritikum im Text entsprechen (zum Beispiel "ꝫ", combining characters, alchemistische Zeichen)
3. Unicode-Zeichen: PUA der MUFI (zum Beispiel "")
4. Unicode-Zeichen: IDS, IVS
5. idiosynkratische Notationen wie {πρ}, {q3-it-a}

Voraussetzung: Zu orig sollen mindestens Gruppe 1 und 2 gehören. Also zum Beispiel Zeichen aus dem Kernbereich wie "a", Zeichen aus Spezialgebieten wie der medievalist character "ꝫ", und offizielle Zeichen, für die wir selbst noch keinen Font haben, wie die Alchemie-Zeichen (nur in diesem Fall würden wir eine escape sequence wie &x1F700; verwenden). Ein Kernbereich von Unicode-Zeichen ist sowieso nicht klar definierbar.

Mögliche Kriterien, um zu entscheiden, ob die anderen Gruppen in orig oder in faithful kommen, sind:

1. vom Benutzer zu schaffen, versus Programmieraufwand
2. Unicode: Standard versus PUA
3. idiosynkratisch versus Standard

Mit diesen Kriterien ergibt sich:

	orig	faithful	unklar
A	1 2 3	4 5
B	1 2	3	4 5
C	1 2 3	5	4

Das sinnvollste Kriterium ist wohl Kriterium A: Kann der Benutzer den XML-Text auf seinem eigenen System mit geringem Aufwand korrekt darstellen lassen? Geringer Aufwand ist zum Beispiel, Unicode-Fonts zu installieren.

Gegen Kriterium B: Um Gruppe 2 korrekt anzeigen zu können, muss der Benutzer einen MUFI-Font installieren. Normale Fonts können "ꝫ" nicht anzeigen. Wir erwarten auch, das der Benutzer sich einen Font für die CJK-Extension B installiert. Dann kann der Benutzer aber auch Zeichen der Gruppe 3 anzeigen lassen.

Kriterium A und B widersprechen sich nicht vollständig, und es gibt auch Argumente (siehe hier und hier), die dafür sprechen, PUA-Zeichen nur im faithful-Attribut zu erlauben. Dann wäre die Trennung 1 2 versus 3 4 5.

Gegen Kriterium C: Zum Beispiel IDS-Sequenzen können wir zurzeit noch nicht richtig (d.h. als ein einzelnes Schriftzeichen) darstellen, obwohl sie aus offizellen Unicode-Zeichen bestehen.

Die Private Use Area

Im folgenden wird unser Umgang mit der Private Use Area (PUA) von Unicode besprochen. Wir würden gerne alle PUA-Zeichen zum Beispiel der MUFI nehmen, aber unsere Texte müssen in einem Web-basierten System anzeigbar sein.

• Wir erfinden selbst keine PUA-Zeichen.
• PUA-Zeichen müssen regularisiert werden.
• These: Standardisierte PUA-Zeichen wie die MUFI-Zeichen dürfen in "Original" stehen, anstatt in @faithful geschoben zu werden.

Mehrere mögliche Fälle:

1. Das Zeichen kann nur durch ein PUA-Zeichen völlig korrekt wiedergegeben werden. Beispiel "", das immerhin durch "qꝫ" angenähert werden könnte.
2. Das Zeichen kann am besten durch ein PUA-Zeichen wiedergegeben werden, es gibt aber auch nicht-PUA-Alternativen. Beispiel "", das auch "uͦ" geschrieben werden kann.
3. Das Zeichen könnte im Prinzip mit einem PUA-Zeichen wiedergegeben werden, aber wir haben keinen Font, der es dann auch anzeigen kann. Beispiel: kursives "" wie in ſenatori́ (Benedetti p.296). Siehe die Diskussion im Abschnitt Latein.

PUA-Zeichen in Original zu erlauben, scheint mir sinnvoll zu sein (siehe oben). Es gäbe aber auch Gründe, PUA-Zeichen ganz in das faithful-Attribut zu verbannen. Zum Beispiel greift bei offiziellen Zeichen der normale Font-Ersetzungsmechanismus: Man muss nur einen MUFI-Font installiert haben, dann wird das Zeichen korrekt angezeigt, selbst wenn man diesen Font nicht als Anzeige-Font verwendet. Ein PUA-Zeichen wird dagegen nur dann korrekt angezeigt, wenn das Zeichen im Anzeige-Font vorhanden ist. Zum Beispiel im Alvarus:

• mit PUA: <reg norm="numquam">nū̄</reg>
• ohne PUA: <reg faithful="nū̄" norm="numquam">nūq̄ꝫ</reg>

Ein konzeptionelles Argument wäre, dass der Original-Modus aus offiziellen Unicode-Zeichen bestehen sollte, und dass die PUA-Zeichen, selbst wenn es MUFI-Zeichen sind, eher unseren idiosynkratischen Notationen aus den DESpecs entsprechen. Paul könnte sich den Text dann im faithful-Modus anschauen.

Regularisiert wird das Wort in jedem Fall, denn ꝫ ist mit oder ohne Ligatur ein Abkürzungszeichen. Man kann also kein <reg> einsparen, allerdings werden sie etwas länger. Immer noch kein Vergleich zu griechischem Text.

Abkürzungen

Es ist recht geradlinig, Abkürzungszeichen wie ꝙ oder ũ aufzulösen, denn sie sind tatsächlich als Abkürzungen gedacht, wo der Setzer nicht genug Platz hatte. Zeichen wie ę sind dagegen wohl keine Abkürzungszeichen in diesem Sinne, sondern eine bestimmte Weise, den ehemaligen Diphthong ae zu verschriftlichen.

Was ist mit Abkürzungen wie "&c."? Wird das zu "et cetera" oder nur zu "etc."? Im Benedetti steht zurzeit <reg norm="&amp;c." type="unresolved">&amp;c.</reg>. Die Idee davon ist unter anderem, dass jeder Punkt im Text, der nicht Satzendepunkt ist, sich rechtfertigen muss. Eine Art, das zu tun, ist, in einem tag wie <reg> zu verschwinden. Dieses Kriterium wird aber nur für sehr aufwändig nachbearbeitete Texte realistisch sein.

Moderne Abkürzungen wie "z.B." werden möglicherweise gar nicht regularisiert oder normalisiert. In der Normalisierung wäre es wohl zu schwierig und ginge sicher nur, wenn die Schreibweise so standardisiert ist, wie es in unseren Texten wohl nie sein wird (ist ein Abstand zwischen z. und B. oder nicht?). Es gibt im Deutschen viele Abkürzungen, die man auch gar nicht ausschreiben möchte, wie ursprünglich lateinische Wörter "p.", "etc.", "ibid.", "i.e.", oder im Englischen "AD", "BC". (Was ist mit Maßangaben wie mm, l, etc.? Will man unterscheiden zwischen Abkürzungen mit und ohne Punkt?) Trotzdem sollten sie wohl wenigstens im Wörterbuch gefunden werden. Aber in solchen Fällen kann man vermuten, dass auch die Abkürzung im Wörterbuch zu finden ist.

Die Lösung wie im Benedetti hätte jedenfalls den Vorteil, dass die Abkürzungen in der Textanzeige optisch erkennbar sind (weil alle <reg> optisch erkennbar sind). Und es wäre klar, was man im Wörterbuch suchen muss.

Automatische Fehlerkorrektur

In dieser Tabelle geht es um korrekt transkribierte Formen, d.h. die Transkription gibt wieder, was im Original steht. Dies wird natürlich nicht immer der Fall sein. Es steht daher an, die Textqualität automatisiert zu verbessern.

Ein Problem der automatischen Fehlerkorrektur ist, dass es oft nicht selbstverständlich ist, ob der Fehler schon im Original steht oder erst der Transkription hinzugekommen ist. Zwar kann man vermuten, dass zum Beispiel "ipfius" ein Transkriptionsfehler ist, aber es ist nicht sicher. Deshalb wird es bei der automatischen Fehlerkorrektur ein type="unverified" geben. Wenn es feststeht, dass der Fehler erst in der Transkription entstanden ist, kann das <reg> durch die stillschweigend korrigierte Form ersetzt werden.

Bestimmte Fehler, wie zum Beispiel überflüssige oder fehlende spaces, werden wir voraussichtlich von vornherein stillschweigend korrigieren.

Standard-Regularisierungen in allen Sprachen

• Fehler-Korrekturen

Latein

• reſiduũ wird zu reſiduum
• ę wird nicht regularisiert und erst in der Normalisierung zu ae. Ich werde die entsprechenden <reg> noch aus dem Benedetti entfernen.
• alle Variationen von -que werden regularisiert
• alle medievalist characters (Standardzeichen und PUA-Zeichen) werden regularisiert

Benedetti enthält einige medievalist characters, sie werden aber nicht mehr wie im Alvarus standardmäßig verwendet. Ein schwieriger Fall ist das kursive Wort $enatori\'{que} (Benedetti p.296). Das Zeichen {que} könnte wieder mit dem PUA-Zeichen  wiedergegeben werden:

• <reg norm="ſenatorique">ſenatori́</reg>

Aber wir haben keinen Font, der es dann auch in seiner kursiven Form anzeigen kann. Stattdessen müsste man schreiben:

• <reg faithful="ſenatori{q3-it-a}" norm="ſenatorique">ſenatoriq́ꝫ</reg>

{q3-it-a} wird dann entweder als Text wiedergegeben, oder es gibt eine Datei q3-it-a vom Typ jpg/gif/bmp, svg, etc.

Es ist unklar, in welchem Arbeitsschritt die Information hineinkommt, dass es eine kursive Textstelle ist, und dass wir dieses spezielle Zeichen kursiv nicht anzeigen können. Das Problem ist zwar im reg-Skript lösbar, aber vielleicht wäre das ein weiteres Argument, PUA-Zeichen doch nur im faithful-Attribut zuzulassen. Dann kann man nämlich automatisiert ein funktionierendes <reg> erstellen:

• <reg faithful="ſenatori́" norm="ſenatorique">ſenatoriq́ꝫ</reg>

Wenn zu irgendeinem Zeitpunkt klar wird, dass wir das Zeichen im faithful-Attribut gar nicht anzeigen können, kann man es ändern in

• <reg faithful="ſenatori{q3-it-a}" norm="ſenatorique">ſenatoriq́ꝫ</reg>

Der Name {q3-it-a} ist eine Verkürzung des MUFI-Namens "q3app" mit dem Zusatz it für kursiv und a für Akut. {q3-it-a} enthält also den Akut bereits. Selbst wenn wir ein Bild von {q3-it} haben, können wir wohl nicht erwarten, ein Bild korrekt mit einem combining acute anzuzeigen.

Benedetti enthält das Zeichen nur in kursivem Text. Gäbe es das Zeichen auch in normalem Text, würde die entsprechenden <reg> so aussehen:

• PUA in Original erlaubt:
  • upright: <reg norm="ſenatorique">ſenatori́</reg>
  • kursiv: <reg faithful="ſenatori{q3-it-a}" norm="ſenatorique">ſenatoriq́ꝫ</reg>
• PUA in Original nicht erlaubt:
  • upright: <reg faithful="ſenatori́" norm="ſenatorique">ſenatoriq́ꝫ</reg>
  • kursiv: <reg faithful="ſenatori{q3-it-a}" norm="ſenatorique">ſenatoriq́ꝫ</reg>

Dass im zweiten Fall im faithful-Attribut unterschiedliche Dinge stehen, ist unbefriedigend, aber vielleicht nicht zu ändern. (Man könnte den Unterschied eventuell kleiner machen, indem man "ſenatori́" durch "ſenatori{q3-a}" ersetzt. Für {q3-a} könnte dann im System statt einem Bild das PUA-Zeichen ́ hinterlegt sein.) Der erste Fall ist allerdings noch viel unbefriedigender als der zweite Fall. Das wäre also ein Argument gegen PUA-Zeichen in Original.

Im faithful-Attribut könnte man auch die Idee wiederbeleben, das Zeichen durch die Sequenz q́ ZWJ ꝫ darzustellen. Hätte das irgendwelche Vorteile gegenüber dem PUA-Zeichen?

Deutsch

Die Vorgehensweise in deutschen Texten ist noch unklar. Bei einem modernen Text werden wohl nur echte Fehler regularisiert.

Fraktur

Die MUFI hat ein PUA-Zeichen für das {uo} in z{uo}. Wenn man es verwendet, muss jedes z{uo} in ein <reg>, damit es im regularisierten Text kein PUA-Zeichen mehr gibt. Wenn man stattdessen ein "combining letter o" verwendet, reicht es aus, das Zeichen zu normalisieren. Ich neige zum zweiten, insbesondere weil es keine buchspezifische Schreibweise ist.

(Sollten wir die Information uͤ versus ü markieren lassen? In Cardano kommt beides vor, offenbar ohne Bedeutungsunterschied.)

Chinesisch

In Unicode enthaltene Zeichenvarianten auf ihr Standardzeichen zurückzuführen ist Aufgabe der Normalisierung.

Die Regularisierung ist im Chinesischen insbesondere für die Erschließung der Zeichenvarianten zuständig, die nicht in Unicode enthalten sind. Noch vor der Regularisierung wird im XML-Workflow das 中<国V> im Rohtext in einem ersten Schritt in ein XML-kompatibles 中{国V} geändert. Bei der Regularisierung:

• 中<reg faithful="{⿴口或}">国</reg>, falls das Skript nicht auf eine von den Chinesen erstellte IDS-Sequenz wie ⿴口或 zurückgreifen kann
• 中<reg faithful="{国}" type="unresolved">国</reg>, falls das Skript nicht auf eine IDS-Sequenz zurückgreifen kann; dann funktioniert immerhin die Suche. Man kann man diesen Schritt auch auslassen und das <reg> gleich per Hand erstellen.
• <reg faithful="中{⿴口或}">中国</reg> per Hand (Wortgrenzen beachten, eventuell IDS-Sequenz einfügen)

Die Entscheidung, ob eine nicht in Unicode vorhandene Zeichenvariante überhaupt markiert werden muss oder ob man einfach das Standardzeichen tippen kann, haben die Chinesen bereits aufgrund der Regeln in den chinesischen DESpecs getroffen. Da ein Zeichen nur beim ersten Mal markiert werden muss, muss man den Text durchgehen auf alle Vorkommnisse des Zeichens, und eventuell ein <reg> einfügen. Dafür wäre ein interaktives Skript wünschenswert. Beachte, dass im gleichen Text das Standardzeichen und mehr als eine Variante vorkommen können.

(Die IDS-Sequenz {⿴口或} ist natürlich nicht echt, denn sie beschreibt einfach das Langzeichen 國 des Kurzzeichens 国. Es echtes Beispiel wäre {⿱井蛙}. Weitere Beispiele ​hier.

Im faithful-Attribut könnten wir auch IVS-Sequenzen unterbringen. Diese bestehen aus einem Schriftzeichen und einem weiteren Zeichen aus dem Bereich FE00-FE0F (und nochmal ab E0100). Wir haben noch keine Möglichkeit, bei IVS-Sequenzen das korrekte Zeichen anzuzeigen. Wenn man damit gar nichts anfangen kann, wird das zusätzliche Zeichen wohl einfach nicht angezeigt, d.h. man sieht das Ausgangszeichen und eventuell einen space, und die Suche in faithful bricht vermutlich. Nach der Logik der oberen Beispiele sollte man { } darum machen. Das { } wäre eigentlich hier nicht nötig. Eigentlich ist es auch bei IDS-Sequenzen nicht wirklich nötig, aber dann müsste das System ausrechnen, wo die Sequenz wieder zuende ist.

Wir haben bisher noch keinen Font für Extension C und Extension D. Diese Extensions sind viel kleiner als Extension B, und uns ist auch noch kein Zeichen aus diesen Extensions begegnet. Wir werden mit dem Problem umgehen, wenn es auftritt.

Griechisch

Übliche Fehler sind:

• Akzent über dem falschen Buchstaben bei einem Diphthong
• lateinische Zeichen als Ersatz für griechische Zeichen, zum Beispiel small-caps-H für η.
• echte Satzfehler

Bei der Aufarbeitung von griechischem Text stehen wir noch am Anfang.

Ähnlich wie im Chinesischen ist die Regularisierung für Ligaturen zuständig, die wir nicht mit Unicode-Mitteln ausdrücken können. Dabei wird einfach das Wort aus dem Rohtext in das faithful-Attribut geschoben.

Es wäre schön, bei unseren Texten jeweils eine Liste aller Zeichen zu haben, die dem Setzer zur Verfügung standen, und welches Zeichen der Setzer an einer bestimmten Stelle verwendet hat. Es ist aber wohl nicht realistisch, dies auch im XML-Text zu kodieren. Schon im Lateinischen gibt es Standard-Ligaturen wie "fi", die wir nicht markieren lassen. Und gerade bei frühen griechischen Drucken hängt die Ligaturenliste sehr stark von der verwendeten Schriftart ab. Die Bedeutung der im Rohtext markierten Ligaturen ist daher wohl eher, dass wir Transkriptionsfehler besser bereinigen können; siehe auch das Szenario im Abschnitt über das faithful-Attribut.

In den DESpecs steht, dass letter variations wie die alternative Form ϐ von β gar nicht erst getippt werden sollen. Die DESpecs verlangen auch explizit, dass verschiedene Ligaturen von καὶ, die auch im gleichen Text auftreten, nicht optisch mit {καὶ1}, {καὶ2}, etc. als unterschiedliche καὶ-Ligaturen, sondern semantisch als "die" Ligatur {καὶ} markiert werden. Vielleicht kann man deshalb bei dieser Gelegenheit offensichtlich triviale Ligaturen stillschweigend entfernen. Ein Kandidat für eine triviale Ligatur wären zwei ineinander verschränkte λ. Die gleiche Ligatur kann aber in einem Buch einfach und im nächsten Buch schwierig sein. Da wir aber bisher nur theoretische Aussagen von Gräzisten haben, wo die Grenze zwischen trivialen und nicht-trivialen Ligaturen verläuft, halte ich es für sinnvoll, vorläufig alle Ligaturen zu behalten, bis das System tatsächlich verwendet wird. Informationen weglassen können wir immer noch.