Tutorial | FDMLab@LABW

Workshop - Python in OpenRefine

Wed, 14 May 2025 00:00:00 +0000

Wir verwenden Python zusammen mit OpenRefine.

Jython in der OpenRefine Dokumentation.
Einsteiger Workshop 19 Daten mit OpenRefine clustern.
Blogbeitrag Named Entity Recognition mit OpenRefine und spaCy.

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

Die in diesem Tutorial behandelten Funktionen sind teilweise erst verfügbar seit der Version OpenRefine 3.9.3.

Jython

Quasi überall, wo man in OpenRefine GREL-Expressions schreiben kann, kann man stattdessen auch auf Jython umstellen. Also beispielsweise für den Transformations-Dialog, Facets oder neu auch für eigene Clustering Methoden.

Bildschirmfoto des Transformations Dialogs mit Jython.

Praktisch wird das Jython-Snippet, welches man wie in Abbildung 1 gezeigt im Dialog eingibt, in eine Python-Funktion gepackt und dann von Jython ausgeführt. Daher benötigt man im Unterschied zu GREL ein return Statement, um anzugeben, welcher Wert zurückgegeben wird.

def some_fun_name(value, cell, cells, row, rowIndex, value1, value2):
 ...

Das eingegebene Snippet wird quasi anstelle von ... eingesetzt.

Zu den in GREL zur Verfügung stehenden Variablen haben wir schon einiges geschrieben. Diese stehen mit Ausnahmen in Jython unter OpenRefine ebenfalls zur Verfügung. Beispielsweise fehlt die Variable columnName mit dem aktuellen Spaltennamen.

Jython selbst ist eine Java Implementierung von Python. Das bedeutet, dass es innerhalb von Java interpretiert wird und man auch von Jython Code aus auf verfügbare Java Methoden zugreifen kann.

Leider hat das Projekt den Sprung auf Python 3 nicht geschafft und unterstützt daher nur die Funktionalität von Python 2.7. Das macht auch die Verwendung von externen Python Bibliotheken innerhalb von Jython deutlich komplexer.

Es gibt nur noch selten Python Bibliotheken, die Python 2.7 unterstützen. Und es können auch nur Python Bibliotheken verwendet werden, die komplett in Python geschrieben wurden. Einige gerade sehr beliebte Python Projekte verwenden aus Performance Gründen unter der Haube kompilierte Programmiersprachen wie C, Fortran oder Rust. Diese können unter Jython nicht direkt verwendet werden.

Praktisch ist die Ausführung von Jython Code in OpenRefine auch deutlich langsamer, als z.B. GREL oder Clojure Code. Das macht es eher schwierig komplexere Algorithmen z.B. für das Clustering direkt zu hinterlegen.

Alternativ kann von OpenRefine aus, via Jython auf externen Python Code zugegriffen werden, was im folgenden Teil vertieft wird.

Python

Standard Setup

Wir verfolgen die Idee von OpenRefine aus auf Python Code zuzugreifen, der nicht innerhalb von Jython ausgeführt wird. Dafür benötigen wir einen Blick in das Python Projekt Setup.

--- title: Python Setup config: look: handDrawn theme: neutral --- flowchart LR subgraph web[fas:fa-globe Web] subgraph python[fab:fa-python Python] python_3_12[fab:fa-python 3.12] python_3_13[fab:fa-python 3.13] end subgraph packages[fas:fa-folder-tree Packages] typer_0_15[Typer 0.15] fastapi_0_115[FastAPI 0.115] spacy_3_8[spaCy 3.8] my_project_0_1[My Project 0.1] end end subgraph laptop[fas:fa-laptop Laptop] subgraph local_python[fab:fa-python Python] local_python_3_12[fab:fa-python 3.12] local_python_3_13[fab:fa-python 3.13] end subgraph local_packages[fas:fa-folder-tree Packages] local_typer_0_15[Typer 0.15] local_fastapi_0_115[FastAPI 0.115] subgraph local_spacy_3_8[spaCy 3.8] c_code[fab:fa-c Code] compiled_c_code[fab:fa-c compiled] end end subgraph my_project[My Project] subgraph venv[fas:fa-folder-open venv] venv_python_3_12[fab:fa-python 3.12] venv_typer_0_15[Typer 0.15] venv_fastapi_0_115[FastAPI 0.115] venv_spacy_3_8[spaCy 3.8] end package_my_project[My Project] end end python --(1)--> local_python python_3_12 ~~~ local_python_3_12 python_3_13 ~~~ local_python_3_13 packages --(2)--> local_packages typer_0_15 ~~~ local_typer_0_15 fastapi_0_115 ~~~ local_fastapi_0_115 spacy_3_8 ~~~ local_spacy_3_8 c_code --(3)--> compiled_c_code local_python_3_12 --(4)--> venv_python_3_12 local_typer_0_15 --(4)--> venv_typer_0_15 local_fastapi_0_115 --(4)--> venv_fastapi_0_115 local_spacy_3_8 --(4)--> venv_spacy_3_8 my_project_0_1 ~~~ package_my_project package_my_project --(5)--> my_project_0_1

Für ein typisches Python Projekt benötigt man fünf Schritte, die durch verschiedene Tools in unterschiedlichem Ausmaß unterstützt werden.

Schritt 1: Python Interpreter

Zuerst benötigt man einen Python Interpreter, der es ermöglicht Python Code auf dem eigenen Rechner auszuführen. Zur Verwaltung verschiedener Python Versionen auf dem Rechner gibt es zum Beispiel das Projekt pyenv.

Schritt 2: Dependency Management

Üblicherweise werden verschiedene externe Bibliotheken benötigt. Diese stehen zum Beispiel im Python Package Index (PyPI) zur Verfügung und können mit pip verwaltet werden.

Alternativen zur Verwaltung der Abhängigkeiten sind Poetry, pip-tools und pipx.

Schritt 3: Compiler

Wie schon angesprochen beinhalten manche Python Projekte nicht nur Python Code, sondern auch Code in kompilierten Sprachen. Wenn für die von euch verwendete Kombination aus CPU und Betriebssystem (noch) kein kompiliertes Binärpaket für die Bibliothek zur Verfügung steht, dann muss das Paket ggf. auf eurem Rechner kompiliert werden. Dafür werden entsprechende Compiler und Entwicklungspakete auf dem Rechner benötigt.

Alternativ gibt es auf conda-forge eine Sammlung schon kompilierter Pakete.

Schritt 4: Virtuelle Umgebung

Erfahrungsgemäß bleibt es nicht bei einem Python Projekt auf dem eigenen Rechner. Um Konflikte zwischen den Python Versionen und/oder Abhängigkeiten zu vermeiden, ist es üblich für jedes Projekt eine eigene virtuelle Umgebung anzulegen.

Dafür gibt es das Werkzeug venv, welches früher ein separates Paket war, und seit Python 3.3 in den Standard übernommen wurde.

Schritt 5: Package und Release Management

Möchte man das Projekt anschließend für andere z.B. im Python Package Index zur Verfügung stellen, dann muss es davor noch in das passende Paketformat umgewandelt werden. Da das für die Benutzung mit OpenRefine nicht relevant ist, wird dieser Schritt hier nicht vertieft.

uv

Das oben beschriebene Setup klingt recht kompliziert und daher abschreckend gerade für kleinere Experimente. Spätestens seit 2025 setzt sich bei Python Entwicklern hier das Projekt uv durch, welches die Schritte 1, 2, 4 und 5 in einem Werkzeug vereint und das Python Setup dadurch deutlich vereinfacht.

Für die Installation von uv werden mehrere einfache und direkte Wege beschrieben.

Sollte man mit dem Windows-Subsystem for Linux (WSL) arbeiten, dann benötigt man die Installationsanleitung für Linux, auch wenn man Windows als Betriebssystem hat.

uv hat (quasi) drei für uns relevante Modi:

uvx zum Ausführen von Tools.
uv run zum Ausführen von Skripten.
uv zum Arbeiten mit Projekten
(mehrere abhängige Python Dateien, separates Dependency Management).

Wir konzentrieren uns in dieser Anleitung auf die ersten beiden.

Reconciliation Service

Um die Verwendung von uvx zum Ausführen von externen Python Werkzeugen zu demonstrieren, erstellen wir einen eigenen Reconciliation Service basierend auf einer CSV-Datei mit uvx und csv-reconcile. Zum Herunterladen der CSV-Datei von 12 Daten zwischen Projekten abgleichen verwenden wir uvx mit httpie.

In einem Terminal wie iTerm, xTerm, Bash oder Powershell führen wir den folgenden Befehl aus.

uvx --from httpie http --download GET https://fdmlab.landesarchiv-bw.de/data/openrefine-workshop/12_staedte-in-bw-geokoordinaten.csv

Dieses kompakte Snippet lädt die zu diesem Zeitpunkt standardmäßige Python Version und die aktuellste Version von httpie herunter, erstellt damit eine virtuelle Umgebung (venv) und führt darin den Befehl http --download GET ... aus.

Den Reconciliation Service basierend auf der im letzten Schritt heruntergeladenen Datei erstellen wir in zwei Schritten:

Datenbank für Reconcilation Service erstellen
Reconciliation Service starten

uvx csv-reconcile init 12_staedte-in-bw-geokoordinaten.csv "GND ID" "Name"

Mit diesem Snippet erstellen wir die Datenbank für den Reconciliation Service und legen die Spalte “GND ID” als ID-Spalte fest und die Spalte “Name” als Standardspalte für den Abgleich. Den Reconciliation Service selbst starten wir mit dem folgenden Befehl.

uvx csv-reconcile serve

In OpenRefine können wir den Reconciliation Service anschließend hinzufügen mit: http://127.0.0.1:5000/reconcile.

Datenbank mit eigener Konfiguration

Der oben erstelle Reconciliation Service ist recht generisch und es fehlt z.B. noch die Vorschaufunktion für die einzelnen Elemente. Um den Service nach unseren Anforderungen zu konfigurieren, erstellen wir eine Datei config.py mit dem folgenden Inhalt.

SERVER_NAME="localhost:5000"
CSVKWARGS={'delimiter': ',', 'quotechar': '"'}
CSVENCODING='UTF-8'
MANIFEST = {
 "name": "Städte in BW Reconciliation Service",
 "identifierSpace": "https://normdaten.landesarchiv-bw.de/ids",
 "schemaSpace": "https://normdaten.landesarchiv-bw.de/schema",
 "extend": {
 "propose_properties": {
 "service_url": "http://localhost:5000",
 "service_path": "/properties"
 }
 },
 "preview": {
 "url": "http://localhost:5000/preview/{{id}}",
 "width": 500,
 "height": 300
 }
}

Anschließend erstellen wir die Reconciliation Datenbank mit der neuen Konfiguration.

uvx csv-reconcile init --config config.py 12_staedte-in-bw-geokoordinaten.csv "GND ID" "Name"

Der neue Service ist nach dem Starten unter http://localhost:5000/reconcile erreichbar.

uvx csv-reconcile serve

In OpenRefine müssen wir den CSV Reconciliation Service aktuell bei jeder Änderung der Konfiguration neu hinzufügen.

Der Reconciliation Service kann jetzt wie in Abbildung 2 mit dem Beispiel aus 12 Daten zwischen Projekten abgleichen getestet werden.

Screencast zum Reconciling mit OpenRefine und CSV-Datei.

Eigene Skripte

Um Command Line Interfaces (CLIs) zu erstellen, gibt es in Python die Standardbibliothek argparse. Meistens möchte man aber “nur mal schnell” aus einer Python Funktion ein Werkzeug erstellen, welches von der Kommandozeile aufgerufen werden kann. Ein nützliches Python Projekt dafür ist typer.

Typer Hello World Beispiel

Ein einfaches “Hello World” Beispiel mit uv und Typer ist im folgenden Quellcode aus hello_world.py abgebildet.

# /// script
# requires-python = ">=3.12"
# dependencies = [
# "typer",
# ]
# ///
import typer

def hello_world():
 print("Hello World")

if __name__ == "__main__":
 typer.run(hello_world)

Zu Beginn wird über Inline Metadaten definiert, dass das Skript mit Python 3.12 oder neuer ausgeführt werden soll und das Skript zusätzlich die externe Abhängigkeit typer benötigt.

Das Werkzeug uv unterstützt diese inline Metadaten, so dass zum Ausführen dieses Skriptes in einem Terminal lediglich uv run hello_world.py ausgeführt werden muss.

Das Werkzeug Typer übersetzt den CLI-Aufruf für die Python Funktion, und validiert und konvertiert dabei die Eingabedaten.

Typer Beispiel mit Parametern

Wir beginnen mit einem einfachen Beispiel.

# /// script
# requires-python = ">=3.12"
# dependencies = [
# "typer",
# ]
# ///
import typer

def add(a, b):
 print(a + b)

if __name__ == "__main__":
 typer.run(add)

Die Funktion add soll zwei Parameter a und b miteinander addieren und dann ausgeben. Zum Ausgeben des Ergebnisses verwenden wir die Funktion print. Das Werkzeug typer erkennt automatisch die beiden Parameter a und b und meldet, wenn diese nicht gesetzt sind. Unter uv run add.py --help erhalten wir einen Informationstext zur Benutzung unseres CLI-Tools.

Standardmäßig werden die Parameter als Text interpretiert. Mit so genannten Type Hints können wir Typer mitteilen, dass wir hier Zahlen erwarten.

def add(a: int, b: int):
 print(a + b)

Es ist auch möglich, optionale Parameter wie c mit anzugeben.

def add(a: int, b: int, c: int = 0):
 print(a + b + c)

Individuelle Konfigurationen können mit Type Annotations hinterlegt werden.

def add(a, b, c: Annotated[int, typer.Argument()] = 0):
 print(a + b + c)

Mit den Annotationen lässt sich bei Bedarf der Text für die Hilfe weiter spezifizieren. Hier das fertige Skript mit ausführlicherem Hilfstext.

# /// script
# requires-python = ">=3.12"
# dependencies = [
# "typer",
# ]
# ///
import typer
from typing_extensions import Annotated

def add(
 a: Annotated[int, typer.Argument(help="The first number to add.")],
 b: Annotated[int, typer.Argument(help="The second number to add.")],
 c: Annotated[int, typer.Argument(help="The optionally third number to add.")] = 0,
):
 """
 Add the numbers in `a` and `b` and optionally `c` if `c` is provided.
 """
 print(a + b + c)

if __name__ == "__main__":
 typer.run(add)

Das Praktische an Typer ist, dass man “nur zum Ausprobieren” lediglich die type hints und den Aufruf von Typer im Skript ergänzen muss. Bei Bedarf können ausführlichere Hilfstexte oder Validierungen hinterlegt werden, deren Ergebnis in Abbildung 3 gezeigt ist.

Screenshot Terminal mit von Typer generierten Hilfstext.

Zugriff von OpenRefine auf Python Skript

Von OpenRefine heraus, lässt sich mit Jython recht unkompliziert auf das externe Python Skripte zugreifen. Es muss lediglich der Pfad des Skriptes in dem Jython Snippet unten angepasst werden. Ggf. müssen auch noch Parameter für das Skript ergänzt werden.

import subprocess
script = "C:\\...\\python_script.py"
res = subprocess.check_output(
 ["uv", "run", script, "\""+value+"\""],
 shell=True,
)
return res

Probleme beim Zugriff von OpenRefine auf Python Skripte

Der direkte Zugriff auf ein Skript ist erst einmal relativ performant, hat in der Praxis aber mehrere Probleme.

Die korrekte Übergabe von Daten an das Skript via Parametern ist nicht ganz so einfach. Besonders, wenn die Daten größer sind ggf. Sonderzeichen enthalten, …
Man ist selbst für die Fehlerbehandlung verantwortlich. Also dass die Skripte auch irgendwann beendet werden, bei zu langer Laufzeit abgebrochen werden, usw.
Es wird lediglich Text zurückgegeben. Die Interpretation in ein bestimmtes Format muss dann in Jython oder in einem Nachbearbeitungsschritt erfolgen.
Manche Skripte oder Tools müssen initial erst einmal Daten in den Arbeitsspeicher laden. Insbesondere bei Machine Learning Anwendungen kann das mehrere Sekunden dauern. Dies erfolgt bei jedem Skriptaufruf wieder erneut.

Daher ist es wesentlich stabiler stattdessen mit eigenen Web-APIs zu arbeiten.

Eigene Web-APIs mit FastAPI

--- title: Script vs Web-API config: look: handDrawn theme: neutral --- flowchart LR subgraph openrefine["OpenRefine"] subgraph jython["Jython"] jython_code["Jython Code"] end end subgraph venv script["fab:fa-python Skript"] end subgraph uvicorn["Uvicorn"] subgraph fastapi["FastAPI"] python_code["fab:fa-python Code"] end end jython_code -.-> script jython_code -.-> script jython_code -.-> script jython_code -.-> script jython_code -.-> script jython_code -.-> script jython_code -.-> script jython_code -.-> script jython_code -.-> script jython_code <--HTTP--> python_code

Für Web-APIs gibt es etablierte und stabile Protokolle zum Austausch von Daten. Ähnlich wie mit Typer können wir mit FastAPI unsere Python-Funktionen als Web-API zur Verfügung stellen. Mit einem Server wie uvicorn sorgen wir dabei für eine Stabilität der angestoßenen Prozesse für die Abfragen.

Beispielcode für spaCy

Das folgende Skript lädt ein deutschsprachiges Modell von spaCy und berechnet über Word Embeddings die Ähnlichkeit bzw. hier die Distanz der beiden übergebenen Texte.

# /// script
# requires-python = ">=3.12,<3.13"
# dependencies = [
# "spacy",
# "typer",
# "de_core_news_lg @ https://github.com/explosion/spacy-models/releases/download/de_core_news_lg-3.8.0/de_core_news_lg-3.8.0.tar.gz",
# ]
# ///

import typer
import de_core_news_lg as model


def spacy_distance(a: str, b: str):
 nlp = model.load()
 doc_a = nlp(a)
 doc_b = nlp(b)
 dist = 1 - doc_a.similarity(doc_b)
 print(dist)


if __name__ == "__main__":
 typer.run(spacy_distance)

Das Skript hat den eindeutigen Nachteil, dass es bei jedem Aufruf das “große” Sprachmodell laden muss, was mehrere Sekunden dauert. Hier im Vergleich das Skript spacy_distance_fastapi.py, welches die Funktionalität via FastAPI zur Verfügung stellt.

# /// script
# requires-python = ">=3.12,<3.13"
# dependencies = [
# "spacy",
# "fastapi",
# "uvicorn",
# "de_core_news_lg @ https://github.com/explosion/spacy-models/releases/download/de_core_news_lg-3.8.0/de_core_news_lg-3.8.0.tar.gz",
# ]
# ///

import de_core_news_lg as model
import uvicorn
from fastapi import FastAPI

app = FastAPI()
nlp = model.load()


@app.get("/distance")
def spacy_distance(a: str, b: str) -> float:
 doc_a = nlp(a)
 doc_b = nlp(b)
 dist = 1 - doc_a.similarity(doc_b)
 return dist


if __name__ == "__main__":
 uvicorn.run("spacy_distance_fastapi:app", host="127.0.0.1", port=5000)

Die Verarbeitungspipeline für die Texte mit dem “großen” Sprachmodell wird außerhalb der Python Methode definiert, weshalb das Modell pro Aufruf nur einmal aufgerufen werden muss. Im Vergleich zum direkten Skriptaufruf, ist der Zugriff auf unsere lokale Web-API zwar etwas langsamer. Wir profitieren aber von der Müglichkeit ladeintensive Prozesse nur einmal beim Starten auszuführen, sowie von dem zusätzlichen Protokoll im Bereich Fehlerbehandlung, Validierung von Eingaben und Antworten.

Ähnlich wie bei Typer übernimmt FastAPI hier das Mapping der Benutzeranfrage auf die entsprechende Python Funktion. Gleich wie bei Typer werden Type Hints für das Mapping, die Dokumentation und die Validierung verwendet. Auch bei FastAPI kann die Dokumentation mit weiteren Annotationen erweitert und personalisiert werden.

Somit lassen sich mit FastAPI eigene Web-APIs ähnlich leicht erstellen, wie einfache Python Skripte mit Typer. Ausführliche Beispiele stehen im Anhang bzw. als GitHub Gist unter spacy_fastapi.py und rapidfuzz_fastapi.py zur Verfügung.

Von OpenRefine heraus kann man via Jython auf die (lokalen) Web-APIs zugreifen.

Zugriff via GET

Web-APIs unterscheiden für den Abruf von Daten zwischen GET- und POST-Requests (Anfragen). Für GET-Requests gibt es in OpenRefine die Möglichkeit den Dialog Add column by fetching URLs zum Nachladen von Daten zu verwenden.

"http://localhost:5000/ner?text=" + escape(value, "url")

Hier kann man mit einfachem GREL die benötigte URL zusammen bauen. Man sollte jedoch daran denken, die Parameter mit escape für die URL kompatibel aufzubereiten.

In Abbildung 4 ist der Dialog aus 18 Nachladen von Geokoordinaten gezeigt.

Bildschirmfoto des Dialogs zum Nachladen von URLs für GeoNames.

Möchte man eine Web-API z.B. von einem Facet oder einem Clustering-Dialog heraus aufrufen, benötigt man dafür das folgende Jython-Snippet um einen validen GET-Request zu erstellen.

import json, urllib, urllib2
url = "http://localhost:5000/ner"
request_data = urllib.urlencode({
 "text": value.encode("utf-8"),
})
response = urllib2.urlopen(url + "?" + request_data)
return json.dumps(json.load(response), ensure_ascii=False)

Zur Erinnerung: Es gibt Python Bibliotheken wie requests, die das Erstellen und Verarbeiten von Web-Requests deutlich vereinfachen. Wir arbeiten in OpenRefine aber mit Jython und können daher nicht einfach auf externe Bibliotheken zugreifen.

Zugriff via GET und Form

Manche Web-APIs erwarten einen GET-Request mit zusätzlichem Nutzdaten z.B. aus einem Formular. Das lässt sich in Jython / Python 2.7 mit folgendem Snippet umsetzen.

import json, urllib, urllib2
url = "http://localhost:5000/ner"
request_data = urllib.urlencode({
 "text": value.encode("utf-8"),
})
response = urllib2.urlopen(url, request_data)
return json.dumps(json.load(response), ensure_ascii=False)

Der Unterschied zum letzten Beispiel ist, dass request_data als zusätzliche Nutzdaten mit einem Komma getrennt an urllib2 übergeben werden, anstatt sie mit an die URL zu kodieren.

Zugriff via POST

Der in den Beispielen im Anhang verwende Use-Case ist das Verwenden von POST-Requests. Hier werden die Nutzdaten als JSON kodiert an den Request angehängt. Das macht die Kodierung der Daten in der Anfrage komplexer, gleichzeitig aber die Übermittlung stabiler.

import json, urllib, urllib2
url = "http://localhost:5000/ner"
request_data = json.dumps({
 "text": value.encode("utf-8"),
})
request = urllib2.Request(
 url,
 request_data,
 {"Content-Type": "application/json"},
)
response = urllib2.urlopen(request)
return json.dumps(json.load(response), ensure_ascii=False)

Der komplette Workflow vom Starten des Web-Service, bis zur Verwendung von RapidFuzz als eigene Clustering Methode in OpenRefine ist in dem Screencast in Abbildung 5 gezeigt.

Screencast zur Verwendung von uv, FastAPI und RapidFuzz als eigene Clustering Methode bei OpenRefine.

Fazit

Kleinere Skripte mit Jython / Python 2.7 in OpenRefine sind möglich, jedoch gerade beim Clustering oder bei der Nachnutzung von externen Python Projekten problematisch.

Mit Typer und FastAPI lassen sich aus Python Funktionen heraus schnell CLI-Tools oder Web-APIs erstellen. Die beiden Werkzeuge ermöglichen es sowohl mit wenig Aufwand Prototypen zu erstellen, als auch diese zu dokumentierten praktischen Tools zu erweitern.

Mit uv sind die Hürden für das Erstellen von indivduellen Python Umgebungen für einzelne Skripte sehr stark gesenkt worden. Das reduziert nicht nur den Entwicklungsaufwand, sondern erleichtert auch die Nachnutzung von Skripten für Nutzerinnen und Nutzer.

Mit der Kombination aus Jython, uv und wahlweise Typer oder FastAPI lassen sich dadurch modernste Python Anwendungen direkt mit OpenRefine verbinden.

Anhang

FastAPI Wrapper für spaCy

FastAPI Wrapper für RapidFuzz

Workshop - Erweitertes Clustering

Mon, 05 May 2025 00:00:00 +0000

Wir verwenden eigene Clustering Methoden in OpenRefine, um Schreibweisen zu vereinheitlichen.

Clustering in der OpenRefine Dokumentation.
Clustering im OpenRefine Wiki.
Einsteiger Workshop 05 Daten mit OpenRefine clustern.

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

Die in diesem Tutorial behandelte Funktionalität ist verfügbar seit OpenRefine 3.9.3.

Daten

Wir benötigen die folgenden Dateien als OpenRefine Projekt:

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

Erweitertes Clustering

In der nachfolgenden Tabelle sind typische Probleme dargestellt, die mit den Standard Clusteringverfahren von OpenRefine nicht direkt zu lösen sind.

Ort	Name	Name 2
XY, Ort in Bayern	Hans Meier	Hans Meier
XY (Bayern)	Maier, Hans	Hans Peter Meier
XY in Bayern	Hans Peter Meyer	Hans P. Meier
XY; Bayern	Hans (Peter) Maier	Hans (Peter) Meier
XY \| Bayern	Hans P. Mayer	Hans Müller
XY, liegt in Bayern	Meier, Hans (Peter)	Hans Peter Müller

In der Spalte Ort gibt es unterschiedliche Ansetzungen für einen Ort in Bayern. Die Spalte Name enthält unterschiedliche Schreibweisen für den Namen Hans Peter Meier. Und die Spalte Name 2 enthält Hans Peter Meier und Hans Peter Müller jeweils mit und ohne Zweitnamen.

Keying Functions

Eine von OpenRefine unterstützte Art des Clusterings sind so genannte key collision Verfahren.

Die Idee dahinter ist, dass ein Eingabetext nach einheitlichen Regeln umgewandelt wird. Die Ergebnisse der Umwandlungen werden dann verglichen und die gleichen Ergebnisse zusammengefasst.

Typische Beispiele für Umwandlungsregein sind:

Wörter sortieren
Sonderzeichen entfernen oder umwandeln
Wörter auf Normalformen bringen
Synonyme auflösen
n-Gramme erstellen
…

Einige dieser Methoden sind in OpenRefine implementiert. Dennoch sind sie häufig nicht ausreichend für spezifischere Probleme. Seit OpenRefine 3.9.3 ist es möglich eigene Clustering Algorithmen in den von OpenRefine unterstützten Programmiersprachen zu hinterlegen.

Im Folgenden stellen werden zwei Algorithmen für das Keying vorstellt.

OrtFingerprint

Das Problem bei den Werten in der Spalte Ort ist, dass wir unterschiedliche Sonderzeichen, als auch “überflüssige” Wörter haben, die eine Zusammenführung via Clustering erschweren.

Der Screencast in Abbildung 1 zeigt, wie im Clustering Dialog unter Manage clustering functions eigene Clustering Funktionen hinterlegt werden. In dem Beispiel ist das ein GREL-Ausdruck, der die Fingerprint Methode von OpenRefine mit unserem domänenspezifischem Wissen kombiniert.

Screencast zum Anlegen und Anwenden eigener Clustering Funktionen.

In dem nachfolgenden GREL-Ausdruck werden vor der Anwendung der Fingerprint Methode von Openrefine die folgenden Schritte durchgeführt:

Sonderzeichen entfernen, die die Fingerprint Methode nicht berücksichtigt ("|").
Stoppworte entfernen ("Ort").
Klein geschriebene Wörter entfernen (/\b[a-z]+\b/).

fingerprint(value.replace("|", "").replace("Ort", "").replace(/\b[a-z]+\b/, ""))

Das Ergebnis ist eine spezifische Fingerprintmethode, die wie in Abbildung 1 gezeigt, unterschiedliche Ansetzungen bei Orten berücksichtigen kann.

CologneFingerprint

Die in OpenRefine implementierten Clustering-Methoden lassen sich nachnutzen und kombinieren. Der folgende GREL-Ausdruck wendet zuerst das Fingerprinting und dann die Normalisierung bzgl. der deutschen Aussprache mit Cologne Phonetic an.

fingerprint(value).phonetic("cologne-phonetic")

Auf diese Weise können die Werte in der Spalte Name wie in Abbildung 2 gezeigt (größtenteils) zusammengeführt werden.

Bildschirmfoto des Clustering Dialogs mit kombiniertem Fingerprinting und Cologne Phonetic Algorithmus.

Distance Functions

Bei den Distanzfunktionen werden die Texte nicht umgewandelt, sondern mit unterschiedlichen Metriken berechnet, wie “weit” sie voneinander entfernt sind. Dafür erhält man Zugriff auf die Variablen value1 und value2 und gibt eine Zahl zurück, die die Distanz zwischen den beiden Werten repräsentiert. Je größer die Zahl, desto “unähnlicher” sind die Texte.

Manche Algorithmen betrachten auch positiv die Ähnlichkeit (Similarity) von Texten. Dabei sind die beiden Metriken einfach umzurechnen: $distance = 1 - similarity$.

Manche Algorithmen betrachten die Ähnlichkeit bzw. die Distanz auch nicht als Wert zwischen 0 und 1.0, sondern zwischen 0 und 100.

FingerprintDistance

Ein typisches Problem ist, dass man sowohl unterschiedliche Ansetzungen, als auch leichte Abweichungen hat. Hier lässt sich zum Beispiel das Fingerprinting in OpenRefine mit der Implementierung der Levenshtein-Distanz kombinieren.

levenshteinDistance(fingerprint(value1), fingerprint(value2))

In Abbildung 3 sind die Ergebnisse der kombinierten Algorithmen auf der Spalte Name gezeigt.

Bildschirmfoto des Clustering Dialogs mit kombiniertem Fingerprinting und Levenshtein-Algorithmus.

AbsoluteDistance

In der Spalte Name 2 ist das Problem mit Extrabegriffen wie Zweitnamen etwas deutlicher gezeigt. Hier könnte man Methoden anwenden, die Distanzen auf Wortebene berechnen.

Im Folgenden Code Beispiel ist ein Jython-Algorithmus, der die Datenstruktur Counter verwendet um eine Art Bag-of-words Model zu erstellen.

Die Distanz ist hier, die Anzahl an unterschiedlichen Worten zwischen den beiden Texten.

import re
from collections import Counter

splitter = re.compile(r"\W+")
words = Counter(splitter.split(value1.strip()))
words.subtract(Counter(splitter.split(value2.strip())))
dist = sum(abs(count) for count in words.values())

return dist

Wie in Abbildung 4 gezeigt, hilft diese Methode bei dem Problem von einzelnen Extrabegriffen, die den auf Buchstabenebene arbeitenden Levenshtein-Algorithmus “überfordern”.

Bildschirmfoto des Clustering Dialogs mit AbsoluteDistance Funktion.

CosineDistance

Eine wichtige Distanzmetrik zur Berechnung der Ähnlichkeit (oder in dem Fall der Distanz) zwischen Vektoren ist die Kosinus-Ähnlichkeit. Dies ist exemplarisch in dem folgenden Jython-Code umgesetzt.

import re
from collections import Counter

splitter = re.compile(r"\W+")
a = Counter(splitter.split(value1.strip()))
b = Counter(splitter.split(value2.strip()))
words = list(set(a) | set(b))

a_vec = [a.get(word, 0) for word in words]
b_vec = [b.get(word, 0) for word in words]

v_len = lambda v: sum(x * x for x in v) ** 0.5
v_dot = lambda v1, v2: sum(x * y for x, y in zip(v1, v2))
dist = 1 - v_dot(a_vec, b_vec) / (v_len(a_vec) * v_len(b_vec))

return dist

Ähnlich wie bei der AbsoluteDistance zählen wir, wie oft ein Wort im Text vorkommt. Diesmal berücksichtigen wir (vereinfacht ausgedrückt) zusätzlich die Länge der Texte. Dadurch ist der Rückgabewert eine Zahl zwischen 0 und 1. Wie in Abbildung 5 gezeigt, erhält man mit dem in OpenRefine voreingestellten Standardradius von 1.0 dadurch alle möglichen Cluster. Für sinnvolle Ergebnisse sollte man den Radius bei Verwendung der Kosinus-Ähnlichkeit also auf Werte zwischen 0.1 und 0.3 reduzieren.

Bildschirmfoto des Clustering Dialogs mit CosineDistance Funktion.

Weitere Ideen

Mit Jython lassen sich auch Skripte auf dem eigenen Rechner ausführen oder Web-APIs ansprechen. Damit kann man komplexere und effizientere Algorithmen implementieren und/oder auf andere Python Pakete zurückgreifen.

Hier ist eine kleine Sammlung von weiteren Ideen:

Keying
- Liste mit Synonymen einlesen und Synonym-Cluster-ID zurückgeben.
- Lemma, Normalform oder Lexem berechnen z.B. mit spaCy.
- …
Distance
- Texte z.B. mit spaCy in Wortvektoren umwandeln und Abstand berechnen.
- Levenshtein-Distanz mit mehr Einstellmöglichkeiten via RapidFuzz.
- …

Fazit

Eigene Clustering-Funktionen hinterlegen zu können ermöglicht komplett andere Arbeitsabläufe und reduziert regelmäßige manuelle Nacharbeiten.

In Kombination mit der Möglichkeit z.B. über Jython Web-APIs anzusprechen, können zusätzlich Funktionalitäten von externen Werkzeugen für das Clustering genutzt werden.

Im nächsten Teil beschäftigen wir uns Python mit OpenRefine zu verwenden.

20 Python mit OpenRefine

Workshop - Nachladen von Geokoordinaten

Thu, 08 Aug 2024 00:00:00 +0000

In diesem Tutorial beschäftigen wir uns mit dem Nachladen von Geokoordinaten.

Einführung

Reconciling in der OpenRefine Dokumentation.
Spalten via URL hinzufügen in der OpenRefine Dokumentation
OpenRefine API in der lobid API Dokumentation.
Getty Research Institute zu OpenRefine Reconciliation.
Informationssammlung zu OpenRefine Wikidata Reconciliation.

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

Die Situation von Orten in den Datenquellen unterscheidet sich teils stark und ändert sich stets. Daher werden in diesem Tutorial unterschiedliche Strategien gezeigt.

OpenRefine unterstützt für den Abgleich mit Datenquellen die Reconciliation Service API. In dem Workshop wurde schon gezeigt, wie Daten mit der GND, Wikidata und Getty abgeglichen werden können. In diesem Teil des Workshops beschäftigen wir uns im ersten Teil, wie wir von Normdatenverknüpfungen zu Geokoordinaten kommen. Im zweiten Teil behandeln wir den allgemeinen Umgang mit Zugriff auf Daten von GeoNames und OpenStreetMap über allgemeine Geocoding APIs.

--- title: Zusammenhang (Norm-)datenquellen config: look: handDrawn theme: neutral --- flowchart LR ort["Ort"] gnd["GND"] wikipedia["Wikipedia"] wikidata["Wikidata"] tgn["Getty TGN"] geonames["GeoNames"] coordinates[[Koordinaten]] ort --Recon--> gnd & wikidata & tgn ort --API--> geonames gnd --Extend--> wikipedia gnd <--Extend--> wikidata gnd --Extend--> geonames wikipedia --API--> coordinates & wikidata wikidata --Extend--> coordinates wikidata --Extend---> geonames wikidata --Extend--> tgn tgn --Extend--> coordinates geonames --API--> coordinates

In dem Diagramm sind verschiedene Wege gezeigt, die zum Nachladen von Geokoordinaten genommen werden können. Teilweise sind nicht bei allen Orten in den Datenquellen Geokoordinaten hinterlegt, so dass wir der Extend Funktionalität der Reconciliation Service Specification z.B. von der GND-ID zu Wikidata und von dort zu GeoNames “springen”.

Problemstellung

Die Situation der Orte in den einzelnen Datenquellen unterscheidet sich teilweise stark. In der folgenden Tabelle sind einige zufällig ausgewählten Orte aus Baden-Württemberg gelistet, um das Problem zu verdeutlichen.

Datenquelle	Wohnplatz	Gemeinde (historisch)	Ortsteil (aktuell)	Gemeinde (aktuell)
Ort	Kaltenbach	Marlsburg	Marlsburg	Marlsburg-Marzell
GND	7824222-8	4422940-9		4422938-0
Wikidata	Q65183925			Q62032
Getty TGN	7153012		7141027
GeoNames	2893651		2874049	6555902
Wikipedia	Kaltenbach			Malsburg-Marzell
Ort	Luisenheim	Marzell	Marzell
GND	7818883-0	4422941-0
Wikidata
Getty TGN			7129879
GeoNames			2873068
Wikipedia
Ort		Altdorf	Ettenheim-Altdorf	Ettenheim
GND		4260757-7	10099367-9	4015632-1
Wikidata			Q47520099	Q506871
Getty TGN			7216262	1039035
GeoNames			2958031	6558103
Wikipedia			Altdorf	Ettenheim

Der Wohnplatz Kaltenbach kam schon 1823 zur Gemeinde Malsburg dazu, welche dann 1974 zur Doppelgemeinde Marlsburg-Marzell wurde. Dies ist in der GND auch entsprechend “abgebildet”. Was quasi fehlt, ist ein separater Eintrag für Marlsburg als heutigen Teilort von Marlsburg-Marzell. Dies ist in der Tabelle am Beispiel der ehemaligen Gemeinde Altdorf gezeigt, für die es in der GND sowohl für die historische Gemeinde, als auch für den heutigen Teilort separate Eintragungen gibt.

In Wikidata und Wikipedia gibt es nur Hinweise auf Kaltenbach und die aktuelle Doppelgemeinde Marlsburg-Marzell. Für die vorangegangenen Gemeinden Marlsburg und Marzell gibt es auf Wikipedia (noch) keine Einträge.

Dafür sind Marlsburg und Marzell sowohl bei Getty TGN, als auch bei GeoNames zu finden, wobei sich das eher auf die aktuellen Teilorte bezieht. Die aktuelle Doppelgemeinde Marlsburg-Marzell ist bei Getty TGN nicht zu finden, wobei das auch mit Problemen mit dem Bindestrich bei Suchanfragen zu tun haben kann, worauf wir später in diesem Tutorial nochmal zu sprechen kommen.

Luisenheim als im Vergleich zu Kaltenbach weniger bedeutender und zu Marzell zugehöriger Wohnplatz ist beispielsweise nur in der GND zu finden.

Was im Zuge des Reconciling also passieren kann ist, dass man historische Orte wie Altdorf verknüpft. Die Verknüpfung zu anderen Datenquellen wie GeoNames oder Wikidata aber am aktuellen Ortsteil Ettenheim-Altdorf hängt. Oder man umgekehrt den aktuellen Teilort verknüpft, die Informationen zu GeoNames oder Wikidata aber mit dem historischen Ort verknüpft sind.

Stuttgart	Wohnort	Stadtkreis	Regierungsbezirk
GND	4058282-6		4058287-5
Wikidata	Q1022		Q8172
Getty TGN	7004425	7077331	7075017
GeoNames	6690189	3220785	3214105
Wikipedia	Stuttgart		Regierungsbezirk

Ein anderes Problem ist teilweise die Unterscheidung zwischen Wohnort, Stadtkreis, Regierungsbezirk und teilweise sogar Bundesland (Stadtstaaten), die verwaltungstechnisch unterschiedliche Ebenen einnehmen, aber teilweise die exakt gleiche Fläche abdecken.

Hier wird in der GND und Wikidata zum Beispiel bei Stuttgart nicht zwischen Wohnort und Stadtkreis unterschieden, bei Getty TGN und GeoNames aber schon.

Dies sind nur ein paar exemplarische Beispiele, die neben Duplikaten, fehlenden Daten und unterschiedlichen Schreibweisen zu Problemen bei der Arbeit mit Normdaten für Orte und deren Eignung für das Nachladen von Geoinformationen führen.

Daten laden

Wir benötigen die folgenden Dateien als OpenRefine Projekt:

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

Orte

Ort	GND	Wikidata	Getty TGN	GeoNames	Wikipedia
Kaltenbach	7824222-8	Q65183925	7153012	2893651	https://de.wikipedia.org/wiki/Kaltenbach_(Malsburg-Marzell)
Luisenheim	7818883-0
Marlsburg	4422940-9		7141027	2874049
Marzell	4422941-0		7129879	2873068
Marlsburg-Marzell	4422938-0	Q62032		6555902	https://de.wikipedia.org/wiki/Malsburg-Marzell
Altdorf	4260757-7
Ettenheim-Altdorf	10099367-9	Q47520099	7216262	2958031	https://de.wikipedia.org/wiki/Altdorf_(Ettenheim)
Ettenheim	4015632-1	Q506871	1039035	6558103	https://de.wikipedia.org/wiki/Ettenheim
Stuttgart	4058282-6	Q1022	7004425	3214105	https://de.wikipedia.org/wiki/Stuttgart

Die oben besprochenen Orte gibt es, wie in der obigen Tabelle dargestellt, als CSV-Datei schon mit GND-ID, Wikidata QID, Getty TGN Identifikations-Nummer, GeoNames ID und Wikipedia Link. So können die einzelnen Schritte dieses Tutorials auch unabhängig voneinander durchgespielt werden.

Reconciliation Service API

Wie schon beschrieben, wird die Reconciliation Service API von OpenRefine direkt unterstützt, so dass es dafür entsprechende Komponenten in der Oberfläche von OpenRefine gibt. Über diese Komponenten können Daten mit Datenquellen abgeglichen werden, ohne dass dafür “programmiert” werden muss.

GND

Wie der Abgleich mit der lobid gnd API funktioniert, haben wir bereits in anderen Tutorials besprochen:

Prinzipiell sieht die GND Ontology ein Feld für Koordinaten vor, es gibt aktuell aber keinen Eintrag in der Linked-OpenData-Version der GND, wo diese Eigenschaft gesetzt ist. Die GND ist für Geokoordinaten trotzdem interessant, da die lobid gnd API sehr komfortabel zu benutzen ist und wir mit GND-IDs als Ausgangspunkt zu anderen Datenquellen “springen” können.

Dafür verwenden wir in unserem OpenRefine Projekt das Spaltenmenü “GND" "Reconcile" "Use values as identifiers…”. In dem Dialog wählen wir dann Service “GND reconciliation for OpenRefine”. Sollte der Service nicht in der Auswahl stehen, dann nochmal in 06 Reconciling mit OpenRefine und der GND nachlesen, wie man den Service hinzufügt.

Um basierend auf den Informationen in der GND Links zu anderen Datenquellen nachzuladen, verwenden wir wieder das Spaltenmenü “GND" "Edit column" "Add columns from reconciled values…” und suchen dort nach der Eigenschaft “Siehe auch”.

In der GND selbst sind eigentlich nur wenig Verlinkungen z.B. zu GeoNames gepflegt. Aber von der lobid GND Schnittstelle werden zusätzlich Rückverlinkungen z.B. von Wikidata auf die GND gesammelt und mit ausgeliefert.

Wir haben anschließend eine Record-Struktur, da es für einen Ort in der GND mehrere Verlinkungen zu anderen Datenquellen geben kann.

Mit einem Text Facet können wir die Datenquellen schnell identifizieren. Dafür Verwenden wir “Siehe auch" "Facet" "Custom text facet…” mit dem folgenden GREL-Ausdruck.

value.find(/https?:\/\/[^\/]+/)

Wie in dem Screenshot in Abbildung 1 zu sehen, haben wir unter anderem Verlinkungen zu Wikipedia, Wikidata und GeoNames. Die sind für uns interessant, da wir über diese höchstwahrscheinlich Geokoordinaten beziehen können.

Wie schon im Einleitungstext beschrieben, sind die Verlinkungen teilweise aber auch am vorherigen oder nachfolgenden Geografikum erstellt worden. Diese Orte können analog zu der Eigenschaft “Siehe auch” mit Vorheriges Geografikum und Nachfolgendes Geografikum nachgeladen werden. Je nach Organisationsstruktur lässt sich auch via Ort oder Administrative Überordnung des Geografikums ein passendes Geografikum mit Verlinkungen zu anderen Datenquellen nachladen.

Hier riskiert man es ungenauer zu werden. Nachfolgende oder übergeordnete Geographika tendieren dazu flächenmäßig deutlich größer zu sein, wodurch sich die Positionierung der Geokoordinaten im Vergleich zum eigentlich gemeinten Geografikum deutlich verschieben kann. Es kommt also auf den Anwendungsfall und die Dichte der beschriebenen Orte an.

Auf einer Europa-Karte wäre ein Geomarker für Kaltenbach mittig auf dem Gebiet von Marlsburg-Marzell weniger problematisch. Möchte man jedoch die einzelnen Teilorte von Marlsburg-Marzell unterscheiden, dann kann die Strategie des Nachladens von nachfolgenden bzw. übergeordneten Geografika zu Problemen führen.

Aus den Listen der Verlinkungen zu anderen Datenquellen lassen sich einzelne Spalten generieren. Das wird im Folgenden für Wikipedia, Wikidata und GeoNames gezeigt.

Wikipedia Url

Um eine Spalte mit den deutschsprachigen Wikipedia Urls zu erstellen gehen wir über das Spaltenmenü “Siehe auch" "Edit column" "Add column based on this column…” und verwenden in dem Dialog den folgenden GREL-Befehl.

if(value.contains("de.wikipedia.org"), value, "")

Wikidata QID

Um eine Spalte mit den Wikidata QIDs zu erstellen, gehen wir über das Spaltenmenü “Siehe auch" "Edit column" "Add column based on this column…” und verwenden in dem Dialog den folgenden GREL-Befehl.

if(value.contains("wikidata.org"), value.split("/")[-1], "")

GeoNames ID

Um eine Spalte mit den GeoNames IDs zu erstellen, gehen wir über das Spaltenmenü “Siehe auch" "Edit column" "Add column based on this column…” und verwenden in dem Dialog den folgenden GREL-Befehl.

if(value.contains("geonames.org"), value.split("/")[-1], "")

Wikidata

Wie der Abgleich mit der Wikidata Reconciliation Service API funktioniert, haben wir bereits in anderen Tutorials besprochen:

Um Daten von Wikidata nachladen zu können, verwenden wir in unserem Projekt das Spaltenmenü “Wikidata" "Reconcile" "Use values as identifiers…”. In dem Dialog wählen wir den Service “Wikidata reconci.link (de)”. Sollte der nicht in der Auswahl stehen, dann nochmal in 07 Reconciling mit OpenRefine und Wikidata nachlesen, wie man den Service hinzufügt. Eine Verwendung des deutschsprachigen Service hilft uns dabei, dass die Spaltennamen der erzeugten Spalten automatisch mit dem entsprechenden deutschsprachigen Bezeichnung versehen werden.

Von Wikidata aus können wir unterschiedlichste Informationen nachladen. Für uns interessant sind geographische Koordinaten (P625), sowie GeoNames-Kennung (P1566) und TGN-Kennung (P1667), falls für den Ort bei Wikidata keine Koordinaten hinterlegt sind.

Das Nachladen dieser Eigenschaften erfolgt wieder via “Wikidata" "Edit column" "Add columns from reconciled values…”.

Die geographischen Daten im WGS84 Format können wir anschließend in separate Spalten für den Breiten- und Längengrad aufteilen. Dafür verwenden wir das Spaltenmenü “geographische Koordinaten" "Edit column" "Split into several columns…” und verwenden im folgenden Dialog das Trennzeichen ,. Die erste Spalte beinhaltet dann die geographische Breite lat und die zweite Spalte die geographische Länge lng und sollten entsprechend umbenannt werden.

Getty TGN

Wie der Abgleich mit der Getty Reconciliation Service API funktioniert, haben wir bereits in einem anderen Tutorial besprochen:

17 Erweiterter Abgleich mit Getty

Haben wir IDs von Getty TGN, dann sollten wir diese zuerst noch umformatieren, um dem Getty Service mitzuteilen, dass es sich um IDs aus dem TGN Katalog handelt. Dafür verwenden wir das Spaltenmenü “Getty TGN" "Edit cells" "Transform…” mit dem folgenden GREL Ausdruck:

if(isNull(value), "", "tgn/" + value)

Anschließend können wir wie gewohnt die Spalte für das Reconciling vorbereiten “Getty TGN" "Reconcile" "Use values as identifiers…”. In dem Dialog wählen wir den Service “Getty Vocabularies Reconciliation Service”. Sollte der nicht in der Auswahl stehen, dann nochmal in 17 Erweiterter Abgleich mit Getty nachlesen, wie man den Service hinzufügt.

Anschließend können wir die Spalte “Coordinates” nachladen via “Getty TGN" "Edit column" "Add columns from reconciled values…”

Bei Getty ist sowohl die Reihenfolge als auch das Format anders als gewohnt.

[7.733333,47.75]

Um die Koordinaten in Breiten- und Längengrad aufzuspalten verwenden wir daher “Coordinates" "Edit column" "Add column based on this column…” mit den folgenden GREL Ausdrücken.

Für die geographische Breite (lat) verwenden wir den folgenden GREL Ausdruck.

parseJson(value)[1]

Für die geographische Länge (lng) verwenden wir den folgenden GREL Ausdruck.

parseJson(value)[0]

Allgemeine API

Neben der speziellen Reconciliation Service API gibt es auch allgemeine Programmierschnittstellen (engl. abgekürzt API) um mit Diensten im Internet zu kommunizieren. Das Abrufen von Daten (Fachsprache GET-Request) lässt sich in OpenRefine mit dem Dialog zum Hinzufügen von Spalten über URLs umsetzen.

Bildschirmfoto des Dialogs zum Nachladen von URLs für GeoNames.

Wie in Abbildung 2 gezeigt, lässt sich in dem Dialog pro Zeile im Projekt eine URL zusammenbasteln, deren Inhalte dann von OpenRefine angefragt werden. Die Anfragen lassen sich meistens komplett über die URL steuern, manche Optionen sollten jedoch auch als so genannte HTTP header gesetzt werden.

Bei kostenpflichtigen APIs ist das häufig ein Zugangsschlüssel für das Authorization Feld. Kostenlose Dienste bitten häufig darum z.B. die E-Mailadresse im Feld User-Agent mit anzugeben. So haben die Betreiber eine Möglichkeit mit euch in Kontakt zu treten, falls ihr unbewusst oder ungewollt gegen die Benutzungsregeln verstoßt. Die Alternative ist, dass die IP-Adresse von euch bzw. euem Arbeitgeber bei groben Regelverstößen direkt gesperrt wird.

Im Feld Throttle delay könnt ihr eine automatische Pause zwischen einzelnen Anfragen definieren, um den Dienst nicht mit zu vielen Anfragen nacheinander zu überlasten.

Als Ergebnis dieser Anfragen erhält man häufig Daten im so genannten JSON Format.

Exkursion zu JSON

Bei JSON handelt es sich um ein leichtgewichtiges Textformat für den Datenaustausch. Für diesen Workshop benötigen wir lediglich ein paar einfache Grundlagen von JSON.

Ein Objekt wird in JSON geschweifte Klammern eingefasst:

{
 // Hier sind alle Informationen für ein Objekt zusammengefasst
}

Informationen in Objekten bestehen aus Schlüssel-Werte-Paaren:

{
 "name": "Kaltenbach (Malsburg-Marzell)",
 "lat": 47.75388981,
 "lon": 7.72699657
}

Informationen können geschachtelt werden:

{
 "name": "Kaltenbach (Malsburg-Marzell)",
 "coordinates": {
 "lat": 47.75388981,
 "lon": 7.72699657
 }
}

Informationen können mit eckigen Klammern in Listen gespeichert werden:

{
 "name": "Kaltenbach (Malsburg-Marzell)",
 "coordinates": [47.75388981, 7.72699657]
}

Wikipedia API

Je nach Projekt kann es sein, dass man eine Liste von Wikipedia URLs hat, für die man Normdaten nachladen möchte. Für Orte gibt es in Wikipedia auch direkt Geodaten, die man ebenfalls auslesen kann.

Wikipedia hat eine eigene API, welche unter Wikimedia REST API mit der OpenAPI Spezifikation dokumentiert wird. In der OpenAPI Spezifikation der Wikimedia REST API gibt es auch nochmal Hinweise auf die Benutzungsregeln, also z.B. dass doch bitte, wie weiter oben beschrieben, identifizierbare User-Agents verwendet werden.

Die API Dokumentation ist interaktiv, so dass Anfragen zu den einzelnen Endpunkten direkt ausprobiert und getestet werden können.

Um die Wikidata QID oder die Geokoordinaten zu einer Wikipedia Seite auszulesen, bietet sich der Endpunkt für die Seitenzusammenfassung an.

Bildschirmfoto der interaktiven OpenAPI Dokumentation der Wikimedia REST API.

In Abbildung 3 ist das Ergebnis einer interaktiven Anfrage für die Wikipedia Seite für Kaltenbach gezeigt. Über der Anzeige der Rückgabedaten (Response) gibt es auch die Request URL, die wir in OpenRefine direkt weiterverwenden können.

Um die Daten zeilenweise mit OpenRefine über die Wikimedia REST API zu laden, filtern wir zuerst die Zeilen, die eine Wikipedia URL haben über via “Wikipedia" "Facet" "Customized facets" "Facet by blank (null or empty string)…”.

Anschließend verwenden wir das Spaltenmenü “Wikipedia" "Facet" "Customized facets" "Facet by blank (null or empty string)…” und erstellen eine neu Spalte “Wikipedia JSON” mit dem folgenden GREL Ausdruck (User-Agent… nicht vergessen).

"https://de.wikipedia.org/api/rest_v1/page/summary/"+escape(value.split("/")[-1], "url")+"?redirect=true"

Der GREL Ausdruck nimmt den letzten Teil der Wikipedia URL und setzt ihn als Titel an die entsprechende Stelle in der API Anfrage. Dabei verwenden wir eine URL spezifische Umwandlung von Sonderzeichen.

Als Resultat erhalten wir in jeder Zeile eine Antwort im so genannten JSON Format, welches hier gekürzt dargestellt wird.

{
 "type": "standard",
 "title": "Kaltenbach (Malsburg-Marzell)",
 "wikibase_item": "Q65183925",
 "lang": "de",
 "coordinates": {
 "lat": 47.75388981,
 "lon": 7.72699657
 },
 "extract": "Kaltenbach ist ein Wohnplatz auf 730 m ü. NN, der zur Gemeinde Malsburg-Marzell im Landkreis Lörrach gehört. Die Gemarkungsfläche umfasst 450 Hektar.",
 ...
}

Da wir nur relativ wenig Datenpunkte aus dem JSON extrahieren wollen, machen wir das spaltenweise über “Wikipedia JSON" "Edit column" "Add column based on this column…”.

Für die geographische Breite (lat) benötigen wir den folgenden GREL Ausdruck.

parseJson(value)["coordinates"]["lat"]

Für die geographische Breite (lng) benötigen wir den folgenden GREL Ausdruck.

parseJson(value)["coordinates"]["lon"]

Für die Wikidata QID benötigen wir den folgenden GREL Ausdruck.

parseJson(value)["wikibase_item"]

GeoNames API

Für GeoNames gibt es anders als für die Wikimedia REST API (noch) keine OpenAPI Spezifikation. Hier beschränken wir uns darauf basierend auf der GeoNames ID die zugehörigen Geokoordinaten von dem Service abzurufen. Hierfür benötigen wir einen Account bei GeoNames, da der Benutzername ein Bestandteil der Anfrage ist.

Zuerst filtern wir Zeilen mit GeoNames IDs via “GeoNames" "Facet" "Customized facets" "Facet by blank (null or empty string)…” . Anschließend fügend wir eine neue Spalte hinzu via “GeoNames" "Edit column" "Add column by fetching URLs…” , die wir “GeoNames JSON” nennen.

In dem GREL Ausdruck für die URL setzen wir dann die GeoNames ID an die vorgesehene Stelle ein. Diese brauchen wir nicht explizit für URLs aufzubereiten, da sie nur aus Zahlen besteht.

Nicht vergessen den Parameter USERNAME mit dem eigenen Benutzernamen zu ersetzen.

"http://api.geonames.org/getJSON?formatted=true&geonameId="+value+"&username=USERNAME&style=short"

Die JSON kodierte Antwort sieht gekürzt und umsortiert dann etwa wie folgt aus.

{
 "bbox": {
 "east": 7.737455174771594,
 "south": 47.74660464350438,
 "north": 47.76459194100723,
 "west": 7.710695459994031,
 "accuracyLevel": 0
 },
 "lat": "47.7556",
 "lng": "7.72408",
 "name": "Kaltenbach",
 "adminName4": "Malsburg-Marzell",
 "adminName3": "Landkreis Lörrach",
 "adminName2": "Freiburg Region",
 "adminName1": "Baden-Wurttemberg",
 "countryName": "Germany",
 "continentCode": "EU",
 ...
}

Neben dem Längen- und Breitengrad erhalten wir zusätzlich auch ein minimal umgebendes Rechteck (engl. “bounding box”) und weitere Informationen zu dem angefragten Ort.

Um die Längen- und Breitengrade in separate Spalten zu überführen, verwenden wir wieder das Spaltenmenü “GeoNames JSON" "Edit column" "Add column based on this column…”.

Für die geographische Breite (lat) benötigen wir den folgenden GREL Ausdruck.

parseJson(value)["lat"]

Für die geographische Breite (lng) benötigen wir den folgenden GREL Ausdruck.

parseJson(value)["lng"]

GeoNames bietet noch deutlich mehr WebServices an um zum Beispiel Orte via Postleitzahlen oder Geokoordinaten zu finden. Es sind jedoch nicht alle Services kostenfrei, es stehen teilweise Daten nur für einzelne Länder zur Verfügung und teilweise sind die Services auch nur aus den USA nutzbar.

OpenStreetMap API

Das Projekt OpenStreetMap sammelt mit Freiwilligen weltweit Geoinformationen, die unter freien Lizenzen weitergenutzt werden können. Hierfür gibt es unterschiedliche APIs um auf die Daten zuzugreifen.

Zwei dieser APIs verwenden wir in diesem Tutorial, um Geokoordinaten für Orte abzurufen, ohne sie davor mit Normdaten abzugleichen.

Da OpenStreetMap teilweise sehr genaue Daten hat, können wir darüber auch deutlich genauere Geokoordinaten z.B. auf Gebäude- oder Straßenebene abrufen. Das sind Informationen, die aus Relevanzgründen in den bisher besprochenen Datenquellen nicht erfasst sind.

Die Arbeit mit den Ergebnissen dieser Suchdienste in OpenRefine ist jedoch nicht ganz so komfortabel, wie mit der Reconciliation Service API.

Photon

Photon ist ein Service von der Outdoor-Routenplanung-Plattform Komoot. Der Service wird als OpenSource Projekt auf GitHub zur Verfügung gestellt. Das bedeutet, dass man sowohl die öffentliche API unter Photon nutzen, als auch diesen Dienst intern selbst betreiben kann. Das ist gerade für größere Projekte interessant, bei denen es schwer fällt die fair use Bedingungen von öffentlichen APIs einzuhalten.

Die Datenbasis ist hier die gleiche, wie für die Nominatim Schnittstelle, die wir uns im nächsten Abschnitt ansehen.

In Photon können wir die Daten semi-strukturiert eingeben und auf Basis von Layern einschränken. Dafür laden wir die Daten zeilenweise via “Ort" "Edit column" "Add column by fetching URLs…” in die neue Spalte “Photon JSON” mit dem folgenden GREL Ausdruck.

"https://photon.komoot.io/api?q="+escape(value+", Baden-Württemberg", "url")+"&layer=city&layer=district&lang=de&limit=3"

Zusätzlich zum Ortsnamen (value) ergänzen wir noch den Begriff “Baden-Württemberg”, um die Suchergebnisse besser einzuschränken. Hier könnten wir auch noch mehr Daten einbinden, wie Landkreise usw., wenn wir diese Daten denn vorliegen haben.

Die Rückgabedaten erhalten wir wieder im JSON Format, wie im folgenden Beispiel verkürzt dargestellt.

{
 "features":[
 {
 "geometry":{
 "coordinates":[
 8.239959,
 48.7610716
 ],
 "type":"Point"
 },
 "type":"Feature",
 "properties":{
 "name":"Baden-Baden",
 "state":"Baden-Württemberg",
 "country":"Deutschland",
 "type":"city",
 ...
 }
 },
 {
 "geometry":{
 "coordinates":[
 7.7255337,
 47.7549089
 ],
 "type":"Point"
 },
 "type":"Feature",
 "properties":{
 "name":"Kaltenbach",
 "city":"Malsburg-Marzell",
 "county":"Landkreis Lörrach",
 "state":"Baden-Württemberg",
 "country":"Deutschland",
 "type":"district",
 ...
 }
 },
 ...
 ],
 "type":"FeatureCollection"
}

Anders als bei dem Beispiel mit GeoNames erhalten wir mehrere Ergebnisse, wo wir uns zuerst noch für das passende Ergebnis entscheiden sollten. Dafür nutzen wir das erworbene Wissen aus 10 Arbeiten mit Records, so dass jedes Ergebnis in einer eigenen Zeile steht. Das funktioniert über das Spaltenmenü “Photon JSON" "Edit cells" "Transform…” mit dem folgenden GREL Ausdruck.

forEach(parseJson(value)["features"],v, v).join("||")

Anschließend erzeugen wir die Record-Struktur über “Photon JSON" "Edit cells" "Split multi-valued cells…” mit dem Trennzeichen ||.

Um die Ergebnisse im JSON Format besser lesbar zu machen, formatieren wir die Spalte noch via “Photon JSON" "Edit cells" "Transform…” und verwenden diesmal Python anstatt GREL um das JSON lesbar zu formatieren.

import json
return json.dumps(json.loads(value), indent=4)

Jetzt können wir die einzelnen Zeilen mit den passenden Ergebnissen zum Beispiel mit Sternchen markieren und anschließend filtern. Wir können uns bei der Auswahl aber auch von OpenRefine etwas helfen lassen.

Zum Beispiel können wir via “Photon JSON" "Edit column" "Add column based on this column…”. eine neue Spalte mit dem Namen “Photon Match” hinzufügen.

Im GREL Ausdruck greifen wir auf Funktionen zurück, die wir auch im Teil zu Clustering mit OpenRefine besprochen haben. Hier vergleichen wir konkret den Namen des Ortes mit der Eigenschaft name in JSON, mit den Methoden Cologne Phonetic und Fingerprint. Sollte der Vergleich einer der beiden Methoden übereinstimmen, wird true in der neuen Spalte gespeichert. Das können wir dann wieder zum Filtern von (möglicherweise) passenden Ergebnissen nutzen.

with(row.record.cells["Ort"][0].value, ort,
 with(parseJson(value)["properties"]["name"], json_name,
 or(
 phonetic(ort, "cologne") == phonetic(json_name, "cologne"),
 fingerprint(ort) == fingerprint(json_name))))

Die Geokoordinaten selbst extrahieren wir wieder über das Spaltenmenü “Photon JSON" "Edit column" "Add column based on this column…”.

Für die geographische Breite (lat) benötigen wir den folgenden GREL Ausdruck.

parseJson[value]["geometry"]["coordinates"](1)

Für die geographische Breite (lng) benötigen wir den folgenden GREL Ausdruck.

parseJson[value]["geometry"]["coordinates"](0)

Generell ist die Photon API durch die relativ freie Textsuche recht einfach zu benutzen. Es gibt aber auch schnell Falsch-Positive, weil z.B. der zusätzliche Suchbegriff “Baden-Württemberg” zu einem hohen Ranking der Orte “Baden-Baden” und “Badenweiler” führt.

Nominatim

Nominatim ist die offizielle OpenSource Suchmaschine zur Arbeit mit Daten in OpenStreetMap. Für unseren Anwendungsfall verwenden wir den Search Endpunkt der Nominatim API. Im Gegensatz zu der recht einfach gehaltenen Photon API, können wir die Daten bei Nominatim auch strukturiert übermitteln. Außerdem kann zwischen verschiedenen Rückgabeformaten gewählt werden.

Wir laden die Daten zeilenweise via “Ort" "Edit column" "Add column by fetching URLs…” in die neue Spalte “Nominatim JSON” mit dem folgenden GREL Ausdruck.

"https://nominatim.openstreetmap.org/search?city="+escape(value, "url")+"&state="+escape("Baden-Württemberg", "url")+"&countrycodes=de&featureType=city,settlement&format=jsonv2&limit=3&email=YOUR_MAIL_ADDRESS"

Hier nicht vergessen am Ende den Platzhalter durch die eigene E-Mailadresse zu ersetzen.

Das im folgenden gezeigte und gekürzte Ergebnis ist etwas weniger strukturiert wie das von Photon, was die Aufarbeitung jedoch vereinfacht.

[
 {
 "name":"Kaltenbach",
 "display_name":"Kaltenbach, Malsburg-Marzell, Verwaltungsgemeinschaft Kandern, Landkreis Lörrach, Baden-Württemberg, 79429, Deutschland",
 "type":"village",
 "lat":"47.7549089",
 "lon":"7.7255337",
 "licence":"Data © OpenStreetMap contributors, ODbL 1.0. http://osm.org/copyright",
 ...
 },
 {
 "name":"Kaltenbach",
 "display_name":"Kaltenbach, Forbach, Landkreis Rastatt, Baden-Württemberg, Deutschland",
 "type":"isolated_dwelling",
 "lat":"48.6319441",
 "lon":"8.357038733877207",
 "licence":"Data © OpenStreetMap contributors, ODbL 1.0. http://osm.org/copyright",
 ...
 },
 ...
]

Wie bei der Arbeit mit den Ergebnissen von Photon arbeiten wir wieder mit Records, so dass jedes Ergebnis in einer eigenen Zeile steht. Das funktioniert über das Spaltenmenü “Nominatim JSON" "Edit cells" "Transform…” mit dem folgenden GREL Ausdruck.

forEach(parseJson(value),v, v).join("||")

Anschließend erzeugen wir die Record-Struktur über “Nominatim JSON" "Edit cells" "Split multi-valued cells…” mit dem Trennzeichen ||.

Um die Ergebnisse im JSON Format besser lesbar zu machen, formatieren wir die Spalte wieder via “Nominatim JSON" "Edit cells" "Transform…” und verwenden wieder Python anstatt GREL um das JSON lesbar zu formatieren.

import json
return json.dumps(json.loads(value), indent=4)

Nachdem wir die passenden Ergebnisse ausgewählt und gefiltert haben, extrahieren wir die Geokoordinaten wieder über das Spaltenmenü “Nominatim JSON" "Edit column" "Add column based on this column…”.

Für die geographische Breite (lat) benötigen wir den folgenden GREL Ausdruck.

parseJson[value]("lat")

Für die geographische Breite (lng) benötigen wir den folgenden GREL Ausdruck.

parseJson[value]("lon")

Hat man die Daten schon einigermaßen strukturiert vorliegen, dann liefert die Nominatim API in unseren Experimenten passendere Ergebnisse als Photon. Wir haben hier aber auch nur einen kleinen Teil der API getestet und genutzt.

Fazit

Arbeitet man sowieso mit Normdaten, so lassen sich je nach Datenlage Geokoordinaten mit OpenRefine aus der genutzten oder einer verknüpften Normdatenquelle über die Reconciliation Service API nachladen. In einigen Fällen kann man die Ergebnisse mit einfachen API Anfragen an Wikipedia oder GeoNames vervollständigen.

Möchte man genauere Geokoordinaten zum Beispiel auf Adressebene, dann lohnt sich ein Blick auf die OpenStreepMap APIs.

Es gibt noch viele andere Geocoding APIs von hauptsächlich kommerziellen Anbietern mit einem bestimmten Freikontingent an Anfragen. Diese können mit OpenRefine ähnlich genutzt werden, wie bei den OpenStreetMap APIs beschrieben.

Ein ähnliches Projekt zur Arbeit mit OpenRefine und WebAPIs haben wir bei Entfernungen zu GPX Tracks mit OpenRefine ermitteln dokumentiert.

Lizenzhinweise

Dieser Artikel und die Bildschirmfotos enthalten Informationen aus der GeoNames geographische Datenbank, welche verfügbar ist unter der CC BY 4.0 Lizenz.

Dieser Artikel und die Bildschirmfotos enthalten Informationen aus OpenStreetMap, welche verfügbar sind unter der ODbL 1.0.

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.

Dieser Artikel und die Bildschirmfotos enthalten Informationen aus Wikipedia, welche verfügbar sind unter der CC BY SA 4.0 Lizenz.

Im nächsten Teil beschäftigen wir uns mit dem erweiterten Möglichkeiten zum Clustering mit OpenRefine.

19 Erweitertes Clustering

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

Entfernungen zu GPX Tracks mit OpenRefine ermitteln

Thu, 27 Oct 2022 00:00:00 +0000

In diesem Beitrag verarbeiten wir XML in Form von GPX-Dateien mit OpenRefine und berechnen via WebAPIs die Entfernung von unserem Standort zu dem Startpunkt der GPX-Tracks.

Aktuelle Wanderführer bieten die darin beschriebenen Wanderungen häufig zusätzlich als GPX-Datei zum Nachwandern als Download an. Auch Tourismusbüros/verbände/gemeinschaften/… bieten in Kooperation mit Diensten wie OutdoorActive lokale Wanderungen digital an. Planen wir einen Betriebsausflug, oder eine Wanderung, dann ist die Länge der Anfahrt zum jeweiligen Startpunkt durchaus ein wesentliches Entscheidungskriterium für oder gegen eine Wanderung. Anstatt manueller Einzelrecherchen testen wir in diesem Beitrag, wie sich mit OpenRefine die Entfernung und Fahrtdauer mit dem Auto bzw. dem öffentlichen Nahverkehr von unserem Standort zu den Startpunkten der einzelnen Wanderungen berechnen lässt.

Dabei kombinieren wir OpenRefine mit Geodaten im XML basierten GPX-Format und fragen mit den extrahierten Daten verschiedene WebAPIs an.

Unsere Testdaten

Als Testdaten verwenden wir die aktuell 21 Wanderungen aus dem Programm der hochgehberge. Diese lassen sich direkt von der Webseite als GPX-Datei einzeln herunterladen. Dafür muss nach Auswahl einer Tour etwas nach oben gescrollt werden. Wie in Abbildung 1 gezeigt, aktivieren wir zusätzlich die Checkbox bei “Verknüpfte Wegpunkte exportieren”. Das ermöglicht uns bei den Daten der “hochgehberge” nicht nur einen Abgleich mit dem Startpunkt der Wanderungen durchzuführen, sondern auch mit alternativen Parkplätzen, die sich als Einstieg zur Tour eignen.

Bildschirmfoto der Webseite hochgehberge.de mit GPX-Download.

Routing APIs

Wir verwenden für unseren Test die WebAPIs von Google Maps, HERE und OpenRouteService. Für all diese Dienste benötigen wir einen Account und müssen einen API Schlüssel erstellen, um mit OpenRefine eine Anfrage stellen zu können. Alle Dienste haben ein “freies” Kontingent, welches für unsere Anwendung vollkommen ausreichend ist. Im Falle von Google Maps ist jedoch eine Kreditkarte notwendig, um den Dienst aktivieren zu können.

Da das Warten auf die Bestätigungs-E-Mail manchmal mehrere Minuten dauert, lohnt es sich die Registrierung schon jetzt durchzuführen. Wie das funktioniert und wie bei den einzelnen Diensten API Schlüssel erstellt wird, ist in der jeweiligen Dokumentation deutlich besser und umfangreicher beschrieben, als wir es hier können.

Daten importieren und aufarbeiten

Daten in OpenRefine importieren

Bei vielen Dateien oder verschachtelten Strukturen mit Unterordnern empfiehlt es sich, diese in eine ZIP-Datei zu packen, was das Laden in OpenRefine vereinfacht. Wie in Abbildung 2 gezeigt, kann eine ZIP-Datei direkt als Datenquelle für ein neues Projekt ausgewählt werden.

Bildschirmfoto der Dateiauswahl für neue Projekte in OpenRefine.

Wie in Abbildung 3 gezeigt, werden die einzelnen Dateien vor dem Import aus den Unterordnern geladen, und können in einem separaten Dialog nach Dateityp gefiltert werden. Auch eine Filterung basierend auf Mustern im Dateinamen ist möglich.

Bildschirmfoto des Dialogs zum Filtern von Dateien in OpenRefine.

Im XML-Import-Dialog wählen wir anschließend das GPX-Wurzelelement aus und erhalten die in Abbildung 4 gezeigten Daten in OpenRefine angezeigt.

Bildschirmfoto der importierten GPX Dateien in OpenRefine.

Überflüssige Spalten entfernen

In Standard GPX-Tracks würden wir hier einfach den ersten Punkt des GPX-Tracks verwenden und den Rest verwerfen. Da wir in den GPS-Daten der “hochgehberge” aber pro Tour teilweise mehrere mögliche Parkplätze zum Starten als Wegpunkte hinterlegt haben, machen wir den Abgleich hier über die Wegpunkte und verwerfen die Track-Daten.

Wie in Abbildung 5 gezeigt, entfernen wir dafür überflüssige Spalten via “All" "Edit columns" "Re-order / remove columns…”.

Bildschirmfoto des Dialogs zum Löschen und Sortieren von Spalten in OpenRefine.

Die folgenden Spalten behalten wir vorläufig:

File => als Record Identifier, also Zuordnung von Startpunkten zu einzelnen Touren.
WPT lon, lat => Zur Routenplanung via API.
WPT Name + Type => zum Filtern von Startpunkten (Parkplätzen).
WPT DESC + Link => ggf. zur weiteren Recherche hilfreich.
Metadata Name + Link => Information über Wanderung.

Spalten umbenennen

Um auf die Werte einfacher zugreifen zu können, benennen wir die restlichen Spalten passend nach folgendem Schema um:

gpx - wpt - lon Lon
gpx - wpt - lat Lat
gpx - wpt - name Wegpunkt Name
gpx - wpt - type Wegpunkt Typ
gpx - wpt - desc Wegpunkt Beschreibung
gpx - wpt - link-href Wegpunkt Link
gpx -metadata - name Name
gpx - metadata - link - href Link

Spalten sortieren

Nachdem wir geprüft haben, dass die Spalte “Name” für jeden GPS-Track eindeutig ist (Text Facet oder Duplicates Facet), löschen wir die Spalte “File” und verschieben die Spalte “Name” ganz nach links. Dadurch wird der “Name” zum neuen Record Identifier der einzelnen Wanderungen. Ordnungsliebend verschieben wir die Spalte “Link” direkt daneben auf die zweite Position. Das geht in einem Bearbeitungsschritt über den Dialog zum Löschen und Umsortieren mehrerer Spalten via “All" "Edit columns" "Re-order / remove columns…”.

Überflüssige Zeilen entfernen

Wir haben in den Daten einige Leerzeilen, da wir die Spalten zu den einzelnen Trackpunkten gelöscht haben. Außerdem haben wir einige Wegpunkte, die wir ebenfalls noch löschen wollen, da wir uns auf die Parkplätze konzentrieren wollen.

Dies machen wir in vier Schritten:

Werte in Spalte “Name” nach unten auffüllen via “Name" "Edit cells" "Fill down”.
Werte in Spalte “Link” nach unten auffüllen via “Link" "Edit cells" "Fill down”.
Wie in Abbildung 6, ein Text Facet auf der Spalte “Wegpunkt Typ” erstellen, dort die Wegpunkte vom Typ “Parkplatz” auswählen, und die Auswahl invertieren.
Die überflüssigen Zeilen entfernen via “All" "Edit rows" "Remove matching rows”.

Bildschirmfoto des Text Facets zum Filtern von Wegpunkten in OpenRefine.

Nochmal überflüssige Spalten entfernen

Bei den Parkplätzen sind die Spalten “Wegpunkt Link” und “Wegpunkt Beschreibung” nicht mit hilfreichen Informationen versehen, so dass wir sie löschen können.

Auf Duplikate prüfen

Der Vollständigkeit halber prüfen wir mit dem “Duplicates Facet” oder dem “Text Facet” die Spalte “Wegpunkt” auf mögliche Duplikate und löschen diese. Dafür die entsprechenden Zeilen zum Beispiel mit Flaggen markieren, via “Flag Facet” filtern und anschließend löschen.

Records erstellen

Um wieder eine Record Struktur zu erstellen, bei der es zu jeder Tour mehrere mögliche Parkplätze als Startpunkte gibt, machen wir das “Fill down” auf den Spalten “Name” und “Link” aus dem vorherigen Schritt wieder rückgängig, indem wir analog dazu auf beiden Spalten “Name|Link" "Edit cells" "Blank down” verwenden.

Die fertig gefilterten Daten sind in Abbildung 7 zu sehen.

Bildschirmfoto der gefilterten Daten in OpenRefine.

Startkoordinaten suchen

Für einen Abgleich via WebAPI benötigen wir noch die Startkoordinaten. Der Einfachheit halber kopieren wir diese von Google Maps und fügen sie als neue Spalten “Start Lon” und “Start Lat” dem Projekt hinzu (wir starten von unserer Zentrale in der Eugenstraße 7 in Stuttgart). Um Geokoordinaten von Google Maps zu kopieren klicken wir mit dem rechten Maustaste auf den gesuchten Punkt oder den Marker auf der Karte. Wie in Abbildung 8 gezeigt, erscheint anschließend ein Kontextmenü, wo die Geokoordinaten mit einem Linksklick direkt in die Zwischenablage übernommen werden können. Der erste Wert stellt den Breitengrad (Latidude) dar, der zweite den Längengrad (Longitude).

Bildschirmfoto des Kontextmenüs in Google Maps zum Kopieren von Geokoordinaten.

Wegstrecke mit WebAPIs ermitteln

Nun haben wir alle Daten für unseren Datenabgleich zusammen. In Abbildung 9 sind diese noch einmal abgebildet, wobei wir zur Übersichtlichkeit die ersten beiden Spalten ausgeblendet haben. Im nächsten Schritt berechnen wir die Entfernung zwischen unserem Standort und den möglichen Startpunkten der einzelnen Wanderungen.

Bildschirmfoto des aufbereiteten Projektes in OpenRefine.

Um die Daten von einer WebAPI abzurufen, verwenden wir so genannte GET-Requests (siehe HTTP-Anfragemethoden auf Wikipedia). Das hat den Vorteil, dass wir die Daten direkt mit der OpenRefine Funktion des Hinzufügens neuer Spalten via URL abfragen können.

Bei der (prinzipiell) für diese Art von Anfragen empfohlene POST-Request Methode, müssten wir zusätzlich in OpenRefine mit Clojure oder Python programmieren, was wir aus Gründen der Komplexität für dieses Experiment vermeiden möchten.

Verwendung von HERE

Bei HERE handelt es sich um ein ehemaliges Berliner Startup, welches mehrfach verkauft wurde und inzwischen hauptsächlich aus dem Automotive Bereich bekannt ist.

Für die Verwendung der HERE Routing API benötigen wir einen Account und einen API Schlüssel. Die Benutzung der API ist in der Entwickler Dokumentation beschrieben.

Daten abrufen

In Abbildung 10 ist der Dialog zum Hinzufügen neuer Spalten via URLs gezeigt. Diesen können wir aufrufen via “Beliebige Spalte" "Edit columns" "Add column by fetching URLs…”.

Bildschirmfoto des Dialogs zum Abfragen der HERE Routing API mit OpenRefine.

Die neue Spalte nennen wir “HERE” und die URL bauen wir für jede Zeile dynamisch zusammen:

"https://router.hereapi.com/v8/routes?transportMode=car&origin="+row.cells["Start Lat"].value +","+row.cells["Start Lon"].value+"&destination="+row.cells["Lat"].value +","+row.cells["Lon"].value+"&return=summary&apikey={YOUR_API_KEY}"

Wir geben in dieser Anfrage an, dass wir die Route für ein Auto planen möchten und laden die Start- und Zielkoordinaten aus den entsprechenden OpenRefine Spalten. Hier ist der Platzhalter {YOUR_API_KEY} durch einen eigenen API Key zu ersetzen.

Bei HERE haben wir zusätzlich die Möglichkeit, lediglich die Zusammenfassung zurückgeben zu lassen und damit auf die expliziten Einzelschrittanweisungen für die Route zu verzichten.

Das Vorhandensein des API Schlüssels direkt in der URL ist aus Sicherheitsaspekten eher unschön, weshalb hierfür generell andere Methoden empfohlen werden (POST, Header, OAuth). Für unser kleines bzw. einmaliges Experiment ist dieses Vorgehen aus Gründen der Einfachheit vorzuziehen. Wir können die API Schlüssel nach dem Experiment direkt wieder deaktivieren bzw. löschen.

Daten aufbereiten

Die Antwort der HERE Routing API erfolgt im JSON Format. In OpenRefine ist das JSON nicht menschenlesbar formatiert, so dass wir es mit dem Online Service JSON formatter menschenlesbar formatieren.

{
 "routes": [
 {
 "id": "5dae984c-da74-4bf3-b126-a4b8f44f35f7",
 "sections": [
 {
 "id": "ff1eaf83-4cae-498e-b0f0-b2fe68227106",
 "type": "vehicle",
 "departure": {
 "time": "2022-10-24T11:10:38+02:00",
 "place": {
 "type": "place",
 "location": {
 "lat": 48.7789779,
 "lng": 9.1864948
 },
 "originalLocation": {
 "lat": 48.7792369,
 "lng": 9.186687
 }
 }
 },
 "arrival": {
 "time": "2022-10-24T12:17:31+02:00",
 "place": {
 "type": "place",
 "location": {
 "lat": 48.389022,
 "lng": 9.3690754
 },
 "originalLocation": {
 "lat": 48.388977,
 "lng": 9.369079
 }
 }
 },
 "summary": {
 "duration": 4013,
 "length": 62748,
 "baseDuration": 3617
 },
 "transport": {
 "mode": "car"
 }
 }
 ]
 }
 ]
}

Die für uns interessanten Daten sind im Bereich summary zu finden. Unter length finden wir die Entfernung in Metern und unter baseDuration die von der aktuellen Verkehrssituation unabhängige und daher optimistisch berechnete Fahrtdauer in Sekunden. Weitere Informationen zu unterschiedlichen Angaben zur Fahrdauer und wie sie angefragt werden können, sind in der Entwickler Dokumentation zu finden.

Das Routing via öffentlichem Nahverkehr befand sich zum Zeitpunkt der Durchführung dieses Experimentes im Beta Stadium und wurde daher nicht getestet.

Um aus dem JSON die für uns relevanten Daten in OpenRefine Spalten zu überführen, nutzen wir die Funktion “HERE" "Edit columns" "Add column based on this column…”.

Die erste neue Spalte nennen wir “HERE Entfernung” und verwenden den folgenden GREL Ausdruck zur Extraktion und Umwandlung der Entfernung in Kilometern:

(value.parseJson().routes[0].sections[0].summary.length/1000).round()

Die zweite neue Spalte nennen wir “HERE Dauer” und verwenden den folgenden GREL Ausdruck zur Extraktion und Umwandlung der Dauer in Minuten:

(value.parseJson().routes[0].sections[0].summary.baseDuration/60)

Verwendung von OpenRouteService

Bei OpenRouteService handelt es sich um einen OpenSource Geodatendienst, welcher auf Daten von OpenStreepMaps basiert. Die Anmeldung und die Verwendung ist sehr einfach gehalten. Entsprechend ist auch die API im Vergleich zu den hier verwendeten kommerziellen Diensten nicht ganz so umfangreich. Die Verwendung der API zur Berechnung von Routen ist in der Entwickler Dokumentation beschrieben.

Daten abrufen

Das Vorgehen zur Abfrage einer WebAPI via GET-Requests haben wir schon bei der Verwendung der HERE Routing API beschrieben.

Wir laden die Daten in eine neue Spalte namens “OpenRouteService”. Der GREL Code zum dynamischen Erstellen der URLs für die einzelnen Zeilen sieht wie folgt aus:

"https://api.openrouteservice.org/v2/directions/driving-car?start="+row.cells["Start Lon"].value +","+row.cells["Start Lat"].value+"&end="+row.cells["Lon"].value +","+row.cells["Lat"].value+"&api_key={YOUR_API_KEY}"

Daten aufbereiten

Die JSON Antwort von OpenRouteService besteht aus mehreren tausend Elementen im JSON Format, da wir hier zusätzlich die komplette Route mitgeschickt bekommen. Die für uns interessanten Daten finden wir wieder im Element summary. Die Entfernung ist wieder in Metern und die Dauer in Sekunden angeben.

{
 ...
 "summary": {
 "distance": 62204.3,
 "duration": 3993.7
 }
 ...
}

Um aus dem JSON die für uns relevanten Daten in OpenRefine Spalten zu überführen, nutzen wir die Funktion “OpenRouteService" "Edit columns" "Add column based on this column…”.

Die erste neue Spalte nennen wir “ORS Entfernung” und verwenden den folgenden GREL Ausdruck zur Extraktion und Umwandlung der Entfernung in Kilometern:

(value.parseJson().features[0].properties.summary.distance/1000).round()

Die zweite neue Spalte nennen wir “ORS Dauer” und verwenden den folgenden GREL Ausdruck zur Extraktion und Umwandlung der Dauer in Minuten:

(value.parseJson().features[0].properties.summary.duration/60).round()

Verwendung von Google Maps

Google hat bei den hier verwendeten Webdiensten das weitaus umfangreichste API Angebot. Der Account Setup ist hier jedoch im Vergleich auch etwas aufwendiger.

Wir verwenden die Directions API von Google Maps. Es gibt zwar auch eine neuere Routes API, die derzeit in einer Vorschau-Version zur Verfügung steht. Diese bietet jedoch zum Zeitpunkt dieses Experiments (noch?) keine GET-Requests oder Routing via ÖPNV an.

Daten abrufen

Über die Directions API von Google Maps lassen sich auch Routen mit dem öffentlichen Nahverkehr planen. Daher fokussieren wir uns bei diesem Dienst auf diese Funktionalität.

Da Ausflüge wie Wanderungen häufig an Sonntagen stattfinden, dort jedoch der öffentliche Nahverkehr anders getaktet ist als unter der Woche, geben wir bei dieser Abfrage zusätzlich unsere gewünschte Ankunftszeit an (Sonntag, 31. Oktober 2022 um 10:00 Uhr). Die Zeitangaben werden in “Sekunden seit dem 1. Januar 1970” angegeben. In OpenRefine berechnen wir das mit dem folgenden GREL Ausdruck:

"2022-10-31 10:00".toDate("yyyy-MM-dd HH:mm").datePart("time")/1000

Hier eingefügt in den GREL-Code zur dynamischen Erstellung von URLs für das Hinzufügen neuer Spalten via URLs für OpenRefine:

"https://maps.googleapis.com/maps/api/directions/json?origin="+row.cells["Start Lat"].value +","+row.cells["Start Lon"].value+"&destination="+row.cells["Lat"].value +","+row.cells["Lon"].value+"&mode=transit&arrival_time="+ "2022-10-31 10:00".toDate("yyyy-MM-dd HH:mm").datePart("time")/1000 +"&language=de&key={YOUR_API_KEY}"

Daten aufbereiten

Die JSON Antwort der Google Maps Direction API ist recht ausführlich, wenn denn eine funktionierende Strecke gefunden werden konnte. Hier ein kleiner Ausschnitt:

{
 ...
 "copyrights": "Map data ©2022 GeoBasis-DE/BKG (©2009)",
 "legs": [
 {
 "arrival_time": {
 "text": "10:22",
 "time_zone": "Europe/Berlin",
 "value": 1667208156
 },
 "departure_time": {
 "text": "09:06",
 "time_zone": "Europe/Berlin",
 "value": 1667203588
 },
 "distance": {
 "text": "48,2 km",
 "value": 48218
 },
 "duration": {
 "text": "1 Stunde, 16 Minuten",
 "value": 4568
 },
 "end_address": "Panorama Therme, 72660 Beuren, Deutschland",
 "end_location": {
 "lat": 48.5655941,
 "lng": 9.3967464
 },
 "start_address": "Eugenstraße 7, 70182 Stuttgart, Deutschland",
 "start_location": {
 "lat": 48.77899370000001,
 "lng": 9.1865211
 },
 "steps": ...
}

Interessant ist hier, dass wir die Werte für die Entfernung und Dauer sowohl als Text, als auch in Metern bzw. Sekunden erhalten. Wir extrahieren auch hier die Zahlenwerte, da diese einfacher in ein einheitliches Format umgewandelt werden können.

Die erste neue Spalte nennen wir “Google Entfernung (ÖPNV)” und verwenden den folgenden GREL Ausdruck zur Extraktion und Umwandlung der Entfernung in Kilometern:

(value.parseJson().routes[0].legs[0].distance.value/1000).round()

Die zweite neue Spalte nennen wir “Google Dauer (ÖPNV)” und verwenden den folgenden GREL Ausdruck zur Extraktion und Umwandlung der Dauer in Minuten:

(value.parseJson().routes[0].legs[0].duration.value/60).round()

Formate anpassen

Zur Verbesserung der Lesbarkeit, ergänzen wir die Entfernungsspalten um die Angabe “km”. Dafür nutzen wir “Spalte" "Edit cells" "Transform” und den folgenden GREL Ausdruck.

value+"km"

In den Spalten zur Dauer wandeln wir die Angaben von Minuten in Stunden und Minuten um.

with(value.toDate("mm"), d,
 with(d.datePart("h"), h,
 with(d.datePart("min"), min,
 if(h > 0,
 h + "h " + min + "min",
 min + "min"))))

Das Endergebnis ist in Abbildung 11 gezeigt.

Bildschirmfoto des fertigen Projektes in OpenRefine.

Fazit

Dieser Artikel ist überraschend lang geworden. Das liegt hauptsächlich daran, dass wir versuchen Hintergründe zu erklären, mit der Auswertung der Wegpunkte einen etwas komplizierteren Fall durchspielen und uns gleich drei unterschiedliche WebAPIs ansehen.

In einem vereinfachten Test mit einem anderen Datensatz unter der Verwendung des ersten Punktes der Wanderung als Zielpunkt und nur einer API, haben wir die Bearbeitung in etwa 10 Minuten abgeschlossen. Und zwar inklusive Export in eine Software für Tabellenkalkulation und anschließender visueller Formatierung für den Druck.

Generell waren wir überrascht, wie wenig aufwendig es ist, eine Menge von GPX-Dateien im XML-Format in OpenRefine einzulesen, die relevanten Geokoordinaten herauszufiltern und damit Anfragen an eine WebAPI zu stellen.

Bei den WebAPIs hat uns OpenRouteService in seiner Einfachheit gefallen. Der Funktionsumfang der API ist nicht so umfangreich, wie bei den kommerziellen Anbietern. Jedoch ist der initiale Aufwand für die Account Registrierung geringer, sowie die Erstellung eines API Schlüssels sehr übersichtlich gehalten.

Das Erstellen eines Accounts und API Schlüssels für die HERE Routing API war ebenfalls sehr direkt und die Arbeit mit der API machte uns sofort Spaß. Die HERE Routing API lädt dazu ein, noch viel mehr und umfangreicher mit ihr zu arbeiten.

Bei Google fühlten wir uns zuerst von der Menge der Dienste und möglichen Alternativen erschlagen. Die Google Maps Direction API ist dann auch sehr umfangreich, so dass wir im Vergleich mit den anderen APIs etwas länger brauchten, um genau unseren Use-Case damit abzubilden. Dafür konnten wir damit problemlos die Anfahrt mit dem Öffentlichen Personennahverkehr berechnen.

Auch wenn es sich bei den Daten für dieses Experiment nicht um “klassische” Archivdaten handelt, so hilft uns das Experiment besser zu verstehen, wie OpenRefine uns dabei unterstützt Daten aus unterschiedlichen Quellen zusammenzuführen. Im Kontext der einfachen Installation von OpenRefine steigert die Anbindung von generischen WebAPIs ohne Programmierkenntnisse die Attraktivität von OpenRefine weiter.

Workshop - Arbeiten mit GREL

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

In diesem Tutorial beschäftigen wir uns mit der “General Refine Expression Language” (GREL).

Einführung

GREL in der OpenRefine Dokumentation.
GREL Rezepte im OpenRefine Wiki.

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

Mit der General Refine Expression Language (GREL) werden in OpenRefine die einzelnen Operationen auf den Daten ausgeführt. Die meisten Funktionen und Dialoge in OpenRefine sind quasi nur ein Eingabeformular für GREL Ausdrücke, die in den Facets angezeigten Daten basieren auf GREL Ausdrücken und in verschiedenen Dialogen können wir auch direkt GREL Ausdrücke verwenden, um zum Beispiel Daten zu transformieren.

Die Syntax von GREL ist dabei an die Programmiersprache JavaScript angelehnt, die unterliegende Technologie basiert jedoch auf der Programmiersprache Java. Dadurch entstehen Verständnisprobleme, wenn zum Beispiel reguläre Ausdrücke im Stil von JavaScript geschrieben werden, dann jedoch in OpenRefine intern von Java ausgewertet werden und entsprechend die Funktionalität von regulären Ausdrücken in Java unterstützen.

Die Eingabe von GREL Ausdrücken erfolgt (meistens) über Dialogfenster wie in Abbildung 1. Hier sehen wir nicht nur eine Vorschau der Umwandlung, die wir gerade anstreben, sondern können auch vorherige oder gespeicherte (Starred) GREL Ausdrücke laden.

Bildschirmfoto eines Dialog Fensters zur Transformation von Daten in OpenRefine.

Werte, Variablen, Objekte

In Programmiersprachen gibt es verschiedene Konzepte um mit Daten zu arbeiten.

Ein Konzept ist die Typisierung von Daten. So wird bei Werten zum Beispiel zwischen Text und Zahlen unterschieden. Mit diesen Werten können dann verschiedene Operationen und Berechnungen durchgeführt werden.

5 > 2
> true

Diesen Werten können via Variablen auch Namen zugewiesen werden.

laenge = 5
breite = 2
laenge > breite
> true

Oder es gibt spezielle Funktionen für Werte eines bestimmten Typs:

text = "Lorem ipsum"
length(text)
> 11

Werte und Funktionen lassen sich zu Objekten zusammenfassen. Via Variable kann ein bestimmtes Objekt gespeichert und darauf zugegriffen werden.

Rechteck(laenge, breite):
 laenge = leange
 breite = breite
 flaeche()
 return laenge * breite

rechteck1 = Rechteck(5, 2)
rechteck2 = Rechteck(4, 2)

rechteck1.flaeche > rechteck2.flaeche
> true

In GREL verwenden wir hauptsächlich schon existierende Variablen, Funktionen und Objekte.

Datentypen

In der OpenRefine Oberfläche arbeiten wir mit vier Datentypen: boolean, date, number und string. In GREL gibt es noch die Datentypen array, object und regex. Texte (string) können zusätzlich in eine Repräsentation für HTML, JSON oder XML geparsed werden. Das bedeutet vereinfacht, dass die (Text-)Daten intern von OpenRefine in eine Repräsentation überführt werden, die zum Beispiel XML versteht und dafür passende Funktionen anbietet. Also zum Beispiel die Funktion über alle XML-Knoten mit einem bestimmten Namen zu iterieren.

Typ	Kürzel	GUI	Beispiel(e)
array	a		`["a", "b", "c"]`
boolean	b	Ja	`true`, `false`
date	d	Ja	`[date 2022-05-03T15:00:00Z]`
number	n	Ja	`1`, `3.1415`
object	o		`[object Cell]`
regex	p		`/\d{4}/`
string	s	Ja	`Lorem ipsum...`

Variablen

Beim Arbeiten mit GREL stehen uns zusätzlich einige Umgebungsvariablen zur Verfügung.

Variable	Alternative	Beschreibung
cell	row.cells[columnName]	Aktuelle Zelle der ausgewählten Spalte.
cell.recon		Reconciliation Daten für die Zelle.
cell.recon. …		Dokumentation zu Recon.
cell.value	value	Wert der Zelle.
cell. ….		Dokumentation zu Cell.
columnName		Name der ausgewählten Spalte.
row		Aktuelle Zeile.
row.cells	cells	Zellen in der aktuellen Zeile.
row.cells. …		Dokumentation zu Cells
row.index	rowIndex	Index der aktuellen Zeile.
row.record		Record der aktuellen Zeile.
row.record. …		Dokumentation zu Record
row. ….		Dokumentation zu Row.
value1		Neu seit OpenRefine 3.9 für Distanz basiertes Clustering.
value2		Neu seit OpenRefine 3.9 für Distanz basiertes Clustering.

Die Variablen beinhalten teilweise einfache Werte (value, rowIndex) wie einen Text oder eine Zahl. Teilweise verweisen sie auf komplexe Objekte, worin die Werte gesammelt oder verschachtelt gespeichert sind (row). Manche Variablen stellen auch Abkürzungen dar. So kann auf den Wert der aktuellen Zeile in der ausgewählten Spalte direkt mit value zugegriffen werden, anstatt dies via row.cells[columnName].value machen zu müssen.

Hier eine Übersicht der Objekte und Variablen.

--- title: Datenstruktur config: look: handDrawn theme: neutral --- flowchart LR columnName row.index[index] row.cells[cells] row.columnNames[columnNames] row.starred[starred] row.flagged[flagged] row.record[record] row.cells.cell[cell...] row.cells.cell.value[value] row.cells.cell.recon[recon] row.cells.cell.recon.properties[...] row.cells.cell.errorMessage[errorMessage] row.cells.cell.errorMessage.value[value] row.record.index[index] row.record.cells[cells] row.record.fromRowIndex[fromRowIndex] row.record.toRowIndex[toRowIndex] row.record.rowCount[rowCount] row --> row.index & row.cells & row.columnNames & row.starred & row.flagged & row.record row.cells --> row.cells.cell row.cells.cell --> row.cells.cell.value & row.cells.cell.recon & row.cells.cell.errorMessage row.cells.cell.errorMessage --> row.cells.cell.errorMessage.value row.cells.cell.recon --> row.cells.cell.recon.properties row.record --> row.record.index & row.record.cells & row.record.fromRowIndex & row.record.toRowIndex & row.record.rowCount cell -.-> row.cells.cell cells -.-> row.cells rowIndex -.-> row.index value -.-> row.cells.cell.value

Fortsetzung für Reconciliation Daten einer Zelle:

--- title: Datenstruktur - recon config: look: handDrawn theme: neutral --- flowchart LR row.cells.cell.recon[row.cells.cell....recon] row.cells.cell.recon.judgment[judgment] row.cells.cell.recon.judgmentAction[judgmentAction] row.cells.cell.recon.judgmentHistory[judgmentHistory] row.cells.cell.recon.matched[matched] row.cells.cell.recon.match[match] row.cells.cell.recon.best[best] row.cells.cell.recon.features[features] row.cells.cell.recon.candidates[candidates] row.cells.cell.recon.features.typeMatch[typeMatch] row.cells.cell.recon.features.nameMatch[nameMatch] row.cells.cell.recon.features.nameLevenshtein[nameLevenshtein] row.cells.cell.recon.features.nameWordDistance[nameWordDistance] match.id[id] match.name[name] match.type[type] match.score[score] row.cells.cell.recon --> row.cells.cell.recon.judgment & row.cells.cell.recon.judgmentAction & row.cells.cell.recon.judgmentHistory & row.cells.cell.recon.matched & row.cells.cell.recon.match & row.cells.cell.recon.best & row.cells.cell.recon.features & row.cells.cell.recon.candidates row.cells.cell.recon.match --> match.id & match.name & match.type row.cells.cell.recon.best --> match.id & match.name & match.type & match.score row.cells.cell.recon.candidates --> match.id & match.name & match.type & match.score row.cells.cell.recon.features --> row.cells.cell.recon.features.typeMatch & row.cells.cell.recon.features.nameMatch & row.cells.cell.recon.features.nameLevenshtein & row.cells.cell.recon.features.nameWordDistance

Auf Attribute eines Objekts kann punktnotiert row.cells oder via Klammern row["cells"] zugegriffen werden. Prinzipiell empfiehlt es sich aus Gründen der Lesbarkeit die Punktnotation zu verwenden und die Variante mit Klammern nur, wenn der Name in einer Variablen steht cells[columnName] oder wir mit Spaltennamen arbeiten, die potentiell “Sonderzeichen” beinhalten können cells["GND-ID"].

Aktuell kann nicht auf alle Werte einer Spalte zugegriffen werden. Man kann aber auf alle Werte einer Spalte eines Records zugreifen: row.record.cells[columnName].

Kontrollstrukturen

Etwas verwirrend ist das Definieren von eigenen Variablen in GREL. Das geschieht mit einer with Anweisung. Im folgenden Beispiel setzen wir die Variable jahr auf den Wert 1988 und berechnen dann den Ausdruck jahr < 2000.

with(1988, jahr, jahr < 2000) == true

Wir geben das erwartete Ergebnis der GREL Ausdrücke in den Beispielen zusätzlich via == ... an, so dass das Ergebnis auch abgelesen werden kann, ohne den Ausdruck in OpenRefine oder im Kopf auswerten zu müssen.

Eine der essentiellen Kontrollstrukturen in der Informatik ist die Verzweigung. In GREL wird dies mit if realisiert. Im folgenden Beispiel setzen wir wie zuvor die Variable jahr auf den Wert 1988, geben aber abhängig von dem Ergebnis einer Prüfung unterschiedliche Werte zurück. Die if-Anweisungen können auch ineinander verschachtelt werden.

with(1988, jahr, if((jahr >= 1980).and(jahr < 1990), "80er", "Sonstiges")) == "80er"

Anstatt einer Verzweigung ist es manchmal auch nötig eine komplette Liste (technisch Array) von Werten zu filtern. Dafür gibt es in GREL eine filter() Funktion. Im folgenden Beispiel erstellen wir einen Array aus einem Text indem wir ihn mit split() am Trennzeichen , trennen. Anschließend wandeln die einzelnen Elemente mit toNumber() in Zahlen um und filtern anschließend nur die geraden Zahlen via mod(number, 2) == 2. Um das Ergebnis in OpenRefine ausgeben zu können, wandeln wir die Daten im Array anschließend mit join() wieder in einen Text um, da OpenRefine in der GUI keine Arrays anzeigen kann.

filter("1,2,3,4,5,6,7,8,9,10".split(","), v, mod(v.toNumber(), 2) == 0).join(",") == "2,4,6,8,10"

Um alle Werte einer Liste (technisch Array) durchzugehen, gibt es in GREL die forEach Anweisung. Im folgenden Beispiel erstellen wir mit split() einen Array aus einem Text und fügen mit + zu jedem Element die Endung “er” hinzu. Anschließend fügen wir die Daten im Array mit join() wieder zu einen Text zusammen.

forEach("70,80,90".split(","), v, v + "er").join(",") == "70er,80er,90er"

Zusätzlich gibt es noch weitere Helfer. Um den Typ eines Wertes zu prüfen gibt es verschiedene Varianten von is…, um einen bestimmten Bereich aufzuzählen forRange oder um eine Liste (technisch Array) aufzuzählen forEachIndex.

Extra: forNonBlank

Da sie etwas verwirrend ist, geben wir der Funktion forNonBlank hier noch einen separaten Absatz. Angenommen wir wollen eine Liste (technisch Array) von Werten durchgehen und dabei nur Werte bearbeiten, die einen Inhalt haben. Also zum Beispiel die ["1", "2", "", "4", "5"] umwandeln in 1,2,0,4,5.

forNonBlank(["1", "2", "", "4", "5"], v, v, 0).join(",") == "1,2,,4,5"

Das klappt so nicht, da forNonBlank(v, ...) eine andere Schreibweise für if(isNonBlank(v), ...) ist. Der korrekte Weg ist also einer der beiden folgenden Ausdrücke.

forEach(["1", "2", "", "4", "5"], v, if(isNonBlank(v), v, 0)).join(",") == "1,2,0,4,5"
forEach(["1", "2", "", "4", "5"], v, forNonBlank(v, v, v, 0)).join(",") == "1,2,0,4,5"

Standardbibliothek

Üblicherweise haben Programmiersprachen eine Standardbibliothek von Funktionen zum Arbeiten mit den zur Verfügung gestellten Datentypen.

Diese ist bei GREL im Vergleich zu anderen Programmiersprachen zwar recht übersichtlich, kann hier aber trotzdem nicht vollständig besprochen werden. Wir empfehlen daher, die Liste der in OpenRefine verfügbaren Funktionen als Referenz verfügbar zu halten.

Wir gehen hier auf ein paar Besonderheiten von GREL ein.

Syntax für Funktionsaufrufe

Eine Besonderheit in GREL ist, dass Funktionen zur besseren Lesbarkeit auch in Punktnotation aufgerufen werden können. Also length(value) auch geschrieben werden kann als value.length().

Aliase

Es gibt Funktionen, die unter mehreren Namen verfügbar sind.

Beispielsweise sind trim() und strip() bis auf ihre Namen identisch und wurden auch gleichzeitig in OpenRefine eingeführt. Vermutlich sollte das Quereinsteigern von anderen Programmiersprachen den Einstieg vereinfachen.

Vorbereitung: Projekt erstellen

Wir laden die folgende Datei in ein OpenRefine Projekt.

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

Kretschmann Kabinett III

Wie in Abbildung 2 beinhaltet die Datei das Kabinett Kretschmann III mit den Berufen.

Bildschirmfoto des Projektes direkt nach dem Laden.

Aufgabe 1: GREL Variablen nutzen

Das Geburtsdatum ist in drei Spalten aufgeteilt, wir wollen das Geburtsdatum jedoch in einer Spalte haben und dabei den Monat auch noch ausgeschrieben haben. Das haben wir in 03 Transformieren: Aufgabe 5 so ähnlich schon einmal mit Funktionen in der Benutzeroberfläche gelöst. Hier wollen wir GREL Funktionen verwenden, um die Bearbeitung in einem Schritt durchzuführen.

Dafür verwenden wir “Geburtsjahr" "Edit column" "Add column based on this column” und entwickeln schrittweise den in Abbildung 3 gezeigten GREL Ausdruck.

Bildschirmfoto des Dialogs zur Transformation.

Schritt 1: Geburtsmonat umwandeln

Um die Spalte “Geburtsmonat” in einen Namen umzuwandeln verwenden wir den Zugriff über row.cells["Geburtsjahr"] und die Funktionen toDate() und toString().

row.cells["Geburtsmonat"].value.toDate("M").toString("MMMM")

Schritt 2: Spalten zusammenfügen

Um die Spalten zusammenzufügen verwenden wir den Operator +.

row.cells["Geburtstag"].value + ". "
+ row.cells["Geburtsmonat"].value + " "
+ row.cells["Geburtsjahr"].value

Schritt 3: Verzweigung einbauen

Für manche Zeilen wird entweder eine Fehlermeldung oder null angezeigt. Das sind die Zeilen, wo kein Geburtstag und kein Geburtsmonat vorhanden sind.

Diese behandeln wir separat mit einer Verzweigung und passen dabei den Typ der Inhalte der Spalte “Geburtsjahr” an.

if(
 isBlank(row.cells["Geburtstag"]),
 row.cells["Geburtsjahr"].value.toString(),
 ...
)

Aufgabe 1

Fügen Sie die drei obigen GREL Ausdrücke zu einem GREL Ausdruck zusammen.

Lösung:

if(
 isBlank(row.cells["Geburtstag"]),
 row.cells["Geburtsjahr"].value.toString(),
 row.cells["Geburtstag"].value + ". "
 + row.cells["Geburtsmonat"].value.toDate("M").toString("MMMM") + " "
 + row.cells["Geburtsjahr"].value
)

Aufgabe 2: Werte aufräumen und sortieren

Die Werte in der Spalte “Beruf oder Beschäftigung” sind nicht sortiert, haben teilweise Duplikate und teilweise numerische Referenzen hinter den Berufsbezeichnungen. Diese Spalte wollen wir daher in einem Schritt mit einem GREL Ausdruck aufräumen und dabei die numerischen Referenzen entfernen, Duplikate entfernen und die Werte alphabetisch sortieren.

Dafür verwenden wir den Dialog “Beruf oder Beschäftigung" "Edit cells" "Transform” und erarbeiten uns einen GREL Ausdruck.

Schritt 1: Text in Liste umwandeln

Um die einzelnen Werte im Text in eine Liste (technisch Array) umzuwandeln, verwenden wir split() mit , als Trennzeichen.

"Politiker, Abgeordneter, Lehrer, Regierungschef, Politiker (5), Lehrer (3)".split(", ")

Schritt 2: Numerische Referenzen entfernen

Um die numerischen Referenzen zu entfernen verwenden wir replace() mit einem regulären Ausdruck und entfernen zusätzliche Leerzeichen.

"Politiker (5)".replace(/\(\d+\)/, "").trim()

Schritt 3: Funktion auf alle Elemente anwenden

Um die Ersetzung der numerischen Referenzen auf alle Elemente in der Liste (technisch Array) anzuwenden nutzen wir forEach.

forEach(
 ["Politiker, Abgeordneter, Lehrer, Regierungschef, Politiker (5), Lehrer (3)"],
 v,
 ...
)

Schritt 4: Werte vereinheitlichen und sortieren

Um die Werte zu vereinheitlichen und zu sortieren nutzen wir uniques() und sort().

["Politiker, Abgeordneter, Lehrer, Regierungschef, Politiker, Lehrer"].uniques().sort()

Schritt 5: Text aus Liste erstellen

Um aus der Liste (technisch Array) wieder einen Text zu erzeugen, verwenden wir join() mit , als Trennzeichen.

["Abgeordneter", "Lehrer", "Politiker", "Regierungschef"].join(", ")

Aufgabe 3

Fügen Sie die fünf obigen GREL Ausdrücke zu einem GREL Ausdruck zusammen. Das Ergebnis sollte in etwa wie in Abbildung 4 aussehen.

Bildschirmfoto des Projektes nach der Bearbeitung.

Lösung:

forEach(
 value.split(", "),
 v,
 v.replace(/\(\d+\)/, "").trim())
 .uniques()
 .sort()
 .join(", ")

Fazit

Viele Umwandlungen lassen sich in Einzelschritten über die graphische Oberfläche von OpenRefine ansteuern und umsetzen. So kommt man auch ohne in GREL zu programmieren in OpenRefine recht weit. Das Wissen um den Zugriff auf die Umgebungsvariablen und nützliche Funktionen wie find(), replace() oder Datumsumwandlungen ersetzt viele manuelle Schritte.

Das explizite Programmieren mit Verzweigungen und Schleifen ergänzt Arbeitsschritte oder reduziert mehrere Einzelschritte in der graphischen Oberfläche zu einem Schritt. Beim Export von XML in OpenRefine (Templating) sind die Kontrollstrukturen noch einmal relevant.

Im nächsten Teil behandeln wir das Konzept von “Records” in OpenRefine.

10 Arbeiten mit Records

Workshop - Arbeiten mit Records in OpenRefine

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

OpenRefine kann im Zeilen- oder Records-Modus arbeiten. In diesem Tutorial besprechen wir, wie wir Records aus auf Zeilen basierten Datensätzen erstellen, wie wir mit Records arbeiten können und wie wir Records wieder in auf Zeilen basierte Datensätze umwandeln.

Einführung

Records in der OpenRefine Dokumentation.
Records mit GREL in der OpenRefine Dokumentation.

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

Um in OpenRefine zwischen dem Zeilen- und dem Record-Modus zu wechseln, gibt es in der oberen Bedienleiste, die in Abbildung 1 gezeigten Schaltflächen.

Bildschirmfoto der Schaltflächen zum Umschalten zwischen dem Zeilen- und Record-Modus.

Diese Schaltflächen ändern, wie OpenRefine aufeinanderfolgende Zeilen anzeigt, filtert, und bearbeitet. Betrachten wir den folgenden Ausschnitt aus dem Kabinett Kretschmann III, mit dem wir auch die folgenden Praxisaufgaben durchführen werden.

All	Name	Beruf
1.	Kretschmann, Winfried	Abgeordneter
2.		Lehrer
3.		Politiker
4.		Regierungschef
5.	Walker, Thekla	Pädagogin
6.		Politikerin
7.		Weibliche Abgeordnete

Diese Tabelle zeigt, wie OpenRefine im Zeilenmodus mit den Daten umgeht. Jede Zeile steht für sich und hat auch eine eigene Zeilennummer. Wird in diesem Modus in der Spalte “Beruf” nach dem Wert “Politik” gefiltert, dann werden in diesem Modus nur die Zeilen 3. und 6. angezeigt. Man weiß also nicht, zu welcher Person dieser Wert gehört.

Im Record-Modus betrachtet OpenRefine die 1. Spalte, nimmt die erste Zelle mit einem Wert (z.B. Zeile 1) und fasst sie mit den folgenden Zeilen mit einer leeren Zelle in der 1. Spalte (Zeilen 2 - 4) wie in der nächsten Tabelle gezeigt zu einem Record zusammen.

All	Name	Beruf
1.	Kretschmann, Winfried	Abgeordneter Lehrer Politiker Regierungschef
2.	Walker, Thekla	Pädagogin Politikerin Weibliche Abgeordnete

Entsprechend wird auch die Anzeige geändert und zum Beispiel nicht mehr die Zeilen durchnummeriert, sondern die Records. Das ermöglicht es mit OpenRefine baumartige Strukturen zu importieren, zu verarbeiten und zu exportieren.

In den folgenden praktischen Übungen werden wir das Arbeiten mit Records praktisch ausprobieren und dabei auch einige für Records spezifische GREL Ausdrücke kennen lernen.

Vorbereitung: Projekt erstellen

Die folgende Datei in ein OpenRefine-Projekt laden.

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

Kretschmann III als CSV

Aufgabe 1: Records aus wiederholenden Zeilen erstellen

Bildschirmfoto mit den Berufen der Mitglieder im Kabinett Kretschmann III.

Wir starten wie in Abbildung 2 gezeigt mit den Berufen der Mitglieder im Kabinett Kretschmann III (abgerufen am 03.12.2021 aus der GND). Unser Ziel ist es, einen Überblick über alle Berufe eines Mitgliedes des Kabinetts zu erhalten.

Dafür verschieben wir die Spalte “Name” via “Name" "Edit column" "Move column to beginning” ganz nach links. Anschließend sortieren wir die Spalte “Name” alphabetisch via “Name" "Sort…” und fixieren diese Sortierung wie in Abbildung 3 zu sehen via “Sort" "Reorder rows permanently”.

Bildschirmfoto mit dem Menü zum Sortieren.

Danach entfernen wir die Mehrfachnennung der Namen via “Name" "Edit cells" "Blank down”. Das Ergebnis sieht dann wie in Abbildung 4 aus.

Bildschirmfoto mit den Berufen der Mitglieder im Kabinett Kretschmann III.

Typische Anwenderfehler bei “Blank down”:

Vergessen auf den “Zeilenmodus” (rows) umzuschalten.
Inhalte sind nicht alle vom Typ Text.

Aufgabe 2: Arbeiten mit Records

Die Record Struktur hilft uns beim Verarbeiten baumartiger Strukturen, wie es beim Lesen und Schreiben von XML vorkommt. Hier ein paar hilfreiche Funktionen zum Arbeiten mit Records, deren Ergebnisse in Abbildung 5 gezeigt sind.

Bildschirmfoto mit den Ergebnissen verschiedener Aktionen mit Records.

Um Aktionen auf Records anzuwenden, wechseln wir in den Records-Modus.

Records filtern

Das Verwenden von Filtermöglichkeiten mit Records kann manchmal etwas verwirrend sein. Um dies zu demonstrieren verwenden wir eine Kombination aus Textfacet und Textfilter auf der Spalte Beruf via “Beruf" "Facet" "Text facet” und “Beruf" "Textfilter”.

In dem Textfilter suchen wir dann nach dem Begriff “Recht”.

Bildschirmfoto mit einer Kombination aus Textfacet und Textfilter auf Records in OpenRefine.

Wie in Abbildung 6 zu sehen, werden im Record-Modus bei der Verwendung eines Textfilters alle Records angezeigt, die eine Zeile haben, auf die der Textfilter passt. In unserem Fall sind das Minister Strobl und Ministerin Gentges, die beide in der GND Rechtsanwältin bzw. Rechtsanwalt als Berufsangabe haben.

Das ist auch nachvollziehbar und sinnvoll. Gleichzeitig bedeutet es, dass das Textfacet nicht auf Werte reduziert wird, die den Begriff “Recht” im Namen haben (Rechtsanwalt und Rechtsanwältin), sondern alle Werte angezeigt werden, die in den beiden gefilterten Records vorkommen. Das ist ebenfalls nachvollziehbar und sinnvoll, überrascht aber manchmal, da man im Kopf noch/schon im Zeilenmodus denkt.

Daher ist gerade beim Filtern mit Records im Hinterkopf zu behalten, dass manchmal zwischen dem Zeilen- und Record-Modus hin- und hergewechselt werden sollte.

Records durchnummerieren

Wir erstellen eine neue Spalte “Record ID” via “Beruf" "Edit column" "Add column based on this column…” und verwenden den folgenden GREL Ausdruck.

row.record.index + 1

Anschließend verwenden wir “Record ID" "Edit cells" "Blank down” um die überzähligen IDs zu entfernen.

Elemente in Records durchnummerieren

Wir erstellen eine neue Spalte “Record Element ID” via “Record ID" "Edit column" "Add column based on this column…” und verwenden den folgenden GREL Ausdruck.

1 + row.index - row.record.fromRowIndex

Elemente in Records zählen

Wir erstellen eine neue Spalte “Record Count” via “Record Element ID" "Edit column" "Add column based on this column…” und verwenden den folgenden GREL Ausdruck.

if(value==1, row.record.rowCount, null)

Hier sparen wir uns das anschließende “Blank down”, da wir über eine if-Anweisung die Anzahl nur in Zeilen mit der Record Element ID 1 geschrieben haben.

Elemente Sortieren/Doppelungen entfernen

Wir transformieren die Spalte “Beruf” via “Beruf" "Edit cells" "Transform…” und verwenden einen der folgenden GREL Ausdrücke.

Doppelungen entfernen:

row.record.cells["Beruf"].value.uniques().join(", ")

Nur sortieren:

row.record.cells["Beruf"].value.sort().join(", ")

Doppelungen entfernen und sortieren:

row.record.cells["Beruf"].value.uniques().sort().join(", ")

Diese Operation schreibt die Werte alle in eine Zeile.
Wie wir daraus wieder Records bekommen, ist in “04 Records aus Feldern mit mehreren Werten erstellen” beschrieben.

Aufgabe 3: Records in Felder mit mehreren Werten auflösen

Da nicht alle Zielprogramme mit einer Record-Struktur klarkommen, müssen diese manchmal auch wieder umgewandelt werden. Eine Möglichkeit sind so genannte “Multi-Value-Fields”, oder Felder mit mehreren Werten. In unserem Beispiel könnte das eine mit Komma separierte Liste aller Berufe sein.

Dafür verwenden wir “Beruf" "Edit cells" "Join multi-valued cells…” und wählen als Trennzeichen eine Zeichenfolge aus Komma und Leerzeichen ,. Das Ergebnis der Operation ist in Abbildung 7 gezeigt.

Bildschirmfoto mit der Spalte Beruf als Multi-Value-Fields.

Möchte man die Werte in mehrere Spalten aufteilen, so kann dafür “Beruf" "Edit column" "Split into several columns…” verwendet werden. Das Ergebnis der Operation ist in Abbildung 8 gezeigt.

Bildschirmfoto mit der Spalte Beruf auf mehrere Spalten aufgeteilt.

Aufgabe 4: Records aus Feldern mit mehreren Werten erstellen

Im FDMLab kommt es öfter vor, dass wir Datensätze mit “Multi-Value-Fields”, wie in Abbildung 7, oder die Daten aufgeteilt auf mehrere Spalten, wie in Abbildung 8 bekommen.

Diese wandeln wir dann in Records um, um zum Beispiel die Schreibweise via Clustering zu vereinheitlichen, oder ein gemeinsames Reconciling der Daten durchzuführen.

Dafür machen wir die in “03 Records in Felder mit mehreren Werten auflösen” durchgeführten Änderungen wieder rückgängig, ohne die History-Funktion zu verwenden.

Zuerst fügen wir die Spalten wieder via “Beruf 1" "Edit column" "Join columns…” zusammen. Die Einstellungen sind in Abbildung 9 gezeigt.

Bildschirmfoto des OpenRefine Dialogs zum Zusammenführen von Spalten.

Anschließend erstellen wir die Record-Struktur via “Beruf" "Edit cells" "Split multi-valued cells…” und wählen als Trennzeichen die gleiche Trennsequenz, wie beim Zusammenfügen der Spalten in Abbildung 9. In unserem Fall also ,.

Wir sind nun wieder bei der Record-Struktur wie in Abbildung 4 angekommen.

Aufgabe 5: Records in wiederholende Zeilen auflösen

Manchmal wollen wir von der Record-Struktur auch zu sich wiederholenden Werten in Zeilen wechseln, wie wir es ganz zu Beginn dieses Tutorials in Abbildung 2 gesehen haben.

Wir gehen davon aus, dass wir eine Record-Struktur wie in Abbildung 4 haben. Dort nutzen wir dann das Gegenstück zu “Blank down” via “Name" "Edit cells" "Fill down” .

Um zum “Original” in Abbildung 2 zu kommen, müssten wir die Spalte “Beruf” noch alphabetisch sortieren und ganz nach links verschieben.

Fazit

Mit Records lassen sich interessante Datentransformationen bewerkstelligen. Bei der Aufbereitung von Findbüchern mit OpenRefine haben wir damit zum Beispiel die Inhalte von zweispaltigen Seitenlayouts in einzelne Zeilen umgewandelt.

Zu Beginn ist das Konzept potentiell noch neu und ungewohnt, wer sich jedoch tiefer damit beschäftigt, kann damit Probleme lösen, die man sonst an Programmiersprachen wie Clojure oder Jython in OpenRefine delegieren würde.

Im nächsten Teil behandeln wir das Konzept des Transponierens mit dem wir in OpenRefine ähnliche Probleme behandeln können.

11 Transponieren

Workshop - Arbeiten mit regulären Ausdrücken

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

Ein wichtiges Werkzeug beim Arbeiten mit Daten sind reguläre Ausdrücke. Diese werden in OpenRefine von verschiedenen Funktionen unterstützt.

Einführung

Reguläre Ausdrücke in der OpenRefine Dokumentation.

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

Mit regulären Ausdrücken können wir Muster definieren, mit denen wir bestimmte Zeichenfolgen in einem Text finden, extrahieren und/oder ersetzen können. Dies funktioniert nicht nur in Programmiersprachen wie Python oder Programmen wie OpenRefine, sondern auch in frei verfügbaren Text Editoren wie Notepad++ oder Visual Studio Code.

Perl Problems von Randall Munroe unter CC BY-NC Lizenz.

Bei Memes zu regulären Ausdrücken wird wie in Abbildung 1 häufig der Eindruck erweckt, dass sie mehr Probleme erzeugen als sie tatsächlich lösen. Richtig dosiert sind sie jedoch ein hilfreiches Werkzeug bei der Datenextraktion.

Das Vorgehen beim Entwickeln von regulären Ausdrücken unterscheidet sich von Person zu Person. Wir zeigen hier unser bevorzugtes Vorgehen, von dem gerne abgewichen werden darf.

Zum Entwickeln, Testen und Verstehen von regulären Ausdrücken, nutzen wir RegEx101 (Alternative: RegExr). Hier bekommen wir wie in Abbildung 2 visuelles Feedback, auf welche Textzeilen unsere regulären Ausdrücke passen und was die einzelnen Bestandteile bedeuten.

Bildschirmfoto von RegEx101 mit Art ECMAScript, einem regulären Ausdruck zur Extraktion von Datumsangaben in der Mitte oben, mehreren Beispielen direkt darunter und hilfreichen Informationen auf der rechten Seite.

Die Verwendung eines visuell unterstützenden Werkzeuges wie RegEx101 hat den Vorteil, dass wir einen übersichtlichen regulären Ausdruck entwickeln können, den wir dann in unsere Ursprungsanwendung, wie zum Beispiel OpenRefine, übertragen können. Ein Nachteil ist, dass zum Beispiel in OpenRefine nicht alle Features von regulären Ausdrücken unterstützt werden und der reguläre Ausdruck nachträglich ggf. angepasst werden muss.

Vorbereitung

Wir erstellen uns eine kleine Sammlung von Beispielen für Daten, die wir mit einem regulären Ausdruck bearbeiten wollen. Dazu ergänzen wir einige Negativbeispiele, also Beispiele, die von unserem regulären Ausdruck nicht extrahiert werden sollten.

Die Beispiele für dieses Tutorial sind im Folgenden gelistet und wir kopieren sie in das Testfenster von RegEx101.

2021-11-25 Einsteigerworkshop 1
2021-12-08 Einsteigerworkshop 2
2022-04-07 Einsteigerworkshop 3
2022-04-13 Einsteigerworkshop 4
2022-05-03 Fortgeschrittenenworkshop
1970-01-01
2005-1-1
- - - - - - - - - - - - - - - - - - -
Do not match!
1234-56-78
2022-13-01
2022-01-32
12-34-56
abcd-ef-gh

Wir werden bei den folgenden Aufgaben teilweise keine “perfekten” regulären Ausdrücke entwickeln, also teilweise Treffer in der Liste der Negativbeispiele haben!

Reguläre Ausdrücke werden von verschiedenen Programmiersprachen und Werkzeugen unterstützt. Dabei unterscheidet sich die Art, wie reguläre Ausdrücke als solche markiert werden. Außerdem werden je nach Programmiersprache, Version der Programmiersprache oder Werkzeug nicht alle Features von regulären Ausdrücken unterstützt.

In RegEx101 können wir daher ein so genanntes Flavor für die Eingabe der regulären Ausdrücke auswählen. Wir verwenden für unser Tutorial “ECMAScript (JavaScript)”. Das hat den Hintergrund, dass sich GREL an der Syntax für JavaScript orientiert, auch wenn es im Hintergrund Java zur Auswertung verwendet. Reguläre Ausdrücke werden hier durch zwei Schrägstriche /.../ markiert.

Hinter dem regulären Ausdruck gibt es optional noch Optionen. Wir verwenden für RegEx101 die Optionen g und m. Das sind die Standardoptionen, die bewirken, dass ein regulärer Ausdruck auf den kompletten Text (g für global) und auch Zeilen übergreifend (m für multiline) angewendet werden kann.

Wir haben sie in den Beispielen explizit gesetzt, damit sie beim Kopieren und Einfügen von regulären Ausdrücken hier aus dem Tutorial nicht ungewollt deaktiviert werden. In OpenRefine benötigen wir diese Optionen für unser Tutorial nicht.

Aufgabe 1: Zeichenauswahl (Character Classes)

Wir wollen die Datumsangaben extrahieren. Diese haben das Muster Jahreszahl-Monat-Tag bzw. ZahlZahlZahlZahl-ZahlZahl-ZahlZahl. Ein erster Ansatz ist es, dies direkt zu formulieren.

/(0|1|2|3|4|5|6|7|8|9)(0|1|2|3|4|5|6|7|8|9)(0|1|2|3|4|5|6|7|8|9)(0|1|2|3|4|5|6|7|8|9)-(0|1|2|3|4|5|6|7|8|9)(0|1|2|3|4|5|6|7|8|9)-(0|1|2|3|4|5|6|7|8|9)(0|1|2|3|4|5|6|7|8|9)/gm

Mit dem Pipe-Symbol | können wir in regulären Ausdrücken Alternativen formulieren. Also zum Beispiel 0|1. Mit den runden Klammern ( und ) können wir die Alternativen gruppieren.

Dies ist etwas umständlich und unleserlich. Daher gibt es in regulären Ausdrücken auch ein Muster zur Zeichenauswahl, welches die eckigen Klammern [ und ] verwendet. Mit den Character Classes lässt sich der obige Ausdruck vereinfachen zu:

/[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]/gm

Die Zeichenauswahl lässt sich kombinieren und limitieren. So lassen sich Zahlen im Hexadezimalsystem identifizieren mit [0-9A-F].

Aufgabe: Passen Sie den obigen regulären Ausdruck so an, dass das erste Zeichen der Jahreszahl des Datums nur eine 1 oder 2 sein darf.

Lösung:

/[1-2][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]/gm
/(1|2)[0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]/gm

Aufgabe 2: Zeichenklassen (Shape Matching)

Alternativ zu der recht flexiblen Zeichenauswahl gibt es vordefinierte Zeichenklassen, die es einfacher machen, die Form des Musters zu beschreiben.

Klasse	Steht für	Zeichenauswahl	Beschreibung
`\d`	digit	`[0-9]`	Beliebige Zahl
`\w`	word	`[a-zA-Z0-9_]`	Buchstaben in Groß- oder Kleinschreibung, Zahlen und Unterstrich.
`\s`	space		Leerraum: Leerzeichen, Tabulator, …
`\b`	boundary		Wortgrenze, erfasst kein separates Zeichen.

Mit der Klasse \d für Zahlen sieht der reguläre Ausdruck aus Aufgabe 1 wie folgt aus:

/\d\d\d\d-\d\d-\d\d/gm

Aufgabe: Passen Sie den obigen regulären Ausdruck so an, dass er (nur) auf das Datumsformat 2005-1-1 passt.

Lösung:

/\d\d\d\d-\d-\d/gm

Aufgabe 3: Verneinungen

Die Zeichenauswahl oder Zeichenklasse lässt sich auch negieren. Bei der Zeichenauswahl funktioniert das mit dem Sonderzeichen ^, bei den Zeichenklassen durch Großschreibung.

Negierte Zeichenauswahl für Zahlen: [^0-9]
Negierte Zeichenklasse für Zahlen: \D

Aufgabe: Negieren Sie die regulären Ausdrücke für das Datum aus Aufgabe 1 und Aufgabe 2.

Lösung:

/[^0-9][^0-9][^0-9][^0-9]-[^0-9][^0-9]-[^0-9][^0-9]/gm
/\D\D\D\D-\D\D-\D\D/gm

Aufgabe 4: Quantoren (Quantifiers)

Anstatt Zeichen, Zeichenauswahl oder Zeichenklassen wiederholt zu schreiben, lassen sich Wiederholungen auch durch Quantoren definieren.

Quantor	Alternative	Beschreibung
`{2,}`		Mindestens zweimal
`{1,2}`		Mindest einmal, höchstens zweimal
`?`	`{0,1}`	Kann vorkommen
`+`	`{1,}`	Kann sich wiederholen
`*`	`{0,}`	Kann vorkommen und sich wiederholen

Ein möglicher regulärer Ausdruck für unsere Daten wäre also:

/\d{4}-\d\d?-\d\d?/gm

Aufgabe: Schreiben Sie den obigen regulären Ausdruck so um, dass er den ? Quantor nicht mehr verwendet.

Lösung:

/\d{4}-\d{1,2}-\d{1,2}/gm

Aufgabe 5: Gruppierungen (Group Constructs)

Mit den runden Klammern ( und ) lassen sich Gruppen in regulären Ausdrücken definieren. Das ist nicht nur hilfreich, wenn man mit dem Pipe Symbol | Alternativen definieren möchte, sondern auch um einzelne Bestandteile zu markieren.

Setzen wir die einzelnen Bestandteile des regulären Ausdrucks in runde Klammern, dann zeigt uns RegEx101 wie in Abbildung 3 in Gruppe 1 die Jahreszahl, in Gruppe 2 den Monat und in Gruppe 3 den Tag. Auch bei der Verwendung von regulären Ausdrücken in OpenRefine können wir auf die einzelnen Gruppen zugreifen.

/(\d{4})-(\d{1,2})-(\d{1,2})/gm

Bildschirmfoto von RegEx101 mit den extrahierten Gruppen.

Die einzelnen Gruppen können auch benannt werden um dann wie in Abbildung 4 über den Gruppennamen aufgerufen werden.

/(?<Jahr>\d{4})-(?<Monat>\d{1,2})-(?<Tag>\d{1,2})/gm

Bildschirmfoto von RegEx101 mit den benannten Gruppen.

Aufgabe: Erstellen Sie einen regulären Ausdruck mit den zwei benannten Gruppen Datum und Event. Das erwartete Ergebnis ist in Abbildung 5 gezeigt.

Bildschirmfoto von RegEx101 mit den erwarteten Ergebnissen.

Lösung:

/(?<Datum>\d{4}-\d{1,2}-\d{1,2}) (?<Event>[a-zA-Z0-9 ]+)/gm
/(?<Datum>\d{4}-\d{1,2}-\d{1,2}) (?<Event>.+)/gm

In OpenRefine 3.5, 3.6 und 3.7 werden benannte Gruppierungen nicht überall unterstützt. Beispielsweise wird bei find() immer nur der vollständige Treffer zurückgegeben und bei match() die Gruppen ausschließlich durchnummeriert. Lediglich bei replace() lässt sich auf die benannten Gruppen zugreifen.

Der folgende GREL Ausdruck nutzt benannte Gruppen um mit replace() die Reihenfolge des Datums umzudrehen:

value.replace(/(?<Jahr>\d{4})-(?<Monat>\d{1,2})-(?<Tag>\d{1,2})/, "${Tag}-${Monat}-${Jahr}")

Aufgabe 6: Look-around (Look-ahead/Look-behind)

Manchmal möchte man die Daten weiter einschränken.

Hier ein einfaches Beispiel um nur Daten aus dem Jahr 2022 zu extrahieren:

/2022-\d{1,2}-\d{1,2}/gm

Aufwendiger wird es, wenn ein Datum nur extrahiert werden soll, wenn ein bestimmter Begriff dahinter steht. Dies funktioniert mit so genannten Look-around Anweisungen. Man kann via positive Look-ahead (?=...) definieren, dass ein Begriff nach einem Muster vorkommen soll und via positive Look-behind (?<=...) kann definiert werden, dass ein Begriff vor einem Muster vorkommen soll.

So findet der folgende reguläre Ausdruck alle Daten unserer Einsteigerworkshops, ohne den Begriff “Einsteigerworkshop” mit in das Ergebnis aufzunehmen:

/\d{4}-\d{1,2}-\d{1,2}(?= Einsteigerworkshop)/gm

Die Look-around Anweisungen lassen sich auch verneinen, indem man das Gleichheitszeichen = durch ein Ausrufezeichen ! austauscht. So findet der folgende reguläre Ausdruck mit einem negative Look-ahead (?!...) alle Daten von nicht Einsteigerworkshops:

/\d{4}-\d{1,2}-\d{1,2} (?!Einsteigerworkshop)/gm

Aufgabe: Extrahieren Sie die Titel aller drei Workshops im Jahr 2022. Nutzen Sie dazu eine positive Look-behind Anweisung (?<=...).

Hinweise:

Quantoren wie +, *, ?, {1,9} werden in Look-around Gruppen nicht überall unterstützt! Das kommt auf die benutzte Programmiersprache, deren Version und/oder verwendeten Zusatzbibliotheken an. Daher im Zweifel erst einmal testen!
Look-around Anweisungen verlangsamen die Auswertung eines regulären Ausdrucks deutlich und sollten daher mit Bedacht eingesetzt werden.

Lösung:

/(?<=2022-\d\d-\d\d )(?<Titel>[a-zA-Z0-9 ]+)/gm

Aufgabe 7: Datums Einschränkungen

Mit einer Kombination von Alternativen, Gruppierungen, Zeichenauswahl und Quantoren lässt sich auch ein regulärer Ausdruck entwickeln, der ausschließlich valide Datumsangaben zwischen 1900 und 2029 extrahiert.

/(?<Jahr>19\d\d|20[0-2]\d)-(?<Monat>0?\d|1[0-2])-(?<Tag>[0-2]?\d|3[0-1])(?=\s)/gm

Auch wenn er fachlich und technisch richtig ist, welche Probleme treten bei diesem regulären Ausdruck eventuell auf?

Hinweise:

Der reguläre Ausdruck ist sehr komplex und schwer zu verstehen.
Überflüssig da es ggf. gar keine invaliden Datumsangaben gibt?
Ggf. möchte man falsch geschriebene Daten explizit mit in die Ergebnisse aufnehmen und nachkorrigieren?
Ggf. Datumsangaben vor 1900 oder nach 2029 übersehen?
Unterscheidet nicht zwischen Monaten mit 28/30 und 31 Tagen.
…

Aufgabe 8: Spezielle Zeichen

Es gibt eine Liste mit speziellen Zeichen, die bei Vorkommen in einem regulären Ausdruck mit einem Backslash \ escaped werden müssen um sie zu deaktivieren.

Zeichen	Bedeutung
`.`	Wildcard, beliebiges Zeichen
`^`	Zeilenbeginn oder Verneinung
`$`	Zeilenende
`\`	Escapezeichen
`+`	Quantor
`*`	Quantor
`?`	Quantor
`{`, `}`	Quantor
`(`, `)`	Gruppe
`[`, `]`	Zeichenklasse

Der folgende reguläre Ausdruck passt zum Beispiel auf Zeilen, in denen nur ein Datum steht.

/^\d{4}-\d{1,2}-\d{1,2}$/gm

Aufgabe: Schreiben Sie einen regulären Ausdruck, der in dem folgenden Text ausschließlich Dezimalzahlen in englischer Schreibweise mit Punkt . als Trennzeichen extrahiert.

Der Literpreis für Diesel ist erstmals über 2.00 Euro gestiegen.

Siehe auch Code AFE2A00F.

Lösung:

/\d+\.\d+/gm

Aufgabe 9: Reguläre Ausdrücke in OpenRefine

In OpenRefine kann anstelle von Text auch häufig ein regulärer Ausdruck verwendet werden. Zum Beispiel beim Suchen via Textfilter, dem Aufteilen von Spalten oder dem Replace-Dialog. Eine Liste der GREL Funktionen mit Unterstützung von regulären Ausdrücken gibt es in der OpenRefine Dokumentation.

Für diese Aufgabe wechseln wir zu OpenRefine und laden die Datei 08_kurzbiographien.csv in das Projekt “Kurzbiographien”.

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

Kurzbiographien als CSV

Die Datei 08_kurzbiographien.csv verwendet Texte von verschiedenen und in der Datei referenzierten Wikipedia Artikeln, die unter einer CC BY-SA 3.0 Lizenz veröffentlicht wurden. Die Datei 08_kurzbiographien.csv ist entsprechend ebenfalls lizenziert unter einer CC BY-SA 3.0 Lizenz.

Die Datei enthält aus Wikipedia gesammelte Kurzbiographien einiger Autoren einer bestimmten Literaturströmung.

Aufgabe: Wir wollen aus den Kurzbiographien mit Hilfe von regulären Ausdrücken vier neue Spalten erstellen: Geburtsdatum, Geburtsort, Sterbedatum und Sterbeort.

Bonusfrage: zu welcher Literaturströmung gehören die Autoren?

Hinweise:

Um mit einem regulären Ausdruck nur einen Teil der Daten aus einer Spalte in eine neue zu überführen bietet sich der “Add column based on this column…” Dialog und die GREL Funktion find() an.
Der GREL Ausdruck value.find(/\d{4}/)[0] findet beispielsweise alle Jahreszahlen in Form einer Liste (technisch Array) zurück und wir extrahieren mit [0] das erste Element.
Reguläre Ausdrücke werden in OpenRefine Funktionen mit /.../ eingefasst.

Lösung:

Es gibt unterschiedliche Lösungswege, hier ist eine recht einfache Variante aufgezeigt. Hierbei verzichten wir auf komplexe reguläre Ausdrücke und formulieren verständliche Einzelschritte.

Neue Spalte “Geburtsdatum” erstellen via “Kurzbiographie” “Edit column” “Add column based on this column…” und dem GREL Ausdruck value.find(/\*[^;]+/)[0].
Wiederhole Schritt 1 mit “Sterbedatum” und dem GREL Ausdruck value.find(/†[^\;)]+/)[0].
Die Spalte “Geburtsdatum” in zwei Spalten aufteilen via “Geburtsdatum” “Edit column” “Split into several columns…” und dem Seperator \s+in\s+ (Häkchen bei regular expression nicht vergessen).
Wiederhole Schritt 3 auf der Spalte “Sterbedatum”.
Spalten umbenennen
Unnötige Zeichen in Spalte “Geburtsdatum” ersetzen via “Geburtsdatum” “Edit cells” “Transform…” und dem GREL Ausdruck value.replace(/(\*\s*|†\s*)/, "") (alternativ geht das auch über den “Replace” Dialog).
Wiederhole Schritt 6 auf der Spalte “Sterbedatum”.

Alternative Lösung(en):

Wir verwenden match() und einen komplexen regulären Ausdruck um alle Datenbestandteile gleichzeitig zu extrahieren:

value.match(/.+\* (?<Geburtsdatum>\d{1,2}\. [a-zA-Zä]+ \d{4}) in (?<Geburtsort>[^;]+); † (?<Sterbedatum>\d{1,2}\. [a-zA-Zä]+ \d{4}) in (?<Sterbeort>[^;|\)]+).+/)

Diesen GREL Ausdruck können wir dann viermal mit “Kurzbiographie” “Edit column” “Add column based on this column…” anwenden und jeweils via value.match(...)[0] (Geburtsdatum) bis value.match(...)[3] (Sterbeort) die einzelnen Bestandteile für die jeweilige Spalte extrahieren.

Oder wir verwenden anstatt value.match(...)[...] die Funktion value.match(...).join(";") und teilen die neue Spalte anschließend an dem Trennzeichen ; in vier Spalten auf.

Oder wir extrahieren die Daten zuerst gemeinsam und transponieren sie anschließend, wie in Daten mit OpenRefine Transponieren beschrieben. Vor dem Transponieren müssen wir die Daten anhand von einem Zeilenumbruch \n in mehrere Zeilen aufteilen, die Spalte anhand von : in zwei Spalten aufteilen und mit “Edit cells” “Fill down” die restlichen Spalten auffüllen.

with(
 value.match(/.+\* (?<Geburtsdatum>\d{1,2}\. [a-zA-Zä]+ \d{4}) in (?<Geburtsort>[^;]+); † (?<Sterbedatum>\d{1,2}\. [a-zA-Zä]+ \d{4}) in (?<Sterbeort>[^;|\)]+).+/),
 v,
 "Geburtsdatum: " + v[0] +
 "\nGeburtsort: " + v[1] +
 "\nSterbedatum: " + v[2] +
 "\nSterbeort: " + v[3]
)

Aufgabe 10: Vorsicht bei Umlauten

Wie schon erwähnt basiert OpenRefine auf Java und in der hier im Tutorial eingesetzten OpenRefine Version 3.9.3 wird Java in Version 11 mitgeliefert. Eine Übersicht über alle von Java in dieser Version unterstützen Features von regulären Ausdrücken findet sich in der Java 11 Dokumentation zu RegEx Pattern. Die Unicode Unterstützung ist bei den Mustern in Java 11 optional und muss daher separat aktiviert werden. Das hat zur Folge, dass “Sonderzeichen” wie unsere Umlaute äöü, oder die in der französischen Sprache gebräuchlichen Buchstaben mit Akzenten éêè, nicht von den Mustern [a-z] oder \w berücksichtigt werden.

Um zum Beispiel auch Umlaute zu berücksichtigen gibt es mehrere Möglichkeiten:

Umlaute explizit auflisten: [a-zäöüß]
Spezielle Klasse für Buchstaben (letter) verwenden: \p{L}
Spezielle Klasse für alphabetische Zeichen verwenden: \p{IsAlphabetic}
Unicode Modus mit inline Flag aktivieren: (?U)\w

Aufgabe: Kopieren Sie den folgenden GREL Ausdruck in einen GREL Dialog und ersetzen Sie ... mit den oben genannten Möglichkeiten auch Unicode-Zeichen zu berücksichtigen.

"abcöüßéêè€$123!-".find(/.../)

Hinweise:

In RegEx101 wird bei der Auswahl des Flavors Java 8 die Unicode Unterstützung über das U Flag nach dem regulären Ausdruck aktiviert. Inline Flags werden dort nicht unterstützt.
In OpenRefine wird U nur als inline Flag und nicht als Regex Flag unterstützt.

Fazit

Bei der Verwendung von regulären Ausdrücken sollte stets die Balance zwischen Genauigkeit und Trefferquote im Hinterkopf behalten werden. Liegt die Priorität darauf nur genau die Daten zu finden, die einem sehr präzisen Muster folgen? Oder formulieren wir das Muster eher unpräzise und filtern die überflüssigen Treffer in einem separaten Schritt?

Wie bei der Lösung zur Aufgabe 9 angesprochen, ist es manchmal einfacher und verständlicher die Arbeiten in mehrere einfache Schritte zu teilen, anstatt sie in einem komplexen Schritt zu formulieren. Also zum Beispiel Geburtsdatum und Geburtsort zusammenhängend zu extrahieren und dann aufzusplitten, anstatt komplexe reguläre Ausdrücke für ein Geburtsdatum und den Geburtsort separat zu formulieren.

Im nächsten Teil beschäftigen wir uns mit der Programmiersprache GREL.

09 Arbeiten mit GREL

Workshop - Daten mit OpenRefine Transponieren

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

OpenRefine kann Zeilen und Spalten tauschen. Diese Transposition kann sowohl auf dem kompletten Datensatz, als auch nur auf einer Auswahl an Spalten durchgeführt werden. In diesem Tutorial besprechen wir zwei Varianten des Transponierens.

Einführung

Transponieren in der OpenRefine Dokumentation.

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

In der Praxis kommt es vor, dass wir Daten in Spalten organisiert bekommen, die wir eigentlich zeilenweise benötigen, oder umgekehrt. In der nächsten Tabelle ist ein Ausschnitt von Daten zu Politikern im Kabinett Kretschmann III gezeigt, mit dem wir im Laufe dieser Aufgabe arbeiten werden. Die Daten sind in Spalten gespeichert.

GND-ID	Name	Geschlecht	Geburtsdatum	Geburtsort
143926683	Kretschmann, Winfried	Männlich	1948-05-17	Spaichingen
122189930	Hermann, Winfried	Männlich	1952	Rottenburg am Neckar
…	…	…	…	…

In der nächsten Tabelle sind die gleichen Daten zeilenweise gespeichert. Mit der zusätzlichen “GND-ID” Spalte, die wir nicht mittransponiert haben, ergibt sich dadurch eine Record-Struktur, wie wir sie im letzten Teil des Workshops kennen gelernt und besprochen haben.

GND-ID	Schlüssel	Wert
143926683	Name Geschlecht Geburtsdatum Geburtsort	Kretschmann, Winfried Männlich 1948-05-17 Spaichingen
122189930	Name Geschlecht Geburtsdatum Geburtsort	Hermann, Winfried Männlich 1952 Rottenburg am Neckar
…	Name Geschlecht Geburtsdatum Geburtsort	…

Mit der Option Daten in OpenRefine zu transponieren, können wir Daten in den oben gezeigten Formaten ineinander umwandeln.

Vorbereitung: Projekt erstellen

Die folgende Datei in ein OpenRefine-Projekt laden.

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

Kretschmann III als CSV

Die importierten Daten sind in Abbildung 1 gezeigt.

Bildschirmfoto der Daten nach dem Import.

Aufgabe 1: Transponieren ohne Schlüsselspalte

Wir transponieren in dieser Aufgabe die in Abbildung 1 abgebildeten Daten in ein zeilenweises Datenformat. Dabei lassen wir die Spalte “GND-ID” stehen um anschließend eine Record-Struktur zu erzeugen.

Zum Transponieren gehen wir in den zugehörigen Dialog via “Name" "Transpose" "Transpose cells across columns into rows…” und wählen dort die zu transponierenden Spalten aus. Wie in Abbildung 2 geben wir als Zielformat an, dass wir die Daten in einer Spalte (One column) zusammengefasst bekommen möchten.

Bildschirmfoto des Dialoges zum Transponieren in eine Spalte.

Das Ergebnis ist in Abbildung 3 gezeigt. Wir haben nun eine Record-Struktur mit der GND-ID als Identifikator und allen zugehörigen Daten in einem Record-Feld.

Bildschirmfoto der Daten nach dem Transponieren in eine Spalte.

Der Schritt von einer zeilenweiser Speicherung zurück zu Spalten geht über “Daten" "Transpose" "Transpose cells in rows into columns…”. In dem Dialog geben wir 4 Zeilen zum Transponieren an. Das Ergebnis ist in Abbildung 4 gezeigt.

Bildschirmfoto der Daten nach dem Transponieren von einer Spalte.

Hier sind auch schon zwei Nachteile beim Transponieren ohne Schlüssel zu sehen:

Die Spalten müssen nachgearbeitet werden (Name ändern, Präfix entfernen).
Die Daten müssen einheitlich sein, also gleiche Anzahl an Elementen und gleiche Sortierung, da die Umwandlung sonst “verrutscht”.

Aufgabe 2: Transponieren mit Schlüsselspalte

Wir machen die Änderungen rückgängig und stellen den in Abbildung 1 gezeigten Ursprungszustand des Projektes wieder her.

Diesmal transponieren wir die Daten in zwei Spalten, indem wir eine separate Schlüsselspalte erzeugen lassen. Dies funktioniert über den gleichen Dialog wie in Aufgabe 1 über “Name" "Transpose" "Transpose cells across columns into rows…”. Die Einstellungen sind in Abbildung 5 gezeigt.

Bildschirmfoto des Dialoges zum Transponieren in zwei Spalten.

Das Ergebnis der Umwandlung ist in Abbildung 6 gezeigt. Wir haben eine Record-Struktur mit der GND-ID als Identifikator und allen zugehörigen Daten in einem Record-Feld.

Bildschirmfoto der Daten nach dem Transponieren in zwei Spalten.

Bevor wir von diesem Format zu einem Spaltenformat kommen, müssen wir zuerst die Records auflösen. Wir haben in diesem Datensatz nur eine Spalte (“GND-ID”) mit leeren Feldern, also genügt es diese über “GND-ID" "Edit cells" "Fill down” aufzufüllen.

Anschließend können wir diesmal über “Schluessel" "Transpose" "Columnize by key/value columns…” mit den in Abbildung 7 gezeigten Einstellungen wieder zum Ursprungsformat zurückgelangen.

Bildschirmfoto des Dialoges zum Transponieren von Schlüssel/Werte Spalten.

Diesmal benötigen wir anschließend keine Anpassungen oder im Vorfeld schon sortierte Daten. Lediglich die Schlüssel in der Spalte “Schluessel” sollten einheitlich geschrieben sein.

Aufgabe 3: Transponieren ausgewählter Spalten

Eine weitere praktische Anwendung des Transponierens liegt vor, wenn man mehrere Spalten von einem Typ hat, die man in einem Arbeitsgang zum Beispiel via Clustering vereinheitlichen oder mit einer Normdatenquelle abgleichen möchte. Für diese Aufgabe wurden exemplarisch die Daten des bisher verwendeten Datensatzes mit den jeweiligen Wirkorten der Politikerinnen und Politikern ergänzt. Das Ergebnis nach dem Import wird in Abbildung 8 gezeigt.

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

Kretschmann III als CSV

Bildschirmfoto der Daten mit mehreren Ortsspalten.

Um alle Orte in der Tabelle in einem Arbeitsgang mit z.B. der GND abzugleichen, müssen wir die Daten der einzelnen Spalten in eine gemeinsame Spalte überführen. Dabei müssen wir uns merken, aus welcher Spalte die einzelnen Orte kommen, um sie nach dem Abgleich wieder zurück schreiben zu können.

Hierfür eignet sich ebenfalls das Transponieren. Die Voraussetzung dafür ist, dass die zu transponierenden Spalten alle direkt nacheinander gelistet sind. Dies lässt sich relativ komfortabel mit “ALL" "Edit columns" "Re-order / remove columns…” erledigen.

Anschließend werden nur die Ortsspalten über “Geburtsort" "Transpose" "Transpose cells across columns into rows…” zusammengeführt. Die Einstellungen sind in Abbildung 9 gezeigt.

Bildschirmfoto des Dialoges zum Transponieren von Spalten in Zeilen.

Hierbei nicht vergessen, den Haken bei “Fill down in other columns” zu setzen. Das spart das spaltenweise Auffüllen der einzelnen Spalten vor der Rückumwandlung. Das Ergebnis nach der Umwandlung ist in Abbildung 10 gezeigt.

Bildschirmfoto der Daten mit den zusammengefassten Ortsspalten.

Nach dem Abgleich werden die Daten mit wie in Abbildung 11 gezeigt wieder in das Spaltenformat umgewandelt.

Bildschirmfoto des Dialoges zum zurückführen der Zeilen in Spalten.

Das Ergebnis der Rückumwandlung ist in Abbildung 12 gezeigt. Bei Bedarf kann man die Ortsspalten jetzt wieder einsortieren und/oder für jede Ortsspalte eine GND-ID Spalte hinzufügen mit “Ortsspalte" "Reconcile" "Add entity identifiers column…”.

Bildschirmfoto mit den mit der GND abgeglichenen Daten.

Automatischer Fill-down

Sollte man beim Umwandeln in das Zeilenformat vergessen haben, den Haken bei “Fill down in other columns” zu setzen, dann kann man das noch spaltenweise mit “Spaltenname" "Edit cells" "Fill down” nachholen.

Hat man sehr viele Spalten, so kann man stattdessen via “ALL" "Transform…” den folgenden GREL Ausdruck verwenden.

if(isBlank(value), row.record.cells[columnName][0].value, value)

Dabei ist darauf zu achten, dass man die ID-Spalte entweder auslässt und separat auffüllt, oder die ID-Spalte bei der Massenbearbeitung via “Drag&Drop” ans Ende verschiebt. Ansonsten ändert sich die “Record”-Struktur, bevor alle Spalten befüllt wurden und der GREL-Ausdruck funktioniert nicht mehr.

Alternative für GND-ID Spalten

Hat man sehr viele Ortsspalten, dann lässt sich die Erzeugung der GND-ID-Spalten auch etwas automatisieren.

Nachdem man die Daten mit der GND abgeglichen hat (also bevor man die Zeilen wieder in Spalten überführt), ergänzt man die GND-Nummer im Namen des Ortes über “Ort" "Edit cells" "Transform…” und dem folgenden GREL Ausdruck.

value + "||" + cell.recon.match.id

Anschließend werden die Werte via “Ort" "Edit cells" "Split multi-valued cells…” und den Trennzeichen || in mehrere Zeilen aufgeteilt.

Der zukünftige Spaltenname wird ergänzt via “Ortstyp" "Edit cells" "Transform…” und dem folgenden GREL Ausdruck.

if(isBlank(value), row.record.cells[columnName][0].value + " (GND-ID)", value)

Das Ergebnis sieht dann wie in Abbildung 13 aus. Dort müssen jetzt noch die restlichen Spalten vor der Umwandlung in das auf Spalten basierte Format zum Beispiel mit “Fill down” aufgefüllt werden

Bildschirmfoto ergänzten Zeilen für die zukünftigen GND-ID Spalten.

Fazit

Transponieren in OpenRefine hat noch weitere Features, wie zum Beispiel die Berücksichtigung von extra Spalten, mehreren Werten und separaten Spalten für Notizen. Dabei ist OpenRefine gerade beim Unwandeln von zeilenweisen Daten in spaltenweise sehr sensibel gegenüber der Sortierung der Werte in der Schlüsselspalte und ggf. weiteren Spalten, die nicht mit umgewandelt werden sollen.

Ein typischer Fehler ist zum Beispiel die Umwandlung von “Records” mit “Columnize by key/value columns” ohne die “Records” vorher mit “Fill down” aufzulösen. Das führt dazu, dass “Leer” als eigener Wert berücksichtigt wird und OpenRefine die Daten dadurch wie in Abbildung 8 sehr unerwartet sortiert.

Bildschirmfoto des Ergebnisses von Aufgabe 2 ohne ‘Fill down’.

Im nächsten Teil ergänzen wir mit OpenRefine ein Projekt mit Daten aus anderen Projekten.

12 Daten zwischen Projekten in OpenRefine abgleichen

Workshop - Daten zwischen Projekten in OpenRefine abgleichen

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

Daten können zwischen OpenRefine Projekten abgeglichen werden. In diesem Tutorial zeigen wir wie das funktioniert.

Einführung

cross() in der OpenRefine Dokumentation.
cross() im OpenRefine Wiki.

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

Im Artikel Gemeinsam an OpenRefine-Projekten arbeiten haben wir verschiedene Varianten, Daten zwischen OpenRefine Projekten abzugleichen, besprochen und verglichen. In diesem Tutorial fokussieren wir uns auf die Funktion cross() in OpenRefine, ohne über Alternativen und zukünftige Entwicklungen zu spekulieren.

Vorbereitung: Projekt erstellen

Die folgenden Dateien jeweils in ein OpenRefine-Projekt laden.

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

Staedte in BW

Staedte in BW - Geokoordinaten

In der Datei für das Projekt “Staedte in BW” sind Informationen aus Wikidata und der GND zu den 25 bevölkerungsreichsten Städten in Baden-Württemberg gesammelt.

In der Datei für das Projekte “Staedte in BW - Geokoordinaten” sind Geokoordinaten für Städte in Baden Württemberg gesammelt. Mit diesen beiden Projekten testen wir in den folgenden Aufgaben den Datenabgleich.

Das Projekt “Staedte in BW” verwenden wir in 13 Die Welt der Facets noch einmal.

Aufgabe 1: Daten via Name abgleichen

Im Projekt “Staedte in BW” wollen wir die passenden Geokoordinaten für die einzelnen Städte aus dem Projekt “Staedte in BW - Geokoordinaten” nachladen. Dafür gehen wir im Projekt “Staedte in BW” über “Stadt" "Edit column" "Add column based on this column…” und verwenden den folgenden GREL Ausdruck.

cell.cross(
 "Staedte in BW - Geokoordinaten",
 "Name")
 .cells["Geokoordinaten (WGS 84)"]
 .value[0]

Dabei benötigen wir den exakten Projektnamen des Projektes aus dem wir die Daten nachladen wollen (“Staedte in BW - Geokoordinaten”), die Spalte in dem anderen Projekt mit der unsere Spalte “Stadt” abgeglichen werden soll (“Name”) und den Namen der Spalte in dem anderen Projekt, die wir “nachladen” wollen (“Geokoordinaten (WGS 84)”). Der Dialog ist in Abbildung 1 gezeigt.

Bildschirmfoto des Dialogs zum Abgleich mit einem anderen Projekt über die Spalte Stadt.

Aufgabe: in der Vorschau in Abbildung 1 ist zu sehen, dass für “Freiburg im Breisgau” keine Daten nachgeladen werden konnten. Warum ist das so? Gibt es noch weitere “problematischen” Einträge? Was bedeutet das für einen Abgleich über “Namen”?

Lösung:

Im Projekt “Staedte in BW - Geokoordinaten” sind die Namen der Städte “Freiburg im Breisgau” und “Esslingen am Neckar” abgekürzt.
Ein Abgleich über Namen scheitert manchmal an unterschiedlichen Schreibweisen.
Wenn möglich also besser eindeutige IDs verwenden.
Siehe auch Gemeinsam an OpenRefine-Projekten arbeiten für weitere Details und mögliche Lösungsstrategien.

Aufgabe 2: Daten via ID abgleichen

Wir wiederholen die Aufgabe mit einem Abgleich über die Spalte “GND-ID”.

Aufgabe: Laden Sie im Projekt “Staedte in BW” die Spalte “Geokoordinaten (WGS 84)” aus dem Projekt “Staedte in BW - Geokoordinaten” über einen Abgleich mit der Spalte “GND-ID” nach.

Lösung:

Dafür gehen wir im Projekt “Staedte in BW” über “GND-ID” “Edit column” “Add column based on this column…” und verwenden den folgenden GREL Ausdruck.

cell.cross(
 "Staedte in BW - Geokoordinaten",
 "GND ID")
 .cells["Geokoordinaten (WGS 84)"]
 .value[0]

Bildschirmfoto des Dialogs zum Abgleich mit einem anderen Projekt über die Spalte GND-ID.

Aufgabe 3: Zeilen nachladen

OpenRefine arbeitet Spalten orientiert und erlaubt daher nur das Hinzufügen oder Nachladen von zusätzlichen Spalten. Manchmal möchte man einzelne Zeilen zum Beispiel aus einem anderen OpenRefine Projekt nachladen. Hier ist der einfachste Weg beide Projekte zu exportieren und in einem neuen Projekt gemeinsam zu importieren.

In seltenen Fällen ist dies unpraktisch, da man beispielsweise die Bearbeitungshistorie erhalten, oder nur einen Teil der Daten übernehmen möchte. Daher nutzen wir hier die Funktion cross() um Zeilen aus einem anderen Projekt nachzuladen.

Projekte erstellen

Wir verwenden noch einmal die CSV-Dateien 01_kretschmann-kabinett-frauen.csv und 01_kretschmann-kabinett-maenner.csv aus Aufgabe 2 in 01 Projekte in OpenRefine laden und verwalten.

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

Kretschmann Kabinett Frauen als CSV

Kretschmann Kabinett Maenner als CSV

Diesmal laden wir die Daten jeweils in ein eigenes Projekt mit dem Namen “Kretschmann Kabinett III - Frauen” bzw. “Kretschmann Kabinett III - Männer”.

Projekt 2: Spalte Abgleich erstellen

In dem Projekt “Kretschmann Kabinett III - Männer” erstellen wir via “Geschlecht" "Edit column" "Add column based on this column…” und dem folgenden GREL Ausdruck eine neue Spalte mit dem Titel “Abgleich”.

row.index

Über diese Spalte steuern wir, wie die beiden Projekte zusammengeführt werden sollen. So kann der Wert der Spalte “Abgleich” für Zeilen, die nicht übertragen werden sollen, wieder entfernt, bzw. gar nicht erst gesetzt werden.

Projekt 1: Spalte Abgleich erstellen

In dem Projekt “Kretschmann Kabinett III - Frauen” erstellen wir ebenfalls via “Geschlecht" "Edit column" "Add column based on this column…” und dem folgenden GREL Ausdruck eine neue Spalte mit dem Titel “Abgleich”.

with(7, rowsInProject,
 with(6, rowsToLoad,
 if(row.index + 1 == rowsInProject,
 "," + forRange(0, rowsToLoad, 1, v, v).join(","),
 ""
 )
 )
)

Dieser GREL Ausdruck schreibt nur in die letzte Zeile eine Aufzählung der Zeilennummern aus dem Projekt “Kretschmann Kabinett III - Männer”. Da wir (aktuell) nicht automatisch ermitteln können, wie viele Zeilen das aktuelle bzw. das abzugleichende Projekt hat, müssen wir diese Informationen via den Variablen rowsInProject und rowsToLoad selbst setzen. Das Ergebnis der Operation ist in Abbildung 2 gezeigt.

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

Projekt 1: Neue Zeilen erstellen

Anschließend erzeugen wir die neuen Zeilen via “Abgleich" "Edit Cells" "Split multi-valued cells…” auf dem Komma , als Trennzeichen. Das Ergebnis ist in Abbildung 3 gezeigt.

Bildschirmfoto des Projektes nach dem Hinzufügen der leeren Zeilen.

Projekt 1: Daten nachladen

Dann können wir mit dem folgenden GREL Ausdruck über “ALL" "Transform…” die zusätzlichen Zeilen nachladen. In dem folgenden Dialog können wir auch auswählen, auf welchen Spalten der GREL Ausdruck angewendet werden soll, und so auch nur spezifische Spalten nachladen. Das Ergebnis ist in Abbildung 4 gezeigt.

if(isNonBlank(row.cells["Abgleich"].value),
 row.cells["Abgleich"].cross("Kretschmann Kabinett III - Männer", "Abgleich").cells[columnName].value[0],
 value
)

Bildschirmfoto des Projektes nach dem Nachladen der Zeilen.

Die GREL Ausdrücke wurden hier absichtlich etwas komplexer gewählt, um zusätzliche Schritte wie Filtern zu vermeiden.

Fazit

Mit der Funktion cross() können ziemlich komfortabel Daten zwischen unterschiedlichen OpenRefine Projekten abgeglichen werden. Natürlich kann sie auch dazu verwendet werden Datenspalten innerhalb eines Projektes zu vergleichen. Die Funktion kann jedoch nur eindeutige Werte zusammenführen. Schon kleinste Abweichungen wie zusätzliche Leerzeichen oder Abkürzungen sorgen für einen fehlenden Abgleich der einzelnen Zeilen. Umso wichtiger ist ein sorgfältiges Arbeiten und die Verwendung von eindeutigen Identifikatoren.

Im nächsten Teil beschäftigen wir uns weiter mit Facets in OpenRefine.

13 Die Welt der Facets

Workshop - Die Welt der Facets in OpenRefine

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

Nachdem wir uns im Workshops für Einsteiger hauptsächlich mit den Text Facets in OpenRefine beschäftigt haben, betrachten wir in diesem Tutorial weitere nützliche Facets.

Einführung

Facets in der OpenRefine Dokumentation.
Reconciliation Facets in der OpenRefine Dokumentation.

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

Vorbereitung: Projekt erstellen

Wir verwenden das im Tutorial 12 Daten zwischen Projekten abgleichen erstellte Projekt “Staedte in BW”.

Aufgabe 1: Datentypen anpassen

Der Grundzustand des Projektes ist in Abbildung 1 gezeigt.

Bildschirmfoto des Projektes ‘Staedte in BW’ ohne Anpassungen.

An der schwarzen Farbe der Spalteninhalte erkennen wir, dass wir es hier ausschließlich mit Textspalten zu tun haben. Da wir in diesem Tutorial Facets für verschiedene Datentypen kennen lernen wollen, passen wir die Datentypen der einzelnen Spalten an.

Hierfür gibt es in OpenRefine schon Befehle, die wir im Spaltenmenü finden “…“ "Edit cells" "Common Transforms" ”…”

Aufgabe: Wir passen die Datentypen in den folgenden Spalten an:

Urkundlich erwaehnt: Datum (toDate)
Flaeche (km2): Zahl (toNumber)
Bevoelkerung (2021): Zahl (toNumber)
Weibliche Bevoelkerung (2021): Zahl (toNumber)
Maennliche Bevoelkerung (2021): Zahl (toNumber)

Das Ergebnis sollte dann aussehen wie in Abbildung 2.

Bildschirmfoto des Projektes ‘Staedte in BW’ nach Typanpassungen.

In der “All” Spalte gibt es Facets, die auf den ganzen Datensatz angewendet werden können. Neben den schon bekannten Facets zum Filtern von mit Sternen oder Flaggen markierten Zeilen sowie komplett leeren Zeilen gibt es auch Facets zum Filtern von leeren Einträgen in Spalten oder Records. In Abbildung 3 sind die beiden Facets für “Blank value per column” und “Non-blank value per column” gezeigt. Mit diesen Facets lassen sich schnell und übersichtlich Zeilen filtern, ohne das “Facet by blank” für jede Spalte separat aufzurufen.

Aufgabe: Überprüfen Sie die folgende Aussage.

“Alle Orte in diesem Datensatz ohne Angabe zum männlichen Bevölkerungsanteil haben auch keine Angabe zum weiblichen Bevölkerungsanteil.”

Aufgabe 3: Null oder Leer

Bei den einzelnen Spalten gibt es drei Facets zur Identifikation von leeren Zeilen. Das Äquivalent zu den in Aufgabe 2 vorgestellten Facets ist das “Facet by blank (null or empty string)”, welches in Abbildung 4 abgebildet ist. Das Facet wurde geöffnet mit “Urkundlich erwaehnt" "Facet" "Customized facets" "Facet by blank (null or empty string)”.

Aufgabe: Öffnen Sie auf der Spalte “Urkundlich erwaehnt” zusätzlich die Facets “Facet by null” und “Facet by empty string”. Worin unterscheiden sich die drei Facets?

Lösung:

OpenRefine unterscheidet zwischen nichts (null) und einem leeren Text (""), der ja zumindest vom Typ Text ist. Da wir aber häufig null und "" gemeinsam behandeln wollen, gibt es zusätzlich blank, was null und "" zusammenfasst.

OpenRefine bietet unterschiedliche visuelle Darstellungen für Zahlen in Facets an. In Abbildung 5 ist die Histogrammansicht gezeigt. Auf der X-Achse ist der Wertebereich abgebildet und auf der Y-Achse die Häufigkeit des entsprechenden Wertes. Der angezeigte Bereich lässt sich mit Schiebern an den Seiten einschränken.

Zusätzlich zu dem normalen “Numeric Facet” gibt es bei den “Customized Facets” noch eine logarithmische Darstellung (“Numeric log facet”) und eine begrenzte logarithmische Darstellung (“1-boundet numeric log facet”).

Eine andere Darstellung ist das “Scatterplot facet”, welches zuerst ein Streudiagramm über alle numerischen Spalten anzeigt (Abbildung 6) und durch Auswahl eines Streudiagramms dieses in die Facet Ansicht übernimmt (Abbildung 7).

Bildschirmfoto des Scatterplots über alle numerischen Spalten.

In dem Streudiagramm in Abbildung 7 lassen sich auch Werte und Bereiche mit der Maus auswählen und danach filtern.

Aufgabe: In dem Datensatz gibt es laut Streudiagramm eine Stadt mit einem leichten “Männerüberschuss”. Um welche Stadt handelt es sich dabei?

Lösung:

Bei der Stadt handelt es sich um Karlsruhe.

Es gibt ein separates Timeline Facet, welches auf eine Spalte vom Typ Datum (“date”) angewendet werden kann. Wie in Abbildung 8 zu sehen, ist das ähnlich wie beim “Numeric facet” ein Histogramm, nur dass die Daten auf der X-Achse nach Datum geordnet sind.

Da das bei Jahreszahlen auch recht schnell unübersichtlich wird, können wir so ein Facet auch selbst erstellen. Wir gehen dazu auf “Urkundlich erwaehnt" "Facet" "Custome Numeric Facet…” und verwenden den folgenden GREL-Ausdruck um das in Abbildung 9 gezeigte Facet zu erstellen.

value.datePart("year")

Aufgabe: Erstellen Sie ein Facet mit den Differenzen für “weibliche - männliche” Bevölkerung.

Lösung:

Dafür benötigen wir ein “Custom Numeric Facet” mit dem folgenden GREL-Ausdruck:

row.cells["Weibliche Bevoelkerung (2021)"].value -
row.cells["Maennliche Bevoelkerung (2021)"].value

Da wir in dem GREL Ausdruck die Spalten direkt aufrufen, ist es egal von welcher Spalte aus wir das Facet erstellen.

Aufgabe 6: Text Facets

Es gibt neben dem “normalen” Text Facet auch noch weitere Facets zum Umgang mit Text. In Abbildung 10 sind untereinander das “Text length facet”, das “Log of text length facet” und das “Unicode char-code facet” gezeigt.

Bildschirmfoto der Facets zu Textlängen und dem Unicode Zeichenbereich.

Ziemlich hilfreich bei Texten ist auch das in Abbildung 11 gezeigte “Word Facet”, welches alle in der Spalte vorkommenden Worte aufzählt.

In Abbildung 11 ist zum Beispiel bei “erwähnt,” zu sehen, dass das normale Wort Facet auch Satzzeichen berücksichtigt. Möchte man das vermeiden, so kann dies durch einen Klick auf das blaue “change” im Kopfbereich des Facets angepasst werden. Wir passen den GREL-Ausdruck wie folgt an und erhalten das in Abbildung 12 gezeigte Facet.

value.replace(/(?<=[a-z])[,.-]/, " ").split(' ')

Aufgabe: Erstellen Sie auf der Spalte “Kurzbiographie” ein Facet, welches alle darin vorkommenden Jahreszahlen darstellt.

Lösung:

Dafür benötigen wir ein “Custom Text Facet” mit dem folgenden GREL-Ausdruck:

value.find(/\d{3,4}/)

Es gibt spezielle Facets zur Unterstützung von Reconciliation Vorgängen. Zwei davon (“Jugment action type” und “Best candidate’s score”) werden automatisch geladen.

Es können weitere Facets nachgeladen werden. Dafür starten wir einen Reconciliation Vorgang über “Stadt" "Reconcile" "Start Reconciling” und verwenden als “Service” den “GND reconciliation for OpenRefine” Service von lobid (siehe 06 Reconciling mit OpenRefine und der GND für die grundlegende Einrichtung und Benutzung des Dienstes).

Wir suchen nach einem “Geografikum” und lassen gut passende Treffer automatisch auswählen. Die Einstellungen sind in Abbildung 13 abgebildet.

Bildschirmfoto der Einstellungen für den Reconciling Dialog.

Über “Stadt" "Reconcile" "Facets" ”…" können wir dann die restlichen Facets nachladen.

Gruppe 1: Entscheidung

By judgment (default)
Jugment action type
Jugment action timestamp

In der Gruppe 1 sind Facets zu den getroffenen Entscheidungen zu finden. Hier kann danach gefiltert werden, ob für eine Zeile schon eine Entscheidung getroffen wurde, ob die Entscheidung automatisch oder manuell getroffen wurde und sogar zu welchem Zeitpunkt (Zeitstempel) die Entscheidung getroffen wurde.

Gruppe 2: Treffer

Best candidate’s score (default)
Best candidate’s type match
Best candidate’s name match

Die zweite Gruppe bezieht sich auf die Treffer und zwar immer nur auf den “besten” Treffer. Hier gibt es das Standard Facet mit der Bewertung des Treffers durch den Reconciliation Service. Außerdem gibt es noch zwei Facets, welche nützlich sind, wenn man iterativ mehrere Reconciliation Versuche auf einer Spalte durchführt und dabei mit und ohne Typisierung sucht.

Gruppe 3: Treffer Ähnlichkeit

Best candidate’s name edit distance
Best candidate’s name work similarity

Der Algorithmus zur Auswahl von Treffern durch den Reconciliation Service ist häufig nicht transparent oder direkt nachvollziehbar. Daher lassen sich in OpenRefine zusätzliche Facets laden, die die Ähnlichkeit des Spalteninhalts mit dem jeweils besten Treffer anzeigen.

Die Editierdistanz basiert auf der Levenshtein Distanz, die wir schon in 05 Daten mit OpenRefine clustern kennen gelernt haben. Die Wortähnlichkeit hingegen wird berechnet, indem die Anzahl der übereinstimmenden Wörter ohne Stoppwörter zwischen Zellinhalt und bestem Treffer gezählt und normalisiert wird. Der Wertebereich geht dabei von 0 für keine Ähnlichkeit bis 1 für vollkommene Übereinstimmung.

Gruppe 4: Treffer Typ

Best candidate’s types

Die Liste der Typen, die sich aus dem jeweils besten Treffer für die einzelnen Zeilen ergeben.

Aufgabe: Beim Erstellen des Tutorials sind vier Städte automatisch mit einem Treffer gematcht worden. Ein Treffer ist jedoch falsch. Überlegen Sie, mit welcher Facet Kombination Sie diesen falschen Treffer schnell isolieren können.

Lösung:

Eine mögliche Kombination wäre im Facet “Jugment action type” den Wert auto auszuwählen und im Facet “Best candidate’s name edit distance” auf eine Distanz größer 1 zu filtern.

Der falsch zugeordnete Treffer ist dann “Freiburg im Breisgau”.

Da sich die Implementierung der Suchstrategie im lobid Reconciliation Server ändern kann, ist es möglich, dass Sie andere Ergebnisse erhalten.

Aufgabe 8: Duplikate

Das Duplikate Facet haben wir bewusst übersprungen und an das Ende verschoben.

Über “Urkundlich erwaehnt" "Facet" "Customized facets" "Duplicates facet” können wir uns Zeilen anzeigen lassen, deren Werte mehr als einmal vorkommen. Wir können hier aber keine Duplikate auswählen, markieren oder wie beim Clustern mit Ungenauigkeiten arbeiten.

Aufgabe: Überlegen Sie sich, wo das Duplikate Facet sinnvoll eingesetzt werden kann.

Mögliche Lösung:

Im FDMLab nutzen wir das Facet zur schnellen Überprüfung, ob zum Beispiel eine ID-Spalte nur eindeutige Werte beinhaltet.

Fazit

Mit Facets können wir uns durch die Daten filtern, sie für die explorative Datenanalyse verwenden oder beim Data Cleaning zu bearbeitende Gruppen identifizieren und diese gesammelt korrigieren. Mit einem Grundverständnis von GREL können wir uns selbst Facets programmieren oder den Code der voreingestellten Facets anpassen. In Kombination mit regulären Ausdrücken können wir auf spezifischen Mustern basierende Facets erstellen.

Da die Facets nicht selbst benannt werden können, gibt es jedoch das Risiko, sich in seinen eigenen Filtern zu verlaufen.

Im nächsten Teil beschäftigen wir uns mit dem Import und Export von XML in OpenRefine.

14 XML importieren und exportieren

Workshop - Erweiterter GND Abgleich mit lobid

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

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

Einführung

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

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

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

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

Aufgabe 1: Operatoren in der Weboberfläche

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

Beispiel 1: Maria oder Marie?

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

Versuch 1: Maria Marie.

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

Versuch 2: Maria OR Marie

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

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

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

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

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

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

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

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

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

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

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

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

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

Beispiel 2: Das nicht

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

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

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

Beispiel 3: Ungenaue Suche

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

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

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

Übersicht über die Operatoren

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

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

Aufgabe 2: Nutzung in OpenRefine

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

Bildschirmfoto des Reconciliation Dialogs in OpenRefine.

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

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

Kretschmann Kabinett III mit Fehlern

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

Bildschirmfoto des Projektes direkt nach dem Import.

Transformation 1: Name fuzzy

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

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

Transformation 2: Geburtsdatum reduzieren

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

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

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

Transformation 3: Geburtsort ergänzen

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

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

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

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

Bildschirmfoto des Projektes nach den Transformationen.

Abgleich durchführen

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

Bildschirmfoto der Einstellungen für den Reconciliation Dialog.

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

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

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

Bei unserem Experiment waren alle Treffer korrekt (true).

Weitere Operationen

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

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

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

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

Fazit

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

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

16 Erweiterter Abgleich mit Wikidata

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

Workshop - XML in OpenRefine importieren und exportieren

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

In diesem Tutorial beschäftigen wir uns mit dem Laden von XML in OpenRefine und dem Exportieren nach XML mit Templating.

Einführung

Templating in der OpenRefine Dokumentation.
Templating im OpenRefine Wiki.

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

Die als XML abgekürzte “Extensible Markup Language” kann sehr komplexe Datenformate abbilden. Von Textdokumenten über Grafikdaten zu Geodaten. Im GLAM Bereich begegnet uns XML in Standards wie EAD, METS, MODS, RiC, TEI, usw.

Zur Abbildung der komplexen Strukturen in XML verwendet OpenRefine die im Workshop schon besprochenen Records. Damit können aber nur baumartige Strukturen abgebildet werden und keine komplexen Netzwerke.

Um zu verstehen, wie OpenRefine XML einliest und ausgeben kann, verwenden wir exemplarisch ein einfaches Format.

<?xml version="1.0" encoding="utf-8"?>
<kabinett title="Kretschmann III">
 <person gnd-id="143926683" sex="m" birthday="1948-05-17" birthplace="Spaichingen">
 <name>Kretschmann, Winfried</name>
 <links>
 <link>http://dbpedia.org/resource/Winfried_Kretschmann</link>
 <!-- ... -->
 </links>
 </person>
 <!-- ... -->
</kabinett>

Das sind die Daten der Politiker des Kabinetts Kretschmann III, diesmal im XML Format. Die Personendaten sind teilweise in Attributen und teilweise als separates Element angelegt. Die Links auf weitere “Profile” sind als Sammlung unterhalb des <person> Elementes angelegt.

Aufgabe 1: XML Laden

Wir laden die folgende Datei in ein OpenRefine-Projekt.

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

Kretschmann III als XML

Der Import von XML-Daten beginnt mit einem anderen Dialog, als wir es gewohnt sind. Wie in Abbildung 1 gezeigt fragt OpenRefine nach dem ersten XML Element, welches als Record geladen werden soll. Wir wählen hier das <person> Element aus, da wir die Daten zu den Personen laden möchten. Die restlichen Daten, wie zum Beispiel das <kabinett> Element mit dem title Attribut werden dann verworfen.

Bildschirmfoto der Import Oberfläche für XML.

In Abbildung 2 ist das Projekt direkt nach dem Import abgebildet. Wir sind im “Record” Modus und aus jeder Person wurde ein “Record”. Die Links sind auf mehrere Zeilen aufgeteilt.

Interessant ist die automatische Benennung der Spalten:

Das Attribut gnd-id am Element <person> wurde in die Spalte person - gnd-id geladen.
Das Element <name> mit dem XML Pfad /kabinett/person/name wurde in die Spalte person - name geladen.
Die Linksammlung mit dem XML Pfad /kabinett/person/links/link wurde in die Spalte person - links - link geladen.

Bildschirmfoto der geladenen XML Datei.

Durch diese automatische Benennung lässt sich nachvollziehen, woher die Daten stammen und wie sie zusammengehören. Es bedeutet aber auch, dass wir die Spalten alle manuell umbenennen müssen.

Aufgabe: Benennen Sie die Spalten wie in Abbildung 3 gezeigt um.

Bildschirmfoto des Projektes mit korrekten Spaltennamen.

Aufgabe 2: XML exportieren (einfach)

Theoretisch könnten wir die Daten im Projekt jetzt mit weiteren Daten anreichern, umformatieren… Diesen Part überspringen wir und beschäftigen uns direkt damit, wie wir die Daten wieder als XML exportieren können.

Unser Zielformat sieht wie in folgendem Beispiel aus:

<?xml version="1.0" encoding="utf-8"?>
<personen>
 <person>
 <gnd-id>143926683</gnd-id>
 <name>Kretschmann, Winfried</name>
 <geschlecht>m</geschlecht>
 <geburtstag>1948-05-17</geburtstag>
 <geburtsort>Spaichingen</geburtsort>
 </person>
 <!-- ... -->
</personen>

Wir wollen also die Personendaten in einzelne Elemente speichern und erstmal auf die Links verzichten. Dafür wechseln wir in OpenRefine in den “Rows” Modus und filtern die zusätzlichen Link Zeilen via “GND-ID" "Facet" "Customized facets" "Facet by blank (null or empty string)”.

Anschließend gehen wir auf “Export" "Templating…” um den in Abbildung 4 gezeigten Dialog aufzurufen.

Bildschirmfoto des Templating Dialogs in OpenRefine.

Dieser Dialog besteht aus fünf Teilen:

Das “Prefix”, also der Text, der zu Beginn steht.
Das “Row Template”, also das Template für die einzelnen Zeilen.
Der “Row Separator”, also das Trennzeichen zwischen den einzelnen Zeilen.
Das “Suffix”, also der Text, der am Ende steht.
Eine Vorschau auf der rechten Seite.

Initial wird ein Template zum Erzeugen von JSON geladen. Im Template Feld sind GREL-Ausdrücke in geschweiften Klammern {{...}} zu sehen, die die Werte in den einzelnen Feldern mit der Funktion jsonize() in ein kompatibles Format umwandeln.

Für die Generierung von XML gehen wir ähnlich vor.

Die Vorschau ist teilweise recht aufwendig zu berechnen. Sollte es zu lange dauern, bis sie geladen wird, kann man die GREL-Ausdrücke in einem anderen Dialog-Fenster (zum Beispiel “Edit cells” “Transform”) testen und/oder zum Entwickeln die Anzahl an Einträgen via Facet (zum Beispiel “Facet by star”) reduzieren.

Prefix

Zu Beginn benötigen wir die XML Deklaration und das Wurzelelement <personen>, welche wir in das Feld “Prefix” schreiben.

<?xml version="1.0" encoding="utf-8"?>
<personen>

Suffix

Das Wurzelelement schließen wir im Feld “Suffix” und fügen davor zur besseren Lesbarkeit noch eine Leerzeile (Zeilenumbruch) hinzu.


</personen>

Row Separator

Um die einzelnen Zeilen zu separieren verwenden wir ebenfalls eine Leerzeile (Zeilenumbruch).

Row Template

Der aufwendigste Part ist die Erstellung eines Templates für die einzelnen Zeilen im Feld “Row Template”. Hierfür können wir in einem ersten Versuch die Vorlage des Zielformates in das Feld kopieren und die einzelnen Werte mit Variablen (Spaltenname) versehen.

 <person>
 <gnd-id>${GND-ID}</gnd-id>
 <name>${Name}</name>
 <geschlecht>${Geschlecht}</geschlecht>
 <geburtstag>${Geburtstag}</geburtstag>
 <geburtsort>${Geburtsort}</geburtsort>
 </person>

Die Variante mit Variablen funktioniert und ist gut zu lesen. Sie hat jedoch den Nachteil, dass einzelne Sonderzeichen in den Feldern (< oder > ) die Struktur des XML Dokumentes zerstören können. Um das zu verhindern, gibt es in GREL die Funktion escape().

Aufgabe: Schreiben sie die Vorlage so um, dass statt der Variablen analog zu dem JSON Template GREL Ausdrücke mit escape() verwendet werden.

Lösung:

 <person>
 <gnd-id>{{escape(cells["GND-ID"].value, "xml")}}</gnd-id>
 <name>{{escape(cells["Name"].value, "xml")}}</name>
 <geschlecht>{{escape(cells["Geschlecht"].value, "xml")}}</geschlecht>
 <geburtstag>{{escape(cells["Geburtstag"].value, "xml")}}</geburtstag>
 <geburtsort>{{escape(cells["Geburtsort"].value, "xml")}}</geburtsort>
 </person>

Aufgabe 3: XML exportieren (Records)

In Aufgabe 2 haben wir die Baumstruktur des Dokumentes ignoriert, also die Links weggelassen. Diesmal wollen wir die Links jedoch mit ausgeben. Dafür deaktivieren wir das in Aufgabe 2 erstellte Facet und wechseln in den “Record” Modus.

Unser Zielformat sieht wie folgt aus:

<?xml version="1.0" encoding="utf-8"?>
<personen>
 <person>
 <gnd-id>143926683</gnd-id>
 <name>Kretschmann, Winfried</name>
 <geschlecht>m</geschlecht>
 <geburtstag>1948-05-17</geburtstag>
 <geburtsort>Spaichingen</geburtsort>
 <links>
 <link>http://dbpedia.org/resource/Winfried_Kretschmann</link>
 <!-- ... -->
 </links>
 </person>
 <!-- ... -->
</personen>

Es unterscheidet sich also lediglich durch das zusätzliche Element <links>.

Leider gibt es bei den Vorlagen in OpenRefine keine direkte Unterstützung von “Records”, so dass wir uns mit GREL behelfen müssen. Wir bauen also das komplette Template durch eine Verkettung von Textschnippseln in GREL zusammen. Dafür verwenden wir die Kontrollstrukturen if und forEach.

Hier ist die allgemeine Idee für unseren Algorithmus:

Wir verarbeiten immer nur die erste Zeile eines Records.

if(row.index - row.record.fromRowIndex == 0, "<person>\n" + ... + "</person>", "")

Wir geben alle Spalten mit nur einer gefüllten Zeile im Record direkt aus.
```
"<gnd-id>" + escape(cells["GND-ID"].value, "xml") + "</gnd-id>\n"
```

Wir zählen Spalten mit mehr als einer Zeile im Record zeilenweise mit forEach auf.

forEach(row.record.cells["Links"].value, link, "<link>" + escape(link, "xml") + "</link>")
.join("\n")

Aufgabe: Erstellen Sie mit GREL ein Template, welches zusätzlich zu den Daten aus Aufgabe 1 auch die Links mit ausgibt.

Lösung:

{{
if(row.index - row.record.fromRowIndex == 0,
 "<person>\n"
 + "<gnd-id>" + escape(cells["GND-ID"].value, "xml") + "</gnd-id>\n"
 + "<name>" + escape(cells["Name"].value, "xml") +"</name>\n"
 + "<geschlecht>" + escape(cells["Geschlecht"].value, "xml") + "</geschlecht>\n"
 + "<geburtstag>" + escape(cells["Geburtstag"].value, "xml") + "</geburtstag>\n"
 + "<geburtsort>" + escape(cells["Geburtsort"].value, "xml") + "</geburtsort>\n"
 + "<links>\n"
 + forEach(row.record.cells["Links"].value, link, "<link>" + escape(link, "xml") + "</link>")
 .join("\n")
 + "\n</links>\n"
 + "</person>",
 ""
)
}}

Hinweis: Wir verzichten in diesem GREL Ausdruck auf Leerzeichen zur Formatierung des XML zur Einrückung der einzelnen Elemente. Wir haben die Erfahrung gemacht, dass die Lesbarkeit der GREL Ausdrücke darunter leidet. Einfacher ist es, bei Bedarf das XML anschließend in einem Editor wie Notepad++ oder Visual Studio Code mit den entsprechenden XML Erweiterungen automatisch formatieren und dabei auch gleich noch validieren zu lassen.

Fazit

Wir haben für diesen Workshop bewusst ein einfach strukturiertes XML Beispiel erstellt um direkt zu sehen, wie OpenRefine die XML Struktur verarbeitet und XML erstellen kann. Üblicherweise sind XML Dateien weitaus tiefer strukturiert und es dauert entsprechend länger, bis die Daten in OpenRefine passend benannt und sortiert sind. Auch der Export ist oft weitaus komplexer, zum Beispiel wenn Felder optional leer sein können oder es mehrere Verschachtelungen in den Records gibt. Jedoch sind die Strategien zur Lösung dieser Probleme (“Sortieren & Umbenennen” bzw. “if und forEach”) die gleichen wie hier im Beispiel besprochen.

Im nächsten Teil beschäftigen wir uns mit dem erweiterten Datenabgleich zwischen OpenRefine und der Gemeinsamen Normdatei via des lobid API.

15 Erweiterter GND Abgleich mit lobid

Workshop für Fortgeschrittene - Warum OpenRefine?

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

In diesem Workshop für Fortgeschrittene gehen wir tiefer in die spezialisierten Funktionalitäten von OpenRefine und beschäftigen uns mit angrenzende Themen. Unter anderem betrachten wir reguläre Ausdrücke und programmieren mit der General Refine Expression Language (GREL).

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

Inhalte des Workshops

Warum eigentlich OpenRefine für Fortgeschrittene?

OpenRefine is Excel on steroids!

Oder um einen bildlichen Vergleich eines Workshop Teilnehmers wiederzuverwenden:

Mit Excel hatten wir bisher einen Trabi.
Mit OpenRefine haben wir einen Ferrari bekommen.

Der Umgang mit einem solchen Werkzeug sollte jedoch geübt und vertieft werden. Viele Funktionalitäten von OpenRefine sind über die graphische Oberfläche bedienbar. Jedoch können einige Bearbeitungsschritte vereinfacht oder automatisiert werden. Im Workshop für Einsteiger haben wir uns auf grundlegende Funktionen von OpenRefine fokussiert. Diesmal vertiefen wir einige Konzepte oder ergänzen Sie mit weiteren Technologien.

Wir werden dabei unter anderem die Programmiersprache GREL kennen lernen. Diese ist bei weitem nicht so mächtig, wie zum Beispiel Java oder Python. Jedoch können wir damit schon einige Dinge automatisieren und vereinfachen.

Außerdem werden wir uns mit regulären Ausdrücken beschäftigen. Diese helfen uns Daten zu finden, die bestimmten Mustern entsprechen.

Im ersten Teil machen wir einen Exkurs zum Arbeiten mit regulären Ausdrücken zur Erkennung und Extraktion von Mustern.

08 Arbeiten mit regulären Ausdrücken

OpenRefine Workshop für Einsteiger veröffentlicht

Tue, 19 Apr 2022 00:00:00 +0000

Was hat denn der Osterhase hier im Blog entdeckt? Da ist seit Anfang April ein OpenRefine Workshop versteckt!

Wir haben schon 2021 im FDMLab einen an die Bedürfnisse im Archiv angepassten Workshop für OpenRefine entwickelt. Diesen internen Workshop haben wir anschließend zum Nachlesen oder selbst Lernen für den FDMLab Blog aufbereitet und online gestellt.

Im Workshop für Einsteiger geben wir eine grundlegende Einführung in die Bedienung mit OpenRefine. Dabei behandeln wir das Filtern, Sortieren und Umwandeln von Daten. Anschließend beschäftigen wir uns mit den Funktionalitäten von OpenRefine um Daten zu Clustern, mit der Gemeinsamen Normdatei (GND) oder Wikidata abzugleichen.

Link zum Einsteiger Workshop für OpenRefine

Im Mai veröffentlichen wir darauf aufbauend einen Workshop für Fortgeschrittene. Hier werden wir uns uns mit regulären Ausdrücken und der Programmiersprache GREL beschäftigen. Anschließend vertiefen wir die Arbeit mit OpenRefine im Kontext von Records und dem Umgang mit XML. Als Bonus lernen wir die erweiterten Suchoptionen beim Abgleich mit dem lobid GND API kennen.

Link zum Fortgeschrittenen Workshop für OpenRefine

Workshop - Daten mit OpenRefine clustern

Fri, 01 Apr 2022 00:00:00 +0000

Wir verwenden verschiedene Clustering Methoden in OpenRefine, um Schreibweisen zu vereinheitlichen.

Clustering in der OpenRefine Dokumentation.

Clustering im OpenRefine Wiki.

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

Hintergrund

OpenRefine implementiert unterschiedliche Methoden, um Cluster in Mengen von Werten zu finden. Dies hilft uns beim Vereinheitlichen von Werten, finden von Tippfehlern, usw.

Im folgenden Diagramm ist dargestellt, wie alle Vorkommen von “Michael Müller” in einer Liste von Namen zusammengefasst werden können. Ein einfaches Sortieren nach Namen genügt hier nicht, da “Michael Müller” unterschiedlich geschrieben wurde. Hier ist eine Deduplizierung erforderlich, wofür in OpenRefine Clustering eingesetzt werden kann.

--- title: Visualisierung Clustering config: look: handDrawn theme: neutral --- flowchart LR subgraph unsorted["Unsortiert"] mm1_1["Michael Müller"] mm1_2["Michael Müller"] mm1_3["Michael Müller"] mm2_1["Michael Mueller"] mm2_2["Michael Mueller"] mm3_1["Michel Müller"] end subgraph original["Sortiert (Original)"] mm1["3 x Michael Müller"] mm2["2 x Michael Mueller"] mm3["1 x Michel Müller"] end subgraph clustered["Zusammengeführt"] mm_finished["9 x Michael Müller"] end mm1_1 & mm1_2 & mm1_3 -.-> mm1 mm2_1 & mm2_2 -.-> mm2 mm3_1 -.-> mm3 mm1 & mm2 & mm3 -.-> mm_finished unsorted --Sortieren--> original --Deduplizieren--> clustered

Hier eine Übersicht über die verschiedenen Arten von Cluster-Verfahren und welche Probleme sie lösen. Die Zusammenfassung basiert auf Clustering In Depth aus dem OpenRefine Wiki und aus unseren Erfahrungen beim Clustering von Namen mit OpenRefine.

Fingerprint Verfahren (schnell)

Name	Beschreibung	Beispiel	Kommentar
Fingerprinting	Normalisiert und Sortiert auf Wortebene. Entfernt Satzzeichen!	Straßburg (Elsaß, Frankreich) Elsass (Frankreich), Strassburg Strassburg, Elsáss, Frankreich	Probleme mit kleinen Abweichungen.
N-Gram Fingerprinting	Normalisiert und sortiert auf Buchstabenebene	Paris = 1-gram => a i p r s Paris = 2-gram => ar is pa ri	Schnell und hilft z.B. bei Buchstabendrehern.

Die Fingerprinting Methoden sind sehr schnell und helfen bei typischen Problemen wie Wortreihenfolgen, unterschiedlicher Verwendung von Sonderzeichen oder Satzzeichen. OpenRefine bietet hier ein Verfahren auf Wortebene und eines auf Buchstabenebene an.

Hierbei ist zu beachten, dass schon kleine Abweichungen (ein zusätzliches/anders geschriebenes Wort) dazu führen, dass ein Text aus einem Cluster ausgeschlossen wird.

Phonetische Verfahren

Name	Sprache	Beispiel
Cologne-phonetic	Deutsch	Meier, Maier, Mayer, Mayr.
Metaphone3	Englisch	Reuben Gevorkiantz und Ruben Gevorkyants.
Daitsch-Moktoff	Slawisch und Jiddisch	Moskowitz und Moskovitz.
Beider-Morse	Slawisch und Jiddisch	Weniger Falsch-Positive als Daitsch-Moktoff.

Die phonetischen Verfahren berücksichtigen, dass manche Buchstaben in der gesprochenen Sprache die gleichen Laute erzeugen. Das ist gerade für Namen in historischen Dokumenten sinnvoll, da diese häufig nach Hörverständnis geschrieben werden.

OpenRefine hat Implementierungen für die deutsche Sprache in Form von Cologne Phonetic, für die englische Sprache in Form von Metaphone, und für slawische Sprachen und Jiddisch Daitsch-Moktoff und Beider-Morse.

Nearest-Neighbor-Verfahren (langsam)

Name	Beschreibung	Beispiel	Kommentar
Levensthein	$d(A, B) = repl + ins + del$	Seid, Christoph Seld, Christoph	Aufwendig Gut bei OCR Fehlern
Prediction by Partial Matching	$d(A, B) = \frac{compress(A, B) + compress(B, A)}{compress(A, A) + compress(B, B)}$	Streitt, Johann Konrad Streitter, Johann, Conrad	Aufwendig Falsch-Positive Braucht lange Texte

Die Levensthein Distanz berechnet die Ähnlichkeit zwischen zwei Texten, indem sie die notwendigen Änderungsoperationen (Ersetzungen, Einfügungen, Löschungen) zählt, die notwendig sind um zwei Texte ineinander zu überführen. Die Berechnung ist jedoch recht aufwendig. Dafür ist die Levensthein Methode hilfreich um Tippfehler oder OCR-Fehler zu identifizieren.

Bei Prediction by Partial Matching werden Kompressionsverfahren verwendet. Die Annahme dabei ist, dass Texte mit ähnlichen Inhalten (strukturell, nicht semantisch!) komprimiert ähnlich aussehen. Das ist gerade bei längeren Texten hilfreich, bei kurzen Texten (einzelne Worte) ist das Verfahren nicht so erfolgreich.

Probleme beim Clustering

Auch wenn man mit den Clustering Methoden schnell zu sinnvollen Ergebnissen kommt, gibt es einige Bereiche, für die es in OpenRefine (noch) keine Lösungen gibt, bzw. spezialisierte Clustering Methoden notwendig wären. Hier eine unvollständige Liste von separat zu behandelnden Problemen mit Beispielen:

Abkürzungen: w, weibl., weiblich
Synonyme: ledig, single, alleinstehend, frei, unverheiratet
Bestimmte OCR-Fehler: Fleinrich und Heinrich
Fehlende Zweitnamen: Speckmann, Johann Stefan
Fehlende Namensbestandteile: Albrecht (von Lauterburg) Johann Konrad
Alternative Schreibweisen: Greck, Leo und Greck (Gregk), Leo

Aufgabe 1: Clustering mit “fingerprint” Methoden

Die Spalte “Todesdatum (beschreibend)” sieht auf den ersten Blick recht aufgeräumt aus.

Wir testen auf dieser Spalte die Cluster-Methoden “fingerprint” und “ngram-fingerprint”. Den Dialog für das Clustering öffnen wir entweder über die Bedienfläche “Cluster” im “Text Facet” der Spalte, oder über das Spaltenmenü “Todesdatum (beschreibend)“ "Edit cells" "Cluster and edit…”.

Bildschirmfoto vom Clustering Dialog mit der ‘fingerprint’ Methode.

Wie in Abbildung 1 zu sehen, wird automatisch die “fingerprint” Methode ausgeführt, die auch gleich drei mögliche Cluster findet. Diese unterscheiden sich lediglich in der Reihenfolge der Satzstellung sowie Groß- und Kleinschreibung.

Wir führen diese Cluster noch nicht zusammen, sondern schauen uns noch die Ergebnisse der “NGram-Fingerprint” Methode an. Diese findet in den Standardeinstellungen hier keine Cluster, sondern erst, wenn wir, wie in Abbildung 2 markiert, die Größe auf 1 reduzieren.

Bildschirmfoto vom Clustering Dialog mit der ‘Ngram fingerprint’ Methode.

Aufgabe 2: Clustering mit phonetischen und “Nearest-Neighbor”-Methoden

Die Spalte “Familienverhältnis” beinhaltet unterschiedliche Abkürzungen und Tippfehler. Testen Sie verschiedene phonetische und “Nearest-Neighbor”-Methoden zum Clustern aus.

Bildschirmfoto mit Text Facet auf der Spalte Familienverhältnis.

Aufgabe 3: Clustern?

Auch in der Spalte “Religion” haben sich unterschiedliche Abkürzungen und Tippfehler eingeschlichen. Lohnt sich hier ein Clustering, oder besser eine Kombination aus “Text Facet” und Textfilter?

Bildschirmfoto mit Text Facet auf der Spalte Religion.

Fazit

Die in OpenRefine implementierten Clusteringverfahren sind mächtig und komfortabel integriert. Auch wenn man ohne Hintergrundwissen über die einzelnen Clusteringverfahren zu einem brauchbaren Ergebnis kommt, ist es sinnvoll sich im Vorfeld einen passenden Workflow zurechtzulegen. Je nach Datenmenge wartet man sonst unnötig lange auf das Ergebnis eines aufwendiger zu berechnenden Nearest-Neighbor-Verfahrens.

Hier gibt es im GLAM-Bereich auch durchaus noch Potential weitere Clusteringverfahren zu implementieren. Zum Beispiel zur Korrektur von OCR-Fehlern, Berücksichtigung von Synonymen, oder Worteinbettungen wie Bag-of-Words Modelle und Word2Vec.

Update Mai 2025: Seit OpenRefine 3.9.3 lassen sich eigene Clustering Funktionen definieren. Das wird in 19 Erweitertes Clustering vertieft.

Im nächsten Teil beschäftigen wir uns mit dem Abgleich von Daten in OpenRefine mit der Gemeinsamen Normdatei (GND) über das lobid API.

06 Reconciling mit OpenRefine und der GND

Workshop - Daten mit OpenRefine exportieren

Fri, 01 Apr 2022 00:00:00 +0000

Wir exportieren Daten mit OpenRefine in unterschiedliche Formate.

Daten exportieren in der OpenRefine Dokumentation.

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

Hintergrund

OpenRefine bietet sowohl verschiedene fertige Exportmöglichkeiten an als auch die Möglichkeit, eigene Formate (JSON, XML) zu erstellen. Wir konzentrieren uns in diesem Workshop auf tabellenartige Formate.

Aufgabe 1: Daten als Excel exportieren

Wir verwenden das Projekt “Kretschmann Kabinett III”, das wir in Projekte in OpenRefine laden und verwalten erstellt haben.

Dort erstellen wir ein “Text Facet” auf der Spalte “Geschlecht” und wählen darüber alle weiblichen Kabinettsmitglieder aus.

Über “Export" "Excel 2007+ (.xlsx)” erzeugen wir eine Excel Datei.

Aufgabe 2: Daten als CSV exportieren

Wir verwenden das gleiche Setup wie in Aufgabe 1.

Über “Export" "Comma-separated value” erzeugen wir eine CSV Datei.

Aufgabe 3: Datenexport spezifizieren

Wir verwenden das gleiche Setup wie in Aufgabe 1.

Über “Export" "Custom tabular exporter…” erzeugen wir eine spezielle Datei.

Die Einstellungen sind mit Bildschirmfotos in Abbildung 1 und 2 dokumentiert.

Bildschirmfoto von OpenRefine Export Einstellungen 1.

Bildschirmfoto von OpenRefine Export Einstellungen 2.

Die Dateiendung der heruntergeladenen Datei ändern wir anschließend von .txt nach .csv.

Aufgabe 4: Datenexporte vergleichen

Wir öffnen die drei exportierten Dateien mit Excel.

Was sind die Unterschiede zwischen den Dateien?

Welcher Export eignet sich für welchen Anwendungsfall?

Hinweise/Lösungen:

Der normale Export berücksichtigt die momentan aktiven “Facets” und Filter.
Excel erwartet bei CSV ein Semikolon ; als Trennzeichen und windows-1252 als Kodierung. Daher sieht die erste CSV-Datei in Excel “seltsam” aus. ¹
Der normale CSV Export von OpenRefine ist mit Komma , getrennt und verwendet utf-8 als Kodierung, wie es von den meisten Anwendungen erwartet wird.
Beim spezifischen Datenexport hat man die Kontrolle darüber, was exportiert wird und kann Trennzeichen, Kodierungen, … beeinflussen.
Im FDMLab verwenden wir xlsx, wenn die Daten in Excel weiter bearbeitet werden sollen, und csv, wenn wir die Daten mit anderen Anwendungen weiter bearbeiten.

Microsoft Excel hat einen Textimport-Assistenten, mit dem auch andere Formate importiert werden können. ↩︎

Fazit

OpenRefine kann die Projekte in gängige Formate exportieren. Das ist schnell und bequem. Komplexer wird es bei verschachtelten Formaten wie XML. Das behandeln wir in unserem Workshop für Fortgeschrittene.

Im nächsten Teil beschäftigen wir uns mit den Mechanismen zum Clustering in OpenRefine.

05 Daten mit OpenRefine clustern

Workshop - Daten mit OpenRefine filtern und sortieren

Fri, 01 Apr 2022 00:00:00 +0000

Wir erkunden Datensätze mit OpenRefine, indem wir sie filtern und sortieren.

Facets in der OpenRefine Dokumentation.

Sortieren in der OpenRefine Dokumentation.

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

Hintergrund

OpenRefine bietet umfangreiche Möglichkeiten Daten zu sortieren und zu filtern. So können Filter kombiniert und Teilmengen des Datensatzes gesammelt bearbeitet werden.

Wir fokussieren uns in diesem Workshop auf die Funktionen, mit denen man Text ordnen und filtern kann. Um Daten zu filtern gibt es in OpenRefine so genannte “Facets”. Diese lassen sich über das Spaltenmenü via “Facet” aktivieren.

Bildschirmfoto von OpenRefine Text Facet.

Das “Text Facet” zeigt alle Werte einer Spalte an. Man kann die Werte nach Name oder Anzahl sortieren lassen, ein oder mehrere Werte auswählen oder die Auswahl umkehren (“invert”).

Das “Text Facet” über der Spalte Vorname in Abbildung 1 informiert uns, dass der häufigste Vorname “Max” lautet. Von den Personen mit Vornamen “Max” haben laut der Spalte “akad. Grad/Titel” zwei einen Doktortitel.

Bildschirmfoto von OpenRefine Text Facet.

Facets lassen sich auch kombinieren. Wählen wir zusätzlich im “Text Facet” zum Titel den “Dr. med.” aus und aktivieren das “Text Facet” auf der Spalte “Beruf”, so erfahren wir in Abbildung 2, dass ein Max Arzt und ein Max Zahnarzt war.

Die Gurs-Daten wurden zur Veröffentlichung im Blog aufbereitet. Die Spalten für die Namen und Berufe wurden dabei entfernt!

Wir arbeiten mit dem Gurs-Datensatz, den wir in “Projekte in OpenRefine laden und verwalten” geladen haben.

Untersuchen Sie mit “Text Facets” die einzelnen Spalten. Diese rufen Sie auf über “Spalte" "Facet" "Text facet”. Fällt Ihnen bei den Werten einzelner Spalten etwas auf?

Besteht Bedarf die Werte einzelner Spalten zu korrigieren?

Notieren Sie Ihre Beobachtungen.

Was gibt es noch für “Facets”?

Gibt es Spalten mit passenden Daten um die “Facets” darauf anzuwenden?

Hinweis: Um ein spezielles Facet für “Number” oder “Date” zu verwenden, muss die entsprechende Spalte zuerst in diesen Datentyp umgewandelt werden. Das geht zum Beispiel über “Spalte" "Edit cells" "Common transforms" "To number”.

Es gibt eine “All” Spalte, wo Aktionen für alle Spalten verfügbar sind.

Wir verwenden das “Facet by blank (null or empty string)” um Leerzeilen zu identifizieren. In den 4.000 Einträgen (rows) sollte es fünf Leerzeilen geben. Das Facet wird geöffnet über “All" "Facet" "Facet by blank (null or empty string)”.

Warum werden diese fünf Leerzeilen mit dem Facet nicht gefunden?

Hinweise:

Sollten Ihnen nur 3.995 Zeilen angezeigt werden, so haben Sie die Leerzeilen beim Importieren der Daten schon gelöscht.
Es gibt in dem Datensatz fünf Zeilen, die lediglich Leerzeichen enthalten. Diese sind aus Sicht von OpenRefine nicht “leer”. Wir werden in einer späteren Aufgabe lernen, wie wir diese Leerzeichen und Zeilen automatisiert entfernen können.

Aufgabe 4: Zeilen sortieren

Wir sortieren die Spalte “Geburtsort” via “Geburtsort" "Sort…” und sortieren die Spalte als alphabetisch aufsteigenden Text. Dadurch erscheint ein neues Menü in der Kopfzeile namens “Sort”, welches wir in Abbildung 3 markiert haben.

Wird dadurch eine Aktion in der “History” hinterlegt? Was passiert in der “History”, wenn wir in dem Menü “Sort” die Aktion “Reorder rows permanently” ausführen?

Bildschirmfoto von OpenRefine mit dem Menü zum Sortieren.

Machen Sie abschließend die Sortierung wieder rückgängig.

Hinweis: In der Spalte Geburtsort gibt es einige Orte, die nur eine GND-ID haben. Darum kümmern wir uns in einer späteren Aufgabe.

Aufgabe 5: Spalten löschen / ausblenden

Wir haben in Aufgabe 1 festgestellt, dass die Spalte “Geburtsdatum (beschreibend)” leer ist.

Wir können diese Spalte entweder via “Geburtsdatum (beschreibend)“ "Edit column" "Remove this column” löschen oder via “Geburtsdatum (beschreibend)“ "View" "Collapse this column” ausblenden.

Testen Sie die beiden Varianten. Was sind die Vor- und Nachteile davon?

Aufgabe 6: Spalten sortieren

Um Spalten umzusortieren gibt es zwei Möglichkeiten:

Im Spaltenmenü unter “Edit column” die Spalte nach links oder rechts verschieben.
Im “All” Menü unter “Edit columns” den Dialog “Re-order / remove columns…” aufrufen.

Testen Sie die Funktionen und machen Sie sie anschließend wieder rückgängig.

Fazit

Die Möglichkeit Daten mit Facets zu filtern und sie mit anderen Facets oder Filtern zu kombinieren ist ein häufig genutztes Feature von uns. Das Umbenennen und Sortieren von Spalten fühlt sich manchmal jedoch etwas aufwendiger an, als es sein sollte.

Im nächsten Teil löschen wir Daten in OpenRefine, wandeln sie um und Bearbeiten sie.

03 Daten mit OpenRefine transformieren

Workshop - Daten mit OpenRefine umwandeln

Fri, 01 Apr 2022 00:00:00 +0000

Wir lernen verschiedene Methoden kennen um Daten aufzuräumen und umzuwandeln.

Daten transformieren in der OpenRefine Dokumentation.

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

Hintergrund

OpenRefine bietet unterschiedliche Arten an Daten umzuwandeln. Dies kann manuell auf Zellebene passieren, in einem “Facet”, auf Spaltenebene oder für bestimmte Aktionen auf dem kompletten Datensatz.

In den folgenden Aufgaben werden wir nun aktiv Daten filtern, umwandeln und zusammenführen.

Aufgabe 1: Leere Zeilen identifizieren und löschen

Wie in Aufgabe 3 in 02 Filtern und Sortieren verwenden wir das “Facet by blank (null or empty string)” um Leerzeilen zu identifizieren. Denn in den 4.000 Einträgen (rows) sollte es 5 Leerzeilen geben. Diese werden jedoch nicht angezeigt, da sie nicht leer sind, sondern Leerzeichen beinhalten.

Die Leerzeichen können wir global über “All" "Edit all columns" "Trim leading and trailing whitespace” entfernen.

Anschließend können wir, wie in Abbildung 1, mit dem “Facet by blank (null or empty string)” die Leerzeilen auswählen und via “All" "Edit rows" "Remove matching rows” entfernen.

Gehen Sie noch einmal zurück zu den Bildschirmfotos der Importeinstellungen in Projekte in OpenRefine laden und verwalten und vergleichen diese für Aufgabe 1 und 2.

Wir können Probleme mit Leerzeilen schon beim Importieren lösen, indem wir, wie bei Aufgabe 2, das Kontrollkästchen bei “Trim leading & trailing whitespace from strings” aktivieren und das Kontrollkästchen bei “Store blank rows” abwählen. Das ist jedoch nicht immer möglich, oder manchmal wird es vergessen.

Aufgabe 2: Geschlechter vereinheitlichen

Die Geschlechtsbezeichnungen in der Spalte “Geschlecht (m/w)” sind sehr uneinheitlich. Wir wollen dies vereinheitlichen, so dass überall nur noch die Werte “m” und “w” stehen.

Dafür testen wir mehrere Methoden.

1. Einzeln bearbeiten

Wenn wir mit der Maus über eine Zelle gehen, dann erscheint wie in Abbildung 2 eine blaue Bedienfläche mit der Bezeichnung “edit”. Darüber können wir einzelne Zellen bearbeiten.

Bildschirmfoto von Edit Bedienfläche in Zelle.

Hinweise:

Die Bearbeitung auf diesem Weg kann zwar rückgängig gemacht, aber nicht als Aktion exportiert werden!

Wenn wir mit der Maus über einen Wert im Facet gehen, dann erscheint wie in Abbildung 3 ein blauer “edit” Link. Darüber können wir alle Zellen mit diesem Wert in der Spalte gleichzeitig bearbeiten.

3. Ersetzen in der Spalte

Im Spaltenmenü findet sich unter “Geschlecht (m/w)“ "Edit cells" "Replace” ein Dialog, mit dem in dieser Spalte Ersetzungen durchgeführt werden können.

4. Textfilter und Transform

Eine andere Methode ist eine Kombination aus Textfilter und “Transform”. Im Spaltenmenü wählen wir “Geschlecht (m/w)“ "Textfilter” und geben im Eingabefeld des Filters nur den Buchstaben “w” ein, der praktischerweise in “männlich” nicht vorkommt.

Im “Text Facet” für die Spalte Geschlecht, sehen wir analog zu Abbildung 4 die gefilterten Werte.

Bildschirmfoto mit Kombination aus Facet und Textfilter.

Anschließend rufen wir den Dialog zum Transformieren über das Spaltenmenü via “Geschlecht (m/w)“ "Edit cells" "Transform…” auf.

In dem Dialog könnte komplexer Code geschrieben werden, wir wollen den Inhalt jeder Zelle jedoch einfach mit dem Wert "w" ersetzen. Die Anführungszeichen sind wichtig, da wir dadurch OpenRefine mitteilen, dass wir den Wert w meinen, und keinen Programmcode.

Aufgabe 3: Spalte akad. Grad/Titel vereinheitlichen

In der Spalte “akad. Grad/Titel” sind die akademischen Grade uneinheitlich geschrieben (siehe auch Abbildung 5). Überlegen Sie, welche der in Aufgabe 2 gelernten Methoden hier geeignet wäre und vereinheitlichen Sie die Titel.

Bildschirmfoto mit Text Facet auf Spalte Titel.

Aufgabe 4: Spalten auftrennen

Bei den Ortsangaben sind der Ortsname und die GND-ID des Ortes mit | getrennt in einer Zelle. Wir wollen die Spalte “Geburtsort” auftrennen, so dass wir jeweils eine Spalte mit dem Ortsnamen und eine mit der zugehörigen GND-ID haben.

Dafür verwenden wir im Spaltenmenü den Dialog “Geburtsort" "Edit column" "Split into several columns…” mit den in Abbildung 6 gezeigten Einstellungen.

Bildschirmfoto vom Dialog zum Auftrennen von Spalten.

Anschließend entfernen wir überflüssige Leerzeichen via “Geburtsort" "Edit cells" "Common transforms" "Trim leading and trailing whitespace” und benennen die neuen Spalten entsprechend in “Geburtsort” und “Geburtsort (GND-ID)” um.

Hinweise:

Mit Hilfe des regulären Ausdrucks \s*\|\s* hätten wir die Leerzeichen beim Aufsplitten auch direkt entfernen können.
Vielleicht sind Ihnen Zeilen aufgefallen, wo anstelle des Ortes nur die GND-ID steht. Um diese kümmern wir uns später.

Aufgabe 5: Spalten zusammenführen

Beim Sterbedatum haben wir das umgekehrte Problem. Hier ist das Datum in drei Spalten aufgeteilt, wir wollen jedoch eine Spalte haben. Bevor wir die Spalten zusammenführen, prüfen wir, ob die Werte in den einzelnen Spalten sinnvoll sind, und korrigieren die Werte bei Bedarf.

Anschließend rufen wir im Spaltenmenü den Dialog zum Zusammenführen von Spalten auf “Todesdatum (Tag)“ "Edit column" "Join columns…” mit den in Abbildung 7 gezeigten Einstellungen.

Bildschirmfoto vom Dialog zum Zusammenführen von Spalten.

Aufgabe 6: Datum vereinheitlichen

In der Spalte “Geburtsdatum (exakt)” gibt es mehrere Formate für das Geburtsdatum:

“31.03.1920”
“31-03-1920”
“31. März 1920”

OpenRefine bietet verschiedene Funktionen an, um mit Daten zu arbeiten.

Datumsfunktionen in der OpenRefine Dokumentation.

Um die Daten in ein einheitliches Format zu bringen, wandeln wir sie zuerst in ein Datumsobjekt um und schreiben sie anschließend als Text wieder raus.

Dafür müssen wir OpenRefine noch mitteilen, wie die Eingabe- und Zielformate aussehen:

“dd.MM.yyyy”
“dd-MM-yyyy”
“dd. MMMM yyyy”

Um die Daten umzuwandeln öffnen wir den Dialog zum Transformieren über das Spaltenmenü von “Geburtsdatum (exakt)“ "Edit cells" "Transform” und verwenden den Ausdruck:

value.toDate("dd.MM.yyyy", "dd-MM-yyyy", "dd. MMMM yyyy").toString("dd.MM.yyyy")

Hinweise:

OpenRefine bietet die Möglichkeit Programmcode zu nutzen um Transformationen durchzuführen. Dazu gehören Clojure/Python und die General Refine Expression Language (GREL).
Die Datumsumwandlung gehört zu den Funktionen von GREL, die wir auf Grund ihrer Relevanz in diesen Einführungsworkshop mit aufgenommen haben.

Aufgabe 7: Daten mit Filter auf eine andere Spalte übertragen

In der Spalte “Geburtsort” ist bei einem Ort die GND-ID verrutscht und der Ortsname verloren gegangen. Bei dem Ort handelt es sich um “Breslau (Polen)” mit der GND-ID “4008216-7”.

Um dies zu beheben erstellen wir ein “Text Facet” für die Spalte “Geburtsort” und filtern nur die Einträge mit “4008216-7”. Es gibt nun verschiedene Möglichkeiten die Daten in die Spalte “Geburtsort (GND-ID)” zu übertragen.

Zellen einzeln bearbeiten
Ein weiteres “Text Facet” für die Spalte “Geburtsort (GND-ID)” erstellen und in beiden die Werte gesammelt bearbeiten.
Die Werte via Textfilter oder “Text Facet” filtern und die Spalten zusammenführen ( “Geburtsort" "Edit column" "Join columns…”), ohne die Original Spalte zu löschen.
Im Spaltenmenü via “Geburtsort (GND-ID)“ "Edit cells" "Transform” die Daten aus der anderen Spalte mit dem Ausdruck row.cells["Geburtsort"].value kopieren.

Alle Varianten haben ihre Berechtigung und je nach Kontext oder Anwendungsfall eignet sich die ein oder andere eher.

Fazit

Die Kombination aus Facets/Filtern und den Bearbeitungsmöglichkeiten machen OpenRefine zu unserem Liebling beim Aufräumen von Daten (Data Cleaning). Manchmal vermissen wir es jedoch größere Bereiche manuell auszuwählen und in eine andere Spalte zu Verschieben.

Im nächsten Teil lernen wir verschiedene Exportmöglichkeiten in OpenRefine kennen.

04 Daten mit OpenRefine exportieren

Workshop - Die Oberfläche von OpenRefine

Fri, 01 Apr 2022 00:00:00 +0000

Wir geben einen Überblick über die OpenRefine Oberfläche.

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

--- title: OpenRefine Setup config: look: handDrawn theme: neutral --- flowchart LR subgraph server[fas:fa-server Server] server_api[fas:fa-code Reconciliation API] end subgraph laptop[fas:fa-laptop Laptop] browser[far:fa-window-maximize Browser] laptop_or[fas:fa-gem OpenRefine] end browser -.-> laptop_or laptop_or -.-> server_api

Die Startseite

Wir verwenden OpenRefine auf unserem Laptop oder PC im Browser. In Abbildung 1 ist die Startseite von OpenRefine gezeigt. Hier kann von unterschiedlichen Datenquellen heraus ein neues Projekt erstellt werden. Ein existierendes Projekt kann man via “Open Project” öffnen.

Bildschirmfoto von der Startseite in OpenRefine.

Die Projektübersicht

Mit “Open Project” gelangt man zu der in Abbildung 2 gezeigten Projektübersicht. Die Projekte kann man nach “Tags” filtern. Die blaue Schrift zeigt hier Links an, mit denen zum Beispiel die Projektmetadaten bearbeitet oder Projekte geöffnet werden können.

Praktisch ist in dieser Ansicht auch der Link zum Speicherort der Projekte, falls man diese zum Beispiel für ein Update sichern möchte.

Bildschirmfoto von der Projektübersicht in OpenRefine.

Die Bearbeitungsansicht

Die Daten in der Bearbeitungsansicht eines Projektes werden wie in Abbildung 3 gezeigt tabellarisch dargestellt. Zurück zu Startseite kommt man durch einen Klick auf das OpenRefine Logo oder über die in OpenRefine neu eingeführte Schaltfläche mit der Aufschrift “Open”. Neben der Schaltfläche gibt es ein so genanntes Dropdown-Menü mit verschiedenen Möglichkeiten die Daten zu exportieren.

Der Name des Projektes lässt sich in dieser Ansicht mit einem Klick auf den Text bearbeiten.

Bildschirmfoto von der Bearbeitungsansicht in OpenRefine.

In der nächsten Zeile finden sich verschiedene Navigationselemente. Ganz links kann zwischen der Facet- und Filter-Ansicht und der History hin- und hergewechselt werden. Über der Tabelle kann zwischen dem Zeilen- und dem Record-Modus gewechselt werden.

Außerdem gibt es die Möglichkeit auszuwählen, wie viele Zeilen/Records pro Seite angezeigt werden sollen, und ganz rechts kann dann durch die einzelnen Seiten geblättert werden.

Die Bearbeitungsfunktionalität versteckt sich bei OpenRefine in so genannten Dropdown-Menüs über jeder Spalte, die wir kurzerhand “Spaltenmenüs” nennen. Es gibt ganz links auch eine “All”-Spalte, mit der Aktionen auf allen Spalten angewendet, oder einzelne Zeilen mit Sternen oder Fahnen markiert werden können.

Die Facets und Filter ganz links können einzeln reduziert, geschlossen und miteinander kombiniert werden. Mit ihnen können die Daten nicht nur zur Ansicht gefiltert werden, sondern auch Bearbeitungen auf einer Teilmenge des Datensatzes durchgeführt werden.

Die Sprache der Benutzeroberfläche

Die Sprache der Benutzeroberfläche von OpenRefine lässt sich von der Startseite ausgehend unter “Language Settings” auch auf Deutsch umstellen. Wir verzichten im FDMLab und für diesen Workshop explizit darauf.

Da die Dokumentation (noch) nicht auf Deutsch verfügbar ist, hat es sich nach unserer Erfahrung gezeigt, dass die Orientierung in OpenRefine mit englischer Benutzeroberfläche einfacher ist. Bei einer deutschen Benutzeroberfläche ist es deutlich schwieriger die in der Dokumentation beschriebenen Menüs, Schaltflächen und Konzepte zu finden.

Fazit

Es zuerst etwas gewöhnungsbedürftig die Funktionen in den Spaltenmenüs zu finden und nicht zum Beispiel via Rechtsklick in einem Kontextmenü. Auch die räumliche Trennung von Daten und Funktionalität in OpenRefine ist im direkten Vergleich mit Excel ungewohnt, da man in Excel Formeln direkt in die Datenzellen schreiben kann.

Jedoch gewöhnten wir und unsere bisherigen Workshop Teilnehmer uns ziemlich schnell an das Bedienkonzept von OpenRefine.

Im nächsten Teil gibt es eine Erklärung zur Installation von OpenRefine.

00 Openrefine Installieren

Workshop - OpenRefine installieren

Fri, 01 Apr 2022 00:00:00 +0000

Wir “installieren” OpenRefine als portable Anwendung. Anschließend starten wir die Anwendung.

OpenRefine installieren in der OpenRefine Dokumentation.

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

Herunterladen

OpenRefine kann auf der Webseite https://openrefine.org/download.html heruntergeladen werden. Wir verwenden für unseren Workshop die Version: OpenRefine 3.9.3.

Als Distribution verwenden wir das Windows kit with embedded Java. Dadurch ersparen wir uns die separate Installation von Java.

Einrichten

Das Archiv openrefine-win-with-java-3.9.3.zip können wir via Rechtsklick "Alle extrahieren" entpacken und anschließend den darin enthaltenen Ordner openrefine-3.9.3 kopieren.

Wir verwenden OpenRefine als portable Software. Das bedeutet, dass OpenRefine nicht installiert wird, und es gibt auch keine Startsymbole auf dem Desktop oder dem Startmenü.

Es empfiehlt sich auf dem lokalen Rechner in seinen Dateien einen Ordner mit z.B. dem Namen Portable Software anzulegen, wo solch portable Programme abgelegt werden können. Dieser Ordner sollte nicht auf einem Netzwerklaufwerk liegen, da von dort aus keine Programme ausgeführt werden können, bzw. sie sehr langsam laufen.

Starten

Zum Starten öffnen wir die Datei openrefine.exe im Ordner openrefine-3.9.3.

Beim ersten Starten kann es sein, dass sich, wie in Abbildung 1 gezeigt, der SmartScreen Schutzmechanismus von Windows meldet, da wir versuchen ein aus dem Internet heruntergeladenes Programm auszuführen.

Bildschirmfoto von Windows SmartScreen 1.

Mit einem Klick auf “Weitere Informationen” erhalten wir, wie in Abbildung 2 gezeigt, die Möglichkeit OpenRefine “Trotzdem aus[zu]führen”.

Bildschirmfoto von Windows SmartScreen 2.

Anschließend öffnet sich eine so genannte Konsole, die den OpenRefine Server startet. Die Bedienoberfläche öffnet sich im Webbrowser unter http://127.0.0.1:3333/.

Stoppen

Zum Schließen das OpenRefine Konsolenfenster auswählen und wie zum Kopieren von Text die Tastaturkombination STRG-C drücken. Dies stellt sicher, dass alle Änderungen am Projekt gespeichert werden.

Alternativ kann nach kurzer Wartezeit das Konsolenfenster auch einfach geschlossen werden.

Fazit

Das von uns schon mehrfach gelobte Client-Server-Modell von OpenRefine sorgte beim ersten Start von OpenRefine bei einigen Kursteilnehmerinnen und Kursteilnehmern für Stirnrunzeln. Ein Programm ohne Einträge im Startmenü, welches irgendwo abgelegt werden kann, in einer Konsole läuft und via Browser bedient wird?

Aber auch daran konnten wir uns alle recht schnell gewöhnen. Also haben Sie noch Geduld und bleiben Sie noch etwas bei uns im Workshop!

Im nächsten Teil laden wir verschiedene Dateien als Projekte in OpenRefine.

01 Projekte in OpenRefine laden

Workshop - Projekte in OpenRefine laden und verwalten

Fri, 01 Apr 2022 00:00:00 +0000

Wir laden mehrere Dateien in OpenRefine Projekte und bearbeiten deren Metadaten.

Projekte in der OpenRefine Dokumentation.

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

Hintergrund

OpenRefine kann unterschiedliche Dateiformate über verschiedene Quellen in das interne Projektformat importieren. Der “übliche” Weg ist der Import von einer oder mehreren Dateien, weshalb wir uns vorerst darauf beschränken.

Aufgabe 1: Eine Datei laden

Wir werden im Laufe des Workshops häufiger mit einem Ausschnitt der Gurs-Deportationsliste arbeiten, die vom Generallandesarchiv Karlsruhe recherchiert und im FDMLab bereinigt und mit weiteren Normdaten ergänzt wurde.

Für diesen Workshop wurde die Liste nachträglich mit einigen “Problemen” versehen, die wir in den nachfolgenden Aufgaben bereinigen werden. Für diese Aufgabe wollen wir erst einmal nur die Datei 01_gurs.csv in das Projekt “Gurs” laden.

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

Gurs als CSV

Beim Projektimport verwenden wir die folgenden Einstellungen:

Project name: Gurs
Tags: Gurs, GND, Workshop, 2024

Die Optionen für das Format sind als Bildschirmfoto hinterlegt.

Bildschirmfoto von OpenRefine Parsing Options.

Die Gurs-Daten wurden zur Veröffentlichung im Blog aufbereitet, indem Zeilen und Spalten gelöscht sowie die restlichen Spalten zufällig sortiert wurden. Für die Verwendung in den Aufgaben des Workshops ist die Datei nach wie vor geeignet, jedoch nicht für Recherche und Forschungszwecke!

Aufgabe 2: Mehrere Dateien gleichzeitig laden

Wir haben die Beteiligten des Kabinetts Kretschmann III getrennt nach Frauen und Männern in zwei CSV Dateien gespeichert (01_kretschmann-kabinett-frauen.csv und 01_kretschmann-kabinett-maenner.csv).

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

Kretschmann Kabinett Frauen als CSV

Kretschmann Kabinett Maenner als CSV

Diese Dateien laden wir gemeinsam in ein OpenRefine Projekt.

Beim Projektimport verwenden wir die folgenden Einstellungen:

Project name: Kretschmann Kabinett III
Tags: GND, Workshop, 2024

Die Optionen für das Format sind als Bildschirmfoto hinterlegt.

Bildschirmfoto von OpenRefine Parsing Options.

Aufgabe 3: Projektdaten anpassen

OpenRefine bietet noch mehr Einstellungen für Projekte, als die die wir beim Erstellen angeben. Dazu gehören zum Beispiel der Name des Erstellers, ein Vorschaubild, die Lizenz, …

Bildschirmfoto von OpenRefine Projekt Metadaten.

Um diese anzupassen, verwendet man den Link “About” in der Projektübersicht wie in Abbildung 3 und fügt die Informationen via “Edit” ein. Um dies einmal durchzuführen, ergänzen wir bei dem Gurs-Projekt im Feld Homepage die URL des LABW, wie in Abbildung 4 gezeigt.

https://www.landesarchiv-bw.de

Bildschirmfoto von dem Bearbeitungsdialog der OpenRefine Projekt Metadaten.

Aufgabe 4: Aktionsverlauf

OpenRefine speichert Änderungen automatisch und erstellt einen Verlauf aller auf ein Projekt angewendeter Aktionen. Diese können im Tab “Undo/Redo” angesehen, rückgängig gemacht oder importiert werden.

Um das besser kennen zu lernen laden wir ein OpenRefine Projekt und übertragen die Änderungshistorie auf ein Projekt von uns.

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

Kretschmann Kabinett (Vorlage) als OpenRefine Projektdatei

Wir laden die OpenRefine Projektdatei über das in Abbildung 5 gezeigte Formular zum Importieren von OpenRefine Projekten.

Bildschirmfoto vom Formular zum Importieren von OpenRefine Projekten.

Anschließend öffnen wir den Reiter für die Änderungshistorie in OpenRefine. Dort werden automatisch alle automatisch gespeicherten Arbeitsschritte gezeigt. Frühere Zustände des Projektes können durch Anklicken des entsprechenden Eintrages in der Änderungshistorie wiederhergestellt oder überschrieben werden. Geht man in der Änderungshistorie zum Beispiel zu Schritt 2 zurück und fügt dann eine neue Änderung ein, dann werden die nachfolgenden Schritte (3-4) überschrieben.

Wie in Abbildung 6 gezeigt können die Arbeitsschritte eines Projektes auch extrahiert werden.

Bildschirmfoto des Reiters für die Änderungshistorie in OpenRefine.

Der in Abbildung 7 gezeigte Dialog zum Extrahieren erlaubt es auch einzelne Schritte zum Export aus- oder abzuwählen. Wir extrahieren den kompletten Text und kopieren ihn in die Zwischenablage.

Bildschirmfoto des Dialogs zum Extrahieren von Änderungen.

Der kopierte Text sieht in etwa wie folgt aus, wobei die Beschreibung (description) nachträglich mit einer deutschsprachigen Erklärung versehen wurde.

[
 {
 "op": "core/column-split",
 "engineConfig": {
 "facets": [],
 "mode": "row-based"
 },
 "columnName": "Bevorzugter Name",
 "guessCellType": true,
 "removeOriginalColumn": true,
 "mode": "separator",
 "separator": ",",
 "regex": false,
 "maxColumns": 2,
 "description": "Spalte nach Vorname und Nachname auftrennen."
 },
 {
 "op": "core/column-rename",
 "oldColumnName": "Bevorzugter Name 1",
 "newColumnName": "Nachname",
 "description": "Spalte Bevorzugter Name 1 in Nachname umbenennen."
 },
 {
 "op": "core/column-rename",
 "oldColumnName": "Bevorzugter Name 2",
 "newColumnName": "Vorname",
 "description": "Spalte Bevorzugter Name 2 in Vorname umbenennen."
 },
 {
 "op": "core/text-transform",
 "engineConfig": {
 "facets": [],
 "mode": "row-based"
 },
 "columnName": "Geschlecht",
 "expression": "grel:if(value == \"Weiblich\", \"w\", \"m\")",
 "onError": "keep-original",
 "repeat": false,
 "repeatCount": 10,
 "description": "Männlich und Weiblich als m und w kodieren."
 }
]

Um die Änderungen in unserem eigenen Projekt anzuwenden öffnen wir das Projekt “Kretschmann Kabinett III”, öffnen dort den Tab “Undo/Redo”, drücken auf “Apply” und kopieren wie in Abbildung 8 den Text in den Dialog.

Anwenden von Aktionen über die History Funktion von OpenRefine.

Da wir in unserem Projekt die gleichen Spaltennamen haben, wie im Vorlagenprojekt, konnten wir die Änderungen direkt übernehmen und haben nun den gleichen Stand.

Fazit

OpenRefine öffnet viele unterschiedliche Dateitypen, extrahiert Archive, rät die Einstellungen für den Import und bietet mit der Vorschau eine tolle Möglichkeit die Einstellungen anzupassen. Das Metadatenmanagement der Projekte ist etwas lieblos implementiert. Die Möglichkeit (fast) jeden Bearbeitungsschritt wieder rückgängig zu machen gibt die Sicherheit, auch mal Datenbearbeitungen ausprobieren zu können, ohne sich in verschiedenen Versionen einer “Datei” zu verlaufen. Beim Verlauf der Bearbeitungsschritte wäre es noch praktisch, wenn man verschiedene Stände markieren könnte, um schneller dorthin zurückzuspringen.

Im nächsten Teil lernen wir, wie wir Daten in OpenRefine filtern und sortieren können.

02 Daten mit OpenRefine filtern und sortieren

Workshop - Reconciling mit OpenRefine und der GND

Fri, 01 Apr 2022 00:00:00 +0000

Wir nutzen die Daten der GND über OpenRefine, gleichen damit Daten ab und laden Daten nach.

Reconciling in der OpenRefine Dokumentation.

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

Hintergrund

Die Gemeinsame Normdatei (GND) wird als Linked Open Data (LOD) angeboten. Das ermöglicht uns Daten mit eindeutigen Identifikatoren (GND-ID) zu verknüpfen.

Mit OpenRefine können wir mit der GND zwei Dinge tun:

basierend auf GND-IDs weitere Daten nachladen (Aufgabe 1).
via Reconciliation Service GND-IDs für Entitäten suchen (Aufgabe 2).

Kurzer Exkurs zur GND als LOD

Die GND als LOD bedeutet, dass die Daten nicht in einer klassischen Datenbank angeboten werden, sondern mit einer Ontologie versehen wurden. Die Hierarchie der Ontologie ist in Abbildung 1 visualisiert.

Visualisierung der GND Ontologie, mit den für uns relevanten Bereichen Personen, Orte und Dinge.

Neben den Typen der Objekte in der GND Ontologie gibt es auch vordefinierte Verbindungen zwischen diesen Objekten. Ein Beispiel ist im folgenden Diagramm für einen Teil der GND-Daten für Winfried Kretschmann gezeigt. Beispielsweise gibt es die bidirektionale Verbindung hasSpouse, zwischen ihm und Gerlinde Kretschmann. Oder die unidirektionale Verbindung placeOfBirth zwischen der Person Winfried Kretschmann und dem Ort Spaichingen.

--- title: Visualisierung zu Objekten und Verbindungen in der GND config: look: handDrawn theme: neutral --- flowchart LR subgraph place["fa:fa-map-marked Place"] spaichingen["Spaichingen"] laiz["Laiz"] end subgraph person["fa:fa-user Person"] kretschmann_winfried["Kretschmann, Winfried"] kretschmann_gerlinde["Kretschmann, Gerlinde"] end subgraph shss["fa:fa-tag Subject heading senso stricto"] politiker["Politiker"] politikerin["Politikerin"] lehrer["Lehrer"] lehrerin["Lehrerin"] end kretschmann_winfried <-- hasSpouse --> kretschmann_gerlinde kretschmann_winfried -- professionOrOccupation --> politiker & lehrer kretschmann_gerlinde -- professionOrOccupation --> lehrerin kretschmann_winfried -- placeOfBirth --> spaichingen kretschmann_gerlinde -- placeOfBirth --> laiz kretschmann_winfried -- placeOfActivity --> laiz lehrer <-- relatedTerm --> lehrerin politiker <-- relatedTerm --> politikerin

Optional kann in einer Ontologie festgelegt werden, dass zum Beispiel eine Verbindung wie placeOfBirth nur zwischen einer Person und einem Ort existieren kann.

Vorbereitung

Datensatz laden

Wir erstellen eine neues Projekt mit dem Namen “Kretschmann Kabinett III” aus der Datei 06_kretschmann-kabinett-iii.csv.

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

Kretschmann III als CSV

Diese Datei besteht nur aus einer Spalte mit GND-IDs.

Reconciliation Service hinzufügen

Die GND selbst wird von der DNB aktuell als kompletter Datensatz zur Verfügung gestellt und nicht als Service. Daher nutzen wir den GND Service von lobid. Über diesen kann die GND via einer Online-Oberfläche durchsucht werden. Es gibt aber auch einen so genannten Reconciliation Service, mit dem direkt via OpenRefine Daten mit den Daten in der GND abgeglichen werden können.

Dafür fügen wir den Service zu OpenRefine hinzu. Im Spaltenmenü finden wir den in Abbildung 2 gezeigten Dialog über “GND-ID" "Reconcile" "Start reconciling”.

Bildschirmfoto von OpenRefine Reconciliation Services.

Über “Add Standard Service” geben wir die folgende URL ein:

https://lobid.org/gnd/reconcile/

Aufgabe 1: Daten nachladen

Wir wollen die folgenden Spalten zu unserem Datensatz aus der GND ergänzen:

Name der Person
Geburtsdatum
Geburtsort
GND-ID des Geburtsortes
Liste der Berufe der Person

Dafür nutzen wir im Spaltenmenü der Spalte “GND-ID” die Funktion “GND-ID" "Reconcile" "Use values as identifiers” und wählen den Service “GND reconciliation for OpenRefine” aus.

Anschließend können wir ebenfalls über das Spaltenmenü mit “GND-ID" "Edit column" "Add column from reconciled values…” weitere Daten nachladen.

Das Ergebnis sieht dann ungefähr wie in Abbildung 3 aus.

Bildschirmfoto von OpenRefine Ergebnis.

Hinweise:

Die Spaltennamen stimmen nicht unbedingt mit der Bezeichnung in der GND überein.
Die GND-ID des Geburtsortes erhalten wir über die Spalte “Geburtsort”.
Sollten Sie für Zeilen keine Ergebnisse erhalten, prüfen Sie ob sich ggf. noch Leerzeichen im Datensatz befinden.

Aufgabe 2: Daten verknüpfen

Hierfür verwenden wir den Gurs-Datensatz, der uns über den kompletten Workshop begleitet.

In der Spalte “Geburtsort” sind nicht alle Orte mit GND-IDs verknüpft. Wir filtern diese Orte und verknüpfen sie mit GND-IDs.

Dafür nutzen wir im Spaltenmenü der Spalte “Geburtsort" "Reconcile" "Start reconciling” und wählen den Service “GND reconciliation for OpenRefine” aus.

Bildschirmfoto des gefilterten Gurs Datensatzes mit Reconciliation Vorschlägen.

Die GND-ID können wir anschließend wie in Aufgabe 1 als extra Spalte hinzufügen. Anschließend verbinden wir die neue Spalte “GND-Nummer” mit der Spalte “Geburtsort (GND-ID)” (siehe Aufgabe 5 in 03 Daten mit OpenRefine umwandeln).

Fazit

Durch die Implementierung und Integration des Reconciliation Service API in OpenRefine und der GND von dem hbz gestaltet sich der Abgleich von ganzen Datensätzen mit der GND auch für technische Laien als machbar. Im Workshop für Fortgeschrittene besprechen wir, wie wir die Treffer beim Abgleich mit dem lobid API verbessern können.

Im nächsten Teil beschäftigen wir uns mit dem Abgleich von Daten in OpenRefine mit Wikidata.

07 Reconciling mit OpenRefine und Wikidata

Workshop - Reconciling mit OpenRefine und Wikidata

Fri, 01 Apr 2022 00:00:00 +0000

Wir nutzen die Daten von Wikidata über OpenRefine, gleichen damit Daten ab und laden Daten nach.

Arbeiten mit Wikibase in der OpenRefine Dokumentation.

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

Hintergrund

Eine weitere interessante Wissensquelle ist Wikipedia. Auch dort liegen strukturierte Daten vor. In dem Bildschirmfoto der Wikipediaseite der Stadt Spaichingen in Abbildung 1 sind zum Beispiel die Infobox und die Geokoordinaten der Stadt markiert.

Annotiertes Bildschirmfoto der Wikipedia Seite von Spaichingen.

Die Daten auf der Wikipediaseite direkt sind jedoch noch kein Linked Open Data (LOD). Diese Lücke schließt zum Beispiel das DBPedia Projekt, welches aus den Daten der Wikipedia einen Linked Data Graphen erstellt. Hier der Link zum DBPedia-Eintrag der Stadt Spaichingen.

Außerdem gibt es das Wikidata-Projekt, welches ebenfalls semantische Daten beinhaltet. Das entsprechende Datenobjekt ist auf jeder Wikipediaseite verlinkt. Der Link ist in Abbildung 1 markiert. Hier der Link zum Wikidata-Eintrag der Stadt Spaichingen.

Die Auswahl der Datenquelle (Wikipedia, Wikidata, oder DBPedia) ist nicht nur abhängig von der verfügbaren Technologie (für Wikidata gibt es einen Reconciliation Service), sondern auch eine Frage der Lizenzbedingungen. So stehen die Daten in der DBPedia als abgeleitetes Werk von Wikipedia unter einer CC BY-SA 3.0 Lizenz, wohingegen die Daten in Wikidata analog zur GND unter einer CC0 1.0 Lizenz stehen, was die Weiternutzung zum Beispiel für Erschließungsdaten vereinfacht.

--- title: Lizenzen für Wikipedia und Wikidata config: look: handDrawn theme: neutral --- flowchart LR gnd[("GND")] wikipedia[("Wikipedia")] wikidata[("Wikidata")] dbpedia[("DBPedia")] cc0[["fab:fa-creative-commons fab:fa-creative-commons-zero CC0 1.0"]] cc-by-sa[["fab:fa-creative-commons fab:fa-creative-commons-by fab:fa-creative-commons-sa CC BY-SA 3.0"]] gnd & wikidata -.-> cc0 dbpedia & wikipedia -.-> cc-by-sa wikidata --> wikipedia --> dbpedia

Vorbereitung

Datensatz laden

Wir erstellen ein neues Projekt mit dem Namen “Bundeslaender” aus der Datei 07_bundeslaender.csv.

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

Bundeslaender als CSV

Diese Datei besteht nur aus einer Spalte mit der Wikidata-Kennung (QID).

Reconciliation Service hinzufügen (optional)

OpenRefine 3.5 kommt schon mit Wikidata als voreingestelltem Reconciliation Service.

Es ist jedoch auch möglich, Wikidata auf Deutsch zu verwenden.

Dafür fügen wir den Service in deutscher Sprache zu OpenRefine hinzu. Im Spaltenmenü finden wir den in der Abbildung gezeigten Dialog über “QID" "Reconcile" "Start reconciling”.

Bildschirmfoto von OpenRefine Reconciliation Services.

Über “Add Standard Service” geben wir die folgende URL ein:

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

Aufgabe 1: Daten nachladen

Wir wollen die folgenden Spalten zu unserem Datensatz aus Wikidata ergänzen:

Name des Bundeslandes
GND-ID des Bundeslandes
Hauptstadt des Bundeslandes
Geokoordinaten der Landeshauptstadt im WGS84 Format
Zuständiges Archiv des Bundeslandes
GND-ID des zuständigen Archivs
ISIL des zuständigen Archivs
Webseite des zuständigen Archivs

Dafür nutzen wir im Spaltenmenü der Spalte “QID” die Funktion “QID" "Reconcile" "Use values as identifiers” und wählen den Service “Wikidata (en)” (oder die deutschsprachige Alternative) aus.

Anschließend können wir ebenfalls über das Spaltenmenü mit “QID" "Edit column" "Add column from reconciled values…” weitere Daten nachladen.

Das Ergebnis sieht dann ungefähr wie im folgendem Bildschirmfoto aus.

Bildschirmfoto von OpenRefine Ergebnis.

Hinweise:

Die Spaltennamen stimmen nicht unbedingt mit der Bezeichnung in Wikidata überein.
Einige Daten erhalten Sie nicht direkt über die Spalte “Bundesland”.
Sollten Sie für Zeilen keine Ergebnisse erhalten, prüfen Sie ob sich ggf. noch Leerzeichen im Datensatz befinden.

Aufgabe 2: Daten verknüpfen

Hier ist eine Liste der Mitgliedstaaten der Europäischen Union (Stand November 2021).

 - 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. Nachdem wir die Daten aufgeräumt haben, starten wir den Abgleich mit Wikidata via “Land" "Reconcile" "Start reconciling” und wählen den Service “Wikidata (en)” (oder die deutschsprachige Alternative) aus.

Fazit

Mit nur einem Klick können wir über die gleiche Oberfläche Daten in OpenRefine nicht nur mit der Gemeinsamen Normdatei (GND) via dem lobid API abgleichen, sondern auch mit Wikidata oder einer spezifischen Wikibase-Instanz wie zum Beispiel FactGrid für historische Daten.

Der OpenRefine Workshop für Einsteiger ist an dieser Stelle zu Ende. Bei Interesse werden Themen und Konzepte vertieft im OpenRefine Workshop für Fortgeschrittene.

OpenRefine Workshop für Fortgeschrittene

Workshop für Einsteiger - Warum OpenRefine?

Fri, 01 Apr 2022 00:00:00 +0000

In diesem Workshop für Einsteiger betrachten wir die grundlegenden Funktionen von OpenRefine im Archivalltag. Wir geben dabei nur eine grundlegende Einführung in den Umgang mit dem Programm und fokussieren uns gegen Ende auf den Abgleich mit Normdaten. Vertiefende Themen behandeln wir im Workshop für Fortgeschrittene.

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

Inhalte des Workshops

Zur Herkunft von OpenRefine

Ursprünglich wurde OpenRefine als Freebase Gridworks (OpenSource) für die Datenbanktechnologie Freebase entwickelt. Später wurde die entwickelnde Firma (Metaweb Technologies) von Google übernommen. Das Produkt wurde anschließend erst als Google Refine veröffentlicht und später als OpenRefine zu einem von der Community getragenen OpenSource Projekt.

Warum eigentlich OpenRefine?

OpenRefine is Excel on steroids!

Diese Aussage findet sich manchmal als Kurzbeschreibung von OpenRefine und ist genauso falsch wie goldrichtig. OpenRefine und Microsoft Excel haben unterschiedliche Anwendungsfälle.

Microsoft Excel ist ein Programm zur Tabellenkalkulation, wohingegen OpenRefine ein Programm zur Bereinigung, Umwandlung und Anreicherung von tabellarischen Daten ist.

Da aber Microsoft Excel zumindest bei uns häufig dafür eingesetzt wird, tabellarische Daten zu bereinigen, ist OpenRefine tatsächlich wie “Excel on steroids!”. Oder um einen Workshopteilnehmer zu zitieren:

Mit Excel hatten wir bisher einen Trabi.
Mit OpenRefine haben wir einen Ferrari bekommen.

OpenRefine und Künstliche Intelligenz?

Wie schon in Fünf Dinge, die wir an OpenRefine mögen berichtet, ermöglicht es die Architektur von OpenRefine, das Werkzeug sowohl auf einem Client (Laptop, Rechner), als auch auf einem Server laufen zu lassen. Die Bedienung erfolgt anschließend über den Browser.

--- title: OpenRefine Setup config: look: handDrawn theme: neutral --- flowchart LR subgraph server[fas:fa-server Server] server_or[fas:fa-gem OpenRefine] server_api[fas:fa-code Other API] end subgraph laptop[fas:fa-laptop Laptop] browser[far:fa-window-maximize Browser] laptop_or[fas:fa-gem OpenRefine] laptop_api[fas:fa-code Other API] laptop_python[fab:fa-python Python] end browser -.-> laptop_or & server_or laptop_python -.-> laptop_or & server_or laptop_or -.-> laptop_api & server_api server_or -.-> server_api

Wenn es auf einem Laptop eingesetzt wird, behält OpenRefine alle Daten lokal und führt auch die Bearbeitungen lokal durch. Erst wenn Daten aus dem Internet nachgeladen werden (Stichwort Reconciling), werden Daten an Dienste im Internet übermittelt.

Da OpenRefine verschiedene Clustering Methoden anbietet und über das Reconciliation API Protokoll den Zugriff auf Suchtechnologien ermöglicht, könnte man behaupten, dass OpenRefine die Bearbeitung von Daten mit künstlicher Intelligenz ermöglicht (konkret Maschinelles Lernen, ein Teilgebiet der künstlichen Intelligenz). Und damit gehört es genau zu der Art von Werkzeugen, die wir im FDMLab suchen, testen und bei Gefallen vorstellen.

OpenRefine und Big Data

Eine recht pragmatische Betrachtung von Big Data ist

Wenn es in den Arbeitsspeicher passt, ist es kein Big Data.

Sobald ein Datensatz zu groß ist, um ihn komplett im Arbeitsspeicher zu halten, werden Strategien aus dem Big Data Bereich benötigt, um sie bearbeiten zu können. OpenRefine hat solche Strategien (noch) nicht implementiert. ¹

Dabei ist der Begriff Big Data nach obiger Betrachtung sehr relativ. Ein normaler Bürorechner ist üblicherweise mit 2 GB Arbeitsspeicher ausgestattet, eine Data Science Workstation mit 128 GB (und mehr) und ein Superrechner teilweise mit mehr als 4.500.000 GB.

Es ist also nicht zu erwarten, dass der Bürorechner eines Sachbearbeiters mit OpenRefine riesige Datenlieferungen umwandeln und bereinigen kann, auch wenn das auf einem besser ausgestatteten Rechner eines Data Scientist problemlos möglich wäre.

Fazit

Wir setzen OpenRefine ein, wenn wir Daten für die Übernahme in unser Archivisches Fachinformationssystem vorbereiten, oder für die Veröffentlichung in anderen Informationssystemen umwandeln. Hierfür nutzten wir bisher Excel mit viel manuellen Tätigkeiten oder spezialisierte Werkzeuge, die explizit für das Zielsystem entwickelt wurden.

Mit OpenRefine haben wir nun eine Zwischenlösung, die es uns ermöglicht, langwierige manuelle Tätigkeiten zu automatisieren, ohne explizit Programme dafür zu entwickeln.

Auch beim Zusammenführen von Daten aus unterschiedlichen Datenquellen nimmt uns OpenRefine viele manuelle Arbeiten ab.

Im nächsten Teil gibt es eine allgemeine Einführung in die Bedienoberfläche von OpenRefine.

Die Oberfläche von OpenRefine

Dies ändert sich mit OpenRefine 4.0 und der geplanten Unterstützung von Apache Spark. ↩︎

Gemeinsam an OpenRefine-Projekten arbeiten

Tue, 07 Dec 2021 00:00:00 +0000

Im FDMLab testeten wir verschiedene Möglichkeiten mit OpenRefine gemeinsam an Projekten zu arbeiten. Dieser Artikel fasst unsere Erfahrungen beim kollaborativen Arbeiten mit OpenRefine 3.5.0 zusammen.

Wir hatten in Fünf Dinge, die wir an OpenRefine mögen schon darüber berichtet, dass uns die Architektur von OpenRefine gefällt, da sie es ermöglicht OpenRefine sowohl auf einem Client (Laptop, Rechner), als auch auf einem Server laufen zu lassen. Die Bedienung erfolgt anschließend über den Browser.

--- title: OpenRefine Setup config: look: handDrawn theme: neutral --- flowchart LR subgraph server[fas:fa-server Server] server_or[fas:fa-gem OpenRefine] end subgraph laptop[fas:fa-laptop Laptop] browser[far:fa-window-maximize Browser] laptop_or[fas:fa-gem OpenRefine] end browser -.-> laptop_or & server_or

Da läge es nahe, dass OpenRefine auch eine Benutzerverwaltung und eine Möglichkeit zum Kollaborativen Arbeiten an Projekten anbietet. Dafür gab es Pläne ein Broker Protokoll für OpenRefine einzuführen, die bisher aber weder umgesetzt noch eingeplant wurden.

In der Dokumentation von OpenRefine wird folgendes Vorgehen empfohlen:

Die beste Art, mit einer anderen Person zusammenzuarbeiten, ist, Projekte zu exportieren und zu importieren, wobei alle Änderungen gespeichert werden, so dass Sie an der Stelle weiterarbeiten können, wo die andere Person aufgehört hat.

Übersetzt von Starting a project: Import a project, aufgerufen am 01.12.2021.

--- title: Gemeinsam arbeiten - Strategie 1 config: look: handDrawn theme: neutral --- flowchart TD subgraph a["fa:fa-user Alice"] vaa["fa:fa-table Version A"] vab["fa:fa-table Version B"] vac["fa:fa-table Version C"] vad["fa:fa-table Version D"] end subgraph b["fa:fa-user Bob"] vba["fa:fa-table Version A"] vbb["fa:fa-table Version B"] end subgraph c["fa:fa-user Charly"] vcb["fa:fa-table Version B"] vcc["fa:fa-table Version C"] end vaa -.Übergabe.-> vba --Arbeiten--> vbb -.Übergabe.-> vab -.Übergabe.-> vcb --Arbeiten--> vcc -.Übergabe.-> vac --Arbeiten--> vad

Konkret bedeutet das, dass bei einer Kooperation von Alice, Bob und Charly zwar alle an dem gleichen Projekt arbeiten können, jedoch nicht gleichzeitig. Nachdem Alice das Projekt an Bob übergeben hat, arbeitet Bob daran. Nachdem Bob fertig ist, übergibt er das Projekt an Alice zurück, die es an Charly übergibt. Nachdem Charly fertig ist, übergibt er das Projekt an Alice zurück, die dann erst daran weiterarbeiten kann. Das war für uns im FDMLab ein eher unbefriedigender Zustand, weshalb wir zu einer anderen Strategie gewechselt haben.

--- title: Gemeinsam Arbeiten - Strategie 2 config: look: handDrawn theme: neutral --- flowchart LR subgraph a["fa:fa-user Alice"] va["fa:fa-table Version A"] vb["fa:fa-table Version B"] vc["fa:fa-table Version C"] vd["fa:fa-table Version D"] end subgraph b["fa:fa-user Bob"] pa["fa:fa-table Part A"] end subgraph c["fa:fa-user Charly"] pb["fa:fa-table Part B"] end va -.-> pa vb -.-> pb pa -.-> vc pb -.-> vd va --Arbeiten--> vb --Arbeiten--> vc --Arbeiten--> vd

Wir haben angefangen Teile eines Projektes in OpenRefine auszulagern und nach erfolgreicher Bearbeitung wieder in das Originalprojekt einzupflegen. So kann in unserem Beispiel Alice weiter an dem Projekt arbeiten, während Bob und Charly sie durch die Bearbeitung einzelner Teile unterstützen. Diese Teile werden anschließend von Alice wieder in das Originalprojekt eingepflegt. Wie das funktioniert besprechen wir in den folgenden Unterpunkten.

Zeilenweise zusammenführen

Manchmal ist es möglich, ein Projekt zeilenweise aufzuteilen. Also dass Alice die ersten 100 Zeilen, Bob die nächsten 100 und Charly die letzten 75 Zeilen bearbeitet.

Die Ergebnisse können nach der Bearbeitung als CSV-Dateien exportiert und daraus anschließend ein neues OpenRefine-Projekt erstellt werden.

Bildschirmfoto der Dateiauswahl Oberfläche von OpenRefine.

Wie in Abbildung 1 gezeigt, kann OpenRefine ein Projekt aus mehreren Dateien erstellen. Das kann auch ein Dateiarchiv sein, dessen Dateien in ein neues Projekt importiert werden.

Bildschirmfoto des Dateifilter Oberfläche von OpenRefine.

Bevor das Projekt konfiguriert wird, gibt es wie in Abbildung 2 gezeigt, die Möglichkeit einzelne Dateien aus- oder abzuwählen. Im Idealfall haben die einzelnen Dateien schon die gleichen Spaltenüberschriften in der richtigen Reihenfolge. Ansonsten bietet OpenRefine mit der Möglichkeit Spalten zu verbinden und Spalten zu verschieben die Möglichkeit das nachträglich zu bereinigen.

Spaltenweise zusammenführen

Ein häufiger Anwendungsfall im FDMLab ist, dass das Aufräumen und Transformieren der Daten von einer Person erledigt wird, die zum Beispiel beim Reconciling oder dem Abgleich mit weiteren Datenquellen von weiteren Personen unterstützt wird. Dafür werden einzelne Spalten als CSV (oder Excel) exportiert, von der unterstützenden Person bearbeitet und die Ergebnisse dann wieder in das Originalprojekt übernommen.

Ein anderer Fall kann sein, dass es schon einen anderen Datensatz gibt, dessen Daten komplett oder teilweise übernommen werden sollen. Das haben wir in Findbuchdaten mit OpenRefine wiederverwenden teilweise besprochen.

Beispiel

In unserem fiktiven Beispiel arbeitet Alice mit einem Datensatz der 16 Bundesländer, wie er in Abbildung 3 gezeigt ist. Diesen gibt sie an Bob und Charly weiter.

Bildschirmfoto der Oberfläche von OpenRefine mit den 16 Bundesländern.

Bob unterstützt Alice, indem er für die 16 Bundesländer das “Motto” recherchiert, er kann jedoch nicht für alle Bundesländer ein Motto finden und liefert den in Abbildung 4 gezeigten Datensatz zurück. ¹

Bildschirmfoto der Oberfläche von OpenRefine mit dem Motto einiger Bundesländer.

Charly hat die Aufgabe die Hauptstädte der einzelnen Bundesländer zu recherchieren, und liefert den in Abbildung 5 gezeigten Datensatz zurück. Dabei wurden jedoch die Namen der Bundesländer teilweise geändert, also zum Beispiel der Begriff “Freistaat” aus dem Namen wegoptimiert.

Bildschirmfoto der Oberfläche von OpenRefine mit den Hauptstädten der 16 Bundesländer.

Datensätze herunterladen

Die drei beschriebenen Datensätze können hier heruntergeladen werden, um die vorgestellten Methoden zum Zusammenführen von Daten beim gemeinsamen Arbeiten in OpenRefine selbst auszuprobieren

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

Bundesländer als CSV

Bundesländer Motto als CSV

Bundesländer Hauptstädte als CSV

ID Spalte erstellen

Wir werden die Daten auf drei Arten abgleichen:

Via einer dedizierten ID-Spalte
Mit einer improvisierten ID-Spalte (Name des Bundeslandes)
Via Reconciling

Idealerweise haben alle Datensätze eine einheitliche ID-Spalte zum Abgleichen. Diese lässt sich in OpenRefine über “Spaltenmenü" "Edit column" "Add column based on this column…” mit dem folgenden GREL Ausdruck anlegen:

row.index + 1

Wie in Abbildung 6 gezeigt, wird so eine ID-Spalte erzeugt, deren Nummerierung analog zur Nummerierung der Zeilen in OpenRefine verläuft.

Bildschirmfoto des Spalten hinzufügen Dialogs in OpenRefine.

Alternativ lassen sich manchmal auch ID-Spalten improvisieren, indem zum Beispiel bei Personen die Namen und Vornamen in eine ID-Spalte übernommen werden.

Zusammenführen mit cross()

Alice hat von Bob und Charly zwei CSV-Dateien bekommen, die sie in ihr OpenRefine-Projekt übernehmen möchte. Eine Möglichkeit, das innerhalb von OpenRefine zu erledigen, ist die Funktion cross().

Im OpenRefine-Wiki gibt es einige Beispiele zur Anwendung von cross(). Außerdem gibt es eine OpenRefine-Erweiterung für cross() um die Funktion über Dialoge in der Oberfläche von OpenRefine zu verwenden.

Wir verwenden die Funktion cross() ohne Erweiterung. Dafür erstellen wir für die drei Datensätze jeweils ein Projekt.

Projekt “Bundesländer” aus bundeslaender.csv
Projekt “Bundesländer Motto” aus bundeslaender-motto.csv
Projekt “Bundesländer Hauptstadt” aus bundeslaender-hauptstadt.csv

Wir verwenden absichtlich Umlaute und Leerzeichen im Projektnamen, um zu testen, ob OpenRefine beim Auflösen mit cross() damit klarkommt!

Zusammenführen via ID

Idealerweise haben wir eine eindeutige ID-Spalte, um die Projekte miteinander abzugleichen. Mit cross() können wir über die ID-Spalte Daten aus einem anderen OpenRefine-Projekt nachladen. Das funktioniert aber nur, wenn die IDs eindeutig sind.

Nachladen des Mottos

Zum Nachladen des Mottos der Bundesländer gehen wir im “Bundesländer”-Projekt über das Spaltenmenü “ID" "Edit column" "Add column based on this column…” und verwenden den folgenden GREL Ausdruck.

cell.cross("Bundesländer Motto", "ID").cells["Mottotext"].value[0]

Dabei ist “Bundesländer Motto” der Name des Projektes aus dem wir die Daten holen wollen, und “ID” die ID-Spalte im Projekt “Bundesländer Motto”.

Bildschirmfoto des Spalten hinzufügen Dialogs mit cross() für den Mottotext in OpenRefine.

Wie in Abbildung 7 gezeigt, werden die Daten (also der Mottotext) aus dem anderen Projekt nachgeladen. Es haben nicht alle Bundesländer einen Mottotext hinterlegt, was den Abgleich nicht weiter stört.

Nachladen der Hauptstadt

Zum Nachladen der Hauptstadt der Bundesländer gehen wir im “Bundesländer”-Projekt über das Spaltenmenü “ID" "Edit column" "Add column based on this column…” und verwenden den folgenden GREL Ausdruck.

cell.cross("Bundesländer Hauptstadt", "ID").cells["Hauptstadt"].value[0]

Dabei ist “Bundesländer Hauptstadt” der Name des Projektes aus dem wir die Daten holen wollen, und “ID” die ID-Spalte im Projekt “Bundesländer Hauptstadt”.

Bildschirmfoto des Spalten hinzufügen Dialogs mit cross() für die Hauptstadt in OpenRefine.

Wie in Abbildung 8 gezeigt, werden die Daten (hier die Hauptstadt) aus dem anderen Projekt nachgeladen. Es haben alle Bundesländer eine Hauptstadt, so dass der Abgleich hier für jeden Eintrag ein Ergebnis produziert.

Außerdem ist zu erwähnen, dass sich OpenRefine hier auch nicht daran stört, dass die ID-Spalte bei uns im Projekt “Bundesländer” als Zahl, im Projekt “Bundesländer Motto” jedoch als Typ Text gespeichert ist.

Zusammenführen via Werte

Es ist nicht immer eine eindeutige ID-Spalte vorhanden. Das kommt zum Beispiel vor, wenn die Daten aus verschiedenen Projekten stammen. Man kann auch ID-Spalten improvisieren, was aber nicht immer zum gewünschten Ergebnis führt. Wir werden den Abgleich mit cross() diesmal über die Spalte “Bundesland” durchführen.

Nachladen des Mottos

Zum Nachladen des Mottos der Bundesländer gehen wir im “Bundesländer”-Projekt diesmal über das Spaltenmenü “Bundesland“ "Edit column" "Add column based on this column…” und verwenden den folgenden GREL Ausdruck.

cell.cross("Bundesländer Motto", "Bundesland").cells["Mottotext"].value[0]

Wie in Abbildung 9 zu sehen ist, hat der Abgleich zwischen diesen beiden Projekten kein Problem, da die Bundesländer hier einheitlich geschrieben sind.

Bildschirmfoto des Spalten hinzufügen Dialogs mit cross() für den Mottotext in OpenRefine.

Nachladen der Hauptstadt

Zum Nachladen der Hauptstädte der Bundesländer gehen wir im “Bundesländer”-Projekt diesmal über das Spaltenmenü “Bundesland“ "Edit column" "Add column based on this column…” und verwenden den folgenden GREL Ausdruck.

cell.cross("Bundesländer Hauptstadt", "Bundesland").cells["Hauptstadt"].value[0]

Wie in Abbildung 10 zu sehen ist, hat der Abgleich hier Probleme, da die Bundesländer teilweise unterschiedlich geschrieben sind. Es fehlen Ergänzungen wie “Freistaat”. Daher können die Daten für diese Bundesländer nicht nachgeladen werden.

Bildschirmfoto des Spalten hinzufügen Dialogs mit cross() für die Hauptstadt in OpenRefine.

Ergebnis

Bildschirmfoto von OpenRefine mit den Bundesländern und den zusätzlichen Spalten aus anderen Projekten.

Der Abgleich mit cross() innerhalb von OpenRefine funktioniert recht einfach, solange es eine Spalte mit eindeutigen Werten gibt. Der Abgleich stört sich auch nicht an Sonderzeichen, Leerzeichen oder fehlenden Werten.

Problematisch wird es, wenn die Werte der Spalten, die abgeglichen werden, nicht komplett übereinstimmen. Diese sind in Abbildung 11 farblich hervorgehoben. In solchen Fällen empfiehlt sich das im nächsten Abschnitt besprochene lokale Reconciling.

Zusammenführen mit lokalem Reconciling

Wir hatten in Fünf Dinge, die wir an OpenRefine mögen schon die Architektur von OpenRefine gelobt, da diese so gestaltet ist, dass OpenRefine auch mit anderen APIs kommunizieren kann. Besonders unterstützt ist dabei das Reconciliation Service API Protokoll. Damit können Daten in einem OpenRefine-Projekt nicht nur gegen Wikidata oder die GND abgeglichen werden, sondern mit Werkzeugen wie csv-reconcile auch mit lokalen CSV-Dateien.

--- title: OpenRefine Setup config: look: handDrawn theme: neutral --- flowchart LR subgraph server[fas:fa-server Server] server_or[fas:fa-gem OpenRefine] server_api[fas:fa-code Reconciliation Service API] end subgraph laptop[fas:fa-laptop Laptop] browser[far:fa-window-maximize Browser] laptop_or[fas:fa-gem OpenRefine] laptop_api[fas:fa-code Reconciliation Service API] end browser -.-> laptop_or & server_or laptop_or -.-> laptop_api & server_api server_or -.-> server_api

Für die Verwendung von csv-reconcile benötigt man Python auf seinem System. Ist Python vorhanden, dann kann csv-reconcile einfach via Shell (PowerShell, Git Bash, …) installiert werden. Wir erstellen dafür erst eine virtuelle Umgebung in unserem Arbeitsordner, um csv-reconcile ausschließlich dort zu installieren.

Der Arbeitsordner ist der Ordner, in dem wir unsere CSV-Dateien liegen haben, mit denen wir hier arbeiten.

Die virtuelle Umgebung für Python ermöglicht es uns, Python Bibliotheken nur für dieses Projekt zu installieren, so dass sie nicht mit Bibliotheken oder Python Versionen in anderen Projekten in Konflikt kommen.

> python -m venv venv # virtuelle Umgebung erstellen
> .\venv\Scripts\activate # virtuelle Umgebung aktivieren (Windows!)
(venv) > pip install csv-reconcile # csv-reconcile in virtuelle Umgebung installieren

Da csv-reconcile in Version 0.3.0 den Vorschaudienst optional anbietet und keine automatische Erkennung von Encoding und Trennzeichen in CSV-Dateien hat, erstellen wir in unserem Arbeitsordner zusätzlich eine Datei config.py mit dem folgenden Inhalt.

CSVKWARGS={'delimiter': ',', 'quotechar': '"'}
CSVENCODING='UTF-8'
MANIFEST = {
 "preview": {
 "url": "http://localhost:5000/preview/{{id}}",
 "width": 400,
 "height": 300
 }
}

Anschließend können wir mit aktivierter virtueller Umgebung in unserem Arbeitsordner den lokalen Reconciling Service für die “Bundesländer Motto” CSV-Datei initiieren und starten.

(venv) > csv-reconcile init --config config.py bundeslaender-motto.csv ID Bundesland
(venv) > csv-reconcile serve

Wenn wir mit dieser Datei fertig sind, können wir den lokalen Reconciling Service für die “Bundesländer Hauptstadt” CSV-Datei initiieren und starten.

Ob die virtuelle Umgebung aktiv ist, sieht man an der Ergänzung (venv) in der Shell. Ansonnsten lässt sie sich mit .\venv\Scripts\activate wieder aktivieren.

(venv) > csv-reconcile init --config config.py bundeslaender-hauptstadt.csv ID Bundesland
(venv) > csv-reconcile serve

Wir könnten die beiden lokalen Reconciling Services auch parallel laufen lassen, indem wir sie in unterschiedliche Ordner schieben und wie unter csv-reconcile: Common configuration beschrieben über die Variable SERVER_NAME in der config.py jeweils einen anderen Port setzen.

In OpenRefine fügen wir den lokalen Reconciliation Service hinzu, indem wir in einem Projekt über ein beliebiges “Spaltenmenü" "Reconcile" "Start reconciling” aufrufen und dort via “Add Standard Service…” die Adresse http://localhost:5000/reconcile eingeben. Der Port 5000 muss entsprechend angepasst werden, wenn er in der config.py geändert wurde.

Siehe auch die OpenRefine-Dokumentation zu Reconciling: Getting started.

Zusammenführen via ID

Idealerweise haben wir eine eindeutige ID-Spalte, um die Projekte miteinander abzugleichen. Dann ist der lokale Reconciliation Service fast schon etwas zu mächtig, und wird von uns eher eingesetzt, wenn wir es vermeiden wollen, zu viele OpenRefine-Projekte zu jonglieren.

Nachladen des Mottos

Wir haben den lokalen Reconciling Service für das “Bundesländer Motto”-Projekt, wie im oberen Abschnitt beschrieben, am laufen.

Zum Nachladen des Mottos der Bundesländer gehen wir im “Bundesländer”-Projekt über das Spaltenmenü “ID" "Reconcile" "Use values as identifiers” und wählen unseren CSV Reconciliation Service aus.

Die IDs werden nun alle zu Links. Wie im Maus-Hover in Abbildung 12 sehen wir, dass nicht alle IDs aufgelöst werden, sondern manchmal eine “Nicht gefunden” Meldung angezeigt wird. Zur Erinnerung: es gibt nicht für alle Bundesländer ein Motto in unseren Daten!

Bildschirmfoto des Maus-Hover ‘Not Found’ in OpenRefine.

Den Mottotext können wir über “ID" "Edit column" "Add columns from reconciled values…” nachladen. Wie in Abbildung 13 zu sehen ist, kann der Dienst auch mit nicht auflösbaren IDs umgehen und ignoriert diese einfach.

Bildschirmfoto des Reconciliation Dialogs mit dem Mottotext in OpenRefine.

Nachladen der Hauptstadt

Wir haben den lokalen Reconciling Service für das “Bundesländer Hauptstadt”-Projekt, wie im oberen Abschnitt beschrieben, am laufen.

Zum Nachladen der Hauptstädte der Bundesländer gehen wir wieder im “Bundesländer”-Projekt über das Spaltenmenü “ID" "Reconcile" "Use values as identifiers” und wählen unseren CSV Reconciliation Service aus.

Die IDs werden nun alle wieder zu Links. Bei diesem Abgleich können alle IDs aufgelöst werden und wir sehen wie in Abbildung 14 überall Maus-Hover mit den entsprechenden Werten des gematchten Eintrags in der CSV-Datei.

Bildschirmfoto des Maus-Hover mit CSV Werten in OpenRefine.

Zusammenführen via Werte

Es ist nicht immer eine eindeutige ID-Spalte vorhanden. In so einem Fall spielt der lokale Reconciliation Service seine Stärke aus, da wir mit ihm auch “ungenaue” Werte finden und matchen können.

Nachladen des Mottos

Wir haben den lokalen Reconciling Service für das “Bundesländer Motto”-Projekt, wie im oberen Abschnitt beschrieben, am laufen.

Zum Nachladen der Mottos der Bundesländer über die Wertespalte gehen wir zu “Bundesland" "Reconcile" "Start reconciling” und wählen den “CSV Reconciling Service” aus.

Wie in Abbildung 15 markiert, ist das automatische Matching etwas zu großzügig, so dass Bundesländer gematcht werden, weil sie zum Beispiel beide den Begriff “Freistaat” im Namen haben. Das kann manuell und bei größeren Datenmengen mit der Unterstützung von Facets auf den Konfidenzwerten (Wert wie gut das Matching passt) nachgearbeitet werden.

Bildschirmfoto des Ergebnis des automatischen Reconciling in OpenRefine.

Den Mottotext können wir dann wieder über “Bundesland" "Edit column" "Add columns from reconciled values…” nachladen. Wie in Abbildung 16 zu sehen ist, kann der Dienst auch in diesem Fall mit nicht auflösbaren IDs umgehen und ignoriert diese einfach.

Bildschirmfoto des Reconciliation Dialogs mit dem Mottotext in OpenRefine.

Nachladen der Hauptstadt

Wir haben den lokalen Reconciling Service für das “Bundesländer Hauptstadt”-Projekt, wie im oberen Abschnitt beschrieben, am laufen.

Zum Nachladen der Hauptstädte der Bundesländer über die Wertespalte gehen wir zu “Bundesland" "Reconcile" "Start reconciling” und wählen den “CSV Reconciliation Service” aus.

Da wir in diesem Datensatz passende Einträge für alle Bundesländer haben, funktioniert das Matching, wie in Abbildung 17 zu sehen ist, recht gut, obwohl die Bundesländer teilweise anders geschrieben sind.

Bildschirmfoto der Oberfläche von OpenRefine mit den Reconciliation Ergebnissen für die Bundesländer.

Ergebnis

Der Abgleich mit dem lokalen Reconciling Service hat initial einen höherne Aufwand, da sowohl Python auf dem System als auch der CSV Reconciling Service in OpenRefine eingerichtet werden müssen. Dann ist das Verfahren jedoch deutlich flexibler als das Zusammenführen mit cross(), da darüber sowohl ein exaktes ID Matching und Nachladen von Spalten durchgeführt werden kann, als auch ein so genanntes Fuzzy-Matching, bei dem die Werte in den Spalten nicht exakt übereinstimmen.

In Abbildung 18 sind nochmal alle nachgeladenen Spalten abgebildet, wobei

via cross() auf der ID-Spalte
via cross() auf der Werte-Spalte (Namen Bundesland)
via lokalem Reconciling Service auf der ID-Spalte
via lokalem Reconciling Service auf der Werte-Spalte (Namen Bundesland)

nachgeladen wurde.

Bildschirmfoto von OpenRefine mit den Bundesländern und den zusätzlichen Spalten aus anderen Projekten.

Ausblick auf weitere Methoden

Für das Zusammenführen von Datensätzen mit OpenRefine gibt es noch weitere Möglichkeiten, die sich aktuell in der Planung und Entwicklung befinden.

Zum einen gibt es Überlegungen für Projekte in OpenRefine automatisch einen Reconciliation Service zu erstellen, so dass analog zu cross() direkt innerhalb von OpenRefine ein Reconciling gegen andere Projekte durchgeführt werden kann. Also Reconciling innerhalb von OpenRefine ohne separaten lokalen Reconciling Service.

Zum anderen gibt es mit Datasette ein komplettes Ökosystem um Daten in SQLite einzulesen und anschließend via unterschiedlicher APIs zur Verfügung zu stellen. Es wird gerade auch ein Reconciliation Plugin für Datasette entwickelt.

Gibt es in Arbeitsgruppen Datensätze, die intern oder extern veröffentlicht und auch für Reconciliation genutzt werden sollen, dann lohnt sich ein Blick auf dieses Werkzeug.

Fazit

OpenRefine bietet mit seiner Architektur das Potential zukünftig kollaboratives Arbeiten zu ermöglichen. Bis dahin können wir uns selbst helfen und mit wenig Extraaufwand Aufgaben aufteilen und die Ergebnisse wieder zusammenführen. Mit der cross() Funktion können wir direkt Daten aus anderen OpenRefine-Projekten über ID-Spalten übernehmen. Mit einem lokalem Reconciling Service können wir auch Daten aus unterschiedlichen Projekten verbinden.

Bisher klappt das beschriebene Vorgehen im FDMLab ganz gut und wir beobachten weiterhin gespannt die Entwicklung sowohl von OpenRefine, als auch von anderen Werkzeugen wie csv-reconcile und Datasette, die es hervorragend ergänzen.

Die Mottotexte wurden aus Wikidata geladen und sind daher genauso (un)vollständig, wie die Daten dort. ↩︎

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

Named Entity Recognition mit OpenRefine und spaCy

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

In diesem Artikel beschreiben wir unsere Versuche mit OpenRefine ein “Named Entity Recognition” mit spaCy durchzuführen, um die Entities anschließend mit der Gemeinsamen Normdatei (GND) abzugleichen.

OpenRefine kann Python Code ausführen. Dann sollte es doch auch möglich sein, damit eine “Named Entity Recognition” mit dem auf Python basierten Framework spaCy durchzuführen. ⚠️ Leider hat es sich gezeigt, dass sich die Umsetzung technischer gestaltet als erwartet.

Da wir uns vornahmen auch negative Erfahrungen zu berichten gehen wir wie folgt vor:

Wir beschreiben, wie wir uns die Umsetzung vorgestellt hätten.
Wir erklären, weshalb das nicht funktioniert.
Wir zeigen eine flexible, dafür technisch aufwendigere Lösung.

Versuch: spaCy in OpenRefine ausführen

OpenRefine bringt mit Jython eine Java Implementierung für Python mit. Theoretisch ist es also möglich das Python Framework spaCy als Python Paket zu installieren und direkt in OpenRefine auszuführen.

Unser gedachtes Vorgehen: wir nehmen an, dass wir auf einem Windows System sind. Dort gehen wir mit dem Dateiexplorer in den OpenRefine Ordner mit integrierter Java Umgebung und öffnen dort eine PowerShell. Dann aktivieren wir mit Jython den Python Paketmanager pip (Zeile 1), installieren spaCy (Zeile 2) und laden ein deutsches Sprachmodell (Zeile 3).

1
2
3


.\server\target\jre\bin\java.exe -jar .\webapp\extensions\jython\module\MOD-INF\lib\jython-standalone-2.7.2.jar -m ensurepip
.\server\target\jre\bin\java.exe -jar .\webapp\extensions\jython\module\MOD-INF\lib\jython-standalone-2.7.2.jar -m pip install spacy
.\server\target\jre\bin\java.exe -jar .\webapp\extensions\jython\module\MOD-INF\lib\jython-standalone-2.7.2.jar -m spacy download de_core_news_sm

Hätte das funktioniert, könnten wir nun im “expression” Editor zum Beispiel beim Hinzufügen oder Transformieren von Spalten von GREL auf Jython umstellen und mit folgendem Code ein “Named Entity Recognition” mit spaCy auf den Inhalten durchführen.

import spacy
nlp = spacy.load("de_core_news_sm")
doc = nlp(value)
return "\n".join(ent.text + "||" + ent.label_ for ent in doc.ents)

🚫 Leider funktioniert die Installation von spaCy in Jython via pip nicht.

Technische Hintergründe

Jython implementiert aktuell Python in Version 2.7. Seit Januar 2020 wird Python in Version 2 jedoch nicht mehr weiterentwickelt und auch nicht mehr mit Bugfixes versorgt (Status end-of-life). Die aktuelle Version von Python ist Version 3.9.

Entsprechend sind Bibliotheken in aktueller Version häufig auch nur noch mit Unterstützung für Python 3 zu finden. Eine Neuentwicklung von Jython um Python in Version 3 zu unterstützen, oder basierend auf neuer Technologie wie GraalVM nutzbar zu machen, ist nach wie vor in Planung/Umsetzung (siehe Python 3 Roadmap).

Aber auch ältere Versionen von Bibliotheken mit Unterstützung für Python 2 sind nicht einfach via pip zu installieren. Das liegt daran, dass Jython auf Java basiert, viele Python Bibliotheken unter der Haube jedoch Abhängigkeiten zur Programmiersprache C haben.

Alternative: spaCy separat ausführen

Wenn wir spaCy nicht in OpenRefine zum Laufen bekommen, dann können wir es stattdessen separat als Webservice betreiben.

In “Fetching and Parsing Data from the Web with OpenRefine” wird gezeigt, wie mit OpenRefine das Text Processing API verwendet werden kann. Das Projekt unterstützt aktuell Englisch, Holländisch, Portugiesisch und Spanisch. Ähnliche Freemium Angebote gibt es auch mit deutschen Sprachmodellen.

Anstatt einen externen Dienst zu bemühen, wollen wir den Dienst lokal laufen lassen. Dafür packen wir spaCy mit FastAPI in ein API und verwenden Uvicorn als Server.

Python 3.9 installieren

Python 3.9 kann in Form einer ausführbaren Datei (.exe) von Python Downloads heruntergeladen und lokal installiert werden.

Virtuelle Umgebung aufsetzen

Wir erstellen einen Ordner ner-service. In dem Ordner starten wir eine PowerShell. Dann erstellen wir mit Python eine so genannte virtuelle Umgebung (Zeile 1). ¹ Die virtuelle Umgebung aktivieren wir anschließend (Zeile 2), installieren die benötigten Programme (Zeile 3) und laden das Sprachmodell mit spaCy herunter (Zeile 4).

1
2
3
4


python -m venv venv
.\venv\Scripts\activate
pip install fastapi python-multipart spacy uvicorn
python -m spacy download de_core_news_sm

NER Service erstellen

Den folgenden Python Code speichern wir in dem Ordner ner-service in der Datei simple-ner-service.py.

import spacy
import uvicorn
from fastapi import FastAPI, Form

app = FastAPI()
nlp = spacy.load("de_core_news_sm")


@app.post("/ner")
def ner(text: str = Form(...)):
 doc = nlp(text)
 return [{"text": ent.text, "label": ent.label_} for ent in doc.ents]


if __name__ == "__main__":
 uvicorn.run("simple-ner-service:app", host="127.0.0.1", port=5000)

Mit aktivierter virtueller Umgebung können wir den Server mit der PowerShell aus dem Ordner ner-service heraus starten:

1
2


.\venv\Scripts\activate
python .\simple-ner-service.py

NER Service in OpenRefine nutzen

In OpenRefine schicken wir im “expression” Editor den Inhalt einer Zelle (value) mit Jython an den ner-service unter http://localhost:5000/ner und geben das Ergebnis im JSON Format zurück. Dabei haben wir auf die Kodierung (“encoding”) zu achten, da Python 2 standardmäßig nicht mit UTF-8 arbeitet. Ein Problem, das in englischsprachigen Anleitungen häufig nicht relevant ist und daher ignoriert wird.

import json, urllib, urllib2
url = 'http://localhost:5000/ner'
request_data = urllib.urlencode({"text": value.encode('utf-8')})
response = urllib2.urlopen(url, request_data)
return json.dumps(json.load(response), ensure_ascii=False)

Die Vorschau des “expression” Editors in OpenRefine zeigt die ersten Ergebnisse.

OpenRefine ermöglicht es Spalten basierend auf URLs hinzuzufügen. Dabei werden so genannte GET-Requests ausgeführt, die von der Zeichenbeschränkung für URLs betroffen sind. Daher ist es empfehlenswert Texte via POST-Requests zu versenden, weshalb wir die Anfrage mit Python und urllib2 ausführen.

Zusammenfassung und Erweiterung

Mit etwa 15 Zeilen Python Code haben wir die Daten aus OpenRefine heraus mit einen (lokalen) Service verknüpft, der aufbauend auf der neuesten Technologie eine “Named Entity Recognition” durchführen kann.

Dabei ist der Ansatz so generisch, dass er auf ähnliche Anwendungen übertragen werden kann. Daher haben wir den minimalen Ansatz noch optimiert, dokumentiert und als GitHub Gist zur Verfügung gestellt.

NER mit OpenRefine und spaCy

--- title: Prozess config: look: handDrawn theme: neutral --- flowchart LR text[fas:fa-file-alt Text] spacy[fab:fa-python spaCy] data[fas:fa-list-alt Entities] gnd[fas:fa-database GND] semantic[fas:fa-project-diagram Graph] text --> data --> semantic spacy --> data gnd --> semantic

Mit dem funktionierenden NER Service können wir nun unserer ursprünglichen Idee nachgehen und ein “Named Entity Recognition” mit spaCy durchführen und die “Entities” anschließend mit der Gemeinsamen Normdatei (GND) abgleichen.

NER Service starten

Zuerst starten wir unseren NER Service. Dafür benötigen wir - wie im oberen Abschnitt beschrieben - Python 3 und eine virtuelle Umgebung mit spaCy, FastAPI und Uvicorn. Dort starten wir die Datei ner-service.py aus dem GitHub Gist.

Der NER Service ist nach dem Start unter http://localhost:5000 zu erreichen und kann wie in Abbildung 1 in einer interaktiven Dokumentation auch gleich getestet werden.

Bildschirmfoto der interaktiven API Dokumentation des NER Service.

OpenRefine Projekt erstellen

💾 Für OpenRefine haben wir einige Textschnippsel aus Wikipedia zusammengesucht (CC-BY-SA-3.0) und bieten diese mit Quellangabe unter gleichen Lizenzbedingungen in einer JSON Datei zum Download an (Rechtsklick und “Ziel speichern unter…”):

Wikipedia Textschnippsel als JSON .

Mit der JSON Datei erzeugen wir wie in Abbildung 2 ein neues Projekt in OpenRefine.

Bildschirmfoto zur Erstellung des Projektes mit einer JSON Datei in OpenRefine.

Anschließend benennen wir die Spalten zur Übersichtlichkeit in Quelle und Text um.

NER auf Text durchführen

Um eine “Named Entity Recognition” durchzuführen, erzeugen wir eine neue Spalte NER basierend auf der Spalte Text und verwenden wie in Abbildung 3 eine Jython Expression.

import json, urllib, urllib2
url = 'http://localhost:5000/ner'
request_data = json.dumps({'text': value.encode('utf-8')})
request = urllib2.Request(url, request_data, {'Content-Type': 'application/json'})
response = urllib2.urlopen(request)
return json.dumps(json.load(response), ensure_ascii=False)

Wir haben die “expression” im Vergleich zu unserem Test abgeändert, da wir bei der Überarbeitung des NER Service von form-urlencoded zu JSON wechselten.

Bildschirmfoto mit Dialog zur Durchführung von NER in OpenRefine.

Informationen aus JSON extrahieren

Um die Informationen aus dem JSON formatierten Text zu extrahieren, verwenden wir die Werkzeuge von GREL. Dafür erzeugen wir wie in Abbildung 4 eine neue Spalte Entity aus der Spalte NER mit einer"expression".

forEach(parseJson(value), v, v.text).join("||")

Bildschirmfoto mit Dialog zur Erzeugung einer neuen Spalte mit dem Entity Text in OpenRefine.

Für den Typ der Entities erzeugen wir wie in Abbildung 5 eine neue Spalte Label aus der Spalte NER mit einer “expression”.

forEach(parseJson(value), v, v.label).join("||")

Bildschirmfoto mit Dialog zur Erzeugung einer neuen Spalte mit dem Entity Label in OpenRefine.

Wir haben nun mehrere Werte in einer Zelle, weshalb wir diese wie in Abbildung 6 mit “Entity" "Edit Cells" "Split multi-valued cells…” und “Label" "Edit Cells" "Split multi-valued cells…” an der Trennsequenz || auftrennen.

Bildschirmfoto mit Dialog zur Aufteilung der Entities in mehrere Zeilen in OpenRefine.

Daten mit GND abgleichen

Nun haben wir die gefundenen Entities in einzelnen Zeilen und können sie nach Belieben bearbeiten, löschen oder mit externen Diensten abgleichen. Dafür verwenden wir den GND Reconciliation Service von lobid. Mit “Entity" "Reconcile" "Start reconciling” starten wir den Abgleichsvorgang. Siehe auch Findbuch Index mit OpenRefine aufbereiten für Details zum Datenabgleich von Daten in OpenRefine mit der Gemeinsamen Normdatei (GND). In Abbildung 7 haben wir einen Screenshot der Daten, nachdem die Entities mit der GND abgeglichen und mit der GND-ID angereichert wurden.

Bildschirmfoto der zugeordneten Entities in OpenRefine.

Fazit

In diesem Beitrag haben wir eine Möglichkeit gezeigt, wie generell mit OpenRefine Daten an einen lokalen Service übergeben und verarbeitet werden können. Das haben wir genutzt um ein “Named Entity Recognition” mit spaCy durchzuführen.

Wir hätten uns gewünscht, dass die Integration von Python Frameworks in OpenRefine direkter und weniger technisch zu bewerkstelligen wäre. Andererseits haben wir mit FastAPI eine Framework getestet, mit dem unkompliziert Dienste zur Verfügung gestellt werden können.

Eine virtuelle Umgebung ermöglicht es uns, die für dieses Projekt benötigten Abhängigkeiten direkt in den Ordner zu installieren, und bei Bedarf das komplette Projekt mit allen Abhängigkeiten wieder aufzuräumen. ↩︎

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

Findbücher mit OpenRefine in Datenbank übernehmen

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

In diesem ausführlichen Tutorial wandeln wir mit OpenRefine ein Findbuch zu Akten des Reichskammergerichts in ein AFIS kompatibles Importformat um. Hierbei setzen wir gezielt einfache und verständliche Techniken ein.

Dieses Tutorial ist so geschrieben, dass die einzelnen Schritte direkt in einer eigenen OpenRefine Umgebung nachvollzogen werden können. Die benötigten Dateien stehen im Laufe des Tutorials als 💾 Download zur Verfügung.

Findbuchdigitalisierung

Wir haben im FDMLab unterschiedliche Findbücher digitalisiert und in unser AFIS überführt. Teilweise existierten die Findbücher als Word-Dateien, teilweise als PDF und teilweise ausschließlich als analoge Bücher. Über unseren Workflow beim Digitalisieren von Findbüchern und über die Bedeutung von regulären Ausdrücken bei der Textextraktion haben wir schon berichtet.

Um einen hohen Automatisierungsgrad zu erreichen, haben wir Technologien wie Docker, Jupyter NoteBooks, Python, flairNLP und spaCy eingesetzt.

Das ist sinnvoll, wenn - wie im Fall der Findbücher zu den Akten des Reichskammergerichts - mehrere Findbücher mit ähnlicher Struktur existieren. Die Beherrschung dieser Technologien setzt jedoch technische Grundkenntnisse voraus, deren Aneignung recht zeitintensiv ist.

Daher stellen wir mit OpenRefine eine Möglichkeit vor, wie Findbücher semimanuell für den Import in Datenbanksysteme vorbereitet werden können. Hierbei setzen wir explizit mehr auf nachvollziehbare Schritte und weniger auf automatisierte, universell wiederverwendbare Code-Schnipsel.

Generelles Vorgehen

In diesem Tutorial extrahieren wir 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”. Hierbei handelt es sich um 20 Findbucheinträge. Dies ist eine übersichtliche Anzahl für ein Tutorial. Wir haben die Techniken auch mit einem größeren Findbuch mit ca. 400 Einträgen getestet.

Exemplarisch ist der erste Eintrag des Findbuchs in Abbildung 1 gezeigt. Jeder Findbucheintrag ist in die folgenden acht nummerierten Abschnitte eingeteilt: (1) Bestellsignatur und Laufzeit, (2) Kläger, (3) Beklagter, (4) Prokuratoren, (5) Prozessart und Streitgegenstand, (6) Vorinstanzen, (7) Darinvermerk, (8) weitere Angaben. Einige dieser Abschnitte sind optional. Bei dem ersten Eintrag fehlt zum Beispiel der Abschnitt 6 mit den Vorinstanzen.

Erster Eintrag aus dem Findbuch Inventar von R J 10

Die einzelnen Abschnitte enthalten teilweise zusammenhängende Informationsbestandteile (Beklagte, Prokuratoren, Vorinstanzen, …). Teilweise enthalten sie jedoch auch mehrere Informationsbestandteile, wie zum Beispiel im ersten Abschnitt.

1 1 Nr ( C 2145 Altsignatur ) 1597 – 1600 Laufzeit
Vorsignatur: R Rep. 9 Nr. 230 Vorsignatur

Wir gehen bei der Extraktion in mehreren Schritten vor:

Einträge des Inventars aus Findbuch extrahieren
Einträge in Abschnitte aufteilen
Einzelne Informationsbestandteile aus Abschnitten in Tabelle extrahieren
Einzelne Informationsbestandteile aus Tabelle auf Datenbankschema übertragen

--- title: Datenextraktion Mapping config: look: handDrawn theme: neutral --- flowchart LR subgraph findbuch[fas:fa-font Findbuch] intro[Einführung] Inventar Index end subgraph abschnitte[far:fa-list-alt Abschnitte] a1[Abschnitt 1] a2[Abschnitt 2] a3[Abschnitt 3] a4[Abschnitt 4] a5[Abschnitt 5] a6[Abschnitt 6] a7[Abschnitt 7] a8[Abschnitt 8] end subgraph data[fas:fa-table Daten] nr[Nr] Altsignatur Vorsignatur Laufzeit Klaeger[Kläger] Beklagte Prokuratoren Prozessart Gegenstand Vorinstanzen Darin Umfang Stapelhoehe[Stapelhöhe] Hinweise end subgraph db[fas:fa-database Datenbank] Titel Bestellsignatur Vorsignatur1[Vorsignatur 1] Vorsignatur2[Vorsignatur 2] Entstehungszeitraum[Entstehungszeitraum] EntstehungszeitraumA[Entstehungszeitraum, Anm.] db_Beklagte[Beklagte] Bemerkung db_Gegenstand[Gegenstand] Enthaelt[Enthält] db_Umfang[Umfang] end Inventar --> abschnitte a1 --> nr & Laufzeit & Altsignatur & Vorsignatur a2 --> Klaeger a3 --> Beklagte a4 --> Prokuratoren a5 --> Gegenstand & Prozessart a6 --> Vorinstanzen a7 --> Darin a8 --> Umfang & Stapelhoehe & Hinweise Klaeger --> Titel nr --> Bestellsignatur Altsignatur --> Vorsignatur1 Vorsignatur --> Vorsignatur2 Laufzeit --> Entstehungszeitraum & EntstehungszeitraumA Beklagte --> db_Beklagte Vorinstanzen & Hinweise--> Bemerkung Prozessart --> db_Gegenstand Prokuratoren & Gegenstand & Darin--> Enthaelt Umfang & Stapelhoehe --> db_Umfang

Zur Vollständigkeit: In anderen Findbüchern zu den Akten des Reichskammergerichtes im Landesarchiv BW gibt es noch weitere Informationen, wie zum Beispiel eine separate Bestellsignatur, Schadensbeschreibungen, Literaturhinweise, Hinweise auf Abgabe der Akten an andere Institutionen, … Außerdem gibt es in unserem Erfassungsschema noch weitere Felder, die für alle Findbucheinträge mit einem festen Wert vorbelegt wurden.

Diese Spezialbehandlungen ignorieren wir für dieses Tutorial.

Technische Voraussetzungen

OpenRefine

Bei OpenRefine handelt es sich um ein Excel ähnliches Werkzeug im Browser, mit dem Daten in andere Formate überführt werden können. Details zur Funktionsweise gibt es in der Dokumentation von OpenRefine und in den Erklärvideos zu OpenRefine.

Wir verwenden das Windows kit with embedded Java, mit dem wir ohne Administrationsrechte oder separater Java-Installation direkt loslegen können.

Auch wenn die Arbeit mit OpenRefine im Browser stattfindet, so liegen die Daten trotzdem lokal auf der eigenen Festplatte. Eine Datenübertragung findet dann statt, wenn zum Beispiel ein so genanntes Reconciling durchgeführt wird, bei dem die Daten mit einem Dienst im Web abgeglichen werden.

Reguläre Ausdrücke

Perl Problems von Randall Munroe unter CC BY-NC Lizenz.

Bei Memes zu regulären Ausdrücken wird wie in Abbildung 2 häufig der Eindruck erweckt, dass sie mehr Probleme erzeugen als sie tatsächlich lösen. Richtig dosiert sind sie jedoch ein hilfreiches Werkzeug bei der Datenextraktion.

Zum Entwickeln, Testen und Verstehen von regulären Ausdrücken, nutzen wir RegEx101 (Alternative: RegExr). Hier bekommen wir wie in Abbildung 3 visuelles Feedback, auf welche Textzeilen unsere regulären Ausdrücke passen und was die einzelnen Bestandteile bedeuten.

Bildschirmfoto von RegEx101 mit Art ECMAScript, einem regulären Ausdruck zur Extraktion der Altsignatur in der Mitte oben, mehreren Beispielen direkt darunter und hilfreichen Informationen auf der rechten Seite.

1. Inventar aus Findbuch extrahieren

OpenRefine ist für die Arbeit mit tabellenartigen Strukturen ausgelegt, weshalb es mühsam ist große Texte darin zu formatieren, bzw. längere Abschnitte zu löschen. Daher empfiehlt es sich einige Vorbereitungen zu erledigen, bevor die Daten in OpenRefine geladen werden. Dazu gehört es zum Beispiel das Inventar in einer separaten Datei zu speichern und Abbildungen zu entfernen. Außerdem sollten im Vorfeld ggf. Layout- und OCR-Fehler korrigiert werden. Darauf gehen wir in einem separaten Artikel ein.

In diesem Tutorial betrachten wir den Fall, dass wir auf Basis der originalen Word- oder PDF-Vorlage direkt eine “ordentliche” Textdatei erstellen können.

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

Inventar 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. Einträge in Abschnitte aufteilen

Findbuch laden

Nachdem wir OpenRefine gestartet haben, öffnet sich die Bedienoberfläche im Webbrowser auf http://localhost:3333 automatisch.

Die Sprache der Oberfläche lässt sich auf Deutsch einstellen, wir bleiben jedoch bei Englisch. Das macht es uns einfacher die einzelnen Bedienelemente und Funktionen mit der Dokumentation abzugleichen bzw. via Google Lösungen für Fragestellungen zu finden.

Wie in Abbildung 4 gezeigt, laden wir unter “Create Project” die Textdatei aus dem letzten Abschnitt mit dem Inventar des Findbuchs in OpenRefine.

Bildschirmfoto vom Projekt Erstellen Formular in OpenRefine.

Bei uns hat OpenRefine direkt die passenden Einstellungen für die Datei geladen. Wir haben lediglich den Projektnamen angepasst und Schlagworte (Tags) vergeben. Um das neue Projekt zu erstellen, klicken Sie rechts oben auf den Button “Create Project”. Manchmal möchte OpenRefine davon überzeugt werden, dass wir wirklich eine Textdatei ohne jegliche Tabellenstrukur laden möchten. Dafür wie in Abbildung 5 unter “Parse data as” den Punkt “Line-based text files” auswählen.

Bildschirmfoto vom Projekt Einstellungsformular in OpenRefine.

Wir haben für uns festgestellt, dass es einfacher ist initial die leeren Zeilen mitzuladen und später zu entfernen. So helfen die leeren Zeilen zum Beispiel bei der visuellen Separierung der einzelnen Findbucheinträge.

Vorbereitungen in OpenRefine

In OpenRefine haben wir nun jede einzelne Textzeile als “row”. Um einen besseren Überblick zu haben benennen wir die (einzige) Spalte in “Original” um und stellen die Anzeige auf “50 rows” um. Zum Umbenennen verwenden wir das Menüsymbol neben der Spaltenüberschrift und gehen in das Untermenü “Edit column" "Rename this column”.

Anschließend wollen wir die Kopfzeilen der ursprünglichen Seiten entfernen. Diese sehen wie folgt aus (bei den Pfeilen handelt es sich um eine Repräsentation des Unicode Zeichens U+000C für einen Seitenumbruch):

🡹486 Anhang
🡹 Inventar 487

Um diese Zeilen zu entfernen klicken wir auf das Menü-Symbol in der Spalte Original und wählen den “Textfilter”. Dort aktivieren wir das Auswahlkästchen bei “regular expression” (siehe Abbildung 6).

Durch ausprobieren entweder mit RegEx101 oder direkt in dem Feld finden wir heraus, dass der reguläre Ausdruck \d\s+Anhang (Zahl, viele Trennzeichen und das Wort Anhang) alle Zeilen filtert, die wir für die Filterung auf die ursprünglich “linken Seiten” benötigen. Ein etwas aufwendigerer regulärer Ausdruck wäre \d{3,}\s{4,}Anhang$ (drei oder mehr Zahlen, vier oder mehr Leerzeichen und das Wort “Anhang” am Ende der Zeile).

Bildschirmfoto vom Textfilter für Kopfzeilen linker Seiten in OpenRefine.

Über das Menü-Symbol neben der Spalte “All” können wir diese Zeilen im Untermenü “Edit rows" "Remove matching rows” entfernen.

Die Kopfzeilen für die ursprünglich rechten Seiten können via Inventar\s+\d bzw. Inventar\s{4,}\d{3,}$ identifiziert und entfernt werden.

In diesem Findbuch hätten wir auch lediglich nach “Anhang” und “Inventar” suchen können um die einzelnen Zeilen zu identifizieren. Teilweise werden diese Wörter aber auch in den Texten der Findbucheinträge verwendet und wir wollten daher gleich den generischen Ansatz vorstellen.

Über das Schließen-Symbol am Textfilter kommen wir zur ursprünglichen Ansicht zurück.

Findbuchnummer extrahieren

Neue Spalte anlegen

Als erstes Feld extrahieren wir die Findbuchnummer aus den Textzeilen. Dafür verwenden wir “Original" "Edit column" "Add column based on this column…”.

Wir verwenden die von GREL unterstützten regulären Ausdrücke. Um die Findbuchnummer zu extrahieren, verwenden wir match auf jeder Zeile (value, siehe Abbildung 7).

Bildschirmfoto des Dialogs zum Hinzufügen der Spalte Nr für die Findbuchnummer in OpenRefine.

Die verwendete “Expression” filtert Zeilen, die mit 1 und mehreren Leerzeichen beginnen und extrahiert alles direkt nach den Leerzeichen, was keine Klammer ist. Das anschließende .+ benötigen wir, da der reguläre Ausdruck bei match, anders als bei find, auf die komplette Zeile passen muss. Von der Liste (technisch Array) der möglichen Ergebnisse wählen wir das erste Ergebnis via [0] und entfernen überflüssige Leerzeichen mit trim.

value.match(/1\s+([^(]+).+/)[0].trim()

Unterschied zwischen rows und records

Die Spalte Nr verschieben wir anschließend ganz an den Anfang via “Nr" "Edit column" "Move column to beginning”. Das hat zur Folge, dass wir nun zwischen “rows” und “records” hin- und herwechseln können. OpenRefine gruppiert die Zeilen anhand der Merkmale in der ersten Spalte in so genannte “records”.

Anstatt der erwarteten 20 Findbucheinträge haben wir jedoch 71?

Also überprüfen wir, ob bei der Extraktion der Findbuchnummern etwas schief gelaufen ist.

Extraktion überprüfen

Um die Extraktion zu überprüfen ohne uns durch alle Seiten zu klicken, verwenden wir ein “Facet” um die entsprechenden Zeilen zu filtern. Dafür verwenden wir “Nr" "Facet" "Text facet”. In dem “Facet” wählen wir “blank” und invertieren die Auswahl oben im “Facet” über “invert” (siehe ABbildung 8).

Die Extraktion scheint funktioniert zu haben. Beim genaueren Betrachten der “records” fällt jedoch auf, dass Leerzeilen ebenfalls als “records” gezählt werden.

Leerzeilen entfernen

Es ist also an der Zeit die Leerzeilen zu entfernen. Dafür wechseln wir wieder in die Ansicht “rows” und erstellen ein “Facet” via “All" "Facet" "Facet by blank (null or empty string)”. Im “Facet” wählen wir anschließend “true” und löschen die ausgewählten Zeilen via “All" "Edit rows" "Remove matching rows”.

Wenn wir das “Facet” wieder schließen und nun in die “records” Ansicht wechseln, haben wir genau 20 Einträge.

Hier sollte sich spätestens das Bedürfnis melden diesen Zwischenstand speichern zu wollen. Das ist nicht notwendig, da OpenRefine alle Schritte (die Veränderungen einführen) speichert und unter “Undo/Redo” zur Verfügung stellt.

Abschnittnummer extrahieren

Die Abschnittnummer benötigen wir zwar nicht für unsere Datenbank, sie hilft uns aber die einzelnen Abschnitte mit OpenRefine zu gruppieren und zu bearbeiten.

Analog zur Extraktion der Findbuch Nummer fügen wir eine neue Spalte Abschnitt hinzu (“Original" "Edit column" "Add column based on this column…”) und verwenden die folgende “Expression”:

value.match(/([1-8])\s\s.+/)[0]

Diese Expression filtert Zeilen, die einer Zahl zwischen 1 und 8 gefolgt von zwei Leerzeichen beginnen, und extrahiert anschließend die Zahl.

Die neue Spalte verschieben wir anschließend an den Anfang (“Abschnitt" "Edit column" "Move column to beginning”) und kontrollieren die extrahierten Bestandteile (“Abschnitt" "Facet" "Text facet”). Das “Facet” auf den Abschnittsnummern lassen wir stehen, da wir es später noch benötigen werden.

Zeilen der Abschnitte zusammenfassen

Das Verschieben der Spalte Abschnitt an den Anfang sorgt dafür, dass jeder Abschnitt nun einen eigenen “record” darstellt.

Das ist von daher von Vorteil, da wir alle Zeilen eines “records” in eine Zeile zusammenfassen können. Dafür verwenden wir “Original" "Edit cells" "Join multi-valued cells…” und geben -:::- als Trennsequenz (“separator”) an. Diese Zeichenfolge verwenden wir, da wir sie anschließend mit einem Zeilenumbruch \n ersetzen wollen. Ein direktes Verbinden von Zellen mit einem Zeilenumbruch geht in der aktuellen Version (3.5.1) nicht.

Via “Original" "Edit cells" "Transform…” ersetzen wir unsere spezifische Trennsequenz anschließend durch einen Zeilenumbruch.

value.replace("-:::-", "\n")

Wie in Abbildung 9 gezeigt, haben wir nun gleich viele Zeilen (“rows”) wie “records”.

Bildschirmfoto der zwei extrahierten Spalten Abschnitt und Nr in OpenRefine.

3. Findbuch Inventar in Tabelle umwandeln

Nun können wir den Text Abschnitt für Abschnitt in ein tabellenartiges Format überführen. Das Vorgehen ist prinzipiell immer gleich:

Mit einer “Expression” eine neue Spalte basierend auf der Spalte Original hinzufügen.
Eventuell Zeilenumbrüche in der neuen Spalte entfernen.

Abschnitt 1 (Nr, Altsignatur, Vorsignatur, Laufzeit)

In dem “Facet” für den Abschnitt wählen wir den Abschnitt 1.

Die Spalte Nr" haben wir bereits in einem der vorbereitenden Schritte extrahiert. Es folgen die Expressions für die restlichen drei Angaben, die sich noch in Abschnitt 1 befinden, nämlich Altsignatur, Vorsignatur und Laufzeit. Hinzugefügt wird mit “Original" "Edit column" "Add column based on this column…”.

1 1 Nr ( C 2145 Altsignatur ) 1597 – 1600 Laufzeit
Vorsignatur: R Rep. 9 Nr. 230 Vorsignatur

Altsignatur

Die Altsignatur steht in Klammern direkt nach der Findbuchnummer. Anstatt mit match einen regulären Ausdruck für die komplette Zeile zu definieren, verwenden wir nun find.

value.find(/(?<=\().+?(?=\))/)[0].trim()

Wir suchen eine beliebige Folge von Zeichen, die zwischen zwei Klammern steht. Dafür nutzen wir so genannte “Look-around assertions”. Anschließend wählen wir das erste Ergebnis aus und entfernen vorsichtshalber noch Leerzeichen am Anfang und am Ende.

Alternativ können wir die Klammern auch mit in den regulären Ausdruck aufnehmen und anschließend mit substring entfernen.

value.find(/\([^)]+\)/)[0]
 .substring(1, -1)
 .trim()

Vorsignatur

Die Vorsignatur steht direkt hinter dem Text “Vorsignatur:”. Dafür können wir eine “positive look-behind assertion” verwenden.

value.find(/(?<=Vorsignatur:).+/)[0].trim()

Alternativ kann auch hier der Text “Vorsignatur:” mit in den regulären Ausdruck aufgenommen und anschließend mit replace entfernt werden.

value.find(/Vorsignatur: .+/)[0]
 .replace("Vorsignatur:", "")
 .trim()

Das setzt jedoch voraus, dass der Text “Vorsignatur:” auch einheitlich geschrieben wurde. Die Variante mit der “positive look-behind assertion” kann bei unterschiedlichen Schreibweisen einfacher angepasst werden.

Laufzeit

Die Laufzeit steht mit Abstand hinter der eingeklammerten Altsignatur. Also können wir hier als “positive look-behind” nach einer schließenden Klammer, gefolgt von mehreren Leerzeichen suchen, und alle folgenden Zeichen als Laufzeit extrahieren.

value.find(/(?<=\)\s{4}).+/)[0].trim()

Alternativ können wir auch hier die Klammer mit in den regulären Ausdruck aufnehmen und sie anschließend entfernen.

value.find(/\)\s{4,}.+/)[0].substring(1).trim()

Abschnitt 2 (Kläger)

Wir wechseln mit dem “Facet” zu Abschnitt 2 und übernehmen hier den kompletten Inhalt, den wir anschließend bearbeiten. Wir entfernen die Abschnittnummer am Anfang und das Trennzeichen . /. zwischen Käger und Beklagten.

value.replace(/^2\s{2,}/, "")
 .replace(/\n\s*\.\s*\/\./, "")
 .trim()

Ab einer bestimmten Menge an Findbucheinträgen gibt es hin- und wieder Unterschiede in der Anzahl der Leerzeichen (Tippfehler, Scanfehler, …), weshalb wir diese dynamisch mit regulären Ausdrücken beschrieben haben. Alternativ hätten wir in diesem Findbuch auch ohne reguläre Ausdrücke arbeiten können.

value.replace("2 ", "")
 .replace(". /.", "")
 .trim()

Es ist hier auch möglich den Text zu Verkürzen, anstatt die 2 zu ersetzen:

value.substring(1)
 .replace(". /.", "")
 .trim()

Wir zeigen hier bewusst Lösungen mit unterschiedlicher Komplexität. Je nach vorliegendem Datenmaterial sind die einfachen Strategien (Textverkürzung, Textersetzung, …) vollkommen ausreichend. Teilweise sind Findbücher jedoch inkonsistent (unterschiedliche Autoren, unterschiedliche Archivalien, Tippfehler, Scanfehler, …). Hier benötigt es komplexere Lösungen, wie zum Beispiel reguläre Ausdrücke.

Zeilenumbrüche entfernen

Bei den Klägern wollen wir zusätzlich die Leerzeilen entfernen. Dafür gehen wir auf “Kläger" "Edit cells" "Transform…” und verwenden die folgende Expression:

value.replace(/-\n\s*(?![A-Z])/, "")
 .replace(/(?<=-)\n\s*(?=[A-Z])/, "")
 .replace(/\n\s*/, " ")

Dieser Expression entfernt zuerst Zeilenumbrüche (mit Bindestrich), die mit einem Bindestrich enden, wobei das erste Wort in der nächsten Zeile nicht groß geschrieben sein darf. Dann werden Zeilenumbrüche entfernt, bei denen der Bindestrich erhalten bleiben soll. Anschließend werden die restlichen Zeilenumbrüche mit einem Leerzeichen ersetzt. Diese Umwandlung können wir wie beschrieben in einem nachgelagerten Schritt, oder direkt bei der Erstellung der Spalte durchführen.

Abschnitt 3 (Beklagte)

Wir wechseln mit dem “Facet” zu Abschnitt 3, übernehmen hier den kompletten Inhalt, entfernen die Abschnittnummer, und entfernen die Zeilenumbrüche.

value.replace(/^3\s{2,}/, "")
 .trim()
 .replace(/-\n\s*(?![A-Z])/, "")
 .replace(/(?<=-)\n\s*(?=[A-Z])/, "")
 .replace(/\n\s*/, " ")

Abschnitt 4 (Prokuratoren)

Wir wechseln mit dem “Facet” zu Abschnitt 4 und übernehmen hier den kompletten Inhalt. Die Formatierung (Zeilenumbrüche, …) wollen wir hier beibehalten. Lediglich die Abschnittnummer entfernen wir.

value.replace(/^4/, " ")

Abschnitt 5 (Prozessart und Gegenstand)

Wir wechseln mit dem “Facet” zu Abschnitt 5. Hier wollen wir die Prozessart von dem Prozessgegenstand trennen. Hierfür ist es in den meisten Fällen ausreichend, die erste Zeile von den restlichen zu trennen. Bei manchen Prozessen erstreckt sich die Prozessart jedoch auf mehrere Zeilen. Es ist zwar möglich auf Grund verschiedener Merkmale die Anzahl der Zeilen für die Prozessart zu bestimmen, der Algorithmus dafür wird jedoch komplex. Daher prüfen wir die einzelnen Einträge und korrigieren bei den Ausnahmen manuell nach.

Prozessart

value.split("\n")[0]
 .replace(/^5\s{2,}/, "")
 .trim()

Wir trennen den Text an den Zeilenumbrüchen auf, wählen die erste Zeile und ersetzen dort die Abschnittnummer. Anschließend korrigieren wir die Prozessart in den Ausnahmefällen manuell. Dafür fahren wir wie in Abbildung 10 mit der Maus in die zu bearbeitende Zelle, worauf ein blaues Bedienelement mit dem Text “Edit” es uns erlaubt in den Bearbeitungsmodus für diese Zelle zu wechseln.

Bildschirmfoto der ‘Edit’-Funktionalität in OpenRefine.

Gegenstand

Die Spalte Prozessart haben wir schon manuell korigiert. Um uns diesen Schritt für die Spalte Gegenstand zu sparen, gehen wir in der nächsten “Expression” wie folgt vor:

Ersetze die Abschnittnummer
Ersetze alle Zeilenumbrüche
Entferne die Prozessart durch Ersetzung mit dem Inhalt der Spalte Prozessart.

value.replace(/^5\s{2,}/, "")
 .replace(/-\n\s*(?![A-Z])/, "")
 .replace(/(?<=-)\n\s*(?=[A-Z])/, "")
 .replace(/\n\s*/, " ")
 .replace(cells["Prozessart"].value, "")
 .trim()

Abschnitt 6 (Vorinstanzen)

Wir wechseln mit dem “Facet” zu Abschnitt 6 und übernehmen hier den kompletten Inhalt. Die Formatierung (Zeilenumbrüche, …) wollen wir hier beibehalten. Lediglich die Abschnittnummer entfernen wir.

value.replace(/^6/, " ")

Abschnitt 7 (Darin)

Wir wechseln mit dem “Facet” zu Abschnitt 7 und übernehmen hier den kompletten Inhalt. Die Zeilenumbrüche wollen wir entfernen, dabei aber jedes Q in einer neuen Zeile stehen haben.

Dabei gehen wir wie folgt vor:

Abschnittnummer entfernen
Zeilenumbrüche vor Q mit Trennsequzenz ersetzen
Zeilenumbrüche vor ohne Q mit Trennsequzenz ersetzen
Zeilenumbrüche mit Bindestrich (anschließend Kleinschreibung) entfernen
Zeilenumbrüche mit Bindestrich (anschließend Großschreibung) entfernen
Restliche Zeilenumbrüche mit Leerzeichen ersetzen
Trennsequzenz durch Zeilenumbrüche und Leerzeichen für Formatierung ersetzen

value.replace(/^7/, " ")
 .replace(/\s*\n\s+(?=Q\s*\d)/, "-:::-")
 .replace(/\s*\n\s+(?=ohne Q\s*)/, "-:::-")
 .replace(/-\n\s*(?![A-Z])/, "")
 .replace(/(?<=-)\n\s*(?=[A-Z])/, "")
 .replace(/\n\s*/, " ")
 .replace(/-:::-/, "\n ")

Abschnitt 8 (Umfang, Stapelhöhe, Hinweise)

Wir wechseln mit dem “Facet” zu Abschnitt 8. In diesem Abschnitt haben wir mehrere Bestandteile, die wir in separate Spalten extrahieren wollen.

Q 1– 39
3 cm Stapelhöhe
ohne Wetzlarer Nummer, da vor Generalausteilung abgegeben (an Nach-
folgeinstanz?)

Die Stapelhöhe bietet sich hier als Trennmerkmal an, da sie einfach zu identifizieren ist. Bei Einträgen ohne Stapelhöhe können wir die Trennung manuell vornehmen. Bei komplexeren Angaben können die verwendeten regulären Ausdrücke auch erweitert werden.

Umfang

Um den Umfang zu extrahieren, teilen wir den Eintrag bei der Stapelhöhe und entfernen die Abschnittnummer.

value.split(/\d+\s+cm/)[0]
 .replace(/^8\s+/, "")
 .trim()

Ein Eintrag muss manuell nachbearbeitet werden.

Stapelhöhe

Die Stapelhöhe extrahieren wir direkt mit einem regulären Ausdruck.

value.find(/\d+\s+cm/)[0]

Hinweise

Die Hinweise stehen nach der Stapelhöhe. Daher teilen wir den Eintrag bei der Stapelhöhe, nehmen den hinteren Teil, und entfernen die Zeilenumbrüche.

value.split(/\d+\s+cm/).slice(1).join("")
 .replace(/-\n\s*(?![A-Z])/, "")
 .replace(/(?<=-)\n\s*(?=[A-Z])/, "")
 .replace(/\n\s*/, " ")
 .trim()

Ein Eintrag muss manuell nachbearbeitet werden.

Nacharbeiten

An dieser Stelle ist es soweit, dass wir die Spalten umsortieren, überflüssige Spalten löschen, die Zeilen zusammenfassen und die Daten noch einmal visuell prüfen.

Spalte Abschnitt löschen

Die Spalte Abschnitt wird nicht mehr benötigt und sie kann gelöscht werden. “Abschnitt" "Edit column" "Remove this column”

Zeilen zusammenfassen

Bei der Spalte Original verbinden wir mit der Trennsequenz -:::- über “Original" "Edit cells" "Join multi-valued cells…”. Die Trennsequenz ersetzen wir anschließend via “Original" "Edit cells" "Transform…”.

value.replace("-:::-", "\n")

Die anderen Spalten (Hinweise, Stapelhöhe, Umfang, Darin, Vorinstanzen, Gegenstand, Prozessart, Prokuratoren, Beklagte, Kläger) verbinden wir ohne Trennzeichen, da es hier ja nur einen Wer pro “record” gibt.

Jetzt sollten wir wieder genausowiele Zeilen (“rows”) wie “records” haben.

Spalten sortieren

Jetzt können die Spalten via “All" "Edit columns" "Re-order / remove columns…” noch sortiert werden.

Visuell inspizieren

Jetzt kommt noch einmal ein visueller Abgleich der extrahierten Daten mit dem Original. Die Spalte Original kann danach auch gelöscht werden (“Original" "Edit column" "Remove this column”). Das Ergebnis ist in Abbildung 11 gezeigt.

Bildschirmfoto der bereinigten Daten in OpenRefine.

Export

Die Daten können wir über “Export" "Comma-separated value” als CSV-Datei exportieren. Das machen wir, da wir für die Transformation der Daten auf das Datenbankschema ein separates Projekt erstellen wollen.

Diese Trennung in zwei Projekte ist Geschmackssache. Es hat sich jedoch gezeigt, dass es gerade bei der Übertragung der Daten auf das Erfassungsschema Abstimmungsbedarf und gegebenenfalls mehrerer Iterationen bedarf. Daher hat sich diese Aufteilung in zwei getrennte Arbeitsschritte und Projekte bei uns etabliert.

💾 Die einzelnen Arbeitsschritte im OpenRefine Format:

Inventar Akten RKG Band 57 - Wertheim als OpenRefine Arbeitsschritte .

4. Tabelle auf Datenbankschema übertragen

Wir haben in Teil 3 den Text des Inventars des Findbuchs in strukturierte Daten umgewandelt. In diesem Teil wandeln wir diese Daten in unser Erfassungs- bzw. Datenbankschema um. Anders ausgedrückt: Wir bringen die Daten in eine Form, die es uns erlaubt, sie auf die Felder unseres Erschließungsformulars im AFIS zu mappen.

💾 Die Datei mit den strukturierten Daten für diesen Teil:

Inventar Akten RKG Band 57 - Wertheim als CSV .

Import

Wir erstellen ein neues Projekt in OpenRefine und importieren dafür die CSV Datei. OpenRefine erkennt automatisch die passenden Einstellungen und wir passen lediglich den Projektnamen und die Schlagworte an. Siehe dazu Abbildung 12.

Bildschirmfoto der Einstellungen zum Import der CSV-Datei in OpenRefine.

Transformation

Da wir schon strukturierte Daten haben, fällt dieser Abschnitt etwas kürzer aus. Hier geht es hauptsächlich darum einzelne Spalten zusammenzufassen, gegebenenfalls mit Text zu ergänzen und manchmal auch umzuwandeln.

Titel

Hier wollen wir, dass der Kläger im Titelfeld steht und dass der Titel mit “Kläger:” beginnt. Unser Titel soll also die Form “Kläger: {Kläger}” haben. Dafür wandeln wir die Spalte einfach via “Kläger" "Edit cells" "Transform…” um:

"Kläger: " + value

Anschließend benennen wir die Spalte via “Kläger" "Edit column" "Rename this column” in “Titel” um.

Um die Übersicht zu behalten, verschieben wir diese Spalte mit “Titel" "Edit column" "Move column to end” direkt an das Ende.

Bestellsignatur

Für die Bestellsignatur ergänzen wir zur Findbuch Nummer in der Spalte Nr die Bestandssignatur R J 10. Dafür transformieren wir via “Nr" "Edit cells" "Transform…”

"R J 10 " + value

Danach benennen wir die Spalte via “Nr" "Edit column" "Rename this column” in “Bestellsignatur” um.

Anschließend sind wir mit dieser Spalte fertig und verschieben sie via “Bestellsignatur" "Edit column" "Move column to end” direkt an das Ende.

Vorsignatur 1

Hier können wir direkt die Spalte Altsignatur umbennen und an das Ende verschieben.

Vorsignatur 2

Hier können wir direkt die Spalte Vorsignatur umbennen und an das Ende verschieben.

Entstehungszeitraum

Wir haben beschlossen, dass wir als Entstehungszeitraum die niedrigste Jahreszahl der Laufzeit bis zur höchsten Jahreszahl der Laufzeit verwenden. Diese müssen aus der Laufzeit erst noch extrahiert und in das AFIS Importformat umgewandelt werden.

Um die original Schreibweise zu erhalten, wird diese im nächsten Feld (Entstehungszeitraum, Anm.) übernommen.

Also erstellen wir hier eine neue Spalte aus der Spalte Laufzeit durch folgende Operationen:

Ersetze alles was keine Ziffer ist \D durch ein Leerzeichen.
Ersetze mehrere Leerzeichen hintereinander \s+ durch ein Leerzeichen.
Entferne Leerzeichen zu Beginn und Ende der Laufzeit mit trim().
Teile den Text an Leerzeichen mit split().
Sortiere die Liste (technisch ein Array) mit sort().
Die Liste wird arr genannt (via with).
Wenn die Liste mehr als ein Element beinhaltet, nehmen wir das erste arr[0] und letzte Element arr[-1] aus der sortierten Liste.
Wenn die Liste nur ein Element beinhaltet, nehmen wir dieses.
(indirekt) Bei Fehlern, wird das Feld einfach nicht ausgefüllt.

with(
 value.replace(/\D/, " ")
 .replace(/\s+/, " ")
 .trim()
 .split(" ")
 .sort(),
 arr,
 if(arr.length() > 1,
 ">=<= +" + arr[0] + " +" + arr[-1],
 "= +" + arr[0]))

Anschließend verschieben wir die neue Spalte an das Ende.

Entstehungszeitraum, Anm.

Hier können wir direkt die Spalte Laufzeit umbennen und an das Ende verschieben.

Beklagte

Diese Spalte übernehmen wir direkt so und verschieben sie an das Ende.

Bemerkung

In dieser Spalte fassen wir die Spalten Vorinstanzen und Hinweise zusammen. Hier gibt es mehrere Möglichkeiten die Spalten zusammen zu fassen.

Technische Variante

Bei der ersten, technischeren Variante erstellen wir eine neue Spalte basierend auf der Spalte Vorinstanzen und fügen dabei den Wert der Spalte Hinweise hinzu. Dabei ist zu beachten, dass wir die Werte nur verwenden, wenn sie auch vorhanden sind isNonBlank. Sonst kommt es zu einem Fehler und die Zielspalte bleibt leer, wenn zum Beispiel für einen Eintrag nur die Vorinstanzen belegt sind.

Von der Spalte Vorinstanzen ausgehend erzeugen wir eine neue Spalte Bemerkung mit folgender “Expression”:

(
 if(isNonBlank(value),
 "Vorinstanzen, Anfangsjahr:\n" + value,
 "")
 +
 if(isNonBlank(cells["Hinweise"]),
 "\n\nHinweise: " + cells["Hinweise"].value,
 ""))
.trim()

Anschließend löschen wir die Spalten Vorinstanzen und Hinweise und verschieben die neue Spalte Bemerkung an das Ende.

Weniger technische Variante

Bei der weniger technischen Variante transformieren wir zuerst die Spalte Vorinstanzen:

if(isNonBlank(value),
 "Vorinstanzen, Anfangsjahr:\n" + value,
 "")

Dann transformieren wir die Spalte Hinweise:

if(isNonBlank(cells["Hinweise"]),
 "\n\nHinweise: " + cells["Hinweise"].value,
 "")

Anschließend verbinden wir die beiden Spalten via “Vorinstanzen" "Edit column" "Join columns…”. Dabei können wir die Original Spalten Vorinstanzen und Hinweise auch gleich löschen. Siehe dazu Abbildung 13.

Bildschirmfoto der Einstellungen zum Verbinden der Spalten Vorinstanzen und Hinweise in OpenRefine.

Die neue Spalte Bemerkung schieben wir an das Ende.

Enthält

Hier fassen wir die Spalten Gegenstand, Darin und Prokuratoren zusammen.

Von der Spalte Gegenstand ausgehend erzeugen wir eine neue Spalte Enthält mit folgender “Expression”:

(
 if(isNonBlank(value),
 "Gegenstand materiell:\n " + value,
 "")
 +
 if(isNonBlank(cells["Darin"]),
 "\n\nDarin:\n" + cells["Darin"].value,
 "")
 +
 if(isNonBlank(cells["Prokuratoren"]),
 "\n\nProkuratoren mit Bevollmächtigungsjahr:\n" + cells["Prokuratoren"].value,
 ""))
.trim()

Die Spalten Gegenstand, Darin und Prokuratoren löschen wir anschließend und die neue Spalte Enthält verschieben wir an das Ende.

Gegenstand

Hier können wir direkt die Spalte Prozessart umbennen und an das Ende verschieben.

Umfang

Wir haben uns dazu entschlossen den Umfang und die Stapelhöhe in einem Feld zu erfassen und führen sie daher wieder zusammen.

Um uns das Umbenennen der Spalte Umfang zu sparen, transformieren wir die Spalte anstatt eine neue Spalte zu erzeugen.

(
 value
 +
 if(isNonBlank(cells["Stapelhöhe"]),
 "\n" + cells["Stapelhöhe"].value,
 ""))
.trim()

Anschließend löschen wir die Spalte Stapelhöhe und verschieben die Spalte Umfang an das Ende. Die Daten sind nun in ihrem Zielformat und sind in Abbildung 14 abgebildet.

Bildschirmfoto der bereinigten Daten in OpenRefine.

Export

Die Daten werden nun über “Export" "Custom tabular exporter…” als CSV-Datei exportiert. Die Einstellungen sind in Abbildung 15 gezeigt.

Bildschirmfoto der Einstellungen für den Export in OpenRefine.

Wir verwenden den “Custom tabular exporter”, da bei uns häufig Excel zum Inspizieren der Daten verwendet wird. Excel erwartet bei CSV-Dateien jedoch ein Semikolon ; als Trennzeichen und iso-8859-1 als Kodierung.

💾 Die Datei mit den strukturierten Daten für den Datenbank Import:

Inventar Akten RKG Band 57 - Wertheim als CSV für Datenbank Import . > > 💾 Die einzelnen Arbeitsschritte im OpenRefine Format: Inventar Akten RKG Band 57 - Wertheim als OpenRefine Arbeitsschritte .

Fazit

Wir haben mit OpenRefine ein komplettes, textbasiertes Findbuch in ein für den Datenbankimport kompatibles Format umgewandelt. Dabei haben wir auf komplexe Code-Schleifen und Bedingungen verzichtet und dafür mehr manuelle Schritte vorgenommen.

Die Fähigkeit von OpenRefine Änderungen an Daten und die Wirkung von Transformationen quasi live anzuzeigen, erlaubt es auch Einsteigern schnelle Fortschritte zu erzielen. Mit den Erklärungen und dem Aufzeigen unterschiedlicher Lösungen haben wir Strategien aufgezeigt, die sich auf ähnliche Probleme übertragen lassen.

Wir konnten zeigen, dass sich mit OpenRefine auch Texte in tabellenartige Formate transformieren lassen. Es bleibt die Herausforderung passende Muster (reguläre Ausdrücke) zu finden, die es ermöglichen die Daten aus den Texten passend herauszufiltern.