Schafft Wissen. Seit 1502. Mit wenig viel erreichen Kreative Infrastruktur-Lösungen für große und kleine DH-Projekte 10. Nov. 2025 Bild: generiert mit Canva Jun.-Prof. Dr. Dennis Ried Akademie-Juniorprofessur für Musikwissenschaft mit Schwerpunkt Musikedition und Digital Humanities
→Studium der Germanistik & Musikwissenschaft, Karlsruhe •Hist. MuWi mit Schwerpunkt Interpretationsforschung →Promotion (2023) / Ruf (W1) nach Halle (2024) / Jun.-Prof. seit Jan. 2025 →Max-Reger-Werkausgabe (Max-Reger-Institut Karlsruhe), 2017–2021 •Hybrid-Edition, Akademieprojekt (AdW Mainz) →Hans Werner Henze-Briefausgabe (Uni Paderborn), 2021–2024 •Digitale Edition, DFG-Projekt →Gesellschaft für Musikforschung •Sprecher der Fachgruppe Digitale Musikwissenschaft →Music Encoding Initiative (MEI) •Chair der Metadata and Cataloging Interest Group Über mich
→Musikphilologie •Editionsphilologische Methodik (Schwerpunkt: Digitale Edition) •Edition von Musikerbriefen; Umgang mit „neuen“ Medien (20./21. Jhd.) •Vermittlung von Forschungsergebnissen •Forschungsportale/-software, Werkverzeichnisse, Multimediale Editionen →Digital Humanities •Datenmodellierung/Standardisierung (MEI) •XML-Datentransformationen (X-Tech) •Forschungsdatenmanagement (FDM) •Infrastruktur/Automatisierungen (CI/CD) in der MuWi/den DH •Nachnutzung von Forschungssoftware (Nachhaltigkeit) Wozu forsche ich?
→Was ist das? •gute Frage! •keine einheitliche Definition •disziplinäre und methodische Vielfalt →Was sind DH für mich? •Begegnung auf Augenhöhe über die Fächer hinweg •Interund Transdisziplinäre Arbeit ▪Theorie und Methodik unabhängig vom eigenen Fach entwickeln ▪Community, Kollektivintelligenz (jede*r trägt etwas bei!) →Wie verstehe ich mich? •Musikwissenschaftler mit digitaler Ausrichtung (DigMus/DigHum) Digital Humanities
„Digital Humanities sind eine Einladung zur Kollaboration.“
→Bekannte Beispiele •OxygenXML Frameworks •Ediarum Framework •TEI-Publisher •Github.com / Gitlab.com →Eigene Forschungsumgebungen (Projektbezogen) •Datenschemata •Forschungssoftware •Forschungsdaten(-management) Infrastruktur ist die Organisation der Informationen und die (technische) Verarbeitungsstruktur — „das, was ich zum Arbeiten brauche“ Infrastruktur(en)
→Aspekte der Organisation, Nachnutzbarkeit, Langlebigkeit •non-proprietäre Dateiformate (sofern möglich) •Versionsverwaltung statt „Abstract_final_final_druckfreigabe3.doc“ •„sich bewusst machen“ → hilfreiches Instrument: FDM-Plan →Fehlendes Management •chaotische (An-)Sammlung •schlechte bis gar keine Dokumentation •Ergebnis ist nicht nachhaltig und nur schwer nachnutzbar Forschungsdatenmanagement (FDM)
→Meine persönlichen Leitfragen im FDM •Was will ich erfassen/verarbeiten? •Was brauche ich für Tools, Technologien, Workflows usw.? •Was sind die richtigen Werkzeuge für mein Projekt? •Was steht mir zur Verfügung (z. B. Uni-eigene Gitlab-Instanz/Github)? •Wie kann ich effizient arbeiten? Forschungsdatenmanagement
→Issues (i. e. Tickets) [Bsp. Folie 10] •Aufgaben anlegen, kategoriesieren, diskutieren, abhaken •Vorteile: ▪Offener Issue = unerledigte Aufgabe ▪vernetzbar (Steuerung auch via git commit: „ref #60“ oder „fixes #60“) ▪Dokumentationsaspekt (für Releases, Projektberichte, Folgeprojekte) •„Nachteil“: Immer einem Repository zugeordnet (Empfehlung: Eigenes Orga-Repository) →Milestones (i. e. Deadlines) [Bsp. Folie 11] •markieren ein (Teil-)Zeil (optimalerweise mit definiertem Enddatum) →Epics [Bsp. Folie 11] •Helfen auf Gruppenebene größere Zusammenhänge abzubilden •Datumsbereiche (Projektphasen) definierbar •Für (sehr) kleine Projekte: der Verwaltungsaufwand darf nicht höher sein als der Nutzen! Projektmanagement mit Gitlab
→Ideen •Alle arbeiten immer mit der selben Version •Niemand muss LaTeX installieren oder bedienen können →Ziele •Keine E-Mails mit „anbei der aktuelle Stand“ •Kein manueller Diff aus unterschiedlichen Versionen •Keine lokalen Abhängigkeiten, d. h. stabile Infrastruktur →Technologien •LaTeX (Docker) •Gitlab CI (yaml) Beispiel 1 – Konferenzband
Z. 15–18: kompilieren Z. 19–21: bereitstellen Aufbau: - image (Z. 6) - stages (Z. 8–10) - jobs (Z. 12–21/23–30) Automatisches Löschen von Pipelines unbedingt aktivieren! (viele Pipelines => viele Artefakte => jede Menge Datenmüll!) Z. 23–30: geht auch einfacher ;-) Konferenzband mit LaTeX
- Ergebnis als PDF - immer aktuell! - bei push neu generiert -“works on my machine” - But: always the same machine! -abrufbar über URL - DOI: 10.25366/2025.156 Konferenzband mit LaTeX {ID}
Beispiel 2 Datenabgleich mit dem Bibliothekskatalog (shell, Gitlab CI)
→Situation •Bestellung von Titeln für die Bibliothek (per Mail) •Organisation der Bestellungen via Zotero •manueller Abgleich mit OPAC, ob die Titel schon im Regal stehen →Ziele •Immer gleiche Vorgänge automatisieren •Zeit (und Nerven) sparen →Technologien •shell-script •Gitlab CI (yaml) Beispiel 2 – Datenabgleich
- Daten aus Zotero abrufen - Abgleich mit dem Bibliothekskatalog - Ergebnis ausgeben Datenabgleich
- Daten aus Zotero abrufen - Abgleich mit dem Bibliothekskatalog - Ergebnis ausgeben Datenabgleich
-Maskierte Variablen verwenden! Sonst sind Passwörter/Keys im Log der Pipeline sichtbar!! - Tipp: CI-Variablen erleichtern das Leben ungemein ☺ Datenabgleich
→Problem •OPAC hatte keine API; Daten aber über lobid.org (API) verfügbar →Lösung •„Ist es bei lobid nachgewiesen, dann steht es auch bei uns im Regal“ •Abfrage der ISBN in lobid -> Besitznachweise filtern →Ergebnis •CSV-Datei (Tabelle) mit den Ergebnissen des Abgleichs •Arbeitet nicht perfekt, aber spart etwa 50–75% der Zeit →Schedule: Montags 4:30 Uhr (Ergebnis liegt zu Dienstbeginn vor) →Workflow läuft seit Mitte 2024 stabil Beispiel 2 – Fazit
Beispiel 3 Henze-Digital (XSLT, Apache Ant, yarn, git, Gitlab CI/CD uvm.)
Beispiel 3b – XML-Daten Selektion hendi-data (Repo) select/collect XSLT restriction.xsl HenDi-datalatest.xar →Technologie •Apache ant für build-Workflow •XSLT für Datenmanipulation →Bereitstellung •Gitlab Package Registry •versch. Pakete (intern/öffentlich) Verschiedene Datenpakete für unterschiedliche Anwendungsfälle: intern: alle Inhalte extern: mit Schwärzungen
Beispiel 3c – HenDi-WebApp HenDiWebApplatest.xar HenDiWebApp Repo WeGAWebApp Repo Das Repo der WeGA-WebApp ist als git submodule eingebunden. HenDi-WebApp Mirror bei Github: https://github.com/HenzeDigital/HenDi-WebApp Vortrag zum Kompilieren der Software: https://doi.org/10.5281/zenodo.15006672 Artikel erscheint zeitnah in den ECEASST yarn
How to deploy Henze-Digital eigenes Repo, das sich alle Pakete zieht und nur das docker image bereitstellt
How to (really) deploy Henze-Digital
→Bedarfsorientiert vorgehen •Immer überlegen, was man wirklich braucht und was wirklich wichtig ist. →Klein beginnen •Die Infrastruktur wächst von alleine! •Eine kleine, aber hilfreiche Infrastruktur ist viel besser als keine! →Das hier vorgestellte lernt man nicht an einem Tag (in einem Monat) Fazit
„Infrastruktur ist was Du draus machst!“
[email protected] https://dennisried.de 0000-0001-5545-2088 @
[email protected] Jun.-Prof. Dr. Dennis Ried Akademieprofessur für Musikwissenschaft mit Schwerpunkt Musikedition und Digital Humanities Martin-Luther-Universität Halle-Wittenberg Philosophische Fakultät II Institut für Musik, Medienund Sprechwissenschaften Abteilung Musikwissenschaft Kleine Marktstraße 7, R. 107 06108 Halle(Saale) Tel.: +49 (0)345/55-24525 Mail:
[email protected] Web: https://dennisried.de ORCID: 0000-0001-5545-2088 Mastodon: @
[email protected]