}}} * {{{<year>}}} * {{{<lang>}}} (ISO 639-1, d.h. zweistellig) * (bisher noch nicht: {{{<publisher>}}}, {{{<city>}}}, {{{<number_of_pages>}}}, {{{<translator>}}}) pageimg: geradlinig. Wenn es {{{<pageimg>}}} schon gibt, muss man im entsprechenden Verzeichnis nachschauen. Für texttool gibt es klare Regeln: 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>}}}. Lokale Kopie von index.meta? Besser xslt statt Perl? Vielleicht zwei Schritte, weil ich mich dabei wohler fühle: 1. reines Abholen der Datei z.B. {{{ 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 }}} (funktioniert nur mit einer internen IP-Adresse) 2. umbenennen der alten index.meta, schreiben der neuen. === raw text bearbeiten === Die Trennung von Vorbereitung und raw text bearbeiten kann man eventuell nicht klar aufrechterhalten, weil es wohl nur ein Skript gibt, das mit dem Server kommuniziert und dort gleichzeitig <texttool> einträgt, Metadaten abgreift, die pageimg importiert. Andererseits können das genausogut drei getrennte Skripte sein. Dann kommuniziert man halt dreimal mit dem Server. ODer einfacher: ein Skript holt sich eine lokale Kopie von index.meta und legt eine getrennte Datei der pageimg an, und die nächsten Skripte müssen dann gar nicht mehr auf dem Server anfragen. Folgende Gruppen sind erlaubt, in beliebiger Reihenfolge, jeweils durch eine Leerzeile getrennt, vor dem ersten {{{<pb>}}}: * {{{metadata:}}} * {{{pageimg:}}} (wird aber gleich wieder verarbeitet) bzw. getrennte Datei, siehe oben * {{{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? ==== Metadaten ==== {{{Filter_2_01_additional_metadata}}} „metadata:“ Skript zur Korrektur der Metadaten aus index.meta ergänze dann den Rest per Hand ⟶ am Anfang: dcterms:creator (GND:118859676) Aristoteles Klaus: Für Convenience einen Link ins Echosystem am Anfang der Datei, beispielsweise {{{ http://echo.mpiwg-berlin.mpg.de/ECHOdocuView/ECHOzogiLib?mode=imagepath&url=/mpiwg/online/permanent/library/PUBSU9QD/pageimg }}} ⟶ oder besser link das Prototyp-System? vorläufig beides! ==== pb's synchronisieren ==== {{{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 ==== ersetze verbotene Zeichen im Text ==== {{{Filter_2_03_find_forbidden_characters}}} ⟶ im ganzen Dokument: {{{Hinɔ wird Hinc}}} (Einzelfälle) entweder direkt im Text, oder mit Zwischenstuf als replacements am Anfang ==== prüfe unknown characters ==== {{{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 ==== prüfe escape sequences ==== {{{Filter_2_05_check_escape_sequences}}} bei replacements: zum Beispiel {{{{ta} ta (vorläufig!)}}} ==== prüfe italics ==== {{{Filter_2_06_check_underscores}}} {{{_ _}}} werden erst später in <it> verwandelt, aber hier wird bereits geprüft, ob es Probleme geben wird (bzw. die Fehler werden per Hand korrigiert) ==== prüfe tags ==== {{{Filter_2_07_check_tags.pl}}} ⟶ 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 ==== prüfe <s> ==== {{{Filter_2_08_check_s.pl}}} kann man hier das s-Skript aufrufen, oder kommt man dann durcheinander? ==== prüfe tables ==== {{{Filter_2_09_check_tables.pl}}} 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? ==== Special Instructions ==== {{{Filter_2_10_special_instructions_for_... .pl}}} (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? === Schritte bis zu wohlgeformtem xml === Diese Skripte sollten problemlos durchlaufen und können in einem Meta-Skript zusammengefasst werden: {{{Filter_3_make_wellformed.pl}}} Außerdem: {{{Filter_3_test_wellformedness.pl}}} ==== ersetze unknown characters ==== {{{Filter_3_01_replace_unknown_characters.pl}}} (vor escape sequences als garantierte Reihenfolge, bevor die escape sequences umgewandelt werden) ==== ersetze replacements ==== {{{Filter_3_02_replace_replacements.pl}}} (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. ==== ersetze escape sequences ==== {{{Filter_3_03_replace_escape_sequences.pl}}} ==== ersetze italics ==== {{{Filter_3_04_replace_underscores.pl}}} ==== Metadaten, root element ==== {{{Filter_3_05_add_basic_xml.pl}}} auch: log ! ==== wohlgeformtes xml ==== {{{Filter_3_06_make_tags_wellformed.pl}}} === schema-konform machen === wieder: Diese Skripte sollten problemlos durchlaufen und können in einem Meta-Skript zusammengefasst werden: {{{Filter_4_make_valid.pl}}} Außerdem: {{{Filter_4_test_validity.pl}}} * {{{Filter_4_00_Schummelskript.pl}}} (solange die Tabellen noch nicht richtig verarbeitet werden) ==== <pb> ==== {{{Filter_4_01_pb.pl}}} ==== floats herausziehen ==== {{{Filter_4_02_move_floats.pl}}} (auch tables!) auch aus <h>, oder lieber Fehler provozieren? ==== <lb> ==== {{{Filter_4_03_insert_lb.pl}}} ==== <s> ==== {{{Filter_4_04_insert_s.pl}}} (eventuell mit Parameter-Wahl; eventuelle manuelle Korrekturen im raw text!) {{{Filter_4_04a_test_s.pl}}} ?? ==== <emph> ==== {{{Filter_4_05_emph.pl}}} ==== tables ==== {{{Filter_4_06_tables.pl}}} wann werden die tables bearbeitet? zwei Schritte: überhaupt syntaktisch korrekt, und dann größtmögliche Annäherung an das Original (erst im scholarly workflow). ==== <div> ==== {{{Filter_4_07_insert_div.pl}}} (nicht wirklich nötig für Schema-konform, aber bekommt man quasi geschenkt) === weitere Schritte === ==== <reg> ==== {{{Filter_5_01_insert_reg.pl}}} (mit Parametern) ==== <var> ==== {{{Filter_5_02_insert_var.pl}}} (mit Parametern) ==== Formeln ==== {{{Filter_5_03_formulae.pl}}} ? ==== div-Attribute ==== {{{Filter_5_04_number_divs}}} === Reste === {{{Filter_template.pl}}} {{{Filter_1_6_punctuation.pl}}} {{{Filter_Archimedes_to_ECHO.pl}}} {{{Filter_roman_numbers.pl}}} == Besonderheiten bei chinesischen Texten == 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,,inline)]] == Die Arbeitsschritte == * 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 Skript-Ketten abrufbar sein. klare Namenskonvention: {{{check}}} als Vorbereitung, {{{test}}} als Nachbereitung, alle anderen Skripte müssen wiederholt werden, wenn man wieder mit dem raw text anfängt. === Vorbereitungen === ==== Von Pythia ins svn-repository ==== in trunk/texts/WO...: * Verzeichnisse anlegen (allerdings nerven die raw/xml-Verzeichnisse in der Praxis) * Datei aus Pythia rüberkopieren * Kopie erstellen und umbenennen, mit identifier, neue line ends Skript: Datei umbenennen? oder ist das jetzt wirklich etwas, was einfacher per Hand geht? Skript von Klaus? ==== Kommunikation mit Foxridge ==== Klaus: Voraussetzung: der Identifier steht im Dateinamen, dann kann bis zur Synchronisation der pb vieles automatisch laufen (⟶ das Skript wird nicht mit legacy-Verzeichnissen funktionieren) 1. 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.). 1. pageimg: Gleichzeitig könnte auch der Inhalt des pageimg-Verzeichnisses (also die Auflistung der Dateien) in den Text geschrieben werden. 1. texttool: Vielleicht sollte man nicht nur aus der index.meta lesen, sondern auch das erforderliche reinschreiben. Sicherheitskopie anlegen. Datei neu formatieren. Metadaten: werden erstmal wörtlich übernommen und in den raw text geschrieben. Erst später wird das Format angepasst. Übernommen werden (jeweils in /): * {{{}}} * {{{}}} * {{{<year>}}} * {{{<lang>}}} (ISO 639-1, d.h. zweistellig) * (bisher noch nicht: {{{<publisher>}}}, {{{<city>}}}, {{{<number_of_pages>}}}, {{{<translator>}}}) pageimg: geradlinig. Wenn es {{{<pageimg>}}} schon gibt, muss man im entsprechenden Verzeichnis nachschauen. Für texttool gibt es klare Regeln: 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>}}}. Lokale Kopie von index.meta? Besser xslt statt Perl? Vielleicht zwei Schritte, weil ich mich dabei wohler fühle: 1. reines Abholen der Datei z.B. {{{ 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 }}} (funktioniert nur mit einer internen IP-Adresse) 2. umbenennen der alten index.meta, schreiben der neuen. === raw text bearbeiten === Die Trennung von Vorbereitung und raw text bearbeiten kann man eventuell nicht klar aufrechterhalten, weil es wohl nur ein Skript gibt, das mit dem Server kommuniziert und dort gleichzeitig <texttool> einträgt, Metadaten abgreift, die pageimg importiert. Andererseits können das genausogut drei getrennte Skripte sein. Dann kommuniziert man halt dreimal mit dem Server. ODer einfacher: ein Skript holt sich eine lokale Kopie von index.meta und legt eine getrennte Datei der pageimg an, und die nächsten Skripte müssen dann gar nicht mehr auf dem Server anfragen. Folgende Gruppen sind erlaubt, in beliebiger Reihenfolge, jeweils durch eine Leerzeile getrennt, vor dem ersten {{{<pb>}}}: * {{{metadata:}}} * {{{pageimg:}}} (wird aber gleich wieder verarbeitet) bzw. getrennte Datei, siehe oben * {{{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? ==== Metadaten ==== {{{Filter_2_01_additional_metadata}}} „metadata:“ Skript zur Korrektur der Metadaten aus index.meta ergänze dann den Rest per Hand ⟶ am Anfang: dcterms:creator (GND:118859676) Aristoteles Klaus: Für Convenience einen Link ins Echosystem am Anfang der Datei, beispielsweise {{{ http://echo.mpiwg-berlin.mpg.de/ECHOdocuView/ECHOzogiLib?mode=imagepath&url=/mpiwg/online/permanent/library/PUBSU9QD/pageimg }}} ⟶ oder besser link das Prototyp-System? vorläufig beides! ==== pb's synchronisieren ==== {{{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 ==== ersetze verbotene Zeichen im Text ==== {{{Filter_2_03_find_forbidden_characters}}} ⟶ im ganzen Dokument: {{{Hinɔ wird Hinc}}} (Einzelfälle) entweder direkt im Text, oder mit Zwischenstuf als replacements am Anfang ==== prüfe unknown characters ==== {{{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 ==== prüfe escape sequences ==== {{{Filter_2_05_check_escape_sequences}}} bei replacements: zum Beispiel {{{{ta} ta (vorläufig!)}}} ==== prüfe italics ==== {{{Filter_2_06_check_underscores}}} {{{_ _}}} werden erst später in <it> verwandelt, aber hier wird bereits geprüft, ob es Probleme geben wird (bzw. die Fehler werden per Hand korrigiert) ==== prüfe tags ==== {{{Filter_2_07_check_tags.pl}}} ⟶ 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 ==== prüfe <s> ==== {{{Filter_2_08_check_s.pl}}} kann man hier das s-Skript aufrufen, oder kommt man dann durcheinander? ==== prüfe tables ==== {{{Filter_2_09_check_tables.pl}}} 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? ==== Special Instructions ==== {{{Filter_2_10_special_instructions_for_... .pl}}} (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? === Schritte bis zu wohlgeformtem xml === Diese Skripte sollten problemlos durchlaufen und können in einem Meta-Skript zusammengefasst werden: {{{Filter_3_make_wellformed.pl}}} Außerdem: {{{Filter_3_test_wellformedness.pl}}} ==== ersetze unknown characters ==== {{{Filter_3_01_replace_unknown_characters.pl}}} (vor escape sequences als garantierte Reihenfolge, bevor die escape sequences umgewandelt werden) ==== ersetze replacements ==== {{{Filter_3_02_replace_replacements.pl}}} (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. ==== ersetze escape sequences ==== {{{Filter_3_03_replace_escape_sequences.pl}}} ==== ersetze italics ==== {{{Filter_3_04_replace_underscores.pl}}} ==== Metadaten, root element ==== {{{Filter_3_05_add_basic_xml.pl}}} auch: log ! ==== wohlgeformtes xml ==== {{{Filter_3_06_make_tags_wellformed.pl}}} === schema-konform machen === wieder: Diese Skripte sollten problemlos durchlaufen und können in einem Meta-Skript zusammengefasst werden: {{{Filter_4_make_valid.pl}}} Außerdem: {{{Filter_4_test_validity.pl}}} * {{{Filter_4_00_Schummelskript.pl}}} (solange die Tabellen noch nicht richtig verarbeitet werden) ==== <pb> ==== {{{Filter_4_01_pb.pl}}} ==== floats herausziehen ==== {{{Filter_4_02_move_floats.pl}}} (auch tables!) auch aus <h>, oder lieber Fehler provozieren? ==== <lb> ==== {{{Filter_4_03_insert_lb.pl}}} ==== <s> ==== {{{Filter_4_04_insert_s.pl}}} (eventuell mit Parameter-Wahl; eventuelle manuelle Korrekturen im raw text!) {{{Filter_4_04a_test_s.pl}}} ?? ==== <emph> ==== {{{Filter_4_05_emph.pl}}} ==== tables ==== {{{Filter_4_06_tables.pl}}} wann werden die tables bearbeitet? zwei Schritte: überhaupt syntaktisch korrekt, und dann größtmögliche Annäherung an das Original (erst im scholarly workflow). ==== <div> ==== {{{Filter_4_07_insert_div.pl}}} (nicht wirklich nötig für Schema-konform, aber bekommt man quasi geschenkt) === weitere Schritte === ==== <reg> ==== {{{Filter_5_01_insert_reg.pl}}} (mit Parametern) ==== <var> ==== {{{Filter_5_02_insert_var.pl}}} (mit Parametern) ==== Formeln ==== {{{Filter_5_03_formulae.pl}}} ? ==== div-Attribute ==== {{{Filter_5_04_number_divs}}} === Reste === {{{Filter_template.pl}}} {{{Filter_1_6_punctuation.pl}}} {{{Filter_Archimedes_to_ECHO.pl}}} {{{Filter_roman_numbers.pl}}} == Besonderheiten bei chinesischen Texten == 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?