OCFL (Oxford Common File Layout) ist eine Spezifikation für die applikations­unabhängige, versionierte Speicherung digitaler Objekte im Dateisystem. Entstanden 2018 in einer Arbeitsgruppe um die Universitätsbibliotheken Oxford, Stanford, Cornell, der LoC und anderen, ist OCFL seit 2020 in Version 1.0 stabil; aktuell ist 1.1 (2024).

Die Kernidee: ein OCFL-konformer Speicherort ist auch dann lesbar und rekonstruierbar, wenn die ursprüngliche Software (oder der ursprüngliche Anbieter) nicht mehr existiert. Alle Strukturinformationen sind als reguläre Dateien im Storage abgelegt. Damit adressiert OCFL ein altes Problem der Langzeitarchivierung: viele AIP-Container hängen an proprietären Repositorien, deren Verlust den Zugang zu den Objekten erschwert.

Zentrale Eigenschaften

  • Selbstdokumentierend — alle nötigen Metadaten zur Rekonstruktion sind als Dateien im Storage.
  • Versioniert — jede Änderung erzeugt eine neue Version, alte Versionen bleiben unverändert.
  • Inhalts-adressiert — Dateien werden über ihre Hashes referenziert; gleiche Inhalte werden nur einmal gespeichert (Deduplikation).
  • Robust gegen Korruption — jede Version hat eine vollständige Manifest-Datei mit Hashes; Fixity-Checks sind trivial.
  • Keine Server-Logik nötig — cp -r reicht zur Sicherung; Tools sind nützlich, aber nicht zwingend.

Storage-Struktur

storage_root/
├── 0=ocfl_1.1                  ← Storage-Marker (NAMASTE)
├── ocfl_layout.json            ← welche Storage-Layout-Extension wird genutzt
├── extensions/                 ← optionale Extensions
└── ab/cd/ef/abc...id/          ← Object-Pfad nach Storage-Layout
    ├── 0=ocfl_object_1.1       ← Object-Marker (NAMASTE)
    ├── inventory.json          ← Manifest, Version-Map, Fixity
    ├── inventory.json.sha512   ← Hash der Inventory-Datei
    ├── v1/
    │   ├── inventory.json
    │   ├── inventory.json.sha512
    │   └── content/
    │       └── files…
    ├── v2/                     ← jede neue Version eigenes Verzeichnis
    │   └── …
    └── …

Objects haben stabile Identifier (URIs oder lokale Strings). Die Storage-Layout-Extension legt fest, wie der Identifier auf einen Pfad abgebildet wird (z. B. N-Tuple Omit Prefix: hash des Identifiers in 3-stellige Tupel).

Die inventory.json

Das Herzstück eines OCFL-Objekts:

{
  "id": "ark:/12345/bcd987",
  "type": "https://ocfl.io/1.1/spec/#inventory",
  "digestAlgorithm": "sha512",
  "head": "v3",
  "manifest": {
    "abc123…": ["v1/content/foto.jpg"],
    "def456…": ["v2/content/foto-corrected.jpg"]
  },
  "versions": {
    "v1": {
      "created": "2024-01-15T10:00:00Z",
      "message": "Initial deposit",
      "user": { "name": "ak", "address": "mailto:ak@k-r.ch" },
      "state": {
        "abc123…": ["foto.jpg"]
      }
    },
    "v2": {
      "created": "2024-02-20T14:30:00Z",
      "message": "Farbkorrektur",
      "user": { "name": "ak", "address": "mailto:ak@k-r.ch" },
      "state": {
        "def456…": ["foto.jpg"]
      }
    }
  }
}

Drei Schlüssel-Sektionen:

  • manifest — Hash → physische Pfade (im Storage).
  • versions — pro Version: Datum, Message, User; und der State (Hash → logische Dateinamen).
  • fixity (optional) — zusätzliche Hash-Algorithmen (z. B. md5 zu sha512).

Validierung

Ein Validator prüft:

  1. NAMASTE-Marker auf Storage- und Object-Ebene.
  2. inventory.json existiert in der Wurzel und in jeder Version, mit identischem Inhalt (vorletzte Version) bzw. konsistenter Erweiterung (aktuelle Version).
  3. Hashes aller Manifest-Einträge stimmen mit den realen Dateien überein.
  4. Versions-Reihenfolge ist lückenlos (v1, v2, …).

Standard-Tool: fcrepo-ocfl oder ocfl-py mit validate-Befehl.

Verhältnis zu anderen Standards

  • OAIS — OCFL ist ein konkreter Speicher-Layout-Standard für AIPs. Wo OAIS abstrakt vom „Archival Storage” spricht, gibt OCFL eine Implementation vor.
  • BagIt — verwandtes Konzept (datei­system-basierter Container mit Manifest + Hashes). BagIt ist Transport-Format für eine Übergabe, OCFL ist Storage-Format mit Versionierung.
  • METS / PREMIS — PREMIS-Events können in einer OCFL-Object-Version als zusätzliche Datei mitgegeben werden; OCFL kümmert sich um Speicher-Layout, METS/PREMIS um die inhaltliche Beschreibung.

Werkzeuge

  • fcrepo 6 — Fedora Repository Server nutzt OCFL nativ als Storage Backend.
  • Hyrax / Samvera — Repository-Stack für wissenschaftliche Bibliotheken; OCFL-Storage-Adapter.
  • ocfl-py — Python-Library + CLI (Stanford).
  • rocfl — Rust-CLI mit guter Performance.
  • OCFL-Java — Java-Library der Universitätsbibliothek Oxford.

Aus unserer Praxis

Unser PHP-Paket ocfl ist eine Implementation der OCFL-Spezifikation in Version 1.1 — siehe ocfl in unseren Open-Source-Paketen.