Regularisierung und Normalisierung, I: 1 2 3, II: 4 5 6 7

7. Was ist konkret zu tun?

Arboreal

Tippfehler und Programmfehler bei u/v-Regeln korrigieren. (Wer macht das?)

XML-Texte

Benedetti:

• entferne <reg> für ę
• <num value="1585" style="sc">mdlxxxv</num>
• class="sc" zu style="sc"

Info in den Metadaten: Für diesen Text wird ein Font für medievalist characters, Extension B, Hieroglyphen etc. benötigt. Oder: Dieser Text enthält Zeichen aus den Unicode-Blöcken ... (Skript schreiben!) (Insbesondere bei PUA-Zeichen, denn offizielle Codepoints kann man immerhin bei Unicode oder oft auch bei der (englischen) Wikipedia oder Wiktionary nachschauen.)

Workflow

Textkorrektur: Akut statt Tonos

<reg>: es soll einfach sein, Regularisierungen für unterschiedliche Sprachschichten auszuprobieren

Prüfmodul für <reg>:

• NFC-Normalform
• keine PUA-Zeichen mehr im Text
• keine medievalist characters mehr

interaktives Skript für den scholarly workflow:

• ersetze <reg faithful="{πρ}ός">πρός</reg> durch πρός
• ersetze <reg norm="exem" type="context">exẽ</reg> <lb/>plo durch <reg norm="exem- plo" type="context">exẽ-<lb/>plo</reg> (soft hyphen!)

DESpecs

• chinesische DESpecs: bei Varianten eine IDS-Sequenz angeben lassen
• uͤ versus ü markieren lassen?

Schema

<reg> mit type="unverified" (spätestens wenn die automatisierte Textverbesserung beginnt)

Frontend

Checkbox "faithful" als Unterpunkt von Original. (Jochen: zwar einfach zu machen, aber nicht dringend)

Der Benutzer muss gewarnt werden, dass er für Original (auch ohne faithful) eventuell bestimmte Fonts installieren muss, zum Beispiel einen MUFI-Font wie Andron, Junicode oder Palemonas. Entweder eine allgemeine Warnung, oder die Information wird einem Eintrag in den Metadaten entnommen.

Der Benutzer soll für einen Text die Normalisierungen von verschiedenen Sprachschichten einstellen können. Also in den extended-Optionen für jede Sprache die Wahl zwischen allen vorhandenen Normalisierungen. Wenn das Backend die Information liefert, ob ein Text <place> enthält, könnte man vielleicht auch herausfinden, welche Sprachen er laut den xml:lang-Attributen im Text enthält, und in den Optionen nur diese Sprachen auflisten?

Backend

Modulare Architektur:

• Zwei Lex-Dateien pro Sprache, eine für die Textanzeige und eine für die Wörterbuch-Normalisierung. In manchen Sprachen weitere Aufteilung in Sprachschichten. Falls gewünscht, schreibe ich die Lex-Dateien zumindest für die Textanzeige.
• Regeln sollten leicht änderbar sein, indem man eine Lex-Datei ändert, ohne in den Java-Code eingreifen zu müssen; sowohl bei einfachen Ersetzungsregeln als auch bei algorithmischen Regeln wie u/v.
• Änderungen sollten im System sofort sichtbar sein. Wenn die Lex-Dateien in Java umgewandelt werden müssen, sollte das idealerweise per Knopfdruck möglich sein.
• Die Architektur muss mit offenen Klassen wie der chinesischen Zeichenliste umgehen können, wo gelegentlich Zeichen von studentischen Hilfskräften nachgetragen werden.
• Trennung von sprachimmanenter Normalisierung (Beispiel "Gravis wird zu Akut") und technisch bedingter Normalisierung (Beispiel "Unicode wird zu Betacode"). Die technisch bedingte Normalisierung ist der sprachimmanenten Normalisierung nachgeschaltet.
  • Intern verwenden wir reines Unicode. Ein wichtiges Ziel ist, auch die Wörterbücher auf Unicode umzustellen. Falls das nicht möglich ist und zum Beispiel bei Griechisch weiterhin Betacode verwendet werden muss, brauchen wir eine modulare Architektur mit einer Unicode-Schnittstelle und kleinen Konvertierungsmodulen für die Wörterbücher, die leicht angepasst werden können.
  • Die Umwandlung von Käse in Kaese für ein bestimmtes Wörterbuch ist ein Beispiel eine technisch bedingte Normalisierung, die schon für das nächste Wörterbuch in der gleichen Sprache nicht zutrifft.
  • Aus Performance-Gründen könnte man dann die Normalisierungen eventuell automatisiert zusammenfassen. Dieser Vorgang müsste bei jeder Änderung an den Original-Modulen wiederholt werden.
• Ziel ist eine Kaskade:
  1. Normalisierung der Textanzeige, dann
  2. sprachimmanente Normalisierung für Wörterbücher, dann
  3. technisch bedingte Normalisierungen, dann
  4. Grundformbildung.

Auf dem Weg sollte die Wortform-Disambiguierung von zum Beispiel hîc aufbewahrt werden.

Zentrales repository ("authority file") für die {}-Sequenzen aus dem faithful-Attribut: {πρ}, {q3-it-a}, {⿴口或} etc., mit Angaben, wie diese Sequenzen dargestellt werden. Eventuell auch für escape sequences wie &x1F70D;. (Wenn es zu einer Sequenz keine Angabe oder Dateinamen gibt, wird sie unverändert angezeigt.)

Die Informationen im faithful-Attribut sollen sinnvoll suchbar sein. (Für die entsprechende XQuery sollte es wohl eine Checkbox in den Suchoptionen geben: "Suche in faithful".)

Langfristig sollen zumindest die IDS- und IVS-Sequenzen als jeweils ein einziges Zeichen anzeigbar sein, siehe Ticket ​#40.

<num> wie <var> vor der morphologischen Analyse verstecken

Archimedes-Texte: Beispiel <expan abbr="cõprehenſione">comprehenſione</expan>:

• Original: cõprehenſione (neu)
• Regularized: comprehenſione (wie bisher)
• Normalized: comprehensione (wie bisher)

Durchgehen: was genau sind die spezifischen Anforderungen der von uns verwendeten Wörterbücher?

sprachspezifische Normalisierungen

alle Sprachen:

• Umgang mit Zeilenumbrüchen (siehe auch Tickets ​#62 und ​#82)
• Allgemeine Definition von Wortgrenzen, oder muss das sprachspezifisch gemacht werden? Problem der Bindestriche im Deutschen? Grundstock an Zeichen, das von einzelnen Sprachen noch ergänzt werden kann? (Und wo notfalls auch Zeichen gestrichen werden können?)
• Apostroph im Wort oder als Wortendezeichen: unterscheide ' (0027) und ’ (2019).
  • Niederländisch: 't Gravenhage, auto's
  • Englisch: don't
• Allgemeine Vokal- und Konsonantenklassen zum Beispiel für die u/v-Regeln, auf Basis der Arboreal-Definitionen, ergänzt um die Vokale mit Diakritika, die bei uns normalisiert werden (und nur um diese Zeichen?). Oder gibt es einen Grund, die Vokalklassen für die Sprachen einzeln zu definieren?
  • Vokale: A E I O U Æ Œ in groß/klein, zusätzlich Ę ÀÈÌÒÙ ÀÈÌÒÙ ÄËÏÖÜ in groß/klein
  • Konsonanten: B C D F G H K L M N P Q R S T V W X Z in groß/klein sowie ſ ß
  • weder noch: J und Y
• Es gibt kein sprachunabhängiges Normalisierungsmodul mit allgemeinen Regeln wie "ſ wird zu s", denn es wird immer irgendwelche Ausnahmen geben. Stattdessen wird "ſ wird zu s" bei jeder auf dem lateinischen Alphabet beruhenden Sprache wiederholt.

Latein

• ſ wird zu s
• ß zu ss
• æ und ę zu ae
• œ wird zu oe
• ij wird zu ii
• u/v-Regeln
• nur Anzeige:
  • ò ô ö werden zu o, entsprechend für alle Vokale
• nur Wörterbuch, sprachimmanent:
  • ò wird zu o; entsprechend für alle Vokale
  • ô wird zu o; Wortform-Disambiguierung; entsprechend für alle Vokale
  • ö wird zu o; entsprechend für alle Vokale

Latein, explizite Liste

Die u/v-Regeln gelten auch für U und V. Ansonsten sind alle Regeln explizit angegeben. Es muss also zum Beispiel zu "œ zu oe" keine Regel "Œ zu OE" ergänzt werden.

• ſ : s
• ß : ss
• æ ę : ae
• Æ : AE
• œ : oe
• ij : ii
• u/v-Regeln (entsprechend auch für U und V)
  • qv wird zu qu
  • bei "Vokal [Zeilenumbruch] u Vokal" innerhalb eines Wortes wird u zu v
  • bei "Konsonant v [Zeilenumbruch] Konsonant" innerhalb eines Wortes wird v zu u
  • bei "v [Zeilenumbruch] Konsonant" am Wortanfang wird v zu u
  • Vokale im Sinne der u/v-Regeln sind (mindestens) A E I O U Æ in groß/klein sowie œ ę à è ò ù
  • Konsonanten im Sinne der u/v-Regeln: wie oben definiert (B C D F G H K L M N P Q R S T V W X Z in groß/klein sowie ſ ß)
• überflüssige Diakritika:
  • -à -àm -è -ò -ùm (jeweils am Wortende)
  • einzelne Wörter: aliàs, hîc, quòd (auch als Quòd QVòd), Cùmque, aër

im Wörterbuch außerdem:

• verwende hîc zur Disambiguierung (Adverb "hier" statt Demonstrativpronomen "dieser")

Kurzfristige Umsetzung der Regeln für Latein

Die neuen Regeln ersetzen die jetzigen Regeln. Was hier nicht explizit angegeben ist, wird nicht normalisiert.

Die Regeln sollten mittelfristig in Lex formuliert werden, und die Normalisierungsmodule sollen die oben beschriebene Architektur haben.

Kurzfristig kann man die Regeln größtenteils aus dem Arboreal-Quellcode übernehmen:

• Die einfachen Ersetzungsregeln können direkt aus dem Lateinischen übernommen werden: ſ ß æ ę Æ œ.
  • Beachte bei Æ, dass es zu AE und nicht wie in Arboreal zu Ae wird.
• die Regel für ij kann aus dem Italienischen übernommen werden.
• Die u/v-Regeln für Kleinbuchstaben können aus dem Italienischen übernommen werden.
  • Anpassungen beim Umgang mit Zeilenumbrüchen: entferne für die Normalisierung den Zeilenumbruch, arbeite also zum Beispiel mit ſphærę statt mit ſphæ-<lb/>rę. Beachte <pb> und <anchor>.
  • Der hier beschriebene Fehler im Arboreal-Programmcode muss korrigiert werden, wenn er sich durch den anderen Umgang mit Zeilenumbrüchen nicht sowieso erledigt hat.
  • Die Regel für qv muss neu implementiert werden, als Vorbild kann man die ij-Regel verwenden.
  • Die u/v-Regeln müssen dann noch für die Großbuchstaben U/V wiederholt werden.
  • Die Vokalklasse muss umdefiniert werden: A E I O U Æ in groß/klein sowie œ ę à è ò ù
• Die Diakritika-Regeln müssen neu implementiert werden.
  • -à -è -ò: Vokal gefolgt von Wortende --> Gravis fällt weg
  • -àm -ùm: Vokal gefolgt von "m" und dann Wortende --> Gravis fällt weg
• einzelne Wörter: Explizite Regeln für aliàs, hîc, quòd, Quòd, QVòd, Cùmque, aër. Die Regeln für die einzelnen Wörter sollten (zumindest in der Lex-Version) vor allen anderen Regeln abgearbeitet werden. Einzelwörter mit Regeln wie in der Arboreal-Java-Klasse zu beschreiben ist nicht schwierig, aber sehr umständlich. Kurzfristig könnte man das deshalb teilweise durch folgende Regeln ersetzen:
  • aliàs durch -às (am Wortende)
  • quòd, Quòd, QVòd durch -òd (am Wortende)
  • aër durch eine Regel: aë wird zu ae
  • hîc und Cùmque bleiben
• Die Disambiguierung von hîc kann man in der kurzfristigen Version weglassen.

Technisch bedingte Normalisierung im Lateinischen

Erstmal ist es okay, für Pollux die alte Normalisierung zu verwenden. Grundsätzlich gilt die neue Normalisierung aber auch für die Wörterbücher. Dabei werden mehrere Module hinteinandergeschaltet:

1. Erst wird das Normalisierungsmodul für die Textanzeige ausgeführt,
2. auf das Ergebnis wird ein weiteres Modul für sprachimmanente Normalisierungen (z.B. Gravis zu Akut im Griechischen; im Lateinischen gibt es möglicherweise gar keine) angewendet,
3. dann technisch bedingte Normalisierungen für einzelne Wörterbücher.

Wir sollten uns mal zusammensetzen, um zu gucken, wie die technisch bedingte Normalisierung aussehen soll. Es ist klar, dass Zeichen wie ẽ oder û nicht an Pollux geschickt werden sollten, weil Pollux nicht mit Unicode umgehen kann. Vermutlich läuft es darauf hinaus, dass die Diakritika nicht wie bei Malcolm einfach entfernt werden, sondern dass solche Wörter gar nicht erst an Pollux geschickt werden. Für die Index-Erstellung sollte es aber okay sein, die Wörter zu schicken. Dann sind eben Wörter wie Praeterquàmquod im Index. (Original ist Pręterquàmquòd, und ich gehe von einer Regel -òd aus; wird P im Index zu p, also praeterquàmquod? Wenn ja, macht Lucene das selbst?)

Italienisch

• ſ wird zu s
• u/v-Regeln

Englisch

• ſ wird zu s

Französisch

• ſ wird zu s
• u/v-Regeln?

Deutsch

• ſ wird zu s
• nur Wörterbuch, technisch bedingt (Celex):
  • Umlaute

Chinesisch

• Wortliste mit Einträgen der Form "Standard: Variante1 Variante2 etc." Beispiel: "歷: 歴"
• entferne ZWS

Griechisch

• nur Wörterbuch, sprachimmanent:
  • Gravis wird zu Akut
• Sigma: siehe ​#64
  • korrektes Sigma im XML-Text verwenden
  • keine Normalisierung in der Textanzeige
  • keine sprachimmanente Wörterbuch-Normalisierung
  • Falls nötig, technisch bedingte Normalisierung. Überschneidet sich eventuell mit der Umwandlung in Betacode, wo beide Sigma gleich dargestellt werden.