Ein Beitrag zum Call ‘Wie Archive von Geokoordinaten in Wikidata profitieren‘ (2025). Von Alexander Winkler.
LODifizierung von GLAM-Daten
Viele der Erschließungsdaten aus Kulturerbeeinrichtungen (in der Folge kurz GLAMs für Galleries, Libraries, Archives und Museums) sind mittlerweile maschinenlesbar verfügbar und orientieren sich – bald mehr bald weniger – an den FAIR-Prinzipien.[1]
Die tatsächliche Nachnutzbarkeit[2] ist aber nicht immer voll ausgeprägt. Zahlreiche unterschiedliche Wege des Datenabrufs, mangelnde Dokumentation, eine Vielzahl von Datenformaten – um nur einige Hemmnisse und Herausforderungen zu nennen – können die Arbeit mit GLAM-Daten erschweren. Die Daten sind zwar oft von hoher Qualität und verwenden insbesondere etablierte Vokabulare und Normdaten; bei genauerem Besehen brauchen aber auch diese qualitativ hochwertigen Daten oft noch eine gewisse Vorverarbeitung, ehe sie produktiv genutzt werden können.
So werden Normdaten oft unterschiedlich eingebunden: mit schlichten (und damit schwer maschinell auflösbaren) IDs, mit falschen URIs[3] etc. Es muss also vor einer Weiterverarbeitung erst eine Harmonisierung der Daten erfolgen. Vor der Verarbeitung an sich müssen zudem relevante Daten erst lokal individuell zusammengetragen werden. Die Korpusbildung geht also der Nutzung voraus.
Die Überführung von GLAM-Daten in Linked Open Data (LOD), d.h. die Integration von GLAM-Daten in einen sog. Wissensgraphen kann einige der skizzierten Hürden absenken. LOD sind offen, maximal verknüpft, maschinenlesbar und hoch interoperabel. Verschiedene LOD-Bestände lassen sich über eine sog. Föderation im Verbund abfragen, sodass – so zumindest die Idee – einer Silo-Bildung entgegengewirkt wird.
Das besondere Potential von LOD ist im Kulturerbesektor längst erkannt, wie die Bemühungen der einschlägigen NFDI-Konsortien demonstrieren.[4] Viele dieser Wissensgraphen entwickeln eine eigene Ontologie, die die möglichen Beziehungen zwischen den verschiedenen enthaltenen Entitäten definieren. Es mag hierfür überzeugende inhaltliche Gründe geben, eine optimale Nachnutzbarkeit profitiert jedoch von einem möglichst einheitlichen Datenmodell und einer mehr oder minder zentralisierten Infrastruktur.
Hier kommt nun Wikidata ins Spiel. Wikidata ist der wohl größte generische, frei verfügbare und von allen modifizierbare Wissensgraph mit 1,7 Milliarden Aussagen zu ca. 120 Millionen verschiedenen Entitäten aus allen Bereichen.[5]
Wikidata ist die zentrale offene Datenplattform – nicht zuletzt auch für GLAMs.[6] Wikidata verzeichnet Personen, Objekte, Orte, Werke und vieles mehr. Gegenüber zentral kuratierten Datenbanken wie der GND hat Wikidata den Vorteil, dass alle jederzeit und instantan sog. Items und Aussagen über Items ergänzen und modifizieren können.
Die schiere Größe des Datenbestands auf Wikidata macht die Verzeichnung neuer Entitäten effizient möglich: Ergänze ich die Werke einer Künstlerin, ist für diese Künstlerin oft schon ein Item vorhanden, das ich referenzieren kann. Der Nachlass eines Schriftstellers kann im meist schon bestehenden Item des Schriftstellers hinzugefügt werden.
Die Zentralität von Wikidata sorgt dafür, dass das Datenmodell etabliert und weithin bekannt ist. Die im Umfeld von Wikidata eingesetzten Tools (z.B. Quickstatements, OpenRefine oder der Wikidata Query Service) erleichtern die Interaktion dem Wissensgraphen erheblich.
Eine weitere Folge der Popularität von Wikidata ist die Sichtbarkeit der Inhalte. Wikidata wird von vielen Menschen und Anwendungen verwendet, dort auffindbare Inhalte werden also bevorzugt wahrgenommen. Die Einbindung weiterer Wissensgraphen ist technisch zwar möglich, erfordert in der Praxis jedoch eine gesonderte Anstrengung.
Kurzum: Für Kulturerbedaten ist Wikidata ein guter Ort. Im Folgenden möchte ich knapp beschreiben, wie ich Nachlassinformationen aus dem Kalliope-Verbund für den Import nach Wikidata vorbereitet und diesen dann durchgeführt habe.
Die Daten des Kalliope-Verbundkatalogs
Im Kalliope-Verbund haben sich Bibliotheken, Archive und Museen zusammengeschlossen, um unter Federführung der Staatsbibliothek zu Berlin ein zentrales “nationale[s] Nachweisinstrument für Nachlässe, Autographen und Verlagsarchive” anzubieten.[7]
Die Kalliope-Plattform ist mit ihren aktuell (Stand 19.4.2026) über 6,9 Millionen Verzeichniseinheiten[8] ein zentrales Rechercheinstrument weit über die Literatur- und Geschichtswissenschaften hinaus.
Kalliope setzt auf hohe Datenqualität durch Verwendung von Normdaten, namentlich der Gemeinsamen Normdatei (GND) für Personen und dem International Standard Identifier for Libraries and Related Organizations (ISIL) für datengebende bzw. bestandshaltende Institutionen.
Die Bereitstellung maschinenlesbarer Daten erfolgt über eine SRU-Schnittstelle[9], die die Ausgabeformate MODS 3.7, MODS 3.4[10] und Dublin Core unterstützt.
Die Herausforderung der Lizenzierung
Unklare und restriktive Lizenzen sind oftmals eine größere Herausforderung als Technisches. Bei den Kalliope-Daten ist das in gewisser Weise auch der Fall: Die maschinenlesbaren Metadaten enthalten keinen Rechtehinweis, obwohl dies – in MODS 3.7 z.B. im Feld mods/accessCondition – einfach möglich wäre.
Auf der Website sind explizite Lizenzhinweise schwer zu finden. Auf der englischen Terms-of-Use-Seite findet sich der Hinweis, die Daten stünden unter “CC NC-BY-SA 3.0”. Auf der entsprechenden deutschen Hinweise-Seite gibt es keinen Hinweis zur Lizenz der Daten. Im Anhang des Teilnahmevertrags[11] steht unter “§ 3 Rechte an den Daten”, dass für alle Daten die “CC-BY-SA Lizenz” (ohne Versionsnummer) gelte. Dieselbe Information, allerdings mit der Versionsnummer 2.0 für die CC-BY-SA-Lizenz, enthält auch ein Blog-Beitrag zu Kalliope von Gerhard Müller aus dem Jahr 2018.
Auf schriftliche Nachfrage hin erklärte die Arbeitsstelle Kalliope-Verbund, dass die Daten verwendet werden dürften, wenn auf ihren Ursprung aus dem Kalliope-Projekt hingewiesen werde. Explizit gestattet wurde dankenswerterweise die Verwendung der Daten in Wikidata ungeachtet der oben formulierten effektiven CC-BY-Lizenz, unter der die Daten zur Verfügung zu stehen scheinen.
Dieser konkrete Fall zeigt, dass mit unklarer und restriktiver Lizenzierung erhebliche Aufwände und Einschränkungen verbunden sind. Datensätze sollten so frei wie möglich nutzbar sein. Im besten Fall heißt dies, dass Daten unter CC0 bereitstehen sollten. Einschränkungen sollten stets sorgfältig abgewogen und begründet werden. Eine Bitte um Verweis samt Zitationsempfehlung dürfte in aller Regel das mildere Mittel sein, um eine adäquate Attribution zu erwirken. Die Lizenz muss schließlich eindeutig und leicht auffindbar sein und sollte, so dies technisch möglich ist, unbedingt auch in maschinenlesbarer Form in den Datensätzen enthalten sein. Unsicherheit hemmt die Nachnutzung und die Daten sollen, um größtmögliche Wirkung entfalten zu können, bequem nachnutzbar sein.
Kalliope und Wikidata
Berührungspunkte zwischen Kalliope und Wikidata bestehen durchaus schon. So wurde bereits im Oktober 2021 die Property P9964 (Kalliope-Verbund-Kennung) eingerichtet, die die in Kalliope hinterlegten GND-Identifier verzeichnet.[12] Vorausgesetzt die Daten werden regelmäßig aktualisiert, lässt sich über diese Property ermitteln, welche Personen in Wikidata auch in der Kalliope referenziert werden. Aktuell (Stand 18.4.2026) sind es 292.661 unterschiedliche Entitäten, für die diese Property verwendet wird.[13]
Darüberhinaus wäre es gewiss interessant, auch konkrete Nachlassinformationen in Wikidata vorzuhalten. Wenn also Kalliope den Nachlass einer Person verzeichnet, sollte diese Information auch in Wikidata zu finden sein. Dadurch werden die Nachlässe sichtbarer, anders und mitunter besser recherchierbar und nicht zuletzt auch quantitativ analysierbar (beispielhafte Analysen siehe unten im Abschnitt “Ein Blick in Daten”).
Nachlässe lassen sich in Wikidata über die Property P485 (archiviert in) modellieren. Der Nachlass Amalie Augstes von Bayern (Q61221) in der SLUB Dresden (Q323270) ist folgendermaßen verzeichnet:
Über Qualifikatoren wie P217 (Inventarnummer) und P11868 (Art der aufbewahrten Dokumente) mit dem Objekt “Nachlass” (Q3827332) lassen sich weitere Informationen angeben.
Workflow Kalliope → Wikidata
Im Folgenden soll in groben Zügen der technische Ablauf beschrieben werden, wie die Daten aus Kalliope nach Wikidata geladen wurden.
Datenabzug aus Kalliope
Zunächst werden die Daten über die SRU-Schnittstelle der Kalliope heruntergeladen.
Für den Download bietet sich von den drei verfügbaren Formaten besonders das MODS-3.7-Format an, da es nicht nur die GND-URIs der bestandsbildenden Person (in mods/name[@type=”personal”]/@valueURI) enthält, sondern auch die ISIL der besitzenden Institution (location/physicalLocation/@valueURI).
Für die Verzeichnung von Archivalien in Wikidata empfiehlt es sich, nur in Ausnahmefällen granularer als auf Bestandsebene zu verzeichnen. Mit Blick auf Nachlässe ist im generischen Wikidata-Kontext die wichtigste Information, dass es diesen gibt und in welcher Institution dieser aufbewahrt wird.
Entsprechend werden über die SRU-Schnittstelle alle Datensätze mit dem Suchfilter ead.genre.index=Nachlass abgerufen. Andernfalls würden auch Datensätze zu einzelnen Archiveinheiten ausgegeben.
Die URL für den Abruf des ersten Hunderterbatchs lautet: https://kalliope-verbund.info/sru?version=1.2&operation=searchRetrieve&query=ead.genre.index%3DNachlass&recordSchema=mods37&startRecord=1&maximumRecords=100.
Die weiteren Datensätze werden abgerufen, indem der startRecord-Wert um je 100 inkrementiert wird.
Die MODS-Daten wurden geparst und in eine SQLITE-Datenbank geschrieben, wobei insbesondere die ISIL der bestandshaltenden Institution, die GND-ID der bestandsbildenden Person und die Inventarnummer verzeichnet wurden.
Datenaufbereitung und Reconciling in OpenRefine
Die SQLITE-Daten können direkt in OpenRefine importiert[14] und dort weiter aufbereitet werden. Hier wurden einige Institutionen mit fehlender oder fehlerhafter ISIL über das Reconciling-Verfahren mit den entsprechenden Wikidata-Items verknüpft. Auf Wikidata fehlende Institutionen wurden punktuell erstellt. Im Wesentlichen wurden jedoch nur solche Daten für den Upload vorbereitet, die schon in Kalliope über eine Personen-GND und Institutions-ISIL verfügen, also relativ hohe Qualitätskriterien erfüllten. Immerhin gab es weit über 60.000 Nachlassangaben, die sich für einen solchen Import anboten.
Upload nach Wikidata
Nach dem Datenabzug, der Aufbereitung und dem Reconciling können die Daten nach Wikidata exportiert werden. Dafür gibt es zwei etablierte Verfahren: einerseits über das Quickstatements-Tool, andererseits der Upload direkt aus OpenRefine. Die Grundlage für den Quickstatements-Import wird ebenfalls über OpenRefine erstellt, da OpenRefine eine bequeme Möglichkeit anbietet, die Daten an die Erfordernisse von Wikidata anzupassen.
Der Upload der über 62.000 Datensätze gestaltete sich widerspenstig. Quickstatements wie OpenRefine waren mit dem Upload des gesamten Datensatzes augenscheinlich überfordert. Dies kam an sich nicht unerwartet, durch mangelndes Feedback ist die Fehlersuche bei stockendem Upload jedoch schwierig bis unmöglich. Der Upload aus OpenRefine in kleineren Chargen ist mühsam. Aus diesem Grund wurde folgendes Verfahren gewählt, das letztlich zum Erfolg führte:
- Ich habe alle für den Upload geeigneten Daten aus OpenRefine in das Quickstatements-Format exportiert (“Export to Quickstatements”).
- Die resultierende Datei (hier qs.txt) habe ich mit dem Kommandozeilenbefehl split -l 500 qs.txt in kleinere Dateien à 500 Zeilen aufgeteilt.
- Diese Dateien (vom split-Tool automatisch benannt nach dem Muster xaa, xab, xac …) wurden über ein kleines Bash-Script an das Quickstatements-Tool geschickt (Beschreibung hier). Das Script sieht folgendermaßen aus (username und token hängen vom jeweiligen Account ab und müssen der eben verlinkten Seite entnommen werden):
for i in x*;
do curl https://quickstatements.toolforge.org/api.php \
-d action=import \
-d submit=1 \
-d format=v1 \
-d username=<WD_USERNAME> \
-d “batchname=kalliope_nachlaesse” \
–data-raw ‘token=<TOKEN>’ \
–data-urlencode data@$i;
done
Mit diesem Script werden kleinere Batches an QuickStatements geschickt und dann sukzessive automatisch und ohne weitere Probleme nach Wikidata geladen.
Ein Blick in die Daten
Die Nachlassdaten aus dem Kalliope-Verbundkatalog, die die oben beschriebenen Qualitätskriterien (GND-ID für die bestandsbildende Person und ISIL für die bestandshaltende Institution, wobei bei Wikidata bekannt sein müssen) erfüllen, stehen nun in Wikidata als Linked Open Data zur Verfügung. Sie können mit folgendem Query abgerufen werden:
SELECT ?pers ?archiv ?url WHERE {
?pers p:P485 [
ps:P485 ?archiv ;
prov:wasDerivedFrom [
pr:P854 ?url
]
]
FILTER (CONTAINS(STR(?url), “kalliope”))
}
Da die Nachlassinformationen aus Kalliope nun (zumindest soweit dies mit dem kurz skizzierten Verfahren möglich war) als Linked Open Data vorliegen, sind sie vielfältig nutzbar.
Es lassen sich z. B. verschiedene SPARQL-Anfragen formulieren, von denen hier nur einige wenige angeführt werden sollen.
- Liste der Institutionen mit den meisten Nachlassnachweisen: https://w.wiki/Ld3t
- Geburtsorte der Bestandsbildner:innen im Archiv der sozialen Demokratie: https://w.wiki/Linx

Kartendarstellung der Geburtsorte der Bestandsbildner:innen im Archiv der sozialen Demokratie
- Liste der Einrichtungen in Sachsen, die Nachlässe in Kalliope verzeichnen, geordnet nach der Zahl der Bestandsbildner:innen: https://w.wiki/MPED
Ausblick
Mit dem hier beschriebenen Upload wurde eine erste kritische Masse an Nachlassnachweisen aus Kalliope nach Wikidata geladen. Das ist jedoch nur ein erster Schritt. Man wird überlegen müssen, wie Update-Routinen aussehen könnten, mit denen Ergänzungen in Kalliope auch nach Wikidata übertragen werden können, und wie mit den Daten verfahren werden kann, die für den ersten Upload unberücksichtigt geblieben sind.
Die Nachlassinformationen in Wikidata sind weder vollständig noch perfekt. Wikidata ist stets work in progress. Die Daten in Wikidata haben jedoch den großen Vorteil, dass sie offen, interoperabel, klar lizenziert und von allseits modifizier-, korrigier- und erweiterbar sind. Es steht zu hoffen, dass GLAM-Institutionen, die Forschung und die interessierte Öffentlichkeit Nachlassinformationen auch in Wikidata pflegen und somit gemeinsam das Wissen um dieses wichtige Quellenmaterial dokumentieren.
Autor
Alexander Winkler ist wissenschaftlicher Angestellter bei digiS, dem Forschungs- und Kompetenzzentrum Digitalisierung Berlin, wo er sich aktuell insbesondere mit Metadatenqualität, Linked Data, Datennutzung und KI im GLAM-Sektor beschäftigt. Er hat Latinistik und Italiansitik, Renaissancewissenschaften und Bibliotheks- und Informationswissenschaften in München, Pisa, Warwick und Berlin studiert und über ein neulateinisch-italianistisches Thema promoviert.
ORCID: 0000-0002-9145-7238
[1] Vgl. https://www.go-fair.org/fair-principles/ bzw. den grundlegenden Aufsatz Wilkinson, M. D. et al. (2016). The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data, 3(1), Article 1. https://doi.org/10.1038/sdata.2016.18
[2] Mit dem um ein really erweiterten Akronym versuche ich (vgl. Winkler, A. (2024). Collections as data. Potenziale und Herausforderungen der Nutzung offener Kulturerbedaten. . https://doi.org/10.5281/zenodo.13742627 und Winkler, A. (2025). FAIR, really? Zur Nutzbarkeit von Kulturerbedaten. 113. BiblioCon in Bremen 2025. https://nbn-resolving.org/urn:nbn:de:0290-opus4-198915), die FAIR-Prinzipien um eine pragmatische Dimension zu erweitern. FAIRe Daten, die theoretisch die Kriterien der reusability (umfassende, transparent lizenzierte, an domänenspezifischen Standards orientierte Daten und Metadaten) erfüllen, stellen die Nutzenden in der Praxis vor Herausforderungen durch spezifische Schnittstellen und Formate. Datenangebote, so die These, berücksichtigen nicht immer ausreichend die Bedürfnisse und Fähigkeiten der relevanten Nutzendengruppen. Also: eine Wissenschaftshistorikerin mag durchaus Interesse haben an der Auswertung entsprechender bibliographischer Daten aus Bibliothekskatalogen. Allein müsste sie sich hierfür allzuoft mühsam in den Umgang mit schwach dokumentierten SRU-Schnittstellen, bibliothekarischen Suchindizes und Feldkatalogen einarbeiten. Dies kann die Arbeit mit den Daten hemmen.
[3] Uniform Resource Identifiers (URIs) sind Strings, die Ressourcen idealiter allgemeingültig und eindeutig identifizieren. Sie sind formal oft mit den gängigeren URLs (Uniform Resource Locators) identisch, die Ressourcen im Netz lokalisieren. In der Praxis werden URIs oft falsch verwendet; ein gutes Bespiel ist der uneinheitliche Gebrauch von GND-Identifikatoren. Hier steht die bloße GND-ID (z.B. “10041544X”) neben der URL (“https://explore.gnd.network/gnd/10041544X”) und zwei verschiedenen URIs (“http://d-nb.info/gnd/10041544X” und “https://d-nb.info/gnd/10041544X”). Nur der letzte Identifier (beginnend mit “https”) entspricht der kanonischen Form des URIs, wie er von der GND definiert ist. Eine Übersicht über kanonische URI-Muster findet sich hier. Vgl. zu den URIs auch die kurze Handreichung: Winkler, A. (2024). URIs im GLAM-Bereich – was sie sind und wie man sie verwendet. https://doi.org/10.5281/ZENODO.11608434.
[4] Vgl. den NFDI4Objects Knowledge Graph, den Culture Knowledge Graph der NFDI4Culture sowie den NFDI4Memory Knowledge Graph.
[5] Vgl. hierzu die SPARQL-Abfragen https://qlever.dev/wikidata/sxnjBH und https://qlever.dev/wikidata/GVMRoH.
[6] Erwähnung verdient in diesem Zusammenhang natürlich das FactGrid-Projekt, das auf derselben technischen Grundlage wie Wikidata einen eigenen Wissensgraphen pflegt mit anderer Zielsetzung, anderen Relevanzanforderungen an die eingegebenen Daten und einer restriktiveren aktiven Partizipationsmöglichkeit.
[7] https://kalliope-verbund.info/de/ueber-kalliope/historie.html.
[8] Vgl. https://kalliope-verbund.info/de/search.html?q=.
[9] Dokumentation der Schnittstelle: https://kalliope-verbund.info/de/support/sru.html, Endpunkt: https://kalliope-verbund.info/sru.
[10] Für weitere Informationen zu den MODS-Schemata vgl. https://www.loc.gov/standards/mods/mods-schemas.html.
[11] Verlinkt unter https://kalliope-verbund.info/de/Teilnahme/Kalliope-Verbund.html.
[12] Vgl. das Property proposal unter https://www.wikidata.org/wiki/Wikidata:Property_proposal/Kalliope-Verbund_ID.
[13] SPARQL-Query: https://w.wiki/LcjM.
[14] Vgl. die OpenRefine-Dokumentation.
Beitragsbild: Hintergrundvisualisierung für den 10. Geburtstag von Wikidata, entworfen von der Agentur MOR, Ausschnitt (Wikimedia Commons/Lea Lacroix (WMDE), Lizenz: CC BY-SA 4.0)
Nur der Text ist unter der Lizenz Creative Commons Namensnennung 4.0 International nutzbar. Alle anderen Elemente (Abbildungen, importierte Anhänge) sind „Alle Rechte vorbehalten“, sofern nicht anders angegeben.
OpenEdition schlägt Ihnen vor, diesen Beitrag wie folgt zu zitieren:
GastautorIn (5. Mai 2026). Nachlassinformationen aus Kalliope für Wikidata erschließen. Saxorum. Abgerufen am 15. Mai 2026 von https://doi.org/10.58079/166f1
