Probleme mit Umlauten in OpenRefine

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).

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.

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.

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:

1. Umlaute explizit auflisten: [a-zäöüß]
2. Spezielle Klasse für Buchstaben (letter) verwenden: \p{L}
3. Spezielle Klasse für alphabetische Zeichen verwenden: \p{IsAlphabetic}
4. 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:

1. Einen Begriff mit Umlauten aus dem OpenRefine Projekt in einer separaten Datei speichern und mit einem Hex-Editor analysieren.
2. 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.
3. 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.