doi:10.58079/nl55

ConedaKOR-as-a-Service. Über Kontext, Komplexität und Komplikationen

tl;dr

Der DARIAH-DE-Workshop zu ConedaKOR – einem graphbasierten Datenbanksystem zur Verwaltung und Präsentation von Objektsammlungen – führte neben neuen Entwicklungen der schnittstellenstarken und modular aufgebauten Software über die Anwendungsfälle in der Kunstgeschichte und Maya-Forschung zu grundsätzlichen Fragen in der Software- und Infrastrukturentwicklung für die Forschung:
1. Komplexe Software ist nur für komplexe Projekte sinnvoll.
2. Die Abwicklung der Infrastruktur wird zur Pflicht.
3. Die Voraussetzungen für Software-as-a-Service in der Forschung fehlen noch.

Kontext

Auf Einladung des Digital Humanities Lab des Leibniz-Instituts für Europäische Geschichte (IEG) kamen am 12.02.2020 ein Dutzend interessierte Teilnehmer*innen zu einem ConedaKOR-Workshop in Mainz zusammen. ConedaKOR, kurz: KOR, das graphbasierte Datenbanksystem zur Verwaltung und Präsentation akademischer Objektsammlungen aus den bildbasierten Kultur- und Geisteswissenschaften wird über GitHub bereitgestellt, aber auch im Rahmen von DARIAH-DE als Software-as-a-Service-Dienst angeboten. DARIAH-DE fungierte auch als Ko-Gastgeber dieser Veranstaltung. Ziel dieses Workshops war es, Anwendende und Interessierte zusammenzubringen, gemeinsam neue Entwicklungen zu diskutieren und weitere Einsatzszenarien auszuloten. Die Präsentationen des Workshops sind frei verfügbar.

ConedaKOR: Genese, Entwicklung, Szenarien

Die Entwicklung des Datenbanksystems ConedaKOR begann Ende 2008 im Kunstgeschichtlichen Institut der Goethe-Universität Frankfurt, wo es als Reaktion auf die bis dato eingesetzte, aber hinsichtlich der Anforderungen nicht mehr ausreichende, Softwarelösung DILPS hervorging.
Schon Mitte 2009 wurde dann die erste produktive KOR-Instanz im Institut für Kunstgeschichte in Saarbrücken aufgesetzt und kurz darauf folgte mit der Frankfurter Instanz das „Heimatinstitut“ der Software, wo bis dato auch die größte KOR-Installation betrieben wird (mehr als 300.000 Entitäten/Knoten und 630.000 Beziehungen/Kanten im Datengraph). Heute wird ConedaKOR in rund einem Dutzend Institutionen und Forschungsvorhaben europaweit eingesetzt.

Der Untersuchungsgegenstand der Kunstgeschichte sind die Kunstwerke und ihr Kontext. Folglich zählen zu den fachspezifischen Forschungsdaten die digitalen Abbilder und ihre Metadaten. Für deren Verfügbarmachung und Verarbeitung (Archivierung, Verwaltung und Recherche) in einer gemeinsamen webbasierten Oberfläche wurde ConedaKOR konzeptuell als Graphdatenbanksystem entwickelt. Das Netzwerk aus virtuellen Entitäten und deren Verknüpfungen zueinander bildet im kunstgeschichtlichen Anwendungsfall das Beziehungsgeflecht zwischen Kunstwerken, Künstler*innen und anderen Personen, Sammlungen und Orten ab.

Die Integration einer Upper-Level-Ontologie in KOR eröffnet die Möglichkeit lokale Datenbestände interoperabel zu halten, ohne auf eine spezifische Modellierung zu verzichten. So kann z. B. die Ontologie des CIDOC-CRM integriert und das eigene Datenmodell darauf gemappt werden.^[1] In jüngster Zeit wurde bei der Weiterentwicklung auch ein besonderes Augenmerk auf die Nutzungsmöglichkeiten von Wikidata gelegt.^[2] Und so ist nach der Entwicklung einer Browser-Extension als Brücke für die Datenintegration jetzt auch ein „Wikidata-Lookup-service“ integraler Bestandteil der aktuellen KOR-Software. Die Funktionsweise und Anwendung ist in diesem kurzen YouTube-Clip nachzuvollziehen.

Blick unter die Motorhaube: Architektur, Schnittstellen und mehr

ConedaKOR kann einen Labeled-Property-Graph abbilden, d.h. Knoten und Kanten können mit Eigenschaften versehen werden. So können mehr Informationen übersichtlicher verwaltet werden als in einem Triple-basierten Graphen. „Unter der Haube“ von ConedaKOR läuft jedoch kein natives Graphdatenbanksystem: Die Entitäten, Eigenschaften und Relationen werden in einer MySQL/MariaDB verwaltet und die Ablage der Mediendateien erfolgt im Dateisystem. Die Web-Applikation läuft auf der Basis von Ruby on Rails und Riot.js. Die Ausgabe-Schnittstellen über JSON und Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) können durch verschiedene „Verbraucher“ genutzt werden, z. B. von dem verteilten Bildarchiv „prometheus“. Auch das IIIF-Framework ist integriert, wie dieser Clip veranschaulicht. Zusätzlich können die Daten oder Teilmengen in Instanzen von Elasticsearch und/oder Neo4j migriert werden.^[3] Die Grundlagen für die Entwicklung von ConedaKOR zu einem Service liegen im Zusammenspiel dieser modularen, serviceorientierten Softwarearchitektur und der Anschlussfähigkeit an dezentrale Dienste und offene Datenquellen wie eben Wikidata.^[4]

In seinem Workshop-Beitrag stellte Moritz Schepp, der Hauptentwickler von ConedaKOR, die Möglichkeiten der vorhandenen Datenschnittstellen vor, so z.B. den skriptbasierten Zugriff auf einen KOR-Server (Ruby und ActiveRecord), den „Spreadsheet-Import/Export“ und den Einsatz eigener Werkzeuge per APIs. In einer Live-Demonstration wurden über die JSON-Schnittstelle der Frankfurter ConedaKOR-Instanz alle Kunstwerke und die jeweiligen Datierungen extrahiert und auf dieser Datenbasis die Verteilung visualisiert – nachzuvollziehen im Jupyter Notebook der Session.

Betriebsmodelle und Erfahrungen

Serviceentwicklung in DARIAH-DE

Beim Einsatz komplexer Software stellt vor allem die laufende Administration der Serverumgebung mit Applikationsschicht als ein dauerhafter Betrieb eine große Herausforderung dar. Wenn es um eine Software handelt, die für einen spezifischen Forschungskontext entwickelt wurde, lag der Fokus der Entwicklung oftmals nicht auf einem automatisierten Deployment, flexibler Konfiguration und wartungsarmen Betrieb. Um die Qualität und das Potential dieser Forschungssoftware hinsichtlich einer Nachnutzung trotzdem ausnutzen können, wurde im Rahmen der Infrastrukturentwicklung in DARIAH-DE ein Verfahren entwickelt, Software als Services weiterzuentwickeln. Dieses Verfahren, der Service Lifecycle, beschreibt in mehreren Stufen die Kriterien und Vorgehensweisen für eine schrittweise Entwicklung einer Software zu einem Service.^[5] Dabei gewährleisten verschiedene Maßnahmen eine Qualitätssicherung und Operabilität der Software. ConedaKOR ist dabei die erste Software, die außerhalb des DARIAH-DE-Verbundes entstanden ist und mit diesem Verfahren zu einem Software-as-a-Service weiterentwickelt wurde.^[6]

ConedaKOR-as-a-Service im Projekt: „Textdatenbank und Wörterbuch des Klassischen Maya“

Im „Maya Image Archive“ veröffentlicht das Langzeitprojekt „Textdatenbank und Wörterbuch des Klassischen Maya“ durch das Projekt digitalisierte und erschlossene Fotografien von Objekten der klassischen Mayakultur aus (privaten) Forschungssammlungen. Das Maya-Bildarchiv nutzt hierfür ConedaKOR: Die Fotografien werden mit Metadaten der abgebildeten Objekten verknüpft, so dass ein Wissensnetzwerk entsteht.^[7] Katja Diederichs gab in ihrer Präsentation auf dem Workshop Einblicke in die Abläufe, darunter waren auch der über Skripte automatisierte Import von Daten aus Excel-Listen, die manuelle Fehlerkorrektur in der Webobefläche und die schnittstellenbasierte Lieferung der Daten in die Deutsche Digitale Bibliothek.

ConedaKOR-as-a-Service als Angebot: Aktueller Stand und Pläne bei DAASI International

Der DARIAH-DE-Partner DAASI International bietet ConedaKOR seit ca. 3 Jahren als Software-as-a-Service an und ist als GmbH in der Lage bundesweit (und international) Dienstleistungen anzubieten – anders als Infrastrukturverbünde wie DARIAH-DE, für die noch keine Rechtsform gefunden werden konnte.^[8] DAASI betreibt die Software auf DSGVO-konformen Cloud Ressourcen und ist neben der Einrichtung und Grundkonfguraton für den Betrieb von Server, Betriebsystem und Applikation verantwortlich. Die grundständige Beratung zum Dienst übernimmt das DH Lab am IEG Mainz, der 3rd Level Support wird vom Deutschen Forum für Kunstgeschichte Paris übernommen – beide Einrichtungen leisten damit einen Beitrag im Rahmen der DARIAH-DE Betriebsvereinbarung. Die Kosten für das Hosting einer ConedaKOR-Instanz lagen bisher bei ca. 1.500,– € per annum. DAASI International ist es inwzischen jedoch gelungen, durch den Einsatz von Docker-Containern die Kosten auf bis unter 1.000,– € p.a. zu senken. Damit liegen die Kosten für ein Hosting in einem ähnlichen Bereich wie Dokumentenserver, größere Wikis oder Informationssysteme – trotz der vergleichsweise kleinen Anzahl von Instanzen. Der Beitrag von Peter Gietz offenbarte neben den Fortschritten und Innovationen im Hosting jedoch auch den Umstand, dass die Kosten trotz der erreichten Reduktion für viele Lehrstühle angesichts schmaler Budgets nicht tragbar sind.

Auf Kosten der Komplexität

Die Diskussionen im Workshop pointierten zum einen die bisherigen Erfahrungen in der Entwicklung und Anwendung der Software, legten jedoch auch bisher noch ungelöste Probleme der Infrastrukturentwicklung offen:

1. Komplexe Forschungssoftware benötigt komplexe Forschungsprojekte
… und vice-versa. Die bisherigen Anwendungsfälle bestätigen das Einsatzgebiet von ConedaKOR: Verbundvorhaben, zu deren Kernaufgaben die Erschließung von (Bild-)Daten gehört und die neben der Erfassung auch die Repräsentation ihrer Objekte vorsehen, verfügen über Personalstärke, Ressourcen und Laufzeit, die den Einsatz eines komplexen Informationssystem notwendig und möglich zugleich machen. Das bedeutet im Umkehrschluss auch, dass kleine, kurzzeitige oder ressourcenarme Vorhaben von diesem Softwaretyp Abstand nehmen sollten. ConedaKOR ist keine Software für eine Nacht!

2. Auf Entwicklung folgt Abwicklung
Die Phasen von „Entwicklung“, „Nutzung“, „Betrieb“ und „Abwicklung“ müssen zum Projektverlauf passend aligniert werden und je nach Projekt muss dann auch die Abwicklung Teil des Projektes sein. So wurden im Editionsvorhaben Sandrart.net die Bilddaten über eine ConedaKOR-Instanz erfasst, während der Laufzeit in der Editionsplattform angezeigt und nach Projektende vollständig integriert, so dass die Editionsplattform nun unabhängig von der Erfassungsumgebung betrieben werden kann. Software kann auch als Forschungsinstrument dienen ohne zum dauerhaften Produkt zu werden. Abwicklung darf kein Tabu mehr sein!

3. Es ist (noch) nicht das Zeitalter der Dienste
Die Hostingkosten sind günstig. Wenn eine Webapplikation im Laufe von Jahren nur 10.000,– € Betriebskosten verursacht, ist dies nur ein Bruchteil der Produktionskosten (Personalkosten von Entwicklung und Inhaltserfassung). Trotzdem existiert derzeit kein standardisiertes Verfahren, das Hosting eines Informationssystems als Prdoukt eines Forschungsvorhaben zu realisieren. Der Fall ConedaKOR demonstriert, was notwendig wäre: Die modulare Softwarearchitektur erlaubte grundsätzlich ein Hosting durch Dritte, DARIAH-DE fungierte als Framework für die Weiterentwicklung zu einem Service, DAASI International kann durch ihre Rechtsform als Anbieter auftreten. Mit Blick auf die derzeitige Infrastrukturlandschaft finden sich jedoch noch keine dieser Voraussetzungen: Es fehlen Kriterien, Abläufe, Anbieter und Fördermodelle für Forschungssoftware als as-a-Service. Im Raum steht die Frage: „NFDI – übernehmen Sie?“

Die Teilnehmenden des DARIAH-DE-Workshops ConedaKOR in der Diskussion — Die Teilnehmenden im Austausch mit Mensch und Maschine

Referenzen

Vgl. Sven Peter: „Abbildung relationaler Daten auf die Ontologie des CIDOC CRM“, Heidelberg 2015, DOI: https://doi.org/10.11588/artdok.00003454. ↩︎
Thorsten Wübbena: „Wikidata: Nutzungsmöglichkeiten und Anwendungsbeispiele für den Bereich Digital Cultural Heritage“. Blog. DHd-Blog, 25. Februar 2018, https://dhd-blog.org/?p=9336. ↩︎
Ausführlicher bei Thorsten Wübbena, Moritz Schepp: „ConedaKOR“. DARIAH-DE WorkingPapers Nr. 30, Göttingen DARIAH-DE, 2019. urn:nbn:de:gbv:7-dariah-2019-2-9. ↩︎
Fabian Cremer und Thorsten Wübbena. „The next big thing will be a lot of small things – Serviceorientierung als Modell für die Infrastrukturlandschaft“. Blog. DHd-Blog, 18. September 2018, https://dhd-blog.org/?p=10480. ↩︎
DARIAH-DE: Report zur Aufnahme zukünftiger neuer Dienste (R 3.2.7), 29.02.2016, https://wiki.de.dariah.eu/download/attachments/14651583/R3.2.7.pdf. ↩︎
In einem Kooperationsprojekt des Deutschen Forums für Kunstgeschichte Paris (DFK Paris|http://dfk-paris.org/) mit DARIAH-DE wurde ConedaKOR als Software-as-a-Service-Angebot realisiert und kann durch (DAASI International|https://daasi.de/) als buchbarer Dienst angeboten werden, vgl.
Thorsten Wübbena. „ConedaKOR als ‚Software as a Service‘-Angebot bei DARIAH-DE“. Blog. DHd-Blog, 13. Oktober 2016, https://dhd-blog.org/?p=7268. ↩︎
Siehe Katja Diederichs und Christian Prager: „‚Maya Image Archive‘ online: digitales Bildarchiv für Mayahieroglyphen, -kunst und -architektur“, Blog. DHd-Blog, 31. August 2018, https://dhd-blog.org/?p=10411. ↩︎
Vgl. Peter Gietz und Heiko Hütter: „Der Aufbau einer nachhaltigen technischen Infrastruktur für die Geisteswissenschaften: Die DARIAH-DE eHumanities Infrastructure Service Unit (DeISU)“. In: Bibliothek Forschung und Praxis 40, Nr. 2 (2016): 244–249. https://doi.org/10.1515/bfp-2016-0029. ↩︎

Weiterführende Links

OpenEdition schlägt Ihnen vor, diesen Beitrag wie folgt zu zitieren:
Thorsten Wübbena (19. März 2020). ConedaKOR-as-a-Service. Über Kontext, Komplexität und Komplikationen. Digital Humanities Lab. Abgerufen am 13. September 2024 von https://doi.org/10.58079/nl55