Changes between Version 23 and Version 24 of workflow


Ignore:
Timestamp:
May 25, 2010, 4:03:46 PM (14 years ago)
Author:
Wolfgang Schmidle
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • workflow

    v23 v24  
    2020
    2121Die 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.
    2323
    2424  * Im Gegensatz zu den früheren Skripten dürfen die hier beschriebenen Bearbeitungsschritte die Zeilenstruktur verändern, zum Beispiel eine Zeile hinzufügen.
    2525  * 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.
    2826
    2927
     
    3230In diesem Schritt werden alle Vorbereitungen getroffen, um mit dem raw text arbeiten zu können. Insbesondere werden Verzeichnisse angelegt und Dateien kopiert.
    3331
    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.
    3532  * 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}}}.
    3734
    3835
    3936==== 1.01 Von Pythia ins svn-repository ====
    4037
    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.
     38Das 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. 
    4239
    4340  * Im [source:trunk/texts Texte-Verzeichnis] Unterverzeichnisse anlegen (allerdings nerven die raw/xml-Verzeichnisse in der Praxis)
    4441  * 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).
    4643
    4744(Shell-Skript von Klaus)
    4845
     46Im 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
    4948
    5049==== 1.02 Kommunikation mit Foxridge ====
     
    5453Erstelle eine lokale Kopie der entsprechenden index.meta-Datei (funktioniert nur innerhalb des Instituts):
    5554{{{
    56 http://content.mpiwg-berlin.mpg.de/mpiwg/online/permanent/archimedes_repository/large/catan_belli_502_la_1600/index.meta
    5755http://content.mpiwg-berlin.mpg.de/mpiwg/online/permanent/library/2UZM8E2N/index.meta
    5856}}}
     
    8280=== 2. raw text bearbeiten ===
    8381
    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 
     82In 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
     84Am Anfang der Datei sind folgende Blöcke erlaubt:
    8885  * {{{metadata:}}} (kopiert aus {{{index.meta}}} in Schritt 1.02, korrigiert in Schrtt 2.01, aufgelöst in Schritt 3.05)
    8986  * {{{pageimg:}}} (kopiert aus {{{pageimg/}}} in Schritt 1.02, aufgelöst bereits in Schritt 2.02)
     
    9289  * {{{log:}}} (per Hand angelegt, immer wenn es nötig ist. Aufgelöst in Schritt 3.05, wo es in <dcterms:description> umgewandelt wird.)
    9390
    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.
     91Jeden 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).
     92Die 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
     94Der 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
     96Es 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.
    9997
    10098
     
    103101Das 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.
    104102
    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.
     103Fü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.
    106104
    107105Bei Personen wird, falls bekannt, die GND eingefügt. Beispiel:
     
    111109}}}
    112110
    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.)
     111Unbekannte 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.)
    114112
    115113Außerdem fügt das Skript links zu ECHO ein, beispielsweise
     
    127125==== 2.02 pb's synchronisieren ====
    128126
    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.
     127Das 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.
    130128
    131129Das Skript macht also Änderungen im ganzen Dokument, zum Beispiel:
     
    133131<pb 25>[0037]
    134132}}}
    135 Da die Zurdnung des Textes auf die Seiten Voraussetzung für das Arbeiten mit dem Text ist, wird der {{{pageimg}}}-Block im Gegensatz zu den anderen Blöcken bereits hier aufgelöst.
     133Da 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.
    136134
    137135Entferne außerdem Dateinamen wie zzzz.jpg
     
    144142erstellt eine Liste verbotener Zeichen und Uncode-Blöcke im Text, bei einzelnen Zeichen mit Korrekturvorschlag. Beispiele:
    145143
    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 Korrketurvorschlag.
     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.
    147145  * ÿ statt ij in kursivem Text (Beispiel für ein sprachabhängiges Zeichen: Zum Beispiel im Französischen kann ÿ [http://de.wikipedia.org/wiki/Ÿ vorkommen].)
    148146  * „substitute“ (U+001A)
     
    150148  * 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.)
    151149
    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}}}.
     150Soweit 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}}}.
    153151
    154152Eventuell 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.
    157153
    158154
     
    202198prü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.
    203199
    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
    205204  * nicht-existente Elemente, wie z.B. in {{{<scG</sc>}}}, oder auch {{{<sup>9</sup>}}} statt {{{<^>9</^>}}} (aber siehe unten)
    206205  * verschachtelte {{{<p>}}} (vermutlich ein {{{<p>}}} zuviel), und entsprechend für {{{<h>}}} etc.
     
    209208  * zusammengehörende Tags wie {{{<rh>}}} und {{{</rh>}}} sind nicht in der gleichen Zeile
    210209
    211 Die letzten Punkte sind noch nicht vollständig umgesetzt, aber das Skript funktioniert in der Praxis schon sehr gut.
    212 
    213210Wie bei Schritt 2.03 muss man jeweils entscheiden, ob eine Korrektur im Text selbst gemacht wird oder in den {{{replacements}}}-Block geschrieben wird. Beispiel:
    214211{{{
     
    217214}}}
    218215
    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ällen verändert das Skript den Text nicht selbst. (Es könnte allerdings regexes vorschlagen, die der User verwenden kann.)
     216Bei 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.)
    220217
    221218Das Skript ignoriert alles vor dem ersten <pb>.
     
    239236==== 2.09 prüfe tables ====
    240237
    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 Formen muss es in Schritt 4.02 aus dem Absatz herausgezogen werden.
     238Das 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.
    242239
    243240
     
    247244{{{
    248245replacements:
    249 --] &lt; (i.e. "--]" becomes "<"; see p.0018 and "DESpecs_special_batch3.pdf"
     246--] &lt; (i.e. "--]" becomes "<"; see p.0018 and "DESpecs_special_batch3.pdf")
    250247[-- &gt;
    251248}}}
    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
     251Zum Beispiel die Special Instructions für die Tabellen am Ende von Berzelius 1819 könnten dagegen mit einem Skript weiterverarbeitet werden.
    255252
    256253
    257254=== 3. Schritte bis zu wohlgeformtem xml ===
    258255
    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]
     256Diese 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]
    262257prü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.)
    263258
     
    267262==== 3.01 ersetze unknown characters ====
    268263
    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>}}}.
     264Das 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>}}}.
    272265
    273266
     
    328321=== 4. schema-konform machen ===
    329322
    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.)
     323Wie 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.)
    333324
    334325Eine Ausnahme für das problemlose Durchlaufen kann das Skript für <s> sein.
     
    339330==== 4.01 <pb> ====
    340331
    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.
     332Das 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.
    344333
    345334
    346335==== 4.02 floats herausziehen ====
    347336
    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 ale 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.
     337Das 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
     339Das 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.
    351340
    352341  * Vorsicht bei anchored marginal notes.
     
    357346==== 4.03 <lb> ====
    358347
    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.
     348Das 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.
    362349
    363350
    364351==== 4.04 <s> ====
    365352
    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.
     353Das 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.
    369354
    370355Beachte Fälle wie:
     
    412397==== 4.06 tables ====
    413398
    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.
     399Das 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.
    417400
    418401Beachte die unterschiedlichen Anweisungen in den DESpecs 1.1.2 und 2.0.
     
    421404==== 4.07 <div> ====
    422405
    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 es quasi 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.
     406Das 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.
    426409  * {{{n}}} und {{{level}}} werden mit {{{n="0"}}} und {{{level="0"}}} gefüllt und erst im Schritt 5.06 korrekt durchnumeriert.
    427410  * Korrigiere <div> (automatisch?) bei den {{{<head>}}}, die eigentlich Footer sind.
     
    437420Hier 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.
    438421
    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?
     422Die 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.
    440423
    441424
    442425==== 5.01 <reg> ====
    443426
    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. Details stehen noch nicht fest.
     427Das 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.
    445428
    446429Kein 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:
     
    462445==== 5.02 <var> ====
    463446
    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.
     447Das 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.
    467448
    468449Für das Skript gibt es einen [source:trunk/schema/scripts/script-tests/var-testparcours.txt testparcours].
     
    471452==== 5.03 <num> ====
    472453
    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.
     454Das 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>}}}.
    474455
    475456(Verwende das Skript {{{Filter_roman_numbers.pl}}}: <num value="..."> für römische Zahlen.)
     
    483464==== 5.05 <foreign> ====
    484465
    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.
     466Das 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.
    488467
    489468
    490469==== 5.06 div-Attribute ====
    491470
    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.)
     471Das 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.)
    493472
    494473Es 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>?
     
    512491Brauchen 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.
    513492
    514 Ein möglicher Gesamt-Test für einen sorgfältig annotierten Text: Keine Punkte mehr im Text, die nicht
    515   * 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.}}})
     493Ein 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.}}})
    518497
    519498
     
    536515=== Anmerkungen ===
    537516
    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.
    546524
    547525
     
    553531  * lateinische Zeichen können durch ihre full-width-Version ersetzt sein, zum Beispiel „?“ durch „?“
    554532  * 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:
    556534{{{
    557535<num value="301">三〇一</num>