Digital resources in the Social Sciences and Humanities OpenEdition Our platforms OpenEdition Books OpenEdition Journals Hypotheses Calenda Libraries OpenEdition Freemium Follow us

Workshop-Resümee “Hört, hört! Zum Umgang mit Audio in den DH”

Von Vorlesungen aus dem letzten Jahrhundert, griechischer und lateinischer Dichtung bis 1588 sowie Spionageprozessen in der DDR über Hörspiele, Rezitationen vedischer Hymnen in Sanskrit bis hin zu Oral-History-Interviews – die Bandbreite von Audiomaterial im Bereich der Fachwissenschaften und der Digital Humanities ist immens. Jedes Projekt ist auf seine eigene Weise speziell, unterscheiden sich die audiovisuellen Materialien doch in ihrer Charakteristik, ihrem Inhalt, ihrer Qualität und ihrer Quantität. Fällt der Blick auf Schwierigkeiten, Herausforderungen und offene Fragen, zeigt sich jedoch, dass die Forscher*innen und Wissenschaftler*innen, trotz der Unterschiedlichkeit ihrer audiovisuellen Materialien, vielfach vor ähnlichen Problemen und Fragestellungen stehen.

An zwei Nachmittagen im Februar 2023 lud das Team DH@BUW Forscher*innen aus ganz Deutschland zu wissenschaftlichen Gesprächen über ihren jeweiligen Umgang mit Audio- und Videomaterial ein. So entstand zum einen eine kleine, aber informationsreiche Vortragsreihe, in der verschiedene Projekte vorgestellt wurden, und zum anderen ein Austausch über gemeinsame Herausforderungen und bewährte Best Practices. Im Anschluss an eine langjährige Tradition der textbasierten Erschließung geraten nun zunehmend multimodale Objekte in den Blick. Der Workshop zielte darauf ab, verschiedene Projekte und deren spezifische Arbeitsweisen mit nichttextlichen Medienformen kennenzulernen, um im besten Fall voneinander zu lernen. Inwiefern gleichen oder unterscheiden sich die Probleme der jeweiligen Projekte? Gibt es bereits Lösungen? Welche Vorgehensweisen lassen sich auf das eigene Projekt übertragen und welche Anregungen lassen sich finden?

Die DH@BUW arbeitet aktuell an mehreren Projekten, in denen Audiomaterial eine Rolle spielt. So stießen Andreas Mertgens und Enes Türkoğlu im Rahmen des Teilprojekts “The Harold Garfinkel Archive” auf Audioaufnahmen von Vorlesungen des Soziologen Harold Garfinkel (1917-2011), welche bereits transkribiert vorliegen. Die Schwierigkeit liegt hierbei darin, dass Garfinkel die Transkription schon zu seiner Zeit veranlasst hatte und in diese direkt etwa in Form von Korrekturen und Ergänzungen eingriff, sodass die Transkription als Vorlage für weitere Vorlesungsskripte dienen konnte. So stellt sich laut der Referenten zum einen die Frage nach dem Umgang mit Transkripten, die stark von der Tonspur abweichen. Zum anderen zeige sich hier der Bedarf nach einem AI-gestützten System, mit dem es sowohl möglich ist, ein genaues Audio-Transkript automatisch herzustellen als auch, das historische und das neue Transkript mit dem Audio parallel darzustellen.

Anders verhält es sich mit der von Dr. Jennifer Bunselmeier vorgestellten Digitalen Edition der griechischen und lateinischen Dichtungen von Lorenz Rhodoman (1546-1606). Bei diesem Projekt sind logischerweise keine Originalaudioaufnahmen vorhanden. Das Audiomaterial soll erst als Form der editorischen Anreicherung als Lesung des überlieferten Textes produziert werden. Da sich die Edition unter anderem an Lernende der lateinischen oder griechischen Sprache richtet, könne die Vertonung auf Vermittlungsebene dabei unterstützen, Aussprache und Metrik der Verse zu erlernen. Eine offene Frage sei hier, wie eine einfache Umsetzung realisiert werden kann, die für die Nutzer*innen eine unkomplizierte Handhabung gewährleistet, und welche technischen Modelle es dafür bereits gibt.

Beim Stasi-Unterlagen-Archiv im Bundesarchiv in Berlin entwickeln Prof. Daniela Münkel, Dr. Ronald Funke und Dr. Mark Laux unter dem Titel “Töne der Repression” eine Online-Edition aufgezeichneter DDR-Spionageprozesse. Aus dem Bestand von etwa 250 vollständig oder teilweise auf Tonband überlieferten Prozessen aus den Jahren 1952 bis 1989 erfolgt eine wissenschaftliche kommentierte Auswahl, die alle Jahrzehnte der DDR abdecken wird. Das im Vordergrund der Online-Edition stehende Tonmaterial soll zudem mit korrespondierenden Quellen wie Fotografien, Prozessprotokollen und weiteren Akten präsentiert werden. Im Bezug darauf wird bei der Projektkonzeption danach gefragt, was durch das Audio transportiert wird und wie dies hinreichend sichtbar gemacht werden kann. Was wird gesagt? Wie wird etwas gesagt? Wie agieren die Akteure miteinander? Wie klingt die Verhandlung? Dem Verständnis der Projektwissenschaftler*innen folgend, sind in den Tondokumenten im Vergleich zu schriftlichen Überlieferungen zusätzliche Bedeutungsebenen enthalten. So werden Stimmungen und Emotionen, Sprechpausen, Satzabbrüche, Stühlerücken oder auch das Lachen im Publikum wiedergegeben. Als Herausforderung zeige sich in diesem Projekt der Umgang mit der großen Menge des Tonmaterials durch die teilweise bis zu 20 Stunden langen Prozesslaufzeiten. Aus diesem Grund sei auch die Realisierung einer detaillierten Suchfunktion notwendig, mit der nicht nur die sprechenden Personen und ihr Wortlaut, sondern auch parasprachliche Elemente wie die Art des Sprechens, nichtsprachliche Äußerungen oder bestimmte Hintergrundgeräusche gefunden werden können.

Schon nach den ersten drei Vorstellungen von audio- bzw. audiovisuell-basierten Projekten konnten wir feststellen: Trotz der Heterogenität der Editionsvorhaben sind die Fragestellungen und Herausforderungen hinsichtlich des Umgangs mit Audiomaterial ähnlich. Um diese Erkenntnis konstruktiv zu nutzen, wurde vorgeschlagen, konzeptionelle Festlegungen und gemeinsame Begriffe zu schaffen. Diskutiert wurde außerdem die Frage, wie präzise und feingranular Auszeichnungen in der editorischen Aufbereitung von Audiodateien sein sollten. Finde eine allzu kleinschrittige und exakte Auszeichnung statt, so könne darunter die Übersichtlichkeit im Endprodukt und die Aufwand-Nutzen-Relation leiden. Dabei entstehe auch die Frage nach der Objektivität der Auszeichnung. Wird etwa ein Lachen im Audiomaterial nochmals differenziert in beispielsweise theatralisches und herzhaftes Lachen? Konsens besteht darüber, während des Entwicklungsprozesses einer Edition kritisch zu hinterfragen, für welches Forschungsinteresse und Nutzerpublikum die Edition produziert wird, um zu verhindern, sich in der Vielzahl der Möglichkeiten zu verlieren. Stattdessen solle die Zielvorstellung im Blick behalten werden. Indem die Entwickler*innen diese Benutzerperspektive einnehmen, könne ein Mittelweg zwischen einer Vollerschließung und einer bloßen Wiedergabe von Audiomaterial gefunden werden.

Das Dissertationsprojekt von Bastian Politycki mit dem Arbeitstitel “Paul Wühr: So eine Freiheit – Modell einer kritischen Audioedition” ist den bisher vorgestellten Projekten im Prozess der Einbindung von Audiomaterial einige Schritte voraus, indem bereits eine umfassende Datenmodellierung stattgefunden hat. In dieser digitalen Hörspieledition werden skripturale sowie audiophone Dokumente als TEI-XML Dokumente ausgearbeitet. Bei der Transkription des Hörspiels mit XML werden Schnitte, Geräusche, Musik bis hin zu einzelnen Worten kodiert. Die Webanwendung wird mit Svelte(Kit) erstellt. Hier wird der Hör- und Lesetext in Kapitel unterteilt dargestellt. Die Audiospur und deren Transkription laufen beim Abspielen parallel mit. Das Navigieren innerhalb eines Kapitels ist sowohl über das Audio als auch über die Partitur möglich. In einem “Textgenese Lab” lässt sich die Kollation anzeigen, um die Textgenese eines Kapitels darstellen zu können. Die Herausforderungen liegen in diesem Projekt bei der Frage, wie die Nachhaltigkeit der Edition gewährleistet werden kann, sodass sie zitierfähig bleibt. Außerdem gehe es in editorischer Hinsicht darum, in dem Hörspielformat, wie Paul Wühr es vorlegt, den Autor, Werk- und Textbegriff zu bestimmen.

Dr. Thomas Schmidt und Hanna Hedeland konnten den Teilnehmenden bestehende und erprobte Best Practices, Werkzeuge, Workflows und Standards im sprachwissenschaftlichen und sprachdokumentarischen Bereich vorstellen, die auch in der qualitativen Sozialforschung und den Oral History Studies angewendet werden. Neben Archiven für verschiedene Audioaufnahmen – von gesprochenem Deutsch bis hin zu gefährdeten Sprachen – wurde der bewährte Workflow vorgestellt. Bei all den im Folgenden beschriebenen Arbeitsschritten kann auf eine ausgereifte Tool-Unterstützung zurückgegriffen werden. Geprägt von Zyklen und Rückkopplungen enthält der Workflow die Datenerhebung, die Datenerschließung (EXMARaLDA Partitur-Editor), das Datenmanagement (Corpus Manager), die Datenpublikation (ZuMult) sowie die Datenanalyse (EXAKT, ein Analyse- und Konkordanztool von EXMARaLDA). Sprachwissenschaftlicher Standard ist unter anderem, dass alle Datensätze autorisiert sind und dass es eine einheitliche und konsistente Erfassung von Metadaten gibt. Darüber hinaus wurde ein ISO-Standard (ISO 24624:2016 Transcription of spoken language) festgelegt, der auf den Guidelines der TEI basiert. Aus diesem Vortrag ergaben sich die Fragen, ob die vorgestellten Tools generisch oder disziplingebunden sind und welche Potenziale zur Automatisierung noch ausgeschöpft werden können.

Am Ende des ersten Workshop-Tages ist klar: Der Austausch über audiobasierte Forschungsvorhaben und dabei entstehende Probleme ist ein Gewinn für alle Projekte. Die Problemlösungen, aber auch schon die Herausforderungen und Fragen der anderen Workshop-Teilnehmer*innen können auf das eigene Projekt bezogen werden, um passende Anregungen für spezifische Schwierigkeiten zu finden. Allen bisher vorgestellten Projekten sei gemein, dass das Parallelisieren von Handschriften und Audios und die zusätzliche Verbindung mit externen Dokumenten sowohl in technischer als auch methodischer Hinsicht die größten Hindernisse darstellen. Hinzu komme die Komplexität von Audiodateien, die zumeist nicht nur direkt gesprochene Sätze oder Wörter, sondern auch parasprachliche Ausdrucksformen wie Lachen und Husten sowie Hintergrundgeräusche (z. B. Stühlerücken) beinhaltet. Am ersten Workshoptag zeichnete sich die Frage ab, wie all diese Komponenten für die Nutzer*innen einer Edition auf einer Oberfläche modelliert werden können. Der erste Austausch ergab die Erkenntnis, dass die automatische Verbindung von Audio und Text sowie automatisches Transkribieren möglich ist. Außerdem gelte es bei der Arbeit an Projekten wie diesen neben dem Nutzen der Edition kritisch zu hinterfragen, wie ihre Offenheit gewährleistet werden kann, um eine transdisziplinäre Beschäftigung, d. h. Anschlussfähigkeit, zu ermöglichen.

Die DH@BUW beteiligen sich außerdem an dem Akademievorhaben “N. Luhmann – Theorie als Passion”, das Lena-Luise Stahn den Teilnehmenden des Workshops vorgestellte. In diesem Editionsvorhaben werden inbesondere der schriftliche Nachlass, daneben aber auch einige wenige Audioaufnahmen des Soziologen Niklas Luhmann (1927-998) verarbeitet. Hierbei handelt es sich um auditive Dateien, die Mitschnitte der Vorlesungen und Vorträge Luhmanns enthalten. Zum Teil existieren Manuskripte der Vorlesungen, die zukünftig mit dem Audiomaterial verknüpft, dargestellt werden sollen. Der Workflow besteht aus der automatischen Transkription der Audioaufnahmen per sonix.ai und der editorischen Glättung und Bereinigung. Darauf folgt die editorische Anreicherung, die Ergänzung von Literaturhinweisen, eine Kurzbeschreibung sowie Angaben zur Vorlesung bzw. zum Vortrag. Zuletzt werden die Daten manuell in XML/TEI übertragen. Ziel ist es, diesen Workflow zu vereinfachen und die Darstellung und Sprungmarken im Frontend auszubauen. In Frage stehe dabei, ob und ggf. wie Performativität ausgezeichnet und wie mit Abweichungen von Audio- und Manuskripttranskription umgegangen werden kann.

Das Projekt “VedaWeb 2.0. – Entwicklung einer kollaborativen Arbeitsumgebung für altindoarische Texte”, vorgestellt von DH@BUW-Kollegin Anna Fischer, beschäftigt sich mit der Weiterentwicklung einer digitalen Plattform zur Erforschung von Texten oraler Tradition in vedischem Sanskrit. Während aktuell die Bereitstellung neuer Texte und deren Übersetzung sowie die Anreicherung mit Annotationsschichten vorbereitet wird, steht in den kommenden Monaten unter anderem die Kuratierung von Audiodateien im Mittelpunkt, welche Rezitationen vedischer Hymnen enthalten. Ziel ist es im Hinblick auf die Plattform, dass Nutzer*innen angezeigte Textabschnitte (Verse) per Klick anhören können. Aktuell wird geprüft, ob eine automatisierte Kennzeichnung der Sprechpausen den manuell in ELAN erfolgenden Segmentierungsprozess sinnvoll unterstützen kann.  Das besondere Forschungspotenzial des Audiomaterials in VedaWeb liegt darin, lautliche und intonatorische Muster erkennbar zu machen, die in einer rein textbasierten Edition nicht greifbar werden. Daher soll es Nutzer*innen der Plattform auch ermöglicht werden, die Audiodateien für die Weiterverarbeitung exportieren zu können. Hierzu sollen exportierbare Formate nach Praat und ELAN genutzt werden. Wünschenswert sei außerdem die Möglichkeit, Hymnen in der Plattform unabhängig von der verszentrierten Darstellung anhören zu können.

Im Beitrag von Dr. Martha Stellmacher und André Eckardt wurden die gegenwärtigen Vorhaben der Sächsischen Landesbibliothek – Staats- und Universitätsbibliothek Dresden (SLUB) in Bezug auf Digitalisierung und Bereitstellung von audiovisuellen Materialien sowie die Weiterentwicklung von entsprechender Software vorgestellt. Im Rahmen des SAVE-Projekts digitalisiert und publiziert die Bibliothek Audio- bzw. audiovisuelles Kulturgut mit sächsischem Bezug und macht es über die Deutsche Digitale Bibliothek und die Mediathek der SLUB öffentlich zugänglich. Zudem wird fachliche Beratung angeboten, auch durch die an der SLUB angesiedelte Fachstelle Fotografie und Ton der Deutschen Digitalen Bibliothek, die deutschlandweit Institutionen dabei unterstützt, Bild- und Audio-Inhalte zu veröffentlichen. Darüber hinaus stellt die SLUB eine Infrastruktur zur Forschungsunterstützung zur Verfügung. Zum einen wird derzeit die Open-Source-Digtialisierungssoftware Kitodo weiterentwickelt, sodass sie auch als Workflow- und Präsentationstool für digitalisiertes audiovisuelles Material genutzt werden kann, in dem Timespans genau adressiert werden können. Diese Software wird zukünftig (neben der Präsentation der eigenen Sammlungen und der SAVE-Bestände) für das im Aufbau befindliche Audio-Repositorium Musiconn.audio im Rahmen des Fachinformationsdienstes Musikwissenschaft verwendet. Das Repositorium wird Wissenschaftler*innen ermöglichen, musikbezogene audio(-visuelle) Daten, die in Forschungskontexten entstehen und für weitere Forschung langzeitverfügbar sein sollen, zu publizieren. Zum anderen ist die SLUB an der Entwicklung des DFG-Viewers für musikalische Quellen beteiligt, der die kombinierte und synchronisierte Darstellung eines Musikwerks in seinen verschiedenen digitalen Repräsentationen (Notendigitalisat, maschinenlesbarer Notentext in MEI und Audio-/Videofiles) ermöglicht.

In einem letzten Vortrag stellten Herdis Kley und Dr. Cord Pagenstecher von der Freien Universität Berlin das Projekt “Oral-History.Digital“, eine Erschließungs- und Rechercheumgebung für Zeitzeugeninterviews, vor. Dabei handelt es sich um audiovisuelle Interviews als Gegenstand des erinnerungskulturellen Erbes und des kulturellen Gedächtnisses zur Würdigung von Überlebenden, deren Stimmen zu ihrer Zeit nicht an die Öffentlichkeit gelangen konnten. Charakteristisch für diese Interviews ist, dass sie narrative und performative Aspekte transportieren. Im Rahmen des Projekts wird eine Erschließungs- und Recherche-Plattform entwickelt, um diese Interviews wissenschaftlich zu sammeln. So können auch andere Institutionen und Forschungsprojekte ihre Daten archivieren, erschließen, zugänglich machen, annotieren und auswerten, was eine sammlungsübergreifende Recherche ermöglicht. In der Umsetzung wird das Audiomaterial detailliert segmentiert und verschlagwortet. Die Performativität der Interviews wird im Transkript mit aufgezeichnet, da sie aus Sicht der Projektwissenschaftler*innen für die Forschung unbedingt von Interesse sind. Dabei sei es eine Herausforderung, eine Nutzeroberfläche zu schaffen, die eine optimale Darstellung gewährleistet und zugleich Tiefenrecherche ermöglicht. Bei der Arbeit an diesem Projekt wurde festgestellt, dass die Frage danach, was aufbewahrt wird und was nicht, unter anderem von externen Bedingungen abhängig ist. Dieser Entscheidung müsse sich nicht nur die Forschung, sondern auch die Politik stellen.

Der zweite Workshop-Tag hat nochmals verdeutlicht, dass Audiomaterialen in den Digital Humanities als historische Objekte und Teile des kulturellen Erbes in ihrer Vielfältigkeit enorm spezifisch sind. Mit einem kritischen Blick auf die bisherige Erschließungs- und Editionspraxis konnte festgestellt werden, dass der Schwerpunkt bislang stark auf den Text gelegt wurde, wobei audiovisuelle Dateien und auch ein audiovisueller Fokus in einem digitalen Endprodukt weitestgehend außer Acht gelassen wurden. Durch den Workshop ist es gelungen, an die Relevanz von Audio in den Digital Humanities zu erinnern und zu erkennen, dass Tonmaterialien Forschungsräume eröffnen, die neue Forschungsfragen, -interessen und -instrumente zulassen.


Lehre @DH-BUW // Dokumente – Quellen – Editionen. Texterschließung mit TEI und Co. Sommersemester 2021

Nadine Sutor, WissMa @DHBUW

Mit den inzwischen gut etablierten Digital Humanities an der Bergischen Universität Wuppertal (BUW) nimmt auch die Ausweitung des Lehrangebots weiter Fahrt auf. Zwar sind die DH hier in der Geschichtswissenschaft angesiedelt. Die Konzeption der Lehrveranstaltungen verfolgte jedoch von Beginn an eine interdisziplinäre Ausrichtung. Interessierte Studierende aus allen geisteswissenschaftlichen Disziplinen sollen die Möglichkeit bekommen, einen sicheren Umgang mit digitalen Werkzeugen zu erlernen, ein Grundverständnis in der Arbeit mit XML-basierten Datenstandards, Markup-Sprachen und Semantic-Web Technologien auszubilden sowie von einer Vielzahl an praktischen Übungen profitieren. Damit leisten die digitalen Geisteswissenschaften am Standort Wuppertal einen wichtigen Beitrag zum Kompetenzaufbau und der Ausbildung des wissenschaftlichen Nachwuchses in Form einer jungen, nachrückenden Generation an „Digital Humanists“.

Im Sommersemester 2021 gab es nach einer zweijährigen Auszeit erstmals wieder eine praktische Übung zur philologischen Textauszeichnung mit TEI, in der die texttechnologische Kodierungspraxis in mehreren Beispielen exemplarisch eingeübt wurde. Mit 8 Teilnehmer*innen aus unterschiedlichen, nicht nur geisteswissenschaftlichen Disziplinen war die Anzahl der Studierenden übersichtlich. Einige brachten Vorwissen im Umgang mit Prozessen der elektronischen Datenverarbeitung.

Was ist TEI?

Die Text Encoding Initiative [1] (TEI) ist ein internationales Konsortium, das den maßgeblichen Standard zur Kodierung und zum Austausch von Texten in den Geisteswissenschaften entwickelt, der technisch in XML ausgedrückt wird. Die von der TEI formulierten Richtlinien haben sich für die Wiedergabe beliebiger Arten von Dokumenten und die philologische und historische Textauszeichnung etabliert. Hierzu spezifiziert die TEI eine Markupsprache, die die Datengrundlage für einen großen Teil der geisteswissenschaftlichen Forschungsvorhaben in unserer Zeit darstellt, die Bedienung unterschiedlicher Ausgabeszenarien ermöglicht und ihre Nutzung unter Anwendung von DH-Tools Werkzeugen erlaubt. Als Fundament für die Modellierung unterschiedlicher Textsorten und Genres bieten die Richtlinien nicht nur Kodierungsmöglichkeiten für die Wiedergabe, Erschließung, Annotation und kritische Edition von Texten, sondern erleichtern und unterstützen Vorhaben, die über die statische Präsentation eines Textes hinausgehen. TEI-basierte Daten dokumentieren die Entstehungsgeschichte, erlauben eine detaillierte Auszeichnung des dokumentarischen Befundes, verbinden Text und Bild und generieren variable Anzeigeformen.

Als fester Bestandteil des Studienverlaufs im Master Editions-und Dokumentwissenschaft (EDW) [2] ergänzt und erweitert die praxisorientierte Veranstaltung die Kompetenzen im philologischen und medientechnologischen Profil. Die texttechnologische Kodierungspraxis unter Anwendung des TEI-Standards bereichert jedoch nicht nur die Editionswissenschaft. Da das interdisziplinär ausgerichtete Regelwerk der TEI vielfältige Möglichkeiten der digitalen Textauszeichnung für nahezu alle geisteswissenschaftlichen Disziplinen bietet, profitieren beispielsweise die Geschichtswissenschaft, die Germanistik, die Literaturwissenschaften und die Philosophie von dieser Technologie, um nur einige Disziplinen zu nennen. In Kombination mit speziellen Schemasprachen und Werkzeugen hält die TEI einen ganzen Kosmos an Ideen für unterschiedliche Verwendungszwecke und Anwendungsgebiete in den Digital Humanities bereit.

Die Quelle(n)

Als zuvor aufbereitetes Spielmaterial dienten die Transkriptionen [3] der „Briefe aus dem Wupperthal“ [4] die der damals noch junge Friedrich Engels in seiner Bremer Zeit regelmäßig im „Telegraph für Deutschland“ [5] Ende des 19. Jahrhunderts unter dem Pseudonym „Friedrich Oswald“ [6] veröffentlichte. Einige Studierende brachten eigene Texte mit in die Übung. Material aus anderen Veranstaltungen oder aus Projekten, in denen sie aktuell arbeiten. In der Sitzung zu „Genrespezifischen Dokumentstrukturen“ sollten die Teilnehmer*innen jedoch auch mit anderen, ihnen unbekannten Gattungen und den damit verbundenen Herausforderungen, speziell die Kodierung betreffend, konfrontiert werden. Dazu zählt die Auszeichnung von Briefstrukturen, Dramen und lyrischen Texten.

Modellierung: Metadaten und Textbereich

Im Fokus der Sitzungen zur Datenmodellierung stand die Auszeichnung einfacher Textstrukturen und die Kodierung der Metadaten im teiHeader. Nach einer Einleitung in die XML-Technologie, dem Versuch einer Klassifizierung verschiedener Markup-Sprachen sowie der Vermittlung des Konzepts „logisches“ und „präsentationsorientiertes“ Markup und der Erläuterung von Wohlgeformtheit und Validität ging es unmittelbar an die TEI als standardisierte XML-Anwendung. In den textuellen Wissenschaften hat sich inzwischen eine Vielzahl gut etablierter Standards für die Auszeichnung von Dokumenten etabliert. Das betrifft sowohl die Beschreibung übergeordneter Strukturen wie Überschriften und Absätze als auch den semantischen Inhalt. Die Überleitung zur TEI bildete die Frage: Wie sieht es mit einem Standard für die digitale Beschreibung von Dokumenten in den Textwissenschaften aus? Ein stetiger Begleiter waren die TEI-Guidelines. Als modular aufgebautes Regelwerk bildeten diese Richtlinien die Grundlage für die praktische Arbeit und gleichzeitig Orientierung und Empfehlungen für die Studierenden.

Erschließung und Publikation

Als Vorbereitung auf die theoretische wie praktische Behandlung spezifischer Anwendungsfelder wie Personen- Orts- und Werkregister sowie Stellenerläuterungen und Kommentare sollte zusätzlich zur äußeren Textdarstellung auch eine inhaltliche Erschließung mittels sogenannter Named Entities erfolgen. Die Generierung und Einbindung selbst erzeugter Schemata für die Kontrolle der erstellten Daten bildete die vorletzte Einheit. Bevor es um die webbasierte Ausgabe von TEI-Dokumenten ging, mussten zunächst Konzept und Funktionsweise und insbesondere das Zusammenspiel der Transformationssprache XSLT und der Pfadsprache XPath vermittelt werden. Durch ein selbstgeschriebenes XSLT-Skript und unter Hinzunahme zweier relevanter Frontend-Technologien (HTML & CSS) publizierten die Studierenden ihre Daten in einer Webausgabe.

Tools: ROMA und TEI-Publisher

Ein wichtiger Bestandteil einer jeden Veranstaltung sollte der Einbezug von Tools, Werkzeugen und aktueller Software sein. In vielen Fällen unterstützt und erleichtern sie die Arbeit mit projekteigenen Daten. Für die Generierung des Schemas kam das Web-Frontend ROMA [7] zum Einsatz. Als eine Alternative zu XSLT wurde für die TEI-basierte Datenvisualisierung der in den DH inzwischen beliebte TEI-Publisher [8] unter Anwendung in zwei Beispielprojekten [9] vorgestellt.

11 Tipps aus der praktischen Projektarbeit: Luhmann, Rhodomanologia und Co.

Mit einer sehr aufschlussreichen und ausführlichen Präsentation über die praktische Anwendung der TEI in drei aktuellen Forschungsvorhaben gab uns Dr. Jennifer Bunselmeier, wissenschaftliche Mitarbeiterin am Lehrstuhl für DH in Wuppertal und Projektmitarbeiterin im Akademie-Vorhaben “Niklas Luhmann – Theorie als Passion” [10] in der letzten Sitzung wertvolle Einblicke in die projektspezifische Datenmodellierung und die damit verbundenen Herausforderungen. Größere und kleinere Etappen, die in keinem Workflow fehlen dürfen, sind zunächst eine Priorisierung der Arbeitsschritte, eine ausführliche Dokumentation aller durchgeführten Aktionen an und im Projekt, sowie die Einhaltung einer gewissen Ordnung. Letzter Punkt betrifft insbesondere die Organisation und Ablage der Daten. Der Entwurf einer modellhaften Visualisierung des Datenzyklus kann dabei helfen, Fehler im Workflow ausfindig zu machen. Der letzte Schritt einer Überprüfung aller Tasks sollte nicht nur am Schluss, sondern zwischendurch mehrfach wiederholt werden. Mit der Vorstellung dieser Tipps sollten die Studierenden einen Einblick in die praktische Projektarbeit bekommen und dafür sensibilisiert werden, wie wichtig jeder dieser Abschnitte für ein befriedigendes, vielversprechendes und vor allem nachhaltiges Endergebnis ist.

Fazit und Ausblick

Die TEI-Übung im Sommersemester 2021 war meine erste Lehrveranstaltung an der BUW. Sicher ist man vor dem offiziellen Start nervös. Es kommen Fragen auf: Ist das alles so richtig? Kann ich das so machen? Ist die Reihenfolge sinnvoll? Sind die Inhalte verständlich? Sollte noch ein Zwischenschritt kommen? […] Am Ende konnte ich stolz auf mich sein, denn es hat mir Spaß gemacht. Auch bei den Studierenden war eine gewisse Zufriedenheit, aber auch Erleichterung erkennbar. Erleichterung, weil die Welt der X-Technologien und den damit verbundenen Möglichkeiten auf den ersten Blick erschlagend und kompliziert wirken kann. Trotz dieser für einige doch schweren Materie fiel die Feedbackrunde positiv aus und brachte mir eine gute Rückmeldung. Nicht nur die Teilnehmer*innen, auch Kolleginnen und Kollegen, die gelegentlich vorbeischauten, gaben mir ein positives Feedback. Es ist schön zu sehen, wie wir (immer noch) im eigenen Team voneinander lernen können.

In wenigen Wochen geht es auch schon wieder los! Webtechnologien für Geisteswissenschaftler*innen wird es geben. Mit tatkräftiger Unterstützung von Lena Stahn und Stephan Makowski. Mal sehen, wie viele „Geistis“ sich dieses Mal in die digitale Welt wagen. Es gilt: no brackets, no fun!


[1] Offizielle Website des TEI-Consortiums: https://tei-c.org/, zuletzt geprüft am 02.08.2021.

[2] Vorstellung des Masters „EDW“ auf der Website der Bergischen Universität Wuppertal (BUW). Die Veranstaltung zum XML-basierten Datenstandard ist ein Pflichtmodul, das im Rahmen des Studienverlaufsplan als Pflichtkurs zu belegen ist. Startseite online verfügbar unter: https://www.edw.uni-wuppertal.de/de/home.html, zuletzt geprüft am 02.08.2021.

[3] In drei aufeinanderfolgenden Semestern erstellte der EDW-Master unter der Leitung von Bernd Füllner eine Vielzahl an Transkriptionen sämtlicher Werke von Friedrich Engels.

[4] Die Transkriptionen bildeten die Grundlage für die im Winter 2020 publizierte Print-Edition anlässlich des Engels-Jahrs in Wuppertal.
Neuerscheinung zum Engelsjahr. Wuppertaler Studierende bringen „Briefe aus dem Wupperthal“ neu heraus. Medieninformation auf der Website der BUW: https://www.presse.uni-wuppertal.de/de/medieninformationen/2020/12/09/32958-neuerscheinung-zum-engelsjahr-wuppertaler-studierende-bringen-briefe-aus-dem-wupperthal-neu-heraus/ zuletzt geprüft am 03.08.2021.

[5] Telegraph für Deutschland. Deutsche Kulturzeitschrift des 19. Jahrhunderts. Online verfügbar in den Digitalen Sammlungen der Lippischen Landesbibliothek Detmold. https://digitale-sammlungen.llb-detmold.de/periodical/titleinfo/6868786, zuletzt geprüft am 03.08.2021.

[6] Gelegentlich auch „F. Oswald“, und „Friedrich O.“

[7] Roma – ODD Customization. Web-Frontend online verfügbar unter: https://romabeta.tei-c.org/, zuletzt geprüft am 03.08.2021.

[8] TEI-Publisher. The Instant Publishing Toolbox. Projektwebsite online verfügbar unter: https://teipublisher.com/index.html, zuletzt geprüft am 03.08.2021.

[9] Eines der Projekte visualisiert einen mittelalterlichen Handschriftenkorpus in Form einer virtuellen Bibliotheksrekonstruktion. Das zweite Projekt präsentiert die Jahrgänge 1618 und 1619 der Frankfurter Postzeitung. Beide Projekte befinden sich aktuell noch in der Entwicklung.

[10] Projektwebsite online verfügbar unter: https://niklas-luhmann-archiv.de/, zuletzt geprüft am 03.08.2021.

Word validieren mit Schematron?

Wie kann eine Worddatei validiert werden, sodass daraus erfolgreich projektspezifisches TEI-XML transformierbar ist?

von Dr. Jennifer Bunselmeier

Abstract: Um aus einer Worddatei per XSL-Transformation saubere TEI-XML generieren zu können, müssen die Dateien vorgegebene Formatierungsregeln genau einhalten. Wie kann dies sichergestellt und eine kontextabhängige Qualitätskontrolle durchgeführt werden? Ich teste zwei Möglichkeiten: das Onlinetool Data2Check und ein projektspezifisches Schematron, das auf der Word-XML aufsetzt. Hier ein Zwischenbericht.

Die Frage der Nutzer(un)freundlichkeit von digitalen Tools ist ein Dauerthema in der DH-Community. Die editorische Arbeit in unserem Projekt startete 2012 unmittelbar in den XML-Dateien. Diesen Arbeitsmodus empfanden die EditorInnen jedoch auch nach mehrjähriger Einarbeitungszeit als aufwändig, unkomfortabel und vor allem als extrem störend für den geisteswissenschaftlichen Denk- und Arbeitsfluss. Sie fühlten sich in ihrer editorischen Arbeit mehr behindert als unterstützt.

Als Zugeständnis an die Kodierenden, die sich bei der Arbeit ein etwas wohlgefälligeres Layout wünschen, bei dem der Lesefluss nicht durch XML-Tags im Text gestört wird, hätte sich ein Wechsel zum Oxygen-Autormodus mit einem projektspezifischen Framework (oder angelehnt an Ediarum). Diese Option wurde jedoch seinerzeit aus verschiedenen insbesondere strukturellen Gründen nicht gewählt.

Stattdessen arbeiten die EditorInnen jetzt in Word. Da eine docx-Worddatei im Hintergrund auf XML basiert, kann sie durch eine Transformation, z. B. per XSL oder XQuery (Word2TEI-Transformation), in das gewünschte Zielformat TEI-XML übersetzt werden.1 Dieses TEI-XML wird dann über weitere Skripte in HTML transformiert und in der Onlineedition angezeigt. Auf diese Weise können die EditorInnen in der vertrauten graphischen Wordoberfläche arbeiten und das Ergebnis direkt in der Onlineedition veröffentlicht sehen, ohne selber mit den XML-Dateien arbeiten zu müssen.

Unabdingbare Voraussetzung für eine erfolgreiche Transformation von Word-XML zu TEI-XML sind allerdings klare 1:1 Übersetzungsregeln. Das bedeutet, für jedes Phänomen und jede Formatierung in Word muss festgelegt sein, in welches TEI-Element es übersetzt werden muss. Umgekehrt muss jedes TEI-Element des Projekt-Datenmodells eine eindeutige, identifizierbare Entsprechung in der Worddatei haben. 

Inzwischen hat sich dieser Word2TEI-Workflow im Projekt etabliert, weist allerdings drei große Schwachstellen auf, für die in naher Zukunft eine Lösung gefunden werden muss.


1. Viele Transformationsschritte  – viele Fehlerquellen


Abb. 1   Der Word2TEI-Worfklow im Projekt. Die EditorInnen sehen nur das Eingangsformat Word und das Endergebnis in der Onlineedition, nicht die Schritte dazwischen. Das erschwert die Fehlersuche.

Zwischen dem Ausgangsmaterial (formatierte Worddatei) und dem Endprodukt (HTML-Seite in der Onlineedition) stehen viele komplexe Arbeitsschritte und Skripte, was die Fehlersuche sehr aufwändig macht, falls das Resultat nicht den Erwartungen entspricht.

Ein typisches Beispiel: Die EditorInnen edieren in Word, starten die Transformation und bekommen eine HTML-Seite in der Onlineedition angezeigt. Dort fehlt der erwartete Titel des edierten Textes. Wieso erscheint er nicht in der Ausgabe, obwohl er in der Worddatei steht? Liegt der Fehler in den Anzeigeskripten? In den Transformationsskripten? Oder in der Worddatei?

Die häufigste Ursache: Der Titel wurde in Word versehentlich falsch formatiert, z. B. mit der Formatvorlage „Titel“ und nicht mit der Formatvorlage „Überschrift1“. Die Transformationsskripte übersetzen aber nur Text in der Formatvorlage „Überschrift1“ (nicht „Titel“) in das dafür vorgesehene TEI-Element <title>. Für die Onlineanzeige laufen anschließend weitere XSL-Skripte. Diese übersetzen normalerweise <title> in das HTML-Element <h1>. Da aber <title> im TEI-XML aufgrund der falschen Formatvorlage gar nicht erst kodiert wurde, wird es auch in der HTML-Version nicht als <h1> angezeigt. Im besten Fall wird es in der Onlineanzeige als „normaler“ Text innerhalb von <p> übernommen, im schlechtesten Fall gar nicht visualisiert.

 


Abb. 2       Eine falsche Formatierung in Word führt zu einer fehlerhaften HTML-Anzeige. Für die EditorInnen ist dieser Fehler in Word oft nur schwer zu erkennen, er offenbart sich erst ganz am Ende des Workflows in der fehlerhaften Onlineanzeige.

2. Formale vs. semantische Kodierung

Word kodiert nach Formateigenschaften, nicht semantisch. Das bedeutet, alle Textportionen, die exakt dieselben formalen Eigenschaften aufweisen, werden in einem Element zusammengehalten. Ob diese Textportionen auch semantisch zusammengehören, spielt dabei keine Rolle. Umgekehrt können Textportionen, die semantisch zusammengehören, aufgrund formal unterschiedlicher Eigenschaften getrennt voneinander kodiert werden. Formateigenschaften, die zu einer getrennten Kodierung führen, können z. B. sein:

  • Absatz
  • geschütztes (oder anderweitig wichtiges) Leerzeichen
  • Wechsel der Schriftschnitte/-arten/-größen
  • Wechsel der Sprache
  • einsetzende/endende Unterkringelung von Wort(-teilen) durch die Grammatik- oder Rechtschreibkorrektur

Einige dieser formalen Trennungen sind für die Weiterverarbeitung nützlich (z. B. können semantisch relevante Passagen gut durch unterschiedliche Schriftschnitte voneinander getrennt werden), andere sind irrelevant und müssen im Rahmen der Transformation bereinigt werden (z. B. Texttrennungen nur aufgrund von Rechtschreibfehlermarkierungen).

Um saubere, sinnvolle TEI-XML-Dateien zu generieren, muss die rein formale Kodierung der Word-XML also zunächst um irrelevante Informationen und Inhalte bereinigt und dann anhand der verbleibenden Formalia in eine semantische Kodierung übersetzt werden. Je komplexer die TEI-Zielkodierung ist, desto stärker ist die Transformation auf ein gut organisiertes Zusammenspiel von projektinternen Absatz- und Zeichenformatierungen, Positionierungen und Formulierungen innerhalb von Textstrings angewiesen.

Ein Beispiel: Eine typische kritische Fußnote wie „am Rand hinzugefügt lorem ipsum B“ soll übersetzt werden in eine TEI-Lesartenkodierung:

<app>
	<lem/>
	<rdg wit="#B">
		<add place="margin">lorem ipsum</add>
	</rdg>
</app>

Listing 1 Eine Lesartenkodierung nach TEI, generiert aus einer Word-Fußnote

Bei diesem Transformationsbeispiel werden verschiedene Formatinformationen ausgewertet:

  • Das Format „Fußnote“, beginnend mit kursiviertem Text, weist auf eine Kodierung zur Textkritik hin (anders z. B. Sachanmerkungen, die als Fußnote in recte gesetzt wären). Die gesamte Fußnote wird daher übersetzt in <app><lem/><rdg/></app> (und nicht z. B. in <note type=“footnote“/>).
  • Der kursivierte Textstring selbst entspricht einer von mehreren möglichen standardisierten textkritischen Wendungen. Eine Liste aller Wendungen und ihrer TEI-Entsprechungen ist bei der Transformation hinterlegt. So wird „am Rand hinzugefügt“ übersetzt in <add place=“margin“>, weitere Beispiele wären „im Korrekturverzeichnis hinzugefügt“ in <add type=“corrigenda“> oder „gestrichen“ in <del>.
  • Der Text „lorem ipsum“ in recte beinhaltet den eigentlichen Textinhalt, der innerhalb von <add place=“margin“> stehen soll.
  • Der Textinhalt endet, sobald nach einem Leerzeichen eine weitere kursivierte Passage folgt. Diese wird als Bezeichnung des Textzeugen interpretiert und dem umgebenden <rdg/>-Element als @wit-Attribut beigegeben.
  • Da es sich um eine Hinzufügung in einem anderen als dem Haupttextzeugen handelt, bleibt das <lem/> leer.
Abb. 3   Eine Fußnote kann anhand verschiedener Formatinformationen in eine TEI-Lesartenkodierung übersetzt werden

Dieses Beispiel verdeutlicht die Wichtigkeit exakt eingehaltener Vorgaben. Schon kleine Fehler wie das versehentliche Nicht-kursivieren des Textzeugen oder ein Tippfehler in der standardisierten Wendung können zu falschen Kodierungen führen.

3. Zu viele Freiheiten in Word

Ziel des Word2TEI-Workflows ist es, den EditorInnen zu ermöglichen, die beiden Schritte „freies, kreatives geisteswissenschaftliches Arbeiten“ und „Glätten und Einpassen in ein einheitliches, projektspezifisches Format“ nicht mehr gleichzeitig durchführen zu müssen. Stattdessen sollen sie diese nach eigenen Präferenzen in den Arbeitsablauf einbauen können. Das strukturelle Arbeitsumfeld von Word ist jedoch primär auf die Anforderungen des ersten Schrittes ausgelegt und bietet kaum Unterstützung für den zweiten Schritt.

Das Problem: In Word kann, anders als in XML, kein Schema eingebunden werden, das die Schreibenden direkt warnt, wenn sie etwas formulieren oder formatieren, was nicht den Projektregeln entspricht und in dieser Form entweder gar nicht oder auf eine nicht gewollte Weise transformiert würde.

Erschwerend kommt bei unserer Hybridedition hinzu, dass die Worddateien nicht nur die Grundlage für die XML-Dateien bilden, sondern auch als Basis für die Erstellung einer Printedition durch eine Setzerei verwendet werden. Das bedeutet, die Worddateien müssen gleich zwei formalen Ansprüchen genügen: 1. Die Formatierung muss in einer Art und Weise vorliegen, dass die Dateien problemlos in ein fehlerfreies TEI-XML-basiertes Datenmodell transformiert werden können. 2. Die Dateien aller BearbeiterInnen müssen ein einheitliches Format aufweisen und den Anforderungen an ein Druckmanuskript entsprechen, sodass beim Satz keine arbeitsaufwendige und kostenintensive Nachbearbeitung erfolgen muss.

Die Lösung für alle drei genannten Schwachstellen ist eine möglichst frühzeitige Qualitätskontrolle der Ausgangsdokumente. Ich habe zu diesem Zweck zwei Möglichkeiten getestet.

Möglichkeit A – Das Wordvalidierungstool Data2Check

Abb. 4 Data2Check – ein leicht zu bedienendes, individuell konfigurierbares Onlinetool. [Quelle: https://www.data2check.de/documentation/doku-word.html#regeln]

Vielversprechend ist das Tool Data2Check.

Data2Check ist ein komfortables, leicht bedienbares und individuell konfigurierbares frei zugängliches Onlinetool, mit dessen Hilfe man u. a. prüfen kann, ob Worddateien einer festgelegten Struktur folgen oder eine vorgegebene Terminologie verwenden. Ein Vorteil für EditorInnen: Erkannte Fehler können unmittelbar als Kommentar in der Worddatei zurückgegeben werden.

Das Tool kann Formatvorlagenabfolgen (Absatz und Zeichen) prüfen, z. B.:

  • Nach jeder Formatvorlage „Überschrift1“ muss genau einmal die Formatvorlage „Absatz ohne Einzug“ folgen.
  • Jedes Dokument muss (genau) eine Formatvorlage „Überschrift1“ und (mindestens) eine Formatvorlage „BearbeiterIn“ enthalten.
  • In der Formatvorlage „Zitat“ sind keine Zeichenformatvorlagen (Kursivierung etc.) erlaubt.
  • Bilder und/oder Tabellen sind nie erlaubt usw.

Spezielle Formulierungen sind per String oder Regular Expression (RegEx) suchbar, anzeigbar oder sogar direkt ersetzbar, z. B.:

  • Alle Dokumente sollen die Schreibweise „Onlineedition“ verwenden. Andere (explizit anzugebende) Schreibungen wie „online Edition“, „Online Edition“ oder „Online-Edition“ werden „angewarnt“ oder direkt ersetzt.
  • Datumsangaben müssen einem bestimmten Format entsprechen usw.

Ein absolut empfehlenswertes Tool!

Leider ist es für unsere Zwecke nicht weitreichend genug, denn: String-/RegEx-Abfragen und Formatvorlagen können nicht kombiniert geprüft werden. Genau das führt bei unserer Transformation aber oftmals zu Fehlern, denn die TEI-Elemente werden oft auf Basis von standardisierten Formulierungen innerhalb bestimmter Formatvorlagen generiert. So sind Wörter wie „gestrichen“ in einer Fußnote explizite Marker für eine ganz bestimmte Kodierung und ähnliche, aber falsche Formulierungen wie „durchgestrichen“ sind an dieser Stelle nicht erlaubt – an anderen Stellen im Text sind jedoch natürlich beide Wörter zugelassen, weil sie dort keine (oder eine andere) Funktion haben.

Möglichkeit B – Schematron für Word-XML

Da Word-XML auf XML basiert, ist es möglich, die Datei außerhalb des Wordprogamms zu validieren, noch bevor sie transformiert wird. Dabei soll sichergestellt werden, dass…

  1. alle Konstellationen, Formulierungen und Formatvorlagen, auf die die Transformationsskripte zugreifen, korrekt verwendet wurden,
  2. die EditorInnen so früh wie möglich eine Rückmeldung erhalten, wenn und wo(!) Fehler auftreten, die die Transformation stören oder verhindern.

Um XML-Dateien nicht nur rein syntaktisch, sondern auch kontextabhängig zu prüfen, bietet sich Schematron an. Dazu wird die Worddatei direkt im Oxygen-Editor geöffnet und mit einer Schematron-Schemadatei validiert.

Die ersten Versuche sind sehr vielversprechend.

Beispiel Titelei – Struktur gut prüfbar

Was mit Schematron sofort gut funktioniert, sind strukturelle Abfragen auf Formatvorlagenebene ohne (oder mit nur minimaler) Textbeteiligung.

Das obige Beispiel mit der fälschlich verwendeten Formatvorlage „Titel“ statt „Überschrift1“ lässt sich z. B. gut abbilden. Wenn an bestimmten Stellen im Dokument nur bestimmte Formatvorlagen erlaubt sind, kann für die Word-Kodierung der Formatvorlagen (<w:pStyle w:val=“…“>) in einem Schematron-<assert>-Test einfach eine feste Liste an Attributwerten für @w:val vorgegeben und jede Abweichung angewarnt werden.

Ein anderes Beispiel: alle unsere Worddateien müssen mit vier Absätzen in einer bestimmten Formatvorlage und mit standardisierten Angaben beginnen (Titel, BearbeiterIn, Datum und projektinterne Textnummer). Aus diesen werden wichtige Angaben für den <teiHeader> generiert. Danach folgt eine Leerzeile ohne Formatvorlage. Die ersten vier Absätze sind aufgrund der festgelegten Reihenfolge und des standardisierten Inhalts (u. a. ein festes Zahlenformat) gut prüfbar. Für die Leerzeile greift ein einfacher <report>-Test der sicherstellt, dass der fünfte Absatz im Dokument keinerlei Formatvorlagen-Styleinformationen und keinen Text enthält. Fehlt diese Leerzeile, scheitert die Transformation komplett, da die unmittelbar nachfolgende Struktur darüber entscheidet, welche Transformationsskripte angewendet werden und welche nicht, weshalb diese Prüfung besonders wichtig ist.

Beispiel Spracheinstellung und Sonderzeichen – Transformationsskripte entlasten

Da die Wordprogramme der EditorInnen in sehr unterschiedlichen Sprachen eingestellt sind, weisen die Dateien mitunter unterschiedlich benannte Word-Formatvorlagen auf (Überschrift1, Heading1, Titolo1,…) oder verschiedene per Autokorrektur ersetzte Anführungszeichen (typographische, französische,…). Diese Details sind für die EditorInnen nur schwer zu bemerken, führen jedoch zu großen Transformationsproblemen.

Aktuell müssen die Transformationsskripte deshalb per <choice>-Test vieles abfangen, was bei einer einheitlichen Formatierung in Word nicht nötig wäre.

Wird diese Art der Qualitätskontrolle aus den XSL-Transformationsskripten ins Schematron verlagert, ist das nicht nur methodisch sauberer, sondern entlastet zusätzlich die XSL-Skripte, macht sie weniger fehleranfällig und steigert dafür deren Performanz. Darüber hinaus sind Kleinigkeiten wie eine einheitliche Verwendung der Anführungszeichen für ein sauberes Druckmanuskript ebenfalls wichtig.

Beispiel Stringabfragen – Schematron um individuelle Funktionen erweiterbar

Die oben erwähnte Zerstückelung des Textes aufgrund formaler Kriterien führt dazu, dass String- oder RegEx-Abfragen beim Prüfen der Word-XML nicht ohne Weiteres funktionieren.

Glücklicherweise sah sich der Kollege, der seinerzeit die XSL-Skripte für die Word2TEI-Transformation geschrieben hat, mit demselben Problem konfrontiert. Seine Lösung: er hat XSL-Funktionen geschrieben, mit denen sich das Word-XML leichter parsen lässt.2 Darunter auch eine Funktion, die die Textblöcke wieder zusammensetzt, sodass Stringabfragen möglich sind. Auf diese Funktionen kann auch Schematron aufbauen, sodass eine Kombination von Formatvorlage und String abfragbar ist.


<xsl:function name="wt:string" as="xs:string">
	<xsl:param name="context" as="item()*"/>
	<xsl:value-of select="string-join($context//w:t, '')"/>
</xsl:function>
<pattern id="standardisierte_Wendungen">
	<rule context="w:footnote/w:p[w:r/w:t]">
		<let name="string" value="wt:string(.)"/>
		<report test="not(starts-with($string,'am Rand hinzugefügt') or starts-with($string,'gestrichen'))" role="warning">Bitte standardisierte Formulierung in der krit. Anm. prüfen.</report>
	</rule>
</pattern>

Listing 2 Eine XSL-Funktion wt:string() setzt die Word-Textblöcke aus w:t per string-join() zusammen. Die Funktion kann in einer Variablen oder direkt im <report>-Test aufgerufen werden.

Ein bislang ungelöster Schönheitsfehler ist die Genauigkeit in der Fehlermarkierung. Da derartige Abfragen den gesamten Inhalt von w:p (also einem Absatz) als String ansetzen und nur ein boolesches „String-enthält“ / „String-enthält-nicht“ zurückgeben, wird bei einer Fehlermeldung folglich der gesamte Absatz als fehlerhaft markiert, nicht eine konkrete Tippfehler-Stelle. Insbesondere bei längeren Abschnitten wäre eine präzisere Lokalisierung wünschenswert.

Ein Problem bleibt – zurück zum Oxygen

Für die EditorInnen dürfte der Anblick von Word-XML eine noch abschreckendere Wirkung haben als die Code-Ansicht von TEI-XML. Wie sollen Schematronwarnungen in Word-XML dabei helfen, in Word das eine Spatium zu finden, das versehentlich in der falschen Formatvorlage formatiert ist?

Lösung: Doch der Autormodus

Die erste und einfachste Möglichkeit ist die Anzeige der Word-XML in einem sehr einfachen Autormodus ohne komplizierte CSS-Stilanweisungen, in dem die fehlerhafte Stelle vom Schema möglichst präzise markiert wird. Die EditorInnen können die markierte Textstelle dann in ihrer Worddatei suchen und dort die Formatierung überprüfen. Diese Option nutzen wir aktuell und sie wird als durchaus zumutbar empfunden. Da kein projektspezifisches Framework verwendet wird, werden jedoch Auszeichnungen wie Kursivierung nicht wiedergegeben.

Abb. 5 Die Anzeige von Word-Fußnoten im Oxygen-Autormodus. Das Schematron warnt die falsche Formulierung „durchgestrichen“ an (richtig wäre „gestrichen“).

Vision: Schematronfehlermeldungen in Word zurückspielen

Eine elegante Lösung wäre ein Zurückspielen der Schematronfehlermeldungen in die Worddatei in Form eines Kommentars, wie es bei Data2Check möglich ist. Einen solchen Weg hat Colin Mackenzie auf der XML Prag (Februar 2020) vorgestellt3: Mithilfe einer XProc Pipeline4 können alle notwendigen Schritte automatisch nacheinander ablaufen: „Word.zip entpacken à Word-XML validieren à Schematronfehlermeldungen über XSL in Worddatei einfügen“. Ob sich diese Vorgehensweise auch für unser Projekt als effizient und praktikabel erweist, muss noch getestet werden.

Zwischenfazit zu Wordvalidierungstools

  Pro Contra
Data2Check
  • sehr einfach zu konfigurieren
  • grobe Struktur gut prüfbar
  • globale String- und RegEx-Abfragen möglich
  • Fehlermeldung direkt in Word möglich
  • Kombination von Stringabfrage und Formatvorlage nicht möglich
  • Regeln für komplexe Schachtelungen von Formatvorlagen nur bedingt möglich
Schematron
  • deutlich komplexere Abfragen und Konfigurationen möglich als bei Data2Check
  • erweiterbar um QuickFixes (Tauglichkeit noch zu prüfen)
  • Typisierung der Fehler in Error und Warnung möglich
  • alle Regeln in den Transformationsskripten können einzeln schon vorab geprüft werden, da mit XPath und den Funktionen dieselbe Sprache verwendet wird
  • Qualitätskontrolle (i.S.v. typische Fehler abfangen) muss nicht mehr in den XSL-Skripten während der W2T-Transformation stattfinden
  • Stringabfragen nur durch Erweiterung um eigene Funktionen möglich (dann aber Kombination von Stringabfrage und Formatvorlage möglich)
  • Fehlermeldung (erstmal) nur im Word-XML (=Oxygen-Autormodus) möglich
  • Word-XML (erstmal) nicht im Ganzen validierbar (da Text, Fußnoten, Endnoten und Kommentare jew. als einzelne XML gespeichert werden)

 

  1. Die Transformation muss nicht zwangsläufig selbst geschrieben werden, der TEI-Onlineservice OxGarage bietet automatische Transformationen für eine Vielzahl an Ausgangs- und Zielformaten an, darunter Word zu XML, TEI-XML oder Verbatim-XML. Die individuellen Projektanforderungen, insbesondere hinsichtlich der Transformation der Apparate, erforderten jedoch komplexere Eingriffe, als dies mit OxGarage möglich ist, daher wurde dieser Service nicht gewählt. []
  2. Zur Dokumentation siehe Dario Kampkaspars GitHub-Repository; Zusammenstellung aller Funktionen hier. []
  3. Mackenzie, Colin: Use cases and examination of XMLtechnologies to process MS Worddocuments in a corporate environmentToolset to test and improve the quality and consistency of styling in MS Word. (Vortragsmaterialien hier) []
  4. XProc ist eine XML-Sprache, die die Stapelverarbeitung beliebig vieler Eingangsdokumente (z.B. XML-Dateien) durch beliebig viele automatisch nacheinander ablaufende Verarbeitungsschritte (z.B. XSL-Transformationen oder Schematron-Validierungen) ermöglicht. []

„Du kannst ja immer noch Lehrerin werden!“

Meine Mutter, selbst Lehrerin und mit der nahenden Rente vor Augen, versucht mir regelmäßig ihre (auch nicht allererste) Berufswahl schmackhaft zu machen.

„Da hast du ganz schnell Routine und immer gaaaanz viele Ferien!“

An ihre Weisheiten muss ich denken am Vorabend meiner allerersten IDE-Winter School, der „Digitale Editionen – Masterclass“, die vom 22. bis 26. Februar 2021 theoretisch an der BUW, faktisch aber online stattfinden wird. Nun also tatsächlich: Eine Woche lang bin ich Teil eines Dozenten-Teams – und ganz und gar nicht überzeugt davon, dass das die Lösung aller Job-Probleme sein wird.

Achtzig Leute haben sich angemeldet! Was wohl weniger am Themenspektrum als vielmehr am „Meister“ Patrick Sahle als Host einerseits und an der so digitalen, ortsunabhängigen wie langweiligen Corona-Zeit andererseits liegt. Achtzig Leute, von denen gut fünfzigZugelassene sich ab morgen eine Woche lang im zentralen Zoom-Raum einfinden werden.

Zudem hat das Organisations-Team, bestehend aus Patrick Sahle, Torsten Roeder, Roman Bleier, Nadine Sutor und mir, in einem schwachen Moment während der Planung die grandiose Idee gehabt, das Beste aus fünf Tagen Zoom rauszuholen und die Nachmittags- und teilweise auch die Vormittagssessions in mehrere parallele Stränge aufzusplitten. Kleinere Übungsgruppen zum Preis von höherer Arbeitslast für jede*n.

Montag „Modellierung und Anwendung“

Wann: Montagmorgen, 8:30 Uhr, „… lädt Sie zu einem geplanten Zoom-Meeting ein. Meeting-ID: …“

Der Raum füllt sich, immer mehr he/him’s, she/her‘s, die überwiegende Mehrheit aber wohl unter dem Motto „ask me!“, interessieren sich offenbar für das so kryptische wie hochrelevante Montags-Thema Named Entities. Am Puls der Zeit? Möglicherweise schon einen Tick hinterher, aber genauso beabsichtigt: man will sein Pulver ja nicht gleich am ersten Tag verschießen. Und wer mit mangelnder Relevanz rechnet, wird durch die grandiosen Gast-Dozent*innen sofort in den Bann der Normdaten, Linked Data und Knowledge Graphs gezogen: Christiane Fritze und Christopher Pollin spannen den Bogen von semantischer Auszeichnungs-Theorie bis zu graphentechnischer Praxis, unterlegt mit einer Souveränität und Lässigkeit, die ihresgleichen sucht.

Nachmittags starten die Teilnehmenden in ihre erste Übungseinheit. Von mir wird (erstmals in dieser Woche) halbwegs Intelligentes zum Thema „Named entities semantisch ausdrücken“ erwartet…

Zur Belohnung gibt es abends das erste-Highlight der Woche: Vier Panelist*innen (Bärbel Kröger (Germania Sacra), Frederike Neuber (Berlin-Brandenburgische Akademie der Wissenschaften), Peter Stadler (Weber Gesamtausgabe), Georg Vogeler (ZIM Graz)) beharken sich zu „Best Practices und offene Fragen zu Named Entities in Editionen“. Oder vielmehr stimmen überein, zumindest dahingehend, dass es jede Edition irgendwie anders macht.

Der erste Tag endet mit einer Präsentation des Tools KBSET (Knowledge-Based Support for Scholarly Editing and Text Processing) und tiefe Einblicke in die Text-Editoren-Geschichte (#emacs). Allmählich trennt sich die Spreu vom Weizen…

Dienstag „Technologien: XSLT“

Wenn die Woche einen Höhepunkt hat, dann ist es der Dienstag. Nicht nur, dass heute das Thema ansteht, weswegen eigentlich alle hier sind, es wird noch dazu unterrichtet von der crème de la crème der XSLT-Gemeinde. Nachdem im Morgens-Slot Beziehungsprobleme („Ich liebe Dich so, wie Du bist, aber: Identity-Transform“), Konsumverhalten („Nimm doch gleich alles: copy() und copy-of()“) und die Polarisierung der Gesellschaft („Man liebt es oder man hasst es: Namensräume“) besprochen werden, lüftet Transformation-Veteran Thomas Meinike Experten-Geheimnisse in Sachen XSLT 3.0 und SVG. Themen und Tempo sind überwältigend, was den Lerneifer des Publikums meines Nachmittagsangebots zum Thema „TEI2RDF“ aber offenbar erst recht angefacht zu haben scheint. Nach anderthalb Stunden intensiver XSL-Transformationen haben die Teilnehmenden erfolgreich RDF-Daten produziert. Meine Erleichterung über den reibungslosen Verlauf feiere ich gemeinsam mit dem harten Kern und ein, zwei digitalen Gläser Wein am Abend im „Beatz und Kekse“, aka Kumospace,. So nahe liegen Höhen und Tiefen dieser Woche beieinander…

Mittwoch „Technologien: XML-DB und xQuery“

DER Tag aller Tage. Mein Hauptpart, zum allergrößten Glück gemeinsam mit Stargast Stephan Makowski (BUW), der Wunderwaffe zu allen Fragen und Problemen, die auf IT-Seite (unter anderem) bestehen könnten.

Unser heutiges Ziel ist es, eine grundlegende Idee von der Funktionsweise und Mächtigkeit von XML-Datenbanken einerseits und von XQuery als Ergänzung (die Alternative glaubt uns ja keiner) zu XSLT zu vermitteln. Hochgesteckte Ziele! Wenn ich vor den letzten beiden Tagen Muffensausen hatte, so geht mir jetzt der vielbesagte Arsch auf Grundeis. Nicht nur, dass wir uns vorgenommen haben, in anderthalb Stunden bei ca. fünfzig Leuten eine erfolgreiche eXist-db-Installation auf jedem einzelnen Rechner (und nein, wir haben nicht mit Apples neuester Sicherheitspolicy gerechnet, die Installation von Software „unbekannter Herkunft“ zu verweigern) zu versprechen, darüber hinaus sollen die Leute nach weiteren neunzig Minuten auch erste XQuery-Abfragen in dieser Datenbank machen können.

Wir ziehen unser Programm durch. Wieder einmal beruht der Erfolg der Sitzung im Wesentlichen auf der Souveränität des Vortragenden (das Gendern kann hier ausfallen, da ich mich ausdrücklich von dieser Aussage ausnehme). Jede noch so spezielle Einzelfrage (insb. auch die oben angedeuteten Installationsprobleme) bewältigt Stephan mit Engelsgeduld, nichts kann ihn aus der Ruhe bringen. Dieser Umstand scheint auch auf das Publikum zu wirken. Denn obgleich Thema und Technik die Nerven allseits stark strapazieren, ist der Großteil der Leute bis zum Schluss drangeblieben, jedenfalls dem Zoom-Panel nach zu urteilen. Vor allem gehen die meisten wohl mit wesentlich mehr Fragen als Antworten aus der Sitzung (Alpträume aufgrund dieses traumatischen Erlebnisses nicht ausgeschlossen), was spätestens in der Feedback-Runde am Freitag deutlich wird. Als persönliches Zwischenfazit zu diesem Tag steht für mich fest: Die verträgliche Publikumsgröße für die Themen eXist-db/XQuery ist bei zehn Leuten erreicht. Mac-User nicht miteinberechnet!

Wen dieser Tag nicht vollkommen erledigt und und entmutigt hat, findet sich abends zum „Open Forum: Projekte – Probleme – Lösungen Teil 1, konkretisiert an den Beispielen der Hebräischen Gelehrtenbriefen des 17. Jh. (Maximilian de Moliére) und Peter Handkes Notizbüchern (Vanessa Hannesschläger, Katharina Pektor, Johanna Eigner). Das Format scheint anzukommen, auch zur Mitte der Woche zeigen die Teilnehmenden reges Interesse und Diskussionsbedarf.

Donnerstag „Publikationsformen“

Der Donnerstag steht ganz im Zeichen des Publizierens. Ein Spitzenvortrag reiht sich an den nächsten. Patrick Sahle macht den Auftakt mit seinem Parforceritt durch Publikationsarchitekturen. Nach dieser Aufwärmübung führt Altmeister Wolfgang Meier in den TEI Publisher ein, erste Hinweise auf neueste Entwicklungen inklusive. Nachmittags kann dann im TEI Publisher-Übungsblock (Lars Windauer übernimmt) selbst Hand angelegt werden, bevor mit Alexander Czmiel (Berlin-Brandenburgische Akademie der Wissenschaften), Martin Prell (Universität Jena), Sibylle Söring (FU Berlin), Johannes Stigler (ZIM Graz) und Pascale Sutter (Schweizer Rechtsquellenstiftung / e-editiones) die zweite Ausgabe des Expertenpanels stattfindet. Zum Thema „Publikationsszenarien“ bieten die Diskutant*innen Einblicke in ihre Strategien, machen deutlich, wie offen die Frage nach der EINEN Lösung nach wie vor ist und stellen im Zeitalter des „software rot“ kaltblütige Forderungen, etwa nach der Modellierung sämtlicher Publikationsschichten, einschließlich der der Repräsentation (Stigler),  der Steigerung der Wertschätzung für digitale Editionsformen durch  Anreizsysteme (Söring), einer engen Verflechtung der Datenpublikation mit, wo möglich, der Lehre (Prell) und fordern eine formale Beschreibung der Digitalen Edition, „sodass diese jederzeit nachbaubar ist“ (Czmiel). Der bisher möglicherweise entstandene Eindruck, das Feld der Digitalen Editionen sei eine fest in ihren Strukturen und Methoden etablierte, vor allem aber nachhaltige Wissenschaft, wird hier gründlich über den Haufen geworfen.

Abgerundet wird dieser vorletzte Tag durch das Format „Open Forum: Projekte – Probleme – Lösungen“ Teil 2. Im Verlauf der Projektvorstellungen (Annelie Große zu „Quellenüberlieferung der preußischen Monarchie 1786-1918“, Marc Lemke zur Uwe Johnson-Werkausgabe) und abermals äußerst lebhaften Diskussion frage ich mich, ob die Winterschule ohne Lehrpersonal und ausschließlich bestehend aus „Open Forum“ womöglich effektiver wäre.

Freitag „Nachnutzung und Analyse“

Für den krönenden Abschluss am letzten Tag dieser Woche sind Gäste aus der DH-Community geladen: In parallelen Strängen geben sie den Teilnehmenden die Möglichkeit, eines von fünf Tools kennenzulernen und sich in dessen Anwendung zu üben. Zur Auswahl stehen Textvergleich und Textvarianz: LERA (Marcus Pöckelmann), Textanalyse I: CATMA und Dracor (Mareike Schumacher, Frank Fischer, Dominik Gerstorfer), Textanalyse II: DARIAH TopicsExplorer (Sina Bock, Evelyn Gayer), Geografische Informationen I: Recogito (Rebecca. Kahn) sowie Geografische Informationen II: Dariah Geo-Browser (Thomas Kollatz, Patrick Sahle et al.). Ob das Ziel der Übung erreicht wurde, also eine ungefähre Antwort auf die Frage „Und was macht man dann damit [i. e. mit den Daten]?“ gefunden zu haben, oder am Ende der Woche noch mehr Verwirrung besteht als zu Beginn, wird auch in der abschließenden Feedback-Runde nicht ganz deutlich.

Fazit:

Ein Fazit zu ziehen fällt mir nach dieser Woche voller Eindrücke sehr schwer. Eigentlich sind es viele „Fazite“, die sich ergeben. Das Wichtigste aber – und das trifft hoffentlich nicht nur auf mich zu –  Ich habe so viel gelernt! Auf jeder Ebene, in jeder Facette:

erweiterte Horizonte, neu entdeckte Themen und Fragen – vor allem sich an tollen Lehrer*innen, Kolleg*innen und Teilnehmer*innen ein Vorbild nehmen und an ihnen lernen zu können. Meine Mutter würde jetzt sagen: „Siehste! Lehrersein ist doch ganz einfach!“

Frankfurter Postzeitung 1615-1619. Zum Korrespondenzsystem.

… Kleine Datengeschichten. Kleine Visualisierungsgeschichten. Kleine Forschungsgeschichten …

Von Patrick Sahle

Titellose Zeitung, Titelbereich, die erste überlieferte Ausgabe #39 von 1615, beginnend mit einem Brief aus Köln: “für diesmal wenig neues …”

Das zunächst “namenlose”, in der Forschung aber als “Frankfurter” Postzeitung bekannte Periodikum, das seit 1615 nachgewiesen ist, gehört zu den ältesten Zeitungen überhaupt. Die Quelle war im Wintersemester 2020/21 Gegenstand einer Übung an der Bergischen Universität Wuppertal. Erste Metadaten zu Zeitungen und umfassende Digitalisate stehen an der Staats- und Universitätsbibliothek Bremen im Portal “Zeitungen des 17. Jahrhunderts” zur Verfügung. In der Übung wurden u.a. die Jahrgänge 1618 und 1619 unter Nutzung von Transkribus transkribiert und dann in TEI/XML in Anlehnung an die Regeln des DTABf weiter ausgezeichnet und erschlossen.

Frühe Zeitungen, wie auch die Frankfurter Postzeitung, bestanden im Prinzip aus Briefen, die von teils festen, teils losen Korrespondenten eingesandt und von einem Herausgeber, der in unserem Fall zugleich der örtliche Postmeister war, zusammengestellt und veröffentlicht wurden. Dabei ist weitgehend unbekannt, wer diese Korrespondenten waren und auch über die Transportwege und -bedingungen der Nachrichten wissen wir (Kursteilnehmer) noch wenig. Zu den vielfältigen Forschungsfragen an und mit den Postzeitungen gehören Fragen nach dem Korrespondenznetz und nach dem allmählich sich entwickelnden inneren Aufbau der Zeitung. Um hier systematischere Einblicke zu gewinnen, haben wir (Patrick Sahle und Jana Klinger, Anna Wibbeke für die Farbensprache) in der Übung aus den XML-Daten (siehe gitlab) mittels XSL-Transformation (ebenda) einen SVG-Diagramm-Typen (siehe Lehrstuhlserver) entwickelt, der für einzelne Jahrgänge über den Verlauf des Jahres und der Ausgaben die Reihung der eingegangenen und veröffentlichten Briefe sichtbar macht. Die Zeichnungen sind zu groß, um sie in dieser Blogplattformumgebung gut benutzbar in den laufenden Text einzubinden. Ein Klick auf die Vorschaubilder sollte aber zu den eigentlichen Diagrammen mit ihren vollen Funktionalitäten (Hovern, Skalieren) führen. Es empfiehlt sich, diese parallel geöffnet zu halten um den kommenden Ausführungen zu folgen.

1615

Beginnen wir exemplarisch mit dem ersten überlieferten – und vermutlich auch ersten erschienenen – Jahrgang 1615.

Korrespondenzdiagramm für 1615 (Vorschau)

Wie man sieht, sind für 1615 nur wenige Ausgaben überliefert. Die Ordnung der Briefe bzw. Absendeorte von oben nach unten in der Grafik entspricht der Reihenfolge in der Zeitung. Ort und Absendedatum lassen sich – nicht im Vorschaubild, sondern in der echten SVG-Grafik – als Tool-Tip beim Überfahren der Punkte mit der Maus näher inspizieren. Dabei erkennt man schon für dieses Jahr zwei Ordnungsprinzipien. Zum einen wird mit den älteren Absendedaten begonnen und neuere Nachrichten tendenziell nach hinten gestellt. Zum anderen werden Briefe aus gemeinsamen Absenderegionen tendenziell zusammen gebracht. Dies kann ein Hinweis darauf sein, dass sie auch zusammen transportiert wurden und dann gemeinsam in Frankfurt ankamen und redaktionell verarbeitet wurden. 1615 wurden so die Briefe aus Rom und Venedig und die Briefe aus Den Haag und Köln immer unmittelbar hintereinander gedruckt, auch wenn die strenge zeitliche Abfolge eigentlich zu einer Einsortierung anderer Briefe und zu einer Mischung der Absenderegionen geführt hätte. Das grundsätzliche chronologische Prinzip wird 1615 außerdem noch dadurch unterlaufen, dass die Briefe aus (Den Haag und dann) Köln in diesem Jahr immer am Anfang stehen, obwohl sie – aus Köln mit dem kürzesten Laufweg und damit dem rezentesten Absendedatum – eigentlich hinten stehen müssten.

Für das späte Jahr 1615 sieht man spätestens mit Ausgabe #42 schon gut das Prinzip der regelmäßigen Korrespondenten (Rom und Venedig bzw. Den Haag und Köln), die von einzelnen oder hin und wieder auftretenden Briefsendern ergänzt werden. Nachrichten aus dem Süden und dem Westen werden so vor allem von Briefen z.B. aus dem Südosten (Wien, Prag) und Osten (Magdeburg, Leipzig, Breslau) begleitet. Die “regelmäßigen Briefe” werden im Diagramm mit Linien verbunden, um diese Grundstruktur der Kommunikation sichtbar zu machen. Parallele Linien zeigen so die Stabilität der Ordnung, überkreuzenden Linien deuten auf “Störungen” der Ordnung hin.

Methodenkritisch ist hier zu bemerken, dass die Annahme und Visualisierung einer “regelmäßigen Korrespondenz” sich nicht automatisch aus Transkriptionsdaten ergibt, sondern schon eine Deutung ist, die in die extrahierten (Zwischen-)Daten eingeflossen ist. Hier sind ausgefallene Briefe als Orte mit Vermerk “fehlt” eingefügt wurden. Diese Einfügungen zerstören dabei leider eine andere Lesemöglichkeit des Diagramms: Die Menge der Punkte entspricht dadurch nicht mehr der Menge der Briefe. Wollte man also der Frage nachgehen, wie viele Briefe eigentlich in den Ausgaben zum Abdruck kamen, dann müsste man die gestrichelt umrandeten Punkte abziehen – was als rein visueller Eindruck nicht leicht möglich ist. Kritisch muss außerdem gesehen werden, dass zwangsläufig eine Einordnung fehlender Briefe an einem bestimmten Punkt in der Briefreihenfolge vorgenommen werden muss – diese Position aber nur hypothetisch sein kann.

1616

Korrespondenzdiagramm für 1616 (Vorschau)

Die skizzierten Strukturen der Korrespondenz setzen sich 1616 fort. Die regelmäßigen Briefe aus Den Haag und Köln stehen etwas chronologiewidrig am Anfang. Die regelmäßige Post aus Rom (in 18 von 25 Ausgaben enthalten) und Venedig (22 von 25) fällt manchmal aus. Auffällig ist hier die vertauschte Reihenfolge bei #32, die sich angesichts der ganz regelmäßigen Absendedaten überhaupt nicht erklären lässt. Ob man Korrespondenzpartner in Wien und Prag als “regelmäßig” bezeichnen möchte – darüber kann man sich für 1616 noch streiten. Regelmäßigkeit andeutende Verbindungslinien gibt es hier nur, wenn Orte in aufeinander folgenden (überlieferten) Ausgaben wiederkehren. Wegen der Abhängigkeit vom Überlieferungszufall ist dies methodisch durchaus diskutabel. Aus Prag liegen immerhin in 12 von 25 Ausgaben Briefe vor, aus Wien sind es acht.

1617

Korrespondenzdiagramm für 1617 (Vorschau)

Für das Jahr 1617 gewährt uns der Teufel, den wir Überlieferungszufall nennen, leider nur einen winzigen Blick durchs Schlüsselloch. Einzig Ausgabe #40 ist erhalten. Die Briefe aus Rom und Venedig sind wie üblich dabei. Den Haag und Köln ebenfalls, jetzt aber ganz am Ende der Ausgabe. Damit ist die Chronologie etwas konsequenter eingehalten. Allerdings verwundern dann die “falsche” Reihung Wien-Rom (27/9 – 23/9) und Venedig-Prag (30/9 – 3/9).

Insbesondere die Prag-Datierung (das Datum ist von der Briefposition her eigentlich mindestens 27 Tage zu früh) ist ein Beispiel dafür, welche weiteren Überlegungen sich aus der Positionierung von Briefen ergeben können: Vielleicht liegt ein Verschreiber für 30.Ditto. vor, vielleicht ist das “Ditto” aber auch vorgreiflich zum Brief aus Den Haag “vom 5. October”, so dass dann der 3. Oktober gemeint wäre. Das ließe sich in diesem Falle wohl durch weitere Quellen lösen, denn im Brief steht ja, dass Kaiser Mathias “gestern … allhier [in Prag] angelangt” sei. In anderen Fällen könnte die Beweisführung aber auch umgekehrt sein: dass die Datierungen aus den Zeitungen helfen, andere Quellen ins Rechte Licht zu setzen. Dafür kann es aber wichtig sein, die inneren Strukturen dieser Zeitungen genau zu verstehen.

1618

Korrespondenzdiagramm für 1618 (Vorschau)

Für 1618 ist die Überlieferung bis in den späten August dürftig, ab dann aber fast vollständig. Hier sehen wir zum Prinzip erhoben, was wir schon 1617 beobachteten. Die “alten” Nachrichten aus den langen Postwegen von Rom und Venedig stehen am Anfang der Ausgaben und die neueren Briefe aus dem Westen ganz am Ende. Zu Den Haag und Köln tritt jetzt im Westen mit Amsterdam ein dritter Absendeort, der erstmals in #16 erscheint und dann wieder in #35. Wegen der Überlieferungslücken kann man aber schlicht nicht sagen, ab wann es sich hier um einen “regelmäßigen” Korrespondenten handelt. Was man an der stets korrekten chronologischen Reihung deutlich sehen kann ist, dass Briefe wohl von Den Haag über Amsterdam (und nicht anders herum) nach Köln liefen. Was sich 1617 andeutete ist 1618 klar zu sehen: jede Woche laufen Briefe aus Wien und Prag ein. Dabei ist allerdings unklar, ob auch diese beiden zusammen einkamen oder getrennt. Die beiden Briefe stehen fast immer zusammen; zweimal schiebt sich ein weiterer Brief dazwischen, der dann aber aus der gleichen Richtung kommt. Zu bedenken wäre hier wohl auch, dass seit dem Sommer 1618 im böhmisch-pfälzischen Krieg Wien und Prag auf den verschiedenen Seiten des Konflikts lagen und man sich fragen muss, ob unter diesen Umständen briefliche Nachrichten wohl von Wien über Prag nach Frankfurt gelangten. Unabhängig von diesen Detailfragen sehen wir für 1618 einen sehr stabilen Aufbau der Zeitung und ihres Informationsnetzes: die sieben regelmäßigen Korrespondenzen werden nur fallweise durch weitere Briefe ergänzt. Nur 16 von 151 Nachrichten (10,6%) kommen nicht aus den Haupteinsendeorten.

1619

Korrespondenzdiagramm für 1619 (Vorschau)

Ordnungsprinzip und Korrespondenznetz bleiben auch 1619 stabil. Dennoch gibt es bemerkenswerte Entwicklungen. Mit Ausgabe #42 endet vorläufig die Korrespondenz aus Amsterdam – wenn es nicht die Überlieferungslücken zusammen mit den Unwägbarkeiten erfolgreicher Zustellung sind, die hier einen Fehlschluss verursachen. Denn wir sehen ja immer wieder einmal ausgefallene Briefe und können nicht sagen, ob sie einfach nicht geschrieben, oder nur nicht angekommen sind. Das Erstere scheint unwahrscheinlich. Gerade die Briefe aus Köln beginnen oft mit einer Floskel, dass eigentlich nichts zu berichten sei – geschrieben wird dann aber trotzdem. Einen interessanten Beleg für die misslingende Zustellung haben wir in Ausgabe #30. Die so zuverlässigen Briefe aus Rom und Venedig fehlen – dafür bildet eine Nachricht aus dem sonst nicht vorkommenden Ort Augsburg das Schlusslicht der Ausgabe. Und dort heißt es:

Die Ordinari Poſten auß Jtalia ſeyndt allererſt heut ankommen/ Vrſachen/
daß der Poſtknecht zu Baſſano in den Fluß della Brenta gefallen/ darüber dann
der gute Poſtknecht gar das Leben laſſen müſſen/ vnnd ertruncken/ das Pferdt hat
ſich ſaluirt/ weiln der Gurt alsbald gebrochen/ vnnd der Sattel ſampt dem Fellis
von jhm kommen/ gleichwol faſt alle Brieffe zu ſcheitern gangen.

Frankfurter Postzeitung, 30/1619, S. 4

Dies ist einer der ganz wenigen Auskünfte, die in der Zeitung selbst über die Kommunikationswege zu finden sind. Der Weg der Briefe ging offenkundig von Venedig über u.a. Bassano del Grappa und später u.a. Augsburg nach Frankfurt. Und da der Augsburg zugeordnete Abschnitt kein eigentlicher “Brief aus Augsburg” ist, sondern nur weitere verstreute Notizen aus dem Süden enthält, scheint die Post tatsächlich nicht vollständig “scheitern gegangen” zu sein.

Eine weitere Beobachtung betrifft den Umstand, dass seit 1619 manchmal gleich mehrere Briefe aus Wien und Prag bzw. zusätzlich aus mit diesen Städten verbunden Orten (nämlich den Feldlagern der beiden Kriegsparteien) gedruckt werden. Diese waren dann nicht im Wochenabstand verfasst, sondern nach zwei bis vier Tagen. Der Takt der Berichterstattung wird damit schneller, als der Rhythmus der Publikation. Der Charakter der Einzelbriefe bleibt hier immer gewahrt. Man wird ab 1620 sehen, wie der Herausgeber der Zeitung darauf reagiert.

Schluss

Mit dem Jahr 1619 verlassen wir die Entwicklung der Frankfurter Postzeitung. Die diagrammatische Schau basiert auf den Transkriptionen und ihrer analytischen Annotation in TEI/XML, die im Kurs nur bis hier vollzogen werden konnte. Die Produktion der Diagramme ist fast vollständig algorithmisch und durch Skripte automatisiert. Sie erfolgt allerdings in zwei Schritten. Zunächst werden aus den Transkriptionen die Briefdaten extrahiert und um die “fehlenden” Briefe der regelmäßigen Korrespondenten ergänzt. Aus diesem Datenbestand werden in einem zweiten Schritt die Diagramme berechnet.

Oben sind dazu im Vorübergehen schon einige methodische Bemerkungen gemacht worden. Vieles ließe sich dazu noch diskutieren. Die Balance zwischen datengetriebener algorithmischer Visualisierung und deutenden Eingriffen kann unterschiedlich ausgestaltet werden. Andere Aspekte einer Diagrammkritik können die Übersichtlichkeit, die Verständlichkeit und die “Suggestivität” der gewählten Lösung betreffen. Dazu gehören auch Formaspekte wie die gewählten Farben. Über diese haben wir lange nachgedacht und sehen hier keine perfekte Lösung. Die zu verdeutlichende Basisaussage war: Nachrichten kommen grundsätzlich aus drei Regionen: dem Süden (Italien), dem Südosten (Wien und Prag) und dem Westen (Den Haag, Amsterdam, Köln). Weitere ergänzende Briefe fallen dahinter quantitativ zurück, kommen oft aus den gleichen Regionen (Brüssel und Paris hinter Köln; Orte in Österreich-Ungarn und Böhmen hinter Wien bzw. Prag) und nur in einzelnen Fällen aus anderen Richtungen (dem Norden mit Hamburg oder Stockholm; dem Osten mit Leipzig oder Breslau). Ob diese Verhältnisse durch die Wahl von “Farbbereichen” mit “Unterfarben” wirklich gut sichtbar werden, ist schwer zu sagen – und hängt womöglich sogar vom individuellen Farbempfinden oder der Kalibrierung von Monitoren ab. Die Einteilung von Berichtsregionen ist darüber hinaus ein weiterer interpretierender und suggestiver Eingriff. Sicherlich könnte man die Gruppen auch ganz anders bilden.

Wozu das alles? Die Diagramme sind ein kleines Lehrstück. Ein Ergebnis von Kursarbeit. Historische Quellen, Erschließung, digitale Aufbereitung, Technologien (XML, XSLT, SVG), Datenvisualisierung, Visualisierungskritik – das fließt hier zusammen. Wie können wir historische Daten nutzen, um Erkenntnisgewinne zu erzielen? Wie spielen Fachfragen und digitale Verfahren zusammen? Wie verwandelt man unstrukturierte Textwüsten in anschauliche Diagramme? Und wie interpretiert man die dann? Bei diesen Versuchen war es uns auch wichtig, keine Standardtools und keine Standard-Bibliotheken der Visualisierung zu verwenden, sondern den ganzen Prozess selbst durchzuführen. Nur dadurch können nämlich wirklich neue Ansätze gefunden werden, die wirklich gegenstands- und fragestellungsgeleitet sind.

Die hier diskutierten Diagramme könnten noch in verschiedene Richtungen weiterentwickelt werden. Wünschenswert wäre z.B. eine stärkere Berücksichtigung und “Kartierung” der genauen Absendedaten. Dadurch würden andere strukturelle Phänomene sichtbar werden. Interessant wäre es auch, die Daten mit den bestehenden Standardwerkzeugen (Voyant, GeoBrowser, Palladio, Gephi etc.) oder Standardbibliothek (D3.js u.a.) zu traktieren. Wir haben hier aber absichtsvoll den zweiten Schritt vor dem ersten getan. Weitere können folgen.