Die besonderen Herausforderungen multimodaler heterogener Daten- und Quellentypen an die Datenverwaltung. Ist eine Forschungsdaten-infrastruktur ohne eine Datenbank umsetzbar?

Das Forschungsvorhaben

In einem Kooperationsprojekt zwischen der Potsdamer Arbeitsstelle des Corpus Vitrearum Medii Aevi (CVMA) Deutschland an der Berlin-Brandenburgischen Akademie der Wissenschaften sowie dem Institut für Kunstwissenschaft der Technischen Universität Berlin wird die digitale Erschließung und Repräsentation der Nikolaikirche in Bad Wilsnack sowie der Quellen zur als “Wilsnackfahrt” bekannten Wallfahrt umgesetzt. Hierbei handelt es sich um ein interdisziplinäres Forschungsvorhaben aus den Bereichen Kunstgeschichte, Mediävistik, Digital Humanities (DH) und Informationswissenschaften. Verschiedene Forschende haben unterschiedliche Bedarfe an die Infrastruktur sowie die erzeugten digitalen Informationen und Dateien.

Die Kirche St. Nikolai in Bad Wilsnack ist auch als Wunderblutkirche bekannt und war seit Auffindung der drei “Wunderbluthostien” im Jahr 1383 ein zentraler Wallfahrtsort (Bednarz et al. 2010, 87–165; Kühne und Ziesack 2005, 9–18). Zahlreiche Quellen verschiedener Art belegen dies, als Stiftungen in Form von Glasmalereien und Ausstattungsstücken des Bauwerks oder als Überlieferungen wie Pilgerzeichen, Testamente und Ablässe. Schriftquellen liegen teilweise nur gedruckt oder nicht erschlossen in Archiven verschiedener nord- und mitteleuropäischer Länder vor und benötigen eine systematische Aufarbeitung. Überlieferungen sind zum Teil nicht sicher belegt und nur durch Verweise auf nicht mehr vorhandene Quellen bekannt. Das Bauwerk war aufgrund der politischen und religiösen Geschehnisse im Laufe der Jahrhunderte verschiedenen baulichen Veränderungen ausgesetzt. Neben umfangreichen Restaurierungsmaßnahmen wurden Ausstattungsstücke verändert, bewegt, entfernt oder gar – insbesondere während der Zeit der Reformation und durch verschiedene Eigentümerwechsel – zerstört (Bednarz et al. 2010, 88–92).

Datenbasis

Die Quellen der Wallfahrt bilden die Basis für die Datenerfassung und eine daraus erfolgende Repräsentation, z. B. auf Karten oder als 3D-Modell des Bauwerks sowie ausgewählter Ausstattung. Die Forschungsdateninfrastruktur, die aktuell entwickelt wird, muss einerseits mit heterogenen Inhalten der Quellen, andererseits auch mit verschiedenen Dateitypen umgehen. Neben Bilddateien als TIFF oder JPG sowie Regesten der Quellen, die in proprietären Office-Formaten erstellt und in ein menschen- und maschinenlesbares Format wie XML oder JSON konvertiert werden, entstehen ebenfalls 3D-Daten (Punktwolken, digitale Rekonstruktionen) in unterschiedlichen Formaten, z. B. OBJ oder PLY, und Koordinaten als GeoJSON für die Kartendarstellungen. Heterogene Dateitypen und verschiedene Informationsschichten in z. T. ungenauem bzw. ungesichertem Überlieferungsstatus werden zu einem multimodalen Datenmodell zusammengeführt. Das Bauwerk betreffende Informationen werden mit Ereignissen in Verbindung gebracht, um zu erfassen und abzufragen, was bspw. Akteure der damaligen Zeit gesehen haben könnten, als sie die Kirche St. Nikolai zu einem bestimmten Zeitpunkt betraten, welche Ausstattungsstücke wann sichtbar waren oder welche Routen Pilger zurückgelegt haben. Die digitalen Ressourcen werden auf einer von der Software getrennten Dateiebene wiederum mit Metadaten angereichert.

Forschungsdateninfrastruktur

Im Bereich des digitalen Kulturerbes gibt es nur wenige standardisierten Lösungen für digitale Infrastrukturen, auf die zurückgegriffen werden kann. Bekannte virtuelle Forschungsumgebungen sind MonArch und WissKI. MonArch ist jedoch für die Zwecke des Vorhabens nicht ausreichend, da es hier primär um Building Information Modeling für die Erfassung und semantische Annotation bauwerksbezogener Inhalte geht (AriInfoware 2022). WissKI ist eine Forschungsumgebung, die über das CMS Drupal Zugriff auf verschiedene Dateitypen bietet und mittels Datenmodell organisiert ist. Eine Repräsentation von Kartendarstellungen und eine Einbindung von 3D-Viewern ist möglich (Germanisches Nationalmuseum o. J.). Im Bereich des Digitalen Kulturerbes findet vor allem das CIDOC Conceptual Reference Model (CRM) für die Datenmodellierung Anwendung, da hiermit objektbezogene und ereigniszentrierte Informationen und ihre Eigenschaften modelliert werden können (Bekiari et al. 2022). So kann eine Nachnutzbarkeit bereits vorhandener aber auch der eigenen, zum Großteil noch zu erstellenden Daten gewährleistet werden. Eine Besonderheit stellt im Bereich der Kunstgeschichte und des Kulturerbes die Vermittlung von Beziehungen zwischen Informationen dar, die getroffene Aussagen über Objekte und Orte in Zusammenhang mit Akteuren und Ereignissen in einen Kontext setzen (Burrichter et al. 2021, 111f.). 

Eine Speicherung der Dateien erfolgt in einer durch das Projekt vorgegebenen Ordnerstruktur (Kontinent/Land/Bundesland/Stadt/Gebäude/Datentyp). Verschiedene Tools greifen auf die digitalen Ressourcen zu und die Datenschicht ist von der Software getrennt (Gerber 2022, 16–28). Für ihre Erschließung mit Metadaten aber auch für die Erfassung des Datenmodells wird derzeit der bereits in den beiden Arbeitsstellen des CVMA Deutschland verwendete CVMA Digitaler Ressourcen Manager (CVMA DRM) (Gerber und Fischer 2021) weiterentwickelt. In erster Linie wurde er für die Erschließung von digitalen Bilddateien konzipiert. Die Inhalte werden online über ein webbasiertes GUI auf Basis von Javascript aufgerufen und verarbeitet. Der Zugriff auf die Daten erfolgt über einen Webserver. Metadaten werden in einer der jeweiligen digitalen Ressource zugehörigen maschinen- und menschenlesbaren JSON-Datei gespeichert und perspektivisch in GitLab versioniert. Das zu annotierende Datenformat ist unerheblich, da sich die JSON-Dateien mit jedem Datentyp verknüpfen lassen, neben Bilddaten z. B. auch Textdateien, Daten der Punktwolken oder Koordinaten. Eine Zuordnung erfolgt über den Dateinamen und den persistenten Identifikator (PID). Die Metadateninformationen haben denselben Dateinamen wie die jeweils verschlagwortete Ressource, die Dateiendung .meta und sie werden in derselben Ordnerstruktur wie die durch sie beschriebenen Dateien abgelegt. Durch die Speicherung als JSON-Dateien werden zunächst nur die Metainformationen und stark herunter skalierte Bilder bzw. Vorschauansichten der Modelle geladen. Die großen, hochaufgelösten Daten sind für eine Anzeige explizit auszuwählen, so dass sich die Ladezeiten erheblich verkürzen. Die Konfiguration der Ansicht und des Metadatenschemas erfolgt ebenfalls über JSON-Dateien.

Die erschlossenen Inhalte der Quellen werden durch das Datenmodell organisiert und mittels verschiedener Viewer, u. a. Kompakkt für 3D-Modelle (Universität zu Köln 2018–2022), Digilib für Bilder (digilib Community 2001–2022) und das Chronotopische Tool für Kartendarstellungen (Fischer und Thomas 2021), repräsentiert. In diese Viewer können zudem weitere digitale Ressourcen, z. B. Bilder oder beschreibende Texte, eingebunden und mit den dort dargestellten Daten angezeigt, sowie die Inhalte mit zusätzlichen Informationen außerhalb der Metadaten annotiert werden. Ein einzelnes System müsste aufwendig angepasst oder es muss auf verschiedene Datenbanken zurückgegriffen werden, um die verschiedenen Dateitypen speichern zu können. Daher ist die Entwicklung einer Weboberfläche geplant, über die der Ressourcenmanager zur Erfassung und Recherche, aber auch die Tools zur Anzeige der Präsentationsschicht eingebunden und angezeigt werden. Bisher erfolgt ein Aufruf der jeweiligen Tools über verschiedene Links. Sie befinden sich bereits auf demselben Webserver und greifen auf denselben Datenbestand zu. Für die Regesten und Texte der Quellen muss zum Zeitpunkt des Abstracts noch eine Lösung gefunden werden.

Datenmodellierung

Über das Datenmodell werden die sehr heterogenen Informationen und Dateien inhaltlich organisiert und mittels automatisiert vergebener PID miteinander verknüpft. Dieser Prozess erfolgt manuell. Aus den Quellentexten entnommene Angaben zu Akteuren, Datierungen, Ereignissen, Objekten und Orten erhalten konkrete Bezeichnungen und bilden die Gruppe der Forschungsobjekte. Diese werden dann verschiedenen Kategorien des Datenmodells zugewiesen, z. B. St. Nikolai als Bauwerk der Klasse E18 Physical Object, Wilsnack als Stadt der Klasse E53 Place oder Bischöfe und Pilger als Personen der Klasse E39 Actor. Die Quelle liegt als digitale Ressource vor und wird mit Metadaten angereichert sowie den entsprechenden Forschungsobjekten zugewiesen. Der Quellentyp, wie Ablass, Testament, Urkunde, wird zusammen mit ihrem Fundort in den Metadaten erfasst. Es ist nicht ausreichend, das Datenmodell nur am Bauwerk oder an geographischen Informationen auszurichten, da heterogene Daten miteinander in Verbindung gebracht werden müssen und Informationen zu Bauwerk und Ereignissen beinhalten.

Derzeit orientiert sich das Modell an der Basisontologie von CIDOC CRM. Im Laufe der folgenden Projektphase wird in verschiedenen Unterontologien geprüft, welche Klassen und Eigenschaften zutreffend sein könnten, um bestimmte Angaben zu präzisieren. Hier erscheinen insbesondere CIDOC CRMba für archäologische Bauwerke (Ronzino et al. 2016), CRMdig für Herkunftsmetadaten (Doerr, Stead und Theodoridou 2016) sowie CRMgeo für räumlich-zeitliche Daten (Hiebel et al. 2015) als geeignet. Die Kategorien für die Erfassung der Forschungsobjekte entsprechen zu diesem Zeitpunkt hauptsächlich den High Level Classes, für die Hierarchisierung des Bauwerks werden bereits untergeordnete Klassen verwendet. Die Modellierung der Beziehungen zwischen den Forschungsobjekten dient deren Kontextualisierung und erfolgt unter Verwendung der den jeweiligen Klassen zugewiesenen Eigenschaften. Aus Gründen der Datenlogik lässt sich nicht jede Klasse mit jeder Eigenschaft verbinden. Eine feinere Granulierung erfolgt während des Fortschreitens des Projekts, da die Entwicklung des Datenmodells im Dialog mit den Erkenntnissen der Forschung erfolgt. Eine zu grobe oder kleinteilige Erfassung führt zu ungenauen oder zu geringen Informationen, die miteinander in Verbindung gebracht werden. Anpassungen werden im Projekt dokumentiert. Es besteht ebenfalls die Möglichkeit, ab Herbst 2022 das in der Weiterentwicklung befindliche Datenmodell für die semantische Annotation von 3D Artefakten der NFDI4Culture (Rossenova 2021) zu testen und für das Wilsnackprojekt anzupassen.

Die sehr heterogenen Forschungsobjekte erhalten bereits während des Erfassungsprozesses konkrete Bezeichnungen wie “Kirche St. Nikolai”, “Chor”, “Chorfenster I”, “Hostienwunder”, “1383”, “Hostienverbrennung”, “Johann Ellefeldt”, “1552”, u. s. w., so dass eine Zuordnung eindeutig ist. Nicht jedes Ausstattungsstück oder jeder Akteur der Zeit werden erfasst. Gemeinsam in der Projektgruppe erfolgt eine Priorisierung. Gleich benannte Forschungsobjekte, wie Säulen, nicht näher bezeichnete Altäre oder die Wunderbluthostien, werden nummeriert. Eine Dokumentation erfolgt in den Metadaten der zugehörigen digitalen Ressourcen und im Datenmodell. Das Bauwerk wird durch die Kategorien Bauwerk – Gebäudeteile – immobile und mobile Ausstattung hierarchisiert. Den Forschungsobjekten werden alle zugehörigen Informationen und Dateien – egal welchen Typs – zugewiesen, z. B. werden alle Fotografien, Bauberichte und entstehenden Modelle des Chors mit dem Forschungsobjekt “Chor” verknüpft. Jede erfasste Information, egal ob Forschungsobjekt oder Datei, erhält einen PID, so dass eine Eindeutigkeit gewährleistet ist. Die Zuweisung erfolgt händisch und kann korrigiert werden. Einzelscheiben der Montagen oder des Gesamtfensters können gruppiert werden, wenn sie dieselben Bewegungen im Raum durchlaufen. Eine Erfassung erfolgt jedoch für jedes Forschungsobjekt einzeln, da sie verschiedene Ereignisse durchlaufen haben und noch können.

Erschließung der Daten

Eine Annotation von digitalen Ressourcen mit Metadaten erfolgt auf der Dateiebene mit einer projekteigenen und sich in der Entwicklung befindlichen Spezifikation, die sich aus Gründen der Nachnutzbarkeit an bekannten und etablierten Standards orientiert. Der Erstentwurf verwendet das Austauschschema LIDO 1.1 (ICOM-CIDOC LIDO Working Group 2021), welches sich u. a. an CIDOC CRM, CDWA Lite (J. Paul Getty Trust 2006) und Spectrum (Collections Trust 2017) orientiert, sowie Elemente aus Dublin Core (DCMI 1995–2022, DCMI 2020). Bei LIDO handelt es sich um einen etablierten Standard für die (Meta-)Datenerfassung im Bereich des Digitalen Kulturerbes (Knaus, Stein und Kailus 2019, 12–15). Dieses Schema ist neben der Erfassung von Grafiken und Fotografien auch für Ausstattungsstücke geeignet (Knaus, Kailus und Stein 2022, 18–21). Die Spezifikation des Projekts wird im Hinblick auf die Annotation der zu erstellenden 3D-Modelle um für diese erforderliche Angaben erweitert. Hier erscheint der Standard CARARE 2.0 als geeignet, da technische Angaben (digitale Herkunftsmetadaten) und beschreibende Informationen für Gebäude, Artefakte und born-digital Objekte möglich sind (Fernie, Gavrilis und Angelis o. J.). Mit LIDO können Metadaten desselben Typs unter Zuweisung verschiedener Kategorien und Rollen erfasst werden, z. B. ob jemand an der Erstellung einer Ressource beteiligt war oder lediglich auf dieser abgebildet ist. Administrative, beschreibende und technische Metadaten werden abgedeckt. So können die Datei selbst aber auch ihr Erstellungsprozess beschrieben werden. Die Konfiguration des Metadatenschemas erfolgt ebenfalls über eine JSON-Datei. Anpassungen werden dokumentiert und versioniert. Um eine eindeutige Zuordnung zu Akteuren, Ereignissen, Orten oder auch eine zweifelsfreie Klassifizierung der Objekte zu ermöglichen, werden bereits etablierte Normdatenvokabulare, wie GND, Wikidata, Iconclass, Getty Art & Architecture Thesaurus oder Geonames, genutzt und die Identifier erfasst. Zudem gibt es Überlegungen, Normdaten im Rahmen der NFDI4Culture über Wikibase (Rossenova u. a. 2021) zu erfassen und als Linked Open Data in den Wissensgraphen (NFDI4Culture o. J.) einzuspeisen.