Finally Removing NAs: Ein Werkzeug für den Abgleich und Umzug

Die Grundidee meines Projektes Remove NA ist es, strukturiertes Wissen zur queeren Geschichte zu erheben und das dann in Wikidata zu importieren. Lücken finden und auffüllen.

Konkret ergibt das für das Projekt RemoveNA drei Schritte:

1. Ist dieses Item vorhanden? Beispiel: Gibt es den Verlag Max Spohr in Wikidata?
2. Hat dieses Item Werte für bestimmte Properties? Ist dafür Max Spohr als Gründer hinterlegt?
3. Falls nicht, importiere die fehlenden Daten aus Factgrid in Wikidata.

Dieser Import funktioniert in beide Richtungen: Wenn ein Statement bei Factgrid vorhanden ist, aber nicht bei Wikidata, kann das in Wikidata geschrieben werden. Und umgekehrt: Von Wikidata zu Factgrid.

Um diesen Prozess semi-automatisch vollziehen zu können, habe ich mir ein Werkzeug gebaut. Das Werkzeug ist eine R-Shiny-Webapp, die für verschiedenste Properties, etwa Geburtsdatum oder Nachrangige Organisation, abgleiche zwischen Wikidata und Factgrid erstellt und als drei Tabellen und ausgibt:

• Statements, die in beiden Quellen vorhanden sind
• Statements, die nur in Factgrid vorhanden sind (inkl. Quickstatements für Wikidata)
• Statements, die nur in Wikidata vorhanden sind (inkl. Quickstatements für Factgrid)

Voraussetzung

Die Voraussetzung, um diesen Prozess machen zu können, ist eine vorhandene Übersetzung zwischen Factgrid-Items und -Properties und Wikidata-Items und -Properties. Die Wikidata-Items habe ich in den vergangenen Monaten so gut es ging bei den vielfältigen Matching-Prozessen für verschiedene Entitäten in Factgrid geschrieben. Und die Wikidata-Properties? Die sind zu meinem Glück bereits weitreichend in Factgrid hinterlegt. Etwa bei „Instance of“, P2 in Factgrid, steht dort auch, dass dies P31 in Wikidata entspricht. Diese Quer-Information gibt es bei einigen anderen Properties verschiedenster Typen, etwa Properties, die auf andere Items verweisen, hinter denen sich Strings, URLs, Dates usw. verbergen.

Schematisch funktioniert der Abgleich so:

Umgesetzen kann ich das mit federated queries, also Abfragen über mehrere Datenquellen hinweg. Das ist der Kern und die Magie hinter Knowledge Graphs. Die Übersetzung von Relationen zueinander ist darin angelegt und Wikidata ist die zentrale Plattform, um IDs externer Datenbanken zu sammeln.

Für solche Abfragen braucht man Prefixes. Ein Prefix ist so etwas wie ein Wegweiser, um bestimmte Daten abzurufen. Wer mit Wikidata oder Factgrid arbeitet, kennt wd oder wdt. Das sind zwei Prefixes, um auf Items (Q...) und Properties (P...) zu zeigen.

Mehr zu Prefixen und Federated Queries kannst du hier in der Wikidata-Dokumentation nachlesen.

Als Beispiel hier die Abfrage, um die Werte zu unverheirateten Partner:innen zu vergleichen. Der Link zur Abfrage ist hier.

Wie die Webapp funktioniert

Die Webapp unter apps.katharinabrunner.de/compare-factgrid-wikidata/ erfordert zwei Schritte, um sie nutzen können. Der erste ist: Die Auswahl eines Property Types, etwa URL (Verweise auf Webseite), andere WikibaseItems (etwa Partner:innen), Strings (Spitznamen…). Danach werden alle Properties angezeigt, die den gewählten Property-Type haben und eine korrespondierende Wikidata-PID angegeben.

Solche Abfragen können lange dauern, wenn sie über die gesamte Factgrid-Wissensbasis durchgeführt werden. Dann landet man häufiger als es einem recht sein kann, in einem Timeout. Deshalb können Filter gesetzt werden, der auf dem Screenshot gesetzte (P131 – Q400012) grenzt die Suche auf das RemoveNA-Projekt ein.

Ein Beispiel: Vergleich des Arbeitsgebiets/Field of Work innerhalb des RemoveNA-Projekts vor einigen Tagen, als ich den Screenshot aufgenommen habe.

Damals waren fünf Statements übereinstimmend zwischen Factgrid und Wikidata, 201 Informationen waren in Factgrid, aber nicht in Wikidata, und 31 mal war es umgekehrt. Alle drei Fälle können in einzelnen Tabellen begutachtet werden und die jeweiligen Quickstatements für Importe in die eine oder die andere Richtung heruntergeladen werden.

Entschließe ich mich nun, die fehlenden Daten in Wikidata zu importieren, kann ich mir die Quickstatements dazu, inkl. Referenz auf Factgrid, herunterladen und per Copy-Paste in Wikidata importieren.

Known Issues

In der ersten Version der App gab es keinen Filter nach der Typ der Properties, etwa ob sich dahinter eine URL oder ein Item verbirgt. Meine Vorstellung war, inhaltlich geleitet die Daten zu sichten und ggf. zu importieren: Erst alle persönlichen Beziehungen, danach die von Organisationen etc. Technisch wäre das jedoch deutlich komplexer geworden – also: die Entwicklung hätte länger gedauert und keine wirkliche Verbesserung gebracht.

Die frühzeitige Trennung nach Properties erlaubt es, unterschiedliche Vergleichsabfragen, Darstellungen und Export-Import-Downloads zu erstellen. Beispiel: Um Datumsangaben wirklich vergleichen zu können, muss ich auch die „Time Precision“ wissen, also ob es sich bei dem Datum um eine Jahresangabe oder ein tagesgenaues Datum handelt.

Überhaupt Datumsangaben. Ein gutes Beispiel dafür, warum es nicht immer ist es so einfach zu entscheiden, was übernommen werden sollte oder nicht. Beispiel: Sappho, die griechische Dichterin auf Lesbos. Wann ist sie gestorben? Bei Wikidata gibt es elf Angaben, eine davon ist als präferiert gekennzeichnet.

Factgrid-Properties und Wikidata-Properties können sich in ihrem Zuschnitt unterscheiden. Ein Problem im Handling ergibt sich, wenn eine Factgrid-Property steht für mehrere Wikidata-Properties stehen kann. Etwa P83, Ortsansässig in, für das in Wikidata P551 für Menschen und P131 für Organisatonen verwendet wird. Dieser Filtermechanismus ist in der Webapp nicht eingebaut. Diese Auswahl muss an anderer Stelle passieren.

Weiterentwicklungsmöglichkeiten

• Auswahl der zu importierenden Elemente direkt in der Webapp auswählen – denn manches will man importieren, manches nicht
• Hinweise, wenn ein Factgrid-Property für mehrere Wikidata-Properties steht
• auch Wikicommons-Angaben vergleichen können (Bilder!)
• Bisher können nur solche Items in der jeweils anderen Datenbank ergänzt werden, wenn sie zuvor exitieren.

Grundsatzfrage: Wie viel Redundanz?

Gundsätzlich stellt sich die Frage: Wie viel Daten sollen hin und her kopiert werden zwischen verschiedenen Datenquellen? Wie viel Redunanz ist sinnvoll? Es gibt zwei Sichtweisen. Die eine ist: Daten können ruhig an mehreren Orten vorgehalten werden. Ob das Geburtsdatum jetzt neben Wikidata zusätzlich in Factgrid steht, ist ja unerheblich und bringt zusätzlichen Kontext. Gleichzeitig ist wiederspricht das dem „Single Source of Truth“- Prinzip. Es ist ja häufig nicht so, dass Daten immer eindeutig sind. Selbst bei etwas, das relativ wenig Interpretationsspielraum erlaubt, wie das Geburtsdatum. Gerade bei historischen Figuren, aber nicht nur bei ihnen, kann es mehrere Daten geben. Nehmen wir an, ein Geburtsdatum wird auf Wikidata gelöscht, ergänzt oder als preferiertes Datum markiert. Ohne regelmäßigen automatischen Abgleich erfährt Factgrid (oder jede andere Datenbank) nichts davon – und die Datenqualität sinkt.

Ich habe für mein Projekt keine Entscheidung treffen müssen. Denn mein Positiv, die strukturierten Daten aus dem Münchner Archiv, habe ich zu einem relevanten Teil bereits in Wikidata überführt. Weitere Importe und Anreicherungen, etwa zu LGBT-Chören weltweit, mache ich direkt in Wikidata. Es macht keinen Sinn, den Umweg über Factgrid zu gehen. Das heißt, mein Projekt ist eine One-Time-Sache erstmal.

Würde das Projekt weiter kontinuierlich Daten in Factgrid sammeln, würde sich die Frage nach der Redundanz, Datenimporten und der damit zusammenhängenden Kuration sowie einem zumindest semi-automatisierten Prozess viel dringlicher stellen.

120 LGBT-Chöre sind in Wikidata explizit als solche modelliert. Die meisten davon aus Deutschland und den USA: