Der Stand beim XML-Workflow

Anfang März 2011

Plan: "Version 1.0": zwei Monate (ca. 8-9 Wochen)

1. DESpecs

Data Entry Specifications (DESpecs) für europäische Texte und für chinesische Texte

• Übersicht: über 100 Texte damit geschickt
• erste Versionen abgeschlossen
• werden weiterentwickelt nach den Erfahrungen mit den geschickten Texten
• Regeln: einfach formuliert versus semantisch und linguistisch korrekt
• wir wollen semantisch relevante Eigenschaften, wir bekommen optisch erkennbare Dinge
• im Zweifelsfall: markieren lassen, hinterher prüfen und eventuell verwerfen (z.B. <col>)
• eventuell Neubewertung, seitdem man die fertigen Texte wirklich sehen kann
• absichtlich kein echtes XML; definierte Schnittstelle für verschiedene Transkriptionsfirmen
• reine Textdateien, Unicode
• escape sequences, auch für seltene Unicode-Zeichen: sonst Stochern in der Unicode-Tabelle
• Dokumentation:
  • die DESpecs sind im wesentlichen selbsterklärend
  • aber Designentscheidungen und linguistischer Hintergrund
  • muss noch aufgeschrieben werden

Europäische Specs (mit Malcolm und Klaus):

• (korrekter wäre wohl: Specs für Alphabetschriften, auch Arabisch)
• sprachunabhängige Regeln, hauptsächlich für Textstruktur
  • Seiten-Struktur, und Spalten
  • Textblöcke
  • Tabellen im weitesten Sinne
  • Marginalien und Fußnoten
  • Abbildungen
  • nicht identifizierbare Zeichen (unbekannt, unleserlich)
• Transkriptionsregeln für das lateinische Alphabet
  • Interpunktion
  • Zeichen, escape sequences
  • Schriftstile
• Regeln für andere Sprachen und Schriftsysteme
  • Griechisch
  • Fraktur
  • Mathematik (typischer Fall: <math> von Special Instruction in die Specs)
  • Symbole
  • weiteres Ziel war Arabisch (mit Mark), davon gibt es noch Ansätze von Specs für Arabisch

Chinesische Specs (mit Martina):

• europäische Specs zwar sprachunabhängig, aber implizite Voraussetzung Alphabetschrift
• Regeln für Textstruktur angepasst
• killer feature: Regeln für Zeichenvarianten
• in der Pipeline: überarbeitete Regeln für Zeichenvarianten einbauen

Außerdem diverse ​Special Instructions für europäische und chinesische Texte, und beantwortete Fragen von Formax

• aktuell mit Cathleen: SIs für Enzyklopädie-Einträge, für Heidelberg (erweiterbar auf VLP-Lexika)

technische Hilfe beim Aufbau einer vergleichbaren Gruppe bei der Partnergruppe

• aus politischen Gründen gescheitert
• neuen Versuch starten?

In der Pipeline:

• Cathleen-Texte (Bibliothekskataloge; das sind nicht die Heidelberg-Texte)
• Paul: Heytesbury, Swineshead
• Mingli tan (klären mit Joachim)

"Version 1.0":

• die DESpecs sind bereits 1.0 und wurden erfolgreich verwendet
• aber: die DESpecs sind teilweise zwei Jahre alt, und es gibt eine lange Liste von Änderungswünschen. Diese Änderungen sollten berücksichtigt werden, bevor weitere Texte geschickt werden, und insbesondere bei Chinesisch müssen dringend Texte geschickt werden (für uns und für Heidelberg). Man kann also nicht einfach sagen, alle Teile sollen Version 1.0 erreichen, bevor wir hier weitermachen.
• Sprachregelung deshalb: diese Änderungen gehören zu Version 1.0.

für Version 1.0:

• Specs ins repository
• chinesische Specs: von Martina überarbeiteten Umgang mit Zeichenvarianten einbauen
• europäische Specs: u.a. <math> und Antworten von WO 10; Juttas Anmerkungen
• 1 Woche

für Version 1.x:

• Lexika

2. ECHO-Schema

Echo-Schema 1.0 (mit Malcolm)

• Nachfolger von Archimedes-DTD
• geschrieben in RELAX NG compact
• modulare Struktur
• konsequent Unicode
• Design-Entscheidungen:
  • ein Schema für alle Texte
  • möglichst unabhängige Module
  • tags in den DESpecs sollten möglichst ein Gegenstück im Schema haben
  • aber das Schema soll die DESpecs nicht sklavisch nachmachen (die DESpecs sind nur aus pragmatischen Gründen vor dem Schema entstanden)
• lange Liste von Ergänzungen fertig, muss mit TEI verglichen und hochgeladen werden

Dokumentation:

• Modul-Struktur:
  1. Einteilung der Module in Gruppen
     • Standard-Module
     • Grobstrukturierung des Textes
     • Feinstrukturierung des Textes
     • Textauszeichnung
  2. damit verwandt: Zuordnung der Module zur XML-Hierarchie
  3. Abhängigkeiten zwischen den Modulen
  4. Module sortiert nach zeitlichem Ablauf:
     • automatisisiert und semi-automatisiert
     • scholarly workflow
• die einzelnen tags
  • sortiert nach Schema-Modulen
  • Verwendung, best practices z.B. bei <lb>
  • Verhältnis DESpecs-tags und Schema-tags
  • Darstellung im Anzeigesystem und in GIS

Beziehung zu / Abgrenzung von TEI:

• systematischer als TEI (weniger historisch bedingter Wildwuchs)
• strikter als TEI
• <s>: wissenschaftliches Arbeiten
• nur das, was wir konkret verwenden / anzeigen
• TEI ist kein einheitlicher Standard, sondern eine Familie von Standards
• trotzdem TEI als Austauschformat

für Version 1.0:

• Schema-Version 1.0
• Texte neu einchecken?
• 0,5 Wochen

für Version 1.x:

• kompliziertere Figures
• Zwiebelstruktur des Schemas
• Vorgehen bei Schema-Änderungen; verschiedene Schema-Versionen
• Ergänzungen für Lexika

3. Workflow

Konzept des Workflows: Texte schicken, Fragen beantworten, überprüfen, korrigieren, bearbeiten

• Dokumentation
• Skripte in Perl und XSLT
• Umsetzung als Textfilter
• so lange wie möglich: Arbeiten mit .txt statt .xml
• Beziehung zwischen DESpecs, Schema, Workflow: berücksichtige verschiedene DESpecs-Versionen
• Es gibt fast nie Rückmeldungen zu den erstellten XML-Texten. Arbeitet eigentlich jemand mit den Texten, z.B. mit den 20 Vitruv-Texten?

Schritte bis zur fertigen Transkription:

• Klaus: vorbereiten, überprüfen
• Fragen beantworte meistens ich.
  • Letzter Work Order (WO 10) bestand aus besonders schwierigen Texten, die bisher liegengeblieben waren. Großer Aufwand bei der Beantwortung der Fragen.
  • Antworten müssen noch in die DESpecs überführt werden.
  • Grundsätzliche Änderung: realistischere Ziele bei dem, was die Chinesen erreichen können, insbesondere in den Special Instructions für einzelne Texte. Beispiel Wimmelbilder-Figures. Lieber ein Zwischenstadium, mit dem wir gut weiterarbeiten können. (Ich muss noch prüfen, ob es in WO 10 funktioniert hat.)

Schritte nach Erhalt der fertigen Transkription:

• Konzept und Implementation
• Workflow durchführen: meistens Klaus
• zusätzlich: Figures ausschneiden: Beschreibung von Klaus, durchgeführt von Student
• Im ersten Schritt werden alle Vorbereitungen getroffen, um mit dem raw text arbeiten zu können.
  • Text in das repository
  • Abstimmung mit Foxridge: index.meta
• Im zweiten Schritt wird der raw text annotiert und korrigiert.
  • Metadaten ergänzen: Skript von Klaus
  • <pb> synchronisieren als Voraussetzung für die weitere Arbeit
  • verbotene Zeichen im Text ersetzen
  • unknown characters durchgehen
  • escape sequences prüfen
  • italics prüfen ("_ _")
  • tags prüfen: Wichtig als Grundlage für weitere Skripte. Beispiele:
    • zu <h> gibt es ein </h>
    • <tb> steht auf eigener Zeile
    • Elemente sind korrekt verschachtelt
  • prüfe <s>: wende das <s>-Skript testweise an und finde Merkwürdigkeiten im Ergebnis
  • prüfe Tabellen (fehlt noch)
  • eventuell Skripte für tags aus Special Instructions
• Im dritten Schritt wird der annotierte raw text in wohlgeformtes XML verwandelt. Weitgehend automatisch.
  • ersetze unknown characters, replacements (d.h. Textänderungen, die im raw text nicht direkt durchgeführt wurden, sondern in einem Block am Anfang vermerkt wurden), escape sequences, italics
  • XML: wandle die Metadaten in XML um, erzeuge aus dem Pseudo-XML im Textteil wohlgeformtes XML
• Im vierten Schritt wird der XML-Text schemakonform gemacht. Weitgehend automatisch.
  • <pb> nachbearbeiten
  • Floats aus den Absätzen herausziehen
  • <lb>
  • <emph>
  • Tabellen (fehlt noch)
  • <div>
• Scholarly Workflow / Texanalyse:
  • <reg>
• weitere Skripte für den Scholarly Workflow sind noch im Konzept-Stadium:
  • <var>, <num>, Formeln
  • <foreign>
  • <place> etc.
  • Textkorrektur durch Abgleich mit Donatus
  • allgemeines Test-Skript
  • echo-de: <wrong> etc.
  • Hilfe bei der Korrektur typischer Transkriptionsfehler
• weitere Skripte (schon vorhanden):
  • <div>durchnumerieren (auch für DTD-Fragment)
  • Wrapper für XSLT-Skripte, um Nebenwirkungen zu korrigieren
• Chinesischer Workflow:
  • Skript für Zeichenvarianten

Bearbeitungsstand

• Konzept fertig
• die Grundstruktur ist implementiert und verwendbar
• müssen überarbeitet werden: s, emph, ...
• fehlen noch: korrekte Verarbeitung von Tabellen, Fußnoten, ...
• kurzfristiges Ziel: Skripte so einfach wie möglich verwendbar machen
• <place> und allgemein overlays weiter ausarbeiten

Problem der Fehlerkorrektur:

• interessant sind nur echte Satzfehler
• Transkriptionsfehler werden stillschweigend korrigiert

Konzept: Editionssystem

• killer feature
• geht über klassische Text-Editionen hinaus
• Werkzeug zur Beseitigung von Transkriptionsfehlern
• Regularisierung: <reg>-Skript, Zusammenarbeit mit Paul
• Normalisierung: Lex-Skripte, Koordinierung mit Josef und Robert
  • was wird übergeben
  • was kommt zurück
  • Zeilenumbrüche

für 1.0:

• Konzept: ist 1.0
• Skripte: alle Skripte durchgehen, so dass die vorhandenen Texte als fertig bezeichnet werden können. insbesondere
  • <s>
  • Tabellen
  • <reg>
  • Brüche
  • (<math>: nur eine erste Version)
  • (noch nicht: Textflows)
  • 3 Wochen
• Workflow anwenden:
  • chinesische Texte mit neuen Specs nach China schicken
  • überarbeitete Skripte anwenden auf die vorhandenen Texte (Klaus)
  • aber zuerst, dringend: Texte von WO 10 prüfen
  • 0,5 Wochen

für Version 1.x:

• Workflow für Texte, die nicht aus China kommen
• weitere Texte schicken, insbesondere Special Instructions für Pauls Texte
• schwierigere Texte fertig umwandeln
• Skripte für chinesischen Workflow
• chinesische Texte umwandeln
• Programm-Code der Skripte glatter machen, damit es nicht so unübersichtlich wie in Arboreal ist
• Textflow-Skript
• Konzept für overlays aus XML-Sicht

für Version 2.0:

• Einfaches Paket, das von interessierten Forschern leicht verwendet werden kann. (siehe auch 8. Scholarly Workflow)
• Umgang mit Formeln

4. Zusammenspiel XML und Anzeigesystem

Mitarbeit am Konzept für die Anzeige von:

• Buchstruktur
• Textseite
• Bildseite
• Anzeige-Optionen
• Wörterbuch-Informationen
• Suchergebnissen
• Besonderheiten bei chinesischem Text
• statische Versionen, Lite-Version, URLs, etc.

Überblick über die Tickets

• für Frontend, Backend, GIS
• Umsetzungen des Konzepts, und Bugs

Liste: Verhalten für jedes tag, im Text und im Inhaltsverzeichnis​

• Beispiele für Darstellung von tags:
  • CSS-level: optisch erkennbar
  • Sprachtechnologie: wird nicht oder anders analysiert: <var>, <reg>

Normalisierung:

• genaue Analyse des Ist-Zustands in Arboreal und im Backend
• Übersicht über das Zusammenspiel von Regularisierung und Normalisierung
• Regularisierung im Detail:
  • Ziele
  • Zusammenhang mit Anzeige-Modi
  • @faithul-Attribut
    • für "überschüssige" Information und zur Unterstützung bei der Korrektur von Transkriptionsfehlern
    • Abgrenzung von Orig und faithful
    • Umgang mit PUA-Zeichen
  • Umgang mit Abkürzungen im Text
  • Aussicht: automatische Fehlerkorrektur
  • Sprachübergreifende Regularisierungen
  • Regularisierungen für einzelne Sprachen
• Normalisierung im Detail:
  • Ziele
  • Textgestalt, die die Normalisierung vorfindet
  • Normalisierung für die Textanzeige
  • Normalisierung für Wörterbücher (sprachimmanent und technisch bedingt)
  • Normalisierung für die Suche
  • Verhältnis von Wortform und Grundform
  • Diakritika
  • Sprachschichten
  • sprachübergreifende Normalisierungen
  • Normalisierungen für einzelne Sprachen, insbesondere Latein, und Umgang mit Zeichenvarianten im Chinesischen
• Umsetzung
  • Liste: konkret zu tun
  • Lex für jede Sprache (mit Java-Testerklassse)

für Version 1.0:

• Normalisierung fertig, wiki-Text an den aktuellen Stand anpassen, paper
• Lex testen
• 1 Woche

für Version 1.x:

• Umgang mit Textflows klären: Eipo, Conimbricenses, Übersetzungen, Notes, etc.
• TOC-Skript

für Version 2.0:

• Darstellung von Lexika

5. Zusammenspiel XML und GIS

• Übergang vom alten Frontend (Falk) zum neuen Frontend (Christopher/Robert) angestoßen und begleitet
• Konzept: Verknüpfung Frontend mit GIS (Integration der Projektteile)
• <place>: mit Dagmar und Grace: Konzept für
  • overlay mit Tabelle (GIS-System als Prototyp für overlay)
  • Inhalt der Tabelle
  • Struktur des authority file

für Version 1.0:

• Konzept für die Verzahnung von <place>-Tabellen, Annotationen, Overlays, Kartenanzeige (gemeinsame Infrastruktur)
• 0,5 Wochen

--> verschieben auf Version 1.x ?

6. Vorzeigetexte

Latein

• ​Benedetti: europäischer Vorzeigetext; für Jürgen
• ​Alvarus: früher gedruckter Text mit vielen Abkürzungen; für Paul
• Clavius-Euklid: für das Euklid-Projekt

Chinesisch

• ​Song Yingxing: chinesischer Vorzeigetext; places; für Dagmar
• ​chinesischer Euklid: für das Euklid-Projekt

Deutsch

• ​Heeschen (Eipomek und Deutsch): Textflows; für Martin T.
• ​Abruzzen: Text ursprünglich von Martin R. erstellt, in Zusammenarbeit mit Martin in einen Schema-konformen Text umgewandelt.

Diverse Skripte für Einzeltexte, insbesondere bei den ersten Texten und für Nachbearbeitungen

für Version 1.0:

• Alvarus: <reg>
• Song Yingxing fertig, und an neue Schema-Version anpassen
• Clavius schemakonform machen
• 1 Woche

für Version 1.x:

• places in Benedetti markieren

7. Wiki und Dokumentation

• Dokumentation: DESpecs (fehlt), Schema, Workflow
  • werde ich in ein Unterverzeichnis documentation/de bzw. documentation/en verschieben
• Diskussionstexte: Ich versuche, meine Überlegungen zeitnah ins Wiki zu stellen, damit sie diskutiert werden können. (Beispiel Seitenzahlen)

für Version 1.0:

• Skripte genauer dokumentieren
• 1 Woche

für Version 1.x:

• Computer durchgehen auf weitere Dinge, eventuell aufs wiki stellen
• Workflow-Dokumentation überarbeiten
• Usage Guide weiter
• Dokumentation der DESpecs
• wiki aktualisieren
• Beispiel-XML-Dateien überarbeiten
• Anbindung an andere Projekte und Europeana
• paper

8. Scholarly workflow

• im Schema bereits angelegt
• Anfänge sind gemacht mit <reg>-Skript

für Version 2.0:

• Skripte für scholarly workflow
  • zusätzliche Auszeichnungen wie <num>
  • Korrektur von bestehenden Auszeichnungen wie <s>
• Skripte für Texte aus anderen Quellen, z.B. Stabi
• Interaktivität insbesondere im scholarly workflow, aber auch in den Schritten davor
• Web-Services

9. Der Weg zu Version 1.0

Die oben aufgezählten Arbeiten für Version 1.0 dauern zusammen ca. 8 Wochen. Es kommen aber oft andere Arbeiten dazwischen:

1. killer feature Anzeige-Modi:
   • die Arbeiten für die neue Normalisierung waren sehr umfangreich, aber ein Ersatz für die bisherige Normalisierung war dringend
   • erst Konzept erstellt, und dann wurde klar, dass ich auch die Lex-Dateien selber schreiben muss (mache ich gern, aber hat viel Zeit gekostet, auch für die Koordination von Lex mit dem Backend)

--> jetzt fertig (bis auf Wiki aktualisieren und testen)

2. laufende Arbeiten:
   • WO 10 überprüfen
   • SI mit Cathleen
   • Song Yingxing
   • GIS
   • Wiki

--> muss sein; aber mögliche Priorisierung: vor Abschluss von Version 1.0 nur noch die Texte schicken, die bereits in Arbeit sind

3. Konzept für das gesamte Projekt:
   • eine bestimmte Konzeptschicht unter dem Großen Ganzen, nämlich Usersicht, konkrete Funktionalität, Besonderheiten der einzelnen Sprachen
   • Verzahnung der Teilprojekte
   • Beispiele: Anzeige der XML-tags, GIS-Tabellen, Seitenzahlen, ...
   • macht sonst niemand systematisch; erzeugt viel Widerstand

--> mögliche Priorisierung: noch anstehende Arbeiten in diesem Bereich hinter Version 1.0 verschieben? (Aber wenn z.B. das Thema Overlays nicht als ganzes um diese zwei Monate verschoben wird, sehe ich es als meine Aufgabe, da meinen Standpunkt einzubringen.)

4. Qualitätssicherung:
   • ich suche nicht systematisch Fehler, sondern ich arbeite mit dem System und schreibe auf, was mir auffällt
   • extrem hoher Verwaltungsaufwand:
     • Tickets erstellen
     • Navigation durch das Ticketmeer: ticket-overview aktuell halten
     • drauf dringen, dass die Tickets bearbeitet werden
     • Hilfe bei der Fehlersuche
     • überprüfen, ob als "fixed" markierte Tickets wirklich gelöst wurden
   • kostet viel Zeit, erzeugt viel Widerstand; aber außer mir macht es praktisch keiner (94 von 120 Tickets sind von mir)

--> Ich hätte weniger Arbeit, wenn ich die Tickets nur erstellen müsste und die weiteren Schritte dann glatt durchlaufen würden. Mögliche Spielregeln: z.B. "wontfix" oder "2.0" für Tickets, die man erstmal verschiebt