wiki:workflow

Context Navigation

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

XML Workflow

Die Arbeitsschritte
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 leere Platzhalter, aber die Struktur stimmt bereits.

Die Arbeitsschritte

Im ersten Arbeitsschritt werden alle Vorbereitungen getroffen, um mit dem raw text zu arbeiten. Im zweiten Schritt wird der raw text korrigiert und annotiert. Im dritten Schritt wird der annotierte raw text in wohlgeformtes XML verwandelt. Im vierten Schritt wird der XML-Text schemakonform gemacht.

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 DESpecs 1.1.2 und Work Orders 6 bis 9 mit den 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 <s>-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.

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

Es ist noch nicht ganz klar, wie neue Dateien in Zukunft verarbeitet werden: Kommen sie zuerst nach Pythia oder gleich in das wiki-repository? Jedenfalls muss geprüft werden, dass es die Datei reiner Text in utf-8 ist.

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 (autor_jahr_identifier), Zeilenenden von CRLF zu LF. Entferne BOM-Fragmente (korrekte BMs sind okay).

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)

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

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)

Umbenennen der alten index.meta (eventuell wird eine ältere Sicherheitskopie ohne Nachfrage überschrieben), Schreiben der neuen.

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

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

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.

Metadaten

Skript zur Korrektur der Metadaten aus index.meta: Filter_2_01_additional_metadata „metadata:“

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

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

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

Das Skript Filter_2_05_check_escape_sequences ruft intern erst 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!)

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

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?

Schritte bis zu wohlgeformtem xml

Diese Skripte in diesem Arbeitsschritt sollten problemlos durchlaufen und können in einem Meta-Skript zusammengefasst werden: Filter_3_make_wellformed . Das Skript Filter_3_test_wellformedness prüft anschließend, ob das Ergebnis wohlgeformt ist.

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

Das Skript 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 NRC

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

Legt die Hierarchie der inline-Elemente (z.B. <var> in plaintext, <ref> im inline model) eine Verarbeitungsreihenfolge nahe?

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₁ im Original eine Variante des Standardzeichens S ist, es aber in Unicode eine weitere Zeichenvariante V₂ von S gibt, die optisch näher an V₁ dran ist als S an V₁, so sollen die Chinesen die Variante V₂ 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 兾 (V₂) 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?

Download in other formats:

Plain Text