Changes between Version 23 and Version 24 of workflow
- Timestamp:
- May 25, 2010, 4:03:46 PM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
workflow
v23 v24 20 20 21 21 Die Arbeitsschritte bestehen jeweils aus einer 22 [source:trunk/schema/scripts/workflow Reihe von Skripten]. Einige dieser Skripte sind noch leere Platzhalter, aber die Workflow-Struktur stimmt bereits.22 [source:trunk/schema/scripts/workflow Reihe von Skripten]. Einige dieser Skripte sind noch leere Platzhalter, aber die Workflow-Struktur ist bereits recht ausgereift. 23 23 24 24 * Im Gegensatz zu den früheren Skripten dürfen die hier beschriebenen Bearbeitungsschritte die Zeilenstruktur verändern, zum Beispiel eine Zeile hinzufügen. 25 25 * Beachte, dass Work Orders 1 bis 5 mit den [http://pythia.mpiwg-berlin.mpg.de/department1/mpdl/despecs/DESpecs.pdf/DESpecs_V1.pdf DESpecs 1.1.2] und Work Orders 6 bis 9 mit den [http://pythia.mpiwg-berlin.mpg.de/department1/mpdl/despecs/DESpecs.pdf/DESpecs_V2.pdf DESpecs 2.0] geschickt wurden. Unterschiede sind zum Beispiel das Format von Figures und von Tabellen. 26 * Ein Stern * bei einem Filter bedeutet: Wenn man zum raw text zurückkehrt, muss dieses Skript anschließend noch einmal angewendet werden. Alle Skripte mit * laufen automatisch ab; Ausnahme könnte später das {{{<s>}}}-Skript sein. Die automatischen Skripte sollten soweit wie möglich in Meta-Skripten abrufbar sein.27 * Namenskonvention bei den Skripten: {{{check}}} als Vorbereitung, {{{test}}} als Nachbereitung. Alle anderen Skripte müssen wiederholt werden, wenn man wieder mit dem raw text anfängt.28 26 29 27 … … 32 30 In diesem Schritt werden alle Vorbereitungen getroffen, um mit dem raw text arbeiten zu können. Insbesondere werden Verzeichnisse angelegt und Dateien kopiert. 33 31 34 * Im Gegensatz zu den weiteren Skripten ist zumindest das Skript in Schritt 1.01 kein Text-Filter, denn man arbeitet hier noch gar nicht mit einem Text-Editor.35 32 * Wenn wir einen transkribierten Text aus China erhalten, muss zuerst geprüft werden, ob die Datei tatsächlich, wie in den DESpecs verlangt, reiner Text in [http://de.wikipedia.org/wiki/UTF-8 UTF-8] ist. Insbesondere akzeptieren wir keine doc-Dateien. 36 * Es ist noch nicht ganz klar, wo neue Dateien in Zukunft abgelegt werden: Kommen sie wie bisher zuerst nach [http://pythia.mpiwg-berlin.mpg.de/department1/mpdl/raw-texts Pythia] oder gleich in das [source:trunk/texts wiki-repository]? Ich gehe vorläufig davon aus, dass Texte weiterhin zuerst nach Pythia kommen. Die Namenskonvention auf Pythia ist bisher Workorder_Autor_Jahr.33 * Es ist noch nicht ganz klar, wo neue Dateien in Zukunft abgelegt werden: Kommen sie wie bisher zuerst nach [http://pythia.mpiwg-berlin.mpg.de/department1/mpdl/raw-texts Pythia] oder gleich in das [source:trunk/texts wiki-repository]? Ich gehe vorläufig davon aus, dass Texte weiterhin zuerst nach Pythia kommen. Die Namenskonvention auf Pythia ist bisher {{{workorder_autor_jahr}}}. 37 34 38 35 39 36 ==== 1.01 Von Pythia ins svn-repository ==== 40 37 41 Das Skript [source:trunk/schema/scripts/workflow/Filter_1_01_import_text.pl Filter_1_01_import_text] legt die Verzeichnisse im repository an und kopiert den Text von Pythia in das repository. 38 Das Skript [source:trunk/schema/scripts/workflow/Filter_1_01_import_text.pl Filter_1_01_import_text] legt die Verzeichnisse im repository an und kopiert den Text von Pythia in das repository. 42 39 43 40 * Im [source:trunk/texts Texte-Verzeichnis] Unterverzeichnisse anlegen (allerdings nerven die raw/xml-Verzeichnisse in der Praxis) 44 41 * Datei aus Pythia rüberkopieren 45 * Kopie erstellen und umbenennen ( autor_jahr_identifier), Zeilenenden von CRLF zu LF. Entferne [http://de.wikipedia.org/wiki/Byte_Order_Mark BOM]-Fragmente (korrekte BOMs sind okay).42 * Kopie erstellen und umbenennen ({{{autor_jahr_identifier}}}), Zeilenenden von CRLF zu LF. Entferne [http://de.wikipedia.org/wiki/Byte_Order_Mark BOM]-Fragmente (korrekte BOMs sind okay). 46 43 47 44 (Shell-Skript von Klaus) 48 45 46 Im Gegensatz zu den weiteren Skripten ist zumindest das Skript in Schritt 1.01 kein Text-Filter, denn man arbeitet hier noch gar nicht mit einem Text-Editor. 47 49 48 50 49 ==== 1.02 Kommunikation mit Foxridge ==== … … 54 53 Erstelle eine lokale Kopie der entsprechenden index.meta-Datei (funktioniert nur innerhalb des Instituts): 55 54 {{{ 56 http://content.mpiwg-berlin.mpg.de/mpiwg/online/permanent/archimedes_repository/large/catan_belli_502_la_1600/index.meta57 55 http://content.mpiwg-berlin.mpg.de/mpiwg/online/permanent/library/2UZM8E2N/index.meta 58 56 }}} … … 82 80 === 2. raw text bearbeiten === 83 81 84 In diesem Arbeitsschritt wird der raw text auf die Umwandlung in XML vorbereitet. Die ersten beiden Skripte bearbeiten die Einträge, die [source:trunk/schema/scripts/workflow/Filter_1_02_import_metadata.pl Filter_1_01_import_metadata] im raw text gemacht hat. Alle weiteren Skripte ändern den raw text gar nicht, sondern finden Stellen, die per Hand geändert werden müssen. Diese Änderungen werden soweit möglich am Anfang der Datei gemacht. Nur wenn es nicht anders geht, wird der Text selbst geändert. 85 86 Am Anfang der Datei sind folgende Gruppen erlaubt, in beliebiger Reihenfolge, jeweils durch eine Leerzeile getrennt, vor dem ersten {{{<pb>}}} (d.h. vor dem eigentlichen Text): 87 82 In diesem Arbeitsschritt wird der raw text auf die Umwandlung in XML vorbereitet. Die ersten beiden Skripte bearbeiten die Einträge, die [source:trunk/schema/scripts/workflow/Filter_1_02_import_metadata.pl Filter_1_01_import_metadata] im raw text gemacht hat. Alle weiteren Skripte ändern den raw text gar nicht, sondern finden Stellen, die per Hand geändert werden müssen. 83 84 Am Anfang der Datei sind folgende Blöcke erlaubt: 88 85 * {{{metadata:}}} (kopiert aus {{{index.meta}}} in Schritt 1.02, korrigiert in Schrtt 2.01, aufgelöst in Schritt 3.05) 89 86 * {{{pageimg:}}} (kopiert aus {{{pageimg/}}} in Schritt 1.02, aufgelöst bereits in Schritt 2.02) … … 92 89 * {{{log:}}} (per Hand angelegt, immer wenn es nötig ist. Aufgelöst in Schritt 3.05, wo es in <dcterms:description> umgewandelt wird.) 93 90 94 Jeden Block kann es höchstens einmal geben. 95 96 Der Sinn der Aufteilung in Anlegen der Blöcke in Schritt 1 und 2 und Auflösen der Blöcke in Schritt 3 ist, dass man möglichst lange mit dem raw text arbeiten kann. Es soll außerdem möglichst lange nachvollziehbar bleiben, welche Änderungen an der aus China erhaltenen Version gemacht wurden. Erst in Schritt 5 wird die XML-Version des Textes ein Faktum an sich, das nicht mehr jederzeit neu aus dem raw text erzeugt werden kann. Idealerweise fällt das mit dem Beginn des scholarly workflow zusammen. 97 98 Es muss möglich sein, bereits im raw text korrektes XML zu verwenden, ohne dass die Skripte darüber stolpern. Beispielsweise muss man <div type="body"> einfügen können. Ein anderes Beispiel: Während der Bearbeitung fällt auf, dass ein Abschnitt auf italienisch ist. Das muss mit <p xlm:lang="it"> markiert werden können. 91 Jeden Block kann es höchstens einmal geben. Die Reihenfolge ist beliebig, aber alle Blöcke sind vor dem ersten {{{<pb>}}} (d.h. vor dem eigentlichen Text). 92 Die Blöcke werden jeweils durch eine Leerzeile voneinander getrennt. Änderungen am raw text werden soweit wie möglich mit Hilfe dieser Blöcke gemacht. Nur wenn es nicht anders geht, wird der Text selbst geändert. 93 94 Der Sinn der Aufteilung in Anlegen der Blöcke in Schritt 1 und 2 und Auflösen der Blöcke in Schritt 3 ist, dass man möglichst lange mit dem raw text arbeiten kann. Es soll außerdem möglichst einfach nachvollziehbar bleiben, welche Änderungen an der aus China erhaltenen Version gemacht wurden, ohne dass beispielsweise durch das Einfügen von <s> jede Zeile anders aussieht als in der originalen Transkription. Erst in Schritt 5 wird die XML-Version des Textes ein Faktum an sich, das nicht mehr jederzeit neu aus dem raw text erzeugt werden kann. Idealerweise fällt das mit dem Beginn des scholarly workflow zusammen. 95 96 Es muss möglich sein, bereits im raw text korrektes XML zu verwenden, ohne dass die Skripte darüber stolpern. Beispielsweise muss man {{{<div type="body">}}} einfügen können. Ein anderes Beispiel: Während der Bearbeitung fällt auf, dass ein Abschnitt auf italienisch ist. Das muss mit {{{<p xlm:lang="it">}}} markiert werden können. 99 97 100 98 … … 103 101 Das Skript [source:trunk/schema/scripts/workflow/Filter_2_01_additional_metadata.pl Filter_2_01_additional_metadata] bearbeitet die in Schritt 1.02 aus {{{index.meta}}} in den {{{metadata}}}-Block kopierten Metadaten. 104 102 105 Ich verwende für die Metadaten eine Kurzschreibweise. Vielleicht ersetze ich die aber auch wieder durch korrektes XML, sodass die Metadaten in Schritt 3.05 nur noch an die richtige Stelle kopiert werden müssen. Das XML aus index.meta muss allerdings auf alle Fälle an das Schema angepasst werden.103 Für die Metadaten eine Kurzschreibweise, die nicht XML ist. Vielleicht ersetze ich diese Kurzschreibweise aber auch wieder durch korrektes XML, sodass die Metadaten in Schritt 3.05 nur noch an die richtige Stelle kopiert werden müssen. Das XML aus index.meta muss allerdings auf alle Fälle an das Schema angepasst werden. 106 104 107 105 Bei Personen wird, falls bekannt, die GND eingefügt. Beispiel: … … 111 109 }}} 112 110 113 Unbekannte Personen werden in die GND-Datei eingetragen. Diese Datei kann mehrere Einträge für dieselbe PErson haben, nämlich einen Eintrag für jede bei uns vorkommende Schreibweise. Eventuell wird auch ein link eingefügt, mit dem man die GND prüfen kann, zum Beispiel [http://d-nb.info/gnd/118859676] für Benedetti. (Irgendwann könnte das durch ein interaktives tool passieren.)111 Unbekannte Personen werden von dem Skript in die GND-Datei eingetragen. Diese Datei kann mehrere Einträge für dieselbe Person haben, nämlich einen Eintrag für jede bei uns vorkommende Schreibweise. Für die unbekannte Person muss die GND per Hand nachgetragen werden. Eventuell wird auch ein link eingefügt, mit dem man die GND prüfen kann, zum Beispiel [http://d-nb.info/gnd/118859676] für Benedetti. (Irgendwann könnte das durch ein interaktives tool passieren.) 114 112 115 113 Außerdem fügt das Skript links zu ECHO ein, beispielsweise … … 127 125 ==== 2.02 pb's synchronisieren ==== 128 126 129 Das Skript [source:trunk/schema/scripts/workflow/Filter_2_02_sync_pb.pl Filter_2_02_sync_pb] schreibt die JPG-Dateinamen im {{{pageimg}}}-Block hinter die <pb> im Text. Die Zuordnung muss dann per Hand geprüft werden. Falls die Zuordnung nicht stimmt, müssen die Dateinamen korrigiert und das Skript wiederholt werden.127 Das Skript [source:trunk/schema/scripts/workflow/Filter_2_02_sync_pb.pl Filter_2_02_sync_pb] schreibt die JPG-Dateinamen im {{{pageimg}}}-Block hinter die <pb> im Text. Die Zuordnung muss dann per Hand geprüft werden. Falls die Zuordnung nicht stimmt, müssen die Dateinamen im {{{pageimg}}}-Block korrigiert und das Skript wiederholt werden. 130 128 131 129 Das Skript macht also Änderungen im ganzen Dokument, zum Beispiel: … … 133 131 <pb 25>[0037] 134 132 }}} 135 Da die Zu rdnung des Textes auf die SeitenVoraussetzung für das Arbeiten mit dem Text ist, wird der {{{pageimg}}}-Block im Gegensatz zu den anderen Blöcken bereits hier aufgelöst.133 Da die Zuordnung der Textseiten zu den JPGs Voraussetzung für das Arbeiten mit dem Text ist, wird der {{{pageimg}}}-Block im Gegensatz zu den anderen Blöcken bereits hier aufgelöst. 136 134 137 135 Entferne außerdem Dateinamen wie zzzz.jpg … … 144 142 erstellt eine Liste verbotener Zeichen und Uncode-Blöcke im Text, bei einzelnen Zeichen mit Korrekturvorschlag. Beispiele: 145 143 146 * ɩ („latin small letter iota“) aus dem Unicode-Block „IPA Extension“ anstelle von „dotless i“. Der ganze Block „IPA Extension“ ist verboten, aber bei den anderen Zeichen gibt es keinen automatischen Korr keturvorschlag.144 * ɩ („latin small letter iota“) aus dem Unicode-Block „IPA Extension“ anstelle von „dotless i“. Der ganze Block „IPA Extension“ ist verboten, aber bei den anderen Zeichen gibt es keinen automatischen Korrekturvorschlag. 147 145 * ÿ statt ij in kursivem Text (Beispiel für ein sprachabhängiges Zeichen: Zum Beispiel im Französischen kann ÿ [http://de.wikipedia.org/wiki/Ÿ vorkommen].) 148 146 * „substitute“ (U+001A) … … 150 148 * Zeichen, die in den Skripten intern verwendet werden: ¤, ¥. (Diese Währungszeichen als reservierte Zeichen wurden ausgewählt, weil sie in alten Texten wahrscheinlich nicht vorkommen, aber in vielen modernen Fonts verfügbar sind.) 151 149 152 Soweit wie möglich sollten die Korrekturen im {{{replacements}}}-Block am Anfang des Textes stehen. Einzelfälle können aber auch direkt im Text korrigiert werden. Beispiel: Ein einzelnes {{{Hinɔ}}} wird zu {{{Hinc}}}.150 Soweit wie möglich sollten die Korrekturen im {{{replacements}}}-Block am Anfang des Textes stehen. Der {{{replacements:}}}-Block wird in Schritt 3.02 aufgelöst. Einzelfälle können aber auch direkt im Text korrigiert werden. Beispiel: Ein einzelnes {{{Hinɔ}}} wird zu {{{Hinc}}}. 153 151 154 152 Eventuell wird das Skript noch von einer Blacklist von Unicode-Blöcken auf eine Whitelist umgestellt. 155 156 Der {{{replacements:}}}-Block wird in Schritt 3.02 aufgelöst.157 153 158 154 … … 202 198 prüft ein paar Fälle, die nicht vorkommen sollten und auf Fehler bei der Transkription hindeuten. Der Sinn dieser Prüfung ist auch, dass sich die weiteren Skripte auf die Einhaltung dieser formalen Dinge verlassen können. 203 199 204 * {{{<h>}}}, {{{<mgl>}}}, {{{<mgr>}}}, {{{<fig>}}} jeweils nicht in allein in einer Zeile, bei {{{<pb>}}} nur noch {{{<rh>}}} erlaubt 200 * {{{<h>}}}, {{{<mgl>}}}, {{{<mgr>}}} jeweils am Anfang einer Zeile 201 * {{{</h>}}}, {{{</mgl>}}}, {{{</mgr>}}} jeweils am ende einer Zeile 202 * {{{<tb>}}}, {{{<fig>}}} auf eigener Zeile 203 * bei {{{<pb>}}} ist nur noch {{{<rh>}}} erlaubt 205 204 * nicht-existente Elemente, wie z.B. in {{{<scG</sc>}}}, oder auch {{{<sup>9</sup>}}} statt {{{<^>9</^>}}} (aber siehe unten) 206 205 * verschachtelte {{{<p>}}} (vermutlich ein {{{<p>}}} zuviel), und entsprechend für {{{<h>}}} etc. … … 209 208 * zusammengehörende Tags wie {{{<rh>}}} und {{{</rh>}}} sind nicht in der gleichen Zeile 210 209 211 Die letzten Punkte sind noch nicht vollständig umgesetzt, aber das Skript funktioniert in der Praxis schon sehr gut.212 213 210 Wie bei Schritt 2.03 muss man jeweils entscheiden, ob eine Korrektur im Text selbst gemacht wird oder in den {{{replacements}}}-Block geschrieben wird. Beispiel: 214 211 {{{ … … 217 214 }}} 218 215 219 Bei den Dingen, die in diesem Schritt geprüft werden, kann man unterscheiden in echte Fehler, die das Skript nicht korrigieren kann, und falsche Formatierungen, die das Skript selbst korrigieren könnte. Beispielsweise könnte das Skript selbst ein return einfügen, wenn <tb> nicht auf einer eigenen Zeile steht. Aber zum Beispiel gibt es in den DESpecs die Regel, dass eine heading <h> auf eigener Zeile stehen muss, ein running head <rh> dagegen auf der gleichen Zeile wie das zugehörige <pb>. Wenn dies nicht beachtet wurde, ist meistens nicht klar gewesen, ob eine Textzeile eine Überschrift oder ein running head ist. Aufgrund von solchen Fällenverändert das Skript den Text nicht selbst. (Es könnte allerdings regexes vorschlagen, die der User verwenden kann.)216 Bei den Dingen, die in diesem Schritt geprüft werden, kann man unterscheiden in echte Fehler, die das Skript nicht korrigieren kann, und falsche Formatierungen, die das Skript selbst korrigieren könnte. Beispielsweise könnte das Skript selbst ein return einfügen, wenn <tb> nicht auf einer eigenen Zeile steht. Aber zum Beispiel gibt es in den DESpecs die Regel, dass eine heading <h> auf eigener Zeile stehen muss, ein running head <rh> dagegen auf der gleichen Zeile wie das zugehörige <pb>. Wenn dies nicht beachtet wurde, ist meistens nicht klar gewesen, ob eine Textzeile eine Überschrift oder ein running head ist. Damit hier keine Information verschwindet, verändert das Skript den Text nicht selbst. (Es könnte allerdings regexes vorschlagen, die der User verwenden kann.) 220 217 221 218 Das Skript ignoriert alles vor dem ersten <pb>. … … 239 236 ==== 2.09 prüfe tables ==== 240 237 241 Das Skript [source:trunk/schema/scripts/workflow/Filter_2_09_check_tables.pl Filter_2_09_check_tables] prüft die "syntaktische Korrektheit" und die Plausibilität der tables. Was das genau bedeutet, ist noch nicht ganz klar. (Es wird jedenfalls nicht geprüft, ob die Tabelle das Original korrekt wiedergibt.) Es ist auch noch nicht ganz klar, wie eventuelle Korrekturen in den raw text geschrieben werden, d.h. ob sie in der Syntax der DESpecs hineingeschrieben werden oder schon als xhtml. Wenn als xhtml, muss es von den folgenden Skripten ignoriert werden. In beiden Formenmuss es in Schritt 4.02 aus dem Absatz herausgezogen werden.238 Das Skript [source:trunk/schema/scripts/workflow/Filter_2_09_check_tables.pl Filter_2_09_check_tables] prüft die "syntaktische Korrektheit" und die Plausibilität der tables. Was das genau bedeutet, ist noch nicht ganz klar. (Es wird jedenfalls nicht geprüft, ob die Tabelle das Original korrekt wiedergibt.) Es ist auch noch nicht ganz klar, wie eventuelle Korrekturen in den raw text geschrieben werden, d.h. ob sie in der Syntax der DESpecs hineingeschrieben werden oder schon als xhtml. Wenn als xhtml, muss es von den folgenden Skripten ignoriert werden. In jedem Fall muss es in Schritt 4.02 aus dem Absatz herausgezogen werden. 242 239 243 240 … … 247 244 {{{ 248 245 replacements: 249 --] < (i.e. "--]" becomes "<"; see p.0018 and "DESpecs_special_batch3.pdf" 246 --] < (i.e. "--]" becomes "<"; see p.0018 and "DESpecs_special_batch3.pdf") 250 247 [-- > 251 248 }}} 252 (Schöner wäre es, wenn die entsprechende Zeichen durch Unicode-Mathematik-Zeichen angenähert werden könnten und die modernen Zeichen erst in der MathML-Formel verwendet werden. Leider gibt es diese Zeichen so nicht in Unicode. Der Umgang mit veralteter mathematischer Notation ist noch nicht vollständig geklärt. )253 254 Aber zum Beispiel die Special Instructions für die Tabellen am Ende von Berzelius 1819 könnten mit einem Skript weiterverarbeitet werden.249 (Schöner wäre es, wenn die entsprechende Zeichen durch Unicode-Mathematik-Zeichen angenähert werden könnten und die modernen Zeichen erst in der MathML-Formel verwendet werden. Leider gibt es diese Zeichen so nicht in Unicode. Der Umgang mit veralteter mathematischer Notation ist noch nicht vollständig geklärt. Alternative wäre wie bei Alchemie-Symbolen ein Bild; ist das bei Büchern mit vielen Formeln realistisch?) 250 251 Zum Beispiel die Special Instructions für die Tabellen am Ende von Berzelius 1819 könnten dagegen mit einem Skript weiterverarbeitet werden. 255 252 256 253 257 254 === 3. Schritte bis zu wohlgeformtem xml === 258 255 259 Diese Skripte in diesem Arbeitsschritt sollten problemlos durchlaufen und können daher in einem Meta-Skript [source:trunk/schema/scripts/workflow/Filter_3_make_wellformed.pl Filter_3_make_wellformed] zusammengefasst werden. 260 261 Das Skript [source:trunk/schema/scripts/workflow/Filter_3_test_wellformedness.pl Filter_3_test_wellformedness] 256 Diese Skripte in diesem Arbeitsschritt sollten problemlos durchlaufen und können daher in einem Meta-Skript [source:trunk/schema/scripts/workflow/Filter_3_make_wellformed.pl Filter_3_make_wellformed] zusammengefasst werden. Das Skript [source:trunk/schema/scripts/workflow/Filter_3_test_wellformedness.pl Filter_3_test_wellformedness] 262 257 prüft anschließend, ob das Ergebnis wohlgeformt ist. (Dieses Skript ist zurzeit ein Wrapper für xmllint. Ich werde es wahrscheinlich noch auf ein Perl-Modul statt xmllint umstellen.) 263 258 … … 267 262 ==== 3.01 ersetze unknown characters ==== 268 263 269 Das Skript [source:trunk/schema/scripts/workflow/Filter_3_01_replace_unknown_characters.pl Filter_3_01_replace_unknown_characters] ersetzt die Zeichen aus dem {{{unknown}}}-Block. 270 271 Das Skript zur Ersetzung der escape sequences (Schritt 3.03) kann sich darauf verlassen, dass die unknown characters bereits geändert wurden. Das ist wichtig für Fälle wie {{{\'<001>}}}. 264 Das Skript [source:trunk/schema/scripts/workflow/Filter_3_01_replace_unknown_characters.pl Filter_3_01_replace_unknown_characters] ersetzt die Zeichen aus dem {{{unknown}}}-Block. Das Skript zur Ersetzung der escape sequences (Schritt 3.03) kann sich darauf verlassen, dass die unknown characters bereits geändert wurden. Das ist wichtig für Fälle wie {{{\'<001>}}}. 272 265 273 266 … … 328 321 === 4. schema-konform machen === 329 322 330 Wie in Schritt 3 sollten diese Skripte problemlos durchlaufen und können daher in einem Meta-Skript [source:trunk/schema/scripts/workflow/Filter_4_make_valid.pl Filter_4_make_valid] zusammengefasst werden. 331 332 Das Skript [source:trunk/schema/scripts/workflow/Filter_4_test_validity.pl Filter_4_test_validity] test dann, ob das Ergebnis schemakonform ist. (Dieses Skript ist ein Wrapper für Jing, das die eigentliche Validierung macht.) 323 Wie in Schritt 3 sollten diese Skripte problemlos durchlaufen und können daher in einem Meta-Skript [source:trunk/schema/scripts/workflow/Filter_4_make_valid.pl Filter_4_make_valid] zusammengefasst werden. Das Skript [source:trunk/schema/scripts/workflow/Filter_4_test_validity.pl Filter_4_test_validity] test dann, ob das Ergebnis schemakonform ist. (Dieses Skript ist ein Wrapper für Jing, das die eigentliche Validierung macht.) 333 324 334 325 Eine Ausnahme für das problemlose Durchlaufen kann das Skript für <s> sein. … … 339 330 ==== 4.01 <pb> ==== 340 331 341 Das Skript [source:trunk/schema/scripts/workflow/Filter_4_01_pb.pl Filter_4_01_pb] verwandelt {{{<rh>}}} in ein Attribut {{{rhead}}} in {{{<pb>}}}. 342 343 Alle Formatierungen wie kursiv, gesperrt, Fettdruck etc. im running head werden entfernt, weil es recht sicher ist, dass sie semantisch irrelevant sind. Die grundsätzliche Frage, wie genau wir die originale Textgestalt wiedergeben wollen, selbst wenn sie offensichtlich semantisch nicht relevant ist, haben wir allerdings noch nicht genau geklärt. 332 Das Skript [source:trunk/schema/scripts/workflow/Filter_4_01_pb.pl Filter_4_01_pb] verwandelt {{{<rh>}}} in ein Attribut {{{rhead}}} in {{{<pb>}}}. Alle Formatierungen wie kursiv, gesperrt, Fettdruck etc. im running head werden entfernt, weil es recht sicher ist, dass sie semantisch irrelevant sind. Die grundsätzliche Frage, wie genau wir die originale Textgestalt wiedergeben wollen, selbst wenn sie offensichtlich semantisch nicht relevant ist, haben wir allerdings noch nicht genau geklärt. 344 333 345 334 346 335 ==== 4.02 floats herausziehen ==== 347 336 348 Das Skript [source:trunk/schema/scripts/workflow/Filter_4_02_move_floats.pl Filter_4_02_move_floats] zieht Floats aus Absätzen heraus: An der ursprünglichen Stelle wird {{{<anchor>}}} eingefügt, und al e Floats eines Absatzes kommen in ein {{{<div type="float">}}} direkt nach dem Absatz. Dadurch bleiben die Floats im Text in der richtigen Reihenfolge.349 350 Das Kriterium in den DESpecs, wo die Floats zu tippen sind, ist recht krude. Daher ist eine minimale Nachbereitung sinnvoll. Zum Beispiel sollte ein Float stillschweigend aus dem Absatz geschoben werden, wenn nur eine einzige Textzeile davor oder danach ist.Da dies automatisch geschehen kann, wird es nicht schon in Schritt 2 gemacht.337 Das Skript [source:trunk/schema/scripts/workflow/Filter_4_02_move_floats.pl Filter_4_02_move_floats] zieht Floats aus Absätzen heraus: An der ursprünglichen Stelle wird {{{<anchor>}}} eingefügt, und alle Floats eines Absatzes kommen in ein {{{<div type="float">}}} direkt nach dem Absatz. Dadurch bleiben die Floats im Text in der richtigen Reihenfolge. 338 339 Das Kriterium in den DESpecs, wo die Floats zu tippen sind, ist recht krude. Daher ist eine minimale Nachbereitung sinnvoll. Zum Beispiel wird ein Float stillschweigend aus dem Absatz geschoben, wenn nur eine einzige Textzeile davor oder danach ist. (Als Folge können allerdings Marginalien, die sich auf einen Absatz beziehen, im xml formal vor oder nach dem Absatz stehen.) Da dies automatisch geschehen kann, wird es nicht schon in Schritt 2 gemacht. 351 340 352 341 * Vorsicht bei anchored marginal notes. … … 357 346 ==== 4.03 <lb> ==== 358 347 359 Das Skript [source:trunk/schema/scripts/workflow/Filter_4_03_insert_lb.pl Filter_4_03_insert_lb] verwandelt Zeilenumbrüche in <lb/>. Das ist normalerweise geradlinig. Beachte Ausnahmen bei <pb> und <anchor>. 360 361 Als Effekt wird die Zeilenanzahl des Textes sehr viel kleiner. 348 Das Skript [source:trunk/schema/scripts/workflow/Filter_4_03_insert_lb.pl Filter_4_03_insert_lb] verwandelt Zeilenumbrüche in <lb/>. Das ist normalerweise geradlinig. Beachte Ausnahmen bei <pb> und <anchor>. Als Effekt des Skriptes wird die Zeilenanzahl des Textes sehr viel kleiner. 362 349 363 350 364 351 ==== 4.04 <s> ==== 365 352 366 Das Skript [source:trunk/schema/scripts/workflow/Filter_4_04_insert_s.pl Filter_4_04_insert_s] fügt <s> ein. 367 368 Bei diesem Skript kann man bestimmte Parameter wählen, um bessere <s> zu erhalten. Trotzdem kann es manchmal passieren, dass man zum raw text zurückkehren muss und dort bei manchen Punkten manuell markieren muss, ob es eine Satzende ist oder nicht. Das können einzelne Punkte sein, wo es sich wahrscheinlich nur in Ausnahmefällen lohnen wird, oder wiederkehrende Situationen wie eine nicht erkannte Abkürzung. Details und die Syntax dafür habe ich mir noch nicht überlegt. 353 Das Skript [source:trunk/schema/scripts/workflow/Filter_4_04_insert_s.pl Filter_4_04_insert_s] fügt <s> ein. Bei diesem Skript kann man bestimmte Parameter wählen, um bessere <s> zu erhalten. Trotzdem kann es manchmal passieren, dass man zum raw text zurückkehren muss und dort bei manchen Punkten manuell markieren muss, ob es eine Satzende ist oder nicht. Das können einzelne Punkte sein, wo es sich wahrscheinlich nur in Ausnahmefällen lohnen wird, oder wiederkehrende Situationen wie eine nicht erkannte Abkürzung. Details und die Syntax dafür habe ich mir noch nicht überlegt. 369 354 370 355 Beachte Fälle wie: … … 412 397 ==== 4.06 tables ==== 413 398 414 Das Skript [source:trunk/schema/scripts/workflow/Filter_4_06_tables.pl Filter_4_06_tables], das in Schritt 2.09 vorbereitet wurde, verwandelt die Tabellen-Syntax der DESpecs in gültiges xhtml. 415 416 Wie schon in Schritt 2.09 wird hier nicht geprüft, ob die Tabelle tatsächlich dem Original nahekommt. Dies passiert erst im scholarly workflow. 399 Das Skript [source:trunk/schema/scripts/workflow/Filter_4_06_tables.pl Filter_4_06_tables], das in Schritt 2.09 vorbereitet wurde, verwandelt die Tabellen-Syntax der DESpecs in gültiges xhtml. Wie schon in Schritt 2.09 wird auch hier nicht geprüft, ob die Tabelle tatsächlich dem Original nahekommt. Dies passiert erst im scholarly workflow. 417 400 418 401 Beachte die unterschiedlichen Anweisungen in den DESpecs 1.1.2 und 2.0. … … 421 404 ==== 4.07 <div> ==== 422 405 423 Das Skript [source:trunk/schema/scripts/workflow/Filter_4_07_insert_div.pl Filter_4_07_insert_div] fügt eine simple <div>-Struktur in den Text ein, indem es bei jeder <head>-Gruppe ein <div> beginnen lässt. Dadurch bekommt der Text ein rudimentäres Inhaltsverzeichnis. (Dieser Schritt ist nicht wirklich nötig für einen schemakonformen , aber man bekommt esquasi geschenkt.)424 425 * Automatisch erstellte {{{<div>}}} sind alle auf demselben level. Für eine hierarchische <div>-Struktur muss die automatische <div>-Struktur per Hand nachbearbeitet werden.406 Das Skript [source:trunk/schema/scripts/workflow/Filter_4_07_insert_div.pl Filter_4_07_insert_div] fügt eine simple <div>-Struktur in den Text ein, indem es bei jeder <head>-Gruppe ein <div> beginnen lässt. Dadurch bekommt der Text ein rudimentäres Inhaltsverzeichnis. (Dieser Schritt ist nicht wirklich nötig für einen schemakonformen Text, aber man bekommt die <div>-Struktur quasi geschenkt.) 407 408 * Automatisch erstellte {{{<div>}}} sind alle auf demselben level. Für eine hierarchische <div>-Struktur (z.B. mit front, body, back) muss die automatische <div>-Struktur per Hand nachbearbeitet werden. 426 409 * {{{n}}} und {{{level}}} werden mit {{{n="0"}}} und {{{level="0"}}} gefüllt und erst im Schritt 5.06 korrekt durchnumeriert. 427 410 * Korrigiere <div> (automatisch?) bei den {{{<head>}}}, die eigentlich Footer sind. … … 437 420 Hier gibt es einen Einschnitt im workflow: Der schemakonforme xml-Text wird bearbeitet. Es ist dann nicht mehr möglich, einfach zum raw text zurückzukehren und alle Bearbeitungsschritte noch einmal zu machen. Dies fällt, wie schon in Schritt 2 gesagt, idealerweise mit dem Beginn des scholarly workflow zusammen. 438 421 439 Die Nummern dieser Skripte in diesem Schritt können sich noch ändern. Legt die Hierarchie der inline-Elemente (z.B. <var> in plaintext, <ref> im inline model) eine Verarbeitungsreihenfolge nahe?422 Die Nummern dieser Skripte in diesem Schritt können sich noch ändern. Die Hierarchie der inline-Elemente (z.B. <var> in plaintext, <ref> im inline model) legt vermutlich noch keine Verarbeitungsreihenfolge nahe. 440 423 441 424 442 425 ==== 5.01 <reg> ==== 443 426 444 Das Skript [source:trunk/schema/scripts/workflow/Filter_5_01_insert_reg.pl Filter_5_01_insert_reg] regularisiert den Text. Für eine ausführlichere Diskussion von <reg> siehe [wiki:regularisierung hier]. Wie beim <s>-Skript kann man hier einige Parameter wählen. D etailsstehen noch nicht fest.427 Das Skript [source:trunk/schema/scripts/workflow/Filter_5_01_insert_reg.pl Filter_5_01_insert_reg] regularisiert den Text. Für eine ausführlichere Diskussion von <reg> siehe [wiki:regularisierung hier]. Wie beim <s>-Skript kann man hier einige Parameter wählen. Die Details der Parameter stehen noch nicht fest. 445 428 446 429 Kein Zeichen, das normalisiert werden soll, darf hinterher noch im Text (außerhalb von {{{<reg>}}}) sein, zum Beispiel kein Zeichen mit Tilde (mit Ausnahmen in manchen Sprachen). Für !Latein/Benedetti: … … 462 445 ==== 5.02 <var> ==== 463 446 464 Das Skript [source:trunk/schema/scripts/workflow/Filter_5_02_insert_var.pl Filter_5_02_insert_var] fügt <var> um Variablen ein. Ein Ziel ist, den Inhalt vor der morphologischen Analyse zu verbergen. Eventuell hat dieses Skript ebenfalls Parameter, nämlich wie Variablen im Text aussehen (zum Beispiel {{{AB}}} versus {{{.a.b.}}}). 465 466 {{{<emph>}}} in Variablen wird wie bei running heads entfernt: Ob der Setzer ein K in upright shape oder in italics gewählt hat, ist egal. 447 Das Skript [source:trunk/schema/scripts/workflow/Filter_5_02_insert_var.pl Filter_5_02_insert_var] fügt <var> um Variablen ein. Ein Ziel ist, den Inhalt vor der morphologischen Analyse zu verbergen. Eventuell hat dieses Skript ebenfalls Parameter, nämlich wie Variablen im Text aussehen (zum Beispiel „{{{AB}}}“ versus „{{{.a.b.}}}“). {{{<emph>}}} in Variablen wird wie bei running heads entfernt: Ob der Setzer ein K in upright shape oder in italics gewählt hat, ist egal. 467 448 468 449 Für das Skript gibt es einen [source:trunk/schema/scripts/script-tests/var-testparcours.txt testparcours]. … … 471 452 ==== 5.03 <num> ==== 472 453 473 Das Skript [source:trunk/schema/scripts/workflow/Filter_5_03_insert_num.pl Filter_5_03_insert_num] fügt <num> um Zahlen ein, die nicht in der in modernen westlichen Texten üblichen Weise geschrieben sind. Ein Ziel ist wieder, den Inhalt vor der morphologischen Analyse zu verbergen. 454 Das Skript [source:trunk/schema/scripts/workflow/Filter_5_03_insert_num.pl Filter_5_03_insert_num] fügt <num> um Zahlen ein, die nicht in der in modernen westlichen Texten üblichen Weise geschrieben sind. Ein Ziel ist wieder, den Inhalt vor der morphologischen Analyse zu verbergen. Beispiel: {{{<num value="0.5">½</num>}}}. 474 455 475 456 (Verwende das Skript {{{Filter_roman_numbers.pl}}}: <num value="..."> für römische Zahlen.) … … 483 464 ==== 5.05 <foreign> ==== 484 465 485 Das Skript [source:trunk/schema/scripts/workflow/Filter_5_05_insert_foreign.pl Filter_5_05_insert_foreign] soll fremdsprachliche Textstellen markieren. 486 487 Füge {{{<foreign xml:lang="el">}}} zumindest für griechischen Text (erkennbar an den verwendeten Zeichen) ein. Durch eine minimale linguistische Analyse des Textes kann man wohl auch weitere fremdsprachliche Textstücke korrekt erkennen. 466 Das Skript [source:trunk/schema/scripts/workflow/Filter_5_05_insert_foreign.pl Filter_5_05_insert_foreign] soll fremdsprachliche Textstellen markieren. Füge zumindest für griechischen Text (erkennbar an den verwendeten Zeichen) {{{<foreign xml:lang="el">}}} ein. Durch eine minimale linguistische Analyse des Textes kann man auch weitere fremdsprachliche Textstücke korrekt erkennen. 488 467 489 468 490 469 ==== 5.06 div-Attribute ==== 491 470 492 Das Skript [source:trunk/schema/scripts/workflow/Filter_5_06_number_divs.pl Filter_5_06_number_divs] numeriert die Attribute {{{<div level="." n=".">}}} korrekt durch. (Das Skript ist ein Wrapper für das xslt-Skript {{{number-divs.xsl}}}, das die eigentliche Arbeit macht.)471 Das Skript [source:trunk/schema/scripts/workflow/Filter_5_06_number_divs.pl Filter_5_06_number_divs] numeriert die Attribute {{{<div level="." n=".">}}} korrekt durch. (Das Skript ist ein Wrapper für das XSLT-Skript {{{number-divs.xsl}}}, das die eigentliche Arbeit macht.) 493 472 494 473 Es muss möglich sein, bereits im raw text korrektes XML zu verwenden, ohne dass die Skripte darüber stolpern. Beispielsweise muss man <div type="body"> einfügen können (beachte: dann sollte auch der type in <text> geändert werden). Braucht man dazu ein tool, oder geht das so? Was ist die Verbindung zum <div>-Skript? Braucht man ein tool zur manuellen Nachbearbeitung der automatisch erstellten <div>? … … 512 491 Brauchen wir ein allgemeines Test-Skript? Zum Beispiel kann es nach Anwenden eines Skriptes zwei Spaces hintereinander geben. Das muss kein Fehler des Skriptes sein, aber es deutet auf ein Problem hin. 513 492 514 Ein möglicher Gesamt-Test für einen sorgfältig annotierten Text: Keine Punkte mehr im Text, die nicht515 * Satzende-Punkte sind({{{<s>Bla bla bla. </s>}}})516 * in einem Tag verschwinden({{{<ref>ex .7. quinti Eucl.</ref>}}})517 * zu einer Zahl gehören({{{.11.}}})493 Ein möglicher Gesamt-Test für einen sorgfältig annotierten Text: Alle Punkte im Text gehören zu einer der folgenden Kategorien: 494 * Satzende-Punkte ({{{<s>Bla bla bla. </s>}}}) 495 * in einem Tag ({{{<ref>ex .7. quinti Eucl.</ref>}}}) 496 * bei einer Zahl ({{{.11.}}}) 518 497 519 498 … … 536 515 === Anmerkungen === 537 516 538 Das Grundgerüst für alle Filter ist 539 [source:trunk/schema/scripts/workflow/Filter_template.pl dieses template]. 540 541 Figures nachbearbeiten; beachte DESpecs 1.1.2 versus 2.0 542 543 Filter_punctuation.pl: Das Skript zur Normalisierung der Interpunktion habe ich vorläufig weggelassen, weil es vermutlich merkwürdige Nebenwirkungen hat. Zum Beispiel spaces vor „:“ weg. (Hier ist die Frage, ob wir Information verlieren, die wir gerne konservieren würden. Beispiel „EPISTOL AE“). Ziel ist wieder, dass sich die folgenden Skripte auf ein einheitliches Format verlassen können. Beispielsweise müsste das reg-Skript, das unter anderem {{{q;}}} durch {{{que}}} ersetzt, nicht noch prüfen, ob es {{{q ;}}} gibt. 544 545 Filter_Archimedes_to_ECHO.pl: Dieses Skript habe ich für die Umwandlung von Song Yingxing verwendet. Für europäische Texte müsste es überarbeitet werden. 517 * Das Grundgerüst für die Skripte ist [source:trunk/schema/scripts/workflow/Filter_template.pl dieses template]. 518 519 * Figures nachbearbeiten und ausschneiden: beachte DESpecs 1.1.2 versus 2.0 520 521 * Das Skript zur Normalisierung der Interpunktion (Filter_punctuation.pl) habe ich vorläufig weggelassen, weil es vermutlich merkwürdige Nebenwirkungen hat. Zum Beispiel spaces vor „:“ weg. (Hier ist die Frage, ob wir Information verlieren, die wir gerne konservieren würden. Beispiel „EPISTOL AE“). Ziel ist wieder, dass sich die folgenden Skripte auf ein einheitliches Format verlassen können. Beispielsweise müsste das reg-Skript, das unter anderem {{{q;}}} durch {{{que}}} ersetzt, nicht noch prüfen, ob es {{{q ;}}} gibt. 522 523 * Filter_Archimedes_to_ECHO.pl: Dieses Skript habe ich für die Umwandlung von Song Yingxing verwendet. Für europäische Texte müsste es überarbeitet werden. 546 524 547 525 … … 553 531 * lateinische Zeichen können durch ihre full-width-Version ersetzt sein, zum Beispiel „?“ durch „?“ 554 532 * Wort- und Satzgrenzen markieren (bzw. andersrum: invisible spaces innerhalb von Wörtern entfernen) 555 * Nach der Definition in Schritt 5.03 müsste man chinesische Zahlen in chinesischen Texten mit <num> markieren. Ist das tatsächlich sinnvoll? Es gibt jedenfalls ein älteres Skript für Euclid 1966, um beide Schreibweisen in westliche Zahlen umzuwandeln:533 * Nach der Definition in Schritt 5.03 müsste man chinesische Zahlen in chinesischen Texten mit <num> markieren. Ist das tatsächlich sinnvoll? Es gibt jedenfalls ein älteres Skript für Euclid 1966, das beide Schreibweisen in westliche Zahlen umzuwandelt: 556 534 {{{ 557 535 <num value="301">三〇一</num>