wiki:workflow

Version 10 (modified by Wolfgang Schmidle, 15 years ago) (diff)

--

XML Workflow

  1. Die Arbeitsschritte
    1. Vorbereitungen
      1. Von Pythia ins svn-repository
      2. Kommunikation mit Foxridge
    2. raw text bearbeiten
      1. Metadaten
      2. pb's synchronisieren
      3. ersetze verbotene Zeichen im Text
      4. prüfe unknown characters
      5. prüfe escape sequences
      6. prüfe italics
      7. prüfe tags
      8. prüfe <s>
      9. prüfe tables
      10. Special Instructions
    3. Schritte bis zu wohlgeformtem xml
      1. ersetze unknown characters
      2. ersetze replacements
      3. ersetze escape sequences
      4. ersetze italics
      5. Metadaten, root element
      6. wohlgeformtes xml
    4. schema-konform machen
      1. <pb>
      2. floats herausziehen
      3. <lb>
      4. <s>
      5. <emph>
      6. tables
      7. <div>
    5. weitere Schritte
      1. <reg>
      2. <var>
      3. Formeln
      4. div-Attribute
    6. Reste
  2. Besonderheiten bei chinesischen Texten

Bisher sind 19 schema-konforme Texte bei ECHO, siehe ​mpdl-proto und ​echotest. Der automatische XML-Workflow besteht aus einer Reihe von Skripten. Einige dieser Skripte sind noch reine Platzhalter, aber die Struktur stimmt bereits.

Die Arbeitsschritte

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 Skript-Ketten 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.

Vorbereitungen

Beachte: In diesem Arbeitsschritt sind die Skripte vermutlich keine Text-Filter, denn man arbeitet hier noch gar nicht mit einem Text-Editor.

Von Pythia ins svn-repository

im Texte-Verzeichnis im repository:

  • 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.).
  2. pageimg: Gleichzeitig könnte auch der Inhalt des pageimg-Verzeichnisses (also die Auflistung der Dateien) in den Text geschrieben werden.
  3. 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 <resource>/<meta>):

  • <author>
  • <title>
  • <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)

  1. Umbenennen der alten index.meta (eventuell wird eine ältere Sicherheitskopie ohne Nachfrage überschrieben), 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 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

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​

⟶ 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​

kann man hier das s-Skript aufrufen, oder kommt man dann durcheinander?

prüfe tables

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?

Special Instructions

.pl Filter_2_10_special_instructions_for_...

(bei manchen Texten wird es einfacher sein, es statt mit einem Skript per Hand zu machen)

⟶ am Anfang: --] &lt; (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​

Außerdem: Filter_3_test_wellformedness​

ersetze unknown characters

Filter_3_01_replace_unknown_characters​

(vor escape sequences als garantierte Reihenfolge, bevor die escape sequences umgewandelt werden)

ersetze replacements

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.

ersetze escape sequences

Filter_3_03_replace_escape_sequences​

ersetze italics

Filter_3_04_replace_underscores​

Metadaten, root element

Filter_3_05_add_basic_xml​

auch: log !

wohlgeformtes xml

Filter_3_06_make_tags_wellformed​

schema-konform machen

wieder: Diese Skripte sollten problemlos durchlaufen und können in einem Meta-Skript zusammengefasst werden: Filter_4_make_valid​

Außerdem: Filter_4_test_validity​

*

Filter_4_00_Schummelskript​ (solange die Tabellen noch nicht richtig verarbeitet werden)

<pb>

Filter_4_01_pb​

floats herausziehen

Filter_4_02_move_floats​

(auch tables!)

auch aus <h>, oder lieber Fehler provozieren?

<lb>

Filter_4_03_insert_lb​

<s>

Filter_4_04_insert_s​ (eventuell mit Parameter-Wahl; eventuelle manuelle Korrekturen im raw text!)

Filter_4_04a_test_s ??

<emph>

Filter_4_05_emph​

tables

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).

<div>

Filter_4_07_insert_div​ (nicht wirklich nötig für Schema-konform, aber bekommt man quasi geschenkt)

weitere Schritte

<reg>

Filter_5_01_insert_reg​ (mit Parametern)

<var>

Filter_5_02_insert_var​ (mit Parametern)

Formeln

Filter_5_03_formulae

?

div-Attribute

Filter_5_04_number_divs

Reste

Filter_template​

Filter_1_6_punctuation

Filter_Archimedes_to_ECHO

Filter_roman_numbers

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 V1 im Original eine Variante des Standardzeichens S ist, es aber in Unicode eine weitere Zeichenvariante V2 von S gibt, die optisch näher an V1 dran ist als S an V1, so sollen die Chinesen die Variante V2 mit < V> tippen. Ein Beispiel ist <兾V> statt <冀V> in den ​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 兾 (V2) 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?