Ein Python-Abenteuer mit den Daten auf der Flucht

Montagmorgen, acht Uhr in Marburg. Die Tage werden kürzer, die Temperaturen sinken und Halloween ist gerade erst vorbei. In der Abteilung Digitalisierung des Hessischen Landesarchivs wartet bereits der nächste Fall. Die Verdächtigen befinden sich allerdings weder in den endlosen Gängen und Regalreihen des Magazins oder zwischen zahllosen Aktendeckeln und Archivkartons noch in den Büroräumen, geschweige denn im Lesesaal. Sie verstecken sich zwischen tausenden Zeilen XML.

Die Digitalisierung bearbeitet neben den Digitalisaten des analogen Archivguts ganz unterschiedliche Fragestellungen zu den digitalen Daten des HLA. Entsprechend vielfältig sind die Aufgaben: Daten analysieren, Auffälligkeiten prüfen oder Dateien automatisiert verarbeiten. Während meines Praktikums lag mein Schwerpunkt vor allem auf Python, XML und digitalen Daten. Python ist als Programmiersprache quasi unser treuer Gefährte Watson und unterstützt bei der Recherche und Analyse der Indizien. Der Programmiercode (Skript) ist unser rationaler von Logik getriebener Sherlock. Beide arbeiten in diesem Äquivalent zusammen.

Der Tatort ist XML (Extensible Markup Language): ein textbasiertes Format, in dem die Informationen zum Archivgut hierarchisch strukturiert werden. Vereinfacht lässt es sich mit einer Struktur eines Archivs vergleichen: Vom Gebäude über die Magazinräume, die Regale bis hin zur einzelnen Archivale. Die Angaben in den eckigen Klammern, sogenannte Tags, zeigen die Ebene in der wir uns befinden bspw. alle Informationen zum Bestand innerhalb der Tags <bestandinfo> und </bestandinfo> (siehe: Abb.)

Fall 1: Das PDF-Phantom

Mein erster größerer Fall klang zunächst simpel: Repräsentationen, die konkreten physischen oder digitalen Erscheinungsformen des Archivguts, mit der Bezeichnung „PDF“ in den Arcinsys-XML-Exporten finden. Doch ein Treffer allein genügte nicht. Entscheidend war auch die Frage, zu welchem Bestand und zu welcher Verzeichnungseinheit dieser gehört.

Das entwickelte Programmiercode durchsucht die XML-Dateien automatisiert, ordnet Treffer über ihre Signaturen zu und schreibt die Ergebnisse in eine CSV-Datei, mit der die Daten in einer menschenlesbaren Tabelle geöffnet werden können. Die Spuren sind gesichert – die verdächtigen Kandidaten müssen anschließend noch zur Gegenüberstellung. Es gilt festzustellen bei welchen Verzeichnungseinheiten die Bilddateien in der Repräsentation als PDF gekennzeichnet waren. Dies erfolgt anhand von Fingerabdrücken, wie den standardisierten Pfadangaben zu den Bilddateien, mit einer Datenbank.

Fall 2: Links und HTML auf Abwegen

Für digitale Daten gibt es auch gefährliche Elemente. Dazu gehören die Elemente von HTML, einer Sprache mit der die Daten von Webseiten strukturiert werden. Ein Beispiel sind Links, die etwa auf externe Webseiten führen, wie andere Archive oder weiterführende Infos zu historischen Quellen. Diese galt es zu identifizieren.

Der von mir programmierte Link-Finder durchsucht deshalb die Felder des XML nach den Mustern von HTML. Dazu folgen wir den mutmaßlichen Verdächtigen anhand eines Pfades von Indizien – in Form von HTML-Elementen – und sichern die zunehmenden Anhaltspunkte für die Beweiskette. Die einzelnen Indizien sind nicht automatisch problematisch. Sie können jedoch technisch oder sicherheitsrelevant werden. Die Ergebnisse der Analysen wurden deshalb zur weiteren Prüfung an die forensische Fachabteilung weitergegeben.

Dabei zeigte sich für mich ein zentraler Punkt: Automatisch auffällig bedeutet nicht automatisch fachlich gefährlich. Python kann vielfältige Muster finden und Hinweise liefern – ihre Bedeutung muss weiterhin im archivischen oder technischen Kontext bewertet werden, egal in welchem weiteren Anwendungsbereich.

Fall 3: Wenn aus Analyse ein Eingriff wird

Ein weiterer Fall ging noch einen Schritt weiter. Diesmal mussten Digitalisate an die Benennungsrichtlinien des HLA angepasst und an das Archivinformationssystem angehängt werden. Da ein Fehler hier tatsächlich Dateien verändern könnte, arbeitet Sherlock zunächst nur im Trockenlauf. Er erstellt eine CSV-Datei mit den geplanten Änderungen. Erst nach einer Kontrolle werden die Änderungen ausgeführt. Konflikte oder unklare Fälle bleiben unangetastet. Automatisierung soll schließlich Arbeit erleichtern – nicht die Kontrolle ersetzen.

Akte geschlossen?

Nicht ganz.

So unterschiedlich die einzelnen hier kurz abgebildeten Aufgaben auch waren, hatten sie einen gemeinsamen Kern: Fachliche Fragestellungen mussten zuerst verstanden und anschließend in technische Regeln übersetzt werden. Aus einzelnen Skripten entstand so nach und nach ein kleiner modularer Werkzeugkasten. Einige Spuren führen inzwischen zur weiteren fachlichen Prüfung nach Wiesbaden, beim PDF-Phantom steht noch der nächste Abgleich aus – und irgendwo zwischen CSV, XML-Datei und Digitalisat wartet wahrscheinlich bereits der nächste Fall.

Sherlock bleibt also beschäftigt.

Und Watson Python wartet schon auf den nächsten Aufruf.

Rebecca Navel, Philipps-Universität Marburg