3.7 Erhaltungsplanung

3.7.1 Zielsetzung der Erhaltungsplanung

Die Erhaltungsplanung (Preservation Planning) ist ein zentrales Element der digitalen Langzeitarchivierung. Ihr Ziel ist es, die dauerhafte Authentizität, Integrität und Nutzbarkeit aller eingelieferten Daten gemäß dem OAIS-Modell sicherzustellen. Dazu werden geeignete Maßnahmen identifiziert, bewertet, dokumentiert und umgesetzt.

Authentizität bedeutet, dass Archivdaten vollständig, korrekt und nachweislich dem Original entsprechen. Sie wird gewährleistet durch Prüfsummen (Checksums) bei der Paketierung, regelmäßige Integritätsprüfungen (Fixity Checks) im Archivbetrieb sowie die Dokumentation nachvollziehbarer Provenienzinformationen.

Nutzbarkeit bedeutet im Kontext der Meißner Porzellanmanufaktur, dass die digitalisierten 3D-Modelle auch in Zukunft zur Herstellung passgenauer Gipsformen einsetzbar bleiben. Dies erfordert wohldokumentierte signifikante Eigenschaften, den Einsatz archivtauglicher Formate bereits bei der Digitalisierung, anlassbezogene Formatmigrationen auf neue Standards sowie die dauerhafte Bewahrung aller zur Verarbeitung notwendigen Metadaten. Auch fotografische Dokumentationen müssen so erhalten bleiben, dass Dekorationsmaler:innen die Bemalung detailgetreu und farbverbindlich rekonstruieren können. Dazu gehört neben der Farbtreue der Bilddaten auch die Archivierung von Farbnummern bzw. Mischungsverhältnissen, um spätere Reproduktionen konsistent zu ermöglichen.

3.7.2 Risikoanalyse (Technology Watch & Community Watch)

Die Erhaltungsplanung nach dem OAIS-Modell beginnt mit einer strukturierten Risikoanalyse. Dabei kommen zwei sich ergänzende Strategien zur Anwendung:

Die Technology Watch verfolgt technologische Entwicklungen rund um Speichermedien, Dateiformate, Rendering-Software (z. B. Blender, MeshLab, Autodesk-Produkte) und Betriebssystemkompatibilitäten. Sie erkennt Risiken wie Bit-Verfall oder schwindende Formatunterstützung (z. B. OBJ zugunsten von glTF) frühzeitig und leitet daraus entsprechende Migrationsbedarfe ab.

Die Community Watch erfasst parallel die Anforderungen der relevanten Zielgruppen – etwa Kunsthistoriker:innen, Restaurator:innen, 3D-Druck-Dienstleister:innen, die Porzellanmanufaktur und die GLAM-Community – insbesondere in Bezug auf Dateiformate, Wiederverwendbarkeit und modellierungsrelevante Standards.

Beide Beobachtungsansätze fließen in eine zyklische Risikoanalyse ein und bilden die Grundlage für die priorisierte Planung und Umsetzung von Erhaltungsmaßnahmen.

3.7.3 Erstellen von SIPs

Bei der Einreichung von Daten in ein digitales Archiv erstellen die Datengebenden ein Submission Information Package (SIP). Es enthält alle Datenobjekte und die zugehörigen Metadaten. Die Struktur des SIP wird vom Archiv vorgegeben; in diesem Projekt kommt das weit verbreitete Baglt-Format zum Einsatz.

Verwandte Datenobjekte und Metadaten werden als „intellektuelle Einheit“ (abgekürzt „IE“) zusammengefasst. Eine Porzellanfigur, wie etwa der Kakadu von Johann Joachim Kändler, bildet mit allen zugehörigen Objektdaten und Metadaten eine solche IE. Archive wie das SLUBArchiv.digital stellen jede IE in einem eigenen AIP dar. Dessen Einlieferung ins Langzeitarchiv erfolgt in Form eines SIPs, das alle zu einer Figur zugehörigen Tonteile, Scans und Fotos enthält.

3.7.3.1 Beispielhafter Aufbau eines SIP im Use Case

999999999_111111111111111/
│   bag-info.txt
│   bagit.txt
│   manifest-md5.txt
│   manifest-sha512.txt
│   tagmanifest-md5.txt
│   tagmanifest-sha512.txt
│
├───data/
│   │   color_mixtures.xml
│   │   color_mixtures.xsd
│   │   meissen_extension.xsd
│   │   mets.xml
│   │
│   ├───clay_parts/
│   │   ├───clay_part001/
│   │   │   ├───processed_meshes/
│   │   │   │   ├───mesh_gltf/
│   │   │   │   │       mesh.bin
│   │   │   │   │       mesh.gltf
│   │   │   │   │
│   │   │   │   └───mesh_stl/
│   │   │   │           mesh.stl
│   │   │   │
│   │   │   └───scans/
│   │   │       ├───processed_scans/
│   │   │       │   └───scans_e57/
│   │   │       │           scan.e57
│   │   │       │
│   │   │       └───raw_scans/
│   │   │           └───scans_e57/
│   │   │                   scan.e57
│   │   │
:   :   :
│   │   │
│   │   └───clay_part013/
│   │       ├───processed_meshes/
│   │       │   ├───mesh_gltf/
│   │       │   │       mesh.bin
│   │       │   │       mesh.gltf
│   │       │   │
│   │       │   └───mesh_stl/
│   │       │           mesh.stl
│   │       │
│   │       └───scans/
│   │           ├───processed_scans/
│   │           │   └───scans_e57/
│   │           │           scan.e57
│   │           │
│   │           └───raw_scans/
│   │               └───scans_e57/
│   │                       scan.e57
│   │    
│   ├───overview_photos/
│   │   └───photos_tif/
│   │           00000001.tif  (alle mit eingebettetem ICC-Profil)
:   :           :
│   │           00000006.tif
│   │
│   └───painting_reference_photos/
│       └───photos_tif/
│               00000001.tif  (alle mit eingebettetem ICC-Profil)
:               :
│               00000015.tif
│
└───meta/
        rights.xml
        sigprops_meissen_porcelain_for_reproduction.xml

Jedes SIP erhält eine eindeutige ID, hier z. B. 999999999_111111111111111 , die nach einem Schema des Archivs festgelegt wird. Im SLUBArchiv.digital setzt sich diese aus einem vom Produzenten vergebenen Identifier (hier: 999999999) und einem vom Archiv vergebenen Workflow-Identifier (hier: 111111111111111), über den das SIP eingeliefert wird, zusammen.

Einige Archive speichern zusätzlich zu den archivtauglichen Masterdateien auch abgeleitete Derivate (z. B. für Online-Präsentationen). In diesem Projekt wird jedoch ausschließlich die Masterdatei für die Langzeitarchivierung berücksichtigt.

3.7.3.2 Paketierung und Dateneinreichung ins Archiv

Die Erstellung von Submission Information Packages (SIPs) kann entweder automatisiert über ein vom Archiv bereitgestelltes Werkzeug (z. B. Webschnittstelle oder Kommandozeilenprogramm) erfolgen oder über das Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH), das Objekte und Metadaten aus definierten Quellen einsammelt.

Nach der Erstellung werden die SIPs im Rahmen des sogenannten Ingest-Prozesses in das Archiv überführt. Dieser umfasst:

• die Prüfung auf Vollständigkeit und Integrität (unter anderem anhand von Prüfsummen),
• den Abgleich mit den Archivvorgaben,
• die Identifikation und Validierung von Dateiformaten,
• sowie ggf. Formatkorrekturen, die Extraktion technischer und beschreibender Metadaten und die finale Strukturierung der Archivpakete.

3.7.3.3 Formatidentifikation

Die automatisierte Erkennung von Dateiformaten erfolgt mithilfe spezialisierter Tools wie DROID, Siegfried oder Fido. Diese Werkzeuge sind häufig in etablierte Archivsysteme wie Archivematica, Rosetta oder Preservica integriert.

Einzelne Formate weisen oft mehrere Varianten auf:

• Vom glTF-Format existieren z. B. die Versionen 1.0 und 2.0, die sich nicht allein anhand der Dateiendung .gltf unterscheiden lassen.
• STL-Dateien können sowohl in ASCII- als auch in Binärform vorliegen, obwohl beide Varianten die gleiche Erweiterung .stl tragen.
• TIFF umfasst unterschiedliche Spezifikationen (z. B. Baseline-TIFF und TIFF 6.0) mit vielfältigen Optionen wie Mehrseitigkeit oder Komprimierungsverfahren.

Zur präzisen Erkennung solcher Unterschiede werden Formatsignaturen im Bitstream analysiert. Diese Signaturen sind standardisiert und werden in Formatdatenbanken wie PRONOM gepflegt. Auf Basis dieser Informationen können Archive Formatversionen zuverlässig identifizieren und dokumentieren.

Problemfall:
In Voruntersuchungen zeigte sich, dass STL- und glTF-Dateien von den Identifikatoren Siegfried 1.10.1 und Fido 1.4.1 nicht immer eindeutig erkannt wurden.

Lösung:
Im Rahmen dieses Projekts wurde daher ein Erweiterungsskript für Archivematica 1.13.2 entwickelt, das Siegfried mit Fido kombiniert („Siegfried Falls Back on Fido“) und so die Stärken beider Tools vereint.

3.7.3.4 Formatvalidierung

Nach der Identifikation eines Dateiformats erfolgt dessen Validierung anhand der offiziellen Formatspezifikation. Nur so lässt sich sicherstellen, dass die übermittelten Daten spezifikationskonform sind – eine grundlegende Voraussetzung für die langfristige Erhaltung und Weiterverarbeitung.

Für gängige Formate wie PDF, PNG, WAV oder XML stehen in Archivsystemen etablierte Validatoren bereit, wie etwa JHOVE, veraPDF (für PDF/A) oder MediaConch (für AV-Formate wie MKV, FFV1, LPCM). TIFF-Dateien lassen sich z. B. mit checkit_tiff prüfen.

Spezialisierte 3D-Formate erfordern hingegen eigene Validierungsansätze:

• glTF: Validierung mit den von der Khronos Group bereitgestellten Tools (Webinterface und Kommandozeilen-Tool).
• E57-Punktwolken: Prüfung über die Kommandozeilen-Tools aus libE57.
• LAS/LAZ: Nutzung von LAStools für Konvertierung, Filterung und Validierung.
• STL: Da bislang kein offizieller Validator existiert, wurde in diesem Projekt ein eigener „STL Validator for Archivematica“ entwickelt.
• DAE (COLLADA) und X3D: Für beide Formate wurden eigene Referenzimplementierungen ergänzt, um die bestehenden Lücken in Archivematica 1.13 zu schließen.

Ergebnis: Für alle genannten Formate konnten gezielte Validierungsprozesse ergänzt werden – entweder durch bestehende externe Tools oder durch eigene Erweiterungen, sofern Archivsysteme diese bisher nicht unterstützten.

3.7.3.5 Formatkorrektur

Um sicherzustellen, dass Dateien den jeweiligen Formatspezifikationen entsprechen, fordern einige Archive – wie das SLUBArchiv.digital – Datengebende auf, Korrekturen bereits vor der Archivübernahme vorzunehmen. Ziel ist die Behebung formatbedingter Fehler, damit Dateien erfolgreich validiert und langfristig archiviert werden können.

Für diesen Zweck existieren verschiedene spezialisierte Werkzeuge:

• TIFF-Dateien: Korrekturtool zur Behebung fehlerhafter Metadaten oder Strukturprobleme.
• STL-Dateien: Im Rahmen dieses Projekts wurde der STL Cleaner entwickelt, der Spezifikationsverstöße bereinigt, ohne die 3D-Geometrie zu verändern.

Beispiel: Korrektur von STL-Dateien

Fehlerhafte STL-Dateien können 3D-Workflows und die Archivierung stören. Einige verbreitete Tools exportieren 3D-Daten nicht streng gemäß der ursprünglichen Spezifikation von Marshall Burns. So schreibt MeshLab z. B. den Generatornamen („STL generated by MeshLab“) nach dem solid-Tag und den verwendete Bibliotheksnamen der Visualization and Computer Graphics Library („vcg“) nach dem endsolid-Tag. Zudem treten teilweise unerlaubte Werte wie negative Koordinaten auf.

Der STL Cleaner wurde entwickelt, um solche Spezifikationsverletzungen automatisiert zu bereinigen und somit die Archivfähigkeit sicherzustellen.

Vorbereitung: Prüfung der Geometrietreue mit Blender

Vor der Anwendung des STL Cleaners muss sichergestellt werden, dass das 3D-Modell geometrisch korrekt (mannigfaltig) ist. Dies bedeutet, dass jede Kante genau zwei Flächen teilt und das Modell keine Löcher oder unzulässigen Strukturen enthält. Die Prüfung und Korrektur erfolgt in Blender:

1. Blender öffnen und zu Edit > Preferences > Add-ons gehen.
2. Nach „3D Print Toolbox“ suchen und aktivieren.
3. STL-Datei importieren (File > Import > STL).
4. Taste „N“ drücken und den Reiter „3D Print“ auswählen.
5. Im „Edit Mode“ das Modell mit der Taste „A“ auswählen.
6. Auf „Check All“ klicken, um Probleme zu identifizieren
7. Auf „Make Manifold“ klicken, um nicht-mannigfaltige Geometrien zu korrigieren.
8. Das Modell erneut überprüfen und als bereinigte STL-Datei exportieren.

Abschließend: Anwendung des STL Cleaners

Nach der Geometrieprüfung erfolgt die Formatkorrektur mit dem STL Cleaner. Dabei werden alle verbleibenden Verstöße gegen die Spezifikation entfernt. Das Resultat ist eine valide STL-Datei, die sich problemlos paketieren und archivieren lässt.

Vergleich vor und nach der Korrektur

Wichtig: Alle STL-Dateien müssen vor der Paketierung mannigfaltig und bereinigt sein, um die Archivvalidierung zu bestehen.

3.7.3.6 Metadatenextraktion

Im Anschluss an die Formatvalidierung erfolgt die Extraktion technischer Metadaten. Diese sind essenziell für die Risikobewertung und die Planung langfristiger Erhaltungsmaßnahmen. Technische Metadaten geben Auskunft über Formateigenschaften, Komprimierung, eingebettete Ressourcen und Strukturmerkmale.

Beispielsweise können glTF-Dateien in unterschiedlichen Versionen vorliegen und sowohl verlinkte als auch eingebettete Ressourcen wie Texturen oder Bump Maps enthalten. Auch TIFF-Dateien können komprimiert oder unkomprimiert sein – eine Information, die für die Risikobewertung besonders relevant ist, da komprimierte Daten in Archiven möglichst vermieden werden.

Das Wissen über diese Eigenschaften ermöglicht es Archiven, gezielt formatabhängige Metadaten zu extrahieren und darauf abgestimmte Erhaltungsstrategien zu entwickeln.

Zur Metadatenextraktion stehen verschiedene Tools und Erweiterungen zur Verfügung:

• Das offizielle glTF-Validierungstool der KhronosGroup gibt neben der Formatprüfung auch grundlegende Metadaten aus. Darauf aufbauend wurde im Rahmen von NFDI4Culture eine Archivematica-Erweiterung für glTF-Modelle entwickelt.
• Für STL-Dateien wurde ein eigener STL Metadata Extractor für Archivematica implementiert.
• Die libE57-Tools ermöglichen die Extraktion technischer Metadaten aus E57-Punktwolken. Auch hier wurde ein ergänzender E57-Metadatenextraktor für Archivematica realisiert.
• Für etablierte Formate wie TIFF, PDF/A oder XML kommen bewährte Werkzeuge wie ExifTool oder FITS zum Einsatz.
• MediaInfo ergänzt diese Tools um Metadatenanalyse für Multimedia-Dateien und ist Bestandteil vieler Archivsysteme.

Durch die Kombination spezialisierter Tools und detaillierter Formatkenntnis lassen sich strukturierte, formatnahe Metadaten extrahieren, die die Grundlage für die langfristige Verfügbarkeit und Nachnutzbarkeit digitaler Objekte bilden.

3.7.4 Speicherung im Archiv

Nach der Übertragung der Submission Information Packages (SIPs) in das Archiv werden diese in Archival Information Packages (AIPs) überführt. AIPs enthalten sämtliche für die Nachvollziehbarkeit relevanten Informationen – darunter durchgeführte Prozesse, technische Merkmale und dokumentierte Erhaltungsmaßnahmen. So ist der gesamte Lebenszyklus eines Archivobjekts lückenlos nachvollziehbar.

3.7.4.1 Bitstream Preservation

Die Bitstream Preservation dient der Sicherung der Datenintegrität digitaler Objekte. Sie stellt sicher, dass Dateien unverändert erhalten bleiben und keine unbeabsichtigten Änderungen am Bitstrom auftreten. Wichtige Maßnahmen sind:

• Georedundanz:
  Speicherung mehrerer Kopien an mindestens zwei physisch getrennten Standorten schützt vor lokalen Ausfällen und gewährleistet hohe Verfügbarkeit.
• Auffrischung (Refreshment):
  Regelmäßiges Kopieren auf neue Datenträger verhindert Datenverluste durch Medienalterung.
• Prüfsummenchecks (Fixity Checks):
  Durch kontinuierliches Vergleichen gespeicherter und neu berechneter Prüfziffern lassen sich Datenkorruptionen frühzeitig erkennen und beheben.

3.7.4.2 Content Preservation

Die Content Preservation zielt auf den langfristigen Erhalt der Nutzbarkeit und Lesbarkeit digitaler Inhalte. Sie gewährleistet, dass Daten auch auf zukünftigen Systemen interpretierbar bleiben – insbesondere durch:

• Migration:
  Veraltete Formate werden verlustfrei in moderne und unterstützte Formate oder neuere Versionen desselben Formats konvertiert.
  1. Beispiel:
     Das British Museum erstellte zunächst 3D-Modelle – darunter Porzellanfiguren – im OBJ-Format. Später wurden diese in glTF überführt, um sie auf Plattformen wie Sketchfab und in VR/AR-Anwendungen nutzbar zu machen.
  2. Beispiel:
     Auch auf Google Arts & Culture finden sich Sammlungen, die ursprünglich in glTF 1.0 vorlagen. Mit der Weiterentwicklung der Plattform und der verbesserten Unterstützung für AR/VR wurden viele Modelle auf glTF 2.0 migriert. Dies ermöglichte realistischere Materialien, verbesserte Texturen und höhere Interaktivität.
• Emulation:
  Ist eine verlustfreie Migration nicht möglich, kann der ursprüngliche Softwarekontext durch virtuelle Umgebungen bereitgestellt werden.
  • Beispiel:
    Alte AutoCAD-Dateien lassen sich nicht immer fehlerfrei in neuere Versionen übertragen. Durch Disk-Images von Windows 3.1 und AutoCAD 12 können diese Daten mit Emulatoren wie DOSBox auch auf modernen Betriebssystemen genutzt werden – ohne Informationsverlust.