OCR | FDMLab@LABW

Das FDMLab@LABW: Data-Science-Methoden und -Techniken für den Einsatz im Archiv

Tue, 09 Aug 2022 00:00:00 +0000

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

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

Ist NER robust gegenüber OCR Fehlern?

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

Wir haben schon mehrfach die Behauptung gehört, dass Named Entity Recognition (NER) robust gegenüber OCR Fehlern ist. Daher werden wir in diesem Beitrag die Named Entity Recognition anhand einiger Beispiele genauer betrachten.

NER ist ein intuitiv einfach wirkendes Verfahren, um Schlagwörter aus Texten zu extrahieren und zu kategorisieren. Dabei sind die Fähigkeiten von NER abhängig von den Trainingsdaten und der Art, wie das Modell trainiert wurde.

Wir verwenden für unsere Beispiele spaCy und flairNLP in Kombination mit einem deutschsprachigen Sprachmodell. Diese Modelle können die vier Klassen Personen (PER), Orte (LOC), Organisationen (ORG) und Sonstiges (MISC) unterscheiden. Das ist recht wenig im Vergleich zu Modellen für die englische Sprache, wo zum Beispiel mit den auf OntoNotes basierten Modellen 18 Klassen unterschieden werden können. Das liegt an der fehlenden Verfügbarkeit von öffentlichen Trainingsdaten für die deutsche Sprache.

Die Visualisierungen in diesem Artikel wurden mit displaCy erstellt. Mit der Online Demo von displaCy können die Beispiele selbst nachvollzogen werden.

Beispiele mit spaCy

Zum Trainieren der Sprachmodelle liegen menschlich und/oder heuristisch annotierte Beispiele/Sätze vor.

Adam PER arbeitet bei der britischen MISC Example Inc ORG in Paris LOC .

Anhand solcher Beispiele kann ein Sprachmodell lernen, was ein Named Entity ist und wie es kategorisiert werden soll. Mit genügend Beispielen lernt das Sprachmodell, dass es sich bei Adam und eine Person handelt und bei Paris um einen Ort. ¹

Aber das ist noch nicht alles. Nehmen wir einen einfachen Beispielsatz und mutieren einzelne Buchstaben, wie es bei OCR Fehlern vorkommt. Anschließend wenden wir die NER Komponenten von spaCy auf die Beispiele an.

Adam PER lebt in Paris LOC .
Adam PER lebt im Paris LOC .
Adam PER lebt in Pares LOC .
Adam PER libt in Pares LOC .

Es scheint so, als ob NER “robust” gegenüber diesen Mutationen ist. Aber bevor wir uns über dieses stabile Verfahren freuen, schauen wir uns ein weiteres Beispiel an.

Adam PER lebt im Pares.

Was ist hier passiert?

Das Sprachmodell von spaCy hat vermutlich gelernt, dass es sich bei Paris um ein Named Entity der Kategorie Ort handelt und markiert es entsprechend in den Beispielen 1 und 2.

Es hat möglicherweise auch gelernt, dass zum Beispiel die Konstruktion “in ABC” einen Ort kennzeichnet und markiert entsprechend Pares in den Beispielen 3 und 4.

Im Beispiel 5 haben wir zwei Fehler kombiniert, wodurch das Sprachmodell weder Paris, noch die Konstruktion “in ABC” erkennen konnte. ²

Interessant dabei ist, dass das Sprachmodell basierend auf der Satzkonstruktion auch die Beispiele 6 und 7 erkennt.

Adam PER lebt in Bxyueqty LOC .
Xoyietzqgf PER lebt in Bxyueqty LOC .

Hier können wir davon ausgehen, dass die Begriffe Xoyietzqgf und Bxyueqty nicht in den Trainingsdaten vorkommen. Die Bestimmung der Entities erfolgt aus der Satzkonstruktion und zeigt die Übertragbarkeit der gelernten Inhalte auf unbekannte Beispiele.

Vergleich mit flairNLP

Nicht alle Sprachmodelle lernen die gleichen Regeln aus den Trainingsdaten. Beispielsweise hat flairNLP ein Problem mit unserem Beispiel 4 (8), erkennt Beispiel 5 (9) aber korrekt.

Adam PER libt in Pares.
Adam PER lebt im Pares LOC .

Vielleicht hat das Sprachmodell von flairNLP gelernt, dass die Konstruktion “lebt … ABC” einen Ort kennzeichnet. ³

NER und Mehrdeutigkeit

Ein interessantes Feld ist auch das Auflösung von Mehrdeutigkeiten. So ist für den menschlichen Leser klar, dass es sich bei Paris in Beispiel 10 um eine Person handelt. SpaCy kennzeichnet Paris in Beispiel 10 als Ort.

Adam PER liebt Paris LOC . Sie ist wirklich nett.

Da die meisten Sprachmodelle auf einzelne Sätze trainiert werden, fehlt ihnen die Möglichkeit den umgebenden Kontext mit in Betracht zu ziehen.

Für flairNLP gibt es die FLERT Modelle, die mehrere Sätze gleichzeitig betrachten und daher den Kontext mit in Betracht ziehen können. Beispiel 11 wurde mit einem FLERT Model markiert.

Adam PER liebt Paris LOC . Sie ist wirklich nett.

Überraschenderweise wurde hier auch Paris als Ort markiert. Laut flairNLP/flair#2193 wurde für Version 0.8.0 das Sprachmodell neu trainiert und erkennt Paris als Ort, wo es bei früheren Versionen Paris noch korrekt als Person erkannte.

Versuchen wir es mit einem anderen Beispiel (12 und 13), was zwar nicht zu unserem Paris Beispiel passt, jedoch die Fähigkeiten der FLERT Modelle zeigt:

Adam PER liebt Buxtehude LOC .
Adam PER liebt Buxtehude PER . Adam PER und Buxtehude PER sind verheiratet.

Fazit

Es ist nicht transparent, welche exakten Regeln ein Sprachmodell aus den Trainingsdaten ableitet. Es können einzelne Begriffe sein, die als Named Entity erkannt werden, oder eine bestimmte Wortkonstruktion (“in ABC”). Manchmal wird auch die Struktur und die Grammatik des Satzes beim Training und der Anwendung mit berücksichtigt (Beispiel 14). Oder anstatt auf einzelnen Sätzen wird auf größeren Textabschnitten trainiert, wie es bei den FLERT Modellen der Fall ist.

Die vermeintliche Robustheit von NER gegenüber OCR Fehlern kommt von der Fähigkeit der Sprachmodelle auf Basis der Satzstruktur auch unbekannte oder mit OCR Fehlern versehene Entities zu erkennen. OCR Fehler im Entity sind also nicht problematisch. Ein simpler OCR Fehler außerhalb des Entity, wie ein fehlendes Leerzeichen, kann abhängig vom Sprachmodell die Erkennung massiv stören (Beispiel 15).

Adam lebtin Paris PER .

Von daher ist für uns die Aussage “NER ist robust gegenüber OCR Fehlern” zu unspezifisch.

Auf die Mehrdeutigkeit des Begriffs Paris, welches auch als Vorname verwendet wird, gehen wir am Ende des Artikels ein. ↩︎
Für diese Beispiele haben wir das Sprachmodell de-core-news-sm in Version 3.0.0 verwendet. In Version 2.3.0 wurde Beispiel 5 noch richtig erkannt. ↩︎
Für diese Beispiele haben wir das Sprachmodell ner-german-large in Version 0.8.0 verwendet. ↩︎

Analyse tabellarischer Layoutstrukturen mit Transkribus

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

Eine gute Layouterkennung ist die Voraussetzung für eine gute OCR- oder HTR-Erfassung von Dokumenten. Anhand von Stammrollen aus dem LABW testen wir, welche Möglichkeiten Transkribus bei der Layouterkennung komplexer Tabellenstrukturen bietet.

Unser Ausgangsmaterial: Stammrollen mit Tabellen-Layout

Die militärischen Bestände des LABW aus dem Zeitraum zwischen 1871 bis ca. 1920 beinhalten u.a. umfangreiche militärische Personalunterlagen. Dazu gehören die sogenannten Kriegs- und Friedensstammrollen von verschiedenen Regimentern. Diese listen alle Angehörigen einer Einheit mit Daten zur Person, den Angehörigen, mitgemachten Gefechten, Auszeichnungen etc. auf. Die Stammrollen sind für viele unterschiedliche Forschungsfragen interessant und insbesondere auch für Genealogen eine gerne genutzte historische Quelle.

Die Stammrollen sind bereits vollständig digitalisiert und über das Online Findmittelsystem (OLF) des LABW einsehbar.¹ Durch eine zusätzliche Volltexterfassung der Namen und Geburtsdaten aus den Stammrollen könnte man schnell und bequem nach einer bestimmten Person suchen. Das wäre ein echter Mehrwert für genealogische Forschungen! Wir testen, wie wir dies mit Transkribus umsetzen können.

Hier zuerst ein Blick auf das Layout unserer Stammrollen:

Tabellarisches Layout der Stammrollen (Quelle: Landesarchiv Baden-Württemberg, Hauptstaatsarchiv Stuttgart M 439 Band 270).

Layouterkennung als Basis für die Transkription

Die Layoutanalyse ist in Transkribus der erste Schritt, bevor man ein Dokument manuell oder automatisiert transkribieren kann. Bei der Layoutanalyse wird ein Dokument in Textregionen, Zeilen und Basislinien unterteilt. Die Texterkennung arbeitet auf der Basis dieser Segmentierung. Ausführliche Informationen, wie man die automatische Layoutanalyse durchführen kann, gibt es auf der Transkribus-Website.²

Wir testen, wie gut die automatische Layoutanalyse bei unseren Stammrollen funktioniert.

Ergebnisse der automatischen Layoutanalyse

Schon ein kurzer Blick auf eine Seite aus unseren Stammrollen zeigt, dass wir es mit einem komplexen Layout zu tun haben: Unsere Tabelle besitzt 15 Spalten mit Spaltenüberschriften. Auf einer (Doppel-)Seite gibt es in der Regel zwei Einträge, sprich Zeilen. Die Zellen innerhalb einer Zeile sind teilweise noch einmal in zwei kleinere Zellen unterteilt. Was wir als Menschen sofort verstehen, stellt an Transkribus hohe Anforderungen bei der richtigen Erkennung von Textabschnitten und Zeilen und der Festlegung der Lesereihenfolge der einzelnen Elemente. Wir haben Transkribus eine harte Nuss zu knacken gegeben!

Die Ergebnisse der automatischen Layoutanalyse sind dementsprechend fehlerhaft. Der Großteil des Textes wurde als Textzeilen erkannt. Vor allem in den Spaltenüberschriften, vereinzelt auch in den Tabelleneinträgen, gibt es aber auch Textzeilen, die nicht als solche erkannt wurden.

Bei der Erkennung der Textregionen scheint Transkribus sich insgesamt an den Tabellenspalten zu orientieren. Dies hat jedoch nicht zufriedenstellend funktioniert. Während einerseits mehrere Tabellenspalten in einer Textregion zusammengefasst wurden, sind andere Spalten in mehrere Regionen aufgeteilt worden, die sich teilweise auch überlappen.

Auch, wenn das Layout der Tabelle auf jeder Seite dasselbe ist, werden bei jeder Seite unterschiedliche Textregionen erkannt, da die Textverteilung sich auf den Seiten unterscheidet. Das Ergebnis der automatischen Layoutanalyse ist daher bei gleichen Voreinstellung auf jeder Seite etwas anders.

Die fehlerhaften Textregionen stellen deshalb ein Problem dar, weil dadurch auch die Lesereihenfolge der Zeilen durcheinandergerät.

Ergebnis der automatischen Layoutanalyse von Transkribus.

Manuelle Bearbeitungsmöglichkeiten

Um zu einem brauchbaren Ergebnis zu kommen, sind manuelle Nacharbeiten erforderlich. Transkribus stellt uns dafür umfangreiche Möglichkeiten zur Verfügung. Eine detaillierte Anleitung findet sich ebenfalls auf der Transkribus-Website.³ Zuerst müssen die Textregionen korrigiert werden. Sinnvoll ist es hier, jeweils eine Tabellenzelle als eine Textregion zu kennzeichnen.⁴ Nachdem die Lesereihenfolge der Textregionen berichtigt wurde, werden auch die Basislinien innerhalb der Textregionen manuell korrigiert, wo dies nötig ist. Abschließend wird die Lesereihenfolge der Zeilen angegeben.

Manuelle Nachbearbeitung der Layouterkennung.

Tipps für manuelle Layoutkorrekturen

Um fehlerhafte Textzeilen zu korrigieren, müssen Sie die Basislinien korrigieren, an denen sich die Texterkennung orientiert. Die Zeilen werden dann automatisch ebenfalls angepasst.
Wenn Sie Text aus einer Textregion auf zwei unterschiedliche Textregionen aufteilen möchten, nutzen Sie das Werkzeug zum Zerschneiden von Elementen (gekennzeichnet durch das Scherensymbol). Nur so werden die Zeilen korrekt zu zwei Regionen zugeordnet.
Achten Sie darauf, dass sich Textregionen nicht überlappen.

Fazit

Die automatische Layoutanalyse von Transkribus, die bei einfachen Layouts durchaus überzeugend funktionieren mag, kann ein komplexes Tabellenlayout wie das unserer Stammrollen nicht mit ausreichender Qualität verarbeiten. Transkribus bietet uns umfangreiche Möglichkeiten, die Layouterkennung manuell nachzubearbeiten. So haben wir am Ende unseres Tests die Seite aus der Stammrolle zufriedenstellend segmentiert. Die Nacharbeiten nehmen jedoch viel Zeit in Anspruch, sodass dieses Vorgehen nicht geeignet ist, um unseren gesamten Bestand an Kriegs- und Friedensstammrollen im LABW zu bearbeiten.

Um einen effizienteren Weg zu finden, unser Tabellenlayout zu analysieren, werden wir als nächstes das Tool P2PaLA testen, welches in Transkribus integriert und ab Version 1.15.1 für alle Transkribus User freigeschaltet ist. Mit P2PaLA lässt sich ein spezifisches Strukturmodell für die Layouterkennung einer Dokumentensammlung trainieren. Auf diese Weise möchten wir einen höheren Automatisierungsgrad bei der Erkennung unseres Stammrollen-Tabellenlayouts erreichen. Wir werden in einem Folgebeitrag davon berichten.

Die Bestände des Hauptstaatsarchivs Stuttgart HStA M 430/1 - M631 in OLF. ↩︎
Anleitung zur Layoutanalyse mit Transkribus im Transkribus-Ressourcenzentreum der READ COOP. ↩︎
Anleitung „Wie man Dokumente mit Transkribus transkribiert“ im Transkribus-Ressourcenzentreum der READ COOP. ↩︎
Grundsätzlich kennt das von Transkribus verwendete PAGE XML Format auch Tabellen. Jedoch werden rekursive Strukturen (Tabelle -> Zelle -> Text) unserer Erfahrung nach nicht von allen Werkzeugen zuverlässig unterstützt. ↩︎

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

Wie wir Docker einsetzen

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

Programme haben Anforderungen an ihre Umgebung. Dies kann ein bestimmtes Betriebssystem sein (Windows, Linux, macOS), eine Laufzeitumgebung für eine Programmiersprache (Python, Java, C#), oder die Verfügbarkeit bestimmter Bibliotheken (GTK, .NET, Qt). Wir wollen uns beim Testen und Evaluieren aber nicht einschränken!

Im FDMLab evaluieren wir Programme und Bibliotheken, die sowohl für den Gebrauch am Rechner, als auch als Serveranwendung entwickelt wurden. Würden wir diese alle auf unserem Testrechner installieren, hätten wir schnell die von Randall Munroe dargestellte Situation erzeugt. Also unser System mit Programmen, Laufzeitumgebungen und Konfigurationsdateien vollgemüllt.

Python Environment von Randall Munroe unter CC BY-NC Lizenz.

Stattdessen versuchen wir - sofern möglich - die zu evaluierenden Programme als Docker Container zu testen. Wie im Eingangsbild symbolhaft dargestellt¹, handelt es sich bei Docker Containern (vereinfacht) um einen Standard um Anwendungen mitsamt ihrer Umgebung zu verpacken und somit auf unterschiedlichen Docker Hosts laufen zu lassen.

Wir verwenden dafür Docker Desktop für Windows.

Docker Container via Browser

--- title: Docker Container via Browser config: look: handDrawn theme: neutral --- flowchart TD subgraph Container[Container] FC[Dateien] Server[[Server]] DB[(Datenbank)] Lib{{Bibliotheken}} end Browser[[Browser]] FU[Dateien] FU <--> FC --> Server Server --> Browser DB --> Server Lib --> Server

Eine Variante Docker zu verwenden, ist mit der Anwendung in dem Container via einer Web GUI im Browser zu interagieren. Ein Beispiel hierfür ist das Projekt OCR4All. Mit dem folgenden PowerShell Befehl wird die Vorlage für einen OCR4All Container (image) aus der Docker Hub Registry heruntergeladen und lokal ein OCR4All Container erstellt.

docker run --rm -it -p 8080:8080 ls6uniwue/ocr4all

Über die Adresse http://localhost:8080 lässt sich die Web GUI des OCR4All Containers aufrufen und bedienen.

Es ist möglich Daten von der eigenen Festplatte mit in den Container einzuhängen (mounten).

docker run --rm -it -p 8080:8080 -v ${PWD}:/var/ocr4all/data ls6uniwue/ocr4all

Docker Container als Skript

Docker Container können ähnliche wie Skripte verwendet werden.

Mit dem folgenden Beispiel wird ein OCR-D Workflow ausgeführt, ohne dass die mehr als 60 unterschiedlichen Prozessoren separat installiert werden müssen.

docker run --rm -v ${PWD}:/data -w /data -- ocrd/all:maximum bash workflow.sh

Das Image ocrd/all:maximum ist mehrere Gigabyte groß!

Wo Docker nicht funktioniert

Es gibt Software, die nicht als Docker Image vorliegt, oder als solche verwendet werden kann. Dazu gehört Software, die eine systemspezifische GUI Bibliothek verwendet.

Beispiele hierfür sind der Page Viewer oder der Transkribus Expert Client. Diese benötigen beide Java als Laufzeitumgebung und stellen ihre GUI mit nativen Betriebssystemkomponenten dar. Docker Container haben keine nativen GUI Komponenten, weshalb diese Programme in einem Docker Container nicht genutzt werden können ².

Unser Fazit

Wir verwenden Docker um schnell und unkompliziert unterschiedlichste Anwendungen evaluieren zu können. Inzwischen kommen Docker Container bei uns auch praktisch zum Einsatz. Zum Beispiel um gemeinsame Projekte reproduzierbar bearbeiten zu können.

Die Standardisierung von Seefracht-Containern zu ISO-Containern optimierte die Transportkette im Güterverkehr. Daher werden standardisierte virtuelle Container häufig mit Fracht-Containern verglichen. ↩︎
Es gibt Bibliotheken, die die nativen GUI Komponenten für Webbrowser darstellen können. Ein Beispiel hierfür ist GTK Broadway. ↩︎