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

E-Book-Export für digitale Editionen

Abstract

Einen (kostenlosen) E‑Book‑Output für eine digitale Edition zu erstellen ist technisch einfacher, aber konzeptionell herausfordernder, als zunächst gedacht.

Für die technische Umsetzung gibt es verschiedene Ansätze: Ich teste und diskutiere Softwarelösungen, das oXygen-interne TEI-P5-zu-EPUB-Transformationsszenario sowie eine eigene XSL-Transformation und vergleiche Möglichkeiten, E‑Books sowohl in den offenen EPUB- als auch den proprietären Amazon‑Formaten zu erstellen.

Konzeptionell stelle ich die Frage, ob sich interessierte Laien als neue Zielgruppe gewinnen lassen und ob diese überhaupt über die üblichen Plattformen erreicht werden können. Zudem untersuche ich, welche Teile wissenschaftlicher Editionen sich überhaupt für eine lineare Lesefassung eignen und wie stark ihre Inhalte dafür vereinfacht werden müssen.

Inhalt

 

Als jemand, der sehr gerne und sehr viel Literatur im E‑Book‑Format liest, stellte ich mir die Frage, ob man nicht die Inhalte der digitalen Editionen[1], an denen ich mitarbeite, als E‑Book zur Verfügung stellen könnte.

Aus dieser naiven Ausgangsfrage entwickelten sich schnell drei konkrete Folgefragen:

  1. Gibt es einen Bedarf?
  2. Wer ist die Zielgruppe und was bedeutet das für die Konzeption?
  3. Wie ist es technisch umsetzbar?

1. Bedarf

Zur Frage nach dem Bedarf war das ernüchternde Ergebnis einer ersten (nicht repräsentativen) Umfrage: kennt keiner, nutzt keiner, bietet keiner an. Auch eine Onlinesuche nach Editionsprojekten, die einen E‑Book‑Output anbieten, war nicht erfolgreich[2].

Aber bedeutet das, Editionen bieten keine E‑Books an, weil sie niemand lesen will? Oder liest niemand E‑Books, weil keine Edition sie anbietet?

Da kommerzielle Wissenschaftsverlage durchaus E‑Books vertreiben, unterstelle ich, dass es einen Markt gibt, das grundsätzliche Interesse also da ist. Im naturwissenschaftlichen Bereich sind digitale Publikationen ohnehin gang und gäbe und auch im geisteswissenschaftlichen Bereich werden viele Titel – selbst von textkritischen Editionen – zumindest auch als E‑Book neben einer Printversion angeboten. Einer Umfrage[3] aus dem Jahr 2024 nach lesen zumindest 40% der Befragten „hin und wieder” E‑Books (und 81% gedruckte Bücher), wobei die Akzeptanz bei jüngeren Leuten deutlich höher ist (50%) als bei älteren (ab 65 Jahre: 15%) Aber in Anbetracht der Tatsache, dass schon der Ausgangspunkt – die digitale Edition – stärker von einer jüngeren Zielgruppe genutzt wird, ist diese Diskrepanz für die weiteren Überlegungen nicht relevant.

Wenn ein Editionsprojekt seine Inhalte zusätzlich als E‑Book zur Verfügung stellt, scheint das somit zunächst eine kostengünstige Möglichkeit zum Hybrid-Selbstverlag zu sein. Die Herausforderungen beim Selbstverlag sind natürlich bekannt: Oft fehlt es in Projekten an Ressourcen und Know-how in Bereichen wie Layout, (Fein-)Typografie und Satz. Aber während im professionell gedruckten Buch hohe gestalterische Ansprüche gelten, die mit eigenem PDF‑Output nur selten erreicht werden, verschiebt sich der Fokus beim E‑Book auf andere Aspekte. Entscheidend ist nicht mehr eine perfekte visuelle Gestaltung, sondern im Gegenteil eine saubere technische Umsetzung, die flexible Ansichten ermöglicht und auf unterschiedlichen Geräten zuverlässig funktioniert. Ist das ein Vorteil für Editionsprojekte?

Zusammengefasst: Einen konkreten Bedarf kann ich zwar nicht nachweisen, aber um nicht an dieser Stelle bereits abbrechen zu müssen, unterstelle ich ein grundsätzliches Interesse, das dem allgemeinen Trend zur steigenden E‑Book-Nutzung folgt.

2. Konzeption

E‑Books sind digitale Bücher, die auf speziellen Geräten (E‑Readern) oder Apps gelesen werden. Sie unterscheiden sich von gedruckten Büchern (und statischen PDFs) dadurch, dass die LeserInnen die Darstellung nach ihren individuellen Wünschen anpassen können (etwa Schriftgröße und -art verändern) und von digitalen Textformaten wie HTML dadurch, dass sie nur sehr reduzierte Funktionalitäten bieten (etwa nur eine begrenzte Einbindung von Medien und kaum interaktive oder dynamische Zugangsmöglichkeiten).

Bevor es an die technische Umsetzung geht, muss zunächst das Ziel abgesteckt und konzeptionell durchdacht werden. Wie sich herausstellte, ist dieser Schritt deutlich komplexer, schwieriger und wichtiger, als anfangs gedacht und wirft einige sehr grundsätzliche editorische Fragen auf.

2.1 Allgemeine konzeptionelle Überlegungen

Zunächst die naiven, naheliegenden Überlegungen. Da es sich bei Editionen – insbesondere bei textkritischen und/oder synoptisch angelegten – um hochgradig strukturierte, heterogene Daten handelt und E‑Books lediglich eine stark reduzierte Ausgabe erlauben, ist es entscheidend festzulegen, welche Informationen wie abgebildet oder weggelassen werden.

Da E‑Books noch mehr als gedruckte Bücher linear gelesen werden (müssen), stellen insbesondere Inhalte, die auf eine starke interne Vernetzung setzen, ein Problem dar. Links sind in E‑Books zwar möglich, aber auf E‑Readern ist das Hin- und Herspringen oder Blättern über längere Abschnitte hinweg unkomfortabel. Das heißt, in einer idealen E‑Book-Welt lässt sich der Text ohne nennenswerten Informationsverlust linear von vorne bis hinten durchlesen, was allerdings der Realität und dem Anspruch vieler Editionen entgegensteht, die möglichst viele verschiedene, gerade nicht linear vorgegebene Zugänge zum Material bieten wollen.

Dynamisches Ein- und Ausblenden von Segmenten, z. B. Popups, oder ständiges Hin- und Herspringen zwischen Haupttext, Apparaten, Registern oder gar externen Webressourcen ist auf den meisten E‑Readern nicht möglich[4]. Das bedeutet, der Text muss auch ohne diese Ebenen in sich geschlossen und verständlich sein.

Auch dürfen weder das Textverständnis noch die Struktur von der visuellen Gestaltung abhängen. Da Layout und Satz im E‑Book nicht statisch sind, sondern sich je nach Gerät, Bildschirmgröße und Nutzereinstellungen verändern, müssen die Inhalte unabhängig von ihrer Präsentation erkennbar bleiben. Seitenumbrüche sind fluide und insbesondere ältere Geräte unterstützen keine Farben, sondern ausschließlich schwarz-weiße Darstellungen. Strukturen, die stark auf visuelle Unterscheidungen oder Positionierung setzen – etwa die Präsentation verschiedener Textzeugen oder Übersetzungen nebeneinander, farbliche Hervorhebungen, typografische Differenzierungen, Texteinrückungen oder Positionierung von Marginalien – lassen sich deshalb nur eingeschränkt oder gar nicht umsetzen.

Medien wie Bilder, Videos oder Audiodateien werden von nur von wenigen E‑Readern überhaupt dargestellt und führen zu einem enormen Anstieg der Dateigröße, was sich negativ auf die Ladezeiten und die allgemeine Performance auswirkt.

Typische Aspekte einer Edition, die aufgrund der genannten Eigenschaften gekürzt, vereinfacht oder ganz weggelassen werden müssen, sind z. B.:

  • Zentrale Informationen
    • Apparate (z. B. Sachanmerkungen, Textkritik, Varianten)
    • Overlay-Informationen (z. B. Popups, Tooltips)
    • Externe Vernetzung (z. B. Normdaten, Digitalisate)
  • Ordnung/Hierarchisierung der Informationen
    • Synoptische Darstellungen (z. B. Textzeugen, Übersetzungen)
    • Hervorhebung (z. B. Farben, Schriftgröße, Positionierung)
  • Alternative Zugänge zum Material
    • Register (z. B. Personen, Orte, Werkzusammenhänge)
    • Visualisierungen (z. B. Illustrationen, Graphen, Karten)
    • Medien (z. B. Audio, Video)
    • Suche/Filter (z. B. individuelle Korpuszusammenstellung, Ansichten-/Suchfilter)

Auch wenn die konkrete Zielgruppe eingangs nicht sicher umrissen werden konnte, muss ich doch wieder auf diese Frage zurückkommen. Denn um zu entscheiden, welches die wesentlichen Teile einer Edition sind und welche weggelassen werden können, müssen zwei Seiten zusammengebracht werden: 1. was die EditorInnen als das Wesentliche ihrer Arbeit ansehen und 2. was – in welchem Kontext – für die LeserInnen das Wesentliche ist.

Das Ergebnis einer – wieder nicht repräsentativen – Umfrage war, dass diese beiden Seiten mitunter deutlich auseinandergehen. Für LeserInnen steht beim E‑Book der unkomplizierte Zugang zum Inhalt im Vordergrund. Sie wünschen sich einen interessanten und flüssig lesbaren Text, ohne sich mit komplexen wissenschaftlichen Hintergrundinformationen auseinandersetzen zu müssen. Elemente wie textkritische Apparate, Variantenvergleiche oder vielschichtige Querverweise sind von nachgeordneter Bedeutung. Für EditorInnen hingegen steckt gerade in diesen wissenschaftlichen Ebenen ein zentraler Teil ihrer Arbeit. Werden sie weggelassen, bleibt ein wesentlicher Teil ihrer editorischen Leistung unsichtbar.

Dieses Spannungsverhältnis lässt sich leicht auflösen, wenn man das E‑Book nicht als den Output der Edition versteht, sondern lediglich als einen von mehreren, die alle auf unterschiedliche Zwecke hin gestaltet sind – beim E‑Book eine einfache Lesefassung. Genauso, wie auch eine gedruckte Fassung einen anderen Schwerpunkt setzt als beispielsweise die Darstellung in Form einer Graphdatenbank oder eine Parallelansicht von Text und Faksimile.

Eine – in welcher Form auch immer vorgenommene – Reduzierung auf einen einzigen Lesetext ohne Varianten oder vertiefende (sprach-)wissenschaftliche Erklärungen lässt sich vielleicht mit dem Ansatz von Reclam vergleichen: Das Ziel ist, „Bildung für alle zu ermöglichen”, indem „Leserinnen und Lesern jeden Alters Zugang zu Literatur – mit Klassikern der Weltliteratur” ermöglicht wird, durch die „verständliche […] und zeitgemäße […] Aufbereitung anspruchsvoller Inhalte”.[5] Reclam-Ausgaben sind eine niederschwellige, kostengünstige Möglichkeit, sich mit Texten verschiedenster Gattungen und Epochen auch außerhalb des eigenen Fachs zu befassen, einfach, weil sie einen interessieren. Wissenschaftliche (digitale) Editionen hingegen wirken oft unübersichtlich, abschreckend und zum einfachen Lesen zu kompliziert.

Ein Editor formulierte in diesem Zusammenhang einen sehr wichtigen Gedanken, der in wissenschaftlichen Editionsprojekten meines Erachtens oft untergeht: Warum nicht die edierten Texte auch für interessierte Laien zugänglich machen? Ein E‑Book‑Output kann meines Erachtens genau das leisten, indem es die Forschungsergebnisse auf niederschwellige Weise über den engen wissenschaftlichen Kreis hinaus einem breiteren Publikum näherbringt.

Aber dann wurde ich mit der berechtigten Frage konfrontiert, wie sich eine so radikal gekürzte E‑Book-Version rechtfertigen lässt, wenn doch auch eine PDF-Fassung erstellt werden kann, die auf der einen Seite viele der wissenschaftlichen Hintergrundschichten, z. B. Apparate, beibehält, es den LeserInnen aber auf der anderen Seite freistellt, diese bei Bedarf einfach zu überspringen. Warum also reicht eine PDF nicht aus?

Meiner Ansicht nach ist hier vor allem ein Argument ausschlaggebend: Barrierefreiheit. Nicht nur Menschen mit Behinderungen profitieren von barrierefreien Angeboten, sondern alle, da diese im Idealfall besonders durchdacht, klar strukturiert und intuitiv gestaltet sind. Weil bei PDFs das Layout starr ist, müssen sie auf kleineren Geräten oder Bildschirmen wie Handys, Tablets und E‑Readern umständlich gezoomt und gescrollt werden. Das macht die Nutzung schwierig und für Personen mit Einschränkungen mitunter gänzlich unmöglich. E‑Books hingegen sind deutlich inklusiver: Sie lassen sich mit Screenreadern nutzen, Schriftgröße und Kontrast können individuell angepasst werden, und der Text kann vorgelesen oder in Blindenschrift umgewandelt werden.

Zudem zwingt die Arbeit an E‑Books dazu – so meine Erfahrung der letzten Monate –, die edierten Inhalte unabhängig von ihrer visuellen Präsentation wieder mehr als Daten zu betrachten. Denn wenn „[v]isuelle Gewichtungen durch Farbe, Schriftgröße oder Positionierung […] bei der Nutzung von Screenreadern oder Braillezeilen verloren gehen”[6], müssen die wesentlichen Teile der Edition ohne diese visuellen Hilfsmittel identifiziert, strukturiert und hierarchisiert werden, was zu einer neuen Auseinandersetzung mit den eigenen Inhalten anregt.

2.2. Der konkrete Anwendungsfall – vier Projekte

Die Entscheidung, in welcher Form – und ob überhaupt – sich eine Edition für eine E‑Book-Fassung anbietet, kann natürlich nicht global, sondern nur für jedes Projekt einzeln getroffen werden. In meinem Fall kommen die folgenden vier Projekte in Frage, die sich hinsichtlich Fachbereich, Umfang und Inhalt stark unterscheiden.

Rhodomanologia: eine textkritische Edition spätmittelalterlicher altgriechisch-lateinischer Lyrik (Klassische Philologie)

Die Texte dieser Edition eignen sich sehr gut für einen E‑Book‑Output. Derzeit umfasst die Edition etwa 75 Gedichte des Dichters und Schullehrers Lorenz Rhodoman zu Themen wie Bibelkunde, Theologie, griechischer Mythologie und Schul- und Bildungsgeschichte sowie persönliche Briefgedichte und Grabinschriften. Obwohl das Projekt seinen Forschungsschwerpunkt auf literarische und metrische Analysen legt, sind die Inhalte durch ihr breites Themenspektrum auch für interessierte Laien zugänglich. Hinzu kommt, dass viele Gedichte zweisprachig in Griechisch und Latein überliefert (und vom Projekt auf Deutsch übersetzt) sind, was sie zusätzlich für Studierende der Altphilologie interessant macht.

Niklas-Luhmann-Archiv: eine textkritische Edition des wissenschaftlichen Nachlasses von Niklas Luhmann (Soziologie)

Der Nachlass des Soziologen Niklas Luhmann ist deutlich diverser und eignet sich nur zum Teil für einen E‑Book‑Output. Der Nachlass besteht aus zwei Hauptkomplexen: einem Zettelkasten mit etwa 90.000 Zetteln sowie etwa 3.900 Manuskripten, bzw. Typoskripten. Aber das Projekt lebt zusätzlich vor allem von seiner bibliographischen Datenbank, die aktuell etwa 2.700 Bücher und Aufsätze enthält, die von Luhmann selbst verfasst wurden, sowie weiteren 14.000 Titeln, die er in seiner privaten Arbeitsbibliothek stehen hatte und/oder nachweislich bei der Entwicklung seiner Theorien herangezogen und zitiert hat. Diese bibliographische Datenbank ist immens wichtig für die Forschung, aber kein Inhalt, der sich zum gemütlichen Lesen als E‑Book anbietet.

Auch die Zettel enthalten vor allem Stichworte, Gedanken, Argumente und Literaturhinweise, die erst durch ihre exzessive Vernetzung das Gesamtwerk ausmachen, aber für sich alleine genommen eher wenig unterhaltsam zu lesen sind.

Die Manuskripte wiederum sind entweder stichpunktartige Vortrags- und Vorlesungsskripte oder sorgfältig konzipierte Aufsätze oder Monographien, die zur Printpublikation vorgesehen waren. Allerdings liegen diese oft in verschiedenen Bearbeitungsfassungen vor und müssten erst editorisch zu einer finalen Fassung zusammengesetzt werden. Die Edition versucht zwar, die oft stark annotierten Fassungen so aufzubereiten, dass sich ein Lesetext konstituieren ließe, allerdings sind dafür trotzdem zu viele editorische Einzelfallentscheidungen notwendig, als dass sich ohne Mehraufwand eine gute E‑Book-Fassung automatisiert erzeugen ließe. Das wiederum ist aber eine Voraussetzung, um einen E‑Book‑Output sinnvoll und ressourcenschonend in den bestehenden Projektworkflow zu integrieren.

VedaWeb: eine linguistische Forschungsplattform für altindische Hymnen (Indologie)

Das VedaWeb-Projekt scheint auf den ersten Blick die Voraussetzungen für einen E‑Book-Export perfekt zu erfüllen. Es stellt auf einer Plattform insgesamt sechs in sich geschlossene, vedische (indogermanische Sprache, Vorgänger des Sanskrit) Texte mit Hymnen von ca. 1300–1000 v. Chr. zusammen, die von großer historischer und religiöser Bedeutung sind. Zwar liegt der Fokus des Projektes auf der linguistischen und philologischen Arbeit, aber eine Lesefassung ließe sich recht einfach extrahieren. Allerdings ist das Projekt nicht als Editionsprojekt angelegt, sondern als „kollaborative Forschungsumgebung”, auf der die zur Verfügung gestellten Texte „von den BenutzerInnen der Plattform mit verschiedenen Arten von Annotationen, verfügbaren Übersetzungen sowie mit Links zu Wörterbuch-Einträgen angereichert werden können”[7]. Das bedeutet, das Projekt erstellt keine eigene Edition der Texte, sondern trägt bestehende Editionen zusammen. Daraus eine E‑Book-Lesefassung zu generieren, wirft somit Urheberrechtsfragen auf, die erst sorgfältig geprüft werden müssten. Zudem sind die Texte so bekannt und wichtig, dass sie bereits als E‑Books in mehreren Sprachen verfügbar sind.

Astronautilia (in Vorbereitung): eine textkritische Edition eines neuzeitlichen, altgriechisch-tschechischen Sci-Fi-Romans (Klassische Philologie)

Der Text dieser Edition eignet sich vermutlich am besten für einen E‑Book‑Output. Das Projekt befindet sich zwar noch in Vorbereitung, aber gerade deshalb kann die E‑Book-Fassung besser als bei den anderen Projekten von Anfang an mit bedacht werden. Inhaltlich geht es um ein außergewöhnlich bizarres Werk: ein Science-Fiction-Epos in ca. 6.600 Versen aus den 1990ern, verfasst auf Altgriechisch und Tschechisch. Im Rahmen des Projektes wird eine deutsche (möglicherweise auch eine englische Übersetzung) erstellt, während der fachwissenschaftliche Fokus wie bei Rhodomanologia auf der literarischen und metrischen Analyse und der Kommentierung liegt. Der außergewöhnliche Inhalt des Textes macht eine Lesefassung für ein deutlich breitgefächerteres Laienpublikum interessant, als die bisher genannten Projekte. Und auch für Altgriechisch-Lernende würde es die Literaturauswahl angenehm und spielerisch erweitern.[8]

Ob sich eine Edition für einen E‑Book‑Output eignet, hängt also stark vom konkreten Projekt ab:

  • Rhodomanologia und Astronautilia sind besonders geeignet, da sie literarisch interessant und auch für Laien zugänglich sind.
  • Das Niklas-Luhmann-Archiv eignet sich nur eingeschränkt, da viele Inhalte aus nicht-literarischen Dokumenttypen wie Notizzetteln, bibliographischen Datensätzen und Druckvorstufen bestehen und erst durch komplexe Vernetzungen untereinander ein Gesamtwerk ergeben.
  • VedaWeb ist wegen urheberrechtlicher Fragen und bereits vorhandener E‑Book-Ausgaben ungeeignet.

Fazit zur Konzeption

Obwohl – oder gerade weil – E‑Books nur einen stark reduzierten Ausschnitt einer digitalen Edition darstellen, ist ihre Konzeption in Bezug auf Zweck, Inhalt und Zielgruppe ein komplexer und wichtiger Schritt. Da E‑Books im Gegensatz zur digitalen Edition stark linear aufgebaut und technisch eingeschränkt sind, müssen viele Inhalte vereinfacht oder weggelassen werden. Sie müssen ohne Apparate, synoptische Darstellungen oder interaktive Elemente verständlich sein und dürfen nicht von der visuellen Gestaltung abhängen. Das zwingt dazu, Inhalte strukturell sauber aufzubereiten und fördert eine datenzentrierte Sicht auf editorische Arbeit. Ähnlich wie Reclam-Ausgaben sollen die E‑Book-Exporte komplexe Inhalte als einen leicht zugänglichen und flüssig lesbaren Text bereitstellen. Idealerweise kann ein E‑Book Forschungsergebnisse somit auch für ein breiteres (Laien-)Publikum öffnen. Ein wichtiges Argument für die Bereitstellung von E‑Books ist zudem die Barrierefreiheit. Anders als PDFs sind sie kompatibel mit Screenreadern, nach individuellen Wünschen oder Einschränkungen anpassbar und lassen sich in Blindenschrift umwandeln. Aber nicht jede Edition eignet sich für einen E‑Book‑Output.

Um den konzeptionellen und technischen Workflow einmal durchzuspielen, habe ich mich im Folgenden auf die Erstellung von E‑Books im Rhodoman-Projekt konzentriert.

3. Technische Umsetzung

Die erste Hürde beim Erstellen eigener E‑Books ist das Format. Es existieren verschiedene Formate nebeneinander und nicht jedes Format ist mit jedem E‑Reader kompatibel und umgekehrt.

Das wichtigste Format ist EPUB – ein offenes, nicht-proprietäres Format, entwickelt vom IDPF / W3C, das von einer Vielzahl von Geräten (z. B. Tolino, Kobo), Apps (z. B. Apple Books, Google Play Books) und Browsern gelesen werden kann. Aber Marktführer in Deutschland bei E‑Readern ist (neben dem Tolino von Thalia) der Kindle von Amazon[9] und dieser ist mit EPUB nicht kompatibel[10]. Stattdessen setzt Amazon auf eigene proprietäre Formate: MOBI (das älteste), AZW, AZW3 und KFX (die neuste Version). Diese werden wiederum von E‑Readern wie Tolino und Kobo nicht unterstützt. Um Inhalte für eine möglichst breite Zielgruppe zugänglich zu machen, müssen also sowohl die Amazon- als auch die Nicht-Amazon-Geräte bedient werden, das heißt mindestens die Formate EPUB und KFX bereitgestellt werden, sowie idealerweise auch Formate für die älteren Kindle-Geräte (MOBI, AZW, AZW3). Mithilfe externer Software lässt sich EPUB in die Amazon‑Formate überführen, sodass es für meine Versuche ausreicht, mich zunächst auf die Erstellung der EPUB zu konzentrieren und die Amazon‑Formate daraus abzuleiten.

Um eigene E‑Books zu erstellen, gibt es verschiedene Möglichkeiten, die ich im Folgenden vorstelle.

3.1. Selfpublishing Web-Angebote

Onlinedienste (beispielsweise Feiyr) übernehmen einen Teil der klassischen Verlagsaufgaben, unter anderem die technische Aufbereitung des E‑Books für verschiedene Endgeräte, die Bereitstellung in gängigen Online-Shops (wie Amazons Kindle Store, Apple Books oder Thalia) sowie die Abwicklung von Verkauf und Abrechnung. Der offensichtliche Vorteil liegt darin, dass die veröffentlichten E‑Books eine hohe Sichtbarkeit erreichen und in professionellen Vertriebskanälen erscheinen, ohne dass ein klassischer Verlag eingeschaltet werden muss. Der Nachteil ist, dass diese Dienstleistungen kostenpflichtig sind und an einen externen Anbieter abgegeben werden, was ja gerade beides vermieden werden soll. Deshalb habe ich diesen Ansatz nicht weiterverfolgt.

3.2. Software zur EPUB-Erstellung

Programme wie Calibre oder Sigil sind eine einfache Möglichkeit, lokal E‑Books zu erstellen, ohne sich mit technischen Details beschäftigen zu müssen. Nach der Eingabe der Inhalte und Metadaten kann die Datei mit wenigen Klicks automatisch generiert werden. Während Calibre nicht nur EPUB‑Dateien erzeugen, sondern diese bei Bedarf auch in die Amazon‑Formate konvertieren kann, bietet Sigil diese Option nicht. Der Vorteil dieser und ähnlicher Programme liegt in der einfachen Bedienung und in der hohen Wahrscheinlichkeit, dass die erzeugten E‑Books auf verschiedenen E‑Readern korrekt funktionieren. Der Nachteil ist, dass die Konfigurationsmöglichkeiten begrenzt sind und die internen Abläufe verborgen bleiben, was projektspezifische Anpassungen erschwert. Aus diesem Grund habe ich die Programme zwar nicht zur Erstellung der EPUB genutzt, Calibre aber sowohl für die Konvertierung in die Amazon‑Formate, als auch als E‑Book-Lese-App eingesetzt.

3.3. Im oXygen XML Editor integrierte „TEI P5 EPUB Transformation”

Eine auf den ersten Blick ideale Lösung: der – ohnehin in allen vier Projekten verwendete, allerdings proprietäre – oXygen XML Editor bietet eine bereits integrierte Transformationsmöglichkeit von TEI-XML – die Datenbasis in ebenfalls allen Projekten – zu EPUB. Die anfängliche Euphorie war allerdings nur von kurzer Dauer. Die Ergebnisse der ersten naiven Transformationen waren nicht zu gebrauchen – vergleiche die Darstellung in der digitalen Edition mit dem EPUB-Export (Abb. 1).

Abb. 1: Vergleichende Darstellung eines Gedichts in der digitalen Edition (links) und dem EPUB-Export (rechts).

Die Ausgangs-XML enthalten viel zu viele Daten, die eben nicht in den EPUB‑Output übernommen werden sollen, z. B. <pb/>-Elemente für Seitenumbrüche, extensive Metadaten im <teiHeader/>, Apparate, diplomatische Versfassungen und Marginalien. Auch die automatisierte Übersetzung der TEI-Elemente in die für EPUB benötigten XHTML-Strukturen spiegelt häufig nicht die vom Projekt intendierte Hierarchie wieder. Insbesondere die Struktur der Gedichtverse mit ihren jeweils zwei oder drei Sprachen wurde nicht adäquat erkannt. Zudem werden elementare Bestandteile wie die Verszahlen (kodiert im @n-Attribut in <l n=“…”/>) gar nicht übernommen, dafür aber Titel und Kapitel automatisiert aus den völlig falschen Elementen „generiert”. Die Ausgangs-XML müssten also zunächst durch eigene Arbeitsschritte vorprozessiert und in ein reduziertes Übergangs-TEI-XML gebracht werden, das von der Transformation dann in das finale XHTML‑Format übersetzt werden kann.

Auch das Styling der generierten Datei war unbrauchbar. Beispielsweise waren die Sprachen in den Gedichten nicht durch Zeilenumbrüche voneinander abgesetzt. Wenn es eine Möglichkeit zur Anpassung während der Erstellung gibt, beispielsweise durch das Einbinden eigener CSS-Stylesheets, konnte ich sie nicht finden. Auch die offizielle Dokumentation liefert dazu keine Hinweise, sondern bezieht sich nur auf das Post-Processing der erzeugten EPUB‑Dateien, was im Projektworkflow nicht praktikabel ist.

Da es sich um eine oXygen-interne Transformation handelt, kann diese auch nicht ohne weiteres aufgebohrt und manuell angepasst werden. Stattdessen muss in einer Kopie gearbeitet werden, was ich aber nach einigen erfolglosen Versuchen aufgegeben habe. Zum einen, weil die Transformation viel zu viel Ballast enthält (insb. extensive interne und externe Abhängigkeiten sowie Einzelschritte und -skripte) und zum anderen, weil der Vorprozessierungsschritt für ein reduziertes Input-TEI-XML dennoch weiterhin nötig bleibt.

Aus diesem Grund habe ich auch diesen Ansatz verworfen und stattdessen den „build from scratch”-Schritt gewagt.

3.4. Eigener Workflow zur EPUB-Erstellung mit XSL

Aus der Projektarbeit bin ich es gewohnt, Daten zwischen unterschiedlichen Formaten zu konvertieren. Die benötigten Transformationsskripte selbst zu schreiben, um jetzt ein EPUB‑Format zu erzeugen, lag somit nahe. Der offensichtliche Nachteil gegenüber den zuvor genannten Optionen sind eine höhere technische Einstiegshürde und größerer Arbeitsaufwand.[11]

Am Anfang steht die Analyse des Zielformats: Was genau ist EPUB und wie ist es aufgebaut? Das bedeutet: erst einmal die Spezifikation lesen. Erfreulicherweise ist EPUB im Kern XML-basiert und lässt sich somit wunderbar in unseren bestehenden Workflow integrieren. Konkret handelt es sich bei EPUB um ein ZIP-komprimiertes Archiv mit standardisierter Struktur. Es besteht im Wesentlichen[12] aus folgenden Bestandteilen:

  • mimetype – Eine Textdatei mit dem Medientyp „application/epub+zip”. Sie muss unkomprimiert an erster Stelle stehen und ist kein
  • xml – Eine technisch notwendige Datei, die dem Lesegerät mitteilt, wo sich der Einstiegspunkt (die OPF-Hauptdatei des E‑Books) befindet.
  • opf – Eine XML‑Datei mit Metadaten (Titel, Autor, Identifier, Version, Datum usw.), einer Auflistung aller enthaltenen Dateien und der Lesereihenfolge.
  • ncx (EPUB 2) bzw. toc.xhtml (EPUB 3) – (Optional) Ein Inhaltsverzeichnis im XML‑Format, aus dem das Lesegerät Sprungmarken und Navigation generiert.
  • XHTML‑Dateien – Die eigentlichen Inhalte auf beliebig viele Dateien verteilt.
  • CSS‑Dateien – (Optional) Für Layout und Formatierung.
  • Ergänzende Ressourcen – (Optional) Bilder, Medien oder Schriftarten.

Mein Anspruch war es, die Transformation so aufzubauen, dass sie beliebig oft wiederholbar ist – ohne manuelle Eingriffe ins Endergebnis. Der E‑Book‑Output soll sich jederzeit aktualisieren lassen, falls sich die Ausgangs-XML‑Dateien ändern oder neue Inhalte hinzukommen. Abgesehen von der mimetype‑Datei, die grundsätzlich unverändert bleibt, und der CSS‑Datei, die einmal erstellt und nur bei Bedarf angepasst wird, müssen die Skripte somit automatisch:

  • die XHTML-Inhaltsseiten aus den Ausgangs-XML generieren,
  • die Metadaten- und Strukturdatei (package.opf) entsprechend aktualisieren,
  • und die Inhaltsverzeichnisse (toc.ncx bzw. toc.xhtml) neu erzeugen.

Da es sich um eine XML-zu-XML-Transformationen handelt, bietet sich XSL als naheliegende Skriptsprache an. Lediglich den letzten Schritt – das Zippen der Einzeldateien zu einer Gesamt-EPUB‑Datei – konnte ich nicht über XSL steuern. Stattdessen habe ich dafür ein Pythonskript geschrieben.

Nachdem das Zielformat verstanden, das grundsätzliche Vorgehen mit XSL festgelegt und erste Tests erfolgreich waren, möchte ich im Folgenden auf einige unerwartete Herausforderungen und Fallstricke aus den Bereichen Technik, Design und Konzeption eingehen.

3.4.1. Technische Herausforderungen

Validierung: Damit die selbst erzeugten E‑Books auf den unterschiedlichen Lesegeräten und Apps korrekt dargestellt werden, müssen sie dem erwarteten Format entsprechen. Das bedeutet, sie müssen valide sein. Für diese Prüfung habe ich die freie Software EPUB-Checker verwendet. Das war sehr hilfreich, denn obwohl ich mich bemüht hatte, den Aufbau der EPUB möglichst genau an der Spezifikation auszurichten, machte mich die Validierung auf einige Punkte aufmerksam, die ich übersehen hatte. Beispielsweise war in den Metadaten das Datum zu kurz angegeben und entsprach nicht dem korrekten Format (s. Abb. 2).

Abb. 2: Fehlermeldung im Validierungstool EPUB-Checker zu falschem Datumsformat.

Überrascht und dankbar war ich auch für die Fehlermeldung „referenzierte Datei nicht gefunden”. Übergangsweise hatte ich eine spezielle Schriftart in der EPUB‑Datei eingebettet und die TTF‑Dateien in der OPF aufgelistet. Als das Einbetten des Fonts in einer späteren Fassung nicht mehr nötig war, habe ich zwar den Eintrag in der OPF gelöscht, aber vergessen, dass die Fonts auch in der CSS‑Datei über @font-face referenziert wurden, worauf mich erst die Validierung hinwies (s. Abb. 3).

Abb. 3: Fehlermeldung im Validierungstool EPUB-Checker zu einer Referenz im CSS auf eine nicht mehr vorhandene Datei.

Besonders, wenn der E‑Book‑Output immer wieder neu generiert wird, weil weitere Inhalte hinzukommen, ist es eine große Hilfe, wenn die Validierung auf Konsistenz achtet und sicherstellt, dass sämtliche Abhängigkeiten korrekt aufgelöst sind.

E‑Book-Identifier: Laut Spezifikation benötigt das E‑Book einen eindeutigen Identifier in der OPF: „The EPUB creator MUST provide an identifier that is unique to one and only one EPUB publication – its unique identifier – in an dc:identifier element”[13]. Dieser Identifier kann z. B. eine UUID, DOI oder ISBN sein. UUIDs lassen sich einfach selbst generieren, aber DOI und ISBN müssen von einer entsprechenden Organisation vergeben werden. Für eine zitierfähige Veröffentlichung des E‑Books wären letztere besser, aus einem Projekt heraus sind diese aber mitunter organisatorisch schwerer zu bekommen. Das Fehlen des Identifiers wurde auch bei der Validierung sofort korrekt gemeldet.

E‑Reader stürzt ab – Datei zu groß: Zum Testen der erzeugten E‑Books verwende ich auf dem PC die App Calibre und als Lesegerät einen Tolino Vision Color von Thalia. Eine erste E‑Book-Fassung enthielt alle Gedichte in allen drei Sprachen (Griechisch, Latein und Deutsch) jeweils untereinander pro Vers, wie in der digitalen Edition. Aber während Anzeige und Bedienung in Calibre problemlos waren, stürzte der Tolino beim Blättern regelmäßig ab. Da das Gerät mit Erscheinungsdatum 2024 und Kaufdatum 2025 noch sehr neu war und ich dieses Problem bei anderen – kommerziellen wie nicht-kommerziellen – E‑Books nicht hatte, lag die Ursache vermutlich in der Datei selbst. Und tatsächlich stellte sich als Grund die Dateigröße heraus, mit der der E‑Reader offenbar überfordert war. Die Datei enthielt sowohl ein Titelbild als auch einen eingebetteten griechischen Font. Letzterer war nötig, weil die Akzente im Griechischen zuvor nicht sicher korrekt angezeigt wurden (s. Abb. 4). Aber schon bei einer Testdatei mit lediglich drei Gedichten ergaben sich daraus folgende Dateigrößen:

Dateigröße (in KB) Titelbild Fonts  
1.928 mit Titelbild + mit Fonts
1.178 mit Titelbild + ohne Fonts
769 ohne Titelbild + mit Fonts
19 ohne Titelbild + ohne Fonts

Das Problem war somit eindeutig das zu große Titelbild. Zwar gibt es Möglichkeiten, die Dateigröße insbesondere von EPUB mit Bildern zu reduzieren, aber da ich persönlich das Titelbild als nicht so elementaren Teil sehe, habe ich diesen Weg vorerst nicht weiterverfolgt und das Bild in den nachfolgenden Fassungen schlicht weggelassen. Kurioserweise konnte ich das Problem mit der fehlerhaften Akzentdarstellung später selbst ohne eingebetteten Font nicht mehr reproduzieren und auch bei Testpersonen, die verschiedene andere Lesegeräte verwendeten, war die Darstellung stets fehlerfrei. Somit konnte ich glücklicherweise auf die eingebetteten Fonts verzichten – auch wenn ich bis heute keine Erklärung für diesen Bug gefunden habe.

Abb. 4: Fehlerhafte Akzentdarstellung im Griechischen.

Inhaltsverzeichnis nicht erkannt: Das Inhaltsverzeichnis eines E‑Books ist nicht bloß eine normale Textseite, sondern auch eine technische Navigationsfunktion. Die Lesegeräte erzeugen daraus ein eigenes Menü, das als Popup oder Seitenleiste erscheint und Sprungmarken zu den einzelnen Abschnitten anbietet. Es kann auf zwei Arten definiert werden: über die Datei toc.ncx (EPUB 2) oder über toc.xhtml (EPUB 3). Obwohl der von mir verwendete Tolino das Format EPUB 3 und damit toc.xhtml als Inhaltsverzeichnisdatei unterstützt und die Validierung keine Fehler in der Datei oder ihrer technischen Zuweisung über das @properties-Attribut meldete, wurde es auf dem E‑Reader dennoch nicht erkannt. Auch bei Tests auf anderen Geräten war das Navigationsmenü stets leer bzw. die Funktion nicht verfügbar. Lediglich Calibre setzte das Menü ohne Probleme um. Die toc.ncx hingegen funktionierte fehlerfrei. Eine Erklärung konnte ich bislang nicht finden. Glücklicherweise ist es möglich – und aus Gründen der Rückwärtskompatibilität ohnehin empfehlenswert –, stets beide Dateien anzubieten, damit sowohl neue als auch alte Lesegeräte ein Navigationsmenü generieren können, sodass dieses Problem zwar frustrierend unerklärlich aber zumindest leicht zu lösen war.

Lesegeräte-Simulatoren: Die Vielzahl an Lesegeräten und Apps ist vergleichbar mit dem Problem digitaler Editionen, auf allen möglichen Betriebssystemen, Browsern und Bildschirmgrößen funktionieren zu müssen. Während sich im Webbereich jedoch verschiedene Umgebungen simulieren lassen, um die Darstellung einer Edition gezielt zu prüfen, konnte ich für E‑Book-Lesegeräte kein vergleichbares Tool finden. Dabei wäre es sehr hilfreich, unterschiedliche Geräte vergleichen zu können, um ein Gefühl dafür zu bekommen, ob – und an welchen Stellen – sich die Darstellungen unter Umständen so signifikant unterscheiden, dass sie konzeptionell berücksichtigt werden müssen.

Apps wie Calibre oder Adobe Digital Editions erlauben zwar das Lesen von E‑Books auf dem PC oder Mac, simulieren aber keine konkreten Geräte. Der Kindle Previewer wiederum ist eigentlich genau dafür gedacht, die Darstellung der Amazon‑Formate auf verschiedenen Kindle-Geräten zu testen, jedoch konnte ich das Programm nicht wie gehofft nutzen, weil ich bei meinen Dateien die Fehlermeldung bekam: „Kindle Previewer unterstützt diese Datei nicht, da sie […] [mit] einer Drittanbieteranwendung erstellt wurde”. Somit war das Tool für meine Tests der mittels Calibre erzeugten Amazon E‑Book-Versionen leider unbrauchbar. Das Laden der EPUB‑Dateien hingegen funktionierte im Kindle Previewer unerwarteterweise gut, sodass ich dort zumindest grob die Anzeige auf Tablet, Smartphone und einem generischen Kindle-E‑Reader[14] vergleichen konnte. So wurden beispielsweise auf Tablet und Smartphone die Links im Inhaltsverzeichnis blau dargestellt, in der Kindle-Ansicht hingegen nicht, da die meisten E‑Reader keine Farben wiedergeben können. Auch die Anzahl der pro Seite angezeigten Zeilen variierte je nach Gerätegröße. Auf dem Smartphone brachen zudem die Zeilen aufgrund des schmaleren Displays früher um (s. Abb. 5).

Abb. 5: Simulierte E‑Book-Vorschau für Tablet, Smartphone und E‑Reader.

3.4.2. Design-Herausforderungen

Die meisten Design-Herausforderungen hingen damit zusammen, dass kaum vorhersehbar ist, wie – oder überhaupt ob – ein Lesegerät die mitgegebenen CSS-Anweisungen interpretiert und umsetzt. Wirklich zuverlässig funktionierten auf den getesteten Geräten und in den Apps nur sehr grundlegende Formatierungen wie Fett, Kursiv oder Unterstreichung. Auch Zentrierung wurde überraschend konsistent umgesetzt, obwohl sie bereits eine Form von Positionierung darstellt. Unsicherer waren dagegen zeichenbasierte Formatierungen wie Kapitälchen oder die Darstellung des Griechischen, weil sie jeweils von der auf dem Gerät verfügbaren Standardschriftart abhängen. Ebenso unvorhersehbar war, wie ein Gerät klassische XHTML-Strukturelemente – etwa Überschriften (<h1>) oder Absätze (<p>) – behandelt und ob es dabei den mitgegebenen CSS-Vorgaben folgt oder ein eigenes, im Gerät hinterlegtes Design verwendet.

Als besonders problematisch erwies sich der Seitenumbruch. Im Rhodoman-Projekt ist jede Einheit als eigene XHTML‑Datei angelegt, die wiederum mehrere Gedichte enthalten kann, verschachtelt in <div>-Elemente. Alle Reader setzen automatisch vor jeder neuen XHTML- Datei einen Seitenumbruch. Mein Wunsch war es aber, dass auch jedes darin enthaltene Gedicht auf einer neuen Seite beginnt, also ein page-break vor jeder <div>. Während Calibre diese Anweisung zuverlässig umsetzt, wurde sie von den getesteten Tolino-Geräten ignoriert – unabhängig davon, ob ich die ältere, theoretisch abwärtskompatible CSS-Variante page-break-before:always; oder die neuere break-before:page; verwendet habe. Der Kindle Previewer suggeriert zwar eine korrekte Umsetzung, letztlich hängt das Ergebnis aber auch dort wohl vom konkreten Gerät ab.

Schwierig war auch die Darstellung des Inhaltsverzeichnisses, genauer der toc.xhtml als Textseite (also nicht des aus der toc.ncx generierten Navigationsmenüs). Der Tolino scheint intern zwar die Anweisung zu haben, die <li>-Einträge einer <ol> automatisch zu nummerieren, liefert jedoch keine eigene CSS-Regel, die sicherstellt, dass für diese Zahlen ausreichend Platz vorhanden ist. Mehrstellige Zahlen wurden dadurch abgeschnitten (s. ab Eintrag 10 in Abb. 6). Die Lösung bestand darin, die Einrückungen über CSS mit margin und padding zu definieren. Aber ob die E‑Reader diese Vorgaben tatsächlich umsetzen, bleibt offen.

Abb. 6: Fehlender Platz im Navigationsmenü des Lesegeräts für automatisiert generierte Nummerierung.

Dieses Misstrauen ist nicht unbegründet, denn dass Einrückung per CSS problematisch sein kann, zeigte sich an den Verszahlen. Zunächst wollte ich diese, wie in der Printtradition üblich und auch in der digitalen Edition umgesetzt, in Fünferschritten ausrücken. Auf meinem Tolino (Erscheinungsjahr 2024) wurde dies problemlos dargestellt. Als mir jedoch ein Test-User die Anzeige auf seinem Tolino Epos 3 (Erscheinungsjahr 2022) zeigte, wurde deutlich, dass selbst zwischen zwei so eng verwandten Geräten die Unterschiede unvorhersehbar groß sein können (s. Abb. 7). Weil es zwar etwas weniger elegant, aber für die Darstellung robuster ist, habe ich mich deshalb entschieden, die Verszahlen nicht mehr auszurücken, sondern schlicht in eckigen Klammern in den Vers zu schreiben. Hier beeinflussen Einschränkungen im Design also direkt konzeptionelle Entscheidungen.

Abb. 7: Deutliche Abweichungen in der Darstellung desselben Textes auf zwei nah verwandten Lesegeräten.

3.4.3. Konzeptionelle Herausforderungen

Abb. 7 zeigt noch weitere Schwachstellen meiner initialen Konzeption.

Die Verse, insbesondere die deutsche Fassung, sind in der Regel zu lang für eine Zeile und brechen um. Bei stets mindestens zwei, oft drei Sprachen parallel führt das dazu, dass ein einziger Vers in der Anzeige vier oder mehr Zeilen umfasst. Um die einzelnen Verse optisch voneinander zu trennen, müssen die Abstände zwischen diesen Gruppen vergrößert werden, was den Text stark zerfasert. In Abb. 7 sind auf einer Seite nur sechseinhalb Verse zu sehen, verteilt auf 20 Zeilen – und das mit lediglich einer einzigen Verszahl zur Orientierung. Unter anderen Umständen könnten für sechs Verse sechs Zeilen ausreichen, auf der Seite wäre somit Platz für dreimal so viel Inhalt. Sollten sich LeserInnen nicht für alle drei Sprachen interessieren, sondern beispielsweise nur für die deutsche Übersetzung, muss somit bereits nach jedem sechsten Vers umgeblättert werden, was auf Dauer viel zu anstrengend ist. Aber selbst LeserInnen, die Originalsprache und Übersetzung parallel lesen möchten, müssen beim Lesen von Sprachzeile zu Sprachzeile springen. Ein lineares Lesen ist somit nicht möglich. Wäre die Darstellung wenigstens so regelmäßig, dass jede Sprache nur eine Zeile beansprucht, wäre das Layout ruhiger und geordneter. Dafür müsste der Reader aber entweder auf Querformat eingestellt oder die Schriftgröße verringert werden und beides ist keine robuste Lösung, da die NutzerInnen die Einstellungen ja selbst anpassen können.

Um den Anspruch der linearen Lesbarkeit in den Mittelpunkt zu stellen und diesem gerecht zu werden, habe ich deshalb entschieden, in einer zweiten Fassung die Sprachen zu trennen und jeweils ein eigenes EPUB für den deutschen, griechischen und lateinischen Text zu gestalten. Das Ergebnis wirkt sofort viel ruhiger, und der Text ist deutlich flüssiger lesbar (s. Abb. 8). Es bleibt jedoch das eingangs aufgeworfene Problem, dass ohne genauere Kenntnis der tatsächlichen NutzerInnengruppe nicht klar ist, ob überhaupt Bedarf an einer rein originalsprachigen Ausgabe im E‑Book‑Format besteht.

Abb. 8: Deutlich ruhigere Textdarstellung bei nach Sprachen getrennten E‑Book-Fassungen.

Diese zweite Fassung brachte zudem weitere konzeptionelle Probleme mit sich. So gibt es beispielsweise Einheiten, die aus einem ersten Gedicht auf Latein und einem eng verwandten zweiten Gedicht auf Griechisch bestehen, weshalb sie als eine Einheit zusammengefasst sind. Eine Einheit mit dem Kurztitel „Rhod. Coc.Ion. 1–2” signalisiert beispielsweise, dass sie zwei Gedichte enthält. In der lateinischen E‑Book-Fassung ist jedoch nur das erste Gedicht enthalten, in der griechischen wiederum nur das zweite. Die Einheit behält dann zwar weiterhin den Titel „1–2”, beginnt aber entweder irritierenderweise mit „Gedicht Nr. 2” oder endet nach „Gedicht Nr. 1”, wodurch der Eindruck entsteht, dass Inhalte fehlen würden. Und wenn doch mal eine Übersetzung für eine originalsprachliche Stelle benötigt würde, müsste ein komplett anderes E‑Book geöffnet werden – ausgesprochen unkomfortabel.

Da ich weder die Paralleldarstellung noch die Sprachtrennung zufriedenstellend finde, plane ich aktuell eine dritte Option, in der die gesamte Edition wieder in einem einzigen E‑Book zusammengefasst ist, aber jedes Gedicht in zwei aufeinanderfolgende Blöcke aufgeteilt wird: Zunächst die Originalsprachen Griechisch und/oder Latein pro Vers untereinander (Zeilenumbrüche sollten sich hierbei in Grenzen halten) und anschließend die deutsche Übersetzung als eigenständiger Block. Die Verszahlen dienen dabei als Link-Verbindung zwischen den Sprachblöcken, sodass LeserInnen entweder einen der beiden Blöcke linear durchlesen oder bei Bedarf über die Links zum entsprechenden Vers im anderen Block springen und wieder zurückkehren können.

Ich hoffe, dass dies ein Kompromiss ist, der sowohl die lineare Lesbarkeit als auch die parallele Darstellung der Sprachen berücksichtigt, ohne dass der Lesefluss oder die Übersichtlichkeit zu stark leiden.

Fazit zur technischen Umsetzung

Es gibt verschiedene Möglichkeiten, E‑Books aus einem Projekt heraus zu generieren. Selfpublishing Web-Angebote sind kostenpflichtig und gehen eher in Richtung Verlags-Kooperation. Spezielle Software zur EPUB-Erstellung funktioniert grundsätzlich gut, lässt sich aber schlecht individuell konfigurieren. Die im oXygen XML Editor integrierte „TEI P5 EPUB Transformation” will eine generisch für alle TEI‑Dateien funktionierende Transformation bieten, lässt sich aber ebenfalls nicht projektspezifisch anpassen und interpretiert Strukturen oft anders als gewünscht.

Ich habe mich deshalb für einen eigenen Workflow zur EPUB-Erstellung mit XSL entschieden. Da EPUB im Kern eine ZIP‑Datei ist, die (fast) ausschließlich XML-basierte Formate enthält, ließ sich es sich sehr gut in den bestehenden Projektworkflow integrieren. Technische Herausforderungen waren dabei unter anderem die Dateigröße (umfangreiche EPUBs mit Bildern und eingebetteten Fonts führten auf meinem Lesegerät zu Abstürzen) sowie das Inhaltsverzeichnis (das neuere Format toc.xhtml wurde, im Gegensatz zum älteren toc.ncx, nicht zuverlässig als Navigationsdatei erkannt). Um sicherzustellen, dass die EPUB‑Dateien dem von den Lesegeräten erwarteten Format entsprechen, bieten Validierungstools wie der EPUB-Checker eine unkomplizierte und praktische Hilfe. Generell fehlt es jedoch an Simulationsmöglichkeiten für verschiedene Lesegeräte. Programme wie Calibre oder der Kindle Previewer liefern zwar grobe Eindrücke, etwa beim Vergleich von Tablet, Smartphone und E‑Reader, simulieren aber keine konkreten Geräte. Meine Tests zeigen, dass selbst nah verwandte Geräte dieselbe Datei teils signifikant unterschiedlich darstellen. Insgesamt erwiesen sich die physischen Lesegeräte bei meinen Tests generell als weniger zuverlässig, komfortabel und robust in der Anzeige als E‑Book-Apps.

Wie – und ob überhaupt – eingebettete CSS-Anweisungen umgesetzt werden, ist von Gerät zu Gerät unterschiedlich und nicht vorhersehbar. An Beispielen wie der Ausrückung von Verszahlen, der Nummerierung im Inhaltsverzeichnis und dem Versuch, Seitenumbrüche vor <div>-Elementen vorzugeben, zeigte sich, dass diese Design-Instabilität mitunter direkten Einfluss auf die konzeptionelle Gestaltung hat.

Konzeptionell noch ungeklärt ist zudem der Umgang mit den verschiedenen Sprachen im Projekt: Alle drei Sprachen nebeneinander stört die Lesbarkeit, während drei nach Sprachen getrennte E‑Books die Gedichte inhaltlich auseinanderreißen und fälschlich Lücken suggerieren. Ein möglicher Kompromiss – Originaltext und deutsche Übersetzung in zwei separaten, aber miteinander verlinkten Blöcken innerhalb eines E‑Books – muss noch umgesetzt werden.

4. (Exkurs) Laien als Zielgruppe – Zugänglichkeit neu denken

Abschließend noch ein paar Gedanken zu der eingangs aufgeworfenen Frage, ob eine digitale Edition auch für eine Laien-Zielgruppe außerhalb der fachwissenschaftlichen Community zugänglich gemacht werden kann. Mein Eindruck ist, selbst wenn sich ein Projekt inhaltlich für eine breitere Öffentlichkeit eignet und einen E‑Book‑Output anbieten würde, ist fraglich, ob diese Zielgruppe tatsächlich erreicht würde – oder ob die Angebote nur weiter innerhalb des akademischen Umfelds zirkulieren. Ich vermute, dass dafür neben Suchmaschinen wie Google stärker auch Plattformen wie Amazon, Thalia oder Kobo als potenzielle Zugangs- und Sichtbarkeitskanäle in den Blick genommen werden müssten.

E‑Books in diesen Shops anzubieten wäre ein naheliegender Weg, um Sichtbarkeit zu schaffen, denn genau dort suchen Leute nach Lesestoff. Fraglich ist allerdings, ob kostenlos angebotene E‑Books die Zugänglichkeit tatsächlich erhöhen oder eher Zweifel an ihrer Relevanz und Wertigkeit wecken. Zudem kommen organisatorische und technische Aspekte hinzu, die ich noch nicht überblicken kann. So müsste sich das Projekt etwa um die Vergabe einer ISBN kümmern. Unter Umständen ist die Nutzung kommerzieller Plattformen wie Amazon auch mit Kosten verbunden, für die im Projekt keine Mittel bereitstehen. Und es stellt sich die Frage, wer sich nach Ende der Projektlaufzeit um Pflege, Aktualisierung und langfristige Verfügbarkeit kümmert.

Aber vielleicht muss die DH-Community auch darüber nachdenken, wie die Angebote innerhalb der digitalen Edition besser auffindbar gemacht werden können. Denn wissenschaftliche Editionen sind von Natur aus komplex. Es kostet Zeit und Mühe, sich in fremde Editionen einzuarbeiten, ihre Struktur zu verstehen, ihre Zielsetzung, welche Materialien sie bereitstellen, kurz, was die Edition ist und was sie nicht ist. Von interessierten Laien kann ich das nicht erwarten.

Wenn ich mich als Laie erst in die individuellen Untiefen einer Edition einarbeiten muss, weil sich die E‑Books unter abschreckenden Reitern wie „Technische Dokumentation und Downloads” befinden – wo sie bei meinen Projekten schändlicherweise zu Testzwecken momentan noch liegen – oder ganz am Ende in der Fußzeile zwischen Buttons mit hoch technischen Bezeichnungen wie „TEI-XML”, „JSON” und „TIFF”, werde ich sie sehr wahrscheinlich nicht finden.

Für mich bedeutet das ganz konkret: Wenn ich die E‑Books im Rhodoman-Projekt leicht zugänglich machen will, müssen sie raus aus dem Downloads-Untermenü und am besten bereits auf der Startseite sichtbar sein (weil potentielle LeserInnen beispielsweise nach einer Googlesuche dort landen). Das widerspricht allerdings meinem Anspruch, diese möglichst minimalistisch und aufgeräumt zu halten. Und welche Rechtfertigung gibt es, einen – im Gesamtkonzept des Projektes klar untergeordneten – E‑Book‑Output prominent auf der Startseite zu platzieren, während der „eigentliche” Inhalt der Edition verborgen bleibt? Das heißt, idealerweise zeigt bereits die Startseite der Edition beiden Zielgruppen – Laien und FachwissenschaftlerInnen –, welchen Weg sie innerhalb der Edition wählen müssen, um die für sie relevanten Inhalte und Outputs in den jeweils passenden Komplexitätsstufen zu finden. Aber eine konkrete Vorstellung, wie das für die Rhodoman-Edition aussehen könnte, habe ich noch nicht.

5. Fazit

Die technische Umsetzung eines E‑Book‑Outputs ist deutlich unkomplizierter, als ursprünglich befürchtet. Das EPUB‑Format ist gut dokumentiert, standardisiert und weit verbreitet. Unerwartet war lediglich die Notwendigkeit, neben EPUB auch die proprietären Amazon‑Formate bedienen zu müssen, um nicht einen großen Teil der potentiellen Leserschaft auszuschließen. Falls in einem Editionsprojekt keine Mittel für eine Kooperation mit einem Verlag vorgesehen sind, lässt sich mit soliden XSL-Kenntnissen recht einfach ein E‑Book‑Output realisieren. Unter Umständen reichen sogar Softwarelösungen wie Calibre oder Sigil aus. Projektspezifische Konfigurationsmöglichkeiten sind dabei jedoch begrenzt und sie lassen sich mitunter schwerer in automatisierte Projektworkflows integrieren, weil die Erzeugung per Hand geschehen muss.

Die eigentlichen Herausforderungen liegen meines Erachtens weniger auf der technischen, sondern auf der konzeptionellen Ebene – ein Aspekt, den ich unterschätzt habe. Die komplexen Inhalte wissenschaftlicher Editionen müssen für das Medium E‑Book stark vereinfacht und reduziert werden und nicht alle Projektinhalte eignen sich überhaupt für eine lineare Lesefassung. Zudem sind viele Gestaltungsmöglichkeiten und Funktionen, die im digitalen oder gedruckten Kontext gang und gäbe sind, im E‑Book nicht möglich, weil das Layout nicht starr und die Funktionalitäten der Lesegeräte eingeschränkt sind.

Ein großes Problem ist zudem, dass die Zielgruppe nicht klar bekannt ist. Durch die stark reduzierte Struktur und den Anspruch, eine niederschwellige Lesefassung zu sein, sind E‑Books zwar eine Chance die in den Digital Humanities manchmal zu wenig bedachte Zielgruppe der interessierten Laien zu erschließen, gleichzeitig ist aber fraglich, ob diese über den Weg einer digitalen Edition überhaupt erreicht werden. Zumindest für meinen Testfall Rhodomanologia muss ich die Website dahingehend noch einmal gründlich überdenken.

Überlegungen für einen E‑Book‑Output sind damit weniger ein technisches, sondern vielmehr ein konzeptionelles Experiment. Sie regen dazu an, sich mit der Edition als Ganzes auseinanderzusetzen. Wenn also Zeit und Ressourcen es erlauben, spricht nichts dagegen, es einfach zu versuchen.

Endnoten

[1] Ich verwende im Folgenden die Kurzform „Edition” für jede Art von nicht-kommerzieller, fachwissenschaftlicher Aufbereitung und Bereitstellung von Texten in digitaler Form ohne Verlagsbeteiligung, die über eine bloße Faksimiledarstellung hinausgeht, und bei der eine „klassische” Publikation als Print (oder E‑Book) nicht der primäre Output des Vorhabens ist.

[2] Was nicht bedeutet, dass keine Editionen E‑Books anbieten, sondern dass die Frage schwer in eine Onlinesuche umzusetzen ist.

[3] https://de.statista.com/statistik/daten/studie/277971/umfrage/nutzung-von-buechern-und-E‑Books-deutschland/

[4] Die meisten neueren Geräte können zwar ins W-Lan und haben teilweise auch eingebaute Browser, aber gerade die papierähnliche, augenfreundliche E-Ink-Technik, die E‑Reader ausmacht und sie von anderen Geräten wie Tablets unterscheidet, macht jede Änderung in der Anzeige wie scrollen oder Passwörter eintippen langsam und ruckelig.

[5] https://www.reclam.de/verlag/ueber-reclam

[6] https://www.boersenverein.de/beratung-service/barrierefreiheit/leitfaden-barrierefreie-epub3-E‑Books-seite-2/

[7] https://gepris.dfg.de/gepris/projekt/470926253?context=projekt&task=showDetail&id=470926253&

[8] Aus persönlicher Erfahrung kann ich sagen, dass interessante Texte, die in klassische Sprachen übersetzt werden, ein nicht zu unterschätzender Anreiz sind, sich intensiver mit diesen Sprachen zu beschäftigen. So habe ich beispielsweise Harry Potter auf Latein und Altgriechisch deutlich lieber gelesen als die klassischen antiken Werke zu Religion, Philosophie und Krieg.

[9] https://de.statista.com/themen/658/E‑Reader/

[10] Um EPUB auf Amazon-Geräten lesen zu können, müssen sie zunächst selbstständig in ein kompatibles Format konvertiert werden und das funktioniert – je nach Tool und EPUB – nicht immer zuverlässig.

[11] Es ist abzusehen, dass sich der Workflow und die Skripte nicht als Rundum-Sorglos-Lösung zur direkten Nachnutzung für andere Projekte eignen werden, weil sie speziell auf dieses eine Projekt zugeschnitten sind. Die oXygen-interne „TEI P5 EPUB Transformation” hingegen versucht gerade diese generische Lösung zu bieten. Für Projekte mit flacherer oder näher am klassischen Buchformat orientierter TEI-Struktur kann dieser Ansatz deshalb durchaus ausreichend sein.

[12] Minimalanforderung: Eine EPUB muss nur aus mimetype, HTML/XHTML‑Dateien, einer OPF‑Datei und der container.xml bestehen, damit sie technisch gelesen werden kann. Inhaltsverzeichnis, CSS und sonstige Dateien sind üblich aber optional.

[13] https://www.w3.org/TR/epub-33/#sec-opf-dcidentifier

[14] Die drei Ansichten (Tablet, Telefon, Kindle) im Kindle Previewer sind generische Simulationen und beziehen sich nicht auf konkrete Gerätemodelle. Vermutlich spiegelt die Kindle-Ansicht wider, wie Amazon intern EPUB‑Dateien bei der Konvertierung in eigene Formate interpretiert.

 

Forschungspraktikum im Master Geschichte: Mitarbeit im “chigc“-Projekt

von Lukas Schievelbusch

Im Rahmen meines Studiums ist ein Berufspraktikum im Feld “Geschichte” vorgesehen. Aber was ist “Geschichte” denn überhaupt? Nun ja, “Geschichte” ist nicht das Gleiche wie “Vergangenheit”. Vielmehr werden in der “Vergangenheit” geschehene Ereignisse von Historikern untersucht und kontextualisiert. Narrative werden konstruiert, andere Narrative dekonstruiert. Dabei findet sich diese “Geschichte” in einer Zwickmühle wieder. Wie bei jeder anderen Wissenschaft wird Objektivität angestrebt, dem Forscher stehen dabei jedoch zwei grundlegende Probleme im Weg. Zum einen die Perspektive des Forschers selbst. Kontexte und Narrative werden aus dem Blickwinkel und sozialen Umfeld des Historikers gebildet, vergangene Ereignisse können politik-, sozial-, kulturhistorisch und mit zahllosen anderen Herangehensweisen untersucht werden. Man muss als Forscher wohl in Kauf nehmen, dass dadurch keine echte Objektivität erreicht werden kann.

Das andere Problem sind die Quellen. Geschichte lebt von Quellen. Ereignisse, die wirklich gar keine Quellen hinterlassen haben, hätten aus unserer Perspektive auch genauso gut nie stattfinden können. Zudem sind die Quellen, die überliefert wurden, immer mit einer Agenda entstanden, jedes Dokument, jedes Bild, jede Karte, alles wurde von Menschen in ihrem sozialen Umfeld angefertigt und ist nie objektiv, jedenfalls nicht nach naturwissenschaftlichen Maßstäben. Trotzdem sind diese Quellen alles, was wir als Historiker haben, um aus der “Vergangenheit” “Geschichte” zu machen, also müssen wir mit diesen Quellen arbeiten.

Natürlich kann man das Feld der “Geschichte” auch aus anderen Perspektiven als der der historischen Forschung betrachten. Das Berufspraktikum bietet auch die Möglichkeit, in Museen, Archiven, Bibliotheken und ähnlichen Stellen tätig zu werden. Es geht in der Geschichte genauso um den Erhalt und die Darstellung von historischem Wissen wie um den weiteren Erkenntnisgewinn. Als Geschichtsstudent:in hat man also eine Vielzahl von Möglichkeiten historisch tätig zu werden. Für mich persönlich liegt jedoch dieser Erkenntnisgewinn im Vordergrund. Da ich vorhabe, später hauptsächlich in diesem Teilbereich der Geschichte zu arbeiten, sollte mein Praktikum hauptsächlich diesen Aspekt widerspiegeln.

Die direkte Arbeit mit historischen Quellen war mir daher besonders wichtig für mein Praktikum, und hier kommt das „chigc“-Projekt ins Spiel. Das interdisziplinäre Kooperationsprojekt von fünf europäischen Universitäten, gefördert von der DFG und dem FWF, Laufzeit 2022-2025, hat es sich zur Aufgabe gemacht, die über die Jahrhunderte entstandenen Abschriften des von Peter von Poitiers im 12. Jahrhundert niedergeschriebene Compendium historiae in genealogia Christi zu erfassen, zu untersuchen, zu edieren und dabei vor allem auch zu „visualisieren“.

Im Rahmen dieses Blogposts möchte ich das Projekt im Allgemeinen und meine Aufgaben darin kurz vorstellen. Außerdem werde ich hier über meine Erfahrungen als Teil eines Forscherteams schreiben, und was ich für mich persönlich aus der Arbeit im Projekt mitnehmen werde.

Das Projekt

Das Projekt zur Visualisierung des Compendium historiae in genealogia Christi (chigc) ist ein Gemeinschaftsvorhaben der Universitäten Graz, Tübingen und Wuppertal, zusammen mit Kooperationspartnern an der Universität Ca’Foscari Venedig und der University of London, die von Januar 2023 bis Dezember 2025 läuft. Gegenstand des Projekts ist das gleichnamige Werk von Peter von Poitiers aus dem 12. Jahrhundert. Dieser verbildlichte die biblische Heilsgeschichte in Form einer linearen genealogischen Synopse von Adam und Eva bis zum Tod Christi. Entlang einer vertikalen Achse listete er die theologisch relevanten Personen samt ihren Beziehungen zueinander auf und erläuterte einige dieser Personen an manchen Stellen mithilfe kurzer Texte.

Beispielhafte Darstellung des Compendiums anhand der Handschrift B.15.4 des Trinity Colleges

Oftmals findet sich das Compendium in Begleitung der Historia Scholastica, verfasst von Petrus Comestor, welche ebenfalls die Heilsgeschichte des Alten Testaments darstellt, allerdings komplett in Textform.

Ein Autograph von Peter von Poitiers ist uns leider nicht überliefert, wir kennen das Werk aber recht gut, da sich dieser “Stammbaum” vom 12. bis 16. Jahrhundert im lateinischen Westen so sehr verbreiten konnte, dass uns heute mehr als 300 Abschriften überliefert sind. Das chigc-Projekt hat es sich zur Aufgabe gemacht, diese Abschriften zu sichten, zu untersuchen, zu edieren und dabei vielleicht auch das Stemma der Abschriften (also ihre Abstammungsverhältnisse) zu rekonstruieren. Die Frage, die ich in der Einleitung angesprochen habe, durch welche Linse Geschichte konstruiert werden sollte, wird in dem Projekt relativ einfach beantwortet: “durch möglichst viele!”. Der Grund für die Kooperation der fünf Universitäten ist, dass das Compendium so durch die Blickwinkel der Kunstgeschichte, lateinischen Philologie, mittelalterlichen Geschichtsforschung, Editionswissenschaft und digitalen Geisteswissenschaft betrachtet und untersucht werden kann.

Meine Arbeit im Projekt

Mein Praktikum im chigc-Projekt läuft seit Juli 2023. Ich bin also etwas mehr als ein halbes Jahr nach Beginn des Projekts dazugestoßen. Das Team in Wuppertal ist hauptsächlich mit den digitalen Aspekten des Projekts und Fragen der editorischen Aufbereitung betraut. Es geht dabei u.a. um die Visualisierung der Struktur der Handschriften und ihrer Überlieferungsvarianz. Was soll dargestellt werden, was kann vernachlässigt werden? Wie sollte man die Eigenschaften der Handschriften sortieren, gruppieren und abbilden?

Im Projekt selbst hatte ich vor allem mit Elisa Cugliana und Lennart Rouxel zu tun, zwei Mitgliedern des Teams in Wuppertal, die sich mit diesen Fragen beschäftigten, und Patrick Sahle, dem Leiter des Wuppertaler Teams. Elisas Hauptaufgaben lagen in meiner Zeit einerseits bei dem sogenannnten „navigational graph“ als Visualisierung des Werkes und andererseits der Stemmatologie der Handschriften, sprich deren Verwandtschaftsgrad und welche Handschrift von welcher kopiert wurde. Lennarts Aufgabe war es, Überlegungen zur späteren Visualisierung anzustellen.

Die bekannten Handschriften waren zu Beginn meines Praktikums schon in einer Erfassungs- und einer Superstrukturtabelle, gelistet, Digitalisate (falls vorhanden) und IDs waren somit schon geordnet. Die nächste Frage war also, nach welchen Faktoren die Kodizes und Rollen verglichen werden sollten. Fest stand, dass die finale digitale Ansicht in “Layer” unterteilt wird, um Benutzerfreundlichkeit zu gewährleisten. Der “Stammbaum” (Graph) wird im obersten Layer dargestellt, Verbindungen (Connections) und Gruppierungen (Groups) der einzelnen Personen (Nodes) in einem weiteren Layer. Die Diskussion, ob noch ein dritter Layer mit gesonderten Informationen zu den Nodes erstellt werden sollte, wurde kurze Zeit nach meiner Ankunft wieder verworfen. Dies war, auf seine eigene Art, direkt ein Einblick für mich, wie die Zusammenarbeit in internationalen Projekten funktioniert. Neue Ideen werden erdacht und dann in einer größeren Gruppe abgewogen. Nicht jeder Plan schafft es zur Umsetzung, aber verschiedene Ideen aus mehreren Blickwinkeln zu diskutieren, gehört zweifelsfrei zu einer konstruktiven Zusammenarbeit dazu.

Nach der ersten Woche “Eingewöhnung” und Auseinandersetzung mit dem Werk Compendium, sowie einschlägiger Literatur (beispielsweise die sehr zu empfehlende Habilitationsschrift von Andrea Worm zur Kunstgeschichte[1]) fingen meine eigentlichen Aufgaben in der zweiten Juliwoche an. Als Mitglied der “digital natives” bin ich das Paradebeispiel für die Menschen, die zwar täglich mit digitalen Medien arbeiten, aber wenig bis keine Ahnung haben, sobald es um etwas mehr als Endnutzung geht. Während ich mir durchaus bewusst war, dass mein Praktikum in den Digital Humanities etwas mehr als meine Vorkenntnisse erfordern würde, war ich doch etwas nervös, als ich mich in der folgenden Woche sowohl auf GitHub eingearbeitet, als auch mit SVG auseinandergesetzt habe. SVG ist ein Dateiformat, welches sich zum Darstellen von Vektorgrafiken eignet. Vektorgrafiken sind herkömmlichen Bildern im JPG- oder PNG-Format in der Hinsicht überlegen, dass sie skalierbar sind und somit nicht an Bildschärfe verlieren. Sie können nicht “verpixelt” werden. Daher wird SVG voraussichtlich das Format sein, in dem der Graph schlussendlich codiert werden soll. Dementsprechend habe ich mich zusammen mit Lennart an SVG gewagt und die ersten Zeichnungen “geschrieben”. Ebenfalls zu dieser Zeit ging die erste Version von Cadmus für chigc online. Cadmus ist ein digitales Annotations-Tool, welches es ermöglichen und vereinfachen sollte, die Handschriften in einem Overlay zu sortieren und Nodes, Connections und Groups zu markieren und mit Anmerkungen zu versorgen. Diese erste Phase bestand hauptsächlich aus Bug-Testing und nach ein paar Tests von allen Teams wurde Cadmus zur Überarbeitung erstmal wieder offline genommen. Damit verschwand Cadmus und SVG erstmal aus meinem Blickfeld und ich wandte mich anderen Aufgaben zu.

So sieht Cadmus während der Annotation aus

Die erste dieser Aufgaben hatte mit der vorher erwähnten umfassenden „Superstructure“ aller erfassten Handschriften zu tun. Die Personen (Nodes) waren schon sortiert, die Groups waren bekannt, doch die Nodes waren noch nicht den Groups zugeordnet. Diese Zuordnung war meine Aufgabe. Dies war zum einen einfacher als SVG, zum anderen half mir dies auch, einen Überblick über die Genealogie zu bekommen. Das Alte Testament ist voll von Personen mit (für mich) unkonventionellen Namen und eine Zuordnung von Personen zu Personengruppen kam mir sehr gelegen. So konnte ich mich mit der mir größtenteils in diesem Ausmaß unbekannten Ebene der christlichen Theologie auseinandersetzen.

Am 11. Juli fand ein Meeting aller Teams in Graz statt, dem ich via Zoom beiwohnte. Der Austausch war im Großen und Ganzen produktiv und verfestigte die Vorhaben der einzelnen Teams. Persönlich war ich beeindruckt vom Vorgehen der Teams. Im universitären Lehrbetrieb wird immer wieder Interdisziplinarität in individueller Forschung betont, dieses Teammeeting zeigte mir aber einen anderen Zugang. Jedes Team kümmerte sich um die jeweils eigene Disziplin und Austauschmeetings sorgen dafür, dass das Gesamtziel nicht aus den Augen verloren wird. So werden die einzelnen Disziplinen zu einem interdisziplinären Gesamtprodukt verbunden werden.

Transkribieren, Annotieren und Diskutieren

Nach dem Meeting bekam ich die Aufgabe, die ersten Texte zu transkribieren. Manche Nodes haben “Begleittexte” mit Erläuterungen. In der ersten Gruppe (g-adam_eua), die Adam, Eva und deren fünf Kinder beinhaltet, lassen sich für gewöhnlich drei solcher Texte finden, ein „langer“ für Adam, einer für Cain und ein kurzer für Seth. Die Transkription dieser Texte ist wichtig für die Stemmatologie der Handschriften (damals Elisas Aufgabe), da sich durch Unterschiede innerhalb der Texte am ehesten feststellen lässt, welche Texte von welchen anderen Texten abgeschrieben wurden (Ich nenne dies das Stille-Post-Prinzip). Diese Transkriptionen fertigte ich zunächst in dem Online-Tool Miro an.

Ich besitze aus Schulzeiten das Latinum und ich habe aus Interesse an der Sprache zusätzlich an der Universität, sogar im gleichen Jahr, noch Lateingrundkurse belegt. Sprachlich war ich also durchaus in der Lage, die drei Texte zu verstehen. Leider ist das Latein, das in Schule und Uni gelehrt wird, aus der Zeit der späten Republik. Das Latein der Handschriften ist jedoch zwölf bis sechzehn hundert Jahre jünger und vor allem die (in der Antike übliche Vorgehensweise Wörter abzukürzen stellte mich zusätzlich zur variierenden generellen Lesbarkeit der Texte vor einige Herausforderungen, wodurch diese Transkriptionsaufgabe den Hauptteil der nächsten zwei Monate in Anspruch nahm.

Glücklicherweise gab es zu diesem Zeitpunkt im Projekt schon eine “Leit-Transkription” der Handschrift CCC29 des Corpus Christi College in Cambridge, welche auf den Beginn des 13. Jahrhunderts datiert werden kann und von der daher angenommen werden kann, dass sie sehr nah am nicht erhaltenen Original von Peter von Poitiers ist.

CCC29 und die entsprechende Leit-Transkription der drei Texte

Es sind momentan etwa einhundert der dreihundert erhaltenen Handschriften digital verfügbar. Das bedeutet, ich hatte potentiell circa dreihundert Texte zur Transkription der ersten Gruppe vor mir. Während es sich vielleicht erstmal etwas trist und langweilig anhört, verteilt über zwei bis drei Monate einhundert Mal den gleichen Text zu Adam zu transkribieren, nur um dies dann mit Cain und Seth zu wiederholen, hat sich die Arbeit doch als überraschend interessant und abwechslungsreich herausgestellt und ähnelte eher einer Detektivarbeit als einem repetitiven Abschreiben. Der Inhalt der Texte war (größtenteils und im besten Fall) gleich. Die entsprechenden Stellen in den Handschriften zu finden, war die erste Herausforderung. Da es keine universellen Regeln zur Anfertigung von solchen Abschriften bei mittelalterlichen Handschriften gab, sind die Texte zwar in der Nähe der jeweiligen genealogischen Knoten, aber in zwei Handschriften selten an genau derselben Stelle. Hatte ich die Texte einmal gefunden, musste ich als nächstes schauen, wo sie wieder aufhörten. Oft half der Initialbuchstabe des folgenden Textchens, aber auch das war kein allgemeingültiger Anhaltspunkt. Einige Versionen waren bis zu dreimal so lang wie der Leittext in CCC29, andere waren deutlich kürzer. Waren dann diese Rahmenbedingungen geklärt, ging es an den Inhalt. Ich habe gerade die Abkürzungen einzelner Wörter angesprochen. Die Suspensionen, Kontraktionen und mir unbekannten feststehenden Zeichen zu identifizieren und diese zu entschlüsseln, war mir anfangs nur anhand der Leit-Transkription möglich. Die stetige Wiederholung der gleichen Texte sorgte dafür, dass mir das Entziffern der Schrift mit der Zeit immer leichter fiel und Ähnlichkeiten eher ins Auge stachen. Wenn ich darüber nachdenke, stelle ich mir meinen Fortschritt nicht unähnlich dem der Schreiber vor, die die Texte ursprünglich händisch kopierten: Übung macht den Meister.

Der Cain-Text in ctc-b-15-4, ctc-b-15-5, CCC-437 und mbm-89. Irgendwann erkennt man das Muster.

Die meisten der Texte waren nach einiger Zeit recht einfach zu transkribieren. Einfach heißt hierbei, dass ich fünf bis sechs Handschriften an einem guten Arbeitstag übertragen konnte. Jedoch gab es immer mal wieder interessante Ausnahmen. add-30509 der British Library in London, eine Handschrift, die irgendwo in Ostengland im 15. Jahrhundert entstand, überraschte mich beispielsweise damit, komplett auf Latein zu verzichten und stattdessen in Mittel-Englisch geschrieben zu sein.

Der Adam-Text in der alt-englischen Version in lbl-add-30509

Ein anderer bemerkenswerter Ausreißer ist der Vaticanus Latinus 3782. Diese Handschrift stammt aus dem späten 13. Jahrhundert, liegt also zeitlich vergleichsweise nah am Original. Trotzdem sind die Texte in Vat.Lat. 3782 im Schnitt drei- bis fünfmal so lang wie üblich. Vor allem der Seth-Text wächst von den üblichen zwei Zeilen plötzlich auf 11 Zeilen an, so dass sich die Frage stellt, on dies hier überhaupt noch das selbe Werk ist?

Der gigantische Textabschnitt zu Seth in vba-vat-lat-3782, “normale” Seth Texte enden nach Zeile zwei.

Eine Anomalie anderer Art ist hingegen apel-1 der Universitätsbibliothek Leipzig aus dem 15. Jahrhundert. Hier taucht aus dem Nichts ein Text zu Abel, dem dritten Sohn von Adam und Eva, auf. Von allen Handschriften, die ich transkribiert habe, ist diese die Einzige, die Abel mit einem eigenen Text würdigt.

Woher kommt der Text zu Abel in lub-apel-1?

Diese Passage ist ähnlich zu einem Text zu Abel aus Isidor von Sevilla’s (560-636) De ortu et obitu patrum. Momentan ist noch unklar, wo apel-1 entstanden ist, es ist jedoch durchaus möglich, dass der Text aus De ortu et obitu patrum in die Handschrift gelangt ist. Etwas, womit ich vor den Transkriptionen nicht gerechnet hätte, ist das sporadische Auftreten arabischer Zahlen. Laut den Texten stammt Adam aus dem Land, in dem vier Flüsse zusammenfließen. Diese Ziffer “vier” wird im Regelfall entweder durch die römischen Numerale IIII dargestellt oder ausgeschrieben (“quattuor”), ab und zu taucht jedoch eine “4” auf und in zwei bis drei Fällen wird das nachfolgende Symbol  verwendet:

Nach  kurzem  Raten,  was  es  bedeuten  könnte,  fanden Patrick und ich heraus, dass es ein arabischer Vorgänger der Ziffer “4” ist, im Endeffekt stellt das Symbol nichts anderes dar als “halbe 8” (die obere Hälfte, um genau zu sein).

Ich denke, durch meine Ausführungen hier wird schnell offensichtlich, dass ich zu jeder einzelnen Version der drei Texte etwas Interessantes schreiben könnte und obwohl sich der Inhalt ähnelt, sind keine zwei Texte ganz identisch. Ich sehe allerdings ein, dass eine Aufzählung schnell langweilig werden kann. Während die Transkription dieser Texte zwar den Großteil meiner Arbeit im Compendium (bis jetzt) ausmachte, möchte ich im Folgenden noch einmal kurz auf andere Erlebnisse und Aufgaben eingehen.

Anfang August tauschte ich mich kurz mit Eleanor Goerss aus Tübingen aus. Ich hatte ein paar Fragen und auch die ein oder andere Anmerkung zu Unklarheiten in der Kanon-Transkription. In der Transkription bestand beispielsweise die Unklarheit, ob am Ende des Cain-Texts “etiam” oder “est” steht. Meine Arbeit mit anderen Handschriften ließ mich schlussfolgern, dass “est” richtig war. Zur gleichen Zeit habe ich auch den Aufbau meiner Transkriptionen im Miro-Board angepasst, zu den einzelnen Transkriptionen den Aufbewahrungsort, Entstehungsort und -zeit und das Kürzel hinzugefügt.

Nach dem Austausch mit Eleanor wandte ich mich noch einmal der Superstructure zu. Dort hatte ich einen Monat zuvor die Nodes den Groups zugeordnet, und jetzt, mit Eleanors Feedback, begann ich die Texte des Compendiums, die noch keinen Gruppen zugeordnet waren, zuzuordnen. Elisa arbeitete zu dieser Zeit weiter an den  stemmatologischen Ansätzen. In diesem Zusammenhang zeigte sie mir verschiedene Software-Lösungen, die meine Transkriptionen auswerten und die Verwandtschaftsgrade berechnen können sollten. Es gab mir ein gutes Gefühl, diese ersten Ergebnisse zu sehen, da ich so wusste, dass meine Arbeit direkt im Team weiterverwendet wurde.

Beispiel für einen ersten, von Elisa erstellten, “Stammbaum” der Handschriften

Physische Handschriften in der digitalen Zeit

Trotz meines Interesses an den Handschriften war ich gleichzeitig zumindest physisch sehr distanziert von selbigen. Am Ende des Tages arbeitete ich mit Digitalisaten, manchmal einfachen Fotografien, und nicht mit den eigentlichen Schriften selbst. Daher kam es mir sehr gelegen, als Patrick und ich am 28. September das neue historische Archiv in Köln besuchten, um dort die Handschrift kha-w-247 zu bestaunen. kha-w-247 stammt (vermutlich) aus der zweiten Hälfte des 12. Jahrhunderts und liegt somit, ähnlich wie CCC-29, zeitlich sehr nah am Original. Daher hatte die Besichtigung des Kodex neben dem Interesse an einem physischen Exemplar auch praktische Gründe. Zuallererst konnten wir so eigene farbige Fotografien anfertigen, die bereits digital verfügbare Version (ein Scan eines alten Mikrofilms) war nur in schwarz-weiß. Außerdem haben wir festgestellt, dass die Abbildung der Arche, in den meisten Handschriften eine von drei Abbildungen im Compendium, in kha-w-247 nicht im Compendium selbst, sondern in der im gleichen Band eingebundenen Historia Scholastica von Petrus Comestor zu finden ist. Da die beiden Werke oft zusammen innerhalb eines Kodex vorkommen, ist anzunehmen, dass die Arche in späteren Abschriften von der Historia Scholastica in das Compendium wanderte. Dabei muss ich auch erwähnen, dass die letzte Seite des Compendiums in kha-w-247 verstärkt ist und die Quarternionen der Historia Scholastica nummeriert sind, die des Compendiums allerdings nicht. Dies könnte ein Indiz für eine nachträgliche Zusammenführung der beiden Handschriften sein, muss aber nichts heißen. Nach den zwei Stunden im Archiv haben wir also schon einiges herausgefunden, was uns die digitale Version nicht bieten konnte.

Finale Erfahrungen und Erkenntnisse

Seit der zweiten Oktoberhälfte war ich so gut wie fertig mit den Transkriptionen der Texte aus g-adam_eua und widmete mich den Annotationen in der aktuellen Version von Cadmus. Während es im ersten Durchgang primär um Bug-Testing ging, standen nun Usability und die Frage, was und wie man am besten annotieren kann im Vordergrund. Zu diesem Zweck bearbeitete jedes Team dieselben Seiten der gleichen Handschrift und es besteht ein reger E-Mail-Austausch über Ideen und Feedback zwischen den Teams. Ich bin mir noch nicht sicher, was der nächste Punkt auf der Agenda sein wird, aber ich freue mich schon drauf. Außerdem begann ich damit, die g-adam_eua Transkriptionen in XML zu übersetzen. Dieses Format erlaubt eine bessere Weiterverarbeitung der Texte und wird sich in Zukunft als praktischer erweisen als das Miro-Board.

Beispiel einer XMLTranskription von t-adam.

Mein Praktikum dauerte insgesamt knapp ein halbes Jahr. Ich habe um diese längere Laufzeit (bei reduzierter Stundenanzahl pro Woche) gebeten, da ich die Vorgänge in einem geschichtswissenschaftlichen Projekt über einen längeren Zeitraum beobachten und mich daran beteiligen wollte. Wäre ich nur die ursprünglich vorgesehenen sechs Wochen dabei gewesen, hätte ich vermutlich viele Veränderungen nicht mitbekommen und auch meinen Aufgaben nicht so intensiv nachkommen können. Jetzt nähert sich das Praktikum dem Ende zu, ich möchte allerdings noch weiter im Projekt bleiben. Die Art und Weise, wie hier im Team gearbeitet wird, gefällt mir. Ich habe meine eigenen Aufgaben, ohne dass ich jemand anderem dabei in die Quere komme. Gleichzeitig kann ich auf die Expertise der Kollegen in Wuppertal und in den anderen Teams bauen. So muss ich kein Experte in allem sein, um am Ende ein Ergebnis produzieren zu können, das noch dazu einen Mehrnutzen für sowohl interessierte Webseitenbesucher als auch die scientific community haben wird.

Für mich persönlich kann ich (neben dem ganzen neuen Wissen über Verwandtschaftsverhältnisse im Alten Testament) mitnehmen, dass mir das Arbeiten mit digitalen Methoden Spaß macht. Auch wenn ich vorher maximal einen Einführungskurs in Python besucht habe, sind SVG, Cadmus etc. kein Hexenwerk, sondern bieten Möglichkeiten historisch zu arbeiten, die ich vermutlich auch privat in Zukunft verwenden werde. Falls jemand diesen Eintrag liest und sich gerade fragt, ob sich ein Praktikum in den Digital Humanities lohnt, kann ich diese Möglichkeit, Erfahrungen zu sammeln und in wissenschaftlicher Teamarbeit zu forschen, nur wärmstens ans Herz legen.


[1] Worm, Andrea: Geschichte und Weltordnung: Graphische Modelle von Zeit und Raum in Universalchroniken vor 1500, Deutscher Verlag für Kunstwissenschaft, 2021.

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.


Von der Detektivarbeit einer kodikologischen Novizin: Eine Autopsie der Lagenstruktur Dom. Cod. 83-II 

Janna Schillinger

Da wage ich mich einmal in die kodikologische Forschung hinein und schon sorgt ein spannender mittelalterlicher Codex dafür, dass ich seine Anatomie ergründen will. Hier möchte ich von meiner Reise durch den dunklen Wald der Detailforschung berichten und zeigen, dass in der Geschichtswissenschaft auch mit wenig Erfahrung aufregende Entdeckungen möglich sind.

Um herauszufinden, wie sich Inhalt und lagenstrukturelle Form der Handschrift 83-II aus dem Bestand der Kölner Diözesan- und Dombibliothek zueinander verhalten und ob daraus weitere Erkenntnisse gewonnen werden können, habe ich ihren Aufbau visualisiert und in Relation zu ihrem Inhalt näher untersucht. Mit Hilfe des VCEditors von VISCOLL und den Handschriftenbeschreibungen der Dombibliothek war es mir möglich, die Lagenstruktur für die bevorstehende Detektivarbeit zu modellieren. Die dabei entstandene interaktive Grafik ist unter folgendem Link einsehbar: Visualisierung Cod. 83-II.

Abb. 1 Die Gesamtvisualisierung von Cod. 83-II …ist lang.

Bei der untersuchten Handschrift, die in den Katalogen unter dem Titel Kompendium der Zeitrechnung, Naturlehre und Himmelskunde geführt wird, handelt es sich um einen 219-seitigen auf Lateinisch in karolingischer Minuskel geschriebenen Codex auf Pergament. Er entstand vermutlich in den Jahren 798 und 805 n. Chr. in Köln und wurde von einer noch nicht bestimmten Anzahl an Schreibhänden erstellt. Die zum Zeitpunkt der Digitalisierung durch das DFG-Projekt CEEC (Codices Electronici Ecclesiae Coloniensis) im Jahr 2000 entbundene Handschrift beinhaltet Abschriften von Texten unterschiedlicher Autoren. Darunter befinden sich beispielsweise solche des Bischofs Isidor von Sevilla über Naturphänomene sowie ausführliche Teile des Werks zur Zeiteinteilung und -berechnung von Beda Venerabilis. Gleichsam lassen sich Informationen zu der Kunst der Zeitrechnung entnehmen sowie zahlreiche aufwendig gestaltete Lehrfiguren darin betrachten.

Auf dem Weg zu einer Visualisierung: Die Lagenformel und das Digitalisat

Die Struktur der Handschrift wird in den Katalogen durch sogenannte Lagenformeln beschrieben. Im Katalog Glaube und Wissen findet sich beispielsweise diese Formel:

„1 1+8+1, 2 4, 3-4 8, 5 6, 6-7 8, 8 6, 9 8, 10 6-3, 11-19 8, 20 4, 21-23 8, 24 4-2, 25-27 8, 28 6+2, 29 8, 30 6+2  “ (van Euw 1998), 

während im Anderson-Katalog Folgendes steht:

[7], i 1+8+1, ii 4, iii-iv 8, v 6, vi-vii 8, viii 6, ix 8, x 6-3, xi-xix 8, xx 4, xxi-xxiii 8, xxiv 4-2, xxv-xxvii 8, xxviii 6+2(signature on 6th, two singles at end were previously a separate bifolium), xxix 8, xxx 6+2 (two added at end, signature on 6th), [1]. Quire signatures V, VI, XI, XIII- XXIII, XXVI-XXVIII, XXX(xxix)-XXXI(xxx) visible entire or partly trimmed; XXVIII and XXXI(xxx) on 6th (see collation) (Anderson u. Black 1997) .

Formal setzt sich 83-II aus dreißig Lagen mit zumeist acht Blättern zusammen, wie die Lagenformeln verraten. Deren kryptisches Format zu verstehen, stellte die erste Hürde des Modellierungsprozesses dar. Mit logischem Schlussfolgern war sie jedoch schnell zu überwinden, wobei dennoch Unklarheiten über die Position von hinzugefügten oder fehlenden Blättern innerhalb der jeweiligen Lagen bestanden. Da Cod. 83-II aber im entbundenen Zustand digitalisiert wurde, ließ sich die in der Lagenformel nicht aufgeführte Erklärung zu ihrer exakten Verortung in den Bilddigitalisaten finden. Weil aus diesem Grund Einzel- und Doppelblätter deutlich zu unterscheiden waren, konnten die für die Modellierung notwendigen Informationen in den digitalen Bildern beschafft werden. Darauf aufbauend ließen sich anhand der Sauberkeit jeder Schnittkante und der Vollständigkeit der Texte ebenso eine gewaltsame Entfernung oder allmähliche Erosion als Ursache für fehlende Einzelblätter ausschließen. Vielmehr ist ersichtlich geworden, dass die Einzelblätter ordentlich zurechtgeschnitten und daraus schlussfolgernd bewusst eingefügt oder entfernt wurden.

Das Ermittlerwerkzeug: Der umfangreiche VCEditor von VISCOLL

Abb. 2 VCEditor von VISCOLL im „Visual Mode”

Waren diese Aspekte erst einmal nachvollzogen, konnte ich damit beginnen, die Lageninformationen von Cod. 83-II in den VCEditor zu übertragen. Dies stellte sich als einfacher heraus als zu Beginn des Vorhabens angenommen, da die Editor-Oberfläche sich nicht nur intuitiv und aufgeräumt anfühlte, sondern sich die Verwendungsweise der wichtigsten Funktionen selbst erklärten. Auch tiefergreifende Optionen – wie das effiziente Einbinden der Bilddigitalisate mittels der iiiF-Manifest-URL der Diözesan- und Dombibliothek – ließen sich ohne Schwierigkeiten bedienen. Die Möglichkeit zum Erstellen einer eigenen „taxonomischen Liste“ war zudem hilfreich.

Abb. 3 Taxonomien in VISCOLLs VCEditor

Darunter versteht VISCOLL die Möglichkeit zum Anlegen eigener Beschreibungen, wodurch sich bestimmte Blätter gezielt mit Begriffen (terms) wie Autorennamen oder Titeln versehen lassen. Auf diese Weise können zudem beispielsweise sämtliche in der Handschrift eingetragenen Autorennamen sowie ihre Position in der Visualisierung angezeigt und nachvollzogen werden. 

Abb. 4 Unklare Autor-Titel-Beziehung in Lage xii

Es wäre allerdings hilfreich, wenn beispielsweise Titel-Autor-Begriffspaare auch als einander zugehörig angegeben und nicht als lose Einzeltags an den Blättern erscheinen würden. Zudem ließ sich die Reihenfolge der terms nicht beeinflussen, weshalb die Beziehung der angehefteten Begriffe zueinander manchmal nicht eindeutig ist (z.B.: Blatt 84 (L84)–Blatt 88 (L88)). Die Implementierung einer Option zur Definierung klarer Eigenschaft-Wert-Paare könnte ein Lösungsansatz sein.

Als weiterer Kritikpunkt sei allerdings zu nennen, dass sich die Reaktionsgeschwindigkeit des webbasierten Editors mit der Zeit immer weiter verlangsamte, je mehr Informationen hinzukamen. Denn obwohl er bis zu etwa der 17. Lage flüssig lief, verzögerten sich Eingaben von dieser Lage an immer stärker bis beispielsweise das Anhängen von Begriffen auf Blättern unterer Lagen schließlich bis zu zwölf Sekunden in Anspruch genommen und so den Arbeitsfluss erheblich beeinträchtigt hat.

Hinsichtlich der Beschriftung lässt sich diskutieren, ob jedes Blatt mit Autor und Titel benannt werden sollte oder es der Übersichtlichkeit dienlich wäre, nur exakt das Blatt zu etikettieren, auf dem ein neues Kapitel startet. Bei mehreren auf einer Seite beginnenden und endenden Kurzkapiteln wäre in einem solchen Fall die Zuordnung und Chronologie jedoch unklar, vor allem in Hinblick auf die Einschränkungen des VCEditors bezüglich der term-Reihenfolge. 

Ich persönlich denke stark in optischen Mustern, sodass mir der Umfang eines jeden Kapitels durch ein gleiches Betitelungsschriftbild direkt klar wird, weshalb ich mich für die durchgängige Beschriftung entschieden habe. Allerdings musste ich dabei darauf achten, mich nicht zu sehr zu einer Missachtung des Inhalts verleiten zu lassen.

Letztendlich entstand jedoch eine Lagenvisualisierung, anhand derer sich der inhaltliche wie strukturelle Aufbau miteinander in Verbindung setzen und deren Zusammenspiel beobachten ließ. Zu Beginn dieser Reise durch die Anatomie von Cod. 83-II bestand die Erwartung, dass sich durch den Inhalt der Blätter einer Lage Schlüsse daraus ziehen lassen könnten, warum sich bestimmte Anordnungen auffällig gestalten. So könnte sicherlich nachvollzogen werden, wo Nachträge eingeschoben wurden oder warum bestimmte Blätter fehlen. Rückschlüsse wären beispielsweise darüber möglich, ob sie aus Gründen persönlicher Gesinnung willentlich entfernt oder etwa durch eine inhaltlich begründbare häufige Verwendung zur vollständigen Herauslösung erodiert sind. Im Fall von Cod. 83-II allerdings war die Ursache auch mit der Visualisierung nicht immer eindeutig auszumachen oder mit seinem Inhalt zu begründen, vor allem da es mir noch immer an ausreichendem kodikologischen Erfahrungswissen mangelt.

Auffälligkeiten in der Lagenstruktur von Cod. 83-II

Bei einer Betrachtung der Gesamtvisualisierung fällt zunächst auf, dass einundzwanzig Lagen der achtblättrigen Struktur folgen. Zwei weitere Lagen schließen sich ihnen durch ihre zwei additiven Einzelblätter an (xxviii und xxx). Zudem wird das Muster immer wieder von kleineren Lagen mit vier oder sechs Blättern unterbrochen. Umschlossen wird die gesamte Ordnung zu Beginn und am Ende jeweils von einem Einzelblatt. Längere Abfolgen gleichartiger Blattgruppierungen lassen sich nur bei Lagen wie xi bis xix oder xxv bis xxvii feststellen. Die restlichen Lagen weisen Besonderheiten auf, die sich teilweise aber nicht immer inhaltlich begründen lassen.

Ob das einzelne Vor- und Nachsatzblatt aus Papier jeweils als eigenständige Lage berücksichtigt werden sollten, bleibt allerdings zu diskutieren. Auf der einen Seite sind sie keine Segmente des Haupttextes einer Handschrift, sondern eine Form ihrer Präsentation und bestehen wie in diesem Fall oft aus einem abweichenden Material. Auf der anderen Seite werden sie in den Katalogen dennoch gesondert in der Formel aufgenommen, wenn auch nicht mitgezählt. Zudem sind sie ein Teil des aktuellen Ist-Zustandes einer Handschrift, auch wenn sie weder als Lage im eigentlichen Sinn zu verstehen sind noch in der Lagenzählung inkludiert werden.

Bei der Visualisierung von Cod. 83-II habe ich ihre Aufnahme in Form einer Lage deshalb gewählt, weil im VCEditor zurzeit keine losen Blätter vor einer Lage eingefügt werden können, ohne ihnen eine eigene Lage zuzuweisen.

Das hat jedoch zur Folge, dass die Lagenzählung in dem Endprodukt von der Zählung der Lagenformeln der Kataloge um zwei divergiert, was zu Verwirrung bei der Untersuchung der Lagenstruktur führen kann. Zum besseren Verständnis habe ich die Lagen in dieser Visualisierung ab Quire 2 zusätzlich mit bei beginnenden fortlaufenden römischen Ziffern versehen, die in der folgenden Diskussion Verwendung finden sollen.

Abb. 5 Lage i

Bereits Lage i hebt sich von ihren Folgelagen ab, da sie unter anderem insgesamt aus zehn Blättern besteht, was in dieser Handschrift einen Einzelfall darstellt. Das erste Blatt (L2) der Lage, auf dem sich ein Bucheignerzeichen Erzbischof Hildebalds lesen lässt, ist als eine an L3 angefügte Ergänzung zu betrachten und ist kein Teil eines Doppelblatts. Dies ist inhaltlich nachvollziehbar, da es sich als eine Art nachträglich angebrachtes Namensschild präsentiert. Darauf folgt ein regulärer Quaternio (vier Doppelblätter), der mit einem Vorwort Hieronymus‘ und Eusebius‘ zu der christlichen Geschichtsschreibung beginnt. Letztere geht ab der Rectoseite von L6 (5r) in einen Teil der Weltchronik Bischof Isidors über, die sich wiederum noch bis auf die Versoseite von L13 (12v) in Lage ii erstreckt. Auffällig ist, dass mit L11 innerhalb der Lage auch ein Blatt zu finden ist, das laut der Anderson-Katalogbeschreibung als zur originalen Lage zugehörig anzusehen sei (vgl. Anderson u. Black 1997), jedoch ein Einzelblatt darstellt. Dank des gleichen Autors und Werks schließen sich 10v und 11r trotz der Besonderheit aneinander an, sodass Lage ii schließlich nach einer Ergänzung mit historischen Daten aus Köln enden kann. Inhaltlich lässt sich die Position des Einzelblatts daher nicht erklären, weil es sich um eine in sich geschlossene Ordnung handelt. Unterstützt wird diese Deutung auch durch den Katalog Glaube und Wissen, der hierzu formuliert: „Die beiden ersten Lagen (2r–14v) bilden formal und inhaltlich eine Einheit“ (van Euw 1998).

Rätselhaft ist dennoch, warum das Einzelblatt ursprünglich eine einzelne Lage gebildet haben soll, wenn es sich inhaltlich bereits mitten in Isidors Weltgeschichte zu befinden scheint. Gleiches gilt für das Einfügen der vier Doppelblätter zuvor, die inhaltlich ein volles Vorwortkapitel beinhalten und mit „Chronicon“ noch ein weiteres Kapitel beginnen. Ist es hier vielleicht möglich, dass diese Kapitel traditionell gemeinsam auftraten? Das würde jedoch den Bereich der Koüberlieferungsverhältnisse antasten. Aufgrund des Umfanges kann dem in dieser Untersuchung nicht nachgegangen werden. 

Die obige Problematik bliebe auch bestehen, falls es sich stattdessen bei L11 um die in der Lagenformel beschriebene Addition handelt und L2 dafür das native Blatt darstellt. In diesem Fall würde sich allerdings die Frage auftun, warum das Einzelblatt ausgerechnet an das Ende von Lage i und nicht etwa an den Beginn von Lage ii angefügt oder thematisch abschließend nach 12v eingesetzt wurde, wenn es inhaltlich dazu doch keine Vorgaben zu geben scheint. Trotz der Auffälligkeiten liegt daher der Verdacht einer zufälligen Zusammensetzung von Lage und ii nahe.

Zwei mögliche Ursachen lassen sich jedoch als Gegenargumente für eine solche Beurteilung einbringen. Zum einen wäre der Wechsel von Schreiberhänden, der nach dem Anderson-Katalog in 83-II generell zwischen den Lagen vollzogen werde (vgl. Anderson u. Black 1997), möglicherweise ein Grund dafür. Eventuell wurde separat und zu mehreren Personen gleichzeitig an den Abschriften gearbeitet, wodurch sich die Stückelung erklären würde. Auf den ersten Blick erscheinen beispielsweise die linken Striche des Buchstaben x auf Folium 11r länger als bei dem gleichen Buchstaben auf 10v, doch nach einem näheren Studium lassen sich auch auf 10v solche längeren Striche finden, was das vermeintliche Indiz für unterschiedliche Schreiberhände schwächt. Da zu den Händen von Kodikolog*innen keine detaillierten (Positions-)Angaben gemacht werden und sich die Schriftbilder von 10v und 11r für das ungeübte Auge zu ähnlich sehen, kann ich keine fundierte Aussage darüber treffen. 

Zum anderen könnte eine Ursache darin liegen, dass die in der Lagenformel beschriebene Addition von acht und einem Blatt zeitlich vor dem Beschreiben mit der Abschrift Isidors vollzogen worden ist, sodass sich die inhaltliche Kontinuität trotz besonderer Form dadurch ergibt. Möglicherweise war nur ungefähr, jedoch nicht genau bekannt, wie viele Blätter für die Abschrift tatsächlich benötigt werden würden. Das Einzelblatt könnte als Erweiterung eingefügt worden sein, anstatt noch einen neuen Ternio (drei Doppelblätter) oder Quaternio zu beginnen, von denen unbeschriebene Blätter wieder hätten entfernt werden müssen. Um Material zu sparen, wurde vielleicht auf ein verfügbares Einzelblatt zurückgegriffen. Doch auch dafür stehen mir nicht genügend Informationen zur Validierung bereit. Abschließend klären lässt sich die auffällige Struktur von Lage daher noch nicht. 

Auf Lage ii folgen zwei regelmäßig achtblättrige Lagen, die sich den mathematischen Grundlagen sowie der Entwicklung der Zeitrechnung widmen. Es schließt sich daran Lage v mit nur sechs Blättern an. Da diese Lage allerdings mit den Ausführungen über die Astronomie eines unbekannten Autors endet, lässt sich als Ursache annehmen, dass lediglich nicht mehr Blätter für ihre Abschrift benötigt wurden und das Kapitel bereits in dieser Länge geplant wurde. Wenn man die Kapitel und die von ihnen behandelten Themengebiete genauer betrachtet, findet sich darin eine inhaltliche Strukturierung, die diese Annahme stützen kann.

Aus den 30 Lagen ergeben sich inhaltlich folgende 12 Blöcke. Block I (1r14v, Lage 1–2) behandelt den chronistischen Teil der Handschrift. Block II (15r36v, Lage 3–5) dagegen umfasst Kapitel zur Mathematik, Zeitrechnung und Astronomie, während sich Block III (37r44v, Lage 6) mit dem Mondzyklus beschäftigt. Daran schließt sich der vierte inhaltliche Abschnitt an (45r58v, Lage 7–8), welcher der Lehre der Zeitrechnung gewidmet ist. Es folgen Block V (59r69v, Lage 9–10) mit Vorschriften sowie Block VI (70r85v, Lage 11–12) mit Berechnungstabellen, Kalendern und „Rechenrädern“.

Abb. 6 „Rechenräder“ auf den Folia 81v82v und 85v (v.l.n.r.). Quelle: Digitalisat der Diözesan- und Dombibliothek.

Der siebte inhaltliche Block (86r125v, Lage 13–17) gebührt Beda Venerabilis mit Anleitungen zur Zeit- und Osterberechnung, während im Folgeabschnitt Isidor von Sevilla über die Naturphänomene spricht (126r145v, Lage 18–20). Thematisch knüpft Block IX (146r171v, Lage 21–24) über Himmelserscheinungen daran an. Außerdem ist ein zehnter Inhaltsabschnitt (172r187v, Lage 25–26) auszumachen, innerhalb dessen Traktate und Briefe gesammelt sind. Die letzten beiden Einteilungen können zwischen 188r bis 203v (Lage 27–28) sowie 204r bis 219v(Lage 29–30) getroffen werden. Während in dem ersten Block noch weitere Korrespondenzen aufgeführt sind, wird die Handschrift in dem letzten Abschnitt mit Saturnalien, Zyklen sowie einem kleinen Anhang abgeschlossen.

Da die Lagen iii bis v strukturell genau zu dieser Einteilung passen, ist es also gut möglich, dass von Anfang an genau 22 Blätter für sie eingeplant wurden (Inhaltsblock II).

Gleiches trifft auf die Lagen viii und xx zu. Beschreibstoffe waren im späten 8. Jahrhundert ein kostbares Gut und eine effiziente Verwendung darum vor allem bei Pergament wirtschaftlich. Allerdings scheint die Notwendigkeit dazu bei Cod. 83-II nicht allzu groß gewesen zu sein, da bis auf L1 alle 219 Pergamentblätter in dem verhältnismäßig großen Format von etwa 37 mal 27 Zentimetern ohne auffällige Materiallöcher zugeschnitten sind. Daher lässt sich davon ausgehen, dass entsprechende finanzielle Mittel sowie hochwertiges Material bei der Anfertigung zur Verfügung standen. Der Hinweis, dass es sich bei der Handschrift laut dem Katalog Glaube und Wissen außerdem um eine von Erzbischof Hildebald in Auftrag aufgegebene Kommissionsarbeit handle (vgl. van Euw 1998), passt dazu. Dennoch scheint auch bei Cod. 83-II auf unnötiges Material verzichtet worden zu sein, wie den sauberen Schnittkanten der Blätter nach zu urteilen ist.

Es stellt sich dann jedoch die Frage, ob die insgesamt fünf abgetrennten Einzelblätter stattdessen für die fünf Einzelblattergänzungen in den betreffenden Lagen verwendet wurden. Obwohl die gleiche Anzahl auffällig ist, spricht zumindest für zwei von ihnen das Folgende dagegen (L208 f.). Beide Einzelblätter sollen laut der Lagenformel des Anderson-Katalogs ursprünglich einmal ein verbundenes Doppelblatt – also vor ihrer Teilung eine Einheit – gewesen sein (vgl. Anderson u. Black 1997). Ob einige der übrigen Einzelblätter jedoch einmal zusammengehörten, lässt sich nur mittels einer eingehenderen Materialanalyse feststellen, die Struktur, Alter oder chemische Zusammensetzung untersucht. Für einen Laien ergeben sich zwischen den verbliebenen und den eingefügten Einzelblättern zwar teilweise übereinstimmende Maserungsähnlichkeiten an den Falzrändern, allerdings könnte es sich dabei ebenso um eine trügerische Wunschwahrnehmung handeln. 

Weil die Befestigung eines Einzelblatts außerdem erfordert, dass es ein wenig breiter ist als ein halbes Doppelblatt, ließe sich die These noch besser durch Ausmessen der in diesem Fall entbundenen Einzelblätter widerlegen. Beispielsweise sind die Blätter L208 und L209 ungefähr 27 Zentimeter breit, während bei den anderen Doppelblättern wie L206 von ihrem Rand bis zur Mitte der Falz nur etwa 26,5 Zentimeter zu messen sind. Das macht es unwahrscheinlich, dass sie ehemalig Teil eines Doppelblatts gewesen und abgetrennt in anderen Lagen als Einzelblätter eingefügt worden sind.

Abb. 7 Lage xxviii

Die Addition von zwei dieser Einzelblätter in Lage xxviii bleibt rätselhaft, da sie sich mit den Ausführungen des Pseudo-Hieronymus oder Pseudo-Columban zu Diskussionen über Fest- und Samstage beschäftigen, wie es auch das letzte Blatt der Originallage tut (L207). Abgesehen von der erneuten Möglichkeit unterschiedlicher Schreiberhände, könnte die Notwendigkeit bestanden haben, den Text durch die Ergänzung noch einmal zu erweitern. Fraglich ist dann jedoch, ob der Platzmangel nicht schon vor der Abschrift abzusehen gewesen wäre und nicht direkt ein Quaternio dafür hätte gewählt werden können.

Dass sich diese beschriebenen Blätter außerdem einmal an einer anderen Stelle in der Handschrift befunden haben könnten, ist auszuschließen, da sie sich thematisch zu sehr an die heutige Lage xxviii angliedern und sie außerdem eine inhaltliche Einheit mit dem vorherigen Blatt L207 bilden. Es könnte jedoch sein, dass L207 zuvor noch unbeschrieben war und nachträglich mit der Festtagsdiskussionen befüllt wurde, zwei Folia jedoch nicht ausreichten, weshalb noch zwei weitere Blätter hinzugefügt werden mussten. Da sich dann allerdings mit dem noch unbeschriebenen L207 einmal ein ganzes leeres Blatt am Ende der Lage xxviii befunden haben müsste, ist diese Theorie sehr unwahrscheinlich.

Der Grund für die Teilung des laut Lagenformel ursprünglich separaten Doppelblattes, um als zwei Einzelblätter am Ende der Lage xxviii angefügt zu werden, verwundert zusätzlich. Es könnte sein, dass beide Blätter lokal separiert voneinander beschrieben worden sind, bevor sie an die inhaltlich passende Lage angehängt wurden. Der Nachtrag musste eventuell zeitlich schnell fertiggestellt werden, weshalb eine Arbeitsteilung für drei Einzelblätter gewählt wurde. Hierfür mangelt es aber erneut an Schreiberhandinformationen.

Abb. 8 Lage xxx

Bei Lage xxx dagegen ergibt sich anhand der Inhaltsbeschriftung in der Strukturvisualisierung eine naheliegende inhaltliche Begründung. Es handelt sich dabei um die Ergänzungen zu den Zeitrechnungen von Bischof Isidor sowie um eine Urkundenabschrift, die inhaltlich abgegrenzte, unterschiedliche Einschübe darstellen. Sie sind in ihrer Natur bereits als Nachträge zu werten, weshalb sich ihre Addition in der Lage inhaltlich erklärt.

Fazit

Alles in allem lässt sich sagen, dass sich die Lagenstruktur von Cod. 83-II mithilfe der Lagenformel in Verbindung mit der Handschriftenbeschreibung und dem Bilddigitalisat gut in dem leicht zu bedienenden VCEditor von VISCOLL verbildlichen ließ. Für mich ist der Editor ein empfehlenswertes Instrument mit einem so großen wie praktischen Funktionsumfang, dass sich die Anwendung hervorragend für die Modellierung und Präsentation von Lagenstrukturen eignet. Dank ihm konnte ich die Strukturvisualisierung beispielsweise mit inhaltlichen Begriffen anreichern, sodass sich nicht nur eine optische, sondern auch eine inhaltliche Übersicht beschreiben ließ, um diese näher zu untersuchen. 

Die Arbeit mit dem VCEditor war daher essenziell, um die inhaltliche Struktur der Handschrift verstehen, ihre Konzeption entdecken und ihren Auffälligkeiten nachgehen zu können. Sie konnte mir als Novizin außerdem als Stütze für die zahlreichen Überlegungen auf der Spurensuche dienen, sodass mir der Arbeitsprozess nicht nur erleichtert wurde, sondern ich ihn auch besser reflektieren konnte. 

Dadurch wurden einige Besonderheiten des Lagenaufbaus deutlich, die jedoch nicht immer mit inhaltlichen Aspekten erklärt werden konnten. In einigen Fällen half dabei die im Verlauf entdeckte Einteilung der Handschrift in ihre inhaltlichen Lagenblöcke, die einen Aufschluss darauf geben konnte, warum welche Lagen mit wie vielen Blättern gestaltet und wie sie im Voraus geplant wurden. Es waren also vielseitige Entdeckungen darüber möglich, wie Handschriften an der Wende vom 8. zum 9. Jahrhundert konzipiert und ihre Lagen strukturiert wurden.

Die Visualisierung mit dem VCEditor könnte darüber hinaus zum Ausgangspunkt vieler weiterer Untersuchungen oder Modellierungen werden. Beispielsweise ließen sich die herausgearbeiteten Inhaltsblöcke samt ihren dazugehörigen Lagen und Kapiteln einmal übersichtlich präsentieren. Eventuell könnte das in der Form geschehen, die Jana Klinger für Cod. 83-II gewählt hat.

Abb. 9 Visualisierung der Inhaltsblöcke von Cod. 83-II von Jana Klinger

Eine solche Visualisierung in Verbindung mit den Erkenntnissen aus der VISCOLL-Modellierung könnte weitere Entdeckungen und Aufschlüsse ermöglichen. Dem einmal näher nachzugehen, stelle ich mir spannend vor, da die inhaltliche Einteilung in meiner Untersuchung in ein paar der besonderen Fälle für mehr Klarheit sorgen konnte.

Einige Befunde blieben trotzdem rätselhaft. Aufgrund von fehlenden Beschreibungen und Informationen besonders zu den Wechseln von Schreiberhänden und in Ermangelung spezifischer Kompetenzen ließen sich ihre Ursachen lediglich diskutieren und Vermutungen zu ihnen aufstellen. Abschließend klären ließen sie sich jedoch nicht – es bleibt für mich ein kodikologisches Rätsel, das darauf wartet, gelöst zu werden.

Verwendete Quellen und Literatur

Digital Humanities in der ewigen Stadt

Mein Praktikum am Deutschen Historischen Institut Rom

Jana Klinger

Diesen Sommer habe ich ein sechswöchiges Praktikum in der Digital Humanities-Abteilung des Deutschen Historischen Instituts Rom (DHI Rom) absolviert. Dort erhielt ich Einblicke in den Arbeitsalltag am DHI im Allgemeinen und der Digital Humanitites-Abteilung im Besonderen. Finanziell wurde mein Praktikum durch den DAAD im Rahmen eines Kurzstipendiums unterstützt.

Bei meiner Ankunft wurde ich am DHI sehr freundlich in Empfang genommen. Zunächst wurden mir von der Verwaltung die Schlüssel für mein Zimmer ausgehändigt. Da es am DHI Rom ein Gästehaus gibt, in dem Räume für Stipendiat:innen und Praktikant:innen zur Verfügung stehen, entfiel im Vorfeld die Suche nach einer Unterkunft. Während des Praktikums war es dann sehr angenehm direkt neben dem Institut mit den anderen Praktikant:innen und Stipendiat:innen zusammen zu wohnen.

An meinem ersten Tag hatte ich einen Termin mit Jörg Hörnschemeyer, meinem Praktikumsbetreuer aus der Digital Humanities-Abteilung am DHI Rom. In einem ersten Gespräch haben wir uns über die Geschichte des DHI, die Digital Humanities-Projekte am DHI Rom, sowie über meine eigenen Forschungsinteressen und Studienschwerpunkte ausgetauscht. Auf dieser Grundlage hat Herr Hörnschemeyer mir die Aufgabe gegeben, die mich die nächsten Wochen begleitet hat: Die Weiterentwicklung eines Prototyps der Visualisierung von Geodaten zur Präsenz deutscher Einheiten in Italien 1943-1945.

Das Projekt: Visualisierung von Geodaten mit Javascript

Die Datenbank, auf der die Visualisierung basieren sollte, wurde zwischen 2000 und 2004 von Carlo Gentile im Auftrag des DHI erarbeitet und wird von Historiker:innen regelmäßig zu Forschungszwecken konsultiert. Da das Interface und das dahinterliegende Backend inzwischen etwa 20 Jahre alt und somit etwas in die Jahre gekommen sind, ist eine Neuauflage dieser Datenbank in Form einer Visualisierung der Geodaten geplant. Donata Gerhards hatte im Rahmen ihres Praxisprojektes im Masterstudiengang “Digitale Methodik in den Geistes- und Kulturwissenschaften (M.A.)” der Johannes Gutenberg-Universität Mainz am DHI Rom schon einen ersten Prototypen erstellt, der auf der Javascript-Bibliothek OpenLayers und dem Datenstandard KML[1] basiert. Im Zuge dessen hatte sie auch die Daten aus Carlo Gentiles Datenbank mit Geodaten angereichert.

Mit den von Frau Gerhards angereicherten Daten und dem Prototypen als Orientierungshilfe sollte ich nun eine Visualisierung entwickeln, die auf der Javascript-Bibliothek Leaflet basiert. Leaflet ist „designed with simplicity, performance and usability in mind.“[2] Da ich bislang wenig Erfahrung in der Arbeit mit Javascript hatte, schien die Arbeit mit dieser Bibliothek eine gute Wahl um einen ersten Eindruck von der Funktionsweise dieser Programmiersprache zu bekommen. Die ersten Tage meines Praktikums verbrachte ich damit mich in die Welt von Leaflet einzuarbeiten, indem ich die Tutorials von Leaflet bearbeitete, mich in die Dokumentation einlas und überlegte, wie ich das Gelernte für die Erarbeitung einer Visualisierung der vorliegenden Daten nutzbar machen kann.

Zuerst habe ich den Rahmen der Visualisierung erstellt. Dazu zählten für mich zunächst ein Header und eine Karte, die die gesamte Seite ausfüllt (siehe Abb. 1). Für den Header habe ich auf Bootstrap 5 als Framework zurückgegriffen und die Karte mit Hilfe eines, dank Leaflet sehr kurzen, Javascripts eingebunden.[3] Im Anschluss habe ich mich daran gemacht, die Seite mit Inhalten zu füllen. Dabei stieß ich jedoch schnell an Grenzen, da ich merkte, dass die bisherige Datengrundlage in Form von KML sich nicht gut mit Leaflet verträgt. Bei der Programmierung der Webanwendung mit Leaflet war das JSON-Format die bessere Wahl. Bei der Arbeit mit Geodaten bietet sich ferner die Spezifikation GeoJSON an, um Daten mit Javascript zu verarbeiten.

Abb. 1: Die Grundlage der Visualisierung besteht aus einem Header und der Karte, die klar im Zentrum steht.

Mit dem Ziel vor Augen, die Visualisierung mit möglichst geringem Aufwand zu realisieren, sobald mir die Daten im richtigen Format vorliegen, habe ich ein XSLT-Skript erstellt, mit dessen Hilfe ich die Daten in GeoJSON transformieren konnte. Und tatsächlich: Die GeoJSON-Daten ließen sich ohne großen Aufwand in Form von Markern auf der Karte in meiner Webanwendung darstellen! Jedoch kam sofort sas nächste Problem auf: Sobald ich nicht ALLE in der GeoJSON-Datei enthaltenen Daten gleichzeitig abbilden wollte, stieß ich an Grenzen. Denn Datensätze innerhalb eines JSON-Dokuments lassen sich nicht mit Javascript abfragen, wie dies zum Beispiel bei einem XML-Dokument und einem XPath-Ausdruck möglich ist.

Die Lösung für dieses Problem fand ich in dem eBook Introduction to Web Mapping von Michael Dorman. Dank seiner Tutorials zu Leaflet und der Arbeit mit GeoJSON fand ich heraus, dass ich durch das Laden der GeoJSON-Daten in eine per SQL API abfragbare Datenbank mein Problem würde lösen können. Der Anhang von Michael Dormans eBook beinhaltet eine auf den ersten Blick recht komplizierte und auf mich zunächst einschüchternd wirkende Anleitung mit dem Titel Setting up an SQL API. Nach einigen weiteren erfolglosen Versuchen doch irgendwie ohne SQL API bestimmte Datensätze aus der GeoJSON-Datei herauszufiltern, entschloss ich mich schließlich dazu, einen Versuch zu unternehmen eine SQL API einzurichten. Dormans Disclaimer zu Beginn seiner Anleitung habe ich mir dabei stets vor Augen gehalten:

These instructions are more advanced than the material given in the main part of the book. If you are not familiar with the software components being used, be prepared for some amount of trial and error, which is part of the learning process.[4]

Es hat nichts auf Anhieb funktioniert und ich habe nicht alles zu 100% so umgesetzt, wie in Dormans Anleitung vorgegeben war, da ich erstmal alles nur bei mir lokal auf dem Rechner ans Laufen bringen wollte und daher nicht auf einen Cloud Service zurückgegriffen habe. (Das erste Kapitel der Anleitung direkt zu überspringen hat sich falsch angefühlt, aber am Ende hat es trotzdem funktioniert!). Aber nach „some amount of trial and error, which is part of the learning process“ hatte ich eine funktionierende SQL API, mit deren Hilfe ich in meinem Projekt weiterarbeiten konnte. Durch Nutzung der SQL API war ich nun in der Lage in meinem Javascript mittels SQL-Abfragen spezifische Teile der Daten liefern und auf der Karte anzeigen zu lassen (z.B. alle Orte an denen eine bestimmte Einheit zwischen 1943 und 1945 stationiert war oder alle Einheiten der Gattung „Luftwaffe“, siehe Abb. 2).

Abb. 2: Hier werden nur Marker angezeigt, die die Position von Einheiten der Gattung ‘Luftwaffe’ markieren.

Nachdem die größte technische Hürde genommen war, konnte ich dann recht unkompliziert mit Hilfe der Tutorials in Dormans eBook (besonders durch die Kapitel über Non-Spatial Queries und Spatial Queries) sowie das GeoJSON Tutorial von Leaflet Marker mit nach Einheiten spezifizierten Stilen setzen und Pop-Ups erstellen, die beim Klick auf einen Marker erscheinen und weitere Informationen geben (siehe Abb. 3). Features wie Menüs in der Sidebar in Kombination mit funktionalen Checkboxen konnte ich ebenfalls aus den Daten generieren lassen, sodass beim Anklicken einer Box in der Liste von Gattungen und Einheiten die entsprechenden Marker auf der Karte erscheinen. Sogar einen ersten Prototypen einer Umkreissuche konnte ich ohne großen Aufwand implementieren (siehe Abb. 4).

Abb. 3: So sehen die Pop-Ups aus, die nach Klick auf einen Marker weitere Informationen zu der an dem markierten Ort stationierten Einheit liefern.
Abb. 4: Um eine Umkreissuche durchzuführen, muss im Dropdown-Menü in der linken unteren Ecke der Karte die gewünschte Kilometerzahl ausgewählt werden. Beim Klick auf die Karte wird die angeklickte Stelle durch einen blauen Marker markiert und die Marker aus dem gewählten Umkreis erscheinen auf der Karte.

Das Drumherum: Meine Zeit in Rom

Am DHI habe ich mir mit zwei anderen Praktikant:innen ein Büro geteilt. Im Rahmen eines Praktikums am DHI Rom ist eine Arbeitszeit von vier Stunden am Tag vorgesehen. So bleibt neben dem eigentlichen Praktikum genügend Zeit für eigene Forschungsprojekte und Entdeckungstouren durch Rom. Unser Alltag sah meist so aus, dass wir bis zum Mittag zunächst die Arbeit für das Praktikum erledigten und uns danach noch einige Stunden eigenen Aufgaben widmeten. Hierbei konnten wir z.B. auf die Literatur in der sehr gut ausgestatteten Bibliothek des DHI Rom zurückgreifen.

Nachmittags und abends sind wir dann regelmäßig gemeinsam ins centro storico gefahren. So haben wir zum Beispiel zusammen die Galleria Borghese besucht und dort Berninis Statuen bewundert oder sind an Ferragosto über die Via Appia aus Rom herausspaziert. Darüber hinaus war das Essen in Rom ein besonderes Highlight. Während meiner sechs Wochen in Rom habe ich unglaubliche Mengen an Pizza und Pasta verzehrt und trotz meiner Aversion gegen das Kochen habe ich mir fest vorgenommen bei der nächsten Gelegenheit für meine Wuppertaler WG Spaghetti cacio e pepe zuzubereiten.

Impression von unserem Ausflug zur Via Appia.

Fazit

Die sechs Wochen am DHI haben mir großen Spaß gemacht. Die Arbeit an dem hier vorgestellten Projekt war spannend und ich konnte meine technischen Kompetenzen in Bereichen ausbauen, die z.B. auch für meine anstehende Master-Thesis nützlich sein werden. Bei Fragen und Problemen konnte ich mich jederzeit an meinen Praktikumsbetreuer, Jörg Hörnschemeyer, wenden. Gleichzeitig hatte ich die Freiheit, selbstständig an dem Projekt zu arbeiten. Auch abseits der Arbeit hatte ich eine sehr schöne Zeit in Rom. Durch die gemeinsame Unterkunft im Gästehaus des DHI sowie das gemeinsame Büro habe ich schnell engen Kontakt zu den anderen beiden Praktikant:innen geknüpft, was uns die Möglichkeit eröffnete, spontan gemeinsame Unternehmungen zu machen. Insgesamt kann ich am Ende des Praktikums auf eine tolle und lehrreiche Zeit zurückblicken. Ich freue mich sehr, dass ich die Chance hatte, in der Digital Humanitites-Abteilung des DHI Rom ein Praktikum zu absolvieren und kann daher allen Studierenden mit Interesse an Geschichte und Digital Humanities nur empfehlen, sich ebenfalls dort auf ein Praktikum zu bewerben.

[1] KML ist die Abkürzung für “Keyhole Markup Language”. Dabei handelt es sich um einen XML-basierten Standard für die Beschreibung von Geodaten. Die Dokumentation kann hier eingesehen werden: https://www.ogc.org/standards/kml. Zuletzt abgerufen am 12.09.2022.

[2] Leaflet: https://leafletjs.com. Zuletzt abgerufen am 01.09.2022.

[3] Siehe: Leaflet Quick Start Guide. https://leafletjs.com/examples/quick-start/. Zuletzt abgerufen am 01.09.2022.

[4] Dorman, Michael. Introduction to Web Mapping. Kapitel H.1 Setting up an SQL API, Introduction. Zuletzt aktualisiert am 11.07.2022. https://geobgu.xyz/web-mapping2/setting-up-an-sql-api.html#introduction-12. Zuletzt abgerufen am 01.09.2022.