Geisteswissenschaften im Beruf – in einer digitalen Welt

Und was machst Du damit?

Eine Frage, die man als Geisteswissenschaftler*in wohl immer noch irgendwann gestellt bekommt. Um den Studierenden der Bergischen Universität Wuppertal eine Antwort neben der des Lehramts zu liefern, biete ich dieses Sommersemester jeweils donnerstags zwischen 16:15-18:00 Uhr eine offene und hybride Ringvorlesung unter dem Titel: „Geisteswissenschaften im Beruf – in einer digitalen Welt“ an.

In die Ringvorlesung kommen Gäste, die von ihrer Tätigkeit in internationalen Organisationen, dem Museums-, Bibliotheks-, Archiv- und Verlagswesen, von der Gedenkstätten- sowie der Öffentlichkeitsarbeit und dem Wissenschaftsmanagement berichten.

Darf er das überhaupt?

Mit dem Format habe ich einen Wunsch der Studierenden vom aus dem Sommer letzten Jahres aufgegriffen, die diesen über die Fachschaft ins Historische Seminar getragen haben. Dort bildete sich daraufhin die Arbeitsgruppe IASUL (Interessenvertretung Austausch Studium und Lehre). Die Arbeitsgruppe beschäftigt sich vor allem mit der Veränderung von Strukturen und der Verbessrung von Kommunikation. Mein damaliger Kollege Malte Windrath engagierte sich dort und beteiligte sich auch an der Planung der Ringvorlesung, sowie deren Vernetzung. Mein Anliegen war aber ein anderes, im Format der Ringvorlesung sehe ich ein (relativ) einfaches und unkompliziertes Mittel, Studierenden Alternativen zum Studienabbruch aufzuzeigen, nämlich andere Zukunftsperspektiven zu eröffnen. Zwar gibt bzw. gab es Angebote wie das des Career Service, doch sind diese entweder nicht speziell auf Geisteswissenschaften zugeschnitten oder ausgelaufen. Mit dem Ende der Förderphase des Qualitätspakts Lehre endete so beispielsweise auch das Format des „Jobtalks“.
Mir war es deswegen ein Anliegen, diese Leerstelle auszufüllen und ein entsprechendes Angebot zu schaffen. Zunächst musste ich mir dafür eine Sondergenehmigung des Dekanats einholen, weil meine Dissertation noch nicht abgeschlossen ist und mir dementsprechend eigentlich die Qualifikation fehlt. Das ging aber verhältnismäßig schnell und unkompliziert.

Netzwerkarbeit

Schwieriger war es, herauszufinden, mit wem ich sprechen muss und wen ich beteiligen kann. Bisher habe ich die Universität wegen der Pandemie nur digital kennengelernt und bin deswegen kaum mit den dortigen Serviceeinrichtungen in Kontakt gekommen. Das lässt auch schon die Probleme erahnen, die mit der Planung der Ringvorlesung verbunden waren. So ist es mir nicht gelungen, Honorare für meine Referent*innen aufzutun. Seitens der Verwaltung wurden kurz vor Semesterbeginn neue Honorarrichtlinien herausgegeben. Unterschiedliche Ansichten, was die (angemessene) Höhe von Honoraren angeht, werde ich hier nicht darstellen. Das wäre ein zu frustrierendes Leseerlebnis.

Die Ringvorlesung musste zudem irgendwie curricular eingebunden, das heißt „prüfungsrelevant“ für die Studierenden werden, um auch andere Motive für einen Besuch der Vorlesung zu bieten. Dafür bot es sich an, mit dem Team des kombinatorischen Bachelors zu sprechen, das die Vorlesung in das Modul für „Digitale Kompetenz“ integrieren konnte. Das Modul eignet sich gut für die Angebote, die wir als Lehrstuhl für Digital Humanities machen, und bietet mir die Möglichkeit, neben der Vorlesung auch Übungen anzubieten, die sehr praxis- und projektorientiert sind. Bisher hatte ich dabei das Problem, dass ich entweder auf die intrinsische Motivation von Studierenden setzen oder nur sehr kleine Projekte umsetzen lassen konnte. Mit dem Modul bzw. den Möglichkeiten, darüber „Leistungspunkte“ erwerben zu können. Ein bisschen desillusionierend war allerdings, dass daraufhin die Anmeldezahlen von 15 auf fast 100 Teilnehmer*innen stieg.  

Mit dem schon oben erwähnten Career Service hatte ich sowieso unbedingt sprechen, weil ich weder beabsichtigte, dass sich Angebote gegenseitig kannibalisieren, noch das ich solche übersehe oder ich schlicht meine Zuständigkeiten überschreite. Irgendwann meldete sich dann das Qualitätsmanagement für Studium und Lehre bei mir, um Aktivitäten dieser Art mehr zu vernetzen, man habe von meiner Vorlesung gehört. Gleichzeitig bekam ich über Twitter von dem sich neu formenden Netzwerk beruf:geschichte mit und engagierte mich dort. So entstand der gemeinsame Plan, unsere Veranstaltungen auch für Studierende anderer Universitäten zu öffnen.

https://twitter.com/matzke_judith/status/1499001054389846022

Hybridität

Anders als die Uni Köln sollten in Wuppertal auf Bitte des Rektorats größere Lehrveranstaltungen ab 60 Teilnehmenden auch in einem zusätzlichem „asynchronen digitalen Format“ angeboten werden. „Neue, bessere und einfach bedienbare Technik [sei] verfügbar“.

Eigentlich lassen solche Ankündigungen auch nur Raum für böse Vorahnungen Dementsprechend habe ich lange einem passenden Hörsaal suchen lassen und mir die Medientechnik des ZIM, unserem „Zentrum für Informations- und Medienverarbeitung“, kommen lassen, diese aber zu früh wieder gehen lassen. Es kam also wegen technischer Schwierigkeiten, wie die Deutsche Bahn es ausdrücken würde, zu „Verzögerungen im Betriebsablauf“.

https://twitter.com/DerGuenther/status/1514653646021144582

Übung macht den Meister: In der zweiten Veranstaltung lief es dann aber perfekt. Das ZIM reagierte auf Twitter und die Mitarbeitenden zeigten sich äußerst hilfsbereit.  Mit dem hybriden Format war mir allerdings auch klar, dass ich dringend Unterstützung in der Moderation benötigen würde. Diese bekam und bekomme ich durch die sehr engagierte Fachschaft Geschichte, worüber ich sehr glücklich bin

Leere

Während in der ersten Sitzung der Hörsaal ziemlich voll war und auch einige via Zoom zugeschaltet war, drehte sich das Verhältnis in den bisherigen Sitzungen. Plötzlich war der Hörsaal gähnend leer und nur ein paar Studierende hatten sich auf Zoom eingeklinkt.
Woran es liegt, kann ich noch nicht einschätzen. Sicher ist, dass ich einen fatalen Fehler gemacht habe, den „Scheinstudierenden“ mitzuteilen, nur drei Vorlesungstermine seien prüfungsrelevant. Wahrscheinlich ist es aber auch sehr verlockend, sich einfach Zuhause *irgendwann* einen nebenbei Vortrag anhören zu können.

https://twitter.com/DerGuenther/status/1519563323355840513?s=20&t=WtMuTmBqTAhZ79lQ2GjiAA

Das Programm

Jeweils Donnerstags von 16:00-18:00 Uhr (st).

Anmeldung via Zoom:
Registrieren Sie sich bitte für das Datum und die Uhrzeit, die Ihnen am besten passen:
https://uni-wuppertal.zoom.us/webinar/register/WN_nVrhMIytQcC0-f-ZCGdL_g

oder analog: Raum L.09.28 (Hörsaal 12)

Es ist nie zu früh für die DHd

Die DHd2022 aus der Sicht einer Studierenden

Jana Klinger

Die 8. Jahrestagung des Verbands „Digital Humanities im deutschsprachigen Raum“ (kurz: DHd2022) fand dieses Jahr vom 7.-11. März statt. Thema der diesjährigen DHd waren die „Kulturen des Digitalen Gedächtnisses“. Die Beitragenden näherten sich diesem Thema aus verschiedenen Blickwinkeln in dem von den ausrichtenden Institutionen, der Universität Potsdam und der Fachhochschule Potsdam, geschaffenen Rahmen. Die ursprünglich für das Jahr 2021 geplante Tagung wurde auf das Jahr 2022 verschoben, um die Tagung vor Ort in Potsdam in Präsenz durchführen zu können. Lange wurde für das Jahr 2022 mit einem Präsenzszenario geplant, doch Ende Januar 2022 fiel dann die Entscheidung, die Tagung in den virtuellen Raum zu verlegen.

Da die DHd in diesem Jahr als Präsenzveranstaltung geplant war, wurde Studierenden, Promovierenden und Post-Docs die Möglichkeit gegeben, sich um verschiedene Reisestipendien zu bewerben, die eine Teilnahme an der Tagung in Potsdam ermöglichen sollten. Ich war an einer Teilnahme an der DHd2022 sehr interessiert, da ich während meines Studiums der Fächer Geschichte und Anglistik in Wuppertal die Digital Humanities für mich entdeckt habe. Daher habe ich mich ohne zu zögern auf eines der Reisestipendien für Studierende beworben.

Mit Erfolg! An dieser Stelle möchte ich den Förderern der Reisestipendien für Studierende, der „NFDI4Culture“, dem Verein „Geistes- und kulturwissenschaftliche Forschungsinfrastrukturen“ und dem Verband „Digital Humanities im deutschsprachigen Raum e.V.“, herzlich für die Möglichkeit danken, an der DHd2022 teilzunehmen. Zwar ist eine Erstattung meiner Reisekosten zur DHd2022 nach der Umstellung vom Präsenz- auf ein Online-Format nicht mehr nötig, aber stattdessen wird nun Anfang Juli ein Barcamp für alle Stipendiat:innen in Potsdam stattfinden, in dem wir gemeinsam unsere Erlebnisse auf der DHd2022 reflektieren können. Ich freue mich darauf!

Was macht man eigentlich auf einer Tagung?

Diese Frage habe ich mir im Vorfeld der DHd2022 gestellt, da ich bislang noch nicht an einem ähnlichen Veranstaltungsformat teilgenommen hatte. Für die DHd2022 kann ich diese Frage nun beantworten. Das Programm war sehr vielfältig: Workshops, Panels, Vorträge und ein (zurecht legendärer) DHd-Posterslam[1]! Gerahmt wurde das Ganze von einer Eröffnungs- und einer Abschlusskeynote. Während Plätze in den Workshops im Vorfeld gebucht werden mussten, konnten die anderen Veranstaltungsformate im Laufe der Woche spontan besucht werden. Bei den Workshops stand das Machen und Ausprobieren von DH-Tools und -Methoden im Vordergrund, während in den anderen Formaten Forschungsarbeiten präsentiert und diskutiert wurden.

Als Raum für soziale Interaktion während einer Tagung im Online-Format wurde eine eigens für die DHd2022 kreierte Welt bei gather.town zur Verfügung gestellt. Diese bestand aus einigen Sehenswürdigkeiten Potsdams (z.B. Schloss Sanssouci), ergänzt durch fiktive Orte wie den allseits beliebten Strand, an denen man Leute treffen und networken konnte. In dieser Gather-Welt fanden auch zahlreiche Ereignisse statt, wie zum Beispiel virtuelle Museumsführungen oder die Postersession am Donnerstag, in der man sich die eingereichten Poster ansehen und mit den Autor:innen austauschen konnte. Die täglich vom Organisationsteam verschickten Morgen-Mails boten Orientierung im Termin-Dschungel. So behielt man den Überblick über die vielen Veranstaltungen und hatte im Laufe des Tages für jedes Event den passenden Link parat. An dieser Stelle geht mein Dank an das Organisationsteam, das den reibungslosen Ablauf der Tagung im Remote-Modus garantierte und dafür sorgte, dass auch ohne Präsenz vor Ort die sozialen Aspekte der Tagung nicht zu kurz kamen.

Was habe ich eigentlich auf der DHd2022 gemacht?

Nach Abschluss der DHd2022 kann ich sagen: Ich habe sehr ereignisreiche Tage hinter mir! Mit den Workshops ist die Woche direkt intensiv gestartet. Meine Teilnahme am Workshop „Introduction to Docker“ hat mir Einblicke in die Funktionsweisen einer Software ermöglicht, die für mich bis dahin nur ein oft gehörtes Buzzword war. Auch der Besuch von Vorträgen zu Themen, die mit meinen Studienschwerpunkten nur eine geringe Schnittmenge haben, wie zum Beispiel die zur „Digitalen Filmwissenschaft“, haben mir neue Perspektiven auf digitale, geisteswissenschaftliche Forschung eröffnet. Input zu mir unbekannten Themenbereichen zu bekommen, hat mir ermöglicht meinen Horizont zu erweitern.

Darüber hinaus habe ich auch festgestellt, dass ich die Vorträge zu den Themen „Digitale Geschichtswissenschaft“ und „Digitale Editionen“ als besonders spannend empfunden habe. Mein Vorwissen in diesen Bereichen hat dazu geführt, dass ich den Beiträgen auf eine andere Art und Weise folgen konnte. Hier war mein Blick auf die vorgestellten Forschungsarbeiten geschulter und ich konnte sie in Relation zu anderen mir bekannten Forschungsprojekten setzen. Ich war in der Lage, mir gezielt Notizen zu machen und Fragen zu formulieren, die teilweise in der an die Vorträge anschließenden Diskussion geklärt werden konnten.

Einblicke in verschiedenste Forschungsvorhaben aus dem Feld der Digital Humanities zu bekommen, war für mich als Studierende ein besonders wichtiger Aspekt der DHd2022. Durch die Breite der vorgestellten Themen, vom Hobbyprojekt über Doktorarbeiten bis hin zu DFG- und Akademieprojekten, habe ich in der vergangenen Woche wichtige Eindrücke gewonnen. Wie der Arbeitsalltag von Geisteswissenschaftler:innen und Digital Humanists aussieht, kann ich mir nun sehr viel besser vorstellen. Vor diesem Hintergrund würde ich auch Studierenden in der Anfangsphase eines Studiums der (digitalen) Geisteswissenschaften, die sich nicht sicher sind, was man denn mit einem solchen Studium später beruflich machen kann, eine Teilnahme an der DHd empfehlen, da hier unbekannte Perspektiven aufgezeigt werden können.

Neben dem offiziellen Programm der DHd waren aber natürlich auch die persönlichen Begegnungen mit anderen (angehenden) Wissenschaftler:innen in der Gather-Welt ein großer Spaß. Hier konnte ich sowohl einige bekannte Gesichter wiedersehen, als auch neue Bekanntschaften knüpfen. Insgesamt war der Besuch der DHd2022 für mich also ein voller Erfolg und ich freue mich besonders darauf, beim Barcamp Anfang Juli die anderen Stipendiat:innen face2face kennenzulernen und mich mit ihnen auszutauschen. Anderen Studierenden mit einem Interesse an den Digital Humanities, die den Wissenschaftsbetrieb näher kennenlernen und erste Kontakte knüpfen wollen, kann ich die Teilnahme an einer der künftigen DHds nur ans Herz legen. Vielleicht sieht man sich ja vom 13.-17. März 2023 bei der neunten DHd in Trier und Luxemburg zum Thema „Open Humanities, Open Culture“!


[1] Beim DHd-Posterslam erhalten alle Einreichenden eines Posters (bei der DHd2022 waren es 60 Poster; 20 Poster haben beim Posterslam teilgenommen) die Möglichkeit ihr Poster in einem höchstens 60sekündigen Vortrag vorzustellen. Am Ende wird von den Zuschauer:innen das Gewinnerposter gekürt.

Lehre @DH-BUW // Hello World! Webtechnologien für Geisteswissenschaftler*innen // Wintersemester 2021/2022 (hybrid)

Nadine Sutor

Im vergangenen Wintersemester hat sich der Lehrstuhl für Digital Humanities am Standort Wuppertal dazu entschieden eine praktische Übung für interessierte Studierende aus allen geisteswissenschaftlichen Disziplinen anzubieten, die einen ersten Einblick in die drei gängigen Webtechnologien HTML, CSS und JavaScript lernen, oder diese überhaupt erst einmal verstehen erhalten wollen.

Anspruch und Ziel der Übung

Der Fokus der Veranstaltung lag auf dem Entwurf, der Entwicklung und der Gestaltung einer kleinen, aber feinen interaktiven Webanwendung. Diese drei Stufen gliederten die alle zwei Wochen abgehaltene Übung und bildeten einen Workflow ab, in dem die jeweils passende Technologie vorgestellt, erlernt, diskutiert und ausprobiert wurde. Angefangen von den Basics in HTML und CSS über JavaScript bis hin zu Design-Tools sollten die Studierenden einen Einblick in die Frontend-Webentwicklung bekommen und deren Grundfunktionen und Zusammenspiel kennenlernen. Ziel war es, ein allgemeines Grundverständnis für Sinn und Zweck sowie Bedeutung (abseits der „normalen“ Webentwicklung im Berufsfeld der IT) dieser Technologien mit Blick auf die Umsetzung primär geisteswissenschaftlicher Forschungsprojekte zu schaffen. Denn man weiß, dass jedes Interface, welches Informationen bereitstellt und mit seinen Nutzer*innen in Kontakt tritt, nicht nur funktionell und interaktiv, sondern auch „gut aussehen“ und optisch ansprechend sein sollte. Darüber hinaus muss es seinen Inhalten, dem bereits wissenschaftlich erschlossenen und digital aufbereiteten Kulturerbe, in seiner digitalen Präsentation gerecht werden.

Exkurs: Was ist ein „Backend“?

Der Fokus der Übung lag klar auf der Oberflächengestaltung der Webanwendung. Damit die Anwendung reibungslos funktioniert und erreichbar ist, muss klar sein, was „hinter den Kulissen“ passiert. Daher wurde in einem kleinen Exkurs das sogenannte Backend als technische Infrastruktur thematisiert. Stephan Makowski, Wissenschaftlicher Mitarbeiter in den Digital Humanities an der Bergischen Universität Wuppertal (BUW), erläuterte das Client-Server Prinzip am Beispiel unseres Lehrstuhl-Servers. Anschließend erklärte er, was es mit dem sogenannten OSI-Modell auf sich hat, welches einem „Schicht-Prinzip“ folgt und sowohl den Netzzugriff, die Verbindung, als auch die Kommunikation zwischen Client, z.B. einem Browser, und dem Webserver abbildet. Darüber hinaus diskutierten wir einige gängige Protokolle wie HTTP zur Übertragung von Daten auf der Anwendungsschicht über ein Rechnernetz und SSL, ein Netzwerkprotokoll zur sicheren Übertragung von Daten.

HTML und CSS: Basics der Frontend-Webentwicklung

Anhand der Frankfurter Postzeitung [1], eine der ersten und langlebigsten Zeitungen im Erscheinungszeitraum von 1615 bis 1866, ging es in den ersten Einheiten darum ein HTML-Grundgerüst für den Dokumentenaufbau zu entwickeln. Jede*r der Teilnehmer*innen sollte je eine der vierseitigen Ausgaben aus dem Jahrgang 1618 und 1619 auf Basis von HTML so aufbereiten, dass sich die Inhalte via CSS einfach layouten und gestalten ließen.

Interaktive Komponenten mit JavaScript

Um die Anwendung mit einigen dynamischen Komponenten auszustatten und auf diese Weise  zu erweitern, sollten gemeinsam einige leicht umsetzbare Features entwickelt werden: Die Implementierung eines Buttons für das automatisierte Highlighting bestimmter Textstellen, sowie das ein- und ausblenden des Faksimiles und/oder der Transkription. Wie beim Zusammenspiel von HTML und CSS ging es in dieser Einheit um eine ähnliche Frage: Wie beeinflusst JavaScript die Dokumentstruktur und wie lässt sich diese manipulieren? Sowohl den Theorieblock, als auch die hands-on Session leitete Lena Stahn, Wissenschaftliche Mitarbeiterin des Lehrstuhls und Teil des Akademieprojekts „Niklas-Luhmann Archiv“. Die Studierenden sollten in mehreren praktischen Einheiten lernen, wie sie das DOM, das Document Object Model, anreichern und auf diese Weise bestimmte Elemente interaktiv gestalten.

Einzelobjektdarstellung des Jahrgangs 1618, Ausgabe 9. Transkription und Digitalisat wurden mit HTML, CSS und JavaScript umgesetzt und visualisiert.

GitHub-Repository und Versionierung

Direkt zu Beginn der Übung ging es uns, abseits der praktischen Arbeit am Code, um die Vermittlung des Mehrwerts und der Notwendigkeit eines Versionskontrollprogramms. Nach Aufsetzen eines projekteigenen GitHub-Repositorys versionierten und aktualisierten die Studierenden ihre Daten nach Abschluss der produktiven Arbeit mit dem GitHub-Client. Auf diese Weise blieb jede Änderung stets nachvollziehbar. 

Mockup-Design mit Figma

Als Alternative beziehungsweise Vorstufe zur unmittelbaren produktiven Arbeit am Code haben wir uns das Design-Tool Figma angesehen. Eine detailliert getreu ausgearbeitete Vorlage, ein Entwurf, ein sogenannter Mockup, dient als Orientierung im Entwicklungsprozess der späteren Website. Die Ausarbeitung eines solchen Mockups ist ein gängiger Schritt im UI/UX-Design und soll den Entwickler*innen in Form eines vorgefertigten Prototyps als Unterstützung dienen, um von dem Ursprungsdesign nicht abzuweichen.

Mit Figma erstellter Entwurf einer Startseite für die digitale Präsentation der Frankfurter Postzeitung.

Fazit

Das eingeholte Feedback von den Studierenden fiel überwiegend positiv aus Es entstand der Eindruck, dass vor allem die JS-Komponente für viele eine neue Thematik darstellte. Denn HTML und CSS hat jede*r „irgendwo schon einmal gehört“. Für einige war der Einstieg und die anschließende Weiterentwicklung des Datenmodells schwieriger. Mit angeleiteten Übungen, der eigenständigen praktischen Arbeit am Nachmittag und einigen Wiederholungseinheiten versuchten wir, ausreichend Hilfestellung zu geben und jede*n dort abzuholen, wo er/sie feststeckte. Aufgrund der überschaubaren Teilnehmerzahl gelang uns eine gute Einzelbetreuung. Kritik wurde bezüglich des Umfangs der behandelten Technologien geäußert. Die Anzahl der Tools und Programme wirkte vereinzelt überfordert und nach Meinung einiger Teilnehmer*innen bliebt zu wenig Zeit für eine tiefergehende Einarbeitung. Eine Fortsetzung und/oder thematische Erweiterung der Übung ist vorstellbar und könnte durch ein regelmäßiges Angebot weitere interessierte Geisteswissenschaflter*innen anlocken. In Abwechslung zu den bis dato behandelten Frontend-Technologien wäre die Konzeption einer Veranstaltung denkbar, die sich ausschließlich auf das Backend beschränkt und beispielsweise die in den Digital Humanities relevanten Datenbanksysteme und Server behandelt – abhängig vom jeweiligen Forschungsinteresse.


[1] Link zu den Digitalen Sammlungen der ULB Bremen: https://brema.suub.uni-bremen.de/zeitungen17/periodical/titleinfo/934741 (03.03.2022)

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

Nadine Sutor, WissMa @DHBUW

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

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

Was ist TEI?

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

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

Die Quelle(n)

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

Modellierung: Metadaten und Textbereich

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

Erschließung und Publikation

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

Tools: ROMA und TEI-Publisher

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

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

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

Fazit und Ausblick

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

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


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

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

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

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

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

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

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

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

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

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

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.

Word validieren mit Schematron?

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

von Dr. Jennifer Bunselmeier

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

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

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

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

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

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


1. Viele Transformationsschritte  – viele Fehlerquellen


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

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

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

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

 


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

2. Formale vs. semantische Kodierung

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

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

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

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

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

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

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

Bei diesem Transformationsbeispiel werden verschiedene Formatinformationen ausgewertet:

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

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

3. Zu viele Freiheiten in Word

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

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

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

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

Möglichkeit A – Das Wordvalidierungstool Data2Check

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

Vielversprechend ist das Tool Data2Check.

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

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

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

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

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

Ein absolut empfehlenswertes Tool!

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

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

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

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

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

Die ersten Versuche sind sehr vielversprechend.

Beispiel Titelei – Struktur gut prüfbar

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

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

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

Beispiel Spracheinstellung und Sonderzeichen – Transformationsskripte entlasten

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

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

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

Beispiel Stringabfragen – Schematron um individuelle Funktionen erweiterbar

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

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


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

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

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

Ein Problem bleibt – zurück zum Oxygen

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

Lösung: Doch der Autormodus

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

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

Vision: Schematronfehlermeldungen in Word zurückspielen

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

Zwischenfazit zu Wordvalidierungstools

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

 

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

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