21 | | 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: |
| 25 | 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: |
27 | | 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".) |
| 31 | 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".) |
| 32 | |
| 33 | 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 πρός. |
| 34 | |
| 35 | 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). |
| 36 | |
| 37 | Das type-Attribut in <reg> wird sich wohl weiterhin nur auf den Inhalt des norm-Attributs beziehen. |
| 99 | 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. |
| 100 | |
| 101 | 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. |
| 102 | |
| 103 | |
| 104 | === Abkürzungen === |
| 105 | |
| 106 | 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. |
| 107 | |
| 108 | Was ist mit Abkürzungen wie "&c."? Wird das zu "et cetera" oder nur zu "etc."? Im Benedetti steht zurzeit `<reg norm="&c." type="unresolved">&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. |
| 109 | |
| 110 | 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. |
| 111 | |
| 112 | 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. |