in diesem Blog Wikidata erklären zu wollen, würde wahrlich Q1373747 bedeuten. Daher will ich mich hier zu Beginn auf die Punkte beschränken, die mir entscheidend für die Beschäftigung mit Wikidata am Deutschen Forum für Kunstgeschichte Paris (DFK Paris) erscheinen.
Das Potenzial der frei bearbeitbaren, mehrsprachigen Wissensdatenbank Wikidata besteht nicht zuletzt darin, dass es nicht um Deutungen geht, vielmehr ist das Ziel, den Wissensstand zu einem definierten Zeitpunkt belegbar abzubilden. Das Modell von Wikidata weist eine enorme Flexibilität auf, ist entsprechend erweiterbar und die derzeit mehr als 50.000.000 Datensätze[1] stehen unter der CC0 1.0-Lizenz, womit sie frei von urheberrechtlichen und verwandten Schutzrechten sind. Neben der Lesbarkeit für Mensch und Maschine sind an den Objekten zahlreiche Identifikatoren aufgeführt, die in Datenbanken von externen Organisationen verwendet werden und – spätestens hier wird es für die Kunstgeschichte spannend – Wikidata führt mehr Kunstwerke auf, als z.B. die GND.
Ein Framework also, welches diverse Szenarien der Nachnutzung eröffnet – auch jenseits der Verwendung in Wikidata-Schwesterprojekten wie Wikipedia et al. – und vor dessen Hintergrund am DFK Paris der Gedanke aufkam, das oben beschriebene Potenzial für die eigenen Vorhaben zu nutzen.
Ausgangslage
Mit dem quelloffenen ConedaKOR[2] wird im DFK Paris eine graphbasierte Datenbanklösung genutzt, die das in der Fachwissenschaft relevante Beziehungsgeflecht zwischen Werken und ihren Kontexten abzubilden vermag. Die digitale Bildersammlung hat sich hierbei im Laufe der Zeit zu einer Wissensdatenbank und einem Instrument zur Vermittlung kunsthistorischer Kompetenzen weiterentwickelt. Die Software erfüllt in diesem Szenario sehr spezifische Anforderungen der kunsthistorischen Forschung, ohne jedoch als spezifische Anwendung konzipiert zu sein. Das Konzept einer modularen Softwarearchitektur erlaubt es, die Spezialisierung über Konfigurationsmöglichkeiten und einzelne kleinere Dienste zu erreichen. Das Datenmodell ist innerhalb der Applikation frei konfigurier- und erweiterbar, erlaubt sowohl die Kompatibilität mit einer Top-Level-Domäne (CIDOC CRM) als auch die lokale Ausprägung.[3] Ein rollen- und sammlungsbasiertes Rechtemanagement erlaubt hier die – in Verbundprojekten und institutsweiten Anwendungen so kritische – granulare Rechtekontrolle. Diese spezifische Konfiguration, Verwaltung und Betreuung (Datenmodellierung, Objekterschließung usw.) begründen das Bestehen und die Weiterentwicklung dieser lokalen Infrastrukturen als Komplement zu zentralen, generischen Werkzeugen oder Portalen.[4]
Überlegung
Aus der Beobachtung heraus, dass in vielen neu startenden, datenbankgestützten Projekten jedes Mal aufs Neue ein Grundstock bereits vorliegender Informationen angelegt wird (insbesondere Personen, Werke, Orte etc.), kann Wikidata eine Möglichkeit bieten, die begrenzten Ressourcen eines Projekts in die Erschließung neuer Informationen zu investieren. Aus demselben Grund kann sich der Einsatz von Wikidata als externe Datensammlung selbstverständlich auch für das Tagesgeschäft in kunsthistorischen Einrichtungen mit ihren zahlreichen Bilddatenbanken lohnen.
Es geht hierbei aber nicht nur um die einbahnstraßenhafte Nutzung der Daten aus Wikidata, denn die in den Instituten und Projekten erhobenen Informationen können auch wieder in den Wikidata-Bestand hineingeschrieben werden und kommen damit der Allgemeinheit, der Sichtbarkeit und dem Gedanken der Nachnutzung (= Nachhaltigkeit) zugute. Eine in der Tat verführerische Idee, wenn in der Kunstgeschichte nicht das zentrale Objekt der Untersuchung das Bild wäre, welches zugleich Gegenstand einer oft schwierigen Rechtelage ist. Und somit entsteht die Notwendigkeit, zumindest dort ein eigenes Repositorium für die Bilddaten zu betreiben, wo diese aus rechtlichen Gründen nicht gezeigt werden dürfen oder aus forschungsrelevanten Überlegungen heraus (z.B. bei Aufnahmen, die im Projektkontext noch auszuwerten sind) vorerst nicht gezeigt werden sollen. Aus diesem Dilemma heraus wurde daher am DFK Paris ein Workflow entwickelt, der die Verknüpfung lokaler Daten mit Wikidata ermöglicht.[5]
Umsetzung
Um diese angestrebte Kopplung bei größtmöglicher Kompatibilität und zugleich geringem Aufwand (Entwicklung und Anwendung) zu erreichen, wurde bei der Implementerung auf eine Browser-Erweiterung gesetzt. Verfügbar für Firefox und Chrome wird nach der Installation des Add-ons bei jedem Besuch einer Website nachgesehen, ob diese eine Wikidata-ID enthält[6]. Ist das der Fall, dann meldet die Extension, wenn eine korrespondierende Entität in der eigenen Datenbank vorhanden ist[7] und das a) Abbildungen dazu vorliegen, die bereits im Extension-Fenster als Vorschaubild erscheinen und im eigenen Repositorium angezeigt werden können oder b) es noch keine zugehörigen Abbildungen gibt und – falls verfügbar – nun ins eigene System hochgeladen werden können (s. Szenario 01 bzw. 02).
https://www.youtube.com/watch?v=A_lsGmYQF7w
Szenario 1
https://www.youtube.com/watch?v=QhfliHjsM9I
Szenario 2
Damit ist die Nutzung der Datenbasis in Wikidata möglich und die häufig rechtesensible Situation der Abbildungen wird bei diesem Vorgehen weiterhin im System der Nutzer*innen geklärt. Dieser Ablauf ermöglicht, dass neu erarbeitete Informationen, die in Wikidata abgelegt werden können, auch direkt dort hineingeschrieben werden. Damit erhält – wie oben bereits angedeutet – projektspezifisches kunsthistorisches Wissen Sichtbarkeit in Wikidata und kann darüber hinaus entsprechend nachgenutzt werden.
Konkret angewendet wurde dieses Vorgehen im DFK Paris zum Beispiel im Projekt „Wissenschaftliche Bearbeitung des Palais Beauharnais“, wo im Zusammenhang mit der Erstellung einer online recherchierbaren Version des vollständigen Inventars der Möbel, Bronzen, Gemälde und anderer Gegenstände des Palais Beauharnais zahlreiche Entitäten in Wikidata angelegt wurden[8].
Die Browser-Erweiterung ermöglicht aber auch die Übernahme von Wikidata-Inhalten in die eigene Datenbank. Wenn die zugehörige Entität einer entdeckten Wikidata-ID noch nicht im eigenen System vorhanden ist, bietet die Extension eine konfigurierbare Importmöglichkeit an (s. Szenario 03).
https://www.youtube.com/watch?v=lvvTN-6aYXw
Szenario 3
Bei diesem Import wird ferner nachgesehen, ob über Relationen zu verbindende Entitäten bereits in der eigenen Installation vorhanden sind und im positiven Fall werden diese Verbindungen zeitgleich angelegt. Im obigen Beispiel (Szenario 03) werden somit gleich Verknüpfungen zwischen dem Werk („Susanna and the Elders“), der aufbewahrenden Sammlung (Bayerische Staatsgemäldesammlungen) und dem Urheber (Albrecht Altdorfer) erzeugt.
Ausblick
Voraussetzung für das beschriebene Verfahren mit einer Forschungssoftware mit spezifischen Funktionalitäten und einem externen Datenbestand ist selbstverständlich die Bereitschaft, die Daten im Netz, in Wikidata, vorzuhalten, zu ergänzen und nicht mehr primär im eigenen Datenbanksystem. Damit ergeben sich – neben technisch zu berücksichtigenden Aspekten – natürlich Fragen, die u.a. die Redaktionshoheit betreffen. Welche neuen datenkuratorischen Wege sind zu gehen, welche Prozesse ergeben sich, wenn eine größere Gruppe an den Datensätzen mitschreibt? Hier könnte z.B. der in der Wikidata community diskutierte Ansatz der „signed statements“ interessant werden, womit Institutionen ihre Aussagen mit einem Label versehen könnten.[9]
Aber auch generell steht diese Kombination aus Forschungssoftware mit spezifischen Funktionalitäten, sowie einem externen Datenbestand, beispielhaft für eine flexible und wissenschaftsgetriebene Nutzung digitaler Infrastrukturen, deren Services sich bedarfsspezifisch zusammensetzen. Ein derart modularer Aufbau dürfte zukünftig wichtiger werden, als monolithische Virtuelle Forschungsumgebungen. Im Falle von Drittmittelprojekten ist allerdings noch zu diskutieren, wie erarbeitete Daten gegenüber der jeweiligen Förderinstitution klar ausgewiesen werden können, wenn diese Arbeit im großen Ganzen von Wikidata aufgegangen ist?
Sicher ist, dass – neben einem zweckmäßige(re)n Einsatz von Ressourcen – auf diesem Weg eine Reduzierung der isolierten Datenbestände einer Fachdomäne erfolgen kann, wie sie derzeit als Datensilos eben immer noch als (ein) Ergebnis von zeitlich begrenzten Vorhaben zurückbleiben und die Förderung des freien Zugangs zu den Kultur- und Forschungsdaten in maschinenlesbarer und standardisierter Form gestärkt werden kann.
——————————————-
[1] Siehe hierzu: https://www.wikidata.org/wiki/Wikidata:Statistics
[2] ConedaKOR: https://github.com/coneda/kor und https://coneda.net.
[3] Vgl. Sven Peter: Abbildung relationaler Daten auf die Ontologie des CIDOC CRM, 2015, DOI: https://doi.org/10.11588/artdok.00003454.
[4] Der technische Betrieb dieser webbasierten Anwendungen vor Ort erfordert Ressourcen und Kompetenzen, die vielen Projekten und Instituten nicht zur Verfügung stehen. Als Antwort auf dieses Szenario wurde ConedaKOR daher in Kooperation mit DARIAH-DE (https://de.dariah.eu/en/) zu einem „Software-as-a-Service“-Modell weiterentwickelt und steht als erste community-driven Software über DARIAH-DE zur Verfügung.
[5] In der Folge bezieht sich die Darstellung auf eine ConedaKOR-Installation, aber die hier beschriebene Erweiterung ließe sich auch für andere Datenbanksysteme entwickeln.
[6] Die Extension reagiert auf Wikidata-IDs einer Website – die nicht nur auf Wikidata-Seiten vorhanden sein müssen – und somit zum Beispiel auch beim Browsen auf Wikipedia.
[7] Dazu muss eine zugehörige Wikidata-ID im eigenen System abgelegt sein. Alternativ auch andere Identifier, über welche die Wikidata-IDs importiert werden können.
[8] Öffentlich zugängliche Online-Version des Katalogs unter: https://dfk-paris.org/de/WissenschaftlicheBearbeitungdesPalaisBeauharnais/Datenbank.html