Dateiformat-Explosion

Vorwort

Zum Bibliothekartag 2014 gab es im Nachtrag zu unserem Vortragsblock eine rege Diskussion darüber, ob es sinnvoll ist, erst einmal alle Dateien in ein Langzeitarchiv aufzunehmen und sich später Gedanken darüber zu machen, wie man deren Langzeitverfügbarkeit z. B. durch Formatmigration sicherstellt.

Ich habe viel recherchiert, aber wenig belastbare Zahlen gefunden. Ein guter Indikator könnten die Signaturen für DROID sein, einem Programm zur Ermittlung des Datenformates unbekannter Dateien.

Auf Pronom findet man 77 Versionen von 08-2005 bis 07-2014, von ehedem 766 bis heute 1.459 von DROID unterstützten Signaturen.

Alternativ könnte man die Datenbanken des Unix-Befehls file (http://www.darwinsys.com/file/) heranziehen. Auf ftp://ftp.astron.com/pub/file/ findet man Versionen von 08-2008 bis 06-2014.

Eine andere Möglichkeit wäre, die bei der IANA registrierten MIME-Types (zur Zeit 1.087 verschiedene Signaturen) heranzuziehen: http://www.iana.org/assignments/media-types/media-types.xhtml

Außerdem wurde ich noch auf http://fileformats.archiveteam.org/wiki/Main_Page aufmerksam gemacht.

Leider gibt es zu den letzten beiden Links keine auswertbare Timeline.

Was uns 'file' verrät

Wir können annehmen, dass sowohl bei 'file' als auch bei DROID, die Signaturen in gewisser Weise die Dateiformate enthalten, die auch weit verbreitet sind. Wie stark wissen wir nicht, aber wenn sie total unbedeutend wären, hätte sich keiner die Mühe gemacht, für diese Signaturen zu erstellen.

Wir können ferner annehmen, dass nach einer gewissen Einschwingzeit die Zahl der Dateiformate in diesen Signatur-Datenbanken der Anzahl der tatsächlich verbreiteten Dateiformate entspricht.

Im Folgenden das Diagramm der Entwicklung der Dateiformate basierend auf der file Magic Bytes Datenbank von Ende 1999 bis Mitte 2014.

Count of different fileformats based on magic bytes database of file, 08/2014, Andreas Romeyke

Als Grundlage für das Diagramm diente das GIT-Repository von file, genauer das Verzeichnis 'magic/Magdir'. Über die Tags extrahierte ich alle Versionen des Verzeichnisses und ließ das folgende Script die dem Diagramm zugrunde liegende CSV-Datei erstellen:

#!/bin/bash
echo "#version, date, group, count"
for version in *;do
  for sub in $version/magic/Magdir/* ; do
    group=$(basename $sub); 
    count=$(cat $sub | grep "^0" | wc -l);
    date=$(cd $version; git log --name-status --date=raw \
    --pretty='format:commit,%ae,%ai,%ce'| cut -d "," -f 3| head -n 1|\
    cut -d " " -f 1)
    echo "$version, $date, $group, $count"; 
  done ;
done

Sehr überraschend für uns war der nahezu lineare Verlauf der Formatvielfalt. Um auszuschließen, dass dies andere Ursachen hat, war es notwendig, eine zweite, von file unabhängige Quelle heranzuziehen.

DROID/Pronom als Quelle

Die Entwickler von DROID haben, wie oben bereits angedeutet, ihre Signaturfiles von Version 1 bis zur aktuellen Version 77 online angeboten.

Pronom hat als Projekt das Ziel, für Langzeitarchive eine verlässliche Quelle für Dateiformate, Signaturen und zugeordnete Programme bereitzustellen. DROID übernimmt als Programm die Aufgabe der Identifikation unbekannter Formate.

Durch den strukturierten Aufbau der Signaturdateien ist eine automatische Auswertung möglich.

Im Folgenden ist die Anzahl der verschiedenen Dateiformate über die Zeit zu sehen:

Count of different fileformats based on DROID signatures, 08/2014, Andreas Romeyke

Auch hier ergibt sich ein nahezu linearer Zuwachs, spätestens ab Mitte 2010.

Da erst in späteren Signaturen ab ca. 2009 auch MIME-Types hinterlegt wurden, sieht die Entwicklung der einzelnen Kategorien im folgenden Diagramm etwas anders aus:

Count of different fileformats per category, based on DROID signatures, 08/2014, Andreas Romeyke

Hier noch das Shell-Script:

#!/bin/bash
echo "#version, date, application, text, images, audio, video"
for i in droid/DROID_SignatureFile_V*.xml; do
  version=$(echo $i |sed -e "s/.*_V\([^.]\+\).*/\1/" );
  date=$(cat $i | grep -m 1 "DateCreated=" |\

  sed -e "s/.*DateCreated=\"\(....-..-..\).*/\1/" );
  echo -n "$version, $date,"
  for category in application text image audio video; do
    count=$(xmlstarlet sel -t -v\

    "//_:FileFormat[contains(@MIMEType, \"$category/\")]/@Name" $i| \

    sort | uniq | wc -l)
    echo -n "$count,"
  done;
  echo
done | sort -n 

Wenn pro Jahr also 90 neue Dateiformate…

Die Anzahl der  Dateiformate wächst nahezu linear. Pro Jahr kommen im Schnitt 90 neue Dateiformate hinzu, die immerhin eine solche Verbreitung erfahren, dass sie in den Signatur-Datenbanken Widerhall finden.

Wenn wir in Zeiträumen von 50 Jahren denken, haben wir knapp 5000 Formate zu behandeln.

Wer alles in sein Langzeitarchiv hineinkippt, was ihm seine Nutzer anbieten, wird daher in Zukunft kaum die Ressourcen haben, Spreu und Weizen zu trennen und eine Langzeitverfügbarkeit sicherzustellen.

Die Entwicklung zeigt, dass dringend eine Spezialisierung der Langzeitarchive notwendig ist, um Wissen über Formate aufzubauen und sich gegenseitig zu unterstützen.

Es zeigt auch weiterhin, dass Nutzer der Archive über die Problematik aufgeklärt werden müssen.

Am Ende der Nahrungskette?

Gestern war ich auf dem Bibliothekartag und im Anschluß der Vorträge zum Thema Langzeitarchivierung entspann sich eine kleine hitzige Diskussion, darüber ob man im Workflow die abliefernden Stellen dazu bekommen könne, Dokumente für das Langzeitarchiv zukünftig in besserer Qualität bereitzustellen.

Das Kernproblem ist, daß man im Langzeitarchiv aus folgenden Gründen nur archivfähige Dokumente halten möchte. Archivfähig (sh. Nestor Handbuch)  sind diese Dokumenttypen dann, wenn sie:

• offen spezifiziert sind, damit man im Notfall einen Programmierer heransetzen kann, falls keine anderen Werkzeuge mehr existieren
• große Verbreitung erfahren, weil dann die Chance hoch ist, daß genügend Erfahrungen mit dem Dokumenttyp vorhanden sind (und der Aufwandf sich ggf. lohnt)
• eine geringe Komplexität besitzen, da so Interpretationsmissverständnisse und damit Fehler minimiert werden
• ohne Rechtemanagment versehen sind, damit man die Dokumente ohne Probleme (Schlüssel weg, Anbieter existiert nicht mehr) lesen und verarbeiten kann
• selbstdokumentierend sind, sprich: wichtige Aussagen über das Dokument selbst, wie Autor, Erzeugungsdatum, Stichworte im Format hinterlegt sind. Hintergrund ist hierbei, daß man im Fall der Fälle, wenn nur noch dieses Dokument existiert, man den Katalog an Metadaten neu aufbauen könnte.
• robust gegen kleine Fehler sind. Fehler bleiben nicht aus. Seien es durch Hardware bedingte Bitfehler oder Fehler in der Software. Robust sein bedeutet auch, daß kleine Fehler im Datenstrom keine großen Schäden im Dokument nach sich ziehen. Deswegen fallen komprimierte (Teil-)Dokumente nicht unter diese Forderung.
• keine oder nur geringe Abhängigkeiten von spezieller Hardware, Software oder anderen Resourcen haben. 

Da die Welt nicht ideal ist, werden Bibliotheken immer auch Dokumente angeboten bekommen, die nicht obige Kriterien erfüllen.

Üblicher (vereinfachter) Workflow
für Bibliotheksaufnahme

Unsere Kollegin hatte in ihrem Vortrag folgenden Workflow vorgestellt, der versucht einen Kompromiß zwischen "idealer Welt" und "Wir machen es den Abliefernden so einfach wie möglich" zu erreichen, in dem Dokumente nach obigen Kriterien geprüft und bei Verletzung eine Automatische Korrektur (ggf. Konvertierung) in ein besser für die Langzeitarchivierung geeignetes Dokument zu erreichen. Da die Konvertierungstools dabei das Aussehen des Dokumentes verändern können, wird das Ergebnis dem Abliefernden zur Überprüfung mitgeteilt.

Erweiterter Workflow um Abliefernden
die Konformität zum Langzeitarchiv so
einfach wie möglich nahezubringen

Die Diskussion entspann sich daran, daß es "schlicht unmöglich sei, die Abliefernden damit zu belasten", weil man doch "froh drüber sein muss, wenn überhaupt abgeliefert werde". In dem Zusammenhang fiel auch der Satz: "Als Langzeitarchiv stehen wir am Ende der Verwertungskette" und der Abliefernde "hat ja gar keine Veranlassung an die Langzeitarchivierung" zu denken.

Ich halte diese Aussagen im Übrigen für eine faule Ausrede. Ja, es stimmt, zur Zeit ist kaum ein Bewusstsein für Langzeitarchivierung vorhanden. Aber da heißt es nicht, Kopf in den Stand zu stecken, sondern dieses Bewusstsein zu wecken.

Wir haben auch gar keine andere Wahl. Die Zahl der vielfältigen elektronischen Formate wächst  nahezu exponentiell. Die Zahl der elektronischen Publikationen (wie anfangs die der Bücher) ebenfalls.

„Europäische Produktion von gedruckten
Büchern ca. 1450–1800“ von Tentotwo,
CC BY-SA 3.0 über Wikimedia Commons.

Absatz EBooks in Deutschland, Quelle: Statista

Wenn wir nur auf Bitstream-Preservation (Reines Backup) setzen werden wir einen Großteil unseres kulturellen Erbes verlieren.

Als Gedächtnisorganistionen werden wir immer nur ein Bruchteil der Ressourcen zur Verfügung haben, es ist utopisch zu glauben, daß man, Zitat: "Badbank für Archive" einrichten könne. Also machen kann man das schon, doch es ist dann eine bloße Datenmüllhalde, die dem eigentlichen Zweck der Langzeitarchivierung, die Verfügbarhaltung und Sicherung der Nutzbarkeit von Dokumenten entgegenläuft.

Kurzum, wir leben nicht in einer idealen Welt, aber ein Grund zu kapitulieren ist das nicht. Wir müssen spätestens jetzt anfangen darauf hinzuwirken, daß von unserer Kultur mehr als nur die Reste bleiben.