BagIt ist ein quelloffenes, dateisystem-basiertes Container-Format der Library of Congress und der California Digital Library. Es definiert eine schlanke Verzeichnisstruktur, mit der digitale Inhalte zuverlässig transportiert, übergeben und aufbewahrt werden können. Seit 2018 ist BagIt als RFC 8493 standardisiert.

Die Idee ist bewusst minimalistisch: ein „Bag” ist ein Verzeichnis, das einen Payload-Ordner mit den eigentlichen Daten enthält und daneben Manifest-Dateien mit Hashwerten, die jederzeit eine Integritätsprüfung ermöglichen. BagIt schreibt nichts über die Inhalte selbst vor — es geht ausschliesslich um zuverlässigen Transport und Verifikation.

Aufbau eines Bags

mein-bag/
├── bagit.txt                 ← BagIt-Version + Encoding (Pflicht)
├── data/                     ← Payload (Pflicht)
│   ├── dokument.pdf
│   └── unterordner/
│       └── bild.tif
├── manifest-sha256.txt       ← Hashes aller Payload-Dateien (Pflicht ≥ 1 Algorithmus)
├── tagmanifest-sha256.txt    ← Hashes der Tag-Dateien (optional)
├── bag-info.txt              ← freie Metadaten (optional)
└── fetch.txt                 ← URLs für indirekte Bags (optional)

Pflicht-Dateien

  • bagit.txt — eine Mini-Datei mit fixem Inhalt: 
    BagIt-Version: 1.0
Tag-File-Character-Encoding: UTF-8
  • data/ — alle eigentlichen Inhalte als reguläre Datei-Hierarchie.
  • manifest-<algorithm>.txt — Hashwert + Pfad pro Payload-Datei. Mindestens ein Manifest ist Pflicht. Erlaubte Algorithmen: SHA-256, SHA-512, SHA-1, MD5 (empfohlen: SHA-256/512).

Beispiel manifest-sha256.txt:

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  data/dokument.pdf
4e4f… (Hash) … 0bf  data/unterordner/bild.tif

Optionale Dateien

  • tagmanifest-<algorithm>.txt — Hashes der Tag-Dateien (alles ausser data/). Schützt auch die Manifest-Dateien selbst gegen Veränderung.

  • bag-info.txt — freie Metadaten als Key: Value-Paare. Häufige Felder: Source-Organization, External-Identifier, Bagging-Date, Contact-Name, Bag-Size, Payload-Oxum.

    Source-Organization: Kränzle & Ritter GmbH
Bagging-Date: 2026-05-07
External-Identifier: KR-2026-05-07-001
Payload-Oxum: 12345678.42

    Payload-Oxum (Octetstream Sum) ist eine Schnellprüfung: <bytes>.<filecount> über alle Files in data/. Erlaubt vor der teuren Hash-Verifikation eine Plausibilitätskontrolle.

  • fetch.txt — verweist auf URLs, von denen Payload-Dateien später nachgeladen werden müssen. Erlaubt „Holey Bags” ohne lokal mitgelieferte Daten:

    https://example.org/file.tif  124356  data/file.tif

Validierung

Ein Bag ist valid, wenn:

  1. bagit.txt und data/ vorhanden sind.
  2. Mindestens ein manifest-<algorithm>.txt vorhanden ist und alle Payload-Dateien dort eingetragen sind (ohne Extra-Einträge).
  3. Alle Hashes übereinstimmen.
  4. Optional: tagmanifest-<algorithm>.txt validiert.
  5. Optional: alle in fetch.txt referenzierten Dateien sind erreichbar.

Ein Bag ist zusätzlich complete, wenn keine Datei fehlt — auch keine, die nur in fetch.txt steht.

Werkzeuge

  • bagit-python (Library of Congress) — Referenzimplementation; CLI und Python-Library.
  • bagit-java — Java-Implementation für JVM-basierte Workflows.
  • bagger — GUI-Werkzeug zum Erstellen und Validieren von Bags.

Beispiel mit der Python-CLI:

bagit.py --processes 4 mein-verzeichnis/
bagit.py --validate --fast mein-bag/      # nur Payload-Oxum (schnell)
bagit.py --validate mein-bag/             # mit Hash-Verifikation

Verwandte Standards

BagIt ist konzeptionell verwandt mit anderen Submission-Containern:

  • SIP nach eCH-0160 — Schweizer Standard, ebenfalls ein Verzeichnis mit Payload + Manifest, aber mit dem reichhaltigeren metadata.xml als Header.
  • METS — XML-basiertes Containerformat.
  • OAIS — abstraktes Modell, das Container-Begriffe wie SIP/AIP/DIP definiert.

Aus unserer Praxis

Bei Übergaben einzelner Sammlungen oder Datenpaketen, in denen wir keine vollständige eCH-0160-Struktur brauchen, nutzen wir BagIt als pragmatischen Container — gerade für interinstitutionellen Transport.