Probleme mit Umlauten in OpenRefine

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

Bei der Verarbeitung deutschsprachiger Texte stoßen wir hin und wieder auf Probleme mit Umlauten und anderen Sonderzeichen. In diesem Artikel haben wir einige typischen Probleme und ihre Lösungen aufgelistet.

Umlaute in Metadaten sorgen für Speicherprobleme in OpenRefine 3.5

OpenRefine hat in der Version 3.5 ein Problem mit Umlauten und anderen Sonderzeichen in den Metadaten. Zu den Metadaten gehören zum Beispiel der Projektname, die Schlagworte, der Dateiname der importierten Datei, Templates für den Export, …

Diese fehlerhaft gespeicherten Sonderzeichen in den Metadaten verdoppeln sich bei jedem (Neu)Start von OpenRefine (siehe Grafiken 1 - 3).

Bildschirmfoto des Projektes nach dem Import.

Bildschirmfoto des Projektes nach dem ersten Neustart.

Bildschirmfoto des Projektes nach dem zweiten Neustart.

Da es sich hierbei um ein exponentielles Wachstum handelt, ist es möglich, dass wir nach einiger Zeit Metadaten in der Größe von mehreren Gigabyte produzieren. Dadurch kann OpenRefine irgendwann nicht mehr starten und meldet beim Start: HTTP ERROR 500 java.lang.OutOfMemoryError: Java heap space. Der Reflex die Größe des Heaps (max memory heap size) in der openrefine.l4j.ini anzupassen hilft zwar erst einmal, jedoch werden die Metadaten weiterhin schneller wachsen, als man Arbeitsspeicher nachkaufen kann.

Um das Problem vorübergehend zu mitigieren, benötigen wir zuerst eine Liste der betroffenen OpenRefine Projekte. Dafür ermitteln wir, wo die OpenRefine Projekte gespeichert sind.

In diesem Verzeichnis identifizieren wir ungewöhnlich große metadata.json Dateien. Dabei ist ungewöhnlich groß abhängig von der Art der Projekte mit denen wir arbeiten. Normalerweise sind metadata.json Dateien mit einer Größe, die in Megabyte oder größer gemessen wird, ein Grund sie genauer anzusehen.

Zur Identifikation der großen metadata.json Dateien können auch Werkzeuge verwendet werden. Für Windows gibt es unter anderem TreeSize und WinDirStat.

Die betroffenen Projektordner können dann (temporär) aus dem OpenRefine Projektordner herausgenommen und ihre ID aus der Datei workspace.json entfernt werden.

Um die metadata.json Dateien zu korrigieren, kann eine Kombination der Kommandozeilenwerkzeuge find und jq verwendet werden, wie es auf GitHub unter Out of memory errors from large metadata.json files being parsed during OpenRefine Project Open beschrieben wird.

Alternativ können die metadata.json Dateien auch manuell korrigiert werden. Dafür werden diese mit einem Texteditor geöffnet, der in der Lage ist diese großen Dateien darzustellen. Unter Windows kann dafür der Standard Texteditor (NotePad) verwendet werden.

Erfahrungsgemäß ist es dabei einfacher, die nicht betroffenen Teile der JSON-Datei in eine neue Datei zu kopieren, anstatt zu versuchen Megabytes an Sonderzeichen zu löschen.

Der Fehler wird mit OpenRefine 3.6 gefixt, jedoch werden die schon vermehrten Umlaute nicht automatisiert aufgeräumt. Generell ist es zu empfehlen, dass betroffene Benutzer möglichst früh zur Version 3.6 von OpenRefine wechseln.

Daten richtig in OpenRefine laden

OpenRefine ist prinzipiell schon recht gut darin die richtige Kodierung beim Import der Daten für ein Projekt zu erkennen. In Abbildung 4 wurde hier schon korrekt die Kodierung “UTF-8” erkannt. Es ist prinzipiell trotzdem zu empfehlen in der Vorschau der Daten zu prüfen, ob Umlaute und Sonderzeichen auch richtig angezeigt werden.

Bildschirmfoto der Optionen für den Projektimport.

Gegebenenfalls muss das Encoding noch angepasst werden. Dafür auf das Encoding-Feld klicken. In Abbildung 4 ist es das Feld mit Text “UTF-8”. Daraufhin öffnet sich ein Dialog mit einer Schnellauswahl von üblichen Kodierungen (Abbildung 5) und einen Tab “All Encodings”, mit einer ausführlichen Liste aller unterstützten Kodierungen (Abbildung 6).

So kann das Encoding der Datei noch vor dem Projektimport manuell angepasst werden.

Bildschirmfoto der Optionen für das Encoding.

Bildschirmfoto der erweiterten Optionen für das Encoding.

Nachgeladene Daten anpassen

Wir laden häufig auch Daten aus externen Quellen in ein existierendes Projekt. Hierbei kann es vorkommen, dass die Kodierung der eingehenden Daten nicht zu den Daten im Projekt passt.

Dafür gibt es die Möglichkeit die Daten mit der GREL Funktion reinterpret() anzupassen.

Die Kodierung des OpenRefine Projektes findet man in den Metadaten unter import option metadata (JSON). Die Kodierung der eingehenden Daten ist abhängig vom Projekt bzw. der API von der die Daten abgeholt werden.

Reguläre Ausdrücke mit Umlauten

Dem Thema Umlaute bei regulären Ausdrücken in OpenRefine haben wir eine eigene Aufgabe in unserem OpenRefine Workshop für Fortgeschrittene gewidmet.

Hier die Kurzzusammenfassung: OpenRefine verwendet Java zur Auswertung der regulären Ausdrücke, wobei die Unicode Unterstützung separat aktiviert werden muss. Das hat zur Folge, dass “Sonderzeichen” wie unsere Umlaute äöü, oder die in der französischen Sprache gebräuchlichen Buchstaben mit Akzenten éêè, nicht von den Mustern [a-z] oder \w berücksichtigt werden.

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

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

Probleme mit Textfilter und Umlauten

Manchmal haben wir in UTF-8 kodierten Projekten das Problem, dass Umlaute zwar korrekt dargestellt, Begriffe mit Umlauten z.B. über die Textfilter jedoch nicht gefunden werden.

Das kann daran liegen, dass Umlaute in UTF-8 sowohl als einzelnes Zeichen wie ä kodiert sein können, als auch als kombiniertes Zeichen aus a und " dargestellt werden können. ¹ Suchen wir dann zum Beispiel nach Gemälde, so wird der als Gema"lde kodierte Begriff nicht gefunden.

Um zu prüfen, ob das in einem OpenRefine Projekt der Fall ist, gibt es mehrere Möglichkeiten:

Einen Begriff mit Umlauten aus dem OpenRefine Projekt in einer separaten Datei speichern und mit einem Hex-Editor analysieren.
Mit einem Custom Text Facet und dem GREL Ausdruck value.unicode() prüfen, ob es kombinierte Zeichen wie das UTF-Zeichen 771 für den ergänzenden " gibt.
In einem Textfilter reguläre Ausdrücke aktivieren und die Sonderzeichen im Suchbegriff durch einen bzw. zwei Punkte .. (universeller Platzhalter) ersetzen. Also nach Gem.lde und nach Gem..lde suchen. Gibt es Ergebnisse mit Umlauten bei einem Punkt, dann sind die Umlaute mit einem Zeichen kodiert, gibt es Ergebnisse mit Umlauten nur bei zwei Punkten, sind sie als getrennte Zeichen kodiert.

GREL bietet zwar die Möglichkeit mit reinterpret den Text in eine andere Kodierung umzuwandeln, jedoch nicht die interne Kodierung von UTF-8 anzupassen.

Dafür benötigen wir entweder die Normalizer Standardfunktionalität von Java via Clojure, oder die Standardbibliothek unicodedata von Python via Jython.

Hier ist der entsprechende Ausdruck in Clojure:

(java.text.Normalizer/normalize value java.text.Normalizer$Form/NFC)

Hier der entsprechende Ausdruck in Python/Jython:

from unicodedata import normalize
return normalize("NFC", value)

Diese Schnippsel können z.B. via “All" "Transform” auf ausgewählte oder alle Spalten im OpenRefine Projekt angewendet werden.

Fazit

Die Unterstützung von Sonderzeichen und damit speziell Umlauten in der deutschen Sprache ist in OpenRefine nicht optimal. Das ist in den meisten Fällen technisch begründbar und es gibt Lösungen, jedoch ist es gerade für technische Laien problematisch das Problem so zu formulieren, dass die entsprechenden Lösungsansätze dafür gefunden werden.

Mit diesem Artikel hoffen wir, die Sichtbarkeit der möglichen Lösungen für Umlautprobleme in OpenRefine zu erhöhen.

Siehe dazu den Artikel zu Normalisierung von Unicode auf Wikipedia. ↩︎

Workshop - Daten mit OpenRefine exportieren

Fri, 01 Apr 2022 00:00:00 +0000

Wir exportieren Daten mit OpenRefine in unterschiedliche Formate.

Daten exportieren in der OpenRefine Dokumentation.

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

Hintergrund

OpenRefine bietet sowohl verschiedene fertige Exportmöglichkeiten an als auch die Möglichkeit, eigene Formate (JSON, XML) zu erstellen. Wir konzentrieren uns in diesem Workshop auf tabellenartige Formate.

Aufgabe 1: Daten als Excel exportieren

Wir verwenden das Projekt “Kretschmann Kabinett III”, das wir in Projekte in OpenRefine laden und verwalten erstellt haben.

Dort erstellen wir ein “Text Facet” auf der Spalte “Geschlecht” und wählen darüber alle weiblichen Kabinettsmitglieder aus.

Über “Export" "Excel 2007+ (.xlsx)” erzeugen wir eine Excel Datei.

Aufgabe 2: Daten als CSV exportieren

Wir verwenden das gleiche Setup wie in Aufgabe 1.

Über “Export" "Comma-separated value” erzeugen wir eine CSV Datei.

Aufgabe 3: Datenexport spezifizieren

Wir verwenden das gleiche Setup wie in Aufgabe 1.

Über “Export" "Custom tabular exporter…” erzeugen wir eine spezielle Datei.

Die Einstellungen sind mit Bildschirmfotos in Abbildung 1 und 2 dokumentiert.

Bildschirmfoto von OpenRefine Export Einstellungen 1.

Bildschirmfoto von OpenRefine Export Einstellungen 2.

Die Dateiendung der heruntergeladenen Datei ändern wir anschließend von .txt nach .csv.

Aufgabe 4: Datenexporte vergleichen

Wir öffnen die drei exportierten Dateien mit Excel.

Was sind die Unterschiede zwischen den Dateien?

Welcher Export eignet sich für welchen Anwendungsfall?

Hinweise/Lösungen:

Der normale Export berücksichtigt die momentan aktiven “Facets” und Filter.
Excel erwartet bei CSV ein Semikolon ; als Trennzeichen und windows-1252 als Kodierung. Daher sieht die erste CSV-Datei in Excel “seltsam” aus. ¹
Der normale CSV Export von OpenRefine ist mit Komma , getrennt und verwendet utf-8 als Kodierung, wie es von den meisten Anwendungen erwartet wird.
Beim spezifischen Datenexport hat man die Kontrolle darüber, was exportiert wird und kann Trennzeichen, Kodierungen, … beeinflussen.
Im FDMLab verwenden wir xlsx, wenn die Daten in Excel weiter bearbeitet werden sollen, und csv, wenn wir die Daten mit anderen Anwendungen weiter bearbeiten.

Microsoft Excel hat einen Textimport-Assistenten, mit dem auch andere Formate importiert werden können. ↩︎

Fazit

OpenRefine kann die Projekte in gängige Formate exportieren. Das ist schnell und bequem. Komplexer wird es bei verschachtelten Formaten wie XML. Das behandeln wir in unserem Workshop für Fortgeschrittene.

Im nächsten Teil beschäftigen wir uns mit den Mechanismen zum Clustering in OpenRefine.

05 Daten mit OpenRefine clustern

Encoding | FDMLab@LABW

Probleme mit Umlauten in OpenRefine

Umlaute in Metadaten sorgen für Speicherprobleme in OpenRefine 3.5

Daten richtig in OpenRefine laden

Nachgeladene Daten anpassen

Reguläre Ausdrücke mit Umlauten

Probleme mit Textfilter und Umlauten

Fazit

Workshop - Daten mit OpenRefine exportieren

Hintergrund

Aufgabe 1: Daten als Excel exportieren

Aufgabe 2: Daten als CSV exportieren

Aufgabe 3: Datenexport spezifizieren

Aufgabe 4: Datenexporte vergleichen

Fazit