PREMIS Events

In PREMIS ist das Event die Entität, die jede einzelne Bearbeitung eines digitalen Objekts protokolliert. Die Summe aller Events zu einem Objekt ergibt seine Provenienz im Archiv — von der Übernahme bis zur Aussonderung. Ohne lückenlose Event-Kette gibt es keine vertrauenswürdige Langzeitarchivierung im Sinne von OAIS und ISO 16363.

Dieser Spickzettel vertieft den Event-Teil von PREMIS: Welche Felder gehören zu einem Event, welche eventType-Werte sind gebräuchlich, und wie sieht eine typische Ingest-Kette aus.

Die Felder im Überblick

Element	Pflicht	Inhalt
`eventIdentifier`	ja	eindeutige Event-ID (Type + Value)
`eventType`	ja	Typ aus kontrollierter Liste (siehe unten)
`eventDateTime`	ja	ISO-8601-Zeitstempel
`eventDetailInformation`	nein	freier Text mit Details (Tool-Aufruf, Parameter)
`eventOutcomeInformation`	empfohlen	`success` / `failure` / `warning` mit Detail
`linkingAgentIdentifier`	empfohlen	welcher Agent (Person / Software) hat es ausgeführt
`linkingObjectIdentifier`	empfohlen	welches Objekt war betroffen

Die Verknüpfungen über linking*Identifier machen aus einzelnen Events einen navigierbaren Graph: Vom Event zum Objekt zum nächsten Event, vom Event zum Agent.

eventType — die kontrollierte Liste

PREMIS schreibt die Werte für eventType nicht zwingend vor, die Library of Congress pflegt aber das Preservation Event Type Vocabulary als SKOS-Liste. Die wichtigsten Typen, gruppiert nach Lebenszyklus-Phase:

Übernahme

accession — formelle Aufnahme in den Bestand
appraisal — Bewertungsentscheidung
ingestion (oder ingest start / ingest end) — Eintritt in das Archivsystem
transfer — Übergabe von einer Stelle an eine andere
information package creation — Bildung eines AIP

Identifikation und Charakterisierung

format identification — z. B. via Siegfried oder FIDO, mit PUID als Resultat
message digest calculation — Hash-Berechnung
metadata extraction — Extraktion technischer Metadaten (z. B. mit ExifTool oder JHOVE)

Validierung

validation — Strukturprüfung gegen ein Schema (XML, TEI, METS)
fixity check — Vergleich des aktuellen Hashes mit dem hinterlegten
virus check — Malware-Scan beim Ingest

Erhaltungsmassnahmen

migration — Format-Migration (z. B. WAV → FLAC, DOC → PDF/A)
normalization — Überführung in Archiv-Zielformat beim Ingest
replication — Kopie an einen weiteren Speicherort
refreshment — Datenträger-Refresh ohne Format-Änderung

Manipulation

creation — Neu-Erzeugung (z. B. einer Repräsentation aus Quell-Files)
compression / decompression
encryption / decryption
digital signature validation

Zugriff und Aussonderung

dissemination — Auslieferung als DIP
deaccession — Aussonderung aus dem Bestand
deletion — physische Löschung
quarantine — temporäre Isolation (typisch nach virus check mit Fund)

Die Liste ist nicht abgeschlossen — eigene Werte sind erlaubt, sollten aber dokumentiert und konsistent verwendet werden. Wer format identification mal als format-identification, mal als format_identification schreibt, vergiftet die Auswertbarkeit der eigenen Provenienz.

eventOutcomeInformation

Drei gebräuchliche Werte für das Resultat:

success — Event erfolgreich abgeschlossen
failure — fehlgeschlagen, das Objekt ist möglicherweise in inkonsistentem Zustand
warning — durchgelaufen, aber mit Auffälligkeiten (z. B. format identification mit niedrigem Confidence-Score)

eventOutcomeDetail nimmt den maschinen- oder menschenlesbaren Detail-String auf — typisch das Tool-Output, ein Stack-Trace oder der konkrete Fund. Diese Information ist im Schadensfall der einzige Anhaltspunkt für die Forensik; sie sollte vollständig erhalten bleiben, nicht nur „Errorcode 42”.

Eine typische Ingest-Kette

Was Archivematica oder eine vergleichbare OAIS-Pipeline pro übernommenem File generiert (vereinfacht):

1. transfer                    SIP wird übernommen
2. virus check                 ClamAV
3. format identification       Siegfried → fmt/19 (PDF 1.4)
4. metadata extraction         ExifTool, JHOVE
5. validation                  JHOVE: well-formed and valid
6. message digest calculation  SHA-256 = e3b0c4…
7. fixity check                gegen den im Manifest hinterlegten Hash
8. normalization               PDF 1.4 → PDF/A-1b
9. ingestion                   Eintritt in den AIP
10. replication                Spiegelung auf zweiten Storage-Pool

Jeder Schritt ist ein PREMIS-Event mit success / failure, jeweils mit Verweis auf das Object und den ausführenden Agent. Die Kette ist linear lesbar und maschinell auswertbar — z. B. um Fragen zu beantworten wie „wann wurde dieses Objekt zuletzt fixity-geprüft?” oder „welche Files sind nie validiert worden?”.

Beispiel — ein Event in XML

<event xmlns="http://www.loc.gov/premis/v3">
  <eventIdentifier>
    <eventIdentifierType>UUID</eventIdentifierType>
    <eventIdentifierValue>e3b0c442-98fc-1c14-9afb-f4c8996fb924</eventIdentifierValue>
  </eventIdentifier>
  <eventType>format identification</eventType>
  <eventDateTime>2026-05-09T09:14:02Z</eventDateTime>
  <eventDetailInformation>
    <eventDetail>siegfried 1.11.0 (signature: pronom-v117)</eventDetail>
  </eventDetailInformation>
  <eventOutcomeInformation>
    <eventOutcome>success</eventOutcome>
    <eventOutcomeDetail>
      <eventOutcomeDetailNote>fmt/19 (PDF 1.4) — confidence: extension and byte match</eventOutcomeDetailNote>
    </eventOutcomeDetail>
  </eventOutcomeInformation>
  <linkingAgentIdentifier>
    <linkingAgentIdentifierType>local</linkingAgentIdentifierType>
    <linkingAgentIdentifierValue>siegfried-1.11.0</linkingAgentIdentifierValue>
    <linkingAgentRole>executing program</linkingAgentRole>
  </linkingAgentIdentifier>
  <linkingObjectIdentifier>
    <linkingObjectIdentifierType>local</linkingObjectIdentifierType>
    <linkingObjectIdentifierValue>obj-2026-001</linkingObjectIdentifierValue>
    <linkingObjectRole>source</linkingObjectRole>
  </linkingObjectIdentifier>
</event>

Granularität — wie viel ist genug?

Eine Daumenregel: Jede Operation, die das bitstream-Niveau ändert, das Format umrechnet oder das Vertrauen in das Objekt beeinflusst, sollte ein Event sein. Keine Events nötig sind für rein technische Vorgänge ohne Risiko (z. B. das Lesen einer Datei für die Auslieferung — das ist ein dissemination-Event auf AIP-Ebene, nicht pro read()).

In der Praxis erzeugt Archivematica pro Ingest-Vorgang dutzende bis hunderte Events. Das ist nicht zu viel — die Auditierbarkeit hängt genau daran.

Verhältnis zu W3C PROV-O

PROV-O (W3C Provenance Ontology) und PREMIS-Events lösen ein verwandtes Problem auf unterschiedlichen Ebenen:

PROV-O — domänenneutrale Provenienz: prov:Activity, prov:Agent, prov:Entity. Geeignet für Forschungsdaten, wissenschaftliche Workflows, generische Datenpipelines.
PREMIS-Events — domänenspezifisch für digitale Erhaltung. Hat eingebaute Begriffe wie fixity check, migration, normalization, die in PROV-O erst modelliert werden müssten.

Mappings PREMIS ↔ PROV-O existieren (LoC publiziert eine OWL-Variante), in der Praxis bleiben aber meist beide Welten getrennt.

Werkzeuge

Archivematica — generiert PREMIS-Events automatisch über die gesamte OAIS-Pipeline. Der Standard-Referenzfall.
Rosetta (Ex Libris) — proprietär, native PREMIS-Events.
PREMIS Validator (LoC) — Schema-Validierung für PREMIS-Dokumente inkl. Events.
bag-info-Tools — BagIt generiert keine PREMIS-Events, aber bag-info.txt plus die Manifest-Hashes liefern die Rohdaten für fixity check-Events.