Erfahrungen | FDMLab@LABW

Deutscher Archivtag 2024

Thu, 10 Oct 2024 15:00:00 +0000

Schleswig-Holsteinischer Archivtag 2024

Wed, 24 Apr 2024 10:50:00 +0000

Abschluss des FDMLab@LABW

Mon, 31 Jul 2023 00:00:00 +0000

Nach drei Jahren endet das Projekt FDMLab@LABW. Wir nutzen die Gelegenheit, um hier im Blog noch einmal einen Überblick über unsere Ergebnisse und Projekte zu geben.

Einen ausführlichen Rückblick über die Arbeit in den ersten beiden Jahren des FDMlab haben wir schon letztes Jahr geschrieben.

In der “Phase II” unserer Förderzeit haben wir uns mehr auf praktische Aufgaben konzentriert.

KI im Archiv

Das FDMLab wurde dazu eingeladen an den EDV-Tagen 2022 einen Vortrag zum Thema KI im Archiv zu halten. Das Thema beschäftigte uns auch mit dem Aufkommen eines allgemeinen Zugangs zu Large Language Modellen via ChatGPT bei einer Gastvorlesung bei der VU Digitalisierung an der Universität Wien im Wintersemester 2022/2023.

Gerade das Thema Künstliche Intelligenz ist ein Bereich, für den es scheinbar schon viele fertige Lösungen gibt. In der Domäne von archivischem Material liefern diese fertigen Lösungen häufig noch nicht die benötigte Qualität. Umso wichtiger ist ein regelmäßiger Austausch zu funktionierenden und nicht funktionierenden Ansätzen. Bei unserem Vortrag an den EDV-Tagen konnten wir nicht nur über unsere Erfahrungen berichten, sondern darauf aufbauend Feedback, Ideen und weitere Datenservices anderer Projekte kennen lernen.

OpenRefine

Die OpenRefine Workshops wurden mit weiteren Anleitungen versehen. Zum Beispiel, wie man komplexe Datenabgleiche mit Wikidata und den Getty Thesauri durchführen kann. Außerdem wurden weitere Tricks zum Abgleich von Daten zwischen Projekten ergänzt.

Neben der Begleitung von Workshops, führte das FDMLab zusammen mit Verena Mack von der GND-Agentur LEO-BW-Regional einen Normdatenworkshop beim 82. Südwestdeutscher Archivtag durch.

Die Inhalte der OpenRefine Workshops bleiben vorerst mit dem FDMLab Blog online verfügbar. Es gibt jedoch Überlegungen die Workshop Inhalte vom Blog zu entkoppeln und in einem anderen Format anzubieten.

Dokument-, Layout- und Texterkennung

Mit unseren eher durchwachsenen Erfahrungen bei der Layouterkennung von tabellarischen Inhalten in Transkribus, beschäftigten wir uns mit Technologien, die für uns für die Formular- und Tabellenerkennung besser geeignet sein könnten. Außerdem beschäftigte uns nach wie vor die Erkennung von Texten, die aus unterschiedlichen Handschriften bestehen.

Dabei betrachteten wir unter anderem Detectron2 und die Transformer basierte Texterkennung (TrOCR bzw. TrHTR). Da diese Technologien noch 2023 in Transkribus selbst verfügbar sein werden, verzichteten wir auf umfangreichere Experimente.

Unsere Erkenntnisse konnten wir weiterhin bei der Unterstützung und der nun vertieften Zusammenarbeit im Projekt Transformation der Wiedergutmachung anwenden.

Provenienzforschung

In der Phase II kooperierte das FDMLab intensiv mit Katharina Hardt bei der Bearbeitung des Projektes Provenienzforschung im Landesarchiv.

Konkret ging es um eine Aufarbeitung von Metadaten mit Methoden des maschinellen Lernens.

Extraktion von Schlagwörten zu Kunst- und Kulturobjekten

Es sollten automatisiert aus relevanten Akten spezifische Schlagwörter extrahiert werden. Dabei konnten wir zeigen, dass wir mit einem selbst trainierten Modell zum Named-entity Recognition mit überschaubarem Mehraufwand deutlich bessere Ergebnisse erzielen konnten, als mit lexikon- oder regelbasierten Ansätzen. Details zum Vorgehen und dem Diagramm in Abbildung 1 finden sich unter NER Modell mit GND Starthilfe trainieren.

Scatterplot für Precision und Recall für die einzelnen Datensätze.

Massenabgleich mit GND

Die extrahierten Schlagwörter wurden anschließend mit den Daten der Gemeinsamen Normdatei (GND) angereichert. Fehlende Begriffe wurden in Kooperation mit der GND-Agentur LEO-BW-Regional in der GND angelegt.

--- title: Workflow GND config: look: handDrawn theme: neutral --- flowchart LR filtern["Filtern"] ner["NER"] normalisieren["Normalisieren"] gnd_abgleich["GND Abgleich"] gnd_netzwerk["Netzwerk erstellen"] gnd_beantragen["Begriffe Beantragen"] netzwerk_anpassen["Netzwerk anpassen"] import["Importieren"] filtern --> ner --> normalisieren --> gnd_abgleich --> gnd_netzwerk & gnd_beantragen --> netzwerk_anpassen --> import

Neben dem Vorteil, dass Normdaten durch einheitliche Benennung und Identifizierung die Auffindbarkeit erhöhen, konnten wir die Netzwerkstruktur der GND verwenden, um die Schlagwörter durch weitere relevanten Schlagwörter anzureichern. Details zum Vorgehen finden sich im Artikel Named-entity Recognition und Gemeinsame Normdatei zur Verbesserung der Erschließung.

flowchart LR 4175414-1(["Porzellantasse"]):::initial click 4175414-1 href "https://lobid.org/gnd/4175414-1" "4175414-1" _blank 4184488-9["Tasse"] click 4184488-9 href "https://lobid.org/gnd/4184488-9" "4184488-9" _blank 4124863-6["Essgeschirr"] click 4124863-6 href "https://lobid.org/gnd/4124863-6" "4124863-6" _blank 4186181-4["Trinkgefäß"] click 4186181-4 href "https://lobid.org/gnd/4186181-4" "4186181-4" _blank 4140542-0["Geschirr #lt;Hausrat#gt;"] click 4140542-0 href "https://lobid.org/gnd/4140542-0" "4140542-0" _blank 4128003-9["Gefäß"] click 4128003-9 href "https://lobid.org/gnd/4128003-9" "4128003-9" _blank 4132060-8["Hausrat"] click 4132060-8 href "https://lobid.org/gnd/4132060-8" "4132060-8" _blank 4020299-9["Gerät"] click 4020299-9 href "https://lobid.org/gnd/4020299-9" "4020299-9" _blank 4175414-1 --> 4184488-9 4184488-9 --> 4124863-6 4184488-9 --> 4186181-4 4124863-6 --> 4140542-0 4186181-4 --> 4128003-9 4140542-0 --> 4132060-8 4128003-9 --> 4020299-9 classDef default fill:#FFF,stroke:#0088c9,stroke-width:3px,color:#000; classDef category fill:#FFF,stroke:#1fbeb8,stroke-width:3px,color:#000; classDef initial fill:#FFF,stroke:#4dbd05,stroke-width:3px,color:#000;

Schlagwörter Netzwerk

Die Anreicherung mit Oberbegriffen, funktionierte nicht in allen Schlagwortbereichen wie erwartet. Darüber haben wir ausführlich unter GND Hierarchieinformationen zur Verbesserung der Erschließung berichtet. Bei einer erweiterten Analyse der Netzwerkstrukturen der Schlagwörter in der GND konnten wir nicht nur zeigen, dass es sehr viele unverknüpfte Schlagwörter gibt. Wie in Abbildung 2 zu sehen, gibt es viele Strukturen, die nur aus einem Oberbegriff und sehr vielen direkten Unterbegriffen bestehen.

Boxplot zur Darstellung der Verteilung der Anzahl von Kindknoten pro Komponentengröße.

Mit Methoden der Netzwerkanalyse und manuellen Verknüpfungen erarbeiteten wir das in Abbildung 3 annotierte Netzwerk von verknüpften Schlagwörten für relevante Akten für die Provenienzforschung in den Archivabteilungen des Landesarchivs Baden-Württemberg.

Annotierte Visualisierung des Schlagwortnetzwerkes von Prov. relevanten Akten.

NER für Metadaten im Archiv

Neben der Erkennung von spezifischen Objekten experimentierten wir auch mit der Möglichkeit ein allgemeineres Modell für NER zu trainieren.

Hier ein mit einem Standard NER Modell verarbeiteter Beispieltext über das Landesarchiv Baden-Württemberg, welcher von der englischsprachigen Wikipedia angepasst wurde. ¹

The State Archives ORG of Baden-Württemberg ( LABW ORG ) encompasses all state archives in Baden-Württemberg GPE .
The State Archives ORG of Baden-Württemberg is part of the portfolio of the Baden-Württemberg Ministry for Science, Research and Arts FAC .
It keeps historic documents that reach back to the middle ages DATE .
The current President of the State Archives ORG of Baden-Württemberg has been Prof. Dr. Gerald Maier PERSON since February 1st, 2018 DATE .
It employs around 250 CARDINAL people at 8 CARDINAL locations.

Das Model en_core_web_lg hat generell einen f-score von 0,85 und unterscheidet 18 Arten von Entitäten: CARDINAL, DATE, EVENT, FAC, GPE, LANGUAGE, LAW, LOC, MONEY, NORP, ORDINAL, ORG, PERCENT, PERSON, PRODUCT, QUANTITY, TIME und WORK_OF_ART. ²

Eine ähnliche Auswahl an Entitätenklassen und Qualität wäre natürlich auch für unsere Daten im Archiv wünschenswert. Daher haben wir zusätzliche Experimente mit dem Training eines spezifischen NER Modells mit den folgenden Klassen durchgeführt:

PER: Person - Personen und fiktive Personen wie z.B. Künstlernamen
ORG: Organization - Firmen, Behörden, Institutionen, Vereine, …
FAC: Facility - Gebäude, Flughäfen, Straßen, Brücken, …
GPE: Geopolitical Entities - Länder, Bundesländer, Landkreise, Städte
LOC: Location - Non-GPE Locations - Berge, Landschaftsgebiete, Flüsse, Seen, …
EVENT: Benannte Events - Weltmeisterschaften, Zweiter Weltkrieg, …

Mit dem auf Transformern basierten Modell von spaCy konnten wir auf unseren Testdaten die in der folgenden Tabelle gelisteten Werte erzielen:

Label	Precision	Recall	F1-Score
GPE	96,10	97,14	96,62
PER	96,45	96,62	96,54
FAC	95,11	94,40	94,76
ORG	91,72	89,78	90,74
LOC	90,48	89,76	90,12
EVENT	94,41	90,00	92,15

Das Modell hat für die Klassen EVENT, FAC und LOC jedoch zu wenig Beispiele in den Trainings- und Testdaten, um verlässliche Aussagen zu treffen. Auch sind die Metadaten für die für die Provenienzforschung relevanten Akten sehr spezifisch, so dass das Modell für die Anwendbarkeit auf anderen Beständen ein Nachtraining erfordert.

Im Vergleich zum Training des spezifischen NER Modells für die Erkennung von Kunst- und Kulturobjekten war das Training deutlich aufwendiger. Wir gehen jedoch davon aus, die Trainingsdaten in anderen Projekten ergänzen zu können und so Schritt für Schritt zu einem generischen Modell für unsere Daten zu kommen.

Da etwas mehr als die Hälfte der für die Provenienzforschung relevanten Akten noch einer Sperrfrist unterliegen, können wir weder die Trainings- bzw. Testdaten noch das Modell veröffentlichen.

SpanCat für Personendaten

Ein komplexerer Fall stellt die Erkennung von semi-strukturierten Pesonendaten in den Akten und Metadaten unserer Aktenbestände dar. Hier hatten wir Probleme mit klassischen NER Ansätzen, da wir teilweise sehr lange Entitäten haben, die sich auch überlappen können.

Hier experimentierten wir mit SpanCat und konnten initial recht gute Ergebnisse erzielen.

Erkennung von strukturierten Personendaten mit SpanCat.

Es stellte sich jedoch heraus, dass wir im Vergleich zu unserem oben beschriebenen NER Modell deutlich mehr und diversere Trainingsdaten benötigen. Besonders das Trainieren von proportional unterrepräsentierten Features, wie zum Beispiel Berufsangaben, Titel und Aliasen, stellte sich als problematisch heraus. Als Zwischenlösung trainierten wir für diese Features separate Modelle und fassten sie mit dem ursprünglichen SpanCat Modell in einer Pipeline zusammen. Dies stellte sich als komplizierter raus, als ursprünglich erwartet. ³

--- title: Pipeline für Personendaten config: look: handDrawn theme: neutral --- flowchart LR text["Text"] ---> spancat1 custom_component --> entities["Entities"] subgraph pipeline["Pipeline"] direction LR spancat1["SpanCat1"] --> spancat2["SpanCat2"] spancat2 --> custom_component subgraph custom_component["Custom Component"] sc end end subgraph pipeline_spancat1["Pipeline SpanCat1"] subgraph component_spancat1["Spancat1"] direction LR spancat1_tok2vec["Tok2Vec"] sc_spancat1 end end subgraph pipeline_spancat2["Pipeline SpanCat2"] subgraph component_spancat2["Spancat2"] direction LR spancat2_tok2vec["Tok2Vec"] sc_spancat2 end end sc_spancat1 -.merge-.-> sc sc_spancat2 -.merge-.-> sc component_spancat1 -.source-.-> spancat1 component_spancat2 -.source-.-> spancat2

Insgesamt ist der Ansatz jedoch sehr vielversprechend und wir hätten gerne mehr Zeit gehabt, ausführlicher über unsere Ansätze zu berichten und sie weiter zu vertiefen.

Hierzu standen wir auch im fachlichen Austausch mit dem Provenance Lab an der Leuphana, die in Hidden Value: Provenance as a Source for Economic and Social History die Umsetzung einer ähnlichen Anwendung von SpanCat beschreiben.

Weitere Datenprojekte

Reichskammergericht

--- title: Workflow Reichskammergericht 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

Wir hatten schon in Phase I über die Retrodigitalisierung von analogen Findbüchern berichtet. Unter anderem haben wir exemplarisch einen Findbuch Index mit OpenRefine aufbereitet.

Für Findbücher zu den Akten des Reichskammergerichts⁴ haben wir nun die Personen- und Orts-Indizes ebenfalls in Tabellenform überführt und mit Normdaten der Gemeinsamen Normdatei abgeglichen.

Neben weiteren Erfahrungen mit dem Massenabgleich von Daten über die OpenRefine Schnittstell der lobid-gnd, konnten wir dabei zusammen mit Verena Mack von der GND-Agentur LEO-BW-Regional einige Dubletten identifizieren und fehlende Einträge ergänzen.

Digitalisierung von Heimlisten

Für das Projekt Aufarbeitung von Heimerziehung und Zwangsunterbringungen wurden ursprünglich analog vorliegende Adresslisten von Heimen digitalisiert, tabellarisch aufbereitet und die Ortsangaben mit Normdaten, sowie Geokoordinaten versehen.

Abgleich von Findbüchern mit Dateistrukturen

Im AV Archiv im Hauptstaatsarchiv Stuttgart werden digitale Medien erfasst und archiviert. Das FDMLab unterstützte das AV Archiv bei einer Analyse der vorliegenden Dateistruktur und einem Abgleich mit den zugehörigen Findmitteln.

Verlinkung der Tomi Actorum

Bei der Digitalisierung der Verhandlungsprotokolle der württembergischen Landstände wurden im Hauptstaatsarchiv Stuttgart Protokolle digitalisiert und die Sachregister zusätzlich transkribiert. Es konnte in dem Online Findmittelsystem jedoch keine direkte Verbindung zwischen einem Eintrag im Sachregister zu dem zugehörigen Digitalisat des Protokolleintrags genutzt werden. Das FDMLab unterstützte das Projekt, indem etwa 50.000 Verlinkungen von Sachregistereinträgen zu den zurgehörigen Protokolleinträgen mit der Unterstützung von Methoden der Mustererkennung automatisch vorgenommen wurde.

Veröffentlichung von Forschungsdaten

Das FDMLab unterstützte das Staatsarchiv Wertheim bei der Veröffentlichung einer Forschungsdatenbank auf Radar4Culture. Dazu gehörte die Auswahl eines geeigneten Forschungsdatenrepositoriums, die Konvertierung in ein geeignetes Veröffentlichungsformat, sowie Hinweise zur Datenbeschreibung, Lizenzierung und Anreicherung mit Normdaten.

Schluss ⛔

In den drei Jahren FDMLab@LABW konnten wir viele Projekte bei der Umsetzung von Digitalisierungsaufgaben unterstützen. Dabei versuchten wir neue Wege zu gehen und dabei nachvollziehbare Beschreibungen unserer Wanderungen zu hinterlassen.

Ohne die fachliche Zusammenarbeit mit Kolleginnen und Kollegen hätte das FDMLab nicht funktionieren können. Vielen Dank an alle, die sich mit Fragen, Beiträgen und fachlicher Unterstützung an den Projekten des FDMLabs beteiligt haben.

Finanziert wurde das FDMLab@LABW aus Mitteln der Zukunftsoffensive III durch das Ministerium für Wissenschaft, Forschung und Kunst Baden-Württemberg.

Nach drei Jahren endet die Förderung und wir schließen das FDMLab@LABW.

Die Inhalte des FDMLab Blogs werden wir vorläufig in einer statischen Form weiter vorhalten.

Wikipedia Autoren, „Landesarchiv Baden-Württemberg“, Wikipedia – Die freie Enzyklopädie, https://de.wikipedia.org/w/index.php?title=Landesarchiv_Baden-W%C3%BCrttemberg&oldid=223510351 (aufgerufen am 20. Juli 2022). ↩︎
NER erstellt mit spaCy 3.3 en_core_web_lg. ↩︎
Siehe auch https://github.com/explosion/spaCy/discussions/12462 ↩︎
Akten des Reichskammergerichts im Hauptstaatsarchiv Stuttgart: Inventar des Bestands C. Bearb. von A. Brunotte, R.J. Weber, Veröffentlichungen der Staatlichen Archivverwaltung Baden-Württemberg, Band 46 Nr.1-8, Stuttgart 1993-2008. Außerdem: Akten des Reichskammergerichts im Staatsarchiv Sigmaringen: Inventar des Bestands R 7. Bearb. von R.J. Weber, Veröffentlichungen der Staatlichen Archivverwaltung Baden-Württemberg; Band 57, Stuttgart 2004. ↩︎

EDV-Tage 2022

Thu, 29 Sep 2022 13:45:00 +0000

Ein Rückblick auf zwei Jahre FDMLab

Tue, 26 Jul 2022 00:00:00 +0000

Nach zwei Jahren steht das FDMLab@LABW kurz vor dem Ende der ersten Projektlaufzeit. Dies nehmen wir zum Anlass, zurückzublicken und eine Zwischenbilanz zu ziehen: Was waren unsere wichtigsten Projekte? Was haben wir erreicht und was war schwierig? Was würden wir in Zukunft gerne tun?

Formung des Projektteams und Einarbeitung

Das FDMLab hat den Auftrag, am Landesarchiv Baden-Württemberg eine Basisinfrastruktur im Bereich E-Science und Forschungsdatenmanagement (FDM) aufzubauen, welche einen Beitrag zur NFDI leistet. Das zentrale Ziel ist dabei stets, die Auffindbarkeit, Zugänglichkeit und Nutzbarkeit unseres Archivguts zu erhöhen und die Nutzungsmöglichkeiten an einer zunehmend digitalen Forschungspraxis auszurichten. Dazu haben wir bereits vorhandene Konzepte und Technologien aus dem Data Science und KI-Bereich für den Einsatz im Landesarchiv evaluiert, einige geeignete Instrumente (ggf. mit Anpassungen) testweise implementiert und uns aktiv in die GLAM-Labs-Community eingebracht, um die Bedarfe der Archive zu kommunizieren und Impulse für die Weiterentwicklung relevanter Werkzeuge zu liefern.

Um diese Aufgaben anzugehen, braucht es einerseits das Verständnis archivischer Quellen und der Arbeitsprozesse rund um die Erschließung, Digitalisierung und Bereitstellung im Archiv. Andererseits sind umfangreiche Kenntnisse in den Bereichen Data Science und Maschinelles Lernen wichtig. Das Kernteam unseres Projekts besteht aus einer Archivarin und einem Data Scientist. Diese Kombination von Expertisen ist für das FDMLab ein wichtiger Erfolgsfaktor. Besonders die Anfangszeit des Projekts war geprägt von einem Kommunikationsprozess, in dessen Verlauf das Projektteam zu einer gemeinsamen Sprache fand und viel aus der Denkweise der Teammitglieder lernte. Hierbei gab es auch immer wieder wertvollen Input von zahlreichen Kolleginnen und Kollegen aus ganz unterschiedlichen Abteilungen des Landesarchivs.

Das FDMLab war von vornherein als experimentelles Forschungsprojekt geplant. Daher entschieden wir uns für ein iteratives Vorgehen. Anstatt einen starren Projektplan zu entwerfen, bearbeiteten wir verschiedene inhaltlich stark verzahnte Themenfelder parallel. Dies hatte den Vorteil, dass wir auf Erfolge und Rückschläge bei Experimenten flexibel reagieren konnten. Auch konnte das FDMLab immer wieder kurzfristig Hilfe leisten, wenn andere Projekte oder Abteilungen des Landesarchivs eine Frage zur Datenaufbereitung stellten. Dadurch konnten wir unsere Arbeitsweise und unseren Fokus auf die direkten Bedürfnisse unserer Kolleginnen und Kollegen anpassen.

Volltextgenerierung

Die Volltexterkennung bildete einen der thematischen Schwerpunkte der vergangenen Projektlaufzeit. Das FDMLab hat verschiedene OCR- und HTR-Werkzeuge für die Erkennung von Text in digitalisiertem Archivgut getestet.¹ Als Testmaterial dienten hierbei die digitalisierten Kriegs- und Friedensstammrollen aus dem Hauptstaatsarchiv Stuttgart (Bestände LABW HStA M 430/1 – M 631) und dem Generallandesarchiv Karlsruhe (Beständegruppe XIV. (Badisches) Armeekorps) und die ebenfalls digitalisierten Kriegsgräberlisten aus der Abteilung Staatsarchiv Ludwigsburg (Bestand LABW StAL EL 20/1 VI). Diese Bestände weisen einige Merkmale auf, die für einen größeren Teil des jüngeren Archivguts im Landesarchiv Baden-Württemberg charakteristisch sind: ein komplexes tabellarisches Layout, sowie eine Mischung aus Handschrift, Druckschrift und Schreibmaschinenschrift, wie in Abbildung 1 gezeigt.²

Beispiel für Mischung aus Druck- und Maschinenschrift [2].

Anhand dieser Testbestände konnten wir wertvolle Erfahrungen mit dem Aufbau geeigneter Workflows für die Volltexterkennung sammeln. Für gedruckte Archivalien des Landesarchivs eignen sich vor allem die Werkzeuge von OCR-D und OCR4All.

--- title: OCR Tools config: look: handDrawn theme: neutral --- flowchart LR subgraph ocr[fas:fa-font OCR-Tools] OCRopus --> Kraken --> Calamari OCRopus --> Calamari OCRopus -.-> Tesseract Qurator end subgraph gui[far:fa-window-maximize GUI-Tools] Calamari --> OCR4All Kraken --> eScriptorium Tesseract --> tesseractXplore end subgraph cli[fas:fa-terminal CLI-Tools] ocr-d Calamari & Qurator --> origami end ocr --> ocr-d

Bei handschriftlichem Archivgut hat sich die Software Transkribus bewährt. Eine “One fits all”-Lösung für alle Bestände des Landesarchivs kann es dabei nicht geben, was wir bereits zu Projektbeginn auch vermutet hatten. Unser Archivgut aus verschiedenen Jahrhunderten ist sowohl im Schriftbild als auch im Layout sehr heterogen. Daher müssen für unterschiedliche Bestände jeweils eigene Workflows aufgebaut und die Parameter der Erkennungssoftware darauf angepasst werden.

Bildschirmfoto der Oberfläche von Transkribus.

Um komplexere Layouts wie das der militärischen Stammrollen zu verarbeiten, führt nach dem aktuellen Stand der Technik außerdem kein Weg daran vorbei, eigene Erkennungsmodelle zur Layouterkennung zu trainieren. Transkribus besitzt zwar auch eine eingebaute Layouterkennung. Diese kann mit Tabellen und Formularen jedoch nicht ohne Weiteres umgehen. Um ein eigenes Modell zu trainieren, muss man zunächst umfangreiche Ground Truth-Daten manuell erstellen, die dem Algorithmus der Texterkennungssoftware als “Übungsbeispiele” dienen können. Hierfür sind erhebliche Personal- und Zeitressourcen notwendig. Auch nach Abschluss eines Modelltrainings fällt weiterhin eine intellektuelle Nachbearbeitung der automatisch generierten Volltexte an, soweit das Ergebnis noch nicht den Qualitätsansprüchen genügt.

Die Bewertung von Ergebnissen einer Volltexterfassung von unserem Archivmaterial gestaltete sich zunächst aufwendiger als gedacht. Die Standardmetrik Character Error Rate (CER) berücksichtigt auch das Layout, was in den meisten Fällen auch Sinn ergibt. Im Falle von tabellarischen Inhalten, kann jedoch schon eine Abweichung der Lesart (zeilenweise vs. spaltenweise) zu sehr schlechten Bewertungen bei eigentlich guten OCR-Ergebnissen führen. In der folgenden Tabelle ist ein Beispiel mit neun Zahlen, wo nur auf Grund der unterschiedlichen Lesart eine Fehlerrate von über 66 Prozent erzeugt wird.

1	2	3	-	Lesart	Reihenfolge
4	5	6	-	zeilenweise	1 2 3 4 5 6 7 8 9
7	8	9	-	spaltenweise	1 4 7 3 5 8 3 6 9

Daher haben wir uns mit alternativen Metriken zur Bewertung von OCR-Ergebnissen beschäftigt und für uns die Flexible Character Accuracy entdeckt.³ Diese ist zwar weitaus aufwendiger zu berechnen, lässt sich dafür aber von Abweichungen von der Lesart eines Formates nicht so stark beeinflussen.

Als hilfreich beim Aufbau von speziellen Workflows zur OCR-Erkennung hat sich das Projekt OCR-D erwiesen, mit dem sich verschiedenste Open-Source-Anwendungen aus dem Texterkennungsbereich über eine einheitliche Schnittstelle bedienen lassen. So können zum Beispiel unterschiedliche Werkzeuge zur Layoutbestimmung und Zeichenerkennung miteinander kombiniert und mit eigenen Modulen, ergänzt werden. Als Oberfläche zur Erstellung von so genannten Ground Truth Daten haben wir uns zu Beginn unseres Projektes für OCR4All entschieden, welches in Phase III auch ein Teil des OCR-D Projektes wurde.

--- title: OCR Prozess config: look: handDrawn theme: neutral --- flowchart LR original[fas:fa-archive Original] scan(fas:fa-camera Scannen) subgraph manual[fas:fa-hand-paper semi-manuell] preprocessing_m(fas:fa-file-image Vorverarbeitung) layout_m(fas:fa-draw-polygon Layout-Seg.) lines_m(fas:fa-align-justify Zeilen-Seg.) transcription(fas:fa-pencil-alt Transkription) end subgraph engine[fas:fa-magic automatisch] preprocessing[fas:fa-file-image Vorverarbeitung] layout(fas:fa-draw-polygon Layout-Seg.) lines(fas:fa-align-justify Zeilen-Seg.) ocr(fas:fa-font OCR) end quality(fas:fa-search Qualitätskontrolle) text[fas:fa-file-word Text] original --> scan scan --> preprocessing & preprocessing_m preprocessing_m --> layout_m --> lines_m --> transcription --> quality preprocessing --> layout --> lines --> ocr --> quality quality --> text

Neben der vollständigen Digitalisierung von analogem Material, sind wir manchmal auch an Teildigitalisierungen interessiert. Beispielsweise werden bei der Digitalisierung von Findmitteln oder Übergabelisten nicht alle analogen Inhalte in der digitalen Version benötigt. Für diesen Zweck haben wir mit dem Einsatz von Scanstiften experimentiert. Diese sind ähnlich groß wie Textmarker und können einzelne Wörter, Phrasen oder Zeilen scannen, OCR erfassen und z.B. direkt in das zugehörige Formularfeld einer Erfassungssoftware übertragen. Es benötigt etwas Eingewöhnung, bis man den richtigen Winkel und die richtige Geschwindigkeit zur Bedienung herausgefunden hat. Bei richtiger Bedienung funktionieren die Scanstifte für moderne Drucke ähnlich gut wie kommerzielle Software für die OCR-Erfassung (die unter der Haube teilweise auch eingesetzt wird). Es gibt jedoch keine direkte und für technische Laien verständliche Möglichkeit die Scanstifte für die Erfassung behördlicher Schreibmaschinenschrift, Handschriften oder historischer Drucke anzupassen.⁴

Neben der Erfassung von Volltexten beschäftigten wir uns auch mit verschiedenen Möglichkeiten der Darstellung von Volltexten in Webanwendungen. Dafür setzten wir die Anzeige von Volltexten für den Bestand Abschiedsrede von Anton Geiß, GLAK N Geiss Nr. 6 in einem Prototyp für verschiedene Möglichkeiten wie hOCR und den DFG-Viewer um und testeten die Bedienung der verschiedenen Anzeigevarianten, wobei der Fokus auf der Benutzung und nicht der Qualität des Volltextes bzw. des Designs lag (siehe Abbildungen 3 und 4).

Bildschirmfoto der Übersicht unseres Prototypen zur Darstellung von Volltexten.

Bildschirmfoto der Detailsansicht unseres Prototypen zur Darstellung von Volltexten mit hOCR.

Datenanalyse und -anreicherung

Eine Aufgabe im Archiv ist die Retrodigitalisierung, also die zur Verfügungstellung analog vorliegender Daten in digitaler Form für die wissenschaftliche Nutzung. Dies ermöglicht in der Regel nicht nur einen einfacheren Zugang zu den Daten, sondern unterstützt zusätzlich auch die Bestandserhaltung. Neben der (Retro)Digitalisierung von Archivalien gehört hier auch die Digitalisierung der entsprechenden Metadaten, also der Findmittel dazu, aber auch die Umwandlung von schon digital vorliegenden Daten in strukturierte Formate oder semantisch beschriebene Datensätze.

Eines unserer ersten Projekte im FDMLab war die Überführung des gedruckten Findbuches “Fürstlich Thurn und Taxissches Archiv Obermarchtal Grafschaft Friedberg-Scheer" in unser archivisches Fachinformationssystem (AFIS).⁵ Hierbei konnten wir schnell feststellen, dass vermeintlich durchstrukturierte Findbücher in vielen Punkten minimal vom vermeintlich einheitlichen Schema abweichen, sodass eine komplett automatische Einsortierung der einzelnen Textbestandteile in die entsprechenden Formularfelder nicht sinnvoll ist.

--- title: Prozess Datenextraktion config: look: handDrawn theme: neutral --- flowchart LR text[fas:fa-file-word Text] corr(Korrekturen) subgraph entries[fas:fa-address-card Einträge] extraction(Extraktion) line_breaks(Zeilenumbrüche) structure(Strukturerkennung) conversion(Mapping) end subgraph index[fas:fa-address-book Index] extraction_i(Extraktion) classification(Klassifizierung) person[fas:fa-user Personen] place[fas:fa-map-marker Orte] extend(Anreicherung) end combine(Zusammenführen) afis[(AFIS)] db[(Externe DBs)] text --> corr --> extraction & extraction_i extraction --> line_breaks --> structure --> conversion --> combine extraction_i --> classification --> person & place --> extend --> combine --Import--> afis db --> extend

Bei unserem Folgeprojekt, der (Retro)Digitalisierung der Findbücher zu den Reichskammergerichtsakten, haben wir daher OpenRefine eingesetzt. Das hat den Vorteil, dass wir einerseits automatisch strukturierte Daten in Massenbearbeitungen aus dem Text extrahieren können, andererseits die problematischen Abweichungen schnell identifizieren und separat behandeln können.⁶

1 1 Nr ( C 2145 Altsignatur ) 1597 – 1600 Laufzeit
Vorsignatur: R Rep. 9 Nr. 230 Vorsignatur

Strukturbeispiel (Abschnitt 1) für Findbuch zu Akten des Reichskammergerichts.

OpenRefine hat uns dabei so gefallen und wir haben so positiv davon berichtet, dass wir von mehreren Kolleginnen und Kollegen gebeten wurden dazu doch einen internen OpenRefine Einsteigerworkshop anzubieten. Dieser wurde wiederum so positiv aufgenommen, dass wir den OpenRefine Einsteigerworkshop inzwischen schon viermal durchgeführt haben und darauf aufbauend einen OpenRefine Fortgeschrittenenworkshop erstellt und ebenfalls bereits zweimal durchgeführt haben. Die zugehörigen Materialien und Anleitungen haben wir zusätzlich für unseren Blog aufbereitet und dort zur Verfügung gestellt.

Link zum Einsteiger Workshop für OpenRefine

Die Resonanz aus dem deutschsprachigen GLAM-Bereich (Galerien, Bibliotheken (Libraries), Archive und Museen) zu OpenRefine ist bisher recht positiv und uns erreichen aus dem deutschsprachigen Raum auch immer mal wieder Anfragen zu konkreten Problemen oder Projekten, bei denen wir im Rahmen unserer Möglichkeiten gerne weiterhelfen.

Link zum Fortgeschrittenen Workshop für OpenRefine

Ein weiteres Daten-Projekt, welches wir im FDMLab technisch begleiten durften, ist das Themenmodul Gurs im Landeskundlichen Informationssystem Baden-Württemberg (LEO-BW). Konkret wurde hier mit OpenRefine eine von mehreren Kolleginnen und Kollegen zusammengetragene Excel-Datei inhaltlich und strukturell vereinheitlicht und für die Veröffentlichung als Datenbank im XML-Format aufbereitet. Dazu gehörte auch die Einbindung von Bildern, die Anreicherung von Orten mit Normdaten und Geokoordinaten sowie die Recherche und Normdatenerstellung in Kooperation mit Verena Mack von der GND-Agentur LEO-BW-Regional.

Bildschirmfoto der Kartenansicht des Themenmodul Gurs in LEO-BW.

Ähnlich wurde vom FDMLab das Projekt Winterberg-Tunnel auf LEO-BW unterstützt.⁷ Wobei hier der Fokus auf der Restrukturierung der Personendaten lag, damit diese auf LEO-BW als Datenbank angeboten werden können, sowie die Ergänzung und Erstellung von Normdaten für Orte wiederum in Kooperation mit Verena Mack.

Bei unserer Arbeit mit Normdaten zu Orten in Baden-Württemberg in der Gemeinsamen Normdatei (GND) stolperten wir hin und wieder über Dubletten. Gemeinsam mit Verena Mack führten wir ein Experiment mit SPARQL auf einem Apache Jena Triple Store durch, um solche Orte zu identifizieren und eine Bereinigung der Daten beauftragen zu können. Dabei konnten wir circa 600 eindeutige Dubletten bei 33.000 Ortsdatensätzen für Baden-Württemberg identifizieren. Details dazu unter unserem Bericht zum Experiment zur Identifikation von doppelten Orten in der GND.

Weitere Erfahrungen bei der Arbeit mit Normdaten konnten wir bei der Unterstützung der Aufbereitung des Bestandes StAL EL 68 IX Landesvermessungsamt Baden-Württemberg: Landesbefliegung Baden-Württemberg 1968 - Luftbilder und digitales Orthophoto sammeln. Hier wurden 21.132 Datensätze mit 19.569 digitalisierten Luftbildern und 30.000 georeferenzierten Orthofotokacheln automatisiert mit insgesamt 195.988 teils neuen, normierten Ortsdeskriptoren verknüpft. Siehe dazu auch Luftbilder aus der Sammlung des Landesvermessungsamts Baden-Württemberg online.

Auch die Überführung in neuere Datenformate gehört zu unseren Aufgaben im Archiv. Zum Beispiel liegen die Daten der Volkszählung 1961 (Bestand StAL EL 413/4) seit 2005 in Form von Textdateien im Staatsarchiv Ludwigsburg. Dort wurden sie als alternative Repräsentation in CSV mit ergänzenden XML-Metadaten gespeichert. Zur besseren Zugänglichkeit wurden die Daten im FDMLab zusätzlich in eine SQLite-Datenbank überführt, wobei eine Verknüpfung der Daten in den CSV-Dateien mit den XML-Metadaten vorgenommen wurde. Dadurch erhoffen wir uns eine bessere Nutzbarkeit durch Forschende.

Die Unterstützung bei der Aufbereitung von Metadaten für die Datenweitergabe an Portale, die Daten zu einem bestimmten Thema aggregieren, gehört ebenfalls zu den Routineaufgaben des FDMLab. Eine Anforderung solcher Portale ist häufig die Ergänzung von Geodaten, um die einzelnen Bestände auf einer Karte visualisieren zu können. Hierfür vervollständigen wir im FDMLab Bestände des Landesarchivs mit Ortsnormdaten und ergänzen die Metadaten für die Weitergabe mit für das Zielsystem passenden Geokoordinaten.

Weitere Kooperationen bei der Datenverarbeitung gab es mit der Fachstelle Archiv des DDB-Teams bei der Aufbereitung und der Automatisierung des Imports von Archivdaten in das Archivportal-D.

Neben Erfolgsgeschichten hatten wir auch Projekte, die wir von Beginn an abgelehnt, verworfen oder nach kurzer Evaluation abgebrochen haben. Hier ein Projekt, welches erst nach einer mehrtätigen Evaluationsphase verworfen wurde. Das Ziel des Projektes war es, über einen Dublettenabgleich zwischen zwei digital vorliegenden Findbüchern mit insgesamt etwa 64.000 verzeichneten Personenakten, Dubletten über im Titel genannte Personendaten automatisch zu identifizieren. Auf den ersten Blick schien das direkt umsetzbar. Es stellte sich jedoch heraus, dass die 30 unterschiedlichen Informationsbestandteile zu Personen- und Ortsdaten von Orten weltweit, in unterschiedlicher Tiefe und Reihenfolge erfasst waren. Der Dublettenabgleich konnte in der erforderlichen Qualität also nicht vollautomatisch durchgeführt werden. Eine Evaluation basierend auf Vor- und Nachnamen ergab, dass der Anteil an (möglichen) Dubletten höchstens bei 10 Prozent lag und damit weitaus geringer war als erwartet, jedoch zu groß um eine manuelle Prüfung durchzuführen. Im Nachhinein wäre es sinnvoller gewesen, die Prüfung auf mögliche Dubletten zuerst durchzuführen und sich dadurch die langwierige Arbeit mit den vielen Informationsbestandteilen zu den einzelnen Personen zu sparen.

FAIR-Prinzipien für die Datenbereitstellung

Das FDMLab arbeitete nicht nur an der Generierung und Analyse von Daten, sondern evaluierte auch die bisherige Praxis des Landesarchivs bei der Datenbereitstellung über das Online-Findmittelsystem (OLF). Richtschnur waren dabei die sogenannten FAIR-Prinzipien für die Datenbereitstellung, die in der Forschungsdatenmanagementcommunity inzwischen eine weite Verbreitung gefunden haben. Die Abkürzung “FAIR” setzt sich zusammen aus den englischen Adjektiven findable (auffindbar), accessible (zugänglich), interoperable (interoperabel) und reusable (nachnutzbar). Diese Eigenschaften sollten Daten bzw. die Datenbereitstellung besitzen, um eine nachhaltige (wissenschaftliche) Nutzung zu gewährleisten.⁸

Die FAIR Leitprinzipien für Daten [8].

Die Untersuchung ergab, dass das Online-Findmittelsystem einige der 15 FAIR-Kriterien bereits erfüllt, sie jedoch noch nicht in vollem Umfang umsetzt. Bei der anstehenden Neuentwicklung eines archivischen Fachinformationssystems, welches künftig auch das jetzige Online-Findmittelsystem ablösen wird, sollen die FAIR-Prinzipien vollständig berücksichtigt werden. Das FDMLab lieferte hier Impulse für die Definition von Anforderungen an das neue AFIS. Die Präsentationskomponente des neuen AFIS soll archivische Daten unter transparenten und leicht verständlichen Nutzungsbedingungen bereitstellen – und dies so offen wie möglich. Dabei gilt es selbstverständlich auf der anderen Seite auch, den Datenschutz, das Urheberrecht und andere Schutzrechte zu wahren.

Eine der bei der Evaluation definierten Anforderungen ist die Einführung eines global eindeutigen Persistent Identifiers (PID), der sowohl die Daten als auch die Metadaten des Landesarchivs weltweit und zeitlich unbegrenzt kennzeichnet und somit eine sichere Zitation ermöglicht.

Die rechtlichen Nutzungsbedingungen sollen über die derzeitige zentrale Infoseite auf der Homepage des Landesarchivs hinaus auch auf den Detailseiten der einzelnen digitalen Objekte verlinkt werden. Dadurch soll es noch einfacher werden, sich über Lizenzen etc. zu informieren.⁹

Außerdem soll das neue AFIS eine frei zugängliche Schnittstelle besitzen, über die Daten in einem maschinenlesbaren Format und in flexiblem Umfang (einzelne Digitalisate oder Batch-Verarbeitung) zum Download bereitstehen. Dies wäre dann eine ergänzende Möglichkeit zum Download, zusätzlich zu den bereits heute verfügbaren Downloadmöglichkeiten über die DDB bzw. das Archivportal-D.

Weiter wurden die Voraussetzungen zur Verwendung eines IIIF-kompatiblen Viewers untersucht. Um Metadaten auch in einem semantischen Datenmodell anzubieten, soll im neuen AFIS der neue archivische Erschließungsstandard Records in Context (RiC) des International Council on Archives (ICA) genutzt werden.

Konferenzen und Veranstaltungen

Neben unserer praktischen Tätigkeit waren wir als FDMLab auch auf einigen Veranstaltungen, wie dem Südwestdeutschen Archivtag und der Konferenz “Offene Archive” sowohl als Teilnehmende, als auch zur fachlichen und technischen Unterstützung oder als Vortragende aktiv. Eine Liste von Vorträgen und Präsentationen des FDMLab haben wir auf unserer Webseite unter dem Menüpunkt Vorträge veröffentlicht.

Im Bereich Forschungsdatenmanagement waren wir während unserer ersten Projektlaufzeit eher in der Orientierungs- und Planungsphase und haben die tatsächliche Implementierung und Umsetzung in Form von Vorarbeiten an andere Projekte innerhalb des Landesarchives weitergegeben.

Eine abwechslungsreiche Ausnahme unserer Tätigkeiten war die Unterstützung von Datenberaterinnen und Datenberatern für Archive in Baden-Württemberg für den Kultur-Hackathon Coding da Vinci Baden-Württemberg 2022.

Ausblick

Das FDMLab hat sich in seiner ersten Projektlaufzeit mit verschiedenen Themen beschäftigt, die für Archive noch weitestgehend Neuland sind. Bei der automatischen Erstellung von Volltexten und der Datenanalyse und –anreicherung mit Hilfe verschiedener Tools und Technologien konnte wertvolles Wissen und bei vielen praktischen Projekten Erfahrungen gesammelt werden. Dennoch bleibt auch weiterhin viel zu tun: Ergebnisse aus Experimenten und Prototypen sollen in den Produktivbetrieb überführt werden, Volltexte und angereicherte Metadaten in größerem Umfang generiert werden. Und so freuen wir uns außerordentlich, dass das Projekt FDMLab@LABW nach der ersten Projektlaufzeit verlängert wird und wir mit der Unterstützung des Ministeriums für Wissenschaft, Forschung und Kunst Baden-Württemberg ein weiteres Jahr von August 2022 bis Juli 2023 das Thema Maschinelles Lernen im Archiv vorantreiben dürfen.

Eine Übersicht über die im FDMLab getesteten Tools finden Sie unter Werkzeuge zur Texterkennung: ein Blick in die digitale Werkstatt des FDMLab am Landesarchiv Baden-Württemberg und unter OCR im Archiv – ein Blick in das FDMLab@LABW. ↩︎
GLAK 465 c Nr. 418, NS Überlieferung in staatlichen Archiven. ↩︎
C. Clausner, S. Pletschacher, A. Antonacopoulos , “Flexible character accuracy measure for reading-order-independent evaluation”, Pattern Recognition Letters, Volume 131, March 2020, Pages 390-397, https://doi.org/10.1016/j.patrec.2020.02.003 ↩︎
Theoretisch ist es möglich die vom Scanstift gescannten Bilder in einen Zielordner zu speichern und dann automatisiert zum Beispiel mit einem OCR-D Workflow weiter zu verarbeiten. Das setzt jedoch ein recht tieferes technisches Grundverständnis voraus. ↩︎
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. ↩︎
Akten des Reichskammergerichts im Hauptstaatsarchiv Stuttgart: Inventar des Bestands C. Bearb. von A. Brunotte, R.J. Weber, Veröffentlichungen der Staatlichen Archivverwaltung Baden-Württemberg, Band 46 Nr.1-8, Stuttgart 1993-2008. Außerdem: Akten des Reichskammergerichts im Staatsarchiv Sigmaringen: Inventar des Bestands R 7. Bearb. von R.J. Weber, Veröffentlichungen der Staatlichen Archivverwaltung Baden-Württemberg; Band 57, Stuttgart 2004. ↩︎
Bestände GLAK 456 C Nr. 2656-2661, GLAK 456 C Nr. 2664 und GLAK 456 D Nr. 226-228 ↩︎
“FAIR data principles” von SangyaPundir ist lizenziert unter einer CC BY-SA 4.0 Lizenz. ↩︎
Die Metadaten des Landesarchivs stehen unter der Creative Commons-Lizenz CC0. Die Digitalisate werden, wenn dem aus rechtlicher Sicht nichts entgegensteht und sie nicht sowieso gemeinfrei sind, unter der Creative Commons-Lizenz CC-BY weitergegeben. Siehe dazu die Nutzungsbedingungen auf einen Blick. ↩︎

Konferenz "Offene Archive" 2022

Mon, 13 Jun 2022 16:00:00 +0000

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

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

Gemeinsam an OpenRefine-Projekten arbeiten

Tue, 07 Dec 2021 00:00:00 +0000

Im FDMLab testeten wir verschiedene Möglichkeiten mit OpenRefine gemeinsam an Projekten zu arbeiten. Dieser Artikel fasst unsere Erfahrungen beim kollaborativen Arbeiten mit OpenRefine 3.5.0 zusammen.

Wir hatten in Fünf Dinge, die wir an OpenRefine mögen schon darüber berichtet, dass uns die Architektur von OpenRefine gefällt, da sie es ermöglicht OpenRefine sowohl auf einem Client (Laptop, Rechner), als auch auf einem Server laufen zu lassen. Die Bedienung erfolgt anschließend über den Browser.

--- title: OpenRefine Setup config: look: handDrawn theme: neutral --- flowchart LR subgraph server[fas:fa-server Server] server_or[fas:fa-gem OpenRefine] end subgraph laptop[fas:fa-laptop Laptop] browser[far:fa-window-maximize Browser] laptop_or[fas:fa-gem OpenRefine] end browser -.-> laptop_or & server_or

Da läge es nahe, dass OpenRefine auch eine Benutzerverwaltung und eine Möglichkeit zum Kollaborativen Arbeiten an Projekten anbietet. Dafür gab es Pläne ein Broker Protokoll für OpenRefine einzuführen, die bisher aber weder umgesetzt noch eingeplant wurden.

In der Dokumentation von OpenRefine wird folgendes Vorgehen empfohlen:

Die beste Art, mit einer anderen Person zusammenzuarbeiten, ist, Projekte zu exportieren und zu importieren, wobei alle Änderungen gespeichert werden, so dass Sie an der Stelle weiterarbeiten können, wo die andere Person aufgehört hat.

Übersetzt von Starting a project: Import a project, aufgerufen am 01.12.2021.

--- title: Gemeinsam arbeiten - Strategie 1 config: look: handDrawn theme: neutral --- flowchart TD subgraph a["fa:fa-user Alice"] vaa["fa:fa-table Version A"] vab["fa:fa-table Version B"] vac["fa:fa-table Version C"] vad["fa:fa-table Version D"] end subgraph b["fa:fa-user Bob"] vba["fa:fa-table Version A"] vbb["fa:fa-table Version B"] end subgraph c["fa:fa-user Charly"] vcb["fa:fa-table Version B"] vcc["fa:fa-table Version C"] end vaa -.Übergabe.-> vba --Arbeiten--> vbb -.Übergabe.-> vab -.Übergabe.-> vcb --Arbeiten--> vcc -.Übergabe.-> vac --Arbeiten--> vad

Konkret bedeutet das, dass bei einer Kooperation von Alice, Bob und Charly zwar alle an dem gleichen Projekt arbeiten können, jedoch nicht gleichzeitig. Nachdem Alice das Projekt an Bob übergeben hat, arbeitet Bob daran. Nachdem Bob fertig ist, übergibt er das Projekt an Alice zurück, die es an Charly übergibt. Nachdem Charly fertig ist, übergibt er das Projekt an Alice zurück, die dann erst daran weiterarbeiten kann. Das war für uns im FDMLab ein eher unbefriedigender Zustand, weshalb wir zu einer anderen Strategie gewechselt haben.

--- title: Gemeinsam Arbeiten - Strategie 2 config: look: handDrawn theme: neutral --- flowchart LR subgraph a["fa:fa-user Alice"] va["fa:fa-table Version A"] vb["fa:fa-table Version B"] vc["fa:fa-table Version C"] vd["fa:fa-table Version D"] end subgraph b["fa:fa-user Bob"] pa["fa:fa-table Part A"] end subgraph c["fa:fa-user Charly"] pb["fa:fa-table Part B"] end va -.-> pa vb -.-> pb pa -.-> vc pb -.-> vd va --Arbeiten--> vb --Arbeiten--> vc --Arbeiten--> vd

Wir haben angefangen Teile eines Projektes in OpenRefine auszulagern und nach erfolgreicher Bearbeitung wieder in das Originalprojekt einzupflegen. So kann in unserem Beispiel Alice weiter an dem Projekt arbeiten, während Bob und Charly sie durch die Bearbeitung einzelner Teile unterstützen. Diese Teile werden anschließend von Alice wieder in das Originalprojekt eingepflegt. Wie das funktioniert besprechen wir in den folgenden Unterpunkten.

Zeilenweise zusammenführen

Manchmal ist es möglich, ein Projekt zeilenweise aufzuteilen. Also dass Alice die ersten 100 Zeilen, Bob die nächsten 100 und Charly die letzten 75 Zeilen bearbeitet.

Die Ergebnisse können nach der Bearbeitung als CSV-Dateien exportiert und daraus anschließend ein neues OpenRefine-Projekt erstellt werden.

Bildschirmfoto der Dateiauswahl Oberfläche von OpenRefine.

Wie in Abbildung 1 gezeigt, kann OpenRefine ein Projekt aus mehreren Dateien erstellen. Das kann auch ein Dateiarchiv sein, dessen Dateien in ein neues Projekt importiert werden.

Bildschirmfoto des Dateifilter Oberfläche von OpenRefine.

Bevor das Projekt konfiguriert wird, gibt es wie in Abbildung 2 gezeigt, die Möglichkeit einzelne Dateien aus- oder abzuwählen. Im Idealfall haben die einzelnen Dateien schon die gleichen Spaltenüberschriften in der richtigen Reihenfolge. Ansonsten bietet OpenRefine mit der Möglichkeit Spalten zu verbinden und Spalten zu verschieben die Möglichkeit das nachträglich zu bereinigen.

Spaltenweise zusammenführen

Ein häufiger Anwendungsfall im FDMLab ist, dass das Aufräumen und Transformieren der Daten von einer Person erledigt wird, die zum Beispiel beim Reconciling oder dem Abgleich mit weiteren Datenquellen von weiteren Personen unterstützt wird. Dafür werden einzelne Spalten als CSV (oder Excel) exportiert, von der unterstützenden Person bearbeitet und die Ergebnisse dann wieder in das Originalprojekt übernommen.

Ein anderer Fall kann sein, dass es schon einen anderen Datensatz gibt, dessen Daten komplett oder teilweise übernommen werden sollen. Das haben wir in Findbuchdaten mit OpenRefine wiederverwenden teilweise besprochen.

Beispiel

In unserem fiktiven Beispiel arbeitet Alice mit einem Datensatz der 16 Bundesländer, wie er in Abbildung 3 gezeigt ist. Diesen gibt sie an Bob und Charly weiter.

Bildschirmfoto der Oberfläche von OpenRefine mit den 16 Bundesländern.

Bob unterstützt Alice, indem er für die 16 Bundesländer das “Motto” recherchiert, er kann jedoch nicht für alle Bundesländer ein Motto finden und liefert den in Abbildung 4 gezeigten Datensatz zurück. ¹

Bildschirmfoto der Oberfläche von OpenRefine mit dem Motto einiger Bundesländer.

Charly hat die Aufgabe die Hauptstädte der einzelnen Bundesländer zu recherchieren, und liefert den in Abbildung 5 gezeigten Datensatz zurück. Dabei wurden jedoch die Namen der Bundesländer teilweise geändert, also zum Beispiel der Begriff “Freistaat” aus dem Namen wegoptimiert.

Bildschirmfoto der Oberfläche von OpenRefine mit den Hauptstädten der 16 Bundesländer.

Datensätze herunterladen

Die drei beschriebenen Datensätze können hier heruntergeladen werden, um die vorgestellten Methoden zum Zusammenführen von Daten beim gemeinsamen Arbeiten in OpenRefine selbst auszuprobieren

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

Bundesländer als CSV

Bundesländer Motto als CSV

Bundesländer Hauptstädte als CSV

ID Spalte erstellen

Wir werden die Daten auf drei Arten abgleichen:

Via einer dedizierten ID-Spalte
Mit einer improvisierten ID-Spalte (Name des Bundeslandes)
Via Reconciling

Idealerweise haben alle Datensätze eine einheitliche ID-Spalte zum Abgleichen. Diese lässt sich in OpenRefine über “Spaltenmenü" "Edit column" "Add column based on this column…” mit dem folgenden GREL Ausdruck anlegen:

row.index + 1

Wie in Abbildung 6 gezeigt, wird so eine ID-Spalte erzeugt, deren Nummerierung analog zur Nummerierung der Zeilen in OpenRefine verläuft.

Bildschirmfoto des Spalten hinzufügen Dialogs in OpenRefine.

Alternativ lassen sich manchmal auch ID-Spalten improvisieren, indem zum Beispiel bei Personen die Namen und Vornamen in eine ID-Spalte übernommen werden.

Zusammenführen mit cross()

Alice hat von Bob und Charly zwei CSV-Dateien bekommen, die sie in ihr OpenRefine-Projekt übernehmen möchte. Eine Möglichkeit, das innerhalb von OpenRefine zu erledigen, ist die Funktion cross().

Im OpenRefine-Wiki gibt es einige Beispiele zur Anwendung von cross(). Außerdem gibt es eine OpenRefine-Erweiterung für cross() um die Funktion über Dialoge in der Oberfläche von OpenRefine zu verwenden.

Wir verwenden die Funktion cross() ohne Erweiterung. Dafür erstellen wir für die drei Datensätze jeweils ein Projekt.

Projekt “Bundesländer” aus bundeslaender.csv
Projekt “Bundesländer Motto” aus bundeslaender-motto.csv
Projekt “Bundesländer Hauptstadt” aus bundeslaender-hauptstadt.csv

Wir verwenden absichtlich Umlaute und Leerzeichen im Projektnamen, um zu testen, ob OpenRefine beim Auflösen mit cross() damit klarkommt!

Zusammenführen via ID

Idealerweise haben wir eine eindeutige ID-Spalte, um die Projekte miteinander abzugleichen. Mit cross() können wir über die ID-Spalte Daten aus einem anderen OpenRefine-Projekt nachladen. Das funktioniert aber nur, wenn die IDs eindeutig sind.

Nachladen des Mottos

Zum Nachladen des Mottos der Bundesländer gehen wir im “Bundesländer”-Projekt über das Spaltenmenü “ID" "Edit column" "Add column based on this column…” und verwenden den folgenden GREL Ausdruck.

cell.cross("Bundesländer Motto", "ID").cells["Mottotext"].value[0]

Dabei ist “Bundesländer Motto” der Name des Projektes aus dem wir die Daten holen wollen, und “ID” die ID-Spalte im Projekt “Bundesländer Motto”.

Bildschirmfoto des Spalten hinzufügen Dialogs mit cross() für den Mottotext in OpenRefine.

Wie in Abbildung 7 gezeigt, werden die Daten (also der Mottotext) aus dem anderen Projekt nachgeladen. Es haben nicht alle Bundesländer einen Mottotext hinterlegt, was den Abgleich nicht weiter stört.

Nachladen der Hauptstadt

Zum Nachladen der Hauptstadt der Bundesländer gehen wir im “Bundesländer”-Projekt über das Spaltenmenü “ID" "Edit column" "Add column based on this column…” und verwenden den folgenden GREL Ausdruck.

cell.cross("Bundesländer Hauptstadt", "ID").cells["Hauptstadt"].value[0]

Dabei ist “Bundesländer Hauptstadt” der Name des Projektes aus dem wir die Daten holen wollen, und “ID” die ID-Spalte im Projekt “Bundesländer Hauptstadt”.

Bildschirmfoto des Spalten hinzufügen Dialogs mit cross() für die Hauptstadt in OpenRefine.

Wie in Abbildung 8 gezeigt, werden die Daten (hier die Hauptstadt) aus dem anderen Projekt nachgeladen. Es haben alle Bundesländer eine Hauptstadt, so dass der Abgleich hier für jeden Eintrag ein Ergebnis produziert.

Außerdem ist zu erwähnen, dass sich OpenRefine hier auch nicht daran stört, dass die ID-Spalte bei uns im Projekt “Bundesländer” als Zahl, im Projekt “Bundesländer Motto” jedoch als Typ Text gespeichert ist.

Zusammenführen via Werte

Es ist nicht immer eine eindeutige ID-Spalte vorhanden. Das kommt zum Beispiel vor, wenn die Daten aus verschiedenen Projekten stammen. Man kann auch ID-Spalten improvisieren, was aber nicht immer zum gewünschten Ergebnis führt. Wir werden den Abgleich mit cross() diesmal über die Spalte “Bundesland” durchführen.

Nachladen des Mottos

Zum Nachladen des Mottos der Bundesländer gehen wir im “Bundesländer”-Projekt diesmal über das Spaltenmenü “Bundesland“ "Edit column" "Add column based on this column…” und verwenden den folgenden GREL Ausdruck.

cell.cross("Bundesländer Motto", "Bundesland").cells["Mottotext"].value[0]

Wie in Abbildung 9 zu sehen ist, hat der Abgleich zwischen diesen beiden Projekten kein Problem, da die Bundesländer hier einheitlich geschrieben sind.

Bildschirmfoto des Spalten hinzufügen Dialogs mit cross() für den Mottotext in OpenRefine.

Nachladen der Hauptstadt

Zum Nachladen der Hauptstädte der Bundesländer gehen wir im “Bundesländer”-Projekt diesmal über das Spaltenmenü “Bundesland“ "Edit column" "Add column based on this column…” und verwenden den folgenden GREL Ausdruck.

cell.cross("Bundesländer Hauptstadt", "Bundesland").cells["Hauptstadt"].value[0]

Wie in Abbildung 10 zu sehen ist, hat der Abgleich hier Probleme, da die Bundesländer teilweise unterschiedlich geschrieben sind. Es fehlen Ergänzungen wie “Freistaat”. Daher können die Daten für diese Bundesländer nicht nachgeladen werden.

Bildschirmfoto des Spalten hinzufügen Dialogs mit cross() für die Hauptstadt in OpenRefine.

Ergebnis

Bildschirmfoto von OpenRefine mit den Bundesländern und den zusätzlichen Spalten aus anderen Projekten.

Der Abgleich mit cross() innerhalb von OpenRefine funktioniert recht einfach, solange es eine Spalte mit eindeutigen Werten gibt. Der Abgleich stört sich auch nicht an Sonderzeichen, Leerzeichen oder fehlenden Werten.

Problematisch wird es, wenn die Werte der Spalten, die abgeglichen werden, nicht komplett übereinstimmen. Diese sind in Abbildung 11 farblich hervorgehoben. In solchen Fällen empfiehlt sich das im nächsten Abschnitt besprochene lokale Reconciling.

Zusammenführen mit lokalem Reconciling

Wir hatten in Fünf Dinge, die wir an OpenRefine mögen schon die Architektur von OpenRefine gelobt, da diese so gestaltet ist, dass OpenRefine auch mit anderen APIs kommunizieren kann. Besonders unterstützt ist dabei das Reconciliation Service API Protokoll. Damit können Daten in einem OpenRefine-Projekt nicht nur gegen Wikidata oder die GND abgeglichen werden, sondern mit Werkzeugen wie csv-reconcile auch mit lokalen CSV-Dateien.

--- title: OpenRefine Setup config: look: handDrawn theme: neutral --- flowchart LR subgraph server[fas:fa-server Server] server_or[fas:fa-gem OpenRefine] server_api[fas:fa-code Reconciliation Service API] end subgraph laptop[fas:fa-laptop Laptop] browser[far:fa-window-maximize Browser] laptop_or[fas:fa-gem OpenRefine] laptop_api[fas:fa-code Reconciliation Service API] end browser -.-> laptop_or & server_or laptop_or -.-> laptop_api & server_api server_or -.-> server_api

Für die Verwendung von csv-reconcile benötigt man Python auf seinem System. Ist Python vorhanden, dann kann csv-reconcile einfach via Shell (PowerShell, Git Bash, …) installiert werden. Wir erstellen dafür erst eine virtuelle Umgebung in unserem Arbeitsordner, um csv-reconcile ausschließlich dort zu installieren.

Der Arbeitsordner ist der Ordner, in dem wir unsere CSV-Dateien liegen haben, mit denen wir hier arbeiten.

Die virtuelle Umgebung für Python ermöglicht es uns, Python Bibliotheken nur für dieses Projekt zu installieren, so dass sie nicht mit Bibliotheken oder Python Versionen in anderen Projekten in Konflikt kommen.

> python -m venv venv # virtuelle Umgebung erstellen
> .\venv\Scripts\activate # virtuelle Umgebung aktivieren (Windows!)
(venv) > pip install csv-reconcile # csv-reconcile in virtuelle Umgebung installieren

Da csv-reconcile in Version 0.3.0 den Vorschaudienst optional anbietet und keine automatische Erkennung von Encoding und Trennzeichen in CSV-Dateien hat, erstellen wir in unserem Arbeitsordner zusätzlich eine Datei config.py mit dem folgenden Inhalt.

CSVKWARGS={'delimiter': ',', 'quotechar': '"'}
CSVENCODING='UTF-8'
MANIFEST = {
 "preview": {
 "url": "http://localhost:5000/preview/{{id}}",
 "width": 400,
 "height": 300
 }
}

Anschließend können wir mit aktivierter virtueller Umgebung in unserem Arbeitsordner den lokalen Reconciling Service für die “Bundesländer Motto” CSV-Datei initiieren und starten.

(venv) > csv-reconcile init --config config.py bundeslaender-motto.csv ID Bundesland
(venv) > csv-reconcile serve

Wenn wir mit dieser Datei fertig sind, können wir den lokalen Reconciling Service für die “Bundesländer Hauptstadt” CSV-Datei initiieren und starten.

Ob die virtuelle Umgebung aktiv ist, sieht man an der Ergänzung (venv) in der Shell. Ansonnsten lässt sie sich mit .\venv\Scripts\activate wieder aktivieren.

(venv) > csv-reconcile init --config config.py bundeslaender-hauptstadt.csv ID Bundesland
(venv) > csv-reconcile serve

Wir könnten die beiden lokalen Reconciling Services auch parallel laufen lassen, indem wir sie in unterschiedliche Ordner schieben und wie unter csv-reconcile: Common configuration beschrieben über die Variable SERVER_NAME in der config.py jeweils einen anderen Port setzen.

In OpenRefine fügen wir den lokalen Reconciliation Service hinzu, indem wir in einem Projekt über ein beliebiges “Spaltenmenü" "Reconcile" "Start reconciling” aufrufen und dort via “Add Standard Service…” die Adresse http://localhost:5000/reconcile eingeben. Der Port 5000 muss entsprechend angepasst werden, wenn er in der config.py geändert wurde.

Siehe auch die OpenRefine-Dokumentation zu Reconciling: Getting started.

Zusammenführen via ID

Idealerweise haben wir eine eindeutige ID-Spalte, um die Projekte miteinander abzugleichen. Dann ist der lokale Reconciliation Service fast schon etwas zu mächtig, und wird von uns eher eingesetzt, wenn wir es vermeiden wollen, zu viele OpenRefine-Projekte zu jonglieren.

Nachladen des Mottos

Wir haben den lokalen Reconciling Service für das “Bundesländer Motto”-Projekt, wie im oberen Abschnitt beschrieben, am laufen.

Zum Nachladen des Mottos der Bundesländer gehen wir im “Bundesländer”-Projekt über das Spaltenmenü “ID" "Reconcile" "Use values as identifiers” und wählen unseren CSV Reconciliation Service aus.

Die IDs werden nun alle zu Links. Wie im Maus-Hover in Abbildung 12 sehen wir, dass nicht alle IDs aufgelöst werden, sondern manchmal eine “Nicht gefunden” Meldung angezeigt wird. Zur Erinnerung: es gibt nicht für alle Bundesländer ein Motto in unseren Daten!

Bildschirmfoto des Maus-Hover ‘Not Found’ in OpenRefine.

Den Mottotext können wir über “ID" "Edit column" "Add columns from reconciled values…” nachladen. Wie in Abbildung 13 zu sehen ist, kann der Dienst auch mit nicht auflösbaren IDs umgehen und ignoriert diese einfach.

Bildschirmfoto des Reconciliation Dialogs mit dem Mottotext in OpenRefine.

Nachladen der Hauptstadt

Wir haben den lokalen Reconciling Service für das “Bundesländer Hauptstadt”-Projekt, wie im oberen Abschnitt beschrieben, am laufen.

Zum Nachladen der Hauptstädte der Bundesländer gehen wir wieder im “Bundesländer”-Projekt über das Spaltenmenü “ID" "Reconcile" "Use values as identifiers” und wählen unseren CSV Reconciliation Service aus.

Die IDs werden nun alle wieder zu Links. Bei diesem Abgleich können alle IDs aufgelöst werden und wir sehen wie in Abbildung 14 überall Maus-Hover mit den entsprechenden Werten des gematchten Eintrags in der CSV-Datei.

Bildschirmfoto des Maus-Hover mit CSV Werten in OpenRefine.

Zusammenführen via Werte

Es ist nicht immer eine eindeutige ID-Spalte vorhanden. In so einem Fall spielt der lokale Reconciliation Service seine Stärke aus, da wir mit ihm auch “ungenaue” Werte finden und matchen können.

Nachladen des Mottos

Wir haben den lokalen Reconciling Service für das “Bundesländer Motto”-Projekt, wie im oberen Abschnitt beschrieben, am laufen.

Zum Nachladen der Mottos der Bundesländer über die Wertespalte gehen wir zu “Bundesland" "Reconcile" "Start reconciling” und wählen den “CSV Reconciling Service” aus.

Wie in Abbildung 15 markiert, ist das automatische Matching etwas zu großzügig, so dass Bundesländer gematcht werden, weil sie zum Beispiel beide den Begriff “Freistaat” im Namen haben. Das kann manuell und bei größeren Datenmengen mit der Unterstützung von Facets auf den Konfidenzwerten (Wert wie gut das Matching passt) nachgearbeitet werden.

Bildschirmfoto des Ergebnis des automatischen Reconciling in OpenRefine.

Den Mottotext können wir dann wieder über “Bundesland" "Edit column" "Add columns from reconciled values…” nachladen. Wie in Abbildung 16 zu sehen ist, kann der Dienst auch in diesem Fall mit nicht auflösbaren IDs umgehen und ignoriert diese einfach.

Bildschirmfoto des Reconciliation Dialogs mit dem Mottotext in OpenRefine.

Nachladen der Hauptstadt

Wir haben den lokalen Reconciling Service für das “Bundesländer Hauptstadt”-Projekt, wie im oberen Abschnitt beschrieben, am laufen.

Zum Nachladen der Hauptstädte der Bundesländer über die Wertespalte gehen wir zu “Bundesland" "Reconcile" "Start reconciling” und wählen den “CSV Reconciliation Service” aus.

Da wir in diesem Datensatz passende Einträge für alle Bundesländer haben, funktioniert das Matching, wie in Abbildung 17 zu sehen ist, recht gut, obwohl die Bundesländer teilweise anders geschrieben sind.

Bildschirmfoto der Oberfläche von OpenRefine mit den Reconciliation Ergebnissen für die Bundesländer.

Ergebnis

Der Abgleich mit dem lokalen Reconciling Service hat initial einen höherne Aufwand, da sowohl Python auf dem System als auch der CSV Reconciling Service in OpenRefine eingerichtet werden müssen. Dann ist das Verfahren jedoch deutlich flexibler als das Zusammenführen mit cross(), da darüber sowohl ein exaktes ID Matching und Nachladen von Spalten durchgeführt werden kann, als auch ein so genanntes Fuzzy-Matching, bei dem die Werte in den Spalten nicht exakt übereinstimmen.

In Abbildung 18 sind nochmal alle nachgeladenen Spalten abgebildet, wobei

via cross() auf der ID-Spalte
via cross() auf der Werte-Spalte (Namen Bundesland)
via lokalem Reconciling Service auf der ID-Spalte
via lokalem Reconciling Service auf der Werte-Spalte (Namen Bundesland)

nachgeladen wurde.

Bildschirmfoto von OpenRefine mit den Bundesländern und den zusätzlichen Spalten aus anderen Projekten.

Ausblick auf weitere Methoden

Für das Zusammenführen von Datensätzen mit OpenRefine gibt es noch weitere Möglichkeiten, die sich aktuell in der Planung und Entwicklung befinden.

Zum einen gibt es Überlegungen für Projekte in OpenRefine automatisch einen Reconciliation Service zu erstellen, so dass analog zu cross() direkt innerhalb von OpenRefine ein Reconciling gegen andere Projekte durchgeführt werden kann. Also Reconciling innerhalb von OpenRefine ohne separaten lokalen Reconciling Service.

Zum anderen gibt es mit Datasette ein komplettes Ökosystem um Daten in SQLite einzulesen und anschließend via unterschiedlicher APIs zur Verfügung zu stellen. Es wird gerade auch ein Reconciliation Plugin für Datasette entwickelt.

Gibt es in Arbeitsgruppen Datensätze, die intern oder extern veröffentlicht und auch für Reconciliation genutzt werden sollen, dann lohnt sich ein Blick auf dieses Werkzeug.

Fazit

OpenRefine bietet mit seiner Architektur das Potential zukünftig kollaboratives Arbeiten zu ermöglichen. Bis dahin können wir uns selbst helfen und mit wenig Extraaufwand Aufgaben aufteilen und die Ergebnisse wieder zusammenführen. Mit der cross() Funktion können wir direkt Daten aus anderen OpenRefine-Projekten über ID-Spalten übernehmen. Mit einem lokalem Reconciling Service können wir auch Daten aus unterschiedlichen Projekten verbinden.

Bisher klappt das beschriebene Vorgehen im FDMLab ganz gut und wir beobachten weiterhin gespannt die Entwicklung sowohl von OpenRefine, als auch von anderen Werkzeugen wie csv-reconcile und Datasette, die es hervorragend ergänzen.

Die Mottotexte wurden aus Wikidata geladen und sind daher genauso (un)vollständig, wie die Daten dort. ↩︎

Fünf Dinge, die wir mit OpenRefine nicht (gerne) machen

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

Wir haben uns in den letzten Wochen im Blog ausgiebig mit OpenRefine beschäftigt und wollen einmal festhalten, wozu es sich unserer Ansicht nach nicht eignet.

Batchverarbeitung

Die Idee von Batchverarbeitung von Daten mit OpenRefine (Automating OpenRefine) ist relativ simpel: es wird eine Datei mit OpenRefine bearbeitet und die History anschließend mit einem Programm wie openrefine-batch auf die anderen Dateien angewendet.

--- title: Batchverarbeitung mit OpenRefine config: look: handDrawn theme: neutral --- flowchart TD openrefine[fas:fa-gem OpenRefine] openrefine2[fas:fa-gem OpenRefine] hist[fas:fa-file-code History] subgraph input[fas:fa-sign-out-alt Input] file1.xml[fas:fa-file-alt] file2.xml[fas:fa-file-alt] filex.xml[fas:fa-file-alt] end subgraph output[Output fas:fa-sign-in-alt] file1.csv[fas:fa-file-excel] file2.csv[fas:fa-file-excel] filex.csv[fas:fa-file-excel] end filex.xml --> openrefine --> filex.csv openrefine --> hist --> openrefine2 input --> openrefine2 --> output

Das funktioniert, solange die Dateien alle genau die gleichen Strukturen und Inhalte haben (Happy Path). Problematisch wird es bei der Fehlerbehandlung oder Verzweigungen. Wir haben in unserem Artikel Findbuch Daten mit OpenRefine wiederverwenden über die Anwendung der History auf weitere Findbücher berichtet. Dort hatten wir unter anderem das Problem, dass die Kopfzeilen eine andere Struktur hatten. Das lässt sich zwar in vielen Fällen mit Kontrollstrukturen in OpenRefine abbilden, jedoch wird die Umsetzung schnell komplex.

Big Data

Mit Big Data meinen wir hier Datensätze, die auf Grund ihrer Größe nicht im Arbeitsspeicher (RAM) gehalten werden können. Je nach Rechner, kann das schon bei Datensätzen mit einer Dateigröße unter einem Gigabyte der Fall sein.

OpenRefine wurde so entwickelt, dass es ohne externe Datenbank funktioniert. Stattdessen werden die Daten im Speicher vorgehalten (siehe Technology Stack). Dadurch können und sollen Datensätze ab einer bestimmten Größe mit OpenRefine nicht mehr verarbeitet werden. ¹

In der Dokumentation zu OpenRefine steht, dass schon ab einer Dateigröße von mehr als 50 Megabyte, die Standardeinstellungen von OpenRefine anzupassen sind (Increasing memory allocation).

XML Transformationen

OpenRefine kann XML einlesen, verarbeiten und ausgeben, es kann Daten als Tabelle darstellen und mit dem Konzept von Records baumartige Strukturen zugänglich machen.

Das Problem ist, dass XML noch “mehr” kann. In einer XML Datei können mehrere unterschiedliche Tabellen, Bäume und Netze gespeichert werden. Diese lassen sich als Gesamtwerk in OpenRefine nicht sinnvoll darstellen und daher nicht komfortabel bearbeiten.

Bei der Verarbeitung von XML mit OpenRefine kommt es also auf die Struktur der Daten in der XML Datei an. Daher verwenden wir besonders bei XML Transformationsaufgaben häufig andere Technologien und Tools, die explizit für die Arbeit mit XML entwickelt wurden.

Tabellenkalkulation

Die folgende Tabelle ist in einer Software für Tabellenkalkulation wie MS Excel oder LibreOffice Calc in Sekunden erzeugt. Als Bonus kann die Summenzeile als Formel definiert werden, die bei Änderungen automatisch die Werte aktualisiert.

Jahr	Spalte 1	Spalte 2	Spalte 3
2019	1	4	7
2020	2	5	8
2021	3	6	9
Summe:	6	15	24

In OpenRefine ist das Hinzufügen einer Summenzeile im Vergleich ziemlich aufwendig, inklusive Transponieren der Tabelle, da nur neue Spalten hinzugefügt werden können. Eine automatische Aktualisierung der Summenzeile via Formel ist aktuell nicht möglich.

Zeilenübergreifende Operationen

OpenRefine arbeitet spaltenorientiert und tut sich schwer damit zeilenübergreifend zu agieren. Ein Beispiel ist die Berechnung der kumulierten Werte wie in der folgenden Tabelle.

Wert	Kumuliert
1	1
2	3
3	6

Das Problem ist, dass es in OpenRefine keine (direkte) Möglichkeit gibt, auf eine Spalte zuzugreifen. Der Zugriff auf die aktuelle Zeile mit row.cells funktioniert problemlos!

Hierfür gibt es zwei Workarounds:

Verwendung der cross() Funktion.
Die Tabelle zu einem einzelnen Recordeintrag machen. Innerhalb eines “record” lässt sich via row.record.cells auf alle Spalten des “record” zugreifen.

Beide Varianten sind jedoch wenig intuitiv.

Fazit

OpenRefine kann schnell zu “Maslows Hammer” werden. Mit diesem Artikel wollen wir einige Probleme zeigen, die sich nach unserer Erfahrung mit OpenRefine nicht oder im Vergleich mit anderen Werkzeugen nur sehr aufwendig lösen lassen.

Nachtrag: der Artikel wurde auch auf der OpenRefine Dev Mailingliste kommentiert.

Dies ändert sich mit OpenRefine 4.0 und der geplanten Unterstützung von Apache Spark. ↩︎

Erfahrungsbericht - Extraktion und Abgleich von Prokuratoren mit OpenRefine

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

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

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

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

Generelle Daten

Text:

10 Bände
10.339 Textzeilen

CSV:

2.912 Indexeinträge
Davon 100 Aliase

Deduplikation:

472 Prokuratoren

Abgleich mit GND:

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

Anwenden mehrerer Teilschritte

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

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

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

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

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

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

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

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

Deduplikation mit Clusterverfahren

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

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

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

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

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

Abgleich mit der GND

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

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

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

Fazit

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

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

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

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

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

Fünf Dinge, die wir an OpenRefine mögen

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

Wir haben uns in den letzten Wochen im Blog ausgiebig mit OpenRefine beschäftigt und wollen einmal festhalten, was uns daran so gefällt.

--- title: OpenRefine Setup config: look: handDrawn theme: neutral --- flowchart LR subgraph server[fas:fa-server Server] server_or[fas:fa-gem OpenRefine] server_api[fas:fa-code Other API] end subgraph laptop[fas:fa-laptop Laptop] browser[far:fa-window-maximize Browser] laptop_or[fas:fa-gem OpenRefine] laptop_api[fas:fa-code Other API] laptop_python[fab:fa-python Python] end browser -.-> laptop_or & server_or laptop_python -.-> laptop_or & server_or laptop_or -.-> laptop_api & server_api server_or -.-> server_api

Architektur

Zuerst mag es seltsam erscheinen, dass sich beim Starten von OpenRefine die Bedienoberfläche im Webbrowser öffnet. Der Grund dafür ist, dass bei OpenRefine die Bedienoberfläche von der eigentlichen Anwendung getrennt ist (Architektur von OpenRefine). Die Kommunikation zwischen Bedienoberfläche und Programm erfolgt via einer Programmierschnittstelle (API von OpenRefine).

Durch die Benutzung über den Webbrowser, kann OpenRefine sowohl auf dem eigenen PC oder Laptop betrieben, als auch auf einem Server zur Verfügung gestellt werden. Über die OpenRefine API lässt sich das Programm programmatisch steuern. Es gibt mehrere Softwarebibliotheken für unterschiedliche Programmiersprachen, die die Verwendung der OpenRefine API vereinfachen. In dem obigen Diagramm haben wir das exemplarisch mit Python dargestellt.

Scripting

Neben den vorgefertigten Funktionen bietet OpenRefine mit der JavaScript ähnlichen General Refine Expression Language (GREL) ein passendes Werkzeug um Daten zu transformieren.

Mit der Einbindung der deutlich mächtigeren Programmiersprachen Clojure und Jython fühlen sich auch Entwickler wohl und können damit komplexe Probleme lösen.

Schnittstellen

OpenRefine ist explizit offen entwickelt und es lassen sich auf unterschiedlichesten Wegen zig Formate einlesen und exportieren.

Darüber hinaus lassen sich mit OpenRefine auch Webdienste beziehungsweise andere APIs verarbeiten. Wir haben bereits gezeigt, wie wir mit der Reconciliation API Daten mit dem von lobid bereitgestellten GND Service abgleichen, wie wir die Reconciliation API mit lokalen CSV Dateien verwenden, und wie wir mit FastAPI beliebige lokale Services selbst erstellen und mit OpenRefine nutzen.

History

Die History ist ein prominentes Element im der Bedienoberfläche. Mit ihr lassen sich Operationen in einem Projekt nachvollziehen und auf andere Projekte übertragen.

Wir verwenden die Funktion häufig im Kontext eines iterativen Vorgehens. Wir springen zu einem früheren Bearbeitungszustand zurück, korrigieren einen Bearbeitungsschritt und wenden anschließend die Folgeschritte automatisiert erneut an.

Das funktioniert nicht bei der manuellen Bearbeitungen von Zellinhalten!

Filter

Bisher haben wir die Filterfunktionen (Facets) nur eingeschränkt genutzt. Die Möglichkeit unterschiedliche Filter miteinander zu kombinieren und sie zu invertieren und anschließend gezielt Operationen auf die Filterergebnisse anzuwenden ist jedoch ziemlich mächtig. Beim Reconciling von Daten mit der GND konnten wir dadurch ziemlich schnell relevante Treffer identifizieren und uns lediglich mit diesen beschäftigen.

Weitere Quellen

Bei der Suche nach Lösungen sind wir über einige Anleitungen gestolpert, die wir an dieser Stelle gerne weiterempfehlen möchten.

Das Projekt histHub in der Schweiz beschäftigte sich schon ausführlich mit OpenRefine und hat eine komplette deutschsprachige Tutorial-Serie zu OpenRefine geschrieben. Weitere Artikel finden sich auf der Projektseite unter dem Tag OpenRefine.

Das Programming Historian Projekt hat zwei mehrsprachige Tutorials zum Säubern von Daten mit OpenRefine und zum Aufbereiten von Daten aus dem Web mit OpenRefine im Angebot.

Eine ausführliche Liste von weiteren Quellen gibt es im OpenRefine Wiki.

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

2. Workshop des OCR-BW-Projektes 2021

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

Der FDMLab Blog - Begrüßung

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

Das FDMLab@LABW ist das Forschungsdatenmanagement Labor am Landesarchiv Baden Württemberg. Hier beschäftigen wir uns -zusammengefasst- mit dem Thema Digitalisierung und Aufbereitung von Archivgut und Findmitteln.

Daher sind unsere fünf Hauptthemen:

/ Erkennung von Druckschriften (OCR) und Handschriften (HTR)
Objekterkennung auf Bildern (z.B. YOLO)
Normdaten (z.B. Gemeinsame Normdatei, Linked Data)
User Generated Content (UGC)
FAIRe Daten

Im FDMLab evaluieren, testen und nutzen wir eine Vielzahl von Technologien und Strategien. Auch um selbst einen Überblick über unsere Ergebnisse zu behalten, haben wir angefangen diese auszugsweise in Artikel aufzubereiten und als Blog zur Verfügung zu stellen.

Wir schreiben über die von uns eingesetzten Technologien, über unsere Vorgehensweise, was sich bewährt hat und auch was nicht erfolgreich war. Daher wird es hier eine Mischung aus teilweise sehr technisch und archivfachlich orientierten Artikeln geben.