= Der Stand beim XML-Workflow Anfang März 2011 [[PageOutline(1-4,,pullout)]] 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 * [wiki:OverviewWorkOrders Ü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. ) * eventuell Neubewertung, seitdem man die fertigen Texte wirklich sehen kann * absichtlich [wiki:despecs 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: 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 [http://pythia.mpiwg-berlin.mpg.de/department1/mpdl/special-instructions 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. und Antworten von WO 10; Juttas Anmerkungen * Wiki: eine Seite mit allen links zu PDFs und LaTeX-Sources * Lizenz (CC ?) * 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 [wiki:echo-schema Dokumentation]: * Modul-Struktur: 1. Einteilung der Module in Gruppen * Standard-Module * Grobstrukturierung des Textes * Feinstrukturierung des Textes * Textauszeichnung 1. damit verwandt: Zuordnung der Module zur XML-Hierarchie 1. Abhängigkeiten zwischen den Modulen 1. Module sortiert nach zeitlichem Ablauf: * automatisisiert und semi-automatisiert * scholarly workflow * die einzelnen tags * sortiert nach Schema-Modulen * Verwendung, best practices z.B. bei * 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 * : 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 * Usage Guide: Übersicht: welches tag hat welche Attribute * [source:trunk/schema/xml-test-files Beispiel-XML-Dateien]: Minimal-XML aktualisieren, Beispiel-XML für alle tags aktualisieren * Texte neu einchecken? * 0,5 Wochen für Version 1.x: * DESpecs direkt für XML-Texte (also Usage Guide mit den Beispielen aus den DESpecs) * kompliziertere Figures (insbesondere Bion) * Zwiebelstruktur des Schemas * Vorgehen bei Schema-Änderungen; verschiedene Schema-Versionen (nicht die namespaces im XML ändern!) * Ergänzungen für Lexika für Version 2.0: * Texte auf Knopfdruck in TEI umwandeln == 3. Workflow Konzept des Workflows: Texte schicken, Fragen beantworten, überprüfen, korrigieren, bearbeiten * [wiki:workflow 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 [wiki:WO10_Bion_1723 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 [wiki:workflow#a1.Vorbereitungen 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 [wiki:workflow#a2.rawtextbearbeiten zweiten Schritt] wird der raw text annotiert und korrigiert. * Metadaten ergänzen: Skript von Klaus * 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 gibt es ein * steht auf eigener Zeile * Elemente sind korrekt verschachtelt * prüfe : wende das -Skript testweise an und finde Merkwürdigkeiten im Ergebnis * prüfe Tabellen (fehlt noch) * eventuell Skripte für tags aus Special Instructions * Im [wiki:workflow#a3.Schrittebiszuwohlgeformtemxml 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 [wiki:workflow#a4.schema-konformmachen vierten Schritt] wird der XML-Text schemakonform gemacht. Weitgehend automatisch. * nachbearbeiten * Floats aus den Absätzen herausziehen * * * Tabellen (fehlt noch) *
* Scholarly Workflow / Texanalyse: * * weitere Skripte für den Scholarly Workflow sind noch im Konzept-Stadium: * , , Formeln * * etc. * Textkorrektur durch Abgleich mit Donatus * allgemeines Test-Skript * echo-de: etc. * Hilfe bei der Korrektur typischer Transkriptionsfehler * weitere Skripte (schon vorhanden): *
durchnumerieren (auch für DTD-Fragment) * Wrapper für XSLT-Skripte, um Nebenwirkungen zu korrigieren * Chinesischer Workflow: * Skript für Zeichenvarianten * Workflow für Änderungen bei den Scans (Abstimmung mit der Digigroup) 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 * 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: -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 * ; und das Prüf-Skript für die sollte auch für einen Text funktionieren, der bereits hat * Tabellen * * Brüche * (: 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: * FAQs ? (im Zusammenhang mit Knopf: "ich habe einen Textfehler gefunden") * kleines Workflow-Tutorial anhand von einfachem Beispiel-Text; insbesondere Textfilter genauer erklären (Klaus?) * 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. [wiki:ticket-overview Überblick] über die Tickets * für Frontend, Backend, GIS * Umsetzungen des Konzepts, und Bugs Liste: Verhalten für jedes tag, [wiki:echo-schema#a3.UmsetzungderXML-tags im Text] und [source:"trunk/papers/discussion_papers/Regeln zum Erstellen eines Inhaltsverzeichnisses.pdf" im Inhaltsverzeichnis] * Beispiele für Darstellung von tags: * CSS-level: optisch erkennbar * Sprachtechnologie: wird nicht oder anders analysiert: , [wiki:normalization Normalisierung]: * genaue Analyse des Ist-Zustands in Arboreal und im Backend * [wiki:normalization/4 Übersicht] über das Zusammenspiel von Regularisierung und Normalisierung * [wiki:normalization/5 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 * [wiki:normalization/6 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: [wiki:normalization/7 konkret zu tun] * [source:trunk/schema/scripts/MpdlNormalizerLex 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) * : 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.x (verschoben von Version 1.0): * Konzept für die Verzahnung von -Tabellen, Annotationen, Overlays, Kartenanzeige (gemeinsame Infrastruktur) * 0,5 Wochen == 6. Vorzeigetexte Latein * [http://echo.mpiwg-berlin.mpg.de/ECHOdocuView?url=/mpiwg/online/permanent/library/163127KK&pn=5 Benedetti]: europäischer Vorzeigetext; für Jürgen * [http://echo.mpiwg-berlin.mpg.de/ECHOdocuView?url=/mpiwg/online/permanent/library/YHKVZ7B4&pn=5 Alvarus]: früher gedruckter Text mit vielen Abkürzungen; für Paul * Clavius-Euklid: für das Euklid-Projekt Chinesisch * [http://echo.mpiwg-berlin.mpg.de/ECHOdocuViewfull?url=/mpiwg/online/permanent/echo/china/songy_tiang_zh_1637 Song Yingxing]: chinesischer Vorzeigetext; places; für Dagmar * [http://mpdl-dev.mpiwg-berlin.mpg.de/ECHOdocuViewfull?url=/mpiwg/online/permanent/library/02NT95YF&viewMode=text&pn=5&characterNormalization=reg chinesischer Euklid]: für das Euklid-Projekt Deutsch * [http://mpdl-dev.mpiwg-berlin.mpg.de/ECHOdocuViewfull?url=/mpiwg/online/permanent/library/XYZATWZM Heeschen] (Eipomek und Deutsch): Textflows; für Martin T. * [http://mpdl-dev.mpiwg-berlin.mpg.de/ECHOdocuViewfull?url=/mpiwg/online/permanent/library/0QDF6SH2&pn=7 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: * Benedetti IDs * Song Yingxing fertig, und Änderungen nach dem Hochladen der neuen Schema-Version ( etc.) * Clavius schemakonform machen * 1 Woche für Version 1.x: * places in Benedetti markieren == 7. Wiki und Dokumentation * Dokumentation: DESpecs (fehlt), [wiki:echo-schema Schema], [wiki:workflow 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 [wiki:pagenumbers Seitenzahlen]) für Version 1.0: * Skripte genauer dokumentieren (überschneidet sich mit Workflow-Tutorial) * 1 Woche für Version 1.x: * Computer durchgehen auf weitere Dinge, eventuell aufs wiki stellen * Workflow-Dokumentation überarbeiten * [wiki:echo-schema#a2.UsageGuide Usage Guide] weiter * Dokumentation der DESpecs * wiki aktualisieren * Anbindung an andere Projekte und Europeana * paper == 8. Scholarly workflow * im Schema bereits angelegt * Anfänge sind gemacht mit -Skript für Version 2.0: * Skripte für scholarly workflow * zusätzliche Auszeichnungen wie * Korrektur von bestehenden Auszeichnungen wie * 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 (haben die Special Instructions funktioniert, etc.) * SI mit Cathleen * Song Yingxing: Zusammenarbeit mit den studentischen Hilfskräften * GIS * Wiki --> muss sein; aber 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, philologische Korrektheit * Verzahnung der Teilprojekte * Beispiele: Anzeige der XML-tags, GIS-Tabellen, Seitenzahlen, ... * macht sonst niemand systematisch; erzeugt viel Widerstand --> 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: [wiki: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 (97 von 123 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. [[BR]]--> Jochen: ab jetzt: Tickets bei Ablage priorisieren, monatliche Ticket-Sitzungen