Erfahrungsbericht - Extraktion und Abgleich von Prokuratoren mit OpenRefine

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

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

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

Generelle Daten

Text:

• 10 Bände
• 10.339 Textzeilen

CSV:

• 2.912 Indexeinträge
• Davon 100 Aliase

Deduplikation:

• 472 Prokuratoren

Abgleich mit GND:

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

Anwenden mehrerer Teilschritte

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

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

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

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

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

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

Deduplikation mit Clusterverfahren

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

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

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

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

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

Abgleich mit der GND

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

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

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

Fazit

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

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

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

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