RegEx | FDMLab@LABW

Workshop - Arbeiten mit regulären Ausdrücken

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

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

Einführung

Reguläre Ausdrücke in der OpenRefine Dokumentation.

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

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

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

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

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

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

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

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

Vorbereitung

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

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

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

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

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

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

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

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

Aufgabe 1: Zeichenauswahl (Character Classes)

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

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

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

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

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

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

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

Lösung:

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

Aufgabe 2: Zeichenklassen (Shape Matching)

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

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

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

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

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

Lösung:

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

Aufgabe 3: Verneinungen

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

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

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

Lösung:

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

Aufgabe 4: Quantoren (Quantifiers)

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

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

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

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

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

Lösung:

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

Aufgabe 5: Gruppierungen (Group Constructs)

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

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

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

Bildschirmfoto von RegEx101 mit den extrahierten Gruppen.

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

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

Bildschirmfoto von RegEx101 mit den benannten Gruppen.

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

Bildschirmfoto von RegEx101 mit den erwarteten Ergebnissen.

Lösung:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hinweise:

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

Lösung:

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

Aufgabe 7: Datums Einschränkungen

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

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

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

Hinweise:

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

Aufgabe 8: Spezielle Zeichen

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

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

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

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

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

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

Siehe auch Code AFE2A00F.

Lösung:

/\d+\.\d+/gm

Aufgabe 9: Reguläre Ausdrücke in OpenRefine

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

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

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

Kurzbiographien als CSV

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

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

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

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

Hinweise:

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

Lösung:

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

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

Alternative Lösung(en):

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

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

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

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

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

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

Aufgabe 10: Vorsicht bei Umlauten

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

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

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

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

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

Hinweise:

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

Fazit

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

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

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

09 Arbeiten mit GREL

Workshop für Fortgeschrittene - Warum OpenRefine?

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

In diesem Workshop für Fortgeschrittene gehen wir tiefer in die spezialisierten Funktionalitäten von OpenRefine und beschäftigen uns mit angrenzende Themen. Unter anderem betrachten wir reguläre Ausdrücke und programmieren mit der General Refine Expression Language (GREL).

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

Inhalte des Workshops

Warum eigentlich OpenRefine für Fortgeschrittene?

OpenRefine is Excel on steroids!

Oder um einen bildlichen Vergleich eines Workshop Teilnehmers wiederzuverwenden:

Mit Excel hatten wir bisher einen Trabi.
Mit OpenRefine haben wir einen Ferrari bekommen.

Der Umgang mit einem solchen Werkzeug sollte jedoch geübt und vertieft werden. Viele Funktionalitäten von OpenRefine sind über die graphische Oberfläche bedienbar. Jedoch können einige Bearbeitungsschritte vereinfacht oder automatisiert werden. Im Workshop für Einsteiger haben wir uns auf grundlegende Funktionen von OpenRefine fokussiert. Diesmal vertiefen wir einige Konzepte oder ergänzen Sie mit weiteren Technologien.

Wir werden dabei unter anderem die Programmiersprache GREL kennen lernen. Diese ist bei weitem nicht so mächtig, wie zum Beispiel Java oder Python. Jedoch können wir damit schon einige Dinge automatisieren und vereinfachen.

Außerdem werden wir uns mit regulären Ausdrücken beschäftigen. Diese helfen uns Daten zu finden, die bestimmten Mustern entsprechen.

Im ersten Teil machen wir einen Exkurs zum Arbeiten mit regulären Ausdrücken zur Erkennung und Extraktion von Mustern.

08 Arbeiten mit regulären Ausdrücken

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.

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