Wofür das Digital in Digital Humanities wirklich steht

Am 27. Juni 2019 sprach Alexander Czmiel im Rahmen eines Gastvortrags an der Universität zu Köln darüber, warum er Softwarekenntnisse in den Geisteswissenschaften für unabdingbar hält und in welchem Umfang dieser hohe Anspruch von den deutschen Hochschulen bereits bedient wird: „Research Software Engineering in den Digital Humanities oder warum Programmierkenntnisse eine Kernkompetenz der DH sind“.

Den Einstieg ins Thema bildet ein kurzer Austausch auf Twitter, den Czmiel mit einer Kollegin hatte, die Quintessenz: Eine Stellenausschreibung für eine Digital Humanities / DH-Stelle ist keine Stellenausschreibung für eine DH-Stelle, wenn keine Programmierkenntnisse gefordert sind. Ein Statement, das aneckt, gerade im Hinblick darauf, dass die DH ein vergleichsweise recht neues Forschungsfeld sind, ihre Methoden noch nicht in vollem Umfang klar abgesteckt sind und nicht jeder wissenschaftliche Neuzugang sich bereits ein Programmierportfolio zusammengebaut hat. Dennoch, die These steht: DH ohne Programmieren ist nicht DH, so zieht es sich als roter Faden durch den Vortrag.

Unterfüttert werden diese Forderungen mit einer Studie anhand der Frage „Is Software important?“, die Czmiel im Kreise seiner Kollegen online durchführte. Die Antworten sind aufschlussreich. 92% der Befragten nutzen Software selbst in ihrer Forschungsarbeit, 69% halten sie für fundamental in Bezug auf (online) Ressourcen und 56% schreiben sie selbst. Forschung ist heute immer digital, so Czmiel, insofern seien die 56% zwar gut, aber noch zu wenig, denn potentiell finden sich in jedem Forschungsgebiet Probleme, die eine maßgeschneiderte Softwarelösung erfordern. Hier findet sich die Schnittstelle, in der die Digital Humanities ihre Kompetenz entfalten, die bedarfsorientierte Entwicklung von spezialisierter Software. Da dies jedoch meist projektbezogen geschieht, bleibt die entwickelte Software nach Abschluss des Projektes oftmals auf der Strecke. Das Problem dabei: Der Motor läuft nur, solange Forschungsgelder vorhanden sind. Sobald diese aufgebraucht sind und keine Finanzierung mehr besteht, muss das Projekt liegengelassen werden.

Die Infrastruktur

Eine passende Herangehensweise dafür ist bereits vorhanden, das Prinzip „Open Science“. Das meint vollumfängliche Transparenz in der Entwicklung und Nutzung von Software im wissenschaftlichen Kontext: offene Daten, Quellen, Methoden, Feedbackkanäle, Zugang und Bildung – das nicht-singuläre, sondern breit verfügbare Angebot von Technologien zur freien Nutzung in allen Bereichen. Open Science ist eine schöne Idee, die mit Open Source bereits erfolgreich durchgeführt wird und einen großen Zugewinn für jede Art des Datenaustauschs darstellt. Im Unterschied zum Vorbild lässt Open Science eine zentrale Fokussierung bislang allerdings vermissen. Der Regelfall ist zurzeit, dass eine Lösung, die mit geringer Modifikation an zwei unterschiedlichen Stellen großen Nutzen bringen würde, nicht selten zweimal separat voneinander entwickelt wird – mit dem zweifelhaften Erfolg, dass am Ende nicht ein umfängliches und komplett entwickeltes Tool zur Verfügung steht, sondern zwei kleine, die auf nur einen Verwendungszweck ausgerichtet sind und nach dem Ende des entsprechenden Forschungsprojekts schlimmstenfalls in der Schublade verschwinden. Hier fehlt eine Open Science Softwareökologie, die zunächst eine Übersicht über Bedarf und Angebot schafft, ähnliche Entwicklungsansätze zusammenführt und damit die vorhandenen Gelder und Kompetenzen in einer abgerundeten Infrastruktur verbindet. Projektorientierung, Nachnutzung und Nutzungsanalysen sind hier Schlagworte: jede Software, die doppelt entwickelt wird, ist ein Potential zum neuen Standardtool, das folgende Definitionungenutzt bleibt.

Abb.1: Die Fundamente von Open Science. Bild von Wikimedia: https://en.wikipedia.org/wiki/Open_science#/media/File:Open_Science_-_Prinzipien.png (Letzter Zugriff: 23.07.2019).

Nochmal von vorn: worum geht’s bei den DH?

Neben dieser organisatorischen Problematik steht der effektiven, stromlinienförmigen Arbeitsweise ein anderes Hindernis im Weg: die Selbstdefinition der Digital Humanities ist noch nicht abgeschlossen und die Teilnehmer und Rezipienten nicht konkret eingegrenzt. Die Antwort auf die Frage, was Digital Humanities denn schlussendlich sind, bleibt in einer räumlichen Sphäre, die ganze Begriffsgebiete umfasst, ohne sie auf Schlüsselbegriffe festzunageln. Czmiel durchstöberte für seinen Vortrag das Internet und fand dort u.a. folgende Definition:

„Digital Humanities erforschen computerbasierte Methoden für die Geisteswissenschaften. Ausgangspunkt ist dabei häufig die Digitalisierung des kulturellen Erbes (der Quellen geisteswissenschaftlicher Forschung) in Form von Text, Bild oder Objekten. Die so geschaffenen Daten werden computergestützt modelliert, analysiert und der Interpretation zugänglich gemacht. Computerbasierte Verfahren, Werkzeuge und Infrastrukturen zur Lösung geistes- und kulturwissenschaftlicher Fragestellungen werden in den Digital Humanities in Einklang mit den Fachwissenschaften wissenschaftstheoretisch fundiert, konzipiert, entwickelt, angewendet und kritisch reflektiert.“

​Auf den ersten Blick meint man, damit sei das Feld ganz gut abgedeckt, Czmiel aber weist darauf hin, dass die Entwicklung – anders als die Nutzung und Erforschung – von Software konkret keine Erwähnung findet. Natürlich kann dieser Aspekt bei gutmütigem Lesen in die Definition gedeutet werden, doch der Punkt bleibt, dass die Gewichtung nicht primär auf eine Weise ausgelegt wird, die Programmierkenntnisse als obligatorischen Teil der Ausbildung im Bereich der Digital Humanities bezeichnet.

Und wozu nun Software schreiben?

An diesem Punkt können wir uns fragen, warum denn diese Fähigkeiten eine so unumstößliche Voraussetzung für die Arbeit in den DH bilden. Schließlich gibt es im Zweifelsfall entweder eine Lösung aus der Wirtschaft oder – wie oben erwähnt – als Open Source, die nur ein wenig angepasst werden muss und bereits jegliche Zwecke erfüllt. Das mag durchaus stimmen, die Bibliotheken des Internets sind voll mit Templates und A​_pplikationen, die sich mit wenig Aufwand auf neue Nutzungsfelder ummünzen lassen, doch was in diesem Prozess verloren geht ist die Unabhängigkeit von externen Quellen. Czmiel argumentiert, dass Deutschland schon jetzt mit einem Bein den Standards hinterherhinkt, die andere Nationen an ihre Forschung und an ihre Software stellen. Beispiele zu finden ist nicht schwer, allein die großen Technologie-Universitäten aus den USA und Skandinavien beliefern die Welt mit kostenlosen Bildungsangeboten und Tools, mit denen sich jeder selbst das Programmieren beibringen kann – hier findet sich die wohlwollende Verbreitung von Wissen und Kompetenz. Allerdings ist es kritisch, sich angesichts dieses Angebots zurückzulehnen und anzunehmen, es sei doch alles da, denn das Gegenbeispiel der wirtschaftlichen Softwareentwicklung zeigt, wie schnell neue Technologien erfunden, patentiert und schlimmstenfalls monopolisiert werden, wenn niemand sich um eine Öffnung der harten Lizenzgrenzen bemüht. Fakt ist, dass Boden verloren geht, wenn man nicht mit einem Kompetenzaufbau in den eigenen Reihen der Programmierer dafür arbeitet, ihn für alle zugänglich zu halten. Open Science und die Digital Humanities bieten genau diese Chance.

Abb. 2: Eine Mindmap mit Chancen und Potentialen von Open Science. Bild von Dr. Aled Edwards: https://www.flickr.com/photos/gforsythe/29095589178 (Letzer Zugriff: 23.07.2019).

Fazit​

Es geht also um Bestrebungen zur IT-Bildung und Ausbildung. Die Mehrzahl der Fachbereiche freundet sich zum jetzigen Zeitpunkt mit den Schnittstellen zur IT an, da sie den Mehrwert und die zukünftigen Anwendungsfälle erkannt haben. Nicht jede Disziplin kann und soll zu einem technischen Mischstück ummodelliert werden, doch die Fähigkeiten, die für eine dynamische und flexible Reaktion auf neue technische Probleme notwendig sind, sollten gerade für die Geisteswissenschaften in erreichbarer Nähe sein. Die DH bieten diese Möglichkeiten, die mit einer Zentralisierung der Projekte und Kompetenzen voll ausgeschöpft werden könnten.

Zur Person: Alexander Czmiel ist für die Leitung des Digital Humanities Projekts TELOTA an der Berliner Akademie der Wissenschaften zuständig, koordiniert in einer Vielzahl von Forschungsprojekten die Bestrebungen zur Digitalisierung und ist in der deutschen Szene der Digital Humanities engagiert.

Zum Autor: Tim Schmude studiert Informationsverarbeitung im Master an der Universität zu Köln und beschäftigte sich im Bachelor vorwiegend mit Journalismus. Interdisziplinäre Schnittstellen ziehen sich als Thema durch seine wissenschaftlichen und publizistischen Arbeiten.


OpenEdition schlägt Ihnen vor, diesen Beitrag wie folgt zu zitieren:
dhstudi (28. August 2019). Wofür das Digital in Digital Humanities wirklich steht. Digital Humanities Cologne. Abgerufen am 13. Oktober 2024 von https://doi.org/10.58079/nkjh


Ein Gedanke zu „Wofür das Digital in Digital Humanities wirklich steht“

  1. Hallo,

    hier ein kleiner Kommentar von der o.g. Kollegin, die gerne den Austausch fortführen möchte. 🙂

    1. Diskussion im Rahmen der DHd: Im Panel “DH from Scratch” merkte ich an, dass ich die Anforderungen in DH-Stellenanzeigen manchmal seltsam finde, da spezielle Programmierkenntnisse verlangt werden, die man dann in der Ausübung der Stelle doch nicht braucht. Dies war ein kleiner Erfahrungsbericht, der anregen sollte, genau zu überdenken, ob man mit (nicht wirklich benötigten) Kenntnissen in Stellenanzeigen nicht geeignete Bewerber*innen ausschließt. Es geht nicht darum, KEINE Programmierkenntnisse in DH-Stellen zu erwarten. Sondern wenn, dann bitte die tatsächlich nötigen. Denn sonst schließt man passende Leute mit anderen (Programmier-)Kenntnissen aus.

    Der darauffolgende Tweet (“Wenn Programmierkenntnisse keine Rolle spielen, ist es keine DH-Stelle. #dhd2019”) war aus meiner Sicht in seiner Absolutheit etwas unglücklich, da er meine Kernaussage irgendwie nicht traf.

    Ich hätte sehr gern dort in diesem Raum mit all den klugen Leuten darüber weiter diskutiert, da ich die DHd genau als diesen Ort sehe. Leider hatte der Gesprächspartner nach Absenden des Tweets den Raum verlassen.

    Danke im Nachhinein für die beiden sehr klugen Tweets von Sybille Söring und Anne Baillot zu dem Thema. Ich bin immer noch beeindruckt von den Panel-Kolleg*innen, die es schafften, parallel vor Ort und auf Twitter zu diskutieren und so schnell umschalten konnten.

    2. Data Literacy
    Manchmal halte ich verschiedene Ebenen der Data Literacy für ebenso wichtig wie Programmierkenntnisse. Wir alle lieben Zahlen in Vorträgen, weil wir schnell eine genaue Vorstellung von Verteilungen (“92% der Befragten”) im Kopf unseres Publikums erzeugen können, die selten angezweifelt werden. Das ist sehr gut, da man nun anhand dieser Zahlen weitere Gedanken entwickeln kann. Ich hoffe nur sehr, dass für diese weiteren Gedanken nicht eine mir bekannte Befragung verwendet wurde. Die Anzahl der Befragten der gemeinten Untersuchung betrug 23 Wissenschaftler*innen an einer Bibliothek und lässt somit keine Aussagen über die Grundgesamtheit aller Geisteswissenschaftler*innen in Deutschland zu. Es kann sich natürlich aber auch um eine andere Befragung drehen, die mir bisher entgangen ist.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.