Findbuch | FDMLab@LABW

Verborgene Datenschätze heben: Das FDMLab experimentiert mit KI im Archiv

Thu, 28 Apr 2022 00:00:00 +0000

Clustering von Namen mit OpenRefine

Tue, 12 Oct 2021 00:00:00 +0000

In diesem Artikel betrachten wir die Clustering Verfahren von OpenRefine im Kontext der Aufarbeitung der Indices der Prokuratoren der Akten des Reichskammergerichts.

Clustern von Prokuratoren

In unserem Artikel Erfahrungsbericht - Extraktion und Abgleich von Prokuratoren mit OpenRefine berichteten wir bereits, dass wir die Deduplikation der Prokuratoren mit unterschiedlichen Schreibweisen über 10 Bände, mit den in OpenRefine integrierten Clustering Verfahren durchgeführt haben.

Bildschirmfoto der Oberfläche zum Clustering in OpenRefine.

Um die Namen zusammenzuführen, fassen wir zuerst die gleich geschriebenen Namen in Cluster zusammen und suchen anschließend mit den in OpenRefine verfügbaren Clustering Verfahren ähnlich geschriebene Namen (Deduplizierung).

--- title: Clustering visualisiert 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

Da wir unterschiedliche Arten von Duplizierungen hatten, verwendeten wir mehrere der angebotenen Verfahren nacheinander, bis wir keine Cluster mehr automatisiert finden konnten.

Dieses Vorgehen ist zwar pragmatisch, jedoch nicht sehr wissenschaftlich. Daher nutzen wir den entstandenen Datensatz, um damit die einzelnen Clustering Verfahren von OpenRefine genauer zu betrachten.

Informationen zum Datensatz

Die Daten sind recht speziell und der Datensatz ist auch nicht sehr groß.
Daher sind die Erkenntnisse in diesem Artikel nur bedingt übertragbar!

Wir haben 2.813 Einzeleinträge (Namen), aus 10 Datenquellen (Findbücher), die wir zu 472 Cluster (Prokuratoren) zusammengefasst haben. In Abbildung 2 ist eine Verteilung der Cluster Größen gezeigt. Also wie viele der 472 Cluster am Ende 1, 2, …, 10 Namen haben.

Histogramm mit Verteilung der erwarteten Cluster Größen.

In Abbildung 2 ist zu sehen, dass es nur wenig Prokuratoren gibt, die in allen 10 Bänden erwähnt werden. Wobei hier auch berücksichtigt werden sollte, dass es bei dem relativ kleinen Bestand der Akten des Reichskammergerichts im Staatsarchiv Wertheim - Inventar des Bestands R J 10 insgesamt nur 37 Prokuratoren gibt. Laut Histogramm gibt es circa 80 Prokuratoren, die jeweils nur in einem Band vorkommen.

Insgesamt war die Schreibweise über die Bände relativ einheitlich, so dass nur etwa 10 Prozent der Einträge eine abweichende Schreibweise in einem anderen Band aufwiesen. Diese konnten also schon durch Sortieren in Cluster zusammengeführt werden. Innerhalb der Bände gab es drei Duplikate, also Prokuratoren, die im Index eines Bandes in unterschiedlicher Schreibweise mehrfach erwähnt wurden.

Probleme im Datensatz

Bei der Deduplizierung fanden sich verschiedene Problemtypen, die zu unterschiedlichen Schreibweisen in den einzelnen Bänden geführt haben. Die folgenden Fälle werden in der anschließenden Diskussion näher besprochen:

Andere Buchstaben: B(u|o)ntz, Jose(f|ph)
Kurzformen: Antonius, Johannes
Fehlende Zweitnamen: Speckmann, Johann Stefan
Fehlende Namensbestandteile:
- Albrecht (von Lauterburg), Johann Konrad
- Heeser, Johann Konrad von
Alternative Schreibweisen:
- Greck (Gregk), Leo
- Brandt, ( Johann ) Ferdinand Wilhelm
OCR oder Tippfehler: (Fl|H)einrich, Seche(i|l)

Verfügbare Clustering Verfahren

In OpenRefine werden 8 Cluster Methoden angeboten, die in der Dokumentation zu den Clustering Verfahren erklärt und im OpenRefine GitHub Wiki vertieft werden. Diese Clustering Verfahren lassen sich in drei Arten aufteilen.

Bei den aufwendiger zu berechnenden Nearest-Neighbor Verfahren, wird die Distanz zwischen zwei Namen berechnet. Zum Beispiel haben Buntz und Bontz eine Levenshtein-Distanz von eins (u durch o ersetzen). Diese Distanzen werden anschließend verwendet, um alle “Nachbarn” innerhalb eines bestimmten Radius zu einem Cluster zusammenzufassen.

Bei den allgemeinen Fingerprinting Methoden, werden die Wörter normalisiert und sortiert, bevor sie miteinander abgeglichen werden. Beim n-gramm Fingerprinting werden statt Wörtern Buchstabengruppen verwendet.

Bei den sprachspezifischen Fingerprinting Methoden (Phonetisches Clustering), werden zusätzlich Buchstaben(gruppen) berücksichtigt, die ähnlich ausgesprochen werden. So wurde metaphone3 für die englische Aussprache und cologne-phonetic für die deutsche Aussprache entwickelt. Daitch-Mokotoff und Beider-Morse sind beide auf die jiddische und slawische Aussprache spezialisiert.

Theoretisch sollten in unserem Fall cologne-phonetic, sowie die Nearest-Neighbor Methoden gute Ergebnisse erzielen. Die allgemeinen Fingerprinting Methoden lösen Probleme, die wir in unseren Daten eher nicht haben, wie unterschiedliche Reihenfolge der Namen oder unterschiedliche Interpunktion, Groß- und Kleinschreibung, Akzente,…

Durchführung des Clusterings

Zuerst führen wir den Original Datensatz mit den Prokuratoren aus den Findbüchern und den fertig deduplizierten und mit der GND abgeglichenen Datensatz zusammen. Hierbei ist uns aufgefallen, dass es bei der Bearbeitung mit OpenRefine praktisch gewesen wäre eine ID-Spalte aus dem Original Datensatz mitzuführen, so dass der Ausgangsdatensatz einfacher wieder mit dem Ergebnis zusammengeführt werden kann.

Anschließend legen wir für jede der in OpenRefine verfügbaren Clustering Methoden eine eigene Spalte an. Mit dieser Clustering Methode werden die Namen in der Spalte so lange zusammengeführt, bis sie keine weiteren Cluster mehr findet. Das war bei den meisten Methoden (Ausnahme: Nearest-Neighbor Methoden) nach dem ersten Durchlauf der Fall.

Verfahren	Runde	Cluster	Parameter
levensthein	1	78	Radius 1.0, Block Chars 6
	2	1	Radius 1.0, Block Chars 6
ppm	1	160	Radius 1.0, Block Chars 6
	2	14
	3	1
fingerprint	1	29
ngram-fingerprint	1	27	Size 2
metaphone3	1	113
cologne-phonetic	1	101
Daitch-Mokotoff	1	112
Beider-Morse	1	69

Es werden alle Vorschläge für Cluster übernommen. Es werden keine Cluster manuell bearbeitet oder geprüft. Dadurch werden auch Falsch-Positive erzeugt, also Namen von unterschiedlichen Prokuratoren automatisch zusammengeführt. ¹

Wir nehmen an, dass in einem realen Anwendungsfall Falsch-Positive zwar einen extra Bearbeitungsaufwand beim Prüfen der Cluster Vorschläge erzeugen, jedoch gut erkannt und vor der Zusammenführung entfernt werden können. Problematischer sind in unserem Fall Falsch-Negative. Also Namen des gleichen Prokurators, die von den Clustering Verfahren nicht erkannt und daher manuell gefunden und zusammengeführt werden müssen.

Ergebnisse

Zur Bewertung der Ergebnisse verwenden wir verschiedene Metriken zur Cluster Performance Analyse von scikit-learn, als auch die Trefferquote (hit_rate).

Bei der Trefferquote bewerten wir lediglich Falsch-Negative als Fehler, da wir davon ausgehen, dass Falsch-Positive bei der manuellen Prüfung der Cluster Vorschläge aussortiert werden. Die von scikit-learn angewendeten Bewertungsmetriken versuchen die Ähnlichkeit zwischen den erzeugten und den gewünschten Cluster zu bewerten.

Bewertung der Clustering Verfahren mit unterschiedlichen Metriken.

Das Diagramm in Abbildung 3 zeigt die Abweichung der Bewertung für die einzelnen Clustering Verfahren von original an. Dabei beinhaltet original die Cluster, die man durch Sortieren und direktes Zusammenführen von exakt gleich geschriebenen Namen erhält.

Eine Abweichung größer Null bedeutet, dass durch das Clustering Verfahren eine Verbesserung eingetreten ist. Eine Abweichung kleiner Null bedeutet, dass durch viele Falsch-Positive eine Verschlechterung eingetreten ist.

Es ist zu sehen, dass die hit_rate als Bewertungsmetrik die Clustering Verfahren Daitch-Mokotoff, metaphone3 und ppm überschätzt, da sie nur Falsch-Negative als Fehler bewertet.

Prinzipiell scheinen auf unserem Datensatz cologne-phonetic und levenshtein ergänzt durch metaphone3 und ppm einen guten Kompromiss darzustellen.

Diskussion

Die Ergebnisse entsprechen in etwa unseren Erfahrungen beim unreflektierten Ausprobieren der verfügbaren Clustering Verfahren. Mit cologne-phonetic konnten wir im Vergleich zu metaphone3 relativ schnell Namen mit wenigen Falsch-Positiven zusammenführen und dann mit den anderen Verfahren noch fehlende Zusammenführungen vornehmen.

Cluster Visualisierung

Um die Wirkung einzelner Clustering Verfahren auf einzelne Cluster zu visualisieren, haben wir diese mit so genannten Tree Maps dargestellt.

Erklärung zu Cluster Visualisierung mit Tree Maps.

Auf der linken Seite werden zu einem Cluster gehörige Namen dargestellt. Gleich geschriebene Namen werden zu Sub-Clustern zusammengefasst, was unserer “Original” Ausgangsbasis entspricht. Je mehr Namen ein Sub-Cluster hat, desto größer wird er dargestellt.

Auf der rechten Seite sind Sub-Cluster dargestellt, wie sie nach dem Anwenden des Clustering Verfahrens bestehen. Dabei sind Cluster, die von diesem Clustering Verfahren zusammengefasst werden, in der gleichen Farben gehalten. Also Sub-Cluster in einem blauen Farbton auf der linken Seite sind rechts in einem Cluster mit blauer Farbe zusammengefasst.

Spezielle Sub-Cluster sind auf der linken Seite durch eine Umrandung markiert. Wird ein Clustering Verfahren visualisiert, dann handelt es sich bei dem markierten Sub-Cluster um ein Beispiel, das ausschließlich von diesem Verfahren zusammengeführt werden konnte. Wird kein Clustering Verfahren visualisiert, dann handelt es sich bei dem markierten Sub-Cluster um ein Beispiel, das von keinem Clustering Verfahren zusammengeführt werden konnte.

Der Titel des Diagramms enthält den Namen, wie er manuell für das Cluster festgelegt wurde, und die Anzahl an Gesamteinträgen des Clusters.

Andere Buchstaben

B(u|o)ntz, Jose(f|ph)

Für dieses Problem können besonders die phonetischen Clustering Verfahren eingesetzt werden. Wir konnten in unserem Datensatz keine übrig gebliebenen Sub-Cluster mit (ausschließlich) diesen Fehlern finden.

Kurzformen

Antonius, Johannes

Spezialfall Zusammenführung durch ppm.

Das Prediction by Partial Matching Verfahren war im Vergleich zu den anderen Verfahren besonders erfolgreich bei der Zusammenführung von Kurz- und Langformen. Es war das einzige Verfahren, dass zum Beispiel den Nachnamen Streitter zusammenführen konnte.

Fehlende Zweitnamen

Speckmann, Johann Stefan

Problem mit fehlenden Zweitnamen.

Hier kommt es auf die Länge des Gesamtnamens an. Manchmal konnten kurze fehlende Zweitnamen ignoriert werden. In diesem Beispiel hat der im Verhältnis recht lange Zweitname “Johann” dazu geführt, dass “Speckmann, Stefan” separat blieb und von keinem der Clustering Verfahren mit “Speckmann, Johann Stephan” zusammengeführt wurde. Diesen Namen haben fanden wir, indem wir die Liste alphabetisch sortiert und dann manuell geprüft haben.

Fehlende Namensbestandteile

Albrecht (von Lauterburg), Johann Konrad

Heeser, Johann Konrad von

Problem mit fehlenden Namensbestandteilen.

Das fehlende von war für die meisten Verfahren nicht problematisch. Auch die fehlenden Zweitnamen Maria Joseph konnten von mehreren Verfahren kompensiert werden.

Problematisch war hier der relativ lange Einschub von Lilienthal, der dafür sorgte, dass kein Verfahren das Cluster vollständig zusammenfügen konnten.

Alternative Schreibweisen

Greck (Gregk), Leo

Brandt, ( Johann ) Ferdinand Wilhelm

Spezialfall Zusammenführung durch Fingerprinting.

Da beim Fingerprinting eine Normalisierung durchgeführt wird, bei der auch Klammern und Umlaute normalisiert werden, konnte hier die alternative Schreibweise “Thürn” mit “Thurn” zusammengeführt werden. Dies ist jedoch ein Spezialfall. Mit diesem Problemtyp hatten wir in unserem Datensatz die meisten Probleme.

Problem mit alternativer Schreibweise 1.

Zum Beispiel hat der Zusatz (Gregk) in Kombination mit den kurzen Namen dazu geführt, dass diese beiden Cluster von keinem Verfahren zusammengeführt werden konnte.

Problem mit alternativer Schreibweise 2.

Auch bei Reineck hat der relative hohe alternative Namensbestandteil im Namen dafür gesorgt, dass das Cluster von keinem Verfahren vollständig zusammengeführt werden konnte.

Problem mit Sonderzeichen.

Hier haben wir zusätzlich zu dem alternativen Namen in Klammern auch noch unterschiedliche Anführungszeichen, die je nach Verfahren zusätzliche Probleme erzeugen, wenn sie im Vorfeld nicht normalisiert werden.

OCR oder Tippfehler

(Fl|H)einrich, Seche(i|l)

Spezialfall Zusammenführung durch levenshtein.

Die (phonetischen) Fingerprint Verfahren haben Probleme mit OCR-Fehlern, wie zum Beispiel die Ersetzung von l durch i. Hier kann ein Nearest-Neighbor Verfahren mit der Levenshtein-Distanz helfen, diese Fälle zusammenzuführen.

Kombination aus anderer Schreibweise und OCR-Fehler.

Die unterschiedliche Schreibweise von Burckhardt in Kombination mit dem OCR-Fehler in Fleinrich konnte in den Standardeinstellungen der Clustering Verfahren nicht aufgelöst werden. Hier lohnt es sich mit den Parametern für die Levenshtein-Distanz zu experimentieren (Blockgröße reduzieren und Radius erweitern).

Manuelle Prüfung

Bei der manuellen Prüfung haben wir deutlich mehr Informationen zur Verfügung, als die verwendeten Clustering Verfahren. So nutzten wir zusätzlich die Herkunft des Namens (Band …), Wirkdaten der Prokuratoren, Hinweise auf alternative Schreibweisen durch Verweise im Index der Prokuratoren, Nennung vollständiger Namen im Index der Personen, …

Diese Informationen lassen sich aktuell in OpenRefine nicht automatisiert mitverwenden.

Fazit

Wir haben bei der Analyse der verschiedenen Clustering Verfahren in OpenRefine einiges für unseren Anwendungsfall gelernt:

Im Vorfeld mehr Data-Cleaning (OCR-Fehler, Sonderzeichen, …)
Wenn alternative Schreibweisen im Namen kodiert sind, dann diese Kodierungen auflösen und separat clustern (Greck, Leo und Gregk, Leo statt Greck (Gregk), Leo).
Für deutsche Texte zukünftig zuerst cologne-phonetic und dann metaphone3 verwenden.
Anschließend mit Nearest-Neighbor Verfahren in verschiedenen Parametern ergänzen.
Abschließend die Ergebnisse in sortierter Reihenfolge manuell prüfen.

Aber die wichtigste Erkenntnis:

Clustering mit OpenRefine ist so einfach und funktional, dass wir auch ohne Fachwissen zu einem guten Ergebnis kommen konnten!

Details zu Falsch-Positiven und Falsch-Negativen finden sich im Wikipedia Artikel zur Beurteilung eines binären Klassifikators. ↩︎

Erfahrungsbericht - Extraktion und Abgleich von Prokuratoren mit OpenRefine

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

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

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

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

Generelle Daten

Text:

10 Bände
10.339 Textzeilen

CSV:

2.912 Indexeinträge
Davon 100 Aliase

Deduplikation:

472 Prokuratoren

Abgleich mit GND:

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

Anwenden mehrerer Teilschritte

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

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

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

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

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

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

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

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

Deduplikation mit Clusterverfahren

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

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

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

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

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

Abgleich mit der GND

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

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

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

Fazit

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

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

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

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

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

Findbuchdaten mit OpenRefine wiederverwenden

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

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

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

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

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

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

Index Prokuratoren Akten RKG Band 57

Index Prokuratoren Akten RKG Band 57 als OpenRefine Arbeitsschritte

Prokuratoren Akten RKG Band 57 - Wertheim als CSV

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

Operationen übertragen

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

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

Bildschirmfoto der Ansicht zum Erstellen neuer Projekte in OpenRefine.

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

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

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

Dialog zum Anwenden von exportieren Operationen in OpenRefine.

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

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

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

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

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

Bildschirmfoto der Daten nach der Anwendung der Operationen in OpenRefine.

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

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

Zwischenfazit

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

Abgleich mit lokaler CSV Datei

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

Abgleich mit reconcile-csv (Clojure)

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

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

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

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

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

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

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

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

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

Abgleich mit csv-reconcile (Python)

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

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

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

1
2
3
4


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

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

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

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

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

Abgleich mit der GND

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

Fazit

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

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

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

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

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

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

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

Findbuch Index mit OpenRefine aufbereiten

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

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

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

Generelles Vorgehen

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

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

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

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

Zur Aufarbeitung des Index gehen wir wie folgt vor:

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

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

1. Index aus Findbuch extrahieren

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

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

Index Prokuratoren Akten RKG Band 57 - Wertheim .

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

2. Spalten zusammenführen

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

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

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

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

1 Spalte in Original umbennen

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

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

Bildschirmfoto der geladenen Daten ohne Bearbeitung in OpenRefine.

2 Seiten als records

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

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

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

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

Bildschirmfoto von Seiten als ‘records’ in OpenRefine.

3 Spalten zeilenweise auftrennen

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

Dialog zum Aufteilen von Spalten in OpenRefine.

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

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

Bildschirmfoto der aufgeteilten Spalten in OpenRefine.

4 Records in einer Zeile zusammenfassen

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

Bildschirmfoto der zusammengeführen Zeilen in OpenRefine.

5 Spalten zusammenführen

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

Dialog zum Zusammenführen der Spalten in OpenRefine.

Das Ergebnis ist in Abbildung 9 gezeigt.

Bildschirmfoto der zusammengeführten Spalten in OpenRefine.

6 Zeilen auftrennen

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

Dialog zum Auftrennen der Zeilen in OpenRefine.

Das Ergebnis ist in Abbildung 11 gezeigt.

Bildschirmfoto der aufgetrennten Zeilen in OpenRefine.

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

3. Informationen zu Prokuratoren zusammenführen

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

Informationen auftrennen

Spalte Name

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

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

Spalte Jahre

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

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

Spalte Verweise

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

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

Spalten umformatieren

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

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

Bildschirmfoto der extrahierten Spalten in OpenRefine.

Spalte Jahre

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

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

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

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

Spalte Verweise

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

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

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

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

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

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

Spalte Name

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

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

Dialog zum Aufsplitten von Spalten in OpenRefine.

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

Bildschirmfoto der aufgeräumten Spalten in OpenRefine.

4. Abgleich mit der Gemeinsamen Normdatei

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

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

Bei uns hat sich das folgende Vorgehen bewährt.

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

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

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

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

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

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

Bildschirmfoto der abzugleichenden Daten in OpenRefine.

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

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

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

Bildschirmfoto der abgeglichenen Daten in OpenRefine.

5. Umwandlung in Deskriptorenformat

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

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

Das Endergebnis ist in Abbildung 19 gezeigt.

Bildschirmfoto der umgewandelten und abgeglichenen Daten mit OpenRefine.

💾 Die einzelnen Arbeitsschritte im OpenRefine Format:

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

Fazit

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

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

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

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

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.

Einträge analoger Findbüchern automatisiert in Datenbanken übernehmen - Reguläre Ausdrücke

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

Im FDMLab haben wir einige analoge Findbücher digitalisiert und die Einträge automatisiert in unsere Datenbanksysteme übernommen. Dieser Blogbeitrag konzentriert sich auf die Extraktion der Informationen mit regulären Ausdrücken.

Dabei gehen wir recht technisch vor und zeigen Codebeispiele in Python und mit spaCy 3.0.

Bei spaCy handelt es sich um ein Python basiertes Framework für Natural Language Processing (NLP). Wir konzentrieren uns hier auf einen kleinen Teil des Frameworks, nämlich das regelbasierte Matching.

Inhaltsverzeichnis

Folgende imports sind notwendig um die Code-Beispiele auszuführen.

import re

from spacy import displacy
from spacy.lang.de import German
from spacy.matcher import Matcher
from spacy.tokens import Span

Wir versuchen die (Code-)Beispiele so knapp und verständlich wie möglich zu halten. Daher fehlen einige Details (Fehlerbehandlung, Spezialfälle, …).

Einfache reguläre Ausdrücke

Bei unseren Projekten zur Findbuchextraktion haben wir häufig die Situation, dass wir die Inhalte eines Textblocks auf mehrere Felder in der Zieldatenbank mappen.

Hier haben wir ein markiertes Beispiel für den Beginn eines Findbucheintrages.

42 NR HSTA L13 42 SIG ( A9594 ASIG ) 1798 DATUM

Hier sind die Findbuchnummer (NR), die Bestellsignatur (SIG), die Altsignatur (ASIG), die Vorsignatur (VSIG) und ein zugehöriges Datum (DATUM) der Archivalie in einer Zeile und sollen als einzelne Datenfelder extrahiert werden.

Mit einem regulären Ausdruck und so genannten “named capturing groups” lassen sich die benötigten Datenschnippsel (Entities) extrahieren und direkt für die Datenbank weiterverarbeiten.

Code-Beispiel:

text1 = "42 HSTA L13 42 (A9594) 1798"
pattern = "^(?P<NR>\d+)\s+(?P<SIG>[^\(]+)\s+\((?P<ASIG>.+)\)\s+(?P<DATUM>\d+)$"
re.match(pattern, text1).groupdict()

Ausgabe:

{'NR': '42', 'SIG': 'HSTA L13 42', 'ASIG': 'A9594', 'DATUM': '1798'}

Aber: zumindest in den von uns bearbeiteten Findbüchern blieb das Schema nie so konsistent, als dass die Daten mit nur einem verständlichen regulären Ausdruck extrahiert werden konnten. Hier eine weitere Zeile aus einem Findbucheintrag aus dem gleichen Band.

113a NR HSTA L13 50-55c SIG (Vorsignatur: GLAK B33 F 7 13b VSIG , T1234c ASIG ) ca. 18. Jhd. DATUM

Hier funktioniert der oben gezeigte reguläre Ausdruck nicht mehr.

Code-Beispiel:

text2 = "113a HSTA L13 50-55c (Vorsignatur: GLAK B33 F 7 13b, T1234c) ca. 18. Jhd."
re.match(pattern, text2) is None

Ausgabe:

True

Der Einsatz von einzelnen regulären Ausdrücken führte bei uns zu unübersichtlichen und nicht zu pflegenden Konstrukten. Daher sind wir dazu übergegangen, die unterschiedlichen Bestandteile einzeln und mit mehreren regulären Ausdrücken zu erfassen.

Mehrere reguläre Ausdrücke

Anstatt alle Bestandteile in einem regulären Ausdruck zu erfassen, kann man einen Text auch mit mehreren getrennten regulären Ausdrücken bearbeiten.

Code-Beispiel:

asig_regex = r"[A-Z]\d+[a-z]?"
entity_definitions = {
 "NR": [r"^\d+[a-z]?"],
 "SIG": [r"HSTA.+(?=\()"],
 "ASIG": [fr"(?<=\(){asig_regex}(?=\))", fr"(?<=, ){asig_regex}(?=\))"],
 "VSIG": [r"(?<=Vorsignatur: ).+(?=,)"],
 "DATUM": [r"(?<=\) ).+$"]
}

for text in [text1, text2]:
 found = {}
 for key, regex_list in entity_definitions.items():
 for regex in regex_list:
 match = re.search(regex, text)
 if match:
 found[key] = match.group()
 print(found)

Ausgabe:

{'NR': '42', 'SIG': 'HSTA L13 42 ', 'ASIG': 'A9594', 'DATUM': '1798'}
{'NR': '113a', 'SIG': 'HSTA L13 50-55c ', 'ASIG': 'T1234c', 'VSIG': 'GLAK B33 F 7 13b', 'DATUM': 'ca. 18. Jhd.'}

Diese Methode ist aufwendiger in der Implementierung, jedoch deutlich flexibler als die Verwendung eines einzelnen regulären Ausdrucks.

Aber auch hier zeigen sich schnell mehrere Probleme:

Keine Warnung/Fehler, wenn sich reguläre Ausdrücke überlappen.
Keine automatische Anpassung, wenn es mehrere Ergebnisse für ein Entity gibt.
Keine Markierung von schon ausgewählten/extrahierten Informationen.

Dies lässt sich nachrüsten, sorgt jedoch für weitere Komplexität bei der Umsetzung. Eine Lösung hierfür bieten Frameworks zur Extraktion von Informationen aus Text, wobei wir spaCy für diesen Zweck einsetzen.

Regelbasiertes Matching mit spaCy

Das NLP Framework spaCy hat ein eigenes System für das regelbasierte Matching.

Daher hier ein Beispiel mit einer spaCy Pipeline.

Code-Beispiel:

nlp = German()

ruler = nlp.add_pipe("entity_ruler")
patterns = [
 {"label": "NR", "id": "nr", "pattern": [{"IS_SENT_START": True, "IS_DIGIT": True}]},
 {"label": "NR", "id": "nr", "pattern": [
 {"IS_SENT_START": True, "TEXT": {"REGEX": r"^\d+[a-z]?$"}}]},
 {"label": "SIG", "id": "sig", "pattern": [
 {"TEXT": "HSTA"}, {"SHAPE": "Xdd"}, {"TEXT": {"REGEX": r"^\d+[a-z]?$"}},
 {"TEXT": "-", "OP": "?"}, {"TEXT": {"REGEX": r"^\d+[a-z]?$"}, "OP": "?"}]},
 {"label": "ASIG", "id": "asig", "pattern": [{"SHAPE": "Xdddd"}]},
 {"label": "ASIG", "id": "asig", "pattern": [{"SHAPE": "Xddddx"}]},
 {"label": "DATUM", "id": "date", "pattern": [{"SHAPE": "dddd"}]},
 {"label": "DATUM", "id": "date", "pattern": [
 {"TEXT": "ca."}, {"SHAPE": "dd."}, {"TEXT": "Jhd."}]},
]
ruler.add_patterns(patterns)

doc = nlp(text1)
displacy.render(doc, style="ent")

42 NR HSTA L13 42 SIG ( A9594 ASIG ) 1798 DATUM

doc2 = nlp(text2)
displacy.render(doc2, style="ent")

113a NR HSTA L13 50-55c SIG (Vorsignatur: GLAK B33 F 7 13b, T1234c ASIG ) ca. 18. Jhd. DATUM

Bei diesem Code-Beispiel sehen wir einige Vorteile bei der Verwendung von spaCy. Wir können die mitgelieferten Visualisierungstools verwenden, mehrere Regeln für ein Entity hinterlegen und auf weniger komplexe Regeln zurückgreifen (Shape-Pattern, IS_PUNCT, …).

Wir können uns auch direkt die übersprungenen Teile ausgeben lassen (oder sie markieren).

Code-Beispiel:

print([token for token in doc2 if not (token.ent_type_ or token.is_punct)])

Ausgabe:

[Vorsignatur, GLAK, B33, F, 7, 13b]

Hier zeigen sich auch gleich mehrere Probleme bei der Verwendung von regelbasiertem Matching mit spaCy:

Jedes Muster passt immer nur auf einen Token.
Ein “lookahead” oder “lookbehind” wie bei regulären Ausdrücken ist (noch) nicht möglich. Es gibt also keine Entsprechung für (?<=Vorsignatur: )[^,]+(?=,).

Um trotzdem nur die Vorsignatur zu extrahieren, ohne das Prefix “Vorsignatur: " mitzuspeichern, gibt es mehrere Lösungen:

Nachbearbeitung der Entities, also das Prefix in einem separaten Durchlauf löschen.
Die komplexen Muster in einem separaten Durchlauf verarbeiten (nächster Abschnitt).
Reguläre Ausdrücke (Gesamttext) mit spaCy kombinieren (übernächster Abschnitt).

Erweitertes regelbasiertes Matching mit spaCy

Für das folgende Beispiel wollen wir ein Entity basierend auf “Umgebungsinformationen” bestimmen. Nehmen wir zum Beispiel an, dass es ziemlich komplex ist die Signatur zu bestimmen, wir aber wissen, dass die Signatur immer nach der Findbuch-Nr zu finden ist.

Also würden wir gerne ein Muster der Form (?<=NR).+(?=\()definieren. Dafür verarbeiten wir den ersten Beispielsatz zweimal mit spaCy.

Zuerst erstellen wir wieder eine Pipeline, die uns die “einfachen” Entities markiert.

Code-Beispiel:

nlp = German()

ruler = nlp.add_pipe("entity_ruler")

patterns = [{"label": "NR", "pattern": [{"IS_SENT_START": True, "IS_DIGIT": True}]}]
ruler.add_patterns(patterns)

doc = nlp(text1)
displacy.render(doc, style="ent")

42 NR HSTA L13 42 (A9594) 1798

Anschließend verarbeiten wir den mit Markierungen versehenen Beispielsatz mit einem Matcher und unserem komplexen Muster.

Code-Beispiel:

matcher = Matcher(nlp.vocab)
signature_pattern = [
 {"ENT_TYPE": "NR"},
 {"TEXT": {"NOT_IN": ["("]}, "OP": "+"},
 {"TEXT": "("}
]
matcher.add("Signature", [signature_pattern])

matches = matcher(doc)
for _, start, end in matches:
 entity = Span(doc, start + 1, end - 1, label="SIG")
 doc.ents += (entity,)

displacy.render(doc, style="ent")

42 NR HSTA L13 42 SIG (A9594) 1798

Hier erstellen wir das Entity selbst und fügen es den von spaCy verwalteten Informationen hinzu. Der gefundene Treffer beinhaltet das Entity NR und die öffnende Klammer (, daher schneiden wir noch vorne und hinten jeweils einen Token ab.

Im ersten Durchlauf für die Nr hat die Pipeline Komponente diese Aufgaben übernommen.

Hinweis: leider beinhalten die Treffer keinen Hinweis auf die Regel, die den Treffer erzeugt haben. Hat man viele Regeln, die mit unterschiedlichen Labels oder Beschnitt versehen werden sollen, empfehlen sich entweder der on_match Callback für die Regeln, oder eine Custom Component für die Pipeline.

Kombiniere reguläre Ausdrücke mit spaCy

Die Ansätze mit regulären Ausdrücken auf dem Gesamttext und dem regelbasierten Matching mit spaCy lassen sich auch kombinieren. Zuerst lassen wir das Dokument von spaCy analysieren. Anschließend wenden wir die regulären Ausdrücke auf den Gesamttext an und ermitteln die Position der Treffer. Mit dieser Information erzeugen wir dann Entities mit spaCy.

Code-Beispiel:

nlp = German()

ruler = nlp.add_pipe("entity_ruler")
patterns = [
 {"label": "NR", "id": "nr", "pattern": [{"IS_SENT_START": True, "IS_DIGIT": True}]}
]
ruler.add_patterns(patterns)

doc = nlp(text1)
displacy.render(doc, style="ent")

42 NR HSTA L13 42 (A9594) 1798

entity_definitions = {"DATUM": r"(?<=\) ).+$"}

for key, regex in entity_definitions.items():
 match = re.search(regex, doc.text)
 if match:
 start, end = match.span()
 entity = doc.char_span(start, end, label=key)
 doc.ents += (entity,)

displacy.render(doc, style="ent")

42 NR HSTA L13 42 (A9594) 1798 DATUM

Ein ähnliches Beispiel dazu findet sich auch in der spaCy Dokumentation.

Hier sind noch die folgenden Dinge zu beachten:

Es werden keine Entities überschrieben.
Es können keine sich überschneidenden Entities angelegt werden.
Manchmal “rutschen” Trennzeichen (z.B. Leerzeichen) mit in den Beginn oder das Ende der Treffer. Diese führen beim Setzen einer Entity in spaCy zu einem Fehler.

Die entsprechenden Fehlerbehandlungen haben wir im Code-Beispiel ausgelassen.

Fazit

Bei der Aufbereitung von Findbüchern für die Datenbank sind wir sowohl mit regulären Ausdrücken, als auch mit dem Regelsystem von spaCy an die jeweiligen Grenzen der Technologie gestoßen. Dabei haben wir die Toolunterstützung von spaCy zu schätzen gelernt, die uns einiges an Entwicklungsaufwand abnimmt und bei der Visualisierung der Ergebnisse unterstützt.

Mit einer Kombination aus regulären Ausdrücken und Regeln in spaCy, die auf schon identifizierten Entities basieren, konnten wir mit einer übersichtlichen Codebasis selbst komplexe Datenaufbereitungen durchführen.

80. Südwestdeutscher Archivtag 2021

Fri, 18 Jun 2021 11:00:00 +0000

Werkzeuge zur Texterkennung: ein Blick in die digitale Werkstatt des FDMLab am Landesarchiv Baden-Württemberg

Fri, 18 Jun 2021 11:00:00 +0000

Wie wir gedruckte Findbücher in unsere Datenbank bekommen, ohne zu viel Zeit in manuelle Arbeiten zu investieren

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

Viele Archive kennen diese Situation: Es gibt ein archivisches Fachinformationssystem (AFIS), über das Archivgut erschlossen und für eine Online-Recherche bereitgestellt wird. Doch gleichzeitig existiert zu einigen Beständen auch noch eine Reihe älterer gedruckter Findbücher im Lesesaal. Diese Bestände können nicht in der Datenbank recherchiert werden.

Um für diese Bestände zeitgemäße Recherchemöglichkeiten bieten zu können, müssen die Erschließungsinformationen aus den analogen Findbüchern in das digitale Fachinformationssystem übertragen werden. Wie geht das, ohne dass Archivar*innen zu viel wertvolle Arbeitszeit in manuelle Arbeitsschritte investieren? In diesem Beitrag zeigen wir an einem Beispiel, wie wir dieses Problem im FDMLab angegangen sind und was wir dabei gelernt haben.

Der Prozess

Überblick über unseren Prozess, es folgen die einzelnen Bearbeitungsschritte im Detail.

Findbuch digitalisieren und Volltexterkennung durchführen

--- title: Prozess: OCR config: look: handDrawn theme: neutral --- flowchart LR A[Findbuch] --> |OCR| B[Word]

Im FDMLab wollen wir das Findbuch „Fürstlich Thurn und Taxissches Archiv Obermarchtal Grafschaft Friedberg-Scheer“¹ bearbeiten, das 1.517 Urkunden des 14. bis 19. Jahrhunderts enthält. Das Findbuch wurde im Vorfeld digitalisiert und es wurde eine Volltexterkennung mittels OCR durchgeführt. Das Ergebnis hat das FDMLab in Form einer docx-Datei erhalten.

Extraktion der Erschließungsdaten

--- title: Prozess: Textexport config: look: handDrawn theme: neutral --- flowchart LR B[Word] --> |Textexport| C[Text]

Ziel ist es nun, die Daten in ein maschinenlesbares Format umzuwandeln, das wir später in unser AFIS importieren können. Hierfür wandeln wir die Datei in eine txt-Datei um.

Die docx-Datei ist aus zwei Gründen nicht für die weitere automatische Verarbeitung der Daten geeignet:

Word verwendet schwebende Felder, um manchen Text so zu platzieren, wie er vermeintlich im Original vorlag. Diese Felder müssen in der Struktur des XML-Dokuments erstmal gefunden und dann deren Position im Text separat berechnet werden. Daher ist es einfacher, mit dem Reintext zu arbeiten, in dem der Text schon “richtig” formatiert ist.
Word hat einige Findbuchnummern und Datumsangaben als Aufzählfelder deklariert. Eine manuelle Korrektur oder Veränderung eines solchen Feldes (z.B. wegen OCR oder Layoutproblemen) kann unerwartete Seiteneffekte haben. Beispielsweise wird in so einem Fall beim Einfügen einer Leerzeile von Word automatisch eine Findbuchnummer mehrere Seiten später hochgezählt.

Es hat sich bewährt, eine Ausgabe des analogen Findbuchs stets zur Hand zu haben, um

fehlende/fehlerhafte Abschnitte korrigieren zu können,
Kürzel verstehen und auflösen zu können,
Validitätschecks (Anzahl Einträge, …) durchführen zu können.

--- title: Prozess: Daten Transformation config: look: handDrawn theme: neutral --- flowchart LR C[Text] --> |Daten Transformation| D[CSV]

Aus der txt-Datei können mit Verfahren der automatischen Textextraktion die verschiedenen Findbucheinträge aus dem Gesamtdokument separiert und die einzelnen Erschließungsdaten wie Titel, Datierung, Signatur etc. extrahiert werden. Die extrahierten Daten werden in eine csv-Datei geschrieben, da sich das csv-Format für den Import in das AFIS eignet.

In diesem Projekt haben wir ausschließlich sogenannte reguläre Ausdrücke verwendet, um Muster zur Datenextraktion zu definieren. Mit dem regulären Ausdruck \d{4}(-\d{2}){0,2} lässt sich zum Beispiel ein Datum in der Form 2020, 2020-03 oder 2020-03-28 erkennen. Auf Details werden wir in separaten Artikeln nochmal eingehen.

Import der Erschließungsdaten ins AFIS

--- title: Prozess: Import config: look: handDrawn theme: neutral --- flowchart LR D[CSV] --> |Import| E[(AFIS)]

Die csv-Datei enthält die Erschließungsdaten in einem strukturierten, maschinenlesbaren Format. Sie kann mit einem Übernahmeassistenten verarbeitet werden, der einen automatischen Import der Daten in das AFIS ermöglicht.

War bis hierher technisches Wissen gefragt, braucht es nun archivarische Expertise, denn im nächsten Schritt geht es um das Mapping der extrahierten Daten mit den Datenfeldern im Erschließungsformular für Urkunden. Nachdem die csv-Datei ausgelesen und das Mapping im Übernahmeassistenten vorgenommen wurden, können die Daten in einem Arbeitsgang in das AFIS importiert und unter einem zuvor definierten Punkt in der Tektonik eingehängt werden.

Freischalten der Erschließungsdaten für die Online-Recherche

Die Erschließungsdaten können jetzt an das Online-Findmittelsystem (OLF) des LABW übertragen und für die Internetrecherche freigeschaltet werden. Nutzer*innen können nun online nach Urkunden der Grafschaft Friedberg-Scheer recherchieren und müssen nicht mehr auf die Printversion des Findbuchs zurückgreifen.

Lessons Learned

Nach der Bearbeitung des Findbuchs können wir die folgenden Punkte als Lessons Learned mitnehmen:

Die automatische Textextraktion stellt ein geeignetes Verfahren für die Automatisierung der Übertragung von Findbüchern in die archivische Datenbank dar. Trotzdem gab es nach wie vor noch manuelle Nacharbeiten. Dies resultiert u.a. daraus, dass das gedruckte Findbuch zwar auf den ersten Blick eine normierte Form besitzt, bei näherem Hinsehen aber verschiedene Unregelmäßigkeiten bei Struktur, Layout und auch sprachlicher Gestaltung der Findbucheinträge sichtbar werden, die die Formulierung von Extraktionsregeln erschweren.
Word ist als Dateiformat für die Datenextraktion ungeeignet. Da das Layout bei der Datenextraktion relevant ist, sollte, wenn möglich, direkt mit Bilddateien und reinen Textdateien (txt) gearbeitet werden ².
Bei der Findbuchextraktion ist eine enge Zusammenarbeit von technischem und archivfachlichem Personal empfehlenswert. Durch die Zusammenarbeit kann die Granularität der Datenextraktion schneller bestimmt und die anschließende Abbildung der extrahierten Daten auf das Erfassungsformular frustfrei durchgeführt werden.

Dep. 30/1 T1 Fürstlich Thurn und Taxissches Archiv Obermarchtal Grafschaft Friedberg-Scheer. Urkundenregesten 1304-1802. Bearb. Von Robert Kretzschmar. Stuttgart 1993 (Inventare der nichtstaatlichen Archive in Baden-Württemberg ; Bd. 18), Online-Version des gedruckten Inventars. ↩︎
Die digitale Druckvorlage ist natürlich noch besser geeignet. ↩︎

2. Workshop des OCR-BW-Projektes 2021

Wed, 09 Jun 2021 11:00:00 +0000