Regularisierung

Die Regularisierung des Textes mit Hilfe von <reg> ist wohlbekannt. 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.

Grundgedanken

Ziele:

• 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.

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 {πρ}ός. 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 alle Stellen von {πρ} im Text finden mit einer einzigen XQuery und alles auf einmal korrigieren. (Für die XQuery sollte es wohl eine Checkbox in den Suchoptionen geben: "Suche in faithful".)

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

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 {πρ}, {q-et-it-acute}

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

These: Das sinnvollste Kriterium ist 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.

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. Die Kurzversion ist: Wir erfinden selbst keine PUA-Zeichen. Standardisierte PUA-Zeichen wie die MUFI-Zeichen dürfen in "Original" stehen, anstatt in @faithful geschoben zu werden, müssen aber regularisiert 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 "".

...