Wikibase – taugt die Wikidata-Software zur Sammlungsdokumentation? (Teil 1)

Wikibase zur Erfassung von Universitätssammlungen?

In unserer Serie über Softwarelösungen, die für die digitale Dokumentation von Universitätssammlungen in Betracht kommen, wenden wir uns in diesem Blogpost mit Wikibase einem System zu, das in diesem Feld sicher nicht zu den naheliegendsten Lösungen zählt.

Wikibase und Wikidata

Wikibase ist die Software hinter Wikidata, dem datenorientierten Schwesterprojekt von Wikipedia, man könnte auch sagen: Wikibase ist Wikidata ohne Daten. Zur Erinnerung: Wikdata wurde geschaffen, um die in Wikipedia lexikalisch behandelten Gegenstände in Form strukturierter Daten zu dokumentieren. In einem Wikipedia-Artikel werden die Informationen über den behandelten Gegenstand in einem kollaborativ erstellten lexikografischen Text vermittelt, der immer in einer bestimmten Sprache verfasst ist, so dass in der Regel unzählige Sprachversionen vorliegen, die jeweils von Autor*innen der entsprechenden Sprachgemeinschaft verfasst wurden. Sie unterscheiden sich also nicht nur sprachlich, sondern auch inhaltlich. Wikidata extrahiert die darin enthaltenen Daten und Fakten, definiert sie sprachunabhängig als Entitäten mit einem eindeutigen Identifier und verknüpft sie in einem alle behandelten Gegenstände überspannenden Wissensnetz. Inzwischen ist Wikidata mehr als das Datenextrakt der Wikipedia: Jeder Wikipedia-Artikel hat eine korrespondierende Wikidata-Entität, aber es gibt viele Wikidata-Entitäten, die auf keinen Wikidata-Artikel verweisen.

Die in Wikidata dokumentierten Gegenstände sind selbstverständlich nur zu einem geringen Anteil Objekte, wie man sie in Sammlungen erwartet, sondern etwa auch Sachverhalte, Ereignisse, Personen, Orte, Begriffe, Theorien usw. Es sind aber in zunehmendem Maße auch Sammlungsobjekte in Wikidata vertreten, angefangen mit Hauptwerken der Kunst-, Kultur- und Wissenschaftsgeschichte, die einen eigenen Wikipedia-Artikel haben, bis hin zu einzelnen Objekten auch aus kleineren Sammlungen.

Knowledge Base, nicht Datenbank

Die Universalität von Wikidata spiegelt sich auch in der Selbstdefinition der zugrundeliegenden Software, also der Wikibase-Suite, wieder:

Wikibase is an open-source software suite for creating collaborative knowledge bases, opening the door to the Linked Open Data web.

https://wikiba.se

Das in diesem Claim angesprochene Konzept einer „knowledge base“ ist sehr viel weiter und generischer als das einer klassischen Datenbank. Die Software kann das Wissen zu beliebigen Entitäten in Form eines Knowledge Graphs, eines Netzwerks aufeinander bezogener Elementaraussagen, repräsentieren. Auf die physischen Objekte einer (Universitäts-)Sammlung und die sie beschreibenden Daten trifft das natürlich auch zu, nur drängt sich die Frage auf, ob Wikibase als maximal generisches System die spezifischen Anforderungen erfüllen kann, die sich bei der digitalen Sammlungsdokumentation ergeben.

Dass es dennoch sinnvoll erscheint, den Einsatz von Wikibase in Betracht zu ziehen, hat, das sei zur Orientierung vorweggeschickt, zwei Gründe: Erstens ist, zumindest im Bereich der Open-Source-Software, keine Lösung verfügbar, die dem Anforderungsprofil von Universitätssammlungen in allen Aspekten gerecht wird und sich als Standard aufdrängt. Man hat es bei der Software-Auswahl ohnehin mit schwierigen Abwägungen zu tun und wird Kompromisse eingehen müssen. Zweitens könnte die offene, wissensorientierte Struktur von Wikibase gerade für Universitätssammlungen interessant sein, bei denen die Sammlungsobjekte in besonderem Maße Wissensobjekte sind, da sie im Zusammenhang mit Forschung und Lehre gesammelt wurden und für Forschung und Lehre nutzbar gemacht werden sollen. Auch für die Erfassung von Sammlungen mit sehr unterschiedlichen Objekten mit einem einheitlichen System könnte Wikibase mit seiner offenen Struktur eine gute Lösung sein.

Die Installation

Wikibase ist eine Suite von Software-Komponenten (MediaWiki, WikibaseQueryService, QuickStatements mit API, Blazegraph), die erst im Zusammenspiel die gewünschte Funktionalität erbringen. Da dieses Paket in der Lage ist, das Wikidata-Projekt mit aktuell knapp 100 Millionen Entitäten[1] zu stemmen, kann man sich vorstellen, dass es sich um recht komplexe Komponenten handelt. Auch wenn die für die Installation notwendigen Schritte gut dokumentiert sind, braucht es schon eine gewisse Vertrautheit mit Softwaresystemen und der Serveradministration, um Wikibase zum Laufen zu bringen. Ein guter Startpunkt ist sicherlich die Option, Docker zu verwenden, wodurch die notwendige Konfiguration der Serverumgebung als Container gekapselt ist und automatisiert hergestellt wird. Für unsere Erprobungen haben wir diesen Weg gewählt. An einer Stelle musste allerdings die Konfigurationsdatei (docker-compose.yml) manuell angepasst werden, weil das Docker-Image fehlerhaft war.[2]

Das erste Datenobjekt in der Knowledge Base

Der Weg zum ersten Datenobjekt in einer neu aufgesetzten Wikibase ist denkbar einfach: Auf der Spezialseite „Ein neues Datenobjekt erstellen“ (Wikibase ist ein Wiki, die Struktur der Benutzeroberflächen folgt deshalb einer Seiten-Logik) steht eine schlichte Eingabemaske zur Verfügung. Man gibt dem Objekt (Entity) einen Namen, eine kurze Beschreibung und klickt auf den Button „Erstellen“.

Im Anschluss kann man über das neue Objekt beliebig viele Aussagen (Statements) treffen, die stets nach dem für die Graphen-Technologie fundamentalen Triple-Struktur aufgebaut sind: Subjekt – Prädikat – Objekt, wobei die Subjektstelle stets das angelegte Datenobjekt einnimmt, über das man das Statement trifft. Das Prädikat im Statement entspricht der Feldbezeichnung in einer klassischen, relationalen Datenbank, das Objekt dem Wert, den man für dieses Feld einträgt. Zu einem Prädikat können beliebig viele Werte eingetragen werden. Die Werte, also die Objektstelle des Tripels, sind entweder eine Referenz auf eine Entität in der eigenen Wikibase oder direkte Eintragungen. Für die Eigenschaft (Property, an der Prädikatstelle des Tripels) ist festgelegt, welche Datentypen hier möglich sind, etwa ein Texteintrag, ein kalendarisches Datum, eine Ortsangabe, eine URL (insgesamt gibt es aktuell zwölf Möglichkeiten). Jede Eigenschaft hat genau einen möglichen Datentyp.

Nachmodellieren einer klassischen Datenbank

Wie würde der Workflow aussehen, wenn man eine klassische relationale Datenbank in Wikibase imitieren möchte? Dort hat man typischerweise einen Feldkatalog, dem in einem Datenbankmanagementsystem die Felder der Eingabemaske(n) entsprechen und in exportierten Daten die Spaltentitel einer Datentabelle. Über Primär- und Fremdschlüssel können die Datensätze in unterschiedlichen Tabellen verknüpft werden, was die Datenbank relational macht und die Normalisierung der Daten ermöglicht.

Am folgenden Praxisbeispiel lässt sich die strukturelle Analogie zwischen relationaler Datenbank und Wikibase veranschaulichen. In der Objektdatenbank der Theaterhistorischen Sammlung der Freien Universität Berlin zum Nachlass der Bühnenbildnerfamilie Brandt ist zu einer Architekturzeichnung im verwendeten Datenbanksystem Omeka S (siehe unsere Review zu Omeka S) der folgende Eintrag zur Datierung vorgenommen worden:

In Wikibase könnte man diese Information wie folgt erfassen:

Um in diesem Sinne die Daten in einer gesamten relationalen Datenbank analog in Wikibase abzubilden, würde man also in Wikibase für jedes Feld im Feldkatalog eine Eigenschaft erstellen und den passenden Datentyp konfigurieren. Ist dies für den gesamten Feldkatalog geschehen, kann man die Daten eingeben. Statt Felder mit Werten auszufüllen, generiert man in Wikibase Statements mit den entsprechenden Eigenschaften.

Oberflächlich betrachtet erhält man so einen ähnlichen Datensatz wie nach dem Ausfüllen der Felder in einer relationalen Datenbank. Der größte Unterschied liegt im Workflow: Die gute alte Eingabemaske gibt mit ihre Formular-Logik einerseits Hinweise, welche Daten man zu dem Objekt erheben sollte, falls sie vorhanden sind, andererseits definiert sie auch grundsätzlich, welche Daten man eintragen kann und welche nicht, indem für die einen ein Feld vorhanden ist, für die anderen nicht.

In Wikibase ist man bei der Eingabe der Daten dagegen ganz auf sich gestellt. Nachdem das Datenobjekt angelegt wurde, produziert ein Klick auf „+ Aussage hinzufügen“ das immer gleiche Dialogfeld mit dem Eingabefeld für die Eigenschaft.

Man muss also wissen, welche Eigenschaften für die Erfassung des betreffenden Objekts vorgesehen sind. Die Suggest-Funktion des Eingabefeldes hilft einem, den genau richtigen Namen der Eigenschaft zu finden, aber das funktioniert nur, wenn man zumindest grob weiß, was man eingeben möchte und welche Eigenschaft dafür zu verwenden ist.

Die praktischen Schwierigkeiten, die durch die fehlende Eingabemasken entstehen, lassen sich leicht mildern: Man könnte z.B. für jeden Objekttyp ein Musterobjekt anlegen, bei dem zu allen vorgesehenen Eigenschaften (zur Not: fiktive) Werte eingetragen sind. Das schränkt die Freiheit aber nur regulatorisch ein, nicht technisch. Nichts hindert die Beabeiter*innen, etwa einer Planzeichnung ein Geburts- und ein Sterbedatum zu geben, wenn diese Eigenschaften (gedacht für Personen als Datenobjekte) vorhanden sind. Auch ist die Anzahl der Werte für eine Eigenschaft unbegrenzt, man könnte also auch drei Inventarnummern oder Signaturen eintragen. Ob sich durch diese hohen Freiheitsgrade Probleme hinsichtlich der Datenqualität ergeben, hängt von der Qualifikation und Sorgfalt der Bearbeiter*innen ab.

Zur nachträglichen Sicherung der Datenqualität steht mit EntitySchema eine mächtige Erweiterung zur Verfügung, die hier nur kurz erwähnt sei. EntitySchema ermittelt, ob vorhandene Datenobjekte den Anforderungen eines hinterlegten Datenmodells gerecht werden. Gegebenenfalls kann man Fehleingaben dann systematisch korrigieren. Es bleibt aber letztlich ein Workaround, da die Prüfung nicht bei der Eingabe erfolgt, sondern erst im Nachhinein.

Jenseits der Feldkataloge

Während die maximale Generizität und Offenheit von Wikibase im direkten Vergleich mit klassischen Objektdatenbanken problematisch erscheint, sind diese hohen Freiheitsgrade eine besondere Stärke, wenn Anforderungen an die Sammlungsdokumentation gestellt werden, die von klassischen Objektdatenbanken nicht oder nur mit Mühe erfüllt werden können.

Das könnte etwa der Fall sein, wenn

  • Kontext-Informationen eine große Rolle spielen
  • Objekte in der Sammlung und Objekte, die nicht zur Sammlung gehören, aber im Hinblick auf eine bestimmte, die Sammlungsobjekte betreffende wissenschaftliche Fragestellung relevant sind, gemeinsam in einer Knowledge Base erfasst werden sollen
  • die Eingliederung in den digitalen Wissensraum, die Verknüpfung mit externen Ressourcen, von wesentlicher Bedeutung sind
  • komplexe Beziehung zwischen den Objekten zu erfassen sind
  • die Sammlungsobjekte und/oder die Anforderungen an ihre Erfassung und Erschließung sehr unterschiedlich sind

Reizvoll erscheint auch die Überlegung, die Datenbank als einen sich ständig fortentwickelnden Organismus zu sehen, der sich den Anforderungen anpasst, die sich aus dem dokumentierenden Umgang mit den Sammlungsobjekten ergibt. Dann würde man zunächst relativ „freihändig“ erfassen und im Nachgang, etwa unter Verwendung von Tools wie EntitySchema, zum einen die erfassten Daten konsolidieren, zum anderen die Modellierung den sich abzeichnenden Anforderungen anpassen.

Tabula rasa

Löst man sich in diesem Sinne von der Perspektive, Wikibase in strikter Analogie zu einer klassischen relationalen Datenbank zu verwenden, und nutzt es als flexibles Werkzeug, das Wissen über die Sammlungsobjekte in einem Netzwerk an Elementaraussagen zu erfassen, ergeben sich freilich neue Herausforderungen.

Der Knackpunkt ist die Loslösung von einem inhaltlich vordefinierten Katalog an Eigenschaften. Technisch, also bezogen auf den konkreten Workflow der Dateneingabe, müssen die Eigenschaften vordefiniert sein. Ein Statement kann das betreffende Datenobjekt nur durch eine vorhandene Eigenschaft mit einem Wert oder einem weiteren Datenobjekt verknüpfen. Man kann allerdings in Wikibase ebenso leicht Eigenschaften anlegen, wie man Datenobjekte erzeugt. Dies kann auch on-the-fly geschehen, also nach Bedarf bei der Erfassung des Wissens über ein konkretes Objekt (in der Reihenfolge: Eigenschaft erzeugen, Statement mit dieser Eigenschaft anlegen). Hier liegt ein entscheidender Unterschied zur Arbeit in Wikidata. Dort sind für „normale“ Nutzer*innen die verfügbaren Eigenschaften bereits vorgegeben; aktuell sind es knapp 10.000.[3] Erweitert oder editiert werden diese Eigenschaften nicht von einzelnen Nutzer*innen, sondern in einem streng regulierten Prozess auf Ebene der Wikidata-Community. Das hat seinen guten Grund. Denn das Ändern oder gar Löschen von Properties ist hoch problematisch, da ja potenziell schon unzählige Statements existieren (könnten), die diese Eigenschaften verwenden, und zwar so, wie sie zum Zeitpunkt, als das betreffende Statement angelegt wurde, semantisch definiert waren.[4]

In der eigenen Knowledge Base hat man administrativ alle Freiheiten. Eine Eigenschaft ist so schnell angelegt wie ein Datenobjekt, ihre Semantik kann frei definiert werden. Dessen ungeachtet ist die Anforderung, dass Eigenschaften persistent sein müssen und ihre Verwendung deshalb sorgfältig geplant werden muss, in der eigenen Wikibase-Instanz ebenso relevant wie in Wikidata mit über 20.000 aktiven Nutzer*innen[5]. Und mit der Bindung an den Community-basierten Redaktionsprozess fällt die Crowd weg, die vielen Nutzerinnen und Nutzer, die sich in oft langwierigen Diskussionen kontinuierlich um den Aufbau eines tragfähigen Repertoires an Eigenschaften gekümmert haben.

Das Anlegen von Eigenschaften on-the-fly ist also technisch möglich, konzeptionell aber nur sinnvoll, wenn gewährleistet ist, dass die dabei getroffenen Festlegungen semantisch so überlegt und solide sind, dass die frisch geschaffene Eigenschaften langfristig verwendet werden können. Man darf davon ausgehen, dass es für sehr viele Sammlungen eine Überforderung darstellen würde, diese Abklärung beim Prozess der Datenerfassung in der erforderten Qualität mitlaufen zu lassen. Konkret hieße das: Zu dem gerade erfassten Sammlungsobjekt soll eine Aussage getroffen werden, für die noch keine passende Eigenschaft in der eigenen Wikibase-Instanz existiert. Also entwerfen wir ein solche Eigenschaft, diskutieren ihre semantische Definition im Team, legen sie, nachdem dieser Redaktionsprozess abgeschlossen ist, an und können dann die gewünschte Aussage treffen. Das erscheint mir schlicht unpraktikabel.

Offenheit durch Masse

Ein Ausweg wäre, mit einem vordefinierten Katalog an Eigenschaften zu arbeiten, der so umfassend ist, dass in der praktischen Arbeit jede relevante Aussage getroffen werden kann, bis auf wenige Ausnahmen, in denen man den Katalog ergänzt. Das wäre dann die Situation, in der sich ein*e „normale“ Wikidata-Nutzer*in befindet: in aller Regel findet man in den rund 10.000 Properties eine, die geeignet ist, das auszudrücken, was man über ein Objekt festhalten möchte.

Mit der Option, diesen Groß-Katalog selbst aufzubauen, muss man sich nicht lange aufhalten. Ein solches Unterfangen hätte in den meisten Fällen eine größere Dimension, als die geplante Datenerfassung selbst. Naheliegender ist die Orientierung an vorhandenen Vokabularen und Ontologien, beispielsweise an LIDO (oder dem umfassenderen CIDOC CRM), EAD, ABCD, GBIF usw. Hier ist die semantische Definition bereits erfolgt, sachgerecht und persistent. Braucht man für eine Aussage eine noch nicht vorhandene Eigenschaft, konsultiert man das betreffende Vokabular, findet die passende Eigenschaft und legt eine analoge Eigenschaft in Wikibase an. Zu bedenken ist allerdings, dass die Datenmodellierung in den verwendeten Vokabularen und Ontologien unter Umständen einer anderen Logik folgt als der Statement-Atomismus von Wikibase. Ein einfaches Beispiel: Für Sammlungen mit kulturhistorischen Objekten wäre das Austauschformat LIDO ein naheliegendes Referenz-Vokabular. Für eine Aussage, die den Urheber oder die Urheberin eines Objekts erfasst, findet sich in LIDO keine unmittelbare Entsprechung, denn LIDO ist ereignisbasiert. Ein Objekt ist mit einem Creation-Event verknüpft, dieses hat einen Actor in der Rolle des Creator. Natürlich lässt sich dieses Problem lösen, schließlich stammen viele über das Format LIDO ausgetauschte Daten aus relationalen Datenbanken, in denen es ein Feld „Urheber“ (o.ä.) gibt. Es sei mit diesem Beispiel nur angedeutet, dass die Anlehnung an externe Vokabulare und Ontologien nicht mit einem einfachen Nachschlagen auskommen wird, sondern die Übersetzung von einem Datenmodell in ein anderes mit sich bringt.

Anlehung an Wikidata

Die praktikabelste Lösung wäre nach meiner Einschätzung eine direkte Übernahme der Wikidata-Properties. In unserem Beispiel würde man einfach in Wikidata schauen, wie dort die Urheberschaft von Objekten erfasst ist. Man findet leicht die Property P170 Creator (Urheber). In der eigenen Wikibase legt man also eine Property mit dem Label „Urheber“ an, die natürlich eine ander P-Nummer als Identifier erhält (die eigene Instanz fängt bei 1 an und zählt einfach hoch), aber – wenn man dies als Konvention festlegt – genauso verwendet wird, wie in Wikidata. Ich sage bewusst: verwendet, denn stabil ist in Wikidata, wie bereits erwähnt, eher die implizite Semantik Verwendung als die explizite Definition der Eigenschaften.[6]

Ein praktikabler Workflow für eine Verwendung von Wikibase als Sammlungsdatenbank mit konsistenter Anlehnung an Wikidata könnte wie folgt aussehen:

1. Anlage eines Pools von Wikidata-Entities, die den Objekten in der eigenen Sammlung vergleichbar sind. Neben der Vergleichbarkeit sind wichtige Kriterien, dass zu diesen Objekten die gewünschten Statements angelegt wurden, und zwar unter Verwendung von Properties, die dem Usus bei Wikidata entsprechen. Diese Referenz-Entities sollten jederzeit leicht konsultierbar sein, z.B. indem man sie in einem Online-Manual verlinkt.

2. Bei der Dokumentation eines Sammlungsobjekts legt man die Statements analog zu diesen Beispielobjekten an.

3. Wenn dabei Konflikte auftreten – das eine Beispielobjekt verwendet die eine, das zweite die andere Eigenschaft – oder Fehlstellen identifiziert werden – kein Beispielobjekt hat ein passendes Statement – wird per Konvention eine Version als verbindlich festgelegt bzw. die Sammlung von Referenz-Entities ergänzt.

4. Zur nachträglichen Qualitätskontrolle kann man die bereits erwähnte Extension EntitySchema einsetzen.

Zwischenfazit

Wikibase bietet ein breites Spektrum an Möglichkeiten, Informationen zu den Objekten der eigenen Sammlung digital zu erfassen und das Wissen zu den Objekten semantisch differenziert und präzise abzubilden. Technisch gesehen steht mit Wikibase ein ausgereiftes, funktionsmächtiges Open-Source-Werkzeug zur Verfügung, dass durch die Verwendung beim Großprojekt Wikidata als sehr zukunftssicher und für alle denkbaren Szenarien skalierbar gelten kann.

Wer Wikibase in der Sammlungsdokumentation produktiv einsetzen möchte, wird allerdings um einen anspruchsvollen Planungsprozess nicht herumkommen: Wie reduziert man die maximalen Freiheitsgrade, die Wikibase bietet, auf ein Maß, das eine nachhaltige, semantisch konsistente Erfassung ermöglicht? Einige der möglichen Herangehensweisen haben wir hier vorgestellt.

Im kommenden 2. Teil unserer Wikibase-Review werden wir uns den eher praktischen Fragen der Datenerfassung und der Einbindung von Digitalisaten zuwenden.


[1] Die jeweils aktuelle Statistik finde sich unter https://www.wikidata.org/wiki/Wikidata:Statistics/en.

[2] Betroffen war die Login-Funktionalität von QuickStatements.

[3] Der aktuelle Stand ist unter https://www.wikidata.org/wiki/Wikidata:List_of_properties/de einsehbar.

[4] Die formelle Definition von Eigenschaften ist in Wikidata notorisch schwach, es gibt keine ausgefeilten, sprachunabhängigen Scopenotes (wie etwa bei CIDOC CRM); ein wesentlicher Aspekt der semantischen Konturierung der Properties ist nach meiner Einschätzung der Usus, also wie sie bereits in Wikidata verwendet wurden.

[5] Der aktuelle Stand ist unter https://www.wikidata.org/wiki/Wikidata:Statistics/de einsehbar.

[6] Man muss nur die Beschreibungen anschauen, mit denen die als Beispiel erwähnte Eigenschaft „Urheber“ bei Wikidata in den verschiedenen Sprachen definiert ist, um zu erkennen, wie problematisch die formale Definition von Wikidata-Properties ist:

Englisch: „maker of this creative work or other object (where no more specific property exists)“
Deutsch: „Urheber eines Werkes (vor allem für darstellende Künstler)“ (beide Stand: 5. April 2022)

Im Englischen (und in vielen anderen europäischen Sprachversionen) haben wir eine Einschränkung auf Fälle, bei denen die Rolle des/der Urheber*in bei der Entstehung des Objekts nicht näher spezifiziert werden kann, im Deutschen stattdessen eine unscharfe („vor allem“) Einschränkung auf „darstellende Künstler“ (gemeint sind wahrscheinlich bildende Künstler). Eigentlich ist das ein Unding – was gilt denn nun? Mit einer gewissen Großzügigkeit, die mir geboten scheint, wenn man das famose Gemeinschaftswerk Wikidata nicht aus formalen Gründen verwerfen will, würde ich sagen: Es gilt der Usus, also die faktische Verwendung der Eigenschaft Urheber im riesigen Datenfundus Wikipedia. Wie man den Usus ermittelt, wäre eine berechtigte Frage, die an dieser Stelle aber nicht weiter erörtert werden kann.


OpenEdition schlägt Ihnen vor, diesen Beitrag wie folgt zu zitieren:
Michael Müller (10. Juni 2022). Wikibase – taugt die Wikidata-Software zur Sammlungsdokumentation? (Teil 1). Digitales Netzwerk Sammlungen. Abgerufen am 16. Juli 2024 von https://doi.org/10.58079/nt5n


Das könnte dich auch interessieren …

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.

Suche in OpenEdition Search

Sie werden weitergeleitet zur OpenEdition Search