Workshop - Erweiterter Abgleich mit Wikidata

In diesem Tutorial vertiefen wir den Abgleich von Daten mit Wikibase Instanzen wie Wikidata.

Einführung

Reconciling in der OpenRefine Dokumentation.
Informationssammlung zu OpenRefine Wikidata Reconciliation.
OpenRefine Wikibase Dokumentation.
OpenRefine Wikibase Projekt.

Auch wenn das Protokoll zum Durchführen eines Abgleichs über eine Reconciliation Service API standardisiert ist, so ist die konkrete Umsetzung der Suchfunktionalität von Dienst zu Dienst unterschiedlich.

Um dies zu zeigen, verwenden wir ähnliche Daten wie in Aufgabe 2 von Erweiterter GND Abgleich mit lobid. Diesmal gleichen wir die Daten jedoch mit Wikidata ab. Diese Plattform basiert auf der Software Wikibase und kann mit OpenRefine-Wikibase um eine Reconciliation Service API erweitert werden.

Wie schon in Reconciling mit OpenRefine und Wikidata beschrieben, ist in OpenRefine standardmäßig schon der englischsprachige Service für Wikidata aktiviert. Es ist aber auch möglich den Service in einer spezifischen Sprache zu verwenden.

Wir verwenden in diesem Tutorial die deutschsprachige Schnittstelle über:

https://wikidata.reconci.link/de/api

Aufgabe 1: Abgleich mit Wikidata

Wir benötigen die folgenden Dateien als OpenRefine Projekt:

💾 Wir benötigen die folgende Datei (Rechtsklick und “Ziel speichern unter…”):

In dieser Datei ist das Kabinett Kretschmann III. Wie in Abbildung 1 zu erkennen, sind die Namen mit OCR üblichen Fehlern versehen. Wir ignorieren die Spalte “QID”, mit der wir die Namen sofort wieder korrekt aus Wikidata nachladen könnten. Diese Spalte benötigen wir später zur schnellen Überprüfung der Ergebnisse. Unser Szenario lautet wieder: Wir haben eine Liste mit Namen, deren genaue Schreibweise wir nicht kennen, können diese Namen für den Abgleich jedoch mit einem ungefähren Geburtsdatum und einem Geburtsort ergänzen.

Transformation 1: Name fuzzy

Die Daten in der Spalte “Name” beinhaltet nicht ganz so viele OCR-Fehler, wie in der Aufgabe zum Abgleich mit der lobid. Das liegt daran, dass beim OpenRefine-Wikidata Reconciliation Service zwar angegeben werden kann, dass der Name fuzzy gematcht werden soll. Anders als bei der lobid gnd API lässt sich jedoch nicht angeben, wie viele Fehler erlaubt sein dürfen. ¹

Auch hier fügen wir jedem Wort, welches Fehler beinhalten könnte, den Fuzzy-Operator ~ hinzu. Dafür transformieren wir die Spalte via “Name" "Edit cells" "Transform…” und fügen mit dem folgenden GREL Ausdruck zu jedem Wort ~ hinzu.

forEach(value.split(" "), v, v + "~").join(" ")

Transformation 2: Geburtsdatum reduzieren

Auch bei Wikidata haben wir das Problem, dass uns teilweise nur das Geburtsjahr bekannt ist bzw. umgekehrt in Wikidata nur das Geburtsjahr eingetragen wurde. Bei Wikidata haben wir jedoch kein Wildcard-Zeichen zur Verfügung und müssen uns daher anders behelfen.

Mit so genannten subfields können wir beim Reconciliation Vorgang wie in Abbildung 3 direkt angeben, dass es sich bei den Daten in unserer Spalte um eine Jahresangabe aus einem Datum handelt. Um das einheitlich zu handhaben entfernen wir in der Spalte “Geburtsdatum” den Geburtsmonat und den Geburtstag, sofern vorhanden. Das funktioniert via “Geburtsdatum" "Edit cells" "Transform…” und dem folgenden GREL Ausdruck.

value.split("-")[0]

Subfields

Die “Unterfelder” werden nicht bei den Daten selbst erfasst, sondern im Mapping der Datenspalten auf die zusätzlichen Eigenschaften bei den Einstellungen im Reconciliation Dialog. In der folgenden Tabelle ist eine Liste von verfügbaren subfields:

Keine Transformation beim Geburtsort

Die Spalte “Geburtsort” beinhaltet zwar ebenfalls kleinere Schreib- oder Tippfehler. Bei zusätzlichen Spalten wird bei OpenRefine-Wikibase automatisch die Fuzzy-Suche aktiviert.

Die für den Reconciliation Vorgang umgewandelten Spalten sind in Abbildung 2 abgebildet.

Abgleich durchführen

Den Reconciliation Vorgang starten wir mit “Name" "Reconcile" "Start reconciling” und den in Abbildung 3 gezeigten Einstellungen. Dabei ist darauf zu achten, dass beim Geburtsdatum nicht nach dem Namen der Eigenschaft (“Geburtsdatum”) gesucht wird, sondern stattdessen die Property-ID P569 mit der subfield Ergänzung @year verwendet wird.

Durch die ergänzenden Spalten konnten bei unserem Experiment 12 von 13 Politikern mit hoher Konfidenz automatisch zugeordnet werden. Wie in Abbildung 4 gezeigt, konnte für Peter Hauk kein Treffer gefunden werden, weil Haucl für das Fuzzy-Matching zu weit von Hauk entfernt ist.

Weiterführende Informationen

Es lohnt sich die Dokumentation über die Bewertung einzelner Feldtypen genauer durchzulesen. Zum Beispiel hat die Bewertung einen Bereich von 0 bis 100 (keine Übereinstimmung bis volle Übereinstimmung), und es wird ein Abgleich von Geokoordinaten unterstützt. Wobei beim Koordinatenabgleich schon eine Abweichung von 1km als “keine Übereinstimmung” interpretiert wird.

Aufgabe 2: Suchbereich einschränken

In Wikidata befinden sich deutlich mehr Daten, als in der GND, und auch das Datenschema ist deutlich komplexer. Als Ergänzung bietet der OpenRefine-Wikibase Reconciliation Service die Möglichkeit so genannte Property Paths zu verwenden. Bei den Property Paths werden aktuell nur die Operatoren / und | unterstützt.

Dies zeigen wir an einem konkreten Beispiel.

💾 Wir benötigen die folgende Datei (Rechtsklick und “Ziel speichern unter…”):

Was an dem Projekt “Städte” direkt auffällt ist, dass wir es hier nicht nur mit Städten zu tun haben. Das Projekt beinhaltet Bundesländer aus Deutschland, Bundestaaten in den USA, sowie gleichnamige Städte in den jeweiligen Ländern.

Da die im Folgenden entwickelten Anfragen recht lange rechnen, reduzieren wir zum Testen wie in Abbildung 5 die Einträge mit einem Sternchen-Filter auf vier.

Ein direktes Vorgehen wäre, den Reconciliation Vorgang in vier Schritten durchzuführen:

1. Filtern nach “Country Code” US und Abgleich mit Bundesstaat der Vereinigten Staaten.
2. Filtern nach “Country Code” US und Abgleich mit City in den Vereinigten Staaten.
3. Filtern nach “Country Code” DE und Abgleich mit Bundesland.
4. Filtern nach “Country Code” DE und Abgleich mit Stadt in Deutschland.

In diesem Fall wollen wir aber einige erweiterte Features der OpenRefine-Wikibase Reconciliation API testen.

Einfacher Abgleich

Starten wir direkt auf den vier gefilterten Einträgen einen Reconciliation Vorgang gegen die deutschsprachige Version der Wikidata Reconciliation API, so bekommen wir direkt schon einige Entitätstypen vorgeschlagen. Nach kurzer Recherche können wir die Verwaltungseinheit (Q56061) als gemeinsame Oberklasse identifizieren.

Wie in Abbildung 6 gezeigt, verwenden wir also Q56061 als Typ für den Reconciliation Vorgang.

Hier bekommen wir zwar schon richtige Ergebnisse zurück. Diese sind jedoch gemischt mit Wahlbezirken, historischen Orten, usw. und müssten manuell richtig zugeordnet werden.

Abgleich mit Instanzfilter

Wenn wir in einem Reconciliation Vorgang nach mehreren Typen suchen wollen, so können wir das mit einem Trick in OpenRefine umsetzen. Konkret suchen wir nach Bundesstaat, Stadt und Kleinstadt. Dafür deaktivieren wir den Filter auf die markierten Zeilen und fügen via “Item" "Edit column" "Add column based on this column…” eine neue Spalte “Types” hinzu.

Als Werte für die neue Spalte “Types” nehmen wir "Bundesstaat|Stadt|Kleinstadt" und wandeln sie via “Types" "Edit cells" "Split multi-valued cells…” auf dem Trennzeichen | in eine Record Struktur um. Das gefilterte Ergebnis sollte dann aussehen, wie in Abbildung 7.

Der Hintergrund für diese Datenerweiterung ist, dass OpenRefine mehrere Werte in einer Record Struktur als “Oder” verknüpft betrachtet. Baden-Württemberg kann also ein Bundesstaat sein, oder eine Stadt, oder eine Kleinstadt. ²

Die neue Spalte “Types” berücksichtigen wir beim Reconciliation Dialog in Abbildung 8 als Property P31 “ist ein(e)”. Dadurch werden die Einträge mit einem “falschen” Typ zwar nicht weggefiltert, sie bekommen aber einen niedrigeren Score und rutschen weiter nach unten.

Abgleich mit Country Code

In der Spalte “Country Code” haben wir passende Ländercodes für die einzelnen Entitäten. Die Ländercodes sind jedoch nicht direkt mit den einzelnen Entitäten verknüpft. Hier helfen uns so genannte Property Paths. Mit dem Property Path P17/P297 in Abbildung 9 können wir ausdrücken, dass Baden-Württemberg in einem Land mit dem Ländercode DE liegen soll.

Der Abgleich dauert nun schon deutlich länger, jedoch passt die Sortierung der Ergebnisse deutlich besser. Nur bei den verschiedenen gleichnamigen Städten in den USA haben wir noch Probleme bei der (korrekten) Sortierung der Suchvorschläge.

Abgleich mit State Code

In der Spalte “State Code” haben wir zusätzlich das Kürzel des jeweiligen Bundeslandes/staates, in dem die jeweilige Stadt liegt. Diese Werte finden wir zum Beispiel bei den alternativen Bezeichnungen für die einzelnen Bundesländer/staaten. Die so genannten Aliase lassen sich über spezielle Eigenschaften abfragen, bei denen man ein Kürzel mit einem Sprachcode kombiniert. Die englischsprachigen Aliase erhält man also über Aen. In der folgenden Tabelle sind weitere Kürzel mit Beispielen gelistet.

Hier haben wir das Problem, dass wir wieder eine Art “Oder Verknüpfung” benötigen. Diesmal haben wir nicht verschiedene Werte, sondern verschiedene Arten von Verknüpfungen. Bei den Bundesländern/staaten selbst befindet sich das Kürzel in der Liste der Aliase. Bei den Städten befindet sich das Kürzel des Bundeslandes/staates in einem der übergeordneten Objekte.

Auch hier helfen uns die Property Paths. Mit Aen|(P131/Aen)|(P131/P131/Aen) in Abbildung 10 können wir ausdrücken, dass der gesuchte Wert entweder im englischsprachigen Alias (Aen), oder (|) im Alias einer der beiden übergeordneten Verwaltungseinheiten (P131/Aen bzw. P131/P131/Aen) zu finden sein soll.

Ergebnis

Bei unserem Experiment konnten wir mit dieser komplexen Reconciliation Abfrage die Bundesländer/staaten und gleichnamigen Städte fast immer voneinander “trennen”.

Ausnahmen gibt es zum Beispiel in einzelnen amerikanischen Bundesstaaten, wo es teilweise ebenfalls mehrere Städte mit dem gleichen Namen gibt, so dass das Staatskürzel zur Identifikation nicht ausreichend ist.

Der Reconciliation Vorgang benötigte für die knapp 100 Objekte mehrere Anläufe von jeweils mehreren Minuten. Je nachdem, wie gut sich die Daten im Vorfeld separieren lassen, lohnt sich im Vergleich die in der Einleitung erwähnte Strategie des mehrmaligen Abgleichs auf einer gefilterten Untermenge der Daten bzw. die separate Behandlung von Einzelfällen.

Fazit

Die OpenRefine-Wikibase Reconciliation API bietet nicht so viele Suchfeatures wie die lobid gnd OpenRefine Reconciliation API. Es ist interessant, dass bei der Spalte auf der abgeglichen wird, das Fuzzy-matching manuell aktiviert werden muss, es auf den zusätzlich Spalten aber automatisch durchgeführt wird.

Etwas versteckt ist die Möglichkeit auf sprachspezifische Bezeichnungen L, Beschreibungen D, Aliase A und Seitenlinks S durch Hinzufügen des jeweiligen Sprachcodes zuzugreifen.

Das Matching von Teilausdrücken über subfields wie @year ist recht komfortabel, da dadurch die Information der Datentransformation, also nur Jahr zu berücksichtigen, in der Reconciliation Abfrage und nicht in den Daten selbst steckt.

Mit den Property Paths können wir komplexe Anfragen durchführen und die Suchmenge sehr spezifisch einschränken. Jedoch benötigt die Berechnung der Antwort recht lange und wir erlebten bei unseren Tests häufigere Abbrüche des Vorgangs.

Da als Suchtechnologie bei Wikibase üblicherweise wie bei lobid gnd ElasticSearch als Suchtechnologie eingesetzt wird, könnte es sein, dass weitere Features der Query string syntax zukünftig ebenfalls nutzbar sein werden.

Im nächsten Teil beschäftigen wir uns mit dem erweiterten Datenabgleich zwischen OpenRefine und Getty.

• 16 Erweiterter Abgleich mit Getty