Semantic Web | FDMLab@LABW

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

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

Experimente mit Visualisierungen für Sachbegriffe in der GND

Tue, 24 May 2022 00:00:00 +0000

Die Gemeinsame Normdatei (GND) enthält unter anderem semantische Daten zu Sachbegriffen. In diesem Beitrag experimentieren wir mit Visualisierungen für Sachbegriffe in der GND, um die Daten und die Ontologie dahinter besser kennen zu lernen.

Wie im obigen Bild¹ thematisiert, beinhaltet die als Linked Open Data (LOD) zur Verfügung gestellte GND einen komplexen Graphen mit verlinkten Daten, deren Verlinkung und Struktur sich auf Grund ihrer Komplexität für Außenstehende nicht auf Anhieb verständlich gestaltet.

Im Bereich der Sachbegriffe (Subject Heading) gibt es mehrere Konzepte zur Gruppierung. Es gibt die GND-Sachgruppen und verschiedene Arten von Oberbegriffen².

Um die Daten und deren Verknüpfungen besser zugänglich zu machen, gibt es auch das am 31. Mai von der DNB als beta freigegebene Projekt GND-Explorer.

In Kooperation mit Katharina Hardt von dem Projekt Provenienzforschung am Hauptstaatsarchivs Stuttgart hatten wir im FDMLab ein konkretes Problem, wofür wir eine visuelle Unterstützung benötigten. Dafür haben wir ein Experiment zur Visualisierung von GND Sachbegriffen umgesetzt, über welches wir im Folgenden berichten. ³

Es handelt sich bei der GND Hierarchie Visualisierung um ein prototypisch umgesetztes Experiment und nicht um eine produktive Anwendung!

Die Ludwigsburger Porzellantasse

Eine Frage, die wir uns im Kontext der Provenienzforschung gestellt hatten, ist die mögliche Verschlagwortung mit Normdatenverknüpfung für den Begriff Ludwigsburger Porzellantasse.

Die Ludwigsburger Porzellantasse gibt es nicht als Sachbegriff in der GND. Die aus unserer Sicht passenden Begriffe in der GND sind Ludwigsburger Porzellan und Porzellantasse.

Dabei stellten wir uns die folgenden Fragen:

Haben die beiden Begriffe einen gemeinsamen Oberbegriff?
Gehören die beiden Begriffe zu einer gemeinsamen Sachgruppe?
Ist Porzellan ein gemeinsamer Oberbegriff?
Ist Geschirr ein Oberbegriff von Porzellantasse?
Wie verhält sich der Begriff Porzellanfigur ⁴ im Kontext der beiden Begriffe?

Diese Antworten auf diese Fragen lassen sich im Einzelnen auch via der Weboberflächen von der DNB, lobid, OGND oder in OpenRefine manuell recherchieren. Bei mehreren Begriffen, ist dieses Vorgehen jedoch langwierig.

Daher haben wir basierend auf dem lobid GND API, dem Frontend-CSS-Framework Bootstrap und dem JavaScript Framework Mermaid prototypisch eine Webanwendung zur GND Hierarchie Visualisierung von Sachbegriffen umgesetzt, die es uns ermöglicht die oben genannten Antworten zu den obigen Fragen zu visualisieren und zu beantworten.

Das nächste Diagramm zeigt ein bearbeitetes Beispiel zu der Hierarchie der Oberbegriffe von Ludwigsburger Porzellan, Porzellantasse und Porzellanfigur.

flowchart LR 4175414-1(["Porzellantasse"]):::initial 4184488-9["Tasse"] 4175411-6(["Porzellanfigur"]):::initial 4046277-8["Plastik"] 4046851-3["Porzellan"] 4168206-3(["Ludwigsburger Porzellan"]):::initial 4124863-6["Essgeschirr"] 4186181-4["Trinkgefäß"] 4181363-7["Silicatkeramik"] 4153870-5["Feinkeramik"] 4140542-0["Geschirr"] 4128003-9["Gefäß"] 4030282-9["Keramischer Werkstoff"] 4030271-4["Keramik"] 4132060-8["Hausrat"] 4020299-9["Gerät"] 4065579-9["Werkstoff"] 4169078-3["Material"] 4037940-1["Materie"] 4175414-1-->4184488-9 4175411-6-->4046277-8 4175411-6-->4046851-3 4168206-3-->4046851-3 4184488-9-->4124863-6 4184488-9-->4186181-4 4046851-3-->4181363-7 4046851-3-->4153870-5 4124863-6-->4140542-0 4186181-4-->4128003-9 4181363-7-->4030282-9 4153870-5-->4030271-4 4140542-0-->4132060-8 4128003-9-->4020299-9 4030282-9-->4065579-9 4065579-9-->4169078-3 4169078-3-->4037940-1 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;

Laut unserem Diagramm ist der Begriff Geschirr ein Oberbegriff zur Porzellantasse. Die Porzellanfigur und das Ludwigsburger Porzellan haben Porzellan als gemeinsamen Oberbegriff, die Porzellantasse jedoch nicht. Es gibt keinen gemeinsamen Oberbegriff für alle Begriffe, sie gehören jedoch, zur GND-Sachgruppe Kunsthandwerk (siehe nächstes Diagramm).

flowchart LR 4175414-1(["Porzellantasse"]):::initial cat0[["Kunsthandwerk"]]:::category 4175411-6(["Porzellanfigur"]):::initial cat1[["Plastik"]]:::category 4168206-3(["Ludwigsburger Porzellan"]):::initial 4175414-1-->cat0 4175411-6-->cat1 4175411-6-->cat0 4168206-3-->cat0 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;

Gemeinsamer Oberbegriff für Bilder?

Bei den GND Sachbegriffen für Acrylbild, Aquarell, Lithografie, Ölgemälde, Radierung und Pastellzeichnung fragten wir uns, ob diese einen gemeinsamen Oberbegriff wie Bild oder Bildliche Darstellung haben. ⁵

flowchart LR 4132048-7(["Acrylbild"]):::initial 4037220-0["Malerei"] 4002511-1(["Aquarell"]):::initial 4036042-8(["Lithografie"]):::initial 4154503-5["Flachdruck"] 4043238-5(["Ölgemälde"]):::initial 4048166-9(["Radierung"]):::initial 4113357-2["Druckgrafik"] 4075923-4(["Pastellzeichnung"]):::initial 4124801-6["Drucktechnik"] 4021845-4["Grafik"] 4021850-8["Graphische Technik"] 4794555-2["Medientechnik"] 4145419-4["Bildliche Darstellung"] 4132048-7-->4037220-0 4002511-1-->4037220-0 4036042-8-->4154503-5 4043238-5-->4037220-0 4048166-9-->4113357-2 4075923-4-->4037220-0 4154503-5-->4124801-6 4113357-2-->4021845-4 4124801-6-->4021850-8 4124801-6-->4794555-2 4021845-4-->4145419-4 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;

Wie im obigen Diagramm abzulesen, ist das nicht der Fall. Interessant ist hier, dass die Pastellzeichnung mit Acrylbild, Aquarell und Ölgemälde als gemeinsamen Oberbegriff in die Malerei verortet wurde, die Pastellzeichnung im nächsten Diagramm aber mit der Radierung und der Lithografie in die GND-Sachgruppe Zeichnung, Grafik eingeordnet wird.

flowchart LR 4132048-7(["Acrylbild"]):::initial cat0[["Malerei"]]:::category 4002511-1(["Aquarell"]):::initial 4036042-8(["Lithografie"]):::initial cat1[["Zeichnung, Grafik"]]:::category cat2[["Papierherstellung, Grafische Technik"]]:::category 4043238-5(["Ölgemälde"]):::initial 4048166-9(["Radierung"]):::initial 4075923-4(["Pastellzeichnung"]):::initial 4132048-7-->cat0 4002511-1-->cat0 4036042-8-->cat1 4036042-8-->cat2 4043238-5-->cat0 4048166-9-->cat1 4075923-4-->cat1 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;

Fazit

Mit wenig Aufwand, auch Dank dem GND API von lobid, konnten wir eine Webanwendung umsetzen, mit der wir die Sachbegriffe in der GND besser kennen lernen können. Die nachträglich bearbeitbaren Visualisierungen helfen uns bei der Projektdokumentation und bei der Kommunikation mit unseren Fachkollegen.

GND Hierarchie Visualisierung selbst ausprobieren

Das Bild “GND Sachbegriffe visualisieren” 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 “GND Sachbegriffe visualisieren” ist ebenfalls lizenziert unter einer CC BY-SA 4.0 Lizenz. ↩︎
Broader term, Broader term (general), Broader term (generic), Broader term (instantial), Broader term (partitive), Broader term (with more than one element) ↩︎
Danke hier auch an die GND-Agentur LEO-BW-Regional für ein erstes Feedback! ↩︎
Die Vorzugsbenennung für Porzellanfigur in der GND ist Porzellanplastik. Wir verwenden hier im Artikel teilweise offiziell in der GND gelistete Synonyme für Sachbegriffe, wenn sie besser in unsere Erzählstruktur passen. ↩︎
In der GND ist teilweise die Bildart und teilweise die entsprechende Maltechnik die Vorzugsbenennung. Also Aquarellmalerei ist ein Synonym für den Vorzugsbegriff Aquarell und Ölgemälde ist ein Synonym für den Vorzugsbegriff Ölmalerei. Für eine einheitliche Erzählstruktur, haben wir uns daher teilweise für die Verwendung der Synonyme in unserem Text und den Diagrammen entschieden. ↩︎

Erfahrungsbericht - Extraktion und Abgleich von Prokuratoren mit OpenRefine

Tue, 21 Sep 2021 00:00:00 +0000

In diesem Beitrag beschreiben wir unsere Erfahrungen bei der Textextraktion, der Deduplikation und dem Abgleich mit der GND von Indizes aus zehn Findbüchern.

Wir haben bisher in Tutorials gezeigt, wie wir einen Findbuch Index mit OpenRefine aufbereiten und wie wir diese Findbuch Daten mit OpenRefine wiederverwenden können.

Die dabei gesammelten Erfahrungen haben wir anschließend praktisch angewendet und die Indizes der Prokuratoren aus den Findbüchern zu den Akten des Reichskammergerichts in den Staatsarchiven Wertheim und Sigmaringen, sowie die Bände 1 - 8 im Hauptstaatsarchiv Stuttgart mit OpenRefine aufgearbeitet und mit der GND abgeglichen.

Generelle Daten

Text:

10 Bände
10.339 Textzeilen

CSV:

2.912 Indexeinträge
Davon 100 Aliase

Deduplikation:

472 Prokuratoren

Abgleich mit GND:

275 ohne GND Eintrag
197 mit GND Eintrag (ca. 42 Prozent)

Anwenden mehrerer Teilschritte

--- title: Extraktionsprozess config: look: handDrawn theme: neutral --- flowchart LR subgraph books[fas:fa-book Bände] band1[Band 46/1.txt] bandn[Band 46/...] band8[Band 46/8.txt] band9[Band 46/57.txt] band10[Band 57/Wertheim.txt] end subgraph csvs[fas:fa-file-csv CSV] csv1[CSV Band 46/1.csv] csvn[CSV Band 46/...] csv8[CSV Band 46/8.csv] csv9[CSV Band 57.csv] csv10[CSV Band 57/Wertheim.csv] end db[fas:fa-file-csv Prokuratoren.csv] gnd[fas:fa-database GND] result[fas:fa-project-diagram Prokuratoren] band1 --fas:fa-gem--> csv1 --fas:fa-magic--> db bandn --fas:fa-gem--> csvn --fas:fa-magic--> db band8 --fas:fa-gem--> csv8 --fas:fa-magic--> db band9 --fas:fa-gem--> csv9 --fas:fa-magic--> db band10 --fas:fa-gem--> csv10 --fas:fa-magic--> db db & gnd --fas:fa-gem--> result

Wir haben uns dazu entschieden, aus jeder Findbuch(text)datei mit OpenRefine eine CSV Datei mit den Informationen zu den Prokuratoren zu extrahieren und die zehn CSV Dateien anschließend zusammenzufassen.

--- title: Extraktionsprozess config: look: handDrawn theme: neutral --- flowchart LR subgraph books[fas:fa-book Bände] band1[Band 46/1.txt] bandn[Band 46/...] band8[Band 46/8.txt] band9[Band 46/57.txt] band10[Band 57/Wertheim.txt] end txt[fas:fa-file-txt Bände.txt] db[fas:fa-file-csv Prokuratoren.csv] gnd[fas:fa-database GND] result[fas:fa-project-diagram Prokuratoren] band1 & bandn & band9 & band10 --fas:fa-magic--> txt --fas:fa-gem--> db db & gnd --fas:fa-gem--> result

Es wäre auch denkbar gewesen, die zehn Textdateien in einer Textdatei zusammenzufassen und daraus mit OpenRefine in einem Projekt eine CSV Datei zu erstellen. Das Layout der einzelnen Findbücher unterschied sich jedoch so, dass wir uns anders entschieden. Im Nachhinein wäre die Lösung mit einer Textdatei als Grundlage einfacher zu handhaben gewesen, da wir bei unserem Vorgehen systematische Fehler in allen zehn Projekten nachzukorrigieren hatten.

Um die einzelnen Operationen zwischen den Projekten besser austauschen zu können, haben wir die groben Schritte, wie zum Beispiel “zweispaltiges Layout in einspaltiges Layout umwandeln”, als Sammlung von mehreren Operationen in separaten .json Dateien vorgehalten. Diese haben wir dann über die “History” Funktion von OpenRefine auf das aktuelle Projekt angewendet. Darüber haben wir auch schon in Findbuch Daten mit OpenRefine wiederverwenden geschrieben.

So konnten wir iterativ mehrere Operationen gleichzeitig anwenden, das Ergebnis überprüfen und bei Bedarf die Operationen wieder rückgängig machen, sie anpassen und neu anwenden. Hierbei wäre es praktisch gewesen, wenn man sich einzelne Versionen in der History von OpenRefine hätte markieren können, um einfacher dorthin zurückspringen zu können.

Nachdem wir die CSV Dateien zusammengefasst hatten und in einem neuen Projekt die Deduplikation mit OpenRefine begannen, stellten wir fest, dass es trotz sorgfältiger manueller Prüfung nach wie vor Extraktionsfehler in den Einzelprojekten gab.

Daher geben wir hier als Tipp weiter, die Projekte und Zwischenschritte automatisch zu validieren. Dafür kann zum Beispiel in OpenRefine mit Textfiltern und regulären Ausdrücken überprüft werden, ob es noch Zahlen oder andere unerwartete Zeichen in den Namen gibt, die Jahreszahlen und Verweise richtig formatiert sind, …

Deduplikation mit Clusterverfahren

Zur Deduplikation verwendeten wir die in OpenRefine integrierten Cluster Verfahren. Da wir unterschiedliche Arten von Duplizierungen hatten, verwendeten wir mehrere der angebotenen Verfahren nacheinander, bis wir keine Cluster mehr automatisiert finden konnten.

Probleme machten hierbei alternative Schreibweisen, die in unseren Findbüchern durch Klammerung kompakt zusammengefasst wurden. Beispielsweise gab es für Re(c)hlinger, Johann in den Findbüchern auch die Schreibweise Rehlinger, Johann und Rechlinger Johann.

Dies konnte durch die Clusterverfahren gut erkannt und zusammengeführt werden.

Schwieriger wurde es bei der automatischen Zusammenführung von Brandt, (Johann) Ferdinand Wilhelm von, mit Brandt, Ferdinand Wilhelm, da hier der geklammerte Ausdruck relativ zum Namen recht lang ist.

Wenn der Anteil des geklammerten Namens zu groß wird, dann finden die verfügbaren automatischen Clustermethoden keine (sinnvolle) Ähnlichkeit mehr. Dies war beispielsweise bei Müller (Mulher), Christoph und Müller, Christoph der Fall.

Abgleich mit der GND

Der Abgleich der Daten mit der GND via lobid nahm die meiste Zeit in Anspruch. Um die Sortierung der Suchtreffer zu verbessern, haben wir eine zusätzliche Spalte “Beruf” mit dem Wert “Jurist” eingefügt und mit der Eigenschaft professionOrOccupation abgeglichen.

Probleme gab es mit den schon erwähnten Namen mit Alternativen in Klammern, da geklammerte Ausdrücke Probleme bei der Verarbeitung durch die lobid API haben.

Ein wesentlicher Aufwandsfaktor war die fehlende Möglichkeit zur Einschränkung der Lebens- und Wirkungsdaten. Hier hatte lobid schon auf unseren letzten Blogpost reagiert und das Feature im März 2022 umgesetzt. ¹

Fazit

Die Umwandlung der 10.339 Textzeilen zu 472 Prokuratoren ließ sich mit OpenRefine relativ problemlos bewältigen. Durch den Abgleich der Prokuratoren über mehrere Findbücher konnten einige OCR-Fehler korrigiert oder alternative Schreibweisen aufgelöst werden. Die anschließende Zuordnung zu GND-Nummern war hingegen langwierig.

Mit 472 Juristen, die alle aus der gleichen Berufsgruppe kommen und auch an anderen Orten schriftliche Spuren (Doktorarbeiten, …) hinterlassen haben, war dieser Datensatz vergleichsweise einfach aufzuarbeiten.

In den Findbüchern zu den Akten des Reichskammergerichts gibt es noch einen gemischten Orts- und Personenindex. Dieser ist etwa 50mal so groß, wie der Index der Prokuratoren, enthält unterschiedlichste Typen von Einträgen (Adel, Berufe, Familien, Orte, …), und enthält vermutlich deutlich weniger Treffer in der GND. ²

Hier werden wir gegebenenfalls zusätzliche externe Werkzeuge bemühen, wie wir es für den Artikel Named Entity Recognition mit OpenRefine und spaCy getestet haben.

Update April 2022: Durch ein Update in dem lobid GND API für OpenRefine kann nun eine zeitliche Einschränkung beim Reconciliation vorgenommen werden. Details dazu finden sich unter Using range query parameter via OpenRefine Reconciliation auf GitHub und unter Erweiterter GND Abgleich mit lobid auf unserem Blog. ↩︎
Es kostet mehr Aufwand zu überprüfen, wenn etwas nicht da ist, als wenn es sofort ein eindeutiges Ergebnis gibt. ↩︎

Findbuchdaten mit OpenRefine wiederverwenden

Tue, 24 Aug 2021 00:00:00 +0000

In diesem Artikel behandeln wir die Frage, wie wir schon aufbereitete Daten mit OpenRefine wiederverwenden können.

Wir haben schon einen Findbuch Index mit OpenRefine aufbereitet. wenn wir nun den Prokuratoren Index von “Band 57: Akten des Reichskammergerichts im Staatsarchiv Sigmaringen - Inventar des Bestands R 7. Bearb. von Raimund J. Weber. Kohlhammer 2004” bearbeiten wollen, dann wäre zu erwarten, dass wir das Projekt nachnutzen können.

Dies ist bedingt möglich. Zum einen können wir die Operationen aus der letzten Findbuchaufbereitung wiederverwenden. Zum anderen können wir die Prokuratoren mit den Prokuratoren aus dem letzten Projekt abgleichen.

Um es vorweg zu nehmen: es hat sich gezeigt, dass wir nur einen Teil der Operationen und Prokuratoren übernehmen können. Aber gerade bei den Operationen ist das eine ziemliche Zeitersparnis.

💾 Wir benötigen drei Dateien (Rechtsklick und “Ziel speichern unter…”):

Index Prokuratoren Akten RKG Band 57

Index Prokuratoren Akten RKG Band 57 als OpenRefine Arbeitsschritte

Prokuratoren Akten RKG Band 57 - Wertheim als CSV

Wir möchten explizit dazu einladen diese Dateien zu nutzen, um die einzelnen Schritte in OpenRefine selbst auszuprobieren und damit zu experimentieren.

Operationen übertragen

Mit OpenRefine ist es möglich, die durchgeführten Operationen eines Projektes zu exportieren und in einem anderen Projekt zu importieren. Beschrieben ist das im OpenRefine Manual.

Zuerst erstellen wir das Projekt in OpenRefine mit der Datei akten-rkg-band-57-prokuratoren.txt als Grundlage. Die Einstellungen sind in Abbildung 1 gezeigt.

Bildschirmfoto der Ansicht zum Erstellen neuer Projekte in OpenRefine.

Mit der Schaltfläche “Extract…” bei “Undo/Redo” (siehe Abbildung 2) können wir die Operationen aus einem Projekt exportieren und mit der Schaltfläche “Apply..” anwenden.

Bildschirmfoto der Schaltfläche zum Anwenden von exportieren Operationen in OpenRefine.

Nach Klicken der Schaltfläche “Apply..” können wir die exportierten Operationen aus akten-rkg-band-57-openrefine-prokuratoren.json wie in Abbildung 3 gezeigt einfügen und mit “Perform Operations” die Operationen auf dem aktuellen Projekt anwenden.

Dialog zum Anwenden von exportieren Operationen in OpenRefine.

Bei unserem ersten Versuch haben wir festgestellt, dass die Operationen von unserem letzten Artikel nicht direkt auf diesen Index anwendbar sind. Beim Anwenden von Operationen aus einem anderen Projekt sind einige Dinge zu beachten.

Die .json Datei sollte mit einem Quelltexteditor wie (unter Windows) der Editor App, Notepad++ oder Visual Studio Code geöffnet (und bearbeitet) werden.
Die Spaltennamen in den beiden Projekten müssen die gleichen Namen haben.
Manuelle Editieroperationen und Filteroperationen werden nicht mit übertragen.

In unserem konkreten Fall gab es zusätzlich die folgenden Probleme

Die Extraktion der Seitenzahlen funktioniert nicht, da die Kopfzeilen sich unterscheiden.
Das zweispaltige Layout hat statt 4 einen Minimalabstand von 3 Leerzeichen.
Es gibt Zeilenumbrüche bei dem Namen der Prokuratoren und bei den Verweisen.
Die Anpassungen für das “reconciling” lassen sich nicht übertragen.

In der Datei akten-rkg-band-57-openrefine-prokuratoren.json haben wir die Operationen entsprechend bereinigt und angepasst, so dass sie direkt angewendet werden können. In Abbildung 4 ist das Ergebnis der Anwendung zu sehen.

Bildschirmfoto der Daten nach der Anwendung der Operationen in OpenRefine.

Bei “Albrecht von Lauterbach” ist eine andere Formatierung verwendet worden, die wir manuell nachkorrigiert haben. Dafür sind wir in der “History” der Operationen zurück zu Schritt 33 gegangen. Dann haben wir die fehlerhaften Einträge manuell via “inline editing” korrigiert. Anschließend haben wir die (ehemaligen) Operationen 34 und 35 erneut via “Apply…” angewendet. Die (ehemaligen) Operationen 34 und 35 haben wir hier direkt zum Kopieren in den Artikel eingefügt:

[
 {
 "op": "core/column-addition",
 "engineConfig": {
 "facets": [],
 "mode": "row-based"
 },
 "baseColumnName": "Nachname",
 "expression": "join ([coalesce(cells['Nachname'].value,''),coalesce(cells['Vorname'].value,'')],', ')",
 "onError": "keep-original",
 "newColumnName": "Name",
 "columnInsertIndex": 1,
 "description": "Create column Name at index 1 based on column Nachname using expression join ([coalesce(cells['Nachname'].value,''),coalesce(cells['Vorname'].value,'')],', ')"
 },
 {
 "op": "core/column-move",
 "columnName": "Name",
 "index": 0,
 "description": "Move column Name to position 0"
 }
]

Zwischenfazit

Die Übertragung von Verkettungen von Operationen, wie zum Beispiel das Auflösen eines zweispaltigen Layouts, ist praktisch und spart dem versierten Benutzer einiges an Zeit. Durch die automatisch generierten Beschreibungstexte für die Operationen ist es jedoch nicht leicht, die entsprechenden Blöcke von Operationen auch zu identifizieren.

Abgleich mit lokaler CSV Datei

Mit der Datei akten-rkg-band-57-wertheim-prokuratoren.csv besitzen wir eine (kleine) lokale Datenbank mit bereits aufbereiteten Prokuratoren. Diese können wir zum Abgleich mit unseren aufbereiteten Daten in OpenRefine verwenden. Dafür gibt es Werkzeuge, die eine CSV Datei als “Reconciliation Service” zur Verfügung stellen.

Abgleich mit reconcile-csv (Clojure)

Das Projekt reconcile-csv basiert auf Clojure und lässt sich daher direkt mit der gleichen Java Version ausführen, mit der wir auch OpenRefine verwenden. Dafür erstellen wir im Ordner mit der openrefine.exe einen Ordner services und kopieren die heruntergeladene reconcile-csv-0.1.2.jar hinein.

In dem Ordner öffnen wir anschließend eine PowerShell und führen mit der Java Version von OpenRefine die .jar Datei aus. Das CSV Reconciliation Service benötigt drei Parameter:

Der Pfad zu der CSV Datei.
Der Name der Spalte mit der abgeglichen werden soll.
Der Name der Spalte mit einem eindeutigen Wert (ID) für jede Zeile. ¹

.\server\target\jre\bin\java.exe -jar .\services\reconcile-csv-0.1.2.jar .\data\akten-rkg-band-57-wertheim-prokuratoren.csv Name Nr

Mit “Name" "Reconcile" "Start reconciling” können wir auf der Spalte Name den “Reconciliation” Vorgang starten und dort die Adresse http://localhost:8000/reconcile als “Reconciliation Service” hinzufügen.

Wie in Abbildung 5 gezeigt, gibt es für die einzelnen Ergebnisvorschläge auch eine Vorschau Funktion, in der die Inhalte der Tabellenzeile zum besseren Abgleich angezeigt werden.

Bildschirmfoto vom Abgleich mit ‘reconcile-csv’ in OpenRefine.

Wir konnten mit dem lokalen Abgleich 28 Prokuratoren aus unserer Liste finden.

An dieser Stelle würden wir gerne weitere Daten aus der CSV Datei laden, wie es von dem von OpenRefine unterstützen Data Extension API angeboten wird. Leider wird diese Funktionalität in diesem Service nicht unterstützt. Da das Projekt Stand August 2021 seit 2015 nicht mehr weiterentwickelt wurde, ist damit auch nicht zu rechnen.²

Abgleich mit csv-reconcile (Python)

Ein neueres Projekt zum Abgleich mit lokalen CSV Dateien ist csv-reconcile, welches auf Python basiert und sich aktiv in der Entwicklung befindet.

Wie wir schon im Artikel Named Entity Recognition mit OpenRefine und spaCy festgestellt haben, ist die Verwendung von Python Frameworks mit OpenRefine aufwendiger, da wir dafür zusätzlich eine aktuelle Python Installation benötigen.

Haben wir lokal Python installiert, dann können wir mit PowerShell im gleichen services Ordner wie im letzten Abschnitt eine virtuelle Python Umgebung anlegen (1), diese virtuelle Umgebung aktivieren (2), das Paket csv-reconcile mit pip installieren (3), und den “CSV Reconciliation Service” starten (4).

1
2
3
4


python -m venv venv
.\venv\Scripts\activate
pip install csv-reconcile
csv-reconcile --init-db --config config.py ..\data\akten-rkg-band-57-wertheim-prokuratoren.csv Nr Name

Leider konnte unsere CSV Datei auf Grund ihres Formates und Kodierung nicht auf Anhieb richtig geladen werden, so dass wir zusätzlich eine Konfigurationsdatei config.py mit dem folgenden Inhalt im Ordner services hinterlegt haben.

CSVKWARGS={'delimiter': ',', 'quotechar': '"'}
CSVENCODING='UTF-8'

Der “CSV Reconciliation Service” ist anschließend unter http://localhost:5000/reconcile erreichbar.

Das Python Projekt ist deutlich flexibler und ausführlicher zu konfigurieren, als das ältere Clojure Projekt. Es unterstützt auch die “Data Extension API”, so dass wir nach dem Abgleich weitere Spalten aus der CSV Datei nachladen können. ~~Leider fehlt noch eine Vorschau, so dass kein visueller Abgleich zum Beispiel mit den Wirkdaten der Prokuratoren möglich ist.~~ Ab Version 0.3.0 gibt es eine optionale Vorschau Funktion.

Abgleich mit der GND

Nachdem wir etwa 10 Prozent der Prokuratoren mit unseren lokalen Daten abgleichen konnten, können wir nun den Rest direkt mit der Gemeinsamen Normdatei (GND) abgleichen. Darauf sind wir in Findbuch Index mit OpenRefine aufbereiten genauer eingegangen und werden das daher hier nicht weiter vertiefen.

Fazit

--- title: Prozess config: look: handDrawn theme: neutral --- flowchart LR text[fas:fa-file-alt Text] code[fas:fa-code Code] index[fas:fa-file-csv Index] data[fas:fa-table Table] partially[fas:fa-tasks Parts] gnd[fas:fa-database GND] semantic[fas:fa-project-diagram Graph] text --> data --> partially --> semantic code --> data index --> partially gnd --> semantic

Die Möglichkeit json Schnippsel mit Verkettungen von Operationen für komplexe Aufgaben zu importieren gefällt uns, und wir werden diese Methode gegebenenfalls öfter verwenden.

Für den komfortablen Abgleich mit einer lokalen CSV Datei fehlte den beiden getesteten Bibliotheken noch Funktionalität.

Das auf Clojure basierende reconcile-csv lässt sich ohne großen Mehraufwand verwenden und bietet eine hilfreiche Vorschau Funktion. Ohne eine Unterstützung der “Data Extension API” ist es für unsere Anwendungsfälle aber nur beschränkt nutzbar.

Das auf Python basierende csv-reconcile benötigt eine lokale Python Installation und bietet noch keine Vorschau Funktion, ohne die sich der Datenabgleich teilweise mühsam gestaltet.

Die Möglichkeit eigene Datenbanken in Form von CSV Dateien zu nutzen, oder wie im Falle der Indizes zu den Akten des Reichskammergerichts schrittweise aufzubauen, ist jedoch vorhanden und hat das Potential von großer Arbeitserleichterung.

Da wir bei der Bearbeitung des Prokuratoren Index der Akten in Wertheim nicht alle Prokuratoren mit einer GND-ID verknüpfen konnten, haben wir den Daten eine Spalte Nr mit der “GREL expression” row.index + 1 hinzugefügt. ↩︎
Eine Möglichkeit das “Data Extension Problem” zu umgehen, ist aus den abgeglichenen Daten eine neue Spalte mit der “GREL expression” cell.recon.match.id zu erzeugen und die beiden Dateien anschließend mit einem anderen Werkzeug zusammenzuführen. Eine weitere Möglichkeit besteht darin, die andere CSV Datei in OpenRefine als Projekt zu laden und den Abgleich mit der Funktion cross durchzuführen. ↩︎

Findbuch Index mit OpenRefine aufbereiten

Tue, 27 Jul 2021 00:00:00 +0000

In diesem Tutorial arbeiten wir mit OpenRefine und der Gemeinsamen Normdatei (GND) den Prokuratoren Index eines Findbuchs zu Akten des Reichskammergerichts auf.

Wir haben bereits beschrieben, wie wir die Einträge eines Findbuchs mit OpenRefine für den Datenbankimport aufbereiten. In diesem Beitrag geht es um die Aufarbeitung eines Indices von Findbüchern. Wir beginnen mit dem Index der Prokuratoren. Andere Indices folgen gegebenenfalls in weiteren Artikeln.

Generelles Vorgehen

Zur Übersichtlichkeit verwenden wir wieder das Findbuch “Akten des Reichskammergerichts im Staatsarchiv Wertheim - Inventar des Bestands R J 10” aus dem Anhang von “Band 57: Akten des Reichskammergerichts im Staatsarchiv Sigmaringen - Inventar des Bestands R 7. Bearb. von Raimund J. Weber. Kohlhammer 2004” mit 20 verzeichneten Archivalien.

Die Findbücher zu den Akten des Reichskammergerichts enthalten verschiedene Indices. Wir behandeln in diesem Tutorial den Index der Prokuratoren.

Erste Seite des Index der Prokuratoren im Findbuch zu Bestand R J 10.

Wie in Abbildung 1 zu sehen, handelt es sich bei dem Index um ein mehrspaltiges Layout, was das Einlesen in OpenRefine verkompliziert. Zu den einzelnen Prokuratoren finden wir eine Zuordnung von Jahren auf die Findbuchnummer(n) der verzeichneten Archivalie(n).

Zur Aufarbeitung des Index gehen wir wie folgt vor:

Index aus Findbuch extrahieren
Spalten zusammenführen
Informationen zu Prokuratoren zusammenführen
Abgleich mit der Gemeinsamen Normdatei (GND)
Umwandlung in internes Deskriptorenformat

Dabei werden wir die einzelnen Schritte in OpenRefine nicht so detailliert beschrieben, wie in unserem letzten Tutorial. Bei Bedarf, können Details zu einzelnen Schritten dort noch einmal nachgelesen werden.

1. Index aus Findbuch extrahieren

Auch bei den Indices empfiehlt es sich schon diverse Vorarbeiten im Text selbst durchzuführen.

💾 Wir stellen die aufgeräumte Datei zur Verfügung (Rechtsklick und “Ziel speichern unter…”):

Index Prokuratoren Akten RKG Band 57 - Wertheim .

Wir möchten explizit dazu einladen diese Datei zu nutzen, um die einzelnen Schritte in OpenRefine selbst auszuprobieren und damit zu experimentieren.

2. Spalten zusammenführen

Wie in unserem letzten Tutorial erstellen wir mit OpenRefine ein neues Projekt mit “Create Project” und laden die heruntergeladene Datei als Text.

Um das zweispaltige Layout in ein einspaltiges Layout zu überführen, gehen wir wie in Abbildung 2 schematisch dargestellt vor:

Die Spalte “Column 1” benennen wir in Original um.
Wir erstellen “records” aus den einzelnen Seiten.
Wir trennen die Spalten zeilenweise auf.
Wir fassen die “records” in einer Zeile zusammen.
Wir fügen die Spalten wieder zusammen.
Wir trennen die einzelnen Zeilen wieder auf.

Strategie zur Zusammenführung der zwei Spalten in mehreren Schritten.

1 Spalte in Original umbennen

Die Umbenennung der Spalte Column 1 in Original funktioniert über “Column 1" "Edit column" "Rename this column”.

Der geladene Datensatz sieht ansclhießend wie in Abbildung 3 aus.

Bildschirmfoto der geladenen Daten ohne Bearbeitung in OpenRefine.

2 Seiten als records

Um die einzelnen Seiten als “records” zu markieren, erstellen wir eine neue Spalte Seite via “Original" "Edit column" "Add column based on this column…” und verwenden die folgende “expression” um die Seitennummer auszulesen.

value.match(/.(\d+)\s+Anhang/)[0]

Die Seite 519 tragen wir bei der Indexüberschrift “4. Prokuratoren” von Hand ein. Die leeren Zeilen löschen wir über das “Blank row Facet”, das wir über “All" "Facet" "Facet by blank (null or empty string)” aktivieren.

Die Spalte Seite verschieben wir anschließend an die erste Position, um pro Seite ein “record” zu haben. Die nach Seiten organisierten “records” sehen anschließend wie in Abbildung 4 aus.

Bildschirmfoto von Seiten als ‘records’ in OpenRefine.

3 Spalten zeilenweise auftrennen

Um die Spalten aufzuteilen, gibt es wie in Abbildung 5 gezeigt mehrere Möglichkeiten. Es ist möglich ein Trennzeichen anzugeben, einen regulären Ausdruck zum Trennen zu verwenden, oder eine feste Spaltenbreite zu definieren.

Dialog zum Aufteilen von Spalten in OpenRefine.

Bei diesem Findbuch funktioniert die Auftrennung nach einer festen Spaltenbreite nicht, da zum Beispiel die linke Spalte auf Seite 519 größer ist als die linke Spalte auf Seite 520. Also trennen wir an einer Folge von vier oder mehr Leerzeichen auf \s{4,}. Das hat den Nachteil, dass wir die Einrückungen in der zweiten Spalte verlieren. Dies stört uns bei diesem Index nicht.

Das Ergebnis ist in Abbildung 6 gezeigt. Anschließend können wir mit “All" "Trim leading and trailing whitespace” alle unnötigen Leerzeichen in den Spalten entfernen.

Bildschirmfoto der aufgeteilten Spalten in OpenRefine.

4 Records in einer Zeile zusammenfassen

Um die Zeilen pro “record” zusammenzufassen, verwenden wir “Original 1" "Edit Cells" "Join multi-valued cells…” mit der Trennsequzent -:::- und verfahren bei Spalte Original 2 ebenso. Das Ergebnis ist in Abbildung 7 gezeigt.

Bildschirmfoto der zusammengeführen Zeilen in OpenRefine.

5 Spalten zusammenführen

Die Spalten Original 1 und 2 werden über “Original 1" "Edit column" "Join columns…” wieder in der Spalte Original zusammengeführt. Die Einstellungen sind in Abbildung 8 abgebildet.

Dialog zum Zusammenführen der Spalten in OpenRefine.

Das Ergebnis ist in Abbildung 9 gezeigt.

Bildschirmfoto der zusammengeführten Spalten in OpenRefine.

6 Zeilen auftrennen

Um die einzelnen Zeilen wieder aufzutrennen, verwenden wir “Original" "Edit Cells" "Split multi-valued cells…” mit der Trennsequenz -:::-, wie im Dialog in Abbildung 10 abgebildet.

Dialog zum Auftrennen der Zeilen in OpenRefine.

Das Ergebnis ist in Abbildung 11 gezeigt.

Bildschirmfoto der aufgetrennten Zeilen in OpenRefine.

Anschließend können wir alle Zeilen mit Seitennummern entfernen und die Spalte Seite löschen. Dafür ein “Text Facet” auf der Spalte Seite erstellen und die entsprechenden Zeilen auswählen und löschen.

3. Informationen zu Prokuratoren zusammenführen

Wir haben in den vorangegangenen Schritten das zweispaltige Layout in ein einspaltiges Layout überführt und wollen nun für jeden Prokurator ein “record” erzeugen. Dafür trennen wir die Zeilen in einzelne Spalten für Name, (Wirkungs-)Jahre und Verweise auf. Anschließend transformieren wir die einzelnen Spalten, um zum Beispiel die Jahre und Verweise zusammenzufassen.

Informationen auftrennen

Spalte Name

Wir erzeugen von der Spalte Original aus eine neue Spalte Name mit einer “expression”. Dafür suchen wir mit dem regulären Ausdruck [A-Z].+ nach Zeilen, die mit einem Großbuchstaben beginnen.

value.match(/([A-Z].+)/)[0]

Spalte Jahre

Wir erzeugen von der Spalte Original aus eine neue Spalte Jahre mit einer “expression”. Dafür suchen wir mit dem regulären Ausdruck (\d{4}):.+ nach Zeilen, die mit vier Zahlen gefolgt von einem Doppelpunkt beginnen. Davon extrahieren wir die vier Zahlen.

value.match(/(\d{4}):.+/)[0]

Spalte Verweise

Wir erzeugen von der Spalte Original aus eine neue Spalte Verweise mit einer “expression”. Dafür suchen wir mit dem regulären Ausdruck \d{4}:(.+) nach Zeilen, die mit vier Zahlen gefolgt von einem Doppelpunkt beginnen. Davon extrahieren wir alles nach dem Doppelpunkt.

value.match(/\d{4}:(.+)/)[0]

Spalten umformatieren

Die Spalte Original benötigen wir nicht mehr und können sie löschen. Wir verschieben anschließend die Spalte Name an den Anfang, da sie die “records” definiert.

Das Ergebnis ist in Abbildung 12 gezeigt. Anschließend formatieren wir die einzelnen Spalten.

Bildschirmfoto der extrahierten Spalten in OpenRefine.

Spalte Jahre

Die Jahre im Beispiel 1797, 1767, 1770, 1801 wollen wir als Zeitraum im Format 1767 - 1801 zusammenfassen. Dafür führen wir die Zeilen der Spalte Jahre via “Jahre" "Edit Cells" "Join multi-valued cells…” mit der Trennsequenz ,\s+ zusammen.

Die Spalte Jahre transfomieren wir anschließend via “Jahre" "Edit cells" "Transform…”. Dafür bestimmen wir das Minimum und das Maximum in der Liste der Zahlen. Leider gibt es in GREL keine Funktion, die das auf einer Liste (technisch Array) für uns übernehmen kann. Daher gehen wir wie folgt vor:

Wir erzeugen eine Liste years, indem wir mit split() an der Sequenz ,\s+ trennen.
Die einzelnen Jahre year wandeln wir in einer forEach Schleife mit toNumber() in Zahlen um, da sie sonst “fehlerhaft” sortiert werden ("1, 10, 11, 2, 20, ...").
Wir sortieren die Liste years mit sort().
Hat die Liste years nur ein Jahr, dann wandeln wir es mit toString() in Text um.
Hat die Liste years mehrere Elemente, nehmen wir das erste (Minimum) und das letzte Element (Maximum). Durch die Verbindung über - wird automatisch ein Text erzeugt.

with(
 forEach(
 value.split(/,\s+/),
 year,
 year.toNumber())
 .sort(),
 years,
 if(
 years.length() < 2,
 years[0].toString(),
 years[0] + " - " + years[-1]))

Spalte Verweise

Die Verweise führen wir ebenfalls via “Verweise" "Edit Cells" "Join multi-valued cells…” mit der Trennsequenz ,\s+ zusammen.

Die Spalte Verweise transfomieren wir anschließend via “Verweise" "Edit cells" "Transform…”. Bei den Verweisen haben wir mehrere Probleme:

Teilweise werden sie als Bereiche 8-10 angegeben, die wir in 8, 9, 10 überführen wollen.
Es werden zwei verschiedene Bindestriche verwendet, die optisch gleich aussehen.
Wir können Duplikate bei den Verweisen haben.
Die Reihenfolge kann durcheinander sein.

Die “expression” um diese Probleme zu behandeln, ist daher komplex. Hier eine Erklärung des Vorgehens:

Wir trennen die Verweise mit dem regulären Ausdruck ,\s+ in eine Liste (technisch Array).
Jeden der Verweise v in der Liste trennen wir anschließend mit dem regulären Ausdruck –|\- (unterschiedliche Bindestriche) und nennen das Ergebnis v2.
Wenn der Verweis v2 mehrere Elemente hat (es also ein Bereich mit Bindestrich war), dann erzeugen wir mit forRange eine Zahlenliste über diesem Bereich, und verbinden die Zahlen mit join(",") zu einem Text.
Jetzt haben die Bereiche und die einzelnen Verweise das gleiche Format. Also verbinden wir sie ebenfalls mit join(",").
Den verbundenen Text trennen wir anschließend wieder mit , in eine Liste mit einzelnen Verweisen und wandeln die einzelnen Verweise v mit toNumber() in Zahlen um.
Da wir nun eine Liste mit Zahlen haben, können wir mit uniques() die doppelten Verweise entfernen und sie mit sort() sortieren.
Die bereinigte Liste wandeln wir mit join(", ") anschließend wieder in einen Text um.

forEach(
 forEach(
 value.trim().split(/,\s+/),
 v,
 with(
 v.split(/–|\-/),
 v2,
 if(
 v2.length() > 1,
 forRange(v2[0].toNumber(), v2[1].toNumber() + 1, 1, i, i).join(","),
 v2[0]))
 )
 .join(",")
 .split(/,/),
 v,
 v.toNumber())
.uniques()
.sort()
.join(", ")

Spalte Name

Diese Spalte bearbeiten wir als letzte, da wir ansonsten die “record” Struktur verloren hätten. Die “record” Struktur haben wir in den vorherigen Schritten benötigt, um die Jahre und Verweise in einer Zeile zusammenzufassen.

Wir wollen die Spalte Name in Vorname, Nachname und Titel trennen. Das erleichtert uns das Überführen in andere Formate zum Beispiel für den Abgleich mit der GND oder das Umwandeln in ein Deskriptorenformat. Dafür trennen wir die Spalte Name via “Name" "Edit Cells" "Split into several columns…” in drei Spalten am Trennzeichen , auf und lassen sie auch gleich entfernen. Die entsprechenden Einstellungen sind in Abbildung 13 gezeigt.

Dialog zum Aufsplitten von Spalten in OpenRefine.

Die Daten sind nun sauber aufgetrennt und können zur weiteren Verarbeitung verwendet werden. Das Ergebnis ist in Abbildung 14 gezeigt.

Bildschirmfoto der aufgeräumten Spalten in OpenRefine.

4. Abgleich mit der Gemeinsamen Normdatei

--- title: Abgleich mit GND config: look: handDrawn theme: neutral --- flowchart LR text[fas:fa-file-alt Text] data[fas:fa-table Table] gnd[fas:fa-database GND] semantic[fas:fa-project-diagram Graph] text --> data --> semantic gnd --> semantic

Als Bonus gleichen wir die Prokuratoren mit der Gemeinsamen Normdatei (GND) ab. Der Vorgang wird in OpenRefine Reconciling genannt. Dafür verwenden wir den GND Reconciliation Service von lobid. Die Verwendung ist in einem lobid Blogeintrag ausführlich erklärt.

Bei uns hat sich das folgende Vorgehen bewährt.

Zuerst erzeugen wir via “Nachname" "Edit column" "Join columns…” eine neue Spalte Name, wo wir die Namensstruktur “Nachname, Vorname” der GND übernehmen. ¹ Anschließend können wir via “Name" "Reconcile" "Start reconciling” den Vorgang starten.

Falls noch nicht geschehen, den “lobid gnd service” via “Add Standard Service…” mit der URL https://lobid.org/gnd/reconcile hinzufügen und auswählen.

Die entsprechenden Einstellungen für den Abgleichvorgang sind in Abbildung 15 abgebildet. Wir fügen den Titel als separate Spalte hinzu, da wir dadurch bessere Ergebnisse erzielen konnten. Leider können wir die (Wirkungs-)Jahre nicht berücksichtigen, da es keine kleiner/größer Operation für den “Reconciliation Service” gibt.

Dialog zum Abgleich der Daten mit dem ’lobid gnd service'.

Beim “reconciling” werden die Inhalte der ausgewählten Spalten an einen Webservice übertragen! Sollte das nicht gewünscht sein, ist es auch möglich einen lokalen “reconciliation services” einzurichten.

Das Ergebnis ist in Abbildung 16 gezeigt. Jetzt können mit einer Mischung aus Heuristik (zum Beispiel alle Treffer mit Übereinstimmung von mehr als 95 % automatisch übernehmen) und manueller Prüfung die einzelnen Personen verknüpft werden.

Bildschirmfoto der abzugleichenden Daten in OpenRefine.

Anschließend wollen wir die GND-ID als zusätzliche Spalte in unserem Datensatz haben. Das funktioniert über “Name" "Edit columns" "Add columns from reconciled values…”, wo wir die GND-ID wie in dem in Abbildung 17 dargestellten Dialog auswählen können.

Dialog zum Auswählen zusätzlicher Spalten von abgeglichenen Daten.

Wir konnten 18 der 37 Prokuratoren aus unserem Datensatz in der GND identifizieren und verknüpfen. Das Ergebnis ist in Abbildung 18 gezeigt.

Bildschirmfoto der abgeglichenen Daten in OpenRefine.

5. Umwandlung in Deskriptorenformat

Aus den einzelnen Datenbestandteilen können wir nun einen Deskriptor für unser AFIS zusammensetzen. Dafür gehen wir zu einer beliebigen Spalte, um von dort aus mit einer “expression” eine neue Spalte Deskriptor im Format Nachname, Vorname Titel; Prokurator am Reichskammergericht {Wirkungsjahre} | {Optionale GND-ID} zu erzeugen. ²

cells["Nachname"].value.trim()
 + ", " + cells["Vorname"].value.trim()
 + " " + cells["Titel"].value.trim()
 + "; Prokurator am Reichskammergericht " + cells["Jahre"].value.trim()
 + if(isNonBlank(cells["GND-Nummer"]),
 " | " + cells["GND-Nummer"].value,
 "")

Das Endergebnis ist in Abbildung 19 gezeigt.

Bildschirmfoto der umgewandelten und abgeglichenen Daten mit OpenRefine.

💾 Die einzelnen Arbeitsschritte im OpenRefine Format:

Index Prokuratoren Akten RKG Band 57 - Wertheim als OpenRefine Arbeitsschritte .

Fazit

Wir haben mit OpenRefine den Prokuratoren Index eines Findbuchs zu Akten des Reichskammergerichts aus einem zweispaltigen Layout in ein einspaltiges Layout überführt, den Datensatz aufbereitet und die einzelnen Prokuratoren mit der GND abgeglichen.

Die Operationen zum Aufräumen der Daten (Jahre und Verweise) waren diesmal komplex, lassen sich jedoch auf ähnliche Probleme übertragen.

Es bleibt die Erkenntnis, dass der Abgleich von Personen mit dem “Reconciliation Service” von lobid deutlich komfortabler wäre, wenn es möglich wäre eine zeitliche Einschränkung der Lebens- und Wirkungsdaten vorzunehmen. ³

Die Zuordnung der Daten erfolgt über den “Reconciliation Service”. Manche verwenden Verfahren, bei denen eine Übereinstimmung im Format relevant ist und zu besseren Ergebnissen führt. Andere verwenden Verfahren, bei denen die Reihenfolge der Suchbegriffe komplett ignoriert wird. ↩︎
Uns ist gegen Ende aufgefallen, dass wir noch überflüssige Leerzeichen in den einzelnen Spalten haben. Anstatt sie im Deskriptor mit trim() zu entfernen, wäre es sinnvoller gewesen sie vorher mit “All" "Trim leading and trailing whitespace” zu entfernen. ↩︎
Update April 2022: Durch ein Update in dem lobid GND API für OpenRefine kann nun eine zeitliche Einschränkung beim Reconciliation vorgenommen werden. Details dazu finden sich unter Using range query parameter via OpenRefine Reconciliation auf GitHub und unter Erweiterter GND Abgleich mit lobid auf unserem Blog. ↩︎

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