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. 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 muss in <reg>
• halte die Anzahl der benötigten <reg> möglichst klein
• 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 {πρ}ός (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. 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).

Das type-Attribut in <reg> wird sich wohl weiterhin nur auf den Inhalt des norm-Attributs beziehen.

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

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.

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.
• PUA-Zeichen 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 "" wie in ſenatori́ (Benedetti p.296)

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.