Changes between Version 22 and Version 23 of normalization/5
- Timestamp:
- Jan 17, 2011, 10:10:11 AM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
normalization/5
v22 v23 1 1 [[PageOutline(1-4,,pullout)]] 2 2 3 == 5. Wie soll regularisiert werden? == 3 [wiki:normalization Regularisierung und Normalisierung], 4 I: [wiki:normalization/1 1] [wiki:normalization/2 2] [wiki:normalization/3 3], II: [wiki:normalization/4 4] [wiki:normalization/5 5] [wiki:normalization/6 6] [wiki:normalization/7 7] 5 6 = 5. Wie soll regularisiert werden? = 4 7 5 8 Die Regularisierung eines Textes mit Hilfe von <reg> ist wohlbekannt. Schon vor Beginn des MPDL-Projektes wurde das <expan> aus dem Archimedes-Projekt in <reg> umbenannt, und vor einem halben Jahr wurde die Struktur von <reg> umgestellt: … … 11 14 Beispiele für Regularisierungen sind in [wiki:normalization/4 dieser Tabelle] zu sehen. 12 15 13 == = Ziele ===16 == Ziele == 14 17 15 18 Durch die Regularisierung soll im Idealfall eine Textgestalt geschaffen werden, die zusammen mit der Normalisierung einer klassischen Text-Edition entspricht. … … 27 30 28 31 29 == = Das faithful-Attribut ===32 == Das faithful-Attribut == 30 33 31 34 Das faithful-Attribut nimmt Informationen aus dem Rohtext auf, die wir zurzeit noch nicht richtig darstellen können und die die Suche brechen. (Ein anderer möglicher Name wäre "facsimile".) … … 46 49 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 menschenlesbar erklären, wie es zu einer bestimmten Regularisierung gekommen ist. 47 50 48 == = Zusammenhang mit den Anzeigemodi ===51 == Zusammenhang mit den Anzeigemodi == 49 52 50 53 Bei den Anzeigemodi ist "faithful" als eine Checkbox von Original realisiert. … … 61 64 62 65 63 == = Die Grenze zwischen orig und faithful ===66 == Die Grenze zwischen orig und faithful == 64 67 65 68 In diesem Abschnitt geht es um die Frage, wo die Grenze zwischen Original und faithful gezogen wird. … … 79 82 Gruppen 4 und 5 gehören zu faithful; für diesen Gruppen ist faithful ja eingeführt worden. Entscheidend ist, dass wir ein Zeichen in der Vorlage nicht durch mehrere Zeichen in Original wiedergeben wollen. Zum Beispiel können wir IDS-Sequenzen, die naturgemäß aus mehreren offiziellen Unicode-Zeichen bestehen, zurzeit noch nicht richtig (d.h. als ein einzelnes Schriftzeichen) darstellen. Eine nicht umgewandelte IDS-Sequenz würde also die Textvorlage nur indirekt wiedergeben. Um diese Gruppen korrekt anzuzeigen, muss man also auf der Server-Seite Programmieraufwand betreiben. 80 83 81 == = Die PUA ===84 == Die PUA == 82 85 83 86 Wir würden gerne einfach alle PUA-Zeichen zum Beispiel der MUFI verwenden, 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 Schwierigkeiten des Themas. Klar ist: … … 130 133 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 "ſenatorí" durch "ſenatori{q3-a}" ersetzt. Für {q3-a} könnte dann im System statt einem Bild das PUA-Zeichen ́ hinterlegt sein.) Der Unterschied im ersten Fall ist allerdings noch viel unbefriedigender als der zweite Fall. Das wäre also ein Argument gegen PUA-Zeichen in Original. 131 134 132 == = Abkürzungen ===135 == Abkürzungen == 133 136 134 137 Abkürzungszeichen wie ꝙ oder ũ werden regularisiert, 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 (zu ę siehe auch [wiki:e-caudata hier]). … … 140 143 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 (unabhängig davon, ob es dann auch einen Wörterbucheintrag gibt). 141 144 142 == = Automatische Fehlerkorrektur ===145 == Automatische Fehlerkorrektur == 143 146 144 147 In [wiki:normalization/4 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. … … 154 157 Lesehilfe-Diakritika können wir möglicherweise zur Wortgrenzenerkennung verwenden, zum Beispiel beim fehlenden Leerzeichen in "ferècæteri" (Benedetti p.7). 155 158 156 == = Standard-Regularisierungen in allen Sprachen ===159 == Standard-Regularisierungen in allen Sprachen == 157 160 158 161 * Fehler-Korrekturen 159 162 * Abkürzungszeichen auflösen 160 163 161 == = Latein ===164 == Latein == 162 165 163 166 * reſiduũ wird zu reſiduum … … 166 169 * alle medievalist characters (Standard-Unicode und PUA-Zeichen) werden regularisiert 167 170 168 == = Deutsch ===171 == Deutsch == 169 172 170 173 Die Vorgehensweise in deutschen Texten ist noch unklar. Bei einem modernen Text werden wohl nur echte Fehler regularisiert. … … 178 181 (Sollten wir in Zukunft die Information uͤ versus ü markieren lassen? In Cardano kommt beides vor, offenbar ohne Bedeutungsunterschied. Und das alternative r? Eher vergleichbar mit ſ oder mit letter variation ϐ? Immerhin ist das alternative r in Unicode: ꝛ (A75B). Wenn sich der Benutzer den Text mit einem Fraktur-Font anzeigen lässt, wäre es sicher netter, wenn das alternative r richtig dargestellt wird. Aber gibt es überhaupt Fraktur-Fonts, die ausreichend kompatibel mit Unicode sind? Zwangsligaturen wie ch, ck, tz lassen wir auch nicht markieren und überlassen es einem eventuellen Fraktur-Font, sie korrekt darzustellen.) 179 182 180 == = Chinesisch ===183 == Chinesisch == 181 184 182 185 In Unicode enthaltene Zeichenvarianten auf ihr Standardzeichen zurückzuführen ist Aufgabe der Normalisierung. … … 195 198 Wir haben bisher noch keinen Font für ''Extension C'' und ''Extension D''. Diese Extensions sind viel kleiner als Extension B, und unsere Texte enthalten bisher keine Zeichen aus Extension C oder D. Wir werden mit dem Problem umgehen, wenn es auftritt. 196 199 197 == = Griechisch ===200 == Griechisch == 198 201 199 202 Bei der Aufarbeitung von griechischem Text stehen wir noch am Anfang. Übliche Fehler in der Vorlage sind:
