}}} * {{{<year>}}} * {{{<lang>}}} ([http://de.wikipedia.org/wiki/ISO_639 ISO 639-1], d.h. zweistellig) * (bisher noch nicht: {{{<publisher>}}}, {{{<city>}}}, {{{<number_of_pages>}}}, {{{<translator>}}}) Finde den pageimg-Unterordner (default ist {{{pageimg/}}}) und schreibe die JPG-Dateinamen in den {{{pageimg}}}-Block in den raw text. Änderungen in index.meta: * index.meta neu formatieren. * Wenn <texttool> noch nicht vorhanden ist, anlegen. * Pageimg und figures anlegen, aber unverändert lassen, wenn es sie schon gibt. * text-url-path anlegen: Sprache aus z.B. {{{<lang>it</lang>}}}. Das Skript meldet sich nicht bei Foxridge an. Die Änderungen in index.meta werden daher nur in der lokalen Kopie gemacht. Es fehlt also: * Sicherheitskopie von index.meta anlegen (auch lokal?): Umbenennen von index.meta in index.meta.old, eine ältere Sicherheitskopie mit demselben Namen wird ohne Nachfrage überschrieben. * Schreibe die neue index.meta (Die Trennung der Schritte „Vorbereitung“ und „raw text bearbeiten“ wird nicht vollkommen eingehalten, denn dieses Skript schreibt bereits Daten in den raw text.) === 2. raw text bearbeiten === In diesem Arbeitsschritt wird der raw text auf die Umwandlung in XML vorbereitet. Änderungen werden soweit möglich am Anfang der Datei gemacht. Nur wenn es nicht anders geht, wird der Text selbst geändert. 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): * {{{metadata:}}} * {{{pageimg:}}} (wird aber gleich wieder verarbeitet) * {{{unknown:}}} * {{{replacements:}}} (per Hand; könnte man noch aufteilen in forbidden, escape sequences, special instructions; aber bringt das mehr Klarheit?) * {{{log:}}} (per Hand) (Alle in getrennte Dateien? Oder ist das dann auch wieder übertrieben? Getrennte Datei doof für Skripte, weil sie die Datei dann finden müssen? Also doch gleich in den raw text?) 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. ==== 2.01 Metadaten ==== Skript zur Korrektur der Metadaten aus index.meta: [source:trunk/schema/scripts/workflow/Filter_2_01_additional_metadata.pl Filter_2_01_additional_metadata] „metadata:“ ergänze dann den Rest per Hand * Metadaten: Können vollständig aus der index.meta gewonnen werden, in dem entsprechenden Verzeichnis. Da sollte auch die GND eingefügt werden (siehe mein Hashtable, vielleicht sollte man noch eine interaktive Abfrage einbauen, in der der Benutzer noch zu {{{http://d-nb.info/gnd/$GND}}} surfen kann, ob das auch der richtige Typ ist.). ⟶ am Anfang: dcterms:creator (GND:118859676) Aristoteles Klaus: Für Convenience einen Link zu ECHO am Anfang der Datei, beispielsweise {{{ http://echo.mpiwg-berlin.mpg.de/ECHOdocuView/ECHOzogiLib?mode=imagepath&url=/mpiwg/online/permanent/library/163127KK/pageimg http://mpdl-proto.mpiwg-berlin.mpg.de/mpdl/page-query-result.xql?document=/echo/la/Benedetti_1585.xml http://echotest.mpiwg-berlin.mpg.de/content/historymechanics/Echo/163127KK }}} ==== 2.02 pb's synchronisieren ==== [source:trunk/schema/scripts/workflow/Filter_2_02_sync_pb.pl Filter_2_02_sync_pb] „pageimg:“ (wird aber im Gegensatz zu den anderen „bla:“ sofort verwurstelt) ⟶ im ganzen Dokument (nicht zu vermeiden): <pb>![001] neu: das Skript kann sich darauf verlassen, dass die Dateinamen schon im raw text stehen. entferne zzzz.jpg ==== 2.03 ersetze verbotene Zeichen im Text ==== Das Skript [source:trunk/schema/scripts/workflow/Filter_2_03_find_forbidden_characters.pl Filter_2_03_find_forbidden_characters] erstellt eine Liste verbotener Zeichen und Uncode-Blöcke im Text, bei einzelnen Zeichen mit Korrekturvorschlag. Beispiele: * ɩ („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. * ÿ statt ij in kursivem Text * „substitute“ (U+001A) * zwei spaces hintereinander * Zeichen, die in den Skripten intern verwendet werden: ¤, ¥. (Diese Währungszeichen als reservierte Zeichen wurden ausgewählt, weil sie in alten Texte wahrscheinlich nicht vorkommen, aber in vielen modernen Fonts verfügbar sind.) 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: {{{Hinɔ}}} wird {{{Hinc}}} Eventuell wird das Skript noch von einer Blacklist von Unicode-Blöcken auf eine Whitelist umgestellt. ==== 2.04 prüfe unknown characters ==== [source:trunk/schema/scripts/workflow/Filter_2_04_check_unknown_characters.pl Filter_2_04_check_unknown_characters] „unknown:“ ⟶ am Anfang: {{{<002> ꝑ (p.28: ok)}}} sollte die codes auch schon in die Datei schreiben, damit man sie nicht rüberkopieren muss ==== 2.05 prüfe escape sequences ==== Das Skript [source:trunk/schema/scripts/workflow/Filter_2_05_check_escape_sequences.pl Filter_2_05_check_escape_sequences] ruft intern erst [source:trunk/schema/scripts/workflow/Filter_3_01_replace_unknown_characters.pl Filter_3_01_replace_unknown_characters] auf und prüft dann, wo danach noch folgende Zeichen im Text sind: { \ Man muss dann jeweils entscheiden, ob diese geschweiften Klammern etc. in Ordnung sind oder nicht. Beispiel: Im Text wird die idiosynkratische Notation {ta} für eine Ligatur in kursiver Schrift verwendet. Im {{{replacements}}}-Block: {{{{ta} ta (vorläufig!)}}} ==== 2.06 prüfe italics ==== [source:trunk/schema/scripts/workflow/Filter_2_06_check_underscores.pl Filter_2_06_check_underscores] {{{_ _}}} werden erst in Schritt 3.04 in <it> verwandelt, aber hier wird bereits geprüft, ob es Probleme geben wird (bzw. die Fehler werden per Hand korrigiert) ==== 2.07 prüfe tags ==== Das Skript [source:trunk/schema/scripts/workflow/Filter_2_07_check_tags.pl Filter_2_07_check_tags] 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. * {{{<h>}}}, {{{<mgl>}}}, {{{<mgr>}}}, {{{<fig>}}} jeweils nicht in allein in einer Zeile, bei {{{<pb>}}} nur noch {{{<rh>}}} erlaubt * nicht-existente Elemente, wie z.B. in {{{<scG</sc>}}}, oder auch {{{<sup>9</sup>}}} statt {{{<^>9</^>}}} (aber siehe unten) * verschachtelte {{{<p>}}} (vermutlich ein {{{<p>}}} zuviel), und entsprechend für {{{<h>}}} etc. * {{{</p>}}} ohne vorhergehendes {{{<p>}}}, und entsprechend für {{{<h>}}} etc. * zusammengehörende Tags wie {{{<p>}}} und {{{</p>}}} liegen sehr weit auseinander * zusammengehörende Tags wie {{{<rh>}}} und {{{</rh>}}} sind nicht in der gleichen Zeile (noch nicht vollständig umgesetzt, funktioniert aber in der Praxis schon sehr gut) ⟶ replacements zum Beispiel: << « (lines 41 to 43) ⟶ oder zum Beispiel im ganzen Dokument: heads <⟶ running heads, etc. --> das Skript sollte alles vor dem ersten <pb> ignorieren mit [source:trunk/schema/scripts/script-tests/check_tags-testparcours.txt testparcours] ==== 2.08 prüfe <s> ==== [source:trunk/schema/scripts/workflow/Filter_2_08_check_s.pl Filter_2_08_check_s] kann man hier das s-Skript aufrufen, oder kommt man dann durcheinander? ==== 2.09 prüfe tables ==== [source:trunk/schema/scripts/workflow/Filter_2_09_check_tables.pl Filter_2_09_check_tables] was immer das genau machen wird: prüfe die "syntaktische Korrektheit" der tables wie wird das in den raw text geschrieben? schon mit korrektem xhtml ist vielleicht etwas viel Aufwand. noch eine Zwischensprache, oder was ist da überhaupt zu tun? ==== 2.10 Special Instructions ==== [source:trunk/schema/scripts/workflow/Filter_2_10_special_instructions_for_xxxxxxxx Filter_2_10_special_instructions_for_xxxxxxxx] (bei manchen Texten wird es einfacher sein, es statt mit einem Skript per Hand zu machen) ⟶ am Anfang: {{{--] < (i.e. "--]" becomes "<"; see p.0018 and "DESpecs_special_batch3.pdf")}}} ⟶ auch im ganzen Dokument? === 3. Schritte bis zu wohlgeformtem xml === Diese Skripte in diesem Arbeitsschritt sollten problemlos durchlaufen und können in einem Meta-Skript zusammengefasst werden: [source:trunk/schema/scripts/workflow/Filter_3_make_wellformed.pl Filter_3_make_wellformed]. Das Skript [source:trunk/schema/scripts/workflow/Filter_3_test_wellformedness.pl Filter_3_test_wellformedness] prüft anschließend, ob das Ergebnis wohlgeformt ist. Wenn der Text wohlgeformtes XML ist, sollte man ihn mit Dateiendung in {{{xml}}} im Verzeichnis {{{xml/}}} statt {{{raw/}}} abspeichern. ==== 3.01 ersetze unknown characters ==== [source:trunk/schema/scripts/workflow/Filter_3_01_replace_unknown_characters.pl Filter_3_01_replace_unknown_characters] (vor escape sequences als garantierte Reihenfolge, bevor die escape sequences umgewandelt werden) ==== 3.02 ersetze replacements ==== [source:trunk/schema/scripts/workflow/Filter_3_02_replace_replacements.pl Filter_3_02_replace_replacements] (blöder Name!) (ebenfalls vor escape sequences: z.B. für Dinge wie {{{<< «}}}) siehe oben: könnte man noch aufteilen in forbidden, escape sequences, special instructions; aber bringt das mehr Klarheit? Wenn man es aufteilt, macht man eben drei Unter-Skripte. ==== 3.03 ersetze escape sequences ==== Das Skript [source:trunk/schema/scripts/workflow/Filter_3_03_replace_escape_sequences.pl Filter_3_03_replace_escape_sequences] löst alle escape sequences auf, sowie einige weitere Schreibweisen aus den DESpecs. * escape sequences: Beachte, dass {{{\'}}} (U+0027) im Text auch als {{{\’}}} (U+2019) geschrieben sein kann. * Beachte auch: {{{\-}}} wird hier zu einem combining macron, weil es so im transkribierten Text steht. Später wird das in den meisten Fällen zu einer Tilde korrigiert, weil das Makron normalerweise eine falsche Transkription einer Tilde ist. Genauso ist {{{\,e}}} in den meisten Fällen in Wirklichkeit {{{ę}}}, wird aber hier zu {{{ȩ}}}. * Löse {{{$}}} auf * Zeichen, die wir absichtlich nicht in die Specs aufgenommen haben, zum Beispiel {{{<^>9</^>}}} für ꝰ (modifier letter us, U+A770) * löse {{{{ }}}} auf: {{{{ij}}}} auf zu {{{ĳ}}} (später stillschweigend zu {{{ij}}}), {{{{ae}}}} zu {{{ę}}} * zum Schluss: Unicode-Normalform [http://unicode.org/reports/tr15/ NRC] ==== 3.04 ersetze italics ==== [source:trunk/schema/scripts/workflow/Filter_3_04_replace_underscores.pl Filter_3_04_replace_underscores] Ersetze {{{_ _}}} für {{{style="it"}}}. Diese Ersetzung ist nicht Teil des emph-Skriptes, weil sie vor <s> passieren sollte und in Schritt 1 bereits vorbereitet wurde. ==== 3.05 Metadaten, root element ==== Das Skript [source:trunk/schema/scripts/workflow/Filter_3_05_add_basic_xml.pl Filter_3_05_add_basic_xml] ergänzt {{{<?xml version="1.0" encoding="UTF-8"?>}}}, und fügt das root element {{{<echo>}}} sowie {{{<metadata>}}} und {{{<text type="free">}}} ein. auch: log wird zu {{{<dcterms:description>}}} ==== 3.06 wohlgeformtes xml ==== [source:trunk/schema/scripts/workflow/Filter_3_06_make_tags_wellformed.pl Filter_3_06_make_tags_wellformed] * reservierte Zeichen in XML: {{{&}}} wird zu {{{&}}}. Das Skript kann mehrere Male aufgerufen werden, es wird also aus {{{&}}} nicht {{{&}}}. * Attribute: {{{<... it>}}} wird zu {{{<... style="it">}}}, genauso für {{{fr}}} * ändere die Element-Namen der DESpecs in ihre Gegenstücke im ECHO Schema. Konzeptionell gibt es mehrere Teile: 1. ergänze „{{{/}}}“ in den ungeschlossenen Elementen wie {{{<pb>}}} und {{{<hd>}}}, 2. korrigiere verbotene Element-Namen wie {{{<^>}}}, 3. benenne die Elemente so, wie sie im Schema heißen. === 4. schema-konform machen === wieder: Diese Skripte sollten problemlos durchlaufen und können in einem Meta-Skript zusammengefasst werden: [source:trunk/schema/scripts/workflow/Filter_4_make_valid.pl Filter_4_make_valid] Außerdem: [source:trunk/schema/scripts/workflow/Filter_4_test_validity.pl Filter_4_test_validity] * [source:trunk/schema/scripts/workflow/Filter_4_00_Schummelskript.pl Filter_4_00_Schummelskript] (solange die Tabellen noch nicht richtig verarbeitet werden) ==== 4.01 <pb> ==== [source:trunk/schema/scripts/workflow/Filter_4_01_pb.pl Filter_4_01_pb] verwandle {{{<rh>}}} in ein Attribut {{{rhead}}} in {{{<pb>}}}, ignoriere dabei alle Formatierungen wie kursiv, gesperrt, etc. ==== 4.02 floats herausziehen ==== [source:trunk/schema/scripts/workflow/Filter_4_02_move_floats.pl Filter_4_02_move_floats] (auch tables!) auch aus <h>, oder lieber Fehler provozieren? Floats aus Absätzen herausziehen (vor "{{{<s>}}} bestimmen" !):{{{<anchor>}}}, {{{<div type="float">}}} nach dem Absatz. Vorsicht bei anchored marginal notes. Prüfe bei anchors im Text, ob es eine zugehörige note gibt. Akzeptiere kleine Abweichungen der Symbole voneinander, zum Beispiel {{{3)}}} im Text und {{{3}}} in der Fußnote ==== 4.03 <lb> ==== Das Skript [source:trunk/schema/scripts/workflow/Filter_4_03_insert_lb.pl Filter_4_03_insert_lb] verwandelt Zeilenumbrüche in <lb/>. ==== 4.04 <s> ==== Das Skript [source:trunk/schema/scripts/workflow/Filter_4_04_insert_s.pl Filter_4_04_insert_s] fügt <s> ein. Beachte Fälle wie: * et.a.b.hoc est * .a.b:c.d:e.f. * .{{{<lb/>}}}a.b. * Wort-Abkürzungen (hier wäre es einerseits hilfreich, wenn Wortabkürzungen bereits in {{{<reg>}}} wären; andererseits wird der Punkt am Ende von {{{<reg>}}} zum Beispiel in {{{ex .7. quinti <reg>Eucl.</reg>}}} oft noch als Satzendepunkt gebraucht) * {{{&c.}}} etc. (eventuell mit Parameter-Wahl; eventuelle manuelle Korrekturen im raw text!) ==== 4.05 <emph> ==== [source:trunk/schema/scripts/workflow/Filter_4_05_emph.pl Filter_4_05_emph] Ersetze Fomatierungs-Elemente durch {{{<emph style="...">}}}. Denke an {{{<sub>}}} und {{{<super>}}}. Verschiebe style-Informationen so wie wie möglich nach oben im xml, zum Beispiel \\ {{{<p><emph style="it">text</emph>.</p>}}} wird zu \\ {{{<p style="it">text.</p>}}}. Anderes Beispiel: \\ {{{<mgl>_eine kur-_<lb/>_ze Notiz._</mgl>}}} mit [source:trunk/schema/scripts/script-tests/emph-testparcours.txt testparcours] ==== 4.06 tables ==== [source:trunk/schema/scripts/workflow/Filter_4_06_tables.pl Filter_4_06_tables] wann werden die tables bearbeitet? zwei Schritte: überhaupt syntaktisch korrekt, und dann größtmögliche Annäherung an das Original (erst im scholarly workflow). beachte DESpecs 1.1.2 versus 2.0 ==== 4.07 <div> ==== [source:trunk/schema/scripts/workflow/Filter_4_07_insert_div.pl Filter_4_07_insert_div] {{{<div>}}}-Struktur für das Inhaltsverzeichnis erstellen: Erstmal {{{<div>}}} von einer {{{<head>}}}-Gruppe bis zum nächsten. Automatisch erstellte {{{<div>}}} sind alle auf demselben level. {{{n}}} und {{{level}}} werden mit {{{n="0"}}} und {{{level="0"}}} gefüllt. Korrigiere anschließend (automatisch?) bei den {{{<head>}}}, die eigentlich Footer sind. (Dieser Schritt ist nicht wirklich nötig für einen schemakonformen, aber man bekommt es quasi geschenkt.) ==== 4.08 Formatieren ==== Wenn der Text schemakonform ist, kann man ihn neu formatieren. Es müssen keine Zeilen umgebrochen werden, sondern nur die Anzahl der Leerzeichen am Anfang normalisiert werden. === 5. weitere Schritte === 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. Die Nummern dieser Skripte können sich noch ändern. Legt die Hierarchie der inline-Elemente (z.B. <var> in plaintext, <ref> im inline model) eine Verarbeitungsreihenfolge nahe? ==== 5.01 <reg> ==== [source:trunk/schema/scripts/workflow/Filter_5_01_insert_reg.pl Filter_5_01_insert_reg] (mit Parametern) Problem der Wort-Abkürzungen mit Kasus. Verwende dort {{{<ref>}}}, falls möglich. Test: 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: * Zeichen mit Tilde (ã ẽ ĩ õ ũ ñ) * combining tilde (insbesondere p̃ t̃ q̃ r̃) * combining acute (insbesondere q́) * medievalist characters: ꝑ ꝓ ꝗ ꝗ̃ ꝙ ꝰ  ́ ꝯ * weitere: ę ĺ * Apostroph: insbesondere wird ꝰ manchmal für {{{'}}} gehalten (in den Abschnitten in Benedetti mit {{{xml:lang="it"}}} bzw. {{{xml:lang="ita"}}} ist {{{'}}} dagegen erlaubt) mit [source:trunk/schema/scripts/script-tests/reg-testparcours.txt testparcours] ==== 5.02 <var> ==== [source:trunk/schema/scripts/workflow/Filter_5_02_insert_var.pl Filter_5_02_insert_var] (mit Parametern) Ziel: verberge den Inhalt vor der morphologischen Analyse Entferne {{{<emph>}}} in Variablen. mit [source:trunk/schema/scripts/script-tests/var-testparcours.txt testparcours] ==== 5.03 <num> ==== [source:trunk/schema/scripts/workflow/Filter_5_03_insert_num.pl Filter_5_03_insert_num] Ziel wieder: verberge den Inhalt vor der morphologischen Analyse [source:trunk/schema/scripts/workflow/Filter_roman_numbers.pl Filter_roman_numbers] (nicht im repository): <num value="..."> für römische Zahlen, wird eventuell Teil des num-Skriptes. ==== 5.04 Formeln ==== [source:trunk/schema/scripts/workflow/Filter_5_04_formulae.pl Filter_5_04_formulae] ? ==== 5.05 <foreign> ==== [source:trunk/schema/scripts/workflow/Filter_5_05_insert_foreign.pl Filter_5_05_insert_foreign] Füge {{{<foreign>}}} zumindest für griechischen Text (erkennbar an den verwendeten Zeichen) ein, und {{{xml:lang}}}. ==== 5.06 div-Attribute ==== [source:trunk/schema/scripts/workflow/Filter_5_06_number_divs.pl Filter_5_06_number_divs] 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>? ==== Abgleich mit Donatus ==== * Einfügen fehlender Bindestriche * Korrektur von fehlenden/überflüssigen Spaces * korrigiere Standardfehler wie fumptis, fint, bumanitate in kursiv ==== allgemeines Test-Skript ==== Allgemeines Test-Skript? z.B. gibt es nach Anwenden des Skript zwei Spaces hintereinander? Das muss kein Fehler des Skriptes sein, aber es deutet auf ein Problem hin. Gesamt-Test: Keine Punkte mehr im Text, die nicht * Satzende-Punkte sind ({{{<s>Bla bla bla. </s>}}}) * in einem Tag verschwinden ({{{<ref>ex .7. quinti Eucl.</ref>}}}) * zu einer Zahl gehören ({{{.11.}}}) === scholarly workflow === * ersetze {{{<wrong/>}}} durch {{{<sic/>}}} oder entferne es; löse {{{<unsure/>}}} auf * weitere {{{<reg>}}}, Korrekturen von bestehenden {{{<reg>}}} * {{{<ref>}}} * weitere {{{<foreign>}}} * entferne library stamps * „old-style numerals typed as letters“, zum Beispiel {{{ex .II.}}} statt {{{ex .11.}}}, aber auch andersherum: {{{10. BENEDETTI}}} statt {{{IO. BENEDETTI}}} * Wörter mit einzelne griechischen oder einzelnen lateinischen Buchstaben (automatisierbar?) * Wörter mit einzelnen Großbuchstaben mitten im Wort ({{{ClaZomenius}}}). Häufig ist die Ursache ein fehlendes Space vor dem Großbuchstaben. === Reste === [source:trunk/schema/scripts/workflow/Filter_template.pl Filter_template] Figures nachbearbeiten; beachte DESpecs 1.1.2 versus 2.0 IDs einfügen (es könnte ein Modul geben, in dem das {{{id}}}-Attribut gefordet wird, und das mit der Zwiebelstruktur in diesem Stadium in Aktion tritt. Dann müssen wir nicht in den usage guide schreiben: Es ist zwar formal optional, aber es sollte verwendet werden.) GIS: {{{<person>}}}, {{{<place>}}}, {{{<time>}}}, {{{<event>}}} [source:trunk/schema/scripts/workflow/Filter_punctuation.pl Filter_punctuation] (nicht im repository): 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. [source:trunk/schema/scripts/workflow/Filter_Archimedes_to_ECHO.pl Filter_Archimedes_to_ECHO] (nicht im repository): Dieses Skript habe ich für die Umwandlung von Song Yingxing verwendet. Für europäische Texte müsste es überarbeitet werden. [source:trunk/schema/scripts/workflow/Filter_4_04a_test_s.pl Filter_4_04a_test_s] ?? == Besonderheiten bei chinesischen Texten == Version 2.0.1 der chinesischen DESpecs ist [http://pythia.mpiwg-berlin.mpg.de/department1/mpdl/despecs/DESpecs_chinese.pdf/DESpecs_chinese_V3.pdf hier]. * beachte die in {{{echo-chinese-text}}} definierten Attribute * lateinische Zeichen können durch ihre full-width-Version ersetzt sein, zum Beispiel „?“ durch „？“ * verarbeite character variants automatisiert * verarbeite character variants im scholarly workflow so gut wie möglich. Beispielsweise würde \国 durch die Unicode-Zeichenfolge ⿴口玉 angenähert werden. * Wort- und Satzgrenzen markieren (bzw. andersrum: invisible spaces innerhalb von Wörtern entfernen) Wie der automatisierte Workflow für chinesische Texte aussehen wird, ist noch nicht völlig klar. Wenn zum Beispiel im Text <獘V> getippt wurde, kann man das automatisiert nur zu <reg norm="獘" type="V">獘</reg> mit vorläufigem Typ "V" machen, wo also das getippte Zeichen einfach wiederholt wird. Die Variante im Text kann dann nur eine studentische Hilfskraft anhand der von !ZhongYi erstellten Excel-Tabellen "herstellen". Ziel ist eine Zeichenfolge, die das Zeichen im Text beschreibt. Hier: ⿱敝大. Und dann: {{{ <reg norm="獘" type="simple"><image xlink:href="symbols/chinese/⿱敝大.svg"/></reg> }}} Wenn das Zeichen V,,1,, im Original eine Variante des Standardzeichens S ist, es aber in Unicode eine weitere Zeichenvariante V,,2,, von S gibt, die optisch näher an V,,1,, dran ist als S an V,,1,,, so sollen die Chinesen die Variante V,,2,, mit < V> tippen. Ein Beispiel ist <兾V> statt <冀V> in den [http://pythia.mpiwg-berlin.mpg.de/department1/mpdl/despecs/DESpecs_chinese.pdf/DESpecs_chinese_V3.pdf chinesischen DESpecs 2.0.1], p.10/11. Ziel ist dann: {{{ <reg norm="兾" type="simple"><image xlink:href="symbols/chinese/⿱𠂉異.svg"/></reg> }}} Das Herunterkochen von 兾 (V,,2,,) zu 冀 (S) sollte dann "von alleine" passieren. Allgemein: Was ist das Ziel, wenn die Chinesen eine Zeichenvariante (ohne < V>) getippt haben, die es in Unicode gibt? Soll die dann auch ein <reg> bekommen? Wer erkennt überhaupt, dass es sich um eine Variante handelt? Zumindest in der Theorie muss man das nicht regularisieren, und die Suche funktioniert von alleine richtig. Sollen wir umsteigen auf ein System, wo die Chinesen <001> tippen, und dann im Anhang eine IDS-Sequenz?

= XML Workflow = [[PageOutline(2-4,,pullout)]] Der automatische XML-Workflow besteht aus einer [source:trunk/schema/scripts/workflow Reihe von Skripten]. Einige dieser Skripte sind noch leere Platzhalter, aber die Workflow-Struktur stimmt bereits. Bisher sind 19 schema-konforme Texte bei ECHO, siehe [http://mpdl-proto.mpiwg-berlin.mpg.de/mpdl/attribute-query-result.xql?docbase=echo&query-type=browse&order-by=author&pn=1 mpdl-proto] und [http://echotest.mpiwg-berlin.mpg.de/content/historymechanics/Echo echotest]. Bis auf [http://mpdl-proto.mpiwg-berlin.mpg.de/mpdl/page-query-result.xql?document=/echo/la/Alvarus_1509.xml Alvarus], [http://mpdl-proto.mpiwg-berlin.mpg.de/mpdl/page-query-result.xql?document=/echo/la/Benedetti_1585.xml Benedetti 1585] und [http://mpdl-proto.mpiwg-berlin.mpg.de/mpdl/page-query-result.xql?document=/echo/zh/SongYingxing_1637.xml Song Yingxing] sind alle Texte mit den hier beschriebenen Workflow-Skripten erzeugt worden. == Die Arbeitsschritte == Der XML-Workflow besteht aus mehreren Arbeitsschritten. Im [#a1.Vorbereitungen ersten Schritt] werden alle Vorbereitungen getroffen, um mit dem raw text arbeiten zu können. Im [#a2.rawtextbearbeiten zweiten Schritt] wird der raw text korrigiert und annotiert. Im [#a3.Schrittebiszuwohlgeformtemxml dritten Schritt] wird der annotierte raw text in wohlgeformtes XML verwandelt. Im [#a4.schema-konformmachen vierten Schritt] wird der XML-Text schemakonform gemacht. Der dritte und der vierte Schritt laufen wietgehend automatisch ab. * Im Gegensatz zu den früheren Skripten dürfen die hier beschriebenen Bearbeitungsschritte die Zeilenstruktur verändern, zum Beispiel eine Zeile hinzufügen. * 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. * 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 {{{}}}-Skript sein. Die automatischen Skripte sollten soweit wie möglich in Meta-Skripten abrufbar sein. * 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. === 1. Vorbereitungen === In diesem Schritt werden alle Vorbereitungen getroffen, um mit dem raw text arbeiten zu können. Insbesondere werden Verzeichnisse angelegt und Dateien kopiert. * 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. * 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. * 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 zuerst nach Pythia kommen. Die Namenskonvention auf Pythia ist bisher Workorder_Autor_Jahr. ==== 1.01 Von Pythia ins svn-repository ==== 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. * Im [source:trunk/texts Texte-Verzeichnis] Unterverzeichnisse anlegen (allerdings nerven die raw/xml-Verzeichnisse in der Praxis) * Datei aus Pythia rüberkopieren * 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). (Skript von Klaus verwenden?) ==== 1.02 Kommunikation mit Foxridge ==== Das Skript [source:trunk/schema/scripts/workflow/Filter_1_02_import_metadata.pl Filter_1_01_import_metadata] kommuniziert mit Foxridge. Das Skript setzt voraus, dass der Identifier im Dateinamen steht. (Das Skript wird daher nicht mit legacy-Verzeichnissen funktionieren.) Erstelle eine lokale Kopie der entsprechenden index.meta-Datei (funktioniert nur innerhalb des Instituts): {{{ http://content.mpiwg-berlin.mpg.de/mpiwg/online/permanent/archimedes_repository/large/catan_belli_502_la_1600/index.meta http://content.mpiwg-berlin.mpg.de/mpiwg/online/permanent/library/2UZM8E2N/index.meta }}} Extrahiere daraus die Metadaten und schreibe sie in den {{{metadata}}}-Block in den raw text. Die Metadaten werden wörtlich übernommen, das Format wird erst in Schritt [#a2.01Metadaten 2.01] angepasst. Übernommen werden (jeweils in /): * {{{}}} * {{{}}} * {{{<year>}}} * {{{<lang>}}} ([http://de.wikipedia.org/wiki/ISO_639 ISO 639-1], d.h. zweistellig) * (bisher noch nicht: {{{<publisher>}}}, {{{<city>}}}, {{{<number_of_pages>}}}, {{{<translator>}}}) Finde den pageimg-Unterordner (default ist {{{pageimg/}}}) und schreibe die JPG-Dateinamen in den {{{pageimg}}}-Block in den raw text. Änderungen in index.meta: * index.meta neu formatieren. * Wenn <texttool> noch nicht vorhanden ist, anlegen. * Pageimg und figures anlegen, aber unverändert lassen, wenn es sie schon gibt. * text-url-path anlegen: Sprache aus z.B. {{{<lang>it</lang>}}}. Das Skript meldet sich nicht bei Foxridge an. Die Änderungen in index.meta werden daher nur in der lokalen Kopie gemacht. Es fehlt also: * Sicherheitskopie von index.meta anlegen (auch lokal?): Umbenennen von index.meta in index.meta.old, eine ältere Sicherheitskopie mit demselben Namen wird ohne Nachfrage überschrieben. * Schreibe die neue index.meta (Die Trennung der Schritte „Vorbereitung“ und „raw text bearbeiten“ wird nicht vollkommen eingehalten, denn dieses Skript schreibt bereits Daten in den raw text.) === 2. raw text bearbeiten === In diesem Arbeitsschritt wird der raw text auf die Umwandlung in XML vorbereitet. Änderungen werden soweit möglich am Anfang der Datei gemacht. Nur wenn es nicht anders geht, wird der Text selbst geändert. 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): * {{{metadata:}}} * {{{pageimg:}}} (wird aber gleich wieder verarbeitet) * {{{unknown:}}} * {{{replacements:}}} (per Hand; könnte man noch aufteilen in forbidden, escape sequences, special instructions; aber bringt das mehr Klarheit?) * {{{log:}}} (per Hand) (Alle in getrennte Dateien? Oder ist das dann auch wieder übertrieben? Getrennte Datei doof für Skripte, weil sie die Datei dann finden müssen? Also doch gleich in den raw text?) 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. ==== 2.01 Metadaten ==== Skript zur Korrektur der Metadaten aus index.meta: [source:trunk/schema/scripts/workflow/Filter_2_01_additional_metadata.pl Filter_2_01_additional_metadata] „metadata:“ ergänze dann den Rest per Hand * Metadaten: Können vollständig aus der index.meta gewonnen werden, in dem entsprechenden Verzeichnis. Da sollte auch die GND eingefügt werden (siehe mein Hashtable, vielleicht sollte man noch eine interaktive Abfrage einbauen, in der der Benutzer noch zu {{{http://d-nb.info/gnd/$GND}}} surfen kann, ob das auch der richtige Typ ist.). ⟶ am Anfang: dcterms:creator (GND:118859676) Aristoteles Klaus: Für Convenience einen Link zu ECHO am Anfang der Datei, beispielsweise {{{ http://echo.mpiwg-berlin.mpg.de/ECHOdocuView/ECHOzogiLib?mode=imagepath&url=/mpiwg/online/permanent/library/163127KK/pageimg http://mpdl-proto.mpiwg-berlin.mpg.de/mpdl/page-query-result.xql?document=/echo/la/Benedetti_1585.xml http://echotest.mpiwg-berlin.mpg.de/content/historymechanics/Echo/163127KK }}} ==== 2.02 pb's synchronisieren ==== [source:trunk/schema/scripts/workflow/Filter_2_02_sync_pb.pl Filter_2_02_sync_pb] „pageimg:“ (wird aber im Gegensatz zu den anderen „bla:“ sofort verwurstelt) ⟶ im ganzen Dokument (nicht zu vermeiden): <pb>![001] neu: das Skript kann sich darauf verlassen, dass die Dateinamen schon im raw text stehen. entferne zzzz.jpg ==== 2.03 ersetze verbotene Zeichen im Text ==== Das Skript [source:trunk/schema/scripts/workflow/Filter_2_03_find_forbidden_characters.pl Filter_2_03_find_forbidden_characters] erstellt eine Liste verbotener Zeichen und Uncode-Blöcke im Text, bei einzelnen Zeichen mit Korrekturvorschlag. Beispiele: * ɩ („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. * ÿ statt ij in kursivem Text * „substitute“ (U+001A) * zwei spaces hintereinander * Zeichen, die in den Skripten intern verwendet werden: ¤, ¥. (Diese Währungszeichen als reservierte Zeichen wurden ausgewählt, weil sie in alten Texte wahrscheinlich nicht vorkommen, aber in vielen modernen Fonts verfügbar sind.) 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: {{{Hinɔ}}} wird {{{Hinc}}} Eventuell wird das Skript noch von einer Blacklist von Unicode-Blöcken auf eine Whitelist umgestellt. ==== 2.04 prüfe unknown characters ==== [source:trunk/schema/scripts/workflow/Filter_2_04_check_unknown_characters.pl Filter_2_04_check_unknown_characters] „unknown:“ ⟶ am Anfang: {{{<002> ꝑ (p.28: ok)}}} sollte die codes auch schon in die Datei schreiben, damit man sie nicht rüberkopieren muss ==== 2.05 prüfe escape sequences ==== Das Skript [source:trunk/schema/scripts/workflow/Filter_2_05_check_escape_sequences.pl Filter_2_05_check_escape_sequences] ruft intern erst [source:trunk/schema/scripts/workflow/Filter_3_01_replace_unknown_characters.pl Filter_3_01_replace_unknown_characters] auf und prüft dann, wo danach noch folgende Zeichen im Text sind: { \ Man muss dann jeweils entscheiden, ob diese geschweiften Klammern etc. in Ordnung sind oder nicht. Beispiel: Im Text wird die idiosynkratische Notation {ta} für eine Ligatur in kursiver Schrift verwendet. Im {{{replacements}}}-Block: {{{{ta} ta (vorläufig!)}}} ==== 2.06 prüfe italics ==== [source:trunk/schema/scripts/workflow/Filter_2_06_check_underscores.pl Filter_2_06_check_underscores] {{{_ _}}} werden erst in Schritt 3.04 in <it> verwandelt, aber hier wird bereits geprüft, ob es Probleme geben wird (bzw. die Fehler werden per Hand korrigiert) ==== 2.07 prüfe tags ==== Das Skript [source:trunk/schema/scripts/workflow/Filter_2_07_check_tags.pl Filter_2_07_check_tags] 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. * {{{<h>}}}, {{{<mgl>}}}, {{{<mgr>}}}, {{{<fig>}}} jeweils nicht in allein in einer Zeile, bei {{{<pb>}}} nur noch {{{<rh>}}} erlaubt * nicht-existente Elemente, wie z.B. in {{{<scG</sc>}}}, oder auch {{{<sup>9</sup>}}} statt {{{<^>9</^>}}} (aber siehe unten) * verschachtelte {{{<p>}}} (vermutlich ein {{{<p>}}} zuviel), und entsprechend für {{{<h>}}} etc. * {{{</p>}}} ohne vorhergehendes {{{<p>}}}, und entsprechend für {{{<h>}}} etc. * zusammengehörende Tags wie {{{<p>}}} und {{{</p>}}} liegen sehr weit auseinander * zusammengehörende Tags wie {{{<rh>}}} und {{{</rh>}}} sind nicht in der gleichen Zeile (noch nicht vollständig umgesetzt, funktioniert aber in der Praxis schon sehr gut) ⟶ replacements zum Beispiel: << « (lines 41 to 43) ⟶ oder zum Beispiel im ganzen Dokument: heads <⟶ running heads, etc. --> das Skript sollte alles vor dem ersten <pb> ignorieren mit [source:trunk/schema/scripts/script-tests/check_tags-testparcours.txt testparcours] ==== 2.08 prüfe <s> ==== [source:trunk/schema/scripts/workflow/Filter_2_08_check_s.pl Filter_2_08_check_s] kann man hier das s-Skript aufrufen, oder kommt man dann durcheinander? ==== 2.09 prüfe tables ==== [source:trunk/schema/scripts/workflow/Filter_2_09_check_tables.pl Filter_2_09_check_tables] was immer das genau machen wird: prüfe die "syntaktische Korrektheit" der tables wie wird das in den raw text geschrieben? schon mit korrektem xhtml ist vielleicht etwas viel Aufwand. noch eine Zwischensprache, oder was ist da überhaupt zu tun? ==== 2.10 Special Instructions ==== [source:trunk/schema/scripts/workflow/Filter_2_10_special_instructions_for_xxxxxxxx Filter_2_10_special_instructions_for_xxxxxxxx] (bei manchen Texten wird es einfacher sein, es statt mit einem Skript per Hand zu machen) ⟶ am Anfang: {{{--] < (i.e. "--]" becomes "<"; see p.0018 and "DESpecs_special_batch3.pdf")}}} ⟶ auch im ganzen Dokument? === 3. Schritte bis zu wohlgeformtem xml === Diese Skripte in diesem Arbeitsschritt sollten problemlos durchlaufen und können in einem Meta-Skript zusammengefasst werden: [source:trunk/schema/scripts/workflow/Filter_3_make_wellformed.pl Filter_3_make_wellformed]. Das Skript [source:trunk/schema/scripts/workflow/Filter_3_test_wellformedness.pl Filter_3_test_wellformedness] prüft anschließend, ob das Ergebnis wohlgeformt ist. Wenn der Text wohlgeformtes XML ist, sollte man ihn mit Dateiendung in {{{xml}}} im Verzeichnis {{{xml/}}} statt {{{raw/}}} abspeichern. ==== 3.01 ersetze unknown characters ==== [source:trunk/schema/scripts/workflow/Filter_3_01_replace_unknown_characters.pl Filter_3_01_replace_unknown_characters] (vor escape sequences als garantierte Reihenfolge, bevor die escape sequences umgewandelt werden) ==== 3.02 ersetze replacements ==== [source:trunk/schema/scripts/workflow/Filter_3_02_replace_replacements.pl Filter_3_02_replace_replacements] (blöder Name!) (ebenfalls vor escape sequences: z.B. für Dinge wie {{{<< «}}}) siehe oben: könnte man noch aufteilen in forbidden, escape sequences, special instructions; aber bringt das mehr Klarheit? Wenn man es aufteilt, macht man eben drei Unter-Skripte. ==== 3.03 ersetze escape sequences ==== Das Skript [source:trunk/schema/scripts/workflow/Filter_3_03_replace_escape_sequences.pl Filter_3_03_replace_escape_sequences] löst alle escape sequences auf, sowie einige weitere Schreibweisen aus den DESpecs. * escape sequences: Beachte, dass {{{\'}}} (U+0027) im Text auch als {{{\’}}} (U+2019) geschrieben sein kann. * Beachte auch: {{{\-}}} wird hier zu einem combining macron, weil es so im transkribierten Text steht. Später wird das in den meisten Fällen zu einer Tilde korrigiert, weil das Makron normalerweise eine falsche Transkription einer Tilde ist. Genauso ist {{{\,e}}} in den meisten Fällen in Wirklichkeit {{{ę}}}, wird aber hier zu {{{ȩ}}}. * Löse {{{$}}} auf * Zeichen, die wir absichtlich nicht in die Specs aufgenommen haben, zum Beispiel {{{<^>9</^>}}} für ꝰ (modifier letter us, U+A770) * löse {{{{ }}}} auf: {{{{ij}}}} auf zu {{{ĳ}}} (später stillschweigend zu {{{ij}}}), {{{{ae}}}} zu {{{ę}}} * zum Schluss: Unicode-Normalform [http://unicode.org/reports/tr15/ NRC] ==== 3.04 ersetze italics ==== [source:trunk/schema/scripts/workflow/Filter_3_04_replace_underscores.pl Filter_3_04_replace_underscores] Ersetze {{{_ _}}} für {{{style="it"}}}. Diese Ersetzung ist nicht Teil des emph-Skriptes, weil sie vor <s> passieren sollte und in Schritt 1 bereits vorbereitet wurde. ==== 3.05 Metadaten, root element ==== Das Skript [source:trunk/schema/scripts/workflow/Filter_3_05_add_basic_xml.pl Filter_3_05_add_basic_xml] ergänzt {{{<?xml version="1.0" encoding="UTF-8"?>}}}, und fügt das root element {{{<echo>}}} sowie {{{<metadata>}}} und {{{<text type="free">}}} ein. auch: log wird zu {{{<dcterms:description>}}} ==== 3.06 wohlgeformtes xml ==== [source:trunk/schema/scripts/workflow/Filter_3_06_make_tags_wellformed.pl Filter_3_06_make_tags_wellformed] * reservierte Zeichen in XML: {{{&}}} wird zu {{{&}}}. Das Skript kann mehrere Male aufgerufen werden, es wird also aus {{{&}}} nicht {{{&}}}. * Attribute: {{{<... it>}}} wird zu {{{<... style="it">}}}, genauso für {{{fr}}} * ändere die Element-Namen der DESpecs in ihre Gegenstücke im ECHO Schema. Konzeptionell gibt es mehrere Teile: 1. ergänze „{{{/}}}“ in den ungeschlossenen Elementen wie {{{<pb>}}} und {{{<hd>}}}, 2. korrigiere verbotene Element-Namen wie {{{<^>}}}, 3. benenne die Elemente so, wie sie im Schema heißen. === 4. schema-konform machen === wieder: Diese Skripte sollten problemlos durchlaufen und können in einem Meta-Skript zusammengefasst werden: [source:trunk/schema/scripts/workflow/Filter_4_make_valid.pl Filter_4_make_valid] Außerdem: [source:trunk/schema/scripts/workflow/Filter_4_test_validity.pl Filter_4_test_validity] * [source:trunk/schema/scripts/workflow/Filter_4_00_Schummelskript.pl Filter_4_00_Schummelskript] (solange die Tabellen noch nicht richtig verarbeitet werden) ==== 4.01 <pb> ==== [source:trunk/schema/scripts/workflow/Filter_4_01_pb.pl Filter_4_01_pb] verwandle {{{<rh>}}} in ein Attribut {{{rhead}}} in {{{<pb>}}}, ignoriere dabei alle Formatierungen wie kursiv, gesperrt, etc. ==== 4.02 floats herausziehen ==== [source:trunk/schema/scripts/workflow/Filter_4_02_move_floats.pl Filter_4_02_move_floats] (auch tables!) auch aus <h>, oder lieber Fehler provozieren? Floats aus Absätzen herausziehen (vor "{{{<s>}}} bestimmen" !):{{{<anchor>}}}, {{{<div type="float">}}} nach dem Absatz. Vorsicht bei anchored marginal notes. Prüfe bei anchors im Text, ob es eine zugehörige note gibt. Akzeptiere kleine Abweichungen der Symbole voneinander, zum Beispiel {{{3)}}} im Text und {{{3}}} in der Fußnote ==== 4.03 <lb> ==== Das Skript [source:trunk/schema/scripts/workflow/Filter_4_03_insert_lb.pl Filter_4_03_insert_lb] verwandelt Zeilenumbrüche in <lb/>. ==== 4.04 <s> ==== Das Skript [source:trunk/schema/scripts/workflow/Filter_4_04_insert_s.pl Filter_4_04_insert_s] fügt <s> ein. Beachte Fälle wie: * et.a.b.hoc est * .a.b:c.d:e.f. * .{{{<lb/>}}}a.b. * Wort-Abkürzungen (hier wäre es einerseits hilfreich, wenn Wortabkürzungen bereits in {{{<reg>}}} wären; andererseits wird der Punkt am Ende von {{{<reg>}}} zum Beispiel in {{{ex .7. quinti <reg>Eucl.</reg>}}} oft noch als Satzendepunkt gebraucht) * {{{&c.}}} etc. (eventuell mit Parameter-Wahl; eventuelle manuelle Korrekturen im raw text!) ==== 4.05 <emph> ==== [source:trunk/schema/scripts/workflow/Filter_4_05_emph.pl Filter_4_05_emph] Ersetze Fomatierungs-Elemente durch {{{<emph style="...">}}}. Denke an {{{<sub>}}} und {{{<super>}}}. Verschiebe style-Informationen so wie wie möglich nach oben im xml, zum Beispiel \\ {{{<p><emph style="it">text</emph>.</p>}}} wird zu \\ {{{<p style="it">text.</p>}}}. Anderes Beispiel: \\ {{{<mgl>_eine kur-_<lb/>_ze Notiz._</mgl>}}} mit [source:trunk/schema/scripts/script-tests/emph-testparcours.txt testparcours] ==== 4.06 tables ==== [source:trunk/schema/scripts/workflow/Filter_4_06_tables.pl Filter_4_06_tables] wann werden die tables bearbeitet? zwei Schritte: überhaupt syntaktisch korrekt, und dann größtmögliche Annäherung an das Original (erst im scholarly workflow). beachte DESpecs 1.1.2 versus 2.0 ==== 4.07 <div> ==== [source:trunk/schema/scripts/workflow/Filter_4_07_insert_div.pl Filter_4_07_insert_div] {{{<div>}}}-Struktur für das Inhaltsverzeichnis erstellen: Erstmal {{{<div>}}} von einer {{{<head>}}}-Gruppe bis zum nächsten. Automatisch erstellte {{{<div>}}} sind alle auf demselben level. {{{n}}} und {{{level}}} werden mit {{{n="0"}}} und {{{level="0"}}} gefüllt. Korrigiere anschließend (automatisch?) bei den {{{<head>}}}, die eigentlich Footer sind. (Dieser Schritt ist nicht wirklich nötig für einen schemakonformen, aber man bekommt es quasi geschenkt.) ==== 4.08 Formatieren ==== Wenn der Text schemakonform ist, kann man ihn neu formatieren. Es müssen keine Zeilen umgebrochen werden, sondern nur die Anzahl der Leerzeichen am Anfang normalisiert werden. === 5. weitere Schritte === 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. Die Nummern dieser Skripte können sich noch ändern. Legt die Hierarchie der inline-Elemente (z.B. <var> in plaintext, <ref> im inline model) eine Verarbeitungsreihenfolge nahe? ==== 5.01 <reg> ==== [source:trunk/schema/scripts/workflow/Filter_5_01_insert_reg.pl Filter_5_01_insert_reg] (mit Parametern) Problem der Wort-Abkürzungen mit Kasus. Verwende dort {{{<ref>}}}, falls möglich. Test: 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: * Zeichen mit Tilde (ã ẽ ĩ õ ũ ñ) * combining tilde (insbesondere p̃ t̃ q̃ r̃) * combining acute (insbesondere q́) * medievalist characters: ꝑ ꝓ ꝗ ꝗ̃ ꝙ ꝰ  ́ ꝯ * weitere: ę ĺ * Apostroph: insbesondere wird ꝰ manchmal für {{{'}}} gehalten (in den Abschnitten in Benedetti mit {{{xml:lang="it"}}} bzw. {{{xml:lang="ita"}}} ist {{{'}}} dagegen erlaubt) mit [source:trunk/schema/scripts/script-tests/reg-testparcours.txt testparcours] ==== 5.02 <var> ==== [source:trunk/schema/scripts/workflow/Filter_5_02_insert_var.pl Filter_5_02_insert_var] (mit Parametern) Ziel: verberge den Inhalt vor der morphologischen Analyse Entferne {{{<emph>}}} in Variablen. mit [source:trunk/schema/scripts/script-tests/var-testparcours.txt testparcours] ==== 5.03 <num> ==== [source:trunk/schema/scripts/workflow/Filter_5_03_insert_num.pl Filter_5_03_insert_num] Ziel wieder: verberge den Inhalt vor der morphologischen Analyse [source:trunk/schema/scripts/workflow/Filter_roman_numbers.pl Filter_roman_numbers] (nicht im repository): <num value="..."> für römische Zahlen, wird eventuell Teil des num-Skriptes. ==== 5.04 Formeln ==== [source:trunk/schema/scripts/workflow/Filter_5_04_formulae.pl Filter_5_04_formulae] ? ==== 5.05 <foreign> ==== [source:trunk/schema/scripts/workflow/Filter_5_05_insert_foreign.pl Filter_5_05_insert_foreign] Füge {{{<foreign>}}} zumindest für griechischen Text (erkennbar an den verwendeten Zeichen) ein, und {{{xml:lang}}}. ==== 5.06 div-Attribute ==== [source:trunk/schema/scripts/workflow/Filter_5_06_number_divs.pl Filter_5_06_number_divs] 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>? ==== Abgleich mit Donatus ==== * Einfügen fehlender Bindestriche * Korrektur von fehlenden/überflüssigen Spaces * korrigiere Standardfehler wie fumptis, fint, bumanitate in kursiv ==== allgemeines Test-Skript ==== Allgemeines Test-Skript? z.B. gibt es nach Anwenden des Skript zwei Spaces hintereinander? Das muss kein Fehler des Skriptes sein, aber es deutet auf ein Problem hin. Gesamt-Test: Keine Punkte mehr im Text, die nicht * Satzende-Punkte sind ({{{<s>Bla bla bla. </s>}}}) * in einem Tag verschwinden ({{{<ref>ex .7. quinti Eucl.</ref>}}}) * zu einer Zahl gehören ({{{.11.}}}) === scholarly workflow === * ersetze {{{<wrong/>}}} durch {{{<sic/>}}} oder entferne es; löse {{{<unsure/>}}} auf * weitere {{{<reg>}}}, Korrekturen von bestehenden {{{<reg>}}} * {{{<ref>}}} * weitere {{{<foreign>}}} * entferne library stamps * „old-style numerals typed as letters“, zum Beispiel {{{ex .II.}}} statt {{{ex .11.}}}, aber auch andersherum: {{{10. BENEDETTI}}} statt {{{IO. BENEDETTI}}} * Wörter mit einzelne griechischen oder einzelnen lateinischen Buchstaben (automatisierbar?) * Wörter mit einzelnen Großbuchstaben mitten im Wort ({{{ClaZomenius}}}). Häufig ist die Ursache ein fehlendes Space vor dem Großbuchstaben. === Reste === [source:trunk/schema/scripts/workflow/Filter_template.pl Filter_template] Figures nachbearbeiten; beachte DESpecs 1.1.2 versus 2.0 IDs einfügen (es könnte ein Modul geben, in dem das {{{id}}}-Attribut gefordet wird, und das mit der Zwiebelstruktur in diesem Stadium in Aktion tritt. Dann müssen wir nicht in den usage guide schreiben: Es ist zwar formal optional, aber es sollte verwendet werden.) GIS: {{{<person>}}}, {{{<place>}}}, {{{<time>}}}, {{{<event>}}} [source:trunk/schema/scripts/workflow/Filter_punctuation.pl Filter_punctuation] (nicht im repository): 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. [source:trunk/schema/scripts/workflow/Filter_Archimedes_to_ECHO.pl Filter_Archimedes_to_ECHO] (nicht im repository): Dieses Skript habe ich für die Umwandlung von Song Yingxing verwendet. Für europäische Texte müsste es überarbeitet werden. [source:trunk/schema/scripts/workflow/Filter_4_04a_test_s.pl Filter_4_04a_test_s] ?? == Besonderheiten bei chinesischen Texten == Version 2.0.1 der chinesischen DESpecs ist [http://pythia.mpiwg-berlin.mpg.de/department1/mpdl/despecs/DESpecs_chinese.pdf/DESpecs_chinese_V3.pdf hier]. * beachte die in {{{echo-chinese-text}}} definierten Attribute * lateinische Zeichen können durch ihre full-width-Version ersetzt sein, zum Beispiel „?“ durch „？“ * verarbeite character variants automatisiert * verarbeite character variants im scholarly workflow so gut wie möglich. Beispielsweise würde \国 durch die Unicode-Zeichenfolge ⿴口玉 angenähert werden. * Wort- und Satzgrenzen markieren (bzw. andersrum: invisible spaces innerhalb von Wörtern entfernen) Wie der automatisierte Workflow für chinesische Texte aussehen wird, ist noch nicht völlig klar. Wenn zum Beispiel im Text <獘V> getippt wurde, kann man das automatisiert nur zu <reg norm="獘" type="V">獘</reg> mit vorläufigem Typ "V" machen, wo also das getippte Zeichen einfach wiederholt wird. Die Variante im Text kann dann nur eine studentische Hilfskraft anhand der von !ZhongYi erstellten Excel-Tabellen "herstellen". Ziel ist eine Zeichenfolge, die das Zeichen im Text beschreibt. Hier: ⿱敝大. Und dann: {{{ <reg norm="獘" type="simple"><image xlink:href="symbols/chinese/⿱敝大.svg"/></reg> }}} Wenn das Zeichen V,,1,, im Original eine Variante des Standardzeichens S ist, es aber in Unicode eine weitere Zeichenvariante V,,2,, von S gibt, die optisch näher an V,,1,, dran ist als S an V,,1,,, so sollen die Chinesen die Variante V,,2,, mit < V> tippen. Ein Beispiel ist <兾V> statt <冀V> in den [http://pythia.mpiwg-berlin.mpg.de/department1/mpdl/despecs/DESpecs_chinese.pdf/DESpecs_chinese_V3.pdf chinesischen DESpecs 2.0.1], p.10/11. Ziel ist dann: {{{ <reg norm="兾" type="simple"><image xlink:href="symbols/chinese/⿱𠂉異.svg"/></reg> }}} Das Herunterkochen von 兾 (V,,2,,) zu 冀 (S) sollte dann "von alleine" passieren. Allgemein: Was ist das Ziel, wenn die Chinesen eine Zeichenvariante (ohne < V>) getippt haben, die es in Unicode gibt? Soll die dann auch ein <reg> bekommen? Wer erkennt überhaupt, dass es sich um eine Variante handelt? Zumindest in der Theorie muss man das nicht regularisieren, und die Suche funktioniert von alleine richtig. Sollen wir umsteigen auf ein System, wo die Chinesen <001> tippen, und dann im Anhang eine IDS-Sequenz?