Lernstücke – DH@BUW

31/10/202202/11/2022

Ordnung schaffen in den Handschriften der Wikipedia

Rebecca Fritz, Studentin an der Bergischen Universität Wuppertal

Im Sommersemester 2022 habe ich die Veranstaltung „Kodikologie und Paläografie“ von Prof. Dr. Sahle im Rahmen meines Geschichtsstudiums belegt. In Form einer schriftlichen Ausarbeitung habe ich mich mit den Zuordnungen der Handschriften auf Wikipedia, speziell mit der Zuordnung nach Jahrhunderten, beschäftigt. Das Ziel meiner Arbeit war es, dass in der Kategorie Handschriften mehr Einträge zum 4. bis 16. Jahrhundert zu finden sind.

Nach dem ich mir ein Konto angelegt, mich mit den Funktionen, insbesondere mit dem Anlegen von Kategorien beschäftigt und mir einen groben Überblick über die vorhandene Kategorie „Handschriften“ verschafft hatte, konnte ich mit meiner eigentlichen Arbeit beginnen. Zunächst habe ich die fehlenden Kategorien zum 4. bis 16. Jahrhundert angelegt. Anschließend bin ich systematisch die bereits vorhandenen Kategorien durchgegangen und habe die einzelnen Handschriftenartikel aus diesen Kategorien den entsprechenden Jahrhunderten zugeordnet. Nach Durchsicht der Kategorien habe ich in der Volltextsuche ebenfalls nach Handschriften gesucht. Handschriften, die nicht eindeutig einem Jahrhundert zuzuordnen waren, habe ich beiden Jahrhunderten zugeteilt. Zunächst war ich unsicher, ob ich das jüngere, das ältere Datum oder beide Daten nehmen sollte. Da in den Kategorien „Bibelhandschrift (x. Jahrhundert)“ und „Bilderhandschrift (x. Jahrhundert)“ entsprechende Handschriften beiden Daten zugeordnet wurden, bin ich ebenso verfahren.

Zu Beginn meiner Arbeit ist mir aufgefallen, dass zeitgleich der Nutzer Jairon Levid Abimael Caál Orozco zunächst die Kategorie „Handschrift nach Jahrhundert“ erstellt und in den einzelnen Jahrhunderten die Unterkategorien „Bibelhandschrift (x. Jahrhundert)“ und „Bilderhandschrift (x. Jahrhundert)“ hinzugefügt hat. Dies hat für mich die Frage aufgeworfen, welche weiteren Kategorisierungen vorgenommen werden könnten. Ich könnte mir noch die Unterscheidung in literarische oder dokumentarische Handschriften vorstellen.

Meiner Meinung nach wäre es noch sinnvoll in der Zukunft zwischen Codizes und Papyri in den einzelnen Jahrhunderten zu unterscheiden. Diese mischen sich nach dem aktuellen Stand auf Wikipedia besonders im 3. und 4. Jahrhundert, zumal in der Beschreibung der Kategorie Handschriften deutlich steht, dass die Papyri nicht hierhin gehören. Auch unter „Bibelhandschrift“, die eine Unterkategorie zu „Handschrift“ bildet, folgt nicht der Definition der Oberkategorie , sondern versammelt Kodizes und Papyri/Rollen. Hier muss in Zukunft noch eine Lösung gefunden werden, um Codizes und Papyri zu trennen.

Kategorie: Handschrift (3. Jahrhundert) – Streng genommen gehört keiner dieser Papyri in die Kategorie „Handschrift (3. Jahrhundert)“, da es sich nicht um Codices handelt.

Der „Zwölfprophetenkodex“ ist eine Handschrift. Aber ist es auch eine Handschrift im Sinne der Wikipedia-Kategorie “Handschriften“? Also ein Codex? Vermutlich nicht.

Eine weitere Frage, auf die ich während meiner Überlegungen zu dem Kategoriesystem gestoßen bin: Gehören Handschriftenartikel, die bereits in einer spezielleren Kategorie, beispielsweise „Bilderhandschrift (6. Jahrhundert)“ zugeordnet sind, noch einmal zusätzlich in die Oberkategorie „Handschrift (6. Jahrhundert)“? Ich habe zunächst die Handschriften, welche den Kategorien „Bibelhandschriften (6. Jahrhundert)“ und „Bildhandschriften (6. Jahrhundert)“, ebenfalls noch einmal der Kategorie „Handschrift“ (6. Jahrhundert) zugeordnet. Dies habe ich ebenfalls beim 5. und 7. Jahrhundert vorgenommen. Mein Gedanke war, dass in der Übersicht zunächst alle Handschriften erscheinen und sie dann in einer speziellen Kategorie noch einmal gesondert gelistet und sortiert auffindbar sind. Jedoch hat mich ein anderer Nutzer darauf aufmerksam gemacht, dass mein Vorgehen falsch sei und bei Handschriftenartikeln, die bereits in den Kategorien „Bibelhandschrift (x. Jahrhundert)“ und „Bilderhandschrift (x. Jahrhundert)“ zugeordnet seien, die übergeordnete Kategorie nicht noch einmal eingetragen oder ergänzt werden dürfe. Ich konnte hierzu leider keine bestehende allgemeine Diskussion oder eine einheitliche Regel finden und habe von dem entsprechenden Nutzer keine genauere Begründung erhalten.

Das Ergebnis meiner Aufräumarbeiten. Kategorie: Handschrift nach Jahrhundert

Teilweise von mir angelegte und befüllte Kategorien zur Ordnung der Handschriften nach Jahrhunderten

Fazit

Ich habe während meiner Arbeit in Wikipedia gut 200 Handschriften kategorisiert. Mein persönlicher Eindruck war, dass dort ein Großteil der Handschriften in den entsprechenden Kategorien „Handschriften“ vom 4. Bis zum 16. Jahrhundert zu finden sind. Jedoch denke ich, dass in den einzelnen Kategorien noch weitere Arbeit notwendig ist und weitere Unterkategorien, wie die Unterscheidung zwischen Codizes und Papyri, sinnvoll sind, um ein noch übersichtlicheres und systematischeres Kategoriesystem zu erhalten. Als Anfänger in dem Bereich Kodikologie und Paläografie ist mir die Unterscheidung schwergefallen, ob ein Artikel einen „Kodex“ oder ein „Werk“ behandelt, da diese Teilweise vermischt sind. Ein typisches Beispiel hierfür wäre der „Kölner Mani-Kodex“. Die Zuordnung der Handschriftenartikel nach Jahrhunderten ist mir hingegen leichter gefallen. Den Umgang in der Wikipedia habe ich zum größten Teil als freundlich empfunden. Eine Ausnahme war hier das oben schon beschriebene Problem, in Bezug auf die Einordnung der Handschriften in den Kategorien „Bibelhandschrift (x. Jahrhundert)“ und „Bilderhandschrift (x. Jahrhundert)“ und der übergeordneten Kategorien. Allgemeinen wurden meine Veränderungen aber angenommen.

06/06/202212/10/2023

Digitale Forschung und Wissenschaftskommunikation – der Fall der mediävistischen Zeitschriften.

Colleen Seidel

Im Sommersemester 2020 habe ich am Seminar „Digitale Transformation in den Geisteswissenschaften“ bei Prof. Sahle an der Bergischen Universität Wuppertal teilgenommen. Während für viele Kommilitonen eine Untersuchung von digitalen Quelleneditionen oder digitaler Erinnerungskultur in Betracht kam, war für mich relativ schnell klar, dass ich eher eine empirische Untersuchung machen wollte. Daraus ergab sich dann das Thema meiner Seminararbeit: Wie verändern sich Zeitschriften der Mittelalterforschung durch die Digitalisierung.

Vorgehen / Methodik

Angefangen habe ich mit der Auswahl der zu untersuchenden Zeitschriften. Dabei wurde schon nach kurzer Recherche deutlich, dass ich eine Auswahl treffen musste, da es innerhalb der Mittelalterforschung sehr viele verschiedene Zeitschriften gibt. Aus sprachlichen Gründen entschied ich mich, nur Zeitschriften aus dem deutsch- und englischsprachigen Raum zu untersuchen. Zudem wollte ich auch auf den Unterschied zwischen „klassischen“ Zeitschriften und „born digital“-Zeitschriften eingehen. Deshalb habe ich mich schließlich für folgende Zeitschriften entschieden:

„Klassische“ Zeitschriften:

Deutsches Archiv für Erforschung des Mittelalters: Zeitschrift der MGH, die älteste Zeitschrift im deutschsprachigen Raum und eine der führenden in der internationalen Mittelalterforschung, erscheint seit 1820
Mediaevistik. Internationale Zeitschrift für interdisziplinäre Mittelalterforschung: hier sollen vor allem interdisziplinäre Ansätze gefördert werden, erscheint seit 1988
Das Mittelalter. Perspektiven mediävistischer Forschung: Zeitschrift des Mediävistenverbandes, erscheint seit 1996
Speculum. A journal of medieval studies: Zeitschrift der Medieval Academy of America und erste Zeitschrift in den USA zum Mittelalter, fachlich sehr breit ausgerichtet, erscheint seit 1926
Medieval Studies: Zeitschrift des Pontifical Institute of Medieval Studies mit Schwerpunkt auf der Kirchengeschichte, erscheint seit 1939
Journal of Medieval History: europäische Geschichte (auch die Kontinentaleuropas) des Mittelalters soll (besonders in den USA) verbreitet werden, erscheint seit 1975

„born digital“-Zeitschriften:

Digital Medievalist: Zeitschrift der Gruppe „Digital Medievalist“ mit dem Ziel, ein Forum für alle Aspekte der digitalen Mediävistik zu bieten, erscheint seit 2005
Medieval Worlds. Comparative & interdisciplinary studies: vom Institut für Mittelalterforschung der Österreichischen Akademie der Wissenschaften, veröffentlicht interdisziplinäre und transkulturelle Studien, erscheint seit 2015
The Medieval Review: wird aktuell von der Indiana University herausgegeben, mit dem Ziel Rezensionen schneller zu veröffentlichen und leichter zugänglich zu machen, erscheint seit 1993

Um den Einfluss der Digitalisierung auf die Zeitschriften zu untersuchen, habe ich die Jahrgänge 1999, also die Frühphase des Umbruchs, und 2019 betrachtet, da die Zeitschriften im Sommer 2020 teilweise noch keine Ausgabe für das Jahr veröffentlicht hatten. Daraus ergab sich über alle Zeitschriften hinweg eine Anzahl von 257 Artikeln und 2994 Rezensionen. Bei den Zeitschriften Digital Medievalist und Medieval Worlds musste ich auf deren jeweilige Erstausgabe (2005 und 2015) als Vergleichsbasis zurückgreifen, weil diese Zeitschriften 1999 noch nicht publiziert wurden. Ich habe mich schließlich für die Nutzung einer Datenbank entschieden, da die Zeitschriften auf eine große Bandbreite von möglichen Änderungen hin untersucht wurden (Art der Texte, Länge der Texte, Sprache, Autorschaft, Hinweise auf Digitalisierung in den Texten und Forschungsthemen). Der entscheidende Vorteil einer Datenbank gegenüber einer einfachen Datentabelle (wie bei Excel) liegt darin, den Datenbestand über verschiedene Abfragen auswerten zu können. Für die Auswertung habe ich mir die Daten für die jeweiligen Zeitschriften, für die Jahrgänge und für „klassische“ und „born digital“-Zeitschriften angeschaut. Immer dann, wenn es in der Fragestellung vor allem um die unterschiedliche Herangehensweise in der Forschung geht, wurde zudem noch nach „klassischer Mediävistik“ und „digitaler Mediävistik“ unterschieden.

Ergebnisse der Auswertung

Zunächst stellt sich die Frage, worin sich eigentlich „klassische“ und „born digital“-Zeitschriften unterscheiden. Der offensichtlichste Unterschied ist das Datum der Erstausgabe. Dieses ist bei den „klassischen“ Zeitschriften zumeist deutlich früher (bei den hier untersuchten „klassischen“ Zeitschriften liegt es zwischen 1820 und 1996) als bei den „born digital“-Zeitschriften (zwischen 1993 und 2015). Zu erklären ist dies durch die Art der Publikation. Während „klassische“ Zeitschriften auch heute noch in gedruckter Form vorliegen, sind „born digital“-Zeitschriften, wie der Name schon sagt, allein in digitaler Form erhältlich. Mittlerweile haben auch die „klassischen“ Zeitschriften zumindest Teile ihrer Ausgaben in digitaler Form verfügbar gemacht. Aber hier ist ein weiterer, wenn nicht sogar der wichtigste Unterschied zwischen den beiden Arten von Zeitschriften zu finden. Die untersuchten „born digital“-Zeitschriften haben alle einen Open Access-Zugang, das heißt jeder kann auf sie zugreifen, ohne dafür zu bezahlen. Anders sieht es bei den „klassischen“ Zeitschriften aus. Hier liegen die digitalen Ausgaben der Zeitschriften hinter einer Pay Wall, sodass Institutionen oder Einzelpersonen für den Zugang zahlen müssen.
Das heißt, hinter den beiden Arten von Zeitschriften stecken zwei verschiedene Konzepte bezüglich der Zugänglichkeit von Forschungsergebnissen. Während die „born digital“-Zeitschriften für jeden ohne Einschränkungen zugänglich sind, wird bei den „klassischen“ Zeitschriften weiterhin am klassischen Verlagsmodell, also Zugang nur gegen Bezahlung, festgehalten.

Auch wenn es bei den inhaltlichen Formaten der Zeitschriften kaum Veränderung in den letzten 20 Jahren gegeben hat, soll kurz auf die Arten der Texte sowie die Anzahl und Länge eingegangen werden. Die beiden wichtigsten Textarten von Zeitschriften sind die Artikel und Rezensionen. Zusätzlich gibt es in manchen Zeitschriften auch noch Vorworte der Herausgeber, Berichte über Tagungen oder aus Instituten/Verbänden und Nachrufe. Insgesamt ist hier aber eine sehr große Konstanz beim Vergleich der beiden Jahrgänge zu verzeichnen. Die einzige Ausnahme bildet Das Mittelalter, bei dem es 1999 noch keine Rezensionen gegeben hat – 2019 dann schon.

Jahrgang	Anzahl Artikel	Länge Artikel (in Seiten)	Anzahl Rezensionen	Länge Rezension (in Seiten)
1999	7,4	23,66	209,1	1,16
2019	8,4	24,48	156,6 (ohne Das Mittelalter 192,75)	1,32

Beinahe konstant sind auch die Anzahl und die Länge der Artikel geblieben. In einer Zeitschrift sind normalerweise ungefähr acht Artikel, die ungefähr 24 Seiten lang sind. Etwas anders sieht dies bei den Rezensionen aus, da hier eine Zunahme bei „born digital“-Zeitschriften zu verzeichnen ist, während es gleichzeitig zu einer Abnahme bei den „klassischen“ Zeitschriften gekommen ist. Dies könnte an einer zunehmenden Bekanntheit von „born digital“-Zeitschriften und dem leichteren Zugang und Handling (z.B. Suchfunktionen und Open Access) im Vergleich zu „klassischen“ Zeitschriften und auch an „Platzmangel“ und Druckkosten bei den „klassischen“ Zeitschriften liegen. Der „Platzmangel“ in „klassischen“ Zeitschriften macht sich auch bei der Länge bemerkbar, da in „born digital“-Zeitschriften Rezensionen durchschnittlich um fast ein dreifaches länger sind als in „klassischen“ Zeitschriften.

Jahrgang	Anzahl Artikel	Länge Artikel (in Seiten)	Anzahl Rezensionen	Länge Rezension (in Seiten)[1]
Klassisch 1999	7,4	26,3	223,1	1,2
Klassisch 2019	8,6	27,6	189,7 (ohne Rezension von Das Mittelalter)	1,3 (ohne Rezension von Das Mittelalter)
“born digital” 1999	8,3	24,3	167	3,4
“born digital” 2019	7,5	34,0	202	2,8

Der nächste Aspekt, den ich untersucht habe, ist die Sprache der Artikel, der Rezensionen und der rezensierten Werke. Da ich nur Zeitschriften aus dem deutsch- und englischsprachigen Raum untersucht habe, ist es nicht weiter verwunderlich, dass Deutsch und Englisch auch die Hauptpublikationssprachen der Artikel waren. Dabei scheint es zumindest in der Untersuchungsmenge eine Entwicklung zu mehr englischsprachigen Artikeln oder Artikeln mit zumindest einem englischsprachigen Abstract zu geben – rein deutschsprachige Artikel machten 1999 noch 44% aus, während es 2019 nur noch 9% sind. Ähnlich sieht es auch bei den Rezensionen aus: Das Mittelalter und das Deutsche Archiv publizieren diese nach wie vor ausschließlich auf Deutsch, während Speculum Rezensionen ausschließlich auf Englisch veröffentlicht, bei Mediävistik hat es allerdings eine deutliche Zunahme der englischsprachigen Rezensionen gegeben (von 13% 1999 auf 56% 2019). Auch gibt es einen klaren Unterschied zwischen Artikeln und Rezensionen aus „klassischen“ und aus „ born digital“-Zeitschriften. So gibt es bei ersteren eine deutliche Orientierung an der Sprache des Publikationslandes, während letztere ausschließlich auf Englisch publizieren. Bei der Sprache der rezensierten Werke lassen sich drei Aussagen treffen:

Werke, die in Englisch verfasst wurden, wurden 2019 (56%) häufiger rezensiert als noch 1999 (41%)
In „klassischen“ Zeitschriften orientiert man sich an den Publikationen der Landessprache (so sind mehr als 33% der untersuchten Rezensionen in Zeitschriften aus dem deutschen Sprachraum über Werke auf Deutsch)
In „born digital“-Zeitschriften sind 92% der untersuchten Werke in Englisch verfasst.

Insgesamt ist eine deutliche Zunahme des Englischen zu verzeichnen, was größtenteils wohl auf die Digitalisierung und die daraus folgenden Internationalisierung der Forschung zurückzuführen ist.

Auch bei der Betrachtung der Autorschaft von Artikeln, Rezensionen und rezensierten Werken kam es innerhalb der letzten 20 Jahren zu einer Veränderung, wobei sich der Einfluss, den die Digitalisierung hierauf hatte, nicht genau bestimmen lässt. So hat der Anteil von Co-Autorschaft – also Artikel die von mehr als einem Autor oder einer Autorin verfasst wurden – vor allem in „born digital“-Zeitschriften und stark international ausgerichteten Zeitschriften wie der „Mediävistik“ deutlich zugenommen (z.B. beim Digital Medievalist von 29% 2005 auf 100% 2019). Bei den Rezensionen konnte keine Veränderung festgestellt werden, was aber mit der Kürze dieses Textgenres begründet werden kann. Aber auch bei den rezensierten Werken ist eine langsame Veränderung zu mehr Co-Autorschaft zu registrieren.

Jahrgang	Artikel		Rezension			Rezensiertes Werk
	Ein Autor	Mehrere Autoren	Kein Autor angegeben	Ein Autor	Mehrere Autoren	Kein Autor angegeben	Ein Autor	Mehrere Autoren
1999	89 (97%)	3 (3%)	92 (6%)	1522 (94%)	1 (0%)	58 (4%)	1275 (79%)	282 (17%)
2019	107 (77%)	32 (23%)	46 (3%)	1333 (97%)		17 (1%)	1275 (79%)	374 (27%)

Neben der Betrachtung der (Co-)Autorschaft habe ich auch die Angaben der Kontaktdaten der Autorinnen und Autoren in den Zeitschriften untersucht. Hier konnte ich eine große Konstanz bei den verschiedenen Angaben innerhalb einer Zeitschrift feststellen. Zwar sind Angaben wie Telefonnummer oder Faxnummer, die es 1999 noch gegeben hat, verschwunden und Webseiten und ORCID der Autor*innen hinzugekommen, aber in den allermeisten Fällen waren nur die Universität und die Adresse angegeben oder es gab keine Kontaktangaben (hier ist vor allem das Deutsche Archiv zu nennen). Auch konnte festgestellt werden, dass es insgesamt bei der Nennung von Mailadressen beim Vergleich der Jahrgänge 1999 und 2019 zu einer Steigerung von 12% auf 28% kam. Besonders deutlich ist der Unterschied bei der Angabe der Mailadresse beim Vergleich von „klassischen“ Zeitschriften (9%) und „born digital“-Zeitschriften (95%). Diese Beobachtungen gelten sowohl für Rezensionen als auch für Artikel

Bei den Hinweisen auf Aspekte der Digitalisierung der Forschung in den Texten können in einem sehr pragmatischen Vorgehen mehrere Aspekte untersucht werden: Zum einen die Überschriften und Abstracts und zum anderen die Fußnoten und die Bibliographie. Dabei habe ich zunächst die Anteile der Fußnoten mit digitalem Inhalt verglichen und dann die Inhalte der Fußnoten in sechs verschiedene Kategorien eingeteilt: digitale Werkzeuge, digitale Methoden, Daten, Literatur über digitale Werkzeuge und Methoden, digitale Ressourcen im Internet und digitale Literatur.
Bei der Betrachtung der Überschriften fiel auf, dass normalerweise in den untersuchten Zeitschriften keine Artikel mit Hinweisen auf Digitalisierung in der Überschrift veröffentlicht werden. Einzige Ausnahme ist hier das Themenheft von 2019 zum Thema „Digitale Mediävistik“ der Zeitschrift Das Mittelalter und die Zeitschrift Digital Medievalist, wobei bei dieser schon im Namen der Zeitschrift deutlich wird, dass sie sich der „digitalen“ und nicht der „klassischen“ Mediävisitk widmet. Auch bei den Rezensionen gibt es nur in seltenen Ausnahmen Hinweise auf Digitalisierung in der Überschrift, wobei es sich aber meistens um Links zu Inhaltsverzeichnissen handelt, die mit in der Überschrift stehen.

Etwas anders sieht es bei der Untersuchung der Abstracts der Artikel und der Rezensionen aus. Zunächst konnte festgestellt werden, dass die Anzahl der Artikel mit Abstracts in den letzten 20 Jahren deutlich (von 20% auf 71%) zugenommen hat. Zwar sind auch hier meistens die Hinweise auf Digitalisierung nur im Themenheft „Digitale Mediävistik“ und in dem Digital Medievalist zu finden, aber auch in fünf weiteren Abstracts war dies der Fall. Bei den Rezensionen ist im Vergleich zu den Artikeln eine deutliche Zunahme von 9% an Hinweisen auf Digitalisierung zu verzeichnen.

Jahrgang	Artikel			Rezension
	Kein Abstract	ja	nein	ja	nein
1999	74 (80%)		18 (20%)	5 (0,3%)	1619 (99,7%)
2019	40 (29%)	20 (14%)	79 (57%)	127 (9%)	1252 (91%)

Um herauszufinden, ob sich der Anteil der digitalen Inhalte in Fußnoten innerhalb der letzten 20 Jahre verändert hat, habe ich bei jedem Artikel den Anteil der Fußnoten mit digitalem Inhalt bestimmt und dann den Bereichen 0%-5%, 5%-10%, 10%-25%, 25%-50%, 50%-100% und keine Fußnoten zugeordnet. Daraus lassen sich folgende Tendenzen ablesen: Erstens nimmt die Zahl von Artikeln mit 0%-5%-Anteil „digitaler Fußnoten“ zwischen 1999 und 2019 von 92% auf 70% ab. Zweitens sind 80% der Artikel der „digitalen Mediävistik“ im Bereich 50%-100% und drittens sind 90% der Artikel der „klassischen Mediävistik“ im Bereich 0%-5%.
Ein ähnliches Bild entsteht bei der Betrachtung der Inhalte der digitalen Fußnoten. So sind Hinweise auf digitale Werkzeuge (z.B. Datenbanken, Sprachen wie HTML, …), digitale Methoden (z.B. Erstellung von digitalen Editionen, Katalogisierung von Quellen, …) und Daten (z.B. Training oder Genauigkeit von Programmen, …) vor allem in Artikeln zu finden, die der „digitalen Mediävistik“ zuzuordnen sind, während dies in Artikeln der „klassischen“ Mediävistik seltene Ausnahmen sind. Auch bei Literatur über digitale Werkzeuge und Methoden ist dies der Fall. Anders sieht es bei der Verwendung von digitalen Ressourcen (z.B. Webseiten, …) und digitaler Literatur (z.B. Zeitschriften oder Bücher, die online zugängig sind) aus. Hier ist ein starker Anstieg innerhalb der letzten 20 Jahre zu verzeichnen: bei digitalen Ressourcen um 43% und bei digitaler Literatur um 26%. Zwar liegt auch hier die „digitale Mediävistik“ immer noch vor der „klassischen Mediävistik“, allerdings weist der allgemeine Anstieg auf eine größere Nutzung des Internets und eine dadurch veränderte Forschungsarbeit hin. Es sollte auch beachtet werden, dass möglicherweise die Nutzung von digitaler Literatur nicht in den Fußnoten zu finden ist, da anstelle dieser die gedruckte Version zitiert wird. Diese Vermutung ist kaum zu überprüfen. Abschließend ist noch zu sagen, dass es auch in Bibliographien von Artikeln, auch wenn sie in dieser Untersuchung kaum vorkamen, Hinweise auf Digitalisierung gegeben hat.

Klassisch / born digital	Literatur über digitale Werkzeuge und Methoden		Digitale Ressourcen im Internet		Digitale Literatur
	ja	nein	ja	18 (35%)	ja	nein
Klassisch	16 (8%)	190 (92%)	68 (33%)	138 (67%)	43 (21%)	163 (79%)
Klassisch (ohne Themenheft zur digitalen Mediävistik von „Das Mittelalter“	2 (1%)	182 (99%)	48 (26%)	136 (74%)	28 (15%)	156 (85%)
born digital	5 (9%)	46 (91%)	18 (35%)	33 (65%)	9 (16%)	42 (84%)

Digitale Mediävistik /Klassische Mediävisitk	Literatur über digitale Werkzeuge und Methoden		Digitale Ressourcen im Internet		Digitale Literatur
	ja	nein	ja	nein	ja	nein
Nicht genau zuordbar	2 (67%)	1 (33%)	3 (100%)		1 (33%)	2 (67%)
Digitale Mediävistik	18 (50%)	18 (50%)	29 (81%)	7 (19%)	21 (58%)	15 (42%)
Klassische Mediävistik	1 (0,5%)	217 (99,5%)	54 (25%)	164 (75%)	30 (14%)	188 (86%)

Als letztes habe ich mir – in Anlehnung an die These, dass die Digitalisierung zu neuen Fragestellungen führt – die Forschungsthemen der Artikel und rezensierten Werke angeschaut, um herauszufinden, ob es hier zu einer Veränderung gekommen ist. Da im Rahmen der Seminararbeit nicht möglich gewesen ist, alle Forschungsthemen miteinander zu vergleichen, habe ich vier verschiedene Kategorien eingeführt: Literaturart, weltlich/geistlich, Zeit und Region.
Bei der Literaturart – also Forschungsliteratur oder Quellenedition – ist zunächst wenig überraschend festzustellen, dass Artikel nur in Ausnahmefällen keine Forschungsliteratur sind. Außerdem nahm der Anteil der Quelleneditionen in den rezensierten Werken etwas ab (5%), dabei könnte es sich aber auch um zufällige Schwankungen handeln.
In der Kategorie „weltlich/geistlich“ ist eine große Konstanz festzustellen, wenn von Themenheften abgesehen wird, wodurch man Rückschlüsse auf das Profil der Zeitschrift ziehen kann. So sind zum Beispiel 1999 60% und 2019 83% der Artikel der Medieval Studies zu geistlichen Themen, wobei zu beachten ist, dass diese Zeitschrift vom Pontifical Institute of Medieval Studies herausgegeben wird. Bei anderen Zeitschriften ist das Verhältnis zwischen weltlichen und geistlichen Themen ausgeglichener und die geringen Unterschiede zwischen „born digital“ und „klassischer Zeitschrift“ dürften zu vernachlässigen sein.
Auch bei der Einordnung der Artikel und Rezensionen in die behandelte „Zeit“ kann man das Profil der einzelnen Zeitschriften erkennen, obwohl die einzelnen Zeiten (Frühmittelalter, Hochmittelalter, Spätmittelalter, Mittelalter, allgemein, Andere) jeweils relativ gleichmäßig vorkommen. So sind beispielsweise viele Artikel des Deutschen Archivs über das Früh- und Hochmittelalter, während im Journal of Medieval History der Fokus eher auf das Hoch- und Spätmittelalter gelegt wird und Mediävistik (zumindest 1999) sehr ausgeglichen über alle „Zeiten“ ist.
Die Profilbildung der Zeitschriften ist auch im Bereich der Regionen zu finden: das Deutsche Archiv beschäftigt sich vornehmlich mit dem Heiligen Römischen Reich, im Journal of Medieval History und Speculum sind Artikel zu den britischen Inseln zu finden, während Medieval Worlds eher die Welt außerhalb Europas und Mediävistik Europa in den Blick nehmen. Digital Medievalist, Medieval Studies und Das Mittelalter sind mit dieser Untersuchung kein bestimmter Schwerpunkt zuzuordnen. Wichtig zu erwähnen scheint, dass es innerhalb der letzten 20 Jahre eine zunehmende Beschäftigung mit außereuropäischen Ländern gibt (Steigerung von 3% auf 9%) und dass man in den „klassischen“ Zeitschriften viel zu den Regionen das Heilige Römische Reich, Italien, Frankreich, britische Inseln und Europa findet, wohingegen „born digital“-Zeitschriften sich öfter auch mit außereuropäischen Ländern beschäftigen.

Fazit

Bei der Einschätzung dieser Ergebnisse ist zu beachten, dass, auch wenn 257 Artikel und 2994 Rezensionen untersucht wurden, dies immer noch eine sehr geringe Datenbasis für eine statistische Auswertung ist. Dies gilt vor allem für den Bereich der „born digital“-Zeitschriften, da hier nur 51 Artikel und 369 Rezensionen aus drei Zeitschriften analysiert wurden. Auch wenn ich versucht habe, die großen Linien der Entwicklung aufzuzeigen, müssten noch mehr Jahrgänge und / oder Zeitschriften ausgewertet werden, damit zwischen statistischen Schwankungen und tatsächlichen Veränderungen unterschieden werden kann.

Dennoch sind einige Befunde festzuhalten:

Zwischen „klassischen“ und „born digital“-Zeitschriften gibt es vor allem große Unterschiede bei der Art der Verfügbarmachung (Open Access gegenüber Pay Wall) und der Rolle der digitalen Ausgabe (primäre Form bei den „born digital“ und Zusatzfunktion bei den „klassischen“ Zeitschriften).
Große Unterschiede hinsichtlich des Einflusses der Digitalisierung gibt vor allem bei der Herangehensweise an die Fragestellungen, also ob klassisch oder eher digital wie beim Digital Medievalist, sodass man hier auch von zwei verschiedenen Welten der Mittelalterforschung sprechen könnte.
Die Digitalisierung hat kaum einen Einfluss auf die Profile der Zeitschriften.
Bei der Betrachtung der Forschungsthemen lassen sich die Zeitschriften sehr gut (auch bei der geringen Anzahl von Artikeln und Rezensionen) in bestimmte Profile einteilen.
„Digitale Mediävistik“ ist nicht automatisch in „born digital“-Zeitschriften zu finden, aber sie hat auch kaum Platz in den „klassischen“ Zeitschriften (abgesehen von einem Themenheft).

Somit ist das Fazit meiner Seminararbeit, dass sich die „klassische Mediävistik“, wie sie sich in den traditionsreichen Zeitschriften äußert, innerhalb der letzten 20 Jahre bis auf die Nutzung des Internets, digitaler Editionen, digitaler Literatur und digitale Kommunikationsmittel in ihre Arbeit kaum weiterentwickelt hat. Auch stehen sich „digitale Mediävistik“ und „klassische Mediävistik“ fast berührungslos gegenüber und es gibt nur in wenigen Ausnahmen Ansätze fachlicher Zusammenarbeit zwischen diesen beiden Forschungsrichtungen.

Kategorie	Das Mittelalter	Deutsches Archiv	Mediävistik	Speculum	Journal	Medieval Studies	Digital Medievalist	Medieval Worlds	Medieval Review
Klassisch / born digital	klassisch	klassisch	klassisch	klassisch	klassisch	klassisch	born digital	born digital	born digital
Erstausgabe	1996	1820	1988	1926	1975	1939	2005	2015	1993
Aktueller Herausgeber	Mediävistenverband / Regina Toepfer	Präsident der MGH (Enno Bünz, Martina Hartmann, Claudia Märtl, Stefan Petersen)	Albrecht Classen	Medieval Academy of America	C. M. Woolgar	Pontifical Institute of Medieval Studies (PIMS)	Digital Medievalist	Institut für Mittelalterforschung der Österreichischen Akademie der Wissenschaften (Walther Pohl und Andre Gingrich)	Indiana University
Aktueller Verlag	De Gruyter	Böhlau	Peter Lang	University of Chicago Press	Elsevier	University of Toronto Press	n.a.	n.a.	n.a.
Open Access	Nein	Moving-Wall (drei Jahren)	Alle Ausgaben ab 1999	Nein	Nein	Nein	Ja	Ja	Ja
Themenhefte	Ja	Nein	Nein	Nein	Nein	Nein	Nein	Meistens	Nein
Sprache	Deutsch	Deutsch	Deutsch & Englisch	Englisch	Englisch	Englisch	Englisch	Englisch	Englisch
Häufigste Sprachen der rezensierten Werke	Deutsch, Englisch	Deutsch, Englisch, Französisch, Italienisch	Deutsch, Englisch, Italienisch	Englisch, Französisch	n.a.	n.a.	n.a.	n.a.	Englisch
Co-Autorschaft bei Artikeln	Zunahme um 52%	Nur in Ausnahmen	Nur in Ausnahmen	Kaum	Kaum	Keine	Zunahme um 71%	Zunahme um 19%	n.a.
Co-Autorchaft bei rezensierten Werken	Kein Vergleich möglich, da es hier 1999 noch keine Rezensionen gab	Zunahme um 8%	Zunahme um 12%	Zunahme um 10%	n.a.	n.a.	n.a.	n.a.	Zunahme um 11%
Schwerpunkt bei den Forschungsthemen der Artikel	Hängt von den Themenheften ab	– Etwas mehr geistliche als weltliche Themen- Vor allem Früh- und Hochmittelalter- Reich	– Bei „weltlich oder geistlich“ relativ ausgeglichen- Relativ ausgeglichen bei den „Zeiten“- Europa	– Bei „weltlich oder geistlich“ relativ ausgeglichen- Leichte Tendenz Hoch- und Spätmittelalter- Britische Inseln	– Bei „weltlich oder geistlich“ relativ ausgeglichen- Vor allem Hoch- und Spätmittelalter- Britische Inseln	– Vor allem geistliche Themen- Vor allem Hoch- und Spätmittelalter- Kein räumlicher Schwerpunkt	– Bei „weltlich oder geistlich“ relativ ausgeglichen- Eventuell Fokus aufs Spätmittelalter, sonst bei „Zeit“ relativ ausgeglichen- Kein räumlicher Schwerpunkt	– Hängt von den Themenheften ab- Vor allem außerhalb Europas oder in und außerhalb Europas	n.a.
Schwerpunkt bei den Forschungsthemen der rezensierten Werke	– Bei „weltlich oder geistlich“ relativ ausgeglichen- Bei „Zeit“ relativ ausgeglichen- Reich und Europa	– Bei „weltlich oder geistlich“ relativ ausgeglichen- Bei „Zeit“ relativ ausgeglichen- Reich und Europa	– Bei „weltlich oder geistlich“ relativ ausgeglichen- Schwerpunkt auf Hoch-, Spätmittelalter und Mittelalter- Europa	– Bei „weltlich oder geistlich“ relativ ausgeglichen- Schwerpunkt auf Hoch-, Spätmittelalter und Mittelalter- Britische Inseln, Europa	n.a.	n.a.	n.a.	n.a.	– Bei „weltlich oder geistlich“ relativ ausgeglichen- Schwerpunkt auf Hoch- und Spätmittelalter – Britische Inseln

Kategorie	Das Mittelalter	Deutsches Archiv	Mediävistik	Speculum	Journal	Medieval Studies	Digital Medievalist	Medieval Worlds	Medieval Review
Häufigste Sprachen der rezensierten Werke	Deutsch, Englisch	Deutsch, Englisch, Französisch, Italienisch	Deutsch, Englisch, Italienisch	Englisch, Französisch	n.a.	n.a.	n.a.	n.a.	Englisch
Co-Autorschaft bei Artikeln	Zunahme um 52%	Nur in Ausnahmen	Nur in Ausnahmen	Kaum	Kaum	Keine	Zunahme um 71%	Zunahme um 19%	n.a.
Co-Autorchaft bei rezensierten Werken	Kein Vergleich möglich, da es hier 1999 noch keine Rezensionen gab	Zunahme um 8%	Zunahme um 12%	Zunahme um 10%	n.a.	n.a.	n.a.	n.a.	Zunahme um 11%
Schwerpunkt bei den Forschungsthemen der Artikel	Hängt von den Themenheften ab	– Etwas mehr geistliche als weltliche Themen – Vor allem Früh- und Hochmittelalter – Reich	– Bei „weltlich oder geistlich“ relativ ausgeglichen – Relativ ausgeglichen bei den „Zeiten“ – Europa	– Bei „weltlich oder geistlich“ relativ ausgeglichen – Leichte Tendenz Hoch- und Spätmittelalter – Britische Inseln	– Bei „weltlich oder geistlich“ relativ ausgeglichen – Vor allem Hoch- und Spätmittelalter – Britische Inseln	– Vor allem geistliche Themen – Vor allem Hoch- und Spätmittelalter – Kein räumlicher Schwerpunkt	– Bei „weltlich oder geistlich“ relativ ausgeglichen – Eventuell Fokus aufs Spätmittelalter, sonst bei „Zeit“ relativ ausgeglichen – Kein räumlicher Schwerpunkt	– Hängt von den Themenheften ab – Vor allem außerhalb Europas oder in und außerhalb Europas	n.a.

Kategorie	Das Mittelalter	Deutsches Archiv	Mediävistik	Speculum	Journal	Medieval Studies	Digital Medievalist	Medieval Worlds	Medieval Journal
			„Zeiten“ – Europa	Spätmittelalter – Britische Inseln	ter – Britische Inseln	kt	er, sonst bei „Zeit“ relativ ausgeglichen – Kein räumlicher Schwerpunkt
Schwerpunkt bei den Forschungsthemen der rezensierten Werke	– Bei „weltlich oder geistlich“ relativ ausgeglichen – Bei „Zeit“ relativ ausgeglichen – Reich und Europa	– Bei „weltlich oder geistlich“ relativ ausgeglichen – Bei „Zeit“ relativ ausgeglichen – Reich und Europa	– Bei „weltlich oder geistlich“ relativ ausgeglichen – Schwerpunkt auf Hoch-, Spätmittelalter und Mittelalter – Europa	– Bei „weltlich oder geistlich“ relativ ausgeglichen – Schwerpunkt auf Hoch-, Spätmittelalter und Mittelalter – Britische Inseln, Europa	n.a.	n.a.	n.a.	n.a.	– Bei „weltlich oder geistlich“ relativ ausgeglichen – Schwerpunkt auf Hoch- und Spätmittelalter – Britische Inseln

Die Seminararbeit und die Rohdaten sind auf Zenodo zu finden.

[1] Da es sich bei den Artikeln um Inhalte einer Webseite handelt, wurde für die Bestimmung der Länge im Firefox die Funktion der Druckvorschau (Standardeinstellungen) genutzt.

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.

06/07/202107/07/2021

Word validieren mit Schematron?

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

von Dr. Jennifer Bunselmeier

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

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

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

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

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

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

1. Viele Transformationsschritte – viele Fehlerquellen

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

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

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

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

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

2. Formale vs. semantische Kodierung

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

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

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

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

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

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

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

Bei diesem Transformationsbeispiel werden verschiedene Formatinformationen ausgewertet:

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

Abb. 3 Eine Fußnote kann anhand verschiedener Formatinformationen in eine TEI-Lesartenkodierung übersetzt werden

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

3. Zu viele Freiheiten in Word

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

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

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

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

Möglichkeit A – Das Wordvalidierungstool Data2Check

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

Vielversprechend ist das Tool Data2Check.

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

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

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

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

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

Ein absolut empfehlenswertes Tool!

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

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

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

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

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

Die ersten Versuche sind sehr vielversprechend.

Beispiel Titelei – Struktur gut prüfbar

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

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

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

Beispiel Spracheinstellung und Sonderzeichen – Transformationsskripte entlasten

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

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

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

Beispiel Stringabfragen – Schematron um individuelle Funktionen erweiterbar

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

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

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

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

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

Ein Problem bleibt – zurück zum Oxygen

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

Lösung: Doch der Autormodus

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

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

Vision: Schematronfehlermeldungen in Word zurückspielen

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

Zwischenfazit zu Wordvalidierungstools

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

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

31/05/202107/07/2021

Docker für die Digital Humanities

von Stephan Makowski

Manchmal möchte ich schnell mal etwas testen. Da ich regelmäßig mit Softwarelösungen arbeite, die hauptsächlich unter Linux laufen, setze ich mir für Testzwecke eine virtuelle Maschine auf. Das geht, ist aber recht ressourcenhungrig. Egal, ob unter Hyper-V oder Virtual Box. Möchte ich mehr als zwei Maschinen gleichzeitig laufen lassen, hat mein Rechner irgendwann eben keinen Speicher mehr. Also muss ich mir etwas anderes einfallen lassen.

Die beste Lösung hierfür ist ohne Zweifel ein Docker-Setup. Bei Docker handelt es sich um eine Containerlösung. Vereinfacht gesagt bedeutet das, dass auf dem Host ein Dockerservice installiert wird. Nach der Installation können beliebig viele (je nachdem, was der Rechner/Server so hergibt) Web-/Mailserver, Datenbanken, WordPressinstanzen, etc. gestartet und gemanaged werden. Eine Übersicht über die möglichen Container, die unter Docker laufen, ist auf Docker Hubs zu finden.

Das Schöne daran ist: Die meiste Software, z. B. Apache, MySQL oder Neo4J, ist direkt ohne weitere Programmierkenntnisse einsetzbar. Die Container werden runtergeladen, individuell konfiguriert und in der Dockerumgebung gestartet. Klingt einfach? Ist es auch. Wer mir nicht glaubt, kann das hier direkt mal nachlesen.

Docker compose – dein Freund und Helfer

Inwiefern ist das also auch für die Digital Humanities interessant? In etlichen Bereichen werden NoSQL Datenbanken wie eXist-db oder BaseX eingesetzt. Auch diese Datenbanken sind bereits als vorbereitete Dockerimages zu haben.

Möchte man solch eine Konfiguration öfter mal testen, tut man gut daran, eine sogenannte docker-compose-Datei zu schreiben. Hierbei handelt es sich um eine Art Beschreibung, welches Image Docker laden soll und wie dieses zu konfigurieren und zu starten ist.

Im Juni 2021 wurde eine neue NoSQL-Datenbank mit dem Namen FusionDB veröffentlicht. Zu Testzwecken habe ich hierfür eine docker-compose-Datei erstellt, die ich im Folgenden präsentieren möchte:

version "3"
services:
  fusiondb:
    image: fusiondb
    build:
      context: ./conf
      dockerfile: ./Dockerfile
      args:
        PASSWORD: ${PASSWORD}
        INIT_MEMORY: ${INIT_MEMORY:-256}
        MAX_MEMORY: ${MAX_MEMORY:-2048}
        CACHE_SIZE: ${CACHE_SIZE:-256}
        COLLECTION_CACHE: ${COLLECTION_CACHE:-256}
        LUCENE_BUFFER: ${LUCENE_BUFFER:-256}
        HTTP_PORT: ${HTTP_PORT:-4059}
        HTTPS_PORT: ${HTTPS_PORT:-5059}
        SERVER_NAME: ${SERVER_NAME:-localhost}
    volumes:
      - data:/opt/fusiondb/fusiondb-server-1.0.0-ALPHA1/data
    ports:
      - 4059:4059
      - 5059:5059  
    container_name: fusiondb
    restart: always
    networks:
      - www
    labels:
      - "traefik.backend=fusiondb-backend"
      - "traefik.docker.network=www"
      - "traefik.frontend.rule=Host:fusiondb.stephan-makowski.de"

volumes:
  data: {}

networks:
  www:
    external:
      name: ${TRAEFIK_NETWORK:-www}

docker-compose.yml

In dieser Datei soll ein Dienst mit dem Namen fusiondb erstellt werden. Hierfür gibt es (noch) kein fertiges Image, sodass dieses vorab erstellt werden muss. Die Anweisungen, welche und wie eine Erstellung vorgenommen werden soll, befinden sich in der Datei “Dockerfile” (s. unten).

Ein wichtiger Vorteil von Docker ist die EInrichtung sogenannter Volumes. Hierbei handelt es sich um (permanente) Verzeichnisse, die zur Laufzeit innerhalb des Containers gemounted werden. Es sind sozusagen Ordner, die an einer bestimmten Stelle eingehangen werden. An dieser Stelle soll das Volume data an das Verzeichnis /opt/fusiondb/fusiondb-server-1.0.0-ALPHA1/data angehangen werden. Wozu? Die Volumes können vom Host gesichert werden. Außerdem wird so sichergestellt, dass die Daten persistent vorgehalten werden. Ohne solch ein Volume würde bei jedem Start der Ursprungszustand des Images wiederhergestellt werden. Das ist bei Datenbanken etwas unpraktisch.

Die meisten Dienste im Internet sind über Portangaben zu erreichen. Für die Internetseiten ist es meist der Port 80, der als Standard für alle eingehenden Http-Anfragen genutzt wird. Der Service fusiondb soll allerdings auf eingehende Anfragen auf den Port 4059 (http) sowie 5059 (https) lauschen. Die Angaben können hier ganz leicht gesetzt werden. Oft kommt es aber vor, dass zwei unterschiedliche Dienste denselben Port nutzen. In diesem Fall kann in der Datei eine Zuweisung vorgenommen werden, welcher Port alternativ abgehört werden soll. Die Notation hierfür ist:

-ports:
– externer Port: interner Port

Damit wird eine Art Weiterleitung eingerichtet, die für jeden Dockercontainer genutzt werden kann.

Die folgenden Definitionen geben an, wie der Service heißt, welches interne Routingnetzwerk genutzt werden soll und ob ergänzende Informationen benötigt werden. In meinem Fall habe ich noch Angaben für den Routerservice Traefik gemacht. Abschließend folgen die Definitionen der Netzwerke sowie der Volumes. An dieser Stelle sei auf die gute Dokumentation von Docker verwiesen.

Wenn man kein Image hat, baut man sich halt eines

Wie bereits erwähnt, gibt es derzeit für fusiondb noch kein Dockerimage. Da ich dieses aber gern testen wollte und für zukünftige Updates bereits vorbereitet sein möchte, erstelle ich mir das Image selbst.

Im Grunde folgt die Datei dem Aufbau:

- Welche Basis soll benutzt werden?
- Was soll innerhalb der Basis gemacht werden?
- Wie ist das Image ansprechbar und wie soll Docker die Inhalte ansprechen?

ARG BASE_CONTAINER=ubuntu:latest
FROM $BASE_CONTAINER

LABEL maintainer="Stephan Makowski <stephan.makowski@rub.de>"

USER root

ENV JAVA_TOOL_OPTIONS="-Dfile.encoding=UTF-8"

ARG PASSWORD
ARG INIT_MEMORY=256
ARG MAX_MEMORY=2048
ARG CACHE_SIZE=256
ARG COLLECTION_CACHE=256
ARG LUCENE_BUFFER=256
ARG HTTP_PORT=8080
ARG HTTPS_PORT=8443
ARG SERVER_NAME='localhost'

RUN apt-get update && apt-get -yq dist-upgrade &&\
  apt-get install -yq --no-install-recommends \
  sudo \
  curl \
  htop \
  default-jdk \
  unzip \
  vim \
  wget &&\
  rm -rf /var/lib/apt/lists/*

WORKDIR /opt/fusiondb

RUN wget http://www.fusiondb.com/download/fusiondb-server-1.0.0-ALPHA1-unix.tar.bz2

RUN tar xjf ./fusiondb-server-1.0.0-ALPHA1-unix.tar.bz2

WORKDIR /opt/fusiondb/fusiondb-server-1.0.0-ALPHA1

VOLUME /opt/fusiondb/fusiondb-server-1.0.0-ALPHA1/data

RUN echo '#!/bin/bash' >> /usr/local/bin/docker-entrypoint.sh &&\
  echo 'set -e' >> /usr/local/bin/docker-entrypoint.sh &&\
  echo 'cd /opt/fusiondb/fusiondb-server-1.0.0-ALPHA1' >> /usr/local/bin/docker-entrypoint.sh &&\
  echo 'sudo bin/startup.sh' >> /usr/local/bin/docker-entrypoint.sh &&\
  chmod +x /usr/local/bin/docker-entrypoint.sh

EXPOSE ${HTTP_PORT} ${HTTPS_PORT}

HEALTHCHECK --interval=1m --timeout=3s \
  CMD curl -f http://localhost:4059/ || exit 1

ENTRYPOINT ["docker-entrypoint.sh"]

Dockerfile

Kurz zusammengefasst soll das Image für die Datenbank das letzte verfügbare Ubuntu als Ursprungsbetriebssystem nutzen. Anschließend erfolgt eine Aktualisierung und die Installation benötigter Komponenten wie z. B. Java. Im nächsten Arbeitsschritt lädt Docker dann die Datenbank herunter, entpackt diese und kopiert das Startskript, damit dieses von Docker ausgeführt werden kann.

Mir war bewusst, dass es sicherlich nicht die eleganteste Lösung ist, und wollte noch weitere Verarbeitungsschritte einarbeiten. Deshalb sind noch einige etwas kryptische Argumente enthalten. Und: Es funktioniert. Das erlaubt mir schon mal vorab, fleißig zu testen. Sollte in naher Zukunft eine aktualisierte Version der fusiondb herauskommen, bin ich vorbereitet.

Die Skripts können vollständig aus meinem Gitlab heruntergeladen werden.

Routing mit Traefik

Egal, ob Datenbank, Webpages oder andere Tools: selten werden die Dienste über nur einen Domainnamen angesprochen. So macht es Sinn, explizite Namen bzw. Subdomains für die unterschiedlichen Dienste zu verwenden. Während eine x-beliebige API unter api.meine-domain.de erreichbar ist, kann das obere Beispiel unter fusion.meine-domain.de laufen. Diese sinnstiftende syntaktische Unterscheidung vereinfacht die Nutzung wesentlich. Eine Möglichkeit, dies zu erreichen, ist die Verwendung des Dienstes traefik. Hierbei handelt es sich um einen Routingdienst, der sowohl per Docker als auch nativ auf dem Server betrieben werden kann. Die Nutzung ist denkbar einfach. Die jeweiligen Subdomains (www, api, db, etc.) werden im Domain Name Server (DNS) der Domain angelegt und verweisen dort zentral auf den Server (per IP). Wie ein jeweiliger Dienst angesprochen werden kann, muss separat in der docker-compose Datei hinterlegt werden.

labels:

– “traefik.backend=fusiondb-backend”

– “traefik.docker.network=www”

– “traefik.frontend.rule=Host:fusiondb.stephan-makowski.de”

Der Dienst wäre in diesem Beispiel nun unter fusiondb.stephan-makowski.de zu erreichen. Die Notation unterscheidet sich aber je nach verwendeter Traefik-Version. Mit dem Upgrade auf Traefik V2.0 ist die Auszeichnung zwar etwas umfangreicher geworden, erlaubt im Gegenzug aber eine vielfältigere Konfiguration. Eine Übersicht über sämtliche Funktionalitäten kann hier schwerlich geleistet werden. Vielmehr dient diese Übersicht lediglich als erster Eindruck.

labels:

– traefik.enable=true

– traefik.http.routers.hp.entrypoints=http

– traefik.http.routers.hp.rule=Host(`fusiondb.stephan-makowski.de`)

– traefik.http.middlewares.hp-https

-redirect.redirectscheme.scheme=https

– traefik.http.routers.hp.middlewares=hp-https-redirect

– traefik.http.routers.hp-secure.entrypoints=https

– traefik.http.routers.hp-secure.rule=Host(`fusiondb.stephan-makowski.de`)

– traefik.http.routers.hp-secure.tls=true

– traefik.http.routers.hp-secure.tls.certresolver=http

Die Notation ist teilweise variabel. So ist die grundlegende Syntax:

– traefik.http.[middlewares/routers].[Abkürzung des Dienstes].etc

Es muss beachtet werden, dass jeder Dienst sein eigenes Namenschema enthält. Ansonsten kann eine Auflösung des Dienstes nicht erfolgen.

Beispiel:

– traefik.http.routers.hp.rule=Host(`www.stephan-makowski.de`)

– traefik.http.routers.api.rule=Host(`api.stephan-makowski.de`)

-traefik.http.routers.fusion.rule=Host(`fusiondb.stephan-makowski.de`)

Ausblick

Ob eine kleine NoSQL-Datenbank zum Testen, eine WordPressinstanz als Projektseite oder ein Cluster, der über mehrere Server Ausfallsicherheit bietet: All das kann Docker und noch mehr. Und das Wichtigste: Das System ist kostenfrei erhältlich und nutzbar. Die Zeiten, in denen in langwierigen Verfahren an Rechenzentren Server beantragt werden mussten, sind vorbei. Denn Docker ist ein wunderbares Werkzeug und erleichtert einem massiv die Arbeit. Außerdem ersparen Dienste wie Traefik eine tiefgründige Beschäftigung mit Apache oder Nginx und macht Docker sowohl für IT-Expert*innen als auch für Laien interessant.

Für einen Austausch zu dem Thema stehe ich gern zur Verfügung.

Weiterführende Links

Überarbeitete Fassung des Blogbeitrags vom 17. Juni 2019 auf https://blog.stephan-makowski.de

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.