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

„Du kannst ja immer noch Lehrerin werden!“

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

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

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

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

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

Montag „Modellierung und Anwendung“

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

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

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

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

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

Dienstag „Technologien: XSLT“

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

Mittwoch „Technologien: XML-DB und xQuery“

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

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

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

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

Donnerstag „Publikationsformen“

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

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

Freitag „Nachnutzung und Analyse“

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

Fazit:

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

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

Masterclass „Digitale Editionen“ @Bergische Universität Wuppertal 2021

Von Nadine Sutor, WissMa @BUW

Trotz Corona veranstaltete die Bergische Universität Wuppertal (BUW) in der Zeit vom 22.02 bis 26.02.2021 die Masterclass – Digitale Editionen für advanced people in den Digital Humanities. Natürlich im Remote-Modus, wie aktuell jede Veranstaltung. Gewagt, gewagt. Kein Problem für das wunderbar funktionierende Orga-Team (bestehend aus Patrick Sahle, Lena Stahn, Torsten Roeder[1] und Roman Bleier[2] (letzterer für den Austrian-Spirit) und mir). Yes! Damit fing‘ alles an. Wer übernimmt welche Aufgabe? Wer ist wofür zuständig? Bis dato war ich bei derartigen Veranstaltungen als Tutorin und somit als Ansprechpartnerin für die betreuten Hands-on-Sessions am Start. Nice, 1 Upgrade. Teilnehmerlisten verwalten, Zeitslots für das Open-Forum vergeben, das technische Set-up[3] aka Zoom + Breakoutsessions aufziehen UND abschließend Zertifikate ausstellen. Klar hat ein komplett digital ausgerichteter Workshop Vorteile aber auch Nachteile sowie Herausforderungen. Zwar Keine Buchung von Unterkünften für Dozierende aber leider auch kein f2f Bier und Wein in der Kneipe …  

Der Call zur Masterclass wurde sehr gut angenommen. Innerhalb kürzester Zeit mussten wir den Slot für die Anmeldung schließen, da uns viele Bewerber*innen ihre spannenden und interessanten Projektberichte zusendeten. Kann man unsererseits von einer gewissen Erwartungshaltung sprechen? Was die Anmeldezahlen betrifft, wurde diese mehr als übertroffen. Mit Bezug auf den Call for Interest, den Patrick Sahle im Vorfeld (24.12.2020) auf das DHd-Blog [4] rausgewemmsert hat, formierten wir in wöchentlich stattfindenden Zoom-Sessions einen Plan. Nach und nach entwickelte sich eine 5-Tage-Dramaturgie mit möglichen Formaten, die unterschiedliche Themenschwerpunkte behandeln sollten. Das Programm[5] deckt fünf große und wichtige anwendungsspezifische Aspekte in den Digital Humanities ab:

  • Modellierung und Anwendung (Named Entities)
  • Anwendung von X-Technologien
    (Schwerpunkt advanced XSLT)
  • Datenbanksysteme (eXist-db in Kombination
    mit der Abfragesprache XQuery)
  • Publikationsformen (u.a. Minimal Publishing)
  • Nachnutzung und Analyse (u.a. Annotation, Topic Modelling)

An zwei Abenden boten wir ein Open-Forum an. Es sollte Wissenschaftler*innen die Möglichkeit geben, ihre Editionsprojekte vorzustellen und anschließend im Rahmen einer moderierten Diskussion Probleme zu diskutieren und potentielle Lösungsansätze zu erarbeiten, sofern es die Zeit zulassen würde. Darüber hinaus integrierten wir zwei Expert-Panels mit eingeladenen Dozierenden zu Best Practices und offenen Fragen zu Named Entities in Editionen und Publikationsszenarien.

Die Tage gliederten sich in einen Vormittag der Theorie in Form mehrerer Vortragsreihen und in einen Nachmittag, der sich mit praktischen Übungseinheiten füllte. Ein Vorteil des Online-Formats ist die Ansetzung mehrerer parallellaufender Stränge. So konnte jede*r Teilnehmer*in ein Thema wählen und den „Raum betreten“, der ihr/ihm am ehesten zusagte. Das brachte eine gewisse Flexibilität ins Spiel. Auch ich konnte bei der Winter School etwas mitnehmen. Sowohl mehr Informationen zu Themen sammeln, über die ich im Rahmen anderer Vorträge schon etwas gehört hatte (z.B. Topic Modeling), als auch Wissen zu bereits bekannten Technologien (eXist-db, XSLT) vertiefen und erweitern.

Mein subjektiver Eindruck?

Die School wäre nichts ohne das Engagement der wissbegierigen und aufgeschlossenen Teilnehmer*innen gewesen. Die Atmosphäre war locker, entspannt und heiter. Die Mitmachbereitschaft war da, es kam immer eine lebhafte und durchaus kontrovers geführte Diskussion zustande. In den praktischen Übungen arbeiteten einige selbstständig und eher für sich. Das betraf primär Teilnehmer*innen, die mit der Materie bereits vertraut waren. Genügend Fragen gab es in jedem Fall. Auf diese Weise bekamen die Sessions eine interaktive Komponente und waren nicht so sehr frontal und eintönig. Ein Problem, das immer wieder auftauchte und besonders bei einer Remote-Veranstaltung schwer zu händeln ist, ist das „Mitkommen“ und „Mitnehmen“ aller Beteiligten. Gelegentlich machte das technische Set-Up hier und da einen Strich durch die Rechnung.

War der Anspruch des Programms zu hoch oder zu niedrig angesetzt?

Genau richtig! Bei jeder School wird es thematische Abschnitte geben, die in der Kürze der Zeit nicht ausführlich und detailliert genug behandelt werden können damit sie am Ende jede*r versteht. Das war auch eigentlich nicht Ziel und Intention dieser Masterclass. Die Menschen sollten mit ihren projektspezifischen Fragen und Problemstellungen an uns herantreten, damit wir als Dozierende der BUW, der Leopoldina und des ZIMs gemeinsam mit Hilfe der großartigen Unterstützung vieler Gastdozierenden im Rahmen moderierter Diskussionen und praktischer Übungen Lösungsansätze erarbeiten und einen Überblick über aktuelle Entwicklungen des jeweiligen wissenschaftlichen Forschungsfeldes geben.

Was können wir aus der School mitnehmen?

Einiges. Vor allem das positive Feedback der Teilnehmer*innen! Nicht nur für die durchaus arbeitsintensive Planung, Durchführung und reibungslosen Ablauf, sondern auch für die Art des Umgangs mit den Menschen, die Betreuung, das einfach nur „da-sein“. Für uns als Winter School -Team war es das erste Mal, dass wir eine School im digitalen Format ausrichteten. Trotz der fehlenden und eigentlich so wichtigen sozialen Komponente (!), Stichwort socialisen, haben wir das alle sehr gut gemeistert. Mit einer so guten Rückmeldung gehen wir mit voller Kraft und Motivation an die nächste School. Hoffen wir auf eine nächste Veranstaltung, organised by Team-DH@BUW im Präsenzformat.

Spoiler : #digigw23 ! 


[1] Leopoldina, Berlin und BUW.

[2] Zentrum für Informationsmodellierung (ZIM), Graz.

[3] Während der School kommunizierten die Teilnehmer*innen parallel über einen extra eingerichteten Slack-Channel. An einem der Abende diente der Kumo-Space für einen zwanglosen Austausch. Spoiler: Das virtuelle Glas, angeheftet am Profilbild des eigenen Avatars, füllt sich mit Wein sobald man sich der Bar nähert.

[4] Veröffentlicht auf dem DHd-Blog am 24.12.2020. Online verfügbar unter: https://dhd-blog.org/?p=14824, zuletzt geprüft am 04.04.2021.

[5] Das Programm zur Masterclass – Digitale Editionen gibt es online auf der Website des IDE unter: https://www.i-d-e.de/aktivitaeten/schools/winter-school-2021-wuppertal/, zuletzt geprüft am 04.04.2021.


Webinar “eXist-db und XQuery”

Am kommenden Mittwoch und Donnerstag findet per Zoom eine interne Fortbildung zu dem Thema “eXist-db und XQuery” statt. Der Schwerpunkt am Mittwoch wird vor allem im Bereich der nativen XML-Datenbanken liegen. Primär soll erläutert werden, was Datenbanken sind und welchen Mehrwert diese bieten. Hierzu werden verschiedene einschlägige Datenbanken vorgestellt und deren Vor-/Nachteile erläutert. Der Fokus wird aber bei der eXist-db liegen. Im zweiten Teil des Mittwochs erfolgt dann eine kurze Einführung in XQuery sowie XPath.
Der Donnerstag wird dann vollumfänglich dazu genutzt die explizite Verwendung von XQuery anhand eines Beispiels exemplarisch durchzugehen. Hierzu wurde eine authentische Test-App erstellt, um praktisch die Verwendung von XQuery zu üben und nachvollziehen zu können. Der Nachmittag soll der Umsetzung und Beantwortung von speziellen Wünschen der Teilnehmer dienen.

Mittwoch

9:00 – 10:30h Einführung in native XML-Datenbanken
10:30 – 11:00h Pause
11:00 – 12:30h Einführung in XQuery & XPath

Donnerstag

9:00 – 10:30h Exemplarisches Beispiel für die Verwendung von XQuery
10:30 – 11:00h Pause
11:00 – Open End Benutzerspezifische Fragen (Facettierung, Github-Workflow, etc)


Vortragende: Lena Stahn, Stephan Makowski

Kontakt: Stephan.Makowski@uni-wuppertal.de

Frankfurter Postzeitung 1615-1619. Zum Korrespondenzsystem.

… Kleine Datengeschichten. Kleine Visualisierungsgeschichten. Kleine Forschungsgeschichten …

Von Patrick Sahle

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

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

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

1615

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

Korrespondenzdiagramm für 1615 (Vorschau)

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

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

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

1616

Korrespondenzdiagramm für 1616 (Vorschau)

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

1617

Korrespondenzdiagramm für 1617 (Vorschau)

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

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

1618

Korrespondenzdiagramm für 1618 (Vorschau)

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

1619

Korrespondenzdiagramm für 1619 (Vorschau)

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

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

Frankfurter Postzeitung, 30/1619, S. 4

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

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

Schluss

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

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

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

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

Das DH-Blog @ BUW

Das Blog „DHBUW“ hat zum Ziel, die Entwicklung und Tätigkeiten des seit Mai 2019 am historischen Seminar der Bergischen Universität Wuppertal [BUW] neu etablierten Lehrstuhls für „Digital Humanities“ zu präsentieren und zu diskutieren. Die Professur ist am Fachbereich Geschichte angesiedelt und setzt Schwerpunkte in den Bereichen Quellenerschließung, Digitale Editionen, Informationsvisualisierung und Digital History. Sie wird unterstützt durch uns, ein engagiertes, breit aufgestelltes und vielseitig interessiertes Lehrstuhlteam, das es sich zur Aufgabe gemacht hat, die DH nicht nur an der BUW, sondern einem breiten Publikum bekannt und schmackhaft zu machen.

Wir beschäftigen uns mit Daten, Datenmodellen, Formaten und Standards in den digitalen Geisteswissenschaften. Auch die Theoriebildung ist ein zentraler Aspekt. Daneben wird die Lehre ein zentrales Thema sein. Durch „Werbung“ für unsere Veranstaltungen in Form von uns selbst verfassten Berichten hoffen wir, Interesse wecken und Hemmungen bei der Beschäftigung mit „digitalen“ Themen beseitigen zu können. Gleichzeitig wollen wir die Studierenden ermutigen, von ihren selbst erarbeiteten Projekten und Ergebnissen, die im Rahmen von Seminaren und praktischen Übungen entstehen, zu berichten. Als Teil des Lehrstuhl-Betriebs sollen sie ein fester Bestandteil des Lehrstuhl-Blogs sein. Mit diesem Konzept möchten wir eine partizipative und interaktive Komponente in unseren Blog integrieren. Darüber hinaus berichten wir von Workshops und Schools, die sich thematisch mit diversen X-Technologien befassen und an deren Ausrichtung die BUW als Institution beteiligt ist. Weitere wichtige Inhalte werden unsere eigenen Forschungsprojekte sein. Dadurch soll das Profil der DH am Standort Wuppertal zum Vorschein kommen.

Suche in OpenEdition Search

Sie werden weitergeleitet zur OpenEdition Search