Alles hat seine Zeit: Generische Softwareentwicklung und individuelle Projektanforderungen
https://zenodo.org/records/14943216
Einleitung1
Digital-Humanities-Projekte, in denen individuelle Software benötigt wird, und DH-Zentren, an denen generisch einsetzbare Forschungssoftware entwickelt wird, haben unterschiedliche Geschwindigkeiten. Beispielhaft anhand des konkreten Entwicklungsprojektes Intertextor, einem Tool zur Annotation und Analyse von Intertextualität, demonstriert der Beitrag das Spannungsfeld zwischen generischem Anspruch und individuell notwendigen Lösungen, die aus konkreten Projektanforderungen erwachsen. Wir diskutieren, inwieweit einerseits Elemente agilen Projektmanagements helfen können, wo andererseits aber dennoch projektspezifische Entwicklungen vorgenommen werden müssen, um Deadlines einhalten zu können.
Anspruch: Generische Softwareentwicklung
„Eine Zeit zum Lachen“: Sofern eine Forschungssoftware-Entwicklungsabteilung mit begrenzten Personalressourcen den dauerhaften Auftrag hat, für eine Vielzahl von Forschungsprojekten Software zu entwickeln, liegt es auf der Hand, entwickelte Softwarekomponenten möglichst häufig wiederzuverwenden (vgl. Krueger 1992).2 Der Grad der Wiederverwendbarkeit hängt wesentlich von zwei Faktoren ab: Die Heterogenität von Anforderungen aus Forschungsprojekten stellt den äußeren Faktor dar. Dem stehen als innerer Faktor die Entwicklungsstrategie bzw. -methoden des Software-Engineerings gegenüber. Da eine Entwicklungsabteilung auf den äußeren Faktor keinen Einfluss nehmen kann, kommt es darauf an, den inneren Faktor auf die äußeren Gegebenheiten optimal einzustellen: Die Priorisierung generischer Konzepte und Komponenten ist unsere Strategie, um Wiederverwendbarkeit gezielt zu erhöhen, statt sie dem Zufall projektspezifischer Entwicklung zu überlassen. Die zentrale Methode zu dieser Strategie liegt in der Identifikation gemeinsamer Aspekte aus der Vielzahl von vorgegebenen Anforderungen und in der daran anschließenden angemessenen Abstraktion überschneidender Bedarfe in geeignete Software- und Datenmodelle. Neben der Generizität ist eine Hauptherausforderung das Prinzip ‘data first’, mit dem die fundamentale Orientierung an Datenstandards einhergeht, also Daten, die in einer oder für eine generische Anwendung erzeugt werden und auch außerhalb dieser Anwendung prozessierbar sein müssen.
Der Intertextor steht am Standort Münster derzeit prototypisch für die Entwicklung einer generischen Software (vgl. https://uni.ms/intertextor), die einen Bedarf mehrerer Forschungsprojekte abzudecken beabsichtigt (von denen eines weiter unten näher erläutert wird): eine komplexe, webbasierte Forschungsplattform zur manuellen Erfassung und Erforschung von Intertextualität, in der Daten nach offenen Standards produziert werden. Intertextualität bezeichnet die Beziehung eines Textes zu anderen Texten, die durch Zitate, Anspielungen oder stilistische Ähnlichkeiten hergestellt wird (vgl. Pfister 1994). Verschiedene alternative Formen von Intertextualität sind denkbar, je nachdem, was man als intertextuelle Relation betrachtet: Kommentare, Interpretationen, Übersetzungen etc. Der Intertextualitätsbegriff lässt sich darüber hinaus dahingehend erweitern, dass nicht nur schriftsprachliche Texte als Objekte von Beziehungen berücksichtigt werden, sondern jegliche kulturellen Gegenstände, die intermodale Beziehungen untereinander eingehen können; darunter zählen etwa auch Bilder, Filme, Werbung, etc.
In umfangreichen Vorarbeiten haben wir verschieden ausgeprägte Intertextualitätstheorien untersucht und eine Intertextualitätsontologie herausgearbeitet, die wir in OWL formalisiert haben (vgl. Horstmann et al. 2023). Die Generizität zeigt sich darin, dass sich unterschiedliche Intertextualitätstheorien durch formale Erweiterung dieser Kernontologie modellieren lassen. Die Kernontologie setzt ihrerseits auf einen bestehenden W3C-Standard auf – das „Web Annotation Data Model“ (WADM) – womit die Nachnutzung dieser Ontologie in unterschiedlichen Softwareanwendungen zudem begünstigt wird.3
Innerhalb des Intertextors können intertextuelle Bezüge ontologiebasiert als strukturierte Annotationsdaten modelliert werden. Die Generizität des Intertextors besteht mithin in der Nutzung des generischen Datenmodells – allerdings nicht nur darin: Die textuellen Beziehungen sollen im Intertextor auf unterschiedlichen Ebenen hergestellt und in verschiedenen Formen dargestellt werden können (vgl. Horstmann et al. 2024). Eine in verschiedenen Projekten (etwa auch dem unten vorgestellten Ijob-Projekt) gewünschte Variante besteht in der synoptischen Darstellung zweier oder mehrerer Texte, in denen verschiedene Textpassagen hervorgehoben und mit einer Annotation versehen sind, welche die Art der Beziehung näher bestimmt. Einer solchen Benutzerschnittstelle, die das close reading im Blick hat, steht eine netzwerkartige Präsentationsform gegenüber, bei der Gesamttexte als Knoten und intertextuelle Beziehungen zwischen diesen als Kanten dargestellt werden und so eine Weise des distant readings ermöglichen. Zwischen den Polen der close- und distant-Präsentation sind verschiedene Zwischenstufen geplant.
So gut es klingt, generische Software zu haben, so vielfältig sind jedoch auch die Risiken, die mit ihrer Entwicklung verbunden sind. Das Projekt geht zum einen das Risiko ein, dass die Software nicht rechtzeitig fertig werden könnte, sondern z.B. erst zum Ende des Projekts oder gar danach. Zum anderen besteht projektseitig das Risiko der Priorisierung bei der Softwareentwicklung: Stehen die für das Projekt notwendigen und gewünschten Funktionen oben auf der Aufgabenliste der Entwickler*innen? An diese beiden Faktoren schließt sich eine weitere, nicht unerhebliche Unsicherheit an: Ist der Drittmittelgeber von der Realisierbarkeit der Software trotz etwaiger Risiken zu überzeugen? Für das DH-Zentrum besteht das Risiko, sich zu überheben. Dieses Risiko wird mit der Anzahl der Stakeholder an der Software naturgemäß größer. Auch das DH-Zentrum muss die Risiko-Einschätzung des Drittmittelgebers antizipieren, um abgelehnte Drittmittelanträge zu vermeiden.
Unter diesen Bedingungen ist die Entwicklung ausgereifter generischer Anwendungssoftware eher etwas Unwahrscheinliches. Dennoch gibt es Gründe, warum Forschungsprojekte und DH-Zentren die Risiken eingehen sollten.
Agiles Projektmanagement und Herausforderungen
„Eine Zeit zum Behalten und eine Zeit zum Wegwerfen“: Durch ihre „interdisziplinäre Ausrichtung stellen Projekte in den Digital Humanities höhere Ansprüche an Projektmanagement als andere Kooperationen innerhalb etablierter Fachkulturen, bei denen zumindest die fachlichen Perspektiven einheitlich sind und nur organisatorische Abstimmung benötigt wird“ (Kremer et al. 2024). In der Software-Entwicklung werden vor dem Hintergrund ähnlicher Anforderungen seit Jahren agile Verfahren (wie etwa Scrum) als „Framework für das Management komplexer Projekte“ (Wirdemann et al. 2022) eingesetzt. Dabei gibt agiles Projektmanagement „ein dreifaches Versprechen: ein Leistungsversprechen (alles wird schneller, innovativer und besser); ein Emanzipationsversprechen (die Arbeit wird autonomer, selbstbestimmter und bedarfsorientierter) und ein Entlastungsversprechen (statt überbordender Komplexität: Konzentration aufs Wesentliche)“ (Kremer et al. 2024). Projektmanagement wird mittlerweile einerseits als „integraler Bestandteil der modernen Wissensproduktion“ (Cremer et al. 2024) bezeichnet . Andererseits attestiert z.B. Allington (2013) den Digital Humanities eine Obsession mit Management und nennt sie daher „managerial humanities“. Neubert (2020, 65) resümiert: „doing digital research in the form of planned projects is nothing too new, however, the novelty lies in an unprecedented interdependence when collaborating with large numbers of researchers, librarians, research software engineers and other involved stakeholders.“ Von Kremer et al. (2024) stammt ein Vorschlag für eine an Forschungskontexte angepasste reduzierte Scrumvariante. Hintergrund ist die Erkenntnis, dass Forschungsprojekte, die in der Regel innerhalb des komplexen Regelwerks des öffentlichen Dienstes durchgeführt werden, nicht gewinnorientiert agieren und parallel zu Aufgaben in der Lehre, akademischen Selbstverwaltung und Fortbildung bzw. Vernetzung bearbeitet werden müssen, in ihrer spezifischen Struktur nicht für die vollständige Umsetzung der Scrum-Methodologie prädestiniert sind. Dennoch liegt es im Wesen der Agilität, Frameworks an den jeweiligen Anwendungskontext anzupassen. Kremer et al. konstatieren: „Gerade für Forschungsprojekte, die zum einen neues Wissen generieren, gleichzeitig aber in einer beschränkten Zeit einen nutzbaren Ertrag sicherstellen sollen, eignet sich agiles Projektmanagement gemäß der Grundidee eines fokussierten Teams und eines offenen Lösungswegs sehr gut“ (Kremer et al. 2024). Im pragmatischen Einsatz von SCRUM in Forschungsprojekten hat sich daher etabliert, Vorhandenes zu adaptieren und mit Versatzstücken zu arbeiten, d.h. etwa die Elemente Daily Meetings, Backlogs, Task Boards, Product Owner und Sprints einzusetzen. Freilich gibt es auch im akademischen Kontext starke Divergenzen, auf die ein agiler Entwicklungsmodus reagieren muss, z.B.: „Different disciplinary affiliations, as well as one’s position within the academic hierarchies may lead to different research cycles over time. While PhD and postdoctoral researchers have a clear time limit set by their temporary employment within the CRC, Principal Investigators and professors are limited through other tasks and research interests within their respective field” (Neubert 2020, 71f.).
Auch in der Intertextor-Entwicklung setzen wir Verfahren des agilen Projektmanagements mit mehr oder weniger Erfolg um. Das Scrum-Element des Daily Meetings haben wir auf höherer SCDH-Ebene, dort spielt der Intertextor (als ein Entwicklungsprojekt neben sehr vielen vom SCDH begleiteten Forschungsprojekten) nicht jedes Mal explizit eine Rolle. Statusmeetings (von Kremer et al. 2024 zweimal wöchentlich empfohlen) finden bei uns einmal wöchentlich mit explizitem und ein zweites Mal mit möglichem Intertextorbezug statt (in Anwesenheit des Product-Owners); zusätzlich haben wir ein wöchentliches Treffen von Scrummaster und Entwicklern. Der Scrummaster ist zusätzlich Systemarchitekt des SCDH und als solcher ebenfalls Stakeholder des Intertextors (neben den Forschungsprojekten, die konkrete methodische Anforderungen an das Tool haben). Wir haben ein Product-Backlog mit Userstorys und ein Sprint-Backlog (in Form priorisierter Userstorys), sodass inkrementorientiertes Arbeiten mit hoher Autonomie des Teams in den Arbeitsphasen möglich wird. Die große Herausforderung bleibt, die unterschiedlichen Geschwindigkeiten der Projektlogiken (s. beispielhaft u.) auf der einen und der dauerhaften generischen Lösungen auf der anderen Seite zu vereinen (vgl. auch Neubert 2020, 71f.). Kremer et al. (2024) betonen die gute Passung von Scrum zu Entwicklungsprojekten von Forschungssoftware-Prototypen. Die darin implizierte Schnellschussmetaphorik, die „Projektifizierung geisteswissenschaftlicher Forschung in kurzzeitige Einheiten“ (Cremer et al. 2024) könnte ein Grund sein, der einer langfristigen generischen Lösung, einem lauffähigen und dauerhaft durch eine Institution der Forschungsinfrastruktur betriebenen Forschungstool entgegensteht. Spezifische Bedarfe, die an das generische Tool gestellt werden, werden im Folgenden beispielhaft anhand eines der Stakeholderprojekte, dem Ijob-Projekt, illustriert.
Konkrete Projektbedarfe
Digitale Edition antiker Textzeugen des Ijob-buches mit Darstellung der Übersetzungsweise
„Eine Zeit zum Bauen”: Das Projekt einer digitalen Edition der antiken Textzeugen des Ijob-buches unter der Leitung von Prof. Dr. Johannes Schnocks möchte die aramäischen Übersetzungen, zwei fragmentarische Übersetzungen aus Qumran und den rabbinischen Targum ins Deutsche übersetzen und mit dem hebräischen Text vergleichen (vgl. DH-Blog 2023). Als „Kontrollgröße“ soll auch der griechische Text der Septuaginta hinzugezogen werden. In einer Synopse der ursprachlichen Texte und ihren deutschen Übersetzungen – das wäre in gedruckter Form eines Buches enorm unübersichtlich – macht die digitale Edition die Unterschiede sichtbar (vgl. dazu exemplarisch Schnocks 2018; zum Ijob-Buch und der Forschungsgeschichte Witte 2018). In Annotationen wird erklärt und kommentiert, wie die antiken Übersetzer gearbeitet haben. So wird die antike Übersetzungsweise deutlich herausgearbeitet: Wenn die antiken Versionen in ihrer bisweilen ja erstaunlichen Übersetzungsweise umfassender wahrgenommen werden, ergibt sich nicht nur eine größere Sicherheit in der Rekonstruktion der Textgeschichte, sondern es entstehen theologisch aufschlussreiche Einblicke in die frühe Rezeptionsgeschichte und die Intertextualitäten der biblischen Texte. In diesem Sinne handelt es sich beim Ijob-Projekt um eine Form von Intertextualität, die das synoptische Interface voraussetzt.
Bei diesem Projekt haben sich mit der Möglichkeit auf komplexe generische Anwendungen zu setzen von Beginn an die Chancen und Risiken abgezeichnet: Einerseits lagen die Vorarbeiten zum Datenmodell des Intertextors zu Beginn der (technischen) Vorbereitung des Projekts, Anfang 2023, bereits vor und damit das Versprechen einer generischen Web-Anwendung. Andererseits hat sich im Verlauf des Jahres abgezeichnet, dass eine schnelle Realisierung des Intertextors utopisch ist. Dennoch sollten noch vor Beantragung von Drittmitteln die wesentlichen technischen Komponenten zur Durchführung der Forschungsfrage vorliegen und ihr Funktionieren nachweisbar sein, um das Risiko aus Sicht des Drittmittelgebers und somit des Projekts zu minimieren. Diese wesentlichen Komponenten sind einerseits eine Möglichkeit zur kommentierenden und klassifizierenden Erfassung auffälliger Übersetzungsweisen und andererseits eine synoptische Anzeige der Verse mit Hervorhebung der auffälligen Text-Stellen; also Datenein- und -ausgabe. Zudem zeichnen sich konzeptuelle Spannungen zwischen dem generischen Intertextor und dem Projektvorhaben ab, insofern der Intertextor weniger dafür geeignet ist, die Forschung eines Projektes zu präsentieren, als vielmehr in einen globalen Graphen zu integrieren. Schon wegen der Open-World-Assumption der dem Intertextor zugrundegelegten Semantic-Web-Architektur ist seine Eignung zum Leistungsnachweis eines Forschungsprojekts fraglich. Nichtsdestotrotz ist die spätere Integration des Datenpakets des Projekts in den Intertextor wünschenswert, z.B. um in den Genuss der geplanten umfangreichen Abfragemöglichkeiten zu kommen.
Pragmatische Lösungen
„Eine Zeit für den Tanz”: Das Prinzip ‘data first’ stellt das verbindende Element der Entwicklung von projektspezifischen Lösungen und generischen Anwendungen dar. Für die generische Anwendung Intertextor impliziert das die Forderung, dass alle an der Nutzeroberfläche produzierten Daten Standards folgen und auch außerhalb der Anwendung prozessierbar sein müssen. Für die projektspezifische Lösung heißt das ebenfalls, dass Datenstandards befolgt werden müssen, um so letztlich den FAIR-Prinzipien nachzukommen und die Projektdaten nicht in Spezialsoftware einzuschließen ( lock in). Konkret hieß das für die projektspezifische Lösung, dass das Datenmodell von Beginn an analog zum Intertextor konzipiert worden ist. Das Prinzip data first ist somit auch Grundlage dafür, am SCDH die agile Software-Entwicklung übergreifend von den Einzelprojekten und ihren Speziallösungen bis hin zu generischen Anwendungen zu denken.
Eine Herausforderung war aber die Tatsache, dass es für Standoff-Annotationen nach dem Web Annotation Data Model (WADM), das zentral für die Annotationen im Intertextor sein wird, bislang kaum Implementierungen vorliegen, insbesondere keine, die gut in ein Projekt integrierbar sind, in welchem die annotierten Texte zur gleichen Zeit noch ediert, also verändert, werden. Wir haben daher nach einer Möglichkeit der Integration von WADM-Technologie in Editionsumgebungen gesucht; zudem sollte eine spätere Darstellung im Web möglich sein. Mit einer grundsätzlichen Trennung von Datenein- und -ausgabe war dies realisierbar. Sowohl die Texte, als auch die Standoff-Annotationen werden in TEI-XML erfasst. Standoff-Annotationen in TEI-XML sind bislang zu unrecht nicht sehr verbreitet: Mit dem Element <annotation> bietet TEI eine Struktur, welche die TEI-Referenz als analog zum WADM ansieht.4 Mit RDFa im TEI-XML zur Kodierung von Properties lassen sich Klassifizierungen einbauen, die verlustlos und ohne Konventionen RDF-konform sind. Eine projektspezifische Ontologie, die Klassen für Übersetzungsweisen definiert, schließt dazu an die Kernontologie des Intertextors an. Allerdings war eine zu den Selektoren des WADM analoge Struktur in TEI-XML eine offene Frage. Hier konnte nun Abhilfe geschaffen werden. Anlässlich des Projekts sind die in den TEI-Guidelines5 (und von der W3C) spezifizierten XPointer-Schemata implementiert worden, die wie die WADM-Selektoren ermöglichen, Fragmente, Bereiche zwischen Fragmenten oder Teile von Textknoten u.dgl.m. zu referenzieren (Lück et al. 2023).6 Eine Teilmenge der XPointer-Schemata ist kompatibel zu den WADM-Selektoren. Diese neu implementierte Softwarekomponente ist generisch; sie wurde nicht für das Projekt, sondern anlässlich des Projekts entwickelt. Auf diese Weise konnte der tatsächlich projektspezifische Code auf 330 Zeilen XSLT begrenzt werden, die zudem ohne Abstriche in anderen Projekten einsetzbar sind, welche WADM-kompatible Standoff-Annotationen in TEI erfassen wollen.
Aus Sicht des Intertextors mag die Entwicklung dieser Komponente ein Abweg sein. Aber sie war ein in ca. drei Wochen realisierbarer Baustein, der einen ansonsten sehr erprobten Technologie-Stack (TEI als Editionsplattform und X-Technologien) vervollständigt und für das Projekt einsetzbar macht. Und dieser hat seine Stärken: Unter Zuhilfenahme von <prefixDef> lassen sich Range-Pointer wie mt:12.5.2-6 (Masoreten-Text, Kapitel 12, Vers 5, Wörter 2 bis 6) schreiben. Wir haben damit eine Notationsweise, die Forschende aus dem Effeff beherrschen.
In diesem Projekt konnte der Anspruch, den Projektbedarf mit einer generischen Forschungsplattform abzudecken, vorerst nicht eingelöst werden. Dennoch ist klar ersichtlich, dass allein die Planung generischer Forschungsplattformen die Entwicklung von Software und Datenmodellen in Projekten strukturiert und einen übergreifenden agilen Prozess in Gang setzt. Er wird von Stakeholdern mit individuellen Projektanforderungen und nahenden Deadlines häufig mehr oder weniger wohlwollend zur Kenntnis genommen, aber nicht unbedingt aktiv unterstützt. Die eigenen Projektziele und engen Deadlines sind in individueller Perspektive stets sehr viel wichtiger als die Ausarbeitung gemeinsamer Ziele in Form generischer Userstorys.
Fußnoten
Bibliographie
- Allington, Daniel. 2013. „The managerial humanities; or, Why the digital humanities don’t exist.“ http://www.danielallington.net/2013/03/the-managerial-humanities-or-why-the-digital-humanities-dont-exist/ (zugegriffen: 16. Juli 2024).
- Cremer, Fabian, Swantje Dogunke, Anna Maria Neubert und Thorsten Wübbena. 2024. „Einleitung: Zusammenarbeit klug gestalten: Projektmanagement und Digital Humanities“. In Digital Humanities Research, hg. von Fabian Cremer, Swantje Dogunke, Anna Maria Neubert und Thorsten Wübbena, 7–20. Bielefeld: Bielefeld University Press / transcript Verlag. 10.14361/9783839469675-001.
- DH-Blog Universität Münster. 2023. „Die Steine umdrehen, um zu sehen, ob die Ameisen darunter immer noch so laufen…“ https://www.dh.uni-muenster.blog/die-steine-umdrehen-um-zu-sehen-ob-die-ameisen-darunter-immer-noch-so-laufen/ (zugegriffen: 22. Juli 2024).
- Horstmann, Jan, Christian Lück und Immanuel Normann. 2023. „Systems of Intertextuality: Towards a formalization of text relations for manual annotation and automated reasoning”. Digital Humanities Quarterly 17(3). http://digitalhumanities.org/dhq/vol/17/3/000731/000731.html (zugegriffen: 22. Juli 2024).
- Horstmann, Jan, Christian Lück, Immanuel Normann und Jan-Erik Stange. 2024. „Intertextor: Interfaces für die Annotation intertextueller Relationen“. DHd 2024 Quo Vadis DH (DHd2024), Passau. 10.5281/zenodo.10698496.
- Kremer, Dominik, Sabine Pfeiffer und Blake Byron Walker. 2024. „Effiziente Zusammenarbeit in den Digital Humanities: Ein Erfahrungsbericht aus drei Jahren Anwendung von Scrum in Forschungskontexten“. In Digital Humanities Research, hg. von Fabian Cremer, Swantje Dogunke, Anna Maria Neubert und Thorsten Wübbena, 153–184. Bielefeld: Bielefeld University Press / transcript Verlag. 10.14361/9783839469675-006.
- Lück, Christian, Ludger Hiepel und Johannes Schnocks. 2023. „TEI XPointer Schemes - Implementation and Example Application”, TEI Conference “Encoding Cultures”, Paderborn. https://teimec2023.uni-paderborn.de/contributions/134.html (zugegriffen: 22. Juli 2024).
- Krueger, Charles W.. 1992. „Software reuse”. ACM Computing Surveys 24(2), 131–183. 10.1145/130844.130856.
- Neubert, Anna. 2020. „Navigating Disciplinary Differences in (Digital) Research Projects Through Project Management“. In Digital Humanities Research, hg. von Silke Schwandt, 59–86. Bielefeld: Bielefeld University Press / transcript Verlag. 10.14361/9783839454190-003.
- Pfister, Manfred. 1994. „Intertextualität“. In Moderne Literatur in Grundbegriffen, hg. von Dieter Borchmeyer und Viktor Žmegac, 215–218. Berlin, Boston: de Gruyter. 10.1515/9783110925661.215.
- Schnocks, Johannes. 2018. „Ethische Bibellektüre als Gratwanderung. Auf der Suche nach der theologischen Autorität des Alten Testaments”. In Bibel und Moral - ethische und exegetische Zugänge (Jahrbuch für Moraltheologie 2), hg. von Christof Breitsameter, Stephan Goertz u.a., 11–30. Freiburg u.a.: Herder Verlag.
- Witte, Markus. 2018. Hiobs viele Gesichter. Studien zur Komposition, Tradition und frühen Rezeption des Hiobbuches (Forschungen zur Religion und Literatur des Alten und Neuen Testaments 267), 13–36. Göttingen: Vandenhoeck & Ruprecht. 10.13109/9783666552656.13.
- Wirdemann, Ralf, Astrid Ritscher und Johannes Mainusch. 2022. Scrum mit User Stories. 4., überarbeitete und erweiterte Auflage. München: Hanser. 10.3139/9783446474383.