Visualisierung

06/12/202203/02/2023

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 ¹⁺⁸⁺¹, 2 ⁴, 3-4 ⁸, 5 ⁶, 6-7 ⁸, 8 ⁶, 9 ⁸, 10 ^6-3, 11-19 ⁸, 20 ⁴, 21-23 ⁸, 24 ^4-2, 25-27 ⁸, 28 ⁶⁺², 29 ⁸, 30 ⁶⁺²“ (van Euw 1998),

während im Anderson-Katalog Folgendes steht:

[7], i ¹⁺⁸⁺¹, ii ⁴, iii-iv ⁸, v ⁶, vi-vii ⁸, viii ⁶, ix ⁸, x ^6-3, xi-xix ⁸, xx ⁴, xxi-xxiii ⁸, xxiv ^4-2, xxv-xxvii ⁸, xxviii ⁶⁺²(signature on 6th, two singles at end were previously a separate bifolium), xxix ⁸, xxx ⁶⁺² (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.

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 i beginnenden fortlaufenden römischen Ziffern versehen, die in der folgenden Diskussion Verwendung finden sollen.

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 i 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 i 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 i 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 (1r–14v, Lage 1–2) behandelt den chronistischen Teil der Handschrift. Block II (15r–36v, Lage 3–5) dagegen umfasst Kapitel zur Mathematik, Zeitrechnung und Astronomie, während sich Block III (37r–44v, Lage 6) mit dem Mondzyklus beschäftigt. Daran schließt sich der vierte inhaltliche Abschnitt an (45r–58v, Lage 7–8), welcher der Lehre der Zeitrechnung gewidmet ist. Es folgen Block V (59r–69v, Lage 9–10) mit Vorschriften sowie Block VI (70r–85v, Lage 11–12) mit Berechnungstabellen, Kalendern und „Rechenrädern“.

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

Der siebte inhaltliche Block (86r–125v, 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 (126r–145v, Lage 18–20). Thematisch knüpft Block IX (146r–171v, Lage 21–24) über Himmelserscheinungen daran an. Außerdem ist ein zehnter Inhaltsabschnitt (172r–187v, 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.

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.

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

Anderson, Diane Warne/Black, Jonathan: „Köln, Dombibliothek Hs. 83-II“. In: Diane Warne Anderson (Hg.): The Medieval Manuscripts of the Cologne Cathedral Library 1. Manuscripts 1–100. Collegeville (Minnesota) 1997. Online-Version: https://digital.dombibliothek-koeln.de/hs/content/description/334039.

Handschriften der Diözesan- und Dombibliothek: „Kompendium der Zeitrechnung, Naturlehre und Himmelskunde (Köln, Erzbischöfliche Diözesan- und Dombibliothek, Cod. 83-II)“. Online-Digitalisat: https://i3f.vls.io/?collection=i3fddbk&id=https://digital.dombibliothek-koeln.de/hs/i3f/v20/168520/manifest&toc=false&view=gallery.

van Euw, Anton: „Kompendium der Zeitrechnung, Naturlehre und Himmelskunde, Köln, 798 und 805“. In: Glaube und Wissen im Mittelalter. Katalogbuch zur Ausstellung. München 1998, S. 136–156. Online-Version: https://digital.dombibliothek-koeln.de/hs/content/description/334040.

12/09/202214/09/2022

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.

08/09/202117/11/2021

Eine kleine Geschichte der Bundesrepublik Deutschland

… Kleine Datengeschichten. Kleine Visualisierungsgeschichten. Kleine Forschungsgeschichten …

Von Patrick Sahle und Jana Klinger.

Hinter allem steckt eine Geschichte. Jedes Thema ist geeignet, um historische Zusammenhänge aufzuzeigen, denn alles hat eine historische Dimension. In unserem digitalen Informations-Ökosystem sind überall Informationen und Daten. Daraus lassen sich Geschichten erzählen. “Erzählen” ist aber nicht nur gesprochene oder geschriebene Sprache, sondern kann auch verschiedenste Visualisierungen meinen. Bilder und Diagramme zeigen Zusammenhänge und erzählen Geschichte(n). Es folgt ein willkürliches Beispiel.

Wikipedia ist eine Enzyklopädie für alles. Viele Dinge in der Welt haben einen Artikel. Ähnliche Dinge haben ähnlich strukturierte Artikel. Gruppen von Dingen haben Listen dieser Dinge. Das geht oft in eine erstaunliche Detailtiefe. So haben z.B. sogar einzelne Schiffe eigene Artikel in Wikipedia. Einzelne U-Boote auch. Viele U-Boote der Bundeswehr haben einen eigenen Artikel (Beispiel: U9 ). Hinzu kommen Artikel zu Bootsklassen (Beispiel: Klasse 201) und schließlich auch eine “Liste von Unterseebooten der Bundeswehr“. Das sind Informationssammlungen, aus denen sich vielleicht eine Geschichte erzählen lässt.

Im Sommersemester 2020 (dem ersten Corona-Semester) haben wir uns an der Bergischen Universität Wuppertal im Rahmen einer Übung “Informationsvisualisierung in den Geisteswissenschaften” mit der Frage beschäftigt, wie aus Daten Diagramme werden und wie bestehende Visualisierungen kritisch untersucht und eigene Schaubilder entwickelt werden können. Grundsätzlich sollte jede/r Teilnehmer/in ein eigenes Projekt verfolgen. Die Frage nach den U-Booten nach 1945 diente dabei als Fallbeispiel, als möglicher Ausgangs- und Anknüpfungspunkt für eigene Projekte und als Angebot zur Beteiligung für alle, denen partout nichts eigenes einfallen wollte.

Am Beispiel kann man gut die allgemeinen Prozesse von (ich greife jetzt mal hoch) “data science” und “information visualization” durchspielen. Denn natürlich wollten wir nicht einfach ein Diagramm “zeichnen”, sondern dies datengestützt und algorithmisch erzeugen. Es ist wichtig zu beachten, dass unser Szenario grundsätzlich darauf ausgerichtet ist, nicht einfach aus einem gegebenen Datensatz eine Visualisierung zu entwickeln, sondern einen automatischen Prozess zu etablieren, der jederzeit neu angestoßen werden kann. Eine Veränderung der Datengrundlage würde dann automatisch zu einer Aktualisierung des Diagramms führen. In einer idealen Welt sind Datengrundlage und Analyse ganz voneinander getrennt und nur funktional verbunden (die Analyse bedient sich bei der Datengrundlage). In so einem Szenario können Visualisierungen dynamisch reagieren, Veränderungen abbilden und stets aktuell sein. Das ist ein prinzipieller, theoretischer Anspruch. Ob dieses Versprechen in der Wirklichkeit eingehalten werden kann, wird man sehen.

Die typischen Arbeitsschritte von data science und information visualization, die allerdings nicht streng sukzessive ablaufen, sondern teilweise in Schleifen verlaufen und wiederholt werden müssen, sind unter anderem …

Identifikation einer geeigneten Datenquelle
Datengewinnung
Datenbereinigung
Entwicklung einer Fragestellung
Konzeptionelle Entwicklung einer Visualisierung
Technische Entwicklung einer Visualisierung
Evaluation, Kritik, Überlegungen zu weiteren Entwicklungsmöglichkeiten

In diesem Prozess entstehen Daten und Dateien, die wir der Transparenz und Nachvollziehbarkeit halber im Repository der Digital Humanities an der Bergischen Universität Wuppertal abgelegt haben. Startpunkt dieser Dokumentation ist das gitlab-repo https://git.uni-wuppertal.de/dhsfu/uboote-brd

Die Datenquelle

Wie bereits erwähnt haben die meisten U-Boote einen eigenen Artikel. Aber nicht alle. Manche sind im Artikel zu ihrer technischen Klasse zusammengefasst. Kerninformationen laufen in einem Listenartikel zusammen. Die dort enthaltenen Tabellen zu den U-Booten sind händisch erstellt, speisen sich also nicht automatisch aus den Einzelartikeln und deshalb können die Informationen auch manchmal von diesen abweichen. Wenn wir davon ausgehen, dass der Listenartikel einigermaßen zuverlässige Daten enthält und auch in Zukunft weiter gepflegt und aktualisiert wird, dann können wir ihn trotzdem als Ausgangspunkt für die Informationsbeschaffung benutzen. Die “Liste der U-Boote” enthält zwei Tabellen, die für uns interessante Angaben enthalten, nämlich: Bezeichnung des Schiffes, Klasse, Datum der Indienststellung und Datum der Außerdienststellung.

Screenshot. Wikipedia “Liste von Unterseebooten der Bundeswehr”, Liste der außer Dienst gestellten Boote. Stand 9/21

Das sind alles relativ gut strukturierte, einheitliche Daten, mit denen man eigentlich gut arbeiten können sollte.[1] Zusätzlich gibt es ein freies textuelles Anmerkungsfeld, über dessen Nutzung wir uns später Gedanken machen können. Einzelne Angaben sind mit weiteren Wikipedia-Artikeln verlinkt, so dass in der Linkverfolgung zusätzliche Informationen erhoben werden könnten. Das betrifft hier vor allem das einzelne Boot (sofern es einen eigenen Artikel gibt) und die technische Klasse des Bootes. Über die Klasse ließen sich grundsätzlich Informationen zu Länge, Breite, Verdrängung, Besatzung, Antrieb, Bewaffnung und einiges mehr einsammeln. Über die einzelnen Bootsartikel käme man systematisch zu näheren Informationen, z.B. zu Schicksal und Verbleib. Die Bootsartikel (oder Beschreibungen der Boote in den Artikeln zur Klasse) sind aber weniger gleichmäßig strukturiert, so dass man hier nicht Detailinformationen in der ganzen Breite der Untersuchungsmenge gewinnen kann.

Datengewinnung

“Harvesting” ist das Zauberwort. Andere sagen “web scraping” dazu. Ausgehend vom Listenartikel haben wir mit einem Skript die Datentabelle ausgelesen und in gleichmäßig strukturierte Datensätze verwandelt. Grundsätzlich ist es egal, welche Technologie bzw. welche Programmiersprache man hier einsetzt. Aktuell erfreut sich in diesem Anwendungsbereich vor allem Python großer Beliebtheit. Wir haben aber XSLT den Vorzug gegeben, weil es sich bei der Zielressource um eine baumartig strukturierte Datei handelt. Eine Wikipedia-Seite ist eine HTML-Seite ist eine XHTML-Seite ist eine XML-wohlgeformte Datei. Deshalb “passt” die Logik der X-Technologien gut zu den vorliegenden Daten. Beim Harvesting unterscheide ich grundsätzlich zwischen “front door harvesting” und “back door harvesting”. Der Traum der Datenverarbeitung sind transparente, einfach zu nutzende APIs (Application Programming Interfaces), also Schnittstellen, mit denen andere Skripte mit Anwendungen kommunizieren und Daten austauschen können. Auch die Wikipedia hat selbstverständlich solche APIs, an denen ein Datenkunde seine Datenpakete an der Laderampe auf der Rückseite des Geschäfts abholen kann. Die uns interessierende Seite würde man mit

https://de.wikipedia.org/w/api.php?action=parse&format=xml&page=Liste_von_Unterseebooten_der_Bundeswehr

… bestellen und bekäme dann eine weiter verarbeitbare XML-Datei zurück. Aus verschiedenen Gründen bevorzuge ich aber manchmal das frontdoor harvesting. Ich gehe in den Laden den wir Browser nennen und sage – via https-Aufruf – nur “Gib mal die Seite X” und bekomme dann exakt das, was ich auch im Schaufenster gesehen habe. Schon in die Abfrage innerhalb einer XML-Verarbeitung durch XSLT eingebaut klingt das dann so:

doc(https://de.wikipedia.org/wiki/Liste_von_Unterseebooten_der_Bundeswehr)

Einfacher geht es nicht.

Man hat dann, wie gesagt, eine XML-Datei, die man weiter verarbeiten (Fachwort: parsen) kann. Aus der Seite werden dabei die Informationen ausgelesen, die uns interessieren. Ich spreche mal deutschen Pseudocode:

gehe zu den uns interessierenden Tabellen
für jede Tabellenzeile lege einen Datensatz an
für jede Zelle der Zeile bilde ein Element und fülle es mit den entsprechenden Angaben

Das ist das Grundgerüst und im Prinzip ganz einfach. Im Detail stecken hier so einige Teufel. Unschön sind z.B. Zellen, die über mehrere Zeilen gehen (wie bei den U-Boot-Typen). Da muss man dann ein paar ~~Umwege gehen~~ Verfeinerungen einbauen. Für diesen Fall muss man z.B. vorher abfragen, wie viele Zellen es eigentlich in der Zeile gibt und wenn es eine Zeile mit fehlender Zelle ist, an der entsprechenden Stelle abfragen, was denn in der vorhergehenden vollständigen Zeile steht. Dies ist nur ein Beispiel. Das Parsing der Ausgangsdaten muss grundsätzlich so lange verfeinert werden, bis die gewünschten Ergebnisse erreicht sind. Im Prinzip sehen die dann aber ganz einfach so aus:

<boote> <boot> <name>U 2365 - S 170 (U-Hai)</name> <klasse>XXIII</klasse> <dienstStart>15. August 1957</dienstStart> <dienstEnde>24. September 1966</dienstEnde> </boot>

Datenbereinigung

Ein großer Teil des Aufräumens passiert schon beim Harvesting. Aus Gründen werden z.B. zusätzlich Kurznamen extrahiert oder die Klassentypen direkt mit Angaben zur Länge und zur Verdrängung ergänzt. Die menschenfreundlichen Datumsangaben (“15. August 1957”) werden um eine computerfreundliche Form ergänzt (1957-08-15). Außerdem passiert hier etwas, über das man sich in methodischer Hinsicht durchaus streiten darf: Im Hinblick auf die spätere Visualisierung wird erstens der zeitliche Abstand zu einem gesetzten Zeitpunkt (hier: 1.1.1945) berechnet und dieser zweitens in eine Distanz auf einer bestimmten Skala umgerechnet. Das ist eigentlich methodisch doppelt unsauber, denn die gesammelten Daten sollten eigentlich nicht auf die Nutzung in einer Visualisierung vorausschauen und sie sollten es ganz sicher nicht im Hinblick auf deren spezifische Skaleneigenschaften tun. Wir verbuchen diese Praxis unter “quick’n’dirty”. Die Daten sehen deshalb tatsächlich nicht wie im obigen Fake, sondern so aus:

<boote> <boot> <name kurz="U 2365">U 2365 - S 170 (U-Hai)</name> <klasse laenge="35" tonnen="258">XXIII</klasse> <dienstStart distanzZu45="4609" aufSkala750="226.19" norm="1957-08-15"> 15. August 1957</dienstStart> <dienstEnde distanzZu45="7936" aufSkala750="317.28" norm="1966-09-24"> 24. September 1966</dienstEnde> </boot>

Vom Prinzip her ist das harvesting- und parsing-Skript (HarvestData.xsl) jederzeit auf die Wikipedia-Seite anwendbar und erzeugt eine perfekte Datengrundlage für die Visualisierung. In der quick’n’dirty-Praxis hat man aber nicht immer Lust, noch die letzten Säuberungsaktionen in allgemeingültige Algorithmen zu übersetzen. Der Unterschied zwischen der erzeugten Datei und einer manuell nachgesäuberten Datengrundlage zerbricht also streng genommen den vollautomatisierten Workflow. Wir wollen aber mal nicht so streng sein. Außerdem ist die endgültige Daten-Datei (UBootDaten_clean.xml) auch zu didaktischen Zwecken ein wenig “schöner” formatiert.

Entwicklung einer Fragestellung

Daten sind “allgemein”. Sie können viele Fragen beantworten. In der Theorie. In der Wirklichkeit können bestimmte Daten aber nur bestimmte Fragen beantworten und legen bestimmte Daten bestimmte Fragen nahe. Die Tabelle der U-Boote ergibt für sich genommen noch keine einfache Erzählung. Man liest, dass Boote zu bestimmten Zeitpunkten in Dienst gestellt wurden und wieder aus dem Dienst genommen wurden. Man sieht, dass es eine Abfolge verschiedener Klassen gab, die sich z.B. in ihrer Größe unterschieden und vielleicht mal weniger und mal mehr erfolgreich waren. Das hätte man gerne übersichtlicher und auf einen Blick erfassbar. Die naheliegende Fragestellung ist, wie sich der Bestand an Booten und die verschiedenen Bootstypen entwickelt haben. Vielleicht lässt sich das dann auch in Beziehung zu den großen historischen Entwicklungslinien der Nachkriegsbundesrepublik setzen.

Konzeptionelle Entwicklung einer Visualisierung

Für eine historische Visualisierung bietet sich eine Zeitachse an. Auf der könnten die Boote dargestellt werden. Hier wäre eine Einzeichnung jedes einzelnen Bootes mit seiner Dienstzeit denkbar. Wir schreiben also ein kleines Skript, das eine Grafik-Datei erzeugt:

Abb. 1: Grobe Skizze, U-Boote mit Dienstzeiten, gestapelt.

Unser XSLT-Skript schreibt eine SVG-Datei. Dabei ist unser SVG komplett individuell berechnet, greift also nicht auf bestehende Bibliotheken zurück. Dem Vorteil totaler Freiheit und Autonomie steht der Nachteil gegenüber, wirklich alles selbst bestimmen und berechnen zu müssen. Für diese Dokumentation ist außerdem zu beachten, dass SVG-Grafiken nicht in das WordPress-Blogsystem eingebunden werden können. Wir müssen deshalb hier leider mit Screenshots arbeiten. Dieselben sind aber mit den Original-SVG-Grafiken auf dem Server des Lehrstuhls verlinkt. Dort stehen dann auch alle dynamischen Funktionen, wie Zooming oder Hovern zur Verfügung. Hier ist zu betonen, dass der simple “Tooltip-Mechanismus” gerade bei dieser Art von Visualisierungen besonders wichtig ist, weil er dem unmittelbar Sichtbaren bereits eine zweite Informations- bzw. Explorationsschicht gibt. Eine dritte Schicht läge in weiter ausgebauten Infoboxen, eine vierte in der Verlinkung mit weiterführenden Ressourcen …

Abb. 2: Hover-Effekt / Tool-Tip zum dritten Boot von unten.

Der erste Entwurf einer algorithmischen Zeichnung zeigt schon einige Vor- und Nachteile dieses Ansatzes. Jedes Boot ist mit seiner Dienstzeit sehr gut zu erkennen. Durch die Verwendung von Farben für die verschiedenen Klassen wird auch die technische Entwicklung gut sichtbar. Auf die gehobenen Weltkriegsboote (braun) folgen die “scheiternden” Klassen 201 und 202 (grün) und dann die erst scheiternden, aber dann doch funktionierenden Klassen 205 und 206 (blau), die dann erst nach der Jahrtausendwende durch eine ganz neue Entwicklung (Klasse 212A, violett) abgelöst wurden. Die einzelnen Boote, den Zusammenhang der Dienstzeiten und Klassen sieht man hier sehr gut. Die sehr unterschiedliche Größe der Boote sieht man nicht. Und man kann nicht überblicken, wie viele Boote eigentlich zu welcher Zeit einsatzbereit waren. Deshalb haben wir uns entschiedenen, einen anderen Weg einzuschlagen, der einem etwas konventionelleren Ansatz folgt und letztlich die Idee des Liniendiagramms wieder aufnimmt.

Technische Entwicklung des Diagramms

Hierzu ist schon alles nebenbei gesagt: Ein XSLT-Skript nimmt unsere erstellten Daten und verwandelt sie in eine SVG-Datei. Im Kurs hatte sich gezeigt, dass SVG eine sehr einfach zu erlernende Technologie ist. Wie bei den meisten Web-Technologien bedeutet dies aber eigentlich Zweierlei. Die grundlegende Funktionsweise und erste Schritte, mit denen man schon produktiv arbeiten kann, sind sehr leicht zu lernen. Dahinter verbergen sich dann weite Möglichkeiten und die Komplexitäten einer professionellen Anwendung – die man nur allmählich und entlang eigener Projekte vertiefen kann. Unser SVG ist damit ein weitgehend “unprofessionelles” SVG – aber letztlich zählt nur das Ergebnis. Im Kurs haben viele Studierende SVG “von Hand” geschrieben, XSLT haben nur die eingesetzt, die diese Sprache schon vorher kannten oder sich selbst beigebracht haben. Bei SVG habe ich allerdings Wert darauf gelegt, dass keine Programme wie InkScape oder Adobe Illustrator eingesetzt werden. Beide erleichtern zwar als WYSIWYG-Editoren das Zeichen, hinterlassen aber keinen menschenlesbaren Code, so dass ein tieferes Verständnis der Logik und Funktionsweise von SVG eher erschwert wird.

Unser Ergebnis

Diagramme sind fast nie “perfekt”. Eigentlich gibt es immer etwas zu verbessern, zu ergänzen, zu diskutieren oder zu revidieren. Das folgende Diagramm markiert deshalb eher nur einen stabilisierten Diskussionstand, allerdings nach bereits dutzenden Iterationen und Veränderungen.

Abb. 3: U-Boote der BRD, Bestand an im Dienst befindlichen Booten.

Nun sieht man sehr gut die Entwicklung des Bestandes, denn die verbindende Linie bildet die Summe der Boote im Dienst ab. Bei jeder Indienststellung (ausgefüllter Kreis) steigt der Bestand, bei jeder Außerdienststellung (leerer Kreis) sinkt er. Werden zeitgleich mehrere Boote in Dienst oder außer Dienst gestellt, kommt es zu entsprechenden Sprüngen. Für eine genauere individuelle Betrachtung der Boote gibt es wiederum Tool Tips.

Abb. 4: Tool Tipp zu einzelnen oder mehreren Booten.

Nachteilig an dieser Lösung sind Zeiträume schnellen Indienst- und Außerdienststellens wie in den späten 1960er Jahren, weil hier der Blick in die Details erschwert wird. Allerdings kann man in SVG natürlich beliebig hineinzoomen, um genauer hinzuschauen. Und es bleibt eine valide Aussage: Hier passiert viel. Die Grafik verwendet ähnliche Farben, um die Klassen zu unterscheiden. Außerdem wird die Größe der Kreise variiert um die Unterschiede zwischen Kleinst-U-Booten, den die meiste Zeit üblichen kleinen Booten und den jetzt wieder größeren Booten sichtbar zu machen.

Überlegungen zur Farbgebung erfordern eigentlich einen gesonderten Bericht, denn auch mit Farben wird erzählt. Nähe und Distanz von Farben sind hier z.B. sehr bewusst danach gewählt, wie Klassen wiederum Gruppen bilden und wie stark sie sich voneinander unterscheiden. Außerdem wird hier natürlich der fundamentale Unterschied zwischen den “alten” (zunächst versenkten und später wieder gehobenen) Weltkriegsbooten und den technischen Neuansätzen deutlich gemacht. Fragen der Farbgebung und einer möglichst “schönen” Legende waren im Kurs eine gesonderte Aufgabe, die hier von Elia Hildebrand gelöst worden ist, dem insofern die entsprechenden Credits zustehen. Jana Klinger hat an vielen Stellen an der SVG-Umsetzung mitgearbeitet. Ann-Kathrin Haustein hat bei der Erfassung und Berechnung von Daten geholfen, die nicht automatisch ausgelesen wurden.

Die Daten kommen aus der Wikipedia. Sie sind halbautomatisch in eine Visualisierung überführt worden. Was liegt näher, als das Diagramm wieder im Wikipedia-Artikel einzufügen, dessen Zahlen hier veranschaulicht werden? In einer idealen Welt würde sich die Visualisierung automatisch aus sich ändernden Daten speisen und selbst aktualisieren. Eine solche Dynamisierung wird allerdings auf absehbare Zeit nicht möglich sein, weil verschiedene technische Restriktionen eine vollständige Automatisierung verhindern. Tatsächlich war es noch nicht einmal einfach, das Diagramm überhaupt in den Wikipedia-Artikel einzubringen.[2]

Verfeinerungen und Erweiterungen?

Was bleibt zu tun, was kann noch besser gemacht werden? Bei Diagrammen geht es auch um Ästhetik und Design. Hier ist wahrscheinlich noch Luft nach oben. Wieso sehen z.B. die Skalen und Skalenbeschriftungen für mich noch nicht perfekt aus? Grundsätzlich können auch immer noch mehr Informationen in eine Grafik eingefügt und noch mehr Details gegeben werden. Die Tool Tipps könnten zu echten Infoboxen ausgebaut werden. Die Hover-Funktion könnte auch weitere Informationsschichten z.B. für die Geschichte der einzelnen Boote sichtbar machen.

Abb. 5: Vollständiger Zeitstrahl für U 2540.

In dieser Diagrammform wäre die Visualisierung aller vollständigen Einzelgeschichten schwierig, weil ja nicht jedes Boot einen eigenen “Platz” in der vertikalen Anordnung hat. Wir haben deshalb alle Schicksale wiederum in den ersten (gestapelten) Entwurf integriert und dort zusätzlich einen Schalter eingebaut, der diese Informationsschicht “togglet” also sichtbar und unsichtbar schaltet. Technisch erweitert sich das Arsenal der Mittel zur Diagrammerstellung um eine minimale Menge Javascript. Inhaltlich ergibt sich eine neue Tiefendimension und eine Zusammenschau der Geschichten vor und nach den eigentlichen Dienstzeiten. Auch hier ist wieder eine differenzierende Farb- und Formensprache zu finden. Hellgrün sind hier andere Verwendungszeiträume, Grau sind “Latenzzeiten” (durchgezogene Linien für Bauzeiten und “in Abwrackung”; gestrichelte Linien für “bestellt” oder “noch nicht in Anschlussverwendung), Gelb sind passive Verwendungen (z.B. als Ersatzteilspender), Rot sind Verwendungen als Museumsboot. Sichtbar wird jetzt einerseits, dass die unterschiedlichen Bau- und Indienststellungszeitpunkte eher zufällig sind und auf blockweise Bestellvorgänge zurückgehen,[3] dass manchmal früher geplante Boote erst später in Dienst gestellt werden konnten, und wo Boote ein Nachleben als Museumsboote oder sogar im aktiven Dienst anderer Länder gefunden haben.

Abb. 6: U-Boote nach Dienstzeiten gestapelt mit Zusammenschau der Gesamtgeschichten.

Der Phantasie für noch mehr Information, mehr Dynamik und mehr Interaktion sind insgesamt kaum Grenzen gesetzt. Mit JavaScript-Schalthebeln wie dem eben ansatzweise eingeführten könnten Informationsschichten noch weiter gefiltert oder Diagramme angereichert werden. Aber bis zu welchem Punkt ist das sinnvoll? Und wie lange stehen Aufwand und Nutzen noch in einem guten Verhältnis?

Visualisierung als Reduktion

Visualisierungen dienen auch dazu, Informationen zu reduzieren und Geschichten auf den Punkt zu bringen. In diesem Sinne sind wir vielleicht schon zu weit gegangen? Im Prinzip des “overview and detail” haben wir zwar schon einen Überblick über die Entwicklung der deutschen Rüstung am Beispiel der U-Boote und zugleich die Möglichkeit, sich die einzelnen Boote im Detail anzusehen, aber vielleicht liegt eine gute “Geschichte” in der deutlichen Vereinfachung. Denn worum geht es hier: Die U-Boote der Bundesmarine zeigen plastisch die Geschichte der Bundesrepublik zwischen Kriegsende, Wiederbewaffnung, Kaltem Krieg, Wiedervereinigung, Friedensdividende und politischer Neuausrichtung (?).

Abb. 7: eine kleine Geschichte der BRD in Schlagwörtern

Diagramme als Bilder sprechen nicht nur die Sprache der Statistik, sondern auch im Rahmen der Bildsprache. Gegen die Richtschnur des linearen Sprechens und der linearen Zeichenketten steht hier die Topografie der Zweidimensionalität im Vordergrund. Dies ernstgenommen, kommt es zu einer eigenen Ausdrucksweise und zu einer anderen “Ästhetik”, die man für gelungen oder misslungen, für besser oder schlechter lesbar, für ausdrucksstärker oder unverständlich halten mag:

Abb. 8: Eine kleine Geschichte in Schlagwörtern – als Bildkunst?

Fußnoten

[1] Im Arbeitsprozess können jedoch vereinzelt auch Unstimmigkeiten auftreten. So zum Beispiel beim Datum der Außerdienststellung der U-Boote U13 und U14. Hier ist in dem Listenartikel vom 23.09.1997 die Rede. In den Einzelartikeln dagegen vom 26.03.1997. Der Artikel zur Klasse der Boote gibt als Datum ebenfalls den 26.03.1997 an. Wie geht man nun mit diesen widersprüchlichen Angaben um? Zunächst sollte geprüft werden, ob eine der Angaben mit externen Belegen versehen ist. Dies ist bei diesem Beispiel jedoch auf keiner der drei Seiten (Gesamtliste, Klasse, Einzelartikel) der Fall.
In einem nächsten Schritt lohnt es sich, die Versionsgeschichten der Artikel genauer anzusehen. So lässt sich prüfen, ob in einem der Artikel zu einem bestimmten Zeitpunkt (möglicherweise unter Angaben von Gründen) das Datum der Außerdienststellung vom 23.09. zum 26.03. geändert wurde (oder umgekehrt). Die Versionsgeschichten der Einzelartikel zu den U-Booten U13 und U14 verraten, dass beide Artikel am 22. Dezember 2016 erstellt wurden und von Beginn an als Datum der Außerdienststellung den 26.03.1997 nennen.
In der ersten Version des Listenartikels der U-Boote (vom 20. August 2004) wird für U13 und U14 noch kein Datum der Außerdienststellung angegeben. Dies wurde jedoch schon wenige Tage später, am 23. August 2004, nachgeholt. Hier wird der 23.09.1997 als Datum der Außerdienststellung genannt, wie es auch in der aktuellen Version des Artikels noch der Fall ist.
Ein Blick in die Versionsgeschichte des Klassenartikels verrät, dass dieser Artikel am 5. August 2004 erstellt wurde, und damit ähnlich alt ist wie der Listenartikel. Schon in der ersten Version des Artikels ist zu den U-Booten U13 und U14 ein Datum der Außerdienststellung angegeben: der 23.09.1997. Und jetzt wird es interessant! Denn in der aktuellsten Version dieses Artikels wird als Datum der Außerdienststellung der 26.03.1997 genannt. Es muss also irgendwo in der Versionsgeschichte des Artikels zur U-Boot-Klasse 206 der Zeitpunkt zu finden sein, an dem das Datum der Außerdienststellung vom 23.09. zum 26.03. geändert wurde.
Tatsächlich lässt sich dieser Punkt auf die Zeit vom 3.-5. Juni 2010 festsetzen. In der betreffenden Woche ist in dem Artikel viel passiert, da verkündet wurde, dass diejenigen U-Boote der Klasse 206A, die sich noch im Dienst befanden, mit sofortiger Wirkung außer Fahrbereitschaft genommen und in Kürze außer Dienst gestellt werden würden. Die Tabelle mit den Informationen zu den U-Booten der Klasse 206(A) wurde daraufhin in wenigen Tagen von verschiedenen Benutzer:innen bearbeitet und aktualisiert, wobei zwischenzeitlich auch das Datum der Außerdienststellung der U-Boote U13 und U14 fälschlicherweise zum Juni 2010 geändert wurde. Dieser Fehler wurde kurz darauf wieder korrigiert, jedoch wurde dann nicht, wie zuvor, der 23.09.1997 als Datum der Außerdienststellung eingetragen, sondern stattdessen der 26.03.1997.
Es liegt also der Verdacht nahe, dass in dem Anfang Juni 2010 im Artikel zur U-Boot-Klasse 206 herrschenden Chaos, versehentlich das Datum der Außerdienststellung vom 23.09.1997 zum 26.03.1997 geändert wurde. Dieser Verdacht wird noch dadurch erhärtet, dass die Person, die im Klassen-Artikel das Datum der Außerdienststellung zum 26.03.1997 änderte, eine halbe Stunde später auch den Listenartikel bearbeitet hat, ohne hier jedoch das Datum der Außerdienststellung ebenfalls vom 23.09.1997 zum 26.03.1997 zu ändern.
Letztendlich bleibt es also bei der begründeten Vermutung, dass es sich beim 23.09.1997 um die verlässlichere (weil früher angegebene und nur unter fadenscheinigen Umständen geänderte) Angabe handelt.

[2] Bilder für die Wikipedia sollten zunächst bei wikimedia commons hochgeladen und mit Informationen zum Bild und zu seiner Lizenz versehen werden. Das ist im Prinzip unproblematisch, das Ergebnis sieht man hier: https://commons.wikimedia.org/wiki/File:UBoote_BRD_v1.svg. Die Schwierigkeiten liegen darin, dass man nicht einfach jede Art von SVG-Grafik (sinnvoll) hochladen kann. Aus Sicherheitsgründen sollte z.B. kein Javascript-Code enthalten sein. Die größte Hürde stellt aber der Konverter von wikimedia dar, der aus einem SVG-File eine Rastergrafik (für SVG typischerweise dann PNG) erstellt weil in den Wikipedia-Artikel SVG-Bilder in der Regel nicht unmittelbar und nativ, sondern stattdessen ein Vorschaubild angezeigt werden sollen. Das Konversionsskript hat leider seine Eigenheiten: es verweigert z.B. die Verarbeitung von circle-Elementen (Kreise) ohne unmittelbare (sondern in die CSS-Angaben ausgelagerte) Radius-Angaben und ist insgesamt sehr empfindlich, was die Verletzung von XML-Wohlgeformtheit oder -Validität betrifft. Das ist im Prinzip verständlich, macht damit aber einen großen Unterschied zur Praxis der gängigen Browser, die solche SVG-Dateien klaglos und korrekt anzeigen. Unverständlich ist, dass der Konverter eine den Browsern diametral entgegengesetzte Politik verfolgt, was die Verwendung des Attributs href im Code betrifft. Während die Verwendung von “xlink:href” vom W3C inzwischen als “deprecated” deklariert ist, verlangt die Wikipedia die veraltete Methode inklusive Deklaration des Namensraumes. Ähnlich eigenwillig verhält es sich mit den Schriftarten in SVG-Grafiken. Hier will der Konverter nur solche zulassen, die allgemein auf den Wikimedia-Servern installiert sind. Und das sind – gelinde gesagt – “exotische” Fonts. Zwar gibt es Ersatzschriften für Arial oder Times New Roman, aber kein SVG-Designer würde wohl auf die Idee kommen, seine Schriften initial nach der Font-Liste der Wikimedia auszuwählen. Im Ergebnis ist die Situation im Jahr 2021 deshalb trotz des rührigen internen “Wikiprojekt SVG” so, dass selbst “einfache” und “saubere” SVG-Grafiken nochmals erheblich überarbeitet werden müssen, bevor sie in der Wikipedia eingebunden werden können. Wir haben in diesem Prozess sehr viel recherchieren und lernen müssen und viele dutzend Male das SVGCheck-Tool bemühen müssen, bis alles nach dem Geschmack des Konverters war.

[3] Es ist uns nicht gelungen, den Bestellzeitpunkt für die Boote der Klasse 206 und einige der Klasse 212A zu ermitteln. Wikipedia macht hierzu keine Angaben und auch in den ansonsten leicht zu recherchierenden Parlamentsprotokollen findet man diese Information nicht. Wir freuen uns über entsprechende Hinweise.

05/03/202121/02/2023

Frankfurter Postzeitung 1615-1619. Zum Korrespondenzsystem.

… Kleine Datengeschichten. Kleine Visualisierungsgeschichten. Kleine Forschungsgeschichten …

Von Patrick Sahle

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

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

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

1615

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

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

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

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

1616

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

1617

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

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

1618

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

1619

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

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

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

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

Schluss

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

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

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

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