SPARQL | FDMLab@LABW

GND Hierarchieinformationen zur Verbesserung der Erschließung

Tue, 07 Mar 2023 00:00:00 +0000

In der Gemeinsamen Normdatei (GND) sind für Sachbegriffe Hierarchieinformationen enthalten. In diesem Blogbeitrag berichten wir, wie wir diese Informationen verwenden, um die Verschlagwortung von relevanten Akten für die Provenienzforschung zu verbessern.

Wir berichteten bereits, wie wir ein Named-entity Recognition Modell mit Starthilfe durch die Gemeinsame Normdatei trainieren und wie wir die dadurch extrahierten Sachbegriffe normalisieren und mit der GND Sachbegriffen verknüpfen.

In diesem Blogbeitrag geht es um den letzten Workflowschritt, nämlich die Anreicherung von Oberbegriffen aus der GND zur Verbesserung der Verschlagwortung. ¹

--- title: Workflow config: look: handDrawn theme: neutral --- flowchart LR filtern["1. Filtern"] ner["2. NER"] normalisieren["3. Normalisieren"] gnd_abgleich["4. GND Abgleich"] begriffe_nachladen["5. Oberbegriffe"] filtern --> ner --> normalisieren --> gnd_abgleich --> begriffe_nachladen style begriffe_nachladen stroke:#000,stroke-width:4px

Schritt 5: Oberbegriffe nachladen

Wir haben 1.753 Begriffe aus der GND verlinkt. Aus diesen wollen wir basierend auf den Hierarchieinformationen in der GND ein hierarchisches Netzwerk aufbauen. Dafür müssen für die 1.753 Begriffe alle verknüpften Oberbegriffe sowie deren Oberbegriffe usw., nachgeladen werden. Da das potentiell ein recht großes Netzwerk werden könnte, haben wir das Netzwerk mit einer lokalen Kopie der GND in ihrer LOD-Form in Oxigraph berechnet. Dafür wurden mit SPARQL die relevanten Knoten und Verbindungen extrahiert, anschließend mit NetworkX zu einem Netzwerk zusammengefügt, und mit PyVis visualisiert.

Konkret haben wir alle Knoten vom Typ SubjectHeading und den entsprechenden Subtypen geladen. Als Verbindungen haben wir broaderTerm, broaderTermGeneral, broaderTermGeneric, broaderTermInstantial, broaderTermPartitive, broaderTermWithMoreThanOneElement und complexSeeReferenceSubject verwendet.

Dieses Netzwerk verwendeten wir zum einen für unsere Analysen. Zum anderen extrahierten wir daraus einen Teilgraphen mit den für uns relevanten Begriffen.

Die folgenden Analysen basieren auf der Linked Open Data Variante der GND. Abweichungen von den tatsächlichen Daten in der GND sind daher möglich.

Bildschirmfoto der ersten Version unseres GND Teilgraphen.

In dem von uns in Abbildung 1 gezeigten, extrahierten Teilgraphen sind zwar hierarchische Strukturen zu erkennen. Insgesamt sind jedoch sehr viele Einzelknoten um den Wurzelknoten herum zu sehen, und die üblichen Algorithmen zur Darstellung von Hierarchien weigerten sich das vermeintlich hierarchische Netzwerk verständlich darzustellen.

Im Folgenden besprechen wir die Probleme, über die wir gestolpert sind und prüfen, ob einige (problematische) Eigenschaften unseres extrahierten Teilgraphen auch im Gesamtnetzwerkes aller Sachbegriffe zu finden sind.

Typen von Oberbegriffen

Bildschirmfoto der Unterklassen von Authority Resources in der GND Ontologie.

In Abbildung 2 sind noch einmal die Unterklassen (Typen) von Normdatenressourcen (Authority Resource) in der GND Ontologie gezeigt. Wir arbeiten mit Schlagworten (SubjectHeading) und den zugehörigen Unterklassen.

Die Diagramme wurden mit unserer experimentellen Webanwendung zur GND Hierarchie Visualisierung von Sachbegriffen erstellt. Hier die Legende:

flowchart LR initial(["Fokussierter Begriff"]):::initial broader["Oberbegriff"] initial --> broader broaderMarked["Oberbegriff mit anderem Typ"]:::nonHeading initial --> broaderMarked narrower["Unterbegriff"] narrower --> initial similar["#Auml;hnlicher Begriff"] initial <-.-> similar broader <-.-> similar broaderMarked <-.-> similar classDef default fill:#FFF,stroke:#0088c9,stroke-width:3px,color:#000; classDef category fill:#FFF,stroke:#1fbeb8,stroke-width:3px,color:#000; classDef initial fill:#FFF,stroke:#4dbd05,stroke-width:3px,color:#000; classDef nonHeading fill:#FFF,stroke:#F04D0E,stroke-width:3px,color:#000;

Wir hatten im letzten Blogbeitrag schon den Perserteppich erwähnt, der über complexSeeReferenceSubject mit den Begriffen Teppich und Iran verknüpft ist. Im folgenden Diagramm haben wir einige weitere Beispiele für Begriffe, die über Komposita definiert sind. Darüber werden als Oberbegriffe auch GND Konzepte nachgeladen, die nicht vom Typ Subject heading oder einem Untertypen davon sind. Diese können zum Beispiel vom Typ oder einem Untertypen von Conference or Event, Corporate Body, Person, Place or geographic name oder Work sein.

flowchart LR 7505070-5(["Perserteppich"]):::initial click 7505070-5 href "https://lobid.org/gnd/7505070-5" "7505070-5" _blank 4059482-8["Teppich"] click 4059482-8 href "https://lobid.org/gnd/4059482-8" "4059482-8" _blank 4027653-3["Iran"]:::nonHeading click 4027653-3 href "https://lobid.org/gnd/4027653-3" "4027653-3" _blank 7608344-5(["Venustempel"]):::initial click 7608344-5 href "https://lobid.org/gnd/7608344-5" "7608344-5" _blank 11876800X["Venus, Göttin"]:::nonHeading click 11876800X href "https://lobid.org/gnd/11876800X" "11876800X" _blank 4059416-6["Tempel"] click 4059416-6 href "https://lobid.org/gnd/4059416-6" "4059416-6" _blank 7509659-6(["Osterweiterung / Europäische Union"]):::initial click 7509659-6 href "https://lobid.org/gnd/7509659-6" "7509659-6" _blank 4128080-5["Erweiterung"] click 4128080-5 href "https://lobid.org/gnd/4128080-5" "4128080-5" _blank 4075739-0["Osteuropa"]:::nonHeading click 4075739-0 href "https://lobid.org/gnd/4075739-0" "4075739-0" _blank 5098525-5["Europäische Union"]:::nonHeading click 5098525-5 href "https://lobid.org/gnd/5098525-5" "5098525-5" _blank 7505070-5 -->|complexSeeReferenceSubject| 4059482-8 7505070-5 -->|complexSeeReferenceSubject| 4027653-3 7608344-5 -->|complexSeeReferenceSubject| 11876800X 7608344-5 -->|complexSeeReferenceSubject| 4059416-6 7509659-6 -->|complexSeeReferenceSubject| 4128080-5 7509659-6 -->|complexSeeReferenceSubject| 4075739-0 7509659-6 -->|complexSeeReferenceSubject| 5098525-5 classDef default fill:#FFF,stroke:#0088c9,stroke-width:3px,color:#000; classDef category fill:#FFF,stroke:#1fbeb8,stroke-width:3px,color:#000; classDef initial fill:#FFF,stroke:#4dbd05,stroke-width:3px,color:#000; classDef nonHeading fill:#FFF,stroke:#F04D0E,stroke-width:3px,color:#000;

Dies betrifft jedoch nicht nur die Verbindungen vom Typ complexSeeReferenceSubject. In den folgenden Diagrammen ist das Beispiel der Thora und des islamische Feiertags Maulid an-Nabi gezeigt. Hier werden jeweils Sachbegriffe mit Werken über Verbindungen vom Typ broaderTermGeneral verknüpft.

flowchart LR 4226122-3(["Thora"]):::nonHeading click 4226122-3 href "https://lobid.org/gnd/4226122-3" "4226122-3" _blank 7849405-9["Thorakrone"] click 7849405-9 href "https://lobid.org/gnd/7849405-9" "7849405-9" _blank 4590779-1["Thorakapsel"] click 4590779-1 href "https://lobid.org/gnd/4590779-1" "4590779-1" _blank 4457982-2["Thorawimpel"] click 4457982-2 href "https://lobid.org/gnd/4457982-2" "4457982-2" _blank 4617346-8["Thoramantel"] click 4617346-8 href "https://lobid.org/gnd/4617346-8" "4617346-8" _blank 7526823-1["Thorazeiger"] click 7526823-1 href "https://lobid.org/gnd/7526823-1" "7526823-1" _blank 4232170-0["Thoraschrein"] click 4232170-0 href "https://lobid.org/gnd/4232170-0" "4232170-0" _blank 4185330-1["Thorarolle"] click 4185330-1 href "https://lobid.org/gnd/4185330-1" "4185330-1" _blank 7849405-9 -->|broaderTermGeneral| 4226122-3 4590779-1 -->|broaderTermGeneral| 4226122-3 4457982-2 -->|broaderTermGeneral| 4226122-3 4617346-8 -->|broaderTermGeneral| 4226122-3 7526823-1 -->|broaderTermGeneral| 4226122-3 4232170-0 -->|broaderTermGeneral| 4226122-3 4185330-1 -->|broaderTermGeneral| 4226122-3 classDef default fill:#FFF,stroke:#0088c9,stroke-width:3px,color:#000; classDef category fill:#FFF,stroke:#1fbeb8,stroke-width:3px,color:#000; classDef initial fill:#FFF,stroke:#4dbd05,stroke-width:3px,color:#000; classDef nonHeading fill:#FFF,stroke:#F04D0E,stroke-width:3px,color:#000;

flowchart LR 7566591-8(["Maulid an-Nabi"]):::initial click 7566591-8 href "https://lobid.org/gnd/7566591-8" "7566591-8" _blank 4310274-8["Maulid"]:::nonHeading click 4310274-8 href "https://lobid.org/gnd/4310274-8" "4310274-8" _blank 4121583-7["Religiöses Fest"] click 4121583-7 href "https://lobid.org/gnd/4121583-7" "4121583-7" _blank 7566591-8 -->|broaderTermGeneral| 4310274-8 7566591-8 -->|broaderTermInstantial| 4121583-7 classDef default fill:#FFF,stroke:#0088c9,stroke-width:3px,color:#000; classDef category fill:#FFF,stroke:#1fbeb8,stroke-width:3px,color:#000; classDef initial fill:#FFF,stroke:#4dbd05,stroke-width:3px,color:#000; classDef nonHeading fill:#FFF,stroke:#F04D0E,stroke-width:3px,color:#000;

Nach unseren Analysen kommen wir auf 558 Knoten mit mindestens einem Oberbegriff, der nicht vom Typ SubjectHeading ist. Das ist bei 204.560 Sachbegriffen ein recht kleiner Anteil von circa 0,27 Prozent. Die entsprechenden Oberbegriffe mit anderem Typ müssen beim Netzwerkaufbau und der anschließenden Analyse jedoch mit berücksichtigt werden.

Mehrere Oberbegriffe

Die Verknüpfung von mehreren Oberbegriffen sorgt für Probleme bei der Berechnung von Hierarchielayouts. Wir haben zur Visualisierung unseres Teilgraphen die Anzahl an Oberbegriffen pro Knoten auf einen Oberbegriff begrenzt. Dadurch verlieren wir zwar Informationen in der Visualisierung, können den Teilgraphen jedoch besser visuell inspizieren.

Keine Oberbegriffe

In unserem Teilgraphen haben etwa 25 Prozent der Begriffe keinen Oberbegriff. Das hat unter anderem damit zu tun, dass die GND in vielen Bereichen entweder gar keine Hierarchieinformationen beinhaltet, oder sie inkonsequent gepflegt werden.

Zu den in unserem Projekt verwendeten Begriffen ohne Hierarchieinformationen gehören zum Beispiel Akte, Archivalie, Antiquität, Feuerzeug, Kamm, Nähzeug, Säge, …

Analyse Subgraph

Mit den oben beschriebenen Erfahrungen und Anpassungen konnten wir aus dem Netzwerk eine darstellbare Hierarchie erzeugen, die wir visuell inspizieren können. Dabei ist uns aufgefallen, dass die Hierarchie in vielen Bereichen ziemlich flach ausfällt. Abbildung 3 zeigt einen kleinen Ausschnitt der Hierarchie.

Bildschirmfoto der zweiten Version unseres GND Teilgraphen als Hierarchie.

Der Radius der grauen Knoten gibt ungefähr an, wie viele Akten mit diesem Begriff direkt gefunden werden würden. Die Skalierung musste jedoch nach unten auf 5 Treffer und oben auf 50 Treffer begrenzt werden. Ansonsten wären Kreise mit einem kleineren Durchmesser nicht mehr sichtbar, und einzelne Begriffe mit mehr als 1.000 betroffenen Akten würden große Teile des Graphen überdecken.

Die roten Knoten zeigen Begriffe, für die wir keine direkten Treffer in den Akten haben. Diese wurden über die Hierarchieinformationen der GND als zusätzliche Begriffe nachgeladen. Diese zusätzlichen Begriffe machen in manchen Bereichen Sinn.

In den Bereichen Biologie und Chemie, die sehr ausführliche und tiefe Hierarchieinformationen haben, sollten die Begriffe in unserem Teilgraphen jedoch reduziert werden. So ist es fachlich zwar korrekt, dass Messing eine Kupferlegierung ist, die zu den Buntmetalllegierungen gehört, welche zu den Schwermetallegierungen gehört, welches eine Legierung ist… diese Informationen bieten in unserem Kontext jedoch keinen Mehrwert.

Hier werden wir in Nachfolgearbeiten versuchen, mit verschiedenen Algorithmen aus der Netzwerkanalyse “überflüssige” Knoten wieder aus der Hierarchie zu entfernen.

Bildschirmfoto der dritten Version unseres GND Teilgraphen als Hierarchie mit Einfärbungen.

In einer weiteren Verbesserung der Visualisierung der Hierarchie in unserem GND Teilgraphen in Abbildung 4 haben wir einzelne Knoten zusätzlich eingefärbt.

Orange: Gegenstand
Grün: Material
Blau: Marke/Herkunft
Lila: Stil
Gemischt Rot: mehrere Kategorien

So konnten bei der visuellen Prüfung schon einige Probleme und fehlerhafte GND Abgleiche identifiziert werden, die in der Liste der mehr als 67.500 Einzelbegriffe untergegangen waren. In Abbildung 4 ist zum Beispiel das Glas in einem gemischten Rot markiert, weil der Begriff sowohl für den Gegenstand Glas, als auch für das Material Glas verwendet wurde. ²

Analyse GND SubjectHeading Graph

Wir haben uns gefragt, ob wir bei der Extraktion unseres GND Teilgraphen Fehler gemacht haben, oder einfach Pech mit unseren Daten hatten, oder ob sich manche Eigenschaften unseres GND Teilgraphen auch im großen Graphen der GND SubjectHeadings wiederfinden.

Daher haben wir eine oberflächliche Analyse des SubjectHeadings Graphen durchgeführt.

Komponenten und Größen

Streudiagramm zur Darstellung der Eigenschaften von Komponenten im GND SubjectHeading Graph.

Unsere erste Feststellung war, dass der Gesamtgraph der GND SubjectHeadings mit 204.560 Knoten in 47.388 Teilgraphen (Komponenten) zerfällt, die nicht miteinander verbunden sind.

In Abbildung 5 ist ein Streudiagramm gezeigt, wo auf der X-Achse die Größe der Komponente und auf der Y-Achse die Anzahl an Komponenten dieser Größe dargestellt ist. Die Größe des Symbols zeigt, wie viele unterschiedliche (Sub)Typen von SubjectHeading betroffen sind.

Auf Grund der enormen Größenunterschiede ist das Diagram logarithmisch skaliert, so dass die Interpretation schwierig(er) ist.

Der Stern ganz links oben stellt 41.465 Komponenten dar, die jeweils nur aus einem Knoten bestehen. Dies umfasst die Typen CharactersOrMorphemes (2.912), EthnographicName (1.257), GroupOfPersons (158), HistoricSingleEventOrEra (635), Language (5), MeansOfTransportWithIndividualName (8), NomenclatureInBiologyOrChemistry (15.132), ProductNameOrBrandName (422), SoftwareProduct (134), SubjectHeading (12), SubjectHeadingSensoStricto (20.900).

Der Stern ganz rechts unten stellt eine Komponente mit einer Größe von 140.105 Knoten dar, welche die Typen CharactersOrMorphemes (261), EthnographicName (2.510), GroupOfPersons (589), HistoricSingleEventOrEra (4.031), Language (5.942), MeansOfTransportWithIndividualName (1.479), NomenclatureInBiologyOrChemistry (11.428), ProductNameOrBrandName (6.994), SoftwareProduct (8.056), SubjectHeading (8.220) und SubjectHeadingSensoStricto (91.381) umfasst.

Anteil von Komponenten bestimmter Größen

Aus dem Diagramm in Abbildung 5 lässt sich ablesen, dass der Graph nicht vollständig verbunden ist und sich in zwei Extreme verteilt. Viele Knoten sind gar nicht, oder nur wenig in Hierarchien eingebunden, andere sind in einem Netzwerk mit 140.105 Knoten zusammengefasst. In dem Diagramm in Abbildung 6 ist dies noch einmal visuell dargestellt. Der letzte große Teilgraph mit den 140.105 Knoten ist im Diagramm abgeschnitten.

Diagramm zur kumulierten Darstellung des prozentualen Anteils von Komponenten bestimmter Größen.

Auf der X-Achse ist wieder die Größe der Komponenten abgebildet und auf der Y-Achse der prozentuale Anteil an Knoten, den Komponenten dieser Größe im Gesamtgraphen innehaben.

Etwa 20 Prozent der Knoten haben keine Hierarchieinformationen.
Etwa 30 Prozent der Knoten sind in Teilgraphen mit weniger als 20 Knoten verbunden.
Etwa 68 Prozent der Knoten sind in einem Teilgraphen mit 140.105 Knoten zu finden.

Tiefe der Hierarchie

Es wäre zu erwarten, dass mit Zunahme der Größe der Komponenten auch die Tiefe der Hierarchie steigt. Daher haben wir in einem Boxplot in Abbildung 7 die maximale Tiefe der Hierarchie jeder Komponente analysiert und sortiert nach Komponentengröße ausgewertet.

Boxplot zur Darstellung der Verteilung der max. Tiefe pro Komponentengröße.

Prinzpiell steigt die Tiefe der Hierarchie mit steigender Komponentengröße etwas. Jedoch wäre bei einer Komponente mit 114 Knoten mehr als 2 Hierarchiestufen zu erwarten. Oder bei einer Komponente mit 140.105 Knoten mehr als 13 Hierarchiestufen.

Kindknoten pro Knoten

Wenn es relativ wenig Hierachiestufen gibt, liegt die Vermutung nahe, dass es in den einzelnen Komponenten Knoten gibt, die sehr viele direkte Unterknoten haben. Daher haben wir noch einmal die Anzahl an Kindknoten pro Knoten analysiert und sortiert nach Komponentengröße in einem Boxplot in Abbildung 8 ausgewertet.

Boxplot zur Darstellung der Verteilung der Anzahl von Kindknoten pro Komponentengröße.

Die graue Linie markiert die maximale Anzahl an Kindknoten, die ein Knoten in einer Komponente einer bestimmten Größe haben kann. Auffällig ist, dass es bei vielen Komponenten Knoten gibt, die nahe an dieser Grenze liegen. Die Komponente besteht dann aus einem Oberknoten mit dem (fast) alle restlichen Knoten der Komponente verbunden sind.

Interessant sind auch die drei Knoten in der größten Komponente, die mehr als 1.000 direkte Kindknoten haben. Hierbei handelt es sich um eine große Anzahl an Verbindungen des Typs Broader term (instantial), die im GND Explorer als “Ist ein Beispiel für andere Entität” angezeigt werden.

Fazit

Nach anfänglichen Schwierigkeiten konnten wir eine für uns in großen Teilen brauchbare Hierarchie aus der GND extrahieren, die wir für unser Projekt weiter bearbeiten können.

Wir waren in unserem Teilgraphen verwundert über die doch vielen Begriffe, die ohne Hierarchieinformationen in der GND liegen. Mit unserer Analyse des Gesamtgraphen konnten wir bestätigen, dass dies wohl ein generelles Problem bei GND Sachbegriffen ist.

Auch sind die Hierarchien in unserem Teilgraphen selbst relativ flach, was sich bei der Analyse des Gesamtgraphen ebenfalls als Eigenschaft der GND bestätigte.

Alternativ könnte es sich auch um ein systematisches Problem in unserer LOD Variante der GND oder unserer Auswahl von Verbindungsarten zwischen GND Sachbegriffen liegen. Wir konnten in unseren Stichproben jedoch keine Hinweise auf solche Fehler finden.

Es würde sich jetzt anbieten die Analyse ausführlicher zu gestalten und dabei zum Beispiel zusätzlich GND Sachgruppen, die einzelnen Subtypen von SubjectHeading, sowie die unterschiedlichen Verbindungsarten weiter zu analysieren. Dies würde jedoch den Rahmen unseres aktuellen Projektes übersteigen.

Prinzipiell kommt es nach unseren Beobachtungen darauf an, in welchem (Fach-)Bereich man sich innerhalb der GND Sachbegriffen bewegt. So fanden wir für unseren Anwendungsfall die Hierarchieinformationen für Haushaltsgegenstände unzureichend, die zu Musikinstrumenten passend und hilfreich, und die für Begriffe aus der Biologie und Chemie zu ausführlich.

Details zur Motivation und unserem generellen Vorgehen haben wir schon unter NER und GND zur Verbesserung der Erschließung berichtet. ↩︎
Details zum Glas als Material und Gegenstand, sowie zu den Kategorien, finden sich im Artikel NER und GND zur Verbesserung der Erschließung. ↩︎

Workshop - Erweiterter Abgleich mit Getty

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

In diesem Tutorial vertiefen wir den Abgleich von Daten mit den Vokabularen von Getty.

Einführung

Reconciling in der OpenRefine Dokumentation.
Getty Research Institute zu OpenRefine Reconciliation.
Tutorial zur Verwendung des Getty Vokabulars in OpenRefine.
Portal zu Getty Vokabularen in ihrer LOD Form.
Sammlung von Beispielanfragen mit SPARQL.

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

Das Getty Research Institute verwaltet verschiedene Vokabulare:

Art & Architecture Thesaurus (AAT) ®
Cultural Objects Name Authority (CONA) ® (noch nicht veröffentlicht)
Getty Thesaurus of Geographic Names (TGN) ®
Union List of Artist Names (ULAN) ®

Anders als die quasi gemeinfrei verfügbaren Daten in der GND und in Wikidata, sind die Daten von Getty unter der Open Data Commons Attribution License (OCD-BY) v1.0 veröffentlicht.

Die Getty Vokabulare stehen in verschiedenen Formaten zum Download zur Verfügung und sind über unterschiedliche APIs abrufbar. Wir interessieren uns hier explizit für die OpenRefine Reconciliation API. Bei entsprechenden Kenntnissen ist es womöglich interessanter direkt über die SPARQL Oberfläche mit den Vokabularen zu arbeiten, oder über OpenRefine den SPARQL Endpunkt anzusprechen. Für die Arbeit mit SPARQL gibt es auch eine Sammlung von Beispielanfragen.

Im FDMLab verwenden wir die Vokabulare von Getty bisher nicht, so dass die hier gezeigten Methoden sehr wahrscheinlich unvollständig sind.

Aufgabe 1: Daten verknüpfen

Projekt anlegen

Hier verwenden wir das gleiche Datenbeispiel, wie bei Aufgabe 2 von 07 Reconciling mit OpenRefine und Wikidata.

Es handelt sich um eine Liste der Mitgliedstaaten der Europäischen Union (Stand März 2023).

 - Belgien
 - Bulgarien
 - Dänemark
 - Deutschland
 - Estland
 - Finnland
 - Frankreich
 - Griechenland
 - Irland
 - Italien
 - Kroatien
 - Lettland
 - Litauen
 - Luxemburg
 - Malta
 - Niederlande
 - Österreich
 - Polen
 - Portugal
 - Rumänien
 - Schweden
 - Slowakei
 - Slowenien
 - Spanien
 - Tschechien
 - Ungarn
 - Zypern

Wir legen diese Liste via Zwischenablage (“Clipboard”) als OpenRefine Projekt an.

Einfacher Abgleich

Nachdem wir die Daten aufgeräumt haben, starten wir den Abgleich mit Getty via “Land" "Reconcile" "Start reconciling” und fügen den folgenden Standard Service hinzu:

https://services.getty.edu/vocab/reconcile/

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

Wie in Abbildung 1 zu sehen, gibt es bei den Getty Vokabularen keine spezifischen Typeinschränkungen, wie wir sie von der lobid gnd oder Wikidata kennen. Wir können uns hier lediglich auf einzelne Vokabulare beschränken.

Trotz englischsprachigem Vokabular und deutschsprachigen Suchbegriffen, bekommen wir bei unserem Reconciliation Vorgang passende Ergebnisse von TGN vorgeschlagen.

Das liegt daran, dass der gesuchte Begriff nicht nur im Namen der Entität gesucht wird, sondern in mehreren Feldern. ¹ So finden wir mit dem deutschsprachigen Begriff “Deutschland” auch das passende “Germany” im TGN. Gleichzeitig können dadurch auch unerwartete Ergebnisse mit hoher Trefferquote auftauchen, da wir nicht beeinflussen können, welche Felder alles durchsucht werden sollen.

Erweiterter Abgleich

Wir können bei den Getty Vokabularen zwar nicht explizit nach Typen filtern, wir können die Bewertung der Suchergebnisse jedoch positiv beeinflussen. Dazu erweitern wir das Projekt.

Wir fügen eine Kopie der Spalte “Land” via “Land" "Edit column" "Add column based on this column…” mit dem Namen “Land2” hinzu.
Von der Spalte “Land2” legen wir eine weitere Kopie via “Land2" "Edit column" "Add column based on this column…” an und nennen die neue Spalte “Label”.
Neben der Spalte “Label” erzeugen wir eine neue Spalte via “Label" "Edit column" "Add column based on this column…” und nennen die neue Spalte “Art des Ortes” und verwenden als Wert den Text "nation".

Das Ergebnis der drei Operationen kann in einem Ausschnitt in Abbildung 3 betrachtet werden.

Anschließend können wir einen neuen Reconciliation Vorgang auf der Spalte “Land2” starten und zusätzlich wie in Abbildung 2 die Spalte “Label” als Eigenschaft label und die Spalte “Art des Ortes” als Eigenschaft placeTypePref verwenden.

Bildschirmfoto der Einstellungen für den Reconciliation Vorgang mit Getty - Zusätzliche Eigenschaften.

Das hat zur Folge, dass die von uns gesuchten Länder im Vergleich zu den anderen Ergebnissen deutlich besser bewertet werden und in der Sortierung nach oben rutschen.

Mit der Spalte “Label”, bzw. dem Mapping auf die Eigenschaft label beim Reconciliation Vorgang, geben wir den Ergebnissen einen “boost”, die den deutschsprachigen Namen des Landes explizit als deutsche Übersetzung haben.

Mit der Spalte “Art des Ortes”, bzw. dem Mapping auf die Eigenschaft placeTypePref, bekommen die Ergebnisse einen “boost”, die als Land eingestuft werden.

Wie in Abbildung 3 an den Beispielen Luxemburg und Malta zu sehen, können wir die gesuchten Länder somit von den restlichen Treffern differenzieren und einfacher zuordnen.

Bildschirmfoto der Ergebnisse des Abgleichs mit Getty.

Fazit

Die Bewertung der Suchtreffer bei Getty ist etwas gewöhnungsbedürftig, jedoch können wir uns das zu Nutze machen, um die Bewertung der Suchanfragen auf unsere Daten anzupassen.

Die dann doch recht eingeschränkten Such- und Filteroptionen könnten erklären, weshalb Wissenschaftler dann doch lieber direkt mit einem Datendownload der Vokabulare, oder der SPARQL Schnittstelle arbeiten.

Lizenzhinweise

Dieser Artikel und die Bildschirmfotos enthalten Informationen aus dem Thesaurus of Geographic Names (TGN) ®, welcher verfügbar ist unter der ODC Attribution License v1.0.

Im nächsten Teil beschäftigen wir uns mit dem Nachladen von Geokoordinaten für Orte.

16 Erweiterter Abgleich mit Getty

Wir konnten keine aktuellen Informationen finden, welche Felder bei welchen Vokabularen standardmäßig durchsucht werden. ↩︎

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. ↩︎

GND in lokale Datenbank laden (reloaded)

Tue, 13 Dec 2022 00:00:00 +0000

Wir setzen unser lokales Testsystem für Experimente mit der Linked Open Data Version der Gemeinsamen Normdatei mit Oxigraph neu auf.

Wir hatten vor über einem Jahr schon einen ausführlichen Artikel zum Laden der GND in einen Apache Jena Triplestore verfasst. Das beschriebene Setup ist nach wie vor im Einsatz und wir sind auch (meistens) zufrieden damit. Jedoch dauert das Einlesen von Daten doch recht lange, was das Aufsetzen von Ad-Hoc Experimenten erschwert.

Daher haben wir als Alternative das relativ neue Projekt Oxigraph getestet.

Datenbank: Oxigraph

Oxigraph Logo.

Das Projekt Oxigraph ermöglicht uns ein ähnliches Setup, wie wir es mit Apache Jena aufgebaut haben. Anders als Apache Jena basiert Oxigraph auf der Programmiersprache Rust und verwendet RocksDB als Datenbank im Hintergrund. Das ist für den Endanwender jedoch nicht sichtbar, so dass diese technischen Details sich hauptsächlich in einer schnelleren Verarbeitungsgeschwindigkeit bemerkbar machen.

Einlesen der Daten

Zum Einlesen haben wir uns die Datei authorities-gnd_lds.nt.gz aus dem DNB Data Dump heruntergeladen. Anders als in unserem Apache Jena Projekt, müssen wir die Komprimierung der Daten vor dem Einlesen mit gzip -d authorities-gnd_lds.nt.gz auflösen. ¹

Wir arbeiten mit der folgenden Ordnerstruktur:

--- title: Ordnerstruktur config: look: handDrawn theme: neutral --- flowchart TD subgraph data[far:fa-folder-open data] fuseki[far:fa-folder oxigraph] gnd_triples[far:fa-folder gnd_triples] end root[far:fa-folder-open oxigraph_test] --> data root --> README[far:fa-file README.md]

README.md: Überblick über das Projekt und die Daten geben!
oxigraph: Ordner zum Persistieren der Datenbank von Oxigraph.
gnd_triples: Speicherort der .nt Datei.

Einlese-Variante 1

In dieser Variante lassen wir zuerst die Daten in einem Container einlesen und dann in einem neuen Container anzeigen. Der folgende Befehl startet einen Docker Container mit dem Verzeichnis der Daten zum Einlesen und einem Verzeichnis zum Speichern der Datenbank.

docker run -it --rm --name=gnd-oxigraph -v "${PWD}/data/gnd_triples:/gnd_triples" -v "${PWD}/data/oxigraph:/data" oxigraph/oxigraph --location /data load --file /gnd_triples/authorities-gnd_lds.nt

Sobald der Einleseprozess beendet wurde und der Container sich schließt, können wir einen neuen Container zum Arbeiten mit den Daten starten.

docker run -d --rm --name=gnd-oxigraph -p 8080:7878 -v "${PWD}/data/oxigraph:/data" oxigraph/oxigraph --location /data serve --bind=0.0.0.0:7878

Anschließend können wir die Benutzeroberfläche in einem Webbrowser über http://localhost:8080 aufrufen. Der Port 8080 wurde hierbei von uns im docker run Befehl gesetzt und kann angepasst werden.

Einlese-Variante 2

Wir können die Daten auch direkt in dem Arbeitscontainer einlesen lassen. Beim Starten des Containers müssen wir dabei zusätzlich den Pfad zu den GND Daten einbinden.

docker run -d --rm --name=gnd-oxigraph -p 8080:7878 -v "${PWD}/data/gnd_triples:/gnd_triples" -v "${PWD}/data/oxigraph:/data" oxigraph/oxigraph --location /data serve --bind=0.0.0.0:7878

Anschließend starten wir den Einleseprozess, indem wir den Befehl oxigraph_server load in dem laufenden Container ausführen.

docker exec -it gnd-oxigraph /usr/local/bin/oxigraph load --location /data --file /gnd_triples/authorities-gnd_lds.nt

3. Anzeigen der Daten

Abschließend testen wir exemplarisch, ob die Daten nutzbar sind. Hierfür verwenden wir eine SPARQL Abfrage mit einem Standardbeispiel aus der GND Ontology.

SELECT ?p ?o
WHERE {
 <https://d-nb.info/gnd/118514091> ?p ?o
}

Zusammenfassung und Ausblick

Oxigraph ist im Vergleich zu Apache Jena noch etwas grob an manchen Stellen und befindet sich noch in der aktiven Entwicklung. Es ist also gut möglich, dass die hier verwendeten Befehle in einer späteren Version nicht mehr so funktioniert oder Schritte wie das Auflösen der .gz-Komprimierung nicht mehr notwendig sind. ²

Bildschirmfoto der Weboberfläche von Oxigraph.

Überrascht waren wir von der Geschwindigkeit, mit der die Daten der GND eingelesen und Abfragen ausgeführt werden können. In der folgenden Tabelle ist ein direkter Vergleich mit unserem Apache Jena Setup für das Einlesens der GND und das Durchführens der Abfrage aus Erste Experimente mit der GND gelistet.

	GND laden	Testabfrage
Apache Jena	5.329,1s	17,5s
Oxigraph	391,0s	3,6s

Das ist natürlich kein ausführlicher oder repräsentativer Benchmark, zeigt aber direkt den Geschwindigkeitsunterschied mit den Daten mit denen wir aktuell arbeiten. Das ermöglichst uns zukünftig Umgebungen für Ad-Hoc Experimente mit der GND zu erstellen.

Wir haben für diesen Blogbeitrag Oxigraph in Version v0.3.8 und den GND Dump vom 13. Oktober 2022 verwendet. ↩︎
Dokumentation zur Verwendung des Oxigraph Docker Image ↩︎

NER Modell mit GND Starthilfe trainieren

Tue, 27 Sep 2022 00:00:00 +0000

In diesem Artikel beschäftigen wir uns mit dem Thema Named Entity Recognition. Wir trainieren ein eigenes Modell zur Erkennung von Kunst- und Kulturobjekten in unseren Erschließungsdaten und verwenden als Starthilfe die Gemeinsame Normdatei.

NER und Erschließung

Ein Arbeitsschritt bei der Erschließung ist die Erstellung von Deskriptoren, also die Identifikation von relevanten Entitäten in den zu verzeichnenden Archivalien. Dazu gehören relevante Körperschaften, Personen, Orte und Dinge. Wenn möglich, werden die identifizierten Entitäten zusätzlich mit passenden IDs aus der Gemeinsamen Normdatei (GND) versehen und somit semantisch verknüpft (Linked Data). Im Bereich des maschinellen Lernens werden diese beiden Schritte Named Entity Recognition (NER) und Named Entity Linking (NEL) genannt.

Dieser Arbeitsschritt findet in der Realität nicht unbedingt direkt bei der initialen Erfassung statt. Wir haben im Landesarchiv noch analoge Findmittel, die wir Retrodigitalisieren, und digitale Findbücher, bei der die Schlagworte (Deskriptoren) fehlen oder unvollständig sind.

In einem Experiment zur Vorbereitung eines Projektes im Kontext der Provenienzforschung testeten wir verschiedene Möglichkeiten NER zur Identifikation von beschriebenen Kunst- und Kulturobjekten in unseren Erschließungsdaten zu verwenden. ¹

NER im Kontext Archiv

Named Entity Recognition gehört zu den stabilen und gern genutzten KI Verfahren zur Extraktion von Informationen. Dafür gibt es schon vortrainierte Modelle, die innerhalb eines Natural Language Processing (NLP) Frameworks wie spaCy oder flair verwendet werden können. Für unser Experiment haben wir uns für spaCy als NLP Framework entschieden, da es ein für uns passendes Ökosystem mitbringt.

Hier ein mit NER verarbeiteter Beispieltext über das Landesarchiv Baden-Württemberg, welcher von der englischsprachigen Wikipedia angepasst wurde. ²

The State Archives ORG of Baden-Württemberg ( LABW ORG ) encompasses all state archives in Baden-Württemberg GPE .
The State Archives ORG of Baden-Württemberg is part of the portfolio of the Baden-Württemberg Ministry for Science, Research and Arts FAC .
It keeps historic documents that reach back to the middle ages DATE .
The current President of the State Archives ORG of Baden-Württemberg has been Prof. Dr. Gerald Maier PERSON since February 1st, 2018 DATE .
It employs around 250 CARDINAL people at 8 CARDINAL locations.

Das Model en_core_web_lg hat generell einen f-score von 0,85 und unterscheidet 18 Arten von Entitäten: CARDINAL, DATE, EVENT, FAC, GPE, LANGUAGE, LAW, LOC, MONEY, NORP, ORDINAL, ORG, PERCENT, PERSON, PRODUCT, QUANTITY, TIME und WORK_OF_ART. ³

Farblich hervorgehoben sind die vom Modell erkannten Entitäten und leicht abgesetzt der bestimmte Entitätentyp. Der f-score besagt in diesem Fall (vereinfacht!), dass in der Evaluation des Modells, von den gesuchten Entitäten etwa 85% gefunden wurden (Recall) und von den markierten Entitäten etwa 85% richtig markiert wurden (Precision). ⁴ In unserem von Wikipedia angepassten Beispieltext bestätigten sich diese Werte.

Hier ein mit NER verarbeiteter Beispieltext über das Landesarchiv Baden-Württemberg, welcher von der deutschsprachigen Wikipedia angepasst wurde. ⁵

Das Landesarchiv Baden-Württemberg LOC (LABW) umfasst alle baden-württembergischen MISC Staatsarchive.
Es gehört zum Geschäftsbereich des Ministeriums für Wissenschaft, Forschung und Kunst Baden-Württemberg. ORG
Es verwahrt historische Dokumente, die bis zum Mittelalter zurückreichen.
Der amtierende Präsident des Landesarchives PER ist seit dem 01. Februar 2018 Prof. Dr. Gerald Maier. PER
Es beschäftigt circa 250 Mitarbeiter an 8 Standorten.

Das Model de_core_news_lg hat einen f-score von 0,85 und unterscheidet 4 Arten von Entitäten: LOC, MISC, ORG, PER. ⁶

Das Modell für die deutsche Sprache erkennt und unterscheidet deutlich weniger Arten von Entitäten. Das hat damit zu tun, dass es für die deutsche Sprache keine so umfangreichen und frei verfügbaren Trainingsdaten gibt. Die Qualität der Erkennung (f-score) ist mit dem des englischsprachigen Modells vergleichbar. Aus Sicht deutschsprachiger Anwender ist es jedoch frustrierend sich auf vier Arten von Entitäten beschränken zu müssen.

Wenden wir das deutschsprachige Modell auf Texte in unseren Erschließungsdaten an, so gibt es noch ein weiteres Problem. ⁷

Besitzhinweis auf Mobiliar (hauptsächlich gekauft bei der Möbelfirma LOC Winfried Mueller, Stuttgart PER ), 1 vollständigen Silberkasten und mindestens 4 Silber-Becher.
Zahlung von 11100 fl. samt rückständigen neunjährigen Zinsen in Höhe von 4999 fl. oder Einsetzung in das adelige Gut Werenwag.
Gen. Forderung stammt aus Streit über Erbe des im November 1595 verst. K[C]aspar (von) Laubenberg. MISC
Entzug des ordentlichen Richters und Verstoß gegen Haigerlocher Evokationsprivileg PER durch Verschleppung kläg. Sohns gen. "junger Lenz" nach Sigmaringen, wo gegen ihn Kriminalprozeß PER angestrengt wurde.

Bei unseren Texten hat das Modell praktisch einen f-score von (nahe) 0. Das ist jedoch kein Problem des spaCy Modells, sondern ein generelles Problem von NER (Domänenproblem). Das auf allgemeinen Texten trainierte Modell funktioniert wie erwartet auf Wikipedia Texten, hat jedoch Probleme mit der speziellen Domäne der “Erschließungsdaten im LABW”.

Das bedeutet, dass wir für die meisten unserer Probleme keine vortrainierten Modelle verwenden können, sondern Modelle speziell für unsere Anwendungszwecke neu erstellen oder nachtrainieren müssen. Das erfordert aktuell

Technisch versierte Personen, die Daten Pipelines und Workflows erstellen können.
Fachpersonal, welches die entsprechenden Trainingsdaten erstellen kann.
Eine Softwareumgebung zur Erstellung der Trainingsdaten.
Eine Hardwareumgebung zum Trainieren der Modelle.

Da dies von den meisten kulturellen Einrichtungen nicht geleistet werden kann, arbeiten mehrere NFDI Konsortien, darunter NFDI4Culture und je nach Genehmigungsstatus ab nächstem Jahr NFDI4Memory daran, mögliche Lösungen für diese Anforderungen zu entwickeln und zur Verfügung zu stellen.

Da das FDMLab explizit dafür ausgelegt ist, solche Probleme zu untersuchen und damit wertvolle Vorarbeiten zu leisten, konnten wir uns dieses Problem ansehen und exemplarisch an einer konkreten Aufgabe durcharbeiten.

Trainieren eines NER Modells

Bei der Erstellung von Trainingsdaten für unser NER Modell waren wir mit dem so genannten “Kaltstart”-Problem konfrontiert. Das bedeutet, dass wir noch keine Trainingsdaten hatten und auch keine Möglichkeit diese auf einfache Art- und Weise zu “synthetisieren”. Da wir es in unserem speziellen Fall explizit mit Kunst- und Kulturobjekten zu tun haben und es in der GND einen umfangreichen Thesaurus mit Sachschlagworten gibt, hatten wir die Idee die Sachschlagworte in der GND als erste Grundlage zu verwenden und anschließend in einem aktiven Lernverfahren den Trainingsprozess für das Fachpersonal zu vereinfachen. ⁸

Vorbereitungen

Wir verwenden spaCy als NLP Framework und prodigy zur Erstellung der Trainingsdaten. Damit können wir basierend auf den Begriffen aus der GND eine Sammlung von Regeln hinterlegen, die automatisch Begriffe vorauswählen. ⁹

Dafür müssen die Daten aus der GND erst noch extrahiert und aufbereitet werden.

GND Daten extrahieren

Wie wir die GND in ihrer Linked Open Data (LOD) Form in einen lokalen Apache Jena Server laden, haben wir bereits ausführlich beschrieben. Die Schlagworte extrahieren wir anschließend via SPARQL zusammen mit ihren Varianten und GND Sachgruppen.

PREFIX gnd: <https://d-nb.info/gnd/>
PREFIX gndo: <https://d-nb.info/standards/elementset/gnd#>
PREFIX gndCat: <https://d-nb.info/standards/vocab/gnd/gnd-sc#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
SELECT DISTINCT ?gndID (SAMPLE(?namex) AS ?name) (SAMPLE(?variantsx) as ?variants) (GROUP_CONCAT(?categoryName; SEPARATOR="|") AS ?categories)
WHERE {
 ?gndID gndo:gndSubjectCategory ?category .
 ?category skos:prefLabel ?categoryName .
 FILTER ( lang(?categoryName) = "de")
 {
 SELECT DISTINCT ?gndID (SAMPLE(?prefName) AS ?namex) (GROUP_CONCAT(?variant; SEPARATOR="|") AS ?variantsx)
 WHERE {
 VALUES ?subjectType {
 gndo:SubjectHeading
 gndo:SubjectHeadingSensoStricto
 gndo:ProductNameOrBrandName
 }
 ?gndID rdf:type ?subjectType;
 gndo:preferredNameForTheSubjectHeading ?prefName .
 OPTIONAL { ?gndID gndo:variantNameForTheSubjectHeading ?variant } .
 }
 GROUP BY ?gndID
 }
}
GROUP BY ?gndID

Bei der Abfrage beschränken wir uns auf die Typen SubjectHeading, SubjectHeadingSensoStricto und ProductNameOrBrandName. Ein Begriff kann in der GND auch mit alternativen Benennungen gelistet werden (variants). Diese sind zwar hilfreich, jedoch nicht so umfassend wie die Daten im englischsprachen WordNet oder im lizenzpflichtigen deutschsprachigen GermaNet. Ein Begriff ist einer oder mehreren Sachgruppen zugeordnet.

In der folgenden Tabelle ist das Ergebnis der SPARQL-Abfrage mit fünf Ergebnissen gezeigt.

gndID	name	variants	categories
4300598-6	Tonnelierter Raum	Barrelled spaces \| Espace tonnelé	Mathematik
4207912-3	Götter <Motiv>		Sachliche Motive in der Kunst \| Literarische Motive, Stoffe, Gestalten
7528956-8	Pflanzenbeobachtung	Pflanzen / Beobachtung	Botanik (Allgemeines)
4379234-0	Freiwillige Selbstkontrolle	FSK \| Selbstkontrolle <Publizistik>	Film \| Presse \| Rundfunk, Neue Medien
4173231-5	Papstkrönung	Papst / Krönung	Kirchengeschichte \| Geschichte überregionaler Gebiete

GND Daten aufbereiten

Die in Tabellenform extrahierten Begriffe werden anschließend in OpenRefine aufbereitet und markiert. Dafür werden die mit | getrennten Varianten und Sachgruppen in einer Record-Struktur aufgelöst, sowie Ergänzungen in Klammern (<Motiv>, (Allgemeines), …) und Hierarchiezeichen (Papst / Krönung => Papst Krönung) mit regulären Ausdrücken entfernt.

Anschließend werden drei Datensätze erstellt:

GND ALL: enthält alle extrahierten Begriffe und Varianten
GND Groups: enthält alle Begriffe und Varianten in von uns markierten Sachgruppen
GND Selected: enthält alle separat von uns markierte Begriffe mit ihren Varianten

Bei der Identifikation von relevanten Sachgruppen ist unser Experiment zur GND Hierarchie Visualisierung eine große Hilfe.

Für jeden Datensatz wird mit Python anschließend ein einfacher Regelsatz (Simple) und ein komplexer Regelsatz (Complex) für spaCy erstellt.

Für den einfachen Regelsatz wird eine Regel mit dem Begriff in seiner bevorzugten Schreibweise erstellt. Besteht der Begriff aus mehreren Worten, so wird zusätzlich eine Regel für eine Schreibweise mit Bindestrichen und eine Regel für eine Schreibweise ohne Bindestriche oder Leerzeichen erstellt.

Hier am Beispiel des Begriffes Ludwigsburger Porzellan:

{"label": "OBJ", "pattern": "Ludwigsburger Porzellan"}
{"label": "OBJ", "pattern": "Ludwigsburger-Porzellan"}
{"label": "OBJ", "pattern": "Ludwigsburgerporzellan"}

Damit decken wir unterschiedliche Schreibweisen für zusammengesetzte Wörter und ggf. fehlende Leerzeichen ab. Tippfehler, andere grammatikalische Formen und Synonyme werden dadurch nicht gefunden.

Für den komplexen Regelsatz wird via regulären Ausdrücken zusätzlich die Option berücksichtigt, dass es weitere mit Bindestrich verbundene Wortbestandteile geben kann (Ludwigsburger-Porzellan-Tasse) und zusätzlich die Grundform des Wortes (Lemma) als Vergleichskriterium verwendet. ¹⁰

{"label": "OBJ", "pattern": [{"LEMMA": "Ludwigsburger"}, {"LEMMA": "Porzellan"}]}
{"label": "OBJ", "pattern": [{"LEMMA": {"REGEX": "Ludwigsburger\\-Porzellan((-|\\s)\\w+)?"}}]}
{"label": "OBJ", "pattern": [{"LEMMA": {"REGEX": "Ludwigsburgerporzellan((-|\\s)\\w+)?"}}]}

Durchführung

Annotation mit Regeln und aktivem Lernen

Mit dem Regelsatz GND Selected Simple wurden 1.000 Sätze mit regelbasierter Unterstützung manuell annotiert. ¹¹ Mit diesen wurde anschließend ein temporäres Modell trainiert, welches dabei unterstützte weitere 2.000 Sätze zu annotieren.¹²

Je nach verwendeter Beschreibungsform im Findbuch (Fließtext, Aufzählung, Liste, Tabelle, …) kann ein Satz zwischen 0 und mehr als 30 Entitäten enthalten.

Auf Grund von Duplikaten entstanden dadurch etwa 2.600 annotierte Sätze für das Training.

Zusätzlich wurden aus jedem der 59 untersuchten Findbüchern 2 zufällig ausgewählte Findbuchbeiträge extrahiert, wodurch ein Evaluations Datenset mit 1.677 eindeutigen Sätzen entstand. Dieses wurde von 2 Personen getrennt annotiert und anschließend die Unterschiede noch einmal besprochen und aufgelöst. ¹³

Das NER Modell wurde anschließend auf den Trainingsbeispielen neu trainiert und gegen das Evaluationsdatenset evaluiert. ¹⁴

Evaluation regelbasierter “Modelle”

Aus jedem der 6 Regeldatensätze wurde eine eigene spaCy Pipeline mit einer EntityRuler Komponente erstellt. ¹⁵ Diese 6 Pipelines wurden anschließend gegen das Trainings- und Evaluationsdatenset evaluiert. ¹⁶

Ergebnisse

	Begriffe		Gruppen
GND ALL	143.064	(100,00%)	339	(100,00%)
GND Groups	33.461	(23,39%)	27	(7,96%)
GND Selected	604	(0,42%)	80	(23,60%)

Insgesamt arbeiteten wir mit 143.061 Begriffen aus der GND (Varianten nicht mitgezählt). Bei der manuellen Auswahl der Sachgruppen wurden 27 Sachgruppen als relevant markiert. Bei der manuellen Auswahl der Begriffe wurden 604 Begriffe als relevant markiert.

Die 604 manuell markierten Begriffe sind insgesamt 80 unterschiedlichen Sachgruppen zugeordnet, wobei ein Begriff mehreren Sachgruppen zugeordnet werden kann.

Es war deutlich einfacher (und schneller) die 27 relevanten Sachgruppen zu identifizieren, als die 604 relevanten Begriffe herauszusuchen. Bei beiden Ansätzen war uns klar, dass wir aus Zeitgründen keine vollständige Auswahl treffen werden, so dass wir uns in der dafür aufgewendeten Zeit einschränkten.

Dataset	Precision	Recall	F1	Dataset	Precision	Recall	F1
GND ALL Simple	0,23	0,37	0,29	Complex	0,19	0,84	0,31
GND Groups Simple	0,33	0,34	0,34	Complex	0,31	0,76	0,44
GND Selected Simple	0,71	0,19	0,30	Complex	0,69	0,37	0,48
NER OBJ	0,96	0,94	0,95

Die Ergebnisse der obigen Tabelle sind in Abbildung 1 visualisiert und werden dort besprochen.

Scatterplot für Precision und Recall für die einzelnen Datensätze.

In Abbildung 1 lässt sich ablesen, dass die Verwendung der komplexen im Vergleich zu den einfachen Regeln den Recall, also den Anteil gefundener Begriffe, deutlich erhöht, wobei die Precision, also der Anteil an falsch markierten Begriffen, im Vergleich nur unwesentlich sinkt.

Es lässt sich ebenfalls ablesen, dass die Verwendung aller Begriffe in der GND (ALL) im Vergleich zur Verwendung der Begriffe ausgewählter Gruppen (Groups) den Recall erhöht, aber nicht so wesentlich, als dass es die deutlich schlechtere Precision ausgleichen könnte.

Mit einem f1-score von 0,48 erhält der Ansatz mit den ausgewählten Begriffen (Selected) den besten Wert der regelbasierten Ansätze. Mit einem f1-score von 0,95 ist das NER Modell den regelbasierten Ansätzen jedoch weit überlegen.

Diskussion

Grundsätzlich lässt sich sagen, dass sich die Idee die GND als Starthilfe für das Anlernen eines neuen NER Models zu verwenden, als erfolgreich erwiesen hat. Mit einem Recall und einer Precision über 90 Prozent könnten wir das anschließend trainierte NER Modell direkt produktiv anwenden. Auch die Verwendung der Sachbegriffe in der GND als Starthilfe hat deutlich besser funktioniert, als wir das erwartet hatten.

Ein wesentlicher Faktor, den wir bei diesem Experiment bewusst nicht erfasst haben, ist der zeitliche Aufwand für die einzelnen manuellen oder automatisierten Arbeitsschritte.

Hier machte eine genaue Erfassung in unserem Fall von daher keinen Sinn, da bei den manuellen Aufgaben ein großer Faktor der einmalige Einarbeitungsaufwand darstellt und die automatisierten Schritte auf Grund unterschiedlicher Lasten auf unserem Testsystem nicht deterministisch waren. Außerdem durchliefen wir verschiedene Iterationen, bis wir einem für uns passenden Workflow gefunden hatten.

Generell würden wir nach unserer Erfahrung davon abraten alle Sachbegriffe der GND, oder mehr als die von uns verwendeten circa 33.500 Begriffe zur Regelgenerierung zu verwenden. Nach unserer Beobachtung ist bei diesen Mengen und bei der Verwendung von regulären Ausdrücken in den Regeln das Laufzeitverhalten der Regelauswertung nicht mehr linear.

Bei der Abwägung, ob mit ausgewählten Begriffen oder ausgewählten Sachgruppen gearbeitet wird, sollte auch die Präferenz des Fachpersonals im Annotationsprozess berücksichtigt werden. Bei einer hohen Precision müssen hauptsächlich zusätzliche Begriffe markiert werden. Bei einem hohen Recall (und niedriger Precision) müssen hauptsächlich falsch markierte Begriffe entfernt werden.

Außerdem haben wir uns bei der initialen Auswahl der Sachbegriffe aus der GND auf bestimmte Typen beschränkt (SubjectHeading, SubjectHeadingSensoStricto und ProductNameOrBrandName). Diese Einschränkung machte für uns Sinn, jedoch sind manche der von uns gesuchten Objekte auch unter den Typen Work bzw. dessen Unterklassen zu finden, oder in der GND als Corporate Body klassifiziert.

Die Entscheidung aus jedem Bestand 2 zufällige Findbucheinträge für das Evaluationsdatenset zu verwenden, sorgte für ein ungünstiges Größenverhältnis zwischen Trainings- und Evaluationsdatenset. Zum einen ist das Evaluationsdatenset recht groß im Vergleich zum Trainingsdatenset. Zum anderen ist es durch die Unterschiede zwischen den einzelnen Beständen nicht repräsentativ. So gibt es eine große Varianz in der Größe der einzelnen Bestände (1 - 1321 Findbucheinträge) und der unterschiedlichen Länge der einzelnen Findbucheinträge (6 - 47.249 Zeichen).

Bei der praktischen Anwendung des trainierten Modells konnten wir feststellen, dass die Performanz des Modells auf den größeren Beständen merkbar schlechter war, so dass wir in der praktischen Anwendung eher mit einer Precision und einem Recall im Bereich von etwa 90 Prozent rechnen.

Theoretisch könnte die Performanz des Modells noch deutlich verbessert werden, indem unter anderem weitere Trainingsbeispiele erstellt werden und zusätzlich eine Hyperparameteroptimierung durchgeführt wird.

Fazit

Named Entity Recognition kann bei der Erstellung von Metadaten von textbasierten Material eine große Hilfe sein. Leider lassen sich auf allgemeinen Texten trainierte Modelle meist nicht auf Texte im Archiv übertragen. Ein Trainieren von eigenen NER-Modellen ist mit guten Ergebnissen und vertretbarem Aufwand möglich. Dabei ist die Gemeinsame Normdatei eine hilfreiche Datenquelle. Jedoch fehlt es vielen kulturellen Institutionen an einem Zugang zu technischem Personal und Infrastruktur. Wir hoffen, dass Lösungen von der NFDI zukünftig diese Lücken schließen können.

Da die bearbeiteten Daten teilweise noch einer Sperrfrist unterliegen, können wir zu diesem Zeitpunkt weder die Daten noch die Modelle bzw. konkrete Ergebnislisten veröffentlichen. Es macht daher auch keinen Sinn eine reproduzierbaren Workflow zu veröffentlichen. ↩︎
Wikipedia Autoren, „Landesarchiv Baden-Württemberg“, Wikipedia – Die freie Enzyklopädie, https://de.wikipedia.org/w/index.php?title=Landesarchiv_Baden-W%C3%BCrttemberg&oldid=223510351 (aufgerufen am 20. Juli 2022). ↩︎
NER erstellt mit spaCy 3.3 en_core_web_lg. ↩︎
Siehe Wikipedia - Precision and recall für Details. ↩︎
Wikipedia Autoren, „Landesarchiv Baden-Württemberg“, Wikipedia – Die freie Enzyklopädie, https://de.wikipedia.org/w/index.php?title=Landesarchiv_Baden-W%C3%BCrttemberg&oldid=223510351 (aufgerufen am 20. Juli 2022). ↩︎
NER erstellt mit spaCy 3.3 de_core_news_lg. ↩︎
NER erstellt mit spaCy 3.3 de_core_news_lg. ↩︎
Siehe Wikipedia - Active Learning. ↩︎
Siehe Rule-based matching und Manual annotation with patters. ↩︎
Siehe Wikipedia - Lemma (Lexikographie) ↩︎
Manual annotation with patters bzw. Prodigy Rezept ner.manual. ↩︎
Manual annotation with suggestions from a model bzw. Prodigy Rezept ner.correct. ↩︎
Prodigy Rezept review ↩︎
spaCy CLI evaluate ↩︎
Language Processing Pipelines bzw. Rule-based matching bzw. EntityRuler. ↩︎
Bei dem regelbasierten Ansatz ist eine Überanpassung nicht zu befürchten, da es sich hier um keinen selbst lernenden Prozess handelt. ↩︎

Experiment zur Identifikation von doppelten Orten in der GND

Tue, 21 Jun 2022 00:00:00 +0000

Bei unserer Arbeit mit Orten in der Gemeinsamen Normdatei (GND) stolperten wir hin und wieder über Dubletten. Also Orte, die in der GND mehrfach vorhanden waren. Dieser Beitrag beschreibt, wie wir in einem praktischen Experiment versuchten diese Dubletten innerhalb des Bundeslandes Baden-Württemberg zu identifizieren.

Bildnachweis¹

Hintergrund

In der GND sind nicht nur aktuelle Orte mit einer eindeutigen GND-Nummer verzeichnet, sondern auch historische Orte. Beispielsweise wurde Cannstatt mit Stuttgart vereinigt und ist seit dem 1. April 1905 als Stuttgart-Cannstatt und später Bad Cannstatt ein Stadtteil von Stuttgart.

Auch wurden Gemeinden und Städte im Zuge von Kreis- und Gemeindereformen eingemeindet oder neu gebildet. Beispielsweise wurden Bissingen und Bietigheim im Jahre 1975 zu Bietigheim-Bissingen zusammengelegt.

Diese Form von Mehrfachnennung meinen wir nicht. Wir sind darüber gestolpert, dass es speziell zu historischen Orten in Baden-Württemberg mehrere Einträge gab.

Idee

Wir wollen basierend auf der Ortsnamensdatenbank Baden-Württemberg (ONDB) mögliche Dubletten von Orten in Baden-Württemberg in der GND identifizieren. Die ONDB wurde in einem anderen Projekt in Form einer Datenspende in die GND eingespielt, so dass wir davon ausgehen, dass wir sie als “Referenz” verwenden können. Dafür identifizieren wir alle mit Baden-Württemberg verknüpften Orte in der GND, markieren die Orte, die in der ONDB vorliegen und betrachten anschließend die Restmenge.

Vorgehen

1. ONDB Aufbereitung

Ein Abzug der ONDB wurde im Kontext eines anderen Projektes mit OpenRefine aufgearbeitet, so dass ein Mapping von GND-ID auf ONDB-ID möglich ist. Wie so ein Mapping funktioniert, ist unter Daten zwischen Projekten in OpenRefine abgleichen beschrieben.

2. GND in Triple-Store laden

Wie unter Erste Experimente mit der GND beschrieben, wurde die GND in ihrer LOD-Form in einen Apache Jena Docker Container geladen. ²

3. Daten aus Triple-Store laden

Mit SPARQL-Abfragen werden die Daten aus dem Apache Jena Triple-Store extrahiert.

4. Dubletten identifizieren

Mit Hilfe der ODNB, Clustering Methoden in OpenRefine und externen Skripten mögliche Dubletten identifizieren und manuell prüfen.

SPARQL Abfrage(n)

wir haben verschiedene Methoden getestet, verworfen und kombiniert, um die für uns relevanten Orte in der GND zu identifizieren und via SPARQL aus dem Apache Jena Triple-Store laden zu können.

Angaben zur Quelle

In der GND ist auch die Quelle einer Dateninformation erfasst, also zum Beispiel die ONDB oder das Landesarchiv Baden-Württemberg als Datenquelle genannt. Diese Information ist in der LOD-Form der GND leider nicht enthalten. Daher konnten wir diese Information nicht als zusätzliche Informationsquelle für unsere Filter nutzen.

Verknüpfung über Hierarchie

Theoretisch sollten wir über den Property-Path Hierarchical superior of place or geographic name alle untergeordneten Orte von Baden-Württemberg finden können.

PREFIX gnd: <https://d-nb.info/gnd/>
PREFIX gndo: <https://d-nb.info/standards/elementset/gnd#>

SELECT DISTINCT ?place
WHERE {
 ?place gndo:hierarchicalSuperiorOfPlaceOrGeographicName+ gnd:4004176-1 .
}

Diese Eigenschaft ist jedoch nicht konsequent und speziell für historische Orte gar nicht erfasst. Daher haben wir diesen Ansatz verworfen.

Verknüpfung über Ländercode

Theoretisch sollten wir über die Verknüpfung mit dem Ländercode (Geographic Area Code) alle mit Baden-Württemberg (XA-DE-BW) verknüpften Orte erfassen können.

PREFIX gnd: <https://d-nb.info/gnd/>
PREFIX gndo: <https://d-nb.info/standards/elementset/gnd#>
PREFIX gnd-area-code: <https://d-nb.info/standards/vocab/gnd/geographic-area-code#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT DISTINCT ?place
WHERE {
 ?place gndo:geographicAreaCode gnd-area-code:XA-DE-BW ;
 rdf:type ?type .
 ?type rdfs:subClassOf* gndo:PlaceOrGeographicName .
}

Hier sind uns zwei Probleme aufgefallen:

die Property-Path-Extension rdfs:subclassOf* funktioniert nicht, wir konnten jedoch nicht klären ob das ein Problem mit Apache Jena oder mit den GND-Daten ist.
Nicht alle Orte in Baden-Württemberg sind mit dem Ländercode XA-DE-BW angelegt, sondern einige auch ausschließlich mit dem Ländercode für Deutschland XA-DE.

Verknüpfung über Ländercode mit Aufzählung aller (Sub-)Klassen

Da die Property-Path Extension auf rdfs:subClassOf nicht funktioniert hat, listen wir die für uns relevanten (Sub-)Klassen alle einzeln auf.

PREFIX gnd: <https://d-nb.info/gnd/>
PREFIX gndo: <https://d-nb.info/standards/elementset/gnd#>
PREFIX gnd-area-code: <https://d-nb.info/standards/vocab/gnd/geographic-area-code#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

SELECT DISTINCT ?place
WHERE {
 VALUES ?geographicType
 {
 gndo:PlaceOrGeographicName
 gndo:AdministrativeUnit
 gndo:BuildingOrMemorial
 gndo:NameOfSmallGeographicUnitLyingWithinAnotherGeographicUnit
 gndo:NaturalGeographicUnit
 gndo:ReligiousTerritory
 gndo:TerritorialCorporateBodyOrAdministrativeUnit
 }
 ?place gndo:geographicAreaCode gnd-area-code:XA-DE-BW ;
 rdf:type ?geographicType .
}

Anzahl pro (Sub-)Klasse

Die folgende Abfrage zählt, wie häufig die entsprechenden Typen für Orte in Baden-Württemberg in der GND vorkommen.

PREFIX gnd: <https://d-nb.info/gnd/>
PREFIX gndo: <https://d-nb.info/standards/elementset/gnd#>
PREFIX gnd-area-code: <https://d-nb.info/standards/vocab/gnd/geographic-area-code#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

SELECT DISTINCT ?geographicType (count(?geographicType) as ?count)
WHERE {
 VALUES ?geographicType
 {
 gndo:PlaceOrGeographicName
 gndo:AdministrativeUnit
 gndo:BuildingOrMemorial
 gndo:NameOfSmallGeographicUnitLyingWithinAnotherGeographicUnit
 gndo:NaturalGeographicUnit
 gndo:ReligiousTerritory
 gndo:TerritorialCorporateBodyOrAdministrativeUnit
 }
 ?place gndo:geographicAreaCode gnd-area-code:XA-DE-BW ;
 rdf:type ?geographicType .
} GROUP BY ?geographicType

In der folgenden Tabelle ist das Ergebnis für die obige SPARQL-Abfrage dargestellt:

geographicType	count
AdministrativeUnit	423
NaturalGeographicUnit	537
PlaceOrGeographicName	4205
ReligiousTerritory	68
TerritorialCorporateBodyOrAdministrativeUnit	23685
BuildingOrMemorial	3711
NameOfSmallGeographicUnitLyingWithinAnotherGeographicUnit	99

DE-Ländercode mit Nachfolger (oder Vorgänger) in BW

Bei den Orten, die mit dem Ländercode XA-DE für Deutschland angelegt wurden, ergab sich ein Muster. Diese hatten häufig einen Vorgänger oder Nachfolger, der mit dem Ländercode XA-DE-BW für Baden-Württemberg verknüpft war.

Die folgende SPARQL-Abfrage zeigt, wie diese Orte abgefragt werden können.

PREFIX gnd: <https://d-nb.info/gnd/>
PREFIX gndo: <https://d-nb.info/standards/elementset/gnd#>
PREFIX gnd-area-code: <https://d-nb.info/standards/vocab/gnd/geographic-area-code#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT DISTINCT ?place
WHERE {
 VALUES ?geographicType
 {
 gndo:PlaceOrGeographicName
 gndo:AdministrativeUnit
 gndo:BuildingOrMemorial
 gndo:NameOfSmallGeographicUnitLyingWithinAnotherGeographicUnit
 gndo:NaturalGeographicUnit
 gndo:ReligiousTerritory
 gndo:TerritorialCorporateBodyOrAdministrativeUnit
 }
 ?place gndo:geographicAreaCode gnd-area-code:XA-DE ;
 rdf:type ?geographicType ;
 (gndo:precedingPlaceOrGeographicName+ | gndo:succeedingPlaceOrGeographicName+) ?relatedPlace .
 ?relatedPlace gndo:geographicAreaCode gnd-area-code:XA-DE-BW .
}

Finale SPARQL-Abfrage

Die folgende SPARQL-Abfrage kombiniert die Orte, die mit dem XA-DE-BW für Baden-Württemberg angelegt wurden mit denen, die einen mit dem Ländercode XA-DE-BW für Baden-Württemberg verknüpften Vorgänger oder Nachfolger haben.

Zusätzlich werden noch die Eigenschaften Bevorzugter Name des Geographikums und die Definition abgefragt. Da diese nicht zuverlässig gesetzt wurden, sind sie als OPTIONAL gekennzeichnet.

Da wir die GND-ID eindeutig halten wollen, diese aber gegebenenfalls mit mehreren geographischen Typen verknüpft sein kann, nutzen wir eine Gruppierung via GROUP BY um doppelte GND-IDs zu filtern.

PREFIX gnd: <https://d-nb.info/gnd/>
PREFIX gndo: <https://d-nb.info/standards/elementset/gnd#>
PREFIX gnd-area-code: <https://d-nb.info/standards/vocab/gnd/geographic-area-code#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

SELECT ?place (SAMPLE(?geographicType) as ?GeographicType) (SAMPLE(?preferredName) as ?PreferredName) (SAMPLE(?definition) as ?Definition)
WHERE {
 VALUES ?geographicType
 {
 gndo:PlaceOrGeographicName
 gndo:AdministrativeUnit
 gndo:BuildingOrMemorial
 gndo:NameOfSmallGeographicUnitLyingWithinAnotherGeographicUnit
 gndo:NaturalGeographicUnit
 gndo:ReligiousTerritory
 gndo:TerritorialCorporateBodyOrAdministrativeUnit
 }
 {
 ?place gndo:geographicAreaCode gnd-area-code:XA-DE-BW ;
 rdf:type ?geographicType .
 OPTIONAL {
 ?place gndo:preferredNameForThePlaceOrGeographicName ?preferredName
 }.
 OPTIONAL {
 ?place gndo:definition ?definition
 }.
 }
 UNION
 {
 ?place gndo:geographicAreaCode gnd-area-code:XA-DE ;
 rdf:type ?geographicType ;
 (gndo:precedingPlaceOrGeographicName+ | gndo:succeedingPlaceOrGeographicName+) ?relatedPlace .
 ?relatedPlace gndo:geographicAreaCode gnd-area-code:XA-DE-BW .
 OPTIONAL {
 ?place gndo:preferredNameForThePlaceOrGeographicName ?preferredName
 }.
 OPTIONAL {
 ?place gndo:definition ?definition
 }.
 }
} GROUP BY ?place

Ergebnisse

Mit der oben beschriebenen SPARQL-Abfrage konnten etwa 33.000 zu Baden-Württemberg zuordenbare Orte aus der GND in unserem Apache Jena Triple-Store extrahiert werden.

Innerhalb dieser Daten konnten etwa 600 eindeutige Dubletten und deren Ursprung identifiziert und der GND Fachstelle zur Korrektur vorgelegt werden. Das entspricht etwa zwei Prozent der gefunden Daten.

Bei der Analyse der Dubletten ist aufgefallen, dass nach wie vor die historische Vorbelastung der GND durch die Verschmelzung der Gemeinsamen Körperschaftsdatei (GKD) mit der Schlagwortnormdatei (SWD) für einen Großteil der Dubletten verantwortlich war. Zusätzlich gab es einzelne Datenlieferungen, die ebenfalls für Dubletten geführt haben.

Beim Identifikationsprozess für Dubletten ist aufgefallen, dass besonders das unterschiedliche Vorgehen bei der “Vorzugsbenennung” eines Ortes zu den vielen nicht offensichtlichen Dubletten geführt hat. Beispielsweise lässt sich Bad Cannstatt auch als Stuttgart-Cannstatt benennen, was weder bei einer alphabetischen Sortierung, noch bei den meisten Standardverfahren zum algorithmischen Abgleich von Dubletten auffällt.

Insgesamt haben wir vermutlich auch nur einen Teil der Dubletten für Orte in Baden-Württemberg in der GND identifiziert. Unter anderem fallen alle Orte durch unsere Suchfilter, die Baden-Württemberg nicht als Geographic Area Code definiert haben und auch keine mit Baden-Württemberg verknüpften Vorgänger oder Nachfolger haben.

Das Bild “Doppelte Orte in der GND identifizieren” wurde erstellt mit Bildern von Peggy und Marco Lachmann-Anke und Gerd Altmann auf Pixabay und dem “Logo Gemeinsame Normdatei (GND)” von Deutsche Nationalbibliothek (DNB), welches lizenziert ist unter einer CC BY-SA 4.0 Lizenz. Das Bild “Doppelte Orte in der GND identifizieren” ist ebenfalls lizenziert unter einer CC BY-SA 4.0 Lizenz. ↩︎
Der für dieses Experiment verwendete Abzug ist authorities_lds_20211013.nt.gz. ↩︎

Erste Experimente mit der GND

Tue, 29 Jun 2021 00:00:00 +0000

Die Gemeinsame Normdatei (GND) enthält unter anderem semantische Daten zu Personen und Orten. In diesem Beitrag verwenden wir SPARQL um die Daten und die Ontologie dahinter besser kennen zu lernen.

Wir versuchen mit der GND die folgende Frage zu beantworten:

Welche Berufe gab es Nürnberg im 17. Jahrhundert.

Zur Beantwortung dieser Frage verwenden wir unseren lokalen Apache Jena Server. Die SPARQL-Anfragen können entweder in der Web GUI von Apache Jena ausgeführt werden, oder mit einer der vielen SPARQL-Clients¹.

Lade Beispielperson

In der GND Ontology sind einige Beispiel Entities genannt. Wir laden hier das Beispiel für eine Individualisierte Person der GND ID 118514091.

PREFIX gnd: <https://d-nb.info/gnd/>
PREFIX gndo: <https://d-nb.info/standards/elementset/gnd#>

SELECT ?p ?o
WHERE {
 gnd:118514091 ?p ?o .
}

p	o
http://www.w3.org/1999/02/22-rdf-syntax-ns#type	gndo:DifferentiatedPerson
http://www.w3.org/2002/07/owl#sameAs	http://www.wikidata.org/entity/Q5383
gndo:gndIdentifier	118514091
gndo:preferredNameForThePerson	Bowie, David
gndo:biographicalOrHistoricalInformation	spielt zahlreiche Instrumente
gndo:homepage	http://www.davidbowie.com
gndo:placeOfBirth	gnd:4074335-4
gndo:placeOfDeath	gnd:4042011-5
gndo:dateOfBirth	1947-01-08
gndo:dateOfDeath	2016-01-10
gndo:professionOrOccupation	gnd:4040841-3
gndo:professionOrOccupation	gnd:4032009-1
gndo:professionOrOccupation	gnd:4052154-0
gndo:professionOrOccupation	gnd:4124099-6
gndo:professionOrOccupation	gnd:4167564-2
gndo:professionOrOccupation	gnd:7628944-8
…	…

Die Anzahl der Trippel wurde aus Darstellungsgründen gekürzt. Bei der Person handelt es sich um David Bowie. Wir erhalten unter anderem weitere Verweise auf andere Graphen mit Informationen über David Bowie, persönliche Daten über ihn, sowie eine Liste in der GND definierter Berufe und Tätigkeiten, die er ausgeübt hat.

Berufe und Tätigkeiten von David Bowie

Als Nächstes suchen wir die Berufe und Tätigkeiten von David Bowie und berücksichtigen dabei auch alternativen Schreibweisen und Bezeichnungen der Berufe. Dafür verwenden wir die Verbindung professionOrOccupation. Alternativ gibt es die Verbindung professionOrOccupationAsLiteral, die in unseren Tests aber einige fehlerhaft geparste Daten beinhaltete (Zahlen, Buchstaben, …) oder Zusatzinformationen lieferte (z.B. Zeitraum in der eine Tätigkeit ausgeübt wurde). Der Beruf ist in der GND als Schlagwort (engl. subject heading) hinterlegt. Daher holen wir uns für das Schlagwort die bevorzugte Bezeichnung und alternative Bezeichnungen.

PREFIX gnd: <https://d-nb.info/gnd/>
PREFIX gndo: <https://d-nb.info/standards/elementset/gnd#>

SELECT DISTINCT ?job
WHERE {
 gnd:118514091 gndo:professionOrOccupation ?jobId .
 ?jobId gndo:preferredNameForTheSubjectHeading|gndo:variantNameForTheSubjectHeading ?job .
}

Musiker, Musikschaffender, Komponist, Tonsetzer, Schauspieler, Darsteller (Schauspieler), Sänger, Konzertsänger, Librettist, Textdichter (Librettist), Bandleader, ld

Zur Übersichtlichkeit haben wir an dieser Stelle eine Listendarstellung für die Ergebnisse gewählt.

Berufe und Tätigkeiten in Nürnberg (fixiert)

Nachdem wir herausgefunden haben, wie wir die Berufe und Tätigkeiten einer Person aus der GND auslesen können, verknüpfen wir diese Information mit einem Ort. Konkret mit dem Ort Nürnberg, welches die GND ID 4042742-0 hat. Hierfür suchen wir zuerst nach Personen, die über eine Auswahl von Eigenschaften (z.B. Geburtsort) mit Nürnberg verknüpft sind und suchen dann nach deren Berufsbezeichnungen.

PREFIX gnd: <https://d-nb.info/gnd/>
PREFIX gndo: <https://d-nb.info/standards/elementset/gnd#>

SELECT DISTINCT ?job
WHERE {
 ?person gndo:placeOfBirth|gndo:placeOfDeath|gndo:placeOfActivity|gndo:placeOfExile|gndo:characteristicPlace gnd:4042742-0 ;
 gndo:professionOrOccupation ?jobId .
 ?jobId gndo:preferredNameForTheSubjectHeading|gndo:variantNameForTheSubjectHeading ?job .
}
LIMIT 20

Künstler, Bildender Künstler, Künstlertum, Kunstschaffender, Grafiker, Graphiker, Kupferstecher, Maler, Mathematiker, Diplommathematiker, Zeichner, Musiker, Musikschaffender, Dirigent, Orchesterleiter, Chorleiter, Chorregent, Chordirektor, Chormeister, Chordirigent

Um eine übersichtliche Ergebnismenge zu erhalten, haben wir die Anzahl der Ergebnisse auf 20 limitiert.

Berufe und Tätigkeiten in Nürnberg (frei)

In der letzten Anfrage haben wir die Art der Verknüpfung von Personen mit dem Ort Nürnberg fixiert. Dazu gehört ein intensives Studieren der GND Ontoloy.

Es geht auch einfacher. In der folgenden Anfrage suchen wir nach Personen, die in irgendeiner Beziehung zu Nürnberg stehen (?person ?p gnd:4042742-0) und suchen dann die Berufsbezeichnungen.

Theoretisch erhöhen wir dadurch die Trefferquote, verringern aber die Genauigkeit. Praktisch spielte das in unseren Experimenten keine Rolle.

PREFIX gnd: <https://d-nb.info/gnd/>
PREFIX gndo: <https://d-nb.info/standards/elementset/gnd#>

SELECT DISTINCT ?job
WHERE {
 ?person ?p gnd:4042742-0 ;
 gndo:professionOrOccupation ?jobId .
 ?jobId gndo:preferredNameForTheSubjectHeading|gndo:variantNameForTheSubjectHeading ?job .
}
LIMIT 20

Künstler, Bildender Künstler, Künstlertum, Kunstschaffender, Grafiker, Graphiker, Kupferstecher, Maler, Mathematiker, Diplommathematiker, Zeichner, Physiker, Astronom, Astronomen, Kartograf, Kartograph, Pfarrer, Pastor, Evangelischer Theologe, Theologe / Evangelische Kirche

Die Ergebnisse dieser Vorschau unterscheiden sich von der letzten Abfrage, da der Graph in einer anderen Reihenfolge traversiert wird. Vergleicht man die Gesamtmenge der Ergebnisse, dann unterscheiden sie sich nur in der Reihenfolge der Elemente.

Berufe und Tätigkeiten in Nürnberg im 17. Jahrhundert

Um die Anfrage aus dem letzten Beispiel auf das 17. Jahrhundert einzuschränken, fügen wir einen Filter für das Geburtsdatum und das Sterbedatum der Personen hinzu.

Der Vollständigkeit halber, haben wir gndo:dateOfBirth und gndo:dateOfDeath optional gesetzt. Das verhindert, dass wir ungewollt Personen filtern, bei denen eines der beiden Daten fehlt. Daher brauchen wir noch ein extra Filterkriterium, welches das Geburtsdatum nach unten und das Todesdatum nach oben beschränkt².

PREFIX gnd: <https://d-nb.info/gnd/>
PREFIX gndo: <https://d-nb.info/standards/elementset/gnd#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

SELECT DISTINCT ?job
WHERE {
 ?person ?p gnd:4042742-0 ;
 gndo:professionOrOccupation ?jobId .
 ?jobId gndo:preferredNameForTheSubjectHeading|gndo:variantNameForTheSubjectHeading ?job .
 OPTIONAL { ?person gndo:dateOfBirth ?birthDay . }
 OPTIONAL { ?person gndo:dateOfDeath ?deathDay . }
 FILTER ( bound(?birthDay) || bound(?deathDay) ) .
 FILTER ( bound(?birthDay) && ?birthDay >= "1501-01-01"^^xsd:date && ?birthDay < "1701-01-01"^^xsd:date ) .
 FILTER ( bound(?deathDay) && ?deathDay >= "1601-01-01"^^xsd:date && ?deathDay < "1801-01-01"^^xsd:date ) .
}
LIMIT 20

Kupferstecher, Zeichner, Künstler, Bildender Künstler, Künstlertum, Kunstschaffender, Maler, Radierer, Buchhändler, Buchführer, Drucker, Buchdrucker, Verleger, Verlagsbuchhändler, Verlagsleiter, Musikverleger, Pfarrer, Pastor, Jurist, Rechtswissenschaftler

Methodische Probleme

Bevor wir mit diesen Ergebnissen versuchen spezifische Aussagen zu treffen, sollten wir zuerst einige methodische Probleme betrachten.

💼 Beruf und 🏠 Ort

Die Verknüpfung von Beruf und Ort lässt sich in der GND nur über eine 👤 Person herstellen. Mit den vorliegenden Daten kann jedoch nicht festgestellt werden, ob die 👤 Person den Beruf (oder die Tätigkeit) auch an diesem Ort ausgeübt hat. Zum Beispiel wurde Albert Einstein in Ulm geboren, hat den Beruf des Physikers dort jedoch nie ausgeübt.

📅 Zeit und 🏠 Ort

Mit dem Filter auf Geburtsdatum und Sterbedatum haben wir zwar eine grobe Einschränkung getroffen. Es ist jedoch nicht zu bestimmen, ob eine 👤 Person mit Sterbedatum 1601 ihren Beruf im 17. Jahrhundert noch ausgeübt hat. Es ist sicherlich auszuschließen, dass die meisten 👥 Personen mit einem Geburtsdatum von 1699 ihren Beruf im 17. Jahrhundert schon ausgeübt haben.

📜 Datengrundlage

Die GND beinhaltet (noch) keinen repräsentative Darstellung der Gesamtbevölkerung. Es gibt einen starken Bias in Richtung 👥 Personen, die schriftliche Erzeugnisse produzierten, oder künstlerisch tätig waren. Das wird im folgenden Beispiel deutlich.

Berufe und Tätigkeiten in Nürnberg im 17. Jahrhundert mit Häufigkeit

Anstatt wie zuvor alle Berufe und Tätigkeiten mit alternativen Bezeichnungen zu sammeln, schreiben wir hier eine Auswertung, die die Häufigkeit der einzelnen Berufe und Tätigkeiten bestimmt. Die alternativen Bezeichnungen, werden in einer separaten Spalte der Ausgabetabelle gesammelt.

PREFIX gnd: <https://d-nb.info/gnd/>
PREFIX gndo: <https://d-nb.info/standards/elementset/gnd#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

SELECT ?job (COUNT(?job) AS ?count) (GROUP_CONCAT(DISTINCT ?jobAlternative; SEPARATOR=", ") AS ?alternatives)
WHERE {
 ?person ?p gnd:4042742-0 ;
 gndo:professionOrOccupation ?jobId .
 ?jobId gndo:preferredNameForTheSubjectHeading ?job ;
 gndo:variantNameForTheSubjectHeading ?jobAlternative .
 OPTIONAL { ?person gndo:dateOfBirth ?birthDay . }
 OPTIONAL { ?person gndo:dateOfDeath ?deathDay . }
 FILTER ( bound(?birthDay) || bound(?deathDay) ) .
 FILTER ( bound(?birthDay) && ?birthDay >= "1501-01-01"^^xsd:date && ?birthDay < "1701-01-01"^^xsd:date ) .
 FILTER ( bound(?deathDay) && ?deathDay >= "1601-01-01"^^xsd:date && ?deathDay < "1801-01-01"^^xsd:date ) .
}
GROUP BY ?job
ORDER BY DESC(?count)

job	count	alternatives
Kaufmann	270	Kaufleute, Fernkaufmann, Fernhandelskaufmann, Großkaufmann, Handelsmann
Jurist	270	Rechtswissenschaftler, Juristischer Beruf, Juristen
Patriziat	164	Patrizier, Stadtadel
Schriftsteller	156	Dichter, Literaturproduzent, Literat, Homme de lettres
Hochschullehrer	120	Professor (Hochschule), Lehrkörper / Hochschule, Lehrpersonal / Hochschule, Universitätsprofessor, Hochschulprofessor
Verleger	104	Verlagsbuchhändler, Verlagsleiter
Pfarrer	94	Pastor
Arzt	76	Mediziner, Ärzte
Künstler	72	Bildender Künstler, Künstlertum, Kunstschaffender
Unternehmer	57	Industrieller, Fabrikant, Entrepreneur
…	…	…

Zur Übersichtlichkeit haben wir die Tabelle auf 10 Einträge reduziert, sie kann als

CSV komplett heruntergeladen werden.

Silhouette der Kaiserburg in Nürnberg, mit nach Häufigkeit gewichteter Wortwolke, der in der GND gelisteten Berufe und Tätigkeiten im 17. Jahrhundert, mit einer Verbindung zu Nürnberg.

Wenn man einen Blick auf diese Auswertung wirft, wird schnell klar, dass dies weder eine repräsentative, noch eine vollständige Darstellung der Berufe und Tätigkeiten im 17. Jahrhundert in Nürnberg darstellt. Für unseren Streifzug durch die Daten der GND war die Fragestellung jedoch sehr hilfreich. Und auch im Archivalltag haben wir immer wieder Rechercheaufgaben, in denen konkret nach Personen mit einem bestimmten Beruf gesucht werden, die in einem bestimmten Zeitraum in einer Stadt gelebt haben.

Wir verwenden sparql_dataframe. ↩︎
Die 100 Jahre sind etwas großzügig, wir erhöhen damit die Trefferquote und verringern die Genauigkeit. ↩︎

GND in lokale Datenbank laden

Tue, 22 Jun 2021 00:00:00 +0000

Normdaten sind hilfreiche und notwendige Datenquellen zum Aufbereiten, Erschließen und Finden von Archivmaterial. In diesem Beitrag laden wir die Gemeinsame Normdatei (GND) zur Weiterverarbeitung in einen lokalen Triple Store von Apache Jena.

GND Logo von der
DNB unter CC BY-SA Lizenz.

Über die Gemeinsame Normdatei

Die GND ist ein von der Deutschen National Bibliothek (DNB) betreuter Dienst zur kooperativen Nutzung von Normdaten. Im Archivbereich interessieren wir uns insbesondere für eindeutig zu identifizierende Personen, Orte und Dinge.

Die GND liegt im Format MARC 21 und in RDF vor und kann über unterschiedliche Schnittstellen abgerufen werden. Wir konzentrieren uns hier auf die GND Daten im RDF Format, da wir diese effektiver durchsuchen können. Zum heutigen Stand gibt es von Seiten der DNB keinen SPARQL Endpoint für den Zugriff auf die Daten¹. Daher spielen wir einen Daten Dump in eine lokale Datenbank ein. Die Verwendung der Daten in einem Memory basierten Graphen z.B. mit RDFlib funktioniert auf Grund der Größe des Graphen nicht.

Datenbank: Apache Jena Fuseki

Apache Jena Logo von der
Apache^® Software Foundation.

Als lokale Datenbank für unser Experiment haben wir uns für Apache Jena entschieden. Das Projekt vereint einen Triple Store (TDB) zum Speichern und Verwalten der RDF Triple der GND, eine Implementierung von SPARQL namens ARQ, sowie einen SPARQL Endpoint mit Fuseki. Zusätzlich gib es auch noch Tools zum Arbeiten mit RDF und OWL, die wir erstmal nicht nutzen werden. Da wir gerne mit Docker arbeiten, es aber kein offizielles Docker Image des Apache Projektes gibt, verwenden wir das Docker Image stain/jena-fuseki aus dem Docker Hub².

Einlesen der Daten

Da das Einlesen der Daten mehrere Stunden dauern kann, empfehlen wir den Workflow zuerst mit einem kleineren Testdatensatz auszuführen.

Zum Einlesen haben wir uns die Datei authorities_lds.nt.gz aus dem DNB Data Dump heruntergeladen³.

Wir arbeiten mit der folgenden Ordnerstruktur:

--- title: Ordnerstruktur config: look: handDrawn theme: neutral --- flowchart TD subgraph data[far:fa-folder-open data] fuseki[far:fa-folder fuseki] fuseki_test[far:fa-folder fuseki_test] gnd_triples[far:fa-folder gnd_triples] test_triples[far:fa-folder test_triples] end root[far:fa-folder-open gnd_test] --> data root --> README[far:fa-file README.md]

README.md: Überblick über das Projekt und die Daten geben!
fuseki: Ordner zum Persistieren der Datenbank von Apache Jena.
fuseki_test: Ordner für den Test mit Apache Jena.
gnd_triples: Speicherort der .nt.gz Datei.
test_triples: Speicherort von Testdateien im .ttl Format.

Testdaten einlesen

Als erstes starten wir einen Docker Container mit dem Namen fuseki, machen die Web GUI verfügbar über http://localhost:8080, setzen das Administrator Passwort auf 123123 und mounten unsere Testordner in den Container⁴.

docker run -it --rm --name=fuseki -p 8080:3030 -e ADMIN_PASSWORD=123123 -v "$(PWD)\data\test_triples:/staging" -v "$(PWD)\data\fuseki_test:/fuseki" stain/jena-fuseki

Den Docker Container lassen wir laufen und öffnen ein zweites Terminal (Shell, PowerShell, …). Von diesem aus können wir uns mit dem Container verbinden und den Einlesevorgang starten. Hierfür gibt es zwei Varianten. In der ersten wird das bereitgestellte load.sh Skript verwendet, welches auf tdbloader verweist. Wir verzichten darauf dem load.sh Skript spezifische Dateien vorzugeben, sondern lesen alle kompatiblen Formate im fuseki_test Ordner in die test Datenbank ein.

docker exec -it fuseki /bin/bash -c './load.sh test'

Abschließend wird der geladene Datensatz in der Web GUI angelegt. In dem folgenden Bildschirmfoto in Abbildung 1 wird ein TDB Datensatz mit dem Namen test angelegt. Hier ist der gleiche Bezeichner zu wählen, wie er auch beim Laden verwendet wurde.

Hinzufügen des Test Datensatzes in der Web GUI.

Anschließend kann entweder in der Web GUI im Tab info oder mit dem folgenden SPARQL-Befehl die Anzahl der eingelesenen Trippel bestimmt werden.

SELECT COUNT(*)
WHERE {
 ?s ?p ?o .
}

Alternative mit TDB2

Alternativ kann auch der tdbloader2 verwendet werden. Hier werden explizit nur Dateien im *.ttl Format eingelesen.

docker exec -it fuseki /bin/bash -c './tdbloader2 --loc=/fuseki/databases/test /staging/*.ttl'

In der Web GUI darauf achten, den Datensatz als TDB2 anzulegen.

GND einlesen

Nach einem erfolgreichen Test lesen wir nun die komplette GND ein. Wir haben uns für TDB2 entschieden, da wir planen den Datensatz länger zu verwenden. Das Einlesen benötigt mit 6 Stunden und 15 Minuten etwa eine Viertelstunde länger als mit der Vorgängerversion TDB.

1. Starten des Containers mit Daten zum Einlesen

Der folgende Befehl startet einen Docker Container mit dem Verzeichnis der Daten zum Einlesen und einem Verzeichnis zum Speichern der Datenbank von Apache Jena.

docker run -it --rm --name=fuseki -p 8080:3030 -e ADMIN_PASSWORD=123123 -v "$(PWD)\data\gnd_triples:/staging" -v "$(PWD)\data\fuseki:/fuseki" stain/jena-fuseki

2. Einlesen der Daten im `TDB2` Format

In einem separaten Terminal starten wir den Einlesevorgang der GND Daten mit dem tdbloader2.

docker exec -it fuseki /bin/bash -c './tdbloader2 --loc=/fuseki/databases/gnd /staging/*.nt.gz'

3. Anlegen des Datensatzes in der Web GUI

Nach dem erfolgreichen Einlesen legen wir den Datensatz in der Weg GUI an. Hierbei achten wir darauf, den gleichen Bezeichner zu verwenden, wie beim Einlesen und als Format TDB2 zu wählen.

Hinzufügen des GND Datensatzes in der Web GUI.

4. Exemplarisches Testen der eingelesenen Daten

Anschließend testen wir exemplarisch, ob die Daten nutzbar sind. Hierfür verwenden wir eine SPARQL Abfrage mit einem Standardbeispiel aus der GND Ontology.

SELECT ?p ?o
WHERE {
 <https://d-nb.info/gnd/118514091> ?p ?o
}

Falls zu diesem Zeitpunkt noch keine Ergebnisse angezeigt werden, den Container beenden und wie in Schritt 5 starten.

5. Wiederverwendung des Containers

Um einen neuen Apache Jena Docker Container zu starten und die eingelesenen Daten wiederzuverwenden, kann der folgende Befehl verwendet werden.

docker run -it --rm --name=fuseki -p 8080:3030 -e ADMIN_PASSWORD=123123 -v "$(PWD)\data\fuseki:/fuseki" stain/jena-fuseki

Zusammenfassung und Ausblick

Zu Beginn war es etwas frustrierend, einen funktionierenden Workflow zum Einlesen der Daten in den Docker Container von Apache Jena aufzubauen. Kleine Abweichungen der obigen Beschreibung oder der Reihenfolge sorgen dafür, dass der komplette Einlesevorgang neu gestartet werden muss.

Die Einlesezeit wird sich auf anderen Systemen drastisch unterscheiden. Das liegt unter anderem daran, dass wir bei unseren Tests die Dateien von einem Windows Dateisystem in ein Linux-Dateisystem im Docker Container eingelesen und dann wieder auf das Windows Dateisystem herausgeschrieben haben.

Mit der Kombination aus Apache Jena, Docker und GND haben wir jetzt eine lokale Testdatenbank, mit der wir intensiv mit den Daten arbeiten können, ohne durch Bandbreiten- oder API-Beschränkungen ausgebremst zu werden.

Alternativ gibt es den Dienst lobid des hbz NRW. ↩︎
Zum Zeitpunkt unseres Tests gab es mehrere Probleme, die mit stain/jena-docker#50 gefixt werden sollten. ↩︎
Die Daten werden auch im für die Kompression optimierten HDT Format angeboten, jedoch hätten wir dafür Apache Jena für HDT anpassen müssen. ↩︎
Die Sicherheit des Passworts ist hier nicht relevant, da wir die Anwendung lokal auf unserem Rechner testen. ↩︎

SPARQL | FDMLab@LABW

GND Hierarchieinformationen zur Verbesserung der Erschließung

Schritt 5: Oberbegriffe nachladen

Typen von Oberbegriffen

Mehrere Oberbegriffe

Keine Oberbegriffe

Ähnliche Begriffe

Analyse Subgraph

Analyse GND SubjectHeading Graph

Komponenten und Größen

Anteil von Komponenten bestimmter Größen

Tiefe der Hierarchie

Kindknoten pro Knoten

Fazit

Workshop - Erweiterter Abgleich mit Getty

Einführung

Aufgabe 1: Daten verknüpfen

Projekt anlegen

Einfacher Abgleich

Erweiterter Abgleich

Fazit

Lizenzhinweise

Workshop - Erweiterter Abgleich mit Wikidata

Einführung

Aufgabe 1: Abgleich mit Wikidata

Transformation 1: Name fuzzy

Transformation 2: Geburtsdatum reduzieren

Subfields

Keine Transformation beim Geburtsort

Abgleich durchführen

Weiterführende Informationen

Aufgabe 2: Suchbereich einschränken

Einfacher Abgleich

Abgleich mit Instanzfilter

Abgleich mit Country Code

Abgleich mit State Code

Ergebnis

Fazit

GND in lokale Datenbank laden (reloaded)

Datenbank: Oxigraph

Einlesen der Daten

Einlese-Variante 1

Einlese-Variante 2

3. Anzeigen der Daten

Zusammenfassung und Ausblick

NER Modell mit GND Starthilfe trainieren

NER und Erschließung

NER im Kontext Archiv

Trainieren eines NER Modells

Vorbereitungen

GND Daten extrahieren

GND Daten aufbereiten

Durchführung

Annotation mit Regeln und aktivem Lernen

Evaluation regelbasierter “Modelle”

Ergebnisse

Diskussion

Fazit

Experiment zur Identifikation von doppelten Orten in der GND

Hintergrund

Idee

Vorgehen

1. ONDB Aufbereitung

2. GND in Triple-Store laden

3. Daten aus Triple-Store laden

4. Dubletten identifizieren

SPARQL Abfrage(n)

Angaben zur Quelle

Verknüpfung über Hierarchie

Verknüpfung über Ländercode

Verknüpfung über Ländercode mit Aufzählung aller (Sub-)Klassen

Anzahl pro (Sub-)Klasse

DE-Ländercode mit Nachfolger (oder Vorgänger) in BW

Finale SPARQL-Abfrage

Ergebnisse

Erste Experimente mit der GND

Lade Beispielperson

Berufe und Tätigkeiten von David Bowie

Berufe und Tätigkeiten in Nürnberg (fixiert)

Berufe und Tätigkeiten in Nürnberg (frei)

2. Einlesen der Daten im `TDB2` Format