ElasticSearch | FDMLab@LABW

Workshop - Erweiterter Abgleich mit Wikidata

Wed, 01 Mar 2023 00:00:00 +0000

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.

Dieser Workshop wurde erstellt mit OpenRefine Version 3.5.0.
Dieser Workshop wurde zuletzt getestet mit OpenRefine Version 3.9.3.

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…”):

Kretschmann Kabinett III mit Fehlern

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.

Bildschirmfoto des Projektes direkt nach dem Import.

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(" ")

Die Kombination aus Bindestrich - und Fuzzy-Operator ~ scheint zu Problemen zu führen, weshalb wir den Fuzzy-Operator bei dem Nachnamen von Nicole Hoffmeister-Kraut wieder entfernen.

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:

	Beispiel	Bedeutung
`@year`	2023	Jahresbestandteil eines Datums.
`@month`	12	Monatsbestandteil eines Datums.
`@day`	24	Tagesbestandteil eines Datums.
`@isodate`	2023-12-24	Datum im Format von ISO 8601.
`@iso`	2023-12-24:12:00+00:00	Datum und Zeitangabe im Format von ISO 8601 in UTC.
`@lat`	48.77909743853026	Längengrad
`@lng`	9.18665139434279	Breitengrad
`@urlscheme`	https://	Schema einer URL
`@netloc`	fdmlab.landesarchiv-bw.de	Adresse einer URL
`@urlpath`	/kontakt/	Pfad einer URL

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.

Bildschirmfoto des Projektes nach den Transformationen.

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.

Bildschirmfoto der Einstellungen für den Reconciliation Dialog.

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.

Bildschirmfoto der Ergebnisse des Reconciliation Vorgangs.

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…”):

Städte

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.

Bildschirmfoto der mit Sternen gefilterten Einträge.

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

Filtern nach “Country Code” US und Abgleich mit Bundesstaat der Vereinigten Staaten.
Filtern nach “Country Code” US und Abgleich mit City in den Vereinigten Staaten.
Filtern nach “Country Code” DE und Abgleich mit Bundesland.
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.

--- title: Abfrage in Wikidata - einfacher Abgleich config: look: handDrawn theme: neutral --- flowchart LR subgraph entities["Entitäten"] direction LR arkansas["Arkansas"] click bw href "https://www.wikidata.org/wiki/Q1612" "Q1612" _blank bw["Baden-Württemberg"] click bw href "https://www.wikidata.org/wiki/Q985" "Q985" _blank stuttgart_bw["Stuttgart, BW"] click bw href "https://www.wikidata.org/wiki/Q1022" "Q1022" _blank stuttgart_ar["Stuttgart, AR"] click bw href "https://www.wikidata.org/wiki/Q79844" "Q79844" _blank end adminBody[["Verwaltungseinheit"]] click adminBody href "https://www.wikidata.org/wiki/Q56061" "Q56061" _blank p_instanceOf{{"ist ein(e)"}} click p_instanceOf href "https://www.wikidata.org/wiki/Property:P31" "P31" _blank bw --> p_instanceOf --> adminBody

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

Bildschirmfoto der Einstellungen für den Reconciliation Vorgang mit Wikidata - Typeinschränkung.

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.

Bildschirmfoto des Projektes nach dem Hinzufügen der Spalte Types.

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. ²

--- title: Abfrage in Wikidata - Abgleich mit Instanzfilter config: look: handDrawn theme: neutral --- flowchart LR subgraph entities["Entitäten"] direction LR arkansas["Arkansas"] click bw href "https://www.wikidata.org/wiki/Q1612" "Q1612" _blank bw["Baden-Württemberg"] click bw href "https://www.wikidata.org/wiki/Q985" "Q985" _blank stuttgart_bw["Stuttgart, BW"] click bw href "https://www.wikidata.org/wiki/Q1022" "Q1022" _blank stuttgart_ar["Stuttgart, AR"] click bw href "https://www.wikidata.org/wiki/Q79844" "Q79844" _blank end adminBody[["Verwaltungseinheit"]] click adminBody href "https://www.wikidata.org/wiki/Q56061" "Q56061" _blank federatedState["Bundesstaat"] click federatedState href "https://www.wikidata.org/wiki/Q107390" "Q107390" _blank city["Stadt"] click city href "https://www.wikidata.org/wiki/Q515" "Q515" _blank town["Kleinstadt"] click town href "https://www.wikidata.org/wiki/Q3957" "Q3957" _blank p_instanceOf{{"ist ein(e)"}} click p_instanceOf href "https://www.wikidata.org/wiki/Property:P31" "P31" _blank p_instanceOf2{{"ist ein(e)"}} click p_instanceOf2 href "https://www.wikidata.org/wiki/Property:P31" "P31" _blank or{"oder"} bw --> p_instanceOf --> adminBody bw --> p_instanceOf2 --> or --> federatedState & city & town

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.

Bildschirmfoto der Einstellungen für den Reconciliation Vorgang mit Wikidata - Spalte Types.

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.

--- title: Abfrage in Wikidata - Abgleich mit Country Code config: look: handDrawn theme: neutral --- flowchart LR subgraph entities["Entitäten"] direction LR arkansas["Arkansas"] click bw href "https://www.wikidata.org/wiki/Q1612" "Q1612" _blank bw["Baden-Württemberg"] click bw href "https://www.wikidata.org/wiki/Q985" "Q985" _blank stuttgart_bw["Stuttgart, BW"] click bw href "https://www.wikidata.org/wiki/Q1022" "Q1022" _blank stuttgart_ar["Stuttgart, AR"] click bw href "https://www.wikidata.org/wiki/Q79844" "Q79844" _blank end adminBody[["Verwaltungseinheit"]] click adminBody href "https://www.wikidata.org/wiki/Q56061" "Q56061" _blank countryCode["DE"] click countryCode href "https://www.iso.org/obp/ui/#iso:code:3166:DE" "DE" _blank federatedState["Bundesstaat"] click federatedState href "https://www.wikidata.org/wiki/Q107390" "Q107390" _blank city["Stadt"] click city href "https://www.wikidata.org/wiki/Q515" "Q515" _blank town["Kleinstadt"] click town href "https://www.wikidata.org/wiki/Q3957" "Q3957" _blank p_instanceOf{{"ist ein(e)"}} click p_instanceOf href "https://www.wikidata.org/wiki/Property:P31" "P31" _blank p_instanceOf2{{"ist ein(e)"}} click p_instanceOf2 href "https://www.wikidata.org/wiki/Property:P31" "P31" _blank p_country{{"Land"}} click p_country href "https://www.wikidata.org/wiki/Property:P17" "P17" _blank p_iso_country{{"ISO 3166-1 alpha-2"}} click p_iso_country href "https://www.wikidata.org/wiki/Property:P297" "P297" _blank sequence1{"/"} click sequence1 href "https://www.w3.org/TR/sparql11-query/#propertypaths" "Sequence" _blank bw --> p_instanceOf --> adminBody bw --> p_country --> sequence1 --> p_iso_country --> countryCode bw --> p_instanceOf2 --> or --> federatedState & city & town

Bildschirmfoto der Einstellungen für den Reconciliation Vorgang mit Wikidata - Spalte Country Code.

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.

Kürzel	Steht für	Bedeutung	Beispiel	Inhalt
`L`	Label	Bezeichnung	`Lde`	Baden-Württemberg
`D`	Description	Beschreibung	`Den`	Land (federal state) in southwestern Germany
`A`	Alias	Alternative Bezeichnungen	`Afr`	BW, Baden-Württemberg, Land Baden-Württemberg, État du Bade-Wurtemberg, DE-BW, BaWü
`S`	Sidelink	Seitenlink	`Sdewiki`	https://de.wikipedia.org/wiki/Baden-W%C3%BCrttemberg

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.

--- title: Abfrage in Wikidata - Abgleich mit State Code config: look: handDrawn theme: neutral --- flowchart LR subgraph entities["Entitäten"] direction LR arkansas["Arkansas"] click bw href "https://www.wikidata.org/wiki/Q1612" "Q1612" _blank bw["Baden-Württemberg"] click bw href "https://www.wikidata.org/wiki/Q985" "Q985" _blank stuttgart_bw["Stuttgart, BW"] click bw href "https://www.wikidata.org/wiki/Q1022" "Q1022" _blank stuttgart_ar["Stuttgart, AR"] click bw href "https://www.wikidata.org/wiki/Q79844" "Q79844" _blank end adminBody[["Verwaltungseinheit"]] click adminBody href "https://www.wikidata.org/wiki/Q56061" "Q56061" _blank countryCode["DE"] click countryCode href "https://www.iso.org/obp/ui/#iso:code:3166:DE" "DE" _blank stateCode["BW"] click stateCode href "https://www.wikidata.org/wiki/Help:Aliases" "Alias" _blank federatedState["Bundesstaat"] click federatedState href "https://www.wikidata.org/wiki/Q107390" "Q107390" _blank city["Stadt"] click city href "https://www.wikidata.org/wiki/Q515" "Q515" _blank town["Kleinstadt"] click town href "https://www.wikidata.org/wiki/Q3957" "Q3957" _blank p_instanceOf{{"ist ein(e)"}} click p_instanceOf href "https://www.wikidata.org/wiki/Property:P31" "P31" _blank p_instanceOf2{{"ist ein(e)"}} click p_instanceOf2 href "https://www.wikidata.org/wiki/Property:P31" "P31" _blank p_country{{"Land"}} click p_country href "https://www.wikidata.org/wiki/Property:P17" "P17" _blank p_iso_country{{"ISO 3166-1 alpha-2"}} click p_iso_country href "https://www.wikidata.org/wiki/Property:P297" "P297" _blank p_alias{{"Aen"}} click p_alias "https://www.wikidata.org/wiki/Help:Aliases" "Alias" _blank p_located1{{"befindet sich in"}} click p_located1 href "https://www.wikidata.org/wiki/Property:P131" "P131" _blank p_located2{{"befindet sich in"}} click p_located2 href "https://www.wikidata.org/wiki/Property:P131" "P131" _blank p_located3{{"befindet sich in"}} click p_located3 href "https://www.wikidata.org/wiki/Property:P131" "P131" _blank or{"oder"} union{"|"} click union href "https://www.w3.org/TR/sparql11-query/#propertypaths" "Union" _blank sequence0{"/"} click sequence0 href "https://www.w3.org/TR/sparql11-query/#propertypaths" "Sequence" _blank sequence1{"/"} click sequence1 href "https://www.w3.org/TR/sparql11-query/#propertypaths" "Sequence" _blank sequence2{"/"} click sequence2 href "https://www.w3.org/TR/sparql11-query/#propertypaths" "Sequence" _blank sequence3{"/"} click sequence3 href "https://www.w3.org/TR/sparql11-query/#propertypaths" "Sequence" _blank bw --> p_instanceOf --> adminBody bw --> p_country --> sequence0 --> p_iso_country --> countryCode bw --> union --> p_alias & p_located1 & p_located2 p_alias --> stateCode p_located1 --> sequence1 --> p_alias p_located2 --> sequence2 --> p_located3 --> sequence3 --> p_alias bw --> p_instanceOf2 --> or --> federatedState & city & town

Bildschirmfoto der Einstellungen für den Reconciliation Vorgang mit Wikidata - Spalte State Code.

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

GitLab Issue zum Thema Fuzzy-matching mit OpenRefine-Wikibase. ↩︎
Details zu Records beim Reconciliation Vorgang unter Store and expose reconciliation candidate features und darin verknüpften Issues. ↩︎

Workshop - Erweiterter GND Abgleich mit lobid

Sun, 01 May 2022 00:00:00 +0000

In diesem Tutorial vertiefen wir den Abgleich von Daten mit der GND über das lobid API.

Einführung

Reconciling in der OpenRefine Dokumentation.
OpenRefine API in der lobid API Dokumentation.
GND reconciliation (advanced) im lobid Blog.
Komplexe Suchanfragen im lobid Blog.
Query string syntax in der Elasticsearch Dokumentation.

Dieser Workshop wurde erstellt mit OpenRefine Version 3.5.0.
Dieser Workshop wurde zuletzt getestet mit OpenRefine Version 3.9.3.

Das von lobid zur Verfügung gestellte API zur Nutzung der Gemeinsamen Normdatei (GND) verwendet unter der Haube die Suchtechnologie Elasticsearch. Wie andere Suchmaschinen kennt auch Elasticsearch Möglichkeiten eine Suchanfrage zu präzisieren. Durch Verwendung von besonderen Zeichen (Operatoren) können sehr komplexe Suchanfragen gestellt werden.

Die genauen Details sind unter Query string syntax in der Elasticsearch Dokumentation zu finden. Es sind bei dem lobid API jedoch nicht alle Features der “Abfragesprache” aktiviert. Im Zweifel die entsprechenden Operatoren erst einmal an einem Beispiel ausprobieren.

Aufgabe 1: Operatoren in der Weboberfläche

Wir führen die Operatoren zur Verbesserung der Suchergebnisse an (Such-)Beispielen ein, welche wir Stück für Stück weiter entwickeln. Da sich sowohl die Inhalte der GND, als auch die Algorithmen von Elasticsearch immer wieder ändern, ist es möglich, dass sich die Ergebnisse zu einem späteren Zeitpunkt von den hier beschriebenen unterscheiden.

Beispiel 1: Maria oder Marie?

Wir suchen eine Frau mit Vornamen Maria oder Marie und lernen dabei einige Sprachbestandteile kennen, mit denen wir die Suche in der GND via der lobid Weboberfläche einschränken können. Die Links verweisen zum Ergebnis in der lobid Weboberfläche.

Versuch 1: Maria Marie.

Diese Anfrage macht jetzt nicht das, was wir (vielleicht) erwarten würden. Mit dieser Anfrage wird nach Einträgen gesucht, die sowohl Maria als auch Marie beinhalten (Maria AND Marie). Die Verknüpfung via AND ist die Standardeinstellung. Dies können wir für unsere Anfrage anpassen, indem wir boolsche Operatoren wie AND, OR und NOT explizit verwenden.

Versuch 2: Maria OR Marie

Nun finden wir sowohl Personen mit Vornamen Maria, als auch mit Vornamen Marie. Aber auch viele andere Ergebnisse, wie zum Beispiel Lieder mit dem Titel “Maria”. Wir benötigen also weitere Einschränkungen für die mehr als 100.000 Treffer.

Versuch 3: (Maria OR Marie) AND dateOfBirth:[1850 TO 1875]

Wir wissen, dass die Person zwischen 1850 und etwa 1875 geboren wurde. Das können wir mit einer Range-Query auf dem Feld dateOfBirth durchführen. Bitte auch die Klammerung beim ersten Ausdruck (Maria OR Marie) und die Verknüpfung mit AND beachten! Ein weiterer Vorteil einer Einschränkung über das Feld dateOfBirth ist, dass wir uns die zusätzliche Einschränkung auf type:Person sparen, da in der GND hauptsächlich Personen ein Geburtsdatum haben.

Versuch 4: (Maria OR Marie) AND dateOfBirth:[1850 TO 1875] AND dateOfDeath:<1939

Wir wissen außerdem, dass die Person den Ersten Weltkrieg erlebt hat, den Zweiten jedoch nicht. Das könnten wir wieder über eine Range-Query abbilden: [1918-11-11 TO 1939-01-01}. Geschweifte Klammern {, } zeigen dabei an, dass der entsprechende Wert nicht in den Bereich eingeschlossen wird. Also [2000 TO 2022] hat die gleiche Bedeutung wie {1999 TO 2023}. Wir haben für den Ausdruck stattdessen einen der Vergleichsoperatoren <, <=, >, >= verwendet.

Versuch 5: (Maria OR Marie) AND dateOfBirth:[1850 TO 1875] AND dateOfDeath:<1939 AND placeOfBirth:Warschau

Wir wissen, dass die Person in Warschau geboren wurde. Die Anfrage liefert aber keine Ergebnisse. Das liegt daran, dass der Geburtsort nicht mit einem Wert, sondern mit einem anderen Objekt in der GND verknüpft ist. Eine Möglichkeit trotzdem ein Ergebnis zu bekommen ist mit placeOfBirth.\*:Warschau alle Felder des verknüpften Objektes zu durchsuchen.

Die präzisere Variante ist die GND-Nummer des Ortes zu verwenden. Diese wird dann in Anführungsstriche "..." gesetzt, da wir hier eine exakte Phrasensuche durchführen.

Versuch 6: (Maria OR Marie) AND dateOfBirth:[1850 TO 1875] AND dateOfDeath:<1939 AND placeOfBirth.id:“https://d-nb.info/gnd/4079048-4”

Es ist inzwischen klar, dass wir nach Marie Curie suchen. Zur Übung nehmen wir jedoch noch eine weitere Einschränkung vor: Wir wissen, dass die Person eine Naturwissenschaftlerin war. Entweder Chemikerin, oder Physikerin oder beides.

Die Berufe sind ebenfalls als Objekte verknüpft über professionOrOccupation und können mit OR verknüpft mit in die Anfrage aufgenommen werden.

Bonusversuch 7: (Maria OR Marie) AND dateOfBirth:[1850 TO 1875] AND dateOfDeath:<1939 AND placeOfBirth.id:“https://d-nb.info/gnd/4079048-4” AND professionOrOccupation.id:(“https://d-nb.info/gnd/4219058-7” OR “https://d-nb.info/gnd/4337175-9” OR “https://d-nb.info/gnd/4202451-1”)

Das ist ein Beispiel, wie die unterschiedlichen Anforderungen einer Personenrecherche in die “Suchsprache” von lobid-gnd/Elasticsearch übertragen werden können. Es gibt noch weitere Operatoren, die nicht mehr in das obige Beispiel reingepasst haben.

Beispiel 2: Das nicht

Manchmal kommt es vor, dass die Ergebnisse von nicht gesuchten Einträgen überschwemmt werden. So gibt es für die Suchanfrage Freiburg tausende Ergebnisse aus allen Kategorien. Ein typisches Vorgehen ist, die Anfrage auf einen bestimmten Entitätstyp einzuschränken Freiburg AND type:PlaceOrGeographicName.

Neben einschränkenden Filtern gibt es auch ausschließende. So können wir in der Anfrage mit NOT alle Einträge mit Freibug ausschließen, die in Baden-Württemberg vorkommen: Freiburg AND type:PlaceOrGeographicName AND NOT geographicAreaCode.id:“https://d-nb.info/standards/vocab/gnd/geographic-area-code#XA-DE-BW”.

Wir können auch mit + und - betonen welche Begriffe wir explizit suchen bzw. ausschließen: +Freiburg AND type:PlaceOrGeographicName AND -Breisgau.

Beispiel 3: Ungenaue Suche

Manchmal kennen wir die genaue Schreibweise eines Namens nicht, oder es gibt mehrere Varianten. Zum Glück ist die GND üblicherweise sehr großzügig alternative Schreibweisen eines Namens zu listen, so dass mit dem Suchbegriff Tschaikowski auch der gesuchte Komponist Čajkovskij zu finden ist.

Bei weniger bekannten Personen, oder unpraktischen OCR- oder Tippfehlern ist das komplizierter. Zum Beispiel gibt es zum Zeitpunkt des Schreibens dieses Tutorials für Eleonore Prockaska keine Treffer. Mit dem Unschärfeoperator ~ und einer Distanz von 1 Eleonore Prockaska~1 finden wir die gesuchte Elenonore Prochaska auf Anhieb.

Ebenfalls hilfreich bei ungenauen Suchen sind die Operatoren ? für ein unbekanntes Zeichen und * für möglicherweise mehrere unbekannte Zeichen. Beispielsweise findet die Anfrage Winfried Kretschmann AND dateOfBirth:1948 keine Ergebnisse, da bei Winfried Kretschmann das Geburtsdatum komplett (1948-05-17) angegeben ist. Mit dem Operator * in der Anfrage Winfried Kretschmann AND dateOfBirth:1948* lässt sich das kompensieren.

Übersicht über die Operatoren

Es gibt noch mehr Operatoren, die wir hier nicht am Beispiel besprochen haben. Dazu gehört die exakte Phrasensuche mit "..." und das Boosting von einzelnen Begriffen mit ...^5.

Operatoren	Beispiel	Bedeutung
`[`, `]`	`[1939-09-01 TO 1945-09-02]`	Einschließende “Range-Query”.
`{`, `}`	`{0 TO 100}`	Ausschließende “Range-Query” (1-99).
`>`, `>=`, `<`, `<=`	`<2000`	Offene Einschränkung auf Bereiche.
`AND`, `OR`, `NOT`, `(`, `)`	`(a OR b) AND NOT c`	Boolsche Operatoren und Gruppierungen.
`+`, `-`	`+Hund -Katze`	Begriffe explizit ein- bzw. ausschließen.
`~`, `~3`	`unschraf~2`	Unscharfe Suche mit erlaubtem Abstand.
`"..."`	`"des Pudels Kern"`	Exakte Suche (Phrasensuche).
`"..."~3`	`"des Pudels Kern"~3`	Unscharfe Suche in Phrase.
`^`	`Wichtig^5`	Boosting/Gewichtung einzelner Suchbegriffe.
`?`	`M?ier`	Ein unbekannter Buchstabe.
`*`	`Politik*`	Kein/mehrere unbekannte Buchstaben.
`:`	`type:Person`	Suche in bestimmten Feldern.
`_exists_`	`_exists_:dateOfBirth`	Nur Einträge mit Geburtsdatum.
`feld.\*`	`hasBirthPlace.\*:Warschau`	Geburtsort mit Warschau in beliebigem Feld.

Aufgabe 2: Nutzung in OpenRefine

Über das Reconciliation API für OpenRefine funktioniert die Nutzung der Operatoren für die Suche ähnlich. Wir wählen eine Spalte aus, deren Daten wir an den Reconciliation Service übermitteln wollen. Für diese Spalte können wir in dem in Abbildung 1 abgebildeten Dialog anschließend eine Typeinschränkung vornehmen. In der rechten Spalte können wir zusätzlich die Inhalte weiterer Spalten mit Feldern in der GND verknüpfen und mit übermitteln.

Bildschirmfoto des Reconciliation Dialogs in OpenRefine.

Das schauen wir uns direkt in OpenRefine an und laden dafür die folgende Datei in ein Projekt.

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

Kretschmann Kabinett III mit Fehlern

In dieser Datei ist das Kabinett Kretschmann III. Wie in Abbildung 2 zu erkennen, sind die Namen mit OCR üblichen Fehlern versehen. Wir ignorieren die Spalte “GND-ID”, mit der wir die Namen sofort wieder korrekt aus der GND nachladen könnten. Diese Spalte benötigen wir später zur schnellen Überprüfung der Ergebnisse. Unser Szenario lautet daher: 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.

Bildschirmfoto des Projektes direkt nach dem Import.

Transformation 1: Name fuzzy

Zuerst wollen wir dem lobid GND Reconciliation Service mitteilen, dass die Begriffe in der Spalte potentiell fehlerhaft sind. Dafür haben wir in Aufgabe 1 den Fuzzy-Operator ~ kennen gelernt. Wir transformieren also die Spalte via “Name" "Edit cells" "Transform…” und fügen mit dem folgenden GREL Ausdruck zu jedem Wort ~3 hinzu.

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

Transformation 2: Geburtsdatum reduzieren

Bei den Geburtsdaten ist in der GND manchmal das komplette Geburtsdatum angegeben, manchmal aber auch nur das Geburtsjahr. Sollten unsere Daten genauer sein, als die in der GND, also wir das komplette Geburtsdatum haben, die GND aber nur das Geburtsjahr, oder umgekehrt, dann würden wir mit der Spalte Geburtsdatum richtige Treffer ausschließen.

Daher nehmen wir nur das Geburtsjahr und ergänzen das Wildcard-Zeichen * via “Geburtsdatum" "Edit cells" "Transform…” und dem folgenden GREL Ausdruck.

value.split("-")[0] + "*"

Transformation 3: Geburtsort ergänzen

Über den lobid GND Reconciliation Service können wir auch direkt verknüpfte Objekte durchsuchen. Wir könnten im Reconciliation Dialog also direkt die Spalte “Geburtsort” mit der Eigenschaft “Geburtsort” in der GND verknüpfen.

Da wir die noch präzisere GND-ID des Geburtsortes haben, verwenden wir diese für unseren Abgleich. Dafür muss die Spalte noch mit dem Präfix https://d-nb.info/gnd/ ergänzt werden. Das funktioniert über “Geburtsort (GND-ID)“ "Edit cells" "Transform…” und dem folgenden GREL Ausdruck.

"https://d-nb.info/gnd/" + value

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

Bildschirmfoto des Projektes nach den Transformationen.

Abgleich durchführen

Den Reconciliation Vorgang starten wir mit “Name" "Reconcile" "Start reconciling” und den in Abbildung 4 gezeigten Einstellungen.

Bildschirmfoto der Einstellungen für den Reconciliation Dialog.

Durch die ergänzenden Spalten konnten bei unserem Experiment schon 11 von 13 Politikern mit hoher Konfidenz automatisch gematcht werden. Die restlichen Kandidaten matchen wir automatisch via “Name" "Reconcile" "Actions" "Match each cell to its best candidate”.

Um die Überprüfung der Ergebnisse automatisch vorzunehmen, speichern wir uns die GND-ID der vom Reconciliation Service gefundenen Treffer in einer neuen Spalte “Abgleich” über “Name" "Edit column" "Add column based on this column” und vergleichen sie dort direkt mit der Original “GND-ID” Spalte mit dem folgenden GREL Ausdruck.

cell.recon.match.id == row.cells["GND-ID"].value

Bei unserem Experiment waren alle Treffer korrekt (true).

Weitere Operationen

Mit ähnlichen Transformationen können wir zum Beispiel auch “Range-Queries” oder andere Operatoren wie AND, OR, … erzeugen.

Jedoch gibt es mit manchen Operatoren (+, -, ^, >, <, >=, <=) aktuell ein Problem, da sie von dem lobid GND Reconciliation API gefiltert und nicht an Elasticsearch weitergegeben werden.¹ Daher benötigen wir zur Verwendung dieser Operatoren aktuell einen Workaround.²

Bei Anfragen an das lobid GND Reconciliation API mit Gruppierungen wie (... OR ...) werden die oben genannten Operatoren nicht gefiltert. Wir können in OpenRefine also die Anfrage <1939 umwandeln in (<1939 OR <1939) oder anstatt +Freiburg -Breisgau können wir explizit (+Freiburg AND -Breisgau) verwenden.

Update 15. Juni 2022: Der beschriebene Workaround ist mit der Umsetzung von Use ElasticSearch validation endpoint to check queries before executing them nicht mehr notwendig.

Fazit

Mit dem GND Reconciliation API als Aufbau auf die Suchtechnologie Elasticsearch verbindet die lobid Daten in OpenRefine mit den Daten der Gemeinsamen Normdatei. Die von Elasticsearch unterstützten Operatoren zur Einschränkung und Verbesserung der Suchergebnisse sind insbesondere beim Abgleich von großen Datenmengen ein sehr wertvolles Mittel, um auch für große Datenmengen eine übersichtliche Menge an idealerweise passenden Treffern automatisch zu ermitteln.

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

16 Erweiterter Abgleich mit Wikidata

Siehe Using range query parameter via OpenRefine Reconciliation auf GitHub. ↩︎
Eine Lösung ist mit Use ElasticSearch validation endpoint to check queries before executing them in Arbeit. ↩︎