Changes between Version 6 and Version 7 of normalization/5


Ignore:
Timestamp:
Dec 10, 2010, 12:23:33 PM (13 years ago)
Author:
Wolfgang Schmidle
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • normalization/5

    v6 v7  
    33== Regularisierung ==
    44
    5 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.
    6 
    7 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.
    8 
    9 Viele Beispiele für Regularisierungen sind in [wiki:normalization/4#Beispiele dieser] Tabelle zu sehen.
    10 
    11 === Grundgedanken ===
    12 
    13 Ziele:
    14  * Wissen über den einzelnen Text und einzelne Textstellen muss in <reg>
     5Die Regularisierung eines Textes mit Hilfe von <reg> ist wohlbekannt. Seit dem Archimedes-Projekt wurde insbesondere die Struktur von <reg> umgestellt von [[BR]] `<reg orig="Original">Korrektur</reg>` zu [[BR]] `<reg norm="Korrektur">Original</reg>`, [[BR]] also zu <reg> als einer Annotation des Originaltextes.
     6
     7Neu 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.)
     8
     9Beispiele für Regularisierungen sind in [wiki:normalization/overview dieser Tabelle] zu sehen.
     10
     11=== Ziele bei der Regulierung ===
     12
     13 * Wissen über den einzelnen Text und einzelne Textstellen muss in <reg> und nicht in die Normalisierung.
    1514 * Halte die Anzahl der benötigten <reg> möglichst klein.
    1615 * Idealerweise wird gerade so viel regularisiert, dass die Normalisierung aus dem regularisierten Text die in der jeweiligen Sprache oder Sprachschicht gewünschte Standardschreibweise ergibt.
    17  * 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.
     16 * Informationen aus dem Rohtext, die wir zurzeit nicht nutzen können, sollen erhalten bleiben. Insbesondere wollen wir Griechisch von Rohtext in XML umwandeln können, ohne Informationen wegwerfen zu müssen.
    1817 * Sobald wir solche Informationen anzeigen können, soll dies mit dem unveränderten XML möglich sein.
    1918 * Die Suche soll funktionieren.
     
    2625=== Das faithful-Attribut ===
    2726
    28 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:
    29 
    30 <reg faithful="{πρ}ός">πρός</reg>
    31 
    32 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.
     27Das faithful-Attribut nimmt Informationen aus dem Rohtext auf, die wir zurzeit noch nicht richtig darstellen können und die die Suche brechen.
     28
     29Das faithful-Attribut muss nicht verwendet werden, insbesondere bei Texten, die nicht in China abgetippt wurden. Wenn es kein faithful-Attribut gibt, muss es aber, wie bisher auch, das norm-Attribut geben.
     30
     31In vielen Texten wird es tatsächlich 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:
     32
     33<reg faithful="{πρ}ός">πρός</reg>
    3334
    3435Die 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".)
    3536
    36 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 πρός.
    37 
    38 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).
     37Umgekehrt 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 πρός.
     38
     39Es 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 {πα} und {σκ} recht einfach sind, die Ligaturen {ευ und {μέν} jedoch nicht. Dieses Skript wird auch helfen, beispielsweise [[BR]] `<reg norm="exem" type="context">exẽ</reg> <lb/>plo`    durch [[BR]] `<reg norm="exem- plo" type="context">exẽ-<lb/>plo</reg>` [[BR]] zu ersetzen (eigentlich mit soft hyphen).
    3940
    4041Sobald der Inhalt von faithful sogar mit Unicode-Mitteln dargestellt werden kann, kommt er zurück in den Original-Text.
    4142
    42 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.
     43Das 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 menschenlesbar erklären, wie es zu einer bestimmten Regularisierung gekommen ist.
    4344
    4445
     
    5354|| <reg faithful="faithful" norm="reg">orig</reg> || orig || faithful || reg || normalisiertes reg ||
    5455
     56Wahrscheinlich werden wir in absehbarer Zukunft keinen Mechanismus zur korrekten Anzeige von Ligaturen wie {πρ} anbieten, so dass im faithful-Modus einfach {πρ}ός angezeigt wird. Die Textdarstellung funktioniert auch ohne einen geeigneten Mechanismus, und der Mechanismus kann jederzeit nachgeliefert werden.
     57
    5558Das 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"?
    5659
     
    5861=== Die Grenze zwischen orig und faithful ===
    5962
    60 In diesem Abschnitt geht es um die Frage, wo die Grenze zwischen orig und faithful gezogen wird.
    61 
    62 Fälle, die entweder in orig oder in faithful gehören:
    63  1. Unicode-Zeichen: Kernbereich (zum Beispiel "a")
    64  1. Unicode-Zeichen: alle offiziellen Codepoints, die direkt einem Zeichen oder einem Diakritikum im Text entsprechen (zum Beispiel "ꝫ", combining characters, alchemistische Zeichen)
     63In diesem Abschnitt geht es um die Frage, wo die Grenze zwischen Original und faithful gezogen wird.
     64
     65Gruppen, die entweder in orig oder in faithful gehören:
     66 1. Unicode-Zeichen: Kernbereich, d.h. alle Zeichen, die auf heutigen Computern problemlos angezeigt werden können (zum Beispiel "a")
     67 1. Unicode-Zeichen: alle offiziellen Codepoints, die direkt einem Zeichen oder einem Diakritikum im Text entsprechen; zum Beispiel
     68  * Zeichen aus Spezialgebieten, wie der medievalist character "ꝫ", für den man einen [http://www.mufi.info/ MUFI]-kompatiblen Font benötigt
     69  * combining characters, die generell ein Problem sind
     70  * offizielle Zeichen, für die wir selbst noch keinen Font haben, wie die Alchemie-Zeichen (nur in diesem Fall würden wir nicht den Codepoint selbst, sondern eine escape sequence wie `&x1F700;` verwenden)
    6571 1. Unicode-Zeichen: PUA der MUFI (zum Beispiel "")
    6672 1. Unicode-Zeichen: IDS, IVS
    6773 1. idiosynkratische Notationen wie {πρ}, {q3-it-a}
    6874
    69 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.
    70 
    71 Mögliche Kriterien, um zu entscheiden, ob die anderen Gruppen in orig oder in faithful kommen, sind:
     75Voraussetzung: Zu orig sollen mindestens Gruppe 1 und 2 gehören. Ein Kernbereich von Unicode-Zeichen ist sowieso nicht klar definierbar.
     76
     77Mögliche Kriterien, um zu entscheiden, ob die anderen Gruppen in Original oder in faithful kommen, sind:
    7278 A. vom Benutzer zu schaffen, versus Programmieraufwand
    7379 A. Unicode: Standard versus PUA
     
    9298=== Die Private Use Area ===
    9399
    94 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.
     100Im 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. Die Anzeigeprobleme für die vorliegende Wiki-Seite auf dem Bildschirm und auf Papier sind bereits ein Hinweis für die Schwierigkeit des Themas.
    95101
    96102 * Wir erfinden selbst keine PUA-Zeichen.
     
    125131=== Automatische Fehlerkorrektur ===
    126132
    127 In [wiki:normalization/4#Beispiele 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.
     133In [wiki:normalization/overview 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.
    128134
    129135Ein 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.
     
    201207 * lateinische Zeichen als Ersatz für griechische Zeichen, zum Beispiel small-caps-H für η.
    202208 * echte Satzfehler
     209 * Transkriptionsfehler: Tonos statt Akut (wird stillschweigend korrigiert)
    203210
    204211Bei der Aufarbeitung von griechischem Text stehen wir noch am Anfang.